Top-Down

Last night I spent a lot of time thinking, on a more philosophical level, about how to approach game design. Interestingly, I came to a pretty big revelation: I've been doing it all wrong. After a few hours of considering my previous technique, I think I've figured out exactly what it boils down to.  The key is top-down vs. bottom-up development. To start, I'll briefly define what I mean by each.

Bottom-Up

You start by developing small subsystems, fleshing them out until they work really well by themselves. In this way, you make everything look beautiful even out of context. For example, you might work on a GUI system, making it look beautiful before moving on to something else. But the GUI system is developed and tested as an isolated component. Maybe you decide to work on trees, and, again, you develop and test tree generation algorithms as a standalone component. In this way, you continue to tackle and perfect each subsystem of the game until all subsystems are complete.

Top-Down

You start with the "big picture," using placeholders for each subsystem, focusing instead on tying the subsystems together into a coherent game. For example, you may use very rough text and simple boxes for your interface, and perhaps you use cylinders for trees, boxes for ships, and spheres for planets - all without texture. But the important thing is that you explore how the interface lets you interact with the world, how trees are distributed over planets, how ships land on planets, and so on - you are not developing the subsystems in isolation. Gradually, you refine each subsystem until it seems good enough in context. Your planets get texture, then dynamic tessellation, and finally an atmosphere.

If you think about it for a while, I think you'll agree that it's a very real distinction.  In some sense, it's comparable to the difference between a progressive (interlaced) and non-progressive image being loaded in your browser.  In the first case (progressive/top-down), you can see the entire image almost immediately, but it is very blurry, and gradually gets more detailed.  In the latter case (non-progressive/bottom-up), you can see individual pixels filling in row after row at full precision, but probably can't tell what the entire image is until a good many rows are loaded; even then, the full image is only revealed at the very end.

Now, historically, I have always approached things in the bottom-up fashion. If you look at the images posted on this blog, I think it's quite clear: almost every image I post highlights a single element - a terrain, a tree, a texture, etc.

Why it Matters

Here's what I realized last night: bottom-up development is wrong. At least for serious game projects involving only one developer. I can't generalize my conclusion to large companies, but I do feel that it should apply to independent gamedevs like myself. Here are some reasons that support my claim:

  • Subsystems are developed out of context (a subsystem working well in isolation does not guarantee that it will work well as part of the final product)
  • Gameplay and game subsystem interactions are de-emphasized
  • Easy to lose sight of the "big picture," since it is not visible until the very end; by extension, easy to lose focus

I think these are all rather self-evident.  If you've developed in a bottom-up fashion, you can probably think of personal examples of each problem occurring in development (I know I can).  Perhaps the biggest problem with bottom-up development, in my experience, is the third item.  Focusing on a single element, it's easy to forget the grandeur of the project as a whole.  As a game developer, you come up with a fantastic game idea - something that really inspires you - and then you work to make it a reality.  But working for a week on a GUI system can make you forget all of the inspiration and beauty of the original idea, causing a loss of motivation and, ultimately, of development efficiency.

On the other hand, in top-down development, it's easy to keep a handle on the big picture, as it's really the focus of this flavor of development.  In that sense, it is easier to always remember the beauty of the idea, because it's right in front of you (albeit, in a coarse form).

Anyway, I don't usually post this kind of philosophical garbage, but it hit me so strongly yesterday that I felt the need to write about it, if only so that my future self will be able to remember.

Here's to a bright future of working down rather than up!

Results: Grand Prize!

Well, that was a productive quarter...managed to get grand prize at the 2012 Stanford Rendering Competition! Here was the final render:

The rendering depicts a spaceship emerging from a thick nebula and asteroid field. A sun-like star lights the nebula from behind.

In summary, the primary technical challenge of the rendering was the nebula. The nebula is rendered using full volumetric path tracing, including multiple scattering and wavelength-dependent scattering. This is probably the first time I've ever tried to do something like this without using hacks. I ended up writing a renderer in CUDA specifically for this purpose, so the final render was rather fast considering the complexity of the scene. I was really pleased with the results!

As for the scene geometry, it's all procedural, written in a procedural modeling language that I developed specifically for the project. The language helped me quickly prototype geometric ideas, and was invaluable in exploring the (procedural) possibilities! I'll definitely talk more about the language in time, and I suspect that it will be making frequent appearances in my real-time work.

In the coming days, I'll post some details on the project (and date the posts appropriately), so as to fill in that void of postless time over the past two months!