📄 g8.htm
字号:
<html>
<head>
<title>游戏制作</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css">
<!--
body { font-size: 14px}
td { font-size: 14px}
a:active { text-decoration: none}
a:link { text-decoration: none}
a:visited { color: #FFFFFF; text-decoration: none}
a:hover { text-decoration: underline}
-->
</style>
</head>
<body bgcolor="#e8ffe8">
<br>
<table width="85%" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td>2.3 游戏引擎 <br>
说到游戏的引擎，很多人都不知道它是什么，以为制作它有多么困难。引擎的概念也 <br>
很混乱，至少现在我还不知道它的确切定义。但我想如果一个东西要被称作引擎，它应该 <br>
具有这样一些特点： <br>
它应该是由函数组成的。 <br>
它应该实现某项具体功能。 <br>
它应该是完整的。 <br>
它应该可以被重新使用。 <br>
<br>
从上面的要求可以看出，其实这就是作为底层程序的要求。我想没有必要把引擎认为 <br>
是游戏的现成编写工具，只要2改一下美术就是另一个游戏了。只要这些程序代码将会被 <br>
我们应用在以后的游戏中，我们就已经节约了很多的时间和精力。 <br>
下面我会说一下在<赤壁>的代码里，哪些将被看作我们的引擎。实际上，这些部分经 <br>
过一些修改后正在被我们应用到新的产品中。 <br>
<br>
显示底层： <br>
这是一套包裹在DirectDraw外面的函数。为了简化在调用DirectDraw函数时的复杂度我 <br>
们使用了一些缺省参数和内部错误处理函数。建立了一个CDDSurface类库，使得对位图的 <br>
使用更加简单。详见DDApi.h <br>
在DDCompo.h中我们有关于游戏鼠标的一套操作。在屏幕独占模式中，Windows标准鼠标 <br>
有时显示会不正常。于是我们自己制作了鼠标的显示方法。方法很简单，在每帧读取鼠标 <br>
的位置，然后在该位置上显示一张位图。 <br>
在赤壁里面，我们没有使用双缓冲区的模式，而是只更新某个特定的区域。它的优点是 <br>
当需要更新哪里的时侯就更新哪里，对于哪些在每帧中都只有小面积图像需要更新时是非 <br>
常高效的。比如在486上，<赤壁>的主游戏界面里的鼠标移动仍然是十分流畅的。可惜的 <br>
是，在<赤壁>的战场部分，它并没有优势，因为基本上是需要全屏刷新的。 <br>
在未来的游戏制作中，因为计算机的速度越来越快，所以我们当时所使用的模式恐怕变 <br>
得不太适用，双缓冲区模式应该是主流方向。 <br>
<br>
多媒体底层： <br>
主要包括声音和视频。我们使用了MCI设备来播放AVI，WAV，MIDI，CD AUDIO等内容。那 <br>
曾经是我们在做上一个游戏的时侯完成的部分。但是它有很多缺点，比如不能同时播放多 <br>
个WAV文件，这对于我们制作游戏音效是很重要的内容。 <br>
所以我们又使用DirectSound来播放声音。这里的难点在于当我们需要播放很长的文件时 <br>
，不能一次读入，而需要建立新的线程按时装入声音。好在现在大部分游戏都使用CD <br>
Audio作为背景音乐，不需要WAV。 <br>
<br>
界面底层： <br>
基于显示底层之上的界面元素其实并不好做。因为我们总希望它的响应方式与Windows95 <br>
中相同。而大家在<赤壁>里看到的内容就与Windows95有些不一样。比如滚动条 <br>
(ScrollBar)对鼠标的响应就非常简单，按钮(Button)的反应也有所不同。但是好在它比 <br>
较简单，易于使用。 <br>
<br>
在每做完一个游戏之后，我们都习惯要把某些东西整理一下，看看它是否可以在以后 <br>
被使用起来。而往往这些东西也都是需要不断修改的。因为程序运行的平台不一样了，它 <br>
的用途也不一样了，而我们的编程水平也不一样了。但总之这些代码被较为完整地保留了 <br>
下来，它必将是我们今后编程的基石。 <br>
<br>
2.4 关键讨论 <br>
<br>
我刚开始编写游戏的时侯总有一个想法，只要游戏的主要部分写完了，游戏也就差不 <br>
多了。我也遇到过一些游戏制作组的成员，他们也大都是这样的想法，认为只要把游戏的 <br>
演示版拿给别人一看，然后只要再投资让美工画一些画，游戏就可以做完了。其实事情并 <br>
不想想象中那样简单。 <br>
在我看来，把游戏的大概样子做完了，顶多占整个游戏的三分之一。另外的两个三分 <br>
之一分别是整个游戏的制作和测试。 <br>
举个简单的例子，比如我们在演示版中通常只有一个兵种和一个战场。游戏的显示效 <br>
果可能很不错。但是，真正在游戏中不会只有一个兵种的，每方都会有大概十种兵，又会 <br>
有三四方的敌人，这时侯你的显示底层是否能够胜任呢?内存是否会占用太多呢?这时侯还 <br>
需要我们对其进行优化和修改。连游戏的底层显示部分都可能需要修改，更何况游戏中还 <br>
有更多的内容呢? <br>
<br>
下面我举一些<赤壁>中的例子，这些都可能是极小的问题，但都是我们需要仔细考虑 <br>
的问题。在你准备开始制作一个即时战略游戏之前，你是否曾经考虑过这些问题呢?假如 <br>
你对这些问题有所了解，那么你就应该可以非常有把握地马上开始制作游戏。如果没有， <br>
也没有关系，因为这些问题我也没有全都事先考虑过。 <br>
假如你有时间，可以对你自己的游戏多多考虑一下，这个游戏距离一个真正的产品， <br>
到底还缺什么?还有哪些模块和部分没有做完?当你对两者之间的差距有了一个明确的认识 <br>
后，也就不会担心了。任何东西都是一点一点做出来的，只要按照你想做的内容去做就可 <br>
以了。 <br>
</td>
</tr>
</table>
<p align="center"> </p>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -