Power Grid’s market system with the two layers of plants is interesting and provides a deceptively large degree of control and prediction. It really is quite clever while presenting a surprisingly predictable pattern. Space Race has the problem that while it models something akin to the 18XX train rusting progression, the intended sequence is so short (3 layers) that incentivising player progression is worse than tetchy. I’m not sure I can learn from Power Grid here, but it is tempting.

A possible address is to model the total productive capacity of the system, to cumulatively sum the total production to date. As that total production volume crosses pre-set thresholds the next layer becomes available and of course as the third layer is entered all level 1 factories rust. This could essentially arithmetic sum could be modelled in several ways, actually tracking total production volume as a calculated sum or simply having bits from a limited supply which are discarded as they are used¹.

With such an approach it becomes tempting to add a fourth level of factory, a pure consumer. We could call it the Centre Of Government or some such silliness (themed after Asimov’s Foundation universe?). It would either be notably expensive or force auctioned at another production volume threshold. There would be only one CoG, and while it wouldn’t necessarily rust the level 2 factories² it would consume both level 2 and level 3 goods until the end of the game, with all fees and payments recorded as usual for route-based deliveries. Variously interesting curves could be applied to the system. Perphaps the market value of the CoG pseudo-product would likely decline continuously, forcing a race between additional factory construction/operation, run-away CoG ROI and endgame acceleration? Similarly a race could be constructed between the level 2 and level 3 factories based on the game-length required for equivalent profit volume³?

Such a system has advantages. The level 1 factories would be (mostly) unprofitable but failing to buy into them would allow those that do to be extremely profitable and to have undue leverage into the level 2 factories and economy. The real value of the level 1 factories would be to establish market relationships for exploitative level 2 factory upgrades which would actually be profitable. This would of course also require ensuring a limited supply of Level 2 factories (possibly by spacing rules rather than count?). The level 3 factories would then be similarly constrained⁴. And likewise for the level 4 CoG factory: placement constricted by neighbourhood. Such placement rules could be quite interesting and offer an attractive short-long planning aspect.

Methinks I should spend more time in the shower.

I generated a 7-depth Penrose tiling last night. It took most of the night.

Axiom:
  [N]++[N]++[N]++[N]++[N]
Rules:
  M=OA++pA—-NA[-OA----MA]++;
  N=+OA–PA[---MA--NA]+;
  O=-MA++NA[+++OA++PA]-;
  P=–OA++++MA[+PA++++NA]–NA;
  A=
Angle:36

The tiled SVG’s generated by the L-System are prone to very high rates of duplicate elements. They’re also extremely slow and system intensive to process under Inkscape as the entire graph is rendered as a single bazillion-point object. Handling the performance problem is simple enough: Inkscape/Edit/Select_All and then break up the object with Inkscape/Path/Break_Apart. Ahh, much better.

Handling the duplicates is tougher. There are simple duplicate elements, PATH elements with identical attributes and vertices and there are path elements which are identical except that they list the vertices in a different order. The former are easy to remove. Just fold the raw XML document so that all PATH entries occupy but a single line, sort the PATH elements and then remove all duplicates. In my case I just extracted the PATH elements to an external text file, wrote a quick XEmacs macro to make each PATH element single-line and then did:

$ sort outfile.xml | uniq 

Voila! All identical PATH elements removed. This simplistic dupe-removal reduced the file size by approximately 30%.

I looked at removing the duplicate-vertex elements but found it too hard for a quick hack fix. In short I’d have to extract all the path elements and then the vertices for each element, sort them and then do duplicate removal. That was more than I was willing to be bothered with. However while wandering the data I noticed that there were many 7 vertex elements whose vertices precisely overlaid the vertexes of other elements (exception: a small few elements at the edge of the graph). With the exception of the ones at the edge of the graph, they were all redundant. Remove them:

$ grep -v "path.*M.*L.*L.*L.*L.*L.*L"  outfile.svg

While a plain white mesh is pleasantly clear, I had the idea of colouring the tiles to give a bit of a stereoscopic effect.

The effect of which is to assign a fill colour to two thirds of the elements, a different colour for each third

I like it.

I’ve been playing with the L-System support in Inkscape, generating Penrose Tilings. Damn this is clever neat nifty fun!

Axiom: 
  [N]++[N]++[N]++[N]++[N]
Rules:
  M=OA++pA----NA[-OA----MA]++;
  N=+OA--PA[---MA--NA]+;
  O=-MA++NA[+++OA++PA]-;
  P=--OA++++MA[+PA++++NA]--NA;
  A=
Angle:36

