Module Design and Game Automation.

[Tim_M]

@uckelman

Thus spake Timothy Mccarron:
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.

–
J.

One thing (slightly off tangent) but would also go a long way in Module design is a visual editor - weve briefly skimmed this before and it would be a major diversion (perhaps long term goal). This could let designer see the build in a different manner to find where things are breaking instead of chasing things down in the current tree view editor. The visual editor could be drag n drop of traits/components and toggles back and forth between tree view.

Put together a little picture of the idea below. It might be here in this editore view where you could drag a box around functions to create “key groups” that register as a single step action with the undo/step forward processes

[Brent_Easton]

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.

The development of tools to automate functions within VASSAL is an on-going project of mine that started about 4 years ago and has a couple more years to run. Other programmers have other priorities and concentrate on those areas. We all have visions of where VASSAL should be and use our limited resources to gradually move VASSAL in that direction.

As the principle author of VASSAL automation tools, I am actually not a great fan of extensive automation. Everything I have written has been to solve specific small automation jobs in modules I was developing.

My general automation philosophy is to build facilities that can optionally be used by players to overcome specific game rules/issues that are tedious or prone to error if done manually. If I had to lay done some guidelines on building automation, they would look something like this:

• Include a ‘Getting Started’ Help item that clearly points out how and when to use any ‘features’ built into the module.

• Don’t automate for automation’s sake. What is the specific game issue you are trying to resolve?

• Automation should be fail-safe - It should not matter if you use a feature or not. Don’t have different pieces of automation depend on the state set up by other pieces of automation. Things should not fail because you did not do A, B and C before doing D.

• Don’t make it too complex - Less is more.

• Automated tasks should report to the Chat Window when they activate.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

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?

I think this is very much a part of it. Most modules are developed by a very small community of a few people who come to know the foibles of that module intimately. The module develops over time and the community develops with it, and all ‘know’ how to use the module ‘correctly’. Suddenly, the module is discovered by some players who don’t have that shared history, and it all falls apart. It is very difficult for the small development group to take a step back and view the module without preconceptions.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

We all have visions of where VASSAL should be and use our limited resources to gradually move VASSAL in that direction.

This is the crux of the problem and one of the shortcomings of Open Source projects in general. In the corporate world people are paid to do the boring stuff like write mission statements, provide clear direction and make sure software behaves in a way that benefits the user. But in OS this entire layer is missing so we just add stuff that would be cool; The end result being a product which is less than the sum of its parts, and I think Vassal is heading this way. The more unnecessary features we add, the worse this will get.

[bsmith]

I think we need to make the following assumption:

• Module designers will not read documentation. Some dude from BGG who wants to churn out Blue Moon City for his first module is just going to kludge through it and make a mess. He probably doesn’t understand program flow so he’s going to put all sorts of circular triggers in. He will tell everyone he has a working module and Vassal is going to look crap.

Can we at least shield them from all the advanced functions? I think someone suggested Beginner and Expert modes in the Module Editor.

[Brent_Easton]

*********** REPLY SEPARATOR ***********

On 15/04/2009 at 5:48 PM bsmith wrote:

We all have visions of where VASSAL should be and use our limited

resources to gradually move VASSAL in that direction.

This is the crux of the problem and one of the shortcomings of Open Source
projects in general. In the corporate world people are paid to do the
boring stuff like write mission statements, provide clear direction and
make sure software behaves in a way that benefits the user.

Yes, it is same old problem that is the bane of all utopian collaborative collectives - Who cleans the toilets?

But in OS this entire layer is missing so we just add stuff that would be cool;

To be fair, we did run a vote and added the most popular cool stuff.

The end result being a product which is less than the sum of its parts, and I
think Vassal is heading this way. The more unnecessary features we add,
the worse this will get.

A specific list of unnecessary features that are about to be added, please.

I don’t want to be wasting my time adding unnecessary features and I completely agree that I have little perspective on this subject.

However, even leaving out all of the advanced stuff (which when used well is what makes VASSAL shine), is still not going to stop people from making crap modules that are going to turn other people off using VASSAL. Even on-going bagging of specific modules on this forum makes no difference, this is not where people first look for information.

This is where the new site with Reviews, and dare I say, Ratings, comes into play. The best part of BGG is the reviews and rating comments. I ignore the numbers and just look at the brief comments left by people who. I look at the first and last few pages of these to get an idea of whether the game is any good.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

*********** REPLY SEPARATOR ***********

On 15/04/2009 at 6:05 PM bsmith wrote:

I think we need to make the following assumption:

• Module designers will not read documentation. Some dude from BGG who
  wants to churn out Blue Moon City for his first module is just going to
  kludge through it and make a mess. He probably doesn’t understand program
  flow so he’s going to put all sorts of circular triggers in. He will tell
  everyone he has a working module and Vassal is going to look crap.

