Godot水墨3D动作游戏开发计划
版本：v1.1。日期：2026-09-05。状态：提交用户审阅的开发计划，尚未执行本计划。引擎固定Godot4.7.2＋GDScript＋Forward+；环境、依赖、代码、资产、动画、特效、声音、构建和基础QA由AI承担。v1.1补入母本制作合同与渲染／战斗约束，阶段和时间目标不变。
目标：先交一款能完整玩10—15分钟、能失败重开、能形成不同打法的水墨3D动作切片。前3—5个开发日先交人物、美术和打击反馈同时成立的短样片，目标10—15个开发日交完整短局。先证明核心品质和AI产线，再决定商业版内容规模。
工期是当前范围下的初步工程估算，置信度偏低，以连续有效执行且所需资产／依赖可取得为前提。D代表启动后的累计开发日，不是已安排的后台任务。P1完成后按实际制作耗时重估；未达验收线不以日期到达代替通过。
1．这次具体做什么
产品任务已给出中间裁决：拟选《暖雪》本体早期常规流派作为唯一玩法母本，保留近战、有限飞剑发射与召回、短瞬身、房间遭遇、局内构筑、Boss与失败重开。本计划据此编排；这是研究推荐，不冒充用户已确认某一游戏成品方案。
原作有2D产品分类及相关官方评选依据，不能推断其每个资产或内部制作管线。我们采用真实3D角色、环境与碰撞，按可见玩法结构重建体验。具体帧数、动画软件和隐藏系统仍以产品任务核验为准，不编造“原作参数”。
| 范围 | 首个完整切片交付 |
|---|---|
| 玩家身份 | 一名可直接操控的剑士，第三人称俯视斜角镜头 |
| 操作 | 移动、朝向、近战连击、飞剑发射、召回、瞬身；键鼠为首要实测输入 |
| 核心循环 | 进入遭遇 → 近战与飞剑配合清敌 → 选择强化 → 改变打法 → 挑战Boss → 结算或死亡重开 |
| 角色与流派 | 1名玩家角色、1个基础流派；用升级形成近战偏重和飞剑偏重两种可辨打法 |
| 敌人 | 3类普通敌人，分别强调近身压迫、远程预告和延迟重击；1个Boss，先做横扫、突进、砸地3种可辨招式与阶段变化 |
| 场景 | 1组林间古寺／渡口水墨场景模块；4种战斗房间模板重组约6处遭遇，另有补给、奖励、Boss节点 |
| 构筑 | 9个行为可见的升级效果，分为近战、飞剑、通用三组；不以全部加百分比充数 |
| 视听 | 角色、环境、攻击特效、命中、受击、危险预告、脚步、UI、环境与战斗音乐形成完整反馈 |
| 流程 | 标题、开始、暂停、音量、奖励选择、死亡、结算、重开；保存设置与已定义的局内恢复点 |
| 交付形态 | 先交可双击启动的Mac本地试玩；正式独立导出单列验收。Windows构建与运行验证分别记录 |
| 首版边界 | 本轮不加入搜打撤装备经济、联机、开放世界、复杂布料长发、剧情配音和运行时生成式AI |
学习成熟作品的交互与反馈结构，角色、名称、故事、地图、代码、画面和声音采用自制或明确授权来源。商业版的内容数量、定价与上市日期不在这份切片计划里提前承诺。
2．按什么顺序交付
| 阶段 | 初步时间 | 我交付什么 | 进入下一阶段的验收线 |
|---|---|---|---|
| P0：合同与执行基线 | D1前半 | 母本映射、首版范围、视觉目标、资源清单、项目与启动／导入脚本；解决正式导出依赖获取路径 | 一个清楚的交付合同；基础流程可重放；不要求用户配置任何软件 |
| P1：真实角色进入引擎 | D1—D2 | 真实蒙皮剑士、移动与朝向、骨架动作、一个目标、首条攻击；可双击的本地预览 | 角色不是几何占位；动作可切换，持物与脚底关系正确，输入可重复驱动 |
| P2：美术与战斗样片 | D3—D5 | 一处目标水墨场景，近战／飞剑／召回／瞬身基本配合，1类敌人、声音与命中反馈；60—90秒操作片段 | 正常速度下看得清、打得中、反馈明确；主角和场景达到同一美术标准，AI已完成基础QA后交用户审阅 |
| P3：内容与产线复用 | D6—D9 | 扩到3类敌人、Boss首版、房间模板；至少3个角色／敌人配置复用同一资产链 | 新单位能按同一流程导入、动作、运行；敌人行为不同；没有逐件依赖专业人工修理 |
| P4：完整一局 | D10—D12 | 遭遇编排、奖励选择、9个升级、两种打法、补给、死亡／胜利与重开；局内恢复点 | 从开始到失败／通关完整可玩，升级改变操作选择，重开无状态残留 |
| P5：修复与交付 | D13—D15 | 画面、打击、声音、性能与流程实改；完整试玩包、源工程、构建说明、运行证据与已知问题 | 独立导出实际启动，完整流程和高负载场景通过；没有把未测平台或主观品质冒充已通过 |
P2是第一道核心品质门。若角色／水墨观感或打击反馈失败，优先修复这一个最大失败点，暂停扩充房间和升级数量。工期随实测更新，不能用更多内容掩盖基础质量不足。
P5通过仅代表受限切片交付。之后用真实玩家验证操作理解、再次尝试与打法差异，再根据内容生产速度编制商业版范围；不会把这份15日目标外推成完整商业游戏工期。
3．我如何把环境全部包下来
| 工作 | AI负责的具体事项 | 当前状态 |
|---|---|---|
| 引擎 | 使用已核验的Godot标准版；固定版本、文件哈希与本地启动入口 | 引擎已就绪，原生基础检查已有证据 |
| 项目 | 独立目录、原始资产／加工资产分开、输入映射、版本记录、资源导入规则与错误日志 | 本计划未创建新游戏工程 |
| 资产依赖 | 查来源与体积，取得明确授权文件，统一格式／尺度／骨架，保留许可与失败记录 | 标准角色与动作候选已选，实际资产链未测 |
| 专业软件 | 第一条产线优先让Godot直接消费glTF／GLB；额外加工工具确有必要时由我准备和操作 | Blender不是要求用户准备的前置条件 |
| 运行与观测 | 我启动原生窗口，注入测试输入，观察状态、录屏、截图并检查实际画面 | 既有探针路径可复用，角色游戏仍需新验收 |
| 打包 | 我生成启动器、正式导出配置与发布文件，检查脱离项目目录后的运行 | 现有PCK只证明资源包加载，正式导出模板仍需准备 |
| 故障 | 我定位版本、导入、骨架、着色器和构建问题，保留失败证据并复测 | 不把错误截图交给用户当作待办 |
正式模板获取在P0查清，不拖到最后。最早预览可以复用现有Godot运行时，但要明确标为本地预览；这不能代替P5独立导出。现有官方全平台模板包约1.28GB，若确需下载，按用户已有规则报告准确对象、来源、大小与落盘位置后取得授权；用户不承担安装操作。本计划编制未下载该包或任何新模型资产。
4．3D人物与水墨美术如何落地
4.1固定资产链
| 工序 | 实现方式 | 实际交付与检查 |
|---|---|---|
| 主角基座 | Quaternius Universal Base Characters与同体系动作库；先保留合格骨架和权重 | glTF／GLB、骨架映射、动作清单；不把网站展示当已取得文件 |
| 古风外观 | 独立头饰、武器、衣装块面与统一材质，先用可控短衣装形成剪影 | 游戏摄像机距离能辨认角色；不能靠脸部特写或复杂飘带支撑设计 |
| 动画 | Skeleton3D、AnimationPlayer、AnimationTree；同一骨架映射与动作库复用 | 检查Bone Rest、缩放、脚滑、武器插槽、状态中断及受击切换 |
| 场景 | 模块化地形、石岸、木构、植被与前景遮挡；AI脚本生成或加工组合 | 可走区域、碰撞与画面一致；同类材质统一密度，角色被遮挡时仍可读 |
| 墨色 | 每类材质控制明暗、冷暖、浓淡和少量设色 | 灰度下能分清主体与背景；普通素材染黑不计通过 |
| 笔触与轮廓 | 物体空间锚定纹理；有选择的轮廓与边缘处理 | 横移、转身与远近变化时检查笔触爬动、闪烁及过粗描边 |
| 动态墨迹 | GPUParticles3D、程序网格轨迹、短寿命贴花与少量扭曲 | 攻击方向与命中点清楚；效果最大时仍能看见敌人和落点 |
| 纸感与雾 | 低强度纸纹、远景层次与局部雾化 | 不遮UI，不把全场变灰，不用噪点补充细节 |
Godot官方文档支持骨骼重定向和AnimationTree混合；骨名一致并不等于默认姿态一致，导入成功也不等于动作正确。本次需要实际验证这些环节。重定向文档、AnimationTree
4.2美术不是最后一周才加
P0整理少量目标参考并写明造型、构图、墨色与动态要求；P1直接使用真实角色基座。P2必须把同一处引擎场景做到可审阅的目标品质，之后复制的是已成立的制作规则。概念图和原生画面分开交付，不能用概念图的质量替运行效果背书。
优先修复顺序为轮廓与比例 → 动作与持物 → 构图与明暗 → 材质笔触 → 局部特效。每轮只解决实际画面中的最大问题，避免连续换工具或叠加后处理。
5．打击感如何做，怎么测
| 层次 | 具体实现 | 验收方式 |
|---|---|---|
| 输入与控制 | 短输入缓冲、允许取消的动作窗口、朝向规则、瞬身状态 | 连续输入、边移动边攻击、受击中输入与瞬身结束都可预期，不能吞输入或卡状态 |
| 动作时序 | 同一攻击时间线控制前摇、有效判定、后摇和可取消点 | 动作、碰撞和声音对齐；不会命中已经不在武器范围的目标 |
| 命中 | 近战扫掠／形状查询，飞剑连续路径检测；攻击实例与目标去重 | 测打空、擦边、多目标、高速穿过、暂停恢复；单次有效攻击按定义扣血 |
| 受击 | 按轻重与敌人状态配置硬直、位移、朝向与死亡 | 小怪有重量与反应；Boss抗性清楚，不能所有敌人一碰就飞 |
| 局部停顿 | 命中停顿服务于角色动作；UI、音频和镜头按独立规则更新 | 减少全局时间缩放造成的丢输入、音频异常与连续命中重复结算 |
| 镜头 | 小幅冲击、方向感与轻微跟随变化；强度可关闭 | 普通攻击不晃到看不清；多次命中时不无限叠加 |
| 声音与视觉 | 统一命中事件携带位置、材质、强度、伤害类型，驱动声音和墨迹 | 打空只有挥动声，命中才有接触层；伤害与预告不能互相混淆 |
首轮可以从短输入缓冲、几十毫秒命中停顿等范围开始调参，但所有具体数值都是本作实验参数，不冒称测得《暖雪》原值。交付普通速度与慢放片段，同时记录输入、判定和反馈事件，主观手感由实际试玩检验。
6．声音从P2就进入战斗
| 事件组 | 我制作或整合的声音 | 混音与检查 |
|---|---|---|
| 移动 | 石地／木地／土面脚步、瞬身起止 | 脚步跟随实际移动与接触，停止移动不继续响；少量变化避免机械重复 |
| 近战 | 不同攻击的挥动、接触、厚度与尾音 | 打空与命中分开；重击更有重量而非单纯增大音量 |
| 飞剑 | 发射、飞行、命中、召回归位 | 重复飞剑限制并发；召回完成可听辨，不把持续高频声铺满全程 |
| 敌人与Boss | 危险预告、受击、死亡与阶段变化 | 预告优先级高于装饰声音；方向与距离提供空间信息 |
| 奖励与UI | 获得、选择、确认、失败与胜利 | 短、明确，不与战斗警告混淆 |
| 场景与音乐 | 风、水、木构环境层；探索与战斗音乐段落 | 使用音乐、环境、战斗、UI总线；切换有过渡，长时间试听不过度疲劳 |
采用明确授权音源，经裁切、分层、包络、音高与音量变化形成统一声音。Kenney的Impact／Interface音源可作为基础候选，实际音质与适配仍需试听；不用普通蜂鸣声代替成品打击音，也不默认依赖付费音频生成服务。Impact Sounds、Interface Sounds、Godot音频总线
若当前工具只能检查波形、时序和削波而无法完成音频内容的实际试听，记录为“听觉复核未完成”，不声称已听过或音质达标。基础声音QA仍由AI承担，不要求用户先替我筛素材。
7．工程模块与依赖
| 模块 | 职责 | 不得混在一起的部分 |
|---|---|---|
| 输入与角色控制 | 输入缓冲、移动、朝向、动作状态和瞬身 | 输入状态与动画表现分开，降低失控与卡死风险 |
| 战斗规则 | 攻击定义、有效时段、伤害、无敌、硬直、攻击去重 | 判定先成立，再触发画面和声音；不能靠播放特效决定伤害 |
| 角色表现 | 骨架、AnimationTree、持物、受击与死亡 | 外观替换不能悄悄改变碰撞规则 |
| 飞剑 | 发射容量、轨迹、连续命中、召回与归位 | 每把飞剑有明确状态，死亡／重开时完全回收 |
| 敌人与Boss | 有限状态、距离判断、攻击预告、招式与阶段 | 不接LLM，不以不可复现对话逻辑决定战斗 |
| 房间与整局 | 遭遇生成、进度、奖励、恢复点、结算与重开 | 房间复用与整局状态分开，防止旧敌人和升级残留 |
| 升级 | 数据化效果、触发条件、上限与组合规则 | 限制递归触发与重复叠加；优先验证会改变打法的组合 |
| 视听反馈 | 镜头、墨迹、粒子、音频事件与并发预算 | 不占用游戏规则的唯一状态，不影响UI输入 |
| 测试与构建 | 调试场景、输入序列、运行日志、截图／录屏、导出 | 测试控制入口与发布版分开；发布时不保留任意代码执行通道 |
关键依赖顺序：角色导入与动画 → 攻击和命中 → 视听反馈 → 单个完整遭遇 → 内容复用 → 构筑和整局 → 独立导出与完整回归。美术规则在P2建立后随内容一起推进，声音也不留到收尾再做。
母本制作合同补入的实现约束
| 约束 | 本计划采用的处理 |
|---|---|
| 透明墨迹重叠可能排序错误 | 主体优先不透明材质，笔触优先可控的Alpha Scissor；半透明粒子保持短、小、少，先检查重叠再扩数量 |
| 全场纸感需要处理透明效果所在的渲染阶段 | 如需Compositor，单独验证POST_TRANSPARENT、窗口缩放与纹理生命周期；该实验接口作为补强项，不成为第一条角色产线的前置依赖 |
| 顿帧不能让动画与命中时间分离 | 战斗状态、有效窗与动画采用统一战斗时钟；手动推进动画时关闭其重复自动推进，输入、UI、音频和镜头仍用各自时钟 |
| 飞剑是资源，不是纯特效 | 首轮以6把为起调值，维持可用、飞出、停驻、返回数量守恒；死亡、跨房和重开统一回收，返回默认只恢复资源 |
| 命中与升级需要去重 | 攻击实例和目标组成去重键；回程伤害若以后加入须显式建立命中规则，派生事件不得无限触发自己 |
| 新载体不得偷偷扩首版规模 | 母本方案中的法印和武器配置只能复用已列9个升级效果；不额外增加职业、触发系统或动画产线 |
官方材料确认Godot透明排序的限制、Compositor的透明后回调和动画手动推进接口，但以上组合尚未在本作实现。透明排序限制、CompositorEffect、AnimationMixer
8．每版怎么验收
| 维度 | 必须出现的证据 |
|---|---|
| 功能 | 实际输入到状态变化；命中与未命中反例；瞬身、死亡、重开、恢复点不破坏规则 |
| 动画 | 普通速度、慢放、攻击取消与受击中断；脚滑、穿模和武器握持问题有处理记录 |
| 视觉 | 实际渲染窗口的静帧与连续运动；四种PC画幅检查主体、UI、预告与遮挡，不拿浏览器截图代替原生验证 |
| 打击感 | 同一段遭遇的输入、攻击有效期、命中与反馈同步记录；体验问题要实改后复测 |
| 内容生产 | 至少3个角色／敌人配置按同一流程交付；还要完成一次武器长度、攻击节奏与墨迹强度的指定修改 |
| 声音 | 实际事件触发、并发、过渡、削波与听觉复核状态，不能只证明音频文件存在 |
| 性能 | 目标1080p、60fps；在本机实际最重遭遇测试并报告帧时、对象与特效数量，空场景数据不能代替 |
| 稳定性 | 连续运行、反复死亡重开、暂停／恢复、读档；同一遭遇多次重置后对象与状态无持续残留 |
| 构建 | 从干净导出目录启动，脱离源项目路径仍可运行；完整走完教学、普通战、奖励与Boss |
| 玩法 | AI自测与用户审美反馈分开；后续邀请真实目标玩家观察无讲解理解、失败后再试和打法差异，不冒充留存或市场证明 |
首要实测设备是当前M5 Max。Windows、Steam Deck、手柄实机和低配机器需要各自的运行证据；可以先做构建或映射检查，但未拿到真实运行结果的项目继续标注未测，不能让用户承担第一轮平台QA。
9．分工、交付与停止线
| 责任 | 负责人 |
|---|---|
| 母本事实、玩法拆解与原作参数边界 | 现有产品研究任务；主任务检查是否可实现并落实到合同 |
| 环境、资产获取与处理、代码、3D、动画、水墨、打击感、声音、构建 | 我负责，不要求用户配置引擎、插件、SDK或建模软件 |
| 基础QA与发现问题后的修复复测 | 我负责，保留原始失败与最终运行证据 |
| 游戏想不想玩、审美是否接受、范围是否调整 | 用户试玩和反馈；不承担基础技术验收劳动 |
每个阶段交付一个可运行版本、短操作片段、实际完成项、仍未通过项与下一最大问题。源工程、资产清单、生成／加工脚本、构建命令与已知问题随版本保存，避免只剩一个无法维护的演示。
停止线只有具体失败：人物必须持续人工修理、目标美术未达标、核心操作始终不好玩、不可重复构建或性能超出目标。每轮集中修复最大失败点；持续失败时报告可复现原因和收缩方案，不自动改引擎、换母本或扩大工具采购。
当前工程状态：Godot环境与基础探针已完成；本计划中的角色产线、目标美术、动作反馈、整局与独立导出均尚未执行。当前正式Para工程与其合同不受本计划影响。
10．依据与追溯
- 当前Godot裁决（本地原档）
- 已完成原生基础实测（本地原档）
- 技术与资产全面研究（本地原档）
- 产品母本拆解任务入口（本地原档）
- 母本选择与制作总方案（本地原档）
- Godot制作技术合同（本地原档）
- 暖雪官方商店接口快照（本地原档）
母本方案与Godot制作合同已形成，最终观察与资料QA仍在补充。产品任务已对一段带剪辑的官方历史开发视频进行有限抽样；它不能提供当前版本精确取消窗、无敌帧或顿帧参数，声音也尚未完成听觉复核。本计划只吸收可核观察与明确标为本作起点的设计，不把这些材料写成原作内部实现或本作验收结果。