Module Design and Game Automation.

[bsmith]

@Brent Easton

do nothing, but do nothing in a consistent way?

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

You mean modules that do nothing except let you just play the frikken game? That would suck.

[Tim_M]

We’ve gone the opposite direction!

Creation automation to prevent module automation - the solution irony

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

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

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.

No, that shouldn’t happen from what I can see in the code.

Will do some testing to see which I can make multi step

Yes please. I’ve tried a few things but have not been able to reproduce the problem except when using the ‘Move Fixed Distance’ trait.

Also what about nested triggers such as?

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

No, those are also be bundled up as one action.

---

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

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “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 pr
ojects in general. In the corporate world people are paid to do the boring s
tuff like write mission statements, provide clear direction and make sure sof
tware behaves in a way that benefits the user. But in OS this entire layer i
s missing so we just add stuff that would be cool; The end result being a pr
oduct 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.

My experience with open-source and commercial software has been completely
different from yours, aparently. Every piece of commercial software I’ve
ever used has eventually had a feature added to it which is universally
detested, yet the users have zero leverage in getting it removed. Same with
bugs—I am consistently impressed with the average speed with which bugs I
report against Fedora are resolved. To cite an example close to home, I’m
consistetly dismayed by how slow Sun has been at fixing Java bugs (though
I see a ton of bugfix activity on the OpenJDK lists, so that’s another
win for open-source).

For my part, almost everything I’ve worked on in the past two years or so
has been directed at improving the user experience, whether by optimizing
to make things faster, creating an installer, fixing up the GUI. Generally
we discuss significant changes, so I don’t agree that we’re lacking
direction.

–
J.

---

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

Post generated using Mail2Forum (mail2forum.com)

[Kim]

A few more thoughts from a complete novice …

Brent Easton wrote:

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.

I hope you realised I wasn’t criticising the addition of further automation, but expressing puzzlement as to where VASSAL was going.

bsmith wrote:

I think we need to make the following assumption:

• Module designers will not read documentation.

But is that really so? The first thing I did when trying VASSAL for the first time (in terms of design) was to look for documentation, only to find there was very little of it. And what documentation did exist was a mixture of the clear-and-useful and the confusing-bordering-on-pulling-out-hair-unhelpful. Some assumed a level of programming knowledge I just don’t have.

I am not a programmer, but would like to make modules for small games I want to play and which are unlikely to be VASSALised by anyone else. If there was a choice between a complex, powerful application which was difficult to design for, and one for which designing was a doddle but had less flexible features; well, I would probably go for the latter (at first anyway).

So it might be an idea to have two levels of module design: one which assumes little knowledge on the part of a would-be designer, and a second which allows a knowledgeable cove full reign to use more complex tools. The Wizard thing that’s been mentioned in this thread a few times could be just the thing.

As for rating modules, there is some merit in that in as far as it pertains to how easy or otherwise a module might be to use. But would it be extended to the actual look of a game? Not all games come with artistically created boards or pieces; some have to be made from the ground up by people who want to play but have no artistic skills. Frankly, I would rather have a basic but playable module than no module at all. But I do wonder if ratings will lead to an elitism which will put off potential designers who don’t have thick skins?

[Tim_M]

Brent, I ran a bunch of routines.
Covered STL/Send back, RTD, both GKC’s, GPs, DPs, Layer, Clone, Delete,
Mask, Replace w/o, Map applied Key. All sorts of nesting.

Everything worked as expected with single undo so all seems well.

I think we may have been forgetting about the chat log - why it seems it
takes a lot of steps to undo/step fwd sometimes when you have to go through
the text logging also.

Could the chat be decoupled from the undo? It would have to stay linked for
step fwd in logs (this may become moot w/ the new logging tools once
implemented however as I remember the outline for those)

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

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

On 17/04/2009 at 5:16 PM Tim McCarron wrote:

Brent, I ran a bunch of routines.
Covered STL/Send back, RTD, both GKC’s, GPs, DPs, Layer, Clone, Delete,
Mask, Replace w/o, Map applied Key. All sorts of nesting.

Everything worked as expected with single undo so all seems well.

I think we may have been forgetting about the chat log - why it seems it
takes a lot of steps to undo/step fwd sometimes when you have to go through
the text logging also.

Do you mean the Chat the people type in or the comments from Report Action traits? Report Action reports should be included in the single undo. A line of chat is just a Command like any other game action and each line is a separate command, so it takes a single step or undo for each line.

Could the chat be decoupled from the undo? It would have to stay linked for
step fwd in logs (this may become moot w/ the new logging tools once
implemented however as I remember the outline for those)

Perhaps both step and undo could be modified to treat all consecutive Chat lines (Chatter.DisplayText Command) as a single step?

I’m not sure we have pinned down the actual problem yet. There are definitely issues with some traits that mean they are not bundled into a single step. ‘Move Fixed Distance’ is one. I had trouble yesterday with a trigger I am working on that does a ‘Replace with Other’, ‘Global Key Command’ (that issues a Send to Location to another counter) then 'Delete’s itself and this seems to generate 2 steps instead one. I am looking into this.

If you have heavy automation that happens to do a lot of the traits that are not bundled into a single step, then you have big undo and step problems.

I would be particularly interested to see modules and logs which demonstrate the ‘painful’ undo behavior reported earlier.

B.

---

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

Post generated using Mail2Forum (mail2forum.com)

[Tim_M]

@Brent Easton

Do you mean the Chat the people type in or the comments from Report Action traits? Report Action reports should be included in the single undo. A line of chat is just a Command like any other game action and each line is a separate command, so it takes a single step or undo for each line.

Sorry, I did mean the chat people type

Perhaps both step and undo could be modified to treat all consecutive Chat lines (Chatter.DisplayText Command) as a single step?

That sounds like a good idea

I’m not sure we have pinned down the actual problem yet. There are definitely issues with some traits that mean they are not bundled into a single step. ‘Move Fixed Distance’ is one. I had trouble yesterday with a trigger I am working on that does a ‘Replace with Other’, ‘Global Key Command’ (that issues a Send to Location to another counter) then 'Delete’s itself and this seems to generate 2 steps instead one. I am looking into this.

If you have heavy automation that happens to do a lot of the traits that are not bundled into a single step, then you have big undo and step problems.

Agreed, I dont know if heavy automation itself is the problem:

I had a pretty deep sequence:
Counter A triggers:

trigger (check layer) -Set GP
trigger (check layer) -Set GP
trigger (check layer) -Set GP
trigger (check layer) -Set GP
trigger (check layer) -Set GP
trigger (check layer) -Set GP (thisi is correct - 6 property filter sets for 6 different layers/GP)
Replace w/ Counter B (w/ apply key after)

Counter B follows up with(from applied key)
Trigger >
Clone (make Counter C)
trigger (check GP) -Set Layer then reset the GP (6 times)

There is a scattering of reports in there also
This will all back up w/ just one undo step - thats quite a lot of traits im going through

I would be particularly interested to see modules and logs which demonstrate the ‘painful’ undo behavior reported earlier.

B.

I’ll keep on digging