A Distributed Game Engine for Mobile Games

on the Android Platform

Davide Gadia

, Dario Maggiorini

, Davide Puopolo

, Laura Anna Ripamonti

and Luca Ziliani

Department of Computer Science, University of Milan, via Comelico 39, I-20135 Milano, Italy

Keywords:

Game Engines, Game Development, Mobile Platforms, Distributed Systems.

Abstract:

In the last few years we have witnessed a tremendous change in the way game developers are required to

deal with software production. We moved from small groups building the application ground-up to large

coordinated teams with hierarchical organisation. To support this transformation, game developers are now

using integrated development and execution environments called game engines. Among all possible gaming

platforms, mobile ones are proving to be a challenging ground due to their intrinsic requirement for game

engines to deploy the ﬁnal application on a distributed system. In this paper we discuss about requirements

for next-generation game engines for mobile devices. In particular, we propose a variation of the standard

approach for game engines architecture pushing from a monolithic architecture toward a distributed one. In

our solution, the mobile game engine becomes modular and lower the distinction between client and server

side.

1 INTRODUCTION

In these last years, the way developers implement

video games is undergoing a tremendous change. If

we look to historical blockbusters for home entertain-

ment such as Pitfall!, Tetris, and Prince of Persia we

can see the name of a single developer. As a matter

of fact, in the ’80s, all aspects of video game develop-

ment were usually managed by a single person or, at

best, a very small group. Today, with the evolution of

the entertainment market and the rise of projects with

seven (or eight) ﬁgures budget, this situation calls for

a drastically different approach. Video game develop-

ment is now a distributed collaborative effort involv-

ing tens to hundreds of programmers. This increasing

complexity of teams organisation and the tremendous

growth of projects size force development teams to or-

ganise themselves in a hierarchical way and to adopt

software engineering practices enforcing string code

reusability. As a result, modern video games are im-

plemented by means of software environments called

game engines.

A game engine, as largely discussed in literature,

is a complex framework made of two main building

blocks: a tool suite and a runtime component. In par-

ticular, the runtime component assembles together all

the internal libraries required for hardware abstrac-

tion and provides services for game-speciﬁc function-

alities. A variable portion of the runtime is usually

linked inside the game and distributed along with the

binary executable. As a matter of fact, deployment

for different platforms requires to embed speciﬁc run-

times wrapping the same game content. The game

content is made up of rules and assets created by de-

velopers and artists, which get managed via the tool

suite component. When developing a game for a mo-

bile device, the aforementioned architecture may re-

ally become an hindrance since we have a distributed

platform as target environment.

Mobile applications in general, and games in par-

ticular, have an intrinsic requirement to be deployed

on a distributed system due to the always-online na-

ture of mobile devices and a strong prerequisite to

play (or, at least, interact) online with other players.

Developing any kind of application for a distributed

environment involves managing data transmission be-

tween heterogeneous platforms and monitoring real-

time operations to prevent failures due to undelivered

or delayed packets. In particular, as also discussed

in (Festa et al., 2017), distributed debugging is a com-

plex problem due to the synchronisation required be-

tween network nodes to correctly reconstruct the se-

quence of events leading to a malfunctioning feature.

With the increasing presence of distributed appli-

cations and frameworks in online services (i.e., cloud

computing), the constraints introduced by mobile de-

Gadia D., Maggiorini D., Puopolo D., Ripamonti L. and Ziliani L.

A Distributed Game Engine for Mobile Games on the Android Platform.

DOI: 10.5220/0006508601420149

In Proceedings of the International Conference on Computer-Human Interaction Research and Applications (CHIRA 2017), pages 142-149

ISBN: 978-989-758-267-7

vices are now spreading to all other platforms. Un-

der these lenses, current research faces an important

task: to understand if classical client-server architec-

tures for games are up to the challenge or something

more modular and ﬂexible is required. We strongly

believe that the classical approach will not be enough

for the next generation of game developers, for two

reasons. The ﬁrst reason is poor scalability. As a mat-

ter of fact, modern games are pushing to involve thou-

sands to millions of players in Massively Multiplayer

Online Games (MMOGs). The resources used by an

MMOG must be shared among users and scale in a

seamless way with the offered workload. If a stan-

dard client-server approach is adopted, the server is

in charge for data exchange between all clients. Such

server will also become a single – global – point of

failure and a serious bottleneck. Load shedding be-

tween servers may not be an option when dynamic in-

formation must be shared to a worldwide player pop-

ulation. The second reason is the client-server strict

dependency from a well known, and always available,

service provider. Next generation games should be

able to exploit the network whenever available, while

allowing single player mode when ofﬂine, with mini-

mal experience degradation for the user.

As a result, we envision that there will be a strong

demand for game engines with a ﬂexible and modular

architecture (such as the ones envisioned in (Maggior-

ini et al., 2015) and (Maggiorini et al., 2016)) which

will deploy seamlessly on multiple platforms and al-

low component distributions over a network without

asking for additional effort from the developer. A pos-

sible ﬁrst step to understand how distributed game en-

gine can be shaped in the future is to apply their model

to the current mobile ecosystem (Gerla et al., 2013).

For this reason, we propose here a modular architec-

ture for game engines targeting the Android operating

system.

To deploy our architecture on a distributed system,

we lower the distinction between client and server ar-

chitecture and make it evolve in a similar direction

as a peer-to-peer network. Where required, a func-

tionality can be provided both locally and remotely

with the same API. Scalability will beneﬁt from this

approach thanks to transparent service-points reloca-

tion. A service may be provided from an arbitrary

point of the peers mesh based on resources availabil-

ity and response time. Service point relocation can

be achieved using local policies leveraging on neigh-

bours node discovery. As a result, from a game devel-

oper’s point of view, no network management will be

required and platform-dependent code can be limited

to a minimum.

2 RELATED WORK

In the past, a fair number of scientiﬁc contributions

has been devoted to improve the architecture of game

engines. Nevertheless, at the time of this writing and

to the best of our knowledge, only a very limited num-

ber of papers are speciﬁcally addressing issues related

to scalability and cross-platform portability.

A signiﬁcant share of existing literature seems to

be focused on optimising speciﬁc aspects or services,

such as 3D graphics (e.g., (Cheah and Ng, 2005)) or

physics (e.g., (Mulley, 2013; Coumans, 2006; Mag-

giorini et al., 2014)).

Issues related to portability on different platforms

have been addressed, among the others, by (Darken

et al., 2005), (Guana et al., 2015), (Munro et al.,

2009), and (Carter et al., 2010). Authors of (Darken

et al., 2005) propose to improve portability by pro-

viding a unifying layer on top of other existing en-

gines. In fact, they extend each architecture with an

additional platform-independent layer and assume a

share set of functionalities to be available on all plat-

form. This approach is feasible for multi-platform de-

ployment but may reduces performances and set all

platforms to use a shared set of basic features. Au-

thors of (Guana et al., 2015) focus on development

complexity and propose a solution based on mod-

ern model-driven engineering while in (Munro et al.,

2009) an analysis of the open source version of the

Quake engine is performed with the purpose to help

independent developers contribute to the project. In

the ﬁrst case, developers may not be able to imple-

ment any possible game mechanics while, in the sec-

ond case, results are limited to a speciﬁc game and

they stay on the same platform. A different approach

has been followed by (Carter et al., 2010) where au-

thors envision convergence to a web-based platform.

In this case, we have to outline mobile devices are still

lacking web-based 3D support and, also, many mobile

features (e.g., bluetooth peer-to-peer connection) may

not be accessible as part of the gaming experience.

If we focus strictly on the adoption of distributed

systems as viable platforms for games, research is

currently pushing toward two directions: improving

network performances and providing distributed ser-

vices.

Improvement of network performances is mostly

related to reduce transmission latency by optimisa-

tion (Chen et al., 2016b) or ofﬂoading (Chen et al.,

2016a; Zucchi et al., 2013) in order to achieve the

same result as in a local system (Chen et al., 2014).

Unfortunately, it has been proved long ago that In-

ternet is not following a WFQ service model and a

reliable estimation strategy for available resources is

still to come. For this reason, many papers are fo-

cusing on how existing game engines are adapting

to the cloud (Messaoudi et al., 2015; Kim, 2013) or

a distributed system in general (Deen et al., 2006)

and evaluating player experience in these environ-

