たこが空を飛ぶゲーム

遊びの軸

プレイヤーは、タコを左右に操作しながら、上方向へ進んでいくステージを攻略します。
タコは常に上昇していくため、障害物の配置を見て、どのタイミングで左右に移動するかを判断することが遊びの中心になります。

単に反射神経だけで避けるのではなく、障害物の動きや配置を見ながら、次に進むルートを選ぶ構成にしています。

ゲームの構成

ゲームは全5ステージで構成されています。
各ステージには異なる障害物の配置やギミックが用意されており、ステージが進むにつれて、避けるだけでなく、ルート選択やタイミングの判断も重要になります。

また、各ステージには2〜3個ほどのスコアアップアイテムを配置しています。
これらを取得するとスコアが上がるため、最短でゴールを目指すだけでなく、アイテムを取りに行くかどうかの判断も発生します。

ステージ内にはチェックポイントも用意しており、到達後は次のプレイからその位置から再開できます。
これにより、難しいステージでも少しずつ進める構成にしています。

スコア

スコアは、ゴールまでの時間とスコアアップアイテムの取得状況によって決まります。

ゴールまでの時間が短いほど高いスコアになりますが、スコアアップアイテムを取得することでもスコアを伸ばせます。
そのため、プレイヤーは「速くゴールするか」「少し遠回りしてアイテムを取るか」を選ぶことになります。

また、チェックポイントから再開せず、最初から通しでクリアした場合はスコアにボーナスが入ります。
ミスを減らして一発でクリアすることにも意味を持たせています。

技術的なテーマ

今作では、前作である NecroReverse での経験を踏まえ、独自フレームワークの改善を行いながら開発しました。
特に、ICommand パターン、IDynamicSource、Blackboard/Scalar による値管理を組み合わせ、ゲーム内の処理や UI の更新をデータ駆動で扱えるようにすることを目指しました。

UI 制御にも力を入れ、ボタンのアニメーション、クリック時の処理、Slider などの UI 要素を Blackboard/Scalar と紐づけることで、値の変化に応じて UI が動的に更新される構成にしました。
これにより、コードを直接変更しなくても、ゲーム内の数値や UI の挙動を調整しやすい形を目指しました。

また、この作品の制作にあわせてゲームフレームワークを大きく改修し、TinnnosukeGameLib として再設計しました。

Editor 拡張

開発効率を上げるため、Editor 拡張も積極的に行いました。

Command の組み立てには専用の Editor Window を作成し、処理の流れを視覚的に確認しながら設定できるようにしました。
Inspector 上で複雑な設定を直接編集する負担を減らし、設定ミスを減らすことを狙っています。

また、Inline で編集できる Command も増やし、コードを書き換えずにゲームの挙動を調整できる範囲を広げました。
これにより、ステージごとの挙動調整や UI 演出の変更を行いやすくしました。

Entity 管理の設計

今作では、Entity ごとに DI コンテナを持たせ、Entity に設定された Component の情報を、その Entity に紐づく Service へ流し込む構成を採用しました。

この構成により、Entity ごとに異なる機能を柔軟に持たせることができました。
一方で、Entity 数が増えるほど依存関係の追跡や初期化処理が複雑になり、設計全体の見通しが悪くなる問題も発生しました。

特に、Entity ごとに DI コンテナを Build する構成は、起動時の負荷や初期化時間の増加につながりました。
さらに、数百体規模の Entity、Blackboard/Scalar の参照、大量の Command 実行が重なることで、パフォーマンス面の課題も明確になりました。

ノートパソコンでのプレイ時には FPS が 30 を下回る場面もあり、ゲームプレイに影響が出るレベルの負荷が発生しました。

得られた課題と次の設計への反映

この経験から、Entity ごとに DI コンテナを持たせる設計は、柔軟性は高い一方で、初期化コスト、依存関係の追跡、実行時パフォーマンスの面で大きな課題があると判断しました。

そのため、次のフレームワークでは、Entity は Authoring された Component を持つだけにし、実際の処理は RootKernel 側の System に集約する方針へ変更しました。
Entity ごとのデータは System に登録し、必要に応じて AoS / SoA を使い分けることで、見通しとパフォーマンスの両立を目指しています。

この作品は、単にゲームを完成させるだけでなく、独自フレームワークの設計上の限界を実際の開発を通じて検証し、次の設計へつなげるきっかけになりました。