ゲームサーバー
サーバーはゲームロジックだけではありません。プレイヤーが誰で、誰と一緒に遊ぶのかが、すべてここにあります。
多くの人はゲームサーバーを選ぶとき、まず「自分のゲームルールを十分速く回せるか」を尋ねます。最初の問いとしては間違いです。半年後に時間を食うのはルールではなく、アカウント・フレンド・ギルド・チャット・リーダーボード・プッシュ通知・レシートです。それらを既に持つサーバーを選ぶか、自分で作る覚悟をしてください。
ゲームロジックではなく、コミュニティ機能で選びましょう
ゲームサーバーはまったく別の2つの仕事をします。一つはゲームそのもの — 駒を動かし、命中を判定し、世界を一貫させること。もう一つはゲームを取り巻くすべてで、この2つ目が初心者の想像よりはるかに大きいのです。そしてプレイヤーが明日また戻ってくるかを決めるのも、こちらです。
フレームレートを比べる前に、以下のうち何個を自分で作り、セキュリティを見て、運用まで行う必要があるかを数えてみてください。
- アカウントとログイン — 端末・メール・Apple・Google・Steam、そしてそれらを一人のプレイヤーに束ね、端末が変わっても進行が続くようにすること。
- チャットと掲示板 — 1対1・グループ・ルームのチャット、再接続しても残る履歴、そして通報とブロック。
- ギルドとフレンド — 参加申請、役割と権限、メンバー一覧、プレゼンス（今誰がオンラインか）。
- リーダーボードとトーナメント — 日次・週次のリセット、同点処理のルール、そして不正ユーザーを上位から外すこと。
- プッシュ通知と課金 — スタミナが回復したと知らせること、そして何かを付与する前にレシートが本物か検証すること。
Docker — サーバーは結局こう動きます
どのサーバーを選んでも結局どこかで動かす必要があり、今日その「どこか」はほぼ常にコンテナです。Docker はサーバーと、それが動くのに必要なすべて — ランタイム、ライブラリ、設定 — を一つの塊にまとめます。その結果できたイメージ一つが、自分のノートパソコンでも、別の国で借りたマシンでも同じように動きます。
ゲームサーバーではこれが他のソフトウェアより重要になります。ゲームのバックエンドは決してプログラム一つではないからです。サーバーにデータベースが付き、たいていキャッシュまで付き、それらが互いを見つけて正しい順序で起動しなければなりません。Docker はその作業を、一ページのセットアップ手順からファイル一つとコマンド一つに変えます — Nakama も SpacetimeDB もクイックスタートをコンテナで案内するのは、これが理由です。
必要な4つの言葉
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 を登録し、組み込み動作の前後にフックを掛けます。
このページは Nakama を複数の選択肢の一つとして教えます。このサイト自体は Laravel・PostgreSQL・Centrifugo・Redis で動いており、Nakama は使っていません。自分たちのスタックではなく、一つの道具を説明しています。
実際に良いところ
苦手なこと
決める前に知っておくべきことです。隠された秘密ではなく、上で見た設計上の選択の結果です。
代替候補
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 の前提と十分に似ていて、それと戦うのではなく拡張することになるか。