Rotating Front Lines

[DHRedge]

I read in the rules that there is better fatigue recovery, and supply refit if you are not on a front line in attrition situation.

You mentioned the 'rotating of units' micromanaging, and I was thinking the same thing. If I have units on front line especially for defense, rotating them from that front line would be more effective, however difficult with the unit counts in the game, and many mouse clicks make that less practical.

However, it makes complete sense, since front line units don't recover and rest as well. So getting rid of the effect would be a bad idea

So how is this for an idea.

What is needed for units, and more importantly HQs is 'set rest factor'. For each unit, or set for all units in an HQ, one more entry should be shown by supply percents on the unit, and be settable on a unit or for all units in a HQ.

That factor would be how many, as a percent' of the units are 'on the front line' and how many are 5-10 miles from the front line. The mode would only have an effect when next to enemy units during a combat turn, and would be the 'percent in 24/7 defensive combat for a unit'

For attrition, those units in rest mode would not be effected by combat, nor add there CV to defense on the front line.
Although if attacked, or air bombed, they would be at some lesser combat readiness(-50%) for first attack against that unit in the turn.


That way I could put a 24-15 Infantry on a line next to 2-3 and 2-1 soviet units, and set it where 50% the units are in rest mode for the other players attack, preparing for the next attack a week or two away.
The 24-15 would be a 12 for attrition and combat supply purposes.
It would be a 18 when defending against a first attack (12 active + half of 12) for first attack against the unit
And if only attrition effects against unit occurred(front line effects), then %50 of the units would get the 'non front line' bonus of refit and rest.

The start of the next turn the unit would have a -2MP or some percent of MP needed to be expended to bring it to readiness, like how On Train button works, or start of next turn, the unit could start with 2 less MP.

If there was another percent that could be decreased to values set to 33%, 50%, 66%, 80%, 100% by clicking on the HQ, or on some button on each unit, it would be both more realistic, and remove much of the micro managing.

Basically there needs to be a 'reserved and resting' percent, where as is usually the case, some percent of the unit is rotated back to rear of the front every few days, or an entire HQ could set there unit to stand down readiness for an increase to fatigue and supply repair, and only be at some percent of strength, or could be at full strength with all the men in the units on the lines.

It is how the situation actually is in such combat. In such infantry lines before a big push where 100% of the units will be used, units are given extra hot meals, and rest up, while they hold a static line on their front during the days before such an attack.

[morvael]

Good idea, but it would not play nice with which units take losses and which get credit for wins and losses on the frontline. This would work in a game with higher abstraction level.

[DHRedge]

ORIGINAL: morvael

Good idea, but it would not play nice with which units take losses and which get credit for wins and losses on the frontline. This would work in a game with higher abstraction level.

Why? Because you would stack three units on front line, and set them all to 33%, so that every turn you would not have to rotate all the units on the line for optimal recovery of fatigue?

The problem is to maintain a front line with German, you have to put almost all units on the front line, and all of those units suffer fatigue from attrition effects, if you have 24 CV facing 1,2 CV factors, the fatigue for the 24 should be less then for the 1 and 2, since holding a line such as that would be much easier. The abstraction is not allowing setting part of the unit to rest(if there is any code that computes ratio when determining fatigue and front line supply usage)

It is similar to 'reserve' but allows a percent of the unit to be put in rest and reserve, instead of everything being calculated based on the entire units. For CV and attrition non 'rest' percent would be used mostly, for fatigue calculations, the penalty of being on front line would apply to those units. If they win or lose it is the same thing.

I don't see where it would effect who takes losses, since the calculations would be the same since all the units are still in the same hex, the only difference is some of the units put less of there CV into the battle, and get less fatigue from attrition front line effects.

How it is determined 'who gets the win' is some formula, and for HQ units, how would that change? You either get the win or not, and the unit regardless of lower CV value from such a function, if it gets the win, is the same as the current situation, it still is in the same hex, and still attached to same HQ

[morvael]

With German you can split the unit and put one regiment in the rear. For Soviets you can rotate whole divisions. I didn't understood your idea fully, I thought that some units in the rear would result in overall army-level "rest and refit" percentage to go up, being evenly applied to units on the front and rear. Anyway, it is impossible to add such rule at this time, because there would be too many points in the code to review whether they should be affected by lower number of "active" elements and to change them (there would be dozens of such places, possibly even hundreds). It isn't only the CV formula that should be affected.

[DHRedge]

I understand the difficulty in such a thing, it would be adding another set of criteria to many calculations.

Although the process of integration is in the area of the retrieval of unit size values, and could be put low in the retrieval system.

This system uses values of each unit, and then calculates values, so at the lowest level, the values of what is in a unit is always retrieved. x number of rifle squads as an example, then from there the combat strength, experience and fatigue, is retrieved and calculates some unit strength, then that is done for each type in the TOE.

If the 'percent active or in rest' was a function put at the level where the x value of each unit is retrieved, (like how many panzer tanks or rifle squads or mortar 81s are in the unit) then it could be put in one place.

In each function that needs to know a unit strength (presuming it is not precomputed number used more then once), send in a value that determines if it should get normal value, or value including 'rest percent set'. Then instead of returning 204 rifle companies, it would return 102 if only 50% were to be considered active(or any other formula).

It would be in many places in quantity, but not difficult in integration since it would be at the level of the retrieval of values. An added parameter would have to be added to functions that get values (so they know if they need to get full strength or active strength some number that says what 'value' should be returned), and each retrieval would then at that one place, calculate the number of units to return, if in some cases the value would be used in both cases, a separate retrieval would have to be added to code in that calculation function. So if you used rest value for attrition, then tried to use the same value for another calculation like damage or displacement from an attack, it would instead have to call the compute value again or retrieve a separate cached full value, if computed values are cached.

If values for all units are precomputed then used in many different potential calculations for a turn, there would have to be two(possibly three) cached computed values, although that is code dependent.

If for each combat all values are computed, then it is simply determining if the requesting function wants the active or full strength value returned.


The difficult part would be that AI routines would have to be written to deduce what percent of a unit should be set to rest as a conclusion of best advantage considering the factor of more rested vs the guess at where an attack might come from that turn. A difficult AI task, since it is intentionally weakening an area, to get a gain the next turn of more rested, where the AI has to compute a few moves ahead to see where an area may be attacked, while the area is a front line area.

Although a simple AI routine could put more units into rest if there fatigue is high that would emulate the current rotation of units from the rear that seems to be currently being used, but instead more units would be in the front.

As far as breaking units into three parts, and rotating them to the front, that cost CP points, loses some zones of control effects, and makes stacking an issue when moving to attack, and still would requier rotating units manually each turn. It can be done where you break down a unit, and rotate it for a turn or two, then put it back together for an attack, but that is many mouse clicks, and creates many other situations with stacking and cp.

Setting a unit at 66% active would do the same thing without all the mouse clicks and stacking problems. The usage of breaking down a unit should be more about increasing its area of influence to three hexes, more then about how many units in a combat are in rest or reserve.

anyways, it is only an idea, but I do agree that it would include code changes when retrieving TOE of a unit for different calculations.

[morvael]

It's easy to affect the CV formula, but there are others too, and all access the number of elements directly, like frontline or winter attrition. These should be altered as well, and I think it would be possible for many similar places not to recognized, and because of that ommited in the process. That's why it's a risky idea at this point. As a core mechanics of a new game it might be good.

[DHRedge]

ORIGINAL: morvael

It's easy to affect the CV formula, but there are others too, and all access the number of elements directly, like frontline or winter attrition. These should be altered as well, and I think it would be possible for many similar places not to recognized, and because of that ommited in the process. That's why it's a risky idea at this point. As a core mechanics of a new game it might be good.

I don't disagree, that it could propagate play balance issues, and also agree it would be something that would have to be considered more in the totality of design. Although if they are thinking about different ideas for the eventual total European Theater game, it would be something to consider. I figure, and they mentioned, they are considering a merging of the west and east theaters into a total game, that would also include the blitz, after they work through play balance of higher ship and air involvement that is more a part of the western theater.


As far as the implementation, it is really easy to make sure all areas consider the changes. If the code directly accesses members for calculations, in the unit area, add code change that wrapped around the process where functions return the values, and set the data members to private.

Then simply changing the function that is called to calculate unit strength based on individual items in the TOE, to have different returns based on what the new parameter sent in indicates. Honestly, add a parameter to the function, and it the compiler itself will show you every function that calls for info, heh. Then decide in each of those calls, what state should be used, and set a parameter to then be passed in to get the desired computation.

Process, add a parameter to the function that is used at the lowest level that gets unit strength from each item in the TOE,(rest active would be part of the unit modularization) then look at each calling function that fails to compile, (if the function flagged is used by multiple methods, add the parameter to that function also to propagate up the tree). Then you have the compiler giving you each line that retrieves the value, write down what each of those computation are for, then decide in some design meeting when resting/active or total strength should be used in each calling function(each calling function is a usage), then add the parameter that indicates what value to use to that calling function.

The propagation up the call tree needed to send different values back to computations is not difficult to do. Visualizing its effect on balance and AI, that would be a bit more difficult. And there are a few obscure situations that would have to be decided, does the AI look at total strength or active strength during threat assessment? Is detection based off of total strength or active strength? Is there different breakdown or damage from weather for active and total strength? All of those and many more would have to be decided on.

The implementation is not difficult, the impact as you mentioned would be something that would have to be thought on, including if it adds to the game in an way that improves the game. I think it would be an improvement, and could be constrained to only apply to the situations it should apply to.

Somewhere someone would have to decide when Total 'active' or 'resting' unit strength should apply to different formulas. And how that would effect play balance, in that I understand it would be risky to play balance, but I really don't see it as difficult, only as potentially having a large impact on balance.

It is not a minor change, but it is so obvious part of command decision, and unit maintenance. Is the unit stood up, or in rest/prepare? that is much of logistics.


The other place it would touch would be should the state be set to stand up on move, or stand up on some type of attack or being attacked, and actually deciding if partial rest is turned off while initiating some combat. Does the unit stand up during every move and attack, only during planned attack, or only planned and hasty attacks? Does it resume some stand down rest after moving until a user switches it? Or does any move set the unit to full stand up? So yea, it is a big change, but logically moving would stand up the unit, while a better user interface would remember the rest percent to reenter that state when it stops moving at end of turn. And how many movement points does it cost to move when some percent is in partial stood down rest state, again another design and play balance decision.

It should be noted, this is simply something for me to think about while having little else to do, and not much more then that, but most of the time the engineer is reluctant to make any changes and that inertia is often much of the worry about making some change, in this case I do agree it is more of a design change then a patching of current functionality.

And of coarse the setting of the mode would have to be intuitive and not create extra mouse clicks everywhere.

As far as code points, it would defiantly touch on most of the product, but it would be a good idea in my view, weather it would be more important then other items to spend time on, that is of coarse a design decision.