Matrix Games Forums

Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

RE: MWIF Game Interface Design

 
View related threads: (in this forum | in all forums)

Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [New Releases from Matrix Games] >> World in Flames >> RE: MWIF Game Interface Design Page: <<   < prev  3 4 [5] 6 7   next >   >>
Login
Message << Older Topic   Newer Topic >>
RE: MWIF Game Interface Design - 8/24/2005 8:33:46 PM   
Cheesehead

 

Posts: 418
Joined: 2/9/2004
From: Appleton, Wisconsin
Status: offline
I don't know what all the "cheat proof" features are going to be built into MWiF, but I am impressed with the ACTS site for rolling dice in my Vassal game. It instantly sends an e-mail to all participants after every roll. Before you make the roll there is a message box for describing what the roll is for. You can't alter the message after the dice have been rolled and then everyone is e-mailed the message with the roll.

John

_____________________________

You can't fight in here...this is the war room!

(in reply to Shannon V. OKeets)
Post #: 121
RE: MWIF Game Interface Design - 8/24/2005 8:44:27 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: Cheesehead

I don't know what all the "cheat proof" features are going to be built into MWiF, but I am impressed with the ACTS site for rolling dice in my Vassal game. It instantly sends an e-mail to all participants after every roll. Before you make the roll there is a message box for describing what the roll is for. You can't alter the message after the dice have been rolled and then everyone is e-mailed the message with the roll.

John

What I intend for MWIF PBEM is something comparable. A small program, eMWIF, will be included with the MWIF game package that can be installed on any ISP. Each game will be 'registered' with a copy of eMWIF (there may be several available?) and when a player needs a die roll, MWIF will go out on the Internet and request one from eMWIF. This way eMWIF 'knows' where in the game a player is and can deny rerolls. When a player sends off his email, MWIF will include all the die rolls that were received from eMWIF.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Cheesehead)
Post #: 122
RE: MWIF Game Interface Design - 8/24/2005 8:59:56 PM   
Cheesehead

 

Posts: 418
Joined: 2/9/2004
From: Appleton, Wisconsin
Status: offline
Sounds perfect. Thanks, Steve

_____________________________

You can't fight in here...this is the war room!

(in reply to Shannon V. OKeets)
Post #: 123
RE: MWIF Game Interface Design - 10/1/2005 6:42:42 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
I am redoing the interface for scrapping units and want to make sure I understand the rules correctly. Here is my understanding.

(1) There are two times that a player can scrap units: at the beginning of a scenario and when a unit is destroyed.

(2) Scrapping a unit only affects that unit and no others (this is a change from earlier editions of WIF).

(3) Any destroyed unit can be scrapped.

(4) Only units whose start date is 4 years before the start of the scenario can be scrapped at the start of a scenario. This number is 3 years if the country starts the scenario at war. Note that no country starts the World in Flames scenario at war.

(5) Any naval unit that was sunk before the start of the scenario can be scrapped.

My main question is what does 'other' refer to in rules section 24.1.5 in the sentence "You can remove any of your other units from force pools if they have a year on their back ...".

(6) It appears that scrapping units can be applied to divisions as well as corps. Is that true for all types of divisions?

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 124
RE: MWIF Game Interface Design - 10/1/2005 10:09:34 AM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
quote:

ORIGINAL: Shannon V. OKeets
I am redoing the interface for scrapping units and want to make sure I understand the rules correctly. Here is my understanding.

(1) There are two times that a player can scrap units: at the beginning of a scenario and when a unit is destroyed.

And at the beginning of the production phase too (13.6.9).
"Before you build new units, you can remove your units from the force pools (...)"

quote:

(2) Scrapping a unit only affects that unit and no others (this is a change from earlier editions of WIF).

(3) Any destroyed unit can be scrapped.

Only units with a date on their back.
reserve & MIL units cannot for instance (13.6.9).
"(...) You have this choice every time one of your units with a date on its back is destroyed (...)"

quote:

(4) Only units whose start date is 4 years before the start of the scenario can be scrapped at the start of a scenario. This number is 3 years if the country starts the scenario at war. Note that no country starts the World in Flames scenario at war.

China & Japan start at war and may scrap 3 years old units.

quote:

(5) Any naval unit that was sunk before the start of the scenario can be scrapped.

My main question is what does 'other' refer to in rules section 24.1.5 in the sentence "You can remove any of your other units from force pools if they have a year on their back ...".

24.1.5 lists a whole bunch of units that you "set aside" from the game before playing. 24.1.5 just tells you that you can also remove (i.e. scrap) others units, if you comply to the scrapping rule.

quote:

(6) It appears that scrapping units can be applied to divisions as well as corps. Is that true for all types of divisions?

I'd say, true for all unit with a date on their back, which type of divisions were you thinking of ? Artillery ?.


< Message edited by Froonp -- 10/1/2005 10:13:50 AM >

(in reply to Shannon V. OKeets)
Post #: 125
RE: MWIF Game Interface Design - 10/1/2005 2:24:54 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
Thanks.

I was thinking about divisional infantry units that are dated. If we are letting players have unlimited breakdown of corps into divisions, the we don't want the players scrapping all the 1-4 infantry so they get to draw 2-3 (or vice-a-versa).

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 126
RE: MWIF Game Interface Design - 10/1/2005 6:32:49 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
Scrapping the dated (1-4) div has no effects on the unlimited (1-4) that you will provide in the game.
Anyway, when scrapping a 5 or 6 strength corps will result in a 1 strength div and a 2 strength div, and scrapping a 7 or 8 strength corps will result in 2 x 2 strength divisions, so scrapping the dated divisions is not relevant, is it ?

(in reply to Shannon V. OKeets)
Post #: 127
RE: MWIF Game Interface Design - 10/1/2005 9:03:07 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
quote:

ORIGINAL: Froonp
Scrapping the dated (1-4) div has no effects on the unlimited (1-4) that you will provide in the game.
Anyway, when scrapping a 5 or 6 strength corps will result in a 1 strength div and a 2 strength div, and scrapping a 7 or 8 strength corps will result in 2 x 2 strength divisions, so scrapping the dated divisions is not relevant, is it ?


I think I'll just make everything easier to understand and prohibit scrapping divisional units that are part of corps breakdown. As you pointed out, this is very close to having no effect at all. One less unit type popping up with the question "Do you want to scrap this unit?" seems like a good idea to me. Especially when you consider that divisional units are probably going to take a lot of the hits, and therefore will be eligible for scrapping frequently.

Just as an aside, only the divisional counters provided in WIF FE will be eligible for being built as divisional units. The unlimited quantity provided under the new optional rule will only be available by breaking down a corp unit that has already been built and placed on the map.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 128
RE: MWIF Game Interface Design - 10/1/2005 10:06:04 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
- Only printed unit can be scrapped.
- The extra divisions from the unlimited breakdown won't be dated, so won't be scrapped.

And I think that normal (paper wif) divisions won't be scrapped, as they are the only one you will be able to build, and it is important to keep divisions to built.

Cheers !

(in reply to Shannon V. OKeets)
Post #: 129
RE: MWIF Game Interface Design - 10/1/2005 10:31:44 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
Here is my proposal for scrapping units. Let me know what you think now, before I start creating this window/form and writing the code to go with it.

