星座物語客戶端分析---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.待續，改天直接分析策劃案子,這個樣子太累