A Model-Driven Engineering Process to Support the Adaptive

Generation of Learning Game Scenarios

Pierre Laforcade, Esteban Loiseau and Rim Kacem

Computer Laboratory of Le Mans University, France

Keywords:

Serious Games, Adaptation, Learning Game Scenario, Generation, Metamodeling.

Abstract:

Adaptation is a key-concern when developing serious games for learning purposes, particularly for people

with speciﬁc needs. This paper presents a Model-Driven Engineering framework that eases the design and

the validation of adaptive learning scenarios. It tackles the personalization issue by helping domain experts

and computer scientists in making explicit then in validating the domain elements and rules involved in the

adaptation. The framework proposes a metamodeling process based on a metamodel specifying at ﬁrst the

domain elements according to both a 3-incremental-perspective on the resulting scenario, and a 3-dimensions

speciﬁcation of domain elements to use and produce. The framework then proposes to model the game de-

scription and the child’s proﬁle as input models for the generator that will produce the adapted scenario as an

output model. We applied the framework in the context of the Escape it! project that aims at helping young

children with Autistic Syndrome Disorder to learn and generalize visual performance skills.

1 INTRODUCTION

The use of serious games (Deterding et al., 2011) in

Autistic Syndrome Disorder (ASD) interventions has

become increasingly popular during the last decade

(Ern, 2014). They are considered as effective new

methods in the treatment of ASD. Computerized in-

terventions for individuals with autism may be much

more successful if motivation can be improved and

learning can be personalized by leveraging principles

from the emerging ﬁeld of serious game design in ed-

ucational research (Whyte et al., 2015).

This paper tackles the challenge of adapting learn-

ing sessions to the needs of individual learners. Our

research is conducted in the context of the Escape it!

project. The objective is to develop a serious game

to train visual skills of children with ASD. This seri-

ous game will borrow mechanics from ”escape-room”

games: the player’s goal is to open a locked door to

escape the room. To this end, the user has to solve

numerous puzzles often requiring observation and de-

duction. We adapted it for our targeted audience, re-

quiring to solve only one puzzle per scene.

In the context of this project we are focusing at

ﬁrst on the generation of learning scenarios adapted

to the current learning progress of children with ASD.

Indeed, this generation is difﬁcult because there are

a lot of elements and rules involved in the set up

of an adapted game session. We need an approach

that allows experts to participate in making explicit

and formalizing the domain elements and rules in-

volved during the generation of an adapted learn-

ing scenario. We propose such a framework: it is

based on Model-Driven-Engineering (MDE) princi-

ples and tools. MDE (Mussbacher et al., 2014) is

a research domain promoting an active use of ’exe-

cutable’ models throughout the software development

process, leading to an automated generation of the

ﬁnal application. We already tackled instructional

design challenges with MDE techniques in the past

(Loiseau et al., 2015) however the learning scenarios

were speciﬁed by teachers and not generated by the

machine.

The remainder of this paper is as follows. The

next section presents the Escape it! project contex-

tualizing our research. Section 3 discuses a literature

review about the generation of adapted scenarios. Our

proposition is then presented in Section 4. Finally, a

case-study is presented in Section 5 in order to ap-

ply and validate our proposition in the context of the

project. We discuss in the conclusion our results and

draw the next directions for further research.

Laforcade, P., Loiseau, E. and Kacem, R.

A Model-Driven Engineering Process to Support the Adaptive Generation of Learning Game Scenarios.

DOI: 10.5220/0006686100670077

In Proceedings of the 10th International Conference on Computer Supported Education (CSEDU 2018), pages 67-77

ISBN: 978-989-758-291-2

2 THE ESCAPE IT! PROJECT

This section presents the Escape it! project that con-

textualizes our research.

2.1 Objectives of the Project

The project aims at designing and developing a mo-

bile learning game (a serious game with learning pur-

poses) dedicated to children with ASD (Autistic Syn-

drome Disorder). The game intends to support the

learning of visual skills (based on the ones described

in the ABLLS-R



curriculum guide (Partington and

Analysts, 2010)). The mobility feature will allow the

learning to take place wherever the parents, therapeu-

tics, as well as the child himself want it. The game

will be used both to reinforce and generalize the learn-

ing skills that will be initiated by ”classic” working

sessions with tangible objects.

The project involves autism experts, parents and

Computer Science researchers, experts in the engi-

neering of Technology-Enhanced Learning systems.

2.2 General Overview and Principles

for the Serious Game

The serious game is based on the escape-the-room

structure: players have to ﬁnd hidden cues and ob-

jects, sometimes combine objects or interact with the

playing scenes, in order to unlock a door. The door

