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 (1/17/2006 9:48:33 PM)

quote:

ORIGINAL: lomyrin

In the CWiF 7.71 Global war scenario the replacement ships arrived as electable ships, the player had the choice whether to accept or decline any or all of the replacement units.

From your last entry I get the impression that you may not be working from the latest CWiF 7.71 which had the global war.

I still have a list of my own detailing the bugs in that program that I was aware of when development stopped.

I can post it here if you so desire.

Lars


If you would send me the list of bugs as a personal message, I would appreciate it.

The version of the CWIF code I have is 0.9.0.0.

Global war is the 11th WIF scenario and the 3rd included in the CWIF beta. As you said, the replacements arrive during play, not as part of setting up the scenario.



Froonp -> RE: MWIF Game Interface Design (1/17/2006 10:10:13 PM)

The Latest CWiF version released to the public was 0.7.71.



Shannon V. OKeets -> RE: MWIF Game Interface Design (1/20/2006 12:26:41 AM)

Here is the revised design for the process of placing units on the map. I am modifying the code so it works this way - hopefully by the end of this week it will be fully implemented. Last chance for suggestions/corrections.

The screen shot is of the work in progress. I intend to remove all the stuff at the bottom of the form (gray box). Though the 6 buttons for land units will appear where you now see the Naval ones (note that the land units have been selected so the buttons are suppose to read INF et al). Once this is cleaned up, the form should be thinner with its bottom just below the "Show Naval" button. This is level 4 zoom (100% in CWIF terms). You have an area about 11 high by 17 hexes wide visible for placing units.

I toyed with the idea of making the form closer to a square in shape, but I really like having that large list of units to look at when selecting who goes where during setup.

I just noticed that the cursor disappears when I take a screen shot. It was positioned over the 7-3 infantry unit.

-----------------------------------------
Design for Placing Units on the Map
(as of January 19, 2006)

This form is used at the start of a scenario, when reinforcements arrive, when reserves are called out, when minor countries enter the game because they are attacked or aligned, and to place partisans on the map. It is very important that this form be done right because it is the first form that a player uses when he sits down to play MWIF. If this form awkward to use, confusing, or otherwise dysfunctional, it can impact the player’s entire MWIF gaming experience.

Though players may not be using the Planes in Flames or Carriers in Flames options when playing MWIF, this form needs to support those options. This means that the player has to:

(1) Choose air units from a random selection (e.g., choose 4 out of 6).

(2) Choose to which air units (from those he chose in step 1) to assign pilots.

(3) Choose to which carriers to assign carrier air units (from those he chose in step 2).

(4) Place all air, land, and naval units on the map.

(5) Reposition units on the map until perfection is achieved.

This form has to: (a) restrict the placement of units to certain geographical locations as specified in the set up rules, and (b) permit the player to undo his decisions.

The form is two rows of units high, but the full width of the screen. It contains:

Group box: a list of groups to be placed (each group has a distinct geographical restriction on where units in the group can be placed).

Air units box a horizontal list of air units sorted by type.

Land/naval units box: a horizontal list of either the land or naval units sorted by type.

The units visible in the air and land/naval boxes are for the selected group. By clicking on a toggle button, the player can switch his view back and forth between the land and naval units. All three types of units (air, land, and naval) and be further reduced to just subsets of those categories (e.g., just carriers, armor, fighters).

Each land unit has a label underneath it saying “Ready”. That means it can be placed on the board. Almost all naval units will be “Ready” too. The only exceptions are carriers that have not been assigned carrier air units. Their label says “No Planes”. Once planes are assigned, then the carrier label will change to “Ready”.

I have improved on my previous interface design for selecting air units, giving them pilots, assigning them to carriers, and placing them on the map. As someone in the forum pointed out, steps 1 and 2 in the above list can be combined. Once a player selects an air unit, it automatically gets a pilot.

Air units have 4 different states. All of them start out as Available for the player to select. This is indicated with a label that describes the number to be selected and the available number from which to select. For example, “F2 (4 of 6)” indicates that the air unit is a fighter costing 2 build points and that the player can select 4 of this type from the 6 that have been randomly drawn from the force pool. Once he has selected which 4, the remaining 2 are placed in the reserve pool. Air units in the reserve pool are already built and only require pilots to be placed on the map. In some cases there is only one air unit from which to ‘choose’. In those cases the program automatically starts the unit as selected..

Left clicking on an air unit selects it. Selected land based air units have a label of “Ready”. When a carrier air unit is selected, its label changes to “No Carrier”.

