Presenting some of the technical feats that we've been able to achieve while making RoboBlastPlanet and an inside look at the setup we have for creating a game that can run at 60 FPS on mobile platforms as well as on a large number of browsers.
3. Agenda
Project intro
Development Tools
Conditional Compilation restrictions
Target frame rate
Cross Platform Multiplayer via
SmartFox Server
Scout usage
Weekly content releases
Leaderboards and Reddis
Part 2
4. Project Intro
Make a game that runs on iPhone, Android &
Web
Minecraft like building style, for avatars and
levels
Real time multiplayer
Social Network, integration with
MovieStarPlanet
6. Conditional compilation restrictions
Helps to keep code clean
Have as few compiler flags as possible (3)
Use of inheritance for device specific code (iOS, Android, Web)
Input works like this
7. Target Frame Rate
60 FPS from the start
“Premature Optimization is the root of all evil” -Donald Knuth
Starting at 60 FPS with no content means every change that drops the framerate gets noticed quickly and
considered more thoroughly before being merged into main branch
8. Network communication code abstraction,
lets us focus on the gameplay server side
TCP & UDP messages only (Web and
Mobile)
Keep packets as small as possible
Amazon Web Services (AWS) for Server
up & down scaling
Cross Platform Multiplayer via
SmartFox Server
11. Weekly Content Releases
Release new content every week for player engagement
We’ve had 40 content releases so far (every Thursday!)
12. Leaderboards and Reddis
Wanted to have cross platform leaderboards
Database access for live data is slow
Real time updates (every time you reload the
leaderboard)
Reddis backend
Estimated 16 gameplay hours to get 1 million blast points!
14. Agenda
Hot reloading of assets (UI & Flare)
JSONSprite
Reuse Flare Materials
Debug Panel and cheats
GameObject/Behavior
Image C
AS3 optimizations
Signals only
Compressed Int
Context Lost
Sharing of render targets
Mesh batching
20. ImageC file format
Preprocessed image
Pros:
No Loader instance needed (No extra allocations)
No decoding
Works in all devices
Cons:
Bigger size (20% larger than a PNG in the worst case)
21. AS3 Optimizations
Optimized Loops
No Array/Vector push calls
No splice if the Player version allow us (RemoveAt() or custom splice)
Object Pooling
Single EnterFrame
22. Custom Signals
Based on Robert Penner’s as3Signals we created a simplified version of that
concept.
Pros:
No Events
No allocations
Callbacks are faster
Cons:
Non typed
23. Compressed int
We needed to store a massive amount of values related to voxels data.
The smallest data type that we could use was int.
This data structure handles multiple values inside one int to reduce the amount of
memory usage.
Example: 1000 ints between 0 and 256
Vector.<int> = 4004 bytes
Compressed int = 1004 bytes;
24. Context Lost
By default Starling keeps a reference to the BitmapData that we are using to be
able to re-upload it when the context is gone.
Instead of doing this we went for the reload everything approach.
We don’t have any bitmapdata cached in ram.
25. Flare & Starling sharing textures
We needed to show a 3d mesh inside the UI without hacking the entire universe.
Create a FlareTexture that we use as a render target and share the native texture with a StarlingTexture
so we can display the same content in the UI without adding additional agents in the middle.
26. Mesh Batching
Basically we reuse the same surface/mesh data to render it in multiple places at the same time in one
draw call.
All the meshes can move, rotate, scale or change color.
This concept was included a few releases later directly in Flare3D.