@ughuuu/game_server 1.0.1001 → 1.0.1004
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 +24 -24
- package/dist/ApiClient.js +1 -1
- package/dist/api/AchievementsApi.js +15 -15
- package/dist/api/AdminAchievementsApi.js +16 -16
- package/dist/api/AdminChatApi.js +6 -6
- package/dist/api/AdminGroupsApi.js +2 -2
- package/dist/api/AdminKVApi.js +19 -19
- package/dist/api/AdminLeaderboardsApi.js +19 -19
- package/dist/api/AdminLobbiesApi.js +2 -2
- package/dist/api/AdminNotificationsApi.js +2 -2
- package/dist/api/AdminSessionsApi.js +2 -2
- package/dist/api/AdminUsersApi.js +2 -2
- package/dist/api/AuthenticationApi.js +2 -2
- package/dist/api/ChatApi.js +11 -11
- package/dist/api/FriendsApi.js +7 -7
- package/dist/api/GroupsApi.js +41 -41
- package/dist/api/HealthApi.js +1 -1
- package/dist/api/HooksApi.js +2 -2
- package/dist/api/KVApi.js +2 -2
- package/dist/api/LeaderboardsApi.js +6 -6
- package/dist/api/LobbiesApi.js +6 -6
- package/dist/api/NotificationsApi.js +6 -6
- package/dist/api/PartiesApi.js +25 -25
- package/dist/api/PaymentsApi.js +2 -2
- package/dist/api/UsersApi.js +3 -3
- package/dist/index.js +133 -133
- package/dist/model/{ShowParty200Response.js → AcceptPartyInvite200Response.js} +27 -27
- package/dist/model/{ShowParty200ResponseMembersInner.js → AcceptPartyInvite200ResponseMembersInner.js} +23 -23
- package/dist/model/AcceptPartyInviteRequest.js +1 -1
- package/dist/model/AdminCreateAchievementRequest.js +1 -1
- package/dist/model/{AdminCreateKvEntry200Response.js → AdminCreateLeaderboard200Response.js} +22 -22
- package/dist/model/{AdminEndLeaderboard200ResponseData.js → AdminCreateLeaderboard200ResponseData.js} +32 -32
- package/dist/model/AdminCreateLeaderboardRequest.js +1 -1
- package/dist/model/AdminCreateNotificationRequest.js +1 -1
- package/dist/model/{DeleteNotifications200Response.js → AdminDeleteChatConversation200Response.js} +18 -19
- package/dist/model/{AdminUnlockAchievementRequest.js → AdminGrantAchievementRequest.js} +21 -21
- package/dist/model/AdminIncrementAchievementRequest.js +1 -1
- package/dist/model/AdminListAchievements200Response.js +5 -5
- package/dist/model/{AdminUpdateAchievement200Response.js → AdminListAchievements200ResponseDataInner.js} +28 -28
- package/dist/model/AdminListChatMessages200Response.js +5 -5
- package/dist/model/AdminListChatMessages200ResponseDataInner.js +1 -1
- package/dist/model/AdminListGroups200Response.js +5 -5
- package/dist/model/AdminListKvEntries200Response.js +9 -9
- package/dist/model/AdminListLobbies200Response.js +5 -5
- package/dist/model/AdminListLobbies200ResponseDataInner.js +1 -1
- package/dist/model/AdminListNotifications200Response.js +5 -5
- package/dist/model/AdminListNotifications200ResponseDataInner.js +1 -1
- package/dist/model/AdminListSessions200Response.js +5 -5
- package/dist/model/AdminListSessions200ResponseDataInner.js +1 -1
- package/dist/model/AdminRevokeAchievementRequest.js +1 -1
- package/dist/model/AdminSubmitLeaderboardScoreRequest.js +1 -1
- package/dist/model/AdminUpdateAchievementRequest.js +1 -1
- package/dist/model/AdminUpdateGroup200Response.js +1 -1
- package/dist/model/AdminUpdateGroupRequest.js +1 -1
- package/dist/model/AdminUpdateKvEntryRequest.js +1 -1
- package/dist/model/{AdminSubmitLeaderboardScore200Response.js → AdminUpdateLeaderboardRecord200Response.js} +22 -22
- package/dist/model/{AdminSubmitLeaderboardScore200ResponseData.js → AdminUpdateLeaderboardRecord200ResponseData.js} +26 -26
- package/dist/model/AdminUpdateLeaderboardRecordRequest.js +1 -1
- package/dist/model/AdminUpdateLeaderboardRequest.js +1 -1
- package/dist/model/AdminUpdateLobby200Response.js +1 -1
- package/dist/model/AdminUpdateUser200Response.js +1 -1
- package/dist/model/AdminUpdateUser200ResponseData.js +1 -1
- package/dist/model/AdminUpdateUserRequest.js +1 -1
- package/dist/model/{AdminEndLeaderboard200Response.js → AdminUpsertKv200Response.js} +22 -22
- package/dist/model/{AdminListKvEntries200ResponseDataInner.js → AdminUpsertKv200ResponseData.js} +25 -25
- package/dist/model/{AdminCreateKvEntryRequest.js → AdminUpsertKvRequest.js} +24 -24
- package/dist/model/{ListGroupMembers200ResponseDataInner.js → ApproveJoinRequest200Response.js} +28 -28
- package/dist/model/CallHook200Response.js +1 -1
- package/dist/model/CallHookRequest.js +1 -1
- package/dist/model/CancelJoinRequest200Response.js +1 -1
- package/dist/model/ChatUnreadCount200Response.js +1 -1
- package/dist/model/CreateGroupRequest.js +1 -1
- package/dist/model/CreateLobbyRequest.js +1 -1
- package/dist/model/CreatePartyRequest.js +1 -1
- package/dist/model/{InviteToGroup200Response.js → DeclineGroupInvite200Response.js} +18 -19
- package/dist/model/DeleteNotificationsRequest.js +1 -1
- package/dist/model/DeviceLoginRequest.js +1 -1
- package/dist/model/ErrorResponse.js +1 -1
- package/dist/model/GetCurrentUser200Response.js +1 -1
- package/dist/model/GetCurrentUser200ResponseLinkedProviders.js +1 -1
- package/dist/model/GetKv200Response.js +1 -1
- package/dist/model/GetLobby200Response.js +5 -5
- package/dist/model/GetMyRecord200Response.js +5 -5
- package/dist/model/{ListLeaderboardRecords200ResponseDataInner.js → GetMyRecord200ResponseData.js} +23 -23
- package/dist/model/HealthResponse.js +1 -1
- package/dist/model/{InviteToGroupRequest.js → InviteToPartyRequest.js} +22 -22
- package/dist/model/ListBlockedFriends200Response.js +5 -5
- package/dist/model/ListBlockedFriends200ResponseDataInner.js +1 -1
- package/dist/model/ListBlockedFriends200ResponseDataInnerRequester.js +1 -1
- package/dist/model/ListChatMessages200Response.js +5 -5
- package/dist/model/{GetChatMessage200Response.js → ListChatMessages200ResponseDataInner.js} +28 -28
- package/dist/model/ListFriendRequests200Response.js +1 -1
- package/dist/model/ListFriendRequests200ResponseIncomingInner.js +1 -1
- package/dist/model/ListFriendRequests200ResponseIncomingInnerRequester.js +1 -1
- package/dist/model/ListFriendRequests200ResponseMeta.js +1 -1
- package/dist/model/ListFriends200Response.js +5 -5
- package/dist/model/ListFriends200ResponseDataInner.js +1 -1
- package/dist/model/{AdminListNotifications200ResponseMeta.js → ListFriends200ResponseMeta.js} +23 -23
- package/dist/model/ListGroupMembers200Response.js +9 -9
- package/dist/model/ListJoinRequests200Response.js +5 -5
- package/dist/model/ListLeaderboardRecords200Response.js +9 -9
- package/dist/model/ListLeaderboards200Response.js +9 -9
- package/dist/model/ListLobbies200Response.js +5 -5
- package/dist/model/ListLobbies200ResponseDataInner.js +1 -1
- package/dist/model/ListMyGroups200Response.js +5 -5
- package/dist/model/ListMyGroups200ResponseDataInner.js +1 -1
- package/dist/model/ListPartyInvitations200ResponseInner.js +1 -1
- package/dist/model/ListRecordsAroundUser200Response.js +5 -5
- package/dist/model/ListSentInvitations200Response.js +5 -5
- package/dist/model/ListSentInvitations200ResponseDataInner.js +1 -1
- package/dist/model/LoginRequest.js +1 -1
- package/dist/model/MarkChatReadRequest.js +1 -1
- package/dist/model/{UserAchievements200Response.js → MyAchievements200Response.js} +27 -27
- package/dist/model/{UserAchievements200ResponseDataInner.js → MyAchievements200ResponseDataInner.js} +28 -28
- package/dist/model/NotifyGroup200Response.js +1 -1
- package/dist/model/NotifyGroupRequest.js +1 -1
- package/dist/model/OAuthSessionData.js +1 -1
- package/dist/model/OAuthSessionDataDetails.js +1 -1
- package/dist/model/OAuthSessionStatus.js +1 -1
- package/dist/model/OauthApiCallback200Response.js +1 -1
- package/dist/model/OauthApiCallbackRequest.js +1 -1
- package/dist/model/OauthCallbackApiAppleIosRequest.js +1 -1
- package/dist/model/OauthGoogleIdTokenRequest.js +1 -1
- package/dist/model/OauthRequest200Response.js +1 -1
- package/dist/model/OauthSessionStatus404Response.js +1 -1
- package/dist/model/PartyCreateLobbyRequest.js +1 -1
- package/dist/model/PartyJoinLobbyRequest.js +1 -1
- package/dist/model/{AdminCreateNotification400Response.js → PaymentsEntitlements401Response.js} +18 -18
- package/dist/model/PaymentsSteamCheckoutRequest.js +1 -1
- package/dist/model/PaymentsSteamFinalizeRequest.js +1 -1
- package/dist/model/PaymentsStripeCheckoutRequest.js +1 -1
- package/dist/model/QuickJoinRequest.js +1 -1
- package/dist/model/RefreshToken200Response.js +1 -1
- package/dist/model/RefreshToken200ResponseData.js +1 -1
- package/dist/model/RefreshTokenRequest.js +1 -1
- package/dist/model/ResolveLeaderboardSlugs200Response.js +4 -4
- package/dist/model/{ListLeaderboards200ResponseDataInner.js → ResolveLeaderboardSlugs200ResponseDataValue.js} +33 -33
- package/dist/model/ResolveLeaderboardSlugsRequest.js +1 -1
- package/dist/model/SearchUsers200Response.js +5 -5
- package/dist/model/SearchUsers200ResponseDataInner.js +1 -1
- package/dist/model/SendChatMessageRequest.js +1 -1
- package/dist/model/SendNotificationRequest.js +1 -1
- package/dist/model/UpdateChatMessageRequest.js +1 -1
- package/dist/model/{UpdateCurrentUserPassword400Response.js → UpdateCurrentUserDisplayName400Response.js} +19 -19
- package/dist/model/UpdateCurrentUserDisplayNameRequest.js +1 -1
- package/dist/model/UpdateCurrentUserPasswordRequest.js +1 -1
- package/dist/model/UpdateGroupRequest.js +1 -1
- package/dist/model/UpdateLobbyRequest.js +1 -1
- package/dist/model/UpdatePartyRequest.js +1 -1
- package/package.json +1 -1
package/dist/model/{ListGroupMembers200ResponseDataInner.js → ApproveJoinRequest200Response.js}
RENAMED
|
@@ -15,7 +15,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
15
15
|
* Game Server API
|
|
16
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 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -24,18 +24,18 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
24
24
|
*
|
|
25
25
|
*/
|
|
26
26
|
/**
|
|
27
|
-
* The
|
|
28
|
-
* @module model/
|
|
27
|
+
* The ApproveJoinRequest200Response model module.
|
|
28
|
+
* @module model/ApproveJoinRequest200Response
|
|
29
29
|
* @version 1.0.0
|
|
30
30
|
*/
|
|
31
|
-
var
|
|
31
|
+
var ApproveJoinRequest200Response = /*#__PURE__*/function () {
|
|
32
32
|
/**
|
|
33
|
-
* Constructs a new <code>
|
|
34
|
-
* @alias module:model/
|
|
33
|
+
* Constructs a new <code>ApproveJoinRequest200Response</code>.
|
|
34
|
+
* @alias module:model/ApproveJoinRequest200Response
|
|
35
35
|
*/
|
|
36
|
-
function
|
|
37
|
-
_classCallCheck(this,
|
|
38
|
-
|
|
36
|
+
function ApproveJoinRequest200Response() {
|
|
37
|
+
_classCallCheck(this, ApproveJoinRequest200Response);
|
|
38
|
+
ApproveJoinRequest200Response.initialize(this);
|
|
39
39
|
}
|
|
40
40
|
|
|
41
41
|
/**
|
|
@@ -43,22 +43,22 @@ var ListGroupMembers200ResponseDataInner = /*#__PURE__*/function () {
|
|
|
43
43
|
* This method is used by the constructors of any subclasses, in order to implement multiple inheritance (mix-ins).
|
|
44
44
|
* Only for internal use.
|
|
45
45
|
*/
|
|
46
|
-
return _createClass(
|
|
46
|
+
return _createClass(ApproveJoinRequest200Response, null, [{
|
|
47
47
|
key: "initialize",
|
|
48
48
|
value: function initialize(obj) {}
|
|
49
49
|
|
|
50
50
|
/**
|
|
51
|
-
* Constructs a <code>
|
|
51
|
+
* Constructs a <code>ApproveJoinRequest200Response</code> from a plain JavaScript object, optionally creating a new instance.
|
|
52
52
|
* Copies all relevant properties from <code>data</code> to <code>obj</code> if supplied or a new instance if not.
|
|
53
53
|
* @param {Object} data The plain JavaScript object bearing properties of interest.
|
|
54
|
-
* @param {module:model/
|
|
55
|
-
* @return {module:model/
|
|
54
|
+
* @param {module:model/ApproveJoinRequest200Response} obj Optional instance to populate.
|
|
55
|
+
* @return {module:model/ApproveJoinRequest200Response} The populated <code>ApproveJoinRequest200Response</code> instance.
|
|
56
56
|
*/
|
|
57
57
|
}, {
|
|
58
58
|
key: "constructFromObject",
|
|
59
59
|
value: function constructFromObject(data, obj) {
|
|
60
60
|
if (data) {
|
|
61
|
-
obj = obj || new
|
|
61
|
+
obj = obj || new ApproveJoinRequest200Response();
|
|
62
62
|
if (data.hasOwnProperty('display_name')) {
|
|
63
63
|
obj['display_name'] = _ApiClient["default"].convertToType(data['display_name'], 'String');
|
|
64
64
|
}
|
|
@@ -91,9 +91,9 @@ var ListGroupMembers200ResponseDataInner = /*#__PURE__*/function () {
|
|
|
91
91
|
}
|
|
92
92
|
|
|
93
93
|
/**
|
|
94
|
-
* Validates the JSON data with respect to <code>
|
|
94
|
+
* Validates the JSON data with respect to <code>ApproveJoinRequest200Response</code>.
|
|
95
95
|
* @param {Object} data The plain JavaScript object bearing properties of interest.
|
|
96
|
-
* @return {boolean} to indicate whether the JSON data is valid with respect to <code>
|
|
96
|
+
* @return {boolean} to indicate whether the JSON data is valid with respect to <code>ApproveJoinRequest200Response</code>.
|
|
97
97
|
*/
|
|
98
98
|
}, {
|
|
99
99
|
key: "validateJSON",
|
|
@@ -117,55 +117,55 @@ var ListGroupMembers200ResponseDataInner = /*#__PURE__*/function () {
|
|
|
117
117
|
/**
|
|
118
118
|
* @member {String} display_name
|
|
119
119
|
*/
|
|
120
|
-
|
|
120
|
+
ApproveJoinRequest200Response.prototype['display_name'] = undefined;
|
|
121
121
|
|
|
122
122
|
/**
|
|
123
123
|
* @member {Number} group_id
|
|
124
124
|
*/
|
|
125
|
-
|
|
125
|
+
ApproveJoinRequest200Response.prototype['group_id'] = undefined;
|
|
126
126
|
|
|
127
127
|
/**
|
|
128
128
|
* Membership ID
|
|
129
129
|
* @member {Number} id
|
|
130
130
|
*/
|
|
131
|
-
|
|
131
|
+
ApproveJoinRequest200Response.prototype['id'] = undefined;
|
|
132
132
|
|
|
133
133
|
/**
|
|
134
134
|
* @member {Date} inserted_at
|
|
135
135
|
*/
|
|
136
|
-
|
|
136
|
+
ApproveJoinRequest200Response.prototype['inserted_at'] = undefined;
|
|
137
137
|
|
|
138
138
|
/**
|
|
139
139
|
* @member {Boolean} is_online
|
|
140
140
|
*/
|
|
141
|
-
|
|
141
|
+
ApproveJoinRequest200Response.prototype['is_online'] = undefined;
|
|
142
142
|
|
|
143
143
|
/**
|
|
144
144
|
* @member {Date} last_seen_at
|
|
145
145
|
*/
|
|
146
|
-
|
|
146
|
+
ApproveJoinRequest200Response.prototype['last_seen_at'] = undefined;
|
|
147
147
|
|
|
148
148
|
/**
|
|
149
149
|
* @member {String} profile_url
|
|
150
150
|
*/
|
|
151
|
-
|
|
151
|
+
ApproveJoinRequest200Response.prototype['profile_url'] = undefined;
|
|
152
152
|
|
|
153
153
|
/**
|
|
154
|
-
* @member {module:model/
|
|
154
|
+
* @member {module:model/ApproveJoinRequest200Response.RoleEnum} role
|
|
155
155
|
*/
|
|
156
|
-
|
|
156
|
+
ApproveJoinRequest200Response.prototype['role'] = undefined;
|
|
157
157
|
|
|
158
158
|
/**
|
|
159
159
|
* @member {Number} user_id
|
|
160
160
|
*/
|
|
161
|
-
|
|
161
|
+
ApproveJoinRequest200Response.prototype['user_id'] = undefined;
|
|
162
162
|
|
|
163
163
|
/**
|
|
164
164
|
* Allowed values for the <code>role</code> property.
|
|
165
165
|
* @enum {String}
|
|
166
166
|
* @readonly
|
|
167
167
|
*/
|
|
168
|
-
|
|
168
|
+
ApproveJoinRequest200Response['RoleEnum'] = {
|
|
169
169
|
/**
|
|
170
170
|
* value: "admin"
|
|
171
171
|
* @const
|
|
@@ -177,4 +177,4 @@ ListGroupMembers200ResponseDataInner['RoleEnum'] = {
|
|
|
177
177
|
*/
|
|
178
178
|
"member": "member"
|
|
179
179
|
};
|
|
180
|
-
var _default = exports["default"] =
|
|
180
|
+
var _default = exports["default"] = ApproveJoinRequest200Response;
|
|
@@ -15,7 +15,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
15
15
|
* Game Server API
|
|
16
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 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -18,7 +18,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
18
18
|
* Game Server API
|
|
19
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 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -15,7 +15,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
15
15
|
* Game Server API
|
|
16
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 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -15,7 +15,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
15
15
|
* Game Server API
|
|
16
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 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -18,7 +18,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
18
18
|
* Game Server API
|
|
19
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 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -15,7 +15,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
15
15
|
* Game Server API
|
|
16
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 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -15,7 +15,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
15
15
|
* Game Server API
|
|
16
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 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -15,7 +15,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
15
15
|
* Game Server API
|
|
16
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 })) ```
|
|
17
17
|
*
|
|
18
|
-
* The version of the OpenAPI document: 1.0.
|
|
18
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
19
19
|
*
|
|
20
20
|
*
|
|
21
21
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -24,18 +24,18 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
24
24
|
*
|
|
25
25
|
*/
|
|
26
26
|
/**
|
|
27
|
-
* The
|
|
28
|
-
* @module model/
|
|
27
|
+
* The DeclineGroupInvite200Response model module.
|
|
28
|
+
* @module model/DeclineGroupInvite200Response
|
|
29
29
|
* @version 1.0.0
|
|
30
30
|
*/
|
|
31
|
-
var
|
|
31
|
+
var DeclineGroupInvite200Response = /*#__PURE__*/function () {
|
|
32
32
|
/**
|
|
33
|
-
* Constructs a new <code>
|
|
34
|
-
* @alias module:model/
|
|
33
|
+
* Constructs a new <code>DeclineGroupInvite200Response</code>.
|
|
34
|
+
* @alias module:model/DeclineGroupInvite200Response
|
|
35
35
|
*/
|
|
36
|
-
function
|
|
37
|
-
_classCallCheck(this,
|
|
38
|
-
|
|
36
|
+
function DeclineGroupInvite200Response() {
|
|
37
|
+
_classCallCheck(this, DeclineGroupInvite200Response);
|
|
38
|
+
DeclineGroupInvite200Response.initialize(this);
|
|
39
39
|
}
|
|
40
40
|
|
|
41
41
|
/**
|
|
@@ -43,22 +43,22 @@ var InviteToGroup200Response = /*#__PURE__*/function () {
|
|
|
43
43
|
* This method is used by the constructors of any subclasses, in order to implement multiple inheritance (mix-ins).
|
|
44
44
|
* Only for internal use.
|
|
45
45
|
*/
|
|
46
|
-
return _createClass(
|
|
46
|
+
return _createClass(DeclineGroupInvite200Response, null, [{
|
|
47
47
|
key: "initialize",
|
|
48
48
|
value: function initialize(obj) {}
|
|
49
49
|
|
|
50
50
|
/**
|
|
51
|
-
* Constructs a <code>
|
|
51
|
+
* Constructs a <code>DeclineGroupInvite200Response</code> from a plain JavaScript object, optionally creating a new instance.
|
|
52
52
|
* Copies all relevant properties from <code>data</code> to <code>obj</code> if supplied or a new instance if not.
|
|
53
53
|
* @param {Object} data The plain JavaScript object bearing properties of interest.
|
|
54
|
-
* @param {module:model/
|
|
55
|
-
* @return {module:model/
|
|
54
|
+
* @param {module:model/DeclineGroupInvite200Response} obj Optional instance to populate.
|
|
55
|
+
* @return {module:model/DeclineGroupInvite200Response} The populated <code>DeclineGroupInvite200Response</code> instance.
|
|
56
56
|
*/
|
|
57
57
|
}, {
|
|
58
58
|
key: "constructFromObject",
|
|
59
59
|
value: function constructFromObject(data, obj) {
|
|
60
60
|
if (data) {
|
|
61
|
-
obj = obj || new
|
|
61
|
+
obj = obj || new DeclineGroupInvite200Response();
|
|
62
62
|
if (data.hasOwnProperty('status')) {
|
|
63
63
|
obj['status'] = _ApiClient["default"].convertToType(data['status'], 'String');
|
|
64
64
|
}
|
|
@@ -67,9 +67,9 @@ var InviteToGroup200Response = /*#__PURE__*/function () {
|
|
|
67
67
|
}
|
|
68
68
|
|
|
69
69
|
/**
|
|
70
|
-
* Validates the JSON data with respect to <code>
|
|
70
|
+
* Validates the JSON data with respect to <code>DeclineGroupInvite200Response</code>.
|
|
71
71
|
* @param {Object} data The plain JavaScript object bearing properties of interest.
|
|
72
|
-
* @return {boolean} to indicate whether the JSON data is valid with respect to <code>
|
|
72
|
+
* @return {boolean} to indicate whether the JSON data is valid with respect to <code>DeclineGroupInvite200Response</code>.
|
|
73
73
|
*/
|
|
74
74
|
}, {
|
|
75
75
|
key: "validateJSON",
|
|
@@ -83,8 +83,7 @@ var InviteToGroup200Response = /*#__PURE__*/function () {
|
|
|
83
83
|
}]);
|
|
84
84
|
}();
|
|
85
85
|
/**
|
|
86
|
-
* \"invited\" if a new invite was created, \"request_approved\" if a pending join request was auto-approved
|
|
87
86
|
* @member {String} status
|
|
88
87
|
*/
|
|
89
|
-
|
|
90
|
-
var _default = exports["default"] =
|
|
88
|
+
DeclineGroupInvite200Response.prototype['status'] = undefined;
|
|
89
|
+
var _default = exports["default"] = DeclineGroupInvite200Response;
|
|
@@ -18,7 +18,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
18
18
|
* Game Server API
|
|
19
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 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -18,7 +18,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
18
18
|
* Game Server API
|
|
19
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 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -18,7 +18,7 @@ function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e
|
|
|
18
18
|
* Game Server API
|
|
19
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 })) ```
|
|
20
20
|
*
|
|
21
|
-
* The version of the OpenAPI document: 1.0.
|
|
21
|
+
* The version of the OpenAPI document: 1.0.1004
|
|
22
22
|
*
|
|
23
23
|
*
|
|
24
24
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|