Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
|
quote:
ORIGINAL: paulderynck
quote:
ORIGINAL: Shannon V. OKeets
I am revising the display (and processing) of land combat resolution. Here is the new form.
At the top is the sequence of the subphases within the phase land combat resolution. RAC (rules as coded) follows RAW (rules as written), for this subphase sequence. Regrettably, RAW is somewhat vague about who decides to use snow units first/second and where the decision about using the engineer occurs.
I am going to change what you see here so that following Select Combat will be: Attacker decides whether to use Snow Units, Defender decides to use Snow Units, Attacker decides to use Engineer, and lastly, the decision about combat table is made.
Note that the Odds are updated as these decisions are made, though those decisions that require a die roll are only estimates until the die roll actually occurs. When there is a difference between Assault and Blitz odds, both are shown with Assault odds shown first (e.g., hex [49, 45]).
At the bottom, the Unit Data Panel is updated whenever the cursor passes over one of the defending or attacking units.
Hi Steve, this was discussed on the Yahoo Rules list and Patrice requested I relay my suggestion to you, as he is in the midst of moving and is suffering from internet pause-itis.
IMO it should be:
1) Declaration of all combats
2) Select the hex
2A) Attacker decides whether to use Engineer's ability
2B) Attacker decides whether to use Snow Units
2C) Defender decides whether to use Snow Units
3) The rest of the combat sequence per RAW
4) Back to step 2 for next hex
I think the Defender should know what the Attacker's options are before having to choose.
An advantage of my suggestion is that the attacker makes his decisions together, rather than the attacker-defender-attacker sequence you suggested. The next decisions are also the defender's - accept or decline the notional; and add DSB (if it is a chosen option) - so these decisions are "grouped". This will reduce the requirement for interaction in hotseat, pbem and network games.
Further to this, a guiding principle should be the grouping of decisions, even if this bends RAW a bit (as long as the effect is minor) - so that the interaction factor is minimized.
Cheers.
Thanks. I think the code is pretty much this way already.
The decision about the engineer is made when the attacker declares his attacks.
The attacker snow decision is made after a specific combat hex is chosen
The defender snow decision is next
The die rolls for HQ support need to be made next, which interrupts the defender's decisions.
The defender chooses Assault or Blitz (knowing all of the above)
==
The only substantative difference is that the attacker decides about Engineers before:
pIgnoreNotional, // RAC 11.14.
pEmergencyHQSupply, // RAC 2.4.3. {make available as a digression too}
pShoreBombardmentD, // RAC 11.16.2.
pShoreBombardmentA, // RAC 11.16.2.
pHQSupportD, // RAC 11.16.3.
pHQSupportA, // RAC 11.16.3.
pGroundSupport, // RAC 11.16.4.
As you presented the Sequence of Play, the Engineer decision would be made after ground support has all been resolved.
==
Here is what I have presently:
pLandMovement, // RAC 11.11.
pAirTransport, // RAC 11.12.
pUnloadLandUnits, // RAC 11.13.
pInvasion, // RAC 11.14.
pParadrop, // RAC 11.15.
pLandCombatDeclaration, // RAC 11.16.1.
pIgnoreNotional, // RAC 11.14.
pEmergencyHQSupply, // RAC 2.4.3. {make available as a digression too}
pShoreBombardmentD, // RAC 11.16.2.
pShoreBombardmentA, // RAC 11.16.2.
pHQSupportD, // RAC 11.16.3.
pHQSupportA, // RAC 11.16.3.
pGroundSupport, // RAC 11.16.4.
pLandCombatResolution, // RAC 11.16.5 & 11.16.6.
The land combat resolution subphases are:
LCRspLandCombatSelection, // RAC 11.16.5.
LCRspAttSnowUnits,
LCRspDefSnowUnits,
LCRspChooseCombatType, // RAC 11.16.5 & 11.16.6.
LCRspLandCombatResolution, // RAC 11.16.5 & 11.16.6.
LCRspConvertShattered,
LCRspAssignLosses, // RAC 11.16.5.
LCRspHexControl, // RAC 11.11.6 (overruns by invading and/or paradropping units)
LCRspRetreats, // RAC 11.16.5.
LCRspAdvanceAfterCombat // RAC 11.16.5.
Each of the air missions has some or all of the subphases:
AspCAP, // RAC 14.2.1.
AspFlyA, // RAC 14.2.2, 14.2.3, & 14.2.1.
AspFlyD, // RAC 14.2.2, 14.2.3, & 14.2.1.
AspInterceptD, // RAC 14.2.1.
AspInterceptA, // RAC 14.2.1.
AspSurprise, // RAC 11.5.6.
AspAirAir, // RAC 14.3.
AspAntiAirD, // RAC 11.5.9.
AspAntiAirA, // RAC 11.5.9.
AspAttack, // RAC 11.5.9, 11.7, 11.8, 11.9, 11.12, 11.15,
// 11.16.4, & 11.8.1.
AspReturnA, // RAC 14.2.
AspReturnD, // RAC 14.2.
And each air-to-air combat has the sub-subphases:
sspLocation, // RAC 14.3.
sspArrange, // RAC 14.3.1.
sspRollDef, // RAC 14.3.2.
ssp1stUnit, // RAC 14.3.3.
ssp1stDisposition, // RAC 14.3.3.
sspRollAtt, // RAC 14.3.2.
ssp2ndUnit, // RAC 14.3.3.
ssp2ndDisposition, // RAC 14.3.3.
sspAttAbortStay, // RAC 14.3.2.
sspDefAbortStay, // RAC 14.3.2.
sspBothStaying // RAC 14.3.2.
_____________________________
Steve
Perfection is an elusive goal.
|
Printable Version
RE: MWIF Game Interface Design - 
... Im no programmer so what looks easy for me can of course be the opposite when it comes to codeing. 
.
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread