Developing Imperfect Software: The Movie

Preview on Laptop
As promised, I have hacked together a movie of the slides of my presentation at GDC 2012. So now you can hear me drone on about data/code dependencies, effective crash reports, and Insomniac’s crash proof tools architecture.

The Blurb

In game software development, we face a unique challenge: the program that we are developing is itself an important tool in our production pipeline, even in its unfinished state. Our artists and designers rely on it to see their work. We should expect it to be broken, a good deal of the time. How we deal with the daily imperfections of this vital tool is an important factor in successful development.

In this talk I discuss three different approaches to making this expected breakage less of an issue:

  1. reducing data/code dependencies in a game data friendly manner
  2. making assertion failures less intrusive and more effective, and
  3. using a client/server architecture to prevent loss of work when our custom productivity tools crash

Related article: Assertions in Game Development

Annotated slides (in Keynote format) available from the Downloads Page.

Developing Imperfect Software: The Movie

Developing Imperfect Software GDC 2012 from Ron Pieket on Vimeo.

8 comments » Write a comment

  1. Really good presentation Ron, and very polished looking slides.

    The first time I came across the “structured binary” approach was in RAD game tool’s granny about 10 years ago. They used to store the schema of their data structures in their binary files. Each executable which consumed the data would then hold a copy of the schema which matched up with the run-time data structures, facilitating the automatic conversion if necessary.

    FWIW, I think your scheme is an absolutely great way to go. The typical day to day loading will generally take the fast path (all binary data is in the desired layout) and then only drop back to the slow path when required to maintain compatibility. It even makes it trivial to preprocess data from one version to another automatically, as well as any endian swapping you may want to do for different platforms. For final disk builds it might be beneficial to strip out all of the schema data to save space since it’s not needed anymore. On the other hand, having the schema information there might make patching a little easier.

    Nice work!

  2. Pingback: A Client/Server Tools Architecture | It Should Just Work!™

  3. “Blame upcasting” –that cracks me up. Excellent presentation… really, I mean it.

    Yes the structured binary is similar to granny’s, but where that data description/schema comes from is very interesting. I’ve been mulling this over recently, trying to find an unintrusive approach to “mark up” a struct, but C++ doesn’t lend itself to this. DDL was unknown to me until now; I will check it out.

    One of the nice things about a self-descriptive binary is that a generic data viewer can be written to browse the data, which beats the crap out of staring at a hex dump. It also works just as well for “liquid” data layouts such as vertex formats and material properties that don’t necessarily map to static code structures–most engines will have something like this already for those uses, but narrowly applied and even duplicated in various unrelated systems.

    The described tool architecture has me salivating and also feeling ashamed and inadequate. Really inspiring.

    I’m so glad you are blogging now… so I can steal your ideas. Cheers

    • Great to hear from you, Jay. And thank you. We’ve been using DDL at Insomniac Games for about two years now. We are planning to release a stand-alone version of DDL to the public. In fact a first version of the parser is already on GitHub. I’ve been warned that it may be a little rough at this point. If you are willing to test it for us, contact me and I’ll get you in touch with the authors.

      Structured Binary will also be released, but that technology is still in an early stage, undergoing changes, and not quite ready. I’ll write a post about it when it solidifies.


  4. Pingback: Back from GDC 2012 | It Should Just Work!™

  5. Wow, a very interesting presentation!

    When your various editor applications send data to the Luna server, do they serialize the entire document? or is a single document maintained as a series of individual records?

Leave a Reply