So I'm going to try to explain how this flavor costing can work. This is a little tough to explain so if you're trying to follow along, please let me know if I lose you anywhere or even if you fully understand. I will do everything I can to clarify where needed. This is a tough project and the more help I can get on this the better so I can get back to the unit stuff asap because IN GAME the units will have a greater impact on play - but this project will help us to empower Khalig's work on leaders and so many other really really cool projects to come so we have to slog through this.
Ok, so I added this page to the Flavors Update Project document:
https://docs.google.com/spreadsheet...mrcznJPofyWWIrlBx0WtXFP8FU/edit#gid=793504951
It's a page that's dedicated to showing how the traits flavor costing system was INITIALLY established. It is NOT up to date with the longer, expanded flavor list. Khalig is working on that and has nearly completed going through all the complex traits and updating the costing on them but we haven't actually taken the time to update the core costing sheet to reflect how it differs now. We don't really HAVE to because the costing on the traits is manually established on each and every trait rather than automatically assigned and there are points where we, for the sake of some balance precision do things with some human differences between the cost guidelines and what is actually assigned.
Thankfully, flavors on all the other game objects isn't nearly as critical to be 'highly accurate'.
However, the EXAMPLE of how to define a tag value to a flavor is provided on that page.
So we'll do this for other game objects, like Civics. The same basic 3 columns will apply and each row will be one of the tags that apply to that type of object.
Some tags don't even get a value because they don't really contribute to a positive or negative evaluation of the object. So, for example, bImpurePromotions declares the promotion the trait gives to be an impure or pure promotion for the Pure traits game option - it's the promotion itself that then later gives a value so in itself, this tag doesn't influence value, only a later calculation.
Thankfully we don't have a Pure Civics game option so that's not a concern.
However, MOST tags will give a translated value. iHealth, for example, is pretty clearly a benefit for the player when it is at a positive amount. Therefore, the Tag notes designate here that 'Positive is good' and then it also goes on to explain what the tag actually means when it is used on a trait. Then in the 3rd column, it lays forth the flavor that the tag adds value and the amount of flavor value for each point in that tag. Here, it's declaring the flavor value on iHealth is 'Growth' and each point of iHealth = 2 points of Growth flavor.
Again, this is out of date. It would still be 2 pts of flavor value for each point on the iHealth tag assigned, but it's no longer FLAVOR_GROWTH, but FLAVOR_HEALTH that it applies to. This is one reason for the expanded list we're using - too many categories, Growth being perhaps the worst offender, were catchall categories that were handling way more than their share and leading to far less specific leader personality variations.
One can think of flavors as 'game style strategic preferences'. A leader who favors growth would have wanted a trait that gives Health as a higher priority. I'd love to play with more highly varied leader leanings, which is what this project is about. So now, iHealth, in traits, gives +2 points of FLAVOR_HEALTH per point in iHealth.
And that's probably a pretty good guideline for the rest of the game objects. The main point is to make things game value equivalent between the tags. It's a universal translator of value. Yes, this becomes a little difficult without a more dynamic ruleset, though we COULD suggest both a static valuation AND a more dynamic ruleset and give our thought notes on each tag too in later columns not shown on this original document that only I worked on to establish the traits.
For example, in all honesty, each point of health is more valuable at the beginning of the game when each point matters more. +2 health in a prehistoric building is way more potent than +2 health in a transhuman building. Trying to even give both the same flavor value ... well at least flavors don't have to be super accurate in terms of their evaluation. However, if we wanted to say that it would be +3 value per point up through Medieval, +2 value per point up through Information age, and +1 value per point beyond, that kind of dynamic adjusting value is actually very possible for a coded end solution like what we're going to build, so I'm not against those kinds of value suggestions. In fact, the better we think of how to translate these values, the better end result this will have for the AI to even possibly not just VARY their play ability, but it could end up being reflected in a much more accurate system that helps ALL AI to vary its sense of value on things to what it currently identifies it NEEDS.
Thus, if your city has NO unhealth problems, aside from leader preference, perhaps we can, as a result, generically use flavoring to tell the city selection manager to reduce FLAVOR_HEALTH down to a bare minimum in value as it looks for ways to address its current needs first. This could improve our selection system AIs quite a bit, even streamline a lot of granular and specific moments in code evaluations so as to lubricate the intelligence of AI selections AND its speed in coming to conclusions at the same time.
I would be willing to be Jaguar's AI mechanisms would benefit from these kinds of flavor costings (if well considered) as well.
Continuing past the basic example of iHealth, iHappiness would have an identical style of costing except that it would now be giving its value to FLAVOR_HAPPY rather than Health flavor.
Then, taking a look at iMaxAnarchy, we haven't changed the costing routine but we DID change that to FLAVOR_POLITICS. iMaxAnarchy is a funny tag - it limits how many rounds of anarchy the civ can go into as a hard limit for having this tag in use on the trait. You won't see this outside of traits I don't think (MAYBE civics?). The way it was cost was to give a value specifically at each possible assigned value so it's flavor value wasn't a matter of x pts for y pts as most are able to be translated. Thankfully there were only so many possible expressions that could be applied to this tag. And the part that really hurts trying to generalize the value on THIS tag is that it GREATLY depends on the game speed you're playing under as to how valuable it should actually be compared to other tags in use on a trait. And again, without actually giving a really dynamic breakdown there, it was impossible to include gamespeed as a costing consideration at all. You really can't do that for the traits like you can for an autoassignment kind of system like this that could calculate the values at the beginning of a game and look at scaling factors in play because the trait values had to be baked in at trait design rather than determined at gamestart since the point was to compare them during design process.
So I came up with a value of 10 if you were limited to 0 rounds of anarchy with any civic or religion change (10 was what I was considering the value of a truly powerful and potent singular factor), 8 if the maximum was 1 round, 6 for a maximum of 2 rnds and up to 1 for 5+ since anywhere 5 and over is still quite a few rounds of anarchy so it has dissolved into a much less meaningful trait with that sort of loose assignment, only really impacting the much longer gamespeeds. Again, if I could consider gamespeed into the equation, I probably would adjust by this scaling factor somehow.
One thing this points out is that it might be a little tough for now to look at a tag and know which flavor it will or should apply to and as we are expanding the list, some of Khalig and I's discussions are about what tags apply to what flavor and we're still seeing if we can eliminate some of the flavors entirely, like generic FLAVOR_MILITARY, for example, that have been split into more specific flavors.
So one of the goals I will have is not only to list off all the tags on the documents for civics, units, etc... but also to then add another column in here to split up the Flavor and Value a bit so that I can run through and just declare 'this is for this flavor' and maybe give 'why it might be for any of these given flavors and what situations would cause it to vary', for example, a lot of Great People values will go towards specific flavors based on the great people its actually referring to (and a different value entirely if it's not referring to ANY particular great person perhaps).
Determining this costing translation is the effort for now so hopefully you can understand the next steps:
1) I'm giving us a costing page sorta like this one for every game object - note that due to the way we're going to compile flavors onto techs as an end step, techs will be last for this and I'll also be adding flavors to promotions (anything techs can unlock).
2) I'll be listing off ALL tags that can be used on that game object in the first column.
3) I'll then go through and give the flavors that tag should assign to and under what conditions those may vary
4) THEN we can come up with both static and variable formulas for assigning flavor values for the numeric entries on that tag use, the numeric translation of tag assignment to flavor value. The important part here is that all calculations keep the ultimate values in balance with one another. Aka, you don't want to say +1 Health is worth the same to a player generically speaking, as not having any upgrade expense when you upgrade - clearly that ability is way more valuable than a mere +1 Health.
When I get back later today, you'll see a lot more work on this document that I'll be putting in but I wanted to give everyone an opportunity to first understand the project. When we get to #4, I deeply hope that we have quite a few of us that are understanding the goal of determining the math translations here that we can have some insightful discussions on key tags that can help to guide the standards on many other tag value translations.
Does this all make sense? Or am I too deep into gibberish territory?