Bérénice Lemoine
email: berenice.lemoine@univ-lemans.fr

Pierre Laforcade
email: pierre.laforcade@univ-lemans.fr

Sébastien George
email: sebastien.george@univ-lemans.fr

An Analysis Framework for Designing Declarative Knowledge Training Games using Roguelite Genre

Keywords: Analysis, Serious Game, Declarative Knowledge, Training, Roguelite, Gameplay

The training of declarative knowledge requires repetition and adaptation to learners' needs. Learning games for training purposes should then offer a wide range of adapted and varied game situations where facts are questioned. Furthermore, answering these questions may involve many gameplays that keep the learnerplayers engaged and motivated to practice again and again. This article presents and justifies how the Roguelite game genre is well-adapted to tackle these challenges. It also proposes an analysis framework to support pluridisciplinary teams of teachers and game developers in identifying the key orientations for designing such training games. This framework is composed of questions to consider during the preliminary design of the training game. We have identified and used this proposition in a specific research context about multiplication tables training. The article illustrates the first results obtained which led to our first playable prototype. Finally, we outlined the major drawbacks of our first game design (i.e., first analysis), which brought us to carry out a second analysis through our proposed framework.

INTRODUCTION

Explicit knowledge of facts, such as multiplication tables, historical dates or geographical information, are known as declarative knowledge. Repetition is a necessary task to encourage the memorization, generalization, and retention of declarative knowledge [START_REF] Kim | An integrated theory for improved skill acquisition and reten-tion in the three stages of learning[END_REF][START_REF] Roediger | Inexpensive techniques to improve education: Applying cognitive psychology to enhance educational practice[END_REF]. However, repetitive or redundant serious games as well as the ones presenting an imbalanced challenge relative to the skills of the players can be boring for the players [START_REF] Streicher | Personalized and Adaptive Serious Games[END_REF]. Therefore, to reduce the feeling of repetition, serious games targeting declarative knowledge should offer a wide variety of adapted learning game activities.

Most of existing serious games for the training of multiplication tables only present questions to answer, surrounded by game elements that do not impact the gameplay. Such training games do not propose long-term engaging activities. Poor gameplay could quickly bore students and reduce their engagement to practice (i.e., motivation, frequency, and duration of sessions, etc.). It therefore seems important to allocate as much importance to gameplay as to educational content when designing learning game activities [START_REF] Marty | Hints for improving motivation in game-based learning environments[END_REF].

This article proposes to highlight a specific game genre, Roguelites. Indeed, this genre is based on several design principles, of which we propose to discuss their compliance with the requirements for efficient and adapted training of declarative knowledge. Our proposal is presented in the form of an analysis framework in order to help the design of Rogueliteoriented training games. This framework involves a set of practical steps to be followed in each iteration of a prototyping-based design approach. The aim is to focus on design needs, from two dimensions (i.e., training and game), such as: technology (i.e., some information needed for the game engine/generation algorithm), game-gameplay (i.e., how the main game mechanics of the Roguelite genre work), and game structure (i.e., the game rules). To illustrate our proposal, we present and discuss the application of this analysis framework during two design iterations of the same research context: the AdapTABLES project.

Test-based learning represents, in cognitive psychology, the idea that the process of retrieving (i.e., remembering) concepts or facts increases their longterm retention. Whilst tests are mainly used as summative assessment tools, they can also be formative.

One way to implement test-based learning is through repeated retrieval (i.e., retrieval practice). Research has shown that this method can improve long-term retention [START_REF] Brame | Test-Enhanced Learning: The Potential for Testing to Promote Greater Learning in Undergraduate Science Courses[END_REF][START_REF] Roediger | Inexpensive techniques to improve education: Applying cognitive psychology to enhance educational practice[END_REF]. Moreover, research also suggests that the benefits of test-based learning are not linked to a specific type of retrieval practice (i.e., various test formats enhance learning) [START_REF] Brame | Test-Enhanced Learning: The Potential for Testing to Promote Greater Learning in Undergraduate Science Courses[END_REF]. In this paper, training involves providing the learner with various forms of questions repeatedly, which is a form of retrieval practice.

The structure of this paper is as follows. Section 2 introduces our research context, including our AdapT-ABLES project and its specific declarative knowledge about multiplication tables. In addition, it presents the video game Roguelite genre and discusses considering Roguelites as a suitable genre for designing training games. Section 3 is dedicated to the proposition of a two-dimensional analysis framework (gaming and training dimensions). This proposal has been applied twice in the context of our project. Section 4 is then devoted to the presentation of these two applications, as well as the feedback gathered from the evaluation of a prototype in line with the first analysis.

RESEARCH CONTEXT

The AdapTABLES project aims to design and develop a serious game dedicated to the individual training of multiplication tables.

From a teacher perspective, the training game to design will be adapted, prior to its use, to reflect how teachers consider the training: source facts, difficulty, progress... This training structure can be set up for the entire classroom's students, for a group, or for individuals having specific needs. From a student perspective, the training game will follow the learners' progress, proposing facts according to their previous training sessions and results. From a player perspective, the training game will offer game levels that take into account their preferences. From a game perspective, a same training task should be tackled through different gameplays with different game elements. Finally, at runtime, the training game will have to generate varied training game activities, adapted, both in terms of gameplay and educational content, to the teachers and learners-players perspectives.

We followed an iterative co-design and prototyping approach, involving teachers and didacticians of mathematics, and game experts during the design and evaluation phases. At first, two initial steps were necessary: 1) specifying the knowledge to be trained, and 2) choosing a type of game that suits the training of declarative knowledge. These contextual elements are necessary to start designing at a high level the main key concepts and rules of the training game.

Declarative Knowledge Training

We started an exploratory research [START_REF] Laforcade | Expressing adaptations to take into account in generator-based exercisers: An exploratory study about multiplication facts[END_REF] with the help of a user group composed of teachers and mathematics experts A training path, see Figure 1, is represented by a set of objectives ordered by prerequisite relationships. An objective (e.g., "Work on the table 2") is broken down into progressive levels of difficulty. Each level is itself broken down into training tasks (e.g., "Level 1: Completion 1 with search for the result, Identification by choice of the correct facts"). A task is defined by its type and parameters. The levels' achievements are considered from both a percent of encountered facts and a percent of achievement to reach. Five types of tasks have been identified with the teachers: Completion 1, i.e., complete an incomplete fact that has one missing element (e.g., 3×? = 15, 15 =? × 5, 3 × 5 = ?); Completion 2, i.e., complete an incomplete fact that has two missing elements (e.g., ?×? = 15 with a set of given choices [3, 6, 5, 10], ? × 5 = ? or 3×? = ? also with sets of given choices); Reconstruction, i.e., replace, in the correct order, all important elements of a fact (e.g., ?×? = ? with a set of given choices [3,6,5,10,15]); Identification, i.e., identify the correctness or incorrectness of one or several facts (e.g., 3 × 5 = 15, true or false?); Membership Identification, i.e., identify the elements that share or do not share a given property (e.g., [3,5,9,14,21] which are results of table 3?).

Considering the training tasks, their specification led us to define several parameters whose values depend on teachers' opinion and preferences to choose and set-up these tasks for each {objective, level} pair. For example, the parameters for the Completion 1 task are presented in Table 1: the targeted tables, the multiplicand position, the result position, the interval (i.e., min/max) of the multiplier, the elements to search, the order of the questions, the modality of response, and the maximum response time.

As we are following a prototyping design approach, the design is carried out step by step. Therefore, each new iteration takes into account a little more information than the previous one. This article presents the first two iterations of our design, which does not yet include the full knowledge structuring presented. The first prototypes aim at a parameterization approach, i.e., teachers have to give the parameter values (cf. Table 1) for each learner inside the game.

Roguelite Genre

Roguelike and Roguelite are video games genres growing in popularity this last decade. They stem from the game that pioneered this type of gameplay: Rogue [START_REF] Toy | Rogue [digital game[END_REF]. Rogue was a turn-based dungeon crawler game where you have to fight your way through levels of a dungeon, picking up items and defeating enemies along the way. The Berlin Interpretation [START_REF] Harris | The Berlin Interpretation[END_REF]) defined 8 high-value factors for Roguelikes, which includes:

• Random environment generation: different room layouts with randomized locations for enemies and items each time you play. This is usually realized with procedural generations, not total randomness, to avoid unwinnable situations.

• Permanent death: when the avatar die, all progress is lost and the player must start over from the beginning. No progress is carried over across runs.

Most of Roguelikes games fall to respect all 8 key aspects, like the turn-based gameplay with movement on a grid. As a result, people started considering these games as "roguelike-like" or "roguelite". For now, Roguelite genre is used in relation to Roguelike games, proposing a macro-level objective by carrying over some items and progression after each attempt. Some well-known commercial Roguelites games are: Hades, Enter the Gungeon, The binding of Isaac, Rogue Legacy and Deadcells. They propose different kind of gameplay, game styles and lore as well as different features and permanent elements to reach the game cross-run objective (e.g., weapons, currencies, upgrades, etc.). For example, some collectible resources can persist between deaths and players can use them to unlock permanent upgrades and increase their chance of success.

