RE: MWIF Game Interface Design (Full Version)

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



Message


Sewerlobster -> RE: MWIF Game Interface Design (6/9/2010 3:09:08 AM)

quote:

ORIGINAL: Shannon V. OKeets
There is a 'hot' region around the border of the maps. When the mouse is placed over that region, the map scrolls in that direction. These regions are fairly small, but some players prefer to disable that function so more of the map is visible.
One of the reasons I have little interest in additional ways to scroll the map is that there are already many available.


This brings to mind a question I'm sure that been asked before. Are you using only one monitor when designing the game? How many playtesters are using two monitors? While I certainly don't have two hooked up to my computer, I can see how having more than one could allow for quite a few charts and other screens to be left open. As convenient as that sounds, the game's interface should feel comfortable with just one monitor.




paulderynck -> RE: MWIF Game Interface Design (6/9/2010 3:42:53 AM)

It workes fine with one monitor. Two is even better, and three is possible too. (I'm a beta tester.)




Anendrue -> RE: MWIF Game Interface Design (6/9/2010 3:48:31 AM)


quote:

ORIGINAL: SewerStarFish

quote:

ORIGINAL: Shannon V. OKeets
There is a 'hot' region around the border of the maps. When the mouse is placed over that region, the map scrolls in that direction. These regions are fairly small, but some players prefer to disable that function so more of the map is visible.
One of the reasons I have little interest in additional ways to scroll the map is that there are already many available.


This brings to mind a question I'm sure that been asked before. Are you using only one monitor when designing the game? How many playtesters are using two monitors? While I certainly don't have two hooked up to my computer, I can see how having more than one could allow for quite a few charts and other screens to be left open. As convenient as that sounds, the game's interface should feel comfortable with just one monitor.


I cannot get specific about the game. However, I use three monitors and yes the extra monitors are extremly useful. I have the main map on my 32" and the other two 21" monitors are turned 90 degrees. They side monitors hold the various forms the game uses. I can clearly see and read units across all of Western Europe and well into Russia past Moscow.




Shannon V. OKeets -> RE: MWIF Game Interface Design (6/9/2010 3:57:03 AM)

quote:

ORIGINAL: SewerStarFish

quote:

ORIGINAL: Shannon V. OKeets
There is a 'hot' region around the border of the maps. When the mouse is placed over that region, the map scrolls in that direction. These regions are fairly small, but some players prefer to disable that function so more of the map is visible.
One of the reasons I have little interest in additional ways to scroll the map is that there are already many available.


This brings to mind a question I'm sure that been asked before. Are you using only one monitor when designing the game? How many playtesters are using two monitors? While I certainly don't have two hooked up to my computer, I can see how having more than one could allow for quite a few charts and other screens to be left open. As convenient as that sounds, the game's interface should feel comfortable with just one monitor.


I did most of the development using two monitors (1280 by 1024) but the second monitor was only used for looking at the code while debugging. All the forms are designed to fit on a single 1024 by 768 monitor.

These days I am working with two 1900 by 1080monitors and it is lovely. But setting that fact aside, playing on a single monitor should be fine.

As you are obviously aware, and I state here only for clarity to others, multiple monitors let you keep helpful screens visible rather than having to bring them up when you need them. For example, when first learning the game having the various help forms visible to translate terrain types/movement costs, hex icons, explain numbers and symbols on units, display status indicators, and display the various combat tables would obviously be nice (though you could print those out individually if you didn't want to keep looking them up in the Players Manual.

Later on, as you become facile with the images and rules, having the global map and multiple datiled maps visible can be very useful.




Sewerlobster -> RE: MWIF Game Interface Design (6/9/2010 10:18:19 PM)

quote:

ORIGINAL: Shannon V. OKeets
I did most of the development using two monitors (1280 by 1024) but the second monitor was only used for looking at the code while debugging. All the forms are designed to fit on a single 1024 by 768 monitor.


Thanks, it's good to know that just one monitor will allow easy play. I just don't have the room for a multiple monitor set-up.




micheljq -> RE: MWIF Game Interface Design (6/10/2010 3:13:47 PM)

I am still using an old 19" CRT monitor, quite heavy to move, the monitor is near 10 years old. It's a NEC the image is still so sharp and nice. It's an unkilleable monitor. [:D]




Anendrue -> RE: MWIF Game Interface Design (6/10/2010 7:37:56 PM)


quote:

ORIGINAL: micheljq

I am still using an old 19" CRT monitor, quite heavy to move, the monitor is near 10 years old. It's a NEC the image is still so sharp and nice. It's an unkilleable monitor. [:D]


I really liked my old NEC's. They had better color than any LCD I have ever used. I miss them [:(].




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/3/2010 8:13:57 PM)

Here is a change I made at the suggestion of Nils.

The first difference is that all the units in the sea area are now shown (not just those included in the current round of naval combat). This is useful in making the decision about whether to avoid combat or not. There are other considerations too, where seeing all the units will be helpful when spending surprise points.

The second difference is that I changed the status indicators so they identify which units are included in the current naval combat round.

Status indicators shown here are:

1 - Topside, far left: unit movement's status. Here the two air units have flown into the sea area to provide air support and the three convoy units have sentry status (they will remain at sea automatically during the return to base phase).

2 - Topside, 2nd position from the left: Disorganized. The Japanese CL is disorganized beacuse it was used to initiate the combat.

3 - Leftside, top position: Engaged in combat. All the Japanese units are in the current naval combat round, but only the US units in the 0 + 1 + 2 sea box sections.

4 - Leftside, 2nd position from the top: initiated combat. The Japanese CL has a separate flag specifically to show that it initiated the combat.

I need to fix the US side so the naval air isn't included in the summary statistics (in the Unit Data panel below the unit list). Other that that glitch, the summary statistics are for the units included in the combat.

[image]local://upfiles/16701/710392BC2FFA44D8B1F02E8A184BCA6E.jpg[/image]




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/3/2010 10:43:56 PM)

Here is another change to an existing form. This addresses the strangeness of the rules for the activity limits imposed on the Communist Chinese. The second column is new; and I have moved the USSR column so the Communist Chinese sit between China and the USSR.

[image]local://upfiles/16701/B4327F210B8349979D7E135E88788DED.jpg[/image]

EDIT: The Communist Chinese have neither air nor naval units, so I set their activity limits for those unit types to zero for clarity.

EDIT 2: I have changed the annotation to:"** Commnist Chinese actions count against the action limits of the USSR."




Froonp -> RE: MWIF Game Interface Design (8/3/2010 11:04:34 PM)

quote:

ORIGINAL: Shannon V. OKeets
EDIT: The Communist Chinese have neither air nor naval units, so I set their activity limits for those unit types to zero for clarity.

As soon as the PatiF counters are added to the WiF FE countermix (which is what is done when you own PatiF and are willing to use those counters in normal WiF FE games), then what you wrote above is wrong.
They have planes, and they have ships. Mostly SUBs and TRS though.




Froonp -> RE: MWIF Game Interface Design (8/3/2010 11:07:35 PM)

quote:

ORIGINAL: Shannon V. OKeets

Here is another change to an existing form. This addresses the strangeness of the rules for the activity limits imposed on the Communist Chinese. The second column is new; and I have moved the USSR column so the Communist Chinese sit between China and the USSR.

[image]local://upfiles/16701/B4327F210B8349979D7E135E88788DED.jpg[/image]

Good move !!!




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/3/2010 11:11:24 PM)


quote:

ORIGINAL: Froonp

quote:

ORIGINAL: Shannon V. OKeets
EDIT: The Communist Chinese have neither air nor naval units, so I set their activity limits for those unit types to zero for clarity.

As soon as the PatiF counters are added to the WiF FE countermix (which is what is done when you own PatiF and are willing to use those counters in normal WiF FE games), then what you wrote above is wrong.
They have planes, and they have ships. Mostly SUBs and TRS though.

Ok. But since MWIF Product 1 doesn't include the Patton In Flames counters, I'll leave it as is for the first product's release.




Orm -> RE: MWIF Game Interface Design (8/4/2010 12:04:07 AM)


quote:

ORIGINAL: Froonp

quote:

ORIGINAL: Shannon V. OKeets

Here is another change to an existing form. This addresses the strangeness of the rules for the activity limits imposed on the Communist Chinese. The second column is new; and I have moved the USSR column so the Communist Chinese sit between China and the USSR.

[image]local://upfiles/16701/B4327F210B8349979D7E135E88788DED.jpg[/image]

Good move !!!

Very nice. [:)]




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/7/2010 12:04:28 AM)

I am working on redesigning how Production Planning is performed. This includes:
1 - the automatic routing of resources and build points in accordance with trade agreement (players can not change these).
2 - the automatic routing of resources to destinations and their use.
3 - reviewing the routing and use of resources.
4 - modifying the routing and use of resources.

#2 is the one I have a question about. If you have an opinion on the following, please let me know.

I am thinking of letting players assign a default destination and use for each resource. The program would use this information first in routing resources. If the resource can reach the destination, then it will perform the given 'use' if it is possible to do so. Both would have to be possible for the default to be implemented. For instance, if an oil resource was to be saved in the destination hex and it could not be because of stacking (e.g., too many oil resources saved therein from previous turns), then neither the destination nor the use would be implemented.

If the default doesn't work, then the program would try to repeat what was done the previous turn. If that can''t be done either, then the resource would sit idle in its hex of origination (In Situ).

I do not intend t otry to have the program work out optimal usage of convoys and saving oil, etc. The player will be able to use the 3rd and 4th items above for doing that.

Here is a composite of screen shots for inspiration.

[image]local://upfiles/16701/3C66CC37C238421A96AF3DE5E441FAC0.jpg[/image]




Taxman66 -> RE: MWIF Game Interface Design (8/7/2010 1:40:20 AM)

Suggestion:
If #2 fails, provide a highlighted, bold text, pop-up or some other form of high-visibility indication to let the player know there is a very good reason to perform a more detailed review.




lomyrin -> RE: MWIF Game Interface Design (8/7/2010 3:54:59 AM)

In the screenshot above the optimum assignment of convoys and resource transportation has clearly not been met and a lot of adjustments need to be made by the player, items #3 and #4 in the tables.

There also needs to be a view of the convouys used and those not used it the transport schemes.

Lars




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/7/2010 3:56:00 AM)


quote:

ORIGINAL: Taxman66

Suggestion:
If #2 fails, provide a highlighted, bold text, pop-up or some other form of high-visibility indication to let the player know there is a very good reason to perform a more detailed review.

Those resources can be identified easily by the word Idle in the Action column. Another major indicator is the number of Idle factories and/or resources in the summary statistics at the top of the form.

When I look at this page, I first check out the 3 bold numbers in the summary statistics: Producing Factories, Total Resources, and Available Build Points. That lets me know whether all is well or that something's amiss.

In practice, players tend to check out this page every so often during a turn, not just during the Production Planning phase at the end of the turn. Because of that, I prefer for the form to be 'passive' rather than 'active'. Players will not like to have to respond to a prompt every time they bring up the form. Note that as things happen from impulse to impulse during a turn, the summary statisitcs are likely to change fairly quickly. For example, DOWs, aligning minors, capturing resources or factories, moving convoys, and cutting supply paths can make a big difference.




Orm -> RE: MWIF Game Interface Design (8/7/2010 8:17:13 AM)

quote:

ORIGINAL: Shannon V. OKeets

I am working on redesigning how Production Planning is performed. This includes:
1 - the automatic routing of resources and build points in accordance with trade agreement (players can not change these).
2 - the automatic routing of resources to destinations and their use.
3 - reviewing the routing and use of resources.
4 - modifying the routing and use of resources.

#2 is the one I have a question about. If you have an opinion on the following, please let me know.

I am thinking of letting players assign a default destination and use for each resource. The program would use this information first in routing resources. If the resource can reach the destination, then it will perform the given 'use' if it is possible to do so. Both would have to be possible for the default to be implemented. For instance, if an oil resource was to be saved in the destination hex and it could not be because of stacking (e.g., too many oil resources saved therein from previous turns), then neither the destination nor the use would be implemented.

If the default doesn't work, then the program would try to repeat what was done the previous turn. If that can''t be done either, then the resource would sit idle in its hex of origination (In Situ).

I do not intend t otry to have the program work out optimal usage of convoys and saving oil, etc. The player will be able to use the 3rd and 4th items above for doing that.

Here is a composite of screen shots for inspiration.

[image]local://upfiles/16701/3C66CC37C238421A96AF3DE5E441FAC0.jpg[/image]

When a resource can't reach the default destination nor the previous turns
routing either and sits idle would it be possible to write the idle in bold so to
mark that it the status for this resource changed this turn?




brian brian -> RE: MWIF Game Interface Design (8/7/2010 4:09:08 PM)

I have a question. Does the form work currently? Can a reasonable person get production done? At some point can't a few otherwise desirable new player hand-holding features be left on the cutting room floor so we can play this game someday? It's a big complicated game and will remain that way regardless of how much effort is poured in trying to simplify it. It will never become as simple as Doom no matter how much work is done on the interface.

As to the question at hand, no I would rather not assign specific resources to specific factories. If there are 13 resources connected in a legal path with sufficient convoys to 17 factories, that is good enough for me. If the program helps me figure out how many factories I moved to Siberia and how much stored oil I have available to keep those running over and above the resource base I have left, that would be a help, yes. But I can do that on my own too.

I looked at this game's competition the other day. Speculating in the world's spot price of minerals to increase economic output to build a bunch of Axis-and-Allies type units to invade a country full of untapped minerals might appeal to somebody (Hitler himself comes to mind), but I just want to be given command of real military units and get on with the invasion already.




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/7/2010 7:55:56 PM)

quote:

ORIGINAL: brian brian

I have a question. Does the form work currently? Can a reasonable person get production done? At some point can't a few otherwise desirable new player hand-holding features be left on the cutting room floor so we can play this game someday? It's a big complicated game and will remain that way regardless of how much effort is poured in trying to simplify it. It will never become as simple as Doom no matter how much work is done on the interface.

As to the question at hand, no I would rather not assign specific resources to specific factories. If there are 13 resources connected in a legal path with sufficient convoys to 17 factories, that is good enough for me. If the program helps me figure out how many factories I moved to Siberia and how much stored oil I have available to keep those running over and above the resource base I have left, that would be a help, yes. But I can do that on my own too.

I looked at this game's competition the other day. Speculating in the world's spot price of minerals to increase economic output to build a bunch of Axis-and-Allies type units to invade a country full of untapped minerals might appeal to somebody (Hitler himself comes to mind), but I just want to be given command of real military units and get on with the invasion already.

I am working on two tasks with the Production Planning form: fixing bugs and improving the interface. These go hand-in-hand since some of the bugs are related to the design of the player interface (data structures in particular). I do not consider the work I am doing on this to be "buffing and polishing".

Probably the loudest complaint about CWIF was routing resources, not the automated system, which worked/works quite well, but the mechanism by which players modified the automated results (personalized the routes). That is the problem I am addressing. My solution is to make something easy for players to understand and use. Based on years of programming experience, I know that if the design is easy to understand and use, then coding it will be vastly simpler and time will not be wasted repeatedly revising the design and the code.

===

This morning I decided that there needs to be a "default route" and "previous route" also saved as part of the data structure. These are only necessary for resources that are shipped overseas.

Perhaps I should emphasize here that shipping resources by rail is totally automated and requires no effort on the player's part (or on my part since that code already exists and works perfectly - to the best of my knowledge, which is considerable having studied and tested it for the past 5 days).

===

I am thinking about enabling the player to filter the list of resources and factories so instead of a long list, he can see just those that might require attention. For instance: only show idle resources and factories with excess capacity. Oil versus non-oil resources is another filter. Shipped overseas is another.

I am working towards envisioning of a form for seeing all convoys currently in use, idle convoys, idle resources, and factories with excess capacity. CWIF had a form that sort of addressed this issue (called Convoy Info), but that form lacked an insert map. Besides displaying current status, I want to use the form for modifying destinations and overseas routes.




Orm -> RE: MWIF Game Interface Design (8/7/2010 10:22:33 PM)

For me it is important that I can always route a specific resource to a specific factory. And that my order to do so has, and keeps, priority over what the program think would be best.

For example. If I have one resource over and one factory over in Canada I do not necessary want to match the two together. Often I want to route the Canada resource over to UK instead and if I do so I do not want to "fight" over it. In CWIF I often had to "fight" with the program to get the resources to go where I wanted them to go. I often prefer to ship resourcesd overseas to Canada and send the Canada resources to UK.




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/8/2010 2:11:30 AM)


quote:

ORIGINAL: Orm

For me it is important that I can always route a specific resource to a specific factory. And that my order to do so has, and keeps, priority over what the program think would be best.

For example. If I have one resource over and one factory over in Canada I do not necessary want to match the two together. Often I want to route the Canada resource over to UK instead and if I do so I do not want to "fight" over it. In CWIF I often had to "fight" with the program to get the resources to go where I wanted them to go. I often prefer to ship resourcesd overseas to Canada and send the Canada resources to UK.

Yes. This is one reason I want to retain both default destination (usually a factory) and route. Also having a default use once the resource arrives is useful at times (production & save are the only choices, and the latter is only available to oil resources).




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/8/2010 2:13:37 AM)

Here is some of today's progress on Production Planning. I have added the radio button group for filtering the list of resources and factories. I am not going to include the option of sorting the list. That is more difficult and I think less useful.

[image]local://upfiles/16701/24D4A9FA3F184CA59DAF6B7F2ED91146.jpg[/image]

EDIT: The German resource is cut off fromreaching a factory (e.g., Cologne) by the French partisan in Paris.

I am moving a lot of items/buttons that had been on this form to a separate form devoted to routing resources. This change still leaves the form quite detailed but should enable the player to review what he is doing with his resources and modify their destinations and usage. A popup menu appears when you right click on a resource. That lets you select a destination and use for the selected resource.

The second form will be devoted to display and modifying the convoys routes for resources that are shipped overseas. That is accessible by clicking on the (currently disabled) button in the lower left corner.




brian brian -> RE: MWIF Game Interface Design (8/8/2010 6:17:01 PM)

I guess what I was trying to say at the end of my post is that allocating to specific factories is too much for me, only countries is all that is needed. It would be a little annoying to order a resource from Canada to the UK and then have to poke through the list of all the factories in the UK and assign it to one in particular, especially, say if a Sea Lion was under way. No, the London factories are full of the South African coal; no the Birmingham factories are handling the India resources, no the rail from Liverpool to Hull is currently cut by German Paratroopers, etc. How many resources reach each area of production is good enough for me, I don't care which exact resource gets wasted due to diabolical enemy action.

Production in WiF for the complicated countries, such as the CW being the prime example, can become a set of mini-pockets as convoy routes or rail nets (USSR) get cut. Moving an exact resource to an exact factory inside such an area is more than is necessary in my opinion.

The rest of my posts yesterday came while waiting for the French Press to finish steeping my new Mexican (Chiapas) light-roast beans which would have had me wider awake on my morning Internet wandering...




paulderynck -> RE: MWIF Game Interface Design (8/8/2010 6:40:39 PM)

I agree routing resources to specific factories seems like overkill. It may be alright for the land-based powers since you might establish the default and only have to change it infrequently. But for the CW, the usual case is dependent on the number of convoys working to the UK and you don't care which oil/resource goes to which factory, except to use up resources first and oil last. A "happy time" turn for axis subs will mean reconfiguring that turn and (hopefully) the next as well.

As others have noted, since the AI will have to do an excellent job on this, one would expect the player-aid version to be almost painless. Something like: "either reduce production to save more oil or click OK".




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/9/2010 7:51:23 AM)


quote:

ORIGINAL: paulderynck

I agree routing resources to specific factories seems like overkill. It may be alright for the land-based powers since you might establish the default and only have to change it infrequently. But for the CW, the usual case is dependent on the number of convoys working to the UK and you don't care which oil/resource goes to which factory, except to use up resources first and oil last. A "happy time" turn for axis subs will mean reconfiguring that turn and (hopefully) the next as well.

As others have noted, since the AI will have to do an excellent job on this, one would expect the player-aid version to be almost painless. Something like: "either reduce production to save more oil or click OK".

Well, it's overkill until you need that capability.[;)]

For instance, if Sealion has been partially successful and cut the UK east-west, taking out Liverpool, well then, you might want to control whether a resource goes to a factory in the north of the UK or to one in the south. There are other possibilities of the Axis occupying parts of the UK, where treating the entire UK as a single destination won't work.

---

If things are well in the realm of routing resources, then the program will route resources to specific factories without the player having to do anything. I'll use the first pass by the program at routing resources to define the 'default' factories for each resource. [The way this works is that if a resource has no default factory/destination, then I'll give it the first one that is chosen by the program.] You might want to tweak those choices slightly, but only if the convoy routes are sub-optimal. As you said, which factory is the destination doesn't matter when things are going well.

When the convoys get messed up, for any of a number of reasons, that is when the player is likely to want to change destinations. Sending oil to cities to be saved and non-oil to local factories (e.g., in Canada instead of overseas to the UK), could be done on a factory by factory basis - without changing the default factories for the resource. The program will attempt to send the resource to the default factory, and failing that, send it to the last destination. So, if there is a interim where the convoy routes are messed up, a temporary routing scheme could be put in place by the player without affecting the default factory destinations. Once the convoy lines are reestablished, the default routing would be reused.

---

I have no interest in trying to optimize convoy routes for players. I am doing it for the AIO, but I do not want to have long arguments with players about what is 'optimal'. I do know it is not a binary decision, but one of subtle trade-offs between risk and reward.




Orm -> RE: MWIF Game Interface Design (8/9/2010 8:15:45 PM)


quote:

ORIGINAL: Shannon V. OKeets


quote:

ORIGINAL: paulderynck

I agree routing resources to specific factories seems like overkill. It may be alright for the land-based powers since you might establish the default and only have to change it infrequently. But for the CW, the usual case is dependent on the number of convoys working to the UK and you don't care which oil/resource goes to which factory, except to use up resources first and oil last. A "happy time" turn for axis subs will mean reconfiguring that turn and (hopefully) the next as well.

As others have noted, since the AI will have to do an excellent job on this, one would expect the player-aid version to be almost painless. Something like: "either reduce production to save more oil or click OK".

Well, it's overkill until you need that capability.[;)]

For instance, if Sealion has been partially successful and cut the UK east-west, taking out Liverpool, well then, you might want to control whether a resource goes to a factory in the north of the UK or to one in the south. There are other possibilities of the Axis occupying parts of the UK, where treating the entire UK as a single destination won't work.

---

If things are well in the realm of routing resources, then the program will route resources to specific factories without the player having to do anything. I'll use the first pass by the program at routing resources to define the 'default' factories for each resource. [The way this works is that if a resource has no default factory/destination, then I'll give it the first one that is chosen by the program.] You might want to tweak those choices slightly, but only if the convoy routes are sub-optimal. As you said, which factory is the destination doesn't matter when things are going well.

When the convoys get messed up, for any of a number of reasons, that is when the player is likely to want to change destinations. Sending oil to cities to be saved and non-oil to local factories (e.g., in Canada instead of overseas to the UK), could be done on a factory by factory basis - without changing the default factories for the resource. The program will attempt to send the resource to the default factory, and failing that, send it to the last destination. So, if there is a interim where the convoy routes are messed up, a temporary routing scheme could be put in place by the player without affecting the default factory destinations. Once the convoy lines are reestablished, the default routing would be reused.

---

I have no interest in trying to optimize convoy routes for players. I am doing it for the AIO, but I do not want to have long arguments with players about what is 'optimal'. I do know it is not a binary decision, but one of subtle trade-offs between risk and reward.

I like it. [sm=happy0065.gif][sm=sign0031.gif]




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/10/2010 12:20:52 AM)

Here is an oddity the automated routine found that I bet no over-the-board player has ever come up with. It stymied me for a while because I have the animation routine (first working version done today) for routing resources overseas to factories just showing the source, departure port, sea areas traversed, arrival port, and destination factory. What the program found for the Commonwealth in the second impulse of the war was: Cyprus, Famagusta, Eastern Med., Alexandria, Warsaw![X(] That probably won't hold up until the end of the turn though.[:D]




Orm -> RE: MWIF Game Interface Design (8/10/2010 1:14:41 AM)


quote:

ORIGINAL: Shannon V. OKeets

Here is an oddity the automated routine found that I bet no over-the-board player has ever come up with. It stymied me for a while because I have the animation routine (first working version done today) for routing resources overseas to factories just showing the source, departure port, sea areas traversed, arrival port, and destination factory. What the program found for the Commonwealth in the second impulse of the war was: Cyprus, Famagusta, Eastern Med., Alexandria, Warsaw![X(] That probably won't hold up until the end of the turn though.[:D]

Yes, that is weird. There is no way that the cyprus resource can go overland to Famagusta. [;)]

Other than that it is an awesome way to save cp to get the Cyprus resource to a factory. [:D]




Shannon V. OKeets -> RE: MWIF Game Interface Design (8/10/2010 1:46:24 AM)


quote:

ORIGINAL: Orm


quote:

ORIGINAL: Shannon V. OKeets

Here is an oddity the automated routine found that I bet no over-the-board player has ever come up with. It stymied me for a while because I have the animation routine (first working version done today) for routing resources overseas to factories just showing the source, departure port, sea areas traversed, arrival port, and destination factory. What the program found for the Commonwealth in the second impulse of the war was: Cyprus, Famagusta, Eastern Med., Alexandria, Warsaw![X(] That probably won't hold up until the end of the turn though.[:D]

Yes, that is weird. There is no way that the cyprus resource can go overland to Famagusta. [;)]

Other than that it is an awesome way to save cp to get the Cyprus resource to a factory. [:D]

Oops! I guess Famagusta wasn't part of the path.[sm=nono.gif]




Page: <<   < prev  64 65 [66] 67 68   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
3.172119