Saturday, March 15, 2003

Notes On Rockstar



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

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

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

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

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

Thoughts On Working On Licenses



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

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

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

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

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

Notes on Jak & Daxter



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

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

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

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

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

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

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

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

Wednesday, March 12, 2003

I Feel Stupid Now



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

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

The Light of Day Brings New Softness



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

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

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

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

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

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

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

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



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

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

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

Is it that not enough innovative games coming out anymore?

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

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

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

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

Tuesday, March 11, 2003

A Better Word Than Depth



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

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

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

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

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

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

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

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

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

Saturday, March 08, 2003

The Jamie Test - Step 6



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

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

Once in alpha, you may want to have some idea if you're going to be at zero bugs on time. You might think you could take the entire bug list, ask everyone how long it's going to take to fix their bugs, and be done. You shouldn't do this, because:
  • The time they spend estimating is time they spend not fixing bugs.
  • DeMarco and Lister have some evidence that programmers work most productively when there are no estimates.
  • According to Steve Maguire in *Debugging the Development Process*, bug fixing is notoriously hard to estimate. (I can vouch for this one: when Die By The Sword was in alpha, I was convinced that I didn't have enough time to finish all the bugs on my plate, and had a lot of them assigned to others. Then I finished my list in record time, and asked to have those bugs reassigned back to me. I might as well have kept my mouth shut.)
  • At any given moment, your open bug list is a small fraction of the long list of bugs that remain to be found and fixed; your estimate is only going to represent how long it takes to fix the current set, not the total.

  • So what are you supposed to use? Strong language?

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

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

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

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

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

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

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

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

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




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

    Friday, March 07, 2003

    Can Do Vs. Can't Do



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

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

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

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

    Tuesday, March 04, 2003

    This Hurts Me



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

    Ouch. I wonder if we even have twenty.

    More On Comments


    Certainly I'm too lazy too comment, and it's nice that Steve McConnell has given me this "I write self-documenting code" excuse for not commenting.

    Still, one man's laziness is another man's cost-effectiveness. I have no studies to back this up, but is it possible that the time spent commenting is not made up for by the time saved by people who come across your code later and try to read it?

    A side note on commenting: I think it's Weinberg who masks off the comments when he reads code, to try to avoid the phenomenon he called "perceptual set": we see what we want to see, and comments can trick us into thinking the code does something it does not. Yet another excuse not to comment.

    Honestly, I do comment, probably around one line of comment per fifty lines of code or something like that.

    It's fairly rare that someone on the team gets on somebody else's case for not commenting. For having the game state spread across dozens of modules and linked like spaghetti, yes, people get upset. But for lack of comments? No.

    Monday, March 03, 2003

    The Comment Holy War


    Occasionally sweng-gamedev gets bogged down with holy wars about coding style or whether to comment or not. I can't resist contributing to the comment war; here is an e-mail I sent to Christer Ericson earlier today, after he put up an obfuscated function--in response to a Noel Llopis claim that writing self-documenting code is better than commenting--that he claimed could not be rewritten for clarity without the addition of comments:

    Obviously this function would benefit from a comment listing the reference were the formula was taken from, but more important than commenting it is rewriting it to use meaningful identifiers. The a, b, c, d, t, p, a1, a2, a3, a4 obviously have to be replaced with clearer identifiers. I grant you that once you have seg1begin, seg1end, seg2begin, seg2end, etcetera, you still won't know *how* the function works, but I'm not sure you need anything more than one line comment that refers the reader to a paper or a chapter of a book for that.

    I assume this function is a bottleneck function and that this obfuscated algorithm is a clever optimization. This is one of the few cases where comments are necessary; if the function was non-bottleneck, you could use a different algorithm that a programmer could read without referring to a mathematical text.

    I could continue to argue Noel's point for him, but the crux of Noel's argument is put most eloquently by Steve McConnell in Chapter 19 of *Code Complete.* You could check it out there.


    Ironically, the comment functionality on this website doesn't seem to work anymore.

    Saturday, March 01, 2003

    A lot of people don't like depth



    A few posts ago I argued for depth in games, but I have to admit favoring depth is my own personal aesthetic. Something I see a lot in people is anti-depth attitudes. These people prefer Canasta to Bridge, prefer Checkers to Chess, prefer Starcraft to Kohan. The reason for this is obvious: people don't like to be punished or humiliated, and that is what happens to beginners when playing a deep game. Kasparov pointed out that chess is a violent sport, your ego is on the line, the loss is personal; when you lose, it is because you are inferior to your opponent. Ernest Adams: "Children's games tend to rely on chance more than games for adults do. It helps to balance out disparities in skill and allows the loser to blame bad luck rather than himself."

    (Side note: when I finally won a game of chess against my dad, when I was twenty, he was quite shocked. "Today you are a man," he said. Or something to that effect. You just don't have moments like that playing Checkers.)

    So what is a game developer to do? You can remove the depth from your game, and be happy that you've satisfied most of your customers. Still, some people, like myself, will be alienated by your game, and even the people who like playing your shallow game will tire of it more quickly than you would like.

    Here are some ideas for solutions, stolen from other games, of course:

    Difficulty Levels

    Or, make a deep game and then have the computer opponent play it extremely poorly at lower difficulty levels. (Does anybody remember the first version of Sargon for the Apple II? Back then, even at the lowest difficulty level, I couldn't beat it.) Future chess programs crippled their AI's extensively, to make a victory possible. I haven't played a chess program lately, but one that was stupid in the exact ways human players are stupid would be fairly rewarding for the chess sandboxer. One that walks right into a fools mate or the classic rook-queen fork, for example. I wonder if somebody's made a game like that yet.

    Difficulty levels only marginally alleviate the humiliation problem. Having to play a game on the easy setting is humiliating. (I was humiliated by Panzer Dragoon Orta, and I'm convinced that's not even a terribly deep game, but rather a game of memorization.)

    If you suck, you win. If you're good, you win big.

    This is the Tony Hawk method. It's not trivial to start skating around and feel marginally good about yourself in Tony Hawk, but it's pretty easy: you can ollie and skate half-pipes right out of the gate, at least. (Try to ollie or skate a half pipe in real life and you'll realize just how easy Tony Hawk is.) But as you keep playing, you keep getting better, almost indefinitely.

    This has flaws too:
    • If the game has an 'ending', (you unlock all the levels, for example) people may quit playing before they've discovered the full riches available to them.
    • In multi-player, the opportunity for humiliation is opened right back up again.
    • It's still possible for it to start out too hard. Tony Hawk is not as rewarding for an absolute beginner as SSX is, for example.


    Are there any better answers?

    Friday, February 28, 2003

    Speaking of rock-paper-scissors, this embarrassed me: http://chappie.stanford.edu/~perry/roshambo/index.html

    Thursday, February 27, 2003

    Back in November I started writing the Jamie test, my own version of the Joel Test, and I got 4 steps into it (5 if you count jumping ahead to step 17) before I lost interest in writing about it because now that the project management is seemingly under control on my team I'm not terribly interested in studying it anymore, and would rather talk about game design, which is still a black hole of unknowns.

    Of course, you can be the best game designer in the world and it won't do a damn bit of good if you can't manage a project. So without further ado:

    The Jamie Test, Step 5

    Commit to Tracking Bugs

    Which basically means: have automated bug tracking software - we use a homegrown thing we built with Seven Simple Steps - and use it from the very beginning of a project. Some people find this surprising: "What? We can't fix the bugs now, we've got a milestone to hit!" Hopefully there aren't too many of those people left these days.

    I'm going to quickly gloss over the reasons to track and fix bugs early that everyone knows. If you want more info on these, read Debugging The Development Process by Steve Maguire:

    - bugs are cheaper to deal with the sooner they're dealt with

    - it's easier to estimate how long it will take to implement a feature than it is to estimate how long it will take to fix a bug

    - crash bugs make it harder to implement features because you can't test; more esoteric bugs make it harder to implement features because you don't know if the reason your new feature isn't working is because you screwed up or because of somebody else's bug

    Here's a weird thing about me:

    Given a choice between scheduling software and bug-tracking software I'd take the bug tracking software. (Nevermind that we use Excel to do both.) According to Peopleware, by DeMarco and Lister, some (admittedly sketchy) studies have shown that programmers work more productively when they aren't scheduled. This may explain the feeling you get when you're in alpha and dozens of bugs get fixed every day. Everyone's trying to fix each bug as quickly as possible, instead of trying to do the best job they can do on a feature within the time allowed. And I think you can benefit from that sort of ASAP mentality even at the beginning of a project, by getting the bug list up-and-running. So there's a fourth reason that you may not have heard before.

    I'm not really anti-schedule, by the way. But that's for a later post.

    Richard Rouse III has a contrary view to this. He points out that some publishers think they can ship projects sooner by getting the project into QA sooner and getting the bugs fixed sooner, and he takes issue with this, saying that people will put up with crash bugs for a fun game but will not put up with a game that isn't fun no matter how solid it is. Richard's POV seems to make more sense for the PC world than the console world. In the console world, the manufacturers don't let you ship a game with bugs. So I'm afraid bugs do have to take priority over fun in the console world, as it's a choice between shipping an unfun game and at least making some of your money back, or never shipping a fun game and making no money. But Richard's POV also ignores the fact that if you try to keep the number of defects down--and by defects I mean things your game does that you did not intend it to do (not including emergent behaviors that you're actually proud of)--you will ultimately slow down your development cycle, and end up with less time to make the game fun in the long run. I would argue that even for a throwaway prototype you should fix the bugs, for the same reason: you'll end up with a better prototype. I swear, it only takes a few days of ignoring bugs to turn your development process into a living hell.

    So let me segue straight into:

    Step 14: Do as much testing in-house as you can.

    I've also heard of in-house testing being called "production testing."

    Once you have your bug list up and running, it could be just a dump for everyone to throw their gripes when something gets in their way while they're working, or you could take a much more disciplined, exhaustive effort to test your product before passing it on to the next level.

    Generally, any asset or feature is going to need a lot of testing. The person who creates the asset or feature should test it before submitting it. Their lead should test it before signing off on it. In house testing should test it before the milestone it is a part of gets submitted. The publisher should test it before it is sent to the console manufacturer. The console manufacturer tests it before releasing it.

    It's quite possible you work at a place where upper management isn't going to spring for in-house testing. All this means is that you have to do more testing yourself. If upper management forbids you to waste your time on that testing stuff--("why are you playing the game instead of working on it?")--you'll have to do it in secret. I, the lead programmer, spent about a third of my time every day playing Tony Hawk when we ported it to the Dreamcast. Rough job, eh? But if I hadn't done that, the game would have taken longer to ship. And even if we had in-house testing back then, I still would have had to spend some time testing, to make sure that features were being implemented correctly.

    If only we did everything right the first time. But it seems that not only to err is human, but that to err a lot is.

    Tuesday, February 25, 2003

    Speaking of stuff that doesn't work, I'm told that Black & White is great for sand-boxing type gameplay, but I'll never know, because I can't get it to work on my XP machine. Ten dollars down the drain. That's right at the point where I'm not sure if I want to bother returning it or not. It makes it tough for a game to become a classic when it won't run on modern hardware.



    Game Design: Theory & Practice got me intrigued to play M.U.L.E., a game I'd heard much about but never played. I remember why now, after downloading a NES emulator: I couldn't figure it out. Maybe I should read the instructions.
    Rock-Paper-Scissors-Spock-Lizard is just as balanced as the original, and adds some cool "newness" in the form of two more choices. But there is no depth added, and it loses the elegance of the original game. More fodder for the "Less can be More" camp.

    "Depth", or something



    I'm fairly strung out from drinking too much caffeine this evening: Albertson's gave me free samples of Kenya coffee for buying my groceries on the web, so I sampled the samples while working late on an internal milestone, but the samples are lasting a lot longer than the work did. So I'll take the opportunity to post some embryonic thoughts I half-baked earlier in the week.

    Although Maxis claims that certain games such as SimCity and The Sims are not games but toys, I do not believe this to be the case. Maxis defines games at activities having goals, so by their definition Devil May Cry is a game (defeat all these creatures until you get to the end of the game) and The Sims is not. However, there is nothing in the dictionary saying that games must have goals in order to be games.

    A recurring line of reasoning in game design is that a game should consist of systems of simple elements that, when combined, allow emergent strategies to develop. Richard Rouse III discussed this in Game Design: Theory And Practice, citing the eyelets of Go, the forks of chess, the organisms of Conway’s Life. I have to agree. For me, finding these emergent strategies is one of the purest kinds of fun a game can offer, and it’s something that The Sims and SimCity give us in spades, but Devil May Cry is somewhat lacking in. Which do you consider a game now?

    Which raises an important point. Games don’t need to have this kind of fun to be successful, any more than they need directed goals. I don’t think anyone plays Grand Theft Auto for the depth of gameplay; although it does have a few emergent strategies (do the taxi/cop/ambulance missions first, before the gangs get angry at you, to make the other sorts of missions either: that’s an example of a holistic strategy that emerges due to the properties of the missions.) GTA3 is successful for different kinds of fun; its immersive qualities, its visceral intensity.

    So we could use a name for this synergy-of-elements kind of fun. Let’s call it ‘depth.’ The more emergent strategies that come out of the simple elements of your game, the deeper it is.

    A game that relies on emergent strategies for its fun is only fun as long as we keep finding new emergent strategies in them; finding the emergent strategy is the reinforcing stimulus—the food pellet—that keeps us playing the game.

    Games that have cinematic storylines and unlockable goodies don’t need depth to keep a player playing beyond the point where they feel they’ve found all the emergent properties; a player will often continue playing to get to the ‘end’, to see the final cut scene or unlock some goody for which they have for some reason attached a fetishistic value. But if the storyline isn’t compelling enough, the game fails. And even if the first edition of the game succeeds, the sequel may fail simply because it’s more of the same. It suffers Version One-Point-Five Syndrome. Again, witness Devil May Cry.

    As a counter-example, the Tony Hawk gameplay has so much depth that even though I worked on ports of Tony Hawk I & II, minor tweaks to the system allowed me to continue enjoying III and IV for many, many more hours. So that’s my argument that, despite the number of shallow games on the market, it is still worth striving for depth.

    We can get rough measures of depth in a couple of ways. One way is to compare the scores of beginning and advanced players. In games like Chess and Go, a moderate player can beat a beginning player almost every time. And an advanced player can beat a moderate player almost every time. And a grandmaster can beat an advanced player almost every time. It’s true for Go, Chess, Tony Hawk, and Kohan. It’s not so true for, say, Checkers; some games you reach a cap where there’s very little you can do to gain further advantages. (Of course, a game with 'breadth'--a wide set of rules that don't interact complexly but you have to know them all to have the highest advantage--could also have the same disparity in play-mastery. In some ways Tony Hawk and Kohan both fall into this category, each with their own large sets of special moves and heroes which the game mechanic requires you to know all of to be at the peak of performance.)

    (A second, less useful, method that doesn’t so much measure depth but breadth times depth—how much there is to a video game in toto—is to look at the articles on it at GameFaqs.com. If they can describe all there is to a game in very little space (Final Fight, Panzer Dragoon Orta) then you can bet that the gameplay is shallow. If it takes a lot of space, then you’re looking at either a “stuff game”—lots of elements that don’t combine to form higher level strategies, such as Diablo—or a depth game. Or both. Unfortunately, this after-the-fact measurement isn’t terribly useful when a game is in development.)

    A combination of atomic elements that elicits emergent strategies is something any game can have, no matter what the genre. It isn’t just for strategy, fighting, and trick games. In these games, the player is left to discover the emergent strategies (should I call them emergencies? No.) themselves. But this theory works for puzzle games such as Zelda and Lode Runner as well. The difference is that here, the game designer thinks of clever ways in which the elements can create emergent behaviors, and purposely puts these combinations into the game.

    For example, one atomic element of Lode Runner—you can dig below you, to the left or the right—when combined with itself, creates the emergent property that to dig n blocks down you need to dig a pit n blocks wide, and thus can guide level design.

    Some game designers disrespect puzzle games on the grounds that once you’ve solved a puzzle once the puzzle is no longer interesting. This is true, but fails to take into account the fact that once you’ve found an emergent strategy, that emergent strategy is no longer hidden, and your non-puzzle game is therefore that much less interesting as well. (To give the non-puzzle games credit, though, it’s much more likely that people will find strategies the game designer was never aware of, and therefore be able to get more enjoyment out of the non-puzzle game than the game designer consciously put in. This is not true of puzzle games.)

    Even adventure games can be thought of in terms of atomic elements. A good example of this is Day of the Tentacle. Day of the Tentacle has the same engine as Sam and Max, and yet is a superior game. Where in Sam and Max, the puzzles are all of the scavenger hunt variety (find this item, use it here), Day of the Tentacle provides a system that creates a whole class of puzzle, and then creates several examples therein. Day of the Tentacle is about time travel; you have three characters in the past, present, and future, and a narrow pipe (actually a toilet) with which you can send some items forward and backward through time. The kicker? You can also send items through time by hiding them in a place to be found by your friend in the future. In this manner, you can bury a bottle of wine, and in the future you’ll have vinegar. You can leave a washing machine running on a sweater, and in the future you’ll have a sweater fit for a hamster. By providing the additional element of the chron-a-john, Dave Grossman and Tim Schafer create emergent properties that Sam & Max could only dream of having. Their game design genius lies in recognizing that this one element would open up so much.

    So how does one achieve depth? The answer, I fear, is the same answer we’ve heard all along: prototype, playtest, and iterate. Conway’s Life is a good example of this. The elements of life are cells that are either on or off; the interactions come from neighboring cells. There are five hundred twelve possible interactions for a given two dimensional cellular automata; therefore the number of possible rule sets we could create are two to the five hundred twelfth power. (That’s around 1E77; if you took a second to test each simulation, looking for emergent properties, it would take around 1E63 eons.) So Conway makes a good guess, and simplifies the problem by only considering population. A living cell with too few neighbors dies; a living cell with too few many neighbors dies; a dead cell with enough neighbors, but not too many lives. Now we’ve got a reasonable number of results to test. Still, with all these possibilities, only one is famous; the cellular automata discovered by Conway which he called the game of life, with its gliders, replicators, eyelets, clocks, and so on and so on.

    Why is this one famous? If you play around with life (http://psoup.math.wisc.edu/Life32.html is an amazing version of the program) you’ll discover that just tweaking the rules a little (making birth or survival one level easier or harder) leads to either massive overpopulation or boring stasis. (You’ll also discover that people who are into life are scary into it. http://www.radicaleye.com/lifepage/lifepage.html)

    So when making a game, we do what the life scholars do. We make some elements and some rules and then run the simulation to see what happens.

    Still, prototype/playtest/iterate is not an ideal way to live. It doesn’t give us any idea when we’ll finally strike depth. It would be nice if we could find some tools to do it right the first time.

    I don’t believe we can do it right the first time—without massive luck—but I do think there are some techniques we can use to reduce the number of iterations:

    What is the matrix?

    For puzzle and adventure games, coming up with rule sets, and for predicting what emergent qualities a game might have, we can use the programmer’s good friend: the matrix. Simply list the elements your game contains horizontally and vertically, mask off the bottom left triangle, and consider the interactions between each pair of elements. This should stimulate the creativity for thinking about puzzles and level design, give you test plans, and the like. Unfortunately, due to the limits of paper and the human mind, it’s not likely you’ll be able to carry this practice into matrices of three or more dimensions, where it’s possible you could discover some other interesting interactions. (The combo system from Spider-Man: The Movie, with its three-button codes for sets of attacks, could easily be expressed with a three dimensional matrix.)

    Adding another element does not necessarily make the gameplay deeper

    At first glance, it might seem like adding a new element will always make gameplay deeper. Hey, adding the time machine to Day of the Tentacle worked great, right?

    But let’s take rock, paper and scissors, for example, where the gameplay is very shallow, with no emergent properties to speak of, and let’s add an element.

    Everyone knows what happens if we add ‘gun’: the game is ruined. You laugh. But I would argue that Kohan (an excellent game despite this flaw, btw) was made shallower by the introduction of the Kohan units, as the special powers of these units unbalance the core rule set and mask the finer points of the game’s strategy. It goes from being a game of using your units to their maximum effectiveness to a game of knowing what special abilities all the Kohans have. Breadth kills depth.

    So what if we try to add an element that is in balance with the other elements? Let’s call it ‘phleghm.’ We make a circle: phleghm beats scissors beats paper beats rock beats phleghm. When elements attack across the circle, it’s a tie. (Phleghm ties paper; rock ties scissors.)

    After some playtest, we discover that Rock Paper Scissors Phleghm is no more fun than Rock Paper Scissors. In fact, we come to the sad realization that Rock Paper Scissors was a better game before we mucked with it; it was simpler, it was easier to remember the results table, there were fewer ties, and the hand signal for ‘phleghm’ was problematic.

    Taking out elements can improve the game

    Supposing we started with Rock Paper Scissors Phleghm. We could immediately improve the game by removing one of the elements. It doesn’t necessarily give us depth, but it can reveal depth, just as tuning the population curve in Conway’s Life can reveal emergent patterns.

    This happened with Tetris. Originally the game was based on a puzzle with shapes made from five squares; when they simplified the shapes to ones made from four squares the game became, well, Tetris.

    So Less is More seems to be a canonical rule of game design. This rule seems to exist in conflict with another rule of videogame design, which is: maximize the number of ways in which the player can feel like a hero. But of course it doesn’t really; if strategies really do emerge, then the number of ways in which the player can kick ass multiplies.

    Okay, caffeine is finally wearing off. Good night.
    So this is Chris Busse's idea. "Maybe we should team up," he said. "Since neither of us is terribly prolific, we increase the likelihood that one of us will have written something. And the blog would be one stop shopping for game development goodness." Actually, he didn't say that, but it's kind of what he meant. So maybe this is it.