Terrain Effects for movement

[Hepps]

@Frostion Very true, Both valid points. I suppose I was caught in a perspective blindness. After reading your post I can see that now.

[Cernel]

The thing of creating territories in between to define connection related movement costs can be legitimized by adding an option for a territory to be transitable only, meaning units can move through this territory, but never end their movement in it. That way you would not need to make that territory non-clickable, to achieve the same result, that is a hack and fails for the AI. Then, you could just make maps with small territories, like circles, in between of two proper territories, that would have the function of taking movement, and may have a territory effect image in them, that clarifies the movement cost for each.

This could also have other implementations. For example, you could make a "Strait of Dover" sea zone with the property of being transitable only and with a Neutral unit in it, that makes AA shots at any units passing by.

[Cernel]

Another matter is how would retreat be handled?

If the cost is for entering, the retreat cost, if any, would be dependent on the territories you retreat to (not the one you retreat from, I suppose), albeit it would be also possible to assume that retreat is always free of charge, as the nonsense of expanding your movement capabilities by retreating is nothing new, as this is allowed also by the basic rules.

[redrum]

@Cernel Most likely retreat would stay free. Otherwise I think you ended up with a very complicated move system that probably doesn't add much depth.

[Cernel]

@redrum A way to keep it free and keep down complexity, while still making sense, may be to say that movement cost is paid for exiting in all cases, but, only when you enter a hostile territory you cannot blitz, you have, instead, also to pay for entering. That way, you would have already paid for the ability to possibly retreat, using it or not. This would also assure that retreating won't expand your movement abilities over what you could do if everything would be friendly, and create a system by which you substantially have equal or higher non combat than combat movement.

[Frostion]

"the nonsense of expanding your movement capabilities by retreating is nothing new"

If you look at retreat the following way, it should not be nonsense:
An army in one territory wants to move into and attack another territory, but other territory is defended by an enemy.
Attacking army moves into other territory, using 1 fuel as it costs 1 to move 1, but attacker crosses the border (or around the border area) they are halted by the enemy. Attacker realizes that he must retreat and that he cannot finish what he started (alias cant move into and freely around the new territory to take control. Most likely he also wanted to reach the center of the territory)
The attacker turns back having only used around half the fuel expected, but still ends up using all fuel as he must backtrack to starting position.

Thinking like this it makes good sense that retreating/turning back does not cost extra fuel. Kind of the same way embarking onto a ship, that is essentially located at territory border, paying full fuel, removes the need to charge fuel again when disembarking / completing the second half of a fuel using attack.

[Cernel]

@Frostion I thought it was obvious I was talking about the units retreating somewhere else but where they came from, not the ones going back whence they came. So, nothing of what you are saying, aside from attacks coming from 1 territory only.

[Cernel]

@Frostion I guess I should not have assumed that the matter was clear to everyone, as I was not being very clear in the first place, and not talking about retreat in general, but about some situations that may verify for some units under the current retreat rules for land units. So I will detail what I was talking about more specifically.

Let's take the "World War II Classic" game.

1. The simplest example of retreat is if I attack Anglo Sudan Egypt from Libya only, and retreat. In this case, retreating make some, or even enough, sense, as you can assume attacking the British units on the border of Anglo Sudan Egypt and retreating, likely after having gone only a little inside enemy territory, may be about as much movement expensive as destroying all British units and taking over the territory.

2. A more complex situation is, in the same case as above, if I blitz French Equatorial Africa (obviously a nonsense move on its own right, as you would not go taking Nigeria for free before attacking enemy forces in Egypt; but this is another matter, and blitz is not even a default ability) with the Armour, then attack Anglo Sudan Egypt from Libya and French Equatorial Africa, only. In this case, I'm allowed to retreat either to Libya or to French Equatorial Africa, with all my units. This is a borderline situation as, in either cases, since the multiple territories I'm coming from (and can retreat to) were in reach of Non Combat Movement from all units involved in the attack, while the total movement are expanding my movement capabilities on a strict sense (either the Armour goes from Libya to French Equatorial Africa, from French Equatorial Africa to Anglo Sudan Egypt, and from Anglo Sudan Egypt to Libya, moving into a total of 3 different territories (more than its movement 2 ability), or the Infantry goes from Libya to Anglo Sudan Egypt, and from Anglo Sudan Egypt to French Equatorial Africa, moving into a total of 2 different territories (more than its movement 1 ability)), all the final possibilities, attacking units can reach to, are at least destination they could have moved to without any retreat involved (in this case, either by just moving all units from Libya to French Equatorial Africa, or by just blitzing French Equatorial Africa back to Libya).

