HTMLアップロードとURL投稿：同じゲームを両方で出すと何が違うか

比べる前に決める三つの問い

比較は、問いが曖昧だと「なんとなく違った」で終わります。次の三つに分けると、記録の欄が決まります。

1. 配信元の問い：ゲームは誰のどのアドレスから届いているか。画面内のコードから見える「自分の居場所」（location.origin）は二つの版で同じか。
2. 保存の問い：数字を増やして再読み込みしたとき、値は残るか。残るなら、閉じて開き直しても、別のブラウザでも残るか。
3. ログインの問い：ゲストで遊んだ場合とログインして遊んだ場合で、進行や履歴の扱いに差が出るか。

三つとも、答えが「同じ」でも「違う」でも収穫になります。同じなら安心して入口を選べますし、違うなら、自分のゲームに必要な方を選ぶ根拠になります。

同じゲームを用意する

比較のために作るのは、押すと数字が増えるだけのゲームです。保存の可否と配信元だけを画面に出します。コードは外部ライブラリを使わず、1ファイルで動きます。

<!doctype html>
<html lang="ja">
<meta charset="utf-8">
<title>保存テスト</title>
<button id="b">押す</button>
<p id="o"></p>
<script>
const KEY = "save-test";
const started = new Date().toLocaleTimeString();
let n = 0, note = "";
try { n = Number(localStorage.getItem(KEY)) || 0; }
catch (e) { note = "読込失敗:" + e.name; }
function show() {
  o.textContent = "回数 " + n + " / 起動 " + started +
    " / origin " + location.origin + " / " + note;
}
b.onclick = () => {
  n++;
  try { localStorage.setItem(KEY, n); note = "書込OK"; }
  catch (e) { note = "書込失敗:" + e.name; }
  show();
};
show();
</script>
</html>

このファイルを index.html という名前で保存します。ポイントは三つあります。

• try/catchで包んでいます。 実行環境によっては、保存領域へのアクセスが例外になることがあります。例外を画面に出せば、「保存できなかった」ことが観察できます。
• 起動時刻を表示しています。 再読み込みで数字が戻ったのか、残ったのかを、起動時刻の更新と合わせて読み取るためです。
• 「書込OK」は書き込み命令が通っただけの意味です。 再読み込み後に値が残ることまで保証するものではありません。残るかどうかは、後の手順で別に確認します。

URL版を出すには、このファイルを自分で公開できる場所に置き、そのアドレスを用意する必要があります。公開場所は何でもかまいません。ただし二つの版は同じファイルから作り、中身を一文字も変えないでください。ここが崩れると、違いの原因が入口なのかコードなのか分からなくなります。

入口の違いを表にして、確かめる欄を作る

先に、アソバースの案内で確認できる違いを表にします。空欄は「作品を開くか、現在の案内で確認する」欄です。

• 入口、HTML・ZIPアップロード：直下の index.html、公開済みURL：作者が公開したURL
• 素材の指定、HTML・ZIPアップロード：相対パス、公開済みURL：現在の案内で確認する
• 規模の上限、HTML・ZIPアップロード：1回20MiB以内。ZIP展開後は合計100MiB・1,000ファイル以内、1ファイル30MiB以内、公開済みURL：現在の案内で確認する
• 対象外の仕組み、HTML・ZIPアップロード：サーバー用コード、サービスワーカー、SharedArrayBufferを使うマルチスレッド、公開済みURL：現在の案内で確認する
• 投稿回数の枠、HTML・ZIPアップロード：1人UTC1日10回。アカウントごとに100アップロード・1GiBまで、公開済みURL：アップロード側の枠です。URL側は現在の案内で確認する
• SDK、HTML・ZIPアップロード：自動で追加される、公開済みURL：作者が読み込むと使える
• クラウドセーブ、HTML・ZIPアップロード：SDK経由で作品ごとにJSON 128KiBまで、公開済みURL：SDKを読み込んだ場合に使える。同じく128KiBまで
• localStorage／sessionStorage、HTML・ZIPアップロード：一時メモリーの互換処理、公開済みURL：作品を開いて確かめる
• 紹介文と遊び方の下書き作成、HTML・ZIPアップロード：本人の検証済みアップロードを読み取る、公開済みURL：公開済みURLを読み取る
• 実行、HTML・ZIPアップロード：sandbox付きiframe、公開済みURL：sandbox付きiframe
• 配信元、HTML・ZIPアップロード：メインサイトとは別のオリジン、公開済みURL：作品を開いて確かめる

アップロードしたゲームは、メインサイトと別のオリジンから配信されます。さらにsandbox付きのiframeで動きます。URL版でこの条件がどうなるかは、案内にない部分を推測せず、実験で表示される origin の値を記録して確かめます。

SDKについても注意があります。クラウドセーブは作品専用のプレイヤーIDで管理されます。ゲーム側へFirebaseのUID、認証トークン、メールアドレスを渡すことはありません。URL版でSDKを使う場合も、これらを自作コードで扱おうとしないでください。SDKの具体的な読み込み方は、投稿画面や現在の案内で確認します。

実験の手順と記録の取り方

準備

• 同じ index.html から、アップロード版とURL版を一つずつ用意します。
• 投稿は「入力→表示の確認→公開」の3段階です。公開にはメールアドレスの確認が必要です。まず下書き保存で進め、表示の確認までを比べるのが無駄の少ない進め方です。
• 公開する場合は、題名に「テスト」と分かる語を入れます。終わったら非公開化または削除で片づけます。
• 自作の作品は自分で評価できません。レビューやいいねは、比較の観点から外します。

実験A：配信元を見る

1. アップロード版を開き、画面に出る origin の文字列を書き写します。
2. URL版でも同じことをします。
3. 二つの値が同じか、アドレスの形が違うか、値が空に近い表記になるかを記録します。

sandbox付きの環境では、origin が意図した形で出ないことがありえます。出ない場合も、そのまま「出なかった」と記録してください。

実験B：保存が残る範囲を見る

各版で、次の条件を順にたどります。数字は毎回3回押して、3から始めます。

1. ゲストの状態で初回起動し、3回押します。
2. ページを再読み込みして、数字と起動時刻を見ます。
3. タブを閉じて開き直し、数字を見ます。
4. 別のブラウザで開き、数字を見ます。
5. 一時停止などの機能は使わず、画面を開いたまま数分置いてから数字を見ます。

記録は次のような表にします。各条件は、まず1回行います。結果が揺れたら、同じ条件を3回まで繰り返します。

• 初回起動後に3回押す、アップロード版の数字：、URL版の数字：、画面の注記：
• 再読み込み、アップロード版の数字：、URL版の数字：、画面の注記：
• 閉じて開き直し、アップロード版の数字：、URL版の数字：、画面の注記：
• 別ブラウザ、アップロード版の数字：、URL版の数字：、画面の注記：

「画面の注記」欄には、「書込OK」「書込失敗:○○」など表示された文字をそのまま書きます。

実験C：ログインの有無で差を見る

1. ゲストで3回押した状態から、ログインします。ログインはGoogleまたはメールアドレスです。
2. 同じ作品を開き直し、数字を見ます。
3. ログアウトして、ゲストの画面に戻ったときの数字も見ます。

確認済みの案内では、ゲストの履歴や進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。この記述と、実験で見た数字が一致するかどうかが読みどころです。

クラウドセーブは、この最小ゲームでは試せません。SDKを使う実装が必要になるためです。進行をアカウントに結びつけたい場合は、別の実験として、作品専用のプレイヤーIDとクラウドセーブの使い方を現在の案内で確認し、128KiB以内のJSONで保存する小さなコードを足します。端末に未同期のセーブがある場合は、クラウドの古いデータより優先して再送される、という仕様があります。ここは、手元の挙動と案内の記述を突き合わせてください。

結果の読み方と起こりやすい誤り

結果は、次のように読みます。

• 両方で数字が再読み込み後に残らない場合：localStorage を保存先として当てにせず、残したい進行はクラウドセーブ側で設計する必要があります。アップロード作品内の localStorage は一時メモリーの互換処理です。この案内と一致するかを確かめてください。
• 片方だけ残る場合：入口によって保存の扱いが違う可能性があります。どちらがどうなったかをそのまま記録し、作品説明に反映するかを決めます。
• 書込失敗が出る場合：その入口では、保存領域がそのままでは使えない可能性があります。コードを疑う前に、同じ失敗が両方で出るかを見ます。
• origin が二つで違う場合：配信元が違うということです。外部のAPIで許可するアドレスを設定しているなら、入口ごとに設定が必要になるかもしれません。

起こりやすい誤りも挙げておきます。

• 二つの版でコードを変えてしまう。 比較ではファイルを共有し、差し替えのたびに両方を更新します。
• プレイ回数の増え方を人数と読む。 プレイ回数は作品起動の実測回数で、人数ではありません。同じ端末・作品で30分以内に再起動した場合は重複が除かれます。テストで何度も開いても、数が増えないことがあります。
• ランキングやスコアの共通機能を期待する。 ゲーム内スコアの共通ランキングは未提供です。ランキングはプレイ回数・いいね数・レビュー平均が対象で、評価順はレビュー3件以上からの掲載です。
• 共通の対戦機能を期待する。 オンライン対戦は公式作品の「潮目のオセロ」と「灯りのチェス」だけです。投稿作品向けの共通対戦APIは未提供です。投稿時の「遊び方・最大参加人数」は作者の申告で、共通対戦を有効にするものではありません。
• テスト作品を残す。 非公開化と削除が使えます。アップロード枠（1日10回など）を消費するため、実験は回数を決めて行います。

次の行動

まず、上の最小コードを index.html として保存し、アップロード版を下書きまで進めてください。同じファイルをURLで公開できる場所に置けるなら、URL版も同じ条件で下書きにし、実験Aの origin を二つ書き写します。次に、保存の表を埋めて、ゲストとログインの差を一行ずつ記録します。SDKやクラウドセーブを試すかどうかは、その表を見てから決めてください。