Design Issues for Peer-to-Peer Massively Multiplayer Online Games

(1)

Design Issues for Peer-to-Peer

Massively Multiplayer Online Games

MMVE’09

Lu Fan

, Phil Trinder, and Hamish Taylor

Heriot-Watt University, Edinburgh, UK

(2)

Overview

_Background

_{Design Issues for P2P MMOGs}

_{Interest Management}

_{Event Dissemination}

_{NPC Host Allocation}

_{State Persistency}

_{Cheating Mitigation}

_Incentives

_{Classification of P2P MMOG Designs}

_Discussion

(3)

Background

_{Conventional MMOG architectures}

_{Client/Server, e.g.}

_{Sony’s EverQuest 2}

_{Blizzard’s World of Warcraft}

_{Middleware & Service Platforms, e.g.}

_{IBM’s Butterfly Grid}

_{Sun’s Game Server technology}

_{In nature}

_{Either dedicated game servers} _{Or shared game server clusters}

(4)

Background

_{C/S or Middleware}

_Advantages

_{Relatively easy to implement} _{Relatively easy to secure}

_{Disadvantages}

_{Reliability – single failure points} _Cost

_{Server hardware} _{Network bandwidth} _{Housing & Cooling} _{Electricity & UPS} _{Maintenance staff}

(5)

Background

_{Engineering Peer-to-Peer MMOGs}

Game server functions:

• Managing players’ positions

• Processing game events

• Controlling NPCs

• Maintaining the game world

• Security reinforcement

• Accounting

P2P MMOG design issues:

• Interest Management • Event Dissemination • NPC Host Allocation • State Persistency • Cheating Mitigation • Incentives

(6)

Design Issues 1: Interest Management

_{Objective: avoid broadcasting game events to all players}

_Approaches:

_{Spatial models}

_{Players communicate with nearby objects}

_{Objects outside a player’s vicinity are ignored} _{E.g. Voronoi ’04, Scalable & Low Delay ’05}

_{Region-based models}

_{A game world is partitioned into multiple regions}

_{A player subscribes to all game events from appropriate regions} _{E.g. Distributed ’04, IM Middleware ’05}

_{Hybrid models}

_{Partition the game world into regions}

_{Select a super-peer in each region to facilitate a spatial model} _{E.g. MOPAR ’05, Meta-Model ’06}

(7)

Design Issues 1: Interest Management

_{IM Discussion}

_{Spatial Models}

_{Advantages: fine-grained}

_{Drawbacks: communication overhead may be high} _{Suitable for unicast}

_{Region-based Models}

_{Advantages: simple, bandwidth efficient} _{Drawbacks: coarse-grained}

_{Suitable for multicast}

_{Hybrid Models}

_{Combines the first two approaches}

(8)

Design Issues 2: Event Dissemination

_Objective:

_{deliver game events quickly and efficiently}

_Approaches:

_Unicast

_{A player distributes game events to all recipients directly} _{E.g. Voronoi ’04, Scalable & Low Delay ’05}

_{Application-Level Multicast (ALM)}

_{A player distributes game events to a small number of forwarders} _{Forwarders relay events to other peers recursively}

_{E.g. P2P Support ’04, P2P Architecture ’06}

_{Locality-aware ALM}

_{Players in the vicinity are used as forwarders} _{Players closer to the source receive events faster} _{E.g. N-Tree ’05, pSense ‘08}

(9)

Design Issues 2: Event Dissemination

_{Event Dissemination Discussion}

_Unicast

_{Advantages: lower communication latency} _{Drawbacks: consumes more bandwidth}

_{Can be ameliorated by using fine-grained IM}

_{General ALM}

_{Advantages: bandwidth efficient}

_{Drawbacks: typically induce longer latency}

_{Locality-aware ALM}

_{Advantages: bandwidth efficient, exploits tolerance of weak}

synchronisation

(10)

Design Issues 3: NPC Host Allocation

