Online game infrastructures, Part 3: Integrate additional device-support functions

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 & Distribution

13 Jul 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 third of four articles, Senior IT Architect Veronika Megler offers a scenario that demands a new set of functional requirements, identifies e-commerce needs and methods to solve them, and discusses how adapting the existing infrastructure can help providers handle device-connectivity issues.

By now, you have a basic online game infrastructure in place. Should you be satisfied with the outcome?

The answer is "yes." And "no."

On the "yes" side, be proud of what you've accomplished already. In Part 1 of this series, you learned to:

• Migrate from a game focus to a business focus, using an e-commerce model to ensure success
• Apply business patterns to the development of a game environment
• Craft a business description of the environment you want
• Take that description and pull out pertinent elements, and build a solution overview of the project
• Use the overview to identify the needed patterns to develop the infrastructure

In Part 2, you learned to:

• Refocus on the game, applying a patterns-based perspective to illuminate its design
• Outline and understand why to chose certain patterns, based on your determinations
• Walk through the application, applying patterns as you go
• Examine scale requirements and determine which patterns fit those best
• Integrate runtime patterns into workable solutions
• Match real-world products with the runtime functions
• Determine when and where reuse (buying or borrowing) was appropriate

The reason to not be satisfied yet? Consider that the scenario you based your initial overview on is not the only scenario; in fact, it is a scenario that can evolve. So you have to dig deeper into the bag of functions and produce some additional ones.

In this article, I look at two important, potentially profitable topics -- producing and selling ancillary products, and establishing a communication connection with the gamer.

It's an ever-changing world

Now look at a scenario that describes game-playing as a lifestyle, which might prompt you to think about maximizing your profit potential. Later in the article, you'll look at device-connectivity issues -- you make no profit if your gamers can't reach the game!

The new scenario: Playing as a lifestyle

Add a new dimension to your game players, Ken and Barbie.

The potential game player, Ken, has seen an advertisement for your newest PC-based MMOG, HAL 2010 - Universe On Demand, in the latest online issue of The Hip Gamer's Magazine.

Ken's favorite game environment is his game console, which he has plugged into his state-of-the-art big-screen TV with surround sound. This lets him feel like he's totally immersed in the game he's playing -- a complete escape from reality. He's a hardcore player and he expects your game to live up to his hardcore expectations.

Of course, keeping up with his technology habit is expensive. Ken has found a way to supplement his income in a uniquely pleasurable way -- he scouts the game, collecting weapons and building up characters, then sells them to other players. This way, he supplements his income while maintaining his habit.

His girlfriend Barbie is a much more casual gamer. She is a technology fashion maven -- she always has the latest cell phone with covers that match her wardrobe and mood. She maintains her fashionista reputation by wearing T-shirts sporting the avatar from her favorite game and by carrying her personalized avatar coffee mug. Her favorite gaming environment is her phone. This lets her play in snatched moments, on the go while waiting for the bus or waiting for her best friend to arrive at Starbucks.

Because her best friend is always late, Barbie has recently upgraded to an N-Gage (a hybrid mobile game device by Nokia) which makes her game-playing a more pleasurable experience. Although she sometimes plays simple games when she's tired (Tetrus, Patience), she often enjoys the same games that Ken plays. However, her character is generally far less powerful since she does not invest the same amount of playing time as he does.

With this scenario as a guide, you've now identified a whole new set of functional requirements. How does your infrastructure so far stack up against these requirements? What holes do you need to plug?

The new requirements

First ,make a quick list of the additional requirements:

• In-game commerce, to allow Ken to sell his in-game characters, weaponry, and possessions.
• Out-of-game commerce, to sell T-shirts and mugs with game characters to Barbie. If you allow gamers to create or customize their avatar graphics, you could potentially create customized T-shirts, with their selected avatar and game nickname. This would give your gamers a way to find each other outside the game -- and create another aspect of community.
• Access from other devices -- consoles, cell phones, and N-Gage. Given the fast-converging and simultaneously diverging cell phone, PDA, and handheld market, you probably don't want to limit your device access too narrowly.

So, how do you go about supporting these added requirements? Start with commerce.

Selling more stuff

You've added some interesting commerce-related requirements in this scenario. Now explore them in detail, beginning with Barbie's T-shirts.

Conceptually, selling T-shirts is a simple use of commerce.You've already identified commerce as a required function and you have a commerce engine that allows a gamer to choose and buy a selection of T-shirts in different sizes and colors.

The graphics technology angle

Printing an individual gamer's avatar on the T-shirt is a little more complex. Because digital T-shirt printing is unlikely to be a competency that you wish to develop, the solution is to build a relationship with an external digital T-shirt printing house. You send them an order with an appropriate image attached as a graphics file and they print it for you. To do this, you need to be able to extract the image of the gamer's avatar, complete with accessories, from the game graphics database. You then can scale it up and ship the image to a digital T-shirt printing facility along with this gamer's nickname and order.

You're making the gross assumption that the individual icons from which the individual avatars are constructed and with which they're accessorized can be scaled up in an appropriate fashion -- this requirement may cause your graphic artists some pain. You can solve this problem by forcing avatars to be created from pre-defined graphic building blocks, then save the high-resolution versions of these blocks in a digital-asset management system. Technology for automatically creating thumbnails from higher resolution graphics is readily available -- some solutions provide more elegant results than others.

When you get a request for a T-shirt, construct the required avatar from higher-resolution versions of the same building blocks from which the avatars are created; then add the nickname to create the proposed T-shirt image.

By the time you've implemented the T-shirt printing, expanding sales to include personalized mugs, posters, screensavers, toys, and other paraphernalia is a small step that might supply substantial financial rewards!

Besides addressing the graphics technology issues, implementing these personalized component sales will almost certainly require some customization or additions to your commerce engine. You know some implementation challenges are likely. But at this level of design,the sales appear to be do-able -- you cannot see any showstoppers. But customization to the existing commerce engine at this stage is a minor issue.

How minor an issue is it, though, when you consider supporting Ken's supplementary source of income -- his sale of in-game possessions?

Creating a barter/exchange system

Begin adding to this new lifestyle scenario:

Ken's character, Buffboy, finds another character, Cooldude, who wishes to purchase one of his possessions.

In-game commerce is a surprisingly large market. EverQuest's developers didn't support (nor have initial knowledge of) the market for characters and weaponry that sprang up on eBay. One study showed that the EverQuest universe of Norrath had an economy ranking close to Russia's in terms of per-capita GNP. (No kidding! For some people, their entire substantial taxable income as reported to the IRS comes from their dealings in this economy.) If you can provide gamer-to-gamer sales inside the game, you can maintain control of this market. If you can create a tax on these sales that go into your pockets, even better.

Lawyers may wish to get involved at this point to explore potential legal issues. For example:

• Is it legal (in whatever countries) for an exchange of cash or credit to occur for something that does not physically exist?
• Who is really the owner of the character's sword, spell, or other possession? The people who developed the game? The people who have the rights to run the game? Or the players who currently hold the possession?
• How do you value the item, and create the exchange?

While you find some thorny issues here, you also find precedents. Casinos have in-casino chips that can be credited to an account, exchanged between players with their agreement, or exchanged for cash at the casino entrance. Frequent flyer miles are another example of an intangible good with questionable ownership that is exchangeable for real money.

Based on these examples, you'll create in-game scrip for use as currency within the game, exchange between players, and credit to the gamer's account.

While this is still commerce, it's quite different from the first scenario. It is, in fact, not a sale that manifests in a transfer of goods in the external world with a cataloged item of inventory that must be managed. This is actually the moving of an item from one gamer to another and a simultaneous exchange of scrip.

The scrip could be implemented in a number of ways. A simple way is to have the scrip exist as a possession within the game and require the gamer to take specific action to move scrip between his account and his in-game existence.

Another option is to have scrip exist as an external currency and to have each transaction manifest in the gamer's external account. You could seamlessly provide a secure link between the in-game existence and his account, so that use of the scrip in the game immediately translates into an account balance change.

This option requires a greater level of integration; greater security, given the temptation to hackers; and probably, greater expenditures on the part of the character since it is then far easier to lose track of expenditures (similar to a casino effect). It potentially also carries with it higher threats of liability, but I take a technologist's view of this and leave that as the lawyers' concern.

I use the first option here since it reduces the level to which you must integrate support of scrip into the other business systems (such as accounts, commerce, and accounting systems). Let's play out this scenario:

Buffboy and Cooldude haggle and reach an agreement on a price in scrip, the local in-game currency. Buffboy then gives Cooldude the item, and Cooldude gives Buffboy a certain amount of scrip. Behind the scenes, the scrip is deducted from Cooldude's in-game scrip balance and added to Buffboy's scrip balance -- potentially minus a transaction cost. When Ken later goes to check his in-game balance, his scrip account has increased.

