Observing the latest EvenMatch version's reports n' general feedback received on both threads over the recent period (but mostly on the Omni msg. board, if I'm honest), I couldn't help but notice that repeated complaints started clustering around the two issues of general balancing performance during matches, on the larger scale, and acceptability of individual swap choices during rounds, on a narrower perspective. Given how the degree of these alleged failings varies from person to person, as well as how differences in standards and inherent biases can creep in and distort one's perception of what they consider balanced or reasonable decision-making in the first place, the thought occurred that perhaps the macroscopic evaluation of whether EvenMatch has truly been contributing to more balanced gaming sessions or not could be assisted through the introduction of more objectively gathered observations to the discussion, namely through the more systematic collection of data (my favourite type of fact
).
Put more practically, what I'm proposing for consideration here is the addition of a "verbose mode" beyond the scope of the current debug output, which server admins could opt to enable in order to have the mutator create and maintain a steady, but not resource-heavy, output of balance-relevant measurements at regular intervals, but also during any other event specifically pertaining to EvenMatch's actions (pre-match team shuffling, routine mid-game soft swaps, manual rebalancing calls, etc.), either in the main server log or (ideally) in a different, dedicated one for easier perusing.
Helpful information that could be gleaned after each match could include a "heartbeat", where the state of balance during a round would be written to the log every, say, 30secs as measured through the already existing Progress metric, and optionally also the number of nodes each team was holding, as well as their cumulative PPHs (or just the difference?) at the time of polling. This would allow for easy rebuilding n' visually depicting the course of rounds n' matches later on, and after reviewing a large enough sample size to gain the necessary experience and understanding of what balanced matches truly look like in terms of graph slopes, the conversation around determining whether any specific match that EvenMatch curated was balanced or not can hopefully be carried out in a much more levelheaded n' pragmatic manner after the fact, rather than be formed mostly on the basis of bruised egos and emotion-affected impressions - which all human beings are susceptible to, myself included.
Additionally, as already touched on in my last post on page 1 here, the crucial bits of info that influenced the reasoning behind each swap and team changing event could also be included for later cross-referencing (reason for swap event [pre-match, routine, manual call, etc.], teams size difference, state of chosen player [walking, idle, dead, etc.], score percentile placement of chosen player), so that should anyone report some seemingly unexpected or counter-intuitive behaviour later on, pulling the relevant data and reviewing exactly what EvenMatch saw as it decided who wasn't a key player that should be moved (versus what the player later claims) can constitute the basis of a more reliable debugging & assessment process.
Much like with general logging standards, such entries for each map/session could be bookended with a match start time stamp, as well as map name & active mutators info for easier bookkeeping n' retrieval.
Assuming my estimates of an average of 16 player swap events per match and ~35mins for matches' length are realistic enough, the above suggestions shouldn't produce more than 90 log entries per match on average (max could be ~80% higher), a value that seems within the reasonably low side of the realtime server resources consuming spectrum. A simple script to append such a daily EvenMatch log output to a cumulative one, while clearing it afterwards could additionally be run once a day to ensure fluid performance for the server HDD, too, as part of routine admin maintenance.
All in all, the goal of a "verbose mode" idea is for it to assist in EvenMatch getting a fair[er] shake by clearing up as much as possible the fog of subjectivity typically associated with the discussion of balancing in ONS matches. As community members continue to report and help assess the mutator's true hits n' misses, shaping its comprehensive benefits n' drawbacks profile, this might just constitute a key part in Wormbo getting the right info to cut through the noise n' correctly identify and stay on the right path for the remainder of its development so that everyone can benefit the most out of EvenMatch's ultimate performance.
PS: Had forgotten about it, but two instances on the same page is pretty much screaming for attention, so quick tip to Cat here: preventing pre elements (which phpBB uses to wrap around blocks of code or other kinds of raw text dumps) from horizontally screwing up pagination can easily be done by adding a
white-space: pre-wrap; rule to the .codecontent class assigned by default to pre elements in stylesheet.css, starting from line 688.
.