1. Province Formation

The idea in the generation of provinces is to keep it flexible. The player should be able to form whatever provinces they like. There will be some general guidelines for how large provinces can be given any particular level of technology and communication and transportation infrastructure. But the idea here is that these restrictions should turn on very slowly, so as not to impose an arbitrary burden on the player. For now there will be simple advantages and penalties associated with whether the province size and shape falls within certain bounds. Since we don't have roads implemented yet, this will be exceptionally crude. The basis for the economic modifiers will be distance of the square in question from the provincial capital, with a simple modification for water transport efficiency. The distance scale is that an adjacent square (with a common edge, diagonals don't count) is distance 1 away. Movement by water, either sea or river, counts as half the distance of land movement. You can combine water and land movement.

The provincial modifiers for economic and government activity are weighted by the population of each square. So a low-population square won't make much difference one way or the other. The way to read the equation below is that distance of a square from the provincial capital gives an overall economic modifier (Econ.) And an overall governmental effectiveness modifier (Gov't). The government modifications are of course pending approval from the government model side. The modifiers determined are then weighted by the population in each square to determine the overall modifier for the province. The player shouldn't have to do any of this calculation, just select a square that is to be added or removed and see how this changes the overall bonus/penalty. Note that these modifiers are just a first shot and will probably be changed.
Econ modifier (%) = 5-3x Distance
Gov't modifier (%) = 15-3x Distance
These modifiers clearly favor small provinces. However, there are also advantages to large provinces, such as being able to build things like weapons for outfitting a complete unit of troops more quickly. The notion is to eventually have these modifiers be somewhat balanced so there's no huge benefit to very small provinces. We're not really at the point to evaluate that fully yet, so I'm just using a guess.

2. Provincial Economics

The idea here is basically to use the Econ model as previously presented, but leave out all specials, and trade. I would like to work in some simple infrastructure, but am not sure if we will have time. Either with infrastructure or without, each province in Demo 5 is basically an economic island with no connection to the rest of the world other than supplying money and military hardware and personnel. Since it's not clear if we will be able to get to infrastructure or not, I think the best approach to take for the demo is to use an approach where the player will have a significant role. In this case I would like to use a Command Economy. This is similar to the system in civ where the government just tells everyone what to do. In terms of the current clash system what this simplified system will be doing is setting the tax rate to 100%. The government will then give back to the people some fraction of that to live on, and use the balance for building economic improvements and military hardware, or keeping it as cash. Normally a command economy has the penalty that when the government gives back it is counted only at something like 80% value. I think we should skip that for the demo because it's very hard for a near-subsistence economy to work properly as a command economy in the currently planned final system.

Internal Details of the Provincial Economy (this section assumes you are fairly familiar with the Econ model, if you haven't read over what is on the web page, then this won't make much sense to you)

We will have four types of production in Demo 5:
Food (F), Resources (R), Production (P) and Services (S).
Because there is no trade yet, production will be limited by the locally available amount of resources. At the lowest level of technology one "head" (1000 people) produces five units of food or services, and 10 units of resources or production. The reason for the difference for resources and production, is their resources are not used directly, but can only be an input for production. So if you have one head working resources, and one head doing production, the net output is 10 finished goods (production) which is the same level of productivity as in the other two sectors.

Prices:
the people have desires for Food, Production, and Services. Their level of desire for these things changes as the economy develops. They will also to a limited extent make trade-offs between the things they desire based on local availability. This is handled behind the scenes using a simple utility function. By assuming that the people all have the same utility function (desires for the produced commodities) one can fairly easily determine prices in the province from the utility function. I have arbitrarily set the price in the service sector = 1 unit of currency. (I'm looking for a better way to include the value of money without making it too complicated, suggestions welcome) After this definition, the prices for the other commodities (depending on the availability of all commodities per head) follow immediately from the utility function. The prices are:

Price of Food = 0.25 (S+ 3.5)/(F- 3)
[Note this is undefined or negative for F <= 3, but that is below starvation level]
Price of Produced Goods = 0.5 (S+ 3.5)/(P+ 1.5)
the price of resources will be strictly determined by the trade system, so it is omitted here

I need to say here clearly that I'm not completely happy with my utility function and approach. However, I think it's plenty good for a first shot at the model.

So for a "Balanced" economy (the price of each good is one) at near-subsistence level, the production per capita is 4F, 1/2 P, and 1/2 S. This is a minimum of food, clothing and shelter acceptable at a destitute peasant's level. However, it includes a little excess production, and a fair amount of excess services so that the player can get Something out of those peasants. That level of food is right on the edge of starvation. Below 4F the population level will decline. The decline is slow near a value of 4, and much faster when true famine sets in around 3.5. The extra amount of services allows for taxation at up to a 12.5% rate without starting to kill off the people. We can probably work out something better for the long run.

The "balanced" economy cited above will only very rarely occur. Usually a province will have some advantage in terms of its land, resources, or other factors, that lead to efficiencies of production in one area or another. In this case the prices are set using the Actual per capita production of the province. This can lead to things like the price of food being lower than one (rich agricultural area) or greater than one (usually an area poor in farmland). So when the player builds weapons for military units, it behooves them to search for a province with the lowest price. I think this search will usually be handled automatically. I don't know how much intelligence we can put into the automatic selection of the best place to build weapons and Demo 5, but eventually we should be able to make it Very smooth.

An Example. . .

Here is a simple table showing the particulars of a provincial economy. This province is probably more imbalanced in terms of what it produces than most will be. It is very food-heavy at the moment. That might occur in a game were agricultural technology is the first thing to be improved, and there is a long wait before the other technologies take a step up. I don't have time to put in the whole description at this point, so I'll just put up the table for people to look at: Province Econ Chart. I tried to put this table directly into the discussion earlier today, and it made a Complete Mess, so you'll just have to go to the link if you're interested .

Here is a simple example of what a particular province might look like. The chart is in the link above. I'll explain basically what is going on. The first let's start with the food row...

The sites column says how much arable land there is available. As technology changes this number might change also. If we go with resource depletion and degradation it might also be able to be reduced with time. Next across it is "Workers". This is simply the number of heads (1000 people) working the sites. With 72 workers, there are still 8 sites left available in the population increases. It's possible that in a more advanced model extra sites available could boost the productivity and the farming sector with the same number of heads as workers. Next comes tech level. This is basically the amount that can be produced per site if the appropriate investments are made (although for resources and production it's actually half the productivity). In the case of the food sector the tech level is six. The next two columns actually show whether investments have been made in the sites or not. The sites@5 column shows the number of sites using the technology that was available at the beginning of the game. In this case ten of the 80 total sites remain in their original condition. The next column shows that 70 of them have been upgraded to the capability to produce six units of food per site. Workers in that sector automatically go to the higher productivity sites. The "produced" column just shows the total production of all occupied sites. In the case of food it is 430 (= 70x 6+ 2x 5). The "per capita" column just shows the production per head. Per capita amounts are what is used in the pricing formulas. And finally the price is obtained by using the correct formula, in this case the one for food. I don't want to go through the whole table step-by-step, so here's just one other note. The resources and services sectors are also at tech level 6. However, none of the sites have yet been upgraded.

Taxation

Taxation is very simple in a command economy like we'll have in Demo 5. The effective tax rate is just the price of the things you build divided by the total economic output. This will usually be either money, site improvements, or military units. Depending on how heavily the people are taxed, their economic happiness will change. At some point (TBD) economic unhappiness will translate into lower productivity or outright revolt.

The two simple components that go into taxation are the total income of the province, and the tax rate. The total income is at this stage just the sum of all the commodities produced times their prices. So it equals the food produced times the price of the food plus... things will get more complicated later, but for now that's it. For the sample province in the table the total provincial income is 471. So a 10% net tax rate would give the government about 47 clash cash units of income. The government can take it as all-cash, and the 47 would simply go into the treasury. Alternatively, it could take some of its taxes in food to feed military units, or goods and services to improve the economy through improving sites if the technology is adequate. The province I used as an example would be an excellent choice for buying food, since it overproduces food and the price of food is low there.

The utility function approach results in dynamic prices. When the government purchases a large amount of a particular commodity, the price will increase as the amount of the purchase grows. Once the trading system is in place, these effects will be taken care of automatically. Until then, I will use a simple average price formula that considers the amount of the good purchased. I already have the formula figured out, but I don't want to complicate this by posting it.

3. Technology and the economy

I need to see exactly what the new technology system looks like a first, before I can say anything in detail here. However, it's clear that technology will provide for improvements in agriculture, resources, production, and building military hardware. Usually getting the most out of technological improvements will require investment as well as the new technology itself.

4. Building military units

Again, I need to wait a little bit to see exactly what the proposed system will look like. But based on previous conversations it will probably consist of taking particular weapons and adding manpower and training to make a unit. I'll rely on the military group to give me some idea of their view of the relative costs of weapons and training.

I will try the flesh out this idea further tomorrow. Probably, I will just add to this post.

Anyway I have a small suggestion with regards to food. Depending on the population growth model you have decided to use food will probably be a factor. I was wondering if we could have 2 levels of food consumption, that is "basic" (just surviving) and a further threshold value for doing well. This can be used to effect the price of food. Which in turn can effect tax and happiness. anything left over after all the population is at the 2nd level could be traded. (Some particularly bad leaders could trade food at under this level, namely stalin and english overlords in ireland. This greatly upsets the populous and can kill them off and cause immigration, but it does supply money.)
As well as tax effects the population that is well fed would contribute towards population growth while that at the basic level would contribute less due to higher mortality rates and the like. The well fed people are also going to be happier.

Is this too detailed?

The food thing is already covered in much more detail than you requested by the utility function. People's desire for food goes from subsistance 4f per capita to about 50f per capita for modern leading-edge economies (50f means lots of meat and other 'grain intensive' specialty items, we obviously don't eat a bushel of grain a day...). The utility function handles it all. I'll give some details at some point. Taking out food when it is high-priced is indeed higher taxation than taking the same per capita amount from a low-food-price province so it works out just like you say.

Province modifiers... is exactly what is in the econ model (exact methods TBD). Of course I don't want it to be too realistic or most inland provinces would have to be smaller than a square

One question I have is to do with the rate of construction. Will improvements have a direct effect on the construction rate? (EG.Will construction of additional shipping yards increase the number of ships that can be built in a turn?)

There will be no arbitrary limitations on what you can build in a turn. I'm not really as far as shipyards yet, but I guess if it were big enough, and there were enough resources you could build many ship units in a turn. More shipyards in different places would definitely help you crank out a navy faster. (Less stress on each local economy than just having one Big shipyard for the whole civ.)

For testing the govt model, we absolutely will have to have some production and consumption.

For the Govt model, I just need to know if the basics are right -- 4 resources?

'Food', 'RawMaterials', 'FinishedGoods', 'Services'?

And all produced in 'units' -- so an int can store their values?

The current plan is to have sites and population at the map square level. We never determined whether to allocate population to each sector in each square, or whether we would just calculate that when (only very occasionally) it was needed. A simple calculation involving average workers per site at the province level, and the pop in the square would give the right number.

But at least as of now, all the production actually happens on the province level. So in some sense its irrelevant where the workers are. (But we would place them in the sensible places anyway.) This is another of those tradeoffs to reduce clocks. We could potentially go to production at the square level if we have the clocks to do it. But running the whole econ model at the square level would IMO take too much time and Way too much memory. (This is part of the 10MB I claimed above since I anticipated you would want to go this way based on the 'Culture Wars' )

Determining production info only at the province level creates a few serious problems, and does not seem to yield the proper numbers:

1) Doesn't that mean no cities/densely populated mapsquares, production-wise? A farmsite would get the same number of workers as any other farmsite in the same province regardless of fertility and soil quality? Regardless of how many workers are actually present? Poor producing gold mines get the same number of workers as highly productive gold mines? Real problems seem to crop up when you don't have enough pop to work all sites (which will likely be the norm). This seems to mean that people are required to micro-manage sites to an annoying degree, changing the number of sites per mapsquare per province every turn, as pop increases/decreases (or the AI will have to do this for them every turn). Which is also highly unrealistic. Using 'average workers per site' thru an entire province really loses a lot, doesn't it? I do not like that loss of detail.

P.S. -- I, of course, disagree with the basic assumptions about 'clock cycles' ya'll are using . . . I really wish you would have tested the assumptions before changing/simplifying the econ model so much.

quote: Doesn't that mean no cities/densely populated mapsquares, production-wise? A farmsite would get the same number of workers as any other farmsite in the same province regardless of fertility and soil quality?

quote: Real problems seem to crop up when you don't have enough pop to work all sites

There is absolutely no micromanagement required... If workers are spread proportionally over the sites the result is automatically optimal. That is one of the features I like about this approach.

Clock cycles:
The production function is actually not that bad, and could certainly be done on an individual square basis. It is trying to do the whole economy (including infrastructure and trade) on a square-by-square basis that I think is prohibitive (suggested by simple calculations I did a while ago). The simple demo 5 econ model (no trade or infra) requires about 50 exponentiations and 200 floating point multiplications/divisions per turn (not even counting addition and subtraction). I don't know speed of exp versus x but lets say its 2:1. So that is an equivalent of 300 floats per economic unit per turn. If the economic unit is a square, that gives about 10kx300 =3M multiplications per turn. This is I think barely doable. If the game were Just the econ model it'd be no problem, but there's all the other stuff... Infra on a per-square basis would give probably 50% more. (Perhaps still barely doable). But trade is the killer. The difficulty of finding the right trade routes goes as the number of econ units within a given transport distance. So it scales as the number of econ units per r^2. This one really explodes as the number of econ units per unit area increases, and I don't think its doable.

Memory usage:
The issue here is doing the infrastructure (housing, etc) all on a local rather than an aggregate basis. That would add something like 25 floats per square.

1) So 'farm sites' is not actually the number of 'farm sites' in a square, but a product of 'fertitility' and acreage (plus a few other variables, I assume)? That seems to create serious wierdnesses in a game, when you consider competing provinces.

The result of fertility and soil quality is suppose to be that a given number of people can produce more food than the same number of people farming worse soil. You will not get this.

If you have one province with one square of fertile 'valley' land, say it has 10 'farm sites' and 10000 people, and 4 unpopulated highlands with only 2 sites each. The next province over, say, has 5 squares of highlands -- 2 'sites' each, and 2000 people each.

Both will produce the same amount of food. The province with the better quality farmland gets no bonus in this case (except for only taking one square).

Then consider a large barbarian country with terrible farmland v. a small river country with excellent farmland but a smaller pop. Since fertility requires pop, the barbarians will outproduce the river people, won't it?
That version of soil quality doesn't produce more per square unless you have more people. And since the basic game tradeoff that will come up is going to be 'quantity' v. 'quality', I think this will absolutely be a problem, and cause some terrible imbalances in the game. Big and poor quality will always outproduce small and high quality, and by a large margin, won't it?

2) If the number of sites is actually a factor of the soil quality and acreage, and that number will change and have to be recalculated as these values change within the mapsquare, then you are already tracking production on a square-by-square basis. You're going to be forced to do the exact same things I'm proposing.

3) To measure clock-cycles, it's a function of what calculations must be made. So to get a preview of the memory usage for your 'aggregate' system, list off the calculations necessary every time the values change. Then compare to the other way.

Since soil will not change often, assuming pop in 5 squares changes:
Aggregate approach -- when pop, soil quality, etc changes in a msq, the province must:

• Get new pop values from all changed squares and total. (5 calcs)
  
• Calculate new 'farmsite' value from all changed squares, and total.(none)
  
• Multiply these two values at the province level.(1 calc)
  

For a pure 'mapsquare' based calculation, a province must:

• Calculate new 'farmsite' value, at all mapsquares where this changed. (none)
  
• Multiply 'pop' times 'farmsite', and total, at all changed mapsquares. (5 calcs)
  
• Add all these values together at the province level.(1 calc)
  

Exact same number of calculations. And you lose detail and realism.

What was the upside, again?

I am certain we will prove this beyond a shadow of a doubt, once the Object builder is a little further along. I can even give you miliseconds of clock time.

4) I haven't thought infrastructure allthe way thru, but I think you have no choice but store infrastructure on a square-by-square basis. Too many wierdnesses erupt if you don't. Obviously roads need to be stored in a mapsquare. But even housing -- again, assume a city. Say an enemy captures a city with 5000 people from your province. The housing has to go with those people, or else he has 5000 homeless people (doesn't capture the city, just the people?). And you have 5000 excess houses. And supplies have to exist somewhere to be captured. Etc.

And again, this stores tightly enough to where it won't really be a problem.

I generally believe that each mapsquare should contain the least info possible, to ensure a smooth gameplay without contradictions.

That would be:

1)Terrain type
2)Vegetation type
3)Population
4) # Farm Sites
5) # Resource Sites
6) # Specials Sites
7) City/Capital status

What doesn't need, in usual circumstances, to be stored in each mapsquare:

1) EGs (and EG attributes): In normal conditions, the repartition of EGs inside a province should be equal for all squares. In special cases, EGs per square can be computed via the population of the square.

2) Social classes (and SC attributes): The same as with the EGs apply here.

3) Kapital: The repartition of Kapital among the squares of the province is of course not equal. The ratios between the various factors of production (L, K, R) are the same everywhere, but the respective size of each sector isn't. The Kapital each square should hold is a function of:
a) Population share of square over province,
b) # of Food or Resource sites,
c) Total Kapital of province,
d) City/Capital status,
e) Value of Trade routes
f) Centralisation/Transportation/Industrial techs
If the Kapital in a certain square is needed, it can be computed with this formula. The Kapital should be computed per sector, according to the per province production of each. The Kapital for F and R is dependant of the # of sites, while for P and S of the population. As Mark has pointed out, because of the property of the production funtion that Y(2x)=2Y(x), calculations are easy and require the involvement of only the examined square and the mother province.

4) Infrastructure: It also depends on investment decisions taken at a province level and it should normally be dependant of:
a) Population share of square over province
b) City/Capital status
So how much of each infrastructure class exists in each square should be comuted, as with Kapital, only when needed.

Other type of info such as military or transportation infrastructure, which are not equally distributed or are pretty constantly in use, had better be stored at each mapsquare. As for trade routes, it depends from the implementation that is already decided elsewhere.

This way, the additional data should only be computed for a certain square only when certain events occur, such as:
a) A raid (barbarians, pirates, bombardment, etc) or a natural disaster occurs in the square
b Enemy occupation of the square
c) The square is transferred to another province
d) The square changes city/capital status
e) There is a strike/riot/revolution in the square

In that case, all or part of the above data are computed and put in a temporary mem slot (that will be saveable along with the usual game data) and be used from there until uniformity with the (new or old) mother province is restored. That can happen, according to the extent of the change immmediately next turn or after a couple of turns. Uniformity can be achieved either with special management of the square (bying or selling of kapital and infrastructure, purges of EGs and classes acording to the prevailing laws) or by merging with the rest of the province (population and workforce reallocation, class demographic changes, mixing of EGs via migration and weighing out EG attributes, etc). When uniformity is achieved, the special data is redundant and will be deleted.

This way, we only need to portray closely only a few important squares and not all the time. We could even reuse the province class, since it is ready-made code; we could create a temporary pseudo-province for each problem square. This way we'll have an autonomous data model for the square, able to deal with everything, and, more important, a ready, full functioning player interface.