The exchange between the characters is straightforward to implement within the game. You have a database -- the game database -- that tracks all characters and knows what items they possess. You can easily create a scrip account within the game to add to and subtract from as a result of an agreed-upon exchange by the players.

However, you still have to account for the transfer of scrip from the in-game account to the external directory:

Ken's character, Buffboy, can request more scrip to be added to his in-game account. He can also request an exchange from scrip to dollars which causes a transfer of the scrip from the game to the gamer's account. The accounts system recognizes scrip as a currency with a given translation into real dollars. Ken can pay his account or purchase items from your online store using scrip. He can also transfer amounts between scrip and dollars at will, add dollars to his account to get more scrip, and vice versa.

How will you implement this? You have a gamer directory which identifies the gamer associated with each character. You can also locate each gamer's account in the accounts and billing system. However, you are now asking for an in-game request to affect the external business systems, and vice versa -- something you only want to do cautiously, under extreme control. Your games programmers are not experienced in this area. This also seems like a function that hackers are likely to target, a further reason for caution.

I mentioned in the previous article that outsourcing a component to an entity that is experienced in creating a specific critical function can be the most prudent path to follow. A little research locates a technology that can help in this instance.

Business Integration for Games (BIG), for instance, is a technology available on the IBM alphaWorks site, which provides a Web-services-based interface between the game and out-of-game services (see Resources). By using BIG, you can make Web services calls from inside the game to the business system that manages the gamer's accounts. By using a specified service in this way, you can simplify the coding from the programmers' perspective and secure the calls by ensuring that the Web services request is accepted only under specified conditions. In fact, BIG has already been integrated with a micropayments service that you may also wish to use.

This is your first need for an external manifestation of an in-game event, but you can easily see additional uses for the same technology. Now take the scenario to the next level of complexity:

Barbie's character, Cutegirl, finds an in-game store, CoolStuff Inc., which advertises personalized T-shirts, showing her avatar. The price is set in scrip. She agrees to buy. Behind the scenes, the cost is deducted from her account. You are running the store, so the scrip value becomes a transaction that adds to your internal account; you also register a purchase transaction in your commerce system for a personalized T-shirt on her behalf. When Barbie later goes to check her account, it has decreased by the T-shirt's cost.

Again, an in-game transaction has out-of-game consequences. In this case, the in-game transaction links to the out-of-game commerce system. You can use BIG to act as a programmer-friendly interface between the in-game transactions and the out-of-game commerce engine.

You also wish to ensure that hackers cannot easily penetrate your business systems, so a firewall divides the game infrastructure from the community infrastructure where the commerce engine resides. Carefully managed firewall holes reduce the danger of security compromises.

Take a look at the additional complexity now added to the game zone.

Remember that every time you expand the scope of your game environment -- whether answering or anticipating gamers' needs by adding and refining services -- you are also contributing to your own best interests. Additional revenue means keeping the game going; that means the company can keep going; and that means you can continue to do a job you like.

Ancillary products and services such as image transfer to physical items and real-world-to-game-world (and game-world-to-game-world) economic exchanges enhance the player experience -- and help keep the business bottom line black.

Now look at the device connectivity requirements I mentioned in the scenario.

The complexities of hooking up

Online games have moved beyond the simple PC environment (as evidenced by the mention of at least three separate classes of devices -- game consoles, cell phones, and hybrids). And you don't want to limit your solution by implementing technology that is too tightly tied to specific devices -- you want to easily support new devices as they become popular.

Revise the functional diagram to reflect this change.

Which pattern fits?

Again, look at whether the patterns can shed light on this. After a little searching, I locate the Pervasive Device Access application pattern::Runtime pattern:: Pervasive Device Services pattern. I validate that the pattern applies to self-service applications such as this one.

The functionalities included in this Runtime pattern are:

• Connectivity -- Implemented by the Gateway node providing communication between pervasive devices and the Web applications
• Application server types -- The app server hosts the application that is designed to handle different types of devices
• Notification -- Provides message interchange between users and applications
• Synchronization -- Provides data synchronization with applications like mail servers and relational databases through communication channels
• Device management -- Provides identification, configuration, inventory management, and software distribution to devices such as PDAs, handhelds, smartphones, wireless access protocol (WAP) devices, or other emerging devices for pervasive computing

This pattern also:

is based on the n-tier model and supports browser users (client node) and mobile users (pervasive user node) accessing back-end applications. The mobile users will have to pass through the gateway to access the IP network and through the transcoding proxy or transcoding functions provided by the Pervasive device services node to adapt the content, based on the type and capabilities of the mobile user device. The presentation tier is split into two, represented by the Web Server Redirector and the Application Server nodes. The Self-Service application runs on the application server. The notification, synchronization, and device manager services also run in the application tier on a separate node.

This pattern certainly seems to address the functions that you need; it also addresses some functions that you have not yet thought about, such as synchronization.

Look at Figure 3 more closely. The non-browser-based user is shown here as a pervasive user. The user accesses your Web site over the Internet, just as the PC users do; however, the access is mediated through a gateway that translates protocols to and from the non-IP network to which the user is most directly attached.

Does this model fit for your purposes? Take a more detailed look at the prevailing game device classes in use today and see where gaps exist. The PC-based game was covered in Parts 1 and 2, so I'll focus on PDAs, mobile/pervasive devices, and game consoles.

Games on the go: Mobiles

Mobile and pervasive games are a new, fast-growing segment of the overall games market. The mobile devices used for games are generally cell phones or connected PDAs with the occasional hybrid device (such as Nokia's N-Gage).

The capabilities of these devices vary tremendously. What they have in common is that they are connected to the network through a network service provider, often a large telecommunications company. The specific connectivity varies based on the network provider.

While mobile games have been limited by small screens, bandwidth, and network response times, this is an area which is changing quickly. Games exploit these constraints, particularly in Europe and Asia. Some games adapt to these constraints in often quirky fashions (such as a Japanese fishing game in which people choose locations near each other on the game map to get an e-mail when a neighbor catches a fish).

How does this affect your ability to present your game on these devices?

• The limited screen size of the mobile devices requires dramatically simplified graphics for the game.
• Limited CPU and memory power supports only a subset of available game functions.
• Limited programming environments -- generally either J2ME (Java-based) or BREW (C/C++ based) -- may mean multiple versions of the game dependant on the specific mobile device. You also need to understand download mechanisms.
• Inconsistent connections and lower bandwidth, depending on the protocol in use, limit connectivity choices. With J2ME's MIDP profile you would use an HTTP subset, for example. If the game is not real-time or is designed to allow delays between player responses, you may also be able to use other protocols, such as SMS or MMS, to provide the transfer of data between the player and the back-end game infrastructure.

To provide your game on these devices in addition to a regular PC environment, you probably will create a lite version of the game to deal with this combined set of constraints while still providing an enjoyable playing experience. This is possible with some thought, though by no means a trivial task.

Some of the other services you plan to provide may also need to be altered to account for device constraints. How can you provide the interface to your FAQ information and commerce system, for example?

Most cell phones with IP-level connectivity do provide a browser-based interface to the Internet, so you can use the browser as an alternate access mechanism to your portal and commerce functions, just as you have for the PC.

You need to ensure that your back-end infrastructure can respond to requests from these devices in a useful fashion.

Luckily, some of the existing technology has these capabilities. Portals available today provide a level of support for cell phone browsers (CHTML browsers provided in NTT DoCoMo's i-mode phones or the WAP browsers provided by some European phone manufacturers). These portals provide a mechanism that identifies the browser capabilities based on information passed to them in the HTTP header and can choose among available portlets to respond in the appropriate protocol.

This solution only addresses the services that, in a PC, are provided through browser technology. For example, if your game provides instant message capability, you may need to adapt this to use alternative services already available on mobile devices, such as interfacing to an SMS capability. If your game uses voice and the mobile device provides voice capabilities, you need to provide an alternate driver to interface from the game to the device's voice capability.

Now take a look at the types of game consoles available.

Games in your room: Consoles

The game consoles on the market today split neatly into two types based on the different business models of their makers:

• Xbox (Microsoft). Microsoft mandates the connection and the game infrastructure. All online game providers that wish to provide games on Xbox must become Microsoft partners. Their games are accessed from Microsoft's game portal (Microsoft Xbox Live) and must use their mandated APIs.
• Playstation and Playstation 2 (Sony), and Game Cube (Nintendo). These are open platforms from an online game perspective, in that the game infrastructure is not mandated by the console vendor. The games can connect to any game server, as required by the infrastructure provider of a specific game.

Since the back-end infrastructure for closed-environment Xbox games is mandated by Microsoft, I will exclude that console environment from this discussion.

Games on console devices, like PC games, often use socket-based communications to connect to the back-end game infrastructure. However, they do not, in most of today's console devices, have the option of switching to a browser to access functions such as the community Web site. Out-of-game functions like registration are performed from within the game or from within the console, using code written and provided by the game provider. The functions available are limited to those foreseen by the game developer.

In your game environment, though, you want users to access functions such as the commerce functions I mentioned. A technically simple (possibly user-unfriendly) solution to this is to require the gamer to access other functions on a PC (ouch!). This way, if console-owning gamers wish to browse FAQ, contact customer service, update credit card numbers, or purchase expansion packs, you simply require them to access that function from their PC using the Web site you've already built.

Alternatively, you could write or acquire a browser that runs in the console. Some games take this approach, but this seems a complex and ugly solution. New versions of consoles are likely to contain browser capabilities, making this a lot of effort for limited return.

Another alternative is to provide access to the same functions that a gamer visiting the Web site would have, but from inside the game.

To do this, you have to provide some type of interface between the game and out-of-game services. However, as an infrastructure provider, you certainly don't want to burden the developers with needing to know how to interface to each of the business systems in your infrastructure. At the same time, you also don't want to expose the business systems to direct requests from the code written by game developers, since industrial-strength code and high-availability production systems are not generally their forte.

What you'd really like is some way to allow the developers to access the systems while shielding them from the details.

As it happens, you've already included a mechanism for doing exactly that: Business Integration for Games. While you initially added BIG to integrate commerce into your game, now you can use it to integrate other services. This component reuse can greatly simplify your overall infrastructure.

How do devices affect our model?

You have identified three major concerns to account for when dealing with devices:

• Multiple versions of the game for these additional devices handle the device constraints. However, your back-end connectivity and infrastructure for the core game itself is the same.
• Some additional functions, such as voice and messaging, require alternate designs and possibly different infrastructures to support them.
• Community functions handle access from different device types. In some cases, you already know that this support is provided by some of your products; in other cases (such as commerce) you might need to investigate how to do this. For example, you may wish to use transcoding.

Many gamers own more than one of these devices. Gamers who own a console or handheld might also own a PC. Many gamers also own a cell phone and PDA, and use them for gaming in different environments.

A gamer friend of mine uses his PDA-based games while playing on the move, but switches to his PC in the office or a game console when he is at home. Today, due to technological constraints, he chooses the game he wishes to play out of the choices available on the most game-capable device with him at the time; he would prefer not to have this constraint.

What's next?

In this article, I identified a new scenario: game playing as a lifestyle. This brought a new set of requirements that demanded additional functions in your game environment -- the need to leverage the gamer's love of playing (and for you to make the most profit).

I discussed requirements needed to create ancillary products for the gamer to purchase, including graphics issues in translating game images to physical items. I also covered the components necessary to building a barter/exchange system, one that works within your gaming world and between the game environment and the real world.

I covered the realities of connectivity between your game and the multitude of devices that gamers might use to access the game environment, identifying the types of game devices, the critical issues in connectivity, and the useful patterns to help adapt your solution to allow a larger number of potential gamers to access the most services in your environment.

In the next and final article, I'll share some thoughts on addressing community issues and examine the functions necessary to game upgrading and account maintenance mechanisms.

Resources

• With Business Integration for Games (BIG), provide a framework using Web services as the underpinning technology and take advantage of reusable business function, distributed throughout the network.
  
  
• 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 may make it easier to choose the correct patterns for your design.
  
  
• 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 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 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).
  
  
• To get an idea of the hundreds of sales of game accessories that occur, log on to eBay and search for Ultima or Everquest.
  
  
• Check out the 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).
  
  
• 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).
  
  
• Read "'EverQuest' spins its own economy" and uncover the closed-economy boom spawned by this game.
  
  
• In "eBay, Yahoo crack down on fantasy sales" and "Sony to ban sale of online characters from its popular gaming sites," get the details of eBay's, Yahoo's, and Sony's responses to the closed EverQuest.
  
  
• Explore the game-playing lifestyle in more detail in "The Unreal Estate Boom."
  
  
• Enable collaboration capabilities for portal users with WebSphere and Lotus Sametime technologies in "Integrating WebSphere Portal Extend V4.2.1 with Lotus Sametime 3.0" (developerWorks, June 2003).
  
  
• Patterns for e-business: A Strategy for Reuse (IBM Press, 2001), by Adams, Koushik, Vasudeva, and Galambos, is the basis for this article. Read a chapter from the book.
  
  
• 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.
  
  
• Find articles about every aspect of building for the World Wide Web in the developerWorks Web Architecture zone.
  
  
• Browse for books on these and other technical topics.
  

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.