如何自学游戏引擎的开发？

zifa2003293 · 发表于 2021-11-16 06:03

Ⅰ：DirectX基础部分学好之后应该如何继续学习？直接看开源的游戏引擎？还是进一步深入学习DirectX可编程渲染流水线？还是看其他一些比如《Real Time 3D Terrain Engines Using C++ And DX9》、《Real-Time Rending》、《Game Engine Architecutre》等等相关书籍？还是自己写Demo？

《游戏引擎架构》序言：

……学习编程技能最好的方法就是写代码。在阅读本书时，强烈建议你选择一些特别感兴趣的主题付诸实践。举例来说，如果你觉得人物动画很有趣，那么可以首先安装OGRE，并测试一下它的蒙皮动画示范。接着还可以尝试用OGRE实现本书谈及的一些动画混合技巧。下一步你可能会打算用游戏手柄控制人物在平面上行走。等你能玩转一些简单的东西了，就应该以此为基础，继续前进！之后可以转移到另一个游戏技术范畴，周而复始。这些项目是什么并不重要，重要的是你在实践游戏编程的艺术，而不是纸上谈兵。

如果要回答一个学习顺序，那么这不是一个很好的答案。但学习过程很多时候并不是顺序的，而且跟个人喜好有关，建议是一边看书（不一定是一本），一边实践想要做的东西。

Ⅱ：涉及游戏引擎开发的公司有哪些？（腾讯？网易？触控科技？），这些公司对游戏引擎开发的职位要求是什么？以及将来面试时应该如何应对？（把自己写的Demo给他看？）

《游戏引擎架构》译序：

……然而，各游戏本身的性质以及平台的差异，使研发完全通用的游戏引擎变得极困难，甚至不可能。市面上出售的游戏引擎，有一些虽然已经达到很高的技术水平，但在商业应用中，很多时候还是需要因应个别游戏项目对引擎改造、整合、扩展及优化。因此，即使能使用市面上最好的商用引擎或自研引擎，我们仍需要理解当中的架构、各种机制和技术，并且分析及解决在制作中遇到的问题。这些也是译者曾任于上海两家工作室时的主要工作范畴。

我在腾讯互娱研发部引擎技术中心的工作内容之一也是引擎改造、整合、扩展及优化。拿著Demo去面试是一个加分项，如果是开源的更能检查编码习惯和软件工程的能力。我会细致地问一些技术点，例如某一部分使用了什么技术，还有那些可选方案，他们之间的优缺点是什么。

另外，「这里的游戏引擎暂时指图形模块」这种想法并不太合适，因为图形与其他模块要互相结合，高层的模块也要共用底层的模块，所以应该首先理解整体，再逐个部分深入。

看到其他答案用了这张图，质量比较差，送张高清图吧。

NoiseFloor · 发表于 2021-11-16 06:10

Ⅰ：DirectX基础部分学好之后应该如何继续学习？直接看开源的游戏引擎？还是进一步深入学习DirectX可编程渲染流水线？还是看其他一些比如《Real Time 3D Terrain Engines Using C++ And DX9》、《Real-Time Rending》、《Game Engine Architecutre》等等相关书籍？还是自己写Demo？

《游戏引擎架构》序言：

……学习编程技能最好的方法就是写代码。在阅读本书时，强烈建议你选择一些特别感兴趣的主题付诸实践。举例来说，如果你觉得人物动画很有趣，那么可以首先安装OGRE，并测试一下它的蒙皮动画示范。接着还可以尝试用OGRE实现本书谈及的一些动画混合技巧。下一步你可能会打算用游戏手柄控制人物在平面上行走。等你能玩转一些简单的东西了，就应该以此为基础，继续前进！之后可以转移到另一个游戏技术范畴，周而复始。这些项目是什么并不重要，重要的是你在实践游戏编程的艺术，而不是纸上谈兵。

