C2C Combat Mod Introduction - Step I (SubCombat Classes)

Ok, I take your point. I guess there would probably be a need for some rebalancing. The horse archer example is worth thinking about - it might be a significant disadvantage because the unit would be counterable by many more unit types than either a simple archer or mounted unit would (spears and javelins for example would both get big plusses against it). Of course, it would also be eligible for a wider variety of promotions, and bonuses from buildings...I'm not sure where the balance woud lie, hit there's a good chance it will change things around enough that well need to do some unit rebalancing.

Maybe the bonuses shouldn't stack between unitcombats. For instance, if a unit has +50% vs Archers and +20% vs Horse Units only gets +50% vs Horse archers.
 
When I added GOM_UNITCOMBAT, I sneaked in a hasCombatType method that works similar to hasSubCombatType but considers main combat type and sub combat types equally.
I spent a lot of time today musing over this issue and there's only one place where I think I might need the separation still and that's probably just due to not knowing all the tricks and tools: the Text Manager. I'd like you to review the code there for displaying all unit combats on unit help popup and see what you can make of how to adjust it if we abandon the old hasSubCombatType entirely.

Otherwise, after much thought, I don't think there would be any other problem with what you proposed and instead using the tag you worked out on hasCombatType. I assume that's in the Unit.cpp? I also presume its using an improved vector combination method? It sounds extremely helpful either way.

@Thunderbrd

I have another question ...

So lineages like the Law Enforcement, Medic, Recon and Criminal line cover many types. Are you saying that we can have combos such as ...

- Medevac Helicopter = Healer + Helicopter
- Police Car = Law Enforcement + Wheeled
- Adventurer = Recon + Mounted
- Medical Ship = Healer + Diesel Ships
- Mobster Car = Criminal + Wheeled
- Pirate Ship = Criminal + Wooden Ship
I knew you would be quick to 'see the light' Hydro! Yes, this is very much intended.

@Thunderbrd:

*head hurts* man this is a lot of new ideas for one mechanic in the Combat Mod. I can hardly imagine how much XML will be needed just to clean up references in Units and Promotions to unitcombats for this. For instance, if we made Cavalry units UNITCOMBAT_CAVALRY and UNITCOMBAT_MELEE, then Axemen would get +50% against them, Shock would apply against them, and so on and so forth. Ditto for almost any other combination of combats that I can think of.

The other nightmare I see from this is the AI. It is already not good at unit selection, and I can't imagine that it will get better now that we are giving units arbitrarily high quantities of unitcombats. I know that much of the Unit selection logic is handled by UNITAIs, but I think that if all that the AI sees is the unitai, then it will be oblivious to the opportunities presented by the subcombats. I think that before implementing any of the features of the Combat Mod into the XML that we should make sure that the AI will not be inconvienenced by them.

True, but why would you ever flag cavalry as melee???

I actually don' think this will be too bad for the AI. It already takes into account all the combat modifiers, and this won't change that (just changes where they come from). As far as evaluating stuff it's really just more promotions, and with a few tweaks the existing promotion evaluation should cope fine. The existing code for building-based unitCombat modifiers should also work fine (it's just more unitCombats that a unit can have)

1. That was just an example, I was actually thinking of giving Horse Archers the Archer unitcombat, and then realized all of the implications of that.

2. OK, That makes sense.

Ok, I take your point. I guess there would probably be a need for some rebalancing. The horse archer example is worth thinking about - it might be a significant disadvantage because the unit would be counterable by many more unit types than either a simple archer or mounted unit would (spears and javelins for example would both get big plusses against it). Of course, it would also be eligible for a wider variety of promotions, and bonuses from buildings...I'm not sure where the balance woud lie, hit there's a good chance it will change things around enough that well need to do some unit rebalancing.

Maybe the bonuses shouldn't stack between unitcombats. For instance, if a unit has +50% vs Archers and +20% vs Horse Units only gets +50% vs Horse archers.

Of course, I gave all these thoughts a lot of consideration when setting this up. I'm not going to purport to have all the balance figured out in my head but I have a few things to say on these matters:

1) Unit AI really wouldn't be impacted much for all the same reasons Koshling brought up. The existing system should handle it 'ok' but that's just as well as its handling pretty much everything else and we're wanting to make a lot of improvements there anyhow so why not do them with the combat mod features in mind first rather than let them be adjusted then have to be readjusted further to account for the combat mod features later? Yes, there are some issues the ai should be considering further, but outside of its basic evaluation routines it already has in mind along with a few tweaks as we see them doing things they shouldn't be doing, it should work fairly alright under this part of the combat mod already.

2) MOST subcombat definitions on a unit will stem from their original unit info definition and only special cases will make promos add new subcombats for as long as those promos continue to qualify on that unit type (will generally outdate on upgrades and such.) So this means that just about any overlap of truly core vanilla combat classes would not only bring some pretty big potential for being effectively countered by one or a few units with well placed promos, it also means they get an exorbitant amount of bonus xp from buildings that are giving their bonuses to those specific Combat Classes, and free promos doing the same.

3) A unit can still only have so many promos at once right? What they earn is limited to what they have achieved and this means that even if I've got an archery and mounted unit, one opponent would still usually be hard pressed to have capped out its possible promo benefits against even one of those combat classes. There's also going to be SO many new promo lines and types after the combat mod is said and done that it will distill these kinds of 'anti-specific combat class' promotions a great deal... it won't always be the most effective promotion styles anymore.

4) This simply means that there's a big tradeoff between the benefits and penalties of a unit with multiple core combat classes, a tradeoff that the ai will naturally work with rather well based on the current ai methods but should be factored into future ai tweaks of course.

5) We should not underestimate the promotion access issue. I'm about to post on promotion types and promotion lines so I'll say more there. But the current system of designing promo access should be greatly adjusted for the combat mod so that combat classes govern these even more directly. Thus, Archers, by default would no longer have City Defense (why not have some archery units have a focus on City Attack instead? Camel Archers make poor city defense even with the promo line being accessible etc...) thus you'd have 'City Garrison' as a combat class in and of itself and if you wanted the Archer unit to have this by default, list City Garrison as one of its SubCombats. Again... more on this in the next discussion. I've been considering what makes the defining of Combat Class Promo access a pain in the arse and I'm looking to use SubCombats and Promo Lines to simplify the process a great deal. (It might mean gutting the current unit xml extensively but for the sake of ease of future modding and rationalizing Promo access chains easier.)

6) Overlapping CORE (by this I generally mean the currently existing Combat Classes) combat classes too much is probably best to be avoided if possible. Few, special, units sure, but its not a good idea to now say, ok, since Knights fight in melee, they should automatically be Melee and Mounted. It might not be a bad idea to do so but the decision to should not be taken too lightly either. I was originally thinking the Javelineer units should be archery and melee but I now feel it would be best to just be a Throwing unit. The Knight should be a Heavy Mounted (to suggest the dual role), as opposed to Light Mounted (the hit and run, surround and destroy raider style) as a sub-definition for Mounted, which should remain its primary Unit Combat.

7)We should put the original vs Melee, vs Archery, vs etc... promo lines to shame with all the forms of promo lines we can develop towards all the many types of Sub Combats we'll have defined. Therefore they begin to blend into the fabric rather than standing out as an easy way to isolate your enemy's strengths and target it or as an easy way to cross defend your stacks. In general, the more common a Combat Class definition is, the lower the combat vs benefit a promo line should offer. For example, Shock is generally +25 per step vs Melee (fairly common... about a third to a fifth of all units tend to be Melee) which is quite a bit stronger than the standard balanced minimum Combat line which is +10 against all. A bonus vs Humans should probably be a +15 due to how common Humans units are... etc...

With all these in play, each being roughly equivalent in value, we confuse the player as much as the ai as to the wisest course of promoting and thus bring the ai closer to our level. It's a bit counter intuitive on the method but in many ways, the AI should benefit from the vastness of options as it will rely on the power of semi-guided chaos in its selections to make the player always second guess his strategy as it won't always work repeatedly. It forces us to abandon 'standard practices' and start really paying attention to what we're likely to be up against instead.

