接着上篇。由于我不提供静态的碰撞数据了,服务器的 炸弹爆炸 和 怪物的范围攻击 就获取不到目标了。
有这几中实现方式:
1、服务器自己做物理系统。这样最好,可是目前服务器已经引入了物理系统,只是无法检测目前服务器也描述不清的物体(服务器是不可能知道哪怕是粗模的数据)。在简易化建筑后效果也很差,主要还是很难描述清除一个多样化建筑的复杂形状。
2、用客户端物理检测发给服务器。就像fps一样仅仅靠客户端检测,可是我们还有攻城的怪物,攻城怪物会有范围攻击。其他游戏能比较容易的检查出范围攻击内的敌方,是因为 敌方数量不大、大小基本确定。加上,服务器去让客户端检测,在玩家使用炸弹进行范围攻击时,还好说,检测有宿主。怪物攻城的时候,怪物是独立的,没有宿主来辅助检测,找谁去辅助都有问题,且即使用一套严谨的宿主查找方式,也不好说,遇到宿主网络不稳定时,这个问题也是不可接受的。
3、使用上一篇的类似的办法。可 即使 使用像素化空间来存储建筑数据,也会因为建筑大小不确定,无法准确的存储到对应的空间节点。比如:我们的一个叫**大厅的建筑大小是炸弹的100倍,大厅的中心点到炸弹有很长的距离,但是边缘到炸弹同样无法用一个或几个简单的参数描述清除。这样就造成,像上篇那样的做法一定会漏掉一些建筑 或者检测错误。虽然这样也能初筛一些建筑做膜长比对,但是锥形的建筑越靠近锥形的顶点,用范围检测的误差越大。并且,这种实时的加载数据还会带来负载的问题——多个炸弹连环引爆,加上多个怪物同时使用范围攻击技能,这一顿实时加载数并用完卸载,据恐怕是个坑。
*、对上述问题进行归纳后,其实会发现:客户端可以做一部分的检测操作,针对有宿主的建筑;服务器对碰撞数据进行实时加载来进行检查操作,可以针对无宿主的建筑。这样就能避免服务器瞬时的加载卸载压力,同时也避免了怪物没有宿主来辅助检查的问题。
那就使用上一篇的类似的办法,并优化一下。
针对没有宿主的范围攻击:在建筑初始化的时候读取建筑的碰撞数据,把建筑存到碰撞数据占用的立方块里。要进行范围建筑检测的时候,可以直接拿到范围中全部的立方块,读取所有立方块潜在碰撞的建筑,这算个初筛。加载初筛建筑的碰撞数据,并检测碰撞数据是否在工具范围内。就得到没有宿主的范围建筑查找了。
针对有宿主的范围攻击:比如炸弹,摆放的那一刻,摆放者请求服务器他的攻击范围内的建筑(我们被攻击时,无法建筑新的建筑),在炸弹爆炸的时候用。