Wow. Just, Wow

UbiSoft ported Splinter Cell from the Xbox to the PS2 in four months.

This is amazing. When doing ports, there are easy ports: going from a weak machine to a strong machine (for example, when we ported Tony Hawk 2 from the PlayStation to the DreamCast). And then there are hard ports, going the other way, like when Treyarch ported Triple Play 2000 to the Nintendo 64. Splinter Cell is a game that pushes the Xbox and it's incredible that they managed to get the whole thing done in four months. If approached with that project, I would have just said no. I would have said it couldn't be done. Not with 90 people on the team, not with 180 people on the team. Reading the article, I still don't see how they did it.

On the other hand, what's wrong with simultaneous development? This is how we did our Tony Hawk 2 port, shipping it at the same time as the PlayStation version. (I pitched a post-mortem on that to Gama but they never responded.) Here's how you do it: use CVS or Perforce. Treat the primary development team as your vendor. Ideally, they'll be a shop as solid as Neversoft, and they'll set up a system so you can access their source control repository. (Neversoft used Source Offsite.) Because they're such a solid team, you can do gets straight from their source control without worrying about the build being broken. If that doesn't work, work out a system by which you get their updates on a semi-regular basis. (We would update from Neversoft weekly.) Integrate from the vendor branch in your source control to your branch on a regular basis. For Tony Hawk 2, I would spend half a day once a week doing this. It was a grueling process in those areas where our code changed dramatically - the tournament scoring system, for some reason, always generated conflicts.

We had a rule to help make the integration process easier: Do Not Change Any Code You Don't Have To. Changing the formatting of a module, or changing the name of an identifier throughout the code base (we would have loved to change CBruce - a legacy class name from Apocalypse - to CSkater. Mick tells me they finally fixed this in Hawk 3.) would have made integration very dicey. By keeping our changes small this was not a problem.

I would have said to UbiSoft: let us start the port now. Give us eight months and ten hand-picked guys.

From reading the article, it seems like they didn't even know simultaneous development is possible. It said things like they couldn't start early because the code wasn't ready yet, and they started work with an early build that still had a ton of AI bugs and the only way to fix it was to bring in the original coders. Maybe there's some unmentioned factor that prevented simultaneous development -- the Xbox team too busy to set up offsite source control or give them regular code drops? -- or maybe it's this: "European developers tended to question authority and try to find a better solution. Sometimes they managed to come up with better ideas, but sometimes they wasted time. On a project with such a compressed schedule, that hurt." Perhaps somebody on the team knew how to do simultaneous development, but was not allowed or encouraged to speak their mind, because UbiSoft Shanghai's command-and-control hierarchy did not allow for it. (On a team of ninety people, I grant you, you probably need command-and-control. But in those early days of the project, when they were a smaller prototype team; what management style did they use then?)

Still, I wish I knew how they did it.

BTW, I've got a new article in Gama, where I say the same thing I usually say: fix bugs, fix bugs, fix bugs.

And this is kind of cool: a ton of Gama articles, indexed by date and popularity.

Who the hell is Andrew Rollings?

I submitted a couple of reviews to Amazon this morning about Rollings' books, both of which I really liked, even though he dissed on Die By The Sword in the first one.

I'm not going to shut somebody out simply because they don't seem to have the experience to back up their words -- for example, I read Joel Spolsky's site religiously even though the team sizes he tends to deal with are much smaller than ours -- but I definitely give more credence to someone who has that track record. Ernest Adams I know, he's got some titles under his belt he can be proud of.

It's especially problematic for Rollings and Morris because they have a lot of advice to offer on how to run a game company that I don't believe was fully field tested when they published it. Advice that heavily contradicts Mark Cerny, but Mark Cerny is the guy with the serious track record.

Another thing that irritated me: in the beginning of On Game Design, they dis on design by consensus, saying that Half-Life's cabal process is the "exception that proves the rule," that the Half-Life guys are really talented and therefore their methods work for them but won't work for anybody else. This dovetails Game Architecture and Design, where they interview a bunch of hot-shit developers, and most of these developers give advice contrary to the advice from the book...but these guys "are from Shao-Lin" and therefore can get away with methods like these.

Rollings/Morris may have a point. Games frequently have strategies that work terribly in the hands of a mediocre player but kick ass in the hands of a strong player. (My favorite example is the Interceptor from Allegiance; learning to be effective with that ship is quite difficult, but once you've mastered it it's devastating.) The mediocre player is best off sticking with a strategy that's easier to manage. Likewise, a beginning studio could be best off working with a "safe" strategy.

But the Cerny Method is not one of those strategies. It is the way a beginning studio should do things; it's an effective strategy that will kick much ass no matter who employs it. Building a game is building a system. Unless your game is very simple, it's going to have emergent properties and complications that you cannot predict. Your plan will not survive contact with the enemy. So, although a bad plan is better than no plan, a big plan is worse than a small plan. A hundred page design document that contains "Design Decisisons" such as 'if the player walks within fifty meters of the nest, the mother monster will go into attack mode, and not leave attack mode until the player is dead or has retreated a distance of a hundred meters' rather than 'mothers protect their nests' is a waste of time and paper...and it's micromanagement to boot.

I'm not so sure about the Cabal Process; so much can go wrong with design-by-consensus (my thoughts on design-by-consensus are two-thirds of the way down the page. That's one thing I liked better about editthispage over blogspot; each article was a separate, linkable page) that it may be one of those advanced strategies best left in the hands of experts.

Still, even if Rollings/Morris are right, and these are secret Shao-Lin methods for making great games, what are you going to do? Are you going to stick with the "safe strategy" that guarantees a mediocre game, or are you going to try to learn the strategy the big dogs use, probably screw it up the first time, but the game after that: look out world!

Still, we don't have to agree with everything somebody says for some of the things they say to be very valuable. (Good thing, otherwise nothing anybody says would be valuable.) Maybe Rollings and Morris aren't that production savvy, but when it comes to game architecture and design, they know their shit.

Ack, bad click, lost post

That's what I get for typing straight into this window. And here I am doing it again. Whoops, there's Cathy with the groceries. Oh well, I guess my brilliant thoughts will be lost for eternity.

Small World

Thanks to Raph Koster (who has a really interesting thing up at his site that further confuses simulation and reality) I know all about small world phenomena, and why it's no coincidence that I once met the author of this (also interesting) article linked to by Joel Spolsky (whom I've never met) here.

But as for small world phenomena, nothing beats the fact that my best friend from first grade, Jon Ross, turned out to be a long lost cousin of my college friend Peter Akemann, who later went on to found the company I now work for.

Notes on Silent Hill 2: Restless Dreams

Everyone I talked to told me that Silent Hill 2 was inferior to Silent Hill. They are so wrong. As (Falstein points out) what often happens with videogame sequels, it is much better. I beefed about my main problem with Silent Hill in the previous post. Silent Hill 2, as mentioned in the comments section, has a much better story than Silent Hill. Not only is it less complex and more clear, but it's also personal and human.

I admit I was more creeped out playing the first one, but I think that was just because it was my first experience of the Silent Hill universe, and if I hadn't had it spoiled for me, the second one would have been just as creepy. (Although there is no moment quite as creepy as the ringing telephone from the first one.)

Silent Hill 2 has an option where you can play it with camera relative controls rather than character relative. Character relative controls kill my feeling of immersion: when I'm steering my avatar like a truck and they're swerving drunkenly on the screen it's a painful reminder that I'm just playing a videogame. Konami calls it "2d type" controls, I guess because if you project the scene two-dimensionally you're pointing where the character goes. I think they should have made it the default control scheme, even though that violates the rule of "Don't change interfaces on people": the gaming world is supposedly used to the Resident Evil style of character control, so to change it would have violated all their expectations. We were under a similar restriction for Spider-Man: our improved control scheme was not the default, because all the people who played the previous game were used to something else. I think that was a bad idea, also. I agree you shouldn't change an interface just for the sake of changing it, but if you invent a better interface, make it the default!

One thing that one could complain about with Silent Hill 2 is that the pacing is slower; in Silent Hill they shoot their wad very quickly, introducing you to the full horror of the world early on. But I think 2 actually did it right, trying to save some of the creepier stuff for the end of the game.

Another thing one could complain about is density. To quote Ken Birdwell's theory of experiential density: "The amount of "things" that happen to and are done by the player per unit of time and area of a map. Our goal was that, once active, the player never had to wait too long before the next stimulus, be it monster, special effect, plot point, action sequence, and so on. Since we couldn’t really bring all these experiences to the player (a relentless series of them would just get tedious), all content is distance based, not time based, and no activities are started outside the player’s control. If the players are in the mood for more action, all they need to do is move forward and within a few seconds something will happen." The original Silent Hill had a good level of experiential density, but this one you sometimes have to jog a fair amount of time before anything happens. Certainly more than a few seconds. I'm betting this was an accidental byproduct of the more powerful consoles; we made similar mistakes when we went from Die By The Sword to Draconus and were suddenly capable of holding much larger levels in memory but without the bandwidth to fill those levels with stuff. At the end of Silent Hill 2 they even give you a scorecard where they tell you how many kilometers you ran. "Tell me about it," I thought. Still, I'm willing to forgive them those boring stretches.

This article on Hypnotic buying the rights to Eternal Darkness reminded me maybe I should compare and contrast those two as well. Eternal Darkness has better gameplay. Hands down. Three resources to manage instead of two, orthogonal elements, a spell system that encourages lateral thinking (borrowed from Dungeon Master I now realize after reading some of Ernest Adams' latest book), a wider variety of challenges, a larger gamespace to explore. The hardcore gamer in me respects that a great deal, and Eternal Darkness was one of my favorite games last year, but I have to admit that Eternal Darkness is not as creepy as Silent Hill 2, and its story is not as compelling, and I think that's what really matters for a horror-story game, so I'm going to have to give Silent Hill 2 the honors for best horror game I've ever played.

Certain types of stories are best expressed by certain types of media, by certain forms. Stories with lots of visual opportunities and simple character arcs make for a good movies or comic books. The "novel of ideas" is best as just that, a novel. And I think maybe stories with heavy backstory work best as video games, because then the "reader" becomes so engaged in uncovering the backstory.

Spoiler warning - read no further - play the game - it's only $20!

Although most videogames thrust the character into a situation where they know nothing, and therefore it makes sense that they are trying to learn, Silent Hill 2 is about a guy exploring his own backstory. The story is about denial: about James Sunderland's inability to admit his own guilt, to remember his own past. The hidden backstory becomes a metaphor for that, and as the backstory is uncovered, James overcomes his denial. It's really kind of cool.

Here's a question: was there a horror movie sequel that was better than the original? I'm not counting Aliens, because that was barely a horror movie.

Story Complexity

Been playing Vagrant Story and Silent Hill lately, doing a sort of retro thing, catching up on PS1 games I missed because I was a PC gamer. One thing these two games have in common is a story so complex that I don't understand either of them. But some modern games' stories are complex, also: Metal Gear Solid 2, Splinter Cell. When I play games like these I often don't even know why my character is doing what they're doing; I just follow the next goal on the mission screen or whatever.

My question is, why does this happen? I have a number of theories:

- the people who write the stories for these games are not good writers. They're people who have contacts within the gaming world, and lucked into a writing position on the strength of other talents. They're under the mistaken illusion that complexity and quality are related.

- the stories are made purposely complex to give the player yet another way of interacting with the game. The story is purposely complex so we have to use our imaginations to make sense of things; the story is a mystery that we gradually uncover as we progress, and the more complex the story is, the more story points we have to uncover.

- although gameplay testing is done on these popular titles; "Did the player get stuck?" "Did the player get frustrated?" we don't test the story. "Did the player get it?" "Did the player know what the hell was going on?"

- the stories actually aren't that complex, and the problem is actually that I'm too lazy to pay attention to cutscenes full of exposition. I don't think this theory is particularly likely, because I am be able to follow the somewhat complex Nintendo stories in Zelda, Eternal Darkness, and Metroid Prime.

- maybe complexity is what the people want. I've overheard people say, of MGS2, "Man, that story is tight! It's totally unpredictable! Nothing you think turns out to be true!"

Whether most people like complexity or not, I'll take a game like Out of This World, where they don't even need text or dialog to tell a completly clear and compelling story.

[Note from later:] Too lazy to play the last third of the game again, this time conserving enough resources to beat the final boss, I read the plot on gamefaqs. And I still don't get it. So there.

Code Reviews: Over-rated

According to Rapid Development, studies have shown that code reviews are beneficial: in theory, the number of bugs caught early in the development process justify the amount of work put into reviewing the code. So we tried it. We wanted to do it right: I read two books on reviews, one by Weinberg and one by Glib. We reviewed, counted the caught bugs, estimated how much time we saved by finding the bugs early.

Our finding? Although we did find some "bugs" early, most of them were not stop shipment bugs. Readability bugs, guideline violations, sure. Every now and then, maybe every other review, we found an actual stop shipment bug and were like, Yes! Good catch!

But we estimated that the amount of time we would have spent fixing the stop-shipment bugs later was actually less than the amount of time we spent reviewing code.

So why are code reviews so damn popular in these studies and software engineering books? My theory is that, way back when, when our compilers and languages weren't so good at catching bugs at compile time, and common practices such as Steve Maguire's for catching bugs at runtime weren't so common, code reviews were extremely beneficial. But as time went on, they became less and less so, until finally the cost outweighed the benefit.

Notes on Ratchet And Clank

After reading the post-mortem on Ratchet and Clank I had to play it. The only other original title that got such a high score on game rankings with such a short development cycle was Deus Ex, if you don't count the time Insomniac Studios spent working on the game they decided to kill. In my book, more important than shipping a great game is Bang For Buck: sure, Nintendo can make Zelda great in four years, Half-Life 2 looks awesome after five, but can they do Ratchet and Clank in eighteen months?

Ratchet and Clank is a good illustration of some of the Harvey Smith articles I've been reading lately: somewhat orthogonal elements encourage emergence and the level design (as with most platformers) is systemic. It's also a good illustration of a few Falstein rules: clear short term goals; emphasize exploration and discovery; and provide parallel challenges with mutual assistance.

Some of the gadgets are more orthogonal than others; while there's a series of weapons that do progressively more damage and have longer ranges (all on the same vector), there's also the brilliant Suck Cannon (possibly the single coolest innovation in the game) which allows you to suck up small enemies and then shoot them. When combined with the amoeba creatures that split into smaller parts, a strategy emerges: hack up the amoeba, suck into your cannon, and use it on the next enemy. The game encourages you to switch weapons because you'll run out of ammo, and ammo for the best weapons costs much more than ammo for the weakest. (And ammo for the Suck Cannon is free.) There are also various kinds of mines. I'm not sure if this counts as a different vector when orthogonality is concerned, because the mines still do damage to enemies...but one thing that does not do direct damage is the 'taunter', which both activates mines and encourages the AI to run towards you (and hit the mines.) More truly orthogonal elements include a grappling hook, skateboard and 'grind boots', jet pack, key that lowers and raises water level, and key that gets through doors (this opens a little puzzle mini game that's kind of neat in itself; I'd say it's the best lockpicking mini-game I've ever seen, including the ones in Dead To Rights and Splinter Cell), and I'm forgetting a bunch.

The AI in *Ratchet and Clank* is typical of platformers. Very predictable patterns: more of a game than a sim. It's clear when playing it that the AI is supposed to be dumb, so nobody faults *Insomniac* for not spending manpower on AI. Still, even though they may have saved a man or two on AI programming, it is simply amazing to me how much stuff they got into the game. Even with the rapid turnaround afforded by repeating the same level elements (grappling hook anchors, turrets, trip lasers, platforms, switches, blah blah blah) there's a lot of different systems (rails for grinding, magnetic strips for walking in loops and upside down, water) and sub-games (skateboarding, flying a jet, and a couple of boss fights.) It makes me want to work for them, just to see how they do it.

As for the Falstein rules: the clear short term goals come up in each level screen, a laundry list of missions that need to be accomplished. The exploration and discovery is typical of the latest generation of platformers: like gates connect the worlds in Mario, your spaceship connects the levels of Ratchet. There are secret areas where one can find 'golden bolts' (I never found out what these were for...maybe just bragging rights?) Because you can choose what you do next, and because you earn money as you explore, it satisfies the 'mutual challenges with parallel assistance.' (This really was useful for me; some of the missions were too hard for me until I'd equipped better stuff, although I felt that somebody much better at the game than me could have made it through the whole thing with just the wrench.)

Like Jak & Daxter, gameplay testing is evident. If I were to give out awards for Least Frustrating Console Games, they would go to: Animal Crossing, Halo, Jak & Daxter, Eternal Darkness, The Wind Waker and this. (Both Metroid Prime and Mario Sunshine were much more frustrating...Nintendo is losing the gameplay-testing wars.) Although I didn't manage to beat the final boss...that's kind of a habit of mine, though...I have so little interest in seeing that final flashy prerender, when the final boss is too hard I'm usually content to just get to it.

I don't know how well it's selling; obviously enough to justify a sequel, but I imagine I would have heard if it was breaking any kind of records. Which makes me wonder: does it make sense to combine shooting with platforming? Both Jak and Ratchet are taking this route. It seems to me that it would alienate both audiences: too cute for people who want to kill, too violent for people who want a kid's game.

On the consensus topic, in their post-mortem they said that they do not design by consensus but they do have a process in place for suggesting ideas and making sure that the ideas fit with the game's vision. I tried e-mailing them to ask what that process is but to no avail. If anybody has a friend at Insomniac, could you bug them for me? I'm really intrigued.

This Post Has Very Little To Do With Games

So I'm pro gun control now. Funny, since I used to think of myself as an anarchist. I'm getting old. It's just that I've been to my third funeral-due-to-firearms in a row, now, and maybe it's just bad luck, but on the basis of that anecdotal evidence, I'm thinking people should not have guns. This will probably alienate me from a lot of my friends, a lot of whom enjoy their guns, but I'm quite happy to sacrifice their gun-owning-pleasure to prevent idiots from having the ability to instantly kill. That's just the kind of guy I am. As for the "they'd just find some other way to kill" argument...whatever. First let's solve this way, and then when they find those other ways we can outlaw them, as well.

And just to keep this blog on track, one thing I really can't stand is people who want to outlaw violent videogames but not guns. Fortunately I've only met a couple of these people in my life, so they must be fairly rare. We should get to shoot as many virtual people as we want. Not because it's "cathartic" and might reduce real-life violence. I'm sure it isn't and doesn't. Just because.

Happened across a good article on play balance: http://www.gamedev.net/reference/design/features/balance/default.asp.

This Is Not A Good Idea

In multiple different games now I've seen this: doing nothing recovers a vital resource. In Diablo 2, you stand still and recover your blue stuff. In The Getaway and Enter The Matrix and Wolverine's Revenge, you stand still and recover health. It actually makes some sense for Wolverine, I suppose. I can imagine why people implement systems like this:

- you can avoid putting those immersion-breaking power-ups into the game

- it makes the game easier and thus should appeal more to the casual gamer

- games where resources stay depleted can be problematic at save-time; if you save a game with depleted resources you may never dig yourself out of the hole you're in

Still, haven't people noticed the problems this creates?

- standing still and watching a resource meter recharge is about as fun as waiting for a level to load

- skill becomes almost irrelevant, both at a tactical and strategic level; if you don't need to conserve resources during an encounter, there's no reason to play that encounter intelligently (except that you'll have to spend less time waiting for your meter to recharge - I suppose if we consider a player's patience as a game resource there's still some motivation to be strategic) - and at the strategic level, you never have that choice of "do I keep going ahead with limited resources" or "do I backtrack and try to find some more resource?"

There must be some solution out there that satisfies all these needs...

[BTW: I'm just talking about single player games here. In multi-player games the amount of time a resource takes to recharge (Kohan) becomes a factor in your strategy.]

Peter Molyneux

Check this out. Peter Molyneux totally beats himself up over all the games he's made, up until Black & White. I can only assume he's beating himself up now about Black & White: why? Becuase, to quote Jim McCarthy, "Bug Count is a Constant." We never finish our games. We put in as much coolness as we can in until we have to ship. Games aren't finished; they are abandoned. Then we take the wishlist features and bugs we marked "Will Not Fix" on our last iteration and try to put them in on our next. Which is something I should try to keep in mind when I criticize games; I always say things like "Why didn't they do this?" The answer is usually: "We wanted to, but we ran out of time."

Black and White seems like the sort of game where you get out of it what you put into it. Which is a risky sort of thing to make; it optimistically believes in the player, that they are going to come to the game open-minded, that they trust you enough to say, "I bet there's more cool stuff in here to discover." What did Rollins say? "This time, we're not going to leave anything to your imagination. We tried that the last time, and in our opinion, it didn't work." Still: the opportunity this risk affords seems totally worth it, to me.

He also talks about having a 'test-bed', what Cerny calls a prototype, what many companies call proof of concept. I agree that this is totally essential.

I only watched the first half, and then he started plugging B&W, but it was interesting up until then.

E3

The best moment of E3 for me, easily, was meeting Ian Klimon and Adel Chaveleh of Timegate Studios and giving them props. It's good to know that they're part of the Kohan online community; it's good to know that what they're trying to prove with their new game is that they can have the strategic richness of Kohan with the beauty of a WarCraft or Battle Realms; it's good to know that the game is entirely data driven so the mod community can go nuts; it's good to know that they're striving to make the actual Kohans themselves less of an unbalancing, random factor in the game. (My biggest complaint with Kohan is that we actually enjoy it more when we turn that namesake feature off, although the guys online seem to love it.)

The rest of E3 was a drag. No Splinter Cell or Wind Waker to get excited about. If you just look at the stuff on the show floor, it seems that Greg Costikyan is right: innovation is dead. There are supposedly innovative titles out there, such as Half-Life 2 and Fable and The Movies (how can Peter Molyneux work on two games at the same time?), but they weren't on the show floor, and I wasn't about to stand in line to see a movie about a game. And to be honest, after Warren Spector's speech about sequel teams carving out their own space to innovate within, I was expecting more from Thief 3 and Deus Ex 2. Maybe I didn't play them long enough, but I was hoping for at least a Mask of Majora or Wind Waker level of innovation, some kind of Take It To The Next Level sort of thing, or some kind of orthogonal feature that would add a new dimension to the game space. Don't get me wrong; the guys at Ion Storm are still my heroes, and I'll still buy these games and play them and enjoy them. I'll probably get Deus Ex for the PC since you really want that mouse + keyboard action when you screw up and need to blast your way out, and I'll get Thief for the Xbox since it's got that lockpicking mode and doesn't really require those FPS skills.

Speaking of disappointing sequels, saw the Matrix: Load at a crappy theater with blown out speakers near the convention center. I wasn't expecting much, but they somehow got in under my expectations anyway. It wasn't as big a letdown as Phantom Menace, but that's not saying a whole lot. What helped fuck it up (and to keep this blog on topic) were the hooks they added for the videogame to fill in: you have these tangential characters and an epidemic lack of clarity (to quote Jay McInerney) as to how they fit in with the whole picture. To increase my depression the reviews for the game seem to all be saying "Although the gameplay is totally mediocre you should buy this game anyway for the movie footage." If that footage was so important why wasn't it in the movie? Let the game be a game, for Christ's sake.

Orthogonal Elements Redux

The bitch about orthogonal elements--to push the metaphor--is one of your elements may be aligned with Winning The Game, whereas the other are orthogonal to it. For example, your fight game has attacks and defenses, but only attacks win the game. Or you've got a medic unit in your RTS, but it's your soldier that wins the game. I bring this up because I was asking myself "How come the game I'm working on has so few orthogonal elements?" and the answer was we couldn't think of a way to make those orthogonal features actually useful to the player. I'm not sure this is something Harvey Smith went into in his article, and I don't seem to have PowerPoint on this machine so I can't check. I still think orthogonal elements are key, but getting them in is hard work.

Another reason why we play: to learn an actual skill that might have a hint of application in the real world. I've been playing Amplitude during compiles, and telling myself that I've been improving my rhythm. I wonder if regular Amplitude playing could make one a tighter musician during actual jam sessions?

Actually feels like we're in good shape for E3. For the first time ever--that I was involved, anyway--we're showing some of the actual game instead of proof-of-concept stuff that we're planning on scrapping later. It runs anywhere from a half hour to three hours before it crashes. We worked a lot of overtime the past couple of months, sure, but it's been 50-60 hour weeks, not 24-7. Which makes me think of something I just read in DeMarco and Lister's *Waltzing With Bears*: they say it's more likely for your deathmarch projects to be low-value projects. The logic being that if your project is of high value to the company, they'll do it right and give you the resources you need, but if they're not into the project, they'll shaft you for resources and tell you to work extra hard.

Experiences

Alex Bortoluzzi was telling us about his most touching moment at E3 two years back; we were demoing Spider-Man and a guy in a wheelchair came up and played the demo over and over again. Alex said the guy was a little misty eyed.

I think that's the most important part of what we do; we give people experiences that they cannot have in real life. This is something novels, movies, and television aspire to do but can not. I've believed this ever since I read Richard Powers' Plowing The Dark, a novel about a team of people creating a virtual reality experience. Powers ties it all in with games and narrative, places it in the context of world history, says it's the new frontier and our future. That book is basically what keeps me going at this job.

But this belief has ramifications: if providing simulated experiences is the most important thing we do, then the game-game-type-game aspect of game development - the point systems, the combos, the rules, the levels, the strategies - is secondary. I think we're seeing the industry start to realize this; GTA3 and Halo represent a gaming future where the simulation (being an unstoppable criminal or being a space marine) is considered more important than the game: I don't know how often people compare their GTA strategies looking for a new insight in how to play the game better; and those giant battles from Halo where you're just one marine among many is not so much a challenge you're trying to win but an experience that thrills you. Metroid Prime, on the other hand, is stuck firmly in the past: with its power ups and color-coded monsters and save-game stations instead of feeling like a space marine you feel like you're playing a game about being a space marine. (If you worked on Metroid Prime, don't hate me: I still thought it was good stuff, definitely got my attention's worth out of it. I just liked Halo better.)

Another ramification of this belief is that those people who only seem to care about good graphics and good audio - those people I've typically snobbishly looked down on as not understanding Games - are on the right track. The graphics and audio are what makes the simulation more immersive, makes it easier to suspend our disbelief, forget that it's just a sim.

And it means that VR, although overhyped in the early nineties, will make a comeback. I think the real reason VR failed as a money-making enterprise back then was the technology just sucked. We were promised that we'd be put in these immersive worlds but we weren't. You'd turn your head and the world would update a half a second later. Give it another decade or two or three. Once the tech is there, it'll be what you want, and if we haven't been burned out already, that's where we'll be working.

Interface or Yummy Candy?


There are some things that we can (almost) all agree belong to the realm of Interface. That is, the experience should be as low-profile as possible because no-one wants to interact with that experience itself. It is just a necessary evil we have to go through in order to get to the thing we actually want (the Yummy Candy).


The process of using the mouse and keyboard in tandem in order to get these words on the web site is a good example. If I could make it so, the process of getting my thoughts to the web site would be instantaneous and invisible to me. The Yummy Candy payoff is having expressed my idea.


If you could perfectly determine on a given project what should be Interface, and what should be Yummy Candy, that would vastly clarify many design decisions. Problem is, people differ even on that most fundamental level.


Playing Age of Empires, I thought that having to micromanage the villagers was Yummy Candy. In my mind, a significant parameter of the game competition was managing one's own attention, and keeping track of everything under pressure. Many others thought this was Interface, and so the sequels featured build cues and more intelligent villager behavior.


An even more extreme case is MOO3, where the design comes close to relegating almost every decision to the Interface category, so that it is possible to win just by clicking the "Next Turn" button over and over. I see what they were trying to do. They wanted people to be able to go after whatever Yummy Candy they each individually wanted to go after, and leave the rest to Interface. Maybe it was just the specifics of implementation that made it fall flat.


Is hitting the piñata just an Interface to the candy inside? For some, yes, and for some, no. Just try your best to assure that you're not making people bang on your Interface over and over before they get any of your game's Yummy Candy to fall out.

Orthogonal Game Elements

A criteria for good game design which seems obvious but is easy to forget in the heat of brainstorming. Fight games forget this all the time, by adding more attacks instead of coming up with ways to multiply the potential of the game. The reason I mention it was I was browsing Ion Storm's web site yesterday and Harvey Smith gave the subject a thorough going over.

The Jamie Test - Step 11

Build Consensus

Going ahead a few steps. Chris's post - which, incidentally, seems to have doubled our readership (Go Chris! I hope your career will survive being blacklisted by Derek Smart) - got me thinking some of the same old thoughts.

I had an English teacher in high school who told us that nothing good ever came out of a committee. This woman also told us that the human body undergoes a weight loss immediately after death -- no doubt the departure of the soul -- and that she was visited by Jesus in her bathroom. Still, she isn't alone in her thoughts; a lot of people look down their noses at 'design by committee.'

I was reading the same post-mortem that Chris read, which talked about the failure of 'design by committee.' I think the wrong lesson is being learned here; much like when you're playing Texas Hold 'Em and you decide not to draw to the inside straight and, lo and behold, the inside straight comes up, and you rebuke yourself, and you say next time I'm going to draw to the inside straight. Wrong lesson. The project in question had a number of problems and 'design by committee' was not what sunk it. This was a project in which a lot of the team members knew the project was in trouble the whole time. If there was any 'design by committee' going on, either these members of the team weren't on those committees, or the committees were not effectively building consensus.

There's a number of ways committees can fail:

Wrong people making the decisions. (Wrong people in the committees.) Frequently you'll have a group of managers as the only ones making decisions and they forget to include the people who are actually going to do the work and know their jobs. So you're handing out job assignments to people who haven't bought in to those assignments in the first place. (I saw this in action with Minority Report. I happened to be in the room when a programmer didn't want to implement a design his boss was suggesting. The boss said, "The consensus is we should do it this way." I said, "It's not consensus if the programmer doesn't agree." "I meant it's the consensus of the leads," the boss said. This was one minor point that surely was not to blame for Minority Report's failure, but if every single aspect of the project was handled that way it could be a problem.) Another possibility, the client (usually the publisher) is not in on the committees either, and will try to control the project retroactively. And finally, people join the team after decisions have already been made; do you rehash all the decisions up to this point? Or do you just shove the old decisions down their throats?

Fear of hurting each other's feelings. At some point, brainstorming has got to end, and hard decisions have to be made, otherwise you will end up with bloatware, as every single person's pet feature is put into the game. It probably is the real problem that the people were complaining about in that post-mortem I mentioned; it's also a problem that we experienced on the team I work on. Our original design document outlined whole systems of features that were tangential to the focus of the game - not quite toasters for cars but headed in that direction. The only thing that got those features cut was that we ran out of time. If we'd been more vigilant in our design, we could have cut sooner, and the resources that did go into those features could have been spent more usefully.

False consensus. Drucker talks about the social experiment where a group of people, in a circle, are asked if two different lines are the same length. Every member of the group but one is a plant; they agree that the different lines are the same. When it gets to the test subject, he almost always caves and agrees with the rest of the group. This phenomenon is what allows a whole group of people to collectively agree on the same bone-headed decision.

Not the best ideas The ideas that go in are not the best ideas but the pet ideas of the most persuasive people. (Often the most persuasive people will be people in lead positions, granted a sort of unconscious bias.) According to Carnegie, persuasion has little to do with the 'rightness' of your argument, and more to do with how you argue.

Nothing gets done Spending eternity in meetings without doing any actual work. When thesis and antithesis compete, it takes a while to come up with synthesis. At the beginning of our latest project we spent half our time in meetings for the first few months. I think the time was well spent but one could argue that we'd have more to show if we just dove in and started making stuff.

That's quite a list, so you may want to switch to The Boss Decides method of making decisions. What this gets you is a trade-off: you're less likely to be bitten by the "fear of hurting other people's feelings" problem and the "nothing gets done" problem, but you're more likely to be bitten by the "false consensus" problem (a bone-headed consensus of one) and the "wrong people making the decisision" problem and the "ideas are not the best ideas but the ideas of the most persuasive." (In this case, the boss.) In my opinion, the fact that you now have someone Responsible running the show, whom you can fire when he fucks up, doesn't really make up for the fact that you've increased the likelihood of fucking up.

My suggestion is this: if you are in a leadership position, take the risk of abandoning yourself to consensus building. (It's hard. There have definitely been times where everybody except me wanted to do one thing and I insisted on another. I now feel that the correct thing for me to do in those cases was keep hashing it out until we achieved synthesis.) If you're not in a leadership position, make yourself heard and try to encourage others on your team to be heard as well.

How do you build consensus? There's a short guide here that I just found via Google. And if you want it spelled out in excruciating detail, and don't mind wacky space cadet stuff, then take a look at the McCarthy's "Decider Protocol" in their Core system here.

These systems solve items 2 through 4, and make some effort to mitigate item 5. What they do not solve is having the wrong people in the meetings. (Our programmer team rapidly achieved consensus when we proposed that we should all get more RAM. There was nobody from budgeting or purchasing in the meeting.) This is a problem I do not yet know how to solve. Must research.

If you still think 'design by committee' is a bad idea, consider this: like Chris said, the Half-Life guys did it. But they took three years to ship, you point out. Well how about this: the Deus Ex guys did it. In my opinion, Deus Ex is the biggest success story in all of recorded videogame development: quality delivered in a timely manner on a reasonable budget. From their post-mortem:

Should you get to name your character or not? A holy war almost broke out on the Deus Ex team about this. "If you can't name your character, it's not an RPG," said some. "If we don't name the character, how do we write and record compelling conversations and create a cool story?" said others. "Story isn't the point…" "Yes, it is…" and on and on and on. We compromised: we gave the player character a code name and back-story but let the player select his real name, which came into play in various ways (though never in speech).

Not a compromise at all, but synthesis. They practice consensus. And so should we.

Chris would say something like, "You're missing my point, Jamie. I never said design by committee was bad, I just said there has to be someone with whom the buck stops." I would argue that since, the world of business being what it is, buck stopping people are built into the system. Whoever your pimp is, they're going to want to know who the "one in charge" is, and that person is going to be considered responsible for the results of the entire team. What concerns me is this unhealthy fascination we have for the org chart. The system wires us to spend a lot more time thinking about who is in charge than we should. Because the system does this to us, and because at some level we like it (who doesn't want to see a nice fat "Technical Director" credit on the game they shipped?) we need to fight this tendency to actually make a true consensus happen. Don't worry about figuring out who is in charge of whom; worry about figuring out how to get the best ideas into your game.

Site Name Change May Be In Order

Saw a movie poster for League of Extraordinary Gentlemen yesterday. They're calling it LXG. LXG??? LXG?!?!?!?! What the fuck? What the fucking fuck? Looks like some marketing suit out there thinks they're making an X-Men thing. I guess after From Hell, I shouldn't be surprised by the butchering of Alan Moore's work. But God! Some people just don't Get It. I say to whoever is making that movie: Good job. You've alienated your hardcore fans and probably the casual moviegoing audience as well.

And now our thirty or so loyal readers will be associating this site with a lame movie instead of a cool comic book.

No Toaster Cars
Know what your game is trying to deliver, and measure everything against how well it helps deliver that thing. If your game is supposed to deliver a visceral feeling of mayhem, don't work on a realistic driving sim. Yes, driving sims are fun. But that's not the game you're making.

Making an appliance that toasts bread is good. But not if you're supposed to be making a car.

No toaster cars.

Conundrums

It seems that every project management platitude out there has its converse out there as well. To wit:

On Offices

People Should Have Their Own Offices

– Steve McConnell

The argument being knowledge workers need long periods of undistracted time in order to accomplish thought-intensive tasks.

People Should All Be In One Big War-Room

The argument being that communication is essential and therefore everyone should be able to always talk to everyone else.

On Scheduling

Optimistic Schedules Are Bad

– Steve McConnell

The argument being that to achieve an overly optimistic schedule you engage in risky and shoddy workmanship, creating a massive bug list that ends up lengthening your schedule beyond what it originally would have been before you got "aggressive."

Optimistic Schedules Are Good

– Steve Maguire, Jim McCarthy

Steve's argument being that tasks take the amount of time allotted for them; to make sure they take as little as possible, create an impossible schedule and rest secure in the knowledge that everyone is getting everything done "as soon as possible."
Jim's argument, from Software For Your Head, is that there are no shortages of resources; only shortages of resourcefulness. I guess we could paraphrase him by saying necessity is the mother of invention.

On Managers Doing Actual Work

The second rule of Bad Management: put yourself in as your own utility infielder

- Tom DeMarco

There are several arguments here: one is management takes time and you should do it. Another is: the people on your team probably know their jobs better than you do, so you shouldn't try to do it for them. Another is: in the role you find yourself in, you're going to be distracted on a regular basis, and therefore not going to be able to focus on doing actual work.

Just Do It or You Pet The Kitty, You Own The Kitty

- Joel Spolsky / Jim McCarthy

I'm paraphrasing here. Joel points out that multitasking is harmful, so if you see a task that needs doing, and everyone on the team is already working on something, it's better to do it yourself than to make somebody task switch. Jim McCarthy says the person who proposes something should implement it, since he's the person who gives a shit.

I'm sure there are more examples of these. In these cases, I think there are solutions where a kind of synergy between both arguments can be developed: for the offices question, we could have a central war room ringed with private offices; "your" computer is in the war-room, but when you need privacy, you can borrow one of the private offices. (I've never heard of anyone actually trying this.) An amusing side note is that on my team we do the exact wrong thing: the people who are actually doing the work are in cubicle farms or share offices, where they get maximum distraction and very little communication, whereas the leads – who should be doing most of the communicating and less actual work – get their own private offices.

And with scheduling, you can use the method from Critical Chain and Slack: schedule deliverables aggressively but have a fat safety buffer at the end of the project. In a way, the industry already does this and calls it 'alpha', although we supposedly do it as a time to fix bugs (which encourages sloppiness, IMO.)

And for that last one, I have no idea. Must think.

Jamie Test, Step 8, Part 2

Let team members estimate their own schedules

More on the scheduling thing: I thought I'd share some of our experiences working with Joel Spolsky's scheduling system.
There are limitations to his system, and while it's still the best thing I've found out there--it beats the crap out of scheduling on filecards, XP style--you have to be aware of the limitations or you can fall into some traps.

- The "Debugging" pad / buffer can allow you to break the system. Supposing I code up a feature. I use up all the hours I've scheduled for it, and it's "done". One problem: it doesn't work yet. So I keep banging my head against it, and log the time as "Debugging." This isn't a problem for the lucky few who write code correctly the first time; people like me, on the other hand, tend to write a collection of bugs, fix the bugs, and then we have software. If we log the 'bug fixing' phase as "Debugging", then we aren't measuring correctly, and the scheduling tool loses its power. The way to fix this is to make sure everybody on the team is aware of this pitfall, and doesn't call a feature 'done' until they've gotten it to the point where there are no stop-shipment bugs that they are aware of.

- The schedule does not explicitly discourage multitasking; you may find that someone is switching from task to task. This could be because different people are asking them to work on different features, or because they just got sick of working on one thing and decided to work on another. Multitasking is bad. Unless truly higher-priority items come up, let people focus on one thing at a time. It's hard to do; everyone wants everything done at once, and they will be constantly asking, "Isn't someone working on this?" and the easy way out is to say, "They are now!" and switch someone.

- People get confused by the whole 8 hour day thing; on our team, we tell them "they aren't hours, they're eighths of days"; on other teams they go to daily. If you spend a half day on something, then you elapse .5 days. A meeting might be .25 or .15.

- Joel says to keep subtasks under 24 hours. In my experience, if you tell your team this, they will frequently underestimate a task (yep, that'll take 24 hours) rather than take the time to subdivide it correctly. (You could argue that we should fix the real problem rather than hack it.) I'm happy with 40 hour granularity; that may be because our schedules tend to project out for almost a year, and we don't need the finer grain.

- How to get everyone to correctly elapse their time every day? If everyone starts on the same day, then they should all have the same number of hours elapsed at the end of every day. So at the end of the day, a manager can run a pivot table that sums everyone's elapsed hours. (Jem Maza found a clever way to automatically pivot into a different spreadsheet.) Then we e-mail that table to the team and people can see who is off. If someone is particularly bad at remembering to elapse, you break out the whip. This is important; the longer you go without remembering to elapse your schedule, the less accurate it gets.

- When someone runs out of time, and someone else still has slack, we'll move tasks across. Because resources aren't fungible, we erase the previous coder's estimate, so it doesn't bias the estimate of the next coder.

- Have a wishlist page in the schedule doc. When the whole schedule is out of slack, it's time to cut features. I cut them from the main page and paste them on the wishlist page. If some time frees up--that very rarely happens--we can move them back. When people come up with new ideas for features, they go onto the wishlist. You can look at the wishlist at the beginning of your next project.

- At certain stages of the project, if we find that someone is consistently under-estimating, we'll go in and pad their remaining estimates. This is usually followed by a spree of reassigning and cutting features.

There are a few arguments against the system: let me address them.

1) "You say this lets me self-manage but it seems more like self-micromanagement to me!"

Micro-management does not mean to manage something in excruciating detail; it means a manager is telling someone else how to do their job. You should be managing in excruciating detail; you should not be telling someone else how to do their job. The scheduling system puts the responsibility for managing the schedule where it belongs: in the hands of the person who knows the most about the problem.

2) "The time I spend scheduling I'm not actually working!"

This isn't really an argument against this system but an argument against scheduling in general. And it's not completely without validity! Scheduling is only useful up to a point, something I talk about here. But for the most part, scheduling is going to be a fact of life, particularly in the production phase of your project, so you might as well use the best system available.

3) "I can't make a decent estimate on how long something is going to take until I've worked on it some."

Scheduling takes time. We admit this. That's why we have a field on the schedule for the act of scheduling itself. If the way you want to schedule is to start working on a task for a little while, until you have enough of a handle on it to make an estimate, that is totally fine. In general, I've found that programmers are surprised at how accurate they turn out to be at the end of the project. In my experience, once estimates are averaged out over a long period of time, everyone comes in between 90% and 150% of their original estimates.

4) "How can I possibly know with that degree of precision how long my tasks are going to take?"

