这几天，几个同学开始玩起一个新的网络游戏，如故，我依然事站在他们电脑后面看——还是不说这个游戏的名字的好——按照我个人的观点，这个网络游戏还是很不错的，尤其是他的人物配点系统，游戏中的每一个玩家都可以是很个性的。这样虽然在同样的面孔下有着更深层的不同，这样对于游戏性是有提高的。可是，我站在同学后面看了不到十分钟，我就对这个游戏很头疼，主要就是因为——Loading...无处不在的Loading...走过一个地图的时候要Loading...进入一个屋子的时候要Loading...制作道具的时候要Loading...流畅性何在！！！
我不做游戏评论，所以不去说Loading对游戏好坏的的分析。但我是“妇科医生”啊，呵呵。所以，我第一个想到的问题是：
这个问题很好回答，我们先搁下。先说说别的。
前两天，刚从网上下载到了Quake III Arena的全套源代码。看看，还真的不小有22.4兆。这当然是和很早之前公布的Quake II的源代码相比，我就不去比最早的Wolf3D的源代码了。再插一句，大学期间完整读完的非技术书籍不多《DOOM启示录》是一个本。对于ID Software一向的源代码开放做法，从游戏开发爱好者的角度说，真的很欣赏；但我也在想，如果我是开发者，会不会这样做。回来，接着说代码。想想，高一的时候，也就是1999年底，第一次买到Quake III Arena的时候，那是一张完整的光盘，有六百多兆呢，为什么他的源代码就22.4兆？那么多的空间都干什么去了？——资源！就是资源！
安装过Quake III Arena的人留心一下你的安装目录就会发现，里面没有多少文件，但有一个文件非常之大——有六百兆。John Carmack真是一个怪人，他难道把所有的资源全包含到一个文件中间去了？我们想想Quake III Arena这样的游戏，中间包含的资源大概有哪些：人物模型以及贴图，地图模型以及材质，武器模型以及贴图，这是能看到的；还有能听见的音乐和音效——幸运的是现在电脑还不能让我闻到什么，不然材质还要多。这是从最基础的角度想想，就有这么多资源。玩过Quake III Arena的人都指导，Quake III Arena只有一次Loading，就是在开始一场屠杀的之前。如果说Quake III Arena的地图比较小好操作的话，那么Quake III TeamArena可是以地图出奇的大出名的，他也是只有这一次Loading。
一个大插笔之后，大家大概能理解到，游戏的源代码本身是不大的，那么Loading的不是别的，就是Loading充斥着整个游戏中，构架出美丽的游戏世界的资源——图形，音乐，音效，剧情教本等等。游戏中的资源大小，几乎占据的整个发布的游戏大小的90％左右，这点从刚才分析的Quake III Arena就能看出来了。可是，Loading又是怎么出来的呢？
相信，教计算机的老师都会说一句，“读写外部存储设备的操作是最慢的！”这可真是金科玉律。参加ACM2004的时候，我一开始把程序写从了把结果保存入文件，结果5道题目全部Time Out，在重新读题目之后，发现没有必要把结果写入文件，我就把所有结果输出道屏幕，在没有修改算法的时候就有一道题目可以提交了。这是我的亲生经历。而且，游戏在Loading的时候，经常会伴随这一阵硬盘指示灯的狂跳。哦～～～原来Loading就是在把硬盘中的资源Loading进内存。
这样，问题看来就简单了，解决Loading的问题，我就不要读写硬盘就可以了——要是法律不管，我早打死说这话的人了。硬盘是要读的，但不能多读，关键是在要怎么读？怎么读已经是后一步的问题了，从开发的角度来说，“怎么存”决定“怎么读”。应此，对于设计阶段的游戏来说，怎么存资源是关键问题。
在这个神奇国度读了这么多年书的人，都会说套话了。关于“怎么存”的套话，我不用想就成说出下面三种：
套话一：每个资源独立成文件。
套话二：把所有资源放在一个文件中。
这两个还算坦白，第三中可就是最是套话的说法了：
套话三：要经过严格的分析，优化组合，合理安排，存放资源。
看来这两天我是系分蓝宝书看多了。
呵呵，套话说出来总是有道理的，我们来逐一分析一下：
把每个资源独立成文件。这可以说是程序源最高兴的事情。每个资源的ID都直接对应磁盘上的一个文件，这对于写程序来说简直是太美的事情了。加一个资源方便的简直不用动脑子；就算这个资源在开发的一开始用上了，后来又不用了，都不用把这个资源文件从目录中DEL掉，就算压进光盘里也无所谓。因此，这个问题在游戏业发展的初期是最常用的。正如我去年说的，我对96～99年间的游戏很了解。那个时候游戏大多是在DOS下的，在不玩这个游戏的时候，没有UNINSETALL而是要DELTREE。那时，我就有一个感觉，游戏本身也不大，但为什么删起来要删很长时间呢？那个时代的游戏还有一个特点，很大的游戏只要一压缩能压缩的很小，我记忆犹新的就是经典的《金庸群侠传》游戏除了CD声轨之外是154兆，可是用RAR3.0分卷压缩之后，只要12张1.44英寸的软盘就能带走。10：1，多大的压缩率啊。这又是为什么呢？这有回到一个基础概念——“簇”。这是操作系统和计算机组成原理两门课程的内容，我不解释，但可以看看我下面的一个截图：
惊人啊，我的4095个字节，就这么白白的没有了。对！由于，每个资源文件本根是大不到哪里去的。在OpenGL写的贴图程序中128×128×24bi的位图文件可以说是最常用的，就这样一个文件大小是49,206 字节，但占用的空间是53,248 字节。一张位图就浪费了8.2％。
如果每一个资源独立放一下文件，再以Quake III Arena为例，一张地图中的地图元素贴图比如说有100个——这个数字不过分——那就需要一百次的读取外部存储设备。这个时间谁承受的起！！！
这样分析下来，套话一的优点有：
1、方便程序编写
2、资源文件明显，便于管理
缺点：
1、浪费大量存储空间
2、大量的读取外部存储设备，降低游戏流畅性
好处都给开发者占了，坏处踢给玩家了，这样游戏哪里来市场！！！
于这种做法相对立的是“套话二：把所有资源放在一个文件中。”这个就不要做太多的分析了，正和和刚才的分析相反。但，还有一个亲身体会是要谈的。我说过很多次了，WinLPM的核心算法部分很快就写完了，就是一个LZSS的算法的实现。但我花了几乎后门的所有时间在一个问题上，多文件压缩上。“压缩”既然已经实现了，那问题就在“多文件”上。多文件的保存和读取是个关键问题。在参考了一些经典文件格式后，我制定了两个结构体，一个是“压缩文件首部信息”和“压缩块信息”。在“首部信息”中保存着第一个块信息的开始的地址，在“块信息”中记录着当前块的大小和开始的地址。这样在通过定义一个“解压缓冲区”就解决了这个问题。把我简陋的WinLPM中的经验拿到“套话二”中，我们能发现，这中方法给开发人员带来了极大的麻烦，需要一个资源的时候，要通过多次的“地址”和“长度”的定位才能找到需要的资源。而且在这个过程中，还有一个关键的问题，就是不能出现一个bit的错误，只要错了一个bit整个游戏将面目全非。
但套话二带来一个最大的好处——整个游戏中只要打开一次文件。打开的文件就是在内存中的，之后的操作全是在内存中的。速度可以大大的提高。如果，这个文件的大小超过了物理内存的大小，“虚拟内存”“内外存交换”这些事情都可以丢给操作系统去做了，对于开发人员可以半透明了。之所以是“半透明”，当然，如果你想真正的搞效率还是在自己的程序中手工完成这些工作比较好。
看来，“套话二”是一个雷锋式的方法，把困难全留给开发人员，好处全给玩家。
呵呵，到了套话中的套话“套话三”了。看看子面就知道这是一个最优的解决方法，但要我说，这是一种骑墙的，中庸的解决方案。当然他兼顾的一、二的优点，克服的一、二的缺点。的确，在现在的游戏开发中这种方法的确是最常用的。一般都是把同类的资源打到一个包里面，比如把所有的地图模型放到一个文件，所有的地图素材放到一个文件，所有的人物对白放到一个文件等等……这样做，一可以很清晰的管理不同的资源，可以很方便的作出一个管理资源的工具给开发人员使用；而且，开发人员也不必为太多不同种类的资源类型而头疼了。而且，虽然和“套话二”比起来多了几次的文件读取，但这几次的操作和“套话一”比起来可以说是小巫见大巫。
好，既然当医生，已经知道是什么病了，也分析出病因了，总要开一个处方。我们以图片资源的存储为例，给出一个资源存储的例子：
我们先构造一个文件头，这个文件头描述了一些基本的信息：有长度，文件版本，压缩类型，还有储存的图片总数。现在详细的说一下，长度就不用说了吧，文件头的大小。文件版本是给开发者看的，根据版本来用不同的方法打开文件，比如不同的结构，或者其他的。压缩类型是一个以备扩展用的功能，根据标识来使用不同的压缩方法解压缩，在这里可以选一个速度和容量折中的压缩方法。图片总数说的不是单个图片的总数，而是静态图片和动态图片的总数，静态图片可以理解成一个图片，动态图片就是一系列静态图片的集合，这个在后面会说到。
| struct tagFileHeader { unsigned long headsize; //文件头长度 int Version; //文件版本 int Compress; //压缩类型 int AllNumber; //图片总数 } |
然后紧跟一个结构体数组，它的下标为AllNumber个，这个结构描述了每个图片的起始偏移量，这是一个结构体数组：
| struct PicIndex { int offset; //图片偏移量 unsigned long PicSize ; //图片长度，如果是多帧的则代表这个图片集的总共长度 int nFrameNumber; //图片帧数 unsigned long* nFrameSize; //每一帧的偏移量，由于帧数不定，只能动态开辟 } |
然后剩下的就是一些数据了，这些数据已经被压缩了，压缩方式通过文件头的Compress变量来获得。
示意图：
| FileHeader | ----------------------------------- | PicIndex Index[0] | | PicIndex Index[1] | | PicIndex Index[2] | | . | | . | | . | | PicIndex Index[AllNumber - 1] | ----------------------------------- | | | D | | A | | T | | A | | | ----------------------------------- |
值得注意的是后面的压缩数据不是整块压缩的，而是单个图片的压缩，然后放在一起而已，我这样做是为了读取方便，就不用读取一个数据还要把整个文件再解压缩一道了，但这样压缩率可能也会降低。
差不多了，今天医生下班了。今年本医生会在进修中不时的出诊，敬请关注！
