一个游戏开发者的反思?缺陷与出路
作者:网络转载 发布时间:[ 2014/8/25 13:56:28 ] 推荐标签:软件测试管理 缺陷管理
理论上,构建一个虚拟的世界,它的基本要素越是高度概括和定义的,那么底层设计工作的重用性越高,扩展性也越大,同时,由于每次依靠本层次控件和规则构成往上一个层次时都可能与初的设想有极小的偏差,因此终层次的表象控制越难。如果我们把当前的宇宙视为一个游戏项目,那么,上帝至少在设计之初将“夸克”视作底层的材料,而我们看到的整个世界都是由几种基本的“夸克”构成的(看来上帝的美术工程师很省工)。由于层次非常多,这个世界后的面貌很可能与上帝的提案书差距非常大。当然,上帝可以在高层直接添加规则来更改这个差距。
D&D代表了目前游戏设计能够高度概括到的极限(或许《进化》能打破这个纪录,还没有看到游戏,不知道具体情况)。我们做游戏设计,没有必要做到这个层次,只需要抽象到玩家看到的具体控件的下面一层可以。例如MMO中有设计纸娃娃的需求,里面有衬肩,那么,我们只要比常用的做法更进一步,将衬肩再向下一个层次,分为贴图风格、形状、种类、颜色4个基本控件,那么,只要每个控件做少量几种能组合成很多种类的衬肩,这样规划可大量减少美术的工作量。而常规做法只能是一个个衬肩去建模和绘制。
概括和定义底层是游戏设计对商业需求分析后简单的一个步骤。在分析商业需求过程中,我们可针对各个方面抽象出类似的关键问题:
1)NPC、怪物、Boss和玩家角色是否属于共同的类?如果是,这个类如何定义?其子类如何定义和区分,基本属性、骨骼、模型、纸娃娃、动作是否通用?各子类是否有必要定义各自的子类?这些所有定义对于美术和程序工作的影响何在?
2)职业、种族作为通用模板如何对上述的类中的对象进行作用,其作用是否与子类的定义相关?
3)作为场景设计的需求,有多少建筑对象以构件组合方式可以作出变化?如是,组合需要支援多少种风格?有必要单独设计的建筑有多少?
4)有无可能以一种统一的升级规则操作基本属性来控制所有的平衡?
这种问题还有很多,根据游戏类型的不同,进行设计时的需求也有很大变化。
游戏设计符合软件工程的要求,需要项目负责人有基本的软件工程知识,并有相应领域的专家加以配合。很多Boss和Leader喜欢拿到提案书开始督促手下人干,事实上,如果给大家几个月的时间实现一个规范的工业设计,能避免以后无数的问题,节省大量返工的成本。
前面说到的是游戏开发这个项目的初步设计问题,接下来我想谈一下我对于游戏设计过程具体管理的看法。
游戏工业的理想状态,应该是流水线生产、精益生产、个体创造的结合,在策划阶段、游戏架构阶段、试生产阶段、测试阶段需要采取不同的策略,从而大程度降低风险、降低成本及控制开发时程。注意“面向过程的管理”这个精益生产的实质,正是游戏开发未来所必须追求的目标,也是实施游戏工业设计规范所不可缺的部分。长久以来,游戏业内的管理是“面向人的管理”或“面向目标的管理”,甚至有的连目标管理都没有,而不用说进行真正的过程管理。
肯定有读者会说:谁说中国游戏开发没有过程管理?没有月表么?没有开发计划么?没有工作日志么?我要说的是,并不是表述了过程可自认为进行了过程管理,也不是每天跑去问程序进度如何是做了过程控制。“面向过程的管理”包括非常多的技巧和细节,这需要管理者去研究、规划和控制。
二、项目开发中的混沌和秩序
我们可能都听说过这些说法:“你不可能不劳而获”“覆水难收”或“天网恢恢,疏而不漏”。如果这些谚语对你说来不算陌生,而且在日常生活中你也反复有过这样的亲身体验,那么你懂得了热力学第一定律和第二定律。
——《熵:一种新的世界观》
在游戏开发过程中,很多人应该有过这样的经历:整个项目的细节越来越多,但没人知道整体是个什么样子;自己做的工作越多,越感到没有信心和无助;不断修改、修正和返工。其实,这是热力学第二定律所表述的,整个项目的无序性在增加,如果不加以控制,那么后的结果是进入无序的状态,也是整个系统的平衡态,即完全裹足不前的状态。事实上,无论游戏制作人意识到与否,游戏能否正常开发完成、能否达到立案之初的目标,很大程度上取决于游戏团队对抗热力学第二定律的能力。
之所以熵增原理对游戏开发影响如此之大,是由游戏开发本身的特殊性所决定的。以制造业为对比,制造业发展到现在非常成熟,其整个工程的无序性和不确定性并不随着规模的增长而质变,原因在于:
1)产品各部件的质量定义非常清晰(目标清晰,需求明确);
2)每道工序对于终产品的作用易于进行量化评估;
3)成熟的流程管理或过程管理机制;
4)专业化的团队;
5)重要的,足够的理论指导和经验积累;
以上是使传统制造业免于熵增原理荼毒的几个关键因素,而游戏开发业显然不具备这些因素。结果是,制造业常规状况下都能完成产品的量产和销售;但只有不足一半的游戏正常开发完成,而达到立案目标的可能不足2成(仅仅从国内的状况而言可能更少)。
大型的游戏项目从立案到策划案,到程序架构设计、底层开发、工具开发、上层逻辑编写,到美术资源制作、到整合、到测试,经历了一个单向资源流动的过程,这个过程类似一条河流在流动过程中不断吸纳支流,终汇流入海。在资源传递的过程中,由于传递的层次很多,在语言和文字的表述无法精确的状况下,多次的传递不仅容易产生错误、遗漏,还会不可避免地出现误解。每个层次资源传递中出现一点的偏差,汇总到后可能出现若干巨大的错误,这是“差之毫厘,谬之千里”。
在缺乏成熟管理机制的游戏开发业,使得热力学第二定律在这方面有了很大的发挥空间。某些策划懒得写必要的文档,依靠口头说明办事;部分团队没有工作总结;很多策划不知道能通过非语言手段(图片、拓扑等)表述信息;更多公司从来不写会议纪要和讨论纪要;绝大多数制作人都没有项目关键词定义的概念。
因此,要首先重视定义,才能制定有效的沟通机制。
在论坛里或朋友之间,我们经常能听到某个朋友说:“如果XX游戏这样设计好了”,或抱怨说:“XX游戏为什么没有继承前一代的某种优点?”在游戏开发中,我们用“功能模块”来表示玩家所提到的这种乐趣点。一个功能模块往往代表了玩法的一个方面,当足够多的模块被整合之后,玩家所看到的是我们希望展示的游戏世界。很多设计者试图堆砌足够多“好玩”的独立系统来形成一个“足够好玩”的游戏。“好玩”的独立系统随着新游戏的推出在不断增加,因此形成一个“足够好玩”的游戏需要的部件越来越多了。由于每个游戏模块都会通过某些接口来操作游戏属性/游戏进程,从而发生作用,这些操作与其他模块的操作可能产生相似/互斥的结果,甚至可能改变其他模块的开关状态。因此理论上,每个新模块被整合进入系统时,制作者都必须检查所有与此模块具备公共操作区域的原有模块,甚至必须检查所有操作可能带来的属性变更对依赖属性的原有模块的影响,这在系统足够大的时候是不可能完成的工作。
这带来了另外一个熵增的根源,项目的复杂度随着模块数量的代数递增作几何递增。即制作人对项目的控制力和把握会随着项目规模的加大而迅速降低,当复杂度到达一个临界点时,制作者追加任何模块,其整合成本对团队都是无力承担的。在这种状态下,依靠堆砌的制作人会在一个阶段之后突然发现,大量问题突然的、集约的出现。
相对稳妥的做法是:确认核心需求,并围绕核心设计必要的外围需求,从底层构架一个层次分明的需求,避免堆砌大而全的四不象,突出重点。
熵增原理作用的一个重要来源是缺乏计划性。由于缺乏经验和理论指导,加之相对漫长的开发过程导致市场的快速变化,在开发过程中,游戏制作者经常主动或被迫频繁地调整策划细节,这种藐视计划性的做法直接导致软件开发目的的不确定性递增。而不确定性反过来作用于游戏团队本身,使开发人员泄气和疲惫,降低工作效率和主动性,终没人会相信工作计划,也没人会尽力做好自己的工作,因为这个工作随时会扔进马桶(被新的需求取代)。一种极端的状况是,有些团队连基本的工作计划和里程碑都没有,每周的工作完全是项目经理来临时安排;另一种状况是,一个既定的计划不会被尊重,开发计划几乎每星期都会推倒修改。很显然,这两种状况下开发已完全失控,其无序性远远超出了正常范围,开发团队必须付出几倍的预算和时间才能获得一线生机。
所以,像对待承诺一样信守你的计划——千万别轻于承诺,但承诺了要做到。
以上说的是3个常见的现象,本章我们讨论的热力学第二定律,其实代表了项目开发中混沌和秩序的对决,而对抗热力学第二定律的实质是,追求设计规范所带来的秩序和控制力,减少无序性和不确定性。
三、游戏设计的量化问题
我们谈过了游戏开发过程中面临的诸多问题,但这里还有一个基本问题是——是不是所有开发工作都能被量化?
很多游戏从业者都对此问题持否定的态度。游戏产业是一个创意产业,创意和艺术创作怎么能被量化?所以有很多号称牛人所写的文章、接受的采访,大谈游戏开发管理的难度,主要根据是,设计工作/艺术创作无法被量化。
真是这样么?
在长度度量衡没有被发明之前,我们可以猜想,人类只能使用简单的表述来说明距离或长度,例如“高”“很高”“远”“很远”“非常长”等,在现代人看来,这种表述“十分不量化”,但在当时的人类认知中,长度应该是无法量化的,因为缺乏一种单位标准,可以使得不同的人能对长度进行同样精确、相同认知的表述。这里,我们可以看出,至少在数学概念的量化上,需要“单位标准”的确定作为前提。
在上面的例子中,一旦加减法被发明出来,度量衡会出现,人们会定义长度的单位和换算方式,此时长度变为可量化单位了(看到这里,会不会觉得《文明》系列中的科技缺了不少?)。
所以,认为游戏开发工作不能被量化的游戏开发牛人们,要么是对游戏开发工作根本不懂;要么是对其他行业的研究成果视而不见,坐井观天;有更多的混子们觉得“不能量化”是糊弄投资商和Boss好的挡箭牌。
大家可以去Google查查“量化管理”,这已经是项目管理学基本的概念,但居然还有这么多游戏业的牛人、老人嚷嚷无法量化,只能说悲哀,这行业的现状让人欲哭无泪。
关于如何“量化”的攻略不管是在网上还是网下都已非常多了,也非常系统了,这里且不多说。大家去搜索一下,注意多看广告和网站的,人家本质上也是创意产业……看完以后你保证有抽那些“无法量化”牛人的冲动。
在整个游戏开发设计过程中,没有一个阶段是无法量化的,不过存在一个量化成本的问题。因为量化需要度量,度量过程需要建立标准、对比标准,对于很多无法用数字表述,必须借助统计甚至拓扑来表述的量化目标来说,这个操作过程的成本很高。所以在游戏初设计的阶段,也是量化成本高的阶段,不必使用“量化”的概念去管理和操作。但在后续开发中,必须将程序、美术等工作都做到量化管理,这是使游戏成为工业化生产的前提,也是我们进行规范的前提。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。
相关推荐
软件测试理论之缺陷管理Bug的生命周期的跟踪管理是怎么形成的?目前比较好用的缺陷管理工具都具备什么特点?缺陷等级的标准是如何判定的?有什么好用的缺陷管理工具吗?缺陷管理中缺陷的状态有哪些?如何进行状态管理?软件测试中的缺陷管理步骤和策略如何有效结合缺陷管理工具和缺陷管理流程?ALM(生命周期管理软件)之缺陷管理-缺陷流程处理ALM(生命周期管理软件)之缺陷管理-缺陷导出与修改ALM(生命周期管理软件)之缺陷管理-缺陷模版配置、导入缺陷ALM(生命周期管理软件)之缺陷管理-提交缺陷缺陷管理之Bug修复软件缺陷管理缺陷管理之测试新手缺陷管理项目实战缺陷管理工具:JIRA系统部署推进上线流程软件缺陷管理流程
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11热门文章
常见的移动App Bug??崩溃的测试用例设计如何用Jmeter做压力测试QC使用说明APP压力测试入门教程移动app测试中的主要问题jenkins+testng+ant+webdriver持续集成测试使用JMeter进行HTTP负载测试Selenium 2.0 WebDriver 使用指南