Last updated 16 April 2001

Programmer's Nightmare FAQ

Welcome to this FAQ. If you have any new questions, please e-mail them to me, I am always happy to receive questions to help improve the playability of a game.

IMPORTANT ADDITIONS TO THE RUN AND BREAK RULES FOR V1.1 and V1.0 These changes don't actually exist in any version of the rules yet, and have no effect on the deal-the-cards-in-a-circle version of the game, but you might want to print this part out anyway! These changes are due to a suggestion by Peter Sarrett that the RUN and BREAK cards, if they didn't happen to be in any player's hand, could really hose up a game, so these are the fixes for Version 1.0 and 1.1.

RUN occurs automatically at a 20-card length, and continues until one player is the winner, or all players decide that the game is a tie. No BREAKS may be played after 20 cards are out.

The player who plays a RUN may verbally BREAK the program any time after the program has completed a loop (that is, at least one command is about to be executed a second time).

A player may BREAK a program by spending 3 life-points, but it still cannot be broken until the program has looped around once.

End of Important Rule Add-Ons for V1.1, Clarifications to Cards and Other Rules Below

"Are tokens which are added to a card used immediately if the Program Counter is currently pointing to the card?" No. This question arose from a MULTIPLIER, ACQUIRE, COPY sequence, where the player felt that the COPY, when executed, would get a new token, which would execute again, and get another token, etc, in the meantime acquiring an infinite number of points. This is not the case. New tokens which are added to a card to which the Program Counter is currently pointing do not execute that instruction until the program has looped entirely around and come back to that instruction.

BIT MOVER; If this card is incremented, +1, you may move any 2 bits from any two separate cards, or the same card, onto any cards adjacent to those 2 cards. The Bits are not required to be on a single card initially.

"Can BREAK be used if an instruction is executed a second time by a COPY, or an instruction is executed a second time by a duplicate of that instruction?" No, the intent of this rule is that the BREAK cannot be used until a specific CARD is used a second time, not merely something that immitates that card's instructions.

BITS, CARDS WITHOUT THEM; Cards without bits on them are not executed when the Program Counter comes around.

BREAK RULES ERROR IN V1.1 In the general rules BREAK can be used either as a one-shot or built into the program. In the card description listing, I said it can only be a one-shot, which is incorrect, it can be both. This was corrected in Version 1.1 of the rules.

COPY; Instructions VS Commands; Evidently I describe COPY in terms of Commands previously executed, or Instructions previously performed, which leaves some room for ambiguity. To put this to rest, COPY copies the last two cards in the sequence, regardless of whether or not they were actually executed.

DEFEND; This was changed a little between version 1.0 and 1.1. In the newer version, it DEFENDS against the next 2 "executed" cards, leaving out the question of its location in a SUBROUTINE. If a SUBROUTINE is one of the 2 executed cards, the defense also works against any cards in the SUB.

Another question arose with respect to the DEFEND against lost Bits, in the event that the Bits are lost due to ERASE killing a command, which indirectly loses the Bits on the lost card. This would best be explained by changing the words on the card "...lost bits from the next 2 executed instructions" to "...Bits removed from cards by the next 2 instructions". Bits that are on cards that get destroyed are not protected by DEFEND.

DELETE; Say Yellow and Red are on a DELETE card. Yellow executes first on the card, removing the Red token. Does Red get to use the DELETE, also?" Answer; No, Red does not. He was removed before he got a chance to execute the card instruction.

FUTURE; See COPY, it works exactly the same, but in reverse. Also see UPGRADE for what happens when you FUTURE an UPGRADE.

FUTURE also has the potential of affecting it's own second command, as does COPY. The first command can destroy or otherwise affect the second command before it gets executed, in which case the new or modified instruction becomes the second instruction.

GOTO; I didn't like the way this command worked. In Version 1.1, it changed to say "Move the Program Counter forward 6 cards". This way, it will always have an effect on the game. As it was in Version 1.0, it almost never had any effect.

In the latest version 3.0, if the command to which GOTO is pointing is discarded, the GOTO is "reset" and may be linked to a new command next time it's used.

MULTIBLE BITS ON A SINGLE CARD; Each player that owns a bit on a card gets to decide, in order of who was there first, whether or not to execute that instruction. If two people have bits on a REVERSE, and the first person reverses the program direction, the second player with a bit on the card might just reverse it back the way it was going. If two people are on a DELETE card, and the first player deletes the second player's bit, then the second player never gets the chance to execute that instruction. If a single player has multiple bits on a card, he/she gets to execute that card multiple times.

NEW BITS; When the creation of new bits is called for, these are taken from whatever supply is available from the tokens that came with the game; once the program is running, you are not limited to the few you started with.

PROGRAM ERROR; Bits placed on PROGRAM ERROR come from the general supply, not the tokens that a player starts with. Also, these should be played before the last claim-Bit a player has is placed. You can't play one after your last claim-Bit is placed. This has been changed from version 1.0, which drew the token from the player's playable tokens, not from the general stock.

SEQUENCING OF ACTIONS; There is some confusion about whether some actions occur simultaneously or not. To clarify, there are no simultaneous actions, everything is a serial sequence. If there are 2 Bits on a card, the first one there executes first, potentially removing the second one before it can execute the command. FUTURE and COPY can potentially change the second command that they copy before it executes, as can SUBROUTINE. When the POINTER gets to a card, only the Bits already there at that moment can execute, not ones added during the card's execution. This will be explicitly added to the RULES in the next edition (a few years from now).

SUBROUTINE; I've recently changed this; COPY and FUTURE and POINTER do not "reach out" of a SUBROUTINE, if they are inside. GOTO does "reach outside", and the count starts at the SUBROUTINE in the main program. Position based commands, such as FLOATER and SWAP INSTRUCTIONS, are limited to cards and positions within the SUBROUTINE.

Due to the confusion that SUBROUTINE causes, it will very likely be removed from the next edition of the game. Feel free to remove it from the game if you like.

UPGRADE; If you FUTURE or COPY an UPGRADE, and the UPGRADE is the first instruction to execute of the two, then the bit color on FUTURE or COPY will change before you have a chance to use the second instruction. On the other hand, since you've already executed the FUTURE or COPY, the new person on it HAS NO CHOICE but to complete its execution. This is handy if there's a PROGRAM ERROR there.

Where UPGRADE says "Pick a place..." on the card, this means you pick a spot between two existing cards, you are NOT replacing a card.