剛纔看了老G同學人肉推送的博文 基於C++ 和JavaScript的全平臺全棧式遊戲開發解決方案的思考 ，想了想，應該把自己的想法也分享下。
遊戲的腳本一直是個比較熱的話題，涉及了遊戲開發的方方面面，從開發到運營，大家都在說，似乎不用腳本就不夠高大上了。但是，如何用，用什麼，到什麼程度，每個人都有一個自己的說法。
先從腳本談起，遊戲裏面使用腳本，最主要的是幾個方面的好處：
提高開發效率。腳本一般可以快速開發，和本地代碼相比，腳本一般學習門檻比較低，功能比較簡單，可以交給策劃或者臨時拉個人來編寫，高端一點，可以直接用編輯器來生成，大量節約程序員的時間。
方便部署。可以方便的進行遊戲內更新，而不需要經常更新遊戲本身。這就非常適合app store的部署策略。
一般，遊戲裏面用的腳本，大致可以分成幾類：
編譯型靜態腳本 這類腳本一般是編譯成本地機器碼，靜態鏈接到系統中，不適合動態使用，運行速度飛快。其實已經接近於語言了，一般存在於跨平臺的方案中，使用同一種腳本，可以生成不同的平臺代碼。
解釋型編譯腳本 這類腳本最後生成了特定的字節碼，系統通過解釋這些字節碼來執行，可以動態加載，速度較慢。但是因爲編譯字節碼可以做一些優化。
純解釋型腳本 這類腳本直接動態讀入，系統一邊解釋，一邊執行。效率低，但是可以即時修改。
編譯型動態腳本 這類腳本一般是編譯成本地機器碼，系統運行時，直接把程序指針跳轉到腳本本地碼上執行，類似於動態鏈接庫
實際上，現在的腳本系統一般都支持上面的一種或幾種模式，可以提供不同的方案。
腳本能幹啥，其實腳本能做任何事情，無非就是代價的大小。和本地代碼比較，腳本的劣勢：
腳本一般是弱類型的語言，追求快速開發，所以，很多問題沒辦法在編譯器發現，會延遲到運行期。
腳本一般沒有很強大的調試器，所以調試永遠是腳本的坑。
腳本編寫人員一般水平都不如寫本地代碼的，所以經常有一些坑爹的寫法，讓人慾仙欲死。
腳本一般沒有一些請打的本地功能，所有的這些都需要宿主系統提供，所以腳本支持也是腳本的一個軟肋。
瞭解了這些，很多時候其實就已經有了評判的標準。
用什麼樣的腳本系統，需要評估一下，開發人員的水平，工具支持，運維部署的特點綜合考慮下。
最後給出一些我的建議：
遊戲裏面儘量選擇一些簡單的腳本系統，華麗的腳本其實非常接近於程序語言了，一般策劃搞不定，還得程序來弄，考慮效率啥的那還不如本地代碼
不要以爲腳本是萬能的，啥都用腳本，一般涉及業務邏輯的建議用腳本，穩定而通用的儘量用本地代碼實現
腳本的調試比較麻煩，所以儘量小心使用。
腳本其實還是跑在同一個設備裏的，所以針對本地代碼的限制同樣適合於腳本，不要以爲腳本就可以無視內存大小什麼了。
腳本畢竟只是腳本，多學點編程，對腳本開發一樣有好處的。