Programming is fun. Now that your mind is blown let's talk about games that feature programming as a core mechanic.
As you're well aware, I love board games. One board game that I enjoy is called Robo Rally. In Robo Rally each player takes control of a robot, each of which need to reach the same set of locations on the board in the same order. Players have cards that serve as commands for their robots, and the robots can interfere with one another.
The catch is that the players have to place their commands face down before the movement phase of the game begins. They have to program their robots in advance, without knowing what the other players are programming their robots to do. Once every player is finished, their programs run simultaneously, usually with disastrous results (did I mention the robots all have lasers?). Because the robots cannot change their programming and because the game board is so hazardous to all life (artificial or otherwise), small changes in conditions can carry dire consequences for the poor robots.
Robo Rally covers two very important programming gotchas: bugs and concurrency. In Robo Rally, if you place a left-turn card instead of a right-turn card, your robot will go on a magical journey into a bottomless pit, or perhaps take a conveyor belt ride directly into a laser death trap. After a few mixups like that players learn something all programmers know: run through your code in your head before deciding it's correct. In other words, Robo Rally teaches players testing and debugging.
Likewise, other players' robots move and act at the same time as yours. The robots can push each other around, ruining a perfectly good program and leading your robot to its metallic death. Luckily the game provides a method for resolving two simultaneous actions through the use of sequence numbers. Every action has an associated sequence number. The smaller the number, the sooner the robot moves. So players can strategize whether to use fast or slow moves during turns they think they'll be near other robots. This doesn't exactly correlate to common solutions to concurrent programming but at the very least it provides a powerful demonstration of the complexities involved in simultaneous code execution in a fun way, which I think it fantastic.
If you've been following me on Steam then you'll know that I've been playing a lot of SpaceChem lately. (In fact I've been playing more SpaceChem than Portal 2 — which is saying a lot considering I haven't beaten SpaceChem yet but I've beaten Portal 2 one and three fifths times.) SpaceChem is not a chemistry game from Zachtronics Industries (known for great games the Codex of Alchemical Engineering and Infiniminer (which was where Notch got his idea for Minecraft) both of which I played years ago), but is in fact an engineering game from Zachtronics Industries.
In SpaceChem, the player's job is create specific chemicals by recombining, fusing and splitting other chemicals. The player does this using a versatile tool called a Waldo, which is, essentially, a program counter. The Waldo follows a path defined by the player, and executes actions along the path as it passes over them. These actions range from "grab atom" to "fire giant mining laser at aliens".
One of the big constraints in SpaceChem is space: each instruction takes up one unit of space (of which there are only 80), and often instructions need to be placed in specific regions in order to work properly. More importantly, there are very few control structures (other than loops) available, and those that are available are rather limited. This means that Waldo paths can get very complicated very quickly unless you have a good strategy for solving the problem beforehand. But it's not so bad, because in accordance with the Lego metaphor Waldo instructions are easy to change and modify while your plan of action changes.
A few levels into the game, the player is given access to additional reactors, adding more complexity to the types of puzzles that can be solved. But the really important feature is that reactors can be saved and loaded: the player can create reusable functions for common tasks. In fact, some of the levels have puzzles that are based on the same fundamental idea that needs to be applied in a more and more complex manner. The game therefore encourages users to create a bank of efficient reactors they can use in later levels. The game encourages smart, modular software design!
With multiple reactors comes another interesting facet of programming that's leaked into SpaceChem: the time and space tradeoff. The more complicated a reactor, the longer the reactor takes to complete its task. Adding another reactor to a puzzle adds more space for the Waldos to work in, but in splitting the task up among more Waldos each individual portion of the task is made simpler and therefore faster. In other words, with many puzzles adding more reactors allows the puzzle to be completed in fewer steps (i.e., adding more space reduces the time it takes for the program to finish). It's neat to see that come up such an accessible game considering it's seen as an excuse to hate programmers. One more example for the good guys.
Programming is fun. Robo Rally and SpaceChem prove it. Robots and chemicals and lasers and aliens are around every function call and return statement. It takes a real hero to be able to win games and write software. That hero could be you! (But in reality it's me.)