Party members have no way to communicate readiness for queueing

[Hectate]

Per docs, if any member of a party sends matchmaking/queue, all members will also auto-queue and receive a matchmaking/queuesJoined event. A side effect of this is that if they do not have all the assets for the requested queue their game will crash on attempting to launch the battle.

We need some way for a client to communicate what its readiness is in relation to the potential queues, so it can be shared with other party member's clients, and potentially warn/block joins if appropriate.

We have lobby/updateClientStatus for lobbies, but unlike a lobby the party has no knowledge of the matchmaking queue(s) currently.

My thought is that we could add to the partyState like so:

...
    members: {
        userId: UserId;
        joinedAt: UnixTime;
        queueReadiness?: {
            [k:string]:{
                isReady?:boolean,
                assetStatus?: "missing" | "downloading" | "complete";
    }[];

The implied purpose of the [k:string] is to hold the queue ID for each queue, but the server will not need to validate it. Instead, each client can do a check against it's own list of known queues.

Of course this means we also need to add a matchmaking/updateClientStatus request to add to go along with it.

[geekingfrog]

I'm not sure about this approach. It adds another layer of state management in party.
What about instead adding a request from server to client like
matchmaking/checkReadiness

queueId: String,
version: String,
engines: [{version: String}],
game: [{springName: String}],
maps: [{springName: String}]

and the client should respond with assetStatus: missing | downloading | complete

So that when someone in a party joins matchmaking, the server sends this request to all involved client, and if they all respond with complete, then it proceeds. If a request times out or returns with missing or downloading, it fails the original request to join matchmaking.
We could extend the response codes of matchmaking/queue to encompass this type of failure.

[Hectate]

I'm not against it. I can easily automate it so that upon receiving a matchmaking/checkReadiness event, the client compares the values and sends a matchmaking/readinessReply request without requiring user input.

My immediate thought was that we really only need the queueId because if you're matchmaking you should already have the list of requirements. But a counterpoint to that is that it isn't guaranteed that you've actually ever requested the queues and may not know the required assets, so your approach solves that problem if you're comfortable sending in the list like so.

As a side thought, now I realize I'm going to want to make a "party-specific matchmaking" view, possibly a tab or something on the party screen. Functionally, just nesting the same functions in a different place.

[geekingfrog]

That wouldn't be an event though, but a request coming from the server. I don't know if the client already has support for such things, but it should.

And yes, the queueID+version is technically enough, but the client may not have requested anything yet, so including this data allow us to save a roundtrip.

[Hectate]

I don't believe there are any client response stuff in the protocol yet. Since it's an automatic thing I see no reason why it can't be set up that way, it just didn't occur to me.

Edit: I did some digging in the client and found the one client-targeting request; battle/start. I should be good to go with that as a model (since I've not put in a request<>response client-side yet).

[Hectate]

One thing to reconsider about the matchmaking join behavior:

When a player is in a party and a member of the party queues for matchmaking, all other member of the party will receive a matchmaking/queuesJoined event to let them know they are now in queue. This event is not sent to the player who originally joined the queues.

Since we will be sending the checkReadiness request to all clients, we should also send the queuesJoined event to all clients, including the initial requestor. We should have to do this because the initiating client no longer can guarantee that they joined the queue simply by the matchmaking response alone. Ideally we standardize the behavior so that it operates that way for both individual clients and party-connected clients.

[geekingfrog]

no, that should not change anything regarding queuesJoined. The call matchmaking/queue behaves as usual.

Let's say there is player A and B in a party.

• player A sends matchmaking/queue for 2v2
• server sends matchmaking/checkAssets to B (I think this name is better than checkReadiness?)
• B respond with ready
• server returns response to matchmaking/queue to player A with success
• player B receives matchmaking/queuesJoined event.

Besides the initial matchmaking/queue request which is user initiated, none of the other event/request are visible to the player.

[Hectate]

OK, so we will just have a potentially longer "pending join" status for player A. I can work with that. We are therefore assuming that player A will have already ensured it has all the assets prior to attempting a join, because they will not get the request.

Yeah I agree on the name, I'll change it (just started working on the PR).