Section
Development
画面情報を増やしすぎず、プレイ中の判断を阻害しない UI と進行管理を意識して開発しました。
遊びの軸
本作は、ユニットを配置して敵の進行を防ぐタワーディフェンスゲームです。
派手なシステムを増やすよりも、配置判断・リソース配分・対応タイミングがそのまま結果に反映されるゲーム性を重視しました。 プレイヤーが状況を観察し、限られた手段の中で最適な判断を重ねていくことを遊びの中心にしています。
プレイヤーの判断
プレイ中は、主に以下の判断が重要になります。
- 敵を効率よく倒すために、どの地点へユニットを配置するか
- 限られたリソースを、配置・強化・対応のどこへ使うか
- 敵の進行状況に対して、どの順番で対処するか
単にユニットを増やすだけではなく、敵の流れを読みながら対応することで、より安定して攻略できるように設計しています。
周回要素
敗北すると「Rebirth」によって最初からやり直しになります。
ただし、前回のプレイで得たリソースの一部を引き継いで再スタートできるため、プレイを重ねるほど少しずつ強くなっていきます。 これにより、失敗しても完全なリセットにはならず、次のプレイで成長を実感できる構成にしました。
実装テーマ
開発面では、タワーディフェンスとしてのゲーム性に加えて、プレイヤーが次に何を判断すればよいかを理解しやすい UI 設計を重視しました。
敵の進行状況を把握しやすくするため、カメラのズームイン・ズームアウト機能や、画面外の敵の位置を示す矢印を実装しています。 また、ユニットのステータスはアイコンで表現し、数値を細かく読まなくても状況を把握できるようにしました。
ゲームループが単調にならないよう、敵の流れを視認しやすくし、プレイヤーが「どこを見れば次の判断ができるか」を明確にすることを意識しています。
使用技術・実装
本作では、ユニット・敵・ステージ情報などを ScriptableObject で管理し、データを変更するだけでステータスやステージ内容を調整できるようにしました。 これにより、コードを直接変更せずにゲームバランスを調整しやすい構成にしています。
ゲーム進行の管理にはステートマシンを導入し、ステージ開始、敵の出現、終了処理などの状態を明確に分けて制御しました。 また、敵の出現タイミングや時間経過に伴う処理にはコルーチンを使用し、タワーディフェンスに必要な時間制御を実装しています。
演出面では DOTween を使用し、ユニットの攻撃や敵の移動、UI の表示切り替えなどに滑らかなアニメーションを加えました。
設計面では、ユニットや敵の種類を増やしやすくするため、共通処理を抽象化しながら実装しました。一方で、後述するように継承に寄せすぎた部分もあり、Unity の Component ベース設計との相性について学ぶきっかけにもなりました。
共同開発
本作は、私とパートナーの2名で制作しました。
私はプログラム全般を担当し、ゲームロジック、UI 実装、データ管理、ステージ進行、演出制御などを実装しました。 パートナーはアートと UI デザインを担当し、キャラクターや画面全体のビジュアル制作を行いました。
開発中は、実装状況やデザイン方針を定期的に共有しながら進行しました。 この経験を通じて、チーム制作では早い段階でゲームの方向性を共有し、仕様・タスク・スケジュールを整理することが重要だと学びました。
学んだこと
本作の開発を通じて、特に以下の点を学びました。
- プレイ中に表示する情報は、多ければよいわけではない
- UI は単体で考えるのではなく、ゲーム進行のテンポと合わせて調整する必要がある
- 早い段階で画面上の導線を整理すると、後半の調整がしやすくなる
- 共同開発では、ある程度動くプロトタイプを作ったうえで役割分担を決めると進行しやすい
- データ管理を ScriptableObject に寄せることで、調整作業を効率化できる
反省点
実装面では、継承を中心にした設計に寄せすぎたことで、Unity の Component ベースの設計と噛み合わない部分がありました。 その結果、ユニットや敵の種類が増えるにつれて、派生クラスの管理が複雑になり、後半の機能追加や調整に時間がかかりました。
また、ゲーム全体を管理するクラスに処理が集中してしまい、進行管理・UI 更新・ゲーム状態の制御が密結合になってしまった点も課題でした。
今後は、共通処理を継承だけで表現するのではなく、Component の組み合わせや責務ごとのクラス分割をより意識し、機能追加や調整に強い構成を目指したいです。