iPlus a User-Centered Methodology for Serious Games Design

Abstract

Standard video games are applications whose development process often follows a traditional software methodology. Serious Games (SGs) are a tool with an immensely positive impact and great success. SGs enable learning and provide entertainment and self-empowerment, which motivates students. The development of an SG consists of complex processes requiring multi-disciplinary knowledge in multiple domains, including knowing the learning domain and adding the appropriate game mechanics to foster high intrinsic motivation and positive player experience that makes the players feel like they are having fun while learning. Otherwise, the game is viewed as boring and not as a fun and engaging activity. Nevertheless, despite their potential, the application of SGs in education has been limited in terms of pedagogy. Several authors assert that this lack is because SG standards and guidelines have not been developed. There is an imbalance between experts’ contributions to education and game design specialists for the SG development. Not all the SGs that have been developed have applied appropriate design methodologies that incorporate both the entertainment mechanics and the serious component. To ensure that an SG meets the user’s expectations, it must be designed using an appropriate method. This work aims to present iPlus, a methodology for designing SGs based on a participatory, flexible, and user-centered approach. Additionally, this paper analyses several case studies with the iPlus methodology.

1. Introduction

The education system has changed rapidly with the development of learning technologies. Rote and non-participatory activities are left behind in support of analytical and research skills that require students to use technological tools. However, despite new implementations, one also sees a rising school dropout level, perhaps due to students’ decreasing motivation to learn. This problem has generated the necessity to define innovative learning strategies that help to revert this trend.

The new generation requires taking advantage of the motivational aspects generated by technology. Serious games (SGs) are considered a modern alternative to traditional learning. Chipia [1] states that SGs help provide an entertaining and self-empowering that motivates students. The term refers to any kind of video-game-based learning, it involves formal and informal settings, and their target audiences include all ages.

Researchers and educators tried to integrate serious games into classrooms. Nevertheless, despite their potential, the application of SGs in education has been limited in terms of pedagogy. An SG with an educational purpose cannot successfully be employed in every field.

Due to the high level of interest and social impact that SGs generate, it is necessary to examine the value they offer to education. Some studies prove that the lack of a correct SG design can bring negative results [2] and lose both their attraction and their game-like essence [3].

Sometimes, SGs do not allow the experience of a process of immersion and motivation, like they share with commercial video games. Even more, maybe they do not fulfill serious teaching goals. This is the importance of properly conceiving SGs for the educational field. To ensure that an SG meets the user’s expectations, it must be designed using an appropriate method. The goal of our research is to propose a reference methodology for SG design that incorporates a user-centered design approach.

The rest of this paper is divided into the following sections: Section 2 presents related research on methodologies used to design SGs. Section 3 describes our methodological proposal, explaining its phases and activities. In Section 4, we illustrate the applications of iPlus; Section 5 presents an analysis of the case study designed with iPlus and the results obtained, Section 6 presents different case studies with iPlus. Finally, Section 7 presents the conclusions and perspectives of our research.

2. Related Research

This section reviews works related to this research domain to point out previous researchers’ contributions and place our contributions in the proper context. We first provide the reader with background information, followed by a discussion of previous research related to our own.

2.1. Background

There is no final definition of “Game”, new practices around games need new definitions. A definition can be better or worse within a particular cultural and historical context and for a particular purpose.

There are game characteristics that better describe them in the literature, but some authors specify considerable difficulty in reaching a comprehensive definition of the game despite this.

Some authors mark the beginnings of the use of games from different perspectives; for example, Johan Huizinga [4,5] argued that play itself is a necessity of cultural development, emphasizing that the characteristics of play are “free”, the game is “as if”, it has a “disinterested character” that becomes “complement of life”.

Bernard Suites [6] from the mathematical current says, “To play a game is to attempt to achieve a specific state of affairs, using only means permitted by rules”. He notices the need to play under some rules so that the game can be a game. His definition does not account for the more modern video games, where the players are NOT limited in scope.

Roger Caillois, in [7], expresses that six characteristics best describe the game: “free”, “separate”, “uncertain”, “unproductive”, “governed by rules”, “make-believe”.

These diverse qualities are purely formal; researchers have criticized this definition, leaving the definition of games open.

Although these authors do not speak from a digital perspective, their critical opinion is essential since our study considers two key terms, the game and the serious content.

On the other hand, the first formal definition of “Serious Game” was proposed by Clark Abt (1970) [8]: “Games may be played seriously or casually. We are concerned with SGs in the sense that these games have an explicit and carefully thought-out educational purpose and are not intended to be played primarily for amusement. This process does not mean that SGs are not, or should not be, entertaining.”

Back then, the first “Serious Games” were not necessarily thought of in terms of digital support. The game was seen as an element that allows people to develop skills or acquire knowledge through practice through play. Clark talks of “non-digital “games, using a wide range of support such as board games in the classroom. The physical elements of interaction and participation between the different participants intervene.

Later, the concept of “Serious Game” was redefined by Sawyer [9], oriented to digital use. “A computer application, made by developers, researchers, industrialists, whose chief mission is not entertainment.” Michael Zyda, in [10], proposes a relevant definition: “A mental contest played with a computer following specific rules, that uses entertainment, to further government or corporate training, education, health, public policy, and strategic communication objectives.”

Unlike their entertainment-only counterparts, SGs use pedagogy to infuse instruction into the gameplay experience. Zyda [10] states that a game must combine components of a video game (story, art, and software) with pedagogical elements to be considered serious.

A more recent relevant definition was proposed by Julian Álvarez [11], who studies the origins of SGs and defines them as “a computer application whose initial intention is to consistently combine serious aspects such as teaching, learning, communication or information, with playful aspects of the video game.” Such an association operates through the implementation of a pedagogical scenario that, at the computer level, corresponds to the performance of a sound and graphic design, a story, and appropriate rules.

There is no perfect definition for serious games because the quality of a definition depends on its purpose. Thus, perhaps the appropriate approach would be to adopt as simple a definition of serious games as possible. However, it would be a mistake to understand this to mean that there is no point in studying and making definitions or that all of them are useless.

2.2. Study of Characteristics of Serious Games

