In recent years, cloud computing services have been increasing in greater pace. High penetration rate of mobile devices and resource limited devices escalate the demand for cloud services further. Even though the cloud industry continues to grow exponentially, the cloud gaming service has been left behind due to the limitations in today's technology. There are three well known reasons for the slower growth - latency, server scalability (esp. bandwidth) and lack of game data at client side to use latency hiding and synchronisation techniques such as Dead-reckoning. In this paper, we propose a novel distributed micro-cloud infrastructure with a next generation device called Gamelet to mitigate the limitations in traditional cloud system for multiplayer cloud gaming on resource limited mobile devices. The paper also investigates the opportunities, issues and possible solutions for Gamelet infrastructure for mobile games with a demonstrable prototype.

1. +
Gamelets - Multiplayer Mobile Games with
Distributed Micro-Clouds
(Mobile Cloud Computing)
Bhojan Anand (presenter), Aw Jia Hao Edwin

2. +
Cloud Games
Cloud Computing
 Infrastructure as a Service(IaaS)
 Platform as a Service (PaaS)
 Software as a Service (SaaS)
Cloud Games
 Software as a Service (SaaS)
 Games on Demand (GoD)
 SaaS alone is forecasted to grow five times faster
than traditional software packages

3. +
Multiplayer Games
(Local Game State)
Player Simulation,
Opponent Prediction

4. + Multiplayer Cloud Games
• CPU/GPU load is
reduced to save
mobile’s energy
• Centralized control
(Version update,
Cheating
prevention,
Payment/
Endogenous-value
…)
• Scalable

5. +
Multiplayer Cloud Games
Key Challenges
- All these
operations
should
happen
serially in
few ms!
- Requires
high sever
bandwidth
for Video
Streaming
Interaction Delay

6. +
Multiplayer Cloud Games
 But, “the Latency and Jitter are not new issues”
How did conventional multiplayer games handle
this?
Local Game State Simulation
Immediate
Response
Prediction
Local
Perception
Filters
Require
Intelligent
Clients!

7. +
Multiplayer Cloud Games
Key Challenge
Could Games introduce additional latencies
 Cloud Processing
 Encoding
More serious one is:
 Network Latency and Jitter
Worse in Mobile Environments.
 Even with LTE it takes 70ms to closest data center
 Goes upto 200ms

8. +
Gamelet System
Render at next hop!
 Gamelet is a minimal-set hardware required
to run, render and stream 3D games placed
in the same local network or few hops (most
of the time one or two hops) away from the
mobile client.
Uses distributed rendering to counter the
limitations of renderer hw resources

9. +
Gamelet Architecture
COMPONENTS:-
- Processing Unit,
- RAM ,
- Graphics Card,
- Flash Drive for basic
OS
Benefits:-
- Latency Hiding
(Immediate Feedback,
DR, LPF)
- Scalable (Bandwidth)
- Distributed Rendering
Peer device can be a Gamelet!

10. +
Gamelet System
Focused Areas of this Work
Zone Distribution
Distributed Rendering (Peer-Assisted
Rendering)
 Content Based Adaptive Streaming

11. +
Zone Distribution & Distributed
Rendering
Avg Size of a 3D Game 5 Gbytes
Eg. Battlefield 3 recommends 4GB RAM and
20GB Storage
 It will take about 56 mins to download over
3G network (assuming 1.5 Mbps)
Download/Render
only the “Zones of
Interest”
Check adjacent
Gamelets before
downloading
Zones

12. +
Zone Distribution
Zones and What they Contain

13. +
Zone Subdivision Algorithm
 Max Zone Size=
Factor(t_Download,
t_Load)
 Recursively divide
until the zone size is
less than max size
 Dynamically Resized

14. +
Zone Request Processing
Request to
download
 When user (player
camera) enters the
boundary
 Request to load
 When user’s far clip
plane enters a new
zone
Boundary Size = function(far clip plane distance,
t_Download, t_Movement)

15. +
Distributed Rendering
Common Methods/Libraries
 Network-Integrated Multimedia Middleware (NMM)
 Top Game engines do not have NMM layer
 Real-Time Scene Graph (RTSG)
 Not accessible for Game developers
 Multi-Camera Distributed Rendering
(MCDR)
 Practicable Approach
 Can be used with any Game Engine

16. +
MCDR - Rotating Camera

17. +
MCDR - Rotating Camera
Fish eye view on objects near and far
NOT
RECOMMENDED!

18. +
MCDR - Reshaping the view
frustum
Most Appropriate Way
- Settings are
Same as Main
camera.
- Manipulate Side
Clip Planes

19. +
Distributed Rendering
Rendering sections of view port in parallel

20. +
Selecting Adjacent Gamelets
Initial adjacency list is obtained from the
main Game Server
 List is maintained with periodic ‘pings’ to
neighbors
A Gamelet will send data to neighbor node
only if ….
 Send Data
 Render
 Receive Image
In Serial < 40ms
(1/25 s)

21. +
Streaming to Client: Image vs Video
Encoding latency (ms) Decoding latency (ms)
461
74
500
450
400
350
300
250
200
150
100
50
0
Image
Video
244
72
300
250
200
150
100
50
0
Image
Video

22. +
Streaming to Client: Image vs Video
File size (kb)
63.85
106.92
120
100
80
60
40
20
0
Image
Video

23. +
Streaming to Client (Images)
Content Based Adaptive Streaming (CBAS)
30% of the display is used for in-game HUD
 5-8fps is sufficient for such static areas
We mask this area in all other frames, resulting in
high compression ratio

24. +
Streaming to Client (Images)
Content Based Adaptive Streaming (CBAS)
When the player is idle and his view is static,
the background is mostly static
 Stream at low rate

25. +
Game Client
Display and Collect User Actions
The client side code of the game simply gets
the compressed stream from the Gamelet
and uncompresses it to display.
 In addition, it captures all the user actions.
 [No Audio in Current Version]

26. +
Evaluations
Bandwidth & Scalability
 800x480 WVGA
 1 to 3 Mbps after state-of-the-art compression
with CBAS
Support upto 5 clients in 802.11b
9.6 Kbps between Gamelet to Server

27. +
Evaluations
Average Processing Load
 Measured with windows task manager and MSI
Afterburner version 2.3.1
GPU Load is proportional to number of pixels to
render. [Linear]

28. +
Evaluation
Small Scale User Study
 Garden of Eden – 3D survival Game
 Game Server in School Network
 Gamelets and Clients at two randomly selected
802.11 APs in School
 Laptop, iPad versions of the Client were used
 Seven UG users played the Game. Played multiple
versions after 20mins training (Game mechanics)
 Observed artefacts (latency, jitter, visual quality,
synchronisation etc)

29. +
Evaluation
Small Scale User Study

30. +
Demo
 Look for “Gamelets - Multiplayer Mobile Games with Distributed Micro-Clouds” in Youtube

31. +
Contribution
First attempt towards a distributed micro-cloud
infrastructure
Multi-camera Distributed Rendering
 Can be done on top of any game engine
Content Based Adaptive Streaming
Techniques for Games
Basic Results are Promising

32. +
Limitations & Future work
 Zone handling overhead
 Addition/Removal of Zones
 User playing in the game world close to multiple boundaries will
trigger the download of several zones
 Synchronisation of Gamelets
 Overall rendering workload is still more than rendering on one device
 Due to number of encoding/decoding calls
 Mobility of players
 Gamelet node – Trust
 Fairness in Game play
 Eg Some users may connect to powerful Gamelet

33. +
THANK YOU
Questions?