There are relatively few games that feature programming as a core mechanic. In this post I’m going to explain one such game: RoboRally. For those who know LightBot (which I’ll cover next time), RoboRally is like a non-electronic, multiplayer precursor to LightBot.
RoboRally does involve programming, but it’s a board game rather than a computer game:
The game is centred around a group of robots (hence Robo) let loose in a dangerous factory, racing towards a series of checkpoints (hence Rally), while trying to shoot and ram each other as much as possible. Hmmm, this one might be a bit of a boy’s game, but bear with me! Play takes place on a combination of these boards of square grids:
Each robot occupies one square, and the board is littered with environmental hazards: lasers that damage you, pushers that shove you, conveyor belts that move you around and so on:
Your job is to guide your robot from A to B. And how you do this is where the programming comes in. There is a deck of movement cards, with very simple movement primitives: move forward (1, 2, or 3 squares), move backwards (1 square), turn left (90 degrees), turn right (90 degrees) and turn 180. You normally get dealt nine of these cards at the beginning of each round:
You must then select five of these cards to comprise your movement for this turn. Every other player does the same. Then you all reveal your cards, one by one, and execute the moves on them. Here’s an animated example (although here I’m covering up the cards to show which moves I’ve made):
The game has various other features which add challenge. Every unit of damage you incur (from players or board obstacles) reduces your starting hand by one card, which starts to get difficult. When you are close to another robot, you must start to consider that you might get rammed, i.e. pushed one space, which really upsets your planned movement! And you want to try and avoid being shot by other players, or else you’ll soon have very few cards each round.
So what programming concepts does RoboRally feature? The first is sequencing of instructions: your cards take effect one after the other. Aside from the unpredictability of other players’ robots, the game is completely deterministic. Your move cards do exactly what they say, and your robot’s interaction with the board has no element of chance. In fact, it all sounds very easy! But a major complicating factor is that you must plan all five cards without moving your robot. So you must be able to predict where your robot will be after each card, in order to get the next move set up correctly. So you have to be able to mentally execute your moves.
The Learning Curve
When players first start out in RoboRally, the first challenge is just to string together five cards to move to where they want. The mental execution proves a bit tricky, so after the third or fourth card, players end up not quite where they had imagined, and thus the fifth card can see them lurching forward towards a deadly pit! But by executing the moves (and with players watching and correcting each other), they can see the disagreement between their prediction and the actual execution. One nice feature of RoboRally is that all state is visible: your robot’s position and rotation on the board is the only thing to keep track of. And the good thing is that failing is funny, with robots unintentionally running into walls or pits.
After players have mastered the basics of movement, they have to then understand the environmental hazards. Walls are very straightforward: you can’t pass through them. But boards can also feature conveyor belts, which move you forwards (and potentially turn you) if you are standing on them, and pushers which shove you sideways. So players must learn the rules of the board squares, and form a mental model of what will happen, in order to plan their move successfully.
Players soon start learning little tricks, especially when their hand selection becomes limited: a turn left 90 plus a turn 180 is a substitute for the turn right 90 that you desperately needed but weren’t dealt. Sometimes, moving backwards can be a useful way of getting to your goal. Planning eventually becomes almost as easy as you might initially have expected: after all, how hard can programming a deterministic machine be? (Programmers know the answer to that one!) You then have to start factoring in what your opponent on the adjacent square is doing, and planning against it (defensive programming!?).
RoboRally is a great example of a programming game. It has a few flaws as a board game: once one player edges ahead, they tend to stay ahead (while the robots behind shoot each other and get in each other’s way), although you can solve this by playing the capture-the-flag variant instead of plain racing. It can get quite slow with many players, which is especially a problem if you have mixed abilities: each turn proceeds at the pace of the slowest player. But I still think it might be a suitable activity for a small after-school club (though it may run over several sessions). Maybe we can try slotting in an evening game at our teachers’ summer school this year.
I couldn’t end without my favourite bit of RoboRally trivia. Designer Richard Garfield came up with the idea for RoboRally in the mid 1980s and was trying to get it published when he met with a young company called Wizards of the Coast (WotC) in the early 1990s. WotC were interested but felt the game would be quite pricey to produce; they wanted a smaller, cheaper game before RoboRally. Garfield offered them a card game that fit the bill, and WotC bought the card game and RoboRally. That card game was Magic: The Gathering, which quickly became one of the most successful card games ever, and which still has millions of players nearly twenty years after its release. But I prefer RoboRally.