|
《仙剑后传》的创作过程
|
|
我们多么希望能破译《仙剑》的图像文件的格式啊，但是太复杂了， Mission failed！我们只能另辟蹊径。 事实证明我们的猜想是正确的！于是我们的总编便活跃起来了。总编 虽然肩负着主程的重任，但也对《仙剑》着迷不已，他很快搞出了一个修 改《仙剑》的存盘文件的工具：这可不是改人物的属性的，以创造出一个 超级李逍遥，而是给人物“改头换面”的（比如说，体会一下带上盖罗娇 去砍人的感觉，或者让李逍遥换套和尚的衣服穿穿）！ 从此我们拥有了两大“王牌”工具：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 much global variables！//faint，大家面面相觑，不知该如何是好（当 时甚至还未把战斗模块include进来，否则早就死悄悄了！）。这时候 Young_Yang出现了，他如同一颗“救星”般的，只是摆弄了几个编译开关 ，便神奇地使程序通过了编译。大家高呼万岁，然而好景不长，两天后BC 编译器又宣判了我们的程序的死刑，不论我们怎么调整编译开关，BC编译 器就是不照。看来BC编译器对一个文件的编译能力已达到了极限了！ 我们狠狠地把Borland公司臭骂一顿，说它这么小气，多几个变量也 不肯。这时Young_Yang建议使用工程Project，哇考，I服了You，我们这 堆土人怎么没想到呢？于是总编大人号召大家把各模块中的常量、数据结 构、函数说明通通丢到各人的HPP文件中去，这项改造工程耗费了我们整 整一个下午。改造工程在215展开，那时另一台机子正在放《情书》，很 好看的，搞的我们心里痒痒的，不过，谁想溜过去瞧瞧，马上会激起公愤 ：好小子，你够不讲义气！结果大家是在几台机子之间轮着转，最后，程 序改造完了，影碟也看完了！ 我们首先测试的是控制、显示、事件三个模块的连接，至于战斗先丢 到一边，因为战斗模块受控于事件模块：只要我们不愿意战斗，你就休想 启动起来，这使得刘小孩十分委屈，//comfort 刘小孩。连接前，我们最 担心的是游戏的速度，生怕人物像石像一样动不了，所以我们把延时调到 最小。万事俱备，我们全拥在总编大人寝室那台经过跳频的电脑前，瞪大 了眼睛，看着总编大人按下最后启动的回车键。 我们用于测试的数据翻译成图像就是《仙剑》中的香兰挎着篮子在砖 地上踩着八字形散步（鬼才知道有没有这种散步方式），高难度动作！大 家都是为了显示一下各自模块的“超强功能”。结果砖地是显示出来了， 上面却空无一人。各位大侠均若有所悟地想了一想，道：不是我的错！ 非也，非也，既然空无一人，肯定有问题。我们又盯着屏幕研究，似 要找出破绽，大家都想把错误载到别人头上去。突然间，一个蓝影“嗖” 的一下穿过屏幕，与此同时，我们惊呼一声，于是谜底也就揭开了：原来 是速度太快了！大家嘻嘻哈哈一片，同时心里非常欣慰：原来我们的引擎 的潜力有这么大。 正因为有这一出戏，后来总编大人灵感一发，在作弊模式中增加了快 速模式和视屏测试，这样子就可以得意洋洋地把主人公开来开去，从地图 的这一头窜到那一头，又从那一头窜到这一头，如果再打开穿墙模式，那 更是不得了了，有时候跑着跑着，就不知道把主人公丢到哪个屋子里去了 。但是我和铁嘴开始颇为不满，因为用这种方式，可以到许多不能去的地 方，提前触发事件，结果把故事逻辑搞的乱糟糟的。于是我和铁嘴采取了 一些措施来限制总编大人的权力，比如动态产生人物和事件，使其并非预 先可见，但总编大人又搞了一些花招，对一些不可见的事物也能产生作用 。我和铁嘴无可奈何，不过不久我们也喜欢上使用这些乱糟糟的作弊模式 ，因为它们能大大方便地调试故事逻辑。 我们的总编大人有一个习惯，喜欢把所有的旧版本的程序保留下来， 这样一旦把程序改坏了，就取回原来的版本。这个主意不错，但是要命的 是，总编大人的新版本诞生得太快了，有时候一天之内能出个五、六个版 本，为了区别，程序名也跟着变，如GHPAL34.CPP、GHPAL56.CPP等，眼见 两位数也不够用了，这时我们语重心长地说：我们的版本“更新”地这么 快，可是连战斗模块都还未加进来，是不是有点……总编大人一想有理， 于是我们达成协议，在战斗模块还未加进来之前，主程的版本号不得超过 GHPAL80.CPP。这成了一条不成文的规矩，鼓励着我们抓紧干，不久GHPAL 80.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.动画部分和战斗部分没有改造好，淡入淡出、震动效果没有。 至此我们的故事就告一段落了，我们的引擎还是非常不成熟的，我们 还有很长的路要走。谢谢朋友们的支持。 ----------------------------------------------------------------- |