Just drop that into Inkscape/Effect/Render/L-System (put all the rules on one line) and you should get this:

Increase the Order value and it will iterate more, drawing a larger graph. Be careful though as execution time grows exponentially as the number of iterations grows.

Some other L-system-derived graphs produced with Inkscape:

Axiom:
  f
Rules:
  f=-f+f+g[+f+f]-;
  g=gg;
Angle: 60

Or perhaps more entertainingly:

Axiom:
  W
Rules:
  W=+++X--F--ZFX+;
  X=---W++F++YFW-;
  Y=+ZFX--F--Z+++;
  Z=-YFW++F++Y---;
Angle: 30

Yes, that’s a single continuous line in what is known as a space filling curve. Wander about Wikipedia or with a search engine and you’ll find many other little L-system programs for other tilings or space filling curves. Plug them in and play! They’re not only a heck of a lot of fun but such curious tilings can easily form the backdrop for interesting games and there are many many such interesting patterns.

I’ve been concerned about transactional density in Space Race. I’d like to have players (near) constantly having to pay each other for little actions and the sum of the current game state. Pay for this, pay for that, etc with all debts/payments recurring for every turn of the game after their inception.

This is a problem. There could easily be 20+ transactions per player in various directions. Of course many of those would more or less cancel. PlayerA plays PlayerB $17 and PlayerB pays PlayerA $14, for a net effect of PlayerA paying PlayerB $3. Of course the loop could be larger than that with all the other players involved in various degrees as the money sloshes about.

The obvious choice is simply polish all that detail out; figure out a way to remove all the accounting detail and yet let the game continue smoothly and with rich decisions. However, I’d like to not do that. I’d like to keep the net effect of all those hordes of micro-transactions without having to have the game support the overhead of hordes of micro-transactions. I intend the game to be severely cash strapped, so a few dollars or more draining out in one direction, turn after turn, is a big deal.

My first thought was that each player would have an income track containing markers for each other player. A player’s marker on a track would represent an obligation to play the track-owner that sum of money at the end of each round. As debt events occurred in the game players would synchronously move their markers up and down on each other’s tracks to represent the new balance of payments. However even this is too fiddly. A five player game would have 20 tracks (4 per player), each containing 4 debt markers (one for each other player), with two markers being adjusted for each debt-causing event. Further all this complexity doesn’t clearly represent or collapse debt cycles (eg PlayerA owes $5 to PlayerB who owes $5 to Player C who owes $5 to PlayerA for a net sum of $0). It also doesn’t clearly represent what the net sum of a player’s debt posture is. Each player would need to add the sum of their debts against the sum of their incomes. Fie!

The current thought is to simply have an income track for each player, centred on zero, say, running from -20 to +20. As debt events occur in the game players would move their income markers up and down as appropriate. Thus if PlayerA incurred a $5 debt to PlayerB, then PlayerA would move their income marker down by $5 and PlayerB would move their income marker up by $5. In a 5 player game this would result in 5 tracks, each with a single marker. All end-of-round payments would be to and from the bank. The net effect would be the same, money in sum moving identically to the more detailed system, but with the bank’s implied capital pool acting as a sump to simplify net transaction resolution.

As thoughts from the shower go, this one seems a keeper.

Turn structure

The base idea is a set of rounds, each round consisting of distinct phases executed in order by each player before moving onto the next phase or round:

• Construction
• Operation
• Resolution

Turn order is rotational. Start player moves back one space each round.

Construction

Players have 2 action points. Available actions:

• Purchase a colony (2AP)
• Cost dependent on level
• Place colony (1AP)
• Placement limitations:
  • 3 edges from nearest colony for level-1
  • 3 edges from nearest level-1 colony and 5 edges from nearest level-2 for level-2 colonies
  • 3 edges from nearest level1 colony, 5 edges from nearest level-2 and 7 edges from nearest level-3 for level-3 colonies
• Colony may upgrade previously placed colony by same or other player
  • New placement
    • Connected routes for new colony must pay docking fees of $2 per route in promissory notes to colony owner
  • Upgrade placement and new owner:
    • Previous owner gives promissory notes to new owner equal to half-cost of current docks
• All exploration bonuses leading to colony are claimed
• Spaceships present on node are docked (returned to player)
• Purchase and place factory (1AP)
• Cost is a function of level
• May be placed on other player’s colonies
• Factories come in three levels (1/2/3) and size (1/2/4) and produce goods of their ssize
  • Level-1 factories come in 3 primary colours
  • Level-2 factories come in 3 different secondary colours and accept their constituent primaries as inputs
  • Level-3 factories are black and accept any two different secondary colours as inputs
  • Sale price for a good is market price*size
  • Large(r) size goods can be delivered to small(er) factories where they count as a single input
