Unite 2010GDC ChinaAsia Game Show 2010GDC 2011
Distributed GamingThe First AttemptThe first network games took a centralized approach. This was the most obvious choice when considering a current game design that one would like to make network-aware. The "client-server" model was well known in other software applications and so were the methods to combat latency and scalability: buy a lot of pipe and high-end servers. For small network games, a client-server model is still a popular choice. However, this becomes quickly un-wieldy when attempting to scale to thousands or more concurrent users. Obvious bottlenecks occur and the overall game-play degrades. E-commerce SimilarityA similar situation occurred within e-commerce and the Web. The first approach to sell products online took a client-server model where customers interacted with one or more web servers that in turn interacted with one or more databases. The performance issues that ensued surfaced as incomplete orders, credit authorizations that "hung", and product pages that never fully displayed, to name a few. Reliable methods were needed to scale specific "pieces" within an e-commerce site. This led to the introduction of several component architectures (including CORBA, COM and EJB) to better identify and encapsulate these pieces of functionality. This also facilitated the means to dynamically scale resources within a given server. However, scaling across server boundaries was still very difficult to accomplish and generally required that all servers were co-located for better efficiency. Without the ability to scale specific resources across a collection of servers, component architectures were limited to duplicating all resources across identical servers with the load-balancing of user requests handled by external network hardware. A further means was needed to scale specific e-commerce resources. The ability to perform this across heterogeneous platforms was also desired. Moreover, the ability for disparate systems to interact from separate, remote locations would facilitate business-to-business (B2B) transactions between corporate partners. In the end, such facilities would help prove e-commerce as an efficient, online retail channel. Recently, "web services" has become a popular technology to deliver such facilities. This technology enables disparate, heterogeneous systems to communicate effectively across the Internet with one another and expose internal services in a common structured language. Web services also shares many goals with peer networking. [2] Distributed GamingOnline gaming can learn from the trials put through e-commerce development. The differences between the two applications can be generally boiled down to the nature of the specific resources and the timeliness of the data. Whether we talk about the state of product information in an e-commerce system or the state of the "universe" in an online game, the issues of scalability, reliability and availability are still the same. Drawing from web services and peer networking, we can envision a model for online gaming with the following features:
To facilitate these features, we define the following: The Resource: The encapsulation of a specific source of information or service particular to a game. The total extent of a game application is the summation of all unique resources. All resources share these qualities:
The Provider: A peer that provides a unique resource to consumers. The Consumer: A peer that seeks service or information from another peer it considers "trustworthy" to some measurable degree. A consumer can be any peer in the network, including those that are also providers. The Trusted Peer: A provider that, over time, has given a degree of consistent information or service so that it is considered relatively "trustworthy" by a specific consumer. Trust is measured by a combination of metrics that represent the reliability and availability of the information or service that the trusted peer provides to the consumer. As such, these metrics are calculated from the viewpoint of the consumer but can be shared with other consumers to build a "network of trust" amongst all consumers seeking the same resource. The Registrar: A specific type of provider that manages the discovery and location of all types of resources. All providers are required to provide information to a registrar that uniquely identifies it in the network and describes the type of information or service that it provides. Registrars maintain a map of resources amongst one another so consumers have a means of discovery for specific resources and the available providers. The Game Network: A network of loosely-coupled resources that collectively represent all functionality, services and information for a specific game application. The state of the game is the collective state of the individual resources for any point in time. Multiple resources exist that duplicate the same information or service. Resources can discover and locate one another through a specific resource called the Registrar. These resources can then actively communicate with one another and dynamically determine the most available and reliable resources from their unique view of the network based on a measurable trust relationship. Scalability is dynamically increased as more redundant resources are introduced to the network, are discovered by other consumers, and rise in trust value. Similarly, the game network is extended in functionality by the introduction of new types of resources. The Game: An application that consists of a dynamic collection of unique resources provided by the game network. The specific resources that make up a game for an end-user can change at any time but must always provide the most reliable and most available services and information. The switching of resources must be transparent to the user. At all times the user’s view and experience of the game must be consistent and not interrupted by the switching of resources. An ExampleSuppose we have a typical massive, multi-player, online, role-playing game (MMORPG). We can define the features and functionality of this game as a set of unique resources (Diagram1):
With this simple set of resources, we have a representation of the majority of functionality found in today’s MMORPGs. In order for a player to enter the game, she must locate providers of these five resources. (This will require, of course, Registrar resources, as described above.) As with other MMORPGs, we quickly realize that we must handle thousands of players, if not more. Thus, the Game Network needs to include more redundant providers in the Player System. As players come online, they will locate an available provider from the Registrar. Scaling the network to meet the demand of even more players simply requires the addition of more providers. Similarly, the other resources must scale as demand increases. However, for simple resources, providers that also serve other, more complex resources may manage this. The Time System is a good example of this. All resources, including the Player System that represents the users themselves, can be providers of the global clock. This is a design consideration to allow the other resources a more reliable means to synchronize state amongst each other. As a user interacts with the game application (or, rather, as the player plays the game), the supporting systems may change according to the user’s unique view of the network at specific moments in time. Indeed, the game itself may add new features and functionality as the user’s game progresses. This is perhaps the greatest feature of distributed gaming: the ability to scale and simultaneously evolve without disturbing game play. As more resources are introduced to the game, the better the game becomes.
|
|
