游戏开发中关于系统的一些思考

系统负责的内容

1. 界面开发【显式】
2. 模块间数据的传播，或者是模块间调用的方式【隐式】
3. 各解决方案的接入（总线）【隐式】
4. 版本发布【隐式】
5. 更新策略及方案【隐式】

系统的现状

1. 需求迭代速度快

   • 已有的多个模块需要同时更改部分功能
   • 不确定性高，可能后期还会更改

2. 模块并行开发

   • 常在堆功能阶段，全新模块和旧块迭代并行开发

3. 复杂度高

   • 涉及所有模块间的相互调用
   • 涉及各种解决方案的接入

4. 人员变动大

   • 系统常误被认为应届就可以满足开发的现状

5. 经验相差悬殊

   • 门槛低，但是做好对经验要求高

6. 过多人插手

   • 实现壁垒低，懂一点代码就能说上两句

为了满足需求并且减少上述现状所带来的风险，我们可以得到下面的矩阵

问题\方案	系统正交性	降低学习成本	避险措施	合作模式	审核机制	AB角	人员培训	福利	晋升机制	话语权
【技术】需求迭代速度快		X		X	X		X
【技术】模块并行开发	X		X
【技术】复杂度高	X	X	X	X	X		X
【管理】人员变动大	X	X	X	X		X		X	X
【管理】经验相差悬殊	X	X	X	X			X
【管理】过多人插手										X

系统正交性

• 分层架构
• AOP编程，底层无模块概念。达到设计上满足但不限于需求的方式。
• 模块跳转统一使用Command的方式
• 模块传参的参数统一使用BsonDocument
• 跨模块调用基于消息机制的传播

降低学习成本

• 降低自定义API的数量
• 使用更符合Unity的规范，如生命周期、操作习惯、命名规范等
• 提供通用的功能性组件

避险措施

• 消息中心可以过滤（屏蔽）、重定向、转发不同渠道。因为模块间的调用都是基于消息模式的设计，所以在消息中心中，让我们的可操作性更高。

合作模式

• 程序与策划人员保持长期稳定的合作方式
• 降低交叉沟通的人次
• 避免出现新人+新人的合作模式，保证老人+新人的合作底线

审核机制

• 有需求分析会议、确定优先级、及执行时的再次审核，减少不合理需求的出现几率

AB角

• 每个岗位都有备选人员

人员培训

• 避免木桶效应，技能有所提升，以达到提高效率的目的

福利

• 让付出与回报成正比，多劳多得

晋升机制

• 明确职业规划，让专业的人更专业

话语权

• 提高对应负责人员话语权，是保证方案能够顺利实施最有效的手段

---

更多文章详见：www.aihailan.com/blog