Some research work in the field of serious gaming frameworks exists. In particular, for the use of design patterns [12,13,14], approaches have been based on problem-based learning [15,16,17,18], deep learning [19,20], RETAIN model of FutureLab [21,22], and Evidence-Centered Design [23,24,25]. In this study, we use the Design, Play, and Experience (DPE) framework [26] to study the characteristics of SGs. DPE is designed to guide the game design process, and it serves as a basis to order and categorize the essential elements to be considered when planning the SGs.

The DPE framework is divided into three phases: Design of the game scenario; Play, the interaction that the player makes with the game; Experience, which defines the sensations or feelings that the game generates. This framework also defines four layers: learning, storytelling, gameplay, and user experience. All these layers are considered throughout the DPE cycle.

Unlike entertaining games, SGs are designed for an educational rather than a fun purpose, but not only for this. They can also be informative, persuasive, subjective, mental and physical training, and data exchange [27]. For this reason, we redefine the DPE “Learning layer” as a “Serious layer,” and we add the gamification element that consists in the application of game features, mainly video game elements, into a non-game context to promote motivation and engagement in learning. We consider that gamification can be at the same level as the gameplay layer, where the game mechanics and dynamics are defined. Figure 1 shows the redefined DPE cycle”.

We conducted a systematic literature review to collect a set of documents related to the origins, definitions, classifications, evaluations, and frameworks of SGs. We analyzed the set of documents to identify the critical characteristics of SGs. Then, we grouped the identified attributes according to the layers of the DPE framework. Below, we present and illustrate the result of this process.

2.2.1. Serious Layer

This refers to the pedagogical or learning content of the game. Characteristics: it defines the topic of work, the target audience, and the SG objectives. It also defines work-focused evaluations, duration of activities, type of play, whether individual or collaborative, gender, purpose and scope of play. Finally, it establishes a correct distribution of tasks, the feedback from the game. All the above is done to stimulate skills according to the SG purpose. References: [1,10,26,28,29,30,31,32,33,34,35,36].

2.2.2. Storytelling Layer

This refers to the narrative of the game story. Characteristics: It designs the game story, the game worlds, the characters for the game, and the movements in the world scenario of the game. It allows the avatar selection. References: [10,26,29,31,33,35,36,37].

2.2.3. Gamification and GamePlay Layer

This refers to the mechanics developed in the game scenario. Characteristics: it designs the gamification techniques, the gameplay, or functionalities of the game. It must allow for easy interaction between the player and the game, achieving different rewards, confidence, curiosity, satisfaction, fun, and attraction. References: [1,26,32,34,36,37,38,39,40,41,42,43].

2.2.4. User Experience Layer

This refers to the entertainment that is caused by the game. Characteristics: It defines the aesthetics and graphics of the game world, the text, and narrations, scenarios, and manipulation of objects on the game scenario. It must allow interest, immersion, and concentration in the player. References: [1,26,28,29,30,31,32,33,34,35,36,37,40,41,43,44,45,46,47,48,49,50].

Studying the characteristics of the SGs, the current definitions do not consider or do not make the use of some key concepts clear when designing the SGs. The essentials elements to be included are gameplay, which refers to the SG scenario actions, and the gamification techniques, which allow engagement and motivation factors in the education field to improve the user experience.

Therefore, we suggest a new technical definition for SGs that comes from a systematic literature review [51]: “Computer application, used for different purposes message broad-casting (educative, informative, persuasive and subjective), training (mental and physical) and data exchange in a different context (education, defense, religion, health, politics.) that contains elements of a video game such as story (narrative of game entertainment, characters, rules of how to win the game, game worlds), gamification (elements of game designs such as badges, challenges, and missions.), gameplay (the mechanics that make up the functional components of the game, such as avoid, destroy, choose.), art (game aspects) and software (implements story requirements, interface features, networks, web connectivity, and other functions) used to improve user experience and commitment.”

2.3. Methodologies for Serious Games Designs

Standard video games are information-oriented applications, for which the development process often follows a traditional software development approach. Some methodologies for leisure game development already exist; however, SG design demands a specific design methodology. According to [52], game design is a process; it contains a continuous sequence of operations or activities leading to a predefined goal. The complexity of the design of SGs has established several approaches that involve various processes and activities. In this section, we present several contributions related to SG design.

Marfisi [53] proposes a methodology for the conception of Learning Games (LG) used in students’ continuous engineering careers training. This methodology helps to model the LG scenario to help designers understand the needs of the stakeholders. This methodology is divided into seven phases: 1. specification of stakeholders’ needs; 2. specification of pedagogical objectives; 3. conception; 4. quality control; 5. production; 6. tests in the target audience; 7. maintenance. For each phase, different experts participate. The specification of the stakeholder needs phase involves stakeholders and the project leader. In the specification of the Pedagogical objective phase involves a subject matter expert and a cognitive expert. The phase involves a pedagogical expert, the game designer, and the screen designer. The quality control phase involves a pedagogical expert. In the production, the phase involves a developer and a graphic designer. In the phase of the test, target audiences involve pedagogical experts and students. Finally, the Maintenance phase involves students. The most important phase of this methodology is the conception stage, in which the scenario of the LG story is designed.

On the other hand, Lopez [54] proposes a methodology based on the one proposed by Marfisi. This methodology is used for the engineering process of an SG to combat childhood obesity. The proposed methodology is divided into five Phases: 1. infants’ understanding of eating habits, use of video games, and traditional games; 2. design of the pedagogical objectives; 3. design of the logic of the videogame; 4. development and implementation of a prototype; 5. evaluation. As the Marfisi proposal, for each phase, different experts participate. In another article, Lopez [55] presented a case study based on a traditional game of Jump Rope, implemented with Microsoft Kinect technology. Still, in this article, he did not apply the proposed methodology.

Barbosa [56] proposes a methodology for designing and developing SGs made up of various levels, allowing the player in each level of the game to have missions to overcome to access the learning mechanisms. To evaluate the methodology, this author presents an SG called “Clean World,” a 3D game created to raise awareness of the environmental problems that we face today and teach what we can do to protect nature.

