MWIF Game Interface Design

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

Moderator: Shannon V. OKeets

User avatar
Mziln
Posts: 667
Joined: Mon Feb 09, 2004 5:36 pm
Location: Tulsa Oklahoma

RE: MWIF Game Interface Design

Post by Mziln »

ORIGINAL: oscar72se

ORIGINAL: oscar72se

Hi!
I don't know if you guys already thought of this, but would it be possible to add a "hover effect" to the interface so that when the user points at a stack, a small window with compressed info about the current stack pops up? In terms of compressed info one could display total attack factors, number of ARM points etc.

So I guess, no?

In CWiF you could click on a stack and it would allow you to filter what you wanted to see battleships, Carriers, Crusiers, Convoys, Subs, Transports, Aircraft, Land units, and etc.
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: Mziln
ORIGINAL: oscar72se
ORIGINAL: oscar72se
Hi!
I don't know if you guys already thought of this, but would it be possible to add a "hover effect" to the interface so that when the user points at a stack, a small window with compressed info about the current stack pops up? In terms of compressed info one could display total attack factors, number of ARM points etc.

So I guess, no?

In CWiF you could click on a stack and it would allow you to filter what you wanted to see battleships, Carriers, Crusiers, Convoys, Subs, Transports, Aircraft, Land units, and etc.

What Mziln describes is still in MWIF. There is a Units Under Cursor panel that can be toggled to be continuously visible or not. It has summary information about the stack under the cursor.

The 2 views shown here are for when the top unit has been clicked on (1 unit's details) and when it has not (whole stack).

Image
Attachments
UUCsummar..20063..jpg
UUCsummar..20063..jpg (205.03 KiB) Viewed 183 times
Steve

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

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

I was reluctant to start a new thread just for this, so I have placed it here.
=================
This is the MWIF Processing Structure for the redesign of the game engine. I had done several previous versions but this is both more complete and more coherent. All the lines without arrowheads are bi-driectional.

I think of the 'player' as having two roles: Controller and Player. As Controller, he starts the game, sets up for restoring or begining a new game, and also has the option to replay a previous game or run through the tutorials. Note that in all those cases he is not 'playing' the game per se. As a Player, he is moving units and making other decisions according to the WIF rules.

So, the Controller starts MWIF (upper left corner) and then decides what to do using the Controller Interface. Say he chooses to start a new game. He gets to set the mode of play (e.g., solitaire or Internet), scenario, optional rules, and identify the players. He might simply assign major powers to players or decide to go through the bidding process. If bidding, he then becomes a Player and the program reaches out to the other players over the Internet. Once major powers are set, Game Control is in charge and informs the active decision makers (Local Player, Internet Player, PBEM Player, AI Assistant, and AI Opponent) so they can perform any preparatory analysis they want. Simultaneously, the "Player on Move" will be informed that it is his turn to make decisions.

The AIO will perform and store its preparatory analysis while waiting on the human player(s) and the human players can do likewise with "Preplanned Decisions".

There is some minor stuff not shown here, but I believe all the important pieces are identified and in place.

My follow-up task to this one is to restructure the program logic so it matches this process structure.

Image
Attachments
Processing..292006.jpg
Processing..292006.jpg (142.05 KiB) Viewed 182 times
Steve

Perfection is an elusive goal.
Incy
Posts: 336
Joined: Sat Oct 25, 2003 4:12 am

RE: MWIF Game Interface Design

Post by Incy »

You should consider using UML Use Case syntax for this stuff.
It will help you get the relations between the various tasks (use cases) better sorted out, and you won't have to define your own symbols.

You could also do good looking into some other UML diagram types for some of this, such as state diagrams and/or Activity diagrams , your drawing seem to mix several types of design drawings into one.
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: Incy

You should consider using UML Use Case syntax for this stuff.
It will help you get the relations between the various tasks (use cases) better sorted out, and you won't have to define your own symbols.

You could also do good looking into some other UML diagram types for some of this, such as state diagrams and/or Activity diagrams , your drawing seem to mix several types of design drawings into one.
In an earlier version I had disk symbols for the data that is stored on disk. They were troublesome to maintain though, so I went with just about the simplest forms possible - mostly identically sized rectangles.

Some portions of this diagram are much better thought out than others. Indeed, the whole upper left quadrant (light brown and light blue) has been rendered into code already. The message control section in the lower right, though not coded, is solid too. The AI stuff is pretty easy conceptually, though I intend to create separate threads for them so they can run in the background. Game replay isn't too hard either.

The messy stuff is the Game Control, Simulation Control, and Player Interface, with the interactive portion of the Tutorial Interface unclear, but that's ok because it is also uncoded as of yet.

It is modifying the existing code (from CWIF) for Game Control, Simulation Control, and the Player Interface that will require the most time for my redesign of the Game Engine. As of today I have it scheduled for 370 hours (remaining). That is probably a lot more than necessary, but overestimating time required is a rare phenomenon for a programmer.

What is UML?
Steve

Perfection is an elusive goal.
Lothrim
Posts: 20
Joined: Fri Apr 07, 2006 8:06 am

RE: MWIF Game Interface Design

Post by Lothrim »

ORIGINAL: Shannon V. OKeets
What is UML?

It is the Universal Modelling Language.
Think of it as a standardised way of drawing software diagrams.

It is only useful if you need to communicate a software model to another developer. If you just code your stuff alone you can draw anyway you want. So for this project just forget UML, it will not make a difference.

regards
Jesper Lyster, independant software architect
User avatar
SamuraiProgrmmr
Posts: 416
Joined: Sun Oct 17, 2004 3:15 am
Location: NW Tennessee

RE: MWIF Game Interface Design

Post by SamuraiProgrmmr »

Steve,
 
Have you considered making the same module that ensures all data is routed to net play be responsible for routing all data to the AIO?  This might be useful if the AIO has its own 'game state data'. 
 
(To be honest, it would also facilitate the addition of AI dlls in case that is still a remote possibility).
 
Dean
Bridge is the best wargame going .. Where else can you find a tournament every weekend?
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: SamuraiProgrammer

Steve,

Have you considered making the same module that ensures all data is routed to net play be responsible for routing all data to the AIO?  This might be useful if the AIO has its own 'game state data'. 

(To be honest, it would also facilitate the addition of AI dlls in case that is still a remote possibility).

Dean
I have completed most of the code for the comprehensive and detailed system that packs/encodes each transaction that changes the game state (i.e., the set of variables that define a game in progress). This is for writing transactions to the game record log. Once I get the Simulation Control module the way I want it, it should only take me another 2 or 3 days to finish that code.

I designed that system to create a single universal 'string' for each transaction (there are close to 500 'string' definitions for the different 'transactions' that occur during game play). The purpose behind this code is to both serve the Game Record Log read/writes and also serve the Message Control read/writes. As for applying it to the communications with the AIO/AIA, I am not so sure that is best.

For one thing, the AIs need to access the Game in Progress Data directly to perform their internal analyses of the game state/map position. Routing all that through a message system would either be a duplication of data values or very inefficient (what with encoding and decoding every transaction). However, I have been giving some serious thought to having the AIs communicate their decisions using the Game Record Log strings, since that task needs to be done anyway. If the AIs do it, then Game Control can send the 'string' along to Simulation Control and hence to the Game Record Log without any extra work being required. That is how transactions received though Message Control (NetPlay and PBEM) are handled. It is also what I intend for the Player Interface communication to Game Control of the Local Player's moves/decisions.

In fact, when I talk about "redesigning the game engine" that mostly involves identifying and isolating every decision/transaction made by the Local Player, encoding it as a GRL string, and routing it through Game Control and Simulation Control rather than having the Player Interface act upon the Game in Progress Data directly (which is how is happens presently).

The AIO (or AIA) as a separate DLL is unlikely because of the first sentence in the third paragraph.
Steve

Perfection is an elusive goal.
User avatar
SamuraiProgrmmr
Posts: 416
Joined: Sun Oct 17, 2004 3:15 am
Location: NW Tennessee

RE: MWIF Game Interface Design

Post by SamuraiProgrmmr »

Steve,
 
I agree with the premise that if the AI has access to the main 'game state', that it will be more efficient as well as preclue external AIOs. 
 
I think I have mistakenly attributed the argument for having a separate data structure for the AI to you when it was made by someone else. 
 
Dean
 
 
Bridge is the best wargame going .. Where else can you find a tournament every weekend?
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: SamuraiProgrammer

Steve,

I agree with the premise that if the AI has access to the main 'game state', that it will be more efficient as well as preclue external AIOs. 

I think I have mistakenly attributed the argument for having a separate data structure for the AI to you when it was made by someone else. 

Dean

The AIO needs to maintain a supplemental set of variables related to previous and current analyses, of course. Those will be one set per major power AIO, though some of them regarding the enemy units and position will be held in common for all the AIOs on the same side. For example, the German AIO and Italian AIO might have a single, common analysis of the position of the French units, but separate plans for what each AIO is going to build.
Steve

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

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

Task Force Interface
(as of May 6, 2007)

As I entered all the units from Cruisers in Flames and Convoy in Flames into the setup data, it became painfully obvious to me that there are going to be a lot of units for players to setup. Now the obvious solution to that, as we have discussed before, is to create task forces. How to design the player interface for task forces is today’s question from me to you.

Each task force would simply be a group of naval units, which could include any cargo they are carrying (e.g., invasion troops). There should be a form/box which displays all the units in the task force (duh). I am thinking of making the size of the units in that display larger than the other unit displays since each naval unit is uniquely named and players might enjoy knowing which ship, by name, are in each task force. In fact, I have a request from one of the beta testers (from long ago) to make the unit size in all displays larger so they are easier to read. If making the unit size in the ‘StackViewer’s larger isn’t too difficult to do, then I will. Of course then the player will be able to change the size of the units displayed from small to large. But I doubt I will provide all 8 levels of zoom that the map has.

So let’s take as a starting point that there is some box that shows all the units in a task force. Indeed, there may be several task force boxes on the screen simultaneously. During setup, there will be the setup tray too, with its display of units to be set up. Drag and drop seems the correct way to transfer units from one display to another. So units could be moved from one task force to another and to and from the setup tray.

Each task force box should provide some summary statistics about the task force’s ability to move and fight. I’ll try to limit that information to just the essentials, since it is easy to make it so detailed that the important items become lost in the clutter. If you have ideas about what those summaries should include, please let me know.

I am puzzling over the actual creation of a task force. I think it has to be associated with either a specific port or a sea area section box. That way I can impose restrictions on which units are available for populating the task force, and where to place units that are removed from a task force. How about whenever a player right clicks on a port or a sea box that contains more than 1 naval unit (or any viable set up port/sea area during setup), the option of creating a task force appears? The task force would be given a (unique) name by the player and voila!, a spanking new task force has been born. At the same time a form/box would be should that contains all the units currently in the port/sea box that are available for inclusion in the task force.

Comments? Suggestions?
Steve

Perfection is an elusive goal.
trees
Posts: 175
Joined: Sun May 28, 2006 7:30 pm
Contact:

RE: MWIF Game Interface Design

Post by trees »

I think it would be quite simple for the program to prohibit dragging and dropping units from TF to TF when the TF's are in different locations.

For the TF summary, I would just want to see a summary of the possible movement points and range of the TF (simply the lowest MP/range of an individual ship in the TF), and a short list of quantities of the ship types therein: CV/BB/CA/lift. Others will want a sum of the total factors for each combat ship, which would be a bunch more work to display, but I would be content to know there are 2 Carriers, 3 Battleships, 6 Cruisers and an AMPH. If you neeed to know more than that, open a windown on the entire Task Force and take a look at all the ships; perhaps that window could show a total. That would be my suggestion.
plant trees
trees
Posts: 175
Joined: Sun May 28, 2006 7:30 pm
Contact:

RE: MWIF Game Interface Design

Post by trees »

I like being able to name the TF, definitely. When SiF and TF's appeared we started using them but in the long run just decided it's easier to make Sweden=Kiel, Spain=Gibraltar, Turkey=La Spezia, the gray map edge=Pearl Harbor, etc, than using another location 2-3 feet away from the action.

I'm guessing unlimited TF? I don't see why not. Except if the Hidden TF optional is currently part of the rules or not, I forget. It is not a popular option though I've always wished to use it more. WiF is so big and detailed, and I think many players tend to approach the game with a land focus first, that hidden TF's are harder for players to conceive of and plan for, so it isn't used often. If Hidden TF is 'in' then the amount of TF's can't be unlimited as there is a mechanical problem with the search rules that immediately gets abused by players. Perhaps that was fixed with the second version of the Hidden TF optional, I forget on that point too. (Obviously I never get to play with it, but I can recall talk about these issues).

And as for how to display a TF, with different zoom and such, wouldn't it be easiest to make it the same routines that display land stacks? With three land units and up to 6 uniquely designated aircraft in a hex, wouldn't the same issue come up?
plant trees
npilgaard
Posts: 176
Joined: Wed May 03, 2006 6:09 pm

RE: MWIF Game Interface Design

Post by npilgaard »

ORIGINAL: Shannon V. OKeets

Task Force Interface
Each task force box should provide some summary statistics about the task force’s ability to move and fight. I’ll try to limit that information to just the essentials, since it is easy to make it so detailed that the important items become lost in the clutter. If you have ideas about what those summaries should include, please let me know.

Good idea with the task forces.

In addition to the movement info (speed/range) mentioned I would like to see the combat relevant info:
- total number of surface/sub (if they can enter task forces)/AA/naval air factors (maybe each followed by column number on the naval battle CRT, to make it easy to reach the right numbers)
- total number of ships (again, maybe followed by row number) - and maybe types specified as suggested above

ORIGINAL: Shannon V. OKeets

Task Force Interface
I am puzzling over the actual creation of a task force. I think it has to be associated with either a specific port or a sea area section box. That way I can impose restrictions on which units are available for populating the task force, and where to place units that are removed from a task force. How about whenever a player right clicks on a port or a sea box that contains more than 1 naval unit (or any viable set up port/sea area during setup), the option of creating a task force appears? The task force would be given a (unique) name by the player and voila!, a spanking new task force has been born. At the same time a form/box would be should that contains all the units currently in the port/sea box that are available for inclusion in the task force.

Comments? Suggestions?

Sounds like a good way of handling it. However, if such task forces are unlimited and present whenever more than 1 ship is at an sea box, then it should be possible to somehow disable viewing enemy task forces on map, and instead viewing the stacks. Otherwise it will be hard to get a quick overview, eg. for Germany when determining where to move the subs, as there will probably be 1-2 CW task in each and every sea area containing convoys.
Also, maybe convoys should not be included in task forces when they are in destination sea area, again for easier overview of the convoy lines (they should be able to be included when in port or when moving, to make movement easier)
Regards
Nikolaj
User avatar
Froonp
Posts: 7998
Joined: Tue Oct 21, 2003 8:23 pm
Location: Marseilles, France
Contact:

RE: MWIF Game Interface Design

Post by Froonp »

Each task force box should provide some summary statistics about the task force’s ability to move and fight. I’ll try to limit that information to just the essentials, since it is easy to make it so detailed that the important items become lost in the clutter. If you have ideas about what those summaries should include, please let me know.
Well, the usual summary of statistics would be :
Total Number of ships.
Total Surface factors.
Total Shore Bombardment sactors (adjusted by the sea box).
Total AA.
Max speed (being the speed of the slowest ship)
Max range (being the range of the lower ranged ship)
Total ASW factors (counting planes).
Max possible Air to Air Strengh.
Max Possible Air to Sea Strength.

Also, Task Force need to be able to be maintained while in port too, so that the player do not need to create it again and again. This Task Force "maintain" has not to be visible for the enemy, only the allied player knows that this and this ships are associated in a "future task force" in a port.

Also, the Task Force screen may be similar to the port screen (not existing, but that should be created). After all, a Task Force is just an assembly of ships. A Port is the same, except that a port is immobile.
User avatar
paulderynck
Posts: 8464
Joined: Sat Mar 24, 2007 5:27 pm
Location: Canada

RE: MWIF Game Interface Design

Post by paulderynck »

Hi Steve,

I have seen a nice interface in other (business) programs I like for this instead of drag and drop. It consists of two text windows presented in column style with some buttons in between. The left hand column would be the units available and the right hand column would be the units in the task force. The text would be the unit names and maybe all of their factors, FREX: "Andrea Doria 6-5-5-1-2-3". The buttons in the middle would be Add, Remove, Add All, Remove All. Usually the buttons also show a direction arrow to remind you the selection is going left to right or vice versa. Of course, you can use standard shift and control keys when clicking the mouse to select groups of items.

I find Drag and Drop can be tedious at times and accidental clicks can slow the whole process down, whereas the selection list idea appeals to me as more efficient.

For Drag and Drop you can use the same multi-select options and even add the "lasso" ability (which can be both good and also annoying when an error is made) - but I wonder if the real estate required wouldn't be too much for really large fleets. The advantage of text is it is more compact. Of course either a text list or a list of unit graphics can be scrolled...

Anyway, just an idea. Maybe a hybrid of the two would work even better.

BTW, on the subject of Task Forces, is the WiF option for Task Forces employable - just curious, personally I don't like it and would not vote for it when starting a game. I got the impression "your" task forces mentioned here are for playability and can be examined freely by all players.

Cheers.



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

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

Task forces as described in WIF FE (i.e., Hidden Task Forces) are not part of MWIF product 1. I am using the word Task Force here as simply a convenience for players moving naval units around on the map.

In particular, MWIF Task Forces have absolutely no effect on any other rules. It is simply as if you were picking up and moving a stack of naval units - which is a common occurrence in WIF. Having units identified as being in a Task Force , does not commit the player to moving them together. At any time, on the merest whim, the player can disband or reconfigure a task force(s) - though all the rules pertaining to moving groups of naval units are still in effect.

So, the enemy player can examine your task forces if he so desires, though that does not mean that is the group of units that will be in the task force once it is your turn to move naval units.

I like the idea of a separate column/area for each task force and arrows connecting them that could be clicked on for moving ships from one location to another. That is the design/style used for moving markers between offense & defense and for moving US Entry chits between entry and tension pools.

However, I am concerned that we might need several task forces active at the same time, instead of just 2 areas. For example, when setting up the CW navy in almost any scenario, there are a lot of different locations you might choose in Europe: Portsmouth, Scapa Flow, Liverpool, Gibraltar, Malta, and Suez come to mind. When distributing the large number of naval units into separate task forces (perhaps one per port), and shuffling them about as you try different configurations, you will probably want to have all those places visible at once.

Maybe having a display of the units in each force pool/location (i.e, multiple areas containing units visible at the same time) and then a simple text list of the same locations would work. The player could select units from whichever location he likes, including selections from multiple locations at the same time, and then click on a 'destination' location. The selected units would then be moved from the old into the new locations/force pools. I have a couple variations on this style in mind. It's a new idea, less than 2 minutes old, but I think it has potential.
Steve

Perfection is an elusive goal.
User avatar
wfzimmerman
Posts: 338
Joined: Wed Oct 22, 2003 7:01 pm
Contact:

RE: MWIF Game Interface Design

Post by wfzimmerman »

I wonder if it might be worth repurposing the AI's task force creation logic for the player interface. I know that when I set up navies that have a lot of units many of my choices are rather arbitrary. It would be nice to be able to just have the computer set up a bunch of reasonable task forces and let me drag each task force to the port that I want it it.

the tradeoff here, of course, is between the competing values of player responsibility and ease of use. I don't think it's unreasonable or out of the spirit of gaming for the human commander to tell his Admiralty "create ten task forces and I will tell you to put them."
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Game Interface Design

Post by Shannon V. OKeets »

ORIGINAL: wfzimmerman

I wonder if it might be worth repurposing the AI's task force creation logic for the player interface. I know that when I set up navies that have a lot of units many of my choices are rather arbitrary. It would be nice to be able to just have the computer set up a bunch of reasonable task forces and let me drag each task force to the port that I want it it.

the tradeoff here, of course, is between the competing values of player responsibility and ease of use. I don't think it's unreasonable or out of the spirit of gaming for the human commander to tell his Admiralty "create ten task forces and I will tell you to put them."
Rather than create a feature where the AIA (Assistant) does this, I would prefer written guidelines/advice as part of the player's manual. Something along the lines of what is a good balance of forces for different roles against different enemy forces:

Role
1 - invasion force
2 - convoy protection
3 - control of sea area/blockade
4 - for a strongly contested sea area

Enemy forces
a - against submarines
b - against a surface fleet (no air)
c - against a surface fleet with air
d - a response/retaliation fleet - requires increased range and movement

My preference is for the player to play the game instead of watching the computer play it for him. However, I do not want to force the player to figure everything out through trial and error either.
Steve

Perfection is an elusive goal.
User avatar
wfzimmerman
Posts: 338
Joined: Wed Oct 22, 2003 7:01 pm
Contact:

RE: MWIF Game Interface Design

Post by wfzimmerman »

ORIGINAL: Shannon V. OKeets

ORIGINAL: wfzimmerman

I wonder if it might be worth repurposing the AI's task force creation logic for the player interface. I know that when I set up navies that have a lot of units many of my choices are rather arbitrary. It would be nice to be able to just have the computer set up a bunch of reasonable task forces and let me drag each task force to the port that I want it it.

the tradeoff here, of course, is between the competing values of player responsibility and ease of use. I don't think it's unreasonable or out of the spirit of gaming for the human commander to tell his Admiralty "create ten task forces and I will tell you to put them."
Rather than create a feature where the AIA (Assistant) does this, I would prefer written guidelines/advice as part of the player's manual. Something along the lines of what is a good balance of forces for different roles against different enemy forces:

Role
1 - invasion force
2 - convoy protection
3 - control of sea area/blockade
4 - for a strongly contested sea area

Enemy forces
a - against submarines
b - against a surface fleet (no air)
c - against a surface fleet with air
d - a response/retaliation fleet - requires increased range and movement

My preference is for the player to play the game instead of watching the computer play it for him. However, I do not want to force the player to figure everything out through trial and error either.


That's what I figured you would say! What I really object to, in particular, is having to spend an hour or two on sifting through Treaty cruisers every time I do a global war setup. ;-)
Post Reply

Return to “World in Flames”