Do you folks think happiness is to harsh this version 2.7?

[Recursive]

My current plan is to:
- Remove the huge modifier from tech entirely
- Make the city size modifier negative again, and use that to balance tall/wide instead of using tech (or base it on empire population / # of cities, or something like this - not sure yet)
- Use the 50th percentile instead of the 55th percentile

 

[mrpilhas]

It just hurts Progress even more. It sucks choosing the "wide" tree and being locked on 3 cities on turn 80 because happiness.

 

[CppMaster]

It just hurts Progress even more. It sucks choosing the "wide" tree and being locked on 3 cities on turn 80 because happiness.

What? In my last game I was playing Progress and rushed 7 cities, so it's doable. Sure, my happiness was about 35% in medieval, but as long as I kept it over 35% it was alright, so you are definitely not locked on 3 cities, lol.

 

[nekokon]

Yes, you can. That is simply playing safe. It's a good decision when unhappiness occur and bad otherwise. Just like you build defensive structure just in case someone attacks you. It's like an insurance policy that has it's cost.

That's a very irresponsible design. Instead of simply giving ppl the tool to solve the problem when it pops up, you're telling them to either pay a big chunk of money for insurance or take the loss when it hits ?
Strategy lies in using what tools you have at your disposal to take care of unexpected problem, not to pick a safe or risky playstyle then go with it all the way disregarding any potential change simply because you already bought your insurance (or choose to just take the loss)

 

[CppMaster]

Strategy lies in using what tools you have at your disposal to take care of unexpected problem, not to pick a safe or risky playstyle then go with it all the way disregarding any potential change simply because you already bought your insurance (or choose to just take the loss)

Strategy absolutely lies also in picking safe or risky playstyle. Why wouldn't it? And you don't have to disregard anything.

 

[nekokon]

That's not strategy when you pick a path before knowing what's ahead, it's railroading at best (if you know what you're starting with) or just gambling (if you don't even know what you have).
And if you don't have the tool to solve new problem popping up on the way there's no other action you can make (you simple don't have the tool) thus the only choice is to just disregard it and keep going. It's just bad game design.

 

[Recursive]

My current plan is to:
- Remove the huge modifier from tech entirely
- Make the city size modifier negative again, and use that to balance tall/wide instead of using tech (or base it on empire population / # of cities, or something like this - not sure yet)
- Use the 50th percentile instead of the 55th percentile

Change of plans:
- Remove the huge modifier from tech entirely
- Remove the city size modifier entirely
- Use the 50th percentile instead of the 55th percentile
- Remove all % modifiers to needs and replace them with -1 Unhappy per -10%, for less kludge
- Playtest, and the community can make adjustments from there

 

[CrazyG]

Change of plans:
- Remove the huge modifier from tech entirely
- Remove the city size modifier entirely
- Use the 50th percentile instead of the 55th percentile
- Remove all % modifiers to needs and replace them with -1 Unhappy per -10%, for less kludge
- Playtest, and the community can make adjustments from there

I LOVE this direction

 

[Zanteogo]

I think it's just slightly too harsh in the current version.
I don't know if we need to redo the whole happiness system. It took forever to get it the way it is now. I would just turn it down slightly as right now I'm always right on the edge of revolts regardless of what I do.

 

[CppMaster]

Remove all % modifiers to needs and replace them with -1 Unhappy per -10%, for less kludge

I don't understand

That's not strategy when you pick a path before knowing what's ahead, it's railroading at best (if you know what you're starting with) or just gambling (if you don't even know what you have).

Every high level decision is part of a strategy. Deciding to play safe or risky included.

And if you don't have the tool to solve new problem

What do you mean you don't have the tool? Which tool do you have in mind?

 

[Recursive]

I think it's just slightly too harsh in the current version.
I don't know if we need to redo the whole happiness system. It took forever to get it the way it is now. I would just turn it down slightly as right now I'm always right on the edge of revolts regardless of what I do.

New formula demands new modifiers. A few more iterations and we should be good.

 

[nekokon]

I don't understand


Every high level decision is part of a strategy. Deciding to play safe or risky included.

What do you mean you don't have the tool? Which tool do you have in mind?

The tool here is able to quickly affect happiness rather than having to wait for it to slowly change in your model. For example if you're currently unhappy and want to get enough happiness to be able to settle, if you're able get extra lux/happiness from any other sources (other civ has extra lux, you got ally with a CS, you meet new civ,...) you can solve your issue right away and settle instead of sitting tight and wait until your happiness slowly crawl up, and that's can result in losing a city location.
Ok bad example since they're not entirely city's happiness but global happiness, a better one would be you got a new TR opportunity or gaining new tech or GP/improvement which increases city yield/happiness.

 

[CppMaster]

The tool here is able to quickly affect happiness rather than having to wait for it to slowly change in your model. For example if you're currently unhappy and want to get enough happiness to be able to settle, if you're able get extra lux/happiness from any other sources (other civ has extra lux, you got ally with a CS, you meet new civ,...) you can solve your issue right away and settle instead of sitting tight and wait until your happiness slowly crawl up, and that's can result in losing a city location.
Ok bad example since they're not entirely city's happiness but global happiness, a better one would be you got a new TR opportunity or gaining new tech or GP/improvement which increases city yield/happiness.

But changes to unhappiness would be instant. I was only talking about smoothing changes to needs. So would still be able to solve the issue immediately.

 

[nekokon]

Hmm, I missed the part where you referring only to need instead of happiness. My bad.
If that's the case then probably there won't be a lot of changes to decision making, aside from the fact needs still get recalculated every turn for each city (costing extra cpu load) and players still need to check them periodically instead of having a constant reminder (x turns until growth). I would still prefer the current simpler method as I'm not sure if smoother needs would change anything while costing extra efforts.

 

[CppMaster]

I usually only pay attention to a city when I choose production or assign citizen and I think I'll continue so. Removing the rule would make it more fluid and natural, which I prefer than arificial and gamey.

 

[Bruhmoment]

The poll votes are a perfect tie - is a change warranted, or will it remain as is?

 

[josh4]

It was not a proposal so it is not binding for the devs, I was just curious.

Recursive in the other thread said it will be changed to a middle ground between old and the new system, slightly easier in total than in 2.7.3, which I'm fine with.

 

[Recursive]

It was not a proposal so it is not binding for the devs, I was just curious.

Recursive in the other thread said it will be changed to a middle ground between old and the new system, slightly easier in total than in 2.7.3, which I'm fine with.

Happiness may be significantly easier after the rework because I'm removing a lot of math that isn't user friendly from the calculation (remnants of the old system which relied on magic numbers). But the point of the change is not to produce the one best happiness system, it's to return it to a state that isn't broken (i.e. needing 20+ Public Works and not being able to break even) and add more levers we can use to experiment with happiness.

With community feedback and/or proposals and/or testing, a few more iterations of changes and we should be in a good place with happiness. We're close.

 

[CppMaster]

@Recursive is the median for needs calculated with AI bonuses included or before? Because inclusion of AI bonuses would make unhappiness harder on higher difficulties. Is that intended?

 

[Recursive]

@Recursive is the median for needs calculated with AI bonuses included or before? Because inclusion of AI bonuses would make unhappiness harder on higher difficulties. Is that intended?

Before.