マガジン

プレイ回数の集計はどこに書かれるか:gameStatsの仕組み

遊びを見つける

執筆にClaudeを使用しています。

プレイヤーの駒と小さなゲームの世界をつなぐ橋、上に浮かぶ雲形の器
記事のテーマをもとに制作したAI生成イラスト。

ランキングの画面で、ある作品のプレイ回数が「10」と表示されている場面を考えてみます。この数字を見て「10人が遊んだ」と読むと、少しずれます。アソバースのプレイ回数は作品を起動した実測回数であり、人数ではないと案内されています。同じ人が3回起動すれば、数字は3つ進む可能性があります。 もう一つ気になるのは、その数字がどこに書かれているかです。作品の中のコードが自分で数えて送っているのか、サイト側が起動を見て数えているのか。この記事では、題名にある「gameStats」を、作品ごとの集計が置かれる場所を指す名前として扱います。ただし、その保存場所の構造や項目名は、確認済みの案内に含まれていません。そこで記事の中心には、「作品のコードが集計を書き込む設計にはなっていないと読み取れる理由」を置きます。内部の構造は創作せず、確認できることから導ける範囲に絞ります。最後に、読者が自分で確かめる手順も示します。

この記事の目次
  1. 確認できていることと、まだ言えないこと
  2. 作品のコードには、書き込むための材料が渡されない
  3. 30分ルールが示す、数え方の性格
  4. ほかの数字と並べると、プレイ回数の位置が見える
  5. 自分で確かめる手順
  6. 作品内の自作カウンタは、サイトの集計とは別物
  7. 数字を読むときの注意
  8. 次の行動

確認できていることと、まだ言えないこと

最初に、根拠にする事実と、言い切れない部分を分けておきます。

  • プレイ回数は作品起動の実測回数、状況:案内で確認済み
  • 同じ端末・作品の30分以内の再起動は重複を除く、状況:案内で確認済み
  • プレイ回数は人数ではない、状況:案内で確認済み
  • ランキングはプレイ回数・いいね数・レビュー平均で切り替え、ジャンル絞り込み、上位50作品、状況:案内で確認済み
  • ゲームはsandbox付きiframeで実行、アップロードコードは別オリジンから配信、状況:案内で確認済み
  • ゲームにFirebaseのUID・認証トークン・メールアドレスを渡さない、状況:案内で確認済み
  • 集計の保存場所の名前・項目・更新の具体的な手順、状況:確認済み事項になし。現在の案内で確認する
  • 30分の判定を端末のどこで覚えているか、状況:確認済み事項になし
  • 別の端末から起動した場合の扱い、状況:確認済み事項になし

下の3行は「分からない」のではなく、「この記事では述べない」という意味です。以降は、上の確認済みの行だけを材料にします。

作品のコードには、書き込むための材料が渡されない

集計の置き場所を考えるうえで、手がかりになるのは「作品の中にある側」が何を持っているかです。

アソバースでは、投稿された作品はsandbox付きのiframeで動きます。iframeは、ページの中に別のページをはめ込む仕組みです。sandboxは、その中身にできることを制限する指定です。さらに、アップロードされたコードはメインサイトとは別のオリジン(サイトの住所にあたる単位)から配信されます。作品のコードは、サイト本体と同じ権限では動いていません。

加えて、ゲームにはFirebaseのUID、認証トークン、メールアドレスを渡さないと案内されています。認証トークンは、「このアカウントとして操作してよい」という証明書のようなものです。作品のコードがこれを持たないなら、サイトの集計に対して「私はこの人です」と名乗って書き込む手段を、作品側は持っていないことになります。

作品に渡される側のものは、SDKを通した作品専用のプレイヤーIDと、作品ごとにJSONで128KiBまでのクラウドセーブです。つまり作品側が自分のものとして扱えるのは、作品専用のIDと、作品専用のセーブ領域です。サイト全体のランキングに効く数字は、この中に含まれていません。

ここから設計から読み取れることを整理すると、次のようになります。

  • 作品のコードは、プレイ回数のようなサイト共通の集計に、自分の判断で書き込む経路を持たない設計だと読み取れます。
  • 起動の計測は、作品の外側(サイト側)で行われる設計だと考えるのが自然です。ただし「どこで」「どのように」は確認済みではありません。

「サーバーだけが書ける」と言い切れる材料までは、案内にありません。それでも、作品側に権限の材料を渡さない方針と整合する、という読み方は成り立ちます。

なぜ作品側に書かせないのか

ここからは理由の推測になります。ランキングの順位に使われる数字を、作品自身が書き込めるとします。作る人が意図しなくても、コードの不具合で数字が膨らむ可能性があります。意図して膨らませる人が出ることも考えられます。起動の数え方を作品の外に置けば、作品のコードの出来に関係なく、同じ基準で数えられます。

この考え方は、オンライン対戦にも見られます。「潮目のオセロ」と「灯りのチェス」では、手番・合法手・勝敗をサーバーで確認すると案内されています。画面の側が「勝った」と申告するのではなく、確認する側が別にいる、という構図です。プレイ回数の仕組みが同じ理由で作られたと断定はできませんが、同じ方向の設計として並べて見ることはできます。

30分ルールが示す、数え方の性格

プレイ回数について確認済みなのは、「作品起動の実測回数」であり、「同じ端末・作品の30分以内の再起動は重複を除く」という点です。この短い説明から、読み取れることがいくつかあります。

  1. 起動単位で数えている。 遊んだ時間の長さや、ステージをいくつ進めたかではありません。ゲームの中で5分遊んでも1時間遊んでも、起動が1回なら同じ扱いと読み取れます。
  2. 短時間の連続起動をならす仕組みがある。 誤ってページを再読み込みしたり、作品を開き直したりしても、30分以内なら重複として除かれます。
  3. 単位は「端末×作品」。 同じ端末で別の作品を起動すれば、それぞれ別に数えられると読み取れます。

一方で、確認済みでないことも明確にしておきます。30分の経過をどこに記憶して判定しているのか、別の端末から開いた場合や、ログイン状態の違いで扱いが変わるのかは、案内にありません。ここを推測で埋めないことが大切です。

また、ログインせずに遊べること、ゲストの履歴や進行は端末内に保存されログイン後のアカウントへ自動では混ざらないことも、案内されています。これは履歴やセーブの話で、プレイ回数の判定が同じ材料を使っているかどうかは、案内からは分かりません。

ほかの数字と並べると、プレイ回数の位置が見える

ランキングは、プレイ回数・いいね数・レビュー平均の3つで切り替えられます。この3つを、「何を単位にしているか」で並べてみます。

  • いいね:1アカウントにつき1件。「好きな作品」と連動します。
  • レビュー:1アカウント1作品1件。1〜5点で、本人が編集・削除でき、自作の評価はできません。評価順はレビュー3件以上から掲載されます。
  • プレイ回数:作品起動の実測回数。30分以内の同端末・同作品の再起動は除かれます。

いいねとレビューは、アカウントという単位で重複を抑えています。プレイ回数はアカウントではなく、起動という出来事を数えています。ログインしなくても遊べるので、アカウントを数の単位にできない場面があるためだと想像できますが、これは理由の推測にすぎません。確かなのは、3つの数字は単位が違うので、同じものさしで比べられないという点です。

なお、「ゲーム内スコアの共通ランキング」は未提供です。作品の中で出るスコアや最高記録は、多くの公式作品で画面を開いている間だけ残るものです。保存があるのは「余白の庭」「WAVE / WAVE」「かたちのあいだ」の3作品だけです。サイトのプレイ回数と、作品内のスコアは別の種類の数字です。

自分で確かめる手順

ここからは、読者が自分で行える確かめ方です。結果はここには書きません。画面に出た数字が答えになります。

問い

「同じ端末で同じ作品を30分以内に開き直したとき、プレイ回数の表示は進むか。30分以上あけたときはどうか。」

準備するもの

  • 自分が公開した作品、または公式作品のうち1本(投稿者でなくてもプレイ回数の表示を見られる画面があれば足ります)
  • 時刻を記録できるメモ(紙でも表計算でも構いません)
  • 同じ端末と同じブラウザ

手順

  1. 対象の作品のプレイ回数を、起動する前にメモします。
  2. 作品を起動し、その時刻を記録します。
  3. 作品を閉じて、すぐに開き直します(30分以内)。プレイ回数を見て、数字を記録します。
  4. 30分以上あけてから、もう一度起動します。数字を記録します。
  5. 別の作品を1本起動し、元の作品の数字が動いたかを記録します。

記録は、「起動前の数字」「起動時刻」「起動後の数字」の3列で足ります。各条件につき最低でも2回は繰り返すと、偶然や反映の遅れによるずれに気づきやすくなります。

結果の読み方

  • 30分以内の再起動で数字が増えていなければ、案内の「重複を除く」と一致します。増えていたら、条件を見直します(端末やブラウザが変わっていないか、時刻の記録が正しいか)。
  • 数字の反映に時間がかかる可能性があります。画面を読み込み直す、少し待つ、といった条件を変えて、記録に残します。
  • 他の人も同じ作品を遊んでいると、自分の操作と関係なく数字が進みます。人気の高い作品ほど、この影響が混ざります。起動の前後で連続して見るほど、影響を減らせます。

起こりやすい誤り

  • ブラウザやシークレットモードを変えてしまう。 「同じ端末」の判定が何に基づくか分からないため、条件を揃えます。
  • 時計を見ずに感覚で30分と判断する。 必ず時刻を記録します。
  • 1回の結果で結論を出す。 他のプレイヤーの起動が混ざるので、繰り返して見ます。

作品内の自作カウンタは、サイトの集計とは別物

作る人が「起動回数を自分で数えたい」と考える場面もあります。次の最小コードは、作品内で起動回数を数えようとする例です。

html
<!doctype html>
<meta charset="utf-8">
<p id="c"></p>
<script>
let n = 0;
try {
  n = Number(localStorage.getItem("launch") || 0);
  n += 1;
  localStorage.setItem("launch", n);
} catch (e) {
  n = "保存できません";
}
document.getElementById("c").textContent = "この作品内の起動回数: " + n;
</script>

アップロード作品内のlocalStorageやsessionStorageは、一時メモリーの互換処理だと案内されています。このコードの数字が、ブラウザを閉じたあとも残るかどうかは、作品を公開して自分で開き直して確かめます。仮に残ったとしても、サイトのプレイ回数とは関係のない、その作品だけの数字です。作品が自分の数字を書いても、ランキングのプレイ回数は動きません。

作品をまたいで残したい進行は、SDKを通したクラウドセーブ(作品ごとにJSONで128KiBまで)を使う設計が用意されています。投稿方法がURLの作品では、作者がSDKを読み込んだ場合に使えます。具体的な呼び出し方は、現在の案内で確認します。

数字を読むときの注意

最後に、プレイ回数を読むときの注意を3つにまとめます。

  • 人数として読まない。 起動の回数です。同じ人の繰り返しが含まれます。
  • 遊び込みの深さとして読まない。 起動単位なので、すぐ閉じた起動も数えられる可能性があります。
  • 他の作品との比較は、公開期間や紹介のされ方も考える。 数字の差は、作品の質だけから生まれるわけではありません。

作る人にとっては、プレイ回数といいね、レビューを並べて見ることで、「開かれたが、気に入られたか」の差が見えやすくなります。

次の行動

自分の公開作品か気になる作品で、上の手順の「30分以内の再起動」を2回確かめてみてください。結果をメモに残すと、プレイ回数が何を数えているかが手元で分かります。集計の保存場所の名前や項目など、この記事で「確認済みでない」とした点は、現在のアソバースの案内で確認してください。