The performance testing I've done is limited to one service, one team with it running and one "team" with an invalid IP (and thus not running). The attack info step runs in around 10ms fairly consistently on my system even after a large number of rounds, however this scenario is obviously not necessarily representative of real world game load. I'm not sure what the best way to stress test this would be.
The primary reason for the sorting when grouping the data is order in the JSON for human readability as well as to avoid giving away any kind of internal state that might be deduced from the natural order in the database. We could drop that for better perf.
The inheritance for the attack info structures looks a bit odd but it seems to me like the best option I am aware of without complicating everything unnecessarily.
The available teams field is just based on the best round team service states and not on the more generic active/inactive distinction-- I'm split on whether that's a good or bad thing. On the one hand it's more granular meaning less potential wasted traffic, but on the other the target teams might actually be up but the checker just missed them. In any case, if there are attack infos, they'll be in the services section regardless, so you can always check that if you want to make sure, so this seemed like a decent compromise. It might make more sense to just drop those checks entirely and just show every active team regardless of their current service states. We could also just not have this section at all since it's somewhat (but not entirely) redundant with the main services section.
The handling for missing team/service names seems a bit superfluous so we could throw that out too and just assume non-null, I don't know what the general policy for engine code is in that regard.
attack.json is currently not archived over time like scoreboard.json is. Seemed unnecessary but I don't know what the exact goals there are so if that's something we want it's very straightforward to add.
Some notes:
attack.jsonis currently not archived over time likescoreboard.jsonis. Seemed unnecessary but I don't know what the exact goals there are so if that's something we want it's very straightforward to add.