# MEnDiGa: A Minimal Engine for Digital Games

Authors: Filipe M. B. Boaventura; Victor T. Sarinho
Journal: International Journal of Computer Games Technology
 (2017)

---

## Abstract

Game engines generate high dependence of developed games on provided implementation resources. Feature modeling is a technique that captures commonalities and variabilities results of domain analysis to provide a basis for automated configuration of concrete products. This paper presents the Minimal Engine for Digital Games (MEnDiGa), a simplified collection of game assets based on game features capable of building small and casual games regardless of their implementation resources. It presents minimal features in a representative hierarchy of spatial and game elements along with basic behaviors and event support related to game logic features. It also presents modules of code to represent, interpret, and adapt game features to provide the execution of configured games in multiple game platforms. As a proof of concept, a clone of theDoodle Jumpgame was developed using MEnDiGa assets and compared with original game version. As a result, a newG-factor based approach for game construction is provided, which is able to separate the core of game elements from the implementation itself in an independent, reusable, and large-scale way.


---

## Body

## 1. Introduction

Game engines allow game developers to reuse significant portions of key software components [1]. A game engine is defined as “extensible software that can be used as the foundation for many different games without major modification” [1] and represents “the collection of modules of simulation code that do not directly specify the game’s behavior (game logic) or game’s environment (level data)” [2].Although game engines are reusable across multiple game projects, they generate high dependence of the game on implementation resources provided by the chosen engine [3]. Referring collectively to game logic, object model, and game state elements asG-factor, BinSubaih and Maddock [3] provided a service-oriented based architecture able to separate the core of game objects from the implementation itself and to support the game portability among game engines.As an attempt to identify commonalities and variabilities in the digital game domain, Sarinho and Apolinário [4] proposed theNarrative,Entertainment,Simulation, andInteraction(NESI) feature model. It is a feature-based approach capable of representing theG-factor according to game concepts found in the literature. Sarinho and Apolinário also proposed theGameSystem,DecisionSupport, andSceneView (GDS) feature model [5], which is based on game features that describe generic configurations and behavioral aspects found on game implementation resources identified in the literature. GDS was also used as a reference model to a proposed generative approach of digital games, showing as a result the feasibility of using features in the production of concrete digital games [5].Although NESI and GDS models represent digital games without relying on the structure of game engines, the large number of proposed features became a difficulty in the design of small and casual games such as platform, quiz, or maze games [6]. This difficulty was confirmed during the production of theSimplifiedPacMan version [5] using Feature-based Environment for Digital Games (FEnDiGa) [7], a game production environment based on a combined representation of NESI and GDS features via Object Oriented Feature Modeling (OOFM) approach [8].This paper presents theMinimal Engine for Digital Games (MEnDiGa), an extensible collection of representative classes based on a simplified set of NESI and GDS features that can be used as the foundation for small and casual games without major modification. MEnDiGa also provides a collection of modules of code for the interpretation and adaptation processes of represented features that do not directly specify the game’s behavior or game’s environment.This paper is organized as follows. Section2 describes important papers related to game domain engineering and game feature modeling. Section 3 presents the proposed MEnDiGa feature model and the resulting framework [9] with representative classes and modules of code. Section 4 describes the development steps to provide aDoodle Jump clone using MEnDiGa assets. Section 5 presents the software metrics analysis forDoodle Jump game versions. Finally, Section 6 presents the conclusions and future work of this project.


## 2. Related Work

Many types of reusable approaches have been applied in game development in recent years. They can simplify and accelerate the production of gaming systems, focusing on game modeling artifacts, digital game components, game product lines, and reusable aspects in game development, for example.Considering the usage of software components on game development, Folmer [10] stated that developers could reuse specific game components to reduce the cost of building games. Folmer [10] also proposed a Reference Architecture for digital games as an attempt to possibly identify areas of reuse.Zhang and Jarzabek [11] proposed the RPG Product Line Architecture (RPG-PLA), a group of common and variable features of four distinct RPG games. As a result, any of the original RPGs as well as similar ones could be derived from feature configurations interpreted by the RPG-PLA.Albassam and Gomaa [12] proposed the use of Software Product Lines (SPL) in the video games domain. They have built a feature dependency model to describe the variability in multiplatform video games (such as different input/output devices, user interface, and CPU) and a variable component-based SPL suited for any video game in the product line.Furtado et al. [13] proposed an improvement of the SharpLudus project [14], replacing the previous ad hoc approach with a customized DSM approach called Domain-Specific Game Development. In this approach, feature models are used to improve the domain vocabulary and to help the identification of specific subdomains of the SPL domain.Müller [15] presented the DGiovanni project, an open-source multiagent architecture for building interactive dramas. It makes use of ontologies to support the creation of different stories and to feed the system with story-related information.Finally, Machado et al. [16] proposed a generic representation to model virtual agents in digital games. It allows the implementation of adaptable behaviors for game agents according to different features of the game environment. Agents are modeled using a linear combination of different variables, which are used to represent specific game features.


## 3. The Minimal Engine for Digital Games (MEnDiGa)

This section presents the proposed MEnDiGa feature model, based on a simplified collection of NESI and GDS features, and the resulting framework, based on representative classes and modules of code able to work with MEnDiGa features. Together, they can configure, represent, perform, and adapt feature specifications of digital games according toG-factor portability for distinct game platforms.


### 3.1. MEnDiGa Feature Model

Originally presented by Kang et al. [17] as part of the Feature Oriented Domain Analysis (FODA), feature modeling allows the identification of system properties during the domain analysis. According to them, a feature model represents “thestandardfeatures of a family of systems in the domain, and the relationships between them,” and features are “aspects or characteristics of a domain which are visible to the user.”Following the feature modeling perspective to identify similarities or differences between the products of a product line [18], MEnDiGa presents digital games as collections of three main features:Spatial,Behavior, andObserver(Figure 1).Figure 1
MEnDiGa feature diagram.Regarding theSpatial feature, it is a collection ofNode features that represent the elements of the game.Spatial feature can be also anEnvironment feature with a collection ofLocation features. EachNode feature contains aCurrentLocationfeature to determine its current position in a game. EachNode feature also has aBoundingVolume feature to delimit the collision detection space.Node features can also containAudioNode,GraphicNode, andPhysicsNodefeatures, likeSceneNode feature from GDS model [5].TheAudioNodefeature represents information about sound effects to be used later in a digital game. It holds the path to an audio file that contains the desired sound effect or background music.AudioNode can also contain information about the state of the audio file and its play mode (normal orlooping).GraphicNode feature represents configurations related to the graphical modeling of a certainNode feature. As a simpleText feature, it holds information about the font and the alignment to draw a string. As aSprite feature, it holds information related to how a texture, or even a region of a texture, should be rendered. Various regions of the same texture can be used to compose animations. As aCamera feature, it contains information about theviewport of aSpatial.ThePhysicsNode feature contains the physical attributes of aNodefeature, such as itsdensity,mass, andrestitution coefficient. It also allows the setting of some constraints for physical simulation, such as the amount ofgravity that acts on theNode feature and whether it issolid or not.Element features are specializations ofNode features. They contain one or morePropertyfeatures represented with identifiernames and representativevalues (Speed: 50 m/s;Life: 2 lives). AnElementthat is responsible for userBehaviors is defined as aPlayerfeature.Playerbehaviors (Jump andCrouch, for instance) are related to default commands (MOVE_UP, MOVE_DOWN, etc.) defined on itsControlMap feature.Observerfeatures are responsible for performingBehavior features according to the evaluation of monitored resources. For instance, anInputObserver feature can be set to evaluate the command activation from an input device, executing the relatedBehavior feature of thePlayer after firing it. As another example, aCollisionObserver feature can trigger the execution of anIncreaseScoreBehavior feature when thePlayer collides with an item or execute aLoseLifeBehavior feature when it collides with an enemy.


### 3.2. MEnDiGa Framework

According to Czarnecki [19], a proposed feature model can be used to define a set of classes capable of configuring various software systems. It is the project stage of a software domain [20], whose objective is to represent a feature value in each instantiated class based on a derived framework from the associated feature model.In this sense, a collection of classes was proposed to represent, interpret, and adapt feature configurations derived from MEnDiGa feature model. The resulting framework was organized according to the following list of packages and classes (Figures2 and 3):(i)
Spatials: represents the collection of spaces and game elements usingSpatial, Environment, andNode classes(ii)
Nodes:defines specializations and internal components of theNode class, such asAudioNode,GraphicNode,BoundingVolume,Element, andPlayer classes(iii)
Locations:defines internal components of anEnvironment usingLocation,Map, andPosition classes(iv)
Behaviors: defines the abstract classBehavior able to be specialized in actions to be performed by a game(v)
Observers: defines abstract structures (Observer,InputObserver,CollisionObserver, andCollisionGroupObserver) to handle fired events in a game(vi)
Adapters: declares concrete classes able to render MEnDiGa objects in distinct game platformsFigure 2
Package diagram of the MEnDiGa framework.Figure 3
Classes and type hierarchies of the MEnDiGa framework.As the main class of the MEnDiGa framework,GameSession (Figure 3) has the responsibility of integrating theSpatial,Observer, andBehavior objects derived from the proposed MEnDiGa features. TheSpatial object contains a collection ofNode instances, such asAudioNode,GraphicNode,PhysicsNode,BoundingVolume, andLocation instances. TheElement class extends theNode class, including a collection ofProperty instances represented in aHashMap structure. ThePlayer class has been defined as anElement subclass. It contains a control map with a collection ofBehavior instances related to player commands. TheEnvironmentclass was also defined as aSpatial specialization. It contains a collection oflocationsobjects such asMap andPositioninstances (the game space).For eachObserverinstance, there is a collection ofBehavior instances. They are executed according to theObserverevaluation approach programmed for each possible event of a game. EachBehavior instance is programmed to execute a determined game action, modifying attributes inNodeinstances and changing the currentSpatialinstance of theGameSession instance in each renderization cycle of the game.Considering theadapters classes, they are responsible for the execution of the instantiated MEnDiGa objects using implementation resources of a chosen game platform. For each worked game platform, a new set of adaptation classes is modeled only once for the first game, allowing theG-factor portability of other MEnDiGa games for the same game platform.


## 3.1. MEnDiGa Feature Model

Originally presented by Kang et al. [17] as part of the Feature Oriented Domain Analysis (FODA), feature modeling allows the identification of system properties during the domain analysis. According to them, a feature model represents “thestandardfeatures of a family of systems in the domain, and the relationships between them,” and features are “aspects or characteristics of a domain which are visible to the user.”Following the feature modeling perspective to identify similarities or differences between the products of a product line [18], MEnDiGa presents digital games as collections of three main features:Spatial,Behavior, andObserver(Figure 1).Figure 1
MEnDiGa feature diagram.Regarding theSpatial feature, it is a collection ofNode features that represent the elements of the game.Spatial feature can be also anEnvironment feature with a collection ofLocation features. EachNode feature contains aCurrentLocationfeature to determine its current position in a game. EachNode feature also has aBoundingVolume feature to delimit the collision detection space.Node features can also containAudioNode,GraphicNode, andPhysicsNodefeatures, likeSceneNode feature from GDS model [5].TheAudioNodefeature represents information about sound effects to be used later in a digital game. It holds the path to an audio file that contains the desired sound effect or background music.AudioNode can also contain information about the state of the audio file and its play mode (normal orlooping).GraphicNode feature represents configurations related to the graphical modeling of a certainNode feature. As a simpleText feature, it holds information about the font and the alignment to draw a string. As aSprite feature, it holds information related to how a texture, or even a region of a texture, should be rendered. Various regions of the same texture can be used to compose animations. As aCamera feature, it contains information about theviewport of aSpatial.ThePhysicsNode feature contains the physical attributes of aNodefeature, such as itsdensity,mass, andrestitution coefficient. It also allows the setting of some constraints for physical simulation, such as the amount ofgravity that acts on theNode feature and whether it issolid or not.Element features are specializations ofNode features. They contain one or morePropertyfeatures represented with identifiernames and representativevalues (Speed: 50 m/s;Life: 2 lives). AnElementthat is responsible for userBehaviors is defined as aPlayerfeature.Playerbehaviors (Jump andCrouch, for instance) are related to default commands (MOVE_UP, MOVE_DOWN, etc.) defined on itsControlMap feature.Observerfeatures are responsible for performingBehavior features according to the evaluation of monitored resources. For instance, anInputObserver feature can be set to evaluate the command activation from an input device, executing the relatedBehavior feature of thePlayer after firing it. As another example, aCollisionObserver feature can trigger the execution of anIncreaseScoreBehavior feature when thePlayer collides with an item or execute aLoseLifeBehavior feature when it collides with an enemy.


