Can Videogames Teach You Programming?

if(desire_to_program > 10)
    continue;
else
    return;

When I tell people I'm a programmer, I get that look. The glazed eyes, the polite smile, the clear desire to change topic. If I'm lucky, I'll get pitched on an idea for the next killer mobile app that my conversation partner insists will make us rich; if I'm less lucky, I'll get wrangled into providing free tech support for the rest of my life. The thing is, though, as impossible as it might sound, programming can be more fun than people realise. Fun enough to warrant its own video game genre, even.

Just how educational are these games, though? Is it really possible to become a programmer by playing games? I dug through Steam and came away with three promising candidates. Let's take a look at them, and see whether they can really teach you skills to pay the bills.

Obviously few games are going to teach you how to write C# code, but these programming games translate the concepts of programming into visual metaphors and achievable puzzles. We're going to therefore review each game in terms of the programming concepts it introduces and how well it teaches those concepts in a manner that would carry over should you start to learn a programming language later. We're also going to run through these games in ascending order of conceptual complexity, so that they might form a complete course towards programming.

It should also be stressed, before we begin, that none of these games claim that they will teach you to code; we just think that they might. Onwards!

Human Resource Machine

Difficulty: Beginner - Intermediate

Human Resource Machine is all about data processing. A conveyor belt marked 'IN' delivers tiles with numbers and letters printed on them, and it is your job to send the right ones - as defined by each puzzle - to the conveyor belt marked 'OUT'. To do this, you put together a list of commands for your eager worker to follow - a program, essentially. Since the tiles rolling in are randomised, your program has to account for all possible combinations of numbers and letters. This is a concern all programmers are intimately familiar with.

HRM does a great job of introducing concepts in an approachable way, giving you time to familiarise yourself with each new command before moving onto the next one. Even better, you can slow down time as your worker performs your program, stepping through each command so you can see exactly where and why it isn't working the way you expected. Given how much time a programmer spends debugging, getting used to breaking down a program line by line is incredibly useful.

Accessibility, though, is only part of the programming equation. The critical question is: can playing HRM teach you how to program? To answer that, let's dig a little deeper into the concepts powering HRM's puzzles.

Concept: Basic Variables

What are they?

Dealing with unknown data, whether it be a conveyor belt of random numbers and letters or the light-speed keyboard commands of a StarCraft pro, is a fundamental component of virtually every program ever written. Because programs can't predict the future - yet, anyway - they need a generic placeholder for storing and referring to unknown data during their execution. This is where variables come in. A variable is basically a labelled container for data that can be emptied and refilled as needed.

How is it taught?

In HRM, floor tiles serve as a surrogate for variables. At the centre of each puzzle room, the floor is divided into a numbered grid where you can temporarily store the numbers and letters coming in on the conveyor belt. In your list of commands, you refer to these tiles by their numerical labels - starting at 0, because in programming counting always begins at 0, not 1. Alternatively, you can give them your own labels like 'FirstAdder' or 'Tally' to help make your program easier to understand. This is a crucial technique in programming, especially if multiple people are working on the same code. Well-named variables can be the difference between diagnosing your misbehaving program straight away, and spending hours just trying to remember what the heck your code is doing.

Concept: Arrays

What are they?

Where variables are used for referencing a single value or object, arrays are used when you need to group a whole bunch of similar objects together. Instead of needing a separate variable for each slot in a player's inventory, for example, a game might have a single 'inventory' array within which all inventory items are stored. The benefit to this approach is that those items can be referenced in relation to the 'inventory' object like so: inventory[0], inventory[1], inventory[2]... This makes it very easy to write code that checks all slots in a player's inventory, and in terms of raw performance, arrays are a lot faster than individual variables.

How is it taught?

HRM pulls no punches with its implementation of arrays. Instead of referencing floor tiles directly through their labels, you can use the value inside one tile as the label pointing to another. For example, Tile '0' might have the number 7 inside it. If you use the standard copyfrom '0' command on it, you'll get that 7 back. If instead you use the copyfrom [0] command, the program will use the 7 as another label and retrieve the value inside Tile 7. Don't worry too much if that sounds a little confusing; you really need to see arrays in action to understand how they work. Importantly, HRM lets you do that with a number of well-paced puzzles.

Concept: Conditional Statements (aka IF…THEN statements)

What are they?

A program wouldn't be much use if it produced the exact same output every time, regardless of the data you fed into it. That would be like a game that literally played itself, ignoring all player input and looping the same run-through again and again. Programs need to make decisions, whether they be as simple as deciding which of two numbers is bigger, or determining if a player's crossbow bolt will hit its target or not. Conditional statements are the real brains of a program, the artificial equivalent of our neocortex.

How is it taught?

To keep things simple, HRM includes only two types of conditional statements: jump if zero, and jump if negative. These commands check the value in your worker's hands and 'jump' to another part of your program if the condition is true. If your worker is holding -5, the jump-if-negative command will resolve as true and follow the jump arrow to the part of the program you pointed it at. If your worker is holding 1 instead, the program will continue as normal onto the next command in line. This may seem pretty simple, but later puzzles require a bunch of jump-if commands all working together, their jump arrows crisscrossing like a football play devised by the devil himself.

Concept: Iteration (aka Looping)

What is it?

Repetition is the bread and butter of computing. We write programs to automate the tasks we don't have time to do ourselves, and for that we use loops. Loops herd NPCs back and forth along the same patrol route. Loops hit enemies with burning damage for every second they're aflame. Loops keep a car accelerating until it reaches its top speed. Hand-coding each iteration of these processes would be woefully inefficient, and when it comes to programming, inefficiency is a sin.

How is it taught?

HRM combines the aforementioned conditional statements with the standard jump command to convey the basics of looping. There are two main types of loops, for loops and while loops, and HRM teaches both. For loops, which perform a set of commands a predetermined number of times, are implemented using one floor tiles as a counter that ticks down until it satisfies the jump-if-zero check and 'breaks' out of the loop. While loops function much the same way, except instead of looping a set number of times, they keep repeating while a certain condition is true. As the puzzles get tougher, you need to combine both types of loops with the array tiles to process lists of data of unknown length. This is a another cornerstone of basic programming, and HRM does a good job of gradually building you up to it.

Verdict:

By framing itself in familiar concepts like conveyor belts and floor tiles, and by offering only a small list of commands to work with, Human Resource Machine serves as a solid introduction to the core principles of programming. Colour-coded commands and helpful jump arrows echo the language of flow charts, making it easier to keep track of what a program is doing as it executes. The bespoke terminology like copyfrom and bump might not translate 1:1 to modern programming languages, but the concepts they teach are one and the same. After conquering HRM, you would be well-equipped to start learning how to code for real.

On page two, we look at Double Fine's Hack 'n' Slash.

Hack 'n' Slash

Difficulty: Intermediate - Advanced

Maybe, though, you want to prep a little more before plunging into the world of programming. This is where Hack 'n' Slash comes into play. At first glance, it seems like a typical Zelda-style action-adventure game, but instead of cutting down enemies you 'hack' them, using your sword-cum-USB-stick to reprogram their behaviour. Nearly all objects in the world can be reprogrammed this way, to the point where you can actually cause the game to crash by rewriting its code. This is both to the game's benefit and its detriment; on the one hand, you have an incredible amount of freedom in approaching every puzzle, but at the same time, it can be terribly intimidating if you don't understand why your solution simply didn't work. To be fair, though, that's pretty much programming in a nutshell.

The main problem with Hack 'n' Slash is that it's effectively two different games, one being the Zelda-style puzzler that explores concepts like variables and routines in greater depth than Human Resource Machine, and the other being a full-on code debugger that drops you into raw code without so much as a plank to float on. This difficulty spike makes Hack 'n Slash a rough game to play, but if you can get past that, there's a lot of good stuff to learn.

Concept: Advanced Variables

What are they?

As mentioned earlier, variables are ways of storing and referring to data in a program. In Hack 'n' Slash, they are used to store much more than the single letters and numbers of Human Resource Machine, and their role in defining a program's behaviour is made far more apparent.

How are they taught?

Hack 'n' Slash develops the concept of variables by introducing what are known as 'typed' variables. These are variables that can hold only a certain type of value, for instance only numbers, or only the values 'true' or 'false'. When you hack an enemy, a list of variables that you can mess with pops up, but you can only change their values according to their type: you can't store letters in a number variable, and you can't increase a number beyond its defined limits. Thanks to these unwritten rules, you gradually learn the difference between Booleans, integers, and strings, even if you don't know them by name.

The crux of Hack 'n' Slash's lesson in variables, however, is seeing how their values dictate a program's behaviour. Trial-and-erroring your way through a variable's range of values is good mental practice for any programmer, especially when testing and debugging. A program needs to be capable of handling all possible data thrown at it, even if that means discarding the data that would cause it to act funky. Realising just how easy it is to break Hack 'n' Slash's enemies by setting their Damage variable to -1 serves as an invaluable lesson in the importance of proper testing.

Concept: Syntax

What is it?

Just like the languages we use to communicate with each other, programming languages have rules for how their words come together to form sentences. This grammar is known as syntax, and though it can be unique to each language, most modern programming languages follow the conventions established by C some four decades ago.

How is it taught?

Hack 'n' Slash introduces the concept of syntax in its second half, when it moves past messing with variables and confronts you with naked code. Based on the Lua programming language, the code takes a number of liberties with its syntax, presumably in an effort to make it easier to understand. In practice, though, the made-up terminology only trades one flavour of confusion for another, limiting its real-world applicability in the process. Fortunately, the most common syntactic elements remain intact, familiarising you with the general structure of modern code.

Such grammatical rules include the dot syntax used in terms like Port.Value, which refers to the Value variable of an object called Port, and the structure of if... then statements for decision making. To help you decipher these oftentimes bewildering rules, Hack 'n' Slash drops you into a visualised version of the code, where variables are represented as colour-coded crystals that get fed into machines which process them into actions. Coloured lines trace the flow of the program between machines, although the machines are stacked so close together that it's often hard to follow the order of operations.

Concept: Functions/Methods

What are they?

There's an old adage in programming that 90% of a program's execution time is spent running 10% of its code. In other words, programs spend a whole lot of time repeating the same operations. To take advantage of this, we split the most common code out into discrete functions, and whenever the program needs to run that code, we just call the function with a command like funFunction(). This saves us from re-writing the same code multiple times throughout a program, and more importantly, it means we only need to change one chunk of code if an oft-used function needs tweaking.

How is it taught?

Taking the form of the largest machines in the visualised version of the code, functions themselves can be hacked just like enemies and other objects, making for an Inception-esque scenario of diving into the code within the code. Changes made to a function's code will propagate through the entire game, potentially leading to unexpected consequences later down the line. This is an all-too-common danger in programming, especially in bigger projects, and learning to be wary of the grander effects of even small changes is just good programming practice.

Verdict:

As a game, Hack 'n' Slash has a lot of problems. As a programming tutorial, it's markedly better. By emphasising the impact of tweaking variables, and visualising functions as physical machines, it covers concepts invaluable to all aspiring programmers. So long as you're prepared to learn the hard way just how much trial, error, and frustration goes into coding, you can come away with a firm grip on the systems and processes that underpin all languages of the modern era.

On page three, the scary world of assembly language in TIS-100.

TIS-100

Difficulty: Advanced+

The first thing you hear when you start TIS-100 is the cold boot of an old CRT. Whether or not this induces a pang of nostalgia is a good litmus test for how you'll feel about the assembly-language compiler disguised as a game. Make no mistake: TIS-100 is for the keenest of programmers only. If you're not already familiar with conditional statements and iteration and the like, you'll have a precipitous learning curve in front of you. Even if(have_exp == true), TIS-100 is hardly a cakewalk.

