tenshin.js开发杂记 技术选型篇

天神乱漫 => lucky || !unlucky

《README.md》

最近程序写多了,突然想说点什么,干脆借着开发杂记的名号夹杂点私货算了,反正PROVIDED “AS IS”

为什么是B/S

本项目的技术栈继承自完全娱乐性质的kagura.js。为什么选择B/S架构也要追溯到那时。写那东西的时候,我本来只是想自动播放某《神乐黎明记 雷道之章》的HCG和音频什么的。我曾经考虑用Python,后来想了想,我还要大战图形界面,算了(拿C#写倒是不用怎么战图形界面,不过我当时没想到)。想了想,上JavaScript,写HTML,排版方便,UI和业务逻辑分离,于是那个项目便用了JS。然后呢,我发现JS(至少是浏览器里面的JS)的文件系统API简直要人命,在忍耐了一整个空气中弥漫着躁动气息的夜晚之后,我终于忍不住了。可是代码已经水了三百行出来了,现在换语言怕是来不及,我灵机一动,nginx目录浏览带json模式,拿来假装自己是RESTAPI挺合适,于是那项目就成了B/S架构。

那项目完成之后,我想了想,没找到能阻止它在广域网上运行的理由,就把整个文件夹甩到地球另一端的服务器上试了试,结果真的可以跑。过了几个月之后,我在某群里吹水,意外地吹到在广域网上玩galgame,也就自然吹到了那个项目,我们开始讨论用当代技术在网页上跑galgame能做到什么地步。

后来又过了几个月,我下了部《千恋万花》并玩了两条线(钓鱼->果然还是放心不下/独自行动),之后想起了那个讨论。看了看,也不存在什么必须要高性能计算机才吃得下来的地方——毕竟nekopara动态全开可以把我们的集显服务器开炸。于是我便考虑移植千恋万花,结果呢,拆包姿势有问题,没拆下来。再后来,我搞到了《天神乱漫》的资源,并且成功拆出了纯文本格式的脚本……于是便有了这个项目。

为什么是徒手移植

  • kirikiri是一个开源引擎,这就意味着我能够搞到它的源代码。
  • kirikiri是一个使用C++的引擎,这就意味着从理论上来讲我们可以emscripten伺候。

然而:kirikiri是一个二十年前的引擎,这就意味着它在当代编译器(例如LLVM)上十有八九要炸得稀巴烂。而我呢,是完全不想修C++代码的,何况那东西只有日文注释!而且你不觉得emscripten走起太无聊了么。

另一种方案是上基于浏览器的虚拟机,显然对于天神乱漫这种老游戏,没有显卡支持什么的不是问题,然而那显然更鬼畜,emscripten暴力编译已经够丧心病狂了。

于是呢,剩下的选择就只有上手了。

为什么是天神乱漫

简单点说,其实就是我当时只拆出来了这个。复杂点说,千恋万花的脚本有第二层(缺乏文档缺乏研究而且还没有源代码的)加密,经过加密的脚本成了字节码,parse起来有困难。

话又说回来,天神乱漫用到的feature倒是挺有代表性的,正好可以拿来做一个全面技术验证。

为什么是Typescript/Webpack/ES6 Module……

可以认为是赶时髦。用Typescript是因为我需要一个自动补全;用Webpack是因为浏览器不支持模块,用ES6模块写法是因为我用不来CommonJS写法;使用jQuery是因为我只会用jQuery,不用现代框架同理,当然也可以说是没有多少框架适合这个情况;用div+css叠图是因为我不会用canvas,也因为div+css的确能够压住这东西。

发表评论

电子邮件地址不会被公开。 必填项已用*标注