书名：游戏引擎原理与实践 卷1：基础框架
ISBN：978-7-115-51807-1
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 程东哲
责任编辑 陈冀康
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书着重讲解游戏引擎的基础知识和工作原理，并结合配套的游戏引擎示例和详尽的代码，介绍游戏引擎开发的技术细节。
本书是第1卷，主要涉及游戏引擎基础架构。全书共13章，分别介绍游戏引擎原理、引擎和引擎编辑器、底层基础架构、数据结构、数学库、引擎初始化、应用程序架构、对象系统、资源管理、引擎设计的哲学理念、场景管理、静态模型导入和LOD技术。本书未涵盖的游戏引擎话题将在卷2中讲解。
本书适合有一定的游戏开发基础和经验并且想要系统学习游戏引擎原理和引擎开发技术的读者阅读。
在IT业界里，与一些程序员聊天时，可能聊到一些游戏的画面如何好看。对于不开发游戏的程序员来说，他们很可能会认为主要由美工在三维软件里创建资源，然后放进所谓“游戏引擎”的黑盒中，就能得到这些结果。但这个黑盒到底做了些什么才能把图形画出来？除了我们肉眼看到的图形之外，游戏引擎还做了什么工作，因而才被称为游戏引擎而不是图形引擎？不开发游戏的程序员可能很难想象出来。甚至由于近年闭源的Unity引擎在商业上的成功，即便是游戏程序员对于这个黑盒的了解程度也比较有限。
从软件开发的角度来说，抽象通常是好事。我们一般不需要了解每个CPU的半导体制作工序，不用知悉某操作系统的文件系统采用了哪种数据结构。那为什么巿面上有这么成熟的游戏引擎，多数国际游戏开发商所制作的顶级游戏会采用自研游戏引擎？我认为，一般商用游戏引擎以通用性、易用性为目标，但游戏是多元化的，不同类型的游戏有不一样的需求，同时顶级游戏会尝试研发更前沿、更极致的体验，易用性对于专业团队来说反而是次要的。自主研发游戏引擎，不仅需要大量资金，还需要专业技术人员。你需要找到最好的游戏引擎开发人员，然后让他们长期投入这样的技术建设，而不是开发一些短期能赚钱的项目。我相信，这种长期投资对于国内游戏业的发展非常重要。
我在8年前加入腾讯时，便与阿哲共事，参与一个自研游戏引擎的研发工作。后来国内手游的井喷式爆发，导致每款游戏的开发周期从以年计算缩短至以月计算，自研引擎难以跟上这种研发节奏。Unity的成功也促进了游戏公司在商业上的成功，但同时我感到业界的技术人才也出现了严重的断层，新入行的游戏程序员在面对黑盒时大部分情况下只能靠猜，对性能的敏感度也在降低。
我个人认为，即使使用通用的游戏引擎，了解游戏引擎的原理和实现对于技术成长也非常重要。知道黑盒的原理和实现，一方面能在使用时更得心应手，另一方面可以针对项目的特殊需求去扩展游戏引擎的功能。近年Epic Games对移动平台的投入，以至提供Unreal Engine的源代码，吸引了不少项目采用。了解游戏引擎的理论和实现已经成为游戏项目中的技术关键之一。
非常理想的情况下，在成长期间，游戏开发人员可以从零开发一些游戏演示示例，当中仅使用操作系统和底层 API（如图形、音频等）；也可以学习一些新技术，对现有游戏引擎做一些扩展。关于游戏引擎，每个人有不同的学习方法。为了分享自己的知识和经验，多年来阿哲花了不少的业余时间，以一个完整的自研游戏引擎例子为主轴，完成了这本厚重的著作。本书还附有大量的示例，循序渐进地展示一些功能如何有机地加入一个庞大的系统中。建议读者在阅读每章前，也可先运行一下这些演示示例，知道该章要实现的目标，思考一下如何做，再看看阿哲给出的答案，也许能学得更深入，收获更多。
叶劲峰（Milo Yip）
腾讯魔方工作室群引擎中心技术总监
游戏引擎技术在国外发展十分迅速，根本原因在于国外的从业者有很扎实的基础，每一代引擎都是根据游戏迭代而来的。国内游戏行业起步相对较晚，再加上从业者有时急于求成，引擎的人才积累远远不如国外，导致国内的自研引擎企业寥寥无几。学习游戏引擎开发的门槛很高，不具备一定知识是很难自学的，这就让很多想学习引擎的人觉得遥不可及。
本书主要讲解游戏引擎的制作与开发，通过详细的引擎代码示例来剖析引擎中的内部技术。书中内容有些是目前市面上比较成熟的解决方案，有些是作者优化并改进的新的架构，对学习和研发引擎开发有很大帮助。如果使用商业引擎，本书对理解引擎的内部架构并很好地使用引擎也会帮助很大。
通过本书，读者可以清晰地了解大企业制作引擎的基本流程和思路，从而以高效地制作游戏为最终目标。一个好的引擎应该做什么，不应该做什么，本书都会详细介绍。
本书的很多概念都来自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、测试、前端、网络技术等。
异步社区
微信服务号
游戏引擎究竟是什么？恐怕就算是资深行业人士也很难三言两语说清楚。让我们一起来敲开游戏引擎的大门，聊聊引擎的来龙去脉。
什么是游戏引擎？其实这很难给出明确的定义。在很多游戏的宣传中，我们会听到对游戏引擎的推崇。绚丽的特效，流畅的体验，似乎都是游戏引擎的功劳。在游戏玩家看来，游戏画面的表现力越好，游戏场面的震撼程度越大，游戏体验的真实感越强，底层的游戏引擎就可能越强大。
看看业界给出的一些定义。
游戏引擎是指一些已编写好的可编辑计算机游戏系统或者一些交互式实时图像应用程序的核心组件。这些系统为游戏设计者提供编写游戏所需的各种工具，其目的在于让游戏设计者能容易和快速地写出游戏程序而不用从零开始。大部分游戏引擎支持多种操作平台，如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》的动画、渲染的程序也被拿来继续开发其他游戏。
故事总归是故事，但对于《冒险岛》来说，被复用的那部分《超级马里奥》代码其实就是最早的游戏引擎。不过它的技术没那么先进，功能也不甚强大，还缺乏顺应潮流的更新，以致最终销声匿迹了。但卡马克的代码则不同，它超越了当时人们的想象力。他不但为射击游戏制定了完整方案，而且实现的代码功能强大。其高度的复杂性和健壮性，甚至让很多人乐于用其中的某些模块去开发非射击类的游戏，结果不但节省开发时间而且游戏健壮性也不错。这几乎是一部简短的游戏引擎发展史。
我们为什么要如此辛苦地探讨引擎的定义？每个人心中都有自己的哈姆雷特，对错已经没那么重要。开发属于我们自己的游戏，了解哪个引擎更强大以及什么引擎更适合，才是研究游戏引擎的真正意义所在。
关于引擎的第二个争论就是到底用哪个引擎。
从卡马克的时代开始，国外就有了关于游戏引擎的概念。根据游戏需求的不同，游戏厂商要么自己开发引擎，要么购买商业引擎。但真正的商业引擎不但必须有规范的开发流程，以便于定制化，而且要有后续的技术支持来帮助购买引擎的人解决遇到的各种问题，以保障购买者能够实现想要的功能。但能真正实现商业化的引擎也仅有少数几款。
商业引擎数量少，加之每款引擎的授权费用高昂，所以很多团队更愿意自己开发引擎。而几乎每一款知名游戏都有自己的引擎，比如育碧的《刺客信条》、EA的《战地》、科乐美的《实况足球》。但自家的引擎同样需要不断迭代，以保证跟上时代的发展，否则落后的游戏引擎终究会被淘汰。
在国内曾经技术匮乏的那个年代，Gamebryo和Ogre算是最早的两款引擎，Gamebryo是用得最多的商业引擎，Ogre是用得最多的非商业引擎。现如今，除了传统大厂商在自己迭代引擎之外，大部分厂商选择了商业引擎。国内厂商更是如此，在3D游戏引擎的选择上都很明确，手机端用Unity，PC端用Unreal Engine。这些引擎不同于以往特定类型的游戏引擎，它们耦合性很低，通用性更好。那些年风光的引擎如图1.4所示。
图1.4 那些年风光的引擎
游戏引擎曾经百花齐放，如今则大局已定。那么自研引擎是否已是明日黄花了呢？
其实这个问题没有明确的答案。如果你的团队有实力，时间相对充足，已经成功开发出游戏，那么迭代自研发当然可以；但如果项目时间紧，要开发的游戏类型与团队已有的引擎类型大相径庭，改动成本高于学习其他商业引擎的成本，那么不妨使用相对成熟的商业引擎。
这里并不是要讲游戏和引擎的关系，而是讨论开发引擎是否一定要依托于游戏。开发过游戏引擎的人，或多或少地想过这个问题。传统的游戏引擎都是依托游戏一代一代迭代发展起来的。对于游戏企业来讲，最终目的是做出游戏，所以游戏引擎的目标是为专属游戏服务。游戏需要什么特性，引擎就提供什么功能。商业引擎也是如此，如果一款游戏引擎没有支撑过任何成功游戏作品，大家是不敢去用的。毕竟使用游戏引擎的人一般不是专业引擎开发人员，出现问题后很难快速解决底层问题。就连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不得不开源。开源的好处会让更多人关注它，为它定制更多的功能插件，许多问题可以轻松地在互联网上搜索到解决方案，这让它的社区也更加壮大。
