ゲームサーバー · Nakama・SpacetimeDB と代替候補

ゲームロジックではなく、コミュニティ機能で選びましょう

ゲームサーバーはまったく別の2つの仕事をします。一つはゲームそのもの — 駒を動かし、命中を判定し、世界を一貫させること。もう一つはゲームを取り巻くすべてで、この2つ目が初心者の想像よりはるかに大きいのです。そしてプレイヤーが明日また戻ってくるかを決めるのも、こちらです。

フレームレートを比べる前に、以下のうち何個を自分で作り、セキュリティを見て、運用まで行う必要があるかを数えてみてください。

アカウントとログイン — 端末・メール・Apple・Google・Steam、そしてそれらを一人のプレイヤーに束ね、端末が変わっても進行が続くようにすること。
チャットと掲示板 — 1対1・グループ・ルームのチャット、再接続しても残る履歴、そして通報とブロック。
ギルドとフレンド — 参加申請、役割と権限、メンバー一覧、プレゼンス（今誰がオンラインか）。
リーダーボードとトーナメント — 日次・週次のリセット、同点処理のルール、そして不正ユーザーを上位から外すこと。
プッシュ通知と課金 — スタミナが回復したと知らせること、そして何かを付与する前にレシートが本物か検証すること。

Docker — サーバーは結局こう動きます

どのサーバーを選んでも結局どこかで動かす必要があり、今日その「どこか」はほぼ常にコンテナです。Docker はサーバーと、それが動くのに必要なすべて — ランタイム、ライブラリ、設定 — を一つの塊にまとめます。その結果できたイメージ一つが、自分のノートパソコンでも、別の国で借りたマシンでも同じように動きます。

ゲームサーバーではこれが他のソフトウェアより重要になります。ゲームのバックエンドは決してプログラム一つではないからです。サーバーにデータベースが付き、たいていキャッシュまで付き、それらが互いを見つけて正しい順序で起動しなければなりません。Docker はその作業を、一ページのセットアップ手順からファイル一つとコマンド一つに変えます — Nakama も SpacetimeDB もクイックスタートをコンテナで案内するのは、これが理由です。

必要な4つの言葉

イメージ プログラムとその環境を凍らせた読み取り専用のスナップショットです。他人が作ったものを取得するか（nakama・postgres）、Dockerfile で自分で作ります。イメージはタグでバージョンが付きます — latest ではなく実際のバージョンを固定しましょう。さもないとある朝、サーバーが足元で変わります。

コンテナ イメージを実際に起動したものです。コンテナは意図的に使い捨てとして設計されています — 一つを止めて同じイメージから新しく起動しても、失うものはありません。コツはそれだけです：捨てるのが安全なら、デプロイも安全です。

ボリューム コンテナより長く生きる保存領域です。コンテナの中に書いたものは、入れ替わった瞬間に消えます — だからデータベースのファイルはコンテナではなくボリュームに置かなければなりません。初心者がプレイヤーデータを失う最もよくある経路が、まさにこれです。

ネットワークとポート 同じ Docker ネットワーク上のコンテナは、互いを名前で見つけます — ゲームサーバーは IP アドレスではなく postgres に接続します。ポートはプレイヤーが直接つなぐものだけ外に開けばよく、ホストのポート一つはちょうど一つのプロセスのものです。

Compose — スタック全体をファイル一つで

ゲームのバックエンドは、一緒に起動しなければならない複数のコンテナです。Docker Compose はそのすべて — サーバー・データベース・キャッシュ — を、ボリューム・ネットワーク・起動順序とともに一つの YAML ファイルに書きます。すると docker compose up の一行でスタック全体が立ち上がり、実サーバーにコピーするのも同じファイルです。

今夜すぐ Nakama を試せる理由がこれです。公式のクイックスタートはサービス2つの compose ファイルで、コマンド一つでデータベース付きのゲームバックエンドが自分のマシンで動きます。システムに入るものもなく、後で消すものもありません。

初心者がつまずく3つのこと

ボリュームを消すとデータベースが消えます。 ボリュームまで片づけるオプションの付いたコマンドは、コンテナと一緒にプレイヤーデータも喜んで消します。片づけのコマンドを走らせる前に、それがどのボリュームに触れるのかを正確に知りましょう — そして知る前に、まずバックアップを。
ホストのポート一つに、プロセス一つです。 既に何かがそのポートを握っていれば、2つ目のコンテナは単に起動に失敗します。サイトを複数動かすマシンでよくある原因で、解決策はポートを開かず、前段のリバースプロキシ一つにドメインで振り分けさせることです。
起動しないならログを読みましょう。 コンテナの失敗のほとんどは、自分のログに理由を書いています。そして初心者のほとんどは、見る代わりに推測します。ログを読むことを最後ではなく最初にしましょう。

このサイトも同じ方式で動いています

