Online games are the future of the interactive entertainment industry. They also present a number of exciting opportunities for new business models, new markets, and new growth. The main problem faced is a solution integration issue. This article describes a framework for online games using Web services as the underpinning technology that can take advantage of reusable business function, distributed throughout the network with a solid integration story.

Introduction
Online games are the future of the interactive entertainment industry, seeing the convergence between the traditional media, and entertainment industry, and the gaming industry in an effort to develop new and sustainable business models and revenue streams in an increasingly online world. They move the gaming industry into a more functionally rich online environment from which the majority of the revenue stream will come -- an e-business environment. But moving to this new model presents a number of challenges to the games developers, the players, and the service providers who ultimately will need to support this new environment.

However, it also presents a number of exciting opportunities for new business models, new markets, and new growth.The main problem faced is a solution integration issue. The player wants to pay for online content with their existing channels, but they also want security and privacy. The developers need cross-platform integration and support for multiple services, channels, and providers. The service providers need to build reusable business function that is robust, efficient, and generic -- it should work for all business models, not just the gaming industries. This article describes a framework using Web services as the underpinning technology that can take advantage of reusable business function, distributed throughout the network with a solid integration story.

The business problem
The difficulties with the business of building online games consists of determining an appropriate Business model for the game, and an appropriate Revenue model.

The Online Game Business Models
As a gross generalization, games today are either expensive and solid, or free with a diverse range of quality. The challenge for mass-market online games is generating enough advertising/sponsorship revenue to cover costs and turn a profit, or alternatively getting enough Casual and Resistance consumers to pay to play. These consumers will pay for entertainment, but the product and business models aren't there yet. Hard core gamers are willing to pay for games, but not every $10/month game can be successful due to the limited number of hard-core gamers. Consolidation of some online games may be necessary. To understand the business models it is important to understand the value chain of the gaming industry and the relationship between the players in that value chain.

Figure 1. Online games value chain

Figure 1 illustrates the six roles in the value chain, and calls out some well-known examples of each role across the industry. The chain starts with content owners producing a game that is then made available to the consumer through some aggregating or hosting entity. The online solution is supported by a number of services provided by, potentially, non-affiliated service providers, and finally delivered to the consumer through some network service using a game device.

However, content owners constitute a set of parties collaborating to produce the content. This group can usually be made up of some brand owner, such as Disney, who is licensing the use of their brand, a developer, such as iD software (developers of Quake), and a publisher, such as Electronic Arts. In the case of console games, the publisher may also be the console manufacturer, and licenses the right to develop content on their console to the developer. The developer may either be owned by the publisher, contracted out for piece work and ports, or funded for the whole program. The publisher may pay the developer a flat fee for their work, a usage-based fee (based on actual usage of the product), a royalty-based fee (based on revenue to the publisher from the product), or a hybrid of these.

The online game is then distributed to the consumer through one of a number of possible mechanisms, depending on the architecture and style of the game. The different mechanisms available are:

• ISP or Portal site
  Partnership with an ISP such as AOL or MSN, or a major portal such as Yahoo!, where the partner acts as an aggregator for online games, and offers wide exposure through their customer base.
  
• Dedicated online game site
  A game-specific aggregator company, such as GameSpy and MGON, whose business model is to attract a loyal customer base and offer peripheral value-add to the games such as community building, player matching, and other enhanced playing experiences. Often these companies produce a toolkit to allow developers to integrate their games with the sites specific value-add infrastructure.
  
• Independent server
  A service dedicated to one specific online game, providing all of the required CRM and delivery requirements for that game. These are usually associated with a major publisher and a strong brand. A select number of larger online game providers have created proprietary game architectures dedicated to a select set of their game titles. An example of this is Blizzard Entertainment's Battle.Net, which provides online gaming for their premier real-time strategy (RTS) titles, StarCraft, Warcraft, and Diablo. Blizzard operates the Battle.Net game system, with hosting handled by AT&T (North America), Telia (Europe), and Dacom (Asia). Blizzard Entertainment is a Vivendi Universal business unit.
  
• Peer-to-Peer
  Many popular current games, such as BioWare's Baldur's Gate and NeverWinter Nights, employ player-to-player online gaming networks, where each player machine participates in a peer-to-peer relationship to create the shared, online game environment. This is often called the Pen and Paper model of role playing games (in reference to the Dungeons and Dragons-style game play). In the examples from BioWare, both Baldur's Gate and NeverWinter Nights provide online gaming in this model for free. Further, NeverWinter Nights includes a toolset for creating persistent worlds; the general concept is to put the online gaming network into the hands of the players, very much like the "Dungeon Master" role of Dungeons and Dragons.

