OK Ladies and Gentlemen.
You may, or may not as the case may be, want me to be involved in the development of Vassal V4.
She who must be obeyed asked ‘are you sure you want to do this?’
I replied ‘Probably not, but I feel I can contribute and I do have very good, inter alia, project management experience’.
So. Where to now?
Do you have a PERT/CPM road map?
Do you know the critical path?
Does the PERT identify each (and I mean each) software code block that needs to be developed?
Does each software code block has every associated linkage to other block identified?
Do you use karnaugh mapping to reduce logic flows and the like?
We need a comprehensive software/block testing regime, when test stages are to be done are a part of the PERT chart. Obviously each block cannot be tested until the whole reaches a certain level.
We need to assign who does what. Not worried about timelines as everybody has a life to live.
My first thoughts. I do not know what each individual developer is capable of. From what I have read in this forum, Joel is one who understands the need to have an extensive testing regime. I’m sure other guys (guys being asexual here) are also extremely competent, as evinced by the way 3.6.x has been coming along since 3.1.17 sat there for a decade or more.
An overall aim should be that the currently available V3.6.x module developer documentation (and user documentation) should be retained for V4.x. I fully expect some changes to this documentation as you/we develop V4 and way better methods of implementing what V3.6.x does now. (thinking GPs as a single ‘property sheet’, ‘array’).
Enough for now.
Let the creative juices flow.
BTW, we will also need a team of alpha/beta testers. Additional people with programming expertise, in whatever language idiom V4 is going to/is using. People who are really committed to help out, in any way. For those with limited or no programming expertise/experience, this will probably involve activity within the documentation sphere, inter alia.
Project management is largely fantasy in the software world—telling yourself or your boss how long something will take when if you were honest you’d admit neither you nor anyone else does or can because what you’re doing is novel. I have over the years scrupulously avoided giving anyone time estimates for things which were not already substantially complete, because there is no upside to guessing right and significant downside to guessing wrong. I’m happy to indicate what’s next. Order is somewhat predictable; duration hardly at all.
At present, I’m experimenting with some of the available technologies so that we don’t design something unimplementable or awkward. If you want to see the series of design documents I’m producing, they’re here:
I’m mulling the next one, the Game Server, presently.
I’m expecting that everything will have unit tests. It’s the only way to ensure that components work as specified and that you’re not breaking them as they change over time. Unit tests can and should be written immediately—even before writing the code they test, if you’re doing Test Driven Development.
I’m also expecting to have acceptance tests as appropriate. In our case, that sort of thing will tend to look like processing a large input to a large output and verifying that the output is as expected (think, e.g.: opening and saving a module, applying a log to a game state).
I’m aware of Karnaugh mapping—it has some relationship with finding minimal adequate sets of connectives for propositional logic systems. It sounds like it could come up in circuit-based complexity classes, though I didn’t encounter it there myself. I’m not clear on what the relevance is for Vassal.
I doubt that any of the V3 documentation will be reusable for V4.
I presume you mean 3.2.17 here, as the last 3.1 release was 3.1.20. It was only three and a third years between 3.2.17 and 3.3.0-beta1, not more than a decade.
Did I not state that ‘time’ is immaterial?
When I was managing projects I learnt many lessons.
- Whatever educated guess you come up for for the duration of a segment, multiply by 10.
- Whatever you guess are the resources required to achieve 1, divide by 10.
- After all the real world intervenes and says, screw that, multiply 1 by 10 again and divide by 10 again for 2.
- If the ‘powers that be’ do provide the resources, you are given people that have no idea about what you are working toward and possess no qualifications that can actually help.
The rest of the project is attempting to train these OTs into something you can actually do something with.
Are we on the same page here?
I was talking about the Module developer documentation.
Are you talking about the same thing or about the documentation required to support the V4 backend?
You would have to be shortsighted to not consider that what the module developer sees, as he/she develops or modifies their module(s), remains pretty much the same. Thus limiting the work required for the USER documentation. By all means develop a way better Vassal backend, but always keep in mind the user GUI and what they are accustomed to for their modules.
Yes, indeed, there will be necessary changes, but surely this can be minimised.
Why overly complicate matters for the user?
Vassal V4 biggest problem will be porting all those modules to the new environment. Some/many/few, whatever, are probably still at the 3.1.x level.
Vassal languished for many years. There were some iterations, none documented.
I do not know for sure, but I suspect that it was you guys who reinvigorated Vassal and its progressive enhancement over the last several years. Great job BTW.
So negative. I also suffer from that affliction.
V4 is a great chance to reach out and do great change.
Module developers however would:
- Like to see most of what they are used to seeing remain. That the actual back end for this GUI has changed considerably does not matter to them.
- Want an easy and, explicit here, error free means to port their modules across to V4.
- (perhaps my want here) Be able to use numbers that are not constrained as integers. One can always use (int) to truncate as required. Even, perhaps, to get away from those workarounds and have the ability to do directly what they want to achieve. Vassal should not be a limiter, it needs to be an enabler.
So endith my recitals. I’ll leave everything to you guys from henceforth.
Now I’ll badger about 3.6.7 enhancements 
And that’s all. My supposed active involvement died.
You must be related to Billy Connolly
Cheeky bugger
I have used this on numerous occasions when developing nested ‘ifs’ to decide what value to assign. Even using the x?a:b notation still takes a hit on performance when nested to many levels. So minimisation is vital.
I mentioned this as there are times when one needs to decide between a number of variables and potential outcomes. These also arise with programming.
So, you are saying that the use of ‘Karnaugh mapping’ is irrelevant to Vassal V4?
I say, how do you know that?
Bye. Forever more. Seems I must type in at least 20 characters. How quaint. I suppose it stops forum users from just typing @#$% it.
Oh I’ll still be hassling to make changes to ver 3.6x
Basically, yes. Not just to V4, but to programming generally. IIRC, the Quine-McCluskey algorithm tends to be used for reducing boolean expressions—but it’s also the case that people seldom write expressions which require reducing or even have enough terms to be reduced. Conditions with even four terms are fairly unusual in application programming, and evaluation of boolean expressions is practically never a bottleneck.
I’d like to see an example of where you think it would be useful.
I spent some of Autumn 2021 writing a program to dump V3 modules to JSON. Getting the data to a human-readable format is half of the conversion job done; the other half we can’t start yet, without a spec for the format to convert the extracted data to.
The best analogy for project management of software development is herding cats. 
Dogs have owners, cats have staff…
Given that Vassal is a volunteer effort, a lot of the project management stuff (resource/budget management) isn’t relevant.
Our biggest risk (IMPHO) is we lose one of our key developers.
BTW - I’m happy to help w/ beta testing and possible documentation updates, but I don’t know Javascript.
Herding cats is easy, compared to this project.
But let us get something straight here.
I never imposed or even suggested a time line, nor deadlines, not anything relating to ‘timeliness’.
I proposed a systematic approach that addressed the potential solution(s), in an appropriate sequence/order. That it also needs to be adaptive to cater for changing circumstances is vital.
My aim was, that all the various ‘parts’ are identified, listed and documented. Not all will follow a straight line path. In fact I’d be surprised if they followed any sort of linear path.
Why do I bother?
Paladin - chill out bro… Don’t read nastiness or trolling into my post, because it wasn’t intended. I’m sure the developers are happy to have help… Like you, I’ve been in the business for a long time and seen all kinds of permutations of project management and software development projects… Some really good and not bad, but not a great fit for the given project team.
I think it’s great to have people volunteer, but remember that not every team sees (or has) the need for certain types of formalism… One of the best software developers I ever worked with viewed project management as anathema. I eventually found that instead of trying to formally manage him, simply describing the use cases & story points and having regular (not daily - brr!) tag-ups was the best approach to maximizing productivity…
I do not know when or where Karnaugh mapping or Quine-McCluskey algorithm would be useful. I raised it more as a possible candidate for when a situation does arise. Both achieve the desired end result. I referenced Karnaugh mapping because that was what I learned to use way in the 1970’s. I’m comfortable with its use.
You are also quite comfortable with the Quine McCluskey algorithm. That is what you learned to use.
Whatever process is to be used, whenever or if ever, a situation does arise I am perfectly happy knowing that you already know of a tested and proven regime to resolve it.
No, that’s not what I said. I don’t use Quine-McCluskey myself when programming; I’ve never heard of anyone using it while programming, in fact—only as something that’s applied to data in things like SAT solvers and by compilers for reducing complex boolean expressions, where the expressions are the data.
You said this:
It sounds like you were using Karnaugh mapping directly. I would like to understand the details of this, please. I’ll wait for that before replying further.
Hi.
I’m going out of lurker mode.
I’m willing to help on the V4 development effort. And I’m willing because I’m a VASSAL user, I enjoy using it and and will love to see it improve. I’m really excited on all the new ideas I have been reading recently.
But we all must be realistic. This is not a company, there’s no money at stacks, no saliries, no promotions to fight for.This will only happen if enough people wants to participate and support the effort.
Please don’t try to look at his issue as a very strict planned thing. Just make a good definition of what we want to achieve and then give it time to happen. Please create a healthy and enjoyable environment where people feel s comfortable collaborating.
If the VASSAL community becomes something similar to the kind of stuff I must handle and my regular work, I don’t think I will participate.
My conclusion: Please, let’s move forward. Let’s define what you want yo have done with VASSAL V4 and let’s do it.
Now, I will go again to my regular lurker mode.
Thanks for all the effort.
Javor