「开发者日记」动作射击游戏开发 Dev Log

发布日期：2025 年 6 月 2 日

一、灵感：从构想到可行性验证

1.1 起源

最初的点子源于一次与朋友的闲聊——他是学音乐的，我们还有一个做游戏策划/设计的共友，我们就聚在一起想说可以一起做一个独立游戏。这个游戏要跟射击有关，然后关键点就是爽，类似于战锤里面的那种手撕虫族。最后想了想，改成了我们自己喜欢的元素：钢铁厂里的 AI 兵工厂暴走，人类抵抗军潜入、破坏、夺回控制权。我想把这种冷峻的工业氛围与快节奏射击、卡牌策略结合起来，做成一款混合了动作射击 + 战术卡牌元素的游戏 —— 关键就是打起来要爽。

1.2 第一张「可信度表」

我们大致讨论了一下下面者三点：玩法卖点 / 技术需求 / 我们的能力点，大致平衡取舍了一下**。**最后留下的雏形是：

第三人称射击：需要角色移动、摄像机、武器系统。
战术卡牌（肉鸽元素）：以后再拆，但现在得保证代码可扩展。
工业场景：钢厂、核电站，两张大地图。
AI 兵种：巡逻、守卫、攻城三种基础行为。

当下就足以做一个 MVP 了，但后来发现还是想简单了。

二、技术折腾记：三次重构的血与泪

2.1 第一次重构 —— 「GPT 说什么我就写什么」

2024 年 11 月，我把“我要做第三人称射击，帮我写人物移动、摄像头控制、WASD 输入”丢给 GPT‑4o，模型立刻产出一套基于 Input.GetAxis() 的移动脚本和极简的摄像机跟随组件。一个月后，我又让敌人挂上 NavMeshAgent 去追踪玩家，Demo 总算能跑起来。可很快就暴露出硬伤：摄像机动不动穿墙、子弹判定时灵时不灵，所有逻辑又都硬塞在 PlayerController.cs 里，改任何一行都像拆炸弹。当时的我甚至不知道 Unity 自带「新输入系统」和 Cinemachine 这种现成方案。

而且由于我当时没有太多做游戏的经验，没完全理解另一位同学给出来的游戏设计，发现当前设计的系统有很多需要改的地方。

2024.11：用 GPT‑4o 提示词：“我要做第三人称射击，帮我写人物移动、摄像头控制、WASD 输入” ；GPT 给了一套基于 Input.GetAxis() 的脚本 + 简易摄像机跟随代码
2024.12：把「敌人」当成 NavMeshAgent 去追踪玩家；跑得动，但摄像机穿墙、子弹碰撞丢失，硬编码全写在 PlayerController.cs 里。

教训：不懂 Unity 生态，连官方的「新输入系统」和 Cinemachine 都没用上，代码全耦合，一个改动就爆炸。

2.2 第二次重构 —— 「先把东西拆干净」

吃过一次大亏后，我决定先做架构再写功能。首先把角色运动、武器射击、摄像机控制和技能体系拆成四个独立组件：CharacterMotor、WeaponHandler、CameraRig 和 AbilitySystem。所有可操作单位（玩家与敌人）统一继承 BaseCharacter，这样只需维护一份移动与射击逻辑。子弹改用 OnTriggerEnter 配合 Layer Mask 做碰撞检测，终于能稳定命中。然而当我尝试加入武器热量和开镜散布时，GPT 生成的代码再次暴露耦合问题：极端角度的射线依旧穿透，新增参数让脚本迅速臃肿。模块化只完成了“拆”，还没做到“优雅”。

虽然这次可以完美满足游戏的设计好的需求，但是没有一点可拓展性。比如说：如果我想新增一种枪械怎么办？我有不同的主角怎么办？肉鸽里面有的几十种能力升级路径怎么处理？我现在的代码都只能处理一种枪械、一个人物、一个技能。现在所有的逻辑基本还是放在一个脚本里的，如果需要改动还是像拆炸弹… 所以就迎来的下一次重构，把所有的系统解耦成基类和子类，让一个系统的武器/吉能/人物可以相互继承。

模块化：
- CharacterMotor（移动）
- WeaponHandler（射击）
- CameraRig（摄像头）
- AbilitySystem（技能）
通用基类：玩家和敌人都继承 BaseCharacter，共享移动/射击逻辑。
碰撞检测：子弹用 OnTriggerEnter + Layer Mask，终于能稳定命中。
问题：
- GPT 写出的碰撞代码面对极端角度射线常穿透。
- 新需求（比如武器热量、开镜瞄准）一加，耦合问题又出来了。

2.3 第三次重构 —— 「官方套件才是王道」

2025 年初，我索性照着 Unity 官方教程重做一遍：输入系统全面切到「新输入系统」，手柄、键鼠、触屏映射随意切换；摄像机换成 Cinemachine FreeLook 轨道，相机再也不会穿墙；角色动画由 Animator 配合 StateMachineBehaviour 管理，状态流转顺滑；事件分发改用 ScriptableObject 事件通道，把 UI、音效、伤害结算彻底解耦；子弹与血迹全部丢进 EZ Pool 对象池，内存与帧率都稳了几个档次。到此为止，人物移动丝滑、四肢 IK 精准，三种伤害类型（穿甲、爆炸、能量）统一走事件系统，改一处数值不再牵一发动全身。

我直接取经 Unity Starter Assets + 官方教程：

新输入系统：可扩展映射（手柄 / 键鼠 / 触屏）。
Cinemachine FreeLook：层级轨道，自动防穿墙。
Animator + StateMachineBehaviour：角色移动 → 攻击 → 受击流转。
ScriptableObject 事件通道：解耦 UI、音效、伤害结算。
对象池：子弹、血迹特效用 EZ Pool 动态管理。

现在的状态：人物移动丝滑、枪械四肢 IK 对齐、摄像机无穿墙，基础伤害逻辑（穿甲 / 爆炸 / 能量）都走事件通道。

三、美术踩坑记：由写实风格转换到Low‑Poly 风格

虽然开发上的问题解决了，但由于之前一直忽视了美术上的问题，所有能跑的部分都是灰模，没法看。美术的问题还是需要我来解决。

最初我天真地以为，只要把 MidJourney v5 生成的概念图丢进项目，再从各种 PBR 素材站东拼西凑贴图，就能在短时间内堆出一套逼真的工业资产。现实却狠狠地教训了我：颜色不统一、法线混乱、授权费飙升，整张场景像廉价素材大杂烩一样。痛定思痛后，我们改投 Low‑Poly 方向：块面简洁、色块鲜明、LOD 友好，也更符合五人小队的产能。

如今的美术流程相对清晰一点吧：先用AI生图工具（GPT-4o 或者 MidJourney），确定概念图，然后用混元 3D 来生成图像，最后在 Blender 里手动改一些小细节就行。

下一步，我们正在尝试把 GPT‑4o 与 混元 3D v2 结合起来，批量产出「低多边形 + 柴油朋克」风格的钢厂管道、两米高货架等模型（含完整 .fbx 和贴图包）。问题在于同一批模型的色调和比例经常漂移。为此，我正编写 Prompt Linter：它会在生成前自动注入我们的色板、倒角半径和比例规则，极大提升一致性。具体可以看我下面 Figma 的截图。

四、当前成果小结

经过三次重构和一次美术转型，目前的原型已经能连贯跑通：角色在 Cinemachine FreeLook 视角下灵活穿梭于钢厂里的 AI 生成的模型；StateMachine 驱动的动作比较流畅；武器与伤害系统支持穿甲、爆炸、能量三系，并且参数完全脚本化；敌人 AI 已实现巡逻与追击；50 件 Low‑Poly 资产覆盖了大部分工业装饰。启动 Demo 后，玩家会出生在钢厂外围的铁路，拾起枪械，与两波巡逻机器人交火并取得胜利。

但是问题也很明显… 都开发了快一年了，虽然这里面很大一部分原因是我在游戏开发领域还很菜，最后出来的游戏效果也非常的塑料。这也就引申出了我们的下一步计划，聚焦一个方向做优化。

七、聚焦地图：重启计划

在最近的复盘会议上，我们意识到自己贪心过头：既想要炫酷地图、又想塞进 Roguelike 循环、爽快战斗、写实美术和 Boss 机制，结果每块都浅尝辄止，项目像散沙一样松散。于是决定推倒重来，并把地图体验定为唯一的 S 级目标。其他系统——战斗、美术、动画、Roguelike 循环、音乐——暂时只做到「能玩」即可。

为达成这一目标，我们先要完成两件事：其一，梳理世界观并写出结构清晰的设计文档，让每张地图逻辑自洽、故事连贯；其二，收束开发流程，只围绕一条可打的核心玩法做深做透，而不是再铺陈功能清单。

五、五条经验

回头看，有五件事值得早点明白。

第一，务必先做能跑的垂直切片（尽可能的精美和完善，标准就是可以在短视频平台爆火），再去构想宏大的玩法宇宙；

第二，能用官方套件就别造轮子，省下的时间应该用来打磨体验；

第三，确定美术风格要比制作资产更早，否则一致性代价极高。在美术上花的时间应该至少占到整个项目的50%，而且需要尽早开始。我们就是美术开始的时间太少了，我的游戏策划朋友实际上了解，但是我不了解。导致我一直再把美术的工作量往后拖，让最后呈现出来的美术效果不是很理想。

第四，把可扩展性写进第一行注释。游戏的代码底层架构一开始定了就很难改了，确保规划好大部分的玩法再开始，或者是做好可拓展性。

第五，坚持写 Dev Log，它不仅是复盘笔记，也可以吸引同好。

暂时就这样，stay tunned！过大半年估计就能开发出来。

动态更新