Three years into Asura's Thread, seventeen scope resets, and one nervous system that has stopped responding to chai after 3pm. If you want to know how to avoid burnout as an indie game developer, I can tell you what the blog posts say, and I can tell you what is actually true. They are not the same list.
Why does indie game development burn people out faster than studio work?
Because there is no floor. In a studio, someone else decides when you are done. Someone else decides the scope. Someone else carries the guilt when the build breaks at 2am. When you are solo, every decision is yours, every delay is yours, every moment of stagnation is yours to explain to yourself. That is not a bug in the indie model. It is the feature that attracts people and also the feature that destroys them.
The IGDA Developer Satisfaction Survey found that over 40% of game developers reported working unsustainable hours. Indie developers skew worse, because at least studio devs go home. We live at work. Our work lives in our apartment. I can see my dev machine from my bed. I have thought about moving it into the bathroom to create physical separation, which should tell you something.
What does burnout actually feel like for a solo dev?
It does not feel like exhaustion, not at first. It feels like disgust. You open the engine and everything in the project looks wrong. The systems you built last month look like they were written by someone who did not understand the game. The art direction you spent six weeks calibrating looks amateur. The premise you started with looks thin.
This is not burnout. This is late-stage proximity blindness, and it is different. Burnout is when you open the engine and feel nothing at all. Not disgust, not frustration, not even the old excitement that has been decaying for six months. Nothing. That is when you are in trouble.
I hit that state at the two-year mark. I opened Godot on a Tuesday morning and sat there for forty minutes doing nothing. Not thinking about the game. Not avoiding the game. Just absent. The game had become a null reference. That is what burnout looks like from the inside, and nobody warned me it would be that quiet.
How do you prevent scope creep from killing your project before burnout gets the chance?
Scope creep is the first mechanism. It operates like a memory leak — you cannot see it happening, and by the time you notice it, you are already crashing. Asura's Thread started as a 15-hour action RPG with a strong narrative core and one mechanic: time-shifted combat that let you replay the last 8 seconds of any fight. Clean. Contained. Achievable.
By month fourteen it had factions, a crafting system, three companion characters with full dialogue trees, a cooking mechanic that was apparently necessary for the lore, and a second region I added because I thought the first region was boring. None of these were wrong decisions individually. As a system they were a debt I had not agreed to carry.
The fix is not discipline. The fix is treating your design document as a contract. Every new feature has to pass one question: does this make the core loop better, or does it make me feel productive? Feeling productive and being productive are different operations. I know this. I still get them confused.
What keeps you actually working when motivation is gone?
Not motivation. Motivation is an unreliable dependency. You do not ship a game on motivation; you ship it on systems.
Here is what works for me: a two-hour daily minimum with no target other than the session starting. The session can be bad. The session can produce one line of code that I will delete tomorrow. The session has to happen. The habit is the deliverable, not the output. This is a Riyaz principle — classical dance practice, the discipline of the daily repetition that Bharatanatyam runs on — and it maps to code the way it maps to footwork. You do not rehearse because you feel like dancing. You rehearse because you made a commitment and your body is a system that requires maintenance.
The other thing that works: I get up and walk to the chai stall on the corner of 80 Feet Road most mornings. Not for the chai specifically, though it is excellent, and not for the noise of Koramangala waking up, though that helps. For the interruption. The brain needs a problem-free twenty minutes where it can process in the background. Breakthroughs in Asura's Thread's narrative structure have arrived during that walk more consistently than they have arrived during any scheduled design session. This is not mystical. This is how diffuse thinking mode works, and there is substantial cognitive science behind it.
How do you deal with the comparison problem?
Badly, and then slightly less badly over time.
Hollow Knight is the comparison that haunts everyone in this space. Two people, three-ish years, and the result was a game that redefined the genre. The math on that is demoralizing if you let yourself do it, and the problem is that you will absolutely let yourself do it, usually at midnight, usually when your own project is in a bad state. You will open Steam, look at Hollow Knight's reviews, and sit with a very specific kind of despair.
What I try to remember: Team Cherry had each other. They had a second person in the room to say "this is good" or "this is not working." That external signal is something a solo dev does not have, and its absence costs far more than the additional development time you carry alone. The comparison is not fair. It is also not one you can stop making. The best you can do is catch yourself making it and note that it is not an analysis — it is a symptom.
What actually helps: TIGSource forums, local game jams, the Bangalore game dev community that gathers in different cafes in Indiranagar and Koramangala. Other devs who can look at your build and tell you whether what you made is actually bad or whether you have been staring at it too long. That external signal is not optional. It is a structural requirement.
What is the role of money pressure in solo dev burnout?
It is the accelerant. Every other burnout factor is made worse by financial precarity. The anxiety is a background process that runs at all times and consumes resources that should be going to the work. I do not have a clean answer for this because there is no clean answer. I am working on Asura's Thread with savings that have a finite duration and a part-time contract that extends the runway.
What I will say: the devs I have seen crash the hardest are the ones who went full-time too early, before the runway was genuinely secured, and then could not think clearly about the game because they were thinking about rent. The financial anxiety colonizes the creative space. If you can keep a part-time income stream without it consuming the time you need for the project, do it. Your future self will not resent the slower pace. Your future self will resent the panic.
How do you know when to take a real break versus pushing through?
When the thing you are making starts to feel like a document rather than a game. When you are adding features because the feature list has a gap rather than because you want to play that feature. When you are making decisions by asking "what would a game designer do here" instead of asking "what do I want here."
Those are the signs that you have detached from the work. A long weekend does not fix that. A week away from the engine — not reading dev blogs, not watching GDC talks, not "just checking" anything — does something. I have taken three of those in three years and come back each time with a revised understanding of what the game actually needs.
The break does not reset your tiredness. It resets your perspective, which is more valuable.
How do you stay alive in this work long enough to finish?
You accept that the game will take longer than you planned and longer than you want, and you build a life around the development instead of collapsing your life into it. I keep Bharatanatyam practice in my week not because it makes me a better developer — though the concentration training probably does — but because it is the part of my life that has nothing to do with whether Asura's Thread ships. It is the part that exists regardless of the build state. That independence is worth protecting.
I write letters I do not send. That is mine and not necessarily yours. But the principle is: have a private practice of some kind that processes the parts of this work that cannot be processed by working more.
The devs who finish are not the most talented. They are not the ones with the best systems or the cleanest code or the most efficient sprints. They are the ones who found a way to stay in the room. Everything else is a tool in service of that.
If you want to argue about burnout, scope management, or whether the crafting mechanic I added in year two was a mistake (it was), I am at my desk in Koramangala most days. Come find me. I am not warm but I am honest, which is more useful.
