I first came into contact with MUDs in the early 1990s, and these early experiences in large part shaped the way I think about multi-player gaming and how a game should be created. Key to the success of the MUD genre was the emphasis on communication and movement around a fixed and/or dynamic game environment. MUD gaming has always been about delivering a rich universe, with concentration on the multi-player aspect above all others. While single-player text-based adventure games also existed, a MUD just could not have worked as a single-player game; there would have been no point. This social aspect to gaming was lent more credence by the rich command set, enabling players to communicate directly through simulated speech and, indirectly, through thought bubbles and emoting.

Gaming Model

Although the MUD genre can mean different things to different people, all MUDs share a common gaming model—one that is based on a pure client/server infrastructure. Usually this requires that all the rendering information be passed from the server to the client—historically a Telnet client, which displays textual information received by the software application. Telnet is a specific protocol, like HTTP, for transferring data over the Internet. It allows the server and client to communicate in a standard way—although what the server sends, and what the client does with the data it receives, is entirely up to the game designers.

The server acts as a communication conduit and maintains the entire game universe, usually in a database. If the server or database system is slow, then communication is slow, and the game becomes generally slower. If the server goes down, then the game cannot be played, as no more communication will be possible. The server is administrated by people (usually also players) with special powers (like super-users in a Unix-based system), which extend to managing the other players and, usually, the system—although not necessarily at the operating-system level. It is the responsibility of these admin players to make sure that everything runs correctly.

Non-Interactive Environments

The dungeon itself (for want of a better term, the game environment) is created by the MUD administration and can be static or dynamic, fixed or interactive. A static non-interactive environment is often just like a chat room. There might be some basic descriptive text, allowing players to take a look at the environment but not interact with it. Although they may be able to move from room (location) to room, nothing can be changed.

Unless the admins decide that a specific room needs a change, once everything is set up, it tends to remain the same. Those players that become admins might take ownership of certain rooms and change their look now and again, but the underlying premise of the MUD is that it is a place for people to come and chat (talk).

A step up from this is a dynamic non-interactive environment. In these environments, the room descriptions (and possibly objects within the rooms) may be changed by anyone with sufficient privileges. This mechanism usually allows non-anonymous players (residents) to have their own rooms, which they can invite people to inspect or chat in—usually with the possibility to lock the room against unwanted access. The difference between a dynamic non-interactive environment and a static environment is the level of customization that is possible. There is still no interaction between the environment and individual players, and the game remains more of a chat room than anything more advanced.

Note

Security concerns creep in at this point, as the server and database are opened up to players. If players find a way to insert a textual command in the descriptions of their rooms, and if that command is something subversive, then without specific safeguards, they could feasibly bring the system down.

Interactive Environments

A static interactive environment lifts the game to a status that enables the players to do more than just chat. The players might actually be able to interact with the game and game environment in a pre-programmed fashion. This opens the door for games involving quests or solving puzzles. In short, these types of environments open the way for “proper” gaming as opposed to just being glorified chat rooms. If players can interact with each other and the gaming environment in a way that allows the special “administrative players” to create games within the environment, then the possibilities for both fun—and security breaches—drastically increase.

It is the malleability of the environment, as delivered by the developers of the MUD platform, that allows gaming to take place. This is the purpose for which the original code was developed: to see what creative players would come up with, be it a sci-fi game inside the MUD or just a place to go to chat online.

At this point, in game-design terms, there are several decisions that have to be made. For example, what happens if you want to send two characters (or groups thereof) on the same quest? Is the entire game environment to be one big world in which this is not possible, or is the multi-player aspect selective, allowing groups to embark on quests at the same time in their own spawned alternative game worlds? Answering these questions is key to the game design—and will certainly complicate the game’s development unless it is left to the MUD admins to decide how this will be implemented. The result is a game framework that can be customized by those responsible for the daily running of the game proper.

For example, admins might choose to have a system in which the rooms and objects required for a specific quest can be copied to a room set that can be accessed only by those who are going on the quest. Access to the quest, therefore would be via some kind of in-game portal, separating out those who are taking part in a quest from those who are not. This resolves, to a certain extent, any issues arising from multiple players wanting to go on the same quest.

