作者：Joseph Mirabello

我数周前发布了《Tower of Guns》这款随机独立FPS游戏。

该游戏目前在metacritic（游戏评论网站）得分为78%，获得了压倒性的积极反馈。我执行了大部分的开发工作，这得以让我持续追踪一个项目的开发过程。我将在此与大家分享一个讨厌按部就班的创意人士如何迷恋上追踪时间的无聊故事。我可以告诉你这款游戏开发时间超过600天，准确地说是3850个小时零5分钟。

有不少人在我的这一追踪过程中请求分享《Tower of Guns》的时间分配，“3850小时”这个数字本身并没有什么意义，所以我将以不同方式分解这个数字。

与许多开发统计资料一样，这里的数据仅针对《Tower of Guns》项目开发过程，也仅适用于一个开发者帐户。我的数据支持许多普遍的开发理念，所以不会有什么额外的惊喜。但这些数据仍可满足关于一个人如何制作出一款像《Tower of Guns》这种第一人称射击游戏的这种好奇心。

在我们深入挖掘之前，要先看看以下一些没有详细说明的因素：

*音乐作曲（我请自己的兄弟来做这事，他没有像我一样的时间追踪癖）。

*帮忙测试和推广游戏的粉丝、好友以及家人的支持。

*使用UDK所节省下的时间（游戏邦注：这款游戏大量使用了现成的UDK工具和功能）。除此之外，我之前就很熟悉美术/设计方面的引擎。

*选择极为抽象的关卡艺术风格所节省下的时间。

*我动作很慢。

按整体精力划分

3850小时如果按开发时间来分配，实际上并不是一个庞大的数字。以下图表显示了每天所投入的时间，其中的插入图表显示了那些年的潜在可用时间（整个项目的百分比天数）。

有趣的是，每年可用的时间以及那些年所投入的精力形成了一个划分极为相似的图表，这一切似乎“暗示”着我加足了马力，坚持不懈地推进项目。但实际上这是不可能的。

追踪方法

虽然许多公司使用电子表格来跟进时间，但我为项目里程碑制做了最小的预先计划，并且只记录了我实际上的工作情况。我一直保存着追踪网站Toggl.com的浏览器标签，当我跳转到Facebook或者去卫生间，或者浏览Twitter的时候，就会暂停我的时钟。这意味着我的时间记录接近于100%的有效性（必须提醒你的是，这并不是说我100%高效，仅仅是说明我在记录时间方面卓有成效）。

在计划一个项目时，多数可靠的制作人从来不会用到100%的效率，通常是以80%左右的较低效率来记录/计划时间。我从来没有追踪“工作模式的时间”，但我认为这应该是每天9-11小时，在接近截止日期时会出现更多峰值。当然这只是一个道听途说的数据，但我的妻子同意这个说法，她有很好的记性。使用这一数据，就可以得到我的实际工作效率：

让我澄清一下：我并不喜欢在开发每个项目时每天都是工作9-11小时，每周6天，连续600天。我也清楚地知道自己从来没有达到80%的效率。2014年的数据目前来看还相对乐观……但是，2012年55-67%的数据却是一个警告。这意味着我每小时浪费了25分钟左右的时间。在2013这个占据大部分项目开发时间的一年中，我的效率也并没有更乐观。

以开发阶段来划分

我妻子开玩笑说我可以对照Toggl.com所记录的时间，看到自己在Twitter上逗留的情况。我可以感觉到，就我个人来看，Facebook和Twitter等社交消遣渠道并非低效率的根源，而是一种低效率的症状。也就是说，我在Twitter上花了更多时间是因为我变消极了，而不是因为Twitter本身让我分神。

以下就是一个更专业的分析图表：

2012年的低效率很容易解释。2012年我在《Tower of Guns》投入了1050小时，其中有一半用于制作原型。我当时还没有预料到这个阶段会如此困难。想创造内容的渴望以及不知如何推进的感觉真的很让人受挫。在Terrible Posture Games之前我从未创办过一家公司。我不知道如何同媒体打交道，或者如何推销自己。我之前从来没有使用过UnrealScript（将近15年从未用过任何代码）。

