[Community mod] Melee rebalance

[real_tabasco_sauce]

15 hours ago, chrstgtr said:

Seems like option 2 is potentially less work if we have to adjust anything/un-commit anything. Option 1 doesn't seem like it really saves any time

So should I make a merge request for just these?

https://code.wildfiregames.com/D5055 (melee rebalance)

https://code.wildfiregames.com/D5054 (along with other ele changes)

https://code.wildfiregames.com/D5053 (catapult changes)

I guess I can't just blanket update all of simulation because those files probably reference things that wont be in a26 (like art files). There aren't really a whole lot of other really important balance changes, but is there anything else I should add? Maybe the new maury hero auras.

maybe https://code.wildfiregames.com/D4964? or should it wait?

 

Edited June 21, 2023 by real_tabasco_sauce

[real_tabasco_sauce]

on second thought, maybe I will just make a single merge request for all of the a27 gameplay changes + the ones from above. Maybe just the important ones.

[real_tabasco_sauce]

https://gitlab.com/0ad/0ad-community-mod-a26/-/merge_requests

Ok they are there. Let me know if you recommend any last minute changes.

Also, not sure why the pipeline is failing. Are they still able to be merged, or do I need to change something @wraitii@Stan`?

[alre]

I'm very opposed to non-random building ai.

[wraitii]

5 hours ago, real_tabasco_sauce said:

Also, not sure why the pipeline is failing. Are they still able to be merged, or do I need to change something @wraitii@Stan`?

Seems like it's just not running. Presumably because you don't have the Developer role https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html#prerequisites

Edit: ran them, looks like it fails 'cause the pipeline is broken.
If people are OK with the changes I can merge them regardless

[chrstgtr]

8 hours ago, real_tabasco_sauce said:

So should I make a merge request for just these?

https://code.wildfiregames.com/D5055 (melee rebalance)

https://code.wildfiregames.com/D5054 (along with other ele changes)

https://code.wildfiregames.com/D5053 (catapult changes)

I guess I can't just blanket update all of simulation because those files probably reference things that wont be in a26 (like art files). There aren't really a whole lot of other really important balance changes, but is there anything else I should add? Maybe the new maury hero auras.

maybe https://code.wildfiregames.com/D4964? or should it wait?

 

I would do melee rebalance, ele changes, and cata. That is one really big change and two more isolated changes. I wouldn't do maurya hero auras (can't remmeber them exactly) because they may stack with any of the other changes and because that would be two changes for Maurya (ele and heroes). I wouldn't do building AI because that is another really big change, which will make the impact of melee rebalance more difficult to understand.

If we knew that we had like 6 months to test then I would want all of them in. But with an undetermined amount of time, I don't want to get squeezed and not understand enough of the impact for anything. With three changes we should at least have a pretty good idea about each of them. We can revisit in another month or so to see if we should have another community mod update. 

[real_tabasco_sauce]

Ah, well @chrstgtrthe reasoning there is that the Maury heroes are already committed. The idea is to test the current gameplay of the release candidate + those 3 new changes.

maury and Han will be the only 2 civs affected by the already committed patches. Fortunately, if we want to just assess the catas, eles, and melee rework without the heroes confounding, all we have to do is play other civs.

I left the buildingAI patch off since that probably needs to wait until after a27.

Edited June 21, 2023 by real_tabasco_sauce

[real_tabasco_sauce]

10 hours ago, alre said:

I'm very opposed to non-random building ai.

I don't want to make too big a side topic, but care to elaborate why?

[real_tabasco_sauce]

9 hours ago, wraitii said:

Edit: ran them, looks like it fails 'cause the pipeline is broken.
If people are OK with the changes I can merge them regardless

Do you think it is worth it to open a poll? Maybe not, I think most players will be happy to get a preview of some a27 content, but there might be complaints about shaking up the meta.

To alleviate those complaints, It would be good to keep 26.4 on mod.io.

[BreakfastBurrito_007]

I like the non-random building ai, but I think there should be a target choice component of it as well.

[alre]

28 minutes ago, real_tabasco_sauce said:

I don't want to make too big a side topic, but care to elaborate why?

- I think it goes in the wrong direction design-wise

- raids don't need to be nerfed

- buildings don't need to be nerfed against large armies.

[real_tabasco_sauce]

I guess we have seen no complaints for making a 5th release of the community mod. @wraitii is there still time to do this?

would it be possible/good to keep the 4th version on modio in case people want to keep playing that version?

[wraitii]

8 hours ago, real_tabasco_sauce said:

I guess we have seen no complaints for making a 5th release of the community mod. @wraitii is there still time to do this?

Sure

8 hours ago, real_tabasco_sauce said:

would it be possible/good to keep the 4th version on modio in case people want to keep playing that version?

I think ModIO keeps past versions automatically, though from within 0 A.D. you won't get it

[real_tabasco_sauce]

https://gitlab.com/0ad/0ad-community-mod-a26/-/merge_requests/29

new version uses repeat time to nerf ranged units damage. This is in the interest of performance and so that the same number of units may 1 shot an enemy.

[ChronA]

7 hours ago, real_tabasco_sauce said:

This is in the interest of performance and so that the same number of units may 1 shot an enemy.

Smart.

[LienRag]

I'm not good enough at 0ad to talk numbers, so I didn't read past the few posts at the beginning.

But though I understand the concern, my take is that the main difference between ranged and melee units being armor is quite accurate historically.

That doesn't mean that melee units shouldn't hack quickly through unarmored ranged units if they can catch them, though.

As I wrote many times, we won't have anything like historical battles as long as we don't have morale, but it doesn't prevent trying to do a not-too-bad balance in the meantime.

Well-armored melee should be extremely hard to kill for archers, and only vulnerable to slingers (take a stone to the helmet, yes it won't crush your skull, but you'll still feel it hard).

To approximate the historical role of harassment by archers, could it be possible to have damage diminish when the health diminish ? Once archers have already wounded the weakly armored parts of the body, the armored part is quite immune to arrows...

Also, good balance (and historical accuracy, see Devereaux's blog post on kiting) would be to have ranged damage heavily dependent on, well, range : if you want to be efficient, you shoot at close range (which would make steep cliffs so much more of a strategic asset), if you just want to harass, you shot at long range.

We need a specific formation for melee units that allows for a short charge, as that's the way historically that hoplites were able to destroy ranged units (which are usually quicker). Turning around (to run in the opposite direction) should take some time (for everyone, but here it's important for the ranged units, so as to make them unable to dance too easily).

I guess that's the good balance would be to make the "turning around" time take as much time as the short charge, so when the charge starts it's too late to turn around.

And if ranged units still "dance" by turning around before the enemy is close enough to charge, well it's (more or less) how they were used historically.

[LienRag]

Another idea, but not sure if it's technically doable : have damage from archers to units with shields being greatly reduced by shields, that is from the front (with the shielded moving to face the greatest threat when at rest, if shot upon).

That should have huge (and very interesting) tactical consequences.

[alre]

5 minutes ago, LienRag said:

Another idea, but not sure if it's technically doable : have damage from archers to units with shields being greatly reduced by shields, that is from the front (with the shielded moving to face the greatest threat when at rest, if shot upon).

That should have huge (and very interesting) tactical consequences.

possible, but in my tests this does not translate well on 0ad battles. units turn at all times in a whim.

[LienRag]

That seems to be a problem of implementation.

Easy fix would be to remove this shield bonus when on "no formation" and make sure that all formations prevent turning at a whim (which most formations actually does AFAIK).

Or if some formations do allow turning at a whim, remove the shield bonus for them (and make that clear in the hover-text !).

[alre]

On 22/10/2023 at 5:34 PM, LienRag said:

That seems to be a problem of implementation.

Easy fix would be to remove this shield bonus when on "no formation" and make sure that all formations prevent turning at a whim (which most formations actually does AFAIK).

Or if some formations do allow turning at a whim, remove the shield bonus for them (and make that clear in the hover-text !).

all formation allow for units to turn, unless the formation is moving, and the units are moving along. this means that if units are fighting they will be turning indipendently anyway.

[panda]

On 26/03/2023 at 11:00 AM, Atrik said:

Maybe rams should have some hack resistance with this. Otherwise they'll have no more roles as they'll be too brittle against melees AND melees would now be decently effective against buildings.

I thought about this too when I first @real_tabasco_sauce's post. The rebalance could give double advantage to defensive structures. 1. With less armor, the buildings will kill units faster 2. More hack for swordmen inside buildings will kills attacking siege faster

[LienRag]

2 hours ago, alre said:

 this means that if units are fighting they will be turning indipendently anyway.

That's... not how a Phalanx is supposed to work, to say the least.
And to pick just one example.

Thanks for the info anyway.

Is the "units turning at a whim" behavior fixable ?
That units turn to face their threat is not a problem, but there should be some consistency in their facing...

[real_tabasco_sauce]

Yeah, I already have siege and building's hack armor adjusted to essentially cancel out the 50% increase in melee damage. So the time it takes for melee units to kill buildings and siege is the same.