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

首先建议读一下Milo Yip大神翻译的《游戏引擎架构》这本书。

其他的各位答主主要说了图形底层制作方面的内容，然而，图形底层制作着实是游戏引擎中极小极小极小的一部分，甚至说如果你想要自己独立开发一个完整的引擎，图形底层的制作真的只会画很小比例的一部分时间。

引擎开发从底层往上层的开发从宏观架构上大致是这样的，先说图形部分：底层封装，比如将DX11, Vulkan之类的底层API封装成更方便的API，比如Mesh, Material, BindProperty这些类和方法，这样在编写更上层的时候就可以省许多劲。你不会想要每个Drawcall都写一大堆buffer传递的。

渲染管线，通过调用已经封装好的API，比如DrawMesh(Mesh, Material)等等，像拼积木一样一层一层的往上叠，比如先传摄像机参数，再渲染不透明物体，再算延迟光照和反射，再渲染透明物体和后处理等等。这一部分往往是工作量最高的部分之一。

着色器，同样是工作量最高的部分之一，成熟的工业级引擎常有众多备用的着色器，基于物理，特效等等。

资源管理，贴图，模型和其他二进制数据的储存和加载(同步与异步)。事实上这一部分乍一看工作量不大，但实际上坑非常多，在这一方面Unreal Engine做的非常好，而且完全开源，可以去读一下源码。

多线程。老生常谈的问题，比如现在比较受欢迎的多线程方法Job Schedule + Command Buffer Queue的形式，这个在Intel的PPT中提到过。事实上现在比较先进的引擎都在使用这类方法，比如顽皮狗的Fiber，Unity3D的Job System等等(实际上我也不大懂，说错了大神轻喷)。这一部分的工作量同样是乍一看不多，然而往往需要伴随着巨量的benchmark和不同机型不同平台的适配。

编辑器。这是游戏引擎的脸，引擎不能不要编辑器就像人不能不要脸(虽然有些人确实可以不要)，一个强大可扩展的编辑器甚至直接决定了引擎的“好用”程度和开发效率与成本。这一部分不用“乍一看”了，实际上就是工作量最高的一部分之一。

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

继续再来说说逻辑框架吧。首先，你的编辑器要有一套开发时的可视化操作，让用户写了脚本以后拖上去就可以运行，比如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正是这样的工作流程。这一部分的开发难度可以说是最高的，需要深入到编译底层，还要在解决需求的同时不断完善才行。