Jason's Development Blog

How to make a Video Game Engine in an easy flowchart

by on Aug.13, 2011, under Games, Programming, Technology, Video Games

Long Answer: Don't

A common mistake people learning programming with an eye towards game development make is the idea that they require a game engine. It just seems natural, a car needs an engine to move so surely a game needs an engine. If only life were so simple.

Look at the history of most of the successful game engines in history, let’s use the Unreal Engine and the id Engine for my examples here, and you’ll find they started off with the game and the engine came afterwards. The Doom Engine (precursor/father to/first version of the id Engine) was not written to be a powerful game engine (for the time), it was written to run Doom. It just so happened a lot of the code got reused in other projects and thus the id Engine was born.

The Unreal engine began, oddly enough, with the game Unreal. Then a lot of the code for Unreal got used in lots of games that followed, being changed, refined and completely rebuilt along the way.

Game engines are not so much invented as they are accidentally created. You write a game, and then you refactor a lot of the code you used so it can be used in a later game. This alone is often enough for the developers/publishers/marketing department to say that both games run on a modified version of the same engine. And I guess technically it’s true.

The idea of a game engine is inherently ill-defined, it can mean a whole lot of things. At the end of the day, seeking to create a “Video Game Engine” is a foolish endeavour, as trying to create something ill-defined often is. Without a lot of luck and skill, you’ll get distracted by the shiny things you can do and at best you’ll wind up with a fantastic technical demo, but not something wholly individual you can use to make a game.

In fact, one could easily argue that the creation of a technical demo, getting someone to run around the screen, is one of the simplest aspects of game development. It is often the unique aspects of a game, the unique code which doesn’t quite always fit efficiently into the average generic “engine”, that provide the real challenges in coding and in developing.

The reason the Unreal Engine, the id Engine and the Source engine are at their current state of awesome is because they have been used to create so many games that the code-base has been refactored, modified and reused countless times in a long, iterative process. This is how a true game engine is made: iteratively.

The best way to make a ‘game engine’ is, at the end of the day, almost always going to be to make a game. The old adage, “Make games, not engines”, is as true today as it was in the days of Doom.

Quote of the Day
“My advice to you, if you’re trying to write an engine, is: Don’t. No matter what your reasons are — it doesn’t matter if you’re writing an engine so you can write your dream game, or if you’re writing an engine because you think it will be a good learning experience, or any number of similar reasons. They’re all wastes of time.”
http://scientificninja.com

:, , , , , , , , ,

  • http://notimetoplay.org/ Felix Pleșoianu

    You’re so right. Wish I would have written this article. Indeed, I know someone who worked on game engines for many years, and never came up with an actual game. He did end up working at CryTek, though. Guess that’s the part he cared about all along.

    The section where you explain why making an engine first is a bad idea is worth expanding, though. I would add that getting a dude to run around a map is the easy part; that’s why so many amateur gamedev efforts seem to get abandoned at this stage. But when you start making an actual game that’s supposed to be interesting and fun, it turns out to be exponentially more difficult, and not (just) because of the coding! All those special cases that no longer fit into an uniform, general engine are hard to figure out in the first place, let alone made to work. And until you’ve made them work — until you have a game worthy of the name — you don’t know what you’ll need in the engine.

  • TheHypnotist

    Back when I made my first game in the late ’80s, there was no such thing as a game engine, so when I got back into programming my attitude was “I don’t make game engines, I just make games”. The whole game engine thing seemed like unnecessary extra effort, and apparently I was right on the money in that regard; thanks for shedding some light on the subject.

  • http://notimetoplay.org/ Felix Pleșoianu

    Actually, TheHypnotist, having an engine is VERY necessary once you get around to making your second game, or the third… or the tenth. It’s just a bad idea to make the engine before the first game — that’s like putting the cart before the horses.

    Oh, and there *was* such a thing as a game engine back then. I know for a fact that there were text adventure authoring systems, at the very least; there must have been similar things for other kinds of games.

  • SpareTimeLearning

    I am teaching myself C# at the moment and have gotten to the point of cloning the originals. Ive been researching state machines, and the question came to me, “Will I need an engine?”. After three days of reading I find this post and it is a relief. :) I can now be excited about just testing my knowledge and concentrate on making a game WORK, no more examples or mini programs to test arrays and enums some actually niddy griddy dirty code if need be. Gotta get my hands wet now but thank you very much for the insite, at just the right time!