A long rant on Game Engines (Part 2)

Xplicity

Pros of writing a custom game engine

Probably the best part about writing a game engine yourself is the complete freedom. You want something unique or specific in your game? You implement it. Is there something useless? Then you just omit it. There are only the things that you have written yourself. Also, that’s useful when you have a very specific way of organizing everything within the game. Sometimes it might be that your game idea just dictates a certain hierarchy within the game world. Well, you can implement it as easily as the other thing – you will be building your game engine from the ground up either way.
The next point that stems directly from this is the complete control. If you are a control freak, a commercial game engine might be your worst enemy. There are a lot of default hidden quirky behaviors in 3rd party game engines. They are all good and fun until you suddenly realize that you need to change it. And then follows the frustration of finding it, understanding it and rewriting or working around it so, that it matches your particular needs. Game engines of today are quite flexible, but… That’s a lot of time and effort wasted, instead of implementing it the way that was needed from the very beginning. So, if you want to have the complete control and the complete understanding of your game engine, maybe it’s a good idea to write it yourself?
When you do it on your own and you really know what you’re doing, the performance within the custom game engine might be absurdly good. You only allow it to perform tasks that are needed, nothing out of the scope, nothing wasted. You can sometimes even make use of very esoteric specific and extremely performant quirks within the API itself.
Also, one of the byproducts of creating everything from scratch in such a complex environment is that the rendering algorithms will inevitably end up being different from everyone’s else. Trust me, there are a great lot of moving parts involved. And even miniscule changes or mistakes (a blessing in disguise) when added create the drastic differences. So, that means that your game will look and feel quite different from the rest.
A super nice thing about custom engine is that a footprint can be very small. You can create nice expansive games that occupy a fraction of the disk space to compare with something created using a commercial engine. Basically, because you have the option of not adding ANYTHING you don’t need. If you go to extreme absurdities, you can even create a 3D game with all bells and whistles: different weapons, enemies, textures, level design, VFX, particles, music and SFX. All totaling in… wait for it… 96KB! Yes, you have read it right: ninety-six kilobytes. The game I’m talking about is called “.kkrieger”. As one comment under the demo video said – a screenshot of this game in action weighs more than 96k. All this was achieved by procedurally generating content when the game starts up and using other clever optimizations wherever possible.

Now one part of this approach that is kind of neutral is the usage of external libraries. For example, many of the commercial engines come with some form of physics simulations. Graphics API has no concept of physics within it. So, if you would be building a custom game engine, you’d now have to build a physics engine too. Or you could use an external library instead – something like Havok or ODE. This also goes for anything else you might need – video playback, content loader helpers, advanced spatial sound libraries. This is a mixed bag, as it always is with external libraries. And that does not necessarily mean that 3rd party engine users would never use an external library either.

Cons of writing a custom game engine

If you start from the absolute zero, it might be really discouraging and inspiration killing when you don’t see anything popping up on your screen for quite some time. Up to a week for simple shapes. And months upon months until you can get something looking like the original image in your head. These terms get a lot longer if you are new. You should be aware of the fact, that it can demotivate you really quickly if you were not expecting to work on it that long. Just compare that to several hours of work for the same result, when are using a commercial engine!
As mentioned previously, you’d have to write EVERYTHING yourself. And I mean it. Even if you use external libraries, you will need to create some adaptors to be able to utilize them. So, be prepared for huge work overheads.
One of the biggest issues and the reason why people often get discouraged and go for commercial engines is the multiplatformity. When you write a game engine from scratch, chances are that you’d be targeting something very specific – for example DirectX on Windows or Gnm on PlayStation. And those low-level specifics would not be transferrable. Now, you could abstract that specific low-level layer, thus decoupling your “business logic” to be transferrable and reusable among all platform implementations. And that would be exactly what other game engines do to achieve this miraculous “runs on everything” tagline. But, again, you will have to do that for every platform you want to target. That means learning not one low level API, but as many as you’d want to go for.
Stemming from the complexity of low-level APIs, the learning curve here is very, very steep. Knowing how to code is a necessity, not a nice-to-have thing. You will have to learn low-level API like DirectX or OpenGL. You will also have to learn how graphical pipelines work (sometimes across multiple generations of the same API, which can be drastically different from one another). Moreover, you will need to learn a shader language. And all this to pretty much start out – display a polygon on a screen. I should, however, mention that this highly depends on the technology chosen – some APIs are a lot more forgiving than others. For example, XNA and MonoGame are a lot more friendly to newcomers, allowing you to skip over certain daunting areas.
Now contrary to the popular commercial engines like Unity or Unreal, the amount of information in the field of custom engine creation might be a bit too scant. The reason is that the more people are using a technology, the more tutorials you can find. The publicly available APIs are well documented, but quite technical. And when it comes to custom engine building, it often is just an enthusiast hobby or, otherwise a trade secret of a game development company. So, not much information finds it’s way back online. You can find information in enthusiast forums, but this comes with that specific “enthusiast flavor” that I, for one, don’t really dig. For really specific platforms and their implementations (think Nintendo and Sony PS) I’d hazard to guess you can only get the documentation if you partner with famous companies themselves. It is not out of the realms of possibility that if you encounter a certain problem when writing your own custom engine, you might be the only person in the whole world that has it. Or at least the problem is so specific, that finding the solution is akin to finding a needle in a haystack.

