UgameFeature: Automatic Code Generation for Unity Game Projects

Joshua Kritz

, Mart de Roos

, Lu

ıs Ferreira Pires

, Jo

ao Luiz Rebelo Moreira

and Giancarlo Guizzardi

Faculty of Electrical Engineering, Mathematics and Computer Science, University of Twente, Enschede, The Netherlands

Keywords:

Model-Driven Engineering, Automatic Code Generation, Unity, Game Software.

Abstract:

Computer games are complex software systems, which means that their development requires some level of

programming skills. However, their design also involves the creation of game objects (characters, scenarios,

etc.), animations and story lines, which are designed by game domain experts, who in general have minimal

(or no) programming skills. Game engines have been developed to facilitate game development by reducing

programming efforts and enhancing productivity, but we observed that most of these engines still require

programming skills in order to be used. In this paper, we discuss how Model-Driven Engineering technologies,

particularly metamodelling and model transformations, can be used to facilitate game development. We deﬁne

a Domain Speciﬁc Language called UGameFeature to be used by game designers to deﬁne games that can be

automatically transformed into scripts that can be executed by the Unity game engine. In order to facilitate

the code generation step, we deﬁned an intermediate metamodel, so that structural differences between the

UGameFeature metamodel and the Unity engine scripts can be accommodated by an intermediate model-

to-model transformation. We claim that with this approach we could deﬁne a streamlined process to go from

game design to game implementation, in this way surpassing the beneﬁts already offered by game engines. We

also discuss some practical obstacles of applying MDE techniques and give recommendations to practitioners

who want to apply them in their projects.

1 INTRODUCTION

The game industry has been growing in the last years,

providing a total revenue of over US$ 170 billion in

2020 (Wijman, 2021), and attracting a lot of com-

mercial interest. Computer games are complex soft-

ware systems, which require some level of program-

ming skills in order to be produced. However, their

development also involves some creative design in

which game objects (characters, scenarios, etc.), an-

imations and story lines are deﬁned. These tasks

are often performed by game designers with artistic

skills, but minimal or no programming skills. This

means that the game design and programming tasks

should somehow be separated from each other, simi-

larly to how HTML/CSS and programming languages

like JavaScript and Java are used in web applications

to separate layout from functionality, respectively.

https://orcid.org/0000-0002-6661-6292

https://orcid.org/0000-0001-5551-4488

https://orcid.org/0000-0001-7432-7653

https://orcid.org/0000-0002-4547-7000

https://orcid.org/0000-0002-3452-553X

Games engines have been developed lately to fa-

cilitate game development by reducing programming

efforts and enhancing productivity. These engines

provide most of the code necessary to implement

games, and some of them do not require any pro-

gramming by supporting visual languages to describe

game objects and events, like Construct

or Stencyl

However, industry still favours more robust and ma-

ture engines that demand some programming skills,

like Unity

and Unreal

(Toftedahl, 2021). Unity is

the most popular engine amongst novice developers,

and therefore in this paper we use it as a game imple-

mentation platform.

This paper presents an approach based on Model-

Driven Engineering (MDE) technologies to facilitate

game development on top of the Unity game en-

gine. Using MDE will provide both a way to ab-

stract from programming language constructs and to

generate code (semi-)automatically (Brambilla et al.,

https://www.construct.net/en

https://www.stencyl.com/

https://unity.com/

https://www.unrealengine.com/en-US/

Kritz, J., de Roos, M., Pires, L., Moreira, J. and Guizzardi, G.

UgameFeature: Automatic Code Generation for Unity Game Projects.

DOI: 10.5220/0010990000003119

In Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2022), pages 371-378

ISBN: 978-989-758-550-0; ISSN: 2184-4348

371

2017). We deﬁned a Domain-Speciﬁc Language

(DSL) called UGameFeature that allows game de-

signers to deﬁne their games in terms of game compo-

nents without having to worry about implementation

(programming) issues. We also deﬁned an interme-

diate metamodel that represents the facilities of the

C#-based scripting language supported by Unity. The

structural differences between UGameFeature and the

scripting language have been accommodated by a

model-to-model transformation that we have also de-

ﬁned. Finally, we deﬁned a model-to-text transforma-

tion that generates game scripts that can be executed

by the Unity engine. This approach makes it possi-

ble to go from game design to game implementation

through a chain of automated steps, with potential

productivity beneﬁts. This paper also discusses the

practical obstacles of performing these steps and give

recommendations to practitioners who want to apply

MDE techniques in their projects.

This paper is further structured as follows: Sec-

tion 2 describes the methodology applied in this work,

by introducing the artefacts and techniques, Section 3

presents and justiﬁes the metamodels we developed,

Section 4 discusses our transformations, Section 5

discusses the transformation chain obtained by com-

bining the metamodels and the transformations and

how this transformation chain has been validated,

Section 6 discusses some related work and Section 7

gives our conclusions and identiﬁes topics for future

work.

2 METHODOLOGY

This work has originated from a project that has been

performed by a group of Master students of a Model-

Driven Engineering course. This project has aimed at

developing an initial solution to offer proper abstrac-

tions to game designers and at the same time auto-

mate code generation. Our goal has been to support

the most relevant abstractions and to produce playable

games as prototypes, not complete game products.

Our solution starts with a model of a game and

generates code that can be executed by the Unity en-

gine. To achieve this, we developed the following

artefacts:

• The UGameFeature Domain Speciﬁc Language

(DSL) that allows game designers to describe

games. Since this is a simple proof-of-concept

only the UGameFeature metamodel has been fully

deﬁned, which means that the concrete syntax of

this DSL has been ignored.

• The GameProgram metamodel that serves as an

intermediary component between the game design

and the game implementation.

• The U2P model-to-model transformations be-

tween the UGameFeature models (source) and the

GameProgram models (target).

• The M2T model-to-text transformation that gen-

erates the Unity script code from GameProgram

models.

This project has been implemented using the

Eclipse modelling tools. Both metamodels have been

speciﬁed using the Ecore tools in the Eclipse Mod-

eling Framework, the model-to-model transformation

has been written in the QVT Operational Mappings

language and the model-to-text transformation has

been written in Acceleo. Each artefact has been prop-

erly tested before being integrated in the ﬁnal solu-

tion.

Figure 1 shows the transformation chain of the

project. A UGameFeature model that is an instance

of the UGameFeature metamodel is given as input to

the U2P model-to-model transformation, which gen-

erates a GameProgram model that is an instance of

GameProgram metamodel. The GameProgram model

is then used as input to the model-to-text transforma-

tion, which generates code in the scripting language

supported by Unity.

Each artefact of our solution is further dis-

cussed in the remaining sections. These artefacts

can be found at https://gitlab.utwente.nl/m7700446/

ugamefeature-mde.

3 METAMODELS

This section presents and justiﬁes the metamodels de-

ﬁned in this work.

3.1 UGameFeature Metamodel

Although some game design languages already exist,

as far as we could observe they are too close to the

programming level, so they are difﬁcult to understand

by game designers with limited programming skills.

This inspired us to deﬁne the UGameFeature DSL,

which we discuss here in terms of its metamodel.

UGameFeature metamodel has been deﬁned to

represent actions and components. Two main goals

have guided the deﬁnition of the UGameFeature lan-

guage elements: we should be able to deﬁne the most

basic games, like e.g., ’Super Mario’, using this lan-

guage, and the language should be easy to use by

game designers, i.e., the language should be intu-

itively appealing to them.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

372

Figure 1: Transformation chain.

The main metaclasses of this language are

GameObject, GUIelement and DataManager. A

GameObject in a game can be used to represent the

player, the enemies, the stage and everything that is

part of the game world. A DataManager contains

Data elements, which are the global information con-

cerning the game, like lives and scores, which are

used in all types of games. A GUIelement is not nec-

essary, but it is usually paired with a Data object to

show information to the player.

We also represent the actions of the game, which

are the global game events that are not necessarily

triggered by the player. In our metamodel, we de-

ﬁned basic actions like the creation and destruction of

objects, addition of force to an object, and changes

to global variables. A Movement encapsulates actions

that allow the objects to move. Two types of move-

ments have been deﬁned, namely platformer and top-

down. A Collision is deﬁned in a game object and

can trigger an action. Figure 2 shows only the most

important metaclasses of the UGameFeature meta-

model, while the complete metamodel has 22 meta-

classes.

Figure 2 shows that a GameObject can perform

different types of actions, which can be distinguished

by how they are related to the GameObject element.

There are four alternatives, namely, through collision

triggers, as a start or update relation, or via an Ac-

tionKey. Start and Update are methods of the Unity’s

Monobehaviour class, where start deﬁned the actions

to be executed when the object is created and up-

date deﬁnes actions executed in every frame of the

game. A collision trigger represents a contact be-

tween game elements, and it happens when an ob-

ject touches another speciﬁc object. Finally, the Ac-

tionKey represents the traditional player interaction in

which a player presses a button and something hap-

pens. In order to test the UGameFeature metamodel,

we represented a simpliﬁed version of ’Super Mario’

and a Mineﬁeld game with this metamodel by using

the Sample Ecore Model editor. We concluded that

the UGameFeature metamodel was suitable for repre-

senting the main aspects of these games.

UgameFeature is still preliminary. Its metamodel

allows the deﬁnition of only small number of games

with limited features. In addition, there is the design

limitation that different GameObjects and different

components cannot reference each other in any way.

However, in our tests we designed complete games

with objects that interact with each other and showed

that it is possible to work around this limitation.

3.2 GameProgram Metamodel

The GameProgram metamodel has been deﬁned to

capture the C# main programming concepts. Figure 3

shows the most important metaclasses of the Game-

Program metamodel, while the complete metamodel

has 20 metaclasses. Although it has been inspired by

the scripting language supported by Unity, the Game-

Program metamodel was deﬁned to be as indepen-

dent as possible of any speciﬁc platform, so that it

could be used to model any program written in a C#-

based scripting language like the language supported

by Unity.

Program is the root metaclass of this metamodel.

A program consists of many Files, which in turn con-

tain Namespaces, which deﬁne programming scopes.

Inside a namespace, InternalTypes can be deﬁned,

which can be either a Class, Struct, Interface, Enum or

Delegate. Each InternalType can be assigned to func-

tionality in a speciﬁc way. For example, a Contain-

ment may contain members, functions and construc-

tors. In case a Containment is a Class, it can extend a

superclass.

To denote types not deﬁned in the program rep-

resented by the model, the program can also refer

to external types, which are imported from some

namespace and have an identiﬁer. This allows classes

and interfaces to be imported, extended, and imple-

mented.

In order to test the GameProgram metamodel, we

represented the Unity scripts for the simpliﬁed ’Su-

per Mario’ and Mineﬁeld games as instances of this

metamodel, and translated these models initially by

hand to the actual Unity scripts. We concluded that

UgameFeature: Automatic Code Generation for Unity Game Projects

373

Figure 2: UGameFeature metamodel.

the GameProgram metamodel was suitable for rep-

resenting the main programming aspects required to

implement these games.

4 TRANSFORMATIONS

This section discusses the transformations developed

in this project.

4.1 U2P Model-to-Model

Transformation

The intermediate (GameProgram) metamodel was in-

troduced to represent the programming concepts of

a C#-based runtime environment, like the one sup-

ported by the Unity engine. This means that a

model-to-model transformation had to be developed

to solve the structural differences between the source

(UGameFeature) and target (GameProgram) meta-

models, while incorporating some implementation

details.

Although the GameProgram metamodel is quite

general in its representation of programming con-

cepts, the U2P model-to-model transformation has

been heavily centered around the support offered by

Unity. This has been necessary since the result-

ing GameProgram model should match the capabil-

ities supported by the Unity engine in order to be

executable. The transformation was deﬁned using

the QVT Operational Mapping transformation lan-

guage (Object Management Group, 2016). Figure 4

shows the outline of the transformation in the Eclipse

Overview. The transformation consists of 8 map-

pings, 3 helpers, 3 queries and 9 properties.

In this transformation, each UGameFeature model

is transformed into one GameProgram model, which

has a program as root element. Due to our use of

Unity, we needed to create external types (as proper-

ties) for the native types of the Unity Engine names-

pace. Each game element (GameObject, GUIEle-

ment, or DataManager) of the source model is trans-

formed into a File and a Class in the target model.

Members and methods of a target class are created

based on the game actions and game components of

the element represented by the class. Each action or

component can create many members, but the meth-

ods are usually already present from the MonoBe-

haviour structure extended by the game classes and

so they only modify the body of their related meth-

ods. Methods are deﬁned from the same relations

that bring about the action types. Methods start and

Update are both native methods for MonoBehaviour

classes, and the collision methods are created by col-

lision objects. From the action types, only ActionKey

does not deﬁne its own methods, since it only extends

the existing update method with an if statement. The

processing of the components that only modify meth-

ods was done using helpers. For example, the code in

Figure 5 represents the transformation of a UGame-

Feature Data into a get Method, to be included in the

