[论文笔记] Action as Space-Time Shapes

Paper：Moshe Blank, Lena Gorelick, Eli Shechtman, Michal Irani, Ronen Basri, Actions as Space-Time Shapes, IEEE Transactions on Pattern Analysis and Machine Intelligence (PAMI ’07), 2007

---

问题描述：文章将人在视频中的运动看作是身体（torso）和四肢（limbs）做连续运动的轮廓图的集合，因此可以用Space-time volume（STV）来表示人的运动。文章将2D图形的分析方法借鉴到3D，应用泊松方程（Possion Equation）于STV，再提取如Space-time Saliency、Action Dynamics、Shape Structure和Orientation等时空特征。这些特征可以用来检测和识别人体的动作（Action Recognition/Detection）以及动作的聚类。

传统动作识别的方法虽然也能得到不错的结果，但各自都存在一些局限。如，基于光流的方法会受到空洞、表面平滑度、不连续性的影响，基于特征跟踪的方法在存在自遮挡、外观改变和重初始化问题的情况下会面临很多困难，而基于关键帧或关键特征的方法则忽略了动作的时序特征，另外一些基于周期性分析的方法则只限于识别据有周期规律的动作。因此，近期一些动作识别的工作都将眼光放在了同时据有时序和空间特征的STV上。（译自原文）

STV由一系列从视频中提取的2D轮廓连结而成，同时包括了人体的姿势和动态信息。不同于一些相似的基于STV的论文——他们基于STV的表面提取特征，这篇文章的方法应用泊松方程来提取STV的各种特征（包括局部的Space-Time Saliency、Space-Time Orientations特征和全局特征），得到其在应对轮廓边界可能存在的噪声时显得更加鲁棒（得到的结果类似于动作的粗略骨架，对于分析动作很有用）。
   

这种方法的主要优点在于：
1. 不需要帧间对齐（Video alignment）；
2. 计算复杂度与STV的采样点个数线性相关，文中言其处理110*70*50 presegmented视频只需要30秒不到的时间（Pentinm 4，3.0 GHz，Matlab，挺快的）；
3. 这种算法可以用于处理低精度的视频。

[Handii] 忙活了一个月，总算有个样子了

一个暑假半偷偷地在做这东西，最近又是老板又是作业的deadline，搞得我很崩溃。不过好在，差不多有个样子了。好不好用的再说，以后可以慢慢改~

起了个自己很得意的名字，叫“Handii”。Hand是因为用手交互，ii是为了像可爱的Wii同学致敬。听起来好像狗狗^^
实现了一些基本的手势交互，能做大概所有鼠标能做的事情，移动啊，点击啊，双击什么的。但是精度不高，也就是个能拿来玩玩的程度，还要多多努力啊。
还做了个3D俄罗斯方块，用Handii玩的，不过3D的俄罗斯方块真的好难。。。（我偷偷地设定了只要填30%的格就能消掉一行，不然死定）做得很赶，连计分板都没有。

因为想要做成一个随便什么人都可以拿来玩的东西，给用户最大的自由和最少的困扰，所以用了大家都买得到的网络摄像头，摄像头的位置也没有约束，考虑到成本也没用上双摄像头，也没有用特别的背景。通通这些都给后来的设计和实现带来了很大的挑战。摄像头的帧率不高，如果动得快就一片模糊；没有深度信息，做不了精确的定位；背景很复杂又常变化，摄像头好动不动突然自以为是地改变亮度，还有其他肤色部位（我的脸、我的手臂），所以不得已地用了指套。和SixSense的想法一样~，不过我最初设想的时候可不知道他们。如果可以的话，以后想要尽可能地把指套脱掉。

      
简易指套（做起来很简单的，彩条+双面胶）              姐姐我的手，还有京东上买的19米的摄像头

  
  
一些能识别的手势：Catch / Release / Click / Double Clicke / Point

以后抽空偷偷接着做~ 持续更新撒~

完结！大年番~ 钢炼~！

周日时一集可有可无（还是有好10~20%）的大团圆各种福利后，钢炼TV Anime步漫画后尘地完结了。这一年里最大的追逐游戏结束了（另一场系福山大叔的龙马传）。

上一部Bones自由发挥的钢炼结局的意味深长，看完后数天总觉郁闷不止；所以果然还是Happy Ending来得舒心，各种和谐，各种福利~

 

# 炼金术师式新表白法！

  
 

 

# 各种和谐~

  

当皇帝咯~ 还是么眼睛。。（pia~）

  

大佐你最赚了，眼睛好了，还抱得美人归（小胡子。。成年的男人都这样吗。。）

知道是谁吗？！！！！（好好捏）

yoho~！结婚咯~ 生娃咯~ 成双成对咯~（你们了解的，谁和谁一对，不了解的去撞墙）

高兴的辫子都不梳了，红衣服也不穿了

 

# 最后附上宅男大杀图一张

温蒂你真是一语惊人啊~！

[论文笔记] Game Over: Learning by Dying

Paper：Grammenos, Dimitris. Game over: learning by dying. In Proc. of CHI 2008 (Florence, Italy 2008), ACM

---

问题描述：这是一篇关于游戏开发者如何更容易地理解游戏的可亲性（Game Accessiblity）的文章。作者设计和开发了一款名为“Game Over！”的游戏，帮助开发人员认识游戏可亲性的重要性，并学习关于其的一些原则和指标。这是世界上第一款“Universally inaccessible game”。此外，作者还通过多种渠道的调查，系统地评估了该游戏所起到的效果。

“Game Over！”的灵感来自于1986年发行的视频游戏“Takeshi's Challenge”。它由一个十分讨厌视频游戏的人（北野武，知道他是谁吧）参与企划，在游戏中几乎打破了所有的视频游戏原则，设计了N多无比变态苦役的任务，比如按某个键4小时、唱歌1小时或者打Boss20000次，号称“还没有开始就Game Over的游戏”（但令人称奇的是，如此变态的游戏，居然在日本大卖，当然也因为它是如此变态，它也只在日本卖）。私以为，“Takeshi's Challenge”真正的好玩之处在于它挑起了玩家抵抗变态设计的兴趣，使得他们想尽一切的办法来方便地完成这些变态的任务，而寻找trick本身是十分有趣的。比如，对于“按键4小时”这个任务，拿重物代替手指按住按键就是个很好的trick，玩家所需要做的只是等待、并在4小时后回来观察结果。这款游戏可能是在无意中打开了一种新的解谜游戏的模式。当然，这是题外话。

游戏的可亲性（Game Accessibility）指的是游戏是否能被玩家所参与，私以为与游戏的可用性（Usability）十分相关，但可亲性更加基础些。可亲性理论认为，有一部分玩家无法玩游戏是因为他们自身物理上、感知或者精神上的残疾；但是另外一部分玩家，是由于不好的游戏设计，而无法充分体验其中、甚至根本无法开始它，如：
1）运行时的环境。在一个十分嘈杂的环境中玩游戏，玩家可以被认为是条件性地失聪的。而在一个十分亮的环境中（太阳底下），玩家则是条件性地失明的；
2）玩家使用的硬件和软件环境也会对游戏体验造成影响，比如移动设备的小屏幕、旧型的浏览器或者不同的操作系统，都会对游戏的兼容性提出挑战；
3）最后，由于不同玩家的游戏技巧和喜好不同，也会造成游戏的不可亲性，比如对于一个十分不喜好或者不适应按各种组合键玩格斗游戏的人，好的设计就应该提供其他的可选按键方案。

游戏可亲性是评价一款游戏好坏的一项十分基本和基础的标准，它是衡量隔阂在玩家与游戏之间的障碍的尺度。没有可亲性，谈论可玩性是没有意义的。
因此，有一些组织一直致力于提出和不断完善游戏可亲性的指标（Game Accessibility Guidelines），如GASIG在2004年发布的与此相关的白皮书。但是不幸的是，这种文字指标在实际应用中表现得十分低效和不可用，这主要是因为它们常十分抽象而难以理解，以致于开发人员虽然记住了很多指标，但在遭遇具体问题时却下意识地忽略了它。并且，这些指标有时是相互矛盾的，单条指标在解决了一些问题后偶尔会产生新的问题。
设计人员还可以通过一些反面的例子来学习什么是好的设计，这不是什么新的点子。有一些网站一直在做这样的事情，提供各种各样坏设计的例子，包括真实的产品和软件交互界面等，比如Bad Human Factors Designs，Interface Hall of Shame和Worst of the Web等。相较于抽象的指标，这是一种比较能够让人获得深刻印象的方法。那么，既然最容易让产品设计师吸取教训的方法是浏览失败的产品设计，我们是不是可以认为，让游戏设计师认识可亲性最快捷有效的方法是体验不可亲的游戏呢？是的，这就是此文所设计和开发的世界上最不可亲的游戏“Game Over！”。
普遍认为，游戏开发者大多都是爱玩游戏的，并且，他们中的大多数能够十分清楚地记忆他们所玩过的最好玩的和最不好玩的游戏。当他们在一款失败的游戏中体验到某一种失败的设计后，他们就变得能够认识到与其相似的其他失败设计，并在今后的设计中避免它们。并且，有研究表明，在人的记忆中，一款好玩的游戏可能被另一款更好玩的游戏所覆盖，但是所有曾经遭遇的糟糕的游戏体验都会被清晰地记忆——“Notable failures last for a lifetime“。因此，我们似乎可以预见，“Game Over！”将是一款让人印象深刻的游戏，因为它涵盖了太多无比糟糕的设计。

“Game Over！”作为一款游戏可亲性的学习工具，作者认为应当满足以下要求：
1）Easy：容易。简单。有一个众所周知的目标和游戏机制。这使得游戏玩家可以方便地理解游戏中存在的问题以及造成问题的原因；
2）Break：直接、明显地破坏游戏可亲性原则；
3）One Rule：一次只破坏这些原则中的一条，这使得识别问题所在变得简单；
4）Major：覆盖这些原则中主要的、典型的部分；
5）Advice：在给出这些可亲性原则或概念的同时，针对每一条，给出相应的解决问题的建议；
6）Humor：幽默。这是为了让游戏本身变得有趣；
7）Platform：能够在尽可能多的平台上运行。

基于这些要求，作者挑选了一个射击游戏作为“Game Over！”的蓝本。玩家被设定为一个乘坐飞盘的外星人，抵抗地球人的舰队对宇宙的进攻。这个故事与我们所熟悉的拯救宇宙的故事是恰恰相反的，以强化“Game Over！”与正常游戏的逆关系。游戏共21个关卡，过关条件是失去3条命，即所谓的Learning by Dying（作者认为，好的游戏设计应当总是给出一些提示玩家如何去赢的线索——无论它多么困难——这样即使玩家失败了，他也只会抱怨自己不够厉害，而不会抱怨设计者变态）。在每一关结束，屏幕上会给出与之相关的名言和可亲性原则等，帮助游戏开发者强化记忆。在整个游戏中，玩家可以被杀死，但敌人永远都不会死。也就是说，如果过关条件被设计为杀死敌人，那么这将真的成为一个永远也无法过关的游戏。典型地，有以下关卡：
1）Start Screen：
这是游戏的开始画面，也是一个热身运动。它要求玩家同时按下“Ctrl + Shift + Enter + Home + F3 + F12 + →”键，这是何等变态的要求。哪怕只体验一次，开发者也会记住，减少按键的个数是多么地重要而美好。
2）Level 3 #Hunt and Peck：
在这一关中，游戏的按键控制会被随机地修改为其他，玩家需要去找到它才能避免死亡，但这几乎是不可能的。这一关是在告诉开发者，需要为玩家提供修改游戏控制方式的功能。
3）Level 9 #Chill Out：
这一关，所有的游戏动作会变得十分十分缓慢，类似的在第8关中相当地快。对应的主题则是，为玩家提供控制游戏速度的功能。
4）Level 13 #Low Budget：
所有游戏中的元素会变得十分十分小，类似的在第14关中十分十分大。对应的主题则是，允许玩家控制文字和图像的大小，或提供适应不同屏幕分辨率的解决方案。
5）Level 19 #Chatterbox：
这一关的画面是黑暗不可见的（模拟高光强的情况），但是游戏提供有关敌人和火力所在位置的音频提示，如“Look out! There is a big spaceship that looks really mean on your left”。这显然是十分唠叨的一句提示，它直到最后一个单词才说出玩家所需要的信息。那么显然，这一关所对应的主题是，提供有意义且有效率的语言提示。

游戏制作完成后，作者通过三种方式测试和统计它对游戏开发人员是否有帮助：1）On-line调查；2）面对面的反馈调查；3）公开的网络上关于“Game Over！”的评价的收集，包括一些网站、blog和论坛。在作者提供的数据中，尽管一部分受调查者表示他们事先或多或少地都了解一些游戏可亲性原则，但大多数人的确通过该游戏认识到了更多。并且有趣的是，在48%对游戏可亲性原则了解少于一半的人群中，有38%的人认为该游戏对他们的帮助非常大，33%认为大，29%认为中等，没有人认为没有或只有少量帮助。但也的确收到了一些十分负面的评价，有人认为特地设计一款游戏来学习可亲性是十分没有必要的，抽象的指标就足够了；还有人认为它不够有趣。

我们可以从以下几个方面来看待“Game Over！”游戏的成功与否：
1）受众：
显然，这不是一款适合大众玩家的游戏，作者的目的在于教育游戏开发者。但是由于其包含的可亲性原则的浅显，它可能更适合于初入游戏开发领域的新手。诚如作者调查问卷第一题“How familiar were you with the accessiblity guidelines presented？”的调查结果所示，一些资深开发者对这些原则是十分熟悉的。那么，对于这些人来说，玩这样一款游戏无异于浪费时间。那么，为什么在资深人员手中依然会出现不可亲的设计呢？私以为那是由于开发资金与时间的限制、以及对玩家的蔑视，唯有现实中的教训才能使其反省。在很多游戏开发公司中，通常会摆放一些游戏设备供员工在午休或下班后时间玩游戏。其间不只该公司的游戏，也包括其他竞争者的产品。员工在玩游戏的过程中，通过自身的感受和与队友的讨论，会不断体验到好设计与不好的设计之间的差距。这虽然是一种十分随机和粗放的体验模式，但往往能收到意想不到的效果，比如发现新的原则。
2）可玩性：
由于这并不是一款单纯的游戏，讨论它的可玩性应与其所相应的Guildlines相比较。诚然，它比Guildlines有趣一点，但它也需要开发者耗费更多的时间。并且，有些关卡的内容和其对应的可亲性原则事实上并没有很好地切合，这同样会让开发者感到迷惑。另外，由于它的设计理念和目的，使得它“一点也不好玩”，也就是说，玩家需要时刻以开发者的身份约束自己，才能觉得它相对有趣些。并且，这种最初出于面对好创意的喜悦之情，会随着时间而退去；也就是说，最后，它会变得和Guildlines一样枯燥（事实上，在玩到一半时，我已经感觉到了）。那么，从这个意义上来讲，它与其说是一款学习可亲性原则的游戏，不如说是一款引人注意的、交互繁琐而精良的可亲性Guildlines。
3）评价系统：
在这个方面，作者做得是不错了。他尝试了多种渠道，试图让尽可能多的人试用和反馈“Game Over！”；并撰写了简单直白的调查问卷，仅5个问题，调查使用者玩游戏前、玩游戏后对可亲性原则的认识，以及他们对游戏本身可玩性的看法、是否适合用作教育工具、是否推荐他人等。值得一提的是，作者还进行了面对面的试用调查，并详细记录了试用者的一些言论，这使得评价更加具体并附有个性，再者直接的交流也比调查问卷能更准确地反映试用者的真实感受。

私以为，此文在交互方式的创意上是具有启迪作用的。尤其作为一种针对成人的职业教育工具，它直接将行业产品作为教育的手段，十分直接而富有震撼力。我们总是希望，教育可以跳出文字与图片构成的教材课本，而以一种更为直接、具象和有趣的方式传达知识。那么，此文的观点就是，游戏专业的学生可以以游戏为课本，医学专业的学术可以以人体为课本。再有，就是以夸张的反面教材的堆积，以低廉的方式使人们获得教训。

[读书笔记] 游戏测试 Part 2：测试技术

Book：Charles P. Schultz, Robert Bryant, Tim Langdell, Game Testing All in One（周学毛等译, 清华大学出版社）, Thomson Learning

---

• 测试技术
  在Intellivision平台上有一款曾经的畅销游戏名为Astrosmash，由于程序员在开发时假设没有玩家能得到达到一千万点，因此他并没有编写处理得分溢出情况的代码。而当游戏发布几周后，就有一些顾客开始打电话抱怨，当他们得分超过9999999点时，得分显示的是负数、字母或非数字符号。而事实上，由于该游戏允许玩家以慢动作玩游戏，使其更易于积累到高分数，因而更易触发该缺陷。由此，该游戏的作者约翰·索尔得到了一个深刻的教训：用户总会让你吃惊。
  理想情况下，玩家可能会希望开发者做完所有可能的测试工作，扫清所有可能触发的Bug；但事实上，由于开发周期、成本等因素，使得这成为一个不可能完成的任务，甚至潜在测试集本身的数量也不允许测试团队做完所有的测试。因此，他们创造了一些十分有用的测试设计技术，来帮助减轻测试的压力，以接近完美的测试。
  
  1）组合测试：
  可选择是游戏的一大魅力所在，如在典型的RPG游戏中，玩家可以选择人物的性别、职业、服装、武器、初始属性值分配和所属战斗阵营等。但是这诸多的可选配置就给测试团队带了一个极为头痛的问题。假设有2种性别（男、女）、2种职业（法师、战士）可供玩家选择，那么需要测试2（2×2）种可能组合；那么，如果额外地提供2种可选的服装（丝绸、皮革），就需要测试8（2×2×2）种可能。完全的组合测试是一个无比庞大的指数级增长，它既不现实也不经济。但其实，只要测试覆盖了足够的功能，就可以将测试集做得小一点。配对组合测试提供了这样一种可能。
  配对组合测试的基本思路是将可选值进行配对，得到测试集必须符合的条件集，那么如果缩小后的测试集满足这些条件，就认为它是正确的。比如上文提到的例子，它的测试集必须符合的条件就如下图（左）所示，而下图（右）则是一个符合要求的测试集表格，但它只有4条测试路径，却涵盖我们所关心的所有可选功能。
                
  事实上，对于任意的可选参数集，都能通过一些简单可循的步骤创建任意大小的配对表格，生成令人满意的较小的测试集。并且，有一些预先构造好的表格模板可供选择，只需要简单地替换参数名称和值就能生成你想要的测试集；还可以选择组合工具Allpair，自动生成测试集。当然，这些并不重要，重要的是配对组合测试的方法可以节省掉大量的时间，将测试员从重复的冗余的测试中解放出来，而将精力投入到其他更值得关注的地方。
  不过，有时完全的组合测试是必要的，比如对于一些对游戏而言十分重要的特征值，但这通常只占总特征的不到10%。测试团队通常会选择混合的方式，即对关键特征作完全测试，对其他普通特征作配对测试。有时，10％关键特征会用掉80%测试路径，而90％普通特征却只能共享剩余的20%，但这是合理的，因为这些关键特征往往是全新的富有创造性的，同是也是最容易出错的。
  
  2）测试流程图（TFD）：
  与组合测试不同，测试流程图是从游戏者的角度来描绘游戏行为的一种方式。如果多个游戏或特性中有相同的行为，测试员可以重复使用TFD；且只要正确的游戏条件和行为没有改变，TFD就保持不变，由此生成的测试路径就始终有效。
  TFD通常使用专门的开发制图工具处理和分析，它大致包括流程、事件、动作、状态、终结符等要素。一张较完整的TFD如下图所示：
         
  TFD需要配合数据词典才能发挥功效。数据词典对TFD集中每个独特命名的初始元素提供了详细的描述，尤其对于do条目定义了需要执行的操作，对check条目定义了测试员所需检查的目标。如定义check条目DropSound为：检查该项目是否已做丢弃声音。
  那么，TFD上的每一条路径就代表一个测试流程，可以通过简单地复制粘贴数字词典上对应的描述，获得一份详细的测试设计文案。对于测试路径有几种经典的可选策略：
  a. 最小路径：这种策略生成覆盖TFD中所有流程的最小路径，即TFD中的每一个地方至少被经过一次。它的测试次数在众多策略中是最少的，但它带来的问题是由于路径较长，有时直到项目的后期，才能发现一些早就在测试路径中存在的问题。
  b. 基线路径集：基线路径是一条从输入终端到输出终端的直接路径，在不重复或往返循环的情况下经过尽可能多的区域，由此往复直到基线路径集覆盖流程中所有的地方。它比最小路径复杂些，但能避免最小路径的延后发现缺陷的问题，不过，由于不同路径的区别操作可能造成最终发现的Bug成因暧昧。
  c. 专家结构路径：这一路径只是一个基于专业人员的经验制定的测试路径，它不必涵盖流程中的所有地方，但一定一次或多次经过专业人员认为最有可能失败或出现问题的地方。它往往是具有偏见的，但却很经济合算。因此，专家路径经常会联合前两者使用。
  测试流程图的方法对于测试游戏的状态转化、操作流程和其他可重复的功能尤其有效。
  
  3）净室测试：
  净室测试是从一种被称为“净室软件工程”的软件开发时间中提取出来的技术，其最初目的是在项目中运行软件，以进行平均无故障时间（MTTF）的测量。在游戏测试中，净室测试被用来解决游戏玩家在运行了许多时间后发现官方未公布的缺陷这一问题。它的目的在于发现、根除很有可能会被用户发现的缺陷。这些缺陷通常存在于玩家经常会使用到的游戏功能中，这也就要求测试团队按照一种玩家的方式去运行游戏的测试。
  首先要获得各个游戏功能的使用率。这可能基于测试员研究游戏玩家而得到的实际数据，也可能来自于个人关于这款游戏如何运行的期望，以及游戏生命周期中可能存在的玩法的变化。但，通常有三种定义和获取的方式：
  a. 基于模式：这指游戏的不同模式，如对战、RPG、多人等。不同模式的游戏针对的用户群不同，因此习惯、关注点、所需提供的功能都不尽相同，比如多人游戏的玩家可能会比单机玩家更多地在意玩家间的交互方式。
  b. 基于玩家类别：Richard A. Bartle将多用户玩家分为四类，进取者、冒险者、社交者和杀手。他们所热衷于的游戏功能就很不同，冒险者很关心游戏的艺术特效和美景，而杀手才不在乎，他只要体验杀戮的快感就万事大吉了。当然，还有其他的分类，比如键盘杀手和自定义者，游戏世界和真实世界是一样的，各种鸟都有。
  c. 基于现实：这种方式比较直接和直观，它通过记录玩家的偏好并统计，以用于进一步的测试和改进。
  得到使用率后，就可以利用其去选择测试步骤、数值、细节，且把它们按顺序排好形成能反映出玩家用法的测试情况。比如在使用组合测试时，使用率高的选项就应当在测试集中占有较大的比重；而在使用流程图测试时，使用率高的地方就应当被更频繁地经过。
  
  4）测试树：
  测试树提供了一种可以很好地反映存在于游戏功能和原理之间的树形关系。通过沿各种不同的从树的定点到树的每一个终点的路径测试，可以检测这些结构的行为方式。在游戏测试中，使用测试树有三种不同的目的。
  a. 测试用例树：它记录了测试用例和游戏特点、原理和功能之间的层次关系。这种测试已经成熟并且文档化了。每一次开发小组给测试者发送一个新版本，测试树就会被使用。测试者根据缺陷补丁或者版本中引进的新功能，决定其影响的范围以及要执行的测试。并且，测试用例树也很好地表型了游戏本身的构造方式。如下图所示，针对一款战役游戏给出了一个粗略的测试用例树。那么，当有关小型战斗游戏模式的代码被改动后，测试者就可以通过查看测试用例树明确地知道，他需要进一步地测试地图、玩家数量、种族、游戏选项和胜利条件等。当然，有时，这种检测可以是向上的，比如一张新地图的加入，就需要执行所有战役模式的测试。
         
  b. 特征树：这种树用于反映游戏中的一些逻辑特征，或者说是游戏规则，典型地如RPG中常见的技能树、任务树和升级树等。特征树可以被很方便地翻译成测试文案，测试方法通常是通过替换每一个特征条件直到满足结论成立，这样，就能找到有缺陷的条件。如下图（左），给出了一个十分简单的技能升级的特征树，只有当人物的白魔法能力达到2级，同时黑魔法能力达到3级，才能修习蓝魔法。那么这一规则的测试就如下图（右）所示。
             
  c. 设计测试树：这种树可以提高对一个复杂的游戏特征的理解，并且给潜在的混乱职能带来秩序，尤其是在关于与其他游戏规则，原理和职能交互作用的部分。测试员通过它生成测试用例，用以查明狭小范围内的游戏行为方式中潜在的缺陷。比如在RPG中，一种魔法会因为不同的人物、地点、武器和对象，而产生不同的伤害效果。那么，测试者就可以根据这些画出一个针对该魔法的树，修建无效的支路，最后依次执行所有的生成校验该魔法适当行为方式的测试。
  
  5）随机测试：
  随机测试（Ad Hoc Testing），有时又称综合测试（General Testing），是以一种较为主观的方法来搜索错误。这种方法认为，就算拥有最全面、详尽的测试计划和设计，依然可能会有疏漏；而随机测试，允许测试员作为一个个体，在对游戏执行系列客观测试的过程中，探测那些可能已出现过的调查路径。通俗地说，当测试员想着“如果我做#%&$，会怎么样？”时，随机测试提过了一个回答诸如此类问题的机会。
  随机测试有两种主要形式，自由随机测试（Free Testing）和定向随机测试（Directed Testing）。
  a. 自由随机测试：又称右脑测试，因为其是否直观和主观，是一种有专业游戏测试人员“即时”设计的“可与原始数据分离”的测试。这种测试往往需要锐利的眼光，一种游戏测试员的直觉；要求测试者在混乱中创造秩序，有目标有记录；并且始终保持孤身作战，这是自由测试的一个重要原则，避免集体审议，使得测试员保留个人作为玩家的特征，更容易发现一些违反直觉的游戏缺陷。
  b. 定向随机测试：这种测试方法使得测试者像一个侦探般工作，它通常用于解决某一特定问题或者查找特定解决方案，通常是因为一个或多个测试员报告了游戏中一个“偶然的”死机情况但原因不明后开始的，比如回答“场景切换的时候有时会崩溃”。测试员会先就结果作出假设，再一个个地验证它们。这个过程十分依赖测试员的经验和敏锐的嗅觉。共享信息是必要的，因为这方便地切断一些别人尝试过的假设，帮助更快的解决问题。
  
  6）性能测试：
  游戏性能测试与上文提到的所有测试技术所关注的焦点均不同。它关注的是“游戏运行得好不好”，而不是“游戏是否能运行”。差别是明显的，并且前者似乎更加重要，而且往往是带有主观特性的。性能测试的大部分是指对游戏平衡性的测试，也就是“游戏会不会太难或者太简单”以及“游戏中的各个可选功能是否均有可选之处”等。测试员所需要做的，是尽量准确地描述游戏的不平衡点，而不是给出过于精确的改善意见。
  还有一些性能测试可以通过外部测试进行，也就是给除了开发团队和测试团队之外的人玩，比如公司的营销部。这也就是我们经常看到的外部Beta测试，它包括封闭的和开放的。封闭测试的测试员经过仔细筛选，而开放测试通常在封闭测试之后进行，面向其他一些感兴趣的人群。外部Beta测试依赖于有效的管理，否则，会带来大量无用的数据。

