关于脚本
一些关于脚本的琐碎的思绪。
如果说Programming Language是对应基础框架以及底层兼容的偏硬性问题的解决方案，那Script Language便是某种意义上真正面向应用功能的解决方案。Programming Language的初衷是调用平台的各种资源与功能，为了达到最好的效果往往都是贴近底层开发的，在这方面“硬”的东西比较多，而且一旦敲定，便不会容易修改。简而言之，Hardcode大概就是这样一种意思。
太硬的东西无论是开发者还是客户都所不愿意见到的，他们不希望自己买了一辆自行车，轮子只能转到100圈，除非他们都是2B。
于是乎有一种叫Data Driven的概念出现了。大约来讲它属于已经被Hardcode编译成计算机本地指令的程序的外部配置信息。程序的代码已经实现了开发过程中能够预见的大多数功能，这些功能可以接收一定的可变的参数来达到一定程度的“动态性”。这基本上是目前绝大多数项目的一种比较统一的解决方案，无论是application，service或者game。
这种开发模式有一个比较重要的平衡点需要掌握：我们需要将多少功能给做出来，又需要将多少功能可以进行外部的配置。前者过多就会导致过多的硬编码，而后者过多就会导致过于零散的功能以及过于复杂的配置。
无论如何，硬编码是我们是在不想看到的，但是如果功能做得过于原子化，那外部的配置必然会相当复杂。要知道在一个团队里面，负责这部分数据生产的不一定都是城续猿。
有时候我们不能太明白的说明，我们到底想要一个什么样具体的功能，城续猿没办法做出一个抽象的模棱两可的功能然后再暴露一些有限的参数供团队里面其他成员使用，而后者往往也说不清楚自己到底想要什么样的东西。但就算双方能达成协议，通过修改代码来实现新功能以及调试的代价往往也是比较昂贵的。
那么，为何不让他们自己去做？
于是我们需要一种，简单，可用，且能比较高效开发的方式 —— 脚本。
理论上来讲脚本也是一种编码语言，它同样有分支，有循环，有变量，只不过其所在的层次不一样。脚本其实也是Data Driven里面的数据，只不过与单纯的贴图，动画，音效等纯数据相比它更有一种自我描述性。换言之它们能自己说明自己的目的，而不是简单的被贴到某个设置好了UV的模型上面去。
城续猿可以做好一系列的相对独立的功能，这些功能之间可以拼凑组合，相互调用，往往我们会将它们称之为API，最终它们会暴露给脚本使用。
在此基础上，如果说通过Programming Language实现的框架模型是“第一次开发”，那么通过Script Language我们可以在项目中进行“第二次开发”。这也就是一种理想的“准备阶段”往“生产阶段”过渡的方式。案例例如游戏中各种角色的AI，任务，界面UI等等。
待续…