Programmed Movement in piecepack Games

There are several games that use a movement mechanism where the player plots his next several moves from a possibly limited set of options. The player is then locked in to those moves until they are finished, at which point the player programs another set of moves and so on. This type of game also usually allow for simultaneous movement when there are no conflicts between the various pre-plotted moves. This mechanism is used in the games Roborally, “Dragon Delta” and as a method of simulating fencing in the '70s RPG “En Guard”. This Essay is a discussion about using piecepack coins as program steps in a “Roborally” like game.

Pawn Facing and Programming

The programming method used in Roborally heavily depends on the fact that the robot miniatures used in the game have an obvious front facing side. Turning in place makes no sense if your piece has no distinguishable front side. With the current piecepack design, pawns do not have a marked front side. I know that there has been previous discussion of modifying the piecepack definition to add a mark to each pawn so that they have an obvious front side, similar to the tick marks on the coins. But as the current pawns are not so marked, any programmed movement system will have to take that into account and either add front marks or will have to work with frontless pawns.

First I’ll describe a system using unmarked pawns and then talk about systems that use pawns with marked front sides.

Unmarked Pawns

Each round a player selects 3 or 4 coins to represent what the player's pawn is to do for its next few actions. One or two coins doesn’t lock the player in enough, while 5 or 6 is too many, given that each player (in a four player game) only has 6 coins to play with. The coins are selected in hiding (probably behind your hand) and placed in a line in the order to be executed. Coins number-side up (ace, 2, 3, 4 or 5) are program steps that cause the pawn to move that number of spaces in a straight line in the direction specified by the tick on the coin. To prevent confusion and arguments, the tick mark on a coin should point in a direction relative to the board not the player. A blank coin specifies the pawn does some special action (determined by the game being played). Coins suit-side up cause the pawn to fire its weapon (or use some other game specified directional action) in the direction of the tick. After all players are satisfied with their programs, the coins are exposed and executed simultaneously in order (the game will specify a method to resolve conflicts). When all the program steps are completed, each player again secretly selects a new set of program steps for the next round.

The Effects of Damage on Programming

One possibility for when a pawn takes damage is for the owning player to select a coin to put aside and then he must program subsequent rounds with fewer coins. If a player has fewer than the needed number of coins available, one or more of his pawn's actions would be to sit and do nothing for that action turn. When a robot’s last coin is gone the robot is destroyed (whether or not it may reenter the game depends on the game rules: in a Roborally like game, “yes”; in something like a Battlebots game, “no”).

Using Marked Pawns or Pyramids

If you are using marked pawns, pawn saucers or Tom’s Pyramids, that have an obvious front side, then turning in place without moving makes sense. If you don't want to mark your pawns and don't have pawn saucers, then one option for marking pawns is to place them on top of a coin and use the coin’s tick mark to show the pawn's front side (of course you then have the problem that that may not be very stable and could get knocked over or miss-arranged while moving the pawn.) Most likely you would want to use the 5 or blank coin for this purpose, depending on what options the game designer wants.

When using marked pawns the coins could have the following meanings: Number-side up could mean move that many squares forward, with ace meaning move one square and possibly the blank meaning move backwards one square. Coins, suit-side up, could mean turn your pawn to face the direction denoted by the tick. If you want weapon fire in your game, then a suit-side up coin with the tick pointing in the same direction as the pawn already faces could mean fire its weapon forward, or, if you want automatic weapon fire on every turn (like in Roborally), that could mean use a special action instead.

Conflict Resolution

It will often turn out that the programmed action of two or more pawns conflict; e.g., they both want to enter the same square. The designer of a game must provide rules to resolve these conflicts. One problem is what happens if a moving pawn is ordered to move into the same space as a stationary pawn. There are several options: the moving pawns could stop in the space before the stationary pawn, it could move through the stationary pawn, or it could push the stationary pawn ahead of it. Pushing another pawn may or may not cost the pusher some it its movement; e.g., pushing another pawn costs two movement points per space moved, while freely moving only costs one point per space. The game designer must also decide if pushing damages either or both pawns.

More complicated situations require the game designer to provide rules to serialize the ordinarily simultaneous pawn movement. Some possibilities are: roll dice to determine who moves first (or who decides the order), using position to determine order (e.g., the farthest from the goal moves first), or have the player priority go around the table with the highest priority shifting one place every round.

Comments

Thank you for reading my essay. Please add any comment on this essay here. -- Mark A. Biggar

Other Programmed Turn Ideas

I'm very new to piecepack (I just printed a set and am waiting for glue to dry) but I am a big Robo-Rally fan and have played other games with programmed movement. It's a game mechanic I like.

Some other programmed mechanics would work with piecepack. Here are a few examples:

• combo moves: you have to put in three "phases" with your six coins, but you can use 1, 2, 3, or 4 coins per movement. This would likely entail some sort of teleportation or "hop" because piecepack would not let you (easily) show a path of "2 right, 1 bottom" so that interaction between pawns could be covered. An example game might be based on something like, "if you use one coin, you are only damaged if someone lands within your square; two coins, you take two points of damage if someone is in your square or in an adjacent square; three coins, three points if within two squares; and automatically destroyed if you used four coins and someone was within two squares."
• colored combos: a two-player game using four or more suits could use coins of one suit for forward movement and another for reverse or some other programmed element. An example that springs quickly to mind would be to have one color move you and another represent the direction and length of your destructo-lance. This would particularly be suited to games that used directionless pawns.
• energy budget: movement is not the only thing that could be "programmed." It might be that you could use coins for movement or for energy. Perhaps you could "buy" special movement options by paying with unused movement tokens, and the special option would take place when the null coin was used.
• movement codes: using two suits, it would be possible to come up with a table of 36 special moves, and the player could pick three moves. This could also be done using one color or you could allow a player to use more than two digits and derive special significance: E.g., one digit continues last direction; two turns as indicated by coin B and moves A squares in that new direction; three will make a pawn go insubstantial during one of the movement square C (and turn/move B,A) allowing the token to pass through walls; four enters "fly" mode and skips over pits; etc. during turn/move D
• phase-variant movement: in Robo-Rally, there are always five movement "registers" per turn. I have played other games that based the number of "phases" on some other characteristic, such as the velocity. In the case of velocity, if a player Alice moved 6 squares and player Bob moved 3, any potential collision would be determined by moving Alice two squares per square moved by Bob. If Bob entered either square traveled by Alice during a phase, a collision took place. (It still works for combos like 4 and 3, but it gets trickier and uses a "least common multiple" phasing system.) Something similar might be done with the coins, particularly with one of the combos mentioned above. E.g., I get 6 coins and I can have 6 phases of one coin, 5 of one and one of 2, etc.

The point I am trying to emphasize is that programmed movement can take not-so-obvious forms, and that it would make a good feature in a game even if it did not apply to movement per se. Like in the "En Guard" you cited as an example, these can be maneuvers, actions, etc.

Now... Go make me a game! Ken Comer

Already did. See my games Everest and Chariots -- Mark A. Biggar

8Bit Box

I just noticed that this mechanic is being used to program the ghosts that follow pacman in a maze using the 8Bit Box board game controllers in this video https://www.youtube.com/watch?v=XZRs634Ww1A

DanielAjoy