patchFreeciv - Patches: patch #4887, [metaticket] Multipliers/policies...

Show feedback again

patch #4887: [metaticket] Multipliers/policies half-bakery

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Tue Jul 1 22:47:05 2014  
Category: NonePriority: 5 - Normal
Status: Need InfoPrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Wed Oct 14 17:20:05 2015, comment #3:

You should limit control of limits to only buildings and government. Imagine maximum value of multiplier are related to value of multiplier B and vice-versa, so player could set values to very high level.

SÅ‚awomir Lach <lachu>
Sun May 10 12:49:23 2015, comment #2:


> Limits controlled by effects

Moved design to patch #6081.

> Cost to change / Limit change frequency
> [...]
> * Changes to sliders simply don't take effect until next turn

That bit is patch #5341. Anything more is still in this ticket.

> AI

Patch #6080 raised to cover minimal AI support.

Jacob Nevins <jtn>
Project Administrator
Wed Jul 2 04:00:35 2014, comment #1:

On AI use of sliders:
In the event that slider value changes are limited to once per turn (players can change as much as they want, whenever they want, but the effect of having done so only takes effect on turn change), the the AI can call into a valuation routine at end-of-turn to set appropriate values. For each multiplier, iterate over the effects (probably makes sense to add multipliers as a source in the ruleset cache for performance reasons), and call dai_effect_value() to determine the relative interest in the effect. Then compute the total valuation of any possible slider position, and select the best one (or a random one of the best in the case of equivalent valuation). Note that doing it this way will cause any bugs in dai_effect_value() to become more obvious if they happen to match effects for which multipliers are applied.

In the event that slider values take effect in realtime, a lightweight target optimisation routine could be added for in-turn relative effects (e.g. unit move rates, attack/defense bonuses, etc.), which has a cache of multipliers relative to specific activities/conditions, which is checked when those conditions apply. In such cases, the AI would push the slider all the way for that effect at that moment, so the sliders move about over the course of the turn (if relevant), and and end of turn, the routine described above is called to set sensible values for turn change. If this is needed, it may make sense to have it be a different patch than the once/turn calculation, as it would be nice to call into some of the code written for that during the cache population.

I haven't investigated the call stack, but it may be that the AI will need to set the multipliers to some neutral value (e.g. 1.0) before calculating best values, so as not to end up in a feedback loop: yes this won't be optimal, but calculating true multivariate optimums without succumbing to local maxima takes more processing than the classic AI should be permitted.

Emmet Hikory <persia>
Project Member
Tue Jul 1 22:47:05 2014, original submission:

A place to dump ideas related to the "effect multipliers" feature being added in patch #4830.

If any of these grow legs, they probably want breaking out into their own tickets.

Limits controlled by effects

Initially the min/max for multipliers is static. By analogy with the "Max_Rates" effect, it would be good to have it able to depend on overall government, wonders, etc, so that better governments allow you more (or less...) freedom to set policies.

Sketch for how rulesets could specify this:

Cost to change / Limit change frequency

It would be good to have some way(s) to optionally attach a cost to changing these settings.


  • Sliders could be used for fundamental, government-like policies, to which you want to attach a revolution-like cost.
  • Some effects can be used within a turn. It would be good to allow sliders to be used with such effects without rewarding micromanagement.
    • Imagine a trade-off of infantry vs cavalry strength, for the sake of argument; you want to be able to prevent a player choosing a setting favouring infantry, attack with infantry, then favouring cavalry and attacking with cavalry, getting the best of both settings. (There are probably less contrived examples.)
    • (We get away with allowing free manipulation of tax rates because they only take effect at turn end.)

Possible cost/delay mechanisms:

  • You have to pay a cost in gold depending on the magnitude of changes
  • Cumulative changes over a threshold since the last revolution plunge you into anarchy
  • Changes to sliders simply don't take effect until next turn

Cost function idea: a set of settings is described as a multi-dimensional array of coordinates in a "cost space"; the cost of changing from one setting to another is the distance between these points. (Players only see the relative costs, the absolute numbers of the "cost space" are a meaningless internal detail.)

So the abstract 'cost is 100 per step of freedom-of-speech + 10 per step of work time (in either direction). A full-scale change of both costs 10*100 + 8*20 = 1160.
You can hang gold costs, revolution thresholds etc off this cost function via some effect-based factor (allows "statue of liberty" free policy change effects).


How on Earth are we to teach the AI how to use this? It's a ruleset-defined trade-offs feature; teaching the AI to understand and manipulate arbitrary trade-offs sounds hard.----

User interface

This is currently presented as numeric sliders, which matches our effects system. However, there might be value in having policies which are presented to the user as boolean, or discrete enumerated types; this would affect display only, the underlying data model remains that of linear numeric effects. This would be some extra properties in multipliers.ruleset that only the client looks at.

Generalised tax rates

What would it take to make science/lux/tax rates a special case of this framework?

  • Need to be able to specify a group of 3 related sliders with appropriate constraints on all 3.
  • Need effects for current tax rate values.
  • Need to teach AI how to locate tax-rate-like constructs in rulesets...
Jacob Nevins <jtn>
Project Administrator


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


   patch dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by lachu (Posted a comment)
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  • -unavailable- added by jtn (original idea)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun May 10 12:49:59 2015jtnDependencies-=>Depends on patch #6081
    Sun May 10 12:49:46 2015jtnDependencies-=>Depends on patch #6080
    Sun Oct 5 15:21:17 2014jtnDependencies-=>Depends on patch #5341
    Tue Jul 1 22:47:23 2014jtnDependencies-=>Depends on patch #4830
    Tue Jul 1 22:47:05 2014jtnCarbon-Copy-=>Added lachu
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup