@ughuuu/game_server 1.0.1034 → 1.0.1039
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +43 -11
- package/dist/ApiClient.js +2 -2
- package/dist/api/AchievementsApi.js +2 -2
- package/dist/api/AdminAchievementsApi.js +2 -2
- package/dist/api/AdminChatApi.js +2 -2
- package/dist/api/AdminGroupsApi.js +2 -2
- package/dist/api/AdminKVApi.js +2 -2
- package/dist/api/AdminLeaderboardsApi.js +2 -2
- package/dist/api/AdminLobbiesApi.js +2 -2
- package/dist/api/AdminNotificationsApi.js +2 -2
- package/dist/api/AdminSessionsApi.js +2 -2
- package/dist/api/AdminTournamentsApi.js +374 -0
- package/dist/api/AdminUsersApi.js +2 -2
- package/dist/api/AuthenticationApi.js +2 -2
- package/dist/api/ChatApi.js +2 -2
- package/dist/api/FriendsApi.js +2 -2
- package/dist/api/GroupsApi.js +2 -2
- package/dist/api/HealthApi.js +2 -2
- package/dist/api/HooksApi.js +2 -2
- package/dist/api/KVApi.js +2 -2
- package/dist/api/LeaderboardsApi.js +2 -2
- package/dist/api/LobbiesApi.js +2 -2
- package/dist/api/NotificationsApi.js +2 -2
- package/dist/api/PartiesApi.js +2 -2
- package/dist/api/PaymentsApi.js +2 -2
- package/dist/api/TournamentsApi.js +394 -0
- package/dist/api/UsersApi.js +2 -2
- package/dist/gamend_proto.js +389 -0
- package/dist/gamend_realtime.pb.js +6473 -0
- package/dist/index.js +63 -0
- package/dist/model/AcceptPartyInvite200Response.js +2 -2
- package/dist/model/AcceptPartyInvite200ResponseMembersInner.js +2 -2
- package/dist/model/AcceptPartyInviteRequest.js +2 -2
- package/dist/model/AdminCreateAchievementRequest.js +2 -2
- package/dist/model/AdminCreateLeaderboard200Response.js +2 -2
- package/dist/model/AdminCreateLeaderboard200ResponseData.js +2 -2
- package/dist/model/AdminCreateLeaderboardRequest.js +2 -2
- package/dist/model/AdminCreateNotificationRequest.js +2 -2
- package/dist/model/AdminDeleteChatConversation200Response.js +2 -2
- package/dist/model/AdminDrawTournament200Response.js +91 -0
- package/dist/model/AdminDrawTournament200ResponseData.js +297 -0
- package/dist/model/AdminGrantAchievementRequest.js +2 -2
- package/dist/model/AdminIncrementAchievementRequest.js +2 -2
- package/dist/model/AdminListAchievements200Response.js +2 -2
- package/dist/model/AdminListAchievements200ResponseDataInner.js +2 -2
- package/dist/model/AdminListChatMessages200Response.js +2 -2
- package/dist/model/AdminListChatMessages200ResponseDataInner.js +2 -2
- package/dist/model/AdminListGroups200Response.js +2 -2
- package/dist/model/AdminListKvEntries200Response.js +2 -2
- package/dist/model/AdminListLobbies200Response.js +2 -2
- package/dist/model/AdminListLobbies200ResponseDataInner.js +2 -2
- package/dist/model/AdminListNotifications200Response.js +2 -2
- package/dist/model/AdminListNotifications200ResponseDataInner.js +2 -2
- package/dist/model/AdminListSessions200Response.js +2 -2
- package/dist/model/AdminListSessions200ResponseDataInner.js +2 -2
- package/dist/model/AdminResolveTournamentMatchRequest.js +90 -0
- package/dist/model/AdminRevokeAchievementRequest.js +2 -2
- package/dist/model/AdminSubmitLeaderboardScoreRequest.js +2 -2
- package/dist/model/AdminUpdateAchievementRequest.js +2 -2
- package/dist/model/AdminUpdateGroup200Response.js +2 -2
- package/dist/model/AdminUpdateGroupRequest.js +2 -2
- package/dist/model/AdminUpdateKvEntryRequest.js +2 -2
- package/dist/model/AdminUpdateLeaderboardRecord200Response.js +2 -2
- package/dist/model/AdminUpdateLeaderboardRecord200ResponseData.js +2 -2
- package/dist/model/AdminUpdateLeaderboardRecordRequest.js +2 -2
- package/dist/model/AdminUpdateLeaderboardRequest.js +2 -2
- package/dist/model/AdminUpdateLobby200Response.js +2 -2
- package/dist/model/AdminUpdateTournamentRequest.js +253 -0
- package/dist/model/AdminUpdateUser200Response.js +2 -2
- package/dist/model/AdminUpdateUser200ResponseData.js +2 -2
- package/dist/model/AdminUpdateUserRequest.js +2 -2
- package/dist/model/AdminUpsertKv200Response.js +2 -2
- package/dist/model/AdminUpsertKv200ResponseData.js +2 -2
- package/dist/model/AdminUpsertKvRequest.js +2 -2
- package/dist/model/ApproveJoinRequest200Response.js +2 -2
- package/dist/model/CallHook200Response.js +2 -2
- package/dist/model/CallHookRequest.js +2 -2
- package/dist/model/CancelJoinRequest200Response.js +2 -2
- package/dist/model/ChatUnreadCount200Response.js +2 -2
- package/dist/model/CreateGroupRequest.js +2 -2
- package/dist/model/CreateLobbyRequest.js +2 -2
- package/dist/model/CreatePartyRequest.js +2 -2
- package/dist/model/DeclineGroupInvite200Response.js +2 -2
- package/dist/model/DeleteNotificationsRequest.js +2 -2
- package/dist/model/DeviceLoginRequest.js +2 -2
- package/dist/model/ErrorResponse.js +2 -2
- package/dist/model/GameServerWebApiV1TournamentControllerIndex200Response.js +110 -0
- package/dist/model/GameServerWebApiV1TournamentControllerIndex200ResponseDataInner.js +258 -0
- package/dist/model/GameServerWebApiV1TournamentControllerMyMatch200Response.js +173 -0
- package/dist/model/GetCurrentUser200Response.js +2 -2
- package/dist/model/GetCurrentUser200ResponseLinkedProviders.js +2 -2
- package/dist/model/GetKv200Response.js +2 -2
- package/dist/model/GetLobby200Response.js +2 -2
- package/dist/model/GetMyRecord200Response.js +2 -2
- package/dist/model/GetMyRecord200ResponseData.js +2 -2
- package/dist/model/HealthResponse.js +2 -2
- package/dist/model/InviteToPartyRequest.js +2 -2
- package/dist/model/ListBlockedFriends200Response.js +2 -2
- package/dist/model/ListBlockedFriends200ResponseDataInner.js +2 -2
- package/dist/model/ListBlockedFriends200ResponseDataInnerRequester.js +2 -2
- package/dist/model/ListChatMessages200Response.js +2 -2
- package/dist/model/ListChatMessages200ResponseDataInner.js +2 -2
- package/dist/model/ListFriendRequests200Response.js +2 -2
- package/dist/model/ListFriendRequests200ResponseIncomingInner.js +2 -2
- package/dist/model/ListFriendRequests200ResponseIncomingInnerRequester.js +2 -2
- package/dist/model/ListFriendRequests200ResponseMeta.js +2 -2
- package/dist/model/ListFriends200Response.js +2 -2
- package/dist/model/ListFriends200ResponseDataInner.js +2 -2
- package/dist/model/ListFriends200ResponseMeta.js +2 -2
- package/dist/model/ListGroupMembers200Response.js +2 -2
- package/dist/model/ListJoinRequests200Response.js +2 -2
- package/dist/model/ListLeaderboardRecords200Response.js +2 -2
- package/dist/model/ListLeaderboards200Response.js +2 -2
- package/dist/model/ListLobbies200Response.js +2 -2
- package/dist/model/ListLobbies200ResponseDataInner.js +2 -2
- package/dist/model/ListMyGroups200Response.js +2 -2
- package/dist/model/ListMyGroups200ResponseDataInner.js +2 -2
- package/dist/model/ListPartyInvitations200ResponseInner.js +2 -2
- package/dist/model/ListRecordsAroundUser200Response.js +2 -2
- package/dist/model/ListSentInvitations200Response.js +2 -2
- package/dist/model/ListSentInvitations200ResponseDataInner.js +2 -2
- package/dist/model/LoginRequest.js +2 -2
- package/dist/model/MarkChatReadRequest.js +2 -2
- package/dist/model/MyAchievements200Response.js +2 -2
- package/dist/model/MyAchievements200ResponseDataInner.js +2 -2
- package/dist/model/NotifyGroup200Response.js +2 -2
- package/dist/model/NotifyGroupRequest.js +2 -2
- package/dist/model/OAuthSessionData.js +2 -2
- package/dist/model/OAuthSessionDataDetails.js +2 -2
- package/dist/model/OAuthSessionStatus.js +2 -2
- package/dist/model/OauthApiCallback200Response.js +2 -2
- package/dist/model/OauthApiCallbackRequest.js +2 -2
- package/dist/model/OauthCallbackApiAppleIosRequest.js +2 -2
- package/dist/model/OauthGoogleIdTokenRequest.js +2 -2
- package/dist/model/OauthRequest200Response.js +2 -2
- package/dist/model/OauthSessionStatus404Response.js +2 -2
- package/dist/model/PartyCreateLobbyRequest.js +2 -2
- package/dist/model/PartyJoinLobbyRequest.js +2 -2
- package/dist/model/PaymentsEntitlements401Response.js +2 -2
- package/dist/model/PaymentsSteamCheckoutRequest.js +2 -2
- package/dist/model/PaymentsSteamFinalizeRequest.js +2 -2
- package/dist/model/PaymentsStripeCheckoutRequest.js +2 -2
- package/dist/model/QuickJoinRequest.js +2 -2
- package/dist/model/RefreshToken200Response.js +2 -2
- package/dist/model/RefreshToken200ResponseData.js +2 -2
- package/dist/model/RefreshTokenRequest.js +2 -2
- package/dist/model/ResolveLeaderboardSlugs200Response.js +2 -2
- package/dist/model/ResolveLeaderboardSlugs200ResponseDataValue.js +2 -2
- package/dist/model/ResolveLeaderboardSlugsRequest.js +2 -2
- package/dist/model/SearchUsers200Response.js +2 -2
- package/dist/model/SearchUsers200ResponseDataInner.js +2 -2
- package/dist/model/SendChatMessageRequest.js +2 -2
- package/dist/model/SendNotificationRequest.js +2 -2
- package/dist/model/UpdateChatMessageRequest.js +2 -2
- package/dist/model/UpdateCurrentUserDisplayName400Response.js +2 -2
- package/dist/model/UpdateCurrentUserDisplayNameRequest.js +2 -2
- package/dist/model/UpdateCurrentUserPasswordRequest.js +2 -2
- package/dist/model/UpdateCurrentUserUsernameRequest.js +2 -2
- package/dist/model/UpdateGroupRequest.js +2 -2
- package/dist/model/UpdateLobbyRequest.js +2 -2
- package/dist/model/UpdatePartyRequest.js +2 -2
- package/dist/realtime.js +75 -12
- package/dist/webrtc.js +187 -21
- package/package.json +2 -2
package/dist/index.js
CHANGED
|
@@ -75,6 +75,18 @@ Object.defineProperty(exports, "AdminDeleteChatConversation200Response", {
|
|
|
75
75
|
return _AdminDeleteChatConversation200Response["default"];
|
|
76
76
|
}
|
|
77
77
|
});
|
|
78
|
+
Object.defineProperty(exports, "AdminDrawTournament200Response", {
|
|
79
|
+
enumerable: true,
|
|
80
|
+
get: function get() {
|
|
81
|
+
return _AdminDrawTournament200Response["default"];
|
|
82
|
+
}
|
|
83
|
+
});
|
|
84
|
+
Object.defineProperty(exports, "AdminDrawTournament200ResponseData", {
|
|
85
|
+
enumerable: true,
|
|
86
|
+
get: function get() {
|
|
87
|
+
return _AdminDrawTournament200ResponseData["default"];
|
|
88
|
+
}
|
|
89
|
+
});
|
|
78
90
|
Object.defineProperty(exports, "AdminGrantAchievementRequest", {
|
|
79
91
|
enumerable: true,
|
|
80
92
|
get: function get() {
|
|
@@ -189,6 +201,12 @@ Object.defineProperty(exports, "AdminNotificationsApi", {
|
|
|
189
201
|
return _AdminNotificationsApi["default"];
|
|
190
202
|
}
|
|
191
203
|
});
|
|
204
|
+
Object.defineProperty(exports, "AdminResolveTournamentMatchRequest", {
|
|
205
|
+
enumerable: true,
|
|
206
|
+
get: function get() {
|
|
207
|
+
return _AdminResolveTournamentMatchRequest["default"];
|
|
208
|
+
}
|
|
209
|
+
});
|
|
192
210
|
Object.defineProperty(exports, "AdminRevokeAchievementRequest", {
|
|
193
211
|
enumerable: true,
|
|
194
212
|
get: function get() {
|
|
@@ -207,6 +225,12 @@ Object.defineProperty(exports, "AdminSubmitLeaderboardScoreRequest", {
|
|
|
207
225
|
return _AdminSubmitLeaderboardScoreRequest["default"];
|
|
208
226
|
}
|
|
209
227
|
});
|
|
228
|
+
Object.defineProperty(exports, "AdminTournamentsApi", {
|
|
229
|
+
enumerable: true,
|
|
230
|
+
get: function get() {
|
|
231
|
+
return _AdminTournamentsApi["default"];
|
|
232
|
+
}
|
|
233
|
+
});
|
|
210
234
|
Object.defineProperty(exports, "AdminUpdateAchievementRequest", {
|
|
211
235
|
enumerable: true,
|
|
212
236
|
get: function get() {
|
|
@@ -261,6 +285,12 @@ Object.defineProperty(exports, "AdminUpdateLobby200Response", {
|
|
|
261
285
|
return _AdminUpdateLobby200Response["default"];
|
|
262
286
|
}
|
|
263
287
|
});
|
|
288
|
+
Object.defineProperty(exports, "AdminUpdateTournamentRequest", {
|
|
289
|
+
enumerable: true,
|
|
290
|
+
get: function get() {
|
|
291
|
+
return _AdminUpdateTournamentRequest["default"];
|
|
292
|
+
}
|
|
293
|
+
});
|
|
264
294
|
Object.defineProperty(exports, "AdminUpdateUser200Response", {
|
|
265
295
|
enumerable: true,
|
|
266
296
|
get: function get() {
|
|
@@ -399,6 +429,24 @@ Object.defineProperty(exports, "FriendsApi", {
|
|
|
399
429
|
return _FriendsApi["default"];
|
|
400
430
|
}
|
|
401
431
|
});
|
|
432
|
+
Object.defineProperty(exports, "GameServerWebApiV1TournamentControllerIndex200Response", {
|
|
433
|
+
enumerable: true,
|
|
434
|
+
get: function get() {
|
|
435
|
+
return _GameServerWebApiV1TournamentControllerIndex200Response["default"];
|
|
436
|
+
}
|
|
437
|
+
});
|
|
438
|
+
Object.defineProperty(exports, "GameServerWebApiV1TournamentControllerIndex200ResponseDataInner", {
|
|
439
|
+
enumerable: true,
|
|
440
|
+
get: function get() {
|
|
441
|
+
return _GameServerWebApiV1TournamentControllerIndex200ResponseDataInner["default"];
|
|
442
|
+
}
|
|
443
|
+
});
|
|
444
|
+
Object.defineProperty(exports, "GameServerWebApiV1TournamentControllerMyMatch200Response", {
|
|
445
|
+
enumerable: true,
|
|
446
|
+
get: function get() {
|
|
447
|
+
return _GameServerWebApiV1TournamentControllerMyMatch200Response["default"];
|
|
448
|
+
}
|
|
449
|
+
});
|
|
402
450
|
Object.defineProperty(exports, "GetCurrentUser200Response", {
|
|
403
451
|
enumerable: true,
|
|
404
452
|
get: function get() {
|
|
@@ -837,6 +885,12 @@ Object.defineProperty(exports, "SendNotificationRequest", {
|
|
|
837
885
|
return _SendNotificationRequest["default"];
|
|
838
886
|
}
|
|
839
887
|
});
|
|
888
|
+
Object.defineProperty(exports, "TournamentsApi", {
|
|
889
|
+
enumerable: true,
|
|
890
|
+
get: function get() {
|
|
891
|
+
return _TournamentsApi["default"];
|
|
892
|
+
}
|
|
893
|
+
});
|
|
840
894
|
Object.defineProperty(exports, "UpdateChatMessageRequest", {
|
|
841
895
|
enumerable: true,
|
|
842
896
|
get: function get() {
|
|
@@ -901,6 +955,8 @@ var _AdminCreateLeaderboard200ResponseData = _interopRequireDefault(require("./m
|
|
|
901
955
|
var _AdminCreateLeaderboardRequest = _interopRequireDefault(require("./model/AdminCreateLeaderboardRequest"));
|
|
902
956
|
var _AdminCreateNotificationRequest = _interopRequireDefault(require("./model/AdminCreateNotificationRequest"));
|
|
903
957
|
var _AdminDeleteChatConversation200Response = _interopRequireDefault(require("./model/AdminDeleteChatConversation200Response"));
|
|
958
|
+
var _AdminDrawTournament200Response = _interopRequireDefault(require("./model/AdminDrawTournament200Response"));
|
|
959
|
+
var _AdminDrawTournament200ResponseData = _interopRequireDefault(require("./model/AdminDrawTournament200ResponseData"));
|
|
904
960
|
var _AdminGrantAchievementRequest = _interopRequireDefault(require("./model/AdminGrantAchievementRequest"));
|
|
905
961
|
var _AdminIncrementAchievementRequest = _interopRequireDefault(require("./model/AdminIncrementAchievementRequest"));
|
|
906
962
|
var _AdminListAchievements200Response = _interopRequireDefault(require("./model/AdminListAchievements200Response"));
|
|
@@ -915,6 +971,7 @@ var _AdminListNotifications200Response = _interopRequireDefault(require("./model
|
|
|
915
971
|
var _AdminListNotifications200ResponseDataInner = _interopRequireDefault(require("./model/AdminListNotifications200ResponseDataInner"));
|
|
916
972
|
var _AdminListSessions200Response = _interopRequireDefault(require("./model/AdminListSessions200Response"));
|
|
917
973
|
var _AdminListSessions200ResponseDataInner = _interopRequireDefault(require("./model/AdminListSessions200ResponseDataInner"));
|
|
974
|
+
var _AdminResolveTournamentMatchRequest = _interopRequireDefault(require("./model/AdminResolveTournamentMatchRequest"));
|
|
918
975
|
var _AdminRevokeAchievementRequest = _interopRequireDefault(require("./model/AdminRevokeAchievementRequest"));
|
|
919
976
|
var _AdminSubmitLeaderboardScoreRequest = _interopRequireDefault(require("./model/AdminSubmitLeaderboardScoreRequest"));
|
|
920
977
|
var _AdminUpdateAchievementRequest = _interopRequireDefault(require("./model/AdminUpdateAchievementRequest"));
|
|
@@ -926,6 +983,7 @@ var _AdminUpdateLeaderboardRecord200ResponseData = _interopRequireDefault(requir
|
|
|
926
983
|
var _AdminUpdateLeaderboardRecordRequest = _interopRequireDefault(require("./model/AdminUpdateLeaderboardRecordRequest"));
|
|
927
984
|
var _AdminUpdateLeaderboardRequest = _interopRequireDefault(require("./model/AdminUpdateLeaderboardRequest"));
|
|
928
985
|
var _AdminUpdateLobby200Response = _interopRequireDefault(require("./model/AdminUpdateLobby200Response"));
|
|
986
|
+
var _AdminUpdateTournamentRequest = _interopRequireDefault(require("./model/AdminUpdateTournamentRequest"));
|
|
929
987
|
var _AdminUpdateUser200Response = _interopRequireDefault(require("./model/AdminUpdateUser200Response"));
|
|
930
988
|
var _AdminUpdateUser200ResponseData = _interopRequireDefault(require("./model/AdminUpdateUser200ResponseData"));
|
|
931
989
|
var _AdminUpdateUserRequest = _interopRequireDefault(require("./model/AdminUpdateUserRequest"));
|
|
@@ -944,6 +1002,9 @@ var _DeclineGroupInvite200Response = _interopRequireDefault(require("./model/Dec
|
|
|
944
1002
|
var _DeleteNotificationsRequest = _interopRequireDefault(require("./model/DeleteNotificationsRequest"));
|
|
945
1003
|
var _DeviceLoginRequest = _interopRequireDefault(require("./model/DeviceLoginRequest"));
|
|
946
1004
|
var _ErrorResponse = _interopRequireDefault(require("./model/ErrorResponse"));
|
|
1005
|
+
var _GameServerWebApiV1TournamentControllerIndex200Response = _interopRequireDefault(require("./model/GameServerWebApiV1TournamentControllerIndex200Response"));
|
|
1006
|
+
var _GameServerWebApiV1TournamentControllerIndex200ResponseDataInner = _interopRequireDefault(require("./model/GameServerWebApiV1TournamentControllerIndex200ResponseDataInner"));
|
|
1007
|
+
var _GameServerWebApiV1TournamentControllerMyMatch200Response = _interopRequireDefault(require("./model/GameServerWebApiV1TournamentControllerMyMatch200Response"));
|
|
947
1008
|
var _GetCurrentUser200Response = _interopRequireDefault(require("./model/GetCurrentUser200Response"));
|
|
948
1009
|
var _GetCurrentUser200ResponseLinkedProviders = _interopRequireDefault(require("./model/GetCurrentUser200ResponseLinkedProviders"));
|
|
949
1010
|
var _GetKv200Response = _interopRequireDefault(require("./model/GetKv200Response"));
|
|
@@ -1025,6 +1086,7 @@ var _AdminLeaderboardsApi = _interopRequireDefault(require("./api/AdminLeaderboa
|
|
|
1025
1086
|
var _AdminLobbiesApi = _interopRequireDefault(require("./api/AdminLobbiesApi"));
|
|
1026
1087
|
var _AdminNotificationsApi = _interopRequireDefault(require("./api/AdminNotificationsApi"));
|
|
1027
1088
|
var _AdminSessionsApi = _interopRequireDefault(require("./api/AdminSessionsApi"));
|
|
1089
|
+
var _AdminTournamentsApi = _interopRequireDefault(require("./api/AdminTournamentsApi"));
|
|
1028
1090
|
var _AdminUsersApi = _interopRequireDefault(require("./api/AdminUsersApi"));
|
|
1029
1091
|
var _AuthenticationApi = _interopRequireDefault(require("./api/AuthenticationApi"));
|
|
1030
1092
|
var _ChatApi = _interopRequireDefault(require("./api/ChatApi"));
|
|
@@ -1038,5 +1100,6 @@ var _LobbiesApi = _interopRequireDefault(require("./api/LobbiesApi"));
|
|
|
1038
1100
|
var _NotificationsApi = _interopRequireDefault(require("./api/NotificationsApi"));
|
|
1039
1101
|
var _PartiesApi = _interopRequireDefault(require("./api/PartiesApi"));
|
|
1040
1102
|
var _PaymentsApi = _interopRequireDefault(require("./api/PaymentsApi"));
|
|
1103
|
+
var _TournamentsApi = _interopRequireDefault(require("./api/TournamentsApi"));
|
|
1041
1104
|
var _UsersApi = _interopRequireDefault(require("./api/UsersApi"));
|
|
1042
1105
|
function _interopRequireDefault(e) { return e && e.__esModule ? e : { "default": e }; }
|
|
@@ -17,9 +17,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
|
|
|
17
17
|
function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
|
|
18
18
|
function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
|
|
19
19
|
* Game Server API
|
|
20
|
-
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **12.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **12.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **12.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **13. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **13.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **13.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **13.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
20
|
+
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged: - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments` ## **13. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **13.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **13.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **13.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **14. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **14.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **14.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **14.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
21
21
|
*
|
|
22
|
-
* The version of the OpenAPI document: 1.0.
|
|
22
|
+
* The version of the OpenAPI document: 1.0.1039
|
|
23
23
|
*
|
|
24
24
|
*
|
|
25
25
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -13,9 +13,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
|
|
|
13
13
|
function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
|
|
14
14
|
function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
|
|
15
15
|
* Game Server API
|
|
16
|
-
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **12.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **12.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **12.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **13. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **13.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **13.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **13.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
16
|
+
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged: - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments` ## **13. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **13.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **13.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **13.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **14. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **14.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **14.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **14.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1039
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -16,9 +16,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
|
|
|
16
16
|
function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
|
|
17
17
|
function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
|
|
18
18
|
* Game Server API
|
|
19
|
-
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **12.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **12.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **12.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **13. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **13.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **13.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **13.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
19
|
+
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged: - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments` ## **13. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **13.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **13.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **13.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **14. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **14.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **14.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **14.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1039
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -16,9 +16,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
|
|
|
16
16
|
function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
|
|
17
17
|
function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
|
|
18
18
|
* Game Server API
|
|
19
|
-
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **12.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **12.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **12.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **13. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **13.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **13.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **13.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
19
|
+
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged: - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments` ## **13. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **13.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **13.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **13.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **14. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **14.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **14.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **14.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1039
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -14,9 +14,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
|
|
|
14
14
|
function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
|
|
15
15
|
function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
|
|
16
16
|
* Game Server API
|
|
17
|
-
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **12.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **12.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **12.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **13. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **13.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **13.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **13.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
17
|
+
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged: - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments` ## **13. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **13.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **13.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **13.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **14. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **14.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **14.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **14.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
18
18
|
*
|
|
19
|
-
* The version of the OpenAPI document: 1.0.
|
|
19
|
+
* The version of the OpenAPI document: 1.0.1039
|
|
20
20
|
*
|
|
21
21
|
*
|
|
22
22
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -13,9 +13,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
|
|
|
13
13
|
function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
|
|
14
14
|
function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
|
|
15
15
|
* Game Server API
|
|
16
|
-
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **12.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **12.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **12.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **13. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **13.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **13.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **13.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
16
|
+
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged: - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments` ## **13. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **13.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **13.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **13.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **14. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **14.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **14.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **14.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1039
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -16,9 +16,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
|
|
|
16
16
|
function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
|
|
17
17
|
function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
|
|
18
18
|
* Game Server API
|
|
19
|
-
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **12.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **12.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **12.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **13. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **13.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **13.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **13.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
19
|
+
* API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, payments, server scripting, and admin portal. ## **1. Authentication** This API uses JWT (JSON Web Tokens) with access and refresh tokens: ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ``` ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token. ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights: - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported ## **3. Friends** The Friends domain offers lightweight social features: - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights: - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated ## **5. Notifications** Persistent user-to-user notifications that survive across sessions: - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect ## **6. Groups** Groups provide persistent community management for players: - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"` ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads): - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel ## **8. Chat** Real-time messaging across multiple conversation types: - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking ## **9. Leaderboards** Server-managed ranked scoreboards: - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings: - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements: - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged: - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments` ## **13. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates. ### **13.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ``` ### **13.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat ### **13.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix` ## **14. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients). ### **14.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency ### **14.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync ### **14.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, { onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1039
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|