開始做遊戲的第12天

09-24

開始做遊戲的第12天

來自專欄開始做遊戲1 人贊了文章

先說明一下項目進度：

1.修復了資源載入方面的一個BUG，可以讀取到文件了。

由於資源載入方面我直接上了AssetBundle,抽到大塊的時間整一個編輯器用來編輯ab包的路徑，手動設置文件和文件夾太蛋疼了，保不準哪天傻逼

2.開始準備導入第一個場景，具體的場景設計還沒弄。計劃是導入一個別處扒來的場景，不過還需要整理。

3.關於讀檔和存檔的思考，這個也是引出今天內容的主要因素。

先說存檔讀檔，在我之前的計劃中是使用Newtonsoft.Json.JsonConvert序列化要保存的類，昨天翻到了 @絮醬醬翻譯的一個插件說明，有興趣的可以研究一下

絮醬醬：【Unity插件】EasySave3 文檔翻譯(一) 入門?

zhuanlan.zhihu.com

然後是今天的重點了。

在我考慮如何讀取保存玩家數據，如何讀取數據，進入遊戲等操作的流程時，我習慣性的寫了一個方法，是這樣的

private void StartLoadGameAsset() { //記載配置 ConfigManager.INSTANCE.LoadConfigData(); //載入UI ResourceLoad.ResourceLoadManager.INSTANCE.LoadAssetBundle(AssetBundleNameDefine.UI_Panel, false); //TODO 載入存檔 // 載入角色存檔，載入場景信息，載入怪物信息 LoadFileManager.LoadPlayerInfo(); LoadFileManager.LoadSceneInfo(); LoadFileManager.LoadMonsterInfo(); finish = true; }

嗯，看起來沒毛病啊，讀取到一切需要的東西，然後就可以切換遊戲狀態機該幹嘛幹嘛了。挺好挺好。然後我就去睡覺了。

但是！！在我一覺睡醒後，發現怎麼這麼傻逼呢。

即便對於一個單機遊戲，把遊戲功能映射到網路遊戲，功能上還是可以區分出服務端邏輯和客戶端邏輯的。

舉個例子，就拿存檔來說，對應的網遊功能就是伺服器讀取資料庫的過程，讀取到然後轉發給客戶端。這樣我們可以把上面的代碼區分開來,上面讀檔部分可以這麼寫

Bridge.RequestSaveInfo(delegate{ finish = true; })

這一行代碼去我們新封裝的偽服務端請求數據,就是下面的Server.Load.LoadSaveFile，讀取完收到伺服器端的回調。

服務端的偽代碼（因為我還沒動手。。。）如下

namespace Server{ public class Load { public void LoadSaveFile(callback) { // 載入角色存檔，載入場景信息，載入怪物信息 LoadFileManager.LoadPlayerInfo(); LoadFileManager.LoadSceneInfo(); LoadFileManager.LoadMonsterInfo(); //回調 callback(); } }}

這麼講你是不是懂了，就是我們自己偽造一個服務端。把單機遊戲和網遊中服務端相同功能部分抽出來。

腳本文件目錄如下

為什麼會有一個Common文件夾，因為這畢竟是一個單機遊戲，有的數據還是需要共享的，如果嚴格區分服務端客戶端邏輯的話，有些地方會造成浪費。比如說視野中存在的怪物列表，客戶端一份伺服器一份，遍歷查找的開銷也是兩份了，所以說一些功能根據取捨可以合併在一起，當然最好是純數據。

如次區分客戶端伺服器有幾個好處：

代碼邏輯比較清楚，符合我一直以來做網遊的思維方式。

下個項目進行時部分代碼可以復用，而且根據客戶端需要展示的效果，改動的部分不會傷筋動骨。

未來如果有可能移植成網遊，這種結構在代碼復用上也有優勢。

歡迎批評指正。

轉載請註明出處。