symbolizes the end of the level and gives access to the

next level. We made a cross analysis between mech-

anisms from various escape-the-room-like games and

best practices for designing serious games for chil-

dren with ASD (Ern, 2014)(Zakari et al., 2014).

We then sketched with experts, during participa-

tory design sessions, the major directions and require-

ments to take into account. Some of them are related

to the game aesthetics and sound environment (to be

adapted to the child sensory proﬁle), other about the

regulation of the child activity (prompts, guidances,

feedbacks, reinforcements, etc. have to be adapted to

every children proﬁle), or about the tracking system

that will be used to update the children proﬁles after

a game session. We only focus here on the scenario

involving the resolution activities, and list, below, the

most appropriate informations for our concern:

• targeted skills: a subset from the 27 visual perfor-

mance skills depicted in the ABLLS-R, the rele-

vant ones for a mobile gameplay adaptation.

• variable game sessions: a session will propose

from 3 to 6 levels according to a start menu choice

(to the convenience of the pairing adult with the

child or the child him-self).

• levels as meaningful living places: the whole

screen will display a ﬁxed (no scrolling or change

of point of view) and enclosed (with a door to

open) easily identiﬁable living places. These

scenes are related to themes, for example the bed-

room, kitchen and living room are related to the

home theme, whereas classroom and gymnasium

are related to the school theme.

• adapted difﬁculty: according to the current child

progress in the targeted skills; difﬁculty raises

after three succeeded activities for a same skill

(along one or several game sessions).

• generalizing the acquired skills: to this end, the

scenes have to change, in accordance with the

previous difﬁculty level, in order to propose non-

identical challenges for the same skill; i.e. :

– changing the scene (background and elements);

– adding background elements to disrupt visual

reading;

– changing the objects to ﬁnd and handle;

– adding other objects not useful to the resolu-

tion;

– hiding objects behind or into others.

We developed several prototypes to test our hy-

pothesis and try the ﬁrst designs. Figures 1, 2, 3

and 4 depict the 4 levels of a scenario taking place in

the same scene (gymnasium from the School theme).

These levels intend to support the learning of 4 visual

skills: match object to picture, match object to object,

sort into categories, and seriation.

Figure 1: Resolving the B3 visual skill (matching an object

to an identical object). In this example two tennis balls have

to be found and moved into the metal storage.

2.3 Anatomy of a Scene

Whichever scenes are selected for the learning sce-

nario, they share common constructs and rules:

• a background image that depicts a familiar scene

for the children, with a few recognizable objects;

CSEDU 2018 - 10th International Conference on Computer Supported Education

Figure 2: Resolving the B4 visual skill (matching an object

to an identical picture): a tennis ball is found and moved

into the metal storage. The previously closed door is now

open to gain access to the next level.

Figure 3: Resolving the B8 visual skill (sorting several ob-

jects into different categories): 4 objects to be found and

moved into the 2 storage boxes according to their cate-

gories.

Figure 4: Resolving the B25 visual skill (completing a se-

rialization). In this example, a ball is already positioned on

the ball storage; 3 others balls of different sizes have to be

found and positioned.

• several empty slots where objects to ﬁnd can be

later positioned;

• additional decorations to impair visual reading (in

relation to the difﬁculty rules); each one can:

– appear in different locations;

– create new slots for other game objects;

• interactive hiding objects: provide new hidden ob-

jects slots and reveal them when touched;

• solution objects where game objects have to be

dropped in/on;

– one or several places can be proposed to po-

sition this element or the different instances re-

quired to solve the level (e.g. for sorting objects

two or more storage boxes can be used);

– zero or several places can be proposed if

dropped objects have to appear speciﬁcally.

Prompts, guidances, feedbacks will also affect the

visual aspect of a scene (e.g. the empty/fulled stars in

Figures 1 to 4) but are not relevant to the scenario we

are focusing on.

The current prototype implements a 4-levels sce-

nario taking place in the gymnasium. The proposed

scenes deal with 4 visual performance skills. Except

the solutions objects and the range of choices for the

relevant objects to handle with the targeted skill, all

objects, additional decorations, positions, hiding el-

ements, etc. are randomly selected and positioned.

This prototype does not currently handle the child’s

proﬁle. Its purpose was to experiment and randomly

display combinations of playable scenes.

2.4 Design Issues and Research

Problematics

As stated above, a game scenario is composed of an

ordered sequence of scenes including precise descrip-

tions of each scene components and locations. All

this information has to be adapted to the child’s pro-

ﬁle when starting a new game session. There are vari-

ous proﬁle variables (current progress during learning

skills, preferences/dislikes, level difﬁculties for every

skill, etc.) and a lot of combinations of elements to

