Moreno, J. (2012). Digital Competition Game to Improve Programming Skills. Educational Technology & Society, 15 (3), 288– 297.
Digital Competition Game to Improve Programming Skills Julián Moreno GUIAME research group, Universidad Nacional de Colombia, Carrera, Medellín, Colombia //
[email protected] (Submitted March 2, 2011; Revised August 4, 2011; Accepted November 11, 2011) ABSTRACT The aim of this paper is to describe a digital game with an educational purpose in the subject of computer programming, which enables students to reinforce and improve their abilities on the concepts of sequencing, defined iteration and nesting. For its design, a problem solving approach was followed and a score comparing mechanism was implemented in order to encourage students to analyze their solutions and look for better ones. To validate the game, a study with a 123 students sample was made, which did not only demonstrate students interest on the approach but also its educational effectiveness.
Keywords Educational game, Computer programming, Problem solving
Introduction Gaming, as a learning and skills improvement mechanism, is a natural process not just for humans but also for many other animal species (Huizinga, 1955). From an educational perspective, games have demonstrated to be an auxiliary tool in the construction of students’ systematic knowledge (Lewandowski & Soares, 2008). Systematization through digital games may allow for better students companionship, verifying frequent errors and presenting them multimedia resources in a different and more appealing way compared to traditional classrooms. A wide variety of studies points out the relevance of these resources to fulfill different learning goals like verbal, mathematical, logic, visual and motor-sensorial, as well as problem solving skills (Klopfer & Yoon, 2005). But, how is that possible? How can digital games help cognitive processes? Piaget (1983) analyzes the importance of the relationship between subject and object (in this case the game), and how object reactions to subject actions allow the latter to build mental models which, through interaction processes, become significant and constitute an important part in learning. Several works during the last two decades present a general vision about the educational use of digital games, describing its convenience in several areas of knowledge (Cavallari et al., 1992; Randel et al., 1992; Downes, 1999; Duplantis et al., 2002; Rosas et al., 2003; Mitchell & Savill-Smith, 2004; Egenfeldt-Nielsen, 2006; Ke & Grabowski, 2007; Chuang & Cheng, 2009; Kim & Chang, 2010). In the particular case of computer sciences, as it is noted by Becker (2001), the use of educational software is not prominent compared to other disciplines, but new developments have been seen in recent years. Some examples of the application of digital games in different knowledge domains within computer sciences such as software engineering and data structures can now be found in several works (Moser, 1997; Gorriz & Medina 2000; Gander, 2000; Baker et al., 2005; Lawrence, 2004; Papastergiou, 2009; Zapata, 2009). The work presented on this paper focuses specifically on the improvement of basic programming skills, without emphasis on any particular programming language; i.e., it is related to the algorithms design rather than the final coding. This issue is of great interest because, at least in Colombia, a computer programming class is not mandatory at the high school level, but it is a compulsory part of the curriculum for most engineering related degrees and obviously for technical degrees in computer related fields. Most teachers in the area would agree that teaching programming logic is challenging because it requires students not only to know how basic instructions work but, more importantly, how to use them in an adequate and creative way to solve a specific problem. For example, if in a classroom with 100 students a teacher proposes a simple exercise like: “Design an algorithm to read three numeric values and determine the largest one”; it would be quite possible for the teacher to find within the group at least 10 different solutions which would not just differ from each
ISSN 1436-4522 (online) and 1176-3647 (print). © International Forum of Educational Technology & Society (IFETS). The authors and the forum jointly retain the copyright of the articles. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear the full citation on the first page. Copyrights for components of this work owned by others than IFETS must be honoured. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from the editors at
[email protected].
288
other in an aesthetic way (the use of more or less instructions), but also in, for example, their efficiency regarding the use of resources (processor and memory), which is of great significance from a computational standpoint. Considering this panorama, an educational digital game called ‘ProBot’ was designed and developed in our research group with the aim of helping students to reinforce their knowledge on three concepts: sequencing, defined iteration, and nesting. According to Garza (2011), sequencing and iteration are two of the three fundamental elements of computers structured programming (the other one is selection, which is not covered in the game). Sequencing refers to the logical succession provided by the instructions in the algorithm. As they are executed, each instruction in the sequence must logically progress to the next one without producing any undesirable effects. Defined iteration, usually related to the expression for, is a control structure that refers to the repetition of a set of instructions until certain stopping criterion is met (the number of repetitions is known with antecedence). Once it occurs, the algorithm resumes its logical sequence. Finally, nesting is related to the enclosing of control structures-iteration for exampleone into another. It creates layers of instructions where the execution of the interior instructions depends on the execution of the exterior ones. The game is based on boxing matches where students must fight against several opponents who use certain set of movements. In order to win a match, each student must program his/her own ProBot (abbreviation for Programmable roBot) defining in an algorithmic way the set of movements the ProBot must perform in order to counteract its opponent movements and defeat it . In this sense ProBot is based on the constructionism learning theory proposed by Papert & Harel (1991), which suggests that new knowledge or skills may be acquired more effectively if the learners are engaged in constructing products that are personally meaningful to them. This is done by allowing students to define their own ProBot behaviors in terms that are easy for them to understand and then test them, putting the ProBots in the boxing arena. This approach is also aligned with the constructionism notion suggested by Kafai & Resnick (1996) who state that learners are most likely to become intellectually engaged when they are working on activities that are interesting and significant to them. In this paper, ProBot is described in detail and its performance tested in a real educational environment, proving the power of the computer-aided gaming approach to education and, in particular, to the development of basic algorithmic thinking in students.
Related works There are several works where games are used as learning environments in the computer programming field; some of them are focused in a particular programming language, while others emphasize in basic programming concepts or the development of logic-related skills. Within the games focusing on a particular language, RoboCode (Li, 2002) and Jupiter (Chicharro et al., 2008) can be found. Robocode is an easy-to-use robotics battle simulator that runs on several platforms supporting Java 2. In this game, instructions on how to manipulate a robot – tank (guns, radar, etc.) must be coded by the player, who then puts it onto a battlefield and let it battle against the opponent robots created by other players in order to see whose code works the best. Jupiter is similar to RoboCode, players may test their Java codes against each other in a competition environment in the form of tournaments, but it is more flexible in the sense that it allows for different kinds of battle games. Within those games focusing on basic programming concepts there are works like Scratch (Resnick et al., 2009), an educational programming language developed by the Lifelong Kindergarten Group at the MIT that allows people of any background and age (it is intended especially for 6 to 16 year-olds, but it has been used by people in all ages) to experiment with the concepts of computer programming by manipulating visual programming blocks to control some components (images, music and sound). In this category we also have Etoys (Kay, 2005), a child-friendly programming environment based on the idea of programmable virtual entities performing several activities on the computer screen. Both projects, Scratch and Etoys are free and implemented in a language called Squeak (http://www.squeak.org) which is a highly portable, open-source version of Smalltalk. Finally, there are games like Light-bot (http://armorgames.com/play/2205/light-bot) and some of the games found in http://www.hacker.org which, even if they may not be developed for an educational purpose, incorporate several logic concepts that players must use in order to overcome a set a challenges. 289
While the game presented here share several similarities with the aforementioned approaches, it also has some fundamental differences. Like RoboCode and Jupiter, one of the main goals of ProBot is to promote the improvement of skills through competence; nevertheless, ProBot is not aimed at experienced students who are already familiar with programming concepts and particular languages; instead, ProBot is similar to Scratch and Etoys in the sense that it is based on graphical programming, where simple blocks representing a basic programming instruction are used instead of pieces of code. Finally, ProBot is similar to Light-bot (in fact, it was after playing this game that the idea of ProBot emerged) and some of the games in hacker.org as, on the one hand, it is also graphical and, on the other, it is based on incremental difficulty challenges.
Game design Considering some elements that promote student involvement into an educational gaming environment (Malone, 1980; Prensky, 2001; Papastergiou, 2009) as well as particular needs of the subject, ProBot was designed following the next considerations, which are included within the elements of this section: It has intuitive controls It keeps student attention and is encouraging It has well defined rules It presents immediate and unlimited feedback It exhibits step-by-step execution It detects student errors and misconceptions It has progressive difficulty levels As multimedia resource it is appealing and entertaining but without containing extra cognitive load
Interface The game was implemented in Macromedia Flash, so students may access it from a Web navigator after it has been loaded in a server (local or Internet). Its interface is completely visual and is divided in four sections as presented in Figure 1: upper, right, bottom and center.
Figure 1. Level 1 interface In the upper section there are three different components (from left to right): the level in which student is currently playing; the available instructions or the corresponding level and the options to enable and disable game sounds and background music. The available instructions are, from a structured programming point of view, the set of structures that are valid for the algorithms a student may define. 290
In the right section the workspace, where a student can define his/her algorithm, is found. It is here where the student drops in a sequential way the instructions dragged from the upper section: high punch, low block, dodging, etc. Such workspace is analogous to a source code in a programming language, with the difference that the number of ‘code lines’ that may be written is limited by the number of cells in the right section, and each cell can only contain one instruction. In the bottom section there are two options: in the right, the boxing gloves-like button allows the player to see the “opponent’s training routine,” that is, the set of movements the opponent will perform during the fight; in the left, the bell-like button starts the fight. Once the bell is pressed the ProBot begins to move in a synchronized way with the opponent movements, according to the instructions provided in the workspace. In the central part of the bottom section a small board is found, where key variables of the opponent and the ProBot are shown during the fight. In this board the ‘resistance level’ is presented, as it is common in most fighting digital games, as well as the character’s energy (battery level). The last feature was included into the game looking for students to consider that problems may have resources restrictions. Finally, the central part of the interface is where action happens. Once a fight starts both, ProBot and opponent, perform their corresponding instructions step by step. If in one of the steps any of the characters receives a punch, its resistance level, which has an initial fixed value in each level, decreases a certain amount. The fight ends when the resistance level of one fighter drops to zero, in which case the other one wins the match. ProBot energy level, which has also an initial fixed value in each level, decreases every time that it punches or dodges, and when this level drops to zero ProBot shut himself down and inevitably loses the match.
Errors detection In the computer programming context, a complier may be defined as a program that translates a source code, defined in a high level language, into another one in a lower level, typically machine language. This is precisely the main function of the game execution engine in charge of translating the set of instructions the student defines in a set of movements that ProBot performs during the match. A compiler is usually composed of two elements: a lexical analyzer (lexer) and a semantic analyzer (parser). The former validates individual instructions syntaxes whereas the latter validates the global semantic of the source code. In this game, a lexer is not necessary because individual instructions are not written freely by the student but are chosen from the menu in the upper section of the interface. On the other hand, validating semantic is made by the parser, looking for errors which, in this case, are related to the wrong use of the ‘defined iteration’ concept. In particular, there are two types of errors or misconceptions that students may have during the game: the order of iteration instructions is wrong or the beginnings of the iteration instructions do not match the closures. Both types of errors are detected automatically by the interface when trying to start a fight and informed to the student, so he/she can correct them.
Difficulty levels The game has in total seven difficulty levels that become available as student moves forward. Besides the fact that this is an obvious mechanism for most digital games to maintain the gamer attention, it also has a pedagogical use in the sense that it presents in an incremental order for the concepts to be covered through the game: that is, they are presented in the same order as in the course outline. In particular, the first levels are devoted to the sequencing concept, the following levels add the simple iteration concept, the next ones deal with the concept of multiple iteration and the last ones with the concept of nested iteration. An important feature of each new level is, as presented in Figure 2, the incorporation of additional available instructions as well as more cells in the workspace, allowing the student to define more complex algorithms to solve the corresponding problems. Each level has a different opponent with his own initial resistance level and punch strength. Each one of them also has its own sounds, gestures and messages; the first two features are included with the aim of entertaining the student, whereas the last one with the aim of encouraging him/her to defeat the opponent. As evident from Figure 1 291
and 2, the audience increases on each level adding defeated opponents as well as new spectators to the benches in order to incorporate a dramatic effect.
Figure 2. Level 4 interface Player name -
Table 1. Scoring table example Last login Level 4 4 3 3 4 3 3 2 2 2 1 1 2
Score 240 225 220 215 185 120 105 90 70 45 45 35 25
Scoring As usual in most digital games, a level password element was included so the student can save it to restart the game in other moment from that point once the level has been overcome. Such feature has the additional purpose of identifying the score a student has accumulated along the matches. This is made in an encrypted way to avoid undesired manipulations on such values. In this game, the score is defined as the sum of resistance and energy levels after defeating an opponent, so the accumulated score in level n corresponds to the sum of the scores obtained in levels n, n-1, n-2 down to level1. As the reader may have inferred already, this score serves to measure the efficiency of the algorithms defined by the student, i.e., the higher the remaining resistance and energy levels after winning a match, the more efficient the corresponding algorithm is. In other words, an opponent can be defeated in many ways, but each way may differ from the others in the resources that are used (energy) and in the punishment that is received in return (resistance). With this feature, good programming practices are promoted through healthy competition. In their search for higher scores, students become aware that, similar to classrooms or real life problems, there are lots of strategies to solve
292
them, but not all of them are equally efficient. This way, they are forced to think about how “good” their proposed solutions are, and not just about solving the problems. This phenomenon was validated in the study with actual students described in the next section. It was observed that many students, once they noticed their solutions could be improved after comparing their score with that of fellow classmates, preferred playing again the same level until reaching a higher score, even if they had solved problem (winning the opponent), increasing their skills this way. To allow students to make such comparisons, a web application was built where they could enter their names and level passwords and a dynamic ranking board was displayed with all the group’s scores. Table 1 shows and example of the information that students could see after accessing the web application, where they can clearly measure the efficiency of their solutions as compared to the ones of their classmates. Even though the ‘Last login’ data presented in the second column of Table 1 was not used for comparative purposes during study, it could be used, for example, in fixed-time competitions.
Validation In order to validate the game proposed in this work, a study was conducted at the Universidad Nacional de Colombia aiming to assess its effectiveness and motivational interest for improving the previously mentioned programming skills on the basis of the curricular objectives pertaining to a course in engineering. The sample was composed by 123 students attending the course ‘Programming fundamentals,’ aged 16–18 years old, 74 males, 49 females, all of them with basic computer knowledge, including Web browsing (to access the game). The sample was divided randomly into two groups: a control group and a test group. To determine if there was a significant difference among the general previous performance of the two groups, a hypothesis test for independent samples via the t statistic was applied as well as an effect size analysis via the Cohen’s d. In both cases the data from the first exam of the course were used. Such an exam did not cover the three concepts of interest: sequencing, iteration and nesting; but related concepts like the logical operators and the binary numeric system. For this reason such an exam cannot be considered as a pre-test per se, but as a measure of previous related performance of the two groups. The corresponding summary data is presented in Table 2, where grades are on a 0-5 incremental scale with a decimal number, as usual in most Colombian higher education institutions. The null hypothesis (H0) was that mean grades were equal and consequently the alternative hypothesis (H1) was that they were not. Group Control group Test group
Table 2. Previous data about study groups performance Students number Mean 63 3.206 60 3.315
Standard deviation 0.674 0.776
The value of the t-statistic is -0.830 with a corresponding P-value of .408. As the P-value is higher than .05 it could be said, with a 95% significance level, that the null hypothesis is accepted. In other words, there is not statistical evidence of previous difference between both groups regarding their performance in related concepts. Consequent with this result, the Cohen’s d value was 0.109 which implies a small effect size. After teaching to both groups all required concepts in a regular classroom according to the course syllabus during four weeks, a regular set of exercises was given as homework for two weeks to the students of both groups, while students from the test group, apart from the regular exercises interacted with the game during same period of time. After that time, a test was made simultaneously to students of the two groups containing four problems that covered all of the taught concepts. The results of the test are summarized in Table 3. Group Control group Test group
Table 3. Global validation results Mean 3.471 3.847
Standard deviation 0.579 0.581
To determine if there was a significant difference among the results of the two groups, a hypothesis test was performed again. In this case, the value of the t-statistic using data from Table 3 is -3.594 with a corresponding P293
value < .001. According to this value the null hypothesis is rejected in favor of the alternative hypothesis, that is, the mean grades are not equal between the groups, with a difference of 0.376 (10.8%) in favor of the Test group. Additional to this result, the Cohen’s d value was in this case 0.654, implying a medium effect size. Although this study demonstrated game effectiveness to improve programming skills, means difference was not as large as initially expected, so a more detailed analysis was made. This time, instead of analyzing general test results, the individual results per exercise were analyzed, considering that each one corresponds to a specific concept. Summary of these results is presented in Table 4. Concept
Control group Mean
Sequencing Simple iteration Multiple iteration Nested iteration
4.100 4.021 3.252 2.451
Table 4. Detailed validation results Test group Control group Test group Mean Standard Standard deviation deviation 4.065 0.559 0.582 4.042 0.607 0.567 3.795 0.599 0.719 3.447 1.088 0.820
t-statistic
P-Value
0.340 -0.198 -4.539 -5.751
.735 .843
