Online game infrastructures, Part 1: Develop a high-level business description and identify patterns

An architectural approach to providing online game infrastructures

Print this page

E-mail this page

Follow us

Help us improve this content

Level: Introductory

Veronika Megler (vmegler@us.ibm.com), Senior IT Architect, IBM Sales and Distribution

07 Jun 2004

The business of the online games industry is a complex one, requiring the input and integration of many variables -- people, business conditions, product goals, and more -- to create, implement, and distribute a successful online game. Senior IT architect Veronika Megler ignites the first of a five-part series that focuses on infrastructure providers for online games. The series illustrates the state of the industry today and demonstrates how to develop a high-level business description and how to identify the all-important business patterns. The author offers eight steps towards this goal.

Twenty years ago, when I wrote computer games for a living, the industry was pretty straightforward. I wrote games, the company packaged them (well before the advent of CD-ROMs and CD-ROM drives for PCs, games were distributed on cassettes -- can you believe it?) and sold them. My employer made good money, I made more money than a college student could make most other legal ways, and I got to play all the computer and arcade games I wanted. Life in the game industry was good!

But I got bored, joined Real Business, and started working with Enterprise Applications. The years flew by and here I am again, working with the game industry. My how it's changed!

The major change in the industry is that every game (well, almost every game) can now be called an online game. Coupled with the phenomena that online access has increased astronomically, that attribute alone has added a tremendous complexity to development and deployment of games and game infrastructures.

Inside the online game industry

Describing the online game industry in any level of detail would take quite a long time and I want to focus on the development issues rather than the history. To create a context for this discussion, I want to spend a moment talking about the industry.

The industry that creates, distributes, and runs games is complex. Increasingly, game art is developed by artist studios rather than by the code developers who performed every task back when I was writing games. Game developers can vary from small startups with a great idea, to major entertainment studios who wish to capitalize on existing media assets by developing a game with movie, character, or brand tie-in.

Games may be distributed by the company that developed the game, by the game publishers, or by game consolidators. The game-development industry is starting to look more and more like movie production with its major studios and small independents -- who sometimes partner and sometimes compete.

Computer games come in many varieties. Game content or game style is substantially different: from role-playing games (RPG) to extreme sports; from strategy to first-person shooters, the ultimate high-twitch games. (High-twitch games are games that require fast reflexes in order to score well -- or even to play for more than a few minutes without losing.)

A common way of segmenting the games is by the number of players:

• Single-player games often take a fairly short time to play, and appeal to the casual gamer. Games such as Patience or Tetris (the freeware version for Windows is called Tetrus), or casino-based games, often fall into this category. They may also be called turn-based games -- the interaction in multi-player versions of these games is often limited to competing for high scores.
• In multi-player games groups of 2 to 64 players are hosted by a single server. These games are generally of a specific length and often possess the high-twitch factor. One example is Battlefield 1942.
• Massive multi-player online games, or MMOGs, have thousands of people playing in a hosted-server game environment; the games generally run continuously, 24/7. Examples are Everquest (sometimes flippantly called Evercrack since it can be so addictive) and the Korean blockbuster, Lineage.

The ways in which these types of games are played differs, and the user interface and detailed technical infrastructure to support them varies as well.

This series will take you on a tour of what I'll call, for simplicity, game infrastructure providers -- a subsection of the overall games industry that includes the following:

• Companies that have developed their own games and now wish to make them available to the game-playing public by hosting their own infrastructures.
• Game consolidators, such as game portals, who provide those who want to play with access to a wide variety of games from a single source.
• Publishers who, similar to game portals, may provide access to one or more games.

Later in the series, I'll focus on the infrastructure that game providers must build to fulfill the goals of these services.

While you'll find differences between single-player, multi-player, and massive multi-player game providers, most of the infrastructure needed by each of these types of game providers is similar enough that the same architecture can support all of them.

Before I move to the steps needed to get started in planning such an infrastructure, look at the environment that envelopes a game infrastructure provider.

Life as a game infrastructure provider

For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why?

Services

A major reason is that subscription-based customers must be kept happy. They expect a set of services and, if those services are successfully provided, they'll enhance the overall income of the game provider. As time goes on, the game players (or gamers in industry jargon) expect an increasing number and complexity of services.

Technology advances

Another reason profiting from games has become more complicated is due to advances in technology, which creates further change. Game devices are becoming more varied and the games themselves are becoming more complex, requiring higher quality graphic abilities and more creative and intricate game play. Distribution, once primarily handled by CD-ROM, can be (and often is) provided electronically.

Investment requirements

Lots of money is also involved. Developing a massively multi-player game can take upwards of $12 million. Given the size of investment in developing a major game, the risks associated with that investment, as well as the opportunities to make significant, recurring profit, meant that it was just a matter of time before the "suits" showed up. And once they did arrive, it was only a matter of time before you start hearing the mantra:

Do more with less -- let's not re-invent the wheel -- reusable components....

Now, online game infrastructure development looks a lot more like other e-business enterprises. All joy and creativity is not lost, though. It's possible to take the overall list of enterprise needs and divide it into smaller chunks, some of which are unique to the game industry and some of which are well-understood enterprise problems that may be amenable to industry standard solutions.

It's really a transitional issue

This is an industry that is struggling with exploding complexity. And constant rapid change means transition. So that's what I discuss in this article: The infrastructure issues involved in the transition of game infrastructure providers from the free-spirited arena to the e-business enterprise.

I explore this view in this series by taking a few scenarios, demonstrating the functions they imply, and postulating a possible architecture that can support the scenario. I'll start with a simple view, then add further functions and scenarios as the series continues.

In this first article, you start to create your architecture using a business pattern approach, as described in the book Patterns for e-business: A Strategy for Reuse (see Resources). This template will also act as a mechanism to determine which additional functions you can add easily and which ones take a significant rethinking of the architecture.

The patterns approach

Patterns are groups of reusable assets that can help speed the process of developing e-business applications. IBM, for example, classifies these reusable assets into the following elements:

• Business patterns identify the interaction between users, businesses, and data, and are used to build simple, end-to-end e-business applications.
• Integration patterns bind other business patterns together to create applications with advanced functionality.
• Composite patterns are combinations of business and integration patterns that have themselves become commonly used types of e-business applications.
• Custom designs are similar to composite patterns (as they combine business and integration patterns to form an advanced, end-to-end solution), but they have not been implemented to the extent of composite patterns; they are instead developed to solve the e-business problems of one specific company.
• Application patterns and Runtime patterns: Driven by customer requirements, these patterns describe the shape of applications and the supporting runtime needed to build the e-business application.

With architectural patterns, developers create solutions more quickly, regardless of the scale of the business.

Borrowing from the book Patterns for e-business: A Strategy for Reuse, I'll describe the steps involved in identifying and selecting the appropriate architectural pattern that best represents the functions required to solve a business problem:

• Step 1: Develop a high-level business description that illustrates the major business functions of the proposed solution.
• Step 2: Develop a solution overview diagram to translate the textual description into a pictorial representation.
• Step 3: Identify business patterns that apply to the solution from a catalog of existing patterns.
• Step 4: Identify integration patterns from the catalog. Integration patterns are commonly found, like recurring combinations of business patterns.
• Step 5: Identify composite patterns to use in identifying major collections of the business functions.
• Step 6: Identify application patterns from the catalog.
• Step 7: Summarize all the application patterns required.
• Step 8: Integrate the patterns and any packages selected into the solution.

I'll lay the groundwork next by offering a simple scenario and discussing issues involving the first six steps. (In the next article, I refocus on the game itself, talk about scale as an infrastructure issue, cover the final two steps, and discuss whether or not to build or buy, using off-the-shelf components.)

Step 1: Developing a high-level business description

Let's describe a potential interaction between a member of the target audience and the system you plan to build. Use this initial interaction for a guide as you design the architecture for the functions that the system needs to provide. Call this interaction Scenario 1: Purchase, then Play.

A potential gamer, Ken, saw an advertisement listing the Web address for your newest PC-based MMOG, HAL 2010: Universe On Demand, in the latest issue of The Hip Gamer's Magazine. He surfs to your public Web site. A banner advertises the game and offers the chance to purchase it.

Ken selects the "buy now!" button. He is asked to provide registration information: A unique user ID and password. He is then redirected to a shopping cart containing the game. Your Web site asks if he would like to add a poster of the game, a T-shirt, cap with a logo, or coffee mug to his purchase -- for an additional fee, of course. He chooses the poster. The site offers him a choice of delivery mechanisms for the game and the poster. He can choose to download them or he can have them snail-mailed (the game on CD-ROM, the poster as, well, a poster). Items with no digital option (coffee mug) and items for which he selects physical delivery are physically shipped after giving him a choice of delivery times and associated costs.

Then the Web site offers the option to browse your catalog, look through new player recommendations, or join a hosted chat session.

As part of the purchase, Ken is afforded a certain amount of free usage. Since he purchased the game from you, you have updated the directory record entry created when he registered with an indicator of the free usage he's entitled to. You can also add to his entry either the registration number of the downloaded game instance you're delivering or the registration code of the CD-ROM that you ship him.

Once Ken begins playing, you can grab information about his game play. Some information is captured in the database that maintains game persistence; other data is added into the directory that contains his profile or the game statistics database.

Your site also offers the option to open a chat session to customer service, if Ken is unable to answer his questions using the FAQ or tutorial information provided.

Once Ken has used up his initial free time, the site automatically generates an e-mail to his designated address with a link to allow him to update his subscription. With this link, he can choose between a number of supported subscription packages (such as unlimited usage per month at one price or a specific number of usage hours at a lower one-time charge). When he selects a particular package, your site presents the credit card information that he used previously, gains his approval, and immediately processes the charge.

Wow! This potential interaction seems straightforward from a user's perspective, but you can already sense that it will be non-trivial to build.

Step 2: Developing an overview of a solution

In developing an outline or overview of a potential solution, what functions are mentioned or implied from the scenario? Here's my list:

The game

It goes without saying, that the game itself is the main content -- the reason the gamer comes to your site. It is likely that you will need to integrate the game with other components; for example, to keep each person's game state intact between game sessions.

Registration

During registration, you ask the gamer to provide a unique user ID and associated password. You also ask him to provide an e-mail address to receive subscription renewals, newsletters, relevant advertising, and other information.

Directory

You need to store basic information identifying the user. This is also a convenient mechanism to store other person-specific information such as game-playing preferences or billing information.

Account administration

For any game that is not free, the gamer should be able to see how much time or money remains in his account and be able to update his account information.

Search and select

While finding access to the game is likely to be easy (in this case through a banner on the site listed in the ad), you also offer the chance to select game-related paraphernalia and to search your catalog of other products. You also mention that a player can search player recommendations; no doubt you will offer other information.

The catalog

This will contain the purchasable game, mugs, posters, T-shirts, books, maybe even telephone ring-tone versions of game sounds.

Order management

Thanks to FedEx and UPS, customers want to track their orders. Many people who purchase over the Internet expect functions such as a link to a shipping site with a delivery number.

Fulfillment

You might deliver some digital items (posters, screen savers, code) electronically. Non-digital items (T-shirts, printed posters, mugs, and CD-ROMs) require physical shipping.

Customer service

Customer service must be able to interface with almost all the functions mentioned in order to help gamers with specific problems. If the problem is with the game, the representative may need to reset the gamer's profile, adjust his account, check his order -- any number of functions. Make customer service convenient for the gamer to keep him from leaving the game in frustration -- provide a variety of access methods, including chat, e-mail, and telephone.

Chat

I mentioned chat twice in the scenario -- among members waiting to play the game and for contacting customer service. Also, you probably want to offer e-mail, although it wasn't called out in the scenario. Group these functions together under the heading "Collaboration."

Billing

This is how you make money -- no kidding. You wish to bill for the initial game purchase, for the other game-related paraphernalia, for game subscription or time played, for game subscription renewal, and for anything else you think you can!

A database of game-related information

This may include information of general interest to all players of the game: tutorials, frequently asked questions, tips from other players, and so on. Besides the catalog, this is the other target for search-and-select capabilities. You may also provide information customized for specific classes of players, such as novices or experts. Ideally, the user can specify a specific interest or a group membership and automatically see new information customized for that class of user. This implies personalization, integrated with the directory.

Oddly enough, when you look at this list, notice that the game developer is really only interested in the first item. The rest of the items are, well, boring -- non-creative heavy lifting that most game developers would rather let someone else do.

Diagramming the solution overview

You can create a solution overview diagram (as shown in Figure 1) to provide a concise representation of the key functions required for the proposed solution. All functional requirements for the base version are included here.

At this point, a few major themes are already obvious.

Clearly, an online game playing infrastructure has some requirements specific to the online games marketplace, driven by the kinds of devices in use and the business models common in this industry.

Many of the other functions, however, look familiar because of their similarities to e-business infrastructures from the dot-com era. Many companies implemented these components in the last few years (Internet-based commerce, customer self-service, community-based tools). The years since the dot-com era have also given a plethora of off-the-shelf solutions time to mature into fully-tested, stable products.

In this world-view, you might regard the game as the online game industry's industry-specific business application.

From this solution overview, move to the next step in this pattern-based approach.

Step 3: Identifying business patterns

Looking closely at the solution overview diagram (Figure 1), you can observe the following business patterns in the solution:

• Gamers interact with the game themselves. Out of the available options, this is best represented as a Self-Service pattern. (Also known as User-to-Business, this pattern addresses the general case of internal and external users interacting with enterprise transactions and data.)
• Buyers may search and select items from the catalog and may place orders for selected items. These functions involve direct interaction between users, back-end systems, and databases (the catalog). This is indicative of a Self-Service business pattern.
• The users may use chat and e-mail to communicate with each other and with customer service representatives. This is a Collaboration business pattern. (Also known as User-to-User, this pattern addresses the interactions and collaborations between users.)
• The company accepts credit cards online from both account administration (for renewal of access to the game and from order management to pay for purchases). This could be counted as an Extended Enterprise business pattern. The usage of online credit cards is well-understood and the function is integrated into many products, but include this pattern for now and see what changes or additions it leads to. (Also known as Business-to-Business, this pattern addresses the interactions and collaborations between business processes in separate enterprises.)
• The fulfillment function is at a boundary between the organization and other organizations; in this case, most likely a shipment house such as FedEx. In some cases, the entire fulfillment function may be outsourced, perhaps using an alliance with a company such as Amazon.

Step 4: Identifying integration patterns

How will you integrate between these functions? In general, use the Access Integration pattern; in fact, this seems to be a good fit here also. This integration pattern describes those recurring designs that enable access to one or more business patterns. In particular, this pattern enables access from multiple channels (or devices) and integrates the common services required to support a consistent user interface.

Access Integration is also a good fit for the customer service personnel too, since they need to access a number of different applications in support of resolving customer issues.

Figure 2 shows the revised solution architecture diagram, including the integration patterns.

Step 5: Identifying composite patterns

Now that you have identified the integration patterns, look for composite patterns. These are common, recurring combinations of integration and business patterns.

Look at the list of patterns included in the solution overview and then check them against the patterns covered by the composite patterns. Note that several of the composite patterns seem to apply: the Electronic Commerce, the Portal, and the Account Access composite patterns all cover part of what you need.

However, the Portal pattern -- which typically aggregates multiple information sources and applications to provide single, seamless, and personalized access to users -- seems to offer the most coverage. It lists the following mandatory building blocks, all of which are in your solution overview:

• Access Integration pattern
• Self-Service pattern
• Collaboration pattern
• Information Aggregation business pattern (also known as User-to-Data, allows users to access and manipulate data that is aggregated from multiple sources)

The pattern description further underscores this belief. To quote Adams from Patterns for e-business: A Strategy for Reuse:

A portal is typically designed to aggregate multiple information sources and applications to provide uniform, seamless, and personalized access for its users. . . . The Composite pattern for portal applications is made up of an Access Integration pattern that facilitates functions such as single sign-on, multiple device support, and personalization, plus at least one other Business pattern.

This exactly describes your situation.

Figure 3 is a pictorial representation of the Portal composite pattern, taken directly from the book.

By comparison, the Electronic Commerce composite pattern notes Information Aggregation, Application Integration (which brings together multiple applications and information sources without the user directly invoking them), and Self-Service as the mandatory patterns, with the others as optional pattern variations. You already understand that Collaboration is a requirement.

Extended Enterprise is listed as an optional pattern variation for both composite patterns. You clearly need Extended Enterprise-like functions for billing, order management, and fulfillment.

The application pattern choices for the Electronic Commerce composite business pattern are either web-up (used to quickly enable a Web-based buying site without any close integration with back-end systems) or enterprise-out (extends an existing order processing system to a new Web-based buying channel and includes close integration with and reuse of existing back-end systems), depending on the existence of legacy applications. Since you are building this infrastructure from scratch, the web-up pattern is the better fit.

Keep an eye on the Electronic Commerce pattern and take a look at the Runtime pattern as you move forward, to see if you can use any implementation suggestions.

Step 6: Identifying application patterns

Once you've selected the business patterns, start to explore the application patterns to implement this business pattern.

As you start to drill down into the Portal application patterns, you find the following diagram which summarizes the various types of functionality found in each business and integration pattern. Again, these are categorized into the mandatory (functions that are always present in this business pattern) and the optional (functions that may or may not be present).

In comparing the mandatory and optional pattern variations for the Portal application pattern against the functions necessary for your solution, note the following requirements:

• Access integration: To be usable by the gamers, single sign-on is absolutely a requirement across these different functions. You also wish to provide personalized delivery of guild- and team-oriented information. For this scenario, you do not (yet) require Pervasive device access.
• Self-service: To reduce the overall service costs of your infrastructure, the Directly integrated single channel pattern is mandatory.
• Chat and e-mail capabilities: Both Store and Retrieve collaboration (e-mail), and Directed Collaboration (chat) help reduce customer service costs. They also allow you to provide additional functions that increase portal "stickiness" by providing team-oriented or interactive events.
• Information aggregation: You need searchable access to a variety of information sources. At the level of sophistication you want, you probably do not need Population Crawl and Discovery, although portal aggregator sites with a large number of information sources may find this functionality useful. At this stag, you are unlikely to need multi-step information aggregation, so you will use single-step aggregation, the simplest practical starting point. You will add data to the information database over time from internal sources such as interviews, articles, and news flashes, and in response to commonly asked questions or problems. In most cases, you initially envision that you'll take overt action to add these items to the information base rather than having an automated process that manages this.
• Extended enterprise: Credit card approvals and charges, as well as any outsourced components such as shipping use these very common e-commerce functions. Make a note to also check the e-commerce pattern as you move forward.

If you review the Runtime pattern choices available for the Portal application pattern, note that the same Runtime pattern is used for each of the mandatory patterns that you require. Therefore, go ahead and use this one Portal composite Runtime pattern. No need to choose between multiple conflicting choices. It includes all the components for access integration and for the other needed functions.

The Portal composite pattern also includes the Runtime components from the Self-Service pattern, so for these two pieces, the infrastructure components are provided by the Portal composite pattern. Single sign-on is provided through the application server's use of the directory.

Figure 5 shows the Portal Runtime pattern.

For comparison, Figure 6 shows the Runtime pattern for the Electronic Commerce pattern.

Looking at the components of the Electronic Commerce Runtime pattern, you see some overlap with the Portal Runtime pattern in the basic structure and common components such as the Web server and firewalls. You also see components not duplicated in the Portal, such as the Commerce Application. To build up the complete Runtime architecture, overlay these two Runtime patterns.

What's next?

In this first of five articles, I've cited reasons that underscore the increasing complexity in the online games industry, especially for game providers (the focus of this series). This industry is in transition, straddling the chasm between enterprise business and the art of games.

I introduced patterns and explained their value when crafting and implementing an online games environment. I examined a typical real-world interaction to to aid you in developing a high-level business description of the development direction you intend to follow. I demonstrated how to take that description, pull out the pertinent elements, and use those elements to build a solution overview of the project.

Then using the solution overview as a base, you learned how to identify the business, integration, composite, and application patterns necessary to developing an online game infrastructure.

In the next article, I refocus on the game itself, applying a patterns-based perspective to it. I'll discuss scalability options and finish up the last two steps of the patterns-based solutions modeling by determining how to integrate the runtime patterns into a solution. You'll use the runtime model to help determine your buy, build, and outsource decisions.

Resources

• Try Patterns for e-business Development Kit Lite (PDK Lite), a self-configuring, end-to-end skeleton Web application in one self-extracting package for implementing various Self-Service solution designs.
  
  
• Visit the IBM e-business Patterns site, a repository of pattern resources, including a walkthrough exercise that can make it easier to choose the correct patterns for your design.
  
  
• Read the author's other articles in this series:
  • In "Online game infrastructures, Part 2: Concentrate on the game," focus on scalability options and complete the last two steps of the patterns-based solutions modeling as you integrate the runtime patterns of the online games infrastructure into a first-level solution and outline whether outsourcing is the best path (developerWorks, June 2004).
  • In "Online game infrastructures, Part 3: Integrate additional device-support functions," focus on integrating new device-support functions into the existing online games infrastructure and meet e-commerce and device-connectivity requirements (developerWorks, July 2004).
  • In "Online game infrastructures, Part 4: Integrate additional device-support functions," focus on learning patterns-based solutions to handle community interaction needs, address adding new content for users of the game environment, and provide assistance when users want it (developerWorks, July 2004).
  • Recap the game infrastructure design process, look at a final revised build-buy-borrow template, and note a few additional potential functions in Online game infrastructures, Part 5: Make the game work (developerWorks, August 2004).
  
  
• Check out the International Game Developers Association, a non-profit membership organization that advocates globally on issues related to digital game creation.
  
  
• Get a quick overview of pattern usage in "Patterns for e-business" (developerWorks, June 2000).
  
  
• Take a detailed peek into the workings of this architecture in "A custom design based on the Portal Composite Pattern architecture" (developerWorks, February 2004) .
  
  
• Read "Business Integration for games: An introduction to online games and e-business infrastructure" for more on the technology solutions behind the business and revenue models of online game systems (developerWorks, October 2003).
  
  
• Browse for books on these and other technical topics.
  
  
• Check out Developing Online Games: An Insider's Guide (O'Reilly & Associates; 1996), by Mulligan and Patrovsky, an excellent book describing the business requirements for running an online games infrastructure.
  
  
• Visit developerWorks Web Architecture zone for articles covering various Web-based solutions.
  
  
• Browse for books on these and other technical topics.
  
  
• Develop and test your Web applications using the latest IBM® tools and middleware with a developerWorks Subscription: You get IBM software from WebSphere®, DB2®, Lotus®, Rational®, and Tivoli®, and a license to use the software for 12 months, all for less money than you might think.
  

About the author

In the early 1980s, Veronika Megler was part of the birth of the computer games industry in Australia as the first employee of the heralded Melbourne House Publisher. While there, she wrote best-selling computer games, including a legendary cult game, the best selling game ever on the Spectrum 64 home computer, The Hobbit. Twenty years has taken her career full circle -- after working in operations, application development, systems programming, systems management disciplines, project management, and IT management consulting, she spent a large part of 2003 working to match IBM's products with the nascent online games industry. Now a Senior IT Architect for IBM Sales & Distribution working on Offerings for Emerging & Competitive Accounts, she is passionate about making IBM solutions and technology usable by customers and consumers. She enjoys building architectural solutions for real business problems, then proving they work in practice.