Expanded Broader Alignments

[Valkrionn]

Very few buildings/units will have large affects. The majority of what you'll see in game is for religions/civics.... And I'm planning to start fresh with civics.

 

[Riot_Starter]

.... And I'm planning to start fresh with civics.

Does this mean what I think it means?? Are you going to redo the civics? If so, I can't wait. I love new shiny things to develop strategies around.

 

[Valkrionn]

Yes it does, that will be done alongside this rework here.

To get an idea of what I'll be doing, check this old mod out: http://forums.civfanatics.com/showthread.php?t=319109

If you check a few posts down, you'll find where I took the time to write up the data from ALL civics he put in.

I won't be doing anything EXACTLY like that, but you get the basic idea... Each civic option has a defined job, and civics within it do that job and only that job. No blob civics, and no ridiculously strong ones... Going for interesting combinations, tough choices.

We WILL have at least two starting civic options, btw.

 

[Valkrionn]

On alignment decay: All alignmentshifts are stored in a separate variable from the standard alignment, so I can decay JUST this value and have your alignment eventually return to the base value if no input is put in. Here's the question, though.... How should I set this up? Constant? Chance each turn for a small shift back? Only after a certain number of turns with no shift? At the moment, I'm thinking the last one, but it's a bit more work.. What do you think?

Edit: Think I'll go with the last one after all. Set it up to use globaldefines, easy to tweak... Currently if your alignment doesn't shift in 5 turns, it'll decay back to the leader's base amount by 5.

 

[Riot_Starter]

A constant decay would be the easiest to do and dial in to a reasonable value. I would start with a decay of the square root of the alignment shift. This means if you shift 100 away (example #, I would need to know the scale and shift numbers to give more accurate examples), then a per turn shift of 10 is needed to stay at a constant 100 away. This combined with the limits of a source should make it so that one can stray easily, but has to make an effort for big deviations.

An addition to this, which is up to you if you want it in, is to change the Base alignment per turn in addition to the alignment shift changing per turn. The Base change could be a small fraction (or some higher power root) of the total current alignment shift. Example: with Base +200 Current Shift +100 Next turn current shift changes by X and Base changes by 4.5 (approximately the cube root of 100). This represents the leader changing over time, but will mean any leader can reach any alignment if they try hard or long enough.

 

[Valkrionn]

A constant decay would be the easiest to do and dial in to a reasonable value. I would start with a decay of the square root of the alignment shift. This means if you shift 100 away (example #, I would need to know the scale and shift numbers to give more accurate examples), then a per turn shift of 10 is needed to stay at a constant 100 away. This combined with the limits of a source should make it so that one can stray easily, but has to make an effort for big deviations.

An addition to this, which is up to you if you want it in, is to change the Base alignment per turn in addition to the alignment shift changing per turn. The Base change could be a small fraction (or some higher power root) of the total current alignment shift. Example: with Base +200 Current Shift +100 Next turn current shift changes by X and Base changes by 4.5 (approximately the cube root of 100). This represents the leader changing over time, but will mean any leader can reach any alignment if they try hard or long enough.

After a bit of thought, I agree. A constant decay, scaling to the AMOUNT of shift, is best. This means you must work harder to get to the extremes... Which is as it should be.

As for changing the base alignment... Not really possible. Best you can do is make yet another stored variable, and use that. The game calculates alignment fresh EVERY turn... At first I wasn't sure of why, but Grey Fox DID have a reason for it. Simplest way to make the effects of civics/religions only take effect when you actually FOLLOW this civics or religions. As a result though, there's no base value for the alignment that you can change easily.

Edit: Looks like I got the decay working... For now, the shift you accumulate each turn is decreased by the square root of the shift, or something approximating it... It's rounded, as it moves from an int (whole number) to float(decimal), takes the sqr root, then back to an int. Won't be EXACT except for perfect squares.

Edit2: Also decided to make a new tracking variable after all. Every few turns (have it at 5) the sqr root of the current total shift will be added to this new variable. Think of it as the permanent shift, not subject to decay.

 

[Riot_Starter]

I look forward to playing with the new system. I liked the idea of BA, but didn't like the previous implementation because most things ended up turning you evil and still felt very static. This one looks to be much more dynamic and hopefully it will end up being balanced on the good-neutral-evil scale.

 

[odalrick]

After a bit of thought, I agree. A constant decay, scaling to the AMOUNT of shift, is best. This means you must work harder to get to the extremes... Which is as it should be.

I'm going to point out the obvious:

Your current plan of having decay proportional to the square root of current shift means that small alignment incomes will have a lesser effect than large alignment incomes.

That is if going from +0 "goodness" per turn to +10 "goodness" will ultimately shift your alignment by +100 (where decay per turn equals -10 "goodness"), then going from +10 to +20 will have a net effect of +300 alignment.

This is possibly intentional; as you get more "goodness" income, it is harder to find additional sources.

If decay is proportional to the square of current shift, then small incomes will have a greater effect. If going from +0 to +10 shifts alignment by net +100, then going from +10 to +20 would shift by +41 . This would be more appropriate if a high alignment means more "goodness" income, for instance by enabling buildings that give "goodness".

If decay is proportional to current shift, then small incomes will have the same effect as large incomes, Going from +0 to +10 and from +10 to +20 will both shift alignment by net +100 .

Having a "banking" effect, permanent alignment shifts, means that any income will eventually take you to the maximum. Also, with a banking proportional to square root of current shift, being slightly Good over a long period will have a greater effect than being very Good for a short time.

If it was me, I'd just write decay as:

(Python code, but there must be some function in C++ that raises a number to an arbitrary power.)

decay = shift_scale * pow( abs(current_shift) , shift_power )

and load shift_scale and shift_power from xml.

To use the current plan of square root shift_power would be set to 0.5 , but more importantly it would be trivial to change to linear (shift_power=1) or square (shift_power=2) or anything.

I also advocate a similar system for the banking effect.

 

[Grey Fox]

None of the values posted are any more than an example.

I used -5 to test the system, because I wanted to make sure it cut out at it's max. Was using the Emperor, so it's only 20 turns of shift to get him to the max there.

Posting examples are always dangerous business

 

[velosepappe]

Some sugestions:

One could divide the alignment into 2 axis, one for the leader and one for the population. The leader axis would represent the basic good-evil, and the population one represents opression (or maybe lawfullness) versus decadence. Population would feel more sympathetic towards states with the same population alignment. This could be used for simulating war weariness (we don't like it that you attack people we can relate to, or "we tolerate this war with the goal to free oppressed people), simulating trade with trade routes to alike people being more profitable,...
I guess that decadent people feel more comfortable around other decadent people, and the oposite lawfull people feel more comfortable around lawfull people, and lawfull people feel sympathetic towards oppressed people and vice versa. Now that i think about it what i propose sure feels a lot like good-evil and lawfull-chaotic, with oppressed people being lawfully evil.

Second one could make alignments more interesting by adding short term diplomatic modifiers for acting out of character. Suppose I have a good alignment and I raze a city. Fellow good leaders have a huge limited term negative modifier "We are shocked by what you did". Evil leaders get the positive modifier: "We see that you are finally joining our side".

Anyway which way it goes, i see that these expanded broader alignments have a lot to add to the game experience.

 

[2Hydroclopse]

Will broader alignments still be optional? If the civic systems --or anything else-- depend to heavily on the new alignment mechanics, then the optionality might need to be removed.

 

[Valkrionn]

I look forward to playing with the new system. I liked the idea of BA, but didn't like the previous implementation because most things ended up turning you evil and still felt very static. This one looks to be much more dynamic and hopefully it will end up being balanced on the good-neutral-evil scale.

That's what I'm hoping, yes.

I'm going to point out the obvious:

Your current plan of having decay proportional to the square root of current shift means that small alignment incomes will have a lesser effect than large alignment incomes.

That is if going from +0 "goodness" per turn to +10 "goodness" will ultimately shift your alignment by +100 (where decay per turn equals -10 "goodness"), then going from +10 to +20 will have a net effect of +300 alignment.

This is possibly intentional; as you get more "goodness" income, it is harder to find additional sources.

If decay is proportional to the square of current shift, then small incomes will have a greater effect. If going from +0 to +10 shifts alignment by net +100, then going from +10 to +20 would shift by +41 . This would be more appropriate if a high alignment means more "goodness" income, for instance by enabling buildings that give "goodness".

If decay is proportional to current shift, then small incomes will have the same effect as large incomes, Going from +0 to +10 and from +10 to +20 will both shift alignment by net +100 .

Having a "banking" effect, permanent alignment shifts, means that any income will eventually take you to the maximum. Also, with a banking proportional to square root of current shift, being slightly Good over a long period will have a greater effect than being very Good for a short time.

If it was me, I'd just write decay as:

(Python code, but there must be some function in C++ that raises a number to an arbitrary power.)

decay = shift_scale * pow( abs(current_shift) , shift_power )

and load shift_scale and shift_power from xml.

To use the current plan of square root shift_power would be set to 0.5 , but more importantly it would be trivial to change to linear (shift_power=1) or square (shift_power=2) or anything.

I also advocate a similar system for the banking effect.

To be honest, I already thought about that and changed the decay to the sqr of the TOTAL shift, not just for that turn. Means the loss is proportional to the distance you move from the original alignment, rather than how quickly you do so.

Let's see if I understand your code, here... What exactly are shift_scale and shift_power? Max each source can bring you, and how quickly? If so, won't work quite that way... Decay is currently done after all the loops, so there's no way to load shift_scale.

As for what you're doing... shift_scale * |current_shift ^shift_power|? Without actually knowing what shift_scale and shift_power are meant to represent, I'm not sure what this will do.

Posting examples are always dangerous business

Apparently so.

Some sugestions:

One could divide the alignment into 2 axis, one for the leader and one for the population. The leader axis would represent the basic good-evil, and the population one represents opression (or maybe lawfullness) versus decadence. Population would feel more sympathetic towards states with the same population alignment. This could be used for simulating war weariness (we don't like it that you attack people we can relate to, or "we tolerate this war with the goal to free oppressed people), simulating trade with trade routes to alike people being more profitable,...
I guess that decadent people feel more comfortable around other decadent people, and the oposite lawfull people feel more comfortable around lawfull people, and lawfull people feel sympathetic towards oppressed people and vice versa. Now that i think about it what i propose sure feels a lot like good-evil and lawfull-chaotic, with oppressed people being lawfully evil.

Second one could make alignments more interesting by adding short term diplomatic modifiers for acting out of character. Suppose I have a good alignment and I raze a city. Fellow good leaders have a huge limited term negative modifier "We are shocked by what you did". Evil leaders get the positive modifier: "We see that you are finally joining our side".

Anyway which way it goes, i see that these expanded broader alignments have a lot to add to the game experience.

Lawful-Chaotic, huh? I plead the fifth.

Will broader alignments still be optional? If the civic systems --or anything else-- depend to heavily on the new alignment mechanics, then the optionality might need to be removed.

Yeah, it will remain optional. You may get some new units/buildings/civics that require a certain alignment... But if BA isn't in, they'll only require the main alignment, not a certain alignment number.

 

[odalrick]

As for what you're doing... shift_scale * |current_shift ^shift_power|? Without actually knowing what shift_scale and shift_power are meant to represent, I'm not sure what this will do.

Moved to the top since this is the only really interesting part of the post:

It's exactly the way you have it set up right now, only you could change decay from square root to square to linear by changing a value in an xml file rather than recompiling the dll. Or you could change it to something like proportional to 4/3 root, just as easily.

It would give you more knobs to turn in order to balance it.

To be honest, I already thought about that and changed the decay to the sqr of the TOTAL shift, not just for that turn. Means the loss is proportional to the distance you move from the original alignment, rather than how quickly you do so.

Yes, I understand that. Since you lose alignment based on the total of how much you have shifted, when the current income equals that loss, you have reached the maximum alignment you can get without increasing income. I was talking about how that maximum alignment is affected by changes in income. Yikes, this is hard to explain. I'll try an example.

When you have an income of 0 "goodness" per turn, your maximum alignment is whatever you started with. If you change to <unnamed minor good religion> you get +10 "goodness" each turn. You you will,eventually, shift to the alignment where you lose -10 "goodness" each turn, let's say that alignment is +100 .

Now consider what happens when you change to <unnamed very good religion>. You get +20 "goodness" each turn. What is the new equilibrium when income balances decay?

If decay is proportional to the square root of current shift, then that point is +400 alignment. (This is your current plan according to your posts.)

If decay is proportional to the current shift, then that point is +200 alignment.

If decay is proportional to the square of current shift, then that point is +141 alignment.

Let's see if I understand your code, here... What exactly are shift_scale and shift_power? Max each source can bring you, and how quickly? If so, won't work quite that way... Decay is currently done after all the loops, so there's no way to load shift_scale.

They have nothing to do with income, they only affect decay.

shift_scale and shift_power would be global constants that are loaded when the civ first starts. Like the standard length of golden ages or the attitude adjustment Neutral civs get to Evil civs or for that matter the strength of a Warrior. They'd need to be floats, so maybe more like how much experience the Hero promotion gives per turn.

decay = shift_scale * |current_shift| ^shift_power

current_shift would be the current total deviation from your base alignment
It needs to be absolute, since otherwise raising it to anything other than even integer values would break things.

shift_power is the power you want decay to scale with. 1/2 for square root as is the current plan.

shift_scale is a fine tuning constant. If you don't have it then 100 alignment can only mean 10 decay. I think you already have it in your code, if nothing else to account for game speed. In the example above shift_scale is 1 . Change it to .5 and the break-even points double. Set it to 0 and there is no decay.

 

[Valkrionn]

Moved to the top since this is the only really interesting part of the post:

It's exactly the way you have it set up right now, only you could change decay from square root to square to linear by changing a value in an xml file rather than recompiling the dll. Or you could change it to something like proportional to 4/3 root, just as easily.

It would give you more knobs to turn in order to balance it.

Gotcha. I thought you meant an xml tag... What you actually meant was a global define. Yeah, that would make it more configurable.

Yes, I understand that. Since you lose alignment based on the total of how much you have shifted, when the current income equals that loss, you have reached the maximum alignment you can get without increasing income. I was talking about how that maximum alignment is affected by changes in income. Yikes, this is hard to explain. I'll try an example.

When you have an income of 0 "goodness" per turn, your maximum alignment is whatever you started with. If you change to <unnamed minor good religion> you get +10 "goodness" each turn. You you will,eventually, shift to the alignment where you lose -10 "goodness" each turn, let's say that alignment is +100 .

Now consider what happens when you change to <unnamed very good religion>. You get +20 "goodness" each turn. What is the new equilibrium when income balances decay?

If decay is proportional to the square root of current shift, then that point is +400 alignment. (This is your current plan according to your posts.)

If decay is proportional to the current shift, then that point is +200 alignment.

If decay is proportional to the square of current shift, then that point is +141 alignment.

Not sure if you're forgetting this, or ignoring it for your posts... There are TWO tags involved here. The speed of the shift, and the value you can shift to. As an example, say Empy gives you a rate of +5, and a max of +300... What the decay is meant to do is force you to work for extra sources of alignment gain in order to get to extreme alignments. So, say, Hyborem is going to be EXTREMELY hard pressed to get up to Good.

They have nothing to do with income, they only affect decay.

shift_scale and shift_power would be global constants that are loaded when the civ first starts. Like the standard length of golden ages or the attitude adjustment Neutral civs get to Evil civs or for that matter the strength of a Warrior. They'd need to be floats, so maybe more like how much experience the Hero promotion gives per turn.

decay = shift_scale * |current_shift| ^shift_power

current_shift would be the current total deviation from your base alignment
It needs to be absolute, since otherwise raising it to non-integer values would break things.

shift_power is the power you want decay to scale with. 1/2 for square root as is the current plan.

shift_scale is a fine tuning constant. If you don't have it then 100 alignment can only mean 10 decay. I think you already have it in your code, if nothing else to account for game speed. In the example above shift_scale is 1 . Change it to .5 and the break-even points double.

shift_scale isn't actually in yet, but it IS planned. Just want to get the rest working before I weight it for gamespeed. I would need a second one for the decay I would think... No reason that caps should be different based on gamespeed.

And as for floats... The defines themselves could be, but the result will be converted to an int. To do otherwise would require rewriting the entire alignment system.

 

[odalrick]

Not sure if you're forgetting this, or ignoring it for your posts... There are TWO tags involved here. The speed of the shift, and the value you can shift to. As an example, say Empy gives you a rate of +5, and a max of +300... What the decay is meant to do is force you to work for extra sources of alignment gain in order to get to extreme alignments. So, say, Hyborem is going to be EXTREMELY hard pressed to get up to Good.

I'm ignoring it, as it doesn't really apply.

Having alignment decay puts a maximum alignment shift based on whatever income you can scrape together. Having Empyrean give a maximum of +300 alignment is just another limit and both work separately.

 

[Valkrionn]

I'm ignoring it, as it doesn't really apply.

Having alignment decay puts a maximum alignment shift based on whatever income you can scrape together. Having Empyrean give a maximum of +300 alignment is just another limit and both work separately.

Not true. The 'permanent' shift was added in expressly to avoid that.

Decay SLOWS the approach as you get to extremes... It can even cause your alignment to stabilize early. However, eventually you'll be able to reach the cap due to the second variable.

Edit: Just to clarify, the way the permanent shift works is this:

Every five turns, an amount equal to the decay is added to the permanent shift variable, and removed from the main alignmentshift variable, which is the one subject to decay. Essentially, small amounts of alignment are slowly made immune to the decay.

 

[odalrick]

Not true. The 'permanent' shift was added in expressly to avoid that.

Decay SLOWS the approach as you get to extremes... It can even cause your alignment to stabilize early. However, eventually you'll be able to reach the cap due to the second variable.

Yes, and if you have a target alignment you want; raising your alignment income is more effective than waiting.

Having a "banking" effect, permanent alignment shifts, means that any income will eventually take you to the maximum. Also, with a banking proportional to square root of current shift, being slightly Good over a long period will have a greater effect than being very Good for a short time.

Sounds pretty good. If you want to be Good you can quickly become Good by doing lots of Good stuff, provided you have a Good heart. If you are Evil hearted, though, you require time is the most important.

 

[Valkrionn]

Yes, and if you have a target alignment you want; raising your alignment income is more effective than waiting.

That is the exact intent here. You can reach a cap provided by a religion EVENTUALLY, even if going from evil to good or good to evil... However, to get there QUICKLY you need new sources. I edited the last post with a description of how the 'banking' works.

Sounds pretty good. If you want to be Good you can quickly become Good by doing lots of Good stuff, provided you have a Good heart. If you are Evil hearted, though, you require time is the most important.

I take it you mean "If you're already good, you can become more good quickly. If you're evil, time becomes the important factor"? If so, exactly that, yes. You'll still get a boost in the proper direction by adopting a religion (probably even the same as it is now, but the actual size of the alignment meter is going from (-511 -> 511) to (-1500 -> 1500). Around three times the size of the current one... Means even if the effect is the same value as now, it's actual effectiveness is reduced), but this boost is temporary. It's not stored over time, it doesn't increase over time, it goes away as soon as you switch religion. The new system is used alongside that.

 

[Riot_Starter]

I tested some numbers in a model I created to see the turn by turn effects of a constant alignment income.

Some observations with square root decay and permanent shift every 5 turns:
- The permanent shift seems high at only square root of current shift. Maybe lower to cube root?
- Some obvious stuff: The end shift of a constant income = income^2. 50-70% of max shift reached in about 15-20 turns. Takes about 150 more turns to reach the final portion.

I'm not sure what kind of balance you want between income, max shift, and time to shift, but this might help you get an idea of the numbers and formulas involved and change w/e needs to be changed.

Edit: After reading the last couple posts (they went up as I was making the spreadsheet), I realize my model is a bit off. I didn't know that you are taking temporary shift and making it permanent, I thought it was a simple addition. Finally knowing the scale makes the numbers fit much better, since an income of 20 isn't an instant evil to good like it would have been on the old scale. I'm going to fix the model to satisfy my own curiosity, but I can repost it if you like.

 

[Valkrionn]

I tested some numbers in a model I created to see the turn by turn effects of a constant alignment income.

Some observations with square root decay and permanent shift every 5 turns:
- The permanent shift seems high at only square root of current shift. Maybe lower to cube root?
- Some obvious stuff: The end shift of a constant income = income^2. 50-70% of max shift reached in about 15-20 turns. Takes about 150 more turns to reach the final portion.

I'm not sure what kind of balance you want between income, max shift, and time to shift, but this might help you get an idea of the numbers and formulas involved and change w/e needs to be changed.

Permanent shift will be reduced. Couldn't find a way to specify the POWER of the root (cube, so on), but using the formula Odalrick posted I can do that easily.

What program does that run on?