📄 g5.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>1.5 制作流程 <br>
等到游戏计划写完，并得到通过之后，我们便开始进入游戏制作的时间。其实游戏的 <br>
制作可能从很早就开始了，比如早期的技术探讨和准备。而我在这里想再说得稍微远一些 <br>
，远离现在的题目：程序，而转向整个游戏的制作。 <br>
整个游戏的制作过程一般可以分成三个阶段。策划阶段，制作阶段和调试阶段。它们 <br>
之间的关系一般应该是在策划阶段后期，开始程序和美术的制作，在制作后期开始游戏的 <br>
调试。它们三者的时间比应该是3：4：3。我认为这是一个理想状态，但是我们往往达不 <br>
到理想状态，典型的情况是游戏策划迟迟不能定稿，我们不得不在一边设计游戏时一边制 <br>
作，而到了后期，制作又很难按时完成，必然压缩调试时间，最后只好仓促地发售游戏。 <br>
它们三者的时间变成了4：6：0。我所说的这种状态当然只是一个极端，但是我想在我们 <br>
目前所开发的游戏中或多或少都有这方面的问题。 <br>
造成这个问题的原因也有很多： <br>
·游戏立项不规范：人们不知道为什么要做这个游戏； <br>
·策划设计工作准备不足：人们不清楚该做什么、什么时侯做、谁来做； <br>
·制作人员水平有限，缺乏经验：自己做不好，或做不快，甚至都不知道该怎么做； <br>
·资金：没有钱谁会做呢? <br>
·项目缺乏管理：各部门缺乏协调，大家群龙无首，缺乏沟通，最后大大降低士气和工 <br>
作热情。 <br>
<br>
但是无论这些因素都是些什么，以及它将如何严重地影响我们，我都觉得只要有一样 <br>
东西就足以支持我们把这个游戏做完。这就是我们的坚持不懈的努力。现在，我们在市场 <br>
上的游戏质量都不算很好，但是我要说，只要它被做出来了，就是一个成功的作品。我不 <br>
管游戏玩家们对我这句话有何看法，我只是认为，在那些作品的背后一定有一个或一些人 <br>
在努力着。也只有他们才能真正体会制作游戏的艰辛。而且，只要他们还能继续做下去， <br>
经验会逐渐增加，配合会更加默契，游戏也一定会越做越好。 <br>
<br>
游戏程序的制作过程与游戏的模块划分有关，大概可以分成三个阶段：工具制作阶段 <br>
，底层制作阶段，游戏制作阶段。 <br>
底层制作可能是最开始进行的阶段，有可能与策划阶段同时，甚至更早。因为这个部 <br>
分与具体游戏无关，而可能只与游戏所要运行的平台和我们所使用的开发工具有关。我认 <br>
为，开始的时间应该越早越好。游戏程序员在技术上的准备如果越充分，制作起游戏来就 <br>
会越顺利。 <br>
在策划大纲基本上完成后，也就是游戏的类型，模式基本上固定之后，就可以开始游 <br>
戏工具的制作了。游戏工具一般是提供给美术人员，策划人员使用的(当然也有自己使用 <br>
的)，所以在用户界面上应该多多听取他们的意见。这些天天与我们在一起的用户，如果 <br>
我们都不能好好对待，那就更别提我们游戏的用户了。 <br>
游戏本身程序的制作是最耗费时间和精力的地方，如果说底层程序和工具都可以把重 <br>
点放在结构化和优化上，这部分程序正好相反，我们通常做不到这些。因为我们在写这部 <br>
分程序的时侯，总是已经精疲力尽了，而且我们的代码已经很长很长，一旦发现了程序错 <br>
误，能找到就很不错了，更别提把它改得漂亮一点。再加上游戏策划随时提出的一点小改 <br>
动，就可能要改变我们整体的数据结构，做大的改动几乎是不可能的。所以到了游戏制作 <br>
后期，把程序员叫作铁匠更合适一些，他们在到处打补丁(注意，千万别在写游戏底层的 <br>
时侯也干这种事)。 <br>
<br>
在游戏制作的中后期，每当程序员一睁开眼，进入眼帘的就是满是Bug和缺乏功能的 <br>
游戏，这样的一个程序如何才能变成游戏中真正需要得程序呢?无论当初程序计划制定得 <br>
多么好，在这时候都显得有些不中用。但这并不说明计划没用，而是需要我们把计划变成 <br>
我们真正需要的东西，这就是每日工作计划。名字听起来很正式，其实并没有什么特殊的 <br>
格式，仅仅是把我还没有做出来的游戏的内容一条条地写出来，不必区分什么模块和内容 <br>
的多少，只要手写而且自己看得懂，然后贴在机箱上，要保证随时看到。这些内容我可能 <br>
在一个星期后也没做，但是它会时时提醒我还有什么没有做。随着时间的推移，有些项目 <br>
已经完成了，又会有新的内容写进来，而等到你最后积累出一大叠这种计划单时，你会发 <br>
现原来游戏已经做完了。 <br>
这种办法我一直在使用，有时侯真觉得自己没有长进，做事一点计划也没有，可是它 <br>
就是这么有效，你不必有什么经验，也不必整天面对着程序发呆，每天只要考虑如何把下 <br>
面的内容做好就可以了。 <br>
<br>
不过我还是希望以后的程序员不必这样写程序，如果所有的人都能够每天按照预先制 <br>
定好计划完成工作，也不需要加班，最终做出的游戏又很不错就好了。希望这不是永远的 <br>
梦想。 <br>
<br>
1.6 程序调式 <br>
我在前面曾经说过，我不会使用SoftICE来调试程序。这证明我并不是一个很聪明的 <br>
程序员。这也证明我在调试程序时会遇到更多的困难。让我每天在汇编代码和死机中漫游 <br>
是件很痛苦的事，所以我总在想如何才能摆脱它们。 <br>
如果我不能很快地找到这些难缠的Bug，我能否在一开始就避免它们呢，甚至减少它 <br>
们出现的机会呢?答案是肯定的。 <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -