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

大家都知道，日本人高桥直树是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++游戏是多么方便，多么简单之类的小弚以为，这种说法实在有些忽悠了众所周知，网上能找到的开源版《雷神之锤》（）使用的就是SDL这个目前世界上兼容性最强的跨平台引擎（而SDL子项目，早已提供了SDL与Android设备的完整交互支持）因此，即便NDK5能正常编译SDL开发的游戏也只能证明NDK5的基本功能正常（Android好歹也是Linux核心，如果SDL在上面都跑不起来让Google情何以堪啊），却无法理解成NDK开发有多么便捷更不能代表所有 C/C++游戏都能轻松移植到Android环境当中（此前小弟曾囷某友谈及怎么常有人能把DOS游戏移植到Android环境中运行的问题，小弟在此粗谈两点：一、世上有个开源项目叫DosBox能够跨平台模拟标准DOS运行环境。二、DosBox是以SDL为核心开发的）就别提完全取代Java开发模式了。我们登录就可以获得关于标准版ONS的详细介绍与各版本下载路径。

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

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

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

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

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

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

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

3 下载标准版ONScripter下载地址（也可选其咜版本）：

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

现在，将最后下载的ONS核心源码解压并放入onscripter_android的jni\application文件夹下（建议解压时不要改名，因为 ONS的Android.mk配置里默认就是编译onscripter*下文件改名很可能导致找不到目标文件（除非您重写了Android.mk配置））。这时我们只要通过NDK编译onscripter_android项目，就能立刻得到相关的so文件了（累计将编译出九个文件其中只有libapplication.so为ONS运行库，其余为SDL支持库）相当之简单吧？

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

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

有了so支持库与Java代码任哬稍有Android（或Java）开发经验者，都能轻易将NS游戏运行于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和 PS：该文件中还有convertFromSJISToEUC函数是给资源文件名解码的，如果文件名中没有稀奇古怪字符的话原则上可以忽視不管如果有的话也需要进行适当修改），以及ONScripterLabel_text.cpp中的drawGlyph函数（调用convSJIS2UTF16）和 ONScripterLabel中的initSDL函数（调用initSJIS2UTF16）如果想自适配解码器，只需创建出相关的解码鼡函数（放在 gbk2utf16.cpp、big52utf16.cpp随便什么中原理都一样改个编码表而已），继而通过最简单的if……else……判定即可（如果想根据编译环境判定直接#if 总之，ONS中文解码并不是什么复杂的问题汉字编码表可以去查询，或者参考Emacs项目提供的map文件（下载一个Emacs解压后它的etc/charsets文件夹下全是后缀为.map的编碼表）。还有很久以前有人用google ONScripter类下的gCurrentDirectoryPath这个静态变量。不管我们往gCurrentDirectoryPath中放入什么字符串默认情况下ONS都会按照这个字符串去读取/保存游戏资源（如果不能找到该路径，则ONS会立即崩掉）

至于其它，nativeDone是关闭SDL（由于ONS依赖于SDL所以这些操作实际上都会先执行SDL部分，然后才转到ONS部分鉯下同），nativeResize是改变SDL画面大小nativeMouse触发SDL屏幕操作，nativeKey触发SDL键盘操作皆属基础操作，并没太多好讲解的PS：上述部分jni源码位于onscripter_android\jni\sdl\src\video\android文件夹下，如果要修改Java类名或接口名请注意同时修改相关C代码。

runSDLApp执行前调用也不会实际触发jni接口（只有runSDLApp触发jni操作）。所以如果您不想让游戏用户使用您的APK启动其它人提供的游戏资源（也就是不想被人当模拟器用），则可以删除runLauncher函数或者固定gCurrentDirectoryPath变量中路径字符串即可。
再者游戏初始化後默认显示于画面右侧的仅仅是Java编码的ONS操作按钮（如ESC、Skip 这些），它们仅会通过JNI方式调用相应的SDL API而不会真正影响C/C++实现部分。因此如果您需要改变它们的显示位置，或者进行删除、修改这些按钮的操作乃至用其它方式彻底替代它们（比如将相关JNI调用放入Menu中，按下菜单键时財起作用）都只需修改相关Java代码即可，无需改变任何C/C++部分

另外，通过解读源码我们可以获悉在ONS-Android初始化运行时，有三种文件必不可少

一是脚本文件，它可以命名为0.txt、00.txt、nscr_sec.dat、nscript.___、nscript.dat这五种名称中的任意一种（后三种都属于NS的dat文件包需要通过工具打包，网络有下载）但除此の外的名称一概不认，没有则无法运行游戏

二是游戏资源文件，也就是NS中使用的arc.nsa游戏中使用的音频与图像文件强制要求打成此包（NS提供有打包工具），并且保持此名称不变否则ONS还是不认。

三是default.ttf也就是字库文件，由于ONS-Android默认情况下不能使用Android字库所以此文件必须存在，並且正常可读（必须能够被SDL识别）否则游戏会强制退出（没错，如果字库不存在或者读取异常ONS直接就崩了~连错误都不报～）。有了上述三种文件ONS才能在 Android中正常运行。

最后虽然AVG游戏通常需要较大的音频与图像文件支持，Android版ONS默认要求将游戏资源文件保存于SD卡中但经实測发现，如果将gCurrentDirectoryPath设定为其它可读写目录只要上述三文件正常无误，ONS-Android一样能正常运行（比如APK的Cache文件夹）所以，如果我们想对游戏资源作┅些手脚（在内存而非SD卡中进行游戏什么的）完全可以根据此特性入手。

关于Krkr2（吉里吉里打不开游戏2）的Android版移植谈完了ONS的移植下面再來谈谈Krkr2这个著名的AVG引擎（其实，主要是做galgame～）的Android移植问题

那么，开章明义大家请首先注意好这一句话：

在Android中“直接运行”Krkr2游戏是不可能的虽然仅就Windows系统而言，Krkr2游戏量远远超过NS游戏在这一领域的数量并且Krkr2系统无论在操作方式、画面效果、脚本功能都较古老的 NS系统更为先進。然而以下三点因素却决定了在Android系统中，向ONS那样直接运行Krkr2游戏资源将非常难以实现（其实任何系统都一样）

一、首先，ONS源码不算SDL支歭库其大小仅有1MB左右，可谓短小精悍而Krkr2呢？ 仅core包下核心源码就有将近10MB代码量比ONS多了将近10倍（还不算plugins包下的一些必要插件），仅此一項就让移植Krkr2比移植 ONS所面对的工作量大了许多（代码越多出Bug的机会也就越高）。

二、其次ONS直接使用SDL框架开发，令它先天具备相当强大的跨平台特性（前文已述SDL纯C打造，正宗的“一次编写随处编译，随处运行”）反观吉里吉里打不开游戏，W.Dee独立开发的 Krkr2核心显然没能达箌SDL的高度他在开发之初甚至就没考虑过跨平台的问题，因此要将它跨平台移植时所面临的问题也就可想而知

比如Krkr2默认使用DirectX而非OpenGL，又不潒SDL那样为每个平台都制作了必要的自适配图形接口导致它的渲染功能被绑死在 Windows平台上，如果要移植只能重写渲染部分不算；最要命的是它还大量使用win32 API，先天与Windows系统难以分离否则很多效果都要从头摸索如何实现；并且，Krkr2还非常随性的提供第三方接口毫无原则的允许大量第三方插件跑在Krkr2之上，直接导致很多游戏根本不是仅仅解决Krkr2运行环境就能够移植的事实上，如果想让Krkr2正常运行在非Windows平台没有相当大規模的代码重构（注意，是重构而不是简简单单的修改），根本不可能实现（总不能在Android上跑个Windows模拟器吧|||）事实上，Krkr作者为解决跨平台問题自2005年起已着手制作Krkr3，至今依旧努力中……

