Vile Escape

Category: Top-Down Zombie Shooter (Capstone)
Engine: Unity (C#)
Team: Team Fame and Game (7 designers)
Itch.io (Team): timothyj.itch.io/vile-escape
Itch.io (Personal Levels): thyarcanist.itch.io/vile-escape
GitHub: github.com/thyarcanist/VileEscapeCAPSTONE

Context

First real C#/Unity project (2021). A zombie apocalypse top-down shooter built by a 7-person team. The code in the GitHub repo demonstrates professional-grade instincts at the capstone stage: separation of concerns, Inspector-friendly tunables, and lifecycle cleanup. These are the systems I built.

Flashlight System (FlashlightUsage.cs)

A game-feel feature, not a tutorial toggle. The flashlight has real battery mechanics:

The flicker uses a coroutine that rapidly toggles the light component when battery drops below the flicker threshold. When battery hits zero, the light cuts with its own audio cue and stays off until recharged. Edge-case handling includes preventing the one-shot audio from stacking when called multiple times in the same frame.

This is a small system, but it demonstrates attention to player feedback. The distinction between “I turned it off” (click) and “it died” (different sound) is the kind of detail that makes a game feel real.

Power Breaker (MainLightBreaker.cs)

A timed interaction that triggers system-wide environmental change. One interaction, broad consequences:

This is a level-design tool disguised as a mechanic. One breaker controls every main light in the scene. The downTime parameter means level designers can tune how long darkness lasts per breaker without touching code.

Road Level

The Road Level (LVL9_Road) shipped in the final build. RoadLevel.cs configures the player’s starting weapons and ammo for the level. The level design itself is a linear gauntlet with trigger-gated progression.

Train Station Level (Scrapped)

Inspired by Resident Evil Outbreak’s Undertow/Underrail level. A subway environment with SubwayOpenTrigger.cs remnants still in the codebase. Scrapped due to scope but the trigger architecture was reused in the Road Level.

Quest/Progression State Machine

The most architecturally significant contribution. Three scripts work together to create a player-driven progression system:

RDTrigger.cs - Trigger Zones

Multiple trigger zones (ThresholdA, ThresholdB, ThresholdC) detect player position and advance quest state. Each threshold can:

RoadEvents.cs - Progression Manager

Tracks quest state through boolean flags: bGotFetchQuest, bGotWater, bGotFetchComplete. When conditions are met:

This is a simple state machine, but it cleanly separates what happened from what should happen next.

CenterAreaEvents.cs - World Response

Reacts to quest states by swapping guidance lights (directing the player) and closing gates if the player exits prematurely. This script reads state from RoadEvents and translates it into environmental feedback.

The Pattern

Trigger scripts detect player position. Manager scripts decide what happens. Reusable tool scripts handle the consequences. This three-layer separation means any of these scripts could be reused in a different level with different quest logic. For a first project, this is a strong architectural instinct.

Engineering Instincts

These patterns show up consistently across all contributions:

Separation of concerns: Trigger scripts never decide what happens. Manager scripts never detect position. Tool scripts (flashlight, breaker) are self-contained and reusable.

Inspector-friendly tunables: [Header(...)] grouping, public fields for timers, rates, audio clips, and thresholds. Every tunable is exposed to the Inspector so designers can adjust without opening a script. This is a practical professional Unity habit.

Lifecycle cleanup: InvokePlayer and InvokeSphere destroy themselves once the quest item is received. This prevents repeated trigger behavior and reduces update overhead. Objects that have served their purpose remove themselves from the scene.