SpaceChem is a puzzle computer game made by Zachtronics intended to teach computational thinking for players of unspecified ages. While the context of the puzzles revolves around chemistry, the core challenge of the puzzles revolves more around how to synchronize discrete operations in elaborate machines to work together towards specified goals efficiently in open-ended environments. That is to say, the chemistry serves as a backdrop, rather than the core learning objectives.

Learning Objectives

Chemistry Knowledge

SpaceChem does not require prior knowledge of chemistry, as it teaches players the necessary chemistry concepts as a part of the tutorial. This domain knowledge (taught in the tutorials) consists primarily of the following concepts:

1. Atoms are the basic building block of chemicals. Atoms are divided into different elements, which behave differently.
2. Atoms can bond together to form molecules; different combinations of atoms form different molecules, while the specific orientation of where the atoms are does not matter (this is an oversimplification to make the puzzle solving more open-ended and less domain-focused)
3. New bonds can be formed between atoms to make different molecules, and old bonds can likewise be broken to form new molecules.
4. Each element has a maximum number of bonds that its atoms can make. This maximum number of bonds is specific to the element.

Computational Thinking

More important than the above chemistry knowledge, the game requires a degree of proficiency in computational thinking, and most of all, grit. It is difficult to pin down exactly which skills are prerequisite vs learned in-game because in principle, players can learn the computational skills the game demands through trial and error while playing. That said, the game is generally accepted as quite difficult by its players and will presumably be inaccessible to players with a low frustration tolerance. One can compensate for lower computational thinking skills with patience and grit – if players start with a lower skill level as well as low tolerance for frustration, then they are likely to get little out of the experience. Below are my impressions of the skills that can be learned/improved by playing the game.

1. Players will use directional commands and rotation to ensure that the relevant pieces are brought to the correct places in correct orientations on the board in the right order.
2. Players will use synchronization commands to control the timing of execution across parallel processes to insure that the correct commands are executed in the correct sequence.
3. Players will identify opportunities to incorporate previously implemented constructs as component parts of a solution to a more complex problem and apply these components effectively in context.
4. Players will refactor their solutions to be more efficient by using fewer commands and/or taking fewer cycles (less time) to run to completion.
5. Players will identify which aspects of their solution are failing and why in order to revise their solution based on the observed results.
6. Disposition: Players will persist in the face of failure and learn from their mistakes and partial-solutions as described in skill 5.

The disposition (Goal 6) is not so much learned in the game as it is a prerequisite. If players do not approach their failures in this way, they are likely to be turned off and quit the game. The only negative review of SpaceChem on the front of its steam page says,
“If you’re someone who likes playing video games for fun rather than reward, you’ll probably not find much to enjoy with SpaceChem.”

This is apt, as players really must be self-motivated to tackle the game’s challenges in order to get much from the experience. That said, for those with the grit to stick through the game’s challenges, the difficult puzzles will present further opportunity for players to practice their persistence.

Transfer

The dispositional goal is the seems the most likely to transfer to other problem solving contexts – grit will always be valuable to facing challenges. The domain knowledge imparted (regarding atoms, molecules, etc.) is unlikely to be particularly useful, as it is rudimentary compared to the difficulty of the puzzles. Most players able to tackle the games intense challenges are likely to already have most of the real chemistry knowledge the game imparts, and those that don’t are unlikely to have mastered the complex skills used in high school chemistry (like balancing chemical equations, making stoichiometry calculations, etc) though they may remember a few chemical formulas.

Likewise, the computational thinking goals are not obviously transferrable into acutal programming or mathematical contexts, as the specifics of the moves used to address the game’s challenges are unique to the game (like using a ‘sync’ command to make one process wait for another before proceeding – while there are analogies that can be drawn from technique to coping with asynchronicity in programming, the actual techniques used in-game are not obviously transferrable).

With that in mind, players who are not experienced programmers, may cultivate an awareness of certain kinds of problems that computational solutions may encounter: e.g. it could be the case that one function takes longer to complete than another, and that this can cause problems if not well handled. Likewise, the techniques used to ‘refactor’ solutions to make them more efficient may not transfer to other computational contexts, but the general value of elegance (in terms of a solution’s compactness and the speed with which it runs) are valuable considerations outside of the game. So it seems most likely that the transferable benefits of the game from a learning standpoint are primarily in an awareness of certain categories of considerations as outlined above, rather than developing the tools to solve computational problems directly. So players can be expected to learn that they should check that a computational solution is executing commands in the right order, avoiding race conditions, making use of abstraction to repeat previously figured out sub-calculations, and running efficiently, but they cannot reasonably be expected to be able to check these things in an out-of-game context, because the tools and techniques used to do so will be significantly different than their in-game experience.

Mechanics

Gameplay centers around iteratively developing circuit-like machines that run parallel processes on a grid. Your goal is to convert several elements or compounds into other chemical products by stringing together the right series of commands within spatial constraints. Each reactor you create has its own grid which can contain two parallel circuits, one red, and one blue. Each circuit has its own set of commands and its own ‘waldo’, a circle that navigates the circuit and executes each command when it crosses the block representing the command.

Commands include dropping new elements onto the board, picking them up or dropping them, turning them around, bonding them together, and outputting desired molecules when they are formed. Each reactor includes two circuits running at the same time. These circuits must be used together and synced up at the right points to ensure they work together to build the desired molecules and put them in the right places at the right times. If two atoms touch each other (hit the same grid cell at the same time) the program crashes and the player must adjust their circuits to fix the problem.

The game is further complicated by eventually introducing levels that require multiple reactors in order to produced the desired results. This emphasizes the process of building very complex systems by individually building functioning systems and integrating them together into a larger whole.

Each level selection screen visualizes the player’s solution in terms of the number of cycles elapsed (runtime required for the solution to beat the level), the number of reactors used, and the total number of symbols used (number of commands). Further, the game includes achievements that encourage players to be efficient in their solutions to various levels.

Together, these incentives encourage players to go beyond solving a problem any way they can and to instead seek a good solution for each level.

Dynamics

It is difficult to plan out a full solution to a level in advance of running your program. Small differences in the timing between both circuits, as well as the precise position and orientation of the input molecules makes it very difficult to know whether you’ve totally got it until your program works (or doesn’t). Even when you know that your solution is incomplete, it’s difficult to anticipate what the most immediate problem with your current implementation will be before you run it and see where it crashes. This encourages the player to be very iterative in their approach. There is no penalty for trying and failing. I found myself very often implementing a small part of what I thought was needed and checking whether things wound up where I expected by running it (and having it crash somewhere), then picking up from there by identifying what needs to happen next (or what is happening that shouldn’t) and fixing one small piece at a time before running and re-evaluating, over and over until I had a working solution.

Each partial solution will yield a different result that must be analyzed in order to improve and beat the level. My most common mistakes were to fail to fail to grab an atom either because I misjudged where it would be placed, to mis-time my outputs so that the beginning of the next loop crashed an atom into the end of the previous loop, and to simply forget to drop an atom in the output area. Below is my journey through one of the earlier levels:

That said, it’s certainly possible to fully implement a functioning solution on the first try and only run the level once. This would be a feat of meticulous planning well beyond my own abilities, though. I assume that most players take a similarly iterative approach to my own.

The incentives for time and fewest-commands efficiency (scores and achievements) also encourage players to go back and try again once they’ve completed a level. In that sense, the outer loop between levels can be as iterative as as the inner loop of solving one level.

Aesthetics

I would describe the overall feeling of playing the game as iterative solution-crafting. Each run presents the opportunity to address a key problem with the previous implementation, while likely invoking new problems that ultimately bring you one step closer to a viable solution. The open-ended nature of the puzzles evokes feelings of discovery and self-expression. The more complex the challenge, the more pride one finds in their individual solution. Part of the appeal is certainly the challenge; most of the reviews on steam mention intelligence in one way or another. Succeeding makes you feel smart, and the hard levels may call into question players’ intellectual integrity. One player wrote, “if you think you’re smart, buy this game, and realize that you are not smart enough.”

Learning Science

Spatial Contiguity

When you hover over a command in your inventory, a tooltip appears nearby to tell you more about what that command does.

Similarly, when you right-click a command that is in your circuit, a menu pops up that allows you to make adjustments to that command like switching its color, or switching an add-bond command to a remove-bond command.

These tw0 mechanics leverage spatial contiguity by keeping the explanations/elaborations of a command physically nearby the command, itself (as opposed to say having one centralized text box on one side of the screen where all tooltips are displayed). This reduces the cognitive load required to make the connection between the command and the additional information provided by the tooltip or menu. That said, the right-click menu that pops up actually covers the command you clicked on, rather than being next to it. This may make it a bit harder to remember exactly which command you clicked on. In the example in the above picture, even though I can choose whether to set the selected command to a bond+ or bond-, I can’t tell just by looking at the popup menu whether the command I selected was already bond+ or bond-, so I have to remember which it currently is in order to know if I should make a change. This could be easily fixed either by highlighting the current selection in the popup menu, or simply moving the placement of the popup menu to avoid obscuring the selected command in the circuit.

Feedback

The game gives some correctness feedback, but very little corrective feedback. When two atoms collide, the simulation crashes and the player is told to stop that from happening, but they are given no direction as to how to do so. The feedback is immediate when the problem occurs, and gives some indication of what the type of problem is, if not how to solve it. Creative and/or persistent players can conjecture what should fix the problem, implement their idea, and then analyze the result to see what if anything should be changed about the new solution, but there is very little help that will be given to players who are truly stuck.

This is unfortunate, because it increases the level of grit required for players to persist through the more challenging levels, which will precisely deter the players who could most benefit from increasing their frustration tolerance. That said, it’s not obvious what kinds of feedback could be useful without simply giving away the complete solution. One method could be to develop a series of incomplete solutions that get closer and closer to fully solving the problem. Stuck players could ask for hints and receive scaffolding that gets them started. They could ask for more and more hints until they are finally shown the complete solution if they truly can’t get it. The hope here is that by revealing partial solutions, players might notice elements of deep structure that solves some of the issues their implementations face. That might inspire players to try new things before asking for another hint.

Two problems with this strategy are how to address the possibility that players abuse hints and learn very little from them, and how to allow players to feel they are expressing themselves when there is only one sequence of solution hints, which might differ significantly from their approach. Even if a player was on a possibly right track, the hints might steer them away from their approach in a way that detracts from the players’ sense of ownership over their solution.

A simple strategy for dealing with the first problem (hint spamming) could be to require that players try a number of new solutions before requesting another hint. This wouldn’t make it impossible to abuse the system, but it could encourage players to try something new before blasting straight to requesting a functioning answer.

The second challenge is more difficult to address. One route could be to instead develop a number of different solutions to each level (each broken down into a sequence of partial solutions), and to create some measurement of similarity between a player’s current attempt and each solution path, so as to select the hint that best aligns with what the player is currently attempting. This is time consuming and technically challenging, however, so it may not be feasible for a small game like this.

Segmentation

The game does a good job of introducing concepts and techniques in a gradual manner that avoids overloading the player with too many new moving parts at once. This allows the player to master the basics of moving the circuits around where they want, inputting new atoms, picking up and dropping atoms, and such before dealing with the more complex manipulations like rotate and sync. Likewise, the player has many opportunities to grapple with individual reactors before contending with the need to organize multiple reactors into a greater system. These things together lower the cognitive load to make the game more accessible to learners, which keeps it from getting too frustrating too quickly.

Linking

After introducing a concept or technique in isolation, the game does a good job of integrating that into successive levels. Once you learn how to use sync, you will continue to rely on it for the rest of the game. Each new command gets re-used in ever more complex contexts in ways that show their interrelated usefulness. Dropping has a particular relationship with output, for example. You can’t score a completed molecule without dropping it into the correct zone and then calling the output command. Every level requires calling these two commands in the right way, in progressively more difficult problems. Using these together over and over helps to implicitly crystallize them into one larger technique of dropping & outputting a completed molecule. Once these are chunked together conceptually, it’s easier to use them more fluently to efficiently solve harder problems.

Synthesis

In the end, SpaceChem is more about the satisfaction of completing a challenging puzzle than it is about learning. The techniques at your disposal bear certain analogy to computational concepts of loops, parallel processing (and the challenges of asynchronicity), and iterative bug-fixing, but they are too abstracted away from real computational problems to serve as meaningful practice in computational thinking. Likewise, the chemistry knowledge involved is rather shallow compared to the overall complexity of the game, so most players able to succeed are likely to know most of the chemistry content the game includes (some of which is fictional, anyway).
SpaceChem does not teach you how to program, debug code, balance chemical equations, or make the kinds of calculations common in high school chemistry.

That said, SpaceChem does have the potential to introduce players into some of the dimensions of computational thinking that people interested in computer science will need to contend with. Players won’t learn how to wrangle asynchronous function calls, but they may learn that it’s a problem if one part of your program depends on another that takes longer to execute. Likewise, they won’t learn how to debug a program, but they may learn that when they’re trying to fix something that it can be helpful to attempt a solution, check it, analyze what went wrong, and use that understanding to try another solution that hopefully brings them one step closer to solving their problem. As for chemistry knowledge, if a player somehow goes into the game able to handle rigorous problem solving without knowing the basics of how atoms bond together to form molecules, what the names of the most common elements are, or the chemical formulas for very simple molecules like water, then they will walk away learning some domain knowledge too.

The most interesting thing to be cultivated by playing SpaceChem may be patience and grit. Ironincally, it takes serious determination to overcome the game’s challenges, so the players most in need of this benefit are unlikely to reap it. Still, it is very satisfying to figure out your own way to solve any of the game’s challenges, so there is real potential for players with enough grit to buy-in to develop even more grit by practicing in the face of extreme difficulty.

Strap in kids, this is a weird one. We Become What We Behold is a browser game made by Nicky Case to teach players about how the news cycle escalates societal conflict. The game ends with a violent (if cartoonish) bloodbath, so if you would rather not expose yourself to that, you may want to skip this review. If you’re unphased by that warning, you can play the game here.

Players take the role of a clandestine photographer snapping pictures of pedestrians to put up on the television screen. Every time you snap a photo, a caption is given in the form of a hashtag.

The photos you put up sew tension in the populace and ultimately create a conflict that results in the aforementioned bloodbath.

Learning Objectives

The game does not present any explicit learning objectives for players, but after playing the game several times, I feel the game aspires to influence players as follows:

1. Players will acknowledge the that news does not capture everything about a story
2. Players will be able to explain how the news escalates social conflict.
3. Players will reflect on how the themes of the game relate to their lives.

The game offers no real evaluation of player performance. There is no score, no timer, and no real winning, though the game does end. Playing the game through to the end does not guarantee that you will learn from the experience, but the simplicity of the message makes the game easily digested. The second listed goal is the most central and will likely be achieved by any player. Nearly every photo you take visibly upsets someone who then does something outlandish for you to take a photo of until “everyone hates everyone”. The first goal is more indirect and implicit. The photos taken are sometimes misleading. In addition, only negative photos and captions have any effect on character behavior. If you photograph a happy moment, the caption tells you to find something more interesting. This means that much of what happens in the game is not captured by the photographs and is therefore missing from the narrative. Players may or may not pick up on this theme, depending on their focus. Finally, the third goal aims to make the game more relevant by reminding the player of their participation in the cycle of news hype and escalating tensions. Like the first goal, this is not so core to the experience that every player is likely to engage in the desired reflection, but a number of game elements encourage this behavior.

Prior Knowledge

The violence in the game and mature themes mean that the game is inappropriate for small children. While I’m not an expert in developmental psychology, I would estimate that players should be at least 13. Players should know what news shows are, what cameras are, and be comfortable using a computer mouse.

Mechanics

The only action players can take is to aim the camera with the mouse and click to take a picture. Regardless of what the player does, characters bustle about the screen, bumping into each other, and shuffling around.

Things take a turn when a lone misanthrope appears onscreen, yelling at anyone he bumps into. When you take a picture of this grouch yelling at someone, it’s labeled “Crazed Square Attacks”

A circle-headed person sees this on screen and becomes fearful of all square-headed people. From here, you photograph progressively more hostile interactions between squares and circles, until everyone goes violently insane.

Another interesting mechanic is that the angry character that you caption “Crazed Square Attacks” actually returns on screen after the conflict has escalated in their absence. Initially, this character is still grumpy, but then a couple wearing heart hats bumps into the grouch, and gives them a hat. The grouch changes behavior completely independent of the player, and starts bouncing around the screen with cartoonish joy.

So the original source of tension, the grouch yelling at anyone they bumped into, actually becomes happy and stops being mean, but this doesn’t get told in the news story. If you try to take a picture of the now happy ex-grouch, you’re told that it isn’t newsworthy.

This bit of narrative helps to demonstrate that stories in the news won’t always give us a full picture of the situation, either because it was considered boring, or simply occurred off-camera. This could be missed by a player that is focused on other characters on screen, but the red hats and pink cheeks of the ex-grouch are some of the only color on the screen and the ex-grouch’s movement changes to skipping like motion that is noticably different from every other on screen character’s movement. These help to attract attention to the grouch’s redemption and drive home goal 1.

Finally, the game ends with a slow zoom-out displaying everything we’ve seen on a realistically rendered macbook.

While not everyone may take this away, I believe this ending is intended to remind us both that this rather jarring experience is only a game and that as consumers of media, we are involved in the hype cycles that run through our society. This helps to point players towards goal 3. By breaking the 4th wall and showing the game on a computer screen (probably often a similar screen to that on which the game is being played), we are given a chance to reflect on the game and how it might relate to our own experience.

Again, because the learning goals are not explicitly listed, and because there is no in-game assessment that attempts to evaluate what players have learned, and no feedback that is intended to help players take the “right” lessons away from the game, players are not guaranteed to achieve any of the learning goals. Still, the mechanics support learning by highlighting relevant events on screen with movement and color, by showing a conflict escalate as it is reported, and by breaking the 4th wall at the end of the game to encourage players to reflect on their experience.

Dynamics

I found myself trying to fight the inevitable. There are a number of cute characters and interactions, including the redeemed grouch, as well as some peaceful protesters, that I wanted to make news about. I kept finding myself taking pictures of pleasant things hoping to influence the news cycle to be more positive. Each time I was told that the positive images were boring and that I should “give the audience what they want.” This dynamic highlighted goal 1 by giving me a sense for how much is happening in the world that isn’t represented on news media. Eventually, I resigned myself to only taking photos of conflict.

Aesthetics

Due to the player’s limited degrees of freedom and powerlessness to steer the populace towards any outcome other than mass murder, I would describe the game as a hopeless death march. This doesn’t mean that the outlook the game leaves you with is entirely bleak, however. Though the happy events weren’t deemed news worthy by the invisible captioners, the feeling of powerlessness to deescalate social conflict filled me with the urge to be wholesome and empathetic. This feeling of powerlessness serves to remind us that what we see in media is only ever a slice of what is in the world, and that contrived narratives can make our situation look more dire than it really is. Thus the aesthetic supports learning goals 1 and 2 particularly well.

Learning Science Principles

Feedback: The broken hashtag and provocative captions encourage the player to capture more controversial events. This is essential for guiding the player to taking the polarizing photographs that drive the narrative. This helps the player learn how media can escalate conflict, and also how the way a story is presented can distort the broader truth.

Spatial Contiguity: When you take a photo, the entire screen becomes a zoomed-in shot of the picture you took. Then the screen zooms out again and you see the image you took on the tv screen in the middle of the game, and people watching the tv become affected by it. Keeping the image you took so close to the characters reacting to it, in combination with the game’s use of zoom and movement to focus the player’s attention, all work together to strengthen the player’s connection between the picture they took and the effect it has on the game’s characters. Casually linking the news stories to the rising tensions in the game is critical to goal 2; this feature supports that goal well.

Challenge: It’s interesting that there is virtually no challenge in this game, whatsoever. It boarders on being a visual novel, with relatively minimal interaction and very little player skill required. Despite this, the game is engaging. The appeal is found more in trying to observe what all the on-screen characters are doing, rather than trying to control or influence the outcomes. The characters are charming and there is enough action on-screen to keep you occupied trying to see how the characters are interacting, even though you don’t have much to do as the player. This helps to shift the player’s focus away from their own sphere of control and onto how the system of media delivery influences other people, facilitating goals 1 and 2.

Final Analysis

We Become What We Behold has minimal interaction, no challenge, and no assessment of what the player learns. Despite this, it is a striking thought piece that encourages you to consider how the way information is presented influences how people think and feel. The lesson is broadly applicable, and the game’s use of generic square and circle-headed people to represent arbitrary divisions between people helps to make the game feel relevant in considering varied polarized issues of identity from race to political affiliation.

The game doesn’t have explicitly written learning goals provided by the designer, nor does it measure player learning in any way. This makes it difficult to judge how effective it may be for influencing how people think about conflict and media in their daily lives. Still, the experience has stuck with me, and I think that the role of news in shaping conflict and my role as a citizen in the proliferation of that cycle will be on my mind for some time because of this game. In that regard, I consider We Become What We Behold a strong success.

CodeCombat is a puzzle game by an identically-named company designed to teach players to write code. The game was released in 2013 for the web, and continues ongoing development. You can play the game here.

Players choose their language of choice (python, javscript, or coffeescript) and use object-oriented commands to navigate their hero through mazes of traps and monsters. Players start with abilities like hero.moveRight(), and gain progressively more complex commands like hero.attack(), and hero.findNearestEnemy() as they progress. In so doing, players learn the basics of programming, from calling functions, to using arguments, to defining variables and writing loops. Each level has a view of the dungeon on the left and a text-editor on the right where you write the code that tells your hero what to do. Players can write code and execute it to see how their hero behaves, and then edit and re-run a new version to try to keep themselves from running headfirst into a bone-crushing ax.

Learning Objectives

The learning objectives are not listed in full in any particular list that I could find. Instead, levels are assigned keywords like “Arguments”, “Strings”, and “Reading the Docs” to describe the skills required to complete the level. This is further complicated by the fact that the game includes a number of worlds that cover a variety of domains including “Game Design” and “Web Development.”

Web and Game development are only available to paid subscribers, so I will limit my analysis to the first world, “Kithgard Dungeon”. Here is my take on the learning objectives involved:

1. Skill: Given a list of available methods, students will be able to be able to make function calls in a correct sequence to move their character through a maze.
2. Skill: Students will pass arguments to functions to move their character the correct distance, attack the correct enemies, and “say” (print) the correct words.
3. Skill: Students will use infinite while loops to repeat sequences of actions concisely.
4. Skill: Students will assign and reference variables to use as arguments in function calls.
5. Disposition: Students will desire to write elegant code

Students can be expected to improve at objectives 1-4 if they are progressing in the game, because levels will require these skills to succeed. In contrast, playing the game is not guaranteed to foster interest in writing elegant code, but the game does incentivize writing elegant code by encouraging you to use “fewer than X” lines of code in each level and by awarding additional points based on your program’s concision.

It’s notable that as written, skills 1 and 2 are limited in scope to in-game skill. I struggled to write these two learning objectives in a satisfactory way and I think it speaks to a general concern about the level of transfer aspired to by this game. To what extent will playing this game empower students to write their own programs? To what extent should it aspire to do so? It’s difficult to judge this just by playing it. The game provides a large amount of scaffolding that does not appear to fade. This makes it hard to evaluate how much skill can transfer outside of the game. For that reason, I’ve limited those first two objectives manipulations entirely within the game, as this aligns more explicitly with what the game measures in its assessment of player competence.

Prior Knowledge

Players are expected to have significant digital literacy before playing the game. They must be able to read, type, and navigate menus with a mouse. Otherwise, they do not need to know much. The basics of programming syntax and semantics required to play are addressed in the tutorial levels, and each new concept and ability comes with tutorial content explaining how and why to use it.

Mechanics

The core mechanics of typing code into the text box, running it, and checking its output against the expected criteria aligns nicely with goals 1-4. Students are required to leverage function calls, arguments, variables and infinite while loops in an appropriate sequence to complete each level. In this regard, students cannot progress without doing these things. Each level includes opt-in hints, in addition to tutorial information, that elucidate how to use the relevant commands at your disposal.

Notably, the hints never “bottom out” into revealing a full solution to the problem. This may however result in struggling students getting frustrated that they don’t understand how to proceed. It does however require that students create their own solutions, and thereby progress in the level’s targeted learning objectives, in order to proceed. The game also provides conveniences like auto-completion and syntax and semantic error catching (e.g. missing quotes or referencing unassigned variables).

These scaffolds mirror the tools included in modern code-editors like VS Code and Sublime Text. Thus these features bring the core game loop closer to the idealized transfer tasks of writing one’s own program and at minimum, shouldn’t detract from the specified learning goals.

