我站在程序员的立场上看待脚本。

lights

我曾经开发过商业游戏。
策划整天到晚把脚本挂在嘴边，好像离了脚本就不能活一样。
甚至还按照他自己的想法写了一段脚本，让我实现。
但当我拿出了我的实现方法，他最后还是放弃了。

      程序的整体控制流程 和 一般脚本写出来比较相似。
      所以脚本和程序之间的距离比策划案和程序之间的距离小很多，所以比起直接设计策划案，设计脚本似乎简单一点。
      可是实现脚本，程序员需要相当的编译原理方面的知识，而且越好越详实的脚本，实现起来越复杂。试想，策划想象中的工作方式是他都已经设定好了程序的流程，程序员只要实现就好了，而且经常自以为是的在自己的脚本中加入结构控制、跳转、事件、属性等程序因素。而把程序员仅仅当做一个脚本编译器，肯定是不现实的。
      但策划的梦想实现了以后，就是另外一回事了，写好脚本，加入素材，编译，游戏成品。是很完美，可是目前还没有这样直接编译脚本成为游戏的好事吧！
      大家请注意，脚本产生的根本目的是拉近甚至消除策划与程序之间的距离。但过分依赖脚本，只会拉大这个距离，请充分的考虑程序的意见和实现难度。
      应该说，脚本是一种无形的东西，他应该是策划案的具体描述，而不该是写在某个文本文件里的一大串文字。

      我的实现方法是先针对策划案进行合理的化分，然后针对不同的模块写不同的编辑器。编辑器的可视化和可调试程度都比一般的脚本要强。而且最后生成什么样的文件，和编辑过程中的控制都在程序员的控制之中，策划的想法通过程序员修改编辑器，这样可以增进协调度和程序的稳定性。我在大明英烈传中产生了动画编辑器、剧情编辑器、人物编辑器、战场编辑器、字幕编辑器等等的编辑器。主程序完成后所有人都可以很简单的从头至尾改变游戏。