Last updated: 24 August 1995.
Originally by: Val Kartchner (val@mail.kdcol.com, now elsewhere)
Hosted by: Richard Rognlie rrognlie@gamerz.net

Table of Contents

1. New in This Version
2. Trademarks and Copyrights
3. This File
4. What if I Disagree With This FAQ?
5. What is _RoboRally_?
6. Rules Summary
   1. Setup
   2. Each Turn
   3. Each Phase
   4. End of Each Turn
   5. Winning
7. Interpretations of Common Rule Misconceptions/Ambiguities
   1. Setup
   2. Belt Movement
   3. Fire Control
   4. Other Option Questions
   5. Other Questions
8. House Rules
   1. Setup Options
   2. Leader Break-Away Syndrome
   3. RoboMonsters
   4. Other Variations
   5. Other Games to Play With _RoboRally_ components
9. Miscellaneous
   1. _RoboRally_ Homepage
   2. _RoboRally_ News
   3. Requests
10. Endnotes
11. List of Contributors
12. Glossary

1: New in This Version

For now, this is a revision history of the latest few versions.

2: Trademarks and Copyrights

_RoboRally_ is a trademark of Wizards of the Coast, Inc.

_RoboRally Operating Manual_ is copyright 1994 by Wizards of the Coast, Inc.

Most of this file is written by Val Kartchner.

Parts are from messages posted to Usenet, or sent to me in email.

This file in its entirity is copyright 1995 by Val Kartchner (authorship and editorial copyrights).

It may not be reproduced in any form without written permission from Val Kartchner, except for personal use or redistribution through normal Usenet channels and viewing with Web browsers.

All contributions and suggestions about this file sent to Val Kartchner are gratefully received and will be regarded, unless otherwise labelled, as freely given donations for possible use as part of this file.

3: This File

This is the unofficial _RoboRally_ FAQ. It has not been approved nor endorsed by Wizards of the Coast, Garfield Games, J. Michael Davis, nor anyone else responsible for the production of _RoboRally_. The views expressed herein are the views of the author, but they may also be shared by others. This answers many of the most frequently asked questions regarding the game _RoboRally_. It is available from http://www.kdcol.com/~val/games/RR/RoboRally-FAQ.html and will be periodically posted to Usenet in the newsgroup rec.games.board. Once this FAQ has passed beyond the preliminary stages, it will probably also be posted in the newsgroups news.answers and rec.answers. Rather than maintain two separate versions of this FAQ, the source file has been written using HTML. The version posted to Usenet has been dumped to an ASCII-only format. Because of the dual role of the source file, there are some artifacts in both the HTML version and the ASCII version. Where significant text is needed to further clarify answers, the text has been placed in the Endnotes section of this document with a numbered reference of the form "(*1)".

4: What if I Disagree With This FAQ

There are many opinions on how the game should be set up and played. I have made (what I judge to be) an educated interpretation of the rules. I have generally followed the order of: clarification(s) by the designers and/or developers, interpretation of the included rules, concensus interpretation, and my best interpretation. I welcome suggestions for improvements of this file from anyone interested in _RoboRally_. I will especially welcome input from J. Michael Davis and others involved in the creation of _RoboRally_. If you disagree with something in this FAQ, please send me an email message state as clearly and as concisely as possible your reason(s) for disagreeing. Include the section number and references supporting your position. I will reply, and either either explain my position better or stand corrected. If you think that there is an ambiguity that I have missed, please send me email stating as clearly and concisely as possible the problem. Please include any possible interpretations which you may have made. Unless otherwise stated these comments will be considered as freely given donations for inclusion in this file.

5: What is _RoboRally_?

In _RoboRally_, each player takes the role of a sentient control computer in charge of a widget factory on a totally automated planet. In order to alleviate the intense boredom, the computers devised a maniacal race around one or more of the factory floors. Each player controls one robot in an attempt to be the first to race from the starting space to each of the checkpoints. It's not just a simple race because you must program your robot to deal with the factory floor using the random instruction cards which you have been dealt. The other robots may use their weapons to cause damage or to otherwise affect your course. This game was designed by Richard Garfield (Garfield Games). It is distributed by Wizards of the Coast who also distribute Magic the Gathering (of Money), the first of the collectible trading-card games. I suspect that many of the stores which sell _RoboRally_ ordered them because they thought that it would be another collectible trading-card game. Mike Davis is listed in the _RoboRally Operating Manual_ as "Developer and `Keeper of the Flame'" (whatever that is), and is an occasional participant in discussions in the newsgroup rec.games.board.

6: RULES SUMMARY

This summary should be sufficient to play a first game. It is brief, but it is believed to be complete. The _RoboRally Operating Manual_ should be consulted for diagrams and more information.

6.1: SETUP

Pick any number of the provided boards and place them adjacent to each other in most any arrangement. Choose one of the archive locations as a starting location for all of the robots. Take any number of checkpoints (flags) and place them on the boards so that it is possible for a robot to get from the start to each of the checkpoints in order. (Four boards and three or four flags is a good number when first playing.) Each player takes five life counters. Each player also picks one of the pewter figures (for `real mode') and the cardboard counter picturing that robot (for `virtual mode'). The players all start in virtual mode at the starting location, and they each pick the initial direction that their robot will face.

6.2: EACH TURN

Each player whose robot has not powered-down is dealt nine cards minus the number of points of damage that their robot has accumulated. The player then programs the five registers numbered from one to five for the five phases of each turn. For each point of damage over four which has been accumulated, one more register becomes locked. (i.e.: The program card most recently there cannot be changed.) Before revealing any cards, any players who's robot has damage (and only those with damage) may declare to be powering down next turn.

6.3: EACH PHASE

During each of the five phases, all players turn over the program card which corresponds to that phase. Most of the time, players' moves can be made simultaneously, but when timing conflicts arise, the player with the higher numbered card moves first.(*1) Robots move according to the instruction on the card moving and/or pushing other robots up to the limits of walls; no two robots in real mode may occupy the same space. (Examples of robot movement are given in _The RoboRally Operating Manual_ on pages 18 - 24 and 31 - 34.) Any robots which move or are pushed onto a pit space is immediately destroyed. (Going off of the board is the same as falling down a pit.) After all robots have moved, the other board elements affect movement in this order: * all express conveyor belts (the silver ones) move robots one space (in the direction of the arrow), * all conveyor belts move robots one space (in the direction of the arrow), * pushers push one space (if active this phase), * gears turn 90 degrees (in direction of arrow), * crushers crush (if active this phase), * lasers fire (causing one point of damage per laser), * checkpoints touched (for robots still alive).

6.4: END OF EACH TURN

Robots which have fallen down a pit, been crushed by a crusher, or been destroyed by taking ten or more points of damage lose a life counter. If all of the life tokens have been lost, that player is out of the game. Otherwise, that player's robot is placed on the most recent archive location on which that robot ended a phase facing any direction. When restored, the robot has two total points of damage, and loses one option card. The player has the option of having the robot restored powered-down. Any player robot which is powered-down has all points of damage repaired. Any robots which are powered-up on an archive location repairs the same number of points of damage as there are wrenches on the space. Robots on double-wrench spaces have the choice of taking an option card instead of repairing any damage. (Option cards modify the rules according to the instructions printed on the card.) Also, any robots which are still in virtual mode and are not occupying the same space as another robot are changed to real mode.

6.5: WINNING

The first robot to tag all of the checkpoints, in order, wins. The game may continue as long as desired to determine runners-up.

7: Interpretations of Common Rule Misconceptions/Ambiguities

7.1: SETUP

Q: Is there a specific procedure used to choose and set up the boards?
A: No. There is an example provided for setting up four boards in a 2x2 configuration, placing one flag per board, and picking a specific starting location. However, I suspect that the rules are specifically vague about setup to allow the players to do whatever they want. Practicallity dictates that it at least be possible to complete the race course.

Q: Where should the robots start?
A: The rules state that the starting location must be on an archive location. The practical reason for this is that if/when a robot is destroyed, it must have a place to which to be restored.

Q: How should the flags be set up?
A: The rules suggest that there be one flag per board, and that no flag "be placed in a corner formed by two or more walls." Additionally, since there are no provisions in the rules House Rules below) --> for handling flags on a belt, in front of a pusher, under a crusher, or over a pit, that no flag be placed in any of those locations.

7.2: BELT MOVEMENT

Q: When moving onto a turning belt under its own power, is a robot turned?
A: No. The turning action of the belt is active only during the belt-movement phase.(*2)

Q: When being pushed onto a turning belt, is a robot turned?
A: No. The turning action of the belt is active only during the belt-movement phase.(*2)

Q: When moved onto a regular turning-belt under power of a high-speed belt during the first phase of high-speed belt movement, is a robot turned?
A: Yes. This is in direct contradiction to the Factory Floor Guide, but is a rules clarification that was posted by J. Michael Davis.(*2)

7.3: FIRE CONTROL

For these questions, it is assumed that the robot that is able to fire has the fire-control option card:

Q: When targetting a register, is a point of damage done as well as locking the register?
A: No. The option card says "When scoring damage, you may: lock register, destroy option, or do normal damage." Use an inverted damage chit to designate a locked register without damage.

Q: When using a double-barrelled-laser, what are the targetting options?
A: It is treated as two different shots, but they must both be to the same area. (i.e.: You may cause two points of damage, target two options, or target any two registers.) If not treated as two separate shots, then it is no different from the high-powered-laser.

Q: When the other person has a shield which would otherwise block the damage (i.e.: shield (in correct facing) or power-down-shield (while powered down))?
A: Fire-control is only effective when it would normally be able to cause damage, therefore, no damage can be done in this case.

Q: What if a high-powered-laser is used is used against a shield?
A: The shield blocks the first point of damage, but the second point gets through and may be targeted.

Q: What if both high-powered-laser and double-barrelled-laser are used?
A: It is treated as two different shots which hit, but they must both be to the same area. (i.e.: You may cause four points of damage, target two options, or target any two registers.)

Q: What if both high-powered-laser and double-barrelled-laser are used against a shielded robot?
A: It is treated as two different shots which hit with one point of damage per shot getting through, but they must both be to the same area. (i.e.: You may cause two points of damage, target two options, or target any two registers.)

Q: What if the target robot has ablative-coat?
A: Treat the same as a shield until three points of what would normally be damage has been accumulated.

7.4: OTHER OPTION QUESTIONS

Q: What happens when a robot is destroyed?
A: When a robot is destroyed as a result of any cause, the robot is immediately removed from the board. At the beginning of the next turn, the robot it placed on the board at the last archive location tagged.

Q: Since an option is lost when a robot is destroyed, does having the superior-archive-copy option do any good?
A: Yes. It is a `superior archive copy' and not a `superior restoration'. This can therefore be interpreted to mean that you may still restore your robot without damage to the last archive location that you tagged while you had the option, but only as long as your robot hasn't tagged any other archive location since then.

