From Prototype to Framework

 The Journey Behind My Miner Game

My project started as a small experiment: a fixed-board card game prototype. The goal was simple  make something playable. But very quickly, the project began to evolve in unexpected ways.

1. When a Simple Prototype Stops Being Simple

As soon as I started coding, bigger questions appeared:

• How should actions be organized?

• How should components behave?

• How can I write this so it won’t break later?

• Can this code be useful for future games?

Trying to answer these questions pulled me out of “quick prototype” mode and into deeper architectural thinking. I didn’t want rushed, messy code that would cause problems later  I’d been there before. But trying to avoid future problems too early created its own kind of paralysis.

I kept aiming for a solid foundation I could reuse, but that ambition constantly pushed me backward. Every step forward exposed my own imperfections and stirred up the familiar anxiety of not being good enough. I’ve spent more time worrying about how to express this than actually building the next part of the game. Writing this is my way of breaking that cycle and taking the next step.

Where I Am Now

Many commits later, the project has transformed:

• The card-game idea is gone no more tapping, to give way to the  WASD movement.

• Instead of messy random generation, I now load levels from a simple ASCII map file.

• Each symbol in the file maps to a tile or object in the game, giving me a clean, controllable way to build levels.

• Two core state machines one for the game flow  and another one for better control sprite animations. 

This project has changed shapes more than I expected, but each shift has pushed it toward a clearer structure and a better game. I’m still building, still learning, and now finally moving with purpose instead of getting stuck in the details. The miner game is taking form  and so is the foundation for whatever comes next.