Reading the documentation, it appears that player sides are mutually exclusive other than “Observer” (default).
I have a game (Europe Engulfed) that could have players as follows:
Referee/Solo (unlimited access)
Observer (View only)
Axis (Germany/Italy)
Allies (Britain, France, Russia, US) (for 2 player)
Britain/US (for 3 player)
France/Russia (for 3 player)
A 2 player game breaks out as Axis + Allies
A 3 player game breaks out as Axis + Britain/US + France/Russia
Ideally, I would like the ability to configure a side such that it can potentially disable selection of other sides (in addition to itself)
IF Player=Britain/US, THEN DISABLE Player(Allies)
IF Player=Allies, THEN (((DISABLE Player (Britain/US)) AND (DISABLE Player(France/Russia)))
I’m pretty sure the existing design allows for proper configuration of who can move what, but I don’t see any obvious way to have a “side” potentially disable other sides
In Vassal 3, this can be done, but it is really, really painful.
You need to create every combination of sides that you may want to use and organise access for them to the appropriate pieces in your module. Create a ‘secret’ password for each side combination.
Then you will need to create a Save game for each valid combination of sides and lock out the side combinations you do not want to use in that save.
To ‘lock out’ a side, set your password to the ‘secret’ password for the side. Load the game and take the side you want to lock out and then save the game WITHOUT retiring. That side combo is no unavailable to be taken. Use that Save game as the basis for building the setup for the combo of sides you don’t lock out.
So, your 'sides will be the ones you show below:
Solo (1)
Axis (2)
Allies (3)
Britain/US (4)
France/Russia (5)
Allied pieces will be accessible to the 4 sides Solo, Allies, Britain/US and France/Russia.
Axis pieces will be accessible to Solo and Axis sides.
For a Solo scenario, you will ‘lock out’ 2, 3, 4 and 5.
For a 2 player scenario, you will ‘lock out’ 1, 4 and 5.
For a 2 player refereed scenario, lock out 4 & 5.
For a 3 player scenario, lock out 1 and 3.
For a 3 player refereed scenario, just lock out 3.
With only 5 combinations, it just feasible to do without going mad. I did this for one of my early modules. Never again
I wonder why you need to have PlayerSide define which pieces a player can use. If I’m an allied player, what are you trying to stop me from doing to the German pieces? Why can’t I join the game as a color side—e.g. the “Red” player, and I use the USA, British, etc pieces because I know that’s what I control in the N-player game I’m playing. I don’t know your game, so I don’t know what I am missing.
This is a “Block” game. Block games typically implement a limited Fog-of-War. You can see there is a block, but until engaged (or other mechanic) you don’t know if it is a weak unit (e.g., Militia-1) or strong unit (e.g., Armor-4).
Thus a stack of 5 blocks, could be a bluff stack (all weak) or very strong… And you don’t know until you engage it…
And of course it also prevents moving units of another side, accidentally (typical use case) or on purpose (rare).
From what Brent described above, it is sufficiently painful that I may not bother and just rely on that ability to Mask a unit and trust that people don’t Unmask.
I know about block games; I’ve done Vassal modules for almost all of Columbia’s catalog and lots by Worthington. In fact, I’m working on a block game at this moment. I just didn’t know why you NEEDED to have player sides defined as you want, and I still don’t. Once you mask a piece, you control it, and your opponent can’t flip it unless you enable them to do so, so accidental flipping is not an issue. As for restricted access, which prevents someone from moving non-owned pieces, I always found it to be a PITA in practice and never use it.
In fact, a lot of games don’t need player sides at all. The only time I think they are important is if players have private windows, which usually indicates the game has screens to hide information.
But what if you have two players playing the same side and you want them to both have access to the same masked pieces? Not possible in Vassal 3. Sides in Vassal 3 aren’t really sides.
I agree. It makes off-line/pbem play extremely difficult. Except for the ‘Observer’ case. I believe the default should be that Observers have an absolutely minimal access to the game and definitely should not be allowed to move pieces, execute right-click commands or click any toolbar buttons apart from opening chart or map windows.
Agreed. Many Vassal modules are basically implemented as sideless, the definitions of ‘Sides’ is more to be able report the ‘Side’ name in the chat window when they do something, rather than any intrinsic link between the defined ‘Side’ and the pieces in the game.
In Vassal 4, the dynamically allocated Seat names would serve this function, the actual defined ‘Sides’ would be internal to the module.
I would imagine in Vassal 4, the default would be to create one Side (Players? Everyone?). Any player Seats created would be given access to this one side. This would basically be the same as the current ‘sideless’ Vassal default. But Observer seats would NOT have access to the default side
Team play, eh? Share a password. I believe passwords are seen as a security feature, but really, they are just keys that link players to pieces. We are not accessing bank accounts here.
And I don’t like trails/paths/whatever they are called either. I tried them, but they just give me headaches.
You need sides for private windows, I think.
This may surprise you, but I hope Vassal 4 as currently envisioned never sees the light of day, and considering how much work and dedication it takes to create a framework like this from scratch, it’s looking good that it will never happen. Fingers crossed.
Oh, Vassal 4 will happen. Module Designers and Players both want more, but Vassal 3 just can’t support it, it is being pushed as far as it can go.
However Vassal 3 will be with us for a long time to come. I have serious doubts about being able to auto ‘convert’ or ‘migrate’ a Vassal 3 module to Vassal 4 and have it work exactly the same except in the simplest cases. Even ignoring all of the custom code that many modules contain these days.
I think we will be able to do a very good job of creating a Vassal 4 module that looks the same with the same maps, windows, pieces etc. However, I have my doubts about being able to simulate the complexity (some would say chaos) that arises naturally from the layered Decorator construction of the game pieces. The symptoms will appear as things like right-click menu commands missing/appearing when they shouldn’t and automation breaking and will be devilishly difficult to debug and fix.
For more complex modules, I think our conversion will produce something that looks good, but the module designer will need to spend an amount (?) of time, tweaking, debugging or re-implementing using the new and improved V4 features.
There is now a vast library of Vassal 3 modules, many of which are used, but not actively maintained and each will require time and effort to migrate them to Vassal 4 and test and fix issues. I suspect plenty of people just won’t bother.
When someone redesigns a system and advertises it as the successor, I believe they are on the hook to be strongly backward compatible, and I’m not talking about a conversion process. I spent my career (I’m retired now) designing and writing systems–mostly frameworks like Vassal, and I have first-hand experience. It’s looming disaster. Vassal now does not have a crisp, well-defined public interface, so it has the likelihood of being a complete mess with dozen of problem reports for each module. Imagine Microsoft telling everyone they are rebuilding Word from scratch in a different language, your documents may no longer work, you’ll have to learn a new interface, and if the docs do work, they won’t look quite the same. No way, and I strongly oppose it.
HOWEVER. If you built a new system that had a different name and did not actively supplant Vassal, then that’s different. In this case, it would not be on the backward-compatible hook, and you could talk about migrating modules to the new system (e.g. “Sauron” v1). You would not be threatening to disrupt users like me who are happy with the current state of affairs. I would support that approach, and you discontinue the whole “Vassal 4 is coming for you” thing.
Personally, I have never considered the possibility as realistic that V4 would run V3 modules unchanged, or that it was ever going to be anything other than Sauron V1. If you have picked up that idea from the discussions that have occurred here, then I think you have picked up a mistaken impression.
I am more than happy with the statement that V3 modules are incompatible with V4, however, if you use this nifty migration tool, the result running on V4 will be somewhere between 95% and 100% similar to what you have on V3 (excluding all custom code).
I’m not sure where the whole You would not be threatening to disrupt users like me who are happy with the current state of affairs thing comes from. Vassal 3 is an open-source project and is not going anywhere. No-one will stop you creating or playing Vassal 3 modules. I would see V3 and V4 running side-by-side for years to come. Joel is likely to halt further development work on Vassal 3, but anyone else is welcome to take up the slack.
It comes from the fact that v4 shares the same name and is a version bump. When someone does that, I think they are making compatibility promises they can’t keep. As for a 90% migration success, I suggest you wait and not make promises. Also, I don’t think anyone has issued any statement about what v4 goals are. I remain skeptical. Good luck though.
I have to say I have 2 conclusions about the proposed changes in VASSAL 4.
1.) They are a really good thing.
2.) Some sort of name change would be appropriate. It could be a name that reflected its VASSAL heritage in some way, but a break in compatibility does really cry out for a new name. With a good migration tool I cannot really see anyone wanting to continue VASSAL 3, but it would be a lot less confusing for everyone.
Thanks for this, I never realized that the “mask” functionality worked that way… Given this, understand & agree with the point that it’s probably not necessary for many games to implement player sides.