Q: Can a robot move such that the robot remains at the same double-wrench site turn after turn and collect an option for each turn ended there (i.e.: become a `robo-monster')?
A: Yes. But only if your robot is powered up. (Confirmed by J. Michael Davis in a Usenet posting that I didn't save.) This is called `sit and spin'. (See RoboMonsters below.)

Q: Is there any limit to the number of options that a robot can acquire?
A: No. Paraphrased from postings by J. Michael Davis: "This is a race game. If a player wants to waste turns not going anywhere, then that's fine." (See RoboMonsters.)

7.5: OTHER QUESTIONS

Q: What happens when a robot is destroyed?
A: When a robot is destroyed as a result of any cause, the robot is immediately removed from the board, and a life token is surrendered. At the beginning of the next turn, if the robot has more life tokens, the robot it placed on the board at the last archive location tagged with two points of damage. The player may return powered-down for the rest of the turn and have all damage repaired.

Q: If I chose to power-down next turn, but I am destroyed during this turn, am I still required to power-down next turn?
A: The manual says that you may "chose to start powered-down when withdrawing an archive copy." This option overides the declaration of powering-down.

8: House Rules

The above interpretations are an attempt to provide a definitive interpretation of cases which are ambiguous or obscure according to the included rules. I've also included answers to questions that I had problems with when I was first learning to play. Not everyone agrees with these interpretations, or there are different rules which may work better in your group. You may also use the options to handicap players. New players should always receive some sort of handicap to give them a chance when competing against the more experienced players. Handicaps can also be given so that consistent winners will have more of a challenge. You could even give everyone a different handicap to make the game much more interesting.

8.1: SETUP OPTIONS

_RoboRally Cubed_: (Originally called _3D RoboRally_, but this is less descriptive.)

Arrange six boards in a cross (or any other arrangement that can be folded into a cube). Play be the normal rule except that the factory floor is considered either inside of a large cube (i.e. every board edge is attached to another board edge somewhere on the configuration). If you are playing on the outside cube then lasers do not cross board boundaries (the don't turn corners). If you are playing on the inside of the cube then lasers only cross board boundaries to the first row of across the boundary. Be very careful when moving around the corners of the boards, it can be very confusing.

8.2: LEADER BREAK-AWAY SYNDROME

In a normal game of _RoboRally_, all of the robots begin together but tend to quickly spread out. The robots which are able to break away from the pack receive less disruptions and therefore generally progress much more quickly toward the next goal. This is known as `leader break-away syndrome'.(*3) In my first game with more than five players, we had one flag per board in a 2x2 board configuration. By the time I had tagged the first flag, five other players had already tagged it, the leader had already tagged the second flag, and the second player was 90% of the way to the second flag. Even from this far behind, I managed to be the third to tag the second flag, and second to tag the third flag. I tagged the fourth, and last, flag two phases ahead of the player just behind me. While this demonstrates that it is possible to still win with such a disadvantage, it is still very difficult. (I've never won from so far behind again.) This is an option devised to combat `leader break-away syndrome': The Dice Rule Each flag is `blockaded' with a die (e.g.: a six-sided die). No robot may tag (even with the mechanical arm) or move onto a flag space (treat as having a wall on all four sides) until the die has been destroyed. Each die can take damage just as would a robot until the number of points of damage shown on the die have been accumulated. (When taking damage, the die itself should be turned to indicate the number of points remaining until it is destroyed.) When the blockade is destroyed, it is permanently removed from the board. The flag may then be tagged as normal by all subsequent robots. This tends to slow down the leaders until the other robots can catch up. However, it is not a random effect but is highly tuneable.(*4)

8.3: ROBOMONSTERS

Whenever a robot ends a turn on a double-wrench site, the player has the option of choosing to repair two points of damage or drawing an option card. Since a robot has the option of ending each and every turn on a double-wrench site, robots can quickly gain a number of options. Such a robot is called a `RoboMonster'. J. Michael Davis sees no problem with unlimited gaining of options. While theoretically, this is a race game and gaining options wastes time, in practicality some people (including the ones with which I play) see problems. These are some of the ways devised to deal with `RoboMonsters'. Installing Options Rule When installing a new option, a robot takes as much damage as it has pre-existing options. (e.g.: a robot with no options will take no damage, but a robot with five options will take five points of damage when installing a new option.) This causes a practical limit of gaining new options to about every other turn while robots power-down to repair damage.(*4) No Sit-And-Spin Rule A robot may not gain more than one option at a double-wrench site until that robot has tagged at least other wrench or double-wrench site. While it is still possible to get one option per turn by going between two close double-wrench sites, in practice, this does greatly limit the number of options gained.

8.4: OTHER VARIATIONS

One Free Life Rule A player gets his first life for `free'. (i.e.: The first restore is done without receiving any damage.) This is a good option to give to new players.(*4) Infinite Lives Rule This rule simplifies the game, and removes the worry that someone get knocked out due to `N' unlucky deaths.(*4) There is still a penalty because the robot must be returned to the last tagged archive location. One Free Option Rule At the beginning of the game, each player draws a free option. This makes the game more exciting from the beginning.(*4) Secret Options Rule Any options drawn are kept face-down until used. This makes the game more surprising, suspenseful, and unpredictable.(*4) The Three Minute Rule Each player (except for first timers) has no more than three minutes to program one's robot. After three minutes (or some other agreed-upon arbitrary time limit), a late player's program is completed by (another player) randomly drawing from the player's unplayed cards (without looking) to fill the empty slots of the player's program. This speeds up play, and makes the game more exciting because of possible program errors.(*4) Be aware that some players can get nasty when this rules is enforced on them.

8.5: Other games to play with _RoboRally_ components

_RoboArena_: Fight to the death. A variant played with no flags where the object is simply to eliminate all of the other robots.(*5)

_RoboBall_: Soccer with robots. The rules for this game (by Joseph Grace) are quite long (15KB), and are therefore not included here. They are available from http://www.gamerz.net/roborally/roboball.htm

9: Miscellaneous

9.1: _ROBORALLY_ HOMEPAGE

Wizards of the Coast has created a _RoboRally_ homepage which is located at "http://www.wizards.com/RoboRally/". It provides authoritative answers some questions about _RoboRally_.

9.2: _ROBORALLY_ NEWS

In October 1995, Wizards of the Coast will be releasing a new version of _RoboRally_ "with minor revisions". They will also be releasing an expansion set with more boards with different types of floor spaces and rules to deal with the new spaces.(*6)

9.3: REQUESTS

It would be nice to have a site that is willing and fairly accessible to keep a small amount of _RoboRally_ material for at least a couple of years. This material would be FAQ, house rules, other games, additional boards (when they are created), etc.

10: Endnotes

1. Due to an what I assume was a mistake in printing, there are two cards which have the number 500. I heard about it in discussions on Usenet, and have since verified that the same is true in my set. These two cards have never been noticed in the same turn in any games in which I have participated. If there is ever a timing conflict, each player should pick a random card from the deck of remaining cards, flip a coin, or otherwise determine which card should be treated as having higher priority. It could be determined by mutual consent without revealing remaing programmed registers, but that's not arbitrary enough. ;-) I have also noticed that in my set, there is no card with the number 600. This is probably due to the same printing error.

2. The rest of this note is the relevant part of a message sent to me by Joseph Grace (jgrace@netcom.com): OK (found it) , here is the answer from an October 27[, 1994] post by J.M.Davis: IF A CBELT MOVES YOU ONTO A CBELT WITH A TURNING ARROW YOUR ROBOT ALSO TURNS (in the direction of the arrow). IF YOUR ROBOT MOVES ONTO A CBELT WITH A TURNING ARROW BY ANY OTHER MEANS THAT CBELT ACTS LIKE A NORMAL CBELT. This is in contradiction with what the factory floor guide says. If a fast belt moves you onto a slow belt in the first belt movement Since you wrote the rules, I suppose we should take the above as a rules clarification? yes, most definately take the above as a rules clarification. I also wrote most of the floor guide. My bit about cbelts got cut for space reasons I imagine. My "turning cbelt" section showed the two cbelts, including the belt just before the one that the current FFG shows. Everything on my FFG is laid out like "If you're on a square that looks like this, this is what you do". On the current FFG, the turning cbelt is different,it says "If you END UP ON A SQUARE that looks like this, AND you got here by THIS means THEN this is what you do".

3. While Joseph Grace (jgrace@netcom.com) was probably not the first to notice the effect, he was the once to coin the term 'leader break-away syndrome' and to begin to use it on Usenet.

4. These variations have been paraphrased from a Usenet posting by Joseph Grace (jgrace@netcom.com). 'The Dice Rule' and the 'Installing Options Rule' are rules which he devised. The text of the original posting is available at "http://www.kdcol.com/~val/games/RR/RRUsenet-JG.html".

5. We've been discussing a RoboRally game variant with no flags where the object is simply to eliminate all the other robots. Has anyone tried this yet? Various rules we've been thinking about for this include no shut-downs (but players could kill themselves if trapped due to locked registers) and various restrictions on options. What do people think? -- proposed by Charles Sumner, sumner@bu.edu We've played this way, with 4 robots starting on the 4 corners of the Maelstrom board (which was the only board used). We allowed shutdowns, but on this particular board shutting down was often more dangerous than remaining powered with a few locked registers. Worked out pretty well, inasmuch as it provided a satisfactory afternoon's enjoyment. -- LeonHard Gumbo, gumbo@virtu.sar.usf.edu

6. From a posting by Charles Keith-Stanley (of Wizards of the Coast) following up to W. Craig Trader and Robert L. Cannon available from "http://www.kdcol.com/~val/games/RR/NewVersion.html". Robert L. Cannon more recently reported that the release has been delayed due to production problems mostly due to casting the figures in one piece and deciding if they should be plastic or metal. The text posted to Usenet is available from "http://www.kdcol.com/~val/games/RR/RRUsenet-RLC.html".

11: List of Contributors

Thanks to the contributors of questions and answers in this FAQ. I have tried to give appropriate credit, but if I have missed someone, I apologize. * Richard Garfield for having created _RoboRally_. * J. Michael Davis (email address to be added later) for having helped (or more) in having created _RoboRally_, and being available on Usenet to make some rules clarifications. * Joseph Grace (jgrace@netcom.com) for many suggestions on my preliminary FAQ's, providing the relevant text of the message above from J. Michael Davis, and making a posting of a collection of house rules. (Sorry for missing the original messages on those which were posted to Usenet.) * Richard Rognlie (rrognlie@netcom.com) for having suggested that fire-control only be allowed to lock a register without causing damage. * Mark Biggar (mab@wdl.loral.com) submitted via email the text for _RoboRally Cubed_. * Charles Sumner (sumner@bu.edu) for having suggested _RoboArena_. * LeonHard Gumbo (gumbo@virtu.sar.usf.edu) for having made a relevant comment about the _RoboArena_ idea. * David Kass (dkass@portia.caltech.edu) for having caught and corrected a timing error which I made in the movement of express conveyor belts. * W. Craig Trader and Robert L. Cannon for having posted information on the new version of _RoboRally_. * Charles Keith-Stanley, Cyberspace Liaison, Wizards of the Coast, Inc. (liaison@wizards.com) for confirming information on the new version of _RoboRally_.

12: Glossary

Archive location A space with a wrench, double-wrench, or flag on which a robot is restored after being destroyed.

Real mode The mode in which a robot may be pushed, shot, and otherwise affected by other robots. The pewter figures are used to indicate real mode.

Virtual mode The mode (only possible when being restored to an archive location) in which a robot may not be affected in any way by other robots. The cardboard counters are used to indicate robots in virtual mode.