Just a request to module designers.
Some things I’d like to see in games where counters can be flipped:
Always have a back side. If it’s blank in the game, have it blank in the module.
Indicate which side is face up. Those of us with poor memories can’t always remember which values are the face up ones. With the physical games, it’s easy to tell from the counter.
Just a couple ideas to help the old memory challanged players. 
Thanks for your time.
Jim
On Mar 4, 2008, at 1:30 PM, jimpyle wrote:
Hmmm. Would putting a bevel on the front side and non on the back
accomplish this? It’s sort of like what you get with die-cut counters.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
On Mar 4, 2008, at 1:30 PM, jimpyle wrote:
As a more general note, perhaps there would be some value in coming up
with a design guidelines document for modules, along the lines of the
GUI design guidelines that Apple, Sun, Microsoft, etc. have.
For starters, coming up with a recommended standard list of key
commands for common actions would be nice. Things like
o Flip counter
o Reset counter
o Remove moved marker
o Clone counter
o Delete counter
o Return to previous location
o Rotate L/R
o Increase/Decrease layer
o Hide/Reveal
…
Learning to use a new module would be easier if all of the modules
used a core set of common keyboard commands.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Telling designers build your module “this way” defeats the entire open ended
structure of vassal and how things can be done.
Each game is different, requires its own unique functions and reserving key
commands may be detrimental in this capacity.
Module design already defaults to ‘recommended’ key commands for traits like
flip, clone, delete etc… If they have changed then there probably was a
reason for it by the module maker
If you lock designers in, you also lock out possibilities
For example, what if I want a hidden delete trait that works off of a
conditional trigger?
Normally I would remove the CTRL D command from the delete trait altogether
and change it to something else and have the trigger do all the work to
prevent accidental user key input.
But if CTRL D is assigned to delete permanently, there is no way for me to
now do this and users can always accidently execute the command
Post generated using Mail2Forum (mail2forum.com)
On Mar 5, 2008, at 10:29 AM, Tim McCaron wrote:
I think we’re in violent agreement.
Just as the GUI interface guidelines issued by the platform creators
are just guidelines, that is the way these should also be seen. They
are style guidelines and not immutable rules.
If there is a compelling reason to do things differently, nothing
should stop that from happening, but insofar as there are common
functions that one wants to use, the means should be uniform across
modules. The point of codifying it is just to make sure that new
module designers are aware of the standard conventions and to
encourage them to think about whether there really is a good reason to
do it differently. Also, by gathering the list in one place, it
provides a convenient reference so that when one is choosing a key
command name for a new function, there is a place to check for
potential conflicts.
In no way is this meant to be a constraint on module designers, but
rather a resource.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Hi,
I was just looking for someway to easily tell if a counter was showing it’s front or back side. A bevel around the edge would work fine.
It’s just a suggestion to designers to make the games easier for players.
Thanks again.
Jim