Roadmap for VASSAL 4

Are there any browser based games available in iPad?

I think we have already rejected JavaScript.

I think you’re right that we need a more portable solution but even Apple rejected browser apps for the iPhone years ago.

  • M.

On 2011-07-02, at 12:01 PM, jeb123 fjt_us@yahoo.com wrote:

With regards to platform direction, I’m thinking that mobile gaming is
the future. Clearly, many of the bigger game companies are betting this
way.

Being a browser based solution would be a great first step as it would
give Vassal a way to migrate their fanatical user base from PC’s to the
platform of the future as people are increasingly replacing their lap
tops with smart phones and tablets like the iPad. Mobile gaming on an
iPad or tablet would make huge sense for gamers as they would be able to
play their games any time from any place from any device and is
something that other competitors do not do. If Vassal where to make
the jump to a browser based system I think they would ensure their
relevance for years to come.


Read this topic online here:
Roadmap for VASSAL 4 - #189 by ftarzanin


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

The next version of Warplanner seems to be designed to run within a browser on even an iPad or Android. My guess is that since the current version of Warplanner is coded in C#, the next version is probably done in C# ASP.NET. A dedicated server may be needed to run this, I suppose. Since Vassal supports many more games, I wonder what kind of server is needed for such a design.

Lance

Interesting. Shame there isn’t a demo.

  • M.

On 2011-07-06, at 1:49 PM, lancel lanceleu@mindspring.com wrote:

The next version of Warplanner seems to be designed to run within a
browser on even an iPad or Android. My guess is that since the current
version of Warplanner is coded in C#, the next version is probably done
in C# ASP.NET. A dedicated server may be needed to run this, I suppose.
Since Vassal supports many more games, I wonder what kind of server is
needed for such a design.

Lance


Read this topic online here:
Roadmap for VASSAL 4 - #191 by lancel


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

Let me see if I can play with some ASP.NET stuffs here a bit for a demo. I know only some C#. It sounds like an interesting side-project to pick up something.

Lance

Probably jumping the gun too soon. It is purely my guess that it is being done in ASP.NET on the basis of their current release. Perhaps their next version is done in a totally new architecture. Until it comes out, no one knows. I will keep the ASP.NET in mind anyway to see how feasible it is to run a game like that. Perhaps the next version of Warplanner will be out by then and we will all find out.

Lance

On further thoughts, I don’t remember this topic ever mentions anything about converting Vassal modules into Java applets and / or running the converted Java applets along with Javascript. Wouldn’t it be more cost-efficient to convert them into applets if it is feasible?

Lance

Java doesn’t really have anything to do with Javascript. It would be just
as easy to convert Java in C++.

If memory serves me correctly, the original Warplanner was done in Visual
Basic. Did they do a complete reimplementation?

  • M.

On 6 July 2011 15:42, lancel lanceleu@mindspring.com wrote:

On further thoughts, I don’t remember this topic ever mentions anything
about converting Vassal modules into Java applets and / or running the
converted Java applets along with Javascript. Wouldn’t it be more
cost-efficient to convert them into applets if it is feasible?

Lance

