27-09-2000 19:46									#31
	Remove this text

Beor:

Excellent questions, but you're kinda getting way ahead of us. Someday those decisions will have to be made, for sure. But not for months, I think.

I personally really like an infrastructure having to pick a terrain. That means no boats on dry land. No Mines in a lake. A logging camp belongs in a forest.

Altho I wouldn't want to push beyond two, or perhaps 3 different types of terrain in a single mapsquare. But we have that ability, if someone wants to make up rules to cover it.

Later . . .

	27-09-2000 20:30									#32
	Help yourself to an AD-FREE life

The rules already exist to deal with multiple terrains per mapsquare. The Ecology model assumes that each square could have some percentage of forest or wetlands, so a square could be hills with 50% forest cover and 50% scrubland.

So in general, the geography would be one terrain type and the vegetation would be one or two terrain types on top of that.

	28-09-2000 09:55									#33
	Get a bigger avatar today!

Richard:

You have a great point there -- that's an excellent object analysis.

'Terrain' objects could hold 'geography' objects. And 'geography' objects could hold 'vegetation' objects.

I like this very much, if you think it's a level of detail that will get used. The flexibility is astounding, for 3 objects. The combinations are almost mind-boggling. And it has a bonus -- think of how crops would be handled! So easily. Just a 'vegetation' object. It can be removed when harvested, each crop type can potentially have it's own properties . . . good work, Richard.

Is this too detailed? If no one objects, I'm going to use it.

	28-09-2000 01:41									#34
	Support Apolyton, pre-order Civilization IV

Re geography and vegetation

I guess this is somewhat equivalent to the SMAC system where the terrain in a square is determined by a 3x3 matrix: Terrain (flat, rolling, rocky) and rainfall pattern (arid, moist, rainy) yielding 9 different combinations. We would however have a multitude of different combinations. One important thing to consider is that this demands very careful attention to details when we decide what effects combinations of geography and vegetation would have during play FE on combat, production and movement. What will be the combined effects on combat of rolling hills and scrub, mountains and forrest, flatlands and tundra etc. With the multitude of combinations we would probably have to design a system where the results of geography and vegetation were considered separately, the combined effect being the sum, the product or some other function of the two factors. If handled incorrectly, this could yield freak situations. It would also be necessary to prohibit certain combinations (FE mountains and mangrove).

But OOOOH, what beautiful graphics we could make. Again we would probably have two layers, one for geography, one for vegetation - I'm not sure this is easy, but it can be done. I'm a little worried that the player would be confused by the multitude of different 'square-looks': In SMAC there are nine, and it took some getting used to. How we should handle mixing of different vegetation types in the same square graphically is even more tricky.

Are you sure players would like to handle this sort of complexity: 'Should I place my legion in the flat marshes or in the forrested hills or behind the city walls?' And if faced with this choice whenever entering a square this will quickly become rather tedious ). It might work, but I definitely think this possibility strengthens the argument for placing of TFs in the mapsquare, not in the terrain. Then at least the choice between different locations within the mapsquare could be made by AI based on what would be most advantageous to the player.

So I guess that what I'm saying is: In general I like the idea, but if too much of this functionality will require the attention if the player, I think we're urinating against the wind. If however it's kept at the AI and model level to achieve greater realism I see nothing wrong with it.

F_Smith if we adopt this three-tiered object-hierarchy would you consider changing 'Terrain' into 'Location'?
A location has a geography has a vegetation?

Re infrastructure and terrain