Aslan [57], on the other hand, proposes a methodology for the development of digital educational games, named diGital educAtional gaMe dEvelopment methodology (GAMED), which consists of a body of methods, rules, and postulates and is embedded within a Digital Educational Game (DEG) integrated into the software life cycle. The DEG life cycle consists of four phases: 1. Game design phase; 2. Game software design phase; 3. Game implementation and publishing phase; 4. Game-based learning and feedback phase. Each phase consists of several stages. Each stage shows the tasks, but this methodology does not define the users and experts that participate in each phase. They explain, in a general way, that it includes the following work team: a subject matter expert, game-based learning experts, game designers, students, and software engineers.

In the article [58], Jiménez presents a methodology to construct educational games in software engineering. This methodology is divided into three stages: 1. pre-production; 2. production; 3. post-production. These are composed of three processes: project management, software implementation, and pedagogical implementation. In this methodology, for each approach, the main actors are identified. For example: for the project management process, a “project manager/leader” is determined, for the software implementation process, a “video game development team” is identified, and for the pedagogical implementation process, a “pedagogic manager” must be involved. The authors present the results of applying this methodology in an educational video game named “Alphaspot,” which aims to facilitate learning about the kernel Alphas of Essence and its states.

In [59], Cano proposes a methodology for SG design for children with auditory impairments. This methodology uses a User-Experience (UX) approach. This proposal is called MEtodología para la CONcepción de juEgos Serios para nIñoS con discapacidad auditive (MECONESIS); it is divided into four phases: 1. Analysis; 2. Pre-Production.; 3. Production.; 4. Post-Production. This methodology is based on the unified software development process that involves Concur Task Trees (CTT) notations to model the interactions. He uses the class diagrams of UML and the Instructional Management System—Learning Design (IMS-LD) metadata for different scenarios. The methodology also involves various experts, such as psychologists, teachers, and speech therapists. Some case studies have been done in USAER, Aguascalientes, Mexico, the Institute for Blind and Deaf Children of Valle del Cauca, Colombia, and the Institute of Special Therapy of Senses of the Club Leones, Cali-Colombia.

Other work proposed by Prieto [60,61] includes a design methodology for educational games based on graphical notations, with a rich narrative of adventure games organized into chapters and scenes for the design of SGs. This methodology is divided into three preliminary phases (Pre-Phases): 1. design of the educational challenges: essential competencies and educational objectives; 2. design of the type of game; 3. design of the story and main characters. Generally, this last is composed of six sub-phases: 1. design of chapters; 2. design of scenes; 3. educational design; 4. emotional design; 5. adaptation design; 6. collaboration design. A series of graphical notations are used to describe the structure of the SG chapters and scenes graphically. The author explains that the diagrams made with the methodology facilitate video game implementation and can be directly interpreted by the developers who were not involved in the design. In this methodology, designers, artists, and programmers are involved. The author explains that this methodology has been conceived from the experience of educational game designs. The case study in this article presents the story of a girl or boy on which the future of planet Earth depends.

In [52], Najoua proposes a cognitive-affective methodology for designing a serious learning games, called KASP. This methodology helps children with Learning Disabilities (LD), based on four pillars: Knowledge, Affect, Sensory, and Pedagogy. This methodology is composed of three main phases: 1. Preliminary Analysis (PAP); 2. Development of Conception Phase (DCP); 3. Deployment Phase (DP). In this methodology, several experts are involved as cognitive experts, knowledge experts, experts in psychology, sensory experts, pedagogical experts, developers and designers. This article simply presents the results of the mental and emotional models of a case study of a child with a dyslexic disorder.

Other researchers have presented results through models. Lepe [62], in his study, presents a model of analysis and design of educational games with pedagogical foundations that takes three factors into consideration: design patterns and features present in educational games; lessons learned from various game design approaches; and pedagogical guidelines. The name of this model is GAGE, which is composed of six elements: 1. stakeholders; 2. goal; 3. audience; 4. game; 5. environment; 6. enhancing the experience. This model serves as a guide for SG developers, offering a set of general recommendations. Finally, Avila proposes a conceptual model for SG design and presents a case study in children with learning disabilities [63]. This model is based on three approaches: instructional design, software development lifecycle (SDLC), and game design document (GDD). Additionally, he proposes four phases of the development of SGs: 1. analysis, 2. design, 3. development, and 4. evaluation.

This model begins with a concept or idea and identifies the set of skills to be improved. The author explains that UML notation can be used to model the components of the SG design. He talked about a team composed of programmers, developers, database analysts, artists, and designers in the development phase. Finally, for the proposal evaluation, the SG “ATHYNOS” was designed, which helps with therapeutic activities and cognitive reinforcement.

Table 1. Comparison of Methodologies.

Author	Year	Scope	Artifacts	User Centered-Design	Integration
Carrión et al. [64]	2019	A generic methodology for educational serious games design	Problem Identification Participant identification Pedagogical Objectives Game Script GamePlay User Story	Active participation of users in the entire methodological process	Integrate with agile approaches through user stories
Avila et al. [63]	2019	A conceptual model for serious games design: A case study in children with learning disabilities	Pedagogical objectives definition, Story design, GamePlay definition, Genre type definition	Only in the analysis phase	Includes its development phase
Najoua Tahiri [52]	2018	KASP: A cognitive-affective methodology for designing serious learning games	Pedagogical model, Genre type identification, Educational conceptual architecture, Prototypes	Only in the preliminary analysis of the final user	Not specified
Jiménez-Hernández, et al. [58]	2016	Methodology to construct educational video games in software engineering	Pedagogical objectives definition, Story design, Gamification techniques, Genre type identification	Not specified	Not integrated. Proposes production and post-production phases
Cano et al. [59]	2016	MECONESIS: Methodology for the conception of serious games for children with hearing impairment	Problem specification, Pedagogical objectives definition, Gamification techniques, Prototype documents Production documents	The methodology focused on the use	Not integrated. Includes its production and post-production phases
Prieto de Lope et al. [60]	2016	URANO: Methodology for educational games based on graphical notations	Design of the scenario, Design of the dialogues and game challenges, Design of the characters, Pedagogical objectives definition	Not specified	Not integrated—Includes a production phase
Aslan et al. [57]	2015	GAMED: Digital educational game development methodology	Education problem, The game idea, Game design, Requirements, Game Architecture, Game software design	Experts and students participate in the generation of ideas to solve the problem.	Not integrated—Game implementation and publishing phase
Lepe-Salazar [62]	2015	A model to analyze and design educational games	Artifacts are not specified	Not specified	Does not specify a life cycle
Barbosa et al. [56]	2014	The methodology of design and development of serious games	Problem specification, Story design, Learning mechanisms	Not specified	Not specified
Lopez-Martinez et al. [54]	2013	Methodology for the analysis and design of a serious video game to combat childhood obesity in the State of Yucatán	Artifacts are not specified Pedagogical objectives definition, Design document, Prototypes, Semi-structured interviews	The final user intervenes only in the analysis phase	Specifies its development phase
Marfisi-Schottman [53]	2012	LG—Learning games methodology Games for higher education or professional training.	Problem specifications, Pedagogical objectives, Scenario storyboard and graphic specifications, Prototypes, Learning game finished, Analysis of traces	The product owner intervenes in the analysis phase	Proposes a realization phase.