set-up a scene. In addition, generalization is very im-

portant in autism. It can be deﬁned as the process of

taking a skill learned in one setting and applying it in

other settings or different ways (Leaf and McEachin,

1999). To support the learning of generalization, we

have to propose a large variety of scenes settings.

Nevertheless, it is not possible to design and de-

velop all the combinations of settings. We need dy-

namically generated game sessions, adapted to each

child’s proﬁle. Next section studies existent solutions.

3 LITERATURE REVIEW

The adaptation of Technology-Enhanced Learning

systems allows the personalization of learning by

adapting whole or parts of the presented systems

(contents, resources, activities, etc.) to the learner’s

needs, interests and abilities. An adaptable learning

A Model-Driven Engineering Process to Support the Adaptive Generation of Learning Game Scenarios

system is generally considered as the degree in which

the system can be manipulated by its end-users. Dif-

ferently, adaptive learning environments aim at sup-

porting learners in acquiring knowledge and skills in

a particular learning domain; they can adapt to the

needs of the learner. In our context, our ﬁrst focus

is not on the adaptability of the mobile learning game

for children with ASD but on the adaptivity of the sys-

tem: to provide adapted game sessions in accordance

to the children’ proﬁles.

Several studies tackled the adaptation issue in se-

rious games. For example, (Lopes and Bidarra, 2011)

noticed that adapting to speciﬁc skills is more impor-

tant than to the global notion of difﬁculty or challenge

like in video games or simulations. The learning goals

to achieve are usually strongly coupled with the grad-

ual personal improvement of a skill set. Adaptive se-

rious games generally have specialized, and ad hoc,

approaches, where game components are adjusted to

encourage training of a speciﬁc skill. However adap-

tivity differs on the targets (game mechanics, AI,

narratives, content, etc.) and the methods (bayesian

networks, ontologies, neuronal networks, rules-based

systems, procedural algorithms, etc.) (Sina et al.,

2014)(Janssens et al., 2014)(Callies et al., 2015).

(Sehaba and Hussaan, 2013) proposes a generic

architecture for personalizing a serious game scenario

according to learners’ competencies and interaction

traces. The architecture has been evaluated in the

context of the CLES project with the objective to de-

velop a serious game for evaluating and rehabilitat-

ing cognitive disorders. It is organized in three lay-

ers: domain concepts, pedagogical resources and se-

rious game resources. They focus on the techniques

(machine learning) to update the learner proﬁle us-

ing interaction traces (Hussaan and Sehaba, 2016). It

does not match our current adaptation challenge, nev-

ertheless their 3-layers architecture and the process to

generate the learning scenarios are close to our con-

cerns. They also propose the generation of 3 succes-

sive scenarios (conceptual, pedagogical and serious

game scenarios) according to the 3-layers. They used

an evaluation protocol to validate the generated sce-

narios. Experts were involved at ﬁrst to validate the

domain rules, a priori of the generator implementa-

tion, and then to produce scenarios, for speciﬁc con-

texts, that will be compared to the generated ones.

Experts are considered as requirements and validation

sources but are not directly involved in the speciﬁca-

tion process.

Differently in the EmoTED project, a serious

game for helping children with ASD to train about the

mimic of emotions, we proposed a model-driven ap-

proach to more involve experts in the design and vali-

dation of game mechanisms (Laforcade and Vakhrina,

2015). These researches did not tackle the genera-

tion issue but the model-driven principles and process

could be further studied for our current challenge.

4 A MODEL-DRIVEN

FRAMEWORK FOR ADAPTIVE

GENERATOR

4.1 Overview of the Framework

The rationale of our proposition is to combine the

general architecture of a scenario generator from

the CLES project (Sehaba and Hussaan, 2013) with

the Model-Driven Engineering approach and process

used in the EmoTED project (Laforcade and Vakh-

rina, 2015) to support the speciﬁcation of the elements

(concepts, properties and rules) required to drive the

adaptive generation of scenarios. From the ﬁrst archi-

tecture we follow the generator principle where the ﬁ-

nal learning game scenario is built after 3 steps. Sim-

ilarly we propose to split the ﬁnal scenario generation

into three scenarios (named differently) :

• the objective scenario refers to the selection of

the targeted learning objectives according to the

user’s proﬁle including his current progress. In

the Escape it! context it is related to the elicitation

of the visual performance skills in accordance to

the number of levels to generate.

• the structural scenario refers to the selection of

learning game exercises or large game compo-

nents. For our case-study: the various scenes

where game levels will take place. This scenario

extends the previous one (i.e. the objective sce-

nario elements are included in this one). It is gen-

