New blog has launched

I am now blogging here: www.gamedevblog.com. Come one, come all.

Happy Birthday To Gamedevleague. Death To Gamedevleague.

That's right, one year ago today, the first post to Gamedevleague appeared.
Over that time, the readership went from around 10 hits a day to 150, and then hit a plateau.
I've learned a lot in the last year. I've learned that there's already a word for emergence and it's...emergence. I've learned that I'm not alone in thinking that Zelda's sailing sequences were not fun. I've learned that automated scheduling systems are no substitute for human attention, but I didn't learn that from this blog. I've learned a lot about marketing. I've learned that I like section headings in a small font better than in a big one. And I've learned that typepad seems to be a better source of blogness than blogspot. (I never learned why some of my posts have spaces between the paragraphs and others don't...)
As the hermit crab grows it must migrate to a new shell. Before I was blogging here I was blogging there. Even though only a few of my closest friends read that old one, that makes me one of the industry's oldest bloggers. And now I'll be blogging somewhere else. Details to come.
Since I'm home sick today, now would be a good time to migrate. I've been holding off, because, being a managerial type I like arbitrary milestone dates like "one year from today", and seeing the blog go a whole year seemed cool. And it was cool. It is cool.

More on cross-training

A web developer named Christian Mogensen had this to say:

I'm not a game developer, but I've seen the same problems you have. At my first job, a web design shop called vivid studios in San Francisco, we did quite a bit of cross-training because it made us more flexible, and it promoted understanding across disciplines.

Graphic artists began to understand why the programmers liked certain solutions better than others, and they could thus change their output to better suit the programmers. Vice versa, the programmers could tweak the odd broken gif if they knew their way around photoshop.

I (a programmer by training) actually ended up training my managers in the mysteries of McConnell. (They were all typical web "producers" - amateurs with experience and little training) That was training well spent! If your manager is clue-impaired, give him more clues! :-)

The efficiency/execution-time gains are a plus, but there are second-order effects that give you a further boost as people adapt their work using their extra knowledge of what the other side needs.

Oh, and of course cross-training improves your bus-coefficient (how many people can be run over by a bus before your critical path halts?)

We didn't have a formal training program for artists, it was more about having an atmosphere where cooperation and training "in the moment" came naturally. So when there was a problem, the engineers would walk the artists through an issue. So over time the artists understood what the engineers were talking about. Vice-versa, if you hang around graphic artists all the time, you're not going to avoid picking up some photoshop skills.

Engineering did have a formal training program (readings from Code Complete and such-like) and an artist would occasionally show up for these. The artists would take us along on field trips to the Moma or the Exploratorium. It rubs off on you...

One Of My Sacred Cows Is Dying

A new Manager In A Strange Land is up, after some technical difficulties.

My wife is back from Long Island. Thank God. I've gotten really used to having her around.

Put in an 80 hour week last week. Been a while since I crunched that hard - over a year, at least. I don't recommend it.

And now for the main course:

Once, I was very into "brittle" systems - Chuck Tolman's term, I'm not sure if that's the official software engineering name for it - the idea being if somebody did something wrong it would break. Have fatal asserts, and don't bother checking if a pointer is null and failing gracefully. "I say let 'em crash!" It helps Catch Bugs Early, because when somebody can't work he goes and drags a programmer to his desk to fix his problem NOW. And catching bugs early is a good thing. I indoctrinated the team with this attitude, and it seems to have paid off - we shipped our last few products on time, and our current, most ambitious, project seems pretty solid, generally soaking for an hour or two before it crashes. (Side note: I've noticed this happy thing about fixing crash bugs - as you fix them, the soak time of your game increases exponentially. Your game crashes after a minute. You fix the bug. Your game crashes after two minutes. You fix the bug. Your game crashes after four minutes. Etcetera. Then it's people - one out of two people who play the game all the way through see a crash. Then one out of four. Then one out of eight. At this point, testing is too slow to find the remaining crash bugs. You ship a product which crashes at least once for one in eight people. You live with it.)

