[messages] [Developers] Re: Roadmap for VASSAL 4
uckelman at nomic.net
Tue May 24 13:38:58 MST 2011
Thus spake swampwallaby:
> Hi Joel,
Hi! Welcome back!
> 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.
That's the idea, yes.
> 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.
C++ has an undeserved bad reputation, which it got largely from people
who didn't know better misuing it. (One might say that same thing happend
with Java on the desktop...) I'm using C++ myself daily now; I'm happy
> - 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.
It should be possible to use XSD for validating XML. There are numerous
validating parsers out there. The thing about XML which is more
"semantic" than our buildFiles is that it won't be so easy to get wrong
in the first place.
I should also direct you here, to a long-running discussion at BGG about
an overlapping topic:
> - 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.
This is the point where some conceptual work is needed. I don't yet have
a clear picture of what hooks in to the "core" are necessary to make this
part work well.
> 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)
> 1. Cross-platofrm.
> 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
I think we're all agreed on these, at least as goals.
> 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.
This one is going to require some planning regarding how we'd like it to
work. Fortunately, it's mostly separate from other concerns.
> 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
> another environment.
I was thinking of providing hooks into the "core", which can call and be
called from Python scripts.
More information about the messages