ments (Sabet et al., 2016; Suznjevic et al., 2016; Wen

and Hsiao, 2014).

When providing distributed services, the main

idea is to make available a game-related feature us-

ing the cloud (Aly et al., 2016). Many research

efforts have been devoted to create distributed im-

plementations of existing engines. Unfortunately,

many of them apply a distributed system approach

only to a speciﬁc internal service (such as simu-

lation pipeline or shared memory (Gajinov et al.,

2014; Lu et al., 2012)) while others ofﬂoad non

time-critical but computational-intensive tasks to the

cloud (e.g., avatar animation (Li et al., 2015)). While

these approaches are greatly increasing data process-

ing power, they do not provide a solution to the prob-

lem of creating a completely distributed game engine.

3 BACKGROUND ON GAME

ENGINES

Although game engines have been studied and per-

fected since mid-’80s, a formal and globally accepted

deﬁnition is yet to be found for them. Despite this

lack of deﬁnition, the function of a game engine

is fairly clear: it exists to abstract the (platform-

dependent) details of doing common game-related

tasks, like rendering, physics, and input; so that de-

velopers can focus on implementing game-speciﬁc as-

pects.

In particular, inside a game engine we can ﬁnd

a runtime component. The runtime component is a

collection of software libraries required for hardware

abstraction. Since a variable portion of the runtime

is usually linked inside the game or get distributed

along with the executable, mobile devices pose seri-

ous problems. These problems may be coming from

very specialised hardware drivers, different technical

speciﬁcations such as screen size and aspect ratio, or

limitations imposed by online market owners. There

might be huge differences in term of capabilities for

runtimes used in phones with different brands. Some-

times, even within different models under the same

brand.

The drawback on the developer is that many times

the game code must be platform aware and perform

operations based on the underlying device due to fea-

ture missing or not working in the local runtime.

3.1 A Brief History of Game Engines

The ﬁrst example of game engine dates back to 1984

with the game Doom (ID Software, 1993) Despite

the fact Doom was not designed around the concept

of game engine, it paved the way to a number of

best practises for their deﬁnition. In the Doom ar-

chitecture, we could observe a strict separation be-

tween software modules. To each module, a pre-

cise function and location in the architecture was as-

signed. In particular, there was clear distinction be-

tween code and data assets. This approach enforced

code reusability and made for an easy portability on

different platforms. The rules we just described are

nowadays standard best practices for software engi-

neering; however, it was not uncommon in the ’80s

for one-man projects to have hardware-speciﬁc self-

modifying code. To actually see the ﬁrst example of

game engine we had to wait until mid-’90s with the

release of Quake Engine (ID Software, 1996) and Un-

real Engine (Epic Games, 1998). Quake and Unreal

have not been designed as environments to hold a spe-

ciﬁc game rather than as collections of software com-

ponents useful to create First Person Shooter (FPS)

games. As a matter of fact, the business model of

ID and Epic was not just about selling games to end

users rather than selling an engine to other develop-

ers. Starting from this point, games opened up to

user customisation and, most important of all, their

engines have been regarded by software companies

as an asset. As of today, we have companies mak-

ing games and selling their internal technology along

with companies (such as Unity Technologies (Unity

Technologies, 2005)) focused only on distributing and

supporting a game engine platform. Of course, game

engines have not been immune to the open source

movement. Many open source projects exist pro-

viding specialised gaming functionalities to be used

in third parties projects (e.g., Ogre3D (Torus Knot

Software, 2013) for graphics and Bullet (Coumans,

2006) for physics) or a complete application stack

(e.g., Cocos2D (Chukong Technologies, 2010) and

Torque (Garage Games, 2012)). Today, we can ob-

serve on the market a growing number of game en-

gines with speciﬁc goals and adopting different ap-

proaches. In particular, for mobile devices, many of

them focus on the optimisation of hardware perfor-

mances and cross-platform deployment (such as the

Marmalade game engine (Marmalade Technologies,

1998)) or try to achieve a distributed platform lever-

aging on the we infrastructure by means of javascript

(see e.g., the Turbulenz game engine (Turbulenz l.t.d.,

2009)).

4 A DISTRIBUTED ANDROID

GAME ENGINE

As already mentioned in the previous sections, the rel-

evant diffusion and success of mobile games is push-

ing the need for advanced, robust, and ﬂexible game

engines, which able to address the peculiar character-

istics of the multiple available platforms and of the

intrinsic difﬁculties of a distributed system. In this

section, we present our proposal for an engine archi-

tecture for mobile games. Our aim is to address in a

simple but effective way the different possible gam-

ing conﬁgurations (online and ofﬂine) as well as roles

(client and server) while feeing the developer from

explicit network management.

The architecture described in the following sub-

section has been implemented in java using the An-

droid Development Toolkit (ADK). By using ADK,

our prototype is leveraging on the android hardware

abstraction to provide a single-layer class library and

to offer basic functionalities to create games. A game

can just import our class library and provide its own

asset management and game logic. The asset man-

agement part may be an ad-hoc implementation for

the game or exploit a third party library; the android

execution environment will take care of the integra-

tion.

To prove the feasibility of our approach, we used

our class library to implement True Believers Mobile:

an online distributed mobile game. As a matter of

fact, the engine prototype can be used as a foundation

for any kind of player vs player strategy game.

4.1 General Architecture

Our proposed architecture tries to disengage from

the classical client-server approach: all functionali-

ties should be present in every node and used seam-

lessly by the runtime component of the game engine.

This way, we lower the boundaries between client and

server components and create generic software nodes

to build a distributed system. Each node is hosting

both a server- and client-side component to be used

depending on the situation. The client component can

connect to a remote server (online mode) or locally

(ofﬂine mode) to request gaming service. The soft-

ware implementing the game client is not actually re-

quired to know – or manage – the actual service mode.

The server component will accept one or more incom-

ing connections to provide a gaming service. The

software implementing the server is not required to

know if a contacting client is local or remote. The

server side must manage multiple connections in the

most effective way, set up games between clients, col-

lect and validate each action or request sent by clients,

and then update the overall state of the game. In any

case, more than one match may take place in a server

at a given time. Each match will hold its own game

state. The equivalent of a classic server is simply a

software node where the client component is inactive.

Of course, one of the key element of any dis-

tributed architecture is the transmission reliability for

game data. Since foundation classes are implemented

directly in ADK, we can use both TCP or UDP trans-

port protocols for data exchange. TCP offers a re-

liable transmission over packet switched networks

by means of packets retransmission after a timeout.

Despite the additional delay, game interactions time

proved to be bounded to an acceptable level for strat-

egy games. When dealing with strict real-time games,

UDP may be preferred over TCP depending on game

mechanic time constraints. Real-time gaming on a

wide area network is usually addressed with speciﬁc

game mechanics and prediction mechanisms. Both of

these solutions are implemented in the higher levels

of the application stack.

One important topic when dealing with distributed

games is cheat prevention. We are not going to ad-

dress this problem here since it is usually solved

through code signing and peer authentication mech-

anisms in the network layer. Our prototype is, in fact,

assuming a trusted network platform. Nevertheless,

we acknowledge the importance of this problem and

plan to address it in a future work.

4.1.1 Server Functionalities

In Fig. 1 we show a scheme representing the modules

of the server component and their interconnections.

Basically, the Connection Manager and Match Man-

ager modules are instantiated at game server startup,

while the other submodules are instantiated on re-

quest.

Game

Engine

Connection

Manager

Match

Manager

Client

Request

Manager

Sender

Receiver

Match

Loader

Game Loop

Game State

Manager

Action

Validator

Game Server

Backend

Client Management

Match Management

Figure 1: Dependencies of Game Server modules.

The role of the Connection Manager is to man-

age all the connection requests and, in case of accep-

tance (usually through an authentication process), to

instantiate all the resources needed by each connec-

tion. After a connection is established, all messages

exchanged between client and server are managed by

a dedicated instance of the Client Request Manager.

A Client Requests Manager manages the messages

from and to a single client through a Sender and a

Receiver modules. Once a request is received (e.g.,

to begin a new game, or to perform a particular ac-

tion during a game), the message is forwarded to the

Connection Manager, which, in turn, will contact the

Match Manager module. The Match Manager mod-

ule, and its submodules are the core of the server side

of our architecture.

Similarly to the Connection Manager, the Match

