430 likes | 619 Views
Peer-to-Peer Support for Massively Multiplayer Games. Bjorn Knutsson, Honghui Lu, Wei Xu, Bryan Hopkins. Presented by Mohammed Alam (Shahed). Outline. Introduction Overview of MMG Peer-to-Peer Infrastructure Distributed Game Design Game on P2P overlay Experimental Results
E N D
Peer-to-Peer Support for Massively Multiplayer Games Bjorn Knutsson, Honghui Lu, Wei Xu, Bryan Hopkins Presented by Mohammed Alam (Shahed)
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
Introduction • Proposes use of P2P overlays to support Massively multiplayer games (MMG) • Primary contribution of paper: • Architectural (P2P for MMG) • Evaluative
Introduction MMG GAME SCRIBE (Multicast support) PASTRY (P2P overlay)
Introduction • Players contribute memory, CPU cycles and bandwidth for shared game state • Three potential problems: • Performance • Availability • security
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
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
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
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
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
Overview of MMG • Latency • Varies • Guiding ‘avatars’ tolerates more latency • First person shooter games (180 millisecond latency max) • Real time strategy (several seconds)
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
Peer-to-Peer Infrastructure MMG GAME SCRIBE (Multicast support) PASTRY (P2P overlay)
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
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
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
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
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
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
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
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
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
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)
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
Game on P2P overlay • Catastrophic failure • Both coordinator and replica dead • Problem solved by cached information from nodes interested in area
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
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
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
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
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
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
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
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
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
Outline • Introduction • Overview of MMG • Peer-to-Peer Infrastructure • Distributed Game Design • Game on P2P overlay • Experimental Results • Future Work and Discussion
Future Work • Assumes uniform latency for now • Testing games with more states and on global distributed network platforms • Stop cheating by detection
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?