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.