Except that his module page at vassalengine.org will have 5 pages of reviews saying what crap the module is. He gets the feedback he needs and fixes the module. Or someone else picks up the ball and runs with it and you get a link to BMC mark II.

Can we at least shield them from all the advanced functions? I think
someone suggested Beginner and Expert modes in the Module Editor.

Sure, sounds like a great idea. Where do you make the split?

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

@Brent Easton

Sure, sounds like a great idea. Where do you make the split?

Yeah that’s a tricky one, I don’t use any advanced features myself.

We can brainstorm a little to start:

• Default traits for everything. All pieces have stackable, delete, free rotate, label, clone, mark moved.

• All Maps have zoom, overview window, hide/show counters, Mark all pieces as not moved.

• A Piece window is mandatory. All pieces and cards should be freely available in the module.

[bsmith]

• By default everything should be disabled, then we can enable functions for Beginners.

• Disable all piece traits except the following:

Delete
Clone
Layer
Prototype
Label
Report Action
Can Rotate
Return to Deck
Mark When Moved

[Brent_Easton]

• Disable all piece traits except the following:

Delete
Clone
Layer
Prototype
Label
Report Action
Can Rotate
Return to Deck
Mark When Moved

I would include Send To Location in a minimal set.

If you are going that far, you could possibly have a Middle level with everything except triggers, GKC’s and properties.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

Your talking about something slightly different here. You talking about ‘New Module’ and ‘New Piece’ setting up a whole bunch of preset ‘stuff’.

I thought that you meant that in ‘Beginner’ mode, we hide certain traits and components from appearing on any menus. e.g. Trigger Action, All Global Key Command stuff, All Dynamic and Global property stuff. What about prototypes?

I am not against the idea of more ‘stuff’ being set up by default when you create a new module or gamepiece, but I know we will have violent arguments over what that ‘stuff’ should be Whatever we chose is going to become the de-facto VASSAL standard.

While I am opposed to including the Delete trait on any sort of production module, I agree that it is a good idea on a newb module. I also don’t like Clone at all, except on Markers that need it. I also would not include rotate, but that’s just that I have never used it in 20 odd modules. (Well maybe once).

What about a sort of New Module Wizard for beginner mode that asks a series of questions and sets the ‘stuff’ up for you?

We can brainstorm a little to start:

• Default traits for everything. All pieces have stackable, delete, free
  rotate, label, clone, mark moved.

• All Maps have zoom, overview window, hide/show counters, Mark all pieces
  as not moved.

• A Piece window is mandatory. All pieces and cards should be freely
  available in the module.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

@Brent Easton

I would include Send To Location in a minimal set.

Yep, agree.

@Brent Easton

If you are going that far, you could possibly have a Middle level with everything except triggers, GKC’s and properties.

Yeah might be worth a shot.

[Tim_M]

Isn’t this like creating something akin to having 2 editors? The new
designer would discover this as it would have to be designer manipulated for
advanced users and figure why am I riding the bicycle when I could be using
the car

I don’t know how that wouldn’t leave the new designer feeling like they are
not trusted to use the tool and leave a bad taste in their mouth

A wizard though might be much more palatable.
A series of questions could be asked, to figure out what the designer wishes
to do, then when its done just give access to those traits that they need to
accomplish there task. Like the startup wizard it could simply be bypassed
or turned off for users more advanced/comfortable with working with the
complete editor as is

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

@Tim M

I don’t know how that wouldn’t leave the new designer feeling like they are not trusted to use the tool and leave a bad taste in their mouth

I would choose pissed off designers over pissed of players any day of the week!

[bsmith]

@Brent Easton

Your talking about something slightly different here. You talking about ‘New Module’ and ‘New Piece’ setting up a whole bunch of preset ‘stuff’.

It was worth a shot, just thought I would Sedgway it in there.

@Brent Easton

but I know we will have violent arguments over what that ‘stuff’ should be

I’m actually pro-arguments. If no-one says anything for fear of arguments then nothing improves. I would rather we fight and have a better Vassal, but I understand I’m probably in the minority opinion here!

@Brent Easton

What about a sort of New Module Wizard for beginner mode that asks a series of questions and sets the ‘stuff’ up for you?

Yeah could do, more work though. Needed?

[Brent_Easton]

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

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.

Wow! I am amazed also. This is news to me. My understanding is that all commands executed by an individual ‘Trigger Action’ or ‘Global Key Command’ are combined as a single action and logged as a single undoable action.

… time passes…

I have been doing some investigation and my understanding is indeed the case. For example, if you setup a trigger that rotates a piece and then a Send to Location and execute the trigger, undo will undo both the rotation and the STL.

however…

