關於遊戲腳本開發解決方案的思考

剛纔看了老G同窗人肉推送的博文 基於C++ 和JavaScript的全平臺全棧式遊戲開發解決方案的思考 ，想了想，應該把本身的想法也分享下。

遊戲的腳本一直是個比較熱的話題，涉及了遊戲開發的方方面面，從開發到運營，你們都在說，彷佛不用腳本就不夠高大上了。可是，如何用，用什麼，到什麼程度，每一個人都有一個本身的說法。

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

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

2. 方便部署。能夠方便的進行遊戲內更新，而不須要常常更新遊戲自己。這就很是適合app store的部署策略。

通常，遊戲裏面用的腳本，大體能夠分紅幾類：

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

• 解釋型編譯腳本   這類腳本最後生成了特定的字節碼，系統經過解釋這些字節碼來執行，能夠動態加載，速度較慢。可是由於編譯字節碼能夠作一些優化。

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

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

實際上，如今的腳本系統通常都支持上面的一種或幾種模式，能夠提供不一樣的方案。

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

• 腳本通常是弱類型的語言，追求快速開發，因此，不少問題沒辦法在編譯器發現，會延遲到運行期。

• 腳本通常沒有很強大的調試器，因此調試永遠是腳本的坑。

• 腳本編寫人員通常水平都不如寫本地代碼的，因此常常有一些坑爹的寫法，讓人慾仙欲死。

• 腳本通常沒有一些請打的本地功能，全部的這些都須要宿主系統提供，因此腳本支持也是腳本的一個軟肋。
  

瞭解了這些，不少時候其實就已經有了評判的標準。

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

最後給出一些個人建議：

• 遊戲裏面儘可能選擇一些簡單的腳本系統，華麗的腳本其實很是接近於程序語言了，通常策劃搞不定，還得程序來弄，考慮效率啥的那還不如本地代碼

• 不要覺得腳本是萬能的，啥都用腳本，通常涉及業務邏輯的建議用腳本，穩定而通用的儘可能用本地代碼實現

• 腳本的調試比較麻煩，因此儘可能當心使用。

• 腳本其實仍是跑在同一個設備裏的，因此針對本地代碼的限制一樣適合於腳本，不要覺得腳本就能夠無視內存大小什麼了。

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