因为可汗游戏大会的开放区可以随便玩、甚至可以通宵玩,我带了4款正在开发中的游戏过去测试,美式、德式、聚会、推理、九卡都有。
即便你在游戏设计前期做了大胆创新、结构上下了几吨心思、打样时抱有美好期望,都要在测试阶段迎来检验。
测试方式、测试人群、测试次数、测试目的、测试结果、测试反馈、版本迭代。← 接下来我会按照会按照这个顺序来行文,以便把这个事情讲得更清楚。
因为我要观察参与测试的玩家的反应,这包括玩家的游戏行为、策略选择,也包括玩家的肢体语言和微表情。
有些事情玩家是没办法告诉设计师的,或者他们不觉得是问题,或者他们不擅长把这种感受描述、反馈出来。比如你设计的游戏里玩家可执行的行动种类过多,再比如你卡牌上的文字描述有歧义,都会让玩家产生片刻疑惑。如果是线上测试,你很可能会漏掉这两个设计中存在的问题,因为玩家在短暂的疑惑之后适应了你糟糕的设计,不觉得这个事情需要给你反馈。如果该玩家是个关注细节的热心人,也许会提出来,但多数时候你不能获得这个信息,获得了也大概率不会准确。
我没有TTS,也拒绝过几次线上测试的邀请,我宁愿跑桌游吧或桌游聚会、展会。
作为一个前万智牌手,我深知玩家的动作、表情可以给人的游戏反馈多么有用。对,我就是那个一手地牌,但面如平湖的无情红烧机器。
有些时候会有朋友表示,你可以把游戏原型寄过来,我们玩完了给你个反馈、帮你测测。
理由一样,我认为文字反馈是冷冰冰的、带来的信息量不足够的。
去桌游吧找玩家测试、约人组桌游局测试、去桌游展会测试是我最常用的测试方式。在这些情境下,你可以遇到不同类型的玩家。
你可以在新人玩家玩你的游戏时观察到你的设计有哪些不符合人性的地方,会使一个甚少接触桌游的玩家不知该如何是好。他们没有玩桌游的习惯时,往往以自己认为最正确的方式操作。这给了你很好的修改方向——基于人的直觉,你应该把游戏调整成这样。
你可以在老桌游玩家玩你的游戏时获得更有用的修改建议,因为他们很有可能玩过某款游戏在类似的状况下有更好的呈现方式。吃惯了珍馐美味的美食家们,对你这盘土豆丝儿可就太有话说了。
我最近很长一段时间以来的感受是,做产品没有什么最好的解决方案。合适的就是最好的。
你不必找最好的插画师画插画,只要成品插画足够适合你的游戏主题、足够对应你的产品用户,就是最好的。
测试次数也是一样,如果游戏结构简单,得到的测试又是有效的,那很可能少量的测试就可以让你完全了解这个游戏的状态。当然,进行次数越多的游戏,你越可能找到游戏隐藏很深的问题。
结合前两个点,如果你找的测试人群合适、又对他们进行了认真的观察,达到了切实有效的的测试效果,即便没有经过几百局的测试,你依然可以很完美的为测试这个环节画上句号。
在测试游戏时,不同的阶段,你的测试目的应该是会改变的。
“掀桌”是桌游玩家之间的黑话,代表不玩这垃圾游戏了,换下一款。首次测试游戏时,你要做好充分准备。
一必须要让玩家可以对游戏充分理解,这份理解包含对游戏规则的理解、对游戏体验的理解。
二尽量让玩家能玩完所有流程,以验证这游戏在你脑内可以运作、在游戏桌上也可以运作。
接下来的测试,我们的目标除了要继续验证游戏可以流畅运作、带来乐趣之外,主要目的变成了“上次测出来、我修改后的问题有没有得到解决或改善”。因为在首测之后,你几乎一定会发现问题、并且对之进行了修改。现在你要看看你的修改是不是奏效。
最后阶段的测试,游戏已经很好玩、很丝滑了,我们的目标变成了查缺补漏,“找一找游戏有没有隐藏的BUG还没有被我们发现”。
首先你必须掐死“我的设计很好,玩家没有GET到是他们的错”这种念头,因为即便真的如此,让他们GET不到也是你的错,你得试试其他呈现方式。何况更多时候,就是设计很糟糕,并没有把你想要传达的内容传达到。
询问你的测试对象,具体是哪里觉得不好,并加以记录。
哪怕首测被掀桌了,你也要沉着地想想,是某个紧关节要的地方处理不妥让玩家觉得荒唐不玩了,还是自打玩家开始游戏就觉得这游戏不行,累积到量,让玩家无聊到再也不想继续下去了。
测试时你要备好纸笔随时记录你发现的和玩家反馈的问题。
然后一旦你回家,请立即去电脑前,将记录的问题整理成反馈文档。
在反馈文档完成后的一段时间里,可能是几小时也可能是几天或几周,你要想尽办法在文档的每一条问题后面写上改善方案。
你必须权衡某个具体问题是需要小修小改还是结构上大调整,甚至是干脆删掉这部分。
以上基本聊得比较全面了,如果有相关游戏测试的话想和我接着聊,就评论区见吧。
最后,4号5号,来可汗游戏大会的朋友,来找我测试桌游吧!
评论区
共 1 条评论热门最新