游戏研发笔试备考：从C++到图形学的考点拆解与策略

1. 笔试前我最纠结的一件事突击算法还是补图形学2020年4月11日晚上7点我在电脑前坐定准备参加一家头部游戏公司的游戏研发暑期实习笔试。两个半小时从19:00到21:30这个时间安排本身就很像游戏行业的工作节奏——傍晚开始深夜结束。当时离笔试还有一周时我最纠结的问题不是“能不能进面试”而是“我应该把最后这几天花在算法题上还是赶紧补图形学”。事后回头看这场考试给我的最大提醒不是某个知识点没掌握而是游戏研发岗的笔试覆盖面远比我以为的要宽。先说结论如果你现在也在准备类似的游戏研发实习笔试算法题很重要但它只是整张试卷的其中一块。游戏研发岗不同于普通后端研发岗笔试考察的东西往往包含C底层机制、数据结构、操作系统、网络、图形学基础、游戏引擎常识甚至还会有一两道需要你站在游戏开发角度去思考的场景题。只刷LeetCode的人可能会在前面做得很快但到了图形学和引擎相关题目时容易发懵。我当时的准备顺序大概是这样前两周集中刷算法题主要围绕动态规划、DFS/BFS、字典和优先队列第三周开始看C语言特性虚函数、智能指针、内存对齐这些最后三天仓促翻图形学笔记结果就是图形学部分准备得最匆忙考试时也确实在这里丢了一些不该丢的分。如果你问我哪一块性价比最高我的排序是C基础大于数据结构与算法、大于图形学常识、大于网络与多线程但这里说的“大于”只是分值权重的粗略感受不代表你可以放弃其中任何一块。笔试前还有一个容易被忽略的点你需要提前把在线笔试环境跑通。我记得当时笔试平台要求使用指定浏览器并开启摄像头监控还需要提前完成设备检测。这些看起来是流程性的事但确实每年都会有人因为浏览器兼容问题浪费开考后的前十分钟。我建议提前一天做一个模拟测试把摄像头、麦克风、网络、浏览器权限全部确认一遍最好再准备一条有线网络作为备用。考试过程中如果突然断网先别慌很多平台有断网保护机制但你需要尽快恢复连接并主动留意倒计时。2. 两个半小时里我按什么顺序答题拿到试卷后我第一反应是先把整张卷子从头到尾扫了一遍。这种做法在普通笔试里也适用但在游戏研发笔试里尤其重要因为它的题型层次很多不同题型之间的难度曲线并不均匀。有的选择题可能很难后面反而会跟着一道比较常规的编程题如果你按顺序死磕很可能在一道两分的题上耗掉十五分钟等做到编程题时只剩下很少的时间。我当时观察到的试卷结构大体可以分成四类单选或不定项选择、基础理论填空或简答、一两道开放性的场景设计题、以及最后的大题编程。选择题覆盖的科目最杂C、数据结构、操作系统、网络、图形学都可能出现而且有些题的选项本身就是在考察你懂不懂游戏引擎中某个具体概念的实现。简答题里我印象比较深的是需要结合游戏场景描述一种同步方案或者资源加载方案这种题没有标准答案但需要你表现出“我真的做过游戏开发”的细节感。答题顺序上我的做法是先花八到十分钟把所有题目快速浏览一遍把编程题全部读完在心里对每道题的复杂度做一个粗略判断。然后我做的是编程题而不是从前往后做选择题。这样安排的原因很简单编程题分值高而且读题、思考、写代码本身就需要较长时间放到最后做容易因为心态浮躁而影响发挥。把编程大题先解决掉后面的选择题和简答题即使时间紧一些也不会造成灾难性后果。当然这样做也有代价。先把编程题做完后时间往往已经过去了四五十分钟留给选择题的时间会被压缩。游戏研发笔试题量通常不小有些选择涉及复杂的计算比如求某个空间变换的矩阵结果或者统计某段代码的输出这类题如果不留够时间很容易因为赶进度而看漏条件。我最后的实际节奏是编程题约七十分钟选择题和简答题约五十分钟开放题约十五分钟最后留五分钟左右检查。整体比较紧张但好在没有出现大面积空题。这里有一个我很想强调的经验如果你发现自己在一道选择题上卡了超过三分钟先标记并跳过。在线笔试没有“回头率”这个指标但你宝贵的时间不能陷在一个选项里。尤其是图形学相关的计算题有时候你觉得自己快算出来了实际上可能已经陷入一个完全错误的推导思路。跳过之后等整份卷子剩下的部分都填完了再回头冷静分析反而更有可能找到之前忽略的条件。3. 考点太多我把它们切成四块来看游戏研发笔试的考点看着零散其实可以切分成几块来理解。我当时复习时没有头绪只能对着知识点清单逐个确认后来才发现按照“语言与底层、算法与数据结构、图形与数学、系统与网络”这四个维度去归类复习起来会清晰很多。下面逐个说顺便把每个模块里真正容易被问到的细节也列出来。3.1 C与内存分值最密集的一类C在游戏研发笔试里基本是默认的主角。这里说的不是“你会不会写for循环”而是你对语言底层的理解到底有多深。常见的考点包括虚函数表与动态绑定构造和析构顺序拷贝控制与移动语义智能指针的引用计数机制内存对齐栈内存与堆内存的区别以及const和static在不同场景下的含义。这些知识点很多看起来学过但如果没在项目里真正踩过坑选择题一变形就容易出错。我印象里有一类反复出现的考察方向是“某个STL容器操作会不会导致迭代器失效”。vector在扩容后迭代器是否失效map删除节点后其他元素的迭代器会怎样unordered_map重哈希时候的行为是什么。这些问题在游戏开发里很现实因为你在处理对象列表、技能列表、Buff列表时经常需要边遍历边删除。如果你写过类似逻辑应该知道常见的处理方式是先标记再统一清理或者使用反向迭代器删除。笔试题一般不会问得这么开放而是给出一段代码让你判断它运行时会不会崩这种题对细节把控的要求很高。移动语义和右值引用也是高频点。游戏里大量对象会被频繁创建和销毁比如发射子弹、生成特效、播放音效如果每次都发生深拷贝内存和CPU的压力会很大。笔试不会直接问你“移动语义能给游戏带来什么优化”但会通过具体的代码片段考察你是否清楚std::move到底做了什么以及移动之后的对象处于什么状态。我的建议是不要只背定义最好自己写一个简单的字符串类或动态数组类手动实现拷贝构造、移动构造、赋值运算符这样应对选择题时心里会踏实很多。3.2 数据结构和算法考的不只是套路算法部分游戏研发笔试很少出那种纯模板题。更多时候是给一个游戏化的背景比如“某种怪物在固定路径上巡逻玩家需要在某个时间内到达某个点求最短路径”或者“背包里有若干物品每种物品有重量和冷却时间求某种条件下的最大收益”。题目内核还是经典的算法模型但表面披了一层游戏逻辑。从题型来看深度优先搜索和广度优先搜索几乎必考因为它们直接对应游戏里的寻路、连通区域判断、状态搜索等场景。动态规划也是重点尤其是背包问题和区间DP。优先队列、字典、并查集这些数据结构也经常出现它们对应的是游戏里的排行榜、怪物分组、阵营关系等需求。二分法不会直接作为一道大题考但经常作为优化手段出现在解法里你需要能看出“这个答案具备单调性可以用二分来逼近”。我的一个实际感受是笔试里的编程题对算法复杂度的要求其实没有竞赛那么高但对你把问题拆成状态的能力要求很高。很多题目的难点不是想不出解法而是你读了三遍还没搞清楚题目的输入输出是什么样的。所以我的建议是平时刷题时养成一个习惯先用一句话描述“输入是什么、输出是什么、中间要维护哪些状态”。如果这道题的输入都还没理清楚先不要急着写代码。3.3 图形学与数学基础不能只背名词图形学在游戏研发笔试里占的比例没有C那么高但它是区分“只刷过题的人”和“真正接触过游戏渲染的人”的重要分水岭。常见的考点包括MVP矩阵变换模型空间、世界空间、观察空间、裁剪空间之间的换算法线向量的变换与模型顶点变换的区别光栅化流程深度缓冲以及简单的光照模型。这些内容如果你的课程里没有专门学过临时应付起来会比较吃力。我的经验是图形学的选择判断其实考得不算深但如果连矩阵乘法的顺序都搞错后面的计算题基本没法做。比如一个顶点要经过模型矩阵、视图矩阵、投影矩阵变换最终映射到屏幕坐标正确的乘法顺序是先让顶点左乘模型矩阵再左乘视图矩阵再左乘投影矩阵也就是projection乘view乘model乘position。这个顺序问题看起来基础却经常被拿出来做文章。还有一个容易出现的考点是法线变换。很多人的第一反应是“法线跟着模型矩阵变换就行”但实际上如果模型矩阵包含非均匀缩放直接用原矩阵变换后的法线方向可能不再垂直于表面。正确的做法是使用模型矩阵的逆转置矩阵来变换法线。这种细节如果只靠背结论过两天就会忘。我建议自己推导一遍你就能理解为什么OpenGL里会有专门的normalMatrix。3.4 操作系统、网络与多线程和你的日常开发强相关操作系统部分考察的内容主要集中在进程与线程、锁、死锁、内存管理、文件I/O和用户态与内核态相关概念。游戏开发里渲染线程、游戏逻辑线程、资源加载线程之间的协作是最常见的多线程场景所以笔试喜欢考察你能否正确使用锁、条件变量和原子操作来同步数据。这里有一个容易被忽略的点简单地把所有共享数据都加锁在很多情况下并不会让程序变得安全反而可能因为锁的粒度太粗导致性能断崖式下跌。选择题里如果出现这类场景一般会在“锁的粒度、死锁顺序、条件变量唤醒”这些关键词里做文章。网络方面TCP与UDP的区别是必考项但游戏开发更关心的是状态同步和帧同步两种同步模式。状态同步适合RPG类游戏逻辑在服务器端运行客户端表现只是状态的投影帧同步适合MOBA或格斗类游戏所有客户端执行同一套逻辑只同步输入指令。笔试里如果给你一个具体的游戏类型让你选择同步方案并说明理由你需要能结合游戏特征来答题而不是只背定义。我当时在操作系统和网络这部分其实复习得比较仓促但后来在工作中发现这块知识对实际开发很有用。比如帧率不稳时排查瓶颈你需要知道CMutex、CPU缓存、内存带宽这些概念网络通信出现卡顿或回放问题时你需要理解UDP的可靠性补偿和延迟隐藏。所以这部分建议不要只为了笔试突击而是当成从业基础来学。3.5 开放题和场景题亮出你的工程判断除了客观题和编程题游戏研发笔试里经常会出现一两条开放性的场景题。比如给你一个正在开发的游戏项目问某个玩法上线后服务器压力过大应该怎么优化或者问某个技能系统如果做成可扩展结构你会怎么设计数据结构和代码框架。这种题没有标准答案面试官想看到的是你有没有工程判断力而不是背了多少知识点。我在作答这类题目时比较推荐的方式是先明确边界再给方案。举个例子如果问题是“某个职业技能冷却系统怎么做”你需要先说明这个技能可能涉及哪些维度冷却时间、技能等级、道具减少冷却、Buff影响冷却、是否受攻速或急速属性影响、是主角技能还是怪物技能。边界清楚了再给类设计和数据结构就顺手很多。哪怕最后时间不够把边界条件列出来也比你只回答“用两个字典存技能ID和剩余CD”要完整得多。4. 编程题我不是写得漂亮而是先写出可跑的框架游戏研发笔试的最后一般会有两到三道编程大题分值占比很高。我当时的策略是先保证框架完整再追求最优解法。这听起来像正确的废话但实际操作中很容易跑偏看到一道有思路的题总想一步到位写出最精简的版本结果写着写着自己绕进去了最后连能通过的代码都没交上去。4.1 模拟类题目把流程拆细再动手第一道编程题通常会更偏向于状态模拟可能涉及多个角色或物体的行为切换。这种题的特点是读题过程长、边界条件多但只要把逻辑按时间线梳理清楚代码本身并不难。我当时犯了一个很典型的错误题目里有一段“单位时间内的行动顺序”描述我读完没细想就直接用一个for循环去模拟结果到了某些角色死亡后会额外触发技能更新时逻辑就乱了。正确的做法是先画一个时间片流程图把每一帧内事件发生的先后顺序列出来然后对着这个顺序写代码。如果题目涉及对象数量比较大还要注意不要在循环里反复查找某些键值提前把需要用到的数据用字典或数组存好。模拟题的另一个常见坑是大数运算尤其是涉及生命值百分比、伤害系数时最好统一换算成不丢精度的整数或分数避免浮点误差影响最终判断。4.2 搜索类题目优先想状态怎么定义另一道比较常见的编程题会考察搜索比如“玩家从起点到终点途中需要收集多个点位求收集完所有点位并到达终点的最短时间”这种。这类题的难点通常不在搜索算法本身而在于状态有可能变成“当前所在点位已收集点位的集合”如果你只用二维坐标去定义状态是没办法正确处理重复访问问题的。你需要用状态压缩的方式把已经收集的点位集合编码成二进制位再用优先队列去做带权值的扩展。我在这类题上的经验是先把状态定义和扩展方向写在草稿纸上确认不遗漏条件后再开写。扩展时不要贪图代码简洁而省略必要的剪枝一个可行的剪枝方案是维护一个visited数组记录某个状态是否已经被更优路径访问过。如果状态空间很大还可以考虑用双向BFS或者A*但在笔试环境下先把普通的优先队列搜索写对比纠结更高级的优化更实际。4.3 数值推导类题目多写几个测试样例有时也会出现需要推导规律或做数学计算的题目。这类题看上去像是智力题但通常都有更底层的算法模型。遇到这种题时我的习惯是先在纸上枚举几个小规模数据尝试找出模式再和已知的经典模型对应。比如某些看似奇特的计数问题本质是排列组合或动态规划某些贪心问题本质是先排序再维护堆。千万不要一上来就想着用数学公式直接求解除非你能在纸上完整推导。笔试环境下枚举加递推往往更稳。写完之后至少手动构造三个测试样例跑一遍第一个是最小输入第二个是题目给的示例第三个是你自己模拟的边界数据比如最大值、空集合、全部无法到达的情况。编程题的判题通常是隐藏用例制自己多造数据验证是在交卷前最有效的止损手段。4.4 编程语言和环境选择熟悉比花哨重要不少在线笔试平台支持多种语言提交我见过有人在C和Java之间来回切换最后两门都写得不太顺手。我的建议是笔试时只用一门你最熟悉的语言。对你来说C在游戏研发岗里是加分项但如果你平时写C很少不要为了迎合岗位描述强行使用。我当时选择C是因为我对STL、内存管理、标准输入输出的细节更熟一旦需要调试运行时错误能更快定位问题。还有一点很容易被新手忽略本地编译环境往往和线上判题环境有差异。比如有些在线平台的编译器版本比较旧不支持某些新特性有些平台的输入输出格式对空白字符比较敏感。我的习惯是尽量使用最基础的语法和标准库函数不依赖特定平台的扩展能力这样能减少很多不必要的编译失败。5. 从这场笔试里我总结出几个真正的教训考试结束后我没有急着对答案而是花了一晚上把整个过程复盘了一遍。现在回头看有几个教训虽然常听人说但只有真正在考场上经历后才会有切身体会。5.1 基础概念要形成“本能反应”而不是靠临时回忆选择题里有很多考点看起来不深却要求你在几十秒内做出判断。比如“某个类的析构函数为什么需要是虚函数”“shared_ptr会不会造成循环引用”“不同容器在中间插入元素的时间复杂度是多少”这些问题如果还需要从底层原理慢慢推导速度就会明显跟不上。游戏研发笔试虽然不追求极端快的手速但两个半小时覆盖这么多科目慢就是输。我后续的做法是把高频概念整理成一张速查表每天睡前快速过一遍。不是背文字而是用自己的话解释。如果你能对着一张没有答案的知识清单把每个点讲清楚就说明这个知识已经内化了而不是仅仅“见过”。5.2 做题习惯比做题数量更重要刷题刷得多不代表考试一定考得好。我发现一个很有意思的现象平时在编辑器里做题即使答案错了也不太有感觉因为可以反复调试但在线上笔试平台代码提交后只能等判题结果而且往往看不到失败的细节。你会突然意识到平时依赖调试器帮你发现边界条件到了考场上全靠自己。我后来有意识地调整了刷题方式尽量在类似笔试的页面里做题一次性写完再提交而不是每写几行就本地运行一次。对读题、写代码、造样例、自查答案这一整套流程做限时训练比单纯追求刷题数量要有用得多。如果平时能养成“写代码前先想清输入输出边界”的习惯考场上紧张时也不会乱。5.3 游戏研发的知识面需要长期经营突击急救容易顾此失彼这次笔试让我最难受的一点是很多非算法知识点并不是完全不会而是记忆已经模糊了。网络同步方案、渲染管线、内存对齐、引擎生命周期这些内容平时看懂了但没有真正在项目里用过几周后就会变得半生不熟。短期突击最多帮你把知识从“完全不会”拉到“有点印象”但没办法把“有点印象”变成“熟练应用”。我在之后很长一段时间里养成了一个新的自学习惯每学一个概念都试着问自己“这个知识在游戏开发里对应哪个具体场景”。比如学了哈希表就想想对象查找和管理学了渲染管线就想想一个模型从CPU到屏幕的过程中走了哪几步。这样把知识点挂在具体场景下记忆的持久度会明显好很多。6. 如果现在让我重新备考我会这么安排时间复盘完已经过去很久了但如果有人让我针对游戏研发暑期实习笔试重新规划备考我会分四个阶段来做。这套思路不仅对笔试有用对后面的面试和个人项目积累同样有帮助。第一阶段是先搭知识框架。找一份比较全面的岗位知识清单把C、数据结构和算法、图形学、网络、操作系统、引擎使用等模块过一遍对每个模块需要掌握到什么程度做到心里有数。这个阶段不要陷进某一个项目里钻研太深目标是建立全局地图。第二阶段是集中刷高频算法题。不用追求偏题怪题就盯住图搜索、动态规划、数据结构设计、模拟题这些高频类型。刷题之外的晚上我会把C语言特性再过一遍尤其是那些容易被选择题拿来出题的点移动语义、智能指针、迭代器失效、内存布局、类型转换。第三阶段是模拟真实笔试环境。找一套在线模拟题计时两个半小时全程开启摄像头不许中途查资料一次性完成。这个阶段就是训练自己做题节奏和抗压能力积累“先做编程题还是先做选择题”的经验。模拟过后把错题对应的知识点单独整理出来第二天集中攻克。第四阶段是考前两天的轻量保持。不再做新题了只看错题笔记和知识速查表再把笔试平台的环境测试做一遍。同时准备好身份证件、草稿纸、充电器和网络备用方案确保开考时心情是平和的。如果时间更充裕我会提前在游戏引擎里实现一个小Demo哪怕只是一个简单的2D小游戏把角色移动、碰撞检测、技能冷却、敌人AI、简单对象池和UI界面都串一遍。这样不仅笔试里的场景题能答得更有底气简历上的项目经验也算有了可聊的实质内容。笔试只是第一关真正进入面试环节后你做过的东西才是最扎实的底气。