Business Integration for games: An introduction to online games and e-business infrastructure
Middleware to enable new business models in the online games industry
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 Online Game Business Models
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:
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 technical problem
The proposed solution
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:
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
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
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.
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.
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.
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.
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.
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.
Federated Trust and Identity
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.
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.
First published on developerWorks at http://www-106.ibm.com/developerworks/webservices/library/ws-intgame/