DataManager Class.

We debugged and tested our transformation with

the models used to test the metamodels mentioned

in Section 3, which means that we applied the U2P

transformation to the UGameFeature model of the

simpliﬁed Super Mario and mineﬁeld games, and

compared the results with the GameProgram models

of these games, respectively. In this way, after all er-

rors were removed, we conﬁrmed that the target mod-

els generated by the U2P transformation indeed cor-

respond to the intended ones, showing that the trans-

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

374

Figure 3: GameProgram metamodel.

Figure 4: U2P model-to-model transformation outline.

formation has been correctly implemented.

4.2 Code Generation

At this point, the GameProject model that represents

a game program still needs to be serialised in terms of

Figure 5: M2M from Data to Method.

Figure 6: M2T from Method to code.

script code in order to be executed by the Unity en-

gine. In order to obtain this script code, we deﬁned

a model-to-text transformation written in Acceleo

which is an Eclipse-based code generation tool. Ac-

celeo is therefore a proper match for the other arte-

facts developed in this project, particularly the Game-

Program metamodel deﬁned using Ecore.

Our Acceleo model-to-text transformation gener-

ates script code for the GameProgram model elements

according to a template. Since the GameProgram

metamodel is conceptually very close to the program-

ming concepts of the runtime platform, this transfor-

mation ended up being quite straightforward. For ex-

ample, the code in Figure 6 is the template that trans-

form the Method class into code.

https://www.eclipse.org/acceleo/

UgameFeature: Automatic Code Generation for Unity Game Projects

375

Once the model-to-text transformation was devel-

oped, the ﬁnal step of the transformation chain could

be tested. This has been done by generating code

from the GameProgram models of the simpliﬁed Su-

per Mario and Mineﬁeld games and importing the re-

sulting code into Unity projects. This procedure has

been used to debug the transformation, until no errors

remained. Therefore these tests also served as a proof

of concept for our transformation chain. The code

generated with our model-to-text transformation uses

some speciﬁc features of the Unity Engine, show-

ing that the generated program is compatible with the

Unity platform.

We are aware that these test procedures are

not comprehensive, however we made sure children

Game Objects and Prefabs could be used without

problems. Since these are powerful capabilities, by

enabling them in the code generation step we al-

low game developers to use some rather sophisticated

Unity capabilities.

5 RESULTS

The ﬁnal application was obtained by integrating the

metamodels and transformations in a single transfor-

mation chain. Although we have not produced a fully

encapsulated application that encompasses the whole

transformation chain, we rely on the Eclipse facilities

to perform the automated steps of the transformation

chain.

To use our application, a game designer needs to

deﬁne a model of a game using UgameFeature. Since

we refrained from deﬁning a concrete syntax, this

model needs to be produced using the Ecore EMF ed-

itor. The deﬁnition of a concrete syntax is an obvious

necessary improvement of the application, but it has

been neglected for the time being since we were more

interested in demonstrating the core of the transfor-

mation chain (the metamodels and transformations).

A game designer can then execute the U2P trans-

formation on the game model in an Eclipse QVT

OM project, producing in this way the GameProgram

model. This can be done by running a QVT Opera-

tion Transformation Run Conﬁguration in Eclipse that

triggers the transformation with proper input and out-

put models.

Once the GameProgram model is obtained, the

game designer can run the Acceleo transformation

that is deﬁned in an Eclipse Acceleo project by using

an Acceleo Application Run Conﬁguration that runs

Acceleo with the template to generate script code us-

ing the GameProgram model as input. Alternatively,

we could use Acceleo’s facilities to trigger transfor-

mations using an Ant build or a Maven script. Since

both transformations have been deﬁned in the same

platform, even if we have two separate projects for

each transformation, respectively, the Acceleo project

can refer to the output of the QVT OM project re-

sult. This means that it is not necessary to copy the re-

sulting GameProgram model from one project to the

other. It would be convenient to have this transfor-

mation streamlined within an one-click application,

however we have not tried that as we focused on the

core of the transformation chain.

Once the ﬁles with script code have been gener-

ated with Acceleo, the last step is to import them into

a Unity project. The scripts have to be associated

to the GameObjects while also adding the necessary

components to match the restrictions described in the

model, i.e., having a RigidBody or collision boxes.

The game designer should keep notes of the names of

objects, and more importantly, the tags of those ob-

jects as they are usually referenced in the code, since

using names that do not match the names used in the

