Generic and Distributed Runtime Environment for
Model-driven Game Development
Sebastian Apel and Volkmar Schau
Department of Computer Science, Friedrich Schiller University Jena, Ernst-Abbe-Platz 2, 07743, Jena, Germany
Software Architecture, Adaptive, Generic Infrastructure, Game Model, Model-Driven Game Development,
Massive Multiplayer Online Games.
Massive multiplayer online games are large-scaled distributed systems to handle a huge amount of simultane-
ous players. Thus, development costs can be enormous. To deal with this, it is necessary to reduce redundant
development steps in such distributed systems, e.g. by using code generators and model analysers to build
components from already existing knowledge. Such knowledge could be the unique game logic. This paper
reports realized approaches to derivate infrastructure from that logic within our middleware. Getting through
this is achieved by using an abstract meta model for game design processes, harvest information from those
design results and generate infrastructure for communication, controlling and persistance. Finally we evalutes
its applicableness and useablity in multiple game projects.
In the last decades gaming is dominated by online
games everybody wants to play, sometimes with
friends, sometimes against them furthermore, they
want to play by browser, phones or in social net-
works. Such large-scaled distributed and complex
systems could need a high amount of development
efforts. Moreover, social, role-playing or shooter
games have an intersection of their architectural com-
ponents. Constructing such Massive Multiplayer On-
line Games (MMOG) requires an architecture to man-
age a high number of players, handle their requests
and persist their states.
A common MMOG architecture is based on
client-server structures (Chen et al., 2013; Bharambe
et al., 2006). The server in general contains a con-
tinuously simulated game logic, a database to persist
game states and a component to handle requests re-
ceived from clients. The clients on the other side man-
ages subsets of the game state, loaded from the server,
can communicate over networks the servers by using
a message handler and provides components to han-
dle visual and auditive elements of the game (Chen
et al., 2013).
The main difference between concepts for this
kind of games can be found in their game logic. This
logic describes core elements of a game and the de-
pendencies between them. Furthermore, this is the
unique part of a game idea. Each unique game idea
has to model and implement the logic as well as
construct the infrastructure components around. The
question would be about which of these infrastruc-
ture components around game logics can be derived
and generated by using code generators and a generic
runtime environment. Another important question is
how to design the architecture to execute such games
with generic infrastructure?
The primary objective is to provide a game mid-
dleware. The GameEngine, our middleware, has to
provide methods to add individual game logics, de-
rives required infrastructural knowledge from them
and generates the corresponding components. Using
this engine would reduce the amount of development
effort and avoids bulky reimplementation of redun-
dant components.
To achieve the goal of generic components, based
on a previously modeled game logic, three steps will
be necessary and part of our work: (1) an efficient ab-
stract communication layer which avoids calculation
overhead mostly triggered by abstraction (Apel et al.,
2014), (2) a mechanism to derive information from
game logic to generate infrastructure for our game and
(3) a meta model for game logics as an entry point for
derivation processes and as development support.
This paper will evaluate the question about the
useablity and applicableness of this middleware
within different kind of game projects. The experi-
Apel, S. and Schau, V.
Generic and Distributed Runtime Environment for Model-driven Game Development.
DOI: 10.5220/0005652306230630
In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 623-630
ISBN: 978-989-758-168-7
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
Zone 1
Zone 2
Zone ...
Room 1
Room 2
Room ...
Figure 1: Visualization of a room-based communication
structure (gotoAndPlay(), 2011).
mentees are supposed to define their own game idea
and going through their model-driven engineering
process until they reach their final platform indepen-
dend game model. The intended game projects are
circumscribed to location-based browsergames, a spe-
cial subtype of MMOGs. Finally each team has to
implemented their model and should executed the im-
plementation within the runtime environment of our
middleware in addition to some kind of client-side vi-
sualization. Furthermore their shouldn’t be any tech-
nological details like communicating with User Data-
gram Protocol (UDP) / Transmisson Control Protocol
(TCP), serialize data with Extensible Markup Lan-
guage (XML) / JavaScript Object Notation (JSON) or
persist data to MySQL databases.
Related research is focusing on architectural ques-
tions about how to construct games for massively dis-
tributed systems and huge amount of players (Chen
et al., 2013; Gregory, 2009; Bharambe et al., 2006).
Another part is going through abstracted communi-
cation, unfortunately independently from the perfor-
mance as well as from modelling and game archi-
tecture. Combining them into a development process
which is dominated by model-driven engineering me-
thodics by using generic approaches is missing.
Taking a look into middleware and tools for
MMOG development is dominated by three solutions:
(1) SmartFoxServer 2X (gotoAndPlay(), ), (2) ES5
Electroserver (Elektrotank, ) and (3) Photon Server
(Exit Games, a). These Java- and C#-based solutions
helps to implement a server-client based game by us-
ing TCP or UDP based sockets and a key-value-based
proprietary protocol for data (de-) serialization. All
products offer a room-based communication infras-
tructure to manage the distribution of data packets to
connected players (gotoAndPlay(), 2011). A room-
based infrastructure as shown in Figure 1 could be
compared with concepts in instant messengers like
Internet Relay Chat (IRC) and ICQ, as well as mes-
max view range
Event A
Event B
Event C
Figure 2: Visualization of a position based communication
structure. The centralized position (marked by X) has a
specific max view range, each event in this range would be
broadcasted to X (in this case event A and B).
sengers based on Extensible Messaging and Presence
Protocol (XMPP). Each connected individual can
specify a set of rooms to listen for. In case of com-
munication events, the runtime environment tries to
place them to the related room and broadcast the con-
tained data to listeners in this room. You can find such
solutions in a wide range of games: every time there
is a visual separation in the game – for example zone
borders, beaming, instantiation or clustering – there is
usually a room concept behind the scenes.
The opposite approach of this room based com-
munication would be a location-based mapping of lis-
tening individuals as shown in Figure 2. Each individ-
ual could have one or more positions and each posi-
tion will have a specific range to listen to. In case
of any event, you will receive this event, if it is re-
leased within the range around one of your positions.
Only the Photon Server (Exit Games, b) offers such
a concept in addition to room-based listenings. Apart
from that, all middleware offer client implementations
in common technologies like HTML5 / JavaScript,
Flash / ActionScript, Unity, iOS and Android.
To add a game idea to these middleware, all solu-
tions offers so called extension points. This extension
point within this monolithic architecture offers capa-
bilities to interact with the communication infrastruc-
ture by using a specified Application Programming
Interface (API). In case of any game logic the de-
veloper has to implement their own controller layer
to handle messages between middleware and game
The objective of this paper is to identifying methods
for game logic analyses. These methods will be com-
bined in our GameEngine to support model-driven
game development processes. First of all, we need
to know detailed information about the game logic it-
self. Defining an abstract model can solve this. This
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
registerObject(o : GameObject)
id : long
execute(a : GameAction)
dispatch(e : Event)
addObserver(o : Observer)
removeObserver(o : Observer)
handle(e : Event)
0..n 0..n
Figure 3: Class diagramm of a basic meta model to use in
game logic implementations.
model defines entry points which can be used by an
abstract component for further analyses. Furthermore
this model has to be the intersection, which could
be found in each game logic. To reengineer such a
meta model, a closer look on fundamental principles
of game modeling was necessary.
A game is a type of play activity, conducted in
the context of a pretended reality, in which the partic-
ipant(s) try to achieve at least one arbitrary, nontrivial
goal by acting in accordance with rules. (Adams,
2010) Pretend some kind of new reality, define a set
of rules and nontrivial goals (Adams, 2010; Rollings
and Morris, 2004). This non-existing, virtual “pre-
tended reality” is our base element within the abstract
meta model. The GameEngine will call this element
“game world”. The element “goal” is a special rule,
a rule with a positive termination condition. Finally
the “rule” should be added indirectly to handle differ-
ent types like: (1) semiotics of the game to describe
meanings and relationships for various symbols, (2)
gameplay to describe challenges and actions, (3) se-
quence of play for progression of activities, (4) the
already pointed out goal of the game, (5) some termi-
nation conditions and (6) meta rules about these rules
(Adams, 2010).
Rules, which describe “something” in this game
world, are semiotics of the game, especially their
symbols (Adams, 2010). The GameEngine will call
this symbols “game objects”. Whenever a rule de-
scribes something like an avatar for the player or an
item like a sword, which could be equipped by this
avatar, then this rule has to be implemented as a spe-
cialization of an abstract game object. In addition
to the semiotics of games, there is a need to real-
ize the other types of rules. One more element of
the meta model is our set of actions as a part of the
gameplay rules. Each game object can trigger a set
of possible actions, hereinafter called “game action”.
Combining game world, game object and game ac-
tion will create the first version of the abstract game
meta model. Figure 3 shows this abstract game meta
model and extends this by using an observer pattern
newAvatar(name : String) : Avatar
- x : int
- y : int
+ move(vector : Vector)
+ attack(target : int)
- id : long
1 0..n
Figure 4: Example model for a simple 2D game. The player
can control the avatar and attack other players.
and timer component. The observer pattern (Gamma
et al., 1994) helps to manage state changes as well
as special events. The timer is used to simulated the
model independently from user interactions.
In case of using a game logic which is based on the
previously defined meta model, the second step would
be the identification of significant elements to derive
an infrastructure. The simplified game logic shown
in Figure 4 will be used to describe requirements and
how to get to communication components.
4.1 Identify Communication Protocol
Figure 4 shows a game, where a player can con-
trol his avatar by moving in two dimensions, for ex-
ample by pressing the arrow keys on his keyboard.
To join this game, the player needs to create a new
avatar. To achieve victory points, the player need to
attack other avatars. In case of manually creating an
infrastructure-workflow as shown in Figure 5 based
on common MMOG architectures, the following steps
have to be done by developers:
1. Creating request objects to name the special re-
quest and define their individual parameters
2. Creating a handling description which will check
parameters, map them to match game logic re-
strictions, call the proper methods and creates a
response object
3. Creating a request receiver process and a mech-
anism to identify the requests and assign them to
the correct handling description and returns the re-
sults of this handling description
4. Creating response objects with parameters which
contains information about the result of a request
These steps can be used as an abstract general-
ization and can be found in many implementations
of request-response-based interfaces. The example
Generic and Distributed Runtime Environment for Model-driven Game Development
send request
send response
Figure 5: Abstract communication flow for message han-
model in Figure 4 requires three requests, three han-
dling descriptions and three responses to handle new
avatar, move and attack. In detail, the request to han-
dle a new avatar should contain a parameter name, the
request to handle moving should contain the avatar id
as well as the corresponding vector whereas finally
the request to handle the attack should contain the
avatar id as well as the target id. By using this exam-
ple two types of requests can be found: (1) requests
with context (move, attack) and (2) requests without
context (new avatar).
To derive requests from our example in Figure
4, we search for method signatures within the game
world to create requests without specific object con-
text as well as searching for methods within game ob-
jects for requests with specific object context. While
requests without context only use the parameters of
the signature, requests with context have to extend
this parameter list by using an identifier for this cor-
responding game object. Additionally, all related re-
sponses can be derived directly by using return values
of currently analysed method signatures.
Continuing this way it is possible to derivate han-
dling descriptions. Using parameters and return val-
ues to ensure the correctness of request parameters
and match them to the game logic by mapping data
type differences between request and method could
do this. Mapping of data types should be treatable,
because previously generated requests. Finally, the
call to the proper game logic method: in case of con-
textual calls, the handling description needs to use an
access point to find the game object by using the id. In
case of a request without context it would be enough
to use the instance of the world we are currently con-
nected and call the matching method. The result of
this contextual and context free call can be used to
create the response and should be returned.
To create a request receiver process and a mecha-
nism to identify the requests, it is important to collect
the generated elements. Because generating a tuple of
a request, response and handling description for each
necessary method in the example game logic, the re-
ceiver process should know the correct handling de-
scription for each request and the possible responses.
Figure 6 shows how to derive request, response and
handler in case of the new avatar method.
+ sequenceId : int
+ handle(call : i)
+ find(id : long, c : Class) : GameObject
name : String
instanceId : long
newAvatar(name : String) : Avatar
+ player : AvatarData
id : int
x : int
y : int
+ handle(call : NewAvatarRequest)
Figure 6: Model based derivation of communication related
elements by using thew new avatar method from Figure 4.
4.2 Identify Data Representation
In addition to identify requests, responses and han-
dlers, it is possible to use the game logic to generate
a generic data representation. As shown above, we
can derive all necessary communication elements. To
get a data stream, ready for transmission, we need a
method to serialize those elements.
One solution would be to use so called serializers.
Most of them produce XML or JSON based on previ-
ously annotated entities. In case of implementations
based on Java, those tools make heavy usage of less
performant reflection API (Oracle, ) calls. Using this
API help to interact with entities on abstract levels in-
stead of native method calls. Testing the performance
loss, in case of using the reflection API, can be done
by calling a method multiple times natively compared
to calls done with the reflection API, measuring ex-
ecution time and divide this by the number of itera-
tions. This test will show something around two, up
to three, times more time per reflection based method
call. Those reflection API calls are used by serial-
ization tools for attribute identification, reading meta
information, calling getters and setters and creating
new instances of data entities. Taking a plain Java se-
rialization, as reference, shows a significant raise of
serialization time in case of popular XML and JSON
tools as shown in Figure 7. Figure 7 shows simple en-
tities which encapsulates basic variable types as well
as complex entities with combinations of them. Each
entity is serialized multiple times by using the same
previously allocated space to avoid measurement er-
rors based on allocation processes. To speed up this
serialization process it is necessary to avoid reflection
based calls as much as possible. Additionally reduc-
ing string based operations would help to boost up
The GameEngine acts as a fully generative exe-
cution environment for game logics. In case of ab-
stracting communication for model-driven develop-
ment and hiding infrastructure it would be possible
to use more proprietary protocols. This enables the
GameEngine to use meta information free data repre-
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
time in ns
Java JAXB JSON GameEngine
Figure 7: Serialization time of different types of entities
with Java, JAXB for XML, JSON and GameEngine.
01FF 00FF 0200 0000 02FF 0000 01FF
x : int = 2
y : int = 511
Figure 8: Data transformation for entity with two integer
variables. Header contains a numeric namespace and a nu-
meric identifier for SomeObject. Attribute values will be
added after header in alphabetic order.
sentation. Each data stream starts with a little header
to identify the represented communication element by
using an numeric identifier, followed by a alphabeti-
cal order list of attribute values. Value will be en-
coded as they are, e.g. an attribute with 32 bit integer
type will be encoded as a big endian sorted 32 bit in-
teger. Figure 8 shows an example how to transform
a simple entity into data streams based on this idea.
To get a more save data handling a little checksum
is embedded in some data types. Figure 8 contains
an additional checksum integers and a checksum for
object ids.
To avoid reflection calls the GameEngine uses
code generators to create native serialization pro-
cesses for each previously identified communication
entity. Each process is a list of binary operations to
extract data from streams to entity instances or to ex-
tract data from entity instances to the data streams by
using native getter and setter calls as well as binary
operations for data transformation.
As shown in Figure 8 the runtime generative code
for mappings between stream and entity to avoid re-
flection based calls is faster than JAXB, JSON or
Java itself. Compairing complex data entities with
fixed and floating point numbers as well as booleans,
strings and sub entities result in 80 times faster trans-
formations. In general it is two times faster than na-
tive serialization in Java just by using code generators,
binary based data representation and communication
objects extracted from specific domain models with-
out losing abstraction level while programming. In
addition Figure 9 shows exactly the same entities used
in deserialization processes and again with faster run-
time than XML and JSON based solutions.
time in ns
Java JAXB JSON GameEngine
Figure 9: Deserialization time of different types of entities
with Java, JAXB for XML, JSON and GameEngine. The
runtime of of JAXB is 100 times slower than JSON and not
visible in this scale.
This method for entity transformation into data
streams could not be used in common development
processes easily. Required dependencies between
client and server implementation would result in a
high failure rate. However, approaches based on
model-driven development can be used to embed
much more performant ideas and could avoid those
failures by using generated elements in development
To run a game logic based on this idea the
GameEngine uses an architecture as shown in Fig-
ure 10 based on a reference architecture for a MMOG
(Chen et al., 2013). Our architecture contains al-
ready named components like game logic, game state
and message handling, but separates a controller from
message handling. The message handler manages
connections and (de-) serialization features while the
controller will handle requests by using the handling
descriptions. This modification is based on a Model-
View-Controller pattern to keep a cleaner separation
of components (Buschmann et al., 1996). The pre-
sented Figure shows the architecture for one single
game instance. The GameEngine itself comes as an
execution environment as shown in Figure 11 written
in Java by using well known specifications from the
Java Enterprise Edition (EE). The reason why Java
EE was chosen is because of its structured compo-
nents to implement services, business logic and ad-
ditional interfaces. Using this allows game develop-
ers to richly extend their games by using standardized
concepts to create additional services around their
game logic. Furthermore the game engine can offer
optional services to enable authentication, payment,
statistical and community services.
The main elements of our middleware are infras-
Generic and Distributed Runtime Environment for Model-driven Game Development
Message Handler
Message Handler
Game State
Game State
Game Logic
Controller I
Controller II
Figure 10: Architecture for a single game instance. Ele-
ments marked black could be generated by using the game
logic (Chen et al., 2013).
tructure, generator, translator, meta model and persis-
tence to realize the described idea as shown in Fig-
ure 11. The infrastructure can be compared to com-
mon socket implementations, which can be used in
Flash, WebSocket or binary mode. The mode for run-
ning a connection is switched dynamically by detect-
ing client specific characteristics.
The game manager handles game logics and of-
fers translator, generator and persistence features. In
case of adding new game logics, the manager will
create the corresponding game instance, analyses the
new game logic, creates the new public communica-
tion port and initialize the logic itself. Analyses and
derivations will be done directly after the start pro-
cess. Finally, logic and generated elements are pre-
pared, available and ready for use.
The translator is an internal component, used as a
runtime service or as a deployment service. In case of
JavaScript the translator can be used to dynamically
include the current client code version. Alternatively,
this component can also be used as a service while
deploying a new client version to embed the translated
code fragments directly.
The described concepts will work in theory as shown
above when using a compact game concept. Next
step would be to go through real scenarios, e.g. game
projects. These projects starts with a computation-
independent model (CIM), followed by a platform-
independent model (PIM) and finally moved to a plat-
form specific model (PSM) for a specific game logic
(Pastor et al., 2008). While moving through a PSM
the created game logic should extended by using the
provided meta model for game development as pre-
sented above. After all, adding the implementation of
the game logic and some client logic for visualization
and the game should be done. Initially we evaluate, if
Game 1
Game 2
Game n
UDP / TCP Sockets
Game Manager
Game Logic 1
Game Logic 2
Game Logic n
Figure 11: Global GameEngine view; our middleware can
handle multiple game logics at once, can offer services and
handles public client connections.
this concept is applicable and useable as well as whats
about the development savings.
6.1 Viechers
One of the first games created using the mentioned
GameEngine is Viechers, which is an evolution based
open world strategy game. The player controls a
horde of entities to collect resources, to breed his
critters, to evolve them and building a civilization
by placing constructions. The game idea of Viech-
ers was created in an early state of our middleware.
The logical core of this game is an independent game
domain model, which describes all entities and their
relations, e.g. the “viechers”, rocks and trees. This
logic is based on a game world, game objects and
a set of game actions for each object, e.g. breed-
ing, harvesting, feeding and sleeping. Because of
the early development state of the GameEngine, re-
quest and response objects as well as the handling
descriptions were created manually. The main goal
of this project was a proof of concept to validate the
theoretical base in a real game project and evaluate
requirements to have an executable example. Fur-
thermore this game was released to public to test
the GameEngine performances in real-world condi-
tions. The client is written in ActionScript and the
client-side communication layer is translated from
server code by using our proprietary code generators
as described above. Because of this finallized, com-
plex MMOG and the manually written components
we could measure, which elements would have the
most effort. The analysed costs were separated into
game logic, request/responses, handling descriptions
and infrastructure. Figure 12 shows a high load for in-
frastructure, requests/responses and handling descrip-
tions. The goal would be to avoid this development
parts in future.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
Requests / Responses
Figure 12: Measurements to show how many line of codes
each part of Viechers uses. There is a overall number of
about 100kloc (without implementations for visualization).
6.2 Stickman Project
Stickman, as another game, was the first one using
the game engine as intended. This game is about a
simple stickman running in a 2D adventure to fight
against other players. The goal of this project was
to show that the GameEngine can handle game logic
implementations based on the meta model without
additional development efforts for infrastructure and
communication. However, this is an ActionScript
based game, but in this case the client code is trans-
lated from previously derived communication objects.
In relation to Figure 12, the infrastructure is part of
our middleware. Handlers, request and responses are
derivated from the Stickman game logic. Analysing
client code shows savings of 75 % comparing vi-
sual and infrastructural implementations. The server
on the other hand handles 11 different types of re-
quests, one of them is implemented manually. Each
request has its own request data object and all requests
together utilizes just five different response objects.
One of those response object is generated from server
code, the other one are implemented as simple data
objects with approx. three attributes. Getting objec-
tive measurements requires an additional implemen-
tation of this project with fully manually written com-
munication and controller layer, which is currently
not done. However, the project itself shows the appli-
cableness and a working game idea without any kind
of communication handling just object oriented han-
dling of entities within the Stickman game logic.
6.3 Independent Game Projects
Next step is to involve independent developers for
evaluating the middleware within their ideas. In this
case four student groups, approx. three experimentees
per group, create and implemente their own game by
using the GameEngine: Prevolution, Terra Life Evo-
lution, HackNSlay Adventure and Kokusnussbikini.
All projects had to follow a real development pro-
cess starting with preproduction phase, going through
production and alpha phase and end up with beta
phase (Claypool and Lindeman, 2008). Teams had
to start with their idea, without any knowledge about
our middleware, as well as creating their game re-
lated sketches. This included requirement analysis,
creating of use cases as well as first drafts of their
game logic with UML tools for class diagrams. Fur-
thermore, these steps are handled without knowledge
about our middleware. After that, the implementation
phase started. Teams got an introduction to our mid-
dleware and get their training about how to use the
API in combination with their created game logics.
Prevolution is a prequel for Viechers by using the
current version of the GameEngine. The player con-
trols single-cell organisms and tries to evolve them by
swimming around in the tide pool. The client is writ-
ten in Java, so translation is unnecessary. This project
helps to test and evaluate a pure Java implementation
for server and client as well.
Terra Life Evolution is about a classical role-
playing concept with modifications to handle the skill
development. Central scene of this game project is a
world separated in islands, which again are separated
into several areas. The player starts in a constant area,
with matching enemies to manage their first steps,
perform quests and improve experience to get skills.
The Hack’N’Slay Adventure is a round-based
concept where players have to manage defending a
centralized object and protect this one against on-
rushing enemy troops. The game starts with a lobby,
where players were put into teams. Each team starts
with an instantiated map to defend the centralized ob-
ject. After ten rounds of onrushing enemy troops the
game is over, depending on survivors the player teams
wins or loses the match.
The last one, Kokosnussbikini, is based on an
open-world-survival idea. This game describes a
generic world for players to move, defend, collect re-
sources and place objects. The client uses an isomet-
ric visualization to show player and landscape.
These four projects have shown that it is possi-
ble to develop browserbased MMOGs by following
classical development processes and avoiding devel-
opment overhead for infrastructure and communica-
tion by using our meta model for their game logic.
In relation to Figure 12, none of these projects have
any kind of socket implementation, neither any line of
code to define request or response objects or to handle
them. Also there is no additional effort to handle dif-
ferent client and server languages. Furthermore, these
projects gave a closer look at the following problems:
Challenging differences between coding lan-
guages, for example the syntax for getter and set-
ter. Currently the GameEngine matches them as
good as possible by using the syntax from Java
copied to other languages. The opposite would be
to use the client side language syntax for them,
Generic and Distributed Runtime Environment for Model-driven Game Development
which could lead to problems in finding the cor-
rect spelling.
Another problem is related to missing mecha-
nism for synchronous calls on the GameEngine
in ECMA based scripting languages (for exam-
ple JavaScript or ActionScript). To manage this
language specific behavior, the GameEngine gen-
erates additional parameters in method signatures
for success and failure callbacks.
JavaScript does not distinguish between byte,
short, integer, long, float or double. The
GameEngine middleware tries to address these re-
strictions, however, it may lead to inaccuracies. In
normal cases, this will not affect the development.
This paper describes the idea of extracting infrastruc-
tural components from implemented game logics by
using model-driven engineering methods and to eval-
uate useablity and applicableness in realistic condi-
tions. Development can be focused on modeling the
game logic which means handling of symbols and re-
lationships between them. Furthermore, it is possible
to reduce infrastructural implementation efforts dra-
matically, which reduces testing and raises overall sta-
bility by using an adaptive and generic execution en-
Using model-driven engineering in a highly ab-
stracted framework in addition to code generators, en-
ables usage of proprietary mechanisms hidden inside
a middleware. They could boost internal critical com-
ponents without any need to get a developer in touch
with it. They just use their own modeled and imple-
mented entities within server and client.
So far there is a working middleware to de-
velop games based on this idea as shown in indepen-
dent game projects, mostly location-based Browser-
MMOGs. In future work this project aims at compar-
ing game logic implementations. Using at least one
of them in combination with a manually constructed
communication layer would give a brief insight about
the percentage of savings.
We would like to thank all members at the Depart-
ment of Computer Science here at FSU Jena espe-
cially Wilhelm Rossak. We would also like to extend
our gratitude to Bernd Weigel and all students here at
FSU Jena about their contributions in different kinds
of game projects as well as the GameEngine itself.
Adams, E. (2010). Fundamentals of Game Design. New
Riders, Berkeley, 2nd edition.
Apel, S., Schau, V., and Rossak, W. (2014). Er-
probung von generischen Kommunikations- und
Verwaltungsinfrastrukturen in modelgetriebenen En-
twicklungsprozessen bei ortsbasierten MMOGs. In
11. GI/KuVS-Fachgespr
ach ”Ortsbezogene Anwen-
dungen und Dienste”, volume 11. in press.
Bharambe, A. R., Pang, J., and Seshan, S. (2006). Colyseus:
A distributed architecture for interactive multiplayer
games. In NSDI ’06: 3rd Symposium on Network De-
sign and Implementation, San Jose, California, USA.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,
and Stal, M. (1996). A System of Patterns, Pattern -
Oriented Software Architecture. Wiley, 1 edition.
Chen, Q., Galiullin, A., and Woo, J. (2013). A reference
architecture for multiplayer online games.
Claypool, M. and Lindeman, R. W. (2008).
Game development timeline. Internet, imgd1001/a08/slides/imgd100
1 04 GameDevTimeline.pdf, visited 2015-10-21.
Elektrotank., visited 2014-09-
Exit Games., visited 2015-
Exit Games. Mmo concept. Internet, http://doc.photonen
concept, visited 2015-10-21.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
(1994). Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley Profes-
sional, 1 edition.
gotoAndPlay()., visited
gotoAndPlay() (2011). SmartFoxServer 2X
Zones and Rooms Architecture. Internet,
room-architecture, visited 2015-10-21.
Gregory, J. (2009). Game Engine Architecture. A K Pe-
ters/CRC Press, Boca Raton.
Oracle. Trail: The reflection api., visited
Pastor, O., Espa
na, S., Panach, J. I., and Aquino, N.
(2008). Model-driven development. Informatik Spek-
trum, 31(5):394–407.
Rollings, A. and Morris, D. (2004). Game Architecture and
Design: A New Edition. New Riders, Indianapolis.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development