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

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

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

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

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

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

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

Jamie Test, Step 8

Let team members estimate their own schedules

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

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

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

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

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

A hobbit can contend with the will of Sauron.

Jamie Test, Step 7

Fix Bugs Before Writing New Code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We take videogames seriously

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

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

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

God damn

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

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

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

Think I'll play some Kohan.

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

More notes on Zelda

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

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

Notes on Zelda: The Wind Waker

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

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

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

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

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

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

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

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

Blah, blah, blah

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

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

Management by Nagging

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

1) ask somebody to do something

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

3) repeat step 2 until done

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

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

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

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

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

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

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

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

Notes on Uplink

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rock, Paper, Scissors Redux

Yes! A rock, paper, scissors tournament!

Some highlights:

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

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

Jamie's 400

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

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

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

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

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

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

- providing puzzles that can be solved in only one way

- having letter grades instead of raw scores

What's the Point of These Rules, Anyway?

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

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