model will lead to errors. This step creates a game in

Unity as it was initially modelled by the designer.

Figure 7 shows a screenshot of a Unity project

to which the code generated with our transformation

chain has been imported. This project shows the sim-

pliﬁed Super Mario game that we used to test the fea-

tures of the project. The game designer deﬁned the

four game objects shown in the screen (wizard, bat,

ghost, and amoeba) along with some game actions by

instantiating the UGameFeature metamodel. Later,

with the game scripts generated, the game designer

can conﬁgure the speciﬁc type of the game objects,

e.g., the wizard as Character and the others as Enemy.

At the bottom of the Unity IDE are the scripts gen-

erated by our project (Bullet, Character, etc.) and at

the left side, under SampleScene are the game objects

that were modeled. This game is playable and works

as intended, and has been generated without writing a

single line of scripting code.

This project had some practical obstacles, the

most notables were with the game metamodel and

implementation choice. Concerning the game meta-

model, it was challenging to deﬁne which of the game

components were both necessary and sufﬁciently sim-

ple for creating games. Balancing those character-

istics is an important factor when designing an ab-

stract game metamodel. Concerning the implemen-

tation choices, we had the obstacle that many of the

game features can be implemented in different ways,

and determining the most suitable implementation for

the automated creation was not simple. These chal-

lenges are the most stringent ones, not only for MDE

application in game development, but for MDE-based

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

376

Figure 7: Unity project of the simple Super Mario game example.

projects in any application domain.

Although our approach presents an abstraction of

the programming part of a game engine, the UGame-

Feature metamodel to be used by game designers was

inspired by the elements of the Unity game engine.

One clear future direction is to deﬁne an even more

abstract metamodel that can be conceived in collab-

oration with game developers, possibly through the

development of a reference ontology of games. In

addition, the development of metamodels of other

game engines, along with the transformations to/from

UGameFeature, can enable not only the code gener-

ation for the speciﬁc engines, but also facilitate the

interoperability among them.

6 RELATED WORK

In this section, we discuss some related work that

aimed at facilitating game programming by applying

MDE. The recent literature review on Model-Driven

Game Development (MDGD) (Zhu and Wang, 2019)

identiﬁes over 30 initiatives, and classiﬁes them into

some categories. The ’Use game engines or equiv-

alent software’ category is the most relevant for us,

which covers four approaches based on Unity as main

tooling environment. Although the approach for de-

veloping serious games with Unity (Aouadi et al.,

2016) introduces an interesting DSL, it is oriented to

pedagogical experts, representing concepts like ludic

resources and activities. Another approach for devel-

oping serious games that uses Unity (Matallaoui et al.,

2015) extends the Gamiﬁcation Modeling Language

and provides transformations for JSON. Although it

is a relevant work and generates ’ready-to-use’ code

(for an intermediary application), it only uses Unity

as a study case and is oriented to gamiﬁcation rather

than gaming. The other two approaches are superﬁ-

cial and do not present implementation details.

GAMESPECT (Geisler, 2019) is a DSL with

aspect-oriented programming features that supports

game-speciﬁc DSLs, also providing a framework to

assist game engine users to balance their games.

This work overlaps with our approach in the attempt

to automatically generate code to assist the devel-

opers of a speciﬁc engine (Unreal Engine 4), thus

limiting the scope to this engine. Similarly, the

Domain-Speciﬁc Game Development approach (Fur-

tado, 2012) proposes a model-driven development

methodology meant to allow game developers to ef-

ﬁciently develop games by applying software product

lines, which enables the generation of games from the

same ’family’. Differently from our approach, both

approaches aim at assisting experienced developers,

in contrast to novice ones.

The MDGD approach presented in (do Prado and

Lucredio, 2015) combines multiple DSLs with design

patterns to provide ﬂexibility and code generation in-

tegrated to manual coding for game developers. Al-

though it has a purpose similar to ours, the major dif-

ference is that their application needs to be combined

with manually created code, not removing the need

to program, which has been our main goal. Another

closely related work is the Casanova DSL (Abbadi

et al., 2015; Abbadi, 2017; Di Giacomo, 2018), which

was created to reduce the cost for developing games,

making coding easier for game developers. However,

this approach still offers a programming language that

requires its users (game designers) to write programs.

We observed that each of these initiatives reported

UgameFeature: Automatic Code Generation for Unity Game Projects

377

a positive impact on the productivity of game devel-

