Teaching Programming with Games

For two years in college, I worked on games to teach programming, particularly on a project named Reduct. Other than the paper¹, there’s little information on it, and I’ve never managed to satisfactorily explain what we did. So first, here’s some context on the problem we faced.

Building educational games is like trying to dress up vegetables for a child: done poorly, they’re a thin facade of “fun” on top of the same old boring lessons; done properly, they’re entertaining in their own right, and the learning becomes invisible. Games that are first and foremost educational are the equivalent of cutting steamed vegetables into star shapes—an educational game needs to be a game still, and designing games is something even game studios can struggle with.

Designers struggle to strike this balance: DragonBox, arguably one of the most successful in this space, didn’t actually demonstrate that students learned anything in studies². Zachtronics games like SpaceChem or TIS-100, as well as programming-inspired games like Human Resource Machine, are essentially puzzle games; you wouldn’t use them to pick up programming itself, even if you might gain some programmatic thought. To be fair, all these games here do an incredible job of making math and programming concepts fun and accessible, whether they consciously try to be educational or not.

Even further down the spectrum, games like Minecraft or Factorio often manage to teach programming almost on accident; people feel compelled to build complicated redstone contraptions because they can. You get sucked in because these games offer programming as an opportunity to make your life in the game easier. To be fair, Factorio is designed entirely around automation. I feel this is really an unexplored avenue: how many developers of today got their start chaining triggers in StarEdit (below)? (I know that influenced me for sure.) A friend of mine got drawn into programming by setting up Perl scripts to automate MMOs. And of course, there’s the stereotype of the student who enters a computer science program because they wanted to make video games. But again, perhaps these games just happen to hit the right buttons for people who might already be amenable to programming; they simply reach far more people than formal CS education ever could, by nature of being games.

Of course, no discussion about teaching programming can fail to mention Scratch—especially as Reduct derives from and improves on its concepts. MIT’s creation is wildly successful; programs like Hour of Code and Code.org use it to introduce programming, and schools around the country teach it to students of all ages. The core idea here is simple: code can be represented as blocks, snapped together much like Legos. To make programming more visible, more meaningful, Scratch pairs these code blocks with a “stage”, allowing your code to move around sprites, play sounds, and respond to input—the worlds easiest game engine. Arm students with a palette of blocks and a library of graphics, and they can build some fairly impressive applications.

What I worked on is neither so sneaky as Minecraft nor primarily a game; Reduct, at least as it stands, is first and foremost a teaching tool, and its design reflects that. Designing games is hard. Obviously, we still wanted Reduct to be fun in its own right, and so in some sense, it’s also “just a puzzle game”. Hopefully, we’ll see the project expanded and made widely available someday.

Next time, we’ll tour the design of the game itself.