FreeMMG: A Scalable and Cheat-Resistant Distribution ... - CiteSeerX

FreeMMG: A Scalable and Cheat-Resistant Distribution Model for Internet Games F´abio Reis Cecin, Rodrigo Real, Rafael de Oliveira Jannone, Cl´audio Fernando Resin Geyer Universidade Federal do Rio Grande do Sul Porto Alegre, RS, Brazil {fcecin, rreal, jannone, geyer}@inf.ufrgs.br M´arcio Garcia Martins, Jorge Luis Victo´ ria Barbosa Universidade do Vale do Rio dos Sinos S˜ao Leopoldo, RS, Brazil {marciog, barbosa}@exatas.unisinos.br Abstract State-of-the-art Massively Multiplayer Games such as EverQuest and Ultima Online are currently implemented as client-server systems. Although this approach allows the development of commercially viable MMG services, the costs associated with running a scalable client-server MMG service are often too high for small companies or research projects. This paper proposes FreeMMG, a mixed peer-to-peer and client-server approach to the distribution aspect of MMGs. It is argued that the FreeMMG model supports scalable, cheat-resistant, massively multiplayer realtime strategy (RTS) games using a lightweight server that delegates the bulk of the game simulation to the clients. A working prototype game called FreeMMG Wizards is presented, together with some preliminary scalability test results featuring up to 300 simulated game clients connected to a FreeMMG server. The results show that the measured server traffic can be considered very low if compared with more centralized alternatives.

1. Introduction Interactive multiplayer (or multi-user) games played over the Internet are becoming increasingly popular. A specific subclass of multiplayer games is the scalable multiplayer game or massively multiplayer game (MMG). This kind of game supports great amounts of players interacting in real-time, simultaneously, in a persistent-state virtual world. Examples of MMGs are EverQuest [22] and Ultima Online [18]. Internet-based multiplayer support architectures often

employ some kind of protection against cheating players. In small-scale multiplayer games such as Quake [13] this problem is solved in great part by the adoption of a centralized, client-server simulation model. This solution naturally extended itself into the commercial implementations of their scalable counterparts. Besides being a relatively simple and predictable model, it offers strong protection against a wide range of possible cheats and allows the server entity to retain access control to the game. However, with the increase of the supported number of connected clients from a few tens to a few tens of thousands, it becomes necessary to supply additional processing (CPU) and communication (network) power to the game server-side. To supply this, most commercial MMG implementations today use multiple game servers to serve a single virtual world through employment of some kind of load balancing scheme [10]. These techniques vary from static to dynamic allocation of clients to server clusters or even Grids [6]. Although the MMG server scalability problem can be dealt with powerful hardware, this approach can be restrictive. For one thing, small or independent game studios and research groups often don’t have access to that kind of hardware infrastructure and thus cannot currently employ it. Also, the client-server (or ‘interaction terminal’ to ‘simulator’) game paradigm always results in high communications cost between clients and servers. Since clients cannot be trusted they need to be constantly fed, in real-time, with game updates. This is the case whether the server is a single machine, a cluster, or distributed in a Grid. This paper proposes FreeMMG, a hybrid client-server and peer-to-peer or distributed simulation model for massively multiplayer games that is cheat-resistant and scalable.

It is argued that FreeMMG can be adequate to support realtime strategy games like Age of Empires [24] in a MMG context. It is shown by simulated tests using a prototype game implementation that a FreeMMG server can handle hundreds of clients using very little bandwidth, if compared to a client-server alternative.

2. Supporting Massively Multiplayer Games Real-time and scalable interactive simulation models have recently found an application as support systems for games played over the Internet. These games, which can be played by thousands of players simultaneously, are known as massively multiplayer games (MMGs for short). Examples include EverQuest [22], Ultima Online [18] and PlanetSide [23]. A MMG simulation model intended for realworld usage can be evaluated through certain technical criteria. In the scope of this paper we consider the following as important characteristics to evaluate in a MMG support model. These characteristics are important to distinguish our model (FreeMMG) from previous work.

2.1. Support for game genres A MMG model must support the constraints imposed by specific types of MMG games. There are many different game genres, each presenting different requirements to the underlying support model. One common requirement is the support for real-time interactions for action games. For instance, first-person shooters (Quake [13], PlanetSide [23]) require fast response times for player commands [19]. Roleplaying games (EverQuest [22], Ultima Online [18]), while similar to first-person shooters in many aspects, often tolerate command latency or temporary inconsistencies better. And finally, real-time strategy games (Age of Empires II [24]) can tolerate rather large command latencies [4] but, in turn, requires support for updating each game client on hundreds of dynamic game objects at each ‘tick’ of the simulation clock (common when players command ‘armies’ of game objects instead of single characters).

2.2. Support seamless presentation of virtual worlds A ‘virtual world’ is a simulation with a persistent state that supports interaction between any two of its participants. Although a single MMG virtual world is often implemented as a collection of distributed simulators, in general these simulators synchronize with each other, thus allowing any two participants of one ‘virtual world’ to eventually meet and interact. When players attempt to interact, the less the seams imposed by the underlying distribution architecture are visible to these players, the better. Of course, if one finds viable game designs that explicitly place visible seams

between the players, then these seams can and should be exploited by the distribution model. Guild Wars [2] focuses on providing a large, seamless virtual world where players talk and organize for smaller-scale, isolated battles. In this scenario, the isolated battles could be seen as isolated virtual worlds, however, this is isolation is an explicit feature of the game’s design, and the entering and leaving of these isolated areas is very integrated into the game as well. So this game could be considered as providing a seamless presentation of its virtual world to the players.

2.3. Support for cheat-proof or cheat-resistant games Cheating is rampant in online games played over the Internet [10]. A MMG simulation model is not adequate for supporting real-world deployments if it doesn’t explicitly address the issue of cheating players. This is probably one of the main reasons why most of the current commercial MMGs are based on strongly centralized client-server architectures. These architectures are mostly cheat-proof: having no direct access to the machines running the actual simulation, potential cheaters are limited to exploiting vulnerabilities in the game’s wire protocol. On the other hand, distributed or peer-to-peer simulation models often delegate the simulation state, and the task of updating it, to the client machines or other anonymous entities. Since the nodes running the simulation cannot be trusted, the development of cheat-proof decentralized models turns out to be a significantly harder problem than cheat-proofing centralized ones. In this paper we consider the existence of cheat-resistant simulation models for MMGs, where it is theoretically possible for a player or a group of players to cheat (for instance, by directly altering the state of the delegated virtual world) but the model offers explicit mechanisms that reduces the chances of cheating attempts being successful.

3. Related Work Butterfly Grid: Successful client-server MMGs such as EverQuest and Ultima Online need multiple servers to handle the simulation load. However, the amount of actual processing power needed by a MMG may vary with time. As such, it is possible that a MMG provider may superestimate this amount, resulting in idle hardware, or may underestimate it, resulting in players being left out of the game. The Butterfly Grid [6] attempts to eliminate this problem (and others) by proposing on-demand allocation of servers from a pool of available servers in a Grid computing environment. These servers could be owned by Internet access providers and, in an ideal scenario, game servers would be allocated to serve the players connected to the same Internet provider. To the best of our knowledge, the Butterfly Grid

supports at least the more traditional [17] MMG genres such as MMORPGs, supporting seamless and cheat-proof virtual worlds. Although the Butterfly Grid offers a scalable service, it still depends on the availability of a complex and dedicated hardware infrastructure to work. It needs reliable, highbandwidth and low-latency connections available between the servers and several high-quality servers located in secure environments readily available to be scheduled by the Grid. Scalable Publisher-Subscriber models: The basic idea of decentralized, distributed or peer-to-peer scalable MMG architectures is to let the clients themselves run all the simulation, without the need for mediation by a reliable, trusted ‘server’ entity. Both Mercury [5] and Fiedler et al’s Communication Architecture for Massively Multiplayer Games [11] are scalable, decentralized multiplayer architectures based on the publisher-subscriber model. Both works address the problem of scalability by splitting the game world into smaller pieces that can be individually subscribed to, and both works address the issues of responsiveness to player commands. Mercury emphasizes the runtime robustness of the architecture (eliminating the server, which is a central point of failure). Fiedler et al assert that there are gains by dividing the game world not only geographically, but also subdividing each piece of the ‘virtual land’ in channels such as the environmental channel (low bandwidth messages such as map data) and the interaction channel (high bandwidth messages such as player updates). Both works don’t explicitly address the issues that arise from cheating players, which, as discussed before, are a decisive factor when considering a real-world usage scenario for massively multiplayer games. Small-scale Peer-to-Peer Replicated Simulation: We chose this arbitrary name, ‘Peer-to-Peer Replicated Simulation’, for the technique presented by Bettner and Terrano [4] that was implemented in the real-time strategy game Age of Empires [24]. In Replicated Simulation, each player keeps a full copy of the game’s state that must always be in synchrony with all the other player’s copies. Messages are exchanged in rounds or turns of fixed length (typically, from 50ms to 200ms duration). Simulation occurs in lock step. In each turn, the game client samples its local input devices and sends to all the other clients a ‘command’ packet that contains basically a set of input events accumulated since the last ‘command’ packet was dispatched. After a client receives all the command packets that were time-stamped for a given turn T, it can update its copy of the state from turn T to turn T+1 and render the new state of the world for the player. To cope with network delay, commands sampled locally at turn T are scheduled for execution in a future turn by all players (in Age of Empires the execution is scheduled for turn T+2 [4]). This turns the lock-step protocol, which

is not an optimistic protocol, feasible for a real-time strategy game, where having a 200ms to 400ms delay between ordering some virtual objects to move and the objects actually starting to move is more acceptable than experiencing heavy fluctuations in lag. Although this technique is proven for small-scale real-time strategy games, it is not scalable for a massively multiplayer game, since it is impossible for a client machine to simulate the entire virtual world and to afford to communicate in real-time with every other player.

4. The FreeMMG model This section describes the FreeMMG model, an alternative to the purely centralized, client-server MMG architectures. A top-level view of the model shows that it is based on client-server (Figure 1), however there are major differences. The FreeMMG server is the entity responsible for player authentication, player session tracking, management of player’s areas of interest and storage of backup copies of the virtual world, but it is not responsible for running the actual real-time, game world simulation. The server’s primary role is just that of an arbiter and keeper of highly sensitive data, such as player usernames and passwords, which are extremely difficult to distribute in a secure manner in an untrusted network such as the Internet.

Figure 1. A top-level view of the FreeMMG architecture. The real-time, game simulation protocol is executed only by the clients, using the ‘Peer-to-Peer Replicated Simulation’ technique discussed in the previous section, which allows a player to command not only an avatar, but large groups of dynamic objects while requiring practically the same bandwidth. To scale this technique to a massively multiplayer game the virtual world is split into segments. This allows that each game client only subscribes to those

segments it is interested in, similar to most publishersubscriber and tile-based (or cell-based) MMG architectures [7, 11, 16]. In FreeMMG, the client’s area of interest is determined by the server, which keeps, for each game world segment, a list of the players that have at least one of their avatars or game objects present in that segment. Each game client will dynamically subscribe to the segments it becomes interested in.

Figure 2. Transferring objects between segments. FreeMMG’s virtual world segmentation warrants scalability to Replicated Simulation, but it creates the problem of supporting interaction between game objects that are hosted in different segments, since each segment is essentially an independent simulation running with its own simulation clock. The ideal tile-based MMG architecture is transparent: all game objects always interact smoothly with all other game objects, regardless of the underlying world tiling scheme. In FreeMMG objects in different segments don’t interact directly, although there is support for transferring game objects between segments (Figure 2), which is more of an essential feature. When a game object reaches the edge of a world segment, all the clients that are subscribing to that segment will send a message to the server requesting that the object is transferred to a given target segment which is adjacent. After collecting the messages, the server will then carry out the operation, synchronizing the insertion of the foreign game object in the target segment with their current subscribers. The insertion of a new game object in a segment must be conservatively synchronized amongst all the active subscribers of that segment, much like is already done for the subscriber’s player commands. To keep the game going smoothly to the subscribers of the target segment, the object’s re-insertion in the game must be scheduled to a game turn that is in the ‘future’ of all the subscribers, which causes object movements to visibly lag a bit when they are crossing the barrier between two segments.

4.1. Preventing Cheats with Replication It has been shown that the Replicated Simulation technique, when applied to a small-scale, short-duration multiplayer game, effectively prevents malicious players from randomly altering the state of the game world [4]. This occurs because the cheater has only access to it’s copy of the game world, and since all players have their own copies, by hacking his own copy the cheater will only prejudice himself. Even if only one of the players was honest and all the others were cheating the rules in common accord, the game would just visibly go out of synchrony for the honest player. A successful cheat is meant to go undetected so the cheater can benefit from it in the following game play, and that would not happen in this case. Of course, there are many other ways to cheat in a decentralized game, such as exploiting protocol look-ahead weaknesses and others [3], but having the ability to randomly alter the state of the game world is the one that would have the most disastrous consequences in persistent-world types of games, since it allows cheaters to manufacture any amount of any game object in no time. Unfortunately, the intrinsic protection offered by Replicated Simulation against state altering cheats is not enough for the FreeMMG model described so far. Since FreeMMG’s simulation is divided into segments, it’s easy for the subscribers of one segment to agree into cheating the game update rules while the other players, which are subscribing to other segments, wouldn’t be able to notice it. To reduce the chances of this scenario ever happening, two techniques can be employed in an implementation of FreeMMG. First, the server must enforce a certain minimum number of subscribers to every segment (five, for instance). Segments with too few interested clients can have their subscription quotas filled with game clients that have available resources or even daemon-like game clients that are run by volunteers (like SETI@Home [1] or Freenet [9] clients). And second, groups of players must be prevented from moving to an inactive segment (one with currently no subscribers) and being the only subscribers of that segment. This can be resolved if the server always assigns a minimum amount of ‘random’ game clients (at least one) to each segment. These random clients would not be interested in subscribing those segments (they would not have any game objects owned by them in there), thus reducing the chances that a specific group of malicious players might control all active copies of any segment. In theory, state-altering cheats could be prevented altogether in FreeMMG if at least one of the random subscribers in each segment could be trusted. If these subscribers are hosted on the server-side, for instance, then they can be trusted. This approach would be similar to Pellegrino et al’s Peer-to-Peer with Central Arbiter (PP-CA)

model [20] which uses a trusted node to maintain the consistency in a small-scale, distributed and optimistic simulation. However, with trusted server-side subscribers the FreeMMG server-side would no longer be freed from the task of simulating the virtual world and constantly communicating with the clients in real-time.

4.2. Dealing with Client Failures A client can fail for a number of reasons. It can fail because a subscription got out-of-sync as a result of a bug or a cheating attempt. Clients can also fail by losing their network connections. In any client failure scenario, the FreeMMG server is responsible for restoring the consistency of the simulations that were subscribed by the failed clients. For illustration purposes, let’s consider the scenario where a single subscriber of a segment is disconnected from the network (Figure 3). The first thing that the server must do is check the segment copies that are in possession of the remaining subscribers. The subscribers send checksums of their stored game states for their most recent simulation turns. If there are enough copies of a recent segment state in possession of the remaining subscribers, the server will upload that state from the subscribers and save it locally as a backup copy. After that, the server may optionally allocate more extra subscribers (to satisfy the requirements on the set of subscribers discussed before) and download the most recent backup copy of the segment to the subscribers that don’t have it. This scenario is shown in Figure 3. A second possible scenario is one where, after a single subscriber fails, the server determines that the remaining copies of the segment’s state cannot be trusted. This can happen because the server never knows for sure if a subscriber failure is due to network problems, or is due to the other subscribers trying to eliminate all the ‘honest’ nodes before attempting to cheat the game state in common accord, for instance. After a failure, if there are less copies of the game state amongst the remaining subscribers than the minimum amount of subscribers allowed for a segment, or if there are not enough copies from random subscribers, then the requirements on subscribers discussed before are not met. In this case, the server will have to allocate additional subscribers and download its current backup copy of the segment’s state to these subscribers. This causes more bandwidth usage and more disruption in game play than the first scenario described before. Therefore, it would be desirable to minimize the need for the server to restore its (old) backup copy. This can be accomplished by setting the default amounts of subscribers that must be allocated for a segment to greater values than the minimum amounts of remaining subscribers acceptable after subscriber failures occur. For instance, if the default amount of random subscribers in a segment is set to two, but

Figure 3. A subscriber fails, and there is enough redundancy.

the minimum amount of random subscribers acceptable after a failure is set to one, and only one of these random subscribers fail, the requirements on subscribers after a failure are still met, and there is no need to restore the old backup copy from the server. Different FreeMMG-based games and applications will be able use different values for these parameters. A deployment of a simple game, where client and server resources are modest and where there isn’t much concern about cheating could maybe benefit even from using the lowest security parameters: no minimum amount of subscribers, and no use of random or trusted subscribers. These parameters are used in the current implementation of FreeMMG Wizards, the prototype game that is presented in Section 5.

4.3. Failures: Maintaining Global Consistency In a distributed simulation, if the simulation clock of any simulator is allowed to step back for any reason (for instance, due to rollbacks in optimistic synchronization algorithms), then there is a problem of maintaining the global consistency of the simulation [12]. In a FreeMMG simulation, if an object O is transferred from source segment S in local simulation time ST2 to destination segment D, and later segment S suffers from subscriber failures and is restored by the server to a state which is time-stamped ST1, then that transfer of object O must be undone if ST2 > ST1 (Figure 4). The specification of a distributed consistency algorithm

for undoing object transfers in FreeMMG is a work-inprogress. Our hypothesis is that finding a suitable algorithm for this task will not prove to be a showstopper problem for two reasons. First, the Replicated Simulation protocol is not optimistic. Therefore, state rollbacks in an individual segment simulation will only occur in the event of client failures, which should be in a different order of magnitude than the occurrence of wrong extrapolations in optimistic simulations, for instance. And second, even if malicious clients start to trigger failures in order to attack the system, those clients could be identified by heuristics if they are frequently involved in segment subscriptions that fail, as discussed in previous work [8]. Those clients could then be suspended or banned from the game, allowing the system to purge itself of problematic clients. This is an important feature for FreeMMG, even if a very efficient consistency algorithm is eventually developed.

the Swing toolkit for graphics. The game protocol is currently built on top of TCP/IP, which provides the needed message ordering, and guaranteed delivery. Data persistence at the server-side is achieved by using Prevayler 1.02 [21]. Further implementation details of FreeMMG Wizards have been presented in previous work [8].

5.1. Game description FreeMMG Wizards is an attempt to model a very simple real-time strategy game that takes place in a persistent world. In Wizards, each player is assigned a unique avatar that represents a ‘wizard’. Every wizard has its own custom attributes and becomes more powerful as the player devotes more hours to the game like in any conventional MMORPG. The difference is that a wizard can use its magical powers to create ‘monsters’ and other units for the player. Thus, a player could eventually summon very large amounts of monsters, which would then be used to destroy the wizards and monsters of the other players. Since the game is persistent, both the player’s wizard and the player’s army of monsters are preserved between game sessions. A screen-shot of the game is presented in Figure 5. Wizards are represented as ellipses, and monsters are drawn as rectangles. The game play area of the interface shows three bright rectangles populated with units, which are segments subscribed by the game client in question, and one empty black rectangle, which is not subscribed because it is not on that player’s area of interest. In this example, the virtual world is divided in very small segments for didactic and testing purposes. In a real game, however, the default segment size can be expected to be the size of an average ‘game map’ of a real-time strategy game such as Age of Empires II [24].

Figure 4. Global consistency problem.

5. Prototype: FreeMMG Wizards The implementation of a general MMG development framework, based on the FreeMMG model, is a work in progress. As a proof-of-concept, we have implemented a simple real-time strategy game using the FreeMMG model, called FreeMMG Wizards. It is implemented in Java J2SE 1.4 edition, using Java’s sockets and threads support, and

Figure 5. A screen-shot of FreeMMG Wizards.

5.2. Scalability tests

10

30

50 Clients 100 Clients 150 Clients 200 Clients 300 Clients

25

KBytes/s

20

15

10

5

0

0

10

20

30

40

50

60

Time

Figure 6. Server-side traffic, varying amount of clients and total execution time.

8

KBytes/s

We developed a batch client simulator in order to provide an initial evaluation of FreeMMG’s potential scalability. The client simulator runs a configurable number of simple simulated clients, each in its own thread. Each client connects to a given FreeMMG server, creates a new user account and asks to enter the game, which causes the client to subscribe to the segment where its wizard is created. All the tests used a world side of 5x5 segments. The following experiments involved two Linux computers running kernel 2.6.5. One of them was responsible for running the FreeMMG server, and the other was responsible for running the clients. With this configuration we executed simulations with durations of 5, 10, 20, 30 and 60 minutes. For each duration we made simulations with 50, 100, 150, 200 and 300 clients. Figure 6 shows server-side traffic varying experiment duration and total number of clients. We can observe that in the low duration simulations the communication rates are higher and, in the long duration ones, the rates are lower and tend to keep an average value. This occurs because there is a setup communication in the beginning of the execution, after that the communications are reduced since the simulated clients run the peer-to-peer simulation mostly independently from the server. The average server-side traffic is presented in Figure 7. In this graphic we considered only the data from 30 and 60 minutes durations, when the communications were stable. We did this to avoid the bad influence of the simulations with lower durations. This figure shows that the increasing of the communications rate stayed lower than linear growth, so the inclusion of more clients did not lead to a network scalability problem at the FreeMMG server.

Average

6

4

2

0

0

50

100

150

200

250

300

Clients

Figure 7. Server-side traffic, varying total amount of clients.

6. Conclusions and Future Work Currently, the massively multiplayer games market is of very difficult access for small start-up and independent game companies [14]. We believe that part of this phenomenon is due to the cost associated with running a resource-intensive service provider such as a MMG server [15]. In a research or educational context it is also difficult to find platforms or frameworks for experimental MMG projects that can run from low-cost servers. This paper presented an overview of the FreeMMG model, a hybrid client-server and peer-to-peer approach for the distribution aspect of massively multiplayer games which attempts to contribute to fill that gap. In contrast to the traditional, pure client-server MMG architectures which are used in most MMORPGs products today, FreeMMG alleviates the server-side resource bottleneck by delegating the bulk of the simulation load to the game clients, while retaining control over sensitive data such as player accounts and backup copies of the virtual world’s state. In respect to the criteria discussed in Section 2 and in the light of the initial test results discussed in section 5.2, we evaluate the support for MMGs offered by FreeMMG as follows: Game genre support: FreeMMG supports real-time strategy games in a scalable context, which is a genre difficult to support by client-server models, but it currently does not seem to support action games with very strong real-time requirements such as first-person shooters, which are easy to provide with client-server. Virtual world support: a FreeMMG simulation can be persistent and considered as providing a virtual world that connects its participants in real-time. Currently, the global consistency algorithm is missing in the model and its spec-

ification a current work in progress. Also, the impact on game play caused by FreeMMG’s non-transparent virtual world segmentation is yet to be determined. Addressing cheats: FreeMMG is cheat-resistant. Although state-altering cheats are possible, there are configurable mechanisms that can allocate more or less resources (more or less state replication in the client machines) to reduce the probability of these cheats being successfully executed, as discussed in Section 4.1. We conclude that FreeMMG may become an interesting alternative for experimental or research projects in the context of the Massively Multiplayer Online Real-Time Strategy (MMORTS) game genre. The current FreeMMG model can be improved in a number of ways. One important improvement would be the specification of a multi-server architecture for FreeMMG, since the current model only supports a single centralized server. Another wanted improvement is the replacement of the current virtual world tiling scheme with a more seamless approach that would allow game objects hosted in different segments to interact directly, in a more transparent fashion. Specification and development of the FreeMMG framework, a reusable MMG networking engine based on the FreeMMG model and its current prototype implementation (FreeMMG Wizards) is currently a work in progress.

