Steam Demo v0.1 · 剧情与开发计划
记录日期：2026-10-17。应用显示名为 《GZA：暴力电驴》，DAYUN-KICKER / dayun-kicker 继续作为技术标识。本文整理维护者提供的五幕方案，并将参谋建议与当前实现分开记录。
2026-10-18 更新：维护者同意按讨论建议先完善并提交文档，后续分阶段实现。第二主角的文档基线采用 周远（小周）；三人的动机与成长方向、客观平行世界及可核对物证写入 人物设定 和 世界设计与实现顺序。本轮为设计更新，不表示新剧情或世界已经接入运行版本。
已暂定： Godot 完整 3D、低多边形建模基础、适度漫画渲染与广州街坊光色；先做 10–15 分钟垂直切片，再扩展为 45–60 分钟离线单人 Demo。
规划基线： 两个世界、两名可操作主角、阿榕作为重要 NPC、五幕主线与一次跨世界逃生。首位主角确定为 34 岁的失业程序员大云；第二主角为 22 岁、毕业后因家庭矛盾离乡来广州打工的青年；阿榕是父亲失踪的广州本地摄影师。已明确信息、动机建议与未定项见 Demo 人物设定。人物能力、世界规则、与《粥还热》的具体衔接仍需切片验证。18 周是待校准的相对排期，不是已承诺的发布日期；Demo v0.1 是内容规划标签，不自动更改工程版本或存档版本。
本文未实施新剧情、角色或世界系统，也未创建远程 Issues、里程碑或发布构建。现有 Godot《粥还热》候选继续作为可运行基线；双宿主职责、资源和发行验收仍遵循 Godot 迁移计划。
执行任务、优先级、依赖与勾选状态统一维护在 游戏开发待办。本文保存产品设计、剧情讨论和估算，不另维护同一批任务的完成状态。
1. 美术默认方向
采用“低多边形体块 + 克制的漫画动作表达 + 温暖的广州街坊光色”：
- 建筑、车辆、树木和街道设施延续现有程序建模，优先统一比例、轮廓、倒角、材质与模块复用。
- 人物、车辆、敌人与交互物通过清楚的轮廓和分档明暗保持可读；背景减少细碎墨线与密集网点。
- 日常世界以奶油色瓷砖、砖红、榕树绿、青绿遮阳篷和暖光建立生活气息。异世界复用地标与街巷，通过环境声、灯光、封路与少量变体物件制造差异，避免只靠全屏压暗表达危险。
- 踢击用短促闪光、动作弧线和夸张物理突出荒诞感；速度线和强烈视觉效果主要服务动作瞬间，并服从减少动态效果设置。
- 先精修骑手站、粥店与异常锚点附近的一段可玩街景。概念图中的店铺密度、树冠和立面细节属于资产制作工作，不视为已有实时效果或性能承诺。
本次五张生成概念图用于内部方向讨论，原图与提示词保存在源码工作区的忽略目录 artifacts.local/concept-art-2026-10-17/，不作为构建依赖或公开文档图片。若后续选为正式媒体，按 COS 资源流程发布和校验。既有画面实现与历史边界见 卡通画面氛围。
2. 产品范围
| 项目 | v0.1 范围 |
|---|---|
| 目标时长 | 新玩家首次正常游玩 45–60 分钟，排除长时间闲逛；以实测分布校准 |
| 主线 | 序幕、第一至第三幕、终幕，共五幕 |
| 世界 | 现实广州与丧尸平行广州；共享基础地图，剧情控制切换 |
| 可操作角色 | 大云，34 岁失业程序员，开场由玩家操控并到陈叔处注册外卖员；周远（小周），22 岁，刚毕业、因职业选择与家人产生矛盾后离乡来广州打工，具体工作待定；先只在指定剧情节点切换 |
| 重要 NPC | 女主角阿榕，广州本地摄影师，父亲是失踪的摩托车修理师傅；通过配送参与街坊摄影专题、接触父亲旧客，并因新线索主动追寻父亲；Demo 中不开放自由操控 |
| 平台 | 优先 Steam Windows x64 离线单人；macOS 用于当前开发与回归，发行声明另验收 |
| 开发方式 | 先完成可玩切片；新系统在 Godot 实现，Web 只选择适合展示的片段 |
维护者补充三人的偏好与内心故事可以关联平行世界：大云喜欢科幻，首个进入丧尸世界；喜欢漫画的青年与怀旧的阿榕分别对应后续漫画风、怀旧岭南风世界的候选方向。长线设想见 平行世界与人物内心，当前 Demo 保持现实 / 丧尸两世界，后续世界的因果与机制未定。
P0： 城市探索、完整配送、电动车骑行与导航、角色对话、剧情切换两名主角、受控世界切换、基础感染者遭遇、基础近战与躲避、必要物资拾取、检查点与存档、完整通关及 Steam Demo 构建。
P1： 城市支线、额外收集与自由角色切换。自由切换不是第一幕首次剧情切换的前置条件。
P2 / 暂缓： 多人合作、额外世界、完整广州开放世界、复杂经济、自由穿越、赛博世界、第三名主角完整控制与技能树。已有对应系统不因此被删除，但不绑到本 Demo 交付。
3. 五幕原案与验收
以下保留原案名称与标称时长；8 + 12 + 10 + 18 + 12 = 60 分钟，已占目标上限，尚未给新手摸索、失败重试与探索留空间。不能把这一相加结果当作试玩时长已达标。
| 幕 | 原案时长 | 剧情与主要操作 | 发布不可缺少的验收 |
|---|---|---|---|
| 序幕：今天不用加班了 | 8 分钟 | 玩家操控失业后的大云，从办公室外与手机消息开始，步行到陈叔处注册外卖员、领取电动车；背景随行动揭露 | 不读外部教程即可完成移动与交互，理解为何开始配送；不靠大段开场独白交代全部过去 |
| 第一幕：您的订单即将超时 | 12 分钟 | 接单、取餐、导航、订单计时、碰撞相遇、首次切换角色 | 完成至少一笔真实配送；认识外乡青年；切换后目标、车辆和任务状态正确 |
| 第二幕：不存在的收货人 | 10 分钟 | 异常订单、阿榕与调查影像、广州塔锚点、空间异常、首次世界切换 | 通过受控锚点到达同一城市的异世界；位置、朝向与任务延续遵守切换契约 |
| 第三幕：这里不是广州 | 18 分钟 | 躲避 / 潜行、拾取、巡逻与追击、基础近战、简易避难所 | 战斗或躲避均可完成必要目标；敌人寻路与同伴掉队不造成任务死锁 |
| 终幕：最后一单 | 12 分钟 | 程序员解析信号、阿榕指路、青年首次破界、限时逃生、父亲影像与片尾 | 完整逃生；失败可从终幕检查点重试；片尾悬念与试玩结束页可达 |
开发顺序以依赖和风险为准，先做第一幕配送与异常切换原型，不按五幕顺序逐个堆完资源。
参谋建议：把故事拴在“订单”上
- 一个主问题贯穿五幕。 “这一单究竟要送给谁、送到哪一个广州？”可作为工作中的叙事钩子。失业、相识、调查和逃生都围绕订单推进，减少互不相干的开场介绍。
- 让主角分工产生操作差异。 程序员负责识别、整理和解读空间信号；外乡青年负责在关键节点对锚点采取行动、完成破界；阿榕负责影像证据、地标辨识和道路引导。具体身份与能力由后续剧情确定；不先做技能树或编程小游戏。
- 首次切换要解决眼前的问题。 碰撞相遇后让玩家分别完成一个短操作，共用步行、交互和骑行基础。避免只换模型、再看一段对话；也不让未操控角色必须实时赶路才能继续。
- 异常应更早露头。 原案约在第 30 分钟才完成首次跨世界。建议开场数分钟就留下可辨认的异常线索，并压缩铺垫，使首个可操作切换有机会在 10–15 分钟内出现。具体是否调整正式五幕时间，待首轮实玩定稿；切片可先截取和压缩这一段。
- 保留具体的人情牵挂。 《粥还热》的粥店、阿婆、陈叔、骑手站和救援可作为复用素材，让危机影响玩家认识的人。同一门口、招牌与路线在两世界中的变化，比新增大片废墟更有意义；不要求把原七单再完整玩一遍。
- 终幕能力提前铺垫。 青年正式破界留在终幕，但此前出现可观察、可试探的反应，让玩家知道要做什么，避免结尾突然获得一项未经表达的能力。
- 只用一条主要限时压力。 普通订单计时先给宽限与可理解的后果；异常调查和关键对话不被配送超时反复打断。终幕承担明确的逃生倒计时，暂停 / 对话 / 加载如何冻结须统一，失败从近处检查点重试。
以上是建议，不代表新增对白、世界观因果或能力规则已经确定。
4. 先做的 10–15 分钟垂直切片
切片应同时验证故事、驾驶、角色切换、一次世界切换与最小生存操作。只做配送加转场视频，无法验证完整方案。
| 连续步骤 | 暂定时长 | 要验证的内容 |
|---|---|---|
| 最短步行 / 交互引入 | 1–2 分钟 | 无文档引导、明确接单动机 |
| 一次接单 → 取餐 → 骑行 → 停稳交付 | 4–5 分钟 | 现有驾驶与导航是否支撑叙事节奏 |
| 相遇与一次剧情角色切换 | 1–2 分钟 | 角色有明确分工，输入、相机和任务不丢状态 |
| 异常订单 / 影像线索与接近锚点 | 1–2 分钟 | 玩家是否理解异常并愿意继续 |
| 可恢复的世界切换 | 约 1 分钟 | 共享位置、转场、加载失败与存档边界 |
| 一小段躲避 / 踢退与到达安全点 | 2–3 分钟 | 一种感染者、基础近战、失败重试和收尾 |
合计约 10–15 分钟，只是设计配额。先复用 客村 / TIT 骑手站的一段现成配送路线；广州塔作为正式剧情锚点保留。若塔边走廊尚不能满足这段节奏，先用现有安全点做开发锚点验证技术，不提前锁定塔边整片街区或扩大精修范围。
切片出口：新档连续可玩、两名角色各完成一次有意义的操作、切换前后检查点可跨进程恢复、最小遭遇可用战斗或躲避通过。收集新玩家完成时间、迷路点、死亡 / 重试、角色与世界规则理解情况，并检查选定样板街景的实际画面与既有性能门槛。
5. 现有 Godot 基础与新增缺口
2026-10-17 只读盘点了当前工程、内容链路和相关测试入口；本次未运行游戏、性能测试或发行构建，以下不等同于完整技术审计或验收通过。 Web / 实验工程的能力不自动算作原生能力。
| 模块 | 当前可复用的原生基础 | Demo 新增 / 待验证 |
|---|---|---|
| 工程与地图 | 原生生产工程、固定章节地图包、程序美术 GLB 导出、路网与碰撞 | 切片边界、双世界变体与资源生命周期；当前不是运行时流式整城 |
| 控制与驾驶 | 步行、上下车、骑行、第一 / 第三人称、键鼠 / 合成手柄路径 | 两主角身份、切换时输入 / 相机 / 停车状态；实体手柄验收 |
| 配送与导航 | 接取送、停稳交互、任务门槛、导航及职业进度 | 异常订单、跨世界订单状态与失败 / 宽限规则 |
| 剧情 | 《粥还热》JSON 节点图、对白执行器、条件、计时和宿主校验 | 五幕内容、跨章与跨世界事实、角色切换事件及恢复 |
| 感染者 | 章节事件生成、近距追逐、接触减速、踢退与持久化状态 | 巡逻 / 感知 / 丢失目标、潜行、步行近战、防御、伤害与可靠脱困 |
| 存档 | schema 2、内容版本、章节游标、原子写入、备份和未来版本保护 | 世界变体、主角与同伴、必要物资、转场提交与新旧内容兼容 |
| UI / 声音 / 画面 | HUD、地图、菜单、设置、音频与三种画面风格 | 双主角 / 双世界提示、异常声景、明确的低多边形漫画样板 |
| 测试与导出 | 规则、连续章节、恢复、原生窗口测试与 macOS / Windows 导出链路 | 新剧情端到端、目标 Windows 实机、实体手柄、Steam Demo 分发与完整通关 |
现有章节感染者的“追逐 + 接触减速 + 踢退”不能直接算作第三幕所需的完整生存战斗。现有共享单车、夜游和环境车流可按任务价值复用，不另立为 Demo 必做模块。
6. 技术落地原则
保留单一 Godot 游戏工程与现有目录。autoload/、actors/、systems/、worlds/、chapters/ 是职责示意，不作为强制搬目录的任务；也不为每项职责新增全局单例。
| 职责 | 复用 / 扩展路径 |
|---|---|
| 会话与输入 | 扩展当前 GameSession；同一时刻只有一个受控角色和一个物理控制权威 |
| 剧情与任务 | 继续使用 dayun-kicker-content 的手写 JSON 与现有构建 / 节点执行链路；新 Demo 使用独立内容 ID，保留旧章 |
| Resource 的用途 | 可作为 Godot 侧生成数据或场景绑定的承载形式，不建立与共享 JSON 并行的第二套手写任务真相 |
| 角色 | 共用移动、交互、骑行与基础动画接口；身份和能力用数据 / 小组件表达，不复制两套控制器 |
| 世界 | 基础道路、坐标和稳定实体 ID 共用；现实 / 感染变体覆盖环境、道具、敌人与必要通路状态 |
| 战斗 | 从一种感染者和一种基础近战动作开始，关键任务不依赖随机刷怪或 NPC 恰好走到某点 |
| 存档 | 扩展当前白名单状态与版本迁移；不序列化场景树，不把内容版本冒充世界变体 ID |
| 内容分工 | 规则规格和 fixtures 共用；新玩法先在 Godot 验收，Web 不承担五幕同步实现 |
世界切换的最小契约
- 只在剧情允许且可停稳的锚点发起；冻结输入和模拟计时，记录源世界、角色、车辆、任务与检查点。
- 请求目标变体并验证资源、碰撞和必要任务点。可使用预加载与遮挡转场；不同时常驻两套完整城市，不先承诺完全无缝或通用地图分块。
- 锚点在两世界中保持相同可站立空间，以保持角色位置和朝向。若目标空间无法满足契约，转场失败并恢复源世界 / 检查点，不静默传送到任意位置。
- 目标可玩后一次性提交世界、任务与控制角色；转场触发和奖励必须幂等。加载失败、重复交互或退出重开不能得到一半现实一半感染的状态。
- 在源世界检查点和已提交的目标检查点保存；中途退出回到最近已提交状态。覆盖角色在车上 / 步行、重复触发、资源失败、读档和取消输入。
世界视觉变化必须与敌人、碰撞、导航和交互状态一致，不能只切滤镜。目标变体是否需要重新生成局部寻路、车辆是否随行、同伴如何到达均在切片内明确。
建议的新增持久状态职责包括内容 ID / 版本、章节与节点、世界变体 ID、当前主角、各角色和车辆状态、关键物资、世界事实与已提交检查点；具体字段名和 schema 版本等实现设计后再定。
7. 工作量原估与校准
| 模块 | 优先级 | 原估人日 |
|---|---|---|
| 现有 Godot 项目审计 | P0 | 3–5 |
| 角色控制与摄像机整合 | P0 | 5–8 |
| 电动车驾驶与导航 | P0 | 8–12 |
| 任务、对话、触发器框架 | P0 | 10–15 |
| 现实 / 末日世界切换 | P0 | 8–12 |
| 丧尸 AI 与基础战斗 | P0 | 12–18 |
| 五幕剧情、演出与事件 | P0 | 20–30 |
| UI、音效、存档与设置 | P0 | 10–15 |
| Steam 构建、测试与优化 | P0 | 12–20 |
| P0 合计 | 88–135 | |
| 城市支线与收集 | P1 | 6–10 |
| 自由角色切换 | P1 | 4–7 |
| 多人合作与额外世界 | P2 | 暂缓 |
原估不含完整美术资产生产、配音和大规模场景重建，也不含表外 P1。现有系统应按“复用 / 增量开发 / 验证”重新拆分，避免把驾驶、存档和任务框架全部重新估为从零开发；尚未实现的能力也不能仅凭 Web 或实验版本直接扣除。
18 周按每周 5 工作日约为单人 90 人日，只能覆盖原估下沿，且未扣沟通、返工、测试支持或加入美术工作。W1–W2 应补团队实际投入、资产清单、目标设备和风险储备，再校准排期；不按 AI 工具数量折算可并行的人日。
8. 18 周相对里程碑
| 周次 | 交付重点 | 阶段出口 |
|---|---|---|
| W1–W2 | 技术审计、范围冻结、样板街景与目标设备基线 | 当前可运行版本、复用清单、缺口与第一切片范围可复现 |
| W3–W5 | 配送、相遇、剧情换角、异常、世界切换及最小遭遇 | 10–15 分钟连续切片，保存 / 重试闭环和初轮新玩家反馈 |
| W6–W9 | 感染变体、一种感染者、基础战斗 / 躲避、物资与逃生 | 双世界玩法闭环，关键任务具备恢复路径 |
| W10–W13 | 补齐五幕、必要演出、终幕、结局与存档 | 新档可完整通关，时长经实玩校准 |
| W14–W16 | 操作、性能、剧情节奏、声音、可用性与回归 | 严重阻断消除；目标设备和输入验证有证据 |
| W17–W18 | Steam Demo 候选、商店素材、测试分支与发布检查 | 独立包离线可玩、存档可恢复、全程可通关，平台审核与发布条件满足 |
构建与 Windows 运行冒烟应从第一切片开始，不能等 W17 才首次导出或测试；平台审核和外部等待单独跟踪，不保证固定周数内完成。
未过阶段出口时先缩场景面积、支线和演出复杂度，保留两主角、双世界与逃生的核心验证。若核心切换或战斗仍不成立，应重新评估范围与日期；不能用取消试玩目标或降低稳定性门槛假装完成。
性能按 游戏性能手册 和 渲染记录执行。保持已有画质、实际缓冲、物理和资源预算；报告 P95 / P99、长帧、CPU、真实就绪与切换峰值资源，不把概念图、导出成功或局部帧率当作发布验收。
9. Sprint 01 · 第一周任务
任务已拆入 游戏开发待办 · B0 基线与范围，以该处状态为准。第一周优先冻结基线、完成复用审计、明确角色 / 世界规则、选定最小路线与资产、建立每周候选构建。随后按 V1 依赖整合配送、换角、异常订单、世界切换和最小遭遇。
本次只读初盘与任务整理不代表完整审计或功能已经完成；GitHub Issues / 里程碑可沿稳定任务 ID 关联，远程创建和派发另行执行。
10. 后续待明确的问题
- 大云的房租压力与背景揭露如何呈现；周远的专业、当前工作、一次具体家庭争执与换角动机；破界的前兆、触发条件和限制。
- 阿榕摄影专题的具体切入点、父亲失踪时间与第一条有效线索；她全程参与的表现形式是现场同行、影像 / 通话还是分段会合，以及如何避免持续护送成本。详细已知与未定项见 人物设定。
- 世界切换是否携带电驴、同伴与物资；两世界的时钟、可见线索与局部状态如何对应。
- 《粥还热》的事件哪些直接复用、哪些改写；阿婆救援与感染者分别发生在哪个世界。新世界规则不能直接等同于旧章的
outbreakSeen标记。 - 破界逃生回到原现实还是第三种状态；父亲影像揭示一个明确事实，并留下哪一个长线问题。
- 发布版首个世界切换的目标时间、必要探索空间、目标 Windows 设备、实体手柄、团队投入与美术资源工时。
这些问题可随切片逐项解决，不阻止复用现有系统；会影响实现的规则需在对应模块开工前写入数据和验收规格。