HELLSCAPE

• Game design, story structure and branching
• Gameplay programming in C#: on foot, in the van and in the boss fight
• Enemy AI with NavMesh navigation, sight and sound
• Dialogue, choice and judgement systems
• Editor tooling that builds each act into the scene
• Play-mode regression tests for the story branches
• Diegetic UI, cinematic cameras and cutscenes
• Python tools that generate sound effects and textures

A branching story is easy to break. Every choice, checkpoint and interrupted cutscene is a way to skip a line, replay one, or leave the player holding state that should have been cleared. The game also spans very different kinds of play, walking, puzzles, chases, swimming, driving and a boss, and they all have to share one player, one UI and one set of story flags.

1. 01

   Judgement

   Conversation answers, the kill-or-spare choice and who you pull from the flood are recorded as flags. The verdict at the bridge is assembled from them, with a separate line for each person.

2. 02

   The Lost and the Damned

   Enemies walk, crawl, feed or stand dormant. They hunt by sight and sound, scream before they charge, and the scream draws in the others nearby.

3. 03

   Two realms in one office

   Pressing V closes a pair of eyelids, swaps the burnt office for a clean memory of it, and opens them again. Each visit lasts six seconds, and puzzles can only be solved in the memory.

4. 04

   Dialogue as data

   647 lines live in a CSV and are loaded by id, so the script can be rewritten without touching the scene or the code that triggers it.

5. 05

   Diegetic UI

   No health numbers. A beating anatomical heart stands in for the player, and the van's paint dents, scorches and starts to smoke as it takes damage.

6. 06

   Cinematic cameras

   The van escape cuts between fixed film set-ups along the road, in the manner of PS2-era survival horror, and hands back to a chase camera in the tunnel and the boss arena.

7. 07

   Three-phase boss

   Blood orbs, slams and charges. An exposed heart takes triple damage, a dodged charge leaves him stunned, and if the van is lost the fight continues on foot.

8. 08

   Generated assets

   Python scripts synthesise the sound effects and paint the van's damage stages, so those assets can be regenerated instead of edited by hand.

1. Each act is assembled by an editor script instead of by hand. Re-running a builder deletes the previous version of the act and builds it fresh, which keeps a large scene reproducible.
2. The van camera went through three designs: a top-down view, a set of fixed spots along the road, and the cinematic set-ups the game uses now. The earlier two are still in the code, switched off.
3. The story was rewritten after the systems existed. An audit mapped the new script onto what was already built, and the rewrite replaced text through those systems instead of adding a second narrative framework beside them.
4. Changes to the story are checked by play-mode tests that run against disposable scene state and never save the scene.

• Dialogue that survives interruption

  Pending lines are deduplicated, urgent interruptions get their own generation so an old speech finishing cannot corrupt the new one, and a checkpoint respawn cancels queued replies, choices and puzzles.

• Swapping a realm without breaking it

  Entering the memory swaps materials and post-processing over the same geometry. Leaving restores the exact material slots captured at startup, and a door can never close on the player mid-transition.

• State across death

  Story state lives in memory and survives checkpoints because a respawn does not reload the scene. There is no save to disk yet, so quitting loses the run.

• In development. The current build ends on TO BE CONTINUED.
• The full project, including design documents and test tooling, is public on GitHub.