2020年秋招那阵子我手里攥着一份投递列表搜狐畅游的引擎开发工程师排在挺靠前的位置。游戏引擎岗在当年算得上竞争比较狠的方向一方面是因为做游戏引擎的机会本身就少另一方面是很多人对这个岗位的理解停留在“会写C就能上”结果笔试一出来就露馅了。畅游那场笔试给我的印象很深——它不是单纯考你背了多少API而是把一个引擎开发工程师日常要面对的底层问题拆成了卷子上的题目从语言底层、图形数学、算法到引擎架构都有涉及。这篇文章就把我当时踩过的坑、复盘出来的知识点以及后来面试中验证过的重点整理出来给准备投递同类岗位的朋友一份参考。1. 笔试概况题型分布与现场时间分配1.1 整体考试形式与我的第一印象2020年那会儿校招笔试基本都迁到在线平台了畅游用的也是牛客网那套系统双机位监控两小时倒计时。我当时拿到卷子的第一感觉是题量不算夸张但每一道题都需要认真想不是那种一眼就能写出答案的送分题。整张卷子大致分成四个部分选择题单选加多选、填空题、两道编程题、若干简答题。选择题大概20道左右覆盖C语法、操作系统、计算机网络、数据结构这些计算机基础内容难度中等但有几个多选很刁钻少选多选都不得分。填空题主要是C输出结果题和简单的数学计算比如给一段继承关系的代码让写出构造和析构的顺序。编程题是两道一道偏算法一道偏图形/几何。简答题则是典型的引擎岗风格内存布局、渲染管线、场景管理、性能优化。如果你准备过一段时间校招会发现这个结构不算意外但真正决定你能不能过的往往不是那些大路货题目而是简答题里暴露出来的工程思维深度。选择题错了还能蒙简答题要是写得空洞基本就宣告出局了。1.2 时间分配策略别在选择题上恋战两小时看着不少真坐下来写就会发现时间很紧。我自己的策略是把时间切成三块第一块约30分钟快速过一遍选择题和填空题遇到卡壳的题目先标记不恋战。第二块约60分钟主攻两道编程题先把思路写在草稿区再动手写代码。第三块约20分钟写简答题把关键术语和流程写清楚尽量分点作答。最后10分钟回查标记的选择题补漏。实测下来这个节奏是够用的但前提是选择题不能磨太久。尤其多选里那种“下列说法正确的是”题四个选项往往涉及四个不同的知识点想在考场上现场推导太费时间。正确做法是把选项当判断题确定对的打勾、确定错的打叉拿不准的就别选保证能拿到的分先拿到。1.3 考场之外这类笔试到底在筛什么人后来我跟畅游的面试官聊过一次他说笔试环节并不是指望你考满分而是要筛掉三类人语言基础不扎实的、数学功底太薄的、只会写业务代码不理解底层原理的。所以你会发现卷子里几乎每一道题都在往“原理”和“为什么”上靠而不是问你某个函数的参数列表。这个逻辑从一开始就锁定了整张卷子的出题偏好。2. C与底层内存题引擎开发的第一道门槛2.1 多态与虚函数表性价比最高的考点选择题第一梯队必有多态。引擎开发里到处都是继承和接口比如Actor、Component、Renderable这些基类运行时靠虚函数分发调用所以虚函数表的机制几乎是必考内容。我印象里有一道题问的是一个类含有一个虚函数那么sizeof(该类)是多少很多人会惯性答“成员变量之和”但忽略了虚函数指针vptr的存在。64位平台下空类加一个虚函数后大小是8字节一个指针大小。如果类里有成员变量还要考虑对齐。这个考点延伸出去还能考虚继承、纯虚函数、构造函数里调用虚函数、析构函数为什么要声明为virtual等。笔试里让我印象比较深的一道填空是class A { public: virtual void f() { cout A; } }; class B : public A { public: void f() { cout B; } }; int main() { A* p new B(); p-f(); delete p; return 0; }输出结果是B但如果A的析构函数不是虚函数delete p时只调用A的析构B的析构会被跳过。后来面试追问环节面试官专门问了这个派生类资源泄漏问题所以这题背后的知识点比题目本身重要得多。2.2 内存管理new/delete、智能指针与内存对齐引擎开发绕不开内存管理Unity、Unreal这类商业引擎都有自己的一套内存分配器但笔试考的还是语言层面的基本功。有一道简答题让我现在都记得请说明new和malloc的区别。基础答案是malloc只分配内存new还会调用构造函数free只释放内存delete还会调用析构函数new返回类型安全的指针malloc返回void*。但想拿高分还得补上new底层其实调用了operator new而operator new内部又调用mallocnew[]和delete[]要配对使用placement new可以在已分配内存上构造对象。智能指针也是重点。shared_ptr的引用计数机制、weak_ptr如何解决循环引用、unique_ptr为什么能做到零额外开销这些都要能顺口答出来。有一道选择题问的是两个对象互相持有shared_ptr会导致什么答案是内存泄漏必须把其中一个改成weak_ptr。这个场景在引擎的组件树或节点树里非常常见父节点持有子节点子节点又持有父节点指针处理不好就是泄漏。内存对齐也是引擎岗的高频题。一道典型题目是struct S { char a; int b; char c; };问sizeof(S)是多少。如果不考虑对齐直觉上是6字节但实际在默认对齐规则下是12字节int按4字节对齐char a占1字节后填充3字节b占4字节c占1字节后又填充3字节。调整成员顺序为int b; char a; char c;后可以压到8字节。这个知识点在引擎的序列化、网络数据包、顶点结构体定义中非常实用顶点属性布局设计不好就是白白多占显存带宽。2.3 STL容器底层从vector扩容到map的红黑树选择题里STL也占了相当大的比重。vector为什么插入效率高但中间插入慢因为它底层是连续内存中间插入需要搬移元素。vector是怎么扩容的大多数实现是1.5倍或2倍增长扩容时要重新分配内存、拷贝或移动旧元素、释放旧内存。这里有个隐藏考点如果元素类型没有定义移动构造函数扩容时就会退化成拷贝性能会差很多所以引擎里常见的math库类型都会实现移动语义。map和unordered_map的区别也是必考项。map底层是红黑树key有序插入查找都是O(log n)unordered_map底层是哈希表key无序均摊O(1)。引擎里如果需要一个稳定的遍历顺序比如渲染排序就用map如果只是快速查找资源ID到资源对象的映射用unordered_map更合适。但要小心哈希碰撞攻击和hash函数质量差的场景这是追问中可能展开的点。2.4 运算符优先级与const的坑填空里有一道出乎意料的题int a 1; int b a a; cout b;这题其实是未定义行为因为a和a在同一表达式中对同一个变量进行多次修改求值顺序不确定。但考试时我却硬算了一个答案事后复盘发现这题考的其实是“你知道它是未定义行为”这一层。这种题看着基础其实是区分“背过C”和“真读过C标准”的分水岭。不过现场做题时如果选项里有“未定义行为”一项基本就是正确答案。3. 数学与图形学基础向量、矩阵与变换的实战考察3.1 引擎核心逻辑里最常被抽问的数学概念游戏引擎本质上就是一个实时数学计算系统。角色移动要算位移摄像机要算视图矩阵渲染要算投影物理碰撞要算交点。所以引擎岗笔试必有一批数学题。畅游的卷子里数学题占比不低而且风格很务实不搞偏题怪题。我印象比较深的是这几类向量点积判断两个向量的夹角方向、投影长度。向量叉积求平面法向量、判断多边形的朝向左手/右手坐标系下方向不同。矩阵乘法顺序先旋转后平移还是先平移后旋转结果完全不同。变换矩阵的逆视图矩阵的逆、法线矩阵为什么要用逆转置矩阵。有一道选择题是这样一个物体从模型空间变换到世界空间先缩放2,2,2再绕Y轴旋转90度最后平移到1,0,0。问最终变换矩阵是什么。这个题的坑点在于矩阵乘法的顺序如果向量是列向量那么变换矩阵是T * R * S应用顺序是先从右边开始也就是先缩放、再旋转、最后平移。方向反了矩阵算出来完全是另一个东西。3.2 绕任意轴旋转与四元数必背公式简答题里考了一道绕任意轴旋转的方法。绕坐标轴旋转有现成公式但绕空间中任意单位轴旋转就得用Rodrigues旋转公式v v*cos(θ) (k × v)*sin(θ) k*(k·v)*(1 - cos(θ))这个公式是三维旋转的基础很多引擎的旋转工具、陀螺仪解算、骨骼动画插值都会用到。能把公式写出来并解释每一步含义比单纯背一个矩阵靠谱得多。四元数也是一道题请说明四元数相比欧拉角的优势。答案要点是欧拉角有万向锁问题插值不平滑四元数只需要4个分量旋转紧凑且可以用球面线性插值slerp实现平滑旋转。引擎里角色朝向、摄像机旋转基本都用四元数存储和插值。但要注意四元数也有坑单位四元数才能表示旋转使用前要归一化两个四元数相乘的顺序也不能反。3.3 视锥体与投影矩阵从“看得见”到“算得出”渲染相关的数学题也不能忽视。一道选择题问的是透视投影和正交投影的区别。答案很直白透视投影有近大远小的效果正交投影没有工程制图、UI渲染、2D游戏用正交投影3D场景一般用透视投影。再深一层的考点是视锥体裁剪。在渲染一个场景时CPU端会先判断一个物体是否在摄像机视锥体内不在就跳过绘制这个判断利用的就是视锥体的六个平面方程。一个AABB包围盒与视锥体的相交测试本质上是一系列点与面的符号判断。笔试不会让你现场推导六个平面方程但会问你“剔除一个场景中的物体有哪些手段”这时候答上视锥体裁剪、距离裁剪、遮挡剔除、背面剔除就说明你对引擎的粗粒度加速有概念。3.4 光照模型Lambert与Blinn-Phong图形学入门必考的光照模型卷子里也出现了。Lambert漫反射模型是diffuse albedo * lightColor * max(dot(N, L), 0)没考虑视角方向。Blinn-Phong在这之上加了半程向量H normalize(L V)用dot(N, H)的幂次控制高光范围。这里有个细节Blinn-Phong之所以比Phong好是因为半程向量计算简单且高光过渡更平滑在实时渲染里几乎成了默认选择。这种题的价值不只是让你背公式而是面试官想看看你有没有真正实现过光照。如果你能在简答题里补一句“实际移动端渲染中会用half精度向量做近似减少ALU开销”那档次立刻就上去了。4. 算法与数据结构压轴有限时间内写出可靠的方案4.1 两道编程题的回忆与破题思路编程题一共两道都是在线IDE里手写代码不要求能编译运行但要求逻辑清晰。第一道是经典题目的变体给定一个整数数组和一个目标值找出数组中三个数之和最接近目标值的组合返回这个和。这道题本质上就是三数之和的变种。标准做法是排序加双指针先排序复杂度O(n log n)。固定第一个数i用左右指针j和k指向i1和数组末尾。计算nums[i] nums[j] nums[k]与target的差值更新最小差值。如果和小于target左指针右移大于target右指针左移等于target直接返回。这个解法的时间复杂度是O(n^2)空间复杂度O(1)。注意去重逻辑否则同一个组合会被算多次。我写的时候还加了一个小优化如果固定数已经是三个数里最小的且nums[i] * 3 target可以直接剪枝。第二道编程题偏几何给定平面上若干个点求能构成的最大三角形面积。我当时的思路是用凸包先求出点集的凸包然后在凸包上枚举三个点计算面积。凸包可以用Andrew单调链算法时间复杂度O(n log n)枚举三点是O(m^3)m是凸包上的点数实际会小很多。更优的做法是旋转卡壳但笔试时间有限能写出凸包加暴力枚举已经比绝大多数人强了。4.2 算法题之外的隐藏考点我在做第一道编程题时其实犯了一个小错误一开始忘了排序直接用三重循环暴力解虽然答案对但复杂度是O(n^3)数据量一大就挂了。后来我在注释里补了双指针的优化版本。这也算一个经验在线笔试不会跑大数据但面试官会看你的最终代码你交上去的不能是“能跑就行”的烂代码。此外数据结构的应用也常在简答题环节出现比如场景中有很多物体玩家点击屏幕要快速找到被点击的物体你会怎么做这个问题其实考的是空间加速结构——把物体按网格划分、四叉树/八叉树划分或者用BVH树。点击时从根节点向下遍历只检查可能相交的叶子节点这样不必遍历场景中所有物体。如果你能画出一个简单的八叉树结构并说明插入和查询流程那就是一道完整的加分答。4.3 时间不够时的答题策略两道编程题如果只能完整做出一道那优先做哪道我的经验是先做自己最有把握的那道保证拿全分再回头啃另一道。对于第二道题哪怕写不出完整代码也要把自己的思路分步骤写清楚第一步求凸包第二步枚举面积第三步用最大面积公式。阅卷时只要思路对也能拿一部分分。最忌讳的是死磕一道题另一道完全空白。5. 引擎架构与性能优化开放题从答题思路看工程素养5.1 场景管理与空间加速结构简答题的开放程度比较高我记得有一道题大概是一个大型开放世界场景中有数万个物体如何高效管理并渲染它们这个问题在引擎开发中非常典型可以从几个层面展开CPU层面场景管理。用四叉树2D或八叉树3D对物体做空间划分视锥体裁剪时只需要访问可能可见的节点。渲染层面合批与剔除。静态物体可以预先合并成更大的网格减少Draw Call动态物体用GPU Instancing还可以做遮挡剔除。数据层面LOD多级细节。远处物体用低模、低分辨率贴图近处用高模减少像素着色压力。加载层面流式加载。只加载玩家附近的资源远处的放磁盘或内存待命。写答案时不要写成流水账最好能体现“为什么”。比如为什么要用八叉树而不是均匀网格因为八叉树能自适应物体分布密度在空阔区域用大节点在密集区域用小节点树深度均衡查询效率更高。这种因果解释比罗列概念有用得多。5.2 渲染管线与GPU瓶颈引擎岗的简答题十有八九会涉及渲染管线。畅游的卷子里问了“简述一个物体的渲染流程。”标准答案是顶点着色器顶点变换→ 几何着色器可选→ 光栅化 → 片段着色器 → 混合与输出。但这个答案太基础了想拿高分得补充两点第一顶点着色器里做了什么。通常是把模型空间的顶点坐标乘以模型矩阵、视图矩阵、投影矩阵得到裁剪空间坐标。这个阶段还可以做顶点动画、顶点色处理、法线变换。第二性能瓶颈怎么定位。引擎渲染卡顿往往不是所有阶段都慢而是某个环节拖了后腿。比如Draw Call太多CPU提交渲染命令的时间就会暴涨像素填充率不够全屏雾效或高分辨率下帧率就掉得厉害。定位方法是分层排查先看是CPU bound还是GPU bound。最简单的方法是把屏幕分辨率调低如果帧率明显上升说明是GPU像素处理瓶颈如果帧率没变化很可能卡在CPU端的Draw Call提交或逻辑更新。5.3 资源管理引用计数与加载卸载资源管理题出现得很自然游戏中一个角色模型被多个场景引用如何管理它的生命周期答案是引用计数。加载一个资源时计数加一释放时减一计数归零时才真正从内存中卸载。这里要补充的是引用计数有循环引用问题资源A引用BB又引用A两边计数都不为0所以引擎还会配套资源依赖图或专门的资源管理器做统一卸载。更进一步引擎的资源加载往往是异步的。主线程发起加载请求IO线程读文件再丢回主线程做解析和上传GPU。笔试如果问“加载大模型时卡顿怎么解决”就可以从异步加载、分帧加载、预加载、内存映射四个角度展开。5.4 物理与碰撞检测的常见问题引擎岗也会涉及物理。一个典型的题是如何判断两个物体是否发生碰撞从粗到细的思路粗检测阶段用包围体AABB或球体做初步相交测试排除大部分不相交的物体。细检测阶段对粗检测命中的物体对做更精确的凸包检测如GJK算法或使用SAT分离轴定理。数据加速用BVH或空间哈希维护碰撞体的空间分布避免两两检测。如果物体是凹多边形要先分解成多个凸体或者直接用三角形网格做精确检测但性能更差。引擎里多数会用凸包近似凹体比如用多个凸包拼接表示一个复杂关卡墙壁。这些点讲出来后面试官就知道你是真做过物理模块。6. 笔试之后的复盘那些让我后怕的细节6.1 对照知识点清单做一次自我体检笔试结束后我没有干等结果而是花了一个晚上把整张卷子默写出来然后对着题目整理了一份自己的“引擎开发工程师知识点体检表”。这里分享出来供准备笔试的同学参考考点类别具体知识点掌握程度1-5补救方式C语言虚函数表、内存对齐、智能指针、移动语义3《Effective C》 手写小测试数据结构vector/map/unordered_map底层、红黑树、哈希表4刷LeetCode容器题数学点积叉积、矩阵变换、四元数、Rodrigues公式3重写一遍变换库图形学渲染管线、视锥裁剪、光照模型、LOD3实现一次软渲染器引擎架构场景管理、资源管理、物理碰撞、异步加载2阅读开源引擎源码算法双指针、凸包、空间加速结构4LeetCode ACM题单这份表格最大的作用不是记知识点而是让你清楚自己的短板在哪里。我当时最弱的是引擎架构模块因为平时主要在写业务逻辑很少从引擎全局视角思考问题。后来我专门去读了一些开源引擎的源码文档把场景管理和资源加载的部分搞明白了才在后续面试中有了底。6.2 笔试题目在面试中的延续有个很容易被忽视的点笔试的简答题内容面试官往往会拿来作为追问的引子。比如笔试考了“智能指针的循环引用”面试时他可能就会问“你在项目里遇到循环引用的实际场景吗怎么排查出来的”如果笔试时只是背答案到这里就露馅了。所以我在校招期间的做法是每场笔试结束后把开放题当成一个小型研究项目去补全它的完整方案而不是只管对错。这样既巩固了知识也为后续面试积累了可以讲的实际案例。6.3 给后来人的几点经验回过头看畅游2020校招笔试其实是一场“压力测试”它考的不是你掌握多少知识点而是你在有限时间内、面对不熟悉的在线IDE时能不能稳定输出高质量的答案。几个实用经验提前熟悉牛客网等平台的IDE用法特别是C代码如何输入输出避免现场调试五分钟。答简答题时用总分的结构先给结论再列要点最后补充理由。阅卷人扫一眼就能抓住重点。编程题哪怕不会也能拿步骤分思路写详细比留空白强一万倍。不要因为一道选择题卡住而影响整体节奏先跳过最后回来再蒙。最后聊几句实在的笔试是校招的第一道关卡但它的作用并不只是“过不过”。我在准备畅游笔试的过程中被迫把C语言、数学、图形学、数据结构和引擎架构这几块知识做了一次系统的串联这个收获比我拿到的那些offer本身还值。后来我在做自己的小游戏项目时很多当年笔试里“死记硬背”的结论比如内存对齐对顶点数据的影响、矩阵运算顺序对物体变换的作用都变成了日常工作的思维习惯。如果你也在准备引擎开发方向的笔试我的建议是别只刷题多问自己对一个知识点能不能讲清楚“为什么”这种深度思考才是校招真正要考察的东西。