garbagemule
commented
5 years ago I feel like this is something a generic cooldown-plugin could solve. Is there any reason to reinvent the wheel?
Open YuiHirasawa opened 5 years ago
garbagemule
commented
5 years ago I feel like this is something a generic cooldown-plugin could solve. Is there any reason to reinvent the wheel?
YuiHirasawa
commented
5 years ago Having built in support for it might work better im pretty sure a "generic cooldown-plugin" wouldn't allow me to set cooldowns after a set wave or have any other options than to run a cooldown after the join command was run.
garbagemule
commented
5 years ago I still think actual cooldowns are an odd construct for something like a minigame. It feels more like a knee-jerk reaction to a sub-par arena setup or a different throttling construct than something that's inherently useful as-is for a server. I'd like to prod a bit at the motivation to see what else we can come up with before we dive head-first into implementing cooldowns, and I'd also like to take a look at where MobArena is currently headed. But first, let's consider the drawbacks of cooldowns (only blind men believe in silver bullets) so we know what issues they introduce.
The purpose of a cooldown is to throttle how often a given event can occur. More precisely, a cooldown puts a limit on the "maximum occurrences over time" for an event. Typically, the scope of a cooldown is a player, but it can also be a group of players or server-wide. An important aspect of a cooldown is that it activates only after an event has occurred and not, by definition at least, at a fixed rate.
If the rewards for an arena are too valuable or powerful, it may be tempting to limit how often those rewards can be reaped. One way is to throttle the access to the arena itself, but this also throttles the access to the fun.
A much more obvious (and currently possible) way to throttle rewards is to make the arena more difficult, or to grant rewards "higher up" in the wave sequence. This means that you can't just "farm" the lower wave numbers, and you actually have to devote significant effort into gaining anything from the arena. Another possibility is to just remove all rewards from the arena and leave only one for the final wave. It all comes down to how important the rewards are in the server setup.
In games like World of Warcraft, reward throttling is implemented with locks and resets (not cooldowns). In a given period of time, doing anything major in a dungeon will lock you to that specific instance of the dungeon until the end of the period when everything is reset. This means that if you go back into the dungeon, you enter the same instance as everyone else who also got that instance ID. This means that people can retry after a wipe, and it means their progress is stored.
To me, it seems a lot more intuitive to introduce locks and resets on rewards (or sessions) than cooldowns on arenas. Every day, you can get all the rewards an arena has to offer - but only once. That way you know the upper bound of rewards being injected into the server economy, and people can keep playing if they want. And if they wipe at wave 10, they can just try again right away if they really want to go all the way to wave 50 with their friends a bit later the same day. In the Sessions rework, it might be useful to introduce the idea of "sticky sessions" to accommodate the idea of locks and resets.
If the number of groups wanting to play an arena at any given time is greater than 1, someone has to sit on the bench and wait. If there's a limit to how many players can join, it's pretty much first come, first served with the way the joining works right now.
The idea of an actual queue system has been discussed previously. This would allow anyone currently waiting for a session to end to sign up and reserve a seat in the next session, without having to know exactly when that session ends. Again, World of Warcraft does it really well with their Battlegrounds and Arena queue systems, also allowing for groups of players to sign up together (which introduces the bin packing problem to solve contention when group sizes don't match player limits). This is also a viable problem for the Sessions rework.
I think it's very clear that a queue system solves the fairness problem much more elegantly than cooldowns would.
A server may have any number of minigames, and the server owner may wish to "activate" all the minigames at any given day to spread out the "load", keep things "fresh", and generate some anticipation and hype for the "next up" minigame.
Cooldowns can solve this by the very nature of the mutual exclusion of minigames. If you join one minigame at 2 PM, then another one at 4 PM, and a third one at 9 PM, and they all have the same cooldown of 24 hours, it creates a bit of a "rhythm". However, this rhythm is player-specific and doesn't quite open up the possibility for a community to "look forward" to something together.
For a round robin setup, I find it very natural to use a type of scheduling plugin to open up a given minigame for a given period of time, and then close it again in favor of a new one. This "minigame cycling" is an obvious use case for a "cron-job" setup.
MobArena is currently undergoing a massive rework of its core notion of a "session" and what defines an arena. You can read more about it in the Sessions rework meta issue here on github and join the Discord discussions.
The Sessions rework is meant to tackle not only what's possible in a MobArena session, but also how those things become possible. The goal is to drive a more World of Warcraft dungeon-like type of scaffolding to allow for much more flexible arena setups that aren't limited by spawnpoints and waves the way MobArena currently is (not to say the current setups won't be possible - of course they will).
Access throttling for arenas and rewards is not out of the scope of the Sessions rework, but considering some of the previous feature requests like being able to "re-join" a session and "persisting progress" for a given amount of time, cooldowns just seem wildly out of place and more like something that will hamstring other features. And for what reason? Reward throttling? There has to be a better solution that won't negatively affect how the plugin can evolve going forward.
From my perspective, cooldowns are a knee-jerk reaction trying to solve the wrong problem. They punish players for something that isn't their fault. I'd much rather see the plugin open up the possibility of a stronger, positive incentive for a desired behavior than one that punishes another. It should be totally fine to "spam" MobArena if that's what people want to do. Don't punish them for having fun.
Feature request
Short description
Cooldowns on how often a player can enter the arena so they cant spam it for rewards
Implementation details
Maybe a True/False like player-cooldown: true/false player-cooldown-time: 500 (seconds, minutes ect.) start-cooldown-on-join: true/false start-cooldown-after-wave: [wave number] start-cooldown-on-leave: true/false
Maybe a vip section as well vip-cooldown-ignore: true/false #permission ma.vip.cooldown.ignore vip-cooldown-reduce: true/false #permission ma.vip.cooldown.reduce vip-cooldown-time: 500 (seconds, minutes ect.)
And an admin section for the cooldowns --ingame commands-- /ma admin reset cooldown [name] #permission ma.admin /ma admin set cooldown [amount] [name] #permission ma.admin