Reference

How the cart works

Driving a cart with code is just a position and a facing. Once you can picture which cell the cart is on and which way it points, you can read a program and trace its route around the walls before it runs. Here’s the model. Open the track lab →

  • The cart has a cell and a facing

    The cart sits on one square of the grid and points one way (up, down, left, or right). Everything it does is relative to which cell it is on and which way it faces right now.

  • move() goes forward one cell

    move() sends the cart one square the way it faces — but only if that square is open. If a wall or the edge is in the way, the cart stays put (the move is blocked).

  • turns change the facing, not the cell

    turnLeft() and turnRight() rotate the cart in place by 90°. They don’t move it — they aim the NEXT move(). To go around a corner: move up to it, turn, then move on.

  • canMove() looks one cell ahead

    canMove() answers yes/no: is the cell right in front open? That lets a program decide — `while canMove() { move() }` drives forward until a wall or edge stops it, with no counting.

  • A rule can steer around walls

    An if/else rule each step — “if you can move, do; otherwise turn” — follows a bent corridor without knowing its shape in advance. That is how one small program solves many tracks.

  • A solver proves it’s solvable

    Before you ever see a track, a search (breadth-first) tries every route and checks that SOME program reaches the ore — so a puzzle is never impossible — and it reports the shortest program, the “par”.

The cart commands

  • move()Go forward one cell (if it is open); otherwise stay put.
  • turnLeft()Rotate 90° left, in place — aims the next move.
  • turnRight()Rotate 90° right, in place — aims the next move.
  • canMove()Yes/no: is the cell straight ahead open (not a wall or the edge)?
  • atOre()Yes/no: is the cart on the ore right now?
  • while canMove() { … }Repeat while the way ahead is open — drive until something blocks it.
Where this idea comes from

Carts, rails and a robot named Karel

Long before trains, coal was pulled along wooden rails in carts called wagons. The Wollaton Wagonway near Nottingham, built in 1603–04 by Huntingdon Beaumont, is often named as the first overland one in England: the rails decided where a wagon could go.

One thing to hold: Karel the Robot, a tiny robot on a grid made up by Richard Pattis in 1981 to teach programming. Karel’s main moves are to step forward, turn left and check what is ahead, like RailForge’s cart.

Why it matters: A loop like "while canMove()" must end some day. In 1967 the computer scientist Robert Floyd showed how to be sure: find something that gets smaller every time round (the cells left before the wall), and it cannot shrink forever. Tony Hoare then wrote rules for proving what a program does when it ends.

What we don’t know: Which wagonway came first is still argued: a wagonway at Prescot Hall, near Liverpool, may be a few years older than Wollaton, and short tracks inside mines may be older still but were never written down.

Dates:

  1. 1604 The Wollaton Wagonway carries coal on wooden rails.
  2. 1967 Floyd shows how to prove a loop finishes.
  3. 1969 Hoare writes down rules for proving programs right.
  4. 1981 Karel the Robot starts teaching programming on a grid.

Sources: M. J. T. Lewis, Early Wooden Railways (Routledge & Kegan Paul, 1970) · Richard E. Pattis, Karel the Robot: A Gentle Introduction to the Art of Programming (Wiley, 1981) · Robert W. Floyd, "Assigning Meanings to Programs", Proceedings of Symposia in Applied Mathematics 19 (1967) · C. A. R. Hoare, "An Axiomatic Basis for Computer Programming", Communications of the ACM 12(10), 1969

The trick to reading a cart program is to trace it cell by cell: move forward, turn to aim, check ahead, repeat. Walls and the edge stop a move; the loop or the rule steers around them. Read a cart program →