gdc 2013 - ditching the server: making client-side only social games

Ditching the ServerHow to create client-side only social games

Amitt Mahajan (@amittm)Founder/CEO, Red Hot Labs

2

My Background• Co-creator/Lead Developer

– FarmVille

– ExampleVille: Zynga’s game engine & framework

• CTO, Zynga Japan

– Develop mobile games for the Japanese market

• Developer, Unreal Engine/Gears of War

GDC2013 • @amittm

GDC2013 • @amittm 3

Client/Server Replication• Client replicates commands to the server

– Mostly async, non-blocking, operations

• Server validates commands to prevent

cheating

– Success: Update DB; Failure: Out-of-sync error


Client/Server Implementation• Client-side code: ActionScript, Obj-C, Java,

JS

• Server-side code: PHP, Ruby, C, JS

• Data storage: Relational DB, NoSQL, iCloud

• Communication via REST calls


The Problem• Write code twice, maintain 2 codebases

• Server state needs to be in sync: leads to out-of-sync

errors

• Provision servers & deploy code for each game

• Game teams and server ops teams tightly integrated

• Complicated, hard-to-port, game-specific network code


Proposal: Client-only validation

• All game logic lives with client-code

• Trust player client state

• Server is a dumb-pipe to store data

• Use automatic validation to lazy check

state


Benefits• Split creating games from running server operations

• Reuse infrastructure in several games and platforms

• Better utilize server resources with reduced

complexity

• Reduce development time and errors

• Reduce out-of-sync errors, potentially better for mobile


Limitations

• Prior server controlled variables are now insecure

• Player-to-player interactions made insecure

• Potentially complicated validation mechanisms

• Global leaderboards / ladders easily manipulated


Data Storage

• Schema-less DB offers greatest flexibility (e.g. NoSQL)

• Object-based schema keyed using class-name and id

• Server does not validate data but keeps track of

properties

• Objects can have references to other objects


Example Object{

_className:“User”,_id: 25,_acl: {“read”:”global”,”write”:[25]},_version: 3,level: 4,coins:76,

games:[{_className:”Game”,id:45},{_className:”Game”,id:34}]}


Example API• Object.get(className, id)

– Returns object data based on className and Id

• Object.set(className, id, data)

– Sets data for an object

• Object.acls(newAcls)

– Changes the access permissions for an object


Data Security

• Object Access-Control-Layer (ACL) system

• Permissions granted using access tokens

• Versioning / Conflict-resolution


Uses for ACLs

• Private or read-only user data

• Shared game state or game objects

• Static, developer-defined, game data


Example: Access Tokens

Client APIServer

1. Login using email/pass

2. Return Access Token

3. Request game object with token

5. Return requested object

4. Verify access token grants permission SPECIFICALLY to requested object

15

Access Token Levels

GDC2013 • @amittm

Access Token Level

None • No or invalid access token provided• User only has access to global objects

User• User logged-in / authenticated• User can access objects owned by their user

ID

System• Secret/private access token• Game developer usage only• Can modify any object on the server


Impact on Game Design• Trust is now a consideration in game-design

• Some game-styles will not be possible

without additional validation

• May limit creativity of game mechanics in

certain cases


Best Use Cases• Asynchronous is the intended use case

• Single player games that require cloud storage

– Plants vs. Zombies, Angry Birds

• Single player w/ multiplayer component

– FarmVille, Sims Social

• Limited PvP games

– Words with Friends, Draw Something


Cheating

• Modification of player stats/state

• Generating favorable outcomes

• Could potentially hurt revenue

• Non-technical players can cheat with tools


Validation Techniques

• Analytics

• Secure token and separate service

• Unified scripting language


Example: How to hack XP1. Player uses a proxy to examine network calls

2. Figures out what a save call looks like

3. Modifies game state to desired result

4. Executes a save call with modified state

Note: This is TRIVIAL and a big hole!


Example: Preventing XP Hacking

• Developer marks XP field in an object as being “rate-limited”

or “important”

• User modifies their local XP value

• On post-object-save:

– Store historical values of field

– Standard deviation rate of change flags account for manual review

– Tweak thresholds for false-positives


Example: XP delta over time

Day 0

Day 2

Day 4

Day 6

Day 8

Day 1

0

Day 1

2

Day 1

4

Day 1

6

Day 1

8

Day 2

0

Day 2

20

200

400

600

800

1000

1200

Suspicious spike outside acceptable range,flag account

Acceptable Range


Production Case: Bingo Blast!

• Head-to-head & solo game for iOS/Android

• Shared game objects

• Game requests / messages

• In-app purchases

• No server work required


Conclusion• There is no one-size-fits all solution

• Server-side validation is good for absolute cheat prevention

and is proven to work

• Client-only validation provides performance boost, less errors,

and development time reduction at cost of security

• Automatic validation non-trivial and will improve over time


Thank you!

Email: [email protected]

Twitter: @amittm

Web: amitt.com / redhotlabs.com

gdc 2013 - ditching the server: making client-side only social games

Technology