Unity3D 之脚本架构,优雅地管理你的代码

时间:2022-08-01 16:19:05

本文参考雨松MOMO大神的帖子:

图片全部来自他的帖子(请允许我偷懒下)

------------------------------------------------------------------------

写代码,我相信大家都会,但我看过不少网上的源代码,发现很多人代码写得很随意,

想到什么写什么,没有个固定的框架,代码乱,高耦合,不仅看起来不舒服,以后要维护也非常困难,

而且还容易出现一直莫名其妙的BUG。

呐,本人有点小洁癖,有点强迫症,虽然我还只是个菜鸟,但我却非常在意代码的写法,非常讲究

结构,今天我就把我的心得以及雨松MOMO的帖子讲讲要怎么写:

如下图所示,任何平台下的任何游戏核心都是由:数据、逻辑、渲染三大部分组成。

Unity3D 之脚本架构,优雅地管理你的代码

如下图所示,Unity3D这套游戏引擎在游戏开发中的权重如图中所示。其中包含100%的渲染部分 +50%左右的逻辑部分。(因为Unity3D封装了很多与逻辑相关的API供开发者使用)

Unity3D 之脚本架构,优雅地管理你的代码

下面我们回到Unity3D脚本架构的编写上,我们知道Unity3D在是可以创建游戏场景的,在每个游戏场景中又可以创建游戏对象,把每个场景的游戏对象融合在一起就是一款3D游戏。游戏场景之间属于同等级的关系,为了让游戏场景之前交互我们需要有一个凌驾所有场景之上的脚本,我称之为“全局脚本”。如下图所示,所有场景都能与这个唯一的全局脚本进行交互。当场景切换时可将临时逻辑数据写入全局脚本中,切换完毕后再去全局脚本中取之前保存的数据,从而实现交互。(当然还有别的办法也能实现这个效果,但是我觉得这样做会更好一些,数据会更安全一些)

例如:游戏战斗时你获得一定数量的金币,当你返回菜单界面时,你仍然能看见UI界面显示你的金币数量,这就是全局交互。

又或者,大部分游戏Loding时都只有一个Loading场景,A场景转到B时调用这个场景,B转到C也是调用这个Loading场景,

那么Loading场景要怎么知道接下来读取哪个场景?当然是通过你将全部场景的名字存到全局变量,然后读取的时候指定了。

Unity3D 之脚本架构,优雅地管理你的代码

接着我们就进入场景中,游戏场景是由若干游戏对象组成,下面我好好说一说游戏对象。游戏对象是需要绑定游戏脚本才能完成它的生命周期。那么脚本的使命就会尤其的重要。因为游戏对象比较多那么脚本必然会出现交互的情况,如下图所示,很多初期Unity3D的项目中的脚本会编写成这个样子。错综复杂相互交互,这样编写的脚本有可能你的游戏能做出来,可是你在维护的时候团队开发的时候你会发现你的脚本非常的混乱,别的同事想改都不知道怎么改。(显然这样的作法时完全错误的)

Unity3D 之脚本架构,优雅地管理你的代码

游戏中尽量避免这种高耦合的方法,比如由于某些变动,上面图片的脚本4需要修改或者删除,那么也必须更改脚本1,2,3,5与其的交互,不然会出错。

这种高耦合的方法显然非常累,而且还容易出错,比如你忘了更改脚本3与脚本4的交互,那么就出错。

我们想想为什么脚本之间要交互,原因很简单。是因为脚本中需要使用/调用另一条脚本或者另一条脚本对应的游戏对象某一项数据/方法,为了解决这个问题而导致最终的脚本非常混乱。为了避免这个问题,我在开发中会这么做,如下图所示,脚本之间切记不要做直接的相互交互,脚本之间只做间接的交互。每一个游戏场景都有一个凌驾所有游戏对象之上的单例脚本,在这条脚本中保存场景中所有脚本的公共数据。包括该场景的整体逻辑更新都是在这条单例脚本中完成。每条脚本都只与这个单例脚本做交互,和别的脚本一概不交互。(间接交互)

Unity3D 之脚本架构,优雅地管理你的代码

或者使用消息通知中心来实现解耦也可以:

Unity3D 之脚本架构,优雅地管理你的代码

(需要注意的是,Unity自带的消息中心很烂,效率不高,也没有订阅功能,需要自己扩展)

编写脚本时请注意,脚本只干属于自己最重要的事情,就跟代码中的函数一样,只干最重要的事情。切记和该条脚本无关的事情不要去管,不要在脚本中做过多的相互连带工作,让所有连带工作的话都放在全局单例脚本中来做。