Programming games: who are they for?
I am a programmer at heart, which is a good thing because otherwise my manager made a serious error in hiring me for a software development position. You would think that after a day in the code mines, drilling to extract the unrefined algorithms to be cut and polished for production, that the last thing I’d want to do when I get home is to write more code. To be fair, you’d be right some of the time. Other times I work on one of my pet projects or, bringing us around to the topic for today, I jump into a game that lets me exercise those skills.
Programming games are something that you might not realise exist, but once you know about them it’s surprising how many you can find. In some ways they offer a more structured programming experience compared to a software development job. They’re usually a lot less open-ended: you have a defined task to complete with defined (absolute) restrictions, you often have an objective means of scoring your solution, and you know that a solution is possible. Quite often you don’t get these things in the real world. The games also don’t have customers breathing down your neck because they were using an undocumented API and you dared to change it and now their entire system is broken and when can you release a hotfix so they… [*deep breath*] sorry, I got a little carried away there. What I’m trying to say is that these games are to real software development what Farming Simulator is to real farm work: you can have the fun of sowing, tending, and harvesting crops, but without coming home coated in mud. Or worse.
Types of programming game
Before we go any further it would be good to establish a rough categorisation of the games. I’m going to approach this as simply as possible—how much programming does the game make you do?
Programming as the primary gameplay mechanic
These are games were your main or only interaction with the game is in terms of writing code. This doesn’t include, for example, games where you have a world that you walk around in, even if writing code is frequently required in order to progress.
Two of the most well known recent games in this category are TIS-100 and SHENZHEN I/O by Zachtronics, released in 2015 and 2016 respectively. TIS-100 has you writing code for a fictional parallel processing system in order to repair it. The cores are arranged on a grid and you write code in a form of assembly language, with the ability to directly pass values between adjacent cores. SHENZHEN I/O, on the other hand, has you building circuits and writing code for any microprocessor parts you use within them. This is a game that fully expects you to read (fictional) component datasheets.
MHRD is a game that straddles the line between programming and electronics. It tasks you with creating increasingly complex logic circuits from first principles, starting with only a NAND gate available and working your way up to a basic processor. Other than the NAND gate design that you start with, everything else that you combine together is created by you within the game. You create the “circuits” by writing code that specifies how parts should be wired together. If you’ve programmed FPGAs then this is likely to feel similar to working with a hardware description language.
Gladiabots and Screeps are more competitive games where you program bots to collect resources and fight bots controlled by opponents. In Screeps you do this via Javascript, which is a divergence from most other programming games in that it is a real language that is widely used outside of the game. In Gladiabots, on the other hand, you use flowcharts to define your bots’ actions.
Finally, Human Resource Machine and Lightbot both have the player assemble programs from blocks. In the case of Human Resource Machine the goal is to move boxes from an input conveyor to an output one in the correct sequence, along with manipulation of the box contents. In Lightbot you are programming a robot to navigate a simple grid-based 3D world.
Programming as an additional required gameplay mechanic
These are games that provide you with a world to play in but which require coding in order to progress within the game. I have limited experience personally with these games compared to the other two categories.
My lack of direct experience aside, there are a number of examples of this that are relatively well-known within the indie games community. Quadrilateral Cowboy is one, where you play a hacker facilitating espionage/infiltration missions by overriding cameras and doors and programming a small “rover” to scout and collect objects. The interaction in Quadrilateral Cowboy is more akin to terminal commands than actual code. Duskers has you exploring derelict ships via the use of remote drones, similarly providing you with a command line interface to control them. The Magic Circle and Hack ’n’ Slash, on the other hand, provide a different style of gameplay wherein you directly manipulate in-game objects and creatures in order to progress.
Programming as an additional optional gameplay mechanic
There are a large number of games where programming is included, or modded, as an optional gameplay mechanic. The two that will possibly come to mind first are Minecraft and Kerbal Space Program. While Minecraft includes redstone circuitry in the base game, mods such as ProjectRed and ComputerCraft have significantly expanded on this and also added computer blocks that can be programmed. KSP has the kOS mod, which allows the player to write programs to execute on their ships for automated control, which is particularly interesting when paired with the RemoteTech mod which prevents player control of ships when they are out of communications range.
Player experiences
Now that we know what types of programming game exist and have identified a few in each category we come to the question of who plays them and why. As I mentioned at the start of this article, I enjoy technical challenges both at work and at home. To get an idea of other people’s experiences with programming games, I spoke to Paul Fenwick and Marcel van de Steeg. Paul is the creator of KSP-CKAN, a comprehensive mod management system for Kerbal Space Program, and regularly delivers talks on the intersections between automation, technology, and psychology. Marcel is a software developer with a side of game development and often takes part in game jams.
Paul’s first meaningful exposure to the idea of programming within a game was AnimeMuck, a text-based multi-user dungeon style game primarily focused on building. It allows users to create programs in MPI or Multi-User Forth in order to create more interactive areas. As well as the intended uses of the user programs it was possible to exploit them to do sneaky things like using the privileges of another user to view their inventory. Since then he has played a variety of programming based games, including several of the ones mentioned previously.
Something Paul enjoys doing is taking a non-programming game and introducing a programming element to it. An example is playing KSP with the RemoteTech and kOS mods, allowing him to write scripts within the game to perform automated actions when ships are out of communication. He has also written external helper programs for games like Puzzle Pirates and Everquest. Paul also enjoys production line style games such as Factorio when they allow physical metaphors for code, particularly issues such as extensible design, large-scale architecture, and the idea of incurring technical debt for quick solutions.
When I talked to Marcel, the subject was actually his daughter’s experience with coding. She had the chance to play Lightbot a couple of years ago when she was 6 years old. At the time she had no prior programming experience, but when her dad picked up Lightbot from the Hour of Code website she decided she wanted to have a go at it herself. While the game didn’t make her into a professional coder overnight, Marcel feels that it established the concept of combining structured blocks of instructions together to achieve a goal. Since then she has been programming using Scratch, has taken part in the Hour of Code several times, and has programmed a Sphero BB-8 robot to dance. Marcel also recommended Lightbot to his manager, who has older children, and tells me that they enjoyed and learned from it as well.
Use in education
Clearly there are two directions from which people approach programming games: as someone who enjoys solving technical problems or as someone who wants to learn the basic techniques for how to do so. These games are fun to the right people and can spark an interest in people who don’t already consider themselves programmers, but are they educational? On the other side of that coin, is this an intention the developers have for their games?
Paul believes that the main draw of programming games is that they are aimed at being fun rather than educational. In being fun, though, they can raise people’s interest in programming. Children in particular might want to learn more after playing them. The developers of both KSP and Minecraft have released education-targeted editions of the games to capitalise on this introduction of concepts to children through games. However, an important consideration is that this balance can be delicate. An activity, no matter how fun it might otherwise seem, can quickly feel like a chore if it is presented as mandatory. As mentioned previously in relation to Marcel’s daughter, she made the choice to play Lightbot herself and that opened the gate to other related interests. Marcel feels that if she’d have been sat down and told to play the game then the outcome may have been quite different. Even when learning isn’t forced there can be a certain element of luck, as Marcel described to me:
A colleague had a wonderful story about this. He bought a Raspberry Pi kit with robot and electronic components. Came with a big book of exercises and projects and all that. He had a tinker with it and showed it to his kids, hoping they would be interested. Not interested at all. So, very disappointed, he put it all back in the box and put it aside. A year or so later his son attends a presentation on Internet of Things, comes home, digs out the box and proceeds to do all the exercises and projects. Dad was stoked of course. Sometimes it’s all about timing.
In my experience, and an observation shared by Paul, the moment that learners really start to take interest in programming is when physical interaction is added. Being able to press physical buttons to affect the execution of code or have the code control physical indicators can be a turning point. For an example of this, you don’t have to look much further than the enthusiastic response to projects such as physical KSP control panels or games created specifically to be played with unusual physical interfaces.
As mentioned previously, Zachtronics is a game development studio with a history of releasing programming related games including TIS-100 and SHENZHEN I/O. While both of those games involve writing code and SHENZHEN I/O also involves creating circuits, developer Zachary “Zach” Barth says that the games are not intended to be explicitly educational nor to teach the skills in question. Instead the games are designed to be self-contained experiences, with existing skills simply allowing the player to more quickly pick up the core concepts. This contrasts with Screeps for example, which requires the player to write JavaScript code and ideally for them to invest time in learning to program outside of the game. Going further than this, Code Combat have developed a commercial (though open source) product explicitly targeted at teaching programming skills in which the player writes code to interact with units in a strategy game.
So, bringing us back around to the original question, are programming games suitable for an educational context? As with many questions involving human experiences, there is unlikely to be a single answer that applies to all people. However, bringing the right person together with the right game can almost certainly kick-start an interest that can last years or even a lifetime.
Expanding on current features
While talking to Paul about his experience with programming games it became clear he had strong opinions on what he would like to see in this type of game in the future. Foremost among these is the integration of some form of source control, providing commits or checkpoints and the ability to roll back to previous versions of your code, compare differences, and so on. Source control is important when developing any non-trivial software in the real world, so having games reinforce the concepts in an accessible way could provide a major advantage to the player. Continuing the theme of real world programming concepts, Paul would also like to see unit testing integrated into games such as TIS-100 or SHENZHEN I/O, allowing each part of a design to be independently tested with specific inputs and outputs. Another useful feature is an easy way to share solutions. Factorio, for example, allows blueprints to be exported as strings for this purpose. Alternately, game data could be encoded into an image such as a screenshot or diagram, allowing the recipient an idea of what they’re about to load.
Wrapping up Hopefully I’ve given you an idea of what kinds of programming game are available, what you can expect from them, and who they’re targeted at. For the right person they can provide endless hours of fun problem solving. If you’ve never played one of these games but are now interested then the ones I’ve mentioned here are a good starting point. If you have a favourite game in this genre or an interesting story about your experience with them then I’d love to hear about it in the comments.
I am a software developer by day and dip into a range of related activities in my spare time, including working on my own software projects, writing, proof-reading, and, of course, gaming of both the digital and boardgame varieties. I am slowly starting to sink my teeth into game development.