==============================
Interface Design for Scrapping Units
(as of October 1, 2005)

I am looking at a whole new screen design for scrapping units. To start with, I want to use the entire screen for the window/form so a lot more information can be displayed when the player makes these decisions. I am also planning on having three different ‘pages’ for this form: air, land, and naval. The player examines each of the them, in any order he likes, for units that he may want to scrap.

The air unit page will contain 15 rows by 5 columns of boxes. Within each box will be individual air unit counters. Each box should be able to display 5 counters or so. The naval boxes will be able to show 10. The columns will be the same for the air, naval, and land pages:
(A) Can be scrapped
(B) On map
(C) In production or repair pool
(D) In force pool
(E) Available in the future


The rows for air units will be:
(1) Fighters that cost 4 build points (BP)
(2) Fighters that cost 5 BP
(3) Tactical bombers that cost 4 BP
(4) Tactical bombers that cost 5 BP
(5) Tactical bombers that cost 6 BP
(6) Naval air that cost 4 BP
(7) Naval air that cost 5 BP
(8) Naval air that cost 6 BP
(9) Strategic bombers that cost 4 BP
(10) Strategic bombers that cost 5 BP
(11) Strategic bombers that cost 6 BP
(12) ATR that cost 4 BP
(13) ATR that cost 5 BP
(14) ATR that cost 6 BP
(15) Carrier air units (sorted by carrier class)

The naval unit page will contain 7 rows:
(1) Carriers
(2) Battleships
(3) Cruisers
(4) Submarines
(5) Naval transports (TRS)
(6) Amphibious units (AMPH)
(7) Frogmen and ASW units

The land unit page will contain 15 rows:
(1) Infantry corps
(2) Cavalry corps
(3) Motorized corps
(4) Mechanized corps
(5) Armor corps
(6) Mountain corps
(7) Paradrop corps
(8) Marine corps
(9) HQ corps
(10) Garrisons
(11) Territorials
(12) Artillery divisions
(13) Anti-tank and anti-air divisions
(14) Motorized engineer, marine engineer, armored marine, air landing, & ski divisions
(15) Supply units

The infantry, motorized, mechanized, armor, cavalry, paradrop, marine, and mountain division size units are not included in the above list because scrapping them will not be permitted. They will always be available for breaking down corps size units.

Any unit type that contains only 1 unit (for the major power scrapping units) will be omitted. This is because there are no ‘better’ units to draw at random. For example, this would usually apply to armor HQs.

When the player opens the page for, say, air units, the 75 different boxes will fill with units. If there are no units in the “Can be scrapped” column, then that row will be omitted. At a glance, the player will be able to see all his air units that could potentially be scrapped and the quality of the similar air units which either currently are in his force pool, or might be there in the future. Moving the cursor over any unit will bring up all its detailed information. Simply clicking on a unit in the “Can be scrapped” column will mark it for scrapping. If the player changes his mind, clicking on it again will remove that mark (it won’t be scrapped). Once a player has selected all the air units he wants to scrap, he can move on to the pages for naval and land units. A final confirmation will be required for each page and none of the units will be scrapped until the player exits from the scrap unit window entirely.

What I hope to achieve with this new design is to enable the player to make more informed decisions about scrapping units. The procedure should be rather painless too.

What do you think?


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 130
RE: MWIF Game Interface Design - 10/1/2005 11:40:12 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
Overall nice idea and presentation.
However, there are a few things to consider.

quote:

ORIGINAL: Shannon V. OKeets

Here is my proposal for scrapping units. Let me know what you think now, before I start creating this window/form and writing the code to go with it.

==============================
Interface Design for Scrapping Units
(as of October 1, 2005)

I am looking at a whole new screen design for scrapping units. To start with, I want to use the entire screen for the window/form so a lot more information can be displayed when the player makes these decisions. I am also planning on having three different ‘pages’ for this form: air, land, and naval. The player examines each of the them, in any order he likes, for units that he may want to scrap.

The air unit page will contain 15 rows by 5 columns of boxes. Within each box will be individual air unit counters. Each box should be able to display 5 counters or so. The naval boxes will be able to show 10. The columns will be the same for the air, naval, and land pages:
(A) Can be scrapped
(B) On map
(C) In production or repair pool
(D) In force pool
(E) Available in the future


The rows for air units will be:
(1) Fighters that cost 4 build points (BP)
(2) Fighters that cost 5 BP
(3) Tactical bombers that cost 4 BP
(4) Tactical bombers that cost 5 BP
(5) Tactical bombers that cost 6 BP
(6) Naval air that cost 4 BP
(7) Naval air that cost 5 BP
(8) Naval air that cost 6 BP
(9) Strategic bombers that cost 4 BP
(10) Strategic bombers that cost 5 BP
(11) Strategic bombers that cost 6 BP
(12) ATR that cost 4 BP
(13) ATR that cost 5 BP
(14) ATR that cost 6 BP
(15) Carrier air units (sorted by carrier class)

These are costs while not playing with pilots. If playing with pilots, they are all 2 BP cheaper.

In your categories of planes, bear in mind that in WiF Final Edition, Tactical Bombers and Strategic Bombers (who existed in WiF 5) are now all designed by an unique name : Land bombers (abreviated LND).
The Strategic bombers are those LND that cost 6 BP (not using pilots).
So your categories should not have "Tactical bombers that cost 6 BP" because they are the Strategic bobmers, and should not have neither the "Strategic bombers that cost 4 BP" and the "Strategic bombers that cost 5 BP" because they are LND.
In short, rows (5), (9) and (10) should disappear.
Now, for the ATR, there is no "ATR that cost 4 BP" (not using pilots) in the current countermix, so row (12) should disappear too.

quote:

The naval unit page will contain 7 rows:
(1) Carriers
(2) Battleships
(3) Cruisers
(4) Submarines
(5) Naval transports (TRS)
(6) Amphibious units (AMPH)
(7) Frogmen and ASW units

There should be a row for CA and a row for CL. Same for Carriers, there should be a row for the CV and a row for the CVL, this is extremly important as they are different force pools, and they can be numerous, so tedious to tell the ones from the others if they are mixed.
ASW should idealy be in their own row, without the Frogmens.
Frogmens should be amongst SUBs. But this is only a subjective opinion.

quote:

The land unit page will contain 15 rows:
(1) Infantry corps
(2) Cavalry corps
(3) Motorized corps
(4) Mechanized corps
(5) Armor corps
(6) Mountain corps
(7) Paradrop corps
(8) Marine corps
(9) HQ corps
(10) Garrisons
(11) Territorials
(12) Artillery divisions
(13) Anti-tank and anti-air divisions
(14) Motorized engineer, marine engineer, armored marine, air landing, & ski divisions
(15) Supply units

The infantry, motorized, mechanized, armor, cavalry, paradrop, marine, and mountain division size units are not included in the above list because scrapping them will not be permitted. They will always be available for breaking down corps size units.

Any unit type that contains only 1 unit (for the major power scrapping units) will be omitted. This is because there are no ‘better’ units to draw at random. For example, this would usually apply to armor HQs.

If the row contains only 1 unit that can be scrapped, it should be displayed as well as the future & on maps & all units, because you can always want to scrap a lone unit to make the future ones available for advance build.
Anyway, whether you scrap it or not, you should always see all units that are scrappable.

