星座物語客戶端分析---01物品編輯器
一、整體設(shè)計思路猜測
1.前期目標(biāo)數(shù)據(jù)結(jié)構(gòu)盡可能單一化，配置化。
2.盡可能讓程序和策劃的接口無人化，工具化，歸納需求以后程序提供工具給策劃人員。
二、數(shù)據(jù)結(jié)構(gòu)分析
所有的道具都被冗余到同一個數(shù)據(jù)結(jié)構(gòu)中了。
優(yōu)勢：編碼、和配置文件的制作上非常方便
劣勢：內(nèi)存略高，后期編碼肯能會有負(fù)擔(dān)
*所有游戲世界中任何道具都可以用_ITEM_TABLE結(jié)構(gòu)體來描述
三、類型邏輯分析
目前分析到的代碼，可以看出來，道具是“二級”分類，前期考慮也不夠充分，后面添加的代碼略顯混亂。
第一級：醫(yī)療道具、裝備道具、輔助道具、任務(wù)道具(道具觸發(fā)任務(wù)、道具觸發(fā)技能、道具觸發(fā)循環(huán)任務(wù))
第二級：
醫(yī)療道具二級分類：HP、MP、HPMP、Fealty(寵物忠誠度)、Health
裝備道具二級分類：武器、頭部、衣服、手套、鞋子、項鏈、戒子、肩部
*任務(wù)道具二級分類(實際代碼被卸載一級分類中了)：道具觸發(fā)任務(wù)、道具觸發(fā)循環(huán)任務(wù)
*輔助道具二級分類(實際代碼被卸載一級分類中了)：道具觸發(fā)技能、ect.
四、細(xì)節(jié)分析：
1.對武器強化(打?qū)毷蚩?的支持不夠好。
猜測_ITEM_TABLE.nNextLevel用于支持強化。實際使用可能強化前，和強化后是完全不同的兩個物品，通過nNextLevel關(guān)聯(lián)起來。這種設(shè)計中每個武器只要是同一類型，那么一定是統(tǒng)一屬性的。
一個更好的方案是，給每個武器一個GUID，然后可以為武器添加全局唯一的屬性，方便“小極品”，允許更多個性化的存在，同時也可以更好的追蹤物品的交易流轉(zhuǎn)。這樣需要一個查詢效率足夠高的數(shù)據(jù)庫來保存游戲中每一個物品的數(shù)據(jù)。目測可以用KV來解決。如果查詢壓力太大，可以允許數(shù)據(jù)冗余，將道具的GUID數(shù)據(jù)和持有玩家綁定起來，一個玩家ID可以批量查詢出其對應(yīng)的所有道具的GUID數(shù)據(jù)，直接用blob字段保存起來，同時GUID字段作為日志表保持，只在發(fā)生更改的時候才會有寫操作。或者這部分?jǐn)?shù)據(jù)用KV數(shù)據(jù)庫系統(tǒng)保存。
2.有沒有辦法把_ITEM_TABLE結(jié)構(gòu)體拆分，或者把道具做的靈活一點，變成組建系統(tǒng)或者屬性系統(tǒng)。
比如：道具看成是一個組建/屬性容器，放了一個裝備組建進去他就具有裝備的功能，放了一個醫(yī)療屬性就是一個醫(yī)療物品。這樣道具可以更加靈活，比如：將一個裝備作為藥品吃掉。（這個時候一級類型不再是類型，而是屬性，具有裝備道具屬性同時具有道具類型屬性）
3.降內(nèi)存
使用protobuf代替直接使用結(jié)構(gòu)體會不會好一點？_ITEM_TABLE中還使用了std::string作為字段，一個不小心memset就會掛掉。此外protobuf的優(yōu)勢還有支持optional等配置，可能會有優(yōu)勢，比如不用更具一級類型去復(fù)用二級類型的字段，而是將不同的部分獨立出來作為optional字段。
五、道具屬性
基礎(chǔ)屬性(三圍數(shù)據(jù))：力量(Strength)、敏捷(Agility)、耐力(Stamina)、精神(Energy)、智力(Intellect)、物攻(Attack)、魔攻(Magic)、物防(Recovery)、魔防(Mrecovery)、攻速(AckSpeed)、準(zhǔn)確(Nicety)、躲閃(Dodge)
MP、HP
體力消耗
磨損
價格
職業(yè)
ect.待續(xù)，改天直接分析策劃案子,這個樣子太累