Still, others have shipped games without this attitude. David Cook of Triple Play and Kelly Slater likes skippable, nonfatal asserts. Chris Carollo of Deus Ex likes them too. And I have to admit, this attitude has its warts. Just yesterday I was fixing a dereferenced null pointer. The programmer put in a fatal error before the dereferenced null, but did not handle the null case. The error was that the wrong kind of icon was being displayed over the head of a certain entity. This wrong icon was displayed for a single frame while the screen was black. Our code was incorrect, and the fatal assert caught us. But is it a bug if the end user never sees it? Which ties in with my bitching about test driven development. What percentage of the time do the tests catch non bugs? Although it's cheaper to fix a bug if you catch it early in the lifecycle, is it really so much cheaper that it's worth the cost of false alarms going off in the code? (I'm sorry, but I think those numbers about it being 100 times cheaper to catch a bug at design time than in beta are fallacious. I'll accept several times.)

Thing Two: a few days ago I demanded that we make our sound system robust to missing sound files, just like we made our graphics system robust to missing textures. There was a painful chicken-and-egg problem with sounds - here's the lifecycle of a sound asset on our project:

- mission designer requests sound
- sound engineer adds sound to the database, submits
- mission designer syncs, adds sound to mission script, submits
- sound engineer rebuilds all sounds in the game (this takes about an hour), submits. (this involves over a gig of data and brings Perforce to its knees)
- mission designer syncs, tests to make sure the sound is okay

If this process was done out of order the game would crash due to the missing sound asset.

And as fast as Perforce is compared to Sourcesafe, whenever we do a sync we usually have to recompile and rebuild a ton of data, which can take anywhere from a few minutes to half an hour.

Are you feeling our pain yet?

Now, once we slaughter my sacred cow, and force the system to be robust to missing sounds:

- mission designer requests sound
- sound engineer gives mission designer a filename in e-mail
- mission designer adds sound to mission script but doesn't get to hear it yet. submits
- sound engineer adds sound, rebuilds sounds, submits
- mission designer syncs, tests

We've gone from four handoffs to two.

So, after all this, I would revise my philosophy. First - don't settle for brittle. Go for Steve Maguire's "Brittle & robust." Whenever you add an assertion, also take the steps to make sure your system will survive when that assertion fails. Second - some things should be warnings, not errors. Missing textures and sounds should be warnings. Third - at the beginning of the project, fatal asserts are good: they keep your development on a leash, they keep you slow and steady, they make sure you take the time to do things right. But at the *end* of a project, when you need to fix the high priority bugs, and triage dictates that you should ship the low priority ones - let the asserts be skipped. Because those asserts may be just confusing your priorities - you have real crash bugs to fix, and these asserts are often firing on things that are cosmetic bugs...or not even bugs at all.

Case Study in Line Extension

And it's back to marketing, speaking of no focus.

I just checked out the Secret Weapons Over Normandy post-mortem in the latest GD and #5 on the What Went Wrong caught my eye: they had trouble getting the word out that this Secret Weapons was more arcadey than the last one, and apparently some people aren't happy with its arcadey-ness.

One thing Jack Trout and Al Reis would say (this from *the 22 Laws of Marketing*) is that line extensions give you a short term gain for a long term loss. In other words, by taking the Secret Weapons line of hardcore flight sim and trying to extend it into an arcadey console market, LucasArts will sell a few more copies at first but pay for it later because nobody will know what Secret Weapons means anymore. Jack & Al would probably argue that it would have been better to create a whole new product line than try to ride on the success of previous titles. In other words, the difficulty with product messaging started with the very name of their product. If they wanted to avoid misconceptions about the title, they should have simply named it something else, and their #5 What Went Wrong would have gone away.

I'm making it out to be worse than it is - now that Totally Games has jumped with both feet into arcade-flight, they can stay there and build a happy home. (As long as they stop doing hardcore sims under the Secret Weapons name.) There have been examples of titles that used to mean one thing but now mean something else - although no really good examples are coming to mind right now, there was a list of them in *Positioning*...

But if they try to keep both markets then they'll end up with a weak brand.

Getting into marketing is kind of depressing for us developers because usually all we can do is hope our publisher's marketing department doesn't screw it up...

Tired

Thanks for the compliments in the comments, guys. I haven't updated in a while because I've been crunching full time these past few days. Wake up. Get latte. Go to work. Come home. Sleep. Wife's out of town, good excuse to make...game...better. But I've definitely hit a point of diminishing returns...those extra hours just aren't all that productive.

The love affair is over

It's been a while since I've written about coding. Scott Miller told me recently that I could increase my blog readership if only I'd focus, but I just can't seem to stick with one discipline. With game development in the state it's in today, this is okay, as I discuss in the latest Manager In A Strange Land.

So I'm going to write about coding!

I think it was item 50 in The Pragmatic Programmer that said, "Learn a text processing language." I chose to learn some perl, and after I had learnt a sort of pidgin perl I was thrilled - I took on some rudimentary text processing tasks for people in the office (turn this screenplay into a .csv file, rename all the files in this directory) and was impressed with how easy it was to do these tasks. Then I took on a nontrivial task (compare this file with these three files and n sets of directory listings to make sure they match) at which point I required arrays of arrays and the language turned on me. Like the time I dated a hot girl who turned out to be a recovering junkie, what started out great turned into a nightmare. Most popular perl idioms are completely alien to my brain, which has been thoroughly indoctrinated in the structured programming ways of C. Operators that also set the values of global variables...regular expressions which compress a ton of functionality into a single unreadable line of garbled punctuation...defining functions as you need them in the middle of a line of code...arrays of references of arrays...

500 lines of code (a real perl programmer could probably have done it in 50) and a few days later, I did complete the task...and if I had to do it again, I'd still use perl. But the magic is gone, and I wouldn't use perl for anything except text processing. Our automated build scripts are in perl, and I don't like it.

disappointment #2: test-driven development.

I've been trying harder to write more unit tests, eagerly awaiting the time when one of these unit tests is going to catch a bug. I've maybe written a couple dozen of these things. Although they've been useful in helping me write the code correctly in the first place, they have yet to flag bit rot. Just as an example, there's a train that follows a rail in Spidey 2. I wrote unit tests to exercise the follow-the-rail code, and left them in the code to make sure nobody broke it. Recently, we changed the train model, and had trouble exporting it from Max to spec. So I gave up and changed the code to work with the new train. This broke all my unit tests. But now it was the tests that were wrong - not the code. I'm thinking it's likely that most of the time a unit test fires, it's because the assumptions it's asserting are no longer true. I'm not giving up on unit tests yet -- mostly because I get coder-pleasure from writing them -- but they have yet to truly prove their value to me.

Hey, how about that!

There's actually a page there, now, at least. I'm now 99% sure it does work.

I have no idea what I'm doing

Installing NewsMonster on my desktop machine destroyed Mozilla so deeply that uninstalling and reinstalling it didn't bring it back from the dead. I still have my laptop...but I'm not trying that again. So I am without a way to test if this "atom feed" thing actually works. I'm 99% sure it doesn't, but you might try:

http://gamedevleague.blogspot.com/rss/atom.xml

Let me know if it magically works. I'm going to assume it doesn't, and give up. I'm going to switch to typepad soon.

Feed

Okay, I just attempted to turn on the RSS feed. Could somebody tell me if it worked? I don't actually use a newsreader, myself.

More Notes On Deus Ex: Invisible War

I've found I can alt-tab between DX and my blog. I'm on my second playthrough, seeing how far I can get on hard without killing anyone. (Side note: this is an example of metagame. The game itself gives no recognition for pacifism, the way Ultima IV or a Bioware game might.) So, in no particular order:

* Crates have glass lids. You can look inside and see if it's worth spending a key on, before you waste the key (AKA multitool). Escapes the necessity of a quicksave. Very clever.

* I think games like Deus Ex and GTA3 are what lead designers and publishers into thinking their game has to do it all. A couple of particularly unfocused games came out of Activision last year: True Crime and THUG, and I think the rationale behind the designs was, "GTA did it." The thing designers should remember is that this lack of focus is the focus of these games. Deus Ex is all about choice and GTA is all about freedom, so by necessity they have to be toaster cars. But if your game is about skating, keep it about skating. I stand by what Mark said earlier in the blog: no toaster cars. Another example of the "toaster car that works" is Halo, famous for adding vehicles to the FPS. A couple things to remember there: Halo had such a long dev cycle that they had the time to make two games in one, and the driving has issues - putting FPS controls on driving is very counter-intuitive. It feels squishy and weird. Although it is interesting and satisfying in its own weird way.

* There's (at least) one section that plays differently if you choose a male or female character. Nice touch. A choice with consequences. Which brings me to: consequences. "perceivable consequence" was one of Doug Church's things, and I think what he meant was the player has to be able to learn what the consequences of their choices are going to be, although I've also seen him interpreted as meaning the consequences have to matter. The glass lids on the crates create a perceivable consequence. Choosing a female character in Deus Ex means you have to pay 300 for a key that the male character can get for free. A consequence, but not perceivable. If you don't have some idea of what the consequences of your choices are going to be, the choices are less interesting: you may as well flip a coin. On the other hand, even choices with invisible consequences increase replayability and the breadth of the game space we're exploring.

