Mitigating Information Exposure to Cheaters in Real-Time Strategy Games Chris Chambers Wu-chang Feng Wu-chi Feng Portland State University Debanjan Saha IBM Research

Outline Background Detecting cheating in Battleship Cheat detection for RTS Evaluation  Information hidden  Bandwidth cost

Background: On-line games Are popular Are cheat-filled Cheating is detrimental to popularity and fun RTS games  Players command virtual armies  Peer-to-peer architecture  Most common cheat: maphacks

Warcraft 3 RTS interface

Related work Baghman, Levine, “Cheat-proof playout for centralized and decentralized online games”  INFOCOM 2001  University of Massachusetts  Cool zero-knowledge proof for if two entities share the same location  Scales exponentially with # of units Buro, “ORTS: A Hack-free RTS Game Environment”  International Computers and Games Conference, 2002  University of Alberta  Proposes client/server RTS architecture

Detecting Battleship cheats Familiar turn-based game When played peer-to-peer, exhibits similar problems to RTS games Fix battleship, then fix RTS games

Battleship Conundrum A knows B’s location 12. A fires and hits3. A cheats, A wins Shoot(1,2) Shoot(2,2) Shoot(3,2) A doesn’t know B’s loc 12. A fires, B lies3. B cheats, A loses Shoot() hit miss Shoot() miss “Just lucky I guess” “Just unlucky I guess”

Securing Battleship Pre-game  Exchange hashes of ship location, secret  Commits players to a specific location without revealing it (bit commitment) In-game  Each move, send (and receive) shot coordinates, and whether opponent’s last shot hit or missed  Opponents can lie about hits/misses here Post-game  Exchange secrets and initial ship location  Verify opponent’s integrity by checking all the evidence of shots vs. replies

Battleship  RTS games Battleship only has one secret per player per ship RTS games use the fog of war rule RTS games have hundreds of secrets, and they change moment to moment  Unit type  Unit placement RTS games are balanced like rock, paper, scissors… knowing opponent’s secrets, it’s easy to win

RTS Secrets Yellow shouldn’t see these enemies Yellow should see these enemies Yellow unit, and its vision radius

RTS Secrets Current RTS network protocol is to exchange mouse clicks and each simulate the other’s game PRO: no one can lie about what units they have CON: each player knows the other player’s mouse clicks! Just like Battleship

Hiding RTS Secrets Key idea: You know opponent’s view  If ( ) is in oppView, send  Else send Hash(,secret) 1. myUnitsViewable 2. or h(,s) 3. myView 1. myUnitsViewable 2. or h(,s) 3. myView

Cheat Detection Protocol Pre-game  Create your secret s  Generate initial game state igs, send h(s,igs) In-game  Each time slice, send (and receive) Your viewable area Either your move m, or, if it’s invisible to him, h(s,m) If one of your units just entered his area, send that unit Post-game  Exchange your secret, initial conditions, and all hidden moves throughout the game  Verify opponent’s integrity by simulating the game rapidly with the (now known) hidden moves

Issues Not all information is concealed  Old way: nothing concealed  New way: know viewable areas  How much information is concealed? Increased network requirements  Old way: bandwidth = number of clicks  New way: bandwidth = ???

Quantifying Information Concealment One general measure of information: Shannon’s uncertainty where x is a random variable with n possible values and p(x) is the probability distribution of x Peak uncertainty (1): values are equally likely Minimum uncertainty (0): values are predicted perfectly

Quantifying Information Concealment Experiment method:  Scatter points randomly on a grid  Calculate uncertainty (small)  Create viewable areas from points  Calculate uncertainty  Graph difference Experiment 1: vary number of units (radius fixed proportional to RTS) Experiment 2: vary radius of units (units fixed proportional to RTS)

Uncertainty Gain

Bandwidth RTS games are really turn-based at a ms level, but often the turns are empty Need a bandwidth model that scales down to ms but allows for empty moves Terms: vr = viewable region n = new units s = signaturer = time interval to update vr sm = secured moves

Estimating Bandwidth Viewable area  Game state: 11,000 x 11,000 positions  Mini-map in Warcraft: 175 x 175 pixels  gives reasonable representation of viewable area  Assume 200ms for r Warcraft allows max 100 units/player  Assume half of units sent each timeslice Number of moves  Depends on click-speed  Fast players peak at 5 moves / second Maximum bandwidth: ~2-3 kilobytes/second How does this compare to real games?

Units in a real game over time Replay from a single Warcraft 3 game

Size of mini-map Replay from a single Warcraft 3 game

Summary Scheme addresses a key RTS cheat Decreases information exposed Bandwidth seems reasonable Future work  Evaluate scheme vs. game traces  Make a library of game traces, viewable areas

End of talk Questions?

Non-repudiation How to prove cheating to a 3 rd party?  Need more cryptography: message signatures Digest each message and encrypt the digest with private key 3 rd parties digest each message and compare with decrypted digest  Ideally public keys for this stored at game’s authentication server

Bit Commitment Example: Fair coin flip Each party…  Comes up with a secret key  Encrypts “heads” or “tails”  Exchanges encrypted messages  Exchange secret keys  Whoever was the “flipper” wins if answers differ, loses if they’re the same Needs fixing if you want to show the result to someone else: non-repudiation

Background: non-repudiation Properties  N-r messages cannot be forged  Everyone can verify the author of an n-r message The trick: signatures  Requires player I to have public key pub i and private key priv i  Given message X, compute h(X), a cryptographic hash of X  The signed version of X is (X,priv i (h(X))): X appended with an encrypted version of h(X).  Everyone can verify the author of the message Decrypt the signature using the public key Perform the hash on X. Out pops h(X)  Why can’t they be forged?

Another metric: Information loss Uncertainty very generic We can quantify information loss: percentage of data deleted Example  Quantizing a large map into a 2x2 grid  Any more units than 4 are lost Scheme has two sources of information loss:  Quantization  Overlapping viewable areas

Information loss Quantization  Scatter p points  Downsample  Count number of points p’, compute the ratio p’/p Overlap  Scatter points  Expand viewable areas  Calculate overlapped area as “lost”

Information loss

Information loss conclusions Information loss modest: 12% for 6 units Expect trace-driven data to show more loss: units are clustered often in game play

Applicability outside of RTS Apps that are…  Peer-to-peer (ie, too resource consumptive to host client-server)  Tolerant of extra bandwidth requirements Example:  Board games  Card games

Don’t have to send all units Blue doesn’t send these units (they’re not visible) Blue doesn’t send these units (they’re already known about by yellow) Blue only has to send these units