Blah, blah, blah

Here's a question: how come so many people in game development keep blogs, but nobody in game marketing? Found this, though.

Searching gamerankings and Moby Games for game designers with proven track records, I came across Tim Schafer. Can it be a coincidence that he has a credit on all of LucasArts' best games, but *not* Sam and Max? (For what I think of Sam and Max, click here. I'm probably going to pay for writing that in the future...there's about two degrees of separation in our industry, so no doubt I'll run into whoever worked on Sam & Max at a CGC party or something and they'll beat me over the head with a plate of stale California roll.) And yet he's supposedly a 'programmer'. But what the fuck is this?

Management by Nagging

Anybody can be a manager! It's easy. Here's how it works:

1) ask somebody to do something

2) come back later. ask them if they did it. if not, ask them if they could please do it

3) repeat step 2 until done

It's kind of sad. Despite the number of books on management and people skills I've read, it seems like in the end this is all I do.

Raph Koster says "Not depth, emergence." A better word than depth, I agree, although it may further muddy the distinction between A-Life emergence (an agent did something we didn't expect) and game strategy emergence (a strategy arose we didn't expect). Matt Matthews says maybe one word isn't enough; how about an adjective-noun pair? Hmm..."strategy emergence"..."interactive depth"..."emergent strategy"...I don't know...

Matt wanted to pin down whether I was talking about the micro game--the individual encounters, portions of levels, whatever--or the macro/holistic game. I was definitely talking about the micro game, something the player is going to repeat over and over, thus exploring the "emergent strategies." The macro/holistic game can have emergent strategies too..."get the fairy bottles early and the rest of the game is cake"...but most people are only going to play the holistic game once so I don't think the strategies are a goal, they're just a byproduct of the fact we want to make our holistic games nonlinear and interesting.

Getting together an E3 presubmit for Macrosoft today. This time, when the build broke, I took Draconian measures: I disabled everyone's write access to Perforce. Try checking in crap now, bitches! And, once the build was fixed, knowing that if everyone checked in at the same time it would be broke again in short order, I only let them do it one at a time. Now it's midnight, and the last of the day's changes are checked in, and...hooray...the build still works. An "I have the conch" system of check-ins is Chris Busse & Chuck Tolman's team did every day as a matter of course...maybe I'm dumb to save it for special occasions like this.

Why do people play games? I'd like an exhaustive list of reasons, because it seems like it would be a useful analytical tool. In particular, a game-design rule or guideline could be put within a particular context. Or tradeoffs could be discussed more clearly.

I'd like suggestions for additions to the list. I found myself asking questions like "Why did I put so much time into TFC?"(2,3,8,9,10,13,14), "Why do people cheat at online games?" (#9 + #10) and "Why is Jamie's wife still playing Animal Crossing?" (#13, maybe plus #12)

1. Testing myself against a system
2. Testing myself against others in a competitive situation
3. Operating as part of a team
4. Flavor of pretending to be in a situation
5. Seeing how a situation might play out
6. Having a pretext for acting differently
7. Pretext for socializing
8. Plumbing the depths of a system
9. Feeling of success
10. Gain esteem of others
11. Visceral feel
12. Passing time
13. Pride of ownership in an improved in-game state
14. Challenge of improving personal skills
15. Connection with certain themes

EXAMPLES
1. Puzzles, low-interactivity games (Princes of Florence), Single-player FPS & RTS
2. Multiplayer FPS & RTS, sports titles
3. Team-based FPS, sports
4. RPGs, Historical Simulations.
5. Historical Simulations, RPGs
6. Paranoia & other RPGs, Apples to Apples
7. Parlor games, Party games
8. Chess, Go, Bridge
9. Most games
10. Many competitive games
11. Quake, Starcraft, GTA
12. Minesweeper, Solitaire, any game once mastered
13. Everquest, The Sims, Animal Crossing
14. Any “testing self” or “plumbing depths” game, Poker
15. Railroads, History, War, Airplanes, etc.

Notes on Uplink

