Unity · 2D Isometric Survival Horror
A 2D isometric survival-horror/RPG prototype built around a clear loop: explore the hotel, complete environmental quests, then evade an Abyssal Terror that can spawn out of sight and kill the player in one hit. Tension comes from limited information and pursuit, not scripted jumpscares.
CASE STUDY / 2026A 2D isometric survival-horror/RPG prototype built around a clear loop: explore the hotel, complete environmental quests, then evade an Abyssal Terror that can spawn out of sight and kill the player in one hit. Tension comes from limited information and pursuit, not scripted jumpscares.
Hotel Between is a 2D isometric survival-horror RPG prototype about entering an unfamiliar hotel, understanding its rules, and completing environmental quests before the space turns hostile.
There are no scripted jumpscares. Fear comes from limited vision, uncertain spawn timing, the sound and movement of pursuit, and the knowledge that one hit ends the run.
Quest objectives publish state changes instead of coupling every door, candle, and save operation together. A typical chain is extinguish the required candles, unlock the route, persist progress, and restore the correct objective after loading.
The enemy moves through Patrol, Hunting, and Attacking states. Contact triggers a local one-hit death flow without freezing the whole game through global time scale, keeping UI, transitions, and recovery controllable.
The current Hotel Between build runs directly in this page. Desktop keyboard and mouse are recommended; click inside the game to capture input.
Explore the hotel, complete the candle objective, and react when the Abyssal Terror begins its pursuit. This is an active prototype, so content and balancing may change.
The game keeps interaction, quest state, encounter selection, enemy behavior, presentation, and persistence in explicit systems so the core loop can be tuned without hiding side effects in the player controller.
Quest events, encounter selection, AI state, player death, and save data remain separate enough to test and iterate without turning the player controller into the entire game.
The diagram above is the runtime path. These cards show the concrete modules I implemented and how each one contributes to Explore & Escape.
Input System → target selection → distance validation → UnityEvent action.
Candles, keys, doors, objectives, floor state, and event-driven progression.
URP Light2D, Physics2D line of sight, wall fade, and multi-floor render rules.
45–75 second window → five candidates → distance and visibility rejection → retry.
Patrol → Hunting → Attacking → local one-hit death and recovery flow.
NavMeshPlus paths pursuit across connected hotel spaces and floor transitions.
Quest progress and world state restore through registered saveable modules.
URP ShadowCaster repair tooling and focused tests protect fragile transitions.
These sections are stored with the project and can be expanded, rewritten, or reordered from Creator Studio as the case study develops.
Explore the hotel, complete environmental quests, react when the Abyssal Terror enters the floor, and escape the pursuit. The enemy kills in one hit, so tension comes from uncertainty, route choice, and lost safety—not scripted jumpscares.
Quest objectives publish state changes instead of coupling every door, candle, and save operation together. A typical chain is extinguish the required candles, unlock the route, persist progress, and restore the correct objective after loading.
A shared interaction layer validates distance, selects the current target, manages listener lifecycles, and uses UnityEvents for object-specific behavior. New interactables can join the same player-facing flow without rewriting the controller.
URP Light2D, Physics2D occlusion, and wall fading create a limited field of information. Enemies remain hidden when walls block line of sight, making spatial awareness more important than a scripted scare cue.
The enemy moves through Patrol, Hunting, and Attacking states. Contact triggers a local one-hit death flow without freezing the whole game through global time scale, keeping UI, transitions, and recovery controllable.
The prototype waits a random 45–75 seconds, evaluates five spawn points, rejects locations closer than 12 units or visible to the player, chooses among the safest candidates, and retries after four seconds when no valid point exists.
Sorting layers, floor-aware visibility, and NavMeshPlus navigation support connected hotel floors while keeping movement, rendering, and pursuit behavior readable across vertical transitions.
JSON-backed save data keeps quest progress and world state separate from scene presentation. The system is designed so additional saveable systems can register their own data without turning one manager into a project-wide dependency.
Editor tooling repairs URP ShadowCaster setup and repeatable tests cover fragile gameplay transitions. This remains a work-in-progress prototype; multiplayer authority and production-scale content are not claimed as completed systems.
Architecture and implementation details are documented as part of the work, not reconstructed after delivery.
Cover art, screenshots, diagrams, and demo video can be updated without changing the project record or page structure.
Clear layers and reusable patterns make future features easier to estimate, review, and deliver safely.