游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

独立开发者分享游戏测试实践过程

发布时间:2013-05-09 16:23:00 Tags:,,,,

作者:Remi Lavoie

5月2日,Execution实验室组织了全部团队参与的第一次正式游戏测试。测试可以提供大量信息,使开发者了解游戏中哪些地方执行得好以及哪些地方需要改进。为了使游戏更完善,所以我们在热烘烘的电脑前埋头苦干了一整天,为测试者准备新版本。

在组织测试时,应该记住以下几点:

1、总是用最新版本做测试(我们不想收集已经解决的问题的反馈)。

2、目标明确。

3、尽可能收集诚实客观的反馈。

4、尽可能客观地记录反馈和测试过程。

所以基本上,我们必须制定一个计划!

以下是我们准备计划和执行测试的具体过程。

目标:

为测试树立目标是很重要的。我们想测试游戏的直观性?UI?刚添加的新功能?这些都是有效的目标,我们必须按照特定的目标组织测试。

我们此次测试的目标是,在不给玩家任何指导或背景信息的情况下,考察玩家与游戏的第一次互动情况。所以当测试玩家准备好玩我们的游戏时,我们对他们说了这么一番话:“你们要玩的是一款正在制作中的测试关卡。我们不会给你们任何指导,在你们游戏时我们也不会回答你们的任何问题。我们希望你们从游戏一开始就自己摸索。如果在游戏时你能陈述一下自己的做法,那就太好了,但我们不强制,看你们自己的决定。一旦你们游戏时间到达5分钟,或者通过成功,测试就结束。游戏之后,我们会让你们填写一份反馈表格。谢谢!”

我们还有几个次目标。最近我们对游戏的输入组合做了重大调整,还添加了一些新的美术设计,正好通过这次测试一并了解玩家对它们的想法。

我听到有人问:“先生,目标很明确,但是你们怎么确保测试针对这些目标,并且你们又如何验证结果?”好问题。首先,没必要称呼我“先生”,我们都是朋友嘛。问题的答案就在我们提问题和收集反馈的方法中。这些正是下一段的主要内容!如果我把这些句子全部放在这一段里,那就太多了吧?所以请往下读!

PlayTest(from gamasutra)

PlayTest(from gamasutra)

反馈

毫无疑问,收集测试者的反馈是测试的最关键部分。我们希望并且也必须设计问题。这些问题必须反映我们为测试树立的目标。测试UI?那么问题就应该是这样的:“你认为UI如何?你是否清楚各个按键的作用?是否有你不理解的元素?”等等。

什么?你想知道我们是怎么做的?没问题,那正是本文的重点!

首先,由Mathieu起草一份相当漂亮的反馈表格,等测试完毕,我们就会拿给玩家填写。之后,我们会按组评估表格,确保它覆盖了所有已确定的目标;我们还要检查每一个用词,保证不会透露我们自己的偏好。与单纯地口头问问题(可能用语模糊或带有偏见)相比,白纸黑字的表格更有助于收集到客观的反馈。为什么写好的表格更好?理由如下:

1、隔离层:直接问:“你觉得我的游戏怎么样?”可能会得到不诚实的回答。人们不想当着我们的面给出消极反馈,但在匿名的表格上,他们更可能如实回答。理想情况下,为了得到更加诚实的反馈,收集反馈的人也不应该是开发团队中的一员,但是我们可没有这么奢侈的条件。

2、客观性:表格的客观性体现在两个方面。问题总是一样的,我们不必冒险用不同的话向各个测试玩家表述问题。收集反馈的方式也是客观的,是由回答的人写下来的,而不是我们挑出回答中我们认为重要的东西记录下来,或者甚至更糟,只靠自己的记性,完全不做笔记。

3、存档:我们总是能回顾填好的表格!表格是有形的实体!我们把表格扫描并保存起来,然后编辑到电子表格中,共享给整个团队。这么做有什么好处?我们可以很容易提取所有问题、根据测试玩家的年纪/性别/背景编辑基本数据。之后我们可以处理发现的问题,再返回反馈,验证是否解决了所有有效问题,并写下解决办法。这就形成了一份关于什么、为什么和怎么做的历史记录!

PlayTest2-Forms(from gamasutra)

PlayTest2-Forms(from gamasutra)

记录

为了进一步体现测试的价值,我们可以做记录。这里的记录,我指的是详细地写下当时发生的所有事,或更好一点,拍视频!我们就是那么做的。Alex买了一部文件扫描摄像机,放在桌上。在玩家玩游戏时,我们就打开设备的摄像头。

记录测试过程后,我们可以回头看看视频,也许能发现有价值的信息:玩家做的第一件事是什么?玩家熟悉操作用了多久时间?玩家使用某个功能多少次?一边手动记录这些事,一边玩家在做什么是非常困难的,而拍摄后再观看视频就简单多了。另外,视频也是存档。在我们忙于记笔记时,很可能会错过重要的细节。

记录还可以作为下一次测试的比较和验证工具。例如,如果大多数玩家在第一次测试中很难理解界面,通过比较两次测试的数据,我们可以直接检验我们对下一次测试做的修改。

PlayTest2-Setup(from gamasutra)

PlayTest2-Setup(from gamasutra)

PlayTest1(from gamasutra)

PlayTest1(from gamasutra)

以上就是我们的第一次正式测试的细节。希望本文对你有帮助。

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Playtesting for Indies

by Remi Lavoie

On May 2nd, Execution Labs hosted its first official playtesting session for all the teams. Playtesting can offer a wealth of information about what is working well… and not so well in your current game implementation. We wanted to make sure we did things right, so we slaved all day over our hot computers preparing a shiny new build for testers to play with.

There are a few things to keep in mind while organizing a test session:

Always playtest with a recent build. (we don’t want to gather a bunch of feedback on issues that are already resolved)
Have a goal.

Get the most honest and objective feedback that you can.

Keep objective records of the feedback and the session itself if possible.

So basically… we NEEDED to have a plan!

So here, for your reading and viewing pleasure, the details of our master plan and how we used it to make the most of our playtesting session.

The Goal:

It is very important to set a goal for the session. Do we want to test out your game’s intuitiveness? The UI? That fresh new feature we just put in? These are all valid goals and it is important that we gear our testing towards our specific goal.

Our goal for this session was seeing how players first interact with our game without being given any instructions or background on what the game actually is. So the speech we gave to the candidates as they prepared to play our game went a little something like this: “What you will be playing is a Test Level from a work in progress. We will not give you any instructions, or answer any questions while you are playing. We want you to just start playing and figure things out on your own. If you want to narrate what you are doing, that would be great, but it’s not necessary and is entirely up to you. You will play for 5 minutes or until you complete the level, whichever comes first. After playing, we have a feedback form for you to fill out. Thank you!”

We also had a few sub-goals to verify for ourselves, we recently made significant changes to the input scheme for the game and added some new art assets, and this was a perfect opportunity to see what new players thought of them.

I can hear people saying: “So that’s all well and good sir, but how do you orient your testing towards these goals, and how do you validate them?”. That’s a very good question. First of all, there’s no need to call me sir, we’re all friends here. The answer to that question: it’s all in the way we ask our questions and collect our feedback, which conveniently enough is the subject of the very next paragraph! It’s like if I put all these sentences in some sort of order. I know, pretty crazy stuff, right? So read on!

The Feedback:

Collecting feedback from testers is without a doubt the most crucial part of playtesting. We want to, and in fact need to, plan out the questions we’ll be asking our testers. These questions need to reflect the goals that we have set for our session. Testing out UI? Well there should be a questions like: “What did you think about the user interface? Did you understand what each button did? Is there element that you didn’t understand?” and so on.

What? You want to know how we did it? No problem my friend, that’s pretty much the point of this article!

It all started with Mathieu drafting up a pretty nifty feedback form for our testers to fill out after playing. We then reviewed it as a team, made sure we covered all the goals we had set, and reviewed all the wording so it was not biased in our favor. A written form is a great way to collect much more objective feedback than just asking questions ourselves and relying on our fuzzy and probably pretty biased memories. Why are written forms better? Many reasons, let’s present them in a convenient list form.

Layer of separation: Asking people directly: “So what did you think of my game?” will result in extremely biased responses. People will not want to give negative feedback to our face, but are much more likely to leave more honest feedback on an anonymous form. Ideally, the people collecting the feedback would not even be part of the development team, for even more honest feedback, but we did not have such luxury this time.

Objectivity: Forms are more objective in two ways. The questions are always exactly the same, we do not risk phrasing them differently for each users. The way the answer is collected is also objective, it is written down by the person answering, and it’s not just us taking down notes of what we think was important in the answer, or even worse not taking notes at all and just trying to remember the feedback later on. This brings us to the other reason forms are pretty sweet.

Archives: We can always refer back to the filled out forms! They exist as full on tangible objects! We scanned all of them and kept those on record, and we also compiled all the answers in a spreadsheet which is shared with the whole team. What’s so great about this? We can easily extract all the issues, compile basic statistics based on the age/gender/background of testers. We can then address the issues found, and come back to the feedback and verify that all valid issues have been resolved and write down what was done to resolve them. BAM! Instant history of thewhat? why? and how we solved the issues!

The Records (Optional, but awesome!):

Another thing that can do to add even more depth to playtesting sessions, is keeping records. By records, I mean either a detailed log of everything that happened, or even better, a video! That’s what we did. Alex brought in this sweet document scanner camera that you can set up on a desk and we asked testers to play the game while keeping the device in the camera’s view.

We recorded the sessions, and can now look back at the videos and have really valuable information: what is the first thing the player did? how long it takes them to figure out the controls? how many times did they use a specific feature? Keeping track of all this manually while also watching what the player is doing is extremely difficult, filming and watching back the video later on makes this easy, and again, provides archives of what happened. It is also much less likely that we miss important stuff because we were busy writing down notes instead of watching the user play.

It can also be used as a comparison and validation tool for the next playtest. For example, if most players had trouble with your interface in the first playtest, we can then directly validate (or invalidate) our changes with the next playtest videos by comparing specific statistics from the previous ones (ex: Clicks to get to main gameplay: 1st playtest = 5, 2nd playtest = 3. Validates changes made.)

So there you have it, all the details (and some pretty pictures) of how we proceeded with our first official playtest. Hope you enjoyed the post, and that it was helpful for you.(source:gamasutra)


上一篇:

下一篇: