マガジン

一日一回の遊び:毎日少しだけ遊ぶ設計の条件

遊びをつくる

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

一つのボールと短い足場だけで作られた小さなゲーム模型。
記事のテーマをもとに制作したAI生成イメージ。実際のゲーム画面ではありません。

朝、電車を待つ数分のあいだにブラウザでゲームを開き、1回遊んで閉じる場面を考えてみます。その翌日も同じゲームを開くとしたら、理由は二つに分けられます。「今日は昨日と違うものが待っている」ことと、「昨日はちゃんと終わった」ことです。この記事は、毎日少しだけ遊ばれる設計に必要な条件を、この二つに絞って確かめます。 前者が「日付で変わる要素」、後者が「続けたくなる区切り」です。片方だけでは続きにくくなります。毎日変わっても終わりがなければ、開くたびに負担が増えます。終わりがあっても毎日同じなら、2日目には開く理由が薄れます。 アソバースの公式作品13本の中に、日替わりで中身が変わるものはありません。そのため日付の話は一般的な設計の考え方として扱います。区切りの話は、公式作品の確認済みの仕様から「設計から読み取れること」として説明します。仕様の細部や画面の様子は、作品を開いて確かめてください。

この記事の目次
  1. 一日一回の設計を二つの部品に分ける
  2. 日付で変わるものは一つに絞る
  3. 続けたくなる区切りは公式作品の「短い単位」に見える
  4. 記録をどこに置くかで「続き」の意味が変わる
  5. 作る前に確かめる手順
  6. 次の行動

一日一回の設計を二つの部品に分ける

「毎日遊ばれるゲーム」を一つの工夫のように考えると、何を作ればよいか見えなくなります。部品に分けると次のようになります。

  • 今日の中身:日付によって変わる問題、配置、お題、制約です。
  • 今日の終わり:1回分が終わったと分かる区切りです。結果の表示や、次に何をするかの案内も含みます。
  • 昨日からの続き:最後に遊んだ日、続けた日数、これまでの記録です。保存の仕組みが必要になります。

多くの人が最初に考えるのは三つ目の連続日数ですが、先に決めるべきなのは前の二つです。連続日数は、1回の遊びに「また明日」と思える理由があって初めて意味を持ちます。理由がないまま連続日数だけを増やすと、続けることが義務のように見えてしまいます。

日付で変わるものは一つに絞る

変えるもの、変えないもの

日替わりにしてよいのは、遊ぶたびに内容を読み直しても負担にならない部分です。操作とルールは毎日同じにして、変えるのは盤面の配置、材料の組み合わせ、風の向きといった「問題の中身」だけにします。操作やルールまで変わると、毎日が新しい説明書を読む日になり、1日数分という軽さが失われます。

変えるものを一つに絞ると、プレイヤーは「今日は何が違うのか」を一目で言い当てられます。複数の要素が毎日変わると、違いが印象に残りにくくなります。

日付を種にする方法

サーバーを使わずに日替わりを作る代表的な方法が、日付から乱数の種を作るやり方です。仕組みは次のとおりです。

  1. 今日の日付を「2026-10-22」のような文字列にします。
  2. その文字列から一つの整数を計算します。文字コードを足し合わせるなどの簡単な方法で足ります。
  3. その整数を乱数の種にして、配置や順番を決めます。

種が同じなら乱数の並びも同じになります。そのため、同じ日に開けば誰でも同じ問題になり、通信も保存も要りません。公式作品は独立したHTMLで外部通信なしに動く、という確認済みの構成とも相性のよい方法です。

落とし穴

日付シードには、事前に決めておくべき点がいくつかあります。

  • 日が変わる基準:端末のローカル日付なら、日本では深夜0時に切り替わります。UTC基準にすると、日本では午前9時の切り替わりになります。日本の利用者が中心なら、日本時間で固定する選択もあります。どれを選んでも、遊んでいる人に見える形で説明しておくと混乱を避けられます。
  • 端末の時計:端末の日付は利用者が変更できます。共通のスコアランキングがない環境では、時計の変更を厳しく防ぐ必要は小さいかもしれません。守りたいのは公平さなのか、連続日数の意味なのかを先に決めておくと、対策の重さを判断できます。
  • 難易度のばらつき:乱数で盤面を作ると、解けない日や簡単すぎる日が出ることがあります。これを避けるには、作者があらかじめ作った問題を複数用意し、日付から番号を計算して選ぶ方法があります。基準日からの経過日数を候補数で割った余りを使えば、同じ問題を決まった周期で巡らせられます。解の存在を作者が確認済みの問題だけを並べられる点が利点です。
  • 過去の日の扱い:昨日の問題をあとから遊べるようにするかどうかも、事前に決めます。遊べると取り戻しやすくなりますが、「今日だけ」という感覚は薄れます。

アソバースには、ゲーム内スコアの共通ランキングはありません。同じ日の問題を全員で競う形は、現在の案内の範囲ではプラットフォームの機能として用意されていません。作品内で「今日の問題」を共有しても、比べる場は作品の外に求めることになります。比べることを楽しみの中心に置くかどうかは、設計の段階で考えておくとよいところです。

続けたくなる区切りは公式作品の「短い単位」に見える

区切りは、1回分の長さと終わり方で決まります。公式作品の確認済みの仕様を、その観点で並べてみます。日替わりの作品ではない点に注意してください。ここで見るのは「1回がどれくらいの単位でできているか」です。

  • 紙ひこうき郵便、確認済みの単位:海辺36秒・丘40秒・山44秒で、最後の6秒で郵便受けへ、区切りとして読み取れること:1回が1分に満たず、終わりの時刻が決まっています
  • 時計じかけの台所、確認済みの単位:1皿28秒、6つのレシピ、料理ごとに100点評価、区切りとして読み取れること:1皿ごとに終わりと評価があります
  • 月夜の配達、確認済みの単位:3つの夜、各夜の最少区間数の記録、区切りとして読み取れること:1夜ごとに閉じたパズルになっています
  • こだまの森、確認済みの単位:6・8・10ラウンドの3コース、区切りとして読み取れること:遊ぶ長さを選べます
  • かたちのあいだ、確認済みの単位:同じ配置の再挑戦、保存あり、区切りとして読み取れること:同じ条件でやり直せます
  • 余白の庭、確認済みの単位:時間制限なし、最大80個、保存あり、区切りとして読み取れること:終わりを自分で決める型です

ここから読み取れる区切りの条件は三つあります。

  1. 終わりの時点が先に分かる:秒数、ラウンド数、夜の数など、1回の長さがあらかじめ決まっています。何分かかるか見えているゲームは、開く前の心理的な負担が小さくなります。
  2. 終わりに評価か記録がある:料理ごとの100点評価や最少区間数のように、終わった時点で一つの結果が出ます。結果があると、1回分が終わったと感じやすくなります。
  3. 同じ条件でやり直せる、または長さを選べる:「もう一回」と「今日はここまで」の両方を、プレイヤーが選べます。

一日一回の設計にするときは、これらの条件を日替わりと組み合わせます。たとえば、1回を30秒前後にして今日の問題を一つだけ出し、終わりに評価を見せます。そのうえで同じ条件での再挑戦を許すか、明日まで待たせるかを決めます。強制的に待たせるより、「今日の分は終わりました」と示しつつ遊び直しは妨げない形のほうが、はじめて開いた人を締め出さずに済みます。

どの公式作品がどんな画面で終わりを知らせるかは、本稿では書きません。作品を開いて、結果が出る瞬間と次の操作の案内を確かめてください。

記録をどこに置くかで「続き」の意味が変わる

連続日数や最後に遊んだ日を残すには、保存が必要です。ここで、確認済みの事実を整理しておきます。

  • 公式作品のうち、保存があるのは余白の庭・WAVE / WAVE・かたちのあいだの3作品です。他の10作品の記録は画面を開いている間だけ残ります。
  • アップロード作品内のlocalStorage/sessionStorageは、一時メモリーの互換処理です。永続的な保存先としては当てにできません。
  • ログイン中は、作品ごとにJSONで128KiBまでのクラウドセーブが使えます。アップロードしたゲームにはSDKが自動で追加され、URL投稿のゲームは作者がSDKを読み込むと使えます。
  • ゲストの履歴や進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。
  • 未同期の端末セーブは、クラウドの古いデータより優先して再送されます。

SDKの具体的な呼び出し方は、この記事では扱いません。投稿画面や現在の案内で確認してください。

連続日数に必要なデータは、最終プレイ日、連続日数、今日のクリア状況ほどで、128KiBに対して非常に小さくて済みます。大きな制約になるのは容量よりも、ログインが前提になることです。ゲストで遊び続けた記録がログイン後に自動で合流しないため、連続日数が途中で切れたように見える場面が出ます。この点は、作品の説明文や画面に一言添えておくと親切です。

もう一つ決めておきたいのは、連続が途切れたときの扱いです。途切れた瞬間に積み上げた成果をすべて失う設計は、休んだ翌日に開く気持ちを削ぎます。連続日数は「今回の連続」と「これまでの最長」を分けて見せるなど、失うものを小さくしておくと、数日空いた人も戻りやすくなります。

なお、アップロード作品ではサービスワーカーが対象外です。ブラウザの通知は一般にサービスワーカーを使うため、作品側から通知で呼び戻す設計は前提にしにくいと考えられます。その代わり、終わりの画面で「明日はこの問題が変わります」のように次回の予告を見せる、といった作品内で完結する工夫が中心になります。

作る前に確かめる手順

次の手順で、自分の企画を点検できます。

  1. 公式作品を一つ選び、1回が終わるまでの長さを自分の感覚で測ります。30秒前後に収まるものと、数分かかるものを比べると、自分の企画の目安が決まります。
  2. 毎日変わるものを一つに絞って書き出します。操作とルールが変わらないことも、あわせて確認します。
  3. 日が変わる基準を、ローカル日付・UTC・日本時間のどれにするか決めます。
  4. 問題を乱数で作るか、手作りの候補から選ぶかを決めます。手作りの場合は、全候補を自分で解いて確かめます。
  5. 開発中に端末の日付を前後に動かし、日をまたいだ動作を確認します。切り替わる時刻の前後、月末や年末も試します。
  6. 終わりの画面に載せる内容を決めます。今日の結果、連続日数、明日の予告のうち、何を出すかを選びます。
  7. 記録の保存先を決めます。ログイン時のクラウドセーブを使う場合は、ゲストの記録の扱いを説明文にも書きます。

プレイ回数は作品の起動の実測回数で、同じ端末・作品の30分以内の再起動は重複を除いて数えられます。人数ではないため、「毎日遊ばれているか」を直接示す数字としては読めません。日別の利用状況を見られるかは、現在の案内で確認してください。

次の行動

まず公式作品を一つ開き、1回が終わるまでの長さと、終わったと分かる瞬間を確かめてください。そのうえで、自分の企画で毎日変えるものを一つだけ書き出し、手順の3〜4を決めるところから始めます。作品をアソバースに投稿する場合は、下書き保存を使いながら、日をまたぐ動作の確認まで進めてください。