Failure is a key-part of Roguelites. When players start, the new mechanics, traps, difficult enemies and bosses, or the various features that they need to learn, will lead them to fail and/or die many times before they win their first complete run. While losing over and over again may not sound fun, Roguelikes typically have fast restart times and will quickly get players back into the action. Through playing more runs, players begin to understand the underlying mechanics and get further. The game flow (i.e., temporal representation of game sessions) of Roguelite oriented games can be different from one game to another. This article considers the game flow presented in Figure 2 where a play session is a temporal session that begin when the player starts the game and that ends when he/she stops it. It is composed of complete or incomplete runs. A run is a succession of game levels, played without dying, with increasing difficulty. There are two conditions for stopping the run: the end of the game is reached or the avatar died. A game level is generally a level of a dungeon (or something similar) that is composed of interconnected rooms or areas.

Adequacy of Declarative Knowledge

Training with Roguelite Genre

Replayability is at the heart of the Roguelite genre, which is designed to keep players interested while relying on a repetitive mechanic (i.e., permanent death).

In addition, the random environment generation feature offers a wide variety of dungeons (i.e., each generated dungeon level is different in terms of rooms, room succession and elements). The procedurally generated maps will always provide a different experience with each play through. Finally, the progress feature allows for the storage of player data. All these features are necessary elements in our research context. Repetition to retain declarative knowledge, generation of varied activities to limit the impact of repetition, and progression to keep track of the learner's progress and preferences in order to adapt the activities. Therefore, Roguelite seems to be a suitable genre for declarative knowledge training, where the training game activities generated are dungeon levels.

Left ∨ Right 1 × 2, 1 × 3, 1 × 4.. ∨ 2 × 1, 3 × 1, 4 × 1.. Result Position Left ∨ Right 1 × 2 = 2 ∨ 2 = 1 × 2 Multiplier Interval Integer Min/Max in [1, 12] [1, 5] ∨ [5, 10] ∨ [1, 12] Element to search Result ∨ Multiplicand ∨ Operand 1 × ? = 2 ∨ ? × 2 = 2 ∨ 1 × 2 = ? Questions Order Ascending ⊕ Descending ⊕ Random Response Modality
Choice between propositions ∨ Input Max Response Time Time in seconds

Targeted Adaptations

Our general context is about the adaptation of the generated game and learning activities. This adaptation needs then to be characterized from both game and learning perspective. Adaptation is often characterized by three concepts: the source (i.e., to what do we adapt?), the target (i.e., what is adapted?) and the pathways (i.e., what methods are used to adapt the target to the source?) [START_REF] Vandewaetere | The contribution of learner characteristics in the development of computer-based adaptive learning environments[END_REF]. Foremost, in our context, the adaptation targets generated dungeon and their elements (i.e., what is adapted). Therefore, it takes place during the generation of an activity (i.e., when it is adapted). In the spectrum of adaptation defined by [START_REF] Oppermann | Adaptability and adaptivity in learning systems[END_REF], our targeted adaptation can be positioned in-between adaptivity and adaptability, as it uses user's data previously collected to automatically generate an activity that is adapted to her/him.

In the literature, the gaming adaptations are mostly based on players/personalities profiles [START_REF] Tondello | The Gamification User Types Hexad Scale[END_REF][START_REF] Nacke | BrainHex: A neurobiological gamer typology survey[END_REF][START_REF] Goldberg | An alternative" description of personality": The big-five factor structure[END_REF] or players characteristics, such as age and genre. In our context, adaptation from a game perspective seeks to take into account player preferences to choose the game elements (i.e., source). The main idea is to represent preferences as game elements that can be activated/deactivated by the player. From the learning perspective, our intention is to use knowledge of the learner (e.g., actual level, previous mistakes) from his/her learning path (source) to adapt the dungeons' difficulty in terms of educational content.

Since the adaptation is an integral part of the generation, in our context, this article does not dissociate them (i.e., the generation criterion includes adaptation, see Section 3).

Research Question

Many questions need to be answered when designing a Roguelite oriented game for training declarative knowledge. What is generated? How and when does the avatar die? What are the consequences? What varies? What indicates a progression? And so on. Furthermore, these questions need to be answered from both an educational and a game perspective. Moreover, in a prototyping design approach, the answers may change from one prototype to another. Therefore, our research question is: How can the design of Roguelite-oriented learning be facilitated in a prototyping design approach? Our proposal is an analysis framework that helps designers ask the right questions and make their choices explicit during each design iteration.

ANALYSIS FRAMEWORK FOR A ROGUELITE LEARNING GAME

Firstly, it is important to keep in mind that we are designing a game. Therefore, although the design tends to focus on learning, the game aspect must not be neglected. To this extent, the proposed framework aims to provide a means of analyzing the design needs of Roguelite-oriented learning games by specifying both dimensions through specific criteria. The first step in designing a Roguelite is the specification of game mechanisms, such as generation (e.g., what is generated? How?), permanent death (e.g., when does one die?), as well as progression (e.g., what elements are kept?). Hence, the generation mechanism involves the specification of the variety mechanism, e.g., which elements should the generation vary? In a game, as in learning, an essential notion is that of difficulty progression, e.g., how does one increase difficulty? When? In our context, the 5 mechanisms (Generation, Death/Hurt, Variety, Progress, and Difficulty) are criteria for analyzing needs that must be specified from both points of view. Each criterion consists of a series of questions that relate to the same mechanism. Each question should be answered in order to clarify the design needs of the learning game. The questions per criterion are:

1) Generation The table 2 presents a structure to be completed for the needs analysis. Each row represents a criterion and is divided into X sub-rows (i.e., one sub-row per question). Each column represents a dimension (i.e., a column for the game dimension, another for the educational dimension). If both dimensions have some common information, it can be precised by merging both related cells. The proposed framework is independent of the learning field and is suitable for the design of any learning game based on Roguelite genre. The following section presents the application in the context of the AdapTABLES project.

FRAMEWORK APPLICATION: ADAPTABLES PROJECT

This section is broken down into four subsections: subsection 4.1 details the analysis for the design of the first prototype; subsection 4.2 describes the current prototype; subsection 4.3 presents the feedbacks (collected informally in real-life conditions) on the prototype); subsection 4.4 specifies the design needs analysis for the next prototype, and subsection 4.5 discusses the proposition.

First Analysis

The initial step in our iterative process was to carry out the design needs analysis for the first prototype.

The initial scope was to put aside the knowledge structure by focusing on one task only (Completion 1 for multiplication tables) that will be manually set up into the game (persistent information through different training sessions). Table 3 presents an overview of the first design needs analysis.

Generation. The generated element (Q1) is a dungeon level and its elements (i.e., rooms, rooms order, rooms elements, elements positions and values). Each room has a type between question room and noquestion room. A question room is associated to a task (i.e., the training task defined by the teacher and set-up before playing). A no-question room is a fun room where enemies, traps, and only game elements are present. The presence of purely gaming rooms intends to avoid giving the learners-players the impression that they are simply answering a disguised questionnaire. Following the game flow presented in Figure 2, a dungeon is generated when (Q2) the player asks for a new game level.

As mentioned in Section 2.4, our game adaptations target players' preferences. To identify the preferences, we first looked at the existing Roguelites and found out that many of them offer a mechanism for purchasing items (e.g., equipments, upgrades, skills). Then, by working with game designers, we identified three kinds of preferences: 1) Content, 2) Rules and 3) Visuals & Audio (Q3). Content preferences are additional objects present while playing or elements that change the structure of the activity if activated. For example, an extra life or a dungeon mode (linear or labyrinthine) are content preferences. Rules preferences are elements that impact the players, the avatar or the NPCs (Non-Player Characters) behaviors. For example, increasing the enemies speed or adding a game goal (e.g., completing an activity without mistakes earns +10 coins) are rules preferences.

From the game dimension, the generation is based on (Q3) these three types of preferences (e.g., if a player bought and activated the labyrinthine mode, the generation algorithm takes it into account). To keep track of learners' in game progress, the generator also takes into account the last level number and state: if the previous level was #5 and was successful, then the next level is #6; in case of death, the next level is reset to #1. Level number affects the dungeon length, the quantity of rooms with questions, and the dungeon effects (levels greater than #4 are in dark mode). In the educational dimension, many tasks parameters can change depending on the level of the learners (cf. Section 2). Therefore, all learners have their own setup for the task Completion 1 (or a shared one) defined by the teachers. These parameters values are used to produce relevant questioned facts associated to the rooms-with-questions (Q3). Previous encountered questioned facts and results are used to avoid answering again a successful questioned fact.

It is worth notice that both game and training dimensions can sometimes conflict. For example, if a learner-player has bought and activated the 'labyrinthine' mode and if the task setup requires the learner to meet the questioned facts in an ascendant or descendant order. In these cases, our recommendation is to consider the training dimension as a priority.