如果要回答一个学习顺序，那么这不是一个很好的答案。但学习过程很多时候并不是顺序的，而且跟个人喜好有关，建议是一边看书（不一定是一本），一边实践想要做的东西。

Ⅱ：涉及游戏引擎开发的公司有哪些？（腾讯？网易？触控科技？），这些公司对游戏引擎开发的职位要求是什么？以及将来面试时应该如何应对？（把自己写的Demo给他看？）

《游戏引擎架构》译序：

……然而，各游戏本身的性质以及平台的差异，使研发完全通用的游戏引擎变得极困难，甚至不可能。市面上出售的游戏引擎，有一些虽然已经达到很高的技术水平，但在商业应用中，很多时候还是需要因应个别游戏项目对引擎改造、整合、扩展及优化。因此，即使能使用市面上最好的商用引擎或自研引擎，我们仍需要理解当中的架构、各种机制和技术，并且分析及解决在制作中遇到的问题。这些也是译者曾任于上海两家工作室时的主要工作范畴。

我在腾讯互娱研发部引擎技术中心的工作内容之一也是引擎改造、整合、扩展及优化。拿著Demo去面试是一个加分项，如果是开源的更能检查编码习惯和软件工程的能力。我会细致地问一些技术点，例如某一部分使用了什么技术，还有那些可选方案，他们之间的优缺点是什么。

另外，「这里的游戏引擎暂时指图形模块」这种想法并不太合适，因为图形与其他模块要互相结合，高层的模块也要共用底层的模块，所以应该首先理解整体，再逐个部分深入。

看到其他答案用了这张图，质量比较差，送张高清图吧。

Baste · 发表于 2021-11-16 06:14

我们公司引擎部门新员工，一般会有两个入门练习：
一是只用类似DrawPixel的函数，实现一个软件光栅化。
二是使用自家引擎做一个完整游戏。可以比较简单，但必须完整。
一个去鹅厂的小伙伴也做过类似跑酷类手游作为练手。

所以我觉得，从学习的角度，一边做游戏，一边做个玩具引擎，并不冲突。
做一个自己的引擎出来，满足技术好奇心，也能试验想法；
用一个开源图形引擎做一个类型的游戏，能了解组成部分和主要需求。了解

楼上有好多关于做游戏还是做引擎的讨论，都是有道理的。
如@张静vinjn 等所说，如果没做过一个完整的游戏，直接只做引擎，学习的效率和引擎的质量都不会太高。
但在很多人心里，会把引擎开发的这个工作神话。这种时候自己做一个引擎，对提高自己的信心会有帮助。大部分贬低引擎开发工作的人，至少都是有能撸一个的底气的（且不说质量）。

-------------------------------------------------------------------------------------------------------------
所以对两个方面，我都推荐一些自己感觉不错的资料:

游戏逻辑方面：推荐一个网站， Game Programming Patterns，作者把自己的书放github上，供读者提意见。

引擎架构方面：Game Engine Architecture，这本得看中文翻译的。
图形引擎方面，主要是算法和API，引擎架构抄一套别人的。
图形基础算法书籍：在lz的基础上，推荐一个3D Game Engine Design，里面的3D算法和原理讲解很详细，可惜有点老。
高级图形技术：除了Real Time Rendering 3和GPU Pro系列以外，可以跟KlayGE和OpenGPU。这个方向量力而行，国内现在的行情是转手游的多，一些复杂的效果研究太深入也可能发挥不了。

update：
下面评论有问，我贴一下。
软件光栅化可以简单理解为，只给你一个画点的函数，你需要用C++实现一个三维物体显示的过程。一般这个工作是由Direct3D/OpenGL的驱动实现来做的。
这个工作可以做的很难，也可以很简单。我们公司貌似所有客户端程序都会做这个，但要求跟老大有关。
最基本就是实现一个固定管线，包括顶点坐标的矩阵变化，画线，三角形填充光栅化算法，裁剪，Gouround光照，纹理坐标插值，ZBuffer等等。
要做好点，就可以把一个引擎Renderer部分的借口都实现了，用C++写个VS/PS，跟D3D/OpenGL平级。