• Placed factory may not be same colour as the input or output of a factory already on colony
• Sum of factory sizes on colony limited by level of colony (1/3/7)
• May upgrade previously placed factory for delta cost
• Placement of size-3 factory causes all connected size-1 factories to rust (removed from board)
• Advance travelling spaceship one edge (1AP)
• Double speed if on already explored edge
• Move docked spaceship to connected colony and advance one edge (1 AP)

Player’s travelling spaceships which are not advanced during turn are removed from the board along with the paths they explored.

Operation

The Operation phase is split into three steps:

1. For each player in turn order:
2. Produce products on all level-1 (input-less) factories
3. Move products across network to consumers - Pay for network transit per colour - Owner of product pays market price (forced) for product - May not delivery to factory if an input of that colour is already present
4. For each player in turn order:
5. Produce products on all level-2 factories that have both inputs
6. Move products across network to consumers - Pay for network transit per colour - Owner of product pays market price (forced) for product
7. For each player in turn order:
8. Produce products on all level-3 factories that have both inputs
9. Move products across network to consumers - Pay for network transit per colour - Owner of factory received market price from bank

Resolution

The Resolution phase is split into three steps:

1. For each colour of level-1 factories adjust the market price for that colour:
   • down if there are unshipped goods of that colour
   • up if all products of that colour were consumed to produce level-2 products
   • no-change if all products of that colour were shipped but not all were consumed
2. Each player now exchanges promissory notes with their owners to reduce the number of notes in the game to a minimum (trade a player’s promissory notes with that player for notes they hold of other players, repeat until no further exchanges are possible).
3. Each player pays all promissory notes other players hold of their’s.

Other

Preferably game ends when bank breaks.

I’m concerned that Operations and Resolution are horribly fiddly. Transaction density is a problem.

Basic patterns:

• Network growth is slow and beginning a spur commits the player for 2-3 turns as a failure to extend an incomplete link on a turn looses the spur
  • Network occurs on a penrose mesh
  • Growth spreads from central hub
• Reaching previously untouched nodes rewards money when the spur is terminated at a colony (cf Through the Desert tokens)
• Colonies (which are placed on nodes) cost both money and an entire turn to purchase, plus an action to place
  • Ergo colonies are purchased on spec and then placed as/when advantageous
• Like networks, colonies are owned by the constructing player
• Colonies can be upgraded/scaled by any connected player
  • The upgrader owns the big colony, the original builder the inner hub
  • Size of colony limited by number of connected colours
• There are placement distance rules for different size colonies
• Colonies may contain factories
• Factories are either original producers (no inputs) or require input supplies before production.
  • Three base factory types (no inputs)
  • Three secondary factory types (requires two different-type base-type inputs)
  • One terminal-type factory (requires two different-type secondary-type inputs)
• Factories cost money to buy and an action to place
• A factory may not be built on a colony which contains a factory which accepts that product as either an input or an ouput
• Factories come in 3 size scalings, each requiring a bigger host colony
• Size 3 factories cause all size 1 factories to rust
• Between network manipulation rounds players produce on their factories and feed their goods across the network to other factories etc in production chains
  • Money is paid for sold goods, network use etc.
  • Long term commitments (eg factory hosting on colonies are represented by promissory notes issued by factory owners (pay $X to bearer every round)
  • Promissory notes may be traded collapsed in standard logical reduction fashion
• Factory goods have a small 18XX-esque market
  • Goods which can’t be consumed drive prices down
  • Goods which are fully consumed drive prices up
  • The ranges are fairly small(?)
• Game is ended based on factory construction (N rounds with size 3 terminal factory) or bank breaking
  • End game score is cash
  • Promissory notes are worth cash at some exchange rate

Getting the costs/values right will be interesting.

I’ve been noodling a game tentatively called Space Race for a few months now. Inspired by Clippers (which I’ve been playing a lot of), Indonesia, Wayfinder, ‘Ohana Proa and the 18XX, the intent is for the players to simulate a producer/consumer pipeline across an emergent transport network between nodes that the players also provide and define. A very free-form game.

A few of the other basic intentions:

• Economies of scale mostly won’t
• An amusing argument against Seth Jafee’s Ship vs Build game model
• Also an argument against the general Multiple Paths to Victory view of games (I find it a near meaningless term)
• No (few) proper nouns – a fully emergent game with little to no prior definition, just emergent patterns