_____________**
Read this topic online here:
vassalengine.org/**forum/vie … 0#**p23660<Roadmap for VASSAL 4 - #195 by lancel

_____________**
messages mailing list
messages@vassalengine.org
vassalengine.org/**mailman/listinfo/messageshttp://www.vassalengine.org/mailman/listinfo/messages

The original Warplanner was done in VB? I have no idea. I just so happened to look up for Empire of the Rising Sun module, which Vassal still does not have and came upon this Warplanner. I was a bit surprised that it was written in C#.

About Java applet, if it is converted from the current Java app, wouldn’t it run inside a browser too? Has the Vassal Engine ever been converted to run as a Java applet?

Lance

It wouldn’t help you running it on an iPad. iPad doesn’t support Java at
all whether it’s an applet or not.

  • M.

On 6 July 2011 21:22, lancel lanceleu@mindspring.com wrote:

The original Warplanner was done in VB? I have no idea. I just so
happened to look up for Empire of the Rising Sun module, which Vassal
still does not have and came upon this Warplanner. I was a bit
surprised that it was written in C#.

About Java applet, if it is converted from the current Java app,
wouldn’t it run inside a browser too? Has the Vassal Engine ever been
converted to run as a Java applet?

Lance

Thus spake lancel:

About Java applet, if it is converted from the current Java app,
wouldn’t it run inside a browser too? Has the Vassal Engine ever been
converted to run as a Java applet?

It would not be easy to convert VASSAL 3 to be a Java applet, and maybe
not even possible, because:

  1. It needs access to your disk. It might be possible to give an
    applet the privileges is needs for that, but I suspect it would involve
    signing the applet and so on, which would make it impossible to use
    with custom classes.

  2. You will run into problems with the heap size. I don’t know what the
    maximum heap is for Java applets, but I’ll bet it’s less than what’s
    needed for most modules, and won’t be adjustable from inside the applet.

Lastly, if you can run Java applets, it means you have Java, so you
could run the regular application.


J.

Thus spake lancel:

On further thoughts, I don’t remember this topic ever mentions anything
about converting Vassal modules into Java applets and / or running the
converted Java applets along with Javascript. Wouldn’t it be more
cost-efficient to convert them into applets if it is feasible?

The similarity between Java and JavaScript is that the former is a
substring of latter. As languages, they’re entirely distinct—Java is
strongly, statically typed and has class-based inheritance, while JS is
dynamicly, weakly typed, has first-class functions and closures, and
uses prototype-based inheritance. It’s unfortunate that JS is known by
the name that it is.

Any conversion from Java to JavaScript is going to be nontrivial (and
in the wrong direction, in my opinion, as complex codebases are harder
to maintain in dynamic, weakly typed languages).

It’s not clear to me how applets can interact with JS, as JS acts on the
DOM, as from that point of view, an applet is just an opaque XML element.
So, you’d have that problem (which there might be some solution for, I
don’t know) in addition to the other problems I mentioned with running
as an applet.


J.

Javascript can call up fields in a Java applet. I have seen that done. I just browsed the Javascript Bible and saw some simple examples there too. I was not aware though that iPad does not support Java at all until it was brought up yesterday. (I don’t have an iPad myself.)
Lance

Sorry to bump in in the middle without a clue, but are you really planning to rewrite the (core) vassal in c++?! If so, please do count me in.

Yes, I have ridiculous schedule and a pile of kids to look after but this is something I have been looking after for so long. Or even if you are just planning to rework the current engine so that it could run on Android system… count me in on that too! :slight_smile:

MVC model is a good for responsibility separation and doing at least the Model part in C++ might be a viable solution. Adding a scripting language support such as Python or Lua should not be a big issue and with JNI Java/Android interface should not be a problem either. IPad etc. on the other hand might be an issue: I really don’t know how Objective-C and C++ plays out, but I have heard rumors that it should be OK.


Rami

Thus spake rami:

Sorry to bump in in the middle without a clue, but are you really
planning to rewrite the (core) vassal in c++?!

Yes.

If so, please do count me in.

We’d like the help. We need to do a bit of design work before diving
in; criticizsm of the proposed design would be helpful at the moment.

MVC model is a good for responsibility separation and doing at least the
Model part in C++ might be a viable solution.

I already have C++ demo of the GUI View. It doesn’t handle much yet, but
it can draw pieces and a map and handles user interaction.


J.

I have been reading this thread with great interest. I can see you that you have decided to develop Vassal 4.0 in C++.

All though I love Java, I fully understand why you want to make the move to a C++ implementation, and I’m very happy to see that you are so focused on making a cross-platform implementation.

You have been looking at different libraries, such as wkWidget and boost. I would suggest that you take a look at Qt. Qt has a large range of advantages compared to most other GUI libraries. I’ll list some of them here:

  1. Qt is a complete GUI and application framework library (cross platform network, file handling, XML, threading, and so forth). Its very feature rich, and hence there is no need for other libraries like boost.
  2. The Qt GUI model is very similar to the Swing programming model, and can be learned with minimal effort by Swing developers.
  3. The Qt libraries are extremely well documented (by far the best documentation I have seen). There lots of books available on the Qt libraries, and tons of information can be found on the web. For example: http://doc.qt.nokia.com/4.7/index.html
  4. The Qt libraries are cross-platform (Windows, Mac and Linux). Qt apps can also be compiled to Android devices.
  5. The Qt rendering pipeline is based on OpenGL, and hence has very good performance.
  6. Qt has a huge developer community (250.000 plus developers) and is being actively developed. And Qt is properly one of the most used cross-platform C++ libraries out there today. See: http://www.google.com/trends?q=qt%2C+wxwidgets&ctab=0&geo=all&date=all&sort=0
  7. Qt is open source (GPL and LGPL). Backed by Nokia.
    8 ) Forms and GUI’s is easy to design with the Qt Creator (form designer). GUI’s can naturally also be created progmatically like in Swing if preferred.
  8. Very good IDE support (Qt creator witch is a complete C++ editor with form designer), or Eclipse CDT integration.
  9. There are lots a 3. party widgets available.

You can find the Qt homepage here: http://qt.nokia.com/products/

Instructional videos can be found here: http://developer.qt.nokia.com/elearning

If you want a quick overview of Qt, here is a good introductional video: http://developer.qt.nokia.com/elearning/watch/qt_programming_essentials_by_ics_part_1

I haven’t been programming in C++ for the last 10 years (mainly Java), but I would like to contribute to the Vassal 4.0 project, if possible (Vassal is somehow very dear to my heart :stuck_out_tongue:, me being a passionate board gamer ). I will need to brush up on my C++ though :stuck_out_tongue:

Anyhow, I think it is worth giving Qt a look. I think it would be a perfect fit for a new Vassal 4.0 C++ engine.

QT was already brought up earlier although I can’t say why it is no longer mentioned anymore…

Thus spake Tim M:

“bolabola” wrote:

Anyhow, I think it is worth giving Qt a look. I think it would be a
perfect fit for a new Vassal 4.0 C++ engine.

QT was already brought up earlier although I can’t say why it is no
longer mentioned anymore…

I think the reason is: We’ve been discussing high-level design issues
recently, and which GUI toolkit (or which libraries of any sort) we use
isn’t so relevant at this point.

Regarding Qt, though:

I used Qt some years ago. I found it to be quite irritating that it
had poor integration with the Standard Template Library, and the degree
to which it was generating code using its special preprocessor made
some problems a nightmare to debug. One of the things which people point
to as an advantage of Qt—namely, that it is a giant, all-encompasing
framework providing everything you might need—is also touted as an
advantage of Java, and it one of the reasons why I don’t ever want to
use Java again if I can avoid it. Using a monolithic library means that
it’s harder to swap out parts which are unsuitable or broken, and such
libraries will tend to worm their way into every part of your design. I
want to keep our dependencies on third-party libraries as confined as
possible, so that we’re free to replace them as needed.


J.

I understand your concern, but most if not all cross-platform GUI toolkits are all-encompasing. Primarily due to the sheer complexity of constructing a cross-platform C++ GUI toolkit. Other cross-platform GUI toolkits, like for example wxWidgets and Juce are also all-encompasing, as in so far as they use their own container types (like QString, QList in Qt). STL is not used in any GUI toolkit I have been able to find. The reason cross-platform GUI toolkits don’t use STL, I think, is that STL is not available on all platforms, and that STL is heavily dependent on templates, witch not all compilers handle adequately.

Qt has some support for STL in its container classes, allowing for relatively easy bridging between the container types. Using Boost with Qt shouldn’t be a problem, if this is preferred to Qt utility libraries (networking, threading, file handling and so forth).

Decoupling the toolkit libraries from the application model / architecture can be ensured to some degree by a proper design using a layer of indirection between the application model and the GUI toolkit libraries, though a complete decoupling (toolkit having no effect on the design of the application architecture), would be hard to achieve. But this would be true for any GUI toolkit.

So short of developing your own cross-platform GUI toolkit (witch of cource isn’t feasible :stuck_out_tongue:), you’ll always end up with some dependcies to the GUI toolkit. Changing the GUI toolkit once implemented, would be a huge task no matter witch toolkit is choosen. So choosing a toolkit with proper cross-platform support, proper documentation, proper design, good rendering performance, vibrant community and so forth, is in my eyes key to succes.

But I can gather from the previous post, that you at the current stage primarily are looking at the model design and module file format, and haven’t really decided on a GUI toolkit yet. I just wanted to make sure that you where aware of the Qt toolkit.

By the way, I love your C++ test demo. Clearly out performs the current Java rendering performance :smiley:

Bo

QT was already brought up earlier although I can’t say why it is no
longer mentioned anymore…

I think the main reason was the preprocessor.

  • M.

Interesting thread. I’ll talk about converting to c++ in next message, just want to say that we seem to be losing track of the most important priority for most of Vassal Users:

Number 1: Vassal 4.0 should run all of the 992 existing modules without a hitch (Well, ideally - in practice at least 99% of them).

If the planned rewrite doesn’t do this then it’s not Vassal 4.0 but NewVassal 1.0, a system with few modules and even fewer users and of very little interest to our customers - the Vassal users.

uckelman wrote:

Editing and Designing may be difficult but that would be made easier by properly documenting the piece traits (with an advanced section of the very clever things people have done with them) rather than producing a new set of advanced traits which work differently (hence existing module designers must start from scratch) and won’t be documented (because the Authors think they’re too easy to need it, hate doing it - like all of us and it’s left for later = never)

The game server is a problem but probably 90% of Vassal users use it for pbem so aren’t worried. If any client can be a server then there is no need for a central server anyway.

The interface may be clunky and dated but it works and most Vassal players know how to use it and will probably scream very loudly if it changes in a new version. It’s easy to update the software but much harder to update the users :smiley:

The codebase does need fixing. But we don’t need to jump into a different language etc to do it. Just slog away rewriting it.

Just to reiterate the main point: you don’t have a blank sheet of paper on which to design the perfect game system. You’ve got the legacy of the current system and lots of users to satisfy. Your options are limited.