一、聊聊那次笔试的整体印象前阵子整理电脑里的旧文件翻到2020年参加搜狐畅游校招笔试的记录顺手复盘了一遍。当时投的是引擎开发工程师方向说实在的这份卷子考察的面比预想中广难度也足够筛掉一批人。如果你正准备投游戏公司的引擎岗或者刚入行想了解这个方向到底考什么这篇复盘值得认真看看。先说结论畅游的引擎开发笔试核心就三块——C底层功底、计算机图形学基础、数据结构和算法的实际场景应用。另外还有一道综合题考察对引擎模块的整体理解。整张卷子没有死记硬背的八股问答所有题目都带着实际开发场景这点和很多互联网公司纯面试背题的路数不一样更看重候选人面对真实问题时能不能拿出合理的工程思路。引擎开发岗位和普通后端开发、客户端开发最大的区别在于你需要同时具备系统级语言功底、数学基础和渲染相关的专业知识。这份笔试就是围绕这三个维度来设计的下面一层一层拆开讲。二、笔试结构解读题型分布与考察逻辑2.1 五大模块的题型占比从记忆中的试卷结构来看整场笔试大约两个小时题目分五个部分模块题型题量重点考察方向C语言基础单选多选15题左右指针、内存、STL底层实现、C11特性数据结构与算法编程题2-3题手写代码能力、边界处理、复杂度意识计算机图形学简答计算5-6题渲染管线、坐标变换、光照模型数学基础填空计算3-4题向量运算、矩阵推导、几何判定引擎综合理解开放型问答1-2题引擎架构、优化思路、模块分工单从题型分布就能看出引擎开发并不是让你背UI API或者写业务逻辑它更看重底层语言能力和渲染相关知识储备。C和数据结构占比最大图形学次之数学贯穿其中最后用一道开放题考察你对整个引擎系统的理解深度。2.2 笔试背后的筛选思路咱们换个角度想为什么笔试要这么设计如果你做过游戏开发就会明白引擎开发工程师日常干的事是这些——写渲染器、做资源管理、开发物理模块、优化性能瓶颈、为上层策划和逻辑开发提供工具链。这些工作无一例外要求你能驾驭C这种偏底层的语言理解内存模型、理解对象生命周期能看懂和实现图形学算法至少要知道一帧画面是怎么画出来的有扎实的数学功底尤其是线性代数和几何计算引擎里的任何变换都是矩阵运算具备把算法应用到实际场景的能力而不是只会刷LeetCode。所以整张卷子的筛选逻辑很清楚不是考你会不会用某个引擎而是考你有没有具备成为一个引擎开发工程师的底层素质。了解这个逻辑后你就可以针对性地准备了。三、C与数据结构一切引擎功能的地基3.1 那些年笔试中反复出现的C考点畅游这份卷子的C部分难度不低主要集中在几个方面。指针和引用的本质区别。这题看起来基础但考察的深度可以很夸张。题目大概是这样给定一段代码让你判断指针作为函数参数传入时修改指针本身和修改指针指向内容之后函数外部变量的变化情况。这就是经典的指针传参问题。答题时要明确指针本身是值传递但指针指向的内容是共享的。如果要修改指针本身必须传二级指针或者引用。内存对齐和sizeof计算。我对这题的印象特别深因为它有一组struct里面包含char、int、double成员让你计算在不同对齐方式下的sizeof结果。这种题就是考察你知不知道内存布局的规则。计算规则是结构体每个成员的偏移量必须是该成员大小的整数倍整体大小必须是最大成员大小的整数倍。举个例子struct Test { char c; // 偏移0占1字节 int i; // 偏移4占4字节 double d; // 偏移8占8字节 };这里c后面有3个字节的padding整体大小是16字节。如果你没考虑对齐直接算14813那就掉坑里了。笔试中这类题几乎必出值得好好复习。虚函数与多态的实现原理。引擎开发中虚函数用得非常多因为组件系统、抽象接口都依赖于多态。笔试会考虚函数表的概念比如一个类有虚函数那么它的对象内存布局是怎样的虚函数表存在哪里多重继承下有几个虚函数表指针这些基础问题背后指向的是——你能不能理解引擎中组件调度的开销从哪来。还有一道经典题让我印象很深STL容器底层数据结构与迭代器失效问题。vector在插入时迭代器为什么会失效list插入时迭代器会不会失效map内部是什么结构插入删除的时间复杂度是多少这些不只是面试八股实际写引擎工具和编辑器时经常遇到。比如你在遍历场景中的组件列表时一边遍历一边删除会导致崩溃这就是迭代器失效问题。C11/14的新特性也是必考方向。记得选择题中有一道考察std::move和std::forward的区别还有一道关于shared_ptr的线程安全性判断shared_ptr的引用计数是线程安全的但shared_ptr对象本身不是线程安全的多个线程同时写同一个shared_ptr对象会有问题。这个点如果没深入研究过很容易答错。3.2 数据结构考点不单纯是刷题笔试的编程题部分涉及到的数据结构考察比传统互联网公司更贴近工程场景。我在那次笔试中遇到了一道场景题在游戏中玩家对象和场景对象都继承自同一个基类需要你设计一个数据结构来存储所有对象并支持快速遍历和查找。这道题并没有一个标准答案但考察的点非常明确你会不会根据实际需求选择合适的数据结构。如果对象数量不大、遍历频繁可以用vector存储利用缓存友好性提高遍历速度如果需要频繁插入删除则考虑list如果需要根据ID快速查找可以加一层unordered_map做索引。这种思维模式比单纯刷手撕红黑树更贴近引擎开发的真实场景。还有一道考察哈希表实现原理的简答题问题比较直接哈希冲突的解决方法有哪些分别有什么优缺点如果你做过Unreal或Unity的资源系统对这个问题应该不陌生。游戏引擎的资源加载模块中资源句柄到实际资源的映射底层通常就是哈希表。链地址法和开放定址法的性能差异取决于哈希表的负载因子和哈希函数的质量这些工程细节都是引擎开发中会真实遇到的。3.3 手写代码的避坑心得笔试的编程题环节时间紧、压力大最怕的不是不会做而是思路对了但代码细节崩了。这里分享几个我踩过的坑第一边界条件一定要先写清楚。如果让你实现一个函数入参为空的处理逻辑要先写否则后面主逻辑写一半发现前面的分支判断漏了改动起来很麻烦。第二注意栈溢出问题。递归方案在数据量小的时候能过但笔试环境的测试用例不可控。能用迭代就不建议用递归。举个例子你写一个二叉树的深度遍历用递归很容易实现但如果二叉树深度达到几千层递归会造成栈溢出。改用栈来模拟递归才是工程上稳妥的做法。第三复杂的代码逻辑要手写注释。试卷的编程题是手写或在线编辑的阅卷人看你代码的时候清晰的注释能提升很多印象分。比如你在写一个多线程资源加载的代码为什么加锁、为什么用双检锁注释写清楚这能体现出你的工程素养。四、图形学与数学引擎开发的灵魂4.1 渲染管线吃透每一道流程图形学部分笔试首先考的就是渲染管线。这几乎是所有游戏公司引擎岗必考的内容。题目会问一个物体从CPU到最终屏幕显示经过了哪些阶段每一阶段的输入输出是什么答案要从应用阶段开始写CPU端进行剔除、排序、提交渲染命令然后GPU端依次经过顶点着色器、几何着色器可选、光栅化、片段着色器、测试与混合。关键点在于顶点着色器接收模型空间的顶点坐标经过MVP矩阵变换到裁剪空间光栅化将图元转换为像素片段这一步会产生片元片段着色器计算每个像素的最终颜色涉及光照、纹理采样等输出合并阶段深度测试、模板测试、混合操作最终决定像素显示。如果你只是机械地背流程顺序那只能拿基础分。想要拿高分需要理解每个阶段在引擎中对应哪个模块比如引擎中的RenderThread是负责提交渲染命令给GPU的GPU的顶点和片元阶段则由Shader控制。笔试中有一道题直接问引擎中为什么要将渲染命令和游戏逻辑分离到不同线程这需要你理解游戏逻辑是CPU密集型的而渲染命令提交也占据CPU时间如果不分离帧率会受限于逻辑耗时。这道题我在笔试时答得比较完整核心观点是降低主线程的负担将渲染数据的准备和提交并行化。4.2 坐标变换矩阵推导与代码实现坐标变换是整个图形学的基础中的基础笔试也自然会考。当时有一道计算大题给出摄像机的位置eye、观察点center和上方向up推导并计算视图矩阵View Matrix。这道题考的就是LookAt矩阵的构造过程。你需要分三步来算计算前向量f normalize(center - eye)计算右向量s normalize(cross(f, up))计算真正的上向量u cross(s, f)。最后构造矩阵。注意这里还有一个补充计算s、u、f三个向量要和eye位置拼成最终矩阵。完整的过程如下// 计算视图矩阵 Vec3 f normalize(center - eye); Vec3 s normalize(cross(f, up)); Vec3 u cross(s, f); Mat4 view; view[0][0] s.x; view[0][1] s.y; view[0][2] s.z; view[1][0] u.x; view[1][1] u.y; view[1][2] u.z; view[2][0] -f.x; view[2][1] -f.y; view[2][2] -f.z; view[3][0] -dot(s, eye); view[3][1] -dot(u, eye); view[3][2] dot(f, eye);这题关键在于你必须理解构造原理而不是死记代码因为题目可能会变化比如up向量与f方向平行怎么办这就是一个修正点需要你判断如果f和up完全同向或反向需要更换up向量。这种细节恰恰是引擎开发中容易踩坑的地方。旋转的表示也是一个绕不开的考点。环绕某个轴旋转用矩阵怎么表示用四元数又怎么表示两者之间如何相互转换我印象里笔试中有一道简答题为什么在骨骼动画中经常用四元数表示旋转而不是欧拉角或旋转矩阵答案至少应该包含三个层面欧拉角存在万向节死锁问题在某些角度下旋转会丢失一个自由度四元数做插值Slerp时得到的旋转轨迹更平滑适合做动画插值矩阵旋转做插值不方便而且存储量更大对GPU带宽是一种浪费。4.3 光照模型与物理渲染的工程理解光照模型是图形学笔试中另一个重头戏。2020年那会儿PBR已经非常流行了所以卷子里有几道题都是围绕光照计算的直观原理展开的。一道送分题是写出Phong光照模型中环境光、漫反射、镜面反射三部分的计算公式并解释每个参数含义。这种题没太多技术门槛但公式要写对注意镜面反射的高光指数含义要解释清楚。更有区分度的一道题是描述从Lambert漫反射模型到PBR理论中的GGX高光模型光照模型经历了哪些重要演进每个模型解决了什么问题这道题对没有真正接触过渲染的同学来说难度不小。我的思路是这样的Lambert模型只考虑漫反射适用范围有限Phong和Blinn-Phong加入了高光项使得非金属材质看起来有光泽但参数是经验性的物理上并不准确Cook-Torrance模型引入了微表面理论和BRDF的概念开始从物理角度描述光的反射现代PBR如GGX高光模型则基于微表面理论、能量守恒和菲涅尔方程用物理真实的光照参数粗糙度、金属度来描述材质。引擎开发中理解这些模型很重要因为你在写Shader或者调引擎渲染管线的参数时需要知道背后的原理才能做出正确的效果调整。当时我答这道题时把能量守恒、Fresnel-Schlick近似公式都写了上去并举例说明金属和电介质在反射特性上的差异这部分让阅卷人看到你是真的理解而不是背概念。4.4 碰撞检测AABB与几何判定引擎开发笔试基本不会跳过碰撞检测。卷子里有一道题考察AABB包围盒求交的相关知识给了两个AABB的坐标让你判断是否相交。两个三维AABB相交的判定是在三个坐标轴上分别判断它们的投影区间是否重叠只要有一个轴不重叠就不相交。代码实现非常简单bool IntersectAABB(const AABB a, const AABB b) { return a.minX b.maxX a.maxX b.minX a.minY b.maxY a.maxY b.minY a.minZ b.maxZ a.maxZ b.minZ; }这道题扩展的问法是如果两个包围盒碰撞后如何计算碰撞的穿透距离以及如何解析碰撞。这里考的是物理引擎的基础概念。碰撞穿透向量可以通过计算两个AABB重叠区域在三个轴的深度来确定最小穿透轴决定了解析方向。引擎开发中这是物理模块的一个重要基础。还有一题考射线与三角形的相交检测用的是Möller-Trumbore算法。这个算法利用重心坐标将射线方程与三角形所在平面联立求解一次性算出路程t、重心坐标u和v然后判断是否在三角形内部。这道题比较硬核建议准备引擎岗的同学把这个算法的原理和代码都吃透因为很多场景射线拾取、遮挡检测、编辑器操作都会用到。五、编程算法题实际场景驱动的代码考察5.1 动态规划风格的算法真题回顾笔试的编程题没有直接给裸的算法题而是包装了一层游戏场景的外壳。比如有一道题原型是给你一组城市列表和道路连接情况找到从起点到终点的最短路径长度。这和游戏地图寻路直接相关。拿到这种题先不要慌剥掉包装后就是最短路径问题。Dijkstra算法就能解决。这里给一个简洁的模板笔试时可以根据情况改造#include vector #include queue #include limits using namespace std; struct Edge { int to; int weight; }; int Dijkstra(const vectorvectorEdge graph, int start, int end) { vectorint dist(graph.size(), INT_MAX); priority_queuepairint, int, vectorpairint, int, greater pq; dist[start] 0; pq.push({0, start}); while (!pq.empty()) { auto [d, u] pq.top(); pq.pop(); if (d dist[u]) continue; if (u end) break; for (const auto edge : graph[u]) { if (dist[u] edge.weight dist[edge.to]) { dist[edge.to] dist[u] edge.weight; pq.push({dist[edge.to], edge.to}); } } } return dist[end]; }复杂度的分析也不能丢优先队列实现下Dijkstra的时间复杂度是O((VE)logV)。笔试如果时间允许把复杂度和空间占用都写清楚这是加分项。5.2 图与二叉树相关场景题还有一道题是给出一棵二叉树要求返回从根节点到某个目标节点的路径。这个在游戏开发中的直接应用可以类比为场景管理里的层级关系查找或者UI树的消息传递路径。思路深度优先遍历保存路径栈找到目标后返回整个栈注意递归退出时的路径清理。bool FindPath(TreeNode* root, TreeNode* target, vectorint path) { if (!root) return false; path.push_back(root-val); if (root target) return true; if (FindPath(root-left, target, path)) return true; if (FindPath(root-right, target, path)) return true; path.pop_back(); return false; }这道题的易错点在于递归路径的回溯临时节点必须及时pop否则路径会包含非目标路径上的节点。5.3 笔试的工程代码题线程安全的队列还有一道题我觉得特别值得讲因为它是纯工程向的设计一个线程安全的生产者-消费者队列支持多线程环境下的Push和Pop操作。这道题在引擎开发里太常见了比如主线程和其他工作线程之间的命令队列、日志队列都属于这类结构。我当时的答题思路是使用std::mutex加std::condition_variable实现一个阻塞队列#include queue #include mutex #include condition_variable templatetypename T class SafeQueue { public: void Push(T value) { std::lock_guardstd::mutex lock(m_mutex); m_queue.push(std::move(value)); m_cv.notify_one(); } T Pop() { std::unique_lockstd::mutex lock(m_mutex); m_cv.wait(lock, [this] { return !m_queue.empty(); }); T value std::move(m_queue.front()); m_queue.pop(); return value; } private: std::queueT m_queue; std::mutex m_mutex; std::condition_variable m_cv; };这题想拿高分还需要额外回答两个问题为什么Pop使用condition_variable而不用忙等因为忙等会白占CPU引擎中多个工作线程都在跑不能让它们在空队列上疯狂空转notify_one和notify_all的区别用在哪里单消费者时notify_one即可多消费者场景下可能需要notify_all唤醒全部等待线程。这类题能直接看出你对并发编程的理解深度。引擎的工作线程设计、渲染命令提交、资源异步加载都离不开并发容器这个概念必须滚瓜烂熟。六、复盘总结哪些准备有效、哪些坑必须避6.1 我实际验证过的复习路线复盘完这套笔试题我把自己当时的准备过程梳理了一下对后来准备引擎岗位校招的学弟学妹们有几点建议C不是刷出来的是用出来的。试着去实现一个简单的STL容器比如vector或string或者去给现有引擎代码库贡献一个小功能比你刷一百道选择题更有效。笔试中那些看似基础的问题只有你在实际编码过程中踩过坑才能真正答对。数学要动手推导不要只背公式。视图矩阵、投影矩阵、旋转矩阵的推导自己拿纸笔推三遍考试的时候才记得牢。单纯背公式题目稍微换个问法就会卡壳。图形学要吃透渲染管线的每一个阶段。这是引擎开发的核心知识。推荐把《Unity Shader入门精要》和《Real-Time Rendering》中的涉及管线部分读透不需要完全背下来但至少能清楚地讲述每一阶段的输入输出。算法题要习惯用工程视角思考。不只是通过测试用例还要考虑代码的可读性、可维护性和边界情况。笔试阅卷人最喜欢看到你在代码里考虑异常分支。6.2 笔试中我踩过的一个坑这里想专门提一个我自己的教训。笔试里有一道C的改错题考的是一段shared_ptr循环引用的代码。我一开始想当然地觉得shared_ptr能自动管理内存所以没注意到两个对象互相持有对方的shared_ptr会导致引用计数永远无法归零从而内存泄漏。正确的做法是把其中某一方的持有类型改为weak_ptr。这道题提醒我笔试改错题不是单纯找语法错误更多是在找逻辑和设计上的隐患。引擎开发中大量的对象生命周期管理问题本质上都是循环引用和所有权归属问题笔试的题目其实就是对工程实践的映射。6.3 最后一点体会翻看那次笔试题时我最大的感受是游戏引擎开发工程师的笔试不会考太偏的门类但会对基础知识的深度和细节抠得很细。题目与游戏开发场景结合紧密比如路径查找、碰撞检测、渲染命令、对象生命周期管理都是引擎开发中天天打交道的事。准备这个岗位比起刷海量的题更关键的是建立一套完整的、成体系的底层知识框架同时配合项目实践去验证和深化这些知识。如果你正在准备游戏公司的引擎岗笔试不妨把目标定在C底层机制、数学推导能力、渲染管线的深度理解这三个方向上每一个都亲自手写代码验证过笔试时心里才有底气。这些硬功夫在真正入职后做引擎开发时同样会派上大用场。