VASSAL 4 Design Blog

[bdgza]

Through the Recent Changes list I stumbled on the VASSAL 4 Design Blog. It's a very interesting read, but difficult to find.

Is there a listing somewhere to keep track of (new) blog posts?
What is the blog's intended audience?
Are comments/discussion desired/undesired, and if desired where is the best place? In the forums, the discussion tab, or somewhere else?

[Brent Easton]

G'day.

I wondered how long it would take someone to find that I had a bit of spare time over the last few weeks and got a severe case of the development itch while we wait for Joel to complete his building projects. So I was trying to do a bit of a brain dump on various Vassal 4 design issues, while teaching myself C++ in preparation for the project warming up. I needed some way to get my thoughts in order and the blog resulted.

The intended audience was myself, but I am sure it will be of interest to everyone who is interested in the design of Vassal 4.

Yes, I am more than happy for commentary and discussion and here in the forums is probably the best place now that the wiki has had to be moderated. The ideas expressed are very much my own, but based on 35 years of programming experience, including 15-ish (!) years of Vassal development.

Regards,
Brent.

[bdgza]

Hi Brent .

Blog 1: If with the v4 way the module each player uses is checked strictly then you will run into problems if extensions are still a part of v4. If it unlikely that everyone has the same combination of extensions installed. v3 Takes a single checksum to compare of module + extensions. Often extensions don't change the game but just add some scenarios setups or extra charts, which wouldn't break a logfile. Also, it is possible to modify a module without changing how the game works. E.g. in Combat Commander: Europe/Pacific I changed the mouse-over stack viewer so it displays the hex coordinate. That change doesn't affect the game, since it's not any piece definition that I changed. It would be a bummer if v4 then blocked me from playing against others with that modification.

Blog 3-5 scripting: Lua is used all-over as a game scripting language, and although I don't know it (yet), imho it's a good choice.

Not touched on Blog: You did a comparison of scripting options, do you think you will look at comparing file formats, as in XML v JSON v other? I get a feeling things are leaning towards XML, but I am personally much more in favor of JSON. I have no experience in using JSON with C/C++.

[Brent Easton]

Re: Blog 1. Yep, you are hitting on more of the issues that need to be thought through in detail. The problem is that Vassal cannot know whether a given version of a module will or will not affect the behaviour of a given unit. I worry that we will exchange the 'difficult to update save games' issues we have now to 'random weird unit behavior when using different versions of a module' issues.

I do not plan look at file formats, that is not my area of expertise. My understanding is that XML is a good choice as it's structure can be described in a machine readable form (DTD) and then mechanically validated. This will be essential as more people start to fiddle with the buildfile when it becomes more accessible.

I am more concerned about how we handle hidden information (Invisible and obscured pieces, cards in private hands) in a publicly accessible, human readable save game format.

[JoelCFC25]

A couple of comments on the topic of game piece definitions...

If a log file is replayed on any version of the module except for EXACTLY the same one the log file was created with, there is no guarantee you will see what actually happened in the initial creation of the log file. It is up to players to keep track of every version of every module they have ever used if they want ensure log file replayability.

It will probably require players to be far more aware of what version of the module is being used by other players.
Playing rooms on servers should probably have default setting that players are not allowed to join a game unless that have the same version of the module.

Inconsistent behavior if players are using different versions of the module. A single game Piece may behave differently for each player.

Years of PBEM play has long had me convinced that you simply don't want to allow any of these situations to ever occur in the first place. Some sort of smack-you-in-the-face obvious alert/feedback needs to stop players with different modules from connecting to/with each other or to load files that aren't compatible. Right now, VASSAL silently and happily allows all of these.

[richg]

Hello everyone - is Vassal 4 still happening ? I am a developer (C++/Java) w/30 years years experience looking to get involved.
I already have on github a java profiler https://github.com/rguadagno/French-Roast ( 20K+ lines of C++).

