Can explicit rules, timing, and feedback make a small combat world feel responsive and alive?
Case study · Interactive systems
Rules that create feel.
Explicit state creates legible behavior. Mystic Forest is a solo-built 2D action game focused on how timing, camera, audio, and feedback combine into responsive combat.
RoleSolo developer & designer
PeriodDec 2025 — Jan 2026
StackUnity 6 · C# · WebGL
FocusCombat · AI · game feel
Core systems
Behavior is separated into states, then shaped through feedback.
Finite-state behavior owns decisions while animation, camera, audio, and effects communicate the resulting state.
The browser build became a separate engineering constraint requiring deployment and runtime QA beyond the Unity Editor.
Readable timing
Three-hit combos, parry windows, counter opportunities, and finisher feedback make cause and effect legible.
Explicit states
Enemy idle, chase, attack, and death behavior is separated with finite-state machines instead of one growing controller.
Layered response
Hit stop, Cinemachine impulse, post-processing, particles, and audio mixing reinforce the same gameplay event.
Boss design
The flying boss exposed a control problem: following every vertical movement made it feel weightless and nervous. A deadzone updates target altitude only after the player crosses a threshold, then SmoothDamp preserves mass.
01 · SENSEMeasure the player’s ideal relative altitude.
02 · FILTERIgnore small vertical changes inside the deadzone.
03 · UPDATEChange target altitude only after the threshold is crossed.
04 · MOVEApproach the target with damped motion.
Deployment failure
The Editor was not the runtime that players used.
The deployed WebGL build remained on the loading screen.
A working Editor session was not accepted as proof that the browser artifact was healthy.
Boundary · local runtime ≠ deployed runtimeHosting and compression were checked as part of the system.
The failure path included generated build files, server delivery behavior, and browser loading rather than only gameplay code.
Decision · debug the delivery chain end to endPresentation and runtime assumptions were retested.
Canvas scaling, WebGL audio loading, scene transitions, and physics layers were checked in the browser environment.
Verification · test the artifact where it is consumedThe browser build became a verified deliverable.
The project was rebuilt and deployed with the loading path and browser-specific behavior checked outside the Editor.
Evidence · playable WebGL releaseClaim boundary
A focused interactive-systems project, not an engine.
State-driven combat, boss movement logic, layered feedback, and browser deployment QA in a complete playable project.
The project does not demonstrate large-world simulation, engine-level performance work, or production-scale multiplayer architecture.