How Long Does It Take to Make an Indie Game?

A few weeks ago I released Tower of Guns, a randomized indie-FPS-labor-of-love (here's the launch trailer for it).

The game currently sits at 78% on metacritic and feedback has been overwhelmingly positive. I did most of the development work myself, which allowed for very consistent time tracking on a project-wide basis. I'll spare you the boring story of how a creative-person-with-an-aversion-to-formality got addicted to time tracking, but as a nice side effect I can tell you that over the course of 600 days, Tower of Guns took precisely 3850 hours and 5 minutes to develop.

Since I tracked thoroughly, a number of folks have requested an article diving into the hourage from Tower of Guns. "3850 hours" isn't all that useful of a number on its own, so below are a bunch of different ways that number breaks down.
 

Like many development stats, much here is specific to Tower of Guns' journey, and specific to just one developer's account at that. My numbers support many common thoughts about development, so if you're looking for startling results, look elsewhere. Still, these numbers may satisfy a passing curiosity for how long it takes someone to make an indie first-person-shooter like Tower of Guns.
 

Before we dive in, here are some unaccounted for factors:
 

Breaking down by Aggregate Effort:
 

3850 hours is actually not all that large of a number, once divided out over the development time. This chart shows roughly how much time was spent in each year, with the inset showing how much potential time there was in those years (as percents of days of the total project).

What's interesting here is that the available time in each year and the amount of effort put forward in those years make a similarly sliced up chart, which along with not-alarming "hours per week" would *imply* that I dove in full at full speed and never crunched or slacked. That would also be a complete lie.

Method of tracking:
 

While many companies track time using spreadsheets and fancy producer-scrum-judo, I did minimal pre-planning for a milestone, and only logged the reality of when I worked. Similar to switching on/off a competition chess clock, I kept a browser tab with tracking site Toggl.com up at all times, stopping my clock whenever I switched over to check facebook, or went to the bathroom, or scanned twitter, etc. That means the time logged was about as close to 100% efficicent as possible (not that I was 100% efficient, mind you, but that the captured time was).
 

When planning out a project, most solid producers never run estimates using 100% efficiency (a sure road to sad times), but rather plan/book time with a lower efficiency, usually 80% or so. I never tracked "time in work-mode" (versus "time producing work") but I suspect it was consistently 9-11 hours a day, with sharper spikes near deadlines and dips afterward. That's an anecdotal number, sure, but my wife agrees and she's got a pretty good memory. Using that stat, here's what my actual efficiency looks like:
 

Let's be clear: I'd prefer not to work 9-11 hours a day, 6 days a week, for 600 days on every project. I'm also realistic that I may never hit 80% efficiency. 2014 number's are starting to look pretty good at least though... however, that 55-67% number for 2012 was alarming. That implies that ~25 minutes of every hour was wasted. And 2013, which accounts for the lion's share of the project, was not much better.

Breakdown by Development Phase:
 

My wife jokingly said I should see when I signed up for twitter and chart that against my toggl.com hours. I did, and while despite there not being a correlation, I've a gut feeling that, for me personally, social distractions like facebook and twitter were not not causes of inefficiency, but rather were symptoms. That is to say, I spend more time on twitter because I was demotivated, and not that twitter demotivated me (usually).
 

Here's another totally professional looking chart:

The low efficiency in 2012 is straightforward to explain. Of the 1050 hours spent working on Tower of Guns in 2012, over half of that was prototyping/RnD. I was unprepared for how rough that phase would be. The desire to create something and not knowing how to progress is incredibly frustrating. I had never started a business before Terrible Posture Games. I had no idea how to talk to the press or how to market myself. I had never worked with UnrealScript (or any code in close to fifteen years).
 

I had no concept of anything except for my expertise in isolated slivers of the development pipeline (a common history among Triple-A developers turned indies, it seems). Given my current skill set now, 20 months later, it would not be a hard to imagine the prototype period of a second project taking only 60-80 hours rather than over 600 hours. Knowing is faaaar more than half the battle when it comes to game development.
 

Also, looking back, here's a tidbit I learned about myself during prototyping: feeling overwhelmed leads to demotivation. Demotivation leads to stagnation/distraction/facebook. Working mostly in solitude makes this worse: the sense of a shared investment that comes from teamwork is replaced with an echo-chamber of doubt. Devising strategies to combat self doubt, therefore, became a crucial part of development (maybe that's worth a blog of its own someday).
 

Once I had a clear grasp of what Tower of Guns was (a randomized FPS aimed at the 90s era twitch fan) as well as how to approach building it, my efficiency improved dramatically.

Breakdown by Month:
 

Here I've roughly broken down my time over the project into three buckets: creative junk (asset creation and level authoring), technical crap (scripting, bug fixing, fussing with deployments), and non-dev stuff (marketing, business development, random other stuff).

*The severe dip in overal hours in Dec 2012 is easily explained: I joined in the IndieSpeedRun game jam. While game jams are awesome, I've learned not to underestimate the amount of energy it takes to participate in one—or recover afterwards. In the future I'll save them for when I'm between larger projects, I think.

Anyway, while I do have an overall trend upwards in term of my efficiency over time, the individual buckets have a bizarre oscillation that I wasn't expecting. It looks like I focused on tech one month, art or level work the next, then tech again. This was likely because I would spent a few weeks building a new system, and then a few weeks bolstering the game's content using that feature.
 

While I *thought* I was always focused on the highest priority at any given time, I have a strong suspicion that changing gears compromised my efficiency. Why do I have that strong suspicion? Because in the past producers have told me so. My numbers would suggest that I got better at task-switching with practise.

Breakdown by Aggregated Development Discipline:
 

Here're some charts of my time broken down by rough discipline per year:
 

2012 looks about like how you'd suspect from an "early" development period: bugfixing was minimal (since no product had been developed yet), as was marketing, business development (mostly tax stuff), and level design.
 

The alarming thing during 2012 is how much actual asset work I did. During a phase where prototyping and addressing the unknowns should be the priority, wisdom would suggest that I put off any final asset work. There's a few reasons behind that division of work:
 

On the other side of the development cycle, 2014 was the most "efficient" period of the project, and it was also when I spent the most amount of time focused on a single task: marketing.
 

"Marketing" for me is broadly defined: talking to press, going to conferences, entering contests, interacting with youtubers, even making marketing art like postcards, the trailer, and the website. I think I did a pretty decent job with marketing for an indie developer, ending up with reviews in about 42 different publications (so far), acceptances into a number of industry showcases, appearances at several trade shows, articles on many major news sites, and a ton of Youtubers and Twitch players diving into the game. However, I also have a new appreciation for marketing people. All told, "marketing" took up 983 hours and 24 minutes of the project, or, about 25% of my time.
 

Given how huge a number that marketing stat is, the wisdom of hiring a partner to help me market seems obvious for my next project, but I doubt that number could ever be removed entirely (or if I'd desire that)—direct interaction with the press and the community seems to be crucial these days. Not to mention it was fun, or that some of the elements I counted towards that bucket are ones best not farmed out.
 

Anyway, all those charts really tell me is that if I truly care about that 80% efficiency number then it seems I should go back to working for large studios, where working on focused tasks in a collaborative environment would push me to be more productive. I probably didn't need a pie chart to tell me that.  However, I did enjoy wearing a lot of hats. Even more, I liked having ownership over a project's completion in its entirety.
 

Anyway, here are some lessons learned and notes for myself for my next project:
 

Thanks for reading!  If you'd like to check out the game you can pick up Tower of Guns through a variety of outlets, all of which are linked directly on www.towerofguns.com. If you'd like to start your own time-tracking obsession, I heartily reccomend toggl.com. You don't even need an account to use the dang thing.