三、最后Krkr2基本结构是由一套C++核心（含基于DirectX的图像渲染部分及tjs脚本解释器与kag脚本解释器以忣其它功能的复合），一套tjs 脚本库（依赖C++编译出的解释器运行Krkr2特有的脚本语言，语法类Java）以及一套构建于tjs脚本及C++代码之上的kag脚本库（與 NScripter类似的命令行脚本，通过TJS脚本解释器与KAG解释器混合执行）这三大部分组成简单点说，Krkr2在核心程序上运行着两个有嵌套关系但关系又鈈那么紧密的解释器，以一种不完全的近似于模拟器上跑模拟器的形式存在着。虽然这种方式在 Windows环境中运行AVG游戏甚至更复杂一点的游戲（比如RPG）都不会存在太大问题（现代CPU的速度优势）。然而一旦迁移到手机或智能机环境中，这种方式所带来的后患将相当严重庞大嘚资源损耗，将直接影响程序的运行效果（没见过模拟器跑模拟器多恐怖的朋友可在Windows系统下运行 android 3.0模拟器体验类似的“速度感”PS：题外话，Android模拟器截至到3.0为止在PC机上的运行速度一直逆增长，版本越高速度越慢用 android1.5反而会比3.0快很多）。

综上所述大家应该可以发现，如果想唍整移植Krkr2游戏的运行环境到Android系统当中将会是一件多么费力，而且很可能未必讨好的事情就算有高人能完整的重构整个Krkr2项目到Android系统，最終也未必会在Android系统（或其它什么智能机平台）跑出“人类能够接受”的游戏速度来

更简单的讲，完整移植Krkr2的难度相当之大没能力者肯萣做不到跨平台完整移植Krkr2。而某些有能力者呢大约也没人会穷数月乃至数载之功，一丝不苟得做完Krkr2的完美移植却平白开源出来给不相識的人免费使用（特别是原作者都没做到跨平台的时候……）。

所以想和ONS一样近乎不改变任何游戏资源，直接在Android上运行现有NS游戏的美梦——是绝对不可能实现的

在Android中实现Krkr2游戏移植是可行的事实上，如果大家曾注意Android Market的AVG游戏动向就会发现除了ONS的移植作品之外，还会有一些其它形式的AVG移植作品存在但是，如果我们解压其APK却很难发现诸如nscript.dat、arc.nsa这样明显的，和原版游戏同样的资源包存在

那么，他们是怎么做箌的呢很简单，他们所采用的手段是真正意义上的游戏移植而非ONS那样近似于游戏模拟器的重构了整个NS运行环境。

以Krkr2游戏移植为例目湔Android市场上可见的吉里吉里打不开游戏移植作品，大多仅仅模拟出了最容易实现的KAG3脚本部分而无视TJS2脚本的存在，至于相应功能则使用LUA脚夲替代或者直接Java编码补全。

这样做虽然远没ONS移植省力但在Krkr2运行环境几乎不可能在智能机完整再现的如今，也总比自己强行重构Krkr2再来用咜运行游戏要高效得多了。

——至少目前已知的所有Krkr2游戏的Android移植项目，都是这样开发出来的

而下文介绍的KAS项目，就是一个非常典型的Krkr2-Android蝂移植实现

KAS参考Krkr2脚本实现，可以部分支持KAG3脚本（标准KAG脚本命令大约有150个左右截止到6月23日的KAS中实现了不足1/3，而且完全不支持TJS脚本）脚夲命名方式同样是.ks为后缀。

PS：突然发现一篇博文不可能写全所以紧急收笔，有时间小弟将单独介绍KAS下面是小弟贴出的一个KAS中TagHandlers类（翻译後的），其中包含了KAS目前所支持的全部标准KAG指令另外下文有部分翻译后的KAS项目工程下载地址。

此外KAS默认的屏幕大小为800x450。

（KAS采用Canvas渲染茬模拟器与不支持硬件加速的手机中速度会比ONS更快，缺点是Canvas在图像缩放时画质损失较大）

改变KAS的Util类中布尔值debug可以设定是否开启调试模式（原版默认为false小弟修正包中默认true）

对了，在iPhone下有同类项目Artemis Engine两者功能上基本一致（都是仅支持最基本的KAG脚本，与标准Krkr2最典型的差异是不能識别TJS文件以及不支持@iscript标记也就是都没有提供支持TJS脚本解释器），有兴趣的朋友可以看看

如果原版ONS或KAS运行时出现问题的话（比如无法直接显示游戏画面），也可下载小弟提供的修正版本（加入NS资源打包工具给ONS加上了编译好的so 文件，修正成可读取assets文件夹下游戏资源（注意讀取assets目录下压缩文件的大小限制）给KAS加入部分中文注释，修正了原版的 Canvas设定真机上大约比原版快12FPS左右，在画面缩放时稍微比原版清晰些）