A Renderer is not a Game Engine.

A renderer is a crucial portion of any game engine, but it is not the bulk of the work involved.  Many game projects used to (and some still do) start with a programmer building some cool new rendering technique that looked superior (or simply different) to every thing out there.  Following the first demo of the new engine, the artist would get excited about the potential of the engine and the race would begin.  The base of every engine is a good tool path.  The artists and designers need to have the tools to effectively create content.


For the first major game project I was part of (“Shattered Steel”) we built our own tools from scratch.  This was not the smartest thing to do.  We had a whole list of tools which all did slightly different things.  The workflow was horrible and the tools were nearly unusable due to their programmer-centric design.  To get a robot into Shattered Steel you had to: Build a Polygon in PolyEdit.  Create a texture in some paint tool (we used Corel Draw 3) (thankfully we didn’t try to build a paint program too).  Put that texture into the 100 texture array the game referenced using TexLib.  Change the mapping on the polygon using TexEdit.  Load the textured polygon into BotEdit to construct a Player robot.  Load the Bot into AnimEdit to create a four frame walk cycle animation and then go into the code and add all the rest, like weapon mount locations, pivot locations, etc.  Contrast this to Neverwinter Night where all the art tools were contained in 3DS Max, a tool the artists knew well.


Once you have a tool path, you can actually put some content in the world.  The next step is moving that content, usually in the form of a player character or simply just a camera.  This requires an input handler.  The first kick at an input handler can be pretty simple, to use the joystick, you just grab the values and munge the data till you have the inputs you want.  Later, when you want to add configuration and customization, this turns into a couple months of work.  Now you need to start worrying about collision systems.   How do we create levels and how do we stop the player from falling through the terrain/level?  This is usually an art tool and programming challenge and involves a great deal of pain and iteration.  The end result is a game world that can display art and a character (or camera) without cutting through the world.  Now we’re going to need an animation system.  Yet another tool and engine combo, with export tools to identify the content and the engine code to replay and match it to the character movement.  After you have animation working, it is time for some enemy characters.  At this point we need an AI system, a pathfinding system and a basic gameplay update loop.  Once those parts are together it is time to start adding game mechanics such as health and game states such as death.  At this point you have something that might show the first glimmers of the game you imagined when you first saw the engine run.   Once you have characters interacting in some manner, you’ll likely need some form of particle system to do weapon effects or projectiles or smoke effects or whatever your artist insist upon.  A few more programming and technical art man-months later you have a particle pipeline.


The next stage is to push the engine to see what the real world performance is going to be like.  We can put in “Gold Standard” characters, level art, particles and see where it all breaks down.  This will show us where we need to start optimizing the content and/or engine to deliver an interactive experience.  We throw some particle systems in just to increase the load and fix what is slow.


Next is probably the Audio engine, which need to interface with the game events system, so we better build that too.  Once the audio is in and the events system is working we’ll likely want to play some music too, so another bit of work goes into the music.  What about when the track ends?  how do we loop it smoothly?  Do we want combat music?  if so, how do we transition from the normal ambient track?  Once that is all solved we are probably ready to make a prototype level and pitch our title.  The next few months are a panic of putting in content, fixing bugs and dealing with the fallout of guessing wrong about performance.


If you contrast the above with the act of licensing an engine which has already shipped a title, already gone through a comprehensive bug fixing regime, already had artists learn the tools and manage to develop final shippable content. the value of an engine is obvious.  If you can add to that a community of people who are modding the game which shipped it suddenly becomes much easier to recruit new artists and designers.


So, in summary, if you are looking at a cool new renderer and thinking “This is going to be awesome”, you need to back away slowly and start listing out all the work you have to put in to match an already shipped title.  If you think it still makes sense, proceed with caution and be very aware of the costs to iterate into a shippable game.



Iteration is Everything

For my first follow up to my game development rules I’ll hit on Iteration.

I was lucky enough to be at Bioware during the development of some pretty great games.  In most cases, we were doing new titles, without pre-existing engines or workflows and as such, we did a great deal of invention.  Sounds great so far, doesn’t it?

The sad thing is, most of our inventions didn’t work out as planned, in many cases the best design turned out to be missing a tiny component called “fun”.  The solution wasn’t to come up with a new design and start over from scratch, it was often to dig into the problem and understand what was sabotaging the fun.

The key to this was rapid iteration.  we made a change, tested it and then tried again.

I remember one case specifically:  We had an encounter in Baldur’s Gate where the party met up with a small group of “Kobold Commandos” in the Nashkell Mines.  Initially, we had the AI dialed up to be quite intelligent,  they would all team up and take out the spellcaster first, then the clerics and ranged combatants before moving into melee combat.  We had also equipped them with fire arrows, which did an extra 1-6 damage on every hit.  The end result was the player’s party was usually wiped out before they had a chance to engage the commandos.  We had to go back and re-tune the arrows, the AI and the toughness of the Kobolds quite a lot before they didn’t decimate even well-prepared parties.

I always viewed the first title in a series to be a flawed creation, just about the time you had learned how to create fun gameplay and the tools were up to supporting quick iteration it was time to ship.  The sequel was a magical project, a chance to use all the hard learned lessons, the polished tools and all the great new gameplay ideas spawned from previous iteration to create the best game possible.  In my opinion, Baldur’s Gate 2 was an excellent example of this.  Even today, with Mass Effect 2 you can see the power of iteration as a game can be refined and improved immeasurably by an experienced team iterating at what they do best.