Replies: 3 comments 17 replies
-
|
There are some issues here because I while it doesn't have to be the same on the server, it can't conflict. Lobby refers to the period prior to a game starting and is separate from a game (battle). I've been calling Chobby a client application or lobby client. Client is the connected representation of a user, you can't have a client without user data (but you can have a user without client data if they're not connected). Bot vs AI is a good distinction to make, I agree with it completely. For Host I'd rather swap to founder as host can refer to the machine/instance hosting the game itself and that might be an important distinction to make at a later stage. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Regarding Menu/Lobby/Client/Application or whatever, I agree it's probably not important - I don't think it's gonna come up much apart from maybe the initial login command where it currently sends things like The A battle is the same entity as an ingame battle, as a user is the same entity as an offline user - it's just they have a slightly different state, which I think would be better represented as sub-data, e.g. {
userId: 10,
username: "Bob",
rank: 12,
status: "offline",
battleStatus: null
}
{
userId: 10,
username: "Bob",
rank: 12,
status: "singleplayer",
battleStatus: null
}
{
userId: 10,
username: "Bob",
rank: 12,
status: "battle",
battleStatus: {
battleId: 123,
ready: false,
teamId: 1
}
}
My concern with separating 1:1 entities in the protocol responses is that protocol-clients are very often (if not always) going to want to keep these entities tightly coupled, and having to request each entity separately and handle the responses separately makes things a lot messier and more prone to these related entity datas from being desynced. That being said, I understand the technical reasons for wanting to keep these entities separate from a server perspective, and if it's awkward for the server to split entities in requests from the clients or merge entities in responses to the clients then I'd be willing to compromise in the sake of progress. So in terms of that compromise, and to bring it back to terminology, I'd be happy enough with request: {
"cmd": "account.list_userclients",
"data": {
"ids": [12, 34, 56]
}
}response: {
"cmd": "account.list_userclients",
"data": {
"userclients": [
{
"user": {
"user_id": 12,
"username": "Bob",
"rank": 30
},
"client": null
},
{
"user": {
"user_id": 34,
"username": "Tim",
"rank": 30
},
"client": {
"battle_id": 101,
"ready": false,
"team_id": 1
}
}
]
}
}So long as all requests and responses are only for UserClients then it shouldn't be too difficult for client applications to keep these synced. Might be good to get some second opinions in here too btw. |
Beta Was this translation helpful? Give feedback.
-
Given it is an application running on the user's computer are you thus happy with application? It's implied you are but I want to ensure we're on the same page. I will proceed with discussions assuming you are but it's not in the protocol until you say so.
Not quite. There are 3 stages to a game: pre-game (lobby) in-game (moving units around) and post-game (stats, rating changes etc). There are a number of differences in both how the server and how applications would interact with each of these 3 states. I'm happy to have an overall term to cover all 3 but they're still at least 2 different types of data in 3 states so I see it as important to differentiate them.
As discussed in the discord we can combine them, the majority of the server-related concerns were over having to query data in a way that made no sense. For pure nomeclature reasons and to help prevent confusion when I translate from server-internals to protocol I'd like to use the name UserClient if possible which I think you're okay with based on the above. |
Beta Was this translation helpful? Give feedback.
-
yep ok. so these properties would change to
Right, but in terms of the data what are we thinking? 'Cause right now the data is the same for all 3 states: export type BattleOptions = {
title: string;
engineVersion: string;
gameVersion: string;
map: string;
startPosType: StartPosType;
startBoxes: Record<number, StartBox>;
startTime: Date | null;
gameOptions: Record<string, string | number | boolean>;
mapOptions: Record<string, string | number | boolean>;
restrictions: Restriction[];
};
export type OfflineBattleOptions = BattleOptions;
export type SpadsBattleOptions = BattleOptions & {
id: number;
isHost: boolean;
passworded: boolean;
password: string | null;
scriptPassword: string | null;
founderId: number;
ip: string | null;
port: number | null;
locked: boolean;
maxPlayers: number;
preset: string;
joinQueueUserIds: number[];
autoBalance: string;
teamSize: number;
nbTeams: number;
balanceMode: string;
};A battle in the "pregame" state has all these properties and no more. A battle in the "ingame" state has all these properties and potential additional properties we may wish to add (none right now), and a battle in the "postgame" state still has all these properties and again might have some additional properties we wish to add. Semantically, these are all the same entity. If you're saying the server has some extra info about ingame battles, then I would suggest the same thing as I did for Users and Clients, and for it to be part of the battle response if a battle is ingame/postgame: {
cmd: "battleUpdated",
data: {
battleId: 123,
ingameStatus: {
usersPlaying: [12, 34, 56],
usersResigned: [78],
gameFrame: 123456
}
}
}{
cmd: "battleUpdated",
data: {
battleId: 123,
postgameStatus: {
winningTeam: 1,
statistics: [
{
userId: 12,
damageDealt: 9999
}
]
}
}
}
I'd much prefer just "User", because the concept of "Clients" to represent online user data is only relevant on the server. |
Beta Was this translation helpful? Give feedback.
-
Yes. I'll add it to the PR :)
I'd be happy to have lobbydata, ingamedata and postgamedata be split into 3 chunks if it helps. But if you query a given game at each of the 3 stages you will have quite different properties. E.g. the password is not kept post-game and statistics can only exist post game. |
Beta Was this translation helpful? Give feedback.
-
All the properties that I posted in the first snippet would be relevant in all states though no? A battle in the postgame state would still have the same password? My intention with the sub-objects (like {
cmd: "battleUpdated",
data: {
battleId: 123,
state: "pregame"
}
}{
cmd: "battleUpdated",
data: {
battleId: 123,
state: "ingame",
start_time: 1682898825
}
}{
cmd: "battleUpdated",
data: {
battleId: 123,
state: "postgame",
winning_team_id: 1
}
}If we wanted to do this, it would be easy to define these additional properties in the schema based on the literal |
Beta Was this translation helpful? Give feedback.
-
|
I've thought about it a bit more. I'd like to split Currently the server has very little info about ongoing games so this should be pretty easy to handle, the vast majority of what we'd want to handle will just sit in lobbies; even saying it's in-game/post-game would be an attribute of a lobby. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds sensible, I think. 1 lobby can have many matches (prefer I can see we're torn on I think in the current landscape, these terms and separations make sense, but I'm not sure if this is desirable or not. Because lobby data doesn't necessarily reflect a match's data, a match entity would have a lot of the same properties of lobby, but would reflect the actual ingame data rather than the lobby's. For example, if a lobby has map A, the match starts on map A, but then the host/boss/democracy changes the map to B while the match is still in progress, the lobby map won't reflect the match's map. This would be true of almost every lobby property - once a game is launched, the match's actual properties become a snapshot of what the lobby's state was at the time of launch. This is only really applicable to custom games, wouldn't apply to matchmaking. |
Beta Was this translation helpful? Give feedback.
-
|
1 I track lobbies and matches separately so keeping them separate won't be an issue from a query perspective. It's up to you if you want to nest the current match in the lobby data or have it as a separate thing. |
Beta Was this translation helpful? Give feedback.
-
|
@Jazcash am I right in thinking these are the terms and meanings we agreed upon?
|
Beta Was this translation helpful? Give feedback.
-
|
Yep I think I'm fine with those |
Beta Was this translation helpful? Give feedback.
-
|
I'll PR it into a doc soon |
Beta Was this translation helpful? Give feedback.
-
Going forward I think it'd be a good idea to standardise the terminology used in the protocol. Words like
client,lobby,hostor evengamecan be confusing depending on the context, so I'd like to clear up that ambiguity in regards to this protocol at least.My proposals:
Beyond All Reason test-22425-e6c0e37105.1.1-1544-g058c8ea BAR105Just to be clear, I don't think these terms necessarily need to be strictly adhered to in either the server or the lobby codebases. For example, in BAR Lobby the term
botactually means an instance of an AI, and I believe currently in the server battles are known aslobbies. I think that's fine. The terminology in this protocol should be distinct from that and shouldn't be concerned with terms that are irrelevant to it.Beta Was this translation helpful? Give feedback.
All reactions