Roadmap for VASSAL 4

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. :slight_smile: 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”>


</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.

I agree 100% with making files human-readable XML, it should not be a major problem to implement and have huge benefits. But making savegame files completely human-readable XML seems to me problematic if that savegame file contains hidden piece information – it would be perhaps too easy for someone to sneak a peak at his opponent. Unless you’d find a way to encrypt or otherwise serialize hidden information.

I hate the traits module, I can manage to use it, but I can’t understand it. Using keyboard commands as triggers is hell to use. Keyboard shortcuts need to be separated from the events they trigger. Although I’ve not used it much yet, Python is a language that is used a lot nowadays for all sorts of application scripting.

I think Java is great in the way it provides a free cross-platform environment, which is very easily dynamically expandable with class loading, but it looks horrible. You can make Java apps look better, but it takes a lot of work. For me the most important thing is that it remains cross-platform. If you are going to do that without Java there are not a lot of attractive options imho. There are some libraries that provide cross-platform GUI libraries, but they will only look good on one platform, or none of them, pretty much like standard Swing. Things like GTK+ look worse on Mac than basic Swing. One solution to this is to not use the OS widgets, but to make the interface completely custom drawn, so you only need to design one for all platforms, and write a foundation layer of code for each platform that runs below the game engine and GUI code itself.

Interesting post.

I am new to the code base and it is a bit messy, there is not as much separation between layers (not just the GUI) as one might wish, but it is hard work keeping code clean over time.

A clearer format would help people to look and see what is going on and allow people to edit outside of Vassal which would be a good thing.

Not sure I quite understand how the traits replacement would work but you obviously see a way so it would be worth looking at further.

The server as a central point of failure, or overload, is not a good plan so p2p seems sensible but I know almost nothing about it. A quick look round gives JXTA and the Java peer-to-peer sockets but it doesn’t look like a particularly active community.

The last point is very interesting - what ideas do you have?

My native language is Java but that is because that is where the work has been, I would prefer to use the more modern dynamic languages (Ruby for example runs on Windows, Linux and OSX) as they are more fun, more productive and require less coding (I have RSI type problems). Speed is ok and it easy to go into C if you hit a slow spot, and it is easy to link in with 3rd pary libraries.

Ruby runs on all mentioned platforms, but it’s not easy to develop GUI binaries for all those platforms from the same code (I’d be happy to be proven wrong on this). From what I have understood a lot of 3rd party libraries are binaries (meaning they probably won’t work cross-platform)? On Windows you could use IronRuby with Visual Studio, but it means .NET, so you are basically dropping Macs (I know Mono, it’s not exactly a solution). You could make a lovely Ruby Mac app with MacRuby (from Apple), but it only works on Macs. You could use something like GTK+, which I already mentioned has worse looking widgets than Java. Or you can use JRuby which goes back to Java with AWT or Swing, where we started.

wxWidgets seems to be highly regarded and has good Ruby bindings.

Or for real cross-platform development what about Javascript Vassal running in a browser!

Thus spake bobd:

wxWidgets seems to be highly regarded and has good Ruby bindings.

Yes, I’ve seen that wxWidgets has Java bindings as well.

Or for real cross-platform development what about Javascript Vassal
running in a browser!

I have mixed feelings about this. On one hand, I detest browser-based
apps myself, as you get none of the advantages of a window manager and
all of the disadvantages of browser quirks. I’ve also not seen any
browser-based apps which can handle 3D smoothly. However, I can see the
appeal for people, so having something like that as one possible frontend
might be something we want to look into. I just don’t want it to be the
only frontend.


J.

Browser-based Vassal is definitely an interesting idea, and something I’d love to contribute to. For comparison to gaming apps already developed, there’s freeciv.net (HTML5), and for 3D browser apps, Google’s version of Quake 2 (HTML5), and id’s QuakeLive (the actual game is a browser plugin written in C, frontend has some horrid flash bits too).

You could even wrap offline and p2p modes into an HTML5 app.

It’d be a massive undertaking moving to browser, no doubt.

I don’t think that they have survived, wx4j got to version 0.2 in 2004 and jwx got to version 0.0.2 in 2006.

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@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. :slight_smile: 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”>


</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:
https://forum.vassalengine.org/t/roadmap-for-vassal-4/3769/1


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages

Thus spake Michael Kiefte:

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 terrib
ly worried about the bugginess because, honestly, you’re going to find that e
verywhere 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 JavaScr
ipt: this will be a nightmare and with paint ourselves into a corner. JavaSc
ript is a very inflexible environment to work in and if you think we have bug
s to deal with in Java…

Could you expand on that a bit? I’ve had a number of people suggest to me
that the frontend be done in JavaScript now. I’d like to know in more
detail why you think it would be problematic.

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, b
ut when you do, the results are excellent. The platform is open source, so i
f we find a bug, we can offer a fix ourselves (I’ve done that in the past). T
he code is relatively easy to understand and there are cross-platform APIs th
at 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 (e
ffectively anyway).

Yes, this worries me a lot. I have some doubt about whether we’ll have
a good selection of libraries in Java five years from now.

As you might be able to tell, I would support wxWidgets quite readily. Anoth
er downside, however, is that the number of willing developers might drop –
and I’m not exactly the most prolific contributor. I am, however, really com
fortable 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 i
s a sadist, by the way.

Well, aside from Java, I’m also very comfortable in C, C++, and Perl. I
could become comfortable with basically any language in a few weeks,
though I think I would curse to myself if I had to use Python, due to the
restrictions on whitespace. I prefer C++ myself, and I think that for the
backend at least, it makes a lot of sense, and would give us the best
selection of libraries.

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

I’m glad you think I’ve identified the problems correctly. :slight_smile:


J.

I have very little experience with JavaScript, but what little I’ve looked at suggests that there are a few implementation problems. I would be uncomfortable dealing with browser-specific issues when they come up. As a JavaScript developer, you have a lot less control over the platform being run. Also, my experience suggests JavaScript can be very inflexible and kind of kludgy. It was never designed for large-scale applications. With wxWidgets there would be no restrictions on what we could do in the future and we would only be limited by our own imaginations.

To give you an example, when I was working on the JOGL stuff, I had in my mind a way to implement terrain elevation when location traits would be introduced (e.g., Combat Commander). In JOGL, there would be a very intuitive way to implement elevation. That is probably doable in Jacascript, but it’s probably a kludge.

Just my thoughts.

  • m.

On 2011-03-22, at 8:49 AM, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Michael Kiefte:

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 terrib
ly worried about the bugginess because, honestly, you’re going to find that e
verywhere 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 JavaScr
ipt: this will be a nightmare and with paint ourselves into a corner. JavaSc
ript is a very inflexible environment to work in and if you think we have bug
s to deal with in Java…

Could you expand on that a bit? I’ve had a number of people suggest to me
that the frontend be done in JavaScript now. I’d like to know in more
detail why you think it would be problematic.

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, b
ut when you do, the results are excellent. The platform is open source, so i
f we find a bug, we can offer a fix ourselves (I’ve done that in the past). T
he code is relatively easy to understand and there are cross-platform APIs th
at 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 (e
ffectively anyway).

Yes, this worries me a lot. I have some doubt about whether we’ll have
a good selection of libraries in Java five years from now.

As you might be able to tell, I would support wxWidgets quite readily. Anoth
er downside, however, is that the number of willing developers might drop –
and I’m not exactly the most prolific contributor. I am, however, really com
fortable 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 i
s a sadist, by the way.

Well, aside from Java, I’m also very comfortable in C, C++, and Perl. I
could become comfortable with basically any language in a few weeks,
though I think I would curse to myself if I had to use Python, due to the
restrictions on whitespace. I prefer C++ myself, and I think that for the
backend at least, it makes a lot of sense, and would give us the best
selection of libraries.

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

I’m glad you think I’ve identified the problems correctly. :slight_smile:


J.


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages

Browser based gaming is the hot thing going right now but doesn’t mean we should do it too - being trendy doesn’t mean being good or being the best game play aid option available which should be the goal and I don’t see being browser based meeting that criteria based on the browser game apps I’ve seen already. They are really quite crappy in one way or another.

I’ll reserve my other thoughts - still thinking about everything else

wxWidgets suggested by Michael looks like a good cross-platform framework. It looks to me like higher level entry for developers though, so I don’t know if the developers could/would make that step.

I checked out freeciv.net, done in HTML5 this week, and was very impressed. But it runs the game processes on the server. I can’t imagine that would be what you’d want, more server strain. The code to do it is complex, and that only runs 1 kind of game! Please don’t consider JavaScript, it’s great for scripting web pages, but not for complex applications like this. JavaScript is interpreted code, so you will get a huge performance hit from that alone. You’d also need to use some other means for the “GUI” with JavaScript, so you’d end up with browser dependent display code (DHTML/CSS) which breaks every few months with updates. Despite the hype nothing serious gets written like this. You have web games, but they are either flash and/or very very simple. There is google apps, but although nicely done, they do nothing as complex as VASSAL. HTML5 adds a lot of features, but is far from final and there is inconsistent support for it. Instead of JavaScript you could write an application in Flash/Flex or Silverlight (ZunTzu 2 is planned to use Silverlight), but the step to just making a desktop app with much more flexibility in what you can do is small.

Hi all!

I’m the developer of OpenSettlers, a game engine specific to design Settlers of Catan games written in Java. It contains a reference implementration of a SoC client using GWT ui codebase. GWT compiles Java to Javascript, enabling me to write java, but have a complete browserbased game. An alpha demo is up at opensettlers.sourceforge.net. Keep in mind that it’s an alpha demo (lotsa bugs, looks still ugly), I will upgrade it in the coming weeks to a much more playable version.

In this post, I will outline some of the design decisions and implementation strategies I used. I hope they inspire the Vassal team for the implementation of the v4 release.

Seperation of UI/data
The codebase of OpenSettlers has the seperation of concerns (ui and data). I have defined interfaces for most things, implementation of these interfaces use a “SimpleEventBus” to propagate changes in the objects. That way UI objects can subscribe to changes in the data. A truly seperated should be able to have different UI implementations. Currently, OpenSettlers has this: It uses SVG to draw the gameboard as only implementation. If you like code, here are some links to the Robber implementation (a robber can move, and has a location property):
Robber class:
github.com/generateui/OpenSettl … obber.java
Moved event:
github.com/generateui/OpenSettl … Event.java
Moved event handler:
github.com/generateui/OpenSettl … ndler.java

EventBus interface and SimpleEventBus are classes from GWT, but these are extracted from another project, code.google.com/p/simpleeventbus/. It should be easy to build a custom one for Vassal.

As OpenSettlers is mainly focused on offering a webbased playing experience, I’m writing code for GWT UI only. However, a dev wanting to make a swing or JavaFX would only need to implement a set of interfaces already defined. A browser itself offers a few possibilities also to write UI in: HTML, canvas, canvas3d (WebGL), SVG and flash. As such, a 3D version of OpenSettlers would be trivial to add, only the defined interfaces should be implemented, similar to adding a swing or JavaFX implementation. The data classes can be reused among those UI implementations. OpenSettlers is based on GWT 2.1, when it upgrades to GWT 2.2, I will add support for the canvas drawing, which only involves adding about 10-15 classes which implement the defined interfaces.

Abstracted definition of data
Another point of Uckelman is using another way to store the data into files. Uckelman proposed XML as a way of doing this. OpenSettlers has the same problem: the classes only consisting of data (no behaviour/methods) must be defined, and then some serialization technique should be added in order to read/write this data from disk/ssd. The solution I will use will be protobuf: code.google.com/p/protobuf-gwt/. Protobuf lets you define those dataclasses in a DSL, resulting in a set of protobuf files containing the definition of all dataclasses. With this platform and language independent definition, you have a basis which you can use ANY serialization technique with. Whether that’s XML, Java, Json, RelaxNG, plain text, it does not matter. Currently serializers exist for quite some languages, included the noted ones (XML, Json etc).

Some examples why this will benefit OpenSettlers:
I’d like to store some data into the local browser storage. For instance, I’d like to save board definitions of OpenSettlers locally, to prevent redownloading them each time a player connects to a server. I have an interface Board, with a corresponding implementation BoardImpl. To do this without protobuf, I must either create a new class taking a Board, then manually write code to serialize this to Json in order to write this to the local storage in the browser. I must do this for every data class definition I want to store into the local browser storage. When the definition changes, I need to update this manual code, you get the idea.
Instead, protobuf solves this for me. Using a generator, a Json implementation of the data class is generated from the protobuf definition. No need to write a single line of code. This would be no different when using XML.

I get very excited when I realize other SoC projects can reuse the protobuf defnition. Pioneers is such an implementation, written in C. It would be a matter of applying a C generator (which exists) to the protobuf definition. This generator then generates the dataclasses in C. If Pioneers would do this, Pioneers and OpenSettlers would become compatible. So, it not only saves writing manual code, it also allows to have a “standardized protocol”. No matter what language or platofrm is used: as long as a generator exists, it’s compatible. When no generator exist, it’s not very hard to write one. Lots of generators already exist.

I’m planning to add protobuf in a few weeks. It would be much better when I started with protobuf, but I only learned of them far in the implementation process. As OpenSettlers isn’t out of alpha yet, not all is lost ;).

My personal preference: I very much dislike XML, but like Json much more. That’s fine: a Json file will do just as good as an XML file. As long as there is a platform independent way to describe the data and then generate code from it, it’s just a matter of adding a generator to support another serialization technique.

GWT
Google Web Toolkit is not only a Java to Javascript compiler. It’s also a “set of best practices”. In working with GWT for about 6 months now, I came to learn that GWT is created with the unix philosophy in mind. Basically, GWT is a set of small, focused libs. Not only did I learn a lot of GWT specific stuff, but also lots of good idea’s, practices and good quality code. Examples are the ModelViewPresenter paradigm, handling of resources and RequestFactory.

GWT defines an application in three folders: shared, client and server. This makes sense: Seperating the code shared among the client and server, the client UI code, and the server specific code. You’re not forced to do it like this, but it turned out to be quite clarifying.

Vassal & OpenSettlers
I have looked to use Vassal for OpenSettlers to avoid writing code which I can reuse from Vassal. Uckelman describes the problems very accurately for why I dismissed it (for now). As parts of Vassal and OpenSettlers are pretty much alike, it would make sense to reuse those parts. When v4 successfully addresses above noted problems with the codebase, I’d very interested to reuse/include Vassal code into OpenSettlers. If solutions for the mentioned problems fall in my domain of expertise, I’d be happy to help with the transition, too.

I hope I add my 2 cents with this contribution. Greetz, generateui.

First of all, wxWidgets is indeed cross-platform, but: it’s still platform dependant, as currently every UI library is platform dependant. Namely: wxWidgets is dependant on the wxWidgets platform. This may sound a bit weird, but the current state of UI toolkits is that none of the toolkits/libraries implement a set of standardized interfaces. Truly platform independance would be achieved by having a set of interfaces for widgets/behaviour defined, and then implemented in the various libs/toolkits. Example: Say I make a login window. I HAVE to tie the code in the loginwindow to the UI lib. I cannot define an instance of interface Button. Instead, I have to define wxButton, or gwtButton, or javafxButton. If I’d be able to define a private button Button; , i can have the instance of the button be polymorphic.

GWT is a different beast. It can support Javascript, without ever working with javascript code directly. Modern browsers such as Chrome and Firefox actually compile javascript objects into anonymous classes, which are then consumed by the javascript engine. This results in very fast code execution. You can say the old IE <8 and FF <3 engines are indeed code interpreters, but newer engines lean towards JIT compilation, like Java or .NET. Especially for boardgames, performance is not really an issue. The above link to OpenSettlers demo uses 1MB of minified javascript code (!). That’s a lot of interpretation. When loading locally from SSD, loadtime on a single core 1.5Ghz is below 1 second. That’s surely acceptable. And I even have not yet optimized the OpenSettlers code yet. There’s a huge set of classes which are not really necessary, but are compiled by GWT nevertheless because I needed only a few classes.

GWT only supports features which work in all major browsers. That’s the reason SVG is not yet supported: it’s implementation in the different browsers is not yet on par for every major browser. On the other hand, canvas is supported by the major browsers, and as such supported by GWT 2.2.

