Review RoboRally
RoboRally was published more than ten years ago (1994). It is an older game which I kept playing for a while in the mid to late Nineties. It recently got back to the table which motivates this review.
The objective of the game is to program your robot to reach certain waypoints on the board. At the start of a turn you get a set of program steps which enable your robot to move (forward, backward, fast forward, very fast forward) or to turn (90 degrees or 180 degrees). The game is set in some sort of (old?) factory with different designs for the factory layout. The board layout alone contains plenty of challenges for your robot: belt conveyors which move you another one or two fields, firing lasers, plus deep deeeeeep holes.
RoboRally makes a programmers life difficult. It is quite possible that your hand is missing that particular left turn which would have made you reach the next waypoint easily. But the game is not about hand management: each player receives nine cards (or less if the robot is partially broken due to laser fire) and has to pick five cards as programming steps for their robots. The cards introduce a luck element into this very algorithmic thought processes. Which makes it all the more challenging, as the obstacles on the board, in particular the belt conveyors cause a lot of thinking trouble for women, academics and regular people. RoboRally is a game that gives software engineers a little advantage, I guess...
After each player has secretly decided on the programming steps, a (imaginery) CPU processes them by priority. Each card has a priority value printed on it which determines the order in which this particular step is executed (as compared to the other player's cards). Due to this process your entire programming steps might get totally messed up as another programmer may have a higher priority and hustle your little fellow over the board. If this happens directly after the first step, your entire programming will obviously result in a totally messed up position, or even worse, in a robot's termination. Or should we rather say temporary termination? As a copy of the robot is reinstated at the last archive spot on the map (i.e. the last waypoint or a particular repair spot in the factory). From here on, the robot's progress is less obstructed by fellow robots.
Unfortunately, this is one of the major problems of the game. Once a single robot is ahead one or two waypoints it is nearly impossible to stop him. The game is fun, if there is a lot of interaction between robots - the Schadenfreude effect. If one robot is too far ahead it becomes boring easily. The second problem of the game is it's length. To finish a game with two boards and four or five waypoints takes a long long time. As all players have to carefully plan their moves, this phase of a turn might become lengthy as well. A robot that is currently in a rather uncomplicated area of the board is easier and quicker to program than one currently stuck in this supercomplex maze of conveyor belts.
The game celebrates the luck element. The program execution order and the interaction of robots can totally destroy what player's had previously planned. I sometimes think RoboRally tries to teach us that planning ahead is not everything. Taking a strategic detour at the beginning to get out of the way of the crowds is a promising strategy. But which detour is the right one?
Personally, I like to play the game from time to time. The Schadenfreude-effect is just to cool. Plus, if your carefully planned program is destroyed by another robot and you have to watch your little robot move twoards the abyss... It is heartbreaking. All the energy for nothing. If players are able to take this with a lot of humor then RoboRally makes for an entertaining evening. Just try to cut the game short a little bit and introduce a limit for programming time. This should speed up the game a little bit and decrease total play time.