Hello,
can you please explain the reasons to move VASSAL to C++?
I don’t think it is a good idea. No portability, code more difficult to mantain, more difficult to debug.
Also, rewriting completely the code is always anti-economic: lot of work for little optimization.
I really need to understand your reasons. Can you please explain?
We went over this a lot already.
Ironically, Java sucks for platform dependence issues. Joel has had a
miserable time with graphics under Java trying to ensure everything works
transparently across platforms. I haven’t done anything with that, but I do
a lot of audio work and Java sucks for that too in terms of platform
dependence. Debugging in Java is not bad, but it’s not bad in C++ either.
C++ is no more difficult to maintain.
I believe the #1 reason is graphics. We would be capable of a lot more were
it not for Java. Java has a lib for OpenGL, but it’s out of date and
somewhat difficult to use (and very platform specific – so no advantage
over C++ whatsoever).
On 1 August 2011 14:57, cianchet cianchet@tiscali.it wrote:
Hello,
can you please explain the reasons to move VASSAL to C++?
I don’t think it is a good idea. No portability, code more difficult to
mantain, more difficult to debug.Also, rewriting completely the code is always anti-economic: lot of work
for little optimization.I really need to understand your reasons. Can you please explain?
I imagine I am the last one in the queue of people who could have complained about this decision.
Portability: people will ask to see Vassal for IPad and for Android. Ok Java is no good for both, but is C++ better?
In my opinion you will end supporting a windows version only, actually reducing portability.
Now I can play in Linux. Ok no great graphics, but I can use it.
Examples of good graphic interface in Java: gametableonline. Have you ever seen it? It’s in Java.
Sound??? Do you need sound on boardgames? Do you want to hear KABOOM when your artillery fires???
IMHO you should think more in terms of functionality.
What you have:
What you miss (in order of importance):
If you move to C++, you will also lose the Java code which is currently implemented in the modules.
I don’t think is a good deal.
I’ve been pushing this a long time but the current code was never originally built with that in mind. Sometimes starting from scratch is the easier thing to do. 
A scripting language like Lua - yes, a true AI not nearly as important though - the idea is to play against other people, not the computer 
Has been discussed before. Ideally what should replace it is a comm software integrated with the engine in some way… such as skype/mumble/ventrilo/teamspeak etc - most still provide a loggable chat line too so I guess that is an improvement and still usable for pbem
A whole set of unique challenges here I forsee due to the complete difference in gui behavior that needs to be resolved/coexist with traditional pc media and still work properly in both environments i.e expanding counter stacks - dbl click mouse = double tap screen etc…? This wont be an easy task
Portability: people will ask to see Vassal for IPad and for Android. Ok
Java is no good for both, but is C++ better?
I don’t know about Android, but I can assure you that C++ is infinitely
better for iPad than Java. You can actually compile C++ code for iOS,
whereas you cannot for Java.
In my opinion you will end supporting a windows version only, actually
reducing portability.
To the best of my knowledge, most (many?) VASSAL developers actually use
Linux. I’ve contributed a fair bit of code to VASSAL and I personally use
Linux on a Mac and dual boot. I actually have the least experience with
Windows and rely on others to tell me if things are working alright as I do
not have a working Windows computer.
Sound??? Do you need sound on boardgames? Do you want to hear KABOOM
when your artillery fires???
No, I didn’t say that. I personally work with sound outside of VASSAL and
platform independence is terrible with Java. The irony is that it used to be
platform independent but somewhat useless. Now it has quite a lot of
features but is impossible to work across platforms transparently. So this
is a good example of Java not living up to its promise as being a platform
independent language. As I said in my post, Joel has wasted a lot of time
with VASSAL ensuring the image stuff works the same across platforms. Given
my experience with audio, this doesn’t surprise me. I did some prototypes
for 3D graphics in VASSAL using Java and I was frankly quite surprised at
how difficult it was to get the same experience across platforms. So if
it’s going to be that much of a hassle, I no longer see the advantage of
using Java.
And Java itself has bugs that we have no control over. That’s also a huge
pain. One of my motivations for switching is that, if we use an open
toolkit under C++, we can actually contribute to that toolkit when bugs
arise which would benefit everyone.
What you have:
…
What you miss (in order of importance):
…
It’s probably a good idea to go back and read the archives on these topics.
If you move to C++, you will also lose the Java code which is currently
implemented in the modules.
I don’t think is a good deal.
As the author of a module that probably has the most custom code of any
other, I’m not actually worried about that. Converting from Java to C++ is
not that hard. Going in the other direction is a nightmare, but,
fortunately, we don’t have to do that! Some stuff has to be reimplemented
from scratch, but I think that’s mostly Joel’s image stuff and he’s probably
the biggest proponent of the switch. And the VASSAL UI is so primitive,
that converting it to almost any windowing toolkit will be an improvement
regardless.
Thus spake cianchet:
Hello,
can you please explain the reasons to move VASSAL to C++?
I don’t think it is a good idea. No portability, code more difficult to
mantain, more difficult to debug.Also, rewriting completely the code is always anti-economic: lot of work
for little optimization.I really need to understand your reasons. Can you please explain?
C++ is more portable than the current codebase. We have thousands
of lines of Java to work around all manner of plaform differences. I
have never written more platform-specific code in any language than I
have in Java.
The current codebase is rotten to the core. There is almost nothing
I can point to in the current codebase that should be designed the way
it is knowning what we know now. And it’s not just design problems, it’s
also bugs. We’ve had the automatic bug reporter collecting crash
information for quite some time now, we’ve made a heroic effort to fix
all of those bugs, but more than two years later we are still getting
reports of bugs which so far as I can tell already existed in VASSAL 2
or earlier.
Working with what you have makes sense when what you have is
fundamentally sound. But the way to untie the Gordian Knot is to cut
it, not to pick at it until it comes loose. By starting over, we
can have a sound design and thorough unit testing from the beginning,
rather than trying to retrofit it onto something which we would have
to fight at every step and of which we would be unable to verify its
behavior.
You’re quite free to start working on any bugs you like if you disagree
(and, in fact, we would appreciate the help, as we are still doing
development work on 3.2 right now). Here are the current 25 most-
reported bugs:
vassalengine.org/tracker/dup … openonly=1
Have at them.
In C++, the only image loading code we need is essentailly the standard
example code which you find for loading images into byte arrays. It’s a
few hundred lines, has no special cases, and is utterly straighforward.
I know this because I’ve already written it. It successfully loads all
of the “bad” test images I’ve collected that Java barfs on. Because
almost everything which loads images relies on the libraries we’ll use
(e.g., libjpeg, libpng), if we do find a bug, we will not have to wait
a decade for that bug to be fixed.
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 resisted this conclusion for quite some time, but: Java on the
desktop is moribund, if not outright dying. How many Java applications
do you use other than VASSAL? For my part, the answer is ‘one’ (and it’s
one that I would happily abandon if I saw an alternative). I would bet
that for the vast majority of our users, the answer is ‘zero’. Java on
the server might be doing fine (due to a lot of distributed computing
work like Hadoop and various web frameworks), but desktop Java is a
ghetto. We have also had no end of installation issues with Java. If you
search our forum, you will find literally hundreds of questions where
VASSAL does not start because something is wrong with the user’s JRE
install.
–
J.
I’ve been pushing this a long time but the current code was never
originally built with that in mind. Sometimes starting from scratch is
the easier thing to do.
Yeah, like check out the Twilight Struggle module–the evil mess that it is.
A scripting language like Lua - yes, a true AI not nearly as important
though - the idea is to play against other people, not the computer
I actually took courses in AI in graduate school and the first thing that
occurs to me is that, if you’re worried about using one language over
another, you’re already in trouble.
That being said, we usually used Lisp (because it has built-in linked
lists).
“cianchet” wrote:
- IPAD and Android implementation
A whole set of unique challenges here I forsee due to the complete
difference in gui behavior that needs to be resolved/coexist with
traditional pc media and still work properly in both environments i.e
expanding counter stacks - dbl click mouse = double tap screen etc…?
This wont be an easy task
Which has nothing to do with whether you’re using C++ or not!
- 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’m surprised you weren’t tempted to use the C++ code in the current version
of VASSAL.
- I resisted this conclusion for quite some time, but: Java on the
desktop is moribund, if not outright dying. How many Java applications
do you use other than VASSAL? For my part, the answer is ‘one’ (and it’s
one that I would happily abandon if I saw an alternative). I would bet
that for the vast majority of our users, the answer is ‘zero’. Java on
the server might be doing fine (due to a lot of distributed computing
work like Hadoop and various web frameworks), but desktop Java is a
ghetto. We have also had no end of installation issues with Java. If you
search our forum, you will find literally hundreds of questions where
VASSAL does not start because something is wrong with the user’s JRE
install.
I’m kind of with Joel on this one. I really wanted to love Java when it
came out. I still use it for very small things, but for a project of this
size, it isn’t practical.
Thus spake cianchet:
I imagine I am the last one in the queue of people who could have
complained about this decision.Portability: people will ask to see Vassal for IPad and for Android. Ok
Java is no good for both, but is C++ better?
Yes, you can compile C++ for tablets.
In my opinion you will end supporting a windows version only, actually
reducing portability.
I do all of my development work on Linux, and I want to use VASSAL
myself. VASSAL running on Linux is my first priority. We will not end up
supporting Windows only.
Now I can play in Linux. Ok no great graphics, but I can use it.
Examples of good graphic interface in Java: gametableonline. Have you
ever seen it? It’s in Java.
Yes, and they’re doing it with Web Start, which has all its own
deployment problems. We once used Web Start for VASSAL, before 3.0, and
abandoned it due to the endless problems that people had with it.
The games I see at gametableonline.com have small maps and few pieces.
None seem to have the ability to scale the view. Yes, you can make
things look nice if you design a custom interface for each game (though
I would say that the interfaces they have look very 90s). They seem not
to be trying to do what we are trying to do.
Sound??? Do you need sound on boardgames? Do you want to hear KABOOM
when your artillery fires???
Michael’s point about sound was not that we need better sound support
from Java, but rather that the poor sound support is similar to poor
support for other things.
IMHO you should think more in terms of functionality.
What you have:
- PBEM
- Realtime play via internet
- Chat Server (to be improved)
- Website
- An enormous module library.
- API (to be improved)
- Forum
What you miss (in order of importance):
- Rules enforcement (API to be improved and/or easy scripting language
- Java is already quite good for that)
I think a procedural approch to this is misguided. I favor a model-
checking approach based on a logical language for this.
- AI (API to be improved and/or scripting language)
#1 and #2 would require VASSAL’s internals to be wholly different from
the way they are now. Getting to a point where the internals are
sufficiently disentangled for you to add rules-enforcement or AI hooks
would be more work than starting from scratch. We are planning to make
both #1 and #2 possible.
- Chat Server improvement
This is an independent thing—the game server is its own program.
- IPAD and Android implementation
We’ve been told repeatedly that Java will never run on the iPad.
If you move to C++, you will also lose the Java code which is currently
implemented in the modules.
There isn’t all that much custom code out there, actually. The fact
that Michael—who is the author of the Twilight Struggle module, which
has arguably the most complex custom code out there—is in favor of
the switch is telling.
–
J.
Thus spake Michael Kiefte:
I actually took courses in AI in graduate school and the first thing that
occurs to me is that, if you’re worried about using one language over
another, you’re already in trouble.
This why I want to provide a proper API, so that someone can (try to)
write AI in whatever language they want. I’m not holding my breath that
anyone will write any useful AI, though—most strategy games have far
larger game trees than chess and are no where near so well-studied.
–
J.
Thus spake Michael Kiefte:
- 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’m surprised you weren’t tempted to use the C++ code in the current version
of VASSAL.
Java bindings for other languages are not fun things to work with in
my experience. (I’ve worked with JNI and Jython.)
–
J.
Custom classes dont count in making messes - core engine only! Much better doing that than making Vassal do things it was never intended to do with core traits like I do
Im not in trouble (yet) - wait till the language is selected then ask me how much trouble I’m in! Funny you mention Lisp. Autolisp was the first language other than Basic I encountered many moons ago from working with autocad. Probably would be lost today since its been 18 years since I last saw any lisp code
Thats because I tend to wander OT hehe
There isn’t all that much custom code out there, actually. The fact
that Michael—who is the author of the Twilight Struggle module, which
has arguably the most complex custom code out there—is in favor of
the switch is telling.
To be fair, I want to be on the ground floor when VASSAL starts moving over
to C++ and that wouldn’t be true of the authors of most custom code—those
modules are going to be stuck with versions 3.x. Twilight Struggle started
out as a challenge to see how many rules I could enforce in a VASSAL module
with a game with fairly simple mechanics. In that module, there are a lot
of traits on the pieces that do incredibly complicated things. Then I hit a
wall and starting developing custom code. Then I just didn’t stop.
What I learned was that I should have done most of it in custom code from
the beginning and just kept the VASSAL interface. In fact, there was
something that was originally designed using basic VASSAL traits and
properties that had to get cut out because its behaviour was unpredictable
based on how the board pieces were ordered internally, so I redid it in
custom code and, ultimately, with a lot less effort. How the traits and
properties work is very opaque and you spend a lot more time figuring out
how to perform cardiac surgery with boxing gloves rather than just taking
the gloves off and doing it with your bare hands. A lot of stuff is not
documented and I was literally forced to use a debugger to figure out what
the heck some of those things were actually doing. I am now an authority
and expert on trait ordering.
The amount of effort that goes into learning how to design rules enforcement
in VASSAL using traits and properties seems to be more work than learning
how to do it in custom code. If there were a handy manual on how to do
custom code, it wouldn’t actually be that long. What would really help is
if the API were a little more accessible and a little better organised (or
with public access for that matter). There’s a lot of strange things going
on internally in VASSAL. Joel said there is almost nothing in the VASSAL
code that he agrees with and I’ve seen a lot of what he’s talking about.
I would like to point out that there are some monumentally great modules out
there. I know Tim is an author of several and he’s a regular here. I think
he relies mostly on basic traits but I’ve also spotted a bit of custom code
here and there, right Tim? There are others that I’ve played to and some
people appear to be capable of amazing feats of logic designing these
modules. VASSAL itself could be helping them a lot more and it could be a
little more module-designer friendly. Lua has been offered as a possible
scripting language. I can tell you that if there was anything in VASSAL that
looked like a scripting language, I would have written minimal custom code.
Back to the original subject, VASSAL loses absolutely nothing by moving away
from Java. Java doesn’t actually buy you that much. What is more, what
many Java calls actually do is not so obvious. In addition to staring at
VASSAL code, I’ve spent a bit of time staring at the JRE itself–a lot of
the stuff it actually does is not terribly obvious or well documented. I
fully suspect that’s going to happen with C++ libraries as well (I used to
know wxWidgets fairly well), but you shouldn’t kid yourself by saying that
Java is easier by any stretch. What is more, if you spot something bad in
Java, it won’t get fixed very quickly. My experience with something like
wxWidgets is very different.
Just a little aside from my experience with working on/with VASSAL.
Hello everybody,
I would like to thank you all for your contribution to this discussion.
I would like also to say my final word on this, even if I promise I will write some other considerations in another post.
I would like also to say that I respect your decision of coding VASSAL 4 in C++ and I am perfectly conscious that you won’t change your mind: that does not mean I will not express my opinion.
I would like to better explain my ideas about such a decision.
I understand that VASSAL needs a general rewriting and a new architecture.
We need to understand why. If the reason is: simplify bug fixing, forget it, you will always get to the point in which ‘things get too complicated’.
The only reason which is OK for re-thinking the architecture is: provide more functionalities.
So, thinking to new functionalities, I made my list (“what you miss”). The first thing you miss is “Rules enforcement coding”, which means: more sound API or scripting language. If you already work on good API, then you can already think to API which support AI (keeping the platform open to another advancement and second point of my list).
What would “Rules enforcement coding” benefit from passing to C++? Nothing. In the present situation I can already use Java as a scripting code with some good results (see twilight struggle module). It is difficult (almost not documented), but you can do it.
Another consideration. A new architecture is ‘per se’ language independent. Regarding language the dependency is on what you want to achieve with the new architecture.
Since, IMHO, the next step is “Rules enforcement”, then C++ provides no plus (plus).
The last step (“what you miss” list): other platforms support (android, Ipad,…). Don’t say that you can use C++ for them. Yes the language is the same, the code is completely different. You will end up having one branch for each new OS and for sure you will abandon the branches with less users/support. In the end, you will finish supporting only Windows. I can bet on it.
I am a Windows user. I don’t have any PC with Linux or MacOs. I don’t have the Ipad. My cell is android, but I don’t pretend to play vassal on it. I only think that playing vassal on a tablet would be great.
Many thanks for your work on Vassal.
Thus spake cianchet:
Hello everybody,
I would like to thank you all for your contribution to this discussion.
I would like also to say my final word on this, even if I promise I will
write some other considerations in another post.I would like also to say that I respect your decision of coding VASSAL 4
in C++ and I am perfectly conscious that you won’t change your mind:
that does not mean I will not express my opinion.
We’re happy to have your input.
I would like to better explain my ideas about such a decision.
I understand that VASSAL needs a general rewriting and a new
architecture.
We need to understand why. If the reason is: simplify bug fixing, forget
it, you will always get to the point in which ‘things get too
complicated’.
The only reason which is OK for re-thinking the architecture is: provide
more functionalities.
I don’t disagree with you on this point, but it’s worse that than: The
current architecture doesn’t support well things we’re already doing.
So, thinking to new functionalities, I made my list (“what you miss”).
The first thing you miss is “Rules enforcement coding”, which means:
more sound API or scripting language. If you already work on good API,
then you can already think to API which support AI (keeping the platform
open to another advancement and second point of my list).What would “Rules enforcement coding” benefit from passing to C++?
Nothing. In the present situation I can already use Java as a scripting
code with some good results (see twilight struggle module). It is
difficult (almost not documented), but you can do it.
I don’t expect that anyone would be writing rules-enforcement code (or
any custom module code) in C++. This is one of the reasons for providing
a modern scripting language, probably either Python or Lua.
Another consideration. A new architecture is ‘per se’ language
independent. Regarding language the dependency is on what you want to
achieve with the new architecture.
Since, IMHO, the next step is “Rules enforcement”, then C++ provides no
plus (plus).
Switching to C++ is orthogonal to fixing the architecture, true. But
I gave numerous independent reasons for switching to C++.
The last step (“what you miss” list): other platforms support (android,
Ipad,…). Don’t say that you can use C++ for them. Yes the language is
the same, the code is completely different. You will end up having one
branch for each new OS and for sure you will abandon the branches with
less users/support. In the end, you will finish supporting only Windows.
I can bet on it.
The GUI code might differ across platforms. The code for the internals
will not.
Supporting the platforms we already support is one of our highest
priorities, both as a group and for me personally. I need VASSAL to
work on Linux becuase I use Linux myself. I need VASSAL to work on
MacOS and Windows because I have opponents who use those OSes. Dropping
support for any of those is not acceptible. We won’t.
–
J.
I think it is worth recalling the original motivation behind the development of Java, C#, .NET etc: the perception (certainly true through the '90’s) that C++ was too sharp a knife, and most development teams were incapable of writing quality code in it due to (amongst other issues) heap management, error handling and multiple inheritance complexities. Before any code gets written in C++ can we get a broad consensus on how to manage the codebase to address these issues.
Thus spake pgeerkens:
I think it is worth recalling the original motivation behind the
development of Java, C#, .NET etc: the perception (certainly true
through the '90’s) that C++ was too sharp a knife, and most development
teams were incapable of writing quality code in it due to (amongst other
issues) heap management, error handling and multiple inheritance
complexities. Before any code gets written in C++ can we get a broad
consensus on how to manage the codebase to address these issues.
The answers I would give are:
–
J.