Death/Hurt. In both cases, when the avatar is injured (Q5), it loses a life, and when there is no life left, it dies. The player (through the avatar) gets hurt (Q4) when touching a foe, falling into a pit (game dimension) or when answering incorrectly to a question (educational dimension). It also happens when the time is over (preliminary set in the task parameters). Answering a question incorrectly or running out of time can only be done in a question room (Q6), while hitting the wrong enemy or falling into a pit can be done in both types of rooms.

Variety. In terms of game variety, different elements can be chosen by the generation algorithm. In the context of Roguelite, the variations are mainly based on the types of objects, their position, the shape of objects and dungeons, and the number of elements present (Q7). Therefore, the decorative objects positions as well as the rooms shapes are chosen "randomly" (Q8) (i.e., the coherence is kept, e.g., the elements are not outside the room or the avatar can access the necessary elements). The gameplay repre-sents the concrete way in which the learner performs the task. Therefore, having only one form of gameplay per task can quickly lead to a sense of redundancy. One way to avoid this sense is to vary the gameplay. To that extent, 4 gameplays were identified (Q7) for the Completion 1 task type: open the chest wearing the correct answer, pass through the door that has the correct answer, touch the foe wearing the correct answer, or type down the correct answer.

From the learning dimension, the facts to be worked on are different, until each fact has at least been seen once (Q7). Moreover, depending on the parameters (cf. Table 3), the facts shapes (e.g., missing element, position of the equal, etc.) vary (Q8). Some degree of randomness is always involved in the variation of elements. However, this randomness is limited by the preferences of the game, the educational constraints (i.e., the teachers' choices) as well as by the choices made earlier (i.e., elements already selected by the algorithm).

Progress. In order to take into account players' preferences, our main idea is to use a purchase mechanism (i.e., commonly used in Roguelites) where players can buy items and then activate/deactivate them as they wish. Therefore, progression from the game viewpoint can be seen through the elements bought and the number of coins (Q9). Some Roguelites only keeps progression when the level/dungeons are finished (i.e., the avatar did not die). Therefore, the coins are only gained if the player finishes a dungeon completely. These coins are collected through the dungeon journey (randomly appear when opening a correct chest) or win at the end according to the activated rules (for example, +10 if ending the dungeon level without any mathematics error). Training progression can be seen at the end of a dungeon (when reaching the end or dying) with statistics presenting the mistakes made, the correct answers given, and what is left to work on. All the results are persistent across the runs.

Difficulty. From the game dimension, difficulty increases during a run by increasing the number of rooms-with-question (i.e., 5 rooms first, then 7, then 9, then 11, etc.) (Q10). The total number of rooms may still vary according to the generation process that can randomly includes rooms without question along with the dungeon structure (tortuous but linear or labyrinthine) (Q11). After 5 levels played, without losing, a harder level is proposed where the player is in the dark, a torch only illuminates the avatar (Q10). The educational difficulty increases in accordance with the parameters defined by the teachers, but while these parameters are not changed, the questioned facts will always concern this setup (Q11).

These choices are mainly debatable, and intends to define a first version of the game's difficulty progression, which is bound to evolve.

First Prototype

The prototype has been developed using the Unity game engine, as a 2D game with C# scripts. It is exported and deployed as a Web platform WebGL build. The game uses an HTTP REST API (developed in .Net Core) to persist data in a NoSQL MongoDB database. In addition, a teacher dashboard is available as a web application (developed in .NET with Blazor). It allows teachers to monitor for their students: the current settings for the multiplication parameters, current achievement progress for the considered multiplication facts, current elements that has been bought. Currently, only a French version playable with both a gamepad or a keyboard is available.

Figure 3 shows 6 screenshots of the prototype. The screen 3a represents part of the current 'hub' area with four accessible elements: statistics ("Stats Generales"), progress ("Progression"), educational settings ("Reglages") and lastly the purchase panel ("Achats", i.e., game preferences). This 'hub' area is where the player starts a run and goes back after he died. It offers players a peaceful space where they can check their progress or manage collectibles (purchase, activation/deactivation). Screen 3b is an extract from the educational settings panel (cf. Table 1). Screen 3c is an extract from the item purchase panel. An example of each of the currently implemented gameplays present in the dungeon levels (i.e., choosing the correct foe, the correct door, and the correct chest) is illustrated in the Screens 3g, 3e, 3f. Finally, the Screen 3h presents an example of a room where the player has to type down his/her answer.

Experiment Feedback

The design of the prototype went through 3 iterations where it was tested in real conditions and then improved according to the feedback from teachers and students (i.e., played in classroom by students supervised by their teacher). Some empirical feedback were about ergonomics concerns (keyboard versus gamepad), playability experience, replayability inclination, motivation to play and train the tables, etc.

The rest of the information collected were related to the overall design, based on our previous analysis choices, stated in the previous section. With regard to the death/injury criterion, several problems have been identified. Firstly, children sometimes make unintentional choices due to the current 'touch'-oriented interactions that do not require the use of a button or key. Even if this gameplay problem is related to ergonomics, it can lead to a feeling of unfairness from the reward/punishment system. Secondly, some rooms have randomly positioned foes very close to the avatar's entry area: swept along by the momentum, children can lose hearts without having time to avoid them. Similarly, some room-with-question also embed holes to avoid. Teachers have pointed out to us that these game elements can disturb children when they should focus on the question.

Considering the variety criterion, children appreciated the three gameplays for choosing an answer (door, chest, and foe). This prototype offered 3 different room structures for each game, however it does not vary enough. The gameplay about touching the correct foe has been considered confusing by both children and teachers. In some rooms, foes were to be avoided, while in others the players must lead their avatar to touch the foe with the answer they choose. This is counter-intuitive, and teachers consider that identifying a correct answer should not be associated with a negative action (here, killing the foes). The prototype also proposes several rooms-with-question that require to directly type down the correct answer on the keyboard. According to the correctness or not of the answer, the right door or chest opens, or all foes die. Any incorrect answer leads to open an empty chest, open a door towards a dead end, or having no effect on the touched foe, but in all three cases, injuring the avatar. These situations were initially designed to vary the mode of response while providing similar room content, but were ultimately confusing.

As far as the progression perspective is concerned, we failed to provide a balanced way of collecting coins. Only chest-oriented gameplays (choose or write modality) can randomly contain '+1' or '+3' coins (or a 'heart'/life). Some purchased and activated rules may provide other ways to earn coins, but early successful dungeon levels may not result in any coins being earned. Moreover, the first purchased items are mainly those of the content category (extra hearts), preferred to rules. In addition, some teachers were not convinced about leaving learners free to buy and activate rules that push them to act faster, stressing them to answer quickly.

As mentioned earlier, the generation process may disable some activated rules that do not conform to the current configuration of the Completion 1 task. This can lead to feelings of confusion when discovering the generated dungeon levels.

Second Analysis

This second analysis was conducted for the design of the next multiplication tables training prototype.

Based on teachers' and learners' feedback, we worked with game designers to identify solutions and further directions, both from a game and training dimension.

As with the functional scope of the first prototype, the knowledge structure is still not taken into account, although all 5 task types are considered. The prototype will make it possible to manually parameterize the current training configuration for any children according to their individual progress (correspondence of a {objective, level} pair) of a learner's training path, cf. Figure 1).

Generation. The generated element (Q1) is still a dungeon level composed of organized room of two types: room without question, and room with one question associated to one of the types of task involved according to the training setup. Each room is composed of various interactive elements. This dungeon level is generated when (Q2) the player requests a new game level, from the hub-room (to start a new run) or after the debriefing screens following a successful dungeon level. From the game dimension, the generation continues to take into account the last level number and state (Q3) as well as the purchased and activated features. However, the purchasable (activatable) elements have changed. These elements are explained in the following categories. From an educational dimension, each generation considers the current configuration of the learner for all types of tasks involved (from 1 to 5), and takes into account the previous questioned facts and the previous results.

Death/Hurt. The player still gets hurt (Q4) when touching a foe, falling into a pit (game dimension), when answering incorrectly to a question or lacking of time (educational dimension). The main difference is that the question rooms will no longer have traps and game elements that can hurt the avatar other than those related to the question to be answered (Q6). Getting injured in a question room will always be caused by a wrong answer or a time-out. The consequences of an injury are not changed (Q5), it leads to the loss of a life, or death.

Variety. In the first prototype, the different types of rooms merged game elements and gameplays. In order to propose more varieties of rooms (Q7), we consider a new approach (see. the conceptual class diagram in Figure 4). On one hand, the types of tasks are mapped to different gameplay types according to the current tasks parameters. Every type of gameplay requires a quantified number of elements having the specified ability. On the other hand, the types of rooms describe some positions accepting different elements having a given ability. By extension, different types of game elements are associated to the abilities they can manage.

Combined, these elements will drive the generation of rooms and their built-in elements (Q8). As a result, the purchase mechanic now consists of players choosing items that will, if equipped (i.e., activated), unlock new types of gameplays that can occur in cer- tain rooms if they are consistent with the task associated to the room. By providing variants of game elements that share these abilities, game developers will increase the possibilities for variations. Let's take as an example the "boxing gloves" item, that allow the destruction of every "destroyable" elements (i.e., having an ability). Several elements can have "destroyable" as an ability: walls, pots, statues, rocks, etc. If the avatar is equipped with this item, it is possible to create multiple variants of gameplays. The mechanism remains the same, but the elements vary (e.g., destroy the wall, break the rock).

Progress. Equipment items are definitely purchased across runs. The coin mechanism is retained, but will be adjusted so the learners will earn one coin per correct answer. Questioned facts encountered and associated results are also saved beyond death. Therefore, the progression can be observed through: the equipments available, the number of coins, and fact results, i.e., available outside a game level (Q9).

Difficulty. The educational difficulty is maintained as in the first prototype, i.e., according to the parameters of the tasks supervised by the teachers (Q11). From a gameplay point of view, the progression according to the length of the dungeons is kept, but a new gameplay mechanism is added: the curses (Q10). The game progression will be structured in different minimum thresholds, unlocking curses that may or may not occur during the dungeon level to be generated (Q11). For example, if we consider thresholds every 3 dungeon levels, the generation of level #10 may involve at worst 3 curses, or 0 with luck.

Discussion

The first advantage of the framework is the traceability of design choices. Indeed, at each iteration, the choices are explained and then summarized. This traceability facilitates the evolution of the design without the risk of involuntarily going backwards. On the other hand, the visual synthesis (cf. Table 2) makes it possible to check that none of the dimensions has been neglected (i.e., presence of an empty box in case of neglect). In a prototyping approach, iterations are essential to fix certain settings. However, it would seem that the use of such a framework (i.e., allowing traceability as well as visual verification of the nonneglect of a dimension) could reduce the number of iterations required. Finally, this tool provides a support that can be understood by all stakeholders of the design process. However, the proposed framework takes into account a rather precise context: training or retrieval practice (i.e., a form of test-based learning) in the con-text of the Roguelite video game genre. Moreover, the criteria used are those that we consider essential. Consequently, other criteria might be considered essential by other researchers or game designers. In particular, some criteria depending on the application domains might be interesting to add.

RELATED WORK

The literature includes many frameworks and methods for games, serious games, game-based scenario design. However, many of them are mainly oriented towards and used for the analysis of already existing games [START_REF] Junior | Redefining the MDA Framework-The Pursuit of a Game Design Ontology[END_REF].

(De Freitas and Jarvis, 2006) proposed a fourdimensional learner-centered framework (Representation, Context, Pedagogy, Learner) to help design game-based learning scenarios. This approach is at a high level of design, which does not facilitate the transition from educational content to concrete game elements. [START_REF] Winn | Handbook of Research on Effective Electronic Gaming in Education[END_REF] introduced the DPE framework, an extension of the Mechanics, Dynamics, Aesthetics (MDA) framework [START_REF] Hunicke | MDA: A formal approach to game design and game research[END_REF] for serious games. This framework is broken down into three categories (design, play, experience; i.e., the designer designs the game, the player plays the game, which results in player's experience), each described by four criteria: Learning, Narrative, Gameplay, User Experience. [START_REF] Schell | The Art of Game Design: A Book of Lenses[END_REF] proposed a method consisting of a series of questions on different aspects to be taken into account for the design of the game. This method is more generic than ours (i.e., at a higher design level) because it does not focus on a specific type of knowledge or game genre. [START_REF] Amory | Game object model version II: A theoretical framework for educational game development[END_REF] described GOM II, a framework for the design of educational games extended from the Game Object Model (GOM). This framework considers that an educational game is composed of a set of elements described by abstract and concrete interfaces (based on the Object-Oriented paradigm). This work is theoretical and focuses on the general design of games rather than their concrete implementation. [START_REF] Arnab | Mapping learning and game mechanics for serious games analysis: Mapping learning and game mechanics[END_REF] proposed the LM-GM framework that enables the association of Learning Mechanics to Game Mechanics through the use of Serious Game Mechanics (SGM; "design decision that concretely realizes the transition of a learning practice/goal into a mechanical element of gameplay for the sole purpose of play and fun"). Nevertheless, this framework is more oriented towards the analysis of games than towards their design. [START_REF] Carvalho | An activity theory-based model for serious games analysis and conceptual design[END_REF] presented a conceptual model, called ASTMG, based on activity theory, which seeks to provide a better understanding of the relationships between the serious games elements and learning objectives/goals. This framework is also more oriented towards game analysis.

Many other framework and methodologies exists [START_REF] Yusoff | A Conceptual Framework for Serious Games[END_REF][START_REF] Barbosa | A New Methodology of Design and Development of Serious Games[END_REF][START_REF] Marne | The Six Facets of Serious Game Design: A Methodology Enhanced by Our Design Pattern Library[END_REF][START_REF] Kiili | Digital game-based learning: Towards an experiential gaming model[END_REF][START_REF] Silva | Practical Methodology for the Design of Educational Serious Games[END_REF]. Some works offer methods that are closer to some general game genre (i.e., adventure games, story oriented games for [START_REF] De Lope | Designing educational games: Key elements and methodological approach[END_REF]). However, these works are mainly generic (i.e., they are not specific to a type of knowledge or a game genre). Therefore, being in the specific context of the Roguelite genre, none of the existing works met our requirements. Nevertheless, these frameworks are not incompatible and can be used together. As examples: the framework proposed by [START_REF] Schell | The Art of Game Design: A Book of Lenses[END_REF] could be used to describe the general design of the game; the ASTMG [START_REF] Carvalho | An activity theory-based model for serious games analysis and conceptual design[END_REF] could be used to verify the coherency of each prototype. In short, the current frameworks that share our goal of assisting the design of learning games deal with different pedagogical objectives, different types of knowledge, different game genres. They do not aim to assist design in situations where the game genre is already identified because of its relevance to a specific learning objective. Our analysis framework is dedicated to Roguelite games for declarative knowledge retention: a very specific scope. Nevertheless, multidisciplinary teams also require specific frameworks to guide them deeper in the design of relevant, adapted, and balanced learning games.

CONCLUSION

This article 1) presented Roguelite as a suitable game genre for declarative knowledge training, and 2) introduced a design needs analysis framework for Roguelite-oriented learning game. The proposed framework gives a very first insight into the mechanism and choices that benefits both to the game and training dimension. The main idea is to allow a twodimensional design between the play and learning dimensions. This design aims at a separate description of the dimensions while allowing the verification (and maintenance) of both dimensions' conformity.

