游戏开发成功论（四）：量化

jiantx78

原文：
http://blog.sina.com.cn/u/4a6e7dce010006bc

4，游戏设计相关：量化



感谢大家之前提出的意见和反例。有任何意见都欢迎在blog留言。



另外，我希望各位了解，任何的理论，包括我们所谈的游戏开发规范，都有其局限性，都有其作用范围和作用前提，我们不能指望有一个完美无暇的理论，亦或流程，可以无限制的解决游戏开发中任何阶段的任何问题，也不能苛求此理论绝对没有一个反例。那不是规范，那叫神话。举个例子，在量子力学和相对论出现之前，经典物理学的学究们曾经认为“物理学的大厦已经建好了”，实际上我们现在看来，物理学在当时才刚刚起步而已。因此，我们要把个案研究和理论研究进行区分，个案代表一个现象集，而理论则是探讨多种现象的本质，并试图引导人们获得更佳的结果。



同时，文章的阅读性和深度，以我目前的能力确实无法兼顾，大言不惭的说，似乎也没什么牛人能真正做到。大家所经常推为经典科普的《时间简史》，有几个人能真正读懂其理论部分？充其量不过是满足物理盲们对理论物理的窥阴癖而已。这也是为什么我blog上米果相关文章的点击是本系列的N倍——大多数人都是看热闹的，真正有探讨、学习心态的人寥寥无几。



以上并非正题。



在构成游戏开发工业规范之前，与抽象和层次同样重要的一个基本问题是，是不是所有开发工作都是能被量化的？



很多很多游戏从业者，都对此问题持否定的态度。游戏产业是一个创意产业，创意和艺术创作怎么能够被量化？所以就有很多号称牛人所写的文章，接受的采访，大谈游戏开发管理的难度，主要根据是，设计工作/艺术创作无法被量化。



真的是这样么？



在长度度量衡没有被发明之前，我们可以猜想，人类只能使用简单的表述来说明距离或者长度，例如“高”，“很高”、“远”、“很远”、“非常长”等等，在现代人看来，这种表述“十分不量化”，但是当时的人类认知中，长度应该是无法量化的，因为缺乏一种单位标准，可以使得不同的人能够对长度进行同样精确、相同认知的表述。这里，我们可以看出，至少在数学概念的量化上，需要“单位标准”的确定作为前提。

在上面的例子中，一旦加减法被发明出来，度量衡就会出现，人们会定义长度的单位和换算方式，此时长度就变为可量化的单位了（看到这里，会不会觉得文明系列中的科技缺了不少？）。

所以，认为不能游戏开发工作被量化的游戏开发牛人们，要么是对游戏开发工作根本不懂，啥都抽象不出来；要么就是对其他行业的研究成果视而不见，坐井观天；有更多的混子们觉得“不能量化”是糊弄投资商和boss最最好的挡箭牌。

大家可以去google查查“量化管理”，这已经是项目管理学N年前最基本的概念，但是居然还有游戏业的这么多牛人、老人嚷嚷无法量化。只能说悲哀，这行业的现状让人欲哭无泪。



如何“量化”的功略网上太多了，非常系统，不多说了。大家去搜索一下，注意多看广告和网站的，人家本质上也是创意产业……看完以后你保证有抽那些“无法量化”牛人的冲动。



整个游戏开发设计过程中，没有一个阶段是绝对无法量化的，不过存在一个量化成本的问题。因为量化需要度量，度量的过程需要建立标准、对比标准，对于很多无法用数字表述，必须借助统计甚至拓扑来表述的量化目标来说，这个操作过程的成本很高。所以，我们在游戏最初设计的阶段（游戏原型设计，不明白的等以后的章节吧），也就是量化成本最高的阶段，不必使用“量化”的概念去管理和操作。但在后续开发中，必须将程序、美术等等工作都做到量化管理。这是使游戏成为工业化生产的前提，也是我们进行规范的前提。



本节本来想写很多关于开发量化的方法，一查，网上全有……偷懒一下吧。

心灵震撼者

量化。。。。

嘿嘿。。。。。有道理。。。

shengkz

确实值得思考。
我觉得如果是自己做引擎的话，应该策划先行半年，程序实现部分可以请一个资深程序顾问，把底层规划清楚，例如服务器构架方式，图形部分，逻辑处理都有一个明确的需求列表，然后进行各种编辑器的开发，首先是地形、角色编辑器，然后是事件、任务编辑器。程序开工后，同期进行游戏世界的规划，例如地形，建筑，人物，特效等，请一个资深美术作顾问，还有技能、物品的设置，大概需要半年时间，这些都完事后，正式启动美术。大概也是一年，策划其间进行游戏高层内容的开发，例如怪物分布、任务设计、数值演算等，而程序主攻系统脚本、调整BUG等工作。。。
思路有点乱，请高手大大们指点

storm1986

有了大框架，量化才可行。做游戏就像盖摩天大楼。想一想盖一栋楼的流程就知道做游戏要做哪些了。
游戏是软件，大型游戏制作是一项软件工程 。我觉得深入理解工程思想是关键，一个建筑设计师转行做游戏设计师，他会很容易理解游戏开发的步骤和做法。