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
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
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)
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
All the information required for a user to play the game in his specific zone
Boundaries are the places in the world which prompts the game to request additional game data for downloading.
Near and far clip planes on the cameras view frustums are not aligned between all rendering units
If your actor moves in a building, you may want to ignore the walls or furniture between the actor and the camera, you may use the Clipping Planes feature. By defining the range consists of Near and Far parameters, you may see the actors behind the wall or relieve the load of your system. This feature can not be set as a key in the Timeline.
Rule of Clipping-planes
The Clipping-Planes provide two parameters, Near and Far, to define the render-able range of a camera.
<http://www.reallusion.com/iclone/Help/iClone3/10_Scene/Camera/Clipping_Planes_of_the_Camera.htm>
Encoding – 86% reduction
Decoding – 70% reduction
VIDEO STREAM – Encode Current Frame with previous N frames. Only changes in new frame will be sent.