Ok, more on the Indy Game front. (Although Uplink may not qualify anymore, now that they've got a deal with Infogrames.)

I've only played it for a couple of days, and there's still a lot more to explore, but let me get some first impressions down:

Uplink simulates being a hacker, but it's even better than it sounds: it simulates being a good, cinematic hacker. Something we learned from Die By The Sword is that people didn't want to simulate swordfighting; they wanted to simulate movie swordfighting. They want to parry and riposte, and all that exciting stuff. The realism of Die By The Sword went too far. Uplink does not have that problem. When playing, you feel like the guy from Swordfish. (Side note: my friend Jon Ross actually knows a guy who does computer interfaces for the movies. Says he mocks them all up in director. Apparently most of the movie development houses work with this guy. Just a factoid I found interesting.)

Is simulation always good? Not necessarily. IMO, what makes simulation good is the immersion it gives, and the more accurate a sim is, gameplay can be improved because the sim will behave the way the user expects it to behave. Uplink succeeds in both of these areas.

When the game kicks in, it drops you straight into the simulation. You can almost imagine that you're a real life hacker, being given access to a hacking-server-farm somewhere on the internet. Elements that add to the immersion of the sim: there is a newsreel you can access. When the game begins, certain news items hint at a story, and show that there are other hackers at work doing the same things you're doing. When you start doing big hacks yourself, there are news items about you. Talk about feeling like you're in a world.

And I won't spoil them, but the elements of the sim that mimic real life allowed me to come up with strategies that actually worked.

Still, in Uplink gameplay trumps simulation: there are 'time controls' clumsily wedded into the interface which allow you to "get to the good bits" quicker, whether it's waiting for a mission to pop up, waiting for a stock price to change, or waiting for hardware to be installed on your hacker rig. And although sometimes the hacking is unrealistic so it can be more cinematic, mostly the hacking is unrealistic so it can be a better game.

(And moments of humor. "Government" is just another company, which probably simplified their coding slightly, and evokes Snow Crash And there's a Steve Jackson Games that has had their server seized by said government.)

One of Noah Falstein's 400 is "Provide Parallel Challenges with Mutual Assistance" and Uplink does this in a couple of ways; one by providing you with a set of missions, each one of which you complete earns you money which you can use to buy hardware to defeat still harder missions. Also, you can always hack additional systems to increase your chances for a given uber-hack. Another Noah Falstein rule is "Emphasize Exploration and Discovery", and Uplink does this as well. You can hack the systems that you're on a mission to hack, or you can explore a world of internet nodes, discovering as you go.

The fundamental mechanic of hacking is this: you have a certain amount of time to hack a system before you're caught, but all the software you can bring to bear on the problem takes time to execute. For me, the constant time pressure created actual adrenaline rushes, a level of excitement that is rarely acheived by other games.

So what about the 'breadth' and 'emergence'? The hacking in uplink relies on adding new elements as you go (you start with the password cracker, then the voice analyzer, then the encryption cypher, and so on) instead of taking what you've learnt so far and extending it, although you definitely can take some of the simpler systems and multiply them for added power. But, like Pikmin, the game is more about discovering how to use and deal with simple elements. Which means for it to remain interesting and challenging, the tutorial has to be sparse; the game is about figuring out how to play the game. Rather than being "Simple to Learn, Hard to Master", it's just "Hard to Learn". I'm sure some people like this aspect of it. (There were some flames on the Uplink forum against people who asked for advice, implying that figuring it out for yourself is what the game is all about.) Not exactly my cup of tea, but I'm willing to accept it, and it can still be worth many hours of attention.

To hack tough systems you hack a lot of smaller systems first. I'm reminded of digging lots of horizontal holes in Lode Runner to get deeper. This brings me to my big complaint with the game. Games can frequently be broken down into their micro and macro aspects. For example, a typical console FRPG will have the fight-with-monsters as the micro-game, and the resource management of your characters hitpoints, skills, and items is the macro-game. With FRPG's the micro-game often becomes tedious -- it crosses the gray area between 'game' and 'chore' -- and it's just the macro-game that pulls you along. Uplink has the same problem. It also has the same benefit; when you hack a system in seconds that used to take you a whole minute, it feels a lot like that party of orcs that used to be tough to kill but now only takes one fireball spell to eliminate; "I'm a badass now!" There are many games out there that prove that if you get the macro-game right, the micro-game doesn't have to be that involving: Animal Crossing and Diablospring to mind. (My wife still plays Animal Crossing and, frankly, I'm getting a little worried about her.) Uplink, for me, is right on the edge; when an uber-hack fails and I say to myself, "I've got to hack all those little computers again," I come pretty close to quitting forever.

Minor nice touch: someone who's name I forget wrote in Game Design Perspectives that Doug Church's "Perceivable Consequence" meant that the consequences of a game action should be severe -- severe enough to make a difference, anyway. It's not clear to me that's what Doug meant, but it may be true whether he meant it or not. Uplink's software economy has an interesting feature along these lines: version n of any given software package costs the same no matter what version of the software you already have. Which creates an interesting choice: do you hold out until you can afford the full deal, or do you accept the weaker software knowing that you're going to have to still pay full price later?

On superstitious learning: part of the game is you have to delete log files to avoid capture. When you get caught, you don't get arrested right away. Which causes a lack of clarity I don't particularly like -- "Why did I get busted that time?" -- but has a nice side benefit: (one is it gives you the opportunity to booby-trap your equipment, which is probably why it works that way) it allows us to think that there may be more going on inside the sim than there really is. In the forums, people seem to be split about whether you have to delete just the routing logs, or if you should delete everything.

They have a brutal save game system: when you lose, they delete all your progress. I'll skip the arguments for and against this, and point out that you can easily hack the save files. This may be a case of Introversion knowing their market, and understanding their metagame: the kind of people who like this kind of game will easily be able to figure out how to save their progress, if that's what they want.

Uplink is buggy, which may be an unavoidable side effect of being an independent game. No army of testers on a battery of computers. What can be done about this? Either indy game developers have to slow down and spend more time testing (which may speed them up in the long run, according to some studies) or maybe the indy movement could use some kind of indy testing community.

So there it is. Since I'd never played Hack or Neuromancer, for me, Uplink was a very fresh experience, and you should check it out if you're looking for something new.

On the topic of indy games, I noticed that there are supposedly 10,000 people in the Uplink forums. If they all bought legit copies, and they make a $20 profit on a $25 sale, that's $200,000. Supposing it took a year to develop (pulled that out of my ass), and there's about four of them...sounds like they're in the "barely surviving" stage. Hard to say. It's not much, but it may be worth it to come up with something fresh, where you own the IP. I'm sure they've acheived their 'minimum profitability', to riff off of Peter Drucker and Greg Costikyan. You go, guys.

Rock, Paper, Scissors Redux

Yes! A rock, paper, scissors tournament!

Some highlights:

Experienced players say winning is not just a matter of luck but strategy. On their first throw, Walker said, novices throw out a fist -- a Rock -- nearly two out of three times. So any player worth his or her salt knows a flat hand -- Paper -- will beat an amateur.
That's why, said Miguel Frutos, a 39-year-old bartender from Healdsburg, he planned a "Scissor throw" in the first round.
"There's a science to it," he said, adding that he honed his skills settling childhood fights with siblings over who had to mow the lawn. "Everyone here's pretty much not as smart as I am."
* * *
Jeff Johnson, a 31-year-old salesman from Santa Rosa, focused on sizing up the competition.
"Whenever you see a tense muscle," he said, flexing his biceps, "they're going Rock. If they look relaxed, it's going to be Paper."
* * *
Maybe there are Michael Jordans in any area of human endeavour. But this is what I think.

Part of the problem with rules for making games is that the term "game" is so broad. Do we expect to have lots of rules that are consistant across multiple types of books, for example?
I think rules and guidelines can be a useful tool so long as you've considered, and are clear about, what the proper scope of their application is. Surely Steven King could give us some guidelines for how to write horror. I'm sure some of that advice is not applicable for a fantasy author, and probably none of it is pertinent for someone writing a math textbook.

Jamie's 400

I don't know much about game design, being mostly on the coding end of things, but that didn't stop me from coming up with my own list of game design rules a la the 400 Project. Most of these I cribbed from other people.

I'm gratified to see that some people not only agree with my "Fun isn't enough" rule, they want to abandon the word 'fun' altogether. (Marc LeBlanc - http://world.std.com/~mahk/algorithmancy/ and Jean-Paul LeBreton - http://www.antifactory.org/archives/000021.html)

There have been a couple notable exceptions to my Don't Simulate A Simulation rule: a lot of people like both JunkBot, a play-with-legos game, and .Hack, a game where you're playing a game. Don't Simulate A Simulation is trumped by raw gameplay and probably a lot of other things; it's mostly a rule not for game design but for generating hype. It's harder to get people excited over paintball and legos than war and skyscrapers. (Actually, using Raph Koster's 'number of google hits' method for measuring mindshare, lego comes in at 1.5 million and skyscrapers only 350,000. Looks like I'm just plain wrong.)

Anyways, I have a new rule, or guideline, or whatever:

Don't Put A Cap On How Good Someone Can Get At The Game

This is the "Hard To Master" part of "Simple to Learn, Hard To Master", and what brought it to my mind today was reading Quake Done Naked. When a game gets enough attention, people can really get into it. And I think almost any game has the potential for infinite (if marginal) improvement, at the very least in time trials. Typical ways we tend to put caps on our games are by

- providing puzzles that can be solved in only one way

- having letter grades instead of raw scores

What's the Point of These Rules, Anyway?

A discussion with Mark Nau over whether chess is really a better game than checkers. I used to think it was objectively, formally, a better game - on the criteria that it supposedly had more 'depth' - and lately discovered that people can get arbitrarily good at checkers just as they can get arbitrarily good at chess. Mark Nau points out it's a different kind of skill: players play checkers the same way computers play checkers - by thinking as many moves ahead as possible - but chess is more of an art, using intuition and feel for strategic advantage. (Maybe I'm getting what he said wrong so he'll be forced to post to correct me and then this site will feel less like "League of Ordinary Game Developer" singular.) So, at this point, it just comes down to aesthetics. And that's a problem with game design 'rules': as much as I'd love to be able to boil games down to a nice formula that always guaranteed good gameplay - wouldn't that make our jobs easier? - it seems like any given 'rule' is going to appeal to one set of people and alienate another set.

All is not lost. If we compare game design to visual arts, then maybe game design has its equivalents of 'fine art' and 'graphic design'. 'Fine art' is the black hole of unknowns, the area where starving artists explore in the hopes of creating, well, art. 'Graphic design' is understood: you read books, you go to school, you can always do a competent job at it with training. This is why it's easier to create good-looking games than games that are fun; we use the well-understood graphic design process to do it, rather than exploring uncharted territory. Similarly, I think anyone, with the proper training and know how, with documented methods and rules, can competently make a mostly derivative title into a highly polished enjoyable experience.

Agh

I want to be the kind of guy who plays games because they're good, not because they're the latest thing with the latest graphics. So I paid $25 for a used edition of System Shock 2, a game which has now reached 'classic' and 'collector's item' status. (Buying new costs $60! For a game that old! Can you believe it?) The demo ran fine on my XP machine. The full version does not.

Black & White had the same problem. Something about Electronic Arts, I guess.

This depresses me. How am I supposed to be the kind of guy I want to be now?

Notes On Rockstar

So I'm checking out this Indy Game Thing. Today I spent the morning playing the Uplink demo, and liked it enough to order it, and also played the Rockstar demo, which I enjoyed all afternoon, but didn't give me enough incentive to pay the whole $6 for the full version.

Rockstar simulates being a rockstar, and is more of a vehicle for satire than a game. To play Rockstar you have to fine tune your drug use and holidays in order to balance your creativity, health, alertness, and happiness. You then attempt to record albums when you're at creative peaks and make money touring. After a few hours of this I never quite caught on to the relationship between albums and touring, or even if there was one. I played three times on three difficulty levels. The hardest--masochist--was the only one where it got interesting. It may have been my imagination but there seemed to be some kind of negative feedback as your stardom progressed: vacations became boring, your fans get tired of you, the studios get sick of you.

What made Rockstar cool was its satire; you can get busted for LSD posession, but it boosts your creativity. Heroin can kill you. (That's how I lost my first game.) You can sacrifice happiness for your other attributes, but if you get too depressed you'll attempt suicide, which will lay you up, uselessly, in the hospital for a while, or even kill you. (That's how I lost my last game.) Your mother offers you drugs. You get laid. Your recording engineers swear at you.

But in the end I have to give it a pass, because the gameplay lacked clarity. Exactly what it was that made gigs succesful or not was a mystery to me. It's fine for a game to have randomness but I was completely clueless as to how to have a good gig or not.

I'm told that at Bullfrog they prototyped Dungeon Keeper with an all-text game first, before they went into production. So who knows? Maybe with more work this game could be turned into something very cool. It certainly has potential.

Thoughts On Working On Licenses

Let me get two more cents in on this Spector vs. Costikyan discussion. One thing I've noticed in this thread is the assumption that everyone would prefer to work on an original IP than someone else's franchise. (Although Greg does mention the possibility of dweebs sending our resumes in hopes of working on Spider-Man 3. Hey! That really hurts.)

I've actually mostly worked on original IP: MindCraft's Magic Candle universe and then Die By The Sword and then Draconus. Even ignoring the fact that Interplay owned the Die By The Sword world we created, and that Crave owned the Draconus world, you can probably guess why this wasn't too exciting for me. All of these worlds were Tolkien/D&D derivative shlock. Orcs, kobolds, dwarves, and elves. Fucking elves! Given a choice between that and Spider-Man, I'll take Spider-Man in a heartbeat.

I'm just speaking from my own experience, but I imagine this is a pretty common phenomenon. If you're not one of the few people in the core creative team, what are the chances you're going to buy into their vision? Even if their vision is something cool the peripheral team probably won't buy into it. Freedom Force would be a good example...in the Game Developer post-mortem, I believe it was mentioned that the team in Australia did not buy into the vision that was being force-fed them from the office in the States. And IMO that was some brilliant IP.

Especially if you're a programmer, like myself. Although an artist or game designer can usually put their own unique thumbprint on the core team's vision, a programmer doesn't really have that outlet.

Of course, if I was in the core creative team, I'd rather create my own IP than go with a franchise. (Once I worked on a title called Gryphon Masters that was all me. I decided Celtic myth was an un-mined area that needed to be exploited by FRPG's, did a ton of research, and with the help of the rest of the team [including Ed Del Castillo and Steve Burke] created some really cool stuff. But I knew crap about project management back then, and if MindCraft hadn't folded first I would have had a huge disaster on my hands.) Even with all the problems that would introduce, the need to find some way to get the whole team to buy into an unknown, the lack of support from upper management, and the like, it would be more fulfilling. So my only point with this article is to point out yet another pitfall with non-franchise titles, something to be aware of.

Notes on Jak & Daxter

So Jack & Daxter benefitted from the consulting of Cerny Games. Presumably, they used the Cerny Method. And what did they get for it?

The Cerny Method involves a prototyping phase. In project management terms, game production with the Cerny method starts with a spiral of several iterations, until you have the prototype you don't throw away, and then you enter full production. The prototyping phase, ideally, allows you to take risks, in the search for some innovative game design mechanisms. If the risks don't pan out, you cancel the project. If the risks do pan out, happy happy joy joy.

So I'm a little disappointed that Jak & Daxter offers very little new. It's Mario 64 with the addition of some cool stuff; a mode where you fly 'zoomers', these flying motorbike like things, and some clever moves, such as pole swinging. Daxter, the furry sidekick who sits on Jak's shoulder and occasionally makes amusing comments, is not gameplay but color. On the technology track, loads are well nigh invisible; just as good as Mario 64 (and remember Mario 64 was on a cart), and better than Sunshine. Clever level of detail makes you feel like you're in a world, instead of in a series of disconnected levels.

So I've got to ask; is that all we get? This is all that can be invented with million dollars of prototyping money?

And then I think about it, and really, it's not surprising. The mode of development for most studios, I believe, is to spend eighteen months making a prototype and then ship it whether it was good or bad. So I should have expected that a million dollar prototype was going to, in the end, produce less innovation than the more typical "throw ourselves off a cliff" method.

We could learn the wrong lesson here and say, "Well, then, the Cerny method must be wrong." But stop and think about everything the game does right. Ed Del Castillo once commented that most games that hit the shelves these days don't feel like they were actually finished. Jak & Daxter is an exception to this (although there *is* a Yellow Sage in the final level, which kind of implies they probably intended to have a Yellow Sage World, which didn't make it into the final product). Jak & Daxter is polished. Part of the reason, no doubt, is that they locked down the feature set early in production; after they finished the prototype. The real lesson to learn is that there are limits to how much anyone can innovate, and it's a good idea to have a process in place to curtail further risky innovation later in the project.

Another thing that I love about Jak & Daxter is the number of times I wanted to throw my controller through the screen was very small. This is amazing for me, because normally I hate platformers for that very reason. I never completed Mario 64, and Mario Sunshine definitely set my teeth on edge on occasion. Also, I never once had to get up and consult Gamefaqs.com to figure out how to get through a level. This is no doubt due to another aspect of the Cerny Method: namely, "Gameplay testing is your most important feedback." One thing the best designers say time and again is you've got to watch people play your game. (In the interview sections of Richard Rouse's book it kept coming up: Ed Logg's field tests, Chris Crawford quoting Dani Bunten, Steve Meretzky saving the play logs for his text adventures.) Mark Cerny has made a science out of this, collecting statistics on how long it takes people to get through levels and where they get stuck.

So: prototype and gameplay testing. Interestingly, Treyarch's best game--Die By The Sword--did these things, albeit by accident. If by prototype you mean, start making something, and then change focus several months later and make something completely different. Die By The Sword went from being a fighter to being a level-by-level dungeon exploring game around a year into its development. Also, I think Die By The Sword was the first and last project where we actually watched people play our game, and tried to take steps to remedy the problems that we discovered because of it. (Although we took very few steps; usually by the time we saw the problems someone was having, it was too late and too risky to change anything.) With subsequent games we relied solely on our publishers for feedback, and maybe that's why Die By The Sword, of all the original games we've done, has gotten the best reviews. (I could make some snide comment about publisher feedback here. Consider it made.)

I Feel Stupid Now

Just read Raph Koster's Small Worlds slides. Damn. I didn't get half of it.

Something that concerns me: it seems like he's saying most games create a phenomenon where the best player clearly dominates over the second best (and the rest.) Which fucks up my measurement of "depth" (still looking for a better word, please help): it means checkers is just as "deep" as chess.

The Light of Day Brings New Softness

I was in the bathroom this morning and my wife had a copy of Entertainment Weekly open to an interview with Harvey Weinstein of Miramax, and it made me reverse myself on the position I posted last night. No doubt, Harvey Weinstein is the kind of guy Greg Costikyan would like to see at a semi-major game publisher. (Is there a Miramax of game publishers?) He's the guy who funds art movies, is willing to take the risk that they might not be profitable, and it seems like for every two profitable movies they do they also have an unprofitable one. It's thanks to him that we have Lord of the Rings and Pulp Fiction, which they then used to fund some of their flops.

So why can't games be this way? Why can't there be a publishing house that funds art games?

I have a theory: it's because we all want to get rich. We aren't satisfied with just being minimally profitable. People all behave as if a game isn't a megahit then we lose money on it. Let's see if that's true. If we accept Greg's numbers of $3 mil & 3 yrs. (Though at Activision it seems more like it's $5 mil & 2 yrs - I bet $3 mil & 3 yrs would make better games...) And we throw in another $3 mil for marketing, then the game has to sell something like 600,000 if it's a console title and 300,000 if it's a PC title. If we go look at our illegally copied npdfunworld data, we discover; only about a sixth of games do those kinds of numbers. So, theory disproved.

Okay, theory 2: the economics of game publishing make it impossible to make art games. Greg Costikyan is right. We can have art movies because there's so much money in movies--and the movie theaters (or "retailers" and "console manufacturers") get a much smaller cut--that tiny markets of afficianados can support lower budget efforts.

This really is a dark time. Things will change, eventually. As tools improve it will become cheaper to make games, and as games get more mainstream acceptance more money will come in. When the internet eliminates retailers, still more money. Eventually we'll hit a point where there can be a Pulp Fiction of the videogame world, and we'll be able to choose between getting rich off of blockbusters or surviving by our art, instead of having to make blockbusters simply to survive.

That new time won't be all bread and roses. The art house publishers will still have to do semi-shady stuff, like campaigning to win awards for their art house games. Part of where Miramax becomes profitable is by campaigning to win the Oscars. Artists are whores, too.

Aren't blogs great? You can watch people change their minds in real time.

What the hell am I doing still awake? I wanted to go to sleep two hours ago.

I love Greg Costikyan's site but he has a Chris Crawford-ish rant that I enjoyed reading that's implying things I don't agree with. The crux of the thing: now more than ever, game publishers are avoiding risks and thus all you can expect to see in your future are sequels, movie-tie-ins, and me-too titles. The suits at these companies are going to cover their asses and will avoid risks to keep their jobs even if it means the company's bottom line is going to suffer. So indy game developers are getting fucked.

We were a starving indy game developer with an innovative title, once. We shipped late, missed our marketing window, and the innovative title tanked. Then we went into survival mode. We've 'sold out.' So I've been there, I know what Greg is talking about.

Here's what I'm wondering. What, exactly, is Greg's problem?

Is it that not enough innovative games coming out anymore?

I have to disagree. Somehow, innovation keeps slipping through. It's been a few years since The Sims, sure. But there's Animal Crossing and Pikmin; there's Kohan; there's Neverwinter Nights; there's Ico; there's a slew of titles that are broken in various ways but certainly inventive (Europa Universalis, Gothic). Devil May Cry was a new kind of third person fighter. And even sequels innovate: Metroid moves to first person, Mario gets a water gun, Grand Theft Auto gets motorcycles and remote control helicopters and an eighties soundtrack. And Tony Hawk (which Greg dissed on specifically) got it's new mission-based structure which really brought out a lot of the latent coolness of the game for me. If companies are trying to avoid risk, how did this happen? Because companies realize they have to seize opportunities. Because when EGM comes and asks you "Why should our readers buy your game?" the answer, "Because it's exactly like the last game." won't fly.

Is it that starving indy game developers can't make money?

This seems to me like saying we should get paid to make art. I think you should be about as upset that such-and-such struggling garage developer can't get a major label contract as you should be upset that I can't get my novel published. If you want to make a totally inventive, high-risk game, great. Fantastic. Just do it on your own time, with your own money. Make art for art's sake. Suffer for your art. The stories of artists who got rich (T. S. Elliot, Andy Warhol, Will Wright) are anecdotal. Most artists remain unknown. Accept it. As Peter Akemann puts it, you have the choice of being an artist or a craftsman. If you want to get rich, you better become a craftsman.

Maybe I'm just bitter. There's definitely been times I wished I was away from the pressure cooker of the thirty-man team working on the big franchise and in some kind of home office writing Slay.

A Better Word Than Depth

Okay, people already don't understand what I specifically mean when I say 'depth', as I was talking about in my post of 2/25 and then again on 3/1. So what's a good word that means 'Having the tendency to evoke complex higher order strategies and patterns from simple sets of rules'? I have the feeling there's already a word out there that means exactly that. Maybe something German. Post your comments, give me some ideas.

I'm thinking out loud for the rest of this post. Bear with me. (Or skip it.)

On the topic of acheiving this quality...whatever we're going to call it...in that first post I reasoned that in the vast space of rules sets there are only a small number of systems that produce emergent patterns...and this is why we're stuck in a design-playtest-iterate approach to making games...but is that really true, I wonder. Maybe some human faculty can be used to narrow in on the cool systems quickly. I used Conway's Life as an example. The question is how long did it take him to find this cellular automata? Basing it simply on population, instead of arbitrary patterns of surrounding cells, seems like an obvious choice in hindsight. And then once you've done that, it won't be long before you've eliminated most of them due to under- or over- populating. So maybe he discovered Life quickly. And when designing games, we can all narrow in on the simple sets of rules that work in just a few iterations.

And here's another possibility: just because Life is the most famous of two-dimensional cellular automata doesn't mean it's the one with the most emergent patterns. The ones that overpopulate create all kinds of patterns, and just because they're static doesn't necessarily mean they're less interesting than the gliders and clocks of Life. (Look at Stephen Wolfram; he's found enough emergent stuff in one-dimensional cellular automata to make him look like a paranoid schizophrenic.) Part of what makes the great games great is the social phenomena associated with them; people talk about them, and study them, and motivate others to study them, and you get this snowball effect of attention massing on this topic, plumbing it as far down as it will go. I'd like to believe that certain games (and Conway's Life) got so much attention because they had the most depth, but who knows? Maybe Chinese Chess is just as deep as European Chess. Maybe those supposedly inferior versions of Go where some of the stones are laid in advance aren't actually inferior. It's hard to believe, but I've got no evidence Game A is deeper than Game B except hearsay, as I've rarely played Chinese Chess and I'm not good enough at Go to be able to tell if the version where the stones are initially placed is in fact more shallow.

Where am I going with this? I'm looking for excuses to consider 'game designer' a nurturable skill. Excuse A was: there might be ways to tell, or at least get a pretty good idea, on paper, if a rule set is going to have the possibility for depth. And Excuse B was: maybe most of the games that have the possibility for depth actually do have depth, and the main reason some games are considered more deep than others is predominantly a social phenomenon.

Excuse B is pretty lame. This is what I get for thinking on paper.

Excuse A has some potential. A game designer can only tell if a game has depth by playing it and playing it and playing it. If a dominant strategy emerges, that's when depth is capped. You could measure the depth of a game: how long does it take to find the dominant strategy? In games like Go and Chess, a dominant strategy, if there is one, has yet to be found. The best game designer will be able to detect the dominant strategy sooner. He might be able to tell, just by looking at the rules of a broken game, what the dominant strategy is, where a lesser man cannot.

Still, even the best game designer cannot tell whether a game has the kind of seemingly infinite depth that Go has or whether a dominant strategy is just around the corner, and just a few more hours of study will turn it up. Which is depressing. When asked "Does this game have the depth to become an eternal classic among the ranks of Chess or Go?" the game designer can only honestly answer either "No" or "I don't know."

Fortunately, in our industry, we're only expected to provide a few dozen hours of play before the dominant strategy is found. And that's easily within our grasp, even for non-genius game designers (like myself) who can't tell if a game is broken until they play it.

The Jamie Test - Step 6

The Jamie Test continues, my eighteen step process. And step 6 is: believe in a higher power. Just kidding. Step 6 is:

After feature freeze, use your bug find / bug fix rates to estimate your ship date

Once in alpha, you may want to have some idea if you're going to be at zero bugs on time. You might think you could take the entire bug list, ask everyone how long it's going to take to fix their bugs, and be done. You shouldn't do this, because:

The time they spend estimating is time they spend not fixing bugs.

DeMarco and Lister have some evidence that programmers work most productively when there are no estimates.

According to Steve Maguire in *Debugging the Development Process*, bug fixing is notoriously hard to estimate. (I can vouch for this one: when Die By The Sword was in alpha, I was convinced that I didn't have enough time to finish all the bugs on my plate, and had a lot of them assigned to others. Then I finished my list in record time, and asked to have those bugs reassigned back to me. I might as well have kept my mouth shut.)

At any given moment, your open bug list is a small fraction of the long list of bugs that remain to be found and fixed; your estimate is only going to represent how long it takes to fix the current set, not the total.

So what are you supposed to use? Strong language?

Greg John has used this process on the last few projects we've worked on together. The way it works is each day you count how many bugs you have in your database, and make a chart. It should, ideally, be a curve that shoots up rapidly after the product goes into testing, hits a peak, and then trails off towards an asymptote of zero. While the curve is still shooting up, the way to estimate your ship date is to pull a guess out of your ass as to how many bugs you are going to have, total. You can do this by looking at your previous projects and extrapolating. (If you don't have previous projects, now's a good time to start gathering this kind of data!) Greg's rule of thumb, based on the projects he's worked on, is to take the number of people-months that have gone into the project and multiply by ten. (In other words, every one of us introduces a bug that doesn't get caught every three days or so.) At your shop, this number will quite likely be different, depending on your process and your testing team. It could vary from under a thousand (LucasArts), to three thousand (Lionhead Studios), to eighteen thousand (yours truly.)

When you're ascending the curve, and testing is finding bugs faster than you're fixing them, your resources are the bottleneck. Overtime should probably be mandatory during this period, as it's one of the only ways to bring the project in sooner. You may even scrounge up resources from other teams at your company. And you can mark as many bugs "as designed" or "will not fix" as possible.

Once you've "broken the back" of the bug list--you're over the hump, and fixing bugs faster than you find them--this means two things. One: you can get an idea of when you're going to hit zero bugs by looking at the trajectory of the graph. You can see how closely this number relates to your previous estimate of how many bugs there were going to be. Two: you need more testing, as now they are the bottleneck. This is the time (okay, one of the many times) you yell and scream at your publisher, because you're doing all you can to bring the project in on time, and they are the ones holding you back. (Evil publishers--*cough* Crave *cough*--may even have a completion-on-time bonus they don' t want to give you if they don't have to, and will therefore give you just the right amount of testing to ensure that you complete just a week or two late.) It's also a good idea to devote your own people in-house to testing, although it may take some work to train your idle artists and coders how to be good testers.

If you're lucky enough to have the kind of guys on your team that care so much about the project that they implement their own features when nobody's looking, it's time to cancel that shit right now. (And maybe you should cancel that shit before the project even begins, but I'm still undecided about that. It sure is nice having people that care.) On my first project--Magic Candle II--we fixed a cosmetic bug--you could walk in a certain kind of foothill that you weren't supposed to be able to--and accidentally introduced a stop-shipment bug: now you could walk on the ocean, but you couldn't sail on it! And guess what! We didn't catch the bug! (Our testing was, like, two people.) It shipped like that! Talk about needing a patch! So this is the time to remind everyone to not fix anything they don't absolutely have to.

I'm making it sound like once you're armed with these tools you never have to stress those last few months again. Unfortunately, you can always be surprised. On our last project, we blew through our rule-of-thumb estimates for how many bugs there were going to be--it was our first multi-platform release and it took us a while to realize that the number of bugs that were getting reported were multiplied by three. And after we thought we had gotten over the hump, we asked Activision for more QA, and they gave it to us. And the bug find rates climbed right back up again. In fact, our open bug graph ended up looking like the stock market. (Normally Gamasutra puts my post-mortems on their site whether I want them to or not, but for some reason they've taken their time with my Spider-Man post-mortem, which has a picture of that terrifying graph.) Times like these make you feel like you're a first year fucking game developer. (Which reminds me of how Peter Molyneux seemed surprised to enter alpha with Black & White to find that they had 3000 bugs and that fixing one created three more. How long have you been doing this, Peter?)

As counterpoint, Chris Busse has done enough large projects at this point that he just "gets a feeling" for when the project's going to hit zero bugs and he's usually pretty close. He can probably go into more detail, but it seems like for him, alpha breaks down into two stages:

The bugs are like fruit on the ground stage. In this stage, you can't play the game for more than a couple of minutes without hitting a stop shipment bug. When the game is in this state, the testers aren't going to try to do tricky things to break the game, like force their avatars into tight crevices where they might drop out of the world, or find some way to take the thug who has the key to get through the waterfall and throw him through the waterfall. (This exact bug was revealed in Spider-Man, after we shipped, by Capcom when they were localizing it for the Japanese. They have some good testers. They sent us a videotape. Thanks guys. Why don't you just give us paper cuts and rub lemon juice in them?) When you're in this stage, you are still at least a month from being done. Probably two. A lot of developers will start blaming the testers for doing a poor job at this point. I have been guilty of this sin. "Why aren't you guys finding the tough bugs? Why didn't you find this bug sooner?" The answer is because they were so busy writing down things like, "Game crashes when you try to punch thug," they didn't exactly have time. (You might point out that a game should never be in this kind of sorry state. I totally agree, but don't know how to prevent it from happening on teams of more than a dozen guys.)

The finding the hard bugs stage. You are officially within striking distance of being done. You can start sending presubmissions to the console manufacturers. (And fix the slew of bugs that they report.) You are a few weeks from being done.

The firemen stage. Here, you've hit zero bugs, and each morning you come to work and the testing team has found half a dozen new bugs overnight. Most of these you WNF, the rest you get fixed by mid-afternoon, and then you sit around and browse web-sites and pray. Maybe you're getting two sets of bug reports a day. You may give the artists the week off, with the understanding that they are On Call, in case a bug crops up that only they can deal with. At this point, you are almost done, and as soon as you've gone a couple days without a bug report, you fire off submissions to console manufacturers. (Or, as was the case with my last project, you spend all day fixing bugs, every day, and then on the absolute last night you can send submissions and still meet your agreements with Best Buy and Wal*Mart and all them, you get down to zero internally and spend all night making the submissions and fire them off in the morning, untested. Woo hoo. Life on the edge.)

---

If you don't mind me patting myself on the back for the moment, one thing about my eighteen step program is that, unlike Alcoholics Anonymous, you don't have to do all eighteen steps for an individual step to work. You could consider these as Game Management Gems or Best Practices. Steve McConnell, in Rapid Development, points out that you should be wary of "Methodologies" that claim they will only work if you adopt every facet of the methodology. XP and FDD both suffer from this flaw. With most of these eighteen steps (none of which I invented myself, btw), you can introduce them, and almost immediately feel the improvement.

Can Do Vs. Can't Do

In Slack, Tom DeMarco says that people can either be "Can Do" or "Can't Do" people--that is, they either have a "Can Do" or "Can't Do" attitude--and a team should probably be led by both at the same time; one to seek and exploit those risky opportunities, the other to worry about the risks and make sure that nobody bites off more than they can chew.

I'm not sure this is true. With proper planning and risk management, I think a "Can't Do" type--such as myself--will be willing to take on risks, and a "Can Do" type will resist the urge to bite off more than they can chew. This is yet another thing I like about Joel Spolsky's scheduling system; when used properly it lets us ask, "Can We Do It?" and gives us a pretty good answer. For the past several months, I have seemed like a "Can Do" person; as long as there was slack in the schedule, I was willing to entertain feature creep.

Today we ran out of slack; the time we have remaining equals the time we have estimated. From here on out, I become a "Can't Do" person. When asked for a new feature, I ask right back, "Which feature should we cut to make this other feature happen?" or "Will you give me the additional resources we need?"

Here's an article by Scott Crabtree on what to do when your schedule is out of slack.

This Hurts Me

Just saw a Yahoo DSL banner ad with a dorky looking guy who says, "I just rearranged my entire homepage! I bet there's, like, twenty programmers freaking out!"

Ouch. I wonder if we even have twenty.