03-08-2000 16:50									#31
	Support Apolyton

Hello again!

Mark: I don't quite understand what are the extra benefits of running the econ model at the square level, so someone should give me a briefing. I believe that the econ model should run at the same level as the govt, soc and riots models, whatever that level is. Since a province is a sociopolitical and administrative unit, why shouldn't it be an economic one? I'm sure you have a good reason for trying to do economy at the square level, but are you sure this can't be done any other way?

F_Smith: It is a fact that things become simpler when there is detail, but then that detail is more difficult to handle. To use your example, inside the atoms, all can be explained with the 4 fundamental forces (or with less, if you proceed further in), while at a molecule level things are far more complex. Albeit that, I never saw a chemist play with quarks; neither does he need, nor is he able to handle the detail. On the other hand a physicist is able to experiment in quark detail because he never handles more than a handful of particles each time. The world has much detail in it, but we only need and can portray only so much of it.

To all: I believe that the player should be able to decide, according to his computational power, how much detail he wants. I had proposed resolutions ranging from 1.800 to 2.000.000 squares (although these limits are arbitrary), which means that a province could have anything between 1 and say 10.000 squares. Well, if one is kinky enough and has a Cray to spare, and wants to run the econ model (or any other model) at each and every one of those 2M squares, every turn, then, by all means, let him do that! But we poor people, with our 3-year-old PCs, should be given a chance to play Clash in some decent manner, shouldn't we?

To be able to achieve such customisability in detail, while in the same time preserving compatibility between different players and different games, two new kinds functions should be available for the gamedata:

a) Compress: When employed to a set of tiles, it will transform them to an equivalent smaller set, f.e take a 3x3 grid and turn it into a 2x2. When employed to an hierarchical structure (f.e. a province), it will transform it to the next lowest structure in hierarchy (that would be a tile) and assign it under another similar structure (another province). During compression, some detail will be lost.

b) Interpolate: It will be the reverse of compress, adding detail instead of subtracting. In addition to the obvious function of transforming the given tileset into a larger one, it would be able to turn a tile into a province, according to it's original attributes and the attributes of it's mother province, pretty much in the way I have already described. It is more tricky to implement than compress, but it is totally feasible.

These two functions should be called upon the whole game world, during transformation of a savegame and inside the game when provinces are rearranged. If my viewpoint on the subject at hand is implemented (econ at the province level), they would be used to create and destroy pseudo-provinces for each irregular tile. Since these functions will eventually have to be there (compatibility for different resolutions is a must), there is no reason why we shouldn't try this.

	04-08-2000 00:21									#32
	Remove this text

Axi:

I agree, in large part -- many players will want to play the game only on the 'molecule' level, without ever looking into the individual atoms.

