V4 Architecture - Vassal vs. Module vs. Player

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.

1 Like

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.

Are you ok? That’s not a polite way to interact with other people posting here.

Some standardization across modules would do a world of good.

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/

1 Like

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…

Appreciate the work on v3 and future v4…

2 Likes