Precision isn't important; sometimes you're over, sometimes you're under; it all comes out in the wash.

5) "How do I know when I'm supposed to work overtime?"

When your boss tells you "have this done by Friday" and it's Thursday and you're not done you know you need to stay late. When your boss is some kind of Mr. Softie who only expects you to deliver half of your tasks early it's not so clear. I believe that some overtime is important; that no matter how good a game you can make in a forty hour work week, you can make a better one in fifty, and marginally better still in sixty.

We work overtime when there's an unavoidable external deliverable due and we're not sure the game's going to be good enough by then. So we're crunching right now (50-60 hour weeks) for E3, because we're not Sure.

Another reason to crunch is when our bug find rate is higher than our bug fix rate; during this period of time, we're losing ground, and the only way to make it up is with good old overtime.

6) "It doesn't handle dependencies!"

This is the big one, and we've definitely been bitten by it: a version is due, and it's supposed to have feature X, and there's plenty of time for each person working on feature X to get the subtasks done, but the subtasks have to be done in order. Personally, *I* don't care: I'm happy with: when person A gets to their part of feature X, and they discover they're dependent on Person B, we make feature X the highest priority for Person B, and let person A move on to feature Y. Feature X doesn't make it into the rev, and we live with it. It's my belief that, over the cycle of the entire project, the effects of these dependency chains disappear, because these dependency chains are under a month or so: mission requires character which requires animations which require model, for example. As long as we prioritize these things correctly, and push them through the factory, they'll get done before alpha. Of course, the people who evaluate your milestone deliverables may not be as casual about it as I am.

