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.
