I feel strongly that one of Vassal’s strengths is the ability to not enforce rules. Half of the fun for my group is arranging the tokens to spell dirty words. I’m not kidding. Take away that flexibility, and I feel like you quash a little of the creative joy of playing with a bunch of little pieces.
No, obviously the mere fact of backwards compatibility is irrelevant to me as long as it has no impact on my experience. I’m just arguing that the V4 model should be radically different to the current model. If there’s a way of doing that and still loading V3 modules without introducing legacy crud into the model and the program, fine. But that sort of thing is pretty unusual, and Joel’s indicated that the likely route is a module converter from V3 to V4.
There are lots of ways of writing web apps which don’t require users to install new plugins. Java applets, Flash apps, or DHTML apps are all adequate for a wide variety of boardgames. The app could access a module from a URL. Of course there are disadvantages to web apps (server dependency for one), but good web deployment hugely increases the user base of a product.
From the user experience side my ideal would be the following:
The user clicks on a hyperlink. They can now play a board game in their browser. The user doesn’t even need to know they are using VASSAL. Behind the scenes, the browser app is using a VASSAL module which is stored on the server, or loading the module from a VASSAL module repository.
This is a significant gain over the current model for anyone who is trying to design new boardgames, because the initial commitment required from playtesters is reduced to a single mouse click. That’s all they have to do. Then they can decide for themselves if they are interested in playing the game or not.
VASSAL module developers would have the additional overhead of uploading their modules to a test repository. A bit annoying, I agree. But to me, it would be worth it. I don’t pretend to speak for anyone else.
Thus spake dogboy:
There are lots of ways of writing web apps which don’t require users to
install new plugins. Java applets, Flash apps, or DHTML apps are all
adequate for a wide variety of boardgames.
Java applets and Flash both require plugins. Java applets have all of
the disadvantages of Java, with the added disadvantage of an additional
moving part, the browser. Flash is famous for crashing browsers. There’s
also no Flash or Java available on the various iDevices.
The experience I related above w/r/t making a browser-based demo would
seem to indicate that HTML + JS is not adequate for games with modestly-
sized maps. The HTML5 canvas test I made last March performed poorly due
to the size of the canvas. While that seems better with the version of
Firefox I’m using today—I can scroll the canvas smoothly—nothing
else works now. The DHTML demo I made around the same time is still too
jerky, despite that I have a laptop now which is far faster than the one
on which it was written.
WebGL is a possibility, but I didn’t have a browser which supported it
when I was writing these demos, so I don’t know how well it would work.
The app could access a module
from a URL. Of course there are disadvantages to web apps (server
dependency for one), but good web deployment hugely increases the user
base of a product.
Images comprise the bulk of the data in current VASSAL modules; this is
unlikely to change no matter what the V4 module format looks like, so
you can figure that a 10MB module now—a typical size—will still be
a 10MB module in V4.
First of all, this would be unusable without client-side caching. No one
will want to wait for a 10MB module to download each time they play, and
we don’t have the upstream bandwidth to support that even if people
found it acceptible.
Even with client-side caching, loading from a URL is not going to be
very friendly for things which get their connectivity from data plans.
Getting something like World in Flames on your phone is going to use a
significant chunk of your bandwidth for the month, which might take some
people by surprise. If we’re relying on client-side caching, it’s also
worth noting that this doesn’t completely mitigate the bandwidth
problem, as things fall out of caches.
How would this work for modules which can’t be distributed? There are
many such modules out there, and there’s no legal problem I can see with
creators of such modules using them privately. A lot of module designers
won’t have any webspace where they can put such modules without also
making them publicly availiable, but it’s not clear to me how they could
be loaded locally by a browser app. I’ve been under the impression that
you don’t have access to the local filesystem from JavaScript. Is that
no longer the case?
Do you see solutions to these problems?
–
J.
True, but ones which are very widely used already. That’s why I said ‘new plugins’ .
Huh. I didn’t know that the iDevices don’t support Flash or Java. That makes a big difference.
I’ll take your word for this. I’m interested in Euro-style games, so my idea of “modestly-sized” may be different to yours (and to VASSAL’s user base requirements).
Incidentally, it looks like WebGL has serious security issues associated with it, so it may be quite a while (if ever) before it’s widely supported.
All of these are really good points, which I hadn’t considered.
I was about to write, “No - and for good reason.”
But to my amazement, the answer turns out to be “Yes, under HTML5 there is a facility for limited access to the local filesystem.”!
See, e.g.
html5rocks.com/en/tutorials/file/dndfiles/
…for an example.
This doesn’t invalidate the points you’ve made, particularly since it requires the user to select files manually before they can be read, but I’m sharing it since it’s interesting.
No, your arguments are all good ones. It looks - at least given the current state of browser tech - like a thick app is the best solution for VASSAL. I suspect that DHTML is probably adequate for the sorts of game I am personally interested in, but VASSAL has more demanding requirements.
I did see this, too, and I think having to select the file manually would be doable - Users A and B are playing a game, User C joins chat and says, “Anyone have this VMOD?” and User A clicks ‘share module’ or whatever. However, I am under the impression the FileReader solution would have to pipe through the webserver, which Mr. Joel has indicated would be…undesirable.
-Seth
I agree with this for GUI behaviours.
But it seems to me that the biggest part of automation is always likely to be rules enforcement in disguise. The rules of a game essentially specify three things:
- What moves are available to whom in a given game state
- How the game state changes when a particular move is made
- Which states end the game and who wins
You want to restrict rules representation to determining which moves can be made, in some model-checkable universe. Will that involve the design of a new language? And the implementation of a model checker? I’m sure you’ve thought this through better than me, but it sounds
- Hard to do
- Offputting for module developers to learn
- Potentially restrictive in terms of what permissible-move rules can be implemented, depending on how powerful the language and model-checker are
By contrast, for many (most?) games it’s fairly straightforward to formalise the whole of the rules, including permissible moves as well as state changes and end states, in a scripting language. In fact this is desirable for all sorts of reasons, including plugging in black-box AI algorithms to the game (or writing custom AI).
From the point of view of a standard representation of boardgame rules (not just for VASSAL but for other applications), a model which covers state changes and end states is clearly desirable. My guess is that the cleanest way of doing this is (essentially) by calling functions on a rules object via a standard API. It would be a shame for such a standard to exist and for VASSAL not to be able to make use of it (or to implement a competing, less powerful standard).
OK, I agree that move enumeration, and making appropriate use of it where available, is a hard problem, although I’m not convinced that it’s insoluble in the majority of cases. One possible approach that I suspect would cover most games is:
- Allow the set of legal moves to be factorised into smaller subsets. For instance, instead of “place any combination of your pieces on any spaces on the board”, allow this to be broken up into a series of “choose a piece, then place it” conceptual sub-moves. (Ideally, make an abstract interface to the entire set of legal moves, and provide functions which will partially enumerate this set according to a given sub-move decomposition.)
Of course, a checking-based approach will work universally as a fallback, since there are cases where enumeration really won’t work: e.g. in a free-form miniatures game where pieces can be moved anywhere in a continuous space.
Here’s what I think:
- The consequences on game state of making a given move can be formalised programmatically, and it would seem like a pity if VASSAL couldn’t make appropriate use of this.
- Automation is already (selective) rules enforcement in disguise.
- Model checking seems like an unnecessarily complication for VASSAL developers and module developers, when move checking could easily be done in a scripting language, using a simple isMoveLegal(gameState, move) API. This ought to be part of any more general boardgame rules API anyway.
One minor comment here: in game theory, a move is just a transition to another game state. A single game-theoretic “move” could be “play this card, then end the turn, do round cleanup, transfer control to the next player and perform any automatic actions at the start of their turn”. Any decent boardgame formalisation should distinguish the “true” move as it is presented to the player (play this card) from the consequences (end the turn, do round cleanup, …).
Otherwise, rules-checking will have problems properly detecting legal player moves; in this example, the game-state change of simply moving the card from hand to play does not constitute a legal transition in the game-theoretic graph, since it has to be accompanied by a number of other game-state changes.
Leaving that observation aside, I agree that (in many cases) strict rules enforcement will detract from game play. In addition to the considerations you (and IrishWulf) have raised, people will always want to be able to play games with house rules, and override genuine bugs in rules implementation. There should certainly be easy ways for people to force extra-legal game state changes.
What I do still think is that a generic boardgame client should (ideally) be able to make appropriate use of a (full) programmatic representation of a game’s rules. The meaning of “appropriate use” here is not yet clear to me, and I admit it’s a non-trivial problem.
Does that make sense?
Simon
The users could always individually download the VMOD file from a public server or share it via some other means.
By the way, I don’t imagine that HTML5 local file access capability is particularly practical for VASSAL’s purposes. Game saves wouldn’t work, and pulling the images out of the zipfile in a browser-displayable form would likely be horrendous in JavaScript.
Apparently FireFox also allows local file access for digitally signed scripts, although the user has to permit it in a popup.
Simon
Thus spake dogboy:
But it seems to me that the biggest part of automation is always likely
to be rules enforcement in disguise. The rules of a game essentially
specify three things:
- What moves are available to whom in a given game state
- How the game state changes when a particular move is made
- Which states end the game and who wins
You want to restrict rules representation to determining which moves can
be made, in some model-checkable universe. Will that involve the design
of a new language? And the implementation of a model checker? I’m sure
you’ve thought this through better than me, but it sounds
- Hard to do
- Offputting for module developers to learn
- Potentially restrictive in terms of what permissible-move rules can be
implemented, depending on how powerful the language and model-checker
are
I have thought quite a lot about this; it’s something for which I wrote
a research proposal in 2010 (which unfortunately wasn’t funded, though
it did receive high enough marks to be considered fundable).
I agree that creating a rules-specification language which is both
expressive enough and not too awful to use will be challenging, but my
considered opinion is that this would be far better than using a
procedural scripting language, both in terms of user effort and
verifiability.
From the point of view of a standard representation of boardgame rules
(not just for VASSAL but for other applications), a model which covers
state changes and end states is clearly desirable. My guess is that the
cleanest way of doing this is (essentially) by calling functions on a
rules object via a standard API. It would be a shame for such a standard
to exist and for VASSAL not to be able to make use of it (or to
implement a competing, less powerful standard).
It would, but I see no such standard in the offing. If it’s going to
exist at all, I think we’re going to create it here.
–
J.
I feel that a specific game language could be an advantage for non-programmer that want to design modules if it is correctly designed to get close to the elaboration of a rulebook. It could also go beyond the strict rule enforcement feature and can apply to game description, graphical and A.I. design. But besides the language design, associated tools can enhance deeply the user experience in designing module. Take a look at this guy conference that really talks by itself:
vimeo.com/36579366
10 years ago I’ve seen premisces in a few industrial products related to development of such principles but not pushed so far.
What about a editor that allow coding and seeing immediately the result aside as presented in the conference but also designing through the graphical side and seeing the coding automatically written? Some operation are defined faster one way or the other… Non programmer can begin through the graphical side the tool deserving tutorial purpose… and so on…
I know it represent an amount of work that’s a vision that may be valuable to think of and to try to reach. ?
I would not underestimate the amount of work that is required by designing and also using such a game language.
Has anyone had a look at this, yet:
flexiblerules.fulviofrapolli.net/
Yes I have, while it looks and does seem to be more capable than Vassal, it severely lacks any useful documentation (if you thought Vassal documentation was bad, this is worse…) and it is very inaccessible for your average module designer. In order to use it and develop games on it you must know how to do programming - Vassal does not require this and that is an important aspect when you consider that most of the module developers are not programmers.
Any future version should maintain this accessibility for non geeky folk that Vassal relies on to make the modules unless we really are intent on spiting ourselves and disenfranchising a key component of Vassal success
Furthermore, previous attempts (by myself when messing with FlexibleRules) to contact and clarify things with the project authors has been met with the sounds of crickets so I can only presume that the project now appears to be abandoned / complete as far as the authors purposes are concerned.
Thus spake olan:
I would not underestimate the amount of work that is required by
designing and also using such a game language.
Has anyone had a look at this, yet:
flexiblerules.fulviofrapolli.net/[1]
I saw this a year or two ago, and read some of the published work on
it. My primary criticism is that it’s procedural, not declarative.
–
J.
Long thread, but managed to read it though.
Even though I’m a newcomer, I’ve been usign vassal these past few years, and couldn’t agree more on the problems raised here, such as issues with the server, clunky interface, or the sheer amount of facepalming necessary to design a working and understandable module.
So all in all, given the fact that I’ve been doing development for the past 15 years or so, and that I’ve been known in the past to be fluent in Java and C, I’d be glad to help on it, be it C++ or whatever.
My only requirement is to have the opportunity to build a frontend UI based on ncurses with libaa for image rendering. That or to have a working thing.
Additional comment: I was talking with Uckelman yesterday, but forgot to ask this very simple question. Where are we, in terms of decisions and current “task forces” in order to reach the Vassal 4 goal? I saw the demo, saw some of the other threads, but didn’t see any coordinated effort on v4. I suppose that delivering 3.2 comes first, but still, it’s worth asking.
For those of you interested in such a thing, following my (lengthy) discussions with Uckelman, I did two things:
-
Drafted an xsd for the XML gamebox, which you’ll find here: ainulindale.net/vassal/vassalengine.xsd
Obviously it’s a work in progress but it’ll give you the gist about my opinions on the xml’s grammar -
Pushed a branch on vassal4-demo (ainulindale.net/vassal/afrika.xml) it’s isofunctional with Uckelman’s implementation using libxml, but adds validation as well as deserialization (writing game state to XML directly).
I’d be interested in thoughts. Any thought, as long as it’s about this 
Hey guys,
Yesterday we had an interesting talk with Uckelman (to which Tim added his
opinion later on but everyone was sleeping), and I thought that it’d be
worth talking here.
As to release planning and features delivery for V4, what would you prefer?
- “Rolling-release” like, that is implementing feature by feature then
releasing that feature into main V4 when deemed stable enough - Monolithic release, that is implementing all features and releasing when
they’re all in
Obviously, this depends a lot on what is behind a “feature”. Yesterday,
discussion was about hex grid generators and coordinate systems. We could
have a “start top left” system of coordinates for an hex grid such as A1,
A2… B1, B2, … We could also have a “snail type” coordinate system in
which hexes are originated in the center of the grid. I’m sure we could
find games with weird system of coordinates. Here is an example of
“feature”.
For those of you who don’t want to see my opinion before you think about
yours, this is the safe point to stop reading
My point was in this discussion that we’ll always find different ways to
implement this or that feature with this or that specificity.
Hence, in my opinion, we should draft the most basic one which will cover
90% of cases, allow from flexibility from the start (scripting?), do a
first release that way, and then when all basic functionnalities will cover
90% of all possible modules, add the missing parts.
As ever, the common 90% take 10% of the time, and the specific 10% take 90%
of it.
This doesn’t prevent us from thinking about what should be done to cover
all possibilities. But, in my opinion again, this allows us to release more
regularly, keep people interested in what we do (especially potential
developers), as well as allow designers who only need this or that
functionnality to implement their module. It seems to me that this is a
really good way to show people that the project is going forward, which
isn’t quite seeable if one has to browse through git to see changes. Plus,
past experiences have shown me that in open source projects, if you don’t
focus on a specific part as a group with a short term objective in mind,
it’s really hard to get anything done in a reasonable amount of time.
That’s why I’m obviously a solution 1 guy.
Any thoughts?
–
Julien Cassignol
ainulindale.net
This would be my choice, with the initial release being quite modest e.g. to the level required to implement a relatively simple hex game like Battle for Moscow. This will allow us to build a working framework and implement and test various technologies before the project grows to the size where changing a technology becomes too big problem.
Coming from a hex boardgame background, I chose Battle for Moscow as a starter, but at the same time, we should build support for simple versions of other typical game types, especially card games which are not well support atm.
As well as the structural design that is going on now, I would like to see some thought to developing a list of game ‘mechanisms’, for want of a better word, that must be supported. It is important that as we design and build, these core ‘mechanisms’ must be supported. Things like piece ‘ownership’ and changing ownership (dealing etc.), information hiding (masking, hidden).
I guess, these are the ‘behaviours’ that Joel has mentioned. I don’t just mean a list of ‘traits’ as per Vassal, but a deeper understanding and description of the underlying mechanisms. As the design develops, it must support the core behaviours cleanly, or we are wasting our time.
Regards,
Brent.
Thus spake Julien Cassignol:
Hey guys,
Yesterday we had an interesting talk with Uckelman (to which Tim added his
opinion later on but everyone was sleeping), and I thought that it’d be
worth talking here.As to release planning and features delivery for V4, what would you prefer?
- “Rolling-release” like, that is implementing feature by feature then
releasing that feature into main V4 when deemed stable enough- Monolithic release, that is implementing all features and releasing when
they’re all in
I prefer doing frequent releases for V4, with one caveat: We must be
careful to communicate to users what V4 releases are.
There will be many, many releases of V4 before it’s a replacement for
V3 for everyone. We don’t want users getting the idea that V4 is a V3
replacement before it actually is; that will lead to a lot of user
disappointment and frustration. I’m not sure how best to manage user
expectations here—my initial thought is that we call V4 releases
“demos” until there’s a V4 release which implements all of the V3
features.
–
J.
Thus spake Brent Easton:
- “Rolling-release” like, that is implementing feature by feature
then
releasing that feature into main V4 when deemed stable enoughThis would be my choice, with the initial release being quite modest
e.g. to the level required to implement a relatively simple hex game
like Battle for Moscow.
It’s funny you picked that—it’s the game I used for the XML example
I posted yesterday.
As well as the structural design that is going on now, I would like to
see some thought to developing a list of game ‘mechanisms’, for want of
a better word, that must be supported. It is important that as we design
and build, these core ‘mechanisms’ must be supported. Things like piece
‘ownership’ and changing ownership (dealing etc.), information hiding
(masking, hidden).
We should start making a list.
The only mechanisms which I think will be difficult to support via
properties are ones involving hidden information, the difficulty having
nothing to do with the nature of hidden information.
I think the problem becomes clearer by dividing cases. If there’s hidden
information,
- a player cannot access that information unilaterally, or
- a player can access that information unilaterally
a. where doing so will trigger notification of another party, or
b. without anyone else knowing he has.
Secure systems, as when the player doesn’t have the hidden information
or has it, but it’s encrypted with a strong cipher, are in category 1.
A lot of browser-based games with hidden information are like this—
presumably the server does not hand out information to clients that they
are not permitted to see. Systems in category 2.a are things like ACTS,
if I understand it correctly: You can draw a card any time you want, but
your opponent will know that you have. Every virtual tabletop system I
know of is in category 2.b, though the amount of effort needed to access
the hidden information varies.
Which category makes sense for a game depends on both the game and the
players. Lots of games have no hidden information, so for those it
doesn’t matter. For other games, there’s a trade-off between trust and
convenience. Category 1 systems require player interaction if the
player triggering the revelation of some hidden information is not the
one who possesses the key to it. This can be acceptible for real-time
games, or for PBEM games where such revelation happens infrequently
(e.g., many games have secret victory conditions set at the start and
revealed at the end), but could become onerous for games where hidden
information is revealed often (e.g., think of a card game where one
player has the ability to steal a card from some other player every
turn, or a game which has sighting distances for units and real fog-of-
war).
Category 2.a systems don’t require intervention by other players to
reveal information, but also don’t have any protections against
information being revealed improperly. E.g., I can draw a card, and
everyone is notified that I drew a card, but there’s no way to undo
the revelation if I wasn’t supposed to draw a card. If mistakes are
not a problem (or not possible) then this kind of system is fine, and
could expedite PBEM play quite a bit.
Category 2.b systems rely on players not peeking at things they’re not
supposed to see. For me, this is fine when playing games with my
friends—it’s just like playing games face-to-face. I trust them not
to look at my cards when I leave the table to get a beer. But it’s not
so suitable if you’re running a PBEM tournament full of people who don’t
know each other. For that case, having a system in one of the other two
categories means that you don’t have to worry about playing against
cheaters, and you also don’t have to worry about being called a cheater
when you’ve guessed well or had an exceptional run of luck.
Finally, there’s the issue of data recovery with encrypted category 1
systems. People will loose their passwords. If they’ve chosen good
passwords (not “12345” and “password”) and we’re using strong
encryption, then even government-level efforts will not get their
data back from the cyphertext. This might be solvable simply by making
it easy for players to store their data unencrypted locally, and only
encrypt the data in files meant to be sent to others.
That doesn’t help in the case where you need to recover the data after
a player vanishes. This can be a big, big problem in long multi-player
games. E.g, what do you do if all of the force size data is encrypted
and one of your Empires in Arms players stops responding and needs to
be replaced? There is forunately a way around this using public key
crypto, in that you can encrypt the data so that it can be decrypted by
some number of other players acting in concert, but not by fewer
players—the idea being that, say, if the remaining six players in your
EiA game agree it’s ok to release the remaining player’s secret
information, then it’s for a good reason.
So, this issue is rather complex. I think there are at least three
scenarios here we should support:
A) encrypted hidden information stored in saved games
B) unencrypted hidden information stored in saved games
C) hidden information stored in the game server
–
J.
I will note that the current VASL module is a combination of 1 and 2.a. There is a preference that has to be set to allow other people to reveal your concealed units. Without that, only the owner can reveal.
Thus spake Rindis:
I will note that the current VASL module is a combination of 1 and 2.a.
There is a preference that has to be set to allow other people to reveal
your concealed units. Without that, only the owner can reveal.
That’s not accurate. VASL is 2.b. With sufficient knowledge of the file
format and some work, you can read everything.
–
J.