erated from user proﬁle elements and knowledge

domain rules stating the relations between these

pedagogical large-grained resources and the tar-

geted skills they can deal with.

• the features scenario refers to the additional

selection of the inner-resources/ﬁne-grained ele-

ments. In the Escape it! project it concerns all

objects appearing in a scene. The game scenario

includes both previous scenarios components; it

speciﬁes the overall information required by a

game engine to drive the set-up of a learning game

session.

It is worth noting that the ﬁnal scenario is only com-

posed of required descriptive informations to adapt

the game sessions to a user’s proﬁle. Informations

CSEDU 2018 - 10th International Conference on Computer Supported Education

about how these descriptions elements are function-

ing (static and dynamical dimensions) might be ad-

dressed by the generator and the serious game engine:

they are out the scope of the scenarization process.

From the second MDE-oriented research work,

we follow the metamodeling/modeling approach and

the use of the EMF framework (Eclipe Modeling

Framework)(Steinberg et al., 2009). We propose to

capture the global domain elements, required for the

generation, into three inter-related parts of a gen-

eral metamodel: proﬁle-related elements, game de-

scription elements, scenario elements. Contrary to

the EmoTED project, the scenarios elements have

to be generated, not speciﬁed. Nevertheless we still

have to specify the metamodel in order to detail the

components of the three scenarios in terms of ele-

ments/properties and relations to be generated. From

this metamodel, different models have to be consid-

ered:

• the game description model: it describes all the

game elements (skills, resources or exercisers, in-

game objects, etc.); it is an input model for the

generator;

• the proﬁle model: it describes the user’s proﬁle

for one person; it is also an input model for the

generator;

• the scenario model: it embeds the 3-dimensions

global scenario (objective, structural and features

scenarios); it is an output model of the generator.

Thus, we propose a model-driven, iterative and in-

cremental process about the design of the adaptive

generation of serious game scenarios. This process

involves domain experts and computer scientists to

conjointly design and validate the domain elements

and rules relative to the generation of adapted scenar-

ios.

4.2 An Iterative and Incremental

Process Involving Experts

Beyond the model-driven approach we also propose a

dedicated process, Figure 5, to help specify and vali-

date how the adaptive generation should work. Activ-

ities in italics, meta-modeling and generator develop-

ment, are only performed by computer scientists be-

cause of the required expertise. Other activities in-

volve both domain experts, i.e. non-technical users,

and computer scientists.

• Game analysis and design: this activity aims at

identifying and making explicit the various do-

main elements, properties, relations and also do-

main rules that are involved in the adaptive gen-

eration of the targeted scenarios; case-studies and

other designs (diagrams, mock-ups, etc.) can also

be explicit.

• Meta-modeling: this activity consists in specify-

ing the metamodel that captures the static domain

elements according to the model-driven frame-

work presented in the previous subsection. We

propose the use of the Eclipse Modeling Frame-

work (EMF). Indeed, EMF is a modeling frame-

work and code generator for building tools and

other applications based on a structured data

model (Steinberg et al., 2009).

• Generator development: this activity aims at de-

veloping the generator code that will take in

charge the adaptive generation of the different

scenarios. This development can be partially

eased by using the EMF environment. Indeed,

from our metamodel speciﬁcation, EMF provides

tools and runtime support to produce a set of Java

classes for the models, along with a set of adapter

classes that enable viewing and command-based

editing of the model. Thus, the generator code

can use the generated Java classes to import the

input models, handle them to produce the scenario

model, and then to serialize the output scenario.

• Modeling child’s proﬁle and game components

model: domain experts and computer scientists

specify both input models by using a basic tree-

oriented editor, also generated by EMF from the

metamodel speciﬁcation.

• Generator execution: this activity consists in exe-

cuting the generator code. It uses the child’s pro-

ﬁle model and game components model to gener-

ate a model embedding one, two or three of the

inter-related scenarios. It can also used the other

explicit designs (case-studies, mock-ups...). The

generated scenarios can then be analyzed in order

to verify their relevance, coherency and complete-

ness in terms of elements required by the serious

game, but also to validate the domain rules that

drive this generation.

These activities are part of an iterative process. One

can consider at least 3 iterations focusing respectively

on the 3 incremental scenarios: objective scenario,

then resources scenario, and ﬁnally the game sce-

nario. Nevertheless other iterations can occur for a

same targeted scenario according to the analysis of the

results from the generator executions. Indeed, gaps

between experts predictions and generated results can

occur, if such predictions are feasible. More gener-

ally, the analysis of the generated scenarios can high-

light some misunderstandings within the interdisci-

