Max interval between two waves

[sepulzera]

Feature request

Short description

We should have a way to reduce waiting times between waves, while providing sufficient time to clear the waves, without giving infinite time to avoid abuse.

Motivation

There are currently two ways to setup the waves timing:

1. When setting clear-wave-before-next to false, next waves will start after the wave-interval. There are two downsides having a fixed interval. If it set too small, the given time is insufficient to clear later waves with more mobs. But if it set too high, there will be long waiting times between earlier/smaller waves.

2. When setting clear-wave-before-next to true, both downsides of way 1 will be tackled. Next waves will only be started when the current wave is cleared. But this way can be troublesome, either. Whereas in way 1 players are encouraged to clear the waves asap (or otherwise the next wave will spawn and increase the number of enemies), now players may intentionally slow down the progress by not clearing the waves. For instance they will have infinite time to heal up, before going to the next wave or even before fighting the next mob. On the other hand, the match could eventually break, if a wave can not be cleared due to technical reasons (say: glitch, like when a mob somehow manages to leave the arena).

Implementation details

There are several ways to overcome the above issues. Two of them could be:

1. When using clear-wave-before-next=false. Once a wave is cleared, the current wave should be finished, skipping to the next wave (more specific to the next-wave-delay-counter). This will reduce the waiting time between two waves, if the wave is cleared very quick. This behavior could be toggleable via a new setting end-wave-after-cleared=[true | false]. Doing so, the wave-interval can be set to a legit high maximum amount of time between two waves, without waiting times when waves are cleared quickly. But players can not camp for too long, as the next wave would spawn. Still, this could be problematic for larger/later waves that simply can not be cleared within the given interval, even when trying to clear it quickly. Therefore, this method may fit as (I think) easy-to-implement workaround but not fully eliminate the core issue.

2. When using clear-wave-before-next=true. A more suited anti-camping-mechanism could be implemented. For instance, when not killing any mob for one minute, the next wave will start. This could be configurable via a new per-arena-setting "anti-camp-time=[seconds]". Doing so, players will always have enough time to clear the waves, without eventual delays between ways (when clearing them really fast). Although players (or classes) may have sufficient time to fight in their own way (say: own speed to clear the waves), they won't have infinite time. Therefore, this method will effectively eliminate camping without the need of fixed wave-intervals. But it may be more difficult to implement and may require additional thinking.

[garbagemule]

Thanks for the request.

We can't use wave-interval because it is already used to specify the minimum amount of time between waves. Reusing it to also denote the maximum time would effectively negate clear-wave-before-next, because wave-interval is now the exact amount of time that will pass between two waves.

I feel like different arena design can prevent a lot of the types of situations that result in the "infinite wave" problem. Making sure that mobs can't "hide" and players can't kite (you could give mobs in all waves a speed potion effect or all classes a slow effect).

If we do implement an upper limit timer, what would happen when it ticks? Does it wipe all existing mobs? Or does it just let the mobs carry over to the next wave? If so, the timer would restart, causing the arena to flip into a state where clear-wave-before-next is false and wave-interval is equal to the upper limit timer value.

[sepulzera]

Well, maybe it is just wording that matters here. What I want is similar to "using wave-interval but start the next wave when it is cleared". For now, you still have to wait 110 seconds, if wave-interval is set to 120 and you clear the wave within 10 seconds. That waiting is boring.

And I doubt you can effectively prevent stop idling players with redesigning the arena only. It is too easy to runaway from the last zombie and I can not think of any kind of magic to prevent this from happening.

[garbagemule]

The problem with reusing wave-interval is that it's already in use. It has a purpose. It works as a lower bound for how often waves can spawn. Changing its semantics would break every single arena that has clear-wave-before-next set to true. We can't reuse something that already has a purpose. We'd need a new setting.

If we flip it on its head, you're actually not asking for different behavior for when clear-wave-before-next is true, but rather when it's false. You don't want to extend the time of a wave, which is what that setting was introduced for. You want the original behavior of fixed rate spawning, unless the wave has been cleared, in which case you want to skip the remaining wait time. This is not the same. In one case you have a minimum amount of time between waves, in the other a maximum amount of time between waves. Unfortunately this is starting to smell a lot like two separate modes with separate settings, and it is likely better suited for the session rework than a new feature in the current code base.

As for exploiting, I think punishment for unintended behavior is a lot less effective (and often a source of frustration) than rewards for intended behavior. I'd much rather work on something that'd help encourage the intended behavior than something that either punishes or rewards unintended behavior. If the waves just keep running if a player camps or kites, they can exploit this to circumvent the requirement that the wave needs to be cleared before the next spawns and just rack up rewards and continue to kite. You'd be rewarding unintended behavior.

[sepulzera]

Guess I was taking this too easy. I updated the request text.

If we flip it on its head, you're actually not asking for different behavior for when clear-wave-before-next is true, but rather when it's false. You don't want to extend the time of a wave, which is what that setting was introduced for.

This is the real point I think. I do want to give sufficient time for each wave. Obviously a simple fixed wave-interval will not. That is the purpose of clear-wave-before-next=true. But I do not want to give infinite time, to avoid camping or glitches.

I was just giving some ideas to put this into practice.