Tweet
Proposal for a Complete Infrastructure Model
A Complete Infrastructure Model
1. Introduction
This text is aimed to accompany the infrastructure spreadsheet and to explain how it works. It is also an attempt to explain the philosophy of the infrastructure model used there and to adress the various issues of gameplay and model interconnections that rise from it's implementation.
The infrastructure model presented here is actually an enhancement and a completion of the general outlines given in the economic model, of which infrastructure is a submodel. I owe much to Mark Everson, who provided me with these outlines and with the concept of the preferences machine too. A lot of attention was paid to model flexibility, scalability and customisability, so that the model can be used in whatever level of detail it is desired and with whatever effects are desired, both by the developping team and the scenario creators.
This model can be run at a civ, province or mapsquare level, with minor modifications (which are related with government action; see below), but the reccomended level is definitely the province level. Being run at the mapsquare level (and in equal or more detail than what is in the spreadsheet) would IMO be a computational overkill and should be avoided.
The numbers used everywhere are quite arbitrary, but they are in no great dissacord with historical reality. Of course it won't be hard to spot quite a few correlations that are irrational, not to say inaccurate. But, after all, the spreadsheet is created, except from modelling reasons, as an early tool for determining some reasonable and realistic configurations for the multitude of constants the model demands. Production and prices are taken from the Mid-Tech (A=15) province in the Econ model v.11 spreadsheet. In the example you will see in the spreadsheet, this province has more infrastructure than it can maintain or use, so infra units are in the decline.
2. Infrastructure classes
Infrastructure is divided into classes, each corresponding to one sector of human activity. They are in fact the categories in which the people decide to spend their income. As it is prescribed in the econ model, infraclasses resemble storage containers, where "units" are put in and out each turn, according to the amount of investment, consumption, destruction and decay that is applied upon them by the people's decisions and the game rules.
What generally happens is that a budget is decided (through a process described in the preferences machine) and is input at the investment machine, where it is determined, according to their prices, how many of the already existing units of each class are going to be used this turn and how many new units will be bought. According to each classes attributes, this allows us to compute how much benefit there will be from it this turn and how many units there will be left next turn.
The number of infraclasses is not fixed; it depends on the detail we want to give to the model. Of course, making use of more classes means more complexity, not only because of the number of classes per se, but also because this means that more detailed interactions with the rest of the Clash world are needed, in order to provide all the infraclasses with discrete profiles. The connection between infraclasses detail and interactions detail is of course not linear; but this will be made clear below.
In the spreadsheet I use a total of 20 infraclasses which I think cover the spectrum of people's spending to a sufficient degree. This is actually an expansion of the set listed in the corresponding matrix of the econ model. I tried to create an infrastructure model that is general enough to encompass any kind of spending, so here are included some areas (like Food and Kapital Investment) which are supposed to be (or already are) covered elsewhere (the econ and the govtecon model respectively). If it is proven that they cannot be handled sufficiently as infraclasses and that they need special treatment, they will be removed.
You will notice that many of them can be merged with others into a single class, or split into more classes. This doesn't neccessarily mean that the collection of classes inside a single game will be dynamic (f.e. when flight is discovered, add an "Air Transportation" class). Who knows? this approach, although feasible, may create problems in game organisation and historical accuracy. Instead of this, the model (more specifically the preferences machine) has the capability of keeping unwanted infraclasses inactive, when it would be innatural to spend money on them. So each game can easily have a steady (though not always the same) number of infraclasses.
3. Attributes
Columns N through R in the "invmach" sheet contain a set of attributes which determines the rules with which each infraclass is treated. These are:
- Persistant/Consumed. A dummy variable. An infraclass is consumed (0) when the amount that gets used is lost in the process (this is true for food and consumer goods; it might also be true for other classes too). Otherwise it is persistant (1), which means that a # of units used once can be used again next turn, if they still exist (as it is with all other infraclasses; f.e. housing).
- Mobility. What % of this classes units is mobile and can be taken away from the mapsquare/province/civ the model is applied. Infrastructure in the traditional sense means assets tied to the ground (such as housing and water infra, which have 0%), but here we use an extended meaning which includes mobile goods and military units (with 100% mobility) and other mixed types of infrastructure, which can only partly be moved. These usually consist partly of buildings and partly of equipment, of which only the latter can be moved. This isn't used anywhere in the spreadsheet for the time being. For more details see the appendix.
- Decay. What % of each classes units gets lost each turn. Loss can occur for a variety of reasons, including physical decay (for food), depreciation, wear and tear, even boredom (for recreation). Decay occurs to consumed and persistent classes alike, even if they are not used. Decay should be usually positive (as it occurs from the 2nd Thermodynamic Axiom), but a discussion I overheard at the forum about animals being considered infrastructure made me think that a negative decay could be used in such a case, where the infrastructure units multiply by themselves. The figures will be determined chiefly by the Tech model, although other stuff like Ecology can influence this too. For a good way to do this, check out below how preferences are handled.
- Backup. The % of a classes units that is kept unused, although it can be used. This has sense chiefly for making stores of consumed classes. It can be applied to persistent classes too, but it has no sense. Of course we can say that the % of persistant classes units that doesn't get used for economic reasons is backup, but that's not the actual meaning of it.
- Minimum Output. The minimum (per capita) # of each classes units that are needed for survival. A check should be made to the output each turn to make sure that these needs are covered and if not the budget must be accordingly corrected. Or maybe these should be considered basic needs and be met before the budget is applied. This struck me as very tedious work to do in Excel, so I have skipped it: for now this column does not affect anything. Min Out also depends from time to time and from place to place (it can probably be figured out from the social and ecology models), but for most classes it is zero. The figures I use in the spreadsheet are rather arbitrary, but I think they correspond to the most basic living conditions.
4. The distribution of Surplus Value
The square/province/civ in question produces a given amount of commodities (M1, G40-43) which, using the prices set by the econ model (D40-43) sum up to a certain product, or surplus value, measured in CC. This product is altered by extraction of profits from the place (decreased) or investment in the place (increased), which is made by the ruler who controls it and maybe, in later versions of the game, by private agents too. What is left in the province must somehow be distributed among infrastructure classes (the investment machine does that) but also among the economic agents of the province. That distribution is actually a part of the govtecon model, but for the needs of the spreadsheet, it is displayed in matrixes M3 and M2.
M3: The total product is divided between the people and the state by the Effective Tax Rate, which sums up all kinds of taxes applied plus the profits of public enterprise. The % that goes to the people is distributed among the socioeconomic classes in M2 and it all goes to infrastructure. Since this is normally done in the govtecon model, M2 works in an improvised way; the user of the spreadsheet is expected to set the TI per class numbers (H27-H30) so that their sum equals the amount transferred from M3 (it must be H31=H32). I hope that you will excuse me for the inconvenience.
The money of the state on the other hand is only partially redistributed (investment in infrastructure is considered redistribution) and this part is set by the redistribution variable (from the govtecon model). The part that does not go into infrastructure is at the disposition of the ruler for his "expenses" (see Appendix 3).
Redistributed money is further more divided to the levels of government involved. How many they are, it depends on the level the model is run; if, like in the spreadsheet, it is on a mapsquare basis, they are 3 (Local Govt, Provincial Govt and Central Govt), if it is on a province basis they are 2 (PG and CG) and if on aciv basis, there is only CG of course. The measure for the division of this budget is the Centralisation variable that will be hopefully provided by the govt model. The funds in question are of course entirely invested in the specific place, but by more than one agent (f.e. the PG builds roads in the province, but the CG builds the highways).
The funds that each level of government gets it's hands on is furthermore distributed among the AI and the player, according to the ruler's pol.power. This way, the player's intervention can be specialised in whatever degree he wishes, allowing both micromanagement and general guidance of the infrastructure system (see preferences machine).
The funds discussed here include neither the tax money the central govt is entitled to collect and move away from the place in question, nor the money that they decide to specially invest in the place. These should be applied externally upon state investment (M3, cell L31) and move the total % either above or below 100%.
5. Prices
As you can see in the "invmach" sheet, one unit of infrastructure costs a given amount of commodities (F, P and S) to be bought (columns B, C, D) and another amount to be used (columns F, G, H). If these amounts are combined with the current local prices of each commodity (matrix M1), two prices are determined for each infraclass (costs in CC): the input price (column E) and the output price (column I).
The costs in commodities depend chiefly on technology and are expected to be given by the tech model. Because the definition of a infraclass unit is arbitrary, in the input section I have made costs in commodities all sum up to 1, but that is not necessary (like the cost of services always being 1). For obvious reasons, this doesn't happen with the output costs, which are generally much smaller.
Another set of costs (columns K, L, M) and a price (column N) can be derived from these, to provide us with information about the maintenance cost. This is defined as the total of input and output cost that will be needed for one unit of infrastructure to be used used this turn and remain intact for the next turn. This depends of course of the decay and the persistant/consumed dummy variables. This information is not essential for the investment machine, but I thought it would be interesting to display.
But how are the local prices for each commodity computed? The econ model has more or less defined a procedure for this, although it is not finalised. According to this, prices are determined from the amount of Kapital, Resources and Labor required to produce them (production function). Then, as the state takes it's taxes in whatever form it desires (Food, Products or Services), prices are recalculated, to correspond to the new quantities of available commodities in the province. Then trading occurs and, since specials are turned into commodities and commodities themselves get traded too, the quantities change again and so do the prices. With those final prices and quantities the infrastructure model was to work.
However, this infrastructure model does not maintain this balance between the amounts of commodities available and their prices. With the prices as input, it calculates the provinces demand for commodities (M1, I40-I43), which, although it is (at the local market) worth the same as supply, it is in general different from it. This difference between demand and supply can be covered only in two ways: either external trade which will bring supply to the level of the demand (demand based economies) or rearrangemnt of prices which, through another iteration of the investment machine, will bring demand to the level of supply (supply based economies). Of course both can happen in the same time; if supply can move only part of the distance (because of limited trade capacity), then demand has to cover the rest of it. Ancient economies, because of the physical and political restrictions to trade, were mostly supply based. Nowdays, with the modern technological means and the globalisation of the economy, most of the world's economies are demand based. As technological means progress and as international trade relations improve in quantity and volume, economies of civs all over the Clash world will move from supply based to demand based and this will be a major cool feature of the game. I think that this is the market vs. traditional economy feature that Mark has mentioned in the econ model (as a feature that still was not implemented). So this is how things should work inside the game (see M1):
- Initial production. Quantities and prices are set. (col G)
- Commodities are extracted or invested in the provincial economy by the state. Quantities and prices change. (col H)
- Demand is computed by the investment machine (see below how). (col I)
- The merchants cover part of the difference (col J), by buying and selling commodities (whose local values always zero-out; col K) and make a profit out of the difference between local and global prices (cell K46). Quantities are finalised (col L) and prices change.
- Demand has to be equal to the final quantities, so the investment machine has to be reversed somehow to figure out the final prices which will match demand with supply.
Prices rearrangement throughout all these steps is not modelled in M1; this is handled by the econ model. The last step is not yet implemented in the spreadsheet. There are two possible ways with which we can implement it:
a) Since the investment machine takes in the prices vector P=[f p 1] (1x3) and, through a certain transformation function, which is a 3x3 matrix M, transforms it into the quantities vector Q=[F P S] (1x3) so that Q=P*M, all we would have to do is find the inverse matrix M^-1, so that P=Q*M^-1. I don't know how hard the math for this will be though.
b) Make a few iterations of the investment machine, until the difference between supply and demand converges to zero.
6. The Investment Machine
The investment machine is the component which does the bookkeeping for each infraclass. The current plan (and what you see in the spreadsheet) is to apply it once for each place (square, province, or civ), to compute the infrastructure invested by, belonging to and used by everybody in this place. The budget that it uses (columns W and X) corresponds to the collective preferences of all the social classes and the various levels of government involved (see "prefmach" sheet) and to their collective amount of spending (see matrix M3, cells O27, O28). Of course it can be used seperately for the public and the private sector, or for each socioeconomic class and/or for each level of government. The preferences machine would have to be altered (see below) and the investment made upon each agent's spending money (as they are analysed in M3 and M2). What happens now is that we are aggregating all the agent's preferences with weights depending on their money and political power, so that the overall effect is the same, while the detail of who possesses what and benefits from what is lost. But at the same time we are getting rid of quite a lot of complexity and computational weight. If, after all, the lost detail is proven essential for some reason (I can imagine this happening for public/private, but not for social classes), we can easily change our method.
Having the # of infra units available this turn, we can find out how much they need to be maintained, which is there, like the maintenance cost, for informative reasons for the time being. Having also the budget, will let us compute how many of the existing units get used. The formula there says that we use as many units as our budget will afford (if the output cost is 0, we use all of them of course), with the exception of classes which have backup indicated, where the backup% is kept unused. The rest of the money partaining to each infraclass goes then to new units, the number of which is such that the remaining money can pay for their input and output (buying and usage). Provision is made for those units which will be bought but not used (backup again). The input cost is also computed (AB). Then, the total output is derived, by adding the old used units with the new used units. This vector will be used by the game models to calculate the effects of infrastructure. The output cost is also computed (AD). Finally, the units that will remain in the province for the next turn are computed, by applying decay to the sum of old and new units. (AE) For the consumed infraclasses, the output is subtracted from the sum. For each column in units, a column indicating the cost or the worth in CC is displayed, chiefly for informative reasons.
Having finished with the main investment machine, matrix M4 computes the resulting demand of commodities. For both input and output and for each of F, P, S, the sum of the products of units*unit_costs is computed and all these are summed up. As it is expected, the value of the demand (AF28) is equal to the value of the supply (O27).
7. The Preferences Machine
The basic idea behind the preferences machine is to take a "base budget" vector, which is common for all situations in Clash (so it will be a constant of the game) and alter it by applying subsequent percentile modification vectors ("mods"). The final outcome (column AM) is then translated into the budget (column AN) that will be used by the investment machine. The elements of mods are percentages between -100% and 100%. Each mod is related with a certain factor that is known to affect infrastructure. Currently there are mods for Ecology, Technology, Population Density, Culture, Society, Emergencies and Government, but more could be added. The computation of mods has also various degrees of complexity; some mods are given as-is in the spreadsheet, others are computed directly in one stage and finally others require multiple stages of computations.
The mods are applied to the base budget in a serial (subsequent) fashion, so that the outcome is something like Base*(1+Mod1)*(1+Mod2)*… *(1+ModN). The actual order of the mods doesn't matter of course, but I have placed them in order of fundamentality / long-term activity. But mods can also be applied parallelly, either totally or partially, so that the "Total Mod" is the weighted sum of all the mods, or the product of mods and weighted sums of mods (partial mods). For example the Social and Government factors could be computed together, using the percentages of the total product that are invested by the people and the govt respectively (matrix M3, cells M28 and M31 respectively). In parallel computations, the sum of weights must be below 100%, to ensure that a mod never gets below -100% (there is no problem if it gets above 100%). The difference between serial and parallel computation is that the serial mods are independent of eachother and have total control over the budget, while the parallel ones are related, act simultaneously and have control over part of the budget.
But how are mods themselves computed? The exact functions used depend on the mod in question, but the way these functions are defined is uniform. Each mod has a "correlation vector" (cv, shortly) and a special weight for each game variable that we decide to connect with it. Exactly like in the parallel application of mods, the mod is the sum of the products of all cv's with their respective special weights. For the cv's that are derived, the same thing applies; they are computed like the mods are computed; the only difference is that more formulae than just the sum of products can be used there.
The correlation vector may be set by us or the scenario creators, may be input from the ruler, or be derived by other cv's. It defines in which way the infraclass in question is related to this certain variable or agent. The corellation can be inexistant (0%), positively extensive (100%), negatively extensive (-100%) or intermediate, high or low. The concept of corellation is extensively used in statistics. As for the special weights, they determine the extent of the effect. They depend on the variable or on external data concerning the influence of the agents in question. The examples of the mods used in the spreadsheet should be enlightening.
Apart from the main calculations, there are also a couple of informative figures in the "prefmach" sheet. First of all, in row 25 there are the special weights of factors inside a specific group, as opposed to the overall special weights, which are in row 26. According to the case, one of those sets is use for the computation of the mod. Then we have the deviation (col AO) and the percentile deviation (col AP), which compare the final budget with the base budget.
Last but not least, there is Mean Square Corellation (row 24), which is, as the name implies, the mean of the squares of the elements of each mod or cv. It is very useful while setting the constant data of the model, as an index of overall corellation of each factor with infrastructure. It is obvious that, for parallel computations, if we want the representation of each variable to be fair, the MSCs must be approximately equal. But this is no hard rule: if we indeed feel that a variable is not so important, it's MSC will be lower; but this will happen on purpose and not accidentally.
Ecology Mod: It is very well known that according to the climate of the area, the people's needs vary greatly. F.e. heating, as well as food (calories) are more needed in arctic areas than in the tropics and water infrastructure is needed more in arid areas. Here I assume it given by the ecology model. It can be computed like other mods are, according to the basic climatic variables, whatever they are.
Tech Mod: Technology is a major modifier of infrastructure, not only referring to prices and decay, but also to the preferences of the people. F.e. modern day people seem to spend relatively more on communication and transportation than ever, because that is what their modus vivendi dictates. We must take extra care so that this mod doesn't reflect the changes in infra unit costs or PCI that are also due to technology, but choices that can only be correlated with the technological environment. As for ways of computing this mod, this is TBD. IMO, each infraclass mod should be linked to the apropriate L1 or L2 Tech Level, through a vector of game constants.
Population Mod: This currently involves only pop density. It is well known that all kinds of networks are cheaper in densely populated areas, while there is generally more investment in the service sector, but I won't discuss this here. It could be correlated to other demographics as well (and thus become the mod for the pop model) and it could also be corellated to the capital status of the square or province in question. The "independent" variables that I use is population density (defined arbitrarily as population/1000, so that the special weight becomes 100% when population reaches 1000 heads) and it's square, so that the sum of products gives us actually a second degree polynomial function for the mod. In this example density is low, so the MSC is quite low too. This is an example of how we can compute a mod from one variable using a polynomial function which is totally under the control of the Clash Team, or the scenario creator. It is known that, by use of the Taylor/Maclaurin functions, any single-variable function can be easily aproximated by a polynomial; the flexibility thus provided to us is unlimited.
Culture Mod: Culture is surely a very long-term modifier of investment preferences but it surely is important. In columns H through M, these cultural attributes that are considered to have an effect in any way to infrastructure (all of them, except Ethnic and Religious Discrimination, IMO) are assigned cv's and use as special weights their attribute values, to compute the mod. Of course the sum of the weights is more than 100%, so the proper thing mathematically would be to use the reduced values of row 26, which sum up to 100%. But since the numbers here do not cause the < -100% problem, row 25 gives a better result, since the effect of each attribute is independent of the values of the other cultural attributes. Here we can see how important it is for the proper function of the preferences machine to pick the proper special weights for each cv.
Social Mod: This is the first of the two really complex mods. It deals with the part of infrastructure bought by people's money and that's why the sum of it's weights (cell X29) is equal to the percentage of the product that "goes to the people" (see matrix M3). One would expect all the influencing weight to go to the socioeconomic classes, but this is not so; only (1-EP)% of it is under the individual control of the whole of socioeconomic classes, while EP% of it is under the control of all classes that hold power (all except the XC of course). This adds the MC, RC, BE and of course the Ruler, each one posessing their own cv. The Ruler's cv is of course input by the player, while the other three are constants for the time being (they could possibly be derived by other variables but there is no need for it). The influence is distributed along the lines of pol power for the EP% and (as it has been already mentioned) according to total class income for the (1-EP)%, which means that the XC has an influence too. The influence (special weight) of the socioeconomic classes is the sum of these two factors. It is important to notice here that this type of political intervention over private funds will certainly cause discontent to the socioeconomic classes. This could be computed using only EP, but it would be more fair to use the sum of the products of the MSCs and the influences of the socio-political factors.
Unlike the institutional classes, the preferences of the socioeconomic classes are derived. They all depend on a single variable for now: PCI. This is done through the sigmoid function, which (in the "prefmach" sheet at least) has 3 parameters. Each one of the parameters has a cv with PCI, which actually gives the value of the parameter for each infraclass. Each of the socioeconomic classes cv's is an instance of the sigmoid function (posessing these parameters), corresponding to the specific classes PCI. More on the sigmoid function and on why it was chosen will be found below.
Emergency Mod: It encompasses all changes in preference that an emergency such as war or a natural disaster would bring. During wartime, investment in Military Units and Infrastructure is multiplied. Pollution does the same for Nature Preservation; so does disease for Healthcare. A disaster that has caused the distruction of a certain type of infrastructure (f.e. an earthquake that destroys Housing) will lead to an emergency situation where spending in that type of infrastructure is increased. The exact method of computation for this mod will be available when a total emergency model is developped.
Government Mod: This is the other complex mod, covering the part of the budget that belongs to the state. The difference between the government modifiers and the aforementioned socio-political ones is that the first ones adress infrastructure that is considered public (both in ownership, in control and in benefit), while the second adress infra that is privately owned and benefited, but publicly controlled. So f.e. the government mod would not have much to do with goods, but be closely related to services networks and administrative infrastructure. It is computed for the player and the AI in each one of the administrative layers effective (local, provincial, central) using as special weights the state budget described above and in matrix M3 in the spreadsheet. The ruler's cv's are of course input by the player, but the AI cv's are derived from the government policies. For the time being I am using only Economic Planning, Social Policies, Foreign Policies and Centralisation, but Private Property could be added too, if we decide it is important to include (The definition of PP I am using is that it refers to the productive infrastructure - in other words the Kapital - and not to other types of infrastructure). The cv's for policies are fixed and the formulae which link them with the AI cv's are as follows:
(col AE) CG=FP*FPcv^2+EP*EPcv+SP*SPcv^0,5+CE*CEcv
(col AG) PG=FP*FPcv+EP*EPcv+SP*SPcv
(col AI) LG=FP*FPcv^0,5+EP*EPcv+SP*SPcv^2-CE*CEcv
This means that the CG is naturally inclined to a budget dictated more by FP and less by SP, while the inverse happens with the LG. CG is positively affected in it's choices by centralisation, while LG negatively and PG not at all. If we run this at the province level we will probably have to replace the PG formula with the LG one. In the civwide case, the single government would probably use the PG formula. All this is open to revision at any time of course.
We could also consider creating economic discontent from the government mod, as an expression of the people's in-bred resistance to the government, using the 18% special weight and the MSC of the government mod as an indicator. However I am against it, since the people usually expect the state to invest in different things than they do (public goods), so why would they be unhappy about it? Actually, I am only pointing out the capabilities of the model here.
The preferences machine that is shown in the "prefmach" sheet is set up so that it can produce a budget appropriate for computing investment for all agents together. If we decide to make multiple computations, it will have to change appropriately. The good thing about the way things are run in the preferences machine is exactly this; it gives us the capability to assemble and dissasemble it at will.
8. The Sigmoid Function
In the sheet "sigmoid", one can see the infamous Sigmoid Function in action. It is nothing but the well known function arctanx, the inverse of the tangent, properly enhanced with parameters. It is characterised by it's S-type shape, confined between two limits and by the turnpoint, where the second derivative changes it's sign. I have created two implementations of the sigmoid, on with three parameters (column B) and one with four (column C). These I have graphically represented for the variable range 0 -250, inside which we expect PCI to fluctuate, from the antiquity to modern times. Play with the parameters and see how the functions behave in the graph.
The tri-parametric one is earlier and it is the one you saw implemented in the "prefmach" sheet, for corellating PCI with infrastructure. It's parameters are Height, Turnpoint and Slope. It's value at 0 is always near 0, so in fact it can't be shifted up or down. The tetra-parametric one is more complete and (as you can see) it can begin near any value. It's height is the difference between it's two limits. Since this function is transposed (the actual arctanx has it's turnpoint at 0,0 and it's limits are +/-pi/2), it always passes near but never through the points 0, lim(-) and 250, lim(+) that characterise it. How near that is depends from the slope.
I hope that after playing with the sigmoid, the reason I have chosen it for the corellation of PCI with infrastructure is obvious. It is the best way (at least that I know of) to represent the saturation that occurs in the need for certain goods as PCI rises. There is a limit to how much food a person can eat; above some level he will still demand more food than before, but the analogy of this infraclass in his budget will drop. For other infraclasses, saturation never occurs; for others the phenomenon is more abrupt. For some the corellation is negative and rising or dropping. All of this can be represented by the sigmoid; we just have to figure out the proper parameters. I haven't done any such research yet; the figures in cols N, O, P of the "prefmach" sheet are quite arbitrary. But that's what the graph is for; it is a tool for determining the proper constants for the game.
9. Effects of infrastructure
The effects of infrastructure are an issue that needs to be adressed by each model seperately. The output units vector will be the datum that each game model will process to compute the effects. For this part of the game to be modelled, we need to have pretty much settled which infraclasses will be finally used. We must take extra care so that flexibility and customisability are maintained in this (the feedback) too, as they are in the reverse process (the preferences machine and class attributes).
10. Player interface
Being one of the most important issues in each model, infrastructure interface invokes a few issues that have to be discussed.
First of all comes the issue of player intervention in the model. In other civilisation games, the player's control over infrastructure was total. But there infrastucture was handled via city improvements and direct build instructions. In Clash, player's liberties are severely curtailed in this area, to match the real-world capabilities of a ruler. These are not at all insignificant; in most cases throughout history the ruler had always the ability to alter the people's budget through specific legislative restrictions, (this is what happens in col X of prefmach), which were more or less appropriate to the level of Economic Planning. Apart from this, public funds are under a more complete control of the player (this is what happens in columns AF, AH, AJ of prefmach), since they are under political control only, and not under private control too, as it is with private funds. How these are applied is an issue discussed above. Please note that I have used the same cv for the ruler everywhere; in fact all these cv's can be set the to be the same or different, for all places together or each place specifically, according to the desire of the player to micromanage or not his empire.
Finally, there is another way in which rulers exercise their policy and this is price subsidies. We must not confound them with price-setting legislation which is in fact an application on economic planning inside a market economy. In price-setting the ruler bends the market rules and forces a dislocation for which either the producer or the consumer pay the price (for a lower and a higher than market resulting price respectively), but the state remains economically neutral. In price subsidising, the ruler uses the market rules to influence the prices by throwing the state's economic weight to the right direction. In this case the state is economically active and it either gains (from taxing infraclasses) or loses money (from subsidising infraclasses). This money is gained from or lost to either the producer (if the profit margin changes) or the consumer (if the actual price changes) What of these two happens is a very important issue in real economies, but in Clash, where the budget in question is universal, it doesn't matter; the money would be gained from or lost to the "people" in general. Taxing and subsidising is a very powerful tool in the hands of the ruler, with which he can control the infrastructure budget. It has only 2 possible handicaps:
a. It doesn't work with supply- based economies. As it has been already mentioned, prices in supply-based economies are set by the budget and the available commodities, so taxing or subsidising would have only the effect of money-transfer between the state and the people. In supply-based economies, the only way to effect investment is via political control, as demonstrated above.
b. If some infraclasses must be subsidised, others must be taxed, otherwise this will cost money to the state. The problem is not actually the money itself, but the discontent caused by such moves. Because the people, being ungrateful, will probably pay more attention to the burden of the taxes than the relief of subsidies. So, the bigger the intervention of this type, the bigger the discontent it will cause. Of course this applies (even more so) to the direct types of intervention too (as it is shown in the prefmach/social mod section of this text).
As you have noticed, price subsidies are not yet modelled in the spreadsheet. It wouldn't be hard to do so in the investment machine, as long as a way for the bill to be settled were devised. But, specially since the computations are made for all agents together, it sounds silly to adress a preference issue outside the preferences machine. On the other hand, here we have no standalone preferences but preferences linked with prices and actual money transfer. Things could be made easier here if the public and private sector were separated in the computations. So I would prefer to wait and see the final implemetation that we will choose and then apply subsidies.
Another issue concerning player intervention is the "Macchiavelian Ruler" effect encountered in the govt model. If one plays with the player input enough, he will see that one can play with the corellation to achieve the budget he desires. But the limits the ruler can reach with political or governmental intervention are set and since we are discussing modifications on the budget here (and not negotiating the budget itself), the anti-cheating method developped for government policies is built-in in this model. As for subsidies and taxes, manipulation of the market is the essence of them, so there is no issue raised about them.
The last interface issue I want to adress here is the representation of infra units. Plain #s of units are a very dry and counter-intuitive way of representing infrastructure. Representation for most classes will be probably made by the effects of infrastructure. F.e. A units of the "military units" infraclass are analogous to B cavalry units or C infantry units. D units of transp. infrastucture in a square might mean roads and railroads in it, but no highway. E units of water infra in place might mean water for F thousand residents. It's all a matter of translation.
11. Appendix
1. Moving of infrastructure.
Moving of infrastructure can happen in the following cases:
Of course infrastructure that is moved isn't always usable as it is. F.e. say that kapital is 50% mobile and I have 10 units of it in province A. If war breaks and I retreat to province B with 50% of those units, can I install 5 units in province B? Isn't this 50% only machinery, while the factories are left back in province A? Wouldn't I need to buy 5 units locally in province B, to have 10 working units of kapital? Would the cost in commodities be the same as with 5 ordinary kapital units? These are issues that have to be adessed together with the mobilty issue.
2. Destruction of infrastructure
Destruction of infrastructure can happen in the following cases:
For each infraclass, a destroyed percentage should be computed each turn and be summed up with decay, to be applied in the investment machine. What is important (and the same goes for moving of infrastructure) is to find a streamlined way to implement it.
3. Ruler's expenses.
Where could the player spend his money on, except for infrastructure? Here is a list of possible destinations.
1. Introduction
This text is aimed to accompany the infrastructure spreadsheet and to explain how it works. It is also an attempt to explain the philosophy of the infrastructure model used there and to adress the various issues of gameplay and model interconnections that rise from it's implementation.
The infrastructure model presented here is actually an enhancement and a completion of the general outlines given in the economic model, of which infrastructure is a submodel. I owe much to Mark Everson, who provided me with these outlines and with the concept of the preferences machine too. A lot of attention was paid to model flexibility, scalability and customisability, so that the model can be used in whatever level of detail it is desired and with whatever effects are desired, both by the developping team and the scenario creators.
This model can be run at a civ, province or mapsquare level, with minor modifications (which are related with government action; see below), but the reccomended level is definitely the province level. Being run at the mapsquare level (and in equal or more detail than what is in the spreadsheet) would IMO be a computational overkill and should be avoided.
The numbers used everywhere are quite arbitrary, but they are in no great dissacord with historical reality. Of course it won't be hard to spot quite a few correlations that are irrational, not to say inaccurate. But, after all, the spreadsheet is created, except from modelling reasons, as an early tool for determining some reasonable and realistic configurations for the multitude of constants the model demands. Production and prices are taken from the Mid-Tech (A=15) province in the Econ model v.11 spreadsheet. In the example you will see in the spreadsheet, this province has more infrastructure than it can maintain or use, so infra units are in the decline.
2. Infrastructure classes
Infrastructure is divided into classes, each corresponding to one sector of human activity. They are in fact the categories in which the people decide to spend their income. As it is prescribed in the econ model, infraclasses resemble storage containers, where "units" are put in and out each turn, according to the amount of investment, consumption, destruction and decay that is applied upon them by the people's decisions and the game rules.
What generally happens is that a budget is decided (through a process described in the preferences machine) and is input at the investment machine, where it is determined, according to their prices, how many of the already existing units of each class are going to be used this turn and how many new units will be bought. According to each classes attributes, this allows us to compute how much benefit there will be from it this turn and how many units there will be left next turn.
The number of infraclasses is not fixed; it depends on the detail we want to give to the model. Of course, making use of more classes means more complexity, not only because of the number of classes per se, but also because this means that more detailed interactions with the rest of the Clash world are needed, in order to provide all the infraclasses with discrete profiles. The connection between infraclasses detail and interactions detail is of course not linear; but this will be made clear below.
In the spreadsheet I use a total of 20 infraclasses which I think cover the spectrum of people's spending to a sufficient degree. This is actually an expansion of the set listed in the corresponding matrix of the econ model. I tried to create an infrastructure model that is general enough to encompass any kind of spending, so here are included some areas (like Food and Kapital Investment) which are supposed to be (or already are) covered elsewhere (the econ and the govtecon model respectively). If it is proven that they cannot be handled sufficiently as infraclasses and that they need special treatment, they will be removed.
You will notice that many of them can be merged with others into a single class, or split into more classes. This doesn't neccessarily mean that the collection of classes inside a single game will be dynamic (f.e. when flight is discovered, add an "Air Transportation" class). Who knows? this approach, although feasible, may create problems in game organisation and historical accuracy. Instead of this, the model (more specifically the preferences machine) has the capability of keeping unwanted infraclasses inactive, when it would be innatural to spend money on them. So each game can easily have a steady (though not always the same) number of infraclasses.
3. Attributes
Columns N through R in the "invmach" sheet contain a set of attributes which determines the rules with which each infraclass is treated. These are:
- Persistant/Consumed. A dummy variable. An infraclass is consumed (0) when the amount that gets used is lost in the process (this is true for food and consumer goods; it might also be true for other classes too). Otherwise it is persistant (1), which means that a # of units used once can be used again next turn, if they still exist (as it is with all other infraclasses; f.e. housing).
- Mobility. What % of this classes units is mobile and can be taken away from the mapsquare/province/civ the model is applied. Infrastructure in the traditional sense means assets tied to the ground (such as housing and water infra, which have 0%), but here we use an extended meaning which includes mobile goods and military units (with 100% mobility) and other mixed types of infrastructure, which can only partly be moved. These usually consist partly of buildings and partly of equipment, of which only the latter can be moved. This isn't used anywhere in the spreadsheet for the time being. For more details see the appendix.
- Decay. What % of each classes units gets lost each turn. Loss can occur for a variety of reasons, including physical decay (for food), depreciation, wear and tear, even boredom (for recreation). Decay occurs to consumed and persistent classes alike, even if they are not used. Decay should be usually positive (as it occurs from the 2nd Thermodynamic Axiom), but a discussion I overheard at the forum about animals being considered infrastructure made me think that a negative decay could be used in such a case, where the infrastructure units multiply by themselves. The figures will be determined chiefly by the Tech model, although other stuff like Ecology can influence this too. For a good way to do this, check out below how preferences are handled.
- Backup. The % of a classes units that is kept unused, although it can be used. This has sense chiefly for making stores of consumed classes. It can be applied to persistent classes too, but it has no sense. Of course we can say that the % of persistant classes units that doesn't get used for economic reasons is backup, but that's not the actual meaning of it.
- Minimum Output. The minimum (per capita) # of each classes units that are needed for survival. A check should be made to the output each turn to make sure that these needs are covered and if not the budget must be accordingly corrected. Or maybe these should be considered basic needs and be met before the budget is applied. This struck me as very tedious work to do in Excel, so I have skipped it: for now this column does not affect anything. Min Out also depends from time to time and from place to place (it can probably be figured out from the social and ecology models), but for most classes it is zero. The figures I use in the spreadsheet are rather arbitrary, but I think they correspond to the most basic living conditions.
4. The distribution of Surplus Value
The square/province/civ in question produces a given amount of commodities (M1, G40-43) which, using the prices set by the econ model (D40-43) sum up to a certain product, or surplus value, measured in CC. This product is altered by extraction of profits from the place (decreased) or investment in the place (increased), which is made by the ruler who controls it and maybe, in later versions of the game, by private agents too. What is left in the province must somehow be distributed among infrastructure classes (the investment machine does that) but also among the economic agents of the province. That distribution is actually a part of the govtecon model, but for the needs of the spreadsheet, it is displayed in matrixes M3 and M2.
M3: The total product is divided between the people and the state by the Effective Tax Rate, which sums up all kinds of taxes applied plus the profits of public enterprise. The % that goes to the people is distributed among the socioeconomic classes in M2 and it all goes to infrastructure. Since this is normally done in the govtecon model, M2 works in an improvised way; the user of the spreadsheet is expected to set the TI per class numbers (H27-H30) so that their sum equals the amount transferred from M3 (it must be H31=H32). I hope that you will excuse me for the inconvenience.
The money of the state on the other hand is only partially redistributed (investment in infrastructure is considered redistribution) and this part is set by the redistribution variable (from the govtecon model). The part that does not go into infrastructure is at the disposition of the ruler for his "expenses" (see Appendix 3).
Redistributed money is further more divided to the levels of government involved. How many they are, it depends on the level the model is run; if, like in the spreadsheet, it is on a mapsquare basis, they are 3 (Local Govt, Provincial Govt and Central Govt), if it is on a province basis they are 2 (PG and CG) and if on aciv basis, there is only CG of course. The measure for the division of this budget is the Centralisation variable that will be hopefully provided by the govt model. The funds in question are of course entirely invested in the specific place, but by more than one agent (f.e. the PG builds roads in the province, but the CG builds the highways).
The funds that each level of government gets it's hands on is furthermore distributed among the AI and the player, according to the ruler's pol.power. This way, the player's intervention can be specialised in whatever degree he wishes, allowing both micromanagement and general guidance of the infrastructure system (see preferences machine).
The funds discussed here include neither the tax money the central govt is entitled to collect and move away from the place in question, nor the money that they decide to specially invest in the place. These should be applied externally upon state investment (M3, cell L31) and move the total % either above or below 100%.
5. Prices
As you can see in the "invmach" sheet, one unit of infrastructure costs a given amount of commodities (F, P and S) to be bought (columns B, C, D) and another amount to be used (columns F, G, H). If these amounts are combined with the current local prices of each commodity (matrix M1), two prices are determined for each infraclass (costs in CC): the input price (column E) and the output price (column I).
The costs in commodities depend chiefly on technology and are expected to be given by the tech model. Because the definition of a infraclass unit is arbitrary, in the input section I have made costs in commodities all sum up to 1, but that is not necessary (like the cost of services always being 1). For obvious reasons, this doesn't happen with the output costs, which are generally much smaller.
Another set of costs (columns K, L, M) and a price (column N) can be derived from these, to provide us with information about the maintenance cost. This is defined as the total of input and output cost that will be needed for one unit of infrastructure to be used used this turn and remain intact for the next turn. This depends of course of the decay and the persistant/consumed dummy variables. This information is not essential for the investment machine, but I thought it would be interesting to display.
But how are the local prices for each commodity computed? The econ model has more or less defined a procedure for this, although it is not finalised. According to this, prices are determined from the amount of Kapital, Resources and Labor required to produce them (production function). Then, as the state takes it's taxes in whatever form it desires (Food, Products or Services), prices are recalculated, to correspond to the new quantities of available commodities in the province. Then trading occurs and, since specials are turned into commodities and commodities themselves get traded too, the quantities change again and so do the prices. With those final prices and quantities the infrastructure model was to work.
However, this infrastructure model does not maintain this balance between the amounts of commodities available and their prices. With the prices as input, it calculates the provinces demand for commodities (M1, I40-I43), which, although it is (at the local market) worth the same as supply, it is in general different from it. This difference between demand and supply can be covered only in two ways: either external trade which will bring supply to the level of the demand (demand based economies) or rearrangemnt of prices which, through another iteration of the investment machine, will bring demand to the level of supply (supply based economies). Of course both can happen in the same time; if supply can move only part of the distance (because of limited trade capacity), then demand has to cover the rest of it. Ancient economies, because of the physical and political restrictions to trade, were mostly supply based. Nowdays, with the modern technological means and the globalisation of the economy, most of the world's economies are demand based. As technological means progress and as international trade relations improve in quantity and volume, economies of civs all over the Clash world will move from supply based to demand based and this will be a major cool feature of the game. I think that this is the market vs. traditional economy feature that Mark has mentioned in the econ model (as a feature that still was not implemented). So this is how things should work inside the game (see M1):
- Initial production. Quantities and prices are set. (col G)
- Commodities are extracted or invested in the provincial economy by the state. Quantities and prices change. (col H)
- Demand is computed by the investment machine (see below how). (col I)
- The merchants cover part of the difference (col J), by buying and selling commodities (whose local values always zero-out; col K) and make a profit out of the difference between local and global prices (cell K46). Quantities are finalised (col L) and prices change.
- Demand has to be equal to the final quantities, so the investment machine has to be reversed somehow to figure out the final prices which will match demand with supply.
Prices rearrangement throughout all these steps is not modelled in M1; this is handled by the econ model. The last step is not yet implemented in the spreadsheet. There are two possible ways with which we can implement it:
a) Since the investment machine takes in the prices vector P=[f p 1] (1x3) and, through a certain transformation function, which is a 3x3 matrix M, transforms it into the quantities vector Q=[F P S] (1x3) so that Q=P*M, all we would have to do is find the inverse matrix M^-1, so that P=Q*M^-1. I don't know how hard the math for this will be though.
b) Make a few iterations of the investment machine, until the difference between supply and demand converges to zero.
6. The Investment Machine
The investment machine is the component which does the bookkeeping for each infraclass. The current plan (and what you see in the spreadsheet) is to apply it once for each place (square, province, or civ), to compute the infrastructure invested by, belonging to and used by everybody in this place. The budget that it uses (columns W and X) corresponds to the collective preferences of all the social classes and the various levels of government involved (see "prefmach" sheet) and to their collective amount of spending (see matrix M3, cells O27, O28). Of course it can be used seperately for the public and the private sector, or for each socioeconomic class and/or for each level of government. The preferences machine would have to be altered (see below) and the investment made upon each agent's spending money (as they are analysed in M3 and M2). What happens now is that we are aggregating all the agent's preferences with weights depending on their money and political power, so that the overall effect is the same, while the detail of who possesses what and benefits from what is lost. But at the same time we are getting rid of quite a lot of complexity and computational weight. If, after all, the lost detail is proven essential for some reason (I can imagine this happening for public/private, but not for social classes), we can easily change our method.
Having the # of infra units available this turn, we can find out how much they need to be maintained, which is there, like the maintenance cost, for informative reasons for the time being. Having also the budget, will let us compute how many of the existing units get used. The formula there says that we use as many units as our budget will afford (if the output cost is 0, we use all of them of course), with the exception of classes which have backup indicated, where the backup% is kept unused. The rest of the money partaining to each infraclass goes then to new units, the number of which is such that the remaining money can pay for their input and output (buying and usage). Provision is made for those units which will be bought but not used (backup again). The input cost is also computed (AB). Then, the total output is derived, by adding the old used units with the new used units. This vector will be used by the game models to calculate the effects of infrastructure. The output cost is also computed (AD). Finally, the units that will remain in the province for the next turn are computed, by applying decay to the sum of old and new units. (AE) For the consumed infraclasses, the output is subtracted from the sum. For each column in units, a column indicating the cost or the worth in CC is displayed, chiefly for informative reasons.
Having finished with the main investment machine, matrix M4 computes the resulting demand of commodities. For both input and output and for each of F, P, S, the sum of the products of units*unit_costs is computed and all these are summed up. As it is expected, the value of the demand (AF28) is equal to the value of the supply (O27).
7. The Preferences Machine
The basic idea behind the preferences machine is to take a "base budget" vector, which is common for all situations in Clash (so it will be a constant of the game) and alter it by applying subsequent percentile modification vectors ("mods"). The final outcome (column AM) is then translated into the budget (column AN) that will be used by the investment machine. The elements of mods are percentages between -100% and 100%. Each mod is related with a certain factor that is known to affect infrastructure. Currently there are mods for Ecology, Technology, Population Density, Culture, Society, Emergencies and Government, but more could be added. The computation of mods has also various degrees of complexity; some mods are given as-is in the spreadsheet, others are computed directly in one stage and finally others require multiple stages of computations.
The mods are applied to the base budget in a serial (subsequent) fashion, so that the outcome is something like Base*(1+Mod1)*(1+Mod2)*… *(1+ModN). The actual order of the mods doesn't matter of course, but I have placed them in order of fundamentality / long-term activity. But mods can also be applied parallelly, either totally or partially, so that the "Total Mod" is the weighted sum of all the mods, or the product of mods and weighted sums of mods (partial mods). For example the Social and Government factors could be computed together, using the percentages of the total product that are invested by the people and the govt respectively (matrix M3, cells M28 and M31 respectively). In parallel computations, the sum of weights must be below 100%, to ensure that a mod never gets below -100% (there is no problem if it gets above 100%). The difference between serial and parallel computation is that the serial mods are independent of eachother and have total control over the budget, while the parallel ones are related, act simultaneously and have control over part of the budget.
But how are mods themselves computed? The exact functions used depend on the mod in question, but the way these functions are defined is uniform. Each mod has a "correlation vector" (cv, shortly) and a special weight for each game variable that we decide to connect with it. Exactly like in the parallel application of mods, the mod is the sum of the products of all cv's with their respective special weights. For the cv's that are derived, the same thing applies; they are computed like the mods are computed; the only difference is that more formulae than just the sum of products can be used there.
The correlation vector may be set by us or the scenario creators, may be input from the ruler, or be derived by other cv's. It defines in which way the infraclass in question is related to this certain variable or agent. The corellation can be inexistant (0%), positively extensive (100%), negatively extensive (-100%) or intermediate, high or low. The concept of corellation is extensively used in statistics. As for the special weights, they determine the extent of the effect. They depend on the variable or on external data concerning the influence of the agents in question. The examples of the mods used in the spreadsheet should be enlightening.
Apart from the main calculations, there are also a couple of informative figures in the "prefmach" sheet. First of all, in row 25 there are the special weights of factors inside a specific group, as opposed to the overall special weights, which are in row 26. According to the case, one of those sets is use for the computation of the mod. Then we have the deviation (col AO) and the percentile deviation (col AP), which compare the final budget with the base budget.
Last but not least, there is Mean Square Corellation (row 24), which is, as the name implies, the mean of the squares of the elements of each mod or cv. It is very useful while setting the constant data of the model, as an index of overall corellation of each factor with infrastructure. It is obvious that, for parallel computations, if we want the representation of each variable to be fair, the MSCs must be approximately equal. But this is no hard rule: if we indeed feel that a variable is not so important, it's MSC will be lower; but this will happen on purpose and not accidentally.
Ecology Mod: It is very well known that according to the climate of the area, the people's needs vary greatly. F.e. heating, as well as food (calories) are more needed in arctic areas than in the tropics and water infrastructure is needed more in arid areas. Here I assume it given by the ecology model. It can be computed like other mods are, according to the basic climatic variables, whatever they are.
Tech Mod: Technology is a major modifier of infrastructure, not only referring to prices and decay, but also to the preferences of the people. F.e. modern day people seem to spend relatively more on communication and transportation than ever, because that is what their modus vivendi dictates. We must take extra care so that this mod doesn't reflect the changes in infra unit costs or PCI that are also due to technology, but choices that can only be correlated with the technological environment. As for ways of computing this mod, this is TBD. IMO, each infraclass mod should be linked to the apropriate L1 or L2 Tech Level, through a vector of game constants.
Population Mod: This currently involves only pop density. It is well known that all kinds of networks are cheaper in densely populated areas, while there is generally more investment in the service sector, but I won't discuss this here. It could be correlated to other demographics as well (and thus become the mod for the pop model) and it could also be corellated to the capital status of the square or province in question. The "independent" variables that I use is population density (defined arbitrarily as population/1000, so that the special weight becomes 100% when population reaches 1000 heads) and it's square, so that the sum of products gives us actually a second degree polynomial function for the mod. In this example density is low, so the MSC is quite low too. This is an example of how we can compute a mod from one variable using a polynomial function which is totally under the control of the Clash Team, or the scenario creator. It is known that, by use of the Taylor/Maclaurin functions, any single-variable function can be easily aproximated by a polynomial; the flexibility thus provided to us is unlimited.
Culture Mod: Culture is surely a very long-term modifier of investment preferences but it surely is important. In columns H through M, these cultural attributes that are considered to have an effect in any way to infrastructure (all of them, except Ethnic and Religious Discrimination, IMO) are assigned cv's and use as special weights their attribute values, to compute the mod. Of course the sum of the weights is more than 100%, so the proper thing mathematically would be to use the reduced values of row 26, which sum up to 100%. But since the numbers here do not cause the < -100% problem, row 25 gives a better result, since the effect of each attribute is independent of the values of the other cultural attributes. Here we can see how important it is for the proper function of the preferences machine to pick the proper special weights for each cv.
Social Mod: This is the first of the two really complex mods. It deals with the part of infrastructure bought by people's money and that's why the sum of it's weights (cell X29) is equal to the percentage of the product that "goes to the people" (see matrix M3). One would expect all the influencing weight to go to the socioeconomic classes, but this is not so; only (1-EP)% of it is under the individual control of the whole of socioeconomic classes, while EP% of it is under the control of all classes that hold power (all except the XC of course). This adds the MC, RC, BE and of course the Ruler, each one posessing their own cv. The Ruler's cv is of course input by the player, while the other three are constants for the time being (they could possibly be derived by other variables but there is no need for it). The influence is distributed along the lines of pol power for the EP% and (as it has been already mentioned) according to total class income for the (1-EP)%, which means that the XC has an influence too. The influence (special weight) of the socioeconomic classes is the sum of these two factors. It is important to notice here that this type of political intervention over private funds will certainly cause discontent to the socioeconomic classes. This could be computed using only EP, but it would be more fair to use the sum of the products of the MSCs and the influences of the socio-political factors.
Unlike the institutional classes, the preferences of the socioeconomic classes are derived. They all depend on a single variable for now: PCI. This is done through the sigmoid function, which (in the "prefmach" sheet at least) has 3 parameters. Each one of the parameters has a cv with PCI, which actually gives the value of the parameter for each infraclass. Each of the socioeconomic classes cv's is an instance of the sigmoid function (posessing these parameters), corresponding to the specific classes PCI. More on the sigmoid function and on why it was chosen will be found below.
Emergency Mod: It encompasses all changes in preference that an emergency such as war or a natural disaster would bring. During wartime, investment in Military Units and Infrastructure is multiplied. Pollution does the same for Nature Preservation; so does disease for Healthcare. A disaster that has caused the distruction of a certain type of infrastructure (f.e. an earthquake that destroys Housing) will lead to an emergency situation where spending in that type of infrastructure is increased. The exact method of computation for this mod will be available when a total emergency model is developped.
Government Mod: This is the other complex mod, covering the part of the budget that belongs to the state. The difference between the government modifiers and the aforementioned socio-political ones is that the first ones adress infrastructure that is considered public (both in ownership, in control and in benefit), while the second adress infra that is privately owned and benefited, but publicly controlled. So f.e. the government mod would not have much to do with goods, but be closely related to services networks and administrative infrastructure. It is computed for the player and the AI in each one of the administrative layers effective (local, provincial, central) using as special weights the state budget described above and in matrix M3 in the spreadsheet. The ruler's cv's are of course input by the player, but the AI cv's are derived from the government policies. For the time being I am using only Economic Planning, Social Policies, Foreign Policies and Centralisation, but Private Property could be added too, if we decide it is important to include (The definition of PP I am using is that it refers to the productive infrastructure - in other words the Kapital - and not to other types of infrastructure). The cv's for policies are fixed and the formulae which link them with the AI cv's are as follows:
(col AE) CG=FP*FPcv^2+EP*EPcv+SP*SPcv^0,5+CE*CEcv
(col AG) PG=FP*FPcv+EP*EPcv+SP*SPcv
(col AI) LG=FP*FPcv^0,5+EP*EPcv+SP*SPcv^2-CE*CEcv
This means that the CG is naturally inclined to a budget dictated more by FP and less by SP, while the inverse happens with the LG. CG is positively affected in it's choices by centralisation, while LG negatively and PG not at all. If we run this at the province level we will probably have to replace the PG formula with the LG one. In the civwide case, the single government would probably use the PG formula. All this is open to revision at any time of course.
We could also consider creating economic discontent from the government mod, as an expression of the people's in-bred resistance to the government, using the 18% special weight and the MSC of the government mod as an indicator. However I am against it, since the people usually expect the state to invest in different things than they do (public goods), so why would they be unhappy about it? Actually, I am only pointing out the capabilities of the model here.
The preferences machine that is shown in the "prefmach" sheet is set up so that it can produce a budget appropriate for computing investment for all agents together. If we decide to make multiple computations, it will have to change appropriately. The good thing about the way things are run in the preferences machine is exactly this; it gives us the capability to assemble and dissasemble it at will.
8. The Sigmoid Function
In the sheet "sigmoid", one can see the infamous Sigmoid Function in action. It is nothing but the well known function arctanx, the inverse of the tangent, properly enhanced with parameters. It is characterised by it's S-type shape, confined between two limits and by the turnpoint, where the second derivative changes it's sign. I have created two implementations of the sigmoid, on with three parameters (column B) and one with four (column C). These I have graphically represented for the variable range 0 -250, inside which we expect PCI to fluctuate, from the antiquity to modern times. Play with the parameters and see how the functions behave in the graph.
The tri-parametric one is earlier and it is the one you saw implemented in the "prefmach" sheet, for corellating PCI with infrastructure. It's parameters are Height, Turnpoint and Slope. It's value at 0 is always near 0, so in fact it can't be shifted up or down. The tetra-parametric one is more complete and (as you can see) it can begin near any value. It's height is the difference between it's two limits. Since this function is transposed (the actual arctanx has it's turnpoint at 0,0 and it's limits are +/-pi/2), it always passes near but never through the points 0, lim(-) and 250, lim(+) that characterise it. How near that is depends from the slope.
I hope that after playing with the sigmoid, the reason I have chosen it for the corellation of PCI with infrastructure is obvious. It is the best way (at least that I know of) to represent the saturation that occurs in the need for certain goods as PCI rises. There is a limit to how much food a person can eat; above some level he will still demand more food than before, but the analogy of this infraclass in his budget will drop. For other infraclasses, saturation never occurs; for others the phenomenon is more abrupt. For some the corellation is negative and rising or dropping. All of this can be represented by the sigmoid; we just have to figure out the proper parameters. I haven't done any such research yet; the figures in cols N, O, P of the "prefmach" sheet are quite arbitrary. But that's what the graph is for; it is a tool for determining the proper constants for the game.
9. Effects of infrastructure
The effects of infrastructure are an issue that needs to be adressed by each model seperately. The output units vector will be the datum that each game model will process to compute the effects. For this part of the game to be modelled, we need to have pretty much settled which infraclasses will be finally used. We must take extra care so that flexibility and customisability are maintained in this (the feedback) too, as they are in the reverse process (the preferences machine and class attributes).
10. Player interface
Being one of the most important issues in each model, infrastructure interface invokes a few issues that have to be discussed.
First of all comes the issue of player intervention in the model. In other civilisation games, the player's control over infrastructure was total. But there infrastucture was handled via city improvements and direct build instructions. In Clash, player's liberties are severely curtailed in this area, to match the real-world capabilities of a ruler. These are not at all insignificant; in most cases throughout history the ruler had always the ability to alter the people's budget through specific legislative restrictions, (this is what happens in col X of prefmach), which were more or less appropriate to the level of Economic Planning. Apart from this, public funds are under a more complete control of the player (this is what happens in columns AF, AH, AJ of prefmach), since they are under political control only, and not under private control too, as it is with private funds. How these are applied is an issue discussed above. Please note that I have used the same cv for the ruler everywhere; in fact all these cv's can be set the to be the same or different, for all places together or each place specifically, according to the desire of the player to micromanage or not his empire.
Finally, there is another way in which rulers exercise their policy and this is price subsidies. We must not confound them with price-setting legislation which is in fact an application on economic planning inside a market economy. In price-setting the ruler bends the market rules and forces a dislocation for which either the producer or the consumer pay the price (for a lower and a higher than market resulting price respectively), but the state remains economically neutral. In price subsidising, the ruler uses the market rules to influence the prices by throwing the state's economic weight to the right direction. In this case the state is economically active and it either gains (from taxing infraclasses) or loses money (from subsidising infraclasses). This money is gained from or lost to either the producer (if the profit margin changes) or the consumer (if the actual price changes) What of these two happens is a very important issue in real economies, but in Clash, where the budget in question is universal, it doesn't matter; the money would be gained from or lost to the "people" in general. Taxing and subsidising is a very powerful tool in the hands of the ruler, with which he can control the infrastructure budget. It has only 2 possible handicaps:
a. It doesn't work with supply- based economies. As it has been already mentioned, prices in supply-based economies are set by the budget and the available commodities, so taxing or subsidising would have only the effect of money-transfer between the state and the people. In supply-based economies, the only way to effect investment is via political control, as demonstrated above.
b. If some infraclasses must be subsidised, others must be taxed, otherwise this will cost money to the state. The problem is not actually the money itself, but the discontent caused by such moves. Because the people, being ungrateful, will probably pay more attention to the burden of the taxes than the relief of subsidies. So, the bigger the intervention of this type, the bigger the discontent it will cause. Of course this applies (even more so) to the direct types of intervention too (as it is shown in the prefmach/social mod section of this text).
As you have noticed, price subsidies are not yet modelled in the spreadsheet. It wouldn't be hard to do so in the investment machine, as long as a way for the bill to be settled were devised. But, specially since the computations are made for all agents together, it sounds silly to adress a preference issue outside the preferences machine. On the other hand, here we have no standalone preferences but preferences linked with prices and actual money transfer. Things could be made easier here if the public and private sector were separated in the computations. So I would prefer to wait and see the final implemetation that we will choose and then apply subsidies.
Another issue concerning player intervention is the "Macchiavelian Ruler" effect encountered in the govt model. If one plays with the player input enough, he will see that one can play with the corellation to achieve the budget he desires. But the limits the ruler can reach with political or governmental intervention are set and since we are discussing modifications on the budget here (and not negotiating the budget itself), the anti-cheating method developped for government policies is built-in in this model. As for subsidies and taxes, manipulation of the market is the essence of them, so there is no issue raised about them.
The last interface issue I want to adress here is the representation of infra units. Plain #s of units are a very dry and counter-intuitive way of representing infrastructure. Representation for most classes will be probably made by the effects of infrastructure. F.e. A units of the "military units" infraclass are analogous to B cavalry units or C infantry units. D units of transp. infrastucture in a square might mean roads and railroads in it, but no highway. E units of water infra in place might mean water for F thousand residents. It's all a matter of translation.
11. Appendix
1. Moving of infrastructure.
Moving of infrastructure can happen in the following cases:
- Normally, f.e. military units will move all the time.
- Pillaging. When an enemy invades, the most he can take is the mobile part; the immobile part he will have to destroy or leave it alone.
- Desertion. When a civ deserts a place (by will, because of a natural disaster or because of an invasion), they usually take whatever of value can be moved. F.e., in WW2, during the German invasion, the Soviet Union moved all it's industry to the East of the Urals, thus preserving it's industrial base and being able to counterattack, albeit the great loss of territory.
- Special Trade. Perhaps in the future we might want to enhance out trading system with more than just the Specials. Infrastructure units of a certain tech level can be traded with civs that are not so technologically advanced, usually at an extravagant price. (like what's always happened with weapons or what's happening with computers nowdays).
Of course infrastructure that is moved isn't always usable as it is. F.e. say that kapital is 50% mobile and I have 10 units of it in province A. If war breaks and I retreat to province B with 50% of those units, can I install 5 units in province B? Isn't this 50% only machinery, while the factories are left back in province A? Wouldn't I need to buy 5 units locally in province B, to have 10 working units of kapital? Would the cost in commodities be the same as with 5 ordinary kapital units? These are issues that have to be adessed together with the mobilty issue.
2. Destruction of infrastructure
Destruction of infrastructure can happen in the following cases:
- War. When a place is a theater of war, part of it's infra gets destroyed in the process. This also happens during riots and revolutions. It is blind for most infraclasses, but it certainly aims these of tactical importance, like military, transportations and communications infra.
- Looting and pillaging. When a place is invaded or raided, part of it's infra is destroyed on purpose by the invading or retreating army. Again it can occur during riots or revolutions. It is usually selective.
- Bombardment. This contains all ranged attacks on infrastructure, having a strategic aim. It can be selective or be totally blind (like carpet bombing or nuclear bombing is).
- Sabotage. Caused by foreign spies or by underground organisations, these events are selective towards certain infraclasses.
- Natural disaster. According to the type of the disaster, some infraclasses are immune to it (f.e. military units, although many a fleet has been sunk in a gale), and some are specially affected (f.e. housing in a quake).
For each infraclass, a destroyed percentage should be computed each turn and be summed up with decay, to be applied in the investment machine. What is important (and the same goes for moving of infrastructure) is to find a streamlined way to implement it.
3. Ruler's expenses.
Where could the player spend his money on, except for infrastructure? Here is a list of possible destinations.
- Diplomacy. As it is well known from other civilisation games, sometimes large sums of money are given to foreign nations:
- Tribute
- War reparations
- Gifts and loans
- Purchase of land
- Purchase of technology - Secret Services. The player will have access to many covert actions both in the internal and the external scene. For most of them he will need money.
- Bribes of politicians and military units
- Assasinations
- Frame-ups
- Intelligence gathering
- Sabotage of various forms
- Formenting revolutionary organisations - Special Projects. The construction of all types of Wonders of the World, minor or major will probably demand extreme funds, which it will be difficult to be raised through the normal budget (at least for those wonders that are not natural or obtained by chance). Each wonder will probably inherit it's commodity costs and probably some attributes from a specific infraclass. When enough units of this infraclass are gathered, they will be replaced by the wonder in question, which will thereafter follow the rules of the wonders model.
). I think it is very important that the flavour is added by translating the infraunits into some game terms (as you suggested in 10).
).
?
Comment