Create a gamerules file that allows for the easy manipulation of various currently-hardcoded values

[Amazinite]

Is your feature request related to a problem? Please describe.
There are currently a number of hardcoded values that it might be interested to be able to fiddle with, such as as the values that dictate depreciation. There are also mechanics that have been removed in the past that some players might like to have in their game, while others might not. Death benefits comes to mind as one such removed mechanic. Ideally, instead of completely removing such mechanics, it might be better to have them be able to be toggled on and off.

Related Issue Links
#2200 attempted to create a file similar to this.
#5554 includes an example of the type of values that one might want to change in a data file.
#1386 Having customizable gamerules would allow for creating different difficulty levels.
#5512 Such gamerules would ideally be able to be modified by start conditions so that changing difficulties doesn't require going into the data files to switch things around.

Describe the solution you'd like
Create a class similar to preferences named gamerules. Gamerules would contain a map<string, double> where the string is the name of the gamerule and the double is the value. Gamerules would be statically accessed, as preferences is now, whenever it is needed. Using a double for the value means that we can have gamerules that do require doubles, gamerules that require ints (cast the double to and int), and gamerules that require bools (take 0 as false and anything else as true).

What this would not include is the customization of strings that are currently hardcoded, such as outfit and ship categories.

Describe alternatives you've considered
Do what #5555 does and make use of the interface class.

Additional context
Potential gamerules:

• Basic stuff:
  • Depreciation constants. (create parameters.txt file for: *ship categories* *depreciation* *pirate raids*, allow extending of data nodes (adding to existing ship without blowing away values), add sorting of missions by: *system* *payment* *deadline* #2200)
  • Debris lifespan.
  • Author spawn time.
  • Base hit force relative to mass.
  • Base ramscoop value.
• More advanced stuff (e.g. AI changes):
  • The weights that AI give to various targets? (AI::FindTarget)
  • Changing the amount of health a fighter has left before it retreats to its carrier.
  • The system fence distance.
  • Default jump/hyperdrive arrival distance.
    • Also default departure distance (when it becomes a thing).
  • Constants dictating the strength of ramscoops/solar panels given the distance from the system center. (min power, max power, distance where strength = 1)
  • Cooling inefficiency constants.
  • Loan constants (for the player taking loans from the bank).
  • Default constants for the minimum hull equation (when a ship becomes disabled).
  • The range at which missile boat behavior is used.
• Toggle mechanics (stuff that use to exist or has been requested and denied):
  • Whether death benefits are a thing. (Removed mechanic)
  • Whether pirates plunder the player's outfits when they board you. (Removed mechanic)
  • Fines for unlicensed outfits/ships. (Removed mechanic)
  • Refueling costs.
  • Repair costs.
  • Friendly fire.
  • Multiplicative stacking.
• Other (stuff I'm not so sure on):
  • Min/max map zoom levels. (Feature Request: Allow Min and Max Map Zoom Levels to be Defined in interfaces.txt #5554) Handled in the interface.
  • Default bleed rate of status effects.
  • Number of effects created when jumping.
  • Amount of smoke created on ship death based on mass. (Maybe just turn this into something that must be defined on the ship.)
  • Toggle asteroid field.
  • Default attack/defend values.

As with my example in #5554, I imagine all gamerules would have comments above them in the data file to describe what they do. The gamerules file would be stored alongside the preferences file, but could perhaps also be altered depending on which save file the player chooses if different starts are able to modify gamerules.

[Zitchas]

• Debris lifespan (I find chasing dropped minerals and loot from ships to be a pain).
• Authorship spawn time. (I have a separate build of the game that drops author ship spawn time down to 15 seconds. It'd be nice to just have a gamerule file to change instead of having to recompile the game)

[thebigh2014]

I definitely like the sound of this and how it opens up the game to customization. I definitely support min/max zoom levels, depreciation constants, ramscoop/solar panel strength, and debris lifespan. I'm sure there are others if/when I look for them.

[Ferociousfeind]

Any time you see a hardcoded variable anywhere, that is an opportunity to toss it into a configurable file for fun and profit.

Should projectile effects like ion and slowing decay at 1% per frame? What about 0.0001%? Or 10%?
(What if the projectile determined how slowly its unique effect wore off? As in, one weapon does a lot of ion damage but it bleeds off really quickly, to temporarily shock the enemy with an energy shortage, and another one that does a little bit of ion damage but it lingers for a very long time, and slowly paralyzes the enemy ship. But that's an entirely different issue, and should be tackled elsewhere, lmao)

Though, honestly, can't think of any others at the moment. Maybe the heat inefficiency curve? I had proposed a simplified version of the formula which used inverse tangent for a simpler inverse f(x), I think. The heat inefficiency curve could be put onto a configuration file.

[Amazinite]

Though, honestly, can't think of any others at the moment. Maybe the heat inefficiency curve? I had proposed a simplified version of the formula which used inverse tangent for a simpler inverse f(x), I think. The heat inefficiency curve could be put onto a configuration file.

"Gamerules" as defined here would only involve changing constants, not entire equations.

[WarlordMike]

I would love to see this implemented. It'd be fantastic for those of us who are new to the game and would want some more leniency in addition to those who want to go full hardcore mode and have a challenge.

[ravenshining]

Oh, yes! This sounds like it could lead to me being able to play ES and finding it acceptably challenging at the same time as steam newbies, without having to maintain my forked code independently.

"Gamerules" as defined here would only involve changing constants, not entire equations.

True, but, depending on where you put those constants, they could have a profound effect on an equation. Especially if that constant is in an exponent, or on one term of a large equation, rather than simply being applied to the result.

[gregorydgraham]

Following on from Amazinite's comment, could it be GameConstants?

That would leave GameRules free for a more general rules engine that defines equations and appropriate contexts

[Zitchas]

• Default hyperjump entry distance
• Default minimum distance for hyperjump
• Default jumpdrive entry distance
• Default jumpdrive minimum distance

[petervdmeer]

My impression is that most of the options mentioned here would be best placed as a keyword in the data-files. Then you could just get a plugin to override the setting if you want something non-standard.

I also feel that you don't really need a separate class to store those, most values already have some nice location to store them.

An issue that I see with removed mechanics is that re-adding them also requires maintenance and testing for those features. We want them to work properly if we allow players to activate them.

[Amazinite]

The gamerules file was added with #7740. If there are any specific gamerules that people would like, they should be opened as separate issues or PRs.