For any of these options, the infrastructure could also be potentially outsourced to a hosting company, such as IBM.

A number of service providers may also be required to complete the solution that makes up an online game offering, especially with respect to fulfilling the revenue streams from e-commerce and pay-per-play models. Such services as Payment Enabling, such as those provided by PayPal.com, and those integrated with other utility and Telco companies, may be required to be integrated into the game environment. If digital content is protected using some DRM solution, a clearing house service may be required. If e-commerce is required within the game experience, to support the purchase of either electronic or physical assets, then integration with the merchant site is required.

Access to the game is supported through some Telco or ISP. In the case of PC games, the ISP will be the provider of this service. In the case of consoles, the console manufacturer will partner with ISPs and offer a specific service for that console. In the case of wireless and iTV, the players access is provided through their Telco.

The Online Game Revenue Models
The current models can be broken down into three main categories:

• Free Model
  All aspects of the game are free to the consumer. All revenue to the publisher comes from either sponsorship and product placement or advertising.
• Pay for Play Revenue Model
  This can be subdivided into four main sub-categories:
  • Subscriptions
    Allows unlimited access to the player and supports the ongoing development and support of the online service. EverQuest and Phantasy Star Online are popular examples. An interesting recent development in the use of this model is to support clans in FPS-style games that do not require persistence, but require service provisioning of a game server for essentially private use. Dedicated players group socially together online in clans and then pay a subscription fee to an aggregator to host a dedicated server for their use. Quake3 and Counterstrike are popular examples of this phenomenon.
  • Metered usage
    This has faded in popularity in PC and console markets but is still a typical means of revenue in wireless gaming, usually implicitly through use of call time to play the game. It is also a popular means of revenue in Asia through PC baangs, or cyber-cafes oriented to online games playing. The baangs will charge players $1 per hour to play MMP games such as StarCraft and Lineage.
  • One-time fee
    Typically the cost of the game client as a boxed product to the consumer. This may or may not be linked with other pay for play models. For example, EverQuest also employs this model in conjunction with the subscription model.
• Other Revenue Models
  Many hybrids and combinations of the above models can be employed, as well as incremental revenue from other sources. For example, a subscription model may also augment the revenue with one-time fees for participation in special events, like a tournament, or a One-time fee model may allow further episodic content to be downloaded for extra money.

The technical problem
The main technical problems that arise from these issues can be broken down into four main categories.

• Integration logic
  In order to connect the members and fulfill the value chain, third-party-provided systems and services need to be connected and interoperate with each other. In a truly flexible solution, these parties may not previously be integrated or even aware of each other as consumer choice and business relationships combine into a solution instance.
• Business logic
  The code to embody the business requirements of interaction between these multiple parties is neither germane or, in some cases, relevant to the game. At best, it is potentially required to change over time and should certainly be abstracted out of the game logic.
• Delivery capacity
  When consuming and producing messages between the game and the service providers being used, it is important to be able to manage the resources involved in fulfilling this chain, and not to overload a single point in the solution with the responsibility of delivering the services to the game.
• Security and trust
  The execution of this business logic may involve access to private information belonging to multiple parties. For example, to exchange funds from one party to another, an account and pin may be required. Consumers do not want to configure a game with their own private details, and they do not necessarily trust the game code (or the thing charging them for use) to manage the financial transaction. This problem is exacerbated if the transaction is between two players. Coupled with this trust issue is the problem of security and protection from malicious attacks, either from players, rogue service providers, or rogue games.

The proposed solution
Our proposed solution to the development of online games takes advantage of a new technology in the world of software integration.

Web Services
Though the "dot com" craze has ended, business use of the Web is going strong. Over the past several years Web applications have evolved from simply rendering Web content to becoming a sophisticated business productivity tool capable of supporting dynamic and innovative business models while significantly lowering the costs of integrating businesses.

The current downturn in the world's major economies have driven customers to focus their e-business strategies on lowering expenses and increasing efficiencies, including the overall optimization of processes internally and with partners. Yet, these same firms are also trying to drive new or additional business by increasing customer loyalty and satisfaction through better personalization and service delivery. Now more than ever customer investments in IT technology, products, and services must have a direct impact on the business fundamentals. Business Managers are looking to:

• Leverage IT to lower the enterprise cost and improve productivity and efficiency in business operations by improving integration, communication, and information exchange with suppliers, business partners, and customers
• Leverage IT to support new and innovative business models that penetrate new markets and provide direct access to customers and business partners.

• Finding services :
  A standardized way for customers and business partners to find the available services of a given business, and to seek the services they want.
• Accessing services :
  A standardized means for sophisticated consumer and business applications to programmatically use services provided by other businesses.
• Communications security :
  Standardized mechanisms to provide sophisticated user authentication and attribute information in a secure way over a communications channel.
• Federation :
  A standardized means for allowing businesses to directly provide services for customers registered at other (partner) businesses or institutions. With Federation, a business gets trusted information about an accessing user from the user's home organization. The business doesn't need to register that user, and the user is spared from having to get and remember a new login in order to interact with the business.
• Cross-enterprise trust :
  A standardized means for establishing and reflecting trust between organizations. This is a key issue for Federation.
• Federated Identity and Attribute Mapping :
  Well-understood mechanisms and procedures for mapping trusted information about a foreign user (users from business partners) into authentication and authorization information usable to an enterprise's existing services.

Some have learned that the most flexible and cost-efficient way of addressing systems integration is through Web services, where the reusable function is made available to the world as well-defined interfaces, accessible using open standards and protocols, where integration can effectively be achieved at run-time through the use of directory services to discover and determine the integration requirements. This dramatically reduces the software development and systems integration requirements and cycle times. The proposed solution builds upon the IBM existing scalable, reliable and secure infrastructure for multi-channel e-business (such as WebSphere, MQSeries, and Digital Rights Management technology). IBM has thirty years of experience in transactional middleware technology.

But, making various services available on the network to perform generic function such as payment and transaction control through a Web service interface is not enough to be of immediate use to the gaming industry. Games developers are not interested in a new layer of complexity with which they must cope in order to build their systems. Therefore, the proposal embodied within this article is to develop a piece of middleware that provides a layer of simplicity, tailored to the industries requirements, to act as the service layer between the games environment and the intelligent infrastructure.

This architecture isolates the e-business-specific technologies from the game environment, allowing for upgrading and extensions to function to be carried out without affecting game code. It would also mean a native client interface could be provided suitable for whatever the target-client game platform is, and reduce the memory and processing costs within the game code. What is more, the Web services would be usable for a wide range of applications and industries, not just the gaming industry. The games would become just another source of interaction with these e-businesses.

Figure 2. High-level architecture

In figure 2 you see an architecture divided into three layers. In the center of this is the Service-Oriented Architecture as proscribed by Web services. These are the functions made available by service providers to their customers over the internet, and we consider those kinds of functions that could support the online games business models that may evolve, such as payment provisioning, location and notification, e-commerce, rights management, and directory lookup.

At the periphery of the architecture we have the potential game platforms that access the network through their relevant point of presence. These may be PCs and servers, mobile devices, consoles, Set Top Boxes etc. The common feature across all of them is that they contain a thin client to connect them to our middleware infrastructure.

Between these two layers we have the Process Brokers. These form an enabling backbone of servers that provide the abstraction of business and integration logic using open standards and provide a Process-Oriented View of the network of e-business services within it.

The Client Connector
It is the responsibility of the Client Connector to present the process oriented view to the game developer through simple APIs, so that a developer may deal with high-level business function encapsulated within a single function call and rely on the middleware infrastructure to protect them from the details and complexities of the business and integration logic required to fulfill that process. It is also responsible for abstracting the personal, sensitive data belonging to the player away from the game code and client API and moving it to a place that can be administered and controlled by the owner of that data -- the player themselves. This helps to provide privacy and anonymity to the player that desires it and a level of confidence and trust between the player and the game.

Figure 3. Component architecture

Figure 3 illustrates the component architecture broken down into the Client Connector, the Process Broker and the Services. The Client Connector is a thin client that presents the APIs to the game and stores/retrieves personal player data using a secure, encrypted repository. This repository, being persistent, is used to provide any game that uses the Client Connector so that a player does not have to re-enter their data each time they buy a new game, and they do not have to configure their personal sensitive data into any game.

The Client Connector must be as efficient as possible, as it will reside within the game footprint and execution path. For PC and console games, a native, portable C version is required that runs in a non-threaded or threaded model, with memory allocation restrictions to allow a game developer to predict and proscribe its behavior, should they wish.

The Client Connector establishes a secure session with the local Process Broker, and associates the session with the player’s identity within the infrastructure. This allows separate sessions to be correlated with a unique identity for auditing purposes. It then takes the parameters from the subsequent API function calls and marshals them along with required sensitive data from the repository to the Process Broker as a request for a specific process to be executed. The Client Connector should behave in a reliable and robust fashion, so that when a game calls a function call to request the execution of a given process, the game can rely on the middleware to complete the execution once the function call has returned. Therefore, if the game crashes between the function being called and the result returning, the middleware will manage the transaction and either roll back the transaction or persist the result until reconnection, depending upon whatever is appropriate for that process and service provider.

So, by requesting processes to be executed through the Process Broker, the client effectively interacts with Web services asynchronously, using these Web services to provide value-add e-business function rather than core game logic.

The Process Broker
The Client Connector establishes a session with the nearest or most appropriate Process Broker. Therefore, clients that will potentially interact with each other may be using different Process Brokers. Logically, the Process Brokers are a single entity, but are physically rendered as a collaborative network of edge servers.

Figure 4. Distributed process execution

Figure 4 shows how a network of Process Brokers may interact to provide connectivity between clients and service providers. Each client connects locally, but is allocated a globally unique ID so that the clients may refer to each other in function calls to the middleware.

For example, the two game clients in the diagram may wish to exchange money for some reason within the game environment (a payment for a game asset, for instance) and one of the clients would initiate the request for the process to exchange money, citing their own and the other client's unique IDs as two of the parameters. The Service Provider in the diagram would, in this example, be a Payment Service Provider, and its identity would be retrieved from the relevant client's repository and located and invoked by that client's Process Broker.

The Process Brokers are required to act as neutral intermediaries to coordinate transactions between the middleware clients, whether they are player/player or player/game server interactions. In some respects, they act as a generalised escrow service, brokering the information associated with the transactions and are responsible for the reliable execution of the process and persistence of any data over long-running transactions.

The Process Brokers also contain the business and integration logic required to interact with the service providers, insulating the game developer and code from service details and the need to perform business logic at the client. This helps to maintain a flexible and reliable solution.

This logic is encapsulated within the Process Brokers as modular components that can be composed into hierarchical business processes. This means that new processes can be modelled with tooling, rather than requiring code to be written, using existing logic and new function made available to the client connector.

Service Providers
Wherever possible, existing standards specifying Service Provider function will be used. For instance, the PayCircle initiative is one standard that is attempting to define how a Payment Service Provider should present their interfaces with Web services. However, in the case where these standards either do not exist, or have little or no adoption, alternatives must be sought. These can either be generic interface definitions that attempt to canonicalize likely function for a given service type (such as Payment service, Asset service, Security service, etc.) or specific integration logic for a specific Service Provider.

The choice will be influenced by selection of business partners in the value chain, emerging standards and pragmatics of a solution. IBM will continue to work with standards bodies to define the core Web services infrastructure specifications, and with business partners as required.

The initial function provided by the middleware categorizes the Service Providers into a set of types. These types represent a generic interface for that kind of service, and the combination of types can be used to fulfil complex business processes, such as a trade of digital assets protected by a rights management system in return for money.

The following sections detail the service types that have been defined in the initial architecture.

Payment Service
The Payment Service represents a Service Provider that can be used to capture a financial transaction and result in a payment being made between two parties. The support for a peer to peer charging model needs to be supported by this service to allow players to exchange funds, and also the traditional consumer/merchant model to allow a charge to be made on behalf of another service provider.

Figure 5. Payment Services

Examples of organizations that could fulfill this role are Telcos and mobile operators, pre-pay card systems, ISPs and utility companies, credit/debit card services etc. The actual payment fulfillment is abstracted from the service interface, so multiple payment models can be supported.

The Payment Service should be the preferred means of paying for all game experiences by the player, whether it is subscriptions, content, or premium services, so that all charges can be consolidated to a single payment channel for the player.

Asset service
The Content Service is responsible for persistence of digital content within the network, so that games may inject content and make it available to other game clients and servers. This can provide an abstraction over the network mechanism for achieving this so that content can be manipulated independently of its delivery mechanism.

Figure 6. Content distribution

Figure 6 shows two game clients and a game server interacting via a Process Broker. The game clients are able to inject new content into the game environment and make it available to other clients and servers through the Process Broker, which makes use of a content management system exposed as a service. The content service abstracts out the detail of how the actual content is stored and retrieved, so that a content repository of choice can be used to actually store the media. The game server can check authorization and control access to the media. This then allows the game developer to offload the content management and distribution problem to the middleware infrastructure, rather than building their own system. Since the digital assets are defined as an artifact of the middleware, they can be manipulated in conjunction with other Process Broker services, under a single transaction. For example, the game client may now be able to retrieve the content in return for a payment, controlled under a single function call. The function call would result in the Process Broker executing a process that grouped an asset manipulation on the content service with a financial transaction on the payment service.

A separate DRM service can be abstracted out to deal with ownership, key exchanges etc. and allow a separate DRM clearing house to be implemented from the content service. An example implementation that could fulfill this service is the IBM EMMS middleware.

Commerce service
The commerce service provides an abstraction of a Web-based store catalog service that would typically provide an online store capability to a Web site to allow customers to browse catalogs, choose items for purchase, shopping cart facilities, and purchasing. The commerce service allows a game to integrate the content and control provided by the e-commerce store into the game environment through simple function calls and the Process Broker. Because the notion of the store is abstracted out regardless of the actual content of the store, both virtual and real purchases could be possible. For instance, an online store that allows the purchase and download of digital game content could be integrated into the game environment so that the store manifests itself as a 3D store with shelves stacked with goods, like weapons, ammo and armour. When the player picks up an item from the shelf, it is "in their shopping cart" and when they leave the store they pay for the content, which is downloaded/installed into their game client and the necessary permissions to use are amended.

Alternatively, an online store that sells physical goods, such as merchandise, pizza, etc., could be integrated in exactly the same way, but instead of a content download, the content is physically shipped to the player.

Message service
The message service is an abstraction of a message distribution hub, so that applications and data can be loosely coupled through a publish/subscribe message distribution pattern. With the Pub/Sub pattern, messages are associated with topics, which is essentially hierarchical namespace with some semantics implicitly associated with it. A message broker provides a logical cloud that represents the topic space which contains all the topics. Entities using this cloud can either produce or consume messages, and they do this by publishing a message to a topic, or subscribing to a topic. Entities are unaware of each others existence, and they are only concerned with the topic space to which they are publishing or subscribing. Each entity may actually interact with the topic space over a different mechanism, but these details are hidden from the consumers of messages. Also, the use of wildcards is permitted when referring to topic names.

So, one entity may publish messages (sometimes called events) to a topic /Sports/Tennis/Events/Wimbledon/Matches/Henman that represents the current scores for Tim Henman. Another entity may subscribe to the topic /Sports/Tennis/Events/Wimbledon/* and get all messages published about any of the players in any of the matches in the Wimbledon tournament. Figure 7, below, illustrates how a Message Distribution Service abstracting over this kind of facility could connect game environments with producers and consumers of events in completely disparate environments, such as live sporting events or Web applications.

Figure 7. Message distribution patterns

The game code could either produce events by publishing to the PubSub cloud, or listen for events by subscribing to specific topics. This way a game could take the feed of telemetry data from racing cars and the trackside sensors in a NASCAR event and use them to simulate the actual event, without needing to understand how to interface with that particular telemetry feed. Reciprocally, games with multiplayer attributes such as tournament games could publish the current in-game statistics such as current scores, player health, location etc., and other applications such as Web sites could subscribe and aggregate this data and use it however it likes. The important thing, though, is that all the applications, whether they are the games or the web apps, need to know is the relevant topic names. No integration details are required to connect them otherwise.

Other services
Clearly many other kinds of services could be defined and integrated into the middleware, and then combined with each other to provide value-add processes usable from within the game environment. The above list has been a first pass at what might be immediately of value, and the imagination of the gaming industry can help to define further service types.

Federated Trust and Identity
As has been discussed already, there are different levels of trust operating between the various parties involved in the flow of data across the middleware, resulting in different security requirements and levels of federation across the solution.

The first level of trust that must be established is between the Client Connector and the Process Broker. It is imperative that this connection is secure to protect the integrity and confidentiality of messages being exchanged between these components.

Summary
By partitioning business logic, with all its inherent complexity and weight, outside of the game logic, game developers can be free to concentrate on the areas of game development that matter to them -- making good game play and design. The business logic can be executed outside of the game run-time, without bloating the game code and chewing up precious execution cycles.

However, the business logic is of paramount importance to the success of online games as a sustainable business model for the gaming industry, and having the flexibility to design and refine it outside of the game development, and even the game's life cycle, is critical. The ability to mix and match service providers to customers needs, without changing the game code, long after the game is released, enables the business model to support a longer life time and a continued revenue stream.

Open standards and business integration techniques are key enablers to achieving this within the gaming industry, but aren't immediately suitable for embedding within a game environment. The framework described here provides a bridge between programming models and operational run-times to allow the gaming industry to reap the benefits of becoming an on demand e-business.

Resources

• Download the IBM prototype implementation, Business Integration for Games from alphaWorks.
  
  
• Gamasutra is an extensive site dedicated to the technology of game software development.
  
  
• The International Game Developers Association holds regular meetings on the issues facing the game development industry.