最有价值的玩家反馈

OwenTsai

撰写了文章 更新于 2017-06-16 21:15:21

评论 18

Hyhz 1年前

很好的想法,基于这些点,我觉得评测者可能都不需要把评测公布出来(测试阶段的评测很可能给不了解野蔷薇流程的普通玩家造成误导,或者野蔷薇的评测只给有野蔷薇资格的人看)。评测少加修饰和措辞,发给开发者,并进行简单的互相沟通可能比较好。

OwenTsai [作者] 1年前

@Hyhz ‍ 对,但是毕竟野蔷薇除了正在迭代的作品外,还有已经开发完成准备为最终launch宣传推广的游戏,这时候反馈的意义就不大了

snougo 1年前

如果不方便现场视奸,最好的反馈方案还是有玩家录下的第一次游玩的影像

OwenTsai [作者] 1年前

@snougo ‍ 最好还要加上玩家的录音,比如“我认为这个可能是打开门的机关,我来试试看能不能把门打开……哦并不行,我可能需要先为发电机供电”之类的解说,能够方便开发者了解玩家在想什么,他们的感受是否和设计师想得到的感受相同

琪露诺 1年前

个人觉得作为评测者,努力站到制作者角度是更有价值一些的(而不是反馈作为玩家的感受)。如果只进行感受的反馈,那么评测者起到的作用就相当于进入了统计数字之中,失去了本来应该去承担的一些……义务?(另外一个角度是我觉得野蔷薇看上去更加侧重深度而不是量。)听说文学分析有一种“尽量理解作者意图然后看表现手法有没有达到意图”的方式(当然这意味着 1.准确理解作者意图;2.站在作品的角度考虑自己提出的建议)。我觉得如果想作为“评测者”而不止“玩家反馈”,也许这是值得努力的方向吧?换句话说,评测者有义务提出感受之外更多的看法, 但是在提建议的时候需要非常谨慎?


顺便,之前看到朱宥勳关于文学评论的论述中提到的,“我们必须尽可能以文本中呈现了什么来作为评价依据,而尽可能批评文本中没有呈现什么”,也许同样适合游戏评测。虽然和上面说的“描述你看到的内容”角度不太一样,不过目的上也有异曲同工之妙吧?


摘录一段:“而為什麼會有這條紀律呢?因為任何文本都有篇幅上的限制,不可能毫無節制、包山包海地一路寫下去。如果彭教授這種「從虛空中生出問題」的批評方法可行的話,那理論上所有的作品都會是劣作,我永遠都可以說某作沒寫性別、沒寫族群、沒寫階級、沒寫科學、沒寫宗教、沒寫倫理⋯⋯這樣的地圖砲,終究只是讓文學批評成為一場虛無的嘴砲秀而已。這通常好發於喜歡在演講場合中以發問之名、秀「我很有想法」姿態之實的生嫩聽眾,發生在堂堂貫通人文學理的教授身上,著實讓人訝異啊。”

OwenTsai [作者] 1年前

@琪露诺 ‍ 没错的,但是本文只针对处于迭代阶段的游戏评测。在这个阶段需要设计师比对玩家的感受和他们设定的体验目标。如果玩家的感受达到了体验目标,那么说明基本达到了迭代的最终目的;如果玩家反馈上来的感受和事先设定的体验目标出现偏差,那么设计师根据玩家反馈的感受可以分析得出问题出在哪里。所以玩家的感受是必要的。
提出感受之外的建议也是必要的,在相当多的时候可以启发开发者。

琪露诺 1年前

@Owen Tsai ‍ 这样说的话,这是相当前期的工作了……一直以为这是制作组内部可以完成的,不过换个角度想一下让对游戏开发过程“没有剧透到”的玩家来参与这个环节,确实也是很有好处的吧……

OwenTsai [作者] 1年前

@琪露诺 ‍ 事实上像这样一遍遍的迭代贯穿着整个开发流程,从游戏还是一个原型的时候就开始接受玩家的测试。测试,接受反馈,修改;再次测试,接受反馈,再次修改;再次测试,再次接受反馈,再次修改直到达到预期……有很多项目就死在了这个迭代过程中……
所以请玩家评测确实是很重要的事情

扎克 1年前

嗯,基本同意文章的观点。下面的评论不是针对文章的。
先抠字眼,评测,也许是测试和评价,也许是对测试的评价,也许就是评价的意思。所以我不喜欢这个词。评价和测试属于两个行为。评价的主要受众其实是玩家,即为其他玩家提供是否值得购买/关注的参照。测试反馈的主要受众是开发者,即把问题展示给开发者。至于游戏批评,则又是学术层面的东西,跟这两者又不太一样。因为受众的不同,这些行为也有微妙的不同。总得来说,评价是很爽的,因为会有很多人读到。测试是略苦闷的,因为你面对的只是开发者,他们也并不需要你的很多天马行空的想法。游戏批评是只有自己能看懂的……(雾)

我不反对玩家评价或者给测试反馈的时候提出这样那样的建议,只是要求玩家不会强求团队按照他们的意思来。其实玩家给建议,本身也说明游戏某个地方出了问题,只是并不一定在玩家所认为的地方。对于开发者来说,玩家说得越多越好。只是希望玩家不要通过建议来概括他们的体验,反而错过了重要的部分。所以玩家什么都说是最好的。但是玩家又不一定足够敏感,可能很多体验无法到达意识层面,或者无法被记住,或者无法用言语简单概括,或者概括完了就成了某个建议。这也无可厚非,错误的建议也是有价值的(只不过不是最有价值)。

人机交互有专门的 User Testing 科目。最敬业的测试的做法是 Think aloud,把每个时刻自己脑海里想的东西都说出来。有个小故事,Hacknet 和 Expand 的作者是好基友,Hacknet 上线前作者把游戏发给了 Expand 的作者,于是后者通了关,并录了个很长的视频,把他每个时刻的即时反应都讲了出来。于是 Hacknet 上线前一顿调整,上线非常成功。(然而 Expand 卖得很惨)

OwenTsai [作者] 1年前

@扎克‍ 啊,是的。think aloud也有很多前辈和作品提到了。但我目前还没有经历过一个完整的迭代流程,有点怀疑教科书上写的是否可以直接使用

琪露诺 1年前

@扎克‍ 在试玩游戏(比如sin castle等等)的时候我采用过类似think aloud的方式,不过可能没那么即时,而是想到什么随手用txt记下来(也算是测试RPGMaker游戏的时候努力养成的习惯吧)。我觉得原始的内容也许会比较散乱(没有组织过),并且可能浮于表面,需要自己最后再看一遍,并且把想法和游戏进程关联起来,努力寻找里面共通的地方,整理成成型的文字,才更有参考价值吧。另外一点大概就是写txt可能需要刻意提醒自己一下,而一边玩游戏一边录音更加随意也更加有即时性了(尽管个人偏好上还是偏向文字……)

扎克 1年前

@琪露诺 ‍ 跟对原始游戏状态所有需要关联起来的东西尽量完整的记录相比,你整理的文字(这是一个抽象过程)更有参考价值当且仅当你比游戏设计师的水平高,而且高出一个级别(毕竟你没人家了解人家的项目)。

扎克 1年前

@琪露诺 ‍ 这是我的看法。

扎克 1年前

@琪露诺 ‍ 应该说从表面的症状找病因是设计师应该做的事。不过你用think aloud的方式研究游戏还是挺仔细的。

琪露诺 1年前

@扎克 ‍ 啊,不一定是深入分析的意思(深入分析肯定会比设计师缺乏大量的经验、专业素养和信息)……也许只是初步的整理,比如最初记录下的想法是零散不直观的,整理成还算“成文”的内容?
又想了一下,也许不同玩家的习惯也不同,有的玩家在记录下或者表达出的步骤之前,就已经完成了“预先整理”的步骤,这样就自然可以免去下一步啦。

k5 1年前

很少写评论,但是这篇文章还是决定顶一下,写得很中肯,可以作为野蔷薇测试人员教科书般地建议。
在才疏学浅的我看来,测试首先找bug,没bug找错误,没错误找不合理。
bug就是程序运行问题。
错误就是程序中数值错误,文本错误,逻辑错误等等
不合理就是程序体验中感觉需要改进的地方,游戏体验不合理的地方。

OwenTsai [作者] 1年前

@k5‍ 但事实上这个反馈方式只应该在iteration process中存在,游戏因宣传推广之类的原因进入野蔷薇,那么playtest的意义也就不大了

音之幻风 1年前

@k5 ‍ +1,这种方式不太好写进野蔷薇的评价中,倒是跟开发者直接沟通时可以这样做。如果看到bug和错误都写进去,一方面很容易让大家产生“这游戏很糟糕“的感觉,另一方面,开发者修了这些东西而自己没来得及更新,就会进一步出现误解。

登录奶牛关账号即可参与讨论