Peer-to-Peer Support for Massively Multiplayer Games

1. Peer-to-Peer Support for Massively Multiplayer Games Bjorn Knutsson, Honghui Lu, Wei Xu, Bryan Hopkins Presented by Mohammed Alam (Shahed)

2. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

3. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

4. Introduction • Proposes use of P2P overlays to support Massively multiplayer games (MMG) • Primary contribution of paper: • Architectural (P2P for MMG) • Evaluative

5. Introduction MMG GAME SCRIBE (Multicast support) PASTRY (P2P overlay)

6. Introduction • Players contribute memory, CPU cycles and bandwidth for shared game state • Three potential problems: • Performance • Availability • security

7. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

8. Overview of MMG • Thousands of players co-exist in same game world • Most MMG’s are role playing games (RPG) or real-time strategy(RTS) or hybrids • Examples: Everquest, Ultima online, Sims online

9. Overview of MMG • GAME STATES World made up of • immutable landscape information (terrain) • Characters controlled by players • Mutable objects (food, tools, weapons) • Non-player characters (NPCs) controlled by automated algorithms

10. Overview of MMG • GAME STATES (contd..) • Game world divided into connected regions • Regions on different servers • Regions further divided to keep data in memory small

11. Overview of MMG • EXISTING SYSTEM SUPPORT • Client-server architecture • Server responsible for • Maintain & disseminate game state • Account management & authentication • Scalability achieved by • Dedicated servers • Clustering servers • LAN or computing grid

12. Overview of MMG • Latency • Varies • Guiding ‘avatars’ tolerates more latency • First person shooter games (180 millisecond latency max) • Real time strategy (several seconds)

13. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

14. Peer-to-Peer Infrastructure MMG GAME SCRIBE (Multicast support) PASTRY (P2P overlay)

15. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

16. Distributed Game Design

17. Distributed Game Design • Persistent user state is centralized • Example: payment information, character • Allows central server to delegate bandwidth and process intensive game state to peers

18. Distributed Game Design • Game design based on fact that: • Players have limited movement speed • Limited sensing capability • Hence data shows temporal and spatial localities • Use Interest Management • Limit amount of state player has access to

19. Distributed Game Design • Players in same region form interest group • State updates relevant to group disseminated only within group • Player changes group when going from region to region

20. Distributed Game Design • GAME STATE CONSISTENCY • Must be consistent among players in a region • Basic approach: employ coordinators to resolve update conflicts • Split game state management into three classes to handle update conflicts: • Player state • Object state • The Map

21. Distributed Game Design • Player state • Single writer multiple reader • Player-player interaction effects only the 2 players involved • Position change is most common event • Use best effort multicast to players in same region • Use dead reckoning to handle loss or delay

22. Distributed Game Design • Object state • Use coordinator-based mechanism for shared objects • Each object assigned a coordinator • Coordinator resolves conflicting updates and keeps current value

23. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

24. Game on P2P overlay • Map game states to players • Group players & objects by region • Map regions to peers using pastry Key • Each region is assigned ID • Live Node with closest ID becomes coordinator • Random Mapping reduces chance of coordinator becoming member of region (reduces cheating) • Currently all objects in region coordinated by one Node • Could assign coordinator for each object

25. Game on P2P overlay • Shared state replication • Lightweight primary- backup to handle failures • Failure detected using regular game events • Dynamically replicate coordinator when failure detected • Keep at least one replica at all times • Uses property of P2P (route message with key K to node ID, N , closest to K)

26. Game on P2P overlay • Shared state replication (contd..) • The replica kept at M which is the next closest to message or object K • If new node added which is closer to message K than coordinator • Forwards to coordinator • Updates itself • Takes over as coordinator

27. Game on P2P overlay • Catastrophic failure • Both coordinator and replica dead • Problem solved by cached information from nodes interested in area

28. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

29. Experimental Results • Prototype Implementation of “SimMud” • Used FreePastry (open source) • Maximum simulation size constrained by memory to 4000 virtual nodes • Players eat and fight every 20 seconds • Remain in a region for 40 seconds • Position updates every 150 millisec by multicast

30. Experimental Results • Base Results • No players join or leave • 300 seconds of game play • Average 10 players per region • Link between nodes have random delay of 3-100 ms to simulate network delay

31. Experimental Results(Base results)

32. Experimental Results(Base results) • 1000 to 4000 players with 100 to 400 regions • Each node receives 50 –120 messages • 70 update messages per second • 10 players * 7 position updates • Unicast and multicast message take around 6 hops

33. Experimental Results(Base results)

34. Experimental Results • Breakdown of type of messages • 99% messages are position updates • Region changes take most bandwidth • Message rate of object updates higher than player-player updates • Object updates multicast to region • Object update sent to replica • Player player interaction effects only players

35. Experimental Results • Effect of Population Growth • As long as average density remains same, population growth does not make difference • Effect of Population Density • Ran with 1000 players , 25 regions • Position updates increases linearly per node • Non – uniform player distribution hurts performance

36. Experimental Results • Three ways to deal with population density problem • Allow max number of players in region • Different regions have different size • System dynamically repartitions regions with increasing players

37. Experimental Results • Effect of message aggregation • Since updates are multicast, aggregate them at root • Position update aggregated from all players before transmit • Cuts bandwidth requirement by half • Nodes receive less messages

38. Experimental Results

39. Experimental Results

40. Experimental Results • Effect of network dynamics • Nodes join and depart at regular intervals • Simulate one random node join and depart per second • Per-node failure rate of 0.06 per minute • Average session length of 16.7 minutes (close to 18 minutes for half life) • Average message rate increased from 24.12 to 24.52 • Catastrophic failure every 20 hours

41. Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion

42. Future Work • Assumes uniform latency for now • Testing games with more states and on global distributed network platforms • Stop cheating by detection

43. Discussion • Assigning random coordinators could hurt in P2P (modem vs high-speed) • How close can the results obtained in simulation on one machine work in real • Given range of 7.2kB/sec – 22.34 KB/sec in easy game. What about games with more states • How would aggregating messages be bad? • In their case waits for all messages to come before sending? Latency issues?