主题：初到贵宝地,灌一点游戏开发的东东 -- foundera

视觉收益对玩家选产品的重要性

　　中国的游戏研发作为一种高科技含量新兴产业，最先从厚厚内幕中披露和表现出来的一面，很多朋友都认为是国内游戏美工的创作作品。同时这也是全社会对游戏研发这样一种事业慢慢能够接受的切入点。所以在国内的很多游戏网站，我们可以看到日本动漫-电玩-游戏三位一体的主题内容。

　　要承认这么多年来，中国独立的游戏研发作品，前期的整体质量是很糟糕的。策划、程序、UI、美工等等分工里面，最先走出尴尬境地的，就是美工了。这一点倒不妨回忆回忆金山系列的作品，《剑侠情缘》培养了其强壮的美工作业团队，在后来的国内单机游戏研发行业里没有哪家公司的美工能够比金山更有竞争优势。这些演变有些文艺复兴的影子，比如《赵云传》就是个追求优质画面的极致。

　　回忆里形形色色的老游戏，相对而言更能让玩家抱有好感的，绝大部分都在游戏画面上有上乘表现。毕竟人是感性的，接受直观的信息是最有效的选择。往往看数据比看文章更能对判断起有益的作用，看图画比看文章和数据更是最能让人接受。

　　尊重人性化是发展的方向

　　如果研究过艺术的话会发现现代艺术所强调的主题就是人性化。对现代主义艺术风格的形成产生了关键性的影响包豪斯学院，以'包豪斯"风格而闻名于世。它的理念就是要彻底摧毁文艺复兴以来关于“艺术家”的神话。互动游戏是一种艺术形式，在游戏这个主题谈人性化的东西可以谈很多。越来越优秀的画面就是游戏文化进步的一个重要表征。

　　网络游戏3D化带来的视觉风暴

　　2004年将要在中国大陆正式运营的网络游戏，大部分都是基于3D视觉世界的。仅限的几款2D游戏，虽然都是经典的老系列产品，但是在游戏画面上也早已脱胎换骨，连带着诸多特别注重改善游戏人性化高度的修正和改良。随着广大玩家电脑硬件和网络条件的逐步提升，3D化正在游戏产品的不同层次全面渗透，并灵活的应对用户的不同需求和习惯。喜欢真实感的可以玩全3D游戏(比如A3、神迹、天堂II等等)，当然硬件要好网络要稳，看3D视角就头晕头疼的可以玩2D地图3D人物造型，细腻的动作栩栩如生(这一点强烈建议大家去看盛大正在研发的《梦幻国度》，Q版的人物造型非常的可爱！)

　　随着中国网络游戏自主研发实力的不断加强，又在韩国研发商带来的不得不接受的“磨练”中积累了宝贵的运营经验，日后的新玩家将不再像从前那样面临诸多门槛，要去调查好游戏的平衡性等诸多很不直观的资料，而这样的前提下，更能凸现游戏在视觉人性化、美术方面将给予产品的市场推广以鼎立支持。希望眼下充斥市场的韩国造视觉垃圾可以有朝一日被逐渐清理出中国市场。

　　从游戏创作的角度来讲，美工的职务可以分为以下三种：

　　原画人才

　　在没动笔之前，对于一个将要设定角色原画人来说，他们对游戏世界观等大量信息是来至于游戏策划者所写的案子。在他们的原画稿上到处都写满了注释，比如这个角色多高，什么性格等个种关于游戏伦理观的说明，这些游戏理论的注释就是策划者带给他们的最初的信息。他们的工作是很有意义的，原创是艰难的。虽然只是通过最简便的纸笔却很好的表达出来了每个角色的个性化，他们是大胆的他们是很有思想的•

　　2D人才

　　他们的工作绝大部分是给游戏最初的素描稿设定颜色，他们的工作是充满着色彩，充满着活力。要知道表现一个故事背景，须对每一个场景每一个角色的颜色都十分有讲究的。其游戏若要表现个雪景，无疑首考虑的就是冷色调。他们是非常重视氛围的刻画。因此他们会花大量时间来考虑这张图是要表现什么要用什么颜色，他们不希望画出来的图让人不知道是在表现什么主题，所以他们会不断的去了解游戏的精髓，然后通过自己对游戏的了解用色彩在游戏里表现得淋漓尽致。他们的生活无疑是充满着色彩。

　　3D人才

　　说起3D，会让人想起全三维游戏，关于这一类人才，在游戏行业中主要是为游戏提供精美画面。具体来说主要是做游戏画面上的角色，怪物或是NPC等。不管是会动的怪物或是不动的游戏房子，3D的制作人员都要花很大的精力和时间来制作，让整个游戏更有真实的气氛，尽管游戏它是虚拟不真实的，但三维的动画会让游戏显的更有感染力。如今游戏行业中3D网络游戏来势汹涌，且很多玩家对3D类型的游戏大作都很期待，这类人才可以说在将来很长一段时间内都会对网络游戏的发展起到很关键的作用。

在决定开发游戏之前的15个问题

魔戒游戏开发组

　　首先我们试图明确的是：假如能够顺利完成开发工作并上市，我们的成品要卖给谁？换句话说，我们为谁而制作游戏？因无台、港等海外市场背景资料，仅对大陆市场的玩家群体作如下简单归类分析

首先我们试图明确的是：假如能够顺利完成开发工作并上市，我们的成品要卖给谁？换句话说，我们为谁而制作游戏？因无台、港等海外市场背景资料，仅对大陆市场的玩家群体作如下简单归类分析：

　　1、从性别异同上可划分为男性玩家、女性玩家。其特点：

　　男性玩家 ― 涵盖全部游戏类型，集中于SLG、RPG、FPS、RTS、SPG等方面。

　　女性玩家 ― 涵盖大部分游戏类型，集中于RPG、TAB等方面。

　　2、从年龄上可简单分为不同年龄段的用户。其特点：

　　14岁以下 ― 童年期，以初二以下与小学生为主，家长决策购买为主。

　　14―18岁 ― 青春前期，以初三至在校高中生为主，两方式并存。

　　18―22岁 ― 青年后期，以在校大学生与就职青年为主，自主决策购买为主。

　　22―25岁 ― 青年前期，以在职青年为主，自主决策购买为主。

　　25―30岁 ― 青年中期，以在职青年为主，自主决策购买为主。

　　30岁以上 ― 青年后期至终，职业形态不定，自主决策购买为主。

　　3、从收入来源上可简单分为在校学生用户、工薪阶层用户。其特点：

　　在校学生用户 ― 无自主收入来源，主要靠家庭供给与决策购买。

　　工薪阶层用户 ― 有自主收入来源，自主决策购买。

　　4、从文化程度上可简单划分为初等学历、中等学历、高等学历及以上。其特点：

　　初等学历　　　 ― 初中以下文化程度，消费认知力较低。

　　中等学历　　　 ― 初中至高中（中专）文化程度，消费认知力中等。

　　高等学历及以上 ― 大专及以上文化程度，消费认知力较高。

　　5、从居住环境上可简单分为都市型、城市型、县镇型。其特点：

　　都市型 ― 消费焦点广度扩散，购物场所密集分布，收入幅度较高。

　　城市型 ― 消费焦点中度扩散，购物场所较为密集，收入幅度中等。

　　县镇型 ― 消费焦点低度扩散，购物场所较为疏离，收入幅度较低。

　　6、从传媒影响上可简单划分为主动型、被动型、疏离型。其特点：

　　主动型 ― 对于行业传媒具高敏感度，认知渠道宽广。

　　被动型 ― 对于行业传媒敏感度较低，认知渠道较窄。

　　疏离型 ― 基本不接触行业传媒，认知渠道极窄。

　　7、从消费心理上可简单划分为保守型、冲动型、理智型。其特点：

　　保守型 ― 消费欲望低，注重产品售后等外延。

　　冲动型 ― 消费欲望高，注重产品观感与现场服务。

　　理智型 ― 消费欲望中等，注重产品性价比。

　　8、从硬件环境上可简单划分为原主流机种、现主流机种、高配置机种。其特点：

　　原主流机种 ― P133及以下机种，部分无多媒体配置。

　　现主流机种 ― P166-P266之间机种，多媒体配置。

　　高配置机种 ― P300以上机种，多媒体配置。

　　9、从软件环境上可简单划分为DOS用户、Windows用户。其特点：

　　DOS用户 　　― 硬件配置一般较低，多为文档输出平台。

　　Windows用户 ― 硬件配置不等，主流软件环境。

　　10、从接触程度上可简单划分为普通用户、新晋玩家、熟练玩家。其特点：

　　普通用户 ― 游戏与电脑知识匮乏，尚未实际接触游戏的潜在玩家。

　　新晋用户 ― 初步掌握游戏知识，对简单操控的游戏刚刚上手的现实玩家。

　　熟练玩家 ― 熟悉游戏知识，能够熟练操作游戏与电脑的玩家。

　　11、从购买模式上可简单分为正版玩家用户、D版玩家用户、综合玩家用户。其特点：

　　正版玩家用户 ― 日常以正版消费为主体。

　　盗版玩家用户 ― 日常以盗版消费为主体。

　　综合玩家用户 ― 两者情况兼具并额度基本对等。

　?b>12、从娱乐环境上可简单划分为家庭娱乐型、办公室娱乐型、网吧娱乐型。其特点：

　　家庭娱乐　 ― 自有主机，游戏类型不定。

　　办公室娱乐 ― 公用主机，以消遣娱乐性游戏类型为主。

　　网吧娱乐　 ― 公用主机，以竞技对抗性游戏类型为主。

　　13、从游戏形式上可简单划分为单机型、局域网型、互联网型。其特点：

　　单机型　 ― 主要在单机上进行游戏，涵盖各游戏类型。

　　局域网型 ― 主要在局域网上进行游戏，竞技类游戏为主。

　　互联网型 ― 主要在互联网上进行游戏，竞技类游戏为主。

　　14、从游戏目的上可简单划分为操控型、掌握型、剧情型与娱乐型。其特点：

　　操控型 ― 主要在游戏中热衷操作与控制的乐趣，如ACT、SPG、FPS等。

　　掌握型 ― 主要在游戏中热衷发展与征服的乐趣，如SLG、RTS等。

　　剧情型 ― 主要在游戏中热衷故事与养成的乐趣，如RPG等。

　　娱乐型 ― 主要在游戏中热衷消遣与放松的乐趣，如TAB等。

　　综合型 ― 以上两种或数种的综合类型。

　　15.从游戏人格上可简单分为躁进型、冷静型、平衡型、多变型。其特点：

　　躁进型 ― 游戏中易于冲动，喜欢探索新领域与自我表现，较注重游戏声光与操作。

　　冷静型 ― 游戏行为较为保守，喜欢研究系统与剧情，较注重游戏主题与系统。

　　平衡型 ― 处于躁进型与冷静型的中间状态并保持持续稳定。

　　多变型 ― 不同时间.地点中游戏人格多变，难以作统一结论。

　　综上所述，目标顾客群体可从多方面归类分析，其中要注意的问题如下：上述为简单类型划分，详细还可继续深入分析。如互联网玩家可分为连接速率、连接形式、单位时间、游戏量等等细则。应在目标顾客界定时建立有机关联。注意其内在的客观必然联系。类型综合与特殊区域市场的异常等等。如14岁以下玩家必然无个人收入来源。文化程度决定游戏审美观等。掌握相关数据的进化提前量。明确动态发展概念，对成品上市周期与届时环境提前作正确预测。

开始做游戏

你的理想游戏

　　每个玩家似乎都构思着一个梦想中的游戏。那么，我们就来谈谈游戏的构思。你应该知道，那些最终敲开游戏之门的作品是集思广益而得来的。在这个文章中，我们将谈论如何将头脑中的构想组织成一个贯通的、有实现性的设计方案。我们要探明那些你构思中的，可能会遭遇到的情况和潜在的缺憾。让我们开始吧……

创意从何而来

　　创意可以来自任何地方。你可以从其他游戏、或者你的梦境、或者电视节目、或者电影、或者你的朋友和熟人，甚至那些刚刚从新闻组或聊天室中认识的人，从他们中间获得创意。为了成为一名有抱负的设计师或程序员，你最好身边经常带着笔和纸，在创意萌发时将它们记录下来。许多专业的设计师总是将笔记本带在身边。尽管大多数创意或许不是新颖的，但至少值得你努力使它们在你的游戏中展现原始的样子。市场上已经有太多的"我也这样"了，努力不要让你的创意也成为简单的复制品。

　　如果你为某个游戏小组工作，那么可以通过自由讨论来获得独到的见解。这个办法常常被专业的小组采用，并贯穿整个开发过程。最初的创意来自于所有队员坐在一起为新的游戏畅所欲言。每个被引入团队的新创意都会在讨论后进行尝试和测定，去判断它是有益的还是不好的。最后，团队将选择那些听起来对研发最好的建议。

　　如果你打算进行自由谈论，最好先设立一个强有力的领导人，将事情控制在轨道上。如果没有能够做出裁决的领导人，那么这些创意会变成无谓的争吵，那就一事无成了。一旦创意被团队采纳，就需要充实其中的细节。在整个开发过程中使用独特的技术，去解决各式各样的问题并找到原因。

你能做到吗

　　不论是对初学者还是有经验的人而言，持有过多的理想是最大的过失。不要去计划那些根本不可能实现的或者远远超出制作实力的想法。这种错误或偶尔或经常在所有等级的开发者中发生，这是很普遍的事情。那么，让我们看看如何避免这种情况的发生。

　　太多的理想

　　这大概是游戏设计中最普遍发生的错误。很多商业性的游戏都会因为制作时间的限制，而不得不从原始的方案中砍掉一些设计。有很多这样的案例，项目在开始时很大，而后被删减的很简单。

　　如何避免这种失误？喔，作为一名初学者，最好把你的设计做得短小和简单。不要试着把你头脑中巨大的梦想一次倒出来。如果你真的这样做，很可能因为经验不足而倍受打击，这是会让你失去信心的。开始时做得小一些、简单一些，让事情不要花费太多气力。这样做你可能不会得到很多经验，但却可以建立自己的信心。这同样是一个好的建议，使得你不至于一开始就花费太多的时间和精力。

　　还有一件需要避免的事情，就是在设计一个游戏时有太多的内容。许多初学者为每一件事情都设想了厚重的环境，却有很多无谓的设计混在其中。如果要完成这样一个游戏，需要太长的时间和一个庞大的制作队伍。努力让你的设计保持在可以实现的范畴内。

　　不可实现的

　　另一个常犯的错误是过高的估计自己的技术实力。在许多方面，主流的技术也是有许多限制的。尤其在基于三角形技术的三维游戏中。例如：尽管三维模型可以非常接近的体现生命体、或是高度细节的场景，但你恐怕没有任何途径在实时的三维游戏中实现它们。这些三角型计算将非常消耗资源以至于会让三维引擎崩溃。

　　在做实时三维游戏时，你需要对很多难以权衡的事情做决策。你要熟悉所选择的引擎的技术限制，只有这样才可能执行一个很困难的设计。即使你制作自己的三维引擎也是会被限制在主流技术领域中的。经验在你决定事情的可实现性上会有很大帮助。而且，设计的简单一些以获得经验是最好的起步方法。

　　一旦你觉得拥有了一个可执行的游戏设计，那么对于其可行性的最终测试，将通过做一个概念验证而实现。后文会用一个单元来解释什么是"概念验证"。

　　超出能力范围

　　最后一个普遍存在的错误是企图完成某事但却丝毫没有准备。首先，你要在短小、简单的项目中锻炼自己的技能。没有一个专业的游戏开发者是直接从世界级游戏起步的。不要认为id Software的那些家伙是由Wolfenstein 3D起步的，他们第一次的作品是一个类似Commander Keen的简单的卷轴游戏。

　　正象其他值得努力的事情一样，你不能起步过高。想让你梦想的游戏成为一个优秀的作品，需要不断地制作小的项目，然后让它们逐渐复杂起来。最终，你的技能会磨练到一个可以制作出迷人游戏的层次。这需要你的耐心和钻研。罗马城不是在一天里完成的，也不是由伟大的游戏开发者建造的。

写下来

　　一旦有了细致的创意，你应该把它活灵活现地写在纸上。在专业游戏设计师的领域中，称这种文档为策划案。大多数商业游戏项目都有自己的策划案。这些文档在开发过程中担当着地图的作用，并且可以帮助你将精力集中在设计上。

　　策划案包含着所有细节，用以描述你的游戏计划。它可以长或者短，或者包含一些你渴望描述的细节。书写这些文档是没有标准格式的，如果你希望发行商购买你的游戏，那么在策划案中大致要包含以下几个内容。

　　下面的列表是策划案中大致要包含的事项：

1)　游戏的概述

2)　游戏的背景故事

3)　角色或者部队单位的描述

4)　描述游戏的玩法

5)　图片模型

6)　描述游戏的级别

7)　目标市场的机器配置（基本的系统需求）

8)　游戏的风格、类型和视觉感受

9)　描述游戏的特色

10) 描述游戏的AI控制

　　如果你打算让发行商更好的接受你的设计，也许要包含以下项目：

11)　制作队伍的成员名单及其拥有的技能

12)　开发工具的需求列表

13)　项目工程的开发进度表

14)　日常开支的预算案（也就是：办公场地、薪金、设备，等等）

15)　游戏特色的解说（商业卖点）

　　在你的计划书中加入你觉得有必要的、用来指导开发的细节描述。多数的游戏开发者坚持书写开发日志。如果你想制作高质量的游戏，那么这些都是很好的建议。

概念验证

　　或许在你的游戏走向实现的道路上会出现一些阻碍。感念验证是指你的游戏中最基本的模型。你通过什么来验证你的游戏可以实现，以及验证它象你所希望的那样有趣。这是对你设计的严峻考验。如果你打算将游戏卖给出版商，那么拥有一个工作模型对你会大有帮助。

　　你的模式应该包括小型的一个或多个可玩的演示。这些演示要展示主要的游戏玩法原理，以及对你的设计具有鉴定性的任何专门技术的改善或效果。它可以是不完整的，但是必须在重要方面工作正常。

　　很重要的，如果你的游戏面貌采用新的技术，那么你必须证明它们可以实现。尤其在你设法让出版商对你的开发投资时，这是非常重要的。你在着手长时间的开发之前，要在你的设计中明确出所有从技术角度上出发的事情。游戏项目在进行了六个月以后才发现一个重要的特色是不可能被实现的，这种情况可不乐观。

独立制作人还是团队

　　在早些时候，游戏开发可以由一个人或者两个人完成。而今天游戏开发则需要一个完整的开发队伍。为什么？基本上是因为商业开发的内容总量远远超出一个人的能力范畴。制作一个成功的商业三维游戏，在今天需要美术、建模师、关卡设计师、配乐师、游戏设计师，当然，还有程序员。让我们讨论这些情况以及什么办法适合你。

　　独立制作人

　　那么如何才能让自己独立完成一个好游戏呢？首先，你应该担当程序员和设计师。你不得不拥有这些技能使你可以独立开发。那么，让我们假设你已经有了这些技能。下面怎么做？

　　使用现有的引擎来替代那个你需要程序员创建的引擎，从而省略那些写代码的功夫。作为一名出众的程序员，你必须有能力独自应付这类引擎。在网上有很多游戏结构的代码，你可以通过搜索器去查阅它们。例如Quake II, Shogo, Sin, Blood II中的游戏资源，都是可以下载得到的。尽管你不能直接将这些代码用到你的程序中，但是你可以将它们作为写代码时的参考。当然这些游戏或许与你想要的不是同样的类型，但所有的引擎在功能结构上是类似的。

　　为了完成美术部分，你需要纹理和模型。网上可以下载到许多免费的这类资源。最坏的情况，你可以将这些工作以合约的形式包给网上那些热情的美工们。也有很多地方可以直接购买到纹理和模型。

　　为了完成声音部分，你需要背景音乐和音效。有许多工具可以生成音乐，给那些没有能力制作音乐的人，这些工具就象是盒子里的乐队。有许多地方你可以买到唱片音乐和音效，将它们用在不要版税的产品中。最后的办法，你可以和热心的音乐家签约来完成这些音乐和音效。

　　最后，来看看关卡设计。关卡设计是一项成熟的工艺，这意味着不是非常困难，但是你需要实践很长时间才能掌握它。现在多数游戏引擎都配有关卡编辑器，你完全可以使用它们来实践地制作关卡。让自己做的关卡变得更好是你掌握关卡设计这项本领的方法。很多网上的站点上专攻关卡设计的，可以作为你的参考。

　　那么，伴随大量的工作和一些创造性的替代方法，独立制作人就能够制作出漂亮而得体的游戏。

　　团队

　　除了独立制作以外，有其他的途径，就是组建一个团队。队员可能是朋友或者熟人，他们在游戏制作的特定领域中拥有才干。如果你打算建立一个团队，那么最好指定一个人来专门负责决策和项目控制。如果你没有一个强有力的队长，那么你的项目会因为缺乏方向而很容易失败。

　　因为有了互联网的出现，从而有了另一条途径，就是组建网络虚拟社团。就是说你的团队可能分散在世界各个角落，但是他们可以通过互联网保持联络。如果你采用这个办法，那么仔细的选择队员，因为这种工作方式常常会因为人员问题而失败。

　　最后，如果你能够为队员的努力付薪水将是最乐观的情况。尽管很多初始阶段是不能得到薪金支持的，但是如果你有足够的资本，就应该吸引更多的有才能并且乐于奉献的伙伴。如果你不能立即支付，那么至少要在游戏发售后公平地分配利润。这样可以更好地筹措资金，让项目向前发展。

游戏制作入门指南

我经常被问及：一个具有很少甚至没有编程经验的人要如何开始游戏制作。直到目前为止，我总是尽我所能一个一个解答。然而，问题的数量已经增长到了一个难以处理的水平，于是，我便决定把所有的建议汇总在一篇文章里作为参考提供给人们。

　　I often get asked how someone with little or no programming experience can get started in game development. Up until now, I have always tried to help them along as much as I can on a one-to-one basis. However, because the number of questions has grown to an almost unmanageable level lately, I decided it is time for me to put all my advice in an article to serve as a general resource.

　　这篇文章主要面向那些想开发自己的游戏，但仅有一点点或没有半点编程经验的人们。实际上，我也假定读者根本没有任何的编程知识。我将把重点放在游戏开发的编程和设计方面，而不是艺术方面。我也不准备对游戏行业进行论述（因为这个话题的资料太多了），但是，我会带你浏览一下在制作游戏之前需要做的一些事情。该说明的一点是，不要将我这里所介绍的方法当作唯一的或最好的学习游戏制作的路径，但对于我和其他人来说，它是有效的。

　　This article is intended for people who want to make their own games, but who have little or no programming experience. In fact, I'm going to assume the reader has no programming knowledge at all. I will focus mainly on the programming and design aspects of game development, and not the artistic side. I am not going to cover actually getting into the industry (because there are already ample resources for that) but I will walk you through the things you need to do to get to the point that you can make your own games. Finally, the path I lay out here should not be looked at as the only ?or even the best ?route to learning how to make games, but it has worked well for me and for other people.

1、选择一门语言

　 Choosing a Language

　　第一件要做的事就是选择一门语言。你有一大堆的选择，包括 Basic、Pascal、C、C++、Java 等等，同样也有一大堆关于哪门语言最适合初学者的争论。欲了解各种语言的优缺点，请参阅 John Hattan 的绝妙文章《我该使用什么语言》。

　　The first thing you will need to do is to choose a language to program in. You have a lot of choices, including Basic, Pascal, C, C++, Java, etc., and there is a great deal of debate over which language is best for beginners. For a discussion of a number of popular languages, see John Hattan's excellent article, What Language Do I Use?

　　我这里建议使用 C 和 C++。有些人认为这些语言对于初学者来说太难了，但从我个人角度来说我是反对这个观点的，因为我自己就是从 C++ 起步的。另外，C/C++ 是目前最广泛应用的语言，因此，你能找到大量的资料和帮助。至于先学 C 还是先学 C++ 的问题不大，因为一旦你学习了其中一种，再学习另外一种就没太大问题了。不过，如果你一开始就选择 C++，请确信在学习面向对象编程之前，你已经了解并掌握了面向过程编程。（比如说，如果你在不使用类的前提下仍无法编好程序，先不要急于学习类）

　　I'm going to recommend starting with C and C++. Some people will say that those languages are too advanced for beginners, but because I started with C++ myself, I tend to disagree. In addition, C/C++ is the most widely used language today, so you will be able to find a wealth of resources and help. It does not really matter whether you learn C or C++ first, because once you learn one, learning the other will be a trivial matter. However, if you choose to learn C++ first, make sure you understand and can use procedural programming before learning object-oriented programming (i.e. hold off on learning about classes until you can program well without them).

　　如果你发现学习 C/C++ 是一件很困难的事，不要紧，回过头选一门比较简单的语言来学，比如 Basic 或 Pascal。不过我认为，如果你坚持下去，并找一些好的资料，学习 C/C++ 的问题不大。

　　If you start with C/C++ and it turns out to be too difficult, there is nothing wrong with going back and learning a simpler language, such as Basic or Pascal. But I really think that if you stick with it and find the right resources, you should have no problem with C/C++.

　　你的下一个问题是：我如何学习 C/C++？我很高兴你问这个问题。最好的方法是去听课。有没有老师帮助解答问题，对于你的发展影响巨大，而且编程作业将确保你确实掌握了所学的东西。

　　Your next question should be, "How do I learn C/C++?" I'm glad you asked. The best way is to take a class. Having an instructor and TAs available to answer questions and help you along makes a huge difference, and the programming assignments will ensure that you actually apply what you are learning.

　　如果听课不在你的考虑范围内，下一个最好的办法就是找一些好书。不要把注意力放在那些“大全”书上，因为你终究会买几本。我建议你去一个本地书店，花点时间浏览一下介绍 C 和 C++ 的书，直到找到你能理解并能从中学到东西的一本。同时，你可能还想买几本进阶书或是一本参考书，但一旦你具有了这门语言的部分知识，你会对你需要什么有更好主意。可以在网站BOOKS频道中找到一些建议。

　　If taking a class is not an option for you, the next best thing is to get some good books. Don't stress too much about picking the "perfect book", because you are probably going to buy several eventually. I'd suggest going to a local bookstore and spending some time browsing the introductory C and C++ books until you find one that you understand and think you can learn from. In time, you will want to pick up some more advanced books, and probably a reference, but once you have some knowledge of the language, you will have a better idea of what you need. See our books section for some suggestions.

　　在此，我简要的说明一下我见过的很多入门程序员，尤其是年轻人关心的事情：没有钱买书或其他东西。首先，有许多资源是免费的，包括图书馆和 Macmillan Computer Publishing （他们的网站 www.mcp.com 上有数百本编程的书）。其次，如果你想成为一名优秀的程序员，你不得不考虑在这上面的投资。利用各种手段（合法的 ;<）去弄点钞票来。

　　At this point, I want to take a moment and address something that I have seen as a concern for a lot of beginning programmers, especially younger ones: not having money to buy books and other things. First, there are free resources available, including your local library, and Macmillan Computer Publishing, which has hundreds of programming books online at http://www.mcp.com/personal. But second, if you really want to become a good programmer, you have to plan on making an investment in it. Use whatever (legal ;<) means you have to come up with some cash.

　　网络上有大量的 C 和 C++ 的学习教程，但是我认为这些教程作为你学习书本的参考要比作为单独的材料好得多。

　　There are also a number of tutorials available on the web for learning C and C++, but I have found that tutorials are better for supplementing what you learn in books than for being a stand-alone resource.

2、选择合适的编译器

　 Picking the Right Compiler

　　你写的程序，或源码是以文本文件存储的，你甚至可以用记事本来写 C/C++ 程序。但是，必须有样东西能把这些源码转化成一个可执行文件。对于 C 和 C++ 来说，这样东西就是一个编译器。

　　The programs you write, or source code, is stored as a text file, and you can even use Notepad to write a C/C++ program. But something needs to take that source code and convert it into an executable file. In the case of C and C++, that something is a compiler.

　　现在有大量的编译器存在，其中有许多是免费的。选择一个合适的编译器是非常重要的，而免费编译器有个好处就是你能一个一个的试，看哪个你最喜欢。但是，免费编译器经常是比商业编译器功能少或缺少良好的技术支持。幸运的是，大多数商业编译器都有与完整版功能相同，但价格便宜许多的介绍版或学习版，唯一的限制是，你不能发布使用该编译器开发的程序（这点你肯定维持不久）。

　　There are a large number of compilers available, including many free ones. It is important to choose a compiler that you are comfortable with, and the free ones have the advantage that you can try them all out and see which one you like best. However, free compilers are often not as full-featured or well-supported as commercial ones. Fortunately, most commercial compilers come in introductory or academic versions, which cost much less and usually have the same features as the full version, with the only restriction being that you cannot distribute programs you create using it (which you are not going to be doing for a while anyway).

　　基本上，你选择什么样的编译器取决于你能花多少钱、你将在什么操作系统和平台上开发程序。如果你准备为 Windows 作贡献，我强烈建议使用微软的 Visual C++。它具有一个功能强大的开发环境，能让你倍感轻松，再也没有其他编译器能比它更适合开发 Windows 软件了。如果你是名学生，你可以以极低的价格获得一份拷贝。如果你准备在 DOS 下开发程序，你最好使用免费的 DJGPP。

　　Ultimately, the compiler you choose will depend on how much you can spend and which operating system and platform you will be developing for. If you are going to be developing for Windows, I strongly suggest using Microsoft Visual C++. It has a powerful development environment that will make a lot of things easier for you, and there is no question that no other compiler is more well-suited to developing Windows applications. If you are a student, you can obtain a copy for a significantly reduced price. If you are going to program in DOS, your best bet is probably DJGPP, which is free.

3、选择一个目标平台

　 Choosing a Target Platform

　　虽然你可能最终会为各种平台开发程序，你还是应该选择其中之一进行学习。当你学习语言的时候，在没进入图象编程之前，你大概想使用一个非 GUI 的操作系统，比如 DOS 或 UNIX。这有助于你将注意力集中在语言学习上，从而避开一些高层的问题，如 Windows 编程。

　　Although you will probably develop for a number of platforms eventually, you are going to need to pick one to learn in. While you are learning the language, and before you get into any programming involving graphics, you will probably want to use a non-GUI operating system, such as DOS or UNIX. These will avoid the overhead involved with, for example, Windows programming, and let you just focus on learning the language.

　　不过，一旦你准备开始制作游戏，你就该考虑转换你的目标平台了。一下是几个常用的平台：

　　Once you are ready to start making games, though, you should consider changing your target platform. Let's look at the more prominent options.

　　Windows：如果你想在游戏行业里专职工作，或者你想让一大群人玩你的游戏，那么 Windows 是你的首选。你的目标客户大多数使用 Windows，且这个情况不会很快改变。目前大量的 Windows 游戏使用一种你大概听说过的名为 DirectX 的技术。DirectX 是一个允许你直接操作硬件的程序库，你可以依靠它写出高性能的游戏来。

　　Windows: If you want to eventually work professionally in the games industry, or if you just want a lot of people to be able to play your game, then this is the platform you want to choose. The majority of your target audience uses Windows, and I don't see that changing any time soon. The vast majority of games today are made for Windows using a technology you have probably heard of called DirectX. DirectX is a library that allows you to access the hardware directly, which means you can write high-performance games.

　　DOS：DOS 曾经是游戏的主要平台，但这已是昨日黄花。虽然有些爱好者仍然在为 DOS 开发游戏，但是已经没有商业游戏是为 DOS 开发的了，而且， DOS 正由于微软停止对它的支持而走向衰败。如果你刚开始做游戏，别选择 DOS，如果你已经这样做了，不要再停留了。注意：因为有很多游戏编程的书是为 DOS 写的，学习这些书时可能会认为在 DOS 里开发游戏有理有据。但是，随着 Windows 游戏编程书籍数量的增长，这种争论变得越来越少，也越来越没有意义。

　　DOS: DOS used to be the dominant platform for games, but those days are gone. Although some hobbyists are still making games for DOS, no commercial games are being made for DOS, and it will continue to decline as Microsoft stops supporting it. If you are just starting to make games, don't choose DOS, or if you do, don't stay with it for long. Note: because there are a large number of game programming books written specifically for DOS, there may be some justification to developing games in DOS while learning from these books. However, as the number of books for game programming in Windows grows, this argument becomes less and less valid.

　　Linux：Linux 是 UNIX 的一个变种，由于它具有稳定、便宜、反微软情节等多个因素，它正变得越来越受欢迎。虽然目前的 Linux 用户还比较少，但是随着它的热爱者和市场的潜在增长，它也成为了作为目标平台的可行选择。

　　Linux: Linux is a UNIX variant that has become popular lately for a number of reasons, including stability, price, and anti-Microsoft sentiment. Although the number of Linux users is still relatively small, the enthusiasm surrounding it and the potential growth of the market make it an viable choice as a target platform.

　　Macintosh：苹果机拥有一群数量不多但非常忠诚的追随者，几乎每个我见过的苹果机爱好者都有一个强烈渴望更多苹果机游戏的愿望。我没有看过多少在苹果机上开发游戏的资料，但我确信确实有，因此，这也是个合理的选择。

　　Macintosh: The Mac has a very loyal following in numbers that are not insignificant, and nearly every Mac enthusiast I have talked to has expressed a desire for more and better games for the Macintosh. I have not seen as many resources for making games for the Mac, but I am sure they are out there, so this may be a valid option too.

　　家庭游戏机：游戏机（如 Playstation、N64、Dreamcast 等等）游戏市场非常巨大，前景可观。然而，由于种种原因，开发非商业性的游戏机游戏在目前来说是不太可能的。你为游戏机开发的游戏大多都会被商业游戏公司买走。

　　Consoles: The console (i.e. Playstation, N64, Dreamcast, etc.) game market is huge, and there is certainly a future in console game development. However, developing console games in a non-commercial setting is not really plausible at this time, for a number of reasons. If you develop for consoles, it will probably be while employed by a commercial game studio.

4、充足电

　 On to the Good Stuff

　　是讨论真正做游戏的时候了。虽然我所说的大部分内容适用于其他语言，为简单起见，我将假定你选择了 C/C++ 来进行 Windows 编程。

　　Now it's time to discuss actually making games. For simplicity, I'm going to assume that you have chosen to program in C/C++ for Windows, although most of what I say will apply if you chose otherwise.

　　首先，在你考虑如何开始做游戏之前，你应该能很好的掌握 C 和 C++。你应该了解并精通指针、阵列、结构、函数，以及类等。做到了这一点，你就可以开始制作游戏了。

　　First of all, before you even think about starting to make games, you should have a good command of C and C++. You should understand pointers, arrays, structures, functions, and probably classes, and you should be proficient in using them. If so, you are ready to start making games.

　　本文无法教授你关于制作游戏所该了解的一切。幸运的是，这也不是必要的。有很多关于这方面的书，网上也有数以百计的教程。GameDev.net 应该会有目前你所需要的一切。下面是我对你起步的一些建议：

　　This article can't possibly teach you everything you need to know about making games. Fortunately, it doesn't have to. There are many books on the subject, and hundreds of tutorials on the web. GameDev.net should have everything you need right here. Here's how I suggest you start:

学习一本或几本书。对于 Windows 游戏的初学程序员，《Tricks of the Windows Game Programming Gurus 》是一本极好的Windows编程入门教程。在这个站点里拥有许多本站 Books section 里所列出的好书。阅读这些书籍，运行所有的例程，反复研读你不理解的章节。

使用网上教程补充书本的不足。书本除了阐明一些你阅读的东西外，通常也会包含一些书本上没有涉及的主题。

找专家进行咨询。如果你无法从书上或教程中找到答案，到本站的留言版或聊天室来，这里有许多乐于提供帮助的人。

Get one or more books. For beginning game programmers in Windows, Tricks of the Windows Game Programming Gurus is the perfect place to start. Besides that, there are a number of other good books in our Books section. Read through the books, trying all the examples, and rereading parts you don't understand.

Supplement what you read with online tutorials. Besides clarifying things you read, they also cover topics not covered in books.

Ask the experts for help. If you cannot find answers to your questions in books or tutorials, take advantage of our message board and chat room. There are a lot of people out there willing to help out.

　　不要把上面几点当成是个有序的过程，而应当看作是一个循环往复的并行过程。

　　This should not be looked at as a sequential process, but as a silmultaneous process that is repeated continually.

　　仅仅是学习、思考是远远不够的，你应当把你所学的东西付诸实践。从一个简单的游戏开始，逐步发展。你可以阅读一下 Geoff Howland 的文章《How do I Make Games? A Path to Game Development》。

　　It is not enough to just learn, though, you must apply what you learn. Start off with a simple game, and work up from there. See Geoff Howland's article, How do I Make Games? A Path to Game Development.

　　首先，为自己的工作制定一个计划。不要急于加入一个团队，因为那只会减缓你的学习进程。当你囊中拥有数个游戏时，你将为一个团队作出更大贡献。

　　At first, plan on working on your own. Don't rush to join a team, because it will only slow down the learning process. Once you have several games under your belt, you can make a much larger contribution to a team anyway.

　　关于书本，有件事我要提醒一下：你需要阅读除了游戏编程外的其他书籍。为了制作出你在商店货价里看到的各种游戏，你将不得不钻研那些比大多数游戏编程书籍所授内容更高深的话题。有些可能你能从教程中找到，但是，你还是有必要买几本关于图形、人工智能、网络、物理等等方面的书。这是获得计算机科学学位的必经之路，因为你将被要求学习一些你认为与游戏编程无关的课程，而实际上它们是相关的。

　　One thing I'd like to mention about books: You will need to read more than just game programming books. To be able to create the kinds of games you see on store shelves, you are going to have to delve into topics more advanced than those covered in most game programming books. Some of what you need can be found in tutorials, but you are also going to need to pick up some books on graphics, artificial intelligence, networking, physics, and so on. This is where pursuing a degree in Computer Science comes in handy, because you will be required to take classes that you may think don't apply to game programming, but they do.

5、总结

　 Wrapping Up

　　这里有一些能产生巨大差别的技巧：

　　Here's a few more tips that can make a huge difference:

要只知道聚集知识，应用是关键。除非你使用了，否则你无法确实知道和理解这些东西。做一些小的测试程序来应用你所学的东西，并切实完成书上每个章节后的习题。

玩大量的游戏。你会因此找到灵感，从而帮助你制作更优秀的游戏。当然，这也是一种受欢迎的解除编程压力的调剂方式。

帮助别人。在你帮助别人的过程中，你会学到更多东西。

完成你的作品。不要陷入这样一种思想的圈套中：“我知道我可以完成这个游戏，但是我有个更好的主意，我要换做这个好的项目。”如果你能坚持有始有终，你会学到更多的东西，并且你有作品证明你不仅仅是空谈。在你具有丰富的经验之前，做得简单一点，不要尝试制作一个又大又复杂的游戏。

Don't just accumulate knowledge, apply it. You will never really know or understand something until you use it. Make little demo programs that use the things you are learning. Actually do the exercises at the end of the chapters in the books.

Play a lot of games. Doing so will give you ideas and help you make better games. It will also provide a welcome relief from programming.

Finish what you start. Don't fall into the trap of thinking "I know I can finish this game, but I have an idea for a better one, so I'll move on to it instead." You will learn so much more if you

finish the games you start, and you will have something to prove that you are not all talk. To make this a little easier, don't try to make really big or complex games until you are more experienced.

　　出发吧！你该动手制作 Quake 4 了。当然，可能不那么容易，但至少你可以从这个方向出发，并且知道去哪里查找更多的信息。经过多年的努力工作，你会成功的！

　　There you go! You should now be well on your way to making Quake 4. Well, not quite, but at least you can start on that path and know where to look for more information, and with years of hard work, it can happen.

--------------------------------------------------------------------------------

　　作者简介

　　Dave Astle 从 1984 年开始制作电脑游戏。白天他在 ROI Systems 公司任软件工程师，晚上他领导 Myopic Rhino Games 的开发小组。有时他也抽空来帮帮 GameDev.net ，使其成为同行中的佼佼者。有时间他也需要休息了。

非常好

我该使用何种语言

　　目 录

　　1 C语言

　　2 C++

　　3 C++与C的抉择

　　4 汇编语言

　　5 Pascal语言

　　6 Visual Basic

　　7 Java

　　8 创作工具

　　9 结论

--------------------------------------------------------------------------------

　　原 文：What Language Do I Use

　　译 者：Sunlxy

　　版 本：the first edition（Ver 1.0）

--------------------------------------------------------------------------------

　　这是每个游戏编程FAQ里都有的问题。这个问题每星期都会在游戏开发论坛上被问上好几次。这是个很好的问题，但是，没人能给出简单的答案。在某些应用程序中，总有一些计算机语言优于其他语言。下面是几种用于编写游戏的主要编程语言的介绍及其优缺点。希望这篇文章能帮助你做出决定。

　　This is a question that belongs in every game programming FAQ. It seems to be asked in a game development forum several times a week. It's a good question, though, and not one with an easy answer. There are computer languages that work better for some applications than others. Here is a list of the major programming languages used to write games along with descriptions, advantages, and disadvantages. Hopefully this list will help you make a decision.

1、C语言

　　如果说FORTRAN和COBOL是第一代高级编译语言，那么C语言就是它们的孙子辈。C语言是Dennis Ritchie在七十年代创建的，它功能更强大且与ALGOL保持更连续的继承性，而ALGOL则是COBOL和FORTRAN的结构化继承者。C语言被设计成一个比它的前辈更精巧、更简单的版本，它适于编写系统级的程序，比如操作系统。在此之前，操作系统是使用汇编语言编写的，而且不可移植。C语言是第一个使得系统级代码移植成为可能的编程语言。

　　If FORTRAN and COBOL were the first compiled high-level languages, then C is their grandchild. It was created in the 70's by Dennis Ritchie as a tighter and more coherent successor to ALGOL, which was a structured successor to COBOL and FORTRAN. It was designed to be a smaller and simpler version of its predecessors, suitable for writing system-level programs, like operating systems. Before then, operating systems were hand-coded in assembly and were not portable. C was the first programming language that made portability a reality for system-level code.

　　C语言支持结构化编程，也就是说C的程序被编写成一些分离的函数呼叫（调用）的集合，这些呼叫是自上而下运行，而不像一个单独的集成块的代码使用GOTO语句控制流程。因此，C程序比起集成性的FORTRAN及COBOL的“空心粉式代码”代码要简单得多。事实上，C仍然具有GOTO语句，不过它的功能被限制了，仅当结构化方案非常复杂时才建议使用。

　　C is a language that supports structured programming. That is to say that C programs are written as collections of disconnected function calls that run top-down rather than a single monolithic block of code with program control-flow happening via GOTO statements. Hence, C programs are generally easier to follow than monolithic FORTRAN and COBOL spaghetti-code. Actually, C still has a GOTO statement, but its functionality is limited and it is only recommended as a last resort if structured solutions are much more complicated.

　　正由于它的系统编程根源，将C和汇编语言进行结合是相当容易的。函数调用接口非常简单，而且汇编语言指令还能内嵌到C代码中，所以，不需要连接独立的汇编模块。

　　True to its system-programming roots, it is fairly easy to interface C with assembly languages. The function-calling interface is very simple, and assembly language instructions can be embedded within C code, so linking in separate assembly-language modules is not necessary.

　　优点：有益于编写小而快的程序。很容易与汇编语言结合。具有很高的标准化，因此其他平台上的各版本非常相似。

　　Advantages: Good for writing small fast programs. Easy to interface with assembly language. Very standardized, so versions on other platforms are similar.

　　缺点：不容易支持面向对象技术。语法有时会非常难以理解，并造成滥用。

　　Disadvantages: Does not easily support object-oriented techniques. Syntax can be difficult and lends itself to abuse.

　　移植性：C语言的核心以及ANSI函数调用都具有移植性，但仅限于流程控制、内存管理和简单的文件处理。其他的东西都跟平台有关。比如说，为Windows和Mac开发可移植的程序，用户界面部分就需要用到与系统相关的函数调用。这一般意味着你必须写两次用户界面代码，不过还好有一些库可以减轻工作量。

　　Portability: While the core of the language and the ANSI function calls are very portable, they are limited to control-flow, memory management, and simple file-handling. Everything else is platform-specific. Making a program that's portable between Windows and the Mac, for instance, requires that the user-interface portions be using system-specific function calls. This generally means that you need to write the user-interface code twice. There are libraries, though, that make the process a bit easier.

　　用C语言编写的游戏：非常非常多。

　　Games Written in C: Lots and lots.

　　资料：C语言的经典著作是《The C Programming Language》，它经过多次修改，已经扩展到最初的三倍大，但它仍然是介绍C的优秀书本。一本极好的教程是《The Waite Group's C Primer Plus》。

　　Resources: The classic book about C is [The C Programming Language].It's gone through several iterations and has expanded to about three times its original size, but it's still a good introduction to the language. An excellent tutorial is [The Waite Group's C Primer Plus].

2、C++

　　C++语言是具有面向对象特性的C语言的继承者。面向对象编程，或称OOP是结构化编程的下一步。OO程序由对象组成，其中的对象是数据和函数离散集合。有许多可用的对象库存在，这使得编程简单得只需要将一些程序“建筑材料”堆在一起（至少理论上是这样）。比如说，有很多的GUI和数据库的库实现为对象的集合。

　　C++ is the object-oriented successor to C. Object-oriented, or OO, programs are the next step beyond structured programming. OO programs are built out of objects, which are packages of data and functions collected into discrete units. There are many libraries of objects available that make writing programs as simple as pulling together a collection of program "building blocks" (at least in theory). For example, there are many GUI and database libraries that are implemented as collections of objects.

　　C++总是辩论的主题，尤其是在游戏开发论坛里。有几项C++的功能，比如虚拟函数，为函数呼叫的决策制定增加了一个额外层次，批评家很快指出C++程序将变得比相同功能的C程序来得大和慢。C++的拥护者则认为，用C写出与虚拟函数等价的代码同样会增加开支。这将是一个还在进行，而且不可能很快得出结论的争论。

　　C++ is the subject of controversy, especially in the game development community. There are features of C++, like virtual functions, that add an extra layer of decision-making to function calls, and critics are quick to point out that C++ programs can be larger and slower than C counterparts. C++ advocates point out, however, that coding the equivalent of a virtual function in C requires the same overhead. It's an on-going debate that's not likely to be decided soon.

　　我认为，C++的额外开支只是使用更好的语言的小付出。同样的争论发生在六十年代高级程序语言如COBOL和FORTRAN开始取代汇编成为语言所选的时候。批评家正确的指出使用高级语言编写的程序天生就比手写的汇编语言来得慢，而且必然如此。而高级语言支持者认为这么点小小的性能损失是值得的，因为COBOL和FORTRAN程序更容易编写和维护。

　　In my opinion, the overhead of C++ is simply the price you pay for a better language. This same debate went on in the 60's when high-level programming languages like COBOL and FORTRAN started to displace hand-coded assembly as the language of choice. Critics correctly pointed out that programs written in high-level languages were inherently slower than hand-tuned assembly and always would be. High-level language advocates pointed out, however, that the slight performance hit was worth it because COBOL and FORTRAN programs were much easier to write and maintain.

　　优点：组织大型程序时比C语言好得多。很好的支持面向对象机制。通用数据结构，如链表和可增长的阵列组成的库减轻了由于处理低层细节的负担。

　　Advantages: Much better than C for organizing large programs. Supports the object-oriented paradigm nicely. Libraries of common data structures, like linked lists and grow-able arrays, can remove much of the burden of having to deal with low-level details.

　　缺点：非常大而复杂。与C语言一样存在语法滥用问题。比C慢。大多数编译器没有把整个语言正确的实现。

　　Disadvantages: Extremely large and complicated. Like C, the syntax lends itself to abuse. Can be slower than C. Not many compilers implement the entire language correctly.

　　移植性：比C语言好多了，但依然不是很乐观。因为它具有与C语言相同的缺点，大多数可移植性用户界面库都使用C++对象实现。

　　Portability: Better than C, but still not great. While it shares the same disadvantage as C, most of the portable user-interface libraries are implemented as collections of C++ objects.

　　使用C++编写的游戏：非常非常多。大多数的商业游戏是使用C或C++编写的。

　　Games Written in C++: Lots and lots. Almost all commercial games are written in C or C++.

　　资料：最新版的《The C++ Programming Language》非常好。作为教程，有两个阵营，一个假定你知道C，另外一个假定你不知道。到目前为止，最好的C++教程是《Who's Afraid of C++》，如果你已经熟知C，那么试一下《Teach Yourself C++》。

　　Resources: The latest edition of The C++ Programming Language is excellent. As for tutorials, there are two camps, ones that assume you know C, and ones you don't. By far the best ground-up C++ tutorials are Who's Afraid of C++ and Who's Afraid of More C++. If you already know C, try Teach Yourself C++.

3、我该学习C++或是该从C开始（Should I learn C++, or should I start with C ）

　　我不喜欢这种说法，但它是继“我该使用哪门语言”之后最经常被问及的问题。很不幸，不存在标准答案。你可以自学C并使用它来写程序，从而节省一大堆的时间，不过使用这种方法有两个弊端：

　　I thought this bore mentioning, as it's the second most commonly asked question next to "which programming language should I use?"Unfortunately, the answer isn't black and white. You could save a lot of time by just teaching yourself C and writing apps, but there are two disadvantages to this approach.

你将错过那些面向对象的知识，因为它可能在你的游戏中使得数据建模更有效率的东西。

You're missing out on what will likely be a much more effective way of modeling the data in your game. By not learning OO programming off the bat, you could be enforcing bad programming habits that you'll have to un-learn later. Trust me on this one.

最大的商业游戏，包括第一人称射击游戏很多并没有使用C++。但是，这些程序的作者即使使用老的C的格式，他们通常坚持使用面向对象编程技术。如果你只想学C，至少要自学OO（面向对象）编程技术。OO是仿真（游戏）的完美方法，如果你不学习OO，你将不得不“辛苦”的工作。

Many of the biggest commercial games, including most first-person shooters, get by without C++. The authors of these programs, however, always insist that they're using object-oriented programming techniques even though they're using plain old C. If you want to just learn C, at least teach yourself OO programming techniques. OO is the perfect methodology for simulations (read: games), and you'll really be doing it "the hard way" if you push off learning OO.

4、汇编语言（Assembly）

　　显然，汇编是第一个计算机语言。汇编语言实际上是你计算机处理器实际运行的指令的命令形式表示法。这意味着你将与处理器的底层打交道，比如寄存器和堆栈。如果你要找的是类英语且有相关的自我说明的语言，这不是你想要的。

　　By default, assembly was the first computer language. Assembly language is actually a command-based representation of the actual instructions that your computer's processor runs. That means you will be dealing with the low-level details of your processor, like registers and stacks. If you're looking for a language that's English-like and is relatively self-documenting, this isn't it!

　　确切的说，任何你能在其他语言里做到的事情，汇编都能做，只是不那么简单 ― 这是当然，就像说你既可以开车到某个地方，也可以走路去，只是难易之分。话虽不错，但是新技术让东西变得更易于使用。

　　By definition, anything you can do in any other language, you can do in assembly, only not as easily --of course, that's like saying that anywhere you can go in a car, you can go on foot, only not as easily. While the statement might be true, the later technologies made things much easier to use.

　　总的来说，汇编语言不会在游戏中单独应用。游戏使用汇编主要是使用它那些能提高性能的零零碎碎的部分。比如说，毁灭战士整体使用C来编写，有几段绘图程序使用汇编。这些程序每秒钟要调用数千次，因此，尽可能的简洁将有助于提高游戏的性能。而从C里调用汇编写的函数是相当简单的，因此同时使用两种语言不成问题。

　　In general, assembly language is not used on its own for games. Games that use assembly language use it in bits and pieces where it can improve performance. For example, DOOM is written entirely in C with a couple of drawing routines hand-coded in assembly. They are the routines that are called a few thousand times a second, so making the routine as tight as possible really helped the performance of the game. It's fairly easy to write a function in assembly that is call-able from C, so using both languages wasn't a problem.

　　特别注意：语言的名字叫“汇编”。把汇编语言翻译成真实的机器码的工具叫“汇编程序”。把这门语言叫做“汇编程序”这种用词不当相当普遍，因此，请从这门语言的正确称呼作为起点出发。

　　Special Note: The name of the language is "assembly". The name of the tool that converts assembly language into true machine code is called an "assembler". It's a common misnomer to call the language "assembler", so start out on the right foot by calling the language by its proper name.

　　优点：最小、最快的语言。汇编高手能编写出比任何其他语言能实现的快得多的程序。你将是利用处理器最新功能的第一人，因为你能直接使用它们。

　　Advantages: Is, by definition, the smallest and fastest language. A talented assembly programmer can write programs that are faster than anything that can be done in other languages. You'll be the first person to be able to take advantage of the processor's latest new features, because you can use them directly.

　　缺点：难学、语法晦涩、坚持效率，造成大量额外代码 ― 不适于心脏虚弱者。

　　Disadvantages: Difficult to learn, cryptic syntax, tough to do efficiently, and it takes much more code to get something done --not for the faint of heart!

　　移植性：接近零。因为这门语言是为一种单独的处理器设计的，根本没移植性可言。如果使用了某个特殊处理器的扩展功能，你的代码甚至无法移植到其他同类型的处理器上（比如，AMD的3DNow指令是无法移植到其它奔腾系列的处理器上的）。

　　Portability: Zilch. Since the language is designed for a single processor, it is not portable by definition. If you use extensions specific to a particular brand of processor, your code isn't even portable to other processors of the same type (for example, AMD 3DNOW instructions are not portable to other Pentium-class processors).

　　使用汇编编写的游戏：我不知道有什么商业游戏是完全用汇编开发的。不过有些游戏使用汇编完成多数对时间要求苛刻的部分。

　　Games Written in Assembly: I don't know of any commercial games that are written entirely in assembly. Some games, however, have the most time-critical portions done in assembly.

　　资料：如果你正在找一门汇编语言的文档，你主要要找芯片的文档。网络上如Intel、AMD、Motorola等有一些关于它们的处理器的资料。对于书籍而言，《Assembly Language: Step-By-Step》是很值得学习的。

　　Resources: When you're looking for documentation for an assembly language, you're basically looking for the documentation for the chip. There is some online information at [Intel], [AMD][Motorola] for their processors. As for books, [Assembly Language: Step-By-Step] is well-reviewed.

5、Pascal语言

　　Pascal语言是由Nicolas Wirth在七十年代早期设计的，因为他对于FORTRAN和COBOL没有强制训练学生的结构化编程感到很失望，“空心粉式代码”变成了规范，而当时的语言又不反对它。Pascal被设计来强行使用结构化编程。最初的Pascal被严格设计成教学之用，最终，大量的拥护者促使它闯入了商业编程中。当Borland发布IBM PC上的 Turbo Pascal时，Pascal辉煌一时。集成的编辑器，闪电般的编译器加上低廉的价格使之变得不可抵抗，Pascal编程了为MS-DOS编写小程序的首选语言。

　　Pascal was designed by Nicolas Wirth in the early 70's, because he was dismayed to see that FORTRAN and COBOL were not enforcing healthy structured programming disciplines in students. "Spaghetti code" was becoming the norm, and the languages of the time weren't discouraging it. Pascal was designed from the ground up to enforce structured programming practices. While the original Pascal was designed strictly for teaching, it had enough advocates to eventually make inroads into commercial programming. Pascal finally took the spotlight in a big way when Borland released Turbo Pascal for the IBM PC. The integrated editor, lightning-fast compiler, and low price were an irresistible combination, and Pascal became the preferred language for writing small programs for MS-DOS.

　　然而时日不久，C编译器变得更快，并具有优秀的内置编辑器和调试器。Pascal在1990年Windows开始流行时走到了尽头，Borland放弃了Pascal而把目光转向了为Windows 编写程序的C++。Turbo Pascal很快被人遗忘。

　　The momentum, however, did not stay. C compilers became faster and got nice built-in editors and debuggers. The almost-final nail in Pascal's coffin happened in the early 1990's when Windows took over, and Borland ignored Pascal in favor of C++ for writing Windows applications. Turbo Pascal was all but forgotten.

　　最后，在1996年，Borland发布了它的“Visual Basic杀手”― Delphi。它是一种快速的带华丽用户界面的 Pascal编译器。由于不懈努力，它很快赢得了一大群爱好者。

　　Finally, in 1996, Borland released its "Visual Basic Killer", Delphi. Delphi was a fast Pascal compiler coupled with a gorgeous user interface. Against all odds (and the Visual Basic juggernaut), it gained a lot of fans.

　　基本上，Pascal比C简单。虽然语法类似，它缺乏很多C有的简洁操作符。这既是好事又是坏事。虽然很难写出难以理解的“聪明”代码，它同时也使得一些低级操作，如位操作变得困难起来。

　　On the whole, Pascal is simpler than C. While the syntax is similar, it lacks a lot of the shortcut operations that C has. This is a good thing and a bad thing. It's harder to write inscrutable "clever" code, but it makes low-level operations like bit-manipulation more difficult.

　　优点：易学、平台相关的运行（Dephi）非常好。

　　Advantages: Easy to learn. Platform-specific implementations (Delphi) are very nice.

　　缺点：“世界潮流”面向对象的Pascal继承者（Modula、Oberon）尚未成功。语言标准不被编译器开发者认同。专利权。

　　Disadvantages: "World class" OO successors to Pascal (Modula, Oberon) have not been successful. Language standards are not adhered to by compiler-makers. Proprietary.

　　移植性：很差。语言的功能由于平台的转变而转变，没有移植性工具包来处理平台相关的功能。

　　Portability: Dismal. The features of the language changes from platform to platform, and there are no portability toolkits to handle platform-specific features.

　　使用Pascal编写的游戏：几个。DirectX的Delphi组件使得游戏场所变大了。

　　Games Written in Pascal: A couple. The DirectX components for Delphi have made the playing field more level.

　　资料：查找跟Delphi有关的资料，请访问：Inprise Delphi page。

　　Resources: The find out about Delphi, check out the Inprise Delphi page.

6、Visual Basic

　　哈，BASIC。回到八十年代的石器时代，它是程序初学者的第一个语言。最初的BASIC形式，虽然易于学习，却是可怕的无组织化，它义无返顾的使用了GOTO充斥的“空心粉式代码”。当回忆起BASIC的行号和GOSUB命令，没有几个人能止住眼角的泪水。

　　Ahh, BASIC. Way back in the stone-age of the 80's, it was the first language for budding programmers. The original incarnations of BASIC, while easy to learn, were horribly unstructured, leading to the a rash of GOTO-laden "spaghetti-code". Not many people wipe away tears when reminiscing about BASIC's line numbers and the GOSUB command.

　　快速前进到九十年代早期，虽然不是苹果公司所希望的巨人，HyperCard仍然是一个在Windows下无法比拟的吸引人的小型编程环境。Windows下的HyperCard克隆品如ToolBook又慢又笨又昂贵。为了与HyperCard一决高下，微软取得了一个小巧的名为Thunder编程环境的许可权，并把它作为Visual Basci 1.0发布，其用户界面在当时非常具有新意。这门语言虽然还叫做Basic（不再是全部大写），但更加结构化了，行号也被去除。实际上，这门语言与那些内置于TRS-80、Apple II及Atari里的旧的ROM BASIC相比，更像是带Basic风格动词的Pascal。

　　Fast-forward to the early 1990's. While not the monster that Apple was hoping for, HyperCard was a compelling little programming environment that had no equal under Windows. Windows-based HyperCard clones like ToolBook were slow, clunky, and expensive. To finally compete with HyperCard, Microsoft licensed a neat little programming environment named Thunder, releasing it as Visual Basic 1.0. The user-interface was very innovative for the time. The language, while still called Basic (and no longer all-caps), was much more structured. Line numbers were mercy-killed. The language was, in fact, much closer to Pascal with Basic-style verbs than the old ROM BASIC that was built into every TRS-80, Apple ][, and Atari.

　　经过六个版本，Visual Basic变得非常漂亮。用户界面发生了许多变化，但依然保留着“把代码关联到用户界面”的主旨。这使得它在与即时编译结合时变成了一个快速原型的优异环境。

　　Six versions later, Visual Basic is pretty deluxe. The user-interface has made some changes, but still retains its "attach bits of code to the user-interface" motif. This, in combination with instantaneous compiling, makes it a terrific environment for fast prototyping.

　　优点：整洁的编辑环境。易学、即时编译导致简单、迅速的原型。大量可用的插件。虽然有第三方的DirectX插件，DirectX 7已准备提供Visual Basic的支持。

　　Advantages: Neat IDE. Easy to learn. Instantaneous compiling makes for very fast and easy prototyping. Lots and lots of add-ons available. While there are currently third-party DirectX add-ons for Visual Basic, DirectX version 7 is going to include support for Visual Basic right out of the box.

　　缺点：程序很大，而且运行时需要几个巨大的运行时动态连接库。虽然表单型和对话框型的程序很容易完成，要编写好的图形程序却比较难。调用Windows的API程序非常笨拙，因为VB的数据结构没能很好的映射到C中。有OO功能，但却不是完全的面向对象。专利权。

　　Disadvantages: Apps are large and require several large runtime DLL's to run. While form and dialog-based apps are easy to make, writing good graphical apps is more difficult. Calling Windows API functions is clunky, because VB data structures don't map nicely to C. Has OO features, but is not fully object-oriented. Proprietary.

　　移植性：非常差。因为Visual Basic是微软的产品，你自然就被局限在他们实现它的平台上。也就是说，你能得到的选择是：Windows，Windows或Widnows。当然，有一些工具能将VB程序转变成Java。

　　Portability: Worse than dismal. Since Visual Basic is owned by Microsoft, you're pretty-much limited to whatever platforms they've ported it too. That means that you've got the choice of Windows, Windows, or Windows. Note that there are, however, a couple of tools that help convert VB apps to Java.

　　使用Visual Basic编写的游戏：一些。有很多使用VB编写的共享游戏，还有一些是商业性的。

　　Games Written in Visual Basic: A few. There are lots of shareware games done in VB, and a couple of commercial offerings.

　　资料：微软的VB页面有一些信息。

　　Resources: The [Microsoft VB page].

7、Java

　　Java是由Sun最初设计用于嵌入程序的可移植性“小C++”。在网页上运行小程序的想法着实吸引了不少人的目光，于是，这门语言迅速崛起。事实证明，Java不仅仅适于在网页上内嵌动画 ― 它是一门极好的完全的软件编程的小语言。“虚拟机”机制、垃圾回收以及没有指针等使它很容易实现不易崩溃且不会泄漏资源的可靠程序。

　　Java was originally designed by Sun to be a portable "small C++" that could be used in embedded applications. The idea of running little applications in a web-page really captured people's imaginations, so the language caught on quickly. It turned out that Java wasn't just suitable for embedding animated banners in web pages --it was a downright nifty little language for application programming! The "virtual machine" nature, garbage collection and lack of pointers made it easy to make bulletproof apps that didn't crash and had no resource leaks.

　　虽然不是C++的正式续篇，Java从C++ 中借用了大量的语法。它丢弃了很多C++的复杂功能，从而形成一门紧凑而易学的语言。不像C++，Java强制面向对象编程，要在Java里写非面向对象的程序就像要在Pascal里写“空心粉式代码”一样困难。

　　While not an official "sequel" to C++, Java borrows very heavily from C++ syntax. It dumps many of the more difficult C++ features to reveal a rather compact and easy-to-learn language. Unlike C++, Java enforces object-orientation with a heavy hand. Writing a non-OO app in Java is as difficult as writing spaghetti-code in Pascal.

　　优点：二进制码可移植到其他平台。程序可以在网页中运行。内含的类库非常标准且极其健壮。自动分配合垃圾回收避免程序中资源泄漏。网上数量巨大的代码例程。

　　Advantages: Binaries are portable to other platforms. Apps can run embedded in web pages. The included class library is reasonably standardized and extremely robust. Automatic allocation and garbage collection all but eliminates resource leaks in applications. Zillions of code examples on the web.

　　缺点：使用一个“虚拟机”来运行可移植的字节码而非本地机器码，程序将比真正编译器慢。有很多技术（例如“即时”编译器）很大的提高了Java的速度，不过速度永远比不过机器码方案。早期的功能，如AWT没经过慎重考虑，虽然被正式废除，但为了保持向后兼容不得不保留。越高级的技术，造成处理低级的机器功能越困难，Sun为这门语言增加新的“受祝福”功能的速度实在太慢。

　　Disadvantages: Uses a "virtual machine" to run portable byte-code rather than native machine code, so apps are slower than true compilers. There are technologies (like "Just In Time" compilers) that greatly improve the speed of Java, but the speed will likely always lag behind true machine-code solutions. Early features like the Abstract Windowing Toolkit were not well thought-out and, while officially abandoned, have to hang around for backward compatibility. Is very high-level, which makes dealing with any low-level machine features very difficult. Sun is pretty slow in adding new "blessed" features to the language.

　　移植性：最好的，但仍未达到它本应达到的水平。低级代码具有非常高的可移植性，但是，很多UI及新功能在某些平台上不稳定。

　　Portability: The best of the lot, but still not what it should be. The low-level code is very portable, but a lot of the UI and newer features are wobbly on some platforms.

　　使用Java编写的游戏：网页上有大量小的Applet，但仅有一些是商业性的。有几个商业游戏使用Java作为内部脚本语言。

　　Games Written in Java: Lots of little applets in web pages, but only a couple of commercial offerings. Several commercial games use Java as the internal script language.

　　资料：Sun的官方Java页面有一些好的信息。IBM也有一个非常好的Java页面。JavaLobby是一个关于Java新闻的最好去处。

　　Resources: [Sun's official Java page] has some good info. IBM also has an excellent [Java page]. The [JavaLobby] is the best place to go for news about Java.

8、创作工具

　　上面所提及的编程语言涵盖了大多数的商业游戏。但是也有一个例外，这个大游戏由于它的缺席而变得突出。

　　All of the programming languages mentioned above cover pretty-much every commercial game out there. There is one exception, but it's such a big one that it would be conspicuous by its absence.

　　“神秘岛”。没错，卖得最好的商业游戏不是使用以上任何一门语言编的，虽然有人说“神秘岛”99%是使用 3D建模工具制作的，其根本的编程逻辑是在HyperCard里完成的。

　　Yep, the best selling commercial game of all time wasn't written in any of the above languages. While some would say that 99% of Myst was written using 3D modeling tools, the underlying program logic was done in HyperCard.

　　多数创作工具有点像Visual Basic，只是它们工作在更高的层次上。大多数工具使用一些拖拉式的流程图来模拟流程控制。很多内置解释的程序语言，但是这些语言都无法像上面所说的单独的语言那样健壮。

　　Most authoring tools are a bit like Visual Basic, only they work at a much higher level. Most of the tools use some kind of click-and-drag flowchart motif to model control flow. Many contain embedded interpreted programming languages, but these languages aren't nearly as robust as the standalone languages mentioned above.

　　优点：快速原型 ― 如果你的游戏符合工具制作的主旨，你或许能使你的游戏跑得比使用其他语言快。在很多情况下，你可以创造一个不需要任何代码的简单游戏。使用插件程序，如Shockware及IconAuthor播放器，你可以在网页上发布很多创作工具生成的程序。

　　Advantages: Fast prototyping --if your game fits the motif the tool's made for, you can probably get your game running faster than any other language. In many cases, you can make a rudimentary game without writing any code. You can broadcast many authored apps on web pages with plug-ins like Shockwave and IconAuthor Player.

　　缺点：专利权，至于将增加什么功能，你将受到工具制造者的支配。你必须考虑这些工具是否能满足你游戏的需要，因为有很多事情是那些创作工具无法完成的。某些工具会产生臃肿得可怕的程序。

　　Disadvantages: Proprietary, so you're at the mercy of the tool-maker as to what features will be added. You've gotta really look at these tools to see if they'll do everything that your game's gonna require, because there are things that authoring tools simply can't do. Some of these tools produce frighteningly bloated apps.

　　移植性：因为创作工具是具有专利权的，你的移植性以他们提供的功能息息相关。有些系统，如Director可以在几种平台上创作和运行，有些工具则在某一平台上创作，在多种平台上运行，还有的是仅能在单一平台上创作和运行。

　　Portability: Since authoring tools are proprietary, your portability is limited to whatever they offer. Some systems, like Director, can author and run on several platforms. Some tools can author on one platform but play on several. Some are single-platform beasts.

　　使用创作工具编写的游戏：“神秘岛”和其他一些同类型的探险游戏。所有的Shockwave游戏都在网络上。

　　Games Written in Authoring Tools: Myst and a few other "exploration" games of the same genre. All of the Shockwave games on the web.

　　资料：Director、HyperCard、SuperCard、IconAuthor、Authorware。

9、结论（Conclusion）

　　你可能希望得到一个关于“我该使用哪种语言”这个问题的更标准的结论。非常不幸，没有一个对所有应用程序都最佳的解决方案。C适于快而小的程序，但不支持面向对象的编程。C++完全支持面向对象，但是非常复杂。Visual Basic与Delphi易学，但不可移植且有专利权。Java有很多简洁的功能，但是慢。创作工具可以以最快的速度产生你的程序，但是仅对某一些类型的程序起作用。最好的方法是决定你要写什么样的游戏，并选择对你的游戏支持最好的语言。“试用三十天”的做法成为工业标准是件好事情。

　　You probably were hoping for a more cut-n-dry conclusion to the "what programming language do I use" dilemma. Unfortunately, there's no solution that's optimal for all applications. C is suited for fast and small applications, but doesn't support OO programming well. C++ has very complete OO support, but is frighteningly complicated. Visual Basic and Delphi are easy to learn, but are non-portable and proprietary. Java has a lot of neat features, but is slow. Authoring tools can get your app working quickest, but are only useful for a narrow range of applications. It might just be best for you to figure out what kind of game you're writing and pick the language that would best support your game. It's a good thing that the "try it free for 30 days" offer has become the industry norm :-)

--------------------------------------------------------------------------------

　　作者简介

　　John Hattan是位于德克萨斯州的Watauga里最大的软件公司 ― Code Zone的主要负责人。

关于帝国2中的寻路和行军算法

一提起游戏中的寻路，很多人就会想起A*算法，的确，A*无疑是当前用的最多也是最先进的算法，在比较简单的地图上它的速度非常快，能很快找到最短路径(确切说是时间代价最小路径)，而且使用A*算法可以很方便地控制搜索规模以防止程序堵塞

　一提起游戏中的寻路，很多人就会想起A*算法，的确，A*无疑是当前用的最多也是最先进的算法，在比较简单的地图上它的速度非常快，能很快找到最短路径(确切说是时间代价最小路径)，而且使用A*算法可以很方便地控制搜索规模以防止程序堵塞。

　　关于A*算法的文章已经很多了，上google随便一搜都能找到，但是国内网友原创的似乎不是很多，建议英文不太差的爱好者上国外的网站查找相关资料，比如http://www-cs-students.stanford.edu/~amitp/gameprog.html。

　　A*算法本身表述起来很简单，程序写起来也不难，两三百行轻松搞定，关键是要在代码优化上下功夫，这就很考验程序员的算法功底了。基本的思路一般都是以空间(也就是内存的占用)换取时间(搜索速度)，另外还有一些地图预处理(包括人工的预处理和用程序预处理)的技术比如多级地图精度或者地图分区域搜索等等，但我今天要讨论的不是A*算法本身，关于这方面有兴趣的网友可以另外和我交流。

　　不管怎么优化，寻路总是一项非常费时的工作，并且工作量和地图的大小基本成线性关系(不限制搜索规模的前提下)，现在的rts往往允许每方生产200个以上的移动单位，同时可能会有大量的移动物体需要寻路，如果同时选定100个单位点并向他们下达远程行军命令，假设每次寻路需要5ms(在复杂地图上，这个数值一点都不夸张，我是说在我的机器上)，那么就需要0.5秒的时间在寻路上，也就是说整个游戏将因此停顿0.5秒，你受的了么？

　　呵呵，俺们程序员是不会让这种情况出现地，通常有几种方法来避免寻路运算导致程序堵塞：

　　1、限制同时选定的移动单位个数

　　　帝国2里面，这个限制是40个，当然这样一来，同一个编队里的人数就不可能超过40了，这一方面是为了减少寻路耗时，同时可能也有别的考虑，我能想到的是同时控制过多的单位攻击同一个目标可能效率会很低，我不知道其它rts游戏是否也有类似的限制，但是如果采用了下文所述的第2，第3种方案的话，这个限制就显得不那么重要了。

　　2、把寻路工作在时间上分散进行

　　　可以估计一下每次寻路所花的时间，限制每个“回合”(就是游戏的一帧)最多让多少个单位寻路，其它的等下一个回合再说，这样游戏就不会停顿，但是缺点是可能会看到所有人不是同时动身，而是先后开始移动，网上有文章说为了避免选中的单位“发楞”而让玩家以为出了什么问题，可以让一时来不及寻路的单位花很少的时间凭“直觉”决定一个方向(通常就是目标所在的直线方向了)先走再说,等轮到自己寻路以后再改回来，这也是个办法，因为“直觉”的方向在大多数情况下就是正确的方向，但是据我观察在帝国2里面没有用到这个小伎俩,后面会说到。

　　3.这个是最实惠最有效的，就是距离相近的单位公用一条路径，所谓“相近”一般来说以互相都在视野之内为限

　　　玩过帝国2的人都会感叹其中各种漂亮的阵型，连行军的时候都要摆的整整齐齐的一个方阵(当然前提是在空地上跑)。即使你故意挨个把他们分散了(不能距离太远)，同时选中他们并点取一个目的地以后，他们也会在行进中慢慢的自动靠拢，不一会又排成方阵了，而且，不管你让他们去地图的什么地方，他们都会全体立即响应，而不会出现上一条所说的那种停顿或者先后启动，这是怎么回事呢？聪明的你一定能想到，只要让一个人带队寻路，其他人跟着就行了，对！就是这么回事。让一个单位寻路而其余的单位跟随，这比让每个单位单独寻路要快的多了，这个带队的移动单位称之为“寻路兵”。

　　说到这里要提到帝国2的一个不知能不能算的bug，比如有一条很长的小河，你有一帮人马，一部分在河左边，另一部分在河右边，他们挨的很近，虽然隔着河。现在你画个框把他们同时选定，比如让他们都到河左边，因为他们相互都看得见，于是程序就选了一个人带路(怎么选的我不太清楚)，这时候可能出现两种情况：一种是寻路兵在河左边，于是他带着河左边的众弟兄朝目的地去了，河右边的一干人很想跟着(根据程序的设定，他们不需要自己寻路)但是无奈隔着河过不去，在河边彷徨了一会(帝国2的算法据我观察在原定路线不能走的情况下会先尝试从两边绕行，当然绕行的范围是有限的，如果发现绕不过去才重新寻路)，当对岸的人马走出他们视野的时候他们才想起来可以自己寻路，于是顺着河边绕过去了；另一种情况更搞笑，就是系统选出的寻路兵在河右边，本来河左边的人是离目的地很近的，但是他们不管，非要隔着河紧跟着那边的寻路兵，直到在河流的尽头与寻路兵所在的部队汇合以后，才一起排着方阵走向目的地。

　　关于帝国2中寻路兵的确定，就是在一队人马中选哪个来带头寻路，我还没有什么头绪。

　　另外，当寻路兵死亡(按了del键，呵呵)，或者被指定了另外的目的地时，剩下的单位中会重新产生一个寻路兵，重新寻路。

　　奇怪的是，帝国2中的农民的移动却没有采用寻路兵策略，即使彼此很靠近的一堆农民，他们移动时也不会排成方阵，而且点选目标的一瞬间会出现上文第2条所述的那种停顿，即有的农民先启动，有些后启动。在我的CII533的机器上，40个农民，huge空白地图从一头到另一头，最快启动的农民和最慢的大概相差0.5秒，延迟已经很明显了。我不太明白为什么这么设计，可能是农民行为的特殊性上的考虑，呵呵，农民嘛，向来是自由散漫无组织无纪律的:)

　　另外关于帝国2要说明的是它没有类似红警里面的同一方的“让路”算法，如果你让几个人把一个咽喉要道堵住，然后控制另一队人试图通过这个关口，可以看出寻路的时候算法没有考虑堵住关口的单位,因为你控制的人马径直就朝这个关口过来了，就像以为它是通的一样(这本身是合理的，因为他们不知道挡路者什么时候会离开)，到了跟前一看堵住了，左边右边的绕了两下没绕过去就回头找另一条路去了，挡路的人根本无动于衷。

　　现在的rts正在向网络化发展，在地图越来越大，移动单位越来越多的情况下，一方面是路径搜索算法本身的效率，另外行军算法(例如阵型，让路等等)的效率和巧妙程度也是个很值得研究的课题。

　　呵呵，居然写了这么多，我有时间的话还会研究一下其它游戏的寻路特点，如果有同好者欢迎和我交流，本文如果要转载，请注明是转载，谢谢！

即时战略游戏中如何协调对象移动

　　 在图论中人们研究了通过怎样的计算才能找到一条从A点到B点的通路，以图论本身来说这已经解决了从A到B的问题，剩下的只是从A沿着找到的路线移动到B就可以了。这样的认识基于一个默认的假设--道路中的一切障碍物都是固定的，但是在现在已经广泛流行的即时战略类游戏中问题却远远不止这些。

在图论中人们研究了通过怎样的计算才能找到一条从A点到B点的通路，以图论本身来说这已经解决了从A到B的问题，剩下的只是从A沿着找到的路线移动到B就可以了。这样的认识基于一个默认的假设--道路中的一切障碍物都是固定的，但是在现在已经广泛流行的即时战略类游戏中问题却远远不止这些。举个例子说上下班高峰期的时候，路上的每一个人都清楚地知道自己的目的地和所要走的路径，但是由于某些个人不遵守规则或其他人为原因还是会造成堵车现象。而如果这样的事情发生在一个即时战略的游戏中，那么带给玩家的沮丧感和愤怒将远超过现实中的堵车现象。当游戏中的一个士兵接到玩家的命令要从基地的一侧移动到另一侧以帮助抵抗敌人的进攻时，它需要一个计划(更明确的说是一条寻找出来的路线)使它能够到达目的地，但很可能在它移动的过程中预定的路线上出现了变化(例如玩家让工人们在士兵的必经之路上修建一个建筑或另外一批士兵出现在路上，从而堵塞了道路)，这时如果没有一个优秀的移动系统，那么之前的寻道工作等于是白费工夫。

　　本文将介绍一种相当有效的个体移动系统，以从另一个角度探讨游戏中的自动移动问题。虽然本文主要是针对即时战略类型，但所介绍的方法可以很容易的扩展到其它的类型中使用。这里查看原文。

　 一些需要解决的问题

　　在进一步深入到我们的移动系统中之前，我将先简介一下人们在解决移动问题上遇到的一些问题，这些问题是消耗最少的CPU时间的同时达到最佳的智能效果和最高的移动精度的关键。

　　首先让我们对比一下同时移动单个对象与同时移动数十、数百个对象的不同。一次移动一个对象是非常简单的，但是一个可以相当完美的移动单个对象的算法并不一定能很好地解决数百个对象的同时移动，这其中最大的问题就是CPU时间的消耗。请一定要切记如果你要制作一个需要同时移动大量个体的游戏程序，那么在CPU的使用上一定要非常的保守。

　　某些移动算法是很依赖CPU速度的，这就是那些要同时移动大量个体的游戏中只有很少的一部分支持高级的移动方式(例如个体的加速和减速)的原因。玩家们总是认为游戏中的大船和被重装备武装起来的战士们应该具有能够加速和减速的能力，这样才能体现出真实性，但是这小小的真实性将会增加超乎想象的额外的CPU计算工作。这种情况下事实上用来处理个体移动的时间增加了，因为你不得不花费更多的时间来计算加速度，从而获得新的速度值。在后面我们扩展例子程序到处理移动的预操作部分时，你将清楚地看到这样的工作所增加的计算复杂度有多大。另一个将会大大增加CPU计算量的问题是个体的转动半径。大多数寻道算法都不考虑个体的转动半径(转动半径是指一个个体原地旋转一周所需的最小圆的半径，因为我们不可能让一个士兵倒退着走上半张地图去袭击敌人的基地，所以经常需要个体进行旋转)对道路选择的影响。于是就会出现一种情况，虽然我们的一头大象已经找到了一条通往目的地的通路，但是它却不能沿着这条路线移动到目的地，因为路线中的一个拐角面积要比大象的转动半径小一些。大多数移动系统通过减缓个体的速度，再作出一个缓慢而更节省空间的转身动作(相信很多人都看到过即时战略游戏中士兵在拐角处被堵住时所作的动作吧)来解决这一问题，但这种方法会极大的增加CPU的计算量。

　　正如大家所想象的那样，即使是即时战略游戏也并不是即时的，而是不断的进行循环，在每次循环中处理游戏的全部数据和玩家的指令(我们可以称它为UL-Update Loop)。为了增加游戏的性能，一般采用的方法是记录上一次UL的所消耗的时间，以预测下一次UL大约将要花费的时间(为了能尽可能地逼近即时处理，这样做是很有必要的)，但是这就给个体的移动带来了大问题--每次UL中个体的移动距离很可能是完全不同的，下面的图1就是这种情况的一个例子。负责个体移动的算法显然在面对每次移动相同距离时比每次都要为所有移动个体计算不同的时间下移动出的不同距离并将其显示出来要轻松得多。当然，如果游戏的UL系统制作的非常优秀，那将略微改善一点这样的窘境。

　　不要忘记处理个体移动中的碰撞问题。一旦你的游戏中的士兵们碰撞到了一起，你要怎样将他们分开呢？一种方法是是个体之间根本不发生碰撞，但在实际的应用中这是不可能做到的。不仅仅是实现这要求的程序代码非常难写，而且无论你写再多的代码也是无用的，这些个体总是会找到一些途径来使彼此重叠在一起，而在更多的情况中，这些个体的重合是必须的。一些使用近距离兵器进行战斗的游戏，例如《帝国时代》，就是一个要求个体重合的实例。另外，如果你要限制你游戏中的个体不能碰撞在一起，那么他们很可能为了避开彼此而离开预设的移动路线，暴露在其它对手的攻击之下，受到意外的伤害，这会使玩家对你的游戏极端不满。因此你必须决定好你的那些个体相互靠的有多近，重合多少是可以容忍的，还要设法处理由这些决定所带来的问题。

　　注意考虑地图的复杂性。在复杂的地图上实现良好的移动的算法比简单地图上做到同样效果的算法要复杂得多，由于现在地图越来越倾向于复杂和真实，对于移动算法的要求也进一步提高了。

　　随机生成的地图可能造成意想不到的问题。由于不能通过给固定道路编写预定路线来减小寻道的难度，因此随机生成的地图在复杂性上要更高于预设地图，尤其对于寻道而言。当寻道变得使CPU负担过重时，唯一的解决方法是降低寻道的精度和质量，这时就要求提高移动算法的质量以弥补寻道上的不足造成的程序反应迟钝。

　　一定要认真处理各类个体的体积和由此产生的空间问题，这个问题最能说明你所需要的移动算法的精度。如果你的程序中需要移动的物体很少，以至于几乎不会出现彼此互相碰撞的情况(例如大部分的第一人称射击游戏)，那你可以放心地使用一些简单的算法。如果你的程序所要处理的移动物体非常多，并且还要处理彼此的碰撞和诸如检测两个个体之间的缝隙是否足够更小的个体从中间穿过等等操作，这时对你的移动算法在精确度上和质量上的要求将会使计算量大幅度的增加。

一个简单的移动算法

　　让我们从一个简单的对个体状态进行处理的移动算法的伪码开始，这个算法所作的只是简单的使用一条给定路线前进，当遇到碰撞和冲突时重新寻道，因此它能在2D和3D游戏中都表现得很出色。使用该算法，我们将从一个给定的状态开始，持续循环直到找到一个可行的位置作为中继点作为个体移动的目标去接近之后才跳出循环。移动状态将会在整个UL中保存下来，这将使我们能够正确的设置未来的状态，例如"自动"添加中继点。这种保存机制可以保证减少一个个体在下一次UL中作出与当前UL移动相反的判断的可能性。

　　我们假定被给定了一条通向目的地的路径，并且这条路径在提供给我们时是精确的，并且是可行的(也就是不会发生碰撞)。由于大多数即时战略游戏拥有巨大的地图，以至于一个个体可能要花费几分钟的时间来走完整个路程，而在这几分钟里地图上可能发生使当前路径不在可用的变化(例如在路径上新建了建筑)。为了解决这个问题，现在我们加入少许碰撞检测，一旦遇到碰撞，就进行重新寻道。在后面你将看到，我们可以采取几种方法来避免重新寻道，以减少CPU消耗。

碰撞检测

　　所有碰撞检测系统的基本目标都是判断两个个体是否发生了碰撞。这次我们所介绍的碰撞检测都是假设两个物体的碰撞，将来我们会专门介绍大量物体互相碰撞的检测问题。但无论是两个物体还是多个物体发生碰撞有一点是共同的：每个物体都要收到碰撞信息以便作出适当的响应(分开彼此)。

　　大部分即时战略游戏中使用的简单的碰撞判断实际上是将每一个个体看作一个球体(2D中是圆)，再进行简单的球体碰撞检测，而不在意这样简单的判断是否能够满足游戏对于碰撞的要求。这样做确实有利于提升性能，即使一个游戏要进行非常复杂的碰撞判断--例如判断击出的拳头是否击中敌人，或者甚至是低精度的多边形(polygon to polygon)交叉判断，这时为可能出现的碰撞保有一个球体区域往往也能够提升程序的性能。

　　当我们设计一个碰撞检测系统时要注意面对3种截然不同的实体：单个的个体、一群个体的集合以及经过队形编制的个体群(就像《帝国时代2》中的阵形一样，见图2)。事实上对所有这3种类型使用简单的球形判断都能工作得很好，单个个体可以简单的使用单个球体进行它的全部碰撞判断，而对于其它两种情况只需要再稍微增加一点工作量。

　　对于一群个体的简单集合来说，可以接受的碰撞检测下限是对整个组中的每个个体进行检测。这种方法将允许那些不属于你所选定的组的个体轻松的混入你的组队中。相对来说，对编队所要进行的碰撞检测就要更加复杂一些了。我们还应该认识到这种简单的组群还有一种特殊的性质决定了我们应该尽可能的简化对它所采用的碰撞检测方法--这种组群应该能够随时随地的将排列方式变换成任何可能的适应当地空间大小的阵形。

　　对于编队来说，不仅仅要进行如上面的组群那样简单的个体碰撞检测，还要进行大量更加复杂的检测操作。首先要保证编队中的个体之间不能互相碰撞，同时如果编队中的各个个体之间有一定的缝隙，还要保证任何一个不属于该编队的个体不能占用这一空间。另外，一个编队应该不能改变队形或重组，但是游戏的规则又可能规定当没有足够大的通路提供给整个编队保持队形穿越某一障碍物时，编队可以先散开，待各个体越过障碍物之后再重新组成编队，这样的设计更加体贴玩家。

　　我们可以尝试使用基于时间的碰撞描述机制。立即碰撞用来描述当前正发生在两个个体之间的碰撞；未来碰撞用来记录预计在程序运行的后续时间中将会发生在预定地点的碰撞(当然，前提是将要碰撞的对象都不改变各自的移动路线)。在任何情况下立即碰撞的情况都应该比未来碰撞的情况更优先被处理。同时我们也应该定义碰撞的3种状态：未处理的、正在处理和已处理完毕的。

使用"离散"的算法达到"连续"的效果

　　大多数移动算法从根本上都是"离散"的，不同于数学上的离散定义，这里所说的"离散"指移动算法在按照给定路径从A点移动到B点的过程中从不考虑中间路径上可能出现什么东西，相反，在"连续"的算法中就会考虑这些情况。这样做的一个问题就是当我们进行一个Internet游戏时(众所周知，由于网络速度的限制，这类游戏的UL时间一般较长)那些速度较高的个体很可能在一次UL时间中移动相当大的一段距离(由于UL时间变长)，而当这样增长的UL连续出现时很可能出现个体跃过了其它本应发生碰撞的个体。如果这样的情况出现在一个工人的身上那并不会有人在意，但显然任何玩家也不会希望敌人能够从辛苦建设的城墙中穿越而过进而攻击玩家的基地(某些早期及时战略游戏中出现的"穿墙"的BUG就是有这种问题造成的)。大部分的移动系统现在采用限制个体移动距离的方法来对付这一问题，该方法可以有效的简化所需的处理。在离散型的移动算法中解决这类问题的方法如下图所示：

　　一种有效地解决方法是将一次移动拆分成多次移动的集合。这种拆分需要满足一定的移动距离上的要求，这要求就是要保证每次移动的距离刚好短于任何个体的长度，这就可以保证不可能有任何个体移动到当前个体的路径上来，从而避免了从其它个体之上跨越过去的情况。当每次这种拆分后的移动结束时我们就要使用碰撞检测系统对个体的当前位置进行碰撞检测。你可能会想到如此频繁的计算大量点的碰撞信息将会极大的增大系统消耗，没关系，在后面的章节中我们将会介绍一种方法来降低这种计算对系统的消耗。

　　另一种方法是创建一种称之为移动线路(Move Line)的对象。我们可以使用这条移动线路来描述个体的移动，个体的原始位置作为线段的起点，目的地作为线段的终点，就好像《红色警报2》里所表现出来的那样。这种方法并不用添加新的数据，但是会加大碰撞检测部分的复杂性--我们必须把简单的球形碰撞检测修改为对一个点到一条线段的距离的检测，而这样做将会增加计算的难度，也会消耗更多的时间。大多数3D游戏都已经实现了一种可以快速挑选出可被游戏者观察到的物体的分级系统(也就是能够迅速地判断出游戏中的哪些物体处于玩家角色的视野之内的系统)，我们可以对该类系统进行修改，使它们可以用来快速挑选出那些在我们的游戏中可能发生碰撞的个体。这样做的好处是大幅度地减少了需要进行碰撞判断的个体的个数，于是所需要的计算量常常就能够降低到所能允许的范围之内了。

位置预测

　　经过上周的工作，我们已经有了一个简单的移动算法和一个管理个体碰撞的列表，还有什么工作是强化个体之间协作所必需的呢？位置预测(Position prediction)。

　　预测的位置只不过是一个位置列表(至少包含个体的运动方向和时间标记，有时也需要记录加速度等信息)以指出未来某时刻个体所在的位置，参考图4。一个移动系统可以将用来实现个体移动的算法拿来负责计算个体的位置预测，这些预测越准确其可用性也就越大。当然预测计算也会增大计算量，为了不降低游戏的效率，下面我们就来讨论一下如何减少多余的CPU消耗。

　　显然，最方便的优化方法是避免在每一帧中重复计算每一个已经预测过的个体位置。一个简单的移动列表可以实现这样的目的并且能够工作得很好：你可以在每一帧中从表内删除当前的位置，并向表内添加新的预测位置以维持列表长度固定(见图5)。虽然这一方法并不会减少个体开始移动时创建整个列表的计算量，但可以保证在剩余的移动过程中维持固定数量的计算。

　　下一种优化方法是设计一种能够处理点和线的位置预测系统，由于我们的碰撞系统支持处理点和线，因次添加这一功能将是很容易的事。如果一个个体按照一条直线进行移动，那么我们可以利用当前个体位置、预测位置和个体运动半径来指定一段移动的轨迹及范围。然而如果个体正在进行一次圆运动那么整个处理就会略微复杂一些。当然你可以将这种运动过程作为一个函数保存起来，但这显然会加大系统的负担。作为替代可以尝试通过对圆上的点进行取样来作出正确的位置判断(见图6)。最后，再次建议一定要使用能够实现对点和线的无缝交替处理的预测系统，以便在任何可能的情况下通过使用直线来减少对CPU的耗用。

　　最后所要介绍的一种优化方法非常重要，但同时也可能有一些不够直观，不能简单的看出其优化作用。如果我们要使用这样的预测系统，为了尽可能少的消耗资源，显然不应该在计算了一次预测未知之后再进行一次计算来移动个体。因此解决的方法是精确地进行位置预测，并最终使用该位置移动个体。这样我们就能对每个个体的移动只计算一次并且除了前述的开始移动时的计算之外没有其他多余的计算开销。

　　在实际的应用中，你可能每次只能进行一个UL时间的计算来进行位置预测，这时要注意未来每次UL的时间很可能并不等长。如果只是简单的按照预测位置移动个体而不考虑每次UL的长度，这将有可能造成一些问题，当然某些游戏(或者游戏中的某些类个体)可以很好的适应这样的操作。一般的游戏都通过每次对列表中的数据进行一些修正来改善预测的准确性，而这样做的同时也应注意何时应该完全抛掉原来计算的已与现在情况有较大误差的预测而重新计算整个列表。

　　实际对位置预测的应用中主要的难题是由于我们在碰撞检测中将这些预测的位置做为个体的当前位置来使用所造成的。你将很容易的看到对某给定的区域内个体预测位置的比较所需要消耗的计算量，但是为了很好的实现个体间的协作我们必须知道未来一小段时间内每个个体的目的地以及它们可能会与哪些其它个体相碰撞，这都需要一个优秀而且快速的碰撞检测系统。此时最佳的优化措施就是如同前面所述使用3D引擎中的相关部分舍去那些不大可能碰撞的个体组合，这将允许你使用更多的CPU时间来处理最可能发生的那些碰撞。

个体之间的合作

　　我们已经建立了一个复杂的系统来确定个体未来的可能位置，它支持3D移动，同时对计算量的提升也并不比一个简单的方法多多少，重要的是该方法提供给我们一个记录了一个个体在未来一小段时间内移动所需的一切信息的列表，这正是我们所需要的。现在我们可以进入较为有趣的部分了。

　　如果我们的工作做得很好，那么我们所要处理的绝大部分碰撞将是未来的碰撞(因为我们已经使用位置预测尽量地避免了立即碰撞)。由于处理未来碰撞最后的方法将是停止移动并重新寻道，因此为了不使寻道过于频繁，尽量使用其他方法解决碰撞就变得很重要。

　　下面就详细的介绍对于这种个体与个体碰撞的方法。

未处理的碰撞：

CASE 1:if 个体已经全部停止移动：

1. if 是低优先级的个体，什么也不做

2. if 是高优先级的个体，找出哪一个个体将要移动(如果存在)，告知该个体进行尽可能最短的移动来解决碰撞，改变状态为正在处理的碰撞

CASE 2:if 个体没有移动，是另一个个体将要移动，什么也不做

CASE 3:if 当前个体正要移动，其它个体已经停止

1.if 是高优先级个体，其它停滞个体为低优先级并且能够从通路上移开，计算出下一步的位置并通知低优先级的个体从通路上移开(见图7)，改变状态为正在处理的碰撞

2.Else,if 可以避开另一个个体，避开他以解决碰撞

3.Else,if 是高优先级个体并且能够沿移动路线推动低优先级个体，推动它，改变状态为正在处理的碰撞

4.Else,if 停下，重新寻道

CASE 4:if 当前个体正在移动，另一个个体也在移动：

1.if 当前个体是低优先级，什么也不做

2.if 碰撞不可避免，并且当前个体是高优先级，通知另一个体停止移动，转状态为CASE 3.1

3.Else,if 当前个体是高优先级的，计算出下步移动位置，通知另一个体减速到足以避免碰撞。

正在处理的碰撞：

1.if 是一个移动的个体要处理CASE 1的碰撞，并已经移动到了目的地，碰撞解决

2.if 是CASE 3.1中低优先级个体，并且高优先级个体已经抵达预定位置，开始返回原位置，碰撞解决

3.if 是CASE 3.1中高优先级个体，等待(减速或停止)直到低优先级个体从通路上离开，之后继续移动

4.if 是CASE 3.3中高优先级个体并且现在低优先级个体已可以从通路中离开，转状态为CASE 3.1

5.if 是CASE 4.3中低优先级个体并且高优先级个体已经抵达预计地点，恢复移动速度，碰撞解决

　　解决碰撞的关键之一是排定个体优先级的顺序，如果没有一套强壮的完好定义的优先级体系，你将看到碰撞在一起的个体有如旋转木马一般运动，因为每个个体都要求对方让出道路，而同时又没有一个个体能拒绝这个要求。我们也应该为碰撞进行分级，在处理时应该优先处理那些有最高优先级的碰撞，当有足够富裕的时间时再去处理那些优先级低一些的碰撞。在游戏中碰撞处理也需要注意碰撞个体的密度。如果一场大型的战斗使得许多的战士在狭小的空间中碰撞在一起，那你就应该花费更多的CPU时间来处理这些碰撞而不是地图上远处两个矿工间的碰撞。对这类较容易发生碰撞的区域的关注的另一好处是你将能够在其它个体进行寻道时使它们避过这类区域。

计划编制基础

　　计划编制是个体协作的关键，虽然我们尽可能地提升预测和计算的精确性，但是显然事情总是会出错的。例如我们在《帝国时代》中所犯的一个错误是我们总是在一帧的时间内使个体作出移动的决定，虽然这样的决定多数是正确的，但我们并没有在以后的UL中参考它。这样就造成了一个问题：个体对移动路线作出了决定，实行时发现出现问题必须重新决断，结果是使个体再次返回它的出发点。计划编制可以有效地避免这类问题。我们保存一定数量的个体以前移动中所遇到的障碍和碰撞的解决步骤(由其它的游戏细节定义)，这就为我们未来遇到困境时提供了参考。举例来说，当我们要避免一次碰撞时我们将存储哪一个个体是我们所要闪避的。由于我们要设定一个可行的计划，没有任何理由对碰撞中的另一个体进行碰撞检测，除非其中的某一个个体得到了新的命令或发生其它类似的变化。一旦我们完成了闪避，就可以为其它的个体恢复正常的碰撞检测了。在下面的扩展中，你将看到我们将反复利用这一思想来达到我们的目的。

一些简单扩展

　　游戏编程的乐趣之一就是要不停地创新来开发新技术以使设计人员能作出更优秀的游戏。在即时战略游戏中，越来越多的开发人员希望能够在他们下一批作品中加入对编队的处理能力。在这里我不会介绍现在那些低技术含量的移动方法，我所要讨论的是如何协调编队的移动，使每一个个体都能在智能的维持编队队形的同时在地图上随意的移动。

组队(Group)移动

　　首先要弄清楚何谓组队(Group)：由用户(玩家)为方便操作而选取的简单的个体集合(一般会对其成员发布相同的命令)，除了在移动时要保持成员一同移动之外组队并没有其他对移动系统的限制。组队的使用使我们必须记录许多信息，例如组队成员的列表以及当整个组队还在一起时所能移动的最大速度。也许我们还应该保存整个组队的中心，以作为一个可以很容易得到的操作参考点。同时还应该选定一个组队的指挥者，大多数游戏中怎样选出这个个体并不重要，重要的是一定要有一个这样的个体。

　　在我们开始工作之前有一个问题需要回答：当组队在地图上移动时我们有必要保持所有个体在一起吗？如果不，组队将只是为使用户方便操作而存在的，每一个个体都会独自寻道和移动就如同用户对每个个体分别下达指示一样。当我们关注如何加强组队的管理时，我们可以发现组队的凝聚力可以分为多个等级。

组队中的个体都以相同的速度移动。一般地这将使用组队中速度最低的个体的最大速度，不过有时让那些速度较慢的个体在组对中移动的稍快一些会更好(见图8)。然而一般游戏的设计人员给一类个体较低的速度总是有原因的，例如如果允许强力的个体能够非常高速的在地图上移动将会极大的破坏游戏的平衡性。

组队中的个体都以相同的速度移动并使用同一条路径。这种方法可以有效的避免当组队中一半的个体从森林一侧前往目的地时另一半却从另一侧移动(见图9)，稍后你将看到实现这一方法的一条简单途径。

组队中的个体以相同的速度移动，使用同一条路径并同时抵达。这是最复杂的组队组织方式，它不但要求达到上述两点，并且还要求位于前面的个体能够等待落在后面的个体追上来，有时还要给后面的慢速个体短时间加速以使其能够追上前面的个体。

　　怎样才能实现最后的要求？这要使用一种分级的移动系统，这样我们就能在处理每个个体的移动时兼顾那些同属于某个组队的个体了。如果我们对组队的个体创建一个组队对象，我们就能够记录所有必需的数据，为整个组队计算最大速度，以及判断何时需要前面的个体等待后面的个体。下面就是一个组队类的简单定义：

Listing 2. BUnitGroup.

//*****************************************************************************

// BUnitGroup

//*****************************************************************************

class BUnitGroup

{

public:

BUnitGroup( void );

~BUnitGroup( void );

//Returns the ID for this group instance.

int getID( void ) const { return(mID); }

//Various get and set functions. Type designates the type of the group

//(and is thus game specific). Centroid, maxSpeed, and commander are

//obvious. FormationID is the id lookup for any formation attached to

//the group (will be some sentinel value if not set).

int getType( void ) const

{

return(mType);

}

void setType( int v )

{

mType=v;

}

BVector& getCentroid( void ) const

{

return(mCentroid);

}

float getMaxSpeed( void ) const

{

return(mMaxSpeed);

}

int getCommanderID( void ) const

{

return(mCommanderID);

}

BOOL getFormationID( void ) const

{

return(mFormationID);

}

BOOL setFormationID( int fID );

//Standard update and render functions. Update generates all of the

//decision making within the group. Render is here for graphical

//debugging.

BOOL update( void );

BOOL render( BMatrix& viewMatrix );

//Basic unit addition and removal functions.

BOOL addUnit( int unitID );

BOOL removeUnit( int unitID );

int getNumberUnits( void ) const

{

return(mNumberUnits);

}

int getUnit( int index );

protected:

int mID;

int mType;

BVector mCentroid;

float mMaxSpeed;

int mCommanderID;

int mFormationID;

int mNumberUnits;

BVector* mUnitPositions;

BVector* mDesiredPositions;

};

　　BGroup类在其内部管理整个组队中个体之间的交互操作。在任何时间点，它都应该有一个时间表以来处理组队内的个体之间的碰撞，它也应该有能力通过参数和优先级管理来控制或修正个体移动。如果你的游戏只支持一种移动优先级，那么你就应该为你在组队中的个体们添加第二种优先级。虽然一个组队对外的表现似乎只有一种优先级，但在其内部还是应该分为不同的移动优先级。基本上来说，BGroup类是另一个完善的封闭的移动系统。

　　组队的指挥者将负责整个组队的寻道工作，它将决定整个组队的移动路线，在简单的组队移动系统中所需的工作只是由这个个体本身来寻道即可。然而在下面的部分中我们将看到指挥者所能够作的其它事情。

编队控制基础

　　首先应该给出编队的定义：编队(Fomation)是一种更复杂的组队，编队有自己的方向(前方、后方、左翼和右翼)。编队中的每一个个体都试图保持自己在编队中的位置，而这个位置是唯一固定的也是相互关联的。更加复杂的模型使得编队中各个个体的朝向需要单独处理，而同时也要求在移动中提供整体旋转的方法。

　　编队是建立在组队系统之上的，它是一种限制更加严格的组队，因为我们必须非常详尽的规定编队中每个个体的位置。所有的个体在移动中必须保持一起行动，并要求在速度、路径上一致以及相互之间的位置和距离保持不变--如果在移动中编队出现了大间距的缝隙，那么它也就与组队没有什么不同了。

　　下面给出的这个BFomation类能够清晰的管理一个编队的预定位置(我们要求编队中的每个个体所处的位置以及它的方向)、编队方向和编队的状态。大多数游戏中所使用的编队都是预先定义的，显然，在开发过程中进行这项工作是很简单的(通过使用一些非专业人员也能熟练操作的文本编辑器就可以很好的完成这项工作)。我们当然希望能在游戏过程中实时的定义编队，但这样做就需要更多的内存以保证每一个由玩家定义的编队都能在内存中保留一份自身定义的副本。

Listing 3. The BFormation Class

//*********************************************************

// BFormation Class

//*********************************************************

class BFormation

{

public:

//The three formation states.

enum

{

cStateBroken=0,

cStateForming,

cStateFormed

};

BFormation( void );

~BFormation( void );

//Accessors for the formation’s orientation and state. The expectation

//is that BFormation is really a data storage class; BGroup drives the

//state by calling the set method as needed.

BVector& getOrientation( void )

{

return(mOrientation);

}

void setOrientation( BVector& v )

{

mOrientation=v;

}

int getState( void ) const

{

return(mState);

}

void setState( int v )

{

mState=v;

}

//The unit management functions. These all return information for the

//canonical definition of the formation. It would probably be a good

//idea to package the unit information into a class itself.

BOOL setUnits( int num, BVector* pos, BVector* ori, int* types );

int getNumberUnits( void ) const

{

return(mNumberUnits);

}

BVector& getUnitPosition( int index );

BVector& getUnitOrientation( int index );

int getUnitType( int index );

protected:

BVector mOrientation;

int mState;

int mNumberUnits;

BVector* mPositions;

BVector* mOrientations;

int* mTypes;

};

　　使用这个模型，我们必须时刻关注编队的状态。cStateBroken表示编队并没有被创建也没有创建的企图；cStateForming表明我们的编队正在建立但还没有达到cStateFormed状态；一旦所有的个体都已位于它们的预定位置，我们就可以将状态改变为cStateFormed。为了使编队的移动简单化，我们可以使一个编队在完成组建之前(达到cStateFormed状态之前)不可移动。

　　当我们准备使用一个编队时，第一件工作就是组建这个编队。当给定一个编队时，BFormation(译者注：原文这里是BGroup，但该类并没有编队管理功能，经过反复推敲认定为编写错误)控制每个个体移动到编队中的预定位置，该位置的计算是与当前编队方向相关的，如果这个方向发生了变化，那么预定位置将自动被重新计算并修正为正确的位置。

　　为了组建一个编队，我们可以使用预定安置--每一个预定位置拥有一个预设值(由定义规定或由算法确定)来指明个体组建编队时应该按照那种顺序进驻那些预定位置，这样才能使整个组建过程从里到外进行得相当有条理(见图10)。下面的算法列表说明如何实现这样的组建方式。

Listing 4.

设置组队中的所有个体移动优先级到一个相同的低优先级

设置状态为cStateForming

While 状态为cStateForming

{

找出离编队中心最近的未有个体占据的位置

If 没有个体再可用

设置状态为cStateFormed，跳出组建循环

选定一个个体前往所找出的位置，要求满足如下条件：

使个体移动距离最短

与其它编队成员碰撞的几率最小

移动时间最短

设置个体的移动优先级到中等值

等待直到个体就位(可能要经过多个UL时间)

设置个体移动优先级为最大值，这样做可以保证以后进行组建工作的个体不会使该个体离开其位置

}

　　现在我们所有的战士都已经就位了，接下来做什么呢？我们可以开始移动他们以穿过整个地图，我们可以假定寻道系统找出了一条以当前编队的形状和大小可以通过的路径来抵达目的地(见图11)，如果没有这样一条路经那就必须对整个编队进行操作(不久我们就会探讨这个问题)。当编队在地图上移动时我们需要选出一个指挥者来控制整个移动，当指挥者沿路径前进并改变方向时其它所有编队中的个体都要改变方向以追随它，这种操作一般被称为flocking(聚集)。

　　我们有两种方法处理编队的方向改变：忽略这种改变或者转动编队的方向。忽视方向的改变是简单的而且对于那些盒状的编队来说是非常合理的。

　　对编队进行旋转并不会增加多少复杂性而同时对于某些编队方式(如直线形)来说是非常合理的。进行编队旋转时首先要做的是停止编队移动，完成方向的旋转之后我们要重新计算每个预定位置，然后回到cStateForming状态(见图13)，使个体前往新的位置并在完成这一工作之后设置状态为cStateFormed，这样我们就可以继续原来的移动。

高级编队管理技术

　　现在我们已经可以将编队在整个地图中移动了，但是由于游戏的地图是动态而且复杂的，所以很可能出现选出的移动路径不可用的情况。如果这样的事情发生，就需要我们对编队进行操作，一般的操作方式有3种，下面就逐一介绍。

缩放个体间距(Scaling unit positions).由于编队中的预定位置都是由矢量进行定义的，因此我们可以很方便的对整个编队的间距进行放缩以使它变得更小，这就使得编队能够通过城墙或树林中更小的缝隙(见图14)。这种方法对于那些排列得较为分散的编队很有效，但对于那些排列紧凑的编队就没有什么用处了。

简单的障碍回避(Simple ordered obstacle avoidance).如果我们在移动编队时遇到与其它游戏中实体相碰撞的情况时(无论是当前还是未来碰撞)，我们可以假设即使有这样的碰撞发生，原来寻到的道路仍是可用的。简单的解决方法是沿着编队前进的路线找出第一个不再发生碰撞的位置，并在该位置完成编队的重组(见图15)。这样我们的步兵团就可以先分散，带穿越障碍物之后再在另一侧重新组建编队。在使用这一方法时一定要注意有时障碍物的范围非常大，以至于编队的重组工作必须在走出很远之后才能做，这时就得考虑是否应该重新寻道了。

二分和重组(Halving and rejoining).虽然简单的回避能够工作的很好，但是会降低玩家对整个编队穿越地图的感觉，相对来说二分法可以很好的保持住编队所带来的视觉冲击。当我们的编队在前方遇到一个障碍物时我们可以找出编队中的一个拆分点，从该点将编队一分为二，这两个编队分别通过障碍物之后再前进到重组位置恢复成一个编队(见图16)。这种方法只增加很少的计算量，但却能为编队移动带来良好的视觉效果。

路径栈

　　路径栈就是一种简单的用来记录个体移动路由信息的栈操作(后进先出，见图17)。一个路径栈记录的信息一般包括个体当前所采用的路线，现在个体正在向哪个中继点移动以及个体是否正处于巡逻中。一个路径栈对我们的目的有两大作用。

　　首先，它可以为一次分级寻道工作提供便利。一般来说游戏开发者会把寻道区分为两种明显不同的等级--高级(high-level)和低级(low-level)(见图18)。高级的寻道可以为个体找寻出穿越地图上不同地形和主要堵塞地点的道路，这就如同玩家大多数时候给个体制定的路径一样。低级的寻道则同时还会处理较小的障碍物并更注重处理细节。一个路径栈可以方便的存储高级和低级的寻道信息。我们可以先通过高级寻道找出一条路径并把它存储进路径栈中，而当我们必须注意避免与大片空地中的一颗树发生碰撞时就可以将低级寻道的一系列结果存入路径栈顶并执行它们。每当执行完一条路径，我们就可以将它从栈中弹出并继续执行现在位于栈顶的路径。

　　第二点，路径栈可以允许高级寻道被重用(reuse)。如果你回顾前面的介绍将看到组队和编队在移动时的一大要素就是所有的成员都使用相同的路径来移动到目的地。如果我们设计的路径栈可以允许多个个体参考一条路径，那就将使同一条高级寻道路径很容易的被重用。一个编队的指挥者将使用高级寻道找出一条路径并把它拷贝给编队中的每个个体，而其它个体则什么也不用做。

　　这样创建保存路径信息的结构还能提供给我们一些其它好处。通过将一条高级寻道路径拆分成多个低级寻道路径，我们可以在执行具体路径之前充分的对这些低级路径进行更精确的计算。而且如果我们确定高级寻道的结果是可用的话，也可以将低级寻道的工作略微推后再做。如果我们正在进行高协调度的个体移动，路径栈将允许我们向栈顶添加一条临时的用来避免碰撞的路径，并能够很好的使用这一路径修正个体移动(

解决混合碰撞

　　我们定义混合碰撞为同时发生在两个以上个体之间的碰撞。大多数游戏都对于可以解决的混合碰撞中的个体个数有限制，超过这个数目就只能分几次解决了。下面我们将探讨如何使用已有的移动系统对这类情况进行简单的处理。

　　如果我们遇到了一个由三个个体造成的混合碰撞(见图20)，首要的工作是找出其中优先权最高的个体。一旦找到它，我们就要立即找到与之碰撞的另一个个体并确定优先权最高的个体所遇到的最主要的碰撞(该碰撞可能发生在其与次优先的个体之间，也可能不是)。当我们找到了这两个个体后，剩下的工作就交给原来的碰撞处理部分解决即可了。

　　当最初的两个个体的碰撞被解决后，我们就要重新评估整个碰撞并更新个体之间的关系。一个更复杂的系统可以很好的解决这样的问题，但是如果简单的移走已经解决了碰撞问题的个体也能得到不错的效果。

　　一旦我们更新了碰撞中的个体，下一步工作就又回到寻找优先权最高的个体的碰撞上来了。我们将一直重复这一步骤直到所有的碰撞都被解决。

　　你可以在两个地方使用这一系统：碰撞解决部分或碰撞预测系统中。碰撞解决的规则必须被修改以适应对于个体优先级的要求，这样的修改并不难，但会增加一定的代码量。或者你可以修改你的碰撞预测系统使得只会发生两个个体碰撞的情况，然而这样做你仍然需要先找出一次碰撞中的全部个体并作出操作。

解决堆叠峡谷问题(The Stacked Canyon Problem)

　　所有移动系统的最终目的都是要实现智能的移动效果，而所有处理中最能体现智能的就是处理堆叠峡谷问题了(什么是堆叠峡谷问题呢？事实上当一个个体要从一群排列紧凑的个体之间穿过时所需要解决的问题就是堆叠峡谷问题，图21就是一个例子)。虽然此类问题并不能简单的一次解决，但我们可以重用前面的一些简单方法来解决它。

　　第一步是鉴定是否为一个堆叠峡谷问题。这是非常重要的，因为我们将要利用前进个体(driving unit)的优先级。当然我们可以利用每个个体自身的优先级来要求其它个体让出道路，但是更好的解决方法是使用前进个体的优先级。判断一个堆叠峡谷问题可以有两种方法：观察前进个体是否会把一个阻碍其移动的个体推到另一个身上或者观察移动个体的碰撞列表以寻找多重的碰撞。不论采用哪种方法，被推动的个体都应该拥有与前进个体相同的移动优先级。

　　一旦我们判断出将要解决一个堆叠峡谷问题，就可以采用一种简单的递归调用个体协调运动系统的方法来解决它。把第一个被推动的个体作为前进个体处理其于第二个个体之间的关系，并如此循环。每一个个体被它的前进个体推动直到它可以移动到一边而让出道路。当最后一个个体也从陆上让开后，原来的前进个体就可以继续移动了。

　　一个好的习惯是将已经移开的个体在移回原位。为了能够这样做，我们应该记录整个推动过程并在问题解决后倒序的执行该过程。另外如果负责移动的代码能够辨别出前进个体是否归属于一个组队，那就能保证组队中每个个体都能在原来阻碍道路的个体返回原位置之前通过。

注意

优化你的整体系统。如果你只是要做一个2D游戏，那就会有许多多余的计算是可以取消和简单化的。不论你是要做2D游戏还是3D的，你的碰撞检测系统都需要一个优秀的经过优化的个体分拣系统，这类系统已经不再仅仅用于绘图了。

对高级寻道和低级寻道使用不同的方法。过去大多数游戏对这两种寻道方式使用相同的算法。这样做的害处是如果对高级寻道使用低级寻道的算法将使高级寻道变得缓慢并且不能用于寻找长的通路；相反的，如果对低级寻道使用高级寻道的算法将会造成结果并没有将道路上的所有障碍物考虑在内或者造成一个个体能从其它个体之中穿过。一定要抓住要点制作两套寻道系统。

无论你做什么，个体总会交叠碰撞在一起。个体的交叠和碰撞是不可避免的，或者按最好情况说将是非常难以操作的。你最好尽早处理这些碰撞问题，这将使你的游戏更好一些。游戏的地图已经越来越复杂了，并且还会加入随机地图的处理。一个好的移动系统将能够很好的处理随机地图和相应的一切细节。

清楚地了解UL是怎样影响个体移动的。可变化的UL时间将是你的移动系统所必须解决的一大难题。可以使用一个简单的修正机制来解决此类大部分的问题。

只涉及单个UL的做法是过时的。没有计划的编制不可能解决好个体移动的协调问题，如果不记录上一次UL中的操作和将来要发生的问题又是不可能制作好的计划的。一个能够运作良好的移动协调系统必须在任何时候都能够参考以前的碰撞列表和预测碰撞的列表。切记解决碰撞的过程中出现的较小的变化是可以忽略的。

不要再出现傻乎乎的个体移动

　　简单的个体移动是简单的。一套优秀的协调系统是我们所应该追求的，因为它能使你的游戏步上一个等级并能增加玩家的乐趣。在本次的文章中我们研究了一个移动协调系统的基础功能--使用多个UL时间制定行动计划以及一套可以解决任何两个个体碰撞的方法等等。现在你应该不会再满足于你的游戏中那些傻乎乎的个体移动了。

附：

本文的部分基本定义：

移动(Movement):

本文主要指对于一条已知路径的执行。简单的移动算法使个体沿给定的路线运动，复杂的移动算法在移动的同时进行碰撞判断，调整各个体的运动以避免碰撞并允许个体组成特殊的队形共同运动。

寻道(Pathfinding):

找出所需路径的工作。所使用的算法可以是简单的遍历也可以是经过高度优化的A*算法。

中继点(Waypoint):

当个体要前往目的地是所必须经过的路径上的点。每一条路径拥有至少2个中继点：起点和终点。

个体(Unit):

游戏中可以在整个游戏地图中移动的实体。

移动算法伪码：

移动循环

{

if "增加中继点(Waypoint)"：

增加中继点。

if 正在巡逻：

沿指向目的地的方向获取下一个中继点

设置状态为"等待寻道"

else：

if 已经不能再得到下一个中继点：

设置状态为"已抵达目的地"

else：

设置设置状态为"等待寻道"

if "已抵达目的地"：

作出适当的通知(如果存在通知方式的话)

移动完成，停止播放移动动画，退出函数

if "等待寻道":

找出一条通路并将之保存

if 无法找到通路

失败，函数退出

计算出向中继点移动所需的方向

通过旋转改变个体的方向指向中继点

使用新的方向，计算一次UL时间将会移动到的位置

if 新位置将会导致碰撞

设置状态为"等待寻道"

返回循环头

判断现在和移动后的位置：

if 移动之前距离中继点更近：

设置状态为"增加中继点"

返回循环头

if 移动过程中将会经过中继点：

设置状态为"增加中继点"

跳出移动循环

}

设置加速度

进行移动

设置并更新所需要使用的动画

刷新预期位置

浅谈电脑游戏中的人工智能制作

电脑游戏随着硬件执行效率与显示解析度等大幅提升，以往很多不可能或非常难以实现的电脑游戏如此都得以顺利完成。虽然电脑游戏的呈现是那么地多样化，然而却与我们今日所要探讨的主题，人工智能几乎都有着密不可分的关系。

　　在角色扮演游戏中，程序员与企划人员需要精确地在电脑上将一个个所谓的“怪物”在战门过程中栩栩如生地制作出来；所以半兽人受了重伤懂得逃跑，法师懂得施展攻性法术。

　　目前能让人立刻想到与人工智能有密切关系的游戏有两种：一是所谓的战棋／策略模拟游戏，二则是棋弈游戏。人工智能的比重与深浅度，在不同的游戏类型中各有不一。有的电脑游戏非标榜着高人工智能不可，不然没有人买；有的则是几乎渺茫到让玩家无法感觉有任何人工智能的存在。　　　　　　　　　　　　

导向式思考

　　AI最容易制作的的方式，同时也是早期游戏AI发展的主要方向就是规则导向或称之为假设导向。在一些比较简单的电脑游戏中，程序员可以好不困难地将游戏中的规则与设定转化成一条条的规则，然后将它们写成电脑程序。让我们以角色扮演游戏为例。决大多数的企画在设定所谓电脑怪物时，所设定的属性通常有以下几种：

　　生命值　攻击力　防御力　法力　 属性

　　最后一个“属性”是我在设定时喜欢增加的项目之一。透过这项属性的设定，我可以把怪物设定成“贪生怕死的”，也可以把战士设定为“视死如归”。以目前我们所掌握的资料，在战门系统中的大纲如是诞生了：　　　　　　　　　　　　　　　　　　　　　　　　　　

规则一

if (生命值< 10) // 边临死亡了吗　

{　 if (属性== 贪生怕死)　　　　　　　　　　　　　　　

　　　结果 = 试图逃跑　　　　　　　　　　　　　　　

　　if (有任何恢复生命值的物品或法术可用)　　　　　　

　　　结果 = 使用或施展相关物品或法术　　　　　　　

}

规则二

if (可施攻击性法术 && 有足够法力)

{　　　　　　　　　　　　　　　　　　　　　　　　

　　　结果 = 施展攻攻击性法术　　　　　　　　　　　　　

}　　　　　　　　　　　　　　　　　　　　　　　　

　　由以上一连串的“如果－－就－－”规则设定，建立了最基本的ＡＩ。说这样的制方式只能建立基本ＡＩ其实并不当然正确。只要建立足够及精确的规则，这样的方式仍然有一定水准的表现。

　规则导向的最大优点就是易学易用。在没有深奥的理论概念的前提下，仍有广大的使用群。所以很多老道的玩家常常没两下就摸清楚敌人的攻击策略，移动方式等等。

　推论式思考

　　相信曾经接触过电脑语言课程，或是自习过相关书籍的朋友们，都曾曾经听过一个著名的程序，那就是井字游戏。用井字游戏作为讨论AI的入门教材，我个人觉得是最适当的例子。或许有人还不知道井字游戏怎么玩。只要任何一方在三乘三的方格中先先成一线便胜利了。我们在前面谈过的规则导向，在这里也可以派得上用场。

　if任何一线已有我方两子&&另外一格仍空//我方即将成一线吗

　　结果 = 该空格　　　　　　　　　　　　　　　　　　　　　

　if任何一线已有敌方两子&&另外一格仍空//防止敌方作成一线　

　　结果 = 该空格 　　　　　　　　　　　　　　　　　　　　

　if任何一线已有我方一子&&另外两格仍空//作成两子　　　　

　　结果 = 该空格

　　有一次我在某本电脑书上，同样地也看到某些以井字游戏为介绍的范例。不同的是，我几乎看不到任何规则导向的影子。但在仔细分析该程序码后，我得到了极大的启发，原来AI是可以不用这么多规则来制作的。它用的方法正是在电脑AI课程中重要的概念：极大极小法。我在这里只说明这法则的概念。继续以井字游戏为例，电脑先在某处下子，接着会以假设的方式，替对方下子，当然，必须假设对方下的是最佳位置，否则一切则毫无意义。在假设对方下子的过程中，自然又需要假设我方的下一步回应，如此一来一往，直到下完整局游戏为止。

底下是节录书中的程序片段：　　　　　　　　　　　　　　　　　　　　　　　

bestMove(int p, int*v)

{

int i;　

int lastTie;　　　　　　　　　　　　　　　　　　

int lastMove;　　　　　　　　　　　　　　　　　

int subV;　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

/*First, check for a tie*/　　　　　　　　　　　　

if (isTie()) {

*v=0;

return(0);

};

/*If not a tie, try each potential move*/

for (*v=-1, lastTie=lastMove=-1,i=0;i<9;i++)

　　{

/*If this isn't a possible, skip it*/　　　　　　　　　　

if (board[i]!=0) continue;

/* Make the move. */

lastMove=i;　

board[i]=p;　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

/* Did it win? */　　　　　　　　　　　　　　　　　　　　　　　

if (hasWon(p)) *v=1;　　　　　　　　　　　　　　　　　　　　　

else{　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

/*If not, find out how good the other side can do*/

bestMove(-p,&subV);

/* If they can only lose, this is still a win.*/

if (subV==-1) *v=1;

/* Or, if it's a tie, remember it. */　　　　　　　　　

else if (subV==0){

*v=0;

lastTie=i;　

};　　　　　　　　　　　　　　　　　　　　　　　　　　

};　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

/* Take back the move. */

board[i]=0;

/*If we found a win, return immediately (can't do any better than that)*/　　

if (*v==1) return(i);

/*If we didn't find any wins, return a tie move.*/

if (*v==0) return(lastTie);

/*If there weren't even any ties, return a loosing move.*/

else return(lastMove);

};　　　　

　　国外的一些论坛曾举行过256字节的游戏设计比赛。作品非常多，其中有一件作品正巧也是井字游戏。作者用区区两百多行就写了与上述程序演算方式完全相同的作品，可见功力确实了的。另外，我也很希望类似的活动能在国内推展起来。对了，在这样的比赛条件限制下，除了汇编语言外，几乎没有其它的选择了。　　　　

　 .386c　　　　　　　　　　　　　　　　　　　　　　　　

　 code　　　　　　segment byte public use16　　　　　　

　　　　　　　　　 assume　cs:code, ds:code　　　　　　

　　　　　　　　　 org　　 100h　　　　　　　　　　　　

　 tictac　　　　　proc　　far　　　　　　　　　　　　　

　 start:　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 push　　cs　　　　　　　　　　　　　

　　　　　　　　　 pop　　 ds　　　　　　　　　　　　　

　　　　　　　　　 mov　　 ax,0B800h　　　　　; 清除屏幕

　　　　　　　　　 mov　　 es,ax　　　　　　　;　　　　

　　　　　　　　　 xor　　 di,di　　　　　　　;　　　　

　　　　　　　　　 mov　　 cx,7D0h　　　　　　;　　　　

　　　　　　　　　 mov　　 ax,0F20h　　　　　 ;　　　　

　　　　　　　　　 rep　　 stosw　　　　　　　;　　　　

　　　　　　　　　 xor　　 cx,cx　　　　　　　;　　　　

　　　　　　　　　 mov　　 dl,5　　　　　　　　　　　　

　 loc_1:　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 call　　printBoard　　　　　　　　　

　 loc_2:　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 ah,8　　　　　　　 ; 等待按键

　　　　　　　　　 int　　 21h　　　　　　　　　　　　　

　　　　　　　　　 movzx　 bx,al　　　　　　　　　　　　

　　　　　　　　　 sub　　 bl,31h　　　　　　 ; 如果不是1..9

　　　　　　　　　 jc　　　loc_2　　　　　　　; 则重新输入　

　　　　　　　　　 cmp　　 bl,8　　　　　　　　　　　　　　

　　　　　　　　　 ja　　　loc_2　　　　　　　　　　　　　　

　　　　　　　　　 cmp　　 data_1[bx],al　　　　　　　　　　

　　　　　　　　　 jne　　 loc_2　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 byte ptr data_1[bx],'x'　　　　　

　　　　　　　　　 dec　　 dl　　　　　　　　　　　　　　　

　　　　　　　　　 jz　　　short loc_3　　　　　　　　　　　

　　　　　　　　　 mov　　 al,'o'　　　　　　　　　　　　　

　　　　　　　　　 call　　bestMove　　　　　　　　　　　　

　　　　　　　　　 mov　　 [si],al　　　　　　　　　　　　　

　　　　　　　　　 call　　isWin　　　; 判断是否已取得胜利　

　　　　　　　　　 jnc　　 loc_1　　　　　　　　　　　　　　

　 loc_3:　　　　　　　　　　　　　　　　　　 　 　　　　　

　　　　　　　　　 call　　printBoard　　　　　　　　　　　

　　　　　　　　　 mov　　 ax,4C00h　　　　　　　　　　　　

　　　　　　　　　 int　　 21h　　　　　　　　　　　　　　　

　 data_1　　　　　db　　　'12'　　　　　　　　　　　　　　

　 data_2　　　　　db　　　'3456789'　　　　　　　　　　　　

　 data_3　　　　　db　　　0　　　　　　　　　　　　　　　　

　 tictac　　　　　endp　　　　　　　　　　　　　　　　　　

　 printBoard　　　proc　　near　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 si,offset data_1　　　　　　　　

　　　　　　　　　 mov　　 di,548h　　　　　　　　　　　 　

　　　　　　　　　 mov　　 cl,3　　　　　　　　　　　　　　

　 locloop_4:　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 movsb　　　　　　　　　　　　　　　　　　

　　　　　　　　　 add　　 di,5　　　　　　　　　　　　　　

　　　　　　　　　 movsb　　　　　　　　　　　　　　　　　　

　　　　　　　　　 add　　 di,5　　　　　　　　　　　　　　

　　　　　　　　　 movsb　　　　　　　　　　　　　　　　　　

　　　　　　　　　 add　　 di,133h　　　　　　　　　　　　　

　　　　　　　　　 loop　　locloop_4　　　　　　　　　　　　

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　

　 printBoard　　　endp　　　　　　　　　　　　　　　　　　

　 isWin　　　　　 proc　　near　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 bx,1　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 bp,3　　　　　　　　　　　　　　

　　　　　　　　　 call　　sub_3　　　　; 检查横向是否完成　

　　　　　　　　　 inc　　 bx　　　　　　　　　　　　　　　

　　　　　　　　　 inc　　 bx　　　　　　　　　　　　　　　

　　　　　　　　　 dec　　 bp　　　　　　　　　　　　　　　

　　　　　　　　　 dec　　 bp　　　　　　　　　　　　　　　

　　　　　　　　　 call　　sub_3　　　　; 检查纵向是否完成　

　　　　　　　　　 call　　sub_4　　　　; 检查斜向是否完成

　　　　　　　　　 clc

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　

　 isWin　　　　　 endp　　　　　　　　　　　　　　　　　　

　 loc_5:　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 stc　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　

　 sub_3　　　　　 proc　　near　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 ah,3　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 si,offset data_1　　　　　　　　

　 loc_6:　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 di,si　　　　　　　　　　　　　　

　　　　　　　　　 call　　sub_5　　　　　　　　　　　　　　

　　　　　　　　　 add　　 si,bp　　　　　　　　　　　　　

　　　　　　　　　 dec　　 ah　　　　　　　　　　　　　　　

　　　　　　　　　 jnz　　 loc_6　　　　　　　　　　　　　　

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　

　 sub_3　　　　　 endp　　　　　　　　　　　　　　　　　　

　 sub_4　　　　　 proc　　near　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 di,offset data_1　　　　　　　

　　　　　　　　　 inc　　 bx　　　　　　　　　　　　　　

　　　　　　　　　 call　　sub_5　　　　　　　　　　　　　

　　　　　　　　　 mov　　 di,offset data_2　　　　　　　　

　　　　　　　　　 dec　　 bx　　　　　　　　　　　　　　　

　　　　　　　　　 dec　　 bx　　　　　　　　　　　　　　　

　　　　　　　　　 call　　sub_5　　　　　　　　　　　　　　

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　

　 sub_4　　　　　 endp　　　　　　　　　　　　　　　　　　

　 sub_5　　　　　 proc　　near　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 cl,3　　　　　　　　　　　　　　

　 locloop_7:　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 cmp　　 [di],al　　　　　　　　　　　　　

　　　　　　　　　 jne　　 short loc_ret_8　　　　　　　　　

　　　　　　　　　 add　　 di,bx　　　　　　　　　　　　　　

　　　　　　　　　 loop　　locloop_7　　　　　　　　　　　　

　　　　　　　　　 add　　 sp,4　　　　　　　　　　　　　　

　　　　　　　　　 jmp　　 short loc_5　　　　　　　　　　　

　 loc_ret_8:　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　　　　　

　 sub_5　　　　　 endp　　　　　　　　　　　　　　　　　　　　　　

　 bestMove　　　　proc　　near　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 bx,31FEh　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 cl,9　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 di,offset data_1　　　　　　　　　　　　

　 locloop_9:　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 cmp　　 [di],bh　　　　 ; #empty?　　　　　　　　

　　　　　　　　　 jne　　 short loc_12　　; #no, skip　　　　　　　

　　　　　　　　　 mov　　 [di],al　　　　　　　　　　　　　　　　　

　　　　　　　　　 pusha　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 call　　isWin　　　　　 ; #CY: Win　　　　　　　

　　　　　　　　　 popa　　　　　　　　　　;　　　　　　　　　　　　

　　　　　　　　　 jnc　　 short loc_10　　;　　　　　　　　　　　　

　　　　　　　　　 mov　　 bl,1　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 si,di　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 [di],bh　　　　　　　　　　　　　　　　　

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　　　　　

　 loc_10:　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 pusha　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 xor　　 al,17h　; good! toggle 'o' / 'x'

　　　　　　　　　 call　　bestMove　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 data_3,bl　　　　　　　　　　　　　　　　

　　　　　　　　　 popa　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 ah,data_3　　　　　　　　　　　　　　　　

　　　　　　　　　 neg　　 ah　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 cmp　　 ah,bl　　　　　　　　　　　　　　　　　　

　　　　　　　　　 jle　　 short loc_11　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 bl,ah　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 si,di　　　　　　　　　　　　　　　　　　

　 loc_11:　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 mov　　 [di],bh　　　　　　　　　　　　　　　　　

　 loc_12:　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 inc　　 bh　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 inc　　 di　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 loop　　locloop_9　　　　　　　　　　　　　　　　

　　　　　　　　　 cmp　　 bl,0FEh　　　　　　　　　　　　　　　　　

　　　　　　　　　 jne　　 short loc_ret_13　　　　　　　　　　　　

　　　　　　　　　 xor　　 bl,bl　　　　　　　　　　　　　　　　　　

　 loc_ret_13:　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　 retn　　　　　　　　　　　　　　　　　　　　　　

　 bestMove　　　　endp　　　　　　　　　　　　　　　　　　　　　　

　 code　　　　　　ends

　　　　　　　　　 end　　 start　　　　　　　　　　　　　　　　　　

Copyright &copy; 1998-2003 www.chinagamedev.net All Rights Reserved.

网站维护 [email protected]

站务合作 [email protected]

多元化的即时战略AI

关于如今即时战略的AI，实在不想多说。如今没有几个不是通过电脑作弊

而完成看似高AI的即时游戏。因为电脑和其操作是一体的。所以自然速度

要快。但是如此就是对玩家不公平。

完成一个高AI，就需要赋予电脑在不同情况下的思考能力。思考的越严密，

仿真程度就越高。而其思考的过程就是分步的判断敌我双方的状态。

举个地形AI的例子：

我们把整个地图根据地形分成若干个区域，分别以不同的字母来标记。如

地图中央有一块易守的高地（攻10防10移3）。设区域为A，A的西北方三

块区域为缓坡，设为B、C、D三个区域，皆为草地（攻6防4移7）。A东南

三块区域为陡坡，设为E、F、G，为石路（攻7防3移8）。

A对其他的区域攻击可以用冲锋、弓箭和落石。冲锋是主动攻击，刨除在

外，单以守来说，对付B、C、D应该用落石，E、F、G用弓箭。如此才能

达到最大的效果。

除此之外还要判断敌人的兵种和速度，来决定进一步的细节战术。

因此在发现敌人后的第一部应该是判断敌人所在的区域，其次是自己的区

域，再后是敌我的兵种。如此一来就能判断最佳的攻击方式。

换低地的攻方，在判断攻取地形标记为A后判断自己的地形，然后决定前

进方式，如果是在缓坡，为了防落石应该采取蛇行前进，而陡坡则应该

突击来减小损失。最后实时检测敌人状态来变换战术。

然后应该加入兵种的判断，以决定最佳的战术。每种兵种应该有自己单

一的AI判定和对付任何兵种时的多种战术。在特殊的地形应该有其独有

的特殊处理AI，如，在一个关口，骑兵可以一夫当关，或是退后诱敌

（须判断自己周围的部队），然后弓箭手配合伏击……

按此方法引深，可以策划出一套极其优秀的战术性AI，但是其缺点是AI

运算取决于机器的速度，如果机器速度慢的话就会在运算时发生停顿。

对于机器配置低的玩家是不公平的，解决办法是尽量优化AI程序。

前面提到了兵种自己单一的AI，这种设置会使整体的战局变得多样。同

时因为，现在许多游戏都是总体AI，例如某士兵发现敌人，于是全军都

知道了。按理说应该是士兵的通报有一定的范围，就象盟军敢死队里一

样，只有离其最近的单位才有可能得知。

因此，玩家的设置应该是可以看得到所有部队，但是只能看到所选部队

势力范围内的敌人。敌人同样如此，一个士兵发现敌人以后，按其兵种

及其位置作出判断，有能力的话，单独进行破坏，不行的话，回去报告

部队。

如此方法，实时地图系统应该取消，代之以势力范围地图，只有自己变

化或己方部队发现敌人变化后，地图才产生变化。

………………

……………………

想来想去，即时战略的AI可以开发的地方实在是太多了……

谈谈模拟足球游戏中人工智能

当球队进攻时，对于有球队员来说，它(暂且用它咯)在每一个瞬间都会有一个行为指导，也就是下一步行为：是向某方向带球？还是以某种方式传球给队友中的某一人？或者即是立即射门。这个指导行为从何迩来？又如何根据状况得以改变？不管情况怎样变化，使球员能在任何时刻都有一种较为合理的下一步行为为备，这样大概便可以模拟出踢足球的AI了。

其实足球AI模拟的关键就在于会让球员能较为聪明合理地分析球场上瞬息万变的赛况，并根据这个判断得出一个更为聪明合理的下一步行为。能力好的球员会不断的分析，从而迅速地调整它的行为而得以使比赛向更为有利的趋向发展，这个过程不断地持续，一场计算机AI模拟的高水平足球赛便可得以实现了。

第一个难度便是如何教会让AI球员判断场上的情况，如何产生AI分析，如何得出结论并生成下一步行为。

第一步是视觉判断：

带球球员能看到队友及对方的行为，从离它近的到离它远，无论在它前面或是在它侧面甚至是在它身后的，优秀的球员都能够感知。也就是模拟使AI球员“视野开阔”。这些信息可以很方便地从SIM比赛中球员的坐标，速度，动作数据得来，模拟起来并不算太难。

第二步是赛况分析：

也就是说使球员在视觉信息采集后产生一个意图，使比赛能更为向我方有利地发展。（比如：队友位置都不太好，无法穿球，AI使它得出了继续运球的意图；当它离球门距离不太远，有一定的射门空挡，AI便使它得出带球射门的意图；当有队友的跑位出现空挡时，AI便使它产生了向其分球射门的意图；当两侧队友跟进到位时，AI便使它产生向其穿球打下底穿中的意图）

这些都是第一步行为意图，是战术的雏形。

从这些极其离散的视觉采集信息（就是那些敌我双方球员坐标，速度，行为甚至能力）而产生一个战术意图看起来是非常玄妙而神秘的。殊不知，聪明的人类却能够从这些离散而无规的数据中能提炼出非常多隐藏在内的有用的比赛信息！而AI模拟的任务就要让COM球员学会找出这些隐藏的信息！

因此可以将导向式思考（利用经验规则导向）与推论式思考（用极大极小法推导出最佳行为）两种方式合理巧妙地结合起来。

另一个重要的因素便是将大量隐藏信息进行“过滤”，也就是说，AI需要找出最有价值（或者讲是合适）的隐藏信息，这里有随机因素，也有权排序。

最后一步便是根据所产生战术意图而形成一个下一步行为：

这很像是一个细节处理，因为下一步行为行为是随时在频繁地改变，而战术意图相对来说是较为稳定的。（毕竟近处看得多，远处观的少）实现下一步行为便是这个SIM足球的“动作引擎元素”，合理的动作元素可以使模拟比赛的可视性更为真实，更重要的是它能够与AI相互配合，这两者可以说是相辅相成缺一不可的（呵呵~哲学课考试我用的最多就是这句话：）FIFA的缺陷便在于它的动作引擎元素没有WE系列合理真实，这便直接导致了它的真实性不如WE，AI做的再棒也无济于事。

总结：AI球员通过观察赛况，找出离散数据的隐藏信息，得出了一个战术意图，做出了一个动作行为，这便就似完成了一个TURN。剩下的，SidMeier有一个很有用的经验思路：“我先教它如何玩一个回合开始。然后教它如何玩两个回合，再后来就该考虑教它如何玩10个回合了。”当然，SIM足球的AI也许会更复杂，因为我们只考虑了有球球员AI模拟的一个例子，但是我相信这3个部件是适用与足球场上每一个情况的，要做的只是更深入的分析，体会，感悟。

电脑AI浅谈

一说到电脑AI（人工智能），就会有人认为它是高深莫测东西。其实并没那么复杂，电脑AI其实是一组if语句。各类型游戏有各类型的AI，RPG（冒险类）游戏的AI最简单，只要用函数产生随机数在对攻击对象取余即可，稍微复杂点的也只增加了道具、魔法攻击，其AI性质都是一样的。例如：

attack(((unsigned)biostime*rand())%3);/*电脑攻击函数*/

这是一个虚拟的函数，代码省略了。我们关心的只是它的入口，我们定义它的入口为要攻击的对象。选择对象使用了随机数与时间共同工作，这样敌人就在3个攻击对象中随机地选择攻击对象了。

　　在这个语句中，没有使用if选择语句。在这个语句中，我方3个对象受攻击的概率是均等的，其实我们还可以将电脑AI提高一下，让电脑选择我方最弱的对象攻击的机率提高一下。程序改为：

int i,leastblood=20000,weakest;/*leastblood存储最弱对象的血量（初始化为一个比所有对象的可能血量都大的值），weakest存储最弱对象的代号*/

for(i=0;i<3;i++)

{ if(blood[i]<leastblood)/*blood数组为已知的我方对象的血量*/

　{leastblood=blood;weakest=i;}

}

i=((unsigned)biostime*rand())%4;

switch(i)

{ case 0:

　case 1:i=leastblood;break;

　case 2:i=(leastblood+1)%3;break;

　case 3:i=(leastblood+2)%3;break;

}

attack(i);

这样，最弱对象受攻击的机率就提高到了1/2，哈，电脑变聪明了。电脑AI设计是不是很简单？其实电脑AI有深有浅，这只是一个最简单的而已。要深奥，只不过是把制约的条件增多罢了。

　　相对来说，RPG游戏AI是最容易设计的。其次是SLG游戏，SLG游戏电脑AI一般遵循的规则有：最弱对象攻击原则、就近攻击原则、最大攻击力原则。在这三个原则中，排在最先的是就近攻击原则，即电脑对象要攻击，则向距离该对象最近（最省MP）的对象靠近攻击。排在第二的是最弱对象攻击原则，在可以攻击到的对象中，选择最弱的对象进行攻击。排在第三的是最大攻击力原则，如果电脑选中了一个攻击目标，则会使用电脑对象能使用的最大攻击力的方式去攻击。你可能会问，知道电脑如何行动了，那玩游戏对电脑行动不是了如指掌了？不，我不是说过AI的深度与制约条件有关吗？制约电脑行动的条件远不止这些。如电脑游戏就有一种攻击指定目标的玩法。在这种模式下，电脑优先攻击的就是你指定保护的目标了。而且，如果加入魔法机制，电脑的行动就不光是攻击了，而且要定义使用魔法的条件，程序将更为复杂。

　　再谈谈影响电脑AI的状态的游戏脚本，游戏脚本就跟乐器演奏的乐谱一样，影响着整个游戏进程：在什么时候、什么条件下执行什么动作，地图上出现什么，消失什么，谁的状态（如攻击力、防御力等）的改变。都要在游戏脚本中详细说明，只不过是使用符号化的语言而已。可以说游戏脚本就是一种解释类的AI。游戏脚本是非常重要的，RPG游戏不用说，因为RPG游戏几乎是单线式的，绝对需要脚本的支持。而在SLG游戏中，也是非常的重要。比如说，在一关设计时我布置了大量的强大的敌人。如果不用脚本加以控制的话，那么敌人将蜂涌而上，玩家绝对吃不消。而使用脚本控制后，每隔一定时间后有一部分敌人进入搜寻并攻击状态，其它的敌人仍然在待机状态。玩家将敌人一部分一部分吃掉，即不费多大力，又有一种一对N的成就感，娱乐的目的就达到了。ACT（动作类游戏）中，也要使用脚本控制游戏进程，不过这种脚本非常简单，只要写明什么地方出现什么敌人，什么机关工作就可以了。即时战略游戏的脚本相对复杂和抽象，既然是浅谈，这里就不用说了