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.