An optimisation pass. There’s a large discussion below about building limits, transport connectivity, city centre ranges etc. It is complex. I’m concerned that with buildings flipping ownership as city centres upgrade that tracking ownership boundaries could be needlessly detailed and complex. I really don’t want to introduce border markers or ownership markers. There’s more than enough detail and complexity in the game at that level already to be interesting.

Thus the optimisation pass.

The new model is to just use ranges. A city centre has a range. When it is upgraded its range increases. When a City State has a turn, all buildings within range of its city centres activate. Very simple. Look at the city centre, count outward from there to every building in range: they’re all available even they are also in range of another City State’s city centre. As a side effect city centre upgrades become more interesting. They provide an additional way to control turn order on a micro-level by moving city boundaries and activating buildings more frequently than before. Combined with the new war patterns, this would seem to present some interesting player-driven controls.

Additionally this range model by implication partially resolves an ambiguity around transports and inter-city trade. Just when can a player send a product from one city to another? If only the buildings within range of a city centre are activated, then only those buildings may be used to transmute products. QED. Ergo, an activated building may retrieve an already built product from a remote inactive city to satisfy one of its inputs, but may not send its own products to an inactive building. This model is additionally pleasing as it pushes the consumption choice to post-production versus pre-production. Cleaner, simpler, and more available to borking by other players — what’s not to like?

I’m re-examining the premises for war. I like the idea but am uncertain whether the complexity and detail is justified. This almost certainly means it isn’t justified. Ergo I may end up killing war from the design before I’ve adequately explained to you poor readers what it was before I mercilessly defenestrated it. So be it.

The core concepts of war are simple: City States may construct buildings whose outputs are transport-like devices that can destroy other buildings or transports, or which can take over (conquer) other City State’s city centres.

Destruction of buildings can be useful for land-constrained City States or City States attempting to achieve or maintain a competitive edges over neighbours. Such military units could also be used to sever key Transport connections for competitors or possibly of the host City State so that other/different/more attractive connections could be built instead. Of course once a warship (for example) has been built and the appropriate transports adjusted, the question arises of what to do with it in other later turns and who might use it to do what and where? There are laws about unintended consequences as well as idle militaries.

Conquest however was intended to be the more interesting affair. The core concept was that military units could attempt to penetrate another City State and to conquer its city centre. Should they succeed, then a large portion of the treasury of the losing City state would be divided given to the larger investors in the winning City State. In this way potentially large lumps of cash could be extracted from the game and handed to players. (Investors in the losing City State would have their investment totals transferred over to the winner according to some ratio) On subsequent turns all buildings within range of both/all city centres would activate when that City State had its turn. Thus the result of conquest are several-fold:

1. The total number of City States in the game would be reduced, thus the maximum length of a cross-City-State production pipeline would be one shorter.
2. More buildings over a larger area of the map would activate on a given City State’s turn. Ultimately the entire map could potentially consist of a single City State. This is not necessarily a Bad Thing.
3. The effective turn order relationships of buildings within City State boundaries would change. Greatly distant buildings would now be able to operate within the same functional City State turn. This change could have significant effects in making and breaking efficiency optimisations.
4. A City State could acquire technologies and other aspects of a city centre without investing in them directly.

I can also imagine tieing city centre count limits to technology level limits of City States. In essence this would be a logically implied branch of the tech tree.

Getting back to the starting position however, what I’m having the most problem with is the war buildings and the war transport-like objects. They just don’t seem justifiable in terms of return for complexity. It will also be difficult to write rules without problems for them. I do like the investment and cash flow effects of war. Those are compellingly interesting.

A thought: Have branches of the tech tree which do nothing but absorb/conquer other City States whose city centres are within range of the tech tree climbing City State city centre.

Hurm. The more I think about this the more I like it. It also ties in well with another post I haven’t finished writing yet on managing building ownership and city centre ranges. I’ll try and get those details posted later today.

I’ve largely assumed that Colonial Zoo maps will not be symmetrical and/or balanced. Some maps may be based on real world maps (Greece and the Baltic appeal to me), and others will be relatively random or artful designs with more concentration on challenge than fairness across multiple players. I have to assume that some positions on the board/map used will simply be better and will give the players that start there an inherent advantage, and that’s a problem.

Intuitively. Age of Steam’s variant on the classic Dollar Auction may be the right approach. The basic model would be that a turn order would be establish randomly and in that turn order the players would each found a City State by positioning a city centre for it somewhere on the map. Once that was done the player order would be randomised yet again and the players would iteratively bid part of their starting money for the initial turn order.. Bidding would proceed rotationally in turn order and upon their turn a player could either up the bid by whatever factor they wish, or drop. If they drop they would take the lowest currently unoccupied place in the turn order. By upping the bid they would remain in the auction for turn order. Once bidding is concluded the first and second place players would pay the full value of their final bids to the bank, the player last in turn order would pay nothing, and those in-between would pay half their final bid rounded up. Once turn order was resolved, in the new turn order the players would exclusively choose which City State they wanted to adopt as their starting position.

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.