A Day in the Life of a Roguelike Developer: Burnout

I’m experiencing a degree of what many people might describe as developer burnout: I’ve just released a major point release of Unangband and I’m finding it difficult to focus on what needs to be done next. My motivation level is low, my output has dropped significantly – noticeably more so on this development blog than in terms of code written; and I’m wondering if I should continue developing the game at all.

Before you panic and beging deleting your now unsupported copies of Unangband, relax a little. I am conscious of what’s happening, because this has happened many times before over this game's lifetime (more than 10 years and counting). Burnout is a natural part of the creative cycle, and something you should take in your stride. It’s not the end of the world, or coding, as you know it.

Which is why it’s disheartening to see at least two other roguelikes: Umbrarum Regnum and T.o.M.E., contemplating terminating active development. I’m not familiar enough with the inside story for why the developer of Umbarum Regnum has decided at present enough is enough, but I have passing familiarity with T.o.M.E. which has gone through an extended delay in the release cycle between a stable and playable release (version 2) and an ambitious, far reaching rewrite with no end in sight (version 3).

Roguelike development is an unusual activity: you’re working in a game genre with a very limited player base, but paradoxically, wide reaching recognition and respect. Every time a roguelike gets mentioned in more mainstream forums, there is much recounting of anecdotes and day in the life of tales (almost always featuring Zangband, recently usurped by Dwarf Fortress) – and only a few complain about the obtuse interface and limited graphics. At the same time, roguelike developers and players are in this insular, tight-knit community which is blighted by over ambition (leading to failure) and self-criticism (leading to inactivity). Over the last few years, aided greatly by the camaraderie engendered by the 7 day roguelike competition, the community has flourished, and been boosted to an extent by the recognition and rise of independent (indie) games in general.

But no other genre seems to have the length of development cycles that roguelikes have: Angband has been in development for nineteen years, Dwarf Fortress has a public development plan that will take at least five more years to achieve and the next version of NetHack will be out real soon now. Not in the sense of Duke Nukem real soon now – but there is a distinct possibility that some of the gaps in development release will lead to some roguelikes being stillborn before achieving a officially sanctioned version 1.0 instead of a periodic update to a remote SVN repository (a version control system).

For those of you who are in the midst of development crisis, I’d like to share some burnout recovery tips – having periodically gone through this process.

1. You should have natural absences as a part of the development cycle. Given its duration for roguelikes, these are likely to be long: holidays, weddings, child birth. I have fond memories of sitting in an Internet cafe in Ios, Greece, next to the pool, trying to debug an edit file preventing someone from winning the game, while I was ‘on holiday’ when I first travelled to Europe. The fact I was working on the game during a self-imposed absence was a good sign that I was still fresh and enthusiastic.

2. Be sure to have one or more trusted lieutenants to shepherd bug fixing during your time away. Development is a meritocracy rather than a democracy: but that doesn’t stop you from involving others as spokespeople, bug triage, and as a support network. Some of these people don’t have to even understand what you’re doing – a trusting partner, friend or bemused work colleague is still enough to provide a measure of respite, if not respect, for what you’re trying to achieve.

3. Your brain doesn’t exist in a vacuum – no matter what the mind/body dualists say. You need to step away from the keyboard and remain physically active. I swim, lift weights, walk – and you’ll end up thinking about what you can do in the next coding session while you work out. Make sure your computer isn’t too far from where you exercise to take advantage of that post-workout inspiration.

4. Program when you’re interested in programming. Don’t feel like you have to do anything. Although discipline is important – you need to actually write code after all, this is supposed to be an enjoyable hobby, not work. I have never found setting a target useful – work on what interests you now, and what you need to do will sort itself out some other time.

5. There is nothing worse than sitting down whilst tired and trying to code: the bugs per line of code goes up, way up (And forget drunk programming – although that’s where more than a few design decisions have been made).

6. Don’t measure yourself by your failures. And don’t dwell on them.

7. Get used to the natural rhythms of how you work. Listen to your body – learn when to snack, when to load up on the caffeine and do an all night session, and when to just sit there and churn out documentation, or even play the game.

8. Contribute to something related to your project, but which you’re not directly responsible. Even though I set up the procedural wiki, I only treat it like a part time exercise and let some of the other contributors do more of the heavy lifting. That way, I can still feel like I’m being productive while I’m not working on Unangband.

9. Don’t spend too much time talking to other people about what you’re planning on doing it, and just do it. Unfortunately, when it comes to computer programming, a problem shared is a problem doubled (see the Mythical Man Month) – ultimately you’re the only one responsible for how well you do. That’s not to say communication isn’t important: a good indication of whether an idea is feasible is whether you can explain it clearly. But you can do this explanation asynchronously: by documenting or blogging the idea instead.

10. The only way you can solve a problem is by exploring the problem space with code. This may mean writing sub-optimal code now, instead of designing for later, that ends up in the code base. Don’t worry. As long as you get the user interface right, you can always come back to it, and cause code regressions at a later date.

You’ll notice that most of the above recommendations are preventative in nature, and most are just practical programming advice, instead of specific burnout busters. Prevention is the best way to delay the onset of burnout, but you'll ultimately still suffer its effects. But provided you accept the natural process of ups and downs while developing, you’ll see that this state is just one end of a continuum, one which you can recover from, despite what you may think at the time.

Even if you stop developing your roguelike for good, don’t despair. Cory Doctorow, science fiction writer, finds inspiration in the possibility spaces of these ‘abandonware worlds where only a few players remain and the gamemasters have stopped paying close attention. What odd maps might be drawn as the die-hards explore the outermost reaches of these worlds?’