雷火每轮笔试通知发出来之后准备室里最多的两个问题就是第二批跟第一批是不是同一套题我要不要去搜第一批的回忆版来刷我的回答通常是题大概率不会重复但知识点范围几乎是锁死的你真正该做的不是赌题而是把雷火游戏研发这个岗位的技术栈底子摸透。这篇文章就按我自己的备考经验把这类笔试的命题逻辑、章节重点、现场应对和考后复盘全部梳理一遍希望能给准备下场的朋友一个可执行的参考。先说说我为什么对雷火的笔试印象这么深。早几年我准备进游戏行业的时候也刷过很多大厂笔试发现一个现象同样是考察算法互联网后端笔试更偏爱“设计一个LRU”“实现一个线程池”这类贴近业务中间件的题而到了雷火这边题目往往会裹上一层游戏场景的外衣比如寻路、碰撞、状态同步、对象管理。你以为在考算法实际上它同时还在考你“能不能在游戏代码里用起来”。这个差异就是准备阶段最大的方向标。1.1 岗位定位游戏研发工程师要的是什么样的人网易互娱雷火事业群的产品线覆盖了大型MMO、多人竞技、开放世界等多个品类这些项目对研发的要求不是“能写通一个LeetCode Medium”就够的更看重几个底层能力C功底扎实对内存布局、对象生命周期、虚函数机制有真实理解而不是背概念。算法能力可落地树、图、搜索、动态规划这些基础结构能快速写对并且理解它们在游戏系统里的映射。具备实时系统意识多人同屏、战斗同步、资源加载这些场景下能意识到性能、延迟、内存开销的问题。有游戏逻辑的体感哪怕没做过完整游戏也要能说出战斗逻辑框架、技能状态机、碰撞处理这些基本模块的常见做法。笔试筛的就是这几项中的硬功底。因为面试官一天要面很多人笔试成绩是简历之外最客观的第一道筛选。所以笔试内容通常不会出偏题怪题而是把游戏研发日常真正用得到的知识点翻来覆去地考。1.2 “第二批”到底意味着什么同一招聘批次分成两批甚至多批笔试最直接的原因是报名人数多、机位资源有限需要分流。对候选人来说分批意味着出题组会准备多套等价的试卷题目不同但考察的知识点和难度梯度基本对齐。所以如果你在等第二批最聪明的做法不是到处找第一批的真题而是按“同一知识地图、多题型变换”的思路来准备。我见过有人为了搜回忆版题目熬夜到三点结果考场上发现一道原题都没有崩溃得影响心态。反过来把时间花在梳理知识体系上的人就算题型变了照样能应对。2. 知识点地图五类必考模块的权重与典型出题手法我自己备考时做了一张清单把雷火这类游戏研发笔试的考点分成了五个模块。虽然批次不同、题目不同但这张清单基本覆盖了所有可能出现的方向这里直接分享出来。模块大致权重常见题型准备建议C语言特性20%-25%选择题、填空题、改错题重点复习虚函数、内存对齐、智能指针、移动语义、STL底层数据结构与算法40%-45%编程题、手写算法题树、链表、图遍历、BFS/DFS、DP、位运算都要熟练计算机基础15%-20%选择题、简答题网络TCP/UDP、操作系统进程线程、锁和死锁、数据库基础图形学与数学10%-15%选择题、计算题向量、矩阵变换、坐标系、光栅化基础概念游戏系统设计5%-10%简答、场景题状态机、对象池、帧同步、网络同步等常见话题这五个模块的权重不是我拍脑袋估的是我结合自己笔试经历和后来带人复盘时总结出来的常见分布。后面几节分别展开说每个模块到底怎么考、怎么答才算答到点子上。2.1 C语言特性不考语法考你把对象当成内存看的能力市面上很多笔试对C的考察停留在“这个代码输出什么”的层面但雷火这类游戏大厂会明显更进一步。它喜欢把几个知识点揉在一个选择题里比如#include iostream using namespace std; class Base { public: virtual ~Base() { cout ~Base()\n; } }; class Derived : public Base { public: ~Derived() { cout ~Derived()\n; } }; int main() { Base* p new Derived(); delete p; return 0; }这道题看着简单但背后同时考察了虚析构函数为什么必要、new和delete配对、多态机制的实现逻辑。如果你只记住“基类析构函数要加virtual”这个结论没想过它是因为delete基类指针时要通过虚表找到派生类析构函数那么换一道关于虚表指针布局的题就会露馅。所以我给备考者的建议是C部分不要只看语法书至少要把《深度探索C对象模型》里面关于对象布局的章节翻一遍搞明白虚表指针存在对象内存的哪个位置、多重继承时虚表怎么组织、空类为什么占一个字节。这些是游戏研发日常排查崩溃问题时真正会用到的底层知识。2.2 数据结构与算法游戏逻辑的基本功不能只会套模板算法题是笔试的大头也是区分度最高的部分。我观察近年来的出题趋势纯背 LeetCode 答案已经不好使了因为题目会改场景。举几个典型的包装方式“玩家在地图上从A点到B点中间有障碍物求最短路径” —— 本质是 BFS / A*。“一份技能升级表每个技能有前置技能和消耗点数求最省点数方案” —— 本质是图论 / DP。“排行榜要实时维护前100名” —— 本质是堆 / 跳表 / 有序结构。这就要求你不仅会写算法还能识别题面背后的数据结构和算法模型。备考时最好刻意练习“读题拆模型”的能力拿到一道题先不急着写代码先在草稿纸上标出这是树、图、区间、状态转移中的哪一类再选对应解法。这个习惯在笔试限时环境下特别重要。2.3 计算机基础网络和操作系统的考察很实务游戏研发绕不开网络同步和性能优化所以笔试里关于TCP/UDP、多线程、内存管理的题目往往不是死记硬背而是放在具体场景里。比如问“战斗服向客户端广播单位位置选择TCP还是UDP为什么”这类题没有绝对标准答案但面试官想看你能不能说出“TCP可靠但可能队头阻塞、UDP不可靠但延迟低游戏位置同步通常用UDP或应用层自定义可靠协议”这一套逻辑。同理多线程题目喜欢问“对象池为什么需要加锁、怎么设计一个无锁队列的心跳场景”这都是在考察真实工程中会遇到的问题。2.4 图形学与数学不深入但基础概念必须清晰游戏研发不是每个岗位都做渲染引擎但即便是玩法逻辑岗也必须懂向量、矩阵和坐标系转换。原因很简单玩家位置、朝向、技能范围、镜头跟随这些全部离不开三维空间的数学表达。常见的考察方向是给一个点坐标经过平移、旋转、缩放后求新坐标或者判断两个AABB是否相交或者给一个三维向量求归一化。这些题目不会很复杂但要求你计算准确、表达清晰。备考时把线性代数的基础部分过一遍尤其是矩阵乘法顺序、左右手坐标系、点积和叉积的几何意义基本就能覆盖。2.5 游戏系统设计简答题是拉开差距的隐藏赛道很多人忽略笔试里的简答题觉得随便写两句就行。这个想法很危险。压线的候选人可能正好因为你简答题写得比别人有条理就被捞进面试了。游戏系统设计的简答题通常是开放性的比如如何设计一个技能系统如何实现一个背包系统如何做帧同步状态回滚这类题没有唯一答案但拿高分的关键是展现系统思维而不是堆砌名词。我在后面的章节专门用一整节讲这类题怎么答先说结论分层拆解、时序清晰、考虑边界。3. 算法与数据结构真题拆解按出题思路推演解题路径算法题是笔试的主战场也是复习时投入时间最多的一部分。这一节我挑了三个有代表性的题目类型完整推演一遍解题路径不是直接给答案而是带着“出题人想考什么”的思路去拆。3.1 链表与指针操作不只写对还要写出健壮性链表题是笔试常客因为它能同时考察指针操作、边界处理和递归/迭代两种思维。以最常见的单链表反转为例。struct ListNode { int val; ListNode* next; ListNode(int x) : val(x), next(nullptr) {} }; ListNode* reverseList(ListNode* head) { ListNode* prev nullptr; ListNode* cur head; while (cur ! nullptr) { ListNode* next cur-next; cur-next prev; prev cur; cur next; } return prev; }这段代码的核心在于必须先把cur-next存下来再改动指针指向。很多人在笔试现场容易忽略这个顺序导致链表断掉。出题人想要看到的不只是你能背出反转逻辑而是你能在答完后主动检查空链表、单节点链表这两种边界情况。我建议笔试时如果碰到链表题写完代码后在注释里补一句边界处理比如// 处理空链表或单节点的情况 if (head nullptr || head-next nullptr) return head;这种细节在机评时未必算分但在人工复看答题记录时会给面试官留下“这个候选人工程习惯不错”的印象。3.2 地图寻路与BFS题面是游戏模型是经典算法雷火笔试里出现“最短路径”“能否到达”“最小步数”这一类题目时大概率会包装成地图或棋盘场景。这个我建议直接用BFS的模板去套因为BFS天然适合“等权重图求最短步数”。举个例子题目如果换成“二维网格中1表示障碍物0表示可通行求从(0,0)到(m-1,n-1)的最短路径步数”核心代码是这样的#include queue #include vector using namespace std; int minSteps(vectorvectorint grid) { int m grid.size(), n grid[0].size(); if (grid[0][0] 1 || grid[m-1][n-1] 1) return -1; vectorint dx {-1, 1, 0, 0}; vectorint dy {0, 0, -1, 1}; queuepairint,int q; q.push({0, 0}); grid[0][0] 1; int steps 0; while (!q.empty()) { int sz q.size(); while (sz--) { auto [x, y] q.front(); q.pop(); if (x m-1 y n-1) return steps; for (int i 0; i 4; i) { int nx x dx[i], ny y dy[i]; if (nx 0 nx m ny 0 ny n grid[nx][ny] 0) { grid[nx][ny] 1; q.push({nx, ny}); } } } steps; } return -1; }这道题看起来不难但很多人会在三个地方出错一是没有把起点标记为已访问导致重复入队二是把步数更新放在层序遍历外导致步数多加三是边界条件没有先判断起终点不可通行的情况。如果你在笔试时能一次性避开这三个坑代码的完成度就很高了。更进一步如果题目里怪物和玩家的移动速度不同、地形有消耗差异这时候就要把BFS换成Dijkstra或A*题面看着复杂核心依然是“从状态空间中找最优解”。复习时把BFS、DFS、Dijkstra、A*这几个模型的关系理清楚遇到新题才不会慌。3.3 动态规划从题目里找到状态和转移方程而不是背模板动态规划是让很多人头疼的部分但游戏研发笔试里的DP题通常不会太变态一般集中在背包、最长公共子序列、路径计数、状态压缩入门这几个方向。关键在于你能否快速定义状态并验证转移方程是否正确。以“机器人从左上角走到右下角每次只能向右或向下有多少条不同路径”为例很多人知道要用二维DP但有的会写错转移方向int uniquePaths(int m, int n) { vectorvectorint dp(m, vectorint(n, 1)); for (int i 1; i m; i) for (int j 1; j n; j) dp[i][j] dp[i-1][j] dp[i][j-1]; return dp[m-1][n-1]; }这道题的核心思考路径是到达(i,j)只可能来自上方或左方所以状态转移是dp[i][j] dp[i-1][j] dp[i][j-1]初始边界全是1。如果你只是背模板遇到“某些格子有障碍物”“某些格子有额外分值”就会卡住。所以在备考阶段我建议大家每做一道DP题都用纸笔把状态定义、初始条件、转移方程、遍历顺序四件事写清楚而不是在OJ上直接提交了事。3.4 位运算与数学思维题小技巧能省出大时间雷火笔试里通常会有两三道“小而巧”的选择题或编程题考察位运算和数学思维。比如判断一个数是否是2的幂bool isPowerOfTwo(int n) { return n 0 (n (n - 1)) 0; }这类题的底层逻辑是2的幂的二进制表示中有且只有一个1n (n-1)的作用是把最低位的1消掉。我在笔试时见到这类题通常先用几个特殊值验证一下n0、n负数、nINT_MIN再决定要不要补边界判断。这个习惯帮我避免过好几次因为边界条件丢分。4. 容易被忽略的C与计算机基础硬核点答题拿满分的细节算法题是主战场但真正决定你能否进面的往往是那些看起来不显眼的选择题和简答题。这些题分值不高但覆盖面广而且错了就是错了没有调试机会。我把自己见过的高频考点和易错点整理在一起这部分如果能吃透笔试的保底分会稳很多。4.1 虚函数与对象内存布局理解机制而不是背结论C笔试中关于虚函数的题最常见的坑是把“虚函数”和“纯虚函数”“虚继承”“虚析构”混在一起考。我建议你把下面这组问题逐一想清楚而不是只背“析构函数要加virtual”一个类有虚函数时对象内存的头部会多一个虚表指针占用多少字节取决于平台64位下是8字节。多重继承时有多少个虚表指针这决定了内存布局和sizeof的结果。虚继承和虚函数底层用的机制完全不同前者为了解决菱形继承的数据冗余后者为了实现动态多态。构造函数和析构函数中调用虚函数会发生动态绑定吗不会因为构造/析构期间虚表指针可能还未初始化或已改变。这些知识点不是靠刷题能解决的得靠“画内存图”来理解。备考时我建议对每个涉及多态的代码片段都手动画出对象的内存布局标注虚表指针、成员变量、对齐填充分别放在哪里。画过三五张图之后相关选择题基本不会错。4.2 智能指针与对象生命周期工程安全的底线游戏研发的代码里裸指针大量存在但为了防泄漏和野指针智能指针也频繁使用。笔试常考的题型包括shared_ptr的引用计数怎么变化、weak_ptr如何解决循环引用、unique_ptr为什么不能复制只能移动、自定义删除器的应用场景。我记忆很深的一道题是两个对象互相持有shared_ptr会发生什么答案是引用计数永远无法降为0导致内存泄漏。正确的做法是把其中一个换成weak_ptr。这种题在游戏客户端里对应的场景就是场景管理器和角色对象互相引用如果都用shared_ptr管理场景销毁时角色永远释放不了。还有个高频考点是移动语义。很多人知道move是强制转换但不知道它真正的作用是把资源的所有权转移过去避免深拷贝。笔试里可能会给你一个包含vector 成员变量的类问哪个构造函数会被调用、发生了几次堆分配。答这种题要能数清楚临时对象的生命周期。4.3 内存对齐与缓存友好性老生常谈但必须会算内存对齐几乎是必考题因为它直接关系到sizeof运算符的结果。比如struct A { char a; int b; char c; };在32位或64位平台上sizeof(A)是多少很多人凭感觉填9或12实际答案是12。原因是int需要4字节对齐所以a占了1字节后有3字节填充然后b占4字节c占1字节最后整个结构体对齐到4的倍数又补了3字节。如果把成员顺序改成int b; char a; char c;sizeof就变成8。这个例子说明成员声明顺序会影响对象大小也影响缓存命中率。在游戏服务器高吞吐场景下把热字段放在同一缓存行是重要的优化手段笔试考这个是有实际背景的。我备考时练了不少这类题发现一个快速方法先找出最大对齐单位再按顺序计算每个成员偏移量最后整体对齐。多练几道笔试时就是送分题。4.4 网络与操作系统基础锁、进程线程、TCP/UDP的高频考法雷火的笔试里网络和操作系统题目的比例不低但出题风格偏应用。常见题型包括进程和线程的区别线程序度优越性体现在哪。死锁产生的四个必要条件以及如何预防。TCP和UDP在游戏场景下的适用性如何实现可靠UDP。什么是乐观锁悲观锁什么是自旋锁什么场景下用自旋锁。多线程访问共享数据时为什么要用原子操作而不是直接加锁。游戏服务器和客户端的开发中锁和并发无处不在。但这类笔试题目并不会考到很深关键是你能不能用一两句话把事情说清楚而不是堆名词。所以我建议答题时采用“一句话结论 三行展开”的结构既清晰又有深度。4.5 程序改错与代码填空题的常见陷阱除了选择和简答雷火笔试偶尔会有代码改错题或程序填空题。这种题的套路比较固定陷阱集中在悬空指针delete之后没有置nullptr。深浅拷贝类中有指针成员时没有实现拷贝构造函数和赋值运算符。数组越界循环边界错一位。整数溢出int相加后赋值给int没有考虑溢出。循环变量生命周期在循环内定义的对象作用域问题。5. 笔试现场的时间分配与做题顺序最高效的作答策略笔试时间看似充裕但如果你没有规划很容易在某一两道题上耗到天荒地老。我见过太多人算法题卡四十分钟结果后面简答题乱写选择题没时间检查。下面是我验证过的一套时间预算和做题顺序供你参考。5.1 时间预算表假设笔试总时长是120分钟题量大概是选择题20-30道编程题2-3道简答题1-2道。题型建议用时策略选择题20-25分钟先做会做的拿不准的标记后跳过编程题125-30分钟先写框架再补边界不要追求一次完美编程题225-30分钟如果卡在15分钟没思路先写暴力解保底简答题15-20分钟结构化回答分点写不要写长篇大论检查与提交10-15分钟检查编译环境、输入输出格式、边界条件这里的核心原则是分数优先先保稳再看难。不要把时间均匀分配更不要在一道题上赌上全部。5.2 做题顺序的几个实战套路我自己的做题顺序是这样先花5分钟快速把整张卷子扫一遍标记出“一眼会”“有点思路”“完全不会”三档。然后按下面的顺序执行先做选择题里秒答的题快速建立信心顺便确认熟悉的考点没白复习。再写最有把握的编程题保证至少一道完整AC。接着写简答题因为简答题只要写了就有分而且你的系统思维能让面试官眼前一亮。最后攻坚剩下那道编程题。如果只剩15分钟直接上暴力解或部分正确思路哪怕是O(n²)也能拿部分分。完全没思路的题果断放弃把时间留给检查和改错。有人会问为什么不先做编程题再做选择因为如果一上来就写算法题又卡住了很容易崩掉整场心态。先拿下20个会的再挑战算法题心理负担会小很多。5.3 在线笔试环境最容易翻车的几个细节笔试不是“代码写完就完事”在线OJ环境的细节有时候能决定成败。我总结过几个常见坑输入输出格式题目要求多组输入或单组输入格式不同否则样例通过率为0。编译器版本有些平台是C14有些是C17别用C20的特性比如std::format这种。头文件在线OJ推荐使用万能头文件#include bits/stdc.h但要注意部分平台不支持稳妥做法是手动包含需要的头文件。本地IDE vs 在线编辑器本地调试好之后粘贴到线上平台时容易丢行尾空格或缩进提交前再检查一遍。不要在线上平台做大量输入测试平台通常对运行时间有限制如果自己写了个死循环卡到超时会影响心情。这些细节看起来琐碎但每年都有候选人因为“还差一个回车没输出”“题目要求多组输入自己却只处理了一次”而丢分。笔试前建议先花15分钟熟悉平台把示例题跑通。6. 笔试结束后的下一步用复盘把机会变面试通行证笔试交卷不是终点而是所有动作的起点。很多人考完就放飞自我直到收到面试通知才惊慌失措地准备。实际上笔试到面试之间的时间窗口非常宝贵这个阶段如果你能做一次高质量复盘面试表现会有明显提升。6.1 考后48小时内的复盘方法笔试刚结束记忆还新鲜这时候建议立刻做三件事回忆并记录所有拿不准的题按考点分类整理成清单。把每一道编程题的思路在草稿纸上重新写一遍标注出哪一步卡住了、后来自查时是怎么想通的。记录每一道题花费的时间找出时间黑洞。比如你发现自己在“最长回文子串”上耗了20分钟说明这种题型熟练度不够。我个人的经验是笔试后的复盘清单就是面试前最精准的复习提纲。因为笔试和面试的考察范围高度重合你笔试卡住的地方很可能就是面试追问的地方。6.2 把笔试经验转化为面试素材笔试与面试不是割裂的。面试官能看到你的笔试答题记录也可能直接问“你笔试里那题怎么做的当时为什么这么写”这时候如果你能清晰讲出当时的推导过程、遇到的坑、以及后来复盘时想到的优化方案就会给面试官留下极强的正面印象。所以笔试结束后不要只关注“对了几道”要主动围绕游戏研发岗位做一次项目包装。哪怕你还没有一段完整的游戏项目经历也可以写一个小的Demo比如一个基于SDL或Unity的小游戏原型核心系统包括状态机、对象池、简易渲染。一个A*寻路的命令行演示程序包含障碍物随机生成和路径可视化。一个简单的帧同步演示两个客户端各自跑同一套确定性逻辑。这些Demo不需要很炫但面试时能讲清楚设计取舍效果远胜于背一堆八股。我就见过一个候选人笔试成绩中上游但拿着一个自写的回合制战斗框架Demo把状态机、命令模式、对象管理讲得头头是道最后拿下了offer。笔试只是门票真正帮你通关的是你在复盘后的深度理解。6.3 简历和面试沟通中的几个加分动作简历里的技能清单一栏把C放在前面后面括号里写明熟悉STL、智能指针、内存管理、多线程。项目经历里的每一条都写清楚“我做了什么、遇到了什么问题、怎么解决的、收益是什么”不要只写功能列表。面试被问“你做过最有挑战的事情”时优先挑能和游戏研发能力挂钩的经历哪怕是非游戏项目也要从中提炼出与游戏研发相关的底层能力。被问“你的缺点”这类问题时不要只说空话可以讲一个你复盘后正在改进的具体技术细节比如“我之前写代码不注重内存边界笔试时吸取教训后现在每段代码都会主动检查越界和空指针”。这些动作不会让你从“完全不会”变成“面霸”但能让面试官在有限的几十分钟里更快确认你的价值。最后再说一个自己踩过的坑。我当年笔试时在一道图论题上死磕了近四十分钟最后代码没调通后面简答题只能草草写完。那次笔试虽然也进了面试但复盘时发现如果当时先把简答题做掉总分至少能多出一截。后来带人备考时我总会反复强调时间分配其实就是在补自己当年那个坑。笔试真正的筛选逻辑并不只是“谁能写出最难那道题”而是“在同样的限时压力下谁能稳定输出最多的有效分”。这个认知比任何一道题的答案都重要。