Manager In A Strange Land: The Copper Bullet List

On the blog before the blog before this one I wrote a "Jamie Test" - my own version of the Joel Test, for games - thinking about builds and soak tests and smoke tests reminded me of it.   Unfortunately, that old blog - at fristrom.editthispage.com - has eroded over the years, and it's hard to even find pieces of it on cache sites.  All that wisdom lost to the ages.  The humanity.  I really should back up my other blogs somehow.

I later started thinking of it as "The Copper Bullet List" - yes, there are no silver bullets, but there are a set of copper bullets...or "best practices", a boring thing to call them.  These days, I think almost everything on here is common practice.  But without further ado, here's the copper bullet list reborn.  It occurs to me it comes in two parts:

1)  Making a great game

* The key to a succesful team:  people, people, people.  Try to work with people who are better than you.  There's a large body of literature on how to do this - too much to go into here.  But what's usually worked for us has often bordered on nepotism, working with friends and friends of friends - ]friends whom we know are very smart and talented.

* Don't spend more than an hour or so writing a spec for any given feature, level, mission, character, whatever. (Concept art and schematics can take longer...but don't necessarily have to.)  Instead:  proof-of-concept, spike solution, prototype - whatever you call it, do it.  I believe this is the most important thing, the key to having a spark or je ne sais quois that will make your game stand out.

* "Kleenex" or "Blind" test, early and often.  Not doing this will ruin your game.  Your spark will be buried beneath frustration and hate.  (But if you didn't have that spark in the first place, then this'll just give you a polished, um, you know.)

* Keep communication open;  try to involve everyone in decisions.  Sometimes you'll get a lead who'll say "You went around me!" or "You went over my head!" when two others on the team talk without consulting them first - they'll want to implement a chain-of-command and make sure they're always passing messages, the hub of a game of post office.  This is an attitude that must stop.  People on the team need to talk, and leads should only get upset when one of their guys actually go off task for someone else without permission.  Implementing a chain-of-command is just one of the many ways you can block communication, and this is a point about which whole books are written, so maybe that's a sign that the list has come to the end.