* More on the "just because somebody else's really cool game has this doesn't mean you have to" front: interesting choices are not necessary for a game. Many, many people consider rail shooters and linear brawlers and DDR good fun. Some people hate linear games, though, and those people can play Deus Ex and Civ.

* Why are there security bots guarding the toxic waste spill on the inclinator, again? To protect people from the toxic waste by shooting them? And how come everybody knows what I'm doing and radios me at just the right time? Can anybody spy on me at will? And if a tavern can send a safety code that turns my gun off, why doesn't a heavily armed installation? These little plot holes were introduced to make the gameplay better - circumventing robots is fun, knowing what your goals are is fun, killing all your vital contacts is not fun (well, it's not fun after the initial thrill wears off, anyhow). I'm willing to concede these points. Call it poetic license.

* Although Max Payne 2 bust Havok's cherry, Deus Ex really lets you play with it, because you can pick things up, throw them, watch them land. This is a mini game all by itself, although it's rare for the physics to create any meaningful gameplay. You *can* trick guards into exploring the wrong area by throwing things, though...

* The story points seem like noise the first time through. You listen to the news, you talk to people, you don't know which faction is which, it's all a bunch of unconnected dots. The second time through things make sense and feel part of an organized whole. It really takes more than one playthrough to appreciate this game, I think.

Quality of Life

There's a "quality of life" survey at the IGDA. I filled it out, but it bothered me. It is not the best survey ever written. For one thing, there were too many multiple choice answers where the choices were all so specific I would have chosen "none of the above" if it was an option. For example, do I work at a big studio with 4 or more projects or a mid-sized studio with 2-3? I work at a big studio with 3. Better to have two questions: number of employees, and number of projects. Another thing: I checked the box for "my friends and family think I work too hard and want me to spend more time with them" but my wife would think that even if I worked a forty hour a week job. (She's going back to work in February, though, so there'll be some more slack in the near future.) And sure, I seem stressed out all the time. But that's just my pessimistic nature. And no, I don't think I'm paid enough. But who does? And no, I don't look happy. But I am. Really. And yes, everybody here is involved in the crunches, whether they want to be or not. I personally think that's a good thing. (I talk more about it in my latest Manager In A Strange Land article.) And yes, we're too god-damned ambitious, and it means we always end up cutting and crunching...but that's our own damn fault. It's not like upper management is breathing down our necks and saying, "More! More!" Basically, this survey is going to make us look more miserable than we really are.

Do Me A Favor?

I was talking to Chance Glasco the other day - he's been doing some pick-up work for Treyarch on a really cool project TBA, and got some of the Call of Duty story from him. The real impressive part of the story is this:

- 23 developers

- 18 months

- 92% on Gamerankings.com

This alone would put Infinity Ward in the bang-for-buck hall of fame along with Factor 5 and Epic - but they're even more insane than Factor 5 and Epic, because Rogue Squadron II and Unreal Tournament were at least done with their own engines. Infinity Ward had to take the Return From Castle Wolfenstein engine, a totally unfamiliar engine, and run with it. (Of course they replaced the renderer, and many other things, which is a necessary technique for making a great game in a hurry, which I've mentioned a couple of times before.) I can't imagine adapting to someone else's engine that quickly. Also, although Call of Duty is a spiritual sequel to Medal of Honor, I think it shows more originality then the other two bang-for-buck top contenders.

So I'm going to say it. Infinity Ward in the highest bang-for-buck developer of our time. That I know about, anyway. (Although Neversoft is up there, too, there's less innovation in a Tony Hawk sequel than in this.)

Which means...they should win Rookie Studio of the year. Unfortunately, I already filled out my nominations, and I forgot to nominate them. I'm sure somebody else nominated them...but just in case nobody did...could you do it for me? There's only one day left...

Thanks.

In other news, I know my comment system totally sucks big piles of ass. I will switch to typepad one day.

Notes on Deus Ex: Invisible War

Somebody in the comments wanted to see my notes on Deus Ex. We aim to please. I'm going to be biased, though, because the Ion Storm guys are kind of my heroes...even though I never finished Deus Ex, I so admired it, and I admired how much they managed to deliver in a fairly short time frame with not that many people on the team. Hey, I think even they admit that the first Deus Ex was too long...

Choice. Choice. Choice. Deus Ex still owns the word choice. Even more so, this time around: now you have more control over the narrative, and more or less side with whatever faction you want. This may be the first game that really pulls this off. Although plenty of games have alternate endings, usually the endings are based on how many points you get (True Crime, if you count your cop karma as "points") or how well you play (Silent Hill). In Deus Ex, decisions you make affect the story. Decisions you make can even end up in the news. Talk about feeling like you're part of a world. Also, unlike the first Deus Ex, where you were railroaded into siding with the terrorist faction, this Deus Ex leaves it up to you. One of my big complaints about Neverwinter Nights: if I was really evil, then I'd join up with the enemy. Deus Ex makes it possible, in a way. (But what I'm really looking for is joining the enemy and then supplanting their leader and becoming master of evil.)

Another example of the Deus Ex freedom of choice: they have universal ammo. Your ammo magically works in any kind of gun, from a rocket launcher to a poison dart shooter. (Ahh, nanotechnology. Can explain anything.) This was a ballsy, scary move on their part, and I'm sure some of them lay awake at night wondering if it would work. One of the things that makes it easy to make sure your player has to use the entire repertoire of toys you've provided is to have limited ammo. Ratchet & Clank, for example, has two dozen guns and the thing that makes the player try all the guns is because they run out of ammo. But Deus Ex isn't about making the player do anything: it's the player's game and the player can play it however they want. On my first play through, I favored the sniper rifle. I also liked killing with the energy sword and then picking up the dead bodies and hurling them thirty meters into the air. Maybe that's not your cup of tea. But that's okay, you don't have to play that way.

I'm on my second play through now, seeing how far I can get without killing anyone, hard level this time. One great improvement over Deus Ex 1 is this one is shorter, so you actually can go back and experiment with different play styles, and different character advances. Choices are only meaningful if they have consequences: once you've chosen a character upgrade in a given slot, you're fairly committed. You can also upgrade your weapons; once you've made your choice, there's no going back. The shortness of the game allows you to actually "explore the game space" as Will Wright might say.

One of Harvey Smith's things is "orthogonal units". We see this in Deus Ex in a number of places: the enemies are well-differentiated, from the heavily armored Templar trooper--which explodes when killed--to the stealthy Illuminati soldier--who gives off a cloud of poisonous gas at death--to the robots (more vulnerable to EMP weapons than conventional). Color coded trip lasers--gas, alarm, death--different upgrades get you past the different kinds. (Although I usually used grenades.) The player verbs are also orthogonal: sneak, kill, hack, circumvent. Weapons in an FPS are usually orthogonal, and it's no surprise that this game sticks fairly close to the standard FPS model.

People bitched about the demo. This is no surprise, because Deus Ex has to grow on you. Those moments of emergence, when you lead one group of enemies to get killed by another group, or you discover that you can use the explosive crates that are lying around as weapons, or you lure guards away from your target and hide as they run past...because Ion Storm is letting those moments come naturally out of the system instead of crafting set pieces, those moments are rare and precious. It's only after you've had a handful of those moments that its hook is in you and you discover you can't put the game down. How do you demo that?

I played the PC version. Halo is the only tolerable FPS on a console. I wanted my mouse and keyboard interface. I have an okay machine...GeForce 4, 2.4 GHz P4, 512 megs...but it wasn't until I downloaded the patch and turned all the graphical thingies to minimum that I was happy with the framerate. I wonder about Ion Storm's choices, here. Although the beautiful lighting definitely has wow factor, I think players respond on a possibly unconscious level to good framerate. I'm living in a glass house here...once I've worked on a game that manages to maintain 30 FPS I'll have a right to complain.

I'm afraid that Deus Ex is one of those games that teases us and then doesn't meet our expectations. You throw a coffee pot at an NPC and he says, "Quit it." You're impressed. Then you throw a dead body at him and he doesn't seem to notice. It's things like this that made Tom Chick lambast the first one: because this game is a step ahead of the others in the AI department, we expect perfection. Give an inch and we take a mile. For example, it's never bothered me before when an RPG had a handful of irrelevant sidequests. "Great!" I said. "If I want to do a little extra exploring/playing, I have that option. And if I don't want to do it, nobody's holding a gun to my head. And it makes the world seem more rich and detailed!" But this time it bothered me. In the city of Seattle, there are a few sidequests that have almost nothing to do with the main storyline, and I ended up having to do them just to make the money I needed to advance the plot. (Mark Nau calls this, "You're saving the world and you're on a budget.") It's just not exciting to find proof of a nightclub owner's corruption when you're supposed to be getting to the bottom of a global conspiracy. (Actually, come to think of it, the same thing bothered me about Knights of The Old Republic but I hadn't put my finger on it until now.)

Maybe a trick from screenplay writing could help us out here. In the Hollywood formula screenplay, the subplot is tied to the main plot. Take Matrix, for example. The love story between Trinity and Neo is a subplot. The resolution of that love story is inextricably tied with the resolution of the main plot. I'd like to see more of this kind of plot construction in the side quests in RPG's, where they grow out of and tie into the main throughline.

Ending a game is tricky. Zelda has good endings. Metroid Prime had a good ending. Everything else in recent memory?...enh. Most games try to change up the gameplay at the end, give you something different to make it memorable. This leads to things like Xen from Half-Life, the race at the end of Halo, the 'shoot the tiny targets' endings from the two Max Paynes, and a collection of not terribly interesting bosses from many other games. So it seems like sacrificing your core gameplay at the end is a mistake. On the other hand - Deus Ex 2 sticks to its core gameplay - bringing us back to Liberty Island, the starting point of the first game, *awesome* closure, sense of unity, damn good storytelling - and...well...the gameplay feels anticlimactic. Maybe because it's more of the same...maybe because it's a "we ran out of time at the end and had to punt" deal...maybe because none of the choices you can make in the end are very satisfying? One of the endings I saw was depressing, the other -- and I think it was the 'good' ending -- creepy.

Tomo Moriwaki has a rule for final bosses: he says that the whole game is just training for the final boss. Metroid Prime was a great example of this, where your entire repertoire of moves is necessary at the end. But if Deus Ex went this route - in the final level, you had to use stealth AND shooting AND hacking AND so on - it would have violated the spirit of the game. Deus Ex is about OR. I don't know what the Ion Storm guys should have done here.

The first Deus Ex made me realize the value of a continuous world. (Although it wasn't the first to have one.) A little bit of jargon: I would define a "continuous world" as one where you're not artificially constrained. Games which have traditional levels, where you can't backtrack (You came in from this door but now it's locked? - we employed this device a couple of times in Spider-Man 1. Ew.) are not continuous. Games like Zelda, Deus Ex, Quake 2, and Half-Life are. I'd further define a "seamless world" as continuous worlds that have no visible load times: GTA3, Dungeon Siege, Prince Of Persia, Ultima VI, and Metroid Prime are all mostly seamless. The storyteller in us does not like continuous worlds! The storyteller wants to get to the action, and skip the boring walking around parts. But the game designer loves continuous worlds. The game designer wants to immerse the player and give them control. It is wonderful that Deus Ex is continuous. Hopefully the next Deus Ex will be seamless, because the load times were too long.

Oh, and I should mention that the music is excellent. Combined with the lighting, it feels like you're in Blade Runner.

I ended up bagging on the game a lot more than I intended to. It's easy to find fault but hard to put your finger on those intangibles that make you want to keep playing. I'm especially culpable because these 'notes on' articles I write aren't supposed to be pejorative but are supposed to point out cool interesting things about games. I should point out: this is a very good game. It's like Deus Ex but better. This is the first game in a long, long time that I'm playing again.

Speaking of Dvorak

Been using it for a month and still haven't broken 70 wpm, and my qwerty typing is ruined. I'm paralyzed at anybody else's machine. Which is okay: they learn more if I make them type. Still, so far, switching has been a spectacularly stupid idea. Oh, yeah, and everyone at work makes fun of me. I'll give it...two more months...and if I'm not over 100, I'll switch back.

The Design of Everyday Videogames

Rich Bisso made me read Don Norman's *Design of Everyday Things* and I'm glad he did. There's a handful of stuff in here that applies to videogames. The book really isn't about design in the way I think of it: I think of design as being how to make something look good. When designing in the arty sense, function is irrelevant…that's probably why those graphic design samples have garbage text, so no actual information actually gets through. When a website has a pretty, well-composited layout, I think of it as being 'designy'.

What the book is about is usability. And for geeks like me, that's more important than design.

But rather than make you read the whole book, I'll cover the essentials right now, quicklike.

