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?

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

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.

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.

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

To clear up confusion, here's the current object hierarchy:

• mapsquare
  
  
  
  • terrain ("Forest")
    
    
    
    • infrastructure ("Village")
      
    • infrastructure ("Fort Valor")
      
    • resource ("10,000 Fir Trees")
      
    • resource ("4,000 antelope")
      
    • resource ("1,000 small animals")
      
    
    
  • terrain ("River")
    
    
    
    • infrastructure ("Dock")
      
    • infrastructure ("30 Fishing Boats")
      
    • resource ("30,000 Fresh Water Bass")
      
    • resource ("30,000 gallons of water")
      
    
    
  • Ethnic Group ("3,000 Romans")
    
  • Ethnic Group ("200 Etruscans")
    
  • Task Force ("1,000 Romans")
    
  
  

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.

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

• 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")
        
      
      
    • terrain ("Crops")
      
      
      
      • resource ("X bushels of barley")
        
      • resource ("Y bushels of wheat")
        
      • resource ("Z bushels of vegetables")
        
      
      
    • terrain ("Forest")
      
      
      
      • resource ("X cord feet of lumber")
        
      • resource ("Y tons of game")
        
      • resource ("Z pounds of medicinal herbs")
        
      
      
    • terrain ("River")
      
      
      
      • resource ("X tons of fish")
        
      • resource ("Y gallons of water")
        
      
      
    
    
  
  

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.

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.

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.
  

I think there are more, too.

quote: terrain ("Forest")

quote: 'Geography' is now called 'terrain'

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")
      
    
    
  • terrain ("River Valley")
    
    
    
    • Potential Water Rating
      
    • Land Value
      
    • resource ("X tons of clay")
      
    • resource ("Y tons of gravel")
      
    
    
  • terrain ("Human Habitation")
    
    
    
    • infrastructure ("Dock")
      
    • infrastructure ("30 Fishing Boats")
      
    • infrastructure ("Village")
      
    • infrastructure ("Fort Valor")
      
    • Ethnic Group ("3,000 Romans")
      
    • Ethnic Group ("200 Etruscans")
      
    
    
  • terrain ("Crops")
    
    
    
    • resource ("X bushels of barley")
      
    • resource ("Y bushels of wheat")
      
    • resource ("Z bushels of vegetables")
      
    
    
  • terrain ("Forest")
    
    
    
    • resource ("X cord feet of lumber")
      
    • resource ("Y tons of game")
      
    • resource ("Z pounds of medicinal herbs")
      
    
    
  • terrain ("River")
    
    
    
    • resource ("X tons of fish")
      
    • resource ("Y gallons of water")
      

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.

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.

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.

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

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

• 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")
        
      
      
    • infrastructure ("Fort Valor")
      
      
      
      • pointer to TF
        
      
      
    
    
  • 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")
        
      
      
    • infrastructure ("Village")
      
      
      
      • pointer to EG's
        
      • infrastructure ("Dock")
        
      • infrastructure ("30 Fishing Boats")
        
      • infrastructure ("Housing")
        
      • and so on. . .
        
      
      
    • resource ("Crops")
      
      
      
      • resource ("X bushels of barley")
        
      • resource ("Y bushels of wheat")
        
      • resource ("Z bushels of vegetables")
        

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.

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

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
          
    
    
  • 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")
        
      
      
    • GroundCover ("Forest, 68%")
      
      
      
      • resource ("X cord feet of lumber")
        
      • resource ("Y tons of game")
        
      • resource ("Z pounds of medicinal herbs")
        
      
      
    • GroundCover ("Human Habitation, 2%")
      
      
      
      • infrastructure ("Fort Valor")
        
        
        
        • pointer to TF
          
    
    
  • 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")
        
      
      
    • GroundCover ("Human Habitation, 10%")
      
      
      
      • pointer to EG's
        
      • infrastructure ("Dock")
        
      • infrastructure ("30 Fishing Boats")
        
      • infrastructure ("Housing")
        
      • and so on. . .
        
      
      
    • GroundCover ("Crops, 80%")
      
      
      
      • resource ("X bushels of barley")
        
      • resource ("Y bushels of wheat")
        
      • resource ("Z bushels of vegetables")
        

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.

Um, 'groundcover'? I'm not sure that works, to be honest. Can't much spend time thinking about it right this second, tho.

The basic game architecture is in place, and ready.

I've defined all the classes, put them in packages, jarred them all up, and now I'm building the GUI. The GUI is coming out far better than I had hoped, too -- the 'Java2' classes called 'swing' have really helped to no end.

So anyway, we should be able to start running a few test cases after tomorrow nite.

For the moment, it'll be the previously mentioned 'mapsquare'/'terrain'/'resource' and 'infrastructure' hierarchy.

1) Are you guys considering to split infra into immobile and mobile? If so, where in the data structure mobile infra would be?

2) What's the gain in game terms about having mapsquares with more than one terrain?

3) I know the thread about animals (horses, elephants, etc) was put on hold, but maybe this is the time to think where they should be in the data structure. Any thoughts?

I have the same concerns as you have regarding the interface. But, as far as I can tell, all along it's been planned to have more than one location in a square: Particularly it was supposed to be possible to have units inside or outside a city. The object model we are constructing at the moment is really just a generalisation of this plan. It makes it possible, but not mandatory, to have these multiple locations. Most probably the default game will not make use of anything but the most primitive of these facilities.

So, why bother?

Because it helps defining the underlying object structure, making the scaling of the game a piece of cake. It gives structure and flexibility to the code. The relatively small effort will repay itself several times before we've got a finished product

Back to the interface. This is probably the major practical problem associated with multiple locations. How do you render a square that is 50% lowlands (partly grass, partly forrest), 25% hills (almost entirely forrest) and 25% mountains (barren). And how do you make it clear that this square has a different site composition, different combat modifiers and different movements costs from the neighboring square, where there's 45% lowlands, 35% hills and 20 % mountains of the same vegetation compositions. The difference in resources has to be handled anyway, because of the ecology model. This model will give very different outputs for squares that have exactly the same terrain: Production depends on terrain, water resources and climate. There's room for creative thought here. In the default game I think there will only be one terrain + one vegetation + maybe a city. And this could be handled by using the usual approach of showing the basic terrain + a city icon.

Now I'm just throwing some wild ideas as to the rendering of the map with multiple locations. As far as I can see the combined terrain and groundcover will mainly have interactions with the player in the following areas: Movement, Combat, Production, Beauty. When a player looks at the map he is interested in: How far can his units move, how well protected are they in case of attack, how much is produced in a square, and is the map artistically beautiful (this last part should not be overlooked: Playing an uggly map will quickly break even the most enthusiastic Civer). The problem with multiple locations is that what's important in one of these areas might not be important in another. The movement cost might be decided by the grass-lowlands, the combat by the forrested hills, the production by a combination of all terrains, andd the beauty by personal preferences. Maybe we should have parallel maps, one for movement, one for combat, one for production, and a beautiful one. A little like the variuos maps in SimCity (land value, crime, police cover pollution etc). Another possibility is small icons or signatures along square sides designating various forms of info.

What about the micromanagement with multiple locations- if we decide to use them. We've discussed it a little bit in this thread, and I think there's a general agreement that it should always be possible to play the game without having to decide which of the locations in a square a unit is in. The AI should handle the positioning of units on an as needed basis. If it doesn't matter wher the unit is, it will just be in the mapsquare. You could also say that it is in all locations at the same time, and if needed one of these locations is chosen by the AI - or optional by the player.

The same goes for EGs, who most of the time will just be in the mapsquare.

Infrastructure is a little more tricky, since some kinds of infrastructure only fit in some of the terrains present (shipbuilding in the Himalays). If the infrastructure is only allowed in one type of terrain, there's no problem: It will just be placed there when built. But if the infrastructure is appropriate in several types of terrain a choice has to be made. Most of the time this could probably be handled by the AI, but sometimes the player may have to be asked. This problem might not be so great if the no-buildings approach is adhered to strictly.

1. Yes, 'infrastructure' objects will have 'mobility' variables. So in the data structure, 'infrastructure' (both mobile and stationary) will be stored in 'terrain' objects (which are in 'mapsquare' objects).

2. Mapsquares that must have more than one terrain type, like a coast (part ocean, part land). Like the edge of a vast desert. Also for terrain contained within a mapsquare which isn't the 'base' or 'main' terrain -- Like a desert square with an oasis. Or a prairie square with a lake. That kind of thing.

