RpgMakerMV源码解析(2)-启动过程

启动过程

今天宏观的讲解一下rpgmaker游戏框架的启动过程.

在main.js中，首先调用插件管理器加载了插件，然后使用场景管理器，加载了启动场景，

 

 

之后转到sceneManager.run方法，sceneManager是一个典型的延时初始化的类，他的init方法要等到第一次使用该类，即在run里面才会进行初始化。之后加载该场景类。

关于场景管理，这边简单说一下，很多引擎都有类似的东西，好处就是可以将资源打散到多个场景中，一次不用全部加载完毕，所以第一次可以更快的进入游戏，然后在逻辑上，将游戏分为多个场景也方便管理，特别是像RPG类型的游戏，简直是天生的容易分成多个场景，然后分成多个场景之后，在游戏开发的计划上，也可以以场景为基准，更加方便。

关于场景管理器的初始化，更深入的初始化部分就留下下次再说

 

在开启了主循环之后，就跳转到scene_boot，这个可以看成是scene类的一个子类，由场景管理器管理。

 

接下来因为场景管理器开启了帧循环，所以直接看场景管理器的update方法

可以看到，一个updateMain方法被夹在了两个计时方法中，这个用处就是为了算出一帧的执行时间，然后其他的一些处理就要依赖于这个执行时间，因为我们的一些逻辑处理都是要写在一个每帧执行的update里的。例如玩家的移动，但是不同配置的电脑1S可以执行的该方法次数不同，即帧数不同，因为要保证在1S真实时间内的移动相同，所以在移动的时候要乘上这个上一帧经过的时间作为参数。

类似这种不锁定单帧时间的，现在已经是大部分渲染框架和游戏引擎的标配了，毕竟这种可以充分发挥每台电脑的配置，配置越好的电脑帧数越高，画面越流畅，但是玩家1S可以移动的距离也是相同的，不会你电脑好一点就移动的快一点。

当然，为了达成这种效果，自然是需要游戏开发者多付出一些努力。

我还看过一些框架是锁帧的，包括以前的flash，甚至说unity的fixupdate都是锁帧的，这种的话就是编程起来方便一些。，因为每帧时间固定，需要考虑的事情也少了。

 

 

接下来我们看updateMain方法

首先是计算出了上一帧所使用的时间。其实这里有一个设计问题，一些关于时间的变量，方法，放在了sceneManager里面，其实应该再分出几个类，专门用来关于时间的计算和处理，肯定不能把帧循环时间处理放在场景管理器里。

 

然后的逻辑有点难看懂，其实就是一个锁定了帧数上下限的处理，上限60下限40。(但是这里的下限是有逻辑问题的。。因为帧数理论上是没有下限的，给你一台很垃圾的电脑跑高画质的游戏，你怎么可能弄一个帧数下限？所以一旦出现帧数实际上到达不了40帧的情况，会出现一些显示和逻辑问题，例如玩家可能实际移动不了应该1S内移动的距离，假设1S只能更新一帧，那么玩家只能移动一帧内能移动的距离，但是如果不加帧数下限的话，玩家会瞬移到应该1S内移动的距离，不会有中间动画，至于哪个处理好仁者见仁智者见智了，其实我是倾向于不设置帧数下限的。关于其他的这里就不多说了，延伸出来比较复杂，而且毕竟现在跑不动像素风rpg游戏的电脑应该很稀有了。)

关于while以上的部分，个人认为可以另外抽取出一个函数，不用写在这里。

然后先获取输入，之后分发循环事件，最重要的就是updateScene这一句了。

因为一个场景里会有很多的子物体，包括人物，地图，甚至说是抽象的UI界面，这些都是包括在一个scene里的，而他们的循环都是来自于scene上层的分发，scene会使用一个递归的查找，把整个循环链从高到底分发下去。

可以看到，最后循环来到了对应scene的update里，接下来具体要怎么循环，就是每个子scene各自的问题了。

 

scene_boot是一个加载的场景，他是没有重写scene的update方法的，那么实际调用到的就是下面这个基类的方法，即循环所有场景内的子物体

这些子物体各自在自己的循环里又会有不同的逻辑。

那么关于启动过程的分析就先到这里。

---

可以从我的github仓库获取我做的详细中文注释版的rpgmakermv源码进行学习，目前还在更新中 
https://github.com/luckyCatMiao/rpgmakermv-library-ChineseAnnotations