Terrain Effects for movement

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

[redrum]

@LaFayette While I think we could look at the overall usage of attachments and how the XML is structured that's probably better as a separate thread as territoryEffectAttachments already exist and I'm just looking to add a new option to them here.

As @wc_sumpton points out, I recently added variables in order to specify lists of various XML elements to avoid having to copy/paste them and manage updating them in multiple places.

So delegates and attachments are kind of separate things. There are attachments like unitAttachment and supportAttachment for example that aren't directly tied to any specific delegate. I believe the reason for attachments is because the XML is parsed just a single time through so it defines most of the various elements first then creates the attachments to them so it can validate different attachment options to ensure they reference valid elements. This could potentially be changed and parsing updated but would be a significant update.

I think it would be best to take some of these points to a separate thread.

@Cernel I haven't fully decided if I'm going to limit negative modifiers to never allow it to be less than or equal to 0 movement cost. But my general thought is to allow any values and map makers will just need to ensure they don't do ridiculous things like have 2 adjacent territories that both give movement. I decided to make it a modifier rather than set it directly so you could have multiple territory effects combine together in a more logical way. For example, if I have forest cost +1 and mountain cost +1 if I had them define "2" then combining would seem to be "4" instead of "3". Its also easier as if in the future you combine territory effects and units then having them all as modifiers makes more sense then setting the cost directly.

[Cernel]

@redrum said in Terrain Effects for movement:

@Cernel I haven't fully decided if I'm going to limit negative modifiers to never allow it to be less than or equal to 0 movement cost. But my general thought is to allow any values and map makers will just need to ensure they don't do ridiculous things like have 2 adjacent territories that both give movement.

I certainly agree with this. However, I think it may be worth adding a little tweak specifically for movement increase: a cap.

The case of decreasing movement is already fully handled by the fact that the unit can never go below 0 remaining movement (the point at which it stops).

The issue with increasing movement is that the unit doesn't have a maximum movement it can hit. This is true also for giving movement at start phase, of course, but it is not an issue there.

My suggestion is the movement increase from territory effects be capped to the basic movement of the unit (this would need a line in pos2, of course), and if the unit already has a bigger remaining movement than its basis, that remains the same. Practically, differently from units giving movement, territory effects would be only able to restore movement abilities, never to increase them.

Meaning, for example, if we have a territory with modifier -3 (gives +2 movement for entering):

• If a unit with 1 movement left and 4 basic movement enters it, the remaining movement is increased to 3.
• If a unit with 3 movement left and 4 basic movement enters it, the remaining movement is increased to 4 (not to 5).
• If a unit with 4 movement left and 4 basic movement enters it, the remaining movement remains 4 (instead of increasing to 6).
• If a unit with 5 movement left and 4 basic movement (the unit was boosted by something like an airport) enters it, the remaining movement remains 5 (instead of increasing to 7).

What I have in mind, that this feature may support, is the air ferry routes:
https://en.wikipedia.org/wiki/North_Atlantic_air_ferry_route_in_World_War_II#/media/File:AirFerryRoutesOfWWII.png

A realism issue of TripleA games is that air movement is a single fly, that it is usual something that takes a few hours of real time, while turns are easily over 1 month. For this reason, ferrying air units (something that you should be able to unlimitedly do across all over the world, if 1 turn is 1 month or more) cannot be represented. Beside making a map so extrmely detailed that every turn is representing 1 day (which would imply over 10,000 land territories and a playtime of hundreds of rounds), I see this may be achieved by having all eligible land territories giving aircrafts movement upon entering, but only as long as the remaining movement cannot go over a maximum (that would be equal to the distance the aircraft can manage to achieve in a single fly, typically flying over sea zones).

I decided to make it a modifier rather than set it directly so you could have multiple territory effects combine together in a more logical way. For example, if I have forest cost +1 and mountain cost +1 if I had them define "2" then combining would seem to be "4" instead of "3". Its also easier as if in the future you combine territory effects and units then having them all as modifiers makes more sense then setting the cost directly.

Albeit this would be inconsistent with combat bonuses, it may be advisable setting it at the highest amongst territory effects, rather than summing them up. If you think at the matter in term of them being choke points, only the smallest one should matter. Question for example would be if I have a forested mountain, should the movement be as slow as the worst between mountain and forest, or summing them up? Or if I'm representing swamps by having both forests and marshes in those territories (instead of having a swamp territory effect), should the swamp being as bad as the worst between a forest and a marsh or the sum of both (likely both increasing movement consumption over the default, if the default is representing open plains). I'm not really lobbying here, but probably the mapmakers more interested in multiple territory effects should consider the matter.

[redrum]

@Cernel Its an interesting idea. Though my general feel for trying to implement something like that would actually be using the units give movement and adding a requirement for getting that movement on conditions in the destination. So you essentially have "airports" which give movement but only if moving to another airport (this is also the same case for TWW where AA guns are only supposed to get +1 movement when loading onto transports).

[Frostion]

I would be very disappointed if the movement bonus from territory effects be capped according to the basic movement of the unit. Then it would not be possible to have movement boosting territories like "roads" giving bonus on a mostly roadless map. Or "flat plains" giving cavalry bonus in a mixed territory map. "Hyperlanes" or "Jump Gate" territories giving movement bonus to spacecraft etc. Territories should be able to boost movement, just like naval base and air base.

