#思考
下面这段内容不知道能不能发出来，可能有关企业机密，专业性可能也比较强。
————————
某社确实很厉害，近些年凭借着高超的项目管理能力保证每年都有高质量大作出现。
年中曾有幸和他们的游戏设计师得知了他们的制作管理方式。
算是在底层上改造了许多制作管理方式和实现流程。
最主要的，是减少了策划、程序、美术、动作之间的拉锯沟通。
全部调整和组装都落实到策划身上，所以他们效率相当高。
我工作了十几年的传统开发模式，通常是由游戏设计师撰写一套整体策划案。
并分发给程序、美术、动作和音效，让他们制作相应的部分。
由于专业性比较强，最后还需再由程序来进行代码逻辑上的组装。
这样做的坏处是，当策划最终检查和调整时，发现进行最终组装的逻辑出错。
或每个专用组件和策划想象的不一致。
但是某社将每个环节都抽象为一个个可调整的组件。例如：
- 游戏中的所有敌人都抽象为通用的组件。敌人总要移动、总要攻击、总要远离玩家、朝向玩家、分阶段等等。
- 敌人逻辑可以通过工具快速组装
- 动作速度和攻击范围等等也可快速调整
- 连模型和特效等的一些基础项目都可以快速调整。（大小、纹理复杂度、捏脸的感觉）
- 音效也是，DT（随着物体出现时间来延长单独声音的播放时间）等都可以直接调整。
这种做法的好处除了减少拉锯时间外，策划也不需要花费时间撰写整体策划案。
只需要把内容都拆成一个个通用积木，并写要什么积木后，发给相应的岗位即可。
因此，团队中的成员几乎全做工具与组件，不参与游戏实际运行逻辑管理。
这套开发模式的难点在于对团队中的策划要求相当高。
除了要了解全部开发流程，和抽象思维拆分组件外，还要敏感地得知如何组装会更好、如何利用现有的组件来组合出新颖的内容。
并且，作为制作人和导演需要有高超的抽象能力，在开始制作的时候就立马能够敲定接下来有什么、没有什么。
但核心问题在于其他职位没有创作空间了，这和我的创作理念有很大差别。
并且这种开发模式的另一个缺点在于难以做出超越这个框架的东西。
提出新需求的时候，通常都会被要求尝试能不能在现有积木中组合出来，久而久之就懒得提新需求了。
另一个就是难以做一体式设计。
例如时之笛和王国之心3里面将场景、敌人、演出、交互完全结合在一起的boss战，这种开发流程是没法做到的。
例如时之笛里面，有个boss会从四周的镜子中出来攻击玩家、又跑进另一个镜子。
例如策划突然说，这条列车突然组合一起变成一条龙来攻击玩家等等。
这些需要高耦合度的设计就难以用积木去组装出来。
不过我觉得也可以取巧，就是小怪精英怪用魂那种拼积木，boss就是传统模式……
但这样就会做两套实现机制了。
如果boss战也出现小怪的话，就得背后运行着两套框架才行。
一套是积木框架，一套是一体式框架。
这就会拖慢运行性能，还可能出现互相影响时不耦合等问题。
嗯……无论如何，这套开发模式都有许多优点可以学习。
分享给大家。
下面这段内容不知道能不能发出来，可能有关企业机密，专业性可能也比较强。
————————
某社确实很厉害，近些年凭借着高超的项目管理能力保证每年都有高质量大作出现。
年中曾有幸和他们的游戏设计师得知了他们的制作管理方式。
算是在底层上改造了许多制作管理方式和实现流程。
最主要的，是减少了策划、程序、美术、动作之间的拉锯沟通。
全部调整和组装都落实到策划身上，所以他们效率相当高。
我工作了十几年的传统开发模式，通常是由游戏设计师撰写一套整体策划案。
并分发给程序、美术、动作和音效，让他们制作相应的部分。
由于专业性比较强，最后还需再由程序来进行代码逻辑上的组装。
这样做的坏处是，当策划最终检查和调整时，发现进行最终组装的逻辑出错。
或每个专用组件和策划想象的不一致。
但是某社将每个环节都抽象为一个个可调整的组件。例如：
- 游戏中的所有敌人都抽象为通用的组件。敌人总要移动、总要攻击、总要远离玩家、朝向玩家、分阶段等等。
- 敌人逻辑可以通过工具快速组装
- 动作速度和攻击范围等等也可快速调整
- 连模型和特效等的一些基础项目都可以快速调整。（大小、纹理复杂度、捏脸的感觉）
- 音效也是，DT（随着物体出现时间来延长单独声音的播放时间）等都可以直接调整。
这种做法的好处除了减少拉锯时间外，策划也不需要花费时间撰写整体策划案。
只需要把内容都拆成一个个通用积木，并写要什么积木后，发给相应的岗位即可。
因此，团队中的成员几乎全做工具与组件，不参与游戏实际运行逻辑管理。
这套开发模式的难点在于对团队中的策划要求相当高。
除了要了解全部开发流程，和抽象思维拆分组件外，还要敏感地得知如何组装会更好、如何利用现有的组件来组合出新颖的内容。
并且，作为制作人和导演需要有高超的抽象能力，在开始制作的时候就立马能够敲定接下来有什么、没有什么。
但核心问题在于其他职位没有创作空间了，这和我的创作理念有很大差别。
并且这种开发模式的另一个缺点在于难以做出超越这个框架的东西。
提出新需求的时候，通常都会被要求尝试能不能在现有积木中组合出来，久而久之就懒得提新需求了。
另一个就是难以做一体式设计。
例如时之笛和王国之心3里面将场景、敌人、演出、交互完全结合在一起的boss战，这种开发流程是没法做到的。
例如时之笛里面，有个boss会从四周的镜子中出来攻击玩家、又跑进另一个镜子。
例如策划突然说，这条列车突然组合一起变成一条龙来攻击玩家等等。
这些需要高耦合度的设计就难以用积木去组装出来。
不过我觉得也可以取巧，就是小怪精英怪用魂那种拼积木，boss就是传统模式……
但这样就会做两套实现机制了。
如果boss战也出现小怪的话，就得背后运行着两套框架才行。
一套是积木框架，一套是一体式框架。
这就会拖慢运行性能，还可能出现互相影响时不耦合等问题。
嗯……无论如何，这套开发模式都有许多优点可以学习。
分享给大家。