对目前主流MOD框架的分析

bt

目前主流的金庸群侠传MOD框架有两个，即pascal版和lua版，以下简称为p版和l版。本文会连dos版的情况一起分析，此版简称为d版。

基本上，p版和l版最初的目的都是重现d版，故在设计之初，当p版和l版的某些行为与d版不符的时候，均应该向d版靠拢。在2012年左右，p版对d版的重现近乎完美（一些公式除外），故可以完美运行再破菠萝。

运行机制的分析

从d版所表现出的行为来看，当时的设计思想基本属于独占设计，即一次只准许一个过程在运行。
举个例子来说，d版中的大地图上是有飘云和水面闪烁的动态效果的，内场景也有一些动态效果，但是当你打开菜单，或者进入一个对话之后，这些动态效果会全部静止。而p版和l版都采用了类似的设计，情况也是一样的。
通常来说，进入菜单、对话之后，动态效果都停止也并没有什么明显的问题。但是如果战场也使用这种设计，就会有一些不合适的情况出现。假如你设计了战场上某个角色身上会一直有一团火的动态效果，那么在进入战场菜单，或者选武功的菜单的时候，这个效果同样也是静止的。实际上在战场操作的时候，有很多时间是停留在菜单中的，而效果只有在播放人物使用武功动画的时候，或者在流行的所谓半即时设计中，进度条移动的时候才可能动，效果会大打折扣。

值得注意的是，这种阻塞等待事件的做法，也是部分50指令成立的条件之一。例如50指令中有几个画图，画文字的指令，如果这时不采取等待的设计，那么这些图和字会被很快清掉。

那么还是回到上面的情况，如果我们希望这个效果可以一直变化，当然也是可以的，就是在菜单的循环中绘图的部分改为绘制全部，并且为下一次绘制改变效果的贴图。但是这种做法应该说是治标不治本，如果战场操作还有其他的循环，这些地方就全都要修改。

目前来看，红颜录应该是使用了其他的设计，因此可以比较容易地做到上面提到的动态效果，但是好像并没有使用到。

那么，如果想从根本上解决问题，应该怎样做呢？

首先我们提出一个状态栈的概念。栈是一种计算机科学中常用的数据结构，也是计算机运行的基本架构之一。它只能在尾部进行增加和修改操作。

我们考虑将游戏中的状态分为几类，例如标题、大地图、小地图、战场。在游戏开始的时候，应该是处于标题，而后进入大地图，再进入小地图。有一个全局变量保存目前游戏的状态，同时只能存在一个。
如果我们考虑用状态栈来保存，那么从标题进入大地图的时候，就不是将这个状态改写，而是将新的状态入栈，在退出大地图的时候，将相应状态出栈。绘图的时候，我们需要从栈的底部一直画到顶部，但是只准许最顶的状态可以接收并处理鼠标、键盘等的事件，这样就可以解决动态效果的问题。

在软件工程上，当然可以用继承和多态来处理，但是思想是一致的。

这时又会引出一个问题，就是指令的设计。一般的改几个数据的指令还好办，如果涉及到绘画的指令，例如对话，得到物品等，就需要额外添加对应的状态，对话还需要将下一句话不断发送回去，与通常的顺序执行思维方式会不太一样，这样在设计上会出现一些麻烦。

westcoast

太nb了

bt

数据的分析

d版的数据几乎全部为16位整数，最大值为32767，如果用无符号数是65535，对于人物属性来说，通常已经够用。但是经验和银两这两处，是明显不够的。这一点在原版被刻意避开了，但是在所有MOD中，都有相同的困难出现，可谓流毒无穷。《再战江湖》采用银票来回避这个情况，则是治标不治本。

其实这一点在复刻版一开始设计的时候就应该被处理，但是两个版本都没有解决这个问题，当时的想法已经无从得知。而最早设法将这个问题解决的是《金庸水浒传》比较后期的版本，仅对于物品的数量采用了32位的整数。

