Announcement

**Richard Bruns** · September 28, 2000, 23:34

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.

I would never turn those features off. I definitely want to have a realistic modeling of troop discipline and actions. They should not be mindless drones; I want them to act properly.

I just don't want to mess with tactical manouvering.

---

Um, what happened to the geography attribute (hills, flatland)?

I don't think it would be wise to store a fort in that forest object. For example, assume that the ecology model creates scrublend vegetation on 25% of that square. It would make a new object, right? Later, the ecology model might just decide that all the forest needs to vanish and be replaced by scrubland. Then what happens to the fort? I can imagine the players cursing if defense structures vanished like that. . .

This is yet another definition problem. I thought "terrain" meant geography, not vegetation. That's why I don't like the word; it is confusing. But I'll use it in your context.

I don't understand what you mean about treating vegetation as a resource.

Here's the structure I was thinking about:

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

**F_Smith** · September 29, 2000, 00:06

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.

**F_Smith** · September 29, 2000, 11:57

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.

**F_Smith** · September 29, 2000, 13:01

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

**Richard Bruns** · September 29, 2000, 13:18

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:

[This message has been edited by Richard Bruns (edited September 29, 2000).]

**F_Smith** · September 29, 2000, 14:36

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.

**Lord God Jinnai** · September 29, 2000, 16:09

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?

**Richard Bruns** · September 29, 2000, 16:14

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?

[This message has been edited by Richard Bruns (edited September 29, 2000).]

**Richard Bruns** · September 29, 2000, 16:27

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.

**Mark_Everson** · September 30, 2000, 00:39

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.

**Lord God Jinnai** · September 30, 2000, 00:41

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.

**F_Smith** · September 30, 2000, 14:54

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.

Lordy:

There are massive coding bonuses to modeling each object seperately.

Richard:

That's it exactly. Perfect. If I had a cigar, I'd give it to you!

Beor:

You also are right on.

One thing -- you mentioned that the 'vegetation' object might have another name. How about 'vegetation' (and 'ore deposit' and 'wildlife' and anything else that fits) extending a 'resource' superclass?

That way, the 'terrain' will only hold two object types, 'resources' and 'infrastructure'.

Does that sound reasonable?

**Beör** · October 1, 2000, 00:01

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

**Richard Bruns** · October 1, 2000, 13:44

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:

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

**Beör** · October 1, 2000, 17:16

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

Announcement

MapSquare Class OO discussion

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment