早在我没有发现启动场景的时候,我先发现了gameframework的那个预制,我想启动游戏的时候首先遇到的一个问题就是流程,我已经在前文提到过。
StarForce的启动场景中也有gameframwork这个预制只不过是已经经过作者加工组装之后的这点还是很好辨认出来的。builtin部分就是gameframework预制体了
这是流程组件节点Procedure 进入代码看看就知道确实是继承gf的组件类的
很明显这里勾选的是整个游戏启用的所有流程,entrance procedure 顾名思义是启动的第一个流程,这在前文中也提到过了。在前文中我也发现了游戏的在启动之前是要获取场景上的所有组件的。从前文的在ProcedureLaunch流程中组件报空就可得知。而获得所有组件的脚本是GameEntry脚本。
先获取游戏的GF里的标准组件,再获取使用者自定义的组件StarFore就有两个自定义的组件(BuiltinData组件和HPBar组件)
作者这里用partial class 把同属于GameEntry类的各个功能的方法写在了不同的脚本里。作者这种方法可以对代码进行不同功能呢的整理让一个文件里的代码不会太长。整体也挺有条理的。
现在先看那个ProcedureLaunch流程吧首先是继承流程的基类。
流程基类
这里还不是UGF里面内容哦 是游戏逻辑需要用户自己实现的。(作者也写了命名空间可以看出来还是在StarFore内的)
接着再往基类里面走,这次直接使用了GF里面的代码(不是UGF)哦。
在这里发现gf中的流程基类是继承有限状态机类的 并且类型是IProcedureManager流程管理接口。
往基类走可以知道这就是流程类的最终基类了是一个有限状态机泛型类并且有泛型约束
这里的泛型约束的我也不太熟悉在网上看了相关的内容
这很好解释了作者的代码就是一个预防措施(目前我是这么想的,接口是引用类型是合理的)
流程管理接口。
在这里原来using不仅只是用来引用命名空间的啊
拓展C#中using的三种使用方法:https://www.cnblogs.com/mslalan/p/7452021.html
作者在这里使用的是
2.using别名。
using 别名 = 包括详细命名空间信息的具体的类型。
例如:
using aClass = NameSpace1.MyClass;
这种做法有个好处就是当同一个cs引用了两个不同的命名空间,但两个命名空间都包括了一个相同名字的类型的时候。当需要用到这个类型的时候,就每个地方都要用详细命名空间的办法来区分这些相同名字的类型。而用别名的方法会更简洁,用到哪个类就给哪个类做别名声明就可以了。注意:并不是说两个名字重复,给其中一个用了别名,另外一个就不需要用别名了,如果两个都要使用,则两个都需要用using来定义别名的。
进入代码查看
IFsm = 有限状态机接口(接口)
FsmState = 有限状态机状态基类 (抽象类)
IProcedureManager = 流程管理接口(接口)
其实最主要的就是FsmState<T>(泛型类)和GameFramework.Procedure.ProcedureBase类里面的方法比较多
FsmState里有除了上图中的方法还有两个改变状态的方法功能应该是差不多的
在这两个方法中还引用了其他类就是Fsm<T> 从名字来看着就是有限状态机的类了 FsmState<T>是有限状态机状态基类 一个是状态机本身一个是状态机的状态基类。
再进入这个Fsm<T>类中查看
状态机类继承状态机基类,引用接口,状态机接口。
附上最终的图解 有点乱哈哈
上面我只是针对我自己这个流程的梳理 网上烟雨博客做了个全局的梳理我觉得很好如下:
fsm主要是在fsmstate 和 fsmmanager 之前做一个桥梁的作用
总结一下就是在fsm主要是在fsmstate 和流程控制就是状态的切换,fsm更新最新的流程,在每个流程内切换其他流程的时候也和fsm里进行数据交互。用烟雨的话说就是:
由基层的Fsm更新来驱动状态机状态的更新,状态机状态的切换也会传递到底层的Fsm上,即一切状态都被Fsm持有与维护
到这里为止已经把流程这个类梳理了一遍了
图上有很多函数我没有写出来就写了一些重要的。
现在回到最上层看下StarForce的启动流程做了些什么事情。在这里作者的注释已经写得很清楚了。
启动流程的功能就是初始化一些游戏的基本配置,然后在运行的一帧后就切换到splash流程。
starForce的总体流程如下:
想要添加自定义的流程
只要自定义的类继承自procedureBase并实现流程基类里相应的方法就行了。
每个流程就是一个游戏状态,作者也是这个这么设计的。相当于把运行时的游戏逻辑分类了,