This framework was used in a prototyping design approach in the context of the AdapTABLES project. This project aims at creating a game for multiplication tables training. This article presents the application of the framework over two iterations: 1) the first iteration led to the current existing prototype, 2) the second iteration presents the design requirements of the future prototype.

In the future, we would like to apply this frame-

  . The objective was to specify the adaptations to take into account when considering the training of multiplication tables from a teacher perspective: what to consider (source and targets of the adaptations) and how to realize these adaptations. The main two results are: a model of the training organization into training paths, and the specification of 5 detailed training tasks.

Figure

  Figure 1: Knowledge Structure

Figure 2 :

 2 Figure 2: Roguelite Training Game Flow

Figure 3 :

 3 Figure 3: Screenshots of the current prototype features (text in French)

Figure 4 :

 4 Figure 4: Conceptual class diagram illustrating the domain elements and relationships involved in considering a wide variety of question pieces. Yellow concepts are to be generated; blue concepts are specifications of the game and didactic elements available; green concepts concern each learner-player.

Table 1 :

 1 Examples of parameters for the "Completion 1" training task

	Adaptable element	Possible Values	Some Examples
	Targeted Table(s)	From 1 to 12
	Multiplicand Position

Table 2 :

 2 Grid for Design Needs Analysis

	Criteria	Educational Perspective Perspective Game
		Q1
	Generation	Q2
		Q3
		Q4
	Death/Hurt	Q5
		Q6
	Variety	Q7 Q8
	Progress	Q9
	Difficulty	Q10 Q11

Table 3 :

 3 Design Needs of the prototype #1

	Criteria	Educational Perspective	Game Perspective
		Q1: What?	One task and one questioned fact per room-with-question	Dungeon + rooms + entry + exit
	Generation	Q2: When? Q3: Based on?	When a new game level is required "Completion 1" set-up Previous level number and state Current progress among possible facts Activated game elements or rules Task parameters have priority on activated game elements if conflict
	Death/Hurt	Q4: What? Q5: When?	Being touched by foes, falling into holes Injuring causes heart lost, no more hearts causes death Incorrect answers or time out
		Q6: Where?	Question rooms	Any room with foes or holes
	Variety	Q7: What? Q8: How?	Facts Progress and past results	Rooms with gameplay and content Random
	Progress	Q9: What?	Success or failure on met questioned facts	Coins collected during successful game levels + purchased elements
	Difficulty	Q10: What? Q11: How?	Questioned facts In relation with the task parameters	Dungeon level length + dark mode According to previous level number and state

