Initial blind lobby / game support (part 1)

[past-due]

This PRs enables "blind" lobbies / games.

What is a "blind" lobby / game?

In a blind lobby: Players' true identities are hidden from everyone (except the host) - until the game starts
In a blind game: Players' true identities are hidden from everyone (except the host) - until the game ends

The host (currently, a spectator host) has the ability to see players' chosen player names / identities, and configure all of the game settings as expected (position, teams, etc).

You might want to also consider other configuration options, like blocking free chat, if you want to prevent players in the lobby from purposefully revealing their identities to each other.

What is the new "simple lobby" waiting room for blind lobbies / games?

A blind lobby / game can optionally be configured with an even simpler waiting room, which does not reveal the list of players, but simply:

• Basic information on the host
• The ability to check ready
• Basic status information on the lobby (number of ready players, whether waiting on the host to start the game, etc)

Implementation Details

When connecting to a game configured in any of the blind modes, each client will generate a unique new "blind identity" which is exchanged and used for communication with other clients. The host will receive the "true" player name / identity on join, which it can verify as appropriate, but will only share the "blind identity" and generic player names / details with all other clients.

Once the game begins (in "blind lobby" mode) or the game ends (in "blind game") mode, the host shares the host-verified "true" player names / identities with all other connected players. These are then "fixed-up" in the replay files so that replays play back with the true player names / identities revealed.

[ManManson]

@past-due Can you please summarize what's left to be implemented and/or fixed so that [WIP] mark can be removed?

[maxsupermanhd]

@ManManson

Can you please summarize what's left to be implemented and/or fixed so that [WIP] mark can be removed?

So this one is a bit complicated, not sure what contributes to it more, me or pastdue at this point but there is shared consensus between us two (I think) that following falls under this pull request:

• Addition of feature picks from the runtime-provided list (sketch from 13th Jan) Some translations will baked in and referenced somehow on startup/runtime to populate this list
• Additional rework on the left side of the ui allowing player to pick what they want and what they don't want (not sure would be it be 2 way or 3 way with yes/no or yes/dontcare/no), so far no final list of settings was defined but pastdue wants to fit player count in there somehow too.
• Some cmdinterface commands/responses that report to backend application what user picked.

That is gonna be it for this pull request but not all for next beta as I was told, NET_REDIRECT or similar functionality would be added to allow backend-driven matchmaking that is triggered via cmdinterface, no specifics on that so far.

I would also make a pull request with previously rejected attempt at overriding actual display names of players in the lobby via rating request. Rating response should dictate what name does player actually have to finally prevent people stealing each other names and impersonating them.

Another quiet important addition I plan this beta that would be in same pull request as name override and it would allow client to decide if they want to either

• trust host on their rating requesting
• get the url and request on it's own
• ignore rating of the host

This is required to implement multiple rating categories since client currently has no idea what category they are supposed to query from rating server. I am currently exploring options of signing rating responses and letting host deliver signed rating to clients with them treating host-provided and signed with same signature rating (as they would gather signature anyway on join by requesting their own rating) of higher priority than if they requested it on their own.

But I was told to hold on writing literally anything related to that and I already noticed that it is for a good reason since it would've caused a lot of conflicts.

[ManManson]

@maxsupermanhd Thanks for the thorough write up. I'll proceed with reviewing this part of the upcoming feature.

[ManManson]

Have a few nits, otherwise LGTM.