作者：Alistair Doulin

我之前参加了Freeplay Independent Games Festival盛会，有幸玩了1个多小时的《Antichamber》。我们在那展示作品《Battle Group》，我们是大会独立游戏比赛的决赛选手。我和Alex交谈的部分内容是围绕各自作品何时“完工”。这里我将就此深入说明。

Battle Group from moddb.com

我过去听Alex反复谈到自己总是被问及游戏何时完工，何时发行。关于游戏发行时所需的质量标准，Alex的观点很明确，我完全赞同他的看法。我们的《Battle Group》在为期4个月的开发过程中就数次推迟发行日期。这是我参与的所有作品都面临的相同问题（游戏邦注：不论是独立开发，还是任职于大型工作室），游戏总是延迟发行。问题是，我们如何客观判断游戏已经完工？

“若新玩家能够无需帮助就顺利完成所有内容，那么游戏就算完工”

让我深入阐述其中意思。首先你（或团队核心成员）需静观玩家体验。若未进行此环节，游戏就不适合发行。缺乏充足测试，你就无法客观判断游戏是否准备就绪。

只有游戏未包含任何阻碍漏洞，玩家才能顺利完成整个体验。我会连续体验自己的作品好几天都未发现任何问题，而测试员刚体验几分钟就发现缺陷所在。游戏还需给予玩家充分指导，让他们能够无需寻求帮助就完成整个游戏。看到玩家在游戏中犯下看似简单的错误，你会发现给予充分指导并非易事。我之前曾和新手测试人员谈及这点，而现今观看玩家体验《Battle Group》更是强化我对这点的认识。若你需帮助玩家完成部分内容，那么游戏就存在某些缺陷。

若你迫不及待以当前状态向玩家展示游戏，就不可避免要遇到漏洞和帮助的问题。这一点显而易见，若你不是迫不及待，为什么要发行游戏？出乎意料的是，我发现很多人都不顾一切地“就此呈现”，破坏这条原则。当我尝试体验他们的游戏时，他们不断表示歉意，提供各种借口，但依旧觉得游戏已到发行时机，仿佛觉得那些素未谋面的玩家会非常宽宏大量。

就判断游戏何时完工，开发者常常遇到两大问题：

1. 有些人陷入“游戏永无完工日”的误区。他们通常是极度追求完美的小团队，永不满足游戏当前状态。这些游戏通常最后会销声匿迹，因为团队最终会感到厌倦，转而投向其他项目。

2. 另一极端就是过早发行游戏。这些作品通常来自面临外部时间和资金限制的大型团队。

两个极端都非常危险，显然我们希望寻找二者的平衡点。获悉自己倾向哪一端非常重要，这样你就能在项目初期设定预期。项目进展越深入，你就越能轻松判断自己倾向哪端。关于在制作前设定质量标准，我常类比外出小酌进行阐述。在开始喝前，预先计划自己今晚要喝几杯非常重要，因为几杯下肚后，你就失去判断力。投入项目的时间越久，你的判断力就越差（游戏邦注：或希望“发行作品”因为你已厌倦投身其中，或不希望匆匆发行不完整作品，令自己的几个月心血付之东流）。

只有在项目初期设定预期，你才能准确把握质量标准。决定设定何种质量标准时，不妨参考团队组成、游戏目标和项目预算/期限。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

When Is Your Game Finished?

by Alistair Doulin

I attended Freeplay Independent Games Festival on the weekend and had a chance to try out Antichamber for a little over an hour (sorry to all the people in the queue behind me). We were there to show off Battle Group as we were a finalist in their indie game competition. Part of my discussion with Alex was about our when our respective games would be “finished”. Today I’m going to explore this a little further.

I’ve heard Alex speak a number of times in the past and a recurring theme is that he is always being asked when his game is finished, and when it will be released. Alex has some strong views on this that I completely agree with, relating to quality levels required before a game is ready for release. Our own game Battle Group has been pushed back from our (internally planned) release date a number of times in it’s 4 month development. It’s a recurring theme on every game I’ve worked on, both independently and at larger studios, they are always late. The question is, how can we objectively determine when the game is finished?

“You’re game is finished when someone who hasn’t played it before can play through it’s entirety without assistance”

Lets dig a little into what this means. Firstly you (or a few key team members) need to sit and watch people play your game. If you’re not doing this, your game shouldn’t be released, period. Without sufficient playtesting there’s no objective way you can determine if your game is ready or not.

Someone can only play through your entire game once you have no show stopper bugs. I can play a game I’m working on for days on end and never come across an issue which a play tester finds within the first few minutes of playing. The game also needs to teach them enough to be able to play through it’s entirety without your help. This is a really difficult task when watching someone make seemingly simple mistakes in your game. I’ve spoken about this previously with “Virgin” playtesters and spending the weekend watching people play Battle Group only reinforced this for me. If you have to help someone through a certain part, something is wrong.

Related to bugs and assistance is the requirement that you are happy to show people the game in it’s current state. This seems like a no brainer, if you’re not happy to show someone, why would you release? Surprisingly, I’ve seen a number of people so desperate to “just get it out there” that they break this rule. They were all apologies and excuses when I tried to play the game but they felt they were still ready to release it to the world, as if people they don’t know would be more forgiving.

When deciding when a game is finished, there are two areas that people run into trouble:

1. Some people fall into the “it’s never finished” trap. They are usually small teams that aim for absolute perfection and are never happy with the game. These games often disappear and the team gets bored and moves on to something else.

2. At the other extreme are games that are shipped far too soon. These often come from larger studios with external time and money constraints imposed on them.

Either extreme is dangerous and obviously we want to aim for the middle ground between these. Knowing which end of the spectrum you are more likely to favour is important so you can set expectations at the start of the project. The further a game progresses in development the easier it is to diverge towards one of these extremes. When talking about setting the quality level before you begin production on a game I use the analogy of going out drinking. It’s important to set the number of drinks you plan to have in an evening before you start drinking as once you’ve started down that path, your judgement is impaired. The longer your on a project, the more impaired your judgement becomes. Either wanting to “get it out the door” because your sick of working on it, or not wanting to waste the months you’ve been working by releasing an imperfect game.

Only by setting your expectations at the beginning of a project can you have a reasonable chance of setting the quality bar at a safe level. Look at the team makeup, objectives of the game (retail success vs portfolio piece) and project budget/length when deciding what quality bar to aim for.（Source：gamasutra）