presents a comparative analysis of the SG methodologies with the iPlus methodology.

The comparative analysis presented here shows that the product owner and the end-users are not always involved in the game design process. None of the proposals studied contemplate the development of educational SGs in a participative way; this means involving end-users actively to build the learning objectives and ludic components. Our methodological proposal, called iPlus, is distinguished from the others due to its user-centered design approach. iPlus actively involves stakeholders, such as the product owner, end-users, pedagogical experts, the subject matter expert (teachers, tutors), software developers, video game designers, psychologists and players, in the game design process.

The approaches studied do not include a design guide that describes the roles, activities, resources, and the resulting artifacts. iPlus facilitates a process life cycle that guides the user through the design of the game. Each phase comprises a detailed process that includes activities, roles, resources, and the resultant artifacts. The above approaches agree that story design and pedagogical objectives are essential; if an SG is not correctly designed, pedagogical objectives cannot be achieved. The design process of iPlus starts with the problem statement, according to users’ specific needs and the definition of the expected learning outcomes.

None of the previous methodologies uses techniques to promote creativity, and most of them are not generalizable and non-integrable with agile approaches. iPlus proposes an agile approach based on creative techniques that allow users’ active participation to reach a consensus from the generation of ideas. The result of the design process is a guide that includes the game story, engagement techniques (gamification), the game functionalities (gameplay), and the game genre.

The ideas and purposes (requirements) generated with iPlus are refined to remove ambiguity and provide better specific versions of the requirements. iPlus proposes a Refinement phase according to the characteristics presented by the ISO standards [65,66]. Finally, iPlus formalizes its concepts and relationships through a metamodel that makes the design process easier to understand. None of the methodologies analyzed are described through a metamodel.

3. iPlus Methodology

In this section, we describe our methodology (iPlus) for designing SGs with an educational purpose. For the construction of iPlus, we used the design science research approach [67]. This process is an iterative design process in which designers and users are actively involved in artifacts. In our case, this artifact is the methodology. iPlus was designed through experimental protocols carried out in a participatory manner, thereby allowing the user’s and experts’ consensus to obtain a method through the stages that are progressively validated and adapted.

The methodology we propose is intended to be as generic as possible and applicable to any type of SG. iPlus offers a phase for the ascertainment of consensual requirements through the participation of experts and users. iPlus gives the participants options for active and creative involvement; it proposes a participatory approach in which game designers and users focus on the user’s requirements in each phase of the game design process [64,68].

The iPlus design approach is flexible, can be used to design any serious educational game, and offers a design approach integrated with other agile methods. The design process begins by defining the problem according to its specific needs and defining the expected learning outcomes. The story design and the pedagogical objectives are essential, together with the conception of a delightful and playful setting. iPlus aims to take advantage of motivational factors designed through game mechanics to offer interactive learning.

iPlus comprises a series of ordered steps organized into five phases, as shown in Figure 2. To structure the different elements involved in the design of an SG, we have inspired in the 5Ms, also known as a fish-bones diagram, cause/effect diagram, or Ishikawa diagram, which is a fundamental tool for piloting problem-solving projects proposed by Kaoru Ishikawa [69,70].

• Method. Presents the sequence of the phases of the general process that allows the design of the SG;
• Participants. Stakeholders involved in the SG design process. For example, experts (pedagogical experts, psychologist, software developer, video game designer, subject matter expert, among others) and users (product owner, end-users, or players);
• Tools. Models, theories, techniques, standards, and genres of video games used in the design process. Some of the approaches used are:
  • Bloom’s Taxonomy [71]: This theory objective is that after completing a learning game-based process, the student acquires new skills and knowledge. Bloom’s taxonomy levels are knowing, understanding, applying, analyzing, evaluating, and creating;
  • Theory of Learning Multiple Intelligence [72,73]: This theory is related to human beings’ capacities. These only need to be enhanced, and if they do not, they are measured in the usual intelligence tests. This researcher has identified eight different types of intelligence: linguistic–verbal, logical–mathematical, visuospatial, musical, corporeal–kinesthetic, intrapersonal, interpersonal, and naturalistic);
  • Brainstorming [74,75]: Brainstorming is a tool to generate original ideas in a relaxed environment;
  • Affinity Diagram [76]: This is a tool that synthesizes a set of verbal data (ideas, opinions, themes, expressions, among others), grouping them based on the relationship they have between them;
  • Gamification [38,39]: This consists of the use of design mechanics, elements, and techniques of games in the context where they are not games, to engage users and solve problems [77]. For example, Points are game mechanics through which numerical values are assigned to the player. Levels in a game are new spaces available to the player when completing a specific objective and new challenges to keep players’ interest high. Leaderboards are a game mechanic that shows the names and positions in a competition, especially in a game tournament. Badges are among the most used game mechanics and achieve the best results in terms of commitment from the player’s report. Challenges/Quests give players direction on what to do in the world of experience. Tests that the player must pass to obtain points or advance in level are also considered. Onboarding makes a player understand the dynamics, rules, and objectives of a game without reading any instructions. Engagement loops are the rewards that make the player commit, for example, prizes and gifts obtained in the game. Customization allows players to personalize different objects (avatars, worlds, names) from the game world, creating engagement within that virtual world;
  • GamePlay [78,79]: They are functions implemented in the game scenario, such as avoid (avoid losing the SG), create (the act of making objects appear on the SG scenario), destroy (the act of making items disappear on the SG scenario), choose (the action to select one of two options on the SG scenario), move (the story of moving objects on the SG scenario, changing their current location), write (the act of writing a letter, word or phrase on the SG scenario), shoot (the action for jumping, hitting and shooting objects inside the SG scenario), vocalize (the act that allows the player to sing on the SG and thereby generate specific results), transform (the action that helps to transform the object by changing its color, size, texture, and shape);
  • Video Games Genres [80,81]: These allow for classifying a video game based on its gameplay. For example, role (characterized by play a specific part, or personality, in the game scenario), adventure (characterized by research, exploration, puzzle-solving, interaction with characters from the game scenario), simulation (characterized by simulation, which tries to recreate real-life situations, reproducing sensations that are not happening), reasoning (solving problems with a more significant intellectual growth), strategy (those games in which the intelligence factor, technical skills, planning and deployment on the game stage, predominate to propel the player towards the victory of the game), and/or action (characterized in that it allows the player to use speed, dexterity and reaction time);
• Materials/Resources. Set of resources used by the participants to help design the SG (identification form, interview form, post-its, multicolored pens, among others);
• Artifacts. All the products directly or indirectly used to implement the final SG (GameScript, GamePlay, User Stories, among others). We detailed each phase process, the responsibilities, the iPlus participants, the resources to be used, the tools, and the artifacts created.

3.1. Phase 1: Identification

This process is the initial phase of the methodology, where the design process is initiated by the product owner, who has specific educational needs and requirements.

Here, the general problem is defined by the interested party, and, depending on the situation, participants in the methodology are identified. In this phase, it is necessary to fill out the identification form, and the response is the software developer.

Phase Description

Method. The interested party defines the general problem, and, depending on the situation, the participants of the methodology are identified (see Figure 3).

Participants: iPlus facilitator and product owner.

Materials/Resources:

• Identification form to identify the product owner’s specific needs, the institution or establishment that the product owner belongs to, participant’s information (participant role, name and last name, email, phone), participants’ model, and date of the work meeting.

Artifacts: The output artifacts for this phase are iPlus participants.

3.2. Phase 2: Pedagogical Objectives

This process is the second phase of the iPlus, where the general and specific objectives are defined in a participatory and agreed manner, under the pedagogical expert’s guidance. This phase is guided by the iPlus facilitator, who knows the methodology and is responsible for correctly carrying out the activities without interruption.

For the execution of this phase, the following stages are considered.

3.2.1. Initial Steps

• Welcome: Here, participants are welcomed by the facilitator. The project context is explained;
• Round table presentations: The participants introduce themselves, stating their role and field of expertise;
• Phase rules: The rules of the phase are explained to ensure correct collaborative participation.

The description of this stage is presented in the iPlus layer model below.

3.2.2. Phase Description

Method: The iPlus facilitator is responsible for presenting the game context and conducting the interview with the product owner to elicit and understand the end-user’s needs. Participants note down the ideas and desired purposes with the help of orange post-its. With the help of an affinity diagram, participants group the individual goals to create general consensual purposes. The pedagogical expert defines the general and specific objectives related to the previously defined purposes. The process of the pedagogical objectives phase is illustrated in Figure 4.

Participants: All participants.

Tools: Bloom’s Taxonomy [71], Theory of Learning Multiple Intelligences [72,73], Brainstorming [74,75], and Affinity Diagram [76].

Materials/Resources.

• Interview Form is useful to know the users’ needs and their characteristics. The following are some questions for the product owner interview: We would like you to broaden the problem that you present in your work environment in general? What do you want to teach with this application? What is the objective that you want the application to achieve? Who are the end-users? What skills, knowledge, aptitudes do you want to be stimulated and/or developed? What are the characteristics of the end-users? among others.

As a result of this interview, a specification document (two to three pages) is described, including details of the problem, the user profile characteristics and the technique needs, which must be considered by the developer (see

Table 2. Main elements were collected in the interview form.

Elements
Problem description
Teaching topic
Learning objectives
Target audience
Age of target audience
Skills, knowledge to be developed
Audience characteristics
Game type
Usage environment
Device types for deployment
Information to display
Roles

).

• Multicolored Pens identify each iPlus participant;
• Orange Post-it is for writing the purposes or ideas;
• Pink Post-it is for writing generalized purposes or ideas;
• Flipchart contains affinity diagrams;
• General Objective Form useful for describing the central idea of what is expected to be achieved in general terms at the end of the work;
• Specific Objectives Form describes the processes used to achieve the general objective. The specific objectives are deduced from the general objective and related to the ideas and purposes.
• Artifacts. The output artifacts are:
• Needs and constraint.
• Pedagogical objectives.

3.3. Phase 3: Ludic Game Script

This phase aims to create the “Game Design Document” (GDD) based on the Product Owner’s needs or requirements. Here, experts and users’ participation are essential because they imagine the possible scenarios for the SG. Participants and the Product owner discuss and agree on ideas, and then, with the help of the game designer, they create an approved game script. The main components of the ludic game script phase are shown in Figure 5, and its particularities are detailed below.

Narrative represents the story that provides the entertainment component, which details what events or situations occur within the game worlds that are in SGs.

Learning Content represents the details that the product owner (teacher) wants to teach with the SG.

Main Characters represent persons, animals, or other objects present in the SG and controlled by the player.

Game Rules define the way games are played.

Game Worlds represent the different scenarios that can be deployed in the SG.

Multimedia Elements represent the means to communicate actions performed on the game scenario to the player. They guide players to beat specific challenges (sounds, video, and text).

Gamification Techniques represent mechanisms or attractive elements (points, levels, leaderboards, among others) to motivate consistent participation and long-term engagement of the users [38,39,77].

For the execution of this phase, the following stages are carried out.

3.3.1. Initial Steps

• Introduction: The iPlus facilitator explains the rules and activities carried out in the phase;
• Familiarization of the SG design components: The components and the gamification elements that can be implemented in the SG are introduced.

3.3.2. Phase Description

