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?