Sample supporting case study

Ritual Runner

This is sample supporting-project content designed to show how a shorter case study can still communicate ownership, challenge, and outcome clearly on the final portfolio.

Placeholder content: replace this section with a real school, jam, or side project when ready.

Role Gameplay programmer
Team size 3
Duration 4 weeks after jam prototype
Tools Unity, C#, Aseprite workflow, Git
Ritual Runner movement and combat scene with a dash attack across platforms. Ritual Runner boss arena with projectiles, moonlit background, and player dash trail. Ritual Runner route tuning scene with hazards, checkpoints, and timing readouts.

What I owned

  • Implemented the player controller, including acceleration, jump leniency, dash timing, and attack cancel rules.
  • Built buffered input and coyote time so the game still felt responsive under stress.
  • Hooked combat and movement states into hit feedback, checkpoint flow, and controller support.
  • Adjusted enemy timing and arena spacing based on short playtest loops.
  • Handled final polish passes for keyboard and controller parity.

Challenge

The prototype already had speed, but it felt unreliable. Inputs could be missed when players jumped at ledge edges, combat timing drifted between encounters, and the project risked reading as a jam build rather than a portfolio piece.

How I solved it

I focused on consistency before adding more content. Buffered input, coyote time, and clearer attack windows made the controls easier to trust. From there I tuned checkpoints and telegraphs so players could recover from mistakes without the pace collapsing.

Outcome

The polished slice kept the urgency of the original jam idea while feeling stable enough to show. The most useful lesson was how much perceived quality can come from timing, feedback, and failure recovery in a very small project.

Gallery