返回作品馆
已发布项目详情个人练习
Unity 2D 横版动作战斗样机 项目封面

Unity 2D 横版动作战斗样机

个人练习2026-05-21 更新

我为了向战斗策划转型而制作的 2D 横版动作战斗样机，重点验证战斗端制作、能力配置、状态效果、怪物行为复用，以及验证工具和 AI 协同流程如何一起支撑战斗系统迭代。

项目类型个人作品 / 战斗设计样机
项目周期2026
平台Unity 原型
展示范围个人作品集公开案例
职责摘要战斗端制作 / 状态配置 / 敌人行为 / 验证协同

项目背景

  1. 01这个样机最初来自我向战斗策划方向转型时的定向训练。它不是为了把个人 Demo 包装成完整游戏，而是为了把战斗端制作中最基础、也最容易被忽略的结构问题真正做一遍。
  2. 02我想补齐的不是某一个功能点，而是战斗策划落地时必须同时理解的链路：动画和状态机如何承接动作执行，帧数据和输入响应如何影响操作节奏，命中检测和打击反馈如何让行为结果可读。
  3. 03在系统层面，我把 Ability、Buff、怪物行为和 Boss 阶段放到同一个样机里验证，重点看这些内容能不能形成可配置、可调试、可复盘的战斗结构，而不是随着动作和怪物增加变成临时逻辑堆叠。
  4. 04同时，我也把调试工具、自动测试入口和 AI 协同流程纳入项目组织。它们的作用不是抢走战斗系统本身的主位，而是让后续迭代能更稳定地定位问题、验证修改和沉淀经验。

设计目标

  • 理解基础战斗构成通过角色移动、输入响应、动画状态、命中检测、受击反馈和敌我交互，梳理横版动作战斗从能打到可调所需要的基础模块。
  • 验证战斗循环验证玩家输入、能力释放、命中反馈、敌人压迫、资源消耗和复盘调整能否形成稳定闭环，让战斗不是单次动作拼接。
  • 战斗配置方案验证验证普通攻击、技能、派生动作、帧数据、碰撞盒和反馈参数能否用统一配置管理，使新增能力时保持清晰的调试边界。
  • 能力值方案验证验证伤害、硬直、冷却、消耗、位移、霸体和打断等能力值如何影响战斗节奏与风险回报，并为后续调优预留观察入口。
  • 怪物基础行为配置验证怪物基础信息、能力集合、AI 参数和阶段条件能否拆成可组合配置，让巡逻、索敌、追击、攻击选择等行为既可复用又能做出差异。
  • AI 协同开发验证验证 project-index、设计文档、接口说明、实现规则、测试入口和 AIWorkflowEvalChecklist 能否组成受约束的协同流程，让 AI 辅助实现与验证而不替代设计判断。

我的职责

  • 战斗端制作与结构拆解我负责梳理角色战斗端的核心链路，将动作执行、状态切换、连招追踪和命中检测拆成更清楚的结构，保证样机不是只靠单个动作撑起来。
  • 状态与效果配置整理我负责整理 Ability 与 Buff 等可配置内容，把状态效果、触发条件和持续过程从临时逻辑中拆出来，使普通攻击、技能和派生动作能沿用统一的管理方式。
  • 敌人与 Boss 行为组织我负责组织怪物能力、AI 参数和 Boss 阶段行为，在差异化体验与复用边界之间做拆分，让敌人行为后续还能继续扩展。
  • 调试验证与协同流程我负责把 Inspector、命中框观察、状态调试、自动测试入口和 AI 协同流程接入日常迭代，让战斗问题可以被观察、验证和复盘。

我的方案/核心设计

  1. Ability 执行链设计AbilityData 写帧数据、触发条件、连招和反馈参数；AbilitySystem 做输入匹配与连招追踪；AbilityState 执行前摇、活跃、恢复，命中后交给反馈管理。
  2. 怪物行为装配EnemyDefinitionData 作为主入口，装配基础面板、动作集合、单动作规则、行为参数和运行时读取入口，让怪物差异来自配置组合。
  3. Boss 阶段组织沿用怪物能力与 AI 配置，Boss 只追加阶段条件、行为切换、镜像压迫和技能组合，避免 Boss 逻辑变成无法复用的独立孤岛。
  4. AI 协同制作链路project-index 判定任务类型，读取 Feature Spec、系统文档、IterationDoc、SystemAPI，再执行、规则收尾、测试验证和 AIWorkflowEvalChecklist 复盘。

怪物行为装配

  1. 主定义装配入口EnemyDefinitionData 是怪物配置入口，负责把基础信息、动作集合和行为画像挂到同一份敌人定义上，让怪物差异先成为可配置对象。
  2. 基础面板独立EnemyInfoConfigData 只维护怪物身份和基础面板，例如 ID、名称、生命、防御、移动速度和冲刺速度，不夹带索敌、追击和攻击决策。
  3. 动作集合管理EnemyActionSetData 负责默认动作、动作列表和命中框观察配置，让普通怪、精英怪和 Boss 变体通过替换动作集合形成差异。
  4. 单个动作配置EnemyActionData 描述单个攻击或技能的前摇、活跃、恢复、释放距离、伤害、击退、碰撞盒、动画、冷却和选择权重，让一次出招能被复查。
  5. 行为参数拆分EnemyBehaviorProfileData 承接巡逻、索敌、追击、攻击决策、状态动画和受击反馈，决定敌人运行时如何从一个状态切到另一个状态。
  6. 运行时读取闭环EnemyDefinitionProvider 作为稳定读取入口，让执行、调试 HUD 和验收记录都能回到同一份怪物定义，定位问题来自字段、动作还是行为参数。

验证范围与结论

  • 验证范围战斗循环 / Ability / Buff / 怪物 / Boss / 工具
  • 验证方式公开视频 + 手动调试 + 命中框观察 + 自动测试
  • 当前结论已形成战斗系统结构闭环
  • 后续边界非完整商业化调优结论

迭代过程

  1. 收束项目目标/我先明确这不是展示型 Demo，而是一轮面向战斗策划转型的系统验证。
  2. 重构核心结构/我优先重组 Ability、Buff 和怪物配置结构，而不是先堆更多战斗内容。
  3. 补齐验证与协同回路/我把调试工具、自动测试和 AI 协同收尾放进同一条迭代流程，让结构验证真正闭环。

关键产出

  • 战斗系统结构样本留下 Ability、Buff、怪物与 Boss 的结构链路，证明样机价值不只在演示画面。
  • 组合式怪物配置方案把怪物基础信息、能力内容和 AI 参数拆开，为差异化与复用性保留扩展空间。
  • 验证与 AI 协同资产沉淀调试工具、自动测试入口、任务路由和复盘规则，让后续迭代更容易检查。

项目复盘

我真正验证的是战斗系统怎么被组织：这个项目对我最重要的价值，不是做出一个动作 Demo，而是确认我能从战斗端制作、系统拆解、配置组织和验证入口四个层面推进一个战斗样机。

验证工具让设计判断更可复盘：调试工具和自动测试不是开发附属物，而是让我能持续观察命中、状态、怪物行为和 Boss 阶段是否符合设计预期的证据入口。

AI 的价值在于协同结构而不是代劳：我更在意的是先把任务路由、文档边界、测试回路和复盘规则组织起来，再让 AI 进入这条链路，帮助实现和验证保持可管理。