Tutorial 2.0: What exacty is a Game Engine?

In the first Episode (that sounds cool), we learned how to make an utterly basic "game" with LibGDX. We explained the targets, and laid down the first bricks for an engine by making a camera class. In Episode TWO, the saga continues. With making some more "engine code".

Here a simple engine "skeleton". How do I know if the engine structure should look like this? I don’t, but after creating quite a bunch of games / engines, my gut feeling says this will do fine for this type of game. Forgive me if we change a little bit along the course. I just write as I go.

An important detail here, is the strict separation between Engine and Game. What this means? Game knows everything about the engine it uses, but Engine doesn’t know anything (specific) about the Game. The creators of "Gears of War" utilized the Unreal engine to power the game graphics, sound, controls, physics, asset-loading, maps, and so on. But vice-versa, Unreal engine was not made with Gears of War in mind. Hene, that title probably didn't even exist while they were cooking Unreal.

  

Engines are Generic by nature, yet still with constraints and "favours". Unreal for instance was mainly made for (3D) shooters and the likes, not for racing games or The Sims. That means a lot of the tools and code classes, are designed with 3D and certain ways of level design in mind. Maybe too much 3D to make a 2D platform game, or physics not sophisticated enough to make a racing game. Though as Unreal got more mature, more and more has become possible. And of course, you can always extend the engine with your own code and tools to make things possible. That is... if the engine has been designed with that flexibility in mind.

In short, the engine should stay generic, multi-purpose. Once you are done with this game, you should be able to pick up the engine-parts, and create a very different game with it again. But in a much shorter perioid, as you don't have to write a whole new code base of course. Stuff like graphics, sounds, collision detection or pathfinding are already there for you. So you can focus on the "Game" part, which is mainly about making content (images, sounds, levels, menu's), scripts, specific types of A.I., and of course the game rules.

Making a clean generic engine is pretty darn difficult to do properly. And also, for a relative small hobby game like this, it might be a bit overdone. When they say "Make Games! Not Graphics!", they may as well tell me "Make Games! Not Engines!". But still, code that has been setup properly will always pay off on the long term. Especially if you wrote ten-thousands lines of code, then get distracted by a girl/boy/school/work/corona/Doom Eternal for the next 5 months. Quick & Dirty Junk code will be unreadable, even for you. Clean code is easier to pick-up again. It's that bit of discipline to write thngs more thoughtful, and in a clean way. 

Then again, unless you wrote 20 engines already, don't be ashamed to just go ahead and experiment. Mainly the bad design mistakes that makes the engine stiff and clunky, will be your best learning moments when doing it all again a next time. We won't be creating Unreal here. Just showing you the basics, which are useful for the actual game we'll be creating.