In This Chapter
No two games are created exactly the same. Different network game types might involve tackling different design issues. Moreover, it is not always entirely obvious which design issues are actually important. Put another way, it is easy to get bogged down in minutiae and overlook something that later becomes important.
This chapter rounds up some of the design issues posed by various game types. You’ll determine which network technologies will best support the type of game you want to build and how your target market will affect design decisions. You’ll also consider the ways in which your game might (or might not) take advantage of the Internet, as well as the pace of your game vis a vis update cycles. All of these factors feed into your hardware and software decisions as you build your game—which must be robust enough to support the choices you make.
The chapter begins by looking at some general categories of multi-player networked gaming models, as well as different network game types. The chapter then examines the principle design issues factoring into the creation of network games, taking into account the game type, technology, and available resources.
Obviously, you know you want to build a network game, or else you probably wouldn’t be reading this. And you probably want it to be a multi-player game of some description. But of course, there is more to the equation than that.
This section looks at different kinds of game models that can be used for the network-game architecture. The aim is to cover the structure and styles of gameplay that can be built into the game at the design level—or, roughly speaking, the types of games you may want to build. This is important not just because it enables you to envision your game more clearly; it also helps you estimate what kinds of resources (i.e., hardware and software) will be needed to support the game after it is deployed.
First, I’ll build some rough categories into which different game types can be placed. Naturally, in a constantly evolving market, categorizing games that already exist is no small task—and new ones keep being invented all the time. For example, before the genre now referred to as “Grand Theft Auto style” was defined, there had never been such an open-ended, free-roaming, detailed backdrop for a game. So rather than trying to cook up some industry-standard definitions, I’ll simply put forth what is unique or different about various game types. Then I’ll compare some common game structures so you can get a feel for the kinds of design decisions that must be made. (And these are design decisions, and not implementation decisions—even if they might at times feel like it.)
Note
There are few things worse than a networked multi-player game that has evolved poorly from a single-player game. The design is important!.
This first rough category—pseudo single-player online games—is an interesting one. It is founded on the idea that the player competes against a relatively unseen playing population. That is, other players are abstract—indeed, they might as well be non-player characters (NPCs). There is literally no in-game interaction between players. Players know they are competing against other players, but only in a league table–based way.
This approach can be used to create all manner of economy-based games, where “winning” is determined by financial success relative to other players and progress is measured locally. In other words, the player’s own progress is measured against himself or herself, with only the outcome of that progress communicated to the server. Games such as Civilization, for example, or Blizzard’s excellent Diablo, are examples of this game mechanic, as is the upcoming Cities XL.
If it is simply a case of uploading a high score, then this kind of game needs very little server-side support—although if the data stored on the server is cheatable (e.g., high scores), then this has some implications with respect to security. That said, if you go one step further along this path, you’ll see that you can build some logic into the server to extend the concept. For example, an online pseudo single-player online game might be designed such that the player progresses against himself or herself, but the actual gameplay takes place on the server.
A one-on-one network game might be a digital version of a board game, such as chess, or a game that falls into the action genre. Either way, a one-on-one game pits one player against another, usually against a fairly static backdrop. These will include fighting games, for example, where two players fight it out against each other in real time. The proposed network component in Street Fighter IV, when it eventually comes to the console platform, would be a good example of this.
As with pseudo single-player online games, one-on-one games make use of league tables as players progress through the game—but now each player’s progress is measured against another player’s progress rather than as a global struggle. This gives rise to all manner of competition taking place on game servers as players challenge one another.
Generally speaking, in these games, the server is a conduit for the game, but in some cases the networking is peer to peer, in which case it is basically a match-up service. There’s an advantage to using a client/server setup for the communication, however, in that the server can act as referee—which means that the clients don’t have to. Nonetheless, as you shall see, the peer-to-peer route is equally acceptable—indeed, it can even prove to be much more efficient, with higher performance, than games that go through a server in real time.
These games move away from the one-on-one approach, instead providing a meeting place of sorts for multiple players. For games in this category, a server is more or less obligatory—typically a client/server (one-to-many) relationship, giving the system the opportunity to synchronize all the clients and adjust communication rates based on the slowest participants.
Note
Although the client/server model is typically used with these games, multicast and similar technology could, feasibly, be used to deliver the experience.
One type of game that can fall into this category is cooperative games. These see players divided into teams (a.k.a. “clans”) and carrying out a variety of missions against other teams. The server’s role is partly to maintain the state of the game environment (although clients ought to be able to do that themselves) and also to support communication. In other words, the server acts as a multi-way chat server as well as a pure game server—another reason to use a client/server model. That said, game-state synchronization should always take precedence over chat and communication that is incidental to the game at hand. Games such as Unreal Tournament illustrate the clan model, while other games in the war-zone genre sometimes offer player-to-player audio communication.
Of course, loose team play can occur in other kinds of multi-player networked games, like map-based multi-player games. Indeed, the map-based multi-player games category is arguably a sub-category of the team-based multi-player games category; certainly, these two categories overlap somewhat. Game types include capture the flag–style games with teams or single players competing against the game environment and NPCs or against each other, with the aim to capture the enemy’s flag. The maps are local, sometimes part of a single-player (with bots) incarnation of the game in question, sometimes delivered through a server (having been designed separately from the game itself).
The reason I have separated this type of game out is in the title—that is, they are “map based” as opposed to “team-based.” Put simply, the maps are more important than the teams. Indeed, there might not even be teams, as in Unreal Tournament 2003, where players could opt to play on maps where there were no clans, making it every player for himself or herself.
Most cooperative multi-player games, of course, fall into the category of team-based games because the team, rather than the map, is the important component. Even when the map is the same one for each game, the interaction of the teams makes for a different game each time.
Real time–strategy (RTS) games are different from the games discussed so far, which are real-time action in nature, in that they are almost turn-by-turn in execution. In fact, some of the more popular RTS games tend to be strictly turn based. That means each round consists of one move per player, with the game unable to progress until all players have made their move. This category is notable in that players tend to play locally, with other players represented as characters within the local game. Only the actions (or perhaps just the results of the actions) of each player are communicated, via the server, to the clients.
Note
RTS games pose a number of problems, such as what to do if a player has disconnected, is not moving, experiences network problems, is cheating, and so on. These are dealt with in due course in Chapter 7, “Improving Network Communications,” and Chapter 8, “Removing the Cheating Elements.”.
The issue with these games is that the game code is terribly complex, requiring a lot of processing—the majority of which simply cannot be handled by the server. An example of this complexity can be found in an online Civilization game. As a result, the advanced behavior must be distributed to the game clients. This leaves the game open to all kinds of cheating, such as “adjusting” the output of the game so that the other clients believe a player has advanced more than he or she really has (although it should be noted that as far as I am aware, Civ has not been subject to cheating—but the risk is there).
Note
You might have realized that, aside from providing cheat detection and synchronization, the game server is not strictly required. You could play RTS games in a peer-to-peer environment. What is mandatory, for complex RTS games at least, is that the client must do some of the processing that would otherwise be done on the server. Otherwise, the server could not keep up. This is, conceptually, halfway between client-server and peer-to-peer gaming.
The “massive” in “massively multi-player online game” simply means that there are a lot of players—tens or even hundreds of thousands—playing at the same time or that they play against a massive game environment with many locations, artifacts, and players, be they real or NPCs. World of WarCraft, for example, is an MMORPG in which things can get quite complex.
With MMO games, the game environment must be big enough to house all the players without seeming claustrophobic. Apart from that requirement, MMO game types can vary from RTS and action-style games to sports simulations and other genres—provided they appeal to, and have the capacity for, a large number of players.
Although you could argue that this is essentially a type of MMO, the RPG aspect of these games implies something a little different from a purely action game or even an RTS game. MMORPGs usually add a dimension to what might otherwise be a game involving little more than wandering around randomly shooting things. That is, with MMORPGs, there is a sense of travel and progression that is not necessarily prevalent in pure hack-and-slash adventure or combat games.
This dimension is generally a result of the role-play aspect of the game, in part because actions taken ex game are almost as important as those taken in game—including the choices the player makes when establishing his or her account, any customizations the player makes, and interactions that occur in the player forums—with the one having an effect on the other. For example, in a space-trading game, trading in illegal goods has an in-game effect of being chased by police, and an ex-game effect of getting a reputation. That reputation may in turn result in an icon displaying next to the player’s name in the community as well as in-game effects—for example, making that player a target for other players who seek to score bounties.
Now that you have a handle on some of the key game types, it is time to compare the features of some common implementations of the core game types. It is important to realize that the differences have both positive and negative connotations for a project, and will affect the realization of the final product—including whether it is implemented at all. A good game idea can be ruined by the selection of an over-ambitious game type given the skill, experience, and resources available to the game developer.
Turn-by-turn gaming is a very specific implementation of a network multi-player game in which each player makes his or her move in sequence, after which all the moves are executed simultaneously by the game environment (be that at the client level or the server level).
In contrast, with real-time action games, all the action occurs simultaneously—although this does not preclude the possibility that moves can happen asynchronously. In fact, in a game where moves can take a certain length of time, moves could be queued up (an approach taken by some MMORPGs, such as Age of Empires, or Starcraft, to smooth the pace of action). There are also client-side differences, which extend to the interface as well as the way in which the client software interacts with the player.
There are some advantages of turn-by-turn play over real-time action from a design and implementation point of view, not least the fact that they can be implemented very easily on the server with most of the logic on the server or with the responsibility split between the clients and the server. The disadvantages are that the game must be updated on the server, and action is relatively slow. Even so, this model is great for casual games where players expect to play only for a very small period of time each day.
Note
One of the easiest turn-by-turn mechanisms to implement would be a daily update system to update the game environment. This gives players a long time to set up their moves, which are then evaluated at a specific time of the day.
In contrast, real-time action games, obviously, are updated continuously, which implicates the game server and database in a period of player-driven update cycles. This, in turn, has implications for performance, synchronization, and all kinds of issues relating to the efficiency with which the database can be updated. These problems generally do not exist with the turn-by-turn approach unless the game is an RTS game. RTS games tend to happen in pseudo real-time, but a timer mechanism is sometimes used to make sure that the moves are taken within a certain period.
MUDs and real-time action games have quite a lot in common, even down to the information exchange. And like a real-time action game, a MUD game—part chat system, part adventure game (complete with exploration and triggered events), and part RPG—happens in real time. The difference is mainly in how information is interpreted—and that is the responsibility of the client software. This interpretation might include using the client software to display a text description in a text-based MUD, or to display graphics if a different client is used. It is entirely feasible to create a text-based MUD server that will generate graphical information that is only visible to a client that understands it, thus elevating the experience for the player to something resembling a real-time action game.
Interestingly, when you combine the MUD system with the real-time action system, you get a MMORPG—a modern rendering of an old-style MUD, but with much more emphasis on gameplay than casual chat. While the original text-based MUD format was very low tech—meaning much of the game logic sat on the server (in fact, the only client-level logic tended to be keyboard shortcuts and other aids to help with playing the game)—the modern MMORPG is high tech, which means that some of the logic must be shared. At the rendering level, the client still bears the responsibility, as well as bearing the responsibility for some in-game decision making. These decisions usually revolve around estimating the effects of various network-level issues, as well as estimating the outcome of combat where the fluidity of play is more important than keeping artificial synchronization. Of course, the role of the server is to maintain synchronization when, as will happen, the local copies of the game environment advance at different speeds. Games such as World of WarCraft, Eve Online, and Second Life all rely on multiple server clusters, client-side rendering, and inline decision making, just to keep the environment reactive. Without these, the whole façade would fall apart.
NPC combat is one example of a game type in which the decision making has to be split between the server and the client. Specifically, the server has to control the NPCs, but the clients will play out their interaction locally, sending information about the interaction back to the server. So the server can choose commands to be sent in a batch, and the client can execute them. Pure multi-player games don’t have this problem, because each in-game player is mirrored by a real-life player in front of a piece of client software. On the other hand, they share some of the same issues relating to the time required for players to decide what course of action to take and to subsequently take it. The solution is almost the same.
The trick is to make sure that the client receives updated instructions before the queue runs out. At the same time, it needs to relay the results of the interactions back to the server; if the interactions result in a “kill,” the server must be informed, as must all the other clients. (This is not so different from an RTS-style interaction.)
The problem is, what does the server do with differing ideas of what the status of the NPCs should be? In other words, whom should the server and the other clients “believe”? (This issue is akin to the RTS problem mentioned previously.) To rectify this, checkpointing can be used to make sure that the “real” view, as held on the server, is relayed to the clients. This capability is not necessarily needed in other game types.
Player combat is part of both MUD and real time action–style games. It can take place on the client with data relayed to the server. It has issues similar to those associated with NPC combat. The key difference between the two is that, if you allow player combat in a real sense as opposed to “us against the world” (and simulated friendly fire), then you open up a Pandora’s box of issues relating to what to do with a dead player. Some games—World of WarCraft springs to mind—work around a premise of re-spawning the dead player in more or less the same state as he or she was when killed. Other games might choose a harsher option: lose everything and re-spawn in a “safe” area.
Note that “combat” doesn’t imply warfare per se. Player combat might just as likely occur in a driving game as a shooting game. Either way, synchronization issues abound as the various clients play out their local scenarios and try to keep the environment more or less level for all the participants. Generally speaking, the faster the game, the more likely client-side decisions will be needed over and above the server side evaluation of the evolving game session. Additionally, fast-paced games will need more synchronization than slower ones.
All network games are generally based around one of two network architectures: client/server or peer to peer. Even a game that uses a browser as the interface will subscribe to one of them, most likely—in fact, almost exclusively—the client/server model. (The exception to this is if the server is acting as a conduit for a peer-to-peer game without actively participating. This, however, is rare.)
Note
The client is the software that the player uses to interact with the game environment. The server stores the results of that interaction. The client and server might be the same physical machine. The client/server model discussed here relates more to responsibility than physical or logical entities.
Certain games lend themselves to a specific architecture. For example, two-player action games lend themselves to the peer-to-peer architecture, while MMORPGs can really only be handled by client/server setup, even when there are multiple servers.
The design of the client, and the way that it is implemented, is dictated mainly by the target platform and market. For example, it is unlikely that a developer would design a browser-based game for delivery on a modern console. Rather, these are more likely to involve the use of a standalone client, which is a piece of software that can be installed on the target platform. The advantages of using a standalone client are mainly speed, control of distribution, and the possibility of charging a fee for the pretty box.
In contrast, in-browser games use a variety of different technologies to deliver the client experience. They are played in a standard Web browser, which has the advantage of portability—that is, any platform that can support the Internet can support the game. On the other hand, charging for such games is difficult both psychologically as well as in practice.
The design of an in-browser client will vary greatly depending on the game type and the technology used to build the game: basic HTML (supported everywhere), dynamic HTML (using JavaScript), Adobe Flash (supported where there is support from Adobe—likely not to be consoles), and Java applets (supported by a virtual machine on many platforms, again excluding consoles). Basic action, RTS, and even MMORPGs with real-time action can be implemented using Flash or Java applets, while non–real-time action RTSes, MMORPGs, and everything in between (except real-time action) can be created using basic HTML. The interface only gets prettier and easier to use with dynamic HTML in the mix.
Opting for a browser-based game design has some implications with respect to hacking and automated play because everything the browser does is transparent. This applies to the communication layer as much as to the logic layer; since the protocol, HTTP, is fairly open, one can reasonably expect to be hacked at some point. That means if you opt for a low-security solution like JavaScript or HTML, the game logic should reside on the server rather than on the client. (Luckily, this is quite likely to be the case, as client-side processing is not common in such in browser game models.) On the other hand, the client can be made to do some quite impressive things using dynamic HTML—which is fine, except that it leaves the game vulnerable to automated play. Again, the traffic is transparent, and if any kind of encoding is used, a quick analysis of the JavaScript will yield the mechanism used to encode—which is less than helpful. Flash and Java don’t have that problem, nor does a standalone client, as the code is hidden by virtue of the fact that it is compiled. (As you will see in Chapter 8, what can be compiled can also be decompiled and disassembled—a possible security concern. There are, however, ways to combat that.)
So, what are the implications for the game type? That’s easily summed up: If you are creating a game with real-time action, distributed processing for the sake of smoothness of experience, and high client volumes, it is better to go for a custom-install client solution. If, however, you’re just starting out and want to make an RTS or even a basic MMORPG without the bells and whistles, or you are just testing ideas, then an in-browser game is faster to develop, easier to correct, and will reach a far wider audience.
The aim of this section is to encourage best-fit design principles as opposed to attempting to bolt networking capabilities onto an existing design with no real thought as to which game model would be best. It first looks at how a single-player game is different from a multi-player game, and then at how you can add network support to a game design. Next, it deals with how multi-player support can be designed in as well as the different kinds of multi-player support that a game might include. Finally, it looks at how the design process can be used to test ideas using prototyping through low-cost, low-technology infrastructures. This is often a good idea because the balance of a multi-player networked game can only be decided once the game has been experienced in a multi-player environment.
Note
In this case, the “balance” dictates how the various players and NPCs interact, and what the possibilities are with respect to their capabilities. The balance of the game is also dictated by the rules that govern the game and the interactions in it. All these things must be tested before the game reaches beta testers.
I’ve said it before, but here it is again: bolting on networking to a single-player game rarely works. These are just a few of the problems that can result from this approach:
Lousy gameplay
Inappropriate security
Exposure to reverse engineering
Lack of testing
One of the biggest problems is that single-player games have logic contained within them by necessity. Otherwise, the game just wouldn’t work. For a game like Unreal Tournament, this isn’t a problem—except for the possible proliferation of bots (automated players), proxies that offer automatic aiming, and so on. But even these don’t attack the actual gaming logic, and are reasonably easy to detect besides (as you will shall see in Chapter 8). The real issue arises when a single-player RTS is turned into multi-player RTS. Because the resulting game has logic embedded that is part of the game, it is open to hackers. So, in a game like Civilization or Age of Empires, for example, game interactions can be easily faked (see Matt Pritchard’s “How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It,” Gamasutra.com, July 24, 2000). All this is to say that the transition from single player to multi-player requires that the very game engine be adapted to allow for the issues raised here. And that means it is better to design a robust networked multi-player solution from the outset—a task that starts with adding network support.
Suppose you want to design a single-player game to be played in a large online game environment, populated at the server side by NPCs (automated bots). There are many things within this framework that would need to be sorted out before you can even think about what happens when multiple players log onto it:
Note
Rather than reinvent the wheel here, I have taken my cue from a paper entitled “On the Design of Multiplayer Online Video Game Systems” (Hsu et al) [HSU01].
Scalability. Does the server scale with respect to the expected number of players (or at all)? This is not necessarily a linear relationship—some games, such as RTSes, will scale more easily, while others (Multiwinia, Eve Online) will need elaborate multi-server solutions.
Delay. This is also known as the latency of the end-to-end connection (covered in Chapter 7). Different game types have different needs with respect to delay; an action game will require very low latency, while an RTS can usually get away with intermittently bad latency due to the way the game unfolds.
Robustness. With respect to how robust the entire system is—both physically (machine drop-out) and logically—the question is likely to revolve around what happens to the other players when a client drops out, and how this is dealt with. It clearly has more impact in a two-player action game than in an MMORPG.
Consistency. Is the game state consistent across all clients? How does one maintain synchronization on the Internet?
Cheat-proof. Who’s checking the actions of the players, and what actions are taken automatically or manually to resolve possible instances of cheating? Have you done enough to protect the system against cheating, including automated play?
Easy to charge. How do you decide how much to charge the players, and how easy is it to allocate purchased units to players?
Hsu et al. note that “The first three factors favor the distributed architecture, while the last three favor the centralized architecture.” Let us now examine the different architectures and how they change with the type of network game to address these six areas of concern.
In a client/server architecture, multiple clients are connected to a central point. This allows for a central point of security, but also represents a weakness in the sense that there is a single point of failure. Figure 4.1 shows the topography, from a logical point of view, of the client/server architecture.
The communication layer at the server must allow for data to flow from each client, in and out, so all the connections are bidirectional. This is not unusual; it is the same as the request/response mechanism used on the World Wide Web. What is different is that the load is likely to be balanced roughly in each direction, whereas a normal client/server mechanism might be heavier on the download (to-client) side than the upload (to-server) side.
In the case of a game with a low load, multiple clients can connect to single server. If the load rises, however, this may need to be adjusted to a multiple-server system. A single server can cope with only so many clients; estimating this load is a function of the game type. This only becomes more complex when addressing the need to manage clients’ logical existence with respect to the database. The database scheme, therefore, becomes very important, as does the location of the database with respect to the game server.
In terms of scalability, the client/server model is fairly poor. This is largely due to the use of multiple resources and databases for MMORPGs, the most common kind of game implemented under this topography. However, for RTSes and other games that do not require a large amount of server-side processing (i.e., simple Web-based games and those games in which the game logic is distributed), this may not matter. That’s not to say that they scale well, just that it is unlikely that the developer will saturate a single server if all it’s doing is serving Web pages—however dynamic the back end might be.
The delay, or latency, of these systems is also potentially quite poor. All traffic must pass through a central point, so the regular line latency is amplified by the system latency—a point that we cover in Chapter 7. This doesn’t change by game type, either. Whether you’re designing an RTS, action, or MMORPG, the best you can do is try to compensate for the latency by using clever programming.
Naturally, you could say that the client/server model is fairly robust across game types, at least from the point of view of client dropout. It is a design issue as to what you do in these circumstances, as noted previously. However, it was also noted that the single point of failure makes the system much less robust than other topographies. The consistency of the game environment, however, is likely to be very high, because the server holds absolute responsibility for making sure that it is so. This also helps to cheat-proof the system, because even if one of the clients does try to cheat, the cheating can be detected and corrected—almost without the cheater being aware of what has happened. This level of control also makes it easy to charge for game time, which is obviously desirable for those kinds of games based on a subscription model.
The opposite to a centralized system is a distributed system; in game networking, that is known as a “peer-to-peer architecture.” As the name implies, in a peer-to-peer network, each client is connected to every other client without the need for a central server beyond that of setting up the connections. In other words, there may be a matchmaking component offered by a central point to facilitate the actual setting up of the peer-to-peer network, but afterward, the server need play no other part. Examples of peer-to-peer networks are those used for wireless gaming, which is a very localized application, up to true Internet peer-to-peer gaming, where machines connect to each other using Internet technology. Figure 4.2 shows the classic peer-to-peer topography.
In this model, obviously, communication with the server is less important—but security is even more important than in other models, as there will be no cross-checking of the clients’ behavior. Therefore, elaborate peer-to-peer security is likely to be required simply to stop people trying to get ahead. You can also can build AI techniques for cheat detection into the game client as well use the game design to try to limit cheating. The wider game could be designed to make cheating less attractive, but that might just take the edge off the game, as the very reason for cheating is often that the player can get ahead in some way.
In terms of scalability, this model is potentially very strong—that is, as long as individual machines are not expected to connect to every other machine in the game simultaneously. So for RTS games in which player interaction is limited to, say, eight to 16 (or maybe 32) players, the model is scalable in that there can be as many games going on at the same time as there are client machines. The same holds for two-player action games; in fact, this topography favors such games. MMORPGs, however, are a different question. It would not be very practical to try to implement an MMORPG using a peer-to-peer network.
For those games that do lend themselves to the peer-to-peer topography, the latency is reasonable. At least, it depends only on the players involved, and there is no central point to factor into the latency estimations. The network is also quite robust, given that there is no central point of failure, and that one client dropping out is unlikely to affect the rest of the network. That said, the game design must take account of the client dropping out with respect to the ongoing game session. For some game types (such as RTSes), this will be easier to deal with than with one-on-one action games.
In terms of the consistency, there is a risk that the distributed peers will become desynchronized unless great care is taken to make sure that they are resynchronized. Part of this also has implications for the cheat-proofing of the game system. In fact, a distributed network game is not very cheat proof, as there is no central point to referee the clients. This leaves the door open for clients to lie to each other, giving false accounts of interactions that occurred during the game session.
Because the network is distributed, the game will play out as many times as there are clients. So, for an RTS with eight players, eight games will be occurring simultaneously. If one of the clients chooses to mislead the others, it can be hard to spot; designing in anti-cheat mechanisms is part of the whole development process.
A distributed network is not very easy to charge for. And once a player has bought the game, charging him or her afterward using some form of a subscription model is probably not possible. Then again, because the player is no longer actually consuming any of the developer’s resources, charging may be inappropriate anyway (depending on the game model).
In addition to centralized and distributed architectures, there is a third option: mirrored servers and clusters. This offers a good approach to increasing reliability. Essentially, it means there are two or more servers that need to be synchronized, but not necessarily in real time, providing a moderately scalable platform. Figure 4.3 shows the mirrored topography.
In Figure 4.3, you can see that the game environment is likely to be designed in such a way that it can be divided into logical zones. This reduces the dependency on a single server and helps to split the load, but increases the complexity of the system.
Until a player moves from one server to the other, the other server does not need to know or care about them. When the player does actually move, then, it raises a synchronization issue. If the zones are divided by a physical or logical barrier (think teleport or doorways), then this becomes easier. Otherwise, there will be some common ground between the servers, and you need to design the game in such a way to make sure that this is dealt with properly. The overlapping virtual property runs the risk of being hard to deal with.
The main issue is that the latency will be high for these skirmishes, as there will be a high number of players in a restricted space existing on two servers. This means that an MMORPG could find itself suffering from different problems at the edges of zones. For example, if a robust approach is taken, entities on different sides of a zone wall might not be able to interact even though they can be seen. This can also manifest itself in exploits devised by canny players that can enable them to obtain an unfair advantage in certain circumstances. On the other hand, if a loose overlap is allowed, then the speed of gameplay at the edges of zones might be compromised as the servers do double-updates in order to a) stay in sync, and b) allow the game to be played out in real time with respect to their own clients. One other aspect to the multi-homed approach is that it also allows for multicast for local clients as info can be sent out in bulk at once to all clients. This can help to increase performance—at least in theory.
In terms of our criteria, the mirrored solution will perform reasonably well in all categories, whilst a clustered server may be the only way to obtain sufficient scaling for many large MMORPG projects. Because it is an almost centralized topography, it has all the advantages of the central server in terms of security, consistency, and being able to monitor and charge for game time, but with the added robustness of a semi-distributed platform. This architecture can be expensive to set up, however, as multiple server machines will be required—something that should feed into the decision process.
Having tackled the networking aspect, you can now look at the actual multi-player support types that you could select for the game. This is not as simple as it might at first seem, as there are a few points to address.
By definition, more than one player will play a multi-player game simultaneously—but there are, of course, different kinds of multi-player games. For example, players might be playing in a tight group (RTS), a wide group (MMORPG), or one on one (action). The kind of multi-player game helps dictate the network topography and game type or style. You can, for example, extend the concept of game servers for squad-based and map-based multi-player gaming, where different servers handle different aspects of the game.
One thing to remember is that more players equals more complexity—but it is not a straight-line correlation. In fact, it is actually a logarithmic relationship. If you add one more player, you more than double the complexity; but if you add 10, then the complexity increases only slightly. Add 1,000 or 10,000, however, and the complexity starts to increase drastically, again. Note, too, that the risk of hacking and cheating increases roughly in line with the popularity of the game and number of players in the game.
Location-based gaming describes the influence of the position of the player in the game environment on the architecture that is used to implement the game environment. This will have an effect on the way the game is set up in terms of data storage. Part of the decision with respect to architecture revolves around the correlation between the physical servers and the logical setup. For example, different kinds of games can be:
Level based, in which a player plays on a level with other players, and he or she can move from one level to the next after achieving some goal.
Map based, in which players play together on a map, never leaving that map until the end of the game (think cooperative combat and capture-the-flag gaming).
Open free-roaming, in which players can go anywhere that their ingame status allows (like an MMORPG).
Artificially constricted, in which players are restricted to a specific construction in the game, such as a racetrack.
The approach taken to the game-environment design will feed into the way the game infrastructure is designed. For example, maps might be distributed for a map-based action game with each client having a local copy—an approach that is clearly not possible for an MMORPG.
Location-based gaming, then, is an important part of the decision as to how the game is to be put together and an integral part of adding multi-player to the single-player game. One other aspect is being able to detect cheating and hacking.
If a player cheats while playing a single-player game, that player cheats himself or herself but does not damage the experience one iota for anyone else. Not so in a networked multi-player game. Indeed, cheating and hacking in a multi-player game is likely to be endemic if the game is popular. For this reason, it is important to the longevity of game that cheating be able to be detected and dealt with at the client and server level, which is why I have devoted an entire chapter to this topic: Chapter 8. The methods for doing so must be ingrained into the game style and design, not bolted on afterwards. In addition, they must be tested properly.
This is partly an incidental discussion, but the design process—and the decisions taken to select the game type and infrastructure—can be tested using low-tech solutions as the game idea is developed. For example, you can use MUD or in-browser games, which have very low technical requirements, to test the game logic, rules, and balance before investment is made in a full client/server solution. It helps, when designing a complex system, to be able to prototype as soon as possible.
That means part of the design process could actually be a development process, because much of the existing infrastructure already exists. It might not look as pretty or be as versatile as the end result has to be, but it will work, and will give a good idea of how the end result will play. Even if you design a real-time game as a turn-based game by eliminating the action element, you can test and balance other important aspects that help to deliver the experience.
All this is to say there is nothing wrong with starting with a very modest type of game and then moving it up through the technological levels until it is as rich as you want it to be. Along the way, you will make excellent decisions as to how the game should be constructed and how the players will interact.
Here is a roundup of the decisions that need to be made before any further action can be taken. First, the developer needs to decide what kind of network technologies the game will use. Options include
LAN. This is restricted to local play on a network of physically close machines, offering high security, high speed, and a low incidence of cheating.
The Internet. This is a global wide area network (WAN) of geographically diverse machines, offering variable speeds (depending on client platform and quality of connection), low inherent security, and a potentially high incidence of cheating.
Wireless. This is a close-proximity peer-to-peer approach or a method to enable Internet gaming. It offers low speed due to the WiFi protocol. Security depends on the device and settings, and there is a possible risk of cheating.
In addition, you need to choose a target market on which to concentrate. This might not be the only market at which the game will be aimed, but it should be the principal one. Examples might be:
Hard core. People for whom gaming is a large proportion of their free time.
Casual. People for whom gaming is a fun diversion, but who wouldn’t necessarily invest a lot of time in maintaining a networked game presence.
Mobile. This refers to gaming on the go, social gaming, and Internet gaming, predominantly in a casual way—although the actual gamer may classify himself or herself as hard core.
Another key decision is whether the online component is the game proper or just part of the supporting feature set that maintains the community of players. For example, resource-sharing games like Little Big Planet would fall into this second category. Some ideas to consider with regard to implementing the online component as part of the supporting feature set might be:
High scores. Here, secure high scores are fed to a central server in Xbox LIVE fashion.
Community features. These include forums, avatars, competitions, and so on—things that extend the game (whether it’s played online or off) and make it more fun to play because of the networked component.
Message exchange. In-game, or ex-game communication between players in a controlled environment is often a part of a healthy collection of community add-ons.
Next, having decided (we assume) that networking is going to be an integral part of the actual game logic and not just added on, you must decide on the pace of the game:
Real time. Action happens in real time, and the player’s actions are immediately apparent on the screen, as in a first-person shooter.
Turn-based real time. The players queue up events, which are executed in a linear fashion as they take turns, as in a real time–strategy game.
Turn-based delayed action. This is strictly turn based, where a player takes his or her turn and cannot move again until other players have moved. A turn-based delayed action game could be, for example, a daily update game, a two-player game like chess, or a play-by-e-mail game.
This choice of pace of play will influence also the update cycle—i.e., the rate at which the game environment is updated with respect to the playing out of the game logic that drives it. There are essentially two variations:
Updates are player driven in most models, except where a fixed update cycle exists. So players who do not move or otherwise interact may stall the system, as it will not update on its own (unless that update cycle is part of the design). This will be discussed further in the next chapter.
All of these factors feed into the hardware and software decisions that make up the platform. It must be robust enough to support the choices that are made; indeed, the realization of how much resources may be absorbed as a result of a particular decision may well lead to that decision being overturned.