原创

《Unity 3D游戏客户端基础框架》系统设计

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://linsh-tech.blog.csdn.net/article/details/76377037

引言

最近到看一个 《贪吃蛇大战开发实例》,其中 贪吃蛇大作战游戏开发实战(3):系统构架设计 提供的系统架构的设计思路我觉得还是值得学习一下的,接下来的内容是我看完视频后的一点笔记。

架构设计原则:

1.系统分层:

根据功能特性,可以大致将整个系统分为:

  • 视图层(游戏输入、战斗 View、业务 UI):视图层也可以遵循 Mvc 的思路来做进一步分层;
  • 业务层(核心玩法、业务模块);
  • 服务层(模块管理、UI 管理、用户管理、资源管理、配置管理、网络管理、支付管理、分享管理);
  • UI 控件;
  • 基础类库(储存管理、调试器、数学库、网络库、单例、Monobehaviour能力)。

上面的分层是根据游戏具体逻辑来划分的,这些层级之间也并非完全独立,存在依赖关系,为了服务于视图层,通常会把一些常用的 UI 试图进行控件化,也就是会多出一 UI控件层,而且整个系统也需要使用到很多基础类库,所以也就有了基础类库层。

2.单向依赖:

只要有两点要求:

  • 不同层级之间的模块是单向依赖的;
  • 仅允许上层模块依赖下层模块。

也就是说,上层模块可以之间访问下层模块的属性,而下层模块不能直接访问上层模块,下层模块的变化通过 消息/事件 通知上层模块,上层模块通过监听这些 消息/事件 来及时获取下层的属性变化。

3.模块解耦:

各个业务层模块之间,不直接访问彼此的代码,这样可以达到编译不依赖,实现静态解耦,那么他们要通过什么方式进行通信呢?

最常用的做法:业务层模块之间通过【事件】与【消息】的方式通讯。

具体实现方式:模块 A 需要调用模块 B 的逻辑时,会广播一条特殊的 消息/事件,而模块 B 的监听此 消息/事件,当收到 消息/事件 时执行指定的逻辑。

这里的 消息事件 都是不依赖于发起者的抽象类型,通常使用一个抽象消息管理类来管理,经常使用字符串常量来表示不同的消息类型。

4.全局事件:

这种方式适用的情景:

  • 有些事件并非从固定模块发出(可能会有多个模块都会发出此类事件);
  • 有些事件模块影响全局逻辑。

可以在多个模块中监听同一个事件,当事件在某个模块发生,则广播一个全局的事件,此时所有监听了此事件的模块都会触发相应的操作。

缺点:使用全局事件会使得代码的阅读性下降,因为当一个事件有多个触发源时,当事件触发时我们无法准确地定位事件是从何处触发的。(也可以通过日志记录来索引事件源头)

5.模块独立:

主要适用于服务层模块的设计,核心思想就是将两个服务模块必须有的公共逻辑抽象出来,放在基础类库中。

6.代码重用:

将可以重复使用的代码,在系统层级上做一些小整合,例如:

  • 业务层公共逻辑 –> 服务层
  • 服务层公共逻辑 –> 基础类库
  • 视图层公共逻辑 –> UI 控件

6.设计模式:

善用一些设计模式,可以让代码更加高效,这里列举一些游戏开发中常用的设计模式及其适用的场合:

设计模式 应用场合
观察者模式 业务层之间通讯、上层与下层通讯、客户端与服务器通讯
命令模式 业务层之间通讯
单例模式 服务层为上层提供功能
MVC 模式 视图层与业务层通讯
工厂模式 视图层实例的创建、核心玩法中角色的创建、特效的创建管理
文章最后发布于: 2017-07-30 13:41:22
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 书香水墨 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览