If we decide to model it one way or the other will it be difficult to recode in case it's needed?
If no, let's drop the subject for now and proceed anyway you want
If yes, we need to discuss it a little more: I see what you mean F_Smith. There has only been so many ships on top of mountains (mental picture: Noah's Ark on Ararat). And city walls around soft meadows isn't exactly realistic. Are we dealing with two different kinds of infrastructure here? Terrainbound and mapsquarebound (roads, canals, rivers, maybe more).

Re off-map squares

I was thinking in terms of having a mining-facility in an abstractly represented moon-square an such.

	28-09-2000 02:59									#35
	Got spare money?

I'd say its ok if things like forrested hills or half forest, half plains are fine in the Object Model. However as Beör says we need to discuss all these things from a gameplay etc point of view before we consider locking them in as standard. These kind of decisions have fairly large leverage on learning curve and gamplay issues.

As for the military stuff, the notion has been to allow TFs to be in fortresses or outside them depending on the TF orders. I think the AI can handle that level of differentiation within a square. So the object model will need to be able to have TFs contained within at least a few infra types, and the general square itself. As for position with respect to rivers, I think that may be getting a bit much. But we should discuss the details in the Mil thread.

	28-09-2000 06:17									#36
	Increase Your PM Length

F_Smith:

quote: Richard: You have a great point there -- that's an excellent object analysis.

I don't understand this. When I diligantly try to learn and do OO analysis, I fail miserably, make you mad, and create a big disturbance. But when I am scrupulously trying to avoid any mention of coding, you say that I am producing wonderful test cases and OO analysis. I feel like I'm in the twilight zone.

Beor:

quote: With the multitude of combinations we would probably have to design a system where the results of geography and vegetation were considered separately, the combined effect being the sum, the product or some other function of the two factors.

Already planned.

quote: But OOOOH, what beautiful graphics we could make. Again we would probably have two layers, one for geography, one for vegetation - I'm not sure this is easy, but it can be done.

This very thing is being discussed in the Map Graphics Thread.

You could be right about the complexity. But the defense determination should be something as simple as +X% for hills, +X% for forest, add them up.

	28-09-2000 06:39									#37
	Support Apolyton, buy Civilization III: Complete

BTW, F_Smith, that is a great idea for crops. It is an elegant way to do things. Now, the system for harvesting crops can be the same as the one for chopping trees. I'll post that and other relevant stuff in the ecology model.

	28-09-2000 20:51									#38
	Support Apolyton, buy Alpha Centauri

Beor:

You're exactly right, I hadn't thought of that. SMAC does use a similar approach. Bet that game was done via OOA, too.

Layering as many objects as necessary is easy. In the beast, those stupid little stick figures were all layered graphics -- each little man, or little house, was an individual graphic with a 'transparent' background. I can take any picture and replace a color (or more than one color) with transparency. So we can go nuts -- assuming someone with actual artistic skill can make the pictures.

I, obviously, will not be much help in the 'art' department. Unless you've got a call for stickfigures . . .

Absolutely players will have to decide the 'disposition' of their troops -- order them to stay in the fortress and take a siege, or sally forth and give battle on the 'terrain'. This is one of the fun parts, to me.

It would be difficult to go back and add this functionality later. If we might ever want it, we should architect the data structure this way now.

Oh, and 'off-map' squares will be a simple thing. This game datastructure can even be used to make a game that happens on several planets (assuming enough processor power). Maybe that can be the online game? Let the servers handle all those worlds? Dunno.

	29-09-2000 09:06									#39
	Support Apolyton, buy Civilization 2

Hmmm . . .

Posting that description to Richard, I have to say I think I might agree with Beor, perhaps the objects names should then be location, terrain and vegetation --

A 'Location' has 'terrain'. 'Terrain' has 'vegetation'.

That sounds better to me. I think I'll do that.

	28-09-2000 22:34									#40
	Increase Your PM Length

Could we model cities and towns the same way we do vegetation? In the view of the ecology model, they are basically the same thing.

I vote to eliminate the word "terrain." It is a concept that is no longer relevant IMO.

So:

A Location has geography, water availibiity, and climate.
Geography has vegetation, crops, and human settlements.
Human settlements have infrastruture and population.

	29-09-2000 00:30									#41
	Increase Your PM Length

I think this is the right place to discuss this. We're not talking about the game model, we're talking about code architecture.

Richard:

I like the OO hierarchy you put up, with two exceptions. I'm not sure I'm right about them, so let's go over it.

First, I don't like having a 'human settlements' object, personally. I don't see that as being useful. It seemed like just an 'infastructure' at that level is fine. Then 'human settlement' can be one type of 'infrastructure' object. Is there something I'm not thinking of that would make this not work?

Second, I was thinking population would not be tied to any single terrain/location. The pop (ethnic groups objects) would wander around the entire square regularly.

In other words, it didn't seem accurate to state that a 'geography/terrain' has a population.

Oh -- what would ya'll think of changing that 'geography' to 'terrain'?

Use 'mapsquare', 'terrain' and 'vegetation'/'infrastructure' as the hierarchy?

Would ya'll mind if I did that? 'Terrain' seems to be more descriptive than 'geography', to my pea brain.

	29-09-2000 03:42									#42
	Browse Apolyton AD-FREE

So, I guess we have to be able to put military units inside city walls. This is OK, but to keep gameplay simple, I still recommend that whenever a unit enters a square it is just placed in the mapsquare. The player should not decide at this point where he would like to place his troops. Then if attacked he could be given a choice:

'Mighty Caesar. The barbarians are approaching Ravenna. Would you like the 5th legion to face field combat or should they withdraw behind the city walls?'

In most other situations the particular placement of the unit is of less importance, and the most beneficial option for the player should be chosen automatically. If FE a unit enters a square with mountains and plains, it should be the plain movement cost that applies. There might be a few other situations where a unit should be allowed to be in a particular location, but as a rule it should be left in the mapsquare.

I think F_Smiths handling of EGs makes sense. In a way they are everywhere when they are in the mapsquare.

F_Smith, what was the object hierarchy you proposed again: Mapsquare - location - terrain - vegetation? I'm getting a little confused. Maybe there's an unnecessary layer here?

I like terrain better than geography.

And where to place infrastructure? Probably at more than one layer - I have to think a little more about this - especially the city thing .

	29-09-2000 04:38									#43
	Got spare money?

Beör:

On the sites issue that you asked about in the Pop thread... I have already given you a reference to a few long discussions on sites. I have said everything there I can say pretty much. Here is a little more. Unless you want every square to have an enumerated list of how much of each quality land exists in it, sites is IMO the next best thing. Listing qualities of land that way leads to bookkeeping nightmares, AI trouble, and micromanagement since there can be big breaks in land quality... Modeling with sites has none of these problems. All the large nonlinearities are wiped out.

And having only a single quality of land present in a square is IMO less realistic than using sites to model land or resources. The site abstraction is similar to what is used by economists to crudely estimate production amounts in the real world. Surely it is quite adequate for a game.


I think your approach on use of city walls by troops etc is reasonble, except that players should also be able to choose to just automate everyting. Most of the time the choice will be very clear which is better.

	29-09-2000 05:21									#44
	Lose 30 kilos (of popups)

"Human Settlements" was supposed to be something that combines all infrastructure in the square for ecology modeling purposes. It would be a nightmare if every infraclass had unique effects on the ecology. I wanted a concept that combined all infrastructure into something that could be treated like vegetation. That way, we can simply say that a certain square has, by area, 50% forest, 45% crops, and 5% human buildings.

Each mapsquare thus has exactly one thing that the ecology model interacts with. That one thing represents human settlements spread all over the square. So it seems that storing population and infrastructure in that thing would have the same effects as storing those things by mapsquare, which we were doing anyway.

quote: Second, I was thinking population would not be tied to any single terrain/location. The pop (ethnic groups objects) would wander around the entire square regularly.

	29-09-2000 08:00									#45
	Inflate your Upload Space

Can't talk long, got code to churn. But this is just too juicy a discussion!!!

Mark:

I agree, 'sites' works well as a 'minimum' level we need to deal with. I would like to continue to plead for a site to be an object with a 'quality' value, and have the number of sites more directly related to the amount of workable space -- since one of it's main purposes is to control the placement or workers.

Beor:

I believe Mark's idea is that all units be controlled by giving them 'orders'. And one set of orders that he has given to a task force is how to respond to threats -- conservative, balanced or agressive. Then factor in the task force's aggressiveness attribute, and the leader's aggressiveness (and perhaps his discipline?). Then the leader selects a battle tactic . . .

I suggest that a military unit's behavior be determined by two things -- orders given by the player, and some attributes of the unit and/or the unit's 'leader' character.

Also, we should likely consider that when a unit enters a new mapsquare, it would certainly benefit (supply, combat effectiveness of men, etc) by going in to any infrastructure that could provide what they need. Again, the task forces have orders concerning 'pillaging'. And then they'll have to make some sort of 'discipline' check, as will their leader. So you could send an army to save Constantinople, and if you choose an ill-disciplined bunch of louts they may just sack Constantinople once they get there!

Man, this is sounding fun.

Of course, you'll be able to turn all this off, if you don't want to deal with it, so Richard should still be happy.

Richard:

Oh, no. That's the whole 'scalability' thing.

We will start with one terrain per square, but we are not in any way limited to that. Nor would we want to be, I think.

You're right, if I understand you to be saying that the 'human settlement' data will be provided by methods in the 'mapsquare'. You only need to list the data you'll need, and the methods will write themselves (public int getForestPct()).

Then again, looking at the object design, perhaps there's a more elegant solution . . .

[*]mapsquare


[*]terrain ("Forest")


[*]infrastructure ("Village")
[*]infrastructure ("Fort Valor")
[*]resource ("10,000 Fir Trees")
[*]resource ("4,000 antelope")
[*]resource ("1,000 small animals")
[/list]
[*]terrain ("River")


[*]infrastructure ("Dock")
[*]infrastructure ("30 Fishing Boats")
[*]resource ("30,000 Fresh Water Bass")
[*]resource ("30,000 gallons of water")
[/list]
[*]Ethnic Group ("3,000 Romans")
[*]Ethnic Group ("200 Etruscans")
[*]Task Force ("1,000 Romans")
[/list]
[/list]
(I just made numbers up. They may make no sense, but you get the idea).

I just made some changes while typing it. Man, talking this thru is really helping me. Thanks, guys.

Anyway, how about this -- as I've drawn above, let's make 'vegetation' a 'resource'. That makes lots of sense, to me. Any thoughts?

That way, there are only two different types of objects to deal with!

Well, I didn't keep it short. Now I can't reply to any other threads. Sorry.

I'm off to burn up the keyboard . . .

[This message has been edited by F_Smith (edited September 28, 2000).]

	29-09-2000 08:27									#46
	Support Apolyton or Terrorists Win

oops, double post.
[This message has been edited by Richard Bruns (edited September 28, 2000).]

	29-09-2000 08:34									#47
	Support Apolyton, buy Civilization 2

F_Smith:

quote: Of course, you'll be able to turn all this off, if you don't want to deal with it, so Richard should still be happy.

[*]mapsquare


[*]Task Force ("1,000 Romans")

[*]Climate ("Warm Temperate Zone")
[*]Water Rating
[*]Geography ("Hilly")


[*]resource ("X tons of coal")
[*]resource ("Y tons of iron ore")
[*]resource ("Z tons of non-ferrous ore")

[*]terrain ("Human Habitation")


[*]infrastructure ("Dock")
[*]infrastructure ("30 Fishing Boats")
[*]infrastructure ("Village")
[*]infrastructure ("Fort Valor")
[*]Ethnic Group ("3,000 Romans")
[*]Ethnic Group ("200 Etruscans")
[/list]
[*]terrain ("Crops")


[*]resource ("X bushels of barley")
[*]resource ("Y bushels of wheat")
[*]resource ("Z bushels of vegetables")
[/list]
[*]terrain ("Forest")


[*]resource ("X cord feet of lumber")
[*]resource ("Y tons of game")
[*]resource ("Z pounds of medicinal herbs")
[/list]
[*]terrain ("River")


[*]resource ("X tons of fish")
[*]resource ("Y gallons of water")
[/list]
[/list]
[/list]
[/list]
[This message has been edited by Richard Bruns (edited September 28, 2000).]

	29-09-2000 20:57									#48
	Support Apolyton

Hey, Richard:

Well, well.

You *are* understanding OO much better. Cool.

'Geography' is now called 'terrain', by the by. Same object, different name.

The object structure you posted is almost exactly what we've arrived at, with one exception -- that 'geography' object that holds all the terrain objects. It doesn't seem to be necessary. The 'terrain' objects can just be in a collection by themselves.

So your 'hilly' geography object should just be a 'hilly' terrain object. Because that allows for us, later, to scale this to include more than one type of terrain per 3,600 sq. mile mapsquare.

Oh -- I'd also put the 'water rating' at the 'terrain' level, too, so that each terrain type can have it's own.

I do agree that 'climate' belongs there, that seems right to me.

	30-09-2000 09:39									#49
	Inflate your Upload Space

One other thing you guys need is a size scale parameter for mapsquares. In a scenario where the default square size isn't used this parameter would allow scaling the default numbers of sites, etc. up or down by the appropriate ratio (usually by area I'd imagine).

F_Smith:

On sites vs acreage and quality. I really think you are dealing with a fiction here. If you want to be realistic, as I said above, you would need a distribution of qualities all in the same square. Even a desert has oases, stream beds that occasionally flood etc. These are Much better for agriculture than the average ground in the desert. The sites abstraction handles this marvelously, since the first few people to farm this land are very productive, since they take all the good spots. Then as you add more people you find out that beyond the few good places its a dump But your trying to model farmland in a square as an acreage with a single quality number would in this case say nobody could farm there and survive! Your approach is IMO going to produce more unrealistic effects than sites are... Only if you go to the full-blown many-land-qualities per square thing do you gain any advantage. And I claim that is Huge Overkill in a game where individual squares are frankly not that important.

But as usual, if you Must put it into the object model to remain at peace with the universe, go ahead . So long as it doesn't show up in or affect the standard econ model I don't care that much.

	30-09-2000 09:41									#50
	Increase the size of your Attachments

F_Smith i really don't see the purpose of multiterrain enviroment because most people will generally look at the mapsquares for the type of general terrain and if we have more than 1 terrain then there will be hundreds of possible tiles! Besides the differances in 3600sq km of terrain wouldn't in most places be signifigant to worry about and would encourage too much micromanagement of each square.

Other than that i will be working on some way of handling the differnt types of possible tiles because there are so many possible ones already.

	29-09-2000 22:01									#51
	Support Apolyton buy from Amazon

Mark:

For now, I'm satisfied with the 'sites' approach. I'm only talking about making a 'site' an object with a 'quality' variable, so it shouldn't be any big thing to add or ignore.

You are definitely rigth about 'scale'. I'll put that in.

Lordy:

Off the top of my head --

[*]For 'edge' squares between two terrain types, like the edge of a large body of water, a square will have to be able to have both 'water' and 'land' terrain. Same with forests, mountains, etc.

[*]For a single, unusual terrain in a mapsquare that can have a major effect on game play -- like an 'oasis' in the desert.
[/list]

I think there are more, too.

But it's lunch time. Gotta go stuff myself.

	29-09-2000 22:18									#52
	Support Apolyton, buy Civilization: The Boardgame

F_Smith:

quote: terrain ("Forest")

quote: 'Geography' is now called 'terrain'

So you want to treat the geography and vegetation as the same kind of object? That could be okay, I guess. I would say that the location has hills and the hills have a forest, while you say that the location has hills and a forest. The ecology model planned on having the vegetation depend on the available geography, which meant that the forest would need to get info from the hills to determione various things.

The reason I wanted the Geography object was because it would store things like the Land Value and number of sites, and all the Vegetation objects would inherit this directly. I guess we could just keep those in the new terrain objects and have the other terrain objects input those values.

I think that vegetation and geography are sufficiently different that they will end up being two seperate classes derived from the Terrain class.

I'll put in some Ecology model concepts where I think they could go for the game modeling; let me know if what I propose will work.

Natural Water Rating (NWR) includes water that is dirently available to plants, like rainfall and dew.

Potential Water Rating (PWR) includes groundwater and surface water that is used by humans for various purposes. Note that this assumes the presence of small unmodeled streams throughout the tile.

Land Value is an attribute that includes soil composition, slope of the land, and any factor of the geography that determines how well plants can grow.

Farm sites are found by an equation that includes Land Value, NWR, and human influences like fertilization and irrigation.

Mining and other resource sites would presumably be determined by equations that use the square resources and infrastructure and the civ's technology level.

So we have, at maximum detail level:

[*]mapsquare


[*]Task Force ("1,000 Romans")

[*]Climate ("Warm Temperate Zone")
[*]Natural Water Rating
[*]terrain ("Hills")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of coal")
[*]resource ("Y tons of iron ore")
[*]resource ("Z tons of non-ferrous ore")
[/list]
[*]terrain ("River Valley")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of clay")
[*]resource ("Y tons of gravel")
[/list]
[*]terrain ("Human Habitation")


[*]infrastructure ("Dock")
[*]infrastructure ("30 Fishing Boats")
[*]infrastructure ("Village")
[*]infrastructure ("Fort Valor")
[*]Ethnic Group ("3,000 Romans")
[*]Ethnic Group ("200 Etruscans")
[/list]
[*]terrain ("Crops")


[*]resource ("X bushels of barley")
[*]resource ("Y bushels of wheat")
[*]resource ("Z bushels of vegetables")
[/list]
[*]terrain ("Forest")


[*]resource ("X cord feet of lumber")
[*]resource ("Y tons of game")
[*]resource ("Z pounds of medicinal herbs")
[/list]
[*]terrain ("River")


[*]resource ("X tons of fish")
[*]resource ("Y gallons of water")
[/list] [/list] [/list]
Note that for the ecology model to work, the Crops terrain object needs to get Land Value and PWR info from the Hills and River Valley terrain objects. Also, the infrastructure objects in the Human Habitation terrain object need to be able to alter these same values. And the River terrain object will need to alter the PWR of the River Valley object. Is this possible with this OO structure?

It seems to me that the Hills should contain the forest and the River Valley should contain the river, but I'm sure you have a good reason for treating them all the same.

By the way, the main game won't have anything like this detail level. We're just seeing what can be done; I am not trying to say what will be done.
[This message has been edited by Richard Bruns (edited September 29, 2000).]

	29-09-2000 23:36									#53
	Support Apolyton, buy Alpha Centauri

Richard:

No, geography and vegetation are not the same type of object. Geography is the 'terrain' object. 'Vegetation' is the 'resource' object. Man-made improvements are the 'infrastructure' objects.

So the 'mapsquare' will hold the 'hills' terrain object. The 'hills' object then will hold the vegetation 'resource' object (the actual forest). And the mapsquare will hold the 'river valley' object, and the 'river valley' will hold a resource of 'fresh water' (the river).

The 'land value' and 'number of sites' can be stored at either the 'terrain' level or the 'mapsquare' level.

One thing I might should have mentioned last post -- "human habitation", "forest" and "crops" wouldn't be 'terrain'. They'd be 'infrastructure' and 'resources', stored in a terrain object. The 'ethnic groups' would not be stored in the 'human habitation' infrastructure object -- EGs will be stored at the 'mapsquare' level. Each EG can have a pointer to the habitation they 'live' in, tho.

Yes, absolutely, objects can read up or down the hierarchy to get whatever values they need.

	30-09-2000 01:09									#54
	Support Apolyton, buy Civilization: The Boardgame

F_Smith:
Well I'm working on the various types of landforms from the bottom up. FE You need land before anything else, so what types of land can there be? This is also needing to be cocenred with the Map generation based on genoicaly stable/instable worlds. Then you add tempature because this determines all else, including the form water is in, and then water and what form and salt content, the vegitation and finally human habitation.

As far as info for edges go, wouldn't it be easier for the object to simply look at the other neighboring squares for that instead of having it in the square itself? I know this is important, even on a superfiscial level because of how hills and mountains can look more uniform instead of each being 1 square appecie and looking the same height (that seemed kinda ridiculus to see uniform deserts and mountain ranges with a new mountain for each square).

As far as the oasis goes, again that is no problem because it would be stored as far as 'water' object or whatever you call it.

Anyway i will have all the terrain type info in a couple of days. In terrain i mean all factors, not just what it means as an object. I'll post it in the now group owned ecology model.