Method. Here, the SGs different possible scenarios are conceptualized while maintaining the general objective of the previous phase. Participants imagine the possible scenarios for the SG, and each one states its ideas out loud. The product owner selects the best ideas proposed for the game script. Participants and the product owner discuss and agree on ideas. The game script is then created with the narrative, learning content, main characters, games rules, game worlds, multimedia elements, and gamification elements from the selected ideas. Figure 6 shows the process of the Ludic Game Script phase.

Participants. All participants.

Tools. Gamification [38,39,77] such as Points, Levels, Leaderboards, Badges, Challenges/Quests, Onboarding, Engagement loops, Customization.

Materials/Resources.

• Game Design Form to design the elements that are going to be inside the SG;
• Multicolored Pens to identify each iPlus participant;
• Gamification Lego blocks to design mechanics that generate engagement and motivation in the players;
• Green and Red Stickers to select the admissible (green)/deficient (red) ideas proposed by the participants;
• Consensual Game Script to write the consensus ideas for the game script.
• Artifacts.
• Game Script.

3.4. Phase 4: GamePlay

The GamePlay phase aims to specify the functions/actions that are developed for the game script. GamePlay [78,79] refers to the actions that the player performs to interact with the SG, for example, functions such as picking up, triggering, managing, creating and avoiding. The video game designer is in charge, and the results of this phase are the full GamePlay cards. Additionally, the video game genre [80,81] (role, adventure, simulation, reasoning, strategy, and/or action) and the key terms to name the game are identified. For the execution of this phase, the following stages are carried out.

3.4.1. Initial Steps

• Introduction: Here, the iPlus facilitator explains the activities that are carried out;
• Familiarization of GamePlay Lego: At this stage, each of the Lego of GamePlay is explained, which can be used to design the SGs functionalities;
• Presentation of the GamePlay Phase Rules: Here, the rules for starting the activities are presented;
• GamePlay: At this stage, the creative activity is run to create gameplay cards. The complete process of this stage is described in the following sections using the iPlus layer model.

3.4.2. Phase Description

Method: The iPlus facilitator explains the activities involved in this phase. Participants use Lego blocks to image functions developed in the SG, keeping in mind the SG game script. The result is GamePlay cards, presented out loud, which help to identify complementary ideas.

The facilitator then explains the types of video games, and participants select the appropriate gender with the game designer’s help. Finally, participants generate key terms to name the game using brainstorming. The process of the GamePlay phase is illustrated in Figure 7.

Participants: All participants.

Tools: GamePlay [78,79] and genres of video game [80,81].

Materials/Resources:

• Multicolored Pens to identify each participant;
• Lego GamePlay Blocks to design possible actions to be performed on the game scenario;
• GamePlay Cards to design the mechanics of the interaction between the player and the game;
• Video Games Genre sheet to know the different categories in which SG can be classified;
• Star Stickers to vote for the selected game genre;
• Green Post-it is to note down key terms related to the context of the designed SG.

Artifacts:

• GamePlay Cards;
• Video Game Genre;
• Key Terms.

3.5. Phase 5: Refine

The last phase of iPlus aims to validate if each requirement meets the characteristics of a reasonable condition. The documents concerning the purposes and GamePlay cards are filtered to eliminate aspects that are repetitive or are not possible to create. For this, we use a refinement matrix that meets the required specification properties of the ISO standard [65,66,82]. The responsibilities of these activities are those of the software developer and the product owner. This phase results in the user stories, defined according to the specific objectives of the second phase. The product owner validates each user story.

In this phase, there is a single stage.

3.5.1. Initial Steps

• Refinement: Here, a meticulous requirement validation work is carried out, with a refinement matrix to validate the purposes and functionalities. The full details of this stage are presented below.

3.5.2. Phase Description

Method: The software developer fills the refinement matrix and verifies the gameplay and purposes described in phase 2 to ensure that they can be executed in the designed SG. Next, user stories are generated. Then, the developer sets a meeting with the product owner to validate the user stories. Figure 8 illustrates the process of this phase.

Participants: Product owner and software developer.

Tools: Characteristics of requirements [65,66]; the requirements must exhibit the following characteristics:

Necessary means that the requirement is essential; excluding it produces a deficiency that affects the set of parameters required;

Appropriate, the requirement is relevant to the level of the entity to which it refers;

Unambiguous, the requirement can be interpreted in only one way;

Complete, the requirement describes the necessary without needing other information to understand the condition;

Singular, the requirement states a single characteristic but can have multiple conditions under which the requirement is met;

Feasible, the requirement can be realized within system constraints with acceptable risk;

Verifiable, the requirement is verifiable through test cases;

Correct, the requirement represents the real need of the client;

Conforming, the requirement conforms to the style or template.

Materials/Resources.

• Refinement Matrix allows for validating the purposes and functionalities described for the SG. This matrix comprises a set of validation questions based on the ISO standard [65,66]. We complete the refinement matrix with the requirements, and then each purpose answers questions such as the following: Are the conditions clear, is there no ambiguity? Do the requirements represent the real needs of the customer? Are the requirements appropriate, are they within the scope of the project? Are the requirements feasible to carry out despite the limitations of the system? Are the conditions verifiable through test cases? We also fill this refinement matrix with gameplay cards, which go through validation. The following are sample questions: Does the game functional design conform to the gameplay card format? The gameplay cards are complete, include the Lego gameplay? Is there synergy between the game script and the gameplay card? Is it appropriate? The gameplay card is related to the functionality that the customer needs, according to its scope. Is it correct? The gameplay card needs to be implemented to meet the customer’s needs. Is the gameplay card verifiable?
• User Stories Form allows the software developer to specify the user stories that are useful for any methodology that receives user stories as input.

Artifacts: The output artifact of this phase is the User Stories.

3.6. iPlus Metamodel

The iPlus methodology is formalized through a metamodel. This metamodel is used to define the basic concepts and their relationships (see Figure 9).

The heart of the iPlus metamodel is based on the concepts proposed by [10]. Michael Zyda says that an SG is composed of a story, art, and software and involves a pedagogical component. Additionally, we have added other concepts like gamification, gameplay, genre, and participant.

The iPlus metamodel begins with the concept of Serious Game Class (SG), which contains the story of the game through the game script (GameScript Class). This includes the narrative, learning content, characters, game worlds, game rules, and gamification elements (Gamification Class). When designing the game script, it can be categorized into a videogame genre (GenreGame Class). The gameplay (GamePlay Class) refers to the actions that will be implemented in the game scenario. The gameplay can be designed through gameplay cards (GamePlay Card Class). The refinement matrix allows for converting it into refined gameplay (Refined GamePlay Class), responding to the product owner’s needs.

iPlus involves several participants (Participant Class) from different areas of knowledge (Expert Class) and end-users (User Class), those who participate (Participation Class) in the SG design during a work meeting (Meeting Class). A facilitator (Facilitator Class) is responsible for directing each of the activities to be executed to design the SG. Finally, an SG for educational purposes contains pedagogical objectives (PedagogicalObjective class). These pedagogical objectives are classified as general (PedagogicalObjective Class) and specific objectives (SpecificObjective Class). The general objective contains the purposes (Purpose Class). These purposes are discussed to reach a consensus (AgreedPurpose Class). Each definition is refined (Refined Purpose) through the refinement matrix. These purposes are related to the user stories (UserStory Class), which are used as input to any software methodology.

4. Application of the iPlus Methodology

The Ecuadorian Higher Education System implemented a standardized test, called “Ser Bachiller”, as a compulsory requirement for admission to an undergraduate program at any public university in any country. Based on the test, applicants receive a score that allows them to apply to their chosen academic program.

Educaplay is an SG that reinforces academic aptitudes in mathematics, linguistics, natural sciences, social sciences, and abstract skills of students who try to enter higher education. To illustrate the application of iPlus, below, we present a concept of the SG called educaplay [83].

4.1. Identification Phase

Resultant artifacts: In this phase, the general problem is defined, and the actors involved in the game design are identified.

Description: An application is required to reinforce the academic skills of college-bound students. This case study involves an expert in pedagogy, responsible for defining pedagogical objectives, the product owner, a subject matter expert, a video game designer, the software developer, and the concerned students (see Figure 10).

4.2. Pedagogical Objectives Phase

Resultant artifacts: The general and specific objectives.

Description: In this phase, the product owner’s requirements are specified, and the general and specific objectives are defined in a participatory and agreed manner. This is the support given by an educational psychologist and a pedagogue.

Table 3. Main elements collected in the interview form.

Elements	Description
Problem	“We observe that students who finish secondary education have difficulties when taking the exam to enter university since the tests aim to evaluate the different skills, they acquired during their high school studies. Students have difficulty due to the complexity that these tests have, or because students do not feel the interest to study somehow. For this reason, we as teachers want to propose a new alternative for them to achieve motivation to prepare the university entrance exam. An alternative that we think is the use of a game that encourages students to practice different types of exercises in different areas, such as mathematics, linguistics, among others”.
Teaching	“With this tool, we want to teach students to solve different problem statements in the fields of mathematics, linguistics, social sciences, and natural sciences”.
Learning	“We want students to understand how to solve different problem statements of different areas of knowledge”.
Target-Audience	Students in the last years of High School.
Age-Target-Audience	16–19 years old.
Skills	Visual–spatial, linguistic–verbal, logical–mathematical, and naturalistic.
Game Type	individual.
Use environment	In the classroom and anywhere with Internet access.
Device types	“It has to be a game available online, available to download on devices, such as a tablet or a phone, so that the student while riding on the bus, or he is at home, he can play and study at the same time”.
Roles	The administrator can manage the users and update the content. The Player role interacts with each of the games and sends friend requests to users to follow their updates and game progress.

shows some main characteristics collected in the interview form.

Figure 11 illustrates some of the desired purposes written on orange post-its and a general-purpose written on a pink post-it.

Taking the desired purposes as the basis, iPlus participants describe the general objective and the specific objectives. The general aim is defined as “The students develop and train their academic programs through the use of an SG, to take advantage of the motivational factor generated by games, under the guidance of the pedagogue” (see Figure 12).

4.3. Ludic Game Script Phase

Resultant artifacts: Game Script

Description: As a result of this phase, a game script is defined to conceptualize the SGs different possible scenarios based on the product owner’s requirements. The product owner selects the best ideas proposed for the game script. Figure 13 shows the consensual game script for the study case.

4.4. GamePlay Phase

Resultant artifacts: GamePlay cards, video game genre, key terms.

Description: The Gameplay is the specific way in which players interact with the game. In this phase, the functions, actions, and rules that are implemented in the SG are defined. In the iPlus methodology, participants describe the GamePlay with the help of the game designer. Figure 14 shows some results of the GamePlay card.

Afterward, the genre of the SG is identified; in this case, it is classified as reasoning. This process is carried out by voting using star stickers. Finally, in Figure 15, some of the key terms identified by all the iPlus participants in the project are shown on green post-its.

4.5. Refinement Phase

Resultant artifacts: User stories.

Description: This is the last phase of the methodology, during which the user story is obtained. The person responsible for this is a software developer. Here, the purposes and GamePlay cards are filtered.

Table 4. User Story Result.

User Story
Identifier: H003	Role: Player
User Story Name: Application available online Priority: Medium (M) Description: The player requires the SG to be available online to access from a web browser from anywhere there is Internet access Criteria: − The application is developed with web technology so that players from various platforms can access it; − The player can access the application, which is available online.

is an example of the result obtained in this phase: a user story that contains a description of the activities the developer must fulfill. Furthermore, the priority and the role to be carried out are specified in this user story.

By using our methodology, the game script and user stories that allowed for refining the purposes and gameplay can be obtained and used in any software development methodology that receives user stories as input. Our method specifies the design requirements for any technique in the development phase.

For this case study, the SCRUM framework has been used. Figure 16 illustrates the integration of iPlus, enriching the normal flow of SCRUM [84].

5. Analysis of the SG Designed with iPlus

5.1. Problem

As mentioned above, our case study deals with the proposal of an SG being used to support the teaching–learning process for the different topics to be evaluated in the “Ser Bachiller” test, required for admission to an undergraduate program at any public university in Ecuador. The design process is a customized SG, with different challenges or games that include the study fields topics.

5.2. Pedagogical Objective

Educaplay is designed to reinforce the academic aptitudes in mathematics, linguistics, natural sciences, social sciences, and abstract skills of students who try to enter higher education. The Index screen presents the different fields of study (see Figure 17).

5.3. Challenge and Missions

