Roadmap for VASSAL 4

Development
221

by uckelman » 01 Aug 2011 21:03:

Hmmm. It all depends on which part of a multi-platform project you work on. We always estimated that 90% would be platform independent and 10% platform dependent but the effort would be 50-50 for both parts. We were writing in objective-C so had ported the GNU compiler to each platform (so avoiding problems where system X’s compiler optimises your code to not working).

The basic problem is that nothing worth doing ports easy and anything that ports easily is trivial.

Don’t forget the Java implementation on any system stands on the image i/o libraries for that system. The implementors of Java didn’t re-invent the wheel. Any code you write will need to sit on the same libraries and hit the same bugs possibly.

Don’t forget the major testing headache. Now you can assume that Vassal will run on 90% of machines which can install JRE but if you write in C++ you’ll have to build it and test it on all possible environments including old versions of MacOS and Windows and Linux.

You know it works on whatever you’ve built it on. Don’t forget most users are not at the leading edge of Windows, Linux or MaxOS and their machines have old libraries which may have old bugs. You’ll not be able to carry your new libraries around with you as they may not work on older software and/or installing them on older systems may break other programs on the machine. Not to mention 64-bit and 32-bit version of the libraries.

If you don’t want to wait for a bug to be fixed join openJDK and fix the bugs there. They’ll get into mainstream Java and openJDK is porting to Mac so you’ll have 1.6 on the Mac plus bug fixes.

I would hope so!! But if just speed was the goal would it be better to go for Java Native classes for the bits that need speeding up

Don’t forget that no one writes a post on the forum to say his JRE installation worked perfectly! You’ll get a very distorted view if you take the forum posts to represent the general experience. There are thousands using Vassal who’ve had little or no problem.

Do our users care if they are in a code ghetto? They just want their modules to work. As they do now for the most part. The number of bug reports is minimal compared to the number of games played on Vassal.

Hmm, to be a little cynical but perhaps realistics, I suspect someone will be saying the same about your new design in five years time. A design is only clean if you’ve thought everything out beforehand and never extend it. In reality any program grows by accretion after its initial release as users request thing never thought of which don’t quite fit the design or do things with your product which the designers never imagined - and with scripts the module developers will be able to really go to town. Consider what has been done with traits which never crossed anyone’s mind.

But I do agree with the major rewrite, just not with abandoning the Java platform to do it.

by uckelman » 05 Sep 2011 22:58 :

Looking at the code even just quickly shows that it wasn’t written to be multi-threaded and the layout of the packages etc is all wrong. So a major rewrite is called for but this does not mean leaping into something totally different.

Yes, I accept all my custom code will be broken, reluctantly but I do accept it. I suspect that mkiefte and I account for most of it anyway.

I suspect the users would just like the new version to load existing modules and save files without them having to re download new modules (assuming you convert all those on the web site).

Conversion in Java would be easiest as you could just replace existing classes in the buildFile by stubs which collected the data and then created the new classes from that. You could do something like that in C++ but would have to re-write the stubs rather than just stripping surplus code out of existing classes.

I think you are making yourselves a lot of work going to C++ and I don’t think you’ll reap as many benefits as you think especially for portability.

222

Thus spake george973:

Hmmm. It all depends on which part of a multi-platform project you work
on. We always estimated that 90% would be platform independent and 10%
platform dependent but the effort would be 50-50 for both parts. We were
writing in objective-C so had ported the GNU compiler to each platform
(so avoiding problems where system X’s compiler optimises your code to
not working).

The basic problem is that nothing worth doing ports easy and anything
that ports easily is trivial.

The platform-dependent problems I’ve encountered in Java fall into two
categories: Some are due to the nature of the different platforms, some
are due to the JDK. I don’t believe we can eliminate the ones in the
first category, but the ones in the second category are unique to Java,
so we could avoid them by moving to any other language.

Don’t forget the Java implementation on any system stands on the image
i/o libraries for that system. The implementors of Java didn’t re-invent
the wheel. Any code you write will need to sit on the same libraries and
hit the same bugs possibly.

