Map AI coding

[Gary Thomas]

plains 4
rough 6
mountain 10
sea no
road -1

Right now we have "flat", "rolling", "broken", "rocky", "swamp", "tundra", to which I might add "mountain" and "desert". I think that perhaps "rocky" means mountain, but am not sure.

Then there are "roads", "canals", "tracks", "railways", "passes" (my favourite), "river".

Also "forest", "bocage", "urban" area"

I'll change the move method which currently teleports to something where I expect to be called from one square to an adjacent square. I guess map AI can tell the next square needed to go to the final target.

Currently the GUI calls movement with only one square move per call, either from the arrow keys or from the animator, rather than sending a whole string of orders.

If, as Mark has stated, movement is to be simultaneous, the units will have to get their orders and remember them, then execute them in some complex timing sequence, using, in effect, and animation thread.

The tick system means that all units have the same "movement allowance" but different movement costs. The movement allowance system normally encountered is intended to enable all units to have the same movement cost for a particular terrain. Since the tick system is more flexible I am in favour of it.

What worries me with the proposed system for military units is that all the units now have to be aware of all the possible types of terrain. Adding another terrain will mean changing:

1. The terrain code
2. The map GUI code
3. The military XML file
4. The military XML parser
5. The military code

I would much prefer fixed categories of unit:

1. Light foot
2. Heavy foot
3. Light wheeled
4. Heavy wheeled
5. Tracked
6. Naval (perhaps light - canals, rivers and inshore, and heavy - blue water)
7. Airborne

would almost seem to cover it. Adding another category to this would require all the changes listed above, but would, I believe, happen much less often than adding a new terrain type.

My main preference for this system is that the landforms are separated from the unit information. These categories describe the characteristics of the unit, not the land. In effect, the number of dependencies is reduced.

The differential movement costs would then depend on the category, and would not need to be in the XML. Each unit would still have a base movement value, but terrain-aware code could make the adjustments necessary for other than flat terrain.

Cheers

[Mark_Everson]

I too prefer the Light foot / Heavy foot / etc. assignment of 'movement type' to a unit. Otherwise the player will need to remember too many details. What do you think Laurent?

On terrain types, which list are you dealing with Gary? From the code, or from the Vegitation... thread? If its the stuff in Joe's old code just ignore it. He threw in whatever he felt like without regard to it being in a model. Take a look at the spec that Simon came up with about half way thru the Vegetation etc thread and see what you think. Once you check that out we can take the discussion further.

[LDiCesare]

I can put the category rather than movement costs, but then the movement costs per category will have to go in the terrain classes I believe.
I will then propose for an army to have a tag
<movement>heavyfoot</movement>
heavy foot/light foot/heavy wheel/light wheel/airborne/light naval/heavy naval are ok to me, I don't get tracked (my English must be lacking here - could you explain). Plus do you make a difference between motored and ancient wheels?
I also think light cavalry and heavy cavalry should be in.
I could then add a terrain section where I'd have
<terrain>plains heavyfoot 4 lightfoot 4 lightwheel 3 heavywheel 4 etc.
</terrain>
or
<terrain>plains 4 lightwheel 3 </terrain>
(just overload specific units)

[Gary Thomas]

I inadvertently left out "light mounted" and "heavy mounted".

Whether there needs to be a light/heavy distinction is open to argument.

"Tracked" means running on tracks, like a tank.

I don't particularly make a distinction between ancient and modern wheels.

Any difference must be a difference that affects the game, not a difference that might affect the game.

A separate terrain section might be a good idea, but it needs to be cleanly accessible, not buried in any part of the code. Perhaps an interface to get the required information is the best idea.

Cheers

[Mark_Everson]

Yeah, terrain definitely needs its own code section, because it will be plenty complicated with all the economic sites, vegitation, and whatnot.

[Gary Thomas]

&ltterrain&gtplains 4 lightwheel 3 &lt/terrain&gt

This is a bit oversimplified. It implies that the program recognizes "plain" as a terrain type. I would much rather be more explicit:

&ltterrain&gt
&ltname&gtplain&lt/name&gt
&lttype&gtlandform&lt/type&gt
&ltmovement&gt4 lightwheel 3&lt/movement&gt
&ltimage&gtflat.gif&lt/image&gt
&ltother stuff&gt...&lt/other stuff&gt
&lt/terrain&gt

(apart from the fact that I think wheeled transport should always be restricted to roads)

Incorporating the economics stuff requires some care. It should only be present if it is always present in terrain of that type. In effect, I believe the terrain objects should be totally static and never change during game. If the terrain in a square changes, it should be implemented by pointing to a different terrain, rather than by modifying the terrain. Otherwise keeping a whole lot of potentially different terrains in step becomes a coding nightmare.

In the same way (and, I think, already implemented by Laurent) a basic military unit should be static - I think this is currently called an archetype.

The tech material (all ready for D6) works that way. There is a TechnologyObject, static and unchanging, and each tech owner has a TechnologyLevel object which points to the TechnologyObject and contains the specific level as well.

Cheers

[LDiCesare]

I agree. I can put the unittype/movementinfo tag on the units.
As for terrain, it is more complicated given the existing code. I think that putting all data in a xml file is a good idea, and that way we could generate at start a bunch of terrain types (like tech and unit archetypes).
However, the current Terrain code doesn't fit in very well with that model. I can try and adapt it so that terrain types are determined from a text file, but then it may cause trouble to map generators to do it that way. If noone else has better ideas, I'll try it once I put the movement info in the Armies, which should be fast.
I'll start by allowing to fill just the movement costs for the existing terrains (I won't recognize other types yet) and we can try to see if armies can move on such shaky ground.
What do you think?

[Gary Thomas]

The present (coded) terrain system is pretty bizarre and incomplete. I can have code available in a day or two to implement the ideas that I put forward in the ecology thread.

If those ideas are accepted, then unit movement could have cumulative modifiers:

1. For landform
2. For landcover
3. For altitude (probably not necessary)
4. For climate (probably not necessary)
5. For road/railroad/canal/river

all of which could be expressed separately (and many of which would not apply).

What we need is a lookup class to relate each of these, with a unit class (heavy foot, etc) and produce a tick value. I will write a static class to do this (today) and send you (Laurent) a copy, so you can populate it, either with hard-coded static value, or from an xml file. How's that?

Cheers

[LDiCesare]

That's fine with me. I already prepared the xml tags and skeleton code so as soon as I can put some code in it, I can do it. I'll also retailor the movement code in military package.

I think we may also need one type of unit movement which is amphibious. Although there aren't that many amphibious units, there are a few tanks which are amphibious (although they usually only cross rivers and cannot fire in rivers). We could also have naval airborne and land airborne (for planes that land on sea - not that they were much used in warfare, but they exist - ).

[Gary Thomas]

I am just a little unsure of myself here, but it seems to me that the best way of handling amphibious units is by giving every type of unit two movement values - land and sea. Of course, for a phalanx sea movement would be rather limited...

Air units would have the same movement values for land and sea.

To cover the "movement forbidden" situation I have a movement class returned by a movement query, which has a movement forbidden specification. This, I feel, is better than, say, having a tick value of -1 to indicate no movement.

I am inclined to think that the base land movement for all units should be based on movement on a good highway, and for sea movement based on sheltered coastal waters. Then all the terrain effects can be added ticks.

Can anybody tell me how long (in time) a move is supposed to be?

Cheers

[Gary Thomas]

I forgot to mention that there has to be some means of indicating that some terrain is pre-emptive. A road through a forest negates the delaying effect of the forest.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
Can anybody tell me how long (in time) a move is supposed to be?

One month is the uniform timescale throughout the game for a turn of movement. (However economic, technological, etc. timescales can vary over the game.)

Movement rates were meant to be such that in a turn a land-based TF would only be able to move a few squares at most under potential engagement conditions. On rail, or protected roads where there is no fear of blundering into the enemy movement rates much higher would of course be possible.

BTW maybe we should start a thread on "Military Movement Coding" or something, since most of this discussion really ain't Map AI stuff...

[Gary Thomas]

I kept it in the map AI thread because the actual movement values critically affect the map AI.

Perhaps what we need is a terrain thread.

Cheers

[Darkknight]

I'm being serious here I know you're doing great work and all but how did you start off, did you Take the civ2 code and modify it or did you start from the beginning and create a whole new game?
I'm sure I downloaded this but I cant for the life of me find it on my harddisk and I'm getting lost looking for it in the Apolyton site, As usual

[Mark_Everson]

Hi Darkknight:

Clash is a from-scratch whole-history 4x game. Nothing comes from Civilization except some general ideas.

You can download demo 4 from the web site, but demo 5 isn't out yet... I should have bumped up the 'basic info' post that has the web site on it. Will do that now.

Let us know what you think! (But not in the Map AI coding thread )