複数端末でゲームを遊ぶときのデータの考え方
遊びをつくる執筆にClaudeを使用しています。
スマートフォンで途中まで進めたゲームを、帰宅後にPCで続けようとしたら最初からだった――そんな体験をしたプレイヤーは少なくないはずです。この問題は、プレイヤーの不満になるだけでなく、「もう一度やり直すのが面倒」という理由でゲーム自体を離脱させる原因にもなります。 ゲームを作る側からすると、複数端末対応は「あれば嬉しい機能」ではなく、公開後のプレイヤー体験を大きく左右する設計上の判断です。どこにデータを置き、どのタイミングで読み書きするかを最初に決めておかないと、後から直すのに大きなコストがかかります。この記事では、複数端末をまたぐデータ管理の仕組みと、ブラウザゲームを作る際の具体的な判断基準を整理します。
この記事の目次
データをどこに保存するかで、挙動がすべて変わる
ブラウザゲームがセーブデータを置ける場所は大きく三つに分けられます。
ブラウザのローカルストレージは、実装がもっとも簡単です。JavaScriptの数行で読み書きでき、サーバーも不要です。ただし、データはそのブラウザ・そのデバイスにしか存在しません。スマートフォンのChromeで保存したデータを、PCのFirefoxで読むことはできません。同じデバイスでも、プライベートブラウジングや「閲覧データの削除」で消えます。
外部のクラウドデータベース（FirebaseのRealtimeDatabaseやFirestoreなど）は、ユーザーを識別する仕組みと組み合わせることで、どの端末からアクセスしても同じデータを参照できます。実装の手間はローカルストレージより大きくなりますが、複数端末対応の本命です。
プラットフォームが提供するクラウドセーブは、プラットフォーム側がデータの保存・同期をまとめて担う方式です。アソバースでは、作者がSDKで対応したゲームに限り、共通ログインとクラウドセーブを利用できます。プレイ履歴はプラットフォームが管理しますが、ゲーム内部のセーブデータとは別物であるため、SDKの組み込みなしに「自動で引き継がれる」とは考えないようにしてください。
ユーザー識別とデータの紐付けを設計する
複数端末対応で最初につまずくのは、「このデータは誰のものか」を確定させる仕組みです。ローカルストレージには識別子が不要ですが、クラウドに保存するときは必ずユーザーを識別する何かが必要になります。
選択肢は主に三つです。
- プラットフォームの認証を使う：アソバースのSDKで共通ログインに対応すれば、プラットフォームが発行するユーザーIDをゲーム内で受け取れます。メールアドレスやパスワードの管理をゲーム側で持たずに済むのが利点です。
- 外部認証サービスを使う：FirebaseAuthenticationやAuth0などのサービスを組み込み、Googleアカウントやメールアドレスでログインさせる方法です。プラットフォームを問わず使えます。
- ゲーム独自のIDを発行する：ランダムなIDをローカルに保存し、それをクラウドのキーとして使う方法です。最初にIDを作ったデバイスを失うとデータにアクセスできなくなるため、複数端末対応の手段としては不十分です。
「ログイン不要で手軽に遊べる」カジュアルゲームと、「進行を引き継いで長く遊んでほしい」ゲームでは、求める認証の強度が違います。まず自分のゲームがどちらに近いかを決め、それに合った方式を選ぶのが順序です。
「どのデータを同期するか」を絞る
認証の仕組みが決まったら、次は「何を同期対象にするか」を絞り込みます。すべてのゲーム状態をリアルタイムで同期しようとすると、通信コストも実装コストも跳ね上がります。
同期が必要なデータの典型は、ステージのクリア状況・アンロックしたアイテム・スコアの最高記録・キャラクターのレベルや所持品などです。一方、エフェクトの設定・BGMのオン／オフ・操作の入力状態など「端末ごとに違って当然」なものは、ローカルストレージに置いたままにする方が自然です。
設計の出発点として「ゲームを別の端末で再開したとき、プレイヤーが『戻ってきた』と感じるのに最低限必要な情報はどれか」という問いを立てると、同期すべきデータが絞りやすくなります。
競合と上書きの問題を先に考えておく
複数端末から同じデータに書き込む状況では、「どちらが正しいデータか」という競合が起きます。これを事前に設計していないと、後から発生するバグの中でもっとも原因が見えにくいものの一つになります。
よく使われる解決策はタイムスタンプによる最新優先です。保存のたびに更新時刻を記録し、読み込み時に新しい方を採用します。ただしこれは、「古いデータを意図的に使いたい場面」（誤操作で強いキャラを削除した直後に別端末から上書きされる、など）には対応できません。
より安全なのは、マージ可能な構造でデータを持つことです。たとえば「どのステージをクリアしたか」をフラグの集合として保存する場合、二つのデータを統合するのは「どちらかがクリア済みなら済み」とするだけで済みます。一方、「所持金の現在値」のような絶対値は競合時の処理が難しいため、差分（増減の履歴）として持つ設計が有効です。
自作ゲームでここまで作り込む必要があるかは、ゲームの複雑さと想定するプレイスタイルによります。短時間で完結するカジュアルゲームなら「最後に保存した端末を正とする」シンプルな方針で十分なことも多いです。
実装前に決めておく三つの質問
設計を始める前に、次の三つに答えを持っておくと、後の判断がぶれにくくなります。
- プレイヤーはログインすることを前提にするか？ ログイン不要のゲームにクラウドセーブを付けようとすると、途中でユーザー識別の仕組みを追加しなければならず、設計が二度手間になります。
- 同期のタイミングはいつか？ セッション終了時に一括保存するのか、チェックポイントごとに保存するのか、変更があるたびにリアルタイムで同期するのかで、通信量と実装の複雑さが大きく変わります。
- データが消えたときの対処をどこまで作るか？ クラウド側の障害やユーザーの誤操作でデータが失われる可能性はゼロではありません。バックアップの世代数・ローカルとの二重持ちなど、どこまで対策するかを決めておくと設計の手が止まりません。
この三つを決めてから実装に入ると、途中で設計を壊して作り直す場面が減ります。ブラウザゲームは後からセーブの仕組みを変えることが技術的には可能ですが、既存プレイヤーの移行処理が必要になるため、できるだけ公開前に固めておくことをおすすめします。
次の行動
まず自分のゲームに「複数端末でのデータ引き継ぎが必要かどうか」を問い直し、必要であれば上記の三つの質問への答えを紙に書き出してみてください。アソバースでSDKを使った共通ログインやクラウドセーブの対応を検討する場合は、公式のSDKドキュメントで現在の仕様と組み込み手順を確認するのが最初のステップです。設計の方針が固まったら、小さなプロトタイプで保存と読み込みだけを先に動かし、複数のブラウザで動作を確かめることで、後の手戻りを大きく減らせます。
参考資料
- MDN Web Docs「Web Storage API」
- Firebase ドキュメント「Cloud Firestore」「Firebase Authentication」
- アソバース 公式SDKドキュメント
