Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GDC 2013 - Ditching the Server: Making Client-side Only Social Games


Published on

Amitt Mahajan discusses techniques and strategies for developing client/server architecture that is game-code agnostic.

Published in: Technology
  • Be the first to comment

GDC 2013 - Ditching the Server: Making Client-side Only Social Games

  1. 1. Ditching the ServerHow to create client-side only social gamesAmitt Mahajan (@amittm)Founder/CEO, Red Hot Labs
  2. 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 WarGDC2013 • @amittm 2
  3. 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 errorGDC2013 • @amittm 3
  4. 4. 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 callsGDC2013 • @amittm 4
  5. 5. The Problem• Write code twice, maintain 2 codebases• Server state needs to be in sync: leads to out-of-syncerrors• Provision servers & deploy code for each game• Game teams and server ops teams tightly integrated• Complicated, hard-to-port, game-specific network codeGDC2013 • @amittm 5
  6. 6. 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 stateGDC2013 • @amittm 6
  7. 7. 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 mobileGDC2013 • @amittm 7
  8. 8. Limitations• Prior server controlled variables are now insecure• Player-to-player interactions made insecure• Potentially complicated validation mechanisms• Global leaderboards / ladders easily manipulatedGDC2013 • @amittm 8
  9. 9. 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 ofproperties• Objects can have references to other objectsGDC2013 • @amittm 9
  10. 10. 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}]}GDC2013 • @amittm 10
  11. 11. 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 objectGDC2013 • @amittm 11
  12. 12. Data Security• ObjectAccess-Control-Layer (ACL) system• Permissions granted using access tokens• Versioning / Conflict-resolutionGDC2013 • @amittm 12
  13. 13. Uses for ACLs• Private or read-only user data• Shared game state or game objects• Static, developer-defined, game dataGDC2013 • @amittm 13
  14. 14. Example: AccessTokensGDC2013 • @amittm 14Client APIServer1. Login using email/pass2. Return AccessToken3. Request game object with token5. Return requested object4.Verify accesstoken grantspermissionSPECIFICALLY torequested object
  15. 15. AccessToken LevelsGDC2013 • @amittm 15Access Token LevelNone • No or invalid access token provided• User only has access to global objectsUser • User logged-in / authenticated• User can access objects owned by their user IDSystem• Secret/private access token• Game developer usage only• Can modify any object on the server
  16. 16. Impact on Game Design• Trust is now a consideration in game-design• Some game-styles will not be possible withoutadditional validation• May limit creativity of game mechanics in certaincasesGDC2013 • @amittm 16
  17. 17. 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 SomethingGDC2013 • @amittm 17
  18. 18. Cheating• Modification of player stats/state• Generating favorable outcomes• Could potentially hurt revenue• Non-technical players can cheat with toolsGDC2013 • @amittm 18
  19. 19. ValidationTechniques• Analytics• Secure token and separate service• Unified scripting languageGDC2013 • @amittm 19
  20. 20. Example: How to hack XP1. Player uses a proxy to examine network calls2. Figures out what a save call looks like3. Modifies game state to desired result4. Executes a save call with modified stateNote:This isTRIVIAL and a big hole!GDC2013 • @amittm 20
  21. 21. 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-positivesGDC2013 • @amittm 21
  22. 22. Example: XP delta over timeGDC2013 • @amittm 22020040060080010001200Day 0 Day 4 Day 8 Day 12 Day 16 Day 20Suspicious spike outsideacceptable range,flag account
  23. 23. Production Case: Bingo Blast!• Head-to-head & solo game for iOS/Android• Shared game objects• Game requests / messages• In-app purchases• No server work requiredGDC2013 • @amittm 23
  24. 24. Conclusion• There is no one-size-fits all solution• Server-side validation is good for absolute cheatprevention and is proven to work• Client-only validation provides performance boost, lesserrors, and development time reduction at cost of security• Automatic validation non-trivial and will improve over timeGDC2013 • @amittm 24
  25. 25. Thank you!Email: amitt@redhotlabs.comTwitter: @amittmWeb: / redhotlabs.comGDC2013 • @amittm 25