關于游戲腳本開發解決方案的思考

剛才看了老G同學人肉推送的博文 基于C++ 和JavaScript的全平臺全棧式游戲開發解決方案的思考 ，想了想，應該把自己的想法也分享下。

游戲的腳本一直是個比較熱的話題，涉及了游戲開發的方方面面，從開發到運營，大家都在說，似乎不用腳本就不夠高大上了。但是，如何用，用什么，到什么程度，每個人都有一個自己的說法。

先從腳本談起，游戲里面使用腳本，最主要的是幾個方面的好處：

1. 提高開發效率。腳本一般可以快速開發，和本地代碼相比，腳本一般學習門檻比較低，功能比較簡單，可以交給策劃或者臨時拉個人來編寫，高端一點，可以直接用編輯器來生成，大量節約程序員的時間。

2. 方便部署。可以方便的進行游戲內更新，而不需要經常更新游戲本身。這就非常適合app store的部署策略。

一般，游戲里面用的腳本，大致可以分成幾類：

• 編譯型靜態腳本   這類腳本一般是編譯成本地機器碼，靜態鏈接到系統中，不適合動態使用，運行速度飛快。其實已經接近于語言了，一般存在于跨平臺的方案中，使用同一種腳本，可以生成不同的平臺代碼。
  

• 解釋型編譯腳本   這類腳本最后生成了特定的字節碼，系統通過解釋這些字節碼來執行，可以動態加載，速度較慢。但是因為編譯字節碼可以做一些優化。

• 純解釋型腳本    這類腳本直接動態讀入，系統一邊解釋，一邊執行。效率低，但是可以即時修改。

• 編譯型動態腳本  這類腳本一般是編譯成本地機器碼，系統運行時，直接把程序指針跳轉到腳本本地碼上執行，類似于動態鏈接庫

實際上，現在的腳本系統一般都支持上面的一種或幾種模式，可以提供不同的方案。

腳本能干啥，其實腳本能做任何事情，無非就是代價的大小。和本地代碼比較，腳本的劣勢：

• 腳本一般是弱類型的語言，追求快速開發，所以，很多問題沒辦法在編譯器發現，會延遲到運行期。

• 腳本一般沒有很強大的調試器，所以調試永遠是腳本的坑。

• 腳本編寫人員一般水平都不如寫本地代碼的，所以經常有一些坑爹的寫法，讓人欲仙欲死。

• 腳本一般沒有一些請打的本地功能，所有的這些都需要宿主系統提供，所以腳本支持也是腳本的一個軟肋。
  

了解了這些，很多時候其實就已經有了評判的標準。

用什么樣的腳本系統，需要評估一下，開發人員的水平，工具支持，運維部署的特點綜合考慮下。

最后給出一些我的建議：

• 游戲里面盡量選擇一些簡單的腳本系統，華麗的腳本其實非常接近于程序語言了，一般策劃搞不定，還得程序來弄，考慮效率啥的那還不如本地代碼

• 不要以為腳本是萬能的，啥都用腳本，一般涉及業務邏輯的建議用腳本，穩定而通用的盡量用本地代碼實現

• 腳本的調試比較麻煩，所以盡量小心使用。

• 腳本其實還是跑在同一個設備里的，所以針對本地代碼的限制同樣適合于腳本，不要以為腳本就可以無視內存大小什么了。

• 腳本畢竟只是腳本，多學點編程，對腳本開發一樣有好處的。