2)  Actually Getting The Thing Out The Door - (and this part's basically the Joel Test rehashed)

* Use source control - AND asset control.  This can be as simple as checking your data files into Subversion.

* Strive for readable, maintainable code first and fast code only where necessary.  (Corollary:  write as little as possible in assembly language.)

* Run an end-to-end build machine.

* Use a bug database.  (Lately we've been using Bugzilla.)

* Fix the real bugs (p1, p2) before writing new features.  Any bugs that wouldn't completely kill you to ship (p3 on) you can leave until later.

* Schedule.  But in Excel, not in Project.  (A 6-person or smaller team could even skip Excel and use file cards on corkboard.)  Scrum's backlog and burndown are my favorite way of doing it these days - we also lump our bugs into the schedule.  See my talk at the IGDA Leadership Forum in November for more on scheduling.

* The people doing the work make the estimates (try the Planning Game from *Long Term Estimating And Planning* for a robust approach to this)

* Keep your turnarounds tight.  Ideally it'll be 30 seconds or less between making your change and being able to see your change.  (A unit test scaffold gives programmers a new way of doing this.)

* Test internally.  Don't rely on your publisher for enough QA.  Depending on the size of the team and the reliability of your build environment, you might be able to get away with the producer, etc, doing it part-time, but probably not.

Whew.  Big talk for someone who hasn't shipped a game in a few years.  But there it is.  Anything you're not doing?  Anything I missed?

Comments

[Pag]

I disagree with your point about not spending more than an hour designing/specing any feature.

You're right that specing features in minute details ahead of time is a waste of time, because a multitude a factors affect how to handle those minute details. Trying to decide everything in advance is the major sin of waterfall design.

However, the reason I disagree with your point is because I believe in having a strong design vision ahead of time. It's possible to have strong, well-defined design ahead of time without falling in the trap of defining absolutely everything ahead of time.

When I design a game, I ask myself for each element whether it's easier to iterate on the idea on paper or in the actual game. Higher level concepts are easier to iterate on paper -- flip-flopping on whether your strategy game is real-time or turn-based is easy on paper, but long to prototype in software, for example. Lower level elements are easier to determine once the game is actually running -- it's meaningless to decide the length of a dribble animation in a basketball game while the game's just an idea on paper. If a part of the game is easier to change on paper than in software, then I spend a lot of time thinking about it while I'm writing the design to make sure I make the right decision. If a part of the game is easier to change in software, I don't even put it in the design doc (to avoid a programmer doing exactly what I said, but not what I want).

There's no hard border between those two types of features, and it's often not obvious how much detail should be written about each feature. How much detail should be decided ahead of time for levels? Do you just decide where they take place? What their key moments are? The rough layout of the map? The position of every enemy and collectable? The precise point to stop adding detail can be hard to decide. And of course it's not because something's been decided ahead of time that it can't be changed once the game is running.

I think of it like a movie scripts. Movie scripts don't detail everything that's in a movie: camera positions aren't described, sets aren't described in detail, character outfits aren't detailed much, etc. The high-level stuff is decided in the script, but the multitude of lower-level decisions needed to make a good movie are made during production. The best design docs work the same way: they define the high level concepts very precisely, but leave the lower level decisions to the later stages of production, when there is something concrete to base those decisions on.

Anyway, that's the gist of my answer to the question "how can we have strong design vision, without falling into the trap of waterfall development?" And that's why I think it's worth spending a lot of time designing features, but only at the higher level.

[Nathan McKenzie]

Pag:

Can you program at all? (don't read that pejoratively - it's an earnest question =))

My experience, as a game designer who is also a pretty quick programmer, is that I almost always have much better success iterating in code than on paper, regardless of what aspect of design I'm looking at.

I guess I would liken it to musicians jamming, rather than movie scripts - sometimes I just have to roll up my sleeves and prod a bunch of stuff until some of it starts jelling and some of it falls by the way side. Then the stuff that works snowballs, and suggests tons of other things, and before long, the design has grown organically around something that turned out to be really promising that I didn't even know about before iterating.

Anyway, from that end, my experience mirrors Jamie's - I find about a hour of paper+pen or conversation is great for mapping out what I (and peers) _think_ is the problem space, and for nailing down tentative solutions to explore. But for more than that, if I'm working in a space where I'm doing anything new or interesting, I find further conversations or designs are often starved of the kind of feedback that can help guide good decisions.

(I incidentally have exactly these same reactions to code methodologies, where many of the exact same issues come up about upfront planning versus iterative design, of course)

I doubt there's a right or wrong - just an assortment of war stories, and these are mine.

It might be, though, too, that this reflects the kinds of designs I find interesting and personally worth doing. If I were making Curse of Monkey Island, where the technologies and gameplay mechanics were fairly known quantities and the pleasure of the game derives heavily from the writing, characters, voice acting, and artwork, mostly iterating on paper would probably make far more sense.

The other thing in favor of Jamie's point, at least from my experience, comes from the nature of teams and discussions. As hard as establishing a vision is maintaining and enforcing a vision. On every team I've ever been on (and perhaps you would argue there weren't strong enough leaders), as long as design was a verbal/textual thing, everyone within talking distance, regardless of their knowledge or experience or discipline, felt that they had co-equal design ideas and input to the central ideas being generated. Selling vision, and keeping it from wandering off to a known title that people have played recently that they all love, can be wildly difficult. This seems especially true higher up management and producer food chains in highly bureaucratic organizations, where power often doesn't rest solidly on the people who are ostensibly experts at game design. At least in my experience, the moment that things are runnable, and playable, and can be interacted with, particularly if you can capture something legitimately fun early, you start having a fighting chance of having your design stick without infinite hours of pointless political infighting and doubt.

[Pag]

Actually, I was a programmer for a few years and worked on a few games before turning to game design. And I actually had an argument with a programmer who wanted me to make a bigger design doc upfront recently -- I guess you can't please everybody ;)

I think code iteration works very well for things that can be built in a few days by one or two people. Beyond that, it becomes very costly to iterate. Sure you can continue iterating in software at all levels, and it might bring great results, but it's going to be very long and expensive because you're basically building multiple games and picking the parts of each that you like. I think there comes a point where your time is better spent on iterating on paper to get nearly as good result as if you iterated in software -- and all the time you saved by doing that can be used to polish the game or make it more profitable.

That said, different types of games have different amount of high level design that can sensibly be done. Jamie's game, as I understand it, is a smaller game that's very dependant on fund controls and AI behaviour to be fun. The base concept is simple, but the devil is the execution and code iteration makes a lot of sense for this. I wouldn't write much of a design doc for Geometry Wars, for example.

On the other hand, some bigger games could really use more iteration on the high level stuff -- iteration that would be hard to do if you had to build large parts of the game every time. Take Halo 3, for example. I played it single player last week-end and was really surprised about how bland most environments were. Everything was extremely well polished -- they obviously iterated a lot on all of it -- but the levels, weapons and enemies were, for the most part, fundamentally generic. You start in a jungle with nothing really memorable in it (but it's very pretty), you pick up weapons that are similar to those of other FPS (but they're very well balanced) and fight generic alien enemies (with finely tuned AI). It might very well just be me, but while I found the small things impeccable, fundamentally I found things lacking.

My gut feeling is that Bungie jumped right into development, figuring they'd iterate to find what's fun and focus on that. This worked, but they couldn't iterate as much on the higher level aspects of the game (you can't just throw away an environment that a small army of people have been working on for 4 months), so these aspects suffered. Spending more time thinking about the high concepts of levels and about the story before they're in the game and hard to change might have helped there.

Then again, I wasn't on the Halo 3 team, so I don't really know. And the game sold a gazillion copies, so I might just be full of it ;)