This series of posts looks at games that involve programming as part of playing them. Today: LightBot, a free online flash game.
In my last post, I described RoboRally, a board game involving programming a robot using simple commands like move forward, turn left, and so on. In this post, I’m going to look at LightBot, a computer game involving programming a robot using simple commands like move forward, turn left, and so on. Hmmmm! I don’t know if LightBot was actually copied from RoboRally, but either way: the mechanics are very similar.
The interesting parts of LightBot are, therefore, where it differs from RoboRally. In terms of the programming mechanics, the main addition LightBot makes over RoboRally is the addition of functions/procedures. LightBot makes their use necessary by having problems that require more instructions than you can fit in the normal program execution, thus requiring you to pull out parts into a procedure, and calling that several times. It’s quite a neat, simple addition that adds another concept (although there’s no parameterisation for the functions, which obviously limits them).
The major difference between RoboRally and LightBot are the overall setup. RoboRally is a competitive game in which you must guide your robot around to the next checkpoint, dealing with the board obstacles. (Though I guess you could adapt RoboRally as a solitaire game…) LightBot has an explicit set of challenges that increase in difficulty and progressively introduce new concepts. The design of puzzle games is very similar to ideas in instructional design: you must slowly add new tools to the player’s toolbox and offer simple problems that demonstrate the use of each new tool, before you can then offer a problem that involves combining several of the tools.
The other benefits of LightBot are that the goal of each puzzle is clear, the behaviour of the robot and the correspondence to the instructions is clear, and the state of the world is simple and visible. This makes it easy to understand what the instructions do, and easy to see where you are going wrong. It’s no surprise that many teachers use LightBot as a good introduction to programming, especially for younger pupils.
LightBot and RoboRally both share these advantages of having highly visible state and allow easy understanding of what each instruction does. So why can’t all programming be like this? I think the answer is that programming all too quickly involves too much state to be visualised succinctly. As soon as you have more than a few variables (and maybe a data structure), the state becomes too much to visualise all at once. And when your program gets big enough, you shouldn’t need to visualise the whole state anyway: modularisation is an important part of programming later on, precisely because it allows you to consider one part in isolation of the others. Although that’s not to say that programming games can’t get complex, as we’ll see in our next example.