Alexander Jhin has had some second thoughts about his article on the coolness of using behavioral psych in game design. He used to think it was cool, now he thinks it denies the possibility of art in games. I'm not so sure, and I posted this in response. If there's anybody out there who actually reads all my posts, you'll see a lot of repetition here:

Behavioral psychology has the luddites imagining *Clockwork Orange* and pigeons pecking at levers but it was my favorite subject back when I got my psych degree. As I was graduating in 1991 there was a semi-new movement afoot to stop thinking of behavioral psych in terms of manipulation but in terms of communication. The pigeon isn't pecking at the lever because it knows it will get food; the pigeon is pecking at the lever to communicate with the researcher that it would like some food now, please. Or, the researcher is communicating with the pigeon - "Let me know when you want food by pecking this lever, ok?"

Games may be one of the only media that can use this avenue of communication. Will Wright could have written a book where he might say, "Debt is poisonous to a municipal government because of such-and-such." Instead we have this game where he shows us what debt does by punishing us for using it. (I've learned a bunch of other lessons from Will, such as "Nuclear energy is safe and efficient" and "Always hire a maid". I'm not saying what he's communicating is right, I'm just saying it's a unique, engaging way to get communication across. If he had written that hypothetical book...I never would have read it.)

Another way in which we communicate is to guide the player into having the experience we want them to have. Zelda's pieces-of-heart rewards exploring and puzzle-solving, for example. Tony Hawk rewards busting mad tricks and getting huge air. We must be extremely careful with this technique, as what we consider a reinforcer may actually not be, like in the famous experiment where kids were rewarded for drawing and the next day ceased their creative activities. I did not explore much in the latest Zelda.

Which brings me to a final point; behavioral psych, at its origin, is simply this: watch behavior; change stimuli; watch behavior again. Which is what all game designers should be doing: watching people play the game, changing the game, and repeating the process. (Until you run out of time and have to ship.)

So, while I agree that using these techniques to make a game addictive may be bad game design--my wife has finally overcome her Animal Crossing habit, thank God, I thought I was going to need to arrange an intervention--let's not throw them out altogether. You wrote a good, useful article.

Warren Spector's speech, what Greg Costikyan calls the "Don't worry be happy" speech, is available at Gamasutra. I, myself, liked it, but hey - I'm working on a sequel *and* a license. We're taking some fairly big risks this time around (last time around just trying to port an engine to three consoles and make some original content in eighteen months seemed like risk enough) and I'm scared as hell but Warren says that's a good thing. Maybe tomorrow I'll worry less and happy more.

Jamie Test, Step 8

Let team members estimate their own schedules

I really don't have much to say about this that Joel Spolsky and Erik Bethke and Steve McConnell didn't already cover.

I have a friend who has a friend who is working on a high-profile game who is afraid that they don't have enough programmer bandwidth to complete their feature set. I say to that friend: "A Hobbit Can Contend With The Will of Sauron." If you are at a company where they do not ask you to estimate your own schedule -- and in my opinion even asking something like "Do you think you can get this done by Friday?" counts as not asking, because programmers are notoriously underconfident in their estimating abilities and would rather pass the responsibility upstream -- then find some time, either on a weekend or when the boss is not looking, to write down a list of everything you have to do before you ship, and estimate how long each thing is going to take. Then add the various buffers Joel suggests in his article. (25% debugging, 10% unplanned features, etc.) Then compare your results to your project's "alpha" or "feature complete" date. You will probably find you're Not Going To Make It. Take those findings to your lead and ask to have features transferred from you to the other programmers. Recommend that you have the other programmers do the same thing, to make sure that they're going to make it. You will probably find that none of you are Going To Make It. At that point, reccomend that they ask their publisher for a) More Money, b) More Time, c) Less Features, or d) some combination of the above.

Your lead won't want to hear it. He may say something like, "How do *you* know this is how long it will take?" He may say something like, "I think you're just lazy!" Remember your people skills. Say things like "I'm concerned about the accuracy of our schedule" rather than "This is fucking bullshit!" (I'm not very good about this, myself. But I try to save the bullshit-calls for emergencies.) How you handle this conversation could mean the difference between saving the project and ruining it. If he's a Good Lead, he won't kill the messenger, and will take your advice, and possibly save the project. (Peter Drucker says good leaders are secure enough in their leadership that they foster disagreement among their 'followers'.) If he's a Bad Lead...then I don't know what to do next. Maybe you can go over his head, or maybe your team has a way you can give feedback anonymously.

I've never been in this exact situation myself. I have been in the situation where I was handed a project--I was the only programmer--and the first thing I did was come up with estimates and it turned out we didn't have enough time. I immediately told the producer, who happened to be a good friend of mine who got me the job in the first place. He asked me if I'd be willing to put in overtime and I said no. They accepted that and threw more money at the project. Later, when an unplanned feature cropped up, and the code I'd have to be dealing with was cryptic stuff from another dimension, I flatly refused to add the feature. The boss himself came by and asked me if I'd reconsider. Here I was more stubborn than I should have been: I didn't even give them an estimate. I said it was impossible. Honestly, given some amount of time, I could have solved the problem, and once I told them that amount, they probably would have agreed that the bang wasn't worth the buck. On another project with the same producer, we were in the last few weeks and I realized we weren't going to make it. They found another programmer and together we managed to break Brooks's Law and finish on time. And there have definitely been times were it seemed like upper management was trying to push my team around and I pushed back. (Probably could have handled those times better.)