Table 4 :

 4 Design Needs of the Future Prototype (Bold describes changes from the first analysis). Progress and past results Based on the available equipments, gameplays, elements, and in relation to the tasks ⇐⇒ gameplays mappings

	Criteria	Educational Perspective	Game Perspective
		Q1: What?	One task and one questioned fact per room-with-question	Dungeon structure + rooms
	Generation	Q2: When? Q3: Based on?	When a new game level is required All tasks set-up Previous level number and state Current progress among possible facts Equipped items Task parameters have priority on activated game elements if conflict
	Death/Hurt	Q4: When? Q5: What?	Being touched by foes, falling into holes Injuring causes heart lost, no more hearts causes death Incorrect answers or time out
		Q6: Where?	Question rooms	Only rooms with no question
		Q7: What?	Facts	Different types of rooms, types of gameplays, types of elements
	Variety
		Q8: How?
	Progress	Q9: What?	Success or failure on met questioned facts	Coins collected during successful game levels + purchased items
	Difficulty	Q10: What? Q11: How?	Questioned facts In relation with the task parameters	Dungeon level length + curses According to previous level number and state

work to other fields of application than mathematics. Currently, we are working on its application to history-geography facts (e.g., historical dates, countries of the European Union).


Bérénice Lemoine
email: berenice.lemoine@univ-lemans.fr

Pierre Laforcade
email: pierre.laforcade@univ-lemans.fr

Sébastien George
email: sebastien.george@univ-lemans.fr

Mapping Task Types and Gameplay Categories in the Context of Declarative Knowledge Training

Keywords: Serious Game, Didactic, Design, Training, Declarative Knowledge, Gameplay

Learning games for the training of declarative knowledge must offer learners a wide variety of game situations in order to keep them engaged. Designing such situations remains a challenge due to the inherent entanglement of didactical objectives and gaming implementations. This article proposes to tackle the need for mapping different training tasks to different gameplays in order to help the design of relevant gameplayoriented training situations. We identified an approach during the design of a Roguelite-oriented training game for multiplication tables. This approach has been intentionally specified towards a genericity purpose by using domain-independent task types and abstract gameplays. This article details the method we followed to identify this approach and presents the resulting mappings when applied to our specific application context.

INTRODUCTION

This last decade, the design and use of learning games has become a common practice [START_REF] Codish | Detecting playfulness in educational gamification through behavior patterns[END_REF]. However, most learning games fail to be seen as real video games mostly because of their lack of gameplay (i.e., fun elements that can be controlled, decided and done by the players) [START_REF] Prensky | Computer Games and Learning: Digital Game-Based Learning[END_REF]. Although combining the fun of real game and educational content is not easy [START_REF] Prensky | Computer Games and Learning: Digital Game-Based Learning[END_REF], it is a key component of a good learning game design. Combining the two dimensions (i.e., game and education) is difficult, primarily because there are multiple variables to consider. Moreover, these variables often depend on the knowledge to be learned and the targeted game genre.

Learning games targeting declarative knowledge training require a deeper commitment from learners as they are used regularly for repetitive training sessions. This implies that the design of such learning games must offer a wide variety of situations, game mechanisms or gameplays. Designers then have to deal with various stakes such as the dynamic generation of training sessions or the adaptation of these sessions to take into account the different teachers and/or learners' needs or preferences. This also includes de-signing how the variety of situations will be tackled.

Our research interest is about that challenge. We focus on it by considering the design of varied gameplays. These gameplays involve that the playerlearner makes the avatar, which he/she controls, interact with the environments and objects in the game to perform contextualized actions to answer the question being asked. Because training games include several domain-specific parameterized training tasks, many gameplays have to be identified for each one of them. Identifying how different training tasks can be implemented using these different gameplay concepts requires conceptualizing and addressing a transdisciplinary TEL (Technology Enhanced Learning) problem: how can didactic knowledge be mapped to different gameplays?

We encountered this challenge during the design of a Roguelite oriented learning game to train the retention of the multiplication tables. First, we identified an approach that involves addressing the challenge at a higher level of abstraction (task types instead of domain-specific tasks and game categories instead of practical gameplays). This allows for a more generic and domain-independent approach. Secondly, the main thrust of the approach is to use a dedicated pivot to help identify the source (task types) and target (gameplay categories) parameters whose values will guide the elicitation of practical mappings. This paper explains how we identified this approach (method), what this approach consists in (proposal), and which mappings are obtained in our context (application). We assume that this approach is sufficiently generic and reusable to contribute to helping multidisciplinary design teams identify and map gameplays for their domain-specific tasks (contribution).

In cognitive psychology, test-based learning represents the idea that the process of retrieving (i.e. remembering) concepts or facts increases their longterm retention. While tests are mainly used as summative assessment tools, they can also be formative. Repeated retrieval (i.e., retrieval practice) is one way to implement test-based learning, which has been shown to improve long-term retention in research [START_REF] Roediger | Inexpensive techniques to improve education: Applying cognitive psychology to enhance educational practice[END_REF][START_REF] Brame | Test-Enhanced Learning: The Potential for Testing to Promote Greater Learning in Undergraduate Science Courses[END_REF]. In addition, research also suggests that various test formats enhance learning (i.e. the benefits are not linked to a specific type of retrieval practice) [START_REF] Brame | Test-Enhanced Learning: The Potential for Testing to Promote Greater Learning in Undergraduate Science Courses[END_REF]. In our work, training means providing the learner with different forms of questions repeatedly, which is a form of retrieval practice.

The structure of this paper is as follows: Section 2 presents our research context including our gaming (Roguelite genre) and learning (training of multiplication facts) contexts as well as the mapping issue; Section 3 draws current close research studies for tackling this challenge; Section 4 details how the identification of the mapping approach we propose has been conducted; Section 5 presents the resulting approach and its application in our specific context; Section 6 discusses the next challenges to overcome, mainly about formalizing and exploiting the resulting mappings to drive the generation of adapted training sessions.

RESEARCH CONTEXT

Our research interest is about generating effective and engaging training sessions for the retention of declarative knowledge. Declarative knowledge (i.e. knowledge about facts, laws, statements, etc.) are known to require repetition for encouraging their memorization, generalization, and retention [START_REF] Kim | An integrated theory for improved skill acquisition and retention in the three stages of learning[END_REF][START_REF] Roediger | Inexpensive techniques to improve education: Applying cognitive psychology to enhance educational practice[END_REF]. Our concern is about identifying approaches, models, and processes helping multidisciplinary teams in designing learning games targeting such training. Nevertheless, creating activities combining fun and educational content is not an easy job [START_REF] Prensky | Computer Games and Learning: Digital Game-Based Learning[END_REF]. To that extent, Prensky proposed a three steps process to create digital gamebased learning: "(1) Find or create a game with great gameplay that will engage our audience, (2) Find the learning activities and techniques that will teach what is required (doing each with the other in mind), and then (3) successfully blend the two".

A Roguelite for Multiplication Tables Training

