Strategic movement phase

[Rolf Larsson]

The new trains/unit required to move into feature is great, but it could be enhanced. With one setting like "Consumes unit by moving into" Value=StrategicMovePoint Count=1
The idea is simple, an infrastructure like a rail/highway/road creates X StrategicMovePoints as units in a territory at the end of the turn, a movement phase follows and all units, which have the setting above, can move, but consume that special unit, which resets their movepoints and allow these units to move on, when all StrategicMovePoints are beeing consumed, that territory will not allow any more movement... reduced production for damaged units would be good I guess. Train units would not be necessary anymore, and some bottleneck territories would need more producing rails maybe, could also be nice for ancient maps with roads/cubblestone roads, rivers etc.

[redrum]

@rolf-larsson Wouldn't that potentially allow units have some what unlimited movement? For example, if I had a rail from France to Korea then I could move all the way across? In general, "resetting movement" is probably not the best approach for something like this as it makes path finding very difficult and only limits the number of units moved through not total moves for each unit. I think you'd be better off having something like "StrategicMovePoints" reduce movement points consumed to say "1/4" instead of the usual "1". So a unit could move say 4 tiles on rails and maybe each rail produces "3 StrategicMovePoints" so allows 3 units to move through each turn.

[Hepps]

@redrum An interesting conceptual idea. Have to digest both of your concepts.

[Hepps]

@rolf-larsson After thinking on this I can see 1 main issue with the proposal...

As @redrum points out a system like this that puts the movement as the capability of the static unit (ie. the road or rail) would then mean that any unit capable of doing strategic movement would then have a virtual unlimited movement capability so long as the required unit is present in the adjoining territory. While this would create and achieve the goal of putting a limit to the number of times a territory could provide strategic movement... it would create a severely exploitable mechanic. (After all... while a road should extend a ground units range.... it really shouldn't give it an unlimited range).

What this ultimately means is that an idea such as this would then also require the unit that is actually moving (ie. the Infantry) to have its own "Strategic Movement" value. Furthermore, if you were going to have different types of "strategic movement" then the unit attachment would have to specify what capabilities each unit type has on each different type of infrastructure.

<attachment name="unitAttachment" attachTo="americanInfantry" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="movement" value="1"/>
<option name="strategicMovement" value="road:3"/>
<option name="strategicMovement" value="Rail:8"/>
<option name="attack" value="2"/>
<option name="defense" value="3"/>
<option name="transportCost" value="2"/>
<option name="isInfantry" value="true"/>
<option name="requiresUnits" value="americanBarracks"/>
<option name="canInvadeOnlyFrom" value="none"/>
</attachment>

Pretty sure this example would cover of the requirements to make a system like this work.

Then of course you would still need the infrastructure unit itself....

<attachment name="unitAttachment" attachTo="Rail" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
  <option name="isInfrastructure" value="true"/>
  <option name="canBeDamaged" value="true"/>
  <option name="maxDamage" value="6"/>
  <option name="maxOperationalDamage" value="2"/>
  <option name="movement" value="0"/>
  <option name="attack" value="0"/>
  <option name="defense" value="0"/>
  <option name="isConstruction" value="true"/>
  <option name="constructionType" value="rProduction"/>
  <option name="constructionsPerTerrPerTypePerTurn" value="1"/>
  <option name="maxConstructionsPerTypePerTerr" value="6"/>
  <option name="canDieFromReachingMaxDamage" value="true"/>
  ***<option name="canProduceXUnits" value="3"/>
  <option name="createsUnitsList" value="strategicmovementRail"/>***

would still need more examination.... but I think I hit most of it.

Actually I did not include the consumption part of the equation... which would have to be included as well.

[redrum]

@hepps Yeah, I think you are going in the right direction for something like this. Though a couple of points:

1. I'd probably not have a separate phase and just have this happen during non-combat move.
2. I'd probably put most of the unit attributes on the rail/road vs the unit moving.
3. For limiting number of units that can use the rail/road per turn, you'd need to add an attribute to the rail/road like maxEnablesUnitsToMove.

On another note, if you like the current train system (land transport) but wanted to base number of trains that can move on the number of rails in each territory (how advanced the rail infrastructure is), you could do something like #3 above as well.

This type of conversation also leads to the idea of having "movementCost" for various terrain types as well.

[Hepps]

@redrum Yes some of the terminology I used was not well thought out.

But yes... the need for it's own phase seems rather unnecessary.

[Hepps]

@redrum Yes adding 3 would be a good way to incorporate this.... since it could be attached independently to the existing design.

[prastle]

@hepps JESUS! and I wanted was chu chus ...