[Cernel]

@Frostion No problem, I'm not strong on that proposal. I just wonder if you either:
1- realize that "movement boosting territories like "roads"", if we are talking about territories that increase the remaining movement of units entering them, would need never to exist in nearby territories (that doesn't make any sense for roads), or they would give units virtually infinite movement, for going outside roads as well.
2- are rather thinking to cases like -0.5 bonuses, that would be not impacted at all by any max basic movement cap, as they would still be reducing remaining movement, albeit slowly so.

Since roads would be most likely territories one next to the others, I think you are being confused, and are actually thinking about something like point 2, that is not itself impacted by the presence or absence of any basic movement caps.

@redrum Territory effects are certainly not the best way for handling ferry routes, but this would be an additional feature request, obviously. Of course, normal airports giving +1 movements don't really make any sense (shocker). The movement of an aircraft is just given by his own characteristics at full fuel (comprising eventually detachable tanks) and airports do nothing to increase or decrease it. They are just needed to take off and land safely, but back in ww2 aircrafts needed really little in that way (whatever dry strip of plain land works), unless you are trying to build one in Greenland.

[Cernel]

@redrum On this matter, a question may be if movement 0 (both basic or remaining) units should be able to move into a territory requiring 0 movement cost or giving any. If yes, this may support loading things like basic movement 0 materials into transports, as you could just give a territory effects giving -1 to materials in all "sea" territories (or the ones you want).

[Cernel]

@Cernel Tho this would be just another workaround. Movement 0 units should just be always allowed to load onto ships, in my opinion, as long as they didn't move yet (and, of course, have an affordable transport cost assigned). This should be really something basic, but I'm going off topic.

[redrum]

@Frostion I don't plan to put any caps at this point. That being said here are some of my thoughts on some of the things you mention:

Roads/Flat Plains (I'd use a negative movementCostModifier so it costs only fractions of a move point)

<attachment name="territoryEffectAttachment" attachTo="road" javaClass="TerritoryEffectAttachment" type="territoryEffect">
        <option name="movementCostModifier" value="infantry:artillery:tank" count="-0.5"/>
</attachment>
<attachment name="territoryEffectAttachment" attachTo="flatPlains" javaClass="TerritoryEffectAttachment" type="territoryEffect">
        <option name="movementCostModifier" value="cavalry" count="-0.5"/>
</attachment>

So say an infantry could then move 2 territories with roads instead of the normal 1 since it would then cost 0.5 per territory.

Hyperlanes/Jump Gate (I'd make them probably just connect together and have 0 movement cost)

<attachment name="territoryEffectAttachment" attachTo="hyperlanes" javaClass="TerritoryEffectAttachment" type="territoryEffect">   
            <option name="movementCostModifier" value="spacecraft" count="-1"/>    
</attachment>

@Cernel Yeah, the having 0 movement left and still moving to a territory with 0 cost or that gives movement is an interesting point that I'll have to think about. I think ideally they can but I'll have to see how easy/difficult that is to achieve.

[Cernel]

@redrum said in Terrain Effects for movement:

@Frostion I don't plan to put any caps at this point.

Well, if you'll ever reconsider this, an easily agreeable cap (nobody can rationally be against, I suppose) is to have a cap equal to the max basic movement of the unit plus the opposite of the modifier minus 1.

So, for example, in my previous example of a unit having base movement 4 and the territory effect being -3, the cap would be at 6 (=4-(-3)-1). This would just assure from the bouncing to infinite movement practice (as likely eventually some mapmaker will overlook it, and make a map having this possibility).

Not trying to keep fighting a decided item, but I just hope also @Frostion and everyone now realize that, with movement cost paid/received upon entering, "Hyperlanes" or "Jump Gate" would make no sense, if they would be stuff that allows you to generally move faster to anywhere else, as you would get the movement if you enter that territory, but not if you start your turn in that territory (even if you can go out and in, to get the bonus, that still means that starting right where the Hype is equals being farther away from using it than starting in a nearby territory). This is a clear example of why charging upon exiting is overall more realistic, albeit, as I said, I agree that charging upon entering is more intuitive, at least when the effect reduces your movement, as also demonstrated by the fact that everyone else but me assumes that is the best practice.

[wc_sumpton]

@redrum, @Cernel I know this is still being discussed, what about the remainder movement. If armor movement is set to 2 and:

<attachment name="territoryEffectAttachment" attachTo="mountain" javaClass="TerritoryEffectAttachment" type="territoryEffect">   
            <option name="movementCostModifier" value="armor" count="2"/>    
</attachment>

Then the armor can only enter a mountain territory from an adjacent territory. But if the count is set at a range:

<attachment name="territoryEffectAttachment" attachTo="mountain" javaClass="TerritoryEffectAttachment" type="territoryEffect">   
            <option name="movementCostModifier" value="armor" count="2-1"/>    
</attachment>

Where '2' is the normal entry cost but if the armor still has 1 movement left it could still enter the mountain territory.

Cheers...

[Cernel]

@wc_sumpton But, then, the armour would be completely unaffected by the mountains. It could enter the mountains from 2 territories afar and the next turn it could leave them with its full 2 movement. Is this what you want? Not opposing your suggestion, just wondering.