育成シミュレーションの作り方：パラメータと時間経過
遊びをつくる執筆にClaudeを使用しています。
育成シミュレーションは「数値が育つ手応え」と「時間をかけた変化」の二つが組み合わさることで成立します。プレイヤーが画面を閉じても「あのキャラは今どうなっているだろう」と戻ってくるのは、時間経過がゲーム内に織り込まれているからです。 しかし「パラメータを増やす」「時間で何かが変わる」という方向性は決まっても、どう設計すればゲームとして機能するのかは意外と整理されていません。数値が多すぎてプレイヤーが何を見ればいいか分からなくなる、時間経過を入れたら途中でやめる理由がなくなった、という問題は育成ゲームの典型的な詰まりどころです。 この記事では、パラメータの種類と数の決め方、時間経過をゲームに組み込む具体的な方法、そして失敗しやすい設計パターンとその回避策を順に説明します。作り始める前の設計段階に使えることを意識して書いています。
パラメータを設計する前に「軸」を一本決める
育成シミュレーションのパラメータには大きく二種類あります。プレイヤーが直接操作できる入力パラメータ（食事を与える、練習させる、アイテムを使うなど）と、その結果として変化する状態パラメータ（体力、技術値、幸福度など）です。
設計を始める前に、まず「この育成ゲームで最終的に何が育つのか」という軸を一本だけ明確にしてください。たとえば「強さ」「評判」「スキルの熟練度」「キャラクターとの親密度」など、ゲームの目的と直結する数値が軸になります。
軸が決まったら、その軸に影響を与えるパラメータを二〜三個だけ選びます。たとえば「強さ」を軸にするなら「体力」「練習量」「メンタル」の三つで十分です。ここで「センス」「運」「経験値」「才能」などを次々と追加したくなりますが、パラメータを増やすほど「何をすれば強くなるのか」がプレイヤーに伝わりにくくなります。
パラメータ数の目安
- 短時間完結（30分以内）、軸となるパラメータ：1本、サブパラメータ：0〜2個
- 中規模（数時間）、軸となるパラメータ：1〜2本、サブパラメータ：2〜4個
- 長期型（繰り返しプレイあり）、軸となるパラメータ：2〜3本、サブパラメータ：4〜6個
サブパラメータを増やす場合も、それぞれが「プレイヤーの意思決定に影響するか」を判断基準にしてください。表示しているだけで結果に影響しない数値は、あっても混乱の原因になるだけです。
数値の変化に「実感」を持たせる設計
パラメータに数値を割り当てたとき、変化の幅が小さすぎると手応えがなく、大きすぎると序盤で上限に達してしまいます。実感を持たせるために考えるべきことは三点です。
最大値と増分の比率を合わせる。最大値を100にするなら、一回の操作で増える量は1〜5程度が目安です。100回の操作で満タンになる設計は粗すぎ、10回で満タンになる設計は物足りなさを生みます。最大値を1000にして増分を10にするのは数字が大きくなるだけで体験は変わらないため、見た目の数字の大きさではなく比率を意識してください。
変化に非線形性を持たせる。パラメータが増えるほど次の増加が難しくなる「逓減カーブ」は、プレイヤーが長く遊ぶほど「あと少し」を感じやすくする手法です。JavaScriptで実装するなら、増分に Math.sqrt(currentValue) の逆数をかけるだけでも単純な逓減を表現できます。逆に、ある閾値を超えると加速する「爆発的成長」は、長い停滞の後のカタルシスとして有効です。どちらかを一つ意図的に選ぶだけで、育成の「読み応え」が変わります。
マイナス方向の変化を組み込む。値が上がるだけの育成は、操作を止める理由がなくなります。「食事を与えなければ体力が下がる」「練習しすぎるとメンタルが減る」といったマイナス方向の変化があることで、プレイヤーは選択を迫られます。マイナス変化の速度は、プレイヤーが対応できる範囲に収めることが重要です。リアルタイムで急速に下がる設計は、ゲームを離れることへの罰則になり体験を悪化させます。
時間経過をゲームに組み込む三つのパターン
育成シミュレーションにおける「時間」の扱い方は、大きく三つのパターンに分かれます。それぞれ用途が異なるため、ゲームの目的に合わせて選んでください。
パターン1：ターン制
プレイヤーが「朝・昼・夜」「月曜〜日曜」などのターンを進めることで時間が経過します。一回のプレイセッションがいつ終わってもゲームが止まるため、ブラウザゲームに向いています。実装の難易度が最も低く、パラメータの変化タイミングもターンごとに計算するだけで済みます。デメリットは、プレイヤーがターンを連打すれば一瞬でゲームが終わってしまう点です。これを避けるには、一ターンに実行できる行動数を制限する「行動ポイント制」を組み合わせるのが一般的です。
パターン2：リアルタイム経過（セッション内）
ゲームを開いている間だけ時間が進むパターンです。setInterval で定期的にパラメータを更新し、画面を閉じれば時間が止まります。時間プレッシャーを演出しやすい反面、長時間画面を見続けることが前提になります。短時間完結のゲームか、クリックゲーム的な操作が中心のゲームに向いています。
パターン3：オフライン経過
ゲームを閉じている間も時間が経過する設計です。起動時に「前回ログイン時刻」と「現在時刻」の差を計算し、その分だけパラメータを変化させます。localStorage に前回の起動時刻を保存するだけで基本的な実装は可能です。「戻ってきたら変わっていた」という体験がプレイヤーの再訪を促しますが、オフライン中の時間が長すぎるとパラメータが取り返しのつかない状態になるリスクがあります。オフライン経過には上限時間を設けるのが無難です。たとえば「最大8時間分まで計算する」という処理を加えれば、数日放置されても破綻しません。
失敗しやすい設計パターンと回避策
育成シミュレーションを作るときに繰り返し起きる問題を四つ挙げます。
「全部上げればいい」になる。パラメータ同士に競合がないと、プレイヤーは全パラメータを均等に上げるだけの作業になります。回避するには「体力を上げると幸福度が下がる」「技術を鍛えるとメンタルを消費する」というトレードオフを設計段階で組み込んでください。競合がゲームの意思決定を生みます。
ゴールが見えない。パラメータが上がり続けるだけで何を達成すればいいのか分からないゲームは、途中で離脱されます。「〇日間でパラメータXをY以上にする」という期限付きの目標か、「パラメータがZを超えるとエンディングに分岐する」という到達点を設けてください。
数値が増えても体験が変わらない。数値だけが上がってグラフィックや演出が変わらない育成は、成長実感が薄くなります。少なくとも一つのパラメータが閾値を超えたとき、テキストや画像が変わる「段階演出」を入れてください。複雑なアニメーションでなくても、表示するメッセージや背景色を変えるだけで効果があります。
時間経過の速度調整を後回しにする。「ちょうど良い速度」はプレイして初めて分かります。速度や増分は必ず定数として一箇所にまとめて書いておき、数値を変えるだけで全体を調整できる設計にしてください。コード全体にマジックナンバーが散らばっていると、バランス調整のたびに大きな修正が必要になります。
小さく作って確かめる順番
設計が決まったら、次の順番で実装を進めるとバランス調整がしやすくなります。
- 軸となるパラメータ一本と、それを増やす操作一つだけで動く最小版を作る
- マイナス方向の変化を加えて「何もしなければ下がる」状態にする
- ゴール条件（期限・到達値・エンディング分岐）を追加する
- サブパラメータとトレードオフを追加する
- 演出（段階変化のテキスト・画像）を追加する
この順番を守ると、各ステップで「遊べる状態」が確認できます。先に演出やパラメータの種類を増やしてからバランスを取ろうとすると、どの数値を変えれば良いか判断できなくなります。
次の行動
軸となるパラメータ一本を決め、増分・最大値・減少速度の三つだけを書き出してから実装を始めてください。最小版が動いたら、アソバースにHTMLファイルとして投稿して実際にプレイしながらバランスを調整するのが最も効率的です。設計メモと数値定数を一緒に残しておくと、後から修正するときの手間が大きく減ります。
