刚才看了老G同学人肉推送的博文 基于C++ 和JavaScript的全平台全栈式游戏开发解决方案的思考 ，想了想，应该把自己的想法也分享下。


游戏的脚本一直是个比较热的话题，涉及了游戏开发的方方面面，从开发到运营，大家都在说，似乎不用脚本就不够高大上了。但是，如何用，用什么，到什么程度，每个人都有一个自己的说法。


先从脚本谈起，游戏里面使用脚本，最主要的是几个方面的好处：

  1. 提高开发效率。脚本一般可以快速开发，和本地代码相比，脚本一般学习门槛比较低，功能比较简单，可以交给策划或者临时拉个人来编写，高端一点，可以直接用编辑器来生成，大量节约程序员的时间。

  2. 方便部署。可以方便的进行游戏内更新，而不需要经常更新游戏本身。这就非常适合app store的部署策略。


一般，游戏里面用的脚本，大致可以分成几类：

  • 编译型静态脚本   这类脚本一般是编译成本地机器码，静态链接到系统中，不适合动态使用，运行速度飞快。其实已经接近于语言了，一般存在于跨平台的方案中，使用同一种脚本，可以生成不同的平台代码。

  • 解释型编译脚本   这类脚本最后生成了特定的字节码，系统通过解释这些字节码来执行，可以动态加载，速度较慢。但是因为编译字节码可以做一些优化。

  • 纯解释型脚本    这类脚本直接动态读入，系统一边解释，一边执行。效率低，但是可以即时修改。

  • 编译型动态脚本  这类脚本一般是编译成本地机器码，系统运行时，直接把程序指针跳转到脚本本地码上执行，类似于动态链接库

实际上，现在的脚本系统一般都支持上面的一种或几种模式，可以提供不同的方案。


脚本能干啥，其实脚本能做任何事情，无非就是代价的大小。和本地代码比较，脚本的劣势：

  • 脚本一般是弱类型的语言，追求快速开发，所以，很多问题没办法在编译器发现，会延迟到运行期。

  • 脚本一般没有很强大的调试器，所以调试永远是脚本的坑。

  • 脚本编写人员一般水平都不如写本地代码的，所以经常有一些坑爹的写法，让人欲仙欲死。

  • 脚本一般没有一些请打的本地功能，所有的这些都需要宿主系统提供，所以脚本支持也是脚本的一个软肋。



了解了这些，很多时候其实就已经有了评判的标准。

用什么样的脚本系统，需要评估一下，开发人员的水平，工具支持，运维部署的特点综合考虑下。


最后给出一些我的建议：

  • 游戏里面尽量选择一些简单的脚本系统，华丽的脚本其实非常接近于程序语言了，一般策划搞不定，还得程序来弄，考虑效率啥的那还不如本地代码

  • 不要以为脚本是万能的，啥都用脚本，一般涉及业务逻辑的建议用脚本，稳定而通用的尽量用本地代码实现

  • 脚本的调试比较麻烦，所以尽量小心使用。

  • 脚本其实还是跑在同一个设备里的，所以针对本地代码的限制同样适合于脚本，不要以为脚本就可以无视内存大小什么了。

  • 脚本毕竟只是脚本，多学点编程，对脚本开发一样有好处的。