Battlezone Online: ブラウザで遊ぶBZFlag
Battlezone Online: BZFlag in the Browser (github.com)
要約
Battlezone Online (BZO) は、ブラウザ上で動作する無料の3Dマルチプレイヤー戦車ゲームです。インストール不要で、デスクトップ、スマートフォン、VRヘッドセットからアクセスできます。BZFlagクライアントおよびサーバーと互換性があり、Node.jsサーバーとThree.jsクライアントを使用しています。WebXRをサポートしており、VRモードでのプレイも可能です。
全文翻訳
Battlezone Online
ブラウザで遊べる無料の3Dマルチプレイヤー戦車ゲームです。デスクトップ、スマートフォン、VRヘッドセットでプレイでき、BZFlagクライアントおよびサーバーと連携します。インストールは不要です。
今すぐプレイ: https://bz.rikers.org · サーバー · ヘルプ: 操作方法とフラグ · BZFlag Discord
[画像: hixでの試合、北側基地から見た様子:レーダー、ターゲットボックス、赤い戦車の残骸]
試してみる
https://bz.rikers.org/list には、公開されているbzoサーバーと、それらがプロキシするBZFlagサーバーのリストが表示されます。行をクリックすると、そのゲームに入ることができます。
サーバーはNode.jsで、クライアントはThree.jsで、WebSockets、WebTransport、WebRTC経由で通信します。
リリース内容
各タグ付きリリースは以下を公開します:
- リリースノートがCHANGELOG.mdから生成されたGitHubリリース
- ソースtarball
ghcr.io/timriker/bzo:<version>-ubuntu26.04のバージョン付きUbuntu 26.04イメージ- 移動する
ubuntu26.04タグ ghcr.io/timriker/bzo:<version>およびghcr.io/timriker/bzo:latest(どちらもUbuntu 26.04を使用)
公開されるすべてのイメージには、linux/amd64とlinux/arm64のバリアントが含まれています。リリースタグは安定版のvX.Y.Z SemVerのみを使用します。プレリリースおよびビルドメタデータタグは公開されません。
DockerイメージはUbuntu 26.04上でUbuntu独自のnodejsパッケージ(Node.js 22)を使用してビルドされ、CIはUbuntu 26.04コンテナ内の同じNodeで実行されます。
サーバーのインストールと実行
GitHub Container RegistryからのDockerイメージ、またはソースtarballやgitチェックアウトを使用します。ほとんどの人にとって、Dockerがより良いインストールおよびアップデートパスです。
docs/installation.mdには、両方の方法、設定、リバースプロキシの後ろでの実行、サーバーのリスト表示、BZFlagサーバーのプロキシ、アップデートが含まれています。
サーバーをポーリングするサイト(統計情報、サーバーブラウザ)は、docs/api.mdで問い合わせ可能なものを検索します。
/listのLaunchリンクは、インストール済みのBZFlagクライアントでBZFlagサーバーを開きます。docs/bzflag-links.mdは、Linux、Windows、macOSでbzflag://を設定します。
フラグ
bzoはBZFlagが持つすべてのフラグを搭載しています。WA(Wide Angle)はスポーンし、スティックし、悪いフラグのように振り払いますが、何も行いません。視野角を広げるだけで、VRではヘッドセットが投影を所有します。
docs/flags.mdには残りのフラグがあり、その理由も含まれています。
変更履歴とリリースノート
- 人間が読める履歴はCHANGELOG.mdに記録されています。
- タグ付けされたGitHubリリースでは、対応する変更履歴セクションをリリースノートとして使用します。
操作方法
docs/controls.mdには、キーボードとマウス、画面上のタッチコントロール、ゲームパッド、XRコントローラーなど、すべての操作方法が記載されています。ゲーム内では、/または?でキーボードの操作方法が表示されます。
WebXR
VRモードはネイティブWebXRを使用し、immersive-vrをサポートするブラウザとヘッドセットが必要です。ローカル検証のためには、ゲームをhttp://localhost:5154で開いてください。リモートアクセスの場合、ゲームをhttps://経由で提供してください(サーバー自身のhttps証明書を使用するか、リバースプロキシで提供)。クライアントは、ページがHTTPS経由で提供される場合に、WebSocket接続にwss://を自動的に使用します。
インストールされたアプリを起動するヘッドセットブラウザは、2DランディングページなしでVRに入ろうとします。xr-launch.jsは、クライアントの残りの部分がロードされる前にセッションを要求し、没入型セッションに必要なユーザーアクティベーションを伝える可能性のある各シグナル(ウィンドウロード、フォーカス、ページ表示、可視性変更、およびLaunch Handler)で要求を続けます。レンダラーは、いずれかのセッション結果を拾います。それらがどれも成功しない場合、およびそれ以外のすべての場所で、VRモードはボタンから開始されます。
保存された名前はすぐに参加し、名前がない場合はXRメニューが、2Dエントリーダイアログと同じ名前、チーム、戦車の選択肢を持つ参加画面を開くため、プレイヤーが見ることのできない画面で待つ必要はありません。
XRでの入力は、名前またはMOTD行がフォーカスを取得したときに表示されるヘッドセット固有のシステムキーボードを使用します。Quest Browser 26.1以降ではこれが提供されます。提供されないヘッドセットは、それらの行をデスクトップ専用とマークし、プレイヤーはサーバーが割り当てる名前で参加できます。キーボードが開くたびに新しい編集が開始されるため、最初のキーはフィールド全体に追記するのではなく、フィールド全体を置き換えます。
設定ギアの横にあるワンタップVRボタンは、ヘッドセットが搭載されたデバイスでのみ表示されます。これは、Cardboard経由でChrome on Androidがどの電話でもimmersive-vrサポートを報告するためです。VRモードは、そこでは設定メニュー内に留まります。
デプロイメントが制限的なPermissions-Policyヘッダーを設定している場合は、xr-spatial-tracking=(self)を許可してください。TLSは、サーバー自身のもの(https、docs/installation.mdを参照)またはリバースプロキシのもの(docs/installation.md)のいずれかです。
新しいブラウザ、ヘッドセット、またはデプロイメントを確認する際は、WebXR検証チェックリストを使用してください。WebGPUレンダリングは、このチェックリストの範囲外です。
開発チェック
npm run check
これは、構文およびリンティングチェック、サーバー起動チェック、およびテストスイートを実行します。
CIもプッシュおよびプルリクエストでこれらのチェックを実行します。
リリースプロセス
すべてをコミットしてから、何も残さないでください。タグはツリーに名前を付けます。そのため、タグが出されたときに作業ディレクトリに残っている編集はリリースに含まれません。バージョンは1つのことを言い、ボックスは別のことを言い、誰もタグから再現できません。これには、他の誰かがコミットせずに残した作業も含まれます。レビューし、それが何であるかを述べ、それをコミットしてください。タグはその周りをタグ付けするのではなく。リリース準備前にgit statusはクリーンであり、タグがプッシュされたら再びクリーンになります。終了時に保留中のものはすべて、リリースがそれなしで出たことを意味します。
リリースタグは安定版のvX.Y.Z SemVerのみです。プレリリースおよびビルドメタデータは公開されません。
ローカルでリリースを準備します:
npm run release:prepare -- 1.0.1
これにより以下が更新されます:
package.jsonpackage-lock.jsonpublic/version.mjsCHANGELOG.md
これら4つすべてがリリースコミットに入ります。public/version.mjsは置き忘れやすいもので、それなしのタグはそれ以前のバージョンを報告するクライアントを出荷します。
次に、新しい変更履歴セクションを編集して、実際のユーザーが見える変更が含まれるようにします。
ローカルで検証します:
npm run check
npm run release:check -- v1.0.1
npm run release:check:increment -- v1.0.1
その後、コミット、タグ付け、プッシュを行います:
git add package.json package-lock.json public/version.mjs CHANGELOG.md
git commit -m "Release v1.0.1 - short description. Closes #1"
git tag v1.0.1
git push
git push origin v1.0.1
件名は、リリースをラベル付けするのではなく、リリースを説明します。バージョンはすでにタグ、package.json、CHANGELOG.mdに含まれており、git log --onelineは件名がすべてである唯一のビューです。数語で変更を名前付けし、リリースがそれを完了した場所で実際のクローズキーワードで問題を参照してください。ベア (#NN) はリンクするだけです。
リリースワークフローは以下を実行します:
- 安定版タグが前のリリースよりも新しく、
mainを指していることを確認します。 - 依存関係をインストールし、リンティング、検証、監査、およびCodeQLチェックを実行します。
package.jsonがプッシュされたタグと一致しない場合は失敗します。- CHANGELOG.mdに一致するプレースホルダーでないセクションが含まれていない場合は失敗します。
- UbuntuのNode.js 22を使用して、
linux/amd64およびlinux/arm64用のUbuntu 26.04イメージをビルドおよびスモークテストします。 - 検証済みのバージョン付きおよび移動タグをGHCRに昇格させます。
- GitHubリリースを公開し、ソースtarballを添付します。
ワークフローが失敗したリリースはそのままにしておきます。 bzoは開発中であり、すべてのタグが成果物を生成するわけではありません。原因を修正し、次のバージョンに進んでください。公開されたタグを削除または移動しないでください。ビルドされなかったもののGitHubリリースをバックフィルしないでください。CHANGELOG.mdはどちらの場合も記録であり、失敗したバージョンのセクションがすでに含まれています。
public/version.mjsはscripts/prepare-release.mjsによって書き込まれ、scripts/check-release.mjsによってタグに対して検証されます。手動で編集しないでください。ハードコードされたクライアントバージョン文字列を他の場所に再導入しないでください。
バンドルされたアセットとライセンス
コードはAGPLv3です。アセットはすべて同じではありません。
bzoは、いくつかの場所からのモデル、テクスチャ、サウンド、マップを配布しています。一部はBZFlagプロジェクトのもので、そのライセンスの下で使用されています。一部はbzoのために作成されました。一部は貢献とともに到着しました。ファイルは、リポジトリに存在するだけでリポジトリのライセンスを継承するわけではありません。また、その起源が記録されていないアセットは、次に尋ねる人にとっての質問となります。
ここに追加されるものに期待されること:
- プルリクエストで、どこから来たのか、どのような条件で来たのかを述べてください。
- AGPLv3配布と互換性のある条件を優先してください。
- ファイルがツールによってエクスポートされたというヘッダーは、何も付与するものではなく、作者がそれを調べていないという注記も同様です。
すでにツリーにあるすべての資産がその基準を満たしているわけではありません。一部は期待よりも古く、一部はそれ自体で価値のある貢献とともに到着しました。意図は、それがすでに完了していると偽るのではなく、それらすべてのアセットの明確で記録されたライセンスに到達することです。ここにあるものの起源を知っている場合、またはその作者である場合は、イシューで教えてください。これが完了するための最も簡単な方法です。
マップも同様の質問です。サーバーからダウンロードされたマップ、またはクライアントによって保存されたマップは、何も付与しません。マップ形式自体については、docs/bzw.mdを参照してください。
AGPLソースの利用可能性
このプロジェクトはGNU Affero General Public License v3.0の下でライセンスされています。ネットワークユーザーは、実行中のアプリから/source経由でソースコードにアクセスするか、直接以下からアクセスできます: