[PATCH] Bugfix and balance walls / siege

[elexis]

Walls are one of the greatest remaining imbalances in alpha 19 due to multiple bugs and imbalances:

Before the attack:

• Walls can be built very fast r17312
• The number of wall turrets is not limited by area ("min-distance"),

During the attack:

• Walls are instantanously repaired and without any resource costs #3707
• Pathfinder of the attacker yielding unexpected paths in mazes of obstructions
• Wall turrets having more range than every other unit
• Attackers fail at dealing enough damage
  • Regular champs are not (and shouldn't be) useful in attacking walls
  • Elephants die too quickly
  • Ranged siege doesn't deal enough damage and is destroyed by wall-turrets

After the attack:

• Walls don't decay in disconnected territory #3340

---

#3707 and #3340 should be fixed individually. The other issues (besides pathfinding) can be addressed in this ticket. Not everything must be fixed for a20, but it should become more reasonable.

---

See also from: ​https://wildfiregames.com/forum/index.php?/topic/20621-good-players-usually-say-no-walls-in-the-multiplayer-lobby/&do=findComment&comment=314820

[elexis]

Two alpha 19 replays of games that took extremely long due to the pattern described above.

[fatherbushido]

(wrong comment)

[fatherbushido]

There is inheritance from template_structure_defense

    <Hack>15.0</Hack>
    <Pierce>25.0</Pierce>
    <Crush>3.0</Crush>

So with r17312, walls have 33% more crush armour compared as a19 balancing, HP is a bit decreased but for many civs, HP is hardcoded in their own templates (gauls, brits, romans iirc).

[sanderd17]

How about trying to enforce the connectedness of walls.

• Wall pieces should always have 2 towers
  • The health of a wall piece could be defined to be the minimum of both towers.
  • Wall pieces don't have to be constructed, but appear automatically when the two towers are build (it rises together with the slowest tower).
  • When damage is dealt to a wall-piece, that damage is distributed over both connected towers (either divided over the two, or the two get the full damage)
  • When one of the towers collapses, the wall piece also collapses (since its health also reaches 0)

• Towers preferably are connected to two wall pieces.
  • When a wall tower has no wall pieces connected, it should lose health

This would enlarge the easiness to attack a wall: attacking a wall piece would automatically take out 2 towers and 3 wall pieces. The towers could be made more expensive, and the wall pieces even cheaper (you can't delete the towers as that would remove your wall). And overall, I guess it would cause walls to be used as walls, and not just to spam towers.

[fatherbushido]

Sanderd17 idea sounds very good. Does it fix #3789 in the same move ?

[bb]

As discussed some time ago on IRC, the wall tower spam can be solved by making the mindistance a maxdensity component (maxdistance is done in same way here). Also killed a TODO in the wall buildingplacement.

[fatherbushido]

@bb: L150 L151 it should be template.BuildRestrictions.Density instead of template.BuildRestrictions.Distance

[fatherbushido]

I tested the patch. I observed that : When building a set of walls with close tower after queuing some walls i can't build anymore (the red stuff) but if i finish the set then i can build starting from the last towers. (a bit confused description).

[bb]

If I understand correctly, this problem is caused by the effect that the towers in the same drag (during same build order) does not effect each others red stuff (cant build model during placement). Though you cannot build the towers, its just same lack of red stuff.

Solving this issue is kinda a pita, time consuming for pc (already notice the tooltip lagg when placing walls to close) and leading to some strange decisions by the pc (i.o. which tower to skipp and which not, only saying closest tower to start point or most towers won't kill out all cases, so we get a hard time placing walls) I do not know if/how we need to fix this issue.

Attached rebased patch.

[bb]

rebased

[mimo]

Can you explain how is the density computed ? and what's the meaning of your 3 parameters Distance, MinEntity and MaxEntity ? From the IRC discussion you are referring, my understanding was that this could be a new restriction for walls and wallTowers, and not to replace the current distance requirements. But maybe the previous distance requirement is still a subset of your new ones, but some explanations would help.

In any case, if that's restricted to walls and wallTowers, that's not a problem for the AI which does not yet build them, but if it's a new criteria used for other structures, you should also modify public/simulation/ai/petra/mapModule.js where the build requirements are implemented lines 87 to 106.

[bb]

Replying to mimo:

Can you explain how is the density computed ? and what's the meaning of your 3 parameters Distance, MinEntity and MaxEntity ?

MinEntity is the minimum number of Entity's (of a specified class) which should be in range ("Distance" is this range) in order to be able to build the building. When we say MinEntity = 1 we have the old maxDistance component, as a density of 1 in a range is just a maxDistance. MaxEntity is parallel from this: the maximum number of ents (of class) in range ("Distance") on building, so a number of 0 gets us the old minDistance component.

From the IRC discussion you are referring, my understanding was that this could be a new restriction for walls and wallTowers, and not to replace the current distance requirements. But maybe the previous distance requirement is still a subset of your new ones, but some explanations would help.

It's my pleasure to explain :), see the above, the old Distance checks have become useless as its a subset indeed. The only (unused) functionality (which is not in the new system) from the old system would be to add two ranges with different Distance. So a MinDistance and a MaxDistance. If we want such a thing in the new system we need to make it a "zeroOrMore" thing to allow different ranges, not sure if that is needed. (hope this is not too vague)

In any case, if that's restricted to walls and wallTowers, that's not a problem for the AI which does not yet build them, but if it's a new criteria used for other structures, you should also modify public/simulation/ai/petra/mapModule.js where the build requirements are implemented lines 87 to 106.

Thx, cc, towers etc. will have a look on this.

[bb]

added ai support for the changed component, still a TODO in it, not sure if that is vital (as it won't happen too often). The new case in map-module.js changes in L144.

[elexis]

In 18288:

Wall placement cleanup. Somewhat based on patch by bb, refs #3811.

Early return instead of a big if-statement.
Inline r, targetX, targetZ, towerX and towerZ.
Rename s to spacing.
Remove unneeded else keywords.
Eliminate deprecated for-each.
Use let instead of var.
Quote object keys.
++i instead of i++.
Some newlines.

[elexis]

Rebased, removed committed stylefix hunks and bad hunk from GUIInterface. Still contains stylefixes which should be done separately as they draw attention when reading the patch.

[fatherbushido]

see r18502 for gate

[Itms]

Move tickets from the review queue to the rfc one.

[bb]

Partial splitted of cleanup from previous patch (partial in order to prevent mega-patches)

[FeXoR]

Applying ​http://trac.wildfiregames.com/attachment/ticket/3811/t3811_buildingDensity_5.diff throws: ERROR: RelaxNGValidator: Validation error: structures/brit_wooden_tower:1: Expecting an element PlacementType, got nothing ERROR: RelaxNGValidator: Validation error: structures/brit_wooden_tower:1: Invalid sequence in interleave ERROR: RelaxNGValidator: Validation error: structures/brit_wooden_tower:1: Element BuildRestrictions failed to validate content ERROR: RelaxNGValidator: Validation failed for '(null)' ER That happens when a map is loaded (Sometimes only when a builder is selected). Some templates may have been forgotten.

After that more errors occurr and the game is unplayable (actually the GUI will be entirely broken in some cases).

[elexis]

another example of walling that might be considered abusive IMO

[elexis]

Another example of walling that might be considered abusive IMO. The entire game was a 2 hour stalemate. No progress was achievable.

[fatherbushido]

The situation is currently better.

• Walls can be built very fast r17312 -> should be adressed (easy)
• The number of wall turrets is not limited by area ("min-distance") ->
• Walls are instantanously repaired and without any resource costs #3707 -> instantanously repaired is fixed, isn't it ?
• Pathfinder of the attacker yielding unexpected paths in mazes of obstructions ->
• Wall turrets having more range than every other unit -> fixed
• Attackers fail at dealing enough damage
  • Regular champs are not (and shouldn't be) useful in attacking walls
  • Elephants die too quickly -> fixed
  • Ranged siege doesn't deal enough damage and is destroyed by wall-turrets -> fixed
• Walls don't decay in disconnected territory #3340 -> that one should be adressed, btw why don't we allow to capture the wall towers ?

Imo I don't care that someome build some pattern like the attached screenshot, people should be free to do those stuffs, but that should be not rewarded. Excepting #3340, it seems that some other balance tweaks can do the job.

[elexis]

attachment:commands.txt:ticket:4234​ here another replay where the game ended due to boredom after 2 hours.

Analysis:

• It being a free for all with locked teams certainly made it worse
• Champs seem to die too quickly too the many garrisoned arrows.
• The build density wasn't an issue here. It's the typical issue: elephants and champs die due to the garrisoned arrows, rams are destroyed easily by garrisoned sword champions -> infinite stalemate until it is established that one player has a longer tradeline than the other, thus being able to spam more than the enemy into certain death (kill death ratio << 1).

[elexis]

Feature freeze in 2 days.

[fatherbushido]

Following an idea of FeXor and Mythos_Ruler (in 3 years ago discussions on the forum) and as we have now upgrade, I suggest what follows:

So the wall tower are just junction (without extra build restriction wich allow flexible construction) and can be upgraded to wall turret (the same but wich can be garrison and throw arrows) with a build distance restriction (same as defense tower for exemple).

I suggest the following (draft) patch: ​http://trac.wildfiregames.com/attachment/ticket/4285/upgrade_wallturret.diff This is really a draft wich works only for the macedonian walls. Stuff should be done carefully (celtic wall towers, look at roman siege walls too). It's just for getting a design/gameplay/logic ack.

[elexis]

In this release, siege engines seem so strong that it shouldn't be an issue to nuke those walls seen in the screenshots above, once the targetted player has less economy.

But I agree that the upgrading would be a great addition and would add sensible limits to the number of towers per area (which will become important if we buff garrisoned arrows for any reason in any way).

The upgrading system is in particular a better option than the other proposed patch as it will not reduce the possibilities of wall placement itself in some rare cases.

[fatherbushido]

Thanks for your input elexis.

[elexis]

So we can close the ticket once we have an upgrade patch with a minimum-distance requirement and have some kind of model available that we can use for all civs (perhaps we just blatantly reuse the existing wall turret models?).

[Imarok]

Move tickets to Simulation as UI & Simulation got some sub components.