For the longest time, there’s been a plan to work on a better-designed Vassal 4 and ditch Java. Years. But then Covid-19 came along and apparently spurred some new interest in Vassal and there are now some forward-looking plans to significantly improve the v3 client over several releases.
I’ve been avoiding v3 since I heard about v4, but it’s hard to tell if it’s still going to happen. Even desktop Java has improved since the original complaints about it. I don’t want to argue for or against it, I am just wondering: is v4 still likely, or is this resurgence of interest going to keep rolling on v3 into the foreseeable future, and end up being the new goal?
I was hoping to be a part of the new project eventually, learning about it as it grows rather than jumping into that quagmire of v3’s code again. If there’s not going to be a new project, it would be good to know.
I hope this doesn’t come across as pushy or entitled, I understand everyone is a volunteer and things can take time and be interrupted by real life. I am just unclear on the future plans, given the recent (relative) flurry of activity. It feels like there have been more releases this year than over the last five.
Yes, there are still plans for a Vassal version 4. Our ‘Master Designer’ is hoping to start in earnest in December on fleshing out the design.
The current spate of activity on Vassal 3 is partly due to additional manpower, but mainly because we wanted to get Vassal 3 up to a suitable level in terms of bug, usability and performance fixes, plus some new features and get it to the point where we can stop worrying about it so much and leave it to stand on it’s own two feet for a while:) We have managed to fix pretty much all outstanding bugs, including many that have existed for more than a decade, as well as significantly improve performance in several key areas.
I expect Vassal 3 development will quieten down over the next year, however, we do have some keen developers with more ideas for V3.
For the longest time, there’s been a plan to work on a better-designed
Vassal 4 and ditch Java. Years. But then Covid-19 came along and
apparently spurred some new interest in Vassal and there are now some
forward-looking plans to significantly improve the v3 client over
several releases.
That’s only partly due to the pandemic. Work on 3.3 started in Autumn
2019.
I’ve been avoiding v3 since I heard about v4, but it’s hard to tell if
it’s still going to happen. Even desktop Java has improved since the
original complaints about it. I don’t want to argue for or against it,
I am just wondering: is v4 still likely, or is this resurgence of
interest going to keep rolling on v3 into the foreseeable future, and
end up being the new goal?
Once 3.5 is released, my own development time will be going into V4.
We released 3.5.0-beta1 yesterday, so that will be happening fairly
soon.
I hope this doesn’t come across as pushy or entitled, I understand
everyone is a volunteer and things can take time and be interrupted by
real life. I am just unclear on the future plans, given the recent
(relative) flurry of activity. It feels like there have been more
releases this year than over the last five.
From my point of view, the purpose of much of the work since last fall
has been to get V3 into a state where it doesn’t require much maintenance,
in order to give me time to work on V4 while people use V3.
Thank you both, I was looking at the roadmap which appears to contain a significant amount of work for 3.5 and hints of 3.6 as well. I look forward to seeing what comes next.
Not sure if someone already mentioned or if there is already a decision on the tech stack for Vassal 4, but I would like to suggest you to have a look at FoundryVTT and how it was build.
I believe it’s done using Javasript, HTML5, possibly pixiJS and if I’m not wrong a NodeJS server behind it.
It can run locally or on the cloud and you don’t need everyone to have it installed. you just need one instance running and multiple players can connect to it.
I don’t know if you are still pursuing a freeware “business model” but either way, it would work well for both people running it locally or for those that want to put it on the cloud for better access to other players.
That being said, they do offer a set of APIs that other developers can use to implement modules that can be added to the system (if approved). These modules work as independent features that help improve the experience or provide additional functionality to the system.
This tech stack has its own advantages and one good one is that works on any web browser. It is also a good framework to implement 3D stuff like dice, tokens and possible add some more interactivity to other tokens with minimal effort (like having “proper” cards and tokens that can flip in a visual way). Please note that I’m not saying that we should go full 3d with table cameras and such. I have tried many other “more modern” apps that allow to do what vassal does, but I didn’t like them because of the full 3D asped. It’s too intrusive and confusing while a plain top view with some 3D elements it’s easier to follow and closer to the “boardgame on the table”. (Also, despite the need for some improvements, I think that vassal handles components management be).
If any of you would like to have a look at how Foundry VTT works, I would be glad to invite you to check my server and I can show you around for you to have an idea. I would be also glad to help structure the functionalities and interactions for Vassal 4 is you guys want/are interested in such help and ideas (I do that for work, wound’t mind doing it for fun, especially for an app that I use heavily).
I don’t know about the technical side of this issue, but it would be great if Vassal 4 could incorporate some of this functionality as you’ve described. I’m currently working on a module to use with online teaching, and it would be much easier to run it this way rather than making sure students are able to download the program.
What is wrong with Java? Since this game is mainly online, java is super efficient at serialization and deserialization perfect for packet transfer. It’s super secure and runs on Linux and Windows with one build. Java has tons of built in libraries so you don’t have to recreate the wheel and spend lots of time setting up the custom build environment/s.
That said…
It would be really sweet to build in terrain database functionality to make the line of sight tools actually work.
There’s not much inherently wrong with Java, but there’s a lot that’s not great about the design of Vassal as it is now. I’m not sure why you say Java is “super efficient at serialisation” (any more than any other language is) but if a module designer doesn’t take Vassal’s limitations into account, the serialisation of many-layered pieces is such a huge bottleneck that you can wait seconds for multiple pieces to move.
I’m also not sure what’s “super secure” about it, since I could create a module with malicious code in it, and if you opened it you’d have practically zero protection from any unwanted behaviour. That’s not a flaw in the JRE specifically, but Java hasn’t exactly been free of security vulnerabilities over the years either. 50+ in the last two years, by one site’s count.
There are dozens of ways in which it’s unsuitable, which have been detailed extensively in this forum.
If you’d like a specific example, here’s the one I’m fighting with today, which has been an albatross for the entire life of the project: You have to set the maximum heap for the JVM before starting it, without having any idea what the user will load. The contortions we’ve had to go through to accommodate this have consumed months of development effort, all of which would have been unnecessary in any other language.
That’s fine, so we are due for a refactor. While sometimes it’s easier to start over, it’s also nice to refactor off the current code base with an IDE like IntelliJ is brilliant, that should save tons of time.
Alternatively, without garbage collection, all that would have to be coded manually. The nice thing about Java is you generally don’t have to deal with pointers and garbage collection…and if you want to port the code to an web app, you run the code base through gradle, and you have an working web app without having to learn css and html. That’s what I would envision Java’s end state, one code base gives you an website, web app, android app and macos app.
I did see that JVM memory size selector that’s a really nice addition to the program, great job. I’m a little Java biased, but you probably have alot more lessons learned over the years that makes you tired of Java.
You can’t refactor reliably without tests. I started writing tests for Vassal more than a decade ago and made little headway. Almost nothing was in a testable state already, so would have required refactoring prior to having any tests, putting us at risk of breaking things without knowing it. In many cases, I couldn’t establish conclusively how things were supposed to behave, so couldn’t write tests even when things were testable. Finally, the way that custom module code was allowed access to the library code made nearly everything a public API, so it’s extraordinarily hard to refactor anything in a way that doesn’t break modules.
I’ve already been down this road. It’s a dead end.
I’m not arguing in favour of Java, but I still don’t think there’s anything that outright makes it entirely unsuitable that can’t be blamed on the old design of Vassal itself (that’s not an attack on Vassal, it’s just very old and has a lot of old decisions buried deep inside). Problems generally have solutions, but the cost of trying to retrofit them and keep everything compatible is almost certainly too high. I’ll be thrilled to see Vassal get a complete makeover in any language/environment, especially if backwards compatibility is not a concern.
That would be great if it existed as a pre-packaged JVM to bundle for MacOS and Windows and one we could rely on being installed on any Linux distribution, but instead it looks like some patches that haven’t been touched since 2018.
Given that this is something we needed 15 years ago and won’t need once we move on to V4, I’m not expecting it to be production-ready in the window where it would be useful for V3.