Comp763: Modern Computer Games

1
Cheat-Proof Playout for Centralized and
DistributedOnline GamesNathaniel E.
Baughman Brian Neil Levine

• Irwin Chiu Hau
• Computer Science
• McGill University
• Winter 2004

2
Overview

• Introduction
• Assumptions and Terminology
• Fair Playout
• Cheat-Proof Game Interaction
• Performance Analysis
• Supporting Cell-Based Architecture
• Conclusion

3
Introduction

• Cheating in multiplayer online games
• RTS
• FPS
• Anti-cheat techniques
• Cheat detection techniques

Warcraft 3
source blizzard.com
UT 2003
source unrealtournament.com
4
Overview

• Introduction
• Assumptions and Terminology
• Fair Playout
• Cheat-Proof Game Interaction
• Performance Analysis
• Supporting Cell-Based Architecture
• Conclusion

5
Assumptions

• We grant cheaters the ability to
• read, insert, modify block messages involved with
  the game protocol
• We assume that
• Application Software is readable by user and
  performs its functions as originally intended

6
Assumptions

• Beyond the scope of this paper
• Protecting against attacks on existing
  transport-layer and network-layer protocols
• denial-of-service attacks
• flooding a network
• disrupt service, connection
• cause a login to be refused
• Client modifications
• However, the specific cheat-proof techniques are
  tolerant against these modifications

7
Terminology

• A set of information that describes the game at
  any time is called game state, which is composed
  of entity
• An entity may consist of several in-game objects
  and is controlled by a player
• A player is a person playing a game as well as
  the objects that person controls in the game

8
Game state partitioning
Control
9
Terminology

• Players make decisions
• they decide on events that change their own
  states
• When an interaction occurs, multiple players
  decisions must be resolved by computing the
  resulting state

10
Terminology

• frame
• progression of in-game time
• The simulator computes game state for each frame
• Players take exactly one turn during each frame

11
Architectures

• Multiplayer games are coordinated through either
• Centralized client-server or decentralized
  distributed architectures
• The architectures differ by where
• Game state is maintained
• Which involves
• Effecting changes and coordinating interactions

12
Centralized-Control Client-Server

• Server maintains all the entity states
• Server computes game states based on clients
  inputs
• Clients request for the server to change the
  clients entity state

13
Decentralized-Control Client-Server

• The client informs the server of update decisions
  that have affected its entity state
• The server resolves any interactions between game
  objects and coordinate global game state

14
Distributed

• Serverless or Peer-to-Peer
• Clients are referred as hosts
• Each host
• Maintains its own entity state
• Informs other hosts of decisions
• Resolves any interactions
• without the use of any centralized authority

15
Some Facts

• Distributed games are much more prone to cheating
• Cheats are possible within a client-server game
• Many games are designed around the client-server
  architecture
• which provides some implicit security along with
  centralized control of game state.

16
Overview

• Introduction
• Assumptions and Terminology
• Fair Playout
• Cheat-Proof Game Interaction
• Performance Analysis
• Supporting Cell-Based Architecture
• Conclusion

17
Fair Playout

• A correct playout of real-time interaction means
• that the game is identically perceived by every
  player
• A Fair games is one
• where players see events occurs as would be
  expected by games rules and taken actions
• A player cheats by causing updates that defy
  rules of the games or gain an unfair advantage

18
Irresolvable Interactions

• Dead Reckoning
• Can be used in client-server or distributed
  environments
• Problems
• centralized case
• distributed case

19
Centralized Case

• Interactions are resolved by the server
  uniformly, but unfairly
• Server has authority over game states
• to resolve interactions, so all clients are
  updated with the same resulting view of the world

20
Centralized Case

• Resolving an interaction with Dead Reckoning
• The servers decision may differ from the
  expectation of the dead-reckoned player
• The dead-reckoned player may view the server
  decisions as unfair
• Players true actions were not used by the server
• Due to unreliability and latency of the Internet
• unfairness is not tolerated by game players

21
Distributed Case

• Unfair decisions becomes damaging
• Interactions based on dead-reckon state may
  damage the global state
• The result of resolving an interaction based on
  dead-reckoned state incorrectness of overall
  game state

22
Irresolvable Interactions

• An irresolvable interaction problem results when
• Dead-Reckoning is used
• Interactions are either determined
• unfairly by a server
• potentially incorrectly by a distributed host

23
Suppress-Correct cheat

• Dead-Reckoning
• One security flaw under bucket synchronization is
  what we term the suppress-correct cheat

24
Cheating Under Dead Reckoning

• Under some Dead Reckoning policy
• n buckets are allowed to be dead reckoned
• before the player is considered to have lost
  connection
• With such policy, a cheating player
• can purposely drop n 1 update packets
• uses knowledge of the current game state
• constructs an update packet for the nth bucket
  that provides some advantage

25
Example

• A sluggish player S chase a more agile player A
• S begins pursuit, then drop n 1 updates
• A dead reckons Ss missing state, but cannot
  confirm where S really is
• For the nth bucket, S sends a constructed update
  that places S behind A

26
Example (continued)

• As long as S sends plausible updates every nth
  bucket
• A cannot confirm that S is cheating
• S simply claims to be on a congested and lossy
  network
