Difficulties

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
szopen
Krill Swarm
Posts: 14
Joined: Mon Sep 29, 2014 12:20 pm

Difficulties

#1 Post by szopen »

Hi there,

After losing a game ebcause experimentators appeared, I became so frustrated that I started working on FO code.
This is the result:
single_player.png
single_player.png (551.98 KiB) Viewed 2312 times
child_diff.png
child_diff.png (158.67 KiB) Viewed 2312 times
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.
szopen-diff.gz
(23.3 KiB) Downloaded 99 times
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.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Difficulties

#2 Post by Geoff the Medio »

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.

szopen
Krill Swarm
Posts: 14
Joined: Mon Sep 29, 2014 12:20 pm

Re: Difficulties

#3 Post by szopen »

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.
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:

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.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Difficulties

#4 Post by Geoff the Medio »

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.

User avatar
em3
Vacuum Dragon
Posts: 630
Joined: Sun Sep 25, 2011 2:51 pm

Re: Difficulties

#5 Post by em3 »

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

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: Difficulties

#6 Post by Mitten.O »

BTW, how to create diffs so I won't have to modify them by hand, removing all the cmakes etc?
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.
Any code by me in this post is released under GPL 2.0 or later.

szopen
Krill Swarm
Posts: 14
Joined: Mon Sep 29, 2014 12:20 pm

Re: Difficulties

#7 Post by szopen »

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.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Difficulties

#8 Post by MatGB »

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.
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.

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.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Difficulties

#9 Post by Geoff the Medio »

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 ]
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
Krill Swarm
Posts: 14
Joined: Mon Sep 29, 2014 12:20 pm

Re: Difficulties

#10 Post by szopen »

Geoff the Medio wrote:
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 ]
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...
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 :-D ).

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.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Difficulties

#11 Post by Geoff the Medio »

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.
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.

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.
szopen wrote:...can anyone explain why this code does not work?

( *( parse::label(Bonus_token) >> --stuff...- )[ ---do something--- ] > the rest of the FleetParseCode. ...
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
Krill Swarm
Posts: 14
Joined: Mon Sep 29, 2014 12:20 pm

Re: Difficulties

#12 Post by szopen »

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:
szopen-all.diff.desc.gz
(1006 Bytes) Downloaded 102 times
Description and rationale:
szopen-all.diff.gz
(6.71 KiB) Downloaded 88 times

szopen
Krill Swarm
Posts: 14
Joined: Mon Sep 29, 2014 12:20 pm

Re: Difficulties

#13 Post by szopen »

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:
szopen-difficulty.diff.gz
(4.08 KiB) Downloaded 99 times
Only bonus-planet setting. This is a diff with manually removed all references to difficulty from the previous patch
szopen-bonusplanet.diff.gz
(3.62 KiB) Downloaded 115 times
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.
szopen-bonustech.diff.gz
(2.43 KiB) Downloaded 99 times
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.

szopen
Krill Swarm
Posts: 14
Joined: Mon Sep 29, 2014 12:20 pm

Re: Difficulties

#14 Post by szopen »

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.
szopen-bonusplanet.diff.desc.gz
(202 Bytes) Downloaded 96 times
szopen-bonustech.diff.desc.gz
(244 Bytes) Downloaded 90 times
szopen-difficulty.diff.desc.gz
(493 Bytes) Downloaded 86 times
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.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Difficulties

#15 Post by Geoff the Medio »

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.

Post Reply