These solutions, and the game design that spawns them, derive from the fact that the environment is interactive. So the key differences between the non-interactive and interactive environments are as follows:

• Players cannot affect the game world in a non-interactive environment.

• In an interactive environment, the mere fact of interaction leads to some consequences for the player—chiefly that players can often sustain damage and even be killed during a game session.

Note

Player deaths can be at the hands of the environment (or non-player characters, otherwise known as NPCs) or other players. So-called player killer or hack’n’slash MUDs allow players to kill each other, which is more usually reserved for NPCs. These possibilities are brought about by the introduction of game networking, which is more or less unique to multi-player network games, be they LAN- or WAN-based.

In contrast, a dynamic interactive environment enables players to add their own content—or, in MUD parlance, become builders. They might even be able to create quests. Whether their in-game creations are allowed to kill off other players is a decision usually left up to the admins.

Open Systems

Interestingly, the underlying technologies for non-interactive and interactive MUDs are so similar—in terms of the data-storage models and possibilities that must be opened up to the admins to customize the environment—that they are usually based on the same code. It is the customization that makes the game, not necessarily the engine that drives it.

MUD systems are usually open systems by design. In other words, most of the best known MUDs are based on one kind of kernel of code that arrives on the server as a download and is essentially empty. These days, that kernel can be officially open source, freely modifiable, using a language such as PHP and open-source database support with systems such as MySQL. This means that the behavior, as well as the interface and look of the MUD, can be freely modified and re-used.

This is important in another way: the MUD represents a set of solutions to network gaming problems that exist for even the most modern of network games. In other words, if the core can be built on, the game can evolve past a text-based adventure game into something else just by having the interface and game-environment representation tweaked.

It is these visual and representational aspects that set a MUD apart from Second Life. The under-the-hood code ought to be remarkably similar; whether the data transferred is a textual description of a room or a coded description for graphical display, the issues are the same.

Security

Clearly, security is high on the list of issues that need to be considered. Luckily, a MUD is fairly easy to secure because the only place a hacker could have any influence at all is on the server. As long as that is secure, then the worst that could happen is a denial-of-service (DoS) attack (also called “spoofing”)—which easy to spot and not inherently damaging.

Note

We mentioned the possibility that players might introduce database (SQL) statements into their room descriptions, thereby potentially enabling Trojan-style attacks. These so-called SQL injections are also easy to spot and remove, but attention needs to be paid to them on the level at which the SQL statements are executed, as this may be performed by an account with system-level access to the database.

It is worth taking a moment to look at the potential weak spot that is the DoS attack because it applies to any gaming system. It has, in the past, also been the Achilles heel of MUD and other network-gaming systems with which one can easily interface using external systems.

MUDs are usually text based, accessed through an open protocol (Telnet) using plain-text commands enveloped within the protocol. This means that an automated system (bot) can be placed behind the client or in place of the Telnet client. This bot can even carry out automated tasks such as signing up for an account. Moreover, these days, multiple processes can run on a single computer, so multiple bots could be set up on the same machine. The amount of time required to crack most systems would therefore be drastically reduced—and the mere act of running multiple bots all trying to sign up for accounts might even cause the DoS to succeed.

Unfortunately, there are no “CAPTCHA” mechanisms possible to prevent such a scenario, as MUDs work over a pure text-based interface. Any challenge-response security mechanisms would have to be based on questions that only a human can answer, and this would prove to be difficult to implement. And although placing the server machines behind a firewall, thereby restricting access by IP address, would ostracize bots, so, too, would it ostracize legitimate players on LANs connected to the Internet. For these reasons, the MUD can be seen to be relatively unsecure.

In summary, although the benefits, in gaming terms, of the MUD system are that information exchange is minimized (it’s plain text) and a wide platform base is addressed (even cell phones ought to be able to handle Telnet), it does have a key weakness: The client is not specialized enough to guard against spoofing. There should be automatic systems in place to guard against such attacks, which are covered in Chapter 8, “Removing the Cheating Elements.” If no steps are taken to prevent DoS attacks, all someone would have to do is set up a series of bots to log in and spam the system with random text in a private room; this would slow down the system, crippling it for everyone else. Clearly, resolving this issue is key to understanding multi-player security in general.

