![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
MMOGs are arguably one of the most complex technical endeavors that developers can currently undertake. Each instance of each game is a complex simulation made up of millions of lines of code and billions of graphical elements, all executed on huge clusters of the latest computer, storage, and networking equipment. All of this technology runs simulations of artificial worlds and manages the interaction of millions of concurrent players. Game developers must focus on every creative and technological detail in the game. Developer organizations are tasked with making all of the critical decisions regarding what technologies will go into the development of a game, as well as figuring out what kind of and how much technology will support their game. If you're new to the games industry and its terminology, the next section is for you. If you're familiar with the industry and its terminology, please feel free to skip down to the section titled Sizing up the game.
Critical taxonomy of an industry (lingo)
In the movie industry, films are segmented into genres, such as action and adventure, drama, romance, horror, and comedy. Games too are classified into many genres, including first-person shooters, puzzle games, casual games, party games, role-playing games, racing games, and simulations. But unlike movies, the games industry has added a new dimension to its genre classifications by classifying how a game is played and whether it can be played with more than one player.
The most familiar type of electronic game is the single-player game. This type of game pits you against the computer or against the odds. From a business perspective, creating a game in this genre is just like creating any other consumer product, in that the business does not incur any product development or operations costs after the product has shipped. The only infrastructure you need in place is one to manage sales, marketing, and distribution.
Multiuser dungeon, multiuser dimension, multiuser domain
Multiuser dungeon, dimension, or domain (MUD) games are typically text-based, multiuser, role-playing games. These types of games allow multiple people to log on to a central server and share a generally text-based adventure. These games date back to the time of serial consoles, mainframes, and minicomputers. MUDs pre-date not only PC games, but the PC itself. According to a Wikipedia article on MUDs, the first one started in 1977 (see Resources). From an infrastructure perspective, a MUD requires very little when compared to other forms of online play, such as multiplayer online games and MMOGs.
Multiplayer online games cover a broad array of games that support anywhere from one to dozens of players. In these more casual games, play is limited to teams of up to 32 players. The types of multiplayer online games comprise anything from team-based, first-person shooter games such as Half Life and Unreal Tournament, to online versions of more traditional parlor games such as poker, chess, and checkers. It stands to reason that the infrastructure required for these types of games is not as complex as massively multiplayer online games.
Massively multiplayer online games
MMOGs include household names like EverQuest, World of Warcraft, EVE Online, Guild Wars, and Lineage II, to name a few. These games are deployed globally and support millions of players. This type of game requires the most complex of infrastructures, which are replicated and deployed within data centers spread around the world. The development community often describes MMOGs as persistent worlds. From an infrastructure perspective, they are identical.
A persistent world is a simulation that keeps running whether players are logged in or not. The primary difference between persistent worlds and MMOGs is the audience. Persistent worlds tend to target smaller audiences and have non-traditional customer sets or business models. Second Life from Linden Lab is an excellent example of a persistent world that is not considered an MMOG. Persistent worlds are often the appropriate classification for simulation and game technologies used outside of the entertainment industry, such as weather forecasts, battle simulations, global climate models, and oceanographic simulation.
One of the best things about playing in MMOGs is the option to interact with large numbers of real people in a variety of collaborative and competitive situations. This has attracted people to online games from vast geographic and socioeconomic spectrums. Since a person is represented in the game by an avatar that is socially, geographically, and economically equal to all other players (at least it starts out that way), games have a democratizing effect on the communities that play them. This effect enables interactions that are often not physically possible among people due to geographic distance or any other number of factors. A relatively new subcategory of MMOGs, termed massively social games, has arisen to leverage the ability of games comprising global communities. Players actually form social networks, encouraged by game devices such as traveling virtual pets that carry messages from desktop to desktop or virtual 3-D chat worlds. These game users get to decide the look and feel of their avatar or character, determine what will happen to them, and control access to their world in ways that are not possible in the physical world.
The game platform is the end-user access device to the game, also technically known as the client side. The major game platforms are console, PC, handheld, and mobile devices. Another platform that is typically overlooked is the arcade. In the United States, the arcade industry has never recovered from its heyday in the late 1970s and early 1980s. However, arcades remain popular in Japan and greater Asia. Recently, handheld and mobile devices have steadily become serious business. Mostly popular in Asia and Europe, these platforms are finally catching the eyes of the big industry players, as indicated by recent acquisitions. This article, however, focuses on the two most popular game platforms: the console and the PC.
By now, many people, and especially those who have had kids at any point in the past 25 years, possess intimate knowledge of this primary accessory for the television. In the early 1980s, there was Atari and Intellivision. The latter half of the same decade brought us Nintendo and Sega. Today, there's Sony® PLAYSTATION®, Microsoft® Xbox, and Nintendo.
Console game systems represent a huge segment of the games market within the United States, Japan, and parts of Europe. An ever-evolving market, all current and next-generation consoles to date have the ability to connect over broadband connections. Yet, this segment of console play has yet to prove its economic viability.
Ever since the Nintendo Entertainment System first hit the market two decades ago, many people have repeatedly predicted the demise of PC game play. What these people fail to understand is the economics of writing software. As long as PCs are a commodity, there will be an economic draw to develop games for them.
Every year, there seems to be an article that predicts, or laments, the demise of PC gaming. In this author's humble opinion, PC gaming is not going away any time soon -- for many, many reasons. For example, PC games have the lowest barrier to entry for developers. PCs also are arguably the most popular game platform in the whole of Asia. In addition, network-based game play was popularized on PCs. The open nature of PCs allows for companies to experiment with new and innovative hardware and software. Because PCs have fundamental utility outside of game play, there will always be a large installed base of them, which in turn creates a market. Technologies developed for the PC seem to continually find use within PC games, starting with the mouse and moving on to color graphics and PC-based technologies such as 3-D acceleration, multichannel audio, networking support, Web-based games, audio input, real-time text and voice chat, and even multithreading. Adventurous PC game developers have adopted all of these technologies to enhance the play experience. There is no indication that this dynamic will change anytime soon, so expect PCs to be a globally popular platform for all types of games for the foreseeable future.
From an infrastructure perspective, it used to be the case that you could build an online game server infrastructure that would support any online-capable client platform. With the recently introduced console platforms, that no longer seems to be the case. This new trend introduces an additional layer of complexity for game developers, which is beyond the scope of this article.
Dividing up the globe, online game style
To manage the complexity of online operations, the industry uses several terms and a standard methodology for breaking down the physical world into manageably sized chunks.
To address ever-growing global demand, multiplayer online game companies select sites in geographies where it is believed there is sufficient market to warrant the investment. Each global player community is serviced by several strategically located data centers. Each data center may serve a region or country.
Multiplayer online games often have many more game sites than an MMOG, and even have a licensing mechanism by which individuals and companies, such as broadband operators, can host instances of their game. Each site is designed to support a player community bound by geography. The size and geographic distribution of the player community is highly variable.
Patterns for managing game world size
Regarding multiplayer online games and MMOGs, two different "patterns" are used to provide the multiplayer experience. Both patterns divide the total player community. In general, player communities are split into copies of a game world or instances of a battlefield, racetrack, and so on. No other form of entertainment in the history of humanity allows for thousands or even millions of people to concurrently actively participate in a sport or storytelling. Currently, game experiences just aren't very fun with 10 million of your fellow humans.
For MMOGs, the determination of world size is made based on both technology and market. That is, game designers pick a number of players a world will hold based on entertainment and economic considerations. Game developers try hard to maximize this number to reduce infrastructure.
For multiplayer online games, the number of concurrent players in an instance of the game is primarily determined by the technology used in the engine. Most multiplayer online game engines created for sports, first-person shooter, and racing games can adequately handle 16, 32, or 64 concurrent players.
A brave new (single-instance) world
A few notable companies, such as EVE Online's creator CCP, have created single-instance MMOG games, and to date their experiences have been positive. These companies are pioneering resolutions to the playability and technical issues with single-shard MMOGs. Of these issues, content creation for single-instance MMOGs must be solved. It seems that enabling player-created content may be a solution. Player-created content is not a new concept in online games, but the ability for players to extend the game world removes this largest barrier to single-world online games. Allowing players to add to the game brings up all sorts of issues, including issues of game governance. It has been demonstrated repeatedly, both inside and outside the games industry, that interest communities can dramatically broaden the appeal base of a game, as well as extend its revenue-generating lifetime.
Other playability issues of single-instance worlds can be addressed. The resource-scarcity issue (for quests) can be solved by creative application of game play, such as a quest system that manages quest resources based on the number of active players requiring those resources. Vendor and area crowding is another consistent conceptual issue with single-instance worlds. This can be avoided with creative approaches to trading. "Virtual" vendors and quest giver non-player characters (NPCs) are just two examples.
The technical issues plaguing single-world games can also be combatted. Well-documented techniques allow a software system to expand and contract dynamically, such as optimized grid applications (see Resources). These technologies allow the technical infrastructure required to support a single game instance to expand without disruption to the existing game. This leaves one last technical barrier: latency, or the effect a player's physical location has on game play. Fortunately, other industries that rely on global real-time systems have solutions to this problem. A geographically distributed, financial trading desk is an excellent example of a system that has to respond to global user interaction in real time.
The benefits of a single-instance online game to developers are a dramatically reduced cost of development, deployment, and operations. The benefit to the players is dramatically expanded playability.
Given the fact that MMOGs are single applications that have dozens or hundreds of copies deployed globally that support millions of users, sizing the technology needed is a tremendous challenge. Like any complex problem, you first need to think in terms of breaking it down into smaller, more bite-sized, digestible problems. However, even at a more easily understood level, various issues with MMOGs can make it difficult to know where to begin.
There is an axiom that states, "It is best to start with the UI." In a game, the user interface is made up of complex 3-D graphics, 2-D menus, six-channel-sound dynamically triggered symphonic music, volumetric sound effects, 3-D positioning and movement, and 2-D navigation. With so much rich interface at one's disposal, only two technical metrics on the client have any impact on the game's server infrastructure: network throughput and latency requirements. As a result, understand these issues first when trying to figure out the size of the physical infrastructure required in building an MMOG.
Throughput is the amount of transactions the system can handle at any given interval, such as 1 million transactions per second. Latency or performance is the time it takes the system to complete any given transaction (for example, 40 microseconds).
It's worth emphasizing that throughput and performance are two separate entities. Performing 1 million transactions a second does not mean each transaction can be performed in a millionth of a second. Performing 1 million transactions per minute means you can process 1 million one-minute transactions in parallel. Transactions still take a minute to complete. Transactions per second (TPS) is not an appropriate measure for the class of applications that strive to be classified as "real time," and online games fall into that class.
That said, the primary critical measure for any game to be enjoyable is response time. To that end, you might ask, "What is a reasonable response time?" For a game such as chess, it may vary wildly on the skill of the player. Multiplayer online games accessed through a game console have hard-and-fast performance rules that derive from the fixed refresh rate of the display device. Specifically, the entire game must be updated before the next refresh of the display. For televisions, that is every field, or 24 fields, a second. For PC games -- currently the dominant platform for multiplayer online games -- the requirements are much higher. Most PC game players today strive to do much better than 60 frames a second.
For games, user input must be sampled to calculate what change or effect it has on the environment, at which point updates must be sent to the server for those changes to be coordinated with all of the other changes going on in the game. Finally, the server sends the result back to the client and upon receiving the results, can then visualize the update -- all in much less than a 60th of a second. Fortunately, with modern commodity processors, these operations take microseconds to calculate the impact of a user's actions.
Now that we've established a distinction between the two predominant modes of playing online games today, commonly referred to as multiplayer online gaming and massively multiplayer online gaming, it's important to understand how each differentiates player experience and game type, and how each has tremendous impact on the infrastructure required. For those with the computer-science inclination, multiplayer online games and MMOGs represent architectural patterns that result in drastically different operational models. As of the writing of this paper, the interactive entertainment industry has not created standard names for the multiplayer online game and MMOG architectures, so we'll refer to them as "homogeneous" and "tiered," respectively. Now I'll explain what this means in terms of the infrastructure required for these games.
Multiplayer online game infrastructure layers
For homogeneous-type architectures, servers perform functions that are not stratified. In many cases, several instances of simple online games run on a single server and don't even have to communicate with each other. In slightly more sophisticated cases, servers communicate with each other as equals to support the multiplayer online game. In this architecture, each server contributes equally. When the game grows, more servers are simply added to the mix. If implemented properly, the game engine will begin to utilize the new servers automatically.
In contrast to the homogeneous-type architecture, players within the tiered- or shard-type architecture connect to a layer of servers. That tier communicates with another layer of servers that performs a specific function, which in turn communicates with another tier performing another function. The network serves to hold it all together. In addition, when game capacity needs to be expanded, servers are added to each layer.
Tiered- or shard-based MMOGs use dozens or hundreds of copies of the game world to support the massive number of players. The term "shard" is commonly used to describe individual servers that are designed around a traditional application pattern. The pattern is a multitiered Model-View-Controller (MVC). Each shard in an MMOG is divided into three primary layers. The database layer sits on the bottom. On top of that is a layer commonly called the game engine (or game server). Over that layer is what is commonly referred to as the front end. This front-end layer is often divided into several thin layers, such as login, border, boundary, and load balancing. Finally, all MMOGs are topped off with the game's firewall and, of course, a connection to the Internet.
Many factors significantly impact the performance of an MMOG, such as:
- Average amount of data transmitted per second per player: This is critical to understanding the network and front-end infrastructure.
- Target number of total players: The number of players who will buy the game and play it must be estimated accurately.
- Total target number of concurrent players: Of all the players registered, calculate the number of players who will be online at any one time.
- Target number of total players per geography: Geographies should be divided up in accordance with the number who will be playing the game in different areas of the world (for instance, Shanghai, Beijing, Seoul, Tokyo, Sydney, Los Angeles, Seattle, Austin, New York, London, Paris, Munich, and so on).
- Target number of concurrent players per geography: Once the world is divided up according to the game, determine the number of players who are going to be online in each geography.
- Target number of concurrent players per instance: Often difficult to determine, this is a calculation for each shard of the number of players to be supported.
- Size of "world data": A metric that is controlled, but varies entirely, this refers to the amount of information that will be stored in the databases.
- Size range of player-related data: This refers to the amount of persistent data a player will generate during play time.
In general, sizing an MMOG starts with figuring out how large the global target user community will be. Next, you need to determine the target user community per geography. Once you determine the number of sites per geography, you'll have the number of users to be supported per site. You then combine this information with the number of users who can be supported by each instance of the game world, resulting in most of the basic information needed to size an MMOG infrastructure using traditional architecture methods.
To support the massive number of players that make up the "M" in MMOG, the server side of the game is a complex configuration of dozens or hundreds of servers that perform various functions. This infrastructure is often divided into layers, or tiers, like a cake. Each tier performs a related set of functions. Typically, an MMO follows an architectural pattern loosely referred to as "an n-tiered architecture." In its most basic form, this architecture can be broken down into three tiers: front, mid, and database.
Online games are prime targets for attacks. They seem to attract all sorts of individuals and groups who wish to do harm. The front line of defense has to be a combination of high-performance network hardware and good security features, along with a layer of firewalls with a proven track record of defending against denial-of-service, packet fragment, and other typical brute-force attacks on Internet sites.
The sizing of the middle tiers depends on the architecture of the game engine itself. This is the tier where the game engine -- the heart of the simulation -- resides. Sizing of this tier depends almost entirely on the implementation of the game engine. With that said, the bulk of MMOG engines can handle between 200 and 600 players per server; with current-generation processors, more companies are claiming they can achieve a 600-user-per-game engine server. On the positive side, non-traditional game-engine design has allowed them to support 10 times those numbers on their servers.
The database tier has to process transactions in an environment as near latency-free as possible. Every move a player makes, as well as every item, object, and monster is at least one data element within the game's database. Oddly enough, even the largest game worlds are miniscule compared to data warehouses employed by thousands of companies around the world. The schema for a game is also fairly simple. These factors allow a multiplayer online game engine to take advantage of the power of parallel database technology, such as symmetric multiprocessors, and other large memory systems. With a little care, most of the working set of a multiplayer online game can be pulled into the main memory of a large system.
When a person logs off from an MMOG, the persistent world of the game keeps running without that person in it. All information about what the player has done, where the player has gone, and what the player owns is saved (read more about persistence of MMOG design in the Resources section).
The nature of database activity in MMOGs is very specific. The transaction load is characterized by a large amount of simple updates and reads. For example, consider the fact that every move, item attribute, and character attribute is often kept as a data element within a database. Every time a player moves the game character, position data is updated within the database. In an MMOG, literally hundreds of thousands of players are performing these updates constantly.
Generally, MMOGs utilize the same database technology as banks, insurance companies, trading desks, and medical records systems. But unlike typical business systems, the data schemas in MMOGs are deliberately kept simple, and the transactions executed on these tables are all simple updates and reads. Unfortunately, the scale of MMOGs is beginning to reach the architectural limits of traditional databases. Many studios are examining the use of non-traditional database engines that can provide performance and latency technologies. Experience shows that memory databases provide superior performance and low latency. Very well-understood database engine technologies do exist that provide Atomicity, Consistency, Isolation, and Durability (ACID) transactions for latency-critical applications (see Resources for more information on ACID). These technologies often distribute data among several servers, spreading the queries across these systems, which allows for the dataset to reside completely in memory, and several systems to execute queries in parallel.
Once you understand most of the variables involved in sizing an MMOG and you have a rough idea of how to approach the sizing of each individual tier, your focus can shift toward the two most critical factors in sizing an MMOG: network throughput and latency requirements.
Sizing large infrastructures is a science unto itself. Oddly enough, the same techniques used to size a new freeway system can be used to size an MMOG. In short, the technique involves finding both the key capacity factor and the key performance factor. In other words, identify the single largest bottleneck. The benefit of finding a key bottleneck is that any resources applied to fixing that bottleneck will be proportional to the payback. Ideally, applying resources to key bottlenecks improves performance of the entire system by factors of 2, 10, 20, and 100. If bottlenecks are found, and addressing the bottleneck will only improve performance by 5 or 10 percent, you should assume that time would be better spent elsewhere. It will be difficult to justify any expense to fix a bottleneck that has small return. Resources are easy to justify when a key bottleneck is found and performance can be improved by a large factor.
Under these parameters, key bottlenecks are those that put the most constriction on both "how many" and "how fast." To further define, a key bottleneck is characterized typically by these two measures. Once this metric is found, you can use it as a factor to size the entire MMOG infrastructure.
To anyone who has worked on an MMOG, the key bottleneck is painfully obvious -- the link between the game server and the clients. You can safely assume that the CPU, memory, and disk are orders of magnitudes faster than the network. When bottlenecks are known, they are sized to that bottleneck. In other words, once you identify the bottleneck, you can then determine the performance metrics that are key to sizing the infrastructure -- the "how fast" and "how many."
The "how fast" factor involves the bit rate per second required for each client. Unfortunately, due to many complex factors, you will often find yourself in a situation where you don't know the bandwidth required between the client and server until it can be measured. That means you can't determine bandwidth until you actually need a complete client and a server.
The "how many" factor for an MMOG is even more complex. The question here relates to how many concurrent users the game is going to have once launched. The answer can vary anywhere from unknown to in the millions. This criterion is determined either by the game design or by the business model. Either way, someone has to make up a number, and that number has to be a reasonably accurate estimate.
Here are two ways you can go wrong:
- If you overestimate the number of players per shard, you run the very real risk of wasting money on unnecessary equipment.
- If you underestimate this number, you will not have enough equipment for game launch, meaning the game will likely tank and you actually made mistake #1.
There is no exact science for knowing how many players the game will have. You just need to get close enough to not waste money. Experience has shown that it's better to overestimate a little than to underestimate.
After you've decided the number of concurrent players to support, you can shift your attention to calculating the critical factor for the MMOG. This is a simple matter of multiplying the number of concurrent players by the bandwidth required per player. Doing so gives a total required bytes per second that the front end of the infrastructure must push. Here, networking experience is crucial in determining the number of concurrent connections, as well as the number of sustained bytes per second a front-line server can handle.
Sizing the next layers down is compounded, because it depends largely on how the game engine is implemented. A good assumption for the game engine layer is that the bottleneck is actually tied to memory/CPU bandwidth, not communications. If this is true, then the approach would be to calculate how many concurrent players a single two-way server with CPU generation X and memory configuration Y can support. If you're looking for a rule of thumb, here's one that seems to work well: For most games, each single front-end server can keep at least four game-engine servers busy. Using this rule of thumb can be quite a handy placeholder in the early phases of game development.
In contrast, sizing the database layer is relatively easy. The answer is two, and the reason is that people have been designing and improving relational database technology for decades. Modern relational databases have incredible amounts of capacity and perform incredibly well on multiple CPU systems. After you've estimated the number of concurrent players, you can estimate the number of transactions per second. Once performed, you can simply go to a relational database performance benchmark site and find systems in the ballpark range. When you find a system with enough CPU and memory to suit transaction needs, it's as easy as purchasing two of them and running them in an active-active clustering configuration. Ideally, each is sized so that it can handle the entire load of the game shard, but it is reasonable to balance economics with risk. Databases and database servers do not fail that often compared to everything else that can go wrong. The reason for choosing active-active clustering is that with modern database clustering technology and relatively inexpensive fibre-attached storage systems, there is really no reason not to go this route.
It might be said that every game developer would just prefer to have the entire game database in memory. In this scenario, performance would be superb, and transactions would complete in times approaching those of a function call. But that would also mean having a system with a couple terabytes of physical memory. Or would it? There is a type of database called "distributed shared nothing" that has the potential to actually offer the ability to pull an entire database into memory. As of this writing, it is fairly cost-effective to put 4GB of memory into a system. A shared nothing database system can spread the data and queries of a system across an array of systems. For instance, if you put twelve 4GB systems together, they would have enough RAM for an entire 40GB database, in addition to an operating system and other tasks.
Note: Game transactions are not like business transactions. Game designers know that millions of very small reads and updates will have to be done to the database during play. A game engine doesn't need huge joins on star schemas. Games are not like decision support system (DSS) or Online Transaction Processing (OLTP) systems at all. The game workload is much more like Lightweight Directory Access Protocol (LDAP) or telephony directory lookup: lots and lots of small transactions over simple tables.
Thus far, this article has dodged the most important issue that impacts playability for multiplayer online games and MMOGs: latency. The best way to describe what to do about latency and how to size for it is to use a transportation analogy. You can compare latency in online games to the round-trip time it takes parents to drive from home to the store and back. As you can imagine, the round-trip time is impacted by how fast the car moves and how efficiently groceries can be purchased and loaded and the car turned around. An underpowered car, unorganized store with poor checkout design, long lines, or traffic will all have dramatic impact on the turnaround time for the hapless parent.
If you want to reduce latency, you need to expand the capabilities of all elements. In the analogy, you could improve latency by dumping the minivan in favor of a pickup truck with a huge engine, equally huge hauling capacity, and performance suspension. You could also make the road wider and add as many lanes as possible to eliminate traffic jams. The parents could phone the grocery order into the store ahead of time. The store could then get the order packed up into triple-layer, shockproof cardboard and plastic shipping containers -- all before the flying family truck arrives. The family truck could pull into, not a parking lot, but a drive-thru without stopping through a highly efficient "shock and awe" grocery-loading system that ballistic-launches the package into the truck bed. The newly laden supercharged pickup doesn't even have to let up on the gas as it whips back onto the freeway into its own high-capacity vehicle lane.
This scenario may sound pretty silly, but it demonstrates a point. All of the elements in the scenario represent some component of networking technology and how you can modify it to improve latency -- from specialized packet design (such as taking advantage of Internet Protocol version 6 extensions such as jumbo packets) to Quality of Service protocols (QoS options in IP, where available). If the design of the data traveling back and forth between the client and servers is designed like a slow and cumbersome vehicle and has to stop, and the game server is designed like some old tiny mom-and-pop grocery store, the round-trip time of that packet will be non-optimal. On the other hand, if you can use hints from the client and server, so the server can prepare for the incoming late-model, high-performance sports car, then round-trip time can be reduced.
The point of all this is that latency is impacted by design decisions that lay at the heart of the game engine and the client communication system. Well-understood techniques can help you soup up these packets, reduce the number of them, and optimize their turnaround time. Caching, perfecting data, queue optimization, out-of-order transmission and receipt, connection pooling, hints, and parallel connections are all fairly well-understood techniques that you can employ in any multiplayer online game to reduce the elements of latency that are under your control.
Of course, the central issue to latency in MMOGs has been dodged, and that is the speed of the Internet. Believe it or not, there are things that you can do about it. Primarily, it's important to select multiple hosting facilities throughout the market and ensure that those hosting facilities have low-latency connections with the broadband providers that serve the particular markets. The best way to reduce the latency of the Internet is to host within a broadband service provider's infrastructure. This is becoming more and more viable as providers look to add value to their networks through the hosting of multiplayer online games. This is more a viable option for online first-person shooters, racing, sports, and casual games, where their persistent world data is not central to the game play and players tend to be grouped geographically.
Sizing back-office infrastructure
Sizing the game engine infrastructure is only half the battle of sizing an entire MMOG. Billing, accounting, and account management are equally as complex and important to a successful MMOG, especially because these segments are utilized during player logon. As for sizing a billing system, it's all about the number of users and payment methods.
Payment methodologies vary widely between geographies. Surprisingly enough, MMOGs are some of the first truly global online services, where a single service is used by people in all geographies. This has created some unique challenges for the industry. For example, in North America, the credit/debit card system is almost universally used for payment, with the minor exception of prepaid cards. In the European Union, prepaid cards live alongside the credit system familiar to most North Americans. In Asia Pacific, especially in China, the credit-card system is virtually non-existent, and the prepaid card systems are the norm. In all of these regions, no matter what the method, payment processing and billing are traditionally an outsourced function. Common to every geography is a group of companies that specialize in billing and payment collection appropriate for their respective geographies. InfoSpace in Bellevue, Washington, and YeePay in Beijing are examples of such companies.
Billing systems themselves are a well-understood back-office infrastructure component. Any business consulting firm worth its salt that has done consulting in the telecommunications or the services sector can size one with minimal effort. Any company considering building an MMOG is strongly encouraged to seriously consider hiring a consulting firm with experience in billing systems to do the billing. In the short and long run, it will be cost-effective as well as expedient. From a business perspective, an MMOG developer and publisher charge for subscriptions to an Internet-enabled service. As is the case, many companies with successful practices are building billing systems that are well suited to perform scaling and integrating into a game.
As you can now appreciate, sizing is no trivial task. Hopefully you're convinced at this point that it is more a science than an art and that with a small number of educated guesses, you can save yourself a lot of risk and money. The value that an experienced vendor can bring to this process should not be underestimated, and you should set your expectations high when making your vendor selection. You can expect a competent vendor to understand your environment and be able to work with you to size each infrastructure layer.
You've learned how to successfully solve one of the most risky and costly pieces of the MMOG puzzle. Before you move on to conquer your next quest, there is another important piece that deserves attention. You've invested good time and money in the latest and greatest systems. Now where are you going to host them? Game hosting is a non-trivial task that should be looked at more carefully. There is more than meets the eye when it comes to the economic implications of hosting. A bad hosting decision can lead to much misfortune for a game company. Part 2 of this series moves from sizing infrastructure into deeper discussions of the economic factors that you must consider when it comes time to actually host and operate an MMOG.
Learn
-
Check out the history of MUDs in this Wikipedia article.
-
Learn more about ACID in this Wikipedia article.
-
"OptimalGrid -- autonomic computing on the Grid" by James Kaufman, Tobin Lehman, Glenn Deen, and John Thomas discusses OptimalGrid, introduces a research prototype from grid researchers at the IBM Almaden Research Center (developerWorks, June 2003).
-
Memory management and performance are critical to the core engine components of both the client and server side of any game. Check out "Memory profiling for C/C++ with IBM Rational Test RealTime and IBM Rational PurifyPlus RealTime" by Jeff Campbell (developerWorks, April 2004).
-
Learn more about persistence of MMOG design in this 2004 Persistent Worlds Whitepaper (PDF format), presented by the International Game Developers Association (IGDA) Online Games SIG.
Get products and technologies
-
IBM
trial products for download: Build your next development project with
IBM trial software, available for download directly from developerWorks.
George Dolbier is the technical lead for IBM's Games team. George has 10 years of experience in the games industry, starting out implementing input systems, then voice and text chat for games, which in turn led to implementing and managing online operations not only for online games but also for service providers. George came to the games industry with a deep background in software engineering for companies such as Oracle, Informix, and Sequent. Today he uses his experience to help IBM and the games industry understand one another.
