Indie Game (in development)

The problem

Games are the hardest kind of software I know: real-time systems, state everywhere, and an experience that has to feel good, not just work. I wanted a long-running project that forces me to grow as a programmer and a designer at the same time.

The approach

I'm building it in small vertical slices — each one takes a single mechanic from idea to something playable before moving on. That keeps scope honest and means there's always a working build, the same discipline I apply to data pipelines.

How it works

1. 01

   Prototype

   Core mechanic implemented with placeholder art to test whether the game loop is fun before investing in anything else.

2. 02

   Systems

   Building the underlying systems — state management, entities, saving — with the same care for data modeling I use at work.

3. 03

   Art & feel

   Iterating on pixel art, animation and game feel so the mechanics read clearly on screen.

4. 04

   Playtest

   Regular small playtests to catch what's confusing or boring early, then adjusting the design.

Stack

Engine

Game engine (TBD)

Language

C#

Art

Pixel art, self-made

Status

In development

What I learned

• — Game state is a data modeling problem — my pipeline experience translates surprisingly directly.
• — Vertical slices beat big design documents: something playable always teaches more than a plan.
• — Feel is measurable: small timing and feedback changes have outsized impact on how a mechanic reads.

Outcome

• ✓ A playable prototype with the core mechanic working end to end.
• ✓ An ongoing devlog of design decisions I can share as the project matures.