熱更新的內容可以是美術資源, 可以是程式碼, 但相對來說, 美術資源的更新不會受到約束, 程式碼實際上是重災區, 本文介紹的主要是程式碼熱更新

熱更新對於開發者來說是一件麻煩事, 特別對於看重效率,便捷性和結構的程式設計師來說, 熱更新就是運營人員的不懂技術的表現
然而, 對於上線才是剛剛開始的網路遊戲, 特別是手游來說. 熱更新是極為重要的基礎功能

為什麼要熱更新

客戶端

適應上線需求

對於手遊客戶端來說, 受到蘋果稽核的約束, 一次稽核提交需要10~20天不等的等待時間, 而這段時間, 開發進度依然會推進很多.

一旦手游上線, 第一個版本在玩家瘋狂行為下, 出點問題是必然的, 所以”上線更”就成了家常便飯. 如果你要說, 必須大包, 無法熱更, 那麼10~20

多天後, 遊戲估計就沒啥人了, 更別說渠道, 發行投入巨大資金進行推廣之下讓玩家迎來的一堆bug的版本以及所謂程式設計師的傲慢和清高.

熱除錯, 熱開發, 熱釋出

除了線上問題之外, 由於Unity3D為了適應64位應用需求, 將C#編譯出的IL程式碼利用il2cpp第三方庫編譯成為c++. 效率提升了倒是好,

但工程編譯和釋出時間變得相當感人, 沒個1~2個小時完全搞不定. 即便加裝ssd, 為了修改一個bug, 也不知道要等多少根菸的時間…

只要核心功能不變化的情況下, 完全可以讓熱更新成為開發期間的好工具, lua程式碼修改後, 馬上可以在手機上看效果, 沒有編譯, 釋出的時間損耗, 其實反而提升了開發效率

伺服器

對於伺服器來說, 常見遊戲型別的玩家一般在半夜的線上人數會急速下降. 但是對於比較熱門的MMO, 以溝通為基礎的遊戲, 半夜也會有很多人線上

因此傳統的停服更新對於玩家的熱情秒殺很大的. 想想看,屁股先鋒公測停15天各位是什麼感受? 所以為了玩家體驗, 同時保證伺服器穩定的前提下

修復一些輕微bug, 用熱更新再合適不過了. 所以老伺服器程式設計師, 千萬不能以伺服器穩定為藉口而忽略了玩家體驗.

技術是用來解決問題的, 不是用來裝X的

怎麼熱更新

以下是Unity3D的幾種熱更新方式

基於C#, 使用動態載入Assembly反射更新程式碼

這種方式在安卓上完全可行, 對現有架構無需大的修改, 一樣使用C#和Unity3D的方式進行開發

但在iOS上受到限制, 因此對於全平臺首發的遊戲, 或者雙平臺都要上的遊戲, 已經慢慢的不使用這種方法進行熱更新了

基於Lua, 將Lua程式碼視為資源, 動態載入並執行

雲風團隊早期研究出的UniLua是基於C#編寫的Lua虛擬機器來執行, 而且只支援位元組碼解釋, 因此無法做動態功能, 效率奇低

後期, ulua的出現, 徹底將Lua作為比較正統的更新方式存在. ulua基於Tolua庫進行封裝, 添加了一些便捷封裝, 程式碼打包和基本的框架

ToLua本身是一個基於C版Lua上擴充的庫, 以靜態連結庫方式與Unity3D程式碼連結. 因此, 可以說ToLua是跑在C層上, 速度不亞於C++和Lua的組合

基於Lua的程式碼更新方式, 無論跨任何平臺都可以以同一套程式碼和工作流進行, 因此避免很多麻煩, 成為現在主流的開發方式

遊戲邏輯全都用Lua寫麼?

做過網頁和手機App的童鞋都發現, js, 一個bug超多, 設計奇怪的語言居然成為主流介面開發語言, 為啥?

動態特性適合製作ui

另外一個反例就是: 使用C++開發介面, 例如Qt, MFC之類, 雖然設計嚴謹, 但是最終擋不住各種奇葩的修改需求

因此, 介面非常推薦使用動態語言來開發, 遊戲界就是用Lua

而遊戲核心, 根據各自遊戲型別來定, 總的一點, 效率瓶頸點, Update之類的, 儘量使用C#或者C++來實現

寫在最後

當前中國大環境下的玩家和各種氪金理由與純的不能再純的遊戲人的基本願望是衝突的

然而國外遊戲的各種設計和機制, 暴雪戰網更新不及時, 版本不對沒提示, 這些基本錯誤在中國的網遊都不會出現的

技術上無法趕英超美的我們, 在體驗上已經輸出了我們的價值觀, 老外們都在學

對於程式設計師來說, 只是多貼近玩家, 多瞭解外面的世界而已