Unity基础框架从0到1 开篇

  接下来我打算跟大家分享一期关于Unity游戏基础框架的一些内容，希望可以给一些游戏开发初学者提供一点思路，同时也希望借这个机会和大家探讨并继续完善这个框架，框架经过实践的检验才能更加健壮。知识的积累一方面在于自身的学习，一方面在于分享和探讨，与君共勉。

  游戏框架系列大致会和大家分享这些上述这些内容，其中还会穿插着一些我在开发过程中自己总结的优化小技巧，届时我也会同步配上视频讲解框架内容，视频链接会放在留言区，欢迎大家一起探讨交流。
  由于我平时是使用Unity开发，所以这个框架特指Unity游戏框架，后面不再提。这个框架旨在帮助游戏开发初级程序员更好的理解游戏开发流程，理清开发的思路，写出更健壮的代码。
  如果我有讲的不对的地方，也欢迎大家留言或者私信指出，感激不尽！

  今天是框架系列第一篇，我们开始吧。

什么是游戏框架

  既然我们要讲游戏框架，那我们首先要知道什么是游戏框架。在我看来，游戏框架首先是一套规范，它规定了什么东西可以做，什么东西不能做，以及做的时候要怎么做。定义这么一套规范有助于写出更安全可靠的代码，不至于让整个项目变得混乱不可控。当然有了规范和限制，自然也会失去一定的自由性。

为什么要有游戏框架这个东西呢？

一、规范项目
  前面解释游戏框架其实已经说到这点了。在团队开发时，这一点尤其重要。每个人都有自己的代码风格。要实现A攻击B导致B扣血，我可能会选择暴露B的血量，直接在A攻击的地方获取到A的攻击力，然后修改B的血量；或者专门为B写一个扣血的方法，把A的攻击传进去；或者写一个扣血的接口，让所有继承这个接口的物体都可以被扣血…当项目里的每个人都随心所欲按照自己的思路来实现各自的模块时，那将是一场灾难。当使用第一个方法时，忽然有一天B血量不对，想去查找时，发现有几百个扣血的地方，如果这个时候还有人使用第二个方法，那还得监控所有调用方法的地方。等到那天，也许就能更深刻理解到规范的重要性了。

二、职责划分
  这里说的职责划分主要分三个部分：

1. 通用技术与业务逻辑分离(框架与细节解耦)​
2. 程序开发的系统分离(各系统解耦)
3. 各部门之间的工作分离¹ (合作解耦)

  第一个是最基础的，我们将游戏开发中的一些通用技术和通用流程抽离出来，这样在开发一款新游戏时可以迅速搭建好基础的部分，然后在这个基础上去写业务逻辑。游戏的一些流程其实是固定的，只是实现的细节上不同，而框架代码就是独立于细节外的那部分。
  第二个则是在编写业务逻辑代码时，我们需要通过合理的划分，让每个程序员各司其职，不要有太多交集。这样的话，能最大化程序员的效率，而不是互相等待。
  第三个是程序与策划、美术、动画等各部门的合作问题。在程序开发过程中，策划的变动应该是最多的，因此需要提供一套工具来让策划配置的修改能直接影响到游戏，这样只要流程通了具体数值就可以任由策划去调整了。美术和动画稍微特殊点，这边和程序的关联性有点强(通常需要程序配合修改)，因此他们资源做好应该上传到另一个目录中，这样上传后也不会影响游戏运行。上传结束告诉程序有修改，等程序这边有时间了可以通过一些方式获取到最新的资源并做替换处理，这样两者也无需等待，且不会妨碍游戏正常测试。

  要知道程序员们最讨厌的就是改需求(且一定避免不了)，之所以要做职责划分，归根结底就是为了适应变化。抽出通用的技术可以用于不同的游戏，哪天策划说，我们不做这个游戏了，换一种类型，可能框架还是适用的，因为它在更上层，和业务逻辑无关。构建数据表导出模块，是为了适应数值变化，游戏在真正上线前，会经历很多次打磨，数值也会经过反复调整，所以肯定得把这部分独立出去，交给专业的策划让他们自行处理。
  个人觉得，一款游戏的水平首先是取决于游戏的美术水平和游戏机制，其次便是框架的稳定和可拓展性了。前者直接决定了游戏看起来和玩起来怎么样。后者则决定了游戏的开发效率和后期的可维护性，一款优秀的游戏肯定得经过无数的打磨，怎么在需求变动时尽可能降低修改的代价就很重要了，如果每次修改程序都得花费大量的时间去重构系统，再加上Debug的时间，相信很快就会被同类型的游戏超越了。当游戏上线后，游戏由最初大量新需求变成了缝缝补补，如果前期架构不太合理，后期缝缝补补也可能变成灾难现场。

我们要怎么实现一套自己的游戏框架

  当然是继续关注啦！ hhhhh开个玩笑，没有任何一个框架是可以适用于所有游戏的，有些框架是在更上层设计的，它只规定了设计思路。而有些框架则是基于细节设计的，比如我现在这个。基于细节的框架里可能还嵌套了更上层的框架。当我们在自己实现一套框架时，首先得弄清楚要的是一套包含了什么功能的框架，然后针对这些功能思考如何抽象，让框架的可拓展性更强。框架的设计和开发也是要基于实践的，所以想自己实现一套框架的童鞋不妨先做一点积累，注重模块式开发，把平时用的很多的模块单独抽出来，并像上面图片中那样做好分类。组合起来差不多就是一套框架了。

  最后有一点我觉得有必要声明，我们不是为了写框架而写框架，而是借助构造框架和学习框架的过程来学习框架里蕴含的设计思想，把这些琢磨透了，到后面可能也就没有所谓的框架了。

我同时也录制了视频放在B站，如有疑问也可以过去配合视频一起食用。

如果大家感兴趣，欢迎关注我的微信公众号，我们一起探讨更多的技术细节！

---

1. Unity3D游戏架构 http://www.luzexi.com/2013/10/29/Unity3D%E6%B8%B8%E6%88%8F%E6%9E%B6%E6%9E%84 ↩︎