## 3.2. MEnDiGa Framework

According to Czarnecki [19], a proposed feature model can be used to define a set of classes capable of configuring various software systems. It is the project stage of a software domain [20], whose objective is to represent a feature value in each instantiated class based on a derived framework from the associated feature model.In this sense, a collection of classes was proposed to represent, interpret, and adapt feature configurations derived from MEnDiGa feature model. The resulting framework was organized according to the following list of packages and classes (Figures2 and 3):(i)
Spatials: represents the collection of spaces and game elements usingSpatial, Environment, andNode classes(ii)
Nodes:defines specializations and internal components of theNode class, such asAudioNode,GraphicNode,BoundingVolume,Element, andPlayer classes(iii)
Locations:defines internal components of anEnvironment usingLocation,Map, andPosition classes(iv)
Behaviors: defines the abstract classBehavior able to be specialized in actions to be performed by a game(v)
Observers: defines abstract structures (Observer,InputObserver,CollisionObserver, andCollisionGroupObserver) to handle fired events in a game(vi)
Adapters: declares concrete classes able to render MEnDiGa objects in distinct game platformsFigure 2
Package diagram of the MEnDiGa framework.Figure 3
Classes and type hierarchies of the MEnDiGa framework.As the main class of the MEnDiGa framework,GameSession (Figure 3) has the responsibility of integrating theSpatial,Observer, andBehavior objects derived from the proposed MEnDiGa features. TheSpatial object contains a collection ofNode instances, such asAudioNode,GraphicNode,PhysicsNode,BoundingVolume, andLocation instances. TheElement class extends theNode class, including a collection ofProperty instances represented in aHashMap structure. ThePlayer class has been defined as anElement subclass. It contains a control map with a collection ofBehavior instances related to player commands. TheEnvironmentclass was also defined as aSpatial specialization. It contains a collection oflocationsobjects such asMap andPositioninstances (the game space).For eachObserverinstance, there is a collection ofBehavior instances. They are executed according to theObserverevaluation approach programmed for each possible event of a game. EachBehavior instance is programmed to execute a determined game action, modifying attributes inNodeinstances and changing the currentSpatialinstance of theGameSession instance in each renderization cycle of the game.Considering theadapters classes, they are responsible for the execution of the instantiated MEnDiGa objects using implementation resources of a chosen game platform. For each worked game platform, a new set of adaptation classes is modeled only once for the first game, allowing theG-factor portability of other MEnDiGa games for the same game platform.


## 4. Case Study: A Doodle Jump Clone

A clone of the Doodle Jump game was developed to demonstrate the feasibility of producing games with MEnDiGa assets. The MEnDiGa version is based on a Doodle Jump clone called Super Jumper, developed using the LibGDX game framework [21]. Designed to faithfully reproduce the Super Jumper version, the MEnDiGa clone was developed using the same textures and audio files from the original game. It also presents a similar set of features in comparison with the original game.This section presents an explanation of the Super Jumper development process, showing the necessary configuration, implementation, and adaptation steps to provide a MEnDiGa game. For the configuration step, it illustrates some identified Super Jumper features according to proposed MEnDiGa feature model. The implementation step presents developed classes and source codes based on designed MEnDiGa framework which represent structural and dynamics aspects of the Super Jumper game. Finally, the adaptation step describes developed classes able to interpret MEnDiGa objects and perform the Super Jumper game execution using LibGDX resources.


### 4.1. Super Jumper Configuration

According to Super Jumper game, the players must guide Bob (the playable character) to the end of the level. Bob must bounce on platforms to reach the castle, at the top of the game world. Along the way, Bob can collect coins for points and hit springs to jump higher. There are also obstacles, such as crumbling platforms and flying squirrels. The game ends in victory when Bob reaches the castle or defeat if he collides with a squirrel or falls of a platform.For the MEnDiGa version, each screen of the Super Jumper game is represented usingSpatial configurations, where each one holds an appropriate set ofNode features. APosition feature contains the Cartesian coordinates of aNode instance, and it is used to locate nodes in aSpatial feature.Position also holds depth information used to define the overlapping between images onSpatial. Figure 4 illustrates this descriptive mapping among Super Jumper game elements andSpatialsubfeatures for the Super Jumper game.Figure 4
Spatial subfeatures for the Super Jumper game.Figure5 shows theSpatial configuration of the main menu screen. Each option in the main menu, as well as any clickable object in the game, is represented usingNode features. These clickable nodes hold an appropriateGraphicNode feature (Sprite orText), as well as a rectangularBoundingVolume feature to determine the clickable area.BackgroundNode and theTitleNode features are simply placeholders for the background and title of the game.Figure 5
Main menu screen and respectiveSpatial configuration.Figure6 also shows the game world represented by theWorldSpatial feature. This spatial configuration containsNode features that build the game level as a whole. Since platforms and squirrels need thespeed property,Platform andSquirrel subfeatures of theElement feature are used to represent them.Bob, thePlayer character represented as a feature, also contains a property for holdingscore information. Stationary objects such asCoins, Springs, and theCastle are modeled as subfeatures of theNode feature.Figure 6
Spatial configuration of the gameplay screen.WhenBobreaches theCastle at the end of the level, theEndingSpatial feature is used to display the game’s ending. Figure 7 showsBob and thePrincess having a conversation in front of theCastle. TheMessageNode feature contains theGraphicNode feature responsible for displaying the line of the dialog. Clicking anywhere on the screen will advance to the next message or return the game to the main menu when the last message is displayed.Figure 7
Ending screen and respectiveSpatial configuration.Regarding the support of MEnDiGa game events, there is a series of collision events among the Super Jumper game elements and thePlayer feature itself that must be monitored. Figure 8 illustrates someObserver features configured to be responsible for this collision detection and player monitoring during the game execution. There are alsoObservers features dedicated to monitoring interactions with the user interface components, such as clicks on the screen and button press.Figure 8
Observer subfeatures for the Super Jumper game.The actions responsible for changingSpatial feature values are represented usingBehavior features, such asPlayer commands (MOVE_UP, MOVE_LEFT, etc.) or game dynamics (increase/decrease score, win/lose game, etc.). Figure 9 presents some of theseBehaviorfeatures, showing game dynamics that were implemented in the MEnDiGa version. It is noteworthy thatObserver features will activate suchBehavior features upon confirmation of a monitored event (ex.:BUTTON1_PRESS →JUMP).Figure 9
Behavior subfeatures for the Super Jumper game.


### 4.2. Super Jumper Implementation

By the definition of Super Jumper game features, the next step consists of representing the Super Jumper configuration according to the MEnDiGa framework hierarchy. In this sense,Node subclasses are used to represent the characteristics ofSpatial components, such as startingPosition,Element properties, andGraphicNode instances.In case ofSprite objects used to representGraphicNode instances in the game, it is necessary to define the desired region of the image that will be shown. If this information is omitted, the whole image will be used. For each selected region in the image, it will contain subregions calledframes, where each one will have the size set on theSpriteNode constructor (Algorithm 1). Each frame can be referenced using an index number (Figure 10). Animations are composed using selected frames to be rendered and their respectiveframe delay value (the amount of time that a frame will remain on the screen).Algorithm 1:Setting up the GraphicNode of the playable character.
// Create the graphic node
SpriteNode
graphicNode = new
SpriteNode
("bob", // sprite name
"res/superjumper/ite
ms.
png", // source file path
3
2,
3
2); // width and height of a single fra
m
e within the sheet
// Select a rectangular region of the texture
graphicNode
.s
et
R
egio
n
(0, 12
8
, // Upper left corner position
160,
3
2
)
; // region width and height
// Defining animations
graphicNode.
defi
n
e
Animation
(
"jump", // Animation name
new int
[
]
0,
1
,
0
.2f,
// Animations frame and frame delay
PlayMode.
LOOP_NO
RMAL
)
;
//
P
lay mode
graphicNode.setCur
rent
Animation("jump")
; // Set
"
ju
m
p
"
as the current animation
graphicNode.
setScale(l/32f)
; // Set the scale as 32 pixels per game unit
this.add
G
raphicNode(graphicNode); // Add the sprite to the n
o
deFigure 10
The highlighted region is extracted from the texture, according to theGraphicNode configuration.Regarding Super Jumper game dynamics, theSuperJumperGame class extends theGameSession class to “configure” the game (Algorithm 2). This class is programmed to instantiateAudioNode feature values, initial game observers to start the game, and respective game behaviors to perform the game initialization. After this, theSuperJumperGame executes theChangeToMainMenuScreen behavior (Algorithm 2) to prepare theMainMenuSpatial (Figure 5) to be displayed and start up the game.Algorithm 2:Partial description of the SuperJumperGame class.
public class SuperJumperGame extends GameSession
public static enum
Ga
me
Sta
t
e
RUNNING
,
PAUSED
,
READY
,
WIN
private GameState
ga
m
eSta
t
e;
private AudioN
o
de
[
]
audioN
o
des;
public SuperJumperGame()
// Configuring AudioNodes
this.audioN
o
des = new AudioN
o
de
[
]
new AudioN
o
de("coinSound", "res/superju
m
per/coin.wav"), //
⋯
new AudioN
o
de("gameMusic", "re
s
/super
j
umper/music.mp3"
)
;
// Configuring Observers
this.addObserver(new CheckForNewHighScore(this));
this.addObserver(new CheckGameOver(this));
// Configuring
B
ehaviors
this.addBehavior("changeToMenu", new ChangeToMainMenuScreen(this));
this.addBehavior("generateLevel", new GenerateLevel(this));
this.add
B
ehavior("createHud", new CreateHud(this));
this.
add
B
ehavior
(
"resetBob", new ResetBob
()
);
this.
add
B
ehavior
(
Ga
m
eState.
RUN
N
I
N
G
.
toString
()
, new UpdateRunning
(this
)
);
this.
add
B
ehavior
(
"endGame", new
EndGame
(this
)
);
this.add
B
ehavior("playClickSound", new PlayClickSound(this));
public void initialize()
this.get
B
ehavior("changeToMenu").execute(); // load the game menu
this.getAudioN
o
de
(
MUSIC
).se
t
S
t
ate(State.
PLAYING
);
public void update(float deltaTime)
// Perform the current Running Behavior if the game still running
if (this.gameState.equals
(GameState
.
RUNNING
))
this.get
B
ehavior(this.gameState.toString()).execute(deltaTime);
//
⋯When the player selects the“Play” option on the created main menu, theClickNodeObserver instance executesReadyGame behaviors (Figure 9).ReadyGame, in turn, executes theGenerateLevel behavior, which is responsible for creating and randomly placing the platforms, springs, coins, and squirrels on theWorldSpatial instance. With theWorldSpatialpopulated,ReadyGame behavior calls theResetBob behavior, putting theBob object in the initial state before inserting it into theWorldSpatialinstance. TheCreateHud behavior is executed next, creating theHUDSpatial instance that holds the necessaryNode instances for theHead-Up Display.ReadyGame behavior also sets the observers and behaviors required for the gameplay, such as theInputObserver instance to controlBob, the game collision observers and related behaviors, the behaviors to update node values during the gameplay, and the game observers to check for high score updates and game over events.UpdateNode behaviors (Figure 9) are also executed for each generated frame in the game. They update the state of dynamic game elements based on defined game configurations and player inputs. TheUpdateSquirrel and theUpdatePlatform behaviors are set to change thePosition ofSquirrel andPlatform instances according to theirspeed Property value. If aPlatform instance is set to crumble, theUpdatePlatform behavior is responsible for updating the countdown timer for the platform destruction.UpdateBob behavior changes the playerPosition usinggravity andhorizontal speed values.UpdateHighscore behavior is activated by theHighscoresObserver when the game ends after falling down the screen or hitting an enemy/castle, changing the score ranking if the player has enough points.BobCollisionObserverinstances are responsible for evaluating collision events among the player character and eachNode instance inWorldSpatial. They fire appropriateResolveCollision behaviors (Figure 9) if the player’sBoundingVolume intersects anotherNode instance. Some of these observers only trigger collisions on specific situations. For example,Bob instance can pass throughSpring andPlatform objects from below, butResolveCollision behaviors must be performed ifBob hits them from above.Bob/Coin collisions destroy the collidedCoin instance and increase thescore Property value. Collisions betweenBob instance and thePlatform orSpring instances increase its jumpingspeed. However, hitting aPlatform instance may cause it to crumble, destroying it after a crumbling animation is complete. Hitting aSquirrel will trigger theEndGame behavior, showing a“Game Over” message on theHUDSpatial instance asBob goes down through the screen. After clicking anywhere on the screen when the game is over, it will notify theJustClickedObserver instance to trigger theChangeToMainMenuScreen behavior. Hitting theCastle instance will trigger theChangeToEndingScreen behavior, completing the play through.


### 4.3. Super Jumper Adaptation

In a similar strategy to FEnDiGa [7], the next and final step consists of applying Super Jumper instances to use MEnDiGa adapters. Such adaptation classes establish an integration pattern between game configurations with implementation resources of a chosen game platform.LibGDX has been used in this project as a target game engine to provide MEnDiGa adapter classes. It is an open-source framework which presents good market acceptance to produce multiplatform Java games. Among LibGDX available adapters,SpatialRenderer, GraphicNodeRenderer, andInputAdapter should be highlighted.For eachSpatial instance on theSuperJumperGame, aSpatialRenderer needs to be created. It is responsible for loading and rendering specified settings of eachGraphicNode object available in aSpatial. It also follows the rendering order of theGraphicNode instances according to the informed depth (z-axis of thePosition) on eachNode instance.For eachGraphicNode instance to be rendered, a specificGraphicNodeRenderer object is created based on theGraphicNode type.TextNodeRenderer uses the information on aText GraphicNodeinstance to set up LibGDX’s Bitmap Font utilities, loading an image file containing the glyphs and a font file to provide image characters.SpriteNodeRenderer uses the information stored on aSprite GraphicNode instance to load the desired image file as a LibGDXTexture object. This texture is split and its frames are stored in an array, allowing the image usage as shown in Figure 10. In the adaptation process, the animation information defined in theGraphicNode instance is used to createAnimations, LibGDX objects capable of managingSprite animations.TheInputAdapter is the class responsible for notifying theInputObserver about input events. It implements theInputProcessor, an interface provided by LibGDX to receive input events from the keyboard, touchscreen, or mouse. TheInputAdapter has anadaptedControlMap structure that makes the correspondence amongPlayer commands (MOVE_LEFT, MOVE_RIGHT, etc.) and the LibGDX constants for input keys. If the pressed/released key corresponds with somePlayer command, theInputAdapter notifies the fired/released command to theInputObserver that performs the appropriateplayerBehavior according to the configured game dynamics.SuperJumperLibGDX performs the final adaptation among MEnDiGa assets and the LibGDX engine. It implements theApplicationListener interface of the LibGDX, which contains the methods called during the game lifecycle such ascreateandrender.SuperJumperLibGDXoverrides thecreate method to instantiateSuperJumperGame and the other neededadapters during the application launching. Associations amongObserver instances of theSuperJumperGame and the packageadapter (InputAdapter, for instance) are also configured during the creation of theSuperJumperLibGDX. Therender method is also being overridden to continuallydraw the respectiveSpatialRenderer and evaluate monitoring aspects ofObserver instances.In the end, after theSuperJumperLibGDX execution, LibGDX starts the initialization, rendering and updating processes of adapted MEnDiGa assets, displaying as a result the configured Super Jump game to be played. As MEnDiGa is an open-source project, more details about the LibGDX adaptation process can be found at https://bitbucket.org/fmbboaventura/mendiga (master branch).


## 4.1. Super Jumper Configuration

According to Super Jumper game, the players must guide Bob (the playable character) to the end of the level. Bob must bounce on platforms to reach the castle, at the top of the game world. Along the way, Bob can collect coins for points and hit springs to jump higher. There are also obstacles, such as crumbling platforms and flying squirrels. The game ends in victory when Bob reaches the castle or defeat if he collides with a squirrel or falls of a platform.For the MEnDiGa version, each screen of the Super Jumper game is represented usingSpatial configurations, where each one holds an appropriate set ofNode features. APosition feature contains the Cartesian coordinates of aNode instance, and it is used to locate nodes in aSpatial feature.Position also holds depth information used to define the overlapping between images onSpatial. Figure 4 illustrates this descriptive mapping among Super Jumper game elements andSpatialsubfeatures for the Super Jumper game.Figure 4
Spatial subfeatures for the Super Jumper game.Figure5 shows theSpatial configuration of the main menu screen. Each option in the main menu, as well as any clickable object in the game, is represented usingNode features. These clickable nodes hold an appropriateGraphicNode feature (Sprite orText), as well as a rectangularBoundingVolume feature to determine the clickable area.BackgroundNode and theTitleNode features are simply placeholders for the background and title of the game.Figure 5
Main menu screen and respectiveSpatial configuration.Figure6 also shows the game world represented by theWorldSpatial feature. This spatial configuration containsNode features that build the game level as a whole. Since platforms and squirrels need thespeed property,Platform andSquirrel subfeatures of theElement feature are used to represent them.Bob, thePlayer character represented as a feature, also contains a property for holdingscore information. Stationary objects such asCoins, Springs, and theCastle are modeled as subfeatures of theNode feature.Figure 6
Spatial configuration of the gameplay screen.WhenBobreaches theCastle at the end of the level, theEndingSpatial feature is used to display the game’s ending. Figure 7 showsBob and thePrincess having a conversation in front of theCastle. TheMessageNode feature contains theGraphicNode feature responsible for displaying the line of the dialog. Clicking anywhere on the screen will advance to the next message or return the game to the main menu when the last message is displayed.Figure 7
Ending screen and respectiveSpatial configuration.Regarding the support of MEnDiGa game events, there is a series of collision events among the Super Jumper game elements and thePlayer feature itself that must be monitored. Figure 8 illustrates someObserver features configured to be responsible for this collision detection and player monitoring during the game execution. There are alsoObservers features dedicated to monitoring interactions with the user interface components, such as clicks on the screen and button press.Figure 8
Observer subfeatures for the Super Jumper game.The actions responsible for changingSpatial feature values are represented usingBehavior features, such asPlayer commands (MOVE_UP, MOVE_LEFT, etc.) or game dynamics (increase/decrease score, win/lose game, etc.). Figure 9 presents some of theseBehaviorfeatures, showing game dynamics that were implemented in the MEnDiGa version. It is noteworthy thatObserver features will activate suchBehavior features upon confirmation of a monitored event (ex.:BUTTON1_PRESS →JUMP).Figure 9
Behavior subfeatures for the Super Jumper game.


## 4.2. Super Jumper Implementation

By the definition of Super Jumper game features, the next step consists of representing the Super Jumper configuration according to the MEnDiGa framework hierarchy. In this sense,Node subclasses are used to represent the characteristics ofSpatial components, such as startingPosition,Element properties, andGraphicNode instances.In case ofSprite objects used to representGraphicNode instances in the game, it is necessary to define the desired region of the image that will be shown. If this information is omitted, the whole image will be used. For each selected region in the image, it will contain subregions calledframes, where each one will have the size set on theSpriteNode constructor (Algorithm 1). Each frame can be referenced using an index number (Figure 10). Animations are composed using selected frames to be rendered and their respectiveframe delay value (the amount of time that a frame will remain on the screen).Algorithm 1:Setting up the GraphicNode of the playable character.
// Create the graphic node
SpriteNode
graphicNode = new
SpriteNode
("bob", // sprite name
"res/superjumper/ite
ms.
png", // source file path
3
2,
3
2); // width and height of a single fra
m
e within the sheet
// Select a rectangular region of the texture
graphicNode
.s
et
R
egio
n
(0, 12
8
, // Upper left corner position
160,
3
2
)
; // region width and height
// Defining animations
graphicNode.
defi
n
e
Animation
(
"jump", // Animation name
new int
[
]
0,
1
,
0
.2f,
// Animations frame and frame delay
PlayMode.
LOOP_NO
RMAL
)
;
//
P
lay mode
graphicNode.setCur
rent
Animation("jump")
; // Set
"
ju
m
p
"
as the current animation
graphicNode.
setScale(l/32f)
; // Set the scale as 32 pixels per game unit
this.add
G
raphicNode(graphicNode); // Add the sprite to the n
o
deFigure 10
The highlighted region is extracted from the texture, according to theGraphicNode configuration.Regarding Super Jumper game dynamics, theSuperJumperGame class extends theGameSession class to “configure” the game (Algorithm 2). This class is programmed to instantiateAudioNode feature values, initial game observers to start the game, and respective game behaviors to perform the game initialization. After this, theSuperJumperGame executes theChangeToMainMenuScreen behavior (Algorithm 2) to prepare theMainMenuSpatial (Figure 5) to be displayed and start up the game.Algorithm 2:Partial description of the SuperJumperGame class.
public class SuperJumperGame extends GameSession
public static enum
Ga
me
Sta
t
e
RUNNING
,
PAUSED
,
READY
,
WIN
private GameState
ga
m
eSta
t
e;
private AudioN
o
de
[
]
audioN
o
des;
public SuperJumperGame()
// Configuring AudioNodes
this.audioN
o
des = new AudioN
o
de
[
]
new AudioN
o
de("coinSound", "res/superju
m
per/coin.wav"), //
⋯
new AudioN
o
de("gameMusic", "re
s
/super
j
umper/music.mp3"
)
;
// Configuring Observers
this.addObserver(new CheckForNewHighScore(this));
this.addObserver(new CheckGameOver(this));
// Configuring
B
ehaviors
this.addBehavior("changeToMenu", new ChangeToMainMenuScreen(this));
this.addBehavior("generateLevel", new GenerateLevel(this));
this.add
B
ehavior("createHud", new CreateHud(this));
this.
add
B
ehavior
(
"resetBob", new ResetBob
()
);
this.
add
B
ehavior
(
Ga
m
eState.
RUN
N
I
N
G
.
toString
()
, new UpdateRunning
(this
)
);
this.
add
B
ehavior
(
"endGame", new
EndGame
(this
)
);
this.add
B
ehavior("playClickSound", new PlayClickSound(this));
public void initialize()
this.get
B
ehavior("changeToMenu").execute(); // load the game menu
this.getAudioN
o
de
(
MUSIC
).se
t
S
t
ate(State.
PLAYING
);
public void update(float deltaTime)
// Perform the current Running Behavior if the game still running
if (this.gameState.equals
(GameState
.
RUNNING
))
this.get
B
ehavior(this.gameState.toString()).execute(deltaTime);
//
⋯When the player selects the“Play” option on the created main menu, theClickNodeObserver instance executesReadyGame behaviors (Figure 9).ReadyGame, in turn, executes theGenerateLevel behavior, which is responsible for creating and randomly placing the platforms, springs, coins, and squirrels on theWorldSpatial instance. With theWorldSpatialpopulated,ReadyGame behavior calls theResetBob behavior, putting theBob object in the initial state before inserting it into theWorldSpatialinstance. TheCreateHud behavior is executed next, creating theHUDSpatial instance that holds the necessaryNode instances for theHead-Up Display.ReadyGame behavior also sets the observers and behaviors required for the gameplay, such as theInputObserver instance to controlBob, the game collision observers and related behaviors, the behaviors to update node values during the gameplay, and the game observers to check for high score updates and game over events.UpdateNode behaviors (Figure 9) are also executed for each generated frame in the game. They update the state of dynamic game elements based on defined game configurations and player inputs. TheUpdateSquirrel and theUpdatePlatform behaviors are set to change thePosition ofSquirrel andPlatform instances according to theirspeed Property value. If aPlatform instance is set to crumble, theUpdatePlatform behavior is responsible for updating the countdown timer for the platform destruction.UpdateBob behavior changes the playerPosition usinggravity andhorizontal speed values.UpdateHighscore behavior is activated by theHighscoresObserver when the game ends after falling down the screen or hitting an enemy/castle, changing the score ranking if the player has enough points.BobCollisionObserverinstances are responsible for evaluating collision events among the player character and eachNode instance inWorldSpatial. They fire appropriateResolveCollision behaviors (Figure 9) if the player’sBoundingVolume intersects anotherNode instance. Some of these observers only trigger collisions on specific situations. For example,Bob instance can pass throughSpring andPlatform objects from below, butResolveCollision behaviors must be performed ifBob hits them from above.Bob/Coin collisions destroy the collidedCoin instance and increase thescore Property value. Collisions betweenBob instance and thePlatform orSpring instances increase its jumpingspeed. However, hitting aPlatform instance may cause it to crumble, destroying it after a crumbling animation is complete. Hitting aSquirrel will trigger theEndGame behavior, showing a“Game Over” message on theHUDSpatial instance asBob goes down through the screen. After clicking anywhere on the screen when the game is over, it will notify theJustClickedObserver instance to trigger theChangeToMainMenuScreen behavior. Hitting theCastle instance will trigger theChangeToEndingScreen behavior, completing the play through.


## 4.3. Super Jumper Adaptation

In a similar strategy to FEnDiGa [7], the next and final step consists of applying Super Jumper instances to use MEnDiGa adapters. Such adaptation classes establish an integration pattern between game configurations with implementation resources of a chosen game platform.LibGDX has been used in this project as a target game engine to provide MEnDiGa adapter classes. It is an open-source framework which presents good market acceptance to produce multiplatform Java games. Among LibGDX available adapters,SpatialRenderer, GraphicNodeRenderer, andInputAdapter should be highlighted.For eachSpatial instance on theSuperJumperGame, aSpatialRenderer needs to be created. It is responsible for loading and rendering specified settings of eachGraphicNode object available in aSpatial. It also follows the rendering order of theGraphicNode instances according to the informed depth (z-axis of thePosition) on eachNode instance.For eachGraphicNode instance to be rendered, a specificGraphicNodeRenderer object is created based on theGraphicNode type.TextNodeRenderer uses the information on aText GraphicNodeinstance to set up LibGDX’s Bitmap Font utilities, loading an image file containing the glyphs and a font file to provide image characters.SpriteNodeRenderer uses the information stored on aSprite GraphicNode instance to load the desired image file as a LibGDXTexture object. This texture is split and its frames are stored in an array, allowing the image usage as shown in Figure 10. In the adaptation process, the animation information defined in theGraphicNode instance is used to createAnimations, LibGDX objects capable of managingSprite animations.TheInputAdapter is the class responsible for notifying theInputObserver about input events. It implements theInputProcessor, an interface provided by LibGDX to receive input events from the keyboard, touchscreen, or mouse. TheInputAdapter has anadaptedControlMap structure that makes the correspondence amongPlayer commands (MOVE_LEFT, MOVE_RIGHT, etc.) and the LibGDX constants for input keys. If the pressed/released key corresponds with somePlayer command, theInputAdapter notifies the fired/released command to theInputObserver that performs the appropriateplayerBehavior according to the configured game dynamics.SuperJumperLibGDX performs the final adaptation among MEnDiGa assets and the LibGDX engine. It implements theApplicationListener interface of the LibGDX, which contains the methods called during the game lifecycle such ascreateandrender.SuperJumperLibGDXoverrides thecreate method to instantiateSuperJumperGame and the other neededadapters during the application launching. Associations amongObserver instances of theSuperJumperGame and the packageadapter (InputAdapter, for instance) are also configured during the creation of theSuperJumperLibGDX. Therender method is also being overridden to continuallydraw the respectiveSpatialRenderer and evaluate monitoring aspects ofObserver instances.In the end, after theSuperJumperLibGDX execution, LibGDX starts the initialization, rendering and updating processes of adapted MEnDiGa assets, displaying as a result the configured Super Jump game to be played. As MEnDiGa is an open-source project, more details about the LibGDX adaptation process can be found at https://bitbucket.org/fmbboaventura/mendiga (master branch).


## 5. Super Jumper Metrics Analysis

According to Pressman [22], product metrics help software engineers to visualize the design of the software, focusing on specific and measurable attributes of software engineering artifacts. In order to perform a comparative analysis and evaluate the quality of the produced digital game, a set of software metrics was collected from the original Super Jumper version and the respective cloned MEnDiGa version.Table1 presents the collected OO metrics of both games using the Eclipse Metrics plugin [23]. It provides metrics calculation and dependency analysis according toNumber of Classes, Number of Attributes, Number of Methods, Number of Static Attributes,Number of Static Methods,Number of Packages,Number of Overridden Methods,Average Number of Parameters,Total Lines of Code,Average Lines of Code per Method,Abstractness (A),Afferent Coupling (Ca),Efferent Coupling (Ce),Instability (I),Normalized Distance from Main Sequence (Dn),Lack of Cohesion of Methods (LOCOM),Average Nested Block Depth,Cyclomatic Complexity,Weighted Methods per Class (WMC), andDepth of Inheritance Tree (DIT).Table 1
OO metrics from original Super Jumper and cloned MEnDiGa version.
Metric property
Original Super Jumper
Cloned MEnDiGa version
Abstractness (
A
)
0,107
0,042
Afferent Coupling (Ca)
14,8
2
Depth of Inheritance Tree (DIT)
2,231
1,87
Efferent Coupling (Ce)
13
17
Instability (
I
)
0,41
0,895
Lack of Cohesion of Methods (LOCOM)
0,023
0,267
Cyclomatic Complexity
1,576
2,18
Average Lines of Code per Method
7,129
7,57
Average Nested Block Depth
1,242
1,6
Normalized Distance from Main Sequence (Dn)
0,483
0,064
Number of Attributes
44
90
Number of Classes
65
23
Number of Methods
131
94
Number of Overridden Methods
43
18
Number of Packages
5
1
Average Number of Parameters
0,856
0,64
Number of Static Attributes
41
72
Number of Static Methods
1
6
Total Lines of Code
1912
1310
Weighted Methods per Class (WMC)
208
218Number of Classes, Number of Attributes, Number of Methods, Number of Static Attributes, Number of Static Methods, Number of Packages, Number of Overridden Methods, Average Number of Parameters, Total Lines of Code, andAverage Lines of Code per Method are simple and straightforward metrics, with a detailed explanation about them being unnecessary.Abstractness (A) represents the ratio of the number of abstract classes and interfaces to the total number of classes in the selected scope. It varies from zero to one, with A = 0 indicating a completely concrete solution and A = 1 indicating a completely abstract solution.Afferent Coupling (Ca) indicates the number of classes outside of the selected package which depend on the classes inside the package [24]. It also indicates the level of responsibility of the given package.Efferent Coupling (Ce) indicates the number of classes inside a package which depend on classes from other packages [24].Instability (I) is obtained using Ce/(Ca+Ce). It indicates the level of instability of a package, where I = 0 indicates a completely stable package and I = 1 a completely unstable package [24].Normalized Distance from Main Sequence (Dn) is calculated using |A+I-1|. It measures how far away a package is from the idealized line A + I = 1, called the Main Distance [24]. The distance should be close to zero for packages with a good balance between stability and abstractness.Lack of Cohesion of Methods (LOCOM) is calculated using (M-sum(MF)/F)(M-1), where M is the number of methods in the class, F is the number of fields, MF is the number of methods accessing a particular field of the class, and sum(MF) is the sum of MF over all fields of the class. As a measure of the cohesiveness of a class, this metric is calculated using the Henderson-Sellers method [25]. A low LOCOM indicates a cohesive class, while a LOCOM close to 1 indicates lack of cohesion.Average Nested Block Depth indicates the average number of nested code blocks in the selected scope. Too many nested blocks lead to a more complex and less readable solution.Cyclomatic Complexity is used to identify the complexity of a piece of code based on the amount of execution flows [26]. It is the number of independent paths in the source code and it is calculated for methods only. High values of this metric imply a complex solution that can be difficult to understand.Weighted Methods per Class (WMC) is the sum of the complexity of all methods in the selected class [27] (for this work, the measure of complexity of methods is Cyclomatic Complexity). Classes with high WCM tend to be complex and hard to reuse.Depth of Inheritance Tree (DIT) is the maximum length from the class to the root of the inheritance tree [27]. Hierarchies of classes with high DIT can contribute to reuse because the deeper classes in the hierarchy inherit more methods. However, very deep trees tend to be more complex because there are more classes and methods involved [27].Analyzing the obtained metric results, it is possible to verify the following:(i)
Normalized Distance from Main Sequence (Dn),Afferent Coupling (Ca),Efferent Coupling (Ce), andInstability (I) show strong game dependency of the cloned version to MEnDiGa structures in contrast with original game version.(ii)
Abstractness (A), Depth of Inheritance Tree, Total Lines of Code, Number of Methods, Number of Static Methods, Average Number of Parameters, Number of Packages, Number of Classes, andNumber of Overridden Methods metrics confirm the structural simplification of the cloned version in comparison with the original version, despite a higherNumber of Attributes andNumber of Static Attributes.(iii)
Average Lines of Code per Method, Average Nested Block Depth, Cyclomatic Complexity, andWeighted Methods per Class (WMC) indicate a small increment in the complexity of game production with MEnDiGa.(iv)
Lack of Cohesion of Methods (LOCOM) presents a higher result in MEnDiGa version, something that can be explained due toBehavior andObserver classes created to configure and monitore other classes instead of itself.


## 6. Conclusions and Future Work

This paper presented MEnDiGa, a game engine proposal based on the simplification of the NESI and GDS feature models. For this, MEnDiGa provides a minimal collection of necessary features capable of designing small and casual games. MEnDiGa also provides an implementation framework that can be configured and performed according to game designer intentions. Together, these MEnDiGa artifacts are able to realize theG-factor portability followed by NESI and GDS models and provide a product line solution capable of buildingG-factor based games in large scale.Regarding the game platform portability, MEnDiGa assets were implemented and adapted to be interpreted using LibGDX game engine. Per FEnDiGa results [7] and by the production of respective adapter classes, it is possible to affirm that MEnDiGa structure is capable of being extended to additional Java game engines, such as jMonkeyEngine [28], JGame [29], and GTGE [30]. For other game platforms based on different types of programming languages, such as Unreal Engine 4 [31] that uses C++, it is necessary to reimplement MEnDiGa classes to the respective support language. To facilitate this conversion process among game engines based on distinct programming languages, a common XML specification of MEnDiGa games will be defined in the future for generative [5] and interpretive [7] game development approaches.Regarding the production of games from interactive GUIs, game platforms with graphical support environment such as Unity [32], Godot [33], and Scratch [34] have been widely used to produce digital games. However, it is important to reinforce the fact that important game engines still use the API programming approach to implement the game logic for designed games, such as PixiJS [35] and Panda3D [36]. As described in this paper, MEnDiGa follows the traditional API programming approach to implement desired behaviors, define observer criteria, and “configure” classes of the proposed MEnDiGa framework. In the future, a graphical support environment for MEnDiGa will be developed to allow the visual configuration of a future XML representation of MEnDiGa games.Moreover, regarding the complexity and variability in the production of digital games, dedicated game platforms for specific game categories [6], such as RPG Maker [37] and Adventure Game Studio [38], have been well accepted in digital game productions. MEnDiGa in its current modeling does not include specific game domains resources, being focused on providing generic elements available in casual and small games. To improve MEnDiGa as a dedicated game platform, it is necessary to define features and classes able to represent game structures of specific game categories, such as menus, HUDs, user interfaces, game rules, and game elements. The provided collection of dedicated features and classes will be able to produce casual games for specific game categories in a highly reusable way, evolving MEnDiGa consequently to the status of product line for specific game domains in the future.Finally, clone implementation of the Doodle Jump game using MEnDiGa assets was also demonstrated in this paper. As an equivalent example of casual games available today, the developed clone game has similar mechanics, dynamics, and aesthetics characteristics [39] in comparison to the original Super Jumper version. It is an important verification/validation step of this project as an attempt to show the feasibility of MEnDiGa assets in the generation of concrete digital games. Some OO metrics were also collected from the original Super Jumper and cloned MEnDiGa version. By comparison, they confirm that, with a simpler structure and a small increase in complexity, MEnDiGa allows the configuration of digital games from a core structure that follows theG-factor concept of game portability across distinct game platforms.



---

*Source: 9626710-2017-07-11.xml*