1) Affordances: a handle affords pulling. A knob affords turning. A plate affords pushing. Some ways this can apply to videogames: you have a gate operated by a switch. Make it so pushing the switch up raises the gate, and vice-versa. It applies to the controller as well. Which button should be the jump button, and which crouch? The button at top should be jump, and the button at the bottom should be crouch. Unfortunately, this violates another, more important usability rule:

2) Don't fuck with conventions: at this point, so many games have put their jump button in the same place that it is foolishness to violate the convention. There's a little demon in us that makes us want to be different for the sake of being different, or marginally better. Ignore that demon. Don't try to make people learn Dvorak when they're happy with Qwerty. A good example of doing this right is Simpson's Hit And Run. I could pick that game up, and my Grand Theft Auto skills translated perfectly. (On the other hand, although True Crime changed things around, it was pretty clear they had to in order to express the game's additional complexity.)

3) Knowledge exists in the world. Each key on a keyboard has a label saying what it does. Nintendo does this excellently with their games, often having an iconic representation of the controller right there on the screen. (The water nozzle in Mario Sunshine, the usable items from Zelda. The tutorial points of Prince of Persia work similarly, giving the player the knowledge they need when they need it. Having a controller layout accessible from the pause menu is a workable alternative, sacrificing usability for designyness.

4) People are intimidated by a large number of controls, but it's much better to have a control-per-function than to try and compress many functions into a single control. A particularly bad example would be to have a button do one thing when you tap it and a completely different thing when you hold it down. Peter Molyneux got this absolutely wrong when he went from Dungeon Keeper to Black & White. The large number of icons in Dungeon Keeper intimidated people, sure. So he concealed an even more complicated functionality in an invisible interface: less intimidating, yes. More usable, no. With console games, we frequently have more commands than buttons, so we're tempted to use chords and modes and double-taps to express the additional options. A good move is to put those extra options on the D-pad, like Splinter Cell does. And how do we avoid the intimidation factor? Make the new commands available slowly, after the player masters the ones you've already given them. (Side note: I've occasionally gotten into arguments when working on RPG's about whether we should make unavailable menu items greyed out or invisible. The answer: before they're introduced they should be invisible, but after the player knows what they are and is no longer intimidated, if the option becomes unavailable for whatever reason, then it should be greyed, which says to the player "This option isn't available right now, but may become available again at some point in the future." And if you really want to put some knowledge in the world, let the player choose that option anyway, at which point you can put up a dialog box explaining why the option isn't available.)

"Wait a minute, Jamie," you say. "What about the transition from Ultima V to Ultima VI? They went from having one control per function (each letter on the keyboard did a different thing) to a streamlined iconic interface where there were only a dozen or so controls! And it was clearly better!" They did an interesting thing here, where they abstracted several different commands (such as 'unlock' and 'open') into one abstract 'use' command that does the appropriate thing depending on context. This is another avenue you can take: instead of finding more buttons, reduce the number of verbs. Which is not without its drawbacks: suppose you abstract Punch and Kick into one Attack button, which does a punch if the enemy is close but a kick if he's far away? You've taken away some of the player's opportunity for choice. (But it's probably worth itÂ…in both Neversoft and our Spider-Man games, for example, the punch and kick were virtually identical, giving the player what they would eventually discover was a meaningless choice. Better to use one of those buttons for something else, something orthogonal. A defensive button, for example. Oh, wait! We're doing that!)

I think that's it. I'm not doing justice to the book but I do think I've hit some of the most important take-away lessons for game designers.

Something New

I erroneously said in the latest Manager In A Strange Land that Half-Life took three years to ship. Jay Stelly just wrote me to say it was actually two years. I was skeptical - it sure felt like three years. What he had to say:

The source code has comments in it for the first lines being written
October 24, 1996. So it was just over two years between first line of
code and shipping. I wasn't at Valve back then, so I can't personally
confirm that date, but I believe the comment is accurate.

For what it's worth I didn't come to Valve until May 1997. Marc Laidlaw
(our writer) and myself started the same week. The core team was in
place by that point, but there were a few hires in mid-late 1997 - and
Yahn Bernier (who wrote most of the game's front end as well as lots of
the networking) didn't start until Feb '98. We haven't added anyone to
the Half-Life 2 team in a while (other than people who were already at
Valve pitching in to help out on some things).


Also, he says the cabal process is still alive and well and they still use it.

