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.

Figure 3. Pervasive Device Access application pattern:: Runtime pattern:: Pervasive Device Services

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.

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.