jquave · 发表于 2021-11-16 06:23

没有必要刻意的区分游戏引擎和游戏，对于程序员而言，游戏开发得多了，自然会把可重用的部分提取成 library。而这 library 逐渐丰富起来，便成了引擎。

如果你一开始就抱着我想做的是引擎，而不是游戏的态度，那这个事情就有点扭曲了。如果你没开发过游戏，你怎么知道游戏引擎里需要哪些组件呢？是吧。

所以想开发引擎，最靠谱的方法就是，去开发游戏，各种类型的游戏。俄罗斯方块、2048、第一人称射击等等，0D、1D、2D、3D、4D 都需要试试。

以下是哗众取宠的跑题时间（居然被一名学生批评哗众取宠，不开心呀）
0D 就是说没有任何画面 RGB(0, 0, 0)，可以用麦克风来控制、再用音乐来反馈。
1D 就是只有一维，比如一个点在一条线上移动。
2D、3D 大家熟悉。
4D 是 3D 配上奇怪的电子设备，比如 Kinect、Arduino、Oculus Rift、Vibrator（咳咳）等。

yukamu · 发表于 2021-11-16 06:30

思维要随时代一起进步，国人的武侠基因总是导致很多人觉得：我潜心修炼xx年，出道即巅峰，出山就是王者。
自学要从时代性上来解读：

所以个人建议从使用引擎来学习引擎开发，因为时代的便利性给了你“捷径”。
大牛们在那个时候，没有参考，只能从底层筑基慢慢来，中间是几十年的试错成本换来的。如今就算你跟那些鬼才一样智慧，那么你愿意花费十年去试错嘛？
这类似于，先学微积分，后学数学分析。而不是上来整个集合论开始造数，然后延伸到自己从新发明下微积分。
一个东西如果一直溯源，就变成了哲学问题。
所以即使底层，在自学的初学阶段，也应该在合适的深度打住。能懂当然更好，但不是说必须会。
所以当今时代的自学，我还是推荐，从用开始。在用的过程中，看看成熟引擎如何处理你感兴趣的部分。
第一步：照着抄。从上而下。用引擎的组件做到可以自己做“应用”，“实践”。
第二步：自己尝试写，从下往上。因为你知道上层要用什么，你才知道底层怎么去写，这就是把前人的试错成本一下压缩了。
选对的路，让别人喷去吧……

Zephus · 发表于 2021-11-16 06:31

首先建议读一下Milo Yip大神翻译的《游戏引擎架构》这本书。
其他的各位答主主要说了图形底层制作方面的内容，然而，图形底层制作着实是游戏引擎中极小极小极小的一部分，甚至说如果你想要自己独立开发一个完整的引擎，图形底层的制作真的只会画很小比例的一部分时间。
引擎开发从底层往上层的开发从宏观架构上大致是这样的，先说图形部分：

除了图形，还有音效，UI，物理，网络，逻辑框架等多个部分。留个坑占个位之后慢慢填。其实我还是很佩服题主的，原来我也想自己开发游戏引擎，后来一想工作量，就弃坑了……弃坑了……

