Had to check the thread to make sure because I was initially going off of the later date it was added to my cache, and it seems I missed it by a couple of days. Either way, yesterday marked the passing of two years since the balancer's latest version, EvenMatchV2b2, was released.
A quick read of the first post of this thread - or, indeed, skimming through the first 7-8 pages - should be enough to remind anyone of the labourious and sometimes contentious development this mod had gone through to reach its current state, with plenty of improvements and additions along the way. Still, if the stats reflecting its performance on CEONSS as laid out by Cat, Ema and other staffers in posts here are any indication, EvenMatch has consistently proven itself a force for good, helping improve ingame experience for hundreds upon hundreds of players through more balanced teams and beyond (linux server crash fix, voice chat team switching help, etc.). With the benefit of substantial ingame input received on the subject and my own 2 years' worth of experiences having played hundreds (thousands?) of matches curated for balance by EMv2b2 to boot, once again in this thread today I feel compelled to thank Wormbo for all his persistent effort in delivering such a fine piece of UScripting work.
So, what does one get for its second birthday to a mod that has
plenty going for it then? Why, the gift of suggestions for some more improvements based on collected notes from all this time, of course
. Below you'll find 4 such items, plus an extra idea:
1. "teams" calls shouldn't bypass key/valuable player checks
: as covered elsewhere in this thread, EvenMatch can apply nuanced selection criteria for swapping players during rounds to restore balance, employing the concepts of "valuable" or "key" player to do so (one's scoreboard rank being above a certain percentile in the former's case, having special tactical advantages like carrying a dmg. amp or superweapon in the latter) based on countdown timers that remove these filters bit by bit as no suited candidates are found and the count nears zero. Handling "teams" calls can help when it expedites a rebalance check that could otherwise be coming 30secs or more later, but catering to prior "instant gratification" expectations of certain communities has come at the cost of the mod immediately jumping to "panic mode", picking someone with little regard to their situational team value from the bigger team. Rather than zeroing ForcedBalanceAttempt in Timer() after a valid "team" call, why not instead show a "Rebalancing teams in a few seconds, please hold" message to tide over the impatient and give the mod those precious 7secs to work through its process, ensuring that, say, the team's mino/dragon/falcon or other VIP vec driver won't randomly be snuffed out when they're most needed?
2. Add an anti-Ping-Pong logic check
: EM already employs a RememberForcedSwitch function to track recent switches and so prevent uncooperative players from quickly moving back to their previous team after a rebalance. Trouble is, it's been witnessed in some cases that the same player will be shifted from one team to the other and later back again during the same match, and there's no mechanic to track or prevent this sometimes necessary but still very dispiriting situation; on rare occasions, I've heard people say that's happened to them even three times in a match. Including an additional table to track a match's switches in general and a rule that would exempt from further swapping any player already subjected to 2 switches seems as needed here as it'd be straightforward enough to implement.
3. Protection for swapped drivers' vehicles
: the way EM currently swaps not-dead players that have been marked for team transfer is by simply calling the standard Died() function for them, which, in the case of players controlling a vehicle pawn means the vehicle gets blown up, along with any additional passengers on it, too. Hampering other team players' progress and depriving important team resources along with the excess player that gets moved, especially early on in a round, doesn't seem like a fair proposition (or a good look for the mod) just for restoring team balance, and that's even before considering that the most loaded vecs are usually the more important ones. To offer an example I witnessed myself, seeing a mino blow up with all 3 players on board just a few seconds after a match starts and it pulls off its spawn point because someone from the other team, already down by 1 player, lost their connection and the mino driver was randomly picked after a "teams" call can get people pretty angry and cause EvenMatch to be regarded more as the Grim Reaper than Lady Justice.
All that would need doing to fix this would be to add a single line before MutTeamBalance.uc:625
that would eject the doomed player from the vec, leaving the other passengers and their ride intact, then instead of calling a Died for the vehicle, follow with what the next "else if" does and call it for the newly evacuated xPawn; if doing so in the same tick wouldn't be feasible, the other option might be to use a new bool flag there, and call a Timer, say, 0.1secs later that, with some added code, would do the Died() deed. Alternatively and possible within the same tick I think, Died() could be skipped for vehicle drivers and the mod could instead momentarily change the vehicle's DriverDamageMult to 875.0 (that's 350/0.4), followed by dealing 0.4hp damage at the driver's location, enough to kill a 199hp plus 150 shield player without causing 1hp damage to the vehicle, then, finally, restoring the damage multiplier to its default value.
4. Delay delivery of pre-match teamsay messages
: the longer the server pre-game duration, the likelier players are to start discussing team strategies. Trouble is, you can't tell which team you'll end up on before the match actually starts because a last second arrival could lead to EvenMatch arranging teams differently. This has lead to the category of players more familiar with the issue simply not discussing strats during pre-game - aka the point when it'd otherwise be the most useful to do so - and the rest that opt to blurt out where they'll be taking what vehicles to most likely end up handing out tips to their opponents, making both teams resemble the latest U.S. White House situation: leak central.
While the first half of the problem, i.e. restoring team organizing utility to the pre-game window, can't be helped due to the impossibility of acquiring necessary future information at the present, the second part revolving around protecting what's supposedly said in team confidence could be addressed by suppressing and delaying delivery of all non-spectators' teamsay messages, optionally displaying to senders a relevant "Withholding team chat until match starts" note, until the match starts. EvenMatch already uses EvenMatchTeamsCallSpectator as an ingame text monitoring resource for "teams" calls, so tacking on some PreBeginPlay functionality and using a reasonably sized array (say, 20-30 entries) to temporarily hold players' teamsay strings (max 127 chars each, IIRC) until match start seems doable enough.
* (Bonus) Anti-marathon ONS scoring feature
: using the quick round feature, EvenMatch has managed to ensure servers can get at least one balanced round out of any map, sometimes that being preceded by a shorter (max 7mins on CEONSS, I believe) stacked first round. For communities that want to get more than one balanced match out of their maps, however, the stock game only offers the option of raising GoalScore to 3 and playing to reach that via RT or OT round wins, with all the associated gameplay baggage
that brings along, namely the worst case scenario transforming from a 7-10min, 1-round drive-by to that of an exhausting 65-75min, 5-round marathon. The only way to break out of this bind is to bend the default (ONSOnslaughtGame) rules, say, by making all round victories add only 1 point to teams' score regardless of the time it took to get there, and then bringing GoalScore down to 2. While this sacrifices some gameplay nuance (renders winning early meaningless), this affords a minimum of 2 rounds in a map and a maximum of 3, bringing down the worst case scenario of being trapped in a map from 65-75mins to a much more tolerable ~45min ceiling.
Since a mod that allows just that to work has been employed on the DW server for eons, namely DWOnslaught.u
, and EvenMatch already has functionality that monitors round completion time as well as can potentially alter/reset teams' scores if needed, embedding the former's extra bits into the latter could be a way to expand EM's value to the UT/ONS community without having to design any new tool or resource from the ground up. While I don't recall what impact running the DWOnslaught mutator might have on a server's whitelist status, embedding it in EM would certainly help such a server stay there if nothing more exotic was also in use.
Lastly, the aforementioned gameplay nuance loss problem arising from the apparent equalization between regulation time and overtime wins under DWOns rules is something that's been gnawing at me for a good long time. Out of several ways I've considered possible to restore some difference between the two while still giving only 1 point, the one I now believe to be the best, in terms of complexity to develop vs. tactical depth and non-bias, has to do with reducing the core health of any team that lost an RT round at the start of all remaining rounds by a non-insignificant amount ranging between 10% and 15% (or 500 to 650-ish hp out of a 4,500 max). Adding this last bit just as food for thought here.
Before anyone asks, I'm well aware of Wormbo's last statements regarding the probability of him returning and doing further work on this or any other UT project, but since the odds of me trying to do this myself and ahead of all the other ONS stuff I've already got on my plate (my own, comparatively diminished, UScript fluency notwithstanding) are about as good, I figured I might as well post this in case it serves as inspiration for anyone else passing through with enough experience and coding time on their hands to take this up for everyone's benefit - Crusha maybe, who knows?
Regardless of what comes of these ideas, I think it merits wrapping up this celebratory feedback post by thanking Wormbo once again for all he's delivered so far on this front and many others. Whatever you're doing these days, I hope it's equally meaningful and brings as much excitement to people as your contributions have done for the UT community, sir