Part of the challenge of text-based MUD (not to mention MUCK, MUSH, and MOO, all variants on the original MUD) design and implementation is that the interface is, well, text only, which requires a text interface for communicating with the system. The system is then responsible for interpreting the commands, carrying out the actions that they embody, and then relaying the result to the other players.

As a result, the commands themselves need to be fairly self-explanatory and easy to type; but they also need to be short, because they have to travel over a network—usually the Internet, which is not known for its speed and reliability in data transfer. (This was a reasonably big issue in the early days, but not so much now, as data speeds and reliability increase.) Historically, sensible limits were placed on such things as room descriptions (often limiting them to as few as 255 characters), and a paging mechanism was often necessary to display multi-page text. These practices helped to ensure that the widest platform compatibility was maintained, with few extensions for more advanced terminals.

Note

One early extension beyond plain text was support for ANSI screen control—allowing colors and reasonable layout control. Due to the multi-player, multi-platform nature, however, it became important that appropriate measures were taken to ensure that other display types were catered to. That’s why, in the early days of MUDs, users (players) had to choose their terminal type at the start of the gaming session—vt100, for example, being a standard text-only non-ANSI terminal. This mechanism, of course, assumed that the players were well acquainted with their hardware and could make the appropriate choices. Fortunately, although the clients were fairly dumb, these early users, typically computer-science majors, had above-average knowledge of computers in general, and client/server computing in particular. In the intervening decades, networked multi-player games have moved more mainstream.

MUD clients now exist that can emulate the screen (terminal) types and automate the interactive portions of the game interface by automatically inserting text. Rather than having to type commands, the player can now just click a button and have the appropriate command inserted. Furthermore, for certain games, interfaces exist whereby the player can be substituted by a macro—a kind of program—that can insert commands into the stream and analyze the results. In other words, it is one step away from automatic playing. This automatic playing is at the core of most problems associated with hacking. The ability to insert commands into the stream in this manner also highlights the lack of security once a player account has been created. There are no checks to make sure that the player, and not some automated script, is playing. The text-based model makes this easy: Everything is text, and a generic client can be used to play the game.

The basic text-based MUD game model centers on a server that contains data for all the places that can be visited. Also on the server is the logic for passing from one to the other and a communications layer that allows players to chat with each other. All the logic that relays the state of the game environment to all the clients and governs their interactivity is also part of the text MUD engine. Nothing is farmed out to the client beyond simple display chores; even the logic that dictates how the game environment is to be displayed is contained on the server, which must then provide exactly the text to be rendered (and any control codes) to the client. This is partly due to the use of the Telnet protocol for data transfer, which is largely text based, and relies on a client that is fairly dumb.

The basic MUD model can be tweaked and extended in many ways. For example, the Telnet clients can be replaced by smarter, custom-built clients capable of displaying better graphics, playing sounds, and even implementing some of the game logic. (As you will see in Chapter 8, this last extension is not always a good thing, as it is opens the door to cheating by proxy.) Some of the tweaks have been made to improve the text-based nature of the MUD itself; others allow for the creation of entirely new gaming experiences. Such tweaks involve changing the nature of the data exchanged, as well as changing what happens on the client side when it is received.

The preceding section had one example of this: dropping in an alternative front-end to provide the interface for the player. Other examples include richer graphics (rather than text) and may necessitate either streaming the data inline (as in the Google Earth approach) or synchronizing with locally held data that describes the immediate environment. The World Wide Web provides an additional layer for the distribution of a front-end, with two added advantages. The first is that the player doesn’t need to download anything. Secondly, the front-end can be properly adjusted to match the capabilities of the game on offer. An embedded front-end could be an appropriate middle ground between classic text MUD gaming and full-blown distributed client gaming systems. This approach could also feasibly culminate in an entirely proprietary interface that can even be used to extend the basic MUD in a proprietary fashion.

Graphics and Sound

At its core, a MUD is just a place where people can go to chat and occasionally embark on other activities. Even other flavors that add interactivity, objects, and role playing are just variations on that core theme. It is only natural, however, to seek ways to update this basic model to bring the appearance of the game up to modern standards. Because the core server-side processing will never be seen except through the client interface, it doesn’t need a lot of modernization. Adding the ability to move through the game environment in 3D or 2D, however, would be a good starting point for an extension. It would allow players to be more creative with their in-game persona (or avatar), as well as allowing fast recognition between classes of player (or even friend and foe).

Note

You’ve seen how a move from text to graphics has occurred as processing capabilities and networking technologies have improved. As a consequence, however, the server must farm out some of its responsibilities to client systems. The first place that this happens is in the graphics and sound that present the game environment to the players.

One approach might be to extend the GUI itself away from the basic text-based interface of the classic MUD, and on to a more typical modern-day RPG interface. Although this would make the game more accessible, it would still be a MUD; in fact, all that has occurred is a change the front-end. Since the gamer can get status information via the text interface provided by a typical Telnet MUD, it is easy to produce a front-end that can do the same, but display the results differently.

Taken to its logical conclusion, under this model, different players could have different visualizations, even if the underlying game was essentially the same—meaning that with very few logic changes to the underlying system, two players could cooperatively embark on games of different genres. This is an extreme case that probably doesn’t have any practical use, but it does illustrate the power and flexibility of the MUD model—provided, of course, that the rendering tasks are farmed out to the client. The server just sends a command to tell the client what to play (or display); the client is responsible for the rest.

Note

This also presumes some kind of synchronization of assets or inline streaming; if streaming is chosen, then the flexibility of the MUD is compromised slightly. If asset synchronization is chosen (the more common option), then there are a few other things to take care of, covered later in this chapter in the “Arcade Games” section.

Sound can also be introduced into a MUD, adding even more flavor to the gaming environment. Although sound was completely missing (beyond the odd beep) from the classic MUD architecture, it could be introduced/triggered as part of the extensions discussed here. In essence, the same arguments and implementation path can be used for sound as for graphics, with the additional possibility of allowing the player to introduce his or her own soundtrack via the computer’s CD player (for the PC platform, at least). The underlying interactivity model for MUDs can be used to trigger changes in environmental artifacts (things switching on, or other background sounds, for example) based on the location of the player in the game environment; adding sound simply involves slightly extending the core to identify a sound rather than some kind of descriptive display.

All of the above relies on the server being able to identify the client, or the client being able to interpret the result from the server in a certain way—displaying graphics rather than a textual description. This is, however, required only where text and graphics (plus sound) must exist in the same game space. If this is not required, then identification may not be necessary.

Security

Some form of security is necessary for custom, open, homogeneous, and heterogeneous architectures alike. Traditionally, however, MUDs have been weak in this regard. This was because the Telnet model relied on a very simple underlying architecture: a connection-based architecture. If the connection was lost, then the security layer was ditched, and the player would have to re–log on. Moreover, the sign-up process itself was fraught with issues relating to platform restrictions. In short, it was very easy to sign up with a bogus user name and password, initiate a session, spout rubbish or just lurk in the background, whilst the automated client did the same with another account. It didn’t take long for the server to become overloaded—the so-called denial-of-service attack having succeeded.

What can you do to prevent this? For a start, you can add a Web interface for the sign-up process, improving security and preventing DoS attacks by introducing CAPTCHA mechanisms. A CAPTCHA mechanism presents the user with a graphic of a word, suitably obscured to reduce the possibility that an automated process could identify the word in question. The user must then type the characters appearing in the graphic in the field provided. For example, Figure 2.1 shows a simple CAPTCHA containing the phrase “pure genius” with a pixelization filter applied. A human can more or less work out what the phrase is, but a computer would have a much tougher time. This is one simple way to keep the game universe clean—removing someone’s ability to sign up using an automated process. In addition, it puts the onus on a sign-up mechanism that is separate from the MUD itself, thus retaining the underlying simplicity of the system.

Figure 2.1. Simple pixelated CAPTCHA.

Of course you don’t necessarily want to prevent people from creating bots that try to interact in a way that is sensible. Some MUDs allow players to spawn robots that can be instructed to move independently of the player. These bots can even be made to emote and chat as if doing so independently, not just as a result of the human player manipulating them. (Typically, these are called puppets.) Such activities could also be used as a programming challenge or even a serious scientific experiment in machine-language learning and natural-language processing—not to mention a way to test the system in an automated fashion or enable others to help you test it from geographically remote locations. Indeed, much good can come out of such research projects, perhaps even helping future gaming and game security in spotting patterns of undesirable language elements. All this is to say that some automated gameplay is actively encouraged, and that too much security can be counter-productive in MUD gaming.

On the other hand, you don’t want to open the system to attacks, either. Fortunately, moving away from a text-based MUD and the Telnet protocol to, for example, a lightweight Java client will help to increase security whilst adding the benefits of a richer game interface—perhaps even a full-featured virtual world.

Whatever else gets added to the mix—be it a Burnout Dominator–style interface, which requires players to select game types by driving around, or new cooperative gaming modes—the basic model for arcade games remains the same: a client/server, pure connection–based, realtime gaming environment. In other words, it’s like a MUD, but with extreme performance, reliability, and data consistency.

Those extreme conditions extend to the amount of data that needs to be evaluated by the server (including physics, for example) in order to relay the correct in-game status to the client machines. This, combined with the number of players that can play on a given map and the number of maps available, means that the server is required to do an awful lot of processing just to keep everything moving along at an appropriate speed.

For each layer of complexity that is added to an arcade game beyond the basic MUD model, support requirements will grow exponentially. For example, adding graphics introduces a multitude of issues to be solved—from addressing performance problems to keeping all the clients current. One strategy is to stream assets inline using a Google Earth–style model, but the data-transfer requirements will potentially be huge. Adding multiple downloadable maps results in a similar problem—with the added complication that if they change, the server must have some way of determining whether all the clients have the same map. If they do not, then the map needs to be downloaded inline either before the game can begin or whilst the game is in session—which is itself a kind of asset streaming. This last option, streaming map updates inline, is unlikely, however, and potentially dangerous—after all, what do you do about dropped connections? The arcade model has no immediate answer beyond the usual: ending the playing session and disconnecting the player until such a time as his or her environment can be brought up to the appropriate level. All this is to say that the arcade model has a lot more to contend with than the MUD model, simply because it is more time critical. In fact, this is the key aspect that sets the two apart: a MUD is much less reliant on time-critical data exchange—and exchanges much less data, less quickly—than an arcade game.

Complicating matters is the fact that competition in the arcade-gaming market is fierce—indeed, this sector includes almost every genre, and is the most prolific of all models of the modern era. Because of this, game developers must work hard to be better than their competition. This competition drives the success of the market, but also means that the success of an individual game is much more vulnerable in the marketplace if any aspect of it is perceived as negative. This reality is observed by Greg Costikyan in his report “The Future of Online Gaming,” where he states:

That means anything that removes from the experience—be it cheating or network unreliability—will attack the success of the game. In game terms, the reliability of the connection is a matter of life and death. In other words, if the gaming system cannot combat the worst excesses of network lag, latency, and jitter (see Chapter 7, “Improving Network Communications,” for more information about these glitches), it is quickly rendered unplayable. Moreover, the gaming client—which must be proprietary, capable of displaying complex graphics, and capable of playing complex sounds—must also be capable of communicating with multiple versions of servers. Getting all aspects of the model right is a good starting point, even before the implementation of the game proper begins.

As in a virtual world (e.g., Second Life), discussed in “Virtual Worlds” earlier in this chapter, security in an arcade-style network game can both be made easier and be bolstered by the move to a proprietary client/server model. By introducing this measure of control at the protocol and encoding level, security can be enhanced at various stages:

Unlike in a virtual world, however, security breaches in arcade-style network games can have severe and lasting in-game consequences for players. This is because a player’s own progress in the game (think of an online game like Quake or an online RPG) relies on the game’s security remaining intact and on those with malicious intent being kept at bay. Admittedly, a security issue in Second Life might render some of the game environment permanently (or temporarily) unusable, but like graffiti in the real world, it can be cleaned up. It is much harder to “clean up,” however, if a player has been wiped off a game map and lost all his or her hard-earned in-game artifacts, be they experience points, in-game cash, weaponry, or what have you. For this reason, security must be foremost in the designer’s mind, because an inevitable side-effect of a game’s success is that it will become a target.

The problem is that it sometimes impossible to detect when a player or game has been subject to foul play, as the player will probably have been destroyed in a game-legal fashion—that is, by using the rules that determine the game logic against the game environment in a devious fashion. For example, suppose there is an exploit that enables a client to see the location of all other players on the map. In that case, a player could create a bot designed to seek and destroy other players. Such exploits have been found in games; these exploits involve sending data to the server that elicits a response containing more information than it should. In essence, the client spoofs the server into believing that the player is simultaneously present at all (or many) map positions at the same time. (Note that this is only possible in those games where movement is processed on the client and relayed to the server as status information.)

Arcade-based network games must react quickly. As such, the data-exchange model—how information is exchanged between the client and server, as well as any compression or encryption required—needs to be carefully planned. If a network-enabled arcade game is to work, data exchange must be fast, compact, and, preferably, obfuscated.

With respect to speed, LAN gaming benefits from the close proximity of the users involved in that data volume can be increased—meaning that there can potentially be more players on each map, larger maps, and more going on generally. In contrast, while Internet gaming benefits from a wider audience reach, there are considerable drawbacks, including slow network-reaction times, intermittent network connectivity, and the various security issues noted in Chapter 1. Because increasing the data volume is not an option, the game designer should instead attempt to construct the game such that less data (or more compact data) need be exchanged.

Let’s further consider the issue of obfuscation—that is, obscuring the data that passes from server to client and back in such a way to prevent cheating and other types of exploitation. For example, rather than sending data that looks like this:

The same goes for downloadable assets—maps, characters, weapons, and so on. Their representation, the game logic that governs how they are used, and the eventual effect of their use in the game must be obfuscated in some way.

The fact that the arcade-style model is based on a proprietary client makes data obfuscation—as well as general handling of the security layer—far easier. The game designer can dress up the data however he or she wishes because only clients for that particular game need to be able to understand it—although there might be client-side processing-power restrictions that make extreme encryption and compression unsustainable. Be aware, too, that the extreme performance requirements of the arcade genre and related network-gaming genres dictate that designers be creative in keeping the overhead as low as possible.

Text-based games are played in the browser as a collection of Web pages. Under the hood, this means they can be deployed using existing technologies such as open-source content-management systems (CMSes) customized for use in a gaming context. Games such as Project Rockstar, for example, use a basic CMS, overlaying forums, advertising, and other elements to provide an interactive interface. The fact that the game is also based around a turn-by-turn, overnight-update model is due in part to the fact that it uses technologies and services that are slightly more restrictive.

Some key concepts with respect to text-based through-the-browser games include the following:

As mentioned, game interaction in text-based Web games is reasonably low. This can be combated, to a certain degree, by the use of Flash. Flash games use the Adobe Flash platform to deliver a richer multimedia experience that can include video, sound, clickable objects, and a keyboard interface. In short, arcade games, RPGs, front-ends, and navigation systems can all be created using Flash.

The model works using a downloadable-content-plus-streaming-asset approach. The game can be downloaded to the target platform, and additional data can be streamed in through a Web connection. The players’ own statistics can then be fed back to the server and stored, just as with any other platform model.

The simplest Flash model is something I call the “cabinet model.” In this, downloadable Flash games use the networking aspect purely for storing high scores. (Again, obviously, some care has to be taken to combat the adverse effects of cheating.) More elaborate games can then be created that make use of the client/server relationship in other ways, delivering the front-end via the Flash platform. These tend to follow other game-type models, and need no further explanation here.

Note

The Flash model merely provides a way to deliver a better interface via the Web. It is not intended to be held up as some kind of vision of the future of network gaming, just an illustration of how such enabling technology, which is discussed further in the next chapter, can be used to build a workable game model relatively easily.

An up-and-coming game-type category that I call “alternate reality games” typically combines the Web—used to provide game-related clues—with the real, physical world, resulting in a hybrid of armchair and physical playing. Other forms of this game type can combine GPS location data with person-to-person interaction, and augment the real world with a virtual storyline and eventual goal. Purchase of materials such as game cards to be used within the game or in the real-world extension of the game provide interest, collectability, and revenue. Examples of such games include Perplex City, which, for the uninitiated, attaches a real-world prize to Web-based multi-player interactivity, real-world locations, and game cards. The combination is magical—when it works; whether they produce economically viable game models remains to be seen.

Note

As the market for these games matures, the games will almost certainly begin drawing on other technologies such as cell-phone text messaging, e-mail, and even face-to-face human interaction.