Ticket #43160

More ruleset control over Celebration bonus effects

Open Date: 2021-11-04 06:06 Last Update: 2022-11-20 21:58

Reporter:
Owner:
(None)
Status:
Open
Component:
(None)
MileStone:
(None)
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
None
File:
None

Details

TL;DR: Give rulesets unlimited granular control over celebration bonuses instead of assuming they want it hard-coded to trigger based on Civ2 mechanics. Feature requests are at the bottom.

Background. Mechanics to TRIGGER celebration are (mostly) hard-coded to be same as Civ2. Likewise, the BONUS you can get is limited in thinking to be like Civ2 (i.e., increase tile output or rapture.) Therefore, ruleset designers are allowed to emulate Civ2-like bonuses and only under Civ2-like trigger conditions. They have no free will to reshape happiness bonuses in ways different from Civ2. This is problematic because: generally, Civ2 bonuses are considered too boolean (non-granular) and too OP. For example, a +1 trade bonus to a tile is usually +100% and radically OP. Another example, rapture is either on/off, and if on, hard-coded with Civ2 conditions for what triggers it.

Proposal: Allow rulesets more "analogue" control over how bonuses for happiness are triggered, and with more granularity than yes/no bonuses. 1. Rulesets should be able to make effects which trigger based on whether a city is celebrating. Right now they have limited hard-coded options like: 1-increase tile output or 2-rapture. By making a req vec such as "Is_Celebrating", "Local", "City"; rulesets would get much more control all the conditions which trigger the bonus AND the kind of bonus received. The IS_CELEBRATING req is only "stage one thinking" though, as will be made more apparent by reading on. 2. Celebrating/Not celebrating is too boolean. Req vecs such as MIN_HAPPY_PCT, MIN_UNHAPPY, MIN_OUTPUT_SURPLUS could be used to give finer granular control to rulesets. For example, a. A city that's ALMOST celebrating could get more bonus than a city that's barely staying out of disorder. b. A city that's 100% happy could unleash rapture growth even in governments that don't have it, OR any other special bonus decided by the infinite creative artistry of the ruleset. c. Governments who suffer from poor granularity in their bonuses, could be balanced better by fine tuning certain bonuses (slight nerfs to the OP ones, slight fractional bonus improvements to the Underpowered ones.)

Summary of Feature requests: a. IS_CELEBRATING as a testable req vec >>> (the hard-coded Civ2 condition that celebration = 50% happy with no unhappy. however, see (b) and (c) below for how rulesets could make their own conditions for "celebration" bonuses) b. MIN_HAPPY_PCT as a req vec - % of a city whose citizens are happy c. MIN_UNHAPPY or MIN_UNHAPPY_PCT - either the % of citizens who are unhappy, or the raw value d. MIN_OUTPUT_SURPLUS - allows ruleset soft-coding of conditions for things like rapture or other bonuses, instead of hard-coded to be +1 food + 50% happy + !(unhappy) = rapture e. EFT_CELEBRATE - causes a city to celebrate if it fulfills the reqs (rather than hard-coded Civ2 triggers). (Features b,c,d together allow soft-coded granular types of bonuses applied to different govs and cities in special contexts, instead of EXTREMELY limited finite set of black/white yes/no boolean mechanics like currently.)

Ticket History (3/5 Histories)

2021-11-04 06:06 Updated by: lexxie9952
  • New Ticket "More ruleset control over Celebration bonus effects" created
2021-11-04 07:15 Updated by: ihnatus
Comment

Reply To lexxie9952

Summary of Feature requests: a. IS_CELEBRATING as a testable req vec >>> (the hard-coded Civ2 condition that celebration = 50% happy with no unhappy. however, see (b) and (c) below for how rulesets could make their own conditions for "celebration" bonuses)

In 3.2, there is "CityStatus", "Celebration", "City" req that handles wether the city is celebrating.

b. MIN_HAPPY_PCT as a req vec - % of a city whose citizens are happy c. MIN_UNHAPPY or MIN_UNHAPPY_PCT - either the % of citizens who are unhappy, or the raw value

Actually, I thought about an extension of "Present" requirement part from a TRUE/FALSE to a more flexible (while still one-byte) one, including positive and negative percentages and some positive and negative raw values. Something like "CitizenMood", "Happy", "City", "50%".

d. MIN_OUTPUT_SURPLUS - allows ruleset soft-coding of conditions for things like rapture or other bonuses, instead of hard-coded to be +1 food + 50% happy + !(unhappy) = rapture

Sorry, don't understand, what with what that req shall do? From the text I get the idea that just a smooth bonus is wanted instead of a big on/off, that I support. But requirements are on/off things by design... With just requirements (b) and (c) we can define some stairs of effects like "Output_Bonus_Pct", and for a smooth thing without bloating of the ruleset code we should probably play somehow with the multipliers mechanism, like, define for that effect

multiplier = "City.Mood.Happy" divisor = "City.Size"

e. EFT_CELEBRATE - causes a city to celebrate if it fulfills the reqs (rather than hard-coded Civ2 triggers).

I won't oppose such a flexibility, just what is asked for here is defining an effect that mostly just governs a requirement to be used elsewhere. Maybe we can do this on a regular basis? Like, "EffectAboveZero" requirement that also e.g. unhardcodes "BadWallAttacker" flag? I speculated on a thing like this here

2021-11-05 05:06 Updated by: lexxie9952
Comment

In 3.2, there is "CityStatus", "Celebration", "City" req that handles wether the city is celebrating.

Wonderful! Great minds think alike.

d. MIN_OUTPUT_SURPLUS - allows ruleset soft-coding of conditions for things like rapture or other bonuses, instead of hard-coded to be +1 food + 50% happy + !(unhappy) = rapture

Sorry, don't understand, what with what that req shall do?

The req shall liberate you from the chains of hard-coded slavery! Each ruleset could now define its own rules for celebration. For example, all current rulesets with Civ2-like celebration reqs:

{effect_city_celebrate}

type = "Celebrate"

value = 1

reqs =

{ "type", "name", "range", "present"
"MinHappyPct", "50", "City", TRUE
"MinUnhappy", "1", "City", FALSE
}

{effect_civ2_rapture_grow}

type = "Rapture_Grow"

reqs =

{ "type", "name", "range", "present"
"Is_Celebrating", "1", "City", TRUE
"OutputSurplus", "Food", "Local", TRUE
"MinSize", "3", "City", TRUE
"Gov", "Despotism", "Player", FALSE
"Gov", "all non rapture govs listed here", "Player", FALSE
}

Maybe in your own ruleset, you want a city to celebrate from some other thing. Maybe what makes one government celebrate is different from another government. Maybe you want the conditions for rapture to be very rare and more difficult to achieve. Maybe you want different conditions for each type of government to achieve it. When the chains of slavery are gone, you can ruleset-code it any way you want.

e. EFT_CELEBRATE - causes a city to celebrate if it fulfills the reqs (rather than hard-coded Civ2 triggers).

I won't oppose such a flexibility, just what is asked for here is defining an effect that mostly just governs a requirement to be used elsewhere. Maybe we can do this on a regular basis? Like, "EffectAboveZero" requirement that also e.g. unhardcodes "BadWallAttacker" flag? I speculated on a thing like this here

I mostly don't understand, but I sense there might be a powerful idea hiding in what you say.

Clever people noticed something different here.

"Is_Celebrating", "1", "City", TRUE

vs "CityStatus", "Celebration", "City", TRUE

the EFT_CELEBRATE has a value to it, which can be 1, or 2, or 3, or 4... then the Is_Celebrating req checks the VALUE of this, so that you can have stage 1 celebration, stage 2 celebration, stage 3 celebration: a "ladder" of granular gradations of bonuses starting small and going higher. Because let's be honest. Gold and Science give a nice quantitative output, but right now, Luxury is only binary or trinary: Disorder,Peace,Celebrate. The future is to make the Luxury dynamic a lot more interesting. It would even allow for crazy ideas like cities that celebrate too much start getting penalties (yes, the famous "too much vodka" penalty. ;) OK that's just a joke, but the ability to do even this, shows how much more powerful is the system I propose here.

2021-11-05 07:04 Updated by: cazfi
Comment

Happiness/Celebration stuff is one thing that should be converted to ruleset driven concept like Culture already is. Culture does not accumulate from hardcoded requirements, but by ruleset controlled effects. It does not have hardcoded effects, but can be a ruleset defined requirement for anything that has requirements. There are a couple of exceptions to make life for ruleset authors a bit easier in some common cases (Achievements have simple culture value - no need to implement full Culture effect with an Achievement requirement. Cultural victory can be defined easily - no need to make Victory effect(s) with complex requirements). There's probably going to be a meta level concept under which Culture and other similar ruleset driven concepts would fall, but I don't have a name for it yet.

Until better support becomes available, ruleset authors may think ways to use Culture to implement some of their goals (esp. if author in question does not consider it a problem that the engine refers the concepts by names "culture" and "history"). Another thing that is probably going to be handy are Counters currently in development, but it's too early to say what will come of them for, say, freeciv-3.2.

2022-11-20 21:58 Updated by: lexxie9952
Comment

I'm bumping this because, we may be approaching the time I'd be able to contribute it. But I wouldn't want to start until everyone felt happy with the realisation details.

Attachment File List

No attachments

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login