An architectural approach to providing online game infrastructures

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. In the second of this four-part series, IBM senior IT architect Veronika Megler focuses a patterns-based perspective on the game itself, discusses scaling options, demonstrates how to integrate the runtime patterns selected for the infrastructure into a solution, and uses the runtime model to offer real-world suggestions that determine the better option for the in-housing or outsourcing of function building.

In the previous article, I explained the reasons that online games providers face an increasingly complex issue as they work to craft a successful environment:

• The growing expectation for more services
• An ever-advancing technology
• More stringent investment requirements
• An industry in flux

I made the assertion that the games industry is evolving towards an enterprise-business, e-commerce model. Given that perspective, I suggested the applicability of business patterns and explained their value when crafting and implementing an online games environment. I examined a plausible, real world-based scenario to use as a basis for developing a high-level business description. I demonstrated how you can 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 to identify the business, integration, composite, and application patterns necessary to developing an online games infrastructure.

In this 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 all the selected runtime patterns into a solution. With the runtime model to help, you'll determine your buy, build, and outsource decisions.

What about the game?

At this point, I've covered many of the functions that you need for your business. However, the main event -- the game itself -- requires a little more thought.

Although the game is the function you're least likely to buy off the shelf, you may still be able to shed some light on viable game architectures by looking at the problem from a patterns perspective. At least you have nothing to lose by looking and you can always discard what you find if it does not appear to be useful.

The problem: Determining the shape of the game

You've identified the game as a possible fit for the Self-Service business pattern. Do you want to provide access to the game from the portal? Probably. However, you also want to enable players to connect directly to the game without forcing them to connect through the portal.

You know that the game is likely to be a high-volume, highly dynamic part of the environment, so you'd like to provide some level of separation or protection between the game and the various services it uses and between the game and the remainder of the infrastructure. That way, you can provide a high level of availability and service for the game without complicating that environment by integrating it too tightly into the out-of-game community infrastructure. (I'll describe some chat and other game service integration options later.)

In support of this line of thinking, let's investigate the application patterns for self service.

The answer: Application patterns for self service

One appears to apply -- the Stand-Alone Single Channel application pattern (also known as User-to-Business topology).

Figure 1. Stand-Alone Single Channel (a.k.a. U2B Topology 1)

In this case, the gamer is the user and your game company is the business. The game is the industry-specific application in your business.

This application pattern directs you to the following runtime pattern.

Figure 2. Stand-Alone Single Channel Runtime pattern

Does this pattern meet your requirement? At this generic level, it does. You have an application that you will run in a server (in this case, the application is an online game). You require directory services to ensure that you can recognize and distinguish each user. And you need a database to store persistent game data.

The game may or may not be implemented as a standard Web application, though. Certainly some games are now being implemented in a Java environment, but many are still written as C++ applications, providing similar functions as an application server (threading, object retrieval, multi-user support, and so on) within the application itself. In addition, for many games, the game client on the PC is not coded to use HTTP protocols. Socket connections to the game servers are common, often using UDP. Even in these cases, the underlying protocol is usually IP-based.

If I expand the meaning of "Web application server" to include any IP-based application server, then the model does help relate what you are trying to build -- an environment familiar to most e-business architects. While not a perfect fit, it may at least create a level of common understanding.