I recommend the team give some thought to reserved behaviors. Specifically, there are some default behaviors that should be reserved and not modifiable.
A few examples:
Basic Module components (defaults) should not be delete-able by a module designer (including the default piece palette).
Consideration here needs to include not just the needs of the original module designer, but also future module maintainers.
Similarly, there are some defaults for Vassal that perhaps should not be modifiable by module designer. IMHO, some basic Vassal functionality should work the same way from module to module.
A sample Vassal function I think shouldnāt vary module to module is the relatively new āFlareā capability. The consistent ability to point an opponent to a particular part of a board is universally helpful and someone changing the default would be irksome.
Similarly, player preferences (e.g., text size) should not be overridden by a module designer.
The ability to open/close/move/resize windows is something I would like to see reserved to the player, who can and will customize to their unique monitor setup. Having a module ādecideā to move my windows around would be beyond irritatingā¦
I know Vassal is intended to be extremely flexible, which is great, but given that most people play multiple games, some basic behavior shouldnāt be changing module to module. And from an architecture perspective, itās better to decide on some of these basics up-front and early.
Do not, ever, imply that the module developer has restrictions, imposed by the software.
Module developers operate within the constraints of Vassal.
You propose a way less than utopian environment. 1984, inter alia.
Your āsuggestionsā are illogical and spurious.
Go ahead and develop a module, from the get go (as in you are the first to do that game).
Only then would I consider such tripe.
On a more personal note, I would prefer the āflareā function to be assignable. One to the allied team and then to all. Damn difficult to for a team to flare a hex or three when discussing tactics and strategy, when the opposition also see the same thing.
Agreed, one of the criticism often leveled at Vassal is that every module does things differently.
I also agree that we donāt want to unnecessarily force every module into a cookie-cutter mold.
There is a sweet spot there somewhere. Given the level of scripting we want to introduce, customizations of some of these features will probably be inevitable, but I think we can help push things in the right direction by
a) providing sensible, logical defaults (that work cross-platform)
b) providing standard scripts and components that pre-implement standard functionality/
Not sure why there was such a strong negative reaction to what I suggestedā¦
There is always an interesting dynamic tension between standardization and innovation. (and complexity vs. maintainability).
The development team might decide that the existing standard behaviors are exactly right and donāt need to be either curtailed/reduced or extended.
Regardless, architectural design is the right time to at least consider it, when there is no significant code base that the decisions will effect.
Iāve seen a lot of software projects that struggle with code that is virtually impossible to maintain, due to lack of consideration of maintainability, lack of coding standards, architectural entropy, etc.
Just trying to contribute my thoughts, if I think I have something of value to addā¦