作者：Alex Moore

很多文章都有谈到集中测试，这是开发团队鲜少给予充分关注的部分。

这个概念非常简单：邀请公司以外的人士到工作室体验游戏，观察他们的反应，做记录，给他们提供茶和点心，让他们签下保密协议（游戏邦注：这样他们就不会在网上谈论相关内容），然后讨论你从中获得的信息。参考有用信息，忽略无用信息，完善游戏。接着寻找另一愿意进行测试的用户，重复这个过程。

当然实际操作没有这么简单。游戏在开发过程中遇到的最大问题是它们通常只有等到制作末尾才做好进行外部测试的准备，而此时要修改内容已为时过晚。漏洞通常就是这样产生，影响测试工作的进行，我们知道这行不通，动画/特效/用户界面不合适，但我们已没时间进行调整。而你的测试对象是个连掌机是什么都不知道的家伙。

我过去总是相信这些。若你依然这么认为，本文将告诉你这是错的。应及早进行集中测试，若运作得当将起到突出作用：优化游戏和节约资金。

Rogue Trooper from 3.bp.blogspot.com

经验教训

回过头看，我觉得自己是在制作《侠盗骑兵》的时候认识到集中测试的重要性，虽然当时我并未进行集中测试。其实当时我完全相信上述内容：我已制作过很多游戏，担任过首席设计师多次，我相信自己的能力和团队。我是个难搞的合作伙伴，主要由于我不喜欢委托他人。

这在关卡设计中更是如此：我给《毁灭战士》和《雷神之锤》等作品制作过无数关卡，我相信自己知道如何制作好关卡。我就《侠盗骑兵》的所有关卡内容进行白箱测试（游戏邦注：自己玩自己开发的游戏），就是这样，我发现作为首席设计师，我很难摆脱管理者的身份，以挑剔眼光看待这些内容。

这在游戏头几个台阶中表露无遗。下图是游戏初始画面的最初布局（粗略再现）：

rogueStart 01 from gamasutra.com

此设计似乎非常简单，我们的预期是将指南融入其中，这样玩家就会进行如下操作：

rogueStart 02 from gamasutra.com

开头的道路纯粹是为了让玩家回到起点，迫使他们跳过台阶，因为我想在接下来教他们如何爬行。跳跃是游戏的核心机制，不是由于这是款平台游戏，而是因为这能够帮助玩家跳离被敌人点燃的道路。我希望早点将此教给玩家。

在此开发阶段，我们已设定这款PS2游戏的基本功能，我们进行正式演示，旨在获得开发资金，落实《侠盗骑兵》的所有计划，我们的AI非常基础。游戏算不上完美，但你可以四处走动，爬行，利用掩护，射击敌人。我们能将调试文本放置于屏幕上：我们可以创造基本指南。从根本上说：我们应该将白箱测试放到集中测试中。

我们没有这样做，是由于我在第2段提到的原因。

我们让团队成员体验关卡，和主要程序员一起就游戏布局进行冗长技术分析，确保他对此感到满意，以及在植入图像内容时，PS2的运作不会受到影响。我们对内容完善，然后继续向前迈进：美工花费几周时间制作精美几何图形、纹理和灯光。设计师花费几周时间润色玩法，动画家开始制作旨在陈述故事的影片。这些都要耗费大笔资金。

只要这些内容都得到完善，游戏机制也会得到完善，我们最终进入集中测试阶段。我们当时对结果感到非常沮丧。用户所进行的操作有违开发团队和我的期望，他们进行的操作是：

rogueStart 03 from gamasutra.com

不是1次、2次，他们就一直这样，来来回回。有些人明白其中内容，但多数人都不明白。

这一部分是由于游戏指南只出现一次，若用户一开始就错过跳跃说明，便无法再看到相关信息。所以我们对此进行调整，将其放回至集中测试。结果有所改善，但并不显著。有人花15分钟弄清如何回避此沟渠。

我当时的反应是“真是个愚蠢的家伙！”指导后来我才发现，若设计受到曲解，错不再用户身上：是设计本身存在问题（游戏邦注：这是非常重要的经验）。

