Case Study 4 : Red Frontier

Elisabeth Yaneske, University of Teeside

The idea for my game came about through my experience of teaching programming to computing students at the University of Teesside. I noticed that year after year students learning to program seemed to struggle with the same concepts. I wanted to find a way of helping learners concretize these concepts using visual metaphors and I felt that a game environment would be ideal. The game is aimed at adult learners, primarily students studying in Higher Education, who are learning to program. The game has been used by 71 computing students.

The game story is based around a crisis on Earth, A virulent fungus is spreading over the arable land and wiping out the Earth’s crops. Scientists have not been able to find an effective fungicide and so a decision has been taken to set up biodomes on Mars in order to grow crops to feed the starving billions on Earth. A number of facilities have been set up on Mars but they are not yet operational. The mission of the player is to get the facilities operational so that the biodomes can be built and crops shipped back to Earth. There are three facilities that are not yet operational, the power plant, the seed sorter and the manufacturing plant. The power plant provides power to the whole facility, the manufacturing plant cuts the biodome material into the shapes required for their manufacture, and the seed sorter ensures that only uncontaminated seeds are planted in the biodomes. Each facility requires some programming to get the equipment working. Players use a graphical user interface to create the correct pseudocode to control the equipment in each facility. The name of the game and the facility on Mars is Red Frontier.

The design of the game is based on the premise that programming languages share several abstract concepts, such as control structures. These concepts are often harder to understand than the programming syntax itself, especially for those learning their first language. The consequence of not understanding these concepts is poor algorithm design leading to inefficient and non-scalable program code. Unfortunately, when learners test their code they only receive errors when there is a problem with the programming syntax, similar to running a spell check in a word processing package. In the same way that perfect spelling and grammar do not ensure a prize winning novel, perfect programming syntax does not ensure a good program. Learners become product focused rather than process focused with their main criterion being whether a program works rather than whether the code is efficient and scalable. Syntax errors can also put students off programming early and make them overly cautious causing them to make more mistakes. The aim of Red Frontier is to help learners concretize abstract programming concepts, such as how a loop works and why it is better to use a loop rather than multiple IF statements, which are generic concepts. The game does not teach program syntax which is program specific. Players create code by selecting options from a toolbox in a visual programming environment. The advantage of using a game for this purpose is that it can provide an engaging simulation where learners can be presented with problems in context and receive immediate feedback on their actions.

The underlying pedagogy of the game is based on experiential learning theory or ‘learning by doing’ and on a social constructivist view of leaning. The game is played by groups of two to three learners working together as a group to solve each problem. The dialogue between the learners forms an important part of the learning process. Learners have to justify their opinions to the rest of the group in order to have their solution accepted. As mentioned before, one of the advantages of using a game is that it provides instant feedback in context on the player’s actions. Players receive hints on problems detected in their solutions. They are able to step through the code and see how the values of variables change. When the players implement a working solution they receive feedback on the design of their solution. The feedback shows them a model answer and tells them explicitly about the advantages of the design. Players are encouraged to reflect on these good design principles once they have finished playing the game.

The player’s actions are recorded as a script which can then be played back. This script serves two purposes. The script can be used as a teaching tool to encourage reflection in the group through discussion whilst going through the play back. The script records each keystroke made by the players as well as their mouse movements. In order to understand what the players are actually thinking when they make conceptual mistakes they are asked to talk through the play back explaining what they are doing at each stage. Having a formal method of recording how students program and being able to discuss why they have made certain assumptions allows further misconceptions to be identified. These misconceptions are documented and may lead to the modification of the game to add further puzzles or perhaps the development of further games or other teaching tools to address these issues. Often, if a program compiles and executes without error then a student will assume that that is all that matters. They will rarely ask for feedback on the design of the program. The game gives an opportunity for all students to receive formative feedback on the design of their solutions.

At present the game contains three facilities, the power station, the manufacturing plant and the seed sorter. Each facility has an associated problem that players must solve in order to get the Mars base operational. Players can choose the order in which to solve the problems but are advised that the seed sorter is the easiest problem to solve.

Red Frontier

On entering the seed sorter scenario the player will be shown an animation of a checking machine with a red and green light and two tracks exiting the machine. They must program the seed sorter so that contaminated seeds are incinerated to prevent the fungus spreading to Mars. A red light indicates that seeds are contaminated. The track on the left goes to the incinerator. The players must program the track direction based on the light state. This problem acts as an introduction to the game interface but also teaches the players about using a function within a conditional statement. As a general feature for all problems players must initialize variables before using them.

The manufacturing plant shows an animation of a cutting machine that at present does not know how to cut shapes. The intended learning outcome for this task is that learners understand the advantages of a generic function. Players are asked to write a function to cut a square, and then a function to cut a triangle. Then the game explains that rather than have a separate function for each shape it would be more efficient to have a generic function that could cut any regular polygon required. The task for the players is to create this generic function so that the biodomes can be constructed from the cut material.

The power station must periodically check the status of the generators to determine the total power that is being generated and whether any generators are faulty. Players are asked to create a function that accepts a list of generators that are currently on. It is assumed that if the generator is on then it will have a power output greater than zero. Players are therefore told that faulty generators will have a power level of zero. The function must return the total power being output and a list of the faulty generators. The desired learning outcome for this puzzle is that learners understand how a FOR EACH loop works to cycle through each element within an array.

With each of these scenarios tasks players are provided with a list of functions that are available for them to use. When they run their code they see an animation that either shows the equipment working successfully or the equipment failing. The animations are important as a visual representation of the task they are trying to solve. This helps learners to visualise the task and relate it to the non-virtual world that they already understand.

Students were asked to play the game during scheduled tutorial time in the computer labs. The game had to be installed on each computer before the session. I was present during these sessions to provide technical help and general support to students. The game has initially been tested with first and second year undergraduate students studying programming as part of their degree. The participants were asked to complete an online survey that asked them about the game interface and also their perception of how well the game helped them learn. In addition, focus groups were conducted with student volunteers in order to obtain more qualitative feedback.

In general, students enjoyed playing the game and were engaged in the puzzles. In terms of learning, most students felt that the game had helped them learn by providing a way of applying theory in context. It helped them to visualise the advantages of certain design choices. Feedback from students led to the generation of ‘bug lists’ that contained a combination of technical problems that the students had uncovered and user interface changes that the students requested. Tutors of the modules involved were keen to use the game again and felt that it added value to the student experience. It is intended that the game be trialed in more modules and be further developed with more puzzles.

It was decided that the C# programming language should be used for the development of Red Frontier. This was for a number of reasons. Firstly C# is ideal for creating user interfaces and handling user interaction via the Forms library. C# is also a good language for rapid development and code maintainability. One down side to C# (and other managed languages) as opposed to a native language like C++ is that it runs slower however it was not felt that the requirements of Red Frontier were such that they would require the extra speed. The application relies on the playback of video which has been created using Flash and then encoded so as to be played back within Red Frontier via the standard media player.

Development began with the assembly of a set of requirements. From this a design document was created to be used as an overview during application development. The development phase itself consisted of a number of small iterations adding functionality leading toward fulfilling all the requirements (agile coding method). Once new functionality was in place it was tested as fit for purpose and for any bugs. The final phase was a longer test phase testing functionality and usability. Each development iteration was concluded with a test phase where functionality and usability were tested. This naturally led to some alterations that were then fed back into the next iteration. Once the application was feature complete a fuller testing phase was carried out that, as well as spotting some further bugs, helped detect any issues the user may have with the interface.

I applied for funding from the Enterprise Development Fund available at the University of Teesside and obtained £3,000 to develop the game. Half of this money was spent on the development of the game specification and on the game engine and game interface. The other half of the money was used to pay an animator to create the introduction animation for the game, the game map and the failure and success animations for each of the puzzles. The money spent on the animations was a true reflection of the cost but the money spent on development did not in reality cover the developer’s time.


  • Think hard about the scope of the game and what is achievable with money, resource and budgetary constraints. Otherwise the game may never get finished.
  • Test, test and test again. User-centered design is essential to the success of the game.
  • Make your game scalable, include the ability to update the content and add new content.