I’ve been having a discussion with someone on BGG about adding more
facilities for rules enforcement, which I see as a related issue, so this
has been on my mind some lately.
Here’s the problem as I see it: Some kinds of automation impose some
preconditions on how you should interact with the module, but at the same
time they lack the power to enforce those preconditions. This is like
asking someone to walk a narrow ledge without providing a handrail.
I don’t know where to locate the cause of the problem. Is it that module
designers are not considering what will happen if someone goes off the
rails? Are we not providing module designers sufficient tools to do this
properly?
My impression is that module designers for Euro games are making much
heavier use of automation than wargames. I don’t yet understand why this
is—I’d expect to see the opposite, since Euro games tend to be much
simpler, and so I’d think there’s be less need for automation.
It is a combination of both. In some cases the designer has failed to account for every conceivable possibility, or hasn’t “fixed the bolts on the handrail” as it were allowing people to fall off the cliff and in others it is because although they have tried to automate there are still limitations defining the handrail or easy loopholes to avoid the ledge because of the engine
I think it makes sense seeing it happen this way because the tools available now can handle the simpler ruleset without much problem as is
I have been experimenting with VASSAL for only a short time. My experience is that lack of documentation lies behind most problems. If there was a clear “how to” guide both for design and module usage, it all might be a lot more accessible to non-computer-savvy people.
I’m not knocking VASSAL. Far from it. Frankly, it’s a wonderful application (or set of tools; whatever the proper description ought to be), and I wouldn’t be without it now. But it was difficult to get started; I would probably have given up had it not been for the forum.
One thing which does confuse me though is the constant drive to update VASSAL. Until it was clearly explained to me via the forum, I didn’t realise at first that the idea was just to provide a virtual game playing environment; my initial impression was that rule enforcement and automation was all part of the package. Once I was set straight on that, I rather liked the freedom of not having to bother with added complications. So it is a little confusing to find that the people who make VASSAL are forever adding gadgets and tools to add the very automation which appeared not to be particularly important in the beginning.
I have no experience of Zuntzu or Cyberboard. Do either of those offer automation? Are they easier to use or easier as regards module design? They are not options for me, as a Mac user, and I have no intention of learning to use another game-board application anyway, but I am curious to know what attracts people to them.
The vast majority of these “enhancements” have nothing to do with
automation. An enormous number are simply bug fixes. Some are
implemented to make VASSAL more internally consistent. Many
enhancements exist to overcome the fact that players are not face to
face.
However, if you’ve been following the discussion on this list, you’ll
know that bug fixes are the #1 priority right now. The enhancements
that I’m following don’t add to automation whatsoever.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
I agree and raised the issue of documentation earlier in this thread.
When I started just a couple of weeks ago I was stunned to find the Wiki so barren. It’s obvious that there are some very knowledgeable people here regarding Vassal but for newbies there is very little by way of documented examples.
The Vassal documentation is very good up to a point, but worked examples would be extremely helpful.
Given that the order of traits seems to be one of the biggest stumbling blocks for newbies it would be useful to see some worked documentation on how these work - for instance, the interplay between layers and rotation, which took me ages to work out and still causes me some problems.
It seems unfortunate that each and every person who comes to this excellent resource has to reinvent the wheel so to speak and start the learning curve (which appears to be getting steeper) from scratch.
Ed Messina is heading up our documentation effort. He could probalby use
some help with producing documentation for module designers.
Michael’s comment on this is correct. If you look at our change log, nearly
all of the work since late 2007 has been bugfixes or features which aren’t
related to module automation (SVG support, the Windows installer, the Module
Manager, the ADC2 importer, automatic bug reporting, to name a few).
No. They provide basically nothing in terms of automation. If you have 100
fired artillery counters to flip back to their fresh side, you’re going to
be flipping all 100 individually.
It’s hard to make a comparison in terms of ease of module design, because
the capabilities of the three programs are so different. A finished ZT or
CB module is going to have a lot fewer features than a finished VASSAL
module. I find CB’s module editor clunky, but there’s really no alternative
to using it if you’re making a CB module, since the CB file format is closed.
ZT uses an open, documented file format, which you work with directly in
an editor if you’re making a ZT module. It probably is less effort to make
a finished ZT module than it is to make a finished VASSAL module, but it’s
also less effort to build a rowboat than it is to build a battleship.
Ease of use: I find CB to be unintuitive, but once you figure it out, it’s
the same for every module. There is so little to ZT that there’s barely
anything to figure out. There are a lot of differences between VASSAL
modules, so how easy any particular module is to use depends on the choices
the designer made. Here again, the comparison is not straightforward—
some VASSAL modules will be more complex to use because they let you do
more, but sometimes that extra complexity makes them easier to use. Whether
hunting down each and removing every disrupted marker on the map individually
counts as easy depends on the user.
People like ZunTzu because it’s shiny. People like Cyberboard mainly for
its PBEM support (which I would say is a bit better than ours right now,
though that should change for us with VASSAL 3.2).
I’ve loaded the TtA module a few times for troubleshooting. It strikes me
as hugely over-engineered. The game is possible to play face-to-face in a
few hours, right? I don’t see why the module needs to track so much stuff,
rather than just letting the players do it with some tokens.
I find this frustrating as well, but what do you suggest we do? None of us
designed the TtA module, e.g.
I agree that we need to do something to increase the quality of modules;
I’m not convinced that ratings are the way to do that. My impression is
that the current site discourages people from contributing improvements
to modules, and once that’s fixed, we’ll see gradual improvement in module
quality as modules get worked on.
Ratings for things like this are too easy to game, I think; and often the
only people who bother to give ratings are those who have something to
gain or an axe to grind.
I think it would be enough if you could be sure that not using the built-in
automation would not leave you in a bad state. I don’t really know how we
could detect or enforce this, though.
I can’t speak on the others, but the automation in TS is not so intrusive.
You can just ignore the menu items which apply events, for example, and
apply them by hand if you want.
It’s per-page. That poses a problem when you have multiple versions of a
module available from the same page. E.g., suppose that version 1.0 of the
Foo Wars sucks, but 1.1 is great. If you throw the ratings for both versions
together, you won’t get an accurate idea of the quality of the module.
I am certainly not really qualified to speak on the subject but… essentially, you have the team-engineered VASSAL engine with what boils down to a bunch of single-individual-engineered modules. So the kind of benefit you get in the engine from open-source co-operative development (ie ten minds are greater than one) is not generally seen at the module level, in fact it is almost discouraged, at least that is my impression.
Now, if TtA is over-engineered, then someone who understands why ought to be able to take the module, which is published here so openly licensed, and create version which is either ‘fixed’ or else simply cut-down so that players can use that instead, or offer help to the original module designer to do the same if he is still around and willing to take the help. If there is an impasse there, then there should be room here to publish a competing module and let the open market of the player community decide which it prefers.
I don’t think this is really prevented by the current system, although perhaps not encouraged. But ultimately like anything else on VASSAL it takes someone to decide to pick up the ball and run with it.
Meantime yeah I have to say anything that encourages people to contribute improvements would help, as would anything that makes VASSAL module design more approachable to more people.
That’s part of my point. I’ve seen a lot of posts to the forum which
amount to “Thing X is broken/wrong/stupid in module Y, how do I get this
fixed?” and in many cases, there’s no obvious path to pursue because
it’s not clear how to get in touch with the module maintainer, or because
there is no module maintainer, or because it’s not clear how to fork the
module and improve it independently. If we could get more people involved
in module design, I think that we’d get better modules.
I’ve had this problem myself a few times now. I suspect that I encounter a
lot more module bugs than the average user, because often I’m seeing module
bugs before we’ve determined where exactly the problem is. For the bugs
which turn out to be module bugs, I frequenly have no clue who to tell to
get the problem fixed. (And believe me, I want to get module problems which
generate bug reports fixed more than anybody, since I have to deal with
the bug reports.) If I’m having a problem with this, then I think it’s safe
to assume that I am not the only one. My response has been to file all of
these module bug reports away for later. Someone who is not frequently
triaging bugs in our bug database (i.e., basically everybody except Brent
and me) is, I expect, going to be completly stymied and just give up.
I think this thread is a great start. We’re talking about it, acknowledging it’s a problem and making it public that the design of TTA is not a good one. If most module designers refer to the forum, hopefully they will see this discussion and make efforts to avoid their module being used as an example of what not to do!
I’m told the TTA module does work but it takes half a game to figure out. There are still some big problems, even for experienced users. e.g. Undoing a re-deal of the card row involves something like 30 clicks of the Undo button! So it’s best to avoid your regular 4am Vassal Through the Ages session.
On new website if a bug comes up that is a module bug and not a engine bug, the bug can be reported/tagged/published/something like that directly to that modules web page for any to tackle. Because the module pages will be in wiki, users can edit pages marking bugs they pick up, intend to fix etc…
Somehow have a way of embedding direct email link to author in module (sort of like a field in general options - “Module maintained by: foo email address”. Any bug generated with that specific module version goes not only to Vassal but also to the author. Link also provides users direct contact for other issues. If an author doesn’t provide an email in the specific module version, one could assume that they do not intend to support that module further and anyone could pick it up and continue
The problem with 2 would be retro engineering this back into already existing modules that may not be revised (or need to be) for a long time to come - not very pretty but just some rough ideas - anyone got some others?
From: Joel Uckelman uckelman@nomic.net To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org Sent: Tuesday, April 14, 2009 9:49:29 AM Subject: Re: [Module Design]Re: Module Design and Game Automation.
Thus spake “IrishBouzouki”:
That’s part of my point. I’ve seen a lot of posts to the forum which
amount to “Thing X is broken/wrong/stupid in module Y, how do I get this
fixed?” and in many cases, there’s no obvious path to pursue because
it’s not clear how to get in touch with the module maintainer, or because
there is no module maintainer, or because it’s not clear how to fork the
module and improve it independently. If we could get more people involved
in module design, I think that we’d get better modules.
I’ve had this problem myself a few times now. I suspect that I encounter a
lot more module bugs than the average user, because often I’m seeing module
bugs before we’ve determined where exactly the problem is. For the bugs
which turn out to be module bugs, I frequenly have no clue who to tell to
get the problem fixed. (And believe me, I want to get module problems which
generate bug reports fixed more than anybody, since I have to deal with
the bug reports.) If I’m having a problem with this, then I think it’s safe
to assume that I am not the only one. My response has been to file all of
these module bug reports away for later. Someone who is not frequently
triaging bugs in our bug database (i.e., basically everybody except Brent
and me) is, I expect, going to be completly stymied and just give up.
Yeah, ratings is a discussion I didn’t want to be personally involved in; It’s a touchy subject, virtually any custom ratings system can be argued to be skewing results. Or not.
The undo function in automated mods is indeed a frustrating problem, because when you hit undo it is only stepping back the last keystroke, but in many cases of automation there are alot of background hidden keystrokes going on to make that one keystroke the user executes actually happen and they have no idea how many steps to actually “undo” the single action they performed
What would be neat here is a way to “group” a series of keystrokes that are performed for one action much like you would group images in a graphics program so that when a user does undo an action if it is part of a group, all of the keystrokes within the group are undone
I think this thread is a great start. We’re talking about it, acknowledging it’s a problem and making it public that the design of TTA is not a good one. If most module designers refer to the forum, hopefully they will see this discussion and make efforts to avoid their module being used as an example of what not to do!
I’m told the TTA module does work but it takes half a game to figure out. There are still some big problems, even for experienced users. e.g. Undoing a re-deal of the card row involves something like 30 clicks of the Undo button! So it’s best to avoid your regular 4am Vassal Through the Ages session.
this is a good and welcome thread. i agree that one of the things that seems to scare people away from vassal is a (largely misplaced) perception of complexity. Of course, some modules appear more complex because the game itself is complex. But newbies don’t recognize the source of the complexity and just ascribe much of it to vassal rather than acknowledging that they are trying to sit down and play a game which involves 20 races battling for 63 planets with technologies from stone age to star wars
the question of automation is a good one. there are obvious benefits for experienced users, and obvious sources of confusion for new users of a mod. would this sort of thing be a good usage of module extensions? i’ve never built an extension, and don’t know much about it, but maybe good mod development practice should be that a mod contains the basics, where most things are click and drag by hand type mechanics, and then extensions could be used to implement advanced features for experienced users. would this be a reasonable use for extensions?
Wow, that’s awful. It hadn’t occurred to me that undo works that way.
I wonder if there’s anything simple we can do to make groups of actions
atomic w/r/t undo? Probably Brent would be most qualified to speak on
this point.
I was planing to have each module represented in the new bug tracker,
so that bugs can be assigned to and reported against modules. Maybe
I should add a link from each module page to a query showing all
reported bugs for that module, and possibly also a link for reporting
new bugs against that module?
Since user accounts are unified across the whole site, anyone with the
ability to edit the wiki can also report bugs in the tracker.
One of the things which I was hoping we could do when we make a pass
over all of the module pages is determine who is responsible for each
module. Bugzilla can have a default person who is emailed for bugs
reported against each component, so it would make sense for the module
maintainer to be that person for each component which is a module.