Actually, the implementers of Java did reinvent the wheel with
ImageIO. I know this because I’ve spent a significant amount of time
looking at the ImageIO PNG loader in particular to determine exactly how
it’s broken. This would not be a problem with libpng. Because virtually
everything else which loads PNGs depends on it, it has received intense
scrutiny over the years to make sure it works. When bugs are found, they
get fixed promptly. (Similarly for libjpeg, libgif, librsvg.) I don’t
have a collection of PNGs on which libpng barfs. I do have such a
collection for ImageIO.

Don’t forget the major testing headache. Now you can assume that Vassal
will run on 90% of machines which can install JRE but if you write in
C++ you’ll have to build it and test it on all possible environments
including old versions of MacOS and Windows and Linux.

Right now we have a problem which so far as I can tell, only occurs on
64-bit Windows 7. We’ve seen plenty of problems specific to old versions
of MacOS in the past. I don’t see that we can predict which OS-JRE
combinations will work now. This is not a win for Java.

You know it works on whatever you’ve built it on. Don’t forget most
users are not at the leading edge of Windows, Linux or MaxOS and their
machines have old libraries which may have old bugs. You’ll not be able
to carry your new libraries around with you as they may not work on
older software and/or installing them on older systems may break other
programs on the machine. Not to mention 64-bit and 32-bit version of the
libraries.

Except for Linux packages built for particular distribution versions
(where we can specify which lib versions we require), I intend that we
will ship our own copies of the libraries on which we depend. We won’t
be interfering with libraries already on the machine because we’ll be
bringing our own.

If you don’t want to wait for a bug to be fixed join openJDK and fix the
bugs there. They’ll get into mainstream Java and openJDK is porting to
Mac so you’ll have 1.6 on the Mac plus bug fixes.

Some of the bugs I’ve encountered have had patches in Sun’s bug tracker
since before OpenJDK existed, yet they are still not fixed. I’m quite
willing to contribute bug fixes to projects I use, but the JDK looks
like a bottomless pit to me. There’s a limit to the amount of effort
that I’m willing to invest in something that is not my project. Using
dependencies which already work is a more efficient use of our time
than fixing the JDK is. The fact that we’re having this discussion about
image loading bugs—bugs which you would expect to have widespread
impact—tells me that hardly anybody else uses Java the way we do.

  1. You’re underestimating just how much faster C++ is than Java when
    working with images. The majority of the computation that VASSAL does
    involves images. The C++ that I wrote for our V4 demo does everything
    essentially instantanously; working with the same images in Java is
    agonizingly slow.

I would hope so!! But if just speed was the goal would it be better to
go for Java Native classes for the bits that need speeding up

No, it wouldn’t, for reasons I’ll give below.

Don’t forget that no one writes a post on the forum to say his JRE
installation worked perfectly! You’ll get a very distorted view if you
take the forum posts to represent the general experience. There are
thousands using Vassal who’ve had little or no problem.

My point is that this shouldn’t happen at all. It’s a point of failure
introduced by Java, and a particularly difficult one to troubleshoot.

Do our users care if they are in a code ghetto? They just want their
modules to work. As they do now for the most part. The number of bug
reports is minimal compared to the number of games played on Vassal.

The impact on users isn’t direct, but it’s real. Less and less attention
goes in to Java on the desktop, so as time goes on, the user experience
will degrade relative to native apps. Java bugs have a real affect on our
users, not just on us developers.

The number of bug reports is always going to be small in comparison with
the number of occurances of bugs. The fact that we have bugs with 50+
reports tells me we have serious problems.

Hmm, to be a little cynical but perhaps realistics, I suspect someone
will be saying the same about your new design in five years time. A
design is only clean if you’ve thought everything out beforehand and
never extend it. In reality any program grows by accretion after its
initial release as users request thing never thought of which don’t
quite fit the design or do things with your product which the designers
never imagined - and with scripts the module developers will be able to
really go to town. Consider what has been done with traits which never
crossed anyone’s mind.

I don’t agree. When VASSAL was started, there wasn’t anything like it
out there. We have a much better idea of what’s needed now than at the
beginning. It might be the case that in the future, we’ll realize that
some of the design decisions in V4 were bad—but they won’t be the same
bad design decisions we’re saddled with now, and because I believe we’ve
learned from working on VASSAL to this point, I don’t believe they’ll
be worse. Moreover, it’s not just bad design decisions which I want to
correct, but also some pervasive bugs which we can be sure not to
reintroduce.

But I do agree with the major rewrite, just not with abandoning the Java
platform to do it.

Looking at the code even just quickly shows that it wasn’t written to be
multi-threaded and the layout of the packages etc is all wrong. So a
major rewrite is called for but this does not mean leaping into
something totally different.

A rewrite in Java only solves the problems in the codebase which are
not caused by Java itself. Rewriting in Java won’t solve the any of
the JDK bugs we suffer from. Rewriting in Java won’t let us get rid
of the 20k+ lines of code I’ve written in order to make it possible
to handle large images (none of which is necessary in C++). Rewriting
in Java won’t let us make the Module Manager and Player run in the
same process. Rewriting in Java won’t let us compile for something like
an iPad. Rewriting in Java won’t change the fact that Java frees the
programmer from doing memory management by forcing the user to fiddle
with heap settings. Rewriting in Java won’t add type punning for
arrays to the language, the lack of which forces us to do things like
make second copies of very large images when we need the data as a
byte array instead of as an int array.

I suspect the users would just like the new version to load existing
modules and save files without them having to re download new modules
(assuming you convert all those on the web site).

We could convert them on the site, but I was intending to provide a
converter that works from within V4 also.

I think you are making yourselves a lot of work going to C++ and I don’t
think you’ll reap as many benefits as you think especially for
portability.

The fact that we have a C++ demo which already works as a virtual
tabletop in under 2500 lines of code tells me that we won’t suffer from
the problems which have consumed our development time when working in
Java, and that we’ll end up with something far more maintainable.

I’m not claiming that portability will be easier than with Java, I just
doubt that it will be any harder. And it would have to be a lot harder
to eat up all of the other advantages I see.

–
J.

223

I just read over on ZunTzu forums that ZunTzu 2 development has now shifted from (the abandoned) Silverlight to C++ and OpenGL.

zuntzu.com/forum/viewtopic.php?t=1715

224

Ooh. Competition. ;)

  • M.

On 6 September 2011 09:28, bdgza bdegroot@gmail.com wrote:

I just read over on ZunTzu forums that ZunTzu 2 development has now
shifted from (the abandoned) Silverlight to C++ and OpenGL.

zuntzu.com/forum/**viewtopic.php?t=1715[1]http://www.zuntzu.com/forum/viewtopic.php?t=1715[1]

[1] zuntzu.com/forum/**viewtopic.php?t=1715http://www.zuntzu.com/forum/viewtopic.php?t=1715

225

Thus spake bdgza:

I just read over on ZunTzu forums that ZunTzu 2 development has now
shifted from (the abandoned) Silverlight to C++ and OpenGL.

zuntzu.com/forum/viewtopic.php?t=1715[1]

That’s very interesting. It makes me want to have another go at
convincing Jerome to join us…

–
J.

226

What it says to me is that C++ and OpenGL is probably the right choice.

ZunTzu doesn’t really use a GUI though. I’ve heard there are problems with
GLUT, though I’ve never used it. Do we need to GUI toolkit?

  • M.

That’s very interesting. It makes me want to have another go at
convincing Jerome to join us…

227

OK; we are planning to rewrite VASSAL in C++. Seriously, that has to be 2 (very optimistic) to 5+ (more realistic) year project. Is VASSAL 3 going to be frozen to new featues in that time?

228

Thus spake pgeerkens:

OK; we are planning to rewrite VASSAL in C++. Seriously, that has to be
2 (very optimistic) to 5+ (more realistic) year project.

Based on my experience with the demo, I think that we can have something
usable, but without many features, by the end of the year. Being able
to do everything that V3 does now will take longer, but I don’t expect
it will take as long as 2 years for that. Don’t underestimate the amount
of development time for V3 which has been eaten up by Java bugs and
workarounds. For me, I would say it’s been at least half of my dev time
since we started work on 3.1. That’s a huge drag on the project. We
should be able to move quite quickly once we’re not dealing with those
things.

Is VASSAL 3
going to be frozen to new featues in that time?

I’m divided on that right now. I don’t want to sink dev time into V3
which could be spent on V4 once 3.2 is released (though I do want to
continue with bug fixes as needed). I guess it depends on what the
features are. I’m definitely not planning to work on V3 myself once
V4 is really underway.

–
J.

229

Thus spake Michael Kiefte:

What it says to me is that C++ and OpenGL is probably the right choice.

ZunTzu doesn’t really use a GUI though. I’ve heard there are problems with
GLUT, though I’ve never used it. Do we need to GUI toolkit?

I think we do: I forsee needing dialogs, context menus, tabs/panes,
buttons, and scroll bars. I’m not particularly keen on writing any of
those things myself, and I think we’d be better off with a GUI toolkit
which makes them look right on the platforms we support.

ZunTzu takes a completely different approach with this—there’s a post
someplace in their forum where Jerome explains that he sees ZZ as a sort
of GUI experiment, which is why he devises his own widgets.

–
J.

230

See the 4th post.
zuntzu.com/forum/viewtopic.php?t=1553

231

Thus spake Tim M:

ZunTzu takes a completely different approach with this—there’s a
post
someplace in their forum where Jerome explains that he sees ZZ as a
sort
of GUI experiment, which is why he devises his own widgets.

–
J.

See the 4th post.
zuntzu.com/forum/viewtopic.php?t=1553[1]

Yes, that’s exactly the one I meant.

–
J.

232

Is that why Win7 always insists on giving each running module its own taskbar button separate from the module manager one? :unamused:

Good luck! 8)

233

Thus spake Rindis:

Rewriting in Java won’t let us make the Module Manager and Player run
in the same process.

Is that why Win7 always insists on giving each running module its own
taskbar button separate from the module manager one? :unamused:

Yes. It’s due to a crappy workaround so that you can have different
modules open at the same time. Each open instance of a module will use
about the same amount of memory, ceteris paribus. If everything runs in
one JVM, then everything shares one heap. Unfortunately, you can’t adjust
the max heap from within a running JVM, so in the single process case,
opening more modules means that they’re all competing for the same heap
space. So, either you set a max heap which is far too high for single-
module usage, or you get multiple modules starving each other for
memory.

The way we prevent this is to run each module in its own JVM, which is
a solution I dislike (both because it’s baroque and because it screws
up task identification), but I see no way to avoid while we’re using
Java.

–
J.

234

Hi all,

I thought it might be worth sharing the experience of a complete VASSAL newbie in this thread, to give a different perspective.

I’m an amateur boardgame designer (and professional scientist & programmer) and I would really like a digital platform for playtesting my games. A while back I took a look at VASSAL (and ZunTzu) and rejected them out of hand for being too hard to work with.

However, recently it became evident that a digital playtesting platform was too important to the game design process (my major collaborator is on a different continent) so I revisited VASSAL on Friday. After making my way through most of my first module, I have to say the process has been exhausting.

For the purposes of background information, my current module involves drawing/playing cards, rolling dice and collecting resources. It is not a wargame. There are some complicated issues involved in deck setup, but otherwise it’s a pretty straightforward Euro-style game.

Here’s what Joel said in the first post on this thread, and what I think from the point of view of a newbie VASSAL module designer:

Yes. Absolutely. SO unnecessarily difficult. Pretty much every hour of my module development has had me cursing aloud. The biggest issues for me were the clunky scripting system and the incessant click-click-click required to set individual piece properties, although there were many other frustrations.

My game uses about 60 cards, each of which has individual properties. Since it’s a prototype, I’ll be changing the details of the cards regularly. As far as I can make out, in V3.1 VASSAL you can’t import 60 image files at once into a deck. Wait, what!?

I ended up ripping the module file open, reading the CardSlot data format, and then writing Python code to populate a VASSAL deck from a csv file. I estimate that I’ll recoup the 45mins I spent doing that within maybe 4-8 hours of VASSAL module design usage. Even given that I have to constantly open and close applications to remove the locks on the zipfiles.

Makes sense to me. Hasn’t impacted me so far.

Yes. The cosmetics aren’t a big deal for me, but it’s obvious that I can’t have a convenient layout for my game in V3.1. Specifically, a player’s hand should dock at the bottom of the screen and the mouseover stack should work better (not be clipped to the current window). This matters for cards - you need to be able to see the overall layout and also read individual cards easily.

I can’t comment on this one.

Joel also said:

In principle, I’d certainly prefer a peer-to-peer application than a server-based one.

Hell yes. An additional benefit of this, which Joel doesn’t mention, is that it would facilitate the development of external tools. If the current VASSAL module file structure made more sense, my homebrew Python script for making decks from CSV files would populate the piece properties properly as well.

Obviously well worth doing, although I haven’t had a direct reason to care about it so far.

This probably goes without saying, but a great deal of my cursing stemmed from the fact that the scripting system in VASSAL is uber-horrible. I hated using it and pined for a proper scripting language. JavaScript, Python, Ruby, Lua. Anything.

There have been a few posts on this thread arguing that VASSAL 4.0 should be backward compatible because otherwise it will alienate the existing userbase. This doesn’t take the flipside into account: keeping the legacy system will alienate potential new module and code developers like me. So much so that if I didn’t think VASSAL would change, I would be looking at writing my own application instead.

The library of existing modules for a boardgame app is not its biggest feature. If it was actually easy to develop modules, a good app would have a huge library in a relatively short time. People would cannibalise and convert existing VASSAL modules where possible.

I’ve got a few comments on the merits of different implementation technologies for v4.0, but obviously I’m not a VASSAL developer so I don’t have a big investment in this (yet).

Browser-Based Gaming
For someone like me, browser-based deployment would be a fantastic benefit. Potential playtesters wouldn’t have to download any special application. In general, it would significantly expand the userbase. Further, for obvious reasons, a lot of time and effort goes into infrastructure to make brower-based apps work on every platform (with, admittedly, varying levels of success).

I don’t know if the current crop of browser technologies (Flash, Java, HTML5, Unity, etc.) can handle whatever particular needs VASSAL has. I do know they can implement a wide variety of boardgames, because they are pretty much the dominant technology platform for modern casual gaming. If there’s something VASSAL needs which can’t be done efficiently enough in a browser, it’s not something I need.

So, if I was involved in this project (which I’m not), I would want it to be browser-based. I realise that this might make a peer-to-peer model harder to implement, but browser-based is more important to me than peer-to-peer. Someday, someone will make a browser-based boardgaming app which is as powerful as VASSAL currently is. BrettSpielWelt has presumably done most of it already, but their code is commercial and closed-source.

If casual users are presented with the choice between playing boardgames in their browser, or downloading and installing VASSAL, most will choose the browser option. In no small part this is because they will get to play a game right there and then.

I don’t know what technology would be best for an open-source browser-based boardgame app.

Conceptual Model and Multiple Front-Ends
It would be great if whatever work went into coding Vassal V4.0 was at least partly reusable by other front-ends. Ideally, a developer could write, say, a Flash VASSAL client without seeing the code for the original VASSAL executable. The biggest part of this is designing a decent generic model of boardgames.

To my mind this suggests several desiderata:

  • There should be a basic standard for defining all the logical pieces in a boardgame, including things like resource pools and spaces where cards or counters can be put. This should be distinct from any other aspect of the game. Any virtual tabletop software should be able to read this and spit out a basic, playable version of the game.
  • A game module should (optionally) contain any special code required to deal with the player / game interface and preferably separate code to deal with the game rules. They should be separate in case the player / game interface needs to be different on different front-ends (e.g. mobile phones vs desktops).
  • VASSAL V4.0 should use a well-established existing scripting language for per-module game and presentation logic.
  • Probably, the boardgame coding standard should specify an API for UI and game logic code, rather than a particular language.

That’s enough from me! Hope my two cents are useful.

Simon

235

Picking on a couple points:

How so? Assuming that Vassal 4 allows relatively painless creation of new modules, why do you care how old ones were created?

(Admittedly, you are probably presuming that backwards compatibility would entail tying module creation to it’s current painful state. But that is not known to be true, and you are making it sound like the mere fact of backwards compatibility would alienate you. So: why?)

How do you figure? How is a browser going to know a vassal module from gobbledygook? (Which is all it will be to a browser.) I suppose you could do Vassal as browser plugin, but then you’re right back to ‘downloading a special application’, so I really don’t see what you’re trying to gain here, other than perhaps the ‘comfort’ of doing it all inside your favorite program, instead letting the program be its own thing.

236

Thus spake dogboy:

I ended up ripping the module file open, reading the CardSlot data
format, and then writing Python code to populate a VASSAL deck from a
csv file.

This is one reason why I want to have a readable, properly-documented
file formatfor V4, because I see a lot of value in being able to use
a scripting language for creating and modifying it.

This probably goes without saying, but a great deal of my cursing
stemmed from the fact that the scripting system in VASSAL is
uber-horrible. I hated using it and pined for a proper scripting
language. JavaScript, Python, Ruby, Lua. Anything.

It’s because we grew a programming language organically from a template
language, which guarantees that it will be a bad programming language.

I’ve got a few comments on the merits of different implementation
technologies for v4.0, but obviously I’m not a VASSAL developer so I
don’t have a big investment in this (yet).

Browser-Based Gaming
For someone like me, browser-based deployment would be a fantastic
benefit. Potential playtesters wouldn’t have to download any special
application. In general, it would significantly expand the userbase.
Further, for obvious reasons, a lot of time and effort goes into
infrastructure to make brower-based apps work on every platform (with,
admittedly, varying levels of success).

I don’t know if the current crop of browser technologies (Flash, Java,
HTML5, Unity, etc.) can handle whatever particular needs VASSAL has. I
do know they can implement a wide variety of boardgames, because they
are pretty much the dominant technology platform for modern casual
gaming. If there’s something VASSAL needs which can’t be done
efficiently enough in a browser, it’s not something I need.

So, if I was involved in this project (which I’m not), I would want it
to be browser-based. I realise that this might make a peer-to-peer model
harder to implement, but browser-based is more important to me than
peer-to-peer. Someday, someone will make a browser-based boardgaming app
which is as powerful as VASSAL currently is. BrettSpielWelt has
presumably done most of it already, but their code is commercial and
closed-source.

If casual users are presented with the choice between playing boardgames
in their browser, or downloading and installing VASSAL, most will choose
the browser option. In no small part this is because they will get to
play a game right there and then.

I don’t know what technology would be best for an open-source
browser-based boardgame app.

Last year, when I tried creating an HTML5 demo, I found that the
underlying stuff in the browser—whatever that was—was not efficient
enough to smoothly handle even a moderate sized map. I had a similar
problem with a pure JavaScript demo I wrote. This might change
eventually, but I’m not going to build something which will work only
speculatively. The technology needs to be there when we start.

I don’t like browser-based apps myself, for several reasons. As a user,
I have yet to use one that works properly, and I would like to have the
software I’m running be on my machine. As a developer, I don’t find the
browser-OS combinatorial problem at all attractive, nor do I like the
dynamically-typed languages on offer for writing browser-based apps. So,
I won’t be creating something I don’t want to use myself. That said, I’m
intending for V4 to have a library component cleanly separated from the
GUI frontend, so that someone who wanted to make, say, JavaScript
bindings and a browser-based frontend would be able to do that. I’d
welcome there being clients or frontends other than the reference one I
intend to work on myself. In fact, I think it would be beneficial having
someone design a browser app in parallel with the thick app, as it would
help clarify just what we need out of an API. But don’t expect me to
create or use a browser app myself.

Conceptual Model and Multiple Front-Ends
It would be great if whatever work went into coding Vassal V4.0 was at
least partly reusable by other front-ends. Ideally, a developer could
write, say, a Flash VASSAL client without seeing the code for the
original VASSAL executable. The biggest part of this is designing a
decent generic model of boardgames.

To my mind this suggests several desiderata:

  • There should be a basic standard for defining all the logical pieces
    in a boardgame, including things like resource pools and spaces where
    cards or counters can be put. This should be distinct from any other
    aspect of the game. Any virtual tabletop software should be able to read
    this and spit out a basic, playable version of the game.
  • A game module should (optionally) contain any special code required to
    deal with the player / game interface and preferably separate code to
    deal with the game rules. They should be separate in case the player /
    game interface needs to be different on different front-ends (e.g.
    mobile phones vs desktops).
  • VASSAL V4.0 should use a well-established existing scripting language
    for per-module game and presentation logic.

I reached these conclusions myself.

  • Probably, the boardgame coding standard should specify an API for UI
    and game logic code, rather than a particular language.

I’m not sure what you mean by this one.

–
J.

237

Amen to that. I’ve been there!

Yeah, I imagine that the most promising technology would be a widely-used browser plugin like Flash. I have no experience of coding in Flash, so no idea of how difficult this would be. The Unity plugin might also be worth looking at (and it would support 3D board and piece models easily, in case that’s a plus).

Fair enough.

Sorry, what I meant was that it would be ideal if the standard did not specify a particular scripting language for writing the game rules logic (or user interface logic) in. So, rather than

“VASSAL scripts are written in Lua” (or whatever),
“VASSAL scripts can be written in any language which will interface with the engine. Bindings currently exist for Lua.”

Incidentally, I didn’t mention an additional consideration which would require a significant change from the v3.x model. VASSAL v3.x purportedly doesn’t make any attempt to implement a game’s rules. However, the most obvious use of its scripting capabilities is to automate behaviours which the rules specify… in other words, to implement parts of a game’s rules.

The appeal of a virtual tabletop is that it allows you to play the game without the hassle of someone having to code the game’s logic. This means that you aren’t restricted by someone else’s (probably buggy) rules implementation. On the other hand, it’s tremendously attractive if you can make use of a complete well-coded rules implementation.

This suggests another desideratum:

  • The software should be able to make appropriate use of a self-contained algorithmic representation of the game’s rules.

Simon

238

Thus spake dogboy:

Yeah, I imagine that the most promising technology would be a
widely-used browser plugin like Flash. I have no experience of coding in
Flash, so no idea of how difficult this would be. The Unity plugin might
also be worth looking at (and it would support 3D board and piece models
easily, in case that’s a plus).

There’s not a plugin for Linux. It’s also not open-source.

  • Probably, the boardgame coding standard should specify an API for
    UI
    and game logic code, rather than a particular language.

I’m not sure what you mean by this one.

Sorry, what I meant was that it would be ideal if the standard did not
specify a particular scripting language for writing the game rules logic
(or user interface logic) in. So, rather than

“VASSAL scripts are written in Lua” (or whatever),
“VASSAL scripts can be written in any language which will interface with
the engine. Bindings currently exist for Lua.”

Would we then have to bundle an interpreter for every scripting language
we support? That sounds like it would become a maintenance problem.

  • The software should be able to make appropriate use of a
    self-contained algorithmic representation of the game’s rules.

By “algorithmic”, do you mean “procedural” here? Or something else?

–
J.

239

What you lose on Linux, you may make up in portability across different mobile devices. Just throwing that in there.
And Flash works on Linux, no? (Plus I believe it has an open-source alternative implementation.)

I suppose I am thinking to the future here, and the possibility of an open boardgame standard. A conceptual standard for boardgames clearly should not specify any particular language for the implementation of the rules. To my mind it would be cleaner to say “the interface is abstract and does not specify how scripts should be written; however, VASSAL currently only supports scripts written in X, and there are no plans to change that.”

Incidentally, you will have to bundle an interpreter for every scripting language you support, even if that only amounts to one scripting language (unless you go with browser deployment and JavaScript). The additional work of supporting more languages, if you ever wanted to do so, doesn’t look like it would scale worse than linearly.

I mean “in the form of a computer program”, whether that computer program is written in a procedural, functional, logic or other programming language.

It may turn out that the ideal computing paradigm for implementing the rules of boardgames is not one which is well-supported in the scripting language you settle on. For instance, declarative logic within a PROLOG-style inference engine will be a natural way of describing what sort of moves are allowed at any point, while the overall flow of the game might be better captured in a continuation-based imperative language. I don’t know of any scripting language which conveniently supports those two programming styles. So far.

But as far as a generic boardgame client program is concerned (at least insofar as respecting an implementation of a game’s rules goes), it shouldn’t matter what form the rules are written in. A program is a program. What matters is knowing which moves are available to the current player, and what the consequences of making those moves are. (I suppose it gets more complicated if you ever want the client program to be able to explain the rules to a player. That’s technologically a long-ish way off. I’m not going to worry about it just now.)

Simon

240

Thus spake dogboy:

Would we then have to bundle an interpreter for every scripting
language
we support? That sounds like it would become a maintenance problem.

I suppose I am thinking to the future here, and the possibility of an
open boardgame standard.

That’s my aim.

A conceptual standard for boardgames clearly
should not specify any particular language for the implementation of the
rules. To my mind it would be cleaner to say “the interface is abstract
and does not specify how scripts should be written; however, VASSAL
currently only supports scripts written in X, and there are no plans to
change that.”

I think there are at least three related things which need standards
developed for them:

  • game ontology
  • game display
  • game rules

What I had in mind for “game rules” was a language that can be model-
checked, not something that defines behaviors.

Much of the scripting I had in mind is for GUI behaviors and automation,
not rules-enforcement.

What I don’t like about having support for multiple scripting languages
is that it’s either a waste of time (for languages which aren’t used
much) or it splits the community (if more than one language becomes
popular). The programming world can support many languages, but it’s so
much larger than the world of VASSAL module designers.

But as far as a generic boardgame client program is concerned (at least
insofar as respecting an implementation of a game’s rules goes), it
shouldn’t matter what form the rules are written in. A program is a
program. What matters is knowing which moves are available to the
current player, and what the consequences of making those moves are. (I
suppose it gets more complicated if you ever want the client program to
be able to explain the rules to a player. That’s technologically a
long-ish way off. I’m not going to worry about it just now.)

I have a different view of how this should work, which is driven partly
by how I envision people interacting with such a system, and partly by
some theoretic concerns.

  • A system which enumerates legal moves won’t work, at least not in any
    useful way, because in many games there are choice points where the set
    of legal moves is enormous, or in some cases not even finite.

  • When playing games in VASSAL, something I frequently find myself doing
    is moving pieces that will be used in an attack off to one side, or
    speculatively rearranging some pieces to see what might happen if I or
    my opponent take certain actions. That is, I am moving pieces in ways
    which are not moves in the game.

These two considerations make me think that a good way to go eventually
for rules enforcement is to specify rules in a language that can be
model checked. This way, with rules enforcement turned on, the client
will be able to determine whether a proposed move is legal by checking
whether the proposed state is reachable from the existing state, but
with rules enforcement turned off, the user will be able to fiddle with
the pieces as I described above.

–
J.