The Robots Game

(This post is another follow-up to Learning to Program.)



When stage magician James Randi was doing cabaret work, he had the habit of opening his act with a newspaper tearing-and-reassembly routine. With the music playing, he would stride out in front of the audience with a piece of newspaper folded under his arm. He would unfurl the newspaper and tear it up into pieces. Then he would shuffle the pile of pieces, give it a flip and it would all be back together again. The music would stop, he would throw the newspaper aside and address the audience, saying: "I don't know how that trick's done and I don't care."

Now the funny thing about this, as Randi explains, is that there was in fact something about the routine that he didn't know. The rest of the act went better when he started out this way, but for a long time he didn't know why. "Most magicians," says Randi, "don't know why their tricks work. They know they work because they've done them and done them repeatedly, and sometimes they do things on stage that they don't quite understand, but they know that they work."

What was Randi's opening routine really doing? "I started doing it and I found it worked very well," he says. "But I only realised years into it that I was sizing up the audience. I would be looking around the audience while tearing up the newspaper and seeing people who were paying attention and others that maybe had a few too many drinks, or they were distracted in some way and were talking to the person beside them." Who should he call on from the audience to take part in subsequent routines? The way the newspaper routine worked was that it told him the answer to that question and made the rest of his act work better.

I've opened my programming teaching for several years now with "The Robots Game". It seems to work very well for me, but I'm not entirely sure why. So, in this post I'll describe the game and its rules and then I'll speculate on how it might work as the opening routine for a programming course.



Equipment

This is a board game for six players so for each group of six students you will need:

The board, printed out on a large piece of card or foam-board:



The six "robot" playing pieces, numbered 1 to 6:



Printed move-sheets for the players to write directions, and pencils/pens:



You will also need (as you can see in some of the photos) a normal six-sided dice.

Rules

(1) This is a race game played by two teams. The winning team is the first to get all their "robots" from the start to the finish and off the board. (Note: the winner is the first team to get all their robots off the board, not just the first one.)

(2) Each team consists of three players and each player controls one specific robot. Each robot has an identifying number. As you can see from the photos, my robot playing pieces have the numbers on the top, with 1, 2, 3 in one colour for one team and 4, 5, 6 in another colour for the other team.

(3) The robots start facing into the board on the six starting squares on one end. (The pieces must have some way to show what direction they are facing. My robot playing pieces have arrows on the top, but in a previous version I used little Lego figures with numbers stuck to their backs.)



(4) Each player starts with their own blank move-sheet on which they will write directions for their robot. (After your students arrange themselves into two teams of three, get each student to write the number of their robot on their move-sheet, so there's no doubt as to which is which.)

(5) The game consists of a series of turns, continuing until one team has won. Each turn proceeds as follows:

(5 a) Every player writes on their move-sheet up to 10 moves for their robot. As you can see, the move-sheets I use have the numbers 1 to 10 down one edge, so the moves for each turn can be written vertically down one column. Valid moves are Forward (F), Back (B), Right (R) and Left (L). It's fine to not use all 10 moves. (It's even fine to not use any of your moves, in which case your robot will just stay in the same place.) Naturally, players on the same team will wish to coordinate their moves with each other, but hide their plans from the other team.

(5 b) When everyone has finished writing their moves, someone throws the dice. Depending on what number comes up, the robots execute their moves in sequence starting with that number. Thus, for example, if the dice shows 4, then all robot 4's moves will be executed first, followed by all robot 5's, then 6, then 1, then 2 and finally 3. (Thus when writing moves, the players cannot be sure exactly where the other robots will be, even on their own team.)

(5 c) To execute the moves for each robot, the player controlling that robot reads out the sequence of moves for that turn from their move-sheet. Someone else actually moves their robot (preferably someone from the other team). The reason for this is that people can make mistakes writing down their moves, and rather than giving them the opportunity to correct them, we want to ensure that the robot executes the moves that they actually wrote down.

(5 d) Each move is executed as follows: Forward attempts to move the robot forward one square in the direction it is facing. This succeeds if that square is an unoccupied green square or if the shunting rule applies (see 5 e). Otherwise the move fails. (For example if the square in front is a brick-wall.) Back attempts to move the robot one square backwards and succeeds or fails in the same way as for a forwards move. Right and Left turn the robot in place through 90-degrees clockwise or anti-clockwise, respectively. These moves always succeed.

(5 e) Shunting. If a robot attempts to move into a square occupied by another robot, this will succeed provided that (i) the moving robot has just crossed one empty square ("it has momentum") AND (ii) there is an empty green square on the other side of the stationary robot ("it has somewhere to go"). When a shunting move succeeds, the moving robot afterwards occupies the square where the stationary robot was, and the stationary robot is shunted along one square in the obvious way. (Note that part (i) means that you can only shunt another robot one square. Continuing to move in the same direction will fail. You can do two shunts in a turn, but you have to back up and take another run-up at the stationary robot.)

(5 f) All moves of a particular robot are executed in order, irrespective of whether its earlier moves that turn succeeded or failed. Thus a robot might use several moves trying and failing to go forwards ("spinning its wheels") then turn and succeed in going forwards in a different direction. (But probably not end up in the place its controller intended.)



(6) Exit squares and winning. The four squares with outward-facing arrows at the end of the board are exit squares. When a robot moves onto one of these squares it is immediately removed from play, and takes no further part in the game. Moves are made as normal each turn for the remaining robots, skipping over robots which have been removed from play. The first team to have all three robots out of play in this way is the winner.

Discussion

The game is quite fun and doesn't take very long to play — usually around a quarter of an hour or less. It's almost always quite close at the end, because of course it's a race between the last robot in each team. There's plenty of opportunity for delaying tactics and clever blocking moves near the exit by the team which is behind, provided they don't just individually run for the exit as fast as possible.

But turning back to the idea from James Randi, how does this game work? It seems from my experience to be doing something useful, but how does it really work as an opening routine for a programming class? Perhaps first of all, I think it lets me give the impression to the students that the rest of the class might be fun. Lots of students don't seem to like the idea of programming, so perhaps playing a team game like this at the start of the class surprises them into giving it a second chance.

I think also that there is an element of "sizing the audience up" — it's a way to see how the students interact with one another, to see who is retiring and who is bold, who is methodical and who is careless. The people who like clever tricks in the game seem often to be the people who like clever tricks in programming. There is also some evidence that facility with mental rotation is correlated with programming ability. (See Spatial ability and learning to program by Sue Jones and Gary Burnett in Human Technology, vol.4(1), May 2008, pp.47-61.) To the extent that this is true, I might be getting a hint about who will have trouble with programming from seeing who has trouble making their robot turn the correct direction.

I'm keen to point out to the students, after the games are over, that the game really has some relation to programming. I point out that they have been writing sequences of instructions, little programs for the robots, which then get blindly executed. I point out that although computers seem clever, they really have no more intelligence than the wooden playing pieces in the game. Computers just execute their moves billions of times faster, and that makes them seem smart.

I also ask if anyone found that their robot ever did something that they didn't want it to do. (Inevitably there are a few cases where people just wrote down the wrong move and their robot trundled off in an unexpected direction.) I point out that this is an ordinary thing in programming. It's going to happen again, it happens to the best of programmers, so don't be embarrassed. Just learn how to play the detective, to find and fix your inevitable mistakes. Computers, like the robots, don't do what we want. They do what we say.

(James Randi's explanation of his newspaper routine is from the the first Security and Human Behavior Workshop which took place in July 2008.)

(Added 27 July 2013.) I've had some requests for an image of the game board. Here is an 5673 x 4046 pixel image, which should print nicely at any reasonable size.