We initially define a user-centric model for the design of educational games, as shown in Figure 1. Based on this model, the design phase takes into consideration each user type’s initial aspirations that motivate them to use the game, the specific targets they set to achieve through the game, the metrics that will determine the level in which the targets are achieved as well as the feedback provided to them by the system depending on the corresponding target.

These inter-connected concepts are different for each user type and therefore relate to different aspects of the game. For example, the game administrator’s aspirations can be the game’s and server’s problem-free operation and the corresponding targets can be the backup of the data produced, the frequent monitoring for possible malfunctions etc. Performance metrics could include the server’s database capacity, the cache memory capacity etc, while feedback that will indicate whether the server is working properly can comprise of error messages produced by the game (e.g. in case new data cannot be saved).

Similarly, a teacher’s aspirations can be the successful teaching of units on computer programming while the target can look like “at least three of the four game levels on loops will be achieved by all”. Thus, the set metrics can be each level’s and student’s score, log files from the game etc, while the feedback can be a report with the student’s progress at a given time/level. Furthermore, a student’s aspiration can be to enjoy his time within the game, to distinguish himself through accomplishing the assigned tasks and to learn. Based on these aspirations they can set their individual or group targets across the overall learning objectives. Their performance metrics can be the score/resources they have gathered, how many times they have had to retry before writing lines of code correctly etc. Finally, feedback can be explanatory messages from the agents, introductory narrative or video that explains the scenario, errors in the program they’re writing etc. This closely interconnected puzzle is shown in Figure 1 and provides a more abstract overview of the initial metrics taken into consideration during design phase, following a user-centric approach. This model takes the form of a puzzle since all user types need to be addressed equally and represent a different point of view of the game.

Figure 1: CMX Design Strategy Puzzle

The next step that will lead to the proper construction of our framework is the identification of the methodology our game will be based on. More specifically, as shown in Figure 2, students will initially engage in actions, which will in turn generate their desire for improvement through attractive scenarios. These actions will help students gain new knowledge regarding the targeted educational content and through collaborative activities, students will be able to produce the set learning outcomes. In the end, the learning objectives will be achieved after the game experience is properly evaluated.

Figure 2: Methodology steps of the CMX educational game

Finally, both aforementioned steps are reinforced from the review presented in the related work section. More specifically, based on the review of the existing frameworks that guide the design of educational games in general as well as of the features supported by educational games focused on computer programming education, we move on to propose an extended framework that includes the most commonly identified concepts as well as a series of sub-concepts that provide a more in-depth visualization of the steps to be followed during the design and development process. Based on this framework, which is shown in Figure 3, we have designed and developed an MMORPG educational game that aims to teach computer programming.

 

 

Figure 3: CMX Design framework

The CMX Design framework includes concepts that need to be represented within any educational game that aims to teach computer programming. It is abstract enough to be employed by future designers and developers and detailed enough to act as a solid guide without allowing many arbitraries. The most prominent concepts that define the game’s design are:

• Infrastructure. The design initiates with the establishment of the infrastructure architecture, the technical requirements specification as well as the user interface and concepts visualization design. The infrastructure will have to support simplicity and ease of use. ·
• Learning objectives. Designers will have to initially define learning objectives that the game will be required to successfully support. These objectives can include generic goals (e.g. more than 80% of the students will complete all game’s activities within the given deadline) or programming-specific goals (e.g. the 90% of the students will drag & drop correctly the lines of code regarding if statements). Additionally, students can also define their own goals depending on what they desire to achieve through their interaction with the game (e.g. “I have understood if statements so I want to complete all tasks related to loops”).
• Pedagogy. The game’s layout will strongly depend on the learning strategy to be employed during class as well as on the way the course will be organized (i.e. number of units of learning, educational material to be taught etc). For example, it is possible that the teacher will want to create a level per unit of learning, or merge specific units of learning into one game that will correspond to a certain set of learning objectives. Thus, it is essential to determine these features at an early stage.
• Learning outcomes. The determination of the learning outcomes is strongly inter-connected with the set learning objectives. Target outcomes can include the comprehension of the taught material, i.e. computer-programming concepts, such as variables declaration, if statements, loops etc, skills development, such as critical thinking, teamwork, leadership etc as well as interaction capabilities and engagement with innovative technologies and their features.
• User. A user in an advanced educational game can represent different types (e.g. student, teacher, administrator, agent), where each type signifies another aspect of the game’s functionalities, as already explained in the CMX design strategy puzzle. Additionally, the specific characteristics of each user need to be determined (e.g. age, prior knowledge, preferences etc) as well the aspirations that will drive the user’s interaction with the system (e.g. win the game-student, ensure problem free operation-administrator, instruct and assist students-teacher, guide and scaffold players-agent). Finally, each user will need to be able to reflect on the game experience for feedback gathering and future refinement of the game’s functionalities.
• Scenario. The game’s scenario should be thoroughly researched and planned out in order to produce an attractive and immersive virtual world (e.g. fighting arena, castle, forest etc) with interesting characters (e.g. wizards, robots, mentors, snowmen, prisoners etc) that are required to complete interim and final goals (e.g. save the princess, put the map’s pieces in their correct order, navigate through the tree etc). Designers have to also define what types of awards players will be granted with during the game, in order to increase their motivation to continue learning.
• Activities. The design and development of individual activities is essential and will result to the interested and active participation of students. It is important that students will be able to interact with the world’s elements and collaborate with others towards the achievement of all or some of the goals. Additionally, the environment should provide scaffolding mechanisms throughout all activities that will assist students during challenging tasks. Finally, a number of different ways in which students can contribute their knowledge should be included, since not all students learn better using the same techniques. Thus, an educational game should incorporate a programming editor, along with the ability for students to drag & drop lines of code as well as answer multiple choice questions.