Presentation on theme: "Mitigating Information Exposure to Cheaters in Real-Time Strategy Games Chris Chambers Wu-chang Feng Wu-chi Feng Portland State University Debanjan Saha."— Presentation transcript:
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)
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 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