谈谈AVG游戏的Android移植（NScripter与吉里吉里）

大家好，很久不见，小弟最近闭关修炼iPhone中，所以很长时间没更新博文（顺便在写某物的C++版，另外某物0.3.2版与WP7版已构建完成，不久就会发布）。这次回来，先换个与某物无关的话题，以目前用户量最大的NScripter（简称NS，以下同）与Krkr2（吉里吉里2）为代表，来简单谈谈 AVG游戏的Android环境移植吧。

______________

关于NScripter的Android版移植：

ONS和SDL：

大家都知道，日本人高桥直树是NScripter项目的发起者。

然而，事实上高桥直树开发的原始版NS程式早在09年就已经停止了更新，现今已很难再看见利用原版NS开发的程式。那么，NS为何还能有现在这么庞大的用户支持率呢？答案很简单，一切都要归功于ONS的存在。应当说，目前应用最广，也是真正让NS脚本发扬光大的，还要数第三方制作的ONScripter，这一完整支持NS脚本的跨平台AVG引擎不可（简称ONS，以下同）。

单独从编程角度上讲，ONS不等同于NS，由于高桥氏开发的NS程式并没有开放源码，因此ONS是通过黑盒方式参考NS效果自行模拟出的ONS功能（这个过程有点像制作游戏机模拟器），所以它并不是一个代码移植品，而应视同一个独立于NS原版的新型NS脚本解释与执行器。除了能解读同样的游戏脚本外，它与 NS就没有任何程式上的继承关系。

ONS相比较NS的最大优势在于，ONS和完全依赖DirectX渲染仅支持Windows系统的NS不同，它采用了一代神人Slouken制作的SDL框架进行脚本与计算机设备交互，天生具备SDL框架“骇人听闻”的跨平台移植能力。

无论是windows、linux、mac抑或PSP、PS3、PS2gs乃至wince、iphone、ipod、android平台都能看到它活跃的身影（当然，这需要相关的本地运行库配合，比如从渲染角度上讲，在Windows绘制画面既可以使用SDL提供的DirectX封装又可以使用OpenGL 封装，而到了Linux环境就只能使用OpenGL库，到了智能机或者掌机环境就要转到OpenGLES库，这些都必须有人提供相关的本地化封装，然后才能通过统一的API进行调用。即便所写代码在API层面高度一致，但在不同环境中的具体实现依旧是有差异的。也就是说，如果某个平台并没有必要的运行库支持，那么SDL也无法在该平台编译与运行。而SDL的强悍就体现在，它所提供的本地运行库相当完整，几乎涵盖了所有主流系统，兼容性却又相当优异）。

凭借这种优势，目前大家所见的，绝大多数使用NS脚本开发的AVG游戏（或者狭义的指galgame），大多是以ONS而非原版NS作为运行环境——在掌机和智能机上尤其如此。

可以说，没有SDL的成功，就没有今天的NS（ONS）的辉煌。

这里吐个槽，前一阵小弟在某书店读到某Android教程，其中以NDK5编译了某版本的《雷神之锤》，而后就反复强调NDK移植C/C++游戏是多么方便，多么简单之类的。小弟以为，这种说法实在有些忽悠了。众所周知，网上能找到的开源版《雷神之锤》（http://www.libsdl.org/projects/quake/），使用的就是SDL这个目前世界上兼容性最强的跨平台引擎（而SDL子项目http://libsdl-android.sourceforge.net/，早已提供了SDL与Android设备的完整交互支持）。因此，即便NDK5能正常编译SDL开发的游戏，也只能证明NDK5的基本功能正常（Android好歹也是Linux核心，如果SDL在上面都跑不起来，让Google情何以堪啊），却无法理解成NDK开发有多么便捷，更不能代表所有 C/C++游戏都能轻松移植到Android环境当中（此前小弟曾和某友谈及怎么常有人能把DOS游戏移植到Android环境中运行的问题，小弟在此粗谈两点：一、世上有个开源项目叫DosBox，能够跨平台模拟标准DOS运行环境。二、DosBox是以SDL为核心开发的），就别提完全取代Java开发模式了。

我们登录http://onscripter.sourceforge.jp，就可以获得关于标准版ONS的详细介绍与各版本下载路径。

至于ONS-Android，则是由ONS作者提供的，完全实现了ONS功能的，专门用于跑在Android平台的ONS版本。如果您要在Android上进行NS游戏移植，首先就离不开ONS-Android的下载与编译。

ONS-Android的编译：

ONS-Android的编译，仅需要如下步骤就可以做到。

1 下载SDL的Android版扩展库

由于标准版SDL源码包中尚未包括Android本地化支持，所以我们需要单独下载Android版SDL源码包，才能在Android环境中正常编译与运行SDL程序。事实上，所有想使用SDL以C/C++方式开发Android游戏的用户，也会需要这个SDL运行库的支持。

下载地址：http://libsdl-android.sourceforge.net/

（PS： ONScripter-Android内置已是这个运行库，不必真正下载，此处仅说明来源）。

2 下载Android版ONScripter

下载地址：http://onscripter.sourceforge.jp/android/onscripter_android.tar.gz

由于ONS-Android采用JNI方式，进行C/C++部分与Java部分的交互，因此下载后的源代码也就同时包含了java（功能集中在游戏载入，界面初始化与JNI调用）与纯C（sdl-android支持库）两大部分的源码。

不过，真正解释执行NS脚本的ONScripter本体（C++实现）这时却并没有包含在内（估计是作者考虑到ONScripter核心代码是所有平台共通的，才没有直接放入ONS-Android当中）。

现在，我们还需要下载ONScripter的核心源码部分，才能真正进行ONS-Android编译。

3 下载标准版ONScripter

下载地址（也可选其它版本）：http://onscripter.sourceforge.jp/onscripter-20110619.tar.gz

好了，编译ONS-Android的要素全部齐备了。

现在，将最后下载的ONS核心源码解压，并放入onscripter_android的jni\application文件夹下（建议解压时不要改名，因为 ONS的Android.mk配置里默认就是编译onscripter*下文件，改名很可能导致找不到目标文件（除非您重写了Android.mk配置））。

这时，我们只要通过NDK编译onscripter_android项目，就能立刻得到相关的so文件了（累计将编译出九个文件，其中只有libapplication.so为ONS运行库，其余为SDL支持库），相当之简单吧？

下图为通过Cygwin在Windows中编译ONS的画面。
 

可以说，只要系统环境设定正常，原始ONS-Android配置已可保证编译成功。假如在编译时提示找不到某某文件，则说明环境变量中缺少必要的系统支持库路径，并非onscripter_android源码不全，请自行在Android.mk添加相关路径或者修改Cygwin环境配置，具体请参考NDK开发文档或Cygwin使用文档（当然，直接Ubuntu编译最简单）。

编译成功后，获得的so文件列表：

 

有了so支持库与Java代码，任何稍有Android（或Java）开发经验者，都能轻易将NS游戏运行于Android系统之上。

ONS-Android的汉化问题：

出于众所周知的原因，ONS-Android默认并不支持中文编码（它是日本人做的）。这样的设计，在使用原版ONS-Android运行日文游戏时并不会有太大问题（只要该游戏没有调用第三方插件，没有使用额外API）。但是，一旦我们想要让它跑一些经过汉化的中文编码游戏呢？显而易见，肯定会造成乱码的出现。

所以，如果我们想要ONS-Android能够正常地进行中文游戏显示，在进行ONS-Android编译时，便需修改其部分代码。更准确地说——是修改位于ONS核心包下的sjis2utf16.cpp文件来解决这一问题。

总体来讲，ONS的字符解码过程并不复杂，sjis2utf16.cpp中仅有initSJIS2UTF16（初始化解码表到sjis_2_utf16这一数组中）、convSJIS2UTF16（转化日文编码SJIS为UTF-16编码）、convUTF16ToUTF8（转化UTF-16为UTF-8编码）这三个函数在起作用。而ONS的所有字符解码部分也会经由调用convSJIS2UTF16和convUTF16ToUTF8这两个函数产生作用（注意，initSJIS2UTF16是sjis_2_utf16变量初始化赋值时使用的函数，仅会在ONS启动时调用一次）。

知道了这些，解决汉化问题就变得非常简单，只要根据现有的ONS解码规则，将其sjis_2_utf16_org数组中的SJIS日文编码表转化为我们需要的中文编码表（GBK也好，Big5也好，原理都一样，一个指定编码对应一个相对的UTF-16编码，然后以二维数组形式保存），就能够非常轻松的实现 ONS中文解码，甚至不需改写任何逻辑代码（如果有某些字符需要特殊过滤，也可以修改convSJIS2UTF16和convUTF16ToUTF8这两个函数进行拦截）。编码表较大，下文有相关下载地址。

当然，如果我们想保留原版sjis2utf16.cpp内容也没问题，大可以新建一个gbk2utf16.cpp之类的文件，让两套解码器并行存在，按需求进行切换（比如想根据手机环境自适配字符解码器）。怎么做呢？粗读ONS源码我们可以发现，它实际调用到字符解码器的部分，仅集中于DirectReader.cpp和 ONScripterLabel.cpp、ONScripterLabel_text.cpp这三个源文件当中。具体的说，在于DirectReader 中的convertFromSJISToUTF8函数（其中同时调用了解码器的convSJIS2UTF16与convUTF16ToUTF8函数。 PS：该文件中还有convertFromSJISToEUC函数，是给资源文件名解码的，如果文件名中没有稀奇古怪字符的话原则上可以忽视不管，如果有的话也需要进行适当修改），以及ONScripterLabel_text.cpp中的drawGlyph函数（调用convSJIS2UTF16）和 ONScripterLabel中的initSDL函数（调用initSJIS2UTF16）。如果想自适配解码器，只需创建出相关的解码用函数（放在 gbk2utf16.cpp、big52utf16.cpp随便什么中原理都一样，改个编码表而已），继而通过最简单的if……else……判定即可（如果想根据编译环境判定，直接#if defined也行）。

总之，ONS中文解码并不是什么复杂的问题，汉字编码表可以去http://unicode.org查询，或者参考Emacs项目提供的map文件（下载一个Emacs，解压后它的etc/charsets文件夹下全是后缀为.map的编码表）。还有，很久以前有人用google code发布过ONS的gbk解码版本（http://onscripter-cn.googlecode.com/svn/trunk/），有需要的朋友可以从svn下载过来参考。


ONS-Android的运行机制：

单从Java编程角度来说，ONS-An