【转】缺陷与出路—一个游戏开发者的反思 二、项目开发中的混沌和秩序
二、项目开发中的混沌和秩序
我们可能都听说过这些说法：“你不可能不劳而获”“覆水难收”或“天网恢恢，疏而不漏”。如果这些谚语对你说来不算陌生，而且在日常生活中你也反复有过这 样的亲身体验，那么你就懂得了热力学第一定律和第二定律。
——《熵：一种新的世界观》
在游戏开发过程中，很多人应该有过这样的经历：整个项目的细节越来越多，但没人知道整体是个什么样子；自己做的工作越多，越感到没有信心和无助；不断修 改、修正和返工。其实，这就是热力学第二定律所表述的，整个项目的无序性在增加，如果不加以控制，那么最后的结果就是进入最无序的状态，也就是整个系统的 平衡态，即完全裹足不前的状态。事实上，无论游戏制作人意识到与否，游戏能否正常开发完成、能否达到立案之初的目标，很大程度上取决于游戏团队对抗热力学 第二定律的能力。
之所以熵增原理对游戏开发影响如此之大，是由游戏开发本身的特殊性所决定的。以制造业为对比，制造业发展到现在非常成熟，其整个工程的无序性和不确定性并 不随着规模的增长而质变，原因在于：
1）产品各部件的质量定义非常清晰（目标清晰，需求明确）；
2）每道工序对于最终产品的作用易于进行量化评估；
3）成熟的流程管理或过程管理机制；
4）专业化的团队；
5）最重要的，足够的理论指导和经验积累；
以上是使传统制造业免于熵增原理荼毒的几个关键因素，而游戏开发业显然不具备这些因素。结果就是，制造业常规状况下都能完成产品的量产和销售；但只有不足 一半的游戏正常开发完成，而达到立案目标的可能不足2成（仅仅从国内的状况而言可能更少）。
大型的游戏项目从立案到策划案，到程序架构 设计、底层开发、工具开发、上层逻辑编写，到美术资源制作、到整合、到测试，经历了一个单向资源流动的过程，这个过程类似一条河流在流动过程中不断吸纳支 流，最终汇流入海。在资源传递的过程中，由于传递的层次很多，在语言和文字的表述无法绝对精确的状况下，多次的传递不仅容易产生错误、遗漏，还会不可避免 地出现误解。每个层次资源传递中出现一点的偏差，汇总到最后可能出现若干巨大的错误，这就是“差之毫厘，谬之千里”。
在缺乏成熟管理机 制的游戏开发业，使得热力学第二定律在这方面有了很大的发挥空间。某些策划懒得写必要的文档，依靠口头说明办事；部分团队没有工作总结；很多策划不知道能 通过非语言手段（图片、拓扑等）表述信息；更多公司从来不写会议纪要和讨论纪要；绝大多数制作人都没有项目关键词定义的概念。
因此，要 首先重视定义，才能制定有效的沟通机制。
在论坛里或朋友之间，我们经常能听到某个朋友说：“如果XX游戏这样设计就好了”，或抱怨说：“XX游戏为什么没有继承前一代的某种优点？”在游戏开发 中，我们用“功能模块”来表示玩家所提到的这种乐趣点。一个功能模块往往代表了玩法的一个方面，当足够多的模块被整合之后，玩家所看到的就是我们希望展示 的游戏世界。很多设计者试图堆砌足够多“好玩”的独立系统来形成一个“足够好玩”的游戏。“好玩”的独立系统随着新游戏的推出在不断增加，因此形成一个 “足够好玩”的游戏需要的部件越来越多了。由于每个游戏模块都会通过某些接口来操作游戏属性/游戏进程，从而发生作用，这些操作与其他模块的操作可能产生 相似/互斥的结果，甚至可能改变其他模块的开关状态。因此理论上，每个新模块被整合进入系统时，制作者都必须检查所有与此模块具备公共操作区域的原有模 块，甚至必须检查所有操作可能带来的属性变更对依赖属性的原有模块的影响，这在系统足够大的时候是不可能完成的工作。
这带来了另外一个 熵增的根源，项目的复杂度随着模块数量的代数递增作几何递增。即制作人对项目的控制力和把握会随着项目规模的加大而迅速降低，当复杂度到达一个临界点时， 制作者追加任何模块，其整合成本对团队都是无力承担的。在这种状态下，依靠堆砌的制作人会在一个阶段之后突然发现，大量问题突然的、集约的出现。
相对稳妥的做法是：确认核心需求，并围绕核心设计必要的外围需求，从底层构架一个层次分明的需求，避免堆砌大而全的四不象，突出重点。
熵增原理作用的一个重要来源是缺乏计划性。由于缺乏经验和理论指导，加之相对漫长的开发过程导致市场的快速变化，在开发过程中，游戏制作者经常主动或被 迫频繁地调整策划细节，这种藐视计划性的做法直接导致软件开发目的的不确定性递增。而不确定性反过来作用于游戏团队本身，使开发人员泄气和疲惫，降低工作 效率和主动性，最终没人会相信工作计划，也没人会尽力做好自己的工作，因为这个工作随时会扔进马桶（被新的需求取代）。一种极端的状况是，有些团队连基本 的工作计划和里程碑都没有，每周的工作完全是项目经理来临时安排；另一种状况是，一个既定的计划不会被尊重，开发计划几乎每星期都会推倒修改。很显然，这 两种状况下开发已完全失控，其无序性远远超出了正常范围，开发团队必须付出几倍的预算和时间才能获得一线生机。
所以，像对待承诺一样信 守你的计划——千万别轻于承诺，但承诺了就要做到。
以上说的是3个常见的现象，本章我们讨论的热力学第二定律，其实代表了项目开发中混 沌和秩序的对决，而对抗热力学第二定律的实质是，追求设计规范所带来的秩序和控制力，减少无序性和不确定性。
【转】缺陷与出路—一个游戏开发者的反思 二、项目开发中的混沌和秩序相关推荐
- 缺陷与出路——一个游戏开发者的反思（转自《大众软件》）
缺陷与出路--一个游戏开发者的反思(转自<大众软件>) blog原文: http://blog.sina.com.cn/s/blog_4a6e7dce01007rre.html 文章发表在 ...
- 缺陷与出路——一个游戏开发者的反思
文章发表在<大众软件>23期,主要是blog上<游戏成功学>这个系列的一个整理. 在此感谢大软的汪铁兄弟,对本文的修正和配图(有兴趣的读者可以看看那些配图,非常有意思) 由于是 ...
- 缺陷与出路—一个游戏开发者的反思
dmh2002注: 在你看这篇文章之前,我先说一下我对这篇文章的一些看法: 1.这是一篇不可多得的好文: 2.这是一篇很长的文章,但是我建议你最好读3遍: 3.作者提及的游戏开发中遇到的问题,超过80 ...
- 【转】缺陷与出路—一个游戏开发者的反思
原创作者暂时无从知晓,欢迎知情人士告知,感激不尽~ 一转:http://shake863.iteye.com/ 一.从D&D看游戏的底层设计 把一个所谓的游戏意义上的伟大创意在游戏产品上付诸于 ...
- 缺陷与出路——一个游戏开发者的反思（转）
转自:<大众软件> 一.从D&D看游戏的底层设计 把一个所谓的游戏意义上的伟大创意在游戏产品上付诸于实现的前提,是所有的设计应该符合游戏工业设计规范. --龙云峰<EEE&a ...
- 一个游戏开发者的反思—缺陷与出路
编者按: 这篇文章脱胎于一个叫<游戏人成功学>的系列文章,它是作者长期身处游戏开发行业.亲历游戏行业痼疾后不吐不快的随笔.世界上的任何事情都是这样,当一个人对某个事物了解越多,他也就越能清 ...
- 一个游戏开发者的反思：缺陷与出路(转)
阅读提示:本文是作者长期身处游戏开发行业. 亲历游戏行业痼疾后不吐不快的随笔.世界上的任何事情都是这样,当一个人对某个事物了解越多,他也就越能清晰地看到这个事物的缺陷.编者报道游戏行业也有 数年时间, ...
- 《看聊天记录都学不会C#？太菜了吧》（1）从今天开始我是一个游戏开发者
本系列文章将会以通俗易懂的对话方式进行教学,对话中将涵盖了新手在学习中的一般问题.此系列将会持续更新,包括别的语言以及实战都将使用对话的方式进行教学,基础编程语言教学适用于零基础小白,之后实战课程也将 ...
- 一个游戏是如何被设计和开发出来的（怎样开发一款游戏）
本专栏是着重于讨论"开发一款游戏需要怎样的能力",以及"如何学习开发游戏所需的所有技能".在开始讨论我们的两个主题之前,我认为非常有必要让初学者了解一下:一个游 ...
最新文章
- 轻量级图卷积网络LightGCN介绍和构建推荐系统示例
- directory not found for option
- ajaxsetup无效_Ajax请求session失效该如何解决
- linux下使用free命令查看实际内存占用
- mysql用dos窗口即cmd命令登陆mysql
- 【Kaggle-MNIST之路】CNN+改进过的损失函数（三）
- 山东专升本access知识点_专升本计算机速背知识点（十八）
- ESB学习笔记（Spring Integration实战）
- 你吃的瓜子仁，真是老奶奶磕出来的？！
- BZOJ 1036: [ZJOI2008]树的统计Count
- java定时任务增删改查_python实现crontab定时任务的增删改查
- 平台如何限制ip流量_社区团购平台如何通过地推获得更多流量？
- python 面向对象五 获取对象信息 type isinstance getattr setattr hasattr
- FX3SA三菱PLC使用软件GX Works2编写程序（梯形图等）
- Java基础面试题（持续更新）
- javaScript中this以及window对象和window对象的name属性
- RTB广告技术修炼之-流量漫游
- C语言万年历(n排)
- 两句话中的不常见单词（Uncommon Words from Two Sentences）java
- vue中如何点击返回上一页，vue判断没有上页返回首页