在任何游戏引擎中，声音是跟图象一样重要的。不幸的是，声音经常不如画面渲染、物理、动画、人工智能及游戏性那么受重视。一个佐证便是: 程序员经常在写代码的时候把扬声器关掉!(事实上，我知道有许多甚至没有扬声器或者耳机的游戏程序员)。但是，离开优秀声音引擎，没有哪个伟大的游戏能完成。音乐层如图1.27所描述。
声音引擎变化多样。Quake和Unreal的声音引擎都非常基础，游戏开发团队经常通过自定义的功能或者用私有的(in-house)解决方案取代它来增加声音引擎。对于DirectX平台(PC和Xbox 360)，微软提供一个叫做XACT的卓越的声音工具集。EA开发了一个先进、强劲的叫做SoundR!OT的声音引擎。与第一方工作室有关的如Naughty Dog, Sony Computer Entertainment America(SCEA)提供一个叫做Stream的强大的3D声音引擎，它已经用在大量PS3的游戏如Naughty Dog的Uncharted: Drake's Fortune。不过，即使游戏开发团队使用一个已有的声音引擎，每个游戏仍需要大量的定制的软件开发、整合、调整，以及细节上的东西，以便在最终产品中有一个高质量的音效。
1.6.14 多人在线/网络(Online Multiplayer/Networking)
许多游戏允许在一个虚拟世界中有多个玩家游戏。多人游戏至少有四种风格：
* 单屏多人(Single-screen multiplayer). 两个或多个人机接口设备(HID)(手柄， 键盘， 鼠标等)连接到唯一一台街机(arcade machine)、PC或者家用机(console)上。多个玩家共存在一个虚拟世界中，一个唯一的摄像机同时让所有的玩家在画面上。这种类型的游戏包括: Smash Brothers, Lego Star Wars, Gauntlet.
* 分屏多人(Split-screen multiplayer). 多个玩家共存于一个虚拟世界，多个HID连接到一台游戏机，不过每个人都有自己的摄像机，屏幕也被分成多个区块以让所有的玩家都可以看到自己的角色。
* 多人联网(Networked multiplayer). 多台计算机或者家用机通过网络连接在一起，每台机器是其中某个玩家的主机。
* 大型多人在线游戏(Massively multiplayer online games MMOG).就如字面意思所示，成百上千的玩家，可以同时在一个巨大的、稳定的、在线的由一个强大的中央服务器作为主机的虚拟世界中游戏。多人游戏网络层如图1.28所示。
多人游戏跟他们的单人版本在许多地方有相似之处。不过，要支持多人游戏，在游戏引擎模块设计上都会造成一个很大的影响。。游戏世界对象模型，渲染器，HID，控制机制，动画机制都会完全受影响。把多人游戏的特性添加到一个已有的单人游戏引擎基本上不是完全不可行，尽管它是一个让人望而却步的任务。尽管如此，许多游戏团队成功的做到了。那说明，如果你能接受那么奢侈的话，最好是从开发的第一天就开始把多人特性考虑进去。
这个是非常有意思的，如果是从另外一个方向的话 - 把一个多人游戏变为一个单人的 - 是一件非常简单的事。事实上，许多游戏引擎把单人游戏模式视为多人游戏的一个特例，这种情况刚好只有一个玩家。Quake引擎由于它的client-on-top-of-server模式而闻名:一个唯一的可执行程序，运行在一台PC上，在单人作战模式中即扮演客户端又扮演服务器。
1.6.15 游戏可玩性基础系统(Gameplay Foundation System)
"游戏可玩性"(gameplay)这个术语涉及到游戏中的事件的发生，管理游戏所在的虚拟世界的规则，玩家控制角色的能力(即player mechanics)及世界中其他角色和物件的能力，及玩家的目标。游戏可玩性可以用实现引擎其它部分的同样的语言来实现，或者用一个高级脚本语言来实现，有时候两者皆用。作为连接游戏可玩性代码及我们之前讨论了很多的低级引擎模块的桥梁，多数游戏引擎引入一个我称之为gameplay foundation的层(因为没有一个标准的名字).如图1.29所示，这一层提供了一套核心的工具，游戏逻辑在它之上可以很便的实现。
图1.29 gameplay foundation layer
1.6.15.1 游戏世界及物件原型(Game Worlds and Object Models)
游戏可玩性基础层引入了游戏世界的概念，包括静态和动态的元素。世界的内容一般用一个面向对象的方式作为原型(一般，但并不一定，使用一个面向对象的编程语言). 在本书中，组成游戏的物件类型集合叫作游戏物件原型(game obejct model).游戏物件原型为游戏中的不同种类的物体提供了一个实时的模拟。
典型的游戏物件包括:
* 静态的背景几何图形，如建筑物、路、地形(往往是某一特定类型)等
* 动态刚体，如石头、汽水瓶、椅子等
* 玩家控制的角色(PC)
* 非玩家控制的角色(non-player characters, NPC)
* 武器
* 投射物
* 车辆
* 灯光(可能出现在运行时的动态场景中，或者仅仅用于离线的静态光照)
* 摄像机
* 等等
游戏世界原型很紧密的依赖于软件对象模型(software object model)，这种模型可以遍布于整个游戏引擎。软件对象模型涉及到用来实现面向对象软件的语言的特性、政策及方便性。在游戏引擎的情况中，软件对象模型回答以下问题：
* 你的游戏引擎是用面向对象的方式设计的吗？
* 你会使用哪种语言？C? C++? Java? OCaml?
* 这些类的关系将如何组织？一个巨大的紧密集成的层次关系，还是一些松散的联结的模块？
* 你会使用模板和policy-base的设计吗？或者传统的多态？
* 对象怎么被引用？直接的指针？智能指针？句柄？
* 对象怎么被唯一的识别？内存中的地址？名字？全局唯一的标识号？(Golobal Unique Identifier, GUID).
* 游戏物件的生命周期如何管理？
* 游戏物件的状态如何随着时间模拟？
我们将对软件对象模型和游戏物件原型在14.2节进行深入讨论。
1.6.15.2 事件系统(Event System)
游戏物件总是需要跟其它的物件交流。这个可以有多种方式来实现。比如，发送消息的物件可以简单的调用收消息的物件的成员函数。在一个事件驱动(Event-driven)机制下，就像一个典型的图形用户接口一样，也是一种常见的内部物体交互的机制。在事件驱动机制下，发送者创建一个小小的称之为事件(Event)或者消息(message)的数据结构，包含有消息的类型或者其它被发送的任何参数。这个事件通过调用它的事件处理机制(event handler function)传递给接收者。事件也可以存在一个队列中以便将来某个时刻处理。
1.6.15.3 脚本系统(Scripting System)
许多游戏引擎采用脚本语言以更加方便和快速的开发游戏特定的可玩性的规则和内容。没有脚本语言的话，每次对引擎中的逻辑或者数据结构的改动，你必须重新编译和链接你的游戏可执行程序。但当整合了一个脚本语言到引擎中的话，对游戏逻辑和数据的改动只需要修改和重新读取脚本代码就可以了。有的引擎还可以让游戏运行时重新读取脚本。有的引擎则需要在重新链接接脚本之前停止游戏。不管哪种情况，这个都比重新编译链接游戏可执行程序要快很多。
1.6.15.4 人工智能基础模块(Artificial Intelligence Foundations)
传统上，AI处在游戏软件的边缘 - 本质上并不认为它是游戏引擎的一部分。不过最近，游戏公司认可了在几乎每个AI系统中都存在的模块的出现，这个基础模块慢慢的被严格的认为是游戏引擎的一部分。
一个叫做Kynogon的公司开发了一个叫做Kynapse的商业AI引擎，在作为"AI基础模块"的它上面开发游戏AI逻辑可以更加容易。Kynapse提供一个非常强大的特性集，包括:
* 一个路径节点及漫游区域的网络，它们定义了人工智能角色可以自由移动而不必担心撞到世界地形的区域或者路径。
* 每个自由漫游的区域的简单的碰撞信息
* 某个区域的入口及出口的知识，以及在每个区域的哪个位置敌人可以看到或者偷袭你.
* 基于A*算法的寻路引擎
* 挂到碰撞机制和世界原型中，作视线追踪(line of sight traces)和其它感觉。
* 定制的世界物件原型，可以告诉AI感兴趣的所有的实体(同盟、敌人、障碍)，允许动态的避开移动的物体，等等
Kynapse也提供一个AI描述层，包括大脑(brain)的概念(每个角色一个)，代理(每个负责处理一个特殊的任务，如从一个点移动到另外一个点，向敌人开火，寻找敌人，等等)，和动作(负责处理角色表现一个基本的行动，结果一般是在角色的骨骼系统上播放一个动画).
1.6.16 游戏特定子系统(Game-Specific Subsystems)
在游戏可玩性基础层和其它低层引擎组件之上，游戏可玩性程序员和策划们通力协作来实现游戏本身。游戏可玩性系统一般是数目众多、变化也多，并且根据开发的游戏而定制的。如图1.30所示，这些系统包括但不限于玩家控制的角色的结构，游戏中的摄像机系统，NPC的AI，武器系统，车辆，等等。如果说引擎和游戏之间有一条明显的分界线的话，那么就是游戏特定子系统跟游戏可玩性基础系统。事实上，这条线不可能真的那么明确。至少有的游戏定制子系统会渗透到游戏可玩性基础系统中，甚至引擎内核之中。
图1.30 Game-specific Subsystem
2772
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