The game has five different areas, each with their own set of three challenges. For example, in the mathematical area, the first challenge is represented by a space world to train the ability to perform mental arithmetic calculations while dodging meteorites quickly (see Figure 18).

The second challenge is to properly establish a rule of three while building towers with stone blocks. If the relationship is correct, then the building stands firm; otherwise, the tower collapses (see Figure 19).

Finally, the third challenge is based on a popular television show where questions about math problems are answered. Players attempt to win the top prize by answering a series of multiple-choice questions. During the game, a player can simulate access to three lifelines: 50/50, Phone a Friend, Ask the Audience (see Figure 20).

5.4. Gamification

According to Deterding [39,85], “Gamification is the use of game design elements in non-game contexts.” Gamification motivates the users to achieve goals through rewards and creating a playful and fun environment.

Educaplay implements some gamification mechanics. It proposes different games (levels) structured by area: Mathematics, Language and Social Sciences. Users must successfully answer the challenges to earn points; they receive the medals (gold, silver, and bronze), depending on the scores obtained.

Additionally, it implements a social module to track other users, establishing competencies which can be viewed through leader boards. The scores allow quantitative evaluations of behavior in the game.

5.5. Learning Content

The game has preloaded questionnaires that correspond to the exams released by SENESCYT (the government agency that prepares university entrance exams). The game allows for creating new questions related to a study topic; this is done through the administrator module (see Figure 21). Additionally, in the administration module, teachers can see their students’ progress, and edit, and delete them.

5.6. Usability Assessment

We have used the questionnaires CSUQ [86] for the usability evaluation and PU [87,88]. They allow the use of a system, the quality of information within the system and the quality of interfaces of the system to be evaluated in a general way, and measuring and predicting the acceptance of new computer technologies by users. These questionnaires have been modified to adapt them to the educational context. The word “system” was changed to “educational application.” Besides this, the different tasks in the SG are evaluated according to the usability evaluation questionnaires. For further details of the experiment and data analysis, please review the dataset [89].

The roles identified are players (40 students) and administrators (40 teachers). The tasks that are evaluated for each position are the following. For the player: T1. Register and enter with the created account; T2. Enter the level of the game and the world of Highway play until the end-of-the-game message appears; T3. Pause the game while the student is playing; T4. Turn the game sound on and off while the student is playing. There are 14 tasks in this role.

For the administrator: T1. See a list of parameterizable questions; T2. Search questions by word; T3. Edit question text; T4. View user progress in the academic field; T5. See improvements in a game world by levels (fields of study). This role has nine tasks to be performed.

According to Nielsen [90,91]: “A mathematical model of the finding of usability problems” shows that a minimum of five users is necessary to find 85% of usability problems. The CSUQ questionnaire was applied to 40 player participants. The satisfaction of the player in the average usability evaluation was around 85%. The highest percentage obtained was approximately 93% in questions 7 and 19 of the CSUQ questionnaire, which refers to the ease of learning to use the application and the organization of its information. Simultaneously, the lowest score was approximately 78% in question 9, which refers to displaying error messages (see Figure 22).

Forty teachers were in the administrator role; the results obtained show an average usability satisfaction of 93.08%. The highest percentage was 97.86% in question 19, which refers to the system satisfaction, while the lowest percentage was 90.71% in question 3, which refers to how to complete the work using this system effectively (see Figure 23).

The PU questionnaire was also applied to 40 player participants; the average obtained was 89%. The highest value registered was 95% in question 7, regarding whether this game is fun. The lowest value was 84.64% in question 1, regarding whether school assignments were solved faster after using the application (see Figure 24).

6. Others Case Studies of Application of the iPlus Methodology

In this section, we summarize the different case studies in which the iPlus methodology was applied.

6.1. A Serious Games for Engineering Education

This case study is described in [92]. The result is a parameterizable SG that can reinforce the BPMN standard knowledge, aimed at university students who are studying or have passed a course related to “Organizational Process Management.”

6.2. A Serious Virtual Reality Game for Recreational Therapy

This game is a serious virtual reality game used for recreational therapy or Snoezelen for people with intellectual disabilities and low mobility, presented in [93,94]. Recreational therapy is a form of treatment that uses recreational activities to work on rehabilitation goals. It helps the user improve their attention to and perception of the objects displayed on the game stage, improve movement capacity, and increase muscle strength.

6.3. A Serious Game for Labor Inclusion of People with Intellectual Disabilities

In Carrión et al. [95], we presented an SG that aims to contribute to the labor insertion process of people with mild intellectual disabilities through simple activities related to specific works. In this game, the user can learn to develop the activities of tasks through a narrative. After that, the user knows what elements are needed to realize the mission or this task order.

The narratives that are considered in this SG are short, since it is aimed at people with mild cognitive disabilities, and we want them to enter the world of work by training with this game. In this game, users also improve their cognitive skills, like attention, memory and language.

6.4. A Gamified Application to Teach Basic Informatics Literacy

In [96], we illustrate the iPlus methodology application in designing an application to teach basic informatics literacy to older adults or people who are considered digitally illiterate in basic computing.

7. Conclusions

In this paper, we introduce a new participatory methodological approach to designing serious games. iPlus was conceived with experimental protocols and experts from different knowledge areas that have validated its various stages. Processes define each phase.

iPlus is a SGs design methodology that considers the basic concept of an SG as proposed by Zyda but adds a pedagogical component: the GamePlay, and Gamification elements. In particular, the metamodel proposed allows an understanding of each of the concepts used to design an SG and can be used to develop a formal modeling language. iPlus methodology can be integrated into other software development methodologies to form a complete SG development process.

Several case studies have been designed to illustrate its functionality. The multidisciplinary team’s active participation, considered in iPlus has made it possible to generate satisfactory design results for the product owner, fulfilling their expectations.

iPlus identifies the crucial elements to be considered when designing an SG, such as the story or narrative of the game, rules, game mechanics, serious content and gameplay. The result is a set of resultant artifacts allowing us to generate the game design document used by any software developer. The gamification techniques incorporated into the SG design lead to excellent engagement from end-users. In future work, we suggest designing software that helps in the automation of the iPlus methodology, so that the evaluators of serious games can have reports of the fulfillment of the parameters in each phase.