Multi-Level Modelling framework for Designing and Deploying Gameful Systems presented at MODELS 2019 Conference in Munich

1. Exploiting Multi-Level Modelling for
Designing and Deploying Gameful Systems
Antonio CicchettiAntonio Bucchiarone, Annapala Marconi

2. “The use of game design elements
in non-game contexts”
S. Deterding, 2011

3. • Game objectives are real-world challenges.
• Obstacles are real but, thanks to game concepts and mechanics, are tackled
with enthusiasm and resolution.
• The game layer enables a rewarding system based on:
• extrinsic/intrinsic incentives
• short feedback cycles
Gamification for engagement & behavioral change

4. Gameful System
• A software artifact that embeds a gamification process composed by the
following components:

5. Game Elements
• Basic building blocks of gamified applications.
• They are defined to specify how the players should interact with the
application to reach the ultimate goals.

6. Game Mechanics
• Set of rules that specify how the game should evolve for its participants
(i.e., students, citizens or employees).

7. Game Dynamics
• The ”emergent” behavior that arises using a gameful system, when the
mechanics are used.

8. A Gamification Framework for Smart Cities
1. Raman Kazhamiakin, Annapaola Marconi, Alberto Martinelli, Marco Pistore, and Giuseppe Valetto. A gamification
framework for the long-term engagement of smart citizens. In IEEE International Smart Cities Conference, ISC2
2016, pages 1–7, 2016.
2. http://www.drools.org
• Software component1 responsible for the execution of the game
associated with the gameful application.
• Rule execution system (i.e., DROOLS2) able to execute a rule set, with
constitutes the implementation of the game logic.
https://github.com/smartcommunitylab/smartcampus.gamification

9. Gamified Systems for
Smart Cities and Communities

10. To gain and keep the motivation of target players.
To combine a variety of behavioural change goals.
Easy-to-reproduce games in different contexts
(different cities with different players and challenges)
Motivation

11. Current Limits
Increased error-proneness of the implementation with the growth of
the game complexity an its needs of maintenance and evolution.
1
Difficulty in monitoring the evolution of the game and possibly
applying runtime adaptations.
2
Decreased chances of reusing game elements in other scenarios.3
Definition of wrong update for a certain score, making a challenge too
easy/complicated or even impossible to achieve.
4
No way to monitor the player progress (i.e., too slow) and act with
adaptation mechanisms (i.e., revised challenge).
5

12. a tool to design domain-specific languages (DSL)
• Modular approach that can be customized for different gameful
systems and reflects the gamification process.
• Different modelling layers (multi-level modelling), each of which
defined on the basis of the layer above, and the utility layers
(simulation, monitoring, adaptation) that are orthogonal – they can be
defined on the basis of any of them.
GDF: a tool for designing gamified applications
through model-driven engineering mechanisms
https://www.jetbrains.com/mps

13. GML: Gamification Model Language
• Core language to introduce the essential elements to describe a gameful
system.
• Basic building blocks on top of which al the other layers can be described.
• GML is an instance of a modelling language: the MPS base language.

14. GaML: Game Model Language
• It relies on Game Mechanics and allows the game designer to design a
concrete game in a specific domain (i.e., education, mobility).
• dataDrivenActions: actions
that acts on data (i.e., kms,
legs, etc..).
• experiencePoints: points
used to quantify a players
progression through a game
(i.e., pedibus_distance,
walk_km).

15. GiML: Game Instance Model Language
• It relies on Game Dynamics and is used to specify the instantiation of the
different games originating from the same GameDefinition.
• Game instances differ from one another by the set of teams and players
that play a certain instance of a game definition (i.e., Institute and
School instances) and the set of game elements instances (i.e., points,
actions, etc..)

16. Game Utility Languages
GsML - Simulation
• It allows to simulate game scenario for a specific
Team/Player that can execute an action instance or
can win a specific challenge.

17. Game Utility Languages
GmML - Monitoring
• It allows to monitor the state of a specific
Team/Player and check specific game variables: (daily
speed, completition percentage, delay, etc..)

18. Game Utility Languages
GadML – Runtime Adaptation
• It allows to inject new game content on-the-fly for a
specific player game instance (i.e., new/revised
challenge proposed by a recommendation system).

19. GDF Internal Logic
https://github.com/antbucc/GDF.git https://youtu.be/wxCe6CTeHXk
models@runtime models@runtime

20. Game Deployment (GiML)

21. Game Adaptation

22. Player State Monitoring
Retrieved Player State

23. Game
Design
Game
Deployment
Game
Simulation
Game
Monitoring
Game
Adaptation
GDF: a tool for designing gamified applications
through model-driven engineering mechanisms
Thursday, September 19th
Tools and Demos @Forum 12+13+14 -
13.30-15.00
Poster Session @Highlight Towers
Today 19.00-23.00

24. Conclusions
• A domain independent solution for the design of gamified applications.
• The choice of a multi-level modelling came out from the nature of
gamification applications.
• The solution proposed leverages language imports and inheritance
mechanisms provided by MPS.
• MPS supports language embedding through which is possible to
reuse/extend the concepts defined in one language for the specification
of another language.
• The number of levels and instantiation depth are determinated
dynamically by the use of a language.
GML (M4) à GaML (M3) -> GiML (M2)
• GDF allows domain experts to reason about gamification specific
concerns while implementation details are automatically handled by
the code generators.

25. Future Works
• To investigate further adaptation and learning capabilities of GDF.
• Integration with the Recommendation System.
• User-friendly Editors and Monitoring Dashboards.
• A more solid empirical evaluation should be done.
• From the PoC to the Production pipeline.
• To be ready for the next games (KGG and Play&GO) editions.

26. 26
Questions?
Thanks J
Antonio Bucchiarone
bucchiarone@fbk.eu
@antbucc