View
219
Download
0
Tags:
Embed Size (px)
Citation preview
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
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 STATESWorld 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
15
Outline
• Introduction
• Overview of MMG
• Peer-to-Peer Infrastructure
• Distributed Game Design
• Game on P2P overlay
• Experimental Results
• Future Work and Discussion
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
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
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
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?