3. 'Horses' and other animals will be 'resource' objects, stored at the same level as 'infrastructure'. So a 'terrain' object holds 'infrastructures' and 'resources'.
   

Just off the top of my head, anyway.

* * *

Beor:

I'm confused -- what's the problem with the interface?

Had planned to use a standard 'layering' approach which is used in games -- the terrain with the largest % will be the 'base' terrain. We draw that terrain graphic first. Then other terrains get drawn on top, one after another. Then the 'resources' get drawn. Finally the 'infrastructure' gets drawn.

There are a number of strategies we can use to organize this in the mapsquare -- four corners, etc.

Just like 'the beast' -- I drew the basic terrain (just a green or blue square), then draw the 'vegetation' (stupid little squiggles suppose to be trees), then draw the 'infrastructure' (the little 'castle' line drawing), then drew any task forces. The graphics have 'transparent' backgrounds, so they can be layered at will.

I do not see a problem with micromanagement. I think in practical use the AI will always be able to determine the best disposition of a unit.

This is a glance into the internal development of a piece of software, so if you're expecting polish and shine you'll be disappointed. But feel free to make any comments, just don't be too harsh in your judgment, not yet. There's a fully working datamodel underneath, you just can't see it yet!

I'm not saying it cannot be done from a programming point of view- off course it can. It's relatively simple using the approach you have proposed. What I am a bit worried about is how to cram so much information into such a little space, and have the player comprehend it. This is really not an OO subject, rather a graphical one, so I suggest further discussion on the subject should be done in another thread.

IMO it is not a pressing demo5 issue, so we can do that later.

Had a look at your working prototype. It's a bit slow, but otherwise very nice - unless it's supposed to do anything, other than handling the three windows.

All

I had noticed the slow speed, too. It's those swing components, 'JInternalFrame'. The repaint on them seems very slow. Altho I'm not double-buffering the images yet, and haven't over-rided 'update'. So I know a few ways to handle that. But I'm only drawing a simple rectangle in each square . . . if worst comes to worst, I won't be able to use these 'JInternalFrames'. Altho that would be too bad, I think they look pretty good, and would make gameplay a snap.

That's all there is to see, right now. Check again about midnight my time (central standard time).

P.S. -- I was under the impression that the 'no buildings' infrastructure classes were in addition to the necessary infrastructure classes that *have* to be on the map (roads, forts, factories, etc).

Roads and forts need to be explicit objects. Factories are infrastructure that will be handled in the standard system with a no-buildings infra approach. Why would factories *have* to be on the map?

I second Beör's comment about trying to cram too much on the map, and as he says its really a graphics, not an OO issue. There has been some talk around these ideas already, some of it going waaaay back. So when we get to it we should discuss it in a grapics/interface thread.

As it currently is, 'roads' and 'forts' are explicit objects -- subclasses of 'infrastucture'.

I was just assuming 'factories' would be also. This might be my mistake. I was thinking that a 'factory' had to be something the enemy could destroy (or possibly capture?). So I thought it had to be on the map.

I do agree that other people should determine what goes on each map 'view'. There will certainly have to be a bunch of different 'views' or 'looks' for the map, 'Caesar3' or 'SimCity' style. You'll have to be able to view all the resources in a square, all the military units in a square, all the economic output of a square, etc. This can be done in a variety of ways, of course, from numbers and text to layered grafix.

As you said, it's a grafix issue, not a programming one. Because certainly we shouldn't restrict the detail in a game function?

I think you'll like the JInternalFrame look, by the by. I'm trying to duplicate your original 'Clash' gui. More on that tonight, tho.

Once a map is designed for isometrics it looks bizarre as squares. If you are happy with diamond shapes, then that can be done easily.

F_Smith:

Tried out the toy. The general layout looks ok. IMO the frames need to be resizeable, tho I'd guess that's just a detail. Took about 30s to download, and not very long to run.

On factories... Sorry I didn't get your original meaning. Lets back up a bit. All infra is associated with a mapsquare (or I guess some part of it), so I don't understand the distinction you were making between roads and the no-building infra, like educational infra. At least in the current model, factories are the capital associated with the production sector, and not technically infra in the model at all. But 'factories' can be strategically bombed etc since capital in the sectors is also associated with a square.

It'll detect screen size, when done, and adjust itself accordingly. Sorry about that. That's life in development.

Mark:

Yeah, that's actually just a paramater I set to false, as it. They can be resizable, maximizable, minimizable, etc.

Okay, I'm sorry, but I need more clarification on this.

I don't fully understand -- and I'm coding exactly that part next (whenever I finish this IsoMapPanel). Please be patient with me!

im no expert but this is my view on the subject,

first pure m-v-c is hard to find , I think controller is a bit of an ambigous term and is not always easy to seperate from the view

i would agree with marks post on objecting to squares extending canvas ( not that im involved in the project , yet) .

re: jtable and m-v-c

data objects should not draw themselves, A model contains or knows about data, and the view draws the model. in a jtable the TableModel knows about the data (leaf/nodes) as represented by seperate objects/primitives, it is the renderer that is responsible for the actual drawing of the data( and there can be multiple renderers, one for each column , or even cell). the TableModel does not know how to draw itself, it knows things like how many columns the data represents, but leaves it to the renderer to actually draw each column/cell, it is this renderer that will extend a visual component( eg JPanel , JLabel etc), not the model and certainly not the data. Note that the model does not even know about renders, they are registered with the table not the model, you can change the renderer for a model on the fly, getting different views of the same data.

I would class the parts as follows
JTable = 1 part of view ( and controller in that it reorders columns etc)
Renderer = other part of view
TableModel = model (contians data ) ( also controller, in that table sorters are implementations of models, plug a sorter between THE model and the table)

If mapSquare extends canvas then this is not possible ( or much harder ). consider the diffrernt views of a square, the obvious one is when it is just a square on the main playing map, but i may be able to select a square for a more detailed view the square, this appears in a differnt window which gives more detailed information in a totally different display format. both views however are looking at the same object - the square.

I went down the route of squares extending panels when i first got into OO game writing and regretted it , believe me it is better to divorce the view/gui from the model/data. having the map square extend some visual component will make it hard to make changes to the way the game model and the game view work.

F_Smith:

Building an airplane factory, etc.

As a design issue I don't want to get into hundreds of dedicated facility types to build different things. I don't think the player gets much out of it. And it makes the AI's job that much harder to site all these things, balancing threats against ideal production locations etc. Now your OO model can have it the way you picture it, so long as it can accomodate whatever agreement we finally reach for the standard model.

Hi! Glad to have your comments, I need all the help I can get on this.

We are using observers too -- I think it is absolutely the right way to go about it. My comment above about a mapsquare 'redrawing' itself was a reference to that, in fact. I was speaking about 'functionally' redrawing itself -- in other words, the square is redrawn when the data changes and the data object fires the 'hasChanged()' method. The use of extending Canvas was simply a convenience, since otherwise the data object will have to have methods to define what gets painted. Extending Canvas provided all the methods I would otherwise have had to add -- getMinimumSize, getMaximumSize, paint, update, etc. I then used the 'MapSquare' in exactly the same way you'd use a 'ListModel', adding it to a 'MapPanel'.

The way I seperate the 'data model' and 'view' in my mind is that the 'data model' holds the information on what gets painted, while the 'view' component paints whatever the data model defines. Does this seem right?

* * *

Mark:

I'm sorry, I still am not clear. More stupid questions to ask. I'm going to have to build a Gui with this functionality, so I probably better ask questions until I understand it!

So --
When a player has just learned how to build fighter planes, how does he go about building them? Is it 'SMAC' style, where he can build those at any base? Including a 'prototype'-style first-build cost?

Can a player can build airplanes at any of his mapsquares? Or just in his capitals? What about 'specialization'? Can a player 'improve' his fighter plane factories seperate from his other industry, not counting new technologies? Do I understand correctly that a 'factory' can't be specifically destroyed/sabotaged/dismantled and moved on it's own? Is there then a 'factory' object at all, or just one 'infraclass'? If no 'factory' object, is there any specific game representation of a squares industrial capabilities?

Whenever this is required by a certain model, the generic infraclasses can be related to specific objects. These can be military units, wonders, even the civ2-styled city-improvements. See the infra thread for further explainations - I know that since you are discussion the OO structure of the game here, this is the best solution. Only if this approach is in contrast with some model features (f.e. Mark dosn't like military units having logistics based on # of "shields" that the unit costs) should we detach the cetrain objects out of the infrastucture system (this can be claimed for food, kapital and military units).