Applying Best Practices To Game Development

So a lot of people talk about applying good software industry practices to game development.  I just had another idea:  how about we apply good food industry practices to game development?

It just so happens I've read three books on cooking and restauranting, all of which I recommend:  Anthony Bourdain's Kitchen Confidential, Alton Brown's I'm Just Here For The Food, and America's Test Kitchen's The Best Recipe.

From Kitchen Confidential, we learn the importance of speaking other languages so we can work with our immigrant help;  the importance of firing people if they're late to work and don't call in first;  and the importance of crunch time.  Sounds like being a cook is much less pleasant than being a game developer.  Good thing they're so well paid.

Okay, so I'm being snarky.  Seriously, there is some stuff in the book that I think does apply:  he talks about the difference between craftsman and artist.  This is something that Pete used to talk about at Treyarch;  although Die By The Sword was something of an "art project" for us, after that we were pure craftsmen...(although you could argue that the swinging system in Spidey 2 was "artsy" we still had our eyes on reviews and sales - if the People didn't like it, it would get cut)...and by craftsmen I mean we were trying to do a high bang-for-buck job that our clients would appreciate and that would be commercially succesful.  Chris Crawford is an artist.  A fine artist.  We were craftsmen.

Bourdain also has a chapter on firing, one that's fairly merciless on those who coast, cause trouble, or can't cut it.  His argument is that it's a dick thing to do--he argues that it's almost as bad as murder--but you've got to do it anyway:  if someone can't help you bail water out of the lifeboat you've got to throw them over the edge.  I agree with that one too.  (Let the flame wars begin?)

From The Best Recipe we mostly have just recipes.  What's interesting there is the approach:  they experiment with dozens of different variations on a given recipe, doing blind taste tests, and then publish the most succesful result.  What you end up with are recipes where, if you mess with them, you're fairly likely to make them worse.  That's been my experience, anyhow.  Another thing about this book is they have recipes for all of these common-man foods:  hamburgers, steak, chicken, turkey (this is the recipe to use for Thanksgiving, yo), meatloaf, pasta.  I started using these recipes and I became a much better cook overnight.  All from a book.  (I've said it before and I'll say it again:  books are good.)  So what we learn here is that playtesting is important.  We knew that already, but does anybody playtest as extensively as America's Test Kitchen tests its recipes?  Imagine every time you tweak or tune a parameter of your main character you have a group of volunteers rate the experience!

And, finally, I'm Just Here For The Food. 

You've never been to my house so you ask for directions.  I fax you a very precise list of instructions designed to get you where you're going.  Distances are calculated to the tenth of a mile and landmarks are described in Proustian detail.  You arrive without a hitch.

But do you know where you are?  If a tree had fallen in the road or a road suddenly closed, would you know what to do?  Unless you have a GPS in your pocket, I'm eating lunch alone.

If only I'd send you a map instead.

That's what's wrong with recipes.  Sure, they can get us where we're going, but that doesn't mean we know where we are when we get there.  And it would be a real shame to make it all the way to a souffle without realizing that scrambled eggs are just over the hill and meringue's just around the corner.

The rest of the book is his "map" of cooking.  He describes all the basic kinds of cooking, the principles behind why they work, how to do them and how they relate.