PES は Compose ファイル一つに書かれた4つのコンテナです — Web アプリ、PostgreSQL、リアルタイムを担う Centrifugo、そして Redis。その前に HTTPS を終端する共用リバースプロキシがいます。変更のデプロイは、コードを上げてサービス一つを再ビルドすることです。ゲームサーバーのために Docker を学べば、これから作る他のすべてをデプロイする方法も一緒に学んだことになります。

SpacetimeDB

SpacetimeDB は根本的に違う道を選びます — データベースがそのままサーバーです。データベースと会話するゲームサーバーを別に書くのではなく、データベースの中で動く関数（リデューサー）を書き、クライアントはエンドポイントを呼ぶ代わりにクエリを購読します。別途デプロイするサーバープロセスがなく、2つのシステム間の同期コードもありません。システムが一つしかないからです。

そのため持続する世界を作るとき本当に優雅で、構造が単純なので一人で全体を頭に入れられます。代償は、まだ若く生態系が小さいこと、そして考え方の転換に実際の労力がかかることです — 単純ですが、すでに知っているものとは違います。

Nakama とは何か

Nakama は Heroic Labs によるオープンソースのゲームバックエンドサーバーです。Go で書かれ、単一バイナリ一つと PostgreSQL 互換データベースとして配布されます。ネットコードのライブラリでもホスティングプラットフォームでもありません — その2つの間の層です。プレイヤーが誰で、何を持ち、誰と遊んでいるのかを知っている側です。

導入するとすぐに次のものが手に入ります。

アイデンティティと認証 — 端末 ID・メール・Apple・Google・Facebook・Steam・カスタム。一つのアカウントに複数の認証手段を紐づけ、プラットフォームをまたいで機能します。
ストレージエンジン — バージョン付きの JSON ドキュメント、オブジェクトごとの所有権とアクセス規則。プレイヤーのセーブデータはここに入ります。
ソーシャル — フレンド、グループとギルド、プレゼンス、そしてチャット（1対1・グループ・ルーム）とメッセージ履歴。
競争 — リセット周期を設定できるリーダーボードとトーナメント、そして属性で条件を指定するマッチメイカー。
エコノミー — アトミックな台帳取引に対応した財布、そして Apple・Google・Steam のアプリ内課金レシート検証。
リアルタイム — WebSocket と rUDP ソケット、そしてサーバー側のティックループを自分で書く権威的マッチランタイム。
ランタイムモジュール — Go・Lua・TypeScript でサーバーを拡張します。独自の RPC を登録し、組み込み動作の前後にフックを掛けます。

PES は Nakama を使っていません

このページは Nakama を複数の選択肢の一つとして教えます。このサイト自体は SvelteKit・PostgreSQL・Centrifugo・Redis で動いており、Nakama は使っていません。自分たちのスタックではなく、一つの道具を説明しています。

実際に良いところ

拡張モデルこそが本当の機能 多くのマネージド型バックエンドは固定の API を与え、逃げ道としてサーバーレス関数を一つ用意します。Nakama はすべての組み込み呼び出しの前後にフックを掛け、任意の RPC をプロセス内に登録させてくれます。自作のロジックが同じバイナリの中でデータベースに直接アクセスしながら動きます — コールドスタートもなく、ラムダへのネットワーク往復もありません。Go なら型付きインターフェースをネイティブ速度で扱えます。

単一バイナリでの運用 Nakama 一つにデータベース一つ。Kubernetes もサービスメッシュもメッセージブローカーも不要です。小さなクラウドインスタンス1台ですべて動かせ、気にする必要が出てくるまで数万人の同時接続を難なくさばきます。この分野では珍しいことです — 競合の多くは完全マネージドかクラスター運用を前提にしています。

本当にオープンソースで、データは自分のもの Apache 2.0 ライセンスです。データベースは自分のもの、スキーマは文書化され、サーバーは自分のハードウェアで動きます。Heroic Labs が明日消えてもゲームは動き続けます。出口はサポートチケットではなく、データベースのダンプです。

ソーシャル層が成熟している 履歴の残るチャット、役割と参加申請のあるグループ、フレンド関係、プレゼンス — 作るのは退屈で、微妙に間違えやすいものです。Nakama の実装は10年近く実サービスで動いてきました。

書き直さずにマネージドへ Heroic Cloud はセルフホストと同じサーバーを動かします。マネージドへの移行は移植ではなく設定変更です。どちらの方向にも道が塞がれません。

苦手なこと

決める前に知っておくべきことです。隠された秘密ではなく、上で見た設計上の選択の結果です。

専用サーバーのオーケストレーションはしない Nakama には権威的マッチランタイムがありますが、専用サーバーのオーケストレーションは自前で行わず、Edgegap や GameLift といったパートナーに委ねます。マッチごとにヘッドレスの Unreal・Unity ビルドを立てる必要があるなら、それは別に解くべき問題です。

マッチループは共有プロセス内の固定ティック ターン制・カード・ボード・カジュアルなリアルタイム・軽いアクションには十分です。128人シューターに使うものではありません。

ランタイムはサンドボックスではない 「クラウドコード」という言葉の印象とは違い、まずい Go モジュール一つでサーバー全体が落ちます。プロセス内でネイティブ速度で動くことの裏面です。

クラスタリングは Enterprise 限定 オープンソース版はシングルノードです。費用を払うと決めるまでは、より大きなマシンへの垂直スケールで凌ぎます。小さなゲームにとって天井は遠いですが、確かに存在する天井です。

ストレージのクエリに制約がある キーバリューに多少の JSON インデックスが付く程度で、プレイヤーデータに任意の SQL を投げられるわけではありません。Go モジュールからデータベースを直接照会するのが一般的な回避策です。

代替候補

Nakama と同じくらい良い一つの答えはありません。何を最適化したいかで分かれます。自分にとっての難所が何かを先に決めてから選びましょう。

考え方が最も近いもの — オープンソース、セルフホスト可能

	言語	強み	Nakama と比べた弱み
Colyseus	TypeScript / Node	同種で最良の自動状態同期、組み込みマッチメイキング、Unity・Defold・Construct・Haxe・JS の SDK。	リアルタイムのルームのみ — アイデンティティ・ストレージ・ソーシャル・エコノミー・リーダーボードがありません。メタ層は自分で作ります。
SpacetimeDB	Rust / C# モジュール	根本的に異なるモデル — データベースがそのままサーバーです。クライアントはクエリを購読し、エンドポイントの代わりにリデューサーを書きます。持続する世界のゲームに本当に優雅です。	まだ若く生態系が小さく、考え方の転換に実際の労力がかかります。
Rivet	Rust コア、JS/TS スクリプティング	Apache 2.0 でセルフホスト可能。ゲームサーバー・マッチメイキング・認証に加えてバックエンドスクリプティングまで — Nakama を丸ごと置き換えるのに最も近い存在です。	コミュニティが小さく、会社が汎用のステートフルサービス方面へ舵を切ったため、ゲームへの集中度が薄まっています。
Agones + Open Match	Kubernetes	Google が支援しており、専用サーバー群をオーケストレーションする業界標準です。	別の問題を解きます — メタ層がまったくありません。Nakama を置き換えるのではなく、併用するものです。

マネージド・商用

PlayFab — Microsoft の製品で、この分野で最も機能の幅が広いものです — LiveOps・A/B テスト・セグメント・分析・エコノミー。マッチメイキングと専用サーバーの両方を備えますが、Azure 上でのみ動きます。従量課金で、データは自分のものになりません。
AccelByte — エンタープライズ級で、専用サーバーのオーケストレーションを自前で運用する唯一の競合です。資金のあるスタジオ向けの価格です。
Pragma — ライブサービスゲームのための「バックエンドゲームエンジン」を掲げます。深いカスタマイズ、パーティとマッチメイキング、サーバー割り当て、インベントリ、成長、バトルパスとストア。商用側で Nakama と最も哲学が近い存在です。
Photon (Fusion / Quantum) — バックエンドではなくネットワーキングが先です。Quantum の決定論的ロールバックは競技性の高いアクションゲームで並ぶものがありませんが、サービスが付いたネットコード製品であって、その逆ではありません。
LootLocker · brainCloud · Beamable — マネージドで開始が速く、薄い作りです。LootLocker はマッチメイキングもサーバーもなく、Beamable はリレーのみで実時間処理は外部に回します。ゲームがバックエンドをほとんど必要としないときに向きます。

市場についてひとつ

この分野は他より速く統合が進みます — この領域のホスティングサービスが、大きな予告もなく終了したり事業から撤退した例があります。何年も回し続けるライブサービスを計画しているなら、セルフホスト可能なオープンソースを選ぶ理由になります。

どう選ぶか

難しいのはリアルタイム同期で、メタ層は単純だ → Colyseus
持続する共有世界で、設計を考え直す覚悟がある → SpacetimeDB
アイデンティティ・ソーシャル・エコノミー・リーダーボードが必要で、セルフホストしたい → Nakama
マッチごとに専用サーバー群が必要だ → Agones と Open Match、または Edgegap — その横にメタバックエンドを別に置く
LiveOps のツールを作るより買って使いたい → PlayFab または Pragma
すでに自前のリアルタイムサーバーがある → メタサービスだけを Nakama に任せるのも、よくある合理的なやり方だ

セルフホストを好み、特定ベンダーに縛られたくないなら、正直な候補は Nakama・Colyseus・メタ層を自作の3つです。Nakama を選ぶ取引はこうです — 大きくて主張の強い Go バイナリを一つ受け入れる代わりに、フレンド・チャット・ウォレット・リーダーボードを作る半年を飛ばします。問うべきはこれです：自分のゲームのメタ層は Nakama の前提と十分に似ていて、それと戦うのではなく拡張することになるか。