此外，原版数据中，图片的编号需要乘以2，这里增加了计算量，同时导致一些指令的编写变得复杂了。在当年计算机并不快的时候，这个设计看不出任何好处，目前想不出原因所在。

bt

代码结构的分析

d版的代码我们是不会有的。这里分析一下p版和l版在代码结构上各自的优点和缺点。

p版的代码组织是比较乱的，一些功能分散在几个文件中。全局变量没有保护，随便使用。在某些计算量较大的地方，为了节省计算资源，特意使用了计算量略小，但是可读性较差的写法，导致后期维护有些困难。同时一些地方又偷懒过度，例如事件的13个属性根本没写出别名，直接用整数索引调用，以及画状态采用数组别名代替属性名。这在维护上都是非常不利的。
p版在加快绘图速度上下了非常大的功夫，例如内场景的画法曾经多次修改，目前为止也是在各个版本中最快的。
另外，pascal语言本身比较冷门，使用的人不太多。

l版的代码可以分为两部分，c和lua。c部分的量比较小，代码的质量只能说是尚可，其中有几个比较糟糕的风格问题。比如在头文件中定义了一个变量，将很多实现在不同c文件中的函数声明在了同一个h文件中。内部有几个地方的代码是复制粘贴的，看起来非常混乱。
后面接手的人增加了几个函数，例如保存屏幕的一部分用于快速重绘，将贴图统一放大等。但是新增的功能无统一规划，在不同的地方复制粘贴过后，参数的含义有时会出现变化。保存屏幕部分的设计是好的，但是需要手动释放，而在lua中，通常垃圾是自动回收的，这一点违背了lua的设计原则，应该加以修改。
lua部分在初版的时候其实代码尚可，但是随着接手的人增加，代码开始无规划地膨胀，目前的结构相当混乱。
特别地，在lua版中，大地图和小地图是放在同一级别，而不是大地图调用进入小地图的功能。这个设计比较奇怪，可能是方便使用小地图存档，但是l版一开始并没这个功能。实际上这里也一定程度上违背了顺序结构的设计原则。

bt

绘图的分析

d版的窗口尺寸并不大，后期才有高分辨率的设计。

p版在一定程度上沿袭了高分辨率的设计，从一开始就没有考虑放大贴图，并且窗口的尺寸偏小。而l版在后来加上了将贴图自身放大，并重新按照放大后的坐标拼接的方法。应该说，这个方法在放大倍数非整数的时候，基本是错误的。先按照1:1的比例拼接再放大才是正确的方法。不过在SDL2之前，用CPU计算放大这一步是很慢的，如果不加平滑，效果也并没有很明显的改善，只是在一些地方少了几条拼接线而已。

未完待续

muyi66

流弊！文化低看不懂只能围观！同时支持一下！

真正的强强

支持偶像，膜拜偶像！
想问问偶像，如果现在在重写一个复刻引擎，打算怎么搞？会不会用这种麻烦的运行机制？

bt

真正的强强 发表于 2017-10-17 16:45
支持偶像，膜拜偶像！
想问问偶像，如果现在在重写一个复刻引擎，打算怎么搞？会不会用这种麻烦的运行机制 ...

我会在近期给出所有问题的答案。

airliukai12

顶顶顶顶顶

czsazfy

顶礼膜拜一下！

roiff

纠正下 状态和多态 概念上差别还是比较大的 状态机制注重的数据状态的切换和数据转移的顺序, 多态则是面对对象的一个特征,强调的是抽象下存在的不同的几种实现,不纠结概念的话,简单举例在实现上,多态更类似于 在方法内部 if ... else... 把对象不同状态下的方法实现区分开来. 而状态的话,更像是gotostates XXX 把所有堆栈转移, 方法也自然可以重新定义了, 我觉得就金庸MOD的游戏而言,采取状态机制可能优于使用对象的多态