MWIF Game Interface Design

[Froonp]

ORIGINAL: bredsjomagnus

I would like to do something more forceful to indicate the current subphase, but there doesn't seem to be component that has the features that I want. I am loathe to spend time developing a custom made component just for this.

Mayby just another color would do it?

Problem with the color of text is that each Major Power have a different background color for his forms (i.e. blue for the CW, grey for Germany, Red for Japan...), and black font is what works the best for all.

[Shannon V. OKeets]

ORIGINAL: csharpmao

ORIGINAL: Froonp

ORIGINAL: Shannon V. OKeets

2nd in series. Here is what the player typically sees first. The current subphase is Select Combat, which has an asterisk and has a 'raised' presence in the strip of subphases. I would like to do something more forceful to indicate the current subphase, but there doesn't seem to be component that has the features that I want. I am loathe to spend time developing a custom made component just for this.

Maybe use bold font, or another color, to do something more forceful to indicate the current subphase.

Yes, as Froonp said, I think the asterisk is not visible enough.
For me, the best choice would be a color change, but I know that choosing a second color for each major power can be tricky.
Bold is a second choice, but better than the asterisk.

The color and fonts are for the entire row - all entries/subphases. I looked at several alternative components but they all have the same constraint: a single font for all entries. I simply have more important things to spend time on than trying to perfect this.

[Shannon V. OKeets]

ORIGINAL: lomyrin

Where would the die roll be shown when that option is turned on ?

Lars

The Results box is large so I can display a lot of stuff there. For instance, the die rolls.

[Shannon V. OKeets]

ORIGINAL: Froonp

ORIGINAL: Shannon V. OKeets
My main purpose in posting all these screens is to let you know what I have decided about who decides which units take losses. RAW says that the 'owner' decides, but leaves open the question of which player on a side decides when multiple major powers have units that mght take losses. There is a line in the rules about randomly choosing units if the major powers can agree. I didn't want to do that, since it adds a lot of complexity to something that should occur rarely.

How do you know who chooses, I mean, from the screenshots here, do you know just by the color of the Form and the little flag in the title bar ?
Maybe a line of text sur as "[Country] choose wich unit to suffer the combat losses", where [Country] is the name of the Major Power ?

Instead I have decided to designate one player for each side as the decision maker based on the units involved in the combat. Priority goes to:
(1) the player with the most valuable land units in the combat (i.e., build points), or in case of tie,
(2) the player with the most land units in the combat, or in case of tie,
(3) the player with the most valuable units in the combat (this includes land and naval units for the defender), or in case of tie,
(4) the player with the most combat factors in the combat (attack factors for attacker and defense factors for the defender - neither are modified whatsoever).

If things are still tied, then the order is: mcGermany, mcItaly, mcJapan, mcVichyFrance, mcChina, mcCommonwealth, mcFrance, mcUnitedStates, mcUSSR

It looks good to me.
For (1), do you sum up the BP value of all the units in the combat ?

Also, for the final tie, why choose an alphabetical sorting ?

Why not :
mcGermany, mcItaly, mcJapan, mcVichyFrance, mcUnitedStates, mcUSSR, mcCommonwealth, mcChina, mcFrance

Or, for the final tie, put the countries in the same order as their previous turn total Built Points produced ? So this gets the most "powerful" country get the choice.

If you are not the decision maker, the prompt at the top (under the subphases bar) will state who is making the decision. If you are the decision maker, the program will change your current major power (if necessary) to the one that makes the decision.

All the prompts work the same way here. If it is up to you to decide, then you simply see an imperative prompt (e.g., Choose ...). All the other players will see: "Commonwealth is choosing the combat results table", or some such message.
====
I could change the default order, but does it really matter? If 4 different tie breaks fail, let's just let someone involved in the combat decide.

[Froonp]

ORIGINAL: Shannon V. OKeets
Or, for the final tie, put the countries in the same order as their previous turn total Built Points produced ? So this gets the most "powerful" country get the choice.

If you are not the decision maker, the prompt at the top (under the subphases bar) will state who is making the decision. If you are the decision maker, the program will change your current major power (if necessary) to the one that makes the decision.

I could change the default order, but does it really matter? If 4 different tie breaks fail, let's just let someone involved in the combat decide.

I it did not matter, it would not be there, so if it matters a tiny bit, let's have it the best way, no ?

[bredsjomagnus]

