CHANGE.md 4.3 KB
优化项
AOI优化
- 使用基于版本号的 AOI 管理，给每个 Tower 一个版本号，并传递给客户端
- 每次有数据更新就更新 Tower 的版本号
- 客户端移动屏幕时同步下发所有 Tower 的版本号，服务端只推送版本号不一致的 AOI 数据
map player
玩家的资源点应该记录在playerTable，当发送discard消息时只需要在map player身上处理即可，同时地块有变化也会通知该map player
player_logic.go
func (p *actorPlayer) discard(session *cproto.Session, req *pb.I64I32)
障碍点
- 到了障碍点这一层基本上没有多点的概念了，只需要提供批量设置点和批量移除点的功能就好了
资源带
- 某一点快速定位到资源带，先用资源带中心坐标算出ID保存成Map，再通过公式把点映射到中心坐标
三个问题
1. 攻城
问题描述
- 攻城时客户端统一传了建筑的中心点坐标以及建筑对象ID
- 服务端实现攻城点的选取策略为往中心点寻路然后从终点回溯到城墙位置
- 建筑中心点应该是不可通行的动态障碍点，码头和渡口的中心点是不可通行的固定障碍点，寻路会失败
- 当前攻城方法能实现是因为服务端做了兼容处理，需要改为统一的处理逻辑
建议方案
- 不管是什么建筑（玩家城，小型建筑，大型系统城，关卡，渡口等），攻城操作都应该是一个统一的处理流程
- 为每个建筑的每一边都配置一个或者多个攻城点，攻城的时候按距离选择一边，获取多个攻城点
- 通过起点和多个攻城点找到一条成功路径
备选方案
- 由客户端传入攻城点坐标，服务端根据地编数据做验证
人员配合
- 需要策划确定，每个建筑的攻城点是一个还是多个
- 需要地编工具支持给建筑配置攻城点（是否需要按照方向来分组）
- 需要策划导出新的地编数据，包含攻城点的配置
- 如果选择备选方案，还需要客户端支持（路径查询也是请求服务端的，那这个方案是否可行需要与客户端讨论）
2. 插旗
问题描述
- 插旗逻辑不统一，领地可以覆盖州内边界，但无法覆盖州界
- 玩家无法判断哪些是州内边界，哪些是州界
- 旗帜领地范围设计不好可能会导致领地跨过了还未打通关卡的相邻区域，导致主城可以直接落地相邻的区
- 如果旗帜领地覆盖了边界，从边界另一边也有可能连上领地
- 当前服务端的处理方案是，如果旗帜领地覆盖了固定障碍点，就跳过固定障碍点不标识为领地（无法避免覆盖到相邻区的问题）
建议方案
- 在地图上任何位置插旗的行为都应该是一致的，要么都能覆盖边界，要么都不能
- 在地编数据设计上规避掉两个旗帜领地能通过边界相连接的情况（边界要足够宽）
人员配合
- 需要策划确定统一的处理方案
- 需要地编工具支持，在导出地编数据时做检测，避免两个旗帜领地能通过边界相连接的情况
3. 资源和怪物
问题描述
- 资源带的设计过于粗暴，没有考虑固定障碍点的问题
- 资源改为了不刷新，但是被建筑覆盖上去后，资源点会被移除，需要补充
建议方案
- 删除资源带，由地编随机生成，策划调整之后导出地编数据
- 建筑覆盖时移除（或者隐藏）了资源点，建筑拆除后可以通过地编数据重新生成资源点
人员配合
- 需要地编工具支持随机生成资源点，并支持手动调整
- 需要策划多花时间布置资源点位置
4. 玩家被建筑推开
问题描述
- 玩家中止攻城时，部队会往城墙外退一格
- 玩家部队停在空地上时，当空地被其他玩家盖建筑时，部队往建筑外面退
- 系统城被其他联盟占领时，停留在系统城上的部队往城外退
- 目前处理方案比较暴力直接让玩家回城
建议方案
- 每个建筑配置墙外的一圈作为撤退点，部队外推时，选择其中一个点
- 如果选择的点不可走，继续选择下一个点（也可以参照攻城选点的逻辑）
- 如果所有点都不可走，就回城
人员配合
- 需要地编工具支持给建筑配置墙外的一圈作为撤退点