I started making games in Unity at thirteen or fourteen, in the back of a Polish middle school, with my cousin Seba. Every project we started ended in the same place: a terrain, a basic AI that walked towards you, an inventory, a weapon. Then nothing. Not a fight, not boredom, not a better idea. Just a folder that stopped being opened.
For years I filed that under not being disciplined enough. It was the wrong diagnosis, and I know that now because I did it around twelve more times as an adult — same four features, better code, same folder — before I finished anything at all.
The reason those four features are always the four is not psychological. It is structural, and it is almost embarrassing once you see it.
What the four have in common
Terrain. An AI that walks towards you. An inventory. A weapon. Line them up and the shared property is obvious: every one of them can be finished without deciding what the game is.
| Feature | When is it done? | What it assumes about the game |
|---|---|---|
| Terrain | When it looks like ground. | Nothing. Every game has somewhere to stand. |
| AI that follows you | When it arrives at you and does not fall through the floor. | Nothing. It does not need to want anything. |
| Inventory | When items go in, come out and persist. | Nothing. It never asks what the items are for. |
| Weapon | When it fires and something reacts. | Nothing. It does not need a reason to be fired. |
Each has a clear completion criterion that lives entirely inside itself. You can tell when it works. You get the small, real satisfaction of a thing that functions. And at no point does any of them require you to answer the only question that matters, which is what is the player doing and why would they do it twice.
So the work is genuinely pleasant and genuinely productive, right up until the queue of undecidable-free work runs out. Then the next task is no longer “build the thing” but “decide the thing, then build it”, and that is a different job that nobody told you was coming.
The cliff, and why it does not look like a cliff
Nothing fails. There is no bug, no wall, no moment of defeat. The project simply stops producing the feeling it was producing yesterday, and a week later you open something else.
That is the tell that this is structural rather than motivational: abandoned projects do not stop at random points, they stop at the same point. A discipline problem scatters failures across the timeline. A structural problem produces a cliff, in the same place, every time.
The thing you were avoiding is the loop
The loop is the smallest thing the player does over and over: the thirty seconds that repeats for six hours. Place a tile, see the result, place another. Take a contract, fail it, take a better one.
Unlike the four, the loop cannot be built without deciding what the game is, because the loop is the decision, expressed in code. That is precisely why it gets deferred, and deferring it is the single mechanism behind every dead folder I own.
The inversion that works is unpleasant to accept and simple to state:
- Build the loop first, ugly. Grey boxes, no art, no terrain, placeholder everything. The only requirement is that it is playable and repeats.
- Make it boring before you make it good. A boring loop can be improved. A beautiful terrain with no loop cannot be improved into a game; it can only have more things placed on it.
- Add a system only when the loop is worse without it. That sentence is the whole of scope control. An inventory added because the loop needs one is a feature. An inventory added because it was next is a part.
In my case, the game I actually shipped opens on a decision rather than a landscape: you pick a thing to build, the world responds, and the thirty seconds repeats. The terrain came eighteen months later, and only because the loop had earned it.
The version with Seba, and why it matters that we were thirteen
It would be neater to claim the childhood projects were a different problem from the adult ones. They were not, and that is the useful part.
At thirteen, with Seba, we had no deadline, no customer, no cost of failure and infinite afternoons — every condition that motivation advice says you need. We still stopped at terrain, follow-AI, inventory, weapon. Remove every motivational factor and the same four features still appear, in the same order, and the project still dies. That is as close to a controlled experiment as this subject gets, and it is why I no longer believe the discipline explanation.
What we did not have was any concept of a loop. Nobody in a Polish middle school in the early 2010s was going to tell us, and the tutorials we were following were structured exactly like our projects: here is how to build terrain, here is how to make an enemy follow the player, here is an inventory system. The tutorials taught the parts because the parts are teachable. Nobody can teach you the decision.
What actually broke the pattern
Twelve or so projects later the thing that changed was not willpower. Three things changed, and only one of them is about games.
I shipped something small that was not a game. A Windows monitoring app, on the Microsoft Store since July 2026. It is a smaller, duller thing than any of the games I abandoned, and finishing it taught me the part the games never did: what the last twenty per cent actually consists of. Store rejections, an installer, a privacy policy, a support address, a changelog. None of that is visible from inside a prototype, and all of it is the reason prototypes stay prototypes.
I started with the thing that could not be built without deciding. The simulation came before the screens, the screens before the art. Not virtue — I had simply run out of ways to be wrong about this.
I made the game prove it was a game, automatically. There is now a test in which a scripted bot plays four full in-game years and the assertions check that an ordinary player can survive and cannot dominate. That test is the loop, written down in a form that fails when the loop stops being one. I have written about how it works; what matters here is that it answers the question my teenage projects never asked out loud.
The uncomfortable one
The project I finished first was not the project I cared about most. It was the one that was small enough to finish. I spent years believing the opposite order — that finishing the ambitious thing would prove I could finish things — and it is exactly backwards.
Finishing is a skill with its own curriculum, and you cannot learn it on a project large enough to hide the lesson.
A test for whether your current project is about to die
Three questions, in the order I would ask them. They take two minutes and they are uncomfortable on purpose.
| Question | What a bad answer means |
|---|---|
| Could the thing I am building next be dropped into a different game unchanged? | If yes — and if it has been yes for several tasks in a row — you are collecting parts, not building a game. This is the earliest signal and the easiest to ignore, because the work still feels good. |
| Can somebody play sixty seconds of it and want a second go? | If there is nothing to hand them, the loop does not exist yet, whatever the folder size suggests. Sixty seconds, not a demo. |
| What is the smallest version of this I could put in front of a stranger this month? | If there is no answer, the scope is not a plan, it is a wish. If the answer exists but you do not want to show it, that is the real project talking and it is worth listening to. |
The first question is the one I wish somebody had asked me at thirteen. Terrain, follow-AI, inventory, weapon — all four are a yes. We had built four things that would fit in anybody's game, which is another way of saying we had not started ours.
What this does not solve
Building the loop first does not make the project easy, and I would be doing the thing I dislike if I implied otherwise.
- A loop can be genuinely bad, and finding that out early is the point, not a failure of the method. It is still unpleasant.
- Some genres hide their loop. A narrative game's loop is read, choose, see the consequence, and that is harder to grey-box than place, see, place.
- Finishing still takes the time it takes. Mine took eighteen months of evenings after shifts, and no ordering trick compresses that.
What it does buy you is that the project dies, if it dies, in week two rather than month eight, and with a clear reason rather than a folder you stopped opening. Across twelve projects that difference would have been worth years.
Questions people ask about this
Why do solo game projects always stop at the same point?
Because terrain, a follow-AI, an inventory and a weapon share one property: each can be finished without deciding what the game is. They are self-contained, they have clear completion criteria, they feel like progress and they ask nothing of you. When the next task finally requires a decision about what the player is actually doing, there is no buildable work left that does not first need to be decided, and the project stops. It is structural, not motivational.
How do you actually finish a game as a solo developer?
Build the loop before the systems. The loop is the smallest thing the player repeats, and unlike terrain or an inventory it cannot exist without a decision about the game, which is exactly why it gets deferred. Make it playable and boring first, placeholder everything, and add a system only once the loop is worse without it. Then ship something small and real to actual people before you believe you can finish something large.
Is it a discipline problem if I never finish my games?
Almost certainly not. The evidence is that the abandoned projects stop at the same place rather than at random points: a discipline problem scatters failures across a timeline, a structural problem produces a cliff. I had no deadline, no cost of failure and infinite afternoons at thirteen, and the projects died in exactly the same spot as the ones I built as an adult after a work shift.
What is the test for whether a project is about to be abandoned?
Ask whether the thing you plan to build next could be dropped into a different game unchanged. If that has been true for several tasks in a row, you are accumulating parts rather than building a game, even though everything still feels productive. The follow-up is whether anyone could play sixty seconds of it and want a second go.
Should I use a tutorial series to learn game development?
For the parts, yes, and they are good at it. Be aware of what they structurally cannot give you: a tutorial teaches terrain, an enemy that follows the player, an inventory system, because those are teachable in isolation. Nobody can teach you what your game is, so a curriculum made of tutorials produces exactly the four features in this article and then stops. That is not the tutorials being bad. It is a gap you have to know is there.
Who is Marcin Firmuga?
A solo developer from Radom, Poland. I started building games in Unity at thirteen or fourteen with my cousin Seba, and those projects always ended at the same four features: terrain, a basic AI that follows you, an inventory and a weapon. I abandoned around twelve projects before finishing anything. I now build PC Workman, a Windows monitoring app on the Microsoft Store since July 2026, and Scaling Laws, a management simulation with 1,624 automated tests — both in public, including the parts that do not work.