But the hard-core players, the ones that will learn to play this game better than we ever could, the ones that will push the envelope of scenario design, the ones that will invent ways of playing this game we can not now imagine, the ones that will have 200 saves (whoa, that's a lot of play time!) will want to/need to play with the internal workings of the gameworld's atoms.

I believe that a game's replayability is entirely dependent on the depth of the info behind the game interface.

If Mario Bros. had only been one or two levels, you'd have never heard of it again.

Your suggestion of a scale selection is perfectly reasonable. I sort of consider the 'scenario' based gametype to be that control. We can build scenarios that would run on an old 486, just keep the size of the gameworld down and don't put too much detail into the scenario.

There can even be scenarios with no econ or population at all, just two armies. The game is that flexible.

But we can make an option in the beast to 'scale' the gameworld either up or down. I think that sounds like a great, innovative idea.

	04-08-2000 20:47									#33
	Tired of ads?

I think we should keep models and calculations at the province level as much as possible. If the player wants to do square calculations, that person can make each square a province. I believe that there would be many benefits to assuming all squares in a province are identical, but I have been overruled on that. But I will still argue that the game should be centered on provinces rather than squares.

	04-08-2000 22:43									#34
	Support Apolyton, pre-order Civilization IV

I don't this so. I think that will add more unnessary complexity and a lot of extra calculations and memory usage for those who want to do it, which we shouldn't penalize those that want to calculate things that small.

	05-08-2000 04:14									#35
	Suffering from ads?

Richard:

The problem is that the movement and combat model is mapsquare-based. And that requires the pop and resource info be stored at the mapsquare level. No choice.

Would ya'll prefer no mapsquares at all? Just a 'province' based movement and combat system?

Because otherwise, the player will *have* to deal with individual mapsquares in the game every turn -- which mapsquare to attack, where to place defensive armies and fortifications, roads, etc. To do away with the mapsquare level, you would have to do away with mapsquare-based movement and combat.

If you're discussing the game's economy rules, the player will never deal with the specifics of the economy of a single square.

But if you're talking about the storage of game data, behind the scenes, you have to realize that it *can't* ignore the mapsquare level. If all mapsquares in a province are the same, then you have no cities, for instance.

Please do understand this one key concept -- the difference between game rules and technical decisions:

I'll leave the gamerules decisions to ya'll. But you've got to trust the technical people on the technical decisions, then. Data storage will be what it has to be, no more, no less. That will be dictated by the needs of the different systems -- and combat and movement in a map-square based world requires tracking pop and resources at a mapsquare level.

I'd be willing to code this to change movement only on a 'province' level (like Risk), if you'd like -- but that carries some serious ramifications, as I'm sure you know. It could be good, tho. Just let me know.

	05-08-2000 05:14									#36
	Avatar Enlargement: We've got the solution

F_Smith: What you describe is exactly what I want. But like I said, I was overruled. Mark does not want a province based movement and combat system, and most people agree with him.

The bulk of the relevant discussion is in the province sizes thread if you want to look at it.

I know that some stuff will have to be stored at the square level. I was saying that I want to keep the square-based stuff to a minimum.

	05-08-2000 05:41									#37
	Full PM-box? Change here!

Hi everybody:

(I composed this before I saw Richard's post, and am now too tired to go back and change it )

Look, we are just trying an experiment here in code to look into some of F. Smith's ideas. I think the additional time cost for programming to try it this way is very minimal, probably a few hours. Laurent (who just had a second son yesterday! Congratulations Laurent!) and I are just going to code up the Econ demo five model with a switch in it to allow the economy to go either way. Since most of the work involved is necessary to do the province-wide demonstration, the added work to essentially make each map square a little province is minimal. Note, we are going to keep the province definition that the player perceives the way it has always been (multiple squares per province) because of administrative necessities for the player. When we are done, everyone can try it, and we can see what everybody thinks.

F. Smith: hope you're feeling better... Please don't ask Richard rhetorically if he wants to make it like Risk! He has already made that suggestion... although that's a valid direction in which to go for a game, it's not really a game I want to play. Anyway, we have had this discussion before...

Axi: there are bunch of reasons I'm at least interested in looking at the model on a map square level.
1. It gets a local nature of the ancient economy right -- the presence of trade special spurs growth locally, and water-born trade is very important between squares. The higher-level model misses this.
2. Intra-provincial trade in general is handled much more accurately -- the effect of roads is automatically accounted for, whereas in the old system I had to cheat to make the player wants to build intra-provincial roads.
3. Handling damage due to raids or war is much more easy and natural.

	05-08-2000 07:12									#38
	Support Apolyton buy from Amazon

Not everything needs to be handled at the mapsquare level either. The tech model certainly doesn't. I'd go so far as to say it could be done at the civ level, or atleast the provicial level.

The only problem with that, and there would be a slight problem, would be a largely agriculatural province with 1 huge city. This is why i suggested city-state provinces earlier in the other thread.

	05-08-2000 07:16									#39
	Support Apolyton, pre-order Civilization IV

Richard:

Actually, there's no reason not to allow players the option of playing a 'Risk' style game, it would be easy to include.

Have you seen the game 'Shogun'? That's exactly how that works. It's fun, to a point, but not much depth. It gets boring after a few games. Not enough detail. I personally would much prefer the mapsquare level of detail

Mark:

I'm actually a bit worse. I'm off to bed now, actually. I'll make it.

I am curious why so many of the group seem so against having depth behind the interface. In the other threads they keep talking about how flexibility and custimizability is key -- don't they realize this is the only way to gain that?

And besides, the turn/combat system already requires that level of detail . . .

	05-08-2000 07:31									#40
	Suffering from ads?

Lordy:

Just saw your post, after I finished that last one.

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?

	05-08-2000 17:47									#42
	Support Apolyton, buy Alpha Centauri

Lordy:

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.

	05-08-2000 18:14									#43
	Browse Apolyton AD-FREE

Guys:

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.

	05-08-2000 19:34									#44
	Full PM-box? Change here!

I'm sorry.

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.

We can define one set of options as the 'standard' game, and have those as defaults. But this game is 'built' like a machine, from small, simple components. We can bolt on different parts wherever we want.

	06-08-2000 00:31									#45
	Put an end to popups!

My main concern with doing things at the square level is that it could invite micromanagement. I don't oppose adding the detail to the models (unless it makes the game too slow). I am saying that the interface should be centered on provinces rather than squares so the player is not overwhelmed with detail.

I have a question: Will players be able to change the borders of their provinces, and will this affect calculations?

	06-08-2000 00:50									#46
	Support Apolyton, buy GURPS/ Alpha Centauri

Richard:

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.

And yes, you'll be able to change the borders of a province. Especially thru war -- you can conquer a province one mapsquare at a time. Or just take the rich farmland, and not the highlands. Or whatever.

	06-08-2000 01:18									#47
	Support Apolyton, buy GURPS/ Alpha Centauri

I don't agree, atleast to some extent. Well maybe...but there should be consiquences for going to far down in micromanagment in certain governmental types (not to be discussed here). So long as that's done, that's okay.

	08-08-2000 06:10									#48
	Remove this text

Richard: Actually doing the economy at a MapSquare level (if we can get it to work) should make it very difficult for micromanagement of province boundaries to be helpful to the overall economy. As F. Smith says, micromanagement at the MapSquare level would never be mandatory, and I expect most players to manage the economy at a provincial or even civ-wide level. And I think players absolutely need to be able to rearrange their provinces, but nothing in the game should be extremely sensitive to the details of province arrangement. The configuration of provinces may have larger effects with respect to the government model, but still I think we need to keep them under control.

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.

That's it for now... they're also some other helper classes in the econ model, but they don't seem essential to deal with that this point. And I wanted to get this up ASAP so I can get feedback before I slap together any classes beyond what we already have.

	08-08-2000 18:16									#49
	Lose 30 kilos (of popups)

I concede the point. Unless it makes the game run too slowly, square based modeling should work well.

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.

This forces us to change parts of the tech model. We can no longer generate RP's by province. We must now generate them by mapsquare. For a complete explanation of this, look in the tech model thread.

	08-08-2000 19:33									#50
	Support Apolyton, buy Call to Power 2

Richard:

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.

My change in attitude was brought on by F_Smith's point that if we do things on the square level, they frequently will not have to be calculated every turn. (I should have thought of it) It was the cpu load of every mapsquare crunching complicated models every turn that was always my fear. I think now we can get away with calculating most things every 10 turns or so, and just applying the changes ten times... If you do RPs by map square, that would be the case also. But I'm not sure it couldn't just work the old way. The same provinces will still be there...

	08-08-2000 20:51									#51
	Support Apolyton, buy Civilization III: Complete

You can still do things at the 'aggregate' province level. Nothing will change except the way those province numbers are gathered.

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.

Plus, if we 'preprocess' the turn info while the player is still making decisions, turns under many circumstances can be instantaneous.

	09-08-2000 09:28									#52
	Support Apolyton, buy GURPS/ Alpha Centauri

The tech info will change for unpopulated areas (unless you mean oceans) since otherwise there is no such thing (and in some cases oceans will have population). Anyway RP is used and destroyed every turn and anything and everything almost effects Technology, but we'll wait and see.

	09-08-2000 09:36									#53
	Get a bigger avatar today!

Lordy:

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.

P.S. -- how can an upopulated mapsquare have a tech level??? Doesn't tech require people???
[This message has been edited by F_Smith (edited August 08, 2000).]

	09-08-2000 09:51									#54
	Support Apolyton buy from Amazon

F_Smith:

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.

Now as for unpolulated squares, eventually almost every land square will have some population on it, ie if it is even romotely possible to sustain human life by say around 1000 ACE it will have life on it. That means there will be tons of squares with life, depending on the size of oceans. I am not saying to calculate for squares with no population, but there is a differance between no and minimal population.

	08-08-2000 23:19									#55
	Lose 30 kilos (of popups)

Ahem... You guys are in the wrong thread again with the tech discussions.

F_Smith: on recalculation I am only talking about populated squares from the start. IMO where preprocessing really pays off is in the AI moves. There are Lots of AIs... But it does require a whole extra infrastructure to keep track of what object is on which turn then... We will have to look into the opportunites and potential problems of doing this at some point.

	09-08-2000 00:40									#56
	Support Apolyton

Axi:

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.

Since we're going to only have to worry about the values of populated squares, we have to track and calculate values for at worst a few hundred squares until very late in the game.

	09-08-2000 01:17									#57
	Support Apolyton buy from Amazon

The only places not populated are Antartica (with the exception of around 100 scientists) and Greenland, except around the borders. Everywhere else has enough population to show up on any model today.

	09-08-2000 07:33									#58
	Support Apolyton, buy Civilization III: Complete

F_Smith

Just a reminder... but we're using a very large "standard" map. Something like 64,000 squares, sure 70%+ is ocean, but that still leaves u with like 20,000 squares...not the few hundred u mention.

	09-08-2000 09:09									#59
	Support Apolyton, buy GURPS/ Alpha Centauri

Toubabo:

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).

And even then, not all those will have to be recalculated every turn.

	09-08-2000 09:26									#60
	Support Apolyton or Terrorists Win

F_Smith

You're absolutely right, not all squares will or should be populated, I never meant to disagree with that fact, I've even stated it before. And actually I've been trying to "check the numbers" for the disease model, but it's very hard to find that kind of data (at least accurate and unbiased data). And your assumption of 8-9000 squares is probably close to correct... I was just making sure u knew the number of squares u were dealing with, that's all, I'm not trying to disagree with you.