Roadmap Archive

General

This is our development roadmap. Here you can see what we have planned for future releases of VASSAL.

Version Numbering

VASSAL releases have version numbers formatted as major.minor.micro (for example, 3.1.14). Customarily, the major or minor version number changes when we add new features; changes in the micro portion of the version indicate bugfix releases.

Release Plans

3.1

This is the current version. All further releases in the 3.1 series will be bugfix only.

3.2

This is the version currently in development and will be the next release containing new features. The following projects are slated to be completed for 3.2:

Tile Cache

Addresses the long-standing performance problem with very large map images, by slicing them up the first time they're loaded and caching the tiles to disk. (Joel: 100% complete, image code. 50% complete, disk cache management code.)

ZunTzu Converter

Converts ZunTzu modules in to VASSAL modules. (Michael: 70% complete.)

Bugs

Fixing reported bugs. (Never complete. Soul-crushing, yet necessary.)

BeanShell, Calculated Properties, In-line Expressions

[RFE 1565025 Calculated Property and General Mathematical Expressions] Calculated Properties are properties whose value is a Java expression, referencing other properties and in-built functions. Inline Expressions are Java expressions that can be used in fields that currently allow $xxxx$ expressions. (Brent: 80% complete. Working, but needs improvement in GUI.)

Named Key Strokes

[RFE 1604269 Specify keystrokes by name] Wherever a Hotkey can be entered, optionally allow entry of a Name instead. A Name consists of 2 or more alpha characters and does not appear on the right-clock menu. Each unique Name is internally replaced by a unique hotkey that is guaranteed to only match other VASSAL Hotkey fields using the same name. This allows you to make up meaningful names for hotkeys used internally in triggers etc., instead of having to invent series of unusual combinations to prevent overlap. (Brent: 100% complete.)

Jabber Client improvements

Add Room locking, invitations, kicking to the Jabber Client, tied in to the facilities provided by the Jabber server. (Brent: 75% complete.)

Counter Autoloader

[RFE 2132985 Facility to generate many counters from a folder of images] Point VASSAL at a folder of images, enter a Piece definition, preview the counters that will be generated, allow user to rename them, skip some, preview images, then create all of the counters in one go. (Brent: 100% complete.)

Improved Game Updater

[RFE 1199542 Scenario Counter Refresher]. (Brent: 80% complete. Working, but looking at ways of automatically determining counters are out of date and auto-updating.)

Tango Icon Support

Support for variable-size icon sets. (Brent: 50% complete. Awaiting full support for pathnames in DataArchive.)

3.3

Properties

The creation of some utility classes to encapsulate type-safe properties which can be held by objects, queried by name, and watched for changes. (Joel: 95% complete. Could use some tests.)

Preferences

Our current preferences structures have a lot of problems. This project aims to replace existing preference structures with a container using Properties, replace Configurers and the Preferences dialog with with better-looking GUI elements, and to store prefs as human-readable XML. (Joel: 50% complete. Depends on Properties.)

Conversion of Buildables to Use Properties

This project addresses a performance issue, namely that currently retrieval of property values is linear (and demonstrably too slow in some modules), while it could be logarithmic if we used Properties and getter/setter functors stored in Maps. (Joel: 0% complete. Depends on Properties.)

Docking

Add a docking framework so that VASSAL components may be freely rearranged and resized by the user. The docking framework Joel would to use is GPL, which would mean that we'd have to switch VASSAL to GPL. Joel is favor of that anyway; however, it would mean that custom module code would also need to be GPL, and in order to round up the authors to relicense it, it would help to have the module library on the new web site up and running already. Another option would be to use the docking code Joel started before he found something better. He's not keen on that, as it's going to be a lot of work to finish, and then we'll have to maintain it. (Joel: 10% complete. Possibly depends on Web Site Update.)

Logging Improvements

Various improvements to game logging. Tim McCarron and Joel hashed this out about a year ago. This would amount to some VCR controls and an annotatable list of moves. (Joel: 5% complete. Depends on Docking, as there's no place to put the GUI otherwise.)

Wizard Replacement

We have quite some bugs related to the setup and welcome wizards, and moreover they are aesthetically awful. The wizards will still be ugly after fixing the bugs, so Joel wants junk them rather than spend time figuring out how exactly they're broken. This project involves writing a simple wizard framework and reimplementing our wizards in it. (Joel: 40% complete.)

Model-View Separation

Our GUI code is interspersed with our data handling code. This makes it hard to test our data handling code. This makes it hard to ensure that all Swing calls are done on the Event Dispatch Thread. This makes it hard to move as much other processing off the EDT as possible in order to improve GUI responsiveness. This makes it hard to implement other views of the same data (see the JOGL project). The idea here is to separate existing classes into a model class (containing the data) and view classes which hold the GUI components, listen to the model class for changes, and pass on changes from the GUI to the model. (Joel: 0% complete, depends on Properties. Can be done concurrently with Conversion of Buildables to Use Properties.)

JOGL Implementation

We could use JOGL (Java bindings for OpenGL) to have continuous scaling and rotation of map views. Michael has a working demo of this. (Michael, Joel: 10% complete. Depends on Model-View Separation, in Joel's opinion, though Michael wasn't sure last time we spoke about it.)

General Aesthetics

We have a lot of badly laid-out GUI elements, dialogs, etc. They're embarassing. These need to be cleaned up, preferably converted to use MigLayout. (??% complete)

Not Release Specific

Web Site Migration

The new web site will have a newer version of phpBB, a better wiki (MediaWiki), and a better bug tracker (Bugzilla), all with a unified login. (Joel: 99% complete.)

Web Site Update

Once we've migrated to the new site, we'll need people to help clean up the wiki, clean up the module pages, etc. This is a job which can involve many, many people working in parallel so long as someone is organizing it properly. (Tim: 75% complete.)

Module Editor Docs

New docs for the module editor. (Ed: ?% complete.)