+

Gamelets - Multiplayer Mobile Games

with Distributed Micro-Clouds
(Mobile Cloud Computing)

Bhojan Anand (presenter), Aw Jia Hao Edwin

+
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

+
Multiplayer Games

(Local Game State)

Player Simulation,
Opponent Prediction

+Multiplayer Cloud Games

CPU/GPU load is
reduced to save
mobiles energy
Centralized
control (Version
update,
Cheating
prevention,
Payment/
Endogenousvalue )

+
Multiplayer Cloud Games
- All these
operation
s should
happen
serially in
few ms!
- Requires
high
sever
bandwidt
h for
Video

Interaction Delay

Key Challenges

+
Multiplayer Cloud Games
But,

the Latency and Jitter are not new

issues

How

did conventional multiplayer games

handle this?

Local Game State Simulation

Immediat
e
Response

Prediction

Local
Perceptio
n Filters
Require
Intelligent
Clients!

+
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

+
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

+
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!

+
Gamelet System

Focused Areas of this Work

Zone

Distribution

Distributed

Rendering (Peer-Assisted

Rendering)

Content Based Adaptive Streaming

+
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/Rende
r only the
Zones of
Interest

Check adjacent
Gamelets before
downloading
Zones

+
Zone Distribution
Zones and What they Contain

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

+
Zone Request Processing
Request

to
download
When

user (player
camera) enters the
boundary

Request to load

When users far

clip plane enters a
new zone
Boundary Size = function(far clip plane distance,
t_Download, t_Movement)

+
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

+
MCDR - Rotating Camera

+
MCDR - Rotating Camera

Fish eye view on objects near and far

NOT
RECOMMENDED!

+
MCDR - Reshaping the view
frustum
Most

Appropriate Way

- Settings are
Same as Main
camera.
- Manipulate
Side Clip
Planes

+
Distributed Rendering
Rendering sections of view port in parallel

+
Selecting Adjacent Gamelets
Initial

adjacency list is obtained from

the main Game Server

List

is maintained with periodic pings

to neighbors

Gamelet will send data to neighbor

node only if .
Send

Data
Render
Receive Image

In Serial < 40ms

(1/25 s)

+
Streaming to Client: Image vs
Video
Encoding latency (ms)

Decoding latency (ms)

72

74

Image
Video

Image
Video
244

461

+
Streaming to Client: Image vs
Video
File

size (kb)

106.92
Image
Video

63.85

+
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

+
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

+
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]

+
Evaluations
Bandwidth & Scalability

800x480 WVGA

1 to 3 Mbps after state-of-the-art

compression with CBAS

Support
9.6

upto 5 clients in 802.11b

Kbps between Gamelet to Server

+
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]

+
Evaluation
Small Scale User Study
Garden
Game

of Eden 3D survival 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)

+
Evaluation

Small Scale User Study

Demo
+

Look for Gamelets - Multiplayer Mobile Games with Distributed Micro-Clouds in Youtube

+
Contribution
First

attempt towards a distributed

micro-cloud infrastructure

Multi-camera
Can

Distributed Rendering

be done on top of any game engine

Content

Based Adaptive Streaming

Techniques for Games

Basic

Results are Promising

+
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

THANK YOU

Questions?