もしゲームの時間が現実と同じ速さで流れたら

待つ時間は「遊び」から「ゲームの外」へ移る

多くの育成ゲームでは、待つ時間は画面の中で進みます。ゲーム内の一日が数分で過ぎ、その間に画面を眺める、少し手を入れる、といった遊びが成立しています。待ちの大半が遊びの時間の内側にあるわけです。

リアルタイムにすると、この配置が逆転します。待ちは遊んでいない時間に押し出され、遊びの時間は「確認と操作」だけに縮みます。ゲームの体験は、次のように変わると考えられます。

• 一回の起動で操作することがほとんどなくなり、数十秒で終わる。
• 「次にいつ開けばよいか」を覚えておく必要が生まれる。
• ゲームの外にいる間にゲームを思い出させる仕組み（通知や、生活の習慣に結びつけた確認）が重要になる。

つまり、リアルタイムの育成ゲームの中身は、画面上のやりとり以上に「思い出す」設計に寄っていきます。苗の72時間が面白くなるかどうかは、その間に何度、どんな理由でゲームを開きたくなるかにかかっています。

ここで確かめたい問いが一つあります。待ちが外に出たとき、ゲームは「遊び」でしょうか、それとも「世話」でしょうか。世話に近づくほど、保護者や学習者の立場から見て、生活リズムとの相性が大事になります。朝晩の決まった時間に開く習慣と合う作りなら続きやすく、不規則に呼び出す作りなら負担になりやすいはずです。

操作の回数が減ると、一回の重みが増す

リアルタイムにすると、決められる回数が大きく減ります。72時間で水やりのチャンスが仮に三回しかないなら、一回の判断はこれまでの何十倍も重くなります。

この場面で、水やりを間違えた苗を考えてみます。加速された時間の中なら、失敗は数分で取り戻せます。リアルタイムの72時間では、やり直しは現実の三日です。失敗の代償が現実の時間で支払われるため、同じ「失敗」でも感じ方がまったく違います。

重くなった判断には、設計上の選択肢がいくつか出てきます。

1. 失敗を許す：一度の間違いでは枯れず、育ちが遅れる程度にとどめる。
2. 失敗を事前に防ぐ：水やりの前に「いま水が必要です」と状態を見せ、迷いを減らす。
3. 失敗を物語にする：枯れた苗が次の苗の肥料になるなど、取り返しのつかなさを次への手がかりにする。

どれを選ぶかで、ゲームの空気は大きく変わります。判断が重い遊びは、うまくいったときの手応えが大きい反面、失敗した人が離れやすくなります。リアルタイムを選ぶなら、失敗したあとにも続けたくなる道を用意しておく必要があります。

もう一つ、見落としやすい点があります。操作の回数が減ると、「何をしていいかわからない時間」も増えます。開いても何も起きない状態が続くと、ゲームは放置されます。操作できない時間には、その間も世界が動いていることが見える工夫、たとえば苗の小さな変化や、次に起きる出来事までの目安の表示が欠かせません。

ゲームを閉じている間の世界をどう計算するか

リアルタイムの設計で技術的にもっとも重要なのは、閉じている間の扱いです。ブラウザのゲームは、画面を閉じれば動きが止まります。そのため、多くの場合は次の考え方を取ります。

• 最後に遊んだ時刻と、そのときの状態を保存しておく。
• 次に開いたとき、現在の時刻との差を計算して、その分だけ世界を進める。

つまり、実際には裏で時間が動いているのではなく、戻ってきたときに「その間の出来事を一気に計算して見せている」わけです。この方式には、考えるべき点がいくつもあります。

端末の時計は書き換えられる

差分は端末の時計に頼るので、利用者が時計を進めれば、待たずに収穫できてしまいます。逆に戻せば、時間が巻き戻ったように見えます。これを防ぐには、サーバーの時刻を基準にする方法があります。ただし外部通信なしで動く単独のHTMLでは、この手が使えません。時計の不正を許容して、遊び手を信頼する設計にするのも、一つの選択です。

長く離れていた人をどう迎えるか

三か月ぶりに開いた人に、枯れた庭を見せるのか、止まった世界を見せるのか。ここは遊び手への態度が現れる部分です。たとえば、進む時間に上限（最大何日分までは進める）を設けておけば、長く離れても取り返しのつく状態で迎えられます。

保存の置き場所

アソバースで公開する作品について、確認済みの範囲で整理します。

• アップロードした作品の中のlocalStorageやsessionStorageは、一時メモリーとして働く互換処理です。長期の保存先としては期待できません。
• アップロード作品にはSDKが自動で追加され、クラウドセーブ（作品ごとにJSONで128KiBまで）が使えます。URLで投稿する作品は、作者がSDKを読み込むと同じ機能が使えます。
• ゲストの履歴や進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。

