熱更新的內(nèi)容可以是美術資源, 可以是代碼, 但相對來說, 美術資源的更新不會受到約束, 代碼實際上是重災區(qū), 本文介紹的主要是代碼熱更新
熱更新對于開發(fā)者來說是一件麻煩事, 特別對于看重效率,便捷性和結(jié)構(gòu)的程序員來說, 熱更新就是運營人員的不懂技術的表現(xiàn)
然而, 對于上線才是剛剛開始的網(wǎng)絡游戲, 特別是手游來說. 熱更新是極為重要的基礎功能
為什么要熱更新
客戶端
適應上線需求
對于手游客戶端來說, 受到蘋果審核的約束, 一次審核提交需要10~20天不等的等待時間, 而這段時間, 開發(fā)進度依然會推進很多.
一旦手游上線, 第一個版本在玩家瘋狂行為下, 出點問題是必然的, 所以”上線更”就成了家常便飯. 如果你要說, 必須大包, 無法熱更, 那么10~20
多天后, 游戲估計就沒啥人了, 更別說渠道, 發(fā)行投入巨大資金進行推廣之下讓玩家迎來的一堆bug的版本以及所謂程序員的傲慢和清高.
熱調(diào)試, 熱開發(fā), 熱發(fā)布
除了線上問題之外, 由于Unity3D為了適應64位應用需求, 將C#編譯出的IL代碼利用il2cpp第三方庫編譯成為c++. 效率提升了倒是好,
但工程編譯和發(fā)布時間變得相當感人, 沒個1~2個小時完全搞不定. 即便加裝ssd, 為了修改一個bug, 也不知道要等多少根煙的時間…
只要核心功能不變化的情況下, 完全可以讓熱更新成為開發(fā)期間的好工具, lua代碼修改后, 馬上可以在手機上看效果, 沒有編譯, 發(fā)布的時間損耗, 其實反而提升了開發(fā)效率
服務器
對于服務器來說, 常見游戲類型的玩家一般在半夜的在線人數(shù)會急速下降. 但是對于比較熱門的MMO, 以溝通為基礎的游戲, 半夜也會有很多人在線
因此傳統(tǒng)的停服更新對于玩家的熱情秒殺很大的. 想想看,屁股先鋒公測停15天各位是什么感受? 所以為了玩家體驗, 同時保證服務器穩(wěn)定的前提下
修復一些輕微bug, 用熱更新再合適不過了. 所以老服務器程序員, 千萬不能以服務器穩(wěn)定為借口而忽略了玩家體驗.
技術是用來解決問題的, 不是用來裝X的
怎么熱更新
以下是Unity3D的幾種熱更新方式
基于C#, 使用動態(tài)加載Assembly反射更新代碼
這種方式在安卓上完全可行, 對現(xiàn)有架構(gòu)無需大的修改, 一樣使用C#和Unity3D的方式進行開發(fā)
但在iOS上受到限制, 因此對于全平臺首發(fā)的游戲, 或者雙平臺都要上的游戲, 已經(jīng)慢慢的不使用這種方法進行熱更新了
基于Lua, 將Lua代碼視為資源, 動態(tài)加載并運行
云風團隊早期研究出的UniLua是基于C#編寫的Lua虛擬機來運行, 而且只支持字節(jié)碼解釋, 因此無法做動態(tài)功能, 效率奇低
后期, ulua的出現(xiàn), 徹底將Lua作為比較正統(tǒng)的更新方式存在. ulua基于Tolua庫進行封裝, 添加了一些便捷封裝, 代碼打包和基本的框架
ToLua本身是一個基于C版Lua上擴充的庫, 以靜態(tài)鏈接庫方式與Unity3D代碼鏈接. 因此, 可以說ToLua是跑在C層上, 速度不亞于C++和Lua的組合
基于Lua的代碼更新方式, 無論跨任何平臺都可以以同一套代碼和工作流進行, 因此避免很多麻煩, 成為現(xiàn)在主流的開發(fā)方式
游戲邏輯全都用Lua寫么?
做過網(wǎng)頁和手機App的童鞋都發(fā)現(xiàn), js, 一個bug超多, 設計奇怪的語言居然成為主流界面開發(fā)語言, 為啥?
動態(tài)特性適合制作ui
另外一個反例就是: 使用C++開發(fā)界面, 例如Qt, MFC之類, 雖然設計嚴謹, 但是最終擋不住各種奇葩的修改需求
因此, 界面非常推薦使用動態(tài)語言來開發(fā), 游戲界就是用Lua
而游戲核心, 根據(jù)各自游戲類型來定, 總的一點, 效率瓶頸點, Update之類的, 盡量使用C#或者C++來實現(xiàn)
寫在最后
當前中國大環(huán)境下的玩家和各種氪金理由與純的不能再純的游戲人的基本愿望是沖突的
然而國外游戲的各種設計和機制, 暴雪戰(zhàn)網(wǎng)更新不及時, 版本不對沒提示, 這些基本錯誤在中國的網(wǎng)游都不會出現(xiàn)的
技術上無法趕英超美的我們, 在體驗上已經(jīng)輸出了我們的價值觀, 老外們都在學
對于程序員來說, 只是多貼近玩家, 多了解外面的世界而已