Acknowlegments The development of this work was supported by the National Council of Scientific and Technological Development (CNPq), a brazillian research agency, by the MCT/CT-Info 2004 grant.

References [1] D. P. Anderson, J. Cobb, E. Korpela, M. Lebofsky, and D. Werthimer. Seti@home: An experiment in publicresource computing. In Communications of the ACM, 45(17), nov. ACM Press, 2002. [2] ArenaNet. Guild wars, 2004. http://www.guildwars.com/. [3] N. E. Baughman and B. N. Levine. Cheat-proof playout for centralized and distributed online games. IEEE Infocom, 2001. [4] P. Bettner and M. Terrano. 1500 archers on a 28.8: Network programming in age of empires and beyond. Game Developer’s Conference, 2001. http://www.gamasutra.com/features/20010322/terrano 01 .htm. [5] A. R. Bharambe, S. Rao, and S. Seshan. Mercury: A scalable publish-subscribe system for internet games. In Proceedings of the first workshop on Network and system support for games. ACM Press, 2002. [6] Butterfly.net. Powering next-generation gaming with computing on-demand. White Paper, 2003. http://www.butterfly.net/platform/technology/idc.pdf.

[7] W. Cai, P. Xavier, S. J. Turner, and B. Lee. A scalable architecture for supporting interactive games on the internet. In Proceedings of the 16th Workshop on Parallel and Distributed Simulation. IEEE Press, 2002. [8] F. R. Cecin, J. L. V. Barbosa, and C. F. R. Geyer. Freemmg: An hybrid peer-to-peer, client-server, and distributed massively multiplayer game simulation model. In Proceedings of the 2nd Brazilian Workshop on Games and Digital Entertainment (WJogos’03), November 2003. [9] I. Clarke. Protecting free expression online with freenet. IEEE Internet Computing, 2002. [10] I. J. Cunnin. Load balancing schemes for distributed realtime interactive simulations. Master’s thesis, University of Waterloo, Ontario, Canada, 2000. [11] S. Fiedler, M. Wallner, and M. Weber. A communications architecture for massive multiplayer games. In Proceedings of the first workshop on Network and system support for games. ACM Press, 2002. [12] R. M. Fujimoto. Parallel and distributed simulation systems. New York: John Wiley, 2000. [13] id Software. Quake, 2003. http://www.idsoftware.com/. [14] IGDA. Igda online games white paper, 2003. http://www.igda.org/online/online whitepaper.php. [15] S. L. Kent. Making an mmog for the masses, 2004. http://www.gamespy.com/amdmmog/week3/. [16] B. Knutsson, H. Lu, W. Xu, and B. Hopkins. Peer-to-peer support for massively multiplayer games. IEEE Infocom, 2004. [17] MMOWORLDS.COM. Games list, 2003. http://www.mmoworlds.com/index.php?page=liste jeux. [18] Origin. Ultima online, 2003. http://www.owo.com/. [19] L. Pantel and L. Wolf. On the impact of delay on real-time multiplayer games. In The 12th International Workshop on Network and Operating Systems Support for Digital Audio and Video. ACM Press, 2002. [20] J. D. Pellegrino and C. Dovrolis. Bandwidth requirement and state consistency in three multiplayer game architectures. In Proceedings of the 2nd workshop on Network and system support for games, pages 52–59. ACM Press, 2003. [21] Prevayler.org. Prevayler, 2004. http://www.prevayler.org/. [22] Sony. Everquest, 2003. http://www.everquest.com/. [23] Sony. Planetside, 2004. http://www.planetside.com/. [24] E. Studios. Age of empires 2, 2003. http://microsoft.com/games/age2.