Let’s talk about game engines yet again

Apr 26, 2022 at 07:45 am by nemirc

Let’s talk about game engines yet again
Let’s talk about game engines yet again

As of today, there are a lot of choices when it comes to game engines. On top of that, others are also trying to make, and distribute, their own game engines. Just last week I saw someone in a game developers group post about the game engine he was making on his free time, and he said he wanted to distribute it for those who wanted to use it. I am all for testing new applications and all, but when I saw that post all I could think about was “why should I use this engine over Unity or Unreal Engine?”

As I said before, in reality it’s not just a matter of “Unity versus Unreal” because there are a lot of more engines. The reason I wondered that is because those are the two engines I use. However, things are no longer about “Unity versus Unreal” and haven’t been like that for a while.

For example, there’s Godot engine, a free, open-source engine that I’ve covered in the past, and that now even lets you make games on your Android phone. Godot is the perfect example of a very good, and free, game engine that can compete with major engines like Unity or Unreal Engine. The fact that Godot is open source also means you can extend the functionality of the engine, and even use it to develop console ports of your games, since you could program your own console-compilers and add those to the engine. Other engines include Game Maker, CryEngine and Lumberyard (AKA Amazon’s Twitch-ready CryEngine). There are a lot of engines to choose from, but it cannot be denied that Unity and Unreal Engine are still the dominant forces.

When it comes to choosing a game engine, my first question is “what kind of game you want to make.” While my original plan was to make “slow-story-driven games,” that has changed over the years. I have worked on a variety of games, with different gameplay styles and focuses. For example, while Enola and The Dreamlands: Aisling’s Quest are both story-driven games, one of them is horror while the other one is puzzle-based. Now, if we add Just Let Me Go into the mix, we have another story-driven horror game, except this one utilizes stealth mechanics. If it was Enola, I could be fine working on any engine, but then The Dreamlands is a different situation, because, to make the game, we used a point-and-click system found in the Unity Asset Store which made us save a lot of time. Lastly, Just Let Me Go uses a lot of stealth mechanics and AI tools in Unreal Engine make this work a lot easier than the non-existent AI tools in Unity. Besides, we are using realistic hair for the characters in that game, and that’s a feature I’ve only found in Unreal Engine.

A few weeks ago, someone I know was going to start development of a game using Unreal Engine. After some back and forth, I convinced him UE was too much for the kind of game he was going to make (a hyper-casual game) so he decided to use Unity. I could have said something like “there’s also Godot” but he was choosing between the engines he’s more familiar with, and this brings me to my next point…

It is always good to know at least a couple of engines. I think I have voiced my thoughts in the past when it comes to 3D applications (“pick one and stick with it”), but game engines are different. For example, if you have been making 3D games in Unity and, for some reason, your next game is going to be 2D, maybe GameMaker could be a good option if you knew how that engine works. I like Unity I am not a fan of the 2D toolset.

Of course, to do all this you need to devote some of your time to “research and development.” You can’t just pick an engine because you saw a video where it supposedly does what you need. I am not saying learn all the engines out there, but at least know a little bit about two or three engines so you can choose which one to use depending on the project, rather than sticking to one because “it’s the best.”

Doing this research will save you a lot of time in the long run, because you will be able to pick the best tool for the job. While I believe that “it’s the artist, not the tool,” it is also true that the tool will save you a lot of time and make your job easier. For example, you can make a very detailed 3D human in the old 3D Studio R4 for MS-DOS, but it’s going to take you way longer than making it in the latest version of 3D Studio Max. The same has happened with another of the projects I’m working on: Killer Dolls Battle Arena. I began development in Unity, but the AI tools in Unreal convinced me to make the move. I could still make the game in Unity, but making the good AI for the enemies would have taken longer (unless I had purchased add-ons to replicate the functionality inside Unity).

Of course, there’s always the chance you want to make games of a similar style, and just build upon what you already have. For this kind of iterative project, where you gradually add features to your “base engine” as you release games, it’s better to stick to the engine you’re using. For example, after Killer Dolls Battle Arena I want to use the same “base engine” to make another top-down bullet hell game, and adding extra features to what I already have is going to be easier than making a new top-down game in another engine.

At the end of the day, choosing the engine is about the current plan and also future plans, and since these can change as you progress, the choice of engine might also change.

Sections: Tips + Tutorials

This website uses cookies to ensure you get the best experience possible More Info
Got it!