Oh… ok. I actually used to teach C++ once… but that was way before all this fancy C++0x stuff.
Are there any policies about letting VASSAL be able to know more about the game rules? (or not doing it)?
Like… making it possible to calculate movement and show movement options in the GUI?
I realize that would probably require complex features for module writing to use.
Thus spake apm:
“uckelman” wrote:
That’s ok, as we’re not using Java for V4. It’s going to be in C++.
Oh… ok. I actually used to teach C++ once… but that was way before
all this fancy C++0x stuff.
C++11 is a massive improvment over C++03. I’d like to write code for the
C++14 standard if we can, as it fixes a few warts from C++11 (such as:
being unable to move objects into lambdas).
Are there any policies about letting VASSAL be able to know more about
the game rules? (or not doing it)?
My plan is for modules to have access to game objects via JavaScript,
so if one wanted to code up game rules procedurally, one could do so
much more directly than is possible now.
Eventually, I’d like to have a rules representation language for
encoding rules declaratively, which could then be used to enforce rules
via model checking—but that’s not something I want to taclke now, as
it’s very much a research problem, not a software engineering problem.
–
J.
Hmm… I imagined having game modules being able to verify moves or other steps in the Sequence of Play via git commit hooks.
Of course… this is all brainstorming. You are right that git provides a lot heavier history control than is probably required.
Is this something that the layman non programmer is going ot be able to use to build modules?
If not who an dhow will modules be built by end users /buyers and game publishers?
Thus spake hipshot:
Is this something that the layman non programmer is going ot be able to
use to build modules?
It depends on what the “this” is you’re referring to.
If you mean the JavaScript interface, then no—you’d need to have a
minimal understanding of programming to write scripts using it.
If you mean the rules description language I mentioned, I’d say no as
well—I doubt there’s any simple solution in that space because rules
for even the simplest games define very complicated theories.
If you mean module creation generally, I expect it to be simpler than it
is in V3.2, and lots of modules (most?) have been created by
non-programmers.
If “this” is something else, please clarify for me.
–
J.
More brainstorm … 
Wouldn’t it be awsome if VASSAL ended up being naturally usable on devices like this:
http://www.u-touch.co.uk/touch-table/
So … If you could achieve a “touch” experience on the table feeling like the actual board game you could play the same (monster)game in several sittings where some of them were face-to-face and some were over the Internet. - but not having to transfer everything back and forth (which nobody would want to do).
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