实现：
首先分析功能实现上的分工吧。我们要按防作弊来做，所以服务器是要进行验证是否能建造的判断。
就规则来说，承重规则是建立在连接规则之上的，其他几个都是相互独立的。
所以有没有机会和服务器分工呢？比如把规则进行分配完成。其实就最后完成来说吧，不建议分配完成，主要是两个人沟通顺畅思路一样还好，差一点都会在之后的功能叠加上被放大。我们项目的整个流程和数据存储都是前端确定，因为前端表现更知道需要什么吧。我们的打算就是前端先把整个功能写出来，后端前期只做存储，之后再功能完整后再进行代码移植。其实更多还是策划的需求只能这样。前端要实时判断是否可以建造，所以所有的规则都得实现判定。
通信字段：
一个int存储旋转转等级 和 建筑单位的下标（建筑单位下标确定了建筑材料在根节点下的建筑单位位置，旋转等级确定了在建筑单位里的位置。至于家具，制作台这些就只能把这个字段拆开成好几个含义。其实一个int对于家具他们来说，是不够的，会体现在建筑单位内的精度上，我们现在最大会差0.18个精度。这个精度大小受场景里建筑单位个数影响）。这样用的原因是因为一个场景里的，会有很多建筑材料。
我们来极限算一算。假如按规划来说 40*40*10 建筑单位就有 16000个，如果每个面都被填满，那这个就容纳了： A(四面和上下面占用) = (40*40*11) + (40*41*10) + (41*40*10) 个建筑材料；B(中心占用) = 40 * 40 * 40；C(装饰物，就先不加了) = 0；D(字节数) = 4。那仅仅就空间信息存储来说他需要的内存是：D*(A+B+C) = 119,200 byte。这里还没有加入 血量，等级还有唯一标识符等级，这些字段都是直接增加D的值。这个也是我们目前建筑系统的一个难点，所以这也是我这样压缩所有位置信息到一个int的原因。