My approach

If you have read any of my previous articles you might have noticed that I do like to dig deep into the graphical APIs myself. And being one of those control freaks, who need to know everything that goes under the hood of my game engine, has nothing to do with it. For me the process itself is fun – its challenging, educational and I am in no hurry to meet any strict deadlines. So, I guess, I pretty much fall into that “enthusiast” category.

The technology stack I use is:

MonoGame as the base framework
Physically broken custom written physics simulation when / if I need it
Xamarin and bits of batch files that allow me to switch between platforms – Windows / iOS / Android / Windows Phone (sigh).

To sum up the overall experience of this approach, I’d probably say that it is great on the straights: implementing game loop logic, ability to use clean standard C# and the ability to access the underlying graphics API is absolutely awesome. The power of the MonoGame is beastly and I’d say it is underused in the world of game development.

Now when it comes to the corners – getting platform specific bits going, finding workarounds, long release cycles of the framework and some parts that are starting to rapidly age (yes mojoshader, I’m looking at you!) it can get quite frustrating. Sometimes the frustration dragging the effort into months of little-to-no progress.

But in the end, the few chances I get to squeeze an hour or two to work on it – it’s a blast!

Conslusion and my advice

So, what eventually is the best engine or environment to create games in, so that people would look in awe at the marvel you have created? I guess you already know the answer. The tools don’t really matter if you squeeze the maximum out of them. What matters is an idea, direction, discipline and perseverance. After those four, the selection of the engine and the approach comes just as a matter of your own preference.

Still don’t believe me? Still think there is the one ring to rule them all (editor’s note: ring = game engine)? Let me give you a real-life example. I must come clean and admit that in my youth I smirked at people who used GameMaker for their games. I used to think that it was really low to create games using the tool like this. That all of the games bearing that stigma were trashy and that “real” game makers only used code (of course, only C++). And then I got to play Nuclear Throne.

Ok, I’ll leave you with a rule of thumb:

if you don’t know anything and you are just starting out, it is best to start with a game engine. You will learn a lot just by playing around. You will learn it fast. And it will be a fun, painless experience.
if you already have quite some experience with low level APIs and game development, you are a moderate studio, or maybe you have a very particular idea – you might entertain the thought of writing your own engine from scratch. You might want that uniqueness to shine through. And this way you’ll have the most control over it.
if you are a big studio that creates triple A titles the answer gets a tad bit murky. You will need to hire a lot of talents that are experienced in the industry standard field. You will probably target various platforms to keep the studio afloat. In that case it is probably a good idea to get back to working with a 3rd party game engine, because you will most likely make a good use of all the deeper features of the engine (or rewrite parts of it that don’t really work for you). It is also likely, that you can decide to create your own engine in-house if you see that such would fit the companies interests better.

EXTRA HINT: be smart and don’t make the mistake I made. Don’t start with DirectX as your first introduction to game development.