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 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.

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 most interesting, however, is the capturing of e-commerce revenue streams,
either in the form of handling/royalty fees to the merchant, or between players.
The revenue from the "black market" economy of EverQuest makes auction
sites and others a significant amount of money that EverQuest sees none
of.

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.

Each of these categories contains a complex set of issues and, although apparently
orthogonal, all three categories must be addressed with a holistic approach to
ensure that meeting the requirements of one issue does not reduce the efficiency
of another.

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.

Attaining these goals using IT as a productivity lever has been both problematic
and challenging. In the IT world seemingly simple things like exchanging data
within a firm's heterogeneous systems is a challenge today, not to mention trying
to transparently deliver data to users from across a network of business partners
and affiliates. The promise of IT in leveraging the Web for linking heterogeneous
cross-enterprise, cross-platform, and cross-vendor solutions has not been met.
Companies have been unable to deliver bottom-line cost savings or achieve top-line
growth because, until recently, the following basic infrastructure services have
not been met:

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.

Today, these requirements are now in the process of being met by Web services
standards such as SOAP, WSDL, UDDI, and others. IBM is a leader in both the development
of these open standards, and in providing product implementations of those standards.

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.

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 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 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.

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 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.

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.