西山居的秋招笔试在游戏开发圈里一直属于“看着不难、写起来容易翻车”的那种。2023年这场笔试我完整走了一遍从收到笔试邮件到交卷前后三天时间全扑在复习和实战上最后虽然没走到 offer 那一步但整个过程中的收获比预期大得多。这篇文章就围绕这场笔试把我踩过的坑、总结的题型规律、以及备考时真正管用的方法完整写出来给后面准备西山居或者其他游戏大厂笔试的朋友一个参考。先说结论西山居的游戏开发岗笔试核心考察的是C功底、算法与数据结构基础、以及基础的图形学/引擎认知。如果你以为笔试只是刷几道 LeetCode 就能过那大概率会在问答题和综合题上吃大亏。1. 笔试整体设计思路与考察目标拆解1.1 西山居笔试到底在筛什么人西山居的笔试和纯互联网大厂的后端开发笔试有本质区别。后端笔试重点在系统设计、高并发、分布式而游戏开发岗笔试的落点始终围绕“你能否在游戏引擎的约束下写出可靠的代码”这件事。也就是说它不只要看你算法写得快不快还要看你有没有游戏开发必备的底层感觉。从题目结构来看西山居的笔试通常分为三个部分客观选择题、编程题、简答/问答题。选择题覆盖 C 语法细节、数据结构复杂度比较、操作系统基础、网络基础编程题一般是 2 到 3 道难度从“基础数据结构操作”到“带约束条件的综合模拟”不等问答题则直接考察你对游戏开发中常见机制的理解比如物理碰撞处理、资源加载、帧率优化、渲染管线基础。这套组合拳的思路很清楚选择题筛基础扎实度编程题筛代码实现能力问答题筛工程意识。很多人只准备了编程题结果在问答题上丢了大分这是最可惜的。1.2 题型结构与时间分配2023 年秋招这批笔试我印象里总时长是 120 分钟题量不算少。选择题大约 20 道编程题 2 到 3 道问答题 2 到 3 道。如果按分值权重估算编程题和问答题占大头选择题更多是“过线”性质。这里有一个非常关键的策略选择题不要恋战。一道题如果看了 30 秒还一点思路都没有直接标记后跳过最后再回来蒙。因为选择题的容错率其实不低你就算错 5 道只要编程题和问答题撑住整体排名依然不会被拉得太低。反过来如果在一道 C 虚函数表的选择题上卡了 10 分钟后面两道编程题基本就废了。我的建议是时间分配如下题目类型建议用时策略选择题35 分钟快速判断不纠结不确定的先标记编程题60 分钟先做最有把握的每题留 20 分钟问答题25 分钟条理清晰每题写 3 到 5 个要点这个时间分配在多次模拟中都很稳。核心逻辑是编程题的关键是“写出来并跑通”问答题的关键是“展现思路深度”选择题只要不拖后腿就行。2. 核心知识点准备C、算法与图形学2.1 C 与内存管理是底线游戏开发岗笔试里C 占据了绝对的统治地位。西山居的王牌产品线大多是 C 引擎或者底层方案所以 C 水平直接决定你能不能过第一轮筛选。选择题里高频出现的点包括虚函数、虚函数表、纯虚函数、析构函数是否声明为 virtual引用和指针的区别、const 的各种组合含义内存分配与释放、堆和栈的区别、内存泄漏的排查思路智能指针的基本原理shared_ptr、unique_ptr、weak_ptr 的适用场景struct 和 class 的区别、内存对齐、sizeof 的计算构造函数、拷贝构造函数、移动构造函数、赋值运算符重载的调用时机。这些点看起来都是“八股文”但西山居的题目往往会结合游戏引擎的实际场景出题。比如给你一段处理游戏对象组件Component的代码让你分析析构顺序是否正确或者给你一段资源加载的伪代码问你存在哪些内存泄漏风险。这种考法不再单纯背概念而是要看你能不能在实际代码里发现隐患。备考时我推荐认真过一遍《Effective C》的前 40 个条款配合《C Primer》的相应章节。不需要面面俱到但内存管理、拷贝控制、RAII 这三大块相关的内容必须吃透。另外笔试前至少手写一次 shared_ptr 的简化实现理解引用计数是怎么运作的这几乎是大厂游戏岗笔试的保留节目。2.2 算法与数据结构能落地比会炫技重要算法部分的难度坦白说没有达到竞赛水平更接近“leetcode 中等题”的上限。但我观察到西山居有一个倾向不考太抽象、太数学化的题反而喜欢考你在游戏业务中一定会用到的数据结构。例如链表、二叉树、哈希表这些是最基本的需要熟练掌握排序算法的复杂度比较和稳定性图论一般只考 BFS/DFS 和最短路动态规划偶尔出现在压轴题里但不会太刁钻。真正需要注意的是“堆”和“优先队列”这两样因为游戏里用于做任务排序、战斗逻辑处理时非常常见。关于算法准备我建议把 LeetCode 的热门 100 题刷熟尤其关注数组、字符串、链表、二叉树、栈、队列这几类题。每天保持 2 到 3 道题的量就够关键在总结不在数量。我第一次刷题的时候只追数量一周刷了 40 道结果笔试遇到变体题照样懵。后来重新调整策略把每道题都归类、写题解、总结套路效果好了很多。还有一个容易忽略的点手写能力。笔试环境往往不支持本地编译调试代码写完后只能靠肉眼检查。所以备考时最好在纯文本编辑器里练手写代码不依赖代码补全和编译报错。这个习惯一开始很痛苦但能逼着你在写每行代码前都先想清楚逻辑。2.3 图形学与引擎基础游戏开发岗的差异化战场如果说 C 和算法是“通用门槛”那图形学基础就是游戏开发岗的差异化得分点。西山居作为一家以美术品质闻名的公司对候选人的图形学基础一定会有要求。选择题和问答题里出现过不少与渲染相关的内容。需要掌握的核心知识点包括渲染管线的完整流程顶点输入、顶点着色器、光栅化、片段着色器、帧缓冲坐标空间变换模型空间、世界空间、观察空间、裁剪空间、屏幕空间以及 MVP 矩阵的推导光照模型Phong 与 Blinn-Phong 的区别、环境光、漫反射、高光反射纹理映射与 UV 概念常见优化手段批次合并、剔除算法、LOD、帧率优化。这个部分如果之前没有系统学过强烈建议花几天时间配合《Unity Shader 入门精要》或《OpenGL 编程指南》快速建立框架。不需要会写复杂 Shader但至少得知道画面上一个三角形是怎么从顶点数据变成最终像素的。我记得笔试时有一道问答题就是让描述“当你在游戏场景中移动相机时画面中的物体如何保持相对位置正确”这就是对 MVP 矩阵和坐标变换理解的考察。如果连模型空间和世界空间都分不清这种题根本无从下笔。另外Unity3D 游戏开发这个方向相关的知识也值得准备一些。西山居也有在用 Unity 的项目组所以候选人对引擎关键组件不陌生的会很加分。至少要清楚 Update 和 FixedUpdate 的区别、MonoBehaviour 的生命周期、Transform 的层级关系、Resources.Load 和 AssetBundle 的基本使用等。这类题目虽然不一定会直接考但在问答题里引用引擎实例会让你的答案更有说服力。3. 编程大题实操过程与实现思路3.1 典型题一对象池设计与实现西山居 2023 年秋招印象最深的编程题之一是让你实现一个简单的对象池Object Pool。题目背景大概是这样游戏战斗场景中需要频繁生成和销毁敌人子弹而频繁 new/delete 会造成性能抖动请设计一个对象池来优化这件事。这类题目在游戏开发笔试里出现频率极高因为对象池是游戏开发中最基础、最实用的内存优化手段之一没有堆过项目的候选人很难写得完整但写过小游戏 Demo 的都知道它的价值。我的实现思路是这样的#include vector #include memory template typename T class ObjectPool { public: // 从池中获取一个对象 std::shared_ptrT acquire() { if (!freeList_.empty()) { auto obj freeList_.back(); freeList_.pop_back(); return obj; } auto obj std::make_sharedT(); return obj; } // 将对象放回池中 void release(std::shared_ptrT obj) { freeList_.push_back(obj); } private: std::vectorstd::shared_ptrT freeList_; };这里的关键不止是把代码写出来还包括回答后续追问比如池容量限制、对象初始化状态重置、多线程安全性、为什么用shared_ptr而不是裸指针等。如果你在代码注释里补充了这些考虑或者你在题意允许范围内提出改进方案那么这道题的得分会明显不一样。我当时在实现时额外写了一个扩容策略当池为空时一次性预分配 10 个对象而不是每次push_back一个。这样能减少多次扩容带来的重新分配开销。虽然笔试没有运行环境但把这个思路写在注释里面试官是能看到的。3.2 典型题二A* 寻路算法简化实现寻路算法是游戏开发岗的高频考题西山居 2023 年的笔试中也有类似题目。题目一般不会让你直接写完整的 A*而是给一个网格地图要求你实现从起点到终点的最短路径搜索可能是 BFS 或带权重的 Dijkstra难度适中的话就是简化版 A*。这种题的答题流程非常固定定义网格节点状态可通行 / 障碍建立 open list 和 close list从起点开始取出当前 open list 中代价最小的节点遍历四个或八个邻居计算代价并更新回溯路径。需要特别注意的问题是优先队列的使用因为 A* 的每次取最小代价节点操作如果都用遍历时间复杂度和数据量上来后会出大问题。建议用std::priority_queue、或者 C 里的std::multimap来维护 open list。另外一个细节是很多人在一开始就把节点对坐标 代价放到容器里但忘记记录每个节点的父节点导致最后回溯路径时空手而归。这个错误我在模拟练习时踩过多次笔试现场更是容易因为紧张而忽略。所以备考时一定要手写一遍自己的 A* 模板并且记录从“建图”到“回溯路径”的完整过程。3.3 典型题三设计一个简单的战斗伤害计算函数这种题目看似简单其实考察得非常全面。给你一个伤害公式最终伤害 基础攻击力 × 技能倍率 - 目标防御力 × 减伤系数再附加暴击判定。你要写一个函数来计算最终伤害同时考虑随机数种子、属性加成、浮动区间等。这个小题目能考察的点非常多浮点数比较是否使用了 epsilon随机数生成是否使用均匀分布是否把“暴击”和“属性克制”两件事分开处理是否考虑了伤害下限防止出现 0 伤害或者负伤害。你可以发现编码能力只是一个门槛代码可读性、边界条件考虑、对游戏数值的理解才是真正拉开差距的地方。我建议在实现这类题目时把关键公式提出来做成独立函数方便测试和复用也便于阅卷的人看到你的设计层次。4. 常见问题与排查技巧实录4.1 基础不牢导致的丢分重灾区很多人选择题错得多的原因其实不是因为题目偏而是因为基础概念不扎实。比如 C 中sizeof(空类)的值、虚函数表指针的存在是否会影响sizeof、vector扩容时的迭代器失效问题这些都属于面试与笔试的“老演员”但每次考依然有一批候选人栽跟头。对策很简单睡前十分钟翻一翻 C 的易错点总结不用贪多每天看 5 条就够。另外强烈推荐自己整理一份“避坑清单”把曾经做错的、搞混的知识点记在一个文档里考前只看那份清单。这个做法帮我节省了大量复习时间而且针对性极强。操作系统和网络方面也不能完全不看。虽然游戏开发岗笔试对这块的深度要求不及后端岗但进程与线程的区别、死锁产生的四个条件、TCP 三次握手或 UDP 和 TCP 的适用场景还是需要了解的。因为游戏服务器开发也是很多项目组的重要方向这些问题出现的概率非常高。4.2 答题策略会做的先做不会的写思路我的真实感受是笔试中最影响心态的不是“不会做”而是“明明知道这道题能拿分却没时间写完”。所以答题顺序一定不要按照试卷顺序来而是要先做自己最有把握、最可能拿到满分或高分的题目。具体到西山居这套笔试卷我的顺序是先扫一遍编程题挑最简单的先做然后做问答题最后返回去做选择题和较难的编程题。问答题一定不能空着。哪怕你不会也必须写点东西。比如说题目问“如何优化 Unity 项目的加载耗时”即使你没有实际优化经验也可以从资源压缩、AssetBundle 分包、异步加载、场景拆分等常规思路去回答。阅卷人看重的是你有没有解决问题的能力而不是标准答案。只要是合理且有逻辑的分析都会给分。空着反而是最没有办法补救的。另外教大家一个技巧如果编程题时间不够把关键步骤写成伪代码也比完全空白好。我曾经在模拟笔试里遇到一道复杂的图论题最后只写出了节点定义、邻接表构建和 BFS 框架伪代码但这道题反而拿到了一半以上的分。因为阅卷人能看到你的思路是清晰的代码只是时间不够而已。4.3 时间分配失误与心理调整秋招笔试的场景非常特殊竞争对手在同时答题你还要承受“万一考砸就少一个机会”的压力。这种压力下最典型的问题就是在一道题上陷入“我一定能解出来”的执念结果 30 分钟过去后整个人就慌了。我采用的策略是“15 分钟原则”任何一道题如果连续思考 15 分钟仍然没有清晰的解题路径立刻放下先去做其他题。等做完一轮再带着更大的信息量回来重新审题。很多时候做后面题时获得的灵感会反过来帮助你解前面的题目。心态上的另一个有效建议是把笔试当成一次技术交流而不是生死之战。考场上真正的高手往往不是那些写题又快又猛的人而是能稳定发挥、不慌不忙的人。这种状态需要平时多模拟练习来培养我在笔试前做了三次完整的限时模拟每次都严格按照真实时长来刷题。4.4 在线笔试环境的坑西山居的笔试是通过在线平台进行的这类平台有一个共同问题代码补全和格式化支持很不稳定。我在一次模拟中吃过亏原本在本地能正常编译的代码粘贴到平台后因为缩进和自动补全的干扰逻辑出现混乱。所以考前一定要提前熟悉平台的基础操作例如代码框是否有自动缩进、是否支持 CtrlZ 撤销、编译输出在哪里看等。另外要注意的是代码的输入输出格式。在线笔试通常要求从标准输入读取数据而不是像本地那样用ifstream读文件。很多人在 LeetCode 刷题时习惯了“函数传入参数”的模式一遇到需要自己处理输入输出的题目就懵了。我建议在备考后期专门练一练用cin和printf处理多组输入输出的题目防止在格式上吃亏。5. 笔试之后从真题反推动手能力5.1 Unity 与 C# 方向的延伸学习如果你对西山居的客户端开发岗位感兴趣笔试结束后最该做的第一件事就是补齐 Unity 方向的实战经验。C 是笔试门槛但很多项目组在工作时用的是 Unity 加 C#所以如果你只会 C 而完全没碰过 C#在面试环节会显得没有准备。我的建议是选一个简单的玩法原型动手做起来比如 2D 平台的跳跃、射击游戏的子弹与敌人碰撞、背包物品拖拽等。不需要做得精致关键是跑通核心逻辑。做完之后你会发现笔试里那些抽象的概念组件、生命周期、资源管理在引擎里都变得非常具体。这就是“由题带学、由学带做”的路线远比单纯看视频教程要高效。5.2 Godot 与轻量引擎方向一个被低估的选择在热词里我注意到godot 游戏开发的讨论热度一直在涨这也吻合近两年独立游戏和开源引擎兴起的趋势。西山居的游戏开发岗笔试虽然不会直接考 Godot 的知识但如果你对“游戏引擎的通用机制”有深入研究用 Godot 做过几个小游戏面试时反而能成为差异化优势。Godot 的特点是轻量、开源、场景树结构清晰非常适合用来理解游戏引擎的核心原理。更关键的是它可以让你绕过商业引擎授权和庞大资源的困扰专注于逻辑本身。我在笔试结束后用 Godot 复刻了一个极简的塔防 Demo过程中对节点树、信号系统、资源加载的理解比之前看十个小时教程都深。如果你时间允许用 Godot 做一个完整的小游戏放进简历和作品集是很加分的。我会特别推荐把“对象池”“A* 寻路”“伤害计算”这三个笔试的经典题分别在一个小 Demo 里用起来这样一来笔试学的东西就真正变成了你自己的东西。5.3 微信小程序游戏开发另一个可考虑的入口也许有人会想问为什么要在准备大厂游戏岗笔试的时候提微信小程序游戏开发因为在我看来这是一个被很多人低估的练兵场。微信小游戏开发的逻辑和传统游戏开发有很多相通之处但它的特点是开发周期短、发布流程快、可以直接看到体验数据。它不需要你懂复杂的图形学却需要你快速实现完整的玩法循环。如果你能给自己的简历加上一款已发布的微信小游戏无论是技术完整性还是项目完整度都比“我刷了 300 道题”更有说服力。当然微信小游戏开发的跨端、性能优化和资源大小控制也有自己独特的难点。处理不当会出现明显的卡顿和加载延迟这反而逼着你认真考虑内存占用、渲染批次和资源裁剪。从这个层面讲它和笔试中考察的资源管理思想是一脉相承的。6. 个人实操中的几点心得体会准备西山居秋招笔试这段经历让我意识到一个问题游戏开发岗笔试难在“既要又要”。既要你有扎实的 C 和算法底子又要你懂引擎和图形学的基本概念还要你能写出工程上合理的代码。这和刷 LeetCode 完全不是一回事但又不至于像面试那样直接聊项目它是一个很特殊的中间态。我最大的经验是不要等笔试通知来了才开始准备。C 基础、数据结构和渲染管线这些内容至少提前一个月开始每日积累笔试前一周专门刷模拟卷和复盘错题才可能真正从容。如果时间不充裕优先保住编程题和问答题因为这两块是权重最高、也最容易通过短期训练提分的部分。最后再分享一个小技巧笔试结束后不管结果如何第一时间把笔试中出现的题目和自己当时的答案复盘一遍。这个动作的价值不在于判断自己能不能进下一轮而是让你把每一场“失败的考试”都变成下一次面试的素材库。我记得自己复盘了几场笔试后整理出一份“游戏开发岗通用题库”后来在面试环节聊到技术问题时很多思路就是从那里面长出来的。哪怕这次没有拿到 offer这份积累也会在后面的机会里派上用场。