BTW Mark or Rich can you send me the map gen model stuff you have?

	30-09-2000 01:14									#55
	Support Apolyton, buy Call to Power 2

F_Smith:

quote: terrain ("Forest") resource ("10,000 Fir Trees") resource ("4,000 antelope")

quote: Geography is the 'terrain' object. 'Vegetation' is the 'resource' object.

I'm confused.
---
Is this what you were thinking of?

[*]mapsquare


[*]Climate ("Warm Temperate Zone")
[*]Natural Water Rating
[*]Ethnic Group ("3,000 Romans")
[*]Ethnic Group ("200 Etruscans")
[*]Task Force ("Fifth Legion")
[*]terrain ("Hills")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of coal")
[*]resource ("Y tons of iron ore")
[*]resource ("Z tons of non-ferrous ore")
[*]resource ("Forest")


[*]resource ("X cord feet of lumber")
[*]resource ("Y tons of game")
[*]resource ("Z pounds of medicinal herbs")
[/list]
[*]infrastructure ("Fort Valor")


[*]pointer to TF
[/list]
[/list]
[*]terrain ("River Valley")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of clay")
[*]resource ("Y tons of gravel")
[*]resource("River")


[*]resource ("X tons of fish")
[*]resource ("Y gallons of water")
[/list]
[*]infrastructure ("Village")


[*]pointer to EG's
[*]infrastructure ("Dock")
[*]infrastructure ("30 Fishing Boats")
[*]infrastructure ("Housing")
[*]and so on. . .
[/list]
[*]resource ("Crops")


[*]resource ("X bushels of barley")
[*]resource ("Y bushels of wheat")
[*]resource ("Z bushels of vegetables")
[/list][/list][/list] [/list]
So is that what you had planned on?
[This message has been edited by Richard Bruns (edited September 29, 2000).]

	30-09-2000 01:27									#56
	Remove this text

LGJ: All I have that you don't is the Java code, and I haven't been able to get any insights from that. Look in the map genrator model thread to see what they currently have.

	01-10-2000 09:01									#57
	Full PM-box? Change here!

I've been absentminded for the last day or so, and you've really discussed some important issues.

This is going to be a little unstructured, since I'm a litle confused. Please read it carefully: I think some of it may be important:

It seems you've collapsed the location object (former terrain) and the terrain object (former geography) into one object layer (terrain), and that seems reasonable. We wouldn't want a location that had more than one type of geography, and we wouldn't want a type of geography to occur more than once in the mapsquare (I think ?! We'll have all hills in a square in one object, right?). So it's a one-to-one relationship and there's no need to have two 'layers'.

Fine, but somehow I think the original geography idea got lost along the way. My understanding was that the geography was supposed to model the underlying ground: Deep sea, Shallow sea, Flatland, Hills, Mountains basically (maybe a few more, but not many). On top of this vegetation would appear. So forrest and hills should not be on the same level of the object hierarchy, since you can have hills with or without forrests.

Another thing: I think that a river-valley object is inappropriate. What would happen if the river dried up? A river-valley object without a river! I think it should be a valley geography object with a 'River' ressource or some such thing.

On the same note: I think that naming a Forrest terrain object containing a 'Fir trees ressource' is not only confusing, but wrong: If the 'Fir trees'-ressource was harvested, you would have a Forrest terrain object without any tress . You cannot separate the Forrest from the trees, they are one and the same. It could be a flatland/hills/mountains object with 'Trees' ressource. The original geography object should be independent of the contained ressource objects. Real world concepts that are conglomerates of several ressources are a little bit tricky. The forrest nearby where I live has trees and game. If there were no trees there would be no game - at least not to the same degree. This is not symmetrical: There could be trees without game - although probably not for long, since game would reappear quickly: The only real way to completely erradicate game in an area is to destroy the habitat (sorry ) they're occupying.

Then maybe I'm completely wrong: Maybe a 'Trees' ressource is never depleted, and neither is 'Game'. They might just represent the amount of a given ressource that can be harvested from an area, keeping the area in equilibrium. However, if that was the case I don't think that they should be independent objects, rather attributes of a Forrest object. The forrest object representing the combined ressources of a forrest could OTOH be depleted, being replaced by something else.

I am going to try to make a simplistic outline of what I think we should be able to model in the game.
1 One mapsquare can contain a limited number different locations.
2 Each location can have one and only one terrain type: Deep sea, Shallow sea, Flatlands, Hills or Mountains (maybe a few more)
3 Each terrain type will only occur once in a mapsquare, so the locations in 1 really represent all land of a given terrain type in one mapsquare. It has not been mentioned before, but shouldn't the percentage of the square covered by a particular terraintype somehow enter the equations.
4 On top of the terrain (being either Deep sea, Shallow Sea, Flatlands, Hills or Mountains) we will have a limited number of vegetation types: Kelp, Barren, grass, forrest, farm-land, human habitation and a few more. If I understand Richard correctly, the ecology model represents these in percentages of the total area of each terrain type.

So this would be something like:
Sq 5638 has 50% flatlands, 30% hills, 20% mountains
The flatlands of the square is covered with 80% farmlands, 15% forrest and 5% human habitation
The hills of the square is covered with 30% farmlands, 48% forrest, 2% human habitation, 20% barren
The mountains of the square is covered with 5% farmlands, 15% forrest, 80% barren

The ressources available would then be a function of both the terrain and the vegetation type. These ressources would represent the amount of a given ressource that could be harvested from a given combination of terrain and vegetation type while keeping the ecology in equilibrium.
These ressources should probably be supplemented by ressources that could be depleted (specials?). There should be routines of turning one type of vegetation type into another: Forrest to farmland, Forrest to barren, etc. This might even happen as a result of excessive use of particular ressources.

I am not good at this but here's a shot at the object structure

Mapsquare object
Climate
Natural Water Rating (couldn't we just call this Rainfall)
Vector of pointers to EGs
Vector of pointers to TFs
Vector of pointers to mapsquare bound Infrastructure (Major Roads, Railroads, Canals, Major Rivers (in general stuff important enough to influence the relationship with neighbouring squares, particular transportation)
% Deep sea
% Shallow sea
% Flatlands
% Hills
% Mountains
…
(the above sums to 100%)
Vector of pointers to Terrain objects (Deep sea Terrain object, Shallow sea Terrain object, Flatlands Terrain object, Hills Terrain object, Mountains Terrain object, …)

Terrain object
Pointer to Terrain Type object (Deep sea type object, Shallow sea type object, Flatlands type object, Hills type object, Mountains type object)
Extra potential water rating (PWR above whats in the Terrain type Object - might be negative?)
Vector of pointers to EGs
Vector of pointers to TFs
(Vector of pointers to terrain bound infrastructure (Cannot think of any at the moment, possibly because the terrain is potentially spread out across the square))
Number of extra food sites/10.000 km^2 (Sites above whats in the Terrain Type Object - might be negative?)
Number of extra resource sites/10.000 km^2 (Sites above whats in the Terrain Type Object - might be negative?)
Number of extra special sites/10.000 km^2 (Sites above whats in the Terrain Type Object - might be negative?)
% Kelp
% Barren
% Grass
% Forrest
% Farmlands
% Human habitation
…
(the above sums to 100%)
Vector of pointers to Vegetation objects (Kelp Vegetation object, Barren Vegetation object, Grass Vegetation object, Forrest Vegetation object, Farmlands Vegetation object, Human Habitation Vegetation object…)

Vegetation object
Pointer to Vegetation Type object (Kelp type object, Barren type object, Grass type object, Forrest type object, Farmlands type object, Human Habitation type object, …
Vector of pointers to EGs
Vector of pointers to TFs
Vector of pointers to Vegetation bound infrastructure (anything from lumber mills to cities, depending on the type of vegetation object)
Number of extra food sites/10.000 km^2 (Sites above whats in the Vegetation Type Object - might be negative?)
Number of extra resource sites/10.000 km^2 (Sites above whats in the Vegetation Type Object - might be negative?)
Number of extra special sites/10.000 km^2 (Sites above whats in the Vegetation Type Object - might be negative?)

Having Human Habitation at this level is logical, but maybe we should change 'Vegetation' to …

Terrain type object / Global object containing what's typical in this kind of terrain
Type (Deep sea, Shallow sea, Flatlands, Hills, Mountains)
Base Potential Water Rating
Base Number of Food Sites/10.000 km^2
Base Number of Resource Sites/10.000 km^2
Base Number of Spec Sites/10.000 km^2

Vegetation type object / Global object containing what's typical in this kind of vegetation
Type (Kelp, Barren, Grass, Forrest, Farmland, Human Habitation, …)
Base Number of Food Sites/10.000 km^2
Base Number of Resource Sites/10.000 km^2
Base Number of Spec Sites/10.000 km^2


The number of sites/10.000 km^2 at any level can then be obtained:

FE the number of food sites per 10.000 km^2 in the hills of square xx

getFood=objMountainType.basefood + this.extrafood + a * %kelp * objKelp.getFood + b * %baren * objBarren.getFood … z * %whatever * objWhatever.getFood [+ effects of terrain bound infrastructure]

a,b,…,z are constants reflecting that a particular vegetation type in this particular terrain might yield less/more food than the base value.


[This message has been edited by Beör (edited October 02, 2000).]

	30-09-2000 23:54									#58
	Support Apolyton, buy Alpha Centauri

Hi, Guys:

Great discussion. Sorry I'm kinda AWOL this weekend, between coding and b'day stuff I'm putting the forum on the back burner.

But you guys have really helped me with this, I want to thank you all. This is likely one of the best object designs that has ever gone into a game.

	01-10-2000 22:44									#59
	Got spare money?

Beör:

The resources listed are what humans can get out of the forest. So there could be plenty of trees but no useful lumber. And the ecology model will most likely change the vegetation if too many trees get cut down. The "Forest" object exists for the purposes of the ecology model, while the "Lumber" object it holds is used by the economy model.

Natural Water Rating includes rain, snowmelts, dew, and many types of precipitation. We could call it Rainfall for simplicity, but that wouldn't be entirely accurate

I really think that your analysis is the same thing we already have. Everything you said is in the model as I imagined it. FE the "hills I mentioned were supposed to be all the hills and I assumed there would be a percentage in there. Sorry I wasn't more detailed.

So I believe we agree.

All:

I have been thinking about the vegetation class being derived from the resource class. Simply for naming purposes, it would be good to call them different things. Right now, we don't know if "resourse" means the entire forest or just the medicinal herbs.

So I propose creating a derived class called "GroundCover." Originally I called it "Vegetation", but that definition wasn't broad enough. This class extends the resource class and adds the following functionality:

Defines the percent of land area of the terrain occupied by the ground cover.

Determines erosion, soil loss, water quality changes, global climate change effects, and other things needed by the ecology model.

Determines defense adjustment and travel time for land units.

GroundCover classes include crops, natural vegetation, water, and human habitation.

So we have:

[*]mapsquare


[*]Climate ("Warm Temperate Zone")
[*]Natural Water Rating
[*]Ethnic Group ("3,000 Romans")
[*]Ethnic Group ("200 Etruscans")
[*]Task Force ("Fifth Legion")
[*]terrain ("Mountains, 20%)


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of iron ore")
[*]resource ("Y tons of non-ferrous ore")
[*]GroundCover ("Barren ,99%")
[*]GroundCover ("Human Habitation, 1%")


[*]infrastructure ("Lookout Posts")


[*]pointer to TF
[/list][/list][/list]
[*]terrain ("Hills, 70%")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of coal")
[*]resource ("Y tons of iron ore")
[*]resource ("Z tons of non-ferrous ore")
[*]GroundCover ("Scrubland, 30%")


[*]resource ("Y tons of game")
[/list]
[*]GroundCover ("Forest, 68%")


[*]resource ("X cord feet of lumber")
[*]resource ("Y tons of game")
[*]resource ("Z pounds of medicinal herbs")
[/list]
[*]GroundCover ("Human Habitation, 2%")


[*]infrastructure ("Fort Valor")


[*]pointer to TF
[/list][/list][/list]
[*]terrain ("Valley, 10%")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of clay")
[*]resource ("Y tons of gravel")
[*]GroundCover ("River, 10%")


[*]resource ("X tons of fish")
[*]resource ("Y gallons of water")
[/list]
[*]GroundCover ("Human Habitation, 10%")


[*]pointer to EG's
[*]infrastructure ("Dock")
[*]infrastructure ("30 Fishing Boats")
[*]infrastructure ("Housing")
[*]and so on. . .
[/list]
[*]GroundCover ("Crops, 80%")


[*]resource ("X bushels of barley")
[*]resource ("Y bushels of wheat")
[*]resource ("Z bushels of vegetables")
[/list][/list][/list] [/list]

	02-10-2000 02:16									#60
	Inflate your Upload Space

Richard

I also think that we agree, now we've cleared the percentage thing (although I think the percentage should be at the 'host' level, since the hills will not 'know' how big a fraction of the total square they are).

GroundCover, I don't know? It sure beats vegetation . How about LandUsage?

Every time you refer to a particular ressource (FE ore, lumber, game), you are really referring to a number of sites aren't you? So why not call ressources sites at least for programming purposes? It would underline the connection between the economic model, the map and the ecology model.

How do you like my hinting at having a global Terrain Type object that holds a base PWR, and a base number of sites. These base numbers are then subjected to modifications on an individual terrain object basis. In my post above I suggested just adding or subtracting PWR or sites, but it might be better handled as a relative modification or maybe both:

If this was an average hills square it would have a PWR of 6, 0 food sites, 4 resource sites, 0 special sites.

1 However, the particular hills in this square is not as rich as average, so we multiply the resource sites by .6, giving 2.4 prod sites.

2 However, the particular hills in this square has a large deposit of some special comodity, so we add 2 special, giving 4 resource and 2 specials

3 etc

Same system goes for GroundCover + GroundCoverType, although here there's no base water value.

Is this system compatible with the ecology model?

To keep scalability I actually think that sites should be grouped in one Sites object.

If sites are modelled in a Sites object, the modifiers suggested above should be modeled in a SitesBonus object, which could handle both multiplication and addition/subtraction.

If we later decided to add new types of sites, we would just have to change the Sites object and the SitesBonusObject, and of course some handling of sites in the economic model. The Mapsquare, terrain and GroundCover object would never know we changed the handling of sites, since all data are encapsulated in other objects.


[This message has been edited by Beör (edited October 02, 2000).]