• This cheat applies both to
• client-server architecture
• distributed architecture

27
Lookahead cheat

• Most RTS (using stop-and-wait protocol)
• Requires interaction resolution at each discrete
  time unit of time, or turn, in game
• Before time advances
• players must stop and wait for others
• players make state change decisions
• players send that decision to each other player
• Another cheating opportunity called lookahead
  cheat
• A cheating player can simply wait until all other
  players have sent their decision

28
Example

• Player B take a lethal shot towards A
• This decision is sent to server
• Normal human reaction is not quick enough to
  defend against this
• Player A s cheating agent will automatically
  raise shields in time

UT 2003 source unrealtournament.com
29
Overview

• Introduction
• Assumptions and Terminology
• Fair Playout
• Cheat-Proof Game Interaction
• Performance Analysis
• Supporting Cell-Based Architecture
• Conclusion

30
Cheat-Proof Game Interaction

• The paper proposes a protocol that prevents
• lookahead cheats
• suppress-correct cheats
• by disallowing Dead-Reckoning
• Called Lockstep Protocol
• stop-and-wait type protocol

31
Lockstep Protocol

• Each player
• makes a decision but do no announce it
• one-way hashes the decision
• sends the encrypted decision
• Once all encrypted decisions have been received
• Players reveal their decision in plain text
• Hosts can easily verify the reveal decision
• by comparing hashes

32
Lockstep Protocol

• Trade-Off
• Performance Penalty
• Minor optimization
• last player can simply reveal its decision
  immediately
• Correct playout is preserved
• All players will run at the speed of slowest
  player

33
Asynchronous Synchronization

• AS is a synchronization technique that
• relaxes the requirements of lockstep
  synchronization by decentralizing the game clock
• guarantees fair playout and correctness
• provides better performance
• Each host
• advances in time asynchronously from other hosts
• enters in lockstep-style mode when interaction is
  required

34
Sphere of Influence

• Each players host keeps track of each other
  players
• advancement in time and space within a
• Sphere Of Influence ( SOI )

base maximum area that may influence or be
influenced on any one turn delta the change in
influence area that may occur in subsequent turns
35
Asynchronous Synchronization Protocol

• For an each game turn t
• A player determines a decision
• A player sends the hashed decision to all players
• Commitments that are one frame past the last
  revealed frame are accepted
• Before revealing its commitment, the local player
  determines which remote players it is waiting for
  within a SOI
• If no other remote host are in wait state, the
  local host reveals its state for this turn t

36
Secret Possessions

• Objects that are not revealed immediately to
  other players
• weapon, key,
• ex think about battleship
• Solution
• Define a promise as a place to store these secret
  possessions
• Promises can be encrypted or hashed

NWN source Bioware
37
Cheat Detection

• Logger Service a trusted, centralized entity
  that
• records promised information to be verified later
• Observer Service a trusted, centralized entity
  that
• receives secret information via secure channels
• verifies it real-time
• Promise Service a trusted, centralized entity
  that
• receives secret and non-secret information

38
Overview

• Introduction
• Assumptions and Terminology
• Fair Playout
• Cheat-Proof Game Interaction
• Performance Analysis
• Supporting Cell-Based Architecture
• Conclusion

39
Performance Analysis

• Xpilot Simulation
• players control ships in 2-D space
• Test
• Run for about 4000 frames of gameplay
• Traces of 10, 18, 30 and 37 players
• Asynchronous Synchronization protocol
• Lockstep protocol

40
Performance Analysis

• One unit of simulator time 10 ms
• Lower cap
• players could not take turns more often than
  every 4 units of the simulation
• Upper cap
• players could not advance in turns more than once
  every 10 units of simulator time
• Simulate a game running at 10 fps

41
Performance Analysis
Distribution of milliseconds stalled between
frames due to lockstep interaction.
42
Performance Analysis
Distribution of milliseconds stalled between
frames due to lockstep interaction.
43
Performance Analysis

• The simulation shows that the performance of AS
  and lockstep protocols degrades slowly
• With the AS protocol
• at least 50 of the turns can be taken without
  delay due to player coordination

44
Overview

• Introduction
• Assumptions and Terminology
• Fair Playout
• Cheat-Proof Game Interaction
• Performance Analysis
• Supporting Cell-Based Architecture
• Conclusion

45
Supporting Cell-Based Architecture

• In order for MMO games to scale
• amount of communications
• processing
• per client must remain low
• Solutions
• Separate multicast addresses or separate servers
• based on geometric position
• Virtual Playing Field may be broken into cells to
  increase scalability

46
Supporting Cell-Based Architecture

• AS couples together nicely with cell-based
  technique while maintaining
• cheat prevention and cheat detection
• A player must perform AS for the players inside
  the same cell

47
Overview

• Introduction
• Assumptions and Terminology
• Fair Playout
• Cheat-Proof Game Interaction
• Performance Analysis
• Supporting Cell-Based Architecture
• Conclusion

48
Conclusion

• Cheat-proof protocols
• Lockstep
• Provides cheat proof and fair playout
• Asynchronous Synchronization
• Improves performance
• Can be used in combination with cell-based
  architecture

49
Questions?