Musings on Game Engine Design


with 5 comments

The things that interest me about working in the game industry, I’ve realized, aren’t the things they write books about.  They write books about math and APIs and tools.  If you want to know how to handle collision between a sphere and an ABB, you can look that up.  Or if you want to know all about the latest version of DirectX, you can buy a big paperback with a CD tucked into it, and it’ll tell you everything you need to know.  Or if you want to know how to use 3D Studio Max, you can get a dozen books on that.  But reading every book on 3D Studio Max won’t make you an artist, and reading every game development book out there won’t make you a software engineer.

There [Image]aren’t any books that’ll tell you the best way to structure your object hierarchy.  There aren’t any books that’ll tell you whether physics and rendering should share one representation of an object.  There aren’t books to tell you the best way to map a script call to an object, or how to keep track of object state in a networked game or the myriad of other tasks that pull an engine in a million different directions, and, if you aren’t careful, pull it quite to pieces.

I really wish that there were such a book, because I know the answers to very few of those questions.  Many more answers are out there, of course, passed along in the folk wisdom of the game development community.  Some show up in Game Developer magazine.  Some are discussed on the GD Algorithms list or SWEng-GameDev.  Some people share their answers at the Game Developers Conference.

GameArchitect is my place to share my answers.  It’s also my place to share my questions, since I have many more of those.  But mostly, it’s my place to share the things in between, thoughts on their way to becoming answers.  It’s here to give me a reason to write things down and think things out, lest I forget them.  And if anything I write helps out some other struggling game programmer somewhere, that’s wonderful too.

Written by Kyle

March 9th, 2008 at 5:42 pm

Posted in

5 Responses to 'About'

Subscribe to comments with RSS or TrackBack to 'About'.

  1. I stumbled upon this website while looking for information that might help me lay out the architecture for my first collaborative game effort, a simple Java platformer I’m working on with a few friends. I was instantly drawn in by the articles contained, clearly written by industry veterans laying bare the nuts and bolts of cutting-edge AAA game programming, with enough Wikipedia links thrown in to let me know it isn’t an exclusive club. So here I am, posing a question to this community at 3AM.

    As I’ve started to educate myself on the workings of the industry in preparation for my (hopeful) eventual transition into it, I’ve been dismayed to find that many of the engineering practices I’m currently being taught are reversed or ignored completely in current practice. One developer called recursive functions “a neat gimmick you learn in college” which require far more call overhead than they’re worth for common implementation, and now I see your article on Aggregation over Inheritance telling me that Inheritance is soooo 90’s. I don’t want to be obsolete before I even hit the market!

    So my open question to you, Kyle, and any other experienced developers who may have an opinion, is this: should I spend my time NOW, as a junior in college looking for some game development experience that will propel me into a career, perusing sites like this one, looking for the bleeding-edge tools and tricks of the trade so I can go into interviews armed with apropos knowledge, but few demonstration pieces? Or should I try to iterate on very simple things I know I can handle without too much hassle, and go from there to build a large portfolio of experience? In concrete terms, as I’m trying to lay out the structure for my current project, I have the simultaneous urges to make the engine thread-based (a concept I’ve never worked with before) and to push my knowledge further while preparing myself for a multiprocessor environment, but also to put most everything in a very simple rendering loop, so I have few surprises and know I can work on it easily, with perhaps a greater chance of success.

    So… high-concept or high-polish, on several levels? A novice and wannabe wants to know. Thanks for your patience and help.


    8 Apr 09 at 12:15 am

  2. […] Kyle Wilson and I were laying out the design for Day 1’s Despair Engine, low-level support for reflection […]

  3. Someone’s never going to be a professional programmer if he doesn’t understand how pointers and recursive functions work. And to do general aggregation, you still have to have your aggregates inherit from some common base class. Inheritance is useful, it’s just not the solution to all problems.

    Your mileage may vary, but I’m more swayed by the quality of someone’s code than by the flashiness of his demo. It’s better to do few things cleanly and well than to try to do everything at once.


    7 May 09 at 7:19 pm

  4. […] certainly been the case with every game and every engine I’ve worked on.  My good friend Kyle, who has for years been tracking all sorts of wonderful statistics about the development of Despair […]

  5. This blog is great, exactly what I wanted to hear as a student about to refactor an engine to be component-based. I know this hasn’t been updated in years, but I can’t find contact info anywhere. Is there some way to get in touch with Kyle to ask a couple questions?


    15 Dec 11 at 12:32 pm

Leave a Reply