When Programming is Too Much Fun or How I learned to Wear All Those Hats

We are a small company. Broken Rules has a 5.5 person core team. We design, implement and publish our own games. We maintain our own engine in order to minimise external dependencies. We rely heavily on social networks like Twitter and Facebook for marketing, where we maintain our own community. We are a true indie company in that we bootstrap where we can and try to obsessively control every aspect of our games, from idea to release and beyond. To be able to pull this off with such a small team, everyone has to wear a couple of hats. This article is about my hats and how I shuffle them. This is a very personal post. It's about me and how I manage to move from one role to the next. It might not apply to you at all or it might give you a hint on how to get yourself to solve some of the many challenges of indie game development. It's up to you.

I've got a doctoral degree in computer sciences. I've programmed Perl and C on a Compaq iPaq PDA running Linux to teach boots to talk. I've used Pure Data and microcontrollers to turn a pinball machine into a musical instrument. My background is in low-level programming for small devices. Close to the hardware, that's where I come from. I am not a god of programming, just infinitely pragmatic and focused on getting stuff working, no matter how limited the environment is. For me, the fun in programming is the fun of problem solving. That's why I like to optimise existing code. Measure, isolate the problem, think, try out an optimisation. Repeat until successful (enough). It's also why I like to write tools. You roughly describe a problem area and quickly find a solution for that. You get immediate response from the team. Iterate until good (enough). The fun I find in these tasks goes so far that it prevents me from shifting to the other roles I play. The instant gratification of problem solving offers much more motivation than the delayed response you get from finishing a marketing task. You code. You compile. It works or it does not. Instant feedback. You post on Facebook. You wait for days. Your "results" are vague and informal. Delayed, fuzzy feedback. Marketing has a different rhythm than programming altogether. So has story-writing and setting up server infrastructure.

Sometimes when I switch gears I feel like an addict getting off his favourite drug. I can sink hour after hour into tiny optimisation problems or a nifty user interface challenge without realising it. The only way to put on the marketing hat is quitting the IDE for a week and working with the executable of the game – that includes the level editor – for the time being. Only when I do not see those tempting lines of code is it that I can fully concentrate on my other tasks. Interestingly, spreadsheets and diagrams work as a substitute for coding. I can get into those when my brain is so drained that I can neither focus on creative work nor on code. It's even worse for story writing. I love writing and it's one of my favourite parts of game development. I'm infinitely grateful that I can play the role of the lore master in our team. It needs a peculiar state of mind to get into "writing mode" and an even rarer kind of ecstasy to keep up the flow. Having easy to solve programming problems at hand is a surefire way of preventing me to enter that state of mind.

So, to conclude this, my only solution for this dilemma is to shut down the IDE. Keep it off for a whole week. Do all the other tasks that need to be done. Fire up the web server and try out the new forum software. Hack at the CSS script. Finally add the right graphics to the controls menu item. Get lost in the story wiki. Make some truly worthwhile Facebook entries and schedule some Tumblr posts and tweets. Then, with a rested mind, indulge in the bliss of coding again.