MapSquare Class OO discussion

[F_Smith]

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

[Richard Bruns]

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.

[Beör]

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.

[Mark_Everson]

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.

[Richard Bruns]

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.

[Richard Bruns]

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.

[F_Smith]

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.

[F_Smith]

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.

---

Richard:

I'm sorry if it seems confusing sometimes.

But using the "is a/has a" method, can you see why this is an OO analysis? Terrain "has a" geography, geography "has a" vegetation.

I think you understand this better than you may realize.

[Richard Bruns]

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.

It could be a problem that infrastructure affects water availability and crops. Can things lower in the hierarchy have thet kind of effect on things at the top?

Should we be discussing this in the Ecology model thread?

[F_Smith]

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.

[Beör]

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 .

[Mark_Everson]

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.

[Richard Bruns]

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

I was inder the impression that each mapsquare had exactly one geography (terrain) object. In my example, each location (mapsquare) would have one geography object, one climate object, and one water object. Each geography object would have one settlements object, so anything put in the settlements object only happens once per square, just like it did before.

[F_Smith]

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

---

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")[/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).]

[Richard Bruns]

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