Problem with the color of text is that each Major Power have a different background color for his forms (i.e. blue for the CW, grey for Germany, Red for Japan...), and black font is what works the best for all.

 
You can use the same background color to every nation. Yellow or orange for example. You name it.

[bredsjomagnus]

Ok im trying again (to upload my example)

[bredsjomagnus]

Here is same color but with CW

[bredsjomagnus]

And while im at it, i think the buttons could look nicer too... I know that it is just details but i think it enhances the game experience when the interface is nice looking.

I´ve tried to alter the "View Charts" button on this image.

[Anendrue]

I like the light orange color so far. Does this look just as good on the other background colors? If so, it is a clear winner to identify the current subphase.

[alsopxx33]

Could you use ALL CAPS?

[Shannon V. OKeets]

ORIGINAL: alsopxx33

Could you use ALL CAPS?

Yes, that is a good idea. Thanks.
=============
If I could easily change the color of the 'selected' subphase, I would. But the component dosen't allow that. Likewise changing the button graphics requires substantially more work.

At a primitive graphics level, everything is possible. But I do not want to develop special components unless there is a crucial need. For instance, the map and units are done at primitive graphics level, and the code to accomplish that is enormous.

I have a half dozen libraries of components that I am using, but I haven't found a component that does what I want: horizontal list with selectable items, such that selected items have different background colors and fonts. I spent several hours looking for that (all these components are undocumented so it is trial and error, with small hints provided by the component names). I don't have the time to chase after this any more.

[Anendrue]

ORIGINAL: Shannon V. OKeets

ORIGINAL: alsopxx33

Could you use ALL CAPS?

Yes, that is a good idea. Thanks.
=============
If I could easily change the color of the 'selected' subphase, I would. But the component dosen't allow that. Likewise changing the button graphics requires substantially more work.

At a primitive graphics level, everything is possible. But I do not want to develop special components unless there is a crucial need. For instance, the map and units are done at primitive graphics level, and the code to accomplish that is enormous.

I have a half dozen libraries of components that I am using, but I haven't found a component that does what I want: horizontal list with selectable items, such that selected items have different background colors and fonts. I spent several hours looking for that (all these components are undocumented so it is trial and error, with small hints provided by the component names). I don't have the time to chase after this any more.

Well since we have the color limitation CAPS is a fair soulution and easy to implement. Perhaps CAPS, Bold and slightly larger size or even a different font.

[bredsjomagnus]

If I could easily change the color of the 'selected' subphase, I would. But the component dosen't allow that. Likewise changing the button graphics requires substantially more work.

 
Ok, if thats the case [:(]... Im no programmer so what looks easy for me can of course be the opposite when it comes to codeing.
 
Its only grafical details anyway.

[Shannon V. OKeets]

ORIGINAL: bredsjomagnus

If I could easily change the color of the 'selected' subphase, I would. But the component dosen't allow that. Likewise changing the button graphics requires substantially more work.

Ok, if thats the case [:(]... Im no programmer so what looks easy for me can of course be the opposite when it comes to codeing.

Its only grafical details anyway.

The way software tools work is a lot like so many other things for sale. If you are happy with what is on the shelf, there are thousands of similar ones to choose from. But if you want something slightly different, well, then none has been created, much less made available for you to purchase.

[Orm]

ORIGINAL: bredsjomagnus

And while im at it, i think the buttons could look nicer too... I know that it is just details but i think it enhances the game experience when the interface is nice looking.

I´ve tried to alter the "View Charts" button on this image.

I think the land combat sequence looks very nice in this version. I would prefer that it remain without all caps highlighting the current phase. All caps is to "screaming" to me and thus annoying.

Can the color used "bleed" into the background color on some countres for someone who is colorblind?

With the change of the view charts button I got the feeling that the buttons blietzkrieg and assault was greyed out and not available to be chosen at this moment.

-Orm

[bredsjomagnus]

With the change of the view charts button I got the feeling that the buttons blietzkrieg and assault was greyed out and not available to be chosen at this moment.

I only changed one button but the meaning was that every button should look the same. And "my" button is not the worlds most good looking button either [:'(].

[Peter Stauffenberg]

ORIGINAL: Shannon V. OKeets
If I could easily change the color of the 'selected' subphase, I would. But the component dosen't allow that. Likewise changing the button graphics requires substantially more work.

Is it possible to write the subphases already completed with greyish text (or maybe italic), thus showing it's already completed. The active subphase could be written with bold text and future subphases with the normal text.

[paulderynck]

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.

[Shannon V. OKeets]

ORIGINAL: paulderynck

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.