Announcement

**Mark_Everson** · July 10, 2001, 20:58

Bonjour Laurent:

IIRC Gary proposed that there be no 'dual-terrain' (flat (90%) rolling(10%)) squares. And I think that's the right way to go, since otherwise things can get Really complicated without much benefit to the player.

As for road infrastructure... it will probably exist in a gradiated fashion as you propose for the minor roads. The major ones (that show explicitly on the map) will either be there or not, although there might be levels to them like dirt, paved, etc.

On speed/movement for units vs ticks, it could have a proportional effect on ticks, but that could be tricky. Forest slows down infantry, but it slows down armor a lot more... So I'm not sure about the right general way to handle movement+terrain -> ticks at the moment. I'd say just keep it simple for now, perhaps ticks inversely proportional to movement as I think you're suggesting, but keep in mind that its just temporary until we figure out a good way to handle it.

**LDiCesare** · July 11, 2001, 04:32

Main terrain is not much of a concern to me, it's mainly having a lots of roads/few roads which I am interested in so that's OK.
The cover ticks cost will depend on unit type, so basically you would have things like this:
<Terrain>Forest
<MovementCost>2 foot 1 air 0
(close the tags)
This means that a land cover of forest adds 2 ticks for all units except foot units (1) and air units (0).
So you will have several terrain costs, one for cover, one for soil type (slower on sand than soil?), one for wetland/dryland, one for roads and one for main land type (flat, rolling,...).
If I have for instance:
Terrain road MovementCost 1 air 0 /MovementCost /Terrain
and
Terrain noroad MovementCost 3 air 0 wheel no track 2 /MovementCost /Terrain
I can make it so that if you have just a few roads, wheeled units can go in the square but at a high cost, (say +10 ticks). If the terrain is only 50% road, I could go for an average like (for a foot unit) 3 + 1/2 = 2 additional ticks.
Note that a system like that generates lots of ticks.
The best you could have would probably be:
(first figure for foot units, second for tracked units)
flat 4 4
railroad 0 0
dry 0 0
soil 0 0
no cover 0 0(4 ticks)
But you will soon get
mountain 10 15
no road 3 2
dry 0 0
rock 2 3
forest 2 3(17 ticks or 23 ticks - wheeles couldn't cross this).
These figures will all be in a xml file so testers can tune them to find good values.

**Gary Thomas** · July 11, 2001, 16:36

Here is my comment on mixed terrain:

One of the things that will never, in my opinion, be relevant to the game is the possibility of partial terrain squares: 50% plain, 50% mountain. On the other hand, I feel that mixed cover (50% forest, 50% pasture) will play a very important part in the system.

The mixed cover allows a 10,000 km² are of land to be gradually cleared. For movement purposes I would take the least movement cost cover - units will tend to move through pasture land rather than forest.

The terrain I proposed (in the ecology thread!) was:

1. Landform. This is the physical shape of the land. The categories I propose are: flat, rolling, broken, massif. Visible on map.
2. Material. What the land is made of: soil, sand, rock. Visible on map, unless covered.
3. Altitude. In metres, rounded to 100.
4. Landcover. None, crops, pasture, scrub, forest, jungle. Visible on map.
5. Climate. As specified by Simon. Not visible on map.
6. Watertable. As far as my purposes are concerned, this affects low altitude flat land only, producing swamps which are visible.

Linear features can be superimposed. Natural ones:

6. Rivers. Described in more detail below.
7. Lakes.

Human generated linear features:

8. Roads.
9. Railroads.
10. Canals.

Other humans artifacts:

11. Urban areas.

There are two different kinds of movement modifiers which must be recorded in the XML file, it is not sufficient to have a single value.

The two types are:

**Mark_Everson** · July 11, 2001, 16:51

The spec looks basically good to me!

One comment on item 7 (unit teleport to square when moveLeft = 0). The only Really disturbing case I think we need a rule for is so that opposing armies can't teleport *through* each other when 'exchanging' squares. (Army in square A goes to B the same tick as army in B goes to A.) The armies should meet/fight in one of the squares. This isn't essential to have right for d5, but it should be in there eventually.

Less vitally, at some point we need to figure how detailed we want moving in and out of squares to be. FE if my TF is moving into a square, and an enemy is moving out of the same square away from me, but My move is executed one tick earlier than his, is there a battle? In the real world there probably wouldn't be. For now, and possibly forever, we should just handle it by tick -- as in there Would be a battle in the case I outline if orders allow for it.

I propose we forget about railroads for the moment and keep things simple. When we start to put in the modern stuff we can worry about the right way to handle rails. It will take a bit of thought IMO. FE do we need trains to carry things or can TFs just ride the rails as in civ...

**LDiCesare** · July 12, 2001, 00:57

Originally posted by Gary Thomas

There are two different kinds of movement modifiers which must be recorded in the XML file, it is not sufficient to have a single value.

The two types are:

**Gary Thomas** · July 12, 2001, 15:23

Yes. To me the only overriding value is "can't go there". Otherwise, the modifiers would be of two types: + or *, as you say.

What about my example of a road over a mountain? Doesn't the road value override the mountain's value?

And I am strongly against not having a default value. If we ever allow people to add their own unit types (say you want to make a mod where you have tunneling units -why would you have to go ob the ground or above it when you can burrow after all-), how do you allow that? People can't define a new kind of units, and they would have to fill in values for each and every terrain, which in xml is a little tedious. Also, if you want to change the cost of flat lands, you just need to change 1 figure ang get 60% of work done...

You have convinced me...

ALL military orders have a destination square, which may be far apart. Computation of the tick cost is of no interest to the order. It is of interest to the TF and the movement manager. Military orders are stored in the unit for as long as they are not completed. This sets the next square along the road, so you don't have to repeat the target square but just tell nextTick in the tick manager. Do I understand?

The issue here is "how do they get the destination square?". If it is from the GUI, using the map AI, it will ALWAYS come as a sequence of consecutive, adjacent squares. In effect, an order to move to a square includes the route to take. It may, of course, be cancelled and replaced by a different route or destination later. The reason I have chosen that method is that (although it isn't implemented yet) I would expect people to set move through waypoints - as in go to that square by the quickest route, then go to this other square by the quickest route. However, in each case the route is displayed for the user so they can decide whether they want that route or not. Then the route is fixed. When giving a real life order to a military unit the route is always specified.

It would certainly be possible for each unit to call the map AI each time they want to move, but the overhead would be horrendous - I would expect each turn to take quite a bit of time. By its very nature the A* algorithm is calculation intensive, particularly if the destination is distant. In my system the map AI calculation is done once only.

When implemented, I expect the general AI to mimic the way the GUI does it, and calculate the route once only.

Are you a pacifist Gary, never attacked diplomats or settlers, ? Although I agree that non military units move, I stress that they can and will be attacked, so they are no different to me than regular military units (except they have no attack values, poor they). You could even make taskforces with settlers (like I'll settle over there, but I want to protect my guys). So I don't think there should be units outside the military model, since arnies have to be able to attack them. In particular, sea units like transports are prime military targets, even though they may only carry diplomats or settlers.

I was fooled by the term "military.model" - I guess it should be mobil units model. Anyway, I surrender.

However, I do think that the terrain movement calculations belong with where they are now, in the model.physical package. The offence/defence effect of terrain will have to be sorted out though.

The movement system (which was working) has stopped working. I will try and check that out later today.

Unfortunately I am having health problems - this has slowed me down somewhat. I thought I had recovered, but it does not seem to be the case.

Cheers

**LDiCesare** · July 13, 2001, 03:13

I had a few glitches with my computer yesterevening, so I couldn't send the code

Road over mountain is usually still slower than road over plains, so that's why I'd rather get a multiplier. This doesn't work for changing impassable terrain into passable, though, so you have a point.

I checked my code, and here is how it works now:
I have a tickmanager that calls newTick() on all Army instances it knows. This newTick checks the current order destination and asks to move there.
The move() method manages the tick count and teleport when done.
My problem is to know which is the next square to move to, since I'd expect the player or AI to say "go to that square N squares away", and I'd store that in my order queue. When the order first becomes active, I should ask the pathfinding algo what is the path, store it, and then my UnitOrder class would have the target square plus a path (array, ArrayList or whatever) telling me each intermediate square to go through.

As for finding the terrain calculation, yes, keep it where it is.

A question is: How many times do you refresh orders? It may happen that you no longer can go a certain route because a huge army just stopped by there. To change the path, we should avoid recomputing it every turn just in case something chabged (which also can lead to going to and fro some point where the computation result changes).
I guess we can give the paths to an AI (slightly above tactical level?) which knows when an enemy enters a square through which we wanted to go, and decides whether to recompute a new route or just ignore it (either they're far away and may have moved when we get there, or the unit isn't significant enough it can't be crushed through).
That may not be D5, though.

**F_Smith** · July 14, 2001, 14:15

Hi, ya'll:

Can I suggest a 'Transportation' object? I favor all 'GamePiece' type objects encapsulating a 'Transportation' object.

The 'Transportation' object would be where the 'movement' decisions should be made, I believe. It should evaluate the terrain it's crossing, and return a movement value.

And you absolutely would gain from the ability to add and remove 'Transportation' objects. Plus, you can have greater diversity of 'Transportation' objects, which would enhance gameplay significantly.

The player then can have a choice between 'riding horses' and 'war horses', 'basic truck' or 'armored personell carrier'. You can easily change a gamepiece from riding trucks to riding in airplanes.

Etc.

Just a suggestion.

P.S. -- wish I had more time to contribute. Life is just so nuts. Fortunately/unfortunately, Java is really becoming the 'hot new tech' that everyone has to have . . . I still lurk, occasionally, but that's about all I can do.

Ciao.

**Gary Thomas** · July 15, 2001, 19:34

Road over mountain is usually still slower than road over plains, so that's why I'd rather get a multiplier. This doesn't work for changing impassable terrain into passable, though, so you have a point.

Even this doesn't work. If the mountain has the base value and the road is a multiplier, how does the program know which is which without some distinguishing tag in the xml file? Also, although a road over a mountain is slower than a road over a plain, a road over a swamp is not slower, so a simple multiplier will not do. What is required is a careful model of what happens in real life, rather than just coding it in a convenient way.

This then leads me to an extension of the reasoning that resulted in the unit categories. How about terrain categories? Say: easy, moderate, difficult, very difficult and impassable. We would still need the option of having a road override the underlying terrain, but it would certainly simplify the combinations.

I checked my code, and here is how it works now:
I have a tickmanager that calls newTick() on all Army instances it knows. This newTick checks the current order destination and asks to move there.
The move() method manages the tick count and teleport when done.

Could you email me a copy of the tickManager (I have one also, based on a separate thread so it won't interfere with the GUI)?

My problem is to know which is the next square to move to, since I'd expect the player or AI to say "go to that square N squares away", and I'd store that in my order queue. When the order first becomes active, I should ask the pathfinding algo what is the path, store it, and then my UnitOrder class would have the target square plus a path (array, ArrayList or whatever) telling me each intermediate square to go through.

A question is: How many times do you refresh orders? It may happen that you no longer can go a certain route because a huge army just stopped by there. To change the path, we should avoid recomputing it every turn just in case something chabged (which also can lead to going to and fro some point where the computation result changes).
I guess we can give the paths to an AI (slightly above tactical level?) which knows when an enemy enters a square through which we wanted to go, and decides whether to recompute a new route or just ignore it (either they're far away and may have moved when we get there, or the unit isn't significant enough it can't be crushed through).
That may not be D5, though.

The GUI and the AI will never say "go to a certain square". They will say "here are your orders: go to this adjacent square, then go to the next adjacent square, then..."

There are three distinct reasons for this approach.

The first is the sheer calculation burden of recalculating the path algorithm every time a unit passes a square boundary. This I feel will have a serious impact on game speed.

The second comment is an answer to the argument that, say, a large enemy unit will get in the way. When a unit is ordered to move and it encounteres the enemy, the movement orders should be cancelled. If the enemy is further away than the next square, the moving unit is unlikely to know it is there and so will push on regardless.

The third is my real reason for not allowing units to change there route in mid-move. It is infuriating when units don't do what they are told. In the system at present the human player can try various options until a suitable route is found, then the orders are sent to the unit. Then player always has the option of cancelling the orders before they are completed, but one of the GUI options I will provide is for the player to display any unit's remaining proposed path after the orders have been given. It can be changed if it becomes out of date. If the unit can change its mind on the way, I can only ask why? The terrain won't have changed, though I suppose something like a flooded river or destroyed bridge could occur. In this case the unit wioll just wait after sending a message to the owner, just as would happen in real life. Again, running into an unexpected enemy unit in the next square (100 kms away), the unit would either stop, attack, or retreat, depending on more global orders. It wouldn't recalculate its path to go round the enemy unit (a process that could easily lead it thousands of kms out of its way, around a mountain range or sea).

So, in answer to the question, how often do we recalculate the path? We do it only when the original orders are given. This has the advantage that it is already coded, it minimizes cpu loading, it is realistic, and it is simple.

Cheers

**Mark_Everson** · July 15, 2001, 20:02

I don't think Never recalculating the path is a viable option in the long term. For one thing one order will be 'attack army X' which needs to be recalculated basically every turn if the target army isn't intercepted immediately. Otherwise the player would have to re-issue the order every turn, which would be maddening.

I, however, have no problem with one-time calculation being all that happens for now, pending other more-important things being implemented. IMO eventually, the player at their option should be able to determine recalculation of path frequency etc. (Maybe just a 'level' for overall military AI to use?)

BTW, I don't know if you realize it, but I don't plan to use just A*, but also intelligently-determined waypoints as described on the map AI page. This should help quite a bit for calculating paths of TFs that move far.

**Gary Thomas** · July 16, 2001, 01:08

I don't think Never recalculating the path is a viable option in the long term. For one thing one order will be 'attack army X' which needs to be recalculated basically every turn if the target army isn't intercepted immediately. Otherwise the player would have to re-issue the order every turn, which would be maddening.

I, however, have no problem with one-time calculation being all that happens for now, pending other more-important things being implemented. IMO eventually, the player at their option should be able to determine recalculation of path frequency etc. (Maybe just a 'level' for overall military AI to use?)

I wasn't suggesting that there shouldn't be any recalculating of paths, just that it should be under control. On the other hand, how far away is the army to be chased by the "attack a certain army". I wouldn't think such an order is very realistic if the target army is more than one square away. In any case, the recalculation is only needed if the target army moves. And, in most circumstance I can't see how on earth the attacking army would know the other army had moved. Even with modern technology this is difficult.

The "one-time" calculation only exists because we have no AI to issue successive orders.

BTW, I don't know if you realize it, but I don't plan to use just A*, but also intelligently-determined waypoints as described on the map AI page. This should help quite a bit for calculating paths of TFs that move far.

I did realize that, but again, anything more than a very few squares will cover vast distances, more suitable for strategic movement than tactical.

Cheers

**LDiCesare** · July 16, 2001, 04:08

I believe the player wants to go far away, so they give orders to go far away at times (particularly for things like relocation of units to border cities, btw you could even automate that order, like the reloc button in Mastor Of Orion).
We can say that the UI and AI both catch the path and the orders given to the army is always one square away for the moment, so I don't need to worry with a list of squares in the order, but you manage it at the terrain/movement level. (I think that's what you meant from the beginning but I may be slow at times

)

As for tags for multiplier/overrider, yes. Difficulties for terrain, Gary can you elaborate?

The attack a certain army order can be given timeouts of some kinds (don't get farther than... or just don't run more than N turns). I think it is realistic in the sense that e.g. Darius sent armies to intercept Alexander a very long distance away from Persia to Cilicia. And, realistic or not, I think I would probably like to use such an order as a player.

Gary, I'll send you code this evening (my time) so next morning (or noon) yours.

**Gary Thomas** · July 16, 2001, 14:03

I believe the player wants to go far away, so they give orders to go far away at times (particularly for things like relocation of units to border cities, btw you could even automate that order, like the reloc button in Mastor Of Orion).
We can say that the UI and AI both catch the path and the orders given to the army is always one square away for the moment, so I don't need to worry with a list of squares in the order, but you manage it at the terrain/movement level.

You are quite right, that is what I meant, and as I said, it is actually all done. The reason that I called the path algorithm at that level is that a player can try out different paths before deciding on one. Then they "commit" the orders for that path. The easiest way of doing that is to just send the path that was just calculated as a series of one square moves. This will also make it easier (later!) to include waypoints, and further series of moves. Eventually I would expect standard routes to be available, so a unit could be referred to the "take the train from your base to the west coast" route in some simple fashion. The route, however, would be a series of one square steps.

The attack a certain army order can be given timeouts of some kinds (don't get farther than... or just don't run more than N turns). I think it is realistic in the sense that e.g. Darius sent armies to intercept Alexander a very long distance away from Persia to Cilicia. And, realistic or not, I think I would probably like to use such an order as a player.

There needs to be a distiction between a deployment or strategic movement order, and a tactical order. When Darius sent his armies, he didn't say "go and attack the 2nd Pahalanx unit". He probably said something like "go and look for that barbarian upstart and deal with him". Certainly the Persians would have had only vague information about the composition and position of Alexander's army.

Gary, I'll send you code this evening (my time) so next morning (or noon) yours.

Thanks.

I just tried to post a large post to a new thread on terrain generally, and lost the lot when my internet connection went down. I will try again later.

Cheers

**Gary Thomas** · July 17, 2001, 17:50

I have been thinking (deeply!) about movement, and have reached some conclusions.

First, there are certain aspects of movement which shouldn't be forgotten, but which probably do not need implementing for D5 (my permanent obsession...).

General observations for later

Movement kinds:
Basic foot movement is of three kinds: normal movement (taking all necessary baggage along), rapid (normal movement, but leaving baggage behind) and forced march (as fast as possible). These are options that should be provided eventually.

Foraging:
This is terrain dependant and will impact on movement. It should not be forgotten.

Railway movement:
There are more issues than simple movement - the trains must be available and time must be allowed for embarkation and debarkation (is there such a word?). Also, troops leaving a train will be disorganized. In any case I propose to put that aside for the moment (at least for D5), since railway movement didn't have a lot of impact on the Romans and Carthaginians.

Air movement
I do not feel that this is the same kind of movement as land ot sea. The dominating factor for air movement at the strategic level is range, not speed. After all in one tick (3 days) an aircraft capable of 200 km per hour (a pretty slow plane by today's standards) could cover 144 squares, if it had the endurance. This is about a third of the way around the Earth.

In fact, the longest distance airstrike that I am aware of was the B52 raid from Diego Garcia to Iraq during Desert Storm. The round trip still took less than one tick. Accordingly I feel that air movement should be treated differently from land or sea movement, and postponed for D5 purposes.

Road movement.

After a lot of discussion about which terrain dominates and how to deal with overriding terrain (like roads), and multiplicative versus additive models (or both) I reached the conclusion that roads are different in kind from other types of terrain.

The model I propose is that the presence of a road leading from one square to another is recorded, but the road isn't considered terrain in the normal sense, after all the only characteristic it has is direction.

Although it is true that there could be grades of road, we have to realize that on the scale used any visible road is a major highway indeed, in effect, the best kind of road avaialble to the current technology. So we don't lose anything by having only one kind of road.

What I suggest is that the standard of movement for any unit be the number of kilometers that the unit can travel, under ordinary conditions, in one day, on a road, in sustained travel. For an infantry unit 20 to 30 km would be reasonable.

All other terrain would then be a modification of this, depending on the category of unit (foot, horse, etc), including impassible as a possibility.

If a road is present, it will be used, and in particular the road movement rate will be used. The unit will cover 3*m/100 squares per tick (a tick being a tenth of a turn, that is near enough to 3 days, and a square being 100 km). The program will, when calculating movement, convert this to the number of ticks required to reach the next square, giving 100/(3*m) ticks per square.

Other terrain

If there is no road present, the cumulative effect of other terrain is used. For each category of unit and each terrain type (except road) there will be a multiplier. These multipliers will be, not surprisingly, multiplied together to get the cumulative effect of the actual terrain. The ticks per square value derived above for roads will then be multiplied by that value, giving the number of ticks to reach the next square.

In passing, for diagonal movement the value is multiplied by sqrt(2), and where terrain differs in square moved from and the square moved to, the average value (half of each, added together) of the two ticks per square value used.

This all gives a system with a number of advantages:

It is simple.
It is easy to relate to actual speed on the ground.
Modification for different movement conditions is easy.
It avoids any problem of how to specify in an XML which terrain "dominates".
It still allows a great deal of differentiation between units.

Some examples might be, for foot:

Terrain	Multiplier
Flat	1.5
Swamp	2
Forest	1.5
Massif	5

So the multiplier for the Everglades (flat, swamp, forest) is 1.5*2*1.5 = 4.5, for example.

Cheers

Announcement

Military units movement

Military units movement

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment