Balance Factors

[JosEPh_II]

very little reason for him to actually send in 113 arsonists

And here is the Core problem. Arsonists are supposed to be a National Limited unit, 20 Max. But if you play with the Option that gives Unlimited National units you Break their reason to be Limited! Then you complain they are to OP! You Broke their Intent!

I wish we had Never included the Unlimited National Unit Option. It Broke so many Special units. If we had never allowed that Option of Unlimited we would never have had any of this discussion/debate for the past 3 years plus. And pi4t you would not have this complaint or reason to post Arsonists are OP. Neither would anyone else.

So until Players Understand that their game set up options may or will change the intent and purpose of Special Limited units then we will have this discord. All of Sparth's Culture units are supposed to be Limited. By choosing Unlimited Option all of their intent and design is thrown out the window. And game play experiences a major shift in the view of usage for these Special units too. Then the Cry that some/all of them are OP happens. Well Duh! You can now field 100s of them instead of 10 or 20. smh!

 

[billw2015]

And pi4t you would not have this complaint or reason to post Arsonists are OP. Neither would anyone else.

This isn't correct, I would still think them OP at 20 limit as well. Maybe you can clarify some points (perhaps you have done so elsewhere, but search on this forum is basically useless!):

What is the raison d'etre for arsonists? I have seen you first mention patching AI behaviour to avoid too many units, but also vaguely mentioning playing style. What style exactly do they support and how?

What is the historical argument for them as they are defined? I have never heard of this type of unit (thrown fire weapons) being significant historically, but as designed they form the core of the military most people would make as soon as they become available.

Why should we consider promotions so significant when deciding if a unit is overpowered? They aren't free, you need the make the buildings to "pay" for them, and even then I am only seeing either a 1 or 0 promotion difference in my cities with these buildings. e.g. Skirmishers get the same XP as arsonists and overall (subjectively) worse abilities, while costing more and not being available as early. Even if we do consider promotions significant, all units gain experience, and experience counts less the more promotions you get (the promotions costing more XP the more you have). This means that you could easily argue that BASE strength (and inherent modifiers, in this case 25% city attack) is actually what is valuable, because it determines the effectiveness of promotions, which any unit can get eventually.

What is the argument for them having high strength and a city attack bonus on top of also siege ability? Seems like *just* siege ability would fill the role required?

/edit To clarify I am certainly no expert on Civ or C2C mechanics, I might have stuff wrong here, or not be considering any number of things, I'm only going by what I am seeing in the game!

 

[Thunderbrd]

Arsonists are supposed to be a National Limited unit, 20 Max

This isn't correct, I would still think them OP at 20 limit as well.

From one side of this argument, I can see how we would need to make an entire unit definition split with the replacement system for arsonists if we're going to use this sort of unit.

The reason it is allowed to be unlimited in this option is because it's logically unsound to limit this sort of military application. The individuals that make up the unit are not unique and hard to find types of people (which is the reason that Warlord units are still limited despite the unlimited national units option) and they don't currently have the exponential increasing cost factor and 'only one civ gets them' factor of unique cultural units. They are just an imbalanced unit and that's why they need a limit. AKA, bad design is the reason they need to be limited.

That said, I felt National Limits in most cases WAS bad design and was better addressed by more organic limitations where they apply. Thus the reason for the option No National Unit Limits. However, this particular unit would really need to be redesigned between the two options at this point. This way both sides of this argument could have their way on the matter. On the National Limits side, they would need to be given an exponential cost increase if the limit was to be so large as 20 and their stats keep them at an era of combat ahead of the game as they currently are. On the non-limits side, I'd like to take the bombard ability down to 2%, reduce their strength to 6, and their city attack to 10%. This would reintroduce some balance so that they aren't outshining every single unit normally intended for the role of city capture and so that they fit into the picture as a part of the fabric of the makeup of a good invasion army, rather than being a super unit. They would retain the 'a little bit of everything' aspect, including their unique ability to take the edge off of the city defenses enough for rams to have a fighting chance, but if they were used without rams you'd be sitting there for a LONG time trying to do the damage you need to make a difference.

There are some other rebalancing points to go after on other units as well but those adjustments would be a patch at least. Nothing I'm doing before the release though.


@Anq: Thanks for your overview. I think I could work it out from that. When you go to merge the branch, what happens when there are conflicts? You gotta go through the massive headache of deep comparisons at that point I imagine?

 

[Anq]

I agree with national limits and taking away the unlimited units option too. If anyone can build as many hunters as they like, they will gain too much of an advantage if they started on a huge landmass. The national limit of five has two factors of balance: First it gives small island players better chances to catch up, and second it makes the open wilderness more dangerous because you cannot simply outnumber the animals, but you have to play some tactics to keep your experienced hunters alive. Ambushers, they are a nuisance too. Battering rams and arsonists, if you don't limit them to 40 or 20, AIs are going to build hundreds of them because they have such many hammers to spend on units. A game without limit on national units is not the same game anymore.

 

[Thunderbrd]

If anyone can build as many hunters as they like, they will gain too much of an advantage if they started on a huge landmass.

I've never had a problem with this because the land only spawns so many animals and if you overhunt an area, you've wasted your production on hunters and your hunters aren't getting as much XP individually so they don't get to be as good as they could otherwise be, which actually reduces the overall subdual rate ultimately.

Battering rams and arsonists, if you don't limit them to 40 or 20, AIs are going to build hundreds of them because they have such many hammers to spend on units.

That's a problem with the way the AI is designed more than anything. At some point, it's a waste of production and cost. We do have unit upkeep design issues that are intended to establish some controls but they are failing in light of gold glut.

 

[Tajo]

We do have unit upkeep design issues that are intended to establish some controls but they are failing in light of gold glut.

Easy solution, many money generating buildings at and after medieval era could be toned down.

 

[Toffer90]

AIs are going to build hundreds of them because they have such many hammers to spend on units.

Maybe not if these units cost more and more hammers for each one trained, the AI will then be less and less inclined to train them for each one it gets.
We do have a tag that does this and it should imo be used more.

 

[Yudishtira]

I agree with national limits and taking away the unlimited units option too.

I am never in favour of removing options. However:

A game without limit on national units is not the same game anymore.

This is well said, but I would go further. The game with unit limits removed is the wrong game, and programming effort that caters to or assumes this option, is likely to be of little or no benefit to the mod.

 

[Tajo]

I am never in favour of removing options. However:

This is well said, but I would go further. The game with unit limits removed is the wrong game, and programming effort that caters to or assumes this option, is likely to be of little or no benefit to the mod.

Heartly seconded. Removing options to choose is just pointless.

 

[Thunderbrd]

This is well said, but I would go further. The game with unit limits removed is the wrong game, and programming effort that caters to or assumes this option, is likely to be of little or no benefit to the mod.

I'm of entirely the opposite opinion. The limits are usually just a patch for bad unit design balance or an AI flaw. Sure there are global units and so on but there are better ways, like the following statement, to work with balance.

Maybe not if these units cost more and more hammers for each one trained, the AI will then be less and less inclined to train them for each one it gets.
We do have a tag that does this and it should imo be used more.

Furthermore, if you use outright limits to enforce more balanced stack design, then it just means once they hit the limit, they'll just overtrain the next most valuable type. You'd have to limit every unit to make that system work and that, too, doesn't work for numerous reasons.

By the way, it's not hammer cost, it's gold upkeep cost round by round that's incrementally increased. IIRC anyhow. Such an incremental increase in hammers would be good too though.

 

[Toffer90]

By the way, it's not hammer cost, it's gold upkeep cost round by round that's incrementally increased. IIRC anyhow. Such an incremental increase in hammers would be good too though.

No it's for hammers.
This one I mean: <iInstanceCostModifier>; it has nothing to do with gold upkeep, only hammer cost.

You're probably thinking of <iExtraCost>, which does increase the base upkeep cost of a unit, but it doesn't take into account the amount of units of this type already owned by the player.

 

[T-6000]

May i ask , how to do that ?

You need to go into the XML and change the strength number in there - I can't remember exactly where that is since I haven't done it in a while. I will say you should use something better than notepad to do it though, and to back the file up first if you're unsure of what you're doing. I can't remember how changing it affects existing saves, probably best to back them up too.

As an aside, the AI appears to agree with Thunderbrd's assessment of the balance of Arsonists, based on what Justinian just marched into my lands
[...]
For the record, that stack also includes about 15 wolves, a few rams and a healer, but nothing else. No conventional military forces at all. Just loads and loads and loads of arsonists.

It looks like the "fix" to the AI spamming loads of rams might have just resulted in it spamming loads of arsonists instead?

In my experience this has been a problem too - before I reduced arsonists' strength in my own games they were the favoured unit for the AI, and afterwards they did get very keen on wolves. I've seen other cases a bit like this too - in my last game (caveat: this was a few months ago now, so on various 105xx revisions) I had a stack of 291 trebuchets roll up to one of my cities, along with a bunch of dogs and a relatively small (50-ish) escort of sensibly chosen regular units, which turned out not to be a tactically sound choice for the AI. I don't know what's going on in the guts of it but it does seem like when it thinks a unit is strong, they can favour that unit a little too much and don't build a more rounded military.

 

[Thunderbrd]

This one I mean: <iInstanceCostModifier>; it has nothing to do with gold upkeep, only hammer cost.

I'm not sure I'm familiar with that tag... is it in use anywhere now?

You're probably thinking of <iExtraCost>, which does increase the base upkeep cost of a unit, but it doesn't take into account the amount of units of this type already owned by the player.

I'm familiar with that tag but...

Is the Base Cost this display talks about from iInstanceCostModifier? If so, I would've sworn I saw it interacting with the gold upkeep cost as opposed to the production cost but I can see it doing both and that being cool too.

 

[Toffer90]

Is the Base Cost this display talks about from iInstanceCostModifier? If so, I would've sworn I saw it interacting with the gold upkeep cost as opposed to the production cost but I can see it doing both and that being cool too.

What you marked in the screenshot is the iInstanceCostModifier.
In the MToS modmod I've set it to 100 for gatherers, so on marathon GS the first one costs 32, the second cost 64, the third cost 96 and so on.
When a gatherer is used up the cost goes one step down again. I wanted to deter players from hoarding them between the times they can actually be used for something.
I'm pretty sure it doesn't impact upkeep cost at all.

 

[raxo2222]

What you marked in the screenshot is the iInstanceCostModifier.
In the MToS modmod I've set it to 100 for gatherers, so on marathon GS the first one costs 32, the second cost 64, the third cost 96 and so on.
When a gatherer is used up the cost goes one step down again. I wanted to deter players from hoarding them between the times they can actually be used for something.
I'm pretty sure it doesn't impact upkeep cost at all.

Looks like it could be +10% for all units here (maybe scaled by map area or city count).
That is 10th unit would be 2x more expensive to build, 20th unit would be 3x more expensive to build.

This would speed up game since there would be less units.

 

[Thunderbrd]

Looks like it could be +10% for all units here (maybe scaled by map area or city count).
That is 10th unit would be 2x more expensive to build, 20th unit would be 3x more expensive to build.

This would speed up game since there would be less units.

That actually would not be a bad idea and would lend towards enforcing better unit balance, even for the AI.


All this time I have always thought this was a reference to gold cost and not production cost... we really need to improve the wording on that tag!

 

[raxo2222]

That actually would not be a bad idea and would lend towards enforcing better unit balance, even for the AI.


All this time I have always thought this was a reference to gold cost and not production cost... we really need to improve the wording on that tag!

It seems like its tied to Unit Class info.

if (0 != GC.getUnitClassInfo(eUnitClass).getInstanceCostModifier())
        {
            szBuffer.append(NEWLINE);
            szBuffer.append(gDLL->getText("TXT_KEY_UNIT_INSTANCE_COST_MOD", GC.getUnitClassInfo(eUnitClass).getInstanceCostModifier()));
        }

This tag is used in UnitClassInfos.

I used regex to remove (so no duplicates would be here) and then put this tag in all unitclassinfo files.

<UnitClassInfo>
            <Type>UNITCLASS_BEASTMASTER</Type>
            <Description>TXT_KEY_UNIT_BEASTMASTER</Description>
            <iMaxGlobalInstances>-1</iMaxGlobalInstances>
            <iMaxTeamInstances>-1</iMaxTeamInstances>
            <iMaxPlayerInstances>-1</iMaxPlayerInstances>
            <iInstanceCostModifier>10</iInstanceCostModifier>
            <DefaultUnit>UNIT_BEASTMASTER</DefaultUnit>
        </UnitClassInfo>

Units with -1 cost and global units doesn't need this though.
Probably there is less crude way to implement that

Property control should be exempt from this though.

 

[Thunderbrd]

It seems like its tied to Unit Class info.

if (0 != GC.getUnitClassInfo(eUnitClass).getInstanceCostModifier())
        {
            szBuffer.append(NEWLINE);
            szBuffer.append(gDLL->getText("TXT_KEY_UNIT_INSTANCE_COST_MOD", GC.getUnitClassInfo(eUnitClass).getInstanceCostModifier()));
        }

This tag is used in UnitClassInfos.

I used regex to remove (so no duplicates would be here) and then put this tag in all unitclassinfo files.

<UnitClassInfo>
            <Type>UNITCLASS_BEASTMASTER</Type>
            <Description>TXT_KEY_UNIT_BEASTMASTER</Description>
            <iMaxGlobalInstances>-1</iMaxGlobalInstances>
            <iMaxTeamInstances>-1</iMaxTeamInstances>
            <iMaxPlayerInstances>-1</iMaxPlayerInstances>
            <iInstanceCostModifier>10</iInstanceCostModifier>
            <DefaultUnit>UNIT_BEASTMASTER</DefaultUnit>
        </UnitClassInfo>

Units with -1 cost and global units doesn't need this though.
Probably there is less crude way to implement that

OK, now THIS has GOT to wait until after release to be worked on. Discussions crop up a lot here but we're never going to release if we keep updating the SVN with the latest idea as soon as it comes up. Plus, it may not apply equally to ALL units because not all units even have a production cost and that could thus cause problems when applied to those. Additionally, we should wait and make this an early convert tag to UnitInfos since we've gotta change everything on UnitClassInfos to UnitInfos anyhow. AKA, cool the jets just a touch. Love the enthusiasm though.

 

[raxo2222]

OK, now THIS has GOT to wait until after release to be worked on. Discussions crop up a lot here but we're never going to release if we keep updating the SVN with the latest idea as soon as it comes up. Plus, it may not apply equally to ALL units because not all units even have a production cost and that could thus cause problems when applied to those. Additionally, we should wait and make this an early convert tag to UnitInfos since we've gotta change everything on UnitClassInfos to UnitInfos anyhow. AKA, cool the jets just a touch. Love the enthusiasm though.

LOL that thing was meant to be for post release

I mentioned, that it isn't for all units too

 

[Dancing Hoskuld]

So you want to replace the unrealistic limited number of units with the also unrealistic idea that making the second of something is more expensive than the first. I can't think of any example where the cost of production, for anything, goes up rather than down the more you make in the real world.