Could such a book be written for game development? - and I'm thinking specifically right now of game mechanic development.  In A Theory Of Fun Raph Koster shows us how certain game mechanics relate to each other, and on one page even has a map of a handful of games and their relations, but it isn't the sort of all-encompassing map of the terrain that I'm Just Here For The Food is.  Zimmerman's Rules of Play has the sort of scope I'm imagining, but goes far beyond rules & mechanics.  The game design pattern wiki could become this, but it's in its infancy.  Such a work would be encyclopediac, much larger than Brown's book, I think.  And would it be useful?  The way I imagine it in use is you're working on, say, a stealth game, and your kleenex testers are telling you they're not enjoying it, so you turn to the "stealth game" section of this game mechanic map, and there would be a list of various rules that different stealth games have, and why they work together or don't work, and you might say, "Aha!  My patrol paths are too long;  the player spends too much time doing nothing;  it's right here in black and white."  [Side note:  stealth mechanics are usually just tweaked timing mechanics;  there's little difference between sneaking behind a guard in Beyond Good and Evil and avoiding a stomper on a timer in a side-scroller.]  Just like Alton Brown's book tells you what temperatures work for different kinds of cooking. You'd never come up with a Tetris from using such a reference - it would purely be a tool for commercial game makers who are doing evolutionary experiments in established genres.

You can apply any field of learning to any other field of learning with a little creativity, I guess.

Comments

[Adam Lindberg]

About the flame war thing: I think it's sad that you don't consider teaching that someone how to bail water correctly or try to put them on working with the sails instead, before you throw them overboard. Everybody deserves a chance, just to bad that the gaming industry seems too focused on profit these day (maybe as with all industries, I guess).

Regarding the book, I think it is totally possible. It all boils down to a mature industry and that somebody has got to do it. Will eventually happen. So a wiki (or the 400 rules list) is an extremely good start, what such projects need to be accessible for everyone is a nice packaging and some context, a book to be more specific. Of course you can access a wiki easy yourself too, but books make a bigger impression, at least for me.

[Greggman]

Your playtesting comment stuck out for me. According to a friend that works for Nintendo of Japan, they have something they call the Mario Club. It is essentially a bunch of Kleenex testers. They test your product DAILY and send back comments on fun, frustration, suggestions etc. They do this constantly, all through the project not just toward the end and not just once or twice but DAILY. New people are rotated through the club. This is probably one reason why Nintendo seems to have some of the funnest games. I wish more publishers / developers did this. Most companies I've worked at did zero playstesting. A few did it 2 or 3 times in a 2 year project but that was it and generally the 3rd time it was too late to actually make any truely useful changes.

Another thing that stuck out was your side comment about stealth mechanics and stompers. I'm not sure what the point of the comparison is. If your going to abstract them that far then you can keep going until almost all games are about pushing a button and seeing a reaction. Not a very useful abstraction. Even if it's only imagined, stealth games put the player into the role of being stealthy and this means their perception and enjoyment of a stealth segment of a game is vastly different to they way they feel avoiding a stomper on a scroller. That difference is extremely important and your comment suggests it isn't.

[Darren Gordon]

"...if someone can't help you bail water out of the lifeboat you've got to throw them over the edge.."

That sentence has a very 'if you're not with me you're against me' feel which, like Adam said, can be a dangerous line of thinking.

Say someone isn't an accomplished water bailer and you throw them out of the boat. It would sting to come to find out that given a little time they were able to design a more effective water pump but they're now using it in someone else's ship. It's not always about forcing someone's talents to fit a certain role, but finding the role that best suits their talents.

If you haven't read Anthony Bourdain's A Cooks Tour I highly recommend it. If you have seen the show on Food Network then much of it is going to be the same but it's nice to get his take on his travels without the filter of television in the way.

[Liam Hislop]

As an amatuer cook, I will definitely check those books out (always trying to make my food better..hehe)

Second, I agree with throwing people oout of the boat as well. I know many people will see it as cut and dry, but I know that I have tried to give all of my employees (past and present) the chance to learn and correct mistakes. There have been a couple that obviously either are bored with the position, don't have what it takes, and don't want to learn what it takes. At that point, it's better to cut them loose. Not just for you and your team, but for them. It may sound shallow to say that it could be better for them, but sometimes, it takes something like that to wake someone up. What Darren said about them building a better pump... maybe it's somewhere else that they develop the stuff to build that better pump. It would've been something they never developed in your boat. Is that worth risking the whole thing sinking to find out?

Lastly, I love the idea of a "project management map". I think that it possible and it would be useful. My main question isn't usefulness, but useability. Would it be something that anyone could use, or only people who were trained to understand it, or what? The way you describe it, it would need to be as easy to read as a map, however I know people who can still get lost with the best maps...

[Darren Gordon]

You know Liam, your post got me thinking a bit more about this idea and I've come to the conclusion that as it's presented it has me a bit confused about what Anthony and by extension Jamie was trying to get across.

Initially the idea of getting rid of those who can't bail you out of a lifeboat comes off as being based off the person's ability to (in this case) bail water. Maybe the bucket I'm given has a hole in it, or it's very small and only allows me to bail a tiny amount of water. Whatever the reason is the simple fact that I'm not bailing fast enough is cause to push me out and hope a current carries me to shore. Maybe there's use for my tiny hole filled pail and I elsewhere on the ship?

However Anthony uses this idea when speaking in the context of employees who aren't showing up to work, coming in late or generally don't treat their position with the care and attention it deserves. To me firing one of these people doesn't really warrant some special language, much less a whole chapter in a book (although I'm sure there was more to it then just this) it's plain old common sense.

So I suppose after all this, I was mistaken in my original assessment of what he was trying to get across however after thinking about it some more I'm not sure what's wrong with the idea of firing problem employees. Isn't that what you're _supposed_ to do?

Phew that was a lot longer then I had anticipated.

[Hugh "Nomad" Hancock]

You, sir, are a very smart man. I'd never thought of the parallels between game development (and by extension Machinima development) and cooking, and I've read Bourdain too.

(His chapter on firing is, sadly, right on the money.)

Hmm. I'll have to think about this some more.

BTW, if you can aquire it over Bittorrent or similar, you may find Gordon Ramsey's "Kitchen Nightmares" a worthwhile watch - Ramsey, one of the UK's two three-star Michelin chefs, travels around the country sorting out failing restaurants, and usually telling the viewers a lot about the practical business of running a restaurant in the process.