除了自己在开发过程中所掌握的一些有些的开发经验，我不知道自己还会什么（这似乎是从AAA开发环境转向独立领域的开发者的一个通病）。现在我已经掌握了一定的技能，不难想象20个月之后我构思第二个项目原型时只需60-80小时，而非超过600小时。要知道这个阶段离真正的游戏开发还很远。

在此我还要分享一个原型制作阶段时的一个经验：不堪重负的感觉会导致消极。消极又会导致分神/停滞不前/转向Facebook。而在几乎完全闭门造车的情况下工作会令情况更糟：之前同团队分享的投入感却被自我怀疑所取代了。因此，设计一个战胜自我怀疑的方法就成了一个重要的开发环节。

当我清楚掌握了《Tower of Guns》的方向以及如何开发这款游戏的时候，我的效率就开始显著提升了。

按月划分

在此我将自己投入项目的时间划分为三大块：创意环节（创造资产以及关卡），技术环节（脚本，漏洞修复，部署工作），以及非开发内容（营销、业务开发、其他随机事件）。

*2012年12月数小时的低谷很容易解释：当时我加入了IndieSpeedRun游戏大赛。游戏开发大赛虽然很棒，但我也由此知道了不可低估参与一个竞赛以及事后休整所需投入的精力。我想未来我将在更大型的项目开发间隙再参加这种活动。

虽然我总体上的效率一直在随时间发展而提升，但各个环节之间却出现了我所没有预料到的一些奇怪的动荡。我似乎是在技术方面投入了一个月，在美术或关卡工作上投入了又一个月，而后又转向了技术。这很可能是因为我花了数周时间创建了一个新系统，之后又花了数周时间使用该功能支持游戏内容。

虽然我认为自己在任何时间总会专注于最重要的事项，但我极度怀疑改变工具令我的效率大打折扣。为什么我会强烈怀疑呢？因为过去的制作人曾这样告诉我。我的数据显示自己在比较熟悉的过程中切换任务会更好。

按总体开发学科划分

以下就是我按每个学科每年投入所划分的时间：

2012似乎可以看到这是一个“早期”开发阶段：修复漏洞最少（因为还没有成型的产品），营销、业务开发（多为税收事务）以及关卡设计亦是如此。

2012年值得注意的一件事就是我究竟制作了多少实际资产。在这个阶段原型制作和解决自己未知的领域是重中之重，直觉告诉我应该放下任何最终资产开发工作。以下就是进行工作划分的数个原因：

*我采用了垂直式方法。

*提供更完整的游戏可便于测试人员提供具体的反馈。

*有许多关于美术方向的问题需要解决！

*切换到我比较有自信的任务，可以激励我挑战那些让自己受挫的任务。

在这个开发周期的另一方面来看，2014年是整个项目“最有效率”的开发时期，也是我在营销这单个任务上投入最多时间的阶段。

“营销”对我来说定义很广泛：与媒体打交道，参加行业大会，参加竞赛，与Youtube观众互动，甚至是制作海报、预告片以及网站等营销美术内容。我认为作为一名独立开发者，我在营销方法还算卓有成效，获得了来自42家不同媒体的评论，参加了一系列行业展会，出现在多个贸易展会上，获得多家主流新闻网站报告，并将大量Youtube观众和Twitch玩家引向游戏。我在“营销”上花了983小时24分钟，约占25%的项目时间。

鉴于营销工作量庞大，为我下一个项目雇佣一名合作伙伴似乎才是明智之举。但我也认为现在直接与媒体和玩家社区打交道甚为关系。这不单是因为它更有趣，还因为我认为这个环节有些元素最好不要转手给他人。

这些图表告诉我，如果我真的在意那80%的效率，那我最好是重返大型工作室，在一个合作环境中专注于开发一个项目，这样会让我更富有效率。但我却更喜欢一人身兼数职的感觉。我也喜欢自己一人掌握单个项目的所有权。

以下是我将运用于自己下个项目的教训：

*如果你身兼数职，就要做好低效率的准备。

*想尽一切方法克服消极心理。

*下次记得追踪“坐在椅子上的时间”。

*在相关任务上准备投入四分之一的营销时间。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

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).

I’m slow.

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）