※ 引述《cjcat2266 (CJ Cat)》之铭言：
: timeslicing算是我进入业界第一个学到的技巧之一吧
: 非常实用且几乎每天都会摸到
: 简单来说就是有必须反复执行的轻量平行逻辑
: 不用每个frame全部执行，可以分多个frame执行，分担负担
: 像是100个NPC不用每个frame都全部执行，每frame处理20个可省下80%决策运算时间
: 反映NPC决策的动画层，因为与决策层中间透过接口沟通
: 这种几个frame决策延迟并不会被玩家注意到
: (除非你在做无法容忍延迟的格斗游戏，那你是要100个NPC干嘛啦XD)
: 时域切割 同步/异步 的 资料读取输入/储存输出，又有四种排列组合
: 本文有精美动画供参考:)
: 那就废话不多说了(好像已经讲了一堆)
: 连结在此 http://wp.me/p4mzke-14V
: 动画生成原始码在此 https://github.com/TheAllenChou/timeslicing
: 这是游戏程式系列文的一部分 http://allenchou.net/game-programming-series/
: 请多指教 :)
不要每个frame都执行，除了cjcat大分享的timeslicing之外
还有使用timer，设定interval时间每隔一段时间处理的方法
这边想分享一下曾经遇到"失败"的经验
首先我们先回到没有改的状况
版本1：
每个frame要做的事情都写在Update里
版本2：
使用timer
在begin play的时候设定timer，interval可能是5秒，每次作原来Update的事
结果悲剧发生了，如果这个entity被种了10个在同一个场景可能会发生什么事？
10个同时睡觉，同时起床，于是每5秒游戏就会顿一下
(前提是这Update很花时间，不过如果这个Update很快，你根本不会把版本1改掉)
从profiler分析，版本2的average fps会比1好很多，
可是max fps还是跟版本1一样，游戏体验却比1还要遭。
所以这篇文章除了要说明，
使用timer要小心不要同时触发之外。
profiling时也要拥有全面以及正确的观念，average/max 都要同时注意
在寻找改善的标物建议多花一点时间，确定找到的是目前较重瓶颈
时间要花在刀口上~~
以上就是曾遇到的失败经验~~没踩过雷的人可以趁机知道一下~

你这是把同样把全部要做的事情都塞进update里面吧这样有没有延迟5秒执行没有差别阿

的确只是单纯的把呼叫次数降低而已

在开头的时候把timer的第一次周期随机分散

我自己是不太喜欢用timer，因为有不确定因素因为用frame数来决定是否update的话，控制比较精确一开始我会推荐最简单的 (object index + frame#) % n来决定是否update，不够的话再看有没有其他地方可以切也可以试试看lazy update，有需要的时候才触发update下个frame再给结果，太多query的话就排队timesliceUncharted 4的就是用这种request-based lazy update来算出NPC的最佳移动目的地，NPC有reqeust才开始update要算的东西太多，就timeslice，过几个frame再给结果反正是决定层，慢个0.1秒才反映在动画层也看不出来

我的方法跟cj是一样的用更新率来切step或者说就是最简单的一招吧 XD这样做是不用另开执行绪效能不足再开就好

如果平台支援fiber的话，可以在低overhead的状况达到多执行绪的效果，一开始开跟CPU core数量一样的执行绪然后用core affinity绑定CPU core，再用job system分配fiber给执行绪处理范例可以看 http://bit.ly/1eX5mb1

push~

赞

时域切割正夯