Tuesday 23 June 2009

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?’


Mingos said...

Hello Andrew.

I didn't expect to see UR mentioned on your blog - thanks :).

As for why I decided to terminate active development, there's not much philosophy behind it. I'm completely demotivated at the moment. Real life has pretty much sucked me dry of all passion for anything, not only coding. These are the wonders of emigration, I guess. I'm hoping to regain some energy after returning to my home country and restarting a half-normal life.

Jonathan Stickles Fox said...

One of the posters in the Bay12Games Curses subforum recently referred to Liberal Crime Squad as a "roguelikelike", a term I found endearing and particularly apt -- like Dwarf Fortress's Dwarf mode, it lacks many of the trappings of roguelikes, but maintains a console aesthetic and grinding difficulty that makes it feel like one when you play it. The experience of working on it is also similar; though the audience is small, the work is rewarding, and seems to garner disproportionate admiration and respect from players.

Personally, I'm extremely burnout-prone, and my philosophy is to simply embrace this burnout: Every release of Liberal Crime Squad that I build could very well be my last, and I only ever even think about the game if I actually feel like it. I completely walk away on a regular basis and let it collect cobwebs. I accept this, and when anyone asks when the next version is out, I simply tell them I'm not working on the game at all at the moment (and I'll share what I AM doing with my time, usually college and video game related), and tell them the next time a release comes will be the next time I get the itch to work on it. I don't try to push myself to stay on the project; the wind blows and I bend. It's just a hobby for me.

I welcome pretty much anyone who can so much as try to hack some code together to work on LCS; and why not? I didn't make the game myself, I took it over after Tarn and Zach Adams abandoned it to work on bigger and better things. When others come in, it's usually not bugfixing and other maintenance tasks (though a few do that), it's often pet features and design ideas that people want in the game and are willing to work on themselves.

Anyone who is willing to put the extensive effort into it to really maintain LCS, on a more consistent basis, could easily replace me as the main developer, and I have no problem with that. Yet time and again, when I think someone might actually do that, it turns out their passion is even more transient than my own. I've been a horribly absent stepfather to the game, but somehow I keep coming back, and that seems to make all the difference.

Anonymous said...

You are right in talking of ... development cycles. For LambdaRogue it's usually this way:

A long time in which I don't have the time or interest for caring about further development of the game. This time is filled with other interests or my job.

Either by forcing myself to do so or by inspiration of other games, I start to play my current development version of LambdaRogue. Usually this raises my interest in the game and I enjoy to think about the game. This is the phase in which I get new ideas, find lots of bugs etc.

This phase initiates a rather manic programming phase in which I can code over hours and hours. After one week or two, I get physically tired of this, so I come to a feature freeze. This creates a todo list.

The last phase is implementing all things on the todo list, and often this part is not very enjoyable.

After the last phase, a new release is finished -- and I'm finished, too, coming to phase 1.


Unknown said...

Hey, how timely. I'm also in a lull, not willing to call it a burnout yet -- Wayfarer has clear needs but I just don't want to go down those stairs again, right now. I've been coping by coding smaller things, like a vertical space shooter. It's great to have a long-term project on simmer, but why burn yourself out? You're giving your time and energy away to the world, with these open-source / freeware programs. Congrats on getting UnAngband to the point it's at! -- Ben

Ido Yehieli said...

I can relate to that all too well myself- I can never seem to work on one project for more than several months without getting tired of it and not touching it for months/years at a time (if at all).

Brian Jeffears said...

Yes, I can see much danger in burnout in the grand scheme of things indeed. I could see how it could strike me too in the future based on everybody's experiences shared here, but somehow the more likely adversary in my endeavor seems determined to be of forces outside of the games entirely knocking me for a loop and off the rails.

I would imagine having a net of people, well wishers, helpers, enthusiasts, or even just people that know you are alive and what you are somewhat up to would help to keep the embers stoked or at least bounce back a bit sooner. Vacuums tend to be less than stellar...