实现:
首先分析功能实现上的分工吧。我们要按防作弊来做,所以服务器是要进行验证是否能建造的判断。
就规则来说,承重规则是建立在连接规则之上的,其他几个都是相互独立的。
所以有没有机会和服务器分工呢?比如把规则进行分配完成。其实就最后完成来说吧,不建议分配完成,主要是两个人沟通顺畅思路一样还好,差一点都会在之后的功能叠加上被放大。我们项目的整个流程和数据存储都是前端确定,因为前端表现更知道需要什么吧。我们的打算就是前端先把整个功能写出来,后端前期只做存储,之后再功能完整后再进行代码移植。其实更多还是策划的需求只能这样。前端要实时判断是否可以建造,所以所有的规则都得实现判定。
通信字段:
一个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的原因。