Aiding content evolution

While you cannot help with the last mile (the speed of individual gamer's access), you can ensure the only constraint the gamer encounters is their connection speed and not one created by bottlenecks in your infrastructure.

Well-understood methods can reduce the strain that large downloads create on the core network, even if they do not help with the last mile. Caching the patch files at the edge of the network is a simple approach to reducing the load inside the infrastructure. You can also work with a service provider that specializes in providing caches in points of presence close to concentrations of your gamers.

From your side, you need to create a patch file or upgrade file that is internally consistent and serially upgradeable. This means:

• The upgrade should not reintroduce any previously fixed bugs (first, do no harm).
• The upgrade should have all the required components and co-requisites of the fixes that it does have.
• Each upgrade should layer atop the previous upgrade without concerns about incompatibility.

To manage patches and upgrades on an ongoing basis, it is important that adequate problem-management and version-control capabilities are implemented in your development processes. You need to:

• Recognize which problems were fixed in each patch and which problems remain to be fixed.
• Link this information to your gamer-accessible problem database so a gamer who receives an error can quickly and painlessly identify whether an available upgrade is known to fix his problem.
• Recognize which patches were downloaded and installed on this gamer's version of the game and which patches still need to be downloaded.

A gamer finds few things more frustrating than downloading patches and upgrading software, only to discover that he still has the same problem. Then, he calls the help desk and someone tells him that it's a known problem that has not been fixed yet.

Generally, you should plan to group the patches into a bundle, and give them a consistent number such as V1.8.11. When a gamer connects and requests a download of a patch but has not previously downloaded all prerequisite patches, you should identify the list of patch files he requires to upgrade his current level to his desired level, and then automatically download all of them.

A complementary approach -- one that may be particularly appropriate for pervasive devices such as cell phones -- is to use a managed provisioning system to provide download capabilities. For example, a new patch becomes available for a specific device type or class of devices (when, say, just the game version for the N-Gage has a problem). The administrator creates a job that will notify all devices of this type that a new patch is available when the user next connects to the site. The provisioning system keeps track of which devices have successfully downloaded the patch and which have not. As a result, if a gamer connects after having missed several patch notifications, the provisioning system can notify the user of the full set of patches they should download, ensure that they are applied in the correct order and that the next one is not started until the previous one has been successful.

This kind of functionality has become popular for enterprise systems during the past few years because of the difficulty of ensuring that large numbers of PCs and laptops receive security patches for the most recent worm or virus. It is becoming more popular in consumer software, too; for example, the upgrade capability in Quicken or the operating system fixes downloaded by Dell. IBM also has an off-the-shelf component called Tivoli® Device Manager, which is designed to manage this kind of environment.

Another way of adding content

You can add content to the game using a different method.

In the game, Buffboy approaches a ferry at the bank of a river. The ferry requires a toll. Paying the toll will let Buffboy take the ferry to a new land, complete with new challenges and quests.

This is a content upgrade of a different kind; it gives you a nice, neat way to expand and refresh the content available to the gamer. You can easily place locations around the game that act as entry points to additional content. Whether someone has the right to pass into the new section of the game needs to be checked only when their character arrives at the entry point and attempts to enter. Once they are in the new section of the map, you can assume that they have the right to enter.

Implementing the toll is also simple, using mechanisms similar to those discussed in the Creating a barter/exchange system section in part three of this series. The right to access the new content could be listed as a catalog item external to the game for the gamer to purchase. In reality, paying the purchase price alters a setting in the gamer's directory entry. Once the character reaches the toll bridge, your software can check the gamer's directory entry to establish whether they've already paid.

In addition, you can set a price in scrip and the gamer can make a purchase from inside the game when his character approaches the toll gate. At that point, a download is triggered if changes are required on the game client. If the new part of the game content merely reuses existing code on the client, then no download may be required.

This scenario adds quite a few functions here. However, if you look at the services that your infrastructure needs to support, you'll discover that these functions are already provided -- including portal functions and several forms of collaboration, such as chat, e-mail, and presence. What you have done is reused this same infrastructure to provide new capabilities.

Helping the users

Access to customer service is also a key part of creating the community. Expect customer service needs to vary in many ways, from resetting access passwords to getting a player unstuck, from handling account disputes to fielding complaints about the behavior of other players. And of course, collecting information about bugs.

For a large game, customer service can be a significant expense. Automation is critical. A useful rule of thumb:

Individual contacts with your gamer base can easily equal the total number of subscribers you have.

These contacts range from technical support requests, billing and account management issues, e-mails, and in-game help requests.

A scenario

Now, add one last set of meta-level functions.

Ken needs to pay his bill. He thinks he's earned enough from weapon and spell sales to purchase the new version of the game that is about to become available. He wants to check whether the new graphics are at a sufficient resolution to exploit a new, high-definition screen he plans to purchase. Meanwhile, Barbie has got herself into a predicament. Whenever she tries to play, the game tells her someone else is already playing her character. She needs to call on one of the game gods to get her going again.

The new customer-service requirements

You are adding the following functions (plus some obvious extensions):

• User account management (self-service) that allows gamers to renew their subscription, check their account status and balance, and so on (You want to provide this function only for registered users.)
• Customer service through multiple mechanisms: e-mail, chat, or telephone (only for registered users)

You must strike a balance: you need to provide easy access to appropriate assistance without drowning under the volume of requests. You can move in this direction by providing useful self-service mechanisms to gamers. In situations in which this is not sufficient, you can provide access to customer service personnel through chat.

The solutions

As a last resort, or when the gamer cannot get access at all, you can provide a telephone number. In this situation, a voice response unit can reduce the cost of customer service by providing information and simpler or more common transactions. Automate simple transactions and provide personalized responses by using Voice over IP (VoIP) technology combined with a VXML browser. Recent advances have enabled the movement from fixed, preprogrammed responses and inflexible programming models requiring specialized skills to technologies that are easy to program and integrate.

If you add these components into our Runtime pattern overlay, you'll end up with the following updated diagram.

Figure 2. Final overlay of Runtime patterns

What's next?

In this article, I discussed needed community-issue functions such as:

• Providing for self-regulating communities in the form of guilds
• Focusing on purpose-built content and personalization
• Giving groups the ability to recognize their own members for the purpose of content distribution
• Offering gamer education
• Identifying the need some users might have to communicate with other players within the game
• Possibly providing a statistics-based function that could help "matchmake" gamers

When it comes to upgrade issues, I discussed:

• Downloading and installing patches
• Recognizing the current version a player is using
• Automatically installing any patches needed to bring that version up to speed
• Providing an indicator of when a new version is available
• Offering automatic, user-accepted installs of new versions

For customer-assistance issues, you examined self-service user account management that would allow registered gamers to renew their subscription, check their account status and balance, and additional functions. You learned when to use customer service over multiple mechanisms such as e-mail, chat, and telephone.

For all of the new functions covered, I offered pattern advice and helped start the process of matching the functions with real-world products to meet those requirements.

In the next (and last) installment in this series, I'll recap the entire process and describe how to put the game environment to work. I'll deliver a revised build-buy-borrow outline, complete with some real-world product solutions, and offer some ideas about further potential functions for the environment you may want to consider.