MWIF Game Interface Design

World in Flames is the computer version of Australian Design Group classic board game. World In Flames is a highly detailed game covering the both Europe and Pacific Theaters of Operations during World War II. If you want grand strategy this game is for you.

Moderator: Shannon V. OKeets

User avatar
c92nichj
Posts: 345
Joined: Fri Jan 14, 2005 1:15 pm
Contact:

RE: Interface Design for US Entry

Post by c92nichj »

This would open up for cheating as you could deduce what chits your opponent had been drawing, which should be hidden from you.
User avatar
Froonp
Posts: 7998
Joined: Tue Oct 21, 2003 8:23 pm
Location: Marseilles, France
Contact:

RE: Interface Design for US Entry

Post by Froonp »

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.
User avatar
c92nichj
Posts: 345
Joined: Fri Jan 14, 2005 1:15 pm
Contact:

RE: Interface Design for US Entry

Post by 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
User avatar
Froonp
Posts: 7998
Joined: Tue Oct 21, 2003 8:23 pm
Location: Marseilles, France
Contact:

RE: Interface Design for US Entry

Post by Froonp »

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. [:)]
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Interface Design for US Entry

Post by Shannon V. OKeets »

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.
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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".
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.
User avatar
c92nichj
Posts: 345
Joined: Fri Jan 14, 2005 1:15 pm
Contact:

RE: MWIF Game Interface Design

Post by c92nichj »

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?
User avatar
Froonp
Posts: 7998
Joined: Tue Oct 21, 2003 8:23 pm
Location: Marseilles, France
Contact:

RE: Interface Design for US Entry

Post by Froonp »

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.
User avatar
Froonp
Posts: 7998
Joined: Tue Oct 21, 2003 8:23 pm
Location: Marseilles, France
Contact:

RE: MWIF Game Interface Design

Post by Froonp »

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.
User avatar
Froonp
Posts: 7998
Joined: Tue Oct 21, 2003 8:23 pm
Location: Marseilles, France
Contact:

RE: MWIF Game Interface Design

Post by Froonp »

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.)."
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: Froonp
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.)."
Oops. You're right.
Steve

Perfection is an elusive goal.
User avatar
Mziln
Posts: 667
Joined: Mon Feb 09, 2004 5:36 pm
Location: Tulsa Oklahoma

RE: MWIF Game Interface Design

Post by Mziln »

Will transactions be used for the Supprise Impulse and Weather?
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: c92nichj
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?

I am not precisely sure how Matrix handles security for making copies of a game. In any event, you will need to transfer related game files: saved game, record log, etcetera from one computer to the other to keep them in sync. When the program is released, the procedure will be documented for moving a game-in-progress files from one computer to another.

When the program starts up it goes through the security procedure internally and then brings up the screen I posted on this thread last month. If you select a saved game, then the program uses the local INI file to establish IP and email addresses. I could do this either of two ways: (1) read the INI file, or (2) read the saved game file. I prefer the former because it is then consistent with the process for setting up a new game. Though I guess arguments could be made for both cases. Whatever, it will be doable, provided Matrix's security system doesn't get in the way. Of course, you could always buy two copies ....
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: Mziln
Will transactions be used for the Supprise Impulse and Weather?

If an action is an independent action, then it won't have a transaction number. If two or more actions are interdependent, then a transaction number will be created to tie them together. The primary purpose of the transaction number is to enable the program to play the game in reverse. It is essential to undo action sets (i.e., transactions) that are intrinsically linked. As a simple example, when you overrun using a 2 unit stack, then the movement of the 2 units will be written as separate entries in the record log, as will the death of the units being overrun. These all occur simlutaneously so they need a linking transaction number.

I may have errored on the side of using transaction numbers when they aren't needed. When I get to the coding this up I'll check them all again.

If surprise arises when a country declares war, then that flag is set for the impulse for Country A surprises Country B. Except for the US, the declaration of war is a stand alone action. When playing the game in reverse, the flag for surprise would remain set until the game regresses to the declaration of war entry, at which time the surprise flag would be turned off. The US declarations of war are different. Transactions are needed because they are "attempts to declare war" and the associated die rolls and consequences are intrinsically linked to the declaration attempt.

I guess I have to make the weather a transaction (it isn't presently). The linked action(s) is that units can be destroyed when lakes freeze or unfreeze.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Interface Design for US Entry

Post by Shannon V. OKeets »

ORIGINAL: Froonp
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.

Ok, I'll leave it as one common pool - though the logic still eludes me. My bet is that it relates to ADG not wanting to print extra counters.

On a more interesting aspect of entry markers, does anyone have any ideas about how best to display them? I can always just go with a simple 'pool' view but it seems to me we might come up with something better for the USSR - Germany border (as one example). Something that is visible when purusing the map would be nice, so you can assess the relative frontline strengths of both the forces present and the markers at the same time. What should be shown when? And where should it be displayed?
Steve

Perfection is an elusive goal.
User avatar
Mziln
Posts: 667
Joined: Mon Feb 09, 2004 5:36 pm
Location: Tulsa Oklahoma

RE: Interface Design for US Entry

Post by Mziln »

Since all common entry markers (USA entry markers, USA tension markers, and Neutrality pact markers) are only to be viewed by their owners.

It would probably be best to display them like the owing players convoys. Using
larger text or somthing to diferentiate between the convoys.

Have them on your common border being affected and viewable only by their repective owners.
Your common border with another major power consists of every hex you (or your aligned minor countries) control within 3 hexes and/or hex-dots of a hex controlled by the other major power (or its aligned minor countries). Hexes on the American, Asian or Pacific maps, and off-map hexes, still count as only 1 hex for this purpose.



Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Interface Design for US Entry

Post by Shannon V. OKeets »

ORIGINAL: Mziln
Since all common entry markers (USA entry markers, USA tension markers, and Neutrality pact markers) are only to be viewed by their owners.

It would probably be best to display them like the owing players convoys. Using
larger text or somthing to diferentiate between the convoys.

Have them on your common border being affected and viewable only by their repective owners.
Your common border with another major power consists of every hex you (or your aligned minor countries) control within 3 hexes and/or hex-dots of a hex controlled by the other major power (or its aligned minor countries). Hexes on the American, Asian or Pacific maps, and off-map hexes, still count as only 1 hex for this purpose.

You raised some new issues about the interface that I would like hear more opinions about.

First, using the common border is a good idea, but I still have questions.

Let's start by deciding whether we are going to show each counter separately or some kind of a summary. To take an example in hand for discussion purposes, in one of the scenarios Germany starts with 7 offensive markers and the USSR has 4 defensive and 1 offensive markers. I could either make 7 German and 5 USSR markers or 1 German and 2 USSR markers. I could also reduce the USSR to a single marker that showed both offensive counts and defensive counts. When playing, a player will know how many markers the enemy has on the border. Does he also know whether they are offensive or defensive? The owning player too has only limited knowledge at times, doesn't he? There are also the USSR markers that serve as reserve build points. How much of their information is visible to the players?

Assuming we know what we are going to show to whom and whether it will be details or summary, we need to decide on where to show it. The common border area is pretty well defined for the USSR but for the USA there are all those oceans in the way. How about for the USA entry markers we place them somewhere near the US. For instance, in the ocean near Hawaii seems like a good place for the Japanese tension and entry pools. They just kind of float there and whenever a player wants to look at them, he moves the detailed map view to that location. This is simpler than using a menu to select a separate viewing screen that later has to be closed to return to the detailed map. For the German/Italian pools, they could be in the Atlantic, somewhere near the east coast of the US. Again, floating in the ocean where they won't be in the way of anything (i.e., units and sea boxes). These ocean areas are big, so even a dozen markers will fit with little problem. After all, at most the markers will simply be a list of numbers with a count and sum (e.g., 0, 0, 1, 2, 2, 4, 5; 7 markers; sum = 14). And throw in a few text titles too. Small stuff.

This approach might work for the Japanese/USSR border too, if I can find a large enough sea area to use. It probably won't matter that much if it is a little bit off shore.

The German/USSR border is difficult though. There is no large sea area to move this information to. The Baltic is already going to be crowded with 10 sea boxes (5 for each side), so using a sea area is out. That leaves the land border which is likely to be crowded with units, especially when this information becomes most important - the impending outbreak of war between Germany and the USSR. I could find an open place for it right in the border areas but that would have to be redefined all the time as players reposition units. It also would be in the way when positioning units (e.g., trying to see the underlying terrain). Of course its visibility could be toggled off and on but that makes it different from the other marker displays, and I like a uniform design for things that are similar. How about just using Estonia for the display? It isn't on the border proper and usually is void of units. I could (reluctantly) make it possible to toggle it on and off, should the USSR player want to position units there.

Anyway, I have raised a bunch of issues about the design for these suckers, what do you all think?
Steve

Perfection is an elusive goal.
User avatar
c92nichj
Posts: 345
Joined: Fri Jan 14, 2005 1:15 pm
Contact:

RE: Interface Design for US Entry

Post by c92nichj »

This is simpler than using a menu to select a separate viewing screen that later has to be closed to return to the detailed map.

I think that the menu item Info-Neutrality pacts (CTRL-J) as was used in the beta works perfectly. I wouldn't want chits in estonia or other land hexes(or sea areas) in the event of a sitz it is not impossible that the USSR want to have a unit or two in Estonia.
But above all I think that there are a lot more items that of more importannce to code than how to display the neutrality pacts.
User avatar
Mziln
Posts: 667
Joined: Mon Feb 09, 2004 5:36 pm
Location: Tulsa Oklahoma

RE: Interface Design for US Entry

Post by Mziln »

Since USA entry markers are only incremented/decremented other players take certain actions.

While USA tension markers are only incremented/decremented during the US Entry stage where the USA performs actions or attemtps to declare war.

The current WiF way works best for USA entry chits.



As for Neutrality pact markers and Garrison values that could be viewed by the owning player I would prefer to either be shown on a land mass on the global map only or as WiF displayed it. Defensive entry markers are face up and Offensive entry markers are face down.

I agree display of the neutrality pacts values is probably fine as it is.

User avatar
mlees
Posts: 2263
Joined: Sat Sep 20, 2003 6:14 am
Location: San Diego

RE: MWIF Game Interface Design

Post by mlees »

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.

Urrrm. I need clarification on this. For some reason, this stood out of the rest of the post for me...

It is my understanding, when a major power (MP) has declares war on another, the reserves are made available. They may or may not be set up by the controlling MP as he/she desires. If they are, the are afterwards treated as regular units (essentially, free and immediate builds). If they are not, they remain available as long as you are at war with another MP.

Question 1: If they are not immediately placed during the DoW phase, can they be placed at any time afterwards, whenever the controlling MP decides to activate them?

Now, in reference to the quote above, I have another question:

In the setup up for late-war scenerios, (for example the one that starts in '44) where the MP starts already at war with another MP, I assumed that the "reserves" are deemed to already have been called up, and are merely included into their respective force pool types (Infantry "Reserve" Corps are mixed with the regular Infantry Corps), and the required number are "drawn blind" and setup as per the set up chart. I assumed that you do not receive the "Reserve" units free of charge, in addition to the other units.

Question 2: Are my assumptions above correct?

I ask because, in the quoted post above, it confuses me that the player should be provided an opportunity to place the reserves "at the next opportunity", especially in scenerios other than the "Grand Campaign", and this will need to be coded into the scenerio's setup. Sorry for straying a little off topic...[:(]
Post Reply

Return to “World in Flames”