3. The case of retreating absolutely increasing your maximum movement abilities, that is the one I was referring to, can be exemplified by Japanese attacking Americans in China with Infantry units from Manchuria and French Indo China (only), then retreating all to either of those territories. For example, I could attack China with 5 Japanese Infantry units and, if having no losses, retreat all 5 Japanese Infantry units to French Indo China. In this case, I have 3 Japanese Infantry units that started their turn in Manchuria and ended their turn in French Indo China, without any transporting involved, that is a movement that they can not achieve on their own, during Non Combat Movement, not even if Americans would be an Allied player, allowing Non Combat Movement through China.

So, when I said "the nonsense of expanding your movement capabilities by retreating is nothing new", I was not referring to something like the first case, that I understand it is what you have in mind, but I was referring to something like the third case. And, even in the third case, I was not referring to all 5 retreating infantries, but only to the 3 coming from Manchuria (and retreating to French Indo China).

I suppose what you are describing could apply if we would have a property to oblige any offensives each coming from 1 territory only (but this would be a nonsensical limit) or a property that makes every units retreat whence they came (instead of all to a same place) (but this would have some issues or challenges, especially in the moment of selecting casualties).

I hope to have been totally clear now, relatively to what I was referring to. Substantially, the nonsense consists in the fact a hostile territory can allow you to move more than if that same territory would be friendly (allied owned) to you, and what I was pointing out is that this already existent dynamic is liable to become more problematic (bigger) in the moment you have different movement costs per territory, and especially if you pay for entering, rather than for exiting, territories. An example may be that I attack a same movement cost 1 territory from two non-adjacent other territories, one of movement cost 1 and the other one of movement cost 5, then retreat all into the movement cost 5 one, thus obtaining, at the price of 1 movement point, a movement that would cost a total of 6, if the attacked territory would have been a transitable allied or owned one, and I would have just non-combat moved over it, rather than strafing the same. The matter, of course, impacts on fuel too, if movement costs apply there as well (as they likely should).

[redrum]

@Cernel I really think you are getting into a completely different issue at this point. Having alternative retreat rules would be a good feature request to discuss and I think most people agree the standard A&A ones leave a lot to be desired especially around your case #3.

[Cernel]

I've kept thinking about this feature on and off, especially now with territory effects discussions, and especially for the case in which a tick forests should slow down cavalry. I think the best map on which to theorically apply (were it non abandoned) this feature would be Jurassic, where something like this is partially reproduced by just having the dinosaurs receiving movement bonuses upon starting on favourable terrains (an incomplete solution).

I still tend to think that charging upon exiting would be the best (and also consistent with how fuel cost currently works), but I can see pros and cons, for a number of scenarios. The main example I can think of for charging upon exiting is this case:

