浅谈游戏客户端框架设计原则

一、思考

“快速开发出能够稳定运行的游戏” 是游戏开发的终极目标。“框架”也正是为此而生。
“框架”，顾名思义，就是 “约束” 和 “支撑”。
“约束” 是 “支撑” 的基础，没有约束，就不能标准化，没有标准就会杂乱无章，杂乱无章就会产生矛盾和漏洞，就不能快速生产迭代。
如同盖房一样，东一砖头西一瓦，十层不倒百层必倒。

“需求规整可靠” 是策划们应该努力的方向。而程序要做的则是 “拥抱变化”。
如此这样，整体开发趋势才是收敛的、相向而行的。

-------------------------------NRatel--------------------------------------

一套框架的形成必然要经过长期的梳理和重构，但是要尽量避免无谓的、频繁的重构。
一般而言，导致重构的最大原因就是看不到需求全貌。
应该承认，项目前期就考虑到所有可能几乎是不可能的。大多数项目也都是边做边看边调整。
及时发现问题并调整是对的，但这不意味着完全放弃整体规划和设计。
如果程序只能看到局部，盲人摸象，必然要导致返工重构，浪费人力物力。 
个人觉得，策划应该阶段性地对需求进行完整建模，尤其数值策划要进行完整数学建模。这能有效减少不必要重构的发生。
----------------------------------------------------
重构应该容易。而当项目复杂度上来之后，弱类型语言的弊端就开始显现了。如 lua，只能靠文本搜索替换，遇到命名重复/有包含关系的情况，重构很容易出错，不敢大改，就很容易放弃。

-------------------------------NRatel--------------------------------------

项目框架应该能够支撑项目需要的所有上层业务。
在遇到不支持的需求时，要及时对框架进行重构，而不是想办法绕过框架私搭乱建。绕过很容易让框架变得混乱、难以维护。
需要注意的是，做到 “能够支撑项目中的所有上层业务” 并不是一件简单的事。
因为，通常针对性地解决一个问题很容易，而一个方案同时支持解决多个问题，难度就成几何倍数增长了。
（比如，针对性地造一把锁的钥匙很容易，想造一把能开N把锁的钥匙就很难）
所以，一上来就直接从具体问题着手，给出一堆耦合的具体方案是不好的。
应该尝试分析共性，先求一类抽象问题的解，再派生出一些常见的具体方案。

-------------------------------NRatel--------------------------------------

项目框架应该恰好支持项目需要的所有上层业务。
没有“银弹”，不要过度设计，项目的轻重度，决定了框架的轻重度。
过度设计不但浪费工作量，更会增加系统复杂度，增加上层使用者的学习成本，降低开发效率。
应该主张简单，如无必要勿增实体（奥卡姆剃刀原理）。尤其是底层逻辑，如果多了多余的可能性，依赖的它的上层逻辑总是要考虑它。
因需求不明，让造一把万能钥匙的需求，应当严词拒绝。

显而易见，“设想未来”和“保持简单” 是有冲突的。还是要结合实际情况。

-------------------------------NRatel--------------------------------------

框架可以是分层的。
因为不同的项目，需求总是千奇百怪的。无法造出一个宇宙无敌圆满大框架。
所以，为了让框架在不同项目间快速复用，需要从项目框架中再抽象出一套更抽象的通用解决方案。
可以通过依赖注入的方式，将通用框架配置成实际项目需要的框架。

-------------------------------NRatel--------------------------------------

框架可能要在某些地方对易读性/易用性和性能做权衡和取舍。

框架的学习成本要尽量低，要毫无保留地对设计思路进行注释、讲解。

应该积极对待使用者的建议。这是优化框架最宝贵的资源。

二、游戏客户端框架可能要解决的问题

1、选择一种架构模式，mvc或mvvm或其他，能够让界面与数据同步。
2、选择一种热更新方案。
3、提供一系列常见需求的解决方案。  如，
        UI系统、资源管理、版本管理、本地化、屏幕适配、与原生系统的交互封装、AI(状态机/行为树)、寻路、UI特效、图文混排、条件达成、时间管理、功能和活动管理（功能解锁/跳转，活动开关）、红点提示、新手引导等等。
        其中，部分由项目具体需求决定。
4、提供一些常见底层类库。如，
        通用单例、计时器、游戏物体/类对象池、事件管理器、网络接口封装、过程管理、日志管理等等。
5、集成第三方或自己实现一些提升工作效率的工具。如，
       资源检测分析、策划表处理、资源批量处理、持续集成等等。