Musings On Game Engine Structure and Design



What It's All About

Who Is This Guy?

The List

Complete Archive


RSS Feed





By Kyle Wilson
Wednesday, July 10, 2002

I've been thinking lately that the game industry is in the middle of a paradigm shift.  Through the eighties and early nineties, good game engine development was about algorithmic innovation.  Now, and increasingly over the coming years, good engine development is about structural innovation.

Algorithmic innovation is important when games are small and hardware is slow.  When things are small and slow, the right spatial partitioning algorithm or the right triangle rasterizer can make the difference between a game that's fun and a game that's not, or the difference between a game that's feasible and a game that can't be made at all.

Over time, though, computers get faster.  Abstraction layers like DirectX, Glide, and OpenGL arise and settle into standards.  Tight low-level rasterizers and hardware tricks become less important.  At the same time, it becomes harder to create entirely new effects; programmers have to write code that works on varied platforms through a standard API.  (I hope you'll forgive me if most of my examples are graphics-related.  It's because I'm most familiar with graphics, and because rendering  is the most important part of a game engine, as measured by time spent -- most games spend 75% or more of their main loop time rendering.)

These developments have a homogenizing effect.  I hear laments in the game industry still that since the advent of 3D hardware, all games look alike.  I'm sure that as physics and AI middleware become standard, we'll also see games that feel alike and think alike.  But we also have the power now to create worlds far vaster in scope than those made ten years ago.  The important space for innovation now is in the creation and management of game data.  Techniques for shadow casting and reflection and environment mapping are all well-understood these days.  But there are new black arts in game programming as poorly understood as high-end 3D graphics was ten years ago.  How do you structure an efficient data-creation pipeline?  How to you design game objects for flexibility?  What's the best interface for tweaking parameters on ten thousand game objects?

The games of the future are games like Dungeon Siege, Shenmue, Deus Ex, Age of Mythology, Neverwinter Nights, or Grand Theft Auto.  These are games where the game engine itself, whether licensed or written in-house, is just the beginning, and the real effort of creating the game is creating the data that drives it.  The game engine is, in a sense, an interpreter for a higher-level language that allows designers to express themselves at a high level of abstraction.  And our job, as software engineers in the game industry, is to figure out the easiest language for the designers to use, and to write the compilers and editors and debuggers that let them use it.

I'm Kyle Wilson.  I've worked in the game industry since I got out of grad school in 1997.  Any opinions expressed herein are in no way representative of those of my employers.