本期为GAMES104《现代游戏引擎：从入门到实践》视频公开课文字实录第3期。本课程由GAMES(图形学与混合现实研讨会）发起，游戏引擎技术专家王希携手游戏引擎一线开发者共同研发。

课程共计22个课时，将介绍现代游戏引擎所涉及的系统架构，技术点，引擎系统相关的知识。为配合学习实践，课程组在 GitHub 上开源了小引擎Piccolo，上线1个月即获得了2900+star, 累计下载量已超过20000+。

PS：错过了上期内容的同学可以点击下方链接阅读哦。

以下内容为公开课视频转文字版本，为阅读通顺，有删减

01「课程大纲」

接下来快速介绍一下20几节课的课程内容，这也是今年上半年我最重要的工作：要把这么复杂的一个体系结构讲清楚。

游戏引擎的研发，某种意义上很像大学学的一门课程——数据结构。一开始它其实并不是一种科学，只是大家在工程实践中逐渐总结出来的很多方法。当我们做了足够多的实践，会发现需要一套体系化的方法把知识固化下来。你会发现在很多类似的问题上，这些方法、模式都可以重用。

我们在课程设计中尝试把构建虚拟世界的基础结构梳理一遍，每一块着重讲的是方法。

基础的构建

第一节课会介绍游戏引擎最基础的构建，就是当你面对一个这么复杂的问题，按什么方法理解它、设计它。比如怎么理解MVVM设计模式？换句话说就是游戏引擎到底分几层？第一层为什么要把硬件平台、操作系统全部虚拟化？第二层为什么要抽象出很多共用的东西？我们会一层一层讲。

听完第一节课，当你打开虚幻、Unity或者任何一个游戏引擎的代码，你就知道该从哪开始看起了。

先剧透一下，打开任何一个游戏引擎的代码，首先看的是什么？一个叫做update的函数，它每隔1/30秒会去调一个Tick函数，从那个入口看进去，就能够顺藤摸瓜到引擎所有的细节。

渲染

我的目标是听游戏引擎的渲染可以不需要有图形学的基础知识，我们讲的是体系结构。

这个世界由材质、光照、网格、动画、大气等构成，怎么把这些东西拼到一起？在游戏引擎/虚拟现实的世界里面，所有的事情都必须Realtime，怎么把这么多东西Fitting到30毫秒里面去？怎么用Pipeline去组织这些元素？还有大家会提到的，比如Deferred Rendering、Forward Rendering在现代游戏架构中各自的优劣势。

大家学完这节课，会知道一些很有趣的点。比如一个小小的玻璃板/透明物体就会给整个渲染管线带来巨大的困难，大家可能想象不到，如果有好多好多的玻璃，渲染就会非常有挑战。还有比如卡通画的渲染、自己可以定制的渲染管线……

根据不同的应用场景，比如要做仿真模拟，追求的是数据量特别大，要画一个很大的场景。想表达一个角色、一个虚拟人，要把它表现得特别漂亮。或者说，要把这个世界表达得非常地二次元，该在哪找到这些部件？按照什么逻辑把它们拼到一起？这就是游戏引擎课里面所讲的渲染。

我们不会讲太深的算法，会讲这么多算法是按照什么结构拼到一起去的。

动画

动画是一个大家非常熟悉的概念，角色只要动起来就叫动画。

动画有很多理论和实践，在游戏引擎课里的动画这节，教大家什么呢？

用3ds Max/Maya做出很多精彩的动画素材，怎样把它们变成一个可以玩起来的东西？比如做了很多人走路的动画，当这个人跑起来之后，走路的动画和跑起来是怎么过渡的？走到一半要变跑的时候，突然有人从左边打了我一下，我该怎样去变化？这些东西可以用一个个动画做出来，但用什么方式在现代游戏引擎里面把它们组织起来？它们最神奇的地方是什么？我们要提出一种组织结构，比如 Animation tree、Blender，让设计师能够参与进来。

我会讲一些更有趣的概念，比如敌人的一把剑砍过来，我要表演100%空手接白刃，怎么保证这个空手接白刃在游戏里面一定是算的准的？这就是游戏的动画系统的核心设计理念。

这里面不会讲基本的Skeleton、Rigging、Skinning这些东西，会强调交互、强调一个玩法变化的体系，这里面大家能接触到一些把技术变成能够让设计师理解的工具，通过它们构建精彩的游戏世界。

物理

物理是个非常有意思的概念，比如你在一些现代游戏/游戏引擎里面看见地上有个方块，一脚踢它，那个方块就会动/跑起来。但学完这部分就会意识到：这件事情并不是天然的。因为前面三部分只是把东西展现在你的面前，想让这个世界真正互动起来，所有这些东西还有另外一层的表达——物理表达，它与现在这个表达是个孪生世界。

在这个物理表达里面，要用最简单的刚体（盒、球、圆柱、胶囊等）表达这个世界，还要用刚体力学模拟各种运动。

想象一下，如果这个世界是软的、可以压变形的，那是不是要一些弹性力学的东西？接着，有水、有烟、有头发，流体模拟就来了。再想象一下，能不能把这些东西变成一个系统？比如造一辆车，车轮在雪地、泥地上的运转就会不一样。

这些东西在现实生活中很自然，但在游戏引擎里面，Physics是一个非常重要的底层框架。

我们不会讲得那么深，但会把整个结构告诉大家。以后玩一个游戏，比如你看见一堵墙，想一枪打开却没打倒，千万不要觉得意外。你可以说这堵墙只是做了个碰撞体，但是没有做破坏，所以这堵墙是打不倒的。你也不要去怪策划/设计师没有做对，因为很可能技术上做不了这件事情。

GAMEPLAY

有了前面的渲染、动画、物理，我们可以构建一个世界，这个世界已经有点真实了，你能拿脚踹它一下了。

但这是一个游戏吗？不是，它只是一个世界的模拟器。它只是把东西放在一起，你能和它交互，但它本身并不好玩，那真正好玩的东西是什么呢？规则。

比如，你把一颗子弹打出去，可以把敌人的5点血打掉，敌人如果受伤了，可以呼叫他的小伙伴来支援。这些规则是怎么告诉计算机的？这些规则不是程序员写的，而是设计师设计的。那怎样让设计师表达这个事件？这里会教大家一些最基本的（比如事件系统、脚本系统）用图形化方法表达这个世界的规则。

大家学到这部分的时候就会明白：所有现代游戏本质上是个规则体系。

这节课我想告诉大家：无论学的是任何一种语言，还是用图做一个逻辑，实际上都是在编程。我个人特别喜欢Steve Jobs的一个观念，他认为所有现代人都要学会一点编程，但编程并不意味着就是对着电脑敲代码，当你用一些元件构建一个逻辑的时候也是编程。

有时候觉得我们实际上是在做一个电路板设计软件，给你一堆二极管、三极管、电容，把它们串在一起就能造出一个非常棒的现代电子设备。其实Gameplay系统就是设计了一堆二极管、三极管、电容，用这些元件组装成设计师脑子里的一部收音机、一台电视或一个电灯智能开关。

这也是游戏引擎一个特别的地方。

讲完这些，我觉得同学们可以做一个自己的游戏了。

给大家补充一些颜值比较高的系统，比如我们特别喜欢的特效系统，例如冒个烟、冒个火。

特效系统有意思的地方在于：它不能用程序写死，它要提供一整套的框架和结构让艺术家可以创造各种各样的可能性。

我们经常讲一个电影拍得不好叫“五毛钱特效”，游戏特效如果做得不好，也叫“五毛钱特效”。

还有一些杂项系统，比如寻路系统。

我们在游戏里看到的很多智能体/AI是怎么认路的？怎么知道往左拐、往右拐？人对世界的认知是通过眼睛去扫描、去看，但在游戏世界是没有办法扫描的。

告诉AI哪有墙？哪有路？哪有障碍？这就是寻路系统。

最后一个大家可能注意不到——相机系统。如果你喜欢玩射击游戏，就会发现枪的镜头感是非常重要的。

这些系统与前面的配合在一起，基本上就可以做一个比较有意思的小游戏了。

工具链

这部分开始介绍一些和游戏工业化连接比较紧的东西，第一个就是工具链。

游戏引擎研发最核心的就是要构建一个工具体系。

一个一个的工具会非常多，比如大家非常熟悉的场景编辑器、动画编辑器、角色编辑器，在GAMES104课程里面，我们不会介绍这些编辑器怎么用——这是教如何做游戏的课程教的东西，而我们教的是游戏引擎。

我们会讲如何构建一个可以给别人用的游戏开发工具体系，这里面最重要的概念就是反射体系。

你做了一整套工具，后面不停地升级它的数据格式，但过去与未来的数据需要兼容，使得你要做100、1000个工具，这些工具之间还要能通信。这就需要反射体系。

这部分，大家可能会担心自己的C++基础和编程能力，但我会尽可能用最简单的语言讲这套体系。

Online gaming网络

网络在现代游戏引擎中越来越重要了，过去那些商业引擎在网络这块做得比较弱，但现在我们越来越需要连接到彼此。

在游戏世界里，为什么网络这部分这么重要又这么难做呢？

做游戏本质上是在做上帝做的事，是对这个世界进行模拟。但上帝对世界模拟有个优势：只需模拟一份，因为所有人在一个宇宙里。

但真实的网络游戏是什么概念？

比如我在机器上登录了一个游戏，相当于我在本地跑了一个宇宙，另一个和我联网的小伙伴，他在本地也跑了一个宇宙。我们俩是两个不同的宇宙，当我在这个宇宙里挥了一下手，我得把挥手的这个信号发到他的那个宇宙里面，他的宇宙里面也有一个我的克隆，他看见我挥手了，也对我挥个手，这样信号又传回来，相当于有无数个平行宇宙。

通过信息的沟通，让每个宇宙里发生的事情都尽可能一致，想象一下，这件事情是不是很复杂？

玩游戏的时候放了个大招，打中你，觉得很酷，打不中，觉得这个游戏很傻很笨。大家如果懂了游戏引擎的底层原理，就会意识到这件事情很复杂。

我们会把它的复杂性、一些最简单的基础方法告诉大家，比如著名的帧同步和状态同步算法。但这里不会讲具体的算法，只是让大家建立这样的概念。单单服务器这块就非常深，如果游戏引擎基础课程是一本很厚的书，那服务器同样是一本很厚的书。

上完这节课，同学们再去玩游戏，如果放了个大招，觉得打中了对方，实际没有打中，你至少不会那么生气了。因为你知道是网络同步出了问题，说明这个算法写得不够好，等你学会了写代码，可以再写一遍。

讲完这些，我觉得一个骨干的架构基本上讲完了。