quote:


When the player opens the page for, say, air units, the 75 different boxes will fill with units. If there are no units in the “Can be scrapped” column, then that row will be omitted. At a glance, the player will be able to see all his air units that could potentially be scrapped and the quality of the similar air units which either currently are in his force pool, or might be there in the future. Moving the cursor over any unit will bring up all its detailed information. Simply clicking on a unit in the “Can be scrapped” column will mark it for scrapping. If the player changes his mind, clicking on it again will remove that mark (it won’t be scrapped). Once a player has selected all the air units he wants to scrap, he can move on to the pages for naval and land units. A final confirmation will be required for each page and none of the units will be scrapped until the player exits from the scrap unit window entirely.

More than that, I think that there could be a summary panel showing the averages for the relevant factors for each row & column with & without the units you have marked as beeing scrapped.
The relevant factors could be combat strength & movement for land units, range and the 4 other factors for the air units, etc... I'm not sure this would be extremely useful, considering that there are not trillion of units, and that you can have an idea of those values at glance.... don't really know...

quote:


What I hope to achieve with this new design is to enable the player to make more informed decisions about scrapping units. The procedure should be rather painless too.

What do you think?



< Message edited by Froonp -- 10/1/2005 11:45:07 PM >

(in reply to Shannon V. OKeets)
Post #: 131
RE: MWIF Game Interface Design - 10/2/2005 3:02:30 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
Here is my second pass at the interface design for scrapping units. Revisions were ssuggested by Patrice.
==========================
Interface Design for Scrapping Units
(as of October 1, 2005 - Revised)

I am looking at a whole new screen design for scrapping units. To start with, I want to use the entire screen for the window/form so a lot more information can be displayed when the player makes these decisions. I am also planning on having three different ‘pages’ for this form: air, land, and naval. The player examines each of the them, in any order he likes, for units that he may want to scrap.

The air unit page will contain 11 rows by 5 columns of boxes. Within each box will be individual air unit counters. Each box will hold about 5 units. The columns will be the same for the air, naval, and land pages:
(A) Can be scrapped
(B) On map
(C) In production or repair pool
(D) In force pool
(E) Available in the future


The rows for air units will be:
(1) Fighters that cost 2 build points (BP - assumes pilots are built separately)
(2) Fighters that cost 3 BP
(3) Land bombers that cost 2 BP
(4) Land bombers that cost 3 BP
(5) Land/strategic bombers that cost 4 BP
(6) Naval air that cost 2 BP
(7) Naval air that cost 3 BP
(8) Naval air that cost 4 BP
(9) ATR that cost 3 BP
(10) ATR that cost 4 BP
(11) Carrier air units (sorted by class)

The naval unit page will contain 10 rows:
(1) Carriers (CVs)
(2) Light carriers (CVLs)
(3) Battleships
(4) Cruisers (CA)
(5) Light Cruisers (CL)
(6) Submarines
(7) Naval transports (TRS)
(8) Amphibious units (AMPH)
(9) ASW units
(10) Frogmen

The land unit page will contain 15 rows:
(1) Infantry corps
(2) Cavalry corps
(3) Motorized corps
(4) Mechanized corps
(5) Armor corps
(6) Mountain corps
(7) Paradrop corps
(8) Marine corps
(9) HQ corps
(10) Garrisons
(11) Territorials
(12) Artillery divisions
(13) Anti-tank and anti-air divisions
(14) Motorized engineer, marine engineer, armored marine, air landing, & ski divisions
(15) Supply units

The infantry, motorized, mechanized, armor, cavalry, paradrop, marine, and mountain division size units are not included in the above list because scrapping them will not be permitted. They will always be available for breaking down corps size units.

Any unit type that contains only 1 unit in the counter mix (for the major power scrapping units) will be omitted. This is because there are no ‘better’ units to draw at random. For example, this would usually apply to armor HQs.

When the player opens the page for, say, air units, the 75 different boxes will fill with units. If there are no units in the “Can be scrapped” column, then that row will be omitted. At a glance, the player will be able to see all his air units that could potentially be scrapped and the quality of the similar air units which either currently are in his force pool, or might be there in the future. Moving the cursor over any unit will bring up all its detailed information. Simply clicking on a unit in the “Can be scrapped” column will mark it for scrapping. If the player changes his mind, clicking on it again will remove that mark (it won’t be scrapped). Once a player has selected all the air units he wants to scrap, he can move on to the pages for naval and land units. A final confirmation will be required for each page and none of the units will be scrapped until the player exits from the scrap unit window entirely.

What I hope to achieve with this new design is to enable the player to make more informed decisions about scrapping units. The procedure should be rather painless too.

What do you think?


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 132
RE: MWIF Game Interface Design - 10/2/2005 3:23:12 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
quote:

ORIGINAL: Froonp
If the row contains only 1 unit that can be scrapped, it should be displayed as well as the future & on maps & all units, because you can always want to scrap a lone unit to make the future ones available for advance build.
Anyway, whether you scrap it or not, you should always see all units that are scrappable.


My intent was to omit lone unit types. That is, the unit is the only one of the type that will ever be controlled by the major power. Scrapping these units changes nothing, since you can simply never build them instead. This situation can also occur if the player scraps all but one unit of a type. My objective here is to remove clutter from the screen.

quote:

More than that, I think that there could be a summary panel showing the averages for the relevant factors for each row & column with & without the units you have marked as beeing scrapped.
The relevant factors could be combat strength & movement for land units, range and the 4 other factors for the air units, etc... I'm not sure this would be extremely useful, considering that there are not trillion of units, and that you can have an idea of those values at glance.... don't really know...


This suggestion came up before, I think from someone else. If all the units are displayed on the screen, the player can make his own judgments about the average strength, range, and other features. There are a lot of odd bits for air units (night, twin engine, fighter/bomber, etc.) and any average would either ignore those attributes or else make some arbitrary adjustment to the average. The average strength won't help that much and might be misleading.

In addition, I don't think scrapping units is such a crucial area of the game that it deserves lavish attention. The primary reasons I am going to the lengths I am are: (1) making a good decision depends on knowing about all the similar units in the game, and (2) this task can be extremely confusing to a novice since WIF is the only game I know of that has this feature - or anything at all like it.

In any event, I believe that what I am proposing will be a whole lot better than what is available to a player over the board. The time it takes to figure out what units are where can take a lot of time, including turning over a lot of counters to see their build point cost.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 133
RE: MWIF Game Interface Design - 10/2/2005 3:30:21 AM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
quote:

ORIGINAL: Shannon V. OKeets
The rows for air units will be:
(1) Fighters that cost 2 build points (BP - assumes pilots are built separately)
(2) Fighters that cost 3 BP
(3) Land bombers that cost 2 BP
(4) Land bombers that cost 3 BP
(5) Land/strategic bombers that cost 4 BP
(6) Naval air that cost 2 BP
(7) Naval air that cost 3 BP
(8) Naval air that cost 4 BP
(9) ATR that cost 3 BP
(10) ATR that cost 4 BP
(11) Carrier air units (sorted by class)

I'm sorry, I could have thought about this earlier, but CVP come in 3 force pool too, according to their cost. 0BP, 1 BP and 2 BP, and it is important to sort them out with this cost.

