Design vs. implementation

For those wondering what what this job of mine is, that chews up all my (previously) free time: I get paid nothing-an-hour to tinker around with a Kinect IR camera using Libfreenect, OpenNI (with Sensor and NITE), and uinput. Can you guess what I’m building?

Yin and Yang

A while back though David Rosen, of Wolfire fame, wrote a blog post about his two favourite Game Development books: “Rules of Play” and “Game Engine Architecture”. I was lucky enough to come across both of these books while I was in Paris, their respective owners were nice enough to lend them to me, and Easyjet was nice enough not to fine me for going over the weight limit.

What’s interesting is the stark contrast between the two. Where Rules of Play begins by bemoaning the lack of novelty in the game’s industry:

For a while it seemed that every other title was a fresh attempt to answer the question “What can you do with a computer?” Compare that with the current crop of computer games, the majority of which seem to be addressing the question “What can you do while controlling an avatar that is moving through a simulated three-dimensional space?”

Game Engine Architecture jumps right into defining the various canonical “genres” and their specific technical requirements, as though these are the only kinds of games that ever have and ever will exist. I also noted that, whereas a good third of the book is concerned primarily with 3D graphics programming, a single short paragraph is dedicated to “High-level Game flow”. All it really says is:

Would you kindly use a DFA.

For this reason I suppose it’s not a particularly ambitious or creative book. It doesn’t rock the boat, it doesn’t rattle the cage, and the author has a bad habit of name-dropping and using non-words like “authored” and “architected” (shudder). That said it’s sober and lucid and very instructive. I’d recommend it to any and all game-programmers, even those who have no interest at all in 3D graphics programming (though you will be losing that third of the book).

Rules of Play, meanwhile, has scores of introductions and forewords to chew through before you get to the actual point, as though the authors are desperate to justify themselves. This self-conciousness continues throughout the body of the text: it is written in a very vague manner whereby the same word can be defined, say, both as the means to an end and as the end itself:

This is an interesting tactic that drives people in science nuts: in science, definitions are fundamental tools for building theories and making explanations. To a scientist, it appears that the authors want it both ways: the apparent rigor of a definitional approach, but without the commitment. – Amazon Review

That said I still think it’s well worth a look, and for the remainder of this post I’ll try to explain why…

 

“Ideas man”

What’s an “ideas man”? Good question:

I’ve always fancied myself as a game-designer, or rather always wanted to be one (when I grow up). Course, I’ve also always heard that the industry has no place for specialised “ideas men” (at least not straight out of university) so opted for a more versatile Informatics degree instead. It was only at the IGDA in Verona (January 2011) that I started to wonder whether there was more to design than I’d been doing for my previous projects: Federico Fasce, now the elected head of Italy’s IGDA chapter, gave an interesting talk about his process. This got me wondering, but it wasn’t until the recent Art Game Weekend in Paris that this line of thought finally came to a head. I was able to have a long discussion Brice Roy, game design lecturer and game-designer for One Life Remains: a loose collective of six indie game developers. The first question all this brought to mind was:

Does being a decent game-programmer make you a better game-designer? Does it make you worse?

As I’ve become a more and more proficient programmer my ideas have become increasingly less “pie-in-the-sky”, to the point of even being a little conservative. This is because every time I come up with some crazy idea the logical side of me censors it before it has time to flourish. Perhaps a person free of such technological concerns would make a better game-designer? A complete ignoramus would tend to propose impossible concepts but, whether they’ll admit it or not, there’s nothing engineers love more than impossible problems.

Furthermore most of my past ideas would have fit quite comfortably into the conventional set of game genres: apparently I’m not nearly as original as I’d previously thought! So:

Should I give up on my dreams of being a game “ideas man” and instead go full-throttle into development instead?

Nope. I don’t think it would ever fully satisfy me, pleasant though it is to have someone us telling you what to do all the time. But if I want to be a designer I clearly need to up my game (teehee), and to do this I may need to find some way of divorcing myself from the technology a tad. For this there’s no better book than Rules of Play, which talks a lot about ideas but never really concerns itself with their implementation. Several reviewers complained that it’s somewhat out-of-touch with reality, but this is actually its great strength: rigour and best-practices can become handicaps when it comes to thinking outside the box. Emily Levine would talk about the importance of “holding your ideas lightly”:

 

Analysis

This all feeds back into the with FOSS games’ problems discussion: nobody is more concious of the technology they’re working on the hackers, crackers, trolls, moles and code-monkeys that make up the Free (as in “Freedom“) -Software movement. And as we’ve discussed previously, this may be its great weakness: there just isn’t enough ignorance to go around! Speaking of Free Software: I recently lost some (more) work so have decided to (finally) start putting all my code and assets online, simply because I’d rather see them stolen than destroyed by accident. When I get round to it…

Back to the point: when Free Gamer picked up the above I desperately tried to cover my rear by doing a post about games and originality in general. The overarching idea here was that there’s nothing new under the sun: innovation can be reduced an extension, recombination and/or reversal (contradiction) of one or more existing ideas. But there’s actually a fourth process at work here, perhaps more important that the other three combined: analysis. Analysis allows us to take an existing idea and to break it down to an atomic level. This dissecting of existing ideas allows us to extract the elements of particular interest, elements which can then be combined, extended or reversed. The more effectively we can identify, isolate and -above all- understand these game-design building-blocks, the more effectively we can put them back together in new and different ways.

This is the main reason why Rules of Play is a useful book to read. It is essentially a collection of all the game-design elements the authors have been able to discover over the years. If you can get through the stylistic fluff this makes it something an invaluable resource because, as with programming, the lower the level you start from the more unique the result!

 

That said if you wanted to buy just one book on game development it probably shouldn’t be either Rules of Play or Game Engine Architecture: I’d recommend Game Design: Theory and Practice for a fairly broad overview of game development, from concept to implementation. But if you can get hold of all three: knock yourselves out ;)

 

So, did you managed to guess what my project is? That’s right! We’re controlling the cursor with gestures, “Minority Report” style! My boss wanted it working for Windows though and Windows, as you may or may not be aware, is rather unpleasant System to work with: egsnay on controlling the cursor system-wide. Not without some special API at any rate…

 

One thought on “Design vs. implementation

  1. Pingback: Open Source Services for Illegal File Hosting « qubodup net

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>