Resources and discussion about good game engine design and clean code

[Elias Daler]

I'm a big fan of good, readable and maintainable code.

I believe that writing high quality code is important: it saves your sanity, allows you to iterate quickly and do whatever you want with your game without having to deal with coupling issues and random bugs.

So, I hope this thread starts some productive discussion about things that can make your code and engine architecture better. I'll start with some resources, feel free to add everything you liked.

I'll also occasionally write here about some things that made my code much better and I'd like to hear some similar stories from you!

Books:

• Code Complete by Steve McConnell [Amazon]
• Game Engine Architecture by Jason Gregory [Amazon]
• Game Programming Patterns by Bob Nystrom [Amazon] (also available for free online here)
• SFML Game Programming by Jan Haller, Henrik Vogelius Hansson, Artur Moreira [Packtpub]

Articles:

• Fix Your Timestep!
• The guide to implementing 2D platformers

Talks: // todo
Open source games with good code: // todo

[Ironbell]

Great idea. I already know some of the articles/books you posted and will surely take a look at the others.

Creating an engine that is maintainable, efficient and also has high usability requires a lot of skill in my opinion and it's never wrong to learn from the experience of other devs. It's particularly interesting for devs working with SFML because SFML is no game engine but a library suitable to develop one.

The main insight I've gained developing an engine is that the engine's code should not grow when adding content to the game. Everything content-related should come from outside, using scripts/xml/databases/other files but no code. You don't want to recompile your game only because a line in a dialogue changed.

I've managed to apply this insight in my engine to dialogues, npcs, level/map files, special enemy behaviour, items, equipment, quests, music, translations, weather, triggers...
I didn't manage to do it for enemies, sound and special game objects (like a trampoline for example). I'm still working on it because having to create a c++ class for each enemy is not as flexible as it could be.

I'm currently also working with Unity and try to distinguish which parts of that engine are good and which are rather bad ideas.

Anyway, thank you for this thread. If I stumble upon a great article regarding engine design, I'll post it.

[Blader]

Much like Ironbell I think game and engine should be separate, but I think go one step further split up your code into two main aspects, each having very modular and as much as possible separate libraries:

• Game Engine
• Rendering
• Physics
• Networking
• File
• Logging
• Command Line Parsing Library
• Reflection
• Serialisation\Deserialisation
• Entity System
• Scene Management
• Input
• Audio
• UI
• Pathfinding
• Framework
• Inventory\Item\Equipment System
• Statistic System (Health, Mana, Strength etc)
• Quest System
• Ability System
• Weather System
• Player Controllers
• AI Controllers

Then all your game really is, is linking and initialising the systems, libraries and modules you want to use and then providing the data for them.

The next step is then have a clean API. By clean I mean only have one method for doing something. Look at this as an example:

Entity* entity = new Entity(...);
world->AddEntity(entity);

// And

Entity* world->CreateEntity(...);

// And

Entity* entity = new Entity(world, ...);

 

What you want to think about is, will the end user be confused by this many options and what is my actual use case for this code? Does an entity need a world or vice versa? Who owns the entity? Can we simplify to one option?

From there it's the basic:

• Const correctness
• Smart Pointer \ Owner semantics
• Single Responsibility Principle