“Highly reliable, it worked on all the equipment students brought into the classes”
… what does Vassal run on again, that one single thing that is needed to get the exact same “binary” (=bytecode) to run on any Windows, any Mac, any Linux distro, without having to install any DotNet framework updates, Gtk libraries, long list of apt-get arguments and whatnot? What is that one thing that will ensure that even the Vassal releases from years ago will run out of the box on computer hardware that isn’t even invented today? Are you still sure you want to go down the C++ way, after this article?
My other favorite is “Normally only one player can join a specific role. However, if everyone who is going to join that role does so simultaneously, you can pack many players into one role, permitting a small team of students to play the same side while maintaining fog of war. Note that this feature is not officially supported.” - the classical “It’s a feature, not a bug” situation.
That is not due to Java, but in spite of Java. It is solely a result of mammoth efforts by Joel and a slew of OS specific code and Java bug workarounds.
And C++ will not add workarounds for different cpu architectures, compilers and compiler versions on top of that? All those #if defined _MSC_VER i386x86_64 __MINGW64_VERSION_MAJOR and __MINGW64_VERSION_MINOR checks?
Not to mention how much fun it is writing guides for possible contributors to C++ projects, how to setup the development environment and get all dependencies on linux, windows and mac.
I’m not arguing that there aren’t challenges to either approach, but can we please stop the incessant sniping and pretense that Java is perfect and will solve all problems.
A good reason to use C++ is that it works well together with Lua. C++ and Lua can communicate easily.
I guess C++ was (is) regarded as a more “primitive” language than Java because of its pointers. You may argue that C++ is more error-prone due to the pointers, i.e. less strict with type-checking. I am not sure if this is true.
Java is convenient to use. I have nothing against Java. Java has a large knowledge-base and good tools (just look at Android Studio). But in the end the language does not matter, only the skills of the programmer-team matters.
It’s possible to make a mess with every language. Just look at Vassal …
“Highly reliable, it worked on all the equipment students brought into
the classes”
That is not due to Java, but in spite of Java. It is solely a result of
mammoth efforts by Joel and a slew of OS specific code and Java bug
workarounds.
This. We put in a huge bug-fix and release engineering effort from
about 2006 to 2014.
And C++ will not add workarounds for different cpu architectures,
compilers and compiler versions on top of that? All those #if defined
_MSC_VER i386x86_64 __MINGW64_VERSION_MAJOR and
__MINGW64_VERSION_MINOR checks?
I work on numerous C++ projects in my day job, which get built for several
different OSes and architectures. There’s very little of that, even for
things where you might expect it. (E.g., just yesterday I was setting up
autodetection of SIMD instruction sets for something and there wasn’t a
single #define involved in that.)
If you want to see a project containing a lot of preprocessor macros,
have a look at… wait for it… the HotSpot JVM:
Well the Hotspot JVM is not part of Java, its just one of the possible implementations of the JLS.
And some of this mammoth effort was spent doing terrible design decisions and having to deal with previously made terrible design decisions, like the JVM fork or supporting this menu on Mac which is separated from the application window.
But no worries you’ve all done a great job, I’m just trying to lure you back to proper Vassal 3 development, besides they wouldn’t have picked Vassal as their tool of choice at this US army thing if it wasn’t good. Just where is that DoD contract now with the multimillion budget
I say great we don’t have that. No dead-lines, no economic concerns, no irate customers, no worries. Here we have all the time and can therefore do it right. Let’s use this opportunity.
Before making decisions on language, it is better to focus on the design itself, settle fundamental design decisions like:
In what way do we want Vassal 4 to be customizable? Should we aim at avoiding compiled custom classes?
Do we want to run Vassal 4 on MSW, Linux, Mac, Android and iOS? It is wise to try to run Vassal 4 on all at once?
Do we or do we do not want to be able to run Vassal 3 modules on Vassal 4? Do we or do we not want a total rewrite?
How do we make a strict separation between game state (game model) and it’s visual representation? It is easier to handle functionality (like UNDO) if there is a strict separation.
… and so on
I am now trying to find out if we can use qtLua. It is still very much on open question. I will work on this in the weeks to come … blah blah … no time … blah blah … other things to do …
When this is done, I hope a few fundamental design questions can be answered. This is design by prototyping, by finding out what works and what does not work. I am not a great believer in large, abstract designs.
Regarding C++, the Unreal Game Engine was released as open source about a year ago. I downloaded it and compiled it. It took about 4 hours. The number of warnings could be counted with the fingers on both hands. If you want to study good C++ code, go here. They have a manual on developer conventions that all who work with the code must follow, and the code is beautiful. It has to be beautiful or else it wouldn’t work.
I really REALLY hope this will be a cornerstone of the next Vassal. How exactly, does not matter all that much, MVC MVP whatever MV* pattern you use, the main point is that there is a model that has no graphical output and can be used programatically. 1st step maybe write a command-line GUI for the model, 2nd step, pretty desktop GUI, 3rd step, port to various devices with different GUI toolkits.
Overall, yes design comes first, and the strategic goals, the targeted systems etc. Choice of language, second. A good developer can build good software out of anything, like that one guy who built a 4-bit CPU out of wood.