游戏指南还存在其他问题，有些很快就得到修复，有些则需要进行技术调整。这会给动画等内容带来间接影响。若我们在白箱测试阶段就对关卡进行测试，修复就只要10分钟。而等到我们真正进行修复时，整个过程耗费1个多人工周。

合理运用集中测试

那么要如何合理运用集中测试？答案就体现在其名称上：瞄准单个你想要测试的内容。是机制？布局？Boss斗争？无论如何，确保只向测试对象呈现一个测试内容。

就拿测试机制来说：不要创造广阔环境或花时间制作唯美内容，而是瞄准核心元素。花时间制作必要的控制装置、动画、音效和视觉特效。查看自己的机制教授方式——你如何向用户引入游戏机制？

回到《侠盗骑兵》的制作，我们试图在玩家学会行走前教其如何跳跃。这反过来又是我们最初制作游戏的系统模式——我们花费许多精力制作众多机制，供玩家选择，然后向他们呈现完整动作游戏。

《战争机器》也是在此时问世，融入两大内容——掩护射击和主动加载。Epic称游戏的核心机制已几近完美，然后开始基于这些内容创建游戏（游戏邦注：Valve在游戏制作中也是采取相同策略，这也是《使命的召唤》如此规模宏大的原因所在）。

所以当有人要求你继续添加更多功能时，对其进行集中测试。物以稀为贵——花时间完善核心机制总能够更优秀的作品。试着在制作新内容时遵循这些简单步骤：

1. 决定想要测试的内容

2. 建立测试模式

3. 腾出充足时间组织测试工作

4. 确保需要获悉结果的人士参与其中

5. 跟进所提出的所有问题

6. 回应关键问题

每天面对如此多任务和信息，我们似乎很难做到这点。集中测试是我们在项目开始时所需进行的工作。如果等到大型团队开始制作内容，将剩余构思落到实处时再进行测试，一切就太迟了。我知道遵循以上步骤是个鲜少实现的理想模式，但这确实能够帮助我们制作出优秀作品。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Opinion: How To Use Focus Testing

by Alex Moore

[In this reprinted #altdevblogaday-opinion piece, Sumo Digital senior designer Alex Moore explains why focus testing is absolutely essential for improving your game, and why it's never too early to focus test.]

A few articles here have mentioned focus testing, and it’s one of those things that development teams rarely embrace enough.

The concept is simple enough: get someone from the outside world into your studio to play your game, watch them, take notes, give them tea and cake, get them to sign a non-disclosure act so they can’t talk about it on the web and then discuss what you’ve learnt. Action the key points, ignore the stupid ones, refine the game. Find another willing subject, repeat.

Naturally, it’s not that simple in practice. The biggest hurdle that a game faces during its development is that it’s not really ready for external testing to take place until very near the end, at which point it’s too late to be able to change much. Bugs get in the way and skew the testing, we already know that doesn’t work / animations / effects / UI / etc aren’t in yet / we don’t have any time to change anything anyway. The person you got in for testing was an idiot that didn’t know what a console was.

I used to believe all of that. If you still believe it, this post is here to tell you that you’re wrong. It’s never too early to focus test, and if the test is run properly, it will be invaluable: it will make your game better and it will save you money.

The Lesson

Looking back I think the point where I realized that focus testing was invaluable was when we were making Rogue Trooper, though I didn’t realize it at the time. In fact, at that time, I fully believed the paragraph above: I’d made a number of games, I’d been a Lead Designer several times and I was confident in my skills and the team. I was, almost undeniably, a pain in the ass to work with – mostly because of my refusal to delegate.

At no point was this truer that with the level design: having made countless levels for Doom, Quake, and then all the games that I’d worked on I truly believed I knew everything there was to know about making a good level. I did the initial white boxes for almost every level in Rogue Trooper and, because of that, found it very difficult to relinquish control and look at them with the critical eyes that I should’ve been using as the lead designer.

Nowhere was this more evident than in the first few steps of the game. Here’s a (very rough) recreation of the initial layout of the start area to the game:

The design seems pretty simple and the expectation was that the tutorial would be overlaid onto this, and players would do the following:

The path back to the start was put in purely as a method for getting players back to the start and forcing them to jump over it because I wanted to teach climb next. Jumping is a key mechanic in the game, not because it’s a platform game but because it’s useful for diving out of the way of enemy fire. I wanted to teach it to players early on.

At this point in development, we had the basic feature set for the game in place and running on PS2 – we’d done a green light demo to get the main development funded and had most of Rogue’s fundamental moves worked out, and we had very basic AI. The game was a long way off being finished, but you could get around, climb, use cover and shoot enemies. We had ways of putting debug text on screen: we could have created a rudimentary tutorial. Basically: we should have put the white boxes into focus testing.

We didn’t for the most of the reasons I mentioned in the second paragraph.

What we did do was get team members to play through the levels, and do fairly lengthy technical analysis on the layouts with the lead programmer to ensure he was happy that we weren’t going to blow the PS2 up when we started layering art on. Refinements were made, and we carried on: an artist spent several weeks making the detailed geometry, textures and lighting. A designer spent several weeks polishing up the gameplay and animators started creating the cinematics required to tell the story. Lots of money got spent.

Once it was all polished, and the mechanics of the game had been refined, we finally entered focus testing. The result was, at the time, heart sinking. Instead of doing what the development team had been doing, and what I expected, most people instead did this:

And not just once. Not just twice. They just did this. Round and round. Some people got it, but not the majority.

Some of it was due to the tutorial triggers only firing once – if someone missed the instruction on how to jump the first time, they never saw it again. So we changed that and put it back into focus testing. The results were a little better, but not much. One guy spent 15 minutes trying to work out how to get out of the trench.

My reaction at the time was “you stupid idiot!!!!” (note: there may have been more swearing than this). Only later did I come to realize, and come to understand that, if a design can’t be understood, it is usually not the person at fault: it is the design that is wrong. (This is an important lesson: learn it well for it will make you a better designer.)

There were plenty of other issues with the tutorial as well, some which were quick fixes and some similar to to this that required changes to the art. Which then had knock-on effects to the animations and so on. If we’d tested the level when it was in the white box phase, it would have taken 10 minutes to fix. By the time we came to fix it, it took well over a man-week.

Using Focus Testing Right

So, with such an arsenal of excuses at our disposal, how do you go about using focus testing right? Well, the clue is in the name: concentrate on a single thing that you want to test. Is it a mechanic? A layout? A boss battle? Whatever it is, make sure that only the thing you want to test is exposed to the people you get involved.

Take the testing of a mechanic for example: don’t create huge environments or spend time making something pretty, but instead concentrate on the core elements. Spend time working on the controls, any animations, sound and visual effects that are required. Look at how you’re teaching that mechanic – how is it going to be introduced to the player?

Looking back on the experience from Rogue Trooper, we were trying to teach the player how to jump before they could walk. Which in turn was systematic of our approach to making the game in the first place – we spent a lot of effort on lots of mechanics to give the player choices, then presented them with an action game.

Gears of War came out around the same time and did two things – cover-based shooting and active reload. Epic ensured that their key mechanics were honed to perfection and then built the game around them. Valve do the same with their games, and it’s also why Call of Duty has become so huge.

So, when people ask you to keep adding more features, focus test them. Point out that less is more – time spent on polishing key mechanics will always produce a better game over one with many. Try to follow these simple steps when creating something new:

1. Decide what you want testing.

2. Create a prototype for that test.

3. Allocate sufficient time to organizing the test.

4. Ensure the people that need to see the results are involved.

5. Keep a track of all the problems raised.

6. Respond to the key issues.

In the day-to-day deluge of tasks and information that flies around, it will seem hard to achieve this. It’s something that should really happen at the start of the project. Once a large team has come on to create content and flesh out the rest of the experience, it’s kind of too late. I know that’s an ideal world scenario that rarely happens, but when it does great games are made.（Source：gamasutra）