為什麼有的遊戲在開始玩之前要創建角色？

07-09

在很多遊戲開始之前都會先讓你創建一個角色，選擇職業、性別等信息，相當於一個初始化操作，但是否可以不創建角色，因為進入遊戲的時候肯定已經有一個賬號，直接初始化這個賬號就可以
假如賬號表是user，角色表是role，我的意思就是說註冊的時候已經建了一條user表記錄，但有些記錄例如職業、性別這些欄位沒有記錄，那麼在初始化的時候只將User表中一些空的欄位填上，不使用role來初始化。這樣做是否可以，為什麼？
更新：
好吧我描述的有問題，我的問題最準確的描述是為什麼要創建多個角色？是否可以只使用一個角色？也就是說用戶開始玩遊戲的時候後台創建一個角色，不再需要用戶去手動創建角色。

資料庫設計問題？

其實一句話就夠了——賬號和角色是兩碼事。

（PS：角色一般應該叫character不叫role，題主的英語問題我就不吐槽了）

首先，一個賬號下多個角色是非常普通的需求。

拿網路遊戲來說，肯定會有多個伺服器，之間遊戲數據不互通。比如說現在其中一個伺服器維護了，你想去別的伺服器玩，你是願意用現成的賬號直接登錄，從創建角色開始，還是重新輸入一遍那些姓名啊年齡啊身份證防沉迷啊之類信息新註冊個賬號？

很多網路RPG遊戲哪怕是同一個伺服器下也允許同一個賬號存在多個角色信息，這樣玩家就可以方便地體驗不同職業、不同專精等內容。

這時候如果你把角色和賬號放到同一個數據表裡混為一談，就會帶來賬號行重複的問題。你可以看看解釋一下關係資料庫的第一第二第三範式？ - 知乎用戶的回答，裡面講了業務系統不符合第二範式時是怎麼出錯的。我就不細講了。

其次，即使同一個賬號只允許一個角色，單表繼承的缺陷也有點大。

假設我們這個遊戲只有一個伺服器，而且也不允許一個賬號創建複數角色。

拿題主你的例子來說，用戶剛註冊賬號的時候還沒有角色信息，於是只有賬號相關的欄位被填了數據，為了插入這行數據，此時角色相關的欄位全部是null或者默認值。

這樣程序代碼就要累死了，本來資料庫上可以做很多約束，從數據層面解決問題，比如角色名字、職業等不允許為null，現在都要交給程序去判斷了。

另外一方面，從資料庫存儲的角度講，null也是有開銷的。比如你的遊戲有100萬註冊用戶，但是其中只有30萬創建了遊戲角色，另外70萬個角色的數據照樣會佔用空間。對於這種數據MSSQL即使有稀疏優化也很難受，MySQL好點有限。

當然，程序代碼多做一些檢查其實無可厚非，數據存儲空間現在也沒那麼金貴了，所以現在你考慮一下這個問題：

遊戲A上線了，老闆很開心，現在要求團隊開發一個遊戲B，賬號要和之前的通用，怎麼辦？

遊戲B是另外一個類型，原來的是武俠，現在是魔幻，屬性名什麼都不通用了。於是為了遊戲B的角色系統，你還得在原來的表裡加一大堆欄位，對吧？

然後你的表就變成了這樣：

賬號欄位幾個--|--遊戲A欄位幾十個--|--遊戲B欄位幾十個

大部分玩家都只玩其中一個遊戲，於是空數據就更多了。更令人在意的是，這兩個遊戲使用同一張表就拆不開了。

當你給這個表為遊戲B添加欄位的時候，你並沒有辦法保證這個操作不影響之前上線的遊戲A。而且當遊戲B上線以後，你可能還會改遊戲A，比如推出新系統，又給A增加了一些欄位……每次改動都有可能造成公司所有產品一起死掉的災難。你害怕嗎？

沒事，咱精力多，不怕。結果現在又要做遊戲C了。然後你可能會發現，這個表欄位一多了以後，新問題又來了——欄位總寬度超過了頁大小限制，MySQL中會造成嚴重的性能下降，而MSSQL乾脆不允許。

然後現在老闆告訴你：遊戲A再開一個伺服器，賬號通用，遊戲數據不互通。

——何必當初不老老實實地就把表設計拆開呢？

用慣了Excel的人，總是喜歡那些平面的、展開的數據結構，它們做的數據永遠是更易於閱讀而不易於維護的。你要玩資料庫，最好先把這個習慣改掉。

個人感覺：遊戲前創建角色：每個角色一個存檔

遊戲內創建角色或不創建：大多為多檔

最簡單一點，遊戲裡面有3中職業，你告訴我怎麼不創建多個角色去玩遍三種玩法？你說三個賬號？那我要問了，為什麼不能三個角色？