《熵：一种新的世界观》个游戏开发者的反思

　　这带来了另外一个熵增的根源，项目的复杂度随着模块数量的代数递增作几何递增。即制作人对项目的控制力和把握会随着项目规模的加大而迅速降低，当复杂度到达一个临界点时，制作者追加任何模块，其整合成本对团队都是无力承担的。在这种状态下，依靠堆砌的制作人会在一个阶段之后突然发现，大量问题突然的、集约的出现。

　　相对稳妥的做法是：确认核心需求，并围绕核心设计必要的外围需求，从底层构架一个层次分明的需求，避免堆砌大而全的四不象，突出重点。
　　熵增原理作用的一个重要来源是缺乏计划性。由于缺乏经验和理论指导，加之相对漫长的开发过程导致市场的快速变化，在开发过程中，游戏制作者经常主动或被迫频繁地调整策划细节，这种藐视计划性的做法直接导致软件开发目的的不确定性递增。而不确定性反过来作用于游戏团队本身，使开发人员泄气和疲惫，降低工作效率和主动性，最终没人会相信工作计划，也没人会尽力做好自己的工作，因为这个工作随时会扔进马桶（被新的需求取代）。一种极端的状况是，有些团队连基本的工作计划和里程碑都没有，每周的工作完全是项目经理来临时安排；另一种状况是，一个既定的计划不会被尊重，开发计划几乎每星期都会推倒修改。很显然，这两种状况下开发已完全失控，其无序性远远超出了正常范围，开发团队必须付出几倍的预算和时间才能获得一线生机。

　　所以，像对待承诺一样信守你的计划——千万别轻于承诺，但承诺了就要做到。
　　以上说的是3个常见的现象，本章我们讨论的热力学第二定律，其实代表了项目开发中混沌和秩序的对决，而对抗热力学第二定律的实质是，追求设计规范所带来的秩序和控制力，减少无序性和不确定性。

　　我觉得这篇文章的这一段简直就是在说大话3很多的不成熟地方，粉红字中提到的“功能模块”并入整个系统时，与原有的系统没能整合好而并发的各种问题，就像是三阶技能，只设计好框架，但是具体的数据与攻防并没有先设计好一个合理的模型。
   
　　还有这段时间新星这个“功能模块”并入现在的系统时也出了太多的问题，你们在开始有星系统时就应该设计好合理的各种星数据，那样也绝不会出现现在这种情况。