New Population Growth Mechanic [ACCEPTED]

[MrNulll]

They are still going to impact the "Food Kept" after Growth. There is no change needed to the effects of Corn Chambers and Granaries.
Food is still required and consumed by Growth - it is just not the only factor anymore if this concept would be implemented.

That is why this condition also still applies:

------

I never said that Growth would not cost Food anymore - it still will.
Just the "triggering of Growth" will get an extra condition.

Otherwise the balancing of Food in the mod would be completely messed up.
(It would lose a lot of its gameplay value and players would hardly know what to do with all the unused Food.)

------

But maybe there was a misunderstanding somewhere.
(My main intention is simply to prevent "Food bombing exploit".)

I think this concept is very close to perfect. Would the growth points be visible to the player? I think that would be important. And if so, how would it be presented?

 

[ArchdukeLiet]

I think the new food system is a great improvement. It certainly should be in the mod as a default for WTP in my opinion, as it deepens the game - just like the mod does with mostly all aspects of the game.

If an option can be created to use the old system and if that is not too much work, probably that is even better. It allows everyone to enjoy the game the way they like it most.

 

[raystuttgart]

I thought about this again considering gameplay and how the player would / could make the most interesting decisions.
I indeed adjusted the "Food Growth Threshold" by City Population now as @devoultion suggested.

Growth Points >= Growth Threshold **
AND
Food Stored >= Food Growth Threshold ***

With this being true for the Thresholds:
Food Growth Threshold = Growth Threshold + City Population

Reason for this is that it gives an interesting strategic choice.

A) Small Cities: slower Growth for less Food consumed
B) Large Cities: faster Growth for more Food consumed

Or in other words:

Large Cities will provide much more possibility to grow fast because they have higher population.
But it is just more costly and requires more food to be supplied or produce to do so.

Thus if the player does not need citizens very fast he may opt for Growth in small Cities.
It may be slower but it will also require less food and in the end potentially produce more citizens overall.

So it is a decision of:

Faster vs. More

-----

This should give a really interesting gameplay.

 

[raystuttgart]

Would the growth points be visible to the player?

Yes of course.
Just like the current Growth information.

And if so, how would it be presented?

I would it put it also in CityScreen.
And also in Mouse-Over Information of City.

 

[MrNulll]

'Growth points' sounds not that great, do you agree?

I can't think of a better term at the moment, but surely someone can come up with a better term. What would you want to describe this term in German?

 

[raystuttgart]

'Growth points' sounds not that great, do you agree?

The best term would actually be "Growth", but it is already used for the "Birth" of a Citizen.
(Also in the code it would be confusing if I would call it the same.)

Also the term "Growth Points" makes it clear and understandable that it is required for "Growth".
And calling it something else may again be confusing and misleading.

In the game we also have "Founding Father Points" and "Immigration Points" and "Great General Points".
Nobody ever complained about those either. So why should "Growth Points" be problematic then.

Summary:
I think "Growth Points" is the most accurate and easiest to understand.
(I rather keep it clear and obvious than end up with a mismatching or confusing term.)

 

[MrNulll]

Because of nuance, Ray.

Growth points sounds like someone has something unfortunate growing out of them. It might work as a literal translation, but it doesn't work here. People will see it and think wtf?

 

[raystuttgart]

People will see it and think wtf?

Why should players ever care how I call variables of the algorithm internally in C++ code, Python Code or XML?
You are totally confusing / mixing the internal coding now with what is displayed to the player in UI.

Internally in C++ code it may be called iGrowthPoints. And in technical discussions of modders it may also be called "Growth Points".
But in the UI for the player it may be abstracted as an Icon like e.g. a Baby Icon or a Green Arrow Icon or ... I just don't know yet.

Just like Founding Father Points in the UI are also abstracted as Icons.
Or like the Immigration Points in the UI are also abstracted as Icon.
Or like the Great Genral Points in the UI are also abstracted as Icon.
Or like the Revolutionary Rate in the UI is also abstracted as Icon.
...

-------

So can we please stop wasting our time about how I call technical variables in the code?
(Because especially in the code variable naming should be very clear and precise to avoid misunderstandings.)

Because for the player it will really make no difference in gameplay, since he will just see e.g. a Baby Icon in UI.
(And please let us now also not start endless detail discussions about which Icon should be chosen - we will see what looks best.)

 

[MrNulll]

I'm a player and I care very much about your variables thank you very much. Don't blind me with your C++. not impressed Been there done that.

I may have confused your variables with the player UI but my intentions were genuine and friendly. Hey what can I say? I'm an idiot. Nice to meet you

 

[raystuttgart]

... but my intentions were genuine and friendly.

I never said that your intentions were not genuine and friendly.
Otherwise I would also not have continued the discussion.

Hey what can I say?

Sorry, but I just took the time to explain a misunderstanding and end a discussion instead of having to invest even more time into it.
And yeah I admit it, I was a bit annoyed because I was busy which is probably the reason why the explanation sounds a bit sarcastic.

-----

But still I never wanted to be impolite. So please excuse if you felt attacked. I didn't mean it.
Also I am German and I may tell what I think a bit more directly especially if I am annoyed.

 

[raystuttgart]

Ok, I consider this feature as "Accepted" now.
(We have about 80% approval rate now - also counting the ones for "as Option in GlobalDefinesAlt".)

However:

1) I do not plan to still implement this in Release 4.0 (aka "New Hope") - it is a feature for Release 4.1 (no working title yet)
2) To make "everybody happy" I will implement it to be deactivatable in GlobalDefinesAlt.xml (at least until it has proven itself - then maybe the Option will be abandoned) **

------------------------------------------

** Remark on why "Optional Implementations" are bad for game design:

Implementing this as an Option in XML now brings problems with it, thus I want to abandon it eventually once people trust that it is fun.
e.g. as long as it is "optional" it is not possible to e.g. create Traits (e.g. for Nations or Founding Fathers) or Civics or other Features on top.

Just so people are aware what impacts the decision "Option" actually has for game design:
It means "do not use this to create anything else" - because the player may deactive it and break what you build on top!

For some reason people always scream "Make it an Option ! Make it an Option !" - thinking that this is the "best solution possible" - which it is not!
"Implementing as Option" is not the "best solution possible" because it kind of eliminates all creativity to use it in combination with something else.

------------------------------------------

Just imagine e.g. you would marry "optionally" - it would make a great base for having children, right?
Just imagine e.g. you would be hired "optionally" - it would make a great base to get settled, right?

With implementing features "optionally" it is pretty much the same ... nothing can be built on it.
It is a workaround that actually shows poor trust ... potentially to be used however to build that trust.

------------------------------------------

Summary:

I will make it an Option on GlobalDefinesAlt.xml first, but I hope that feedback of Release 4.1 will show that the Option can be abandoned again.
(This had e.g. also happened with the Option to support "Old Storage System" of Vanilla which continuing to support was also just a waste of time and effort.)

Then maybe in Release 4.2 it will be possible to use this feature to create more content with it. (e.g. Traits for Nations or whatever other ideas we have).
For the future - once it has proven itself - I plan to make this a "core mechanic of the mod" just like e.g. Happiness or Health that other mechanics can build on.

 

[modmod]

** Remark on why "Optional Implementations" are bad for game design:

Implementing this as an Option in XML now brings problems with it, thus I want to abandon it eventually once people trust that it is fun.
e.g. as long as it is "optional" it is not possible to e.g. create Traits (e.g. for Nations or Founding Fathers) or Civics or other Features on top.

Just so people are aware what impacts the decision "Option" actually has for game design:
It means "do not use this to create anything else" - because the player may deactive it and break what you build on top!

For some reason people always scream "Make it an Option ! Make it an Option !" - thinking that this is the "best solution possible" - which it is not!

Or the reason of:
Why was I sticked first with TAC for long before changed to RAR.
And why stick with RAR for even longer.

When someone don`t fully agree with a certain feature obviously there is even less chance to agree with one which built upon that.

So it is the reason why folks scream: "Make it an Option ! Make it an Option !"

When there are tons of good and tons which gets deactivated still works.