再更一下,角色背包装备背包也搞定了。
总结一下背包和仓库的难点:
1. 由于不想同步容量和物品实例(否则Array变来变去很难预测),客户端和服务端通信采用的是格子的来源及坐标。加大了通信的难度(服务端默认不相信客户端的物品实例,其实没必要,只是练习下服务端校验)
2. UE的RPC方法只能是void(不确定,反正报错不给用,能用返回的话欢迎指正),导致有些逻辑只能依赖异步,加大了复杂度(比如客户端移动物品,点一下给一个跟随鼠标的图标,再点一下目标格子去服务端挪移,客户端在RPC发起时,就已经使用本地数据预测了结果,如果结果不对,得处理回滚)
3. 背包的数据结构没有设计好,一共六个背包格子,基本固定的,应该采用Capacity1~6六个属性,而我用了数组
导致每动一个背包,一个数组的其他背包得跟着处理,即使它没动。不但容量是数组,实例也是数组,换背包得刷新整个面板,否则蓝图上得拖一大堆线去处理数组中的每个值。属实是过度设计了,结果不但没有太通用,反而更耦合了。思考了一下,正确做法可能应该分成6个独立的属性放在PlayerState上,背包通过配置绑定一个Tag,搞个被动Ability用SetByCaller设置value修改属性值,装上去触发增加的Effect,拿下去触发减少的Effect,UI上固定6个NamedSlot,有东西就展示,没东西就Hidden,然后在OnRep_中处理客户端,不敢想得有多简单,还能本地预测不依赖网络,也能很简单的刷新单个背包,哎,下一个会更好。
----
其他就跟背包仓库没关系了,都是不熟练导致的。总之存储系统的工作量和联机的工作量双双超出预期,做了小半月才搞定,不过基础框架搭好了,后续做人物装备面板,只需要拿现成的组件拼拼凑凑就成了,包括后续想做的合成面板,都会受益。
----
存储算是做完了,下一步是角色装备面板和属性
图:存储完工

总结一下背包和仓库的难点:
1. 由于不想同步容量和物品实例(否则Array变来变去很难预测),客户端和服务端通信采用的是格子的来源及坐标。加大了通信的难度(服务端默认不相信客户端的物品实例,其实没必要,只是练习下服务端校验)
2. UE的RPC方法只能是void(不确定,反正报错不给用,能用返回的话欢迎指正),导致有些逻辑只能依赖异步,加大了复杂度(比如客户端移动物品,点一下给一个跟随鼠标的图标,再点一下目标格子去服务端挪移,客户端在RPC发起时,就已经使用本地数据预测了结果,如果结果不对,得处理回滚)
3. 背包的数据结构没有设计好,一共六个背包格子,基本固定的,应该采用Capacity1~6六个属性,而我用了数组

----
其他就跟背包仓库没关系了,都是不熟练导致的。总之存储系统的工作量和联机的工作量双双超出预期,做了小半月才搞定,不过基础框架搭好了,后续做人物装备面板,只需要拿现成的组件拼拼凑凑就成了,包括后续想做的合成面板,都会受益。
----
存储算是做完了,下一步是角色装备面板和属性
图:存储完工
