|< Day Day Up >|| |
As you playtest, you will invariably notice places where your game is functional, but incomplete. For example, early in the first-person shooter prototyping process, we established movement and shooting rules so the system could function, but we had no rules about hit percentages or winning conditions, so it was still incomplete. Some of these missing elements are obvious, but others are much more difficult to discern. Only by testing every possible permutation under all conditions, can you be certain that there are no sections of the game that are left unfinished. Your job as game designer is to identify and resolve these issues.
This sounds simple, but it’s not. Most games are quite complex systems which can act in unexpected ways under different conditions. The more you test, the more you’ll discover how malleable your game is. Players will do things that you could have never anticipated. There may be gaps in the rules that made sense on paper but when they are actually implemented in the game, they lead to irresolvable situations or gray areas. In boardgames, this often leads to arguments betweenplayers—each side interpreting the rules in their own way. In software, it leads to a loophole that players can exploit, a dead-end in the player experience, or a complete breakdown of the system. You’ll often hear your testers making comments like, “The rules don’t say either way,” “I’m completely stuck,” or “You can’t do that!” These types of reactions are red flags that something within the game isn’t complete and needs attention.
After identifying an incomplete portion of your game, the first thing to do is go back to the rules. Whether you’re working on a digital game or a boardgame, you should have a design document or a rule sheet, which clearly describes how your game is to be played. What you’ll discover is that what you thought was a clear set of rules actually has holes in it. You now have to plug the hole (or complete the rules) so that it makes sense. Doing this can often affect other parts of your game, so it’s a delicate task and may require several testing sessions and revisions before you get it right.
Exercise 9.2: Testing for Completeness
Take the original game prototype you’ve been working with since Exercise 7.9 and test it for completeness. This time, look specifically for moments in which players reach an impasse, question the rules, or have to make a judgment call about what happens next. If players argue about the rules or reach a dead-end, your game is not complete. Revise your game to deal with the issues you find and test again.
You’ll find that sometimes playtesters uncover problems in a system despite the fact that the rules are unambiguous. For an example, let’s go back to the first-person shooter prototype from Chapter 7 on page 160. Is it internally complete?
Here’s a potential problem that plagues many first-person shooters, including our prototype: When more than two people play this game, it’s possible for players to camp near both of the spawning points on the arena map. When a recently killed opponent appears at either spawning point, the campers can promptly shoot the opponent. Players stuck in the position of being shot are furious at this seemingly unfair tactic.
The problem is that the rules are comprehensive and the players are behaving within the bounds of the rules, but certain players have figured out a way to gain an advantage that the designer didn’t expect. Thinking as the designer, how would you alleviate this “spawn camping” problem? For a challenge, stop reading now and think through your own solution. Then compare yours with the following four possible solutions.
The number of spawning points on a map should be equal to the number of players in the game.
Pros: Players will always have at least one safe point on which to spawn.
Cons: Have to design arena maps specific to the number of players that will play on it. Maps cannot facilitate a fluctuating number of players as most online FPS games allow.
A force field shield surrounds each spawning point hex. A spawning player can fire and move outward through the force field. However no one can shoot or move back in. The force field incinerates a spawning player if he remains on the spawning point hex for more than one turn.
Pros: Players are safe when they first spawn. And they can fire upon a single camper.
Cons: Multiple campers can still wait nearby making the turn after spawning difficult for players.
Players can choose to spawn on a randomly generated hex. If the hex is occupied by a wall or another player, then a different hex must be randomly generated.
Pros: Reduces player interest in camping by spawning points.
Cons: Adds an element of luck to the system.
Don’t fix this because it’s a feature, not a problem.
Pros: Some players think spawn camping is just part of the game. Leaving the system as is will force players to fight for choice camping spots which will create a game in itself.
Cons: Other players are extremely frustrated by spawn camping.
The options listed illustrate that there are many creative ways to tweak this system during the process of making a game internally complete. As we noted, the spawn camping problem is not unique to our first-person shooter prototype. If you do an Internet search on the phrase “spawn camping,” you’ll see dozens of web sites discussing the pros and cons. You’ll also notice that many fans have created numerous work-around mods to alleviate the spawn camping problem. Some of the mod solutions are similar to the options we listed previously. Some are different. One solution makes a player invisible for two to three seconds after spawning. This lets a player run around and shoot without being seen, giving them a fighting chance.
Exercise 9.3: Spawn Camping
Write down three original solutions to the spawn camping problem not mentioned previously. Describe why you feel these solutions are inferior or superior to the ones mentioned.
Finding loopholes is an essential part of testing for completeness. A loophole can be defined as a flaw in the system which users can exploit to gain an unfair or unintended advantage. As long as loopholes exist, your game cannot be considered complete. Your mission as a designer, is to close off all loopholes before the product is shipped.
This is no simple task, especially with videogames. The very nature of a computer program makes it easy for loopholes to go undetected. In most videogames, there are so many possibilities that no designer can test them all, and some gamers actually make a point of ferreting them out. To these gamers, the challenge of finding loopholes is irresistible. They love to tout their discoveries and use them to their full advantage when competing against other players. If you don’t believe us, go online and read the fan sites. Gamers make sport out of finding loopholes in games, and they post the flaws on their web sites for everyone to see.
Consider an example from the PC game Deus Ex. We should first state that Deus Ex is widely regarded as one of the most innovative games to be released in recent times. It’s a pioneering piece of work in that the game environment is open and flexible rather than being tightly scripted. One of the weapons available in the game is called a “LAM.” LAMs can be attached to walls and used like proximity mines—meaning they explode a few seconds after someone stands in close proximity to them. They are great for blowing up doors and for killing unsuspecting opponents. Apparently, however, they are also good for something the designers never anticipated.
Creative players learned that they could attach multiple LAMs to a wall, and then quickly run up them like a ladder before they detonated. Doing this allowed players to climb into places on game maps in ways that the designers hadn’t anticipated. This meant that some levels were less challenging than originally planned. If this can happen to world-class game designers, it can happen to you. Players are much more creative and resourceful than you’d ever imagine.
Another example comes from the Atari game, Asteroids. This game was a smash hit in the arcades when it was released in 1979. In this game you control a spaceship and must blast your way out of a field of floating asteroids, and also gun down flying saucers that come on screen to shoot you.
9.2 Deus Ex: gameplay screens, inventory, and LAM (smallest image)
Engineers at Atari played the game incessantly for six months before it was released and had recorded a company high score of 90,000 points. No one believed that a normal player—someone not familiar with how the game was programmed—could ever achieve a score like that. However shortly after the game’s release Atari began receiving reports that players all over the country were scoring three and four times that many points. In fact, the players were “beating the machine” because the Asteroids scoreboard maxed out at 99,990 points and, once surpassed, the score started over at 0.
The engineers at Atari were stunned. So they drove out to an arcade to investigate firsthand. Eugene Lipkin, then president of Atari’s coin-operated–game division was quoted in Esquire magazine in 1981 as saying, “What had happened, was that a player had been smart enough to understand the movement and the programming on the product and had then come up with an idea of how to work around it. It took about three months for that to happen. Then, all of a sudden, we began hearing the same thing from all over. People had figured out that there was a safe place on the screen.”
The safe place on the screen occurred because the player’s bullets can “wrap around” the screen—meaning when firing off the right side screen they reappear from the left on the same trajectory, whereas the flying saucer bullets cannot wrap around. Players learned that if they destroyed all but one asteroid floating on the screen they could lurk near an edge and pick off the flying saucers as they appeared.
The small flying saucer is normally very formidable and is worth 1,000 points. With the lurking strategy, however, a player could shoot a flying saucer with wraparound bullets and get it from behind, or if the saucer appeared on the same side of the screen as the player, they could quickly blast it before it could get off a shot. It still takes a lot of skill to do it effectively but once mastered, this lurking practice allows players to rack up huge scores. Asteroids purists regarded the practice derisively. However this did not keep players from exploiting it to the fullest. Atari had to wait until the next version of the game, Asteroids Deluxe, to fully fix the problem.
9.3 Ultima Online: EvilIndeed makes a kill
Sometimes it’s debatable whether a system issue enables a loophole or whether it is actually a benefit to the game. You’ll see heated arguments online, where gamers take both sides of the issue. The first-person shooter spawn camping loophole discussed on page 227 is one example of this. When you identify one of these subjective issues, you must make a creative choice on how to handle it. Sometimes it’s possible to make variants on the game to satisfy different types of players.
As an example, let’s look at how massively multiplayer online role-playing games (MMORPGs) have dealt with one specific type of “loophole.” Ever since MMORPGs were introduced, players have debated the pros and cons of being able to kill other players. MMORPGs are persistent online worlds where players role-play and interact as virtual characters. Most people dislike players who maliciously kill other players. These people are called “player killers.” The remaining players would prefer that the game designers, for a given MMORPG, tweak the system to prevent player killing from happening. However, some people think that player killing adds to the richness of the game because evil characters are free to play evil roles, and it creates a more intriguing and challenging environment.
Which side is correct? Does the presence of player killing mean that an MMORPG has a loophole and that the game is not internally complete? The solution that MMORPG designers developed over time—through playtesting with real players—was to provide spaces for both types of players. In essence, many MMORPGs have two variants: one where players cannot hurt one another, and another where they can. Each variant is internally complete in its own way. The following are examples of how several well-known MMORPGs have evolved through play and revision to deal with player killing.
Ultima Online is one of the first MMORPGs. Early in the game’s history, new players complained about being bullied and killed for no reason by more powerful players. Newbies had no protection. The problem was spoiling the fun for many players and deterring others from joining. People generally loved the game but hated the player killers—who they called cowards. They filled online message boards with complaints. Articles appeared in magazines about the problem. The designers at Ultima Online needed to tweak their game system to alleviate the tension.
In response, Ultima Online’s designers created a reputation system for characters in the game. Players who murdered other players were given red name banners and designated as “dishonorable.” When law-abiding characters saw a red character, they would likely not trust or cooperate with them. This made it harder and less fun to be a player killer. In addition, and perhaps more dissuasive, was the fact that experienced law-abiding characters would (and do) band together to hunt down red characters. This created a system of vigilante law in the game, which greatly alleviated the tension, but also developed its own set of problems.
Over time, the game designers continued to tweak their system to make it less and less appealing to be a player killer. For example, they placed invincible computer-controlled guards at the entrances to all but one city in the game world. The guards killed red characters on sight. This meant that the cities were safe for law-abiding characters and player killers were relegated to anoutlaw’s existence, either out in the wilderness or in the one town that accepted them—a dangerous place called Buccaneer’s Den. This solution accommodates both law-abiding players and player killers. It also meant that player killers could camp outside of towns, ready to pounce on any hapless players who might wander outside the city limits.
Today, the world of Ultima is divided into two separate spheres—one in which player killers run free, and one in which player killing is disabled by the system.
Asheron’s Call is another popular MMORPG that had to deal with the same problem but came up with a very different solution. In the first version of Asheron’s Call, the designers created an allegiance and fellowship system. When a new player came into the world, he had the option of swearing allegiance to another player character. In return, the new player might receive protection or even money and weapons from the experienced player—who was designated as his “leader.” From that point onward, a share of the new player’s experience points would go to his leader. Likewise, a share of the leader’s experience points would go on to that character’s follower (if she had one) and so on. This created a mutually beneficial pyramid structure that helped protect players.
In addition, Asheron’s Call players had the option of joining fellowships. Fellowships were temporary agreements with other players, usually formed to go on a quest or pursue a goal. Experience points generated while the players were a fellowship were distributed across the group. Individuals in the group received a share of the points based on their experience level. For example a third-level character received a bigger share of the points generated by the fellowship than a second-level character, etc. The designers at Turbine Entertainment developed these systems as an elegant way of rewarding players for working together. They made it more fun to cooperate and less fun to be a spoiler.
Even with these systems in place, law-abiding players of Asheron’s Call still complained about player killers. Turbine responded by tweaking the game so that, by default, players could not be attacked by other players. The story of the game was tweaked to say that the powerful magic of the world of Dereth protected them from one another. This made all players completely safe from one another, but it was disappointing to players that wanted the thrill of battling other live players. In response, Turbine created a way for players to voluntarily convert to player killer status. The interested player had to find a special altar in the game world to do it. After conversion, the player could kill and be killed by other player killers. In this approach, all players could inhabit the same game space, but only players designated as player killers could battle one another. This approach continues to be utilized today.
Rob Daviau is a prolific designer of board and card games. He works on staff at Hasbro Games.
Senior Game Designer, Hasbro Games
Project list (five to eight top projects)
Risk 2210 AD
Axis & Allies Pacific
Trivial Pursuit 20th Anniversary
Star Wars Epic Duels
The Game of Life: A Jedi’s Path
Battleship Card Game
How did you get into the game industry?
Right place, right time. I played games all my life and spent a lot of time fading in and out of role-playing campaigns. After five years as an advertising copywriter I was looking for a change. I applied as a copywriter for Parker Brothers (mostly writing rules and box bottom copy) at the exact time they were looking for a game designer with a writing background. I ended up getting the designer job and the bulk of my work still involves copy-heavy projects. In my interview, I named two of my favorite games from childhood. Turns out the guy interviewing me had designed both those games. It was luck on my part but I advise that as a good tactic when interviewing somewhere. Just don’t make it look like you planned it.
What are your five favorite games and why?
Tough one. For me, I admire games that create a whole new way to think about games—games that create a new type of game. So my top five (in no order) are: Dungeons & Dragons, Diplomacy, Magic: The Gathering, bridge, and Monopoly.
If I had to list my five favorite games (that I have played), I’d go with Acquire, Settlers of Catan, Queen’s Gambit (I had very little to do with that game, so I’m not being egotistical), Scrabble, and hearts.
If I had to pick the five games I’m most excited to play right now, the list would be: hearts, RoboRally, Game of Thrones boardgame, The Riddle of Steel RPG, and a game we’re working on here. That list is for today, in a week a few would probably change. By the time this is published, most will have.
What games have inspired you the most as a designer and why?
Every game—okay most games—have something in them that is clever or new or cool. I keep a mental list of the cool mechanic, the cool piece, the new storage tray, or different artwork in the games I play. I think of it as creating a palette to paint my own pictures. Offhand, in no particular order, the things I find clever right now are: the Spiritual Attributes that force munchkins to be role-players in the Riddle of Steel RPG, the bidding mechanism in the German game Lowenhertz, the shoot the moon aspect of hearts, the simplicity of TransAmerica, the simultaneous planning of RoboRally, the interconnectedness of the turns of Puerto Rico, the one-hand but two-purpose nature of cribbage, the artwork of Mystery of the Abbey—the list could go on and on.
What are you most proud of in your career?
The Avalon Hill line when it first got to Hasbro, which I was part of as a designer and copywriter from 1999 through 2001. I think there are some really good games there.
What words of advice would you give to an aspiring designer today?
It’s very easy to hide behind a gimmick—graphics, sound, a license, nice video segments—but game players are smart. They’ll figure out if it’s all smoke and mirrors with no real game. Think about how well your game would play as a card game. There’s nothing sexy about cards, no gimmick to hide bad gameplay. If your game would still seem fun as a card game, then it’s a good idea and a good game.
EverQuest, an MMORPG developed by Sony Online Entertainment, uses a similar system to Asheron’s Call. In EverQuest, only players who choose to convert to player killer status can kill or be killed by other players. To further appease player killers, EverQuest offers player killer only game servers. On these servers, all players are susceptible to attack from one another. These servers are popular with hardcore fans. This version is the second variant described previously. By responding to player feedback—a form of playtesting—the Sony designers succeeded in closing a disruptive problem and made their game internally complete in regard to the player killer issue.
In most cases, you’ll never find all the loopholes before the release date, and this is why some game developers opt for a public beta test. It’s a risky proposition because it can dampen sales of the game, but in some cases, especially with massively multiplayer online games, it’s a valuable tool.
Figure 9.4: EverQuest
Whether you initiate a public beta or not, it is your responsibility to make sure that there are no loopholes which will ruin the player experience.
Whenever a loophole is discovered, your job is to tweak the system and perform another playtest to see if the disruptive technique works. Eventually, you’ll find a solution that eradicates the loophole. It’s an iterative process, and each loophole can take days or even weeks to solve. By the time a game is released, most designers manage to do a pretty good job at eliminating the obvious flaws, but even with the most sophisticated testing schemes, some loopholes seem to find their way into the final products. This is because the number of people who play a released title is so much larger than the number of dedicated testers any company could manage to recruit, and all it takes is one player to uncover the flaw that everyone else missed. Here are some tips for finding and weeding out loopholes:
Use control situations, as described in Chapter 8 on page 216, to test aspects of the system in isolation. This will force testers into situations they might otherwise avoid, exposing flaws that otherwise wouldn’t be apparent
Do a series of playtests where you instruct testers to attempt to disrupt the system. Challenge them to see who can come up with the most creative way to get ahead.
If possible find testers who enjoy figuring out alternative or subversive solutions. Computer hackers are good at finding loopholes in games. A person doesn’t have to be a programmer to have this personality trait.
Exercise 9.4: Loopholes
A loophole is a system flaw that a player can exploit to her advantage; take your original game prototype and test for loopholes. In this exercise, use seasoned playtesters who know your game inside and out. As advised previously, instruct testers to disrupt the system. Challenge them to see who can come up with the most creative way to subvert the rules.
A dead-end is another type of common flaw that disrupts the gameplay experience. Dead-ends are not loopholes, in that they do not allow a player to exploit a game, but like loopholes, they must be fixed before a game can be considered internally complete.
A dead-end occurs when a player gets stranded in the game and cannot continue towards the game objective no matter what they do. Adventure games, where players have to collect objects in the world and then use these objects later to solve the puzzle, are susceptible to this. If the player cannot solve the puzzle because they are missing a piece, they’ve reached a dead-end.
Dead-ends can also occur in other types of games. For instance, in a strategy game, a dead end can be a situation where the players cannot resolve the conflict because their forces wind up without resources. In an FPS, a dead-end can be a virtual space that a player stumbles into and cannot get out of. Most titles have ironed out deadends before they are released, but now and then, one slips through the playtesting cracks.
The idea of completeness can be summed up by the following statement: An internally complete game is one in which the players can operate the game without reaching any point at which either the gameplay or the functionality is compromised.
This is both an objective and subjective decision. You can say your game is complete at almost any point, and that will hold true until someone uncovers a flaw. In reality, no game is ever complete. There is always room for improvement, and in most cases, there are unknown or irresolvable issues lurking within the game system.
Schedule and budget constraints often preclude designers from ever fully completing this stage of the process. But your job as designer, and specifically your focus during the formal details stage of design, is to enforce a high enough standard and to lay out rigorous enough tests so that you can be certain beyond a reasonable doubt that there are no critical deficiencies lurking within your game. Only once you have accomplished this can your game can be considered internally complete.
|< Day Day Up >|| |