In this article, I will identify two traps that many indie game developers fall into that either prevent them from finishing their projects or extend the length of the development to a point where there is tremendous pressure for the game to succeed. I call these traps "death loops" because of the fatigue and burnout they can cause (and how easy it is to get stuck in them). The article will also offer some suggestions on how to break out of these loops.
"Finishing games gets easier with each game you finish, and the more games you finish, the better you will understand what it takes to make a successful game."
That's been a basic mantra of mine for awhile now. Certainly, we all know of a developer or two that released a smash hit after 10 years of development, but it's a model that's hard to replicate and dangerous to follow. Instead, I think it makes more sense to treat those stories as longshots and teach game development more like a craft, discipline, or vocation - something that can be practiced in a more steady and consistent way. To that end, I want to arm new developers with the knowledge they need to finish their first few games in a timely fashion in preparation for a long and healthy career.
Over the years, I've noticed two particularly bad loops that new developers tend to get stuck in. It's rarely for lack of hard work or technical skill - I think that's the most frustrating part about these loops. Imagine running a marathon but you're running in circles instead of toward the finish line. No matter how strong you are, if you don't move forward you'll eventually have to abandon the race altogether.
In this article, I'll not only outline what "death loops" are and the pressures that cause them, but also offer some suggestions about how to break out of them. However, the proper solution for each person is going to be uniquely tailored to their personality and their project. And, as always, if you're satisfied with your current situation, there's no need to change things.
(Image taken from the Simpsons episode "Last Exit to Springfield".)
In 2002, my friend Jon Perry and I released Eternal Daughter (pictured below) as freeware after two years of on-and-off development. These days, two years of dev time for a Metroidvania seems almost quaint, but before Eternal Daughter our projects would take at most a couple months of work. Finishing that game was a significant milestone for us and it also made a big splash in the Klik & Play community that we were a part of (Eternal Daughter was made in Multimedia Fusion, a more advanced version of Klik & Play).
Jon and I never made another game using Klik & Play tools, but because of my fondness for the scene, I continued to follow it for many years, watching with pride as several ambitious games inspired by Eternal Daughter were announced, one after the other, with exciting trailers and demos. I distinctly remember reading comments about one of these games being an "Eternal Daughter killer", alluding to its technical achievements over ED. I always thought it was cool that we made something worth trying to kill!
Unfortunately, not a single one of those games ever released! Instead, I noticed that the devs would continuously remake their first few levels. The sprites would be redone to look nicer. Or perhaps the base code would get rewritten to allow for more intricate mechanics. In some cases, new content would get added, like fancier combat systems or an overworld map. But since these were never part of the original plan they only expanded the projects laterally instead of moving them forward. These devs were caught in an endless loop where their skills would improve enough that they couldn't bear to finish the game with the work they had already done.
Eternal Daughter has plenty of awkward moments - it was the best Jon and I could do at the time as hobbyists just out of high school. But the game was complete and generally maintained its quality level from beginning to end. No matter how much better the first levels of those games were than Eternal Daughter's first level, none of them would really have a chance to "kill" ED if they never released! And maybe more importantly, finishing ED made it easier for Jon and I to finish even larger and more ambitious projects in the future.
The Loop of Restarting is a danger in any long-term creative project, but video games, as a complex mix of traditional arts and software engineering, are particularly at risk for it. The longer a project goes on, the more you learn and mature, and consequently, the worse the temptations become. On top of your own improving skills, you'll also be tempted by the new and improved tools that emerge and promise that, after some initial rejiggering, your productivity will soar. New games will release during your development, too, adding extra pressure to "keep up" and stay competitive.
The problem is that these temptations never go away. There will always be a better way to do it, a better tool, more games coming out. At some point you either learn to live with it and release your game or simply stay in the loop forever.
Learn how to properly scope. The developers of those unfinished games were all multi-talents who were skilled at art, design, and programming, which is why they were able to singlehandedly put out such amazing trailers and demos. Unfortunately, what they didn't realize is that the best metric for scoping a project is not technical skill, but the scope of the previous games you've finished! By the time Jon and I started on Eternal Daughter we had released quite a few smaller games together and knew what was involved. We still underestimated the project, but our previous experience finishing games gave us a much better idea of how far along we were and what was required to get to the end.
Save most of the polishing for the end. The order that you work on the various parts of a game also makes a difference. I find it best not to spend too long on any one part of the game until the entire game is playable from beginning to end. This is the suggested way to create almost anything: to write a story you start with an outline and then a rough draft; to paint a painting you start with a sketch. That way you can see your creation as a whole and it will give you a better sense of what you need to do to finish. I also think it's easier to, for example, sketch out a second level if the first level is also somewhat rough. Once you put your brain into polish mode it can be hard to return to sketch mode.
Look beyond this one game. What has helped me a lot over the years is reminding myself that the game I'm currently working on is part of a long chain of games. This won't be your only chance to say something through your art. It's not even your only chance to express this exact idea - after all, finishing a game doesn't mean you couldn't remake it later (or put out a sequel)! My advice is to abandon the goal of making an objectively great game. Instead, focus on making the best game you can at the time and find joy in your personal growth. When I look back at my old games like Eternal Daughter, each one feels like a time capsule, reminding me of that time of my life. I see a less mature creator... which is great! I'm proud to have improved at my craft.
Get hooked on the deeper satisfaction of finishing games. Like anyone else, I've left behind plenty of unfinished projects, too. But while those are fun to look at, also, I find that the memories associated with them are much more faded. The games that I finished and released, that other people played and connected with, taught me much more and had a much larger impact on my life. If you do find yourself wanting to start over so badly that you can't keep working on the project in its current state, I'd recommend shelving the idea and starting an entirely new project with a much smaller scale. Come back to it when you're ready for it.
The Loop of Polishing is similar to the Loop of Restarting, but instead of restarting a game endlessly, it's about polishing a game endlessly. And whereas the Loop of Restarting takes place in the beginning of the project, the Loop of Polishing tends to happen toward the end of the project, although honestly it's a danger wherever polishing is done (some devs begin heavy polishing while they're still prototyping game mechanics). Besides, it's easy to think you're closer to the end than you actually are.
But what are we talking about when we say "polish"? Generally speaking, we're talking about smaller improvements that can be critical but are not truly essential. Polish might include adding a subtle hit effect to a collision to heighten the feeling of the impact. Or making a bit of UI more friendly. Or fixing a rare glitch. Or even adding something large enough to be called a "feature" that wasn't originally part of the plan. The exact magnitude of what is considered polish can vary quite a bit from team to team and project to project.
Because polish is so vaguely defined and yet all-encompassing, it's hard to plan around. It's also hard to know when to stop adding polish, because there always feels like something you could improve at least a little bit. This is not a problem restricted to video games - as the old adage goes, "A work of art is never finished, only abandoned." But once again, the complexity of games creates extra challenges. More complexity means more moving pieces means more places where polish could potentially be added.
Just wanting to make the best game possible is a strong enough temptation to keep polishing indefinitely, but there are other external factors that fuel this insidious death loop. One major factor is a form of sunk cost fallacy - the idea that what you've already invested in the project (your sunk costs) justifies sinking more time into it. And the longer a game is in development, the more you feel like it has to succeed to justify its development time, which causes you to spend even more development time on it.
Developers are also encouraged to stay in this loop by sympathetic feedback from family, friends, and other game developers. Out of politeness, this type of solicited feedback usually comes in the form of "constructive criticism", where the person tells us what they like about our game and suggests a few things we could reasonably do to improve it. Unfortunately, while constructive criticism is motivating and useful, it rarely reveals how compelling our core concept and basic execution are, and without knowing that, it's hard to know how much value polishing will add to the game.
But maybe the main reason this loop is so easy to stay in is that we actually don't want to release? I know, it seems unintuitive. But the release of a game is also the moment of judgment and of reckoning... and there is comfort in continuing to work and make improvements, grinding against familiar problems behind-the-scenes. Many developers experience a feeling of loss and aimlessness post-release (at least once the patches and ports are done). So another name for this loop could be called The Loop of Procrastination.
Understand how polish benefits your game. This may seem counterintuitive, but polish is not a great way to broaden the appeal of your game - comparatively, the core concept and basic execution are much more important. For example, if the overall art style of your game is unappealing, then adding juicy effects and other little details will probably not translate into more sales. A mud pie won't taste good to most people no matter how much frosting you put on it, right? Of course, there is always some bare minimum of polish that is required to ship a successful game. And some games are based heavily around a polished aesthetic and experience - for those games polish matters more. But I'd warrant that the final 1/4th or so of most early indie projects is spent on polish that brings a little extra happiness to players that were already convinced but probably has a negligible effect on undecided ones.
Learn how to analyze feedback properly. "Don't read the comments" is a common refrain, and for good reason - they can get ugly. Unfortunately, that unsolicited, raw honestly is also where you'll find the clearest insight into how well your game is going to do. If you release a trailer for your game and receive a very mild reception in the comments and on social media, extra polish will probably not turn that around. In my opinion, that's the time to start thinking about winding down a project and releasing it earlier than planned so that you can quickly move on to the next idea. On the off-chance that the game is an unexpected success after release, you can still build upon it with expansions or sequels.
Every project, from the smallest indie game to the biggest AAA game, requires some compromise because time and resources are limited. Generally, the choice is between more polish, more ambitious game design, or shorter development time, and how much of each you can choose depends on your experience level and your available resources. A lot of new developers who have little experience or resources choose to create very polished, ambitious games, resulting in protracted development times (5-10 years) where funding runs out repeatedly and there is tremendous pressure for the game to be a smash hit. This is also the perfect environment for burnout.
One of the biggest strengths of indie devs is our freedom, which allows us to work in our own way, to make decisions swiftly, and to make bold choices that AAA studios might not be able to. It's the lone wolf approach versus the large army approach. Unfortunately, it also means that we're free to spin our wheels with very little accountability.
I've already suggested some mental adjustments and project management tips that might help you avoid a death loop or pull yourself out of one. Instead of reiterating all that, here's a thought experiment using an example we're all familiar with: from 1985 to 1988, Nintendo released four Super Mario titles on the NES/Famicom, steadily building up their reputation and their understanding of the genre with each release. Imagine if they made it halfway through SMB1's development and decided to start over to make SMB2? Or tried to go straight to a game of SMB3's scale without the experience of the previous ones? Would the overall outcome have been better or worse, you think?
(Screenshots Source: MobyGames)
As indies in the 2020s, yes, it's true that our situation is different from that of Nintendo in the 1980s, so the point is not necessarily to make 4 games in 3 years, but to plan on working your way up through steady and consistent releases rather than one long and self-destructive longshot. To use a baseball analogy, start by trying to get on base and not by trying to hit home runs. If you get good enough at hitting the ball consistently, the chances of hitting a home run go up tremendously. There are plenty of examples of this in the modern indie space, as well. For me, personally, I feel like it was essential to release the first Spelunky game, Spelunky Classic, as a freeware title with simple pixel graphics. Had I attempted to go straight for Spelunky 2 (my current project), I have to believe the road would have been many times more challenging, stressful, and uncertain.
Something else to consider is that avoiding crunch alone is not enough to avoid burnout. While there's no doubt that extended crunch takes a terrible toll on developers, so does being on a long project - the longer it goes, the more it weighs on you mentally, even when you are "taking a break". It's hard for it not to consume you after awhile. Most often, though, long projects and extended crunch go hand-in-hand. So take care of yourself both in the short term and the long term by trading death loops for a circle of life - where one project begets another in a natural and healthy timeframe.
That's the end of this article! From here, you can return to the index.