目的：

构思GSML的目的，是希望减少创意→实现的中间环节。最终目标是，剧本师只要按特定标准书写剧本，就可经过一个脚本处理，直接将剧本内容导入到游戏里。如实现自动生成NPC、战斗处理、场景移动等等的诸多问题。这样就完全不用在写完剧本后再去慢慢编写各种事件(这些实际上这些事件基本一样，完全可以归纳为几个基本模板)

灵感来源：

看一个别人写的剧本，里面为了表述用到了不少符号做标记，加之当时正烦游空缺乏人手，一直在想能不能把一些工作交给程序处理，结果就有了这个玩意的想法。

说明：剧本标记语言，本质上是个SDL(领域特定语言)。

基本构成：

语法、解析器、事件生成器。前两者在语言定义时提供。后者则需要使用者来编写。

在实际操作中，GSML将有这几个部分构成：剧本文件、链接文件、API、事件生成函数。

剧本文件：按特定语法编写的剧本，有脚本师给出。

链接文件：用来反映剧本对象和游戏对象间的映射关系，以及事件生成时的相关配置(这一部分也可独立出来形成配置文件)。

API(解释器)：一套用来处理剧本文件的函数接口，读取剧本文件然后返回某种数据结构的数据。其本质是一个语言的解释器。

时间生成函数(事件生成器)：用来根据链接文件把剧本文件经由API处理返回的数据转换成对应游戏里的具体事件对象。

说明：对于不同架构模式的游戏，语法和解释器是通用的，而事件生成器则需要按实际情况来编写实现。对于链接文件，其结构极可能也需要随着架构模式的不同而作相应的变动。

需考虑的问题:剧本文件不仅仅是面对机器，同时还有面对人的部分，其编写人员也难有编程语言基础，所以要考虑语法的简洁和易读性。

语法说明：作为标记语言，其基本元素为各种标签(实际上完全可以基于XML来架构一个，然而基于XML的结果是得在剧本里加入一堆"<"、">"这样的符号。既不利于阅读写起来也很麻烦。)和控制符。

目标：以rm为环境，编写语法、解析器、事件生成器。这样考虑的原因有两点：1、rm有较为成熟的事件系统。2、个人比较熟悉Ruby的语法。

价值：1、减少一些游戏制作的中间环节，减少人力开支，将枯燥的大量重复性工作交由电脑完成。2、将剧本和游戏内部对象分离，模块化，易于修改和维护(如为游戏提供多语言版本或游戏翻译)。