Development In Progress
In rough order of priority
--- UPDATE --- Turn Tracker Released
A general purpose Turn counter. Configurable to suit any game. Button on launch bar.
It would have to be configurable in regards to sides; some examples PZB is Russian or German PZL is Allied or German American Civil War is CSA or USA Third Reich multiplayher has: Russian, Italian, France, Britain, Germany, USA
Turns also is game specific; some examples SQL, PZB, PZL is 1, 2, 3, 4.... 3R4 is season, spring, summer, fall, winter AND a year (1939-1946) Guns of August is monthly, jan, feb, mar AND a year (1914-1919) War in the East has a Cycle (1-13), turn (1-4) AND a year (1941-1944)
Will also need to be configurable within a game (not just in module) as different scenarios may have different number of players.
- A Turn Counter has:
- launch button text and Control key
- Turn Format (e.g. '$side$ - $month$, $year' - 'Axis - Jan, 1914')
- Report Format (e.g. '$PlayerId$: Turn updated from $oldTurn$ to $turn$' - <Brent>: Turn updated from Axis - Jan, 1914 to Allies - Jan, 1914')
- configurable number of Turn Levels
- Each Turn level is either a counter (start value, increment) or a list of items.
- Clicking on the Turn button brings up a small dialog showing the current setting of each Turn Level (e.g. Year: 1914, Month: January: Side: Allies) and 5 buttons:
- Next: Move Turn counter on
- Prev: Move Turn counter back
- Save: Save Turn counter value and report
- Cancel: Throw away changes
- Set: Bring up dialog to set /configure turn counter
- Set Dialog allows the current status of each Turn level to be changed:
- For a counter, you can set the current value
- For a list, you can set the current value, which value is considered 'first' and you can turn values on/off (i.e. for a 2 or 3 player scenario instead of 5 player).
- Got basic functionality working.
- Rejigged window as a proper floating window.
- Removed save/cancel/set button.
- Changed Prev/next to icon buttons that act immediately.
- Access to Set/Configure via Right-click
- New Ideas
- Tooltip on Next/Prev buttons to show text of next/prev turn.
- More Generic - allow a list item to have phases. Will be able to setup sequence of play and have turn counter step through it.
Status: 100% complete (19-Jul-05, Brent Easton)
Counter Inventories - Summaries and Totals
--- UPDATE --- Released
Inventory a set of counters, print a summary report. Group by values of specified Marker trait. Report count of units, or total integer value in a given Marker trait. Display to Chat window or Dialog window.
- All units on all maps.
- Units on named maps.
- Units with Marker values meeting condition.
- Currently selected units.
Simplified version complete - One line report of all counters with Marker CONTROL defined, showing counts of counters with different values of Marker NATIONALITY. Display to Chat Window or Dialog window.
Control Summary: American: 4 British: 16 French: 2 German: 12 Russian: 10
Status: 60% complete. (May '05, Brent Easton)
Extended Inventory that includes output in an explorer like tree window, auto centering on pieces and sending of hotkeys in addition to the above stated totals.
Status: 100% complete, (May '06, Torsten Spindler)
Improved Text Labels
Now that we know text labels can display HTML and you can specify a transparent background color, you can do some pretty groovy things. But a few extra basics wouldn't go astray:
- Font Selection
- Styles (Bold, Italic, Bold+Italic)
- Rotation by arbitrary degrees.
Status: %100 complete and passed on to Rodney, hopefully for inclusion in 2.0 (May '05, Brent Easton)
Are your players typing the same messages into the Chat Window time after time. Wouldn't it be nice to have a drop-down list of standard messages?
The Messenger Component can be added to the main Game Toolbar, or to any Map or Hand window and let's you set up a list of Chat Messages. One level of sub-menus can also be defined. Just click the button, select a message from the list and it is echoed int the Chat window.
Status: %100 complete. May be included in standard VASSAL (May '05, Brent Easton)
Oblique Hex Grid Numbering - for old AH enthusiasts
Just when I thought I'd finished with Grid's and Grid Numbering's, Oblique Grids pops up it's ugly head. A number of old Avalon Hill (AH) titles use a grid numbering scheme using the natural oblique axes of hexagons, rather than the Orthoganal (Fancy word for squareish!) scheme games use today.
I finished a version that works for Third Reich, hoping that the other games that need it use the same scheme (you have a choice of left or right diagonal, plus ascending or descending sequence on each diagonal). NOPE! Looked at 3 games and found 3 different schemes!
Status: Third Reich version complete. Generalised version 50% complete (May '05, Brent Easton)
Recording Terrain Information - Generalised terrain handling
This has been a goal of both Rodney and myself for a long time. How to store terrain (and other status) information about maps that is:
- Accessible - can be used by other vassal components.
- Maintainable - Not a nightmare to define and maintain the data.
- Generalised - Can be used by many and varied modules.
Terrain information needs to be stored per grid cell (Hex, Square or Region). Would need to be keyed on locationName().
- Primary Terrain Type
- Edge Terrain Type x 6 for hex grids. Edge terrain primarily used in Hex grid games?
- List of (possibly named) features (eg. population centres, Road & Railway connections) and attributes (e.g. control, status's etc.).
- Terrain Types would be defined per module in a separate Terrain component. No hard-coding.
Maintainability will be a problem. Perhaps maintain the Terrain data externally in Excel and have a button to load it into the module. In a perfect world have a point & click, drag and select type interface and with dynamically generated terrain config menu (based on options recorded in Terrain Type Options).
- Movement Point counting.
- Display movement range of a counter.
- Give Map cells names (ie. move -> Paris instead of move -> J29)
- Record and display status information. E.g. record which player controls each hex. Have a button to shade the map showing which players control which hexes.
- Have counters dynamically change (layers, labels) based on terrain or attributes of the hex they are in.
- General purpose Line of Sight tool based for games where terrain assumed to fill entire hex.
See here for details of a custom code implementation.
Variables, Conditionals, Processes - Counter Programming without Java!
This all got started when I was thinking about a better way to implement 'attribute counters' on units. I mean things like a Hit Point level counter that can be incremented and decremented through a series of values and the current value is displayed on the unit somehow.
There are two ways these are generally implemented:
- Using a Text Label. Players manually change the label text to the required value.
- Using Layers. If the number of layers is not great, then a counter image (or better yet, just an image of the value) is stored on each layer level. Increase and Decrease commands are used to change the current layer level, displaying the correct value of the attribute.
This got me thinking about Markers and how similiar they are to Variables in a programming language. Markers define a variable name and specify a value. Currently, once set, marker values do not change. But there is no reason why they shouldn't. If the marker value is a number, then there should be ways to increment or decrement it and to display it's value.
Here's the first scheme I thought up for a better attribute counter -
- Add an appropriate marker to the unit. For example, a marker called HIT_POINTS.
- Modify the Text Label trait to be able display Marker values. For example, something of the form %HIT_POINTS% will be replaced by the current value of the HIT_POINT marker (i.e. Variable) when the label text is displayed.
- Now we just need a way to manipulate the value of the HIT_POINTS marker. This can be accomplished by adding some additional functionality to the Marker trait. Currently the Marker trait does nothing except set the initial value of a marker. Let's add some Key commands. Increase by value, Decrease by value, Set to value. The value to increase by, decrease by or set to may be a specific number, or might be %DAMAGE% to use the current value of the DAMAGE marker! Marker traits could also piggy back onto other command from other traits by specifying a Control key to respond to, but no command name.
Where else could we go with this?
- Extend this to include access to Terrain Attribute information.
- Any place where text is printed about a unit, allow %MARKER% to include marker values in the text. e.g. all Formatted reports. [Done - Vassal 2.1]
- Labels that only appear conditionally.
- Layers that change the level displayed based on marker values (or terrain attributes), or activate/deactivate automatically.
- Add options to the Layer trait to store the current level number, level name and image name into specified markers. [Done - Vassal 2.1]
- Create a Conditional component that returns true or false based on Variable (i.e Marker Values) comparisons ( <, >, =, !=, like, and, or etc.). Conditionals can reference other conditionals to create an arbitarily complex test. [Done in GlobalKeyCommand - Vassal 2.1]
- Modify traits to allow actions optionally dependent on Conditionals. For example, Text Labels that only appear when %HIT_POINTS% < 10 or when the layer level named 'EXPOSED' is currently stored in the marker %EXPOSED_STATE%. [Done in GlobalKeyCommand - Vassal 2.1]
- Send to Location that changes (Map name or position) depending on marker values.
VASSAL Components and counter Traits will be either producers or Consumers of Variable information.
- Any counter trait that affects the display of a counter could be modified to only work if a Conditional is true.
- Layer trait changes layers depending on a Variable
- Layer trait stores current Level number, Image name and Print name into variables. [Done Vassal 2.1]
- Terrain attributes of the current hex will be available to a counter as variables.
Status: 40% - Ongoing (Nov '05, Brent Easton)
Definetly have my eye on this possible development with conditionals Brent! It would almost certainly bring my mod size down from 30mb and 1200 graphic files down to about 100 graphics files and 1-2mb tops. Tim
Update 6-Oct-2005 Some portions of this have been included in version 2.1 VASSAL :-
- All formated reports that relate to specific counters now replace $marker_name$ with the the value of the marker.
- Global Key Commands can no be added as a counter trait and have been hugely increased in power by being able to select characters using an expression e.g. currentMap = main && Selected = true
- Embellishment trait enhanced to return properties reporting current level number, name, image name and active state.
- Basic Piece trait enhance to return properties reporting locationName, currentMap, currentBoard, currentZone.
Replace by Name trait
The current 'Replace' trait requires that you define the replacing counter completely within the trait. 'Replace by Name' would allow you to specify the name of a counter. At run-time, the system will check all game piece pallettes and replace the counter with the first found counter with the name specified.
Easy to do.
This is not such a high priority as you can specify a prototype in the defined marker.
Status: 10% (Nov '05, Brent Easton)
Scribble Pad - Visual Notes
A component that can be added to Maps to allow drawing on the map. The scribbles would be stored on a layer above the map. The Launch button would toggle display of the scribbles on/off. When on, a small floating menu of scribble options would appear. Basic functions would include:
- Freehand Drawing
- Straight line point to point drawing
- Text ?
- Brush size
- Save to file/load from file
Would be implemented as a JLabel that is drawn on top of the map. They are basically private notes and not visible to any opponents. Would be nice to save the scribbles in the save file, but this might be asking a bit much.
Have found an old sourceforge RFE on the same subject. More limited, just allow drawing of ovals, rectangles, text and straight lines. That would allow the drawing to be described with a simple command language that could be saved in the logfile. Freehand drawing is not really required.
Status: 5% (May '05, Brent Easton)
Currently the visibility of a gamepiece can only be defined for a player. Either the player sees it or not. Sometimes more flexibility is asked for: Hiding gamepieces based on side or based on a marker. A first implementation is available now, though raw.
The Hideable class itself does no longer check the visibility of pieces but uses a concrete implementation (read strategy) of the interface HideAccess. Implementations of HideAccess have to provide only two methods, one to get the password for that strategy, one to check the password. The field hiddenBy in Hideable is still used for storing the password provided by the hide strategy.
- See if there's a way around the static methods in HideAccess
- Add strategy to hide based on marker and probably marker value
- Add support for multiple sides, like in Restricted Access
- Updated help page
- Test module with new hideable trait
- see pieces->Basic->Def Wheel
- Example save game
- Source Code
Status: Complete (March '06, Torsten Spindler)