Matrix Games Forums

When setting CAP, the player does not know what air missions the phasing player is going to fly. However, he does know what planes are available for both sides. Therefore, the player can make CAP assignments conditional upon the number, quality, and location of enemy air units. Also included in the conditionals can be references to what is in the target hexes, weather, and the status of other units. For example, the CAP missions against Port Attacks might only be flown if a ‘sufficient’ number of naval units are in the port. The player might also want to base the go/no go decision on whether there are other “good things” for the fighter to do (e.g., don’t fly the CAP mission but keep the fighter available for use later in the impulse/turn).

You say that the player will know what planes are available to both sides.
About the enemy available planes more specifically, it would be good if the player knew the available enemy planes considering the specific hex he chose.
For instance if I choose the Ploesti Oil wells, I'd be happy to have the information about enemy planes that can go to Ploesti, with their cumulative air to air strengh (as if they were aligned to fight) and their total strat / tactical / naval air strengh.

(1) Go or no go decision
Criteria for sending a fighter can depend on type of mission and air-to-air odds. For example; “intercept strategic bombing missions where we have -1 or better air-to-air odds.” It can also depend on the number of uncommitted enemy bombers or ATRs: keep 1 fighter in reserve for each uncommitted enemy ATR.

About the "Keep 1 FTR in reserve", here are some ideas :
- The FTR kept in reserve can be so because it itself has a SO to intercept missions done by ATRs.
- The planes you want the AIA to never touch can be tagged as such by the player (in a way similar to the one which allow to tag a unit to be in Sentry mode).
- Maybe there can be some sort of General SO Options to which all SO would abide, that would say : Always keep X number of FTR (or LND, or else) face-up for each enemy LND (or ATR, or FTR, or NAV or else) face-up, in a given theater.
That's all for the moment.

The bombers are more usually more difficult to sort. The player might want to do a sum of capabilities and sort on the sum. For example, (tactical + strategic + naval strengths) could be a good indicator of how valuable the unit is. He might want to sort in ascending order on that sum (so the least valuable units are at more risk).

Why making a sum ?
Why not using each of the factors of the bomber, and sort them in the order whished by the player ?
You could also provide the sum if the player want to use it to sort the bombers, but why not provide the individual factors ?

SO 9 Return air units to base
Location X.5.2 Non-phasing player returns planes to base (Rules 14.3.2)
Choices
Interface
Default Return to the hex from which it just came.

I wanted to propose ideas for the "Choices". It is ideas that were already mentionned for some of them.

Choices (could check many, but not opposite ones) :
- As near as possible to the frontline.
- As near as possible to the best defensive position in range.
- To the hex from which it just came, or as near as possible to this hex.
- As far away as possible from the frontline.
- As far away as possible from the enemy best offensive positions.
- In range of a possible reorganization source (face-up TRS/AMPH at sea, face-up HQ with no HQ support or else SO, face-up ATR not stacked with PARA or other airmobile troops).
- In a city in its home country (for a possible future retirement of the unit).
- In a given direction (East, West, North, South, etc...).
- As near as possible to the nearest Oil resource.
- As near as possible to the farest Oil resource.
- In a friendly unit ZOC (to avoid Partisans at the end of the turn).
- Avoid allowed overstack if possible (Allowed overstacks are when you use the benefit of an ENG or an HQ to stack extra planes).
- Stacked on a friendly land unit.
- Not stacked on a friendly land unit.

Well, I don't know if it is useful, anyway I believed it was.

Choices Avoid combat, [Choose combat type], [Select enemy target], [Increase your column in naval combat], Decrease Opponent’s column in naval combat, Increase your air-to-air combat value, Decrease opponent’s air-to-air combat value, [Decrease opponent’s anti-aircraft fire column]. Items in [] are not applicable for a player defending against a port attack.

You forgot : Increase your anti-aircraft fire column. Didn't you ?

SO 11 Naval Movement Interception
Location 10.3.3 Naval interception (Rules 11.4.6)
Choices Yes or No.
Interface
Default Yes if probability of victory is greater than probability of loss. Victory is defined by each Major Power for all of its naval units. For example, the CW can define victory as a battle where its losses equal its kills. Italy might want to define it as where its kills are 150% of its losses. Losses and kills are measured in build points.

About the Interface, my ideas :

- The interface shows a list of all the sea areas where I have face-up SCS.

- When I click on each sea area, I see the list of all ships & planes (face-up & face-down) I have there, as well as the list of all face-up enemy ships in adjacents sea area and adjacent ports and a list of planes that can possibly join during the combat. In place of the list of enemy ships, I may see a miniature of the map, with small counters in places of the face-up enemy ships & planes, and when I hover those small counters I see their statitics. It may also be the real map, with t filter showing only possible assets.
The ability to gauge the possibility of an enemy naval move and of its strengh as well as the assets the enemy could mobilize to fight his way through may even be skipped as a WiF player in his right mind would already know this all from his previous observations of the maps and the ensuing reflexions he had.

- Then, knowing my forces and my enemy possible forces, I could check a Yes or a No choice.

SO 15 Overrun Air Units
Location 11.2.2 Forced Air Rebase - during land movement
11.7.9.6 Forced Air Rebase - during advance after combat
Choices
Interface
Default As close to my capital as possible

Choices could be the same as SO 9.

SO 24 Return air units to base
Location 11.7.9.3 Choosing Losses
Choices
Interface
Default Cheapest units (defined by build points).

Is it me or is there a discrepency between the title and the text ?
Title is "Return air units to base" and text talks about choosing losses.
Anyway, if SO 24 is about returning air units to base, the choices could be the same as those of SO 9.

ORIGINAL: Froonp

The bombers are more usually more difficult to sort. The player might want to do a sum of capabilities and sort on the sum. For example, (tactical + strategic + naval strengths) could be a good indicator of how valuable the unit is. He might want to sort in ascending order on that sum (so the least valuable units are at more risk).

Why making a sum ?
Why not using each of the factors of the bomber, and sort them in the order whished by the player ?
You could also provide the sum if the player want to use it to sort the bombers, but why not provide the individual factors ?

The player can refer to individual factors OR to a sum of all or a few of the factors. From the programming point of view, giving the option to add numbers together and then sort by the sum is an additional capabilty to sorting on one factor only.

ORIGINAL: Froonp

Choices Avoid combat, [Choose combat type], [Select enemy target], [Increase your column in naval combat], Decrease Opponent’s column in naval combat, Increase your air-to-air combat value, Decrease opponent’s air-to-air combat value, [Decrease opponent’s anti-aircraft fire column]. Items in [] are not applicable for a player defending against a port attack.

You forgot : Increase your anti-aircraft fire column. Didn't you ?

Yes. Thank you.

ORIGINAL: Froonp

SO 24 Return air units to base
Location 11.7.9.3 Choosing Losses
Choices
Interface
Default Cheapest units (defined by build points).

Is it me or is there a discrepency between the title and the text ?
Title is "Return air units to base" and text talks about choosing losses.
Anyway, if SO 24 is about returning air units to base, the choices could be the same as those of SO 9.

My mistake. The title for SO 24 should be Choosing Land Combat Losses

ORIGINAL: Froonp

When setting CAP, the player does not know what air missions the phasing player is going to fly. However, he does know what planes are available for both sides. Therefore, the player can make CAP assignments conditional upon the number, quality, and location of enemy air units. Also included in the conditionals can be references to what is in the target hexes, weather, and the status of other units. For example, the CAP missions against Port Attacks might only be flown if a ‘sufficient’ number of naval units are in the port. The player might also want to base the go/no go decision on whether there are other “good things” for the fighter to do (e.g., don’t fly the CAP mission but keep the fighter available for use later in the impulse/turn).

You say that the player will know what planes are available to both sides.
About the enemy available planes more specifically, it would be good if the player knew the available enemy planes considering the specific hex he chose.
For instance if I choose the Ploesti Oil wells, I'd be happy to have the information about enemy planes that can go to Ploesti, with their cumulative air to air strengh (as if they were aligned to fight) and their total strat / tactical / naval air strengh.

Good point.

I now have the Standing Orders should include the ability to:
(1) Identify the enemy fighters and bombers (or ATRs) that can reach the target hex(es) under examination,
(2) Be able to calculate the effective air-to-air rating for the front fighter, and
(3) Be able to calculate the total effective bombing factors (after terrain and weather are taken into consideration).

By effective rating for the front fighter, I mean with all the other fighters lined up behind him.

ORIGINAL: Froonp

(1) Go or no go decision
Criteria for sending a fighter can depend on type of mission and air-to-air odds. For example; “intercept strategic bombing missions where we have -1 or better air-to-air odds.” It can also depend on the number of uncommitted enemy bombers or ATRs: keep 1 fighter in reserve for each uncommitted enemy ATR.

About the "Keep 1 FTR in reserve", here are some ideas :
- The FTR kept in reserve can be so because it itself has a SO to intercept missions done by ATRs.
- The planes you want the AIA to never touch can be tagged as such by the player (in a way similar to the one which allow to tag a unit to be in Sentry mode).
- Maybe there can be some sort of General SO Options to which all SO would abide, that would say : Always keep X number of FTR (or LND, or else) face-up for each enemy LND (or ATR, or FTR, or NAV or else) face-up, in a given theater.

I assumed the player would be able to write a SO that says "don't use this fighter (or any specific unit)". I also assume that a SO can say "only use this unit to defend this hex against a specific air mission type".

What I was getting at with my "1 fighter in reserve" comment was the ability to say "use any of these 5 fighters but keep at least 1 of them in reserve". This frees all 5 fighters to be considered for use by the SO (or SOs), yet guarantees the player that he will have one of them face up when the opponent is done his impulse.

ORIGINAL: Froonp

SO 15 Overrun Air Units
Location 11.2.2 Forced Air Rebase - during land movement
11.7.9.6 Forced Air Rebase - during advance after combat
Choices
Interface
Default As close to my capital as possible

Choices could be the same as SO 9.

Yes. Good point. Anything that simplifies the problem of designing all the SO interfaces is good news.

ORIGINAL: Froonp

SO 11 Naval Movement Interception
Location 10.3.3 Naval interception (Rules 11.4.6)
Choices Yes or No.
Interface
Default Yes if probability of victory is greater than probability of loss. Victory is defined by each Major Power for all of its naval units. For example, the CW can define victory as a battle where its losses equal its kills. Italy might want to define it as where its kills are 150% of its losses. Losses and kills are measured in build points.

About the Interface, my ideas :

- The interface shows a list of all the sea areas where I have face-up SCS.

- When I click on each sea area, I see the list of all ships & planes (face-up & face-down) I have there, as well as the list of all face-up enemy ships in adjacents sea area and adjacent ports and a list of planes that can possibly join during the combat. In place of the list of enemy ships, I may see a miniature of the map, with small counters in places of the face-up enemy ships & planes, and when I hover those small counters I see their statitics. It may also be the real map, with t filter showing only possible assets.
The ability to gauge the possibility of an enemy naval move and of its strengh as well as the assets the enemy could mobilize to fight his way through may even be skipped as a WiF player in his right mind would already know this all from his previous observations of the maps and the ensuing reflexions he had.

- Then, knowing my forces and my enemy possible forces, I could check a Yes or a No choice.

Taking your second point first, knowledge about previous enemy activity will not be part of SOs. It is too complicated to do. The player is a far better judge of the details concerning the history of the game and in this case he can simply set the SO to "do not intercept".

Going back to your first point, this seems similar to what we want for air-to-air combat. In particular, the ability to know what units the enemy can bring to bear in the sea area (or the sea box) and an aggregation of those assets' combat factors. For naval combat that can include air-to-sea combat, surface combat, and aspects of the fleet profile. I include the later for those situations where the enemy only has battleships or carriers and would really not want to fight because there are no light ships available to take losses. Fleet profile also lets you make a calculation of the surface combat table columns that would be used.

Taking your second point first, knowledge about previous enemy activity will not be part of SOs. It is too complicated to do. The player is a far better judge of the details concerning the history of the game and in this case he can simply set the SO to "do not intercept".

I agree and was not saying that the SO should have knowledge of the past play.
It should only be able to analyse the existing assets. But I was also saying that if it was unable to assess the existing assets (friendly & enemy) the player could live without this as the player must be able to judge the assets too.

ORIGINAL: Froonp

SO 9 Return air units to base
Location X.5.2 Non-phasing player returns planes to base (Rules 14.3.2)
Choices
Interface
Default Return to the hex from which it just came.

I wanted to propose ideas for the "Choices". It is ideas that were already mentionned for some of them.

Choices (could check many, but not opposite ones) :
- As near as possible to the frontline.
- As near as possible to the best defensive position in range.
- To the hex from which it just came, or as near as possible to this hex.
- As far away as possible from the frontline.
- As far away as possible from the enemy best offensive positions.
- In range of a possible reorganization source (face-up TRS/AMPH at sea, face-up HQ with no HQ support or else SO, face-up ATR not stacked with PARA or other airmobile troops).
- In a city in its home country (for a possible future retirement of the unit).
- In a given direction (East, West, North, South, etc...).
- As near as possible to the nearest Oil resource.
- As near as possible to the farest Oil resource.
- In a friendly unit ZOC (to avoid Partisans at the end of the turn).
- Avoid allowed overstack if possible (Allowed overstacks are when you use the benefit of an ENG or an HQ to stack extra planes).
- Stacked on a friendly land unit.
- Not stacked on a friendly land unit.

These are all good to my eye.

I do not see them as 'Choices' though. My use of the word 'Choices' is what actions the player has to choose from. In this case, all the choices are the same: "pick some hex where the air unit lands after flying a mission". What you are describing are the conditional statements for making that decision.

This is a subtle difference. But you do want me (the MWIF programmer) to be a real stickler for detail don't you?

Right now, how to present the conditionals to the player (the design of the interface) is my main headache for SOs. Your long list will actually help me solve this problem, because it defines the breadth of capabilities the interface needs to provide.

I do not see them as 'Choices' though. My use of the word 'Choices' is what actions the player has to choose from. In this case, all the choices are the same: "pick some hex where the air unit lands after flying a mission". What you are describing are the conditional statements for making that decision.

This is a subtle difference. But you do want me (the MWIF programmer) to be a real stickler for detail don't you?

Right now, how to present the conditionals to the player (the design of the interface) is my main headache for SOs. Your long list will actually help me solve this problem, because it defines the breadth of capabilities the interface needs to provide.

A list of checkboxes would be ok, wouldn't they ?

ORIGINAL: Froonp

I do not see them as 'Choices' though. My use of the word 'Choices' is what actions the player has to choose from. In this case, all the choices are the same: "pick some hex where the air unit lands after flying a mission". What you are describing are the conditional statements for making that decision.

This is a subtle difference. But you do want me (the MWIF programmer) to be a real stickler for detail don't you?

Right now, how to present the conditionals to the player (the design of the interface) is my main headache for SOs. Your long list will actually help me solve this problem, because it defines the breadth of capabilities the interface needs to provide.

A list of checkboxes would be ok, wouldn't they ?

I don't think it can be handled with such a simple solution. Why I feel that way is not easy to explain. If we don't inlcude all the possible conditionals on the check list, the players will be upset about the ones that are missing. The check boxes are at one end of a spectrum - they are very precise. At the other end is something very general. And in between is the ability to do combinations of check boxes or prioritizing according to different parameters.

I am still looking for ideas. This problem probably needs to ferment in my mind for a few days.

ORIGINAL: Shannon V. OKeets
So, let me propose the following:
(1) The capability to require an email instead of a SO will be part of MWIF.
(2) This capability can be turned on or off for each of the 22 SO locations.
(3) The on/off flags can be set either at the beginning of the game (like an optional rule), or dynamically modified during play.
(4) To modify the flags during play requires the unanimous agreement of all the players in the game.

Well, that's my instant analysis. Does it hold water or sink to the bottom like a concrete canoe?

I believe it sinks. A player that insists on that level of control should be directed to TCP/IP play, and told to accept that with PBEM comes some changes from head-to-head-play. We are only creating a conflict-source between the players if we add the ability to demand emails for the non-phaser, not to mention that it goes directly against the purpose with the standing orders.