Design Issues for Online Gaming


In this section, we're going to address a hodgepodge of design issues that are peculiar to online games .

Arriving Players

Players can log on wanting to play your game at any time, and the game has to be capable of dealing with them intelligently. In most noncomputer games, all the players must be present at the beginning of the match, or it won't be fair. In Monopoly , for example, anyone who entered the game late would be at a significant disadvantage ”the others would have already grabbed the best properties, and the game's built-in inflation would swiftly bankrupt them.

The usual solution is to start new matches at frequent intervals and to have a waiting area or "lounge" where the players can hang around while they wait for it to begin. If a game can be played with any number of players (bingo is a good example), you can simply start a new match every three minutes, say, with whoever is around to play. In games requiring a fixed number of players, such as bridge, you will need to establish a matchmaking service that allows them to form groups and to wait (more or less patiently) for enough players to join a particular group ; the game begins as soon as the required number has arrived. The number of players needed for a game should be small, however, so that they don't have to wait too long. Any game that requires more than about eight players will have difficulties in this respect.

In some games, players can join almost immediately without any disadvantage ”poker, for example. Each hand takes little time, and new players can join as soon as the current hand is over. For games of indefinite duration, such as persistent worlds , nothing can be done about the fact that some players are ahead of other players. The players who were there the earliest and who have the most time to play will always have an advantage (unless you allow players to purchase prebuilt characters for real money on eBay, but that just shifts the advantage from players who have the most time to players who have the most money). There are a few ways of preventing this from spoiling the game for the players, however:

  • Get rid of the victory condition. Without winners and losers, it ceases to be a game, per se, and becomes a different kind of entertainment. The player focuses on her own achievements rather than on defeating all the others. In this case, the old clich becomes true: It's not whether you win or lose, but how you play the game. Persistent worlds, which we address later in the chapter, work like this.

  • Discourage competition between old-timers and newcomers. You can measure the progress of your players and see to it that only those who are fairly matched come into direct conflict. This is why tournament chess has a ranking system. An old-timer who beats a newcomer gets little or no reward for it. The clich description for this solution is, make players "pick on someone their own size."

  • Be sure that direct competition is consensual. If old-timers do get the chance to compete directly with newcomers, the newcomers should have the option to refuse to play. No one should be forced to take part in an unfair competition.

Disappearing Players

Just as players can appear at any time, they can log off at any time. If possible, your game should deal with this neatly and with minimal disruption to the other players. Obviously, in games that require a fixed number of participants , your only options are to include an AI element that can take over for the missing player, or to shut down the game.

However, in many games, such as racing games, players compete against one another in a free-for-all. The disappearance of one player doesn't make that much difference ”his car vanishes from the track, and that's that. It's as if he pulled out with mechanical trouble. In effect, the player forfeits the race and the others continue. On the other hand, if the game is played in teams , the disappearance of one player could put his team at a serious disadvantage.

Logging Out as a Form of Cheating

Tournaments are another matter, though. If players are competing to get the best win-loss ratio, one might deliberately choose to log out rather than lose the game ”which also denies the other person victory. Should the vanishing player be forced to forfeit? What if the disconnection was an accident , caused by a bad line? Unfortunately, there's no way to tell which it was.

In baseball, if a game is called off due to rain, it is considered finished if five or more innings have been played (four and a half, if the home team is ahead). Unlike baseball, however, most computer games don't have a distinct way of counting progress toward completion.

Responses to Vanishing Players

Here are a variety of alternative suggestions for dealing with vanishing players:

  • The vanishing player forfeits. Obviously, this is hard on players for whom it was an accident. Unless connections are extremely reliable and unlikely to break (such as in a game played on a local area network), you have to consider the possibility that it was unintentional.

  • Institute a penalty for disconnections, less severe than forfeiture. If you disconnect in the middle of combat during an EverQuest session, your avatar remains in the game for a minute, taking additional damage. Unfortunately, it doesn't fight very well by itself!

  • Award victory to whoever is ahead in the game. The problem with this is that the moment someone goes ahead, she can disconnect to prevent her opponent from having a chance to catch up. Again, you should consider this only in circumstances in which it is difficult or impossible to disconnect intentionally.

  • Record it as a tie. Obviously, this motivates a player who is behind in the game to disconnect intentionally. It is a fairly neutral solution, however.

  • Record it as a "disconnected game." You then have to decide exactly what this means in the context of a tournament, say. If the records are visible to the players, they might notice when someone has a suspiciously high number of disconnections and avoid playing with that person.

  • Abandon the game entirely. This is the fairest solution in the case of accidental disconnections, but it is unfair to whoever is leading if the player who is behind pulls the plug.

Questions to Ask Yourself

There's no one right answer to this problem; it depends too much on the nature of the game. It's up to you as the designer to think about it and try to decide what's fair. Here are some questions to ask yourself:

  1. What will happen to the gameplay when a player vanishes? How will it affect the other players' experience of the game (what they see and hear)? Does it disrupt the balance of the game? Will it make the challenges easier or harder? Is the game even meaningful anymore?

  2. What happens to the score when a player vanishes ”the players' relative progress toward victory? Is the game still fair?

  3. Does your game offer a player an advantage of some kind for intentionally disconnecting himself (whether by preventing himself from losing or by sealing his own victory)? Is there any way to minimize this without penalizing players who are disconnected accidentally ?

Real-Time Versus Turn -Based Games

Many online games take place in real time, with each player acting simultaneously . This offers them maximum freedom; they always have something to do and can order their activities any way they like. It's also more immersive than turn-based gaming. Waiting your turn while other players act harms suspension of disbelief. Unfortunately, real-time gaming tends to make a strategy game into an action game. Whichever player moves his pieces fastest has the advantage. In games such as Command & Conquer , victory becomes a matter of establishing an efficient weapons-production system as quickly as possible.

Turn-based games seem rather old-fashioned nowadays, but there is still a demand for them. Many simpler online games are automated versions of noncomputerized card games and the like, and they still require players to take turns. For this to work smoothly, you must include certain features:

  • Limit the number of players in one game. Four or five is a good maximum. With more than this, players will have to wait too long between turns and will grow impatient.

  • Set a time limit on the length of a player's turn. They mustn't be allowed to hold up the game while taking their turn. Both the player whose turn it is and all the other players should be able to see a countdown timer. The length of time will naturally vary depending on the sort of game it is; for a card game such as Hearts, we recommend no more than 10 seconds.

  • Determine a reasonable default action if the player runs out of time. In games in which it's allowed, this might simply be to pass without acting, but in a game such as checkers, in which a move is required, the game will have to choose one. It doesn't have to be a very smart move, however. It's up to the player to supply the intelligence; if he doesn't, it's his own fault.

  • Let players do other things while waiting their turn. They should definitely be allowed to chat with one another, study the battlefield, organize their units, or do anything else that doesn't actually influence the gameplay.

  • Allow simultaneous turns. This might sound like an oxymoron, but a few games, such as Age of Wonders II , allow all the players to take their turns simultaneously. The turn ends, and the results are computed and displayed when all of the players have input their moves.

Chat

Every multi-player game for machines that have a keyboard should include a chat feature ”a mechanism that enables players to send messages to one another. Depending on the nature of the game, players should be able to send private messages to one other individual, messages only to members of their own team (if any), or general broadcast messages to all other players who might reasonably be interested. Obviously, if there are thousands of players in a game, any one player should be able to broadcast messages only to those in his "local vicinity," whatever that might mean in the context of the game.

Unfortunately, chat brings problems with it: rude, abusive , or harassing behavior. People who are paying to play your game have expectations that others will meet certain minimum standards of behavior. In a sporting event, this is enforced by the referee or, at minimum, by the collective authority of the other players. Online, it's much more difficult to enforce.

Psychological disinhibition: People act like jerks more easily online because anonymity is intoxicating. It is easier to objectify other people and, therefore, to treat them badly . The only way to combat this is to get them to empathize more with other players.

Dirty-Word Filters

Dirty-word filters have been tried, but they never work ”and they sometimes produce laughable results. Words such as damn and hell are perfectly legitimate in a religious context, even if they're considered swearing in another context. In any case, people always get around such filters by misspelling the words. Don't bother trying to implement a dirty-word filter unless you also back it up by other means, such as online customer service representatives.

Complaint and Warning Systems

Some chat systems include mechanisms designed to discourage online rudeness. A complaint system enables players to push a "complain" button whenever they receive an offensive message. The message is automatically forwarded to someone with authority over the game (usually an online customer service person), who can then investigate and take appropriate action: warn the offender to mend his ways or even kick him offline.

The America Online Instant Messenger includes a fully automated system that allows users to warn each other, either anonymously or openly, when one of them is behaving badly. A user can be warned once per message that he sends; the more warnings he receives, the less frequently he is allowed to send messages. If he receives enough, he is unable to send any for several hours. The effect of the warnings fades over time.

Ignoring Other Players

A useful feature of some chat mechanisms is the capacity to ignore other people who are being offensive. The player simply selects the name of a person he wants to ignore, and he no longer receives chat messages from that person. You can permit this to take place silently (the other player doesn't know she's being ignored) or automatically send a message telling her that she has been ignored ”the online equivalent of deliberately turning your back on someone. This is one of the most efficient mechanisms available because it doesn't require staff intervention.

Moderated Chat Spaces

The most effective, but also the most expensive, way of keeping order in a chat space is to give one person authority to discipline the others at all times. This feature is used on Internet Relay Chat, in which the creator of a chat room has the authority to kick people out of it. It is, however, subject to abuse. In a game that people are paying for, you can't safely hand over that authority to one of the players; the moderator has to be an impartial representative of the game's provider ”a customer service agent, in effect, whether paid or unpaid.

Collusion

Most games ”true games, in which players compete for victory ”are designed with an assumption that the players will try to beat one another and that there is never any reason for them to help each other. Often this assumption is formalized in the rules. For example, in Monopoly , one of the rules states, "No player may borrow from or lend money to another player." Collusion is a form of cheating in which players who are supposed to be opponents work together in violation of the rules. In Monopoly, what prevents collusion is the players' agreement to abide by the rules, the potential damage to their friendship if they don't, and the fact that they're all watching each other to prevent it. Unfortunately, you can't count on any of these factors in an online game. Some players will join a game with a deliberate , even avowed, intent to cheat. Because they're playing with strangers, there's nothing at stake, and because they're physically miles apart, no one can see them do it. If you cheat at a board game, you'll most likely be thrown out of the game and your friends won't ever play with you again. Unfortunately, these kinds of penalties are difficult to enforce in online games.

Examples of Collusion

Computer games seldom have written rules because the designers assume that the game will enforce the rules automatically: The players simply can't make illegal moves, for example. However, there's no way for the software to detect certain kinds of collusion between players. Consider an online multiple-choice trivia game. Each question has three possible answers. Each player receives the same question from the server and has a fixed length of time in which to enter an answer. When he enters it, he immediately learns whether he was right or wrong. Correct answers earn points, and the player with the largest number of points at the end of the game is the winner.

Four players can easily collude at this game to guarantee that one of them will win. They all play on different machines in the same physical location ”an Internet caf , for example. When a question appears, three of the players immediately enter a different response ”A, B, or C ”and the fourth one waits. When the software informs one of three players that she is correct, she immediately calls out her letter, and the fourth player enters it before the time runs out. This way the fourth player always enters the correct answer.

This form of collusion is easily defeated: You simply don't reveal the correct answer until the time has run out to enter it. Players who enter an answer early simply have to wait to find out whether they were right. But other forms of collusion can be more insidious. If you offer a prize for the player who wins the greatest number of chess games in a certain length of time, for example, two players can collude to play each other, with one always trying to lose to the other as quickly as possible.

Designing to Reduce Collusion

Part of your job as a designer of an online game is to try to anticipate collusion as much as possible. Unfortunately, experience has shown this to be an extremely difficult thing to do. There are no limits on players' ingenuity or the lengths to which some will go, and, of course, there are thousands of them to only one of you. Even if your game doesn't offer a chat feature, players can play from two machines in the same room or call each other on cellphones to collude.

You can't prevent players from colluding, but you can design the game to minimize its effects. Here are some types of collusion to consider:

  • Sharing secret knowledge. Does the player ever have secret knowledge that she can share to someone else's benefit? In the trivia game described previously, some players are given the correct answer before the time runs out. Withholding this information makes collusion pointless.

  • Passing cards (or anything else) under the table. Does the game include mechanisms to transfer assets from one player to another? Is there any way to abuse these mechanisms?

  • Taking a dive. What are the consequences if one player deliberately plays to lose? Obviously, this makes a huge difference if you allow gambling on matches (even if only with "play" money).

If you're designing a game in which it's supposed to be every player for herself, try imagining what would happen if you made it a team game in which players were supposed to collaborate. If it's already a team game, try to imagine what would happen if one player on the team were a spy for the other team.

Technical Security

For some reason, people feel a strong impulse to test the limits of computer software ”to see what it will do with nonsensical data, for example. In playing a war game, it is a rare player who will not at some point try to order his troops to fire on his own side, just to see what will happen. Similarly, players often think of ways to do things in a manner that the designers never intended or expected. Sometimes these unanticipated maneuvers, such as using the rocket launcher to propel yourself upward in Quake , even become standard tactics.

Making unexpected but legal moves is still fair; one can argue that the designers should have anticipated these tactics or that the testers should have discovered them for themselves . Other forms of cheating, such as hacking the game's software or data files, are clearly unfair. In a single-player game, it doesn't really matter, however. It's rather like cheating at solitaire, and it says more about the player's character than anything else. It is a peculiarity of modern computer games that they are often so difficult that they must come with built-in cheats. Originally these cheats were built in during development to make testing easier and were removed when the game shipped, but now they are often left in for the public to use as well.

The issue of cheating in multi-player games is considerably more serious. People who wouldn't dream of cheating their close friends in person ”say, playing poker around the living room table ”are happily willing to cheat strangers when protected by the distance and anonymity that an online game offers. There's still that temptation to try to break the software, especially because players have gotten used to the notion that computer games will enforce the rules for them. They assume that anything that they can do, they are allowed to do.

This is a grave problem. Players have a moral right to expect a fair game when they're playing against other people, and they have a legal right to it as well if they're paying for the privilege of playing. This becomes even more true if they're playing for prizes. Although all game software comes with a disclaimer that it's sold "as-is" and without any warranty, the moment you start to give out prizes of real monetary value, you have to be very careful to make sure the game is fair.

Use a Secure Telecommunications Protocol

It takes an extremely dedicated hacker to tamper with the data stream between the client software and the server, but it takes only one. If the stakes are high enough, it can be well worth it. To foil this, your software must use a secure telecommunications protocol. Designing such a thing is a programming problem and is beyond the scope of this book, but we include a few suggestions.

  • First, all data should be encrypted to prevent users from understanding its contents. It should also include a suitable checksum, which will enable the software to detect whether it has been garbled in transmission.

  • Second, you might want to consider a "heartbeat" mechanism in which your client software sends a short packet to your server at regular intervals, even when there is no data to be transmitted, simply to tell the server that the client is still present.

  • And as we described earlier, all packets should include a unique serial number to indicate what order they belong in and to prevent spurious packets from being inserted by unauthorized means.

Don't Store Sensitive Data on the Player's Computer

Typically two kinds of data about a player exist in a game. One kind is settings or preferences about the way the player appears and likes to play. The other is information that's actually relevant to the game state: the player's position, score, possessions, and so on. In Monopoly , for example, the player's playing piece (hat, shoe, car, and so on) belongs in the former category; it doesn't matter which token the player is using. However, the player's properties, cash, and position on the board belong in the latter; changes to them affect the player's status in the game.

This second kind of information shouldn't be stored on the player's own computer. Even with encryption techniques, you have to assume that any data kept on the player's machine is subject to tampering and could be used to give the player an unfair advantage over others. If there's really too much sensitive data about each character to store it all on the server, at least store a checksum over the data when the player logs out so that when he logs back in again, you can check over his data and see if it has been improperly modified in the meantime.

Don't Send the Player Data He Isn't Supposed to Have

A common characteristic of real-time strategy games is the "fog of war," in which unexplored areas of the map are dark and the movements of the enemy are not visible unless a friendly unit is nearby to see them. In single-player games, all this information is in the player's computer, of course; it's just not visible to the player. In an online game, any hidden information should not be sent to the player. If the player hacks the game to lift the fog of war, he can see unexplored areas and watch the movements of enemy units, which gives him a significant advantage over his opponents.

Don't Let the Client Perform Sensitive Operations

If you're designing a client/server game, there is always a balance to be struck between the amount of processing that the server does and the amount that the client does. It's clearly cheaper for you to offload as much of the processing work onto the client that you can. However, it isn't always safer. Suppose, for example, that you're designing a very simple role-playing game in which the player occasionally encounters monsters and must do battle with them. It's cheapest for the server to send the client some information about the current monster, and let the fight take place entirely on the player's computer. When the fight is over, the client sends a message back to the server saying whether the player won, lost, or ran away. However, this is obviously very dangerous. If the player has hacked his client, he could program it to report that he wins every fight. In fact, the server, not the client, should act out the fight and determine whether the player won or lost.

Never trust the client: Never put anything on the client. The client is in the hands of the enemy. Never ever forget this.

The legitimate players aren't the enemy, of course, but the handful of cheaters are. We lock our doors at night not to protect us from the honest majority of the population, but to protect us from the dishonest minority. You will have to design your game with the same consideration in mind.



Andrew Rollings and Ernest Adams on Game Design
Andrew Rollings and Ernest Adams on Game Design
ISBN: 1592730019
EAN: 2147483647
Year: 2003
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net