To begin with, the term “engine” (specifically as it related to the game development world) has no strict definition. Therefore, in the interests of keeping everybody on the same page, I’ll define the term as I intend to use it in this article. An “engine” is a collection of robust, reusable software subsystems (possibly including both code libraries and tools) designed to facilitate the development of actual games by addressing specific requirements. The requirements tend to be broadly-defined: rendering, audio, physics, et cetera. Particularly ambitious engines that address multiple broad requirement groups tend be to known as “game engines” rather than just “graphics engines” or “physics engines.”
Now that that’s out of the way, let’s turn to the real issue: how to build engines, and more specifically, if you should even bother.
For any number of reasons, many neophyte game developers (and even some moderately experienced ones) seem to think that a game engine is a required, critical part of a game. They think that — in keeping with the mechanical analogy from which the term “engine” comes from in the first place — like a car, a game with no engine will simply not run. But that mechanical analogy starts to break down when you take it this far, because when you look at the reality of the situation, a game engine is about reusable components. Much like you can build a car with custom parts or generic ones, you can build a game with custom components or reusable ones. The fact that you must have an engine to build a non-trivial game is a fallacy, something perpetuated largely by people who don’t know any better.
Nonetheless, every so often comes the obligatory post on GDNet by somebody who has decided its time for them to write their engine, so they can start making some real games. These posts usually consist of requests for resources about the engine design and development process, and in fact chances are that if you’re reading this, it’s because I caught you making just such a post and linked you here so that I could crush your dreams with a minimum of effort on my part.
So 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. You can sit down and write a game without writing a pre-written engine, and in fact this is very often the better approach, regardless of why you want to write an engine. The entire development process goes much more smoothly if you are focused on writing a game instead: a game is much easier to identify requirements for, much narrower in focused, much more rewarding when finished, and much, much more useful.
Most hobby developers who “finish” an “engine” that was designed and built in isolation (with the goal of having an engine, not a game, upon completion) can’t ever actually use it, and neither can anybody else. Since the project didn’t have any goals, any boundaries, or any tangible applications, it essentially attempted to solve aspect of the chosen problem space and consequently failed miserably. These “engines” tend to be little more than an inconsistent and messy amalgamation of random functionality that isn’t terribly practical, robust or reusable. Furthermore, the actual viewable end product of these “engines” tend to be a cute little map (loaded from one of the popular BSP formats) you can run around in and observe some cute little models (also loaded from a popular model format) rendered with some fairly basic lighting effects (maybe some per-pixel normal mapping or parallax mapping). Maybe you might even see some collision detection or animation. These projects are just tech demos, and not particularly compelling ones at that. There is nothing to them, and they feel rather flimsy and inflexible.
The solution, even if you really want to make an engine, is to make a game instead. I can hear you crying out in protest from here, but just bear with me for a minute. The game does not have to be an epic production. It does not have to be GTA5, Quake 17, the next Elder Scrolls game, or a WoW-killer. It just has to be a game, with well-defined (and ideally well-thought-out) gameplay and well-defined developmental scope. A game is much easier to identify requirements for, as I’ve already mentioned, and it is also a practical application of those requirements. Once you have made one game, make another. Then another. Each time you start a new project, you should identify functionality that could be used and pull it out into a common library of base code. You’ll probably have to refactor some of your code to remove explicit dependencies on other code or data that is game specific, but this is a good thing. It will help you generalize what is generalizable in a way that you can still test the generalized functionality against your finished game and confirm that it still works (obviously you might have to modify some game-specific code to adapt to the increased generality, as well).
If you repeat this process long enough, after a few games you’ll have the beginnings of a solid collection of reusable functionality that has been proven to have practical applications. You’ll also have a set of far more interesting demonstration applications that could also double as test harnesses for your engine. This method of growing an engine (rather than manufacturing it from whole cloth) is superior because it helps you shape your goals, it forces you to actually think about the problems you will face and their practical implementations, it forces you to think about the separation between the domain-specific logic of the engine and the game. It makes you learn from your mistakes rather than pretend that mistakes cannot be made.
This is a nice post. But I would like to comment it with the following: You are advicing us to build a game, rather than an engine. Let’s consider a some-experienced programmer, who knows the SOLID principles and how to use use them in his code. After he writes his game, what will be left is a game loop, and a few classes like an animation model, input handling, collision detection and a few more. At least, this is how it should be. Isn’t taking those classes and putting them inside of a library sort of making an engine? An engine is a structure that keeps all needed aspects of a game in place, and helping them to communicate. From my point of view it looks like you’re not trying to tell us to forget about engines, but you’re rather giving us a short introduction on how to proceed in the engine development, while at the same time stopping script kiddies screaming around “look at me, I’m writing my own engine!”. That’s my impression on the article.
But you do make some really good points as far as I can tell. Thank you for this great article!
Yes, your impression is basically accurate: the flashy, eye-catching title of the post aside, the point I’m trying to make is that it’s usually better to evolve or grow your engine rather than attempt to design it and build it directly, in a vacuum, with no understanding of the requirements of the game you ultimately want to build with it.
It’s also worth pointing out that this was one of the earliest articles I wrote, back when I intended this site to be more of an article repository than a blog. The intention was to link this article to beginning/intermediate level programmers rather than repeat my arguments ad nauseam on forums and IRC channels. Essentially I’m saying that building good engines requires you have some experience building or working with the things those engines will be used for — beginners typically lack that. This advice is somewhat less applicable to developers who already have several completed games under their belt.
One problem with going straight to creating a game is that there aren’t a lot of people with the skills to create both the code for an engine and the non-code parts (meshes, textures, audio, story) for a particular game.
Sure, you’re speaking about content production (“meshes, textures, audio,” et cetera). This is largely distinct from the point I was trying to make here, which is about how one should approach the development of the code. It’s also been demonstrated that you can create some pretty interesting games using relatively lo-fi art assets, regardless of whether you employ a pre-existing engine or tool suite (anything from Ogre to Unity) or build the underlying technology yourself, with or without the consideration of the advice in this article.
I’m not sure that your article answers this question: Should a beginning developer use an existing engine or write their game from scratch?
That’s true; it wasn’t really my goal to answer that question, not with this piece at least. In general, I think the answer to your question is “it depends.” I generally think you should “build” (or develop in-house) what is critical to your project’s unique experience and “buy” (or outsource, et cetera) what isn’t. What that actually means for any specific project is, of course, going to depend on that project’s requirements and other goals.
One good bit of advice from Code Complete was that you should not really think or design for reuse during the main project. Focus on the deliverable (an enjoyable game) and achieving them first. Once the project is done, then go over your code and determine what could be possible candidates for reuse.
This is ridiculous. You SHOULD build an engine. All of the ‘experienced’ programmers seem to want to tell you that it is impossible and should not be done. Bullshit. You SHOULD create a very simple engine that has stuff like state management (done properly! not a switch statement!), resource management, rendering, etc because you will need that kind of stuff in every game you make. Why should you rewrite the code for every single game you try to make. Don’t reinvent the wheel, make the wheel easy to reuse – that’s common sense.
If you note, I am not advocating that one should never write an engine; rather I am advocating that one should not write an engine in isolation. I am saying that one should use games as a means of driving the requirements for ‘engine-level’ code (such as state management systems and the others that you mention). While it is certainly true that all games will require some kind of rendering code, not all games require the same kind of rendering code, the same feature set, or the same interface. Developing and understanding requirements is a critical aspect of any software development project, games included.
Great article and very good advice!
However, I do feel that engine development can be an important part of the development process for certain people. I’d like to share my experience on why I found engine development to be a crucial part of my game development process.
I’m a hobby games developer. I haven’t yet completed any games but I am nearing the completion of my first project – a relatively simple open source game written in C++ and OpenGL – which I started in 2005. The project started life with the approach that you suggest in this article; the pure intention to create a game. I didn’t pay much regard to writing reusable or generic code and I certainly didn’t think about writing an engine. I just wanted to create a game that people could enjoy. I thought it would be pretty easy to do.
So I wrote a lot of code. Things got moving pretty fast, and it wasn’t long before I had some significant functionality and a whole game world set up, built using a custom editing tool. However, as the project moved forward, progress began to wane. My motivation and enthusiasm slowly dropped and breaks from the project increased in duration and frequency, occasionally resulting in months of inactivity. I still really wanted to finish the project. Nothing was more exciting to me than the idea of people actually playing my game, but even as the game neared completion, I was unable to push myself to finish it.
The biggest drain on my motivation was when I realised that the game concept had great potential for expansion and customisation, and thought about how I could have developed it this way. The problem was, almost every class in the game had so much game-specific code and knowledge that it would be impossible to exploit this potential to any degree in the project’s current form. Sure, I could have spent a couple of months kludging the last part of the required functionality into the game and working out the remaining bugs, but deep down I knew there were better ways of doing things, and that knowledge was playing heavily on my mind. Any code I might write to finish the project would only end up being rewritten later in generic form, and knowing that was greatly depressing and demotivating.
Eventually, in early 2009, after almost half a year without any activity, I decided to take the plunge into the refactoring process. The game would be converted into reusable and flexible modules and tools. Every part of the game would be customizable and the game would even support a plug-in architecture, allowing new functionality and objects to be introduced into the game. In short, I’d end up with a nice engine, with my original game running on top as a set components, refactored and generalised from the original project code.
And now? It’s taken a little longer than expected, but the engine framework has been written and the game is almost complete, running on top of the engine. My motivation and enthusiasm for the project has never been higher, and has persisted since I began turning my project into an engine. I can’t really do justice to the difference it’s made. Development has practically become an addiction and there are no signs of slowing down. In fact, for every day that I spend writing code, I think of new and exciting possibilities for future developments (although for now I still retain a clear focus on reaching the original goal). It’s hugely motivating to look forward to a future of experimentation, expansion and customization rather than months of tedious refactoring and kludging things together. I’m honestly not sure if I would’ve ever finished the project without the engine.
I guess what I’m trying to say is that writing an engine can be very rewarding depending on the person and the type of game. There can be more to games development than banging code in one end and getting a game out of the other. I’ve seen a lot of hobby developers who write games this way, and it obviously works for some people, and that’s fine.
But for those who want their project to have a long-term lifespan, I believe that an engine is the way to go. As long as there’s an actual game to pair with the engine to define some concrete goals and keep priorities from swaying, then an engine can be well worth the effort.
In my opinion.
Don’t get too hung up on the use of particular terms (‘game’ and ‘engine’ specifically). What you’re saying isn’t really in disagreement with the point of view I’m espousing: you built a game first, and the experience you acquired during the process tempered your understanding of what you needed from your code. It helped refine your goals. That’s the important part.
I agree with you for the most part.
A small group of my friends and I are making a game, and I’m the game’s engine’s developer.
At this point some would ask “Why even develop an engine separated from game code? Shouldn’t you just simply make your code part of the game’s code and specific to it’s needs?”. The answer is very simple: the “game’s needs” are always changing, especially with the creative, not-so-much technical people as the game’s designers.
The most important thing, when you’re developing an engine, is to have a close interaction with the game’s developers because their needs should drive your development, just like you said!
BUT: Because of the always changing needs of the game, the core functionality a.k.a. the engine should be designed and implemented with special care for the ability to accommodate these changes easily.
Just my two cents. Great article btw!