Lesson: Do build a game, or several games, while building your engine and tools

Have you seen people boasting about their awesome-tacular engines with the bestest-of-the-best rendering, physics, and networking yet have no game to show for it? Have you tried using said much-hyped engine to build a real game? You’ll quickly find that just making a game involves a great deal of work that ends up having very little to do with the "cool" systems, like Graphics, Physics or Networking. How do your game objects interact? How do you set properties, like Health, Speed, etc? What about points? How do your game objects interact with other systems?

By developing a game alongside your engine, you are forcing yourself to use all of the pieces of your engine together, for a single purpose. And let’s face it; game engines are large and unwieldy – with way too many systems and subsystems! How can you possibly know they all work together without having something to show for it? Writing a game is entirely different from writing an engine and I argue that a game engine without a game is nothing more than a tech demo. Now, there’s nothing wrong with writing a tech demo! Just be sure not to mistake a tech demo for a game engine, until a game has been made out of it.

In addition to building a game alongside your engine, I urge you to write several games or applications alongside the engine. What does that accomplish? It will force you to think about how your engine code is shared amongst different games, without stomping on each other. So, for example, you'll implement bump mapping for use by Game 1, and now Game 2 will refuse to render. It's up to you to figure out how change the engine such that both will work. It's very difficult, and time consuming, but very beneficial and ultimately invaluable in building up your engine to be a generic engine.

Case: During my engine development, I built several small "games" to test the engine: One involving a three-wheeled buggy racing around a track; one involving a cannon shooting big ol' cannon balls around planets; my tank AI game; and a 2D gear-themed adventure thingy. Additionally, I wrote several previewers and test applications, all sharing the same engine. Even my editor runs on my game engine. Since each project / test app / game / etc runs nicely with the same engine, it proves (to me at least) the versatility, robustness and flexibility of my engine. It’s a proud moment to see all that come together, let me tell ya!

A another game made with the game engine

Lesson: Know and identify throwaway code

Not all your code needs to be perfect. Not every line needs to be a shining beacon of technical excellence. You'll never finish anything. That doesn't mean you have license to write poor code all the time either. It just means that you need to be aware of the times when you write "subpar" code, why you're doing it, and what you will do about it later on.

Part of this is also knowing the consequences of writing poor code. If you write poor code, and forget about it, you'll pay for it (often, dearly). There are a number of times where I'll track down a bug only to find throwaway code I wrote months earlier and promptly forgot about.

A good example of throwaway code is to have a temporary stub-system in place to get another (dependant) system working. Let’s say you’re working on a making a particle system, but nothing to render the particles yet. No matter, write some stubs and draw little cubes in the world where your particles are meant to be. It’s dirty, hacky, and potentially spaghetti .. but it helps you get your particle system done, right? When the particle system is complete, go back and rework the rendering so that that, too, is correct. It's kinda like duct-tape: excellent in the short term in order to reach larger goals, but remember to go back and do it right!

Case: When I wrote my GUI system, I wanted to test button presses and such but my input system wasn't created yet. So, instead of shifting focus and building the world's-bestest-input-layer, I hacked something together in 30 minutes that would do the job, and continued fleshing out the GUI system as needed. And by hack I mean hacked. I directly polled DirectInput from within the GUI manager and fed it straight to the buttons, which in turn analyzed the data and acted accordingly. No abstraction, no flexibility, nothing. But it got my GUI button input handling working rather nicely. When the GUI was where I wanted it to be, I went back in and reworked the input without impacting the GUI very much. So, I wrote some throwaway code, achieved a larger goal, went back to fix said throwaway code when I could apply full focus.

Case: Now here’s where forgetting about throwaway code bit me in the hiney: In order to get 3D mesh collision working, I had to make a really nasty hack that tightly coupled my physics engine and my rendering engine. It was a nasty hack, but it helped me achieve my goal of getting trimesh collision functional. Unfortunately, I completely forgot about the hack. Months later I changed my vertex format in the renderer, and my physics broke completely! I could not figure it out, and continued to not figure it for two days! I finally tracked it down to the hack I put in, and even discovered a big ol’ comment telling me I had to fix it or I’ll see some nasty bugs later!

Lesson: Tools. Love them. Make them. Love making them

Programmers are lazy. Programmers like to take shortcuts whenever they (we) can, because we have a goal to achieve and doggonnit we’re gonna get there! So, who needs a fancy tool if you can just jot down some settings in a .cfg file? Psh!

Uhm .. yeah .. so that’s terrible. Let’s get out of that habit, shall we?

Tools are awesome, and the more you write, the more you'll love them. Do develop an editor that lets you easily create levels, game objects, apply textures, write scripts, preview your game, etc. It’s a tremendous amount of up-front work, but when you’re done you can create new games much faster than before. Additionally, when you bring more people onto your project they’ll be able to hit the ground running much faster, instead of relying on you to teach them how each individual text file needs to be hand-tweaked to make anything work.

Case: Once my engine had something up and running I built an editor to create levels, game objects, physics-rigs, effects, and so on. It has allowed me to create my game assets with little frustration and has saved a ton of time in just initial setup. My editor has a long way to go, and it's far from either done or perfect, but it has saved me so much time it's insane.

So yeah - don't skimp on the tools. Besides, do you really want to end up maintaining what ends up being hundreds of unique text files? :)

A game editor tool for the "tAInk" game

Lesson: Use Version Control, even if you’re the only developer

So you’re the only person working on your game, you know where everything is, and you don’t have anyone stomping on your toes while you’re working. You don’t need version control, do you?

Well, let me ask you this – have you ever made a large amount of changes to your game, radically changing how everything works, only to realize toward the end that you’ve made a big mistake and you have no idea how to recover from it? Or, alternatively, you’ve introduced a nasty bug – but cannot remember the changes you’ve made to cause it? Or your IDE crashes and you lose half your code? If any of this has not happened to you, don’t worry, it will and you will cry long tears knowing you have no historical backups of your code!

Version Control allows you to keep incremental backups of your work just in case you need to recover old source code, or see exactly what it is you changed, or pinpoint when some bug got introduced. It also serves as a nice backup in case you somehow lose all your work in a hard drive crash or something similar.

Case: When I first started my engine, I was going to work on it with a friend of mine. We set up a subversion server and went at it. He’s moved on though, but I never let go of the subversion server. I found it immensely useful to double-check my changes, revert to backups, and so on. A month or two ago I lost everything through a hard drive crash (“Tick of Death” anyone?). If I had not had all my work on the subversion server, I would have lost it all. Can you imagine? Five years worth of engine work – gone. Yikes! Well, fortunately for me all I had to do was reinstall the subversion client on my new hard drive, sync up, and all my work was right there! I only lost whatever work I did not check in before the crash.

That concludes my short-ish list of lessons I picked up through the past couple of years of game engine development. Unfortunately I had to learn many of these lessons on my own, sometimes painfully so. I hope that they are helpful to you and will prevent you from making the same mistakes I have, or rather make them much less painfully!