开发者应不惧测试压力以提升游戏质量-游戏美术教程网-游戏程序开发-Dogame游戏兵工厂
　您现在的位置： &
　　　　　开发者应不惧测试压力以提升游戏质量
开发者应不惧测试压力以提升游戏质量
发布时间：　查看：747 次　　　
&&&&&&& 优秀的游戏是通过试玩创造出来的。这不是我的一面之词，而是著名游戏设计师Jesse Schell在他的绝妙书籍《The Art of Game Design》中提出来的。他甚至还进一步说明，试玩不仅对游戏有益，而且是制作优秀游戏的必要做法。
&&&&&&& 令我感到惊讶的是，有些游戏开发者只进行少量的游戏测试，甚至完全没有。他们的这种做法可以理解，毕竟，他们都是有着数年游戏设计和开发经验的电子游戏专业人士。普通用户能够在他们的游戏中发现哪些他们自己所不知道的东西呢？事实证明，这种东西的数量很多。
&&&&&& 进行试玩的关键原因在于理解玩家的真实行为和游戏玩法体验（注：不是为了探求他们的意见）。对于游戏的运行方式，每个玩家都有着自己的理解，这便是他们的心智模型，而且玩家的心智模型间可能存在很大的差别。即便玩家间有着相同的人口特征，他们对游戏的理解和体验也会有显著的差别。所以，即便设计师创造的游戏的目标受众是与其类似的玩家，也仍然会有误解情况的产生。理解他人的想法非常困难，从实践上来说，这可能根本无法实现，因为你的设计所针对的潜在玩家是多种多样的。
&&&&&& 那么，既然知道试玩能够产生优秀游戏的道理，为何有些工作室不这么做呢？最普遍的原因便是时间和金钱。工作室通常会在游戏创作达到某个阶段时勉强进行测试。这种做法的危险在于，试玩进行的时间可能会太迟。而且，测试的费用由谁来出也存在分歧，是工作室还是发行商？
&&&&&& 还有许多关于这种做法的传言，比如有人说游戏测试会摧毁设计的创意。在我们已经做过的所有试玩中，从未发生过这种事情。事实上，我们看到的情况正好相反。通过对玩家的行为进行分析，我们看到的是设计决定不断重复并完善。在这些情况中，很可能新颖游戏机制的潜在概念并不存在问题，只是当前的执行方式与玩家的期待或者理解并不相符。
&&&&&& 尽管Schell声称他是游戏试玩的狂热支持者，但是他也承认对这个过程很讨厌。他甚至尝试在试玩被规划在内时寻找理由来剔除。但是，他的理由与那些不做测试的工作室的理由并不相同，他只是害怕人们不喜欢他的游戏。
&&&&&& Schell表示，当设计师和开发者在查看游戏的测试过程时，他们通常会有如下两种反应。有些富有创意的人觉得用户的评论和反映特别刺耳，他们会迅速地拟定设计方案解决遇到的问题。但是对于另一类人，测试是种使人清醒的经历。这才是完全正常和理性的反应，设计和开发游戏是个巨大的承诺，不仅需要投入时间，还需要投入情感。短暂体验游戏的玩家因为感到困惑或者游戏的难度而抛弃游戏，这确实很难令人接受。
&&&&&& 1969年，精神病专家Elisabeth Kübler-Ross提出了人们对付悲痛的5阶段模型。这可以为游戏设计师在游戏测试阶段所用：
否决：“没关系，这个用户很傻，其他人都可以领会。”
愤怒：“为什么他们要这么做？他们难道不理解基本的游戏概念吗？”
商讨：“如果下个用户能够领会的话，我承认自己会为游戏在Metacritic上获得60分感到高兴。”
沮丧：“我放弃，或许我并非如自己想象那样是个优秀的设计师。”
接受：“我知道他们为何会产生这种想法，我也有个可以改善设计的想法。”
事实上，每次设计师都会在测试中经历这5个阶段的过程，他们的游戏也会得到改善。
&&&&&& 而且，你最终都会经历整个系列的情感变化。游戏发布之后，玩家迟早都会接触并对游戏发表观点。关键的是，作为游戏创造者，你可以控制的是这些情感会对你的游戏产生积极还是消极的影响，即是否会重视测试中获得的意见并改善游戏。
&&&&& 我近期询问了一位资深游戏设计师，问他是否认为测试是他作为游戏设计师的软肋。他立即就做出了回答：任何优秀的设计师都应该积极寻求玩家的反馈，让自己的游戏得到改善。
相关文章：
本月教程排行
DOGAME游戏兵工厂HNYU GAME粤ICP备号关注51Testing
资深游戏测试总监详解质量管理工作的9个步骤
发表于： 11:19 &作者：张敬峰 & 来源：51Testing软件测试网采编
推荐标签：
　　就是整天玩游戏的吧？　　游戏测试还要招本科毕业的！！！不是逗我的吧？　　游戏测试不就是拿鼠标或手指头随便点点么？　　……　　本文我们尝试对上述问题作出一点点专业解释，思路脱胎于2015年笔者在公司内部做的一次项目相关的分享。又将近1年时间过去了，在中，又有很多新的感触与心得。拿出来，跟各位读者分享下，抛块砖，引些玉。　　无论是业内人员还是业外人员，在很多人眼里，游戏的质量保证基本上可以和划等号。这种思维是略有偏见的，我们先抛开测试的手段（黑盒，灰盒，白盒）不谈，其实在一款游戏的质量保证过程中，所需要做的工作非常多且杂。这里我大概总结了下常见的工作内容（可能不是太全），见下图：　　　　看完这张图，诸位看官是否已经打消了游戏测试就是拿工资玩游戏的看法，呵呵。　　一款游戏的质量保证工作基本围绕上图中的具体工作展开，为了保证测试任务的效率与质量，让项目组里的测试人员把上面所有工作全部承担，是不现实且耗费过多成本的。一个比较好的解决方案是：游戏项目组中的测试人员专注于功能及关联紧密的接口、日志等测试工作，与项目关联度相对弱化和可分离的内容放到平台测试组去完成。大致模型如下图：　　　这样的配置有两个优点：一是优化测试团队内部的资源分配，二是提升了项目自身的测试效率。专业的人做专业的事是整体的指导思路。　　上面比较笼统的描述了下一款游戏项目质量保证的大致内容，以及如何优化配置测试团度资源。那么具体到实际的工作中，我们又该怎样去做好质量保证的管理呢？　　这里笔者把质量管理工作拆解成了9个过程，我们逐一来谈一下每个部分的内容与重点。当然，无图无真相，诸位客官，图来了～　　　　我们结合上图所，详细谈谈做好每个过程的正确姿势。　　一、过程　　需求管理过程在整个质量保证过程中非常重要，但也是经常被很多读者忽略掉的一个过程。很多测试人员习惯拿过任务来就开始测试，甚至连需求文档都不看，从而出现了漏测或误测的现象。　　对于需求管理过程，在正式开始测试之前，至少有3点是需要格外关注的。　　01）评估需求的合理性。任何人的思维或设计都不可能尽善尽美，所以对策划人员提供的需求文档，我们也要抱有怀疑态度，在阅读需求的过程中，我们需要思考设计是否存在不合理的地方，是否有可以优化的地方。最忌照本宣科，不思考的认为需求是百分百正确的。　　02）思考测试难度与测试周期。在阅读和梳理需求文档时，尽量考虑每个功能点的测试难度与测试需要的时间。如果遇到有不能测试或很难测试的地方，尽早的提出来，与开发人员一起沟通测试方案或者提出测试工具的开发需求。评估测试时间则是为了更加准确的预估测试周期内是否能完成任务，如有困难，尽早的提出，以方便整个项目做出进度上的调整或者协调其他资源来帮忙完成。　　03）考虑关联度。游戏功能之间的关联度比较高，在需求阶段，需要考虑当前功能与其他功能是否有关联，思考新功能的添加是否对旧有功能产生影响。如果存在关联上的影响，需要在实际测试过程中测试这些关联功能。　　二、计划管理过程　　在测试计划管理中，核心的关注点是时间，每个环节的时间预估的越准确，则项目进度可控性越高。反之，则会导致各种不可预估的延期情况，具体流程见下图：　　　在计划管理过程中，核心是时间，重点是计划一定要明确到个人，且需要跟进。任何计划都可能出现延期现象，不要放过，仔细分析延期原因，从而不断改进。　　三、任务分配管理过程　　任务分配管理过程相对简单，需要考虑的点不多，我们还是以一张图来阐述，能上图就不BB，见下图：　　　　四、执行管理过程　　很多结果导向的看官可能会忽视执行管理过程，结果固然重要，但要想获得一个理想的结果，请不要忽视执行的过程。在执行过程中，尽量关注和监督，了解执行的动态信息，如发现可能导致结果打不到预期的苗头出现，需要及时作出动态调整，如增加人手、调整任务或修改预期目标等。　　好的管理未雨绸缪，烂的管理事后诸葛亮。不要当执行结果与预期有差距是去抱怨和牢骚，不如多花精力关注执行过程，动态调整和改进也许效果更好一些。　　五、反馈管理过程　　信息孤岛的出现会给项目带来潜在的风险，我们要尽量避免这种情况。及时主动的沟通反馈有助于团队之间信息通畅，不仅知道自己要做什么，也需要知道别人在做什么，也让别人知道你在做什么。具体内容见下图：　　　　六、管理过程　　Bug管理最常见，也最容易被大家忽视。在这个过程中，我们需要关注八个方面，见下图：　　　对很多测试人员来说，测试工作就是发现bug，然后，就没有然后了。其实仅仅发现缺陷所在是远远不够的，笔者始终强调，发现bug仅仅是测试工作的开始。为什么我们不厌其烦的强调bug管理过程的八个部分，难道搞得这么复杂不会影响效率吗？可以明确的回答，不会，反而会提升项目整体效率。我们简单举两个例子来说明一下。　　例子一：bug提报标准。很多人提bug就是一句话，这种习惯是非常糟糕的。看似很节省时间，实际上浪费的是其他人的时间。开发人员通过一句话可能根本不明白bug是什么意思或者很难找到复现方式，从而还得跟提报人反复确认，这样是对时间的极大浪费。所以一个好的bug应该有清晰的描述，有清晰的复现步骤，有清晰的期望结果，有相关的截图和日志。通过耗费测试人员的一点时间换来项目整体的效率提升。　　例子二：bug的数据分析。数据分析也是经常被忽视的一个方面，通过对bug的数据统计分析，我们可以很清晰的了解到哪个模块容易出问题，哪个开发人员容易出bug，当前版本还有哪些紧急的问题需要修复等等。数据不会说谎也最具有说服力。测试驱动开发喊了很久，怎么去驱动？也许可以从这些点滴的小事开始做起。　　七、版本管理过程　　版本管理过程在游戏运营阶段尤为重要，尤其是产品量级比较大的时候，做好了，万事皆顺，做不好，后患无穷。通过长期的实践总结，个人认为有3个要点需要关注。　　01）版本内容。该进版本的内容必须进全，不该进版本的内容必须不进。这句看似废话的描述，实则是各种血泪史的控诉。版本中无论是少内容还是多内容，都会导致bug的出现。发版本前，多花一些时间，检查和控制好版本内容，则完全可以避免这一类问题的出现，做到防患于未然远比出了问题再修改要好的多。　　另一点则是，任何内容的提交都需要经过测试，这条也是蹚了无数的雷才形成的流程。任何自认为代码没问题就提交而未经过测试的，往往是频繁出bug的地方。　　02）版本时间。为什么版本时间这么重要？晚一天发布不行吗？真实的答案是不行。任何跨天的延期发布都可能导致游戏内众多的活动内容调整，官网内容调整，更不用说昂贵的广告费用打了水漂。所以版本时间一定要控制好，尽量提前预估好时间，留出充足的时间来准备发布。　　03）其他。除了上述2点需要注意的，版本管理还需要注意兼容、版本纪录和版本发布后的线上监控等琐碎问题。　　八、文档管理过程　　文档管理重要程度看似鸡肋，而往往则是这个鸡肋能关键时刻救你一命。一个项目周期越长，如果没有详细的文档纪录，还有项目人员的变动，可能到项目后期都没有一个人能清楚某些规则。对于测试也是一样，需要做哪些文档管理呢？见下图：　　　　还是那句话，传承做不好的项目不是好项目。　　九、部门协调管理过程　　在现在项目过程中，协调部门间的资源越发重要，这基于两点现实：一，任何个体都无法保证项目质量。二，资源具有稀缺性，需要协调一切可利用的资源为己所用。怎么做？一句话，沟通，不断沟通，玩命沟通。　　踩过了无数的坑，才能明白做好项目的质量保证工作并非易事。趟了无数的雷，才能将一条条血泪总结成经验流程。　　啰嗦了这么多，希望各位读者喜欢，希望能对读者们的工作有所助益～
搜索风云榜
( 16:21:34)
能否加上案例
51Testing官方微信
51Testing官方微博
测试知识全知道注册 | 登录
爱因斯坦没有解决的问题，交给泡面（PM）解决
零基础学产品，BAT产品总监带，2天线下集训+1年在线课程，全面掌握优秀产品经理必备技能。
最近，我们的产品上线了，上线之后，稳定是最重要的，但是，出现了几次bug，都是不应该犯的错误，所以，避免bug特别是重大bug出现，提高产品质量，非常迫切。为此，我花了几天时间，翻一些资料来系统地学习，此文是学习的总结。
产品开发过程
产品开发过程：需求分析、设计、编码、单元测试、集成测试、功能测试、Beta测试和发布。在工程师开发之前，策划或产品提过来的需求、策划的配置文件或者后期的测试，都可能影响产品质量，但是，本文侧重于从开发者角度谈提高产品质量。先分享一张来自《Code Complete》的插图。
可以看到，随着项目规模变大，架构、设计和集成测试、系统测试需要的时间会更多，而编码和开发者测试的时间更少。因此，提高效率最为明显的方法是提高产品质量， 减少测试、调试和修改所需时间。所以，设计、测试和编码同样重要，要分配更多时间，编码完 != 工作完成。
测试的重要
在很多大一些的IT公司，比如微软，开发职位叫Software Development Engineer，SDE，软件开发工程师;测试职位叫Software Development Engineer in Test，SDET，软件测试开发工程师，可见测试人员本质还是开发工程师。这有别于我们在公司里常常见到的QA，我是做游戏的，我见到的QA都是打开游 戏，然后点点点，从表现上测试功能是否正常，这样测试是无法全面测试的，这也难怪在很多公司里QA比开发团队地位低。我觉得，对于测试这个职位，要做好， 是很难的。他要能读懂策划文档和开发文档，从源头上开始着手。如果白盒测试，要能看懂别人写的代码;如果黑盒测试，要和开发人员多沟通，画出来实现的流程 图，并且分析网络协议;然后，设计完备的测试用例。如果不根据需求、设计和实现，设计完备的测试流程，而只是操作一下试试功能是否正常，很多隐藏的bug 是测试不出来的。
在传统软件行业：软件的质量和稳定最重要，代表企业：IBM、微软、思科等。根据我查到的资料，开发与测试人员比例，微软1:1，思科1:1.5，普 遍在1:1 &#。SDET从需求文档、设计文档开始Review，SDE编码，SDET写测试用例，跟极限编程的过程类似。极限编程的基本过程：构思 -& 编写测试代码 -& 编写代码 -& 测试，编写测试和编写代码都是增量式的，写一点测一点，在编写以后的代码中如果发现问题可以较快的追踪到问题的原因，减小回归错误的纠错难度。
而互联网行业：快很重要，有bug在线上也方便修改发布，更提倡full stack developer，代表企业：amazon、facebook、google等。开发与测试人员比例，google 10:1， MySpace 5:1。阿里资深专家，amazon前高级经理，陈皓认为：并不是互联网公司认为测试不重要，而是他们认为正因为测试很重要，所以才不应该交给只做测试的 人，开发人员要对自己开发的产品质量负责。对于一个公司，“产出性”的人应该多于“支持性”的人。当你的条件受限人手不够的时候，你必然不能干所有的事， 但你要去做很多自动化的事情，不管是自动化部署还是自动化运维。然而当你的人多的时候，你必然只会简单用人来解决问题。劳动密集型与知识密集型的公司差别 就在这里。
以微软和google为代表的保证产品质量的做法，都有道理，而且都是成功的。但是，我个人更倾向于full stack developer，第一，招很多SDET对大部分公司都不现实，合格的SDET薪资不会比SDE低;第二，我认为开发人员要对自己的开发的内容负责，主 动的想办法提高产品质量，而不是被动的等测试。
产品质量目标
评估产品质量，常用的是千行代码缺陷率，以下是查到的一些业界的千行代码缺陷率数据。典型的统计表明，在开发阶段，平均50~60个，交付后 15~18个;微软内部测试的产品10-20个，正式发布产品0.5个;某外包公司，A级≤ 0.5个，B级≤1个，C级≤5个;航天飞机的软件，0个/50万行。缺陷率做到平均水平的1/10是很少见的，而如果10倍以上，产品可能永远也不会完 工。
跟性能瓶颈一样，80%的错误往往出现在20%的代码中。大部分错误都是低级错误，比如，对需求或设计的误解、书写错误、赋值语句、边界错误或循环错误。大多数错误是容易改正的。另外，warning是很多错误的根源，所以工程里要禁止warning。
主要通过检查和测试。检查包括：需求检查、设计检查、代码详查，测试包括：单元测试、集成测试、系统测试等。
有统计数据表明：单元测试的平均错误检出率是25%，集成测试35%，小规模Beta测试35%，系统测试45%。而对设计和代码进行详查的错误检出率分别是55%和60%。
阅读代码要比测试平均每小时多发现80%多的错误，代码检查和测试所获得的收效之比为8:1。这是因为，错误越早发现，解决成本越低。
检查方法：协同编程，详查需求、设计、代码。不仅仅是检查，要提前思考怎么做?带着思考检查。
1. 基于结构的测试。测试用例要覆盖每一条控制语句，if for while and or switch case等。
2. 数据流测试，避免重复初始化、重复销毁、定义不使用、未初始化使用等情况，检测数据流变化。
3. 错误猜测：
1). 边界分析，&=与&的区别，null、size是0的情况，比如测试小于MAX，三种边界情况MAX，10000个好友/道具的时候会不会导致游戏卡死?
2). 复合边界，int add(int a, int b)，a和b都小于2^31，但是，如果a和b都很大，它们的和会不会出界?
3). 坏数据，太小/大的数据，未初始化的数据，错误类型的数据，错误长度的数据等。
4). 向前兼容和向后兼容。比如，游戏最新版本是2.5，但是有的玩家一直不更新，还是1.0，要兼容这些玩家。
在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。
综合考虑我们团队的实际情况，最后我制定了“详查+单元测试+集成测试+系统测试”的方案，来提高我们的产品质量。有些方法，比如协同编程、净室开发，虽然很好，但是对于我们的团队来说，执行起来太难。ps：我对净室开发很感兴趣，正在研究，研究透以后可能会试着采用。
详查：先自己详查，从需求开始，然后是设计和编码;然后，团队中的小伙伴互查。关于详查，有两点需要注意：1. 检查前，要先制定代码规范，让开发人员不把精力耗在代码规范的争执上。2. 详查结果不作为员工表现的考核标准，考核应该基于最终的产品。
单元测试：重点是理清流程，针对每个流程都测试到。集成测试：把单元测试的功能组合起来测试，侧重于模块的整体性。系统测试：有点像QA的普遍工作，从功能上测试，各个需求点是否都正常。
执行：我首先制定了代码规范，并给大家讲解，然后征求大家的意见统一。然后，写了一份本文章的内部版本，并给大家详细讲解(为了让小伙伴们更容易，内 部版本细节比较丰富，举了一些例子，写的比较啰嗦，稍微精简、加工之后，形成了这篇blog)。另外，需要注意，详查结果不要作为员工表现的考核标准，考 核应该基于最终的产品。
赞赏是对原创者的最大认可
收藏已收藏 | 16赞已赞 | 5
爱因斯坦没有解决的问题，交给泡面（PM）解决
产品经理群
运营交流群
AI产品经理群
文案交流群
Axure交流群
关注微信公众号
大家都在问
16个回答20人关注
15个回答15人关注
4个回答15人关注
52个回答43人关注
17个回答78人关注
17个回答71人关注欧页棋牌游戏开发该如何提高产品质量
产品质量是公司盈利的根基，欧页棋牌游戏开发公司也一样，只有开发出优质的专业的棋牌游戏，才有资格在棋牌游戏开发行业立足。
棋牌游戏的竞争是很激烈的，因为这是一个相对收益较快的行业。游戏开发是一个长久性的发展。同时对于人才积累也是很重要的，开发出来的产品要求有很高的质量保证，要做到产品的精益求精。
棋牌开发人员提升专业水平
棋牌游戏平台的升级和更新换代都是开发人员主导的，这就要求了游戏开发人员在工作之余需要多补充专业知识，以便开发出在市场上更占优势的产品。
棋牌游戏策划人员紧跟市场需求
策划人员的主要工作是编写游戏背景故事，制定游戏规则，设计游戏交互环节，计算游戏公式，以及负责其他游戏中的细节。策划人员需要对棋牌游戏市场的最新需求有着清醒的认知，能及时掌握到玩家对游戏的想法和建议，以及时做出最新的策划文档。
客服人员收集玩家反馈
棋牌类游戏平台的客服人员是直面玩家的工作人员，与玩家沟通较多。他们可以通过制作调查问卷、总结用户投诉等方式获得反馈，来帮助策划人员与研发人员对棋牌游戏进行升级。
提高棋牌游戏开发质量别无他途，更无捷径，只有根据市场需求，踏踏实实地提高技术水平，严格把关，从而提高棋牌游戏的质量。
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
厦门欧页科技有限公司-手机棋牌游戏开发、捕鱼游戏开发、游戏资质代办等。
厦门欧页科技国内十佳棋牌开发商，深受广大运营商的推荐！
今日搜狐热点英雄联盟设计师：游戏动画压缩如何保质量
招聘信息：
不论是哪个平台的游戏，开发商最为头疼的问题之一就是包体大小，因为它不仅影响玩家硬件的存储空间，还直接决定玩家从发现到体验游戏的时间差。而游戏动画则是占用资源最大的部分，所以如何压缩动画是所有开发者都需要面对的问题。最近，《英雄联盟》开发商Riot Games发布了相关的技术贴，设计师Jaewon Jung通过博客的形式讨论了如何在不降低动画质量的情况下进行动画压缩的话题，并且在文章中讲述了Riot公司所使用的一些技巧，希望给遇到这类问题的开发者提供一些帮助。以下为转载自Gamelook编译的完整博文：《英雄联盟》的英雄数量已经超过了125个（目前正式推出126个），每个都有一套独特的动画设定，要问我最喜欢的是哪个？毫无疑问是亡灵勇士-塞恩的跳舞动画（下图），而这只是他38个动画中的一个。这些动作的加入才让英雄们变得栩栩如生，从角色的移动到强大技能的释放以及悲惨的死亡动画，都可以让英雄变得更有个性。随着我们不断的增加和重做英雄，动画数据的总量已经形成了很大的资源负担，比如运行内存、补丁大小以及存储空间等等。除了动画数据之外，最近发布的《召唤师峡谷》视觉更新则增加了内存需求，这次的更新使用了Unique-texel的做法，比此前的Tiling方式更能带来优秀的视觉效果，然而它也不可避免的增加了地图对于内存的占用。我们认为支持多种不同配置的硬件是非常重要的，这样所有人才能同时享受到游戏的乐趣。随着新的动画和地图更新的内存需求不断增加，我们开始寻找降低内存使用的方法。我们发现的其中一个方法就是压缩游戏内骨骼动画数据来减少内存占用，同时维持最低的质量损失，还要保证不对性能产生任何影响。我们可能用了很多方式进行动画数据压缩，但在这个博客中，我会介绍我们主要使用的2个：量化（Quantization）和曲线拟合（Curve Fitting）。压缩的做法总会带来质量降低和释放内存空间两者的矛盾，所以，我会讲述我们发现的可以让人接受的方案，还会解释我们是如何管理数据并且做到最大化性能的。我会使用一些像四元数（quaternions）以及样条曲线（Spline Curves）这样的概念，所以，如果你们对这些不熟悉的话，可以参考博客结尾中非常有用的参考资料。我需要说明的是，这篇博客里提到的所有东西都不是什么新技术，而是从事游戏开发的伙伴们分享的一些非常实用的知识，我还想补充的是，游戏引擎开发商BitSquid（已被Autodesk收购）的博客是非常有帮助而且值得一看的。量化（Quantization）量化指的是把一系列连续的可能性限制在相对小而分离的设定的处理过程。骨骼动画（Skeletal animations）有位置、旋转和量化数据，我们很容易量化3D矢量（用于表示位置和量），只要通过获得他们的最大/最小值范围并且在这个范围内统一分割即可。但骨骼动画数据的复杂性通常来自于旋转。我们这里使用四元法指代3D空间里的旋转，我们量化旋转数据的方式使用了四元数的特殊数学性质，我们使用了单位四元数（unit quanternions），所有组件的范围都是[-1，1]，并且找出最大绝对值的元素定义x，y，z，或者w。然后放弃（绝对值最大的）并保留其余三个，因为我们可以很容易计算出被省略的组件，只要这个单位四元数满足x2 + y2 + z2 + w2 = 1方程式即可。通过省略最大的组件，我们可以把其余三个组件的范围限制在[-1/sqrt(2), 1/sqrt(2)]之间，要知道，在单位四元数当中，这个范围之外的一个组件必须具备最大的绝对值，所以这也是我们将会忽略掉的组件。我们通过量化到比[-1，1]更小的范围来最大化精确度，如果不排除最大组件的话，我们原本可能会（误）用这个范围。这样的做法还让我们避免了对一个较小价值的组件进行重做，从而避免了更多的错误。通过这种方式，我们为每三个保留下来的组件都分配15 bits，被省略的组件分配2 bits，因此每个四元数都总共占据48 bits（其中1 bit是不使用的），细节如上图。作为对比，未经处理的四元数需要为每个组件使用32 bits的浮点数（floating-point number），所以最终使用128 bits，通过我们的处理，原本的128 bits降低到了48 bits，也就是说，我们的压缩率达到了0.375。这种48-bit的四元数量化可以保证数值精度（numerical precision）达到0.000043。所以你可以想象，这个精度几乎可以适用于所有的案例。实际上，当我们把这种量化方式应用到所有动画的时候，没有任何一个动画出现质量下降。另外，我们可以把这些转化应用到加载时间而不是持续的大批量转化过程，所以也不需要以后再为此打补丁，所以这种量化方式是非常简单可行的。样条曲线适配（Curve Fitting）为了进一步压缩，我们使用了样条曲线适配的方式来改变四元数的值，这是一个创造曲线的过程，或者说是数学功能，能够最佳适应一系列的数据点。我们特别使用了Catmull-Rom样条曲线，可以用一个三阶多项式（3rd-order polynomial）表示。你需要四个控制点来确定Catmull-Rom样条曲线，下面借用维基百科提供的数据图可以更好的说明：为了做到准确的适配，我们使用了迭代（iterative）方式来减少失误，这个过程一开始只有2个关键帧（keyframes），并且包含了动画的开始和结束。我们通过迭代的方式增加更多的关键帧来减少曲线的整体失误，把它降低到一个可以接受的水平。在每一次的迭代中，我们都找出关键帧之间的最大错误，并且插入一个中间点关键帧作为替代，这个找错并且替代关键帧的过程是不断重复的，直到每一个部分的错误都降低到可以接受的程度。你可以看上图的红色适配曲线和绿色初始曲线在迭代过程中的对比。黄点代表每次迭代过程中增加的（新的）关键帧。通过这种做法，我们经过88次的迭代之后，把最初的661帧降低到了90帧。在做曲线插值（curve interpolation）之前，千万不要忘记调整四个四元数控制点。一个四元数Q和它的相反数-Q代表的是同样的旋转，但如果不调整的话，最终旋转可能无法实现最短途径的插值。比如，一艘向北行驶的船准备转向东方，如果没有合适的四元数调整，那么它可能直接逆转270度才能做到，而不是顺时针转90度。曲线适配可以对量化结果进行进一步的压缩，而且压缩率在25%-75%之间。我们发现为定位、旋转和量化数据设置合适的误差值对于不损失视觉体验情况下获得最大化压缩率是至关重要的。为了更好的压缩，我们还考虑了样条曲线节点参数，比如在动画数据的案例中，基于关键帧时序（keyframe timings）的参数是最自然的。不过，你仍然可以看一下的数据（也是来自维基百科），四个同样控制点的曲线形状取决于使用哪种节点参数：比如uniform、chordal或者我们使用的centripetal。这些技术会对于某些动画造成明显的质量损失，但通过使用严密的误差值，我们可以把损失降低到最小，但这样做的压缩率也会降低。因此，我们的动画师对每个案例都进行审查，以求做到质量和压缩率方面的平衡。而且，和量化过程不同的是，由于曲线适配过程需要大量计算，所以不可能转换到加载时间上，因此我们必须对所有现存的动画数据进行预处理。降低损失压缩过程导致最明显的现象就是foot sliding，这会导致动画中出现角色的脚或者任何末端执行器（end-effector）一直不动。你可以从上面图中很容易的看到本来应该摆动脚却一直不动。这是因为skeletal rigging中的骨骼是分等级的，错误的累积会造成很大的影响。我们解决这种问题的方法是使用了一种我们称之为‘可适应错误率（adaptive error margins）’的技术，它意味着如果一个节点有较长的派生数，你需要把误差值降到最低，而不是为所有的节点使用同样的误差值。比如，一个末端执行器使用特定的比例，但其母单位则使用半数，那么更上一级的则使用三分之一数，诸如此类。这种自上而下的误差率降低可以最大化限制派生值发生错误的概率。《Game Programming Gems 7》一书介绍了另一种被称为‘在骨骼动画中减少累积误差’的方法，我们内部把这种方法叫做“连接销（joint pinning）”。对一个连接销（比如足部），我们不使用源数据流（source data stream），而是计算新的本地转换数据，这样可以抵消早代数据压缩中所产生的误差，这本书中还有更多在这个话题是非常不错的材料，值得同行们一读。允许缓存的数据结构（Cache-friendly Data Organization）最后，我们来讨论有效实现了以上概念的方法，在研发这些技术的同时，我们同时非常清醒的知道玩家们的硬件存在很大差异，而且对于降低性能方面的做法十分谨慎，我的团队专注的其中一件事就是实现允许缓存的数据结构。我们采取的非常关键的一步就是把所有的关键帧（每一个连接销的位置、旋转和量化帧）放到一个相连的存储块里。通常见到的做法都是为每个连接销创造不同的存储块，但这样看似自然的结构在特定时间段评估一个完整骨骼姿势的时候会导致严重的缓存丢失。我们把数据放到一个存储块是因为所有渠道类型的有效负荷都是48 bit，如我们此前所见，我们把四元数量化到了48 bits，还把3D矢量的每一个x，y以及z组件都分配同样的16 bits，你可以从下面的压缩帧数代码看到实际的代码连接销结构：这里，我们还把key time量化到了16 bits，连接索引（jointIndex）基于各自帧数数据而不同。V箭头包含了量化的有效负荷，确定有效负荷是属于旋转、位置还是量化是非常重要的，我们使用这两种最重要的连接索引来完成。这种方法可以把连接索引控制到14 bits，我们一共有16384个连接销，这对于《英雄联盟》的英雄来说是足够用的了，因为通常一个英雄只使用不到100个。所以对着这些连接销做恰当的关键帧顺序是非常重要的，不管是那种连接销或者类型都很重要，我们本可以用key time进行琐碎的排序，但问题很快就出现了。你可以想象一下动画运行时会发生什么，从下面的图片就可以看出问题：你可以看到被key time分开的四个关键帧以及一个标明了目前重放时间的计时针，你需要Tn、Tn+1、Tn+2以及Tn+3的信息，因为评估一个样条曲线需要四个控制点。如果计时针的目前位置是已经过了Tn和Tn+1，那么它应该是已经熟悉了的，可Tn+2和Tn+3怎么办？你可能会觉得自己可以快速的进行线性扫描，因为这两个帧是可以快速找到的。然而这种方法并不是最优的，假如说这些T是帧数位置，如果动画包含很多旋转变化的话，那么很多的旋转帧可能会存在于两个临近位置的帧数之间（如下图）。这样的话，所有的帧都放在了一起，通过线性扫描的方式寻找Tn+2和Tn+3就是非常低效率的。要让每一次线性扫描都实现回放的诀窍在于，你要按照时间需要的顺序组织帧数，而不是根据key time。一旦计时针通过了Tn的key time之后我们就需要Tn+2，因此我们应该把Tn+2根据Tn的关键数据进行安排。这样任何时候都可以获得需要的信息，所以缓存丢失就可以被最小化。下面的图表可以展示这个工作原理：希望我们使用的压缩方法能够帮助到所有遇到类似问题的开发者们。结论平均来说，在这篇文章中我所讨论的量化技术基本上让《英雄联盟》的英雄内存需求减半，我们还在努力把曲线适配技术做到更好，因为它需要预处理所有的数据，但从我们初期的结果来看，很可能实现另外50%的压缩率，也就是说，我们很肯能做到把最初的内存需求降低到25%，我对此感到兴奋，因为这样就有机会提高各种玩家设备的游戏体验。我们未来还可能探索更多的方向，比如32-bit四元数量化、对不同的曲线适配做不同的节点参数、用最小二乘法适配替换迭代的做法、对增加新的key进行更多优化等等。动画压缩是一个广泛而且非常深度的话题，我们本文讨论的还只是冰山一角。不过，我仍旧希望这些是对你们做动画压缩有帮助的，下面是一些参考文献的链接，祝你们好运。参考文献动画压缩Reducing Cumulative Errors in Skeletal Animation, Bill Budge (Game Programming Gems 7)曲线适配通用压缩方法为准备本文材料所用到的工具
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量3786点击量3252点击量3032点击量2979点击量2856点击量2768点击量2753点击量2737点击量2572
&2016 Chukong Technologies,Inc.
京公网安备89}