The Games Programmers Play
[UPDATE 10/7/2011: After this article showed up on Slashdot earlier today, I've come to realize that the title and introduction send a very different message than the one I originally intended, and that some readers walked away feeling indignant and/or judged. To be explicit: my goal here is simply to draw some attention to a handful of games that sneakily incorporate elements of programming into an enjoyable game mechanic. I never meant to imply that all programmers MUST play games, and that if they do they should only play games about programming, and that anybody who feels otherwise isn't a REAL programmer. Some programmers play programming games. Some programmers (including me) play games from a variety of genres. Some programmers don't play games at all. That's just fine with me!]
Programming is boring. It's dry, detail-oriented, tedious, frustrating, infuriating work. And yet, to borrow a phrase from former US Secretary of State (and all-around stone-cold mofo) Daniel Webster, there are those who love it. Some just find that they have the knack, and there are certainly worse ways to make a living. For others, coding becomes an obsession; after a full day at work, they go home and keep programming all night long, just for fun. What's the appeal? Ignoring for a moment the obvious draws of a life of software engineering-- the riches, the fame, the all-night parties, the insatiable hordes of willing sexual partners, etc. -- it's fair to ask what programmers find so compelling about their jobs.
Or perhaps you need no such explanation. Perhaps you're already a full-on code addict who's looking for a way to share your passion with others. Maybe you just need an amusing distraction to keep yourself sharp in your off-hours.
Either way, you're in luck! Over the years, many an enterprising game designer has attempted to distill some of the joy of programming into a compelling game. Let's look at a few of the more successful ones. I urge you to give them a try, whether as a training exercise, an introduction to the craft, or simply to foster cross-disciplinary understanding (like in the "Dark Empire" series when Luke Skywalker temporarily turns to the Dark Side to learn to combat it more effectively).
At the simplest level are the games like WotC's RoboRally, Maxis's RoboSport and more recently Mode 7's Frozen Synapse that take the concept of turn-based strategy to the next level. In these games, the player is usually put in control of one or more robots who are competing against other robots to accomplish some goal, such as racing through a maze or annihilating the opposing teams deathmatch-style. Rather than simply deciding upon a single action to take for each turn, players must assemble a sequence of instructions for one or more robots to follow. For example, in RoboRally, one player's turn might consist of choosing the sequence "Move 3, Rotate Left, Back Up, Move 2, U-Turn". Once all players have chosen their actions, the sequences for all robots are revealed and played out simultaneously. Inevitably the carefully-planned actions all interfere with each other in interesting and unpredictable ways, which is what makes the game interesting.
So, is this programming? Barely, for sure, but the fundamentals are there. It introduces the process of decomposing a desired high-level action (e.g. "Move across the room, open the door and attack anyone I see") into individual atomic sub-actions -- "Move(forward)", "Use(door)", "If(see-enemy?) then Fire(shotgun)". With teams of two or more robots, there are even elements of cooperative multitasking at play. The big difference is that in these games, each program is executed exactly once and then discarded forever; there's no equivalent to debugging, optimization, architecture, managing data layout, or any of the other skills so central to "real" programming. The games are less about writing high-quality programs and more about correctly anticipating the actions of one's opponents.
Your duty is clear: to build and maintain those robots
Some games seem designed specifically to lead to a career in artificial intelligence. In these games, the player's direct role has finished before the game even begins. Players are once again programming actions for their characters (again, usually some sort of robot). But this time, rather than working one turn at a time, the robot's entire program must be submitted at the beginning of the game. Players then stand back and watch the robots duke it out with each other, fully autonomously! Examples include CogniToy's MindRover and the Starcraft AI Competition.
While second guessing one's opponents is still crucial, the emphasis is much more on the process of effective programming. Your strategy must be clever, but it must also be implemented efficiently and robustly. If your robot reacts too slowly to in-game stimulae, it could be easy prey for a more nimble opponent. A bug in your robot's code can cause it to crash or get stuck in an infinite loop; even simply zigging instead of zagging at the wrong moment can cost you the match. More importantly, unlike the trivial throwaway programs in RoboRally, this code becomes a persistent entity that must be actively maintained between games through iteration, debugging and refinement. These are valuable skills that translate directly into a working programmer's skill set.
One of the earliest and most interesting examples of this genre is 1984's Core Wars, a game inspired by CREEPER (a proto-virus from the early 1970s which is widely considered to be the very first Internet worm) and the "Reaper" program written to defend against it. What's unique about Core Wars is that the players are not programming a game character; instead, their game character is the program itself! Using a custom assembly-like language called Redcode, Core Wars players implement warrior programs which are all run simultaneously on the same simulated CPU, using the same block of memory (called "core" in olden times). The goal is for your program to be the last one running, after overwriting your opponents' programs and causing them to crash themselves. A fascinating ecosystem of strategies has arisen, such as "bombers" (which systematically sprinkle "poisonous" instructions throughout memory in hopes that an opponent will hit one) and "replicators" (which recursively spawn multiple copies of themselves in hopes of overwhelming an opponent). The analogy to malware (and anti-malware) should be obvious, and fairly creepy. Hardcore!
Robots In Disguise
There's one game I'm aware of that goes one step further; rather than using programming to facilitate a game, the programming is the game. On the surface, SpaceChem has nothing to do with programming; it's merely a futuristic puzzle game in which you build factories that convert one or more input molecules into one or more output molecules. Each factory contains a pair of independent molecule manipulators (the game calls them "waldos") which follow a fixed path through the work area. Waldos can grab, drop, and rotate molecules, make and break chemical bonds between atoms, request new input molecules and submit output molecules. Your solutions are graded based on how efficiently they produce the desired output, both in terms of time and number of components used. Of course there are global high-score lists to show you how your solutions measure up. And while it's not relevant to the current discussion, it's got an excellent soundtrack.
Don't be fooled! This isn't a game about chemistry; it's actually the closest thing I've ever seen to a low-level SPU programming simulator! Each factory is an SPU running a single task. The two waldos are the SPU's dual execution pipelines. Moving and editing molecules is analogous to reading, writing and operating on data in local store. Keeping your waldos perfectly synchronized (preferably without the use of the game's explicit synchronization elements, which count against your score) mirrors the challenges of SPU loop pipelining. With multiple factories running simultaneously and feeding into each other, you quickly encounter the problem of multi-core load-balancing to prevent catastrophic bottlenecks; if one factory is producing output faster than a later stage is consuming it, the pipeline will get backed up and crash itself. And just like in real life, faster and smaller code is better; you can spend hours reworking your factories to eliminate a few precious cycles from your overall running time. This is literally programming plus leaderboards; you'll either love it or you'll hate it. Take note, though: if you love it, you may already be a bad-ass PS3 engine programmer without even realizing it! You'd better send your résumé to Naughty Dog, just to be sure...
SpaceChem should keep me busy for quite some time, but I'm always looking for more good programming games. If you know of any that I missed, please let me know in the comments!