UC San Diego

Games for teaching coding have been an educational holy grail since at least the early 1980s. Yet for decades, with games more popular than ever and with the need to teach kids coding having been well-recognized, no blockbuster coding games have arisen (see Chapter 2). Over the years, the research community has made various games for teaching computer science: a survey made by shows that most do not teach coding, and of the ones that do teach coding, most are research prototypes (not production-ready) and difficult to even install. In analysing the list, we found that some were no longer available, of none were blockbusters (see Chapter 2). With decades of unimpressive performance behind us, it is time to take a critical look at the field and ask some key questions: What is a coding game? Why are there no blockbuster coding games? What design guidelines can make it easier to create coding games? How can we categorize past and future work on coding games into a productive taxonomy? What (if anything) makes coding games difficult to produce? What (if anything) makes them difficult to play? What can/should a ``good'' coding game seek to accomplish? And how can/should we evaluate that?

This thesis begins by articulating a design space consisting of 3 types of coding games. The chapters of this thesis examine those three types in the context of systems we built:

* Direct embedding -- ``coding in a game". Chapter 3 looks at CodeSpells, a game in which the player plays the part of a wizard and writes magic spells with code. The coding interface is embedded in the 3D game. CodeSpells is significant because it introduces a novel set of metaphors (magic, wizards, spells, etc.) that correlate neatly with ideas within the pedagogical domain of coding. As an individual system, it is novel because it is the first fantasy-themed coding game (that we know of); as a more general contribution, it is novel because it validates that fantasy-themed coding games can provide an alternative to the more traditional sci-fi themed coding games.

* A programming language that is a game -- ``coding as a game". Chapter 4 looks at The Orb Game where a visual programming language is defined as a set of game mechanics, making the process of coding into the process of (seemingly) playing a game. The coding interface is presented as a game. The Orb Game is significant because it is the first system that has been proven to allow players to write code without realizing that they are doing so -- essentially ``tricking'' them into thinking they are just playing a game. It is more generally significant because it introduces a novel technique called Programming by Gaming, which can be used to design other Turing-complete programming environments that appear to be games.

* A modding environment integrated with a game -- ``coding for a game". Chapter 5 looks at a modding environment integrated with the blockbuster game of Minecraft. The coding interface allows the user to code for the game. It is significant because it allows players to learn to code in the context of a blockbuster game, resulting in higher recruitment numbers than state of the art coding systems like Scratch. More generally, it proves that loosely-coupled, seamful games may be viable alternatives to the more orthodox style of seamlessly integrated games.

This thesis explores this design space and evaluates the three sub-genres above by looking at real systems we built and evaluated. We also discuss our systems in relation to ``adjacent'' systems in the same design space. This analysis, in turn, yields design guidelines that we flesh out in Chapter 6, our concluding chapter.