游戏思想与制作.doc

游戏思想与制作 游戏策划是这样练出来的（一） 准备好了吗？我们的策划案就要正式开始设计了！首先，我们要确立我们要做哪种游戏，RPG?RTG?SLG?AVG?哦？不懂什么是RPG（不会吧？）、RTG、SLG、AVG？没什么，策划就是这样一步步上来的，不懂别装懂，先看看上期的文章！ok?懂了吧！我们继续吧！在这里，我们就要选择RPG来编制。要想把一个游戏做好，并不能只想着如何尽快得将游戏完工，我看过的许多策划案里，常常都是开门见山，一来就是人物、剧情、物品等，这样有几大缺点：一是不能很好的确定中心（也就是游戏的特色）二是很容易落入俗套，让你的策划案和别人的没什么差别。OK，废话少说，如何才能避免这些缺点呢？那当然是首先确定游戏的特色。好吧，现在就开始：（注：本教程是以冰河魔法传策划案为主的）冰河魔法传策划案（一）游戏宗旨：我们的游戏要让您只有想不到，没有做不到/当然，我们并不是要让游戏做得过于复杂，要知道，游戏世界并不是真实世界翻版，而是与真实世界有很多相似点的世界，游戏可以做得更复杂一些，但不是所有功能都必须用，也许你会觉得，这是不是白费工，其实不然，当游戏者在打完一遍后，突然发现游戏的另一种功能，很好玩，而且也可以爆机，玩家肯定会有一种新奇的感觉，必定会重复游戏！这样便有效的延长了RPG游戏的寿命，何乐而不为呢？/这样吧，举个例子，不知您玩过NOX没有，说实话，我觉得那个做得挺不错，凭我的兴趣，我当然是打魔法师了，第一盘下来，我只学了二十几种魔法，我以为我已经学得差不多了，当我打完第二盘时，我已经学了三十几种魔法了，正好那时，我在游民部落里看到了NOX的密码，调起一看，哇噻魔法师总共有六十种魔法！于是，第三盘，我学了四十几种魔法，在第二盘的基础上，多发现了十几个秘密场景，至今我都是兴趣盎然的！如果没数错，我已经打了十二盘了，哈哈一个RPG能做到这样已经不错了！游戏特色预选列表：/所谓预选列表，也就是说，在游戏制作中，由于各种原因，有部分游戏特色会被刷掉。I.建议式战斗系统/上一期游戏思想与制作已经介绍过，没看的，抓紧时间哟！ II.半及时RPG战斗系统/该系统与以往的系统都有很大的区别，具体区别请往下看！III.魔法阵系统/与我很熟的网友，相信这已经不是第n次听说了！呵呵，说起来简单得很！/简言之就是，队友按一定阵型站好后就可以使用一种特殊的魔法。 IV.武术系统/这个难度最大，并且还没有人尝试过，所以我看多半会被刷掉，555/不过，下一期杂志上，我会专门介绍，并且要与大家实际技术切磋一下。V.特殊的升级系统/真的很特殊，简直无法形容，后面的教程会专门介绍。 VI.如果需要，还可以增加我的策划案的第一部分真的很简单，但却很重要，就像大家写文章是要确定中心一样。策划案的结构，千变万化，但有一点不能变：绝对要实用，而不是简单的美观！ 其实这样设计策划案，我也不知道是否能行得通，但我也得试试。回到目录 PC游戏编程（2）转摘 PC游戏编程刘刚 第四章 程序设计 我们在编写自己第一个游戏时,往往是凭借自己的兴趣,想到哪就编到哪,有时连自己都没想到会编出这么大的程序来.那时侯我们对代码的修改往往是很随意和彻底的,因为本来都是自己的东西,而且更希望它更好.可是,程序越写越大,有一个问题就会越来越明显,那就是程序的错误.为了减少错误的产生,我们必须采取一些办法,所以也就产生了程序设计.程序设计的必要性还表现在另一个方面,那就是程序员间的合作.为了让每个程序员对我们所要做的事和我们将如何做这件事有个明确的了解,也为了让管理人员能够从量的角度了解任务的完成状况和进度,我们也必须有程序设计.否则我们就只能象一群乌合之众一般,鬼才知道这游戏要做到什么时侯. 一般,我个人认为,当一个程序需要写到10000行以上时就应该有比较独立的程序设计文档了.可是程序设计文档应该是什么样子呢?很抱歉,我也一直在寻找这个问题的答案.在我刚开始做游戏的时侯,没有人教,于是我翻出上学用的课本,打算来个生搬硬套,写来写去,发现,不行.这样的写法太累了.比如在软件工程课上所讲的数据流图,我好不容易写满了一张八开的纸,马上就发现自己已经糊涂了.就算不马上糊涂,过一段时间我也会认不出那些条条框框是什么了.就算我能记得这些图表的意义,我能够保证所写的代码和图表上的一样么?我写完后,还需要和这些表对一下.就算程序和文档中的内容一样,那如果我的设计方案改了呢?又需要先改文档,再改程序,再对程序.这样对我来讲可太累了. 后来,我才发现,原来书上所写确实有道理,可是它并不是面向我们这些人的,它所面向的是写大型程序的人.这些程序大到需要专门有这样的人来写文档.这些人只要把文档写好再确认完成的程序是否符合要求就可以了,根本不用去写一句的代码.是啊,如果编游戏也有这样的工作就好了.可是很遗憾,目前我尚未遇到可以聘有专职程序设计人员的公司.所以程序设计者就是程序编写者的这个实事起码在我们的目前阶段是很难避免的了. 那么怎么设计文档对我们用处又大又比较节省时间呢?每个公司和每位程序设计人员的习惯都不一样,我只介绍一下我们曾经使用过的一些方法和文档的类型. 程序设计总纲: 无论我们做什么,最先要清楚的一个问题就是:我们做什么?很弱智是不是?但是我发现有些人在很多时侯都不知道自己在做什么.程序设计总纲就是要告诉自己和自己的伙伴们,我们要做的是什么样的游戏程序.它包括: 游戏概述.游戏的背景,类型,操作方法,特点等. 程序概述.游戏程序的编译平台,硬件运行需求,语言,编程重点和难点,技术能力分析等. 程序员概述.参与编程的人的能力和在整个程序制做中的作用和地位. 程序模块划分概述.有本游戏所需要的所有程序,和程序内部的功能模块的划分.这部分只要有比较概括的说明就可以了. 这篇文档的作用就是让所有人都能够了解本游戏的程序将会是什么样子,它的特点是什么,完成它的难点又是什么.以及我们为什么要这样做,有谁来做等这样基本的问题.它所面向的对象除了有自己和本组内的所有程序员以外,还应该有本游戏的游戏策划,美术设计,项目负责人,项目经理,制片人等.如果有可能也应该和本公司的市场,销售,广告公关,出版,甚至公司总经理充分接触,听取各个方面的意见,也充分表达自己的意见.如果能做到制做本游戏项目的所有人员从上到下对本游戏的程序制做都能有一个基本的了解,理解和信心那是最好的. 程序模块划分: 这是对程序设计总纲中最后一个部分的详细说明.说明的内容主要有:该模块的功能,接口,技术要点,所用到的软件底层等.它所面向的对象一般是所有的程序员,但是如果让与程序合作的人员(美术,策划,经理)也能了解则更好,这样可以加强我们之间的沟通,让不懂编程的人也能了解编程人员的苦衷. 一般而言,一个游戏按功能划分(我们很少用其它的分类方法)可以有下面几个部分: 工具部分:在游戏的制做过程之中,从游戏策划的文档,游戏美工的图片到游戏完成,中间必须经过游戏程序的转换和加工.这些数据在进入程序之前必须经过规整,排序等操作.这部分工作过去一般都是由程序员来做的.在人手紧张和工作量比较小的时侯这样做还是可行的.但是如果这样的工作过于复杂,工作量太大,就不行了,我们需要一种方法来提高工作效率.这种方法就是工具.其实我们在计算机所做的任何工作都是在使用工具,唯一的区别只是这些工具都不是我们自己做的.因为游戏本身的特殊性,我们不可能总能找到我们所需要的工具,自己制做就是十分必要的工作. 这些工具也可以分成三个级别:别人的工具,我们自己的可以重用的工具,我们自己的只在本游戏使用的工具.别人的工具是最好的工具.原因很简单,因为它不用我们再去编了,不仅程序Bug较少,操作界面友好和简单,而且开发时间是零.所以如果可能一定要使用别人做好的工具.如果实在没有满足要求的工具,或者我们还需要该工具所没有的功能,我们只能自己编.那么如果这个工具可以被以后用到也不错.所以我们在编写任何工具的时侯,其通用性是我们考虑的首要因素. 工具与游戏其它部分的程序有一个最大的区别,那就是工具程序是独立的可执行文件,它与游戏的唯一交互方式就是存在磁盘上的文件.所以它比较适合交给其他的程序员制做.另外一个特点就是它一般都是针对非程序员的,所以如果工具做好了,也可以很大程度上帮助他们提高工作效率. 底层部分:这部分程序代码的最大特点是可重用性.它是游戏本身与计算机通用系统之间的桥梁,它与游戏的具体细节关系并不大,可以被使用到多种游戏类型和多个游戏之上.这对我们是非常重要的.实际上,我们编写程序所积累的最直接的财富就是可重用的工具和游戏底层. 游戏底层从与游戏的相关性可以有大概三个层次: 最底层:它们向下直接调用系统函数和功能,向上与游戏几乎完全无关,是游戏程序与计算机系统的直接桥梁.它包括: 显示底层.提供游戏显示所需要的所有函数. 文件底层.提供对游戏所需的各种文件处理的接口. 多媒体底层.提供游戏所需的多媒体效果,如声音,视频等.对于三维游戏有模型管理底层.专门保存,处理和显示三维数据. 中间层:它们向下调用最底层的游戏底层,向上为游戏提供函数.与游戏无关.它可能有: 界面底层.使用显示和文件底层,提供界面类库和操作函数. 最高层:它们向下调用中间层和最底层,向上为某种类型的游戏提供特殊的逻辑支持.它可能有: 战略游戏的命令执行底层,显示底层,地图底层. RPG游戏的事件处理底层,场景底层. 这三个层次的制做难度是越来越难的.它往往需要我们在制作过几个游戏之后提炼和总结出来(实际上我们到现在也还没有发展出第三个层次的底层).但同时,这三个层次是越来越重要的,因为它距离一个成品游戏更进一步.我们在写游戏时可重用的部分越多,重用的层次越高,我们的工作量就越少.我们也就越可能有时间研究和开发新的技术,好的算法,我们的游戏也就会越做越精. 相比之下,前面的两个底层都与计算机系统有关,与游戏本身无关;第三个底层与计算机系统无关,与某种类型的游戏有关. 底层部分与工具部分也是密切相关的.一般每一套底层都需要一些工具来与之对应.比如,我的显示底层需要某种格式的图片,我们就要制做一个格式转换和图片观察的工具.把工具和底层结合起来分类,然后把它较给独立的程序员去完成,是一种比较常见的模块划分方法. 当然,我们在做游戏以前也不一定非要什么工具和底层不可,这些东西完全都可以自然产生.假如你能够坚持制做几个游戏,把可以反复使用的程序归纳起来,修改一下,就是一套底层了.如果我们在编写程序时,每时每刻都在想:这段代码是否可以在以后使用,怎样的写法可以使我在以后使用,那么我们在后来的修改工作中就会轻松很多.而假如我们在编写程序以前多花一些时间,把想要做的东西设计清楚,在一开始就可以把它写成独立的底层代码.这样积少成多,我们的财富就会越来越丰富. 游戏本身:这才是我们每次都要做的游戏.所有体现游戏特色的内容全在这里.当然也有的人认为如果我们的经验足够丰富,想得足够全面,连这部分的程序也可以重用起来.以后我们编游戏只要改一下图片,换几个名字,编一段故事,一个新游戏就产生了.实事上,也有公司制做了一些类似游戏工具的东西,其中做得最好的应该是象Director, Autherware那样的多媒体编辑工具吧.但是,它们都有其局限.最明显的一点就是:它们必须针对某一个类型的游戏或只能是多媒体程序,不同类型游戏的制做是有很大区别的,几乎很难用一个固定的模式将其完全函盖.其次,它们创新困难,现在游戏几乎成了创新的代名词,哪一个游戏做出来没有它自己的特点呢?而使用一个固定的工具是很难做到这一点的.第三,难以对它们进行优化.程序的优化往往和程序本身的特点有关,优化的程度越高,它的特殊性也会越大,所以,通用工具只能牺牲一些性能.我到目前还没有看到一个游戏制做工具可以达到商业效果,而多媒体工具之所以成熟正因为制作多媒体产品所需的模式比较单一,对速度要求也不高,没有通常游戏的复杂要求罢了. 所以,制作一个完全可以通用的游戏工具到目前仍然还只是一个梦想.但是,我想这的确是一个很美的梦,如果真的到那个时侯,我们制做游戏将会和拍电影一样简单(我指的只是制做的过程),只需要一个程序员根据策划的意思把图片和声音放在一起就可以了. 每个游戏都是不一样的,但它们都有一些相似的地方,比如: 游戏的操作.游戏者如何操作和控制游戏中的一个或多个主角. 游戏的显示.不是游戏的底层,而是与具体游戏有关的显示部分. 游戏的运动.游戏中有的内容是要不断变化的,包括位置变化,图片变化和形式变化. 游戏的智能.能够与人对抗的思考. 游戏的存储.把所有当前游戏需要的数据保存在磁盘上,然后再重新装入游戏. 游戏状态的转换.从界面到游戏,从游戏到动画,在不同的时侯有不同的操作和显示管理. 我们通常也会按照这样的规律对游戏进行模块划分. 游戏数据结构和算法: 有人讲程序就等于数据结构加算法.这句话很有道理.我们所编的程序其实就是把某种格式的数据(图片,主角的参数)经过一系列的转换,成为计算机屏幕上的数据(游戏本身).所有的数据都需要以某种方式存储,这就是数据结构.而算法因为是与数据结构密切相关的,所以虽然它们不属于同一个概念,我把它们放在一起设计. 我们通常所使用的数据一般可以分成两个部分:数据库结构和当前结构. 这里的数据库不是什么商业数据库软件,而是游戏中所使用到的所有数据的集合.我还没有见到有哪个游戏在存储这些数据时使用商业数据库软件(比如FoxBase)(错了,好象一个大概叫NBA 97/98的使用了标准的商业数据库).也许它们都被隐藏起来了吧,我猜想.但不管怎样,其意义是一样的,我们需要把所有在游戏中用到的数据都以一定的形式储存起来.同商业数据库一样,数据库的组成也是由字段组成,即数据元素.每个数据元素一般是一个类库或结构,有若干的成员.数据元素所组成的数组就是数据库结构中最主要的组成部分. 数据库的内容很多,而且按照一定的规则排列,而真正需要显示和当前需要计算的数据却很少,有些数据还是计算的中间结果,比如主角的位置,主角的动作等,这时侯就需要我们另外存储一些数据.它往往是数据库中的某个字段(数据元素),或一些数据的组合. 如果把数据结构按照功能分类,我们还可以把它分成主数据结构,模块数据结构.它们的定义域是不一样的. 在我们的游戏中,会有许多数据结构的类库,它们之间也必然有数据结构之间的数据传递和保存.如何处理好这些数据之间的关系是编写这部分内容最重要的考虑. 首先是数据结构定义域的问题.在无数的教学课本上都在不断提醒大家,要尽量避免使用全局量.为什么要这样做呢?第一个原因显然是因为这样做的人太多了,我们使用全局量直接,方便,快捷,有什么理由不用呢?而答案也很简单,因为它暗含了错误,因为它不易于阅读和修改.于是我们用两个规则来限止全局量的使用:第一,尽量使用局部全局量,使该全局量的定义域最小,比如基于源程序文件的全局量,只有整个游戏的核心结构是全局范围内有效.第二,对于所有的全局量都对其内容进行全面的封装,如果是类库则使用成员函数,如果是结构,则定义专门的函数对其内容进行处理. 其次是数据的传递.我们经常遇到数据结构之间的互相调用和嵌套, 很多人都喜欢使用指针(又是指针)做这项工作, 因为它象全局量一样:直接,方便,快捷.但是我因为个人水平的问题在使用指针时总遇到一些不便,比如,易于出错,而且一旦出错就是很严重的当机,程序非法退出.要知道现在每启动一次计算机仍然是很耗费时间的. 还有另外一个问题,那就是指针不能存盘,我必须另外制作一套程序对结构的存盘做特殊处理.所以我一般使用索引ID号(句柄)来代替指针.具体的使用是这样的:数据库结构是以数据元素为单位的数组, 数据元素的索引(ID)就是它在数据库数组中的下标.所有其它结构对该数据元素的保存都只保存了该元素的ID号.指针只在从数据库根据索引得到元素时使用.这样的好处很明显,ID号是整型数据,可以通过该值的范围判断出是否有效,只要在其有效范围内,再通过指针取值肯定是有效的,几乎跟本不会出现非法指针的现象. 程序开发计划 有了要做什么和怎么做,下面也就是需要什么时侯做和由谁来做了. 一般我们都会制定一系列的里程碑.比如演示版,原型版(体验版),测试版和正式版等.在这之间也可能会有其它什么版本.然后制定完成每一个版本所需要的时间,主要内容和验收标准.除此之外,我们还有: 程序中每个模块的制作时间的表格, 每个程序员分工的说明,工作量说明. 编程过程中可能出现的风险和问题的说明. 在写完总计划以后,我们还会有更加详细的月计划,阶段性计划,我们还会写程序进度表.我们所做的一切都是为了游戏程序可以按时完成. 影响开发时间的主要因素有很多: 资金因素.这些钱至少应该支持到我们可以把游戏做完,而且能够把我们的游戏向市场推出. 市场因素.是否是销售旺季,是否有同类产品产生竞争,本类型,题材的游戏是否还受欢迎. 策划因素.游戏的复杂性有多大,内容有多少,策划的进度是怎样的. 美术因素.美术的制作进度是怎样的,何时可以提供需要的内容. 技术因素.用户的计算机硬件是否已经准备好.我们的技术是否会过时,开发新技术的风险会有多大.还需要制作哪些外围工具.人员因素.程序员水平如何,配合状况如何. 程序设计人员需要仔细考虑这些因素,才能根据具体情况制定比较完善的程序制作计划. 但是,很不幸,我从没有按时完成一个游戏,所以我目前尚不知道妨碍我们按时完成进度的到底是计划不够好还是执行的人不够努力.总之,在做计划时一定要留有余地,而且我的经验是我们完成游戏的时间一般比计划的要多20%到30%.可是如果按照这样的计划去做游戏的话,一定会把投资人吓跑的.于是在现实生活中这种状况就变成了先斩后奏,写报告的时侯说时间很短,而到时侯我们就因为某些原因不得不脱期,反正钱也花了这么多了,必须再增加投资而把它做完.所以无论是直接制作游戏的人或者投资制作游戏的人,我都希望他们可以对这件事有个比较客观的了解.也许在将来制作游戏可以不必再加班,制作计划也可以按时完成,但是至少在我们这里,还必须随时面对它们,依靠我们顽强的毅力和坚忍不拔的精神把游戏做出来. 第五章 制作流程 等到游戏计划写完,并得到通过之后,我们便开始进入游戏制作的时间.其实游戏的制作可能从很早就开始了,比如早期的技术探讨和准备.而我在这里想再说得稍微远一些,远离现在的题目:程序,而转向整个游戏的制作. 整个游戏的制作过程一般可以分成三个阶段.策划阶段,制作阶段和调试阶段.它们之间的关系一般应该是在策划阶段后期,开始程序和美术的制作,在制作后期开始游戏的调试.它们三者的时间比应该是3:4:3.我认为这是一个理想状态,但是我们往往达不到理想状态,典型的情况是游戏策划迟迟不能定稿,我们不得不在一边设计游戏时一边制作,而到了后期,制作又很难按时完成,必然压缩调试时间,最后只好仓促地发售游戏.它们三者的时间变成了4:6:0.我所说的这种状态当然只是一个极端,但是我想在我们目前所开发的游戏中或多或少都有这方面的问题. 造成这个问题的原因也有很多: 游戏立项不规范.人们不知道为什么要做这个游戏. 策划设计工作准备不足.人们不清楚该做什么,什么时侯做,谁来做. 制作人员水平有限,缺乏经验.自己做不好,或做不快,甚至都不知道该怎么做. 资金.没有钱谁会做呢? 项目缺乏管理,各部门缺乏协调.大家群龙无首,缺乏沟通,最后大大降低士气和工作热情. 但是无论这些因素都是些什么,以及它将如何严重地影响我们,我都觉得只要有一样东西就足以支持我们把这个游戏做完.这就是我们的坚持不懈的努力.现在,我们在市场上的游戏质量都不算很好,但是我要说,只要它被做出来了,就是一个成功的作品.我不管游戏玩家们对我这句话有何看法,我只是认为,在那些作品的背后一定有一个或一些人在努力着.也只有他们才能真正体会制作游戏的艰辛.而且,只要他们还能继续做下去,经验会逐渐增加,配合会更加默契,游戏也一定会越做越好. 游戏程序的制作过程与游戏的模块划分有关,大概可以分成三个阶段:工具制作阶段,底层制作阶段,游戏制作阶段. 底层制作可能是最开始进行的阶段,有可能与策划阶段同时,甚至更早.因为这个部分与具体游戏无关,而可能只与游戏所要运行的平台和我们所使用的开发工具有关.我认为,开始的时间应该越早越好.游戏程序员在技术上的准备如果越充分,制作起游戏来就会越顺利. 在策划大纲基本上完成后,也就是游戏的类型,模式基本上固定之后,就可以开始游戏工具的制作了.游戏工具一般是提供给美术人员,策划人员使用的(当然也有自己使用的),所以在用户界面上应该多多听取他们的意见.这些天天与我们在一起的用户,如果我们都不能好好对待,那就更别提我们游戏的用户了. 游戏本身程序的制作是最耗费时间和精力的地方,如果说底层程序和工具都可以把重点放在结构化和优化上,这部分程序正好相反,我们通常做不到这些.因为我们在写这部分程序的时侯,总是已经精疲力尽了,而且我们的代码已经很长很长,一旦发现了程序错误,能找到就很不错了,更别提把它改得漂亮一点.再加上游戏策划随时提出的一点小改动,就可能要改变我们整体的数据结构,做大的改动几乎是不可能的.所以到了游戏制作后期,把程序员叫作铁匠更合适一些,他们在到处打补丁(注意,千万别在写游戏底层的时侯也干这种事). 在游戏制作的中后期,每当程序员一睁开眼,进入眼帘的就是满是Bug和缺乏功能的游戏,这样的一个程序如何才能变成游戏中真正需要得程序呢?无论当初程序计划制定得多么好,在这时候都显得有些不中用.但这并不说明计划没用,而是需要我们把计划变成我们真正需要的东西,这就是每日工作计划.名字听起来很正式,其实并没有什么特殊的格式,仅仅是把我还没有做出来的游戏的内容一条条地写出来,不必区分什么模块和内容的多少,只要手写而且自己看得懂,然后贴在机箱上,要保证随时看到.这些内容我可能在一个星期后也没开始制做,但是它会时时提醒我还有什么没有做.随着时间的推移,有些项目已经完成了,又会有新的内容写进来,而等到你最后积累出一大叠这种计划单时,你会发现原来游戏已经做完了. 这种办法我一直在使用,有时侯真觉得自己没有长进,做事一点计划也没有,可是它就是这么有效,你不必有什么经验,也不必整天面对着程序发呆,每天只要考虑如何把下面的内容做好就可以了. 不过我还是希望以后的程序员不必这样写程序,如果所有的人都能够每天按照预先制定好计划完成工作,也不需要加班,最终做出的游戏又很不错就好了.希望这不是永远的梦想. 第六章 程序调式 我在前面曾经说过,我不会使用SoftICE来调试程序.这证明我并不是一个很聪明的程序员.这也证明我在调试程序时会遇到更多的困难.让我每天在汇编代码和死机中漫游是件很痛苦的事,所以我总在想如何才能摆脱它们. 如果我不能很快地找到这些难缠的Bug,我能否在一开始就避免它们呢,甚至减少它们出现的机会呢?答案是肯定的. 死机(在Windows系统中经常是非法指令Uhandled Exception错)错误中最主要的来源来自指针,但这并不是说我们就不能使用指针.恰恰相反,我们在很多地方都使用指针,而且出错的机会很少.原因很简单,那是因为我们在使用被保护的指针.如果你能证明你所使用的指针永远都指在合法的位置上,它还会出错么?所以我们在分配空间时大多使用静态空间和连续空间.所谓静态空间就是数组,连续空间就是指针数组.我们通过数组的下标来限制指针的读取,这样非常方便也有效. 封装也是减少错误的很好办法.我们把对内存的分配和释放封装起来,把对全局量的读取封装起来.在查找问题时就可以很快地缩小可疑对象. 对函数的返回值和错误代码的认真对待也可以让我们飞快地找到问题所在.很多人刚开始编程时都认为程序很短小,没必要写那么复杂的错误处理信息,也没必要判定函数的返回值.而我则恰恰相反,无论对待多么简单的程序我都会做非常详尽的错误处理.我甚至把显示错误的对话框写在底层程序中,以供随时调用.假如出现了错误,我就可以迅速知道错误发生的位置以及发生错误的大概原因,我的程序还可以正常地退出,不是继续执行而造成死机. 使用调试信息可以帮助我在Debug版中获得更多的有用信息.比较常用的有Assert()和OutputDebugString().在错误刚刚发生时就拦截它要比它造成了更严重的影响后要好. 代码写得好看一些也有助于查错.假如你在一行中写进好几句代码,你将如何逐行跟踪呢?我们如果把函数,成员函数写得规范对称,虽然麻烦一些,但别人在使用时就会轻松多了. 这些办法都是在我们编写代码时需要注意的内容,我想如果你在准备开始编程时就对此有所准备,那么到你编程结束时应该能够节省不少调试错误的时间.但是Bug是一定会有的,无论你在当初如何注意,因为我们毕竟是人,会犯错误.我想任何人都有过把恒等号(双等号)写成赋值号(单等号)的经历吧(好在在Visual C+ 6.0中有这方面的警告了).没有别的办法,我们仍然需要面对死机.一般的指针错误只会导致非法指令或未知的意外错误,除非你向一个不知名的地方写了大量的内容(比如几百K以上),一般还是可以安全地退到系统中的.这得非常感谢微软, Windows95/98 还是要比DOS好.可是如果你所访问的是系统区域,或申请了与硬件有关的调用,比如在DirectDraw的GetDC()中设置了断点,程序就会直接退回系统或干脆死机. 这个时侯就全凭我们自己了.但是也不要害怕,因为,我们所面对的仅仅是一些代码而已,我们有一个最为严格和伟大的力量:逻辑.这可能是程序员唯一能够全心全意依靠的力量了.所以请大胆地使用它. 如果程序出错,一定有它的道理.哪怕运行一千次只出现一次也是如此.所以我们改正错误的过程实际上也就是找到错误的过程.如何找到错误呢?可以试着用下面的方法: 屏蔽法.把一些代码去掉,再看错误是否消失了,如果已经消失,那么错误可能在刚才屏蔽掉的代码中,再屏蔽掉另外的代码,如果错误又出现了,则错误肯定在这段代码中.要注意的是,这样做不一定能够找到错误,因为,有时侯错误是由两段代码或多段代码相互影响造成的.而且有的时侯我们找到的地方并不是真正出错的地方,你只找到了错误被引发的地方,而真正出错的地方还需要我们再仔细找.比如,一个指针指错了地方,那么我们会发现出错的地方是引用指针的地方而不是修改指针的地方.这时侯就体现出封装变量的用处来了,我们可以很快查出这个指针到底在哪被修改了. 如果上面的方法不能奏效,而且错误是在我们刚刚修改了代码造成的,那么可以使用比较法,找到原来版本的文件进行比较.所以我们需要经常保存备份程序,一方面是为了保证程序不丢失,另一方面也会增加找到错误的机会.尤其是当我们到了编程的后期,我们的程序大都编完,正处于修改的状态,而时间又特别紧迫.如果一旦出现了错误,我们只要比较一下新旧版本,就很容易找到错误. 如果你跟踪了半天也没有结果,几网下去一条鱼也没捞上来,而且必须在全屏状态运行,不能单步跟踪,每执行一遍程序就死机,又需要重新启动,这又该怎么办呢?那也不要担心,我们还有最后一招:输出Log文件.在每一个需要监视的地方,增加一段程序,向磁盘文件输出一段文字,如果程序运行到这里,该文件就会多出一段文字,如果程序运行到这里之前就死机或退出了,那么出错的地方就在这段文字和上段文字之间.虽然这样做比较耗费时间和精力,但是基本上能够找到出错的地方.找到之后,我们再去找出错的原因吧. 但是万一你现在还是没有找到错误该怎么办呢?那也不要着急,我所遇到的找到错误的最长时间是整整一天,有的人达到过3天,但是我目前尚未遇到查找单个错误的时间超过一个星期的.如果你寻找错误的时间还没有达到这个长度,就不要急于认为这个错误你是永远找不到的. 其实最难找的错误并不是这些错误,因为这些错误是确实存在的,所以我们改正它只是时间问题.而比较难以调试的错误并不是每次运行都出现的,有的错误需要特定的环境和条件,比如只在某台计算机上出现,有的错误则需要特定的操作,比如打开某文件,再关上,有的错误则干脆需要运行一定的时间才可能出现,比如运行一个小时.这时侯我们的工作才真正艰巨起来. 这时侯,也往往是开发的最后关头,最紧张的时侯,如果出现了错误,将使我们直接面临一个最严峻的问题,到底是发行时间重要还是修改程序错误重要.我姑且不谈到底谁重要.关键是如何解决这些错误.这里你可以看到,把错误消灭于未然是多么重要.我们工作的重点现在转向了重现错误.使用出错的计算机,频繁重复执行某些有关的操作,随时存盘以保存最近时的信息,都是我们常用的办法. 有的时侯重新启动一次计算机,重新编译所有代码,更换一些驱动程序,都可以解决问题.但是有些问题我必须说明: 第一,要以负责任的态度来解决问题.如果你发现有一个地方很明显不会造成错误,但是修改一下之后错误确实消失了,这时侯千万要小心,因为这个错误可能这样被你又隐藏起来了,在以后的某个时侯(可能是最后的调试期)再次出现,这时侯它将会更加隐蔽. 第二,不要动不动就认为是编译器,驱动程序,操作系统或计算机硬件有问题,而不下功夫去寻找错误.这些东西确实会有问题,但它们出错的机会比起我们自己要小得多,我觉得初级程序员还很难发现它们的错误.有问题还是先从自己那里着手吧.第七章 代码优化 我对代码优化的研究并不深,归根结底是因为我并不是个很聪明的程序员.我曾经见到过一本非常好的书,名叫,英文名是Michael Abrashs Graphics Programming Black Book Special Edition.说它好有两个原因:第一,这本书从头到尾讲得都是程序的优化;第二,我看不懂.我想对于那些高级程序员来讲,他们可能就根本写不出有错误的代码,或者至少他们对于防止程序错误很有一套,总之,程序的调试对他们来讲根本就不是问题,所以他们有的是时间来研究程序的优化.而我所能讲的显然不能与他们相比,仅仅是非常初步的内容而已. 最优化的代码就是没有代码. 我忘了这是谁曾经说过的话.但是我觉得很有道理.有时侯我们把那些外国人想象得多么了不得,其实他们大多只是把这句话应用了一下而已.想一个巧妙的办法有时要比节约几个指令周期有效得多.但是这与我们具体所写的代码和人的经验有关,我们很难只用几句话就把规则说清楚.要知道,游戏的速度有时比游戏的效果重要,如果你对当前我们最需要什么样的游戏有所了解,做起决定就会容易得多. 如果我们真的需要对某些代码进行实质性的优化,那么首先我们要搞清楚哪里最浪费时间.我们常用Profile,VTune或自制的时间计数器来测量时间.往往最浪费时间的代码大都集中在几个函数中,多是大量的循环最占用时间. 优化的级别也有区别:算法级,语言级和指令级. 体现一个程序员水平最重要的地方就是算法.一个好的算法可以使用非常少的代码就实现原来很复杂的操作.而它也是很难做到的.尤其这些算法经常与负载的状况有关,所以需要比较和测试才能有好的效果. 语言级优化就是我们采用较少的C语言代码来代替冗长的.比如使用临时的指针来代替多级的成员读取.把某些赋值语句放到多重循环的外面,使用inline函数,使用指针或引用代替结构赋值,使用指针的移动代替内存拷贝,把初始化操作放在一开始而不是循环之中.它所遵循的原则就是无代码原则,减少需要执行的语句是提高速度的最直接的做法.一般的程序员只要做到这一层就应该可以实现比较明显的优化效果了,这样的程序比较简捷,运行效果也比较稳定. 指令级优化则要深入得多,我对这项工作也并不十分擅长.这里所要用的语言一般是汇编语言,调试和测试也比较复杂,程序不太容易看懂,也更容易出错,有时与硬件有关.但是它所能实现的效果可能是一般人所不能实现的.所以这种方法一般被高级程序员所使用,所针对的代码数量应该比较少,正是刀刃上的部分.这样的优化是以指令周期做为单位的,所以千万要注意,不要让我们费尽心机所做的优化效果,被另外一些很低效的C代码给抵销了. 优化的内容一般有:代码替换.使用周期少的指令代替周期长的指令.比如使用左移指令代替乘数是2的倍数的乘法.使用倒数指令(如果有的话)代替除法指令.这要求我们对80x86的每一条指令都有很熟悉了解.减少分支预测.这是pentium 以上CPU特有的功能,它会在执行该指令前预读一些指令,但是如果有分支就会造成预读的失效. 并行指令.这是pentium 以上CPU特有的多流水线的优势.两条(或多条,在pentium pro以上)参数无关的指令可以被并行执行. MMX指令.在处理大量字节型数据时我们可以用到它,一次可以处理8个字节的数据.指令的预读.在读取大量数据时,如果该数据不在缓存里,将会浪费很多时间,我们需要提前把数据放在缓存中.这个功能大概要在pentium II的下一代CPU Katmai中才会出现.Katmai指令.想一次处理4个单精读浮点数么?那就使用Katmai CPU 中的有关指令吧. 在优化时要注意的问题有: 第一,不要本末倒置.先优化大的内容再优化小的部分.这样我们才总能找到最耗费时间的地方而优化它. 第二,要经常比较.需要对每一种可能的方法进行比较,而不能只听信书上写的.奇迹经常出现在这里. 第三,要在效率和可读性上掌握好平衡,不要光要求速度而不管结构如何,最后造成隐藏的错误.回到目录 游戏扫盲知识（二） 开放游戏必备的几个部分 这里所谓开放游戏，就是指能由玩家自己改变游戏内容的游戏。玩家作为业余爱好者，常常不具备游戏开发的技术，所以为了方便广大玩家能随心所欲的改变游戏内容，游戏开发者常常要为游戏设计专门的游戏开发程序，这里我就简单的介绍一下。 游戏地图编辑器专门用来编辑游戏世界的，在每个游戏里，这都是决不能少的。掌握它也很简单，因为它太直观了！不过要注意几个专业词汇的理解，比如说陷阱，很好理解，就是当主角走到这个陷阱时，便会发生剧情。 游戏脚本编辑器游戏剧情该如何发展，什么时候要说话，什么时候换地图这一系列等等的问题都将会在脚本编辑器里得到解决，脚本编辑器实际上就相当于导演的剧本。脚本编辑器在以前还是游戏必备的工具，但现在有些变了，不少游戏在开发时便使用了媲美C语言的脚本，这对于程序员或许是一种好事，因为编剧本就会跟编程序没有两样了，但对于普通的玩家来说，未必是一件好事，毕竟他们实在是不懂编程序。 游戏物品编辑器这个在小游戏里，存在的必要性不大，但当游戏做大了，没有这个可不行。 游戏人物编辑器小游戏里通常都用不着，因为里面就那么几个人物，几下就搞定了！ 呵呵，有点眉目了吗？刚快找点开放游戏练练手吧！呵呵呵呵呵呵呵呵呵顺便打个广告(众人倒)冰河魔法传理论测试版也属于开放游戏，正处于测试阶段，欢迎您也参与测试。回到目录 图形MUD应该走向何处？如何构筑虚拟世界转载 主题：图形MUD应该走向何处？-如何构筑虚拟世界 版权所有：drhorse2001 原作 今天，随着一部又一部图形MUD被商家们推上市场，MUD（Multiple User Dimension）游戏已经被视为最最炙手可热的网络游戏之一。然而，在热闹背后，人们也许没有发现，这支正开始起步的游戏新军却正在走向死角，发展到了一个看似无法突破的瓶颈阶段：其中有技术上的原因，但更多的是开发者观念的误区所致。先来看一下目前图形MUD的状况：首先是外挂。铺天盖地的外挂程序破坏了原先MUD所具有的平衡，从而直接导致了这些图形MUD的毁灭，如网络三国、石器时代等等。第二是单调枯燥的练功升级模式。纵观图形MUD从开始到现在，所有的游戏都采用了这一纯粹是浪费金钱与时间的模式，无一幸免。这使得大量的用户最终看破MUD，摔鼠标走人。太累了！这是一位MUD资深玩家的感慨。第三是一些图形MUD一味追求3D效果，结果高不成、低不就，成为了所谓的垃圾游戏。试问又有谁会成天逗留在由一堆难看的立方体堆砌成的龟速世界中呢？第四，图形MUD一手培养出来的号称骨灰级玩家。他们又在干什么呢？他们麻木地，或说是机械地，挥洒着成吨的汗水和人民币，所换来的却只不过是几串毫无意义的数字和一堆GM说删就删的数据。也许在追求这些数字和数据的过程中，他们会感受到兴奋与刺激，然而过后他们只可能获得更大的空虚感；玩家当初所期盼的成就感根本就无法被给予。MUD也无法在诞生出令人神往的故事来，因为一眼望去除了毫无生命感可言的机器人，就是无理取闹的PKer，无聊透顶的Flooder和无耻卑鄙的Cheater。现今的图形MUD根本就无法摆脱单机游戏的束缚，失去了其应有的吸引力：几乎所有的用户始终都只是抱着猎奇的心理来玩的，一旦被失望、或不满、或不过就是这么一回事儿的情绪心理所侵袭，他们的流失就不可避免。所以说，现阶段的MUD充其量只是一个个带有游戏功能的聊天室，根本称不上是什么虚拟世界，它们缺少了太多的要素。I?缺乏人与MUD的互动，人与NPC之间无法相互交流NPC的过于简单化使得这一原本构成虚拟世界的极重要元素失去了其应有的光芒，而成了十分机械、呆板的摆设。可以这么说，如今MUD中的NPC成了一根根不点不亮、点了也不一定亮的劣质蜡烛：这不是虚拟世界所需要的NPC，这只不过是普通单机游戏中的NPC。拥有构筑虚拟世界特质的NPC应当具有其独有的行动规律、性格特征及社会背景：应该是完善的，而不是残缺的；应该是与众不同的，而不是批量生产的。这么说吧，即使整个MUD的在线用户数为0，这个MUD也仍然应当让人觉得是充满生气的。这才是虚拟世界。举个例子来说。阿明(NPC名)是A城中一个卖包子的小贩。在现今的MUD中，他永远只是站在街上卖包子，当用户用鼠标点击他，就会出现购买包子的对话框；好一点的，他会在晚间歇市的时候自动消失。这样的NPC根本不够格。合格的NPC阿明至少应当是这样：他应当拥有自己的家，早上（MUD内部时间）他起床洗漱，做包子，包子好了挑担子出门卖；包子卖完了（数量当然应该是有限的）他可能就收摊回家去做自己的事儿，也可能让老婆（如果有）送新出笼的包子来继续卖，也可能在路边放上蒸笼边做边卖。晚上，他也需要睡觉休息。节日里，他也会放自己的假。总之一句话，NPC要有自己的生活。很多人认为这是一种浪费资源的举动。诚然，然而为了使得这个虚拟世界获得血肉质感，而不是让人感觉只是一副干巴巴的骨架，这个问题是必须解决的。他过于功利的游戏是缺乏亲切感的。II?MUD由于升级的模式化而变得枯燥，同时也容易让外挂钻空子放眼当今MUD，有几个能跳出杀敌（做任务）-练功-升级-杀敌（做任务）的模式？如果不能彻底地改变这种单调的模式，除了继续培养大批的练功狂人，MUD游戏不可能再有什么大的进步。用户们厌倦于成天练功升级，于是外挂就应运而生。自动战斗、自动练功、自动任务，无奇不有，无孔不入，而且屡禁不止。本来么，人家上来是寻求欢乐的，不是来浪费食指的（用来点击鼠标）。真的要是禁了外挂，用户们也不再光顾了，因为惰性这样东西不是能够轻易克服的，尤其是在游戏中。III?新手不容性是现今MUD的致命伤现在很多MUD都很讲究上手性：它们不停地炫耀其一只鼠标走天下、或是游戏界面友好，总之，易上手性是其吸引用户的法宝。不错，这是MUD所应具备的基本素质之一，然而，在上手性之外还有一样东西被忽视了，那就是新手容纳性。一个MUD做得再好，先来的人总是不可避免地比晚到的人占有压倒性的优势（现实生活中也是如此），尤其是在已打打杀杀为主旋律的MUD中。于是，新人常常被老鸟欺负，甚至PK；而网络帮派的诞生更是助长了这种歪风。因此说，从一开始的公平游戏发展到不公平是现时MUD的通病。如果无法纠正这个错误，MUD用户的新生力量就无法顺利壮大，MUD从开始时的轰轰烈烈到后来的人迹稀少的悲剧就将再次无奈地上演。如何让一个新人享受到公平的游戏环境呢？第一，必要的新人保护措施及优惠政策。例如不受PK，免费食宿，半价交易等等。这个措施我想很多MUD已经开始做了。有些MUD还专门设立了新人导师机构，好让新人们尽快进入角色。第二，合理的新人限制制度。所有的新人在未达到一定水平之前，可以自愿选择（或强制地）留在诸如武馆、小岛、小城镇之类的保护地中，以熟悉MUD中的一些基本情况；由于和他在一起游戏的也多半是新手，他们之间就可以互相扶助、共同进步。而且当踏上真正之路时，身边也许还会多个伙伴照应呢。第三，通过NPC来表现MUD对新人的友好态度太多的MUD中的NPC对新手老鸟一视同仁的态度让很多用户受不了，拜托，我是新手哎，和我来真的？！其实，多一点来自NPC的帮助，就会使新手对这个MUD多一份眷恋，同时也会少一些整天在闲聊频道里嚷嚷着给点钱吧的网络乞丐。第四，改变游戏本身。这是个较为彻底的解决方法。调整MUD中的平衡度，使得用户始终处在同一级别的难度上，不会因为经验升高了就变得轻松起来，那样老鸟们就会花更多的精力去钻研如何游戏，而非如何欺负新人了。一个MUD游戏是否具有长久而旺盛的生命力，很大程度上取决于对新手排斥与否问题的关注与解决程度。IV?伪开放性-MUD的另一弊病事实上还没有一部MUD真正做到高度自由的全方位开放。然而不少MUD却在未上市前大肆鼓吹其开放性，说的是天花乱坠；待到玩时却发现完全不是那么一回事，一种受骗上当的感觉油然而生。其所谓开放性，也只不过是一些诸如地图行走的限制、Q