I am new to war gaming and just started looking at Vassal in regards to Saipan from Compass - so anyway someone let me know If I can help or just kick around some ideas...

-Richard.

[uckelman]

Thus spake richg:
> Hello everyone - is Vassal 4 still happening ? I am a developer
> (C++/Java) w/30 years years experience looking to get involved.
> I already have on github a java profiler
> https://github.com/rguadagno/French-Roast[1] ( 20K+ lines of C++).

Yes, I still intend to pursue VASSAL 4 as described. I haven't
changed my plans. What's in the queue before it has taken far
longer than I could have imagined, but is nearing completion.

--
J.

[rabbitisle]

Hi Joel, do you still actively work on Vassal 4? If yes, are you planning to provide a repository of your work? Any other plans on development?

Thanks
Harry

[uckelman]

Thus spake rabbitisle:
> Hi Joel, do you still actively work on Vassal 4? If yes, are you
> planning to provide a repository of your work? Any other plans on
> development?

I haven't been able to do anything recently due to having moved house.
My plans haven't changed. As soon as time permits, work will resume
here on a spec and there will be a public repository. Before that I
intend for us to put out a maintenance release of V3.

--
J.

[rabbitisle]

Thanks for the update Joel and thanks for all the work you've put on this.

[Rhett]

I have been looking at the Vassal 4 design blog. I am not an expert in comparing script languages, but Lua looks fine. I got it to run on Linux/Geany and made a few simple scripts.

After upgrading to Linux Mint to 19.1 I noticed that Vassal 3 couldn't run. Linux Mint now uses JDK 11. I managed to download the old JDK 8 and switch to it (with sudo update-alternatives --config java). How long will this be possible? Shouldn't Vassal 3 be changed so that it can run on the latest Java?

Some thoughts on Vassal 4 design:

After having made my first serious module (Verdun: A Generation Lost) I came to realize that the meta-language we use for defining dynamic behavior has its limitations. It is difficult to understand, difficult to change and has poor performance. I am sure it was fine when games where only basic map/counters/dice, but once you want to implement more complex features it becomes unwieldy.

It would be helpful to regard the non-static content of a module as an extension of Vassal itself. You extend (or implement) classes in Vassal to make a game module. A module would be a script file that is either written in the same language as Vassal itself or could could easily import classes from Vassal itself.

It would also be an idea to package the module and the version of Vassal it was made with together, so that old modules with outdated versions of Vassal could still be played. There should be some kind of error message that told you what version of Vassal this module was made with.


I hope development of Vassal 4 soon begins. This is a huge software project. There is not an unlimited amount of time where Vassal 3 can still be used. I am a software developer and hope to contribute in some way.

[uckelman]

Thus spake Rhett:
>
> After upgrading to Linux Mint to 19.1 I noticed that Vassal 3 couldn't
> run. Linux Mint now uses JDK 11. I managed to download the old JDK 8 and
> switch to it (with __sudo update-alternatives --config java__). How long
> will this be possible? Shouldn't Vassal 3 be changed so that it can run
> on the latest Java?

3.3.0 is in preparation now and runs with Java 9 or later. The only
remaining issue to sovle before release is making adjustments to handle
HiDPI rendering.

--
J.

[burzum51]

Hi,

it seems this release will not be based on the current source code. Are there already a source repository for this version or do you wait the fixes to make de 3.x version java 9+ compatibles.

Thanks,

[uckelman]

Thus spake burzum51:
> Hi,
>
> it seems this release will not be based on the current source code. Are
> there already a source repository for this version or do you wait the
> fixes to make de 3.x version java 9+ compatibles.
>
> Thanks,

There's an assortment of design documents and demo code in various places.
Once we've released 3.3.0, I'll be focusing my efforts on assembling and
updating all of that so we can get moving on V4.

--
J.

[burzum51]

Hi,

Thanks for you reply. I will try to help for this version as it's seems no use to understand the current 3.0 branch of code.

Hope this will be soon,
Regards