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