Terrain Effects for movement

Hepps

Just wanted to table an idea for a new terrain effect...

	    <option name="movementEffects" value="armour" count="-1"/>

This would really help with maps that use terrain effects and create a much needed addition to the "noBlitz" effect.

Implementation

Adds new XML TerritoryEffectAttachment option "movementCostModifier" which allows map makers to set movement costs (positive or negative adjustment, the default cost for a territory is 1 and this would add/subtract from that)
Adds new XML property "Enter Territories With Higher Movement Costs Then Remaining Moves"
Update all routing logic to handle movement costs and refactor code base to handle them properly

XML

        <attachment name="territoryEffectAttachment" attachTo="Mountain" javaClass="TerritoryEffectAttachment" type="territoryEffect">
            <option name="movementCostModifier" value="germanStrategicBomber" count="5"/>
        </attachment>

        <property name="Enter Territories With Higher Movement Costs Then Remaining Moves" value="true" editable="false">
            <boolean/>
        </property>

Shows route finding avoiding high cost territory

Showing that a strat bomber that has 6 movement can't enter Austria as it would cost: 1 first move + 6 (1 base + 5 mountain) = 7.

More examples
https://forums.triplea-game.org/topic/1183/terrain-effects-for-movement/49
https://forums.triplea-game.org/topic/1183/terrain-effects-for-movement/56
https://forums.triplea-game.org/topic/1183/terrain-effects-for-movement/60
https://forums.triplea-game.org/topic/1183/terrain-effects-for-movement/61
https://forums.triplea-game.org/topic/1183/terrain-effects-for-movement/63

PR: https://github.com/triplea-game/triplea/pull/5234
POS2 PR: https://github.com/triplea-maps/the_pact_of_steel/pull/38

ron-murhammer created this issue in triplea-game/triplea

closed Add territory effect movement cost #5234

ron-murhammer created this issue in triplea-maps/the_pact_of_steel

closed Add territory effect movement costs #38

Frostion

I would really like this also. I made a request much like it at Github. It could really open up for some possibilities.
https://github.com/triplea-game/triplea/issues/4226

FrostionAAA created this issue in triplea-game/triplea

closed territoryEffectAttachment – /+ movement effect? #4226

redrum

Its a good feature request that has come up a few times in the past. Its not as easy as it appears due to having to then update route finding which gets more complex.

Most likely I'd look to implement it as a movementCost adjustment system and you could argue to apply it in a number of different ways:

Territory effect option - mountains, forest, jungle, hills, etc costing more movement points
Unit option - roads, rails, barriers, trenches, etc costing less or more movement points
Territory option - could configure any territory with a certain movement cost
Connection option - could configure any connection between territories with a certain movement cost
Canal option - could enhance canals to not just block movement but also make connections cost more or less so something like owning both territories with a river in between allows you to avoid the extra movement cost

I think probably the first 2 would be the easiest to use for map makers though not as flexible as say connection/canal as using it there could allow things like rivers (connection between 2 territories).

There are also a few edge cases that I mention in @Frostion github request around things like if I have 1 movement left and a territory takes 2 movement then can I move there?

Cernel

@Frostion That feature request is given open to me here, visually, while it is actually closed. Is this a forum bug, or is that supposed to be something static, created when the reference is firstly made?

Hepps

@redrum All very good points. Glad to see some thought has already been focused on this topic. I suppose I should pay more attention to Git Messy.

I do really like what you suggested in 5 about the canal option as it appears it would provide the needed mechanic to account for the obvious terrain situations, while at the same time enabling so many more possibilities.

The edge cases seem less critical since it would be covered by the rule system. Thus it would be governed much the same was "noBlitz" is implemented currently. Not enough movement... "No soup for YOU!" You could potentially move further in a direction that is open and has no obstacles or you are stuck where you are.

Cernel

Some considerations:

I believe this would be better made as a connection attachment, in that you can assign movement point costs (default 1) to specific connections, for specific units.

For the matter of increasing movement, I would keep it separate from movement costs, and have it done with units, similarly to the current way movement bonus is given, but related to making the whole movement in zones with such units, instead of only the starting zone.

For partial movement, I think here it would be good having a property to set the behaviour, as I can see good arguments for both cases. Default, I would say you can move if you have 1 or more left, and the connection uses more than you have, as I see better arguments and cases for this behaviour, and you can simply use canals if you want some units not to be able to move through some connections at all. For a strategic game, entering a territory mostly means that you are stepping inside it, attacking the units in front of you, as armies would be one next to the other, with a small no-mans land in between; it doesn't mean that you are moving through the whole of it.

Frostion

I really dread this being implemented as connection option. This would mean editing the code into sometimes thousands of connections! and sometimes petty much code/info would be listed/copied thousands of times.

It seems so much more sleek to have it as a territory effect description, wherein the territory effect, besides describing attack and defence bonuses also described how units are impaired by how much when inside this type of territory.

Like a "Tank" gets 1 unused movement removed when inside a territory with this effect. Meaning if Tank has 3 moves, moves 1 move from normal territory into this type (let's say it is "Swamp") it now only has 1 move left.

Next turn, when the player clicks and wants to move the Tank, the Tank starts out showing that it has just 2 out of its 3 moves unused as the territory (game engine) has automatically used up one of its moves (without using fuel I guess).

If the territory effect was positive, like "Plains" increased "Cavalry" from 2 move to 3 move, the Cavalry unit could like start out in a normal territory, use one move into "Plains", get a one and only bonus of +1 move, upon arrival now have two free moves left. Here, in this system a unit could only receive bonus one time from one type of effect, so that the unit could not have unlimited moves when moving around on "Plains" type territory.

LoL, I will not postulate that this system is well thought out But it could maybe work.

Frostion

If a connection implementation is the way to go, I propose that the movement info pop-up, the one showing unused moves/total moves/fuel, be expanded to show a shot connetion info that described what was going on.

Like if a 2 move Tank moved into "Mountains" the info below movement and fuel consumption would say:
"Mountains: -1 Move for Tank"
... of course only when a Tank is moving or is in the group of units that are moving.

Cernel

@Frostion If a territory effects implementation is the way to go, I'd have two Boolean properties for this matter:

One that sets if the movement cost (defined for the territory (default 1)) is charged for the territory you are going into or the territory you are going out of.
One that sets if you can always move if you have 1 or more movement left or only if you have at least as much as the movement cost.

I could list a bunch of reasons and user cases for either behaviours.

The territory vs connection matter is mostly dependant on the scope of the map. Since TripleA is traditionally a grand strategic game, things like rivers or mountains would be not territories, but rather something like the border between "Northern Italy" and "Austria", while Northern Italy itself is a plain. Still, I've no idea how you would represent the rivers this way. Even if the map is so extremely detailed as to represent rivers with territories, like in the case of Civil War, I would think such territories would still be sea zones, and armies moving over them without shipping involved would still not actually step in them, thus it would be still a connection matter, if we want to slow down units that are fording rivers, for cases like river fording or walking on the ice from Finland to Sweden.

redrum

My initial thought is the first implementation would focus on adding movement cost for territory effects as this is probably the most useful and also minimizes amount of XML. It would be charged upon entering the territory and default to 1 (this is how most other games handle it). And that you'd be allowed to enter any territory as long as you have 1 move remaining (this I think gives more flexibility for movement as otherwise if you have units that only have say 1 move and you have territories with movement cost >1 then they could never enter.

Eventually, I'd like to expand it to allow for different movement cost for connections to allow for simulating things like rivers and would consider adding some additional properties like some of the ones @Cernel mentions.

Here would be an example for a mountain effect for tanks which costs 2 movement when entered:

<attachment name="territoryEffectAttachment" attachTo="mountain" javaClass="games.strategy.triplea.attachments.TerritoryEffectAttachment" type="territoryEffect">
	<option name="movementCost" value="tank" count="2"/>
</attachment>

Cernel

@redrum I think for most normal cases, as well as for representing cities akin to Red Sun Over China, the movement would be better charged upon exiting, but there is an interesting case in which movement upon entering would allow for a better representation of small islands.

In a case like this one:

(green arrows are allowed cost 1 movements, red arrows are impossible cost 1 movements)

You could make a territory effect "small island" with "movementCost" = 0, and assign it to all islands touching no other zone but a single sea zone (in this case, Borneo, East Indies, etc.). This way, you could make a 2 movement from East Indies to Borneo (as moving from 32 sea zone to Borneo would cost 0), while still charging 1 movement cost for moving out of Borneo.

I believe the above would considerably enhance the representation of small islands as territories completely inside 1 sea zone, as if you can go in the sea zone that completely contains the island, it makes sense going in the island itself takes no extra movement, while going from the island to any non adjacent sea zones will still take at least 2 movements. I might be using such possibility.

redrum

@Cernel Well, I think there are arguments on both sides on charging on entering or exiting but the majority of TBS games charge on entering (Civ series does that and is one of the most popular TBS games of all time and many games are based on that).

Your case is interesting but would be a further enhancement since loading/unloading transports doesn't care about movement points. The actions of loading and unloading take up the unit's turn and ignore the amount of movement points they have (ex. you can't load/unload a 4 movement unit multiple times).

Cernel

@redrum No, actually, as I said, the case I've shown would be actually supported under your formulation, as long as you can assign movementCost 0:

My initial thought is the first implementation would focus on adding movement cost for territory effects as this is probably the most useful and also minimizes amount of XML. It would be charged upon entering the territory and default to 1 (this is how most other games handle it).

The case would be, for example:
<option name="movementCost" value="fighter" count="0"/>

the territory effect assigned to Borneo.

In this case, you could move a fighter for free from 32 Sea Zone to Borneo, hence you can go from East Indies to Borneo at the cost of 2 movement points, yet not being able to go directly from Borneo to 30 Sea Zone or from East Indies to 32 Sea Zone.

Yes, that would not change anything for units offloading from ships in 32 Sea Zone to Borneo, instead.

Or do you mean it would not work?

redrum

@Cernel Oh I see. I didn't realize you were talking about air units. Yes, in theory, what you describe could work then. I do need to further consider allowing 0 movementCost but haven't decided against it for any reason yet.

Frostion

@redrum
Instead of calling the property "MovementCost" 1 could it not be named a bit different. I don't think that the movementCost definition is self explanatory. Also, maybe the concept could be expanded or made ready to also allow movement modifiers upon exit from territory. Maybe:

"EntryMovementCostModifier" "1" If it would cost an extra move to move into. And "-1" if it was free of cost to move into. Who knows, maybe units/maps/mapmakers would have reasons to let a unit pass into specific territories for free or less cost.

"ExitMovementModifier" "1" or "-1" with the same logic as above, if this was also implemented.

Also, what are your thoughts about fuel consumption when affected? Would it make sense to just make fuel follow the moves, meaning if it cost extra move then it cost extra fuel. Less move would mean less fuel. Free move would be no fuel?

Hepps

I had originally posted this with the intention that if we implemented this as a terrain effect it would be consistent with how it already works... having the movement cost (or limitation) imposed up-front when (attempting) entering the territory in question with a negative effect.

As has been pointed out the issue with having an exit cost is if you have units with a single movement point... then you run the risk of having territories that units can never escape from. This of course can be dealt with by making a much more complex movement system where units start with higher base movement values... and where terrain and infrastructure affects their mobility to a lesser degree (incrementally)...but my suggestion was really (or at least initially) meant to address units with multiple movement values in a way that is simple and in keeping with the existing game structure.

This is not to say I do not value the dialog... examining and developing a workable model for a system with lots of flexibility is an awesome goal.

Schulz

Armours have already minimal roles in most of big maps and it would even worsened inf spawn issue. Because the main problem is better stats are no better than cheap cannan fodders in most cases since fighters are already provide enormous ground support also unlike tanks they can't be destroyed regularly.

I would accept it only if slow units also get some penalties in bad terrains.

CrazyG

I did discover a strange "work around" for this. Let's say you want Germany to connect to Switzerland, but you want entering Switzerland to take 2 movement.

What you can do is create a dummy territory, call it Dummy 1. It has center data, but just a 1 pixel polygon file.

Germany connects to Dummy 1, Dummy 1 connects to Switzerland. Germany DOES NOT connect to Switzerland. A human player can't actually enter Dummy 1. Now when Germany moves into Switzerland, he needs two movement.

There are a ton of issues here though. AI will be able to end movement in Dummy 1, units with only 1 movement can never enter Switzerland, and you are forced to have all unit types face the 2 movement penalty.

On the idea being developed, ideally there would be a property we could set as true false. Something like "A Unit needs the full movement amount to enter rough terrain".
So it its true, a tank with 1 movement left cannot enter a forest that needs 2 movement.
If its false, a tank with 1 movement could enter a mountain that requires 200 movement (like in Civilization 5).

redrum

@CrazyG Yeah, RSOC essentially did that for trains. Its a pretty big hack and causes lots of side effects like you mention. It also requires a lot of work to do it at a large scale.

Frostion

@Hepps If a unit on a map could not exit a territory, it can only be because the mapmaker intended this specific situation for this specific type of unit, maybe some kind of special unit, special situation or the unit is a control/settings unit of some sort that should be able to move into a specific spot but not out. I can't see the problem here.
If if was possible to make a system that also could prevent units from leaving or inhibit movement, I would really like this, and it could be used in future maps.
Edit: And wouldn't an exit movement also be "upfront" payment?