在进行项目架构阶段,游戏框架可以解决一部分问题。剩下的架构问题还需要根据不同的项目解决。总之游戏框架是游戏架构的一部分。 ## 关于锤子和钉子: 最近又拿起了《代码大全》和《暗时间》，想起来《暗时间》的作者维护了一个个人博客,就去逛一逛。 这几天一直琢磨一句话:手里拿着锤子看什么都像钉子。于是翻到了博客[《锤子和钉子》](http://mindhacks.cn/2009/01/16/hammers-and-nails/)。我的这个行为很好的阐述了什么叫:手里拿着锤子看什么都想钉子- -。 看完之后深度自省了一下- - 文章很有趣,推荐大家读下。 对于框架,用锤子和钉子来比喻不太恰当,框架就像一把剑,而项目就是锤子。 框架需要经过项目的千锤百炼,才会越来越锋利(当然我的意思不是为了写框架而写框架,框架是副产品,真正锋利的是自己)。 对于这句话:手里拿着锤子看什么都像钉子。我的观点是:如果以前没使用过这把锤子,当你使用这把锤子的时候,就会给你带来新的视野,新的角度去思考问题。 比如以前自己开发游戏都没有框架这种概念的,写代码都是重新造个小轮子,轮子很不好用,当时视野又小又不知道有其他替代的解决方案,当听到游戏框架这个词的时候才开始去思考关于框架的问题,当开始着手搭建自己的框架时,才会开始注意到以前没注意到的东西。 所以,开始打造自己的框架吧! ### 关于架构: 首先推荐一篇关于架构的好文:[10年感触：架构是什么？——消灭架构！](http://www.manew.com/thread-89749-1-1.html)，文中作者很通俗地解释了什么是架构: > 架构是一个约定，一个规则，一个大家都懂得遵守的共识。那这是什么样的约定、什么样的规则、什么样的共识呢？ > 我以包为例，我经常出差，双肩背包里装了不少东西。笔记本电脑、电源、2个上网卡、鼠标、USB线、一盒大的名片、一盒小的名片、口香糖、Mini-DisplayPort转VGA接口、U盘、几根笔、小螺丝刀、洗漱用品、干净衣服、袜子、香水、老婆给我带的抹脸膏（她嫌我最近累，脸有点黄）、钱包、Token卡、耳机、纸巾、USB线、U盘等。这个包有很多格子，最外面的格子我放常用的，比如笔、纸、一盒小的名片等；中间的格子一般放的是衣服、袜子、洗漱用品、香水等；靠背的那个大格子放了笔记本电脑，和笔记本电脑相近的小格子放的是两个上网卡、Mini-DisplayPort转VGA接口、大盒名片、记事本，和笔记本电脑相近的大格子放的是电源、鼠标、口香糖等。 > 我闭着眼睛都可以将我的东西从包里掏出来，闭着眼睛都可以将东西塞到包里！但是，非常不幸的是，一旦我老婆整理过我的包，那我就很惨了，老是因为找不到东西而变得抓狂！更不幸的，要是我那个不到两岁的“小可爱”翻过，就更不得了了。 > 这个包就是我放所有物品的“架构”，每一个东西放置的位置就是我的“约定、规则、共识”。倘若我老婆也知道我的“架构”、我的“约定、规则、共识”，那么不管她怎么动我的包，我都照样能够轻易的拿东西或者放东西。进一步，如果我的同事也知道我的“架构”，知道我的“约定、规则、共识”，那么他们什么时候动我的包，我也毫无所知！ ## 架构的典型组成部分: 以下分类来自《代码大全》3.5小节的《架构的典型组成部分》,并用我的框架来做了一遍对比。 ### 由框架解决的架构问题: #### 主要的类: 书上写的是:架构应该详细定义所用的主要的类。在我的框架里,提供的主要的的类有QFSM(状态机),QMsgDispatcher(消息分发器)。在未来还会提供ResourceManager,GameManager等,现在框架中有一份实现,但是其实现有些复杂,不易阅读和理解,等有比较容易理解的实现时候会对其写一篇文章,还有一些主要的模块需要客户端自己实现。 #### 资源管理: 包括资源加载/卸载,音频、模型、纹理等,是模块化管理资源还是统一管理资源?,我的框架目前有一份实现,但不够易用,未来会提供易用版本。 #### 国际化/本地化: 很多游戏都会有海外版,国内版,各个国家的版本,如何进行切换/翻译?(我的框架未来会提供)。 #### 输入输出、错误处理: 我的框架未来会提供错误日志。 #### 性能: 1.如何检测?框架应该提供相应的数据。 2.指标如何确定?速度?内存?成本?，游戏开发中还有Draw Call,GC等等(我的框架未来会提供)。 ### 由客户端解决的架构问题: #### 程序组织: 包括文件结构应该反映文件或文件夹之间的关系,要思考以什么方式组织比如:先按照模块分文件结构再按照MVC或者先按照MVC分,然后再按照每个模块来区分，再推荐一篇好文:[Unity3D手游开发实践《腾讯桌球》客户端开发经验总结](http://www.gameres.com/654759.html)()(文章略长),文章的第一小节就有讲到关于文件组织。 #### 数据设计: 书中指的是设计数据库表。在游戏框架中是指提供给客户端使用的数据结构定义,包括何种结构定义玩家的数据信息,策划表结构的定义等等。好的数据结构定义 + 烂的代码质量 \>\> 坏的数据结构定义 + 好的代码质量。 #### 业务规则: 属于游戏逻辑范畴,需客户端实现。 #### 用户界面设计: 用户界面组件之间如何通信,如何管理?用户界面和业务规则还有数据之间如何通信?通信方面已提供消息分发器(QMsgDispatcher)。 #### 安全性: 资源如何加密,如何防破解,防反编译,安全数据检查,服务器验证等等。 #### 可伸缩性: 可伸缩性是指满足未来需求的能力，包括程序的可扩展性,用户量增长时系统的策略等等。 #### 互用性: 如果预计这个系统会与其他软件或硬件共享数据或资源,架构应该描述如何完成这一任务。 #### 容错性: 举个例子:当界面跳转时,系统不可以接受输入(我的框架不提供)。 #### 关于买还是造的决策: Unity可以有很多可以使用的插件、C#库可以使用,很多问题迎刃而解,(我的框架不会包含任何插件,项目不同需要的插件也不同)。 ## 核对表摘自《代码大全》: 1. 程序的整体组织结构是否清晰?是否包含一个良好的架构全局观(及其理由)? 2. 是否明确定义了主要的构造块(包括每个构造块的职责范围及其他构造块接口)? 3. 是否明显涵盖了"需求"中列出的所有功能(每个功能对应的架构块不太多也不太少)? 4. 是否描述并论证了那些最关键的类? 5. 是否描述并论证了数据设计? 6. 书否详细定义了数据库的组织结构和内容? 7. 是否支出了所用关键的业务规则,并描述其对系统的影响? 8. 是否描述了用户界面设计的策略? 9. 是否将用户界面模块化,使界面的变更不会影响程序其余部分? 10. 是否描述并论证了处理I/O的策略? 11. 是否估算了稀缺资源(如线程、数据库连接、句柄、网络带宽等)的使用量,是否描述并论证了资源管理的策略? 12. 是否描述了架构的安全需求? 13. 架构是否为每个类、每个子系统、或每个功能域(functionality area)提供空间与实践预算? 14. 架构是否描述了如何达到可伸缩性? 15. 架构是否关注互操作性? 16. 是否描述了国际化/本地化的策略? 17. 是否提供了一套内聚的错误处理策略? 18. 是否规定了容错的办法(如果需要)? 19. 是否正式了系统各个部分的技术可行性? 20. 是否详细描述了过度工程的方法? 21. 是否包含了必要的"买 vs 造"的决策? 22. 架构是否描述了如何加工被复用的代码,使之符合其他架构的目标? 23. 是否将架构设计得能够使用很可能出现的变更? 24. 你,作为一名实现该系统的程序员,是否对这个架构感觉良好? ### 欢迎讨论! 转载请注明地址：凉鞋的笔记：[liangxiegame.com](http://liangxiegame.com) ## 更多内容 * QFramework 地址：[https://github.com/liangxiegame/QFramework](https://github.com/liangxiegame/QFramework) * QQ 交流群：[623597263](http://shang.qq.com/wpa/qunwpa?idkey=706b8eef0fff3fe4be9ce27c8702ad7d8cc1bceabe3b7c0430ec9559b3a9ce66) * **Unity 进阶小班**： * 主要训练内容： * 框架搭建训练（第一年） * 跟着案例学 Shader（第一年） * 副业的孵化（第二年、第三年） * 权益、授课形式等具体详情请查看[《小班产品手册》](https://liangxiegame.com/master/intro)：https://liangxiegame.com/master/intro * 关注公众号：liangxiegame 获取第一时间更新通知及更多的免费内容。