codosseum-org / backend

Backend service for Codosseum
GNU Affero General Public License v3.0
0 stars 0 forks source link

Design game mode abstraction #8

Open JohnnyJayJay opened 1 year ago

JohnnyJayJay commented 1 year ago

Different game modes have different criteria for what "winning" is. In the current OpenAPI definition, the schema for "game results" is still missing, as it's unclear what the common ground should be that all potential game modes have to stick to.

In other words: we need to find an abstraction, a common denominator for representing game modes, ideally in a way that clients can handle generically (without having to adjust for individual game mode implementations specifically). Finding a good, general representation of "game results" should be sufficient for this purpose, as long as game modes don't introduce completely foreign concepts that change the way of playing rounds.

So, how do we represent "game results" without introducing specialised data for every possible game mode? Once we figure this out, we may even be able to have a plugin system for game modes in the backend.

dr-hextanium commented 1 year ago

I think we should start by trying to find the common characteristics of our current potential game modes.

Is it safe to assume the following?

I think with the existence of a hierarchy to rank properties, and a field for additional metadata, most of bases are covered.

Plugins can interact with metadata themselves as they'll know what to look for. Ranking can be done without any need for plugin intervention through the hierarchy.

Thoughts?

JohnnyJayJay commented 1 year ago

All game modes will have a score, based on test-case accuracy.

Yeah. I think it's safe to say that "getting it right" is important across the board, possibly even the primary criterion for every potential game mode, as you mention in the next point.

All game modes will have a ranking system, based on a hierarchy of tie-breaking properties.

Yeah, that makes sense. Maybe this order of criteria could be exposed through the API as well.

All game modes will have either one or multiple rounds.

I think it makes sense to always think "in the general case", i.e. assume that any game mode has n rounds, but yeah.

The GameResult should probably store a reference to all PlayerRoundResults of all the rounds they played.

Players could possibly get eliminated at any point in some game modes, so it makes sense to include a list of rounds they played in the game result. With the current design it might even be possible to exclude individual players from some rounds, but not all. Although I don't know if that would be useful to actually support.

Some game modes may have to store additional metadata. Perhaps the existence of a generalized metadata property for plugins to interface with?

Yes, this makes sense and it's probably useful to have either way, but it circles back to the point that clients would have to "know" about game modes and what metadata they're offering.

For the game result, I've been thinking that there could be an "abstract score" that uses the same format/scale for all game modes and is computed by the game mode implementation in the backend. It could take into account game mode-specific data that goes beyond singular rounds. To make it "explainable", there could be a generic data structure like a list of objects describing "Criterion name", "score" and "weight" for each "thing" the game result is made up of. Or maybe the ranking compared to other players in individual categories.\ I don't see this (the "explainer") as being immediately necessary though, as per-round scoring is transparent already, and the game result is ultimately some combined version of all rounds.