# Rapid Router Programming Game

By | December 7, 2016

I’ve recently helped several classes experiment with programming using Ocado’s “Rapid Router” game. What surprised me the most was the range of ages that enjoyed using it — from Year 7’s to Year 10’s.

It’s helped by having many levels, with the sophistication of the challenges increasing throughout — we started the Year 10’s on level 45!

The kids enjoyed the competitive nature of the program also, which was another surprise. As the teacher, you can project a continually updating “leaderboard” page showing the progress of all students in the class. It’s not just the fastest that get ahead: the program analyses the quality of the solutions too, so retrying levels to find a better solution (and not just the first that works) is rewarded.

https://www.codeforlife.education/rapidrouter/

Aha! Moments

For several students, the game provided a “light bulb” moment when they suddenly appreciated what an algorithm really is, and what makes an algorithm different from a simple list of instructions. I’ll explain…

In the early levels, the driving instructions can only be built from simple actions, e.g., ahead, ahead, turn left, ahead, turn right, deliver. This allows a route to be constructed, but it only works for one specific road layout. On the next level, with a different road layout, the student has to come up with a completely different set of instructions.

In later levels, more complex actions are introduced, including decision blocks such as “is there a left turn available” and “is there any road straight ahead”. To achieve a perfect score, students must write the shortest program with the least amount of repeated code (“keep it DRY”) — this encourages them to explore solutions that use decisions to navigate the road layout automatically.

The Aha moment comes when students have answered several questions like this, and realise that their sequence of instructions is the same each time, even though they work for any road layout. They realise what they’ve produced is a true algorithm, because that same list of instructions can be used to solve many variations of the same general problem.

After that, they just keep improving the algorithm so it can cope with a wider set of variations, for example when traffic lights are introduced to the road layout!

Is this evidence that teaching programming using test-driven-development (TDD) might help?

Interestingly, when I asked them about the process of discovering and refining their algorithm, they all said that producing multiple “single problem” solutions first had helped them to the spot the general solution — if they’d been asked to produce the final algorithm straight away, they’d have struggled.

This is why I think teaching programming through “test driven development” might be successful. It would encourage students to construct algorithms bit by bit, with each new version handling a wider set of variations, all the time verifying that the new elements haven’t broken any of the earlier capabilities.

Gotchas!

Here are some of the things that caught us out…

• Registration usernames and passwords — these are generated after uploading a CSV file of your class, and can printed out on labels and stuck in Planners. Great, except the passwords contain hard-to-distinguish characters (1, I, l, 0, o etc) — so expect some students to struggle typing them in correctly.
• When the truck’s heading down the screen, left turns and right turns can seem to be the wrong way round, depending on how your brain works.—
• Depending on the size / resolution of your monitors, some levels don’t show the whole layout at once. You can fix it by sliding the dividing line in the middle of the page to the left, to make more room.
• There’s a “go faster” button which speeds up the truck once you’ve got the hand of things.
• After crashing the truck, you need to “reset” it back to the start location (by pressing the “stop” button) before adding more instructions — otherwise you’ll get in a confused mess with your instruction list.