unity coc 战斗回放总结

直奔主题,战斗回放的两种方式:
1.记录每一帧的状态,包括所有的对象的位置,动作等。优点是通用,易于实现。缺点是不易扩展,如果你增加某种状态,就要在回放中增加对应的实现代码。而且文件很大,假设你记录2分钟,120s,那么就是6000帧以上,每一帧假设100个对象需要记录,那么这个数值压缩后基本在M级别以上,你打一场战斗要上M的数据量,对于移动端流量是不可接受的。
2.记录起始状态和玩家全部操作。优点是存储的数据量很小,war3就是这么做的,一场20分钟比赛,replay还不到1M。缺点是对编码限制比较多,特别是对Unity这种根据cpu调整帧率的引擎。后面细说。还有一个缺点就是不能够跳到某一帧播放,因为它必须经过计算才能得出那一个时刻的结果。


那么如果我们要开发一款用Unity引擎的coc游戏的战斗回放,这虽然是作死,我一直以为不会有人这么做。但我还是太年轻,Unity5的demo里面,展示了一个英国公司开发的coc游戏,我下载过来后,发现它是有战斗回放的,而且完美还原,没有丝毫的差别。我迫不及待的破解了它的代码,用了三天时间看了他replay的相关代码。在这里和大家分享下它的做法:
1.首先所有战斗逻辑都必须在FixedUpdate中实现。但是这样会带来很多问题,我们都知道Update里面移动物体,利用dealtTime会得到平滑的移动,但是FixedUpdate做不到,因为它可能一帧调用多次,甚至压根不调用,解决方案是数据逻辑放在FixedUpdate中,而移动更新逻辑放在Update中,详细如下:不能使用unity自带的寻路系统,因为那是基于Update的,建议使用A*寻路,FixedUpdate负责计算路径,Update负责更新位置。但注意,所有战斗逻辑相关的位置必须取得FixedUpdate中的位置,而不能获取GameObject的position,因为不同帧率GameObject位置不同,但FixedUpdate中的计算结果一定是一样的。


2.这一点我不是很确定,但它是这么做的。FixedUpdate之间的顺序是否得到保障,就是说假设你有A B,两个FixedUpdate是否永远是A先B后呢?我也不知道,但有一种方法可以保障,就是你自己调用A.F

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览

应支付9.90元
点击重新获取
扫码支付

支付成功即可阅读