Re: [piecepack] Game mechanic idea: robot programming with piecepack coins

[Mark Biggar <mark.a.biggar@...>]

Here is an updated version of my essay on programmed movement using
piecepack coins.  Please comment.
Thanks
--
Mark Biggar
mark.a.biggar@...
  ----------

Programmed movement in Piecepack games.

There are several games that use a movement mechanism 
where the player programs his next several moves from 
a possibly limited set of options and is then locked 
in to those moves until they are finished at which 
point the player programs a new set and so on.  This 
mechanism is used in the games Roborally, "Dragon Delta" 
and as a method of simulating fencing in the '70s RPG 
"En Guard".  I would like to discuss using piecepack 
coins as program steps in a "Roborally" like game.

The programming method used in Roborally heavily depends 
on the fact that the robot miniatures used in the game 
have an obvious front.  Turning in place makes no sense 
if your piece has no distinguishable front.  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, 
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 discuss using unmarked pawns and then talk 
about systems that use pawns with marked front sides.

Each round a player selects 3 or 4 coins to represent 
what the players 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 use.  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 are program steps that cause the pawn to 
move that number of spaces in a straight line specified 
by the direction of the tick on the coin.  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 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 
will again secretly select a new set for the next round.

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 pawns 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 of 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 or Tom's Pyramids that have 
an obvious front then turning in place without moving 
makes sense.  One option for marking pawns is to place 
them on top of a coin and use the coin's tick mark to show 
the pawns front side (of course you then have the problem 
that that may not be very stable and could get knocked 
over or misarranged 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.

For marked pawns the coins could have the following 
meanings:  Number-side up could mean move that many squares 
forward, with ace meaning 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 upcoin 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 cost two movement points per space moved, while 
freely moving only cost 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, 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.
 
Thanks for your consideration and I hope that this leads to 
some interesting discussion.