I deleted the rest, as I have already answered this.

However, I'd add that I think that such a dialog / Form, can also be useful at other moments in the game, in fact, it could be useful to have it each time that the player wants to look at the force pools. Whether for building, or for assessing the enemy's potential. CWiF alreay allow for force pool observing, maybe your new dialog could be used there too.

Cheers !

< Message edited by Froonp -- 10/2/2005 3:32:12 AM >

(in reply to Shannon V. OKeets)
Post #: 134
RE: MWIF Game Interface Design - 10/2/2005 5:07:37 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
quote:

ORIGINAL: Froonp
quote:

ORIGINAL: Shannon V. OKeets
The rows for air units will be:
(1) Fighters that cost 2 build points (BP - assumes pilots are built separately)
(2) Fighters that cost 3 BP
(3) Land bombers that cost 2 BP
(4) Land bombers that cost 3 BP
(5) Land/strategic bombers that cost 4 BP
(6) Naval air that cost 2 BP
(7) Naval air that cost 3 BP
(8) Naval air that cost 4 BP
(9) ATR that cost 3 BP
(10) ATR that cost 4 BP
(11) Carrier air units (sorted by class)

I'm sorry, I could have thought about this earlier, but CVP come in 3 force pool too, according to their cost. 0BP, 1 BP and 2 BP, and it is important to sort them out with this cost.

I deleted the rest, as I have already answered this.

However, I'd add that I think that such a dialog / Form, can also be useful at other moments in the game, in fact, it could be useful to have it each time that the player wants to look at the force pools. Whether for building, or for assessing the enemy's potential. CWiF alreay allow for force pool observing, maybe your new dialog could be used there too.

Cheers !


As to spreading out the CVPs - sure.

As to using this form elsewhere - no. I try to avoid having a screen perform multiple purposes because it confuses things. Looking at force pools to assess combat strengths (friendly and enemy) should be separate screens. Earlier suggestions from the forum members have already given me a long list of things for the production screen(s). They are for another day.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 135
RE: MWIF Game Interface Design - 10/3/2005 4:18:00 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline

quote:

As to using this form elsewhere - no. I try to avoid having a screen perform multiple purposes because it confuses things. Looking at force pools to assess combat strengths (friendly and enemy) should be separate screens. Earlier suggestions from the forum members have already given me a long list of things for the production screen(s). They are for another day.

I agree, but maybe using the same kind of layout can help making the software more user friendly.
One way or another, the player needs to have a way to look at the force pools any when during the game, not only at the production phase.
The old software (CWiF) had this, but the units in the force pools were only viewable through a lone row of counters. I was thinking that your form with multiple tabs and ultiple rows could be better for that view.

(in reply to Shannon V. OKeets)
Post #: 136
RE: MWIF Game Interface Design - 10/3/2005 6:51:29 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
quote:

ORIGINAL: Froonp
quote:

As to using this form elsewhere - no. I try to avoid having a screen perform multiple purposes because it confuses things. Looking at force pools to assess combat strengths (friendly and enemy) should be separate screens. Earlier suggestions from the forum members have already given me a long list of things for the production screen(s). They are for another day.

I agree, but maybe using the same kind of layout can help making the software more user friendly.
One way or another, the player needs to have a way to look at the force pools any when during the game, not only at the production phase.
The old software (CWiF) had this, but the units in the force pools were only viewable through a lone row of counters. I was thinking that your form with multiple tabs and ultiple rows could be better for that view.


Yes, the more information at one time the better. However, there can be more than 20 units in some of the boxes so I am thinking of only having the left hand column as originally planned and then making the boxes in the other columns different sizes: small for production/repair/construction and future units, large for force pool and very large for on map. Or perhaps dynamically sized depending on where you are in the game. In the beginning there aren't that many on map units but by the end most of them are on the map. The units in the future box gets smaller every year. To display >20 counters in the largest box is now my plan. I need to work out how to use the screen "real estate" so the information is clear, clean, and maximal.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 137
RE: MWIF Game Interface Design - 10/10/2005 6:59:02 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
I have finally finished defining all the entry types for the game record log. It runs to 28 pages so I have only put a few of the entries here. If anyone wants to see the full set of definitions, send me an email (Steve@PatternDiscovery.us) and I'll send them to you in a PDF file.

=========================
Game Record Log and History File
(as of October 9, 2005)

I Overview

MWIF maintains a record log of all events that change the game state. Each record log entry is a text string, comma delimited, that records an atomic level of detail. For example, “E1512, ULMv, T1000100, P2, U199, H2010, H2011" records Entry 1512, where Player 2 Moves the Land Unit 199 from Hex 2010 to Hex 2011, as part of transaction T1000100. There are over 400 different entry types/codes that control all modifications to the starting game state. In aggregate, the record log entries progress the starting game position incrementally through the entire game to the final game position.

The record log serves as a repository for the history of a game and can be used to replay a game in its entirety. In combination with saved game files, an individual turn or impulse can be replayed. Note that each entry contains sufficient information to retract (undo) an action. What this means is that an entire game can be played backwards, starting with the end of the game and receding in reverse to the starting position. As an additional function, the record log is used for debugging the game.

Record log entries are processed by the record log entry processor (RLEP) which, for PBEM games, validates entries received through email and from eMWIF. For other modes of play, all entries are generated by MWIF itself and do not need validation. The RLEP is responsible for keeping the copies of the game residing on different computers synchronized. For security’s sake, the record log file is kept encrypted during play. After a game has been completed, it is decrypted for replay and after-action reports. During a game, a player has the ability to replay the game from his own perspective, but can not see what the opponent has done (or at least no more than he can normally see during a game).

Note that saving and restoring games is not part of the record log. Because different players can save the game on different computers, it is impossible to guarantee that the record logs are identical if they contain entries about saving games. However, each saved game contains the name of its associated record log and the most recent entry # in the record log at the time it was saved. In particular, the PBEM system expects players to have saved games that are out of sync on different computers. It uses the record log entries to bring each game up-to-date as play progresses through email.

II Structure of Record Log Entries

Each record log entry starts with its sequence number in the record log. The sequence numbers begin with 1, for selecting the mode of play, and are incremented by one for each entry thereafter and are unique. In order to retain the concept of each entry recording an atom of detail while simultaneously storing a set of entries as a logical group, transaction numbers are included. Each transaction number identifies a set of entries that happen simultaneously, and which would be nonsense if taken individually. For example, a land attack could result in units being killed, shattered, retreated and advanced. This would generate several entries in the record log, all of which would have the same transaction number. When retracting a land attack, the entire transaction has to be processed, not just an individual entry. The transaction entries begin with 1, for choosing optional rules, and are incremented by one when a new transaction occurs. They are therefore unique.

Entries are generated through the actions of the players, the AI Assistant, the AI Opponent, eMWIF, and MWIF. MWIF makes entries when it comes to a place in the sequence of play that does not involve a player’s decision (e.g., randomly selecting units from the force pools during set up). Most entries pertain to moving units, but the whole gamut of game functions are covered, from choosing the scenario, declaring war, and choosing actions, through partisans, production, and political decisions.

The four letter codes that follow the entry number identify the transformation that is being recorded. Commas are used as delimiters so the record log can be treated as a comma separated values (CSV) file. The number and types of parameters for each entry code vary. Often they contain a starting location followed by an ending location.

For example, the life cycle for a unit is: start the game in the force pool, move to the production line, from there go to the reinforcement pool, enter the game map as a reinforcement, move around the map, and finally return to the force pool when destroyed. Each one of these events is recorded in the log as a separate entry and each entry has enough information for the unit to be moved backwards through this chain of events. The phrases “location”, “old location” and “new location” can indicate a hex on the map, a sea area, or any of the various ‘pools’ of units.

III Record Log Entry Definitions (organized by World in Flames Sequence of Play)

0. Set Up
0.1 Choose mode of play
Entry #, [Mode], Mode of play code, Date, Time, Name of player who starts the game (modes of play are: solitaire, head to head, internet, and PBEM)

0.2 Choose scenario
Entry #, [Scen], Scenario # (scenarios are numbered 1 through 11)

0.3 Choose Optional Rules
Entry #, [OptR], Transaction #, Option #, On/Off, Player name (optional rule settings and who set them)

0.4 Include Players
Entry #, [AddP], Transaction #, Player name, Player #, Player alias, Add/Remove (Player names are looked up in the MWIF.INI file to determine IP addresses for Internet play and email addresses for PBEM play).
Entry #, [Adde], Transaction #, Player #, eMWIF name (different names for eMWIF refer to different ISP locations for eMWIF, as set in the MWIF.INI file).

0.5 Assign Roles (e.g., countries) to players Directly
Entry #, [ARDi], Transaction #, Player #, Role Code, Add/Remove (assign / remove a role to / from a player directly)

0.6 Assign Roles (e.g., countries) to players through Bidding
Entry #, [Bid], Bid #, Player #, Bid amount (a player’s bid for a major power)
Entry #, [ARBi], Final Bid, Player #, Bid amount, Role Code (assign a role to a player through bidding)

--------------------------


4.4.2 Port attack (s. 11.2)
Air missions
Entry #, [CAPP], Country #, Unit #, Old Location, New Location (unit flies CAP against port attack missions)
Entry #, [WSPA], Transaction #, Country #, Unit #, Old Location, New Location, Movement Points Before, Movement Points (unit flies to a way station en route to a port attack mission)
Entry#, [UAPA], Transaction #, Country #, Unit #, Old Location, New Location, Movement Points Before, Movement Points After, Air Missions Before, Air Missions After (unit flies a port attack mission, or last leg of same)
Entry #, [UAIP], Country #, Unit #, Old Location, New Location (unit flies interception/escort against or in support of port attack missions)
Search
Entry#, [PASR], Transaction #, MWIF, Axis Search #, Axis Die Roll Modification, Axis Roll #, Allied Search #, Allied Die Roll Modification, Allied Roll # (search rolls for port attack)
Entry#, [PASP], Transaction #, MWIF, Axis Surprise Points, Allied Surprise Points (port attack surprise points)
Entry#, [PASE], Transaction #, MWIF, Axis/Allied, Surprise Expenditure, Unit # (how surprise points are spent; unit # is if a specific target is chosen by the attacker)
[Avoid combat = 4, choose type = 4, select target = 3, inc attack col = 2, dec attack col = 2, inc air-to-air = 2, dec air-to-air = 2, inc anti-air = 2, dec anti-air = 2]
Air-to-air combat
Entry#, [ACRd], Transaction #, Air Combat Round # (initiate air-to-air combat round)
Entry#, [ACIU], Transaction #, Unit #, Fighter or Bomber (include unit in air combat)
Entry#, [ACFP], Transaction #, Country #, Unit #, Position # (position fighter for air combat)
Entry#, [ACBP], Transaction #, Country #, Unit #, Position # (position bomber for air combat)
Entry#, [ACAu], Transaction #, MWIF, Unit # (bomber cleared through automatically because there are no enemy fighters)
Entry#, [ACOd], Transaction #, MWIF, Axis Air-to-air Strength, Allied Air-to-air Strength, Axis Odds, Allied Odds (air combat odds)
Entry#, [ACRx], Transaction #, MWIF, Axis Roll #, Axis Result, Modified Result (air combat by Axis)
Entry#, [ACRl], Transaction #, MWIF, Allied Roll #, Allied Result, Modified Result (air combat by Allied)
Entry#, [ACAC], Transaction #, Country #, Unit #, Old Location, New Location (bomber cleared through on AC result)
Entry#, [ACDC], Transaction #, Country #, Unit #, Old Location, New Location (bomber cleared through on DC result)
Entry#, [ACAX], Transaction #, Country #, Unit #, Old Location, New Location (unit killed on an AX result)
Entry#, [ACDX], Transaction #, Country #, Unit #, Old Location, New Location (unit killed on a DX result)
Entry#, [ACAA], Transaction #, Country #, Unit #, Old Location, New Location (unit aborted on an AA result)
Entry#, [ACDA], Transaction #, Country #, Unit #, Old Location, New Location (unit aborted on a DA result)
Entry#, [ACBo], Transaction #, Country #, Bouncing Unit #, Bounced Unit # (bounce combat chosen)
Entry#, [PLiv], Transaction #, MWIF, Unit # (pilot lives)
Entry#, [CLiv], Transaction #, MWIF, Unit # (carrier pilot lives)
Entry#, [PDie], Transaction #, MWIF, Unit # (pilot dies)
Entry#, [CDie], Transaction #, MWIF, Unit # (carrier pilot dies)
Anti-air combat
Entry#, [PAAT], Transaction #, MWIF, Anti-Air Factors, # of Bombers (port attack anti-air table)
Entry#, [PAAR], Transaction #, MWIF, Anti-Air Roll # (port attack anti-air roll)
Air-to-sea combat
Entry#, [PATL], Transaction #, MWIF, Net Air-to-Sea Factors, # of Ships (port attack air-to-sea table)
Entry#, [PANR], Transaction #, MWIF, Air-to-Sea Roll # (port attack air-to-sea roll)
Entry#, [PAAA], Transaction #, Country #, Unit # (naval unit disrupted instead of aborted in a port attack)
Entry#, [PARB], Transaction #, Country #, Unit #, Old Location, New Location (air unit returns to base)

4.4.3 Naval air missions (s. 11.3)
Entry #, [WSNv], Country #, Unit #, Old Location, New Location (unit flies to a way station en route to a naval air mission)
Entry#, [UANv], Country #, Unit #, Old Location, New Location After, Air Missions Before, Air Missions After (air unit flies naval air mission or last leg of same)
Entry#, [KaNv], Transaction #, Unit # (Japanese declare a kamikaze attack)

4.4.4 Naval movement (s. 11.4), transport (s. 11.4.5), interception(s. 11.4.6)
[A naval move is recorded sea area by sea area - or port or sea box - but all as 1 transaction. This lets it be replayed in detail but only retracted as a transaction. Note, other possible parts of this one transaction are: (1) embarking units, (2) debarking units, (3) attempts at interception, and (4) any associated naval combat due to trying to fight through a successful interception.]

Naval movement
Entry#, [UJTF], Transaction #, Task Force #, Unit # (unit joins task force)
Entry#, [ULTF], Transaction #, Task Force #, Unit # (unit leaves task force)
Entry#, [TFMv], Transaction #, Task Force #, Old Location, New Location, Movement Points Before, Movement Points After, Range Before, Range After, Naval Moves Before, Naval Moves After (naval task force moves)
Entry#, [TFM2], Transaction #, Country #, Task Force #, Movement Points Before, Movement Points After (every unit in task force pays 2 extra movement points because of the presence of the enemy)
Entry#, [UNDM], Transaction #, Country #, Unit # (naval unit disrupted at end of move)

-----------------------


4.4.16 Land combat (s. 11.16)
Ground attack declaration
Entry#, [LAtA], Transaction #, Country #, Attacked Hex Location, Land Attacks Before, Land Attacks After (land attack announced)
Entry#, [LAtU], Transaction #, Country #, Unit # (land unit joins attack)
Entry#, [LANo], Transaction #, Country #, Notional Unit Yes/No (include or exclude notional unit)
Air missions
Entry #, [CAPu], Country #, Unit #, Old Location, New Location (unit flies CAP against ground support missions)
Entry #, [WSup], Transaction #, Country #, Unit #, Old Location, New Location, Target Location, Night Mission - Yes/No, Movement Points Before, Movement Points After (unit flies to a way station en route to a ground support mission)
Entry#, [UAup], Transaction #, Country#, Unit #, Old Location, New Location, Night Mission - Yes/No, Movement Points Before, Movement Points After (unit flies ground support or last leg of same)
Entry #, [UAIu], Country #, Unit #, Old Location, New Location (unit flies interception/escort against or in support of ground support missions)
Anti-air combat
Entry#, [upAT], Transaction #, MWIF, Anti-Air Factors, # of Bombers (ground support anti-air table)
Entry#, [upAR], Transaction #, MWIF, Anti-Air Roll # (ground support anti-air roll)
Combat support
Entry#, [LAup], Transaction #, MWIF, Air Unit #, Ground Support Factors (unit provides ground support)
Entry#, [LAAB], Transaction #, Country #, Artillery Unit # (unit provides artillery bombardment)
Entry#, [LAHQ], Transaction #, Country #, HQ Unit # (unit provides HQ support)
Entry#, [LASB], Transaction #, Country #, Naval Unit # (unit provides shore bombardment - defensive or offensive)
Combat calculations
Entry#, [LCDS], Transaction #, MWIF, Unit #, Unmodified Strength, Modified Strength (unit’s defensive strength)
Entry#, [LCAS], Transaction #, MWIF, Unit #, Unmodified Strength, Modified Strength (unit’s attack strength)
Entry#, [LCTD], Transaction #, MWIF, Total Defending Strength (total defending strength)
Entry#, [LCTA], Transaction #, MWIF, Total Attacking Strength (total attacking strength)
Entry#, [LCHR], Transaction #, MWIF, Roll #, HQ Support Succeeds/Fails (HQ support resolution)
Entry#, [LCOd], Transaction #, MWIF, Attack Odds, (land combat odds)
Combat results
Entry#, [LCTB], Transaction #, Country # or MWIF, Assault/Blitzkrieg (combat table choice; made by MWIF when assault mandatory )
Entry#, [LCRo], Transaction #, MWIF, Combat Results Table Used, Fractional Odds Probability of Success, Fractional Odds Roll #, Final Attack Odds, Land Attack Roll #, Die Roll Modification (combat die rolls)
Entry#, [LCDd], Transaction #, MWIF, Combat Results Table Used, Attacker Dead, Attacker Code, Defender Dead, Defender Code (combat results; attacker codes are: 0 = disrupted, 1 = ½ disrupted, 2 = no effect, 3 = advance, 4 = blitzkrieg; defender codes are: 0 = shattered, 1 = retreated, 2 = disrupted, 3 = ½ disrupted, 4 = no effect)
Entry#, [LCUX], Transaction #, Country #, Unit #, Old Location, New Location (unit killed in combat)
Entry#, [LCDi], Transaction #, Country #, Unit # (unit disrupted in combat)
Entry#, [LCSh], Transaction #, Country #, Unit #, Old Location, New Location (unit shattered in combat)
Entry#, [LCRe], Transaction #, Country #, Unit #, Old Location, New Location (unit retreated in combat)
Entry#, [LCAd], Transaction #, Country #, Group #, Unit #, Disrupted Yes/No, Old Location, New Location (unit advances after combat)
Entry#, [NonC], Transaction #, MWIF, Unit #, Old Location, New Location (unit destroyed because it violated non-cooperation restrictions)

=====================

There are about 450 unique entry types.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 138
RE: MWIF Game Interface Design - 10/10/2005 3:31:06 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
Here are some comments & questions about the Game Record Log you made.
Please, note that sometimes my comments & questions may be irrelevant because I may have misunderstood (or not understood at all) the scope of the Game Record Log. However, I prefer to make these comments now rather than saying nothing, as it may help.

quote:


0.4 Include Players
Entry #, [AddP], Transaction #, Player name, Player #, Player alias, Add/Remove (Player
names are looked up in the MWIF.INI file to determine IP addresses for Internet
play and email addresses for PBEM play).

Will the MWIF.INI file function as a DNS for Player names / IP address resolution ? If yes, be warned that players risk of having variable IP addresses from sessions to sessions.

quote:


0.9 Select Units et al, and Markers
(...)
Entry#, [PSel], Transaction #, MWIF, Country # (place pilot in available pool)
Entry#, [CSel], Transaction #, MWIF, Country # (place carrier pilot in available pool)

This is the first place where you mention Carrier Pilots, so my remark is made here, but it applies at numerous places in the document.
Pilot & Carrier Pilot are the same, WiF FE does not differenciate both.
Only at set up are Pilots / Carrier Pilots identificated, but then, when play is ongoing, they are the same.
I know that ADG first wanted to make them different. Is it in prevision of being able to differenciate them in the future ?

quote:


4.2.5 Call out the reserves (s. 9.6)
Entry#, [CRes], Transaction #, Country # (call out reserves)
Entry#, [URes], Transaction #, Unit #, Old Location, New Location (place reserves on
map or in force pool)

Reserves are not automatically all placed on the map, so you need to check if all were placed on the map or not. If not all were placed on the map, the player should be given the possibility to place them at the next opportunity.

quote:


4.4.2 Port attack (s. 11.2)
Search
Entry#, [PASE], Transaction #, MWIF, Axis/Allied, Surprise Expenditure, Unit # (how
surprise points are spent; unit # is if a specific target is chosen by the attacker)
[Avoid combat = 4, choose type = 4, select target = 3, inc attack col = 2, dec attack col =
2, inc air-to-air = 2, dec air-to-air = 2, inc anti-air = 2, dec anti-air = 2]

Please also note that the expenditure of surprise points is not mandatory at the moment of Search rolls. The player should be given the opportunity to spend surprise points at other (allowed) moment of the whole air to sea attack (or port attack) process.

quote:


4.4.4 Naval movement (s. 11.4), transport (s. 11.4.5), interception(s. 11.4.6)
Naval movement
Entry#, [TFM2], Transaction #, Country #, Task Force #, Movement Points Before,
Movement Points After (every unit in task force pays 2 extra movement points
because of the presence of the enemy)

It is not "2 extra movement points", it is "2 movement points".

quote:


4.4.5 Naval combat (s. 11.5)

I saw nothing about the special ASW units pre-fire (22.4.19) in the Sub combat part, and nothing about Sub-Hunters ability to force SUBs to be included in the Including units part.

quote:


4.4.14 Invasions (s. 11.14)
Entry#, [IAtt], Transaction #, Country #, Transported Unit #, Old Location, New
Location, Land Moves Before, Land Moves After, Land Attacks Before, Land
Attacks After (unit invades a coastal hex)

Please note that invasions are only possible at eligible coastal hexes, not all coastal hexes.

quote:


4.4.15 Paradrops (s. 11.15)
Entry#, [ACPd], Transaction #, Country #, Air Cav Unit #, Old Location, New Location,
Night Mission - Yes/No, Movement Points Before, Movement Points After, Air
Missions Before, Air Missions After (air cav unit flies paradrop mission)

Air Cav Units ? I thought they were out of MWiF ? Am I wrong ?

quote:


5. End of Turn Stage
5.1 Partisans (s. 13.1)
Entry#, [PaUC], Transaction #, MWIF, Partisan Unit #, Naval Unit #, Old Country #,
New Country # (naval unit changes control from one country to another because
of overrun by partisans)

Please note that Partisans doesn't capture ships, they destroy them instead.
As side note about that control change matter, will MWiF change the color of the ship counter captured by another country, or will the ship counter will stay of the original color ? In other words, will there by Roma BB colored Olive Drab or Deep blue ?

quote:


5.7 Turn (final) reorganization for face-down units (s. 13.5)
Entry#, [OilB], Transaction #, Country #, Oil Source Location (build oil deport)

"Depot", not "Deport".

quote:


5.11 Build units (s. 13.6.5)
Convert units
Entry#, [BldH], Transaction #, Country #, Old Unit #, Heavy Weapons Unit #, Hex
Location (convert a unit to a heavy weapons unit)

As for the Air Cav, I thought Heavies were out of MWiF. But maybe you keep those entries for the future ???


< Message edited by Froonp -- 10/10/2005 3:32:49 PM >

(in reply to Shannon V. OKeets)
Post #: 139
Interface Design for US Entry - 10/10/2005 5:26:56 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
Here is an idea / wish for the US Entry Markers picking.

I would like that the Dialog for picking US Entry Markers to show to the picking player the average value of the pool, along with the fixed values of the averages of the 40, 41, 42 & 43 pools.

I'm not sure it is completely legal, it may be interesting to check before.

I would have prefered the dialog to show the actual markers, sorted by value, rather than the averages, but I suspect this is even less legal, I don't know.

Regards

(in reply to Froonp)
Post #: 140
RE: Interface Design for US Entry - 10/10/2005 5:35:29 PM   
c92nichj


Posts: 440
Joined: 1/14/2005
Status: offline
This would open up for cheating as you could deduce what chits your opponent had been drawing, which should be hidden from you.

(in reply to Froonp)
Post #: 141
RE: Interface Design for US Entry - 10/10/2005 5:42:46 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
That's what I think too, but on the other hand, there are dozens of counters in the cup of US Entry Markers, so it is hard to notice the one who was drawn. Moreover, only the picking player could see them, before picking, and could no more after picking.
That's why I thought about the average values.

Now that I think about it deeper I realize that what a player wants to know is the average value of the Markers left in the cup before doing an action that will lead to an US entry chit be drawn.

Is it possible to have that ? I guess not...

Another way of doing it would be to show in the US Entry Dialog the average value of the Markers currently inside the cup, so that any player can come and see it if he wants, prior to doing some action that will lead to an US Entry Roll.

(in reply to c92nichj)
Post #: 142
RE: Interface Design for US Entry - 10/10/2005 5:48:22 PM   
c92nichj


Posts: 440
Joined: 1/14/2005
Status: offline
But since the same pool is used for the garrision values for USSR/Germany you could then calculate what chits your opponents have. I'm not saying that it is easy but it probably could be done

(in reply to Froonp)
Post #: 143
RE: Interface Design for US Entry - 10/10/2005 6:19:05 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
Do you think that if the average value was displayed, it would allow for cheating ?

On the over hand, Hitler, Mussolini & Tojo weren't knowing the "price" of their actions when they decided to declare war to someone, or to conquer a Chinese city.

But it is a thing I always wanted to know when playing WiF, that is the "price" of things you do regarding US Entry.

(in reply to c92nichj)
Post #: 144
RE: Interface Design for US Entry - 10/10/2005 6:58:14 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
quote:

ORIGINAL: c92nichj
But since the same pool is used for the garrision values for USSR/Germany you could then calculate what chits your opponents have. I'm not saying that it is easy but it probably could be done


I haven't found the code for these yet but I expected to make the US Entry chits separate from the USSR/Germany garrison chits. It is a trivial thing for the computer to have two separate pools for drawing chits and I see no logical reason these two pools should be intertwined.

As to the discussion for 'seeing' what chits are yet to be drawn I would give an emphatic No. The purpose of the entire chit drawing exercise is to leave the player with doubt as to what the political situation is - just as it was pretty much an unknown to the historical governments. Though this is always aggravating to the player, that is its purpose. Given even the smallest morsal of information, the player could simply ask at every opportunity for that morsal to be updated and thereby develop a complete picture.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to c92nichj)
Post #: 145
RE: MWIF Game Interface Design - 10/10/2005 7:23:51 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
quote:

ORIGINAL: Froonp
Here are some comments & questions about the Game Record Log you made.
Please, note that sometimes my comments & questions may be irrelevant because I may have misunderstood (or not understood at all) the scope of the Game Record Log. However, I prefer to make these comments now rather than saying nothing, as it may help.
quote:


0.4 Include Players
Entry #, [AddP], Transaction #, Player name, Player #, Player alias, Add/Remove (Player
names are looked up in the MWIF.INI file to determine IP addresses for Internet
play and email addresses for PBEM play).

Will the MWIF.INI file function as a DNS for Player names / IP address resolution ? If yes, be warned that players risk of having variable IP addresses from sessions to sessions.

The INI will be used for that purpose but the player can use multiple aliases. The only real restriction is that he won't be able to play two games simultaneously using the same name with different associated IP addresses.
quote:


quote:


0.9 Select Units et al, and Markers
(...)
Entry#, [PSel], Transaction #, MWIF, Country # (place pilot in available pool)
Entry#, [CSel], Transaction #, MWIF, Country # (place carrier pilot in available pool)

This is the first place where you mention Carrier Pilots, so my remark is made here, but it applies at numerous places in the document.
Pilot & Carrier Pilot are the same, WiF FE does not differenciate both.
Only at set up are Pilots / Carrier Pilots identificated, but then, when play is ongoing, they are the same.
I know that ADG first wanted to make them different. Is it in prevision of being able to differenciate them in the future ?

Once the game has gotten past the set up phase, all pilots are the same.
quote:


quote:


4.2.5 Call out the reserves (s. 9.6)
Entry#, [CRes], Transaction #, Country # (call out reserves)
Entry#, [URes], Transaction #, Unit #, Old Location, New Location (place reserves on
map or in force pool)

