Harrison Stephan
All work

C++ Game Prototype

Room Run Shooter

A small top-down extraction-shooter prototype built around an explicit frame pipeline and a readable three-room run.

Proof of C++ stateful systems, frame-order discipline, collision boundaries, and prototype scope control.

01 / Problem

A room-run prototype needs combat, loot pressure, extraction, and raid consequences to remain coherent while the feature set grows.

02 / What I built

Built a C++/raylib prototype with a three-room run, weapons, grenades, four enemy types, pickups, early or final extraction, an in-session stash, and pre-raid purchases.

State graph for the Room Run Shooter raid lifecycle and per-frame gameplay pipeline.
Project state map · raid lifecycle and frame pipeline

System boundary

How the pieces connect.

One frame snapshots input, advances small systems over aggregate run state, resolves collisions and room decisions, then renders from the settled state.

  1. 01Input snapshot
  2. 02Player and combat
  3. 03Enemies and projectiles
  4. 04Collision resolution
  5. 05Room / extraction state
  6. 06Render

Engineering decision

Prototype architecture should make the experiment easy to read before making it easy to extend.

Tradeoff

Plain state and small systems keep the prototype direct and testable, while deliberately deferring extensibility, external room data, and editor tooling.

What happens next

External playtesting and tuning remain the next documented phase; no public playtest outcome is claimed yet.

Implemented proof

What can be evaluated today.

All documented prototype feature phases are implemented, while graphics and content remain intentionally minimal.

  1. 01

    Implements a three-room run with optional room-two extraction and final-room extraction.

  2. 02

    Includes pistol and shotgun state, dash, grenades, four enemy types, and multiple pickup types.

  3. 03

    Separates per-raid state from an in-session player profile and stash.

Source proof

A decision visible in code.

Room Run Shooter / C++Engine/Core/src/run_game.cpp
  1. update_player(state.player, input, delta_time, current_room.bounds);
  2. update_weapon_pickups(state);
  3. update_loot_pickups(state);
  4. update_weapon(state.player.weapon, input.reload_pressed, delta_time);
  5. try_fire_player_weapon(state, input, muzzle_position, aim_direction);
  6. try_throw_grenade(state, input, aim_direction);
  7. update_enemy_attacks(state, delta_time);
  8. update_bullets(state.bullets, delta_time, current_room.bounds);
  9. update_bullets(state.enemy_bullets, delta_time, current_room.bounds);
  10. update_grenades(state, delta_time, current_room.bounds);
  11. resolve_collisions(state);
  12. update_room_state(state);
  13. update_room_transition(state);
  14. update_extraction(state, delta_time);
  15. update_feedback_timers(state, delta_time);
  16. render_game(state, assets, profile);
Line 14Frame order stays auditable.

Collision and room state settle before extraction, feedback, and final rendering.

Next case study

NovionOS