As I noted in my previous post, when there is a UI agnostic codebase, it doesnt matter if you want to use SWT of GWT of JavaFX or flash or whatever.

We would never be able to be completely platform neutral as the VASSAL
engine relies on a very wide list of libraries. What you describe would be
very limiting. Although it sounds like a good idea, we would only be able
to support the lowest common denominator with respect to both platform and
browser. That’s great for small apps or very restricted ones, but I can see
us hitting brick walls a lot.

As for JavaScript itself, I see dynamic typing as a debugging nightmare.
We’re actually trying to go in the opposite direction with better defensive
programming practises. In addition, we’re currently looking at ways to
expand our capabilities not restrict them further (e.g., better graphics/3D
engine).

With respect to a C-based language, conversion from Java is relatively
straightforward excepting the UI. JavaScript has a lot of scoping issues
that make a straight translation very tricky.

I think the frontrunners are still the status quo (Java+Swing), Java+SWT,
Qt, or wxWidgets. They all have their problems, but having to rely on a
webbrowser (who might later decide that a feature we’re using is actually an
annoyance) would create more problems in terms of support. Right now, we
support Windows, Mac, and Linux directly, but I can’t imagine supporting
multiple web browsers and all the problems they introduce.

  • M.

On 27 March 2011 12:43, generateui rtimon@gmail.com wrote:

wxWidgets suggested by Michael looks like a good cross-platform

framework. It looks to me like higher level entry for developers
though, so I don’t know if the developers could/would make that step.

First of all, wxWidgets is indeed cross-platform, but: it’s still
platform dependant, as currently every UI library is platform
dependant. Namely: wxWidgets is dependant on the wxWidgets platform.
This may sound a bit weird, but the current state of UI toolkits is that
none of the toolkits/libraries implement a set of standardized
interfaces. Truly platform independance would be achieved by having a
set of interfaces for widgets/behaviour defined, and then implemented in
the various libs/toolkits. Example: Say I make a login window. I HAVE
to tie the code in the loginwindow to the UI lib. I cannot define an
instance of interface Button. Instead, I have to define wxButton, or
gwtButton, or javafxButton. If I’d be able to define a Code:
private button Button;

, i can have the instance of the button be polymorphic.

Please don’t consider JavaScript, it’s great for scripting web pages,

but not for complex applications like this. JavaScript is interpreted
code, so you will get a huge performance hit from that alone. You’d
also need to use some other means for the “GUI” with JavaScript, so
you’d end up with browser dependent display code (DHTML/CSS) which
breaks every few months with updates. Despite the hype nothing serious
gets written like this. You have web games, but they are either flash
and/or very very simple. There is google apps, but although nicely
done, they do nothing as complex as VASSAL. HTML5 adds a lot of
features, but is far from final and there is inconsistent support for
it. Instead of JavaScript you could write an application in Flash/Flex
or Silverlight (ZunTzu 2 is planned to use Silverlight), but the step
to just making a desktop app with much more flexibility in what you
can do is small

GWT is a different beast. It can support Javascript, without ever
working with javascript code directly. Modern browsers such as Chrome
and Firefox actually compile javascript objects into anonymous classes,
which are then consumed by the javascript engine. This results in very
fast code execution. You can say the old IE <8 and FF <3 engines are
indeed code interpreters, but newer engines lean towards JIT
compilation, like Java or .NET. Especially for boardgames, performance
is not really an issue. The above link to OpenSettlers demo uses 1MB of
minified javascript code (!). That’s a lot of interpretation. When
loading locally from SSD, loadtime on a single core 1.5Ghz is below 1
second. That’s surely acceptable. And I even have not yet optimized the
OpenSettlers code yet. There’s a huge set of classes which are not
really necessary, but are compiled by GWT nevertheless because I needed
only a few classes.

GWT only supports features which work in all major browsers. That’s the
reason SVG is not yet supported: it’s implementation in the different
browsers is not yet on par for every major browser. On the other hand,
canvas is supported by the major browsers, and as such supported by
GWT 2.2.

As I noted in my previous post, when there is a UI agnostic codebase, it
doesnt matter if you want to use SWT of GWT of JavaFX or flash or
whatever.

As Vassal is written in Java, Vassal ties itself to the Java platform, which depends on… the JVM (Java platform). I’m very curious about the limitations you see towards the things I describe. As I see GWT as a few things, I also see GWT as a GUI library. From that perspective, It would not be limiting, but just another option to perform the GUI implementation with.

To build further on the Robber code example links I posted: I have an SvgRobber, but as well I can make a CanvasRobber or Canvas3DRobber. All XxxRobber classes implement RobberVisual and subscribe to the MovedEvent to change their [x,y] location. The Robber behaviour and data is seperated into a Robber class, and abstractly defined in RobberVisual interface and implemented in SvgRobber class (or the future CanvasRobber class).

See for RobberSvg: github.com/generateui/OpenSettl … erSvg.java

If you explicitly do not support IE, you can have most cake and eat it too.

Exactly. That’s why GWT worked out for OpenSettlers so well. No dynamic typing, good IDE support, and improved capabilities for the UI (such as canvas, canvas3d (WebGL), html and SVG).

I’m not sure if you’re replying on me, or a previous post. I only talked about C with Pioneers as example, so I assume you’re not replying with above quote to my post.

The point of Uckelman is to decouple classes currently tightly coupled to SWT from the UI toolkit, seperate UI classes from other classes. When that’s done, it does not really matter what UI toolkit one uses. OpenSettlers uses currently 2: an external SVG library, and the GWT widgets. As the architecture of OpenSettlers explicitly supports this using interfaces (loosely coupled design), I can make widgets in SWT, GWT, JavaFX, Canvas, SVG, whatever I like. The question indeed would be what UI library Vassal would support officially, which I should not answer as I am not part of Vassal.

Your last sentence make me believe that what GWT does is not fully understood. Applications written with GWT are entirely written and debugged in java and your favorite IDE. GWT contains a compiler which translates Java to Javascript, so a user can run the application in the browser. GWT makes different permutations for each browser, to ensure the small (and sometimes big in the case of IE) differences are taken care of. That’s something GWT does by default, nothing which the programmer needs to do. I have actually not written a single sentence of javascript, though OpenSettlers still runs 100% natively (no flash/java applet, 100% html/javascript/css) in the browser. By using GWT, I have a single codebase, and I can support any browser, device (as long as it has a modern browser, like Android and IOS devices) and resolution (abstracted UI in OpenSettlers takes care of this). I don’t have to worry about OSes, since the browser itself abstracts the OS. Apart from the SVG element (GWT 2.2, which supports canvas, removes the need for SVG), I have not yet found any crossbrowser bugs. Crossbrowser support is handled by GWT, not by the programmer coding against GWT.

I am no contributor for Vassal, so the things I share on this forum are just FYI. It’s just my experience devving on a codebase in many aspects similar to Vassal’s. I don’t own Google shares, I’m just a techdude sharing learned lessons :slight_smile:

  • The game server is a single point of failure and will not scale.

Making all of VASSAL web-based, even if it runs mostly in client-side Javascript, will still add strain to an already strained server, and does not solve the single point of failure. If VASSAL must be redone as a web-based platform it must use technology which can run offline (when the server goes down). That leaves HTML5, Adobe AIR/Flex, MS Silverlight. HTML5 is completely unready. Adobe AIR runs on all currently supported platforms, but it basically a fancy Flash app, and I don’t think it is suitable. MS Silverlight I think might be suitable someday, but it does not support Linux. The developer of ZunTzu is looking at Silverlight for ZunTzu 2, but I think it will be a tough nut to crack, and ZunTzu does a whole lot less than VASSAL. While there are some fancy web-apps out there, they all rely on their server and are all custom programmed to support one single game/task.

Bottom line is that I don’t feel that all things considered there is any argument that makes web-based make more sense than a more suitable technology. You find the tools to fit the solution, not fit the solution around the tools. If you make it web-based, you force it through because you feel it must be web-based. Desktop applications provide a richer framework and more offline flexibility. Whats important is choosing one that works best on all three currently supported platforms, is easiest to expand to other platforms (iOS/Android/…), and is easiest for the developers to implement all the existing and future desired features (2D/3D graphics, modules and extensions, Python event scripting, …).

I am not a developer either, so my contribution to this thread is all FYI too. I make desktop and web apps. Completely different field from VASSAL, but code is code :wink: .

Thus spake Michael Kiefte:

As for JavaScript itself, I see dynamic typing as a debugging nightmare.
We’re actually trying to go in the opposite direction with better defensive
programming practises. In addition, we’re currently looking at ways to
expand our capabilities not restrict them further (e.g., better graphics/3D
engine).

I was curious to see what could be done with JavaScript as it is now,
so I worked up two demos over the weekend, one using the HTML5 canvas,
and one using regular DHTML techniques. I’ve put the demos here for you
to try:

vassalengine.org/~uckelman/js-test.tar.bz2
vassalengine.org/~uckelman/js-test.zip

(Both archives have the same content, download the one you prefer.)

Once you’ve unpacked the archive, browse to launch.html, where you’ll
find a link to each of the demos. In each demo, you should be able to
drag around the pieces. In the elements demo, dragging on the map pans
it.

I learned a few things by doing this:

  1. The canvas demo is unusable for me. It turns out that this has
    nothing to do with the huge map image—it’s just as bad when there’s
    no map image. What does matter is the size of the canvas. It works well
    for me at 1000x1000, but 8000x3000 is 24 times larger. I don’t know how
    the canvas is implemented in Firefox 3.6.16, but it seems that they’re
    not using algorithms which scale up well.

Also of note here is the fact that every canvas example I was able to
find on the web assumes that you’ll have about 10 objects on your
canvas, so does collision detection by searching the whole object list
and testing each one for hits, and also repaints the whole canvas every
time something changes. If you do either of these, instead of using a
quadtree for collision detection and repainting only changed regions,
you can’t even get a 1000x1000 canvas to work well with 100 objects on
it.

  1. The elements demo works well for me. It’s also 245 lines of code, 41
    of which are just HTML. The reason it’s so small is that all I had to do
    was write event handlers for some mouse events. The browser is already
    providing all of the collision detection, repainting, drag and drop,
    and image loading. We have thousands of lines of code in VASSAL for doing
    essentially the same thing.


J.

Hi Joel,

Why did you comment out mapZoom(e)?

  • M.

On 28 March 2011 09:13, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Michael Kiefte:

As for JavaScript itself, I see dynamic typing as a debugging nightmare.
We’re actually trying to go in the opposite direction with better
defensive
programming practises. In addition, we’re currently looking at ways to
expand our capabilities not restrict them further (e.g., better
graphics/3D
engine).

I was curious to see what could be done with JavaScript as it is now,
so I worked up two demos over the weekend, one using the HTML5 canvas,
and one using regular DHTML techniques. I’ve put the demos here for you
to try:

vassalengine.org/~uckelman/js-test.tar.bz2
vassalengine.org/~uckelman/js-test.zip

(Both archives have the same content, download the one you prefer.)

Once you’ve unpacked the archive, browse to launch.html, where you’ll
find a link to each of the demos. In each demo, you should be able to
drag around the pieces. In the elements demo, dragging on the map pans
it.

I learned a few things by doing this:

  1. The canvas demo is unusable for me. It turns out that this has
    nothing to do with the huge map image—it’s just as bad when there’s
    no map image. What does matter is the size of the canvas. It works well
    for me at 1000x1000, but 8000x3000 is 24 times larger. I don’t know how
    the canvas is implemented in Firefox 3.6.16, but it seems that they’re
    not using algorithms which scale up well.

Also of note here is the fact that every canvas example I was able to
find on the web assumes that you’ll have about 10 objects on your
canvas, so does collision detection by searching the whole object list
and testing each one for hits, and also repaints the whole canvas every
time something changes. If you do either of these, instead of using a
quadtree for collision detection and repainting only changed regions,
you can’t even get a 1000x1000 canvas to work well with 100 objects on
it.

  1. The elements demo works well for me. It’s also 245 lines of code, 41
    of which are just HTML. The reason it’s so small is that all I had to do
    was write event handlers for some mouse events. The browser is already
    providing all of the collision detection, repainting, drag and drop,
    and image loading. We have thousands of lines of code in VASSAL for doing
    essentially the same thing.


J.