Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "Change join queue request for only one queue (#31)" #33

Merged
merged 1 commit into from
Sep 2, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 16 additions & 8 deletions docs/schema/matchmaking.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,14 @@
The matchmaking cycle works as follows:

1. Clients should first retrieve a list of all the available queues from the server using [list](#list).
2. Clients should then queue for one or more of these queues by sending the queue id in several [queue](#queue) requests.
2. Clients should then queue for one or more of these queues by sending an array of the queue ids in a [queue](#queue) request.
3. The server can send periodic updates about the status of the search as a [queueUpdate](#queueupdate) event.
4. When a match is found, the server should send a [found](#found) event along with the id of the queue of the found match.
5. Clients can then ready up by sending a [ready](#ready) request. The number of readied players should be sent to clients via the [readyUpdate](#readyupdate) event.
6. To cancel queueing, or to decline a found match, clients should send a [cancel](#cancel) request.
7. If a client fails to ready up for a found match, the server should send a [lost](#lost) event, and the queueing phase should resume.
8. Once all players are ready, the server should send a [autohost/battleStart](#autohost/battleStart) request to a suitable autohost client. If the autohost doesn't respond quickly, or if it sends a failed response, the server should repeat this step.
9. Once the autohost has successfully started the battle, the server should then send [battle/battleStart](#battle/battleStart) requests to the users.

9. Once the autohost has successfully started the battle, the server should then send [battle/battleStart](#battle/battleStart) requests to the users.
---
- [cancel](#cancel)
- [found](#found)
Expand Down Expand Up @@ -565,7 +564,7 @@ export interface MatchmakingLostEvent {

## Queue

Queue up for matchmaking on the specific queue id.
Queue up for matchmaking. Should cancel the previous queue if already in one.

- Endpoint Type: **Event**
- Source: **User**
Expand Down Expand Up @@ -593,8 +592,14 @@ Queue up for matchmaking on the specific queue id.
"data": {
"title": "MatchmakingQueueRequestData",
"type": "object",
"properties": { "queue": { "type": "string" } },
"required": ["queue"]
"properties": {
"queues": {
"type": "array",
"items": { "type": "string" },
"minItems": 1
}
},
"required": ["queues"]
}
},
"required": ["type", "messageId", "commandId", "data"]
Expand All @@ -612,7 +617,10 @@ Queue up for matchmaking on the specific queue id.
"messageId": "nisi deserunt",
"commandId": "matchmaking/queue",
"data": {
"queue": "nisi deserunt"
"queues": [
"nisi deserunt",
"nisi deserunt"
]
}
}
```
Expand All @@ -627,7 +635,7 @@ export interface MatchmakingQueueRequest {
data: MatchmakingQueueRequestData;
}
export interface MatchmakingQueueRequestData {
queue: string;
queues: [string, ...string[]];
}
```
### Response
Expand Down
10 changes: 8 additions & 2 deletions schema/compiled.json
Original file line number Diff line number Diff line change
Expand Up @@ -1521,8 +1521,14 @@
"data": {
"title": "MatchmakingQueueRequestData",
"type": "object",
"properties": { "queue": { "type": "string" } },
"required": ["queue"]
"properties": {
"queues": {
"type": "array",
"items": { "type": "string" },
"minItems": 1
}
},
"required": ["queues"]
}
},
"required": ["type", "messageId", "commandId", "data"]
Expand Down
10 changes: 8 additions & 2 deletions schema/matchmaking/queue/request.json
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,14 @@
"data": {
"title": "MatchmakingQueueRequestData",
"type": "object",
"properties": { "queue": { "type": "string" } },
"required": ["queue"]
"properties": {
"queues": {
"type": "array",
"items": { "type": "string" },
"minItems": 1
}
},
"required": ["queues"]
}
},
"required": ["type", "messageId", "commandId", "data"]
Expand Down
4 changes: 2 additions & 2 deletions src/schema/matchmaking/README.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
The matchmaking cycle works as follows:

1. Clients should first retrieve a list of all the available queues from the server using [list](#list).
2. Clients should then queue for one or more of these queues by sending the queue id in several [queue](#queue) requests.
2. Clients should then queue for one or more of these queues by sending an array of the queue ids in a [queue](#queue) request.
3. The server can send periodic updates about the status of the search as a [queueUpdate](#queueupdate) event.
4. When a match is found, the server should send a [found](#found) event along with the id of the queue of the found match.
5. Clients can then ready up by sending a [ready](#ready) request. The number of readied players should be sent to clients via the [readyUpdate](#readyupdate) event.
6. To cancel queueing, or to decline a found match, clients should send a [cancel](#cancel) request.
7. If a client fails to ready up for a found match, the server should send a [lost](#lost) event, and the queueing phase should resume.
8. Once all players are ready, the server should send a [autohost/battleStart](#autohost/battleStart) request to a suitable autohost client. If the autohost doesn't respond quickly, or if it sends a failed response, the server should repeat this step.
9. Once the autohost has successfully started the battle, the server should then send [battle/battleStart](#battle/battleStart) requests to the users.
9. Once the autohost has successfully started the battle, the server should then send [battle/battleStart](#battle/battleStart) requests to the users.
4 changes: 2 additions & 2 deletions src/schema/matchmaking/queue.ts
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,10 @@ import { defineEndpoint } from "@/generator-helpers.js";
export default defineEndpoint({
source: "user",
target: "server",
description: "Queue up for matchmaking on the specific queue id.",
description: "Queue up for matchmaking. Should cancel the previous queue if already in one.",
request: {
data: Type.Object({
queue: Type.String(),
queues: Type.Array(Type.String(), { minItems: 1 }),
}),
},
response: [
Expand Down
6 changes: 3 additions & 3 deletions test/cjs/validator.test.cts
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ describe("request", () => {
commandId: "matchmaking/queue",
messageId: "123",
data: {
queue: "1v1",
queues: ["1v1"],
},
};

Expand All @@ -24,7 +24,7 @@ describe("request", () => {
assert.equal(isValid, true);

if (isValid) {
assert.equal(command.data.queue, "1v1");
assert.equal(command.data.queues[0], "1v1");
}
});

Expand All @@ -35,7 +35,7 @@ describe("request", () => {
messageId: "123",
data: {
// @ts-expect-error
queue: 123,
queues: [],
},
};

Expand Down
4 changes: 2 additions & 2 deletions test/esm/validator.test.mts
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ describe("request", () => {
commandId: "matchmaking/queue",
messageId: "123",
data: {
queue: "1v1",
queues: ["1v1"],
},
};

Expand All @@ -24,7 +24,7 @@ describe("request", () => {
assert.equal(isValid, true);

if (isValid) {
assert.equal(command.data.queue, "1v1");
assert.equal(command.data.queues[0], "1v1");
}
});

Expand Down