quote: Originally posted by F_Smith on 08-04-2000 10:31 PM Agreed, I guess, but I still have to ask ya'll -- why not store this at mapsquare level? What is it about the extra detail that ya'll are so against? You want flexibility and customizability without detail? That's a contradiction. We can easily allow players to turn the detail off, and do everything at a province (or even civ only) level. So why not have the extra detail available in there? It is simple to code. The gain is obvious. It would fix several major wierdnesses that the higher level will cause. (All farmers in a Province -- or Civ -- farm with the same tools?). There's no loss. You can turn it off. What am I missing?

The thing is, atleast in my view, the Tech model doesn't handle that. It handles on the development of technologies, basic and application. Its up to the other models to see how they are used, for farmers its up to the economic model. The only thing that concerns the tech model for the map at all is RP production based on the enthic, religious and economic status of the region, not specific squares, like i said, could be handled at provice level if there is allowable city-states. Anything lower doesn't add any signifigant, if even noticeble, addition to the tech model's RP production. This is one of the few models i think that won't benifit in any way by computing it at the square level if like i said earlier, city-state provinces are allowed.

Why doesn't it? RP isn't stored in any square, province. Its stored at the Civ level because that's where the admin of determining how you want you civs to go technologically is determined. This is also because up until recently you couldn't control what was developed exactly, with a few exceptions. We've already addressed this issue. So the player/AI can tell someone to spend more resources in an area of study and RP cost and amount produced will be based on mapsquares and ethnic/religious attributes. That data doesn't include RP, but is used in determining it, that's all.

I disagree strongly -- doing tech at the mapsquare level could add another level of detail that I, personally, would love.

The idea I like is that the individuals in each square do their own 'tech' advancement and innovation. The player wouldn't 'spend' RPs, but instead build/fund research centers that would innovate on their own. Then tech can spread like a 'disease', and farmers/producers (depending on available resources) would adapt to and use the newest tech they know about. So tech would 'spread' out from 'innovative' areas.

Certain ethnic groups can be more 'innovative', as a cultural trait. Increasing the amount of 'education infrastructure' in a mapsquare would increase the innovation of those people. Etc.

This, to me, would be great fun.

I actually intend to (eventually) write an 'alternate' tech system into the code along these lines. It will simply be another option, for players. The 'basic' tech system will be whatever ya'll come up with.

* * *

One other thing:

quote: The thing is, atleast in my view, the Tech model doesn't handle that. It handles on the development of technologies, basic and application. Its up to the other models to see how they are used, for farmers its up to the economic model.

I couldn't disagree more.

You may remember my vocal disagreement on this topic.

A basic definition of techs is actually similar to the basic definition of various ethnic groups, or religions, a civs, or rulers (like in the beast). That is not a system. That is actually a function of scenario designers.

For example, scenario designers can add their own 'techs', can't they? Like a 'fire magic' tech? Granted, we can pre-define a bunch of techs to ease the job of scenario designers, but that is not the same thing as doing work on the model.

A tech 'system' will have to define how techs interact with the other code. How will the increase of a farming tech cause the farming code to increase farm output? Until you've decided upon the specifics of how things will be implemented (clearly the hardest part), the tech system won't be 'done'. Until I finish the 'turn' methods for the object builder beast, I am not done with the Population and Government models. Likewise for the tech model.

Otherwise, I'd be 'done' with the Pop, Govt, Social and Economic model (I've actually already coded up production zones into the model). But I'm not, because it doesn't do anything yet. I'm not done until it 'works'. It isn't designed until you know exactly how it works.

Those of you who are going on about the tech model in this thread are way OT! Please find another home for your conversation, perhaps starting a thread about tech model coding. I will put my responses to the various OT issues in the correct threads so we can maintain some order in the discussion here.

I should have avoided the topic entirely.

I hope I didn't overstep myself. Blame it on the fever.

I'll just try and stick to my current responsibilities, since I have plenty to do for the next week, at least.

Altho, if no one minds, I do plan to write my own version of a tech 'diffusion' model in, as an alternative.

In fact, I'd like to let it be known right now: In the long run, since the code is so componentized, I'd be happy to write 'modules' to implement just about any crazy idea anyone has that they'd like, and offer them to players as options. I'd love to have 10 (or more!) different tech models for players to chose from -- on written by someone from M.I.T., one from a farm-boy in Kansas, etc. Talk about replayability!!!

This goes for the Economic model, too (back on topic now. Sorry). I'd love to have several available -- a 'province' level system like we're using now; a simple mapsquare-based one like old Civ/Alpha Centauri; a massively complex mapsquare system in which several players can play in the same civ (break civ-running into different jobs, like cabinet level, for co-op games); a 'civ-only' level-system, for people who just want to set general goals; an 'automatic' one (A.I. and Characters?) for players that just want a wargame.

Invite micromanagement?

More like 'allow' micromanagement, I should think. We will never force it.

We'll build the standard game as you have asked. But the depth has to be there as an option, for those that want it, agreed? Because without that possibility for micromanagement, the game will become very repetitive very quickly. The only way to make a game interesting the 100th time you play it is to have a bunch of stuff you can control, if you want.

LGJ: Strongly agree, if you are in a democracy with widely distributed power, almost all the "levers" you pull will be at the national level. The local people are largely on their own. It's also similar for a feudal system, since you have limited control over what your vassals choose to do. We don't have all the details yet, but I think we can get all these things right.

And now onto my main topic for the evening...

Proposed class hierarchy for the economic model

Well, I started messing around with the econ code that Laurent has already modified, moving in the direction of the demo 5 model. Our current plan is to start the new econ model in parallel with the old one, at first not much affecting the game in general. Then we will slowly switch over the plumbing from the old model to the new. The object of this discussion is to figure out how to make the code structure flexible, so we can try and not be pestered to death by F. Smith . Yeah, and we would like flexibility and compartmentalization of the code too.... The thing that slightly complicates this is to have an Economy object that can be associated either with a map square or a whole province.

I've already talked about some of this stuff earlier in the demo 5 econ thread, and won't repeat that here. This is my proposed class structure for your criticism or comments:

Economy (now called ProvEcon) is the main economic class. Whether the main economic action happens at a province-wide level, or in individual map squares, it will happen in this class.

Economy will have a number of Sector objects (food, resources, etc.) associated with it. Everything that is limited to a particular sector of the economy is handled in Sector.

In order to store some information that needs to be kept track of at the map square level even if the whole economy is run at the provincial level, there are two "stub" classes to hold this info. SectorStub will hold basic info like capacity in the sector, workers in that sector, and possibly sites. These objects will be organized under an EconStub object that will also hold infrastructure information that needs to be at the map square level. EconStub would also hold things like unemployed workers, anything that needs to be in a MapSquare that is not part of an economic Sector per se.

Right now it seems to me that Economy should extend EconStub, and Sector should extend SectorStub. I think this is the natural way to do it seems each of the stub classes is just a minimalist version of the class that inherits from it.

So for the aggregated economy, where the main economic action takes place at the province level:
each province has an Economy object, and each MapSquare has an EconStub object.

For a MapSquare level economy:
Province will still have an Economy object, but it will shunt most of the action to the map squares, which will each have their own Economy object.

Mark: You are right; modeling the economy at the mapsquare level should eliminate most of the problems associated with altering province borders. I am surprised by your change in attitude, however. For as long as I can remember, you have been telling us to avoid putting detail into the individual mapsquares.

The mapsquare-level thing is Experimental. You don't have to go changing everything elsewhere, since the experiment may not work out. And I wouldn't change something so important without discussion and buy-in from the group anyway... If you want to think about possible ramifications, etc. that's justified.

It's a matter of that 'filing system' I was talking about in the other thread.

Instead of everything being stored in a 'province' object (file folder), the mapsquare data will be stored in a bunch of mapsquare objects (file folders) and assembled when needed.

You can do the calculations at the province level (in the 'province' turn handler) without a problem, if you prefer. Or you can have each mapsquare compute it's own numbers and then add them up at the province level.

And there are other options, too.

* * *

Mark:

Heck, 80% of the mapsquares will *never* have to be recalculated, right? The tech and econ info will not change in unpopulated squares.

If no one is going to use the tech info that turn, what purpose would be served by calculating the tech and econ info?

So for empty/unpopulated mapsquares, there is no reason to calculate the changes. As long as we store all the changing inputs, we don't hae to compute the output until it's needed.

Each turn the tech info will need to be recalculated because each turn the tech level changes. The tech system is based on small changes that happen over long periods of time allowing with it if there is input from char model and such for great leaps forward. This is why every relavant square needs to be recalculated every turn.

There's no way all mapsquares are populated, unless you play a far-future scenario ("Soylent Green"-world?). How much of the Earth's surface is currently populated -- maybe half? Less?

Mark:

Oops -- the same goes for econ data, tho.

Yes, agreed, 20,000 total land mapsquares. Minus Siberia. Minus the Rockies/Himilayas/etc. Minus the Sahara/Gobi/etc. Minus the Ozarks/Everglades/etc. And on, and on.

Let's run the numbers and consider how much will actually be populated.

Someone needs to check some numbers. I can not believe Lordy's assertion that the Earths crust is near 100% populated (meaning, in this case, more than 1000 people in a 60m by 60m area).

For an entire 'ancient' game, someone *really* needs to look up some pop numbers. For the first 3000 years of gametime, how many squares will be populated? A few hundred?

Even in modern times, with a 6 billion population, we have those massive mountain ranges, wide deserts, vast swamps, endless forests, etc that are not going to register pop in this game. I'd guess (based only on my own ignorance, but I'd like to see some actual data) that at worst we'd need to worry about 8,000 to 9,000 mapsquares, under the most amazing of conditions (unless, as I said, someone makes a 'Soylent Green' scenario).

Please note that 1000 people per square is Very easy to achieve since at pastoralist population densities of ~0.3/sq mi a square would have a population of about 1000. So most of the central asian steppe is populated using this definition. However no Atlas I found that gave pop densities went that low. So we are talking primarily about agricultural populations here which may seriously underestimate the Medieval and Classical Antiquity numbers.

Modern times ~ 10k populated squares
Medieval ~ 2k
Classical Antiquity ~1k. (China all by itself has probably 100-200+ in this period)

The latter two estimates might be off by a factor of 2 either way (not counting pastoralists). The modern one something like +/- 50%

It is the modern one that is by far the most troubling for doing calculations at the square level.

So for the first 4000 years of gametime, we'll have at most about a thousand squares to calculate tech, econ, etc.

Not a problem.

There are two ways of modeling animals that I can see: specials and infrastructure.

I think the infrastructure modeling is a better abstraction. This way, the results of the animals' presence can be modeled, and they are "behind the scenes" so they won't clutter up the map. This method of modeling may seem odd, but as far as I can tell the equations for animals and other infrastructure would be the same. There are a few differences, but the "animals" class of infrastructure objects can be derived from the basic "infrastructure component" object class

FE the number of horses available would be an important part of the farming and transportation infrastructure, as their presence increases the ability to complete economic activity. Just like the amount of blacksmiths available, the amount of certain animals affects the general economic ability to do things.

But unlike most infrastructure components, animals can be moved around. They could be transferred from one province to another, and invading armies could take them home and add them to the infrastructure of their civ. Another difference is that animals are bred rather than built. You don't have to expend any inputs other than food to increase the animal infrastructure; you just have to avoid eating too many of them. This leads to another point: animals can be consumed. This is a major difference, but we should be able to take care of it by altering the methods used to calculate depreciation.

While animals integrated into the economy can be tracked like this, wild animals should be specials. But unlike most specials, they are only used once. When your civ discivers the proper tech, the wild animal specials are turned into domesticated infrastructure components.

We should probably have the following infrastructure components:
Horses
Oxen
Donkeys/Mules
Food providing animals
Camels

I also think there are some good reasons for including Dogs and Cats as well. Dogs help farm operation, and cats control granary-draining rodents.

Interesting suggestions. I will need to think a bit before I respond.

Editorial Note:

Let us not forget what our priorities are!

So how does coding the demo 5 econ model go? Any progress we can see?

Will it be easy to transform this code to the final econ model afterwards? There are some important issues with trade, prices and the cash flow you know. Apart from that the govtecon submodel is currently suspended in mid-air.

But for accounting, its very simple. Services = Clash Cash. You can take services out of a province 1:1 as CC, and you can put CC back in that becomes services. Of course prices change when you take out or put in services so it can mimic the inflationary effect of having lots of money dumped into an economy.

Beör was wandering how can the player make the game build the Bismarck for him in a certain province. Is the answer I gave him in the infrastructure thread correct. It it compatible with your econ model and with your vision of the game in general?

(I still haven't been able to look very carefully at your proposal, the responses, and the spreadsheet. I just haven't had the time... So it's possible we will have problems based on my lack of understanding of exactly what you are proposing. I will try to take a closer look sometime today.)

For the people's share of the infrastructure it is as you said my viewpoint is. I think that once the prices of all commodities are determined, just before the people buy infrastructure, that we should just reduce it to a big pile of cc. That is what I think is best given the trade-offs in the system. You are free to argue against it if you like .

And my mind boggles at what F. Smith will say about the whole thing, since he will probably want infrastructure to be broken up on an ethnic group, social status, and age cohort level

quote: Do not forget that the state must have the ability to invest money in the economy of a certain province (money input).

As for government purchases, I am in basic agreement with the response you gave. However there are a few things that I don't understand in what you said, and one clarification. First, the clarification. For the central government, the government should be able to buy whatever it can afford wherever it chooses. The AI will help to reduce management here. However, if others buy into the idea of provincial and local governments, these will only proceed automatically (similar to what the people do) but under central government general guidance if appropriate, depending on the centralization. This whole thing has not been discussed in detail, so I have just presented my view.

Now for the statements I have trouble with...

quote: If you have enough money for the Bismarck, you can funnel them to the province that has the capability of building battleships. They will increase the total budget for infrastructure and also the amount of public investment. This will raise the weight of the govt in the preferences machine enough, so that, if your government profile is actually in favor of building battleships, you will find your money in the military units budget and they will be transformed into military units. If they will build the Bismarck or a couple of Panzer brigades instead, is an issue decided by the General Staff (this is you).

First of all, at the lower micromanagement level the player can simply say "build the Bismarck with this money" provided its enough depending on the local economy. What you say about the government preferences machine matches my general expectation of what happens when the player has just issued overall guidelines to the economy, and expects them to be followed in each province. However, when you have a specific thing in mind, it is better for the player to order it directly using the micromanagement approach. Or alternatively, the player can simply say build me three battleships somewhere along with this coast within the next three years, and let the AI work out how exactly that should be done.

One other thing... You mention about military units being handled as infrastructure. And that this necessitates the "dry" infrastructure version of the military units to the given flavors such as x units of cavalry, Y of infantry. This is not what I intended. Military units can probably be built with the general preferences set up, but should Always be built as specific units IMO. This requires the military unit "infrastructure" class (if we do it that way) to be a bit different from the others. Essentially, you would enter into a queue of units that you desire to be built (or the AI will) and when the cost of the unit has been paid, the particular unit that is at the top of the queue comes into existence. That is the way I envision it. Whether we should handle this as an infrastructure class at all, is a topic I/we need to think about.