As a first application domain, our research takes place into the context of the AdapTABLES project1 which aims at designing and developing a learning game for the training of multiplication tables. It implies the design of a generator for providing game levels during training sessions. It is worth notice that practicing multiplication tables will complement classroom learning (from the teacher's point of view): learning the tables, application in problem-solving, and generalization are outside the scope of the learning game. This project involves mathematical teachers and didactic experts, as well as game designers and serious game experts.

In addition, we studied different game genres in order to identify those capable of keeping players engaged while providing repetitive but various gameplays. The Roguelite game genre meets these needs. It is mainly characterized by procedural dungeon generation with randomized content, permanent death (each avatar's death implies for the player to start a new playthrough), and limited retention of unlockable game elements (characters, items, powerups, ...).

Hadès, Rogue Legacy, Binding of Isaac are well known Roguelite video games. They also share a dungeon-crawler approach: the player has to explore dungeons made up of interconnected rooms where actions take place. Therefore, Roguelite combines all necessary prerequisites for training declarative knowledge (i.e., generation → variety, repetition, and it is a well-known and liked game genre). Briefly, learners-players will get across successive generated dungeon levels, wherein most of the rooms will challenge them to answer task-oriented questions.

Abstract Training Task Types

In an exploratory research, partially presented in [START_REF] Laforcade | Expressing adaptations to take into account in generator-based exercisers: An exploratory study about multiplication facts[END_REF], a user group composed of 2nd to 6th grade teachers and mathematics experts has identified several tasks for training multiplication tables, such as: complete a fact where the result is missing, complete a fact where the operand is missing, decide if a fact is correct, identify the results of a table. These tasks also embeds dedicated parameters in order to drive which facts to consider, how to build them and how to answer them.

In a perspective of genericity with other domainrelated declarative knowledge, we abstracted them into 5 task types:

1. Completion 1: complete an incomplete fact that has one missing element (e.g., 3×? = 15, 15 = ? × 5, 3 × 5 = ?);

2. Completion 2: complete an incomplete fact that has two missing elements (e.g., ?×? = 15 with a set of given choices [3, 6, 5, 10], ? × 5 = ? or 3×? = ? also with sets of given choices);

3. Reconstruction: replace, in the correct order, all important elements of a fact (e.g., ?×? = ? with a set of given choices [3,6,5,10,15]);

4. Identification: identify the correctness or incorrectness of one or several facts (e.g., 3 × 5 = 15, true or false?);

5. (Non-)Membership Identification: identify the elements that share or do not share a given property (e.g., [3,5,9,12,14,21] which are results of the table 3?);

These task types do not claim to be exhaustive. They only cover the specific multiplication tables tasks and are expressed at a higher level of abstraction.

Abstract Gameplay Types

As mentioned by [START_REF] Prensky | Computer Games and Learning: Digital Game-Based Learning[END_REF], the main reason for learning game failure is their lack of gameplay. Therefore, we intend to provide a variety of possible gameplays. To that extent, informal interviews were conducted with game designers to gather possible ideas which lead to the design of gameplay mockups. A game prototype with a few gameplays was created to test some ideas and collect some feedback.

One observation was made after the design of the mock-ups: some gameplays seemed to belong to the same category (e.g. breaking the pot wearing the answer and opening the chest wearing the answer are two similar ways of selecting an object). This observation followed the idea of the game classification proposed by [START_REF] Djaouti | A Gameplay Definition through Videogame Classification[END_REF] which consists in describing games through gameplay bricks (i.e., categories of actions that can be performed within the games). Consequently, further reflexion led to the definition of 5 categories of gameplay in our context (as for the task types, these categories do not claim to be exhaustive):

1. SELECT: select (e.g., touch, kill, break, open) objects wearing the correct answers, through avatar actions;

2. MOVE: correctly place objects at specific locations through avatar actions;

3. ORIENT: orient objects (e.g., rotate), through avatar actions, towards the correct answer;

4. POSITION: move the avatar to the necessary positions for choosing or typing the correct answers;

5. DIRECT RESPONSE: no action is required through the avatar, learners can directly type down their answer by using an input device (e.g., enter the correct answer through a keyboard).

Figure 1 presents a gameplay mock-up for each category.

Research Questions

Following Prensky's process, our main question now is: how to determine and specify the relationships between task types and game categories necessary to the design of learning game activities? Indeed, knowing these relationships is important at design-time to guide the identification of practical gameplays for every specific tasks, and at run-time to drive the generation process. We assume that answering this question at a higher level of abstraction (task types and abstract gameplays) will allow these relationships to be reused in different declarative knowledge contexts.

This research question (i.e., illustrated in Figure 2) consists of answering more precisely to the following questions: Which kinds of abstract gameplays are suitable for which task types? Is the mapping system- According to [START_REF] Tchounikine | A Computer Science Perspective on Technology-Enhanced Learning Research[END_REF], this is typically a problem of research in TEL engineering falling into the "elaborating powerful abstractions" case where the problem must be addressed from a transdisciplinary perspective.

Previous works have addressed the problem of relationships identification between the educational and game dimensions. The following section aims to position our work in relation to these existing works.

RELATED WORK & POSITIONNING

Several existing works have focused on determining the relationships between educational elements and game elements. A pioneer is [START_REF] Prensky | Computer Games and Learning: Digital Game-Based Learning[END_REF], who proposed compatible game genres (e.g., action, roleplay, adventure) with knowledge to be learned (e.g., facts, skills, judgement, behavior) and learning activities (e.g., questions, experiments, observation). An extension to this work, consisting of adding a relation to the learning styles (i.e., activists, reflectors, theorists, and pragmatists) of [START_REF] Chong | The impact of learning styles on the effectiveness of digital games in education[END_REF] has been proposed by [START_REF] Rapeepisarn | The Relationship between Game Genres, Learning Techniques and Learning Styles in Educational Computer Games[END_REF]. Like wise, [START_REF] Sherry | Matching computer game genres to educational outcomes[END_REF] defined relationships between some game genres and the 6 levels of Bloom's taxonomy [START_REF] Bloom | Taxonomy of educational objectives: The classification of educational goals[END_REF]. Similarly, (Gosper and Mc-Neill, 2012) proposed a framework to support the integration of technology in education. This framework defines relationships between learning outcomes (e.g. acquisition of basic facts, automation of skills and concepts), learning processes (e.g. memorization, analogical reasoning, proceduralization), assessment (e.g. self-assessment, peer assessment) and game genres. Although these works are very interesting for the general design of learning games, the identified relationships are not usable at a specification stage for guiding the definition of practical gameplays.

Some work attempts to provide relationships at a specification level. [START_REF] Dondi | A methodological proposal for learning games selection and quality assessment[END_REF] linked learning objectives (e.g., memorization/repetition/ retention), knowledge types (e.g., factual knowledge), and game genres to high-level features that games should possess (e.g., presence of content engine, assessment engine). However, these high-level features do not describe how the relationships are to be implemented in practice.

Other works offer a framework to specify relationships (i.e., either for analyzing existing games or conceiving one). The LM-GM framework [START_REF] Lim | The LM-GM framework for Serious Games Analysis[END_REF] supports the transition from learning objectives/practices to game elements through a concept called Serious Game Mechanic (SGM). It defines learning mechanics and game mechanics and uses SGM to associate both concepts. However, the presented mechanics are high-level ones (e.g., guidance, collaboration, explore) and the relationships are not meant to be implemented as such. Furthermore, [START_REF] Hall | Instructional objectives to core-gameplay: A serious game design technique[END_REF] proposed a framework to guide the designer in specifying the transition from learning content to core-gameplay. It is composed of 5 categories (i.e., goal, choice, action, rules, feedback) in which a series of questions need to be answered from a realworld and a game-world perspective. However, the framework is more oriented towards the general design of the game rather than its implementation.

In conclusion, existing approaches are more oriented towards defining relationships for analysis purposes or to assist in the high-level design of games rather than specifying relationships for low-level design purposes. Indeed, they address specific learning targets or the contexts of specific game genres, as we do. In our context, we seek to propose an approach to specify relationships between declarative knowledge training tasks and gameplays from the Roguelite genre. These relations need to respect one condition: their specification must allow their implementation.

It is well known that the training and evaluation of declarative knowledge is done through questionnaires/quizzes. Moreover, numerical quizzes, compared to paper ones, allow for user interactions that are closer to the ones we can found into basic training games (for example a multiplication table training games where correct answers make the avatar running faster or jumping to higher platforms). Therefore, using exercises types from quizzes formats as a pivot (i.e., a way to close the gap between task types for declarative knowledge training and gameplay categories) seemed interesting in particular because the use of existing content is a way to reduce subjectivity. Therefore, our work intends to propose a systematic mapping approach based on the use of quizzes exer-cises types as a pivot. The next sections present the development of our approach, followed by the proposed approach and an application example.

APPROACH DESIGN

Several steps were necessary to the elaboration of our mapping approach. At first, we conducted an analysis of quizzes design formats to define the types of existing exercises (i.e., our pivot), after which the following questions appeared: (1) How can we draw a parallel between the types of tasks and the exercises identified? (2) How can we draw a parallel between the gameplay categories and the exercises identified? As previously mentioned, the interactions offered by each quiz exercise are closer to games' interactions. Moreover, every concept (i.e., task types, gameplay categories, and exercises) are characterized by their possible response modalities (e.g., enter one answer, choose between X propositions). Therefore, our second step consisted in using the exercises types to identify possible criteria and parameters in order to specify the task types and gameplay categories and ease the identification of the mappings. The last step consisted in using these parameters values (from both task types and gameplay categories perspectives) to compare and identify matches.

Identification of the Pivot

Foremost, we analyzed the proposed exercises types of 6 formats, mostly extracted from Learning Management Systems (LMS), allowing the creation of numerical questionnaires/quizzes:

• the eponymous and proprietary format from the itsLearning (#1) LMS;

• GIFT (#2) a markup language for describing tests that is associated to the Moodle LMS;

• Performance Matters Assessment and Analytics (#3) format associated to the PowerSchool LMS;

• NetQuizzPro (#4) a software allowing the creation of questionnaire;

• QTI (Question & Test Interoperability specification) (#5) from the IMS global learning consortium that defines a standard format to exchange and store assessment content;

• Tactileo -Maskott (#6) format associated to the French pedagogical platform of the same name.

This analysis lead us to the definition of 12 different types of exercises useful for declarative knowledge (i.e., only exercises for which the verification of the results can be automatized). Mainly the analysis consisted of a comparison of the exercises in terms of what they allow. Exercises (of different format) that shared the same type of statement, the same number of desired answers and for which the interaction of answers was similar have been merged to compose a single exercise type. Furthermore, some formats combine several exercises into one (i.e., multiple choice and answers were merged in the format of itsLearning). In these cases, we considered them to be two independent exercises. Moreover, the possibility of having intruders (i.e., elements not to be associated) was something asked by domain experts, however, none of the "Associate" type of exercise analyzed from the formats offer that possibility. Therefore, it was considered as a possibility in our type of this exercise definition. The final types of exercises defined are:

• Alternative: choosing one answer between 2 options; • Multiple choice: choosing one answer between X (i.e., X ⩾ 2) options; • Multiple responses: choosing Y (i.e., zero or more) answers between X (i.e., X ⩾ 2) options; • Short answer: enter the correct answer. Multiple form of answers can be accepted, e.g., for example, How much is 3 times 5? as two possible answers, which are 15 and fifteen; • Fill-in-the-blanks: enter for each gap of a text the wanted "short" answer; • Fill-in-the-blanks choices: choose for each gap of a text the correct answer from a list. Each gap can have an associated list of options, or one list can be associated to all gaps; • Reconstruction: reassemble, in the correct order, each significant element of an information; • Associate-Group: associate elements from a list or multiple lists together. The association can be done by pairs, or not. The elements can be associated with zero to several other ones; • Order: replace a set of information in the correct order; • Graphic choice: point or locate X (i.e., X ⩾ 1) elements on a picture. • Graphic identification: write the correct label for each area-to-complete of a picture; • Graphic association: associate the correct labels to X areas of a picture. As a reminder, these types of exercises aim at dealing with declarative knowledge in general, not just multiplication tables. Therefore, some exercises offer a more visual approach that could be useful, for example, in the context of geographical facts. An overview of which format allows for which exercises is presented in Table 1.

#1 #2 #3 #4 #5 #6 Alternative ✓ --✗ ✗ ✗ Multiple Choice ✓ ✓ ✓ ✓ ✓ ✓ Multiple Resp. ✓ ✓ ✓ ✓ ✓ ✓ Short Answer ✗ ✓ ✓ ✗ ✓ ✓ Fill-in ✓ -✓ ✓ ✗ ✓ Fill-in Choice ✓ -✗ ✓ ✓ ✓ Reconstruction ✗ ✗ ✗ ✓ ✗ ✗ Association ------ Order ✓ ✗ ✓ ✓ ✓ ✓ G. Choice -✗ -✗ ✓ - G. Identification ✗ ✗ ✗ ✓ ✗ ✗ G. Association ✗ ✗ ✗ -✓ ✓
These exercises are characterized by several parameters, such as: their interactions, their response modality (i.e., input or choice), their statement type (i.e., format of the question asked), the number of answers desired, and the number of propositions presented (i.e., if the response modality of a concrete task of this type is "Choice"). Through our analysis, 6 types of interactions were identified: Select Y From X (i.e., the learner must select Y answers from a set of X values); Y (Select 1 from X 1 to X Y ) (i.e, the learner must make a selection of one answer from each set of proposals); a variant is Y (Select 1 from X) (i.e, the learner must select Y answers, one by one, from a set of proposals.); Write X (i.e., the learner as to enter X answers); Order X (i.e., the learner must order X elements correctly); Point X or Locate X (i.e., the learner must point X elements on a picture or locate them); Match Y with X 1-to-1 or Match Y with X (i.e., the learner must associate elements from Y with those from X by pairs or not). In addition, 3 types of statement were found: 1) classic statement (i.e., simple text question), 2) graphic statement (i.e., text question accompanied by an image), and 3) To fill-in statement (i.e., question separating textual elements with other types of elements such as answer boxes). Table 2 presents the exercises through their characterization. It is important to note that none of the formats allows for all possible forms of exercise.

Mapping Task Types to Game Categories

Now that the pivot is specified, the remaining questions are: How to match (1) task types to exercises, and (2) game categories to exercises? The main idea is to use some of the parameters that characterize each concept (i.e. task types, gameplay categories and exercises) to map them.

Task Type to Exercises

Task types are characterized by several parameters, which are: the number of facts targeted by the task, the types of statements allowed for such a task, the response modalities, the number of desired responses, and the number of propositions presented (i.e., if the response modality of a concrete task of this type is "Choice"). For example, the Completion 1 type is characterized as follows: one fact is targeted, all statement types are allowed (i.e., classic, graphic and To fill-in), both response modalities can be used (i.e., input and choice), only one response is desired and at least 2 propositions must be presented if the modality equals Choice. Nevertheless, the assignment of parameter values is not an easy task. At first sight, it could seem possible to carry out a task of the Completion 2 type through the response modality Input. However, presenting a statement in the context of declarative knowledge, such as "?×? = 12", does not give enough information about the fact to work with (i.e., is it 3×4 or 6 × 2). As another example, for a Completion 2 task, it is possible to choose one or two answers. This depends on how the choices are presented. If the set of propositions represents numbers, such as [3,5,7,4], two answers must be chosen. However, if each proposition is presented as a multiplication (without the result), such as [3 × 4; 4 × 5; 6 × 3], then only one answer is required. Table 3 presents the task types through their characterization. Thus, except for the interactions, task types and exercises are characterized by the same parameters.

Consequently, the mapping consists in comparing the shared parameter's values between task types and exercises. For examples, Completion 1 corresponds to Short answer because the specification of Short answer, i.e., {number of facts = 1; type of statement = classic; modality = input; number of desired answers = 1}, is a possible configuration of a concrete task of the type Completion 1 (i.e., the parameter values are included into those of the type Completion 1). This gives questions such as "What times 5 equals 15?" and "What does 3 times 5 equal?". Completion 1 also corresponds to Fill-in-the-blanks choices exercise specified as {number of facts = 1; type of statement = to fill-in; modality = choice; number of desired answers = [1 -∞]; number of choices = [2 -∞]}. This gives questions such as " times 5 equals 15".

Thanks to these mappings, each task type can also be described by its possible interactions (i.e., the interactions of the exercises corresponding to the task type considering the number of requested answers). As an example, the Short answer exercise type asks the learner to write down one short answer to a textual question. Thus, its interaction parameter as for value Write 1. A task of the Completion 1 type could ask questions such as "What does 3 times 5 equal?", leaving the learner to write down 15. Therefore, Completion 1 has Write 1 for possible interaction. As a result of all mappings, Completion 1 can be achieved through the following interactions: Select 1 from X (i.e., X ∈ [2, ∞]), Write Y (i.e., Y is the number of wanted answer therefore Y = 1), Y (Select 1 from X), Point Y or Locate Y, Match Y with X 1-to-1.

Gameplay categories to Exercises

Each game category represents gameplays that are similar in terms of the actions to be performed, such as opening the right chest, choosing the right pot, passing through the right bridge which belong to the SELECT category. Therefore, the common parameters of these gameplays (e.g., number of facts interrogated, number of possible answers) represent those of the category itself.

After analysis, we characterized these categories by the following parameters: the interactions, the response modality (i.e., input or choice), the statement type (i.e., format of the question asked), the number of facts targeted, the number of answers desired, and the number of propositions presented (i.e., if the response modality of a concrete task of this type is "Choice"). These parameters are quite similar to those used for the exercises. They represent a minimal and relevant set of parameters that allow us to discriminate the different categories and gameplays. As an example, the SELECT category is characterized as follows: 1 to many facts can be targeted, both classic and to fill-in statement types are allowed, choice is the only possible response modality, 1 to many answers can be desired, and two interactions (i.e., Select Y from X, and Y (Select 1 from X 1 to X Y )) are possible.

However, during the characterization phase, we realized that the possible interactions and the type of statement changed depending on whether one or more responses were desired. Therefore, in order to simplify the mappings, each category allowing one to multiple possible responses was divided into two subcategories: single (i.e., only one possible response) and multiple (i.e., 2 to many possible responses).

As a result, our 5 categories turned into 9. Table 4 presents the gameplay categories through their characterization. Afterwards, the mapping consisted in directly comparing the parameter's values.

Task Type to Gameplay Categories

From there, we disposed of all the necessary information to answer our main question: Which task type are suitable for which gameplay categories? What are the conditions?

The final step consisted in comparing the task types and categories on the basis of their parameter values (i.e. comparing Table 3 with Table 4). During that step, we observed that 2 parameters represented mapping conditions based on their values: the type of statement and the response modality. Therefore, the obtained relationships are quadruplet composed as follows: (<task type>, <statement type>, <response modality>, (<category1>, <category2>, . . . )). Each task type can have from 1 to 6 associated relationships.

In conclusion, this section has presented the process followed to map the task types for declarative knowledge training to gameplay categories for the Roguelite video game genre. The next section will present the results obtained.

RESULTS

The presented work led to two contributions: (1) an approach to map designers' own task types to their own categories of gameplays, and (2) mappings between our own task types with our gameplay categories.

A Mapping Approach

Our proposal consists of a two to five-steps approach, illustrated in Figure 3. The initial steps are to:

1. abstract the concrete tasks by using the types of tasks presented (e.g. a task "associate the right date with the historical event" becomes complete a fact with a missing element) or by creating new task types;

2. associate the gameplay to one of the categories presented or to a new category.

From here, four states are possible: new task types and categories have been created, only new task types have been created, only new gameplay categories have been created, or nothing has been created. Depending on the condition, the instructions below must be followed:

1. If new task types and new gameplay categories were created:

(S) 1 Classic Choice 1 2 to ∞ Select 1 from X To fill-in SELECT (M) 1 to ∞ Classic Choice 2 to ∞ 2 to ∞ Select Y from X To fill-in Y (Select 1 from X 1 to X Y ) MOVE (S) 1 Classic Choice 1 2 to ∞ Select 1 from X Graphic Point 1 or Locate 1 To fill-in Match 1 with 1 MOVE (M) 1 to ∞ Choice 2 to ∞ 2 to ∞ Match Y with X Classic Point Y or Locate Y Graphic Select Y from X To fill-in Y (Select 1 from X 1 to X Y ) ORIENT (S) 1 Classic Choice 1 2 to ∞ Select 1 from X To fill-in ORIENT (M) 1 to ∞ Classic Choice 2 to ∞ 2 to ∞ Y (Select 1 from X 1 to X Y ) To fill-in Y (Select 1 from X)

POSITION (S) 1

To fill-in 1

Input 0 Classic Select 1 from X Graphic Choice 2 to ∞ Point 1 or Locate 1 POSITION (M) 1 Graphic Input 2 to ∞ 0 Write Y DIRECT RESP. 1 Classic Input 1 0 Write 1 (a)
The first step is to characterize the task types using the six parameters defined above (i.e., number of facts, types of statements, response modalities, number of desired responses, number of propositions, and interactions). In a substep, the mapping between task types and quiz exercises (see Table 2) must be done to define the values of the interactions parameter. (b) The second step is to characterize the gameplay categories using the same parameters. (c) Finally, the last step is to compare both tables (i.e., characterization) through their values. As a reminder, the values of the Statement Type and the Response Modality parameters are possible conditions of the relations.

2. If only new task types were created, then realize step 1a and step 1c.

3. If only new gameplay categories were created, then realize step 1b and step 1c.

4. If no new elements have been created, the work is already done, cf.

Resulting Mappings

As a result of the process presented in section 3, several conditional relationships were identified between each task type and the gameplay categories.

These relationships are presented in Figure 4. If the categories do not have (S) or (M), it means that both are present.

For example, the task type Identification has two relationships: (Identification, Classic, Input, (Position (S), DIRECT RESPONSE)) and (Identification, Classic, Choice, (SELECTION (S,M), MOVE (S,M), ORI-ENT (S,M)).

DISCUSSION & FURTHER WORK

This section discusses the limitations of our work, presents an experiment to validate some mappings, and outlines a way to model the identified relationships.

Figure 4: Conditional relations between task types and gameplay categories.

Extension of the resulting mappings and genericity

Our approach revealed some limits. First, due to the non-exhaustiveness of our task types, all possible exercise types are not covered (i.e., this is the case of Order). It is mainly due to our method: we intended to start with a very first domain context while abstracting tasks types and gameplay categories. It is a very first step towards proposing a complete domainindependent and generic approach. Consequently, other domains than multiplication tables have to be considered to cover, and refine if necessary, our proposal. It is also possible that the current task types have to be modified or extended to cover all exercise types. In particular, we are currently studying a second domain, consisting in the history and geography declarative knowledge necessary to obtain the French diploma "Diplôme National du Brevet" (present in the 9th grade).

Validation of the mappings

In order to gather feedbacks on the gameplay mockups (i.e., to identify relevant gameplays and game elements), we proposed to the members (≈ 10 persons) of the user group (of the project AdapTABLES) a survey presenting possible gameplays for each type of task. This experimentation was also an opportunity to validate some mappings (i.e., the relations for which the categories have existing gameplay mockups). As the experiment is situated in the context of multiplication tables, none of the mappings with the condition "Graphic" are evaluated here. However, since mock-ups of each compatible categories for each task types were created, other mappings are evaluated here. Let's take the example of a gameplay consisting in selecting the right pot among several pots bearing propositions (i.e., SELECT with Choice) to answer a textual question of the type "3×? = 15" (i.e., Completion 1). If this gameplay is validated by the survey, then so is the relationship (Completion 1, Classic, Choice, SELECT).

According to the first results, the mappings presented seem relevant. Negative comments are generally related to the lack of precision of some information or to didactic problems. For example, MOVEtype gameplays requiring objects to be placed in the correct answer areas were rejected because the objects would hide the answers, thus impacting learners' thinking. The issue is not related to the mechanics (i.e., moving objects to predefined areas), but a cognitive one that can be corrected. A basic solution would be to display the value above the selected object. An alternative would be to display the chosen value in the statement at the right position using a different color. Figure 5 illustrates the latter solution: the statue pushed on the left tile hides the associated '5' value, but this value appears now in purple in the room's statement.

Furthermore, the mock-ups of the ORIENT game have received mixed reviews. This is due to the fact that the object chosen to be oriented (i.e., directing the light of a streetlamp) lacks cognitive meaning. Therefore, other mock-ups should be proposed to properly assess the relationships associated with the ORIENT category.

Modelling the mappings

As mentioned earlier, our overall goal is to build a generator of Roguelite oriented learning game activities for declarative knowledge training.

The originality of our overall work is the use of Model-Driven Engineering (MDE) [START_REF] Kent | Model Driven Engineering[END_REF] tools and principles to design the generator. The idea is to specify all the information (domain-dependent tasks, task types, game categories, gameplays, game elements and relationships) in different, interconnected models that are consistent with a dedicated metamodel that we are also specifying. Therefore, each generation could be considered as a model transformation according to MDE.

Figure 6 proposes a first insight of the part of this metamodel focusing on the mapping structure defined in this article. The resulting mappings will be specified as a model in conformance with this metamodel extract. The domain-dependant tasks, as well as the specification of the concrete gameplays, and their implementations into game elements, are not depicted in the figure. As an overview of the mapping process followed at runtime, here are the main steps starting from a given identified domain-dependent task:

1. get the associated task type;

2. collect all relations from the mapping model that are related to this task type;

3. restrict the collected relations to those whose associated condition is satisfied by comparing the statement and modality values of the condition to those of the original task;

4. collect the gameplay categories of the remaining relations.

The generation algorithm will then handle further steps such as selecting the gameplays implementing these game categories, filtering them according to other information (e.g. which gameplays are unlocked and available for this learner-player), instantiating the game elements composing the chosen gameplay, etc.

CONCLUSION

To conclude, this paper introduced an approach to map task types for declarative knowledge training to Roguelite oriented gameplay categories. The originality of this work lies on two points. Firstly, the proposed approach is based on the use of a pivot (i.e., exercises in the form of questionnaires). Secondly, it is oriented towards automating the design of learning game activities (i.e., generation) and therefore specifies fine-grained relationships.

In the future, we plan to: (1) continue the analysis of the second application domain in order to have generic task types with declarative knowledge; (2) focus on specifying gameplays in terms of game elements; and (3) model relationships (and other concepts) to implement a first version of the generator.

  Example of mock-ups by gameplay categories

Figure 2 :

 2 Figure 2: Our Research Question atic or conditional? If conditional, how to find these conditions?According to[START_REF] Tchounikine | A Computer Science Perspective on Technology-Enhanced Learning Research[END_REF], this is typically a problem of research in TEL engineering falling into the "elaborating powerful abstractions" case where the problem must be addressed from a transdisciplinary perspective.Previous works have addressed the problem of relationships identification between the educational and game dimensions. The following section aims to position our work in relation to these existing works.

Figure 3 :

 3 Figure 3: Proposed Mapping Approach.

  Figure 4. Let's take as example a task type T1 characterizes as such {number of facts = 1; type of statement = classic; modality = input or choice; number of desired answers = 1}, and a gameplay category C1 = {number of facts = [1 -∞]; type of statement = classic or to fill-in; modality = choice; number of desired answers = [1 -∞]}. In this case, only one relationship would result: (T1, Classic, Choice, C1).

Figure 5 :

 5 Figure 5: Second solution example.

Table 1 :

 1 Exercises by quiz format (✓ present; ✗ absent; -present but incomplete).

Table 4 :

 4 Characterization of the gameplay categories ((S) = Single; (M) = Multiple).

	Number Statement Response Number Number of of Facts Types Modality Answers Choices	Interactions
	SELECT

https://projets-lium.univ-lemans.fr/adaptables/

ACKNOWLEDGEMENTS

We thank all the members of the user group (teachers and didactics experts) as well as the game designers without whom our research would not be successful. Figure 6: Example of EMF Ecore Modelling for relationships, task types and gameplays.