Security

Your client software will be hacked. For some virtual worlds (such as those with no game aspect to them), this won’t necessarily matter. For the rest, it matters a great deal.

At the very least, it means that all packets sent from the client to the server have to be checked to see if they make sense. Error-correction at the hardware and transport layers should ensure that what arrives at the server is what was sent by the client, so why waste time checking for nonsense that isn’t going to come? Well, the fact is that the server may not be talking to a bona fide client. It could be talking to a piece of code a player has written to masquerade as a client or to insert data into the client’s packet stream. If the server receives nonsense but has no way of handling it, what happens then? Has someone acquired an ability to crash the server?

That’s if it’s even your server. Sometimes, groups of players will write their own server and persuade clients to speak to that instead. They can then design and play their own world in preference to yours—and all for free ¹!

Virtual world programmers don’t have to make life easy for hackers—they can use encryption, own the screen, make very infrequent identity checks that packet-sniffing software may miss—but eventually their code will be reverse-engineered and people will figure out what’s going on. Then they’ll change it ².

Important: Absolutely no decisions with regard to what happens in a virtual world can be delegated to a client. No decisions. That’s no decisions.

Air Warrior’s first client performed the necessary calculations to determine if a shot hit or missed. It was considered unfair for players to line up their sights exactly on a target, pull the trigger, but miss because their client was showing the target to be somewhere the server didn’t think it was. All very laudable, until someone wrote a hack for the client such that whenever you fired, it sent a packet claiming you’d hit whichever plane was closest to your sights—irrespective of whether it was actually in them. Kesmai had to bring out a patch to fix it.

Programmers should never put world-critical code in the client. If they do, it can mean major, big-time fraud. Designers only have to worry about this if they have to come up with a strategy for repairing the damage should it go undetected for too long (for example, groups of players giving themselves money and spending it in inflation-causing amounts).

Designers do have to worry about things such as automated play. Anything that requires similar actions to be performed repeatedly is usually easy to automate—it doesn’t even need a client hack in many cases, as there are off-the-shelf tools that will do it. Ultima Online’s craft system was so boring that players were overjoyed when they discovered macro software intended for typists that enabled them to save their index fingers from repetitive stress injury. Computers can generally issue commands faster than players, too: Someone wrote their own client for MUD1 that stuffed commands down the line so quickly that 30 seconds after having started play, the automated character would be standing with arms full of vicious weapons and other useful kit, while everyone else was still pretty well empty-handed.

Designers should therefore avoid calling for anything that involves doing something again and again and again with no respite (and that can include movement). If you really want an action to take a lot of time, let characters do it as a background task while their players are offline. If speed is occasionally important (for example, for dramatic reasons), insist that the server programmers institute delays between processing the commands from any one player ³. If some level of searching or exploration is required (for example, for a puzzle), put in moving obstacles or traps so a program can’t easily find a solution using a brute-force method.

People usually want to automate tasks that are tedious. If you design something that you think many players might like to automate, consider the possibility that it could be intrinsically uninteresting. For example, players will come to understand a virtual world far better if they make their own maps, so a designer might want to encourage them to do so. However, the actual mechanics of mapping are so mind-numbing that there are auto-mapping programs around (for textual worlds) that try every exit from every room until they have produced a complete map that can then go on a web site. If you were hoping to stimulate a climate of exploration by holding back on embedded mapping tools in the client, it didn’t work.

There are other ways in which wily players can subvert a client to put themselves at an advantage. Consider the case of a character executing a 360° turn. The client must be in close, rapid contact with the server to ensure that the necessary information is at hand to display the world as the sweep progresses. If it weren’t, then the player could be looking at a half-blank screen or seeing characters pop up in the middle of the view that weren’t there an instant earlier. However, as was pointed out earlier, the client can’t usually rely on a super-fast connection to the server.

To solve this problem, the EverQuest server was configured to send the client more information than it strictly needed; if a player wanted to turn, then the positions of nearby objects would already be known and could be displayed without lag effects. To this end, the client was told the locations of all objects and players in the vicinity—not just those that character could “see”—along with other handy tidbits, such as what they were carrying and how many hit points they had. The geography also was kept permanently available on the player’s PC.

This was an efficient approach, in that anyone could rotate or otherwise change the camera angle with impunity without suffering staggered images. However, a number of players soon realized that if the information was present, it could be displayed whether or not it was in actual use. They wrote programs to give radar-like readouts of everyone and everything in the neighborhood. No longer did mobiles attack them from behind; no longer did they need to guess which were carrying loot. One such program, ShowEQ, was so useful a tool that Verant felt compelled to ban its use (leading to one of its many public relations disasters ⁴).

