Manager In A Strange Land: Reuse and Replace

Editor's Note: This is the last weekly installment of Jamie Fristrom's "Manager In A Strange Land" column. Jamie is cooking up some more columns right now however, which will be published on the site later this Spring. Stay tuned...

Rookie coders usually can't wait to throw out the engine they're forced to work with and start over on a new engine, this time "doing it right." I know, because I've been that rookie coder. After Magic Candle IV, I talked Mindcraft into letting me reinvent their role-playing engine for Gryphon Masters, a game you won't be able to look up on the web, because the company went under before the project did. But the project was well on its way to failure. Much later, after spending two years with the Die By The Sword codebase and feeling there wasn't a single line of code in there worth keeping, we started from scratch with Draconus and went six months over, and for some reason when we were done everybody still hated the codebase. (A lot of them never saw the Die By The Sword codebase, though. I tell them they're lucky.)

At this point I had learned my lesson but Treyarch had not; a separate project that I wasn't involved in, given a choice between re-using an engine (granted, it was written by the Japanese) and starting over decided to start over. They used Treyarch's renderer, but what they did not have was a toolset for making levels.

It is because of that project that I write this week's column. For the most part, it seems like the game industry has gotten wise, and few developers make the mistake of trying to write their own engine from scratch anymore. But still, there are some groups that don't listen to the lessons of history and go down the path of destruction.

It is possible to write an engine from scratch and hit your ship date? Both MechAssault and Kinetica managed to achieve this. But it's very rare.

SWAT3 Close Quarters Battle built a new engine and still managed to ship in eighteen months, a feat I would normally consider impossible. Their secret? They used WorldCraft as their level editor. Their designers started prototyping from day one with Quake, and were able to start building full levels before the new engine was even finished.

If we look at the list of projects that took eighteen months or less (see my previous column), we see there's a lot of reuse going on. Unreal Tournament used Unreal, Rogue Squadron 2 used Rogue Squadron, Heretic 2 used Quake, System Shock II used Thief, Dark Age of Camelot used Spellbinder, Spider-Man used Draconus, and Ratchet & Clank used at least some of Jak & Daxter.

The sad thing about reusing your game engine, or using someone else's engine, is it doesn't give you as much of an advantage as you might hope. You'd think it would turn a three year project into an eighteen month one, but in my experience it really only saves about six months. (Even though Half-Life used the Quake engine, Valve still took three years to develop the game.) However, a big benefit of this time savings is that your designers can begin making levels much earlier in the development process. That's your critical path. By reusing an engine, your designers can begin prototyping levels immediately, even though those levels won't have all the features that you envision for the final project. You've leveled six months off your schedule. The fact that you're using an engine that two or more years have gone into doesn't seem to matter; you don't get to save those two years. And working with the engine brings its own price: You continually feel painted into a corner. You'll find yourself saying things like, "If only the engine was designed from the start for network play!" and "If only the engine was designed from the start for a full-state save game!" And so on.

Still, who wouldn't want to shave six months off their development budget? We were burned so badly by starting over that even if I had a three-year project to do, I would not start over from scratch. I would use the extra time to clean up our current code base as much as possible, starting over with only the most heinous modules and the modules that couldn't handle new requirements.

Also, these days, the timelines for original engines such as Doom 3, Half-Life 2, and Duke Nukem Forever, are stretching into three, four, and five years. If you want your game to be competitive, that's what you're up against.

There's two paths you can take when reusing code. You can take your old engine for your old game and dive in and start retrofitting it for your new game. This makes developers unhappy too, knowing that there's a lot of cruft and dead, legacy code sitting in the codebase, confusing people. They would rather start a new project and migrate components over from the previous project; the renderer, the toolset, the animation system. The goal here is to get the reuse without the cruft. This method may be workable but it is definitely safer to just retrofit your old engine. This is how Neversoft turned Apocalypse into Tony Hawk's Pro Skater, and how Treyarch turned Max Steel into Spider-Man. With the retrofit-your-engine model, you are in a safe zone where you're almost guaranteed to hit your ship date, because you've got a working game from day one.

One side note: When using someone else's engine or components, make sure that you have source. Treyarch used EAGL when we were working on Triple Play. That was a different team from mine. This was shortly after EAGL was ported to the PS2, still quite buggy, and EA would not let us see the source code. It was a miserable, harrowing experience for those involved.

So how do you keep your engine fresh, competitive, and up-to-date if all you're doing is re-using? Because you replace components, one component at a time. You'll probably replace the renderer almost every project. Other systems will get replaced as they cause you more headaches, like the AI and animation system. All the systems will cause you a few headaches; you replace the systems that cause the most. When replacement is necessary it is done by teams working in isolation on separate branches -- or in separate projects entirely -- so people working on the mainline can still work.

Still, there sometimes comes a time in an engine's life where it is no longer useful to keep around due to changing technology or changing needs. An engine based predominantly on assembly language should probably be replaced by a C or C++ one. You couldn't make The Sims with the Quake engine, or vice versa. An engine that doesn't have the infrastructure for multiplayer features might need to be replaced by one that does. But how to tell when the time to start over comes, and how to get the funding for it, is a mystery to me. And I don't see why a game engine can't be like Unix; a system that continually gets improved over time, for decades, but still manages to hold its own against competitors.

______________________________________________________