I got around to describing the game to a few locals this evening. Some of the responses were amusing:

1. Every time I think I’ve got the hang of the game there’s another level.
2. This sounds totally like the sort of game I think you’d design: Phase driven, lots of things to do to cause others pain, and most of that pain actually helps you.
3. Who do you expect to get to play this monstrosity? Oh, me. Yeah, I want to play that.
4. You’re evil. You really hate us players don’t you? I like. When will it be ready?

Nothing amazing but pleasing none the less, especially since the game specifically started out as an attempt to design the type of game I strongly dislike, but in a form I’d like. I really dislike what I call economic snowball or economic engine games. Examples include such stalwarts as Puerto Rico, Das Zeptor von Zavendor, Phoenicia, Outpost, Power Grid, St Petersberg etc. They are utterly not my thing and are for me an almost painful playing experience (a year later and David Eisen is still telling the story of the single game of Power Grid he got me to play). The problem was then to successfully design a game founded on the same principles as they, but one that I’d actually like and want to play. Thus the goal of Colonial Zoo was born: Take something dreadful, make something worth playing.

The other amusing aspect of this evening’s conversation was a few statements I made whose truth I recognised only after I’d said them:

In Colonial Zoo the players push money into the City States and then suck money back out of the City States. They do this repeatedly and end up with more money than they started with. Once they have more money they then want a way in which they can shove even more money into the game and take it out in larger lumps too, faster if possible. Basically they want a higher bandwidth money pipeline. This is a primary force behind (expensive) tech upgrades: they increase money bandwidth.

Additionally if the game stays at a low technology level the players will optmise themselves very well for that pattern and will be making more money at it than you are. You will be losing. So you’ll want to upgrade the technology level to cause their pipeline to break and throw them off balance while they optimise for the new level. Of course they then do the same back to you, but that takes a while and as the new technology level is higher bandwidth you’ll be making more money than they could or did. This process then repeats as you break them, they break you, etc. As such the game becomes a rolling process of always building the next better/bigger without ever getting a chance to stabilise on anything before it starts to fall away. It is rampant consumerism gone wild.

Or, to paraphrase a friend from tonight, You are building an economic engine, it just keeps falling apart and breaking and big chunks of it disappearing while you’re doing it. That sounded pretty much right to me.

Terrain is being simplified. Marsh and hills are out. I’ve been unable to come up with a good enough functional justification to keep them. The new terrain set are:

• Ocean (blue)
• Plains (green)
• Mountains (brown/gray)
• Impassable (white/black?)

Another small change is the handling of transport locations. When produced transports accumulate on their producing building and can then move out from there to form contiguous set with the production building similarly to the pattern described for buildings below. Caveat: Transports don’t have to be set-contiguous with the building that individually produced them, they merely need to be set-contiguous to a building which produces those transports and is owned by that City State (may not be the same one that produced that individual transport token).

None of this is a change. The changes relate to the placement of deployed transport markers.

Sea transports are placed in the centres of tiles and there may be a considerable of transport markers in any given location. A sea transport is considered contiguous with the 4 orthogonally adjacent tiles/buildings. Land transports are placed along the shared edge of two land tiles and are considered to be contiguous with 6 tiles: the two tiles which form the shared edge and the additional two tiles at either end which share corners with the end of the shared edge.

Building tile size has been adjusted to be somewhat smaller than terrain tiles so that there is room between buildings to see the colour of the underlaying tile and to plsce transports along that edge.

Possibility: Add blue stick-like markers which may be placed during setup along the edges of land tiles, Settlers-of-Catan-roads? style, to denote rivers. This would not only potentially allow waterway-specific transports (barges, canal boats, etc), but also lakes, inland seas, and also opens the possibility of deliberate canal construction and bridges over waterways.

Complexity: one step backward into simplicity, one step forward into detail and morass.

Building ownership is relatively simple and yet complex, as it affects movement costs and thus action limits, and controls the order in which buildings activate (the order of their owning City States).

The basic policy:

1. Only CityStates? may construct buildings.

2. Buildings may be constructed:

   • contiguous to the city centre
   • contiguous to a chain of buildings one of which is contiguous with the city centre
   • contiguous to a transport chain which is contiguous with a matching transport production building which is contiguous with either the city centre or a building chain which is contiguous with the city centre.

Where this gets interesting is when buildings are removed from the may due to tech upgrades in their owning city or directly connected neighbours. Possible results:

1. The subject building remains connected to the city centre. In this case there is no change.
2. The subject building is no longer connected to any city centre. In this case the building is considered un-owned and may not be used. Any product markers on it must be discarded (or left until it is owned?).
3. The subject building is no longer connected to its original owning city centre but is connected to a different City State’s city centre. In this case the building is now owned by the other City State.
4. The subject building is no longer connected to its original owning city centre but is connected to multiple other different City State’s city centres. In this case the building will belong to the closest City State with ties broken by transport technology level, distance, breadth of connection, and City State treasury size. If there’s still a tie the building is unowned and is treated as in the #1 case.

Simply to reduce play length and in partial paean to Roads & Boats, I’d like all player turns within a City State to be simultaneous. The problem is when player product movements conflict. Multiple players may want to move product markers to the same locations at the same time. I created a forum thread to examine the area here. There have been interesting replies.

What makes the situation a little more complex than even that thread describes is that players may move a single product marker once or several times. Within the single player’s logical space this is not a problem. The problem enters with multi-player coordination and the effective input of iteration. Consider:

1. PlayerA moves product marker to LocationX.
2. PlayerB moves product marker to LocationY. PlayerB then wants to continue and move their marker to LocationX. Should they make the move and thus create a conflict, or shoud they wait until later in the same turn to see if PlayerA moves their product marker off LocationX with their own double-move first?
3. Now add a PlayerC with their own interesting dependency graph.

I’m not sure this is inherently solvable. Much as I discuss, the simple cases can be mostly suitably handled by defining a preset order of resolution of conflicts and a policy for loopbacks. Some problems remain for very large loopback structures, but those may be containable in other fashions (eg simply limit the total number of conflicts that any give player may initiate per turn). The problem is that the problem isn’t that simple, it never is. If I add the multiple-move option described immediately above (which I really need to do for efficiency’s and interest’s sake), then the problem is a lot more complex and I’m not sure that any simple knife can cut that knot.

David Pontier’s approach to a Tech Tree:

It is far too large and long for Colonial Zoo, I’ll need something roughly a fifth the size in each dimension, but it has some nice relationships in it.

The money must flow.

Players start with a base fortune.

They may invest that fortune in City States so that they are able to construct buildings useful to the players.

Some buildings accept money as inputs to produce their product.

Some buildings accept resources as inputs and produce money as their output.

City States will accept resources from players to construct buildings or perform actions. If done during the player phase this purchase will be reflected as an increased investment base for the player even though no money explicitly moved. If done during the City State phase money will move from the City State treasury to the players.

Some buildings may only be constructed during the player phase, other during the City State phase.

Some buildings instantly reward the constructor with money from the bank.

At the end of each round the City States levy taxes. Money is paid from the bank to the City States for each building in that City State. Players must give money to the City State for each product marker they have on a building in the state.

Not all buildings or product markers tax at the same rate.

Players may trade ownership of product markers. They may accompany such trade with money.

City States may conquer or subsume other city states. In short this is done by gaining control of the other City State’s centre. Upon successful conquest much of the treasury of the conquered state is divided among the larger investors of the winning City State. The remaining funds are added to the winning City State’s treasury. Investments in the old state translate linearly to the new larger state.

The turn order pattern can be interesting.

During a City State’s turn all the players with presence in that City State may act, moving and using their product markers as appropriate. This is the micro-economics exercise portion of the programme. Such movements are usually entirely self-interested but they need not be. Players have a limited number of actions they may perform and beyond that limit must pay exponentially for continuing. Any given product market can move at most once for free, with additional movements also raising (slower) exponential costs. The result is that players must optimise a two and a half dimensional field:

1. Limiting the total number of product markers within a City State so as to retain efficiency and flexibility in the face of player competition. The key risk is that every product marker that hasn’t been used or moved by the end of a turn must be discarded (deliberate shades of Neuland). Given that a product market on a late-building may represent actions across a dozen turns, losing such a product marker is expensive.
2. Securing a production line by saturating all the buildings in the production line with product markers. The result is that turns become simple: just bump the whole chain forward one step. Of course if the production chain is longer than the maximum number of free actions, then the costs will need to be balanced. The primary risk is that another player will attempt to pre-empt a later portion of the whole chain, possibly causing a large number of product markers to rot and be lost. The current expectation is that players will attempt this pattern but segmenting their production line across multiple City States. Each City State would contain a smaller number of steps and markers, but the player would need to bear the cost of transport feed for the products between City States.
3. Risk. Production lines will generally represent single technology levels. Too many product markers committed to a single production opens the player to the risk of losing some or all of them due to one of the City States upgrading to a higher technology, causing key buildings and the product markers on them to be lost. It is expected that long production chains will be absurdly profitable. Thus it is in the key interest of all players to push the technology tree quickly so that the players that do secure those long production lines can’t profit from them too heavily and sustain a considerable recovery period when moving to the new technology level (deliberate shades of 18XX: 3 trains cannot be allowed to live for too long).

What makes this interesting is the effect of player and City State turn order on this balance.

On a City State’s turn players first operate in turn order, and then the City State operates. In general the first phase should consist of the players running the micro-economy and the second phase will have the City States gearing up for the next layer/scale of the micro-economy. But not always.

During the player phase players may force the City State to build and do anything they wish just as long as the player also presents all the resources necessary. This has two primary results. First it allows a City State to act (beneficially or not) during the player phase, effectively giving the City State am extra free turn (and multiple players could do this together for multiple extra City State turns) while the players donating that extra turn also increase their investment in the City State, thus possibly becoming the investment leader and thus dictator of the City State’s actions on its turn. Secondly the City State on its turn may purchase goods from players in order to perform City State actions, thus effectively giving money and actions back to the subject player (may be the primary investor/dictator).

ObNote: Players may also purchase products from each other in a limited form auction,

It is hoped that this will create a multilevel market:

1. Players will sacrifice actions and money to gain the buildings etc they want along with influence and control of the City State. The increased investment can change the controller of the City State, the rewards for war (discussed later), and can move the City State higher in the turn order of City States.
2. Primary investors will cause the City States to purchase products from players, thus pushing investment money back out to the players and thus granting them liquidity and flexibility, and reduging the total investment volume of the City State and thus possibly moving it lower in the turn order of City States.

I’ve temporarily renamed the game to Capitalist Zoo. I’m not fond of this name either, but it is at least better than Shadow Clan. More changes to come.

Upcoming topics (not in order, mostly just notes for myself):

• War
• Conquest
• Rewards for conflict
• Extracting money from products
• Extracting money from City States
• Move sequence optimisation
• Turn limits
• Interplayer conflict arbitration
• Player trade
• Negotation
• Use of rusting
• Technology umbras
• Cost structures

Producing the relatively large number of terrain tiles for prototypes has been a concern. In fact I just bought a copy of Roads & Boards plus &cetera just because I expected that I’d also be able to use the many hundreds of bits from those games in the prototypes for this one. Of course it didn’t hurt that I also like Roads & Boats.

And of course I’ve pretty much decided that hexagonal tiles (such as in Roads & Boats) are an unnecessary complexity for this game. Oh well. The problem remains: How to produce the several hundreds of terrain tiles needed?

Solution:

1. Thin wood tiles about 1.5” square from the local craft store.
2. A big sealed storage or fridge container
3. Cheap poster paint.
4. A good-sized dollop of poster paint in the container, some water as solvent, toss in the tiles, shake vigorously, remove and let tiles dry on a piece of chicken wire from the home DIY store.

Two types of buildings:

1. City State centres
2. Other

City State centres occupy a contiguous block of tiles of a certain shape with specific terrain requirements, When upgraded to a larger city centre the new location may not be more than one tile removed from the prior location. Each type/scale of city centre comes with a range. All contiguous buildings (contiguous with the City Centre) within that range or which are connected by state own transports to contiguous buildings within that range, are part of the City State.

Other buildings are production buildings. They are of three types: buildings Producers, Translators and Money Producers (need a better name for this one).

Producers accept no inputs and produce whatever it is they produce. This process is identical to the farms and shepherd shacks in Neuland.

Translators accept a specific mix of inputs of specific types of products and in return output of a product of yet another type. This process is identical to most of the buildings in Neuland.

Money producers accept a specific mix of inputs of specific types of products and in return give the moving player abstract money in their account.

Physically buildings consist of one or more contiguous tiles with terrain limitations. Contiguity will usually require tiles sharing edges but in certain very limited cases may be defined by sharing corners or even by range measurements. Uncertain.

Building tiles are placed on terrain tiles.

Product markers are placed on building tiles. Typically there may be only one product marker per building at any one time, no matter how many tiles the building covers. Some special few buildings may accept multiple product markers (function of tech level?).

Some buildings produce transports given the right inputs. Thus a stable that is adjacent to a paddock may accept food etc as inputs and output horses. Similarly shipyards produce ships, wainwrights produce wagons etc. The produced transports are owned by the city state. The producing player is rewarded with investment value in the city. The producing player may move the transports out from the production centre, and in fact all the transports of that type that are members of a set contiguous with that production centre with the following constraints:

1. No more than N transports may occupy a production site.
2. Transports may be moved off the production site
3. Different transports have different terrain limitations. Those limits may be how many may occupy a given terrain type, if they may share the terrain type with other transports, with other buildings, or the total number of things that may also be present on the tile (crowding).
4. Every moved transport must be able to trace a parth from its location, through other transports of the same type, owned by the same City State, to a production site for transports of that type owned by the same City State.
5. A chain of transports joining two production sites of that type of transport may never be broken by the City State that owns the transport. The chain must remain. Other City States may attack the chain and break it, in which case the original City State has one turn in which to reconnect the disconnected transports before their ownership transfers to whichever City State owns the production site they are connected to.
6. Transports which connect two production sites may still move, perhaps to join yet other production sites, but may not in the process sacrifice connections previously gained.
7. Should a connection be removed by the owning City State destroying or losing that production site then the transports may move away freely.

Players may move products over transports to buildings in connected (or same) City States. Such movement requires payment for use of the transport to the owning City State. The product must continue to move off the transport to a building which can accept it for production. Any required fees for this additional movement must be paid.

Remember, players don’t own transports or buildings, cities do.

Different transports have different capacities. Transports cannot carry loads of too high (or low) a tech level. They are also limited in capacity. This limits the transfer bandwidth between cities.

Orchestration of transport logistics and timing is expected to be significant to good play.