インクリメンタルゲームの数値設計：指数と対数

コストカーブに指数関数を使う理由

アップグレードの購入コストを設計するとき、最もよく使われる式は次の形です。

cost(n) = base × rate^n

base が初期コスト、rate が購入ごとの倍率、n が購入回数です。たとえば base = 10、rate = 1.15 なら、0回目は10、1回目は11.5、10回目は約40、50回目は約1083になります。

なぜ等差（足し算）でなく等比（掛け算）なのかというと、プレイヤーの「稼ぎ」も指数的に増えるからです。生産速度が上がるたびに収入も掛け算で増えていきます。コストが算術的にしか増えなければ、後半は何もしなくても全部買えてしまいます。収入の伸びとコストの伸びを同じ指数のオーダーにそろえることで、「買うか貯めるか」の判断を最後まで残せます。

rate の選び方が設計の要です。1.1〜1.5の範囲が実用的で、1.1前後は「気づかないうちに高くなる」緩やかな圧力、1.5前後は「数回買うと急激に重くなる」短命な選択肢という印象になります。同じゲーム内に複数のアップグレード系統を持つ場合、系統ごとに rate を変えることで役割を差別化できます。

効果カーブと「収益逓減」の設計

コストが指数で増えても、アップグレードの効果も同じ倍率で増えると、後半は一回の購入で生産量が何千倍にもなります。それ自体は悪くありませんが、プレイヤーが「どれを買えばよいかわからない」状態になりやすいです。

効果に対数を使うと、この問題を調整できます。

effect(n) = a × log(n + 1) + b

購入回数が増えるにつれて効果の「上乗せ幅」が小さくなります。序盤の1回目は大きな変化、100回目は小さな変化、という体感になります。これを「収益逓減」（diminishing returns）と呼びます。

ただし対数だけで効果を設計すると、終盤の購入に意味を感じにくくなります。実際のゲームでは「一定回数ごとに乗算ボーナスを挟む」「別系統のアップグレードが対数カーブをリセットする」といった仕組みでリフレッシュ感を作ることが多いです。この「節目のボーナス」は、対数カーブの単調さを補う最も簡単な手段です。

ゲーム時間と数値スケールのすり合わせ

設計の流れとして、次の手順が扱いやすいです。

1. プレイ想定時間を決める　序盤（0〜30分）・中盤（30分〜数時間）・終盤（数時間〜）でどんな体験をさせたいかを言語化します。
2. 終盤の数値上限を決める　「生産量が最終的に何になるか」を先に設定します。1e6（百万）程度に収めるか、1e50を目指すかで使うべき表記（通常の数字 vs 指数表記 vs 「aa」「bb」などの略称）が変わります。
3. 中間点を計算する　終盤の値を基準に、中盤の数値を逆算します。cost(n) = base × rate^n で n を求めるには対数を使います：n = log(cost / base) / log(rate)。この式でスプレッドシートに数列を作り、体感の変化点を確認します。
4. スプレッドシートで通しテストをする　数式だけで全体を書き出し、「各段階でどれくらい貯めれば次が買えるか」を秒数に換算します。30分で中盤に入れているか、終盤に無限ループが生まれていないかをここで直します。

スプレッドシートによるシミュレーションは、実際にゲームを動かす前に問題を発見できる最も費用対効果の高い手段です。コードを書く前にパラメータを10通り試すことを勧めます。

「プレステージ」と対数のリセット設計

多くのインクリメンタルゲームには、ある段階で数値をリセットして永続ボーナスを得る「プレステージ」（転生・リバース）があります。この仕組みは、対数カーブの収益逓減が生み出す「飽き」を解消するために生まれました。

プレステージ報酬の設計にも対数は有効です。

prestige_bonus = floor(log10(total_produced))

総生産量の対数（常用対数）を切り捨てた値をボーナスとする、という方法です。1万生産で4、100万生産で6というように、桁数がそのままポイントになります。この設計の利点は「もう少し貯めれば報酬が増える」という引力を常に作れること、そして報酬がインフレしにくいことです。

注意点として、プレステージ後のコストカーブは「リセット前と同じ rate を使うと早く終わりすぎる」という問題が起きがちです。プレステージ回数が増えるにつれて rate を少し上げるか、または解放されるアップグレード本数を増やして選択肢で長さを作る方法があります。

数値が大きくなったときの表示設計

設計上の問題ではなく実装上の注意として、JavaScriptの number 型は約15桁の精度しか持ちません。1e15 を超えた数値で足し算の誤差が見えはじめます。1e20 を超えるゲームを作る場合は、任意精度の数値ライブラリ（Decimal.js、break_infinityなど）を導入するか、内部的に対数で保持して表示時だけ変換する設計を検討します。

表示の読みやすさも設計の一部です。「1,000,000」より「1M」、「1e6」より「百万」のほうが多くのプレイヤーには直感的です。ただし10e30を超えるゲームでは略称の体系（K・M・B・T→aa・ab…）が必要になるため、序盤からどの表記系を使うか決めておくと実装が楽になります。

次の行動

まずスプレッドシートを開き、cost(n) = 10 × 1.15^n の数列を100行ほど作って「何秒で次が買えるか」を書き込んでみてください。数字を眺めるだけで中盤の詰まりや終盤の崩れが見えてきます。パラメータを変えたときの差異がつかめたら、それをそのままコードに持ち込む準備が整います。アソバースにはHTMLファイル単体でも投稿できるため、プロトタイプを早い段階で公開して他のプレイヤーの反応を見ることもできます。

参考資料

• Wikia / Fandom「Incremental Games」コミュニティ wiki（数値設計のコミュニティ知見）
• MDN Web Docs「Math オブジェクト」（JavaScriptの数学関数リファレンス）
• Decimal.js 公式ドキュメント
• break_infinity.js GitHub リポジトリ