You have a "forests_deep" terrain that it is supposed to be bad for cavalry.
This terrain gives combat maluses to cavalry and slows it down (I really don't care about blitz).

You have three possible situations, when you are on the offensive (on the defensive it matters little, as you will have defensive combat maluses for statically defending in the forests):
Your cavalry moves through a deep forest.
Your cavalry starts outside a deep forest and enters a deep forest.
Your cavalry starts inside a deep forest and moves outside a deep forest.

In the first case, it doesn't matter if we charge the malus upon entering or exiting.
In the second case, if we enter the deep forest to do battle, the cavalry already has all the combat maluses, so the terrain issue is already felt, even if it doesn't immediately impact on movement.
In the third case, if the movement malus is given upon entering, being in a deep forest makes absolutely no impact, as you are not going to make combat in it nor be slowed down for exiting it. I don't think anyone would place its strategic reserves in the worst possible terrain for them to move, but with this system that would be not even a problem at all.
So I think charging upon exiting would be preferable to assure the deep forest will have an impact both in the second and the third case. In the second case, it will have an impact because I will have combat maluses (albeit no movement maluses) for invading a deep forest. In the third case, it will have an impact because I will have movement maluses (albeit no combat maluses) for launching an invasion from a deep forest.

Of course, one could give maluses for exiting territory effects by putting a unit in there, giving such maluses if you start in it, but, then, it would be very punitive if coupled with additional costs upon entering. In the example, if a deep forest would give -1 and you would have to pay an additional 1 for entering a deep forest, a cavalry that moves 2 would be completely unable to move from a deep forest into another deep forest.

As long as the binary matter of charging on entering/exiting, I would actually definitely suggest having a property for setting that. This is also the fairest way to settle the matter, leaving the mapmakers the ability to decide whether entering or exiting is the best for what they are doing. If, after some years, it would look like everyone is using one of the two options, and no one the other one, the property can always be removed (and the behaviour changed to the chosen one, if it was not the default) with no issues at all (you just need to run a search to verify who has set that property one way or the other).

I tend to think that a poll about it would probably end up in the entering option winning, though, just because it is the most intuitive of the two. So, I'm not surprised that a number of other games go that way, as well.

[redrum]

@Cernel IMO, you are overthinking the issue as a game is always going to be somewhat abstract anyways. Almost every TBS game I've ever played charged the movement cost when you enter a territory so that is naturally what players expect.

[Cernel]

@redrum Well, rather than charging upon exiting only, I'm rather in favour having a Boolean option for that, then the default can be charging upon entering, as I agree that is the most intuitive behaviour.

[Cernel]

If instead of territory effects, this feature would be units based, it would seem obvious to have it working upon exiting and consisting of positive bonues (that you can turn negative, by defining them as such), as this is how it practically already works, for units giving movement modifiers to other units, except only for the added limitation of effecting only units starting their turn in the same territory (or next to it, for sea units) (most likely this is just due to the fact that the feature was intended only for air and sea units).

In general, I think it is intuitive the most if positive bonuses are given upon exiting and negative ones are gives upon entering. I think this is pretty obvious. Of course, what is intuitive the most is not necessarily realistic the most, and if the feature would be settable both as positive and negative, it wouldn't matter, at the end, for the user, if the default is giving or taking away.

[redrum]

So I've decided to give this a go...

My thought is focus on territory effects first and have the movement costs be modifiers (additive) with base movement per territory always being 1. Movement modifier can be any positive/negative decimal value. While I don't really think decimal values will be that useful for territory effects as you'll usually have positive integer modifiers but for future proofing if movementCostModifiers is added to things like units then roads/rails/etc could do something like movementCostModifier=-0.5 so that a unit only spends 0.5 per territory (could do this with territory effects as well but then roads/rails would be hard coded).

Example 1 - Mountains

<attachment name="territoryEffectAttachment" attachTo="mountain" javaClass="TerritoryEffectAttachment" type="territoryEffect">
        <option name="movementCostModifier" value="artillery" count="1.5"/>
	<option name="movementCostModifier" value="tank:heavyTank" count="2"/>
</attachment>

So this would mean the following:

• artillery takes 2.5 movement to enter mountains
• tank/heavyTank takes 3 movement to enter mountains
• infantry (no modifier) takes 1 movement (normal) to enter mountains

Example 2 - Forest

<attachment name="territoryEffectAttachment" attachTo="forest" javaClass="TerritoryEffectAttachment" type="territoryEffect">
	<option name="movementCostModifier" value="tank:heavyTank" count="1"/>
</attachment>

So this would mean the following:

• artillery (no modifier) takes 1 movement (normal) to enter forest
• tank/heavyTank takes 2 movement to enter forest
• infantry (no modifier) takes 1 movement (normal) to enter forest

Example 3 - Mountain/Forest

<attachment name="territoryEffectAttachment" attachTo="mountain" javaClass="TerritoryEffectAttachment" type="territoryEffect">
        <option name="movementCostModifier" value="artillery" count="1.5"/>
	<option name="movementCostModifier" value="tank:heavyTank" count="2"/>
</attachment>
<attachment name="territoryEffectAttachment" attachTo="forest" javaClass="TerritoryEffectAttachment" type="territoryEffect">
	<option name="movementCostModifier" value="tank:heavyTank" count="1"/>
</attachment>

So this would mean the following:

• artillery takes 2.5 movement to enter mountain/forest
• tank/heavyTank takes 4 (1 base + 2 + 1) movement to enter mountain/forest
• infantry (no modifier) takes 1 movement (normal) to enter mountain/forest

[LaFayette]

@redrum Why does the javaclass need to be specified? Is that not implied already by the attachment name? AFAIK most of the existing javaclass labels are legacy, we map to the javaclass on the backend by name.

Is 'type' also needed? Is that not also implied already by the attachment name? Thinking more about this, should we really re-use the 'attachment' tag?

eg:

<territoryEffects>
    <territoryEffect terrain="Mountain">
              <movementCostModifier unit="artillery" count="1.5"/>
               :
    </territoryEffect>
 </territoryeffects> 

Looking at the above, we may want to call the feature "terrainEffects" instead of territory effects, as territory implies something more like SZ51 rather than 'desert' or 'forest'.

Second, perhaps as a 2.0 feature, I also wonder if we should allow for 'unit-classes' so we would not need to specify every individual unit. Let's say for example there are 5 air units, instead of listing all four, would maybe something like the following be easier to work with:

<unitClasses>
     <unitClass name="airUnit">
              <unit>Fighter</unit>
               <unit>Bomber</unit>
                :
     </unitClass>
</unitClasses>

[LaFayette]

Another thought, perhaps it would be more cohesive for territory movement effects to be defined with the images and grouped together in one home.

XML specs with ID references are a bit notorious, eg:

<tag id="name" />
<attribute name="modifier" attachTo="name" />

vs:

<tag id="name">
    <attribute name="modifier"/>
</tag>

or:

<territoryEffects>
   <territoryEffect name="mountain">
        <movementModifier unit="infantry" count="2" />
   </territoryEffect>
</territoryEffect>

If at the end of the day the nested tags could still be represented as 'Delegates' on the java side, that is a detail the code can hide and apply the transformation while map parsing. It does seem though as having a proper "Terrain" object be represented and part of the map data would be very clean. Natural attributes of the terrain or territory object would be its effects, name, movement penalties, and image.

[LaFayette]

Last 2 cents hopefully, "delegate" and its corresponding "attachment" has I think perhaps been extended beyond its original intent. The 'original' delegates seemed to have been turn phases. Things like "PurchaseDelegate", "TechnologyDelegate", "CombatDelegate". Then to enhance these we have "attachments".

Said another way, when you have a really nice hammer, everything starts to look like a nail.

IMO stronger nesting should make for XML that is more cohesive, easier to read and understand. It also seems like some XML abuse was done when the XML started to directly reference which java classes rather than leaving it up to the code to decide. We've introduced the infrastructure so that the code can select the implementation based on tag. I strongly think we should stick to that design and not introduce direct coupling between XML and code.

One update I've been toying around is to "fix" the XML schema structure so that properties are truly nested and not have references be scattered around. For example, define players and their units and PU type all in one block rather than have it be multiple. Prototypes of this have been pretty nice, but implementation and transition are prohibitive. Given these transition costs, the XML tag structure and their names are likely to live forever, once defined they would be prohibitive to change. I think we should evaluate carefully how we structure the new XML markup.

[Cernel]

@redrum A question:

If I set it at -1, the unit will make the movement for free, and if I set it below that, the units will have its remaining movement increased for entering that territory? Such bonuses are cumulative, so that, for example, if I have two bordering territories with a "movementCostModifier" any numbers lower than -1 (for example, -2), I can keep moving my unit back and forth between the two territories, increasing its remaining movement at any move, potentially charging it with an infinite quantity of remaining movement.

I have some ideas and proposals, but first I want to be sure I'm understanding all correctly.

Side note, I personally think that it would be more intuitive if this would set the movement cost directly, default being 1 (instead of base 1 and default 0), but I don't really care about this. It's just on the mapmaker (not sure if there will be any tooltips or such).

[wc_sumpton]

@LaFayette we already have the '<variableList>', so for the <unitClass>;

<variableList>
   <variable name="airUnits">
      <element name="Fighter"/>
      <element name="Bomber"/>
      :
   </variable>
   :
</variableList>

This would do just what you are describing.

Cheers...

[wc_sumpton]

I think having the 'movementModifier' included with the 'territoryEffects' makes the most sense, since what is being talked about is modifying the unit by the territory.

Cheers...