<hr/>继续再来说说逻辑框架吧。首先，你的编辑器要有一套开发时的可视化操作，让用户写了脚本以后拖上去就可以运行，比如UE4的逻辑是由Actor和Component组成的，每一个Actor可以包含数个Component，Actor表示一个载体（并且可以执行逻辑），而Component则表示多个功能类。Unity3D和UE4大致相仿，只不过Unity中叫GameObject和Component，而且Unity的GameObject是纯粹的载体而不是可编程的。
实际上大多数情况下这种通用的框架就足够用了，而且这种通用框架开发起来难度也不大（假设题主具有神级的编程水平和框架设计能力），但是这其实仅仅只是一个开始……光有这么一个框架是远远不够的。下面再来列一些必须的功能。
逻辑多线程：在逻辑开发中，多线程的需求是非常普遍的，其中又主要分为异步等待型多线程和并发运算型多线程，前者的实现比较容易，开一个或几个线程并锁住，之后需要用的时候解锁。然而并行多线程则并不容易实现。并行多线程一般要实现Command Buffer保证集中处理运算密集型逻辑，还要实现SIMD保证可以处理众多对象。
数据密集型设计：当场景中有10000个小人在跳舞，你绝对不想建立10000个Actor/GameObject，这会直接卡到绝望，因为作为载体，GameObject实在太过于笨重，这种时候就需要一些数据密集型设计，至于CPU Cache Miss之类的也就不需要多说了。这种情况就需要制定一套规则，手动allocate，管理内存，并组织绘制，物理等统一提交与运算。目前Unity的ECS正是这样的工作流程。这一部分的开发难度可以说是最高的，需要深入到编译底层，还要在解决需求的同时不断完善才行。

super1 · 发表于 2021-11-16 06:31

一点一点回答

题主问的图形引擎开发：
刚好写过一个，这个你一开始可以参考ogre看看，你需要主要研究的内容主要包括但不限于以下部分

最好的学习方法还是从利用现有引擎开发游戏做起，和其他答案说的一样，游戏引擎本来就是抽象出来的一个东西，没写过游戏就写引擎，还是算了。

涉及游戏引擎开发的公司有哪些？
一句话，如果你想做研发，建议还是来我司。

这些公司对游戏引擎开发的职位要求是什么？

以及将来面试时应该如何应对？（把自己写的Demo给他看？）
这个说明不了什么，研发岗位更注重的是表面上看不到的东西，我指的架构程序的能力。当然如果你有水平做这个，面试的时候可以多讲讲，水平高下自然能看出来。

基本就是这样。

ainatipen · 发表于 2021-11-16 06:41

游戏引擎的内容非常多，如果没有提前做好学习计划可能会越学约迷茫，越学越焦虑。在正式开始学习之前要对游戏引擎整体有一个比较完整的了解，再从中挑选自己感兴趣的模块开始下手。完成一个模块的学习之后再去学习下一个模块的内容，连点成线，连线成面。慢慢地，你整体的引擎研发能力会得到一个很大的提升。
下面简单科普一下游戏引擎
  电子游戏是一款软实时(soft real-time)模拟软件。软实时模拟软件需要做到可以响应实时操作，并且即使由于某些原因没有立即响应也不会造成灾难性后果。在电子游戏这样的软实时模拟软件中的大部分数学问题没有闭合式解，因此需要进行离散的模拟才能得到一个结果。
  游戏引擎正是为了完成游戏中各种各样的模拟而整合了各种各样的模块，例如物理模块、渲染模块、逻辑模块等。早期的游戏引擎大多只能运行在特定平台，例如《雷神之锤》的引擎Quake engine、魔兽世界用的暴雪自家引擎。

Quake

魔兽世界

  后来出现了可以跨平台运行的通用游戏引擎，例如Unity、Unreal。
<a href="http://www.zhihu.com/zvideo/1429528678615625728" data-draft-node="block" data-draft-type="link-card">  一般来说，越通用的游戏引擎，在特定平台上的运行效率会越不如那些只能运行于特定游戏平台的游戏引擎。因为性能优化总是基于特定假设的，这个假设越单一，优化起来会越轻松。

  上图中，游戏专用子系统和第三方软件开发包之间的内容都属于游戏引擎的内容。
硬件

  硬件是运行游戏的物理设备，例如pc、xBox Series X、PS5、ns。

PC

xBox Series X

PS5

NS

驱动

  驱动是负责和硬件进行通信的底层软件，常见的驱动有显卡驱动（Nvidia、AMD）、声卡驱动。有了这些驱动之后，开发人员就不需要为具体的硬件设备编写代码。驱动很好地隐藏了硬件设备的复杂性，使开发工作的复杂度降低。

