Football Roguelite

An early top-down 2D prototype exploring movement, automatic football projectiles, enemy spawning and a restartable game loop. This page covers the foundation milestone recorded on 16 October 2026.

My contribution · direction & review

My involvement focused on ideas and direction, identifying issues and giving visual feedback. The development log records Codex-assisted programming and editor checks for the milestone shown here.

Goal 01

The initial goal was to establish a modular game loop using replaceable placeholder visuals before adding progression systems or authored artwork. The development log records Codex-assisted implementation and editor checks.

Entities and pitch visuals in this version are generated at runtime. The component structure was intended to support later changes to visuals and gameplay.

Schematic of the top-down pitch with player, fans and HUD overlay
Fig. 1 — Schematic of the playable state. Prototype entities and pitch are generated at runtime from code; this is a diagram, not a screenshot.

Architecture 02

Five modules with one direction of dependency: Core, Player, Combat, Enemies, UI. They communicate through public APIs and C# events rather than shared state.

Decisions

  • RunManager owns run state only — time, kills, end state, restart. It knows nothing about combat or spawning.
  • IDamageable keeps damage interactions extensible without committing to a full combat framework early.
  • Enemy spawning, player control, projectiles and HUD are independent components, so each can be swapped or tested alone.
  • An editor-only startup hook selects Main.unity, which fixed a class of “empty untitled scene” confusion.
Modules
5
Scene
Main.unity
Recorded warnings
0
Recorded errors
0

What works 03

  • WASD movement on a Rigidbody2D with a pitch that has touchlines, a halfway line, a centre spot and a centre circle.
  • Fans spawning only from the four field edges, moving toward the player and dealing configurable contact damage.
  • Automatic shots at the nearest target, with configurable damage, cooldown, speed and lifetime.
  • Enemy health, death, destruction and kill notifications.
  • Run timer, kill count, a Game Over panel and scene-based restart.
  • A runtime-created HUD showing HP, time and kills, plus final values on death.

Verification 04

The 16 October development log records Play Mode checks of directional movement, timer progression, automatic projectiles and the kill counter. These observations apply to the foundation milestone shown here.

A recorded 40-enemy spawn check placed enemies at the field edges. Contact-damage checks reduced health to zero and displayed the end state. A UI pointer-click event on Restart reloaded the scene, restored health and reset run values. These targeted checks do not constitute a full playthrough or a release build test.

The development log distinguishes compilation results from runtime observations and records the fixes made during that milestone.

Outside the foundation milestone 05

  • Object pooling — enemies are destroyed on death for now.
  • Authored art and prefabs — placeholder entities are generated at runtime.
  • Content and progression were outside this initial milestone. The development log records later work that is not covered by this case study.

This milestone provided an opportunity to explore component boundaries and runtime verification. Its placeholder visuals and targeted checks should be understood in the context of an early prototype.