opment by using MDE. The main difference from our

approach is that they have aimed at assisting devel-

opers to obtain safer and better code, whilst our main

goal has been to abstract from programming issues so

that game designers are able to create games without

the need of writing any code.

7 CONCLUSIONS

MDE-based game development is not novel. The

main difference of our approach to others is that we

offer an abstraction of game programming aiming

at assisting novice game designers in creating their

games, without the need of changing the generated

code. Although this work is limited to the scope of

game development for the Unity engine, the results

presented here offer ample opportunities for reusabil-

ity, since we believe that they can be easily ported to

other engines and/or development methods. There-

fore, this approach has also potential for facilitating

interoperability of game engines.

In this paper, we claim that MDE can enable game

development without any manual code implementa-

tion, and that MDE allows faster creation of games.

Further, we argue that the UgameFeature DSL is sim-

ple enough for novice users to understand, yet use-

ful enough to represent simple games. Although in

this project we showed that this DSL allows the rep-

resentation of some popular (simple) games, future

work should include a usability evaluation with pro-

fessional game developers.

UgameFeature has limitations and its metamodel

should be improved to address them. The most im-

portant is the metamodel simplicity, as it allows to

model only a limited number of games. For example,

right now it is not possible to model multiple levels,

changing scenarios or animations. An improved ver-

sion of this language with these capabilities will allow

designers to model more elaborated games.

Alternatively, one could deﬁne an even more ab-

stract metamodel with concepts that are not neces-

sarily inspired by game engines, but in collaboration

with game developers, possibly through the develop-

ment of a game ontology. Instances of this ontology

could then be transformed to models that can be used

to generate code that runs in some game engine, as

the UGameFeature metamodel that allows the game

to be implemented in Unity. This discussion leads

to a more fundamental question in MDE, which is

how to determine the number of intermediary mod-

els that are required to transform an abstract model

that is sufﬁciently close to the ’world of the domain

expert’ (game designer in this work) to the most con-

crete code that can be executed in some runtime envi-

ronment.

REFERENCES

Abbadi, M. (2017). Casanova 2, A domain speciﬁc lan-

guage for general game development. PhD thesis.

Abbadi, M., Di Giacomo, F., Cortesi, A., Spronck, P.,

Costantini, G., and Maggiore, G. (2015). Casanova:

A simple, high-performance language for game devel-

opment. In Joint International Conference on Serious

Games, pages 123–134. Springer.

Aouadi, N., Pernelle, P., Ben Amar, C., Carron, T., and Tal-

bot, S. (2016). Models and mechanisms for imple-

menting playful scenarios. In 2016 IEEE/ACS 13th In-

ternational Conference of Computer Systems and Ap-

plications (AICCSA), pages 1–8.

Brambilla, M., Cabot, J., and Wimmer, M. (2017). Model-

Driven Software Engineering in Practice. Morgan &

Claypool Publishers, 2nd edition.

Di Giacomo, F. (2018). Metacasanova: a high-

performance meta-compiler for domain-speciﬁc lan-

guages. PhD thesis.

do Prado, E. F. and Lucredio, D. (2015). A ﬂexible

model-driven game development approach. In 2015

IX Brazilian Symposium on Components, Architec-

tures and Reuse Software, pages 130–139.

Furtado, A. W. B. (2012). Domain-Speciﬁc Game Develop-

ment. PhD thesis.

Geisler, B. (2019). GAMESPECT: A Composition Frame-

work and Meta-Level Domain Speciﬁc Aspect Lan-

guage for Unreal Engine 4. PhD thesis, Nova South-

eastern University.

Matallaoui, A., Herzig, P., and Zarnekow, R. (2015).

Model-driven serious game development integration

of the gamiﬁcation modeling language gaml with

unity. In 2015 48th Hawaii International Conference

on System Sciences, pages 643–651.

Object Management Group (2016). Meta Object Facility

(MOF) 2.0 – Query/View/Transformation speciﬁca-

tion. Standard formal/2016-06-03, Object Manage-

ment Group.

Toftedahl, M. (2021). Which are the most commonly used

game engines? Available on the site https://www.

gamedeveloper.com/.

Wijman, T. (2021). Global games market to generate $175.8

billion in 2021. Available on the site https://newzoo.

com/.

Zhu, M. and Wang, A. I. (2019). Model-driven game de-

velopment: A literature review. ACM Comput. Surv.,

52(6).

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

378