[messages] [Developers] Re: Roadmap for VASSAL 4
b.easton at exemail.com.au
Sun May 22 23:38:57 MST 2011
Have spent today catching up on forum news and have read this thread
with interest, though it seems to have been sidetracked into
implementation language issues rather than the larger design issues.
Various ides follow.
Essentially you are proposing to write a Vassal MkII from the ground up,
incorporating all of the hard lessons we have have learned along the
way. Modules are not going to be compatible, but presumably we could
write some sort of importer that may be able to convert a Vassal MkI
module to a Vassal Mk II module. I presume Vassal MkI would be
'mothballed' and left as is for people to keep using if they wished.
One of the best things about Java was that it came along just in time so
that I did not have to learn C++ :) However, I would be interested in
picking up C++ and taking part in a well organised project to write a
new Vassal. C++ has a number of advantages.
Just going over some of your issues you noted in your first post:
- Peer-to-peer communication between clients.
Yes, definitely. Rodney started moving in this direction by writing a
Vassal Jabber module that would allow Vassal to run on any Jabber
Server. I was doing a lot of work on trying to get this working before
my break. Building server capabilities into the clients would be a much
- Moving to XML.
We have discussed this before and it is still my strong belief that the
impenetrable nature of the build file has saved endless problems for us.
Manipulating the build file through the Vassal interface ensures that it
is edited correctly and remains consistent. If you allow free-for-all
editing of the build file, you will get endless errors edited in that
will be difficult to debug. I am not against a move to full XML, but it
must include an industrial strength verifier that can detect any errors
introduced by hand editing, or generation by non-vASSAL tools. The
Vassal definition languange is still going to be immensely complex.
- Model-view separation.
Sure, needed without doubt.
- Hooks for change-listening scripts.
I understand your proposals here and this sort of facility should
definitely be included. This is really the key to the success of the
project, a fundamental redesign of how Vassal will provide the services
we are after for Game Pieces.
The current trait system is built on the Java Decorator pattern and was
developed by Rodney very early on as a demonstration of how to use
Decorator. That was many, many years ago and the drawbacks of this
system only really became apparent recently as the complexity of modules
increased. This was greatly exacerbated by all of the new traits I wrote
to extend functionality and add 'programmability' while staying
constrained to to the Decorator model.
This particular thread has become a bit sidetracked on the issue of
language. While important, it is really a side-issue. The big
issues/questions that I see (not necessarily in order of importance)
We want to keep supporting as many platforms as we do know.
2. Implementation language and libraries.
Very much related to 1.
3. Clean code.
Start clean, keep it that way. Extensive Unit tests, built from the
4. Client/Server/Networking model.
Who 'owns' the game. How do you find an existing game and connect to
it. What happens if the current 'server' goes down.
5. Easy to create simple modules.
As Joel said, it should be very easy as to create a simple module.
6. Game Piece Implementation.
How to implement the myriad behaviour we have now in something that
is easier to use and understand? How do we add additional functionality?
Scripting is necessary. Which scripting language? I did a lot of work on
Beanshell which makes sense in a Java environment, but less so in
Read this topic online here:
More information about the messages