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

解析可用性测试对游戏开发的重要性

发布时间:2011-07-17 17:23:44 Tags:,,,,

游戏邦注:本文原作者是Blitz Games Studios工作室开发总监Chris Viggers,他通过两款Kinect游戏解析了用户测试结果对反映游戏瑕疵的作用。

可用性测试可以说是当今游戏产业发展过程中的一个热词,也是许多开发者内心的恐惧所在。但到底什么是可用性测试,如何利用它创造出更优秀且更具有吸引力的娱乐项目,这一点值得我们深入思考。

从一个游戏开发者的角度来看,可用性测试的核心作用是用来告诉游戏设计师,美工,编码员,动画师以及经理人,他们到底犯了什么样的错误。人类的本性让我们逐利避害,尽量逃避批评带来的各种痛苦(包括心理和身体上的不快),许多人难以接受批评,尽管这种苦口良药有时会促成更好的结果。

游戏产业正以更快的速度迅猛发展,同时也有越来越多人,包括各种层次的用户正在体验我们所创造的游戏。一千人眼中有一千个哈姆雷特,这些用户将宝贵的时间投入游戏时也会对其产生自己的期待和看法。

为什么必须采取可用性测试?

相信任何制作人读到这篇文章都会感同身受,在游戏开发的过程中,大家都会发现若不投入更多时间、资金或资源,项目结果总是无法如自己预期的那般理想。

而且你也很难说服团队和管理层在制作流水线中再添加一个环节,而当这个环节可能带来玩家的更多意见,增加大家补缺补漏的工作量时更是如此。

但是不管怎样,现实就是无论你愿意与否,你的游戏最后总要接受检验,并且会以用户评论或Metacritic(游戏邦注:专门收集对于电影、电视节目、音乐专辑、游戏的评论的网站)评分的结果为世人所知。

如果你在开发过程中忽视了终端用户的反馈以及游戏的可用性结果,那么你将有可能在测试中得到不好的评价和反馈,而因此损害游戏价值及名誉。作为游戏开发者,你必须正视这个问题,并将其真正融入整个游戏开发过程中,才能获取最后的成功。

我们工作室设计总监John Nash曾经说过,这么多年以来,游戏的输入设备已经发生了巨大的转变,同时这种转变也将会一直持续下去。在整个转变过程中,我们遇到了更多不同身份的新目标用户,而这就意味着我们必须在游戏开发的早期对这些用户给予更多重视,并学习不断改进我们的游戏,以更好地适应这些用户的需求。

我将在这篇文章中列举一些实例,阐述我们在Blitz Games Studios中是如何执行游戏的可用性测试。需要说明的是,比起采用直接面对用户的开发领域,我们的实例更适用于盒装游戏产品的开发。因为这是两种完全不同的模式,它们所面临的挑战和问题极为不同。

数据的价值

可用性测试的本质就是一种科学方法论,并依靠用户的游戏体验(而非他们对于游戏的单纯理解或者态度)获得一些相关的数据。可以说,这是一种实实在在的度量方法,无可争辩的数据,它反映的是用户玩游戏的实际操作行为。

虽然收集数据很重要,但是对于开发者来说,更好地理解这些数据的价值将能够帮助他们更有效地开发出一款优秀的游戏。首先,你必须弄清楚这些数据为何与你自己的游戏体验不符,与自己的期望背道而驰。

举个例子来说吧,如果玩家在游戏的某些特定区域遭到挫败,但是却能在最后因揭开谜题而大受鼓舞,这是否就是你想继续扩大的效果?还有一些玩家会在游戏中的一些特定区域由于焦虑而缓慢前行,但并非因厌烦或不知所措而致此。《Limbo》和《Dead Space》就是两个典型的例子。

在我们去年的《Yoostar 2》项目中,我们在6次测试中发现了40多个需要改进的问题,以此才能为玩家提供更“易接近”且更棒的游戏体验。

Yoostar 2测试发现的40个问题(from gamasutra)

Yoostar 2测试发现的40个问题(from gamasutra)

即便搜集到了所有数据,我们的开发团队也并不只是单纯地“扑”向每一个问题并对其进行修复。每个区域的评估结果都与我们原先的愿景以及自己设想的玩家游戏体验相悖。

根据测试调整后的结果,是否能够提高游戏的可用性或者只是让它变得更加复杂?游戏术语的改变是否也能为广大玩家理解?这些变化是否会影响游戏的一些核心元素,如游戏循环的时间或者用户正确操作游戏的能力等?你必须在调整游戏之前着重考虑这些问题,并把它们当成是最“权威”的反馈信息加以重视。

你同样必须清楚,虽然收集到的数据很重要,但有时候这些数据仅仅只需要你采用更多普遍解决方案;换句话说,也就是有些存在问题只是因一些用户所不熟悉的创新功能所引起的,你不应该忽略这一点。评估用户的期望值固然重要,但如果能出其不意地呈现游戏的独特性和创造性,也同样是我们所应追求的目标。

遵从游戏的可用性测试结果虽然没错,但是也不要将其视为需顶礼膜拜的真理,相信自己的直觉和想象也同样很重要。

尽早进行测试

当我们着手《Yoostar 2》这款游戏的开发时,我们知道,在写出一行游戏编码前,我们必须获得更多相关信息。

我们之所以知道怎么做,是因为这款游戏与其它游戏不同,它使用了新的硬件设备,即体感技术Kinect,而这也是玩家从未感受到的新体验。除此之外,这款游戏能够让玩家产生身临电影场景的体验,而这些对于他们来说都是极为新鲜又有趣的。

刚开始我们问自己“这是否是游戏吸引目标用户的核心理念,这些目标用户对这个核心理念有何期待?”以及“人们对于Kinect的看法是怎样的?”

你需要重视的另外一个问题便是如何获得用户对游戏视觉效果的反馈。而如果你想要获得这些问题的答案,唯一的方法便是询问你的目标用户。

针对于实际游戏体验操作,我们立刻联络了Vertical Slice,这是一家擅长于解决用户体验问题和进行游戏可用性测试的公司。我们给这家公司发了一份幻灯片展示,向他们陈述了我们对于游戏流程以及游戏菜单的想法,而非游戏编码。可以说这只是一份最简单的幻灯片。

我们同样也联系了一些目标用户,让他们亲自来“操纵”这份幻灯片——脱离任何控制器,只是单纯地使用肢体语言“玩”游戏,结果非常明显。下面我们将概括这些玩家对于这款游戏的期望。

预先设想的动作测试(from gamasutra)

预先设想的动作测试(from gamasutra)

从我们最初针对于游戏本身功能的测试可以看出,一些很有趣的事实变得更加清晰明了:

·职业模式是促使玩家选择单人游戏的重要原因。

·玩家想要获得双项的选择权利,即模仿自己想要的电影场景,同时又能获得具有创造性和阐述性的游戏性能,但是他们的期望结果有所不同。那些希望重现电影场景的玩家要的是更多游戏得分,而那些只想“即兴表演”的玩家则会因自己创造的一些有趣的混搭场景而大受鼓舞。

·得分机制能够有效吸引玩家再次进行游戏。在单人模式中,玩家希望知道自己的游戏成绩是否进步了;而在多人模式中,他们同样也需要知道自己是否战胜了好友。

·推出电影剪辑片段DLC的这种设想备受玩家欢迎;

·玩家希望游戏视觉效果能够融入好莱坞风格。

特别针对用户对Kinect期望的调查也获得了一些结果:

·玩家认为比起传统的方向盘操作方式,在Kinect上操作光标以进行游戏的速度相对较慢。

·玩家更希望屏幕上的选择按钮更少更简单。

掌握了这些问题,并将其牢记于心,我们重新认真地投入游戏设计以及制作过程中。这些问题不仅将成为我们日后游戏开发和完善的常识,同时也将帮助我们创作出更多符合玩家需求的优秀游戏。

两个世界的交集

我总是开玩笑地称游戏开发者是世界上最糟糕的一群人。因为我们总是处在游戏开发过程中,虽然带着满腔的热情,但却难以作出最客观的判断,可以说,我们一直封闭在自己的茧子中。但我们发现可用性测试真的是一种几近完美的方法,能够让我们获得冷静判断与创作激情之间的平衡。有一个较为简单的例子,也就是当我们制作《Yoostar 2》的Kinect用户界面元素的指示方向时,我们使用了一个简单的箭头标识,如下图:

最初的开始按钮(from gamasutra)

最初的开始按钮(from gamasutra)

这看起来真的很简单吧?我们之前也这么认为,但是我们测试了用户界面时,这个想法发生了变化。

因为这个按钮在VCR上看起来就像一个播放按钮,所以有将近九成的玩家想去摁这个按钮。但十人中就有九人如此操作后却不能继续进行游戏时,我们才意识到问题的所在了。

尽管这个按钮在游戏中已经存在着数周时间了,但是我们工作室里却没有一人对其产生质疑。因为我们都知道Kinect的使用方法,所以理所当然知道“啊,这只是一个滑轨,你只要向右移动你的手便能操纵它。”所以,我们虽然对Kinect的复杂技巧了如指掌,但却并不能保证制作出真正可行的游戏。

根据用户反馈后作出的调整(from gamasutra)

根据用户反馈后作出的调整(from gamasutra)

可以说这只是一个很容易解决的简单例子,且不会对游戏开发团队和项目进度产生较大影响。与此同时,它也给开发者打下了一剂预防针,让他们看清忽略用户看法将会造成多大的致命打击。

收集足够的反馈信息

可用性测试的一大真正重要且经常会被忽视的因素便是,你的开发团队,特别是设计者们必须能够定期收集一些外部的反馈信息。为了确保我们团队文化支持开放式交流和反馈机制,开放性思维和职业态度,我们鼓励团队成员都能够积极接受用户的反馈,并学着利用这些信息建立起合理的项发展目愿景,而不是把这种反馈当成素未谋面的第三方对他们下达的一种强制性任务。

可用性测试过程最好让更多开发团队成员参与其中,这是一种很好的鼓励方式,可以使他们成为项目成果的倡导者和宣传者,并在测试后以更大的热情重新投入于游戏开发工作。

同时,依靠游戏难度曲线的特定区域测试会也出现了一些细节性问题。最好能够按照游戏流程深入测试你所设想的玩家会在其中执行的技巧,所以要相信你所确立的难度标准,并确保能够区分真正的可用性和难度问题。

需让游戏设计师意识到这些问题的重要性,才能避免游戏在挑战关卡环节显得过于平庸。

完善游戏的重要性

我们都知道,对最后的游戏成品进行完善十分重要,但同时你也应该知道,当你在测试游戏的功能时,如果能够针对测试区域做出相应的完善,那么对于该功能的成功将会有很大的帮助。

这点对于Kinect这类型的运动控制器来说尤为重要。通过技巧性测试,你能够很容易测试游戏的一些功能,但是如果这个功能缺少基本的“润色”(也就是完善),例如音效,特效,控制效果或音乐等,玩家将不会被其所吸引,或者还会给这个功能挑刺。

因此你将会得到一些证明这个功能是“没用的”数据结果,然后开发团队将会加足马力想出更复杂的解决方法以“修复”这一功能,或者干脆抛弃这一功能。然而,如果你能在测试前对这一功能进行完善,那么你将可能看到一个完全相反的好结果,也不会浪费了自己所投入的大量精力(游戏邦注:归根结底是因为开发者的心态和玩家的期望值具有较大的分歧)。

如果你正在使用Agile开发方法(游戏邦注:这是一种应对快速变化需求的一种软件开发方法),只要你之前已经深思熟虑,那么把这种方法整合进游戏开发过程将能够大大降低整款游戏开发的难度。通过这一方法,你将能确保在完成游戏功能(功能A)后,将其投入测试中,而一旦完成测试,便能把测试结果纳入游戏的注意事项中,并在下一个“冲刺”环节中针对这些结果做出相应完善。

将用户反馈结果添加到项目计划(from gamasutra)

将用户反馈结果添加到项目计划(from gamasutra)

但当开发团队想将同样的功能引入下一环节(进一步完善),但尚未取得用户测试阶段的反馈信息时,这种方法就会凸显其瓶颈。在很多情况下,缓解这种问题的一个简单方法便是当功能A的用户测试结果进入记录与讨论阶段时,“冲刺”团队可以着手开发全新的游戏功能(功能B),并在最后的“冲刺”阶段再次回到功能A,直接把用户测试结果整合进游戏注意事项里。

反复求证

展开个体用户测试是有益的,但是你必须确保能够坚持这种反复测试,以证实你所做出的调整是行之有效的做法。

我们很容易基于一些有限的反馈信息而做出不合理的调整,并自认为这就是解决问题的“正确”方法,但最后却发现只是越改越错。这也可能是因为我们只是单纯地针对特定功能本身做出大量完善而造成的结果,这就要求我们要同时着眼于其他潜在问题。

我们的一款Kinect游戏《奇幻宠物》(Fantastic Pets)便是一个典型。当我们在第一次测试时发现,很多年轻玩家不能很好地操纵球并将其扔向宠物,特别是当他们拣球,以及小球在预定时间离手的时候。

Fantastic Pets(from gamasutra)

Fantastic Pets(from gamasutra)

对所有用户(无论长幼)来说,掌握Kinect的操作方法需要一定技巧,所以我们开始重新审视自己使用的代码和系统。

对这些系统做出一定调整,并由开发团队的内部人员对其进行测试后,我们的这款游戏得到了一定的改进,特别是在投射小球这一机制上。因此我们相信已经合理完善了这一部分问题,并准备朝着下一个测试阶段前进了。

但令人意外的是,我们在第二次游戏测试中发现,玩家对捡球这一操作仍然存在问题。我们从调查中发现问题的根源是玩家期待能够在丢了一颗球之后立刻得到下一颗球,而不是等着宠物把球带回来再继续。

玩家之所以会如此期待,是因为当小狗去取球的时候,游戏镜头会停在相同的位置上不变,所以他们希望能够借此机会扔出下一个球。一个较为简单的解决方法便是,增加一些追随小狗拣球动作的镜头,这样玩家就更容易理解他们得等到画面切换到标准镜头位置时,才能再投掷下一个小球。

如果没有这种测试过程,我们可能会误以为更改代码就已解决了原来的问题,并可能会在未根治关键问题前就将其推向市场。

总结

在Blitz工作室中,我们在游戏开发过程中不断学习并实践Agile方法;同时也在实践Agile方法的过程中定期融入游戏的可用性测试,对于我们来说这确实是一种相对简单的方式,对未来的进一步发展也极为有利。虽然在游戏开发领域里,可用性测试是一个相对较新的学科,但是我们相信,这种方法带有无与伦比的潜力,如果能够合理加以使用,我们将能够创造出更多成功的娱乐项目,并吸引越来越多类型不一的用户群体。

把游戏的可用性测试归入游戏生产线中是否意味着你需要投入更多的工作?是的。你是否因此要提高开发成本?当然。测试结果对你的公司和开发团队是否有帮助?毋庸置疑。Blitz Games Studios的目标就是创造人人都可体验,并且极具商业价值的成功游戏,而让这些目标用户参与游戏测试正是我们实现这一点的关键所在。(本文为游戏邦/gamerboom.com编译,如需转载请联系:游戏邦

Usability Testing: Face the Fear and Learn to Love It

by Chris Viggers

It’s popular, it’s a buzzword, it’s a growth industry and many developers are afraid of it, but what exactly is usability testing and how can it be used to create ever more compelling entertainment?

From a developer’s perspective, at its core, usability testing is something that tells designers, artists, coders, animators and managers what they are doing wrong.

It is human nature to try to avoid any sort of pain (mental or physical) and many of us struggle to accept criticism, even when that feedback could lead to a better end result.

In addition to the problems of essential human nature, the games industry is changing even more rapidly than before and our creations are being experienced by more and more people, and ever more diverse demographics, each one with their own expectations of how they want to be engaged while spending their precious time on our games.

Why Usability Test At All?

As any producers reading this will testify, during development you are always acutely aware that you never have enough time, enough money, or enough resources to achieve what you really want to achieve with that game.

Adding yet another process into your production pipeline is going to be a difficult sell both to the team and to upper management, especially when that process is highly likely to result in rework to fix the problems that the players are flagging up.

However, the reality is that your game is going to be tested at the end whether you like it or not, and that testing will come in the form of a review or Metacritic score. If you ignore end user feedback and usability results during development, you run the very real risk of getting poor reviews and feedback that will publicly damage your game and reputation. Facing up to this fact and integrating this with your development pipeline is key to success.

Our studio design director, John Nash, has already talked here about how input devices for gaming have changed massively over the years and are continuing to do so.

This, combined with the huge variety of new target audiences, means that we need to not only embrace player input at a much earlier stage in development, but also learn to adapt our work flow to accommodate this input.

In this article I will outline some practical examples of how we did this at Blitz Games Studios, in this case focusing more on boxed product development rather than direct-to-consumer development as the challenges are very different.

The Value of Data

Usability testing is firmly rooted in scientific methodologies and relies on generating data from the user experience of the game that is independent of what the player actually thinks about the game (or rather, what they think they think about the game). It is about hard metrics, unarguable data and demonstrating how the player is actually playing the game.

It is not only the collection of data that is important; understanding its value is clearly critical to being able to maximize its effectiveness in development. The first thing to look at is how does the data you have collected stack up against your game’s experience and the core pillars of your vision?

For example: was the user frustrated in a certain area, only to be elated when they finally solved the puzzle, and is that something that you actually want to maximize? Or were they scared during certain areas and moving slowly through the environment due to their anxiety, rather than just because they’re bored or lost? I’m looking at you, Limbo and Dead Space!

To provide a concrete example of how specific user testing helped on one of our projects (Yoostar 2) last year, over six sessions of testing we found that more than 40 individual items required further attention to ensure that we maximized accessibility and experience for the player.

Even with all this data collected, the team did not just jump on each issue and attempt to fix it. Each area was assessed against the core pillars of the vision and what we wanted the player to feel during the experience.

Would this change result in the game being more accessible or more complicated, would any change in terminology be understood worldwide, or do any of these changes affect core aspects such as the timing of the game loop or the user’s ability to get right to the action? These are all questions you need to ask yourself before amending any parts of the game, even with the most ‘expert’ feedback in front of you.

It is also worth remembering that although the data you get back is important, some of the results you get will point to the need for more generic solutions; in other words, some of the problems are caused by developing innovative features with which people are not already familiar. Assessing peoples’ expectations is great, but surprising them with unique and innovative ideas is also something we should be striving to achieve.

Accord the usability results all due respect, but do not treat them as gospel: trust your instincts and your vision as well.

Test As Early As You Can, If Not Earlier

When we embarked on the Yoostar 2 project, we knew that we needed far more information before we wrote a single line of code.

We knew this because it was a game that not only utilized brand new hardware that no one at the time had yet experienced (Kinect), but the game also gave players the ability to directly star as themselves in movie scenes — something fresh and new to the audience.

The first questions we asked ourselves were “Is the core concept of the game going to appeal to the chosen demographic, and what do they expect from the concept?” and “How do people expect to interact with Kinect?”

An additional and important issue was to capture feedback on the visual styling of the game. There was only one way to get answers to these questions, and that was to ask the people at whom the game was targeted.

With regard to actually navigating and playing the game experience, we immediately contacted Vertical Slice, a company who specialize in user experience and usability testing. We sent them a PowerPoint presentation of what we thought the game flow and menus might look like — no code, just plain slides.

We also took our ideal target audience and got them to “play” the PowerPoint, standing up, with no controller, using gestures. The results were stark. An overview of players’ expectations is shown below.

From our initial focus test on the game features themselves, a number of interesting facts became immediately apparent:

The Career mode was unanimously viewed as a highly motivating reason to play the single player game.

Players wanted the option to both copy a scene accurately and to do a creative, interpretative performance, but their expectations of the results varied. Players who wanted to copy accurately wanted a score, while those who wanted to ad-lib were motivated simply by creating humorous pastiches.

Scores were also reported to be important for replay value; the players wanted to know that they were improving if in single player mode, or that they were beating their friends in multiplayer.

The possibility of DLC for further film clips was well-received.

The players expected Hollywood style imagery to be part of the visual style.

With regard specifically to people’s expectations of how to use Kinect, a selection of the findings were:

People found controlling a cursor to be much slower than traditional pad navigation.

People expected a few simple options on screen rather than many different choices.

We took these results back to the team and then started work in earnest on the game design and game flow with this information in mind. Again, this information seemed like common sense in hindsight, but at the time these pointers were valuable in creating something to which the target audience would really relate.

When Two Worlds (Don’t) Collide

I always joke that game developers are the worst people in the world to make games. We are so close to the process and so passionate about what we do that making objective judgments can be difficult, if not impossible, when we are inside our bubble. We have found usability testing to be a near-perfect way to address this all-important balance of passion with calm judgment. A simple example of this would be when we decided that to indicate the direction of one of the Kinect ‘rail’ UI elements in Yoostar 2, we would use a simple arrow:

That seems perfectly simple, doesn’t it? We thought so too, until we tested the UI.

90 percent of users wanted to push the button, as it looked exactly like a play button on a VCR. The first button in the game and nine out of ten people could not get past the first screen: we had a problem.

Although this was in the game for a number of weeks, not one person in the studio had questioned it. We all knew how Kinect worked and thought “Ah, this must be a rail so you swipe your hand to the right”. All that detailed technical knowledge of Kinect and how to make games actually worked against us in this instance.

This is a simple example and thankfully something that was incredibly easy to fix with little impact on either the team or the project schedule, but it beautifully illustrates the dangers of game developer thinking against a real user’s perspective.

Feedback? Bring It On

A really important element of usability testing and one that many people might overlook is the need to prepare your team, especially your game designers, for getting external feedback on a regular basis. By ensuring that our team cultures support open communication and feedback, an open mind and a professional attitude, we could encourage people to accept the feedback and learn to use the data in conjunction with the established game vision, even to welcome it, rather than seeing it as a list of extra tasks dictated to them by a faceless external third party.

Including as many team members in the actual usability sessions themselves is an excellent way of encouraging buy-in, and it also creates advocates and ambassadors who will enthuse about the process back in the studio.

Testing areas of the game depending on difficulty curve can raise some delicate issues as well. It is important to test further along in the game flow where you would expect real players to have built up game skills, so trust your difficulty matrix and make sure you distinguish between a real usability issue and a difficulty issue.

Training your designers to recognize these is crucial to ensure that your game avoids becoming generic with regard to its challenge levels.

The Value of Polish

We all know the value of polish to the final game assets, but it is also important to note that when you are testing functionality, the value of polish to the area you are testing is key to the success of the feature.

This is of critical importance with motion controllers such as Kinect. It is all too easy to get a feature to a functional pass where technically you can test it, but if the feature lacks basic polish such as sound effects, graphical effects, some control polish and music, the user will most likely reject or have problems with that feature.

This then gives you data showing the feature has “failed”, and the team then either spins its wheels coming up with (usually) more complicated solutions to “fix” the feature or abandon it altogether, whereas in reality a little polish before testing would have made the results more meaningful and saved wasted effort. (Again, this comes down to the sometimes risky dichotomy between the developer mindset and player expectation.)

If you are using an Agile development methodology, integrating this into your process can be fairly simple, as long it is thoroughly thought-through up front. It is relatively easy to ensure that as soon as a product feature is complete (Feature A), you enter (at least) that feature into test; once the feature is tested, you take the findings and add these directly into your product backlog for the project, then deal with the relevant items during the next sprint.

Integrating user testing feedback into your sprint planning

The traditional bottleneck in this method comes when the team wants to move onto the next stage of the same feature (further iteration), but have not got the report back yet from the user testing phase. A simple way to mitigate this in most instances is to have the sprint team move to a new product feature (Feature B) while the Feature A user testing results are being recorded and discussed, and then move back to Feature A for the final sprint, incorporating the user testing findings directly into your backlog for that sprint.

Iterate and Validate

Holding individual user testing sessions is useful, but ensuring that you follow up with regression sessions specifically dedicated to testing out the changes that you make is essential.

It is very easy to fall into the trap of making a change based on limited feedback and assuming that this is the “correct” fix for that issue, only to find that you have actually made it worse. Again, this can be due to the amount of polish on a particular feature over the feature itself, so that possibility should also be addressed.

One example of this was with our Fantastic Pets Kinect game, where we had reports from the first test that many of our younger users were having trouble throwing the ball to the pet; specifically, the problem lay in picking up the ball and also the ball leaving the hand at the expected time (sticky ball syndrome).

As it can be very tricky to get gesture recognition on Kinect right for all users, whether young or older, we took another look at the code and systems we were using.

Having made some tweaks to the systems and tested them internally with the game team, we saw some improvements, especially with launching the ball. We therefore believed that we had improved this aspect ready to go into the next test session.

On the second test session we were horrified to see that players still had trouble in picking up the ball. After further investigation, we realized that the problem actually lay in the player’s expectation that they should be able to throw one ball directly after one another, rather than wait for the pet to bring the ball back to them.

The players thought this because the camera was in a fixed position while the dog went to fetch the ball, so they just expected to be able to throw another one. A simple fix to add cinematic cameras that followed the dog during the retrieval of the ball resulted in the players understanding that they needed to wait until the view returned to the standard camera before they could grab the ball and throw it again.

Without this regression session, we would have assumed that we fixed the issue in the code changes that we made and could have shipped the game without addressing the real root cause.

Summary

At Blitz, we all read and practice Agile methodologies for game development; integrating usability testing at regular intervals into our Agile process was therefore a relatively easy step forward for us, and something that we will definitely continue to maximize for the future. While usability testing is a relatively new science with regard to its role within game development, we believe that it offers unmatched potential in creating successful entertainment for an ever-growing and broadening audience.

Does factoring usability testing into your pipeline mean more work? Yes. Does it add cost to your project? Definitely. Are the end results worth it to your company and your teams? Without a shadow of a doubt. Our passion at Blitz Games Studios is to create critically and commercially successful games that everyone can enjoy, and testing our games with the people who matter is key to achieving this into the future.(source:gamasutra


上一篇:

下一篇: