A few months ago, I wrote about an idea for a game based on transactional moves. I just played a board game tonight (something about vampires) at GameDev which used the lag effect well. It sparked that idea again, so I fleshed out the details and made a game. Namaste and I played a round of it, and it is pretty good in concept. It needs a few tweaks, and I will discuss the way we played it along with the tweaks I am considering. Overall it was a deep strategic game.
There are two players (I plan on generalizing to more) who play on a graph. The graph we used had about 45 nodes and 40 edges. Each edge was marked with a unique identifier (such that starting from any node, you could uniquely identify an edge connected to that node; I used numbers from 1 to 5, nothing higher was necessary). I wish I could show the board, but I don’t have a camera. Each player had three “supply centers” (a la Diplomacy) and three units. Supply centers were special nodes which lay at the coasts of the graph.
On each turn, a player could move one unit to a connected node. No two units can occupy the same node; moving in to a node where there is already a unit is illegal. You may move into supply centers that you own, but not that the opponent owns. In order to conquer a supply center, you must attack with strength greater than their defensive strength — Diplomacy style with support orders. I’ll cover the details of that in a bit.
The interesting twist: each player keeps a private pad of paper. On your turn you write down an order on your paper identifying a move (for example, I would write A3 which meant unit A moves over edge 3 connected to its current node). This represents a command in a “transaction”. After you have written down a move, you have the option of “committing” all the moves you have thus far written: you scratch them out on the paper and execute them all in a single turn, in order. However, if the opponent commits a transaction which involves (either enters or leaves) a node which your transaction involves, you scratch out all the moves in your transaction. You lose those turns. You may also voluntarily abort an entire transaction. Of course, a transaction which is just a single move and a commit need not be written down.
To attack a supply center which is defended with strength n (how that is done I wll say in a moment), you move n+1 (or more) of your units adjacent to it. Then, for all but one unit, you write a “support” order in a transaction (if this is committed before the final attack is made, the support orders do nothing). For example, “AS3″ meant “unit A supports the attack against the node over edge 3″. After all the support orders are complete, a move into that supply center may be issued into the transaction. When the transaction is committed, the move is made and the player who made the move takes control of that supply center.
The defensive strength of a supply center starts at 1. If there is a unit inside the supply center, add 1. For every unit belonging to the owner of the supply center adjacent to it (connected by exactly one edge), add 1.
A special case: when a player gets down to one supply center, he loses a unit and his opponent gains a unit. The player who has 1 center selects a unit, which will from now on be controlled by the opposite player. If the losing player gains another center, then the same unit switches back to his control.
That’s how Namaste and I played it. It might have been the level design (very important), but the game felt a little bit “rigid”. It was too easy to trap units, and it was too easy to hold choke points. So I plan to add the ability to dislodge units (a la Diplomacy again), and also to make all supports automatic. So all you have to do to take a supply center or dislodge a unit is to have more adjacent units than the opponent does. This will make it harder to hold choke points. I also plan to make the graph a bit more dense: a larger edge/node ratio. This will make it easier to navigate the map, since one of the problems is that it took so long to get from one side of the map to the other; however I would still like an interesting topological structure, as opposed to a simple lattice. I also plan to add more units and possibly supply centers, since one of the problems was that it felt like you needed to engage your entire (three-unit) army to take a supply center, leaving you defenseless.
I plan on a networked computer implementation pretty soon. It should be pretty easy to write.