Wait this is just the first part :eek: wow I must say great job on this thunderbird
Thanks GiuseppeIII! :) More to come tonight. And there's still a lot of polishing and recoding to make the mod more processing effective still...

Well I was thinking of the Horse Archer. We have a Horse Archer and A Horse Crossbowman. What if it worked like this?

- Archer = Archer + Human + Bow
- Crossbowman = Archer + Human + Crossbow
- Horse Archer = Mounted + Horse + Bow
- Horse Crossbowman = Mounted + Horse + Crossbow
- Camel Archer = Mounted + Camel + Bow
- Llama Archer = Mounted + Llama + Bow

Thus you can have specific bonuses vs Bows but not Crossbows. Likewise you can have a bonus vs Horses but not Camels.
Again... you see the light! There'd be more definitions than these but this perfectly highlights the intention.
 
6) Overlapping CORE (by this I generally mean the currently existing Combat Classes) combat classes too much is probably best to be avoided if possible. Few, special, units sure, but its not a good idea to now say, ok, since Knights fight in melee, they should automatically be Melee and Mounted. It might not be a bad idea to do so but the decision to should not be taken too lightly either. I was originally thinking the Javelineer units should be archery and melee but I now feel it would be best to just be a Throwing unit. The Knight should be a Heavy Mounted (to suggest the dual role), as opposed to Light Mounted (the hit and run, surround and destroy raider style) as a sub-definition for Mounted, which should remain its primary Unit Combat

Well I think there is a big difference from Melee + Mounted if you use the sub-classes. Such as ....

Swordsman = Melee + Human + Sword
Knight = Mounted + Horse + Sword

Both the Knight and the Swordman would be "Sword" unit class but one is Mounted and one is Melee. Thus any bonus to melee units would not be useful against a knight. But if you had a defense vs specially swords then you would get a bonus vs both knights and swordsmen.

See what I mean?

Note that the Knight might actually be using a Lance and not a Sword but you get the idea.

As for the Javelineer I think it would be ...

Javelineer = Archery + Human + Javelin

Thus sub-classes like Javelin or Polearm would get a bonus to Mounted units. Note that it is Archery since its a "projectile" type of unit.
 
You got my gist completely although it seems like you must've thought I was making a different point. To add, however:

Swordsman = Melee + Human + Sword + Light Shield (Heavy Swordsmen would probably have Heavy Shield)
Knight = Mounted + Horse + Sword (+Lance, +Heavy Mount)

So I'm showing this to clear up any confusion you may have had on what I was saying. In many ways you expressed the intention of my explanation there much better than I did.
 
@Thunderbrd

Well yes. Also the Size and whatever other sub-class factors that are added. I was just giving a simple example using the core class + species class + weapon class.

EDIT: While say a Hunter type of unit would be good vs Animal class if we have the sub-classes for the different groups of animals I could see specialized Hunter promotions such as ....

- Wolfsbane = +100% Canine Units
- Crocodile Hunter = +100% Crocodilian Units
- Whaler = +100% vs Cetacean Units
- Ivory Poacher = +100% vs Pachyderm Units
 
I spent a lot of time today musing over this issue and there's only one place where I think I might need the separation still and that's probably just due to not knowing all the tricks and tools: the Text Manager. I'd like you to review the code there for displaying all unit combats on unit help popup and see what you can make of how to adjust it if we abandon the old hasSubCombatType entirely.

Otherwise, after much thought, I don't think there would be any other problem with what you proposed and instead using the tag you worked out on hasCombatType. I assume that's in the Unit.cpp? I also presume its using an improved vector combination method? It sounds extremely helpful either way.
It is a simple method that is similar to hasSubCombatType. The reason for using it is not really efficiency but avoiding the doubling of code that happens now.
 
@Hydro:That is just awesome! I can see this system is getting your imagination flowing as much as I hoped it would.

It does point out one AI element that needs to be considered though that isn't yet... and that's the matter I mentioned earlier about the value of the bonus being relative to the frequency of the unit type. I need to make it evaluate anti-unitcombat promos on a flat-line consideration rather than on the value of the promo with the assumption that the modder is going to make a human evaluation of the frequency of the combat class to be encountered and adjusts the value to fit that frequency.

Otherwise the ai would see +100% and freak out with excitement to grab that promo above all others!
 
It is a simple method that is similar to hasSubCombatType. The reason for using it is not really efficiency but avoiding the doubling of code that happens now.
Would it be possible then to convert it to a vector or map method to help me see how to do the same with other similar functions as we've discussed? Or is this use of vector/maps rather unnecessary for streamlining the processing here?
 
Would it be possible then to convert it to a vector or map method to help me see how to do the same with other similar functions as we've discussed? Or is this use of vector/maps rather unnecessary for streamlining the processing here?
I don't think a unit will have more than maybe 4 or 5 sub combat types so no need for a map.
For streamlining the processing it should not matter too much what we use as actual data structure as we will only access it with methods so we can change the data structure later if we want (the promotion arrays are larger so should be changed first).
 
Ok... I don't expect to undertake all streamlining steps overnight anyhow so its good to have some guidance as to what will have the greater immediate impact.

@LS612:
What, exactly, do you feel the AI should be taking account of that it may not be accounting for in this section? I'm just looking to start developing a list of AI improvements that should be necessary to accompany this mod in full.

Personally, in regards to SubCombats at least, I feel the AI will handle it pretty well now but may have some unforseen bad ideas in light of the adjustments that would really only come up if we start implementing and playtesting.

But if we can think of some that should be touched on right away, by all means, this project has taken this long - I'm in no hurry to force it in without some preplanning and additional polishing to make it not suck ;)
 
Well I was thinking of the Horse Archer. We have a Horse Archer and A Horse Crossbowman. What if it worked like this?

- Archer = Archer + Human + Bow
- Crossbowman = Archer + Human + Crossbow
- Horse Archer = Mounted + Horse + Bow
- Horse Crossbowman = Mounted + Horse + Crossbow
- Camel Archer = Mounted + Camel + Bow
- Llama Archer = Mounted + Llama + Bow

Thus you can have specific bonuses vs Bows but not Crossbows. Likewise you can have a bonus vs Horses but not Camels.
For me this looks not stringent.
I rather see it working this way:
- Archer = Human + Bow
- Crossbowman = Human + Crossbow
- Horse Archer = Human + Horse + Bow
- Horse Crossbowman = Human + Horse + Crossbow
- Camel Archer = Human + Camel + Bow
- Llama Archer = Human + Llama + Bow

Mounted means to me, that a human is riding on an animal, such as
- horse
- camel
- llama
- donkey
- deer
- elephant
- bear
- bison
- mammoth.

So in the initial list, mounted and horse/camel/llama/etc. i read it as
Horse Archer = Human + Horse + Horse + Bow.

Also, if archer is a needed tag, the initial list should include archer for all units,
- Archer = Archer + Human + Bow
- Crossbowman = Archer + Human + Crossbow
- Horse Archer = Archer + Human + Horse + Bow
- Horse Crossbowman = Archer + Human + Horse + Crossbow
- Camel Archer = Archer + Human + Camel + Bow
- Llama Archer = Archer + Human + Llama + Bow

But as always it's more likely just me not getting the point. ;)
 
@Hydro:That is just awesome! I can see this system is getting your imagination flowing as much as I hoped it would.

It does point out one AI element that needs to be considered though that isn't yet... and that's the matter I mentioned earlier about the value of the bonus being relative to the frequency of the unit type. I need to make it evaluate anti-unitcombat promos on a flat-line consideration rather than on the value of the promo with the assumption that the modder is going to make a human evaluation of the frequency of the combat class to be encountered and adjusts the value to fit that frequency.

Otherwise the ai would see +100% and freak out with excitement to grab that promo above all others!

Actually the AI should really evaluate based on the enemy combat types it sees in the field at the time. I've been meaning to do that for ages, so I'll add it when I make a pass over the promotion choosing code (base weighting on observed frequency of enemy combat type, with extra weighting for enemy combats types that we actually recently lost battles to)
 
For me this looks not stringent.
I rather see it working this way:
- Archer = Human + Bow
- Crossbowman = Human + Crossbow
- Horse Archer = Human + Horse + Bow
- Horse Crossbowman = Human + Horse + Crossbow
- Camel Archer = Human + Camel + Bow
- Llama Archer = Human + Llama + Bow