操作系统(Operating System)

  在操作系统层面上，大致上可以分成游戏专用操作系统和非游戏专用操作系统。
  游戏专用操作系统有xbox的XBoxOS、ps4的Orbis OS、ns的Horizon。这些操作系统的通常知识一个轻量级的库，在游戏运行时，游戏程序几乎可以占有硬件的所有资源和控制权，所以游戏运行效率很高。
  而非游戏专用操作系统通常都会因为各种各样的原因只能占用硬件的部分资源和控制权，例如windows操作系统采用基于时间片(time-slice)的抢占式多任务(preemptive multitasking)方式来运行所有程序。
  这也是为什么同一款游戏在同样硬件性能的PC和PS3上面运行，PC上可能直接变成PPT，而PS3却可以30帧稳定运行。

xbox的XBoxOS

ps4的Orbis OS

ns的Horizon

软件开发包(software development kit, SDK)

  软件开发包一批功能良好的函数的集合，这些函数又称为称为API(application programming interface)。
  大部分游戏引擎都会接入第三方SDK以增强引擎的功能，通过接入SDK的方式给引擎增加功能可以减少引擎的研发压力，同时又能获得良好的效果表现。
  下面列举一些比较常见的第三方SDK：
  物理引擎有Havok、PhysX、Bullet等。

  动画引擎有Havok Animation、Granny等。

  Havok Animation可以在运行时给动画加上物理效果，也就是物理动画技术(Physically based animation)。
  动画的制作流程比较复杂繁琐，部分有钱的游戏厂商会通过动捕(motion cap)的方式来制作动画，钱包确实顶不住的话可以使用Endorphin来自动生成帧动画，提高生产效率。还有一种减少工作量的方法，使用Euphoria在游戏运行时生成符合物理和生物力学的动画。
平台独立层(platform independence layer)

  平台独立层会为特定模块封装各个平台的底层API，让游戏引擎可以支持在多个平台上运行。这一层算是游戏引擎和外界环境进行沟通的桥梁。
核心系统

  核心系统会为游戏引擎提供一个软件该有的底层功能，所有类型的软件都会有这一层。
  这一层的内容也不少，我们关注得比较多的是内容管理模块。因为游戏引擎往往都需要保证最多每隔32毫秒就要执行一边全体代码，对于内存的管理要求会比较高，需要实现高效地内存分配和释放，还会自定义数据结构及算法来减少或完全消除动态内存的分配。
渲染引擎

  渲染这一块内容就比较丰富了，已经被独立成一个专业学科--计算机图形学。一般游戏引擎都不会去开发自己的渲染引擎，因为投入产出比太低，而且现有的渲染引擎已经很成熟了。所以游戏引擎一般都会接入已有的渲染引擎。
常见的渲染引擎有DirectX、OpenGL、Vulkan、Edge等。这里的Edge并不是指微软的Edge浏览器，而是专门为PS3渲染设计的，拥有高效几何处理技术的渲染引擎，同时它还具有动画播放功能。

  渲染引擎一般会采用分层架构(layered architecture)来组织代码，一般会被分为低阶渲染器(low-level renderer)、场景图(scene graph)/剔除优化、视觉效果、前端。
  低阶渲染器会使用图形SDK来设置好渲染器，实现几何图元(geometric primitive)的高速渲染。
  场景图/优化剔除会为不同的游戏场景提供不同的算法来限制提交到GPU的图元数量。常用的算法有平截头体剔除(frustum cull)、空间细分(spatial subdivision)、portal、遮挡剔除技术。其中空间细分算法可以使用不同的数据结构来构建场景图以快速判别潜在可见集(potentially visible set, PVS)。
  视觉效果层专门提供丰富的视觉效果，其中包括粒子系统(particle system)、贴花系统(decal system)、光照贴图(light mapping)、环境贴图(evironment mapping)、动态阴影(dynamic shadow)、全屏后处理效果(full-screen post-processing effect)等。其中全屏后处理效果包括高动态范围(high dynamic tange, HDR)光照、敷霜效果(bloom)、全屏抗锯齿(full-screen anti-aliasing, FSAA)、颜色较正(color correction)等。其中颜色较正包括颜色偏移(color-shift)、略过漂白(bleach bypass)、饱和度(saturation)、去饱和度(desaturation)等。美术师一般会在这一层上面进行工作。
  前端是开发者、玩家与游戏进行交互的桥梁，包括了平视显示器(heads-up display, HUD)、辅助开发的工具（如内置菜单、主控台）、图形用户界面(graphical user interface, GUI)、全动视频(full-motion video, FMV)系统、游戏内置电影(in-game cinematics, IGC)系统等。
人工智能

  游戏中的传统人工智能并不是类似于深度学习的人工智能，而只是让角色看起来有智能。所有貌似拥有智能的行为都是提前硬编码好的，有限状态机和行为树是最常用的技术。现在游戏也慢慢开始加入了具有自我进化能力的人工智能，以后游戏过程中的不确定性会进一步增加。
性能分析工具

  为了提升游戏运行效率，需要在研发过程中或研发完成时对游戏进行性能分析。现在比较成熟的性能分析工具有Intel的VTune、IBM的Quantify和Purify、Compuware的Bounds Checker。有些游戏引擎会开发自己的性能分析工具，例如unty内置的Profiler。一个性能分析工具大致需要具备以下功能：

物理

  游戏物理模拟是个大部头，如果项目有真实物理模拟的需求，那么一般会专门配置一位负责开发物理效果的程序员。
  游戏物理和仿真物理的侧重点并不相同。仿真物理注重模拟效果的准确性，而不关注性能。游戏物理不追求模拟百分百正确，只要最终的效果看起来合理就好，需要特别关注性能表现。因为游戏需要在配置一般的设备上运行，没有太多的算了投放到物理模拟中。只要效果看起来没太大问题，那么它就是对的。
动画

  动画同样是一个大部头，如果项目的动画很多且复杂细腻，一般也会专门配置一位专门负责开发动画效果的程序员。
  动画效果可以很简单，也可以很复杂。最简单的就是播放单个帧动画，复杂的可以搞基于物理的动画、IK效果等。
  负责游戏动画的程序员除了要做好表现效果之外，还要做好资源管理，包括动画资源和动画状态机资源。因为现在大部分项目都是使用动画状态机以及动画融合技术来制作动画效果。
  一个表现效果可能由多个动画clip融合而成。使用这种方案来做动画表现，产出的动画资源一般都不少。
  如果某个模型的动画表现比较细腻的话，它的动画状态机也会很复杂。我曾经见过一个动画状态机打开之后整个屏幕都是密密麻麻的transition连线。
人体学接口设备(human interface device, HID)引擎

  HID引擎会将游戏外设和游戏引擎对接起来。比较常见的游戏外设有键盘、鼠标、手柄。还有一些比较小众的游戏外设，例如赛车模拟设备（方向盘+踏板+挡杆+手刹）、飞行摇杆、VR控制器。

xbox手柄

ps手柄

ns手柄

健身环

赛车模拟设备

  游戏外设的输入信号会先被映射为输入代码，再映射为游戏的具体操作。
音频

  游戏的音频也同样重要，好的音频效果可以营造良好的游戏氛围。一般游戏引擎都有自己研发的音频功能，例如cocos、unity、unreal都有。但是在游戏开发过程中一般不会直接使用引擎提供的功能，而是会使用第三方SDK，例如FMOD、Wwise。因为第三方SDK功能更加完备。

网络

  游戏引擎提供基本网络通信功能并不是什么特别难的事情，但是要提供一套成熟通用的网络同步功能非常困难。不同游戏对网络同步的需求由很大的区别，所以游戏项目组一般都会开发自己的网络同步功能以匹配自己的游戏业务需求。
数字内容创作(digital content creation, DCC)应用软件及资产调节管道(asset conditioning pipeline)

  设计师会通过DCC工具将模型、材质、贴图、音频等工具生产游戏素材。团队一般都会使用市面上以由的DCC工具，例如3DMax、Maya、PhotoShop、FMOD Studio等。这些工具输出的资源格式在大部分情况下没有办法被游戏引擎直接使用，需要游戏引擎对这些资源进行一次转换，转换为游戏引擎方便使用的格式。这个转换过程有资产调节管道来完成。例如每次往unity中拖入fbx模型资源的时候都会出现一个import进度条，正是在进行资源转换。
最后

  这节只是简单带过了各种模块的知识，由于部分内容展开之后量会非常大，所以会在该系列的后续文章中单独讲，也可能会另开一个专栏。希望能帮助到想要从事游戏研发的人。
<hr/>有不少同学问我怎么从零开始学习游戏开发，难以一一回复。这里整理了一份收集多年的优质学习资料，涵盖游戏开发的方方面面

链接：https://pan.baidu.com/s/1C-9TE9ES9xrySqW7PfpjyQ  提取码：cqmd

小弟才浅，如果本篇文章有任何错误和建议，欢迎大家留言
感谢各位人才的点赞、收藏，可以关注我和专栏「游戏引擎从入门到入土」

微信搜一搜「三年游戏人」收获一枚有情怀的游戏人，文章持续更新，第一时间阅读

maltadirk · 发表于 2021-11-16 06:44

很多人并不知道游戏引擎或渲染引擎是怎么回事就开始思考如何做游戏引擎，这是不对的。
首先应该深度掌握渲染的基本原理，因此我非常同意其他答案关于先自己实现一个软件光栅化渲染器的建议，你应该按照最新的标准自己大概实现一遍DirectX(例如要支持tessellation, shader, MSAA, blending, anisotropic filtering, 正确处理各种corner case如退化三角形等情况)。实现的过程中请参考DirectX的specification以学习相关细节。这个文档可能是只对硬件vendor公开，不过还是很容易获得的。实现软件光栅化还能极大地锻炼你的底层C++编码能力，并行程序设计能力和优化技巧，顺便还能把主流的GPU架构搞熟。

一旦搞清楚光栅化渲染的本质，你就能理解各种所谓“高级渲染技术”的精髓，基本上看paper只需几秒钟扫一扫图就能看懂了。这样一来短时间内就能理解大量算法和渲染架构(例如各种shadow map, AO, volumetric scattering, deferred lighting, forward+等等)。

当你对图形管线的本质以及各种可能的应用都了然于胸的时候，剩下的就是高层架构设计问题了。这个属于软件工程的范畴，没有捷径，只能通过大量试错来获得经验了(不停地重写)。

其实当你知道了这些所谓的技术之后，你会发现大部分都是肤浅的hack而已。现在引擎的重要课题不在于谁掌握了更牛逼的渲染技术，而在于谁能设计出更好的开发流水线，内容制作以及美工反馈才是最大的难题。前段时间和bungie的图形总管聊destiny的engine，他们表示任何新的技术他们都可以在两天内实现出来，但最大的难题是1)如何使这些新技术在各种情况下都能鲁棒地工作；而大部分时候都很好，偶尔会挂掉的技术都是不可取的；2)如何构建好的工具让美工能够控制各种情况。举个例子，tessellation是个很酷的技术，但是应用到游戏中并不容易，因为1)创建好的displacement map很困难; 2)一旦引入LOD，则牵动全身：如何保持场景在各个视角的一致性？如何让displacement geometry正确地与阴影、碰撞、贴花和可见性等系统交互？

此外不同平台上还有很多底层优化问题，这里就不展开了。

KaaPexei · 发表于 2021-11-16 06:54

游戏引擎的设计
知乎专栏
游戏开发集中营

		自动登录	找回密码
密码			立即注册

如何自学游戏引擎的开发？

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源