我数周前发布了《Tower of Guns》这款随机独立FPS游戏。
有不少人在我的这一追踪过程中请求分享《Tower of Guns》的时间分配，“3850小时”这个数字本身并没有什么意义，所以我将以不同方式分解这个数字。
与许多开发统计资料一样，这里的数据仅针对《Tower of Guns》项目开发过程，也仅适用于一个开发者帐户。我的数据支持许多普遍的开发理念，所以不会有什么额外的惊喜。但这些数据仍可满足关于一个人如何制作出一款像《Tower of Guns》这种第一人称射击游戏的这种好奇心。
2012年的低效率很容易解释。2012年我在《Tower of Guns》投入了1050小时，其中有一半用于制作原型。我当时还没有预料到这个阶段会如此困难。想创造内容的渴望以及不知如何推进的感觉真的很让人受挫。在Terrible Posture Games之前我从未创办过一家公司。我不知道如何同媒体打交道，或者如何推销自己。我之前从来没有使用过UnrealScript（将近15年从未用过任何代码）。
当我清楚掌握了《Tower of Guns》的方向以及如何开发这款游戏的时候，我的效率就开始显著提升了。
How Long Does It Take to Make an Indie Game?
by Joseph Mirabello
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
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:
Music composition (I contracted my brother for that. He doesn’t share my time tracking obsession).
Support given by the fans, friends, and family who tested and helped promote the game.
Time saved by using UDK (Tower of Guns heavily leverages existing UDK tools and features). Additionally I was extremely familiar with the engine from an art/design perspective beforehand.
Time saved by choosing a very abstractish level-art style (I suspect many titles would have a significantly larger art impact).
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:
I adopted a verticle slice mentality.
Having more complete sections of the game gave playtesters something tangible to give feedback on.
Many questions regarding art direction needed to be resolved too!
Switching to tasks I was confident with motivated me through tasks I was frustrated by.
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 you 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:
Be prepared for lower efficiency if you wear many hats.
Focus on combating demotivation with every trick you can
Temember to track “time-in-chair” next time as well.
Be prepared to spend a quarter of your time on marketing related tasks.（source：gamasutra）