《仙剑后传》的创作过程（作者：许畅）
其实《仙剑后传》并非新石器工作组的原意，这是网友取的名字，既然大家这么热情，我们也就不好推辞了。由于我们用了《仙剑奇侠传》的图片，所以也不得不编成了与仙剑有关的故事情节。作为这个RPG引擎的测试，以前还另有一段故事情节，但是那段情节实属测试用，故不少地方未考虑到实际，其中的一段有关裘伯君与Bill Gates的争吵是不太妥当的。
后来，有人就建议干脆续《仙剑奇侠传》一段，既然图片是它的，我们一想也是，于是我们就开始设计故事了。我们本来打算设计了一个完整的故事的，但到了后期，工作量越来越大了，不得不只实现一小部分，就是大家现在看到的样子。大家可能会注意到当刘晋元跟李忆如说话后，李忆如有两条路可走：一是回家，一是去山神庙，其实走不同的路，故事情节有不同的发展。但是去山神庙的一路情节没编好，玩家只能在路口得到一句回答：“前方施工，行人止步！”，这是颇为遗憾的一笔。
大家一般感到好奇的也许就是我们如何搞到这么多的图片？
大多数人一定会以为我们已经破译了《仙剑》的图形文件的格式，其实非也。开始的时候，我们也在干大家都能猜到的事儿，那就是：抓图！然后再点图！这是非常痛苦的事：我们不断地玩仙剑，然后看到需要的图就把它抓下来，这只是最最初的第一步；接下来的是处理过程，干什么？点图！我相信没有哪位大虾会对这活感兴趣，我们需要把人物的背景用画笔点掉！！理由很简单，因为我们抓下来的图是整张BMP图（320*200），人物和背景都混在一块了。唉，说来简单，做起来就不容易了。记得那时，有一天晚上，我与Tasty_Meat处理两套战斗图片：一是李逍遥的，一是阿奴的。结果搞了一个晚上，搞得头浑眼花，才搞定两个人的准备发招的图片，惨哪！把人物点出来以后，我们还要将它们存入我们的图形库，做好索引表。
我们就这样干了好长一段时间，终于到了无法忍受的时候！
“是可忍，孰不可忍！”
玩过我们游戏演示版的朋友大概还记得我们游戏开始的三个跳绳的小孩，就是这三个小孩从此改变了我们的创作过程。
有一次我们花了一个晚上，却还未能处理完甚至一帧小孩跳绳的图片！这对我们打击很大。晚上我躺在床上睡不着，一直在思考这个问题。如果我们不能找到一种高效的处理图形的方法，恐怕...我不敢再往下想。
第二天，上课的时候我也在思考这个问题，结果课也未听好。但是，不多久，我已经有了一个想法：图片的背景是有规律的！都是32*16的菱形小块，而这些小块有不少是相同或相似的！也就是说，如果我能找到与李逍遥后面的背景相同或相似的的块，再加以比较和删选，就能快速地删除背景而得到李逍遥的图象！于是中饭也没吃，我迅速地搞出一个“块比较”工具，结果效率..嘿嘿！当我给主编演示的时候，我只花了一分钟不到的时间，就迅速搞定了四帧小孩跳绳的图片！！！仅仅是一个穿绿衣服的小孩有一小角被削了，原因是背后的草地也是绿色的，太相近了，起了干扰作用。尽管如此，大家还是非常满意。
早知如此，何必当初呢！唉！
图像处理的问题似乎已基本解决，但是图像的来源逐渐成了大问题了。原因是我们所抓的图像仅仅来源于游戏中的，这使得有些图像的抓取成为不可能，例如：剑圣在整个游戏中只出现过两个方向的行走图像，那么另外两个方向的行走图像就不能通过正常方法获得，那么怎么办呢？
我们多么希望能破译《仙剑》的图像文件的格式啊，但是太复杂了，Mission failed！我们只能另辟蹊径。
我们开始研究《仙剑》的存盘文件的格式了，不久我们得到了许多有益的启发，例如：《仙剑》中的每个人物的所有信息是用32个字节存储的，这包括了所有的与此人有关的图片和故事进程的信息。
这启发了我们：也许我们需要的图片信息也在其中！！！
我们知道：一个人物的动作有许多帧图片，按照一定的速率循环播放，存盘文件中也许有图片套号和图片帧号，当然也可能没有。如果有，Everything is easy to proceed!!!
事实证明我们的猜想是正确的！于是我们的总编便活跃起来了。总编虽然肩负着主程的重任，但也对《仙剑》着迷不已，他很快搞出了一个修改《仙剑》的存盘文件的工具：这可不是改人物的属性的，以创造出一个超级李逍遥，而是给人物“改头换面”的（比如说，体会一下带上盖罗娇去砍人的感觉，或者让李逍遥换套和尚的衣服穿穿）！
从此我们拥有了两大“王牌”工具：Paldebug（修改工具）和KC（块比较工具），再加上三大标准存档（分别对应红地毯、白雪地、标准砖块地的背景），于是我们开始了我们的划时代的图像制作新道路！
在查看《仙剑》图片的过程中，我们不止十次对《仙剑》的美工赞不绝口，《仙剑》游戏中只使用了不到一半的图像资源！它总共有超过一千套的人物图片，每套图片大约有二到十六帧，大多是十二帧。而且这仅限于它的人物图片，不包括背景。
但我们无法得到更多的背景图像，因为《仙剑》的存盘文件中没有任何有关背景图像的信息，对于房子、桌子、树等等东西，我们仍用块比较工具进行处理。
前面谈了许多关于图象的来源和图象处理的问题，目的在于说明对于一个游戏而言，故事情节和美工要比程序重要的多，而这一点却往往被人忽视。尽管我们使用了众多的《仙剑》的图象，但图象的处理工作量之大仍是非常惊人的。
设计这么一个所谓的《仙剑后传》的故事，归根结底是为了测试我们的RPG引擎的健壮性，同时我们的引擎就是在对故事的调试中不断地完善起来的。
我们为什么要设计这么一个RPG引擎呢？故事要追溯到一年多前。
我们几个志同道合的编程者当时都是仙剑迷，的确《仙剑》这款划时代的游戏给了我们太多的震惊，相信任何一个武侠RPG迷都难以忘怀。不多久，金山公司出了一款我们等待已久的RPG游戏――《剑侠情缘》，刚拿到手，我们就迫不及待地玩了起来。游戏有多个结局，我们为了打出各种结局，废寝忘食两日才搞定之。后来回味起来，感慨很深。
应该说，《剑侠情缘》有一个非常不错的引擎，实现了一个多线索多结局的武侠言情故事，但是遗憾的是，它的多种结局有牵强的味道，有些情节的发展颇不自然，而且它的情节主线的切换是硬性规定的，这是它的故事设计的不合理的地方。另外，它的美工的确有不够的地方。我们在谈论中似乎对《剑侠》的表现很不满意，它的表现上的缺陷掩盖了另外的创新，于是我们心里都有点不愉快的算盘。
第二天中午，听Peak_Yang说，我们的（未来的）总编开始编程序了，是有关RPG游戏的。于是我们心里一激动，一起冲了过去：大家都想到一块去了！总编很谦虚地说，我只是试试罢了。但我们大家可是十分兴奋，于是你一言我一语地争执起来。两个小时后，敲定：开搞。
大家是凭着热情和兴趣走到一块来的，最初的分工非常简单：总编大人搞主程，古月先生是美工，语天先生和在下负责事件处理模块和故事的设计。从此我们四个开始了艰难的探索。
编程过程中，为搞笑活跃气氛起见，各人都有自己的nickname，除了古月大名不变外，另外的分别为郭靖、铁嘴、许仙。大家都想把自己加到游戏中去，而且是要很厉害的角色，可是大权掌握在我和铁嘴的手中，结果后来的测试版（最早的测试版）中就有古月和铁嘴。当然那个测试版已经几乎见不到了，成了我们现在很想念的绝版。
当初我们用的是Turbo Pascal V7.0，现在想起来很可怕，一是Pascal语言的限制太多，另一是Turbo Pascal的编译速度太快！编译的速度太慢或是太快都是很可怕的！若是在486上运行Visual C++ V5.0，编译一次的时间可以用来打一把《伺魂》了；若是太快了，不敢相信，以为是错觉，而且没有一种成就感，不是么？看到编译的时候行数在慢慢增加，从一位数到两位数一直到五位数，是不是很爽，是不是很得意？
这个版本的引擎现在看来很是糟糕，因为不是图形界面，是字符界面。但即便如此，也费了我们的美工好一番心思了，他也作了个非常出色的图形编辑器和地图编辑器，当然是用ASCII码拼的图，很不容易的。
编程中大家闹了不少笑话，也学到了许多东西，比如：每个人的模块都好好的，但是一连接起来就出问题了。我们的故事刚刚载入内存不久就消失了，显示出来的故事内容都是乱码，后来一查，原来我们的古月先生使用了release语句释放内存，没有用delete，结果我们的故事也报销了！
才编了一个星期，就得到消息――要物理期中考了，于是大家很不情愿地放下了手中的工作。结果这一放就放了一个多学期，以后大家总是很忙，总有一些自己的事情要做。最初这个非常幼稚的版本只有小小的三个场景，人物有：西门剑（主人公），算命先生杨铁嘴，隐士，农夫，酒客古月，情节非常简单，就是西门剑要进游戏城，但不知如何打开大门，然后到处请教别人，经历一些小挫折，然后得到了钥匙，打开了游戏城的大门。其实这时候的引擎问题很多，很多地方的实现是有偷懒的，图形的显示问题更大，因为我们用的是文本界面，为了显示中文，我们不得不借助于UCDOS，但是UCDOS的汉字刷新有问题，不跟我们的显示速度一致，结果游戏中的人物一跑起来屏幕就坏了，于是大家都很扫兴。
这一阶段性的工作一完成，RPG引擎的开发进程就被很遗憾地耽搁了一段时间，但是这一段愉快的日子为以后我们的新引擎的开发打下了初步的基础。
许久以前，我们在谈论一个有关《仙剑后传》的创作过程的故事，掐指算来，离今天已有半年多了。遗憾的是，不仅当时讲了一半嘎然而止，而且一直以来也未能继续下去。其中的原因也有很多，功课紧张是一方面（告诉大家一个秘密，编写《仙剑后传》的那个学期的期考，我们创作小组几乎全军覆没，//cry，只有古月先生力挽狂澜，独上高楼，以绝对优势夺得状元，为我们小组争得光彩，//applaud），另一方面各人都有自己的事要做，交流不多，所以也难以把自己的体会写下来。然而，有许多的朋友常来和我们交流一些编程与游戏设计的经验，并且鼓励我们把故事写下去。我们非常感谢这些朋友们，同时也想到，我们已是毕业班的学生了，也许不久就要各奔东西，离开科大，在此之前，把我们在编RPG游戏引擎中的一些体会和经验说给大家听听，也许会有一些启示和帮助，能少走一点弯路。如果真是如此，我们小组也就非常欣慰了（大言不惭一把，//hehe）。
接下来我们打算把上次未完的关于《仙剑后传》的创作过程写完，谢谢网友们的支持。
在以前的文章中，我们首先谈到了游戏的内容，即我们根据《仙剑奇侠传》的故事续编了一段，以测试我们的RPG引擎的可行性和健壮性；然后我们又谈到了大家都很感兴趣的图像来源问题，其实是我们用自己编写一些工具半自动地间接地获取《仙剑》的图片并将它们加入到我们的图像库中；再后面就是最重要的关于RPG游戏引擎的设计，我们先说了为什么要编这样一个引擎，接着就开始了RPG游戏引擎的设计的漫长故事。事实上，我们编写RPG引擎一共有三个阶段，我们分别设计了三个RPG引擎，当然是在功能上不断地扩展增强，这三个RPG引擎也分别是用Turbo Pascal 7.0，Borland C++ 3.1和Visual C++ 5.0编写的。在前面的文章中，我们谈了第一个RPG引擎的设计过程，第二个才开了一个头。下面我们从第二个RPG游戏引擎的设计开始谈起。
其实大家心里都还是很挂念这个小引擎的，都想把它扩展一下，编一个完整的游戏，于是半年后，也就是去年一月初，大家又走到一块来了。时值期末考期间，大家还是“偷空”聚了几次，讨论新引擎开发工作的可行性。大家在对旧引擎的肯定与批评的基础上，又提出了新的进一步的目标：采用图形界面，引进多线情节处理，实现完整的物品系统、法术系统，即时战斗系统等。寒假中每人各自研究，第二个学期刚开学大家开了个会，交流各人的设计思想后就开搞了。
刚回到学校，看到我们的美工兼图像显示模块编程者古月先生正埋头研究斜45度视角图像系统，我们都非常感动，听总编大人说，古月先生现在正遇上点麻烦，于是我们赶紧给他打气，因为他这部分工作是非常重要的，是给玩家的第一印象，而且他的难度也很大：以前他的图像引擎是个文字界面，现在变成了图形界面，这是个很大的进步，而且直接采用了斜45度视角，简直是帅呆了――不过问题多多：主要是消影问题，我们给他做测试的时候，常常能让墙后面的东西露出来，非常有趣，而古月倒被我们气得半死。但是我们的古月同志非常有毅力，不久他用了一种叫做四条消影链的技术成功地解决了这个大难题，大家真是佩服得五体投地。尽管古月非常认真地给我们解释了他的消影原理，但只有总编大人若有所悟，其余的人通通坠入云雾，不知所云，而我的装满事件的脑子从此也多了一大块浆糊。
我和铁嘴照样搞事件处理模块。这次我提出了一个事件处理系统的“全新构想”，把以前的事件处理系统踢进了历史的垃圾堆，而且狠狠地踩上几脚，叫它永世不得翻身。原因是原先的事件处理系统太糟糕了，把资源管理和事件处理混在了一起，而且功能太弱。我和铁嘴经研究后推出了号称是“使用了六千个链表，能够实现任意的事件的逻辑关系”的全新一代的事件处理系统，这“六千个链表”开始令我们非常自豪，不久就发现对它们的管理是件很棘手的事，而且是导致前期程序无法通过编译的原因之一。
总编大人是负责主程的，他的地位比较痛苦，是这样的：
事件处理模块 （许仙、铁嘴）
|
主程 （总编）
|
显示模块 （古月）
这个结构图意味着在显示模块和事件处理模块编好之前，总编大人不得不设计两个虚拟机，所以有时我们去看望总编大人“他老人家”，发现他在修改一些文本文件中的数据，然后控制一些ASCII码在屏幕上跑来跑去，他会津津有味地告诉我们：这个P是抬左脚，这个K是抬右脚，你看现在主人公在说话……可怜我们瞪大了眼睛（别笑我是小燕子），眼前也只有一些乱七八糟的ASCII字符在乱窜，//faint。不由地摇摇头，抱拳：实在佩服。
由于我们四个已经合作过，所以第二次合作也非常默契，大家都非常清楚自己的任务。不久我们又有三位新的伙伴加入了（江湖人称东方朔、杨老邪、刘小孩，最后一个名字是我们强行“赐”给他的，//grin），于是我们的队伍几乎又增大了一倍，他们分别搞美术，剧情与战斗。
美术 （东方朔）
剧情 （杨老邪）
战斗 （刘小孩）
这次我们采用的编程工具是Borland C++ 3.1，程序分为控制、显示、事件、战斗四个模块，四个模块分开编写，然后大家include在一起编译联接。大家原来以为这是个很好的方案，开始时我们的确合作得很愉快。但是随着程序的不断膨胀，大约总长有12000行时，BC编译器报告：Too many global variables！//faint，大家面面相觑，不知该如何是好（当时甚至还未把战斗模块include进来，否则早就死悄悄了！）。这时候Young_Yang出现了，他如同一颗“救星”般的，只是摆弄了几个编译开关，便神奇地使程序通过了编译。大家高呼万岁，然而好景不长，两天后BC编译器又宣判了我们的程序的死刑，不论我们怎么调整编译开关，BC编译器就是不照。看来BC编译器对一个文件的编译能力已达到了极限了！
我们狠狠地把Borland公司臭骂一顿，说它这么小气，多几个变量也不肯。这时Young_Yang建议使用工程Project，哇考，I服了You，我们这堆土人怎么没想到呢？于是总编大人号召大家把各模块中的常量、数据结构、函数说明通通丢到各人的HPP文件中去，这项改造工程耗费了我们整整一个下午。改造工程在215展开，那时另一台机子正在放《情书》，很好看的，搞的我们心里痒痒的，不过，谁想溜过去瞧瞧，马上会激起公愤：好小子，你够不讲义气！结果大家是在几台机子之间轮着转，最后，程序改造完了，影碟也看完了！
我们首先测试的是控制、显示、事件三个模块的连接，至于战斗先丢到一边，因为战斗模块受控于事件模块：只要我们不愿意战斗，你就休想启动起来，这使得刘小孩十分委屈，//comfort 刘小孩。连接前，我们最担心的是游戏的速度，生怕人物像石像一样动不了，所以我们把延时调到最小。万事俱备，我们全拥在总编大人寝室那台经过跳频的电脑前，瞪大了眼睛，看着总编大人按下最后启动的回车键。
我们用于测试的数据翻译成图像就是《仙剑》中的香兰挎着篮子在砖地上踩着八字形散步（鬼才知道有没有这种散步方式），高难度动作！大家都是为了显示一下各自模块的“超强功能”。结果砖地是显示出来了，上面却空无一人。各位大侠均若有所悟地想了一想，道：不是我的错！
非也，非也，既然空无一人，肯定有问题。我们又盯着屏幕研究，似要找出破绽，大家都想把错误栽到别人头上去。突然间，一个蓝影“嗖”的一下穿过屏幕，与此同时，我们惊呼一声，于是谜底也就揭开了：原来是速度太快了！大家嘻嘻哈哈一片，同时心里非常欣慰：原来我们的引擎的潜力有这么大。
正因为有这一出戏，后来总编大人灵感一发，在作弊模式中增加了快速模式和视屏测试，这样子就可以得意洋洋地把主人公开来开去，从地图的这一头窜到那一头，又从那一头窜到这一头，如果再打开穿墙模式，那更是不得了了，有时候跑着跑着，就不知道把主人公丢到哪个屋子里去了。但是我和铁嘴开始颇为不满，因为用这种方式，可以到许多不能去的地方，提前触发事件，结果把故事逻辑搞的乱糟糟的。于是我和铁嘴采取了一些措施来限制总编大人的权力，比如动态产生人物和事件，使其并非预先可见，但总编大人又搞了一些花招，对一些不可见的事物也能产生作用。我和铁嘴无可奈何，不过不久我们也喜欢上使用这些乱糟糟的作弊模式，因为它们能大大方便地调试故事逻辑。
我们的总编大人有一个习惯，喜欢把所有的旧版本的程序保留下来，这样一旦把程序改坏了，就取回原来的版本。这个主意不错，但是要命的是，总编大人的新版本诞生得太快了，有时候一天之内能出个五、六个版本，为了区别，程序名也跟着变，如GHPAL34.CPP、GHPAL56.CPP等，眼见两位数也不够用了，这时我们语重心长地说：我们的版本“更新”地这么快，可是连战斗模块都还未加进来，是不是有点……总编大人一想有理，于是我们达成协议，在战斗模块还未加进来之前，主程的版本号不得超过GHPAL80.CPP。这成了一条不成文的规矩，鼓励着我们抓紧干，不久GHPAL80.CPP达到了，怎么办？没关系，主程升级成了MAIN.CPP，从此主程没有了版本号之争。不过，很快战斗也加进来了。
战斗的设计者和编程者是我们的武打设计师刘小孩，他不喜欢我们给他的名字，他有另一个在江湖上响当当的大名――京酱肉丝。京酱肉丝管Enemy叫“鬼子”，“鬼子踢我一脚，我砍鬼子一刀”。
战斗加入以后，程序的运行经常不稳定，经检查，发现内存的减少与执行时间成正比。每战斗一次，内存减少约2K；每存取盘一次，内存减少1K――2K；每切换场景一次，内存或减少或增加，当然，减少的概率要大一些，于是内存越来越少，最终耗尽。由此看来，战斗、事件、显示三个模块都有问题，总编大人要求我们仔细查错。我们发现一个有趣的现象：当空余内存只剩下1K时，各大模块纷纷报错，只有显示模块是一边报告“Restore one not found！”一边还在勉强执行，而别人早就撒手不干了。于是大家一致公认：古月先生的显示模块是最酷的，而背后却骂道：到这时候还死撑着！
为了查错，我们决定写在线Log文件，大家把程序执行中所有有关内存操作的信息及操作后内存的变化都记录在文件Check.Txt中，执行完一遍后只要查一查Log文件，就可以知道谁在内存操作中出了问题；此外，Log文件还有另一个作用，为了某种需要，有时程序需要紧急退出，这当然是非正常的退出途径，总编大人谓之“逃跑”或“开溜”，在程序执行的任何时候，同时按下Ctrl + Alt + F11，程序就能迅速结束。遗憾的是，按下Ctrl + Alt + F11后，程序常常以死机告终。虽然我们希望迅速跳出程序，但也不希望是这个结果啊，所以就借助于Log文件了。大家约定，谁成功地“逃跑”了，就在Check.Txt中留下一句：某某某 run away successfully！就连函数名都取成Run_Away()了。结果总编大人的主程为了“掩护”其它模块的“逃跑”，常常是“死”在程序里了。这也难怪，总编大人不得不等我们“逃跑”后，才能释放时钟中断和键盘中断，然而，总编大人的主程一“死”，机子也死了。
在查死机的原因中，京酱肉丝起了很大的作用，他一针见血地指出是键盘中断的释放出了问题。在按下Ctrl + Alt + F11后，我们的新的键盘中断接受到了消息，于是，大家依次“逃跑”，“逃跑”的最后一项工作是释放我们的键盘中断，将其换为原来的键盘中断，但如果这时那按下的三个键仍未松开，结果一定是死机。为了证明他的理论，京酱肉丝还给出了“预言”，按下Ctrl + Alt + F11后，只要速度足够快地释放它们，就有可能不死机。我们试了，的确有几次能侥幸“活”下来，于是我们对京酱肉丝大大地admire了一把：等级就是不一样啊。不过要解决这个问题困难倒是大大的，最后大家只好忍痛割爱，舍弃了这个“逃跑”功能。“逃跑”事小，死机事大。
我们的游戏终于跌跌碰碰地运行起来了，后期的故事逻辑测试非常累人，为了我们实现的那一段故事情节，我们玩了好几百遍，以至于每次看到游戏又重新开始了，立刻有一种想呕吐的感觉。可见游戏测试人员的工作是非常辛苦的。《仙剑奇侠传》的存盘文件是定长的，其中存储了整个游戏中所出现的人物和所用到的物品，这给它的游戏测试带来一定的方便，但也大大利于破译工作的开展。我们喜欢制造神秘感，把我们游戏的存盘文件搞得不定长。其实我们在存盘文件中只存储了有用的数据，不像《仙剑奇侠传》在游戏一开始，就已经存储了最后场景的数据；到了最后决战前，存盘文件中还有最初村里小虎子的数据。我们认为那是大大得不妥，不符合作为一个引擎的标准，存盘文件中应只存储当前场景中的数据和已发生过的重要事件的数据，应该尽可能脱离游戏的内容。当然，理论只是一方面，对于不定长文件的研究表明：我们往往无法理解自己写的文件中某一字节的含义！
我们的这个引擎及演示游戏得到了同学们的认可，并在第五届软件大赛上获得了一等奖，这使我们感到十分高兴。同时在广大网友们的测试下，我们又发现了众多的Bug，呜呼唉哉！事实上，这个DOS版的程序由于过多地依赖于硬件以及内存管理的不当而一直暗藏着好多“小虫虫”，另外也没有音乐和音效（不是没有尝试过，而是在DOS下播放音乐实在困难重重，主要是兼容性问题）。于是很自然地，我们向Windows95看齐了，这就是我们的第三个RPG引擎――是用Visual C++ 5.0编的。
但由于学习任务繁重，我们为新引擎所作的工作并不多，主要是以下的改进：
1.更换了图形显示底层，采用了DirectDraw技术。当然斜45度的图形 引擎部分不用变化，我们用“偷梁换柱”的方法更换了古月先生的显示区，然后按时钟刷新。事实表明，刷新效果不如DOS版，大约每秒20帧，有时图像发生抖动，但这样可以最大程度地保留古月原先的成果。
2.加上了音乐和音效，这是Windows给我们带来的巨大的好处。大家一定十分迷恋《仙剑》的金曲，这回我们可以非常easy地加上任何一段midi音乐，与情节相配合；另外，加音效也是一件非常happy的事，狗叫声、虫叫声不绝于耳，我们的总编大人还突发奇想，给音效加上立体声效果，根据主人公与小狗的相对方位和距离，两个音箱可以发出不同声响的音来。
3.DOS下的int是16位的，而Windows95中的int是32位的，所以原先的数据文件不再可用。我们改造了所有数据文件，同时把原来乱糟糟的资源管理部分的函数提取出来，按类别创建了若干个相对独立的类。这项工作非常累人，但我们发现十分有效，程序立刻干净了许多。
4.由于我们是改进引擎，所以故事情节没有任何改变。
5.动画部分和战斗部分没有改造好，淡入淡出、震动效果没有。
至此我们的故事就告一段落了，我们的引擎还是非常不成熟的，我们还有很长的路要走。谢谢朋友们的支持。