RE: MWIF Game Interface Design (Full Version)

All Forums >> [New Releases from Matrix Games] >> World in Flames



Message

Shannon V. OKeets -> RE: MWIF Game Interface Design (10/10/2005 10:45:08 PM)


quote:

ORIGINAL: Froonp

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.)."


Oops. You're right.



Mziln -> RE: MWIF Game Interface Design (10/10/2005 10:55:40 PM)

Will transactions be used for the Supprise Impulse and Weather?



Shannon V. OKeets -> RE: MWIF Game Interface Design (10/10/2005 11:05:15 PM)

quote:

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


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 ....



Shannon V. OKeets -> RE: MWIF Game Interface Design (10/10/2005 11:22:17 PM)

quote:

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.



Shannon V. OKeets -> RE: Interface Design for US Entry (10/10/2005 11:42:37 PM)

quote:

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


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?



Mziln -> RE: Interface Design for US Entry (10/11/2005 6:40:50 PM)

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.

quote:

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 -> RE: Interface Design for US Entry (10/11/2005 7:54:15 PM)

quote:

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.

quote:

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?



c92nichj -> RE: Interface Design for US Entry (10/11/2005 8:07:44 PM)

quote:

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.



Mziln -> RE: Interface Design for US Entry (10/11/2005 8:34:34 PM)

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.




mlees -> RE: MWIF Game Interface Design (10/11/2005 10:03:03 PM)

