每年三四月份准备春招的朋友总会把目光投向几家头部游戏公司叠纸游戏就是其中一个绕不开的名字。提到叠纸大多数人第一反应是《恋与制作人》《闪耀暖暖》这些女性向爆款但如果你真想冲它的游戏研发岗光知道这些还不够。叠纸的笔试不像传统互联网大厂那样以海量刷题为导向它更看重你对游戏系统的理解、对渲染表现的技术直觉以及面对未知问题时拆解方案的能力。这篇文章是我结合往年春招题型的复盘以及身边参加过多轮笔试的朋友反馈整理的。虽然每年的具体题目都在变但考察的底层能力是稳定的。无论你目标是服务端、客户端还是引擎方向这套内容都能帮你把复习重点从“盲目刷题”拉回到“精准准备”上。内容会比较长建议先收藏再细看尤其是最后一部分的时间规划和复盘方法关键时刻能帮你多拿不少分。1. 叠纸游戏的笔试到底在考什么1.1 先看清公司的技术底色叠纸的游戏品类决定了它的技术侧重点。你去看《闪耀暖暖》的换装渲染再看《恋与深空》的3D角色表现会发现这家公司在渲染、材质、角色表现上的投入远超一般手游团队。所以笔试里图形学相关题目占比不低而且经常结合具体游戏场景来出比如“把一件裙子的缎面材质效果做出来需要哪些渲染要素”。另一个特点是业务导向非常明显。叠纸的研发笔试很少出现纯粹的理论默写哪怕是一道算法题也常常套着“玩家抽卡”“角色换装”“关卡掉落”这样的壳。说白了公司想筛的不只是会写代码的人而是能理解游戏业务逻辑、知道代码在为哪种体验服务的人。这一点你从题目描述就能感受到提问方式会带着强烈的项目感。1.2 一套典型的笔试题型构成如果你参加过几家公司的游戏研发笔试会发现叠纸的卷面结构算是比较有代表性的。总时长通常在120到150分钟题型大致分成四块选择题或填空题、手写代码题、简答/设计题部分批次还会加一道综合大题。选择题和填空题主要覆盖C基础、数据结构和操作系统比如虚函数表的组织方式、static关键字的作用、进程和线程的区别。代码题一般一到两道难度大致在LeetCode中等偏上但更偏向字符串处理、模拟、搜索这类和游戏逻辑沾边的方向。简答和设计题则直接考查你的游戏系统理解比如如何设计一个排行榜、如何做角色换装的数据存储。不同岗位的侧重点会有差异客户端更重图形学和引擎机制服务端更重网络同步和数据库设计引擎方向则会深挖渲染管线和性能优化。如果你投的是gameplay方向的岗位那题目会更加杂食从基础算法到系统设计都可能出现。2. 硬核一关C与算法题的常见套路2.1 C基础考点不能只看表面叠纸的C题目不考“你背过没有”而是考“你踩过坑没有”。比如面试题里常出现的“vector扩容机制”很多人能说出“容量不够时翻倍增长”但题目一旦变成“为什么是1.5倍或2倍而不是固定增量”很多人就答不上来了。这里面涉及的其实是内存分配开销、迭代器失效、以及不同STL实现之间的差异。还有一类高频题是问“智能指针的引用计数为什么是线程安全的但对象本身不是”这要能拆开讲清楚。引用计数的加减用的是原子操作保证了计数的线程安全但两个线程同时修改指向的堆对象那属于数据竞争智能指针管不了。笔试如果出到这类题往往会在选项里埋坑比如把“智能指针完全线程安全”这种话当作正确项不少基础不牢的人就会跳进去。我的建议是复习C不要只刷面经至少把《Effective C》里关于资源管理、构造析构的章节过一遍。尤其是拷贝构造、移动语义、右值引用这些叠纸的题目经常用一段看似普通的代码考你“这段代码调用了哪几个构造函数”看起来简单真写起来很多人会错。2.2 算法题做对不难写得“漂亮”才加分叠纸的算法题整体难度没有互联网大厂那么卷但它会在代码风格上做隐性考察。我朋友考过的一道题大概是“给定一个角色好感度列表按指定规则排序并输出前N名”。类似这样的题核心考点不是算法本身而是你在代码里会不会写出冗余分支、能不能用稳定的排序、以及异常输入的处理是否到位。这里分享一个通用解法先明确入参出参再考虑边界条件最后才是核心逻辑。很多同学一上来就写核心循环结果忘记处理空列表和重复值这种失误非常可惜。笔试的判分通常按测试用例覆盖来算边界场景挂一个可能就从满分掉到及格线。数据结构的考察则集中在哈希表、优先队列和二叉树。比如“如何设计一个抽卡系统的概率池”这种题本质上是在考权重随机算法。你可以用前缀和加二分查找也可以用别名方法实现O(1)的抽卡操作。如果你能在答案里写出两种方案并对比复杂度阅卷人一眼就能看出你对系统的思考深度。注意笔试里遇到熟悉度很高的题也别高兴得太早就用背诵的代码直接套。叠纸的题目经常在细节上做改动比如排序规则换成“羁绊值相同按角色编号倒序”改动虽小但直接抄模板大概率会挂。2.3 手写代码的现场细节手写代码题一般是在网页编辑器里完成不提供本地编译调试所以平时的编译依赖习惯要改一改。你没法一边写一边F5唯一的保障就是写的时候注意力高度集中。我建议在正式笔试前至少用在线编辑器练两周让自己适应没有IDE提示的码字速度。代码规范也是隐形分数。变量命名要能看出含义不要出现a、b、c这种临时命名关键逻辑要写注释尤其是处理边界条件的地方。这些小细节不会直接加分但阅卷人看了舒服主观题的印象分会好不少。3. 图形学与引擎知识游戏研发的分水岭3.1 渲染管线这类基础题必须拿满分叠纸对图形学的考察深度在同体量公司里是中上水平。选择题常考渲染管线的流程顶点输入、顶点着色器、几何着色器、光栅化、片元着色器、测试与混合这个顺序必须闭着眼都能写出来。进一步它会问你“在哪个阶段做背面剔除”“深度测试发生在混合之前还是之后”这类细节。很多自学图形学的人对管线流程记住了但细节顺序容易混淆。比如Alpha Blend和Depth Test的先后关系正确答案是深度测试在先通过后才做混合。这里一旦理解错后面的透明物体排序问题也会连带出错。坐标变换同样是必考项。模型空间到世界空间再到观察空间到裁剪空间四步变换要能画出矩阵顺序。特别提醒一点叠纸的题喜欢把坐标变换和法线变换混在一起考人问你“非均匀缩放时法线为什么不能直接用模型变换矩阵”这题答得好说明你真懂矩阵推导而不只是背了函数名。3.2 结合项目场景出的渲染题怎么答叠纸的项目以角色表现见长所以换装、材质、布料这类话题几乎是必考方向。比如会问“如何表现丝绸材质的高光变化”你需要拆解成PBR的多个要素基础色贴图控制颜色分区、法线贴图控制褶皱光影、粗糙度贴图控制高光锐利程度再配合各向异性高光做出丝缎的流光感。答题思路建议先讲表现结果再说实现路径最后补性能优化。不要一上来就写一大堆shader代码面试官首先想看到的是你有没有画面感其次才是技术细节。比如“一个角色从白昼走进夜晚场景身上的衣服颜色应该如何变化”这就是一个典型的全局光照与后处理结合的题。能答出“环境光变化、间接光颜色偏移、Bloom阈值调整”三层逻辑的人显然是真正做过场景的。3.3 引擎相关Unity和UE你至少得懂一个叠纸的项目Unity和UE都有Unity偏向客户端业务开发UE更多用在管线和高品质表现方向。笔试通常不会限定引擎但题目会用“你的主引擎”这样的说法来考察通用机制。高频考点包括Unity的Update和FixedUpdate的区别、协程与线程的区别、对象池的原理UE的Actor和Component的职责划分、GC机制、UObject的反射系统。别指望只靠题海战术背答案引擎题目最容易追问“底层为什么这么设计”你得能讲出设计动机来。比如Unity把物理计算放在FixedUpdate是因为物理模拟需要固定的时间步长来保证确定性如果放Update里帧率波动会导致物理表现不稳定。性能优化也是常客比如“UI界面卡顿如何排查”。这类题在现场很难一两句话答完我的诀窍是分层回答先确认是CPU瓶颈还是GPU瓶颈然后CPU侧看是否有频繁Instantiate导致的堆分配是否有Update里做过重的逻辑GPU侧看Overdraw是否过高、是否有多余的实时光源。按这个思路答哪怕不是最终答案阅卷人也会认为你有排查问题的框架感。4. 系统设计题让阅卷人看到你的游戏感4.1 设计题不是写作文是画蓝图叠纸的笔试里系统设计题是拉开差距的地方。它不要求你写出完整代码但要求你的方案经得起推敲。比如“为换装系统设计一套数据存储方案”这就非常典型。拿到题先别急着写字段。第一步要定义系统边界玩家拥有哪些部件、每个部件的属性颜色、星级、稀有度、是否支持染色和自定义、是否有多套穿搭组合。边界定了后面才不会漏需求。第二步是设计核心数据结构比如用部件ID加实例ID的方式区分“设计模板”和“玩家实际持有的物件”避免把模板属性直接写在玩家身上导致后续加新属性时全表都要改。第三步要补交互和表现逻辑。换装保存时要不要做合法性校验穿搭配件冲突时怎么提示外观展示和数据存储之间要不要做缓存。这些点不用全写但挑两三个展开讲透比泛泛讲一大片要有效得多。4.2 如何评估一个系统设计方案的优劣一个常见误区是把系统设计题当成“方案越多越好”。实际阅卷时考官更看重逻辑闭环和可落地性。比如任务系统你写“用状态机管理任务阶段”这没问题但如果没解释清楚“任务进度是存数据库还是存缓存”方案就缺了一条腿。一个成熟的设计一定包含数据如何持久化、并发情况如何处理、容灾和回滚怎么做。可以试着用“五维评分法”自检一用户需求是否明确二数据结构是否清晰三性能边界是否考虑四扩展性是否够好五实现成本是否可控。写完方案后花两分钟对着这五条检查一遍能补的漏洞尽量补上实在来不及就在答题末尾注明“这里受时间限制未展开实际开发中会考虑XX”这比漏掉显得更专业。4.3 几个常考系统题目框架速览排行榜系统核心矛盾是读写压力。读要快写要稳。方案可以用跳表加定期落库或者用Redis的ZSet做实时榜再通过离线任务算周榜。答题时把缓存与持久化的分层讲清楚。背包系统核心是格子管理、堆叠、排序、丢弃。要处理“物品堆叠数量上限”“快捷使用后刷新UI”“批量分解的并发”。数据库层面建议用独立背包表而不是在角色表里塞JSON。好友系统看似简单实际考的是关系型数据的存储设计。双向好友关系的表结构推荐好友的算法以及在线状态如何通过推送服务感知都是加分点。这些框架不需要背但要理解每个系统的核心矛盾在哪。答题时抓住主要矛盾展开比你罗列十几条功能需求要强得多。5. 笔试实战经验时间管理、环境准备与复盘5.1 答题顺序可能比你想的更重要我的个人策略是先快速浏览全卷用两三分钟把每道题的分值和工作量做一个初步判断。先把选择题搞定这部分速度快、拿分稳。然后做设计题因为设计题想拿高分需要思路顺畅放在大脑最清醒的阶段更合适。代码题放到最后但至少要留出40分钟。如果你一上来就死磕一道算法题卡了半小时这半小时如果花在系统设计题上可能多拿一半的分数。很多人笔试后懊悔的都是“那道设计题其实我会只是没时间了”。所以在时间分配上我的建议是选择题不超过30分钟代码题40-50分钟设计题40分钟最后预留5分钟检查。5.2 网络、设备与心态一个都不能少笔试环境是个容易被低估的变量。叠纸的线上笔试一般用网页监控对浏览器的版本和权限有要求。提前一天要做的检查包括摄像头是否可用、浏览器是否允许屏幕共享、网络是否稳定。我建议至少提前30分钟进笔试房间把设备调试好再重读一遍邮件里的考试须知。笔试中如果遇到代码编辑器卡顿或者提交失败不要慌先截图保存再换浏览器刷新。部分平台有断点续答机制重新登录后之前的答案一般还在。但如果你没有截图记录一旦提交异常最后的答案可能就没了。所以关键代码写完后随手复制到本地文档备份这也是一种成熟的工作习惯。心态上游戏研发笔试的范围非常广任何人都不可能全部答对。遇到没见过的知识点先跳过去把能拿的分都拿了再回头琢磨。笔试后半程才是真正的心理战越是紧张越要提醒自己“按正常节奏写就行”。5.3 笔试之后的复盘比估分更重要走出笔试房间趁记忆还新鲜花半小时把每道题还原出来。用文档记录下来题目描述、你的答案、当时的犹豫点、以及现在复盘后的正确思路。这些东西是你接下来面试最宝贵的素材库。面试时被追问“你上次笔试里那个系统设计题如果重新做会怎么改”你就能拿出经过思考的版本而不是支支吾吾。我身边进叠纸面试的朋友几乎都有一个共同习惯把笔试错题整理成专题笔记按知识点分类。比如把图形学错题归到一起把C陷阱题归到一起。这样复习的效率非常高因为你是在针对自己的薄弱点补短板而不是把网上的面经再刷一遍。写在最后游戏研发岗的笔试表面上是考知识点实际上考的是你面对一个具体问题时能否用工程师的方式结构化思考。叠纸的卷子尤其看重这一点它的题目不会偏离游戏太远你平时如果真正玩过自己的游戏、拆解过系统的逻辑、写过干净的代码到考场上自然会比纯刷题的人多一份底气。最后再分享一个小技巧准备一张A4纸考前把容易混淆的知识点手写一遍比如渲染管线的顺序、智能指针底层原理、坐标变换矩阵的排列方式。手写的过程能帮你在大脑里建立索引考场上遇到相关题目时提取速度会比纯看书快不少。祝今年春招的朋友都能拿到心仪的offer我们面试现场见。