作者：程东哲
出版社：人民邮电出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
游戏引擎原理与实践 卷1：基础框架试读：
前言
写作本书的缘由游戏引擎技术在国外发展十分迅速，根本原因在于国外的从业者有很扎实的基础，每一代引擎都是根据游戏迭代而来的。国内游戏行业起步相对较晚，再加上从业者有时急于求成，引擎的人才积累远远不如国外，导致国内的自研引擎企业寥寥无几。学习游戏引擎开发的门槛很高，不具备一定知识是很难自学的，这就让很多想学习引擎的人觉得遥不可及。
本书主要讲解游戏引擎的制作与开发，通过详细的引擎代码示例来剖析引擎中的内部技术。书中内容有些是目前市面上比较成熟的解决方案，有些是作者优化并改进的新的架构，对学习和研发引擎开发有很大帮助。如果使用商业引擎，本书对理解引擎的内部架构并很好地使用引擎也会帮助很大。
通过本书，读者可以清晰地了解大企业制作引擎的基本流程和思路，从而以高效地制作游戏为最终目标。一个好的引擎应该做什么，不应该做什么，本书都会详细介绍。本书内容
本书的很多概念都来自Unreal Engine，但决不是照搬Unreal Engine来讲解。本书配套引擎的代码只有不到10%的地方参照了Unreal Engine，大部分内容是通过另一种方式甚至采用其他的架构来实现的。本书首先帮助读者理解什么是游戏引擎以及游戏引擎的组成部分，让读者对游戏引擎有一个全面的认知。通过“盖楼”的方式，一步步帮助读者建立游戏引擎底层模块，这些底层模块是游戏引擎的基石，帮助游戏开发人员和游戏引擎进行有效的“沟通”，并为在游戏引擎中实现动画、渲染等高级效果提供很好的保障。本书配套的自研引擎叫作VSEngine，作者在实际工作中的一些技术思路和尝试都以它为基础，随着作者自身能力的提升，这个引擎也先后重构过多次。
本书提供了100多个示例，尽可能透彻地说明问题，其中标题带*号的章节都没有给出具体的实现，而只是介绍了详细做法。读者如果想真正掌握本书的知识，就应该完全自己去实现它们。同时每章都有一些练习，有一些是作者准备实现但没时间去实现的；有一些练习很难，即便是经验丰富的引擎开发人员，如果没有这方面的实践，也需要认真思考一番。
本书计划分为两卷出版。卷1主要涉及游戏引擎的基础架构，一共13章，各章主要内容如下。
第1章并没有像其他传统技术图书那样介绍游戏引擎，而使用一个例子去解释什么是游戏引擎，并从一个引擎开发者的角度剖析一些引擎开发的问题。
第2章介绍引擎和引擎编辑器，以及学习引擎所需要的基础知识。
第3章介绍一些底层基础部分，包括文件系统、线程系统、内存管理等和底层跨平台相关的内容。
第4章介绍引擎中使用的基本数据结构，包括数组、队列、链表等类型，这些数据结构没有采用第三方库，都是重新实现的。
第5章介绍数学库，这里并没有介绍每一种数学算法，而只列出本书配套引擎的数学库中的相关代码和功能，并给出具体算法的出处。
第6章讲解引擎初始化方面的知识，引擎中存在很多单件实例管理器、默认值、默认资源，有效地初始化它们是很有必要的。
第7章介绍应用程序框架。不同平台对应的程序入口和执行流程不同，有效地跨平台和用统一的流程管理成为游戏设计中很重要的一个方面。该章还介绍如何关联不同的输入/输出设备到引擎中。
第8章介绍引擎中的对象系统，包括智能指针、RTTI、属性和函数的反射与复制、存储、加载、克隆（clone）、属性与UI的映射。该章最后还介绍了Unreal Engine 4的反射机制。强大的对象系统是一个好的引擎必不可少的。
第9章介绍引擎中资源的管理，包括外部资源和内部资源，并讲解如何有效组织这些资源。
第10章介绍引擎设计的一些哲学理念。深入了解引擎设计理念对于使用和制作引擎都有很大帮助。该章最后一节介绍的内容是引擎设计哲学的一个延伸，有助于读者全面了解垃圾回收机制。
第11章讲解场景管理，包括管理场景物体和相机之间的裁剪关系。该章最后简单介绍遮挡剔除。
第12章介绍如何把一个FBX静态模型导入为引擎格式的静态模型，并添加材质和渲染。
第13章讲解LOD技术，包括如何生成模型的LOD以及集成到引擎中进行渲染，同时介绍在引擎中如何加入和实现地形。
游戏引擎的其他一些相关内容，包括骨骼模型、动画、渲染技术、多线程以及其他额外话题，将纳入《游戏引擎原理与实践 卷2：高级技术》中。本书特色
不同游戏引擎的内部架构千差万别，而且游戏引擎涉及的知识点甚多，很少有人能全面把握每一个知识细节。同时，游戏引擎属于实践性的工程，必须有足够令人信服的演示示例以及代码支持，加上商用引擎的授权、作者个人时间有限等各方面的因素，导致市面上的游戏引擎图书要么泛泛而谈，要么距离真正开发游戏相去甚远。读者阅读完这类图书之后，并不知道一个商业引擎应该具备什么，应该如何写一个商业游戏引擎。本书旨在弥补目前市面上引擎图书的不足之处，尽量详细地解答上面所涉及的问题。
目前国内有自研引擎能力的公司和个人都很少，本书提供了一个良好的知识储备，帮助没有写过商业引擎的人揭开游戏引擎的神秘面纱。读者只要详细阅读本书并了解每个知识点，就能够极大地提升引擎开发能力。即使你使用商业引擎，通过阅读本书，也能够更好地理解引擎机制，在使用相应的游戏引擎的时候更加得心应手，同时你还将具备修改商业引擎的能力。读者对象
本书要求读者熟练掌握C++、数据结构、3D编程、设计模式以及多线程的基础知识，否则对本书中的一些内容理解起来会比较困难。如果你有一定的3D游戏开发经验，或者你是想要尝试3D引擎开发的新手，本书会非常适合你阅读和学习。
本书对大部分比较难的知识点会详细讲解，而对于和游戏开发相关度较小的一些简单与基础的知识点，本书则会列出相关的图书和资源，推荐读者去阅读。
通过阅读和学习本书，读者能够：● 了解游戏引擎的基本原理和作用；● 了解大公司开发引擎的基本流程；● 获得良好的游戏引擎方面的知识储备；● 通过本书专门配套的引擎和示例，可以了解开发游戏引擎的具体
细节。资源支持
本书代码可以从异步社区（www.epubit.com）下载，其中包括本书配套引擎和为讲解引擎而准备的示例程序。作者简介
程东哲，游戏引擎开发工程师，吉林大学计算机硕士，现就职于腾讯公司，曾先后参与了《逆战》《斗战神》《众神争霸》《无尽之剑——命运XBOXONE》《云游戏》《Lucky Night VR》等游戏项目开发。主要负责游戏引擎开发工作，曾开发过腾讯内部自研May引擎和AGE引擎，修改和移植过Unreal Engine。致谢
感谢我的妻子对写作本书的支持。为了写作本书，我牺牲了很多陪伴家人的时间，没有他们的理解和支持，我不可能完成本书的写作。感谢人民邮电出版社的陈冀康编辑，本书是在他的一再推动和鼓励下完成的。
感谢叶劲峰先生为本书作序，同时感谢沙鹰、王杨军、王琛、付强等专业人士对本书的大力推荐。能够得到他们的肯定和支持，我感到万分荣幸。
感谢唐强、周秦、Houwb在百忙中帮助校验本书并修改本书配套代码，没有他们的努力，本书是无法顺利出版的。感谢熊路遥对13.5.2节的技术支持。
感谢本书的所有读者。选择了这本书，意味着你对我的支持和信任，也令我如履薄冰。由于水平和能力有限，书中一定存在很多不足之处，还望你在阅读过程中不吝指出。可以通过79134054@qq.com联系我。资源与支持
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。配套资源
本书配套资源包括相关示例的源代码。
要获得以上配套资源，请在异步社区本书页面中单击，跳转到下载界面，按提示进行操作即可。注意，为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
如果您是教师，希望获得教学配套资源，请在社区本书页面中直接联系本书的责任编辑。提交勘误
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可（见下图）。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。与我们联系
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/ selfpublish/submission即可）。
如果您所在学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。关于异步社区和异步图书“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。异步社区微信服务号第1章 引擎的纷争
游戏引擎究竟是什么？恐怕就算是资深行业人士也很难三言两语说清楚。让我们一起来敲开游戏引擎的大门，聊聊引擎的来龙去脉。1.1 什么是游戏引擎
什么是游戏引擎？其实这很难给出明确的定义。在很多游戏的宣传中，我们会听到对游戏引擎的推崇。绚丽的特效，流畅的体验，似乎都是游戏引擎的功劳。在游戏玩家看来，游戏画面的表现力越好，游戏场面的震撼程度越大，游戏体验的真实感越强，底层的游戏引擎就可能越强大。
看看业界给出的一些定义。
游戏引擎是指一些已编写好的可编辑计算机游戏系统或者一些交互式实时图像应用程序的核心组件。这些系统为游戏设计者提供编写游戏所需的各种工具，其目的在于让游戏设计者能容易和快速地写出游戏程序而不用从零开始。大部分游戏引擎支持多种操作平台，如Linux、Mac OS X、Windows。游戏引擎包含渲染引擎（即“渲染器”，含二维图像引擎和三维图像引擎）、物理引擎、碰撞检测系统、音效引擎、脚本引擎、电脑动画引擎、人工智能引擎、网络引擎以及场景管理引擎。
根据上述定义，在很多人看来，游戏引擎负责把很多已有的零部件组装起来，如同组装手机，CPU、屏幕、摄像头、主板等都是别人生产的，手机厂商按照自己喜欢样式组装一下就好了。
下面再看看Game Engine Architecture（中文书名《游戏引擎架构》）是怎么说的：
通常，游戏和其引擎之间的分界线是很模糊的。一些引擎有相当清晰的划分，一些则没有尝试把二者分开。在一款游戏中，渲染代码可能特别“知悉”如何画一只妖兽（Orc）；在另一款游戏中，渲染引擎可能只提供多用途的材质及着色功能，“妖兽”可能完全是用数据去定义的。没有工作室可以完美地划分游戏和引擎。这不难理解，因为随着游戏设计的逐渐成形，这两个组件的定义会经常转移。
似乎游戏界引擎专家也无法真正给引擎下一个明确定义，虽然大家都知道什么是游戏引擎，却很难用三言两语把它表述出来。本节尝试用比喻的方式把它讲清楚。
假设我们穿越回20世纪80年代，我们的手中已经有整套的FC游戏《超级马里奥》［见图1.1（a）］的代码，现在我们要开发另一款FC游戏《冒险岛》［见图1.1（b）］。此时我们需要从零开始吗？显然，这两款游戏有着太多共性，都是一个游戏角色在横板卷动的地图上蹦来蹦去，都可以踩死怪物。当然，也有不同，画面不同，声音不同，关卡不同……但对于共同的功能，聪明的我们当然会重用一些现成的代码。而这种横板卷轴游戏模板的通用性非常好，目前游戏界对它的需求量也非常大，所以我们决定把这种特定类型游戏的核心功能提炼出来，供那些也要开发这种游戏的人使用。（a）（b）图1.1 《超级马里奥》与《冒险岛》游戏画面
后来，蹦蹦跳跳的游戏逐渐没落，即时战略游戏开始兴起，有人要开发即时战略游戏《红色警界》（如图1.2所示）。图1.2 《红色警界》游戏画面
虽然游戏模板的代码能渲染2D动画、播放声音、处理鼠标键盘的按键响应，但无法用于即时战略游戏。因为玩家们想要的是多人联网，这就要求程序能够处理大量同屏2D动画，能够快速编辑适应即时游戏的关卡，能够运行无法与玩家和平相处的AI，甚至能够让游戏运行在不同的地方，比如PS1和PC。可是原有的游戏模板根本做不到这些。
直到有一天，卡马克设计了一款叫《DOOM》（中文名《毁灭战士》）的游戏（如图1.3所示），这简直就是PC（DOS系统）游戏史的一个里程碑。这款游戏漂亮的3D画面，让很多游戏爱好者在计算机前面“火拼”。图1.3 《DOOM》游戏画面
卡马克又写出了全3D的游戏《QUAKE》，而且支持当时最强大的3D加速卡，人们再次被震惊了。崇拜卡马克的人们用《QUAKE》的代码制作了新的射击游戏——《Counter-Strike》，也就是家喻户晓的CS。《QUAKE》的动画、渲染的程序也被拿来继续开发其他游戏。
故事总归是故事，但对于《冒险岛》来说，被复用的那部分《超级马里奥》代码其实就是最早的游戏引擎。不过它的技术没那么先进，功能也不甚强大，还缺乏顺应潮流的更新，以致最终销声匿迹了。但卡马克的代码则不同，它超越了当时人们的想象力。他不但为射击游戏制定了完整方案，而且实现的代码功能强大。其高度的复杂性和健壮性，甚至让很多人乐于用其中的某些模块去开发非射击类的游戏，结果不但节省开发时间而且游戏健壮性也不错。这几乎是一部简短的游戏引擎发展史。
我们为什么要如此辛苦地探讨引擎的定义？每个人心中都有自己的哈姆雷特，对错已经没那么重要。开发属于我们自己的游戏，了解哪个引擎更强大以及什么引擎更适合，才是研究游戏引擎的真正意义所在。1.2 那些年我们认识的引擎
关于引擎的第二个争论就是到底用哪个引擎。
从卡马克的时代开始，国外就有了关于游戏引擎的概念。根据游戏需求的不同，游戏厂商要么自己开发引擎，要么购买商业引擎。但真正的商业引擎不但必须有规范的开发流程，以便于定制化，而且要有后续的技术支持来帮助购买引擎的人解决遇到的各种问题，以保障购买者能够实现想要的功能。但能真正实现商业化的引擎也仅有少数几款。
商业引擎数量少，加之每款引擎的授权费用高昂，所以很多团队更愿意自己开发引擎。而几乎每一款知名游戏都有自己的引擎，比如育碧的《刺客信条》、EA的《战地》、科乐美的《实况足球》。但自家的引擎同样需要不断迭代，以保证跟上时代的发展，否则落后的游戏引擎终究会被淘汰。
在国内曾经技术匮乏的那个年代，Gamebryo和Ogre算是最早的两款引擎，Gamebryo是用得最多的商业引擎，Ogre是用得最多的非商业引擎。现如今，除了传统大厂商在自己迭代引擎之外，大部分厂商选择了商业引擎。国内厂商更是如此，在3D游戏引擎的选择上都很明确，手机端用Unity，PC端用Unreal Engine。这些引擎不同于以往特定类型的游戏引擎，它们耦合性很低，通用性更好。那些年风光的引擎如图1.4所示。图1.4 那些年风光的引擎
游戏引擎曾经百花齐放，如今则大局已定。那么自研引擎是否已是明日黄花了呢？
其实这个问题没有明确的答案。如果你的团队有实力，时间相对充足，已经成功开发出游戏，那么迭代自研发当然可以；但如果项目时间紧，要开发的游戏类型与团队已有的引擎类型大相径庭，改动成本高于学习其他商业引擎的成本，那么不妨使用相对成熟的商业引擎。1.3 引擎和游戏
这里并不是要讲游戏和引擎的关系，而是讨论开发引擎是否一定要依托于游戏。开发过游戏引擎的人，或多或少地想过这个问题。传统的游戏引擎都是依托游戏一代一代迭代发展起来的。对于游戏企业来讲，最终目的是做出游戏，所以游戏引擎的目标是为专属游戏服务。游戏需要什么特性，引擎就提供什么功能。商业引擎也是如此，如果一款游戏引擎没有支撑过任何成功游戏作品，大家是不敢去用的。毕竟使用游戏引擎的人一般不是专业引擎开发人员，出现问题后很难快速解决底层问题。就连Unreal Engine这样的引擎也要靠自己的《虚幻竞技场》来撑门面。目前，大部分引擎在内部使用，毕竟谁写的谁清楚，出了问题也能第一时间解决。
但是国外游戏引擎的开发氛围要好于国内，游戏引擎技术并没有完全被游戏牵着鼻子走，引擎技术也在反过来逐步推动游戏的发展。游戏引擎的开发者希望能持续地专注于引擎技术的开发，不会因过度依赖游戏而把引擎自身搞得一团糟。
不过到目前为止，还没有哪款引擎是能够满足以下几点要求的真正的万能架构：● 适合所有类型的游戏、所有的游戏功能；● 可以简单实现游戏设计者想到的各种离奇古怪的想法；● 极高的效率——事实证明，优化最好的引擎都是针对游戏本身
的。
引擎开发者心目中的理想引擎或者说许多游戏企业的自研引擎目标是：底层维护分离，具有统一的架构，可以通过底层为不同游戏提供不同的支持。为此，引擎技术人员尽最大可能把游戏需要的技术都完好地集成到引擎中，做到一款引擎可以服务多款不同类型的游戏。
然而，理想和现实往往有一定的距离，大部分引擎是为了一款游戏而生的，最根本的原因就是人的成本（这里成本是指技术人员能力、管理者能力、设计游戏能力、招聘、营销等与人的价值有关的东西）。国外Unreal Engine算是做得比较好的，Unreal Engine 3是比较成功的游戏引擎，用它开发的各种类型的游戏有许多。Unreal Engine算是人力成本相对较低的引擎，国外开发人员的经验积累使他们大多能把控Unreal Engine 3，而国内由于开发人员的能力差异，很少人能把控Unreal Engine 3（这里不谈市场因素）。
所以理想引擎的开发不得不依赖游戏。但事无绝对，Unity传奇般地解决了人的问题，传奇般地实现了当时很多大企业不敢做的事情。
抛开Unity易用性不说，它真正实现了引擎架构的组件化。更重要的是，许多人在为它开发功能，使用终极方式解决人的成本问题。这其实不是一个技术问题，即使有人曾经想过让很多人一起开发引擎，但谁又会想过这会成为现实呢？Unity自己没有耀眼的游戏。现在你几乎可以在网络上找到任何想要的内容，比如体素地形网格化、水流方向映射、反向动力学（Inverse Kinematics，IK）、材质树、技能编辑器，甚至大量的特效、模型、贴图、动画资源，铺天盖地的论坛、教程。Unity只提供底层的基础功能，大部分强大的功能是世界各地的人帮助它完成的，在它自己获益的同时，开发者也在获益。
Unity的出现几乎改变了整个商业引擎的格局，它的开放，它的易用性，它的开发流程，都完全超过当时人们的认知，导致一些设计观念陈旧的商业引擎加速地消亡。有能力转变的也只有Unreal Engine，虽然其庞大的代码库让它不能一下子实现转变，但它以快速的迭代不断追赶。Unity更强大的地方在于扩展，所有人都可以给它定制功能，这逼迫Unreal Engine不得不开源。开源的好处会让更多人关注它，为它定制更多的功能插件，许多问题可以轻松地在互联网上搜索到解决方案，这让它的社区也更加壮大。第2章 起航
现今，想要从头写一个功能强大的3D引擎，个人的力量恐怕难以胜任，即使能力足够，时间恐怕也不允许。在这个美好的开源时代，你只需具备修改各种引擎的能力便足以满足开发游戏的各项需求。现代游戏引擎的复杂级别已不同于以往。引擎中有错综复杂的功能模块，以及同样重要且复杂的游戏编辑器，其中的任何一方面内容都足以独立成书。然而，本书篇幅有限，实在难以面面俱到。我们将在这里迈出第一步，在游戏开发的海洋中扬帆起航。2.1 游戏编程
既然要开始游戏编程，首先要选择语言工具，C和C++是开发游戏引擎的首选。
游戏编程广义上讲可以分成游戏逻辑编程和游戏引擎编程。然而，它们两者之间的边界往往又没有那么泾渭分明。
游戏逻辑开发是指集中力量开发游戏中的剧情和玩法，要决定的是什么时候显示什么内容，什么时候播放什么声音，什么时候通过网络传输什么数据，什么时候这个物体或者人物做某个动作。至于图像如何显示，声音如何处理，数据如何传输，物体动作如何实现，游戏逻辑开发者其实并不用关心，这些归游戏引擎来处理。所以说游戏逻辑负责游戏核心玩法方面的内容，游戏引擎负责底层方面的处理。
有人可能会有疑问：“既然你解释了做什么和怎么做，那么可不可以理解为，我想开发一个已经写好了剧本的游戏，既然内容确定了，游戏引擎就应该能给我马上做出来，至于怎么做，我可以不关心吗？”是的，没错，只要你选择的游戏引擎足够强大。
成功的游戏是以好的游戏逻辑为基础的，虽然引擎并不是一款游戏成败与否的决定性因素，但好的游戏内容通过好的游戏引擎来实现，会给人一种全新的视觉和听觉感受，会更加震撼人心，这就好比传统的2D电影与3D乃至4D电影的效果对比。
游戏逻辑就像电影的剧本，至于能否拍摄出预期的效果，不但取决于导演对剧本的理解和演员的演绎，还取决于拍摄的技术和后期的特效处理。2.2 游戏引擎的组成
现在的游戏引擎比早些年的游戏引擎更加规范，通常包括图形引擎、声音引擎、网络引擎、脚本引擎、图形用户界面、人工智能引擎、物理引擎以及各种编辑器。
游戏画面能正常显示是最基本的要求，所以图形引擎是游戏的基石，其他模块则是为游戏添砖加瓦的。如果一个引擎同时具备下面7个模块，至少说明这个引擎的功能是比较强的。
现在很少有引擎全部自研所有模块，很多引擎通过第三方技术授权形式来实现相应模块的功能。（1）图形引擎——作为游戏的“基石”模块，图形引擎还是以各自实现开发为主，毕竟图形引擎还没能够抽象得那么完美。为了达到更好的画面效果和满足游戏的功能需要，研发图形引擎是必不可少的。（2）声音引擎——市面上用得最多的插件就是FMOD。除了可以播放音乐音效之外，FMOD还包括底层支持及各种声音资源的管理工作。（3）网络引擎——目前的网络引擎并没有一套完全成熟的解决方案，能同时满足各种游戏服务器类型，并且便于接入和开发。单从开发便捷来说，还是以Unreal Engine作为网络引擎比较好，既可用于客户端开发，也可以支持网络端，不过它的架构只适合做“开房间”的游戏。（4）脚本引擎——这里所说的脚本是面向游戏策划或用户的，可以是指令形式，也可以是简单语句。《魔兽争霸3》（见图2.1）就可以使用脚本写出很多有趣的游戏内容，还有当年的《红色警戒2》（见图2.2），甚至《国家的崛起》（见图2.3），玩家可以自己用脚本实现AI。如果希望更深入地了解这些高级的脚本语言，推荐阅读《游戏脚本高级编程》这本书。图2.1 《魔兽争霸3》游戏画面图2.2 《红色警戒2》游戏画面图2.3 《国家的崛起》游戏画面（5）图形用户界面（GUI）——包括血条、分数等在屏幕位置固定不变的2D图案。UI也可以做得很炫，不要小看UI，它也算是游戏里最重要的组成部分。业界比较知名的UI引擎是ScaleForm。（6）人工智能引擎——Unreal Engine内部有自己集成的AI，并且是带编辑器的。Unity也有专门的AI插件，可以到商店购买。这里推荐一些关于游戏AI的图书，如《游戏人工智能编程案例精粹》《游戏编程中的人工智能技术》《游戏开发中的人工智能》等。（7）物理引擎——多数游戏开发使用的是刚体和刚体运动、碰撞、射线检测、布料检测等功能，而使用软体和真实流体、气体等功能的则相对较少。现在市面上有Physx、Havok、Bullet三大物理引擎（Physx和Bullet开源了），如果读者想要零起步学习物理引擎，推荐学习《游戏物理引擎开发》《游戏开发物理学》《游戏中的数学与物理学》《实时碰撞检测算法技术》等图书。2.3 游戏引擎编辑器的组成
常用的引擎编辑器包括场景编辑器、粒子特效编辑器、模型浏览器、动画编辑器和材质编辑器。除了常用的以外，还有物理编辑器、AI行为树编辑器、脚本编辑器和技能编辑器。引擎编辑器不仅可以编辑各种资源，还负责管理和整理各种资源。按照现在引擎的设计理念，编辑器还包括性能分析、打包和部署以及版本发布等功能。
下面以Unity和Unreal Engine为例，列出一些功能编辑的界面，并介绍一些初步的概念。（1）场景编辑器，负责摆放模型物体、光源、摄像机等（见图2.4）。图2.4 场景编辑器（2）粒子特效编辑器，负责制作各种特效（见图2.5）。图2.5 粒子特效编辑器（3）模型浏览器，负责浏览和编辑模型（见图2.6）。图2.6 模型浏览器（4）动画编辑器，负责编辑动画功能，可以触发游戏逻辑中的某些事件（见图2.7）。图2.7 动画编辑器（5）材质编辑器，负责编辑模型效果（见图2.8）。图2.8 材质编辑器（6）资源管理器，负责管理游戏中各种资源（见图2.9）。图2.9 资源管理器
上面只是简单罗列了Unity和Unreal Engine的一些常用编辑器。对于新手而言，建议先看看Unity开发的相关图书，尝试开发简单游戏来熟悉各种编辑器。提示在接下来几节中，我们将回顾开发游戏引擎所需的基础知识。这里并不会详细地介绍每个部分。当然，书中会提及从哪里可以学习到这些知识，不过这并非本书重点。2.4 数学
数学可以说是引擎的根基，它的作用是不言而喻的。不但开发引擎需要数学知识，而且开发游戏逻辑也需要，所需知识基本覆盖了大学里与数学相关的所有课程——《高等数学》《线性代数》《概率与数理统计》。很多人可以把这些课程学得很好，但能创造性地应用在游戏引擎中的人寥寥无几，能把论文中高深的技术在游戏中真正实现出来的人更是凤毛麟角。加入游戏引擎里的数学算法，大多是已经非常成熟的技术，并且已经被标准程序库化，会有效地使用它们其实已经足够。
另外，本书提及的大部分数学知识是一些基础的数学知识，也是引擎中最常用到的。那种复杂的多重微积分的应用，本书并不涉及。下面列出的都是我们需要掌握的基本内容。强烈推荐《3D数学基础：图形与游戏开发》这本书。1．向量
向量（也称矢量）是指具有大小（magnitude）和方向的量。这是图形学和物理学中经常用到的概念，希望读者能了解2D、3D、4D向量的含义，标量和点的含义。在游戏中，3D向量既可以表示一个方向，也可以表示一个点。
读者还要了解向量之间的运算以及对应的含义，包括向量与标量的加减乘除、向量长度、向量点积、向量叉乘、向量单位化、向量加法、向量减法等。2．矩阵
矩阵也是图形学中最常用的概念，它的一个作用就是空间变换。对于没有学过线性代数的人来说，矩阵可能有些难以理解，不过也没关系，引擎中最常用的就是3×3矩阵和4×4矩阵。本书后面会详细讲述它们的功能。
不过这里还要了解关于矩阵的一些特性，包括矩阵的维度、矩阵的逆、矩阵的转置、单位矩阵、方阵、标量和矩阵相乘、矩阵和矩阵相乘、矩阵和向量相乘、向量和矩阵相乘（不同顺序得到的结果也不一样）、正交矩阵、向量与基向量的关系等。3．四元数
关于四元数，需要了解的包括四元数的定义以及四元数的模、单位四元数、四元数的逆、四元数的共轭、四元数的点乘和叉乘等，相关的内容在网上非常容易查到。4．几何体
引擎中的几何体基本是用来做碰撞检测和相交检测以及求相互距离的。所有的几何体都以参数化方式表示。
我们需要弄清楚的是直线、射线、线段、圆、三角形、矩形、平面、球体、立方体、胶囊体等。我们需要用到的是它们之间的相交检测以及点到它们的距离。5．欧拉角
欧拉角和坐标轴的指向没什么关系，它是按照方位来定义的，是以前向量（Roll）、右向量（Pitch）、上向量（Yaw）作为旋转轴得到的角度。按不同顺序旋转得到的结果是不一样的，一般有两种旋转顺序，分别为Roll→Pitch→Yaw和Yaw→Pitch→Roll。本书配套的引擎中采用的是第一种旋转顺序。
读者要深刻了解欧拉角、矩阵、四元数之间的相互转换关系。本书配套引擎中的转换关系如下。（1）分别绕z轴、x轴、y轴旋转AngleZ、AngleX、AngleY角度的矩阵和构建欧拉角的矩阵一样。Matrix(z Axis, AngleZ) * Matrix(x Axis, AngleX) * Matrix(y Axis, AngleY) = Matrix(Roll_AngleZ, Pitch_AngleX,Yaw_AngleY)（2）分别绕z轴、x轴、y轴旋转AngleZ、AngleX、AngleY角度的四元数和构建欧拉角的四元数一样。Quaternion(z Axis, AngleZ) * Quaternion (x Axis, AngleX) * Quaternion (y Axis, AngleY) = Quaternion(Roll_AngleZ, Pitch_AngleX,Yaw_AngleY)（3）欧拉角到四元数和矩阵的转换并不一定可逆，前提是AngleZ、AngleY的范围是[−π,π]，AngleX的范围是[−π/2，π/2]。至于为什么是这样，这里不做过多解释，读者可以根据公式自己推导。2.5 空间变换
接下来介绍3D引擎中的重要部分——空间变换，这也是许多初学者经常搞不懂的地方。2.5.1 坐标系
3D坐标系是由一个点和3个正交的方向组成的。也就是说，这个坐标系下任何一个点v都可以由3条正交的轴向表示（向量与基向量）。
大部分引擎使用的是左手坐标系。当然，也有一些引擎使用右手坐标系（见图2.10和图2.11），所以知道一个引擎是哪类坐标系后，接下来的运算才能正确地进行。不一定非要食指指向y轴，只要那个坐标系符合我们3个手指的方向就可以。图2.10 本引擎中的坐标系和Unreal Engine中的坐标系图2.11 左手坐标系和右手坐标系
一般用大拇指指向y轴，大部分引擎也是y轴向上。当然，也有z轴向上的，但无论什么样，都希望你能区分开。2.5.2 不同空间的转换
许多人看到空间的转换就会蒙头转向，根本原因是还没有掌握空间变换的基本原理。
线性变换满足以下关系式。
F(a+b)=F(a)+F(b)，并且F(ka)=kF(a)，其中，a、b是变量，k是常量，F是函数。
举个简单的例子，比如，函数F(x)=3x，这个函数就可以表示线性变换。
因为它满足F(a+b)=3(a+b)=3a+3b=F(a)+F(b)，同理F(2a)=3×2a=2F(a)。
下面介绍3D中最常用的两个线性变换。
缩放变换满足以下关系式。
F(x,y,z)=ax+by+cz，简单地说，就是把一个点或者一个向量v(x,y,z)的每个分量乘以一个比例系数。
一般情况下，无论什么样的线性变换，都是相对于当前坐标原点来说的，本书后面要提到的仿射变换也是这样。否则，应该表述为“相对于某个点A来进行缩放”。
图2.12说明了这一切：当相对于（2，0）放大2倍的时候，相当于以（2，0）为原点，原来的正方形（1，1）（1，−1）（−1，−1）（−1，1）首先平移到（−1，1）（−1，−1）（−3，−1）（−3，1），然后扩大两倍。图2.12 同一个单位正方形相对原点放大2倍和相对于（2, 0）点放大2倍
其实这里的第二个缩放已经不满足线性变换的条件了，而是后面要说的仿射变换。
旋转变换满足以下关系式。
F(a) = aM，a是变量，F是函数。在3D空间中，M是一个3×3的旋转矩阵，也就是说，如果它满足单位正交化，就满足线性变换。
之所以写成矩阵的形式完全是为了方便，而且矩阵运算满足对空间缩放的变换。在旋转变换中，最常用的就是绕x轴、y轴、z轴旋转或者欧拉角旋转，还有一个是绕某个方向旋转，其实它们之间是可以互相转换的。也就是说，绕某个方向的旋转可以用绕x轴、y轴、z轴的旋转来完成。
在准备自己写引擎的时候，一定要规定好自己的欧拉角和x轴、y轴、z轴向的关系，本书中的引擎里面用欧拉角构造矩阵的顺序是Roll→Pitch→Yaw（即z轴→x轴→y轴），不同的旋转顺序得到的结果会不同。在使用引擎的时候，要找到它们之间的关系。还有一个更重要的概念是旋转方向，不同引擎对方向的定义可能也不同。本书中规定，正角度的旋转表示顺着轴向看是逆时针的，也就是逆着轴向看是顺时针的（见图2.13）。图2.13 正角度的旋转
仿射变换是指线性变换后接着平移，也就是说，F(a)=Ma + T，其中T表示平移。
在3D空间中的大部分变换是仿射变换，当然，也有非仿射变换，比如投影变换、法线的切空间变换。无论是先平移再缩放后旋转，还是先旋转再缩放后平移，最后都可以转化成先缩放再旋转后平移。
这种形式下有F(a) = aSM+T，其中S表示缩放，M表示旋转，T表示平移。
比如，如果先平移再缩放后旋转，则有F(a)=(a+T)SM=aSM+TSM，其中S表示缩放，M表示旋转，TSM表示新的平移。
所以定义一个标准的顺序进行3D空间的仿射变换很重要，基本上所有的引擎采用先缩放再旋转后平移的顺序。
前面说过，仿射变换不一定用矩阵表示，完全可以用3D向量S表示缩放，四元数表示旋转，3D向量表示平移。但矩阵可以整合缩放、旋转和平移，这样进行空间变换要方便很多。
M = 缩放矩阵×旋转矩阵×平移矩阵
缩放矩阵=
旋转矩阵=，其中左上角的3×3矩阵是正交矩阵。
平移矩阵=
一般情况下，骨架层级用矩阵表示，而动作数据用3D向量表示缩放和平移，用四元数表示旋转，在计算GPU蒙皮的时候再转换成矩阵。
另一个重要的概念是矩阵和向量左乘还是右乘的问题。每个引擎都有自己的规定。本书讲的都是左乘，也就是说，矩阵始终在向量右′面，比如，对于一个顶点v，使用矩阵变换v= v M。
这里面有很多细节没有涉及，比如四元数、矩阵、欧拉角之间的变换，还有正交投影、透视投影矩阵是如何求得的。这些内容在《3D数字基础：图形与游戏开发》一书中介绍得很清楚。
一般使用引擎理解仿射变换就足够了，但如果写引擎还要理解很多复杂的变换，除了正交和透视变换之外，计算阴影也会用到这种复杂变换。
试读结束[说明：试读内容隐藏了图片]