Manager is a management module and takes care of

the instantiation and management of Match Loader

modules; one for each active match. When the Match

Manager receives a request to begin a new game, it

checks if other players are available (using a match-

making algorithm on the connected clients), and cre-

ates a new game by instantiating a Match Loader

module. The Match Loader module is in charge of

the actual creation and management of the resources

for the speciﬁc match between the clients involved in

the game. The actual management of a speciﬁc game

is actually performed by the Game Loop, Action Val-

idator, and Game State Manager submodules.

The Game loop module is the main component

for the actual game. It manages the synchronization,

and performs the simulations aimed at determining

the new states for game and players. On the basis

of the nature and complexity of the game, it can be

structured in several dedicated submodules (e.g., for

artiﬁcial intelligence, or for the automatic generation

and validation of new levels), to be executed in dif-

ferent threads. Every time a client performs an action

during a match, the Action Validator module checks

for its validity. This module stores all the controls and

procedures (i.e., the game rules). If the action is valid,

the Action Validator module communicates the result

to the Game State Manager. If the action is refused,

the failure is notiﬁed through the Sender module, or

some other feedback can also be considered (e.g., if

cheating or hacking attempts are detected). The Ac-

tion Validator must also validate actions and events

generated by the Artiﬁcial Intelligence submodule of

Game Loop module. Finally, the Game State Man-

ager updates the overall game state, on the basis of

the actions validated from the Action Validator, and

uses the Sender module to synchronise game states

on the client side.

4.1.2 Client Functionalities

In Fig. 2 a scheme presenting the modules hierarchy

of the Client component is reported. As we can see,

Game

Engine

Rendering

Engine

Session

Manager

Offline

mode

Input

Manager

Match

Loader

Local Action

Validator

Game State

Manager

Game

Loop

Receiver

Sender

Online

mode

Figure 2: Dependencies of Game Client modules.

the same modular approach as in the server compo-

nent is adopted. Moreover, a subset of modules is

also shared between client and server sides. Remote

or local instantiation and execution of these modules

at runtime is based on the actual game mode (e.g.,

online multiplayer or ofﬂine single player). This ap-

proach allows for a great ﬂexibility in the application

of the engine to different games, and a more efﬁcient

implementation for the programmers, who have ac-

cess to those functionalities through a common and

uniﬁed API, with less efforts required in the explicit

management of the network features.

The Input Manager and Rendering Engine mod-

ules are speciﬁc to the Game Client implementation.

The Input Manager manages the input from the player

(through keyboard, mouse, or other input devices),

and on the basis of the type of the input and of the

current state of the game, it communicates to the Ses-

sion Manager module the message to be sent to the

Game Server. The Rendering Engine manages all the

aspects related to the graphics of the application: ren-

dering loop, GUI updates, camera movements, anima-

tions, etc. With respect to the game complexity and

need, it is usually subdivided in several speciﬁc sub-

modules, each dedicated to a speciﬁc aspect. The ﬁnal

result generated by the Rendering Engine depicts the

updated state of the game, once all the actions have

been validated, and the corresponding results simu-

lated and calculated.

Regarding the network modules, the execution

context of the Game Client is very different than the

one of the Game Server. In case of an online game,

there is only one connection (to the Game Server) to

manage. The Session Manager module has the same

role and functionalities than the Client Requests Man-

ager module described before (including its Sender

and Receiver submodules). Actually, from a devel-

opment point of view, they can also provide the same

APIs. When online, the Session Manager module re-

ceives information from the Input Manager and sends

requests to a remote server via the Sender module.

Answers, received through the Receiver module, are

then sent to the Game State Manager module in order

to update the local game state.

As it can be noticed from Fig. 2, the Game Client

presents the same Match Loader module than the

Game Server, with the same duties (i.e., the alloca-

tion and management of the local resources needed

by the game from a client-side perspective). Same

observation holds for the Game Loop and Game State

Manager submodules.

In an online gaming session, the Game State Man-

ager receives update from the Receiver module (af-

ter validation from the Action Validator on the server

side) and updates the local game state. If the game

is used ofﬂine, a Local Action Validator module is

instantiated. This module shares the same code and

most of the functionalities of the Action Validator

module on the server side (even if some speciﬁc con-

trol or procedure may be different due to the differ-

ent networking context), but, in this case, it commu-

nicates directly to the Game State Manager module.

Moreover, on the basis of the nature of the game,

some of the functionalities of the Game Loop (i.e.,

advanced artiﬁcial intelligence) may also need to be

instantiated locally.

To better explain the characteristics and modular-

ity of the presented approach, we present in Fig. 3 a

diagram of the data ﬂow between client and server. In

the ﬁgure, the client side is depicted on the left while

the server side (when playing online) is reported in the

right side. If the client is operating ofﬂine, messages

are routed through the Local Action Validator module

while if the game is online Sender and receiver mod-

ules are involved and talking with the remote counter-

part (large shaded rectangle in the center). About the

big picture, there are two important things to point

out. First, once the engine infrastructure is set up

all the game code is just sitting in the Game Loop

module. From a server-side perspective, the Game

Loop will generate actions (to be validated) for the

evolution of environment and Non-Playing Charac-

ters (NPCs) while, on a client-side perspective, it will

react to player’s input. The game loop will be the

same on both side; actually, there will be only one

Game Loop module since we are not implementing

strictly client or server nodes. Second, for sake of

clarity, Fig. 3 is not drawn in full. As a matter of fact,

all modules are presents on both sides of the commu-

nication and it is possible to also have a player on the

network node acting as server (hosting the game). In

such case, the Input Manager module will be active

also on the server side and the Game Loop will react

to user input as well as generate NPCs actions.

4.2 True Believers Mobile

To test the feasibility of the proposed architecture,

we have implemented an online Real-Time Strategy

game called True Believers Mobile. True Believers

Mobile uses the class library described in the previ-

ous section in order to deliver online functionalities

to the user. Each game level is a maze populated by

enemies, traps, and power-up items where the goal is

to to reach a given position or to acquire an object

within a given time limit. To do this, the player places

her own characters in the maze in a strategical way.

The game can be played by a single (ofﬂine) player,

or against another online player. With respect to the

proposed architecture, character availability for each

level is managed by the Match Loader module. The

Game Loop module implements a dedicated Artiﬁcial

Intelligence submodule to manage NPCs behaviour

and movement.

The maze description is managed by a speciﬁc

submodule of the Match Loader called Maze Man-

ager. This module is responsible to parse a conﬁgura-

tion ﬁle and load all the needed resources. Moreover,

it generates a new set of rules speciﬁc for the loaded

maze and sends them to the Action Validator module.

As already said, these procedures can be executed lo-

cally on the client, or remotely on the Game Server,

without an explicit management from the developer.

Finally, a stand-alone Level Editor tool has been

implemented in order to allow the players to design

and generate their custom mazes to be used during

game sessions with other players. The user is shown

a schematic view of the maze with the possibility to

deﬁne the characteristics of each position. Once com-

pleted, the level description is saved in a local store.

In an online conﬁguration, the new level is sent to the

Game Server when starting a game with another on-

line player. The Level Editor shares with the game en-

gine a subset of modules needed for its execution; in

particular, the Match Loader functionalities are used

to load the graphical resources of the tool, and the In-

put Manager and Render Engine are needed to man-

age the user interaction and the editor interface. In

Fig. 4(a) we show the Level Editor tool, while in

Fig. 4(b) we show a screenshot of a True Believers

Mobile game session based on the level generated by

the Level Editor tool.

Receiver

Sender

Receiver

Sender

Offline mode

Online mode

Update

state

Send

action

Network

Client Side Server Side

Rendering

Engine

Input

Manager

Local

Action

Validator

Game

State

Manager

Game

Loop

Validate

action

Update

state

Collect

input

Generate

action

Update

interface

Session

Manager

Connection

Manager

Match

Manager

Match

Loader

Game

Loop

Game

State

Manager

Action

Validator

Connection

request

Connection

accepted

(instantiate)

Match

request

Create

match

Find

players

Start

match

Generate

action

Action

received

Action

is valid

Update

remote

Client

Request

Manager

Figure 3: Client-Server data-ﬂow diagram.

(a)

(b)

Figure 4: True Believers Mobile: level editor tool (a), and a

screenshot of a game (b).

5 CONCLUSION AND FUTURE

WORK

In this paper we discussed about the requirements

needed by a next-generation game engine to support

mobile devices and a distributed solution feasible for

the Android platform has been proposed. In our solu-

tion, server and client functionalities are hosted in ev-

ery node, and they are allocated and used by the run-

time component of the game engine depending on the

current game conﬁguration (online or ofﬂine). The

overall approach we suggest allows to blur the dis-

tinction between client and server roles and to evolve

the system toward an architecture similar to a peer-

to-peer network. This evolution does not require any

longer the developer to manage the network by imple-

menting a distributed system. In the manuscript, we

also present a Real-Time Strategy game implemented

using our architecture to demonstrate its feasibility.

The next step of our research aims to under-

stand the relation between network performances and

player experience as well as to understand how our

architecture can dynamically adapt to different net-

work technologies e.g., roaming from WiFi to LTE

and back. Moreover, we are also planning to im-

plement other kind of games on top of our proposed

architecture in order to evaluate by comparison how

various genres are going to beneﬁt from a distributed

game engine approach. Last but not least, cheating

prevention mechanisms should also be integrated in

our game engine architecture.

REFERENCES

Aly, M., Franke, M., Kretz, M., Schamel, F., and Simoens,

P. (2016). Service oriented interactive media (soim)

engines enabled by optimized resource sharing. In

2016 IEEE Symposium on Service-Oriented System

Engineering (SOSE), pages 231–237.

Carter, C., Rhalibi, A. E., and Merabti, M. (2010). Develop-

ment and deployment of cross-platform 3d web-based

games. In 2010 Developments in E-systems Engineer-

ing, pages 149–154.

Cheah, T. C. S. and Ng, K. W. (2005). A practical imple-

mentation of a 3D game engine. In Computer Graph-

ics, Imaging and Vision: New Trends, 2005. Interna-

tional Conference on, pages 351–358.

Chen, K. T., Chang, Y. C., Hsu, H. J., Chen, D. Y., Huang,

C. Y., and Hsu, C. H. (2014). On the quality of ser-

vice of cloud gaming systems. IEEE Transactions on

Multimedia, 16(2):480–495.

Chen, M. H., Dong, M., and Liang, B. (2016a). Multi-user

mobile cloud ofﬂoading game with computing access

point. In 2016 5th IEEE International Conference on

Cloud Networking (Cloudnet), pages 64–69.

Chen, Y., Liu, J., and Cui, Y. (2016b). Inter-player delay

optimization in multiplayer cloud gaming. In 2016

IEEE 9th International Conference on Cloud Comput-

ing (CLOUD), pages 702–709.

Chukong Technologies (2010). Cocos2D-x. http://

cocos2d-x.org/.

Coumans, E. (2006). Bullet physic library. http://

www.bulletphysics.org/.

Darken, R., McDowell, P., and Johnson, E. (2005). Projects

in VR: the Delta3D open source game engine. IEEE

Computer Graphics and Applications, 25(3):10–12.

Deen, G., Hammer, M., Bethencourt, J., Eiron, I., Thomas,

J., and Kaufman, J. H. (2006). Running quake ii on a

grid. IBM Systems Journal, 45(1):21–44.

Epic Games (1998). Unreal Engine. http://en.

wikipedia.org/wiki/Unreal Engine.

Festa, D., Maggiorini, D., Ripamonti, L., and Bujari, A.

(2017). Supporting distributed real-time debugging in

online games. In 2017 IEEE Consumer Communica-

tions and Networking Conference (CCNC).

Gajinov, V., Eric, I., Stojanovic, S., Milutinovic, V., Un-

sal, O., Ayguad, E., and Cristal, A. (2014). A Case

Study of Hybrid Dataﬂow and Shared-Memory Pro-

gramming Models: Dependency-Based Parallel Game

Engine. In Computer Architecture and High Perfor-

mance Computing (SBAC-PAD), 2014 IEEE 26

In-

ternational Symposium on, pages 1–8.

Garage Games (2012). Torque-3D. http://

www.garagegames.com/products/torque-3d.

Gerla, M., Maggiorini, D., Palazzi, C., and Bujari, A.

(2013). A survey on interactive games over mo-

bile networks. Wireless Communications and Mobile

Computing, 13(3):212–229.

Guana, V., Stroulia, E., and Nguyen, V. (2015). Build-

ing a Game Engine: A Tale of Modern Model-Driven

Engineering. In Games and Software Engineering

(GAS), 2015. IEEE/ACM 4

International Workshop

on, pages 15–21.

ID Software (1993). DOOM. http://en.wikipedia.org/wiki/

Doom (1993 video game).

ID Software (1996). Quake Engine. http://en.wikipedia.org/

wiki/Quake engine.

Kim, H. Y. (2013). Mobile games with an efﬁcient scal-

ing scheme in the cloud. In 2013 International

Conference on Information Science and Applications

(ICISA), pages 1–3.

Li, M., Cai, W., Wang, K., Hong, J., and Leung, V. C. M.

(2015). Prototyping decomposed cloud software: A

case study on 3d skeletal game engine. In 2015 IEEE

7th International Conference on Cloud Computing

Technology and Science (CloudCom), pages 192–195.

Lu, H., Yijin, W., and Hu, Y. (2012). Design and implemen-

tation of three-dimensional game engine. In World Au-

tomation Congress (WAC), 2012, pages 1–4.

Maggiorini, D., Ripamonti, L. A., and Cappellini, G.

(2015). About Game Engines and Their Future.

In Proceedings of EAI International Conference on

Smart Objects and Technologies for Social Good

(GOODTECHS 2015), pages 1–6.

Maggiorini, D., Ripamonti, L. A., and Sauro, F. (2014).

Unifying Rigid and Soft Bodies Representation: The

Sulfur Physics Engine. International Journal of Com-

puter Games Technology, pages 1–12.

Maggiorini, D., Ripamonti, L. A., Zanon, E., Bujari, A., and

Palazzi, C. E. (2016). SMASH: A distributed game

engine architecture. In 2016 IEEE Symposium on

Computers and Communication (ISCC), pages 196–

201.

Marmalade Technologies (1998). Marmalade game engine.

https://marmalade.shop/en/.

Messaoudi, F., Simon, G., and Ksentini, A. (2015). Dis-

secting games engines: The case of unity3d. In 2015

International Workshop on Network and Systems Sup-

port for Games (NetGames), pages 1–6.

Mulley, G. (2013). The Construction of a Predictive Colli-

sion 2D Game Engine. In Modelling and Simulation

(EUROSIM), 2013 8

EUROSIM Congress on, pages

68–72.

Munro, J., Boldyreff, C., and Capiluppi, A. (2009). Ar-

chitectural studies of games engines: The quake se-

ries. In Games Innovations Conference, 2009. ICE-

GIC 2009. International IEEE Consumer Electronics

Society’s, pages 246–255.

Sabet, S. S., Hashemi, M. R., and Ghanbari, M. (2016). A

testing apparatus for faster and more accurate subjec-

tive assessment of quality of experience in cloud gam-

ing. In 2016 IEEE International Symposium on Mul-

timedia (ISM), pages 463–466.

Suznjevic, M., Slivar, I., and Skorin-Kapov, L. (2016).

Analysis and qoe evaluation of cloud gaming service

adaptation under different network conditions: The

case of nvidia geforce now. In 2016 Eighth Interna-

tional Conference on Quality of Multimedia Experi-

ence (QoMEX), pages 1–6.

Torus Knot Software (2013). Ogre. http://www.ogre3d.org/.

Turbulenz l.t.d. (2009). Turbulenz game engine.

http://biz.turbulenz.com/.

Unity Technologies (2005). Unity3D. http://unity3d.com/.

Wen, Z. Y. and Hsiao, H. F. (2014). Qoe-driven perfor-

mance analysis of cloud gaming services. In 2014

IEEE 16th International Workshop on Multimedia

Signal Processing (MMSP), pages 1–6.

Zucchi, A. C., Gonzalez, N. M., d. Andrade, M. R.,

d. F. Pereira, R., Goya, W. A., Langona, K., d. B. Car-

valho, T. C. M., and Mngs, J. E. (2013). How ad-

vanced cloud services can improve gaming perfor-

mance. In 2013 IEEE 5th International Conference on

Cloud Computing Technology and Science, volume 2,

pages 289–292.