So what about goal 5? Do any of the mechanics support fostering interest in writing elegant code? Most levels include some restriction on the number of lines of code allowed to solve the problem. Additionally, many levels additionally offer extra rewards for writing concise code. While this does not guarantee influencing students’ dispositions, it does seem likely that these incentives might succeed in encouraging students to value concision in their code.

Dynamics

There are no penalties for running incorrect code. It can be difficult to determine exactly what your character will do in advance of running the code, in large part because there are minimal visual cues representing how far apart different places on the map are. You can tell your character to .moveRight() twice in a row, but how far will she go each time? This can be frustrating, but this frustration is somewhat mitigated by the ability to edit and re-run your program without penalty. Thus the game encourages a trial-and-error or guess-and-check approach. If you are not sure what will work, try running a partial solution, and seeing what goes right and what doesn’t. Then you can adjust your program and try again. While it may not be a programming best-practice to start writing code without premeditating your plan with some diagrams and/or psuedo code, this dynamic does encourage students to iterate in the face of failure.

Aesthetics

The gap between what you predict your commands to do and what they will actually do creates a feeling of separation between yourself and the character. Thus the game feels like rather than directly moving your character, you instructing the character on how to navigate the dungeon, and hoping that your instructions are enough. Despite your best intentions, the hapless hero has an affinity for walking blindly into danger. Thus the overall feel is one of protecting a helpless idiot from danger by giving them extremely thorough directions. The lack of penalty for executing incorrect solution makes running an incomplete program (which dooms our poor hero to certain death) an inexpensive way to check how close your answer is to a correct solution. This makes the hero’s life heavily expendable. I would describe the resultant aesthetic as refining grist for the mill. You iteratively develop the instructions you provide your hero/lemming while continuously sending them headlong into peril, until finally arriving at a program that naviagates the hero safely through the gauntlet.

This aesthetic encourages students to engage in trial-and-error, and to perservere in the face of failure, which seem to serve all 5 of the above learning objectives. The aesthetic does somewhat undervalue planning in advance, which may not be optimal. Still, the game heavily encourages learners to revise and seamlessly retry their solutions, which faciliates growth towards all the game’s learning objectives.

Learning Science

Timely Feedback: Players receive three key kinds of feedback to help them navigate each level: explicit syntax corrections, explicit semantic corrections, and the hero’s performance. The first two mimic a text editor to alert the player of certain specific kinds of errors (like missing quotes or referencing unassigned variables). The hero’s performance offers implcit feedback: the player can observe whether the hero moved in the right path, attacked the right enemies, spoke the right password, etc. All of this information collectively empowers learners to debug incorrect solutions and arrive at a program that meets the level’s requirements.

Segmentation: The sequence of levels is designed to introduce concepts gradually, starting with the basics of syntax and growing progressively more complex as players move through the game. When a new concept is introduced, it is done explicitly and in relative isolation. Players are given a new item to equip that gives them a new method to use and are put in a level that will require use of the new technique and little else. Then players build up to using the technique in combination with previously learned techniques in later levels. This segmentation and sequencing of the content helps to reduce the cognitive load and thereby make the learning easier.

Modality: None of the key information is presented auditorily. All the sound is background music, sound effects, or silly sound bytes like, “For the win!”. This may mean that an undue burden is placed on learners’ visual systems, wasting their auditory cognitive capacity. The value of the visual presentation of information is that it mimicks the authentic experience of using documentation and your text editor to figure out what to write, and that the visuals can stay constantly present on-screen for checking and re-checking against your code. It might be better to present some hints and scaffolding in auditorily, as this might be useful for highlighting sailient details acutely without requiring students’ continued attention.

Transfer: It is an open and critical question how well this game prepares learners to write programs outside of the game context. All the function calls used in the game are entirely specific to the game context and have no meaning outside it. But calling pre-defined functions, and giving them the correct arguments to achieve your desired end, are indeed skills that programmers must be able to do. Likewise, while loops and variables serve similar purposes in and out of the game. This suggests that the skills learned in the game will likely transfer to outside of the game, but those skills may be insufficient to empower learners to write programs on their own, without learning more about what functions are natively available in their chosen programming language, and perhaps additionally without some coaching on what kinds of problems programming can be used to solve. We might for example expect that a learner playing this game would be able to call the print() function in python to print a variable of interest in their console, but only after being told that the print function exists and that it works similarly to the hero.say() method they have already used.

Synthesis

Overall, CodeCombat appears to foster learning of its desired objectives. The skill goals (labeled 1-4 above) are explicitly required of the player to proceed through the game, and the dispositional goal of desiring to write elegant code is implicitly encouraged by rewarding players for writing concise code. The mechanics provide rich feedback and segment and sequence the content into manageable chunks. The dynamics and aesthetics work together to encourage players to iterate again and again until they arrive at an acceptable solution.

The biggest open question remains, “What can successful players now go out and do?” Since the game never involves writing code to achieve a purpose that directly aligns with a typical programming task, it is unreasonable to assume that learners will thus learn to write rich programs just by playing the game. But the skills they learn by playing will be directly applicable in authentic programming contexts. So perhaps the reasonable conclusion is that playing this game will prepare learners to learn to code more quickly by giving them core skills that they will need when they try to write programs of their own.

Number Munchers is a DOS game developed by Minnesota Educational Computing Consortium (MECC) in the 80’s to teach elementary schoolers to identify factors and multiples, as well as to evaluate algebraic expressions to make equality/inequality comparisons. You can play the game here. Players move around a 2D grid, munching the numbers that meet the level’s criterion, while avoiding the “Troggles” (monsters) wandering the grid. You must munch every number (or expression) that matches the level’s requirement to beat the level, and you lose a life if you either munch a wrong number, or run into a Troggle. Levels are untimed, so as long as you avoid the Troggles, accuracy matters more than speed. Before starting the game, you choose a mode: Multiples, Factors, Primes, Equality, Inequality, or Challenge. In Multiples and Factors, each level will display a condition like “Multiples of 5”, or “Factors of 20”. In Primes, every level has the same condition of munching only prime numbers.

Equality levels have conditions like “Equals 10”, where each square on the grid has an algebraic expression like “5+5”, instead of a single number. The Inequality levels are similar, except the prompts will look like “Not equal to 5”, “Greater than 10”, or “Less than 16”. In Challenge mode, every level is a random mode.

Learning Objectives

1. Students will be able to identify multiples of 2-10
2. Students will be able to identify factors of 2-20
   1. Auxiliary goal: Students will recognize that some numbers are only divisible by 1 and themselves
3. Students will be able to identify prime numbers < 40
4. Students will be able to evaluate two term/factor expressions of numbers < 40
5. Given a two term/factor expression and a number for comparison, students will be able to determine whether the number equals the expression and if not, which is bigger.

Students playing a given mode can be expected to improve in the corresponding objective. So students playing “Multiples” mode will likely get better at answering the question, “Is X a multiple of Y?”, where X < 40 and Y < 10. Similarly, students are likely to improve their accuracy at performing addition, subtraction, multiplication, and division, depending on the mode and their strategy (multiplication is used in every mode, division is helpful in every mode, but can sometimes be re-framed as multiplication, addition and subtraction are only practiced in Equality, Inequality, and Challenge modes. It is reasonable to suppose that these improvements to arithmetic fluency and to divisibility judgements would transfer outside of the game to either paper tests, or even real-world scenarios like money handling where the need for arithmetic might organically arise. This is because the kind of in-your-head quick thinking required to munch the correct numbers mirrors the way we do such simple arithmetic problems in our heads outside of the game. Paper tests are the most similar to the in-game task insofar as the way the expressions are presented in-game looks like how analogous questions could be asked on a paper test. Every level could be cleanly mapped onto a series of questions about whether any of the following expressions fit the level’s pattern. So students playing “Multiples mode” will likely improve their ability to answer questions like “Is 12 a multiple of 3?”, or more broadly, “Which of the following numbers are multiples of 3?”.

Notably, where memory is concerned, the game is more about recognition than recall; students using a memorization strategy (like memorizing the multiplication tables) usually need only to decide whether a given answer fits the description; they do not need to produce their own answers. This means students playing the game may not see less improvement in their ability to answer the question, “Name 10 multiples of 3”, than their ability to identify 10 multiples of 3 from a bank of potential answers. The Equality and Inequality modes are exceptions to this, as students need to simplify expressions to compare them to the level’s requirement. Additionally, students may use arithmetic strategies to identify numbers to munch, and this could improve their recall and arithmetic fluency even on the simpler levels.

Prior Knowledge

Players must be able to read numbers, and be able to perform addition, subtraction, multiplication, and division of a one-digit number with a two-digit number. For example, in Multiples mode, if the goal is to find “Multiples of 5”, players should be able to multiply 5*3, or divide 15/3 or 15/3 to confirm that 15 is indeed a multiple of 5. Additionally, it they should understand that a prime number means a number whose only factors are 1 and itself. This way, when playing Primes mode, they can check whether 17 is a prime, using the fact that primes are only divisible by 1 and themselves, by seeing whether figuring out whether 2, 3, 4, etc. go into 17. Players must additionally have sufficient computer literacy to navigate their character with the arrow keys (or WASD) and use space to munch.

That might be bullshit, though. All of the modes can be approached with a variety of strategies that have varying requirements for prerequisite knowledge. Take #2: identification of prime numbers. You don’t strictly need to know what a prime number is to be able to recognize one. The game gives you correctness feedback every time you munch. It is possible to figure out which numbers you can munch in Primes mode by brute force and memorization, in which case you wouldn’t need to know what a prime is going into the game. You might start to figure it out as you played however.

Similarly, for Factors mode, it’s easy to say that you need division to identify which numbers are factors of a given number, but students could instead approach the problem as multiplication by thinking something like “3*5=15, so 3 is a factor of 5; munch!” These factors muddy identifying exactly what prior knowledge is necessary to learn from the game, and the issue is further complicated by the fact that each learning objective can be independently pursued by sticking to a given mode. TL;DR; the above skills should be enough, but you may not need all of them, depending on which learning objectives you’re pursuing and which approaches you use.

Mechanics

You move around with the arrow keys, and hit spacebar to munch a number or expression. You gain points when you munch correctly, and you beat the level if you munch every correct number or expression. You lose a life (1 of 4) if you munch a wrong number/expression, or if you run into a Troggle. Each Troggle type has a different movement pattern which stays the same throughout the game. Squares on the grid will randomly become safe zones that vaporize Troggles. Every 3 levels, gameplay is interrupted by a goofy Road Runner style cutscene, where a Troggle tries and cartoonishly fails to hit the number muncher with a rock, dynamite, etc.

One interesting consideration is that Factors mode contains a number of levels where you need to find all the factors of a prime number, without telling you that there is anything special about these numbers, or calling them prime. Something like 3 out of the first 10 levels in Factors mode will ask you to find all the factors of a prime, where the only munchable numbers will be 1 and the given prime. This seems to attempt to implicitly build students’ intuition about what a prime number is, without naming it. It is reminiscent of Zombie Division in this regard (Zombie Division also teaches students to make divisibility judgements and presents primes without explicitly naming the concept). The Primes mode does offer explicit feedback for identifying why numbers are not prime, though it never defines exactly what a prime is:

---

Dynamics

The Troggles are not very threatening, and there is no time pressure, so generally the game goes as quickly as the player chooses to move. You can move in a deliberate grid, getting every answer in a given row, column, etc., or you can erratically jump around munching any number that you spot as correct. Beyond the order in which you munch, there is no prescribed strategy for how to decide whether a given number is munchable. The relationships tested in the game can generally be recognized from a number of angles (like using multiplication or division), and the game doesn’t differentiate between these thought processes at all. This freedom to do the task in a way that suites the player focuses the core experience around the identification of numbers and expressions that match the given pattern, which is well aligned to the game’s goals.

Aesthetics

The inclusion of the enemies and randomness with which they and the safe spaces appear, makes the game feel somewhat frantic, even though you could play quite slowly without penalty. Often you are left with the sense that you must have gotten all the numbers already, how could you have missed one?! This makes the game feel like a bit like a scramble to search the whole grid for the one thing you missed while making sure not to bump into any enemies. I’d call the aesthetic a scrambling treasure hunt. The treasure hunting feeling (finding the right numbers/expressions) definitely supports the core learning objectives of pattern recognition.

It’s unclear whether the frantic scrambling supports learning, however. It probably decreases accuracy, but it does boost engagement. The game would not be fun without being pursued by the enemies, because it would be too easy. So in this sense, the frantic feeling may support learning simply by encouraging learners to play.

Learning Science Principles

Timely feedback: Players receive immediate, just-in-time feedback on every munch. Either it is correct, and they get points, uninterrupted, or it is incorrect, and they receive an error message explaining their mistake (this pauses the game). This supports learning by allowing students to iterate quickly. It explains their mistakes and confirms their correct actions so they know what went right and what to improve.

 Segmentation: The silly cutscenes break the game’s pace, allowing you to rest and laugh in the face of the foolish Troggles. I’m not confident in this point, but I think this segmentation bolsters learning by decreasing the cognitive load, and allowing learners a break when they need it.

Fading Scaffolding (by increasing degrees of freedom): The levels increase in complexity over time by presenting more complex expressions or larger numbers to work with. This furthers the students learning by increasing the cognitive load required of them once they have mastered lower levels.

Final Analysis

Number munchers works well, as an engaging pastime and an educational tool. Each mode focuses on a single learning objective, and these objectives are well-aligned to the core mechanics of identifying expressions that match the level’s requirement. Excluding a timer in favor of enemies adds tension to support engagement while avoiding prioritizing speed over accuracy. The aesthetics serve to incentivize meeting the learning objectives by making finding the correct expressions feel like a treasure hunt, and by using a frantic flight from enemies to create tension that drives engagement. The relatively narrow focus of the learning objectives facilitates a tight delivery that targets growth very well.

The biggest ambiguity about the game’s effectiveness centers around the multitude of approaches that can be brought to bear in a given mode (flexibility in the dynamics). Students may or may not need to use and improve their arithmetic fluency to succeed on the simple modes of Multiples, Factors, and Primes, as these tasks can largely be completed with recognition. However even the recognition strategy requires students to improve their ability to identify Multiples, Factors, and Primes, and in this sense, the game succeeds in teaching its learning objectives so long as a player persists in playing. The more advanced objectives of arithmetic fluency are indeed fostered by the more difficult modes, which can’t be approached with pure recognition. These fluency objectives can even be developed on the easier modes, depending on the player’s strategy. Number Munchers provides a robust and engaging learning experience that has stood the test of time.

Just about everyone has enjoyed playing a game at some point. This is a site about games that aspire to more than fun. Games that try to help the player grow. Transformational Games! This includes games that teach things, and games that make you think about yourself and your life.