Mounted means to me, that a human is riding on an animal, such as
- horse
- camel
- llama
- donkey
- deer
- elephant
- bear
- bison
- mammoth.

So in the initial list, mounted and horse/camel/llama/etc. i read it as
Horse Archer = Human + Horse + Horse + Bow.

Also, if archer is a needed tag, the initial list should include archer for all units,
- Archer = Archer + Human + Bow
- Crossbowman = Archer + Human + Crossbow
- Horse Archer = Archer + Human + Horse + Bow
- Horse Crossbowman = Archer + Human + Horse + Crossbow
- Camel Archer = Archer + Human + Camel + Bow
- Llama Archer = Archer + Human + Llama + Bow

But as always it's more likely just me not getting the point. ;)
Ok, this is one of the reasons I called them SubCombats... to suggest subtly at this kind of use. Think of it like this:
A unit which has a bow or crossbow may not primarily be an archer. Perhaps, primarily its a mounted unit, or a Criminal unit, or a Pirate.

However, it does have a bow, even if the USE of the bow is not what primarily defines its combat style or approach. Therefore, ownership of a bow is a sub-definition that can fit in under other definitions in a mix and match style method.

If I'm an Archer, that's defining my Primary combat methodology and approach, and thus, many, most, archers also have bows. But they could alternatively have crossbows and have nothing to do with bows but still be archers because the strategies to defend and attack, with and against, such units would be somewhat similar in nature and can use this unifying definition to allow us to shape promotions and such.

If I have an anti-archery promotion, I'm probably pretty good at dodging arrows, timing advances, and getting in close on a fighter that lacks quite the strength in hand-to-hand that I do. This would be a strategy that would work against all Archer units regardless of what weapon they are actually using.

If I have an anti-BOW promotion, I've figured out methods to try to take on bow based units that don't otherwise work against Crossbows or any other style of Archer.

Though this might be a bit strange to consider such a combat strategy that would apply against one but no the other, the subdivision between weapons use is still necessary for guiding the assignment of equipments to the proper weapon wielder so that I'm not giving Expert Compound Longbows to Crossbowmen and expecting them to know how to somehow be a crossbowman with all the trained field strategies of such, but instead be wielding a bow (plus that'd just get confusing for the player!)


Actually the AI should really evaluate based on the enemy combat types it sees in the field at the time. I've been meaning to do that for ages, so I'll add it when I make a pass over the promotion choosing code (base weighting on observed frequency of enemy combat type, with extra weighting for enemy combats types that we actually recently lost battles to)
Wow... that would be amazing to see! Thus they build to counter what they've been most unsuccessful in taking care of out in the field so far. Brilliant, but there's a potential downfall in that it could get the ai to over-correct and once you began to understand its tendency to do so you could really throw it for a loop. Have you envisioned them also able to also take into consideration, as a human would, simply trying to 'cover all bases' while weighting their approach as above mentioned'?
 
@LS612:
What, exactly, do you feel the AI should be taking account of that it may not be accounting for in this section? I'm just looking to start developing a list of AI improvements that should be necessary to accompany this mod in full.

Personally, in regards to SubCombats at least, I feel the AI will handle it pretty well now but may have some unforseen bad ideas in light of the adjustments that would really only come up if we start implementing and playtesting.

But if we can think of some that should be touched on right away, by all means, this project has taken this long - I'm in no hurry to force it in without some preplanning and additional polishing to make it not suck ;)

I suspect that the AI will be totally oblivious to the extra weaknesses that having multiple unitcombats brings, as well as the fact that it won't exploit the opportunities that this brings. Most of the other Combat Mod things I think won't be too hard on the AI (assuming the Odds calculator works properly with them), but this one I saw as being a major issue.
 
How could we address those concerns without putting the system into practice to find out how these matters could be improved on? What specific ways would you think they would be oblivious to penalties and what specific ways do you think they would fail to exploit the opportunities?

At the moment, I'm a bit unsure how as a player to fully establish best practices so to improve the ai to do so at this juncture would be somewhat premature wouldn't it?
 
What about adding unit combat type advantages vs. other unit combat types to the unit combat info itself? That way having a unit combat is not an inherent disadvantage until you get to use the associated promotions.
 
Ok, this is one of the reasons I called them SubCombats... to suggest subtly at this kind of use. Think of it like this:
A unit which has a bow or crossbow may not primarily be an archer. Perhaps, primarily its a mounted unit, or a Criminal unit, or a Pirate.

However, it does have a bow, even if the USE of the bow is not what primarily defines its combat style or approach. Therefore, ownership of a bow is a sub-definition that can fit in under other definitions in a mix and match style method.

If I'm an Archer, that's defining my Primary combat methodology and approach, and thus, many, most, archers also have bows. But they could alternatively have crossbows and have nothing to do with bows but still be archers because the strategies to defend and attack, with and against, such units would be somewhat similar in nature and can use this unifying definition to allow us to shape promotions and such.

If I have an anti-archery promotion, I'm probably pretty good at dodging arrows, timing advances, and getting in close on a fighter that lacks quite the strength in hand-to-hand that I do. This would be a strategy that would work against all Archer units regardless of what weapon they are actually using.

If I have an anti-BOW promotion, I've figured out methods to try to take on bow based units that don't otherwise work against Crossbows or any other style of Archer.

Though this might be a bit strange to consider such a combat strategy that would apply against one but no the other, the subdivision between weapons use is still necessary for guiding the assignment of equipments to the proper weapon wielder so that I'm not giving Expert Compound Longbows to Crossbowmen and expecting them to know how to somehow be a crossbowman with all the trained field strategies of such, but instead be wielding a bow (plus that'd just get confusing for the player!)
Do you really want to go as far as determining the difference between various types of missile weapons? How would you (in game terms) define the difference between a bow and a crossbow? How fine do you want the differentiation to be? Will there be shortbows, longbows, composite bows, various types of crossbows, ability for crossbowmen to carry pavises, etc... ?
This is an interesting idea, but could easily cause a lot of headaches.
 
What about adding unit combat type advantages vs. other unit combat types to the unit combat info itself? That way having a unit combat is not an inherent disadvantage until you get to use the associated promotions.
Although you lost me with the second line and its reference to the first, regarding your first statement:

I did consider doing this but there seems to be a problem with adding anything to the schema that controls unit combats. You may be able to get around that I don't know.

If you can, we could add a great number of tags to unit combat and have it represent a lot more in terms of immediate game effects on units with a given combat. This would be useful. As a proxy, I've given the ability to make a promotion free to all units with a unit combat so we can have a promotion designed to represent all base game modifiers for a unit combat. This may be one area where the ai wouldn't see the full impact of the value of a given unit combat as differentiated from any other.

However, it may even be a better solution this way than adding lots of data to unit combats themselves because THAT would require a whole new set of routines for the ai to evaluate properly while adapting the ai to evaluate the value of the unit combat as if it was the value of the sum of any free promotions added to the unit combat would be much easier.

Do you really want to go as far as determining the difference between various types of missile weapons? How would you (in game terms) define the difference between a bow and a crossbow? How fine do you want the differentiation to be? Will there be shortbows, longbows, composite bows, various types of crossbows, ability for crossbowmen to carry pavises, etc... ?
This is an interesting idea, but could easily cause a lot of headaches.

The differentiation should be just enough to keep units using equipment promotions within their categories and not going outside of those boundaries (as that would break the art and intention of the unit at that point.) Thus, if my unit is generally shown using a Bow, it could be taken to be a shortbow or a longbow, a composite short or long bow and I'm sure a few quality categories within those. So should Shortbow differ from Longbow in unit combat? Probably unnecessary because we can represent the step up with the unit upgrade from shortbow to longbow (though now archers can be given a longbow (a higher ranking equipment than a shortbow) without officially becoming a longbowman - the main difference now being an upgrade in the training and strategy practices of the unit.)

More on this in the next installment where I'm about to go over equipments.
 
I did consider doing this but there seems to be a problem with adding anything to the schema that controls unit combats. You may be able to get around that I don't know.
Have you renamed the schema (so it has a different name than the default Civ one)?
 
Top Bottom