📄 g4.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>游戏数据结构和算法： <br>
有人讲程序就等于数据结构加算法。这句话很有道理。我们所编的程序其实就是把某 <br>
种格式的数据(图片，主角的参数)经过一系列的转换，成为计算机屏幕上的数据(游戏本 <br>
身)。所有的数据都需要以某种方式存储，这就是数据结构。而算法因为是与数据结构密 <br>
切相关的，所以虽然它们不属于同一个概念，我把它们放在一起设计。 <br>
我们通常所使用的数据一般可以分成两个部分：数据库结构和当前结构。 <br>
这里的数据库不是什么商业数据库软件，而是游戏中所使用到的所有数据的集合。我 <br>
还没有见到有哪个游戏在存储这些数据时使用商业数据库软件(比如FoxBase)。也许它们 <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>
我一般使用索引ID号来代替指针。具体的使用是这样的：数据库结构是以数据元素为单位 <br>
的数组，数据元素的索引(ID)就是它在数据库数组中的下标。所有其它结构对该数据元素 <br>
的保存都只保存了该元素的ID号。指针只在从数据库根据索引得到元素时使用。这样的好 <br>
处很明显，ID号是整型数据，可以通过该值的范围判断出是否有效，只要在其有效范围内 <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>
且我的经验是我们完成游戏的时间一般比计划的要多20%到30%。可是如果按照这样的计划 <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 + -