And why can’t a player open the editor to create a simple scenario? What’s stopping them?
The current V3 paradigm where you can Edit the module while playing a game of the module at the same time has numerous problems.
Quite apart from the strange interactions that occur when you modify the module in the middle of a game, it bloats out the entire eco-system. The Player cannot be truly separate, and cannot be streamlined, it has to have the full editor tagging along written in exactly the same technology, in case someone decides they want to edit the module.
My feeling is that while the V4 editor may have some player capabilities to visualize different aspects during editing, it probably won’t have a fully featured in-built player as we do now.
Quantum Barriers…
There is a (correct) perception that modifying the guts of a module is significantly harder than simply playing using a module. This in turn, will prevent a lot of people from even trying…
Given that V3 allows creation of simple scenarios without having to use the editor, IMHO V4 should have the same paradigm.
3 Likes
I like the current paradigm of a “scenario” is essentially just a saved game, but I have a few thoughts on that…
- It might be helpful to change the extension from .vmod to something that indicates it’s intended to be a scenario file (e.g., .vscn)
- Vassal currently supports 2 types of scenarios (both of which are really just saved games)
a) “Built-In” - internal to the module
b) “Private” - a scenario which is not built-in and shared via out of band means (email, dropbox)
I think it might be worth considering a third case “Public” - where public scenarios can be easily created and uploaded to the VassalEngine site.
Vassal, when launching a module could have the ability to show the existing “Public” scenarios for that module (in addition to the “Built-In” scenarios).
This paradigm would enable the community to easily build/share new scenarios, without having to modify the guts of the module (helping to keep modules smaller and less chance of screwing something up).
When setting the “# available” in a piece palette, 2 distinct use cases should be considered (and select-able on a per unit-type basis):
- Number is maximum available and strictly decrements
(i.e., hard limit) - Number is maximum available on map at any one time
(i.e., soft limit)
Example:
Tiger Tank 1 available (hard limit)
German Infantry Platoons 3 available (soft limit)
So in this scenario, you only get 1 Tiger and once it’s destroyed no more are available. However, an infinite number of replacements are available for the single company (3 platoons) of German Infantry.
1 Like
The second case (soft limit) could be implemented as a hard limit, but instead of deleting a piece or making it unavailable for the rest of the game when it is removed from play, returned the piece to the piece palette for reuse later. This method may be easier to implement in that it would not require counting or keeping up with how many of the piece are in play at any one time.
There are ways to manually implement around the soft vs. hard limit if both are not intrinsic properties of the piece palette.
However, IMHO having the piece palette implement both hard and soft limits as standard functionality makes module development easier and ensures better consistency.
I’m sure I’m not experienced enough to see most of the benefits of a “master” or “library” palette, but I can see that it would help with inventorying the pieces to make sure they are all in the module.
For scenarios isn’t this just essentially a variation of the current “vlog” extension? The only difference would be it being a static snap shot, and nothing that can be “played back”. And giving it a “vscn” label would make perfect sense
I’d like to chip in with some thoughts from my experience of maintaining modules with many scenarios, including community-generated.
-
Distinguish a scenario file
.vscn is a nice distinction but a deeper indication is required (file extensions don’t normally affect anything more than how the file looks/opens in the OS, yes?). To explain further; once you want your module to run a startup routine, you may well hit the issue of “how do I know that this is a new fresh game”…
This issue is resolved for built-in games since Vassal v3.6, there is now a Startup GKC option that runs when a fresh game is started and built-in is included in that category. So, since v3.6, there is now that caveat on “built-in” being the same as “private”. So, of course, it still leaves the module dev with the issue; as private scenarios have to be handled just like before.
A simple solution might be if the Pre-Defined Scenario menu structure (assuming it exists in v4), included an option to “Start a Game from a file”. If started in this way, Vassal would recognise it as a fresh game. The option to open a file normally, would need to be clear that it is opened just like a log file, to continue an open game. -
Public repository.
I know one scenario designer who already craves this feature - ability to maintain his scenarios without resource to the module dev.
One benefit of integrated scenarios is that the module dev can take those scenarios forward into new versions of the module, aided by the Refresh Pre-Defined Scenarios tool. If v4 somehow does away with the need to refresh, then my point is moot. However, if not, then thought should be give to how the Public repository is kept up to date with maintenance releases (old module version defunct) and new releases (old module still valid).
That has been one of the stated aims for V4 from the start.
1 Like
Does Scenario creation happen in the Editor (Which requires the Editor to have Player features) or does it happen in the Player (Which requires the Player to have Editor features)?. .
Scenarios are created in the player; they are just saved games.
It is enough to load the scenario file to start playing it.
However, to make a scenario appear in the scenario list requires that the scenario file is added into the module (in the Editor, choose Pre-Defined Setup).