Difficulties
Moderator: Committer
Difficulties
Hi there,
After losing a game ebcause experimentators appeared, I became so frustrated that I started working on FO code.
This is the result: I have implemented the following things:
1) General difficulty level "child <--> freeorion god" + custim, which simple presets some other settings
2) specialised settings:
* add tech (one additional random tech from a file of techs "bonus_techs"),
* add fleet (a modification to starting_fleet keywords in form "bonus = [ none low]"). Then in starting fleet you may define which additional fleets are available on some difficulties, with result depending from setting "add_fleet" (to all, to human, only to ais) and difficulty
* cheat tech, cheat pp - not implemented, see below
* guerilla - not implemented, see below
* add planet in homeworld system - during universe generation, additional MEDIUM planet with preferred type is created, making it possible to colonize it.
* experimentators - somewhat implemented. in shared_macros an additional Option name = value was added, e.g.
TURN_EXPERIMENTATORS_START
Option GameSetup.experimentators-sched = TIME_EARLY
'''150'''
Then this [[TURN_EXPERIMENTATORS]] can be added in default/buildings.txt to control when they are to appear. "NEVER" is implemented as a hack (turn value of 20000).
This required in turn some other modifications.
The included patch is NOT INTENDED FOR APPLYING. I created it with diff -Naur myversion latest_svn, which generated 6MB patch, which I then modified by hand. I merely ask developers to inspect the changes and say, whether they would be acceptable. If so, I would be happy to
transfer them to latest SVN edition (I downloaded it minutes ago...). Because i modified 6MB patch by hand, it is possible that I removed too much. DO NOT APPLY, but please please do inspect.
BTW, how to create diffs so I won't have to modify them by hand, removing all the cmakes etc?
cheat PP and cheat tech:
* The idea is to allow beginner players to have a bonus of "free" tech or PP points. I'd implement it by adding float or int "cheat_pp" field to each empire, set by default to 0. On "CHILD" difficulty, human would have some value added here. On ORIONGOD, AIs would have some free poitns added here.
Guerilla
The idea is to prevent easy conquest of enemy planets. After a conquest, a resistance is formed to a new rule. This is not military challenge, just some low-level sabotage, guerillas fighting in forests etc - all captured by "guerilla" umbrella name. This shold simly cap the PP and research points produced by a system for some time after the conquest. Modified by planetery garrisons and new techs like "alien_psychology" or "convincology" (or ultimately, towers like in Strugackis book of which I know no english title "world inside-out"). I though about implementing is as either new METER type, which would then be used in GetMeter in Planet to modify values of returned tech and pp meters.
After losing a game ebcause experimentators appeared, I became so frustrated that I started working on FO code.
This is the result: I have implemented the following things:
1) General difficulty level "child <--> freeorion god" + custim, which simple presets some other settings
2) specialised settings:
* add tech (one additional random tech from a file of techs "bonus_techs"),
* add fleet (a modification to starting_fleet keywords in form "bonus = [ none low]"). Then in starting fleet you may define which additional fleets are available on some difficulties, with result depending from setting "add_fleet" (to all, to human, only to ais) and difficulty
* cheat tech, cheat pp - not implemented, see below
* guerilla - not implemented, see below
* add planet in homeworld system - during universe generation, additional MEDIUM planet with preferred type is created, making it possible to colonize it.
* experimentators - somewhat implemented. in shared_macros an additional Option name = value was added, e.g.
TURN_EXPERIMENTATORS_START
Option GameSetup.experimentators-sched = TIME_EARLY
'''150'''
Then this [[TURN_EXPERIMENTATORS]] can be added in default/buildings.txt to control when they are to appear. "NEVER" is implemented as a hack (turn value of 20000).
This required in turn some other modifications.
The included patch is NOT INTENDED FOR APPLYING. I created it with diff -Naur myversion latest_svn, which generated 6MB patch, which I then modified by hand. I merely ask developers to inspect the changes and say, whether they would be acceptable. If so, I would be happy to
transfer them to latest SVN edition (I downloaded it minutes ago...). Because i modified 6MB patch by hand, it is possible that I removed too much. DO NOT APPLY, but please please do inspect.
BTW, how to create diffs so I won't have to modify them by hand, removing all the cmakes etc?
cheat PP and cheat tech:
* The idea is to allow beginner players to have a bonus of "free" tech or PP points. I'd implement it by adding float or int "cheat_pp" field to each empire, set by default to 0. On "CHILD" difficulty, human would have some value added here. On ORIONGOD, AIs would have some free poitns added here.
Guerilla
The idea is to prevent easy conquest of enemy planets. After a conquest, a resistance is formed to a new rule. This is not military challenge, just some low-level sabotage, guerillas fighting in forests etc - all captured by "guerilla" umbrella name. This shold simly cap the PP and research points produced by a system for some time after the conquest. Modified by planetery garrisons and new techs like "alien_psychology" or "convincology" (or ultimately, towers like in Strugackis book of which I know no english title "world inside-out"). I though about implementing is as either new METER type, which would then be used in GetMeter in Planet to modify values of returned tech and pp meters.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Difficulties
Initial reaction is that these sorts of extra settings might be better put on a separate game rules setup page, not together with the galaxy setup settings.
A tech and production cost slider might be more useful... set it to 0 to make everything cost 1, but otherwise it's a multiplier varying from 0 to 10 or so, perhaps with a nonlinear scale.
Some clarification of "difficulty" level might be good, as there are already settings for monster frequency and AI aggression which do similar things.
I'm not overly fond of hard-coding something about "Experimentators" into the UI if they are otherwise purely content scripted... A way to add such options about scripted content from within the scripts would be preferable. A more generic "end game content" setting would be better if it's hard coded.
Discussion of rules changes such as the proposed "Guerilla" should probably be a separate topic, and would likely conflict in purpose with planned happiness / empire-species interactions changes.
A tech and production cost slider might be more useful... set it to 0 to make everything cost 1, but otherwise it's a multiplier varying from 0 to 10 or so, perhaps with a nonlinear scale.
Some clarification of "difficulty" level might be good, as there are already settings for monster frequency and AI aggression which do similar things.
I'm not overly fond of hard-coding something about "Experimentators" into the UI if they are otherwise purely content scripted... A way to add such options about scripted content from within the scripts would be preferable. A more generic "end game content" setting would be better if it's hard coded.
Discussion of rules changes such as the proposed "Guerilla" should probably be a separate topic, and would likely conflict in purpose with planned happiness / empire-species interactions changes.
Re: Difficulties
Well, in my code proposal there would be an option passed from the game setup, which then could be scripted. E.g. the option "TIME_EARLY" is passed to the parser, and then in shared macros you have EXPERIMENTATORS_TURN_START with different settings for TIME_EARLY, TIME_NEVER and so on. Alternative, but similar approach is with "bonus_fleet" option: the option is passed to the generation, and then you have something like this in starting_fleet.txt:Geoff the Medio wrote: I'm not overly fond of hard-coding something about "Experimentators" into the UI if they are otherwise purely content scripted... A way to add such options about scripted content from within the scripts would be preferable. A more generic "end game content" setting would be better if it's hard coded.
Fleet
bonus = [ none low ]
name = "FN_BATTLE_FLEET"
ships = [
"SD_MARK_1"
]
Fleet
bonus = [ medium high ]
name = "FN_BATTLE_FLEET"
ships = [
"SD_LARGE_MARK_1"
]
As I see it, most players who would actually require diffciulty seetings would be exactly those players, who wouldn't be incredibly good with tinkering with the scripts or whatever and they would, I think, require a nice checkbox in UI, visible during game startup.
After reading several threads I noticed that "Ai Aggression" is not supposed to be about general game difficulty. Adding a nice, large "difficulty" somewhere in dialog starting the new single player game is not necessity, but would be probably welcomed by beginners.
If you owuld think those changes I sensible, at least some of them, I'd svn co latest version, port my changes to them, generate smaller diffs per-file and then post them here. It would take a week at least, though. Maybe more.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Difficulties
I'm not suggesting players should be editing script files. I'm saying that any options that players could see in the UI should not be hard-coded into C++, but would instead be determined by something in the scripts.
Re: Difficulties
A clean solution to the experimentators could be to add support for "mods" or "scenarios". Then, during galaxy creation, they could be enabled on an opt-in basis (with a script-generated configuration popup for each enabled mod).
https://github.com/mmoderau
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556
Re: Difficulties
Use "svn diff" to make svn create the diff. It only includes files in version control in the diff. You will need to notify svn of new files with svn add. (Don't forget to do that, it is embarrassing when you forget. Trust me, I know). If you use another version control system locally, you can probably make it produce similar output one way or another. There is discussion about making git do it on this forum.BTW, how to create diffs so I won't have to modify them by hand, removing all the cmakes etc?
Any code by me in this post is released under GPL 2.0 or later.
Re: Difficulties
Thanks for the hint on making diffs!
Now, I will made separate diffs for
a) add new planet, depending on "add new planet" option + appriopriate checkbox.
b) add new random tech, dependng on "add new tech" option + checkbox
c) add "bonus" option to starting_fleet.txt
c) Preset "difficulty" option
Note if such code is committed, then it doesn't have to be "hardcoded" in a sense that it is no more hardcoded that anything else whcih is written in scripts. You may remove the checkbox, leave the option, and have this option to be set from config, or mod.txt, and so on.
This mod.txt would be automagically loaded by the engine on game startup when you owuld choose available mod,
Maybe mod.txt with a structure
Mod
name = "Child difficulty"
PresetOptions
bonus_planet = only_human, medium
bonus = [ ai = low, human = high ] // to be used in starting_fleets
bonus_tech = 2 // 2 random techs; or bonus_tech = 2 of [ list of techs ]
etc
would be nice solution. I could code it. This mod could then re-define some existing macros and so on.
Now, I will made separate diffs for
a) add new planet, depending on "add new planet" option + appriopriate checkbox.
b) add new random tech, dependng on "add new tech" option + checkbox
c) add "bonus" option to starting_fleet.txt
c) Preset "difficulty" option
Note if such code is committed, then it doesn't have to be "hardcoded" in a sense that it is no more hardcoded that anything else whcih is written in scripts. You may remove the checkbox, leave the option, and have this option to be set from config, or mod.txt, and so on.
This mod.txt would be automagically loaded by the engine on game startup when you owuld choose available mod,
Maybe mod.txt with a structure
Mod
name = "Child difficulty"
PresetOptions
bonus_planet = only_human, medium
bonus = [ ai = low, human = high ] // to be used in starting_fleets
bonus_tech = 2 // 2 random techs; or bonus_tech = 2 of [ list of techs ]
etc
would be nice solution. I could code it. This mod could then re-define some existing macros and so on.
Re: Difficulties
Vezzra and I have discussed that they, if they're kept broadly as are, are a victory condition, and thus should be part of galaxy generation and not just a content script.Geoff the Medio wrote: I'm not overly fond of hard-coding something about "Experimentators" into the UI if they are otherwise purely content scripted... A way to add such options about scripted content from within the scripts would be preferable. A more generic "end game content" setting would be better if it's hard coded.
I thus strongly favour having them included as an off/easy/moderate/hard option in galaxy geneartion separate from other options as then a) it solves many many of the problems new players have with them and b) it's consistent with other similar games{1} and lets players choose whether to face them, if chosen they're guaranteed to be there with scripted parameters, currently they're too random and both too easy (for experienced players) and horrible (for new players)
{1} FreeCol and at least one other 4X game I've played give you options for victory conditions, beating the Royal Expeditionary Force is one condition that's very similar to the Experimentors in feel/game design.
I share the concerns about too much in one undiscussed idea, but I also think some sort of 'cheat' setup, especially for new players, is probably a good plan, an extra planet in your home system is such an easy advantage that you sometimes get randomly anyway, for example, that that in and of itself is a good plan.
@szopen the idea with Experimentors is to change the way they generate currently to be part of the generation scripting, whether or not your code is compatible is way beyond me.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Difficulties
Looks like you want to do complicated stuff that would be better written in a python script than something that has to have custom parsing written...szopen wrote:Mod
name = "Child difficulty"
PresetOptions
bonus_planet = only_human, medium
bonus = [ ai = low, human = high ] // to be used in starting_fleets
bonus_tech = 2 // 2 random techs; or bonus_tech = 2 of [ list of techs ]
Re: Difficulties
I hate python. But if you think it would be better if there would be a python script to do the same, I can learn python and write it. The only difficulty I see _now_ is how to post new options from python script to the GUI, so GUI can present it to the user. In addition, I love writing parsers, though I never before was using anything like spirit and it took me few hours before i started get feel of it (I usually write C++ or C form scratch, just because it is fun ).Geoff the Medio wrote:Looks like you want to do complicated stuff that would be better written in a python script than something that has to have custom parsing written...szopen wrote:Mod
name = "Child difficulty"
PresetOptions
bonus_planet = only_human, medium
bonus = [ ai = low, human = high ] // to be used in starting_fleets
bonus_tech = 2 // 2 random techs; or bonus_tech = 2 of [ list of techs ]
In addition, the modpack in syntax written above would be, I think, be more readable to the users. Trhe user can easily see the option "bonus = true" and change it, while he/she can be kept away by python syntax.
Aaand, if we are with complicated parsing, can anyone explain why this code does not work?
( *( parse::label(Bonus_token) >> --stuff...- )[ ---do something--- ] > the rest of the FleetParseCode. ...
The result was that the parser expected a boolean value if "Bonus" keyword was missing. It took me a whole day, until I finally changed it to the version in the patch above in the post starting the thread ... The same if I used syntax of ( +( X ) > A > B >C ) | (A > B >C ) )
Anyway, it's just the question whether you think it's a good idea. Next week I will have few days of free time and I could try to write it. Maybe it would be hopelessly more complicated that I imagined, I would give up, but then you would lose nothing, OTOH, if you think it is not worth the effort at all and because of game design issues you won't even consider accepting a patch implementing "mods.txt" syntax, I would not even try to write it.
Tomorrow I will prepare the separate patches to the svn version with "add bonus planet", "diffculty", "add random tech" and so on baed to todays SVN checkout.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Difficulties
Players would never be reading either. You'd have a galaxy setup python script that tells the UI (possibly via the server) that it accept a certain set of parameters, and the UI would display widgets to let the player specify those parameters. The client would send the info to the server which would pass it to the script when generating the galaxy.szopen wrote:...the modpack in syntax written above would be, I think, be more readable to the users. Trhe user can easily see the option "bonus = true" and change it, while he/she can be kept away by python syntax.
There was a thread discussing this sort of system for the universe generation scripts, though I'm not sure where it is to link to.
Haven't read your patch, but I think the label parser is optional. If you want a mandatory token, I think you'd need tok.Bonus_ or similar (don't remember the exact form, but see various examples in existing parsers).szopen wrote:...can anyone explain why this code does not work?
( *( parse::label(Bonus_token) >> --stuff...- )[ ---do something--- ] > the rest of the FleetParseCode. ...
Re: Difficulties
OK, here is the version created with svn diff.
Adding only UI three options (difficulty, bonus-planet, bonus-tech), passing them to scripts, using them there.
Difficulty presets monster frequency, aggression, adds bonus-planet and bonus-tech.
The patch: Description and rationale:
Adding only UI three options (difficulty, bonus-planet, bonus-tech), passing them to scripts, using them there.
Difficulty presets monster frequency, aggression, adds bonus-planet and bonus-tech.
The patch: Description and rationale:
Re: Difficulties
Since a post can accept only 3 attachments, here is another post with more diffs. Those are the same as the one big previous patch,e xcept they are put separately here, if someone would want to inspect one of them.
Only difficulty: Only bonus-planet setting. This is a diff with manually removed all references to difficulty from the previous patch Only bonus-tech - randomly adds random tech from bonus_items.txt - created by svn diff and then removing everything which was in the previous patches. Those three patches are meant to be more or less standalone, but frankly, I tested only the first one - those three are meant mostly if someone doesn't like UI changes and yet thinks it would be nice to add bonus-planet, for example.
Only difficulty: Only bonus-planet setting. This is a diff with manually removed all references to difficulty from the previous patch Only bonus-tech - randomly adds random tech from bonus_items.txt - created by svn diff and then removing everything which was in the previous patches. Those three patches are meant to be more or less standalone, but frankly, I tested only the first one - those three are meant mostly if someone doesn't like UI changes and yet thinks it would be nice to add bonus-planet, for example.
Re: Difficulties
Again, since one posts allows only three attachments, here are attachments with descriptions. I am not sure what are the forum rules wrt posting : whether it'd more ok to create one .tar archive and one post, or whether separate gzips (to allow quick inspection of each file) are better, at the cost of three posts instead of one. Please do not kill me.
Now, about the difficulty. I was thinking about your arguments and here is what I came to:
What would you think about easily implemented system like that:
At the start, system reads from default/difficulties.txt and presents them as part of DIFFICULTY setting (rationale: beginners will seek for difficulty setting - at least I was searching for the one - so adding a setting as this would help them). The syntax would be
"<id>" "<short-name>" "Description"
e.g
"Child" "Do not hurt me!" "This setting is meant to the players who are newcomers to FreeOrion game and sets the following options..."
With UserStrings of course instead of straight english"
In the default, you would have the mods directory. Within mods, you'd have separate directories for mods. "Difficulty" would be in fact just a mod like all others.
"Include" would first search for a file in directory "default/mods/<mod-name>, and if the file couldn't be found there, in default/mods/common
In any parser you would do the same (probably some function returning a path would be necessary).
E.g. in code you have "load_fleet(starting_fleets.txt)". User in GUI selected "CHild" difficulty. The system first looks for the default/mods/child/starting_fleets.txt and if it does not find one, for the default/mods/common/starting_fleets.txt
If you want to have some part of starting_fleet.txt to be shared across the mods, you simply separate that part into a file common_starting_fleet.txt in default/mod/common, ensure it is included in starting_fleet.txt's of any mod
This solution does not require ANY change to the syntax, no requirement of coding new parser AND would allow incredibly flexibility (e.g. macros of different values in different mods, sicne they all could load different shared_macros.txt).
To allow more, you could start with minimal parser to allow file "presets.txt" or whatever to exists in each mod diretory. This "presets would, well, preset the UI options presented in Game startup. Syntax would be "option" = "value". You could also have options_exposed.txt with
set of additional, mod-specific options exposed to the gui.
Now, not everyone is python hacker, and this solution would allow a bit-more-advanced players to easily modify their values by hand, or create their own mods in future. Each mod could have his own art folder, or - far in the future - folder with python scripts. I know if someone knows python, he thinks : no need to create this system, since everyone can learn python and create mod that way, but THIS way would be less scary for the non-programmers (think about wesnoth - people who create scenarios quite often are not programmers and they do not even consider themselves programmers).
I could implement a rudimentary version of this very quickly (that is, provided I have some time).
Now, what do you think? You say yes, within a week you will have basic mod system.
Aand about the parser: yes, the syntax says the label is optional and if it existed, then you do one action, and if it does not, then it should do another action. According to documentation, it should work, but it weren't. I spent whole day tryign to figure it out and i failed misearbly, which really hurted my ego.
Now, about the difficulty. I was thinking about your arguments and here is what I came to:
What would you think about easily implemented system like that:
At the start, system reads from default/difficulties.txt and presents them as part of DIFFICULTY setting (rationale: beginners will seek for difficulty setting - at least I was searching for the one - so adding a setting as this would help them). The syntax would be
"<id>" "<short-name>" "Description"
e.g
"Child" "Do not hurt me!" "This setting is meant to the players who are newcomers to FreeOrion game and sets the following options..."
With UserStrings of course instead of straight english"
In the default, you would have the mods directory. Within mods, you'd have separate directories for mods. "Difficulty" would be in fact just a mod like all others.
"Include" would first search for a file in directory "default/mods/<mod-name>, and if the file couldn't be found there, in default/mods/common
In any parser you would do the same (probably some function returning a path would be necessary).
E.g. in code you have "load_fleet(starting_fleets.txt)". User in GUI selected "CHild" difficulty. The system first looks for the default/mods/child/starting_fleets.txt and if it does not find one, for the default/mods/common/starting_fleets.txt
If you want to have some part of starting_fleet.txt to be shared across the mods, you simply separate that part into a file common_starting_fleet.txt in default/mod/common, ensure it is included in starting_fleet.txt's of any mod
This solution does not require ANY change to the syntax, no requirement of coding new parser AND would allow incredibly flexibility (e.g. macros of different values in different mods, sicne they all could load different shared_macros.txt).
To allow more, you could start with minimal parser to allow file "presets.txt" or whatever to exists in each mod diretory. This "presets would, well, preset the UI options presented in Game startup. Syntax would be "option" = "value". You could also have options_exposed.txt with
set of additional, mod-specific options exposed to the gui.
Now, not everyone is python hacker, and this solution would allow a bit-more-advanced players to easily modify their values by hand, or create their own mods in future. Each mod could have his own art folder, or - far in the future - folder with python scripts. I know if someone knows python, he thinks : no need to create this system, since everyone can learn python and create mod that way, but THIS way would be less scary for the non-programmers (think about wesnoth - people who create scenarios quite often are not programmers and they do not even consider themselves programmers).
I could implement a rudimentary version of this very quickly (that is, provided I have some time).
Now, what do you think? You say yes, within a week you will have basic mod system.
Aand about the parser: yes, the syntax says the label is optional and if it existed, then you do one action, and if it does not, then it should do another action. According to documentation, it should work, but it weren't. I spent whole day tryign to figure it out and i failed misearbly, which really hurted my ego.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Difficulties
Your zipped patch files are 7 KiB or less. Zipping them is not worth the effort / time required. Making multiple posts is fine if you need to.
You seem to have a specific (and narrow?) definition of a "mod", which is not how I'd use the term. Combinations of game setup parameters that players could have set up individually anyway isn't worth making an extra set of files to be parsed, and does not constitute, to me, a "mod". Modifying Python is probably more difficult, but people writing those scripts whould be the ones specifying what parameters the scripts accept / understand and their default values anyway. And if someone wants to modify the game, much of the content scripts are FOScript and can be modified without any knowledge of Python.
I'm unsure about the practicality and necessity of a single difficulty setting... But if it were to be done, a 5 or so hard-coded difficulty levels could be set up and supported in the UI and exposed to Python and content scripts. When specifying a parameter for a Python script, it could also specify values to use for each possible difficulty level. Modified Python scripts that use different parameters would specifies values for those parameters for each difficulty level the same way... Or if a script wants to base how it functions off of difficulty settings, then it could just use the difficulty setting parameter directly, and not worry about having a default value for its parameters depending on another parameter (the difficulty setting), which really seems unnecessarily complicated.
The parse::label parsers essentially say: you can put this "whatever = " here if you want to for clarification, or you can leave it out and it'll figure it out based on what's already being parsed and the type of what comes next. parse::label is very specialized in purpose (optional name labels for parameters), and not suited for optional flags that cause an action to happen or not. If you want an optional flag parser, do it like the various existing examples for that already in the parsers, without using parse::label.
You seem to have a specific (and narrow?) definition of a "mod", which is not how I'd use the term. Combinations of game setup parameters that players could have set up individually anyway isn't worth making an extra set of files to be parsed, and does not constitute, to me, a "mod". Modifying Python is probably more difficult, but people writing those scripts whould be the ones specifying what parameters the scripts accept / understand and their default values anyway. And if someone wants to modify the game, much of the content scripts are FOScript and can be modified without any knowledge of Python.
I'm unsure about the practicality and necessity of a single difficulty setting... But if it were to be done, a 5 or so hard-coded difficulty levels could be set up and supported in the UI and exposed to Python and content scripts. When specifying a parameter for a Python script, it could also specify values to use for each possible difficulty level. Modified Python scripts that use different parameters would specifies values for those parameters for each difficulty level the same way... Or if a script wants to base how it functions off of difficulty settings, then it could just use the difficulty setting parameter directly, and not worry about having a default value for its parameters depending on another parameter (the difficulty setting), which really seems unnecessarily complicated.
The parse::label parsers essentially say: you can put this "whatever = " here if you want to for clarification, or you can leave it out and it'll figure it out based on what's already being parsed and the type of what comes next. parse::label is very specialized in purpose (optional name labels for parameters), and not suited for optional flags that cause an action to happen or not. If you want an optional flag parser, do it like the various existing examples for that already in the parsers, without using parse::label.