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

系统 3276 0
大家好,很久不见,小弟最近闭关修炼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的画面。

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

编译成功后,获得的so文件列表:

谈谈AVG游戏的Android移植(NScripter与吉里吉里)

有了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-Android的结构可谓非常简单,开放给用户的仅有Audio.java、DataDownloader.java、 GLSurfaceView_SDL.java、ONScripter.java、Video.java这五个Java文件而已(因为具体实现是 C/C++的)。其中Video.java最为重要,它包含有DemoRenderer和DemoGLSurfaceView两个子类,这不单是ONS- Android的渲染核心,而且包含了nativeInit, nativeInitJavaCallbacks, nativeDone,nativeResize,nativeMouse,nativeKey等六个jni接口。其中最主要的接口是 nativeInitJavaCallbacks以及nativeInit,只有执行了这两个jni函数,才能真正启动ONS(本质上是先启动SDL框架,附带唤醒ONS)。


而执行nativeInit函数时需要注入的地址字符串,默认来源于 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代码。

而 ONS-Android的启动用Activity是ONScripter类,其中真正调用ONS运行的只有runSDLApp这个私有函数,至于 runLauncher及runDownloader函数一者为要求游戏用户选择ONS资源所在路径,一者为通过网络下载ONS游戏资源,都只会在 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卡中进行游戏什么的),完全可以根据此特性入手。


ONS-Android的运行效果:

真机运行效果:

谈谈AVG游戏的Android移植(NScripter与吉里吉里)

模拟器运行效果:

(虽然ONS-Android默认使用GLES,可惜Android模拟器默认只支持PixelFlinger,因此建议真机测试,否则速度相当悲剧)

谈谈AVG游戏的Android移植(NScripter与吉里吉里)

关于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版移植实现。

项目地址: http://studiomikan.net

源码下载: http://studiomikan.net/kas/

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

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

*****************



*****************

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

作者给出的效果图:

谈谈AVG游戏的Android移植(NScripter与吉里吉里)

模拟器效果:
(KAS采用Canvas渲染,在模拟器与不支持硬件加速的手机中速度会比ONS更快,缺点是Canvas在图像缩放时画质损失较大)
谈谈AVG游戏的Android移植(NScripter与吉里吉里)

谈谈AVG游戏的Android移植(NScripter与吉里吉里)

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

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

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


下载地址: http://download.csdn.net/source/3516651

谈谈AVG游戏的Android移植(NScripter与吉里吉里)


更多文章、技术交流、商务合作、联系博主

微信扫码或搜索:z360901061

微信扫一扫加我为好友

QQ号联系: 360901061

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧,狠狠点击下面给点支持吧,站长非常感激您!手机微信长按不能支付解决办法:请将微信支付二维码保存到相册,切换到微信,然后点击微信右上角扫一扫功能,选择支付二维码完成支付。

【本文对您有帮助就好】

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描上面二维码支持博主2元、5元、10元、自定义金额等您想捐的金额吧,站长会非常 感谢您的哦!!!

发表我的评论
最新评论 总共0条评论