A few have accused me of developing a 4X/Civilisation Game. I haven’t discouraged them as in some ways I clearly am, however I’ve also made clear that my focus has been on commerce and investment. What is amusing, and I didn’t realise this until very recently, is the degree to which this design is coming to represent my own views on world history and cultural conquest. For instance there’s no war in Colonial Zoo. There’s also no territorial exploration. War and exploration are staples of standard 4X games but they have no real place in Colonial Zoo and I don’t intend change that. I don’t consider war or exploration to be particularly significant drivers of history and cultural development. No, the simple urge to grow and survive as expressed through commerce is the centre of my view of history, and that is being reflected in Colonial Zoo.
An early stab at the building graph overlaid on the technology graph:
Cleaned up, using groups for technology nodes and heavy solid lines for the tech tree, dashed lines for products_needed_to_build and solid lines for inputs_to-produce:
There’s still much to do. I’m also thinking about dropping out a whole technology level — feels like there are too many acts in the play.
Aaron up at Endgame Oakland rather graciously requested a playtest copy of ‘Ohana Proa. This last Wednesday I dropped off a copy of the map. He already had rules and player aids printed. The store stocks all the other bits needed. I’m greatly looking forward to his reports: the Endgame players are perceptive, aggressive, and demanding.
First version of the technology tree:
Greatly simplified third pass:
This last version feels to be of about the sight size and complexity for Colonial Zoo.
The first version above was drawn with KDissert, a neat enough mind-mapping tool. However for this use it has the problem that it can’t represent loops. The loops in the above image were made by stacking nodes. Bad.
The second two graphs were made with yED, a spiffy Java-based graph editor.
The dollar auction model mentioned below is attractive but may not be enough. I’m also concerned that the early stages of the game will be relatively uninteresting as the player’s only opportunity is to invest in/build their starting cities, and given the action point bonus of operating in multiple cities, their unfailing interest will be in linking the city states as rapidly as possible with transports.
A new proposal for initial setup:
0) Setup map
1) In random order have players place city markers on the board, one per player. There may be spacing limitations.
2) In that same order conduct a standard auction for turn order. as each player passes/drops they take the lowest available turn order slot.
3) In the new turn order have players select their starting cities.
4) Give each city cash proportional to the square of the turn order bid of the player in the inverse position in the turn order. Thus the first player’s city gets cash equal to the square of the last player’s final bid, the second player’s city the square of the second to last player’s bid etc.
5) The players may then invest this money in buildings and actions freely, producing products and transports, and having the city consume/place/etc them until the money is exhausted.
6) Start the actual game.
The square may be too high a proportion. It may also be necessary to force the last/low bidder’s payment to $0 in order to prevent excessive bid inflation: All players bid high in order to flood the setup with early cash. It isn’t clear that this would be a problem however.
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:
0) 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.
1) 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.
2) 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.
3) 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 < href=http://en.wikipedia.org/wiki/Dollar_auction>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:
0) Every time I think I’ve got the hang of the game there’s another level.
1) 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.
2) Who do you expect to get to play this monstrosity? Oh, me. Yeah, I want to play that.
3) 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:
0) Only CityStates? may construct buildings.
1) 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:
0) The subject building remains connected to the city centre. In this case there is no change.
1) 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?).
2) 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.
3) 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:
0) PlayerA moves product marker to LocationX.
1) 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?
2) 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:
0) 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.
1) 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:
0) 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.
1) 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):
– Rewards for conflict
– Extracting money from products
– Extracting money from City States
– Move sequence optimisation
– Turn limits
– Interplayer conflict arbitration
– Player trade
– 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?
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
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.
This game has occupied my commutes, my showers, my pre- and post-sleep musings, and even a few of my dreams. A great many things have been assembled. It is now time to try and get that melange out of my head and assembled into an externally logical system.
The assumed presentation is a modular map built from square tiles. The square tiles would represent one of six terrain types: ocean, marsh, plains, hills, mountains, impassable. The players would start the game by assembling the tiles into a pleasing pattern. Possibly there would also be preset patterns of scenarios for more canned experiences.
Once the map was established the players would in turn each found one city state in some location on the board. A city state would be defined by its central location, initially something like a meeting hut, later something akin to a City Hall, Palace or other capitol building. Subsequent buildings within range of the central building would be considered to be part of the city state.
City states consist of contiguous sets of buildings. City States are defined by their centres and a range factor from their centres. That range gets larger as the city cntre is upgraded. City states may overlap, in which case one either overtakes (war/conquest) the other, one simply absorbs the other, or they co-exist with clearly defined (possibly porous) boundaries.
City states will be invested in by players. These investments will initially take the form of straight cash. Later investments may take the form of building contracts, logistical supplies and material supplies. The lead investors in a city state will guide the city’s decisions. Minor investors will not have a part in this decision process.
This is not a negotiation game.
The basic expected pattern:
1) City states are ordered in terms of descending bankroll
2) In order Each CIty State takes a turn. A turn consists of:
a) Each player with presence in that city taking a turn and moving their product markers among buildings within the City State, or moving them out to buildings in other City States, and other like activities, selling material to the City State, investing in the City State, etc b) The primary investors in the City State making decisions for the City State. This will mostly take the form of building construction, investments in material, wars, etc.
3) Repeat #2 for the next City State
4) When all City States have been processed, repeat from #1.
Buildings would be largely analagous to the buildings in Neuland or Roads & Boats. Player participation however would be strictly along the Neuland pattern. Players would only own product markers and product markers would decay across turns. Like Roads & Boats, players would not own buildings or transports, just product markers. Thus the challenge becomes one of sequencing product marker translations across chains of buildings both within and across City States efficiently. Additionally the challenge is to sequence the City States so that their order of operation allows for most efficient action sequencing. Finally the challenge is to cause City States to construct buildings that most advantage your action sequencing without undue benefit to others.
1) A player may cause a City State to build any requested building merely by providing all required resources.
2) Buildings gall within technology levels in different vectors. Some builds are not constructable until the City State has mastered specific prior technologies
3) City States can “borrow” the technology of their neighbours (connected by transports) without investing in the technologies themselves.
4) Construction of a building at a sufficiently high technology level causes all buildings and any product markers they may contain and any transports which depend on them of a sufficiently low technology level to vanish instantly from the game. They are obsolete. This effect may extend to City States directly connected by transports. Thus for instance a City State may research Internal Combustion Engines and then build a Internal Combustion Engine factory only to see all stables, horses, donkeys and carts instantly vanish from the City State’s domain. This pattern is deliberately directly comparable to the 18XX train rusting pattern.
5) A players turn starts by laying down each one of their product markers that are in the currently active City State. They may move up to N product markers on to subsequent buildings for free. In doind so the product markers stand up (shades of Neuland). They may move product markers additional steps forward through the building chain or add additional action markers or start-location buildsings in the City for an exponentially growing cost. Product markers may be moved across transports to other buildings or to remote City States for a fee paid to the owning City State.
The thematic premise to date has been competing city states (cf early Greece) with players variously investing in the city states and potentially guiding their life cycles, or exploiting the facilities the city states proffer to generate profits. As such the core pattern is a mix of macro-investment tightly combined with micro-investment. A player may guide a City State to built the QRS building so that they can then use that building to produce products which they sell/use to make large profits with another or the same City State, or another player, or perhaps at another building nearby or elsewhere. Thus it is expected that the relationships and connectivities of the city states will provide a large and evolving context which the players will build and evolve, all the while also exploiting the details of the imbalances in that system to their own advantage.
I realise that many players yearn for in-game identities. They want to be the…XYZ. They want to have an identified anthropomorphic role. It has been difficult to determine such a role for this game. Several concepts cam to mind: clan heads, apocryphal jewish investors, Illuminati, conspiring hidden hands etc. I’ve been rather fond of a forced misinterpreation of the Commonwealth term “Shadow Cabinet”, which while it means something else entirely, by name suggests the sort of hidden role the players would take in guiding the lives and fate of the City States.
I am increasingly unfond of the current name of Shadow Clan. It is too melodramatic and suggestive of things this game is not intended to be.
At core this is an attempt to design a game-type I strongly dislike, but in a manner that I’d enjoy playing. I strongly dislike economic system/snowball games (eg St Petersburg, Phoenicia, Power Grid, Das Zeptor von Zavendor, Outpost, Civilisation (and all the other 4X variations) etc). However I do like logistical graph manipulation games. The result is that in many ways this is an attempt to make an economic snowball game which is also an interesting logistical graph manipulation game.
The core game problem is assumed to be competition for share of the pie. The player with the largest percentage of the pie at the end of the game wins. Most likely this will be expressed in terms of money, and thus the pie will effectively be the bank of all money in the game universe with the game ending when the game system runs out of money. The player with the largest net worth at that point (largest fraction of the pie), wins.
The parallel to the 18XX is deliberate. However I’m not interested in producing an 18XX clone and thus will be resisting thinking about or phrasing this game in terms of 18XX comparisons. I expect that this and future blog items will show that this is difficult.
The 18XX are effectively all about owning the most valuable shares at the end of the game. Cash is important, but pretty much only as a way of gaining the most valuable shares. I do not want to follow that pattern. The loose expectation here is that players will build and iteratively exercise logistical systems in order to make profits. However the key element is that they won’t build a profit engine in the 18XX or Outpost, sense, but rathr engage in a game-long sequence of logistic moves and relationships which variously result in net profits (and re-investments etc). Thus it is expected that the game will rely much more on timing, presence, and connectivity than systemic relationships.
To give a sense of where I’m heading the primary game inspirations from the logical perspective are things like:
- Roads & Boats
- Atta Ants
- Bridges of Shangri-La?
And on the investment vehicle side are games like:
Hopefully this will give a sense of where I’m heading, or perhaps trying to head.
Image a multiplayer game. Turns are simultaneous. Players move their pieces about a (relatively small) board in accordance with the current game phase. each player may have half a dozen or so pieces to move on the board in each game phase. Two player pieces may not occupy the same location. This poses two questions:
1) How to resolve when two players want to move their pieces to the same location at the same time?
2) How to resolve multiple simultaneous conflicts in which not only do multiple players have multiple discrete conflicts, but each player has a different desired order in which they want those multiple conflicts resolved? eg If Bubba wins that conflict then I really want to win this conflict, but if Boffo wins this other fight then I absolutely have to win this conflict but otherwise I really don’t care etc.
There are several classic resolutions such as Zoosim’s flag/precedence hierarchy and Roads & Boats similar system along with resolution order dictation etc for the first question. I don’t know of methods that specifically address the multiple simultaneous conflict order resolution problem (tho Roads & Boats makes a nod in that direction).