好游戏取决于有创意的设计、严谨的测试和有力的营销。设计带来亮点，测试巩固亮点，营销贩卖亮点。虽然Bug是挖不尽的，但我们仍希望它是接近完美的。因此，如若没有deadline，测试团队的工作将是无穷无尽的。也因此，使得Time-critical的测试成为一项极为繁重的工作。这迫使业界总在探索更有效的测试技术，如何节约成本，如何避免遗漏，等等。缺陷触发、自动化测试、捕获/回放测试等技术相继诞生。那么，这样一个没有Bug的未来是否值得展望呢？答案犹未可知。

[读书笔记] 游戏测试 Part 1：基本概念

Book：Charles P. Schultz, Robert Bryant, Tim Langdell, Game Testing All in One（周学毛等译, 清华大学出版社）, Thomson Learning

---

为着这学期软件工程课8000+字的Term Paper看的这书。前日去图书馆原是想借些正经软工书的，翻了满架子的书竟是本本写得都像畅销书，还真如众人所说的，真水。想看些架构设计的书，竟也没找着。稍有些质感读起来也不太枯燥的，就只有一些游戏方面的书，有图，还有些我知晓的例子。那便看吧。

测试为什么重要呢？因为游戏会出错，出各种各样的错，并且即使经过了漫长的尽可能全面的测试，游戏依旧会出错。但这恰恰说明在发布前的测试是十分必要的，不管是对于游戏出版商，还是对于开发团队而言。一款出色的游戏会得到褒奖，而一款充满Bug频频跳闸的游戏则会给开发团队带来漫天的骂声，销售额和利润也随之蒸发。

测试为什么对于游戏尤其重要呢？其实测试对于任意一款应用软件都是相当重要的，但是没有一款应用软件像游戏这样拥有庞大、多样、富有压力的客户群。不要指望玩家规规矩矩地按照手册上写的点击菜单，你永远都无法完全预测到每一个玩家所有可能的变态操作——他们可能在物品交易的过程中突发奇想地丢掉正在交易的物品，而导致玩家数据错误。因此，游戏测试是任重而道远的。
 

• 游戏测试员的任务
  作为一名出色的游戏测试员，需要从一名游戏玩家开始，但绝不仅止于此。游戏测试员需要诀窍来发现问题、记录并报告Bug、报告测试进展和帮助开发者发现并确定Bug具体位置。在游戏发布之前，测试员需要反复地做以下这些事情：
   
  
  1）Play：游戏测试员的“玩”较普通玩家是少有选择性的，测试方案从一开始就规定了测试的目的和步骤，如查探某一游戏中的地图、检查某个特定的原则是否得到执行、或者寻找某一类特殊的问题。有些测试甚至是十分具体的，比如对游戏界面的测试，就依赖于敏锐的观察和对细节的注意，并且往往需要循环重复一些枯燥的按钮和下拉动作，以确定是否存在某些不合理或错误的操作响应。
  
  2）Identify：游戏测试有两个目的，一为找到游戏代码或设计中的缺陷，二为说明游戏中的各个部分能否正常运行。当在测试过程中发现了问题，游戏就相对地“失败”了，这时需要测试员详细地描述发生该问题的过程和结果。
  当测试游戏的同一部分时，不是每个测试员都能发现同样的缺陷。心理学上认为这是由人的不同性格造成的，并给出了有效的性格测试工。这个工具可以识别一个人是裁判还是感知者。裁判善于组织和作计划，喜欢井然有序和可预测的测试环境，专注于测试内容的细节，提供详尽的测试报告，适合测试用户手册、脚本；感知者则喜欢采用非常规的游戏玩法，测试多种可能和游戏的真实体验，往往不受计划约束，却能发现一些意想不到的珍贵Bug。这两种人是互补的，因此在一个测试团队中往往需要这两种人。
  
  3）Amplify：这里的“放大”指的是尽可能地使缺陷在第一次被发现时就完全暴露出来，以减少用在这个问题上的时间和成本，这对开发者通常是有益的。为了达到这个目的，通常需要做到两点。首先，尽可能早地执行测试，如当一些新的人物、关卡、功能或子系统第一次被引入时就应当马上进行测试；第二，当在测试过程中发现某个Bug时，应当检查每一个可能触发该Bug的地方，如代码中所有调用包含缺陷的关卡、功能或子系统的地方。
  
  4）Notify：当测试人员发现问题且能描述它影响游戏的方式时，就需要记录此信息并就此向开发人员通报。这一过程通常通过缺陷追踪和管理软件实现，如业界常用的DevTrack。一份完整的通报包括以下几个重要部分：
  
  a. 标题：一个描述性强的标题通常很有用，它帮助开发人员快速地定位此缺陷的大致内容。好的标题通常需要包括一些重要的要素，如事件、人物、方式等。这就和撰写报纸的标题一样，像“杭州地震了”这样的标题是不适用的，它让人产生迷惑。而“5月22日杭州发生里氏8级大地震”这样的标题则合格得多，它恰当地表达了这则新闻的重要性和爆炸性。有时还需要更多的细节，如“造成90人死亡”和“城中30余处房屋倒塌”等。
  
  b. 描述字段：这里包括测试员能及的所有有帮助的细节，人物（战士）、事件（嵌入到内墙的上部）、地点（训练厅）、时间（拜访符咒训练者后）和方式（跳跃）。有时，如果可以，还会描述问题可能的解决方法等。
  
  c. 缺陷的优先级：优先级的名称和含义对项目而言可能各不相同，但概念是相同的，都是根据其重要性对缺陷进行划分，从而决定它是否被优先处理。“紧急”的Bug可能导致玩家信息的丢失、终止或异常中断游戏等重大缺陷；一个“高”优先级的Bug通常是导致某些严重后果的缺陷，如提交了请求但不能得到请求的东西；“中等”缺陷导致明显的问题，但不会危及玩家的奖励或关卡；“低”优先级的Bug则是正对非常微小的缺陷而言，如一些不容易发觉的拼写错误。但应当注意的是，Bug的严重性等级和优先级是有所区别的，比如主菜单中的拼写错误并不会导致什么严重的后果，但却是一个急需改正的Bug。因此，大多数游戏公司会在对Bug订正排序时联合使用严重性和优先级。
  
  d. 缺陷的类型：包括需求修改、文档问题、矛盾报告、进一步增强、微小改进、新特征、第三方错误等，对确定缺陷的路径和处理缺陷而言有重要的意义。通常缺陷管理软件会提供一些可选的分类。
  
  e. 备注：这确保测试员通过添加文件的形式，提供所有有帮助的内容或信息，包括日志文件、包括Bug的录像、操作系统的弹出窗口和错误代码等。
  
  5）Testify：游戏测试员的工作只是发现并通报缺陷，而真正区分缺陷的优先级的权利则掌握在变更控制委员会（CCB）手中。CCB监督和促使最要紧的缺陷得以完成修复，从而在项目期限到时能交付一个最符合要求的游戏。其成员一般包括来自发展部门、测试部门和项目管理部门的代表，他们对Bug进行仔细检查，对其优先级打分，再交付修改。值得一提的是，这里涉及到游戏测试中另一个重要的原则——有选择的（Optional），有时因为项目期限的临近，使得许多团队放弃修复一些有难度的缺陷。
  
  6）Verify：这一步指的是在Bug被修复好之后，有测试人员再次对性测试一次，以确定其是否被完全和有效地改正。
   
   
• 游戏缺陷的类型
  由IBM公司开发的正交分类（ODC）系统定义了多种软件缺陷的分类方法，其中与游戏较相关的大致有八类。每一种缺陷类型或者是执行结果不正确，或者是缺少代码。
  
  1）功能（Function）：功能错误是一种影响游戏性能及用户体验的错误，可能由提供这一功能的代码丢失或不正确造成，如，在触发某一人物技能后，显示技能停留剩余时间的时间条的缺失。
  
  2）赋值（Assignment）：赋值错误指程序所使用的值被错误地初始化或设置，多数发生在游戏开始、进入一个新关卡或一种游戏模式时，典型地如在策略游戏中，对开始的位置单元和可用资源的初始化。错误的赋值将导致对游戏平衡性的破坏。且有时这种错误是隐藏的，难以有程序员发现的，只有通过测试才能找到。
  
  3）检查（Checking）：当代码在被使用前缺少适当地验证数据时，就可能产生检查类型的缺陷，简单地如边界比较，使用<=代替<。
  
  4）时间控制（Timing）：时间控制缺陷与资源的共享、资源的实时管理相关。良好的时间控制应当在加载某些大型资源时，给出进度条，显示正在进行的操作。通常RPG游戏中在人物启动某项特殊技能的时候会给出一个短小的动画，但往往技能切换完成得会比动画快得多，这时错误或缺失的代码讲导致在动画完成前，技能就被启动，这是违反游戏的世界观原始设定（比如关于念魔咒隐身），这是一个典型的时间控制缺陷。
  
  5）构造/包装/合并（Build/Package/Merge）：这类缺陷是由于配置游戏源代码库系统，变更游戏文件管理，或版本识别和控制引起的错误。良好的版本管理和习惯约定能减少或避免出现这类缺陷。
  
  6）算法（Algorithm）：算法缺陷包括一些计算过程或者选择结构中出现的有关时间复杂度或正确性的问题，主要涉及逻辑控制、AI、数值计算、渲染控制等方面。这类缺陷都大部分涉及到游戏功能，其中一些还是隐藏功能，因此大多会考虑写一个专门针对某一算法缺陷的查找脚本，做连续地测试，而不是一个一个地手动测试。
  
  7）文档（Documentation）：文档缺陷不是由不适宜的代码导致的，而是存在于从文件中重新得到的字节型数据或定义的常量，比如在屏幕上显示的文字、音频或供函数调用的读入参数。这些缺陷只能通过仔细地阅读文本、听音频、检查文件和图形，才能被检测到。
  
  8）接口（Interface）：接口缺陷可能在任何一个信息被转移或交换的地方发生。但通常，它的存在是由于模块之间的调用方式有误，比如被传入的参数与调用例程不匹配，或者在传入时使用前没有做合适的数值范围或类型检测等，都可能导致接口缺陷的产生，而且这些缺陷往往是细小且不容易发现的。
   
   
• 测试阶段与过程
  虽然游戏的大小不等，开发周期也各不相同，小到只需数周就可完成的手机游戏，大到一些大型的MMORPG或平台游戏，有时需要几年的开发时间，甚至屡屡跳票（如暗黑3）。但不管游戏有多大、生产周期有多长，其测试始终遵循相同的基本结构。
  
  1）试生产阶段：对测试可能的认知是认为测试是在游戏的一个成功部分被开发之后的某一个时间开始的，但事实上，测试始于项目开始之时。许多发生在项目的早阶段的事情，将会为以后测试的好坏定下基调。最好能在项目一开始，就将较多的努力和技术应用于测试活动来修正错误，而不是后来对其做更多的测试，来努力修正它们。
  在这一阶段，需要制定合理的测试计划，包括：决定测试的范围、任命测试主管、决定阶段验收标准、参与游戏设计检查、建立缺陷追踪数据库（关键）、起草测试计划草稿和测试设计。除此之外，还要对游戏原型作模块测试，并且根据测试要求招募或雇佣额外的团队成员。这一阶段的测试结果往往是不成熟的，但却对未来的测试工作有着深远的影响。
  
  2）测试的开题阶段：这一阶段分为两个部分，测试员准备和开题会议。测试员准备的步骤和开题的议程都记录在测试开题的清单上，可以看到，测试员需要在开题前通过阅读说明书或文档了解被测试的游戏特征，需要测试所需的设备、文件和程序，最后需要阅读由测试专家书写的测试文案。
  开题会议是一个交互式的会议，每个测试的开题都是改善对测试的理解、测试质量和测试执行的机会。通过会议当中的讨论，能提前发现一些在未来的测试过程中可能遇到的问题，并找到补救措施。有统计表明，开题会议实际上节约了测试时间，开题测试的速率是非开题测试速率的1.4倍。
  
  3）α测试阶段：在α阶段的游戏是成型的，游戏的特征已经被测试和校订了，各种素材也被整合过了。这是整个游戏第一次完备的测试，因此，这一阶段的测试是最繁忙的，也因此严格坚持测试套件中的内容是十分关键的，它能让整个测试过程井然有序。在α阶段，游戏的所有模块至少应该被测试一次。业界有公认的详细的α阶段测试入口标准，涉及代码的平台TRC通过率、QA要求、软硬件相容指标和美术要求等，只有符合该标准才能进入α测试阶段；类似的，也有β测试入口标准和最终测试入口标准等，这对整个游戏的测试阶段起到良好的规划作用。
  
  4）β测试阶段：此时，开发团队已经在极大程度上停止创造新代码和新素材，而将关注点转移到如何使游戏更完美，也就是到了识别和修正Bug的时候了。在β测试的早期阶段，会有团队以外的玩家参与测试，但大部分的时间会被花在报告Bug并测试装载上。
  这里有一个值得一提的时间点，称为“设计锁定”。当设计锁定状态被宣布后，游戏大方面的测试都已经结束，平衡问题也得到了最好的解决，团队的关注点变为反复地通过实际测试案例来检验版本。在这一状态到来前，项目组需要作出一些重大的决定，如是否要执行最后时刻的特征强化（引入设计师的新构想）、是否砍掉似乎不那么有趣的关卡、哪些Bug将被忽略（难以决定，但时间是有限的）。
  
  5）最终测试阶段：进入这一阶段的游戏出于典型的发布状态，所有的已知一级Bug（崩溃、暂停、主要功能失灵）和大多数的二级、三级Bug被修复。游戏被宣布处于“代码锁定”状态，测试员充当游戏者和项目组的最后防护线。测试团队将最后一次，在时间允许的条件下，尽可能多次执行所有测试套件。任何在最后阶段中发现的严重缺陷都将导致候选版本被拒绝，Bug修正后最终测试必须从头再做一次。此时，整个团队都处于极度的疲倦中，但唯有大踏步地前进才是最好的取得胜利的方法。
  
  6）发布证明阶段：这一阶段的测试通常是由平台制作商（任天堂、索尼）来完成的。其测试游戏的代码是否符合TRC，其功能性和稳定性是否合乎标准。通常，此时还会有一些Bug被发现，然后开发商将会与平台经理的客户就Bug进行讨论，开发团队将被要求修复那些“必须被修复”的Bug。这一过程有时会反复多次，直至候选版本被平台制造商认可，成为“正式版”。
  
  7）公布后测试阶段：游戏发布后，测试依旧不会停止。这也就是我们通常看到的开发商不断公布补丁的时刻，但并不是所有的补丁都用于修复Bug，有时它们是用来为游戏添加新特征的。这一过程会一直持续到游戏的生命周期结束。
   

清明将至，雨断断续续地纷纷

近脱产地准备iBT已半月有余，每天做2小时的反复听力现在总算跟得上iBT的语速了。顺便背着单词，拿词汇书啃实在痛苦了些，就把一些阅读里听力里的词和句子记在Excel里然后每天看看，至于为啥要写在Excel里呢，因为这样排布起来比较好看~ 700字的阅读最近看起来也不太吃力了，虽然长句读起来还是有些卡时间有时也会超，我发现我比较喜欢看地理和心理类的文章。

作文就只做了些翻译和句型的练习，看到题目还是没有清晰的头绪，接下去得看些范文再模仿着写下。口语基本没准备，前几日试着录了下，发现自己说中文都很含糊> <，难道你们一直听到我口齿不清啊，我要去画圈圈。。

四个部分里准备地最开心的是听力，因为lecture的内容还是比较有实质的，偶尔还可以收获些谈资，更重要的是可以以此为名看美剧和电影。最辛苦的应该是口语吧，所以迟迟都没有开始，说出第一句话还是很困难的，小时候花了几年，现在长大了心智成熟了但怎么着也要酝酿个几个星期吧。

看多了英语，最近觉得听到中文讲话，偶尔听听日语歌还有一丝不挂都是十分美妙的事情，有种回家的感觉。

这段时间杭州的天气着实奇怪，周一阴周二三雨周四五阴周末晴，循环往复。于是每天起床头一件事就是头疼今天穿什么才不至于热死或冷死。panda抱怨是三峡害的，他小时候杭州的天气绝对是四季分明。自辩老师也抱怨三峡导致了西南干旱。我觉得他们都在理，三峡断了我再游长江的美梦，所以，赶快炸了去吧。

刚又去教五调程序了，原本一直跑得挺好动作识别得也挺好，末了老耿至了，soso竟鬼使神差地首次砸到天花板上的日光灯，接着识别结果就开始紊乱了。小魏说这叫蝴蝶效应。我汗，怎么总这样，真是佛曰不可说啊。