Unite2014 Bunny Necropsy - Servers, Syncing Game State, Security and Optimizations
-
Upload
david-geurts -
Category
Software
-
view
280 -
download
0
description
Transcript of Unite2014 Bunny Necropsy - Servers, Syncing Game State, Security and Optimizations
Bunny Necropsy Servers, Syncing Game
State, Security and
Optimizations
Colter Haycock & Dave Geurts
Software Engineers
Smart Bomb Interactive
Goals: Create mobile game that…
• Supports local only mode
• Allows play on multiple devices
• Seamlessly supports online and offline play
• Is non-intrusive when switching devices
• Requires minimal server logic
1) Serialized hashed game state
2) Security
3) Server with volatile caching and persistent storage
4) Save state system for online and offline play
Our Recipe
1) Hashed Game State: Ingredients
Serialization - Google Protocol Buffers
Positives
o Less Server Code
1) Hashed Game State: Ingredients
Serialization - Google Protocol Buffers
Positives
o Less Server Code
o Less Database Schemas to Manage / Scale
1) Hashed Game State: Ingredients
Serialization - Google Protocol Buffers
Positives
o Less Server Code
o Less Database Schemas to Manage / Scale
o Obfuscation
Serialization - Google Protocol Buffers
Positives
o Less Server Code
o Less Database Schemas to Manage
o Obfuscation
Negatives
o Can be difficult for debugging
o Will need an External source for Metrics/Analytics
Game State versioning
1) Hashed Game State: Ingredients
Serialization - Google Protocol Buffers
Positives
o Less Server Code
o Less Database Schemas to Manage
o Obfuscation
Negatives
o Can be difficult for debugging
o Will need an External source for Metrics/Analytics
Game State versioning
1) Hashed Game State: Ingredients
2) Security
Encryption of Game State
Prevent share of save files
Client needs to be able to decrypt
without talking to server
Don’t leave keys/salt in plain text
TAKEAWAY: If someone smart wants to hack your game, they will!
3) Server w/ Volatile Caching
and Persistent Storage
Application language that can Easily load balance
App server needs to be lean!
Simple Logic to allow easy scaling
Cache layer to let databases breathe!
Pick a database that will shard out of the box
4) Online and Offline Play
Problem
How do you allow play on multiple devices while
supporting online and offline modes?
Houston, We Have a Problem
● The client saves on pause and every x min.
● The save goes to disk and tries to go to
server if user has internet
● On startup and resume, client sends login
● Server responds to logins with game state
and accompanying deviceID
Syncing Formula
Client Logic
Login
DeviceID:
Save
Online
Login Save
Online
Login
Save
Online
Server
Example One
State:
1
1
2
2
3
3
2 3 4
4
Login Save
Online
Login Save
Offline Save
Online
Example Two
Login Save
Online
DeviceID:
Server
State: 1
1
2
2
3
2
3
4 4
3
4
Login Save
Online
No Net
So No
Login
Save
Offline Login
Example Three
DeviceID:
Server
State: 1
1
2
2
0
3 4 5 6
2
Situation: same account playing on multiple
devices at the same time
Potential Solutions
Don’t Allow Stomping Stomp + Notify
Same Time Play
● On login, client asks if they can play
● Client sends heartbeat to server every x seconds
● Client sends “I’m done” on pause/quit
Pros
● No losing data by stomping!
Cons
● Requires server and client code
● Must ping servers frequently
Same Time Play: Don’t Allow
● Whoever saves last (closes app) wins
Pros
● No added client or server code
Cons
● Stomping SUCKS
○ Users won’t always realize when
they stomp and might think it’s a bug
Same Time Play: Stomping
Same Time Play: Stomp + Notify
● Whoever saves last (closes app) wins
● Notify users when stomping occurs
Pros
● Users can keep playing if they want
● Notified if stomping is occurring
Cons
● Stomping still sucks
● Extra client and server code
Improvements
Hindsight Is Wonderful
• People barley ever QUIT your app.
Almost all “closes” are really just pauses!
• Don’t assume your target audience’s hardware!
• Do research about silly reasons
why Apple has rejected apps!
Hindsight Is Wonderful
• Plan for networking and work on it from the start !
• QA in a small market, but remember to TEST it!
• Create and release on Android first
• Asset Bundle All the Things!
• Bigger Scope
• Tools
• Networking Approach
• CORE - Custom MonoBehaviours
• Bundle All the Things
Project X
•Text - Data Sheets
•Art - Asset Bundles
•Build Servers
•Cache Server
Tools
Tools
Art Tools
Text Tools
App Server with Queue
Build Servers Dev App / CDN Servers
Tools
Text - Data Sheets
• CSV
• Encryption
• Versioning
• Localization
Tools
Tools
Art Bundles
• Call From Editor
• Async
Tools void OnEnable() {
#if UNITY_EDITOR
EditorApplication.update = MyUpdate; #endif
}
#if UNITY_EDITOR
public void MyUpdate() {
if(www != null && www.isDone) LoadCompleted(); }
#endif
public void LoadCompleted() {
if(string.IsNullOrEmpty(www.error)) {
Debug.Log(“w00000t”); }
}
Tools
Art Bundles
• Call From Editor
• Async
• Authentication
Tools
Queue Server
• Receive Commands From Tools
• Send commands to build servers
• Moves bundles to Dev servers
Build Servers
• CLI unity commands - unity to run
in headless mode
Tools
-batchmode -quit -projectPath /root/Unity5
-executeMethod ABB.BuildAssetBundles
-logFile Unity_Build_Log.log
Tools
Build Servers
• CLI unity commands - unity to run
in headless mode
• SVN
• Optimizations - Cache Server
Tools
Tools
Memory Optimizations
1. Have low-quality and high-quality versions of
images and audio
2. Unload unused
images and sounds
3. Compress animations
4. Don’t use dynamic
meshes if possible
Networking
RESTful HTTP: uni-directional protocol that generates a
new TCP connection for each request
Pros
● Works well with spotty internet
Cons
● Server can’t send messages to client whenever it wants
● New TCP connection every request
● Stateless
Networking
Stream Socket: reliable bi-directional communication
stream with semi-persistent connection
Pros
● Minimal overhead (connect once)
● Server can send messages to client
Cons
● Doesn’t work well with spotty internet
SVN Externals
● Your working copy can be made up of multiple
checkouts from different locations in a repository, or
even a totally different repository.
● Share repositories for
multiple projects
● Fixes made in one don’t
need manual updating
● In-house editor plugins
Core System Core : MonoBehaviour
AudioManager audioManager;
LevelManager levelManager;
AudioManager : ManagerBase
ManagerBase : MonoBehaviour
Awake: coroutine waits for Core to be finished initializing
MUpdate, MAwake, MStart, etc.
ManagedBehaviour : MonoBehaviour
Awake: coroutine waits for Core to be finished initializing all managers
MAwake, MStart, MUpdate, etc.
Core System Pros
1. Before any awake/update/etc. runs you know for sure all core + managers
are done initializing
2. Specific ordering of update/awake/start
3. Pooling – auto repool on disable/destroy
4. Slow down/speed up updates -- for specific types
5. Pausing updates -- for specific types
6. Enables updates every x frames or X ms
Cons
1. Hard to manage Core between scenes
2. Maintenance costs if shared between projects
Bundle, Bundle, Bundle
1. Artists make awesome content
2. Build doesn’t get out in time
3. Everyone is sad
4. Next game uses asset
bundles everywhere so this
doesn’t happen again