1. 本次学习目标与整体安排1.1 为什么开始写系统化的游戏开发学习记录今天这篇学习记录起因其实很简单。最近在做的那个独立游戏Demo卡壳了卡了整整两个晚上问题不大不小但就是绕不过去。翻来覆去查资料、改参数、刷论坛帖子折腾到凌晨一点多才发现是碰撞体分组没设对。那段时间我意识到自己的学习方式太零散了。看教程时觉得什么都懂了关掉视频动手做又发现哪里都是漏洞。想了想决定从今天开始每完成一个阶段就写一份学习记录。一方面倒逼自己梳理知识点另一方面也给之后回头看留个底。这次记录的内容是游戏开发中三个最核心的模块角色控制、交互解谜机制、场景表现优化。这三个模块几乎每种游戏类型都用得上对于正在学游戏开发、或者准备自己动手做小项目的朋友来说应该是比较实用的一份参考。我不太喜欢写那种通篇讲概念的教程所以这篇记录的重点会放在实际操作上——今天实际敲了哪些代码、在引擎里调了哪些参数、遇到什么问题、怎么排查解决的。如果你是零基础跟着走一遍也能有个整体概念如果你有一些经验可以直接跳到第3和第4部分那里有踩坑细节。1.2 今日计划的拆解今天的学习时间大概安排了六个小时分成三大块上午两小时完善角色控制基础逻辑重点是移动手感、跳跃重置和摄像机平滑跟随。下午两小时做交互解谜原型从触发器和事件回调入手实现一个开关门与压力板联动的简单机制。晚上两小时优化场景表现包括光照烘焙、动画状态机调整和项目目录整理。为啥这么安排上午的代码基础决定了下午的功能能不能顺利叠加下午的交互逻辑又需要晚上做表现层包装。一环扣一环省得来回切换上下文。很多朋友喜欢想到什么做什么先做个攻击系统又跳去做一个背包界面最后发现代码一团乱。其实踏实按模块推进效率反而更高。2. 角色控制系统的实践记录2.1 从零搭建基础移动逻辑角色控制这块我用的还是最传统的刚体加胶囊体的方案。没有直接用引擎自带的角色控制器组件因为独立游戏里经常需要自定义移动手感自带方案改起来反而麻烦。基础移动代码的思路很简单读入水平输入和垂直输入归一化之后乘上移动速度再赋给刚体的速度。不过这里有个常见的坑就是角色朝着一个方向跑的时候突然转方向会出现“漂移感”原因一般是把目标速度直接赋给刚体的velocity没有考虑当前速度的变化率。我今天的方案是这样的先用当前输入计算期望速度然后用插值逐步逼近期望值而不是瞬间改变。这段逻辑在每帧的FixedUpdate里跑保证物理模拟稳定。float targetSpeedX inputX * moveSpeed; float targetSpeedZ inputZ * moveSpeed; float nextX Mathf.Lerp(rigidbody.velocity.x, targetSpeedX, 0.25f); float nextZ Mathf.Lerp(rigidbody.velocity.z, targetSpeedZ, 0.25f); rigidbody.velocity new Vector3(nextX, rigidbody.velocity.y, nextZ);跑起来之后手感就是“起步有一点迟滞但转向很跟手”。这个0.25的插值系数是我调了半天试出来的数值太小会感觉角色在冰面上滑太大又显得生硬。建议有心的朋友把它暴露成Inspector里的一个公开变量后续做不同角色时可以直接调。2.2 镜头跟随与视角平滑镜头这块我用的是“第三人称平滑跟随”的做法就是相机位置始终在玩家后方偏上的地方跟着旋转方向一起动。实现上不直接让相机的位置等于玩家位置加上偏移量而是用一个临时向量通过插值慢慢靠近目标坐标。为什么不能直接赋值因为角色在移动中会抖动相机跟随有个延迟看起来反而自然像有人拿着摄像机在拍一样。Vector3 targetPos player.position player.right * offset.x Vector3.up * offset.y player.forward * offset.z; Vector3 smoothPos Vector3.Lerp(transform.position, targetPos, 0.12f); transform.position smoothPos; transform.LookAt(player.position Vector3.up * lookHeight);这个lookHeight很重要如果像机视线直接对准角色脚底画面会显得很低。往上偏大概1.2到1.5个单位视野中心差不多就在角色上半身跑动时看起来最舒服。今天实测下来lerp系数0.12在60帧下表现流畅但如果游戏掉到30帧需要适当调大否则镜头拖尾会很明显。2.3 踩坑记录碰撞体与刚体的摩擦设置今天最磨人的坑出在物理材质上。角色站在斜坡上明明没有按移动键却一直慢慢往下滑。一开始以为是代码问题查了半天发现是刚体默认的物理材质摩擦力太小重力分力超过了最大静摩擦力。解决方法是新建一个物理材质动态摩擦力和静态摩擦力都调到1.0再用代码给刚体挂上去并在所有平台上统一使用这个材质。注意斜坡滑动这个问题不能靠加大代码里的阻力值硬扛那会让角色在平地跑起来像脚底灌了铅。物理材质才是正道。另外还有一个细节跳跃时要把刚体的interpolation设置为Interpolate否则跑动中起跳会有一帧明显的位置跳动。这属于老生常谈但新手很容易忽略。提示如果你发现角色在斜坡上总是不受控制地滑下去先检查物理材质而不是怀疑输入的代码逻辑。3. 核心玩法原型交互与解谜机制3.1 触发器与事件回调的实现思路交互解谜的核心是“检测到玩家进入某个区域然后触发一连串反馈”。实现上最常用的就是引擎的触发器给某个物体挂一个碰撞体勾选IsTrigger然后监听进入事件的回调。今天就拿这个思路做了一个开关门与压力板联动的小机制。开门区域是一个长方体触发器玩家走进去就会调用一个公开方法来打开门走出区域时再调用另一个方法关上门。逻辑本身不难但写的时候有几处值得注意。比如触发器里可能有多个物体同时进出每帧回调会连续触发很多次如果打开门的动画没有做防抖就会出现门在开启和关闭之间来回抽搐。解决方式是在代码里加一个“是否正在切换”的布尔标记等动画播完再允许下一次触发。这是很多交互系统里都需要的通用防抖逻辑以后做其他机制可以直接复用。3.2 用状态机管理游戏流程解谜机制搞到一半我意识到单纯的触发器回调容易出现逻辑混乱。比如压力板被踩住时开门、离开时关门看似简单但加上多个压力板同时存在、顺序触发、时间限制这些条件之后回调里就会堆满if。我的做法是引入一个轻量状态机来管理。所谓状态机就是将一个物体的行为拆成几个状态比如“待机”“激活”“已触发”规定状态之间怎么切换切换时执行什么动作。今天给压力板写了一个很小的状态类核心代码大致长这样class PressurePlate: def __init__(self): self.state idle self.triggered False def update(self): if self.state idle and self.is_pressed(): self.enter_active() elif self.state active: self.resolve_effect()虽然这算是很朴素的写法但关键在于把“状态”和“具体效果”分开了。以后一个压力板既能开门又能激活另一个机关又不至于把所有逻辑都堆在回调里。等机制复杂到一定程度建议直接上正式的状态机库不过今天这个轻量版本对我这个小Demo来说已经够用了。3.3 案例演示开关门与压力板联动完整跑通的小例子是这样一个循环房间中央有一块压力板门口有一扇门。玩家从门口进去踩上压力板门自动关闭等玩家从侧方的暗门离开再放开压力板门重新开启。实现上就三步压力板挂碰撞触发器监听玩家的进出。门使用一个平移动画从初始位置移动到目标位置。压力板触发后调用门的公开方法传入“开”或“关”的指令。调试的时候还发现一个很有趣的问题门的开关速度太快玩家会被卡在半空中。这是因为门在关闭过程中物理碰撞依然生效把玩家往外推。解决办法是把门的碰撞体在动画过程中设置为临时忽略玩家层级动画结束后再恢复。注意交互型机关里“效果执行期间会不会干扰玩家”是必须考虑的一个维度。例子里的门看起来不起眼实际调起来涉及碰撞层级、动画时间、回调时机几个点对不上就会出各种奇怪表现。4. 场景搭建与战斗表现优化4.1 光照烘焙与场景性能调整到了晚上这趴主要是做视觉层面的打磨。今天的场景是一个带走廊和小庭院的中等规模房间按原样用动态光的话每个光源都要参与实时计算特别是有阴影的平行光对性能的消耗非常大。我的做法是改用烘焙光照把场景里的静态物体标记为静态摆放灯光之后先烘焙出光照贴图再运行游戏这时候大部分光照信息直接采样纹理开销明显下降。有个细节必须提一下——烘焙参数里的“间接强度”。数值默认是1场景氛围会比较平我调到0.6之后暗部明显更有层次同时不会出现脏兮兮的黑斑。如果是偏写实风格可以在0.5到0.8之间微调要是卡通渲染风格反而建议设到1.2左右让漫反射更亮。另外阴影质量这个参数最容易被忽略。默认的“软阴影”在近处物体上效果还行但走廊远处的柱子会出现明显的锯齿边缘。我把阴影距离调近了配合分辨率上调一档效果立刻好了很多代价是烘焙时间从两分钟涨到七分钟。好在烘焙是一次性的运行时几乎不占性能。4.2 动画状态机与打击感细节战斗表现这块我重点调了一个普攻三连击的动画状态机。状态机里四个节点Idle、Attack1、Attack2、Attack3每段攻击收招时可以回到Idle也可以进入下一段。这里的核心问题是切换时机如果动画播到一半就切换角色动作会闪一下非常难看如果等动画完全播完才允许切换连招手感又会显得迟钝。我的解决办法是给每段攻击动画设置“攻击窗口”在一个固定百分比的时间点比如35%到70%之间输入下一次攻击会被记录动画一结束就直接衔接下一段。窗口之外的输入统统忽略。用代码里一个简短的定时器就能实现不需要引入复杂的输入缓冲系统。实测下来手感顺滑了许多连招成功率接近九成。打击感另一个容易被忽略的细节是“顿帧”就是命中目标时让攻击方动画暂停极短的时间比如0.06秒。这个效果配合命中时的粒子和镜头轻微抖动砍中敌人的“重量感”马上就不一样了。顿帧不能做得太长否则流畅性会受影响0.04到0.08秒之间是比较稳妥的范围。4.3 资源组织方式与项目目录规划这一点看起来和学习记录没什么关系但恰恰是我今天花时间最多的地方之一。项目做到一半资源网里到处是NewFolder_2、Test_Scene_副本这样的目录想找一个贴图都要翻老半天。今天彻底把项目目录按模块重新整理了一遍结构大致是这样的Assets/ Art/ Characters/ Environments/ UI/ Audio/ BGM/ SFX/ Code/ Player/ Interaction/ Animation/ Prefabs/ Scenes/这种分层方式的好处是做“角色”的时候模型、贴图、材质、动画、代码都在一个大的分类下面虽然物理上分散但每个顶层目录只放各自类型的内容找起来很直观。游戏开发项目中资源命名的重要性怎么强调都不为过。今天顺便把一大批以前乱命名的文件改成了“前缀_功能”的格式比如P_Player_Character表示预制体VFX_Hit_Slash表示斩击命中特效。虽然花了点时间但以后省下的时间只会更多。5. 今日复盘与后续计划5.1 时间分配与效率分析今天的花的时间比计划稍微超了一些主要超在物理材质和项目目录整理这两块。回头复盘原因是这两部分之前一直没有形成固定套路每次都是遇到问题再临时上网查。如果早一点把“斜坡防滑用专属物理材质”“资源目录用顶层分类”这两条规则刻进习惯里至少能省四十分钟。倒是交互逻辑和动画状态机这些“新知识”部分时间控制得不错因为提前把状态机方案想清楚了动手时基本没走回头路。这个经验以后可以复用学习新东西之前先花十五分钟把流程步骤写下来再开始动手。先画路线图再上路效率真的不一样。5.2 阶段性成果自测今天的成果还是可以拿出来见人的角色基础移动手感调好转身不飘、斜坡不滑、跳跃不跳帧。压力板开关门机制跑通并预留了多机关联动的扩展点。动画状态机三连击流程完整连招流畅度和命中顿帧到位。项目目录重命名完毕所有预制体和特效都有统一的命名前缀。老实说单独看每一项都不算复杂但组合在一起这个Demo从一个“灰盒跑酷”终于变成了“看起来像一个正经游戏”的状态。这正是持续做小东西的意义——每天积累一小块几周后回头看变化是跳跃性的。5.3 明天要解决的问题清单根据今天的进度明天计划重点处理下面几个问题给压力板机制加上“顺序触发”的变体测试状态机的扩展性。给角色增加基本的冲刺动作并检查动画过渡是否会被打断。尝试做一版更完善的角色切换系统验证今天整理的目录结构能不能支撑多个角色共存。其实原计划里没有角色切换这块但今天整理代码时发现角色控制的移动、动画、交互三块已经解耦得比较干净加新角色应该不会牵连太多旧代码。这种“因为基础打得好所以敢加功能”的感觉算是做项目最踏实的时刻了。5.4 给同样在自学的朋友一些建议最后简单聊聊我这段时间的自学体会。很多人学游戏开发容易陷入一个误区就是拼命看教程、囤资料但真正动手做的时间很少。我自己的学习记录也用过很多种格式后来发现最有效的不是漂亮的手账也不是详细的目录笔记而是“遇到什么就记什么跌倒了就记录怎么爬起来”的那种流水账。过一阵子回去翻所有坑都历历在目比任何结构化笔记都管用。游戏开发这条路门槛其实不在工具操作而在那个“卡住、想放弃、又硬着头皮继续”的循环里。每次遇到难啃的骨头我都会告诉自己先把问题拆到能解决的最小单元再逐个击破。今天这份学习记录也算是对这种心态的一次见证。那就先记到这里。明天有新的进展我再来更新。