游戏架构猜想（二）【核心篇】

最新推荐文章于 2020-02-13 04:37:55 发布

郭佳

最新推荐文章于 2020-02-13 04:37:55 发布

阅读量914

点赞数

本文链接：https://blog.csdn.net/guojia167/article/details/46469733

版权

本来打算写一系列《游戏架构》方面的内容，只可惜自己既非架构师，也不是一个经验丰富的开发者。以目前只参与过个别小项目的经验来说，题目有些大，所以，只好转写《游戏架构猜想》。一方面为了解决游戏开发中的一些疑惑，解决开发过程中代码不断混乱的问题。另一方面也尽量查看一些宏观的架构方面的思想，用于指导自己的开发。还有，在经过以后的验证前，目前始终只是当做猜想。最重要的，可能也只是为了解开心中的一些疑惑，或者只是理清自己某些开发思路。

==============================================================================

目前的疑惑：

模块之间是如何通信的？

是不是需要严格的上下层？（MonsterManager->Monster1,Monster2,...）

同层之间通常是不是直接相互访问。（Manager1->Manager2 , Monster1->Monster2）

大型游戏之间的交互，是不是主要是消息驱动？

游戏架构（二）核心篇：解耦

组合优于继承。

不要为了架构而架构。

架构的目的是为了使事情变得简单而不是相反。

为什么会出现架构的概念？

不管是设计模式，还是架构，它们的出现是伴随着软件或者游戏开发的不断发展和总结而来的。简单的说，开始是没有架构的概念的。在无数前辈开发者的开发过程中，他们遇到了各种问题；比如代码变得越来越混乱，比如类与类之间的关系越来越复杂。于是，我们的先驱者们开始思考，思考，思考。。。。。。他们通过不断的思考，总结，或者也可以称为重构的过程；使得代码变得更加规范，开发变得更加清晰。

于是，他们将这些总结记录下来，并加以概括。形成了设计模式，形成了架构。

也就是说，架构的出现，是因为问题的出现而出现的。前辈们经过自己的总结，得出：好，这个架构可以解决这个问题；那个架构可以避免出现那个错误。

于是，我们开始在项目中，照着这些经验架构，来指导项目的进行。

......

只不过，当我们想要学习架构的时候；有了一些微妙的变化。之前是遇到了问题，不断优化，得出的架构。一出现问题，二分析总结，三出现架构。而现在我们要做的是，架构先于问题！？（试问，这种情况下怎能学好）

为什么需要架构？

考虑如果我们要给问题一个答案，答案会是什么：我们开发一款游戏时，为什么需要架构？

首先，不是因为早先的天才开发者们已经总结了架构，我们就要去使用。而是，

答案或许不是你想要的：为了使游戏开发变得简单。

为什么？

当我们启动一个新的游戏项目时，我们从何处入手？

所有准备工作做好，做好游戏定位，制定好项目计划，每一个开发者拿到自己的开发任务，开始开发。开发人员完成自己的开发任务后，然后组合到一起，运行。游戏正常，皆大欢喜。

后来，由于游戏的某个功能，用户使用起来很不人性化，所以需要将这部分的功能进行剪切。于是痛苦的事情开始出现（需求开始变化），开发者打开自己实现功能的相应类，将不需要的代码注释掉，并自信的加入相应的说明：“因为功能需求，将该部分功能注释”。同时，由于游戏市场表现不错，接下来要加入新的功能来吸引更多的用户。比如加入竞技场功能、远征功能、好友系统、社区系统、玩家之间交易系统；加入语音功能、视频功能、互动功能。由于各类功能的加入，之前的项目组成员已经远远不足，于是更多的成员加入了。渐渐地，一些变化开始发生。由于系统的不断庞大，不是每个人都能了解代码是如何运行的了，而且各类功能之间的逻辑联系开始密切起来。后来，在某些时候，你开始尝试重构部分功能，但是牵涉的代码太多了，你担心修改之后会影响到其他功能，或者影响到其他成员的调用，于是你放弃了。再后来，更多的人这么做了，代码越来越复杂，最终没有一个人能够理清游戏到底是怎么运行的了。。。很多时候，可能不会出现上面的情况。但是，不可避免的会出现，游戏功能越来越多，游戏后期开发变的越来越复杂。出现牵一发而动全身的情形。游戏开发也开始变得痛苦和不堪。

历史总是如此相似，其实，前辈开发者中已经遇到过相似的情景。而且也已经给了我们答案。这才是我们需要的原因。

架构要解决的问题？

架构的出现就是为了解决游戏开发变得痛苦和复杂的问题。它可以使得你的开发变得有理可依，会使得你的逻辑变得清晰；使得你的开发可以有条不紊的进行下去，从而使游戏开发变得简单。

一个软件系统一般都会经历分与合两个阶段，游戏同样。“分”表示将一个复杂的或者大的游戏系统划分为相对独立的子系统，子模块。每个模块独立完成自己的相应功能，并尽可能少的与其他模块相互联系。“合”表示将各个子模块合并成最终的游戏，同时，也代表了耦合，一个模块与其他模块发生了联系，我们称为耦合。有这样的一个事实，我们可以尽量减少模块之间的耦合，却无法做到完全消除模块间的耦合。

架构的核心思想

分块、解耦。

分块：模块化，可以依据功能的独立性分成合适的独立模块。它使得你可以只关注该模块的功能，而不用考虑对其他模块的影响。

解耦：将每个模块组合到一起的时候，不可避免的要产生耦合，如何使得两个模块之间的耦合尽可能的小，是解耦的最终目的。

模块化的好处：

模块化的含义，不仅仅是划分出多个模块，而且是每个模块要相对独立。典型的一个例子，计算机。键盘出现问题，我还是可以开机，进行一些操作。硬盘坏了，更换新硬盘。就是这么简单。

耦合的表现：

两个类属于继承关系。
两个类相互引用。
多个类之间的混乱调用。

面对解耦：

首先，耦合是不可能消除的。我们追求的只是“高内聚，低耦合”。只是“低”耦合，而不是“无”耦合。

传统的开发方式中，复用的主要方式是通过继承。而讽刺的是，而造成耦合的主要方式是就是继承。

继承的一个替代方案是组合。

凡事过由不及，所以不要掉入极端。解耦的目的是为了软件模块的独立，但不可以为了解耦而解耦。

除了模块间的耦合，模块内部也会考虑降低耦合度。

常用解耦方法：