我们的单机游戏的框架设计

今天做save && load的时候其实大部分时间实在搞一个框架的问题了。感觉做了做，理的差不多了，这里做一个总结吧。

游戏还是传统的总分结构。一个mainmenu，然后上面会有好多进入其他场景的入口。

场景0：（dontdestroyonload）在mainmenu场景之前呢，我做了一个空场景。场景中只有一些dontdestroyonload的东西，因为dontdestroyonload在具体的场景的话切回来会有不断实例化这个坑的，这样子就可以绕过去，其实也可以在具体场景做判断的，或者是在global的的static中初始化。雨松研究院有一篇文章讲的是这个。我用的就是方法一。这个场景呢，我的想法是以后所有dontdestroy的东西都放到这里来。然后他会自动跳转到mainmenu的，等于这个场景是透明的。当然如果在表现上出现和mainmenu明显的为何感觉。那我想把两者UI部分做一样应该是没有问题，视觉上应该没问题的。

场景1：（mainmenu）这个场景有应该有一个startscript，其中start的时候做一些各种manager单例类的init方法。比如在表现上，10个关卡中有9个通关了，最好是这9个和最后一个不一样的UI，这就需要用manager类来进行处理。soundmanager，moviemanager，还有charactermanager这些都是必要的。今天做的save和load其实也是应该在这个场景中的，首先加载场景，这个时候可以加入loading界面，然后加载完场景不要马上场景表现出来（这里其实可以做一个打开雾团的效果，其实就是强制加载场景后等待场景中的ob跑到相应的位置再可以操作）。

场景2：（playgamenode）这个场景就是具体的游戏场景了，结合今天做的事情，需要一定的固定点来进行保存，然后当人物死亡进行load的时候其实是不需要加载场景，而只需要加载人物等位置信息的，这样从存取角度来讲自然会快很多。今天和策划讲了一下，顺便看了一下limbo的checkpoint机制。其实都是确定的点，而且是不可逆的，希望我们策划给力一点，多做一些软设置，不要都是非要给过关后竖起来一块板子这样硬设置。场景中目前我们都是A发消息给B，然后B直接操作这样子，其实是不合理的，还是希望能有一套合理的体制M，作为AB的消息传递体，这样可以做到AB彼此透明。

目前存取方面想到的就是这么多，然后不出意外，我希望我们的框架也就是这样。目前做的工作也就是一个全局脚本+多个场景的事情。我希望这部分可以做好，然后可以把全局脚本写好。以前总以为架构这个事情是有大神来带的，没想到今天自己也开始做了。希望这个能够成功。毕竟是个单机小游戏。