In This Chapter
To contrast with turn-by-turn games, this chapter looks at the issues behind creating online, real-time, massively multi-player games. Rather than rehashing the game-design arguments from the last chapter—many of the same principles apply—this chapter points out the differences, most of which stem from the following:
Client engineering. Clients are generally custom-created due to the real-time nature of these games, which brings some additional burden for both the design and development.
Network inconsistencies. These are hard, real-time systems; the Internet is not really geared up for that level of reliability.
Revenue model. The additional burden of the client engineering and network inconsistencies means that the revenue must be mainly direct, coming from ongoing subscriptions.
Audience. Given all of the above, the audience will likely be less casual, more discerning, and fickle—whilst also being very loyal, once won over.
Perhaps surprisingly, the server side does not change all that much. It’s still a repository for all the in-game data, from player statistics and capabilities to the environment and all the artifacts contained within it. Most differences will be a reflection of the system’s increased capacity requirements due to the real-time–update nature of the system. That means there is no such thing as a daily update; all updates have to take place in real time.
This facet of the client/server model naturally increases the complexity—and hence capacity—of the hardware systems. The result is that these games are more expensive to create, maintain, and run. Consequently, the price to the end-user will be higher. While turn-by-turn games can be free at the point of access, MMORPGs and online arcade games are rarely, if ever, afforded the same luxury.
This means that they have to be good. Very good.
This section revisits the definitions of two kinds of online multi-player games:
Massive multi-player online role playing games (MMORPGs)
Arcade action games
Why? These games represent two extremes. The first, MMORPGs, represent an extreme in terms of the number (expected number, anyway) of clients that will be connected at once or exist in the database. That’s the “massive” part—along with the size of the game environment, which has to be big to contain all the players. The second, arcade action games, represents an extreme in terms of the network speed and delivery of data. There might only be two players (or up to, say, four) at any one time, but they will be doing battle at a lightning-fast pace, thereby placing a great burden on the infrastructure in terms of expected response times.
The general MMORPG environment inherits from the previous chapter, in that the same kinds of possibilities for customization exist. That said, there is one particular aspect of this genre that the turn-by-turn model does not share.
MMORPGs tend to be aimed more toward hard-core gamers than turn-by-turn games—although in-browser casual MMORPGs, which don’t require the same investment in terms of time or money as the likes of World of WarCraft or Everquest, are on the way up. A few things make casual MMORPGs more accessible—simplified rules and less complex environments, for example—but essentially they are the same as their bigger siblings. MMORPGs in general are not turn based but are real time—meaning the environment has to be very reactive. This, in turn, means that the server can’t be the only place that decisions are made because the Internet reaction time might not allow this. So, there will likely be a split between the functionality offered by the server and the client such that the client can maintain some of the game universe by itself, and therefore communicate to the game server in an appropriate fashion. Since this involves a special kind of game system, perhaps we should discuss that now.
The game system will consist of:
A fully functional client
A server
A database system
In terms of the investment required to create the game system, one thing is clear: It will be an expensive undertaking, whatever the client platform. The client must be capable of displaying complex graphics (and the developer has to decide between 2D and 3D renderings), contain enough AI to ensure that the game flows in the face of potentially uneven Internet connectivity, and communicate effectively with the player. The client itself could be anything from a Java-based in-browser client to a full game delivered as a shrink-wrapped product.
Meanwhile, the server must be able to maintain multiple connections at the same time whilst also ensuring that the players who occupy the same logical part of the game universe have priority communications vis á vis each other, as in the previous chapter. But now, rather than having a daily update cycle, the server needs to constantly update itself with respect to the evolving game. This is nothing new, but it does show that the complexity level has jumped somewhat from the turn-by-turn game dissected in the previous chapter.
The playing infrastructure is very similar in many ways to the turn-based system you looked at in the last chapter. It is multi-player, but this time the interactions take place in real time rather than in a turn-by-turn fashion. Even real time–strategy games (RTS games) allow the session to evolve in real time. This also means that the player will be more or less constantly involved with the game during the session rather than it being a pick-up-and-play game, which can be put down as the player chooses.
Player customization is very important for MMORPGs, because the character (as in turn-based gaming), becomes the pivotal point. This could be as true for Burnout, a racing game in which cars can be customized, as it is for Everquest, World of WarCraft, and Eve Online.
It all comes down to a sense of ownership. This means that, as in the previous chapter, the individual characters should be completely customizable—not as a diversion for when the player has nothing else to do, but for recognition and in-game reasons. In addition, there should be a provision for the usual community functions, such as competitions, and a rendering of the in-game character as an avatar in ex-game areas.
The arcade action gaming model is a little different. Here, the emphasis is on the client software, which has to stand up to the action role. That means it must adapt itself to the network flow, depending on how many players are connected at a given moment in time, whilst also providing an accessible interface for things like high scores. After all, these games are less about a progression and more about instant gratification and round-based combat.
The client, then, is highly unlikely to be anything but a real game developed for a specific platform. By “real game,” I mean that it is not likely, for performance reasons, to be a through-the-browser experience. Rather, it is more likely to be a piece of software that is designed to make the most of a specific platform, be that a console, handheld, or PC. The amount of data transferred via the network is likely to be reasonably light, which is just as well because the transfer rate is likely to be high.
For those reasons, the server will need to be fairly lightweight, offering only the barest of configurations for the sharing of connections. It might even be prudent to avoid putting any logic on the server at all, save for basic routing for the incoming data: a match-up service, essentially, for gamers.
The database does not need to be constantly updated; rather it is there to store the result of each bout. It will need to keep track of high scores, however, and be sophisticated enough that it cannot be cheated.
What the previous section has shown is that these game models have a very similar anatomy, sharing a lot of the same characteristics:
High-speed reaction times (i.e., plenty of network traffic)
Live database connectivity (i.e., a persistent gaming world)
High-end assets (artwork and sound)
That means that unlike the turn-by-turn games you looked at in the previous chapter (with the exception of a real time–strategy game like Civilization), these games must be supported by custom client-side interfaces and will stretch the hardware to its limits. In this case, by “hardware,” I mean the client (the player’s interface on the game universe), server (where the player’s moves are stored, relayed, checked, and verified), and network (the bit in the middle that facilitates the multi-player aspects of the game).
Note
It is important to note that you will have to substitute the standard game design stuff for yourself as it relates to the single-player environment. This includes, of course, everything that is related to the end-user experience, such as the control scheme. In addition, because this is a fundamentals book, it does not spend time discussing how the level design should be set out. You are likely already aware that there are different styles of multi-player games: capture the flag, cooperative combat, etc.
In addition, the maps that represent the levels must be defined with the multi-player environment in mind, where appropriate. That’s because there are fewer constraints on what players will do in a given level when so many of them get together. Action games do not have this issue, as they tend to revolve around a constrained game environment (think of a fighting or driving game), but MMORPGs and FPSes have an additional dimension in that they are not constrained. That means the maps for such games have to stand the test of time, whilst also being as open as possible—and almost foolproof. In “Multiplayer Level Design In-Depth, Part 2: The Rules of Map Design” [GAMA01], Pascal Luban breaks this down into three challenges:
Durability. The map must be able to withstand multiple challenges and game sessions, whether they be cooperative combat or Capture the Flag (CTF) based.
Accessibility. Everything about the map should be pretty obvious; it’s not a single-player map where you need to have hidden elements and traps or puzzles.
Entertainment. It has to be fun, because if it isn’t, nobody will want to play the game, let alone the map.
On top of this, other action strategy and MMORPGs have additional constraints—such as open game environments, quests, and so on—that require different map-making and level-design skills. Although these are outside scope of this book, I will touch upon them and the mechanics that must support them along the way.
Performance is an issue with this category of games in a way that it wasn’t in the examples found in the last chapter. The gaming client is still a window on the game environment (which is stored on the server), but it reflects the changing state of that game environment, and everything in it, in real time.
Note
You might argue that a simple Telnet text-based RPG does exactly this, and that the number of players involved—and even the size of the game environment—qualify it as an MMORPG. That said, the text-based RPG is different in that it is text based, so the client requirements are that much less.
So gaming clients for real time action–based multi-player network games are custom created and must offer high performance. That means choices are usually limited to closed-binary or a Java-style play-in-the-browser solutions. This, in turn, leads to decisions such as whether to make the game available as a retail pack with some gaming hours included or a purely subscription-based model with a free download of the game client (Eve Online style). Games such as Unreal Tournament take the approach that the client and even some multi-player action is available for free, with the for-pay model adding to the single- and multi-player environments in a variety of ways.
There are, then, different kinds of clients:
Single player at the core, with multi-player game modes
Multi-player at the core, with no single-player game at all
The underlying question is, Where do you put the majority of the gaming logic? If you put it in the client, you risk being hacked (see Chapter 8, “Removing the Cheating Elements,” and Chapter 9, “Testing Network Games”). On the other hand, if you put it on the server, you risk missing updates. And if you split the responsibilities between the client and the server, you risk getting out of sync.
To understand this, let us look at a client that takes all the decisions locally, a client that shares that responsibility with the server, and a client that does nothing. We’ll assume that the game in question is similar to Eve Online, and a fighting game like Street Fighter IV.
The gaming client that makes decisions locally and relays the result to the server, and hence the rest of the clients, needs only to receive its view of the game environment. It will receive the commands relating to in-game entities from the other clients as the players make their moves. It will then calculate what happens next and relay the new statuses to the rest of the clients in the game.
In this model, it is imperative to put game logic in place to detect when one of the clients becomes hacked and prevent it from lying about the results of actions or the status of its own player in the game. This logic must go on the server. At this point, you may as well concede that the server should share responsibility for updates with the clients. In any case, it is the server that stores the persistent game state, so it might as well provide the logic to operate on that game state as well.
So, in this model, clients have the responsibility to display and calculate, but they relay that data to the server, which then checks and responds to all the clients with a central view of the game environment. In this way, it can detect and remove any cheating (we hope) and keep all the clients in sync.
The next step from this is a model in which the server handles everything and the clients just display the results. The issue with this approach is that, while it is secure, and while the client will be able to display much higher quality renderings of the game environment or be extremely lightweight (for Web use), it does require a very good network connection.
Clearly, deciding what kind of client to use is very important, and involves a trade-off of security against performance. Naturally, platform reach will come into play as well, in that if you want to reach as many potential players as possible, you need to create a client that covers that premise. On the other hand, many console gamers only play games on the console and not on their PC, so that has to be factored into the decision as well. The bit that doesn’t really change in all this is the server.
The MMORPG server is built around the same basic premise as before: data storage and some game logic that helps to describe/manipulate the environment and the players within it. The difference is that the game environment, and the players and things in it, are all that much bigger—as is the game logic that describes the interactions expected within it. In contrast, the action server has one central focus: speed of reaction time. Although it will suffer from many of the same issues as the MMORPG server (i.e., there will be many games going on at the same time), its role is somewhat reduced to managing interactions and results rather than a game environment, per se.
One thing that the servers will need to be able to handle is multiple incoming connections—including supporting some way to make sure that they all receive the same attention. You’ll look at ways of doing this in Chapter 10, “Network Programming Primer.” The server is also responsible for security and cheat detection; these topics are covered in Chapter 8 and Chapter 9. It is important to remember, however, that the actual game logic and storage are only one small part of the responsibilities of the game server.
There are several kinds of multiple server environments, depending on the game and how the game environment and entire system is split up:
Server per service (split up game from support). This approach is the norm for all game types, keeping the gaming servers separate from servers dealing with downloads, community issues, forums, and other kinds of off-game interaction. This might seem like overkill, but it is worth it in that it prevents something that happens on a non-game server from bringing the game server down. This sounds obvious, but like all obvious things, it can be overlooked.
Multiple game zones (big environment, many servers). This approach is for those games where the actual environment is just too big for a single server to cope with (as in Eve Online). This could also be a split by number of clients, of course. Added to that, each zone might actually be a server cluster; a prime example of cases where there are just too many players for one server, as well as an environment that is too big for a single server zone.
Distributed gaming (different servers for different maps/games). This approach takes the view that specific servers will be set up to cover specific requirements, be that in the form of specific maps or game styles. So you might have a CTF server and a frag-fest server, where anything goes. This is just another way of splitting the work-load—although it should also be noted that it is a good way to offer custom code bases, as well. That means two servers could run code with slightly different game rules, like the original TinyMUD customizations that led to MUCK, MUSH, MOO, and other derivatives.
How to break up the game environment and the players present in it is another one of those big questions in network multi-player game design whose answer differs depending on circumstances. Clearly, for example, LAN gaming doesn’t suffer from the weight of this decision as much as, say, Internet gaming. For the latter, a lot rides on the complementary services—for example, the database.
A database is a heavy application in terms of memory and disk space as well as processing requirements. As such, while it is possible to run a database on the same platform as the server, often it will be on a different machine. The database also needs to be accessed by all players (albeit through the server platform); as such, it is often grouped logically with the server platform itself.
The database stores everything the game needs in order to function:
Players’ status, history, customization, and location
Game environment
NPCs
In-game artifacts
Ex-game artifacts (community, etc.)
As with servers, it is probably a good idea if the database is not part of the server infrastructure itself; in this way you can split tasks across databases. Of course, this split can be done in a variety of ways:
Any discussion of database design can wind up running in circles because there is no one answer to the question of how a database should be set up. One approach might be to put the players in one database and the game environment and their locations in another. Then, when a player moves from one location to another, all you need to do is a) change the player’s location status in the PlayerDatabase, and b) display whatever the player might see, as taken from the LocationDatabase. On the other hand, you might choose to let the player move from one database to another, where the database contains the description of the players in a specific zone—and only those players—in conjunction with the game environment. This has a drawback, however, in that the player data must be copied from one database to another, which might be a time-consuming exercise. It does mean, though, that the load will be more evenly spread—which will make data access faster (you hope).
The discussion turns full circle when you consider the physical location and security of the database. Clearly, a distributed model is harder to keep in sync, but also potentially more robust than a model that sees all the data for one facet in a single place. The decision might be simpler for action games where locations just mean a place to stand and fight, but nonetheless, some of the same discussions will be had, especially when it comes to separating databases by function.
This follows much the same path as the discussions related to splitting the server park by function; you don’t want a high-volume message board on the same database platform as the main game database, because it might well slow everything down. Where the main bottleneck is likely to be, however, is at the networking side.
The protocol of choice for many games is TCP/IP—the same protocol used on the World Wide Web and the Internet as a whole. The reason for this is simple: reliability. That reliability comes at a cost, however: efficiency. In many ways, a more efficient way to use the network would be User Datagram Protocol (UDP); as its name suggests, it works by farming out much of the responsibility for the protocol’s management to the user (or, more appropriately, the programmer).
This is the pivotal decision, addressed in Chapter 7 and Chapter 10: Do you go for the inefficient—but safe—TCP/IP approach, or do you go for UDP, which is faster but only because it ignores things like packet ordering and guarantees of delivery? Many network problems can be solved by selecting the right protocol for whatever task is expected of it. For example, a good choice of protocol for a lossy application such as playing back low-quality video is UDP, which is a bad choice for anything that requires guaranteed delivery (unless the application is prepared to spend a lot of time checking that it has what it supposed to have).
Note
To make either of these protocols more efficient, yet another protocol can be used—this time at the IP level—known as multicast. Essentially, multicast means a single point sending data, simultaneously, to multiple recipients. It can help to make a networking protocol respond more quickly. That said, multicast lies in the realm of experimentation, having been tested in some very high-level military and virtual-reality applications, but not extensively in gaming.
As you shall see later in this book, there are three main problems linked with using networking in a real-time environment:
Latency. Slow data rate
Jitter. Unreliable data rate
Loss. Unreliable delivery
I didn’t mention these in the last chapter, because in that context they simply didn’t matter. In this case, however, they suddenly matter very much, because we rely on them to convey the status of the game, and everything in it, in real time. In Chapter 7 and Chapter 10, you learn to implement solutions that tackle these issues head on. In the meantime, however, you need to understand in detail their effects on the game from a game design point of view rather than a purely mechanical one.
Network latency, easily defined as “lag,” refers to a more or less constant delay on the delivery of data. This has a number of root causes, as you shall see later on. Latency is more common with TCP than with UDP, for the simple reason that TCP tries its best to deal with all the network issues at the source. UDP doesn’t suffer from latency as much because it doesn’t try as hard. If a packet is delayed, it tends to just forget about it, delivering it if and when it turns up. TCP, on the other hand, suspends processing until it gets a good packet stream or drops the connection entirely—in effect giving up.
The problem with latency is that it can make a game very slow. That sounds obvious, but it needs exploring a bit further. Latency exists on several levels, each contributing to the overall system latency:
Some of these—mainly network latency, control latency, and client latency—have a direct effect on the game as seen by the player. The effect of the network latency is compounded by internal server latency, which is in turn subject to database latency.
The solution to system latency is to make the network communication as efficient and consistent as possible so that it doesn’t get flooded when the action increases in pace and complexity. The server latencies can also be attacked by judicious use of resources and good system and database design. Given the quantity of unknowns, however, all network connections will have a certain latency, caused in part by the fact that the Internet has no service quality commitment. In short, nobody guarantees that the Internet will “work,” and there is very little measure of what’s working and what isn’t. The result is that, at times, the game will seem to be slow.
If you assume for a moment that all steps have been taken to reduce system latency, but that the Internet has a bad day, what is the net effect? Data will not be received in a timely fashion. That means the client will not be able to display the result of other clients’ actions in a way that is conducive to the fast action of the game. Humans, luckily, are very adaptive, and studies (“The Effect of Latency and Network Limitations on MMORPGs” [NETGAMES01], for example) have shown that latency can be quite high (1250ms) before the game becomes unplayable. The reason for this is in the design of the game. If the game is still fluid at higher latencies, then players will slow themselves down to compensate. Even if the battle is taking much longer to play out, the players will not necessarily notice the full extent of the latency at work.
The secret, then, is to slow down the whole system to compensate. So in an action game, the fighting characters could feasibly be slowed to compensate for the lower data transfer rate; in essence, the pace of play can be artificially kept in sync with the data rate—as long as that data rate can be properly measured. By a similar token, the action in an MMORPG or RTS could be made to unfold in a similar fashion (remembering, of course, that the rate of play has to be set to the network transmission [latency] rate of the slowest client). Otherwise, some strange synchronization issues will occur—some of which are akin to cheating, as the local player might be able to move much more quickly than anyone else. This would mean that by the time the player’s location data was sent in, he or she might have moved more than other players (something I call the “Matrix effect,” after the movie).
One other thing to consider is that only clients in the same logical game space need to match their latencies. If client A cannot see or be affected by client Z, then client A has no need to match client Z’s latencies until such a time as client Z moves within the sphere of influence governed by client A. So this requires a more or less constant conversation between the server and clients in the same logical game space to allow the client software to match the latencies with the pace of play for that particular vector within the game environment. At the very least, constant latency enables you to create a workaround that renders the game playable—if a little slower.
Unfortunately, it is quite rare that latency is uniform on the Internet. Perhaps in LAN gaming, you can be fairly sure that it will be—after all, you control the network infrastructure. A more prevalent latency-related issue for online gaming is the so-called “jitter.”
Jitter is non-uniform latency. That is, it is latency that arrives in bursts. It is highly irritating to players, as it results in the game constantly trying to adjust for late and out-of-sequence data packets.
Causes of network jitter include
Dropped packets, where packets arrive at buffers that are already full
Delayed packets, where packets are re-routed onto routes that are slower
Out-of-sequence packets, where packets in the same stream take different routes, which have different latencies
If the network protocol is UDP, then jitter is treated in a slightly different way than TCP; again, this is because the UDP protocol has absolutely no built-in defenses for packet control. As such, with UDP, there is less jitter, but the net result is that there are no guarantees for the correct delivery of data or streams in the right sequence. TCP, on the other hand, comes with jitter built in because it spends so much time trying to correct for the vagaries of Internet connectivity. If, suddenly, a part of the Internet goes down and packets are re-routed through two different routes, thereby arriving consistently out of sequence, then the TCP protocol will start to jitter as it rearranges the packets.
Let’s assume you have taken the workaround option from the last section and made a game that dynamically alters its speed according to the prevalence of network latency detected across multiple clients all in the same logical game space. For one reason or another, let us assume, too, that the latency is variable—in other words, you are experiencing network jitter. This will result in the pace of the game also being variable. In turn, the player will be unable to adjust his or her own playing speed to match the latency because it is constantly fluctuating.
Somehow, this jitter needs to be smoothed so that players can (albeit unconsciously) continue to adjust their rate of play to match the system latency. Otherwise, they will be unable to settle into the game, as different characters will move at different speeds and the game environment will skip, lurch, and flicker its way to conclusion.
As with latency, however, there is no real solution to jitter. There are just things you can do to limit its effect on playability. The first is an extension of the solution outlined in the preceding section: to vary the latency in a way that gives the players time to adjust. Although this is a complex approach, if implemented correctly, it ought to give the game a chance to adapt properly. The second solution is to use dead reckoning and AI techniques to estimate the actual movements of players in the environment and then correct the estimations once the information is available. There are several kinds of dead reckoning; we deal, in Chapter 7, with two of them:
Trajectory dead reckoning, in which equations are used to estimate movement of objects in the game
Behavioral dead reckoning, in which historical observation is used to try to second-guess players in a very rudimentary fashion
An example of the first might be a bullet fired from a gun. Based on knowledge of the game environment and objects within it, you can deduce that a bullet fired from a gun will always travel in a straight line, and you can calculate the net effect without waiting for the clients to play out the sequence individually. This same trick can also be used with player-controlled vehicles and the like. If the vehicle is not traveling in a straight line, however, or comes to a point where it might have a choice as to whether it continues in a straight line, you need to swap to behavioral dead reckoning. For example, if the vehicle comes to a corner, you can roughly estimate that the player will try to cover the corner by slowing down, so clients (or the server) can calculate this and adjust its estimates to match reality as and when the data arrives. Sometimes, however, the data may not arrive—resulting in network loss.
Network loss can mean different things—loss of packets, loss of connectivity, and so on—but the net effect is the same: data that ought to have been there isn’t. This manifests itself in the game in a variety of interesting ways, from stuttering movement to artifacts appearing and disappearing seemingly at random. At its worst, it can have an effect on the outcome of the game as players all try to do things at the same time, only to find that other players have moved the game on in a different direction.
Note
Not only is this annoying, it can sometimes make it appear as if players are cheating. In fact, dropping data packets, as you will see in Chapter 8, is actually a rather good cheating tactic. The issue is separating natural loss of data from those trying to fool a dead-reckoned system by actively cheating.
One of the worst network loss problems is loss of the connection. This can happen at two levels: logical and physical. On the logical side, network connection loss is usually temporary. It happens when the network gives up for a time, usually due to a simple time-out. If the time-out persists, then the connection loss will become physical. In other words, the systems will become disconnected—rather than suspended—at the network level. Any of the resources assigned to the player on the server or clients will be returned to the controlling system, the player will no longer exist in a logical sense within the game environment, and his or her part is taken over by an AI controller.
We look at this in more detail later on, but again, there are no cures. There are only things you can do to make sure that when it happens, it doesn’t affect the game too much. Clearly, in a two-player online action game, the game is over if the connection is lost—and can only barely continue if there is substantial data loss. In other games, such as MMORPGs and RTS games, players might even force a disconnect to save their position in the game (as a form of cheating) or they might need to be replaced by an automated player temporarily or permanently.
Dealing with data loss goes hand in hand with the various strategies that you looked at earlier for dealing with network latency and jitter. They are connected by the ways in which we choose to design solutions to the problems related to networking at large. These three problems are typical of all network games. As such, the bulk of the remainder of this book concentrates on ways to avoid these problems—or at least mitigate their effects.
This topic might be seen as a kind of footnote by some, but it is important to mention that the available revenue models are very similar to those explored in the last chapter—with one overriding exception: We have a direct method available through the client software, which we own and have developed.
That is, these games are usually
A single-player version with multi-player add-on to justify the price
A pure multi-player sold in a box
A free client with a for-pay multi-player experience
That means most of the revenue will be generated through direct means, which, in turn, will help to fund the debt incurred by the development of the game. In essence, it is more like the regular game-development funding model that many mainstream development outfits will be familiar with.
The direct revenue model is the easiest to leverage and appreciate—but a game with no pedigree will find it hard to get a foot in the door. This is because gamers already spend most of their available gaming time in their favorite MMORPG, and weaning them off it will be next to impossible.
In any case, the typical model used is based around sales of clients with hours of online multi-player time built in. These hours could be unlimited or they could come with a cap. In MMORPGs, it is usually likely that the hours are capped in some way, whereas for action games, there is not likely to be any cap with the retail package. In other words, for some genres of game, it is acceptable to expect players to pay for the online multi-player experience, whereas with others it is not. The latter usually follow some kind of subscription model for additional hours.
Using the subscription model to generate revenue is another way to leverage the multi-player environment. Here, it is typical (as with Eve Online) to distribute the client free of charge and then charge players for the possibility to play online with other players.
Expansion packs (the World of WarCraft model) represent another way in which players can be charged for buying what is essentially the same game, with some modifications and extensions, but nothing really ground-breaking. All they are designed to do is offset the cost of maintaining the game and make some profit.
Yet another way to directly generate money is via the in-game economy. Here, you charge players to buy credits that can be exchanged in-game for various things, be they items, playing hours, or virtual property.
One aside: It is possible to create a demo version of the game (single player) like the Unreal Tournament model and then get people used to the environment in the hopes that they will, eventually, actually give the developer money for it.
Less common with MMORPGs and action games is the indirect revenue model. The games discussed in the previous chapter relied on this model because they are delivered through a platform for which the developer could not charge. This was partly because the components used to build them were freely available, and partly because of the expectation of the gaming public that Web games are essentially free. You become less reliant on this model, however, in cases where the product, in a box, stands on its own and generates direct revenue.
Nonetheless, sponsorship is still a real option, especially for games based on some kind of intellectual property that has a real-world equivalent:
In addition, the advert revenue stream is available to games in this category, although not advertising schemes that require payment through a pay-per-click model. It is highly unlikely that a player will suspend his or her play session to click a banner while playing an MMORPG or action game. This may prove to be more lucrative via other parts of the game, however—i.e., related sites, community (forum, etc.) sites, and so on. That said, it should not be relied on; the best way to raise revenue will probably be through the direct method.
Real-time gaming and the Internet would appear, at first sight, to make very uneasy bedfellows. You might say that they, like water and electricity, are simply not designed to mix—and that when they do, chaos may ensue. There are, however, many tricks you can employ to deal with the worst excesses of the state of the underlying network, most coming from the programmer’s own arsenal (covered in Chapters 7 through 10). Some will evolve naturally and some will need to be designed in, but all are made possible thanks to the increases in computing power that allow us to become ever more devious in our efforts both to create robust client/server game platforms and foil hackers and cheaters.
Most game engines, including, for example, the low-cost Garage Games engine (used in Tribes 2), come with networking support. This solution can then be built on, at a very low cost, to produce stunning gaming environments. It then becomes the task of the game designer to create a compelling gaming environment in which to play and innovative support for the in-game interactions. While arcade games like Street Fighter IV can get away with a less in-depth environment, MMORPGs like Eve Online need to offer more than just in-flight combat and must deliver over and above that simple core premise.
This extended attention brings money: direct revenue in the form of pay-to-play and indirect revenue in the form of trading in-game items and sponsorship and the inevitable books, guides, tactical manuals, and add-ons that provide the lifeblood of any network gaming enterprise: innovation and income. Without both, the game is in danger of perishing. In my opinion, any game creator who does not plan to mine every opportunity for both innovation and income generation is planning to fail in the long run. The strategy guides and offline concerns cannot be ignored; someone is going to profit from them, and it had better be the game’s creators.
On the other hand, failure to recognize that these external critiques of the game will exist is to ignore a very constructive stream of criticism. With that criticism, expressed through the forums or in published guides, comes the understanding that the game can be improved upon. And improve you must to retain the interest of the paying gamer. After all, these are people who pay a premium and expect to get something more than just a single-player game against other people in return. Failure to deliver that experience will see the whole enterprise fall apart through debt. After all, it is unlikely that the game hardware will be pre-funded by the initial membership alone.