Blogus Arbitrarius

I often hear people say they want to write a game or game engine. At least half of these are people who want to write MMOGs. Being a member of that group of people myself, it would be quite hypocritical of me to immediately brush everyone off as incapable, while continuing to putter along on the Invasion engine, all the while thinking that Not So Random is the only group capable of building a game engine without loads of funding and a full development team.

Even if it were true, and we were really that exceptional, I wouldn’t want to be discouraging. I enjoy programming, and even the little successes make the whole project worth it. Discouraging a person to the point of giving up would rob them of that joy.

Even so, I am a realist. The current state of the Invasion engine is only after almost five years of attempts and failures at various large projects like this, and a year and a half and two failed tries at the engine itself. That all adds up to many hundreds of thousands of scrapped lines of code.

My point here is that if you’re serious about building a game or game engine, expect to have to try it over and over again before you have anything you’re happy with. If, however, you don’t want to scrap so much work, perhaps these tips can steer you in the right direction. Games and game engines are, after all, really huge projects. It’s easy to get lost.

1. Plan. If you can’t explain, in detail, how your game engine will (or won’t) accomplish everything a game could possibly want to do, you haven’t planned enough. And I don’t just mean how you’re going to arrange meshes or particles or any of that. I mean specifically, in detail, what aspects of the code will interact with what other aspects.
2. Plan. Seriously. If you think you’ve planned enough, you haven’t.
3. Plan some more. The Invasion Alpha engine took a week of sitting down for perhaps 3 or 4 hours per night and diagramming every single class within the system, and it failed, and the beta version, albeit closer, also failed.
4. Plan. Yes, it is this important. Because everything about a game engine works so intimately with every other piece, the smallest unexpected hitch has a tendency to compound itself into a much bigger problem. It is critical that you understand exactly what components will exist, and how every component will work before you start building them.
5. Don’t reinvent the wheel. There are a lot of libraries and wrappers out there that make things a whole heck of a lot easier to get stuff done. Ogre 3D, for example, is a fantastic graphics wrapper, Lua is a very quick and lightweight scripting engine which is tremendously easy to embed in your application, and Alhem’s Sockets makes networking amazingly easy. The less your engine is responsible for, the more manageable it will be.
6. Use C/C++. If you’re allergic to C, sit yourself down with a mug of tea and start learning assembly. Games, and especially game engines, need to be blazing fast, and that means using a language that doesn’t have the overhead of garbage collection or closures or anything like that. And to be honest, with the right planning you don’t need any of that stuff anyway.
7. Make it cross-platform. If you rely on #include <Windows.h> then you’re doing something wrong. Really, writing cross-platform C code isn’t as difficult as it used to be. As long as your dependencies are cross platform (which Ogre and Alhem both are) your code can remain cross platform and make a lot of people very happy.
8. Know your architecture. This is especially true if you’re taking my previous suggestion. Blender had an issue some time ago where they forgot that some data types on 64 bit processors are twice the size of their 32 bit counterparts, and so saving files wouldn’t work between the systems. Furthermore, if you’re compiling for big endian, you should be aware that the byte order is reversed. This can lead to some funky issues with networking code.
9. Understand what you’re using. Multi-inheritance is a big one in this category. During the development of the Invasion Beta engine, Alex and I spent an entire day trying to figure out the source of a segfault. The issue came from a particular quirk of how the compiler places variables in memory. The end result was that we were inadvertently typecasting our variable to the wrong type. These are things that they don’t teach in classes. If you don’t feel like learning about how exactly multi-inheritance works, and what it’s drawbacks are, follow your professor’s advice and don’t use it.

Development of games and game engines is tremendously satisfying and equally difficult. I don’t mean to be discouraging (truly, I would like to see more independent games out there) but it really is that hard. What’s more, it can at times be depressing when you show your work to someone, trying to explain your ten thousand lines of engine scaffolding, and they simply squint at the spinning, untextured cube on your screen. It’s not work people can appreciate until you’re done. Just keep trucking forward, and take a break when you need it.

Happy coding.
~Sean

Tags: Games, Programming

This entry was posted on Thursday, April 16th, 2009 at 09:24 by Sean Edwards and is filed under Game Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.