Assembly language, for those unfamiliar, is a form of programming language that was common in the '50s and '60s, before being supplanted by higher-level languages like C in the '70s and beyond. Assembly-language instructions are typically based on the machine code a computer uses to talk to itself, and as such they're significantly harder to read and write compared to the likes of Java and C#. Still, despite its archaic sensibilities, TIS-100 grapples with a number of concepts that remain relevant to this day.

Concept: Communication

What is it?

Communication is an essential component of modern programming. From online leaderboards to multiplayer FPSs to MMOs, games rely more and more these days on talking to each other to facilitate their fun. The problem is, it's practically impossible for one program to know what another is doing at any given moment, so managing communication becomes tricky. Think of it like two people having a conversation while at the same time fiddling with their phones. If one person's attention is focused on their phone, they might not hear what the other person is saying. To remedy this, programs communicate using ports and sockets, which are basically Post Office boxes managed by the operating system. A program can send off its data then go about its business, while the onus for checking for new messages falls on the recipient.

How is it taught?

Programs in TIS-100 are split up into nodes, each of which can only execute a limited number of instructions. To achieve the goals laid out for you requires a whole lot of data sharing between nodes. Worse, each node can only talk to those adjacent to it, complicating matters even further. Creating a working solution demands you think of each node as a separate program, privy only to its own operations. Getting them all to cooperate means establishing a communications protocol, just as a network programmer must do. You discover very quickly that convincing different programs to play nice together is harder than it might seem.

Concept: The Stack

What is it?

Like arrays, the stack is a container for grouping together related data. The stack, though, is better suited to shared-data environments where different programs, or different parts of a program, need to access the same data without directly communicating with each other. As the name implies, the stack stores data in a vertical list, adhering to the Last In, First Out (LIFO) protocol: when a new item is added, it goes to the top of the list, and when an item is removed, it's taken from the top of the list. Think of it like a stack of plates at a buffet restaurant, where patrons take from the top, while clean dishes are also placed on top. Or an internet browser's Back button and its record of your recent page history.

How is it taught?

As the programs you're writing increase in complexity, moving data between nodes that can only store two things at a time becomes a game of Chinese whispers, with the likelihood of error only getting higher. The introduction of stack nodes with their limitless data buckets gives you the means to handle much larger sets of data, though the extra capacity doesn't come free. You have to consider issues like deadlock, where one node is waiting for an empty stack to be refilled, but the node that would refill it is in turn waiting on something from the original node - stalemate! Then there's the problem of storing multiple datasets on a single stack without getting them all mixed up. Weighing up the trade-offs of using stack nodes versus managing data manually is the sort of consideration programmers make on a regular basis.

Verdict:
Though TIS-100 looks like a relic of the past, it's in no way outdated. From overlaying menus to multi-core programming, concepts like stack memory and network ports are as relevant today as ever. For the programmer-in-training, TIS-100 is the final hurdle; if you can survive its stiff challenge, you're ready to code.

Conclusions

So, can you learn to program by playing games? I'd say yes, with a couple of caveats. First, the challenges of programming are rarely as clearly defined as the puzzles in the aforementioned games; project requirements often change multiple times during development, and sometimes you won't even know whether what you're trying to do is possible until you do it - or give up. So maybe don't put Human Resource Machine on your CV. Second, games alone won't turn you into John Carmack; they can teach you the basics and help hone a programming mindset, but you'll still need to hit the virtual books before you're ready to make the next DOOM.

Nevertheless, if you go in with appropriate expectations and a healthy supply of determination, games like those I've looked at here can be a solid stepping stone to a future in programming. Just don't forget the most important rule of working in the tech industry: never tell anybody what you do for a living, or you'll be on the hook for fixing family members' bloatware-laden computers for the rest of your life.