アソバースSDKでセーブとログインを使う：実装例

SDKが提供する機能の範囲を先に把握する

実装を始める前に、できることとできないことを確認しておくと手戻りが減ります。

アソバースSDKが現時点で提供しているのは、主に次の二つです。

• 共通ログイン：プレイヤーがアソバースにサインインした状態でゲームを開くと、ゲーム側がそのユーザー情報を取得できます。作者がIDとパスワードのフォームを自前で作る必要はありません。
• クラウドセーブ：ゲームの進行状況や設定をアソバースのサーバーに保存・読み込みできます。プレイヤーがデバイスを替えても続きから遊べます。

一方、プレイ履歴（どのゲームを何分プレイしたかなど）はアソバースが自動で記録しますが、ゲーム内部のセーブとは別物です。ゲームのスコアや進行度をクラウドに残したければ、作者側がSDKのセーブAPIを呼ぶ必要があります。また、フレンド機能やゲーム間のリアルタイム通信はSDKの対象外です。

組み込み前に決めておく三つの判断

コードを書く前に、設計として決めておくべき点が三つあります。

ログインを「必須」にするか「任意」にするか

SDKを使っても、ログインしていないプレイヤーがゲームを開くことはあります。ゲストプレイを許すかどうかで分岐処理が変わります。パズルや短いアクションなら「ログインなしでも遊べるが、セーブだけできない」設計が自然です。反対に、進行管理が中心のRPGなどはログインを前提にしても不自然ではありません。SDKは現在のログイン状態をAPIで取得できるので、状態に応じてUIを切り替えることが可能です。

何をセーブするかを最小限に絞る

クラウドセーブに何でも詰め込むと、データ構造が複雑になり、バージョン更新時に壊れやすくなります。「再開に必要な最低限」だけを保存する設計が長持ちします。具体的には「ステージ番号・アイテム所持数・設定フラグ」程度のJSONにとどめ、ログやリプレイデータは含めないのが無難です。

セーブのタイミングをどこに置くか

「ステージクリア時」「メニューを開いた時」「ブラウザのbeforeunloadイベント」など、タイミングは複数考えられます。beforeunloadは保証が弱く（モバイルでは特に発火しないことがあります）、ゲームの節目に明示的に保存する方が確実です。

実装の基本的な流れ

SDKの具体的なAPIシグネチャや認証フローはアソバースの公式ドキュメントで必ず確認してください（バージョンにより変わります）。ここでは、実装の骨格となる考え方を手順として示します。

1. SDKスクリプトを読み込む

HTMLの<head>または<body>末尾にSDKのスクリプトタグを追加します。アソバースが提供するCDNのURLを使うのが基本です。

2. 初期化とログイン状態の取得

ゲームの起動処理の冒頭でSDKを初期化し、現在のユーザー状態を取得します。非同期で返ってくるので、Promiseまたはasync/awaitで受け取ります。ユーザー情報が取得できればログイン済み、nullや未定義であればゲストとして扱います。

// 概念的な構造（実際のAPIは公式ドキュメントで確認）
async function initGame() {
  await AsoSDK.init();
  const user = await AsoSDK.getUser();
  if (user) {
    // ログイン済み → セーブデータを読み込む
    loadSaveData(user.id);
  } else {
    // ゲスト → ローカルのみで動作
    startWithoutSave();
  }
}

3. セーブデータの読み込み

ログイン済みのプレイヤーに対して、クラウドセーブのロードAPIを呼びます。データが存在しない（初回プレイ）ときはデフォルト値で始められるよう、nullチェックを必ず入れます。

4. セーブデータの書き込み

ステージクリアや中断時に保存APIを呼びます。保存するオブジェクトは事前にJSON.stringifyを通すか、SDKがオブジェクトをそのまま受け取るかを仕様で確認してください。保存が失敗したときのエラーハンドリングも忘れずに。プレイヤーへの通知（「保存しました」のトースト表示など）があると親切です。

5. ゲストプレイヤーへの案内

ログインしていない状態でプレイが一定まで進んだタイミングで「アソバースにログインすると続きを保存できます」という案内を出すと、ログインへの動機になります。強制ではなくあくまで案内にとどめると、離脱を防げます。

詰まりやすいポイントと対処

CORSエラーが出る：SDKが正規の投稿URL以外のオリジンからのリクエストをブロックすることがあります。ローカルのfile://環境ではなく、アソバースへ実際に投稿してからテストする必要があります。開発中はアソバースのプレビュー機能を活用してください。

セーブが上書きされない：保存APIを呼んでいるつもりでもPromiseのawaitが抜けていると、非同期処理が完了する前に画面遷移してしまい、書き込みが間に合わないことがあります。保存処理は必ずawaitするか、コールバックの完了を待つ設計にしてください。

データ構造の変更で読み込みが壊れる：ゲームをアップデートした際に保存するオブジェクトの構造を変えると、旧バージョンのセーブデータを読んだときにエラーになります。保存データにバージョン番号を持たせ、読み込み時にマイグレーション処理を挟む習慣をつけると安全です。

ゲストの途中からログインした場合の引き継ぎ：ゲストとしてある程度進行したプレイヤーがその場でログインすると、クラウドのデータ（空）が優先されてゲストの進行が消えることがあります。「ゲストデータを引き継ぎますか？」の選択肢を出すか、ゲスト状態のローカルデータをログイン後のクラウドにコピーする処理を用意しておくと、プレイヤーの不満を防げます。

テストで確認すべき状態の組み合わせ

実装が終わったら、次の状態を一通り手動で試してください。

• 未ログインでゲームを開く、確認すること：ゲストとして動作し、ログイン要求でフリーズしない
• ログイン済みで初回プレイ、確認すること：デフォルト値で正しくゲームが始まる
• ログイン済みでセーブあり、確認すること：前回の状態から正しく再開できる
• セーブ後に別タブで開く、確認すること：同じデータが読み込まれる
• ネットワーク切断中、確認すること：エラーを握りつぶさずプレイヤーに伝わる

次の行動

アソバースSDKの最新のAPIリファレンスと初期化手順は公式ドキュメントで確認してください。まず既存の小さなHTMLゲームにSDKを組み込み、ログイン取得とセーブの読み書きだけを動かすプロトタイプを作ると、全体の感触をつかめます。動作確認はローカルではなくアソバースへ実際にアップロードした環境で行うのが確実です。

参考資料

• アソバース 公式開発者ドキュメント（SDK リファレンス）
• MDN Web Docs — Fetch API、async/await、beforeunload イベント