 |
Level: Introductory
Veronika Megler (vmegler@us.ibm.com), Senior IT Architect, IBM Sales and Distribution
23 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. 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.
What about scale?
I mentioned earlier that the game is likely to be a high-volume, highly dynamic part of your environment. As such, you're unlikely to fit everything on the single server as indicated previously. The Stand-Alone Single Channel pattern description gives some help here in the form of Non-Functional Requirements custom pattern designs.
Non-Functional Requirements patterns focus on the specific design process considerations for high availability and high-performance solutions. Specifically, the focus is software and node configuration scenarios within the demilitarized zone (DMZ), or external network, and the implementation procedures for using these designs.
High performance is the non-functional requirement I'll address. A number of options are provided -- look at the Basic Runtime pattern in Figure 3.
Figure 3. Non-Functional Requirements, high performance: Basic Runtime pattern
Again, you need to replace the concept of a Web application server with the concept of a more general application server. Generically though, this is probably a reasonable approach to take.
Steps 7 and 8: Integrating runtime patterns into a solution
You're now at the last step of this stage of patterns-based solution modeling. You've identified a number of runtime patterns, each of which apply to part of your infrastructure. Now, overlay all of them into an overall runtime pattern for your scenario. At the same time, add placeholders for functions that you know you need but are not called out by the patterns you've reviewed.
Figure 4. Overlay of Runtime patterns (surrounded by green boxes)
Figure 4 places all these functions together on a single diagram. It adds a couple of additional functions (such as the Customer Relationship Management component) and firewalls to protect functionally separate parts of the architecture. You established the most common linkages or operational flows between each function. You also gave each part of the architecture a name for easier discussion of the overall architecture.
Zoning out: walking through the model
Take a moment to understand this model.
You have a group of gamers, represented on the left side of Figure 4 by the box titled "IP-based user." In this current scenario, you expect that your users are PC-based gamers. As noted previously, when they connect to your site they will probably connect to the game using a browser-based mechanism through HTTP, but also connect directly to the game using a sockets-based, game-specific connection.
The first time the gamer arrives at the site, you will ask him to register. If the gamer arrives as a result of having purchased a game hosted on this site, he may have a registration key, an automatic registration from inside the installed game, or some other mechanism that enables him to register. If he has not purchased and installed a game, you still might require them to register before you give access to premium content. As part of the registration process, you may also allow gamers to hang out in a lobby area -- similar to a crowd milling around outside a theater -- prior to entering the entertainment event. To encapsulate the infrastructure required to support registration and the lobby, I call this part of the infrastructure the lobby zone.
The core reason people come to the game infrastructure is to play the game. Given that sometimes the game population can grow into the thousands (potentially millions), a significant amount of infrastructure might be needed to support them -- server farms, scalability mechanisms that stop a single server from becoming overloaded, fail-over for 24/7 games, and so on. As a way of grouping and identifying this section of the infrastructure, I call this the game zone.
In addition to playing the game, other activities might cause gamers to hang out, spend more time (and more money) at the game site, and become more committed to the game. This propensity can be encouraged by providing appropriate functions and activities at the game site. In essence, these activities pay off for the gamers by making them feel part of a community of people who have the same hobby -- the game. Therefore, I call these the community functions and the part of the infrastructure that supports these activities, the community zone.
This simple categorization gives the first level of structure that you can use to understand and describe what you have. Still, some required functions are missing from this diagram:
- You will need a set of management functions. This includes those functions required to keep the whole infrastructure running, such as monitoring and maintenance. Often, these functions have agents that are distributed across all components, but a centralized point also provides oversight.
- If your applications require significant storage, it may make sense to use an emerging best practice -- consolidation of all storage in your infrastructure into a storage zone.
- You need a development environment that can support the development and testing of components before you bring them into the environment. Fence this set of hardware, software, and activities off from the production infrastructure in a development zone.
- To support your enterprise, you will have other systems, such as finance, payroll, and legal systems. Securely protect these from the remainder of your infrastructure in an enterprise zone.
This is a significant set of issues so I'll leave further elaboration of these zones to another time.
Build, buy, or borrow?
Now that you have an overall picture of the needed functions, you're ready to decide which functions within this infrastructure to purchase off the shelf, which ones to outsource, and which ones to build in-house.
Use the runtime diagram to model and capture the buy, build, and outsource decisions on a function-by-function basis. A model such as this allows you to decide whether custom development or leveraging existing functionality is the best option.
Clearly, the game is key. Without the game, customers have no reason to join the community you're trying to form. You might develop the game yourself, commission the game from another development shop, or purchase a completed game.
Other areas, such as registration or customer service, are places you might choose to support by purchasing off-the-shelf packages from a vendor or using an outsourcing service. After all, writing your own Web-accessible commerce system has limited competitive advantage and potential additional costs.
As an example, Table 1 lists a set of IBM? and IBM Business Partner products that can provide these functions.
Table 1. Existing products that can supply the functions required in Figure 4
| Function |
Products |
| Registration & Login |
- IBM WebSphere? Application Server; Registration on Demand Service
|
| Database Server |
|
| Directory and security services |
|
| Collaboration |
- Lotus? Domino?
- Lotus Sametime?
- Lotus Quickplace?
|
| Web Server Redirector |
- WebSphere Network Dispatcher
- IBM HTTP Server
- WebSphere Application Server Plug-in
- WebSphere Application Server
|
| Content Management |
- WebSphere Application Server
- DB2 Content Manager
- DB2 Universal Database (UDB)
|
| Application Server, including Commerce App |
- WebSphere Application Server
- WebSphere Portal
- DB2 UDB
- WebSphere Personalization
- WPS Search & Indexing Portlets
|
| Billing, Subscription |
- WebSphere Digital Media Enabler
- WebSphere Commerce
- WebSphere Commerce Payments
- WC Recommendation Engine
- WebSphere Application Server
- DB2 UDB
|
Despite the number of products that apply, more work is necessary. At this level, each of these products appears to be a fit, but you still need detailed research to ensure that the products provide an implementation of these functions that sufficiently meets your needs. For example, WebSphere Commerce provides the ability to handle various kinds of subscriptions, such as a particular dollar amount, or time-based or package-based. If you want to send an e-mail to the user to remind him that his time-based subscription is about to end, this requires customization or additional development, depending on how elaborate a renewal solution you wish to provide.
In doing this detailed research, you find that while the marketing materials for some of these products do not focus on capturing the attention of the game developer, the functions provided by many of the products do; in fact, many of them turn out to be a surprisingly good fit.
And, although purchasing the products off the shelf may come with a significant monetary cost, a surprising number of utility-based or application service provider offerings are available for purchase at a per-transaction or periodic cost. This helps in two ways:
- It eliminates the up-front cost of either purchasing- or coding-needed functionality.
- It makes the functionality available much more quickly and with lower risk than most development projects.
Reducing capital outlay and reducing risk -- these are traditional corporate goals!
What's next?
In this article, you identified the game as the most important component of your infrastructure -- without it, customers have no reason to come to your enterprise. You applied a patterns-based perspective to help determine the shape of the game (which attributes the game demands; which patterns best answer those demands).
I outlined the reasons for applying Self-Service patterns to the game, taking you on a hunt to establish an application and a runtime pattern that meets the game's requirements. I discussed the scale of the game and detailed why the high availability/high performance Non-Functional Requirements custom patterns are a good match.
I talked about integrating the runtime patterns into a workable solution. By matching available, real-world products with runtime functions, I demonstrated that reuse can be as viable an option as building from scratch.
I also listed some required functions that are missing from this first level of structure you've built -- food for further thought.
In the next article, I'll offer a scenario that can possibly require a whole new set of functional requirements and you'll see how the first level of structure meets those requirements. You'll identify new e-commerce needs and outline how to provide an infrastructure to meet them. I'll also discuss the requirements needed to efficiently access and connect to the various devices your gamers will use to play the game.
On with the game!
Resources
- Read the author's other articles in this series:
- For more about developing a high-level business description and identifying patterns, review "Online game infrastructures, Part 1: Develop a high-level business description and identify patterns" (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).
- 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.
- 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).
- Discover how to take Tetris game elements, wrap them as Java objects, and create reusable game components in "Tetris meets the Java bean" (developerWorks, April 2002).
- 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.
|
|
