Create account / Log in

Roadmap for VASSAL 4

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: Roadmap for VASSAL 4

Postby Dabrion » March 3rd, 2016, 4:59 pm

Really C++ ... what is wrong with Python ontop of that?
User avatar
Dabrion
 
Posts: 9
Joined: August 29th, 2011, 9:27 pm
Location: Berlin, DE

Re: Roadmap for VASSAL 4

Postby uckelman » March 3rd, 2016, 5:27 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 8849
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby danieltakai » March 9th, 2016, 8:13 pm

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...
danieltakai
 
Posts: 1
Joined: August 17th, 2013, 11:15 am

Re: Roadmap for VASSAL 4

Postby Dabrion » March 9th, 2016, 10:30 pm

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 ;)
User avatar
Dabrion
 
Posts: 9
Joined: August 29th, 2011, 9:27 pm
Location: Berlin, DE

Re: Roadmap for VASSAL 4

Postby uckelman » March 10th, 2016, 3:43 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 8849
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby uckelman » March 10th, 2016, 4:09 pm

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:

http://www.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.
User avatar
uckelman
Site Admin
 
Posts: 8849
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby Dabrion » December 5th, 2016, 9:28 am

Hi guys,

what is the status for V4 atm? Would love to read through a client spec ;)


Cheers,
Phil
User avatar
Dabrion
 
Posts: 9
Joined: August 29th, 2011, 9:27 pm
Location: Berlin, DE

Re: Roadmap for VASSAL 4

Postby uckelman » December 5th, 2016, 11:06 am

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.
User avatar
uckelman
Site Admin
 
Posts: 8849
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Roadmap for VASSAL 4

Postby Dabrion » December 5th, 2016, 1:08 pm

Ok, thanks for the update!

p.s.: you must be living in a huge palace ;)
User avatar
Dabrion
 
Posts: 9
Joined: August 29th, 2011, 9:27 pm
Location: Berlin, DE

Re: Roadmap for VASSAL 4

Postby RunningOpenLoop » January 19th, 2017, 7:17 am

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.
- https://wiki.libsdl.org/
- https://icculus.org/SteamDevDays/SteamDevDays2014-SDL2.pdf

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
RunningOpenLoop
 
Posts: 3
Joined: January 25th, 2016, 7:04 am

Previous

Return to Developers

Who is online

Users browsing this forum: No registered users and 5 guests