游戲人物裝備技能數據表怎么設計（整理）
一、總結
一句話總結：把人物的屬性抽離出去，其它的裝備啊，技能表和屬性表之間建立一個關系表。
1、裝備表如何設計（裝備表和角色表的對應關系是什么）？
裝備屬於人物，所以裝備表可以加上所屬人物的id
裝備，包括的數據項有：裝備名稱，裝備描述，（通用屬性），裝備ID，主人ID
其實可以弄一個裝備屬性表，來表示裝備提升的屬性，和技能一樣
2、技能表如何設計？
技能，包括的數據項有：技能名稱，基礎傷害，加成類型，加成比例，冷卻時間，學習等級
其實可以弄一個技能屬性對應表，來表示技能提升的屬性
有技能id，有屬性id，有提升類型（數值還是百分比），有提升值，每升一級提升值
3、人物的屬性（包括基礎屬性比如力量魔法和面板屬性比如傷害）是否需要抽離？
需要：因為下面這條里面有屬性id
有技能id，有屬性id，有提升類型（數值還是百分比），有提升值 （每級），有技能圖標
4、怪物表如何設計？
和角色表一樣，角色有的怪物應該都有，比如各種屬性
二、RPG游戲數據庫設計
一.數據庫需求分析
通過游戲過程中所需元素，設計如下數據項和數據結構
1.角色，包括的數據項有：用戶ID，角色ID，角色昵稱，（通用屬性，角色屬性）
2.角色屬性，包括的數據項有：力量，智力，敏捷，經驗值，職業，角色ID
3.通用屬性，包括的數據項有：生命值，魔法值，攻擊力，護甲值，魔抗值，主人ID
4.怪物信息，包括的數據項有：怪物ID，（通用屬性，NPC屬性）
5.NPC屬性，包括的數據項有：出生地點，活動范圍，功能，主人ID
6.用戶信息，包括的數據項有：用戶ID，用戶密碼，用戶郵箱，登陸地址，登陸時間
7.裝備，包括的數據項有：裝備名稱，裝備描述，（通用屬性），裝備ID，主人ID
8.技能，包括的數據項有：技能名稱，基礎傷害，加成類型，加成比例，冷卻時間，學習等級
二.數據庫概念結構設計
三.數據庫邏輯結構設計
| 角色 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| YHID | INT | 8 | 不為NULL，外鍵 | 創建該角色的用戶ID |
| JSID | INT | 8 | 不為NULL，主鍵 | 該角色的ID |
| JSNC | CHAR | 8 | 不為NULL | 角色昵稱 |
| 角色屬性 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| ID | INT | 8 | 不為NULL，外鍵 | 擁有該屬性的角色ID |
| LL | INT | 3 | 不為NULL | 力量 |
| ZL | INT | 3 | 不為NULL | 智力 |
| MJ | INT | 3 | 不為NULL | 敏捷 |
| JYZ | INT | 3 | 不為NULL | 經驗值 |
| ZY | CHAR | 4 | 不為NULL | 職業 |
| 通用屬性 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| SMZ | INT | 3 | 不為NULL | 生命值 |
| MFZ | INT | 3 | 不為NULL | 魔法值 |
| GJL | INT | 3 | 不為NULL | 攻擊力 |
| HJZ | INT | 3 | 不為NULL | 護甲值 |
| MKZ | INT | 3 | 不為NULL | 魔抗值 |
| ID | INT | 8 | 不為NULL，外鍵 | 擁有該屬性的ID |
| 怪物 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| ID | INT | 8 | 不為NULL，主鍵 | 怪物ID |
| NPC屬性 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| ID | INT | 8 | 不為NULL，外鍵 | 擁有該屬性的ID |
| CSDD | CHAR | 8 | 不為NULL | 出生地點 |
| HDFF | INT | 3 | 不為NULL | 活動范圍 |
| GN | CHAR | 3 | 可空，商人，任務發布者，怪物等 | 功能 |
| 用戶信息 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| YHID | INT | 8 | 不為NULL，主鍵 | 用戶ID |
| YHMM | CHAR | 8 | 不為NULL | 用戶密碼 |
| YHYX | CHAR | 8 | 不為NULL | 用戶郵箱 |
| DLDZ | CHAR | 8 | 可NULL | 登陸地址 |
| DLSJ | CHAR | 8 | 可NULL | 登陸時間 |
| 裝備 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| ZBID | INT | 8 | 不為NULL，主鍵 | 裝備ID |
| ZRID | INT | 8 | 不為NULL，外鍵 | 擁有該裝備的角色ID |
| ZBMC | CHAR | 8 | 不為NULL | 裝備名稱 |
| ZBMS | CHAR | 8 | 可NULL | 裝備描述 |
| 技能 | ||||
|---|---|---|---|---|
| 字段名 | 數據類型 | 長度 | 是否為NULL | 描述 |
| ID | INT | 8 | 不為NULL，外鍵 | 擁有該技能的角色ID |
| JNMC | CHAR | 8 | 不為NULL | 技能名稱 |
| JCSS | INT | 8 | 不為NULL | 基礎傷害 |
| JCLX | CHAR | 2 | 不為NULL，物理，魔法 | 加成類型 |
| JCBL | INT | 2 | 可為NULL | 加成比例 |
| LQSJ | INT | 3 | 不為NULL | 冷卻時間 |
| XXDJ | INT | 3 | 可為NULL | 學習等級 |
四.數據庫物理結構設計
根據以上邏輯分析所得到的表的關系，我們使用SQL語言設計得到數據庫和數據表，如下：
1.創建數據庫RPGdatabase
CREATE DATABASE RPGdatabase;
2.創建角色數據表
CREATE TABLE Players(
YHID INTEGER NOT NULL,
JSID INTEGER NOT NULL,
JSNC CHAR(8) NOT NULL,
PRIMARY KEY(JSID)
FOREIGN KEY(YHID) REFERENCES(Users)
)
3.創建角色屬性數據表
CREATE TABLE PAttributes(
ID INTEGER NOT NULL,
LL INTEGER NOT NULL,
ZL INTEGER NOT NULL,
MJ INTEGER NOT NULL,
JYZ INTEGER NOT NULL,
ZY CHAR(4) NOT NULL,
FOREIGN KEY(ID) REFERENCES(Players)
)
4.創建通用屬性數據表
CREATE TABLE PAttributes(
ID INTEGER NOT NULL,
SMZ INTEGER NOT NULL,
MFZ INTEGER NOT NULL,
GJL INTEGER NOT NULL,
HJZ INTEGER NOT NULL,
MKZ INTEGER NOT NULL,
FOREIGN KEY(ID) REFERENCES(Players)
)
5.創建怪物數據表
CREATE TABLE Monsters(
ID INTEGER NOT NULL,
PRIMARY KEY(ID)
)
6.創建NPC屬性數據表
CREATE TABLE NpcAttributes(
ID INTEGER NOT NULL,
CSDD CHAR(8) NOT NULL,
HDFF INTEGER NOT NULL,
GN CHAR(3),
FOREIGN KEY(ID) REFERENCES(Players)
)
7.創建用戶信息數據表
CREATE TABLE Users(
YHID INTEGER NOT NULL,
YHMM CHAR(8) NOT NULL,
YHYX CHAR(8) NOT NULL,
DLDZ CHAR(8),
DLSJ CHAR(8),
PRIMARY KEY(YHID)
)
8.創建裝備信息數據表
CREATE TABLE Equips(
ZBID INTEGER NOT NULL,
ZRID INTEGER NOT NULL,
ZBMC CHAR(8) NOT NULL,
ZBMS CHAR(8),
PRIMARY KEY(ZBID)
FOREIGN KEY(ZRID) REFERENCES(Players)
)
9.創建技能信息數據表
CREATE TABLE Skills(
ID INTEGER NOT NULL,
JCSS INTEGER NOT NULL,
JNMC CHAR(8) NOT NULL,
JCLX CHAR(2) NOT NULL,
JCBL INTEGER,
LQSJ INTEGER NOT NULL,
XXDJ INTEGER,
FOREIGN KEY(ID) REFERENCES(Players)
)
參考：RPG游戲數據庫設計 - 簡書
https://www.jianshu.com/p/59fde9eef388
二、MMORPG游戲服務器技能系統設計：表格字段與技能程序框架
本文主要從一個程序員的角度闡述一下mmorpg服務器技能系統的程序框架設計，最近在做這個，就當做一個總結吧，其中某些概念可能沒有解釋清楚，歡迎大家拍磚討論~
技能其實是戰斗系統的一個組成部分，戰斗基本上都可以由技能觸發，技能系統實際上就是一套完整的邏輯，我們用表格來設計，將技能的邏輯用屬性字段抽象出來，然后依據屬性字段來控制邏輯，策划人員可以通過更改屬性字段來配置出不同的邏輯屬性。
1. 表格屬性字段的設計
為了減少冗余，我們將技能屬性字段設計在4個不同的表中：
Skill表：技能表的入口表，包括cast表，buffer表，op表，技能的釋放需求，傷害
Cast表: 技能的釋放過程表，包括技能吟唱時間，技能命中距離等等
Buffer表：各種人物狀態，靜態和動態的光環，效果等等
Status表：角色狀態表，角色在狀態下能使用或被使用的技能或者buffer
op表: 技能的傷害計算公式
skill表字段設計：
名稱：技能名稱，如火球術
技能id：技能id值
技能名稱id：技能系，id一樣表示一個系技能
技能類型：加血、物理攻擊、魔法攻擊、buffer、地圖技能
公共CD時間：多個技能可以共cd,比如所有吃葯技能
CD時間：cd時間
CD保存類型：cd時間在人物下線后是否保存數據庫
需要角色等級：角色等級需求
角色狀態限制：使用技能的角色狀態限制，這個字段需要斟酌以后重新設計成一個表格
需要武器：技能釋放需要的武器類型，如弓，刀，劍等等
消耗類型：需要消耗，如hp,mp,xp等等
消耗數量：hp,mp,xp的消耗數量
是否有益：是否是有益技能
技能屬於：生活技能、裝備技能、職業技能等等
升級技能：改技能的升級技能
調用cast表：調用cast表的id號
調用describe表：調用技能描述表id號
影響形狀：范圍技能的影響范圍，直線、圓、扇形
影響個數：范圍技能影響的npc個數
Buffer1：技能觸發的buffer1
概率1：技能觸發buffer1的概率
Buffer2：技能觸發的buffer2
概率2：技能觸發buffer2的概率
傷害效果：技能產生的傷害
調用op表計算效果：op表中數值計算的公式
是否產生傷害仇恨：是否產生仇恨值
攜帶仇恨：技能產生的仇恨值
cast表字段設計：
名稱：cast表對應技能名稱
是否對地釋放：是否對地釋放
是否對他人釋放：是否可以對他人釋放該技能
是否對自己釋放：是否可以對自己釋放該技能
是否前搖打斷：前腰是否可以打斷
前搖時間：動畫前搖的時間
飛行時間：魔法的飛行時間
持續施法時間：技能的施法時間
吟唱時間：吟唱時間
釋放距離：釋放技能距離目標的距離
技能命中：技能命中率
命中最大距離：指向型技能當目標出了fire區域就不受攻擊了
buffer表字段設計：
名稱：對應skill表中的技能名稱
Id：buffer id
效果nameID：表示一個系列的buffer
類型：靜態、動態、狀態buffer
是否有益：是否有益處
角色狀態：加了buffer后角色處於的狀態，如沉默，天神下凡，嗜血等等
傷害效果：buffer的傷害
調用op表：指向op表中的公式id
動態次數：對應動態buffer生效次數，對靜態buffer無效
生效間隔：對應動態buffer每次生效的間隔時間，靜態buffer無效
持續時間：對應靜態buffer的持續時間，-1表示永久buffer
產生buffer：某些 buffer可以給隊友或敵人加
影響范圍：buffer影響的范圍
是否可以移除：對應驅散技能
移除類型：對應驅散技能等級
是否可以覆蓋：同類型buffer是否可以覆蓋，還是效果疊加
覆蓋類型：大的覆蓋小的
是否需要from：計算效果時是否需要buffer來源。
status表字段設計：
狀態名稱：角色的狀態名稱，如沉默，死亡，天神下凡等等。
狀態id：角色狀態的id號
角色動作最大值：在該狀態下可以使用或者被使用的技能的最大值，如無敵不能受傷害；
角色動作最小值：在該狀態下可以使用或者被使用的技能的最小值，如無敵不能受傷害；
狀態最大值：在該狀態下，可以被使用buffer的最大值；
狀態最小值：在該狀態下，可以被使用buffer的最小值。
2.技能程序框架
技能的表格屬性字段我們已經設計好了，可以滿足策划短期需求了，接下來我們來設計一下技能程序的框架。
技能系統服務器和客戶端是有交互的，具體流程看下圖：
服務器要通知客戶端是否能釋放技能，吟唱時間，技能命中結果，傷害數字，服務器還要廣播技能釋放結果，讓同區域的玩家可以看到別人在釋放技能。
需要立即同步的。
1. hp,眾所周知；
2，角色狀態，角色的各種狀態，比如天神下凡，沉默，死亡。
不需要同步的。
角色屬性改變，如力量，敏捷等角色屬性。
ps:服務器和客戶端同一套代碼，客戶端進行預判，除了血量和角色狀態服務器向客戶端發同步消息，其他屬性改變可以不發消息，這樣可減少服務器和客戶都的消息數量。
代碼的結構設計
這里只畫一個簡單結構，將每個table抽象為一個table_data，然后在game_char中組合起來。
https://blog.csdn.net/caoshulin1989/article/details/53081035
二、RPG手機游戲道具、物品、裝備表設計
為了讓游戲更加的豐富，我們1201團隊的新手機游戲設計了道具系統。於是豐富了游戲、取悅了玩家，哭了開發——道具/物品數據子系統是簡單的、復雜的、不確定的：
1. 簡單，說起來不就是選擇一個或多個數據庫產品，然后定義一種數據模型，然后增、刪、改、查。
2. 復雜，物品/道具可以在細分為裝備、時裝、坐騎、寶石、buff等等，每類物品有不同的屬性需求，於是：
+ 首先物品數據是游戲核心數據里數據量最大、操作最頻繁、數據結構最多元化的數據
+ 如果用一種數據表結構，那么會浪費很多的字段或數據空間（而物品表超大）；
+ 如果用不同的數據表結構，那么游戲邏輯就要麻煩一些了，比如物品在玩家中轉移的時候、修改、丟棄的時候。
+ 是否進行應用邏輯層水平切分？切分了就可以將數據庫分布到多個數據庫服務器上，那么理論上數據規模就不會成為瓶頸了；但如果切分了，道具數據分析、后期的合區邏輯就會很復雜。
+ 裝備、時裝是會有多個屬性的，且每件裝備的屬性值、屬性類型都不一樣，如何設計數據字段（當然如果用nosql數據庫就不存在這個問題了）？
3. 不確定：
+ 隨着游戲開發及運營的進行，各種新的道具的需求會不斷涌現出來，有可能就會需要增加新的屬性和功能需求
+ 到底每一個玩家最終會有多少的物品？
+ 最終單個區服的數據規模有多大這個其實很難預計。我們做的很完善（當然開發代價也大）的設計與開發會不會有些多余，甚至被老板認為想多了？
###二、游戲物品/道具系統數據模型設計目標及解決思路
上面分析做了，槽也吐了，還是要做事嘛，呵呵。根據我們的新游戲的具體需求，對物品數據庫表的設計定義了如下要求和解決思路：
序號 | 要求 | 解決思路
------| ----- | -----------------------------------
1 | 確保數據操作的性能 | 充分利用緩存服務器
2 | 降低程序開發和后期客服工作的復雜度 | 各類道具不分表
3 | 必須可以方便、靈活的支持道具新功能需求的開發 | 將多變的裝備屬性以json格式存於一個字段
4 | 保留充分的可擴展性 | 根據玩家id進行數據庫表水平切分
5 | 盡量降低合區操作時數據處理邏輯的難度和效率 | 用自增長ID、玩家id、區服id做聯合主鍵
###三、具體開發設計方案
根據以上的分析結果，我們在總結了以前的游戲開發經驗並參考了網上的一些文章后形成了我們新手機游戲的物品數據子系統的設計、開發方案。
*所有數據訪問都封裝在model層。*
1. 在程序的model層里定義公共函數GetDb(playerid,areaid)，用於物品數據及其它需要進行按用戶水平分割的數據獲取數據庫（連接）
2. 每一個物品的主鍵由itemid,playerid,areaid三個字段組成
3. 將裝備buff及某道具特有屬性統一以json字符串形式保存在一個varchar字段里
4. 道具表定義 *失效時間* 字段，這個字段同時表示道具有效期的三種情況：
+ =0 ，表示是不限時的永久性道具
+ 小於等於600000，表示有效時間段，如雙倍經驗卡有效時長3小時，那么着個字段值為 **180** （分鍾），使用此道具時，用當前時間加上這個字段值得到失效時間戳修改此字段或做其他處理
+ 大於600000，表示該道具的失效時間戳（unix時間戳格式）
5. 玩家道具數據查詢流程：
+ 首先檢查redis里有沒有
+ 如果有，返回
+ 如果沒有從數據庫里查詢並存到redis，返回
6. 修改/或增加道具數據流程：
+ 首先檢查redis里有沒有
+ 如果沒有，從數據庫里查詢並存到redis
+ 如果有，繼續
+ 修改/增加redis數據，同時在key為“item_update_list”的redis list 數據里記錄下該道具的主鍵
+ 定時根據“item_update_List”數據寫回mysql，並清除“item_update_list”
7. 刪除一個道具數據流程：
+ 在redis 里key為“item_delete_list” 的redis list 數據里記錄下該道具的主鍵
+ 刪除redis里記錄
+ 定時根據item_delete_list”數據刪除mysql里記錄，並清除“item_delete_list”
8.注意：
+ 配置redis 為 **在每次更新操作后進行日志記錄**
+ 緩存定時同步mysql處理程序可以作為一個獨立的進程運行
+ 這個解決方案可以針對其它用戶私有數據，如技能、buff。
###四、總結
數據庫表水平分割和緩存應用基本上已經是服務器端程序員的常識，在google上查相關技術資料時，大多數博文也是寫的這些。
本文先是對游戲道具/物品數據模型的進行了簡單的需求分析，然后講了思路和方案，其實我最想表達的是我的三個設計細節或idea：
+ 道具數據記錄主鍵設計（方便合區）
+ 裝備buff及道具特有的屬性字段設計（為道具豐富的功能需求提供靈活、便捷的數據基礎）
+ 所有道具類別不區分存儲（方便后期的客服查詢和數據統計）
###最后聲明：
其實我是一個程序員，呵呵！
https://blog.csdn.net/fancyblue/article/details/12025031