「最後に遊んだ時刻」と「そのときの状態」は、小さなJSONで表せる内容です。128KiBに収まるかどうかは中身次第なので、作る場合は状態を必要最小限に絞って試算してみてください。ログインしていない遊び手の保存の挙動など、細部は現在の案内で確認してください。

公式作品に見る、時間を手元に置く設計

アソバースの公式作品の中にも、時間の扱いに特徴のあるものがあります。以下は設計から読み取れることです。実際にどう感じるかは、作品を開いて確かめてください。

• 潮だまり：引き潮で浅瀬に海藻や小石を置き、潮を切り替えて観察します。潮の満ち引きを待つのではなく、自分で切り替えて見る作りです。「待つ」ではなく「時間を動かして見比べる」遊びになっていると読み取れます。
• 余白の庭：四季と昼夜があり、時間制限なしで庭を作ります。季節や昼夜という時間の移ろいを、遊び手が見たい形で選べる庭として扱っていると読み取れます。保存があり、以前の庭を引き継げます。
• 時計じかけの台所：時間制限のない見習いと、1皿28秒の本番があります。同じ「時間」を、練習では外し、本番では短く締めています。時間を遊びの強さの調節に使っている例です。
• 紙ひこうき郵便：海辺は36秒、丘は40秒、山は44秒と、一回の遊びを数十秒で完結させています。待ちを遊びの内側に収めた、リアルタイムとは反対側の設計です。

この四つに共通するのは、時間の流れを遊び手の手元に置いていることです。現実の速さに縛られず、遊び手が見たい時間を選べたり、時間そのものを遊びの材料にしたりしています。

この対比を整理すると、時間の置き方には次のような違いがあります。

• リアルタイム、待ちの位置：ゲームの外、一回の操作の重み：重い、閉じている間：差分の計算が必要
• 加速（ゲーム内時間）、待ちの位置：画面の中、一回の操作の重み：中程度、閉じている間：通常は止まる
• 手動で進める、待ちの位置：遊び手の操作、一回の操作の重み：軽い、閉じている間：止まる

リアルタイムが劣っているわけではなく、得意な遊びが違います。生活に溶け込ませたい遊び、毎日少しずつ触れる遊びには向きます。一方、すぐ結果を見たい人や、短い時間で試行錯誤したい人には、手動で進める方式のほうが合います。

自分のゲームで確かめる問い

ここからは、読者が自分で行える問いです。結果はここには書きません。好きな育成ゲームや、作ろうとしているゲームを一つ選んで、次の手順で測ってみてください。

1. 一回の操作時間を書き出す：起動してから閉じるまで、実際に何秒かかるかをストップウォッチで測ります。三回測って平均を取ると、ばらつきがわかります。
2. 待ち時間を書き出す：次に意味のある操作ができるまで、何分、何時間かかるかを調べます。
3. 再訪の回数を数える：一つの成長（苗が実になるまでなど）を終えるのに、何回開く必要があるかを数えます。
4. 比を出す：待ち時間を操作時間で割ります。数字が大きいほど、遊びの大半が「画面の外」にあることを示します。

次に、時間の倍率を仮に変えて、紙の上で並べ直します。たとえば「現実の1時間をゲームの1日として扱う」と決めるだけで、72時間の苗は3時間の苗になります。それでも「三回しか水をやれない」なら、一回の重さは変わりません。倍率を変えても、操作の回数が変わらなければ、遊びの手触りは変わらないからです。

結果を読むときの目安を挙げておきます。

• 比が大きく、再訪の回数が少ない：生活の合間に触れる遊びに向きます。思い出させる仕組みと、失敗の許し方を考えることが課題です。
• 比が小さく、再訪の回数が多い：画面の前で集中して触る遊びに近いです。リアルタイム化すると退屈になりやすいので、別の工夫が要ります。

ありがちな誤りは、時間の倍率だけを変えて、操作の回数を見直さないことです。待ちの長さと判断の回数は、必ずセットで調整してください。もう一つは、再訪の理由を「通知」だけに頼ることです。開く理由が義務だけになると、遊びが世話に変わり、続きにくくなります。

次の行動

好きな育成ゲームを一つ選んで、操作時間と待ち時間を書き出し、比を出してみてください。作る側の方は、最後に遊んだ時刻と状態をJSONで書き出し、128KiBに収まるか見積もるところから始められます。公式作品の潮だまりと余白の庭を開いて、時間を自分で動かせる遊びと、待つ遊びの違いを比べるのもおすすめです。