Reserves are not automatically all placed on the map, so you need to check if all were placed on the map or not. If not all were placed on the map, the player should be given the possibility to place them at the next opportunity.

The sequence of entry definitions are for convenience of finding them in the document. They are written to the log whenever the matching action occurs during a game.
quote:


quote:


4.4.2 Port attack (s. 11.2)
Search
Entry#, [PASE], Transaction #, MWIF, Axis/Allied, Surprise Expenditure, Unit # (how
surprise points are spent; unit # is if a specific target is chosen by the attacker)
[Avoid combat = 4, choose type = 4, select target = 3, inc attack col = 2, dec attack col =
2, inc air-to-air = 2, dec air-to-air = 2, inc anti-air = 2, dec anti-air = 2]

Please also note that the expenditure of surprise points is not mandatory at the moment of Search rolls. The player should be given the opportunity to spend surprise points at other (allowed) moment of the whole air to sea attack (or port attack) process.

quote:


4.4.4 Naval movement (s. 11.4), transport (s. 11.4.5), interception(s. 11.4.6)
Naval movement
Entry#, [TFM2], Transaction #, Country #, Task Force #, Movement Points Before,
Movement Points After (every unit in task force pays 2 extra movement points
because of the presence of the enemy)

It is not "2 extra movement points", it is "2 movement points".

quote:


4.4.5 Naval combat (s. 11.5)

I saw nothing about the special ASW units pre-fire (22.4.19) in the Sub combat part, and nothing about Sub-Hunters ability to force SUBs to be included in the Including units part.

You are confusing when the entries can be written with the entry definitions themselves. I see these as distinctly separate items. There are: (1) the actions the player can take, and (2) the restrictions imposed by the rules on when he can take those actions. There is virtually nothing in the entry definition document about the latter. In the case of prefire ASW combat, for example, the program knows whether the option is in effect and can perform the prefire routine for surface and sub combat but not air-to-sea combat based on that knowledge. In the end the entry written to the record log can use the same definition.
quote:


quote:


4.4.14 Invasions (s. 11.14)
Entry#, [IAtt], Transaction #, Country #, Transported Unit #, Old Location, New
Location, Land Moves Before, Land Moves After, Land Attacks Before, Land
Attacks After (unit invades a coastal hex)

Please note that invasions are only possible at eligible coastal hexes, not all coastal hexes.

quote:


4.4.15 Paradrops (s. 11.15)
Entry#, [ACPd], Transaction #, Country #, Air Cav Unit #, Old Location, New Location,
Night Mission - Yes/No, Movement Points Before, Movement Points After, Air
Missions Before, Air Missions After (air cav unit flies paradrop mission)

Air Cav Units ? I thought they were out of MWiF ? Am I wrong ?

I have included them in the record log for completeness - I will not be coding them for MWIF product 1.
quote:


quote:


5. End of Turn Stage
5.1 Partisans (s. 13.1)
Entry#, [PaUC], Transaction #, MWIF, Partisan Unit #, Naval Unit #, Old Country #,
New Country # (naval unit changes control from one country to another because
of overrun by partisans)

Please note that Partisans doesn't capture ships, they destroy them instead.
As side note about that control change matter, will MWiF change the color of the ship counter captured by another country, or will the ship counter will stay of the original color ? In other words, will there by Roma BB colored Olive Drab or Deep blue ?

Section 13.1 on partisans refers to section 11.11.6 on overrun which does not differentiate between overruns by partisans or regular enemy land units.
quote:


quote:


5.7 Turn (final) reorganization for face-down units (s. 13.5)
Entry#, [OilB], Transaction #, Country #, Oil Source Location (build oil deport)

"Depot", not "Deport".

quote:


5.11 Build units (s. 13.6.5)
Convert units
Entry#, [BldH], Transaction #, Country #, Old Unit #, Heavy Weapons Unit #, Hex
Location (convert a unit to a heavy weapons unit)

As for the Air Cav, I thought Heavies were out of MWiF. But maybe you keep those entries for the future ???


This document is intented primarily for myself so that I know how to write out the entries and how to read them back in. It also serves me well as a task list for the project. For each entry there needs to be code to: (1) write the entry, (2) read the entry, (3) make the change to the dynamic game variables - the game state, (4) validate that the change can be made legally - according to the rules, and (5) provide the player with the ability to implement and see the change - the game interface. I expect this document to undergo quite a few corrections as I proceed to implement it into code.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Froonp)
Post #: 146
RE: MWIF Game Interface Design - 10/10/2005 8:05:37 PM   
c92nichj


Posts: 440
Joined: 1/14/2005
Status: offline
quote:

The INI will be used for that purpose but the player can use multiple aliases. The only real restriction is that he won't be able to play two games simultaneously using the same name with different associated IP addresses.

Will I be able to play the same PBEM game using two different computers? Forexample I might want to make some moves at my home desktops and send them off. Next morning I would do some moves on my laptop when on the train to work?

(in reply to Shannon V. OKeets)
Post #: 147
RE: Interface Design for US Entry - 10/10/2005 9:17:50 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
quote:

I haven't found the code for these yet but I expected to make the US Entry chits separate from the USSR/Germany garrison chits. It is a trivial thing for the computer to have two separate pools for drawing chits and I see no logical reason these two pools should be intertwined.

Maybe you could ask Harry, because it has tremendous ramifications to do that.
In the past, there were USSR Entry Chit, and they disappeared. For me it is intentionnal to have all neutrality & non aggression pacts using US Entry Markers, and you should not change that.
The more neutrality pacts there are in game, the more US Entry Markers are drawn, and the more the USA will higher their US entry level because less US Entry Markers will be in the game and thos of next year will enter play sooner.
I think this is intentional, and so think you should not change it.


< Message edited by Froonp -- 10/10/2005 9:27:20 PM >

(in reply to Shannon V. OKeets)
Post #: 148
RE: MWIF Game Interface Design - 10/10/2005 9:19:22 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
quote:

Once the game has gotten past the set up phase, all pilots are the same.

There are references to Carrier Planes Pilots in your document in others parts, not only in the Setup part.

(in reply to Shannon V. OKeets)
Post #: 149
RE: MWIF Game Interface Design - 10/10/2005 9:25:18 PM   
Froonp


Posts: 7995
Joined: 10/21/2003
From: Marseilles, France
Status: offline
quote:

Section 13.1 on partisans refers to section 11.11.6 on overrun which does not differentiate between overruns by partisans or regular enemy land units.

Yes it does.
From the rules at ADG website (and written RAW7 page 25) :
11.11.6 Overruns
Overrunning naval units
"If you roll a ‘5’ or higher, you keep control of the unit. If you roll a ‘1’, the enemy major power takes control of it until destroyed (option 46: partisans destroy naval units instead of taking control). Place it in the Repair pool. On a roll of ‘2’ ~ ‘4’, it is destroyed. (Options 9 & 28: Any carrier plane (and its pilot) suffer the same fate as a CV it is on.)."

(in reply to Shannon V. OKeets)
Post #: 150
Page:   <<   < prev  3 4 [5] 6 7   next >   >>
All Forums >> [New Releases from Matrix Games] >> World in Flames >> RE: MWIF Game Interface Design Page: <<   < prev  3 4 [5] 6 7   next >   >>
Jump to:





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
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts


Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

2.203