[messages] [Developers] Roadmap for VASSAL 4

Michael Kiefte mkiefte at dal.ca
Tue Mar 22 03:49:13 MST 2011


Hi Joel,

I agree with everything you've said here.  I wanted to comment on a specific issue regarding language.  I'm not in favour of keeping Java.  I'm not terribly worried about the bugginess because, honestly, you're going to find that everywhere and I don't have w good sense of whether Java is relatively better or worse than everything else.  I would like to nix the idea of using JavaScript: this will be a nightmare and with paint ourselves into a corner.  JavaScript is a very inflexible environment to work in and if you think we have bugs to deal with in Java....

I have some experience with wxWidgets (even back when it was called wxWindows) and it's very useable and looks good.  Some things are hard to get right, but when you do, the results are excellent.  The platform is open source, so if we find a bug, we can offer a fix ourselves (I've done that in the past). The code is relatively easy to understand and there are cross-platform APIs that can match the breadth of Java.  Also, I would like to point out that Java's future is very cloudy. Oracle seems to not be interested in it and some of their top people have left.  IBM may be the stewards of Java in the future (effectively anyway).

With respect to Java, if we do decide to stick with it, we may want to consider JWT (or whatever IBM calls it). The biggest problem is that it's not terribly extensive (try doing a spreadsheet with it!).   

As you might be able to tell, I would support wxWidgets quite readily.  Another downside, however, is that the number of willing developers might drop -- and I'm not exactly the most prolific contributor.  I am, however, really comfortable with C and the good news is that wxWidgets does not use a lot of C++ "features" (or planned bugs as I like to refer to them). Bjarne Stroustrup is a sadist, by the way.

Everything you've said here, I completely agree with, by the way.

- M.

On 2011-03-20, at 7:57 PM, uckelman <uckelman at nomic.net> wrote:

> I've been thinking over the past few months about where we should be
> heading with the next major release of VASSAL (i.e., VASSAL 4, as
> opposed to minor releases like 3.2); I've reached the point now where I
> want to write down my thoughts, both to clarify them and to see what
> reaction others have.
> 
> I've identified four problems which I see at the most serious ones we're
> facing:
> 
> * Editing and designing modules is unnecessarily difficult.
> 
> * The game server is a single point of failure and will not scale.
> 
> * The interface is clunky and dated.
> 
> * The codebase is tangly, hard to modify and debug.
> 
> I'll now describe in detail what these problems consist of, and why I've
> singled out these problems in particular.
> 
> * Editing and designing modules is unnecessarily difficult. Hardly a day
> goes by without a question here in the forum about some module design
> issue which is conceptually simple, but is difficult to solve due to our
> design. (For example, copying pieces from one module to another, while
> doable, is something that many module designers will not be able to pull
> off, as it involves editing the module buildFile, which is extremely
> cryptic.) The trait system, while it makes some easy things easy, also
> makes some conceptually easy things mind-bendingly hard. A frequent
> complaint that I encounter (e.g., at ConsimWorld and BoardGameGeek) is
> that building modules in VASSAL is much harder than in, say, ZunTzu. I
> don't find this a fair comparison, in particular because VASSAL modules
> generally have far more capabilities than ZunTzu ones; nonetheless, it
> should be as easy (or even easier) to create a VASSAL module with
> ZunTzu-level capabilities than to create a ZunTzu module.
> 
> * The game server is a single point of failure and will not scale. There
> are two problems here: First, when the game server is inaccessible from
> the internet---whether due to hardware failure, a network connectivity
> problem, a power outage---our users aren't able to play in real time.
> Our users are quite vocal about this problem. If the game server is
> inaccessible, somebody will have complained about it on BoardGameGeek or
> ConsimWorld within a little while. As we have no control over when our
> ISP has connection issues, or when a big thunderstorm knocks out the
> power in Tucson, it's frustrating for us as well as for our users when
> this happens. Second---and this is perhaps more serious, though
> longer-term---if we had about five times the number of users we have now
> connecting to the game server, we might start having issues with
> handling all of the server traffic. This isn't the sort of problem where
> we could simply put another game server on another pipe to the internet,
> as our current server architecture isn't designed to accommodate other
> game servers.
> 
> * The interface is clunky and dated. This is a collection of problems.
> The default Swing Look and Feel is horridly ugly. We also haven't taken
> as much care as we should have over the years with making UI
> modifications, which has resulted in a lot of parts of the interface
> which are cobbled together rather than designed. These make VASSAL look
> amateurish. We're also not taking advantage of better display
> technology, such as using 3D capabilities for rotation and scaling, than
> what existed when VASSAL first started. Some of our competitors are, so
> we stand still at our peril.
> 
> * The codebase is tangly, hard to modify and debug. Our codebase does
> not have a clear separation between GUI and backend. We don't have good
> test coverage; partly that's because we only just started writing tests,
> but we're also hindered by having a great deal of tightly-coupled,
> nearly untestable code. Because of this, it's not as straightforward as
> it should be to verify that changes are correct, that bug fixes don't
> break anything else, and to add new features. This problem impedes our
> progress by making simple tasks take longer than they should, and by
> making larger tasks seem to difficult to tackle.
> 
> I believe it's essential that we address these four problems for the
> long-term health of the project. That said, I have some ideas on how to
> address these problems:
> 
> * Peer-to-peer communication between clients
> 
> * Human-readable XML for modules, saved games, logs
> 
> * Model-view separation
> 
> * Hooks for change listening scripts
> 
> And now I'll explain them in more detail:
> 
> * Peer-to-peer communication between clients. This addresses the problem
> with the game server being a single point of failure and not being
> scalable. What I believe we need to do is make it possible for clients
> to host games in an ad-hoc fashion, without necessarily connecting to
> the game server. The idea here is that among any group of clients, one
> of the clients would act as the game server. The only traffic which
> would go to our server would be the notice to add games to the current
> games list, and if none of the clients in a game ere capable of acting
> as the game server themselves. A P2P library which handles NAT traversal
> and shifting the server to a different client if the client currently
> hosting the server disconnects is what we'd need for handling this. We
> do not want to write this code ourselves, so finding a library to handle
> it is imperative. After a bit of poking around, I was unable to find
> anything satisfactory. If anyone can suggest some library which does
> this, I'd appreciate it.
> 
> * Human-readable XML for modules, saved games, logs. This partially
> addresses the problem of modules being difficult to design and edit. For
> an example of how this would help, have a look at this piece definition
> I took from a buildFile:
> 
> <VASSAL.build.widget.PieceSlot entryName="Die" gpid="22" height="0"
> width="0">+/null/button;77,130;-50;-15;100;30;Roll      macro;Trigger
> die roll and remove Zonk Check;;77,130;;;77\,65,90\,65\  globalhotkey;;77,65;77,195;Dieroll\\   globalkey;;90,65;88,130;CurrentMap = Trivia Gameboard && Icon =
> ZCB;false;1;true;true;;Kill Zone Check Button;-1\\\    piece;;;DieButton.png;Die/      \       \\      \\\    null;0;0;22</VASSAL.build.widget.PieceSlot>
> 
> If have some idea of what this will produce, then you're probably one of
> twenty people in the whole world. If you can see how to edit this by
> hand to fix a problem, then you are probably Tim. :) For virtually
> everyone else, this is an impenetrable mess. If I want to copy this to a
> different module, or change it in some way that's difficult to do with
> the Editor, I'll have very little assurance that I won't completely
> botch it.
> 
> Instead, if this were made human-readable, we'd have fewer questions to
> answer from module designers, we wouldn't have to tell people that
> seemingly simple things require them to tediously recreate their work,
> etc. What I'm proposing is that we don't use what are essentially binary
> blobs in our file formats; instead, every game entity is an XML entity,
> and every property is an XML attribute. So, we'd have such things as:
> 
> <piece_type id="42" name="101 Abn">
>   <face image="..."/>
>   <face image="..."/>
> </piece_type>
> 
> XML like this suggests the right way to edit it, unlike what we have
> now. It also makes it possible to process it with other tools, be they
> XML editors, XSLT, UNIX text processing tools, or even custom tools
> written by others. I believe this solution will reduce module designer
> frustration and simplify module construction.
> 
> * Model-view separation. This addresses both the interface problems and
> the poor state of the codebase. I've mentioned this several times in the
> past. In order to make as much of our code testable as possible, we need
> to have our classes be loosely coupled. This means using interfaces
> rather than concrete classes whenever possible. With regard to the GUI,
> it means separating out all GUI code from data-handling code. All GUI
> code would be put into Views, which listen for changes to Model classes
> and display the effects of those changes as appropriate. This should
> make it possible to be rid of many of the threading issues we have now,
> as well as to increase our flexibility with respect to the GUI. In
> particular, we already have Michael's demo using JOGL for zooming,
> panning, and rotation---this could form the basis for a 3D-enabled view.
> This project gives us the chance to improve both the interface and the
> maintainability of the codebase at the same time. It would also open the
> door to creating other types of views. (For example, we could create a
> view which recorded game actions as a video. We could also treat the
> client-server interface as a view...)
> 
> * Hooks for change-listening scripts. This addresses the code quality
> and module design problems. This is also what I believe to be the most
> radical of the proposals I have. As I mentioned above, the traits system
> is an odd beast. It makes some simple things easy for non-programmers,
> but it lacks the flexibility of a real programming language, which
> drives some people to construct Rube-Goldberg-esque contraptions out of
> it when they'd be better served by a small amount of code. We spend a
> lot of time answering questions about its unintuitive behavior. Much
> frustration results from it. Deep nesting of traits causes bad
> performance. I think we should replace the traits system.
> 
> What I think we should replace it with is the following:
> 
> Each game object you can think of as a bundle of properties. For a
> piece, you have such things as which face is up, whether it can be
> moved, whether and to whom it is hidden, etc. Traits modify those
> properties, or do something as a result of those properties being
> modified. Suppose that each game object was able to have
> pre-modification and post-modification listeners on its properties. A
> pre-modification listener would run when a property was about to be
> modified; a post-modification listener would run after a property was
> modified. The code in such listeners could be in a scripting language
> (BeanShell?) which would have access to the data objects and parts of
> the GUI via an API we would define. Furthermore, we would need to make
> it possible to hang such listeners off certain GUI elements, such as
> menu items.
> 
> In this way, many of the traits we have now would be implementable as
> very simple pre- or post-modification listeners. For example, Send To
> Location would be a listener which sets some piece's location. If no existing listener were
> adequate to the job, rather than stringing together a complex series of
> triggers, a module designer could write a small amount of code to do the
> job.
> 
> What I'd like to see in the Editor is a list of standard listeners for
> common tasks (much like the traits we have now), but the scripting for
> which can be edited if the module designer so chooses. I think this
> would be an improvement over what we have now, as it would be less
> obscure, we could rely on the semantics of a standard scripting language
> rather than the somewhat odd semantics we have for expressions now, if
> wouldn't force designers to know how to program, but it would provide
> more power and flexibility for those who do.
> 
> 
> Carrying out these four projects will mean major changes in our
> codebase, possibly junking a great deal of existing code. I don't see
> this as a bad thing, necessarily, as our old and grotty codebase
> contributes to at least two of the problems I described above.
> 
> This brings me to a question I'd like to put to everyone, which is, on
> one hand, independent of the preceding discussion, but is related
> because of the degree to which we'd be rewriting code. The question: Is
> Java still the best language in which to do all of this? I don't know
> the answer to that. I've long had the impression that Java on the
> desktop is not in good shape---we suffer from a lot of Java bugs, which
> you can see marked "External" in our bug tracker, and also we're getting
> to have a pretty good pile of Java bug workaround code, and lots of
> these bugs were reported to Sun/Oracle years ago. I get the impression
> that libraries which are not as monolithic as Java don't leave serious
> bugs unfixed for multiple years. I also get the impression that
> developers using other languages have a lot more flexibility with
> respect to shipping current versions of libraries which they depend on.
> This does not compare favorably with our experience with Macs, for
> example, where we're simply stuck with Java 1.5 because Apple won't
> update it. So, to sum up, I'm dissatisfied with Java for numerous
> reasons. I have some doubts about whether it's the best way forward. I'd
> like to know what other people think about this, as well---but I do see
> this as independent of the issues raised above. I think we should pursue
> the problems and solutions I mentioned regardless, but it's an issue I
> wanted to be sure to raise.
> 
> _______________________________________________
> Read this topic online here:
> http://www.vassalengine.org/forum/viewtopic.php?p=22309#p22309
> _______________________________________________
> messages mailing list
> messages at vassalengine.org
> http://www.vassalengine.org/mailman/listinfo/messages
> 


More information about the messages mailing list