I LOVE GODOT SO MUCH. It. Just. Works. I tried learning Unreal, I truly did... In Unreal I spent 3 hours trying to figure out why my materials normals had all flipped on my imported model, I never figured it out so I remade my own materials. I then spent a good 5 hours banging my head against the wall that is animation retargeting in Unreal. GODOT ON THE OTHER HAND??? 30 seconds for model and material import, 5 minutes for animation retargeting!!!!!!!! WHAT??? HOW IS THIS NOT THE INDUSTRY STANDARD???? Some other things I adore about Godot:
- Physics and spring bones built in
- LookAtModifier3D makes bones point towards things so you can like make a character look at an object super easy
- SSAO and SSR built in
- IK rigs are easy to make
- Easy .blend file import
- GDScript hot reloading while game is running
- Super simple GLSL shader tools
- Built in light shader type
- Super advanced UI components
- Works on any platform
- Works with YarnSpinner
I'm sure there's more and I just haven't explored enough
When discussing performance issues in games, how much blame should be put on the game engine that a developer is using? A while back, Unity had somewhat of a bad reputation among people online due to its wide use in a lot of low quality mobile games. However, game developers were quick to point out that that was less of an issue of Unity itself and more about how people were using Unity. Does the same idea apply to UE5? Or are there legitimate issues with the engine that hurts the end product?
The real answer here is the practical approach - you do what you can with what you've got. It is entirely possible to reach out to the engine developers and make requests, but they have their own priorities and not beholden to each licensor for quick turnaround on bug fixes and feature requests, so it is up to the individual dev teams to recognize what they can and can't do within the time they have. When this is the case, developers must pivot to working within the areas that they can work - our own code, our own assets, our own resource usage - in order to bring things back to the needed performance levels.
I actually found a bug with one of UE5's systems a while back. It was a broken system that couldn't be used the way it was. I reported it to Epic via their Unreal Developer Network and they acknowledged the bug and said it had been prioritized for a fix, but that it would likely not make it to a public engine release for at least two version updates. That put the coming fix several months away, which was too far away for our needs - we couldn't table development for several months to wait for their fix. Instead, we had to come up with a different solution that would work within our time frame, which we did.
If we can't fix the engine, we must work within the framework it provides and do what we can. Players aren't going to accept unperformant gameplay and accept the nuance of engine issues, they'll stop playing the game out of frustration and the game will likely not do well. It behooves us as practical developers to work around the issues as best we can and produce the best game we can within our circumstances. Every engine is a big batch of tradeoffs - they are really good at some things and not so good at others - this is why we evaluate what kind of game we're trying to make, what kind of technology we need to make it, and what kind of engine would best suit our needs. We have only so many development resources and development time, so it is up to our leadership to make judicious decisions when determining where and how to spend our developer resources.
[Join us on Discord] and/or [Support us on Patreon]
🧠💾🛠️ I've always had a fascination with The Sims franchise and I am currently looking to get into programming. How was The Sims created? What programs were used (Python, Java, etc.)? What programs and computer languages would I need to learn to emulate this sort of game? - Quora
Answer by Eric Bowman:
I was part of the core Sims team. The first Sims code was written by Jamie Doornbos, later I joined him along with Don Hopkins; the three of us wrote pretty much all of the core code using Visual C++ and used a lot of STL. We also adapted an internal Maxis framework called Gonzo, written by a few people including Paul Pedriana (Paul later drove EASTL). I ended up rewriting a lot of Gonzo specifically for The Sims, but it was a nice windowing abstraction to get started with. I'm still quite proud of my text edit widget, which had all kinds of features totally unnecessary for a computer game, but I had a little time to kill while the game play was coming together.
I think the precursor to the original character animation code was written by Jacques Servin, who was responsible for the famous SimCopter easter egg (SimCopter) and is now one of the Yes Men (in an odd twist of fate, along with a college acquaintance of mine, Igor Vamos). Or maybe Jamie helped him with that, I honestly can't remember.
We wrote a ton of code as a small team, and it was 100% C++ -- there wasn't a single line of assembly code in The Sims, at least not in the core code. By the time it shipped we were using a few internal EA libraries as well, in particular for font rendering. We also didn't use 3d acceleration at all, which turned out to be a good call for massive market penetration. We hit a sweet spot in terms of CPU requirements for smooth gameplay and Moore's Law. We also had basically no unit tests; back then Real Programmers didn't test their own code, which led to an army of testers (who were amazing) and basically a lot more pain that necessary. I'm really happy the world moved toward automated unit testing since then.
Jamie created the "tree language" which gave the characters behavior, which they received from the objects they interacted with. Patrick Barrett was the first and probably greatest tree programmer of them all, and added a huge amount to the game.
One thing that I recall is that the original prototype for The Sims, written by Jamie (in C++) was written for the Mac. When he ported it to Windows, he introduced some Mac-like data abstraction layer to make the Mac code work on Windows, and some of that survived in the shipped game. That must have made porting it back to the Mac particularly interesting (as did my somewhat flagrant use of the DirectX APIs in a way that I'm still embarrassed by).
One thing we considered doing was using Swatch Internet Time which looked like it might take off there for a minute or two, and that would have been an interesting twist how time worked in the game.
There is an ok history of The Sims at the Will-Wright Fansite ::.
Source:
Answer (1 of 2): I was part of the core Sims team. The first Sims code was written by Jamie Doornbos, later I joined him along with Don Hopk
Hey if you're interested in making RPGMaker Games...
... but find the cost prohibitive, especially if you've never done it before and just aren't sure if that sort of thing is for you...
The RPGMaker Engines are all on sale, the older ones at absurdly low prices but - and this is what you really need to know - RPGMaker MV, second to most recent, is 93% off right now.
RPGMAKER MV IS 5.59USD (taxes may vary) until FEB. 10, 2025 ON STEAM
POWERFUL enough for a developer SIMPLE enough for a child VERSATILE enough for any platform!RPG MAKER MV allows you to make the RPG of your
***NOTE: MV games, while originally Mac-friendly, got hamstringed by Apple and are really only good for PC and old Mac systems - check to see how old, I really don't remember.
If you're interested, the "latest and greatest" RPGMaker MZ is 55% off which is 35.99USD. As far as I know, MZ is still compatible with Mac.
You want to create an RPG, but every game making tool you have found was either too complex or too limited? RPG Maker MZ empowers you with s
My hope for this post is to impart some hope.
I’ve been making this stuff for a very long time.
There is a large world of alternatives out there, many of them deserving a lot more attention. Each offer their own vibrant communities, support, philosophies, and mentalities surrounding making a game.
With the recent Unity news... whether they walk it back or not, they've made it clear they can't be trusted. Nathalie Lawhead, digital artist, video game developer, and game blogger, put together a reflection on this move, the way it follows a similar trajectory as the death of Flash.
And they have a truly impressive list, with descriptions, explanations, and uses, of other game engines and game-making software. Many of them are independent or open-source. If you are a game developer or interested in game development, it's a great resource to think about in the wake of Unity tanking itself.
Both are made by the same people, have the same motivations, are made in the same language. Experiencing the former is a good experience. However, experiencing the latter is a whole other dimension of interesting. OpenGL is fun to learn, and Portal is fun to play. But I’ve decided to start using Vulkan, and god damn, there’s a lot. You have to enumerate through and interface with devices, you have to create debug messengers, validation layers, buffers, arrays, etc.. Portal 2 gave me that same feeling. (Spoilers for Portal 2): [Falling down into Test Shaft 09 was the moment I realized this game is a lot deeper than I thought. You have to manage repulsion and propulsion gels, tractor beams, faith plates, lasers, and more.] Once you use OpenGL/play Portal, you start to get good at it and can crank out a playthrough/project in a few hours. With Vulkan/Portal 2, it takes a hell of a lot more dedication, but by god its worth it.