(Richard, thanks for the link. We had a simul-post)

F. Smith:

First of all, there are some specifics on the production function approach in the Economic Development Model thread. The particular post you're looking for is from May 21 of this year. It is pretty much exactly halfway down the page. In it I summarize some of the advantages and disadvantages of the production function approach. Now you can use the same production functions on a square basis, they are not necessarily limited to a province basis. But the math is a little bit serious...

I would be happy to send you the spreadsheet so you can play around with the production function and see the kind of things it does when you play with the inputs. It doesn't give what I would consider perfect real world results, but it includes a lot of factors that are completely ignored in your usual god game.

quote: 1) So 'farm sites' is not actually the number of 'farm sites' in a square, but a product of 'fertitility' and acreage (plus a few other variables, I assume)? That seems to create serious wierdnesses in a game, when you consider competing provinces. The result of fertility and soil quality is suppose to be that a given number of people can produce more food than the same number of people farming worse soil. You will not get this.

quote: Then consider a large barbarian country with terrible farmland v. a small river country with excellent farmland but a smaller pop. Since fertility requires pop, the barbarians will outproduce the river people, won't it?

quote: That version of soil quality doesn't produce more per square unless you have more people.

quote: 2) If the number of sites is actually a factor of the soil quality and acreage, and that number will change and have to be recalculated as these values change within the mapsquare, then you are already tracking production on a square-by-square basis. You're going to be forced to do the exact same things I'm proposing.

On your number 3:
Well, your examples don't match the system as it exists. However, your point that to the extent things don't change very much we can skip a lot of calculations is very good. However for the purposes of knowing whether or not its useful to invest in extra capital, you may need to do the production calculations anyway (as a matter of fact, frequently three of them, one each for incremental amounts of population, resources, and capital). The bonus in doing it this way is that you get for free killer economic AI. The bad part is it needs lots of number crunching. Why don't we pick this up after you've read the reference and know basically what is going on in the proposed system.

4) What you bring up is not a big problem. I had just been planning on proportionally moving what ever infrastructure survives to the new province. Of course that requires some bookkeeping overhead to avoid weirdness, but squares change hands very infrequently in the overall scheme of things. YMMV. As I said, I'd actually Like to do it on a square basis, and think it may be possible. But for all of these trade-offs we need to consider size of memory use, save file, and bandwidth in multiplayer.

5) I'm talking about ten seconds for streaming turns here, where the AI is just executing preplanned player directives. Almost anytime the player takes the helm directly there will be Plenty of clock cycles. One of the things I would like to preserve time for is for the AI to be able to think a lot. Our AI is based on both rules, and simulating possible actions. That simulation takes a lot of time! IF you are right and the guts of the game can run in 4 seconds per turn, then several more seconds for the AI probably wouldn't be a problem.

cool discussion. This is neat.

* * *
Axi:

From a programming design standpoint, I must radically disagree.

A data object (like a 'Banana') that is going to be one of a bunch must contain it's own state information at all times ('isPeeled()').

And storing this information at the lowest possible level in an object hierarchy is the smallest possible way to store this data. Decomposition into small 'elements' of data, organized in a 'hierarchy'. Elements of an Atom, Atoms in a molecule, etc. This is the way I store data.

And the fastest, most accurate possible retrieval of this info will be gained by a 'machine' of small, fast, single-purpose components put together in a specific way known as a 'controller' or 'middle-tier'. You build machines called 'handlers' with specific tasks --get this, get that, do this, run that.

And the actual 'logic' of this data engine is provided by what are called 'business rules' (or, in this case, 'game rules').

That's how I want to build it, if that's okay to ya'll.

* * *

Mark:

I followed that thread closely at the time. That was one of the things that made me come back. Of course production has to be a product of inputs. Economics is one of my passions, actually. I was an economics major at SWTSU.

I am not taking issue with the use of production functions. Don't misunderstand me.

My point was about the idea of combining 'quality' with 'quantity' into one variable. Combining 'soil quality' and 'acres of farmland' into 'sites' doesn't seem to work, because of the population requirement.

Because all other things being equal, shouldn't a given number of people working on 'good quality X' outproduce an equal number of people working on 'poor quality X'?

All other things being equal, would 10,000 people mining one rich vein (10 sites, say) be no more productive than 10,000 people mining 10 poor veins?

That seems to be the case. Am I mistaken?

Oh, and tracking sites is exactly like tracking production. They're boths just 'variables' (or objects).

About the A.I. I will have to profess total ignorance. Never done a real one. It seems like spooky stuff! I hope to learn that voodoo from ya'll.

We can calculate and recalculate a lot of stuff in the 30 seconds to 15 minutes it takes a player to play a turn (hey -- how about a timer for multiplay?), and just a theory (totally untested) in my mind is we might be able to make the quality of the AI up to the player -- the longer the player takes between turns, the more time the AI has to plan ahead.

You want a real challenge, play slow.

Just a thought. Dunno.

Finally, estimating by proportionally moving things will not save us anything in terms of performance or storage, I am sure. Not compared to building it right, out of sound, solid components. Like a racing bike. Or an atom.

And we might be able to make many turns run almost instantaneously -- if the player allows enough time between his last move and clicking the turn button, a thread can have completely pre-calculated the entire turn.

The problem is, no client ever knows exactly what they want, so no initial specs are ever any good, right?

Can I suggest using the 'prototyping' methodology, instead? The idea is that your up-front analysis doesn't really begin until you have a prototype. Then the client says "I like that, I hate that, give me more of that". And you revise, show the client the revision, and the cycle repeats.

Because, as I'm sure you've already discovered in your job, the requirments *always* change once the client sees the actual results. So it's better to plan for this in your approach, I think. This methodology has been labeled 'extreme programming', and several good books are availiable on the subject. It has some big advantages over the old way, especially in speed of production.

I'm sure what you're doing is good.

I would like to see whatever you feel comfortable sharing, just because I love code and coding.

F. Smith:

On the issue of quality vs. quantity of sites, you really should reread the whole discussion Richard and I had that I mentioned above (starting halfway down the economic model thread page 2). I have worked up a quickie example to illustrate that the things you think should be in the model actually Are. Here are the assumptions I use: 10,000 acres of great land equals 10 sites. 10,000 acres of poor land equals five sites. Then I compare three different provinces. One with 10 sites of poor land (20,000 acres), one with 20,000 acres of great land (20 sites) and one with 20 sites of poor land (40,000 acres). Note that one point of pop represents 10,000 people. And also for the farmers to be supporting other sorts of workers, they need to be producing something near to five units of food per head (pop point). I'm going to put this table in code format so it maintains the spacing (I hope!). The PW means food per worker population point

code:

---

	10k acres poor land		10k great land		20k poor land
	10 sites			20 sites		20 sites
workers
10		51.5 food/ 5.15 PW		59/ 5.9 PW		59/ 5.9 PW
20		89/ 4.5 PW			103/ 5.15 PW		103/ 5.15 PW

---

Note also that the good land is nowhere near twice as good as the poor land per acre, and that's simply because of the exact production function I have chosen. I have picked a production function for now that is very labor-intensive. The exponent for land is only 0.2. We can change the details of the production function exponents when we're actually playing the game and see how all the factors interact. Note that as you double the number of workers, you don't produce as much per worker as you used to. That is because the extra workers aren't being utilized as efficiently as the initial ones were with respect to the amount of other economic resources. This should make sense from your economics background.

For now, I'll continue coding farm sites the way you've outlined.

But I'm pretty sure that testing is going to bring up a need to seperate the two values. Because it is going to create some bizarre situations.

Because the number of food produced per worker is what is suppose to increase on better farmland. The problem becomes more pronounced when you consider something like 'gold mines'. If a good gold mine doesn't produce any more gold per worker than a poor mine, there can be some serious wierdness.