ゲームサーバー
はだけではありません。プレイヤーが誰で、誰と一緒に遊ぶのかが、すべてここにあります。
ゲームサーバーは、ルールを回す速さよりアカウント・フレンド・チャット・ランキングといったコミュニティ機能で選びます。必要な機能を書き出し、Nakama と他の選択肢を比べましょう。
ゲームロジックではなく、コミュニティ機能で選びましょう
ゲームサーバーはまったく別の2つの仕事をします。一つはゲームそのもの — 駒を動かし、命中を判定し、世界を一貫させること。もう一つはゲームを取り巻くすべてで、この2つ目が初心者の想像よりはるかに大きいのです。そしてプレイヤーが明日また戻ってくるかを決めるのも、こちらです。
レートを比べる前に、以下のうち何個を自分で作り、を見て、運用まで行う必要があるかを数えてみてください。
- アカウントとログイン — ・メール・Apple・Google・、そしてそれらを一人のプレイヤーに束ね、端末が変わっても進行が続くようにすること。
- チャットと掲示板 — 1対1・グループ・ルームのチャット、再接続しても残る履歴、そして通報とブロック。
- ギルドとフレンド — 参加申請、役割と、メンバー一覧、（今誰がオンラインか）。
- リーダーボードとトーナメント — 日次・週次のリセット、同点処理のルール、そして不正ユーザーを上位から外すこと。
- プッシュ通知と課金 — スタミナが回復したと知らせること、そして何かを付与する前にすること。
Docker — サーバーは結局こう動きます
どのサーバーを選んでも結局どこかで動かす必要があり、今日その「どこか」はほぼ常にです。 はサーバーと、それが動くのに必要なすべて — 、、設定 — を一つの塊にまとめます。その結果できたイメージ一つが、自分のノートパソコンでも、別の国で借りたマシンでも同じように動きます。
ゲームサーバーでは、これがさらに重要になります。ゲームのは決して一つではないからです。サーバーにが付き、たいていも付きます。それらは互いを見つけて、正しい順序で起動しなければなりません。Docker を使えば、一ページのセットアップ手順がファイル一つとコマンド一つに縮まります。後のタブで扱うゲームバックエンドサーバー も、公式クイックスタートを で案内しています。
必要な4つの言葉
Compose — スタック全体をファイル一つで
ゲームのバックエンドは、一緒に起動しなければならない複数のコンテナです。Docker Compose はそのすべて — サーバー・データベース・キャッシュ — を、ボリューム・ネットワーク・起動順序とともに一つの ファイルに書きます。すると の一行で全体が立ち上がり、実サーバーにコピーするのも同じファイルです。
今夜すぐ Nakama（後で見るゲームバックエンドサーバー）を試せる理由がこれです。公式のクイックスタートはサービス2つの compose ファイルで、コマンド一つでデータベース付きのゲームバックエンドが自分のマシンで動きます。システムに入るものもなく、後で消すものもありません。
初心者がつまずく3つのこと
- ボリュームを消すとデータベースが消えます。 ボリュームまで片づけるオプションの付いたコマンドは、コンテナと一緒にプレイヤーデータも喜んで消します。片づけのコマンドを走らせる前に、それがどのボリュームに触れるのかを正確に知りましょう — そして知る前に、まずを。
- ホストのポート一つに、プロセス一つです。 既に何かがそのポートを握っていれば、2つ目のコンテナは単に起動に失敗します。サイトを複数動かすマシンでよくある原因で、解決策はポートを開かず、前段の一つにで振り分けさせることです。
- 起動しないならログを読みましょう。 コンテナの失敗のほとんどは、自分のログに理由を書いています。そして初心者のほとんどは、見る代わりに推測します。むことを最後ではなく最初にしましょう。
SONUB は Compose ファイル一つに書かれた複数のコンテナで動きます — と裏で働くワーカー（キュー・）、PostgreSQL、、リアルタイムを担う 、バックアップ。その前の共用リバースプロキシが 接続を受けて復号し、中へ渡します。変更のデプロイは、を上げてサービスを再することです。ゲームサーバーのために Docker を学べば、これから作る他のものをデプロイする方法も一緒に学んだことになります。
SpacetimeDB
は普通のゲームサーバーとは違う道を選びます。がそのままサーバーです。データベースと会話するゲームサーバーを別に書くことはせず、・ などの言語で書いたを上げると、その中の関数（）がデータベースの中で動いてテーブルを変えます。はリデューサーを呼んで状態を変え、必要なして変わった行をすぐに受け取ります。システムが一つしかないので、別にするサーバープロセスも、2つのシステムを合わせる同期もありません。
そのため持続する世界を作るとき本当に優雅で、構造が単純なので一人で全体を頭に入れられます。代償は、まだ若くが小さいこと、そして考え方の転換に実際の労力がかかることです — 単純ですが、すでに知っているものとは違います。
Nakama とは何か
は Heroic Labs によるのゲームサーバーです。 で書かれ、単一一つと 互換として配布されます。ネットのでもでもありません — その2つの間の層です。プレイヤーが誰で、何を持ち、誰と遊んでいるのかを知っている側です。
導入するとすぐに次のものが手に入ります。
- アイデンティティと — ・メール・Apple・Google・Facebook・・カスタム。一つのアカウントに複数の認証手段を紐づけ、プラットフォームをまたいで機能します。
- — 付きの ドキュメント、ごとの所有権とアクセス規則。プレイヤーのセーブはここに入ります。
- ソーシャル — フレンド、グループと、、そしてチャット（1対1・グループ・ルーム）とメッセージ履歴。
- 競争 — リセット周期を設定できるとトーナメント、そして属性で条件を指定するマッチメイカー。
- エコノミー — な台帳取引に対応した財布、そして Apple・Google・Steam の。
- リアルタイム — と 、そしてを担うマッチ — サーバー側のを自分で書きます。
- ランタイム — Go・・ でサーバーを拡張します。独自の を登録し、組み込み動作の前後にます。
このページは Nakama を複数の選択肢の一つとして教えます。このサイト自体は ・PostgreSQL・・ で動いており、Nakama は使っていません。自分たちのではなく、一つの道具を説明しています。
実際に良いところ
苦手なこと
決める前に知っておくべきことです。隠された秘密ではなく、上で見た設計上の選択の結果です。
代替候補
と同じくらい良い一つの答えはありません。何を最適化したいかで分かれます。自分にとっての難所が何かを先に決めてから選びましょう。下の「」はマッチの外の機能（アカウント・フレンド・チャット・セーブ・）、「」はリリース後のイベント・ショップ・アップデートを運営することです。
考え方が最も近いもの — オープンソース、セルフホスト可能
| 言語 | 強み | Nakama と比べた弱み | |
|---|---|---|---|
| / | 同種で最良の自動、組み込み、・・・・ の 。 | リアルタイムのルームのみ — アイデンティティ・ストレージ・ソーシャル・エコノミー・リーダーボードがありません。メタ層は自分で作ります。 | |
| / | 根本的に異なるモデル — がそのままサーバーです。はし、の代わりにを書きます。持続する世界のゲームに本当に優雅です。 | まだ若くが小さく、考え方の転換に実際の労力がかかります。 | |
| Rivet | Rust コア、JS/TS スクリプティング | で可能。ゲームサーバー・マッチメイキング・に加えてスクリプティングまで — Nakama を丸ごと置き換えるのに最も近い存在です。 | コミュニティが小さく、会社が汎用の方面へ舵を切ったため、ゲームへの集中度が薄まっています。 |
| + | Google が支援しており、群をする業界標準です。 | 別の問題を解きます — メタ層がまったくありません。Nakama を置き換えるのではなく、併用するものです。 |
マネージド・商用
- — Microsoft の製品で、この分野で最も機能の幅が広いものです — LiveOps・・セグメント・分析・エコノミー。マッチメイキングと専用サーバーの両方を備えますが、 上でのみ動きます。従量課金で、は自分のものになりません。
- AccelByte — エンタープライズ級で、専用サーバーのオーケストレーションを自前で運用する唯一の競合です。資金のあるスタジオ向けの価格です。
- Pragma — ライブサービスゲームのための「バックエンド」を掲げます。深いカスタマイズ、パーティとマッチメイキング、サーバー割り当て、インベントリ、成長、とストア。商用側で Nakama と最も哲学が近い存在です。
- (Fusion / Quantum) — バックエンドではなくが先です。Quantum のは競技性の高いアクションゲームで並ぶものがありませんが、サービスが付いたネット製品であって、その逆ではありません。
- LootLocker · brainCloud · Beamable — マネージドで開始が速く、薄い作りです。LootLocker はマッチメイキングもサーバーもなく、Beamable はのみで実時間処理は外部に回します。ゲームがバックエンドをほとんど必要としないときに向きます。
この分野は他より速く統合が進みます — この領域のホスティングサービスが、大きな予告もなく終了したり事業から撤退した例があります。何年も回し続けるライブサービスを計画しているなら、セルフホスト可能なを選ぶ理由になります。
どう選ぶか
- 難しいのはリアルタイム同期で、メタ層は単純だ →
- 持続する共有世界で、設計を考え直す覚悟がある →
- アイデンティティ・ソーシャル・エコノミー・リーダーボードが必要で、セルフホストしたい →
- マッチごとに専用サーバー群が必要だ → と 、または — その横にメタを別に置く
- LiveOps のツールを作るより買って使いたい → PlayFab または Pragma
- すでに自前のリアルタイムサーバーがある → メタサービスだけを Nakama に任せるのも、よくある合理的なやり方だ
を好み、たくないなら、正直な候補は Nakama・Colyseus・を自作の3つです。Nakama を選ぶ取引はこうです — 大きくて主張の強い を一つ受け入れる代わりに、フレンド・チャット・ウォレット・を作る半年を飛ばします。問うべきはこれです：自分のゲームのメタ層は Nakama の前提と十分に似ていて、それと戦うのではなく拡張することになるか。