XLcloud Use Case - Cloud Gaming

Check out the video: XLcloud Cloud Gaming Doom 3.
A demonstration of the Doom 3 BFG edition played in the cloud, from the browser. We show both single and multiplayer session. The user experiences no interaction latency and fluid game visual effects. The game runs entirely on a node of the Virtual Cluster. The demo is live at www.MyMultimediaWorld.com.

Overview

Taking off on the early 80s (preceded by the adoption acceleration of personal computers), the industry of video games is one of the most profitable and stable industries in the entertainment market. Currently, videogames are not longer considered as minor sector having just passionate gamers as target. Nowadays, multimedia platforms (PC, tablet, smart-phone...) are becoming more powerful, especially those with advanced GPUs, yet, 3D graphic application designers tend to exploit their capabilities to the edge. GaaS should provide the user to run any game in any device typically through a pay-per service business model. The games are accessible from various clients’ interfaces via a web browser.

overall_arch3.jpg

Figure1. General service

Platform short description

The architecture proposed to render GaaS has 3 main components: The game application, the lobby server and the MPEG compliant client. 

kusanagi_arch.jpg

Figure 2. General architecture

The plug-in is a piece of software that allows turning any 3D graphic application into remote controlled software. This transformation requires being able to stream two different kinds of data: (1) interactivity commands from client to server and (2) audio and video data from server to client. The lobby server is the central program that manages the resources sharing and acts as an interface between the application and the users. A net-input HTTP server is used to transmit clients’ commands to the game. The port number is negotiated by the lobby server and there is no interaction with the lobby server during the session (transport). At the beginning of the session, the lobby server can also provide some user based information to the plug-in like the initial round trip time (RTT), measured between the server and each client. At client side, a full multimedia MPEG-4 player with networking, media, user interactions management and rasterizing is used. 

Use Case 1: Game Catalogue creation

Actors: Professional user; Virtual machine; Lobby server (middleware)
Goals: contributes to build the game catalogue that should be accessible for the end user
Events: (1) Authentication, (2) Installation of the application in the server (performed by the service provider, i.e. the developer or the publisher), allocation of a specific URL know by the lobby, (3) Creation of an snapshot to present in the catalogue and (4) Configuration of the application in the VM

Description: The developer or publisher (service provider) is using our platform to deliver the game to the end user.

System Actor Action System Response 

Professional User (PU) access the system

The system asks for authentication

PU authenticates itself

Display upload interface

PU performs the upload of the game

The system verifies the compatibility: (1) Failure: not compatible à end of the process, (2) Success: installation of libraries and divers

PU logs out

The system allocates diverse instances (depending of the capacity of each VM and the characteristics of the game) and put the information on the Lobby

Requirements:

  • Identification: The platform must authenticate the professional user.
  • Upload of the game and compatibility verification
  • System capable to install the libraries and drivers
  • Catalogue data base
  • Define the number of users according to the characteristics of the game and the capacity of the VM

Use Case 2: Access to the game

Actors: End user; Lobby; virtual machine
Goals: Access to game catalogue and plays (interaction)
Events: (1) Open an account, (2) Access catalog in the browser, (3) Choose a game, (4) Play a game and (5) Saves his information
Description:

System Actor Action System Response 

The user  access the web page and choose to display the games menu

The server is launched and detects if the client plug-in is installed and proposes the installation

User has GPAC or installs GPAC

Server is launched and ask the user for identification

The user authenticates himself

The Lobby recognizes the user and loads the information

The user choose a game

A bt file is charged and the lobby gives the corresponding IP ; The game starts the plug-in (in the VM) ; The system allocates diverse instances (depending of the capacity of each VM and the characteristics of the game) and put the information on the Lobby

The user access the game and starts playing - Interactions requests

Systems render video and image and responses to interactivity

User device to end the game

Systems ask the user if he wants to save the current game and score

User accepts or declines

Systems saves user new information

Exit game

Systems disconnects

Requirements: Allocation of different VM for the same game in case of arriving to the limit capacity. Each game has different HW “necessities”: if we consider that the VM are homogenous the quality of service will be ensure by proving additional VM for the gamers that access the platform when reaching the defined maximum level.

Characteristics of the Lobby: (1) Knows with approximation when it reaches the limit, (2) it’s aware of the nr of users and the nr of games, (3) for the future: measurements of the fps - when fps<threshold we need to start a new VM and (4) we know when a VM it’s saturated - send this information to the virtual cluster manager hat starts a new VM

Technical requirements

1. Architecture: We can have two types of architectures

a) VMa = one VM that does everything (game, interaction, compression, streaming etc)

b) VMb = dedicated machine (One VM for rendering, one for compression etc)

In both cases the VC returns the URL of the machine that does the streaming. The platform has to offer a communication interface with the client. The URL is also sent when resources must be freed (when a user disconnects itself).

2. Hardware : Regarding the video parts in general, requirements are mainly related to spatial resolution and temporal resolution (in frame per second). Regarding the video compression side, video quality, multi-screen content encoding and decoding resources capabilities have to be considered in addition. Finally, regarding the video streaming itself, available and varying bandwidth have to be considered conjointly in the design. Hence, for this particular Cloud Gaming use case, the high level of interactivity leads both to a reduce end-to-end latency and to a quite high frame rate. A latency of 40ms coupled with a frame rate of 20fps seems to be the basis. Regarding spatial resolution, a 720p (i.e. 1280x720 pixels) resolution will be the basis. Video Quality requirements will be a major concern in the project since levels can vary from one part of an image to another or from a scene to another depending on the texture details and the needed interactivity.

3. Software: It “would be nice” if the service can run in different operatin systems. In the client side the only requirement is to have the GPAC available to be downloaded.


This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 5.4.6 - Documentation - Legal Notice

Site maintained by