It doesn’t even have to be the client that’s hacked. Ultima Online used the PC graphics card to control brightness, which meant that opportunistic players could override the client (by turning up the gamma correction) to get full daylight when they were supposed to be in total darkness. Great for ambushes!

If at all possible, designers should be adamant that no items of data are sent to the client that convey any information beyond what the player’s character is entitled to know. Client programming being the inexact science that it is, however, chances are some additional information will have to be sent in advance, even if it’s only texture maps on a CD-ROM. Designers should be appraised of this in advance, so they can adjust their designs accordingly. If you know that players are going to figure out where all nearby objects are anyway, give that information to them officially and be sure it’s never of much use. Have new mobiles that teleport in from nowhere, if you want to keep them on their toes.

Okay, so, your programmers assure you that nothing is in the client that should be in the server, except for a few elements that you can design around. That’s the security issue sorted, then!

Aw, you know it isn’t. Your design itself could have security problems.

For example, suppose (having decided that fixed prices are a bad idea) you make your economy determine the price of goods based on local supply and demand. Suppose also that it allows people to buy and sell in bulk at the price for a single item. Normally, this wouldn’t be a problem: If there are 300 swords for sale, it doesn’t matter whether you buy one at 20 UOC ⁵ or 10 at 20 UOC each. The price will rise the fewer swords are left, which is what you want—having bought 10 swords, the new price might be 22 UOC. You’d make the buy-back price be much lower than the sale price, so that anyone trying to sell back 10 swords they just bought for 200 UOC would receive maybe only 110 UOC for them instead of 220 UOC.

So far, so good.

What happens, though, for high-cost, low-production items? Maybe the local diamond mine unearths only five diamonds a week. When all five are available, the price at the diamond mart is 1,000 UOC; if only one is available, the price soars to 4,000 UOC. If none are available, the supply is exhausted. In that situation, how much could a single diamond be sold back to the diamond mart for? Even with a 50% mark-down on the purchase price, it would still be at least 2,000 UOC. So, if someone were to buy all five diamonds at once for 1,000 UOC each, then sell them back all at once for 2,000 UOC each, they’d make 5,000 UOC each transaction. Your design has given them an engine for generating however much money they like! Augh!

When something is allowed by the virtual world but the designers wished it wasn’t, it’s known as an exploit. Exploits—design bugs—can ruin a virtual world ⁶ overnight.

Exploits aside, there are plenty of ways that players can subvert a designer’s well-meaning intentions. Identity theft—pretending to be someone else in real life—is fairly easy but is hardly the responsibility of the designer ⁷. Character theft—pretending to be someone else’s character in a virtual world—should not be easy, because it is the responsibility of the designer. In particular, if two players can use the same name for their characters then it’s partly the designer’s fault if one of them subsequently successfully pretends to be the other. This “name problem” is discussed in some depth in Chapter 3.

So, your design will have bugs. Players will find these and wring every advantage from them that they can. Even if they report them immediately, they’ll feel you owe them for their honesty. So what do you do?

You can’t prevent exploits, but you can take steps to minimize their number and impact. Detection and recovery are of critical importance. If possible, log everything. In MUD2, players would regularly complain that line noise ⁸ had severed their connection to the game and led to their character’s demise. Instituting a “log everything” policy (player input/output transcripts and all server decisions) solved the problem at a stroke—90% of the time, players were exposed as having been active right up until the moment the dragon incinerated them or the wolf bit off their head or whatever, and therefore their impassioned pleas for resurrection amounted to cheating.

This degree of logging is not always possible for virtual worlds that use a lot of bandwidth, for example, graphical game worlds. There are two approaches to it, but neither is particularly satisfactory: store events (from which exact circumstances can be reconstituted) or store client communications (which gives the player’s actual viewpoint). Both of these create huge quantities of hard-to-search data. Customer service administrators may be able to snoop ⁹ on players as situations unfold, which can partially alleviate the problem, but if they arrive at a scene too late then the only alternative to logs is the presence of impartial witnesses (like there’ll be many of those).

Detecting possible bugs and exploits is important, but it isn’t itself enough. When it transpires that something really has gone unfortunately wrong, the ability to correct the consequences of it should absolutely always be available (even if it means a wholesale reinstallation of the character database from a timed back-up). An incomplete ability to discover when things are going awry is inconvenient; an incomplete ability to recover damaged data is incompetent ¹⁰.

Part of the satisfaction of virtual world design lies in seeing your creation evolving, with things occurring within it that you hadn’t anticipated but which make perfect sense. One of the less fortunate consequences, though, is that some of what happens you’ll almost certainly wish hadn’t, and will have to fix. The more contingency plans you have in place, the better, but you’ll never be able to cover everything.

Still, if you want the unpredictable, you can’t complain when you get it.