quote:

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...[:(]



mlees -> RE: MWIF Game Interface Design (10/11/2005 10:19:46 PM)

quote:

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


quote:

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 ....


I assume the gentlemens question was also addressing the ability to connect to your opponent when IP network addresses change (they are usually controlled by your ISP provider).

Play by email should not be a problem, as Email server's usually have constant static IP addresses. A login password for player verification is usually the means for security in this type of play.

However, direct connect, "live", over the internet games, if this is offered, is trickier. If a game (which may take several days to complete) of this type is saved somewhere midpoint, and the next day my IP address changes, how do I reconnect? Is there going to be some server somewhere for people to "find" and "refind" opponents? I think that c92nichj was wondering about how that works...



Shannon V. OKeets -> RE: MWIF Game Interface Design (10/11/2005 11:23:05 PM)


quote:

ORIGINAL: mlees

quote:

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


quote:

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 ....


I assume the gentlemens question was also addressing the ability to connect to your opponent when IP network addresses change (they are usually controlled by your ISP provider).

Play by email should not be a problem, as Email server's usually have constant static IP addresses. A login password for player verification is usually the means for security in this type of play.

However, direct connect, "live", over the internet games, if this is offered, is trickier. If a game (which may take several days to complete) of this type is saved somewhere midpoint, and the next day my IP address changes, how do I reconnect? Is there going to be some server somewhere for people to "find" and "refind" opponents? I think that c92nichj was wondering about how that works...


Well, it is not written into code yet, so the question becomes "How should it work?".

Let's take a simple example, (I always like to start with the easiest one possible), two guys want to play a game over the internet. They have to communicate that desire to each other somehow, probably either by phone or email. Player A starts the game, selecting the scenario and optional rules. This could also include deciding who is playing what countries if bidding is not being used. As part of the set up process, player A needs to identify who the players are, refering to names (aliases) in the INI file. The INI file has an IP address associated with each player name. If player A doesn't know the IP address of player B then the easiest way to handle that is for player B to provide it at the time they decide to play. If that is not possible (because of dynamic IP addressing), then player A could use email to acquire it when they are both ready to start playing. Either way, both players need to have both IP addresses in their INI file. Player A saves the game (in its startup phase) and sends a copy to player B. Player B installs the saved game and they now both have the same position. An MWIF communication link needs to be established, after which bidding could occur - or the game could start with the first player's initiative.

The key elements here are:
(1) the INI files contain the player names (aliases) and associated IP addresses,
(2) both players are running the same saved game, and
(3) the communication link is established between the 2 running copies of MWIF using the IP addresses.

More players means more IP addresses and more communication links. If a game is halted and restarted several days later, then the same process is used. When restarting, everyone should have the same saved game, so that step can be eliminated.

The case of running the program on a home computer one evening and then again the next day on a portable while travleing shouldn't make any difference. The same 3 steps listed above have to be performed.

If there are potential problems with this conceptual design, now would be a great time to tell me.



Shannon V. OKeets -> RE: MWIF Game Interface Design (10/11/2005 11:33:29 PM)

quote:

ORIGINAL: mlees
quote:

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...[:(]


There are two types of reserves for the USSR. Some are only available when the USSR is at war with Germany. When war is declared, reserves become available. This always occurs during the start of an impulse, so their placement is akin to putting reinforcements on the map. Should the player decide not to place all his reserves at that time then I assume they go on the production wheel to arrive as reinforcements next turn. This is the common procedure for other reinforcements that can not be immediately placed on the map for one reason or another. I certainly don't see the player being able to put them down at the start of one of his own impulses later - like pulling a rabbit out of his hat.

The scenario rules are very explicit as to who has called out their reserves. The merging of the reserve units into the other pools is performed as you described.



Shannon V. OKeets -> RE: Interface Design for US Entry (10/11/2005 11:49:36 PM)

quote:

ORIGINAL: c92nichj
quote:

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.


This would only take 2 or 3 hours to code.

I worry about the invisible elements of MWIF and novices. People who have played WIF over the board have had a lot of tactile and visual feedback on entry chits and neutrality pact markers being placed on borders. We know about them and all their implications. We can make decisions about them (offensive or defensive?). To the novice player, whose first exposure to the WIF game system is MWIF, these can be very confusing. There is nothing like them in any other game I have ever played. They are very abstract concepts. If we hide them from view so the player has to take direct action to find and review them, then the novice is likely to remain unaware of them. The interface for the whole political dimension of the game worries me. I want MWIF to communicate those elements clearly and concisely, so even the beginner feels he has a solid understanding of what is going on.

Code for this stuff is easy. It is just a bunch of text displays. Therefore, we can afford to spend some time coming up with a good design. I have the politics down as one of more difficult things to learn about the WIF system and I would love to make it easier for novices to understand.



Froonp -> RE: Interface Design for US Entry (10/12/2005 12:03:11 AM)

quote:

think that the menu item Info-Neutrality pacts (CTRL-J) as was used in the beta works perfectly.

I agree.
However, the dialog is (was) quite difficult to understand at first glance. A lot of columns there, and not much explanations for them. If it stay as is, it needs to have text to explain the columns entries.



Froonp -> RE: MWIF Game Interface Design (10/12/2005 12:13:27 AM)

quote:

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?

9.6 is the paragraph ruling the calling of reserves.
It is situated in the declaration of war step, so reserves are called during that step and no other. They are put on the map face-down at that step. (remember 1.1 who says "We have arranged these rules in sequence-of-play order")
It says (amongst other things) :
"You don’t have to call out all the eligible reserves at the first opportunity. Any you don’t call out are available while you are at war with a major power."

Nothing prevents the Russian for example to refrain from placing a reserve on the map. He will then be able to place it during any future enemy declaration of war step (that is before the action phase of the enemy) face down.
Needless to say that one would be crazy to do this, as being face-down is being dead if you are attacked.

I don't know why the rule is writen that way (allowing you to refrain from setting up all the reserves) but it is written that way.



mlees -> RE: MWIF Game Interface Design (10/12/2005 12:42:32 AM)


quote:

ORIGINAL: Froonp

quote:

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?

9.6 is the paragraph ruling the calling of reserves.
It is situated in the declaration of war step, so reserves are called during that step and no other. They are put on the map face-down at that step. (remember 1.1 who says "We have arranged these rules in sequence-of-play order")
It says (amongst other things) :
"You don’t have to call out all the eligible reserves at the first opportunity. Any you don’t call out are available while you are at war with a major power."

Nothing prevents the Russian for example to refrain from placing a reserve on the map. He will then be able to place it during any future enemy declaration of war step (that is before the action phase of the enemy) face down.
Needless to say that one would be crazy to do this, as being face-down is being dead if you are attacked.

I don't know why the rule is writen that way (allowing you to refrain from setting up all the reserves) but it is written that way.



Hmm. Ok. I understood the rule, then, I think. (I have only played solo. What a space eating monster!) The only reason I can think of, right now, for voluntarily not bringing in a specific unit is to avoid overstacking, or maybe you want to bring a better unit in on that city first... Maybe.



mlees -> RE: Interface Design for US Entry (10/12/2005 12:54:15 AM)

All right. Thanks for the answers to the "reserve" questions. There should be a way to make sure that the "reserve" units can be seen as unique from the other units... consider:

It is the Mar/Apr turn of 1940. The player controlling Italy DoW's France, and activates his "reserve" units. The CW, for some obscure reason, does not reciprocate with a DoW. (Maybe to set up a devastating "first strike" move to take advantage of the surprise rule.)

At the end of the the May/Jun turn, France is Vichied by a lightning German Campaign! Since Italy is now "at peace" with all other Major Powers, her "reserve" units must be returned to the force pools (if they are not destroyed). This could leave some embarassing hole in Italy's defense vs. the CW player...

Now, granted, the Italy player should have been paying attention, but anyways, being able to see (relatively easily) that a unit is a Reserve unit would be nice. I have a copy of an old CWiF version, and I know how to drag the info "kicking and screaming" out of that version... [:'(] but it can be a chore. (Looking ahead at next years force pools was already mentioned.)



Froonp -> RE: Interface Design for US Entry (10/12/2005 1:12:49 AM)

quote:

All right. Thanks for the answers to the "reserve" questions. There should be a way to make sure that the "reserve" units can be seen as unique from the other units...

What you say is mandatory, because Reserve units are out of the game when you come to peace (as you described in your example), and also because reserve units can't be scrapped.
I'm sure that it is already visible in CWiF, so I'm sure it will be in MWiF.
Cheers !
Patrice



c92nichj -> RE: Interface Design for US Entry (10/12/2005 12:28:46 PM)

quote:

At the end of the the May/Jun turn, France is Vichied by a lightning German Campaign! Since Italy is now "at peace" with all other Major Powers, her "reserve" units must be returned to the force pools (if they are not destroyed).

Italy would still be at war with Free France so she does not go neutral just because France is Vichied, in the unlikely event that France is completely conquered she will be neutral though.
And at that point the onmap reserve units would go back to the force pool enabling Italy to mobilize them once again if CW would declare war so the defence might not be that thin after all. It is a good behaviour from the German to rail down a unit or two to assist in the defence of Italy anyhow.



fuzzy_bunnyy -> RE: Interface Design for US Entry (10/14/2005 11:04:37 AM)

wow...weird thought....what would happen to Germans who railed into Italy in this example after Italy came to peace with France? would they die or just teleport back to Germany? huh.......



c92nichj -> RE: Interface Design for US Entry (10/14/2005 12:31:37 PM)

I belive they would stay where they are but they are unable to move into an hex controlled by Italy until italy becomes active again.

This are hte hexes a unit can move into.
You can move a land unit controlled by an active major power into any hex controlled by:
ï that major power and its aligned minors; or
ï another active major power on the same side (or its controlled minor countries); or
ï a major power or minor country it is at war with.



Mziln -> RE: Interface Design for US Entry (10/16/2005 5:32:17 PM)


quote:

ORIGINAL: fuzzy_bunnyy

wow...weird thought....what would happen to Germans who railed into Italy in this example after Italy came to peace with France? would they die or just teleport back to Germany? huh.......


They teleport.

13.7.3 Mutual peace

If a peace is reached, remove all forces now in each other’s territory. Put them in the nearest hex in whcih they can stack controlled by their major power or its aligned minors.




c92nichj -> RE: Interface Design for US Entry (10/17/2005 10:48:32 AM)

quote:



They teleport.

13.7.3 Mutual peace

If a peace is reached, remove all forces now in each other’s territory. Put them in the nearest hex in whcih they can stack controlled by their major power or its aligned minors.


I think each others territory refers to France and Italy and not to an allied power like Germany. Italian units in france would hence be moved out of france and french units in Italy moved out of Italy. This is also listed under the mutual peace section which only applies if the french and Italian player agrees to come to peace, ie it is not a forced peace.



Froonp -> RE: Interface Design for US Entry (10/17/2005 12:02:03 PM)

quote:

I think each others territory refers to France and Italy and not to an allied power like Germany. Italian units in france would hence be moved out of france and french units in Italy moved out of Italy. This is also listed under the mutual peace section which only applies if the french and Italian player agrees to come to peace, ie it is not a forced peace.

I think as c92nichj that "each other's" in 13.7.3 refers to the major powers agreeing to peace.

I think that the case asked by fuzzy_bunnyy is resolved using the Co-operation rule (18.1) and the Declaring War rule (9).
Reading 18.1 we learn that Italy & Germany don't cooperate anymore if one of them is neutral, which is the case fuzzy_bunnyy brang here.
18.2 then states what are the effects of not cooperating. Reading it we learn that the German units need a German HQ now to enter the home country of a friendly major power it doesn’t co-operate unless it started the step there, which is the case. Which cuold lead us to think that German units in a neutral Italy can now move freely, they jusnt can't end a step stacked with Italians.

However, 9 states that "You can’t enter a hex controlled by a neutral major power on your side", which superseeds 18.2, meaning that Germany units in a neutral Italy are stuck in the hex they are.

Which is basicaly what c92nichj said in post 172.



Mziln -> RE: Interface Design for US Entry (10/17/2005 1:59:37 PM)

Your point is well founded but 18.2 Not co-operating would not be in effect until after 13.7.3 Mutual peace has occured.

quote:

18.2 Not co-operating

A major power or minor country unit that ends any step in the home country of a friendly major power it doesn’t co-operate with is destroyed unless it started the step there or it started the step elsewhere and the unit satisfies the foreign troop commitment limit.


So the headquarters would have to already be in the country or..

You have bring in enough headquarters to satisify Foreign troop commitments all at once or the new headquarters are destroyed.



c92nichj -> RE: Interface Design for US Entry (10/17/2005 2:32:03 PM)

quote:

Your point is well founded but 18.2 Not co-operating would not be in effect until after 13.7.3 Mutual peace has occured.

The original poster asked about what happend after france was Vichied(13.7.4)/concured(13.7.1). At that point the mutual peace(13.7.3) section would not be used at all instead the section related to the specific peace settlement would be used.



Mziln -> RE: Interface Design for US Entry (10/17/2005 3:08:17 PM)

Even if you invoke 18.2 Not co-operating this is a non issue.

quote:

Units that don’t co-operate are not otherwise limited. In particular, they can:

5. trace supply through territory controlled by each other



I don't think this situation is lible to come up anyway.



Shannon V. OKeets -> RE: MWIF Game Interface Design (10/18/2005 1:45:16 AM)

I am still in the thick of setting up the game, scrapping units, and saving setups. I have received a copy of the spreadsheet for the missing scenario, named "MIssed the Bus" appropriately enough. I haven't had a chance to review it but at least I now have all 11 to type in (5 completely entered). I am starting a list of problems I encounter with the setup instructions and will send them to Harry once I have gone over all 11 in detail.

CWIF provided the ability to save setups which doesn't make a lot of sense to me. Part of the setup process is drawing units randomly from the force pools, assigning pilots to planes and then placing the units on the map. When loading in a saved setup, CWIF drew new units randomly and then assigned pilots and unit placements based on the saved setup. Since the quality of planes, especially the range, can change because of the random draw, this all seems likely to result in inferior decisions. And that could be true even given that units can be relocated after the program places them according to the saved setup.

What I propose instead is a broader capability for when the game is saved.

When the game is started the player can select various times for the game to automatically be saved, without the player having to take any action or answer any questions about the matter. The naming conventions for the files would be decided after the scenario is selected. These times would be:

(1) after deciding which units to scrap for a major power; these would be saved separately for each major power for the given scenario;

(2) after placing all of one major power's units on the map; only the placements of the non-random units (e.g., named units, TRS) would be saved;

(3) when a saved file from #2 is used to restore a position, only the non-random units would be placed on the map; all the random units would be drawn fresh and the player would choose which air units get pilots and would have to place each random unit on the map;

(4) at the end of the setup phase for all players, just before the first player declares war, starts moving units, or whatever;

(5) at the end of each impulse;

(6) at the end of each turn.

Of course the player will be able to save a game at other times. What I want to get at with the automatic saves is to remove the need for the player to remember to take an action to save a game. There are many times when playing a game that I meant to save a position but in the heat of the moment forgot. In this case saving the position after scrapping units, #1, and just before the game starts, #4, are specifically intended to avoid that problem.

#2 is intended to avoid some of the tedium with starting a game. In particular, the placement of naval units and convoy pipelines are likely to be the same every time you play a scenario. Together with #1, these will let both the novice and experienced player start the game faster. The novice would be using default scrap lists and placement of non-random units.

If you really want to get right into the action, restoring a position from a #4 save would do the trick. You would be stuck with the random draws from that save and the starting positions for the units. On the other hand, you will have passed over the need to go through those activities yet once again. This might be popular when playing solitaire.

My question to you is, as usual, whadda ya think? And, is there any need to preserve the way setups were saved under CWIF?



mlees -> RE: MWIF Game Interface Design (10/18/2005 4:34:13 AM)

A "generic" setup will be needed for novices and casual players (like me) who have not yet grasped the full finer points of strategy.

It's like chess. I know how the pieces move, but I can't plan more than a turn ahead.

I dont know if this belongs here or in the AI thread, but if you have the game engine with an ability to save each move and so forth, you can record games for tutorial purposes by your beta team uber-players!



Page: <<   < prev  4 5 [6] 7 8   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.59375