Just jumping in, I sort of skimmed from around page 14(?).
For the front end, is the plan to use OpenGL directly vs. some cross-platform library, maybe wxWidgets for example? I saw earlier discussions about Qt as a possibility. Kivy seems to be a wonderful thing for cross platform purposes, but also probably out of scope for what you’re aiming at.
73,
Timothy
Thus spake RunningOpenLoop:
Just jumping in, I sort of skimmed from around page 14(?).
For the front end, is the plan to use OpenGL directly vs. some
cross-platform library, maybe wxWidgets for example? I saw earlier
discussions about Qt as a possibility. Kivy seems to be a wonderful
thing for cross platform purposes, but also probably out of scope for
what you’re aiming at.
I wrote a little OpenGL demo for this in 2013; I figured we’d use
OpenGL directly unless there was some really compelling reason to take
on another dependency.
–
J.
So the idea is to have OpenGL ES so tablets can use VASSAL? I think I saw something about hoping to address that with VASSAL 4. Are you considering to make a multi device presentation system which would be able to dock/send windows to tablets/phones so you could have, say your card hand on your tablet and the map on the computer screen? Or is that out of scope for the roadmap.
73,
Timothy
Hello -
I didn’t read the entire thread, and since I have no programming experience since learning some rudimentary BASIC in 1979 I wouldn’t have understood it anyway.
But I am a Mac user and did note some of the challenges you mentioned a few years ago with cross compiling to a Mac, not the least of which was having neither a Mac nor a Mac programmer on the project.
I can’t get you a Mac programmer, but I would be happy to loan you my Mac via SSH if that would help in anyway.
Also, at the risk of embarrassing myself, is Swift (https://swift.org) an option for development of Vassal V4?
Thus spake RunningOpenLoop:
So the idea is to have OpenGL ES so tablets can use VASSAL? I think I
saw something about hoping to address that with VASSAL 4.
Yes. The amount of OpenGL we’ll need is not very large, given that
we’ll be using it only for fast 2D.
Are you considering to make a multi device presentation system which
would be able to dock/send windows to tablets/phones so you could have,
say your card hand on your tablet and the map on the computer screen?
Or is that out of scope for the roadmap.
It’s not a thing I’d thought of previous to this.
–
J.
Thus spake PaulMcG:
Hello -
I didn’t read the entire thread, and since I have no programming
experience since learning some rudimentary BASIC in 1979 I wouldn’t have
understood it anyway.But I am a Mac user and did note some of the challenges you mentioned a
few years ago with cross compiling to a Mac, not the least of which was
having neither a Mac nor a Mac programmer on the project.I can’t get you a Mac programmer, but I would be happy to loan you my
Mac via SSH if that would help in anyway.
Thanks. Sorting out cross-compilation is one of the things we’ll be
doing towards the beginning of the development process.
Also, at the risk of embarrassing myself, is Swift (swift.org)
an option for development of Vassal V4?
No. There’s no way I’m using a language controlled by a single
corporation. We’ve already seen how miserable that’s been with Java.
–
J.
Hi
I would like to help with VASSAL project too.
How can I help?
I too would be interested in helping out. I apologize if this is redundant, I haven’t read through the whole thread, but another language choice could be python. It’s a little higher level than C++ and it can run C/C++ libraries. Although slower, there is a lot of work put into speeding it up to within a couple multiples of native speed. Plus there is a group that is working on wrapping openGL in python for some really impressive graphical abilities. If you’re interested, check it out: youtube.com/watch?v=_3YoaeoiIFI .
Thus spake ricardojm:
Hi
I would like to help with VASSAL project too.
How can I help?
Watch this space. Once I’ve completed my current project—renovating
a house and moving into it—I’ll get us rolling again and will be
putting my full attention into V4. It won’t be long before there will
be lots of opportunities to contribute.
–
J.
Thus spake phumke:
I too would be interested in helping out. I apologize if this is
redundant, I haven’t read through the whole thread, but another language
choice could be python. It’s a little higher level than C++ and it can
run C/C++ libraries. Although slower, there is a lot of work put into
speeding it up to within a couple multiples of native speed. Plus there
is a group that is working on wrapping openGL in python for some really
impressive graphical abilities. If you’re interested, check it out:
youtube.com/watch?v=_3YoaeoiIFI[1] .
I have some reasons for not using Python:
It introduces additional ways for a program to fail. My experience
with relying on the JVM for VASSAL and Python for various work projects
has been that many, many of the problems users report are due to the
environment not being set up right.
Cross-compiling Python and it’s modules is a pain, and we’d like to
target tablets.
The more I use Python, the more frustrating I find the lack of static
typing.
–
J.
Really C++ … what is wrong with Python ontop of that?
Thus spake Dabrion:
Really C++ … what is wrong with Python ontop of that?
Using Python for scripting makes it very hard to have a web client, as
then you need a Python interpreter in your browser. It’s not impossible
to provide that via emscripten, e.g., but then you’re heading toward
everything being a huge contraption.
There is no effective way to sandbox Python when running natively.
–
J.
I’ll try to be difficult, take it with a grain of salt please 
Also, maybe some points to think about while renovating the house!
Is there a documentation page for VASSAL 4 where I can have a look at the current plan? I read the introductory post of this thread, is there more? Also, I’d be interested in documentation regarding the concepts in use today (coordinate system, token etc), does this exist? I think the concepts are really well thought out, it would be cool to preserve that.
Still following the client-server plan? Is there an API spec up yet? It’s stateful, right - any thoughts spend on the persistence layer yet?
C++ for the server is fine - as long as I don’t have to work on it. What were the reasons to use a less than popular language when you could use something better suited to the problem, i.e. something functional as this is basically a service? Clojure comes to mind. One of the big problems of VASSAL today is all these system level concerns in the codebase. Suddenly we have to worry about memory allocation as well, that does not strike me as good. Functional would be best in a request-response scenario and is also excellent to write tests for.
Possible to separate concerns? Can we have a module version service and a game service separate from each other? Also, I’d like to authenticate via OAuth. I need micro-services to be happy
Can we design it cloud-native, i.e. inherently scalable and resilient? I think it would be a good idea to allow people to run their own servers, i.e. for tournaments.
If this is done right, i can see a bright future, with clients hitting the app stores in no time at all…
Just jumping the train here…
I agree with the overall analysis of #danieltakai ! There is no need to use a low level language. I only deal in C++ for real time and/or hardware abstraction layers, where the trade off of using a low level language is (quantifiably) positive. When it comes to day to day work, I’d rather use a language that is accessible, facilitates rapid development cycles and is interactive.
We do not have realtime issues or hardware abstraction layers to cope with, that would make this kind of ordnance necessary per se.
The limiting factor of vassal in its 3.x incarnation is 1) java and its implications (write 50 sloc for an interface your don’t even use) for module design beyond the stock components, 2) the way traits are implemented (as decorators) and 3) no separation of concerns for rendering (front end) and manipulation of game state (automation, autonomous agents, AI). I would love to use vassal for my reinforcement learning and AI stuff… it is just not worth the time in its current state.
I would think that the module design could be completely handled on a properties+configuration+resources level. The barriers here should be really low and focus on getting things done with a predefined, finite set of tools. The current version is a proof that this concept is very successful and well received!
C++ for the server is maybe fine, but a tough choice strategically. As I already mentioned, this is not a native domain for a low level language. Another thing to consider is: for someone to get into C++ just to help out with his pet project, I will predict a 5% chance this leads to productive contributions. The trade off here is probably negative, and that deficit will be the burden of the core developer(s) (/wave Joel, prolly no news told here). That said, if this choice is one to make you (Joel) more comfortable, assuming you will lift most of the weight, I can understand that.
Perhaps there is a middle way, some sort of agreeable JIT-LLVM … no idea …
CLOUD: there is no cloud… there is only other people computers. For applications of this kind, state is entirely handle client site, with state-transitions communicated piggy-back a slim message protocol (XMPP atm if I am not mistaken). As such nothing really has to scale on magnitudes that need consideration or could be sensibly distributed.
There is a possibility to setup your own server already (to host your own tournament … but why would you do that?).
Another thing that I like to highlight for V4 is cross-platform accessibility for players and developers. This is kind of a nightmare atm. It would also be sensible to care for mobile devices and I’d think that parting with the stylish, 90esque Swing gui’s will open that door automatically. Any current front end framework will be mobile ready.
Take all of this with a grain of salt, I only lurk these channels and my knowledge of the V3 code base is lacking at best
Thus spake danieltakai via messages:
Is there a documentation page for VASSAL 4 where I can have a look at
the current plan?
Not publicly available, no. The last two times I was working on this,
I was interrupted, first by moving to England, and then by buying a
house. I don’t want to publish anything before it and I am ready. I
don’t want to be in the position of discussing a document I do not feel
is ready, as that’s a waste of people’s time, nor do I want to do it at
a time when I lack the availability to have that discussion properly.
I read the introductory post of this thread, is there
more?
Yes, I’ve written a spec, but see above for why it’s not public yet.
Also, I’d be interested in documentation regarding the concepts in
use today (coordinate system, token etc), does this exist?
No. The lack of documentation for how anything in 3.x (or earlier) was
intended to work was one of the things which made me start thinking
about V4. The best we can do with 3.x is look at the code and with
great effort, describe how things actually work—which is often
inconsistent and the product of cobbling over many years, not considered
design.
I think the concepts are really well thought out, it would be cool to
preserve that.
If by concepts, you mean things like piece, map, board, etc., then at
a very general level, I agree—but those are all taken directly from
tabletop games. When you get more fine-grained than that, I would go
more in the direction of “amazing that anything works at this point”
than “well thought out”.
Still following the client-server plan? Is there an API spec up yet?
It’s stateful, right - any thoughts spend on the persistence layer yet?C++ for the server is fine - as long as I don’t have to work on it. What
were the reasons to use a less than popular language when you could use
something better suited to the problem, i.e. something functional as
this is basically a service?
I don’t have any reasons for using a less than popular language when I
could use something better suited to the problem, as I don’t intend to
do that. 
We clearly don’t have the same view of C++. C++ is a popular language
well-suited to the problem.
In any case, one advantage of defining a specification is that it can
be multiply implemented and tested against. I want to write the
reference implementation in C++, but anyone else would be free to
write their own in their language of choice and test its behavior
against the spec.
Clojure comes to mind. One of the big
problems of VASSAL today is all these system level concerns in the
codebase. Suddenly we have to worry about memory allocation as well,
that does not strike me as good. Functional would be best in a
request-response scenario and is also excellent to write tests for.
Perhaps you have not used C++11 (or C++14)? I don’t find myself
worrying much about memory allocation these days, except in some
specialized optimization-intensive circumstances.
Possible to separate concerns? Can we have a module version service and
a game service separate from each other? Also, I’d like to authenticate
via OAuth. I need micro-services to be happy
What would a “module version service” be?
Can we design it cloud-native, i.e. inherently scalable and resilient? I
think it would be a good idea to allow people to run their own servers,
i.e. for tournaments.
Part of my plan is for most game servers to be run locally to one of the
players, with the central one used only when that’s not possible.
–
J.
Thus spake Dabrion:
Just jumping the train here…
I agree with the overall analysis of #danieltakai ! There is no need to
use a low level language. I only deal in C++ for real time and/or
hardware abstraction layers, where the trade off of using a low level
language is (quantifiably) positive. When it comes to day to day work,
I’d rather use a language that is accessible, facilitates rapid
development cycles and is interactive.
We do not have realtime issues or hardware abstraction layers to cope
with, that would make this kind of ordnance necessary per se.
I don’t see C++ as mainly a low-level language. Nor does Stroustrup:
stroustrup.com/bs_faq.html#true
I find C++ accessible and able to support rapid development cycles.
The limiting factor of vassal in its 3.x incarnation is 1) java and its
implications (write 50 sloc for an interface your don’t even use) for
module design beyond the stock components, 2) the way traits are
implemented (as decorators) and 3) no separation of concerns for
rendering (front end) and manipulation of game state (automation,
autonomous agents, AI). I would love to use vassal for my reinforcement
learning and AI stuff… it is just not worth the time in its current
state.
Concur. These are all things I intend for us to rectify.
I would think that the module design could be completely handled on a
properties+configuration+resources level. The barriers here should be
really low and focus on getting things done with a predefined, finite
set of tools. The current version is a proof that this concept is very
successful and well received!
Yes, this is what I’m aiming for.
C++ for the server is maybe fine, but a tough choice strategically. As I
already mentioned, this is not a native domain for a low level language.
This is why I don’t intend to use a low-level language. But we
don’t agree on whether C++ is a low-level language, see above.
Another thing to consider is: for someone to get into C++ just to help
out with his pet project, I will predict a 5% chance this leads to
productive contributions.
We’ve had more people volunteer to help since I announced my intention
to use C++ than we’ve had in years volunteer to help with Java.
Will people learn C++ just to contribute? Maybe not. But that’s true
for any language. In the entire time I’ve been working on open-source
projects, the only person I could name who could say “I learned langague
X because your project uses it and I want to contribute” is me. (I
learned Java to work on VASSAL.) I have met many, many people who said
“I want to contribute to your project and already know language X.”
C++ is a very widely known and used language. The TIOBE index (which
you should take with a grain of salt, but still…) has C++ as the third
most widely used language for March 2016. This is behind C and Java.
The trade off here is probably negative, and
that deficit will be the burden of the core developer(s) (/wave Joel,
prolly no news told here). That said, if this choice is one to make you
(Joel) more comfortable, assuming you will lift most of the weight, I
can understand that.
Given the above, I suspect that we’ll draw more contributers using C++
than any alternative, not fewer.
CLOUD: there is no cloud… there is only other people computers. For
applications of this kind, state is entirely handle client site, with
state-transitions communicated piggy-back a slim message protocol (XMPP
atm if I am not mistaken). As such nothing really has to scale on
magnitudes that need consideration or could be sensibly distributed.
There is a possibility to setup your own server already (to host your
own tournament … but why would you do that?).
Concur w/r/t the cloud. One of my reasons for wanting people to be able
to run their own servers is to eliminate ours as a single point of
failure.
–
J.
Hi guys,
what is the status for V4 atm? Would love to read through a client spec
Cheers,
Phil
Thus spake Dabrion:
Hi guys,
what is the status for V4 atm? Would love to read through a client spec
I’m very delayted in working on this at present, due to continuing
renovations on the house I bought 18 months ago. Once that’s over,
V4 is at the top of my list.
–
J.
Ok, thanks for the update!
p.s.: you must be living in a huge palace
Ahh, good. Looks like I didn’t miss anything since last year.
Not that life will end up with me contributing, but I think C++ is good. I love python for getting things done in, but I fear in a big project/project with many people… static typing/etc is a good thing. But I an curious, are there any studies/papers to suggest otherwise? I.e. that python is good for large projects?
As I recall, Open GL ES was planned for the video. I notice back in 2011 there was some talk about SDL. I do wonder if SDL2 should be considered as a layer to OpenGL / OpenGL ES? This is still portable with respect to computer or mobile devices. I’d been planning on doing a project with the Rasberry PI and to use OpenGL ES, but I think SDL2 should save me some time / and be portable to boot.
I’ve been thinking more and more about making a multi-point coffee-table live screen, I’ve noticed from Instructables this trend too. So back to the idea of phone to view cards / multi-point screen for board.
73,
Timothy
