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

z0106551513

PS：题猪分得清游戏和游戏引擎的区别，所以各位答主不需要劳神解释两者的区别关系什么的了

PS：这里的游戏引擎暂时指图形模块，其他的声音，物理，网络，UI等等模块暂时不考虑

题猪一直自学编程，有c++、数据结构与算法 基础，现在正在自学DirectX9.0，（自然是看红龙书了），想着以后能从事游戏引擎开发相关的职业，敢问各位路过的大神提些宝贵的意见
Ⅰ：DirectX基础部分学好之后应该如何继续学习？直接看开源的游戏引擎？还是进一步深入学习DirectX可编程渲染流水线？还是看其他一些比如《Real Time 3D Terrain Engines Using C++ And DX9》、《Real-Time Rending》、《Game Engine Architecutre》等等相关书籍？还是自己写Demo？
Ⅱ：涉及游戏引擎开发的公司有哪些？（腾讯？网易？触控科技？），这些公司对游戏引擎开发的职位要求是什么？以及将来面试时应该如何应对？（把自己写的Demo给他看？）

大家走过路过不要错过，给点建议行行好

CUA-4109

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

• 信息闭塞的年代，游戏开发的早期，你不自学没办法，书没有，代码没有，圈子没有，竭尽所能的用上一切能找到的边边角角加上自己的悟性和不厌其烦的试错，这种方法不可证伪。
  
• 如今不说最先进，也算的上最先进的引擎之一的引擎都开源了，自学的难度小了很多。你不需要去构建一个概念，直接可以观测利用这些概念。这让学习难度降低了很多很多很多....
  

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

咏蘅誓唁

首先建议读一下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，物理，网络，逻辑框架等多个部分。留个坑占个位之后慢慢填。其实我还是很佩服题主的，原来我也想自己开发游戏引擎，后来一想工作量，就弃坑了……弃坑了……


<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正是这样的工作流程。这一部分的开发难度可以说是最高的，需要深入到编译底层，还要在解决需求的同时不断完善才行。

phillip

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

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

如果要回答一个学习顺序，那么这不是一个很好的答案。但学习过程很多时候并不是顺序的，而且跟个人喜好有关，建议是一边看书（不一定是一本），一边实践想要做的东西。
Ⅱ：涉及游戏引擎开发的公司有哪些？（腾讯？网易？触控科技？），这些公司对游戏引擎开发的职位要求是什么？以及将来面试时应该如何应对？（把自己写的Demo给他看？）
《游戏引擎架构》译序：

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

我在腾讯互娱研发部引擎技术中心的工作内容之一也是引擎改造、整合、扩展及优化。拿著Demo去面试是一个加分项，如果是开源的更能检查编码习惯和软件工程的能力。我会细致地问一些技术点，例如某一部分使用了什么技术，还有那些可选方案，他们之间的优缺点是什么。
另外，「这里的游戏引擎暂时指图形模块」这种想法并不太合适，因为图形与其他模块要互相结合，高层的模块也要共用底层的模块，所以应该首先理解整体，再逐个部分深入。
看到其他答案用了这张图，质量比较差，送张高清图吧。

2428796577

我们公司引擎部门新员工，一般会有两个入门练习：
一是只用类似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平级。

FAAC

没有必要刻意的区分游戏引擎和游戏，对于程序员而言，游戏开发得多了，自然会把可重用的部分提取成 library。而这 library 逐渐丰富起来，便成了引擎。
如果你一开始就抱着我想做的是引擎，而不是游戏的态度，那这个事情就有点扭曲了。如果你没开发过游戏，你怎么知道游戏引擎里需要哪些组件呢？是吧。
所以想开发引擎，最靠谱的方法就是，去开发游戏，各种类型的游戏。俄罗斯方块、2048、第一人称射击等等，0D、1D、2D、3D、4D 都需要试试。
以下是哗众取宠的跑题时间（居然被一名学生批评哗众取宠，不开心呀）
0D 就是说没有任何画面 RGB(0, 0, 0)，可以用麦克风来控制、再用音乐来反馈。
1D 就是只有一维，比如一个点在一条线上移动。
2D、3D 大家熟悉。
4D 是 3D 配上奇怪的电子设备，比如 Kinect、Arduino、Oculus Rift、Vibrator（咳咳）等。