接入总览

本指南面向游戏开发商,说明如何将一款游戏接入本平台,并获得分发、联机、匹配、结算与运营数据能力。接入完成后,玩家在大厅内即可发现、进入并游玩你的游戏。

建议阅读顺序:先读本章建立整体认知,再按快速开始跑通第一个版本,其余章节按需查阅。接口细节见开放 API 参考。

文档约定

• 必须:强制要求,不满足将无法通过审核或无法正常运行。
• 禁止:强制禁止,违反将导致提审被拒或运行被终止。
• 建议:推荐做法,平台以此为准设计,偏离需自行承担兼容风险。

平台能力

你要开发什么

接入本平台不需要自建服务器、域名与运维。一款游戏由两部分产物组成,均由你开发、平台托管运行:

职责划分:

游戏逻辑运行在平台的隔离运行时中,不暴露任何网络接口,玩家无法绕过前端直接访问;游戏前端永远不持有玩家长期凭证,只通过一次性票据连接。

适合什么游戏

接入架构

flowchart LR
    subgraph BROWSER["玩家浏览器"]
        L["平台大厅"] -- "iframe 嵌入" --> GF["游戏前端<br/>开发商静态页面"]
    end
    subgraph PLATFORM["平台"]
        H["大厅宿主"] -- "postMessage<br/>连接配置与票据" --> GF
        G["WebSocket 网关"] --> R["游戏逻辑运行时<br/>托管开发商代码"]
        R -- "回合结算" --> W["钱包服务"]
        S["静态资源托管<br/>存放游戏前端包"]
        P["开放 API"]
    end
    GF -- "WebSocket 游戏事件" --> G
    L -- "REST" --> P
    DEV["开发商后台与 CI"] -- "提包、提审、查询" --> P
    P -- "审核通过发布" --> S
    P -- "审核通过发布" --> R

设计原则:

1. 凭证不进游戏前端:游戏前端通过宿主协议向大厅索取一次性 WebSocket 票据,票据单次有效、30 秒过期。
2. 权威在服务端:影响玩法与资金的操作均由游戏逻辑裁决,前端只负责表现。
3. 资金平台托管:游戏逻辑只能通过平台回合接口发起扣款与奖励,结算原子完成并全程留痕。

接入流程

注册开发商账号 → 平台资质审核 → 登录开发商后台
  → 创建游戏,录入基础信息与联机参数
  → 开发游戏前端与游戏逻辑 → 本地自检自测
  → 提审,上传前端包并提交游戏逻辑包
  → 平台审核 ──驳回──▶ 按意见修改后重新提审
       └──通过──▶ 自动发布上架 → 运营数据跟踪 → 版本迭代

接入复杂度评估

以上估算以熟悉 TypeScript 与 WebSocket 的开发者为前提,不含玩法设计与美术资源工作量。