星座物语客户端分析---01物品编辑器

星座物语客户端分析---01物品编辑器

星座物语客户端分析---01物品编辑器

一、整体设计思路猜测

1.前期目标数据结构尽可能单一化，配置化。

2.尽可能让程序和策划的接口无人化，工具化，归纳需求以后程序提供工具给策划人员。

二、数据结构分析

所有的道具都被冗余到同一个数据结构中了。

优势：编码、和配置文件的制作上非常方便

劣势：内存略高，后期编码肯能会有负担

*所有游戏世界中任何道具都可以用_ITEM_TABLE结构体来描述

三、类型逻辑分析

目前分析到的代码，可以看出来，道具是“二级”分类，前期考虑也不够充分，后面添加的代码略显混乱。

第一级：医疗道具、装备道具、辅助道具、任务道具(道具触发任务、道具触发技能、道具触发循环任务)

第二级：

  医疗道具二级分类：HP、MP、HPMP、Fealty(宠物忠诚度)、Health

  装备道具二级分类：武器、头部、衣服、手套、鞋子、项链、戒子、肩部

  *任务道具二级分类(实际代码被卸载一级分类中了)：道具触发任务、道具触发循环任务

  *辅助道具二级分类(实际代码被卸载一级分类中了)：道具触发技能、ect.

四、细节分析：

1.对武器强化(打宝石，打孔)的支持不够好。

猜测_ITEM_TABLE.nNextLevel用于支持强化。实际使用可能强化前，和强化后是完全不同的两个物品，通过nNextLevel关联起来。这种设计中每个武器只要是同一类型，那么一定是统一属性的。

一个更好的方案是，给每个武器一个GUID，然后可以为武器添加全局唯一的属性，方便“小极品”，允许更多个性化的存在，同时也可以更好的追踪物品的交易流转。这样需要一个查询效率足够高的数据库来保存游戏中每一个物品的数据。目测可以用KV来解决。如果查询压力太大，可以允许数据冗余，将道具的GUID数据和持有玩家绑定起来，一个玩家ID可以批量查询出其对应的所有道具的GUID数据，直接用blob字段保存起来，同时GUID字段作为日志表保持，只在发生更改的时候才会有写操作。或者这部分数据用KV数据库系统保存。

2.有没有办法把_ITEM_TABLE结构体拆分，或者把道具做的灵活一点，变成组建系统或者属性系统。

比如：道具看成是一个组建/属性容器，放了一个装备组建进去他就具有装备的功能，放了一个医疗属性就是一个医疗物品。这样道具可以更加灵活，比如：将一个装备作为药品吃掉。（这个时候一级类型不再是类型，而是属性，具有装备道具属性同时具有道具类型属性）

3.降内存

使用protobuf代替直接使用结构体会不会好一点？_ITEM_TABLE中还使用了std::string作为字段，一个不小心memset就会挂掉。此外protobuf的优势还有支持optional等配置，可能会有优势，比如不用更具一级类型去复用二级类型的字段，而是将不同的部分独立出来作为optional字段。

五、道具属性

基础属性(三围数据)：力量(Strength)、敏捷(Agility)、耐力(Stamina)、精神(Energy)、智力(Intellect)、物攻(Attack)、魔攻(Magic)、物防(Recovery)、魔防(Mrecovery)、攻速(AckSpeed)、准确(Nicety)、躲闪(Dodge)

MP、HP

体力消耗

磨损

价格

职业

ect.待续，改天直接分析策划案子,这个样子太累