📄 g3.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.4 程序设计 <br>
我们在编写自己第一个游戏时，往往是凭借自己的兴趣，想到哪就编到哪，有时连自 <br>
己都没想到会编出这么大的程序来。那时侯我们对代码的修改往往是很随意和彻底的，因 <br>
为本来都是自己的东西，而且更希望它更好。可是，程序越写越大，有一个问题就会越来 <br>
越明显，那就是程序的错误。为了减少错误的产生，我们必须采取一些办法，所以也就产 <br>
生了程序设计。程序设计的必要性还表现在另一个方面，那就是程序员间的合作。为了让 <br>
每个程序员对我们所要做的事和我们将如何做这件事有个明确的了解，也为了让管理人员 <br>
能够从量的角度了解任务的完成状况和进度，我们也必须有程序设计。否则我们就只能象 <br>
一群乌合之众一般，鬼才知道这游戏要做到什么时侯。 <br>
一般，我个人认为，当一个程序需要写到10000行以上时就应该有比较独立的程序设 <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>
<br>
程序模块划分： <br>
这是对程序设计总纲中最后一个部分的详细说明。说明的内容主要有：该模块的功能 <br>
、接口、技术要点、所用到的软件底层等。它所面向的对象一般是所有的程序员，但是如 <br>
果让与程序合作的人员(美术、策划、经理)也能了解则更好，这样可以加强我们之间的勾 <br>
通，让不懂编程的人也能了解编程人员的苦衷。 <br>
一般而言，一个游戏按功能划分(我们很少用其它的分类方法)可以有下面几个部分： <br>
<br>
<br>
工具部分：在游戏的制做过程之中，从游戏策划的文档，游戏美工的图片到游戏完成 <br>
，中间必须经过游戏程序的转换和加工。这些数据在进入程序之前必须经过规整，排序等 <br>
操作。这部分工作过去一般都是由程序员来做的。在人手紧张和工作量比较小的时侯这样 <br>
做还是可行的。但是如果这样的工作过于复杂，工作量太大，就不行了，我们需要一种方 <br>
法来提高工作效率。这种方法就是工具。其实我们在计算机所做的任何工作都是在使用工 <br>
具，唯一的区别只是这些工具都不是我们自己做的。因为游戏本身的特殊性，我们不可能 <br>
总能找到我们所需要的工具，自己制做就是十分必要的工作。 <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -