终於有时间可以来更新
我感觉我低估了自己的忙碌程度Orz
------------
其实，每个人都了解「测试是很重要的」
也会很频繁的对自己的游戏进行测试
但我想在初期测试的时候往往会遇到一个情况
"每个建议都很有道理
这次改了几个，下一次又改了另外几个
但是马上又出现了新的建议，又进入了下一批的修改"
以上的这个状况牵涉到两个重要的问题
第一、该怎麽选择性修改？
第二、何时算是修改完成？
针对第一个问题我一向是在测试中进行下面这样的流程
首先我会先提出我目前在这个游戏过程中感受到的问题或是一个待解决的状况
再来我会询问设计师对於这个部份的看法
最後再根据设计师的回答做出反馈
我简单的说明流程各个部份的操作重点
最开始必须告诉大家（包括参与测试的人），你的焦点放在哪个部份，也就是这个反馈的标的对象
最主要的原因是为了让讨论不要失焦，在这个议题的发言期间大家都一起把目光放在这个部份
这里会牵涉到一个比较核心的技能"对游戏的拆分能力"
必须理解，一个问题往往是因为多个问题的相互影响而造成
所以一个测试人员能够将发生的问题细化到什麽层级，会对这个流程的效率造成最核心的影响
再来为什麽要询问设计师的看法呢
这是因为我们需要先了解，设计师当初在设计这个部份的时候
具体是因为什麽想法，以及期望他能达到的效果之类的设计思路
可能他有一个预期效果，只是表现的不是太好
当然也有可能他并没有预料到会是这个状况
或是他根本没想过
但不管是哪个状况，这里的目的是希望设计师能够尽可能针对这个部份说出自己的想法
所以在这个阶段，设计师的思路越清晰，越能清楚的表述、回覆
就可以更快速的进入下一个阶段
而此时参与测试的人也都了解了设计师的看法
就可以开始进行讨论、反馈
有些时候这个部份的体验是设计师期望造成的效果
那整体讨论可能就得往如何更加强化这个目标效果，或是检讨有没有真正达到这个目标效果
并提出针对性的修改方案
但有些时候设计师其实并没有特别想到这个部份
那整体讨论可能就会倾向於修改这整个造成问题的部份
甚至有可能会导致讨论的核心放在这个部份存在的必要性与否
之所以提出上述这个流程的最主要原因是因为
不同的人会对对游戏有各种不同的看法
这同时导致了100个人就可以对游戏提出100种不同的改法
最糟糕的部份是在於，这100个人讲的可能都没错
所以透过一个这样问答的流程
可以更加清楚的理解设计师的框架，并且针对性的进行讨论得出结果
藉以避免进行过多无谓的修改
但是，这也就是说，如果设计师自己对这个游戏没有明确的框架
基本上讨论是无止尽的，修改也是无止尽的
毕竟你永远有办法提出新的机制或改动让一个游戏似乎变得更有趣
因此下面要接着提到的就是设计师应该如何去对自己的游戏规范一个框架
这同时也是第二个问题"何时算是修改完成？"的最关键部份
-----
长文待更
我以为我能把两件事一次写完
然而无法Orz
