项目问题记录（1）

今天在项目中遇到2个问题：
1.当玩家因为机器特别得卡得时候，会出现丢帧得现象。当玩家得射击速度比较慢得时候，影响不是特别大，因为冷却时间足够长。但是当玩家射速足够快得时候，就会出现问题。 所以就引出了一个问题， 那就是需要对卡的机器进行补帧处理。
补帧需求的前提需求： 必须自身已经接管了Unity的Update，用自身的Upate去代替。
这样做的好处有很多：
可以实现所有物体的状态更新顺序的统一， 在我现在的项目中，因为执行顺序不确定的原因，出现了许多莫名其妙的BUG。 比如： 当我的逻辑引用了某一个对象的时候，而这个对象是我从一个底层控件中拿到的，这个时候我其实不用去管这个物体的是否存在的，因为这个是底层控件的事情。 但是因为我们的Update顺序不统一，有可能我的Update比底层控件的Update提前了，那么就会出现引用为空的问题。所以我们需要统一Update。
可以做暂停逻辑。一般的项目可能都会有这类似这样的需求： 比如刀塔传奇中当我们释放大招的时候，在这个时候只有释放大招的这个人的状态是更新，而其他角色的状态就是暂停的。还有比如我们的游戏，当玩家死亡之后的复活，在这个时候应该是只有玩家进行复活动作与特效而 其他的对象的状态更新是暂停的。
可以进行补帧和追帧操作。这种一般需要我们对游戏的帧率做出限制和规定，比如每秒30帧
当玩家的机器卡了的时候，我们需要对整个游戏的状态更新做帧补偿（这个看策划需求)。
如果我们的游戏需要复判，那么我们就肯定需要逻辑帧与图像帧分离，那么肯定需要进行补帧，与追帧。因为我们需要保证逻辑的每一个Update都是每秒30帧。这样服务器才好根据帧数进行复判。
其他的应用，原谅我暂时还想不到。
2.第二个问题是，我们的游戏的主要玩法是关卡。所以关卡的敌人和各种工具脚本的数量比较大。导致我们游戏在进入关卡之后，FPS一直处于比较低的状态，所以比较能容易想到的一个解决办法是，当玩家距离某个物体足够远的时候，关闭该物体的状态更新。但是这个东西解决起来有几个问题：

1. 我们的游戏有许多全局的东西， 比如有某个物体，全局接受某个消息，当达到条件之后触发某个行为或者说执行某个脚本，类似于这样的脚本就不太进行处理。初步的想法是 给我们的物体加向一个标签，当这个标签为全局对象的时候，那么我们就不会去动态的根据距离关闭该物体的状态更新。
2. 需要维护一个全局的Target列表，用于距离和范围检测。
   昨天晚上在睡觉的时候，想到了一个简单的解决方案，我们在编辑模式下，把场景中的需要检测的对象，放入到我们一个管理器中。游戏中动态创建的物体，是有统一的接口的，也是可以在创建的时候加入到我们的管理器中。这样就可以实现对全局对象的管理。