[长文]RMXP-SDK分析，说说这个东西究竟是什么

FantasyDR

先把结尾摘到前面来，以免有人看不完。

这是个人见解，长文。看完的都是好样的，我先orz了。此文不是推广SDK，而是希望大家能了解SDK试图解决问题的思路，毕竟SDK究竟是好是坏，RMXP一个业余的游戏制作工具是否犯得着弄这么复杂，还是个待回答的问题。老外有时候严谨的可爱，呵呵。

关于使用了SDK导致原先的脚本不能用的问题，大家不用再问了。单独一个SDK不能帮助你改善你的游戏系统，SDK只能对标记“SDK兼容”的脚本负责，其他脚本不兼容是正常的。所以如果你没有使用“SDK兼容”脚本，那么不要在你的脚本中插入SDK。为什么呢？看完下文或许就明白了……

1、SDK究竟是什么？
前段时间，BB崽把一个叫做RMXP SDK的东西发到了66论坛上面，我翻译了一下前面的代码书写约定，估计大部分人还是不明白究竟这个东西是要做什么。后来我到此文档的出处RMXP.net看了下发布原帖，然后阅读了一些脚本代码，大致明白了SDK公布的目的。

下面简单说一下，先贴一下老外原版说明：

Features:
The SDK is a rewrite of many of the default classes, a module with scripting tools and a set of scripting standards. The SDK is aimed at the combatable issues of many scripts fight over the same methods of the default classes. The SDK breaks up these methods into many other methods targeted directly at one function. The hope is that by breaking up these methods you limit the need to over write then whole method and can Alias just the area or function you want to add to or edit.

The SDK should NOT be edited and redistribute with out contacting a Member of the SDK Team. Edits to the SDK may cause massive capability errors and would defeat what we are trying to do here.

When you post a script you should state if it’s SDK compatible and what version it’s compatible with. A member of the SDK Team will review it and flag it to receive a SDK logo signifying that it is indeed SDK compatible. Questions regarding the SDK or making scripts SDK compatible should be directed to a SDK team Member.

这部分内容就解释了SDK究竟要来做什么。我的翻译文档里面有些地方也理解错了，导致有人说是程序员的洁癖。大致翻译一下这个内容，大概看完翻译内容应该会明白些东西：

SDK是对许多默认类的重写，也是一个带有脚本书写工具模块，并且定义了脚本书写规范。SDK目的是解决脚本间的冲突，这些冲突是因为使用了默认类里面相同的方法名称。所以，SDK将很多常用的方法分解成了许多部分，每部分针对一个单独的功能。对于小范围的功能更改而导致重写整个类的方法，这种行为会因为方法的分解而得到解决。

只有联系到SDK成员组的人员，你才可以修改或者重新发布SDK。因为修改往往导致兼容性问题，让我们现在的努力白费。

当你发布一个兼容SDK的脚本，某个SDK成员组人员会检查这个脚本，合格的话就会签发一个兼容性标志(也就是在论坛的脚本发布帖里面加个SDK图标)。

看完以上的文字，写过脚本的人就应该明白SDK的用途了。SDK的那堆文档里面，除了开头的名称为SDK的模块，其他的都是原版的脚本，没有经过内容上的更改。这些脚本只是把一些原来很长的方法拆开成一段一段的短小的方法。

也就是说，SDK是一个：靠人为强制规范化和手动审核来实现的全脚本兼容计划。发布一个脚本，如果希望兼容SDK，就需要按照SDK兼容要求来写，然后交给SDK成员组人员检查，他说没有问题了就签发SDK兼容标志。当然使用这些脚本的游戏里面必须首先插入SDK自身的脚本，也就是BB崽公布的那个RMXP SDK1.3.txt里面的东西。

2、SDK如何解决兼容性问题的？
比如，战斗的update方法很长，牵扯了各个过程。于是在SDK里面，这个方法被保持原样的拆开，比如拆成update_object,update_system等等有名称含义的段落。这样做的好处在于，人们需要加强或者重定义脚本的时候，只需要重写其中一小段就可以。那么，这样就可以最大限度的降低脚本的冲突。

原先官方RMXP已经自带了一套脚本，事实上后面大家书写的脚本都可以称为是“官方兼容”的，而由于官方不能做到人为审核，而且默认脚本里面有些方法实在是冗长，大家书写脚本的习惯又五花八门，所以这些“官方兼容”的脚本互相之间往往冲突。SDK希望解决这个问题，虽然个人觉得实在是个耗时耗力的工程，但是推广一下有助于RGSS规范化的发展，对Scripter的修养有好处。

那么“SDK兼容”的脚本之间就都可以无冲突使用了？这显然也是不可能的，毕竟功能重复的两个脚本肯定会冲突的。SDK只能避免通常情况的冲突，比如大家功能上相近，默认脚本里面的方法太冗长，导致代码段叠在一起，而SDK重定义了那些冗长的方法，拆开了代码段，可能就避免了这个问题。但是由于仍然存在冲突的可能性，所以才会有了SDK文档开头的那个模块。后面会详细说……

3、所谓的SDK里面带的脚本书写工具(Scripting tool)是什么？
SDK开头的那个名称为SDK的module，是用来解决一些公共问题的，应该也就是文档中提到的Scripting tool。
这里面有8个方法，前6个是关于“兼容SDK”的脚本如何被SDK控制。

首先是log方法，这个方法是向SDK的脚本列表，也就是一个数组里面添上要使用的脚本名称和作者信息等。这些信息会在其他方法上用到。
write则是将这个信息存到文件里面，print是以字符串的形式取出某个或者全部脚本信息。这些信息就是一个描述，不用看得太复杂，是兼容SDK的脚本作者自己写的。

然后是enable、disable、和state方法。这3个方法是一套的，控制一个被登记的兼容脚本有没有被启用。听起来SDK很神奇有这种功能，可以通过自己的方法来操作其他脚本。其实这还是一个人为的操作，因为每套“兼容SDK”的脚本都必须是这样格式：

SDK.log(&quotarticle Engine", "Near Fantastica", 1, "02.01.06") #把自己的信息添到那个数组里面。
if SDK.state(&quotarticle Engine") == true
#脚本内容
end

所以state变量如果为false，那么这段脚本就没有被执行到，也就失去功能。而SDK因为规定了这一点，所有正在使用的脚本都可以通过查看那个列表来找出，并且被控制。很巧妙的一个方法，但是仍然是很多人为的操作在里面，必须是脚本书写者遵循这样的写法才行，不是想象中的全自动的只要把SDK加上去其他的脚本就被控制了-_-b

最后有两个方法是比较有用的，前段时间翻译的时候没有领会，现在看过几个实例后多少理解了一些。因为自定义的一些脚本会遇到一些公共的问题，比如怎样和地图的事件产生关系，怎么控制地图事件，怎么获得输入的参数。所以这些方法定义了一套方便的公共途径：

text_box_input
这个方法是执行一段文本命令中的某一个指令。比如你可以定义一大堆指令，放在一个字符串里面，然后根据状态来选择执行。以前需要写一堆if或者switch结构，现在只需要这个方法和一个指令ID就可以。有人可能有这种需要吧～

event_comment_input(*args)
这个方法比较巧妙，从字面上理解就是，靠事件中的注释来获取信息。比如游戏中想控制某个事件，来触发自己自定义脚本里面的事情。再具体一点，比如挂了一个粒子系统，想给event01上加个火焰效果。以前的方式就是写脚本事件，在编辑器里面写RGSS。这样很不利于统一，以后改起来也不方便。脚本就应该写在RGSS里面～
那么现在，只需要给event01里面加注释事件，注释的内容是一个标志和你要的参数，比如&quotarticle System,Fire"。然后在Game的循环里面使用这个方法获取注释里面的内容，自己分析是不是应该开启粒子效果了。这样就隐藏了脚本实现的细节，事件编辑可以不需要写脚本。脚本处理的事情由Scripter在游戏循环内部完成。

以上内容可能很多人觉得烦琐，但是规范化有利于RGSS的发展。一个人的力量是有限的，只有众人的力量集合起来才能产生质的飞跃。而且好的游戏应该是多人合作的产物，术业有专攻，写脚本的细节应该被隐藏在另外的层面中，事件的应用应该更纯粹一些。

这是个人见解，长文。看完的都是好样的，我先orz了。此文不是推广SDK，而是希望大家能了解SDK试图解决问题的思路，毕竟SDK究竟是好是坏，RMXP一个业余的游戏制作工具是否犯得着弄这么复杂，还是个待回答的问题。老外有时候严谨的可爱，呵呵。

xavier

大致了解,
一个像"web标准"一样的"RGSS标准"一样的东西。

CountD

好像身为一个外行没资格说什么...=v=不过...
标准本身的完整和专业性决定实用度...总之都是一件累死人的工作啊...
对RGSSER来说按照这个标准来写也是比较麻烦的事情,...有点囚徒困境的感觉.
而且如果是具体的合作,一般负责的都是不同的模块,还不至于冲突.
这个应该是为了大范围使用推广而设计的吧.
但是即使是这样,有一个统一的标准增加可读性也不错.
其实...还想说...EB当时推出RGSS的时候就应该附带一套官方标准才对嘛,哪怕是推荐标准,也会有一定影响...
可是从我对RGSS不多的了解看来...实在是相当不敬业啊...

PS:Arrow - 定义Arrow（？）的类<=选择光标这个是....
基本不懂的看完了...标准相当完善的样子,不过很多强制性的味道太浓了...
估计要100%遵守非常不容易,除非成为彻底的习惯...=v=

PS的PS:如果真的推广这个,以后估计会出现...
发布脚本需要根据官方的原件写一套,然后根据SDK标准写一套...><

PS的PS的PS:其它的好处还是有的,如果把原来的大段代码继续拆分,对新手来说可能更容易修改.
比较好学习吧.
不过英文的注释...orz...
那么大段E文,连我都看着晕,FDR君...辛苦了...

yoxola

現在只用純C編東西，而使用Lua作為腳本擴充原件，
這個可以作為規範性的參考，我打算以同樣思路修改winVerge這個RPG引擎，
讓國人有更多選擇

FantasyDR

Verge么？

一直没有敢细看的一个东西。似乎可视化编辑的工具很少，但是引擎功能却不弱，而且有n多国外的玩家在使用它制作Demo和同人游戏：）

yoxola

是的，可以直接從這裡得到Verge3的完整源碼

http://verge-rpg.com/files/detail.php?id=651

FantasyDR

竟然是VS.net 2005的工程文件-_-
老外跟进的速度也很快哈。

手动添加ing...

[Edit]突然发现原来有旧版本工程文件。寒。打开了～～：）

[Edit2]以前有下载过引擎，没有下载过源码。因为Verge的引擎结构不是完全OO的，所以感觉有点无从下手，而且曾一度以为Verge是个RPG图像函数库……呵呵。

Verge要是发布引擎的时候配上一套不错的可视化开发环境，然后再配一个详尽的文档就好了。它的文档都在web上面。不过，毕竟不是商业软件，强求这些就难为作者了。期待yoxola的工作了：）