KAGEX ——已经可以放弃的框架

首先看下这几个游戏：
1. front wing发行的游戏《Corona Blossom Vol.1 Gift From the Galaxy》
这是它的框架代码：

2.PALETTE发行的游戏《9-nine-雪色雪花雪之痕》
这是它的框架代码：

3.YUZUSOFT发行的游戏《千恋＊万花》
这是他的框架代码：

明显的注意到明明是没有什么关联的公司，游戏使用的代码却是有着惊人的一致。如果你注意过游戏结尾的staff列表你就知道程序的开发都是外包给了叫wamsoft的一家公司，社长是渡边刚。渡边刚这个就很熟悉了，早期的kag框架你可能见到过他的署名，而他就是kagex最初的开发者。这时再回头看下这些游戏的源码，其实很容易看到kagex的影子。

至此，推断出渡边刚的wamsoft公司一直在维护着kagex并承接了大部分吉里吉里引擎游戏的外包，这个结论应该是没错的。

可以说现在使用的kagex比起开源的版本要新出太多太多，system107个文件，syscn117个文件，单从代码数量上就已经碾压了。而且它做出的游戏有很多的优秀案例，那么拿过来研究下也许能直接使用。
关于拿源码的注意事项，2016-2017年左右，开始有游戏使用编译后的文件而不是明文的源代码，（如果想要反编译，确实是存在叫girigiri的反编译器，不过只能反编译很简单的代码，稍微复杂一点就不行了，可以说完全不能用），而越新的版本越好，所以要找16-17年左右发行的游戏，我能找到的明文最新的版本是在《nekopara vol2》里面拿到的。

框架的代码主要放在system,syscn和main三个文件夹中，system是系统核心代码，syscn是定义展示菜单以及一些插件的代码，main的游戏的自定义代码，main里的代码各个游戏都会不同。 研究了这个框架进行之后，确实是存在一些模块的功能是可以学来用的。
1.action模块
定义在action.tjs的位置，这个模块的功能是控制动画效果，定义了PropActionInfo、ActionSequense、ActionTargetInfo几个类把动画拆分成具体的属性，动画的序列以及不同的对象，kagwindow的基类继承action的基类，然后kag的filpstart方法使用addContinuousHandler来添加具体的动画，比起定时器控制的动画可以做到逐帧的精确控制，基本上大部分的动画行为都是由此模块控制的。
2.uiloader模块
通过定义在uiloader.tjs的方法加载ui信息，使用定义在system.tjs的 DialogModeManager来控制具体的ui行为。主要是使用CSVPaser加载ui的定义文件，定义文件使用分隔值文件的形式定义各个按钮的位置，行为，种类，一般csv后缀定义位置，func后缀文件定义行为。类似下面的就定义了消息框下面的快速菜单的按钮：

然后DialogModeManager提供kag解析的标签，指定生成ui时会按文件中的定义生成指定的按钮加载到当前的消息层上，并生成一个控制ui的对象。
3.系统的钩子模块
在system.tjs中定义，基类是SystemRegistory，类似一个注册表的东西，主要有三个子类，分别管理系统的脚本，系统的文件和系统的钩子。例如钩子可以定义剧本文件跳转时触发的函数,想定义从标题跳到菜单，就加一个"option.from.title"的钩子，然后会从系统文件的注册表中取文件，取到的话会发生跳转这样一个功能。

虽然确实存在一些可以拿来用的东西，但是这个系统已经是wamsoft自己的玩具，从根本上无法由外人使用的。这个系统对conductor做了改造，它会把一些自己无法处理的指令交给world插件处理，而world插件才是这个系统最核心的部分，它控制全部的剧本解析，舞台变更，履历存储，立绘展示等等。scn的文件夹下的全部文件都是存储这些指令的文件，如下：

文件是二进制的，格式只有它们公司知道，游戏通过加载psbfile.dll的插件来解析这个文件，并把解析出的指令交给world插件处理。可以尝试用逆向的手段解析一下这个文件，解析出来是这样子的：
是类似于json的格式，world插件就是通过解析出的json格式装换为指令处理。虽然理论上可以通过分析world的代码了解它是如何处理的，但是scn文件看起来就不像是手工写出来的，不知道如何生成一个scn文件就没有任何意义，而且psbfile.dll的插件也是闭源的，可以说研究kagex的指令处理既没有可行性，也没有意义。
为此我还骚扰过渡边老妖，他的意思言简意赅，就是我就要闭源。

代码存在闭源的部分是放弃的核心原因，除此之外还有两个次要原因。
一是它的代码就是屎山。
里面用不到的旧代码不是删掉，而是用新的代码覆盖掉，而且还喜欢用各种hook和hack方式来对旧功能实现改造，结果就是看起来特别乱。就拿履历层来说，kag本来内置了履历层，放在了historyLayer.tjs里，后来为了扩展又写了个myHistoryLayer.tjs，在里面把以前的类名隐藏掉，然后用新的类，但是之后又有一次扩展，写在了backlog.tjs里面，又再次把以前的类隐藏掉，新写了个类，结果现在的代码里有三个historyLayer。而实际上履历层要使用uiloader的功能，因此只能加载到消息层上，你可以看到我把消息层的属性改了，实际上界面发生变化的是履历：

也就是说界面上的履历层实际是消息层，那么实际的履历层是干什么的？它已经把履历层的类只用于信息的存储，不参与任何显示相关的功能了，而那些visible之类的属性也搞成假的了。 那鼠标焦点的切换要怎么做呢？它搞了个hook，打开履历层的时候把键盘事件拦截到消息层处理。这个逻辑已经是乱七八糟了，但是只要程序能正常运行，不出什么bug那就没任何问题，这款《魔女的夜宴》除了touchui拖拉有点小问题以外，确实是没什么bug，所以我也不好说。

二是系统比较自闭，根本没有考虑到加载用户制作的mod之类的扩展。我一开始是看好它的双语同时展示的功能才去研究它的代码的，其他提供双语的游戏有什么呢，万华镜5，传颂之物，island（近几年不怎么玩游戏了，其他都不知道了），这几个虽然提供了多语言，但是可执行文件是两套，想要切换语言要换可执行文件启动，而kagex框架的游戏可以提供语言即时切换，我想尝试能以mod的方法可以方便的扩展语言的选项。
而在实际看了文件的格式后，解析出来是这样子的：

也就是说，多种语言必须写在一起，这样扩展起来就很困难，完全是我的游戏你别改的态度。

顺便做一点测试，kag原生的话长文本会自动换页，以前一直好奇双语言模式下对于长文本要怎么处理，看来做的也不行，而且连单语言模式下也失去了自动换页的功能。

kagex从一开始就是为了商业游戏制作的特化版本 我觉得这东西虽然有亮点但是实在是难用 我反而比较赞同国内kagexpress的做法

这么看来kagex当中扩展了一堆文件 那么这堆文件到底有多少是有价值的呢
都说world很强大 但从原版使用者看来他做的效果kag3一样可以做到
既然高度特化放出一部分还要闭源