After a very pleasant and contemplative walk with my dog, I have come to the conclusion that shilinski is 100% correct and Vassal 4 should not be called Vassal 4.
The reasons he put forward are quite valid:
An expection of the level of compatibility that will be provided by Vassal 4 to run Vassal 3 modules.
Confusion over the future of Vassal 3 and Vassal 3 modules after Vassal 4 is released.
We currently have 2273 module pages and many 100’s, if not 1000’s of users, many of whom do not follow Vassal developments closely. There is much potential for confusion.
However, I disagree that we should drop the Vassal brand name. Vassal 4 will be a natural progression from Vassal 3, designed to achieve the same goal.
My preference is that when we get to the time when Vassal 4 is actually happening, we re-brand Vassal 3 as Vassal Classic (v3.3.0) and release Vassal 4 with a new name as version 1.0 to clearly delineate it as a different product.
As it would be a new engine, how about calling it by a new name entirely?
maybe something based on the original name?
Vessel?
Then when people search for “vessel” modules, they won’t get results or questions about “vassal” modules… Less confusion would be better here (less forum posts with “this new version of vassal sucks, my module, with loads of custom java classes crashes in it”)
This would also make it possible to make a “Vassal Classic 4.0”, written in Java, reusing old code but breaking compatibility with (some/many/all) old modules, running in a single JVM, with a new GUI e.g. JavaFX, maybe even running on tablets and mobile.
As for the name, the ones with the additional suffix sound good, “Vassal NG”, “Vassal Plus”, keeping the brand name, telling the users that there is the same team behind it, with their several decades of experience.
Thank you. I expect it was your dog though who convinced you? I bet she didn’t mention it, but she and I spoke privately about the matter ahead of time. She said she would do what she could if I only gave her a biscuit.
Doing this is doing you a huge favor because it throws off the albatross of backward compatibility. That is an enormous hook you were on. Oh, I know you want to try, but you can pick and choose more freely.
What puzzles me yet is why do it. What are the goals? Specifically, what would “Vasovasostomy 1.0” give players that they already don’t have? If you are just trying to get back to where we are now with a different framework, then I don’t think it’s worth the enormous effort. If it truly is a next generation step, I would first stop and look around. See Tabletopia, Tabletop Simulator, et al. THAT is the next generation.
I have created a new (and for the time being empty) repository at GitHub which I have called A Lua-based Boardgame Engine or Alben (!?).
It will be used for my own investigations into Lua and Qt. I don’t want to mix these investigations with the Vassal name, which is an old and well established name.
If a new Vassal can no longer run old modules, then it may very well be called something else. I suspect a new Vassal will look and work very differently from the old one. How about (f.ex) implementing animations on the map or an AI opponent. The possibilities are many.
It boils down to how much time developers are willing to use on it. Here no one is paid.
What is about Tabletopia and Tabletop Simulator you like? Apart from a flashy website, a price and nice 3D visualisations, they seem completely shallow and incomplete compared to the feature set supported by Vassal. I see zero support for hex based games for instance.
Vassal++ Objectives:
Get back to where we are in terms of functionality, but with a modern, clean, supportable, efficient, expandable code base that will support ever larger modules without choking as Vassal 3 is starting to do.
Create a clean separation between the model, view and control aspects of the engine. This will allow alternate Visualisers to be written to provide 3D views, board fly-overs etc. [i.e. Flashy Graphics ]
Simplify the Module Creation process.
Implement a full scripting interface providing a full and rich API and multiple hooks to allow scripting and behaviour modification of all game features.
Create an underlying formalised logic that can be used to do cool stuff(I don’t know, ask Joel, he’s the Logic Professor).
The new Vassal will run old modules. It just remains to be seen how close we can get with an automatic conversion process. We have to be very careful how that is ‘marketed’, hence my suggestion of an external module converter.
I expect we will be able to 100% convert the ‘look’ of the module. All images, piece, maps, piece palettes, chart windows, decks, at-start stacks etc. etc. will have some sort of corresponding feature in the new Vassal.
I also expect we will be able to 100% convert all of the individual pieces and prototypes into something equivalent that will mostly work the same as they do in Vassal 3.
Here’s where we run into trouble though. Some behaviour in Vassal 3 pieces is emergent from the Decorator trait stack and will be extremely difficult, if not impossible to completely 100% reproduce in a model that does not have a Decorator trait stack. In many cases, I expect the differences to be insignificant in terms of game play, but there are going to be a set of issues that do effect gameplay in some games. These will be impossible to predict automatically.
The upshot is that a converted module should be pretty damn close to the original, but will need testing before use.
Obviously, any module with custom code will not work properly, but the the components will be fully converted and the module designer will have to re-implement the custom code using the Vassal++ scripting capabilities.
No Linux support and that in 2020 where most good games come with Linux support. That’s more like past generation.
For that, the engine would need to understand the rules of all modules. For that, the module developers would need to implement the game rules in each module, they would need to write code for this in some kind of programming language. Right now anyone and his grandmother are able to produce a working Vassal module by clicking in a visual editor.
Tabletop Simulator (TS) has a perfectly functional Linux release. As for Tabletopia, while I have been unable to get the Windows application to run at all under Linux (with WINE), the website works just fine (on Firefox, at least). Sadly, there are still many good games that don’t come with Linux support. And if they use anti-cheat libraries, WINE probably won’t work for them, either.
As an aside, I must admit I much prefer VASSAL to either TS or Tabletopia, as the automation available in VASSAL is much more important (to me) than the graphical bells and whistles of the other two. From what I’ve seen so far on Tabletopia (I’ve played about half-a-dozen games on it so far in the past couple of months), the only real automation is game set up, and even that isn’t very good (for example, the Scythe module always starts with the same Faction and Player boards in exactly the same locations, rather than randomizing them). Well, and some pieces will snap into the proper place when you drop them close enough, and possibly rotate/flip as appropriate. I’m not sure about TS, because while I own it, none of my friends do, and so I haven’t bothered playing with it much at all.
I didn’t say I liked TTS et al. I tried TTS a couple times, and I felt I was playing a board game with mittens on. I didn’t try the others because I had to register first, and I wasn’t doing that. My point was someone examined stuff like Vassal and decided they could do it better, and they have already arrived at where you might want to go. You might say “it’s only got 3D, and this and that,” but their users are saying “it’s 3D! And this! And that!” I prefer Vassal myself, but then I wouldn’t mind playing Zork again. I’m that old.
Regarding your list of goals, I noticed they all targeted the module maker, not the PLAYERS. Oh, you hope indirectly to give the players something as a consequence, but it’s all about the creators. This does not cut it, in my opinion. I don’t think it’s worth the enormous effort. Joel U in another thread talked about how he realized after looking at the code what a big job it would be to refactor it and he might as well start over, and that fixing things might break other things (a “soft” public interface). Well, to me he is just taking the long road, and when he gets to the end, he faces the same compatibility problems that anyone who took the other road faces. The trouble is Vassal’s public interface has been defined by the users, and no one knows exactly what that is. My advice is when, or more likely if, you create Vassal NG, you completely forget backward compatibility, and if you tackle that it, it is a post-Vassal NG project. I think your biggest hurdle is releasing a bug-free product because if you don’t, well, forget it. And I’m not naive that it won’t be a hurdle.
