GameDevMike

On any given day, you can browse the forums at GameDev.net and see posts where people ask for help with their ‘engine’. Once upon a time, people asked for help with their ‘game’. These days, a lot of posts start out something along the lines of,

I’m making a game and I’m having some trouble with some aspect of my engine.

The problem is that ‘making a game’ and ‘my engine’ appear in the same sentence. It seems to have become an accepted fact in the GameDev.net community (and other similar communities where wannabe game developers congregate) that the first step in making a game is to make an engine. Well, that is just plain wrong.

Inevitably, when I try to point out to someone that they don’t need to make an ‘engine’ to make a game, they bring up the Infinity Engine, the Unreal Engine, the Quake Engines, and other well-known game engines that were originally developed to support a particular game but were also licensed out to other game developers, or used in house to develop other games. There’s a fatal flaw in their logic, though.

Look at the Unreal Engine, for example. The guys at Epic didn’t say, ‘Let’s make a game, but first we need to make an engine.’ For Epic, it was the other way around, ‘Let’s make a game engine that can support all of our future titles and that we can license out for ungodly amounts of money’. With the Quake games, there really isn’t much of an ‘engine’ there at all. All of the code in the Quake engines was created as part of the game code. Download any of the open source Quake engines and you’ll see that the game code is somewhat coupled to the ‘engine’ code. What makes the Quake ‘engines’ is the modular structure. When you license one of them, you get the game code along with the renderer, input management, and everything else. You can then rip out the game code and customize the rest to suit your own game. But it also means pulling some Quake-specific stuff out of the network subsystem, for example.

You have to decide from the very beginning what it is you want to create: a game, or a game engine. If it’s the former, then the word ‘engine’ shouldn’t even be in your vocabulary during the development process. If you want to make a game, then make a game. Don’t waste your time trying to come up with the uber-perfect-killer-OOP game engine design of the century. Do what the guys at id did, make your game modular enough that you can reuse most of the code base for your next game.

You may fail to see how just modularizing your game can be better than actually creating a well structured game engine, but the difference is tremendous. Your state of mind during development will have a huge impact on how you approach every aspect of the project, from design to implementation. If you are designing an ‘engine’, you are going to put a whole lot of attention on the design of every subsystem. Your goal will be to create something that can work with not only the current game but with future games as well. You’ll be spending a great deal of time, energy and effort that could be directed to the game design instead.

When your goal is to create an engine that other people can use, then have at it. But when you just want to make games, and this is particularly important for solo developers or small teams, you are truly wasting your time by focusing on an ‘engine’. Select your target platform(s), your target API(s), and start coding your game. As long as you keep your code modular and keep the coupling between modules as loose as you can, then you’ll not only complete your game more quickly than you would have by developing an engine, you’ll also have a great deal of reusable code at the end of development. What is an engine, if not reusable code? It’s the KISS principle at work. Focus on what’s important to meeting your end goals and you will be much more successful than you would be by getting sidetracked.

Technorati Tags: game engines, game programming, game design