Military units movement

[Mark_Everson]

I'm with you on all your points, Gary. And as you say, airpower is more dependent on range than movement rate. (Although at some point we may need to include a movement rate in some way so we can figure the 'effectiveness' at range.)

Just one question...

Why should the multiplier for flat be 1.5??? It seems to me flat should be the standard, and so have a multiplier of 1.

[Gary Thomas]

Why should the multiplier for flat be 1.5??? It seems to me flat should be the standard, and so have a multiplier of 1.

Perhaps "flat" is a misnomer. My standard is a formed road.

"Flat" includes ditches, gullies, streamlets, bogs, detours around outcrops, small valleys or dells, and so forth.

Try walking over open ground for any length of time and compare it with walking on a formed road. I will change the name "flat" to "open ground" if you like. I don't like "plain" because that has overtones of no intersecting features (like gullies or streams).

There can be a lot of impediment to walking before you get to the level of rolling downs.

Also, doing it this way leaves the way open for different type of "flat". Bear in mind that, over the scale of 100 km a heck of a lot of dissected territory will still qualify as flat. Potentially we could have "flat" subdivided into "billiard ball" (or some similar but more suitable term), "slightly bumpy", "dissected" or whatever, each with their own characteristics. The only one of these that could be used as standard is "billiard ball" which would probably be the same as "road".

The reason for picking formed road as the standard is:

• it is outside the system (as explained in my previous post)


• it is the fastest surface for travel (in our context anyway) so all multipliers are greater than 1


• it is almost invariant over different landforms. At some stage we might want to penalize roads over mountains in some way, but we can assume that even such roads will find the easiest route and my suggestion has simplicity in its favour


• we don't have to pick out some other special terrain type that doesn't otherwise stand out and label it


• we don't have to include roads in the XML because they are always 1, and roads, if they were put in the XML would have to be identified as something special with overriding properties

Cheers

[LDiCesare]

Gary, your specs sound good.

Movement kinds: Yes. There is a multiplier in the code btw, but it's always 1 for now and probably for D5.

One point: What about multipliers for settled areas? As you said elsewhere, there are lots of small roads in settled areas, so that should affect movement. Automatically have road in settled squares?
On the same topic, making non-roads unpassable for wheeled units seems good, but wheeled units should be able to go on settled areas because of the small roads. If roads are not terrain, how do you specify that not-roaded is impassable and roaded can be passed through? We need a special tag for that I believe.

[Gary Thomas]

One point: What about multipliers for settled areas? As you said elsewhere, there are lots of small roads in settled areas, so that should affect movement. Automatically have road in settled squares?
On the same topic, making non-roads unpassable for wheeled units seems good, but wheeled units should be able to go on settled areas because of the small roads. If roads are not terrain, how do you specify that not-roaded is impassable and roaded can be passed through? We need a special tag for that I believe.

That is a really good point which I hadn't considered carefully enough. One way around it would be to give setteled land a multiplier of around 0.8, so flat, settled land has a multiplier of 1.2 (1.5*0.8), compared to 1.0 for a highway, or 1.5 for unroaded flat land. These parameters, of course, can be fine tuned later.

The comment on wheeled vehicles is correct. We need to indicate that the presence of certain types of terrain (settlement in this case) negates the impassible state of the underlying terrain for some units. It is something I would like to set aside for a few days while I think about it. There isn't any hurry for this one. Whatever we decide can be incorporated when it is ready.

In passing, this multiplier system removes my last objection to having default movement values in the XML. I never thought that default movement costs made much sense, but default multipliers certainly do.

Cheers

[Gary Thomas]

I am having trouble with two areas of the system, relating to movement.

The old system had movement operating by pressing an arrow key, then the unit moved, then you could move it again, or switch to another unit and move it.

This is, essentially, incompatible with simultaneous movement. The unit doesn't move until the end of the turn. I could make the arrow movement system work like the mouse system, with a red line showing the path, until you switch to another unit.

My other problem arises from the fact that military units are not differentiated by owner (civilization). Each map square has a list of units, in order of arrival in the square, regardless of the civilization they belong to.

For each civilization in the square I need a single representative unit image to display, and I also need the total force of that civilization in that square.

While I could write the code to work all this out it is quite complex and really belongs in the military model.

What I would like is a sort of super-task-force, which includes all the units in the square that belong to a particular civilization. The mechanism for this is already in the task force class. The map square would be altered to just have a list of theses larger units, one entry per civilization.

This will make drawing the map quite simple, and will even cope with the situation where there are more than one civilization in the square.

Cheers

[Mark_Everson]

Hi Gary:

1. Yes, the arrow movement should just work like the mouse does. An arrow push just indicates a movement order for the unit in question, not actual movement.

2. IMO the single image to show for a given civ's TFs in a square should be the 'active' TF. If none is active for movement, then the largest (in Power). Total power for a civ in a square should be shown (again IMO) as it was in demo 4 by drawing a power circle indicating total power in the square. (This means there will be two concentric power circles in squares with more than one TF. One circle matches the power of the TF image shown, and the other the Total power in the square) I don't really like your mega-TF idea because then as two TFs move through a square at the same time, the image could be different than Both of the individual TFs. This could result in a lot of confusion for players since something that looked like a catapult one turn could look like an infantry unit the next (when it enters the square with another TF), and then return to looking like a catapult when it leaves...

[Gary Thomas]

1. Yes, the arrow movement should just work like the mouse does. An arrow push just indicates a movement order for the unit in question, not actual movement.

OK, I will implement it with a red line.

This could result in a lot of confusion for players since something that looked like a catapult one turn could look like an infantry unit the next (when it enters the square with another TF), and then return to looking like a catapult when it leaves...

I think that you misunderstood my intent. There will be absolutely no difference, as far as a player is concerned, between the system I proposed and the one you outlined (symbol for the largest unit, power circle for the total). If a different unit becomes the largest unit, then the symbol will change in both systems.

My intent was to try and use the mechanism that is already present in the military model for:

1. Finding the symbol for the biggest unit.
2. Adding up the power values for units belonging to a civilization in a square.

It really does seem silly to duplicate all that code in the GUI, and that is what it appears that I will have to do. In addition, for every square, on every tick, and every time a player makes a move, I will have to go through the list of units in the square and sort them by civilization and figure out how many civilizations are present. Then, for each civilization I have to go through all the task forces it has present to find the biggest, and also to add up their power.

As I said, most of that is already in the military model, and I would rather use that code. It is always extremely dangerous to have two separate sections of code doing exactly the same thing. It is too easy for them to get out of step.

I did not intend that the meta-unit would appear in the TF panel or be used for any other purpose.

I suppose I could just assemble these task forces, but I am worried about the possible impact onother aspects of the system - those observers hanging around for example.

Cheers.

[Mark_Everson]

OK, sorry I misunderstood you. Whatever seems best is fine by me then. Hopefully Laurent can put together something appropriate for you.

[The Cid]

Roads and terrain

Hi there,

I was reading the discussion on the effect of roads on different terrains, and I was wondering if the best approach would not be to separate the problem of terrain mobility into two variables: topography, and groundcover, or something similar.

As I see it, in a simplified way, movement is affected by the topography, by which I understand mountains and hills, things that you have to turn around from or that you have to climb and come down from... on the macroscale, roads would do little to improve that, although modern construction techniques can to some degree. This could be the first multiplier of movement.... to which itself would be multiplied by the second modifier: ground cover.

By ground cover I understand the immediate surface on which we walk... mud, swap, forest. Putting a road would set this multiplier to 1 (or even better depending on road technology) but it would still be multiplied by the topography one since going up and down hills still keeps the distance longer, and more tiresome, but having to cross forests in the mountain would be much more of a penalty than walking on a road.

So having roads affects the groundcover multiplier, but not the topograph multiplier.

[LDiCesare]

Gary, we can use the TempTaskForce class just for that.
I could even refactor some code in EncounterManager to reuse it, I 'll see. I think I'll recompute it everytime because I don't want to store an additional pointer/collection in MapSquare. I'll code and send a new MapSquare class to you, probably tomorrow.
Cid, I agree with you, but Gary raised the point of unpassable terrain, so unless we provide an "infinite" multiplier it doesn't work well. Also, roads on plains are faster than plains (say x2), but on mountains they are much faster (say x4, total still slower than road on plains), so it may not be that simpler.

[Gary Thomas]

I think I'll recompute it everytime because I don't want to store an additional pointer/collection in MapSquare.

I was thinking of replacing the existing un-differentiated list with a list by civilization, so the map square would still only have one list.

Of course, in most squares the list would be empty or contain only one civilization.

Cheers

[LDiCesare]

Too late, I coded the stuff yesterday.
As I said in my mail, it would be sensible to do it the way you say, but I need to change the way encounters/fights manage the square task forces in order to do that. For the moment, I think we can say that only the list of TFs per civ method should be used, and deprecate the old one. There should be only a shift in private data. If you can use the additional method I put in, I'll leave it that way for now.

[Gary Thomas]

I will get to checking this out as soon as I have done the input mode stuff (see the D5 countdown thread). Mainly this means coding the arrow key stuff which had never been organized for simultaneous moves.

Cheers

[Mark_Everson]

In my brief look at demo 5 last night I came to one conclusion with regard to showing movement. (BTW Gary the pathfinding is great!) Right now all programmed TF moves are shown as a red line whether they will be completed by the end of the coming turn or not. I think it would give the player a feeling of being more in the action if we were to show the TF moving on the map as far as the turn-end goes. My overall concept for demo 6 and further on would be that:

1. A TF that hasn't been moved yet this turn will show any current orders as a red line, but with arrow-heads indicating where it will be at the end of each turn of pre-programmed movement

2. Once move orders are entered or changed there would be a big red dot or something left on the 'starting' square, and a red (or some other color) line would go from the dot to where the TF will end the turn. The TF image would be shown on the square where it is expected to end the turn (once the turn is cranked). We could use two different colors for lines representing movement within this turn, and in subsequent turns. Or even use a different color for each turn in the future to allow planning of coupled movements of troups that need to rendevous at some future point. Of course I think the TF Image should only move when the pathfinding has been locked in so as to not have the TF dancing around on the screen as the movement cursor is repositioned.

What do you guys think? IMO this will bring the player more into the action. Not as much as with player phases where the action really happens in the turn, but at least closer to that ideal.

[Gary Thomas]

I rather like the system in Space Empires IV. They have a line showing the path to be taken, but at the middle of each square is a number - 0 means the square will be reached this turn, 1 means next turn, and so on.

I have made preliminary provision for the situation where selecting a unit makes any existing move visible in this manner. I will arrange that, by default, new orders are added to the path. To change the orders, they should first be cancelled.

I do expect most of this to be operational for D5.

Cheers