Left clicking on a “No Carrier” air unit and then left clicking on a carrier with a label of “No Planes”, assigns the air unit to the carrier. The air unit label then becomes “Assigned” and the carrier will have the status of “Ready”. As one small detail, it is possible for some carriers to be assigned more than one air unit. In those cases, the carrier’s label is “Some Planes”.

To summarize, a land based air unit starts out Available and left clicking makes it “Ready”. A carrier based air unit starts out Available, the first left click makes it “No Carrier” and the second left click makes it “Assigned”.

Right clicking reverses the sequence. Right clicking on a “Ready” land based air unit returns it to Available. Right clicking on an “Assigned” carrier based air unit makes it “No Carrier” and right clicking on a “No Carrier” air unit makes it Available. Right clicking on a carrier that has an assigned air unit is equivalent to right clicking on the air unit.

This brings us to item # 4 on the task list. All units that are Ready can be placed on the map at any time. Carrier air units can also be placed on the map as stand alone air units (“No Carrier”). Normally they are first assigned to a carrier and then placed on the map automatically when their carrier is placed. Carriers with “No Planes” or “Some Planes” can also be placed on the map at any time.

The player can select as many units as he likes for placing on the map (left clicking on each). When a unit has been selected for placement on the map, its label changes to “In Stack”. That indicates it is in the stack that the player is moving around for placement on the map. The player then moves the cursor around/over the map. [There is no need to “drag and drop” here. What I mean is that the player can release the mouse button. When using drag and drop, the user has to hold the mouse button down until he is ready to drop the item.]

If the units can be positioned in the hex the cursor is over, the cursor will be a green crosshair (circle with cross). If the hex is illegal (due to stacking limitations or setup restrictions) then the cursor is a red X. Left click on a legal hex and the units are placed therein. Right clicking on a placed unit brings up a menu with the option of returning the unit to the setup lists. Placed units can also be repositioned on the map freely, so long as they do not violate stacking or setup restrictions.

The player goes through this process for each of his setup groups. For example, in the Waking Giant scenario, the USA has part of its navy required to set up on the East Coast, part on the West Coast, and part in Honolulu. A fourth setup group (mostly land and air units) can be placed anywhere in the US.

[image]local://upfiles/16701/346F3B5A52DB4E2AB2758D7D5D65AB92.jpg[/image]



c92nichj -> RE: MWIF Game Interface Design (1/20/2006 12:37:57 AM)

Looks good to me.
I have to say that the graphics looks really good, each and every screenshot you post makes me want to play the game.



dhatchen -> RE: MWIF Game Interface Design (1/20/2006 1:10:06 AM)

This sounds very good to me.

As an aside. I like the idea of left click to do and right click to undo when over a unit or whatever. Do you think that this might be a good interface technique to use, where possible, over the whole of MWiF? It has some the goals of UI design, simplicity, consistency, and predictability.



Shannon V. OKeets -> RE: MWIF Game Interface Design (1/20/2006 1:58:15 AM)


quote:

ORIGINAL: dhatchen

This sounds very good to me.

As an aside. I like the idea of left click to do and right click to undo when over a unit or whatever. Do you think that this might be a good interface technique to use, where possible, over the whole of MWiF? It has some the goals of UI design, simplicity, consistency, and predictability.


As attractive as it sounds, it probably can't be implemented. In the above situation there are a very limited number of things the player can do with the unit (2 actually). He can advance it or reverse through the process.

In most game situations, there are numerous things the player can do. Therefore the right click has to be available for a drop down menu - the left click is usually for selecting the unit.

If other situations come up with only a binary choice, I'll use the left and right click again.



dhatchen -> RE: MWIF Game Interface Design (1/20/2006 11:46:02 AM)

quote:

ORIGINAL: Shannon V. OKeets

As attractive as it sounds, it probably can't be implemented. In the above situation there are a very limited number of things the player can do with the unit (2 actually). He can advance it or reverse through the process.

In most game situations, there are numerous things the player can do. Therefore the right click has to be available for a drop down menu - the left click is usually for selecting the unit.

If other situations come up with only a binary choice, I'll use the left and right click again.


Sounds good, I did not know if you were going to use right click context menus or not. Nowadays, this is a more common thing.



Froonp -> RE: MWIF Game Interface Design (1/20/2006 11:51:24 AM)

quote:

ORIGINAL: c92nichj

Looks good to me.
I have to say that the graphics looks really good, each and every screenshot you post makes me want to play the game.


Same for me [:D].



macgregor -> RE: MWIF Game Interface Design (1/20/2006 10:26:59 PM)

Should I start looking for pistachios and non-pareils?



Shannon V. OKeets -> RE: MWIF Game Interface Design (1/20/2006 11:52:22 PM)

quote:

ORIGINAL: macgregor

Should I start looking for pistachios and non-pareils?


It is very hard to maintain continual progress on this game. I have a half a dozen different task lists and make a point of removing 2 or more items from whichever one I am hammering away at each day.

For a small glimpse into what I really do when I work on MWIF, here are some of the notes I maintain on programming problems. These are just the ones I couldn't solve right away. The numbers are assigned chronologically and are unique so I can cross reference them. They are very useful when a problem appears that is similar to something I have seen previously. These are all solved problems and the last dated entry for each problem is the final solution to it. Most of the list below concerns setting up the additional 8 scenarios, which I was working on the last week of November through the first 2 weeks of December.

=================
29 Scenarios November 24, 2005
Barbarossa - Access violation in SetupCity (Bremen) in CheckReinforcement in CreateSULocGroups in phase pReserves after Germany declares war on the USSR.
November 24, 2005 - This might be caused by the SetupForm not being created prior to the call SetupForm.MilitiaPlaced.Add(CityC, CityR).
November 24, 2005 - SetupForm was being referenced incorrectly. Changed to SULocations (and for partisans and reinforcements).
27 Scenarios November 22, 2005
Fascist Tide - Italian units not permitted in Libya, Ethiopia, or Italian Somaliland. See #8.
November 29, 2005 - Added legal countries for scenario
23 Scrap and setup November 13, 2005
Missed the Bus - access violation before scrapping units screen appears. Also see #10.
November 29, 2005 - Illegal relationship “Commonwealth -> Iceland, Greenland” followed by break. See #35.
December 1, 2005 - Iceland and Greenland are automatically aligned when Denmark is conquered.
36 Scrap and setup December 1, 2005
Missed the Bus - Illegal relationship “Vichy France -> Corsica” followed by break.
December 1, 2005 - Corsica is automatically aligned when Vichy is declared (?).
35 Scenarios November 29, 2005
Lebensraum - Illegal relationship “Commonwealth -> Iceland, Greenland” followed by break
November 30, 2005 - Only minor countries can be aligned.
December 1, 2005 - Iceland and Greenland are automatically aligned when Denmark is conquered.
37 Scrap and setup December 1, 2005
Missed the Bus - access violation before scrapping units screen appears. It occurs after calling SetRelations in GameData and in TUnit.HasFogOfWar for the unit Marseilles. MainForm.CurrCountry is set to nil! This is because the ActivePlayer is also nil. This is because there is no defined player with the initiative for this, and most other, scenarios.
December 1, 2005 - The problem was in moving militia to the reserve pool for Free France when Germany “declares war on it”. The French militia (already in the force pool) was being moved to the force pool and the screen images updated. There was no CurrCountry defined for updating the imaginary screen images. This was corrected by two modifications (both may not have been needed): (1) Check if unit already in InForcePool before moving it there, and (2) extend exception processing to exclude pSetup and well as pVichy and pDeclareWar.
33 Scenarios November 29, 2005
Fascist Tide - Commonwealth capital ships not available (Glorious from South Africa is the 1st one)
December 1, 2005 - The ships were actually United Kingdom, not South African.
41 Scenarios December 6, 2005
Barbarossa - When setting up the reserves for Germany, only air units without pilots are available. They should not be shown since there is nothing the player can do with them. The form also shows the carrier pilots remaining, which appears to be wrong as well (= 2). After setup, carrier pilots and regular pilots are merged into one pilot pool.
December 6, 2005 - This is because the ReservePool is only for air units that have been built but no pilots assigned.
30 Setup Reserves November 24, 2005
Barbarossa - Rumanian unit reserves appear twice in setup stacks. Some units are removed from the map and placed in the setup stacks - this is true for both Rumanian and German units.. Pilots for aircraft seem incorrect.
This might be caused by not clearing the SULocations (or the Group.Items). There are indications that Groups.Items and/or SULocations are being used by other routines inappropriately. Both of these variables have to be examined in detail as to what they do and what is being done to them. December 3, 2005 - solution not found in this exploration.
December 3, 2005 - what needs to be understood here is the precise set of code that executes when war is declared automatically. That is what immediately precedes this problem. StackData.Stack is what is displayed on the screen - and it is wrong. It is set by transferring SetupUnits for the location. War declared causes set up reserves to be checked.
December 5, 2005 - it now appears that the problem may be because SetupUnits is never free’d after setting up units. I tried simply freeing SetupUnits but that had no visible effect. I will now try freeing all the individual setup units too and see what that does. Still no change. Units are still being taken from the map and listed as reinforcements in StackData.
December 6, 2005 - This problem occurs during pReserves, which calls PhaseSetup, which calls CheckReinforcements. The UnitStacks.SetupPool contains units. It does not appear to be cleared after setting up all the units for the game.
December 6, 2005 - Finally killed this bozo. Picking units and placing them in the location groups was moving them to the Setup Pool using MoveToSetup. That routine does a ton of unnecessary stuff. I simplified it by merely changing the column # for the selected units and then changing them back later.
38 Setup December 1, 2005
Lebensraum - Trying to place two carrier planes on a two carriers created an infinite loop. in TUnitStack.FixTransportedUnits because the Counter is being reset internally to the loop and never reaches either -1 or exceeds the Count. This seems to occur because the transported unit has a higher counter number than the transporting unit. The former had an index of 22 and the latter 17. The Count was 99. Only one unit was being transported (F-4F4? on the Saratoga) and MoveTB was false.
December 6, 2005 - Solution to #30 worked for this too.
31 Scenarios November 25, 2005
Guadalcanal - When setting up Commonwealth units, after setting up all the units in India, the program goes into an infinite loop that involves getting the unit type of a carrier unit (this is an actual unit, not a setup unit - Tunit.GetUnitType).
December 6, 2005 - this may be related to #30. If it doesn;t appear again, I will assume that to be the case.
28 Scenarios November 23, 2005
Guadalcanal - Carrier air units are not handled correctly when all pilots have been assigned. Is this a problem due to the removal of the call to CheckPilots?
December 6, 2005 - this may be related to #30. If it doesn’t appear again, I will assume that to be the case.
1 Scenarios November 13, 2005
Waking Giant data
December 6, 2005 - Done
8 Scenarios November 13, 2005
Fascist Tide - testing started
9 Scenarios November 13, 2005
Day of Infamy - Territorial unit not available for USA.
December 7, 2005 - Problem went away (when Philippines added?)
39 Setup December 1, 2005 (December 7, 2005)
Fascist Tide - French territorial units not available (2 out of 2) and then the units that do show up can not be placed in Syria, Tunisia, Algeria, nor Morocco.
December 7, 2005 - GameData had never been entered for France.
11 Scenarios November 13, 2005 (December 7, 2005)
Lebensraum - supplemental data: SetRelations & SetLegalCountries. Territorial unit not found for USA. Bearn not available. This is probably because France has been conquered. Special transfer of Bearn to USA is needed.
December 8, 2005 - Special code written.
42 Scenarios December 8, 2005
Lebensraum - Germany holds most of Russia. This is because the Alternate Control Records are being used and they shouldn’t be in June 1941, only in November of 1941. Barbarossa and Lebensraum should match and so should Day of Infamy and Waking Giant. The latter distinction doesn’t matter in Russia, but what about the rest of the world?
December 8, 2005 - Changed when Alternate control records are used in GameData
41 Scenarios December 6, 2005
Brute Force - The Communist units are not set up. Stilwell can not be found - probably because the Chinese can not use the US unit. Special code needed for transferring Stilwell to the Nationalist Chinese.
December 8, 2005 - Made Stilwell a Nationalist Chinese unit. Set flag for setting up communists. This had failed because the Chinese were first on the list of countries to set up in Brute Force.
26 Align countries November 20, 2005
Barbarossa - Access violation when aligning Hungary, after checking if scrapping units is needed (it isn’t). December 7, 2005 - partially solved by moving TotalUnitCount to StaticVar.
December 7, 2005 - Break occurs when positioning Hungarian unit over Germany. Same thing happens when the Finns are aligned. This happens before the cursor can be moved,
December 9, 2005 - CurrGroupID needed to be set to 1.
32 Scenarios November 25, 2005 (December 7, 2005)
Global War - After setting up all the major powers, Germany declares war on Poland then bringing in the Polish units fails in CreateSULocGroups, because SetupForm is nil.
December 7, 2005 - this is undoubtedly the same as #26.
December 7, 2005 - same problem for Fascist Tide.
December 9, 2005 - CurrGroupID needed to be set to 1.
44 Scenarios December 8, 2005
Lebensraum - Free French cannot be set up. Italy can’t find the French submarine. Program crashes for Commonwealth trying to add Greece as a country - is this because Greece has been conquered? How do we put the British units in Tobruk?
December 9, 2005 - Used Libya instead of Tobruk. Problem with misspelled Egypt.
49 Scenarios December 9, 2005
Missed the Bus - Break during reading the French units for scrapping.
December 10, 2005 - French Somaliland is known as French Somali Coast.
47 Setup December 9, 2005
Assign air units to carriers - form is not centered properly. Review the form.
December 10, 2005 - Tracked down the form (UnitDialog) and fixed.
50 Scenarios December 9, 2005
Lebensraum - Netherlands East Indies territorial unit not found. [Fixed] Norwegian TRS not found. [Fixed] Greek cruiser Girgios Averoff not found [Fixed]. CW does not control NEI. [Fixed] CW does not control Crete [Fixed]. Militia and supply units can not be found. [Fixed] These errors are all for setting up the Commonwealth. NEI naval units can not be set up in NEI. [Fixed]
December 12, 2005 - Special code written for transferring units from conquered countries to new owners. Territorial ownership handled using alignment.
10 Scenarios. December 8, 2005
Missed the Bus - same as #50.
52 Scenarios December 12, 2005
Lebensraum - Netherlands East Indies territorial and militia units can not be set up in NEI.
December 12, 2005 - Modified CheckReinforcing routine to permit NEI land units in NEI.
34 Scenarios November 29, 2005 (December 7, 2005)
Day of Infamy - Netherlands East Indies territorial picked but unable to be placed!
December 1, 2005 - Unable to find Australian armor unit.
December 7, 2005 - Typo, should have been a motorized unit, not armor.
December 6, 2005 - The naval units are ok, why not the territorial? See #52.
48 Setup December 9, 2005
SetupForm - Carrier pilots are always shown on the form. This should only happen during setup at the start of the game, not during reinforcements, reserves, et al.
December 13, 2005 - Changed boolean logic back to what Chris had.
54 Scenarios December 13, 2005
Waking Giant - After placing the Communist Chinese, the USSR setup is checked for violations vis-a-vis the Germans (it shouldn’t be).
December 13, 2005 - Changed the call to CheckSetup so it only does the USSR and is based on the current setup country, not the current country.
=======================



Froonp -> RE: MWIF Game Interface Design (1/21/2006 11:54:33 AM)

wow
[sm=crazy.gif]



Anendrue -> RE: MWIF Game Interface Design (1/23/2006 11:05:47 PM)

quote:

ORIGINAL: Shannon V. OKeets

As attractive as it sounds, it probably can't be implemented. In the above situation there are a very limited number of things the player can do with the unit (2 actually). He can advance it or reverse through the process.

In most game situations, there are numerous things the player can do. Therefore the right click has to be available for a drop down menu - the left click is usually for selecting the unit.

If other situations come up with only a binary choice, I'll use the left and right click again.


If your using right click menus then why not assign "control z" and "control y" to reverse and forward through the placemeent process. Perhaps even recordable as a macro. That way in the future when a player sets up he could choose which macro to run and speed up the placement process. This could even facilitate an interesting blind setup for each side.



Shannon V. OKeets -> RE: MWIF Game Interface Design (1/23/2006 11:45:04 PM)

quote:

ORIGINAL: abj9562

quote:

ORIGINAL: Shannon V. OKeets

As attractive as it sounds, it probably can't be implemented. In the above situation there are a very limited number of things the player can do with the unit (2 actually). He can advance it or reverse through the process.

In most game situations, there are numerous things the player can do. Therefore the right click has to be available for a drop down menu - the left click is usually for selecting the unit.

If other situations come up with only a binary choice, I'll use the left and right click again.


If your using right click menus then why not assign "control z" and "control y" to reverse and forward through the placemeent process. Perhaps even recordable as a macro. That way in the future when a player sets up he could choose which macro to run and speed up the placement process. This could even facilitate an interesting blind setup for each side.


I'll keep the possibility in mind.

My preference is to provide mouse controls for all functions. Keystroke controls are then alternatives to using the mouse. Implementing some of the functionality controls using the mouse and others using the keyboard is a no-no. Very hard for people to learn and get use to when both types of controls have to be used to accomplish tasks.

As far as macros are concerned, this is just a game. Such "high-falootin'" productivity aids are best left to applications that people need to use all the time to conduct business.



Anendrue -> RE: MWIF Game Interface Design (1/23/2006 11:52:32 PM)

"high-falootin'" I guess it is at that. [:)]

Just wanted to add "what was I thinking when I said that" (previous post)



Shannon V. OKeets -> RE: MWIF Game Interface Design (2/17/2006 12:42:48 AM)

Saving and Restoring Setup Positions
(as of February 16, 2006)

I am at the point of rewriting the code for saving the setup locations of units to a file, and, of course, the companion code for loading them in from a file. The more I look at the details of this, the less certain I am that it provides any value to a player.

In theory, the idea is that you start a scenario and position all your units exactly where you want them, and then save those setup locations to a file. The next time you want to start a new game using that scenario, you can load those saved setup locations, and all the units will be positioned where you want them. It doesn’t work out quite like that though.

To start with let me differentiate between saving a game and saving setup locations. You can save a game position after you have set up your units. Saving the setup locations is something different. When you restore a saved game, the units have already been randomly selected, and those are the ones that are placed on the map, in the force pools, etcetera. When you restore saved setup locations, the units are freshly drawn. Any named units will be the same (HQ, naval units) and so will any generated units (convoy points, saved oil points, and fortifications). But the bulk of the land and air units will be randomly selected from the force pools.

This means that the 3 stacks you created with exactly 10 strength points in them could now have 7, 9, and 12 strength points. The garrisons, militia and other infantry unit types will still match, but the artillery units could be messed up. The anti-aircraft unit you positioned with the HQ in the rear could now be you best artillery unit and the artillery unit you expected to have bombarding in the front line could now be an anti-tank gun.

The air units are even more difficult to restore from saved setup locations. Right off, I need to decide how to choose the 3 best fighters out of the 5 that were randomly drawn. You only saved setup locations for 3 fighters. The other 2 are going to the air reserve (or force pool if the pilot option hasn’t been selected). If I can figure out how to make that decision automatically for the players, then the positioning might be really screwed up anyway, because the range of the air units is so important when positioning them on the map. There is also the possibility of drawing a bomber with ATR capabilities one time and not the other time. Positioning an ATR versus a long range strategic bomber are usually quite different.

And then there are the units that have been replaced by Siberians or The Queens. And units that have been broken down into divisions. There is also the concern that the options chosen for the saved setup locations do not match those for the new game. There can very well be units added or removed from the game because of selected options: ski units, artillery, amphibious units, divisions, and so on.

So what does a player really gain from being able to restore saved setup locations?
(1) The named and generated units (e.g., the HQs, battleships, and convoys) will be in place.
(2) A semblance of a front line, though precisely which units go where is probably all wrong.

And what does a player lose?
(3) Choosing 4 air units out of 8.
(4) Choosing which units are swapped for Siberians and broken down.

There are a lot of other decisions that are going to either be made ‘automatically’ by the program, or each one of those decisions is going to be tediously asked each time a player loads saved setup locations.

How do you feel about this? I think that it requires me to code in a lot of assumptions and make decisions that otherwise would be made by the player. Some of which are almost certain to be made ‘incorrectly’ in the eyes of some players. I do not see a clean solution for this, only messy ones.

I also feel that part of the reason the option of saving and restoring setups was included in CWIF was because the setup process was poorly designed and required a lot of opening and closing of forms and windows, clicking on units multiple times to select them, assign them pilots, and place them on the map.

The redesigned interface is much smoother and setting up a game goes much faster. When it does take time, it is because the player wants to position units carefully - building those 3 stacks of 10 strength points each, swapping in the Siberians for the weakest infantry divisions, breaking down certain units, positioning anti-aircraft units with HQs, and the myriad of other little decisions that make playing WIF so interesting.

I am still willing to write the code for this, I just would like to know that it will be a benefit and not so annoying that it is never used. At this time, I do not see how to do that. There are too many odd bits.

And your opinion and suggestions are?



c92nichj -> RE: MWIF Game Interface Design (2/17/2006 12:51:28 AM)

Personally I would not use this functionality at all, I would always want to retain the control over how to setup the units.
If I want to try and play a scenario sevreal times with the same setup I would simply save the game after the setup and restart from there.
I think that there are much more urgent things for you to get cracking on than this issue.

Cheers,
Nicklas



Shannon V. OKeets -> RE: MWIF Game Interface Design (2/17/2006 1:00:58 AM)


quote:

ORIGINAL: c92nichj

Personally I would not use this functionality at all, I would always want to retain the control over how to setup the units.
If I want to try and play a scenario sevreal times with the same setup I would simply save the game after the setup and restart from there.
I think that there are much more urgent things for you to get cracking on than this issue.

Cheers,
Nicklas



The timing on this is good to do it now, if it is going to be done. I have just spent 3 weeks rewriting all the setup routines so the information on their data structures and variables is all fresh in my mind. If I drop this and come back to it in 2 months, I will not be as efficient at writing the code as I would be if I do it in the next 2 days.



lomyrin -> RE: MWIF Game Interface Design (2/17/2006 2:23:53 AM)

I also agree that saving something that will not be accurately recovered without any changes is not a good idea.

As Nicklas stated, saving the game after setup so that it can be used again without any changes should be nothing more than the saving at anytime, and of course that function will be there.

Lars



YohanTM2 -> RE: MWIF Game Interface Design (2/17/2006 2:40:53 AM)

So far the feedback is 3-0. I think every game is different and the units you draw will effect your setup. You also do not want people to load and save, load and save in order to get all the white INF and ARM for example and then be able to keep thta perfect setup forever so it must be random as you suggested. Ergo, almost every time you will need to make adjustments.

This is a long game, not a quick setup, battle and setup again so saving the setup means very little to me.



pak19652002 -> RE: MWIF Game Interface Design (2/17/2006 5:06:22 AM)

Skip it!



Neilster -> RE: MWIF Game Interface Design (2/17/2006 11:33:47 AM)

Kill it.

Nicklas :"I think that there are much more urgent things for you to get cracking on than this issue"

"get cracking on" ? You sound like an Aussie! My dad to be exact. The opposite of getting cracking is "dragging the chain".

We won a gold medal in the Men's moguls the other day BTW (even if the guy was born in Canada). Not bad for our sun-drenched land (apart from the mountainous bits with the ski-fields all over them).

We've won three in total; two at the last games. The first was by the very foxy Alissa Camplin in the Aerials. The second (and by far the best IMHO because of how it happened) was when everybody else fell over and Steven Bradbury won the 1000 metres short track speed skating. I had had a few "strong lemonades" at the time and I fell off my chair laughing. It was a classically Australian way to win something.

Cheers, Neilster

[image]local://upfiles/10515/D992BC2DDE8A4275BF2B0A4B2739741A.jpg[/image]



Neilster -> RE: MWIF Game Interface Design (2/17/2006 11:35:20 AM)

Only one picture per post [:@]. Here's Stephen Bradbury.

Cheers, Neilster

[image]local://upfiles/10515/512421718AE14A888D11890059652D08.jpg[/image]



wfzimmerman -> RE: MWIF Game Interface Design (2/17/2006 5:15:10 PM)

quote:

ORIGINAL: Yohan

So far the feedback is 3-0. I think every game is different and the units you draw will effect your setup. You also do not want people to load and save, load and save in order to get all the white INF and ARM for example and then be able to keep thta perfect setup forever so it must be random as you suggested. Ergo, almost every time you will need to make adjustments.



In CWIF, saving setups was very helpful in solitaire play, but in MWIF, there will be an AI.

the key benefit that saved setups delivered in CWIF was to reduce the amount of button-pushing required before counter-pushing can begin. Steve has already indicated that he plans to address that issue with an improved setup dialog & silent scrapping.



buckyzoom -> RE: MWIF Game Interface Design (2/17/2006 5:27:03 PM)

quote:

ORIGINAL: Shannon V. OKeets

Saving and Restoring Setup Positions
(as of February 16, 2006)

How do you feel about this? I think that it requires me to code in a lot of assumptions and make decisions that otherwise would be made by the player. Some of which are almost certain to be made ‘incorrectly’ in the eyes of some players. I do not see a clean solution for this, only messy ones.

I also feel that part of the reason the option of saving and restoring setups was included in CWIF was because the setup process was poorly designed and required a lot of opening and closing of forms and windows, clicking on units multiple times to select them, assign them pilots, and place them on the map.

The redesigned interface is much smoother and setting up a game goes much faster. When it does take time, it is because the player wants to position units carefully - building those 3 stacks of 10 strength points each, swapping in the Siberians for the weakest infantry divisions, breaking down certain units, positioning anti-aircraft units with HQs, and the myriad of other little decisions that make playing WIF so interesting.

I am still willing to write the code for this, I just would like to know that it will be a benefit and not so annoying that it is never used. At this time, I do not see how to do that. There are too many odd bits.

And your opinion and suggestions are?


If you haven't got the message yet, skip it!

A lot of the fun of playing is trying new things. I doubt I'd ever use the functionality.



Ballista -> RE: MWIF Game Interface Design (2/17/2006 6:07:13 PM)

Either way sounds good to me. I can see the somewhat randomness would be nice for solo, but that's about it. Time spent on this will detract from time spent on more important things, I think.....



mlees -> RE: MWIF Game Interface Design (2/17/2006 7:03:39 PM)

The only reason I might use a presaved setup plan would be for the chore of setting up the convoy chains for the CW.

I vote to "skip it", Steve, as far as allowing a player to save setup templates, for all the reasons you listed. (And don't forget those territorials! Kenya this game, Rhodesia the next...)

If the regular save game feature is available during the setup phase, (as I play solo mostly), that is good enough for me if I need to load up and play "right now, mister!".



Shannon V. OKeets -> RE: MWIF Game Interface Design (2/17/2006 7:04:56 PM)

Ok.

Saving setup locations has now been placed in MWIF Product 2 - unless the beta testers voice a strong desire for the functionality.

Thanks to all for the reassurance.



SamuraiProgrmmr -> RE: MWIF Game Interface Design (2/17/2006 7:07:33 PM)


quote:

ORIGINAL: Shannon V. OKeets

... MWIF Product 2 ...


*** SWOOON ***



Mziln -> RE: MWIF Game Interface Design (2/17/2006 7:13:11 PM)

I just want to be sure when you are saying Saving and Restoring Setup Positions you don't mean the Save Sceanario function.

Which in CWiF allowed you to save possiable setups for secanarios to reduce the time it took to set up the game.

I had Saved Sceanarios for the German invasion of Poland, Russian invasion of Bessarabia, Russian invasion of Persia, Itialian set up, and etc.



Shannon V. OKeets -> RE: MWIF Game Interface Design (2/17/2006 7:57:58 PM)

quote:

ORIGINAL: Mziln

I just want to be sure when you are saying Saving and Restoring Setup Positions you don't mean the Save Sceanario function.

Which in CWiF allowed you to save possiable setups for secanarios to reduce the time it took to set up the game.

I had Saved Sceanarios for the German invasion of Poland, Russian invasion of Bessarabia, Russian invasion of Persia, Itialian set up, and etc.


What I am refering to as saved setup locations is most likely what you are calling here Save Scenario.

Internal to the program code, it is the setup locations for the units that are being saved.

If you want to save a game position, that is always possible. Or at least almost always possible - there are some situations where saving a game isn't permitted. For example, in the middle of combat resolution. You can save the game after setting up one country and before setting up the next. In fact, if automatic save has been turned on, that happens without any input from the player.

Saved games are saved in a file for the scenario, so all the Global War saved games go in the subdirectory with that name.

What I have added, that CWIF intermixed with the setup locations, is a separate capability to save scrap lists. You can save and load lists of units to scrap at the start of a scenario. These are saved by scenario and also by major power. There is a separate sub-subdirectory for each major power within the subdirectory for each scenario (e.g., Saved Games/Barbarossa/Germany). Since the scrap list choices are not random, that decision can be made once and used every time thereafter.

When playing CWIF, you could restore a combined "saved setup locations/scrap list" for each major power for each scenario. Indeed, default ones were provided with the game. How it handled the air reserve units, Siberians, and broken down corps is very difficult to figure out from reading the code. I could elaborate on that last sentence for another 3 pages.

My solution to the difficulties in setting up a MWIF scenario is to
(1) provide a ton of detail when scrapping units.
(2) make saving and loading scrap lists separate from setup locations and the air reserves.
(3) simplify choosng air units (e.g., 4 out of 8 fighters for the USSR in Barbarossa).
(4) streamline the process of placing units on the map from the setup panel/form.
(5) eliminate saving setup locations; requiring the player to save the game (and selected units) instead.

Here is a screen shot of the MWIF scrap form. It is for Barbarossa and I have clicked on Fighters only. There are 4 eligible for scrapping, 14 others in the force pool, and 13 new ones that will enter the force pool next year (1942). At the present there are no fighters on the map, in production, or in the air reserve. Later in the game there will be units listed in those catgories and that information will help you to decide whether to destroy a fighter that just got shot down, or to return it to the force pool.

Note that you can click on "Save Current List" or "Load Saved List". The latter will still let you modify your choices - this screen only closes when you click on "OK (Done)".

[image]local://upfiles/16701/00BF5EA8315F4C75BD8ECF2990D139F0.jpg[/image]



Page: <<   < prev  7 8 [9] 10 11   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
2.546875