plinary team, or some misconceptions about the rules

A Model-Driven Engineering Process to Support the Adaptive Generation of Learning Game Scenarios

Figure 5: The iterative meta-modeling and modeling pro-

cess involving domain experts.

and elements involved in the generation. Some re-

engineering iterations are then useful.

Note that changes in the meta-model will break

compatibility of the models: it then requires to re-

do or modify them. Also, changes on the metamodel

can impact the generator code: a new phase of Java

classes generation can be required. If changes do not

affect the metamodel but the semantic of the genera-

tion rules then only the generator code requires mod-

iﬁcations.

5 APPLICATION TO THE

CASE-STUDY

In the next subsections the different steps of the pro-

cess are described in more details by applying our

proposition to the Escape it! context. We then present

one of the use cases involving experts in order to val-

idate our proposition (subsections 5.4).

5.1 The Experts’ Knowledge

Several collaborative sessions with autism experts led

us to progressively explicit:

• the global ’escape-the-room’ gameplay adapta-

tion,

• the visual performance skills in conformance with

this gameplay,

• a more detailed description of the scene resolu-

tion in terms of objects, hiding elements, solution

objects, etc.

• the domain rules to apply when generating a sce-

nario.

Some of these generation rules, the elements from the

proﬁle and game components models in relation with

them, are sketched in Table 1.

The generator we developed do not yet tackle the

childs’ proﬁle elements for the resource and game

levels of the generator (gray cells from Table 1). This

choice allowed us to focus on the high-priorities ele-

ments and rules.

As mentioned in the table, some mapping rules

have been made explicit in order to guide the genera-

tor in deciding how a scene is composed according to

a speciﬁc difﬁculty level. For example, here are the

mappings for the ’intermediary’ level:

• some background elements can appear;

• some hiding objects can appear with 0 or several

hidden objects inside according to their available

slots;

• all selectable objects are in relation to the problem

resolution (no other objects for disturbing pur-

poses).

5.2 The Escape It! Metamodel

The complete metamodel (an XML-based ecore ﬁle)

is represented in a graphical form in Figure 6. It de-

scribes the concepts, properties and relations between

concepts. It has been speciﬁed with the EMF frame-

work.

This metamodel speciﬁes all elements required for

the generator as well as those that will be generated

from it. It is not worth explaining all detailed ele-

ments. We then on purpose propose in Figure 7 a

more abstract perspective of the different parts, and

their relations, composing the metamodel.

There are 3 root elements in conformance with the

3 models to consider: Game Description, Proﬁle El-

ements and Scenario. The Game Description is com-

posed of 3 sub-parts: the skills elements (e.g. the vi-

sual skills), the exercises elements (e.g. the scenes

and themes), the game components (the background,

objects, locations, etc.) that are relative to a concrete

exercise. Some elements from Exercises and Game

Components parts will refer to some speciﬁc skills el-

ements (e.g. the scenes must speciﬁed which targeted

skills they can deal with). Similarly, the Scenario is

composed of the 3 inter-related sub-parts: Objective

Scenario, Structural Scenario and Features Scenario

CSEDU 2018 - 10th International Conference on Computer Supported Education

Table 1: The different domain rules and elements to deal with according to our 3x3-dimensions framework.

Game description User proﬁle Generation rules to consider

for scenarios

Objective

scenario

- the visual skills to acquire

- dependency relations be-

tween skills

- the acquired or in progress skills

- their difﬁculty level

- the number of levels to generate (n)

- only skills with parents at ’inter-

mediary’ level or higher are eligi-

ble

Structural

scenario

- the themes (school, house,

etc.) and the associated

scenes (bedroom, class-

room, etc.)

- for each scene: the skills

it can deal with

- the themes/scenes to ex-

clude/favour according to each

child’s preferences/dislikes

- information about previous game

sessions

- generate n different scenes from

the same theme if possible

- else generate different scenes

from various themes

- else generate a minimum of the

same scenes

Features

scenario

- for each scene: the back-

ground elements, the hiding

objects, the available object

places, etc.

- for each scene: the objects to

exclude/favour according to each

child’s preferences/dislikes

- for each scene: information about

elements involved in previous ses-

sions

- mappings between each difﬁ-

culty level and the objects to se-

lect and place into the scene

Figure 6: Complete view of the metamodel with variations of colors to discern the different dimensions.

(each of them completing the previous one). The Pro-

ﬁle part is not subdivided into other parts because, as

mentioned in Table 1, we only tackled the proﬁle ele-

ments required for generating the objective scenario.

Finally, the most interesting relations are the ver-

tical ones: the generator will analyze the skills ele-

ments and proﬁle elements in order to generate the

objective scenario (including elements being related

to skill elements). In a same way, the generator will

then analyze the Exercises elements according to the

A Model-Driven Engineering Process to Support the Adaptive Generation of Learning Game Scenarios

Figure 7: Conceptual parts and relations (composed-of and

references) composing the metamodel. Similar colors are

used between Figures 6 and 7 to ease the parts identiﬁcation.

previous identiﬁed skills to consider. Some of these

exercises elements will be identiﬁed to be used by ref-

erencing them into the Structural scenario elements.

Lastly, but the more complex part of the generator, the

game components relative to the previous selected ex-

ercises elements are analyzed. It will allow the gen-

erator to create the appropriate Features scenario el-

ements for specifying which objects have to appear

in the scene and at which locations, according to the

learning objective assigned to the scene.

5.3 Development of the Generator

We developed the generator as a Java, console-user-

interface program in order to beneﬁt from the Java

Model code and other code facilities generated from

the metamodel. Nevertheless, the generation rules

still have to be considered. Those corresponding to

levels 1 and 3 (cf. Table 1) are hard-coded with

aleatory procedures when several possibilities occur.

We used the Java Choco-Solver-4 library to spec-

ify level 2 (scenes and themes selection) rules as

constraints-based programs.

As mentioned in previous sections we do not yet

tackle the domain rules relative to the child’s proﬁle

for levels 2 and 3. The generator allows the successive

generation of the 3 scenarios. The resulting ﬁnal sce-

nario is persisted as a model that can be displayed and

handled by the EMF-generated model editor. How-

ever we decided to display in the console a text-based

readable print of the generated scenarios.

5.4 Validation of the Scenario

Generator

This section is dedicated to the description of one use-

case among those we experimented with domain ex-

perts in order to verify (whether the system is well-

engineered and error-free) the generator and validate

(whether the generator and generator rules meet the

experts expectations and requirements) the generation

rules. All those use cases were ﬁctive but realistic ac-

cording to experts suggestions. The modeled game

components were limited to the one available in the

prototype.

5.4.1 Modeling the Input Models

The generator requires two input models. The ﬁrst

one speciﬁes the game components involved with the

various scenario levels whereas the second one simu-

lates a child’s proﬁle.

In our experiments with autism experts, the ﬁrst

model has been speciﬁed on the base of experts’ re-

quirements. We modeled the B3-B4-B8-B25 visual

performance skills (respectively matching object to

image, matching object to object, sorting categories

of objects, making a seriation) and added their depen-

dency relations (e.g. Figure 8 shows that the B3 skill

unlocks the B4 and B8 skills, i.e. completing B3 at

its highest difﬁculty allows to progress independently

with the learning of the B4 and B8 skills). We then

speciﬁed the description of the game scenes according

to their relative theme (Figure 9). Finally, we spec-

iﬁed the elements involved in the gymnasium scene

(Figure 10): the one we focused on when developing

the prototype.

This game description has been modeled using

the tree-based editor generated from our metamodel

thanks to the EMF tooling. Figures 8, 9 and 10 show

different extracts of this unique model. The model

root is a Game Description instance. The composition

relations are naturally represented within this tree-

based representation whereas properties and other re-

lations are detailed in the Properties view according

to the element currently selected.

In opposition to the game components model that

is unique, several children proﬁle models have been

speciﬁed in order to test the correct use of generating

rules about the difﬁculty progress. Figure 11 shows

one of these proﬁle models. It describes a child’s pro-

ﬁle wherein the B3 skill is acquired at its highest (ex-

pert) level. The B4 skill is at the elementary level, B8

is at the intermediate level, and B25 is at the beginner

level.

CSEDU 2018 - 10th International Conference on Computer Supported Education

Figure 8: Partial view of the game description input model

for level 1 (objective scenario).

Figure 9: Partial view of the game description input model

for level 2 (structural scenario).

5.4.2 Analyzing the Output Model

We only depict the output scenario generated from the

child’s proﬁle example of the previous section.

The generator displays in the console user-

friendly prints of the resulting scenario. First prints

remind the input child’s proﬁle and the number of

levels to generate. Then the objective scenario is dis-

played, followed by the additional information gener-

ated with the resource scenario (see Figure 12). For

example, experts can verify that, for this very genera-

tion execution, 4 levels are proposed for the respective

targeted and ordered skills: B4 / B25 / B8 and again

B8 (with their difﬁculty level relative to the one spec-

iﬁed in the child’s proﬁle). In this execution, the gen-

erator succeeded in proposing different scenes from

the same theme (school).

The prints depicted in Figure 13 describe the de-

tails of the game scenario only for the third level in-

volving the gymnasium scene (the only scene we fo-

cused on). This description includes the objects used

Figure 10: Partial view of the game description input model

for level 3 (feature scenario).

Figure 11: Partial view of a child’s proﬁle input model.

and the slots used within the scene. Some slots refer

to the ones offered by background or hiding elements

(cf. descriptions in Figure 10).

5.5 Validation of Generating Rules

Previous subsections described a case-study in or-

der to present the different steps of our meta-

modeling/modeling process. This case-study, with

other ones, let us verify the correct functioning of

the generator. It also allowed us to validate the rel-

A Model-Driven Engineering Process to Support the Adaptive Generation of Learning Game Scenarios

Figure 12: Console prints after the generation of an adapted

scenario: readable view of the objective and structural parts

of the output model.

Figure 13: Console prints after the generation of an adapted

scenario: readable view of the feature part of the output

model.

evance of the generation rules with domain experts.

We now give some additional information about this

validation.

We conducted two collective sessions for exploit-

ing our generator with two experts. The ﬁrst session

focused on the the ﬁrst two layers: objective scenario

and resource scenario. We already tested our gener-

ator with various case-studies before this meeting in

order to avoid coding issues. This session consisted in

modeling some case studies with experts and analyz-

ing the generated scenarios. During this session we

decided not to take into account an initial domain rule

(not mentioned in Table 1) about generating 80% of

levels with skills at a maximal difﬁculty level ’inter-

mediary’ against 20% of skills with higher difﬁculty

levels. They ﬁnally did not consider it relevant. In

contrast we listed different mappings between every

difﬁculty level and the game objects to consider at the

game scenario level.

The second collaborative session focused on the

generation of the game scenario. Before, we modi-

ﬁed the game components model to specify the gym-

nasium scene of the school theme as the only avail-

able scene. Thus, it forced the generator to select

this scene and then detail its game objects when deal-

ing with the game scenario generation. This session

let us validate the good matching between the difﬁ-

culty levels and the different game rules. The ﬁctive

child’s proﬁles were only used here to drive the fo-

cus on a targeted skill, one-by-one, by experimenting

all difﬁculty levels mappings. In order to better visu-

alize the results proposed by the generator we used

some paper-based prints of the scene’s background

(with annotations about slots), objects, solution ob-

jects, hiding objects, etc. We read the console-based

generated result and placed the mentioned objects in

their slots. When done, we discussed the relevance of

the proposition with experts.

These very ﬁrst validation sessions conﬁrmed our

proposition to help domain experts in designing and

validating the required rules to drive the generation of

adapted learning scenarios.

6 CONCLUSIONS

In this paper we studied the problem of adapting

learning game scenarios to people with speciﬁc needs.

We presented a Model-Driven Engineering (MDE)

framework that ease the design and validation of

adaptive learning scenarios. It tackles the personal-

ization issue by helping domain experts and computer

scientists in making explicit and validating the do-

main elements and rules involved in the adaptation.

The proposition is based on a metamodel specifying

at ﬁrst the domain elements according to both a 3-

incremental-perspective on the resulting scenario, and

a 3-dimensions speciﬁcation of domain elements to

use and produce. The framework proposes to model

the game description and the child’s proﬁle as input

models for the generator that will produce the adapted

scenario as an output model. We applied the frame-

work in the context of the Escape it! project that

aims at helping young children with Autistic Syn-

drome Disorder to learn and generalize visual perfor-

CSEDU 2018 - 10th International Conference on Computer Supported Education

mance skills. Collaborative sessions with autism ex-

perts have been conducted.

First results emphasized the interest in validating

the adaptation elements and rules on the early design

phases. It could be useful to avoid the re-engineering

cost when adaptation rules are invalidated when test-

ing a prototype. Moreover, MDE tools provide some

facilities in order to drive and ease the development of

a basic console-based generator. Models are both ex-

ecutable by the generator, and human-readable when

speciﬁed with a tree-based model editor (generated

by EMF from the metamodel speciﬁcation). It then

offers a support for conducting collaborative design

sessions between computer scientists and domain ex-

perts.

Our very ﬁrst validation sessions conﬁrmed our

proposition to help domain experts in designing and

validating the required rules to drive the generation

of adapted learning scenarios. Further developments

will focus on integrating the generator output models

(XML ﬁle) in our Unity-based game prototype. It will

allow us to propose more accurate validations with

respect to the prototype independence to changes on

the generator. We also highlighted that the dynamical

domain rules, like the generation rules and the map-

ping rules between the difﬁculty levels and the game

objects involved within a scene resolution, are not ex-

plicit: they are hard-coded in the generator. Because it

can also lead to coding issues, further research works

about specifying such informations have to be under-

taken. We have started tackling this issue by exper-

imenting various MDE techniques: models transfor-

mations, model weaving, validation of models in con-

formance to rules written with the Object Constraint

Language (OCL), etc.

REFERENCES

Callies, S., Sola, N., Beaudry, E., and Basque, J. (2015). An

empirical evaluation of a serious simulation game ar-

chitecture for automatic adaptation. In R. Munkvold &

L. Kolas (eds.), Proceedings of the 9th European Con-

ference on Games Based Learning (ECGBL 2015),

pages 107–116. Reading, UK: Academic Conferences

and Publishing International Limited.

Deterding, S., Dixon, D., Khaled, R., and Nacke, L. (2011).

From game design elements to gamefulness: Deﬁning

”gamiﬁcation”. In Proceedings of the 15th Interna-

tional Academic MindTrek Conference: Envisioning

Future Media Environments, MindTrek ’11, pages 9–

15, New York, NY, USA. ACM.

Ern, A. (2014). The use of gamiﬁcation and serious games

within interventions for children with autism spectrum

disorder.

Hussaan, A. M. and Sehaba, K. (2016). Consistency Veriﬁ-

cation of Learner Proﬁles in Adaptive Serious Games,

pages 384–389. Springer International Publishing,

Cham.

Janssens, O., Samyn, K., Van de Walle, R., and Van Hoecke,

S. (2014). Educational virtual game scenario genera-

tion for serious games educational virtual game sce-

nario generation for serious games. In Proceedings

of the IEEE 3rd International Conference on Serious

Games and Applications for Health (SeGAH’14).

Laforcade, P. and Vakhrina, V. (2015). A Domain-Speciﬁc

Modeling approach for a simulation-driven valida-

tion of gamiﬁed learning environments - Case study

about teaching the mimicry of emotions to children

with autism.

Leaf, R. B. and McEachin, J. (1999). A Work in Progress:

Behavior Management Strategies and a Curriculum

for Intensive Behavioral Treatment of Autism. New

York: DRL Books.

Loiseau, E., Laforcade, P., and Mawas, N. E. (2015). Turn-

ing recurrent uses of e-learning tools into reusable

pedagogical activities - a meta-modeling approach ap-

plied to a moodle case-study. In Proceedings of the

7th International Conference on Computer Supported

Education, pages 64–76.

Lopes, R. and Bidarra, R. (2011). Adaptivity challenges

in games and simulations: A survey. IEEE Transac-

tions on Computational Intelligence and AI in Games,

3(2):85–99.

Mussbacher, G., Amyot, D., Breu, R., Bruel, J.-M., Cheng,

B. H., Collet, P., Combemale, B., France, R., Hel-

dal, R., Hill, J., Kienzle, J., Sch

ottle, M., Steimann,

F., Stikkolorum, D., and Whittle, J. (2014). The

Relevance of Model-Driven Engineering Thirty Years

from Now. In Dingel, J., Schulte, W., Ramos, I.,

Abraho, S., and Insfran, E., editors, Model-Driven En-

gineering Languages and Systems, volume 8767 of

Model-Driven Engineering Languages and Systems,

page 18, Valencia, Spain. Springer International Pub-

lishing Switzerland.

Partington, J. and Analysts, P. B. (2010). The Assessment

of Basic Language and Learning Skills-revised (the

ABLLS-R).

Sehaba, K. and Hussaan, A. (2013). Goals: generator of

adaptive learning scenarios. In International Journal

of Learning Technology, volume 8, pages 224–245.

Sina, S., Rosenfeld, A., and Kraus, S. (2014). Generat-

ing content for scenario-based serious-games using

crowdsourcing. In Proceedings of the Twenty-Eighth

AAAI Conference on Artiﬁcial Intelligence, AAAI’14,

pages 522–529. AAAI Press.

Steinberg, D., Budinsky, F., Paternostro, M., and Merks,

E. (2009). EMF: Eclipse Modeling Framework 2.0.

Addison-Wesley Professional, 2nd edition.

Whyte, E. M., Smyth, J. M., and Scherf, K. S. (2015).

Designing serious game interventions for individuals

with autism. Journal of Autism and Developmental

Disorders, 45(12):3820–3831.

Zakari, H. M., Ma, M., and Simmons, D. (2014). A Re-

view of Serious Games for Children with Autism Spec-

trum Disorders (ASD), pages 93–106. Springer Inter-

national Publishing, Cham.

A Model-Driven Engineering Process to Support the Adaptive Generation of Learning Game Scenarios