In other news, I saw a trailer for Sky Captain And The World Of Tomorrow last night before a second Return Of The King viewing and I was blown away. Somebody in Hollywood has balls. Just as I was thinking, wow, what amazing art direction, how fantastic, I bet I'm one of the only people in the world who would actually dig this movie, the guy behind me in the theater said, "That looks dumb." Apparently this is Jude Law's pet project or something: that's why they can make a movie that seems so very unmarketable. But remember how I said a few days ago that with enough millions of dollars you can make anything cool? This is going to make retro-barnstorming-action (at least somewhat) cool again, and I bet that Microsoft wants to get another Crimson Skies out to coincide with this movie. Microsoft took a big risk by backing this quirky IP, and here comes the payoff: the public eye has just lit upon this kind of thing. Go Microsoft. You win. Did Microsoft know this movie was in production? How could they, however many years ago? Did they find out before they shipped? I could imagine postponing release just to come out with the movie, but it's even cooler to release early to small sales and then have heritage on your side when you release a second product in time for the hype. "This isn't just a Sky Captain knock off. We were making Crimson Skies before anybody ever heard of Sky Captain."

Machinima Tips

To save valuable animator time, we'll have the mission designers script cut scenes using the paltry in-game tools and script language. I did some of this over the vacation, using this advice from James Zachary, our lead animator:
- when two characters are conversing, the camera shouldn't cross the line between them
- it's better to not have the character smack in the center of the screen, but off to one side
- a little motion on the camera is good
And this advice from Cathy Pascual, my wife, an amateur photographer:
- use the 'rule of thirds' to make a pleasing composition. Cut your image in three, and have your subject be on one of the lines, or filling one of the thirds.
- Closer is better. You don't need to have the entire subject in frame: you can achieve good results by focusing on a specific feature of your subject.
- Varying your shots can be dramatic: if your first shot is from below, try having the next shot be from above.
I've learned that our algorithmic tools for placing the camera didn't get decent results: the computer is good at putting your subject in the center and not much else. To make sure I was getting dramatic close ups from interesting angles I had to manually place the camera in the scene myself. Maybe with days of work I could program a camera to fill the frame with its subject and to obey the rule of thirds, but it took me less than a day to manually place the camera where I needed it for my purposes.
Something to remember if you ever find yourself doing some quick-and-dirty machinima.

More on Dvorak

While in Australia, I was drilling for one to three hours a day with Typing of the Dead using Dvorak. I'm getting to the point where I'm not horrible, but I'm nowhere near my old blazingly fast QWERTY speed. What slows me down is mistakes, of which I make two kinds:
- My fingers reach for the old, familiar QWERTY position of the given letter.
And, far more commonly,
- My fingers reach for a key that seems almost random. Sometimes, when reaching for a semi-rare key, such as 'k' or 'f', my fingers will instead go for a different semi-rare key. ('j' or 'y'.) It's as if at some level my nervous system is saying "I don't remember where that particular rare key is, but this is a rare key, so maybe this is it." Other times, it will be the right finger, wrong position.
- My fingers skip a letter. This is weird...I'll be looking at the letter I'm supposed to type, and my fingers jump the gun and hit the next letter in the word.
I've also learned that learning to type is not a fun game. Each day I get marginally better, but it is such a narrow margin that if Dvorak Typing Of The Dead was a game I was playing just for fun, I would have shelved it already.

It's that time of year again

Whoops. Temporarily posted a rough list of my picks for game of the year, 2K3. Fact is, I don't have enough data to do it yet. Still need to play Deus Ex, and Rise of Nations, and Beyond Good and Evil. Then I'll be informed. Unfortunately, the crunching continues at work, and likely will continue all the way until we ship, so I may not get to play these games until May or something. So my top 5 list is going to be very late.

IAB

Two meaty Managers in A Strange Land went up while I was gone. Here and here.

Thoughts on Australia:

The Sydney Centrepoint Tower is way more impressive than the Seattle space needle. I haven't been there since 1990, so I had forgotten this.

It is illegal for the unlicensed public to hold a koala, but we did find an opportunity for my wife to pet one.

Some toilets in Australia have two buttons: one for a half-flush, and one for a whole flush, so you can tailor your flushing to your excretory needs. Ever since I lived there at the tender age of five I've been impressed that Australians don't use the word bathroom or restroom for public toilets but rather the euphemism-free "toilet." When I returned to the States at the age of six I continued to call them toilets until the age of seven when I finally succumbed to peer pressure and reverted to "bathroom." My friend Andy Lloyd shared my disdain for the American euphemism and would often ironically ask a host, "Can you direct me to your facilities? I need to go 'rest.'"