少年を施設から無事脱出させるゲーム

ゲームの概要

本作は、プレイヤーがお化けとなり、施設から脱出しようとする少年を間接的に守るゲームです。

少年は施設内を進みますが、その先には装置や罠が配置されており、何もしなければ何度も命を落としてしまいます。
プレイヤーは少年を直接操作するのではなく、施設内の仕掛けを観察し、罠の動作やタイミングに介入することで、少年が生き延びられる状況を作っていきます。

観察、関連付け、仕込み、実行を繰り返しながら少年の死因を特定し、最終的に施設から脱出させることが目的です。

役割の面白さ

本作の特徴は、プレイヤー自身が脱出するのではなく、「守る側」として少年の行動を支える点です。

少年は危険を正確に判断できないため、プレイヤーは先回りして罠を解除したり、危険な進路を避けられるように誘導したりする必要があります。
直接的なアクションではなく、状況を読み取り、事前に手を打つことを遊びの中心にしています。

プレイヤーの介入

プレイヤーは主に以下の方法で少年の生存に介入します。

• 施設内の罠や装置の挙動を確認する
• 危険な仕掛けを解除、または別の結果になるように変化させる
• 少年の進路を安全な方向へ誘導する
• タイミングよく行動し、死亡につながる状況を防ぐ

少年が死亡した場合は、その原因を手がかりに次の行動を考えます。
失敗を単なるリセットではなく、次の攻略に必要な情報として扱う構成を意識しました。

リンク

• 開発の詳細

設計上の課題

本作では、プレイヤーの介入結果が少年の生死に直結します。
そのため、難しさを出しながらも、失敗した理由が理不尽に見えないようにすることが重要でした。

特に意識したのは、プレイヤーが「なぜ少年が死んだのか」「次にどこへ介入すればよいのか」を理解できることです。
罠の位置、少年の進行方向、危険が発生するタイミングを分かりやすく見せることで、失敗を次の判断につなげられるようにしました。

実装・設計

本作では、クラス間の依存関係を整理するために DI（Dependency Injection）を導入しました。
ゲーム進行、イベント処理、ギミック制御などの責務を分けることで、巨大な Manager クラスや Singleton に処理が集中しない構成を目指しました。

また、処理を小さなコマンド単位に分割し、それらを Inspector 上で組み合わせられる仕組みも試作しました。
これは、後に制作を進めることになる TinnosukeGameLib の、Inspector 上で構築可能なコマンド構成の原型になっています。

一方で、本作では DI の適用範囲を広げすぎた部分もありました。
特に、Entity ごとに DI コンテナを持たせるような構成は、依存関係の追跡や初期化処理を複雑にし、結果として設計の見通しを悪くする原因になりました。

視認性と演出

本作は施設内を舞台にしているため、全体的に暗い色調を使用しています。
ただし、暗さによってプレイに必要な情報が見えにくくならないよう、少年、敵、重要な装置が視認しやすくなるようにライティングを調整しました。

また、明かりのあるオブジェクトを目立たせることで、プレイヤーの視線を自然に誘導しつつ、施設の不気味な雰囲気を作ることを意識しました。

学んだこと

本作の開発を通じて、以下の点を学びました。

• プレイヤーが直接操作しない対象を守るゲームでは、状況の見せ方が特に重要になる
• 失敗理由が分かる構成にすると、リトライが納得感のある体験になる
• DI は便利だが、適用範囲を誤ると設計が複雑になりすぎる
• Inspector 上で処理を組み立てる仕組みは、イベントやギミック制作の効率化につながる
• 暗い画面作りでは、雰囲気と視認性のバランスを取る必要がある

反省点

当初は DI を積極的に取り入れることで、依存関係を整理しやすくなると考えていました。
しかし、実際には適用範囲を広げすぎたことで、Entity ごとの構成が複雑になり、処理の流れを追いにくくなる場面がありました。

この問題は次のゲームフレームワーク制作の際にも、悪い方向に引き継がれてしまい、結果的に一からの設計見直しにつながることになりました。