We have seen that although a centralized client-server shows significant scalability bottlenecks, game developers have a number of reasons for desiring tight administrative control that such an architecture provides. A natural way to attack the scalability bottleneck (and one which many massively multiplayer RPG games are using [7]) is to replace a server by a centralized cluster of servers, such as that proposed by Shaikh et al. [27]. Such a technique minimizes costs of communication between server nodes, as well as permits aggresive partitioning and load-balancing techniques. We review these approaches later in this section.
In this paper, however, our focus is on a completely distributed deployment scenario. Such a scenario allows arbitrary servers to join together to host the game. There is significant evidence that given appropriate incentives, players are willing to provide resources for popular games. For example, CounterStrike [3], a game originally developed by players themselves, has an estimated 35,000 servers deployed. This uncontrolled deployment might occur in a purely peer-to-peer fashion, distributing game server execution only among the clients that are participating in the game. In this scenario limiting the communication costs incurred by each client is critical because they may not be well provisioned. In addition, it may be difficult for game developers to manage or control game state in such a system because clients may arrive and depart frequently, causing game objects to flow around the system very quickly (or worse, become lost) and limiting the quality of service players can expect.
An alternative form of distributed deployment would be Akamai-like: small groups of servers located throughout the world can join together to host a single instance of a game. Such a deployment has the benefit of utilizing the geographically distributed nature of servers. A cluster can have high latency and low responsiveness to clients that are far away from the cluster, and it still retains a central point of failure. A distributed system, on the other hand, can migrate interacting players intelligently to improve latency and responsiveness. Furthermore, these servers would be much less dynamic than the client machines themselves and are more likely to be well provisioned. Hence, we believe they can be used as a substrate to facilitate stability in a peer-to-peer architecture.
We note that, while a distributed architecture is promising for removing scalability bottlenecks, it makes enforcing security and avoiding cheating more difficult. Solutions to these problems are out-of-scope of this paper.
We now present an overview of previous distributed architectures (cluster-based or otherwise) and discuss their limitations when applied to the aforementioned deployment setting(s).