绝
绝色神偷
Unregistered / Unconfirmed
GUEST, unregistred user!
我先提个头：开发游戏常用那些工具呢？如果开发3D游戏有些什么技术问题呢？
绝
绝色神偷
Unregistered / Unconfirmed
GUEST, unregistred user!
最赚钱的东西怎么在这里会报冷门呢？是不是这些技术不便公开？连书店的书
都难看到一本关于游戏开发的书。
都难看到一本关于游戏开发的书。
L
luyear
Unregistered / Unconfirmed
GUEST, unregistred user!
我老是玩游戏，要做的话恐怕不是那么容易吧
开发游戏的难度仅次于病毒，需要大量人力物力
光是美工就搞死一批人
开发游戏的难度仅次于病毒，需要大量人力物力
光是美工就搞死一批人
绝
绝色神偷
Unregistered / Unconfirmed
GUEST, unregistred user!
资料很好，多谢惠赐！欢迎各位有游戏开发经验的朋友探讨游戏开发的先进技术。
X
xdzhan
Unregistered / Unconfirmed
GUEST, unregistred user!
以上文章是前导公司《赤壁》游戏开发小组撰写的文档！
绝
绝色神偷
Unregistered / Unconfirmed
GUEST, unregistred user!
我认为这应该算是程序设计的比较高的境界。我希望各位高手能发表一下
宝贵的见解。这样可以使大家的水平。得到进一步提高。
宝贵的见解。这样可以使大家的水平。得到进一步提高。
O
OpuBF
Unregistered / Unconfirmed
GUEST, unregistred user!
其实不是没有资料，去国外的游戏站点相关资料去看看就知道了。国外游戏编写的书多
的是，但是没发直接定购呀
只能托国外的朋友买了再寄回来，可是.......
的是，但是没发直接定购呀
只能托国外的朋友买了再寄回来，可是.......
S
SINGLBOY
Unregistered / Unconfirmed
GUEST, unregistred user!
没想到有这么多的志同道和的朋友！
我正学VC++，目的就是想向图形方面发张！
我正学VC++，目的就是想向图形方面发张！
X
xdzhan
Unregistered / Unconfirmed
GUEST, unregistred user!
ACD See Ver 2。22 for Win95
简介：
ACDSee Ver2. 22 for Windows 95是由 ACD Systems 公司推出的基于 Windows 95环境
的32位图形文件观察器。该程序可充分利用 Windows 95的各种已有系统资源而不是完全自
行进行设计。用户阅读完本文之后可以发现，虽然 ACDSee提供了极为丰富的功能，但其整
个程序只占用约500KB的磁盘空间。其主要特点有：
· ACDSee是目前基于 Windows 95 环境的显示图片速度较快、容易操作的图形文件观察器
。其可支持BMP，GIF，JPEG，Photo-CD，PNG，TGA和TIFF 等格式的文件。程序借助
Windows 95平台，通过其内建的基于JPEG的32位解码功能，可在 Windows 95环境下实现图
形文件的快速解码。
· ACDSee 提供了类似DOS环境下运行的著名图形文件观察器Qpeg提供的图形文件的快速预
览功能，但ACDSee对图形文件的预览是全彩色的，并在256色环境下其显示速度与只能以黑
白进行预览的Qpeg 不相上下。
· ACDSee 极大的加强了对系统下的文件的管理功能，如文件的复制、移动、删除、改名
及关联创建。对于已创建了关联的文件，用户还可以在其文件窗口环境下使用鼠标右键实现
文档的快速浏览、编辑、打印等功能。用户甚至可不脱离ACDSee环境就可实现运行程序、修
改系统下应用程序的关联等操作。
· ACDSee充分利用了 Windows 95 的系统资源，通过其内建的32位图形解码器可对以压缩
格式存放的图形文件进行快速解码，并可利用 Windows 95平台所支持的DirectX实现图形的
快速播放和刷新。用户还可通过使用其内建的图形文件的预读入解码技术“Read-ahead
decompression”实现对多个图形文件的快速连续显示
(幻灯机功能，slide show)。据其说明文件介绍，ACDSee可能是目前 Windows 95环境下显
示速度最快的图形观察器，当使用 Slideshow 并定义各图片之间的显示间隔为0时，显示
速度最快可达每秒10幅以上，当然，此时图形文件不能太复杂并没有经过压缩处理。
著作软件
动画天地
Animator Pro
Anamator Pro
Anamator Pro美国Autodesk公司开发的二维动画软件，现已成为动画的工业标准，它提供了
影像制作及动画创作两大系统。功能十分强大。
Autodesk Animation Player for Windows 95/3.x
简介：
Autodesk Animation Player (以下简称Aaplay)是一款由著名图形创作软件生产商
Autodesk 公司推出的动画文件播放器，虽然其本意是用于播放由 3D Studio 等软件生成
的动画文件，但由于十分好用，且功能上有一定的特点，在此还是值得推荐给大家的。
Aaplay
可支持的格式有FLI，FLC，RLE，DIB和BMP，从文件扩展名
上可以看出，该程序还提供简单的图形文件观察功能。对于动画文件的播放，Aaplay 的最
大特点是可在播放过程中由用户自行加入声音(WAV文件)，从而实现图像、声音同步播放，
使播放效果更加出色。
1．1 Animator Studio Animator
二维动画制作软件Animator Studio
Autodesk公司于1995年推出了Animator Studio 1。0，这套基于Windows系统的
软件是一种集动画制作、图像处理、音乐编辑、音乐合成等多种功能于一体的二维动画制作
软件。
在Windows中正确安装这套软件之后，系统桌面上就生成了一项Autodesk
Multimedia群组，该群组中有下面几个程序项：
1·Animator Studio程序项，这个程序项是这套软件中最重要部分，动画制作
及图像处理都是通过它来进行的。
2·Animator SoundLab程序项，这个程序项可以对声音进行编辑与合成，可以
用它剪切或粘贴一段音波，可以把不需要的声音（或杂音）除去，可以控制声音的渐入]渐
出、可以使用过滤器来改变声音的音质等，最重要的一项功能就是在进行动画与声音的合
成时去调整声音的时间，以便与动画同步。
3·Animator Scripters程序项 这个程序项可以编辑要播放的动画的脚本，
如将静态图像与动画串起来，再加上声音和播放控制就可以生成一个播放脚本，这对动态演示非常重要。
4·Animator Player程序项，该实用程序不但可以直接播放多种格式的动画文
件，而且可以播放Animator Scriptor脚本文件。
Animator Studio可读写多种格式的动画文件，如AVI、MOV、FLC和FLI等，还可以读写多种
格式的图形文件，如BMP、JPG、TIF、PCX和GIF等。只要使用File菜单的Save As项就可实现
动画文件格式的转换和静态文件格式的转换，甚至可以将一系列动画文件转换为静态文件。
Animator具有很强的图像处理能力，它有大帐篷、套索和魔棒等选定工具，这些选定工具
不但具有与Photoshop、Photostyler等图像处理软件类似工具的一样的功能，而且还可以
作用于整个动画序列或某个动画序列段。
Animator Studio的绘画工具功能很强，有徒手绘画工具、几何绘画工具。此外，它还提供
了20多种颜料，其中最有特色的当数Filter颜料，这也是Animator Studio与Animatoｒ
Ｐｒｏ 的重要区别之一。Ｆｉｌｔｅｒ 颜料使用的是Adobe的外挂滤镜功能模块KPT 2，
利用Filter颜料不仅很容易实现渐变色，还可以使图
像产生一些非常有趣、甚至出乎预料的效果，如产生旋涡、制作出卷页动画等。
Animator Studio增强了动画设计能力，AnimatorＰｒｏ 的某些先进动画工具
也被引入到 Animator Studio中。
Animator Studio具有很强的动画作品后期制作能力，3D Studio的Video Post
提供了一些后期制作工具，但都非常简单，并不能满足实际需要，现在就可以使用Animator
Studio对三维动画作品进行后期制作（编辑和配音等）了。
Autodesk Animator Studio包括四种不同的程序：用于创建或编辑动画、数字视频以及简
报等。
Animator Program：可以对数字图像或电影进行编辑、绘画、处理和动画。
SoundLab Program：可以创建或编辑WAVE声音文件，以及将它们与电影合成在一起。
Scriptor Program：可以将电影、静止图像以及声音合成到一个单个脚本或简报中。
Play Program：可以独立地播放电影或脚本
Animator：提供了很强的绘画和图像处理功能。
可以使用Inks、Tools、Brushes进行绘画和图像处理。通过提供一两个关键帧可以进行Cel风格动画。
1· 绘画和图像处理
Animator提供了很强的绘画和图像处理
如果想对一幅图像进行绘画和图像处理，可以使用：
Inks，Tools，Brushes
Inks直接作用于图像，简单的墨水，例如Color Ink，只是在所作用的地方简单地增加颜色。更复杂一些的墨水（一些图像处理软件称之为过滤器）则对图像进行相应的处理。
Tools直接控制着墨水作用的地方。
。手工绘制工具：随着鼠标的移动将墨水作用于屏幕上。有四种手绘工具。
。几何形体绘制工具：提供了九种规则的几何形体绘制工具
。填充工具：根据原始图像的颜色，进行相应的填充
。文字工具：允许将文字或标题放在电影中
Brushes：控制绘制时笔刷的形状
Cel风格动画
通过使用一两个关键帧，就可以通过使用Animator的onionskin特色创建出运动的效果。
Automated动画：
可以创建出比Cel风格动画更稳定的效果。
视频动画：
Animator不仅可以处理各种手工绘制动画，也可以装入、播放、编辑和保存数字视频。
Animator Studio同时支持AVI和QuickTime电影格式，以及Autodesk的FLC格式。
Anamator Scriptor
Animator Studio
Autodesk Animator Studio包括四种不同的程序：用于创建或编辑动画、数字视频以及简
报等。
Animator Program：可以对数字图像或电影进行编辑、绘画、处理和动画。
SoundLab Program：可以创建或编辑WAVE声音文件，以及将它们与电影合成在一起。
Scriptor Program：可以将电影、静止图像以及声音合成到一个单个脚本或简报中。
Play Program：可以独立地播放电影或脚本
Animator：提供了很强的绘画和图像处理功能。
可以使用Inks、Tools、Brushes进行绘画和图像处理。通过提供一两个关键帧可以进行Cel风格动画。
1· 绘画和图像处理
Animator提供了很强的绘画和图像处理
如果想对一幅图像进行绘画和图像处理，可以使用：
Inks，Tools，Brushes
Inks直接作用于图像，简单的墨水，例如Color Ink，只是在所作用的地方简单地增加颜色。更复杂一些的墨水（一些图像处理软件称之为过滤器）则对图像进行相应的处理。
Tools直接控制着墨水作用的地方。
。手工绘制工具：随着鼠标的移动将墨水作用于屏幕上。有四种手绘工具。
。几何形体绘制工具：提供了九种规则的几何形体绘制工具
。填充工具：根据原始图像的颜色，进行相应的填充
。文字工具：允许将文字或标题放在电影中
Brushes：控制绘制时笔刷的形状
Cel风格动画
通过使用一两个关键帧，就可以通过使用Animator的onionskin特色创建出运动的效果。
Automated动画：
可以创建出比Cel风格动画更稳定的效果。
视频动画：Animator不仅可以处理各种手工绘制动画，也可以装入、播放、编辑和保存
数字视频。Animator Studio
同时支持AVI和QuickTime电影格式，以及Autodesk的FLC格式。
Anamator Scriptor
1．2 Animator Studio Scriptor
3D MAX 系列
3．1 3D MAX 2。0
3D Studio MAX R20
3D Studio MAX R20可以轻而易举地让任何对象生成动画。如果拥有了这样一套软件，就可
以将设计与创意转化为令人惊叹的效果。
3D Studio MAX R20不但是影视和广告设计的强有力的工具，同时也是建筑外形设计和产
品造型设计的最佳选择。通过相机和真实场景的匹配、声音效果的设计、场景中任意对象
的修改、高质量的渲染工具和各种特殊效果的组合，可以创作出逼真的电影级动画。同时
，3D Studio MAX R20具有友善的开发环境，借助其简单的脚本语言，即可自行扩展功能；
如果你是编程高手，更可以用Visual C++ 开发新的插入组件。
1997年8月4日，美国Autodesk公司的 多媒体子公司Kintix在SIGGRAPH 97会上初次亮相，
并宣布了它在PC领域最畅销的动画和模型制作软件的最新版本 -- 3D Studio MAX R20。
该本本是专门针对影视和交互式游戏开发商用的新一代强有力的软件包。3D Studio MAX
R20比屡获大奖的前一版本提高了近三倍的功能和超过一千种特性，而且它支持各种三维
图形应用程序开发借口，包括OpenGL和Direct3D。
你也许曾经为 3D Studio 中漫长的渲染时间感到无法忍受，那么你不妨试一下 3D Studio
MAX 吧，你会发现计算机的渲染速度科“飞”起来了。 Microsoft公司的Windows NT平
台除了32位特性和多任务外，最重要的一个特色就是对称多处理，这可以成倍提高程序的
性能。由于在三维环境中，渲染时间严重影响工作效率，因此用多重处理器把它们分成小
单位，可以大幅度提高程序的潜能。在 3D Studio MAX中，渲染器中的处理被分解到了象
素级，每个象素可以被单独的渲染。这种独特设计，使 3D Studio MAX 可以充分利用装有
Windows NT的计算机的性能。它可以利用PC机的所有能力，并使扩充性能变得容易且有效。
在不增加内存的情况下，仅增加一个处理器， 3D Studio MAX 的渲染速度就可以提就近一
倍。如果你增加了三维图形加速卡， 3D Studio MAX 就可以提供实时的显示反馈，这可以
与价格非常昂贵的UNIX工作站的性能相媲美，Autodesk公司还为 3D Studio MAX加了TCP/IP
能力，这允许将10，000台计算机联成网，而只使用一套 3D Studio MAX 来完成渲染，
这使得渲染提的性能价格比非常好。
3D Studio MAX的新的Windows界面是很重要的成就。即使在一幅单独屏幕上，四个模块视
图之间也相互有相配合，视图顶部是工具栏，右边是部件区，该区域包括工作时需要的所
有选项。这样可以减少工作时屏幕显示的混乱。建模、动画和渲染都在统一的环境下完成。
在 3D Studio MAX中，动画是很容易掌握的。你只需要在Animste氯钮上单击，运动虚拟的
任何对象即可，你还可以在实时着色视窗中及时观察你的动画。在充分享受到了 3D
Studio MAX的完全面向对象的体系结构的优越性能后，你也许还会发现 3D Studio MAX有
先进的光照效果。非常灵活的的材料编辑功能强大且极易使用的工具——但当你看到 3D
Studio MAX的64位超真彩色的渲染质量后，我想你肯定会为之心动。
3D Studio MAX还具有良好的兼容性，它可以输入 3D Studio 的SHP，3DS，PR昨Auto
CAD的DXF文件。不仅如此，为了适应其它NT处理器，Autodesk公司还会交付重新编译
的MAX版本。
当然，作为一个如此优秀的在PC上运行的三维动画软件，它对硬件的要求也是比较高的。
3D Studio MAX的技术说明中推荐的配置是：
· 主频至少为90MHZ的Pentium或Pentium Pro (支持多处理器系统)
· Microsoft Windows NT Workstation 3.51
· 32M内存
· 100M硬盘交换空间
· 在Windows NT下支持800×600×256色的图形显示卡(推荐使用PCI总线下1024×768×256
色的图形卡，1280×1024×24位的双缓冲区的三维图形加速卡最为理想)
· CD-ROM驱动器
· 选件：声卡和音箱、视频输入输出设备
3．2 Character Studio
3D Character Studio
Character Studio为3D Studio MAX的一个标准外挂程序，是一个极重要的插入模块，用来
创建两足动物的模型并设置其动画。它发挥了3D Studio MAX的所有优点，它与Windows NT
截面完全兼容，也可在Windows 95下运行Character Studio（包括Biped和Phyysifue两个
模块）。
Biped模块：新一代的三维人物及动画模拟系统，用来激活两足动物的模型并设置复杂的动
作动画。Biped利用一个步迹驱动过程来初始生成步迹，并且随后利用调整关键帧的结构来
调整动作。还可以用Biped来设置身体任何一个部位的动画，使模型在使用同一步迹时产生
不同的动作，丰富了动画的内容。另外，Biped还可以利用两足动物的生理动力学和重力学
的原理来添加所生成的特征模型的特征。在不需要根据物理特征来激活模型的情况下，
Biped会允许在自由方式（Free Form）的时间段中关闭重力等因素。你用Biped来简单地
设计步迹即可使人物走上楼梯，或条国跳过障碍，或按节拍跳起舞来。更为奇妙的是可以
把一种运动模式复制到任意一种二足动物身上而不需要做重复的工作。这样对于诸如集体
舞之类的创作就变得轻而易举了。
Physique模块：是一个同意的骨骼变形系统。为生成的双足动物模型提供一个躯体骨架。
给他们附以皮肤，从而能够在运动的过程中，根据肌肉运动的要求，皮肤能够产生弯曲、
伸展或者上膨胀的效果。它能够模拟出逼真的人物来，进而创建出“活龙活现”的效果。
3．3 标准外挂模块
3D Studio MAX标准外挂模块
3D Studio MAX自R 1。1以后，自身带有一些标准外挂模块，这些模块之间没有必然联系，
主要有以下几种：
l Adobe Illustrator AI88文件的输入
l 音频动画控制器
l AutoCAD DWG文件的输入/输出
l Bevel（倒角）调整器
l Combustion（燃烧）外挂模块的应用方法
l 凹痕（Dent）过程贴图
l Editable Mest对象及其应用
l 地球体对象的生成
l Mesh Smooth调整器
l 路径变形空间扭曲
l Photoshop图象过滤器的支持
l 使用PNP图象文件支持
l Relax（松弛）调整器
l Relax Transform（重置变换）实用工具
l Stretch（伸展）调整器
l Wood过程贴图
3．4 第三方外挂模块
3D Studio MAX第三方外挂模块
由于3D Studio MAX软件包是一个以外挂模块为构架的动画软件包，所以非常便于开发者作
功能的扩充。随着对该软件包的开发和应用的不断深入，满足各种特殊需求的外挂模块将
会越来越多。目前，已经发布的用于3D Studio MAX软件包的外挂模块以达1000多个。这
里主要介绍其中一部分：
l Torus Knot外挂模块
l MAX VRML输出器外挂模块
l Super Ellipsoid外挂模块
l Push调整器
l EGO外挂模块
l MorphMagix变形动画系统
l ChromaDepth视频后处理外挂过滤器
l MarMatterLite外挂模块
l Edit Mesh 2调整器
l MIDI控制器
l Collector（位图收集器）
l Color Correct（颜色校正）
l Digital Forest（森林）
l Edge Up Filter（边缘锐利滤镜）
l Flat（平面）模块
l Fantom Image（幻像）模块
l Handy Filter Tool（手工滤镜工具）
l ID Select（代码选择）
l KeyCalc（帧计算器）模块
l MultiDeflect Particle Deflector（多反射粒子反射器）
l Object Combustion（对象燃烧）模块
3．5 3DS4
3DS4
3D Studio 是一个三维动化软件，用它制作的动画效果逼真，可应用于图象仿真学，检查历史现象，建筑专业，卡通动画片的制作，广告制作，法律，影视制作，科学研究领域等方面。
IPAS
IPAS 程序是建立在 3D Studio 基础上，可以利用 C 或 C++ 增加其外处理功
能。IPAS 以 PharLap。386 为基础，与 3D Studio 共享内存缓冲区，因此能够更好地处
理各种图形信息。IPAS 在do
S 环境下存在四种扩展名称即 IXP、PXP、AXP、SXP。
3D VIZ
3DS VIZ是Autodesk今年对工程设计用户的新奉献之一，它也是基于3DX MAX的母体技术而
派生出的一项新产品，主要用于概念化设计和可视化设计。
3DS MAX软件主要面向电子游戏开发商和影视动画制作商，虽然它能成功地用于工程设计
（AEC）行业的渲染制作，但不适于在AEC行业初始化造型及工业产品的概念化设计。当
然，3DX MAX提供的各种动画功能远远超过AEC行业对动画漫游的需要，但它缺乏面向AEC
行业的建模工具（如窗、门、屋顶等），而且也不适于建立精确的模型。其他一些软件厂
商虽有一体化解决方案的产品，但要么迫使设计者携带大量的数据和操作步骤进行工作，
使其难度加大和效率降低。要么其中的绘图工具不能满足大型和复杂工程设计的需求。
3DS VIZ是面向建筑、工程、结构（AEC）和工业设计市场的一种用于三维概念化设计和可
视化设计的极好工具。此产品代表着Autodesk在该领域的产品策略，它将成为一种新的开
发平台，用于开发那些需要可视化设计概念交流的应用软件。3DS VIZ会进一步加强和提高
Autodesk现有的规模巨大的AutoCAD软件市场。3DS VIZ首先提供两种版本：一是AutoCADR14
专版，为AutoCADR14用户提供。另一种是可完全独立运行的3DS VIZ软件。许多人非常想知
道3DS MAX和3DS VIZ这两种软件的主要区别，为此我们列出下表以示说明。
主要功能
艺术设计师们需要一种能够理解他们的设计构想并随时能与之沟通的计算机软件，3DS VIZ
就是这样的软件。其特点就是直接面向建筑师和相关专业的设计师。与其他竞争对不手不
同，Autodesk 的 Kinetix分公司能直接把三维多媒体新技术转移到工程设计行业，使已在
影视及交互式游戏制作业中非常著名的三维可视化技术成为工程设计师的强大设计工具。
1.即时反馈
见过3DX MAX的人都知道它是一种完全交互的环境，而3DX VIZ也会使设计师能够使用这种行进的软件技术。
2.材质编辑器
3DX VIZ的软件中有50种新的工程设计（AEC）特殊材质，当应用这些材质时，它们被设计成平铺模式。这些材质附带着数百种位衅及程序效果，材质编辑器可承时让你在屏幕上预视和控制贴图及材质。
3.参数化的门窗设计
在这个功能中为工程设计（AEC）所设计的材质可赋予门和窗，这些材质将赋门窗相应的位置，如玻璃、围栏、装饰、内框、外框等。用户可用3DX VIZ提供的、也可用自己制作的材质迅速预示其效果。
4.剖面功能
任何横切面都能直接输出到AutoCAD软件中，或可作为底图传给其他3DS VIZ模型进行二维
操作。
5.新的二维特性
6.相机匹配
7.拖拽材质
8.拖拽物体
9.自动捕捉
Premiere 5。0
PremierePAdobe Premeiere 5。0
做过视频编辑的人如果没有听说过Adobe公司的 是不可想象的，她拥有简洁的界面，
直观的工作窗，丰富的控制工具，优秀的音频编辑工具而为人称道，并成为此领域的佼佼
者。经过一段时间的沉寂后，Adobe终于将Premeier 升级到5。0极大地扩展了它的功能
，从而拥有了更强的竞争力。Premiere 5。0能够进行专业的数字视频的编辑。它可以满
足小的视频工作室，多媒体和网络影象开发者，个人视频，工业设计展示等诸多方面视频
编辑需要。通过它一流的界面，Adobe Premeiere 5。0也可作为离线编辑器，轻松地进行
要求很高地广播视频电影的后期处理工作，这个令人兴奋的新产品还包括工作室级的音频
工具，并增加了强大的字幕控制能力，关键帧筛选器，提供强大的长格式编辑能力，
另外5。0版本的Premeiere 编辑器也变得更加灵活，Premiere5。0可以跨平台工作，可
以自由地在Windows和Mac平台间进行各种数据的传输。
在编辑方面通过Adobe Premiere5。0，用户可以在传统的非线性编辑上，即用一种允许3
- point编辑和其他高级的编辑技术方法，进行间接的资源重新安排和精确视频定位，使用
插入和覆盖按钮可以很简单地将剪辑定位于时间流程中，视频编辑可以被无缝地连接在一
起，先进的编辑能力还允许作者一边观看视频编辑的原材料，一边在效果监视窗内编辑他
们。
Premeere 5。0使用滑动编辑工具，从而保持在改变剪辑进出点时图像的连续性，因此可以
创作长达三个小时完整的音频食品，无论是NTSC制的每秒29。97帧，PAL制的每秒25帧，还
是电影中的每秒24帧。
使用一个改进的时间流程，你可以十分简单地在时间流程上标记、隐藏、显示、取消跟踪
，在时间流程中增加多达99个视频轨道和99个音频轨道。新的视频轨道可以出现原有的
轨道之上，以便显示电影的最后效果。允许连续撤消32次以前的操作，。
媒体管理方面有了很大的增强，方便的项目选择窗口来显示剪辑：可以在缩略图中用带有
文字说明的缩微图显示，也在图标窗口中用图标显示，或在六表中作为一个文件显示。在
用户定义和内建的数据区中搜索、排序剪辑包括文字、日期、文件路径及类型变得更加方
便。为了在几个项目中同时使用一个同一个视频剪辑，可以建立一个分开的剪辑库。还可
以设置对一个项目定时进行自动备份。
Preiere 5。0拥有21个专业音频滤镜，包括14个新增的滤镜，可以制作高质量的音轨。新
的滤镜允许你精确地为旋律设定一个动态的范围，删除嗡嗡的杂音声，正确控制延时效果
，提取或改变特殊的频率，模拟听觉的内部效果。通过自动调节引入的音频来协调声音播
放速度。可以精确指定用于网上循环播放的小数据量的高品质的音频抽样。可以工作在3
2kHz到44MHz声音速率上，完全满足数字视频（DV）格式的需要。
设计人员可以精确地控制文字标题的滚动和移动，并可绘制文字或图形。在每一定义的
文字块内都可改变文字的大小、牙色和其他属性。可以设置标题的进入和离开位置，停
留多少秒和具体的帧数。文字的编辑效果可以很容易地在标题窗呃逆看到。Adobe
Premiere 5。0提供大量特殊效果的滤镜，引入了PhotoShop的兼容插件，包括调节色彩的
平衡、明暗度、对比度、润化、扭曲变形等。用专业调节工具可以给添加的剪辑指定色度
、亮度、alpha通道或平滑程度。在动画方面，可以为一幅静止或运动的图像指定其运动
的路径，并可以同时设置诸如盘旋、缩小或放大、转动以及扭曲等各种特殊效果。再调
节时间效果上允许只任意个关键帧。还提供一个能很快地根据用户需要进行歼击间的特
效过度的转变面板。
扩展的硬件和软件支持，给用户带来了更大的灵活性。它可以和Adobe家族的其他软件，
Adobe Photoshop、Adobe AfterEffects及Adobe Illustrator进行良好的协作。能够自
动识别eps文件。并引入了photoshop层的概念。
Premiere 5。0有了强大的音频或视频捕获能力。视频的捕获可以通过人工或第三方设备
的控制来指定时间的起始和终止位置。甚至可以捕获DV格式的文件。不过这时需要一个
FireWire IEEE -1394端。你还可以为自己的视频捕捉卡设置存储特征。Premiere 5。0
还能够自动地捕获一批视频、为视频生产提供强有力的支持。
Premiere 5。0支持多种食品格式，包括大家所熟悉的AVI、MOV格式、引入视频还可以用
AVC（Preception Audio Video）和PVD（Perception Video） 格式。输出的格式还可以
用，AIFF（只在MAC平台）、flc/fli，以及一些静态图像格式，通过外部设备还可以输出
MPEG格式的文件。
也许您对Premiere 5。0并不十分熟悉，通过上面的介绍还是没有把握自己能否很好地应
用这些新特性，那么从现在开始。将逐渐介绍具有Premiere 5。0新特性的棉班和编辑工
具以及如何利用他们编辑您所需要的食品文件。
Adobe公司重新设计了Premiere的编辑截面，为了提高编辑的效率，更直观地得到专业
的编辑效果，去掉了许多不必要的窗口。当您进入Premeiere 5。0的时候，会首先看到
监视窗，新的监视窗强化了它在剪辑窗、预览窗、修饰窗和控制一贯拥有的强大的编辑
工具，这些有效的工作区提供了两个工作区，资源区和编辑区，用户可以把他们定制成
老版本样子，或干脆使用热键。
上面的图一是监视窗：
A· 是资源区，双击或拖动任意的剪辑，都可以查看或编辑他们。
B·这里是资源选择菜单，在这里可以选择你想编辑的剪辑资源。
C·这些按钮使用来控制资源的编辑和播放的。可以通过他们来播放、快进、倒退、循环
、停止至开头结尾等。
D· 这两个按钮一个是插入资源、一个是覆盖资源，可以将新的资源插入到时间
流程中，或覆盖当前的资源。
E· 单击上面的按钮可以从时间流程中删除某一片段，留下一端空白；单击下面
的按钮也是删除某一片段，只是后面的会紧接上来。
F· 这些键用来设置音量，缺省的转换效果，以及回到上一次或下一次的操作。
G· 和C的作用基本一致，他们用来控制观看所编辑的节目的结果。
H· 这个键用来分离监视窗的控制功能，用在有视频捕捉卡和视频显示卡的NTSC
或PAL制的监视器上。
I· 选择想插入的音频或视频剪辑。
J· 节目观察窗
K· 单击这里将弹出一些选项来控制监视窗的组成。包括跳换到修饰模式
（Trim mode）、显示单一窗口，修饰模式和但一显示适合编辑两相互有联系的剪辑。
L· 选中这一项可以将资源和节目关联在一起，有助于观看各种资源是如何被
组织的。
<图片>
Adobe Premiere
随着多媒体技术的发展，计算机技术和视音频处理技术有机地结合起来，形成了全新
的电视节目制作概念——非线性编辑。
目前，在众多类型的非线性编辑系统中，使用较为广泛的非线性编辑软件是 Adob
e Premiere。它融视、音频处理于一体，功能十分强大，与一些视频影像采集压缩回放
卡件象DC20、FPS60、AVmaster等配合使用，可以完成高质量的广播级视、音频制作。
Adobe Premiere支持 Microsoft video for windows格式的．avi文件，Quick Time
Movie格式的．mov文件和.flm文件。对动画文件它支持．flc，·fli。 以及．tga，
，bmp，.rle，.dib，．tif顺列文件。 对静止图像它支持．psd，．bmp，.rle，．
dib，.pic，.umf，.tif，.pcx，.jpg，.tga，.vda，.icb，.vst。对于音频文件它支
持．wav，.aif。由于Adobe Premiere能支持众多的文件格式，因此可以和许多也支持
这些格式的软件配合使用，这使得 Adobe Premiere的功能更加强大。Adobe Premiere
4．0版，一般硬件环境要求是486机、8M内存、100MB硬盘、16位视频卡。软件环境为
：MS—DSS5.0、Windows3.1。当然，为了完成高质量的非线性编辑处理，上述硬件环
境是远远不够。
Adobe Premiere能够替代线性编辑方式中的许多硬件设计，其主要功能如下：
1．动态视、音频采集
Adobe Premiere可以配合计算机上安装的视、音频处理卡件，对来自摄像机、影碟机、
录像机或录音机等视、音频设备输出的动态模拟信号，进行数字化处理并实时动态采
集。对视频信号来说，可根据需要和硬件环境进行软件压缩或硬件压缩。硬件压缩比软
件压缩更快、更有效，要制作高质量的视频，必须使用硬件压缩。比如， Adobe
Premiere配合DC20卡、SCSI—2硬盘，能够实现一帧两场、每秒25帧(PAL制)、24位
颜色深度、?68×576分辨串的视频影像的实时采集及输出。软件压缩分为 Video for
windows和 Quick Time两类，每一类都提供了多种压缩算法，这些算法各有不同的特
长，可灵活选用。一般来讲，如果仅仅是在计算机屏幕上显示视频或是在CD—ROM上播
放。选用软件压缩是十分有效的。对音频信号来讲，可以选择不同的取样频率以及量
化值，既可与视频信号同时采集存在一个．avi文件中，也可单独采集。视、音频文件
的输出可以说是采集的逆过程，软件按存储文件中记录的压缩法代码找到对应的压缩／
解压缩驱动程序，将视频文件解压缩输出，另外在采集动态视频时，AdobePremiere可
对图像的亮度、对比度等参数作必要的调整，如果硬盘速度不够快，还会指示出丢帧率。
2．视、音频非线性编辑及特技处理Adobe Premiere具备99轨视频和99轨音频，可精确实
现声、画同步，并以帧的精度实现编辑，和传统的线性编辑方式相比，使用Adobe
Premiere使整个编辑工作更为简便、轻松。其 A、B两条视轨相当于 A/B卷编辑中的两台
放像机，计算机的硬盘相当于磁带，我们采集到的视、音频片段以及其它软件制作的二、
三维动画以及静止图像都以数字化文件存在其中。在整个编辑过程中，只是在视、音频
轨道上实时调配出入点的画面和声音，一旦发现错误，可立即还原而不影响原始文件。
在任意编辑点插入一段素材，编辑点以后原有素材可以向后推，删除一段素材，被删除
素材之后的原有素材可向前补，每段素材可以任意截取多次使用，对于简单的切换可实
时观看编辑效果。静止图像的持续时间可以任意设定，运动影像可通过设定时间实现—
100~100倍的快、慢动作处理。Adobe Premiere具备强大的数字特技功能，它具有58种
基本特技、75种画像方式，这是传统特技台无法比拟的。利用这些功能，可以实现诸如
视频图像的叠化、圈入圈出、三维卷页、翻转伸缩、波浪、柔化、飞入飞出等特技画像
效果，还可实现声音信号的混响、变声等效果。在画像和特技框中有一些参数设定，通
过调整它们的数值，可使同一种方式产生多种效果。 AdobePremiere还可将连续视频影
像存成.flm文件，在 photoshop中调出．flm文件，使用 pnotoshop带有的图像特技处理
工具对有关图像进行特技处理，然后再由Adobe Premiere调用。 由于 photoshop本身的
图像特技功能也十分强大，这使得 Adobe Premiere如虎添翼。为了方便编辑， Adobe
Premiere还提供了预演功能，编辑效果可通过预演窗口随时观看。
3．抠像与字幕制作
Adobe Premiere提供了14种类型的抠像(key)方式，用于除 A、B视轨外的97条视轨。
这意味着除 A、B视轨外可实现97层不同视频影像的叠加，传统的特技台无法做到这一
点。其中Alpha抠像方式的运用，使得其它软件处理的图像，在 Adobe Premiere中能方
便地混合叠加。字幕与图像的叠加也是通过抠像方式实现的。 由于采用了边缘抗混淆技
术，叠加的字幕或图像边缘光滑无锯齿质量很高。调整抠像设置的某些参数，还能方便地
控制叠加图像的范围、透明度以及谈入淡出等等。在 Adobe Premiere中设有专门的字幕
制作窗口，其自身带有多种英文字体并配有简单的绘图工具，使用中文之星还可实现中文
字幕的制作。 字幕的颜色可通过调色板选用，也可直接给出 R、G、B值，字幕的运动轨
迹可随意设定，并能产生阴影、浮雕等特殊效果。
目前，Adobe Premiere的4.2版已推出。这一新的32位软件比前一代16位产品处理速度快
了两倍多，可以在后台处理视频图像，还提供了一些极好的新功能，其中包括重要的
Internet优化技术。对高分辨串、CD— ROM质量的视频，提供了诸如批处理和可控关
键帧等一些增强功能，支持更好的回放质量并为交互式视频操作提供更快的反应时间。
另外，它还增加了数十种新的数字特技程序，包括 Camera View和 Audi。Suap，前者
可以从简单的视频剪辑中生成漂亮的3— D效果，后者可在回放期间来回交换左、右声道
。虽然 Adobe Premiere是一个相当不错的软件，但包括4．2版在内仍有美中不足之处。
第一是它不支持较为流行的 MPEG文件，使用受到一定限制。 第二是宇幕制作功能与国内
厂家的中、英文字幕软件相比较为薄弱。第三是介面较为复杂，许多菜单需要打开，特别
是编辑片段较多时，更让人感到屏幕空间的狭小。综上所述， Adobe Premiere和其它软
件一样都有其优点与不足。在实践中，我们应注意 Adobe Premiere与其它软件配合使用
，以取长补短产生最佳的综合效益。
游戏修改器
FPE 6．0整人专家
一、 简介
FPE通过修改游戏资料，可以达到所向无敌或无中生有、源源不绝的效果。
本程序为纯Windows 95 32位的应用程序，而且能够加参数 -b在Win95内修改以DOS模式
运行的游戏，并不适用于Windows NT或Windows 3．1。
l FPE 6．0正式版的特点
1. 超强的分析功能：完全的整合了高低阶分析，能够同时连续分析10进制、
16进制、字符串、浮点数和不知道数值的目标。
2. 超快的分析速度：比FPE 5．0快许多，超过了同类软件
3. 超强的拦截能力：测试到目前为止，所有的游戏都能够以热键呼叫FPE6．0
4. 完整的表格功能：除了完整管理功能以外，如果懒得分析还能够直接上网抓
别人改出来的记录直接使用
5. 完整的内存编辑能力：能够以PCTOOLS同时编辑十进制和十六进制的方式，
分析编辑一个程序4GB实际和虚拟内存。
6. 抓图能力：能够直接连续抓取DirectX 5．0以上的游戏图形，存成BMP格式
文件，并能立即看图及管理。
7. 完全图形截面：能够完全以鼠标操作，界面方便美观；
8. 完整的支持：支持Voodoo，Direct 3D的游戏；
9. 免费的转换图形格式程序：可以互相转换BMP、GIF、JPG的格式。
一、 呼叫FPE
只要在游戏中按下热键（内部为键盘右边灰色的*）就可呼叫出几
乎所有的游戏。也可以自己设置一个热键，只要用鼠标点一下“Hot-Key”那个栏位，单
击该键，然后再单击 “Update Key”按键即可。
如果修改的是DOS box执行的游戏，由于Win95先天的限制，需要按下“Ctrl”
+“热键”来呼叫出FPE。
另外还有一种方法可以选择一个程序来修改，在“Others”菜单内单击
“Refresh”按键，FPE会列出所有的窗口及程序名称，可以以鼠标单击一个即可，以
后就以“Alt”+“Tab”来切换游戏和FPE。
二、 功能说明
1· 分析内存（Scan）
FPE是以分析内存变动情形来找出目标的，所以必须在目标的数值有所变动时
，以FPE来分析它。例如我们玩红色警戒（Red Alert）for Win95版，刚开始有资金4000元
，然后。。。
*步骤一：以热键呼出（*）FPE，在 “Scan target”的位置输入目前的数值
“4000”，然后按下“Start”按键，FPE开始分析：并把可能的内存数告诉你，然后单击
右上方的 “Game”按键（或直接按Esc键），回到游戏中。
*步骤二：回到游戏后随便花点钱，例如钱剩下3700时，重复上述步骤，直到
只有三个可能的内存为止。
*步骤三：在下方的内存列表内h：代表该内存的十六进位数值，“d：”则是
十进制，可以以“Ctrl”+“鼠标左键”选择数个地址，或以“Shift”+“鼠标左键”选
择一排的地址，或直接以“鼠标左键”选择单个地址，然后按左边的“Add”按键，把他
们加到表格内。如果要强迫列出所有可能的内存，可以直接按左下方的“Relist”按键
，FPE不管目前有多少可是的内存，都会列出
*步骤四：在Value位置输入想要锁住的值，例如输入9999，以后该目标就会
一直保持9999不会减少，Comment是注释，Auto Lock则为切换是否自动锁住。然后按OK
就会加入表格中。
*步骤五：如上图所示，加入表格后就大功告成。
2· 编辑内存或文件
FPE 6．0的编辑功能可以编辑内存或文件，可以修改游戏的进度，而且FPE还
有独一无二的搜索或是编辑十进制、16进制、字符串、浮点数和未知数的能力；而且能够
恢复（Undo），不怕改错。
3· 抓图能力（GPE）
FPE 6．0正式版能够直接连续抓取DirectX 5．0以上的游戏图形，保存为BMP
文件，并能立即看图及管理。
三、 Game Worm
Game Worm 强大的游戏修改器
Game Worm是一个不同于大多数游戏修改工具的新一代运行于Win95上的游戏
修改工具。它既充分考虑到Win95游戏、又兼顾DOS游戏的在Win95下运行的游戏修改工具。
作为一个32位的应用程序，由于使用了智能内存搜索，Win95游戏在线激活等技术，Game
Worm具有超强的激活能力，使修改游戏变得更容易和有趣，同时又非常稳定，充满乐趣。
随着微软Win95的普及，越来越多的游戏厂商将目光描向了基于 Win95游戏开
发。由于Windows系统集成了多媒体的功能，并且微软提供了专门用于 Win95游戏开发软
件包，使得Win95游戏大量涌现，并且出现了一批优秀的游戏软件，如MDK、TOMB等。
游戏蛀虫由于使用了Win95游戏在线激活技术，使得少数其他游戏修改工具无法修改的游戏
，可以被蛀虫非常容易解决。例如MDK，在切换画面之后就再也无法切换回来；Road Rash
就根本无法激活如PE之类激活能力较强的游戏工具。而对于游戏蛀虫来说，解决此类游戏
非常容易。
游戏蛀虫不仅可以方便地修改Win95游戏，还可以修改DOS程序和磁盘文件。
GameWorm由三个模块组成：W32蛀虫、DOS蛀虫和DISK蛀虫。W32蛀虫专门为Win95游戏设计，
而DOS蛀虫可对Win95游戏及在Win95下运行的DOS游戏均有效。DISK蛀虫可以对游戏存盘文
件进行扫描和修改（不必切换窗口）
游戏蛀虫的功能十分强大！以下列出其主要功能：
。支持精确/模糊查询
。支持字节/双字数值类型的搜索
。用户可自定义W32蛀虫和DOS蛀虫的呼叫热键
。修改地址存取功能 – 免去重复劳动之痛苦
。Win95游戏可在线激活 - - 不切换屏幕
。修改结果可发布共享
。给搜索项加注释，记忆非常方便
。可一次修改多个地址
。高手模式给高级玩家提供更多修改乐趣
。齐全的在线帮助易学易用
。支持地址锁定
。超强稳定性
。文件扫描功能
PhotoShop 5。0
PhotoShop 50
1. 文字处理
较以往版本有重大的改动，以前的文字一旦形成图形就没有改动的可能性，
PhotoShop50可以改变这一缺陷，文字处理可恢复为文字处理信息，可任意改变字体与字
号
2. 具有无限的UNDO和REDO功能，更加强大更加完美
3. 更加悦目、精确的色彩管理和色彩矫正功能，印前处理更加完善与趋于精美
4. 新增加SPOT-COLOR CHANNEL（SPOT色彩管理通道），处理更加方便快捷
5. 增加了大量的自动流程图、批量处理工具、减化了以往复杂的工作程序
6. 更加精确、有效和易于控制的选择、测量工具
7. 为第三方厂家提供了更加开放的PLUGING开放空间
Adobe公司的Photoshop图像处理软件一直被作为2D图像设计的首选。它强大的
图像处理功能让设计人员梦想成真，而且Photoshop 一直在不断革新，每次推出的新版
本都会有许多更贴近用户的改进，一些繁琐的操作将被简化，软件运行速度也越来越快。
4·0版想必一已被广大用户所接受，Photoshop爱好者日益增多，电脑美术设
计大赛也正如火如荼的举行。4。0版本及4。02版本满足了大部分使用者的需要—专为MMX
作优化，增加导航视窗（Navigator）及电子水印（Digimarc），增加对网络图像格式的
支持，而且可以进行双字节文字处理（能直接输入汉字），等等。当Adobe公司并未固步
自封，他们想让Photoshop闯入专业图像设计领域，占领市场。
一、 为任何媒体设计令人满意的图像
在越来越广泛和多样化的媒体形式领域内，Adobe公司的Photoshop已成为制作
数字图像的行业标准。它能提供设计师所需的用来制作高质量图像的所有构件。不仅仅用
于印刷业和多媒体，也被应用于国际互连网上。
面对突飞猛进的网络图片和专业图像制作技术。一个颇具普遍性的挑战正被人
们重视起来—必须制作出高质量图片存储，印刷格式。Photoshop 5。0提供最快捷和最智
能化的解决方案。可编辑文本层面可以让设计师轻松实现对字符界面、字符间距和文本核
直等项目的精确、专业控制。实现自己的创意甚至简单到用鼠标双击即可。增强型文本和
图像层具有生动的光影、辉度、斜度效果，在编辑完一个层面（Layer）之后，它会自动与
原图片溶合在一起。
独具特色的多重撤消能力让设计者自由构思并快速的从错误中恢复原始状态。
以往复杂繁琐的步骤被简化至只需简单的单击或双击。用户甚至可以输入Eps，
Illustrator及PDF格式文件，然后轻松的与自己的图像结合起来。总而言之，无论你从
事任何媒体创制工作，Photoshop 5。0都能提供强有力的专业支持。
二、 真实再现缤纷色彩
色彩控制是数字化环境中实现高保真色彩的最难解决的问题之一。Adobe公司的
Photoshop 5。0提供给用户确保专业水准的广泛、丰富的色彩控制和再现技术。
灵活的配色通道（Channel）可以在任何印刷工作中轻松实现特殊墨水，油漆和
其他印刷效果。这样就不必降低标准从而实现满意效果。Spot-Color技术允许设计者轻松
将精密色彩用于广告设计等消费型艺术品上，甚至可以添加混合图版到CMYK图像中。这些
高质量色彩可以直接自Photoshop 5。0打印出来，也可输出存储成为DCS2。0格式，以供
在其他应用软件中使用。
从输入到输出，我们尽可信赖Photoshop 5。0色彩再现能力，因为Photoshop
5。0所提供的细致色彩获得ICC工业标准人证。在5。0版本中，广泛支持48位和64位色彩
图像，从而实现比32位更优秀的色彩保真度。色彩矫正技术使用户可以控制一个图像中不
同部分的色彩效果。新增添的通道（Channel）和混合器极大地增强了调整色制，例如色
调、饱和度以及曲率等的控制能力，更高的精确度完全满足精细色彩矫正工作的需要。
简言之，Adobe公司的Photoshop 5。0所提供的崭新色彩控制和校正技术适
应专业要求，在打印纸上，在显示屏上，可以轻松制作高质量的图像。
三、 自由构思从此开始
专业图像设计需要自由的编辑作品，同时又不致于浪费宝贵时间，从而在最
短时间内完成设计任务或制作复杂的图片。采用最新“历史调色板（history palette）
”技术的Photoshop 5。0能解决以上问题，让设计师重获自由 。
Photoshop 5。0的回退功能（Undo）不单单是以往简单的恢复或退到上一步
工作，历史调色板可以列出所有近期完成的步骤，这样你就能放心地将图像回复到先前任
意状态—仅仅是用鼠标进行单击。甚至可以为你的作品拍摄几张不同阶段的“快照（
Snapshots）放在历史调色板顶端供以后工作时随心所欲的调用。
别具一格的“历史画笔”（History Brush）与历史调色板齐心协力，互相
配合，可以让设计者将当前图片与某一“快照”或者较早状态图片中最佳部分相结合。
还原、重做、结合以及试验。
可以说，Photoshop 5。0中的这些撤消功能不仅仅是增添的选项，同时它们
将会成为一种标准，被其他软件所接纳，赋予使用者以急需的专业控制能力。
1. Premiere 5。0
PremierePAdobe Premeiere 5。0
做过视频编辑的人如果没有听说过Adobe公司的 是不可想象的，她拥有简洁的界面
，直观的工作窗，丰富的控制工具，优秀的音频编辑工具而为人称道，并成为此领域的佼
佼者。经过一段时间的沉寂后，Adobe终于将Premeier 升级到5。0极大地扩展了它的功
能，从而拥有了更强的竞争力。Premiere 5. 0能够进行专业的数字视频的编辑。它可以
满足小的视频工作室，多媒体和网络影象开发者，个人视频，工业设计展示等诸多方面
视频编辑需要。通过它一流的界面，Adobe Premeiere 5。0也可作为离线编辑器，轻松
地进行要求很高地广播视频电影的后期处理工作，这个令人兴奋的新产品还包括工作室
级的音频工具，并增加了强大的字幕控制能力，关键帧筛选器，提供强大的长格式编辑
能力，另外5。0版本的Premeiere 编辑器也变得更加灵活，Premiere5。0可以跨平台工
作，可以自由地在Windows和Mac平台间进行各种数据的传输。
在编辑方面通过Adobe Premiere5。0，用户可以在传统的非线性编辑上，即用一种允许3
- point编辑和其他高级的编辑技术方法，进行间接的资源重新安排和精确视频定位，
使用插入和覆盖按钮可以很简单地将剪辑定位于时间流程中，视频编辑可以被无缝地连
接在一起，先进的编辑能力还允许作者一边观看视频编辑的原材料，一边在效果监视窗
内编辑他们。
Premeere 5。0使用滑动编辑工具，从而保持在改变剪辑进出点时图像的连续性，因此可
以创作长达三个小时完整的音频食品，无论是NTSC制的每秒29。97帧，PAL制的每秒25帧
，还是电影中的每秒24帧。
使用一个改进的时间流程，你可以十分简单地在时间流程上标记、隐藏、显示、取消跟踪
，在时间流程中增加多达99个视频轨道和99个音频轨道。新的视频轨道可以出现原有的轨
道之上，以便显示电影的最后效果。允许连续撤消32次以前的操作，。
媒体管理方面有了很大的增强，方便的项目选择窗口来显示剪辑：可以在缩略图中用带有
文字说明的缩微图显示，也在图标窗口中用图标显示，或在六表中作为一个文件显示。在
用户定义和内建的数据区中搜索、排序剪辑包括文字、日期、文件路径及类型变得更加方
便。为了在几个项目中同时使用一个同一个视频剪辑，可以建立一个分开的剪辑库。还可
以设置对一个项目定时进行自动备份。
Preiere 5。0拥有21个专业音频滤镜，包括14个新增的滤镜，可以制作高质量的音轨。新
的滤镜允许你精确地为旋律设定一个动态的范围，删除嗡嗡的杂音声，正确控制延时效果
，提取或改变特殊的频率，模拟听觉的内部效果。通过自动调节引入的音频来协调声音播
放速度。可以精确指定用于网上循环播放的小数据量的高品质的音频抽样。可以工作在32
kHz到44MHz声音速率上，完全满足数字视频（DV）格式的需要。
设计人员可以精确地控制文字标题的滚动和移动，并可绘制文字或图形。在每一定义的文
字块内都可改变文字的大小、牙色和其他属性。可以设置标题的进入和离开位置，停留多
少秒和具体的帧数。文字的编辑效果可以很容易地在标题窗呃逆看到。Adobe Premiere
5。0提供大量特殊效果的滤镜，引入了PhotoShop的兼容插件，包括调节色彩的平衡、明
暗度、对比度、润化、扭曲变形等。用专业调节工具可以给添加的剪辑指定色度、亮度、
alpha通道或平滑程度。在动画方面，可以为一幅静止或运动的图像指定其运动的路径，
并可以同时设置诸如盘旋、缩小或放大、转动以及扭曲等各种特殊效果。再调节时间效
果上允许只任意个关键帧。还提供一个能很快地根据用户需要进行歼击间的特效过度的
转变面板。
扩展的硬件和软件支持，给用户带来了更大的灵活性。它可以和Adobe家族的其他软件，
Adobe Photoshop、Adobe AfterEffects及Adobe Illustrator进行良好的协作。能够自动
识别eps文件。并引入了photoshop层的概念。
Premiere 5。0有了强大的音频或视频捕获能力。视频的捕获可以通过人工或第三方设备的
控制来指定时间的起始和终止位置。甚至可以捕获DV格式的文件。不过这时需要一个FireWire
IEEE -1394端。你还可以为自己的视频捕捉卡设置存储特征。Premiere 5。0还能够自动
地捕获一批视频、为视频生产提供强有力的支持。
Premiere 5。0支持多种食品格式，包括大家所熟悉的AVI、MOV格式、引入视频还可以用
AVC（Preception Audio Video）和PVD（Perception Video） 格式。输出的格式还可以
用，AIFF（只在MAC平台）、flc/fli，以及一些静态图像格式，通过外部设备还可以输出
MPEG格式的文件。
也许您对Premiere 5。0并不十分熟悉，通过上面的介绍还是没有把握自己能否很好地应
用这些新特性，那么从现在开始。将逐渐介绍具有Premiere 5。0新特性的棉班和编辑工
具以及如何利用他们编辑您所需要的食品文件。
Adobe公司重新设计了Premiere的编辑截面，为了提高编辑的效率，更直观地得到专业的
编辑效果，去掉了许多不必要的窗口。当您进入Premeiere 5。0的时候，会首先看到监视
窗，新的监视窗强化了它在剪辑窗、预览窗、修饰窗和控制一贯拥有的强大的编辑工具，
这些有效的工作区提供了两个工作区，资源区和编辑区，用户可以把他们定制成老版本
样子，或干脆使用热键。
上面的图一是监视窗：
A· 是资源区，双击或拖动任意的剪辑，都可以查看或编辑他们。
B·这里是资源选择菜单，在这里可以选择你想编辑的剪辑资源。
C·这些按钮使用来控制资源的编辑和播放的。可以通过他们来播放、快进、倒退、循环、
停止至开头结尾等。
D· 这两个按钮一个是插入资源、一个是覆盖资源，可以将新的资源插入到时间
流程中，或覆盖当前的资源。
E· 单击上面的按钮可以从时间流程中删除某一片段，留下一端空白；单击下面
的按钮也是删除某一片段，只是后面的会紧接上来。
F· 这些键用来设置音量，缺省的转换效果，以及回到上一次或下一次的操作。
G· 和C的作用基本一致，他们用来控制观看所编辑的节目的结果。
H· 这个键用来分离监视窗的控制功能，用在有视频捕捉卡和视频显示卡的NTSC
或PAL制的监视器上。
I· 选择想插入的音频或视频剪辑。
J· 节目观察窗
K· 单击这里将弹出一些选项来控制监视窗的组成。包括跳换到修饰模式 （Trim
mode）、显示单一窗口，修饰模式和但一显示适合编辑两相互有联系的剪辑。
L· 选中这一项可以将资源和节目关联在一起，有助于观看各种资源是如何被组
织的。
<图片>
用Premiere制作影视作品
------------------------------------------------------------------------
1. Director
Director最早是以 VideoWork的名字出现在苹果机上，直到1989年改名为Director 1·0。之后几经升
级改版，于1994年推出PC机版Director 4·0，目前最新的版本是1997年推出的Director 6，它支持微软的Windows 3.X、
Windows 95/NT ,当然还有苹果的Macintosh .
从整体而言,Director以鼠标的选择、拖、拉等方式就可以生成多媒体节目。使用起来非常简单，很容易上手。
Director内部提供Lingo程序语言，可以帮助完成诸如与用户交互一类的许多复杂的功能。这是一种面向对象的解释语言，
只有熟练掌握这们语言才能成为真正的Director高手。
Direcotr是一个非常庞大复杂的多媒体开发系统，它的许多常用的概念和组成部分，是进行多媒体创作所必须
了解与掌握的。
Movie：电影。Director将用户（设计者）看成为导演，将多媒体节目看成为一部电影，那么编制的任意一段
Director程序就是一个Movie。Movie以 ·dir的文件格式保存。
Cast：演员。在Movie中用到的各种素材都称为Cast。包括图形、图像、声音、动画、文字、视频和调色板。
甚至可以是另外一个Movie。每个Cast作为一个member（成员）放在CastLib（演员表）中。相对于Movie而言CastLib可
分为内制（Internal）和外制（External）两种。内制的CastLib保存在Movie里。外制的CastLib保存在 ·cst格式文件中。
Stage：舞台。Stage是一个Movie的展示场地，是每个Cast等台的地方。实际上它是屏幕上的一个一定尺寸的区
域。通过设置可以改变Stage的一些属性。比如其大小尺寸、背景颜色、表现形式（是窗口式还是全屏式）等。
Score：脚本。Score是导演要化工夫去设计的演出内容。在这里规定某演员何时上场，做什么动作，何时退场，
以及在Stage上的各种特技效果的安排。Score是按时间来写的，分成若干个Frame（帧）。
Sprite：精灵。这个概念可能不太好理解。实际上它就是在Stage上的Cast。一个演员到了舞台上后就有了许多
不同之处，它要有所动作（表演），产生交互行为（对观众的问题有所反应），因此称这时的演员为精灵。一个Cast可能对
应着多个不同的Sprite。
Script：描述。实际上就是一段Lingo程序。它可以放在Score的某一时刻，由某一事件去执行来完成对Sprite的
控制，实现各种功能。也可以放在某一个Sprite上来产生特定的效果。
Frame：帧。是Score中的最小单位。整个Score是由许多Frame级组成的。可以调整每秒显示的帧数，以改变运行
的速度。程序运行时，会依帧顺序显示当前帧的演员。
Director运行时，Stage做为一个工作平台以背景形式显示在屏幕上；Cast按CastLib放一个窗口里（可能会用到
几个CastLib）；Score以一个窗口的形式出现，需要时，Director会弹出一个Script编辑窗口来完成Script编辑任务。导演
（设计者也即用户）最基本的操作是将Castlib中的一个Cast member拿出来，放到Score的特定Frame上，在Stage上观察效果，
然后对Score中的Sprite进行处理，达到心中所想的效果。
为了辅助导演进行工作，Director提供了许多工具。如Paint用来对图像，图形Cast进行润色黄状。Text用来输入
文本，进行文字版面设计。Tool palette提供多种画笔功能和前景及背景颜色的修改功能。Inspectors提供内存用量观察等辅
助调试手段。
用Director制作多媒体的方法与导演拍电影的过程相似。整个创作过程大致是先收集素材，然后在Director中调入
（Import）演员，接下来就要将演员按时间顺序放到舞台上，构成整个节目（movie），然后编辑各演员的各种行为（behavior）
以产生各种动画，特效以丰富画面。以上几步可能有反复，最后用Director编译形成一个可以执行的多媒体程序。
Director 6.0较之5.0加强了易用性，如Sprite编辑更加简单，对脚本(Score) 的改进，关键帧和自动生成中间帧，
Sprite信息的显示，Sprite inspector等等。
同时增加了关于Internet的改进，如同Internet中的媒体的联接，更多的用于网络的Lingo，与浏览器的结合，支持浏览器
脚本语言，支持Java等等。另外，Director 6.0还支持DirectSound, DirectDraw和MMX,很大程度上提高了其在Windows 95和NT
上的性能.
重复功能，它就象一张巨大的安全网一样保护着您的作品，这样可以在创作过程中随时回过头来进行修改，Freehand中的制表工具可帮你创作出生动形象地信息图表，甚至还可以使用定制工艺图作为图表中的图象文字，图表中的查找替换功能可以快速找到所需要的内容，例如颜色，线宽及对象类型，并轻松简便地对它们的属性进行修改。在Freehand中可以取得的效果是无穷无尽的，同时提供了全面的文本环境，包括检查拼写，绘制表格及拷贝文件等等，引入一个文本文件若想将其分成若干栏，这时只需简单地拖拉图象即可把它放到文本中来，如果想将图象放到某一个段落中，Freehand将会自动地围绕图象重新排列文本，使文本沿着某一路径排列非常简单，只需单击其类型即可，甚至还可以将图象粘贴到文本中来，通过Freehand及相关软件，可以将图象非常简单地移动到WEB或多媒体产品中，使用Shockwave可将本机向量移动到WEB页面上来，这样可将URL连接到任何Freehand对象上，这样可以将文件压缩到50% 以上，还可以将图形对象转换成一些别的格式，例如TIFF，GIF等等。Freehand中拥有许多新的打印功能，例如可兼容地颜色匹配及对高保真颜色进行打印预览，打印风格的支持，使用这些功能可以轻轻松送地创造出高品质的产品，Freehand的强大功能还远远不止这些，它可以使你的创作快速而高效，使你的时间用在设计里而不是等待上，Freehand为打印及Internet图形设计提供了一套非常完善的工具。
简介：
ACDSee Ver2. 22 for Windows 95是由 ACD Systems 公司推出的基于 Windows 95环境
的32位图形文件观察器。该程序可充分利用 Windows 95的各种已有系统资源而不是完全自
行进行设计。用户阅读完本文之后可以发现，虽然 ACDSee提供了极为丰富的功能，但其整
个程序只占用约500KB的磁盘空间。其主要特点有：
· ACDSee是目前基于 Windows 95 环境的显示图片速度较快、容易操作的图形文件观察器
。其可支持BMP，GIF，JPEG，Photo-CD，PNG，TGA和TIFF 等格式的文件。程序借助
Windows 95平台，通过其内建的基于JPEG的32位解码功能，可在 Windows 95环境下实现图
形文件的快速解码。
· ACDSee 提供了类似DOS环境下运行的著名图形文件观察器Qpeg提供的图形文件的快速预
览功能，但ACDSee对图形文件的预览是全彩色的，并在256色环境下其显示速度与只能以黑
白进行预览的Qpeg 不相上下。
· ACDSee 极大的加强了对系统下的文件的管理功能，如文件的复制、移动、删除、改名
及关联创建。对于已创建了关联的文件，用户还可以在其文件窗口环境下使用鼠标右键实现
文档的快速浏览、编辑、打印等功能。用户甚至可不脱离ACDSee环境就可实现运行程序、修
改系统下应用程序的关联等操作。
· ACDSee充分利用了 Windows 95 的系统资源，通过其内建的32位图形解码器可对以压缩
格式存放的图形文件进行快速解码，并可利用 Windows 95平台所支持的DirectX实现图形的
快速播放和刷新。用户还可通过使用其内建的图形文件的预读入解码技术“Read-ahead
decompression”实现对多个图形文件的快速连续显示
(幻灯机功能，slide show)。据其说明文件介绍，ACDSee可能是目前 Windows 95环境下显
示速度最快的图形观察器，当使用 Slideshow 并定义各图片之间的显示间隔为0时，显示
速度最快可达每秒10幅以上，当然，此时图形文件不能太复杂并没有经过压缩处理。
著作软件
动画天地
Animator Pro
Anamator Pro
Anamator Pro美国Autodesk公司开发的二维动画软件，现已成为动画的工业标准，它提供了
影像制作及动画创作两大系统。功能十分强大。
Autodesk Animation Player for Windows 95/3.x
简介：
Autodesk Animation Player (以下简称Aaplay)是一款由著名图形创作软件生产商
Autodesk 公司推出的动画文件播放器，虽然其本意是用于播放由 3D Studio 等软件生成
的动画文件，但由于十分好用，且功能上有一定的特点，在此还是值得推荐给大家的。
Aaplay
可支持的格式有FLI，FLC，RLE，DIB和BMP，从文件扩展名
上可以看出，该程序还提供简单的图形文件观察功能。对于动画文件的播放，Aaplay 的最
大特点是可在播放过程中由用户自行加入声音(WAV文件)，从而实现图像、声音同步播放，
使播放效果更加出色。
1．1 Animator Studio Animator
二维动画制作软件Animator Studio
Autodesk公司于1995年推出了Animator Studio 1。0，这套基于Windows系统的
软件是一种集动画制作、图像处理、音乐编辑、音乐合成等多种功能于一体的二维动画制作
软件。
在Windows中正确安装这套软件之后，系统桌面上就生成了一项Autodesk
Multimedia群组，该群组中有下面几个程序项：
1·Animator Studio程序项，这个程序项是这套软件中最重要部分，动画制作
及图像处理都是通过它来进行的。
2·Animator SoundLab程序项，这个程序项可以对声音进行编辑与合成，可以
用它剪切或粘贴一段音波，可以把不需要的声音（或杂音）除去，可以控制声音的渐入]渐
出、可以使用过滤器来改变声音的音质等，最重要的一项功能就是在进行动画与声音的合
成时去调整声音的时间，以便与动画同步。
3·Animator Scripters程序项 这个程序项可以编辑要播放的动画的脚本，
如将静态图像与动画串起来，再加上声音和播放控制就可以生成一个播放脚本，这对动态演示非常重要。
4·Animator Player程序项，该实用程序不但可以直接播放多种格式的动画文
件，而且可以播放Animator Scriptor脚本文件。
Animator Studio可读写多种格式的动画文件，如AVI、MOV、FLC和FLI等，还可以读写多种
格式的图形文件，如BMP、JPG、TIF、PCX和GIF等。只要使用File菜单的Save As项就可实现
动画文件格式的转换和静态文件格式的转换，甚至可以将一系列动画文件转换为静态文件。
Animator具有很强的图像处理能力，它有大帐篷、套索和魔棒等选定工具，这些选定工具
不但具有与Photoshop、Photostyler等图像处理软件类似工具的一样的功能，而且还可以
作用于整个动画序列或某个动画序列段。
Animator Studio的绘画工具功能很强，有徒手绘画工具、几何绘画工具。此外，它还提供
了20多种颜料，其中最有特色的当数Filter颜料，这也是Animator Studio与Animatoｒ
Ｐｒｏ 的重要区别之一。Ｆｉｌｔｅｒ 颜料使用的是Adobe的外挂滤镜功能模块KPT 2，
利用Filter颜料不仅很容易实现渐变色，还可以使图
像产生一些非常有趣、甚至出乎预料的效果，如产生旋涡、制作出卷页动画等。
Animator Studio增强了动画设计能力，AnimatorＰｒｏ 的某些先进动画工具
也被引入到 Animator Studio中。
Animator Studio具有很强的动画作品后期制作能力，3D Studio的Video Post
提供了一些后期制作工具，但都非常简单，并不能满足实际需要，现在就可以使用Animator
Studio对三维动画作品进行后期制作（编辑和配音等）了。
Autodesk Animator Studio包括四种不同的程序：用于创建或编辑动画、数字视频以及简
报等。
Animator Program：可以对数字图像或电影进行编辑、绘画、处理和动画。
SoundLab Program：可以创建或编辑WAVE声音文件，以及将它们与电影合成在一起。
Scriptor Program：可以将电影、静止图像以及声音合成到一个单个脚本或简报中。
Play Program：可以独立地播放电影或脚本
Animator：提供了很强的绘画和图像处理功能。
可以使用Inks、Tools、Brushes进行绘画和图像处理。通过提供一两个关键帧可以进行Cel风格动画。
1· 绘画和图像处理
Animator提供了很强的绘画和图像处理
如果想对一幅图像进行绘画和图像处理，可以使用：
Inks，Tools，Brushes
Inks直接作用于图像，简单的墨水，例如Color Ink，只是在所作用的地方简单地增加颜色。更复杂一些的墨水（一些图像处理软件称之为过滤器）则对图像进行相应的处理。
Tools直接控制着墨水作用的地方。
。手工绘制工具：随着鼠标的移动将墨水作用于屏幕上。有四种手绘工具。
。几何形体绘制工具：提供了九种规则的几何形体绘制工具
。填充工具：根据原始图像的颜色，进行相应的填充
。文字工具：允许将文字或标题放在电影中
Brushes：控制绘制时笔刷的形状
Cel风格动画
通过使用一两个关键帧，就可以通过使用Animator的onionskin特色创建出运动的效果。
Automated动画：
可以创建出比Cel风格动画更稳定的效果。
视频动画：
Animator不仅可以处理各种手工绘制动画，也可以装入、播放、编辑和保存数字视频。
Animator Studio同时支持AVI和QuickTime电影格式，以及Autodesk的FLC格式。
Anamator Scriptor
Animator Studio
Autodesk Animator Studio包括四种不同的程序：用于创建或编辑动画、数字视频以及简
报等。
Animator Program：可以对数字图像或电影进行编辑、绘画、处理和动画。
SoundLab Program：可以创建或编辑WAVE声音文件，以及将它们与电影合成在一起。
Scriptor Program：可以将电影、静止图像以及声音合成到一个单个脚本或简报中。
Play Program：可以独立地播放电影或脚本
Animator：提供了很强的绘画和图像处理功能。
可以使用Inks、Tools、Brushes进行绘画和图像处理。通过提供一两个关键帧可以进行Cel风格动画。
1· 绘画和图像处理
Animator提供了很强的绘画和图像处理
如果想对一幅图像进行绘画和图像处理，可以使用：
Inks，Tools，Brushes
Inks直接作用于图像，简单的墨水，例如Color Ink，只是在所作用的地方简单地增加颜色。更复杂一些的墨水（一些图像处理软件称之为过滤器）则对图像进行相应的处理。
Tools直接控制着墨水作用的地方。
。手工绘制工具：随着鼠标的移动将墨水作用于屏幕上。有四种手绘工具。
。几何形体绘制工具：提供了九种规则的几何形体绘制工具
。填充工具：根据原始图像的颜色，进行相应的填充
。文字工具：允许将文字或标题放在电影中
Brushes：控制绘制时笔刷的形状
Cel风格动画
通过使用一两个关键帧，就可以通过使用Animator的onionskin特色创建出运动的效果。
Automated动画：
可以创建出比Cel风格动画更稳定的效果。
视频动画：Animator不仅可以处理各种手工绘制动画，也可以装入、播放、编辑和保存
数字视频。Animator Studio
同时支持AVI和QuickTime电影格式，以及Autodesk的FLC格式。
Anamator Scriptor
1．2 Animator Studio Scriptor
3D MAX 系列
3．1 3D MAX 2。0
3D Studio MAX R20
3D Studio MAX R20可以轻而易举地让任何对象生成动画。如果拥有了这样一套软件，就可
以将设计与创意转化为令人惊叹的效果。
3D Studio MAX R20不但是影视和广告设计的强有力的工具，同时也是建筑外形设计和产
品造型设计的最佳选择。通过相机和真实场景的匹配、声音效果的设计、场景中任意对象
的修改、高质量的渲染工具和各种特殊效果的组合，可以创作出逼真的电影级动画。同时
，3D Studio MAX R20具有友善的开发环境，借助其简单的脚本语言，即可自行扩展功能；
如果你是编程高手，更可以用Visual C++ 开发新的插入组件。
1997年8月4日，美国Autodesk公司的 多媒体子公司Kintix在SIGGRAPH 97会上初次亮相，
并宣布了它在PC领域最畅销的动画和模型制作软件的最新版本 -- 3D Studio MAX R20。
该本本是专门针对影视和交互式游戏开发商用的新一代强有力的软件包。3D Studio MAX
R20比屡获大奖的前一版本提高了近三倍的功能和超过一千种特性，而且它支持各种三维
图形应用程序开发借口，包括OpenGL和Direct3D。
你也许曾经为 3D Studio 中漫长的渲染时间感到无法忍受，那么你不妨试一下 3D Studio
MAX 吧，你会发现计算机的渲染速度科“飞”起来了。 Microsoft公司的Windows NT平
台除了32位特性和多任务外，最重要的一个特色就是对称多处理，这可以成倍提高程序的
性能。由于在三维环境中，渲染时间严重影响工作效率，因此用多重处理器把它们分成小
单位，可以大幅度提高程序的潜能。在 3D Studio MAX中，渲染器中的处理被分解到了象
素级，每个象素可以被单独的渲染。这种独特设计，使 3D Studio MAX 可以充分利用装有
Windows NT的计算机的性能。它可以利用PC机的所有能力，并使扩充性能变得容易且有效。
在不增加内存的情况下，仅增加一个处理器， 3D Studio MAX 的渲染速度就可以提就近一
倍。如果你增加了三维图形加速卡， 3D Studio MAX 就可以提供实时的显示反馈，这可以
与价格非常昂贵的UNIX工作站的性能相媲美，Autodesk公司还为 3D Studio MAX加了TCP/IP
能力，这允许将10，000台计算机联成网，而只使用一套 3D Studio MAX 来完成渲染，
这使得渲染提的性能价格比非常好。
3D Studio MAX的新的Windows界面是很重要的成就。即使在一幅单独屏幕上，四个模块视
图之间也相互有相配合，视图顶部是工具栏，右边是部件区，该区域包括工作时需要的所
有选项。这样可以减少工作时屏幕显示的混乱。建模、动画和渲染都在统一的环境下完成。
在 3D Studio MAX中，动画是很容易掌握的。你只需要在Animste氯钮上单击，运动虚拟的
任何对象即可，你还可以在实时着色视窗中及时观察你的动画。在充分享受到了 3D
Studio MAX的完全面向对象的体系结构的优越性能后，你也许还会发现 3D Studio MAX有
先进的光照效果。非常灵活的的材料编辑功能强大且极易使用的工具——但当你看到 3D
Studio MAX的64位超真彩色的渲染质量后，我想你肯定会为之心动。
3D Studio MAX还具有良好的兼容性，它可以输入 3D Studio 的SHP，3DS，PR昨Auto
CAD的DXF文件。不仅如此，为了适应其它NT处理器，Autodesk公司还会交付重新编译
的MAX版本。
当然，作为一个如此优秀的在PC上运行的三维动画软件，它对硬件的要求也是比较高的。
3D Studio MAX的技术说明中推荐的配置是：
· 主频至少为90MHZ的Pentium或Pentium Pro (支持多处理器系统)
· Microsoft Windows NT Workstation 3.51
· 32M内存
· 100M硬盘交换空间
· 在Windows NT下支持800×600×256色的图形显示卡(推荐使用PCI总线下1024×768×256
色的图形卡，1280×1024×24位的双缓冲区的三维图形加速卡最为理想)
· CD-ROM驱动器
· 选件：声卡和音箱、视频输入输出设备
3．2 Character Studio
3D Character Studio
Character Studio为3D Studio MAX的一个标准外挂程序，是一个极重要的插入模块，用来
创建两足动物的模型并设置其动画。它发挥了3D Studio MAX的所有优点，它与Windows NT
截面完全兼容，也可在Windows 95下运行Character Studio（包括Biped和Phyysifue两个
模块）。
Biped模块：新一代的三维人物及动画模拟系统，用来激活两足动物的模型并设置复杂的动
作动画。Biped利用一个步迹驱动过程来初始生成步迹，并且随后利用调整关键帧的结构来
调整动作。还可以用Biped来设置身体任何一个部位的动画，使模型在使用同一步迹时产生
不同的动作，丰富了动画的内容。另外，Biped还可以利用两足动物的生理动力学和重力学
的原理来添加所生成的特征模型的特征。在不需要根据物理特征来激活模型的情况下，
Biped会允许在自由方式（Free Form）的时间段中关闭重力等因素。你用Biped来简单地
设计步迹即可使人物走上楼梯，或条国跳过障碍，或按节拍跳起舞来。更为奇妙的是可以
把一种运动模式复制到任意一种二足动物身上而不需要做重复的工作。这样对于诸如集体
舞之类的创作就变得轻而易举了。
Physique模块：是一个同意的骨骼变形系统。为生成的双足动物模型提供一个躯体骨架。
给他们附以皮肤，从而能够在运动的过程中，根据肌肉运动的要求，皮肤能够产生弯曲、
伸展或者上膨胀的效果。它能够模拟出逼真的人物来，进而创建出“活龙活现”的效果。
3．3 标准外挂模块
3D Studio MAX标准外挂模块
3D Studio MAX自R 1。1以后，自身带有一些标准外挂模块，这些模块之间没有必然联系，
主要有以下几种：
l Adobe Illustrator AI88文件的输入
l 音频动画控制器
l AutoCAD DWG文件的输入/输出
l Bevel（倒角）调整器
l Combustion（燃烧）外挂模块的应用方法
l 凹痕（Dent）过程贴图
l Editable Mest对象及其应用
l 地球体对象的生成
l Mesh Smooth调整器
l 路径变形空间扭曲
l Photoshop图象过滤器的支持
l 使用PNP图象文件支持
l Relax（松弛）调整器
l Relax Transform（重置变换）实用工具
l Stretch（伸展）调整器
l Wood过程贴图
3．4 第三方外挂模块
3D Studio MAX第三方外挂模块
由于3D Studio MAX软件包是一个以外挂模块为构架的动画软件包，所以非常便于开发者作
功能的扩充。随着对该软件包的开发和应用的不断深入，满足各种特殊需求的外挂模块将
会越来越多。目前，已经发布的用于3D Studio MAX软件包的外挂模块以达1000多个。这
里主要介绍其中一部分：
l Torus Knot外挂模块
l MAX VRML输出器外挂模块
l Super Ellipsoid外挂模块
l Push调整器
l EGO外挂模块
l MorphMagix变形动画系统
l ChromaDepth视频后处理外挂过滤器
l MarMatterLite外挂模块
l Edit Mesh 2调整器
l MIDI控制器
l Collector（位图收集器）
l Color Correct（颜色校正）
l Digital Forest（森林）
l Edge Up Filter（边缘锐利滤镜）
l Flat（平面）模块
l Fantom Image（幻像）模块
l Handy Filter Tool（手工滤镜工具）
l ID Select（代码选择）
l KeyCalc（帧计算器）模块
l MultiDeflect Particle Deflector（多反射粒子反射器）
l Object Combustion（对象燃烧）模块
3．5 3DS4
3DS4
3D Studio 是一个三维动化软件，用它制作的动画效果逼真，可应用于图象仿真学，检查历史现象，建筑专业，卡通动画片的制作，广告制作，法律，影视制作，科学研究领域等方面。
IPAS
IPAS 程序是建立在 3D Studio 基础上，可以利用 C 或 C++ 增加其外处理功
能。IPAS 以 PharLap。386 为基础，与 3D Studio 共享内存缓冲区，因此能够更好地处
理各种图形信息。IPAS 在do
S 环境下存在四种扩展名称即 IXP、PXP、AXP、SXP。
3D VIZ
3DS VIZ是Autodesk今年对工程设计用户的新奉献之一，它也是基于3DX MAX的母体技术而
派生出的一项新产品，主要用于概念化设计和可视化设计。
3DS MAX软件主要面向电子游戏开发商和影视动画制作商，虽然它能成功地用于工程设计
（AEC）行业的渲染制作，但不适于在AEC行业初始化造型及工业产品的概念化设计。当
然，3DX MAX提供的各种动画功能远远超过AEC行业对动画漫游的需要，但它缺乏面向AEC
行业的建模工具（如窗、门、屋顶等），而且也不适于建立精确的模型。其他一些软件厂
商虽有一体化解决方案的产品，但要么迫使设计者携带大量的数据和操作步骤进行工作，
使其难度加大和效率降低。要么其中的绘图工具不能满足大型和复杂工程设计的需求。
3DS VIZ是面向建筑、工程、结构（AEC）和工业设计市场的一种用于三维概念化设计和可
视化设计的极好工具。此产品代表着Autodesk在该领域的产品策略，它将成为一种新的开
发平台，用于开发那些需要可视化设计概念交流的应用软件。3DS VIZ会进一步加强和提高
Autodesk现有的规模巨大的AutoCAD软件市场。3DS VIZ首先提供两种版本：一是AutoCADR14
专版，为AutoCADR14用户提供。另一种是可完全独立运行的3DS VIZ软件。许多人非常想知
道3DS MAX和3DS VIZ这两种软件的主要区别，为此我们列出下表以示说明。
主要功能
艺术设计师们需要一种能够理解他们的设计构想并随时能与之沟通的计算机软件，3DS VIZ
就是这样的软件。其特点就是直接面向建筑师和相关专业的设计师。与其他竞争对不手不
同，Autodesk 的 Kinetix分公司能直接把三维多媒体新技术转移到工程设计行业，使已在
影视及交互式游戏制作业中非常著名的三维可视化技术成为工程设计师的强大设计工具。
1.即时反馈
见过3DX MAX的人都知道它是一种完全交互的环境，而3DX VIZ也会使设计师能够使用这种行进的软件技术。
2.材质编辑器
3DX VIZ的软件中有50种新的工程设计（AEC）特殊材质，当应用这些材质时，它们被设计成平铺模式。这些材质附带着数百种位衅及程序效果，材质编辑器可承时让你在屏幕上预视和控制贴图及材质。
3.参数化的门窗设计
在这个功能中为工程设计（AEC）所设计的材质可赋予门和窗，这些材质将赋门窗相应的位置，如玻璃、围栏、装饰、内框、外框等。用户可用3DX VIZ提供的、也可用自己制作的材质迅速预示其效果。
4.剖面功能
任何横切面都能直接输出到AutoCAD软件中，或可作为底图传给其他3DS VIZ模型进行二维
操作。
5.新的二维特性
6.相机匹配
7.拖拽材质
8.拖拽物体
9.自动捕捉
Premiere 5。0
PremierePAdobe Premeiere 5。0
做过视频编辑的人如果没有听说过Adobe公司的 是不可想象的，她拥有简洁的界面，
直观的工作窗，丰富的控制工具，优秀的音频编辑工具而为人称道，并成为此领域的佼佼
者。经过一段时间的沉寂后，Adobe终于将Premeier 升级到5。0极大地扩展了它的功能
，从而拥有了更强的竞争力。Premiere 5。0能够进行专业的数字视频的编辑。它可以满
足小的视频工作室，多媒体和网络影象开发者，个人视频，工业设计展示等诸多方面视频
编辑需要。通过它一流的界面，Adobe Premeiere 5。0也可作为离线编辑器，轻松地进行
要求很高地广播视频电影的后期处理工作，这个令人兴奋的新产品还包括工作室级的音频
工具，并增加了强大的字幕控制能力，关键帧筛选器，提供强大的长格式编辑能力，
另外5。0版本的Premeiere 编辑器也变得更加灵活，Premiere5。0可以跨平台工作，可
以自由地在Windows和Mac平台间进行各种数据的传输。
在编辑方面通过Adobe Premiere5。0，用户可以在传统的非线性编辑上，即用一种允许3
- point编辑和其他高级的编辑技术方法，进行间接的资源重新安排和精确视频定位，使用
插入和覆盖按钮可以很简单地将剪辑定位于时间流程中，视频编辑可以被无缝地连接在一
起，先进的编辑能力还允许作者一边观看视频编辑的原材料，一边在效果监视窗内编辑他
们。
Premeere 5。0使用滑动编辑工具，从而保持在改变剪辑进出点时图像的连续性，因此可以
创作长达三个小时完整的音频食品，无论是NTSC制的每秒29。97帧，PAL制的每秒25帧，还
是电影中的每秒24帧。
使用一个改进的时间流程，你可以十分简单地在时间流程上标记、隐藏、显示、取消跟踪
，在时间流程中增加多达99个视频轨道和99个音频轨道。新的视频轨道可以出现原有的
轨道之上，以便显示电影的最后效果。允许连续撤消32次以前的操作，。
媒体管理方面有了很大的增强，方便的项目选择窗口来显示剪辑：可以在缩略图中用带有
文字说明的缩微图显示，也在图标窗口中用图标显示，或在六表中作为一个文件显示。在
用户定义和内建的数据区中搜索、排序剪辑包括文字、日期、文件路径及类型变得更加方
便。为了在几个项目中同时使用一个同一个视频剪辑，可以建立一个分开的剪辑库。还可
以设置对一个项目定时进行自动备份。
Preiere 5。0拥有21个专业音频滤镜，包括14个新增的滤镜，可以制作高质量的音轨。新
的滤镜允许你精确地为旋律设定一个动态的范围，删除嗡嗡的杂音声，正确控制延时效果
，提取或改变特殊的频率，模拟听觉的内部效果。通过自动调节引入的音频来协调声音播
放速度。可以精确指定用于网上循环播放的小数据量的高品质的音频抽样。可以工作在3
2kHz到44MHz声音速率上，完全满足数字视频（DV）格式的需要。
设计人员可以精确地控制文字标题的滚动和移动，并可绘制文字或图形。在每一定义的
文字块内都可改变文字的大小、牙色和其他属性。可以设置标题的进入和离开位置，停
留多少秒和具体的帧数。文字的编辑效果可以很容易地在标题窗呃逆看到。Adobe
Premiere 5。0提供大量特殊效果的滤镜，引入了PhotoShop的兼容插件，包括调节色彩的
平衡、明暗度、对比度、润化、扭曲变形等。用专业调节工具可以给添加的剪辑指定色度
、亮度、alpha通道或平滑程度。在动画方面，可以为一幅静止或运动的图像指定其运动
的路径，并可以同时设置诸如盘旋、缩小或放大、转动以及扭曲等各种特殊效果。再调
节时间效果上允许只任意个关键帧。还提供一个能很快地根据用户需要进行歼击间的特
效过度的转变面板。
扩展的硬件和软件支持，给用户带来了更大的灵活性。它可以和Adobe家族的其他软件，
Adobe Photoshop、Adobe AfterEffects及Adobe Illustrator进行良好的协作。能够自
动识别eps文件。并引入了photoshop层的概念。
Premiere 5。0有了强大的音频或视频捕获能力。视频的捕获可以通过人工或第三方设备
的控制来指定时间的起始和终止位置。甚至可以捕获DV格式的文件。不过这时需要一个
FireWire IEEE -1394端。你还可以为自己的视频捕捉卡设置存储特征。Premiere 5。0
还能够自动地捕获一批视频、为视频生产提供强有力的支持。
Premiere 5。0支持多种食品格式，包括大家所熟悉的AVI、MOV格式、引入视频还可以用
AVC（Preception Audio Video）和PVD（Perception Video） 格式。输出的格式还可以
用，AIFF（只在MAC平台）、flc/fli，以及一些静态图像格式，通过外部设备还可以输出
MPEG格式的文件。
也许您对Premiere 5。0并不十分熟悉，通过上面的介绍还是没有把握自己能否很好地应
用这些新特性，那么从现在开始。将逐渐介绍具有Premiere 5。0新特性的棉班和编辑工
具以及如何利用他们编辑您所需要的食品文件。
Adobe公司重新设计了Premiere的编辑截面，为了提高编辑的效率，更直观地得到专业
的编辑效果，去掉了许多不必要的窗口。当您进入Premeiere 5。0的时候，会首先看到
监视窗，新的监视窗强化了它在剪辑窗、预览窗、修饰窗和控制一贯拥有的强大的编辑
工具，这些有效的工作区提供了两个工作区，资源区和编辑区，用户可以把他们定制成
老版本样子，或干脆使用热键。
上面的图一是监视窗：
A· 是资源区，双击或拖动任意的剪辑，都可以查看或编辑他们。
B·这里是资源选择菜单，在这里可以选择你想编辑的剪辑资源。
C·这些按钮使用来控制资源的编辑和播放的。可以通过他们来播放、快进、倒退、循环
、停止至开头结尾等。
D· 这两个按钮一个是插入资源、一个是覆盖资源，可以将新的资源插入到时间
流程中，或覆盖当前的资源。
E· 单击上面的按钮可以从时间流程中删除某一片段，留下一端空白；单击下面
的按钮也是删除某一片段，只是后面的会紧接上来。
F· 这些键用来设置音量，缺省的转换效果，以及回到上一次或下一次的操作。
G· 和C的作用基本一致，他们用来控制观看所编辑的节目的结果。
H· 这个键用来分离监视窗的控制功能，用在有视频捕捉卡和视频显示卡的NTSC
或PAL制的监视器上。
I· 选择想插入的音频或视频剪辑。
J· 节目观察窗
K· 单击这里将弹出一些选项来控制监视窗的组成。包括跳换到修饰模式
（Trim mode）、显示单一窗口，修饰模式和但一显示适合编辑两相互有联系的剪辑。
L· 选中这一项可以将资源和节目关联在一起，有助于观看各种资源是如何被
组织的。
<图片>
Adobe Premiere
随着多媒体技术的发展，计算机技术和视音频处理技术有机地结合起来，形成了全新
的电视节目制作概念——非线性编辑。
目前，在众多类型的非线性编辑系统中，使用较为广泛的非线性编辑软件是 Adob
e Premiere。它融视、音频处理于一体，功能十分强大，与一些视频影像采集压缩回放
卡件象DC20、FPS60、AVmaster等配合使用，可以完成高质量的广播级视、音频制作。
Adobe Premiere支持 Microsoft video for windows格式的．avi文件，Quick Time
Movie格式的．mov文件和.flm文件。对动画文件它支持．flc，·fli。 以及．tga，
，bmp，.rle，.dib，．tif顺列文件。 对静止图像它支持．psd，．bmp，.rle，．
dib，.pic，.umf，.tif，.pcx，.jpg，.tga，.vda，.icb，.vst。对于音频文件它支
持．wav，.aif。由于Adobe Premiere能支持众多的文件格式，因此可以和许多也支持
这些格式的软件配合使用，这使得 Adobe Premiere的功能更加强大。Adobe Premiere
4．0版，一般硬件环境要求是486机、8M内存、100MB硬盘、16位视频卡。软件环境为
：MS—DSS5.0、Windows3.1。当然，为了完成高质量的非线性编辑处理，上述硬件环
境是远远不够。
Adobe Premiere能够替代线性编辑方式中的许多硬件设计，其主要功能如下：
1．动态视、音频采集
Adobe Premiere可以配合计算机上安装的视、音频处理卡件，对来自摄像机、影碟机、
录像机或录音机等视、音频设备输出的动态模拟信号，进行数字化处理并实时动态采
集。对视频信号来说，可根据需要和硬件环境进行软件压缩或硬件压缩。硬件压缩比软
件压缩更快、更有效，要制作高质量的视频，必须使用硬件压缩。比如， Adobe
Premiere配合DC20卡、SCSI—2硬盘，能够实现一帧两场、每秒25帧(PAL制)、24位
颜色深度、?68×576分辨串的视频影像的实时采集及输出。软件压缩分为 Video for
windows和 Quick Time两类，每一类都提供了多种压缩算法，这些算法各有不同的特
长，可灵活选用。一般来讲，如果仅仅是在计算机屏幕上显示视频或是在CD—ROM上播
放。选用软件压缩是十分有效的。对音频信号来讲，可以选择不同的取样频率以及量
化值，既可与视频信号同时采集存在一个．avi文件中，也可单独采集。视、音频文件
的输出可以说是采集的逆过程，软件按存储文件中记录的压缩法代码找到对应的压缩／
解压缩驱动程序，将视频文件解压缩输出，另外在采集动态视频时，AdobePremiere可
对图像的亮度、对比度等参数作必要的调整，如果硬盘速度不够快，还会指示出丢帧率。
2．视、音频非线性编辑及特技处理Adobe Premiere具备99轨视频和99轨音频，可精确实
现声、画同步，并以帧的精度实现编辑，和传统的线性编辑方式相比，使用Adobe
Premiere使整个编辑工作更为简便、轻松。其 A、B两条视轨相当于 A/B卷编辑中的两台
放像机，计算机的硬盘相当于磁带，我们采集到的视、音频片段以及其它软件制作的二、
三维动画以及静止图像都以数字化文件存在其中。在整个编辑过程中，只是在视、音频
轨道上实时调配出入点的画面和声音，一旦发现错误，可立即还原而不影响原始文件。
在任意编辑点插入一段素材，编辑点以后原有素材可以向后推，删除一段素材，被删除
素材之后的原有素材可向前补，每段素材可以任意截取多次使用，对于简单的切换可实
时观看编辑效果。静止图像的持续时间可以任意设定，运动影像可通过设定时间实现—
100~100倍的快、慢动作处理。Adobe Premiere具备强大的数字特技功能，它具有58种
基本特技、75种画像方式，这是传统特技台无法比拟的。利用这些功能，可以实现诸如
视频图像的叠化、圈入圈出、三维卷页、翻转伸缩、波浪、柔化、飞入飞出等特技画像
效果，还可实现声音信号的混响、变声等效果。在画像和特技框中有一些参数设定，通
过调整它们的数值，可使同一种方式产生多种效果。 AdobePremiere还可将连续视频影
像存成.flm文件，在 photoshop中调出．flm文件，使用 pnotoshop带有的图像特技处理
工具对有关图像进行特技处理，然后再由Adobe Premiere调用。 由于 photoshop本身的
图像特技功能也十分强大，这使得 Adobe Premiere如虎添翼。为了方便编辑， Adobe
Premiere还提供了预演功能，编辑效果可通过预演窗口随时观看。
3．抠像与字幕制作
Adobe Premiere提供了14种类型的抠像(key)方式，用于除 A、B视轨外的97条视轨。
这意味着除 A、B视轨外可实现97层不同视频影像的叠加，传统的特技台无法做到这一
点。其中Alpha抠像方式的运用，使得其它软件处理的图像，在 Adobe Premiere中能方
便地混合叠加。字幕与图像的叠加也是通过抠像方式实现的。 由于采用了边缘抗混淆技
术，叠加的字幕或图像边缘光滑无锯齿质量很高。调整抠像设置的某些参数，还能方便地
控制叠加图像的范围、透明度以及谈入淡出等等。在 Adobe Premiere中设有专门的字幕
制作窗口，其自身带有多种英文字体并配有简单的绘图工具，使用中文之星还可实现中文
字幕的制作。 字幕的颜色可通过调色板选用，也可直接给出 R、G、B值，字幕的运动轨
迹可随意设定，并能产生阴影、浮雕等特殊效果。
目前，Adobe Premiere的4.2版已推出。这一新的32位软件比前一代16位产品处理速度快
了两倍多，可以在后台处理视频图像，还提供了一些极好的新功能，其中包括重要的
Internet优化技术。对高分辨串、CD— ROM质量的视频，提供了诸如批处理和可控关
键帧等一些增强功能，支持更好的回放质量并为交互式视频操作提供更快的反应时间。
另外，它还增加了数十种新的数字特技程序，包括 Camera View和 Audi。Suap，前者
可以从简单的视频剪辑中生成漂亮的3— D效果，后者可在回放期间来回交换左、右声道
。虽然 Adobe Premiere是一个相当不错的软件，但包括4．2版在内仍有美中不足之处。
第一是它不支持较为流行的 MPEG文件，使用受到一定限制。 第二是宇幕制作功能与国内
厂家的中、英文字幕软件相比较为薄弱。第三是介面较为复杂，许多菜单需要打开，特别
是编辑片段较多时，更让人感到屏幕空间的狭小。综上所述， Adobe Premiere和其它软
件一样都有其优点与不足。在实践中，我们应注意 Adobe Premiere与其它软件配合使用
，以取长补短产生最佳的综合效益。
游戏修改器
FPE 6．0整人专家
一、 简介
FPE通过修改游戏资料，可以达到所向无敌或无中生有、源源不绝的效果。
本程序为纯Windows 95 32位的应用程序，而且能够加参数 -b在Win95内修改以DOS模式
运行的游戏，并不适用于Windows NT或Windows 3．1。
l FPE 6．0正式版的特点
1. 超强的分析功能：完全的整合了高低阶分析，能够同时连续分析10进制、
16进制、字符串、浮点数和不知道数值的目标。
2. 超快的分析速度：比FPE 5．0快许多，超过了同类软件
3. 超强的拦截能力：测试到目前为止，所有的游戏都能够以热键呼叫FPE6．0
4. 完整的表格功能：除了完整管理功能以外，如果懒得分析还能够直接上网抓
别人改出来的记录直接使用
5. 完整的内存编辑能力：能够以PCTOOLS同时编辑十进制和十六进制的方式，
分析编辑一个程序4GB实际和虚拟内存。
6. 抓图能力：能够直接连续抓取DirectX 5．0以上的游戏图形，存成BMP格式
文件，并能立即看图及管理。
7. 完全图形截面：能够完全以鼠标操作，界面方便美观；
8. 完整的支持：支持Voodoo，Direct 3D的游戏；
9. 免费的转换图形格式程序：可以互相转换BMP、GIF、JPG的格式。
一、 呼叫FPE
只要在游戏中按下热键（内部为键盘右边灰色的*）就可呼叫出几
乎所有的游戏。也可以自己设置一个热键，只要用鼠标点一下“Hot-Key”那个栏位，单
击该键，然后再单击 “Update Key”按键即可。
如果修改的是DOS box执行的游戏，由于Win95先天的限制，需要按下“Ctrl”
+“热键”来呼叫出FPE。
另外还有一种方法可以选择一个程序来修改，在“Others”菜单内单击
“Refresh”按键，FPE会列出所有的窗口及程序名称，可以以鼠标单击一个即可，以
后就以“Alt”+“Tab”来切换游戏和FPE。
二、 功能说明
1· 分析内存（Scan）
FPE是以分析内存变动情形来找出目标的，所以必须在目标的数值有所变动时
，以FPE来分析它。例如我们玩红色警戒（Red Alert）for Win95版，刚开始有资金4000元
，然后。。。
*步骤一：以热键呼出（*）FPE，在 “Scan target”的位置输入目前的数值
“4000”，然后按下“Start”按键，FPE开始分析：并把可能的内存数告诉你，然后单击
右上方的 “Game”按键（或直接按Esc键），回到游戏中。
*步骤二：回到游戏后随便花点钱，例如钱剩下3700时，重复上述步骤，直到
只有三个可能的内存为止。
*步骤三：在下方的内存列表内h：代表该内存的十六进位数值，“d：”则是
十进制，可以以“Ctrl”+“鼠标左键”选择数个地址，或以“Shift”+“鼠标左键”选
择一排的地址，或直接以“鼠标左键”选择单个地址，然后按左边的“Add”按键，把他
们加到表格内。如果要强迫列出所有可能的内存，可以直接按左下方的“Relist”按键
，FPE不管目前有多少可是的内存，都会列出
*步骤四：在Value位置输入想要锁住的值，例如输入9999，以后该目标就会
一直保持9999不会减少，Comment是注释，Auto Lock则为切换是否自动锁住。然后按OK
就会加入表格中。
*步骤五：如上图所示，加入表格后就大功告成。
2· 编辑内存或文件
FPE 6．0的编辑功能可以编辑内存或文件，可以修改游戏的进度，而且FPE还
有独一无二的搜索或是编辑十进制、16进制、字符串、浮点数和未知数的能力；而且能够
恢复（Undo），不怕改错。
3· 抓图能力（GPE）
FPE 6．0正式版能够直接连续抓取DirectX 5．0以上的游戏图形，保存为BMP
文件，并能立即看图及管理。
三、 Game Worm
Game Worm 强大的游戏修改器
Game Worm是一个不同于大多数游戏修改工具的新一代运行于Win95上的游戏
修改工具。它既充分考虑到Win95游戏、又兼顾DOS游戏的在Win95下运行的游戏修改工具。
作为一个32位的应用程序，由于使用了智能内存搜索，Win95游戏在线激活等技术，Game
Worm具有超强的激活能力，使修改游戏变得更容易和有趣，同时又非常稳定，充满乐趣。
随着微软Win95的普及，越来越多的游戏厂商将目光描向了基于 Win95游戏开
发。由于Windows系统集成了多媒体的功能，并且微软提供了专门用于 Win95游戏开发软
件包，使得Win95游戏大量涌现，并且出现了一批优秀的游戏软件，如MDK、TOMB等。
游戏蛀虫由于使用了Win95游戏在线激活技术，使得少数其他游戏修改工具无法修改的游戏
，可以被蛀虫非常容易解决。例如MDK，在切换画面之后就再也无法切换回来；Road Rash
就根本无法激活如PE之类激活能力较强的游戏工具。而对于游戏蛀虫来说，解决此类游戏
非常容易。
游戏蛀虫不仅可以方便地修改Win95游戏，还可以修改DOS程序和磁盘文件。
GameWorm由三个模块组成：W32蛀虫、DOS蛀虫和DISK蛀虫。W32蛀虫专门为Win95游戏设计，
而DOS蛀虫可对Win95游戏及在Win95下运行的DOS游戏均有效。DISK蛀虫可以对游戏存盘文
件进行扫描和修改（不必切换窗口）
游戏蛀虫的功能十分强大！以下列出其主要功能：
。支持精确/模糊查询
。支持字节/双字数值类型的搜索
。用户可自定义W32蛀虫和DOS蛀虫的呼叫热键
。修改地址存取功能 – 免去重复劳动之痛苦
。Win95游戏可在线激活 - - 不切换屏幕
。修改结果可发布共享
。给搜索项加注释，记忆非常方便
。可一次修改多个地址
。高手模式给高级玩家提供更多修改乐趣
。齐全的在线帮助易学易用
。支持地址锁定
。超强稳定性
。文件扫描功能
PhotoShop 5。0
PhotoShop 50
1. 文字处理
较以往版本有重大的改动，以前的文字一旦形成图形就没有改动的可能性，
PhotoShop50可以改变这一缺陷，文字处理可恢复为文字处理信息，可任意改变字体与字
号
2. 具有无限的UNDO和REDO功能，更加强大更加完美
3. 更加悦目、精确的色彩管理和色彩矫正功能，印前处理更加完善与趋于精美
4. 新增加SPOT-COLOR CHANNEL（SPOT色彩管理通道），处理更加方便快捷
5. 增加了大量的自动流程图、批量处理工具、减化了以往复杂的工作程序
6. 更加精确、有效和易于控制的选择、测量工具
7. 为第三方厂家提供了更加开放的PLUGING开放空间
Adobe公司的Photoshop图像处理软件一直被作为2D图像设计的首选。它强大的
图像处理功能让设计人员梦想成真，而且Photoshop 一直在不断革新，每次推出的新版
本都会有许多更贴近用户的改进，一些繁琐的操作将被简化，软件运行速度也越来越快。
4·0版想必一已被广大用户所接受，Photoshop爱好者日益增多，电脑美术设
计大赛也正如火如荼的举行。4。0版本及4。02版本满足了大部分使用者的需要—专为MMX
作优化，增加导航视窗（Navigator）及电子水印（Digimarc），增加对网络图像格式的
支持，而且可以进行双字节文字处理（能直接输入汉字），等等。当Adobe公司并未固步
自封，他们想让Photoshop闯入专业图像设计领域，占领市场。
一、 为任何媒体设计令人满意的图像
在越来越广泛和多样化的媒体形式领域内，Adobe公司的Photoshop已成为制作
数字图像的行业标准。它能提供设计师所需的用来制作高质量图像的所有构件。不仅仅用
于印刷业和多媒体，也被应用于国际互连网上。
面对突飞猛进的网络图片和专业图像制作技术。一个颇具普遍性的挑战正被人
们重视起来—必须制作出高质量图片存储，印刷格式。Photoshop 5。0提供最快捷和最智
能化的解决方案。可编辑文本层面可以让设计师轻松实现对字符界面、字符间距和文本核
直等项目的精确、专业控制。实现自己的创意甚至简单到用鼠标双击即可。增强型文本和
图像层具有生动的光影、辉度、斜度效果，在编辑完一个层面（Layer）之后，它会自动与
原图片溶合在一起。
独具特色的多重撤消能力让设计者自由构思并快速的从错误中恢复原始状态。
以往复杂繁琐的步骤被简化至只需简单的单击或双击。用户甚至可以输入Eps，
Illustrator及PDF格式文件，然后轻松的与自己的图像结合起来。总而言之，无论你从
事任何媒体创制工作，Photoshop 5。0都能提供强有力的专业支持。
二、 真实再现缤纷色彩
色彩控制是数字化环境中实现高保真色彩的最难解决的问题之一。Adobe公司的
Photoshop 5。0提供给用户确保专业水准的广泛、丰富的色彩控制和再现技术。
灵活的配色通道（Channel）可以在任何印刷工作中轻松实现特殊墨水，油漆和
其他印刷效果。这样就不必降低标准从而实现满意效果。Spot-Color技术允许设计者轻松
将精密色彩用于广告设计等消费型艺术品上，甚至可以添加混合图版到CMYK图像中。这些
高质量色彩可以直接自Photoshop 5。0打印出来，也可输出存储成为DCS2。0格式，以供
在其他应用软件中使用。
从输入到输出，我们尽可信赖Photoshop 5。0色彩再现能力，因为Photoshop
5。0所提供的细致色彩获得ICC工业标准人证。在5。0版本中，广泛支持48位和64位色彩
图像，从而实现比32位更优秀的色彩保真度。色彩矫正技术使用户可以控制一个图像中不
同部分的色彩效果。新增添的通道（Channel）和混合器极大地增强了调整色制，例如色
调、饱和度以及曲率等的控制能力，更高的精确度完全满足精细色彩矫正工作的需要。
简言之，Adobe公司的Photoshop 5。0所提供的崭新色彩控制和校正技术适
应专业要求，在打印纸上，在显示屏上，可以轻松制作高质量的图像。
三、 自由构思从此开始
专业图像设计需要自由的编辑作品，同时又不致于浪费宝贵时间，从而在最
短时间内完成设计任务或制作复杂的图片。采用最新“历史调色板（history palette）
”技术的Photoshop 5。0能解决以上问题，让设计师重获自由 。
Photoshop 5。0的回退功能（Undo）不单单是以往简单的恢复或退到上一步
工作，历史调色板可以列出所有近期完成的步骤，这样你就能放心地将图像回复到先前任
意状态—仅仅是用鼠标进行单击。甚至可以为你的作品拍摄几张不同阶段的“快照（
Snapshots）放在历史调色板顶端供以后工作时随心所欲的调用。
别具一格的“历史画笔”（History Brush）与历史调色板齐心协力，互相
配合，可以让设计者将当前图片与某一“快照”或者较早状态图片中最佳部分相结合。
还原、重做、结合以及试验。
可以说，Photoshop 5。0中的这些撤消功能不仅仅是增添的选项，同时它们
将会成为一种标准，被其他软件所接纳，赋予使用者以急需的专业控制能力。
1. Premiere 5。0
PremierePAdobe Premeiere 5。0
做过视频编辑的人如果没有听说过Adobe公司的 是不可想象的，她拥有简洁的界面
，直观的工作窗，丰富的控制工具，优秀的音频编辑工具而为人称道，并成为此领域的佼
佼者。经过一段时间的沉寂后，Adobe终于将Premeier 升级到5。0极大地扩展了它的功
能，从而拥有了更强的竞争力。Premiere 5. 0能够进行专业的数字视频的编辑。它可以
满足小的视频工作室，多媒体和网络影象开发者，个人视频，工业设计展示等诸多方面
视频编辑需要。通过它一流的界面，Adobe Premeiere 5。0也可作为离线编辑器，轻松
地进行要求很高地广播视频电影的后期处理工作，这个令人兴奋的新产品还包括工作室
级的音频工具，并增加了强大的字幕控制能力，关键帧筛选器，提供强大的长格式编辑
能力，另外5。0版本的Premeiere 编辑器也变得更加灵活，Premiere5。0可以跨平台工
作，可以自由地在Windows和Mac平台间进行各种数据的传输。
在编辑方面通过Adobe Premiere5。0，用户可以在传统的非线性编辑上，即用一种允许3
- point编辑和其他高级的编辑技术方法，进行间接的资源重新安排和精确视频定位，
使用插入和覆盖按钮可以很简单地将剪辑定位于时间流程中，视频编辑可以被无缝地连
接在一起，先进的编辑能力还允许作者一边观看视频编辑的原材料，一边在效果监视窗
内编辑他们。
Premeere 5。0使用滑动编辑工具，从而保持在改变剪辑进出点时图像的连续性，因此可
以创作长达三个小时完整的音频食品，无论是NTSC制的每秒29。97帧，PAL制的每秒25帧
，还是电影中的每秒24帧。
使用一个改进的时间流程，你可以十分简单地在时间流程上标记、隐藏、显示、取消跟踪
，在时间流程中增加多达99个视频轨道和99个音频轨道。新的视频轨道可以出现原有的轨
道之上，以便显示电影的最后效果。允许连续撤消32次以前的操作，。
媒体管理方面有了很大的增强，方便的项目选择窗口来显示剪辑：可以在缩略图中用带有
文字说明的缩微图显示，也在图标窗口中用图标显示，或在六表中作为一个文件显示。在
用户定义和内建的数据区中搜索、排序剪辑包括文字、日期、文件路径及类型变得更加方
便。为了在几个项目中同时使用一个同一个视频剪辑，可以建立一个分开的剪辑库。还可
以设置对一个项目定时进行自动备份。
Preiere 5。0拥有21个专业音频滤镜，包括14个新增的滤镜，可以制作高质量的音轨。新
的滤镜允许你精确地为旋律设定一个动态的范围，删除嗡嗡的杂音声，正确控制延时效果
，提取或改变特殊的频率，模拟听觉的内部效果。通过自动调节引入的音频来协调声音播
放速度。可以精确指定用于网上循环播放的小数据量的高品质的音频抽样。可以工作在32
kHz到44MHz声音速率上，完全满足数字视频（DV）格式的需要。
设计人员可以精确地控制文字标题的滚动和移动，并可绘制文字或图形。在每一定义的文
字块内都可改变文字的大小、牙色和其他属性。可以设置标题的进入和离开位置，停留多
少秒和具体的帧数。文字的编辑效果可以很容易地在标题窗呃逆看到。Adobe Premiere
5。0提供大量特殊效果的滤镜，引入了PhotoShop的兼容插件，包括调节色彩的平衡、明
暗度、对比度、润化、扭曲变形等。用专业调节工具可以给添加的剪辑指定色度、亮度、
alpha通道或平滑程度。在动画方面，可以为一幅静止或运动的图像指定其运动的路径，
并可以同时设置诸如盘旋、缩小或放大、转动以及扭曲等各种特殊效果。再调节时间效
果上允许只任意个关键帧。还提供一个能很快地根据用户需要进行歼击间的特效过度的
转变面板。
扩展的硬件和软件支持，给用户带来了更大的灵活性。它可以和Adobe家族的其他软件，
Adobe Photoshop、Adobe AfterEffects及Adobe Illustrator进行良好的协作。能够自动
识别eps文件。并引入了photoshop层的概念。
Premiere 5。0有了强大的音频或视频捕获能力。视频的捕获可以通过人工或第三方设备的
控制来指定时间的起始和终止位置。甚至可以捕获DV格式的文件。不过这时需要一个FireWire
IEEE -1394端。你还可以为自己的视频捕捉卡设置存储特征。Premiere 5。0还能够自动
地捕获一批视频、为视频生产提供强有力的支持。
Premiere 5。0支持多种食品格式，包括大家所熟悉的AVI、MOV格式、引入视频还可以用
AVC（Preception Audio Video）和PVD（Perception Video） 格式。输出的格式还可以
用，AIFF（只在MAC平台）、flc/fli，以及一些静态图像格式，通过外部设备还可以输出
MPEG格式的文件。
也许您对Premiere 5。0并不十分熟悉，通过上面的介绍还是没有把握自己能否很好地应
用这些新特性，那么从现在开始。将逐渐介绍具有Premiere 5。0新特性的棉班和编辑工
具以及如何利用他们编辑您所需要的食品文件。
Adobe公司重新设计了Premiere的编辑截面，为了提高编辑的效率，更直观地得到专业的
编辑效果，去掉了许多不必要的窗口。当您进入Premeiere 5。0的时候，会首先看到监视
窗，新的监视窗强化了它在剪辑窗、预览窗、修饰窗和控制一贯拥有的强大的编辑工具，
这些有效的工作区提供了两个工作区，资源区和编辑区，用户可以把他们定制成老版本
样子，或干脆使用热键。
上面的图一是监视窗：
A· 是资源区，双击或拖动任意的剪辑，都可以查看或编辑他们。
B·这里是资源选择菜单，在这里可以选择你想编辑的剪辑资源。
C·这些按钮使用来控制资源的编辑和播放的。可以通过他们来播放、快进、倒退、循环、
停止至开头结尾等。
D· 这两个按钮一个是插入资源、一个是覆盖资源，可以将新的资源插入到时间
流程中，或覆盖当前的资源。
E· 单击上面的按钮可以从时间流程中删除某一片段，留下一端空白；单击下面
的按钮也是删除某一片段，只是后面的会紧接上来。
F· 这些键用来设置音量，缺省的转换效果，以及回到上一次或下一次的操作。
G· 和C的作用基本一致，他们用来控制观看所编辑的节目的结果。
H· 这个键用来分离监视窗的控制功能，用在有视频捕捉卡和视频显示卡的NTSC
或PAL制的监视器上。
I· 选择想插入的音频或视频剪辑。
J· 节目观察窗
K· 单击这里将弹出一些选项来控制监视窗的组成。包括跳换到修饰模式 （Trim
mode）、显示单一窗口，修饰模式和但一显示适合编辑两相互有联系的剪辑。
L· 选中这一项可以将资源和节目关联在一起，有助于观看各种资源是如何被组
织的。
<图片>
用Premiere制作影视作品
------------------------------------------------------------------------
1. Director
Director最早是以 VideoWork的名字出现在苹果机上，直到1989年改名为Director 1·0。之后几经升
级改版，于1994年推出PC机版Director 4·0，目前最新的版本是1997年推出的Director 6，它支持微软的Windows 3.X、
Windows 95/NT ,当然还有苹果的Macintosh .
从整体而言,Director以鼠标的选择、拖、拉等方式就可以生成多媒体节目。使用起来非常简单，很容易上手。
Director内部提供Lingo程序语言，可以帮助完成诸如与用户交互一类的许多复杂的功能。这是一种面向对象的解释语言，
只有熟练掌握这们语言才能成为真正的Director高手。
Direcotr是一个非常庞大复杂的多媒体开发系统，它的许多常用的概念和组成部分，是进行多媒体创作所必须
了解与掌握的。
Movie：电影。Director将用户（设计者）看成为导演，将多媒体节目看成为一部电影，那么编制的任意一段
Director程序就是一个Movie。Movie以 ·dir的文件格式保存。
Cast：演员。在Movie中用到的各种素材都称为Cast。包括图形、图像、声音、动画、文字、视频和调色板。
甚至可以是另外一个Movie。每个Cast作为一个member（成员）放在CastLib（演员表）中。相对于Movie而言CastLib可
分为内制（Internal）和外制（External）两种。内制的CastLib保存在Movie里。外制的CastLib保存在 ·cst格式文件中。
Stage：舞台。Stage是一个Movie的展示场地，是每个Cast等台的地方。实际上它是屏幕上的一个一定尺寸的区
域。通过设置可以改变Stage的一些属性。比如其大小尺寸、背景颜色、表现形式（是窗口式还是全屏式）等。
Score：脚本。Score是导演要化工夫去设计的演出内容。在这里规定某演员何时上场，做什么动作，何时退场，
以及在Stage上的各种特技效果的安排。Score是按时间来写的，分成若干个Frame（帧）。
Sprite：精灵。这个概念可能不太好理解。实际上它就是在Stage上的Cast。一个演员到了舞台上后就有了许多
不同之处，它要有所动作（表演），产生交互行为（对观众的问题有所反应），因此称这时的演员为精灵。一个Cast可能对
应着多个不同的Sprite。
Script：描述。实际上就是一段Lingo程序。它可以放在Score的某一时刻，由某一事件去执行来完成对Sprite的
控制，实现各种功能。也可以放在某一个Sprite上来产生特定的效果。
Frame：帧。是Score中的最小单位。整个Score是由许多Frame级组成的。可以调整每秒显示的帧数，以改变运行
的速度。程序运行时，会依帧顺序显示当前帧的演员。
Director运行时，Stage做为一个工作平台以背景形式显示在屏幕上；Cast按CastLib放一个窗口里（可能会用到
几个CastLib）；Score以一个窗口的形式出现，需要时，Director会弹出一个Script编辑窗口来完成Script编辑任务。导演
（设计者也即用户）最基本的操作是将Castlib中的一个Cast member拿出来，放到Score的特定Frame上，在Stage上观察效果，
然后对Score中的Sprite进行处理，达到心中所想的效果。
为了辅助导演进行工作，Director提供了许多工具。如Paint用来对图像，图形Cast进行润色黄状。Text用来输入
文本，进行文字版面设计。Tool palette提供多种画笔功能和前景及背景颜色的修改功能。Inspectors提供内存用量观察等辅
助调试手段。
用Director制作多媒体的方法与导演拍电影的过程相似。整个创作过程大致是先收集素材，然后在Director中调入
（Import）演员，接下来就要将演员按时间顺序放到舞台上，构成整个节目（movie），然后编辑各演员的各种行为（behavior）
以产生各种动画，特效以丰富画面。以上几步可能有反复，最后用Director编译形成一个可以执行的多媒体程序。
Director 6.0较之5.0加强了易用性，如Sprite编辑更加简单，对脚本(Score) 的改进，关键帧和自动生成中间帧，
Sprite信息的显示，Sprite inspector等等。
同时增加了关于Internet的改进，如同Internet中的媒体的联接，更多的用于网络的Lingo，与浏览器的结合，支持浏览器
脚本语言，支持Java等等。另外，Director 6.0还支持DirectSound, DirectDraw和MMX,很大程度上提高了其在Windows 95和NT
上的性能.
重复功能，它就象一张巨大的安全网一样保护着您的作品，这样可以在创作过程中随时回过头来进行修改，Freehand中的制表工具可帮你创作出生动形象地信息图表，甚至还可以使用定制工艺图作为图表中的图象文字，图表中的查找替换功能可以快速找到所需要的内容，例如颜色，线宽及对象类型，并轻松简便地对它们的属性进行修改。在Freehand中可以取得的效果是无穷无尽的，同时提供了全面的文本环境，包括检查拼写，绘制表格及拷贝文件等等，引入一个文本文件若想将其分成若干栏，这时只需简单地拖拉图象即可把它放到文本中来，如果想将图象放到某一个段落中，Freehand将会自动地围绕图象重新排列文本，使文本沿着某一路径排列非常简单，只需单击其类型即可，甚至还可以将图象粘贴到文本中来，通过Freehand及相关软件，可以将图象非常简单地移动到WEB或多媒体产品中，使用Shockwave可将本机向量移动到WEB页面上来，这样可将URL连接到任何Freehand对象上，这样可以将文件压缩到50% 以上，还可以将图形对象转换成一些别的格式，例如TIFF，GIF等等。Freehand中拥有许多新的打印功能，例如可兼容地颜色匹配及对高保真颜色进行打印预览，打印风格的支持，使用这些功能可以轻轻松送地创造出高品质的产品，Freehand的强大功能还远远不止这些，它可以使你的创作快速而高效，使你的时间用在设计里而不是等待上，Freehand为打印及Internet图形设计提供了一套非常完善的工具。
X
xdzhan
Unregistered / Unconfirmed
GUEST, unregistred user!
PC游戏编程
目录
1 游戏程序理论
1.1 技术基础
1.2 游戏底层
1.3 编写规则
1.4 程序设计
1.5 制作流程
1.6 程序调式
1.7 代码优化
2 游戏实践讨论
2.1 制作概况
2.2 模块划分
2.3 游戏引擎
2.4 关键讨论
2.5 希望
1 游戏程序理论
我做游戏的历史只有三年，我所写的内容都只是我在此期间的感觉和经验，还远远谈不
上完整和正确，甚至有些内容我们自己也没有完全达到，我只是试图说明我们曾经是怎样做
的和在最近的将来打算怎样做。
我读过一些关于如何制作游戏的文章和书籍，有外国的，也有国内的。有的过于难懂
(那些专业技术有的我根本看不懂)，有的过于简单，而且大都着重于程序编写技术。我在
这里希望能够提供其它方面的帮助，比如游戏中的程序设计，项目管理和与我们中国人编
写游戏相关联的一些问题。
我希望能够给那些想编写商业游戏和正在编写商业游戏的人们提供一个样本，这不是
最好的样本，而是在中国内地游戏制作业的初级阶段中一个普通产品的制作方法和经验。
如果是一个初学者，我希望给他一个编写游戏程序的完整印象，让他至少了解编游戏和玩
游戏是有区别的。
我希望阅读本文的人应该是一个程序员，熟练使用C语言和C++语言，曾经编写的单个
程序长度应该在5000行(150k)以上。因为我在这里不会介绍任何有关编程语言的语法，编
译等内容，如果你连这些内容都还没有弄清楚，请先学习一下，否则将很难与本文引起共
鸣。假如你是一位美术设计，游戏策划人员或游戏项目管理人员，虽然你无法看懂里面的
大部分内容，但是我也希望你能够了解里面的有关内容，因为如果你能够了解程序员的工
作，我们就能够更好地配合。
我更希望那些不了解游戏的人们能够看到本文，我希望他们能够了解编写游戏程序与
编写其它程序是一样艰巨和复杂的，制作游戏并不等同于玩游戏。
1.1 技术基础
1.1.1 人员
作一个商业游戏所需要的程序员的水平，可以分成三个级别：系统分析员、主模块程
序员和外围程序员。
·系统分析员：
这里的系统分析员也许比不上程序员资格考试中的系统分析员，因为我们制作的游戏
程序到目前为止都属于中小型程序，长度一般在50000到200000行之间(1.5M到6M)，经过压
缩之后源代码可以轻松放在一张软盘上。工作量一般在20到60人月之间。所以游戏程序的
复杂程度比一些大型应用程序要小。但是，游戏系统分析员的工作也一样是复杂繁重的。
他的主要工作是需求分析，程序设计和进度管理。
在需求分析阶段，主要是根据游戏设计制定的游戏方案确定那些内容是可以实现的，
那些是不能实现的；可以实现的部分如何实现，不能实现的部分该如何修改。最后制定一
个可行的游戏程序制作方案。这个方案最后被系统分析员写在程序设计文档中。当设计定
稿后，制定开发计划，组织人力开发，监督制作成果。
·主模块程序员：
过去我们的系统分析员和主模块程序员由同一人担任，但是到后来，我们发现，因为
程序的管理设计人员也要担任繁重的程序制作任务，很难面面俱到。所以我建议把主模块
程序员独立出来。由他来负责对游戏主要运行部分进行编程。这需要主模块程序员具有非
常丰富的编程经验，至少应该具有完成一个游戏的经验。但是其实每个人都是从不会到会
，从没有经验到经验丰富的，不能满足条件也没有关系，只要程序难度小一些就可以了。
·外围程序员：
游戏的程序一般都会被分割程序若干个模块，如果该模块独立性比较大就可以交给其
他人员完成。这些人只要有一定编程经验就可以胜任了。
1.1.2 编程平台
任何的计算机语言都可以被用来写游戏。游戏可以被运行在任何可能的计算机硬件设备
上。但是，因为我的制作经验的局限，我无法向你们介绍用Cobal语言编写AppleII上运行
的游戏。同样，我也不会教各位如何使用Visual Basic，Pascal或Java，任何形式的DOS程
序也是我不会花时间讲解的。在我后面的讨论中将只涉及在windows95/98下的Visual C++
编程。
现在，编写游戏时不能不提到Microsoft公司的DirectX。它是一套基于Windows95/NT
的游戏底层接口，在我们的游戏中使用了它作为底层接口。关于它的使用想必大家已经很
熟悉了，现在已经有中文的书籍出版，我不必赘述。
有的书上讲在编译和调试程序时最好使用Windows NT或双显示器，尤其因为DirectDraw
中独占显示器。可是我试过之后发现都不实用。对于WindowsNT，它的4.0版只支持DirectX
3.0， 听说5.0版才支持DirectX 6.0，但我总不能等到NT5.0出了之后才开始编吧。对于
双显示器，我一直耿耿于怀，外国人都很阔，每个人可以配备两台机器，可是，就算我找
到两台计算机，程序装入的速度实在让我不耐烦，调试一遍时间太长，等不起。
我们应该重视的倒应该是计算机的兼容性问题。为我们提供测试的计算机是很少的，
如何找到更多的条件才测试我们的程序是后期应该注意的问题，千万不要以为在Windows95
时代计算机硬件的差别已经没有了，它们出起错来更危险。
1.1.3 语言
在任何一本写游戏编程的外文书籍里都会提到编程语言主要有两种，汇编和C。有的书
里甚至不提倡使用C++。不使用C++的原因我猜有两个：第一，速度。据说C++代码比C代码
慢10%。这个数字我没有测试过，但C++比C慢大概应该是对的。因为用C++比直接用C编写
代码要方便和简单，所以速度应该会慢。第二，便于移植，移植这个词可很时髦，什么PC
到PS啦，PS到Saturn啦，Saturn到N64啦，N64到Mac啦，Mac到PC啦之类，一个游戏必须要
在所有地方出现才过瘾。如果使用C++就难了，因为象次世代游戏机上的开发环境，一般不
支持C++，N64虽然说是支持但仍然建议使用C。
使用汇编的理由也是很简单的，那就是快！因为游戏编程中表现最明显的地方就是游
戏的速度。汇编比C快的道理也是很明显的，那就是汇编要比C难写多了，速度自然快些。
那么速度就那么重要么?过去上学的时候，用汇编写出来的程序编译出来的一般十几k
，后来用C写的小程序大的有几十k，而现在编译windows程序，一上来就有一百多k。过去
的游戏就是绿色屏幕上几个字符，而现在都是真彩色的图象和实时三维。过去的游戏一个
人就可以“搞定”，而现在必须分工合作。这些给我的感觉就是游戏越做越大，程序越写
越长。是不是有一些方面开始变得与游戏速度一样甚至更加重要了呢?
有！这其实就是大家经常谈论到的一个问题：程序的Bug。一个程序如果越来越复杂，
越来越长，而且多个人共同编写，这时候就越容易出现程序中的臭虫。我认为，以我们目
前的程序编写水平而言，程序的正确性要远远高于它的效率。实际上，我在后面的主要篇
幅都在讲如何提高程序的正确性上，而只有很少的篇幅介绍程序的优化。
所以我选择编程语言主要是从其正确性和效率两个方面来考虑的。目前我选择C++。
这不仅仅因为我对这个语言最熟悉，更因为它的特点，对两个方面都符合得很好。
程序
是人写出来的，如果程序越容易写，就越容易正确，这方面汇编语言显然不是候选者，
Pascal虽然好，但是那些begin
和End写起来也太累。 C语言要省事得多，C++更进一步，
而且有了封装，继承，多态的概念。可是编写最方便的首选应该是Visual Basic，Delphi
和Java了。程序的框架都已经被准备好，只要在里面填东西就可以了。只是因为它们的效
率比较低，而不能成为游戏编写的最佳语言。
现在很难想象一个游戏整个都是用汇编写的，因为一个10000行的C程序改用汇编写至
少需要50000行，那其中出错的机会至少要多出5倍，而且汇编代码太过抽象，很难读懂。
所以应该只在非常需要效率的地方才需要使用汇编语言。
C语言与C++的差别不大，而且我认为C++所带来的封装的概念足以弥补它们的速度差
异。关于移植，有消息说Sega最新一代的游戏机DreamCast要使用Windows CE作为操作系
统，那么C++应该也会支持的了。大融合的时代总会到来，不同担心。我的C语言代码也主
要用于程序的底层。
那么，现在大家对我所使用的语言应该有所了解了。使用C++作为主要语言，同时辅助
以C和汇编。
1.1.4 编译环境
Microsoft Visual C++2.0/4.0/5.0/6.0是我一直使用的编译器。虽然Borland C++和
Watcom C++也可以编译Windows程序，我仍然认为Visual C++是最好的。没有别的理由，就
是因为习惯了。如果你已经习惯使用Watcom C或Free C什么的，也没必要改。如果从来没
有编过Windows程序，倒是可以先从这里开始。
我听说谁如果不会使用SoftICE调试程序就没有达到编程的顶峰，我一直以此为遗憾。
我不会使用SoftICE。我也远远没有达到编程的顶峰。“竟然这样的人也编起游戏来了”，
也许有的人会这样想，我想这没关系，因为本来谁都可以编游戏的嘛。
1.1.5 背景知识
编程序到底需不需要是专业人才，这也是个大家争论的话题。我还是那个观点，这只
是一个起点的问题，它只表明入门时候的速度而已。但这并不是说你什么都不需要学。有
许多东西需要我们学，甚至需要我们不停地学。
·硬件知识：
你总不能连自己的计算机是什么CPU都不知道吧。虽然我们不需要知道每个芯片的内部
构造，但如果我们知道了Pentium CPU有两条并行流水线同时处理指令的话，我们就会特别
注意这方面的优化了。
·操作系统：
我们的程序不一定需要多任务，多线程，但是了解我们的程序何时被调用是很重要的。
·数学：
数学是我最头痛的科目了。好在我们在这里所接触的大多是离散数学(我也很头痛!)。
最基本的要算是数理逻辑，就是程序中最普通的判断语句中的那些“与”，“或”，“非”
。其次是那些图论，概率。知道这些编写二维游戏就足够了。如果编写三维游戏，那就赶
快复习一下线性代数吧。
·专业课：
这是计算机系中学到的有关课程。虽然数据库，网络的概念在游戏编写中都可能会用
到，但是因为都是间接的，就不在这里说了。数据结构大概是最重要的课程了，这里所提
到的数组，队列，堆栈，链表，表，树，图等概念在我们的程序中几乎都会或多或少地用
到。另外，对于三维编程，还有一门叫计算机图形学，也是很重要的。
·文件：
与游戏密切相关的文件有图象文件，声音文件，视频文件等。这些知识越丰富对我们
编写游戏就越有用。可是，这也并不是绝对的，我在刚开始写游戏时连BMP图的格式都不
知道。
·美术：
大概每个游戏程序员都有过当“助美”(助理美工)的体验吧。当我们做程序测试，或
美术师们没有时间完成裁图，切图等“体力”劳动时，自然由我们来做这些工作。但是，
请记住，程序员永远是程序员，就算我们画得再好，也比不过他们的。
1.2 游戏底层
在我们编写每一个游戏时，都希望能有一部分代码可以重用，这样我们才能有更多的时
间做更多的事情。这些重用的代码就慢慢形成了游戏底层。游戏底层多了，自然就形成了一
些类别。
显示底层：
用于基本显示的函数。把常用的功能制作成函数，统一出错管理。对于Windows95/98下
的游戏编程，我们一般使用DirectX作为大部分底层的底层。因为这部分是我们可以用于编
程的最底层函数。对于二维显示，我们使用的是DirectDraw部分。为什么还需要在DirectDraw
外面再包一层函数呢?原因有三：第一，DirectDraw提供的函数扩充性很强，函数参数较多，
而我们使用时参数比较固定，包裹成类库后，参数更加可以封装起来；第二，DirectDraw
提供的函数比较分散，而有许多操作是需要多个函数按照一定顺序执行的，包装起来后编
写程序比较简单；第三，DirectDraw函数的返回值比较复杂，而且没有对错误进行系统的
处理，我们需要自己制作一套错误处理函数，对错误代码进行解释。
显示底层有许多种做法，可以完全自己开发，也可以直接使用别人完成的函数库，比
如Internet上比较流行的CDX类库就是对DirectDraw进行了很好封装的底层。
显示底层主要分成下面几个部分：
窗口处理：窗口的创建、管理、删除。
图形接口处理：图形设备的初始化、退出、显示模式的设定、主显示面、后缓
冲区的建立。
二维图形处理：游戏使用的二维图象的装入、显示、剪裁、逻辑操作。
外围工具：游戏使用的鼠标，刷新率计算和显示，显示内存斟测，面丢失
(Surface Lost)处理(在DirectX 6.0后据说可以不用)，错误处理，调试函数。
关于显示底层还有两个问题需要说明：
第一，显示部分的调试。因为我们所做的游戏一般为独占模式，在游戏运行时不能
跟踪(除非使用双显示器)，所以我们只能另想办法，一个比较常用的办法是使用窗口模式
和全屏模式切换。不一定在游戏运行中随时切换显示，在调试时事先指定也可以实现该功
能。
第二，多媒体播放底层：
播放多种声音，音乐，视频等多媒体效果。比较古老的一种办法是使用Windows 3.1
就开始使用的MCI调用。它是一种通用接口，使用不同的参数调用同一个函数就可以实现
基本相同的功能。用MCI可以实现的主要媒体类型有MIDI，WAVE，CDAUDIO，和VIDEO。它
的优点是使用简单。缺点则是缺乏交互性，而且同种类型的媒体不能同时播放。这样就很
难实现多种音效的混合。
一个基于DirectX的调用是使用DirectSound。它是基于WAVE文件的一套播放函数。非
常适合混音。缺点就是使用较复杂，而且如果想实现分段读取较长的WAVE文件，编程有些难度。
另外一个针对MIDI的DirectX是DirectMusic。它是DirectX系列中的一个新成员。
对于播放高质量的VIDEO(视频)文件，则有另外一套底层。比如Microsoft的ActiveMovie
和Intel的Indeo Video。有了它们我们就可以放心地全屏播放AVI文件了。
对于这些底层，我们所做的只是简单地封装上一层函数，使我们在使用该功能时达到最简便。
但是假如你对这些现成的播放程序不满意，也可以完全自己开发。只要你知道这些文件的格式，
再把它们存储成你需要的格式，用自己更加优化的算法将它显示出来就可以了。用这种方式你可以
自己播放AVI VIDEO， MPEG， MPEG2或FLI/FLC。
文件封装底层：
对使用的文本，图象等数据进行封装。我们也常用这种方式把多媒体文件封装起来，防止别人
事先查看。这种工作往往是循序渐进的，我们会根据自己的时间和实力，封装相应的部分。比如先
封装比较简单的文本，图象。然后是较为复杂的声音文件，最后是最复杂的视频和动画文件。
有的时候封装也是为了压缩。不仅再安装时少占用硬盘，装入时也可以节省时间，有时在运行
时也会减少内存占用而不会对速度有太大的影响。
根据文件类型的不同，我们可以这样分类：文本、图象、声音、视频、动画等。对于每种类型，
我们还必须有打包函数和解包函数之分。
界面底层：
自己编制的类Windows风格的界面类库。我总有这样的习惯，希望在我的游戏里没有一点Windows
的风格，于是我不会使用任何一点的有Windows风格的界面(游戏工具除外)。所以游戏的界面必须我们
自己做。然而我又使用过MFC那一套界面类库函数，很佩服Microsoft的本事。也希望我们的游戏中有
一套自己的界面系统。这套系统将会包含Windows用到的主要界面元素：位图(Bitmap)、按钮(Button)、
检查框(Checkbox)、滚动条(Scrollbar)、滑块(Slider)等等。
虽然Windows允许我们在使用标准界面时自己画图，但是因为它只支持256色，是基于消息响应机制
的显示，而且无法支持位图的封装，所以我们使用一套完全由自己制作的界面底层。这套底层建立在显
示底层和文件封装底层之上，形成了一套比较完整的系统。
上面这些只是一般游戏所需要的底层，对于某些特殊类型的游戏，可能还会有战略游戏的显示，操
作底层，RPG游戏的事件处理底层，战棋游戏的显示，智能底层，动作游戏的场景底层等。如果编写三维
程序，则还会有三维显示和操作底层。这些底层都不需要也不可能在一开始就全部完成，而必然是在不
断的修改和检验中完善的。它们也不可能一成不变，必然随着我们编程经验的积累和开发环境的改变而
改变和完善。
每个编写游戏的程序员都会慢慢积累出符合自己游戏特点的底层函数库，这些函数库如果得到不断的
发展和扩展将会越来越大，越来越好，这对于每个游戏制作公司和集体来讲都是一笔不可忽视的财富。
而这套函数库越来越复杂，再加上辅助的一整套工具，就可以被称之为游戏的引擎。有了引擎在手之后，
不仅意味着我们有了一套低Bug的现成代码，程序员的工作量将会大幅度下降，而且他们可以把更多的精力放
在游戏的优化、游戏的人工智能、游戏的操作、以及游戏性上面了。到了这个层次，我才可以想象一个好的
游戏将会是什么样子。
1.3 编写规则
现在，只需要一个程序员编写的程序已经很少了，大部分的程序都需要多个程序员的协作才能完成。这期
间必然需要程序员之间互相阅读代码。而代码的编写规则就是非常重要的环节。一段代码如果写的浅显易懂，
不但在程序交流时非常方便，而且对于寻找程序错误也时很有帮助的。程序员也是人，是人就会犯错误，不管
他多么地不愿意犯这个错误。所以我们也希望能制定下一个规则，使他们在一开始想犯错误也不行。于是就出
现了程序的编写规则。
如果不按照这些规则编写代码编译程序是不会报出错误的。但是如果按照规则编写，则对我们的思路的整理、
笔误的减少、错误的查找和代码的阅读都是极有好处的。
下面我只把规则中几个重要的部分加以简单的描述，在后面附录中会有一份我们已经使用了一段时间的完整规则。
命名规则：
程序中对变量和函数的命名看似简单，可是名字起得好与不好有很大的不同。对于变量我们一般采用匈牙利命名
法和微软命名法的结合。对于函数我们一般要把模块名写在函数名的开始。对于类库我们一般要求类的成员和成员函
数要紧密对应。
变量使用：
对于程序中所使用的所有变量，我们都需要其有明显的定义域。对于全局的变量要尽量封装。对
于类库，所有成员必须封装。
函数使用：
我们对函数的参数和返回值做了要求。对于函数的使用范围也做了规定，要求范围越小越好。
注释：
对于程序注释，我们虽然不需要很多，但是在函数声明、变量声明、主要算法部分、源程序文件的开始都需要有注释。
调试：
我们的底层和Visual C++都提供了一些供调试用的代码，在我们的代码中需要适时地使用这些代码，以提高程序的纠错机会。
这里有几个问题需要特别说明：
第一，关于链表的使用。
我在编程中所遇到的所有死机错误中，有90%来自于指针，9%来自于字符串(其实也是指针的一种)，1%来自死循环。而链表
这种把指针的优势发挥到极限的方式我是不提倡使用的。有人讲如果不会使用链表就不是C程序员，那么现在我连个合格的程序
员的资格都够不上了。的确，对许多人来讲，编写没有Bug的链表是很容易的事情，甚至对某些人而言，一个没有链表存在的程序
几乎不能称得上是商业程序。我承认有许多天才的程序员在自己的链表程序中表现得十分出色，他的程序效率既高又没有Bug，
但是我也知道还有更多的程序员并不是天才。就算是天才的程序员如果在他的十万行代码中有五万行于某些链表有关，这其中
的某个指针出了一个错误，而这个错误又不是每运行一次都出现的时候，他又有多大的把握很迅速地找到这个错误呢?链表的复
杂性在于它的地址的随机性，这使我们在调试跟踪时非常困难，我们很难随时观察每一个节点的信息，尤其当节点多的时候。所
以我把链表的使用完全限制在算法的需要和该代码被某个独立模块完全封装的情况下。
实际上我在设计程序时，要求尽量减少指针在主要模块之间的传递，而使用效率较低但是不易出错的句柄ID的方式。
第二，关于类库的成员。
既然我们使用了类库，其中一个主要目的就是要把其中的成员完全封装起来。首先把它设置为私有，然后定义标准的一
套Set和Get函数。这虽然使我们在写代码时比较烦琐，但是只有这样我们才可以严格规定该成员的只读属性和可写属性，
减少对某些重要变量的无意修改。
第三，关于变量和操作符之间的间隔
许多人对于变量和操作符之间的距离并不在意，认为多个空格少个空格只是看起来好不好看而已。而实际上，这对我们是
很重要的。因为如果我们把间隔固定下来，在查找某项操作时就可以使用带空格的字符串，
而大大增加找到的机会。
1.4 程序设计
我们在编写自己第一个游戏时，往往是凭借自己的兴趣，想到哪就编到哪，有时连自己都没想到
会编出这么大的程序来。那时侯我们对代码的修改往往是很随意和彻底的，因为本来都是自己的东西，
而且更希望它更好。可是，程序越写越大，有一个问题就会越来越明显，那就是程序的错误。为了减少
错误的产生，我们必须采取一些办法，所以也就产生了程序设计。程序设计的必要性还表现在另一个方面，
那就是程序员间的合作。为了让每个程序员对我们所要做的事和我们将如何做这件事有个明确的了解，
也为了让管理人员能够从量的角度了解任务的完成状况和进度，我们也必须有程序设计。否则我们就只能
象一群乌合之众一般，鬼才知道这游戏要做到什么时侯。
一般，我个人认为，当一个程序需要写到10000行以上时就应该有比较独立的程序设计文档了。可是
程序设计文档应该是什么样子呢?很抱歉，我也一直在寻找这个问题的答案。在我刚开始做游戏的时侯，
没有人教，于是我翻出上学用的课本，打算来个生搬硬套，写来写去，发现，不行。这样的写法太累了。
比如在软件工程课上所讲的数据流图，我好不容易写满了一张八开的纸，马上就发现自己已经糊涂了。就
算不马上糊涂，过一段时间我也会认不出那些条条框框是什么了。就算我能记得这些图表的意义，我能够
保证所写的代码和图表上的一样么?我写完后，还需要和这些表对一下。就算程序和文档中的内容一样，
那如果我的设计方案改了呢?又需要先改文档，再改程序，再对程序。这样对我来讲可太累了。
后来，我才发现，原来书上所写确实有道理，可是它并不是面向我们这些人的，它所面向的是写大型
程序的人。这些程序大到需要专门有这样的人来写文档。这些人只要把文档写好再确认完成的程序是否符
合要求就可以了，根本不用去写一句的代码。是啊，如果编游戏也有这样的工作就好了。可是很遗憾，目
前我尚未遇到可以聘有专职程序设计人员的公司。所以程序设计者就是程序编写者的这个事实起码在我们
的目前阶段是很难避免的了。
那么怎么设计文档对我们用处又大又比较节省时间呢?每个公司和每位程序设计人员的习惯都不一样，
我只介绍一下我们曾经使用过的一些方法和文档的类型。
程序设计总纲：
无论我们做什么，最先要清楚的一个问题就是：我们做什么?很弱智是不是?但是我发现有些人在很多时
侯都“不知道”自己在做什么。程序设计总纲就是要告诉自己和自己的伙伴们，我们要做的是什么样的游戏
程序。它包括：
游戏概述：游戏的背景、类型、操作方法、特点等；
程序概述：游戏程序的编译平台、硬件运行需求、语言、编程重点和难点、技术能力分析等；
程序员概述：参与编程的人的能力和在整个程序制做中的作用和地位；
程序模块划分概述：有本游戏所需要的所有程序，和程序内部的功能模块的划分。这部分只要有比较概
括的说明就可以了。
这篇文档的作用就是让所有人都能够了解本游戏的程序将会是什么样子，它的特点是什么，完成它的难
点又是什么。以及我们为什么要这样做，有谁来做等这样基本的问题。它所面向的对象除了有自己和本组内
的所有程序员以外，还应该有本游戏的游戏策划，美术设计、项目负责人、项目经理、制片人等。如果有可
能也应该和本公司的市场、销售、广告公关、出版、甚至公司总经理充分接触，听取各个方面的意见，也充
分表达自己的意见。如果能做到制做本游戏项目的所有人员从上到下对本游戏的程序制做都能有一个基本的
了解，理解和信心那是最好的。
程序模块划分：
这是对程序设计总纲中最后一个部分的详细说明。说明的内容主要有：该模块的功能、接口、技术要点、
所用到的软件底层等。它所面向的对象一般是所有的程序员，但是如果让与程序合作的人员(美术、策划、经理)
也能了解则更好，这样可以加强我们之间的勾通，让不懂编程的人也能了解编程人员的苦衷。
一般而言，一个游戏按功能划分(我们很少用其它的分类方法)可以有下面几个部分：
工具部分：在游戏的制做过程之中，从游戏策划的文档，游戏美工的图片到游戏完成，中间必须经过游戏程序
的转换和加工。这些数据在进入程序之前必须经过规整，排序等操作。这部分工作过去一般都是由程序员来做的。
在人手紧张和工作量比较小的时侯这样做还是可行的。但是如果这样的工作过于复杂，工作量太大，就不行了，我
们需要一种方法来提高工作效率。这种方法就是工具。其实我们在计算机所做的任何工作都是在使用工具，唯一的
区别只是这些工具都不是我们自己做的。因为游戏本身的特殊性，我们不可能总能找到我们所需要的工具，自己制
做就是十分必要的工作。
这些工具也可以分成三个级别：别人的工具，我们自己的可以重用的工具，我们自己的只在本游戏使用的工具。
别人的工具是最好的工具。原因很简单，因为它不用我们再去编了，不仅程序Bug较少，操作界面友好和简单，
而且开发时间是零。所以如果可能一定要使用别人做好的工具。如果实在没有满足要求的工具，或者我们还需要该
工具所没有的功能，我们只能自己编。那么如果这个工具可以被以后用到也不错。所以我们在编写任何工具的时侯，
其通用性是我们考虑的首要因素。
工具与游戏其它部分的程序有一个最大的区别，那就是工具程序是独立的可执行文件，它与游戏的唯一交互方式
就是存在磁盘上的文件。所以它比较适合交给其他的程序员制做。另外一个特点就是它一般都是针对非程序员的，所
以如果工具做好了，也可以很大程度上帮助他们提高工作效率。
底层部分：这部分程序代码的最大特点是可重用性。它是游戏本身与计算机通用系统之间的桥梁，它与游戏的具体
细节关系并不大，可以被使用到多种游戏类型和多个游戏之上。这对我们是非常重要的。实际上，我们编写程序所积累
的最直接的财富就是可重用的工具和游戏底层。
游戏底层从与游戏的相关性可以有大概三个层次：
最底层：它们向下直接调用系统函数和功能，向上与游戏几乎完全无关，是游戏程序与计算机系统的直接桥梁。它包括：
·显示底层：提供游戏显示所需要的所有函数；
·文件底层：提供对游戏所需的各种文件处理的接口；
·多媒体底层：提供游戏所需的多媒体效果，如声音，视频等；
·对于三维游戏有模型管理底层：专门保存，处理和显示三维数据；
中间层：它们向下调用最底层的游戏底层，向上为游戏提供函数。与游戏无关。它可能：
·界面底层：使用显示和文件底层，提供界面类库和操作函数；
最高层：它们向下调用中间层和最底层，向上为某种类型的游戏提供特殊的逻辑支持。它可能有：
·战略游戏的命令执行底层，显示底层，地图底层。
·RPG游戏的事件处理底层，场景底层。
这三个层次的制做难度是越来越难的。它往往需要我们在制作过几个游戏之后提炼和总结出来(实际上我们到现在也还没有发展出第
三个层次的底层)。但同时，这三个层次是越来越重要的，因为它距离一个成品游戏更进一步。我们在写游戏时可重用的部分越多，重用
的层次越高，我们的工作量就越少。我们也就越可能有时间研究和开发新的技术，好的算法，我们的游戏也就会越做越精。
相比之下，前面的两个底层都与计算机系统有关，与游戏本身无关；第三个底层与计算机系统无关，与某种类型的游戏有关。
底层部分与工具部分也是密切相关的。一般每一套底层都需要一些工具来与之对应。比如，我的显示底层需要某种格式的图片，我们
就要制做一个格式转换和图片观察的工具。把工具和底层结合起来分类，然后把它较给独立的程序员去完成，是一种比较常见的模块划分方法。
当然，我们在做游戏以前也不一定非要什么工具和底层不可，这些东西完全都可以“自然”产生。假如你能够坚持制做几个游戏，把可
以反复使用的程序归纳起来，修改一下，就是一套底层了。如果我们在编写程序时，每时每刻都在想：这段代码是否可以在以后使用，怎样
的写法可以使我在以后使用，那么我们在后来的修改工作中就会轻松很多。而假如我们在编写程序以前多花一些时间，把想要做的东西设计
清楚，在一开始就可以把它写成独立的底层代码。这样积少成多，我们的财富就会越来越丰富。
游戏本身：这才是我们每次都要做的游戏。所有体现游戏特色的内容全在这里。当然也有的人认为如果我们的经验足够丰富，想得足够全
面，连这部分的程序也可以重用起来。以后我们编游戏只要改一下图片，换几个名字，编一段故事，一个新游戏就产生了。实事上，也有公司
制做了一些类似游戏工具的东西，其中做得最好的应该是象Director， Autherware那样的多媒体编辑工具吧。但是，它们都有其局限。最明
显的一点就是：它们必须针对某一个类型的游戏或只能是多媒体程序，不同类型游戏的制做是有很大区别的，几乎很难用一个固定的模式将其
完全函盖。其次，它们创新困难，现在游戏几乎成了创新的代名词，哪一个游戏做出来没有它自己的特点呢?而使用一个固定的工具是很难做到
这一点的。第三，难以对它们进行优化。程序的优化往往和程序本身的特点有关，优化的程度越高，它的特殊性也会越大，所以，通用工具只
能牺牲一些性能。我到目前还没有看到一个游戏制做工具可以达到商业效果，而多媒体工具之所以流行正因为制作多媒体产品所需的模式比较
单一，对速度要求也不高。
所以，制作一个完全可以通用的游戏工具到目前仍然还只是一个梦想。但是，我想这是一个很美的梦，如果真的到那个时侯，我们制做游
戏将会和拍电影一样简单(我指的只是制做的过程)，只需要一个程序员根据策划的意思把图片和声音放在一起就可以了。
每个游戏都是不一样的，但它们都有一些相似的地方，比如：
游戏的操作：游戏者如何操作和控制游戏中的一个或多个主角；
游戏的显示：不是游戏的底层，而是与具体游戏有关的显示部分；
游戏的运动：游戏中有的内容是要不断变化的，包括位置变化，图片变化和形式变化；
游戏的智能；能够与人对抗的思考；
游戏的存储；把所有当前游戏需要的数据保存在磁盘上，然后再重新装入游戏；
游戏状态的转换：从界面到游戏，从游戏到动画，在不同的时侯有不同的操作和显示管理。
我们通常也会按照这样的规律对游戏进行模块划分。
游戏数据结构和算法：
有人讲程序就等于数据结构加算法。这句话很有道理。我们所编的程序其实就是把某种格式的数据(图片，主角的参数)经过一系列的转换，成为计算机屏幕上的数据(游戏本身)。所有的数据都需要以某种方式存储，这就是数据结构。而算法因为是与数据结构密切相关的，所以虽然它们不属于同一个概念，我把它们放在一起设计。
我们通常所使用的数据一般可以分成两个部分：数据库结构和当前结构。
这里的数据库不是什么商业数据库软件，而是游戏中所使用到的所有数据的集合。我还没有见到有哪个游戏在存储这些数据时使用商业数据库软件(比如FoxBase)。也许它们都被隐藏起来了吧，我猜想。但不管怎样，其意义是一样的，我们需要把所有在游戏中用到的数据都以一定的形式储存起来。同商业数据库一样，数据库的组成也是由字段组成，即数据元素。每个数据元素一般是一个类库或结构，有若干的成员。数据元素所组成的数组就是数据库结构中最主要的组成部分。
数据库的内容很多，而且按照一定的规则排列，而真正需要显示和当前需要计算的数据却很少，有些数据还是计算的中间结果，比如主角的位置，主角的动作等，这时侯就需要我们另外存储一些数据。它往往是数据库中的某个字段(数据元素)，或一些数据的组合。
如果把数据结构按照功能分类，我们还可以把它分成主数据结构，模块数据结构。它们的定义域是不一样的。
在我们的游戏中，会有许多数据结构的类库，它们之间也必然有数据结构之间的数据传递和保存。如何处理好这些数据之间的关系是编写这部分内容最重要的考虑。
首先是数据结构定义域的问题。在无数的教学课本上都在不断提醒大家，要尽量避免使用全局量。为什么要这样做呢?第一个原因显然是因为这样做的人太多了，我们使用全局量直接，方便，快捷，有什么理由不用呢?而答案也很简单，因为它暗含了错误，因为它不易于阅读和修改。于是我们用两个规则来限止全局量的使用：第一，尽量使用局部全局量，使该全局量的定义域最小，比如基于源程序文件的全局量，只有整个游戏的核心结构是全局范围内有效。第二，对于所有的全局量都对其内容进行全面的封装，如果是类库则使用成员函数，如果是结构，则定义专门的函数对其内容进行处理。
其次是数据的传递。我们经常遇到数据结构之间的互相调用和嵌套，很多人都喜欢使用指针(又是指针)做这项工作，因为它象全局量一样：直接、方便、快捷。但是我因为个人水平的问题在使用指针时总遇到一些不便，比如，易于出错，而且一旦出错就是很严重的当机，程序非法退出。要知道现在每启动一次计算机仍然是很耗费时间的。还有另外一个问题，那就是指针不能存盘，我必须另外制作一套程序对结构的存盘做特殊处理。所以我一般使用索引ID号来代替指针。具体的使用是这样的：数据库结构是以数据元素为单位的数组，数据元素的索引(ID)就是它在数据库数组中的下标。所有其它结构对该数据元素的保存都只保存了该元素的ID号。指针只在从数据库根据索引得到元素时使用。这样的好处很明显，ID号是整型数据，可以通过该值的范围判断出是否有效，只要在其有效范围内，再通过指针取值肯定是有效的，几乎跟本不会出现非法指针的现象。
程序开发计划
有了要做什么和怎么做，下面也就是需要什么时侯做和由谁来做了。
一般我们都会制定一系列的里程碑。比如演示版，原型版(体验版)，测试版和正式版等。在这之间也可能会有其它什么版本。然后制定完成每一个版本所需要的时间，主要内容和验收标准。除此之外，我们还有：
程序中每个模块的制作时间的表格，
每个程序员分工的说明，工作量说明。
编程过程中可能出现的风险和问题的说明。
在写完总计划以后，我们还会有更加详细的月计划，阶段性计划，我们还会写程序进度表。我们所做的一切都是为了游戏程序可以按时完成。
影响开发时间的主要因素有很多：
·资金因素：这些钱至少应该支持到我们可以把游戏做完，而且能够把我们的游戏向市场推出；
·市场因素：是否是销售旺季，是否有同类产品产生竞争，本类型，题材的游戏是否还受欢迎；
·策划因素：游戏的复杂性有多大，内容有多少，策划的进度是怎样的；
·美术因素：美术的制作进度是怎样的，何时可以提供需要的内容；
·技术因素：用户的计算机硬件是否已经准备好。我们的技术是否会过时，开发新技术的风险会有多大。还需要制作哪些外围工具；
·人员因素：程序员水平如何，配合状况如何。
程序设计人员需要仔细考虑这些因素，才能根据具体情况制定比较完善的程序制作计划。
但是，很不幸，我从没有按时完成一个游戏，所以我目前尚不知道妨碍我们按时完成进度的到底是计划不够好还是执行的人不够努力。总之，在做计划时一定要留有余地，而且我的经验是我们完成游戏的时间一般比计划的要多20%到30%。可是如果按照这样的计划去做游戏的话，一定会把投资人吓跑的。于是在现实生活中这种状况就变成了“先斩后奏”，写报告的时侯说时间很短，而到时侯我们就因为某些原因不得不拖期，反正钱也花了这么多了，必须再增加投资而把它做完。所以无论是直接制作游戏的人或者投资制作游戏的人，我都希望他们可以对这件事有个比较客观的了解。也许在将来制作游戏可以不必再加班，制作计划也可以按时完成，但是至少在我们这里，还必须随时面对它们，依靠我们顽强的毅力和坚忍不拔的精神把游戏做出来。
1.5 制作流程
等到游戏计划写完，并得到通过之后，我们便开始进入游戏制作的时间。其实游戏的制作可能从很早就开始了，比如早期的技术探讨和准备。而我在这里想再说得稍微远一些，远离现在的题目：程序，而转向整个游戏的制作。
整个游戏的制作过程一般可以分成三个阶段。策划阶段，制作阶段和调试阶段。它们之间的关系一般应该是在策划阶段后期，开始程序和美术的制作，在制作后期开始游戏的调试。它们三者的时间比应该是3：4：3。我认为这是一个理想状态，但是我们往往达不到理想状态，典型的情况是游戏策划迟迟不能定稿，我们不得不在一边设计游戏时一边制作，而到了后期，制作又很难按时完成，必然压缩调试时间，最后只好仓促地发售游戏。它们三者的时间变成了4：6：0。我所说的这种状态当然只是一个极端，但是我想在我们目前所开发的游戏中或多或少都有这方面的问题。
造成这个问题的原因也有很多：
·游戏立项不规范：人们不知道为什么要做这个游戏；
·策划设计工作准备不足：人们不清楚该做什么、什么时侯做、谁来做；
·制作人员水平有限，缺乏经验：自己做不好，或做不快，甚至都不知道该怎么做；
·资金：没有钱谁会做呢?
·项目缺乏管理：各部门缺乏协调，大家群龙无首，缺乏沟通，最后大大降低士气和工作热情。
但是无论这些因素都是些什么，以及它将如何严重地影响我们，我都觉得只要有一样东西就足以支持我们把这个游戏做完。这就是我们的坚持不懈的努力。现在，我们在市场上的游戏质量都不算很好，但是我要说，只要它被做出来了，就是一个成功的作品。我不管游戏玩家们对我这句话有何看法，我只是认为，在那些作品的背后一定有一个或一些人在努力着。也只有他们才能真正体会制作游戏的艰辛。而且，只要他们还能继续做下去，经验会逐渐增加，配合会更加默契，游戏也一定会越做越好。
游戏程序的制作过程与游戏的模块划分有关，大概可以分成三个阶段：工具制作阶段，底层制作阶段，游戏制作阶段。
底层制作可能是最开始进行的阶段，有可能与策划阶段同时，甚至更早。因为这个部分与具体游戏无关，而可能只与游戏所要运行的平台和我们所使用的开发工具有关。我认为，开始的时间应该越早越好。游戏程序员在技术上的准备如果越充分，制作起游戏来就会越顺利。
在策划大纲基本上完成后，也就是游戏的类型，模式基本上固定之后，就可以开始游戏工具的制作了。游戏工具一般是提供给美术人员，策划人员使用的(当然也有自己使用的)，所以在用户界面上应该多多听取他们的意见。这些天天与我们在一起的用户，如果我们都不能好好对待，那就更别提我们游戏的用户了。
游戏本身程序的制作是最耗费时间和精力的地方，如果说底层程序和工具都可以把重点放在结构化和优化上，这部分程序正好相反，我们通常做不到这些。因为我们在写这部分程序的时侯，总是已经精疲力尽了，而且我们的代码已经很长很长，一旦发现了程序错误，能找到就很不错了，更别提把它改得漂亮一点。再加上游戏策划随时提出的一点小改动，就可能要改变我们整体的数据结构，做大的改动几乎是不可能的。所以到了游戏制作后期，把程序员叫作铁匠更合适一些，他们在到处打补丁(注意，千万别在写游戏底层的时侯也干这种事)。
在游戏制作的中后期，每当程序员一睁开眼，进入眼帘的就是满是Bug和缺乏功能的游戏，这样的一个程序如何才能变成游戏中真正需要得程序呢?无论当初程序计划制定得多么好，在这时候都显得有些不中用。但这并不说明计划没用，而是需要我们把计划变成我们真正需要的东西，这就是每日工作计划。名字听起来很正式，其实并没有什么特殊的格式，仅仅是把我还没有做出来的游戏的内容一条条地写出来，不必区分什么模块和内容的多少，只要手写而且自己看得懂，然后贴在机箱上，要保证随时看到。这些内容我可能在一个星期后也没做，但是它会时时提醒我还有什么没有做。随着时间的推移，有些项目已经完成了，又会有新的内容写进来，而等到你最后积累出一大叠这种计划单时，你会发现原来游戏已经做完了。
这种办法我一直在使用，有时侯真觉得自己没有长进，做事一点计划也没有，可是它就是这么有效，你不必有什么经验，也不必整天面对着程序发呆，每天只要考虑如何把下面的内容做好就可以了。
不过我还是希望以后的程序员不必这样写程序，如果所有的人都能够每天按照预先制定好计划完成工作，也不需要加班，最终做出的游戏又很不错就好了。希望这不是永远的梦想。
1.6 程序调式
我在前面曾经说过，我不会使用SoftICE来调试程序。这证明我并不是一个很聪明的程序员。这也证明我在调试程序时会遇到更多的困难。让我每天在汇编代码和死机中漫游是件很痛苦的事，所以我总在想如何才能摆脱它们。
如果我不能很快地找到这些难缠的Bug，我能否在一开始就避免它们呢，甚至减少它们出现的机会呢?答案是肯定的。
死机(在Windows系统中有时是“非法指令”错)错误很主要的来源来自指针，但这并不是说我们就不能使用指针。恰恰相反，我们在很多地方都使用指针，而且出错的机会很少。原因很简单，那是因为我们在使用被保护的指针。如果你能证明你所使用的指针永远都指在合法的位置上，它还会出错么?所以我们在分配空间时大多使用静态空间和连续空间。所谓静态空间就是数组，连续空间就是指针数组。我们通过数组的下标来限制指针的读取，这样非常方便也有效。
封装也是减少错误的很好办法。我们把对内存的分配和释放封装起来，把对全局量的读取封装起来。在查找问题时就可以很快地缩小可疑对象。
对函数的返回值和错误代码的认真对待也可以让我们飞快地找到问题所在。很多人刚开始编程时都认为程序很短小，没必要写那么复杂的错误处理信息，也没必要判定函数的返回值。而我则恰恰相反，无论对待多么简单的程序我都会做非常详尽的错误处理。我甚至把显示错误的对话框写在底层程序中，以供随时调用。假如出现了错误，我就可以迅速知道错误发生的位置以及发生错误的大概原因，我的程序还可以正常地退出，不是继续执行而造成死机。
使用调试信息可以帮助我在Debug版中获得更多的有用信息。比较常用的有Assert()和OutputDebugString()。在错误刚刚发生时就拦截它要比它造成了更严重的影响后要好。
代码写得好看一些也有助于查错。假如你在一行中写进好几句代码，你将如何逐行跟踪呢?我们如果把函数，成员函数写得规范对称，虽然麻烦一些，但别人在使用时就会轻松多了。
这些办法都是在我们编写代码时需要注意的内容，我想如果你在准备开始编程时就对此有所准备，那么到你编程结束时应该能够节省不少调试错误的时间。但是Bug是一定会有的，无论你在当初如何注意，因为我们毕竟是人，会犯错误。我想任何人都有过把恒等号(双等于号)写成赋值号(单等于号)的经历吧(好在在Visual C++ 6.0中有这方面的警告了)。没有别的办法，我们仍然需要面对死机。一般的指针错误只会导致“非法指令”或“未知的意外”错误，除非你向一个不知名的地方写了大量的内容(比如几百K以上)，一般还是可以安全地退到系统中的。这得非常感谢微软，Windows95/98还是要比DOS好。可是如果你所访问的是系统区域，或申请了与硬件有关的调用，比如在DirectDraw的GetDC()中设置了断点，程序就会直接退回系统或干脆死机。
这个时侯就全凭我们自己了。但是也不要害怕，因为，我们所面对的仅仅是一些代码而已，我们有一个最为严格和伟大的力量：逻辑。这可能是程序员唯一能够全心全意依靠的力量了。所以请大胆地使用它。
如果程序出错，一定有它的道理。哪怕运行一千次只出现一次也是如此。所以我们改正错误的过程实际上也就是找到错误的过程。如何找到错误呢?可以试着用下面的方法：
屏蔽法：把一些代码去掉，再看错误是否消失了，如果已经消失，那么错误可能在刚才屏蔽掉的代码中，再屏蔽掉另外的代码，如果错误又出现了，则错误肯定在这段代码中。要注意的是，这样做不一定能够找到错误，因为，有时侯错误是由两段代码或多段代码相互影响造成的。而且有的时侯我们找到的地方可能并不是真正出错的地方，你只找到了错误被引发的地方，而引发错误的地方还需要我们再仔细找。比如，一个指针指错了地方，那么我们会发现出错的地方是引用指针的地方而不是写入指针的地方。这时侯就体现出封装变量的用处来了，我们可以很快查出这个指针到底在哪被修改了。
如果上面的方法不能奏效，而且错误是在我们刚刚修改了代码造成的，那么可以使用比较法，找到原来版本的文件进行比较。所以我们需要经常保存备份程序，一方面是为了保证程序不丢失，另一方面也会增加找到错误的机会。尤其是当我们到了编程的后期，我们的程序大都编完，正处于修改的状态，而时间又特别紧迫。如果一旦出现了错误，我们只要比较一下新旧版本，就很容易找到错误。
如果你跟踪了半天也没有结果，几网下去一条鱼也没捞上来，而且必须在全屏状态运行，不能单步跟踪，每执行一遍程序就死机，又需要重新启动，这又该怎么办呢?那也不要担心，我们还有最后一招：输出Log文件。在每一个需要监视的地方，增加一段程序，向磁盘文件输出一段文字，如果程序运行到这里，该文件就会多出一段文字，如果程序运行到这里之前就死机或退出了，那么出错的地方就在这段文字和上段文字之间。虽然这样做比较耗费时间和精力，但是基本上能够找到出错的地方。找到之后，我们再去找出错的原因吧。
但是万一你现在还是没有找到错误该怎么办呢?那也不要着急，我所遇到的找到错误的最长时间是整整一天，有的人会长达3天，但是我目前尚未遇到查找单个错误的时间超过一个星期的。如果你寻找错误的时间还没有达到这个长度，就不要急于认为这个错误你是永远找不到的。
其实最难找的错误并不是这些错误，因为这些错误是确实存在的，所以我们改正它只是时间问题。而比较难以调试的错误并不是每次运行都出现的，有的错误需要特定的环境和条件，比如只在某台计算机上出现，有的错误则需要特定的操作，比如打开某文件，再关上，有的错误则干脆需要运行一定的时间才可能出现，比如运行一个小时。这时侯我们的工作才真正艰巨起来。
这时侯，也往往是开发的最后关头，最紧张的时侯，如果出现了错误，将使我们直接面临一个最严峻的问题，到底是发行时间重要还是修改程序错误重要。我姑且不谈到底谁重要。关键是如何解决这些错误。这里你可以看到，把错误消灭于未然是多么重要。我们工作的重点现在转向了重现错误。使用出错的计算机，频繁重复执行某些有关的操作，随时存盘以保存最近时的信息，都是我们常用的办法。
有的时侯重新启动一次计算机，重新编译所有代码，更换一些驱动程序，都可以解决问题。但是有些问题我必须说明：
第一，要以负责任的态度来解决问题。如果你发现有一个地方很明显不会造成错误，但是修改一下之后错误确实消失了，这时侯千万要小心，因为这个错误可能这样被你又隐藏起来了，在以后的某个时侯(可能是最后的调试期)再次出现，这时侯它将会更加隐蔽。
第二，不要动不动就认为是编译器，驱动程序，操作系统或计算机硬件有问题，而不下功夫去寻找错误。这些东西确实会有问题，但它们出错的机会比起我们自己要小得多，我觉得初级程序员还很难发现它们的错误。有问题还是先从自己那里着手吧。
1.7 代码优化
我对代码优化的研究并不深，归根结底是因为我并不是个很聪明的程序员。我曾经见到过一本非常好的书，名叫<图形程序开发人员指南>，英文名是Michael Abrash's 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 中的有关指令吧。
在优化时要注意的问题有：
第一，不要本末倒置。先优化大的内容再优化小的部分。这样我们才总能找到最耗费时间的地方而优化它；
第二，要经常比较。需要对每一种可能的方法进行比较，而不能只听信书上写的。奇迹经常出现在这里；
第三，要在效率和可读性上掌握好平衡，不要光要求速度而不管结构如何，最后造成隐藏的错误；
2 游戏实践讨论
现在有很多人对国产游戏事业是又爱又恨的。爱的是希望能够出现一批真正属于我们自己的好游戏，恨的是这些游戏制作者们太不争气，到现在也没有做出来。我非常感谢他们，因为假如没有他们，也就没有了我们。我也感到非常抱歉，因为我们的作品目前还不能让人们满意。我想多说什么都是无用的，只有实事才能说话。前面我所说的大多是理论上的内容，是我们在几年的游戏制作过程中总结出的经验。这些内容有些可能是错误的，因为我们还没有从正面证明它，有些对我们至今仍然只是个美好的愿望，我们自己还没有真正做到。所以请大家在阅读时针对自己的情况进行取舍。
下面我利用我们曾经做过的一个游戏，具体分析它的制作过程和制作方法。希望借此为那些关心游戏制作的人提供尽可能多的材料，让他们了解得多一些。也为那些有志于游戏制作的人提供一些经验和教训，让他们少走一些弯路。要说明的是，我们在处理某些问题的时侯，所使用的方法很可能是非常普通的，甚至是笨拙的，别人看来可能有更好的办法。但是我不想与各位争论，假如您有什么更好的想法和办法，就把它用到你的游戏中去吧，我希望每一个喜爱游戏制作的人都能够制作出更好的游戏来。
2.1 制作概况
<赤壁>作为瞬间工作室成立以来的第一个作品，是1997年7月上市的，这个版本称作标准版。其后增加了网络功能，修改了一些Bug，增加了一些游戏事件，被称作增强版，增强版于1997年底上市。在此期间，我们又制作了日文版，韩文版和繁体版，又为国内的OEM厂商制作了相应的版本。据说<赤壁>全部的销售量超过了十万份，其中零售量超过一万五千份。这是与前导公司所有员工的努力分不开的。
<赤壁>的策划工作开始于<官渡>制作的后期，1996年6月。而程序开始的时间要晚一些，在1996年9月。那时侯我们碰巧见到了另一部国产游戏<生死之间>的早期版本。这给我们的震动非常大，因为这两个游戏的类型比较接近，而我们才刚刚开始这个游戏的制作而已。从程序开始动工，到第一个版本发行，一共9个月，先后参与程序编写的程序员有5人，总的工作量大约40个人月。程序代码的总量约为90000行，2.6MB。大部分用C++编写，少部分由C和汇编编写。我们使用Microsoft Visual C++ 4.0编译<赤壁>标准版，Microsoft Visual C++ 5.0编译<赤壁>增强版。可执行文件大小约为500多KB。
<赤壁>的工作进度如下：
程序设计期：1996年9月初至1996年11月底。
底层制作期：1996年12月初至1997年2月底。
游戏编写期：1997年3月初至1997年5月底。
游戏测试期：1997年6月初至1997年6月底。
日文版： 1997年8月。
OEM版： 1997年9月。
韩文版： 1997年11月。
繁体版： 1997年12月。
增强版： 1997年12月。
需要说明一点：那就是我们的所有程序全部都是自己完成的，没有使用任何其他人其他公司提供给我们的代码。要知道，我们公司当时还没有能力去购买国外的游戏引擎，而我个人连SoftICE都不会使用，更不要说跟踪研究别人的代码了。我们对别人的学习方式非常简单和直接，就是观察。通过观察猜测它所使用的方法，然后考虑自己如何把它实现。这可能是我想到的最笨的一种方法，如果一个程序员能力强，在制作游戏以前，详细分析了解别的游戏的算法我想一定是非常有用的，他在制作游戏时一定可以节约不少走弯路的时间。
另外，我们对<赤壁>的测试时间也是很短的，在程序基本稳定之后，我们大概只剩下两个星期左右的时间。所以有很多Bug。
2.2 模块划分
赤壁的程序分成五个大的部分和19个模块：
显示模块
战场显示模块
分为通用显示底层和游戏战场显示。
通用显示底层是基于DirectDraw的一套函数。
有关内容请详见DDApi.h， DDCompo.h。
游戏战场显示是根据游戏单元的类型，位置，状态，动画帧等数据将单元位图以适当形式显示在战场的适当的位置上。要显示的内容有：地形，单元(士兵/建筑/将领)，攻击效果，魔法效果，远程武器物体，阴影等。
主要功能有：对图素的压缩和读取，图像的显示，单元归属颜色的转换，边界剪裁，遮挡关系，缩略图显示和响应，屏幕移动，阴影遮挡判断，攻击效果，魔法效果，远程武器物体的显示和移动。
有关内容请详见CBDraw.h， 显示单元的位图
CBDrawM.h， 显示特殊效果，比如水。
CBDrawOT.h， 显示特殊物体。
CBMini.h， 显示缩略图。
CBMap.h， 图素的操作。
CBShadow.h， 阴影的计算和显示。
CBOther.h， 特殊效果的显示和计算。
界面显示模块
根据游戏设计需要，在显示器相应的位置上显示游戏的各层界面。
它分为两个部分：界面底层部分和游戏界面部分。
界面底层是属于底层部分的通用函数库。它包括按钮，对话框，滑块，检查框等界面元素的实现。
有关内容请详见DDBitmap.h， 显示位图的基类。
DDButton.h， 按钮。
DDCheck.h， 检查框。
DDList.h， 列表框。
DDMenu.h， 菜单。
DDScroll.h， 滚动条。
DDText.h， 文字。
游戏界面主要有：游戏主菜单，新游戏菜单，读取进度菜单，保存进度菜单，网络选择菜单，系统设置菜单，任务提示菜单，结束菜单，错误处理对话框等。
有关内容请详见Interfac.h， 提供基本的游戏界面接口函数。
Interfa1.h， 处理所有的按钮Button信息。
Interfa2.h， 处理所有鼠标操作发出的消息。
net_face.h， 网络部分界面。
Marco.h， 所有按钮的消息ID。
CBprompt.h， 游戏战场中屏幕右方信息的显示。
CBAarray.h， 对游戏元素的查询。
DDComUn.h， 针对游戏中下达命令时的命令组。
过场动画模块
显示公司标志，制作群，历时回顾，片头，片尾和过场动画。
它有两个部分，第一是播放视频图像，第二是调用其它进程。
有关内容请详见CBAvi.h， 视频图像的播放。
Mciapi.h， 播放AVI文件的底层函数。
VCMApi.h， 高效率的播放AVI的底层函数。
CBGame.h， 播放结尾。
Interface.h， 程序状态的转换。
单挑显示模块
武将单挑时出现的专门画面。本部分与原始设计有出入，原始设计中可以对单挑进行操作，后来删减称为只播放一段Video。有关内容请详见CBAvi.h。
控制模块
鼠标控制模块
根据鼠标的位置设置鼠标的形状，对鼠标的操作对响应单元发出命令。
主要内容有：鼠标点击检测，目的地模式，命令构造，可建造区域判定，鼠标形状转换。
鼠标点击检测，主要判断鼠标点击的位置是否在某个单元上或地形上。详见CBMouse.h。
目的地模式，主要控制鼠标选择了单元(命令主体)后，可能对单元下达的命令的模式，根据不同的命令可能需要不同的目的地类型和命令参数。详见CBCtrl.h。
命令构造，通过鼠标的点击选择或按下某个，命令按钮，构造出具有命令主体，命令ID和命令客体的命令，放到命令队列中，供执行。详见CBCtrl.h。
可建造区域判定，在建造建筑时需要判断哪里可以建造哪里不可以， 并且显示出来。详见CBBuild.h。
鼠标形状转换，鼠标移动到某个界面或某个单元上时，或处于命令构造阶段时，需要对鼠标的形状做一定的改变，以显示当前的操作状态。详见CBMouse.h。
命令处理模块
根据鼠标和人工智能发出的命令，传送给对象单元，并将其转化成为单元的相应状态序列。
根据单元状态，判断单元状况，更改单元的状态。
详见CBCtrl.h， 命令的构造保存和传递。
CBRun.h， 命令的执行。
CBRDelay.h， 命令执行时需要的一些变量。
攻击计算模块
根据敌我双方的攻防力量，计谋的实施和阵型计算每一次打击敌人生命的损失。
详见CBRun.h， 攻击计算。
CBZhenFa.h， 阵法计算。
行军控制模块
根据单元的位置，速度，目的地和地形数据，计算行军路线，设置单元的下一步。详见March_n.h。
网络控制模块
游戏数据在网络上的传递，纠错。模拟机的建立和管理。详见Network.h。
策略模块
君主策略模块
计算机一方根据战场双方的力量对比和战斗模式计算对单元的生产，对敌人的攻击，产生命令。
详见TEmperor.h。
将领策略模块
每一支部队根据将领的属性，士兵的状况调整战斗的方式或判断撤退。
详见TGeneral.h。
本能策略模块
士兵单元面对周围的情况产生固定的基本反应。
详见Tai.h。
Tbnbase.h， 人工智能中需要的数据结构。
CBEyes.h， 人工智能与游戏主体结构之间的接口。
文件模块
资料数据文件模块
地形和单元图素的图像文件，相应控制数据文件。单元的各项属性数据文件，操作用数据文件，界
面位置数据文件。
详见CBData.h， 游戏中使用的单元属性全局数据结构。
CBMap.h， 游戏中使用的地图图素，单元图素全局数据结构。
CBGame.h， 游戏中使用的单元全局数据结构。
存储数据文件模块
存盘用数据，记录战场上的所有单元的状态和思考数据。
详见CBGame.h， 存盘。
其它模块
文件封装模块
为减少程序使用的文件的数量，增加程序的安全性，将大量的图像文件和数据文件封装起来，供程序调用。
详见L_Allbmp.h， L_Image.h， L_Save.h， L_Scan.h， L_Text.h， Tools.h。
声音模块
背景音乐和音效。有混音和音量控制。
详见DsWave.h， 播放WAV文件。
文字模块
在非中文系统下显示汉字，日文，繁体汉字和韩文。详见puthz.h。
地图编辑器
为使美术人员方便快捷规范地制做战场地图，提供专门的地图编辑器。同时为整个游戏的文件系统，
显示系统做技术上的准备。
这是一个单独运行的程序，详见Mapedit。exe。
安装程序
将游戏安装和卸载。详见Setup。exe。
2.3 游戏引擎
说到游戏的引擎，很多人都不知道它是什么，以为制作它有多么困难。引擎的概念也很混乱，至少现在我还不知道它的确切定义。但我想如果一个东西要被称作引擎，它应该具有这样一些特点：
它应该是由函数组成的。
它应该实现某项具体功能。
它应该是完整的。
它应该可以被重新使用。
从上面的要求可以看出，其实这就是作为底层程序的要求。我想没有必要把引擎认为是游戏的现成编写工具，只要2改一下美术就是另一个游戏了。只要这些程序代码将会被我们应用在以后的游戏中，我们就已经节约了很多的时间和精力。
下面我会说一下在<赤壁>的代码里，哪些将被看作我们的引擎。实际上，这些部分经过一些修改后正在被我们应用到新的产品中。
显示底层：
这是一套包裹在DirectDraw外面的函数。为了简化在调用DirectDraw函数时的复杂度我们使用了一些缺省参数和内部错误处理函数。建立了一个CDDSurface类库，使得对位图的使用更加简单。详见DDApi.h
在DDCompo.h中我们有关于游戏鼠标的一套操作。在屏幕独占模式中，Windows标准鼠标有时显示会不正常。于是我们自己制作了鼠标的显示方法。方法很简单，在每帧读取鼠标的位置，然后在该位置上显示一张位图。
在赤壁里面，我们没有使用双缓冲区的模式，而是只更新某个特定的区域。它的优点是当需要更新哪里的时侯就更新哪里，对于哪些在每帧中都只有小面积图像需要更新时是非常高效的。比如在486上，<赤壁>的主游戏界面里的鼠标移动仍然是十分流畅的。可惜的是，在<赤壁>的战场部分，它并没有优势，因为基本上是需要全屏刷新的。
在未来的游戏制作中，因为计算机的速度越来越快，所以我们当时所使用的模式恐怕变得不太适用，双缓冲区模式应该是主流方向。
多媒体底层：
主要包括声音和视频。我们使用了MCI设备来播放AVI，WAV，MIDI，CD AUDIO等内容。那曾经是我们在做上一个游戏的时侯完成的部分。但是它有很多缺点，比如不能同时播放多个WAV文件，这对于我们制作游戏音效是很重要的内容。
所以我们又使用DirectSound来播放声音。这里的难点在于当我们需要播放很长的文件时，不能一次读入，而需要建立新的线程按时装入声音。好在现在大部分游戏都使用CD Audio作为背景音乐，不需要WAV。
界面底层：
基于显示底层之上的界面元素其实并不好做。因为我们总希望它的响应方式与Windows95中相同。而大家在<赤壁>里看到的内容就与Windows95有些不一样。比如滚动条(ScrollBar)对鼠标的响应就非常简单，按钮(Button)的反应也有所不同。但是好在它比较简单，易于使用。
在每做完一个游戏之后，我们都习惯要把某些东西整理一下，看看它是否可以在以后被使用起来。而往往这些东西也都是需要不断修改的。因为程序运行的平台不一样了，它的用途也不一样了，而我们的编程水平也不一样了。但总之这些代码被较为完整地保留了下来，它必将是我们今后编程的基石。
2.4 关键讨论
我刚开始编写游戏的时侯总有一个想法，只要游戏的主要部分写完了，游戏也就差不多了。我也遇到过一些游戏制作组的成员，他们也大都是这样的想法，认为只要把游戏的演示版拿给别人一看，然后只要再投资让美工画一些画，游戏就可以做完了。其实事情并不想想象中那样简单。
在我看来，把游戏的大概样子做完了，顶多占整个游戏的三分之一。另外的两个三分之一分别是整个游戏的制作和测试。
举个简单的例子，比如我们在演示版中通常只有一个兵种和一个战场。游戏的显示效果可能很不错。但是，真正在游戏中不会只有一个兵种的，每方都会有大概十种兵，又会有三四方的敌人，这时侯你的显示底层是否能够胜任呢?内存是否会占用太多呢?这时侯还需要我们对其进行优化和修改。连游戏的底层显示部分都可能需要修改，更何况游戏中还有更多的内容呢?
下面我举一些<赤壁>中的例子，这些都可能是极小的问题，但都是我们需要仔细考虑的问题。在你准备开始制作一个即时战略游戏之前，你是否曾经考虑过这些问题呢?假如你对这些问题有所了解，那么你就应该可以非常有把握地马上开始制作游戏。如果没有，也没有关系，因为这些问题我也没有全都事先考虑过。
假如你有时间，可以对你自己的游戏多多考虑一下，这个游戏距离一个真正的产品，到底还缺什么?还有哪些模块和部分没有做完?当你对两者之间的差距有了一个明确的认识后，也就不会担心了。任何东西都是一点一点做出来的，只要按照你想做的内容去做就可以了。
程序状态的转换
我们在写DirectX程序的时侯，总有一种偏见，那就是不希望Windows界面出现在我们的游戏里。于是什么都需要我们自己做。比如说窗口。因为窗口的刷新需要我们自己管理，就觉得没有必要生成多个窗口了。这样所有的窗口消息就必须在唯一的一个函数里实现。可是我们的游戏里有很多种不同的操作，比如界面，系统菜单，播放视频等，这些内容就都必须在这个地方处理。所以我们就引入了程序状态这个概念。我们定义了一系列的状态，在每个状态里，有固定的操作和响应，状态之间的转换也在特定的时侯进行。这样我们就很容易把一些关系不大的内容独立开来，降低程序的复杂性。
其实我们在实现这一部分的时侯是很混乱的。你很难在代码中找到所有状态转换的地方。但是它的实现很简单，一般的规则就是程序的对称性。有专门的装入函数和释放函数，然后有显示函数，计算函数，鼠标消息响应函数，热键响应函数。在内部，需要结束本状态时就发出一个状态转换的消息。在外部，只要在主程序的主循环和消息响应函数处针对不同的状态执行它们不同的函数就可以了。
这里的关键在于状态的转换。因为状态在转换中一定会释放和申请大量内存，如果有的内存没有释放，转换次数一多就会出现问题。如果我们把状态转换的地方写好了，程序看起来也非常干净整齐，Bug也会比较少。
现在编写游戏，需要装入的图量非常大，很有必要制作一个装入时的画面，并且显示百分比。这是我们可能需要一个装入中的状态。遗憾的是<赤壁>并没有实现这个，它的淡入淡出效果仅仅是效果，程序在执行这部分时停止在这里。
有关内容请详见CBGame.cpp和Interfac.cpp。
执行任务
一个士兵在接到我的命令之后，便开始了它的行动。它察看了一下它的命令，这是由两个部分组成的。它先取出第一个部分，是行走。于是根据自己现在的位置和目的地位置先计算了一下路线，把自己当前的状态设置为正在移动，然后根据计算好的方向和自己的速度把自己移动到一个位置。如果这个位置已经到达目的地了，它就停止行走。又察看了一下剩余命令的部分，是攻击。于是它拔出刀砍向附近的一个敌人。敌人死了么?它不停地问自己。如果敌人真的"哇"的一声倒下了，它就得意地站在一旁，微笑着。
这就是我们在战场的一个角落所看到的一个士兵的表现。而实事上，在程序里我们也是这样做的。
我们把每个士兵做为一个单元，独立地处理自己的事物。我们把每个命令划分得更加细致，而称其为状态，执行每个状态时所需要的参数的执行的步骤是最简化的。每个命令都是由一个或多个状态组成的。一个状态满足后就自动转向下一个状态。我们为每个状态都编写专门的开始，运行中，和结束代码。这样每个士兵都在独立地按照顺序处理自己的事务，一个个复杂的单元行动就变得有条有理了。
有关内容请详见CBRun.cpp。
阴影
有人说Warcraft做得好，有人说C&C做得好。我属于前者一派，这不仅仅因为我对Warcraft的观察多一些，而且有一个理由足以说明Warcraft在程序上比C&C更高一筹。那就是阴影。大家都知道Warcraft是双层阴影，而C&C是单层。双层阴影的好处是更加真实。在我们去过一个地方之后，虽然我已经看清楚了地形，但是这里敌人的活动，我们不应该永远知道。可是要把单层阴影变成双层，并不是只要加上一层显示就可以解决问题的。
首先，增加一层阴影就增加了需要显示的时间。时间对于即时战略来讲是至关重要的。它直接影响到游戏的表现效果和操作速度。多加一层阴影就意味着减少了我们增加效果的机会。在我们这里，双层阴影占用了大约5-10%的显示时间。
其次，增加一层阴影就增加了特殊的计算。一层阴影只需要一个二进制数组记录哪里被打开，哪里被隐藏就可以了。而现在则不同，我们需要把那些已经打开的阴影再关上。我们的做法是生成一个二维数组，每位表示一个图素格子。当有一个士兵的视野可以打开这个格子上的阴影时，就把那里的计数器加一，离开时减一。当为0时则这块地形被重新隐藏。
第三，阴影下的单元需要特殊的处理。当我的士兵离开敌人阵地的时侯，敌人附近被半透明的阴影重新覆盖了，这时我们需要把正在那里活动的敌人士兵隐藏起来，而建筑不动。
这就是双层阴影所带来的。可是为了效果，我们不得不如此。看起来还是达到了效果。
除了双层阴影以外，阴影的边界也是很重要的问题。我们不可能把阴影做得和刀切的一样，而让它必须和打开的地面相结合。于是我们必须要有一套贴图，用于阴影边界的各个方向。好在我们在这里利用了一个偷懒的办法(当然是很巧的办法，是Onefish想出来的)。我们采用了一个椭圆的贴图，让相邻的椭圆相切，从而造成边界。因为椭圆是没有方向之分的，我们也就节省了一些贴图的内存和对使用哪张贴图的复杂计算。
有关内容请详见CBShadow.cpp。
选中谁了
<赤壁>战场里的格子是菱形的。这一点有多少人发现了?又有多少人知道它的代价?或许有人认为菱形的格子并不是个很好的注意，但我们恰巧在这里使用了它。当鼠标按下时我们需要知道它放在哪个格子里了。过去的经验是只要知道该点的位置和每个格子的宽度我们就可以很快地算出格子的序号。但是在这里不行，因为格子是菱形的，在一个矩形区域里的点不能被确定它到底属于哪个格子。
怎么办呢?我制作了一个二进制二维数组，大小是格子的宽和高。在这个区域里，如果是属于矩形内接菱形区域内的点设置为1，否则为0。当鼠标在某个矩形区域里时，我就用这个栅格去判断该点的位置上的数值是1还是0。是1则这个点在这个菱形格子里，否则不在。这个办法是我遇到的比较迅速的一个办法。
命令的产生
一个由游戏者发出的命令，一般有三个部分：命令主体，命令本身和命令客体。命令主体就是执行命令的人。我想对这支部队下达命令，这支部队就是命令的主体，在游戏里就是我们用鼠标选中的一群士兵。命令本身是命令的标识。我想下达的是什么样的命令，在游戏里，可能是我按下了某个命令按钮。命令客体是命令结果的接受者，如果我选择了攻击命令之后，再选择了一群敌人，那敌人就是命令客体。
如果所有的命令都这样下达，那编起程序就简单了，玩游戏的人也会累死了。我们常用的玩法是选择了命令的主体后直接用鼠标右键点击命令客体。而命令的产生就由命令主体和命令客体的类别来确定了。
这才是需要我们考虑的东西。
首先是选择命令主体。当我们在战场上鼠标一点，或圈了一个框，然后一松手，这时侯程序就开始算了。这里我要介绍一下<赤壁>的单元类型。我们把单元分成士兵，将领和建筑。士兵又有已经组建成部队的和尚未组建成部队的。士兵的种类可以分成一般士兵，工人和船。我们的选择规则是：组队的士兵优先于建筑。将领优先于组队的士兵。未组队的一般士兵优先于将领，未组队的船优先于一般士兵，未组队的工人优先于船。另外还有特殊处理。按下Ctrl键则选中该组队士兵的将领，按下Shift键则把刚选中的士兵添加到已选中的士兵中。
其次，是选择命令的客体。命令客体可分为地点和单元。地点有普通地点和资源地点。单元又分为敌人的和我方的。单元的种类有士兵，将领和建筑。士兵分为未组队的和组队的。士兵的种类有工人和一般士兵。建筑又分为一般建筑和资源建筑。我们需要根据命令主体和客体共同来判断命令是什么。不同的组合所产生的命令可能可能是不同的。比如，如果我选择了组队的工人作为命令主体，又选择了一个建筑作为命令客体。如果这个建筑是铁矿，那么命令就是采矿。如果这个建筑是我方的建筑，则这个命令是修理。如果这个建筑是敌人的建筑，那这个命令就是攻击了。
有关内容请详见CBCtrl.cpp。
眼睛函数
在游戏策划编写人工智能的时侯，总喜欢写成这样：“当匪兵甲发现敌人就在不远处时就去攻击。”而要把这句话变成程序，还需要不少的路要走。比如匪兵甲是如何发现敌人就在附近呢?首先必须要知道匪兵甲自己在什么地方，其次匪兵甲的视野有多大，也就是说多远算作附近，第三敌人在哪里。这三样东西匪兵甲是如何知道的呢?依靠的就是眼睛函数。
一般我们在编写人工智能时都会把它作为一个比较独立的模块。因为它的主要功能就是判断。它的出口同游戏者的鼠标操作一样，发布命令。如果它的入口也很明确和简单则这部分内容的难度就非常小了。可是人工智能需要得到大量的信息作为判断的依据，而我们的主体数据结构又可能写得不很好，这时候就需要我们另外制作一套程序把游戏内核与人工智能分开。这就是眼睛函数的用处。
编写人工智能的程序员只需要写出他想知道什么，然后交给游戏核心程序员，由游戏核心程序员从游戏核心数据中找到相应的信息，传递给人工智能。这样编写人工智能的程序员就可以根本不知道游戏核心数据是什么样子就可以开始工作了。但是这也是临时的办法，
如果我们可以把核心数据结构写得风雨不透那也不必如此劳神了。
有关内容请详见CBEyes.cpp。
命令队列与网络
本以为网络编程很简单，一写下来才知道头大。虽然这部分代码不是我写的，但是我也知道跟踪一个10兆大的Log文件是什么滋味。网络上的游戏通讯一般有两个办法：交换所有信息和交换重要信息。第一种方法是随时把自己的所有数据都传递到另一端，另一端根据这些数据进行显示和操作。它的优点是不需要同步，对网络状况要求低，计算也非常简单。缺点则是数据量太大，只传递少量数据还可以接受。所以这种方法多用于RPG游戏并多在Internet上使用。第二种方法则只传递关键的数据，计算机接到这些数据后对其进行计算，因为计算的结果是唯一的，所以可以保证网络两端一致。这种方法适用于那些数据量大的游戏，但它的编写和调试就比较复杂，而且对同步的要求较高。我们的<赤壁>就是采用的这种方法(<西游记>用的是第一种方法)。
在这种网络的联接方式中，最重要的问题一个是同步，一个是结果唯一。只有同步我们才能保证在每一轮的计算中所有计算机上的初始状况是统一的，只有结果唯一我们才能保证在执行了一段时间后所有计算机上的状态是统一的。这样才能保证网络游戏的正确性。
除了初始化等必要得操作以外，我们把游戏中的命令作为关键信息在网络上传递。游戏者对战场上部队的任何操作，下达的任何命令都会被传递给其它的计算机。如果游戏者没有操作，则我们制3在每一轮循环中传递同步信号。在这里我们遇到了一个DirectPlay中的问题，那就是信号并不是每次都会正确传递到对方那里的，尽管我们在DirectPlay中使用的参数要求系统必须在确认对方收到后才返回，可是它返回后对方依然没有收到。关于这个问题我没有查看有关文档，也许有更好的解决办法。所以我们自己制作了一套校验确认的方法。
但是我们在本机上发布的命令传递到另一台计算机上时一定会有延迟，这就不能保证初始状态的一致。所以我们采用了轮回制。任何人发布的命令并不会马上被执行，而是先存储到一个命令队列中。在每次循环中对曾经下达的所有命令统一进行发送，侦听。当所有计算机都收到了所有计算机本轮要执行的命令后，所有的命令开始被顺序执行。这样在任何一台计算机上本轮中所有命令的内容和顺序都是相同的，执行时才能保证其结果的一致。
有关内容请详见CBCtrl.cpp， CBRun.cpp。
兵种的颜色
这大概是即时战略游戏里最隐蔽的一个问题了。因为不做的人不知道，而做的人都心照不宣。在我们的游戏里，不同的君主用不同的颜色代表，属于该君主的士兵则在它的衣服上赋予相应的颜色。这样虽然兵种相同但是他们的颜色不同，这样就可以区分敌我了。但是如果我为每一个兵种都制作一套图素，那么就显得有些浪费了，这会占用过多的内存(我们这里所有兵种的图素量约有10MB，如果有四种颜色就需要40MB的图素)。谁都希望找到一个好的办法节省这些内容。
我们的方法很简单，抽色。我们在调色板里的留出固定的位置，需要改变的颜色就按照顺序存储在这里。在显示时，我们会根据传递进来的君主号为每张图素的颜色进行判断，如果颜色在这些区域里就根据规则偏移。这样各种颜色的士兵就会显示出来，而只需要一份图素。
这种方法的缺点就是速度慢，毕竟需要对每个点进行判断和处理。所以这部分也是我们针对MMX优化的主要部分之一。
怎么样?奇怪么?有关内容请详见CBDraw.cpp。
遮挡
我在设计游戏开始时就考虑过单元的遮挡问题，因为这曾经是<官渡>遇到的问题之一。游戏单元在屏幕上的位置会经常有所变动，但我们必须保证一点，即下面的物体总要把上面的物体遮住。但是我发现这个问题实际上在<赤壁>里几乎不存在。因为在每一帧都是重新显示一屏内的所有信息，只要我每次从上向下画图就可以了。当然这是个极为极端的例子。我们仍然需要考虑遮挡的问题。比如，人被山挡住的问题。我们通常为了在显示函数里显得结构化一些，都是先显示地形，再显示人物。那么当人物走到了山的上部时，就需要山峰挡住人，可是这时侯山都已经显示完了，我们必须再次显示山。而显示山的时侯又不能够显示整个的山，我们必须划分出显示的区域，让它可以显示又不会遮挡别的地形。
调整这部分内容可能占据了我制作显示部分的绝大部分的时间。好在最后实现了，但我仍然在想是否有更好的办法解决这个问题。
有关内容请详见CBDraw.cpp。
行军算法
我们在制作<官渡>时没有给士兵以一套完整的行军算法，让它去寻找一条到达目的地最近的路线，而在<赤壁>里想做一下尝试。就自制了这样一套算法。首先找到一条直线，然后围绕挡住这条直线的障碍物搜索一条可以行走的路线。说起来简单，做起来可很困难。这部分代码写了大约有四五个月。
当然它也仍然有缺点，比如如果在路上的障碍物内部有空洞，那么就会卡住。但好在它的速度还算可以，一百个人同时走路时才会感觉到一点停顿。
本来我们打算在<荆州>里有所改变的，我们采用了世界上比较流行的行军算法：A*算法。并且为它专门制作了一套底层，使它可以挂在任何一个地图结构里。
有关内容请详见March_n.cpp。
为什么有数量限制
又回到了老生常谈的话题。编程序的人一看就可以知道，对士兵数量进行限止的唯一理由就是没有使用链表。的确是我胆小的缘故。我没有在游戏的核心数据结构中使用链表，原因很简单，怕出错。我为每个游戏者开了200个单元的空间，也就是说每方游戏者都可以制造200个士兵和建筑。我想这个数量应该是够了，因为如果真的每个游戏者都生产出这么多数量的单元，游戏也跑不动了。
使用数组不仅出错的机会少一些，而且它对于查错也很有帮助。在我们的早期测试版中，我让游戏每隔10轮就自动存一次盘。存盘的内容就是简单的把这些数组内的内容写到文件中。如果程序跳出，马上调出存盘很快就会跟踪出错误的位置。后来，在<赤壁>标准版发行后，也有玩家反映有异常退出的错误，我就让他们把存盘文件寄给我，我就能很快发现问题。如果使用指针链表恐怕就没那么容易了，但也有一个好处。如果玩家玩出一个错误，只要他再重新玩很可能这个错误就不出现了。
有关内容请详见CBCtrl.cpp。
镂空贴图
我估计有不少初学编游戏的人都会有这个疑问，如何让一个人出现在地形上而身上没有黑边。要知道计算机的显示一般都是以矩形为单位的，一个边界不规则的图形该如何显示呢?
假如我们按点去操作，那么就可以判断如果人的图像上是黑色则跳过去，否则显示到背景上。但是谁都知道这样是很慢的。于是我们想到了使用逻辑操作来贴图。我们有一个真人的图像，边界是黑色的，我们叫源码。然后我们制作一个掩码，人的内部是黑色的实心，外部是白色。然后我们做两次逻辑操作，先把人的掩码与背景做“与”操作，这样背景就被扣出了一个黑色的轮廓，然后把人的源码与背景作“或”操作，人就呆在背景里了。
如果你看到我们的地图编辑器，就会发现我们就是这样做的。这是<官渡>的做法，在编写编辑器时我还不会使用DirectDraw呢。但是在DirectDraw环境下，我想大家就可以省事很多了，只要一个ColorKey的变量设置，DirectDraw就可以替你完成镂空贴图的操作。
从这里你也可以看到我们也许不会一开始就把游戏做好，但只要坚持下去，我们一定会越做越好。
有关内容请详见DDApi.cpp。
2.5 希望
有人说即时战略游戏已经过时了，或者已经做到头了。我的观点截然相反。
我认为它是目前唯一能够胜任大规模集团作战的游戏类型，它所能够带给人的东西我们还远远没有做到。我是很喜欢看电影的，尤其是战争电影，那些电影里的场面和效果在游戏里出现了么?有，但是还远远不够。
我承认我们的制作能力与国外的水平还有很大的差距，但是即时战略依然会有它的发展。
比如，即时战略已经开始慢慢向战棋式的战略游戏靠拢，采用多层战略地图，多级控制的方式。这就是一个可能的发展方向。即时战略也可以不采用采矿的方式，而利用其它(比如经营)方式来获得资源，这也是一个可能的发展方向。
我总是觉得，制作游戏就是在创造世界，虽然我们的这个世界还无法与真实的世界相比。但是，只要我们做了，就会有进步，就会离梦想近一点，也许我等不到那一天，可是也许某个看到我的文章的人等得到那一天，这我已经很高兴了。制作游戏的路刚刚开始，对于我们而言，我们希望能够继续做下去，可是上帝毕竟是广大的玩家，如果大家不认可，那我们还是趁早改行为好。但我总是有些不死心，总希望能够有人坚持下来，如果这个人不是我。我真心地希望能有更多的人了解游戏的制作，了解制作游戏的人，也希望有更多的人加入到这个充满了艰辛的事业来。因为美好的明天需要我们去创造，我们为游戏付出了很多，它也会同样地回报我们的。
以上内容仅是我个人的观点，如果有任何异议请与我联系，但是我不会与各位争论什么，因为只有做才是最重要的。如果有什么问题，也可以来信，但是我可能不会很快或很详细地回答，因为我现在正忙于制作新的游戏。
我的E-mail地址是liu-gang@263。net。
假如你已经整装待发，那么就开始吧，不要犹豫，人的一生只有一次，只要去生活就是了。
目录
1 游戏程序理论
1.1 技术基础
1.2 游戏底层
1.3 编写规则
1.4 程序设计
1.5 制作流程
1.6 程序调式
1.7 代码优化
2 游戏实践讨论
2.1 制作概况
2.2 模块划分
2.3 游戏引擎
2.4 关键讨论
2.5 希望
1 游戏程序理论
我做游戏的历史只有三年，我所写的内容都只是我在此期间的感觉和经验，还远远谈不
上完整和正确，甚至有些内容我们自己也没有完全达到，我只是试图说明我们曾经是怎样做
的和在最近的将来打算怎样做。
我读过一些关于如何制作游戏的文章和书籍，有外国的，也有国内的。有的过于难懂
(那些专业技术有的我根本看不懂)，有的过于简单，而且大都着重于程序编写技术。我在
这里希望能够提供其它方面的帮助，比如游戏中的程序设计，项目管理和与我们中国人编
写游戏相关联的一些问题。
我希望能够给那些想编写商业游戏和正在编写商业游戏的人们提供一个样本，这不是
最好的样本，而是在中国内地游戏制作业的初级阶段中一个普通产品的制作方法和经验。
如果是一个初学者，我希望给他一个编写游戏程序的完整印象，让他至少了解编游戏和玩
游戏是有区别的。
我希望阅读本文的人应该是一个程序员，熟练使用C语言和C++语言，曾经编写的单个
程序长度应该在5000行(150k)以上。因为我在这里不会介绍任何有关编程语言的语法，编
译等内容，如果你连这些内容都还没有弄清楚，请先学习一下，否则将很难与本文引起共
鸣。假如你是一位美术设计，游戏策划人员或游戏项目管理人员，虽然你无法看懂里面的
大部分内容，但是我也希望你能够了解里面的有关内容，因为如果你能够了解程序员的工
作，我们就能够更好地配合。
我更希望那些不了解游戏的人们能够看到本文，我希望他们能够了解编写游戏程序与
编写其它程序是一样艰巨和复杂的，制作游戏并不等同于玩游戏。
1.1 技术基础
1.1.1 人员
作一个商业游戏所需要的程序员的水平，可以分成三个级别：系统分析员、主模块程
序员和外围程序员。
·系统分析员：
这里的系统分析员也许比不上程序员资格考试中的系统分析员，因为我们制作的游戏
程序到目前为止都属于中小型程序，长度一般在50000到200000行之间(1.5M到6M)，经过压
缩之后源代码可以轻松放在一张软盘上。工作量一般在20到60人月之间。所以游戏程序的
复杂程度比一些大型应用程序要小。但是，游戏系统分析员的工作也一样是复杂繁重的。
他的主要工作是需求分析，程序设计和进度管理。
在需求分析阶段，主要是根据游戏设计制定的游戏方案确定那些内容是可以实现的，
那些是不能实现的；可以实现的部分如何实现，不能实现的部分该如何修改。最后制定一
个可行的游戏程序制作方案。这个方案最后被系统分析员写在程序设计文档中。当设计定
稿后，制定开发计划，组织人力开发，监督制作成果。
·主模块程序员：
过去我们的系统分析员和主模块程序员由同一人担任，但是到后来，我们发现，因为
程序的管理设计人员也要担任繁重的程序制作任务，很难面面俱到。所以我建议把主模块
程序员独立出来。由他来负责对游戏主要运行部分进行编程。这需要主模块程序员具有非
常丰富的编程经验，至少应该具有完成一个游戏的经验。但是其实每个人都是从不会到会
，从没有经验到经验丰富的，不能满足条件也没有关系，只要程序难度小一些就可以了。
·外围程序员：
游戏的程序一般都会被分割程序若干个模块，如果该模块独立性比较大就可以交给其
他人员完成。这些人只要有一定编程经验就可以胜任了。
1.1.2 编程平台
任何的计算机语言都可以被用来写游戏。游戏可以被运行在任何可能的计算机硬件设备
上。但是，因为我的制作经验的局限，我无法向你们介绍用Cobal语言编写AppleII上运行
的游戏。同样，我也不会教各位如何使用Visual Basic，Pascal或Java，任何形式的DOS程
序也是我不会花时间讲解的。在我后面的讨论中将只涉及在windows95/98下的Visual C++
编程。
现在，编写游戏时不能不提到Microsoft公司的DirectX。它是一套基于Windows95/NT
的游戏底层接口，在我们的游戏中使用了它作为底层接口。关于它的使用想必大家已经很
熟悉了，现在已经有中文的书籍出版，我不必赘述。
有的书上讲在编译和调试程序时最好使用Windows NT或双显示器，尤其因为DirectDraw
中独占显示器。可是我试过之后发现都不实用。对于WindowsNT，它的4.0版只支持DirectX
3.0， 听说5.0版才支持DirectX 6.0，但我总不能等到NT5.0出了之后才开始编吧。对于
双显示器，我一直耿耿于怀，外国人都很阔，每个人可以配备两台机器，可是，就算我找
到两台计算机，程序装入的速度实在让我不耐烦，调试一遍时间太长，等不起。
我们应该重视的倒应该是计算机的兼容性问题。为我们提供测试的计算机是很少的，
如何找到更多的条件才测试我们的程序是后期应该注意的问题，千万不要以为在Windows95
时代计算机硬件的差别已经没有了，它们出起错来更危险。
1.1.3 语言
在任何一本写游戏编程的外文书籍里都会提到编程语言主要有两种，汇编和C。有的书
里甚至不提倡使用C++。不使用C++的原因我猜有两个：第一，速度。据说C++代码比C代码
慢10%。这个数字我没有测试过，但C++比C慢大概应该是对的。因为用C++比直接用C编写
代码要方便和简单，所以速度应该会慢。第二，便于移植，移植这个词可很时髦，什么PC
到PS啦，PS到Saturn啦，Saturn到N64啦，N64到Mac啦，Mac到PC啦之类，一个游戏必须要
在所有地方出现才过瘾。如果使用C++就难了，因为象次世代游戏机上的开发环境，一般不
支持C++，N64虽然说是支持但仍然建议使用C。
使用汇编的理由也是很简单的，那就是快！因为游戏编程中表现最明显的地方就是游
戏的速度。汇编比C快的道理也是很明显的，那就是汇编要比C难写多了，速度自然快些。
那么速度就那么重要么?过去上学的时候，用汇编写出来的程序编译出来的一般十几k
，后来用C写的小程序大的有几十k，而现在编译windows程序，一上来就有一百多k。过去
的游戏就是绿色屏幕上几个字符，而现在都是真彩色的图象和实时三维。过去的游戏一个
人就可以“搞定”，而现在必须分工合作。这些给我的感觉就是游戏越做越大，程序越写
越长。是不是有一些方面开始变得与游戏速度一样甚至更加重要了呢?
有！这其实就是大家经常谈论到的一个问题：程序的Bug。一个程序如果越来越复杂，
越来越长，而且多个人共同编写，这时候就越容易出现程序中的臭虫。我认为，以我们目
前的程序编写水平而言，程序的正确性要远远高于它的效率。实际上，我在后面的主要篇
幅都在讲如何提高程序的正确性上，而只有很少的篇幅介绍程序的优化。
所以我选择编程语言主要是从其正确性和效率两个方面来考虑的。目前我选择C++。
这不仅仅因为我对这个语言最熟悉，更因为它的特点，对两个方面都符合得很好。
程序
是人写出来的，如果程序越容易写，就越容易正确，这方面汇编语言显然不是候选者，
Pascal虽然好，但是那些begin
和End写起来也太累。 C语言要省事得多，C++更进一步，
而且有了封装，继承，多态的概念。可是编写最方便的首选应该是Visual Basic，Delphi
和Java了。程序的框架都已经被准备好，只要在里面填东西就可以了。只是因为它们的效
率比较低，而不能成为游戏编写的最佳语言。
现在很难想象一个游戏整个都是用汇编写的，因为一个10000行的C程序改用汇编写至
少需要50000行，那其中出错的机会至少要多出5倍，而且汇编代码太过抽象，很难读懂。
所以应该只在非常需要效率的地方才需要使用汇编语言。
C语言与C++的差别不大，而且我认为C++所带来的封装的概念足以弥补它们的速度差
异。关于移植，有消息说Sega最新一代的游戏机DreamCast要使用Windows CE作为操作系
统，那么C++应该也会支持的了。大融合的时代总会到来，不同担心。我的C语言代码也主
要用于程序的底层。
那么，现在大家对我所使用的语言应该有所了解了。使用C++作为主要语言，同时辅助
以C和汇编。
1.1.4 编译环境
Microsoft Visual C++2.0/4.0/5.0/6.0是我一直使用的编译器。虽然Borland C++和
Watcom C++也可以编译Windows程序，我仍然认为Visual C++是最好的。没有别的理由，就
是因为习惯了。如果你已经习惯使用Watcom C或Free C什么的，也没必要改。如果从来没
有编过Windows程序，倒是可以先从这里开始。
我听说谁如果不会使用SoftICE调试程序就没有达到编程的顶峰，我一直以此为遗憾。
我不会使用SoftICE。我也远远没有达到编程的顶峰。“竟然这样的人也编起游戏来了”，
也许有的人会这样想，我想这没关系，因为本来谁都可以编游戏的嘛。
1.1.5 背景知识
编程序到底需不需要是专业人才，这也是个大家争论的话题。我还是那个观点，这只
是一个起点的问题，它只表明入门时候的速度而已。但这并不是说你什么都不需要学。有
许多东西需要我们学，甚至需要我们不停地学。
·硬件知识：
你总不能连自己的计算机是什么CPU都不知道吧。虽然我们不需要知道每个芯片的内部
构造，但如果我们知道了Pentium CPU有两条并行流水线同时处理指令的话，我们就会特别
注意这方面的优化了。
·操作系统：
我们的程序不一定需要多任务，多线程，但是了解我们的程序何时被调用是很重要的。
·数学：
数学是我最头痛的科目了。好在我们在这里所接触的大多是离散数学(我也很头痛!)。
最基本的要算是数理逻辑，就是程序中最普通的判断语句中的那些“与”，“或”，“非”
。其次是那些图论，概率。知道这些编写二维游戏就足够了。如果编写三维游戏，那就赶
快复习一下线性代数吧。
·专业课：
这是计算机系中学到的有关课程。虽然数据库，网络的概念在游戏编写中都可能会用
到，但是因为都是间接的，就不在这里说了。数据结构大概是最重要的课程了，这里所提
到的数组，队列，堆栈，链表，表，树，图等概念在我们的程序中几乎都会或多或少地用
到。另外，对于三维编程，还有一门叫计算机图形学，也是很重要的。
·文件：
与游戏密切相关的文件有图象文件，声音文件，视频文件等。这些知识越丰富对我们
编写游戏就越有用。可是，这也并不是绝对的，我在刚开始写游戏时连BMP图的格式都不
知道。
·美术：
大概每个游戏程序员都有过当“助美”(助理美工)的体验吧。当我们做程序测试，或
美术师们没有时间完成裁图，切图等“体力”劳动时，自然由我们来做这些工作。但是，
请记住，程序员永远是程序员，就算我们画得再好，也比不过他们的。
1.2 游戏底层
在我们编写每一个游戏时，都希望能有一部分代码可以重用，这样我们才能有更多的时
间做更多的事情。这些重用的代码就慢慢形成了游戏底层。游戏底层多了，自然就形成了一
些类别。
显示底层：
用于基本显示的函数。把常用的功能制作成函数，统一出错管理。对于Windows95/98下
的游戏编程，我们一般使用DirectX作为大部分底层的底层。因为这部分是我们可以用于编
程的最底层函数。对于二维显示，我们使用的是DirectDraw部分。为什么还需要在DirectDraw
外面再包一层函数呢?原因有三：第一，DirectDraw提供的函数扩充性很强，函数参数较多，
而我们使用时参数比较固定，包裹成类库后，参数更加可以封装起来；第二，DirectDraw
提供的函数比较分散，而有许多操作是需要多个函数按照一定顺序执行的，包装起来后编
写程序比较简单；第三，DirectDraw函数的返回值比较复杂，而且没有对错误进行系统的
处理，我们需要自己制作一套错误处理函数，对错误代码进行解释。
显示底层有许多种做法，可以完全自己开发，也可以直接使用别人完成的函数库，比
如Internet上比较流行的CDX类库就是对DirectDraw进行了很好封装的底层。
显示底层主要分成下面几个部分：
窗口处理：窗口的创建、管理、删除。
图形接口处理：图形设备的初始化、退出、显示模式的设定、主显示面、后缓
冲区的建立。
二维图形处理：游戏使用的二维图象的装入、显示、剪裁、逻辑操作。
外围工具：游戏使用的鼠标，刷新率计算和显示，显示内存斟测，面丢失
(Surface Lost)处理(在DirectX 6.0后据说可以不用)，错误处理，调试函数。
关于显示底层还有两个问题需要说明：
第一，显示部分的调试。因为我们所做的游戏一般为独占模式，在游戏运行时不能
跟踪(除非使用双显示器)，所以我们只能另想办法，一个比较常用的办法是使用窗口模式
和全屏模式切换。不一定在游戏运行中随时切换显示，在调试时事先指定也可以实现该功
能。
第二，多媒体播放底层：
播放多种声音，音乐，视频等多媒体效果。比较古老的一种办法是使用Windows 3.1
就开始使用的MCI调用。它是一种通用接口，使用不同的参数调用同一个函数就可以实现
基本相同的功能。用MCI可以实现的主要媒体类型有MIDI，WAVE，CDAUDIO，和VIDEO。它
的优点是使用简单。缺点则是缺乏交互性，而且同种类型的媒体不能同时播放。这样就很
难实现多种音效的混合。
一个基于DirectX的调用是使用DirectSound。它是基于WAVE文件的一套播放函数。非
常适合混音。缺点就是使用较复杂，而且如果想实现分段读取较长的WAVE文件，编程有些难度。
另外一个针对MIDI的DirectX是DirectMusic。它是DirectX系列中的一个新成员。
对于播放高质量的VIDEO(视频)文件，则有另外一套底层。比如Microsoft的ActiveMovie
和Intel的Indeo Video。有了它们我们就可以放心地全屏播放AVI文件了。
对于这些底层，我们所做的只是简单地封装上一层函数，使我们在使用该功能时达到最简便。
但是假如你对这些现成的播放程序不满意，也可以完全自己开发。只要你知道这些文件的格式，
再把它们存储成你需要的格式，用自己更加优化的算法将它显示出来就可以了。用这种方式你可以
自己播放AVI VIDEO， MPEG， MPEG2或FLI/FLC。
文件封装底层：
对使用的文本，图象等数据进行封装。我们也常用这种方式把多媒体文件封装起来，防止别人
事先查看。这种工作往往是循序渐进的，我们会根据自己的时间和实力，封装相应的部分。比如先
封装比较简单的文本，图象。然后是较为复杂的声音文件，最后是最复杂的视频和动画文件。
有的时候封装也是为了压缩。不仅再安装时少占用硬盘，装入时也可以节省时间，有时在运行
时也会减少内存占用而不会对速度有太大的影响。
根据文件类型的不同，我们可以这样分类：文本、图象、声音、视频、动画等。对于每种类型，
我们还必须有打包函数和解包函数之分。
界面底层：
自己编制的类Windows风格的界面类库。我总有这样的习惯，希望在我的游戏里没有一点Windows
的风格，于是我不会使用任何一点的有Windows风格的界面(游戏工具除外)。所以游戏的界面必须我们
自己做。然而我又使用过MFC那一套界面类库函数，很佩服Microsoft的本事。也希望我们的游戏中有
一套自己的界面系统。这套系统将会包含Windows用到的主要界面元素：位图(Bitmap)、按钮(Button)、
检查框(Checkbox)、滚动条(Scrollbar)、滑块(Slider)等等。
虽然Windows允许我们在使用标准界面时自己画图，但是因为它只支持256色，是基于消息响应机制
的显示，而且无法支持位图的封装，所以我们使用一套完全由自己制作的界面底层。这套底层建立在显
示底层和文件封装底层之上，形成了一套比较完整的系统。
上面这些只是一般游戏所需要的底层，对于某些特殊类型的游戏，可能还会有战略游戏的显示，操
作底层，RPG游戏的事件处理底层，战棋游戏的显示，智能底层，动作游戏的场景底层等。如果编写三维
程序，则还会有三维显示和操作底层。这些底层都不需要也不可能在一开始就全部完成，而必然是在不
断的修改和检验中完善的。它们也不可能一成不变，必然随着我们编程经验的积累和开发环境的改变而
改变和完善。
每个编写游戏的程序员都会慢慢积累出符合自己游戏特点的底层函数库，这些函数库如果得到不断的
发展和扩展将会越来越大，越来越好，这对于每个游戏制作公司和集体来讲都是一笔不可忽视的财富。
而这套函数库越来越复杂，再加上辅助的一整套工具，就可以被称之为游戏的引擎。有了引擎在手之后，
不仅意味着我们有了一套低Bug的现成代码，程序员的工作量将会大幅度下降，而且他们可以把更多的精力放
在游戏的优化、游戏的人工智能、游戏的操作、以及游戏性上面了。到了这个层次，我才可以想象一个好的
游戏将会是什么样子。
1.3 编写规则
现在，只需要一个程序员编写的程序已经很少了，大部分的程序都需要多个程序员的协作才能完成。这期
间必然需要程序员之间互相阅读代码。而代码的编写规则就是非常重要的环节。一段代码如果写的浅显易懂，
不但在程序交流时非常方便，而且对于寻找程序错误也时很有帮助的。程序员也是人，是人就会犯错误，不管
他多么地不愿意犯这个错误。所以我们也希望能制定下一个规则，使他们在一开始想犯错误也不行。于是就出
现了程序的编写规则。
如果不按照这些规则编写代码编译程序是不会报出错误的。但是如果按照规则编写，则对我们的思路的整理、
笔误的减少、错误的查找和代码的阅读都是极有好处的。
下面我只把规则中几个重要的部分加以简单的描述，在后面附录中会有一份我们已经使用了一段时间的完整规则。
命名规则：
程序中对变量和函数的命名看似简单，可是名字起得好与不好有很大的不同。对于变量我们一般采用匈牙利命名
法和微软命名法的结合。对于函数我们一般要把模块名写在函数名的开始。对于类库我们一般要求类的成员和成员函
数要紧密对应。
变量使用：
对于程序中所使用的所有变量，我们都需要其有明显的定义域。对于全局的变量要尽量封装。对
于类库，所有成员必须封装。
函数使用：
我们对函数的参数和返回值做了要求。对于函数的使用范围也做了规定，要求范围越小越好。
注释：
对于程序注释，我们虽然不需要很多，但是在函数声明、变量声明、主要算法部分、源程序文件的开始都需要有注释。
调试：
我们的底层和Visual C++都提供了一些供调试用的代码，在我们的代码中需要适时地使用这些代码，以提高程序的纠错机会。
这里有几个问题需要特别说明：
第一，关于链表的使用。
我在编程中所遇到的所有死机错误中，有90%来自于指针，9%来自于字符串(其实也是指针的一种)，1%来自死循环。而链表
这种把指针的优势发挥到极限的方式我是不提倡使用的。有人讲如果不会使用链表就不是C程序员，那么现在我连个合格的程序
员的资格都够不上了。的确，对许多人来讲，编写没有Bug的链表是很容易的事情，甚至对某些人而言，一个没有链表存在的程序
几乎不能称得上是商业程序。我承认有许多天才的程序员在自己的链表程序中表现得十分出色，他的程序效率既高又没有Bug，
但是我也知道还有更多的程序员并不是天才。就算是天才的程序员如果在他的十万行代码中有五万行于某些链表有关，这其中
的某个指针出了一个错误，而这个错误又不是每运行一次都出现的时候，他又有多大的把握很迅速地找到这个错误呢?链表的复
杂性在于它的地址的随机性，这使我们在调试跟踪时非常困难，我们很难随时观察每一个节点的信息，尤其当节点多的时候。所
以我把链表的使用完全限制在算法的需要和该代码被某个独立模块完全封装的情况下。
实际上我在设计程序时，要求尽量减少指针在主要模块之间的传递，而使用效率较低但是不易出错的句柄ID的方式。
第二，关于类库的成员。
既然我们使用了类库，其中一个主要目的就是要把其中的成员完全封装起来。首先把它设置为私有，然后定义标准的一
套Set和Get函数。这虽然使我们在写代码时比较烦琐，但是只有这样我们才可以严格规定该成员的只读属性和可写属性，
减少对某些重要变量的无意修改。
第三，关于变量和操作符之间的间隔
许多人对于变量和操作符之间的距离并不在意，认为多个空格少个空格只是看起来好不好看而已。而实际上，这对我们是
很重要的。因为如果我们把间隔固定下来，在查找某项操作时就可以使用带空格的字符串，
而大大增加找到的机会。
1.4 程序设计
我们在编写自己第一个游戏时，往往是凭借自己的兴趣，想到哪就编到哪，有时连自己都没想到
会编出这么大的程序来。那时侯我们对代码的修改往往是很随意和彻底的，因为本来都是自己的东西，
而且更希望它更好。可是，程序越写越大，有一个问题就会越来越明显，那就是程序的错误。为了减少
错误的产生，我们必须采取一些办法，所以也就产生了程序设计。程序设计的必要性还表现在另一个方面，
那就是程序员间的合作。为了让每个程序员对我们所要做的事和我们将如何做这件事有个明确的了解，
也为了让管理人员能够从量的角度了解任务的完成状况和进度，我们也必须有程序设计。否则我们就只能
象一群乌合之众一般，鬼才知道这游戏要做到什么时侯。
一般，我个人认为，当一个程序需要写到10000行以上时就应该有比较独立的程序设计文档了。可是
程序设计文档应该是什么样子呢?很抱歉，我也一直在寻找这个问题的答案。在我刚开始做游戏的时侯，
没有人教，于是我翻出上学用的课本，打算来个生搬硬套，写来写去，发现，不行。这样的写法太累了。
比如在软件工程课上所讲的数据流图，我好不容易写满了一张八开的纸，马上就发现自己已经糊涂了。就
算不马上糊涂，过一段时间我也会认不出那些条条框框是什么了。就算我能记得这些图表的意义，我能够
保证所写的代码和图表上的一样么?我写完后，还需要和这些表对一下。就算程序和文档中的内容一样，
那如果我的设计方案改了呢?又需要先改文档，再改程序，再对程序。这样对我来讲可太累了。
后来，我才发现，原来书上所写确实有道理，可是它并不是面向我们这些人的，它所面向的是写大型
程序的人。这些程序大到需要专门有这样的人来写文档。这些人只要把文档写好再确认完成的程序是否符
合要求就可以了，根本不用去写一句的代码。是啊，如果编游戏也有这样的工作就好了。可是很遗憾，目
前我尚未遇到可以聘有专职程序设计人员的公司。所以程序设计者就是程序编写者的这个事实起码在我们
的目前阶段是很难避免的了。
那么怎么设计文档对我们用处又大又比较节省时间呢?每个公司和每位程序设计人员的习惯都不一样，
我只介绍一下我们曾经使用过的一些方法和文档的类型。
程序设计总纲：
无论我们做什么，最先要清楚的一个问题就是：我们做什么?很弱智是不是?但是我发现有些人在很多时
侯都“不知道”自己在做什么。程序设计总纲就是要告诉自己和自己的伙伴们，我们要做的是什么样的游戏
程序。它包括：
游戏概述：游戏的背景、类型、操作方法、特点等；
程序概述：游戏程序的编译平台、硬件运行需求、语言、编程重点和难点、技术能力分析等；
程序员概述：参与编程的人的能力和在整个程序制做中的作用和地位；
程序模块划分概述：有本游戏所需要的所有程序，和程序内部的功能模块的划分。这部分只要有比较概
括的说明就可以了。
这篇文档的作用就是让所有人都能够了解本游戏的程序将会是什么样子，它的特点是什么，完成它的难
点又是什么。以及我们为什么要这样做，有谁来做等这样基本的问题。它所面向的对象除了有自己和本组内
的所有程序员以外，还应该有本游戏的游戏策划，美术设计、项目负责人、项目经理、制片人等。如果有可
能也应该和本公司的市场、销售、广告公关、出版、甚至公司总经理充分接触，听取各个方面的意见，也充
分表达自己的意见。如果能做到制做本游戏项目的所有人员从上到下对本游戏的程序制做都能有一个基本的
了解，理解和信心那是最好的。
程序模块划分：
这是对程序设计总纲中最后一个部分的详细说明。说明的内容主要有：该模块的功能、接口、技术要点、
所用到的软件底层等。它所面向的对象一般是所有的程序员，但是如果让与程序合作的人员(美术、策划、经理)
也能了解则更好，这样可以加强我们之间的勾通，让不懂编程的人也能了解编程人员的苦衷。
一般而言，一个游戏按功能划分(我们很少用其它的分类方法)可以有下面几个部分：
工具部分：在游戏的制做过程之中，从游戏策划的文档，游戏美工的图片到游戏完成，中间必须经过游戏程序
的转换和加工。这些数据在进入程序之前必须经过规整，排序等操作。这部分工作过去一般都是由程序员来做的。
在人手紧张和工作量比较小的时侯这样做还是可行的。但是如果这样的工作过于复杂，工作量太大，就不行了，我
们需要一种方法来提高工作效率。这种方法就是工具。其实我们在计算机所做的任何工作都是在使用工具，唯一的
区别只是这些工具都不是我们自己做的。因为游戏本身的特殊性，我们不可能总能找到我们所需要的工具，自己制
做就是十分必要的工作。
这些工具也可以分成三个级别：别人的工具，我们自己的可以重用的工具，我们自己的只在本游戏使用的工具。
别人的工具是最好的工具。原因很简单，因为它不用我们再去编了，不仅程序Bug较少，操作界面友好和简单，
而且开发时间是零。所以如果可能一定要使用别人做好的工具。如果实在没有满足要求的工具，或者我们还需要该
工具所没有的功能，我们只能自己编。那么如果这个工具可以被以后用到也不错。所以我们在编写任何工具的时侯，
其通用性是我们考虑的首要因素。
工具与游戏其它部分的程序有一个最大的区别，那就是工具程序是独立的可执行文件，它与游戏的唯一交互方式
就是存在磁盘上的文件。所以它比较适合交给其他的程序员制做。另外一个特点就是它一般都是针对非程序员的，所
以如果工具做好了，也可以很大程度上帮助他们提高工作效率。
底层部分：这部分程序代码的最大特点是可重用性。它是游戏本身与计算机通用系统之间的桥梁，它与游戏的具体
细节关系并不大，可以被使用到多种游戏类型和多个游戏之上。这对我们是非常重要的。实际上，我们编写程序所积累
的最直接的财富就是可重用的工具和游戏底层。
游戏底层从与游戏的相关性可以有大概三个层次：
最底层：它们向下直接调用系统函数和功能，向上与游戏几乎完全无关，是游戏程序与计算机系统的直接桥梁。它包括：
·显示底层：提供游戏显示所需要的所有函数；
·文件底层：提供对游戏所需的各种文件处理的接口；
·多媒体底层：提供游戏所需的多媒体效果，如声音，视频等；
·对于三维游戏有模型管理底层：专门保存，处理和显示三维数据；
中间层：它们向下调用最底层的游戏底层，向上为游戏提供函数。与游戏无关。它可能：
·界面底层：使用显示和文件底层，提供界面类库和操作函数；
最高层：它们向下调用中间层和最底层，向上为某种类型的游戏提供特殊的逻辑支持。它可能有：
·战略游戏的命令执行底层，显示底层，地图底层。
·RPG游戏的事件处理底层，场景底层。
这三个层次的制做难度是越来越难的。它往往需要我们在制作过几个游戏之后提炼和总结出来(实际上我们到现在也还没有发展出第
三个层次的底层)。但同时，这三个层次是越来越重要的，因为它距离一个成品游戏更进一步。我们在写游戏时可重用的部分越多，重用
的层次越高，我们的工作量就越少。我们也就越可能有时间研究和开发新的技术，好的算法，我们的游戏也就会越做越精。
相比之下，前面的两个底层都与计算机系统有关，与游戏本身无关；第三个底层与计算机系统无关，与某种类型的游戏有关。
底层部分与工具部分也是密切相关的。一般每一套底层都需要一些工具来与之对应。比如，我的显示底层需要某种格式的图片，我们
就要制做一个格式转换和图片观察的工具。把工具和底层结合起来分类，然后把它较给独立的程序员去完成，是一种比较常见的模块划分方法。
当然，我们在做游戏以前也不一定非要什么工具和底层不可，这些东西完全都可以“自然”产生。假如你能够坚持制做几个游戏，把可
以反复使用的程序归纳起来，修改一下，就是一套底层了。如果我们在编写程序时，每时每刻都在想：这段代码是否可以在以后使用，怎样
的写法可以使我在以后使用，那么我们在后来的修改工作中就会轻松很多。而假如我们在编写程序以前多花一些时间，把想要做的东西设计
清楚，在一开始就可以把它写成独立的底层代码。这样积少成多，我们的财富就会越来越丰富。
游戏本身：这才是我们每次都要做的游戏。所有体现游戏特色的内容全在这里。当然也有的人认为如果我们的经验足够丰富，想得足够全
面，连这部分的程序也可以重用起来。以后我们编游戏只要改一下图片，换几个名字，编一段故事，一个新游戏就产生了。实事上，也有公司
制做了一些类似游戏工具的东西，其中做得最好的应该是象Director， Autherware那样的多媒体编辑工具吧。但是，它们都有其局限。最明
显的一点就是：它们必须针对某一个类型的游戏或只能是多媒体程序，不同类型游戏的制做是有很大区别的，几乎很难用一个固定的模式将其
完全函盖。其次，它们创新困难，现在游戏几乎成了创新的代名词，哪一个游戏做出来没有它自己的特点呢?而使用一个固定的工具是很难做到
这一点的。第三，难以对它们进行优化。程序的优化往往和程序本身的特点有关，优化的程度越高，它的特殊性也会越大，所以，通用工具只
能牺牲一些性能。我到目前还没有看到一个游戏制做工具可以达到商业效果，而多媒体工具之所以流行正因为制作多媒体产品所需的模式比较
单一，对速度要求也不高。
所以，制作一个完全可以通用的游戏工具到目前仍然还只是一个梦想。但是，我想这是一个很美的梦，如果真的到那个时侯，我们制做游
戏将会和拍电影一样简单(我指的只是制做的过程)，只需要一个程序员根据策划的意思把图片和声音放在一起就可以了。
每个游戏都是不一样的，但它们都有一些相似的地方，比如：
游戏的操作：游戏者如何操作和控制游戏中的一个或多个主角；
游戏的显示：不是游戏的底层，而是与具体游戏有关的显示部分；
游戏的运动：游戏中有的内容是要不断变化的，包括位置变化，图片变化和形式变化；
游戏的智能；能够与人对抗的思考；
游戏的存储；把所有当前游戏需要的数据保存在磁盘上，然后再重新装入游戏；
游戏状态的转换：从界面到游戏，从游戏到动画，在不同的时侯有不同的操作和显示管理。
我们通常也会按照这样的规律对游戏进行模块划分。
游戏数据结构和算法：
有人讲程序就等于数据结构加算法。这句话很有道理。我们所编的程序其实就是把某种格式的数据(图片，主角的参数)经过一系列的转换，成为计算机屏幕上的数据(游戏本身)。所有的数据都需要以某种方式存储，这就是数据结构。而算法因为是与数据结构密切相关的，所以虽然它们不属于同一个概念，我把它们放在一起设计。
我们通常所使用的数据一般可以分成两个部分：数据库结构和当前结构。
这里的数据库不是什么商业数据库软件，而是游戏中所使用到的所有数据的集合。我还没有见到有哪个游戏在存储这些数据时使用商业数据库软件(比如FoxBase)。也许它们都被隐藏起来了吧，我猜想。但不管怎样，其意义是一样的，我们需要把所有在游戏中用到的数据都以一定的形式储存起来。同商业数据库一样，数据库的组成也是由字段组成，即数据元素。每个数据元素一般是一个类库或结构，有若干的成员。数据元素所组成的数组就是数据库结构中最主要的组成部分。
数据库的内容很多，而且按照一定的规则排列，而真正需要显示和当前需要计算的数据却很少，有些数据还是计算的中间结果，比如主角的位置，主角的动作等，这时侯就需要我们另外存储一些数据。它往往是数据库中的某个字段(数据元素)，或一些数据的组合。
如果把数据结构按照功能分类，我们还可以把它分成主数据结构，模块数据结构。它们的定义域是不一样的。
在我们的游戏中，会有许多数据结构的类库，它们之间也必然有数据结构之间的数据传递和保存。如何处理好这些数据之间的关系是编写这部分内容最重要的考虑。
首先是数据结构定义域的问题。在无数的教学课本上都在不断提醒大家，要尽量避免使用全局量。为什么要这样做呢?第一个原因显然是因为这样做的人太多了，我们使用全局量直接，方便，快捷，有什么理由不用呢?而答案也很简单，因为它暗含了错误，因为它不易于阅读和修改。于是我们用两个规则来限止全局量的使用：第一，尽量使用局部全局量，使该全局量的定义域最小，比如基于源程序文件的全局量，只有整个游戏的核心结构是全局范围内有效。第二，对于所有的全局量都对其内容进行全面的封装，如果是类库则使用成员函数，如果是结构，则定义专门的函数对其内容进行处理。
其次是数据的传递。我们经常遇到数据结构之间的互相调用和嵌套，很多人都喜欢使用指针(又是指针)做这项工作，因为它象全局量一样：直接、方便、快捷。但是我因为个人水平的问题在使用指针时总遇到一些不便，比如，易于出错，而且一旦出错就是很严重的当机，程序非法退出。要知道现在每启动一次计算机仍然是很耗费时间的。还有另外一个问题，那就是指针不能存盘，我必须另外制作一套程序对结构的存盘做特殊处理。所以我一般使用索引ID号来代替指针。具体的使用是这样的：数据库结构是以数据元素为单位的数组，数据元素的索引(ID)就是它在数据库数组中的下标。所有其它结构对该数据元素的保存都只保存了该元素的ID号。指针只在从数据库根据索引得到元素时使用。这样的好处很明显，ID号是整型数据，可以通过该值的范围判断出是否有效，只要在其有效范围内，再通过指针取值肯定是有效的，几乎跟本不会出现非法指针的现象。
程序开发计划
有了要做什么和怎么做，下面也就是需要什么时侯做和由谁来做了。
一般我们都会制定一系列的里程碑。比如演示版，原型版(体验版)，测试版和正式版等。在这之间也可能会有其它什么版本。然后制定完成每一个版本所需要的时间，主要内容和验收标准。除此之外，我们还有：
程序中每个模块的制作时间的表格，
每个程序员分工的说明，工作量说明。
编程过程中可能出现的风险和问题的说明。
在写完总计划以后，我们还会有更加详细的月计划，阶段性计划，我们还会写程序进度表。我们所做的一切都是为了游戏程序可以按时完成。
影响开发时间的主要因素有很多：
·资金因素：这些钱至少应该支持到我们可以把游戏做完，而且能够把我们的游戏向市场推出；
·市场因素：是否是销售旺季，是否有同类产品产生竞争，本类型，题材的游戏是否还受欢迎；
·策划因素：游戏的复杂性有多大，内容有多少，策划的进度是怎样的；
·美术因素：美术的制作进度是怎样的，何时可以提供需要的内容；
·技术因素：用户的计算机硬件是否已经准备好。我们的技术是否会过时，开发新技术的风险会有多大。还需要制作哪些外围工具；
·人员因素：程序员水平如何，配合状况如何。
程序设计人员需要仔细考虑这些因素，才能根据具体情况制定比较完善的程序制作计划。
但是，很不幸，我从没有按时完成一个游戏，所以我目前尚不知道妨碍我们按时完成进度的到底是计划不够好还是执行的人不够努力。总之，在做计划时一定要留有余地，而且我的经验是我们完成游戏的时间一般比计划的要多20%到30%。可是如果按照这样的计划去做游戏的话，一定会把投资人吓跑的。于是在现实生活中这种状况就变成了“先斩后奏”，写报告的时侯说时间很短，而到时侯我们就因为某些原因不得不拖期，反正钱也花了这么多了，必须再增加投资而把它做完。所以无论是直接制作游戏的人或者投资制作游戏的人，我都希望他们可以对这件事有个比较客观的了解。也许在将来制作游戏可以不必再加班，制作计划也可以按时完成，但是至少在我们这里，还必须随时面对它们，依靠我们顽强的毅力和坚忍不拔的精神把游戏做出来。
1.5 制作流程
等到游戏计划写完，并得到通过之后，我们便开始进入游戏制作的时间。其实游戏的制作可能从很早就开始了，比如早期的技术探讨和准备。而我在这里想再说得稍微远一些，远离现在的题目：程序，而转向整个游戏的制作。
整个游戏的制作过程一般可以分成三个阶段。策划阶段，制作阶段和调试阶段。它们之间的关系一般应该是在策划阶段后期，开始程序和美术的制作，在制作后期开始游戏的调试。它们三者的时间比应该是3：4：3。我认为这是一个理想状态，但是我们往往达不到理想状态，典型的情况是游戏策划迟迟不能定稿，我们不得不在一边设计游戏时一边制作，而到了后期，制作又很难按时完成，必然压缩调试时间，最后只好仓促地发售游戏。它们三者的时间变成了4：6：0。我所说的这种状态当然只是一个极端，但是我想在我们目前所开发的游戏中或多或少都有这方面的问题。
造成这个问题的原因也有很多：
·游戏立项不规范：人们不知道为什么要做这个游戏；
·策划设计工作准备不足：人们不清楚该做什么、什么时侯做、谁来做；
·制作人员水平有限，缺乏经验：自己做不好，或做不快，甚至都不知道该怎么做；
·资金：没有钱谁会做呢?
·项目缺乏管理：各部门缺乏协调，大家群龙无首，缺乏沟通，最后大大降低士气和工作热情。
但是无论这些因素都是些什么，以及它将如何严重地影响我们，我都觉得只要有一样东西就足以支持我们把这个游戏做完。这就是我们的坚持不懈的努力。现在，我们在市场上的游戏质量都不算很好，但是我要说，只要它被做出来了，就是一个成功的作品。我不管游戏玩家们对我这句话有何看法，我只是认为，在那些作品的背后一定有一个或一些人在努力着。也只有他们才能真正体会制作游戏的艰辛。而且，只要他们还能继续做下去，经验会逐渐增加，配合会更加默契，游戏也一定会越做越好。
游戏程序的制作过程与游戏的模块划分有关，大概可以分成三个阶段：工具制作阶段，底层制作阶段，游戏制作阶段。
底层制作可能是最开始进行的阶段，有可能与策划阶段同时，甚至更早。因为这个部分与具体游戏无关，而可能只与游戏所要运行的平台和我们所使用的开发工具有关。我认为，开始的时间应该越早越好。游戏程序员在技术上的准备如果越充分，制作起游戏来就会越顺利。
在策划大纲基本上完成后，也就是游戏的类型，模式基本上固定之后，就可以开始游戏工具的制作了。游戏工具一般是提供给美术人员，策划人员使用的(当然也有自己使用的)，所以在用户界面上应该多多听取他们的意见。这些天天与我们在一起的用户，如果我们都不能好好对待，那就更别提我们游戏的用户了。
游戏本身程序的制作是最耗费时间和精力的地方，如果说底层程序和工具都可以把重点放在结构化和优化上，这部分程序正好相反，我们通常做不到这些。因为我们在写这部分程序的时侯，总是已经精疲力尽了，而且我们的代码已经很长很长，一旦发现了程序错误，能找到就很不错了，更别提把它改得漂亮一点。再加上游戏策划随时提出的一点小改动，就可能要改变我们整体的数据结构，做大的改动几乎是不可能的。所以到了游戏制作后期，把程序员叫作铁匠更合适一些，他们在到处打补丁(注意，千万别在写游戏底层的时侯也干这种事)。
在游戏制作的中后期，每当程序员一睁开眼，进入眼帘的就是满是Bug和缺乏功能的游戏，这样的一个程序如何才能变成游戏中真正需要得程序呢?无论当初程序计划制定得多么好，在这时候都显得有些不中用。但这并不说明计划没用，而是需要我们把计划变成我们真正需要的东西，这就是每日工作计划。名字听起来很正式，其实并没有什么特殊的格式，仅仅是把我还没有做出来的游戏的内容一条条地写出来，不必区分什么模块和内容的多少，只要手写而且自己看得懂，然后贴在机箱上，要保证随时看到。这些内容我可能在一个星期后也没做，但是它会时时提醒我还有什么没有做。随着时间的推移，有些项目已经完成了，又会有新的内容写进来，而等到你最后积累出一大叠这种计划单时，你会发现原来游戏已经做完了。
这种办法我一直在使用，有时侯真觉得自己没有长进，做事一点计划也没有，可是它就是这么有效，你不必有什么经验，也不必整天面对着程序发呆，每天只要考虑如何把下面的内容做好就可以了。
不过我还是希望以后的程序员不必这样写程序，如果所有的人都能够每天按照预先制定好计划完成工作，也不需要加班，最终做出的游戏又很不错就好了。希望这不是永远的梦想。
1.6 程序调式
我在前面曾经说过，我不会使用SoftICE来调试程序。这证明我并不是一个很聪明的程序员。这也证明我在调试程序时会遇到更多的困难。让我每天在汇编代码和死机中漫游是件很痛苦的事，所以我总在想如何才能摆脱它们。
如果我不能很快地找到这些难缠的Bug，我能否在一开始就避免它们呢，甚至减少它们出现的机会呢?答案是肯定的。
死机(在Windows系统中有时是“非法指令”错)错误很主要的来源来自指针，但这并不是说我们就不能使用指针。恰恰相反，我们在很多地方都使用指针，而且出错的机会很少。原因很简单，那是因为我们在使用被保护的指针。如果你能证明你所使用的指针永远都指在合法的位置上，它还会出错么?所以我们在分配空间时大多使用静态空间和连续空间。所谓静态空间就是数组，连续空间就是指针数组。我们通过数组的下标来限制指针的读取，这样非常方便也有效。
封装也是减少错误的很好办法。我们把对内存的分配和释放封装起来，把对全局量的读取封装起来。在查找问题时就可以很快地缩小可疑对象。
对函数的返回值和错误代码的认真对待也可以让我们飞快地找到问题所在。很多人刚开始编程时都认为程序很短小，没必要写那么复杂的错误处理信息，也没必要判定函数的返回值。而我则恰恰相反，无论对待多么简单的程序我都会做非常详尽的错误处理。我甚至把显示错误的对话框写在底层程序中，以供随时调用。假如出现了错误，我就可以迅速知道错误发生的位置以及发生错误的大概原因，我的程序还可以正常地退出，不是继续执行而造成死机。
使用调试信息可以帮助我在Debug版中获得更多的有用信息。比较常用的有Assert()和OutputDebugString()。在错误刚刚发生时就拦截它要比它造成了更严重的影响后要好。
代码写得好看一些也有助于查错。假如你在一行中写进好几句代码，你将如何逐行跟踪呢?我们如果把函数，成员函数写得规范对称，虽然麻烦一些，但别人在使用时就会轻松多了。
这些办法都是在我们编写代码时需要注意的内容，我想如果你在准备开始编程时就对此有所准备，那么到你编程结束时应该能够节省不少调试错误的时间。但是Bug是一定会有的，无论你在当初如何注意，因为我们毕竟是人，会犯错误。我想任何人都有过把恒等号(双等于号)写成赋值号(单等于号)的经历吧(好在在Visual C++ 6.0中有这方面的警告了)。没有别的办法，我们仍然需要面对死机。一般的指针错误只会导致“非法指令”或“未知的意外”错误，除非你向一个不知名的地方写了大量的内容(比如几百K以上)，一般还是可以安全地退到系统中的。这得非常感谢微软，Windows95/98还是要比DOS好。可是如果你所访问的是系统区域，或申请了与硬件有关的调用，比如在DirectDraw的GetDC()中设置了断点，程序就会直接退回系统或干脆死机。
这个时侯就全凭我们自己了。但是也不要害怕，因为，我们所面对的仅仅是一些代码而已，我们有一个最为严格和伟大的力量：逻辑。这可能是程序员唯一能够全心全意依靠的力量了。所以请大胆地使用它。
如果程序出错，一定有它的道理。哪怕运行一千次只出现一次也是如此。所以我们改正错误的过程实际上也就是找到错误的过程。如何找到错误呢?可以试着用下面的方法：
屏蔽法：把一些代码去掉，再看错误是否消失了，如果已经消失，那么错误可能在刚才屏蔽掉的代码中，再屏蔽掉另外的代码，如果错误又出现了，则错误肯定在这段代码中。要注意的是，这样做不一定能够找到错误，因为，有时侯错误是由两段代码或多段代码相互影响造成的。而且有的时侯我们找到的地方可能并不是真正出错的地方，你只找到了错误被引发的地方，而引发错误的地方还需要我们再仔细找。比如，一个指针指错了地方，那么我们会发现出错的地方是引用指针的地方而不是写入指针的地方。这时侯就体现出封装变量的用处来了，我们可以很快查出这个指针到底在哪被修改了。
如果上面的方法不能奏效，而且错误是在我们刚刚修改了代码造成的，那么可以使用比较法，找到原来版本的文件进行比较。所以我们需要经常保存备份程序，一方面是为了保证程序不丢失，另一方面也会增加找到错误的机会。尤其是当我们到了编程的后期，我们的程序大都编完，正处于修改的状态，而时间又特别紧迫。如果一旦出现了错误，我们只要比较一下新旧版本，就很容易找到错误。
如果你跟踪了半天也没有结果，几网下去一条鱼也没捞上来，而且必须在全屏状态运行，不能单步跟踪，每执行一遍程序就死机，又需要重新启动，这又该怎么办呢?那也不要担心，我们还有最后一招：输出Log文件。在每一个需要监视的地方，增加一段程序，向磁盘文件输出一段文字，如果程序运行到这里，该文件就会多出一段文字，如果程序运行到这里之前就死机或退出了，那么出错的地方就在这段文字和上段文字之间。虽然这样做比较耗费时间和精力，但是基本上能够找到出错的地方。找到之后，我们再去找出错的原因吧。
但是万一你现在还是没有找到错误该怎么办呢?那也不要着急，我所遇到的找到错误的最长时间是整整一天，有的人会长达3天，但是我目前尚未遇到查找单个错误的时间超过一个星期的。如果你寻找错误的时间还没有达到这个长度，就不要急于认为这个错误你是永远找不到的。
其实最难找的错误并不是这些错误，因为这些错误是确实存在的，所以我们改正它只是时间问题。而比较难以调试的错误并不是每次运行都出现的，有的错误需要特定的环境和条件，比如只在某台计算机上出现，有的错误则需要特定的操作，比如打开某文件，再关上，有的错误则干脆需要运行一定的时间才可能出现，比如运行一个小时。这时侯我们的工作才真正艰巨起来。
这时侯，也往往是开发的最后关头，最紧张的时侯，如果出现了错误，将使我们直接面临一个最严峻的问题，到底是发行时间重要还是修改程序错误重要。我姑且不谈到底谁重要。关键是如何解决这些错误。这里你可以看到，把错误消灭于未然是多么重要。我们工作的重点现在转向了重现错误。使用出错的计算机，频繁重复执行某些有关的操作，随时存盘以保存最近时的信息，都是我们常用的办法。
有的时侯重新启动一次计算机，重新编译所有代码，更换一些驱动程序，都可以解决问题。但是有些问题我必须说明：
第一，要以负责任的态度来解决问题。如果你发现有一个地方很明显不会造成错误，但是修改一下之后错误确实消失了，这时侯千万要小心，因为这个错误可能这样被你又隐藏起来了，在以后的某个时侯(可能是最后的调试期)再次出现，这时侯它将会更加隐蔽。
第二，不要动不动就认为是编译器，驱动程序，操作系统或计算机硬件有问题，而不下功夫去寻找错误。这些东西确实会有问题，但它们出错的机会比起我们自己要小得多，我觉得初级程序员还很难发现它们的错误。有问题还是先从自己那里着手吧。
1.7 代码优化
我对代码优化的研究并不深，归根结底是因为我并不是个很聪明的程序员。我曾经见到过一本非常好的书，名叫<图形程序开发人员指南>，英文名是Michael Abrash's 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 中的有关指令吧。
在优化时要注意的问题有：
第一，不要本末倒置。先优化大的内容再优化小的部分。这样我们才总能找到最耗费时间的地方而优化它；
第二，要经常比较。需要对每一种可能的方法进行比较，而不能只听信书上写的。奇迹经常出现在这里；
第三，要在效率和可读性上掌握好平衡，不要光要求速度而不管结构如何，最后造成隐藏的错误；
2 游戏实践讨论
现在有很多人对国产游戏事业是又爱又恨的。爱的是希望能够出现一批真正属于我们自己的好游戏，恨的是这些游戏制作者们太不争气，到现在也没有做出来。我非常感谢他们，因为假如没有他们，也就没有了我们。我也感到非常抱歉，因为我们的作品目前还不能让人们满意。我想多说什么都是无用的，只有实事才能说话。前面我所说的大多是理论上的内容，是我们在几年的游戏制作过程中总结出的经验。这些内容有些可能是错误的，因为我们还没有从正面证明它，有些对我们至今仍然只是个美好的愿望，我们自己还没有真正做到。所以请大家在阅读时针对自己的情况进行取舍。
下面我利用我们曾经做过的一个游戏，具体分析它的制作过程和制作方法。希望借此为那些关心游戏制作的人提供尽可能多的材料，让他们了解得多一些。也为那些有志于游戏制作的人提供一些经验和教训，让他们少走一些弯路。要说明的是，我们在处理某些问题的时侯，所使用的方法很可能是非常普通的，甚至是笨拙的，别人看来可能有更好的办法。但是我不想与各位争论，假如您有什么更好的想法和办法，就把它用到你的游戏中去吧，我希望每一个喜爱游戏制作的人都能够制作出更好的游戏来。
2.1 制作概况
<赤壁>作为瞬间工作室成立以来的第一个作品，是1997年7月上市的，这个版本称作标准版。其后增加了网络功能，修改了一些Bug，增加了一些游戏事件，被称作增强版，增强版于1997年底上市。在此期间，我们又制作了日文版，韩文版和繁体版，又为国内的OEM厂商制作了相应的版本。据说<赤壁>全部的销售量超过了十万份，其中零售量超过一万五千份。这是与前导公司所有员工的努力分不开的。
<赤壁>的策划工作开始于<官渡>制作的后期，1996年6月。而程序开始的时间要晚一些，在1996年9月。那时侯我们碰巧见到了另一部国产游戏<生死之间>的早期版本。这给我们的震动非常大，因为这两个游戏的类型比较接近，而我们才刚刚开始这个游戏的制作而已。从程序开始动工，到第一个版本发行，一共9个月，先后参与程序编写的程序员有5人，总的工作量大约40个人月。程序代码的总量约为90000行，2.6MB。大部分用C++编写，少部分由C和汇编编写。我们使用Microsoft Visual C++ 4.0编译<赤壁>标准版，Microsoft Visual C++ 5.0编译<赤壁>增强版。可执行文件大小约为500多KB。
<赤壁>的工作进度如下：
程序设计期：1996年9月初至1996年11月底。
底层制作期：1996年12月初至1997年2月底。
游戏编写期：1997年3月初至1997年5月底。
游戏测试期：1997年6月初至1997年6月底。
日文版： 1997年8月。
OEM版： 1997年9月。
韩文版： 1997年11月。
繁体版： 1997年12月。
增强版： 1997年12月。
需要说明一点：那就是我们的所有程序全部都是自己完成的，没有使用任何其他人其他公司提供给我们的代码。要知道，我们公司当时还没有能力去购买国外的游戏引擎，而我个人连SoftICE都不会使用，更不要说跟踪研究别人的代码了。我们对别人的学习方式非常简单和直接，就是观察。通过观察猜测它所使用的方法，然后考虑自己如何把它实现。这可能是我想到的最笨的一种方法，如果一个程序员能力强，在制作游戏以前，详细分析了解别的游戏的算法我想一定是非常有用的，他在制作游戏时一定可以节约不少走弯路的时间。
另外，我们对<赤壁>的测试时间也是很短的，在程序基本稳定之后，我们大概只剩下两个星期左右的时间。所以有很多Bug。
2.2 模块划分
赤壁的程序分成五个大的部分和19个模块：
显示模块
战场显示模块
分为通用显示底层和游戏战场显示。
通用显示底层是基于DirectDraw的一套函数。
有关内容请详见DDApi.h， DDCompo.h。
游戏战场显示是根据游戏单元的类型，位置，状态，动画帧等数据将单元位图以适当形式显示在战场的适当的位置上。要显示的内容有：地形，单元(士兵/建筑/将领)，攻击效果，魔法效果，远程武器物体，阴影等。
主要功能有：对图素的压缩和读取，图像的显示，单元归属颜色的转换，边界剪裁，遮挡关系，缩略图显示和响应，屏幕移动，阴影遮挡判断，攻击效果，魔法效果，远程武器物体的显示和移动。
有关内容请详见CBDraw.h， 显示单元的位图
CBDrawM.h， 显示特殊效果，比如水。
CBDrawOT.h， 显示特殊物体。
CBMini.h， 显示缩略图。
CBMap.h， 图素的操作。
CBShadow.h， 阴影的计算和显示。
CBOther.h， 特殊效果的显示和计算。
界面显示模块
根据游戏设计需要，在显示器相应的位置上显示游戏的各层界面。
它分为两个部分：界面底层部分和游戏界面部分。
界面底层是属于底层部分的通用函数库。它包括按钮，对话框，滑块，检查框等界面元素的实现。
有关内容请详见DDBitmap.h， 显示位图的基类。
DDButton.h， 按钮。
DDCheck.h， 检查框。
DDList.h， 列表框。
DDMenu.h， 菜单。
DDScroll.h， 滚动条。
DDText.h， 文字。
游戏界面主要有：游戏主菜单，新游戏菜单，读取进度菜单，保存进度菜单，网络选择菜单，系统设置菜单，任务提示菜单，结束菜单，错误处理对话框等。
有关内容请详见Interfac.h， 提供基本的游戏界面接口函数。
Interfa1.h， 处理所有的按钮Button信息。
Interfa2.h， 处理所有鼠标操作发出的消息。
net_face.h， 网络部分界面。
Marco.h， 所有按钮的消息ID。
CBprompt.h， 游戏战场中屏幕右方信息的显示。
CBAarray.h， 对游戏元素的查询。
DDComUn.h， 针对游戏中下达命令时的命令组。
过场动画模块
显示公司标志，制作群，历时回顾，片头，片尾和过场动画。
它有两个部分，第一是播放视频图像，第二是调用其它进程。
有关内容请详见CBAvi.h， 视频图像的播放。
Mciapi.h， 播放AVI文件的底层函数。
VCMApi.h， 高效率的播放AVI的底层函数。
CBGame.h， 播放结尾。
Interface.h， 程序状态的转换。
单挑显示模块
武将单挑时出现的专门画面。本部分与原始设计有出入，原始设计中可以对单挑进行操作，后来删减称为只播放一段Video。有关内容请详见CBAvi.h。
控制模块
鼠标控制模块
根据鼠标的位置设置鼠标的形状，对鼠标的操作对响应单元发出命令。
主要内容有：鼠标点击检测，目的地模式，命令构造，可建造区域判定，鼠标形状转换。
鼠标点击检测，主要判断鼠标点击的位置是否在某个单元上或地形上。详见CBMouse.h。
目的地模式，主要控制鼠标选择了单元(命令主体)后，可能对单元下达的命令的模式，根据不同的命令可能需要不同的目的地类型和命令参数。详见CBCtrl.h。
命令构造，通过鼠标的点击选择或按下某个，命令按钮，构造出具有命令主体，命令ID和命令客体的命令，放到命令队列中，供执行。详见CBCtrl.h。
可建造区域判定，在建造建筑时需要判断哪里可以建造哪里不可以， 并且显示出来。详见CBBuild.h。
鼠标形状转换，鼠标移动到某个界面或某个单元上时，或处于命令构造阶段时，需要对鼠标的形状做一定的改变，以显示当前的操作状态。详见CBMouse.h。
命令处理模块
根据鼠标和人工智能发出的命令，传送给对象单元，并将其转化成为单元的相应状态序列。
根据单元状态，判断单元状况，更改单元的状态。
详见CBCtrl.h， 命令的构造保存和传递。
CBRun.h， 命令的执行。
CBRDelay.h， 命令执行时需要的一些变量。
攻击计算模块
根据敌我双方的攻防力量，计谋的实施和阵型计算每一次打击敌人生命的损失。
详见CBRun.h， 攻击计算。
CBZhenFa.h， 阵法计算。
行军控制模块
根据单元的位置，速度，目的地和地形数据，计算行军路线，设置单元的下一步。详见March_n.h。
网络控制模块
游戏数据在网络上的传递，纠错。模拟机的建立和管理。详见Network.h。
策略模块
君主策略模块
计算机一方根据战场双方的力量对比和战斗模式计算对单元的生产，对敌人的攻击，产生命令。
详见TEmperor.h。
将领策略模块
每一支部队根据将领的属性，士兵的状况调整战斗的方式或判断撤退。
详见TGeneral.h。
本能策略模块
士兵单元面对周围的情况产生固定的基本反应。
详见Tai.h。
Tbnbase.h， 人工智能中需要的数据结构。
CBEyes.h， 人工智能与游戏主体结构之间的接口。
文件模块
资料数据文件模块
地形和单元图素的图像文件，相应控制数据文件。单元的各项属性数据文件，操作用数据文件，界
面位置数据文件。
详见CBData.h， 游戏中使用的单元属性全局数据结构。
CBMap.h， 游戏中使用的地图图素，单元图素全局数据结构。
CBGame.h， 游戏中使用的单元全局数据结构。
存储数据文件模块
存盘用数据，记录战场上的所有单元的状态和思考数据。
详见CBGame.h， 存盘。
其它模块
文件封装模块
为减少程序使用的文件的数量，增加程序的安全性，将大量的图像文件和数据文件封装起来，供程序调用。
详见L_Allbmp.h， L_Image.h， L_Save.h， L_Scan.h， L_Text.h， Tools.h。
声音模块
背景音乐和音效。有混音和音量控制。
详见DsWave.h， 播放WAV文件。
文字模块
在非中文系统下显示汉字，日文，繁体汉字和韩文。详见puthz.h。
地图编辑器
为使美术人员方便快捷规范地制做战场地图，提供专门的地图编辑器。同时为整个游戏的文件系统，
显示系统做技术上的准备。
这是一个单独运行的程序，详见Mapedit。exe。
安装程序
将游戏安装和卸载。详见Setup。exe。
2.3 游戏引擎
说到游戏的引擎，很多人都不知道它是什么，以为制作它有多么困难。引擎的概念也很混乱，至少现在我还不知道它的确切定义。但我想如果一个东西要被称作引擎，它应该具有这样一些特点：
它应该是由函数组成的。
它应该实现某项具体功能。
它应该是完整的。
它应该可以被重新使用。
从上面的要求可以看出，其实这就是作为底层程序的要求。我想没有必要把引擎认为是游戏的现成编写工具，只要2改一下美术就是另一个游戏了。只要这些程序代码将会被我们应用在以后的游戏中，我们就已经节约了很多的时间和精力。
下面我会说一下在<赤壁>的代码里，哪些将被看作我们的引擎。实际上，这些部分经过一些修改后正在被我们应用到新的产品中。
显示底层：
这是一套包裹在DirectDraw外面的函数。为了简化在调用DirectDraw函数时的复杂度我们使用了一些缺省参数和内部错误处理函数。建立了一个CDDSurface类库，使得对位图的使用更加简单。详见DDApi.h
在DDCompo.h中我们有关于游戏鼠标的一套操作。在屏幕独占模式中，Windows标准鼠标有时显示会不正常。于是我们自己制作了鼠标的显示方法。方法很简单，在每帧读取鼠标的位置，然后在该位置上显示一张位图。
在赤壁里面，我们没有使用双缓冲区的模式，而是只更新某个特定的区域。它的优点是当需要更新哪里的时侯就更新哪里，对于哪些在每帧中都只有小面积图像需要更新时是非常高效的。比如在486上，<赤壁>的主游戏界面里的鼠标移动仍然是十分流畅的。可惜的是，在<赤壁>的战场部分，它并没有优势，因为基本上是需要全屏刷新的。
在未来的游戏制作中，因为计算机的速度越来越快，所以我们当时所使用的模式恐怕变得不太适用，双缓冲区模式应该是主流方向。
多媒体底层：
主要包括声音和视频。我们使用了MCI设备来播放AVI，WAV，MIDI，CD AUDIO等内容。那曾经是我们在做上一个游戏的时侯完成的部分。但是它有很多缺点，比如不能同时播放多个WAV文件，这对于我们制作游戏音效是很重要的内容。
所以我们又使用DirectSound来播放声音。这里的难点在于当我们需要播放很长的文件时，不能一次读入，而需要建立新的线程按时装入声音。好在现在大部分游戏都使用CD Audio作为背景音乐，不需要WAV。
界面底层：
基于显示底层之上的界面元素其实并不好做。因为我们总希望它的响应方式与Windows95中相同。而大家在<赤壁>里看到的内容就与Windows95有些不一样。比如滚动条(ScrollBar)对鼠标的响应就非常简单，按钮(Button)的反应也有所不同。但是好在它比较简单，易于使用。
在每做完一个游戏之后，我们都习惯要把某些东西整理一下，看看它是否可以在以后被使用起来。而往往这些东西也都是需要不断修改的。因为程序运行的平台不一样了，它的用途也不一样了，而我们的编程水平也不一样了。但总之这些代码被较为完整地保留了下来，它必将是我们今后编程的基石。
2.4 关键讨论
我刚开始编写游戏的时侯总有一个想法，只要游戏的主要部分写完了，游戏也就差不多了。我也遇到过一些游戏制作组的成员，他们也大都是这样的想法，认为只要把游戏的演示版拿给别人一看，然后只要再投资让美工画一些画，游戏就可以做完了。其实事情并不想想象中那样简单。
在我看来，把游戏的大概样子做完了，顶多占整个游戏的三分之一。另外的两个三分之一分别是整个游戏的制作和测试。
举个简单的例子，比如我们在演示版中通常只有一个兵种和一个战场。游戏的显示效果可能很不错。但是，真正在游戏中不会只有一个兵种的，每方都会有大概十种兵，又会有三四方的敌人，这时侯你的显示底层是否能够胜任呢?内存是否会占用太多呢?这时侯还需要我们对其进行优化和修改。连游戏的底层显示部分都可能需要修改，更何况游戏中还有更多的内容呢?
下面我举一些<赤壁>中的例子，这些都可能是极小的问题，但都是我们需要仔细考虑的问题。在你准备开始制作一个即时战略游戏之前，你是否曾经考虑过这些问题呢?假如你对这些问题有所了解，那么你就应该可以非常有把握地马上开始制作游戏。如果没有，也没有关系，因为这些问题我也没有全都事先考虑过。
假如你有时间，可以对你自己的游戏多多考虑一下，这个游戏距离一个真正的产品，到底还缺什么?还有哪些模块和部分没有做完?当你对两者之间的差距有了一个明确的认识后，也就不会担心了。任何东西都是一点一点做出来的，只要按照你想做的内容去做就可以了。
程序状态的转换
我们在写DirectX程序的时侯，总有一种偏见，那就是不希望Windows界面出现在我们的游戏里。于是什么都需要我们自己做。比如说窗口。因为窗口的刷新需要我们自己管理，就觉得没有必要生成多个窗口了。这样所有的窗口消息就必须在唯一的一个函数里实现。可是我们的游戏里有很多种不同的操作，比如界面，系统菜单，播放视频等，这些内容就都必须在这个地方处理。所以我们就引入了程序状态这个概念。我们定义了一系列的状态，在每个状态里，有固定的操作和响应，状态之间的转换也在特定的时侯进行。这样我们就很容易把一些关系不大的内容独立开来，降低程序的复杂性。
其实我们在实现这一部分的时侯是很混乱的。你很难在代码中找到所有状态转换的地方。但是它的实现很简单，一般的规则就是程序的对称性。有专门的装入函数和释放函数，然后有显示函数，计算函数，鼠标消息响应函数，热键响应函数。在内部，需要结束本状态时就发出一个状态转换的消息。在外部，只要在主程序的主循环和消息响应函数处针对不同的状态执行它们不同的函数就可以了。
这里的关键在于状态的转换。因为状态在转换中一定会释放和申请大量内存，如果有的内存没有释放，转换次数一多就会出现问题。如果我们把状态转换的地方写好了，程序看起来也非常干净整齐，Bug也会比较少。
现在编写游戏，需要装入的图量非常大，很有必要制作一个装入时的画面，并且显示百分比。这是我们可能需要一个装入中的状态。遗憾的是<赤壁>并没有实现这个，它的淡入淡出效果仅仅是效果，程序在执行这部分时停止在这里。
有关内容请详见CBGame.cpp和Interfac.cpp。
执行任务
一个士兵在接到我的命令之后，便开始了它的行动。它察看了一下它的命令，这是由两个部分组成的。它先取出第一个部分，是行走。于是根据自己现在的位置和目的地位置先计算了一下路线，把自己当前的状态设置为正在移动，然后根据计算好的方向和自己的速度把自己移动到一个位置。如果这个位置已经到达目的地了，它就停止行走。又察看了一下剩余命令的部分，是攻击。于是它拔出刀砍向附近的一个敌人。敌人死了么?它不停地问自己。如果敌人真的"哇"的一声倒下了，它就得意地站在一旁，微笑着。
这就是我们在战场的一个角落所看到的一个士兵的表现。而实事上，在程序里我们也是这样做的。
我们把每个士兵做为一个单元，独立地处理自己的事物。我们把每个命令划分得更加细致，而称其为状态，执行每个状态时所需要的参数的执行的步骤是最简化的。每个命令都是由一个或多个状态组成的。一个状态满足后就自动转向下一个状态。我们为每个状态都编写专门的开始，运行中，和结束代码。这样每个士兵都在独立地按照顺序处理自己的事务，一个个复杂的单元行动就变得有条有理了。
有关内容请详见CBRun.cpp。
阴影
有人说Warcraft做得好，有人说C&C做得好。我属于前者一派，这不仅仅因为我对Warcraft的观察多一些，而且有一个理由足以说明Warcraft在程序上比C&C更高一筹。那就是阴影。大家都知道Warcraft是双层阴影，而C&C是单层。双层阴影的好处是更加真实。在我们去过一个地方之后，虽然我已经看清楚了地形，但是这里敌人的活动，我们不应该永远知道。可是要把单层阴影变成双层，并不是只要加上一层显示就可以解决问题的。
首先，增加一层阴影就增加了需要显示的时间。时间对于即时战略来讲是至关重要的。它直接影响到游戏的表现效果和操作速度。多加一层阴影就意味着减少了我们增加效果的机会。在我们这里，双层阴影占用了大约5-10%的显示时间。
其次，增加一层阴影就增加了特殊的计算。一层阴影只需要一个二进制数组记录哪里被打开，哪里被隐藏就可以了。而现在则不同，我们需要把那些已经打开的阴影再关上。我们的做法是生成一个二维数组，每位表示一个图素格子。当有一个士兵的视野可以打开这个格子上的阴影时，就把那里的计数器加一，离开时减一。当为0时则这块地形被重新隐藏。
第三，阴影下的单元需要特殊的处理。当我的士兵离开敌人阵地的时侯，敌人附近被半透明的阴影重新覆盖了，这时我们需要把正在那里活动的敌人士兵隐藏起来，而建筑不动。
这就是双层阴影所带来的。可是为了效果，我们不得不如此。看起来还是达到了效果。
除了双层阴影以外，阴影的边界也是很重要的问题。我们不可能把阴影做得和刀切的一样，而让它必须和打开的地面相结合。于是我们必须要有一套贴图，用于阴影边界的各个方向。好在我们在这里利用了一个偷懒的办法(当然是很巧的办法，是Onefish想出来的)。我们采用了一个椭圆的贴图，让相邻的椭圆相切，从而造成边界。因为椭圆是没有方向之分的，我们也就节省了一些贴图的内存和对使用哪张贴图的复杂计算。
有关内容请详见CBShadow.cpp。
选中谁了
<赤壁>战场里的格子是菱形的。这一点有多少人发现了?又有多少人知道它的代价?或许有人认为菱形的格子并不是个很好的注意，但我们恰巧在这里使用了它。当鼠标按下时我们需要知道它放在哪个格子里了。过去的经验是只要知道该点的位置和每个格子的宽度我们就可以很快地算出格子的序号。但是在这里不行，因为格子是菱形的，在一个矩形区域里的点不能被确定它到底属于哪个格子。
怎么办呢?我制作了一个二进制二维数组，大小是格子的宽和高。在这个区域里，如果是属于矩形内接菱形区域内的点设置为1，否则为0。当鼠标在某个矩形区域里时，我就用这个栅格去判断该点的位置上的数值是1还是0。是1则这个点在这个菱形格子里，否则不在。这个办法是我遇到的比较迅速的一个办法。
命令的产生
一个由游戏者发出的命令，一般有三个部分：命令主体，命令本身和命令客体。命令主体就是执行命令的人。我想对这支部队下达命令，这支部队就是命令的主体，在游戏里就是我们用鼠标选中的一群士兵。命令本身是命令的标识。我想下达的是什么样的命令，在游戏里，可能是我按下了某个命令按钮。命令客体是命令结果的接受者，如果我选择了攻击命令之后，再选择了一群敌人，那敌人就是命令客体。
如果所有的命令都这样下达，那编起程序就简单了，玩游戏的人也会累死了。我们常用的玩法是选择了命令的主体后直接用鼠标右键点击命令客体。而命令的产生就由命令主体和命令客体的类别来确定了。
这才是需要我们考虑的东西。
首先是选择命令主体。当我们在战场上鼠标一点，或圈了一个框，然后一松手，这时侯程序就开始算了。这里我要介绍一下<赤壁>的单元类型。我们把单元分成士兵，将领和建筑。士兵又有已经组建成部队的和尚未组建成部队的。士兵的种类可以分成一般士兵，工人和船。我们的选择规则是：组队的士兵优先于建筑。将领优先于组队的士兵。未组队的一般士兵优先于将领，未组队的船优先于一般士兵，未组队的工人优先于船。另外还有特殊处理。按下Ctrl键则选中该组队士兵的将领，按下Shift键则把刚选中的士兵添加到已选中的士兵中。
其次，是选择命令的客体。命令客体可分为地点和单元。地点有普通地点和资源地点。单元又分为敌人的和我方的。单元的种类有士兵，将领和建筑。士兵分为未组队的和组队的。士兵的种类有工人和一般士兵。建筑又分为一般建筑和资源建筑。我们需要根据命令主体和客体共同来判断命令是什么。不同的组合所产生的命令可能可能是不同的。比如，如果我选择了组队的工人作为命令主体，又选择了一个建筑作为命令客体。如果这个建筑是铁矿，那么命令就是采矿。如果这个建筑是我方的建筑，则这个命令是修理。如果这个建筑是敌人的建筑，那这个命令就是攻击了。
有关内容请详见CBCtrl.cpp。
眼睛函数
在游戏策划编写人工智能的时侯，总喜欢写成这样：“当匪兵甲发现敌人就在不远处时就去攻击。”而要把这句话变成程序，还需要不少的路要走。比如匪兵甲是如何发现敌人就在附近呢?首先必须要知道匪兵甲自己在什么地方，其次匪兵甲的视野有多大，也就是说多远算作附近，第三敌人在哪里。这三样东西匪兵甲是如何知道的呢?依靠的就是眼睛函数。
一般我们在编写人工智能时都会把它作为一个比较独立的模块。因为它的主要功能就是判断。它的出口同游戏者的鼠标操作一样，发布命令。如果它的入口也很明确和简单则这部分内容的难度就非常小了。可是人工智能需要得到大量的信息作为判断的依据，而我们的主体数据结构又可能写得不很好，这时候就需要我们另外制作一套程序把游戏内核与人工智能分开。这就是眼睛函数的用处。
编写人工智能的程序员只需要写出他想知道什么，然后交给游戏核心程序员，由游戏核心程序员从游戏核心数据中找到相应的信息，传递给人工智能。这样编写人工智能的程序员就可以根本不知道游戏核心数据是什么样子就可以开始工作了。但是这也是临时的办法，
如果我们可以把核心数据结构写得风雨不透那也不必如此劳神了。
有关内容请详见CBEyes.cpp。
命令队列与网络
本以为网络编程很简单，一写下来才知道头大。虽然这部分代码不是我写的，但是我也知道跟踪一个10兆大的Log文件是什么滋味。网络上的游戏通讯一般有两个办法：交换所有信息和交换重要信息。第一种方法是随时把自己的所有数据都传递到另一端，另一端根据这些数据进行显示和操作。它的优点是不需要同步，对网络状况要求低，计算也非常简单。缺点则是数据量太大，只传递少量数据还可以接受。所以这种方法多用于RPG游戏并多在Internet上使用。第二种方法则只传递关键的数据，计算机接到这些数据后对其进行计算，因为计算的结果是唯一的，所以可以保证网络两端一致。这种方法适用于那些数据量大的游戏，但它的编写和调试就比较复杂，而且对同步的要求较高。我们的<赤壁>就是采用的这种方法(<西游记>用的是第一种方法)。
在这种网络的联接方式中，最重要的问题一个是同步，一个是结果唯一。只有同步我们才能保证在每一轮的计算中所有计算机上的初始状况是统一的，只有结果唯一我们才能保证在执行了一段时间后所有计算机上的状态是统一的。这样才能保证网络游戏的正确性。
除了初始化等必要得操作以外，我们把游戏中的命令作为关键信息在网络上传递。游戏者对战场上部队的任何操作，下达的任何命令都会被传递给其它的计算机。如果游戏者没有操作，则我们制3在每一轮循环中传递同步信号。在这里我们遇到了一个DirectPlay中的问题，那就是信号并不是每次都会正确传递到对方那里的，尽管我们在DirectPlay中使用的参数要求系统必须在确认对方收到后才返回，可是它返回后对方依然没有收到。关于这个问题我没有查看有关文档，也许有更好的解决办法。所以我们自己制作了一套校验确认的方法。
但是我们在本机上发布的命令传递到另一台计算机上时一定会有延迟，这就不能保证初始状态的一致。所以我们采用了轮回制。任何人发布的命令并不会马上被执行，而是先存储到一个命令队列中。在每次循环中对曾经下达的所有命令统一进行发送，侦听。当所有计算机都收到了所有计算机本轮要执行的命令后，所有的命令开始被顺序执行。这样在任何一台计算机上本轮中所有命令的内容和顺序都是相同的，执行时才能保证其结果的一致。
有关内容请详见CBCtrl.cpp， CBRun.cpp。
兵种的颜色
这大概是即时战略游戏里最隐蔽的一个问题了。因为不做的人不知道，而做的人都心照不宣。在我们的游戏里，不同的君主用不同的颜色代表，属于该君主的士兵则在它的衣服上赋予相应的颜色。这样虽然兵种相同但是他们的颜色不同，这样就可以区分敌我了。但是如果我为每一个兵种都制作一套图素，那么就显得有些浪费了，这会占用过多的内存(我们这里所有兵种的图素量约有10MB，如果有四种颜色就需要40MB的图素)。谁都希望找到一个好的办法节省这些内容。
我们的方法很简单，抽色。我们在调色板里的留出固定的位置，需要改变的颜色就按照顺序存储在这里。在显示时，我们会根据传递进来的君主号为每张图素的颜色进行判断，如果颜色在这些区域里就根据规则偏移。这样各种颜色的士兵就会显示出来，而只需要一份图素。
这种方法的缺点就是速度慢，毕竟需要对每个点进行判断和处理。所以这部分也是我们针对MMX优化的主要部分之一。
怎么样?奇怪么?有关内容请详见CBDraw.cpp。
遮挡
我在设计游戏开始时就考虑过单元的遮挡问题，因为这曾经是<官渡>遇到的问题之一。游戏单元在屏幕上的位置会经常有所变动，但我们必须保证一点，即下面的物体总要把上面的物体遮住。但是我发现这个问题实际上在<赤壁>里几乎不存在。因为在每一帧都是重新显示一屏内的所有信息，只要我每次从上向下画图就可以了。当然这是个极为极端的例子。我们仍然需要考虑遮挡的问题。比如，人被山挡住的问题。我们通常为了在显示函数里显得结构化一些，都是先显示地形，再显示人物。那么当人物走到了山的上部时，就需要山峰挡住人，可是这时侯山都已经显示完了，我们必须再次显示山。而显示山的时侯又不能够显示整个的山，我们必须划分出显示的区域，让它可以显示又不会遮挡别的地形。
调整这部分内容可能占据了我制作显示部分的绝大部分的时间。好在最后实现了，但我仍然在想是否有更好的办法解决这个问题。
有关内容请详见CBDraw.cpp。
行军算法
我们在制作<官渡>时没有给士兵以一套完整的行军算法，让它去寻找一条到达目的地最近的路线，而在<赤壁>里想做一下尝试。就自制了这样一套算法。首先找到一条直线，然后围绕挡住这条直线的障碍物搜索一条可以行走的路线。说起来简单，做起来可很困难。这部分代码写了大约有四五个月。
当然它也仍然有缺点，比如如果在路上的障碍物内部有空洞，那么就会卡住。但好在它的速度还算可以，一百个人同时走路时才会感觉到一点停顿。
本来我们打算在<荆州>里有所改变的，我们采用了世界上比较流行的行军算法：A*算法。并且为它专门制作了一套底层，使它可以挂在任何一个地图结构里。
有关内容请详见March_n.cpp。
为什么有数量限制
又回到了老生常谈的话题。编程序的人一看就可以知道，对士兵数量进行限止的唯一理由就是没有使用链表。的确是我胆小的缘故。我没有在游戏的核心数据结构中使用链表，原因很简单，怕出错。我为每个游戏者开了200个单元的空间，也就是说每方游戏者都可以制造200个士兵和建筑。我想这个数量应该是够了，因为如果真的每个游戏者都生产出这么多数量的单元，游戏也跑不动了。
使用数组不仅出错的机会少一些，而且它对于查错也很有帮助。在我们的早期测试版中，我让游戏每隔10轮就自动存一次盘。存盘的内容就是简单的把这些数组内的内容写到文件中。如果程序跳出，马上调出存盘很快就会跟踪出错误的位置。后来，在<赤壁>标准版发行后，也有玩家反映有异常退出的错误，我就让他们把存盘文件寄给我，我就能很快发现问题。如果使用指针链表恐怕就没那么容易了，但也有一个好处。如果玩家玩出一个错误，只要他再重新玩很可能这个错误就不出现了。
有关内容请详见CBCtrl.cpp。
镂空贴图
我估计有不少初学编游戏的人都会有这个疑问，如何让一个人出现在地形上而身上没有黑边。要知道计算机的显示一般都是以矩形为单位的，一个边界不规则的图形该如何显示呢?
假如我们按点去操作，那么就可以判断如果人的图像上是黑色则跳过去，否则显示到背景上。但是谁都知道这样是很慢的。于是我们想到了使用逻辑操作来贴图。我们有一个真人的图像，边界是黑色的，我们叫源码。然后我们制作一个掩码，人的内部是黑色的实心，外部是白色。然后我们做两次逻辑操作，先把人的掩码与背景做“与”操作，这样背景就被扣出了一个黑色的轮廓，然后把人的源码与背景作“或”操作，人就呆在背景里了。
如果你看到我们的地图编辑器，就会发现我们就是这样做的。这是<官渡>的做法，在编写编辑器时我还不会使用DirectDraw呢。但是在DirectDraw环境下，我想大家就可以省事很多了，只要一个ColorKey的变量设置，DirectDraw就可以替你完成镂空贴图的操作。
从这里你也可以看到我们也许不会一开始就把游戏做好，但只要坚持下去，我们一定会越做越好。
有关内容请详见DDApi.cpp。
2.5 希望
有人说即时战略游戏已经过时了，或者已经做到头了。我的观点截然相反。
我认为它是目前唯一能够胜任大规模集团作战的游戏类型，它所能够带给人的东西我们还远远没有做到。我是很喜欢看电影的，尤其是战争电影，那些电影里的场面和效果在游戏里出现了么?有，但是还远远不够。
我承认我们的制作能力与国外的水平还有很大的差距，但是即时战略依然会有它的发展。
比如，即时战略已经开始慢慢向战棋式的战略游戏靠拢，采用多层战略地图，多级控制的方式。这就是一个可能的发展方向。即时战略也可以不采用采矿的方式，而利用其它(比如经营)方式来获得资源，这也是一个可能的发展方向。
我总是觉得，制作游戏就是在创造世界，虽然我们的这个世界还无法与真实的世界相比。但是，只要我们做了，就会有进步，就会离梦想近一点，也许我等不到那一天，可是也许某个看到我的文章的人等得到那一天，这我已经很高兴了。制作游戏的路刚刚开始，对于我们而言，我们希望能够继续做下去，可是上帝毕竟是广大的玩家，如果大家不认可，那我们还是趁早改行为好。但我总是有些不死心，总希望能够有人坚持下来，如果这个人不是我。我真心地希望能有更多的人了解游戏的制作，了解制作游戏的人，也希望有更多的人加入到这个充满了艰辛的事业来。因为美好的明天需要我们去创造，我们为游戏付出了很多，它也会同样地回报我们的。
以上内容仅是我个人的观点，如果有任何异议请与我联系，但是我不会与各位争论什么，因为只有做才是最重要的。如果有什么问题，也可以来信，但是我可能不会很快或很详细地回答，因为我现在正忙于制作新的游戏。
我的E-mail地址是liu-gang@263。net。
假如你已经整装待发，那么就开始吧，不要犹豫，人的一生只有一次，只要去生活就是了。
X
xdzhan
Unregistered / Unconfirmed
GUEST, unregistred user!
There are a vast number of different ways to approach this. Todo
2D
animation, you generally draw your sprites using a paint package such as
Photoshop or PaintShop Pro. then
you create an application using Delphi to
draw these sprites on the screen.
Todo
3D, you can either generate the 3D information algorithmically or use
a 3D editor such as 3DS Max or MilkShape (to name two of the numerous 3D
programs out there) to generate a mesh. You then
create an application in
Delphi that loads this mesh and displays it using OpenGL, Direct3D or one of
the many engines/libraries that encapsulate OpenGL or Direct3D.
So, put simply, you need a number of data creation tools. This could any of
the following
- paint package to create 2D artwork (sprites, fonts, etc) and/or textures
(to map onto your 3D mesh)
- 3D design package to create the 3D meshes and animations
- sound editor for recording and editing wav files
- music editor for creating and editing music
- level editor to create the levels for your game. This is usually specific
to your game.
- any other custom tools that you may require for your specific game
Your game then
loads the data created by the above-mentioned tools or
generates the data via various algorithms at run-time and displays it
on-screen using 2D or 3D as desired or plays it through the soundcard.
I spent most of my university days playing games and studying how they were
created. That's probably why I ended up failing the course, but Ido
think
of those days, twelve years ago, as an essential step towards my current
career as lead programmer on a major PlayStation2/GameCube title. We use
all the above tools and many more in the development of our games.
Take a look at http://turbo.gamedev.net or http://www.delphigamer.com for
many links to resources about creating games and animations in Delphi. For
example, http://www.delphi3d.net and http://www.sulaco.co.za have many great
demos using OpenGL that will just blow you away. And they come with full
source code.
If you want to use Delphi for your first little games (and there is no
reason against it) you'll discover very soon that it isn't possible to make
fast and good looking graphics with standart-delphi. the gdi-functions that
go with windows-api or the vcl-components like tcanvas won't suit your
requirements. They are pretty slow anddo
n't support alphablending, rotating
and so on.
There are at least three possibilities for you to achieve nice graphics in
delphi:
- write your own bitmap-manipulation functions. That isn't necessarily
faster but you cando
things like rotating or blending or manipulating the
pixeldate very well. But thats probably a bit complicated for the
begin
ning... (I just point at the Tbitmap.scanlines property!)
- you cando
wnload the jedi-directx files, some wrapper units that allow you
to use directX in your games. I've not tried this yet, but it's as far as i
know the best and fastest way (at least for windows-games) but i guess it's
very complicated too!
- the last way to start is using DelphiX. That's what i did when the
standard stuff wasn't sufficient anymore. DelphiX contains some great
components and tutorials wich allow you to use directX accelaration in your
game. It's really easy to use.
Have a look on www.delphigamer.com or at http://turbo.gamedev.net (as steve
allready said). there you'll find linksdo
Jedi-DirectX and DelphiX.
Btw: I'm quite a newbie too, so if i said anything wrong please correct me!
And i know that i forgot things like openGL and SDL in my list...
2D
animation, you generally draw your sprites using a paint package such as
Photoshop or PaintShop Pro. then
you create an application using Delphi to
draw these sprites on the screen.
Todo
3D, you can either generate the 3D information algorithmically or use
a 3D editor such as 3DS Max or MilkShape (to name two of the numerous 3D
programs out there) to generate a mesh. You then
create an application in
Delphi that loads this mesh and displays it using OpenGL, Direct3D or one of
the many engines/libraries that encapsulate OpenGL or Direct3D.
So, put simply, you need a number of data creation tools. This could any of
the following
- paint package to create 2D artwork (sprites, fonts, etc) and/or textures
(to map onto your 3D mesh)
- 3D design package to create the 3D meshes and animations
- sound editor for recording and editing wav files
- music editor for creating and editing music
- level editor to create the levels for your game. This is usually specific
to your game.
- any other custom tools that you may require for your specific game
Your game then
loads the data created by the above-mentioned tools or
generates the data via various algorithms at run-time and displays it
on-screen using 2D or 3D as desired or plays it through the soundcard.
I spent most of my university days playing games and studying how they were
created. That's probably why I ended up failing the course, but Ido
think
of those days, twelve years ago, as an essential step towards my current
career as lead programmer on a major PlayStation2/GameCube title. We use
all the above tools and many more in the development of our games.
Take a look at http://turbo.gamedev.net or http://www.delphigamer.com for
many links to resources about creating games and animations in Delphi. For
example, http://www.delphi3d.net and http://www.sulaco.co.za have many great
demos using OpenGL that will just blow you away. And they come with full
source code.
If you want to use Delphi for your first little games (and there is no
reason against it) you'll discover very soon that it isn't possible to make
fast and good looking graphics with standart-delphi. the gdi-functions that
go with windows-api or the vcl-components like tcanvas won't suit your
requirements. They are pretty slow anddo
n't support alphablending, rotating
and so on.
There are at least three possibilities for you to achieve nice graphics in
delphi:
- write your own bitmap-manipulation functions. That isn't necessarily
faster but you cando
things like rotating or blending or manipulating the
pixeldate very well. But thats probably a bit complicated for the
begin
ning... (I just point at the Tbitmap.scanlines property!)
- you cando
wnload the jedi-directx files, some wrapper units that allow you
to use directX in your games. I've not tried this yet, but it's as far as i
know the best and fastest way (at least for windows-games) but i guess it's
very complicated too!
- the last way to start is using DelphiX. That's what i did when the
standard stuff wasn't sufficient anymore. DelphiX contains some great
components and tutorials wich allow you to use directX accelaration in your
game. It's really easy to use.
Have a look on www.delphigamer.com or at http://turbo.gamedev.net (as steve
allready said). there you'll find linksdo
Jedi-DirectX and DelphiX.
Btw: I'm quite a newbie too, so if i said anything wrong please correct me!
And i know that i forgot things like openGL and SDL in my list...
J
jrq
Unregistered / Unconfirmed
GUEST, unregistred user!
我也想学学～
将此问题收藏！
将此问题收藏！
L
lesser-panda
Unregistered / Unconfirmed
GUEST, unregistred user!
wo Kao duo
H
huasoft
Unregistered / Unconfirmed
GUEST, unregistred user!
利用Dxdraw控件编写的游戏：www.huasoft.net（长沙三打哈）
