revival-forge/twa-revival
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
Page: EOS and clients
Pages
Contributing EOS and clients Home Hosting Operations Troubleshooting
1 EOS and clients
darask edited this page 2026-10-19 15:15:13 +00:00
Table of Contents

Epic認証・ランチャー・本体配布

自分のEpic環境を設定する

運営者のEpic Developer Portalで製品、sandbox、deployment、ゲーム用clientとpolicy、EASアプリの関連付けを準備します。一般プレイヤーはAccountPortalでログインします。Dev Auth Toolを一般参加者へ要求する構成にしません。Portalの公開範囲や外部アカウントの利用条件は、自分の製品について確認してください。Epic Connect公式資料

バックエンドが受理するのは EOS Connect ID token です。Auth tokenとは異なります。署名・issuer・product/sandbox/deployment/client・有効期限を検査し、PUIDで本人を識別します。表示名で認証しません。

Worker設定 内容
EOS_PRODUCT_ID 自分のProduct ID
EOS_SANDBOX_ID / EOS_DEPLOYMENT_ID 今回公開する環境
EOS_ALLOWED_CLIENT_IDS 今回のゲームclient
EOS_EXPECTED_ISSUER 対象Connect証明で確認した発行元。推測で埋めない
EOS_ALLOWED_EXTERNAL_TYPES Epic Games利用なら epicgames
PLAYER_REGISTRATION closed / invitation / open。省略時invitation

取得したtoken自体をWiki・Issue・ログへ貼らず、環境が一致したかだけを記録します。認証実装と設定の履歴が詳細な根拠です。

プレイヤー用の設定

ランチャー直下の player-release.json は次の構造です。値はすべて自分の製品から設定します。この例の置換前の値は使用できません。

{
  "schemaVersion": 1,
  "apiBaseUrl": "https://control.example.com",
  "eos": {
    "productId": "REPLACE_ME",
    "sandboxId": "REPLACE_ME",
    "deploymentId": "REPLACE_ME",
    "clientId": "REPLACE_ME",
    "clientSecret": "REPLACE_ME"
  }
}

この実装のEOS SDK用clientSecretはプレイヤー用設定が要求する値です。Epicのゲーム用client policyに限定したものを使います。CloudflareのAPI token、WorkerのADMIN_TOKEN・RELAY_TICKET_SECRET、更新署名の秘密鍵とは役割が異なり、それらを代入してはいけません。独立運営者が受け取った既存の秘密値を再配布する手順でもありません。設定の実際の検査

公開コピーから配布物にする時の不足箇所

現在は次の準備が必要です。ゲーム本体をGit LFSで取得しただけでは、これらは自動生成されません。

必要なもの 現在の公開コピーでの扱い
Windows用Python 3.11、Tk、Frida、EOSSDK-Win64-Shipping.dll runtime/ は別途準備。必要ファイルはpackagerが検査する
companion/VERSION 候補の収録一覧152項目中、このファイルが欠落。運営する候補のsemverを明示して追加する。ゲーム版とランチャー版を混同しない
Launch TWA.cmd source/ にある起動入口を配布ルートへ配置。runtimeのpythonで tools/player_bootstrap.py を起動する
native配布セットとreceipt tools/player_native_payload.py が固定するmanifest・DLL・WAD・言語/UIパッチなどを揃える。公開 game/revival-client/ と同一とは限らない
公開CDNと署名鍵 companion/trusted_keys.py の旧QA originとRELEASE_TRUSTED_KEYSを、自分の配布先・公開鍵へ更新する
完成物の動作確認 新規PCでログイン→更新→起動→対戦→結果保存を確認する

候補のnativeツールには work/private-modes-20261010/game.dll などを固定ハッシュで要求する箇所があります。このスナップショットにないreceipt・生成物を、近い名前のDLLで代用しないでください。自分の配布版を作る際は、パッチ生成・ハッシュ・catalog・manifest・receiptを一つの版として揃える必要があります。要求されるファイルとハッシュ

更新配信を準備する

配信は、本体導入・ゲーム差分・ランチャー更新の3系統です。

R2上のmanifest 用途
base-game-manifests/stable.json 本体の初回導入
manifests/stable.json Arena.exe / game.dll / data/wad.pack / npl-base.dll / npl-sdk.dll等のゲーム更新
launcher-manifests/stable.json ランチャー・互換サービス・カタログ更新
objects/... manifestが指す実ファイル

beta も別チャンネルとして扱えます。Workerは /v1/update/manifest、/v1/update/base-game-manifest、/v1/update/launcher-manifest と /v1/update/object/... を提供します。一方、公開ランチャーにはCDN上の静的manifestを読む経路があるため、API URLの変更だけでは配布先変更は完了しません。PUBLIC_DOWNLOAD_ORIGIN、静的manifestの公開パス、各object URL、公開鍵の一致まで確認します。Workerの配信実装、本体取得、固定公開鍵

scripts/gen-manifest-key.mjs はEd25519鍵をリポジトリ外の絶対パスへ作成します。秘密鍵は運営者の署名環境に保存し、クライアント・R2・Workerへ置きません。公開鍵はクライアントのRELEASE_TRUSTED_KEYSへ入れます。開発用 dev-2026-09 は誰でも生成できる試験鍵なので公開配布の信頼元に使いません。

ゲーム更新用の build-manifest.mjs / sign-manifest.mjs / verify-manifest.mjs と、ランチャー用の sign-launcher-manifest.mjs は用途が異なります。スクリプトのusageに沿って生成→署名→検証し、署名済みmanifestと対応objectだけを公開します。本体用manifestにゲーム差分用の形式を流用しないでください。

パッケージ作成と受入

配布用コピーの candidate/launcher/ 相当を作業ディレクトリにし、上記の版・設定・runtime・native-rootを準備した後に実行します。

python tools/player_package.py inventory --runtime-root C:\TWA-Runtime --plan core-lock.json
python tools/player_package.py build --runtime-root C:\TWA-Runtime --plan core-lock.json --output player-core.zip
# 固定nativeセットとreceiptまで用意できた場合
python tools/player_package.py installer --runtime-root C:\TWA-Runtime --plan core-lock.json --native-root C:\TWA-Native-Release --output player-installer.zip

出力先は新しいファイルを指定します。inventory後に入力が変わると拒否されます。packagerの publicReady: false を配布の合格表示へ読み替えません。完成物では Launch TWA.cmd から起動し、署名検査を通した更新、Epicログイン、メニュー、2台の参加、開始、終了、結果の重複なし保存を順に確認します。パッケージの仕様

Wiki