外部調査を、あとから答え合わせに使う——game-dev-playbookの運用実例

ゲーム開発で外部の理論と設計を照らし合わせるとき、やってはいけない順番がある。ゲーム内にプレステージというシステムを実装した。敵を倒して進み、ある条件で進行をリセットして強くなって再チャレンジする——放置ゲーム的な基本設計だ。最初は60分で7回リセットが起きるペースだったが、装備を厳選する楽しみがなくなるため、敵の成長速度を緩めてリセット条件を引き上げ、1時間4回のペースまで落とした。この調整は外部の教科書を読んで決めたのではなく、実際に遊んでみた「手触り」だけが根拠だ。

その後で気になって、外部理論を調べなおした。放置ゲームの実装パターン4種を比較した記事を見つけた。各種それぞれ異なる方式——同地点リセットで獲得ゼロという極端な方式、生涯累積で緩やかな勾配、中庸的な方式、今回だけを基準にした急勾配。自分の実装値と照らし合わせたら、既存の理論体系に矛盾していないことが分かった。つまり、手探りで辿り着いた設計が、学説の側からも理に適っていたということだ。

ここが面白いのは「検算の順番」である。もし先に外部理論を読んで「こういう方式があるから採用しよう」と決めていたら、自分のゲーム固有の要求——厳選する楽しみ——が後付けされていたかもしれない。内で決めて外で検算する。これが自分のプロダクトを守る。中小企業がBtoBツールやDXプラットフォームを入れるとき、「業界標準だから」と先に外部枠組みを導入してから業務を合わせる企業も多い。逆順だ。自分たちの業務フローを整理して、それでもなお必要な部分に限ってツール化する。その判断が生死を分ける。