Write a blog, get a free book!

I knew this blogging thing would pay off. I was just sent Game Coding Complete by Mike McShaffry and all I have to do is write a review of it, something I usually have to buy the book to do.
A quick visit to MobyGames shows that "Mr. Mike" has some serious titles under his belt, and in this one case, the adage "Those Who Can't Do, Write" is disproved. (Good thing, otherwise I'd be in trouble.)
First off: I wish I read this book a year ago for the advice on page 560: how to archive your final build. It would have saved my team several man-days.
Second off: this book, like no other I've read, captures what it's really like to be a professional videogame programmer, covering not just some of the basic coding practices unique to games but also hitting asset control, directory structure, resource management tools, middleware, testing, and scheduling. For someone just starting at a game company, it would be a really good way to prepare for what they're about to experience.
Third off: Mike develops games for the PC. If you develop games for the PC, I'm pretty sure this book should be in your library for Chapter 11 alone, where he covers the requirements for getting your Windows Logo. (If only someone could do the same thing for the console manufacturers' technical requirements without getting sued.)
His advice is particularly suited for PC development, but not suited so well to developing for consoles: he's big into templates, and STL, and writing your own memory managers, and cacheing resources, and although he warns against the use of inheritance he dives right down and uses it anyway. All of these things are things which you can (usually) get away with on the PC, but you need to think long and hard about using when you're developing for a console.
Reading this book I can almost imagine why Ultima VII and VIII turned out the way they did; they're imbued with Mike's personality. (Or he's imbued with theirs?) These were incredible, ambitious games, way ahead of their time. But you needed a top of the line machine to run them, and even then you'd encounter occasional performance problems, and bugs. You could just tell, somehow, playing these games, that they were using C++, that the various objects in the gameworld were instances of C++ classes, and there was inheritance and polymorphism going on, and the games both benefited from this practice and paid a price for it.
My favorite setions were the "Tales From The Pixel Mines", where Mike tells war stories from titles he's worked on. Some of them were educational - so that's how Origin used to do things - and some of them were nostalgic. (In particular one on page 449 involving Borland's 3.1 C++ compiler. After reading it, I had to go share it with someone, but I couldn't find anyone around actually old enough to remember that compiler.)
There's a spiel from project management I never get tired of reading. It goes something like this: "Almost all projects come in late and require egregious overtime, but if you plan in great enough detail and schedule thoroughly, you can avoid this." Chapter 13 is Mike's attempt at the spiel, and of course I found myself nodding my head and saying, "Speak it, brother." Then I snapped out of it. Only clones and ports and casino games (I did a casino game once, too, and shipped that one on time also) can really be planned in this manner. If you're making an original game, your plan will not survive contact with the enemy. Mike knows this, and even points out that despite having a schedule, Ultima VII still came in late.
I'm sounding like one of those chaotic, seat-of-your-pants developers right now, and I'm not. A plan is good. A schedule is necessary. Mike's advice in this chapter is all very sound (except when he suggests using Project instead of Excel to do your scheduling) and mirrors the advice of Eric Bethke and Joel Spolsky. (All three of these developers point out that the worker needs to estimate their own schedule. I concur. That makes four of us.) On my project, we're not currently scheduled with the same rigor Mike suggests...but I may just up the ante after reading this.
And some final, random, last comments: he's got a technique for a pseudo-random traversal of a set that's very cool. Pete and Don did this on Magic Candle II to make a sparkly Star-Trek-like teleporter effect and I never understood it. I still don't understand it, but now I have sample code. On the other hand, he's got a template for an "optional" variable for building validity right into a variable that I don't like at all. I'd much rather write a brittle system - fail if someone uses it wrong - or use what he calls the "first dumb method to return an error code" (although I'd have it pass to a pointer instead of a non-const reference. Steve Maguire doesn't think is so dumb) then use his Optional class. On the gripping hand, (yes, I'm a geek) he describes how a resource management tool should ideally work, and I wish ours worked in just that way.
So that's that. Free book earned. If you're making PC games, read the book. If you're making console games, it wouldn't hurt to take a look at it.

Up in San Luis Obispo this weekend, visiting old college friend Lewis Call. His girlfriend recently got a job at Oddworld so she showed us the place and took us to a barbecue thrown by some of the Inhabitants. Had to sign an NDA first, so I'm not going to divulge what I learned. Me, personally, I haven't yet played Abe or Munch all the way through but I really liked them: simple elements combine into interesting puzzles. I admit it, I like puzzles. The very fact that you don't have a gun and you have to find nonobvious, subtle ways to get past each encounter pleases me greatly, much like the people who play Quake "naked". But I think my aesthetic may be in the minority; as Neal Hallford says, one of the most common types of player is the guy who just wants to frag shit.

Visiting postmodern history professor Lewis Call exercises a different part of my brain. Here's my latest half-baked theory: in the seventies and early eighties, the media--particulary movies--portrayed robots and computers as evil, but that changed in the early eighties and nineties. (The change was best illustrated by the transition from Alien to Aliens and Terminator to Terminator 2. Suddenly the simulated human is the good guy.) In the seventies or eighties, the majority had yet to experience the benefits of computers and were afraid of what they didn't understand. Similarly, right now, we see anti-simulation movies: The Matrix, Existenz, Dark City, The Truman Show, Thirteenth Floor, representing the majority's fear of videogames. As more come to understand and accept videogames, we may start seeing films where simulation is good, where people enter the Matrix voluntarily and aren't considered to be betraying their species.

Stuff

Probably blog less in the upcoming months because I'm writing articles for Gama.

Chris McEvoy points out that he also has Game Studies organized in the same way: http://www.usabilityviews.com/gas_by_date.html.

There's a cool interview with Tim Schafer high up on the list.

I owe Mike McShaffry a review of his book; that will be coming soon.

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.