The problem child seems to be the ‘Moved Fixed Distance’ trait. Due to various bugs, caused by pieces being moved multiple times within the one automation sequence, the way the MFD works was changed. All MFD’s initiated by a single keystroke are ‘batched up’ and run in a separate thread, generating individual MoveCommands for each movement.

Can someone who has this problem please confirm that it is just a problem where ‘Moved Fixed Traits’ are involved?

The solution looks to require a re-engineering of Translate.java (Move Fixed Distance).

B.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Tim_M]

I cant be positive but I think it extends in other features such as GP’s
where values are internally changing - why it takes a few steps. Will do
some testing to see which I can make multi step

Also what about nested triggers such as?

Trigger
—GKC
—STL
—Trigger
------Change DP
------Change GP
------etc…

Post generated using Mail2Forum (mail2forum.com)

[Tim_M]

I like the wizard idea.

The trick would be coming up with the right set of questions to match the
needed traits

Some are obvious such as

Are pieces deleted permanently from the game (Delete trait)
Are there multiple pieces that are identical (Clone)
Are there going to be cards (Mask)
Do cards stack in a deck (Return To Deck)
Can pieces - not cards, change their image (Layer)
Do pieces/cards change their facing (Rotate)

And so on…
The more advanced stuff would be difficult to question, but if the wizard is
uses one question to specifically tackle each trait/component should be
fairly short (or maybe a check mark selection table by the questions), once
finished have everything they theoretically need to put their module
together

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

On 15/04/2009 at 7:00 PM bsmith wrote:

I’m actually pro-arguments. If no-one says anything for fear of arguments
then nothing improves. I would rather we fight and have a better Vassal,
but I understand I’m probably in the minority opinion here!

I agree, hence the smilee

Brent Easton wrote:

What about a sort of New Module Wizard for beginner mode that asks a

series of questions and sets the ‘stuff’ up for you?

Yeah could do, more work though. Needed?

Yes, it could be.

The key thing is to clearly define what problem such a wizard is trying to address and the assess whether it would actually achieve that.

The following covers our discussion so far:

Problem A: Players new to VASSAL are finding and trying to play modules created by Designers new to VASSAL, having a bad experience and giving up VASSAL.

Goal: Make it easier for newb players to play modules designed by newb designers.

Possible Solution: New Module wizard and Beginner mode

Problem B: New modules are created missing many basic components that are really needed by every module.

Goal: Make life easier for newb designers to create basic modules that actually have enough ‘stuff’ to do something useful, and look something similiar to what other newb designers are making.

Possible Solution: Wizard to create new modules with more ‘stuff’ in them.

Problem C: VASSAL is so complex, it is difficult for a new designer to focus on the basics when

Goal: Make it easier for newb designers to focus on the basic elements of VASSAL without getting bogged down in the more complex areas.

Possible Solution: Beginner/Advanced mode to hide more advance functionality.

Does B and C actually achieve A, or would it be more efficient to plaster ‘Crap Module’ Reviews over the offending module page?

I can see merit in both B and C, but people are STILL going to release half-baked, broken, over-engineered (but pretty) junk as working modules.

Is it worth making life easier for beginner Module Designers?

I suspect yes.

BTW - had an idea while thinking about this. How about a function that would work on a palette widget to ‘Extract a prototype’ from a set of counters. It would compare all of the counters and locate a series of traits that are common to all counters, display it, allow some to be removed, then process it and create a new Prototype and replace the trait sequence in all counters with a reference to the new prototype?

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

15/04/2009 at 9:20 PM Tim McCarron wrote:

I like the wizard idea.

The trick would be coming up with the right set of questions to match the
needed traits

Some are obvious such as

Are pieces deleted permanently from the game (Delete trait)
Are there multiple pieces that are identical (Clone)
Are there going to be cards (Mask)
Do cards stack in a deck (Return To Deck)
Can pieces - not cards, change their image (Layer)
Do pieces/cards change their facing (Rotate)

And so on…
The more advanced stuff would be difficult to question, but if the wizard
is uses one question to specifically tackle each trait/component should be
fairly short (or maybe a check mark selection table by the questions), once
finished have everything they theoretically need to put their module
together

The ‘New Piece Wizard’ really needs to be asked for each piece. A module typically consists of a few complety different ‘types’ of counter. Typically Cards, markers and units. Perhaps after answering the questions, you give the ‘type’ of unit you created name, then you can create more units usingthat ‘type’.

Or perhaps we create a set of pre-defined unit ‘types’ (or ‘templates’) that can be used to pre-populate the Piece Definer.

Again, it comes back to how easy should it be for a designer? If we provide all this wizard stuff to create basic modules, aren’t we going to just end up with a lots of modules that basically do nothing, but do nothing in a consistent way?

Ahhh…That’s exactly what you are after isn’t it Ben?

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)