VASSAL engine as our table for Indie and RPG games

Hi,

We’ve been using VASSAL as our table for the RPG/Indie type games which
we play over VoIP with a big success. I promised to prepare a list of
things that could be improved to make the gaming experience better and
more pleasant. I am focusing on getting the main ideas highlighted,
instead of going into details, on our website there is a dedicated topic
with a very detailed spec for each of the features, containing a
description of the behaviour we would like to see. In our RPG/Indie
work-flow we exclusively use an excellent `Bucket of Dice’ VASSAL module by
Filip Łuszczyk (who is the founder of our website).

So: (in order of urgency/size/relevance):

  1. Notes currently are a bit clumsy and there is no formatting, we will
    elaborate about it in a separate thread. Ideally we would want a Wiki
    like markup but with WYSIWYG & GUI + key-bindings for emphasising,
    making text bold or italic etc. I would be a fan (danmey) of a Wiki like
    markup, but we think that WYSIWYG behaviour would be more useful.

  2. There is no `pointing device’. Showing other players a point on the
    canvas using the mouse would be a very useful feature.

  3. No facility to draw anything, I know the development team is looking
    at this issue.

  4. Only the player can delete her/him/self from the game, in case of the
    boardgames it is irrelevant, but in case of regular campaigns it is a
    bit annoying. Deleting players would be very useful.

  5. Very clumsy selection of objects with traits, they basically don’t
    stack. A very little thing, but makes things a bit difficult in case of
    using tactic grid in the D&D style games.

  6. There is no way of adding graphics in the middle of the gaming session,
    you have to prepare the extension before the game, and after that
    everybody needs to download the package again. Probably this function
    does not fit conceptually into VASSAL engine but we are happy to live
    with it.

  7. We’ve never managed to connect peer to peer. (danmey: from my
    perspective it is a limitation of TCP/IP protocol [both sides behind a
    nat] not VASSAL when we have a support for XAMPP based session it should
    go away). It is not important.

  8. Now, we can’t play MP3, which is not a big deal, just a nice feature
    to be integrated into VASSAL. :slight_smile:

  9. When the object is hidden, assigned rapports don’t work. Ideally it’d
    be more convenient if the player who hides the object would see the
    reports in the chatter window. (preferably highlighted as hidden).

Hope it is not too much for you, question and feedback very warmly
welcomed.

Thanks!
Wojciech

Thus spake danmey:

  1. Notes currently are a bit clumsy and there is no formatting, we will
    elaborate about it in a separate thread. Ideally we would want a Wiki
    like markup but with WYSIWYG & GUI + key-bindings for emphasising,
    making text bold or italic etc. I would be a fan (danmey) of a Wiki like
    markup, but we think that WYSIWYG behaviour would be more useful.

  2. There is no `pointing device’. Showing other players a point on the
    canvas using the mouse would be a very useful feature.

I agree that this would be handy. How would you implement this efficiently?
Seems like it would require an enormous amount of message passing between
the server and clients. What rate of update would be necessary to be
useful? 5fps? 10fps?

  1. No facility to draw anything, I know the development team is looking
    at this issue.

This is Bug 1825:

vassalengine.org/tracker/sho … gi?id=1825

There is some code writen for this one, but it’s going to be a horrible
mess to try to finish this before the Model/View separation project.

  1. Only the player can delete her/him/self from the game, in case of the
    boardgames it is irrelevant, but in case of regular campaigns it is a
    bit annoying. Deleting players would be very useful.

  2. Very clumsy selection of objects with traits, they basically don’t
    stack. A very little thing, but makes things a bit difficult in case of
    using tactic grid in the D&D style games.

I don’t follow what you’re saying here.

  1. There is no way of adding graphics in the middle of the gaming
    session,
    you have to prepare the extension before the game, and after that
    everybody needs to download the package again. Probably this function
    does not fit conceptually into VASSAL engine but we are happy to live
    with it.

  2. We’ve never managed to connect peer to peer. (danmey: from my
    perspective it is a limitation of TCP/IP protocol [both sides behind a
    nat] not VASSAL when we have a support for XAMPP based session it should
    go away). It is not important.

I’m not certain myself that this works.

  1. Now, we can’t play MP3, which is not a big deal, just a nice feature
    to be integrated into VASSAL. :slight_smile:

This one’s finished already. It will be in 3.2.0. See Bug 1934:

vassalengine.org/tracker/sho … gi?id=1934

  1. When the object is hidden, assigned rapports don’t work. Ideally it’d
    be more convenient if the player who hides the object would see the
    reports in the chatter window. (preferably highlighted as hidden).

Hope it is not too much for you, question and feedback very warmly
welcomed.

Would you mind putting the ones which aren’t already there into the
bug tracker?


J.

On Dec 6, 2010, at 2:08 PM, Joel Uckelman wrote:

  1. There is no `pointing device’. Showing other players a point on
    the
    canvas using the mouse would be a very useful feature.

I agree that this would be handy. How would you implement this
efficiently?
Seems like it would require an enormous amount of message passing
between
the server and clients. What rate of update would be necessary to be
useful? 5fps? 10fps?

Is this something that could be triggered only by a mouse click?

Maybe with something like animated concentric circles around the mouse
pointer to make it findable?

I suppose as a work-around, one could introduce a pointing finger
counter and place it where you want, then delete it.

Hi,

Joel Uckelman uckelman@nomic.net writes:

  1. There is no `pointing device’. Showing other players a point on the
    canvas using the mouse would be a very useful feature.

I agree that this would be handy. How would you implement this efficiently?
Seems like it would require an enormous amount of message passing between
the server and clients. What rate of update would be necessary to be
useful? 5fps? 10fps?

Yes indeed, it would be too chatty, given limited bandwidth of the
server and the number of users we have now. I don’t know about Vassal’s
network protocol yet, but I believe there are few optimisations that
could be done:

  • trade latency for the number of packets we send over the network,
    sample series of positions into series of deltas and send it as a list
    of deltas in one bulk, once per frame as a compressed binary blob? This
    would require some re-engineering to be done, because I assume you send
    a text XML over the network.

  • use variable FPS, if the user is not moving the pointer to much reduce
    sample rate to minimum, if she is moving constantly - increase.

  • update the positions not only at certain frequency but only send delta
    position at a certain threshold. If the user didn’t move the pointer
    that much, don’t do anything (in fact it is almost the same as the
    previous point). At the same time update the absolute position once per
    some while. So user moved the cursor slightly, it will not update
    anything as the delta didn’t pass the threshold, but after a second it
    will be updated with the absolute position during `sync up’.

  • use sampled units for delta, e.g. send deltas over the AxA pixel grid?
    So (1,2) means the cursor moved (A,2A) pixels, this would reduce the
    bandwidth linearly trading precision of the pointing device, but only if
    the entropy coding was used (see my previous point).

  • allow users to deploy their own servers, how is that possible?

  • P2P would help but we are not certain how is it possible technically.

  • encode shape drawn by the pointer as some function and send the
    coefficients only? That’s the last thing that I can think of.

  1. Very clumsy selection of objects with traits, they basically don’t
    stack. A very little thing, but makes things a bit difficult in case of
    using tactic grid in the D&D style games.

I don’t follow what you’re saying here.

Me either. I wanted to edit the post and explain it after consulting it
with Filip, but seems like I couldn’t edit the post. Let me come back to
it later.

  1. Now, we can’t play MP3, which is not a big deal, just a nice feature
    to be integrated into VASSAL. :slight_smile:

This one’s finished already. It will be in 3.2.0. See Bug 1934:

vassalengine.org/tracker/sho … gi?id=1934

Nice, thanks. Few questions regarding trunk: How stable the trunk is?
Can we use the snapshot? Last time I tried trunk it was not possible to
run Vassal (but maybe it was my bad), is it going to work with the
current server? When do you think the 3.2 will go out of the door?

Would you mind putting the ones which aren’t already there into the
bug tracker?

Yes, I will do it this week.

Thanks!
Wojciech

Ok, I’ll clarify some bullet points.

But first, most of the above are wishes to Santa. Danmey is much more optimistic than myself in this regard; I’m perfectly aware that a lot of those things don’t really belong in a board game engine. I posted pretty detailed specifications and implementation ideas for each feature in the thread at our site, with the assumption that danmey would dig into those one at a time and only when needed. I lack any actual programming skills, so it’s difficult for me to assess the technical side of things - I can only speak from the user’s and module creator’s perspective.

Now, danmey still lacks familiarity with module creation at this point. This complicates the matter a bit.

In terms of priority: points 1, 2 & 3 are features that we would really like to see; 4, 5 & 9 are minor issues that are not so important, but probably easier to do; 6, 7 & 8 (and especially 8) are likely unrealistic and were only included for the sake of completeness.

To give you some context, there are some screenshots posted on my blog. We use a single flexible module for a variety of indie roll-playing systems. It’s set up so that we can easily adjust the appearance of the table and pieces to the needs of a new campaign via extensions.

So, clarifications, point by point:

  1. Notepads and dice are our basic gaming tools. Dice are fine, no problems here. Notepads were a bit more difficult to handle, since Vassal’s default notepad proved insufficient. We barely ever use that one at this point - instead, many pieces in the module have their own notepads attached. Screenshots illustrate the results.

My current solution for this is the spreadsheet trait, with just a single text field. Changes are applied with every key stroke. This gives us a “Google Wave for the poor” effect :slight_smile:

It’s possible there are more functional solutions that I don’t know about. This one is servicable enough, in that we have the basic functionality we need. There is a single mildly annoying bug that results in chaos when two people try to edit the same notepad simultaneously. The lack of text formatting is a complaint I commonly hear, however.

I imagine adding enhanced text formatting to the spreadsheet text fields could prove troublesome.

My other idea was to add a new trait “notepad” that would attach a lightweight text editor to the piece.

  1. As for the pointing device, I wonder if this could be implemented in a way similar to how the LOS Thread works.

We tried the finger piece work around suggested above in the past. Didn’t prove very functional. The whole point is to be able to point at stuff with a single key stroke. With the finger piece, we wound up just using speech in the end - it was faster to start explaining than to place the piece and then explain that you are trying to point at something anyway.

  1. Well, drawing tools are the one thing I knew you had already been working on.

4 & 5: I don’t follow what danmey is saying either :slight_smile:

  1. Currently, once a side is claimed by a player, it remains claimed unless that player manually retires. In campaign play, this occassionally creates some problems when people join and leave or switch computers between sessions (sometimes forgotten passwords were the issue, sometimes we just ran out of sides to claim for no apparent reason at all).

It would be useful if module editor presented “allow enforced retirement” option in the sides definition window.

  1. In short: in this Pathfinder game I had floor tiles with does not stack trait and select only when shift key down option. Proved troublesome when removing “fog of war” (the red highlight in the screenshot) from heavily crowded areas of the map. Changing select only when shift key down to select only when alt key down didn’t help - holding alt grabs the entire map window, at least in my Ubuntu.

It would be useful if does not stack trait also allowed select only when ctrl key down and/or select only if user-defined key down.

  1. My suggestion was adding “user defined image” trait that would overwrite or mask the basic piece picture (with pictures selected via this trait stored in a sub-folder located in the module’s extension folder rather than in the module itself). Seems like something somewhat similar to how module editor’s picture selection works, the problem seems to be automatically sending the picture to other players the way roll-playing decicated virtual tabletops tend to do.

I also had some ideas for changing map boards in the midle of the game, but those are probably even much more unrealistic.

  1. Well, duh.

  2. Oh.

  3. When working with hidden pieces, the lack of reporting sometimes confuses me. I imagine it wouldn’t be that difficult to code printing hidden reports in italics for the player hiding the piece only.

Thus spake danmey:

  1. There is no `pointing device’. Showing other players a point on
    the
    canvas using the mouse would be a very useful feature.

I agree that this would be handy. How would you implement this
efficiently?
Seems like it would require an enormous amount of message passing
between
the server and clients. What rate of update would be necessary to be
useful? 5fps? 10fps?

Yes indeed, it would be too chatty, given limited bandwidth of the
server and the number of users we have now. I don’t know about Vassal’s
network protocol yet, but I believe there are few optimisations that
could be done:

  • trade latency for the number of packets we send over the network,
    sample series of positions into series of deltas and send it as a list
    of deltas in one bulk, once per frame as a compressed binary blob? This
    would require some re-engineering to be done, because I assume you send
    a text XML over the network.

  • use variable FPS, if the user is not moving the pointer to much reduce
    sample rate to minimum, if she is moving constantly - increase.

  • update the positions not only at certain frequency but only send delta
    position at a certain threshold. If the user didn’t move the pointer
    that much, don’t do anything (in fact it is almost the same as the
    previous point). At the same time update the absolute position once per
    some while. So user moved the cursor slightly, it will not update
    anything as the delta didn’t pass the threshold, but after a second it
    will be updated with the absolute position during `sync up’.

  • use sampled units for delta, e.g. send deltas over the AxA pixel grid?
    So (1,2) means the cursor moved (A,2A) pixels, this would reduce the
    bandwidth linearly trading precision of the pointing device, but only if
    the entropy coding was used (see my previous point).

  • allow users to deploy their own servers, how is that possible?

  • P2P would help but we are not certain how is it possible technically.

  • encode shape drawn by the pointer as some function and send the
    coefficients only? That’s the last thing that I can think of.

There are a half-dozen suggestions now on this thread for how to implement
this. What we need now is a pointer demo that implements the differnent
tracking methods so we can see how they perform perceptually.


J.