Queueing/many player support mini-RFC

[PabloMansanet]

The problem

With the resolution we're aiming for and the map size that we have, there's a clear limit to the number of players that can compete on the same arena. From my initial testing, I'd say 12 simultaneous players is about as far as we can go before we run out of breathing room. 8 would be ideal.

We want more than 8-12 players to participate, especially after deciding we want to open the event to outside participants and stream it on twitch, so we need to find a way to have everyone play for a fair amount of time and keep them engaged.

A queue system proposal.

I propose we rework the file upload/file handle systems to behave under a simple set of rules:

• If the current game has fewer than MAX players, simply add the players to the current arena.
• Players that die should continue to respawn indefinitely in the current round, taking priority over the queue. This is important not to discourage inexperienced devs by pushing them to the back of the queue after an unfortunate death. The penalty for dying should be losing points, not losing the opportunity to play!
• When a player tries to join a full match, they're instead added to the global queue.
• When a match ends, all players on it get pushed to the back of the queue, and the next set of MAX players get added to the next round.
• Players should be encouraged to re-upload their wasm blobs as much as they like, so reuploading should not affect position in the queue. Reuploading should not even despawn the character: The AI change will happen live.
• When a player is inactive (no new uploads) for a long time and their character has played enough rounds, it will be removed from the queue (this is just to prevent idlers that left the twitch steam long ago from taking space).

There's a couple implicit principles in the proposal that I think we should maintain even if the implementation particulars change:

• When a character starts playing, they should always get five minutes of play. This is why I think it's better to throw in a new set of challengers every round, instead of constantly churning them in the same round every time someone dies.
• People should felt encouraged to experiment. Knowing that your character will stay in the round no matter how badly you do will make people less scared to try crazy things.

An illustrated example

For the example, I'm going to assume that MAX = 4 (the number of players that can play at the same time in an arena) and that players are named alphabetically from A to Z.

• The first round starts, and the game field is empty. 3 minutes pass as people fiddle with the logic.
• Players A, B, C, D join, and they appear in the arena.
• Players E and F join, and the queue is now [E, F] . Those players are notified of their position somehow.
• Player A dies and respawns, but the queue situation is unaffected.
• Players E and C decide to reupload their AI. C continues playing normally without respawning, and E's position in the queue is unaffected.
• The round ends and all players in it are pushed to the back of the queue, which is now [E, F, A, B, C, D].
• The next round starts, with players [E, F, A, B].
• Player G joins, and the queue is now [C, D, G].
• ...etc

As always, open to thoughts, suggestions. implementation concerns, etc :) I'm also unsure how much of this process we want to represent in the UI. Maybe some sort of message signaling who's playing the next round could be fun!

[strohel]

@PabloMansanet this looks good! I like the rules that encourage players to experiment and make mistakes along the way.

I'd like to add some requirements on the implementation/operational side that I thing would be useful during the event:

Operational requirements (suggestion)

• We'll likely restart both the game binary and the upload server binary during the game event (perhaps to quick-fix bugs). Such a restart should not catastrophically reset things. (okay to replay current round, but should not drop the queue etc.)
• Currently the upload server and game engine communicate only via the filesystem. It would be cool to keep the filesystem-only communication scheme for simplicity and easy human intervention.

Queue system proposal questions

When a match ends, all players on it get pushed to the back of the queue, and the next set of MAX players get added to the next round.

Would it be okay to instead do nothing with the players when a round ends? I.e. that they would need to re-upload their WASM (even if unchanged) if they want to participate in the next rounds?

In theory that would not guarantee 5 minutes of play for every new player if they join late in the round - but that can only happen when there is nobody in the queue. Meaning that such a player can reupload their WASM and very likely to get into the next round anyway.

Reuploading should not even despawn the character: The AI change will happen live.

We already have this on the game engine side, right? (as long as the upload server replaces the correct wasm file)

---

Coming up with a slight variation of the system, one that could be particularly straightforward to implement AFAICS. I'll mix in some implementation details I'm thinking of.

Rounds system proposal (slight modification of top of queue system proposal)

• Instead of past, current round and a queue, we would have: past, current, and future rounds
• Rounds would be numbers 1, 2, ..., and every round would have its same-named folder 1, 2, ...
• Logic on the upload server when a WASM file is uploaded (under given API key):
  • If this API key already has a WASM file in any of the current or future rounds, overwrite that file.
  • Otherwise put it to the first non-full non-past round ~ folder (could be the current round, or could trigger creation of a new round).
  • Inform the user which round they were put to in HTTP response. That way they can roughly tell when it is going to be their turn.
• Game engine would visibly show the current round number during gameplay and on the victory screen.
• When a round is finished (right before the victory screen is shown), game engine would put round-finished.marker file into current round folder, and increments its current_round.
  • This is how the upload server knows which rounds are past (and current and future).
  • This is the only communication in the direction game engine -> upload server.
• When the game engine is started, it would try to find the lowest-named folder without the round-finished.marker file to determine the current round.

What do you think?

I think I can start implementing basics of this on the upload server, and see how far will I get before my time off. CC @bschwind.

[PabloMansanet]

* We'll likely restart both the game binary and the upload server binary during the game event (perhaps to quick-fix bugs). Such a restart should not catastrophically reset things. (okay to replay current round, but should not drop the queue etc.)

That's a good point that I hadn't thought about!

Would it be okay to instead do nothing with the players when a round ends? I.e. that they would need to re-upload their WASM (even if unchanged) if they want to participate in the next rounds?

That makes more sense probably, and it's an easier condition to explain :) also allows people to opt out of playing if they just want to observe.

Reuploading should not even despawn the character: The AI change will happen live.

We already have this on the game engine side, right? (as long as the upload server replaces the correct wasm file)

yup!

Rounds system proposal (slight modification of top of queue system proposal)

I really like your proposal! Feel free to get started on it and I'll help with what I can :)

[strohel]

Resolved by #46.