_Objective:

_{host non-player characters (NPCs) on peers}

_Approaches:

_Region-based

_{Game world is partitioned into regions}

_{Each region selects a super-peer to host all NPCs} _{E.g. Zoned Federation ’04, P2P Support ’04}

_{Virtual-Distance-based}

_{An NPC is hosted by the closest player}

_{E.g. AtoZ ’04, Colysues ’06, Voronoi State ’08}

_{Heterogeneous Task Sharing}

_{Share multiplayer NPCs among ‘nearby’ peers}

_{Resource availability & QoS are considered during task allocation} _{E.g. Deadline-Driven Auctions (DDA) ’09}

(11)

Design Issues 3: NPC Host Allocation

_{NPC Host Allocation Discussion}

_Region-based

_{Early means of NPC hosting}

_{A number of issues: super-peer selection, load-balancing, QoS…}

_{Virtual-Distance-based}

_{Advantages: minimises communication latency & overhead for}

1:1 interactions

_{Drawbacks: QoS for 1:N interactions, NPC host switching}

_{Heterogeneous Task Sharing}

_{Advantages: maximises resource utility, reduces latency for 1:N}

interactions, less NPC host switching

(12)

Design Issues 4: State Persistence

_Objective:

_{store players' profiles between game sessions}

_Approaches:

_{General Storage Infrastructures}

_{Large scale persistent data store utilities}

_{Mostly designed for P2P file sharing application} _{E.g. OceanStore ’00, PAST ’01}

_{Special Persistency Mechanisms}

_{Classify the data to be stored into multiple categories, e.g.}

ephemeral & permanent, deal with each category in separate ways

_{Expedite data read/write with caching mechanisms} _{E.g. Zoned Federation ’04, P2P Architecture ’06}

(13)

Design Issues 4: State Persistence

_{State Persistence Discussion}

_{General Storage Infrastructures}

_{Advantages: well distributed, highly consistent, secure, scalable,}

available, and durable.

_{Drawbacks: high redundancy, slow reading & writing}

_{Special Persistence Mechanisms}

_{Advantages: customised for MMOGs, fast reading & writing} _{Drawbacks: complex, immature, less secure}

(14)

Design Issues 5: Cheating Mitigation

_Objective:

_{prevent cheating, or detect & remedy suspicious}

game sessions

_Approaches:

_{Proactive Mechanisms}

_{Advanced information exposure protocols that prevent unfair knowledge}

acquisition, e.g. Mitigating Information Exposure ’05

_{Advanced event ordering protocols that prevent fixed-delay, suppressed}

update and other cheating, e.g. NEO ’04, SEA ’06, EASES ’08

_{Reactive Mechanisms}

_{Referee-based monitoring & log audit, e.g. LA ’05, Cheat Detection ’06} _{Mutual monitoring among all the players, e.g. FreeMMG ’04, DaCAP ’08} _{Behavioural monitoring for indications of cheating play, e.g. Detection of}

(15)

Design Issues 5: Cheating Mitigation

_{Cheating Mitigation Discussion}

_{Proactive Mechanisms}

_{Advantages: effective and forceful}

_{Drawbacks: applies to specific vulnerabilities, needs to know}

method of exploitation in advance.

_{Reactive Mechanisms}

_{Advantages: broad-spectrum} _{Drawbacks: not so rigorous}

_{Crucial for justifying P2P MMOGs’ practicality}

_{An active research field starting to bear fruit – many}

(16)

Design Issues 6: Incentive Mechanism

_Objective:

_{persuade participants to contribute resources to}

the MMOG

_Approaches:

_{Accounting Systems}

_{Credit –record players historical contribution}

_{Debit – entitle all player to roughly equivalent resources, e.g.}

DCRC ’03, DDA Incentive Model ’09

_{Reputation Systems}

_{Mutual-rating-based trustworthiness aggregation algorithms} _{Anonymous-request-based honesty measurement algorithms} _{e.g. Local Reputation ’07, Proactive Reputation ’08, REPS ‘08}

(17)

Design Issues 6: Incentive Mechanism

_{Incentive Discussion}

_{P2P systems are voluntary resource sharing systems.}

_{Individual concerns vs. collective welfare}

_{Require both:}

_Accounting

_{To quantify resource contribution & consumption} _{To identify selfish participants}

_{To facilitate reciprocity}

_Reputation

_{To evaluate participants’ honesty & dependability} _{To discourage disadvantageous behaviours}

(18)

Classification of P2P MMOG Designs

Complete DCRC PAST Task Sharing Unicast Hybrid [20] Mediator ‘07 Complete REPS Centralised Distance-based Unicast Voronoi [30] VAST ’07 Simple None PAST None ALM Region-based [28] P2P Arch ’06 Moderate None Centralised None Unicast Aura-Nimbus [18] OPeN ’05 Moderate None Distributed Distance-based Unicast Region-based [16] Distributed ’04 Simple None None Region-based ALM Region-based [43] P2P Support ’04 Overall Evaluation Incentive Mechanism State Persistency NPC Host Allocation Event Dissemination Interest Management P2P MMOG Architectures

_{P2P Support ’04}

_{Partitions game world into large regions to apply coarse-grained IM} _{Disseminates game events using Scribe ALM}

_{Hosts all NPCs in a region using a single super-peer} _{No game state persistence}

_{No incentive mechanisms}

(19)

Classification of P2P MMOG Designs

_{Distributed ’04}

☺ _{Partitions game world into small regions & applies a hierarchical IM} ☺ _{Disseminates game events via unicast}

_{Supports a simple distance-based NPC host allocation mechanism} _{Suggests a special game state persistency mechanism}

_{No incentive mechanisms} _{No demonstration application}

(20)

Classification of P2P MMOG Designs

_{OPeN ’05}

☺ _{Supports fine-grained IM using a novel spatial data index service} ☺ _{Disseminates game events via unicast}

_{NPC host allocation is undefined}

_{Stores players’ profiles using a centralised database} _{No incentive mechanisms}

(21)

Classification of P2P MMOG Designs

_{P2P Arch ’06}

_{Partitions game world into large regions to apply coarse-grained IM} _{Disseminates game events using Scribe ALM}

_{No NPC host allocation}

_{Stores players’ data in a distributed way using PAST} _{No incentive mechanism}

(22)

Classification of P2P MMOG Designs

_{VAST ’07}

☺ _{Proposes a remarkable Voronoi assisted fine-grained IM mechanism} ☺ _{Disseminates game events via unicast}

☺ _{Proposes a good distance-based NPC host allocation mechanism} _{Suggests storing players’ data using centralised game servers} ☺ _{Proposes a novel mutual-rating-based reputation system}

(23)

Classification of P2P MMOG Designs

_{Mediator ’07}

☺ _{Adopts a MOPAR-like hybrid IM scheme} ☺ _{Disseminates game events via unicast}

☺ _{Proposes a novel heterogeneous task sharing infrastructure} _{Supports game state persistency with PAST}

☺ _{Supports a native accounting mechanism that is similar to DCRC} ☺ _{Key components & a test-bed application have been implemented}

(24)

Discussion

_Conclusions

_{Classical C/S architectures suffer from various drawbacks}

_{We articulate a set of six design issues for P2P MMOGs}

_{We present design alternatives & discuss their implications}

_{We classify & compare representative P2P MMOG designs}

_{P2P MMOG architecture are improving rapidly}

_{Future Work}

_{To refine the Mediator framework & DDA infrastructure}

_{To evaluate Mediator MMOG prototype}

(25)

Thank you for your attention!

Q & A

Lu Fan [email protected]

Phil Trinder [email protected] Hamish Taylor [email protected]

School of Mathematical and Computer Sciences Heriot-Watt University, Edinburgh, UK