Quality = numRevisions / iterationSpeed;

One problem I’ve always had at my current job is trying to get work done on the poor hardware made available to us. On a regular basis I encounter:

  • 10 seconds lockups to open a new file
  • Compiler crashes
  • 15 seconds to open firefox
  • 1 FPS in debug
  • 10-30 seconds to bring up the visual assist file index
  • 5-12 minute compiles, even with Incredibuild
  • Something like 50 KBPS on our shared internet connection

The problem is twofold: First, you lose the time actually spent waiting. Second, because it’s so distracting you may lose your train of thought and go read The Onion instead. Because it takes so much longer to make changes, you have fewer iterations of the code total. This discourages experimentation, reducing the final quality of the code.

Lets look at the same problem for artists. You ever notice how old games are often more fun than their modern equivalents, despite the old games having a minuscule fraction of the budget of their modern counterparts. I believe this is because of the large iteration time involved with changing assets and code in modern games.

Suppose in my 3D level I have a small town. It turns out the town is the funnest part of the level, with places to hide and more strategy than the surrounding forest. I want to add 4 more towns. In a modern 3D game this is a HUGE amount of work. Man-months by several level designers. In old games, it may be as simple as clicking on the town tile, setting a couple of properties, and trying it out. Suppose it turns out now that 5 towns total wasn’t fun – we should have had 2 instead. Again, with the old game it’s a 5 minute job to adjust the map. In the new game this takes several weeks (have to place trees in place of the old town). Plus, due to the sunk cost fallacy, we may leave the towns in anyway just because it was so much work to put it in in the first place. Maybe rather than removing them the artists just tweak them a bit.

This is why in shooters you don’t see fun levels like in the original Doom anymore. In the original editor I could move a wall in a couple of minutes. In a modern level, this takes 10 times as long.

Fortunately, I think there are ways to mitigate this problem.

First, there is absolutely no excuse for not always working on top-of-the-line equipment. Suppose an employee loses 10 minutes a day due to hardware. This is roughly 40 hours a year, or one week’s pay. At least at my wage this is the cost of the absolute best computer on the market. I currently lose about 2 hours a day due to hardware.

Artists should create levels using only the default Maya objects. Trees should be pillars. Mountains should be triangles. Walls should be cubes. The game should be playable and fun before ever creating a detailed asset. Some final work can be done of course. For example, the character’s model is far less likely to change than a level layout. So it’s not like you have idle artists. Just keep the things that will probably change flexible.

Gameplay programmers should either have a way to very quickly change and link code (such as linking with DLLs) or else use debuggable scripts reloadable at runtime. If using code, it is critical to have a mechanism to change run-time values at run-time, such as debug command console.

Anyway, as I’m soon going into business for myself I’m going to put these ideas into practice.

Leave a Reply