インディーゲーム開発で最初につまずくのは、実はコードの書き方そのものではありません。プロジェクトが大きくなるにつれて「どこに何を書いたか分からなくなる」という設計の問題です。私自身、初めて個人でリリースした恋愛アドベンチャーで、シナリオ分岐のフラグ管理を各シーンのスクリプトに直接書き込んでしまい、後半で分岐を一つ足すだけで半日を溶かした苦い経験があります。ここでは、そうした「未来の自分を助ける」Unityの基礎設計について、実装のテクニックではなく考え方を中心にお話しします。
「シーン」ではなく「状態」で考える
Unityを触り始めると、つい画面ごとにシーンを分け、シーンの中に全ての処理を詰め込みたくなります。しかしこの発想は、規模が大きくなると破綻します。タイトル画面、会話パート、選択肢、エンディングと進む恋愛ゲームで考えてみましょう。これらは見た目こそ違いますが、内部的には「今どんな状態で、次にどこへ遷移するか」という共通の骨格を持っています。
私が最終的にたどり着いたのは、ゲーム全体の進行を一つの状態遷移として捉える方法でした。GameStateという概念を一つ用意し、そこが「今はどの局面か」を一元管理する。各シーンはあくまで表示係に徹し、判断はしない。こうすると、新しい局面を足すときも既存のコードを壊さずに済みます。設計とは、変更したときに壊れる範囲を小さく保つ技術だと言い換えてもいいでしょう。
データとロジックを引き剥がす
初心者がやりがちなのが、キャラクターの好感度やアイテムの効果といったデータを、それを使う処理と同じ場所に書いてしまうことです。好感度の上限を変えたいだけなのに、会話処理のコードを探し回る羽目になります。
Unityにはこの問題への答えとしてScriptableObjectという仕組みがあります。データを「アセット」として外に出してしまうのです。キャラクターの初期パラメータ、選択肢ごとの好感度増減、BGMの割り当て。こうした「調整したくなる値」をScriptableObjectに逃がしておくと、プログラムを書き換えずにInspector上で数値をいじるだけでバランス調整ができます。私の場合、これを導入してからテストプレイのたびにコードを触ることがほぼなくなり、調整のサイクルが劇的に速くなりました。データは資産、ロジックは道具、と分けて考えるのがコツです。
依存の向きを一方通行にする
もう一つ、後から効いてくるのが「どのスクリプトがどのスクリプトを知っているか」という関係、つまり依存の設計です。AがBを呼び、BがまたAを呼ぶような相互参照が増えると、片方を直したらもう片方が壊れる、という状態に陥ります。
理想は、依存を一方通行に保つことです。UIは進行管理を知っていてよいが、進行管理はUIの具体的な中身を知らない。この向きを守るために、私はイベント通知の仕組みをよく使います。好感度が上がったら「上がった」という事実だけを発信し、それを聞きたい者が勝手に反応する。発信側は誰が聞いているか気にしません。この疎結合を意識するだけで、機能追加のたびに全体を見直す必要がなくなります。
「動くもの」を最速で作ってから整える
ここまで設計の話をしてきましたが、最初から完璧な設計を目指すのは逆効果です。個人開発では、まず汚くても動くプロトタイプを作り、面白さを確かめることが最優先です。設計に凝りすぎて一枚も絵が動かないまま数週間が過ぎる、というのは個人開発で最も多い失敗の形だと感じています。
私が実践しているのは、最初のプロトタイプは意図的に雑に作り、「これは面白い」と確信できた部分だけを本設計に載せ替える、という二段構えです。捨てる前提で作ったコードは思い切りよく捨てられます。設計は目的ではなく、面白さを長く育てるための手段だという視点を、常に持っておきたいところです。
まとめ
Unityの基礎設計とは、凝った技術を使うことではなく「変更に強い構造を保つ」ことに尽きます。状態で進行を捉え、データとロジックを分け、依存を一方通行にする。この三つを意識するだけで、個人開発の後半戦が驚くほど楽になります。ただし設計は面白さを守る手段であって目的ではありません。まず動かし、確信した部分だけを丁寧に整える。その順序を守ることが、完成までたどり着く一番の近道です。