The thing is, times were different then. Game programmers were in short supply or high demand, I'm not sure which. I didn't have to worry about finding another job. If I had to (and it never did come to that) I could have voted with my feet. These days, with the major publishers' ubiquitous mantra of "fewer better games" it may be tough to land that next job. So don't be as reckless as I would have been. Make a sincere effort to institute change, don't flip out, and, if your effort fails, send out your resume. (But be careful about it. There's only a few degrees of separation in our industry. There's a good chance that the person you send your resume to is friends with someone on your team! And your headhunter does not care! Very few people at Treyarch send out their resume without me finding out about it.)

A hobbit can contend with the will of Sauron.

Jamie Test, Step 7

Fix Bugs Before Writing New Code

This is the central theme of Steve Maguire's *Debugging the Development Process*, the first book on project management that I ever read. You never forget your first book on project management. It is also straight off The Joel Test. Go there if you want to find out why you should fix bugs first.

I'm here to tell you, in the games industry, most people don't seem to know this. There's a misconception that alpha is the time we fix bugs; up until then we write features, allow a few bugs to get in, and when we hit alpha we fix them all. You'll hear various specious logic about why to skimp on the bug-fixing, such as, "If I take time to fix the bugs, I won't get this feature done on time," and "There's always more bugs! If we tried to fix them all, we'd never be able to write any features!" This is complicated by upper management wanting to see visible progress all the time; they notice when you get the lens flare in, but they don't notice when those fall-out-of-the-world bugs stop happening.

But blaming upper management is too easy. The real problem is us; we hate finding and fixing bugs. We'd rather stick needles in our eyes. It drains the life out of us. It's Sisyphean; every time we fix a bug, two new ones seem to show up on our lists. So we're all too happy to agree when a manager says, "We need to get the minke in there by Friday," because that means we can stop trying to find whatever damn bug we're supposed to be finding, and actually write some new code.

The problem is further complicated by the general pattern which we do things: we code a feature, we check it in, we start on a new feature. While working on the new feature, bugs get reported about our last feature. So we've already broken the "Don't write new code before fixing bugs" rule.

So: how do we do it? How do we change our team so that we fix bugs first?

For what it's worth, here's my advice. Take this advice with a grain of salt, because my team is far from exemplary when it comes to getting those bugs fixed. With our last project, we found at least six thousand bugs (eighteen thousand if you count duplicates) during the alpha phase. That's six thousand bugs that probably should have been found and fixed sooner.)

1) Be flexible in your scheduling. Joel's scheduling system has flexibility built into it. Milestone schedules do not. If you do milestones, then an important criteria for a succesful milestone should be no bugs. It's well-nigh impossible to do zero defect milestones on a monthly basis, IMO; Microsoft's Visual C++ team did them quarterly. Schedule at least 25% of your time for bug fixing. Slip features on milestones rather than slipping bugs. If management pushes you around for not meeting targets, push back.

2) Track bugs from the beginning of the project. Don't wait for it to go into testing. This seems brain-dead obvious to me but a lot of teams don't do it.

3) Have testers from the beginning of the project. If you don't have testers, do the testing yourself. Set up a system where anybody on the team can submit a bug. Schedule time to do testing.

4) You still need to perform triage on your bugs. (http://www.joelonsoftware.com/articles/fog0000000014.html) If you fix every problem everybody has with every feature, it is true; that feature will never be finished. Somebody has to ask themselves: "Could we ship this bug in the box if we had to?" If the answer is yes, the bug goes on the low-priority list, where it doesn't get fixed until alpha. Which means a lot of cosmetic bugs - or graphical glitches - or game design flaws - are high priority bugs that must be fixed when they come up, unless you're willing to ship them.

5) Make sure everyone on the team understands that if they have bugs on their list, they are supposed to stop what they're working on and work on those bugs. This will not make them happy. The knowledge that they're increasing the likelihood of shipping on time is little consolation.

6) Make your asserts fatal. The team will come to a grinding halt when a bug is introduced. Believe it or not, this is a good thing, because people fix their bugs in a hurry when others are waiting on them.

One thing we've tried that Does Not Work is code reviews or inspections. "What?" you say. "But in *Rapid Development*, Steve McConnell said they were the cooler than unit tests! You must have done them wrong!" Honestly; we did it by the book. We read both Glib and Weinberg and instituted a formal policy. We counted the number of stop-shipment bugs we found. By our estimates, the time we spent doing the inspections was greater than the time we would have saved fixing those bugs later, when they popped up. (Although we were counting just coder time when making the estimation. The cost of bugs to producers and testing may have made inspections worth it.) It is my feeling that inspections were something that was more useful when languages and compilers were more prone to letting bugs get through; now that we have automated warning messages and higher level constructs and asserts and the like, inspections don't catch that much. Inspections are also good for enforcing coding standards, if you really care about that kind of thing. I'll say this about inspections; although they didn't help they didn't hurt. The main reason we don't do them anymore is because we didn't get processes in place to make them more automatic.

You might ask, "Once we're fixing our bugs first, why bother having an alpha at all? Why not just add zero-defect features all the way up to our final ship date?"

I found on my last project that even with ruthless fixing-of-bugs-first, even with in-house testing, we still had more bugs than we could handle post-alpha. But supposing the system worked as intended, and you hit alpha with no high-priority bugs. Then you're a big fat winner. You can now spend the next few months fixing low-priority bugs, polishing gameplay, even introducing low-impact features, and acheiving a level of quality rarely seen in the videogame world.

Of course, if anybody has more ideas on how to keep the bugs down, I'd love to hear them.

We take videogames seriously

We just pooled our money to have Chad Proctor drink a cup of "Special Garlic Sauce." He didn't throw up. These things happen during E3 crunch.

We've been playing a lot of Universalis lately. No, it's not a computer game. But I've had a hell of a lot more fun playing it than I have had playing computer games lately. I'm becoming addicted, in fact. It sounded like a dumb idea when I first heard about it; "You tell a story together?" I assumed it was bound to end up with results like this. It turns out that the game provides enough structure to usually prevent that from happening. (We've played half a dozen times now and only once did the story completely derail. And we still had a good time.) And as long as there are enough people playing with enough ideas to keep things rolling...(five seems like enough; four is pushing it)...it's great stuff. It's the Karaoke of storytelling; the narratives we've produced would probably be pretty painful for anyone else to hear, but the enjoyment we got producing them was much greater than the enjoyment we'd typically get from being on the receiving end of mass market narratives. (I admit it. I like Karaoke. I used to think I was too cool for it, but I'm getting old.)

I've written a few reviews on game design/development books here. I covered Erik Bethke, Richard Rouse III, and Roger Pederson.

God damn

Would somebody other than me post to this thing? It's easy. Pretend you're writing e-mail to nobody.

Added some more to the Game Design Wiki. http://www.ludism.org/gamedesign/SaveGamePatterns. To quote Justin Love, the founder: "Yah! A second person ;^) (I was kind of hearing crickets myself)"

Hey! I fixed the archives! I'm not sure how!

Think I'll play some Kohan.

I asked Noah Falstein how I could contribute to the 400 project and he said to e-mail him. Naturally that was dissatisfying. I wanted to see my contributions, rather than feel like they were sucked up into some void. It occurred to me a wiki was the answer. Maybe I should start one, I thought. I tried starting one at Treyarch, and after a small burst of activity...crickets. Maybe I should start one on the internet, I thought. Maybe there's already one there. I did a search. There was. Coolness. A little rough so far, and intended more for board games than computer games, but with a little love... I've already started contributing.

More notes on Zelda

You know, as frustrating as Mask of Majora was for me, it did what Wind Waker failed to do, which was take gameplay in an innovative new direction. The holistic groundhog day design of it, where you have to keep time-travelling back to the beginning of the cycle, with new knowledge and new abilities, was really quite genius, although it was frustrating as hell when you were only halfway through a dungeon and time ran out.

I was pissed that Mask of Majora only had four dungeons, though. For me, Zelda is all about the dungeons. But I guess it isn't for everyone else. Which may point out a problem with the whole Zelda line: does it have a focus? Could you pin Shigeru Miyamoto down and ask him, "In one paragraph, what is Zelda?" Just a thought.

Notes on Zelda: The Wind Waker

Normally I try to objectively study game design with these "notes on" articles, but I don't know if I'll be able to pull that off this time. I don't know if it's because I'm getting old, because my expectations are too high, what, but I found the new Zelda to be disappointing. There was a little of the sense of wonder and awe that I got playing Link to the Past and Ocarina of Time (which I took notes on here), but certainly not as much. It was less difficult; I consulted gamefaqs three times, and two of those times I should have figured it out myself; and although I was pleased that it wasn't frustrating I felt a growing sense of dissatisfaction at the ease of the puzzles. The "Zelda moment", those moments where the answer to the puzzle becomes clear, were not giving me the same joy they usually did, I think because most of the puzzles I had either seen before in previous Zeldas, or were too easy. The insanely complex water dungeon of Ocarina required me to go to gamefaqs twice, but I enjoyed myself, damnit. That reminds me of something Meretzky said in Richard Rouse's book: he argued that it's better to be too hard than too easy, because people can always look up hints if it's too hard (which should be even more true now than it was back then, with gamefaqs) but they have no recourse if it's too easy. But it seems like since the beginning of time, game developers have been going the opposite direction, trying to make the games easier and easier to alienate fewer people. They run the risk of alienating the hardcore gamers, which some would say is a bad idea, arguing that the hardcore gamers are the hubs who spread word of mouth, but I don't know what evidence there is that the hardcore (early adopters) tend to be the same people as the hubs (those with lots of friends/acquaintances).

An additional design flaw that jumps out at me immediately: a lot of the game is sailing. This violates Mark Nau's "terrain is important" rule, and despite the various things they put in the water to try to make sailing interesting it was ultimately a failure. Beautiful and breathtaking for a few minutes; dull for the rest of the game. A world of rivers running through canyons with waterfalls, jumps, and caves seems like it would be obviously more fun, to me. The sailing is technologically impressive; a seamless, continuous ocean dotted with islands. This may be an example of the advances in technology creating more opportunities for boring games. A treasure-hunting mode that essentially boiled down to Fed Ex missions did not save it.

The sailing is tied in with the narrative which is the strongest of a Zelda game yet. The island world reminds me of Wizard of Earthsea; the story of Zelda and the Hero of Time returning in successive incarnations reminds me of Moorcock's Eternal Champion. The narrative had a weight to it that I don't think I've seen in another game, giving my actions a certain heroic something; I almost felt as if what I did meant in the game world meant something. (Somewhere I saw an article discussing Joseph Conrad and Link to the Past but I can't find it now. It must be relevant, somehow.)
So what, besides sailing, was added to the new Zelda?

The two game elements that I had not seen in a previous Zelda were the Grappling Hook and the Song-Of-Command. The first was a third person version of the grappling hook from Metroid; the song-of-command allowed you to control an ally in the dungeons, and that was the one thing that really opened up some new puzzle possibilities: your ally had a different set of attributes then you did, and you would have to use your powers and their powers in concert to advance. I just wished there was more of it.

Combat was much more engaging than the previous Zelda. They added a new 'parry' move that you could only use if you weren't blocking; I found myself abandoning my strategy of keeping my shield up, because I wanted to get those tasty double-damage parries in. Some of the enemies were resistant to most attacks except for the parries. Some of their attacks could be parried and some of them couldn't, so I would have to watch closely, guard down, to see what kind of attack was coming and either parry, block, or get out of the way depending on the move. Simple but effective. Not very deep (I didn't get much better at it by the end of the game than I was in the beginning) but engaging. Also, the previous Zelda would rarely have more than one enemy attack you at the same time. The enemies would mob you in this Zelda, and you would have to jockey for position to not get hit. (And sometimes you could encourage them to strike each other. Good fun.) (And the bosses are less silly than the last couple games.)

In my article on Ocarina I wrote that I didn't understand why they actually made you play the Ocarina. That was the intellectual gamer in me talking. I'm reversing myself. Fact is, actually getting to play the instrument (it's a baton in Wind Waker) is toyetic. (Toyetic means "like a toy" and it's a good thing.)

The illusion of nonlinearity: there was a moment in the new Zelda where it seemed like you could choose which of two dungeons you would get to explore next. It was so convincing I saw a note on Gamefaqs say "You can do these in any order." It is not true; a key NPC is not available until you've completed the first dungeon. I felt slightly betrayed; I have no problem with controlling the line which the player takes through the game world, but to open up two dungeons, implying that you can do either, when you can't...it's like..."psyche! For a second there you thought you weren't on a rail!"

One last thing: since Ocarina had a hold-the-button-down camera lock on and Majora had a toggled camera lock I was really interested in seeing what Nintendo finally went with for Wind Waker. The answer is they didn't: it's configurable in the options menu. That's right, Nintendo caved and for the first time I can think of, let the player decide instead of actually making a choice. For a rant on options menu that may or may not apply to game development, look here.

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.