PeertoPeer Support for Massively Multiplayer Games

1
Peer-to-Peer Support for Massively Multiplayer
Games
2
Introduction

• Drawbacks of Client/Server Model
• Lacks flexibility
• Server to be over-provisioned
• Limits deployment of user-designed games
• P2P Overlays
• Self-organizing
• Games utilize memory CPU of peers
• Problems
• Performance
• Availability
• Security

3
P2P Online MMG

• P2P Game architecture based on locality of
  interest
• Player focuses on a single region at any time
• Examples EverQuest, World of Warcraft, Sims
  Online, Second Life
• Game States
• Players (avatars), objects, map/terrain
• Existing System Client/Server Architecture
• Latency effect on player performance

4
P2P Infrastructures

• Generally provide scalable distributable hash
  table
• Systems balance hosting/query load
• Pastry
• Implements the hash table
• Routes message in log2bN
• Each node maintains leaf set l nodes
  numerically closest to local node
• Scribe
• Multicast infrastructure on Pastry
• Union of routes from node to groups root gives
  multicast tree

5
Distributed Game Design

• Store transient information on peers
• Store persistent information on main servers
• Partition Game world
• Interest Management
• Partition world into regions limited by how much
  a player can see
• Limit communication of object to players in its
  region
• Game State Consistency
• Player state Send updates on player position
  Multicast, Dead reckoning
• Object State Coordinator-based updates
• Map Generally static

6
Distributed Game with P2P Overlay

• Mapping Game states on to peers
• Region contains players, objects
• Node with id numerically closest to region id is
  coordinator
• Random mapping
• Taking care of handoffs when players leaves or
  joins game
• Fault Tolerance Need to be more failure
  resilient
• Game state to be replicated to improve
  availability
• Assumptions
• Node failures are independent
• Failure frequency is low
• Messages will be routed to correct node

7
Distributed Game with P2P Overlay

• Shared State Replication
• Assumes fail-stop failures detection using
  regular game events
• Property of P2P comm systems route messages
  with key K to the node whose ID N is closest to K
• Replica Next numerically closest node M after
  coordinator
• Leaf set is automatically updated if M fails
• Updating new coordinator
• Window exists when consistency is lost failure
  detection replication time
• Used P2P file system for session times
• CAP Conjecture A Distributed system can have
  any of two of Consistency, Availability,
  tolerance of n/w Partitions

8
Implementation Details

• SimMud on top of FreePastry
• Maps objects
• Region by 2-D array
• Object array
• Player object current position states
• Inter-player interaction
• Object Updates
• Reduce message round trips between players
  coordinator

9
Results

• Only of networking load
• Analyze effects of
• Total Population
• Group Size
• Network dynamics
• Message aggregations

10
Questions?