毕业季那阵子我在宿舍楼下公告栏看到4399游戏的校招宣传海报第一反应是“做小游戏的公司笔试应该不难吧”。等真拿到游戏开发类笔试题翻到第三页我就收起了这个念头——这份卷子考得相当扎实算法、C底层、游戏数学、甚至图形学基础一应俱全没有一块是能蒙混过关的。后来我和几个一起投递的同学对过答案发现拿高分的人都有一个共同特点他们不是刷题刷得多而是真正理解游戏引擎里每个模块为什么需要这些数学和算法知识。这篇文章我就把自己对这份笔试题的理解和复盘整理出来从考察逻辑到高频考点再到答题策略给准备游戏开发方向校招的同学一个参考。1. 笔试范围的底层逻辑游戏公司到底想招什么样的人1.1 题型分布背后的岗位分工2015年前后的页游和手游公司对游戏开发者的要求已经从“会写逻辑”变成了“撑得起完整项目”。4399这类平台型公司笔试题目通常覆盖选择题、简答题、编程题几大块。选择题大量考察C语法细节、数据结构和计算机网络基础简答题则偏向游戏数学和设计思路最后的编程题基本都是限时手写算法。这类结构对应了游戏开发岗位的实际分工一部分人做客户端逻辑需要扎实的语言功底和算法能力一部分人接触渲染和引擎层需要图形学和线性代数基础。所以如果你只盯着编程题刷简答题里那些向量叉积、四元数的题目就容易翻车反之如果你只准备游戏数学前面语法题又可能丢分。整场考试筛选的其实是一个均衡型选手。1.2 为什么游戏公司偏爱考察底层知识不做游戏的人可能觉得奇怪招一个游戏开发为什么要考链表反转和内存对齐直接问“你做过什么游戏”不就行了吗但做过完整项目的人都明白游戏是实时性要求极高的程序一个卡顿、一次内存泄漏、一个越界访问在编辑器里可能只是报个错在线上就是闪退和差评。笔试考底层知识就是在筛选那些能写出稳定高效代码的人。再往深一层看游戏引擎本身就是一个巨大的数据结构集合体场景管理用树、渲染排序用数组和堆、网络同步用环形缓冲区、资源缓存用哈希表。如果不懂这些数据结构的时间复杂度和内存布局写出来的功能模块别说优化连正确性都难保证。所以笔试中出现大量STL底层原理和数据结构变形题本质上是在模拟真实项目中“被限制条件逼着选数据结构”的场景。1.3 两套截然不同的出题思路同一个“游戏开发类笔试”的标签下其实经常藏着两套风格差异很大的卷子。一套偏客户端游戏逻辑重点在C、数据结构和简单算法偶尔出现Actor、组件这类概念题另一套偏引擎和图形方向会加入矩阵变换、渲染管线、空间分割树的题目。从2015年那会儿的校招情况看4399的卷子更接近前者为主、带少量后者延伸题的状态。这里给后来人一个建议投递前先想清楚自己应聘的是哪个细分方向再去定复习侧重点。如果你的目标岗位是客户端逻辑开发那数学和图形学题目掌握基础即可不必深挖着色器写法但如果你投的是引擎开发那矩阵、四元数、视锥裁剪这类题目就是必考题不能只背结论得能推过程。方向认不准复习火力就会分散。2. 算法与数据结构笔试卷上的主力题型拆解2.1 遍历与递归从树的层次打印说起算法题里最常出现的类型是树的遍历变形题比如“按层输出二叉树”“之字形遍历”“求二叉树最近公共祖先”。这类题目看起来基础但特别能区分考生是真懂递归还是只会背模板。以按层打印为例标准做法是用队列做广度优先遍历关键点在于如何区分每一层的边界。很多人会直接套BFS模板结果输出结果全混在一行里。我当时写的解法是用一个计数器记录当前层剩余节点数每轮循环结束前把下一层节点数累加循环完一层后换行。核心代码如下void levelOrder(TreeNode* root) { if (!root) return; queueTreeNode* q; q.push(root); while (!q.empty()) { int levelSize q.size(); for (int i 0; i levelSize; i) { TreeNode* node q.front(); q.pop(); cout node-val ; if (node-left) q.push(node-left); if (node-right) q.push(node-right); } cout endl; } }为什么强调这个“层边界”细节因为在实际游戏开发中这种“分批处理一批数据”的场景到处都是比如UI界面的分级加载、技能特效的分帧播放、批量合批渲染。面试官其实不指望你能在十分钟里写出多惊艳的代码他看的是你有没有清晰的思路和把边界条件处理干净的习惯。2.2 经典动态规划小题台阶问题背后的状态设计简答题和编程题里动态规划一般不会出太难通常就是爬楼梯、最大子数组和、背包问题的裸题或简单变形。但有一个点很容易被忽视状态转移方程的起点定义。比如“每次可以走1步或2步走到第n阶有多少种走法”这种题大多数人能迅速写出dp[i] dp[i-1] dp[i-2]但问到“dp[0]为什么等于1”时不少人的回答就开始含糊了。这个细节重要在哪呢它反映的是一个人能否从物理意义上解释状态定义而不只是套模板。游戏开发里几乎所有数值系统都离不开状态设计角色的受击硬直、技能冷却、连击判定本质都是状态转移。如果连最基础的状态定义都讲不清后面写战斗系统时很容易出现“穿透一个怪掉两次血”“击退距离不一致”这类逻辑漏洞那才是真正的灾难。2.3 链表操作的几个陷阱链表题在笔试里出现的频率极高反转链表、判断是否有环、找中间节点是三大常客。这些题本身不难但有几个隐藏考点是否允许修改原链表、边界条件有没有处理空指针、递归写法会不会因为栈溢出挂掉。当年就有同学在“判断链表是否有环”这题上纠结于双指针步长其实快慢指针的核心就是步长差为1一旦相遇就说明有环。我在准备这类题时习惯总结一个“四步检查法”先考虑空链表、再考虑单节点、再考虑头尾循环、最后才看中间逻辑。代码写得对不对靠的不是背得熟不熟而是这几个边界点是否都有意识地处理了。笔试现场时间有限很难大段调试所以提前形成这种肌肉记忆非常管用。3. 游戏数学与图形学那些拉分题背后的原理解析3.1 向量运算不只是公式是开发时的直觉简答题里出现“向量点乘和叉乘的区别及应用场景”几乎是必然的因为它是游戏数学的地基。点乘结果是一个标量通常用来求投影长度和判断方向比如判断敌人是否在玩家的正面视野内只需把玩家的前向向量和指向敌人的向量做点乘结果是正的就在前方负的就在背后。叉乘结果是一个垂直于两个输入向量的新向量多用于求法线、判断左右转向。当时我把这两者的区别整理成了一张对照表笔试前反复看运算结果类型几何意义典型游戏应用点乘标量投影长度、方向一致性视野判定、光照衰减叉乘向量法线方向、面朝向地形法线计算、转向方向很多同学能把公式默写出来但一旦结合“摄像机绕Y轴旋转”这类具体场景就不知道用什么运算了这就是缺少“直觉”的表现。建议复习时不要只背公式拿Unity或Cocos的场景编辑器里实际转几圈看数值变化比刷十道题都管用。3.2 矩阵变换为什么按矩阵乘法顺序理解物体运动涉及图形学简答题的卷子里“用矩阵表示平移、旋转、缩放并解释组合顺序”是高频题。这个地方最容易出错的是矩阵乘法的顺序是先旋转再平移还是先平移再旋转。刚接触的人总会把这两个搞混写出来的变换矩阵结果完全不对——角色明明应该绕自身旋转后移动到指定位置实际却绕着世界坐标原点转圈。我的记忆技巧是对于一个带局部坐标系的物体如果想让它的局部旋转和位移都正确一般是先做缩放再旋转最后平移也就是说 P T * R * S * P。原因在于旋转和缩放都是围绕原点做的如果先平移会破坏物体的局部原点位置但如果你希望物体绕世界某个点旋转那就要先把物体平移到那个点旋转后再平移回去。这两种情况的矩阵顺序恰好相反把这两种场景记清楚就不会再错了。3.3 碰撞检测从包围盒到空间分区的思路演变笔试里经常有一道场景设计题比如“场景中有上千个物体如何高效检测它们之间的碰撞”。多数人第一反应是两两检测但很快发现复杂度是O(n²)几千个物体的场景根本跑不动。合理的思路分两步先通过粗略的碰撞检测剔除不可能相交的物体对再对剩余少数候选对做精确检测。粗略检测常用包围盒或包围球。AABBAxis-Aligned Bounding Box因为计算简单是最常用的粗略检测手段。更进一步的优化是空间分区把场景划分成均匀网格或者用四叉树/八叉树递归划分让物体只和自己所在格子及其相邻格子里的物体做精确检测。这部分虽然没有要求你手写完整代码但能画出示意图并说明复杂度变化就已经能拿到大部分分数。3.4 寻路算法考察比A*更重要的是场景适配游戏开发笔试里寻路相关问题也扎堆出现一旦涉及“如何让怪物绕过障碍追玩家”几乎没人不会提A*。但真正拉开差距的是能不能说清楚A和Dijkstra的适用区别以及为什么游戏里普遍用A。Dijkstra只考虑起点到当前点的实际代价而A*加入了启发式函数估算当前点到终点的代价因此在单终点场景下搜索效率明显更高。我当年为了写清楚A*专门把open list和close list的存取逻辑画成了流程草图然后模拟走了一遍八方向的格子地图。笔试中确实出现了类似的题目“给定一个5x5地图起点左上、终点右下存在障碍简述A*的搜索过程。”考前捋过一遍逻辑这道题写起来就非常顺畅。这里提醒一句别只背伪代码要能对着小地图自己手推几步不然面试官一追问“open list里F值相同时选哪一个”就会露怯。4. C与底层系统考察功底扎实度的关键板块4.1 指针与内存那道必考的“C内存分区”C相关的选择题里“堆、栈、全局区、常量区的区别”几乎年年出现。它考的不是你能不能说出几个名词而是结合具体代码判断变量存储在哪。比如函数内的局部变量存在栈上new出来的对象存在堆上字符串字面量存在常量区静态变量和全局变量存在全局区。这个知识点之所以高频是因为游戏开发中最难排查的bug里很大一部分就是内存管理不当引起的。我在准备这部分时给自己列了一个排查清单栈内存自动管理但空间有限递归过深会导致栈溢出堆内存手动管理但灵活忘记释放会导致泄漏常量区数据只读尝试修改会直接崩溃。笔试里如果出现“请指出这段代码的内存问题”基本就是围绕这些点展开。答这种题要特别小心“悬空指针”和“内存泄漏”同时出现的代码通常陷阱都不止一个。4.2 多线程与并发游戏主循环之外的隐形考点页游和手游的服务端开发绕不开多线程所以笔试偶尔也会涉及线程同步的题目比如“多个线程同时对一个变量自增最终结果是否等于期望值”。这类题想考察的是一个核心概念原子性。即使你用i这样一行代码在CPU层面也包含了读取、修改、回写三步操作多线程环境下这三个步骤可能被其他线程插队。更贴近游戏开发的问法是“客户端的主线程和渲染线程如何安全地交换数据”答案通常指向生产者-消费者模型用带锁的队列或消息系统来解耦。这种题没有标准答案考察的是你在这个领域有没有实际思考过。如果你能主动提到“锁粒度不要太粗、避免在渲染线程里等待IO”这类实践经验面试官会明显对你高看一眼。4.3 STL的底层机制与选择逻辑选择题中还有一类是STL容器底层实现对比比如vector、list、map、unordered_map各自的底层结构、增删查时间复杂度、迭代器失效条件。这不仅是语法背诵题背后是实际开发中选型的能力。游戏场景里一个频繁遍历、偶尔删除的容器和一个频繁插入、偶尔查找的容器选错的差距是数量级的。我自己复习时做过一个表格对比笔试前反复看答这类题几乎不用思考vector连续内存存储随机访问O(1)中间插入删除O(n)适合读多写少。list双向链表任意位置插入删除O(1)但随机访问O(n)适合写多读少且不要求随机访问的场景。map红黑树有序插入删除查找都是O(log n)适合需要有序遍历的场景。unordered_map哈希表平均O(1)查找极快但不保证有序适合键值对缓存。游戏里一个典型的选型例子是管理场景中的NPC列表大部分时间是遍历更新偶尔有NPC加入或离开用vector就够了但如果要频繁按ID查找某个NPC那就应该用unordered_map。笔试里遇到“请选择合适容器”这类题关键不是背容器功能而是把场景的时间复杂度分析说出来。4.4 内存对齐与缓存友好被忽略的加分题有些卷子会出“结构体sizeof是多少”的题目比如下面这个结构体struct PlayerInfo { char name[8]; int level; short hp; bool isAlive; };在不同的对齐规则下sizeof结果不一样。32位和64位系统下默认对齐方式不同如果没考虑内存对齐就会算错。这个知识点在游戏开发中很实用因为服务器和客户端通信时结构体序列化必须严格一致否则就会出现收包解包异常。更进阶的考点是“缓存行填充”。多线程场景下多个线程频繁访问同一缓存行中的不同变量可能引发伪共享导致性能骤降。笔试不一定会考得这么深但如果你能在简答题里主动提一句“尽量把同步频繁的变量拆分到不同缓存行”这会让考官觉得你是真写过性能优化代码的。这部分内容我给准备笔试的朋友一个建议别只看书自己写几个结构体在VS里用 sizeof 打印出来亲自验证对齐规则比死记硬背强得多。5. 交卷前的答题策略复盘这些失误最亏5.1 时间分配是最大的隐形坑游戏开发笔试题量通常在60到90分钟内要在有限时间内完成数量不少的选择题、简答题和编程题。最亏的失误是把时间耗在一道选择题的某个选项上结果后面两道简答题没时间写。我当时的策略是选择题控制在15到20分钟内不会的先圈出来跳过简答题每道控制在10分钟编程题预留至少25分钟。这个策略的底气来自对分数结构的预判。选择题每题分值有限纠结5分钟换来一分并不值简答题按点给分多写一个关键步骤就能拿分投入产出比最高编程题通常占大头哪怕写不完完整代码也要把思路、伪代码和关键边界条件写上去阅卷人往往会给步骤分。笔试本质上是一场“用最少的时间拿最多分数”的博弈不是证明自己全都会的舞台。5.2 编程题别一上来就追求最优解手写算法代码最常见的失误是太想一步到位写最优解结果写到一半发现某个边界条件处理不了时间也耗得差不多了。我的习惯是“先写能通过的版本再在注释里简述优化方向”。比如遇到“求两个有序数组的中位数”先把归并的思路写出来虽然时间复杂度是O(nm)但胜在稳妥写完后再补一句“继续优化可以用二分时间复杂度O(log(min(n,m)))”表达出我知道更优方案。面试官其实更看重一个候选人在限定时间内的工程落地能力。能写出逻辑正确、边界条件完整的版本哪怕不是最优解评分也不会低。最怕的是一个人卡在思路优化上最后交上去一段半截代码这样的处境是最可惜的。5.3 简答题的答题技巧图解公式场景三重保证简答题里凡是能画图的尽量不要只写文字。比如“如何用一个栈实现队列”文字描述能让人看懂但画出入栈和出栈两张示意图再配一个时间复杂度分析阅卷体验完全不一样。笔试阅卷时间紧张图文并茂的答案更容易尽快抓住采分点。另外简答题里如果遇到了“请说明实现思路”这类开放性问题回答时尽量带上“场景 做法 理由”三段式结构。举个例子问“大量怪物同屏如何优化”我不建议直接回答“使用对象池”更好的表达是“在MMORPG地图中同屏可能出现几百个怪物场景我会把怪物实例放进对象池复用避免频繁创建销毁带来的GC压力做法因为C#/Java这类语言的GC触发会造成帧率抖动影响战斗体验理由。”这种答题方式不仅适用于笔试题也是日后技术方案评审的基本沟通方式。5.4 检查一遍代码里的“变量声明”和“边界判断”编程题写完之后如果还有剩余时间我最常做的检查是“读一遍自己刚写的代码”。这一步看似简单却能救回不少分。重点看三处循环里的边界条件是不是能正常退出、用到的变量是否都进行了初始化、递归函数有没有终止条件。很多考生不是不会写而是写完没检查漏掉一个写成就直接影响了通过率。我自己就栽过一回一道二分查找的变形题我在循环条件里写了while (left right)实际应该写成导致查找单个元素场景下根本进不去循环。这种错误靠写代码之前先在草稿纸上跑两组简单测试样例就能规避掉大部分。笔试时间分配再紧张也值得花两分钟做这种低成本的验证比你多啃一道难题的边角要划算得多。6. 考后复盘从一份笔试题看校招准备的长期策略6.1 知识体系比题目本身更重要等笔试结束后我对着一叠草稿纸反思了很久。那些能答上来的题基本都源于我之前在游戏项目中用过的知识比如技能冷却系统的状态机、战斗场景的伤害数值计算、UI列表的懒加载这些平时觉得“只是在写功能”的经历其实已经悄悄覆盖了笔试里的很多考点。而那些我答得磕磕绊绊的题比如矩阵变换的组合顺序、STL容器底层差异恰好都是平时没有主动深挖过的方向。所以准备校招笔试最有效的方法不是临考前疯狂刷题而是拉长到整个项目开发周期里养成“每用到一个技术点就追问一遍原理”的习惯。用排序算法时想一想底层是快排还是插入排序时机合不合适用数据结构时想一想时间复杂度和内存开销值不值得换别的容器。这种积累方式可能慢但每一分积累都是踏实的。6.2 一份笔试题对后续面试的指向作用笔试和面试往往是连在一起的笔试中暴露的薄弱点大概率会成为后续面试提问的靶点。我自己就有过这样的经历笔试里STL容器对比那道题答得模糊到了技术面面试官第一个问题就是“你们项目里的怪物列表用的什么容器为什么不用map”。如果不是提前把笔试那张卷子复盘了一遍我大概率会被问得支支吾吾。因此我强烈建议考完试后趁热打铁做一次全面复盘把每一道没把握的题查清楚自己动手写一遍代码或推导一遍公式。花上两三个小时效果比闷头刷三套新题都好。很多校招同学把笔试当成了终点实际上它只是面试的准备材料。6.3 一个额外提醒保持手写代码的感觉最后说一个很容易被忽略的点笔试是手写代码不是IDE里写代码。平时习惯了自动补全和编译器报错提示的人在纸上写代码时会出现各种奇怪问题——函数名拼错、括号没配对、头文件忘记写、类型写错。这些错误在IDE里早就被提示了但笔试现场只能靠自己的眼睛一行行找。针对这个情况我备考阶段的练习方式是每周挑两三道算法题不用电脑只拿纸笔手写完整代码然后对着编译器输入一遍看哪里有错。连续练几周手写代码的准确率会有非常明显的提升。这个细节很少被提及但对于实际应试来说它可能是性价比最高的练习方式之一。站在现在回看2015年的这份试题它算不上难但足够真实地反映了游戏开发岗位对基础能力的硬性要求。那些年我刷过的题、画过的推导图、踩过的坑在之后做游戏项目的日子里不断被验证算法是客户端性能的地基数学是3D世界的语言而C的底层素养决定了你面对诡异bug时是两眼一抹黑还是能够准确定位。如果你也在备战游戏方向的校招笔试按上面这几个板块稳扎稳打地准备踏踏实实提升基本功这个方向就对了。