那么其实有方法让其变得如同普通游戏一样流畅
首先需要了解游戏的区块资源分配原理：
最小资源：BlockUpdatePack - 单方块更新
普通资源：BlocksUpdatePack - 多方块（＜64）更新
超大资源：ChunkUpdatePack - 区块（≥64）更新
这个原理用于单人；服务器都使用。
单人不明显，但是试想一下多人中，如果一个区块被更新，那么要同时发送给n个玩家
此时不仅是上传延迟，也包括对主机CPU多重压力，这是卡顿的主要原因。
要避免资源卡顿，需要优化一个区块的指令方块更新少于64，如下
只要数量达到63，必须重新更换一个区块。
除了图中摆法外，更实用的是线型，有效的向邻区块延伸。
多人加载中除了资源的共享，也需要加载使用指令的区块
而服务器区块负荷量近似为：
=区块资源*区块刷新率*人数
资源我们知道如何减少，人数是个不可控的量，刷新率也有方法降低：（针对被加载的区块）
高频率：出生点区块 - 玩家出生点 16*16 Chunk
中频率：出生点预加载区块 - 出生点 64*64 Chunk
低频率：出生点忽略加载区块 - 玩家出生点 64*64 Chunk外
为了降低刷新率，节省资源，至少要把模块放在玩家出生点区块（最好也是玩家活动范围）的1024格外
但是需要注意使用区块加载器让模块一直更新
在所有客观因素外的一个主观因素就是逻辑冗繁，
例如一个并联枚举其实可以构建一个如图的空通道来共用输出
还有很多逻辑优化方式，需要自己留心并践行
讲了这么多，总结就三点：
将一个区块的指令方块控制在64个以下
将模块移到出生点区块1024格外
尽可能简化指令
这样基本的服务器都能带动4096（不含区块加载资源）
单人能带动几w甚至10w+指令方块
