Thunderbrd
C2C War Dog
C2C Categories
Categories is a new game object that can be defined in our XML in CategoryInfos.xml in the Assets/XML/GameInfo folder.
You can setup any amount of categories you wish, but I do suggest that we should be sure there is good reason to do so. You can even define categories for categories to be categorized by so as to be able to group selections of categories.
This may seem arbitrary, and based on the current coding, really is. We currently aren't even showing objects as belonging to the categories assigned to them in the pedia (though I'd like to make that a goal very soon because it will really help to deliver the usefulness of this mechanism on the player-facing side of the game.)
At the moment, we can just define categories and what goes in them and the game will track that and from there, with further programming, we can make that a significant factor anywhere in the code or rules we wanted the category for.
Categories can apply to NEARLY any game object - and it's not difficult to add to any further game objects we may wish, like gameoptions for example.
Right now they can be applied to:
Categories
UnitCombats
Promotionlines
Traits
Corporations
Religions
Projects
Terrains
Features
Routes
Builds
Civics
Units
Promotions
Techs
Specialists
Bonuses
Buildings
Improvements
The really interesting thing about C2C Categories is that a Bonus can be placed in the same category as a Building or a Unit or any other type of game object mentioned above.
So when we DO add a page to the pedia that shows the category list and then when a category is selected, displays the objects within that category, it will need to show each of those game object types and what exists within that category, probably just something we can scroll through I'm thinking.
WHY though? What is this even for?
There are a few immediate needs I'm considering here and ultimately it's my hope that although there may end up being numerous new vectors to help us sort by specific categories in a super-fast cached loop rather than a lot of the very lengthy loops we currently have in use (so... speeding up the end turns eventually), which adds potentially quite a lot of data usage in a highly limited environment (BAD), we may be able to find ways to streamline some tag usage thanks to these as well.
Here are the main problems I hope to set us up to solve:
1) LOOOOOONG lists of objects in a tag display.
Here's a great example - in the Agricultural Trait, we have 2 tag displays showing the problem perfectly.
The first is a +50% modifier to worker speeds when they 'Build Farm', 'Build Mushroom Gatherer', etc...
And the 2nd is the +20% Production of 'Artesian Well', 'Bakery', 'Chinampa', etc...
Both of those lists of Builds and Buildings go rather on and on and as C2C grows and expands it makes it harder and harder to keep those lists completely pertinent to what we currently have in our Builds and Buildings assets. New Buildings that should be included in that +20% Production are often forgotten to be included when created because this list was defined at the time that the Agricultural Trait was defined and the maker of the new building is not thinking, nor wanting to even be distracted by, what Traits may apply to this new building (there's a lot of traits to think through!)
That and as a player, just reading through this list requires the patience of a saint and nobody's going to want to memorize this crap so generally, what happens in the player's mind is, 'ok so a lot of buildings of this 'type' of building get a bonus, cool'.
When you then look at the hover tooltip on this sort of display, the tooltip goes screaming off the margins of the page and makes it hard to even know what the trait even does (poor example with this particular trait in that we can assume a lot about Agricultural) and when this happens, far MORE pertinent details tend to get lost because the mind has to go on scan mode and the more important things may not even be where you can see them now.
Categories can help here because we can then categorize all these builds and buildings as 'Agricultural Type Objects'. Now, we could put all the builds in an 'Agricultural Builds' category and all the BuildINGS in an 'Agricultural Buildings' category each to their own OR we could lump them together into the same category entirely - honestly whether we want to do one or the other is more a matter of how we want to work with the cached vector lists in these cases - I would think it might be better to have them in categories of their own types BUT the potential for a crossover, if useful, is there. In fact, one can even create 3 categories, one for just the Agricultural Builds, one for Agricultural Buildings, and one that actually is for all objects of an Agricultural type.
By organizing into these categories, right now it doesn't mean we can just then use XML alone to replace that long list here - it WILL take programming to convert the way the tag works - but once a new tag that can refer to the influenced objects by category is created, such as, in this example, <WorkSpeedModifierbyCategoryTypes> and <ProductionSpeedModifierbyCategoryTypes>, then nested within those tags you could include any referenced category and the integer to refer to the modifier amount, then we'd be able to eliminate a long list of XML referred to objects, referring to them instead through the category selection.
Game facing, the Trait here would then read:
* +50% modifier to worker speeds when they build 'Agricultural Type Builds'.
and
* 20% Production of 'Agricultural Type Buildings'
Much more succinct. Much easier for the player. Much easier for the game to display in tooltips without being overwhelmed.
The downside of this is that it's going to take a LOT of work to gradually convert tags to being able to be referred to by category, a lot of work to categorize into referred to categories, such as our building list, and so on. So as players and modders, be patient, this is not going to happen overnight!
It would be truly cool though if we would be able to determine how to link to a category page wherever that category is referred to in the pedia so that the player can get the full list whenever they wish (and it surely will be a lot easier to see!)
Further, we should be able to get the objects on their own pages to indicate their categories in the pedia so you can look at it from either direction. You may know that your leader is Agricultural and influences build speeds on Agricultural buildings, but you may wonder if a building is categorized as that when you're looking at the building and it'd be nice to be able to see that looking at the building as well rather than just finding the list of Agricultural Buildings by the category list.
C2C has long struggled with these giant lists - this can be our endgame solution to that BIG problem we have always had as a LARGE mod.
2) Game Rules by Category
We already have a lot of ways in this mod to categorize things. Used to be building classes and unit classes were ways to place Unique Units and Buildings into mini-categories of a sort and have a replacement mechanism in place until we eliminated that hierarchy architecture which was a wonderful change for the mod as it streamlined a lot of building search calls and so on.
We have SpecialBuildingTypes and UnitCombats - all also categorization mechanisms. Quite a few. I don't necessarily want to use this system to eliminate those or override them though perhaps years from now we may decide there's a huge benefit to doing so - there are tags on those object classifications and we don't want to make Categories have to maintain a lot of tags of their own so as not to allocate unnecessary data storage on a ton of objects those tags don't apply to (though perhaps we can use categories to somehow indicate whether some tags would apply to a category of objects or not... maybe.)
However, it can STILL be very useful to have categories to help us shape certain game rules.
One of the birds I want to kill with this stone is the categorization of UnitCombat types so that I can create some gamerules that enforce a better game balance and do it in a way that is completely player facing and explained.
For one example, there are some UnitCombat types that should never be allowed to have multiple of those within a given category applied to the same unit. A mammal should never also be a fish.
Then there are the original primary actual COMBAT type definitions of unitcombats that you CAN have multiple types of within that category BUT to do so kinda messes up the game balance on those units. For example, recently a particular Melee AND Mounted unit has been pointed out to be far too powerful because by the time you can build it, as a unit it's fairly cheap to be able to get BOTH the XP amount the city is giving to Melee and the amount the city is giving to Mounted, making the Mounted ONLY units much weaker in the end because they get so much less XP (even though they are actually more advanced and stronger.) So by placing those Primary Combat Unitcombat types into a defined Primary Combat category, I can say, ONLY assign the average XP of the two (or maybe the MAX XP of the two or even the MIN XP of the two depending on how gameplay works out to show what is more 'fair') or more unitcombats this unit may have from within the Primary Combat category, without eliminating the benefit they would get from being a Combatant (a very different category of UnitCombat type) that is entirely intended to be an additional amount that ALL Combatants get.
(Yes, this is a very important rule change that's pending here to address a major balance bug I was kinda hoping I wouldn't have to fix but yeah - it's needed.)
A similar issue exists with multiple types of unitcombats within a given category and the production modifiers that are adding up - this is also a part of how that said Melee/Mounted unit is heavily imbalanced - because it's getting the sum of both worlds rather than an average, minimum or maximum between those two.
Also combat modifiers need to be considered to this end as well.
Anyhow, the point is, by categorizing UnitCombats into their own categories, I can resolve these kinds of gamerule situations - and I've been considering them categorized since we've had multiple unitcombat types on units - it just hasn't been an actual game definition no matter how badly it's been needed to be.
3) This makes it possible for me to build an automatic 'Flavoring' mechanism for the AI to assign flavoring based on tags that refer to objects but don't otherwise have a way to say that tag means it should be calculating to a particular 'flavor'.
This is where I realized it's time to do this now because as some of you know, that's a current and immediate project to address. I hit the point where I was trying to figure out how I could get a +2 adjustment to the birth rate of a Prophet in all cities to be able to equate to adding value to the Religious flavor, for example, or how the same tag might work if it was being used to get a +2 adjustment to a Great General... hmm. So now I can categorize specialists in a way that allows me to assign a flavor to them based on that category. I will be adding a Flavor selection tag to the category object as one of my next tasks. Then I have the information I would need to define the flavoring system in the dll functions much easier. And this means the potential for MASSIVE benefits to the AI programming.
4) Superfast looping improvements - a huge benefit to turn time processing potentially
When used to cache objects into smaller more pertinent loops, we may be able to strongly enhance our game processing speed - though this could be problematic for memory if we overuse it so its to be applied only when absolutely necessary I think.
5) Multi-object groupings may lead to simplification of some tags.
Example: +20% Production of Agricultural Type Objects.
This would mean that if you have a wonder, a standard building, a unit, or a project, indicated in the singular category of: Agricultural Type Object, that one player tag can count for all of the above rather than having to have multiple tags - one for each game object type (such as +20% Production of x,y,z, units and then +20% Production for x,y,z buildings, and so on.)
THIS, over time, could mean a significant MEMORY savings when applied to eliminate unnecessary tags. This could be very big where you have things like terrains AND features where both can simply be indicated by a category that groups them rather than having Terrain Combat Modifiers and Feature Combat Modifiers. You could even lump in promotions and unitcombats into the one common form tag usage of a singular Category Combat Modifiers tag.
6) Can help us to correct problems that stem from many sub-types of the same object
Civ IV had a Forest Terrain. C2C has some 5 or 6 different TYPES of forest terrains. This is a little problematic and this category system can help us solve the problem by allowing us to define all those Forest Types in a unifying category.
This means potential AI valuation improvements, such as in promotion selections where it is summing up all the +15% Combat Modifiers listed for each and every Forest Terrain type individually, making it difficult, with so many forest types, to get a forest based promotion to have the same value as one that gives the same benefit to Hill combat.
There's probably a LOT more even still. We might be able to entirely eliminate some other classes and rewrite the code to just work with a vector stored list that represents that class by defined categories within a category. I'm thinking of how this might streamline multi-map issues and the MapCategory class which it may be able to replace.
That said, we need to consider every step for the best course of action at the time and for now, it's those main solves I've mentioned that I'm looking for this to help with.
If you're a modder, however, be considering how you may be able to use this mechanism to your benefit. I would imagine the really strong programmers could give us some feedback on how to best use this and how to best NOT use this as well. I'm interested in hearing ALL of those warnings and bits of advice. I think this can be used for great things for us, but if misused could be very badly abused as well.
Hopefully, before long, players will be able to gradually see major improvements in some problematic areas of the mod thanks to this project!
Anyhow, this is a thread and feedback from any and all is welcome!
Categories is a new game object that can be defined in our XML in CategoryInfos.xml in the Assets/XML/GameInfo folder.
You can setup any amount of categories you wish, but I do suggest that we should be sure there is good reason to do so. You can even define categories for categories to be categorized by so as to be able to group selections of categories.
This may seem arbitrary, and based on the current coding, really is. We currently aren't even showing objects as belonging to the categories assigned to them in the pedia (though I'd like to make that a goal very soon because it will really help to deliver the usefulness of this mechanism on the player-facing side of the game.)
At the moment, we can just define categories and what goes in them and the game will track that and from there, with further programming, we can make that a significant factor anywhere in the code or rules we wanted the category for.
Categories can apply to NEARLY any game object - and it's not difficult to add to any further game objects we may wish, like gameoptions for example.
Right now they can be applied to:
Categories
UnitCombats
Promotionlines
Traits
Corporations
Religions
Projects
Terrains
Features
Routes
Builds
Civics
Units
Promotions
Techs
Specialists
Bonuses
Buildings
Improvements
The really interesting thing about C2C Categories is that a Bonus can be placed in the same category as a Building or a Unit or any other type of game object mentioned above.
So when we DO add a page to the pedia that shows the category list and then when a category is selected, displays the objects within that category, it will need to show each of those game object types and what exists within that category, probably just something we can scroll through I'm thinking.
WHY though? What is this even for?
There are a few immediate needs I'm considering here and ultimately it's my hope that although there may end up being numerous new vectors to help us sort by specific categories in a super-fast cached loop rather than a lot of the very lengthy loops we currently have in use (so... speeding up the end turns eventually), which adds potentially quite a lot of data usage in a highly limited environment (BAD), we may be able to find ways to streamline some tag usage thanks to these as well.
Here are the main problems I hope to set us up to solve:
1) LOOOOOONG lists of objects in a tag display.
Here's a great example - in the Agricultural Trait, we have 2 tag displays showing the problem perfectly.
The first is a +50% modifier to worker speeds when they 'Build Farm', 'Build Mushroom Gatherer', etc...
And the 2nd is the +20% Production of 'Artesian Well', 'Bakery', 'Chinampa', etc...
Both of those lists of Builds and Buildings go rather on and on and as C2C grows and expands it makes it harder and harder to keep those lists completely pertinent to what we currently have in our Builds and Buildings assets. New Buildings that should be included in that +20% Production are often forgotten to be included when created because this list was defined at the time that the Agricultural Trait was defined and the maker of the new building is not thinking, nor wanting to even be distracted by, what Traits may apply to this new building (there's a lot of traits to think through!)
That and as a player, just reading through this list requires the patience of a saint and nobody's going to want to memorize this crap so generally, what happens in the player's mind is, 'ok so a lot of buildings of this 'type' of building get a bonus, cool'.
When you then look at the hover tooltip on this sort of display, the tooltip goes screaming off the margins of the page and makes it hard to even know what the trait even does (poor example with this particular trait in that we can assume a lot about Agricultural) and when this happens, far MORE pertinent details tend to get lost because the mind has to go on scan mode and the more important things may not even be where you can see them now.
Categories can help here because we can then categorize all these builds and buildings as 'Agricultural Type Objects'. Now, we could put all the builds in an 'Agricultural Builds' category and all the BuildINGS in an 'Agricultural Buildings' category each to their own OR we could lump them together into the same category entirely - honestly whether we want to do one or the other is more a matter of how we want to work with the cached vector lists in these cases - I would think it might be better to have them in categories of their own types BUT the potential for a crossover, if useful, is there. In fact, one can even create 3 categories, one for just the Agricultural Builds, one for Agricultural Buildings, and one that actually is for all objects of an Agricultural type.
By organizing into these categories, right now it doesn't mean we can just then use XML alone to replace that long list here - it WILL take programming to convert the way the tag works - but once a new tag that can refer to the influenced objects by category is created, such as, in this example, <WorkSpeedModifierbyCategoryTypes> and <ProductionSpeedModifierbyCategoryTypes>, then nested within those tags you could include any referenced category and the integer to refer to the modifier amount, then we'd be able to eliminate a long list of XML referred to objects, referring to them instead through the category selection.
Game facing, the Trait here would then read:
* +50% modifier to worker speeds when they build 'Agricultural Type Builds'.
and
* 20% Production of 'Agricultural Type Buildings'
Much more succinct. Much easier for the player. Much easier for the game to display in tooltips without being overwhelmed.
The downside of this is that it's going to take a LOT of work to gradually convert tags to being able to be referred to by category, a lot of work to categorize into referred to categories, such as our building list, and so on. So as players and modders, be patient, this is not going to happen overnight!
It would be truly cool though if we would be able to determine how to link to a category page wherever that category is referred to in the pedia so that the player can get the full list whenever they wish (and it surely will be a lot easier to see!)
Further, we should be able to get the objects on their own pages to indicate their categories in the pedia so you can look at it from either direction. You may know that your leader is Agricultural and influences build speeds on Agricultural buildings, but you may wonder if a building is categorized as that when you're looking at the building and it'd be nice to be able to see that looking at the building as well rather than just finding the list of Agricultural Buildings by the category list.
C2C has long struggled with these giant lists - this can be our endgame solution to that BIG problem we have always had as a LARGE mod.
2) Game Rules by Category
We already have a lot of ways in this mod to categorize things. Used to be building classes and unit classes were ways to place Unique Units and Buildings into mini-categories of a sort and have a replacement mechanism in place until we eliminated that hierarchy architecture which was a wonderful change for the mod as it streamlined a lot of building search calls and so on.
We have SpecialBuildingTypes and UnitCombats - all also categorization mechanisms. Quite a few. I don't necessarily want to use this system to eliminate those or override them though perhaps years from now we may decide there's a huge benefit to doing so - there are tags on those object classifications and we don't want to make Categories have to maintain a lot of tags of their own so as not to allocate unnecessary data storage on a ton of objects those tags don't apply to (though perhaps we can use categories to somehow indicate whether some tags would apply to a category of objects or not... maybe.)
However, it can STILL be very useful to have categories to help us shape certain game rules.
One of the birds I want to kill with this stone is the categorization of UnitCombat types so that I can create some gamerules that enforce a better game balance and do it in a way that is completely player facing and explained.
For one example, there are some UnitCombat types that should never be allowed to have multiple of those within a given category applied to the same unit. A mammal should never also be a fish.
Then there are the original primary actual COMBAT type definitions of unitcombats that you CAN have multiple types of within that category BUT to do so kinda messes up the game balance on those units. For example, recently a particular Melee AND Mounted unit has been pointed out to be far too powerful because by the time you can build it, as a unit it's fairly cheap to be able to get BOTH the XP amount the city is giving to Melee and the amount the city is giving to Mounted, making the Mounted ONLY units much weaker in the end because they get so much less XP (even though they are actually more advanced and stronger.) So by placing those Primary Combat Unitcombat types into a defined Primary Combat category, I can say, ONLY assign the average XP of the two (or maybe the MAX XP of the two or even the MIN XP of the two depending on how gameplay works out to show what is more 'fair') or more unitcombats this unit may have from within the Primary Combat category, without eliminating the benefit they would get from being a Combatant (a very different category of UnitCombat type) that is entirely intended to be an additional amount that ALL Combatants get.
(Yes, this is a very important rule change that's pending here to address a major balance bug I was kinda hoping I wouldn't have to fix but yeah - it's needed.)
A similar issue exists with multiple types of unitcombats within a given category and the production modifiers that are adding up - this is also a part of how that said Melee/Mounted unit is heavily imbalanced - because it's getting the sum of both worlds rather than an average, minimum or maximum between those two.
Also combat modifiers need to be considered to this end as well.
Anyhow, the point is, by categorizing UnitCombats into their own categories, I can resolve these kinds of gamerule situations - and I've been considering them categorized since we've had multiple unitcombat types on units - it just hasn't been an actual game definition no matter how badly it's been needed to be.
3) This makes it possible for me to build an automatic 'Flavoring' mechanism for the AI to assign flavoring based on tags that refer to objects but don't otherwise have a way to say that tag means it should be calculating to a particular 'flavor'.
This is where I realized it's time to do this now because as some of you know, that's a current and immediate project to address. I hit the point where I was trying to figure out how I could get a +2 adjustment to the birth rate of a Prophet in all cities to be able to equate to adding value to the Religious flavor, for example, or how the same tag might work if it was being used to get a +2 adjustment to a Great General... hmm. So now I can categorize specialists in a way that allows me to assign a flavor to them based on that category. I will be adding a Flavor selection tag to the category object as one of my next tasks. Then I have the information I would need to define the flavoring system in the dll functions much easier. And this means the potential for MASSIVE benefits to the AI programming.
4) Superfast looping improvements - a huge benefit to turn time processing potentially
When used to cache objects into smaller more pertinent loops, we may be able to strongly enhance our game processing speed - though this could be problematic for memory if we overuse it so its to be applied only when absolutely necessary I think.
5) Multi-object groupings may lead to simplification of some tags.
Example: +20% Production of Agricultural Type Objects.
This would mean that if you have a wonder, a standard building, a unit, or a project, indicated in the singular category of: Agricultural Type Object, that one player tag can count for all of the above rather than having to have multiple tags - one for each game object type (such as +20% Production of x,y,z, units and then +20% Production for x,y,z buildings, and so on.)
THIS, over time, could mean a significant MEMORY savings when applied to eliminate unnecessary tags. This could be very big where you have things like terrains AND features where both can simply be indicated by a category that groups them rather than having Terrain Combat Modifiers and Feature Combat Modifiers. You could even lump in promotions and unitcombats into the one common form tag usage of a singular Category Combat Modifiers tag.
6) Can help us to correct problems that stem from many sub-types of the same object
Civ IV had a Forest Terrain. C2C has some 5 or 6 different TYPES of forest terrains. This is a little problematic and this category system can help us solve the problem by allowing us to define all those Forest Types in a unifying category.
This means potential AI valuation improvements, such as in promotion selections where it is summing up all the +15% Combat Modifiers listed for each and every Forest Terrain type individually, making it difficult, with so many forest types, to get a forest based promotion to have the same value as one that gives the same benefit to Hill combat.
There's probably a LOT more even still. We might be able to entirely eliminate some other classes and rewrite the code to just work with a vector stored list that represents that class by defined categories within a category. I'm thinking of how this might streamline multi-map issues and the MapCategory class which it may be able to replace.
That said, we need to consider every step for the best course of action at the time and for now, it's those main solves I've mentioned that I'm looking for this to help with.
If you're a modder, however, be considering how you may be able to use this mechanism to your benefit. I would imagine the really strong programmers could give us some feedback on how to best use this and how to best NOT use this as well. I'm interested in hearing ALL of those warnings and bits of advice. I think this can be used for great things for us, but if misused could be very badly abused as well.
Hopefully, before long, players will be able to gradually see major improvements in some problematic areas of the mod thanks to this project!
Anyhow, this is a thread and feedback from any and all is welcome!
wow just looked and thats a whoooole lot of them, lol,, great job 
. . .
