ChildHood/docs/technical/技术可行性评估.md

技术可行性评估 — ChildHood

评估日期：2026-06-04 评估基于：concept.md + 全部设计文档（13 份） 引擎版本：UE 5.7.4 评估人：程序 Agent

---

总体结论

技术可行性：通过。有条件通过。

ChildHood 的所有核心系统在 UE5.7.4 中均有成熟的实现路径，不存在引擎层面的硬性技术障碍。主要风险集中在单人开发的内容量和小游戏的实现深度上，而非技术可行性本身。

前提条件：

1. 严格控制小游戏范围：弹珠和四驱车必须作为独立迭代周期，每个小游戏系统单独验证后再扩展。同时开发多个小游戏是单人开发的最大风险。
2. 分阶段验证核心假设：v0.1 验证探索感、v0.2 验证小游戏可玩性、v0.3 验证时间循环节奏。任一阶段验证失败需要调整后续范围。
3. 善用 UE5 内置系统和 Marketplace 资产：不重复造轮子，第三方资产和插件在必要时引入以节省工期。
4. 叙事文本和美术资产是隐性工作量最大的部分：25+ 交互对象的叙事文本、7 个 NPC 的对话树、全场景的 Lowpoly 资产——这些"非代码"工作可能比系统实现更耗时。

---

技术栈推荐

UE5 功能模块与架构

层次	推荐方案	理由
角色控制	ACharacter + Enhanced Input System + SpringArm	项目已有 ChildHoodCharacter 基类，Enhanced Input 是 UE5 标配，SpringArm + Camera 实现第三人称跟随
交互系统	C++ Interface (Interactable) + SphereOverlap 检测 + UMG Widget	接口模式天然支持多类型交互物，SphereOverlap 简单高效，UMG 做提示和文本 UI
场景构建	子关卡（SubLevel）/ Data Layer 管理区域加载	完整版 ~150m x 120m 不大，可用单关卡，但子关卡便于管理和按需加载
NPC 系统	StateTree（项目已启用）+ 行为树辅助	StateTree 是 UE5 推荐的 AI 框架，项目已启用插件；简单 NPC 也可以纯 Blueprint
UI 系统	UMG (Unreal Motion Graphics)	UE5 标准 UI 框架，适合图鉴、对话、小游戏 UI
数据驱动	DataAsset + DataTable	配置收集品属性、交互物数据、NPC 数据；与 GameConfig/ 目录的 CSV/JSON 对应
动画系统	Animation Blueprint + Blendspace + State Machine	标准 UE5 动画方案，Lowpoly 角色动画简单，Blend Space 处理 Walk/Run 混合
光影 / 时间	Directional Light + Skybox + PostProcess Volume	四时段光影切换用 Directional Light 的 Rotation/Intensity + Skybox 材质变化
物理	Chaos Physics（引擎内置）	弹珠碰撞、拍洋画的卡片翻转——引擎内置 Chaos 物理足够
小游戏	独立 GameMode + 独立 PlayerController	每个小游戏进入时切换 GameMode/PC，隔离逻辑，互不干扰
音频	UE5 Audio System + Audio Volume 分区	引擎内置音频系统支持空间音、背景音、分区音量，满足需求
存档	USaveGame + SaveGameToSlot	UE5 标准存档方案，收集进度、时间进度、剧情状态均可序列化

不推荐使用的系统

系统	原因
GameplayAbilitySystem (GAS)	本游戏无战斗、无技能、无 Buff/Debuff，GAS 引入的复杂度远超收益
Niagara（复杂粒子）	Lowpoly 风格不需要高端粒子效果，简单的 Cascade/材质动画即可
MassEntity / ECS	场景 NPC 仅 7 个，不需要大规模实体管理
Lumen 全局光照	Lowpoly 风格不需要，且对性能有较大影响；用烘焙光照或简单动态光即可
Nanite	Lowpoly 资产面数极低（道具 < 500，角色 < 3000），Nanite 的优势无法发挥

推荐的项目架构

Source/ChildHood/
├── Core/                    # 游戏核心框架
│   ├── ChildHoodGameMode    # 主游戏模式
│   ├── ChildHoodGameState   # 全局状态（时间、天气）
│   └── ChildHoodSaveGame    # 存档系统
├── Player/                  # 玩家相关
│   ├── CHPlayerController   # 主控制器（交互、UI管理）
│   ├── CHCharacter          # 主角（移动、动画）
│   └── CHCameraManager      # 摄像机管理（推镜等）
├── Interaction/             # 交互系统
│   ├── InteractableInterface# 交互接口
│   ├── InteractableComponent# 交互组件（可附着到任何Actor）
│   └── InteractionDetector  # 检测最近的交互物
├── Collection/              # 收集系统
│   ├── CollectionManager    # 收集进度管理
│   ├── CollectionDataAsset  # 收集品数据定义
│   └── CollectionUI         # 图鉴UI
├── NPC/                     # NPC系统
│   ├── CHNPC                # NPC基类
│   ├── NPCScheduleComponent# 时段位置调度
│   └── DialogueComponent   # 对话管理
├── Time/                    # 时间系统
│   └── TimeManager          # 四时段管理、光影联动
├── Narrative/               # 叙事系统
│   ├── EventManager         # 事件触发管理
│   └── QuestManager         # 链式任务管理
├── Minigames/               # 小游戏系统
│   ├── Common/              # 共享框架
│   ├── Marble/              # 弹珠
│   ├── CardFlip/            # 拍洋画
│   ├── Mini4WD/             # 四驱车
│   └── RetroGame/           # FC/街机/PC
└── Economy/                 # 经济系统
    └── EconomyManager       # 零花钱、交易

---

系统逐一评估

1. 角色控制器

• 技术可行性：UE5 原生完整支持。项目已有 AChildHoodCharacter 基类（继承 ACharacter，已配置 SpringArm + FollowCamera），已有 AChildHoodPlayerController（已配置 Enhanced Input 的 IMC/IA 框架）。WASD 移动、鼠标视角、Shift 跑步均为 Enhanced Input 的标准映射，零自定义引擎代码即可实现。
• 实现复杂度：低
• 技术风险点：
  • 蹲下系统需要额外的胶囊体高度切换逻辑和 Crouch 状态的 Blendspace，但这是 UE5 Character Movement Component 的标准功能
  • 摄像机碰撞穿墙需要 SpringArm 的 Collision Test 或自定义 Camera Blocking Volume，工作量为配置级别
• 推荐方案：C++ 基类（已有）+ Blueprint 配置 IMC/IA 资产。Crouch/跑步在 C++ 中用 GetCharacterMovement()->bWantsToCrouch / MaxWalkSpeed 切换，动画混合在 Blueprint 的 AnimBP 中处理。
• 工期预估：v0.1 核心 2-3 天（已有框架），完整版 5-7 天（含蹲下、惯性、碰撞优化）
• 第三方需求：无

2. 交互系统

• 技术可行性：UE5 完全支持，无引擎限制。核心是 SphereOverlap 多播检测 + Interface 多态 + UMG Widget 显示。推镜相机用 Timelines 或 Simple Move To 实现相机平滑移动。
• 实现复杂度：中。4 种交互类型（观察/拾取/操作/对话）各有不同表现逻辑，但共享触发框架。
• 技术风险点：
  • 多交互物共存时"只显示最近一个"的逻辑——需要排序和优先级判断，但不复杂
  • 推镜相机的目标位置计算（物体前方 0.8-1m、微仰视）——需要考虑物体朝向和空间关系，某些场景中可能推镜位置不理想（如贴墙物体）
  • 交互中角色转向 + 移动限制的同步——用 Gameplay Tag 或状态标记管理
  • 打字机效果的 UI 文本——UMG TextBlock + Tick 或 Timer 逐字显示，标准实现
• 推荐方案：C++ 实现 InteractableInterface + InteractableComponent（核心逻辑），Blueprint 继承配置具体交互物数据。推镜逻辑用 C++ Timeline Controller。UI 用 UMG Blueprint。
• 工期预估：核心框架 3-4 天，填充 25+ 交互物数据 2-3 天，调试推镜 2-3 天，合计 7-10 天
• 第三方需求：无

3. 场景白盒

• 技术可行性：UE5 BSP/Modeling Mode 原生支持白盒搭建。80m x 60m（v0.1）到 150m x 120m（完整版）均为单关卡可承载的规模，不需要 World Partition 或 Level Streaming。
• 实现复杂度：低（技术层面），中（设计/布局层面）
• 技术风险点：
  • 场景布局和空间节奏需要反复调试——这不是技术问题而是体验设计问题，但会占用大量迭代时间
  • 6 区域连通性和流线——需要确保玩家不会迷路也不会觉得局促，需多次 Playtest
  • 室内空间（家、小卖部等）的 LOD 和碰撞——Lowpoly 模型简单，不是问题
• 推荐方案：UE5 Modeling Mode（已启用 ModelingToolsEditorMode 插件）直接在编辑器中白盒搭建。用 BSP 基本体 + 简单材质颜色区分区域。收集免费的 Lowpoly Starter Content 或 Marketplace 免费资产作为占位模型。
• 工期预估：v0.1 白盒 3-4 天，完整版场景（含室内）15-20 天
• 第三方需求：建议使用 Marketplace 免费 Lowpoly 资产包（如 Low Poly Megapack 等）作为白盒占位

4. 收集系统

• 技术可行性：UE5 完全支持。基础拾取是交互系统的一个子类型（InteractableInterface 的 PickUp 实现），计数用 GameState 或 SaveGame 中的 Map/TArray 存储。扩展到四类收集品 + 图鉴 UI 后，需要 DataAsset 定义收集品数据和 UMG 构建图鉴界面。
• 实现复杂度：低（v0.1 基础拾取）→ 中（完整版四类 + 图鉴 + 世界反馈）
• 技术风险点：
  • 图鉴 UI 中 3D 模型展示——需要 Render Target 或单独的 3D 场景渲染到 UI，UE5 支持有成熟方案（Widget 中的 Scene Capture 2D）
  • 收集品与小游戏系统的联动——弹珠既是收集品又是道具，需要统一的 Inventory Manager 来管理数量和属性
  • 收集进度驱动的世界反馈（NPC 对话变化、称号系统）——需要在 NPC 对话系统中加入条件判断，增加耦合度
• 推荐方案：C++ 实现 CollectionManager（Subsystem 或 GameState 中的组件），DataAsset 定义收集品元数据（名称、描述、稀有度、分类），SaveGame 序列化进度。图鉴 UI 用 UMG。
• 工期预估：v0.1 基础拾取 1-2 天（随交互系统一起），完整收集系统 10-15 天
• 第三方需求：无

5. 小游戏系统

这是技术评估的核心重点。小游戏系统包含多个独立子系统，复杂度和工作量差异极大。

5.1 弹珠（四维策略系统）

• 技术可行性：技术上可行，但需要自定义较多。物理碰撞用 Chaos Physics，策略系统用 DataAsset 配置，操作手感是最大挑战。
• 实现复杂度：高
• 技术风险点：
  • 操作手感是核心难题：弹珠的"弹射"操作需要映射到手柄/键鼠。设计文档提到"角度 + 力度"，可能的方案有：(a) 类高尔夫游戏的蓄力条 + 方向控制，(b) 类台球游戏的瞄准线 + 力度，(c) 触屏拖拽弹射的键鼠适配。操作方案的选择直接影响可玩性，需要原型验证
  • 物理模拟的调参：弹珠在不同材质地面（水泥/泥土/草地）的滚动、碰撞弹飞效果需要反复调参，Chaos 物理参数对微小物体（弹珠半径约 1cm UE 单位）的数值敏感度需要测试
  • 四维策略的平衡性：规则 x 场地 x 弹珠属性 x 手法的组合空间大，平衡性需要大量 Playtest，这超出了技术范畴但会影响开发周期
  • NPC AI 决策：NPC 如何选择弹珠和手法，需要简单的效用系统或规则引擎
• 推荐方案：独立 C++ GameMode + PlayerController（弹珠专用），Chaos 物理处理碰撞，Blueprint 做操作 UI（瞄准、蓄力条）。先做操作手感的 Throwaway 原型（1-2 天），验证操作方案后再正式实现。
• 工期预估：原型验证 3-5 天，正式实现 15-25 天（含四维策略、NPC AI、与收集系统联动）
• 第三方需求：可能需要物理调试工具插件

5.2 拍洋画

• 技术可行性：与弹珠共享模板，物理模拟从滚动改为气流 + 卡片翻转。技术上更简单。
• 实现复杂度：中（复用弹珠框架降低复杂度）
• 技术风险点：
  • 气流和震动的物理模拟——可能需要简化为动画驱动而非真实物理
  • 卡片翻转的视觉表现——多张卡片叠加的翻转效果需要精心设计
• 推荐方案：继承弹珠共享模板（角度 + 力度操作），物理部分简化为预设动画 + 随机结果权重。
• 工期预估：8-12 天（在弹珠系统完成基础上）
• 第三方需求：无

5.3 四驱车（改装调试系统）

• 技术可行性：UE5 支持，但系统设计跨度大——UI 密集的改装界面 + 物理驱动的赛道比赛。改装 UI 本质是一个复杂的 Widget 交互系统。
• 实现复杂度：高
• 技术风险点：
  • 改装 UI 的复杂度：6 种部件各有多项属性，UI 需要直观展示改装效果（可能需要 3D 预览）。这是本系统中工作量最大的部分
  • 赛道物理：四驱车在赛道上的行驶物理——如果做真实的赛道行驶（弯道、跳跃、碰撞），物理调参量大；如果简化为预设路径 + 速度对比，则工作量可控
  • 改装效果的可感知性：玩家改了一个马达，需要在赛道上"感觉得到"差异——数值差异要转化为可感知的视觉/速度差异
• 推荐方案：C++ 实现 CarConfig DataAsset（部件属性）+ 改装 UI 用 UMG。赛道比赛用简化的物理：预设路径 + 速度/稳定性参数影响过弯和跳跃表现，而非完全物理模拟。
• 工期预估：15-25 天（含改装 UI、赛道系统、与收集系统联动）
• 第三方需求：无

5.4 FC 家用机 / 街机 / PC（游戏中的游戏）

• 技术可行性：技术上完全可行，本质是在 UE5 中实现小型 2D 游戏。FC/街机用 2D PaperZD 或 3D Lowpoly 做像素风格，RTS 用简化版 UI + 简单 AI。
• 实现复杂度：高（不是技术复杂，而是内容量大）
• 技术风险点：
  • 内容量是真正的风险：每种类型 3-5 关，FC 横版 + FC 清版 + 街机清版 + 街机格斗 + PC RTS = 5 个独立小游戏，每个有自己的关卡设计、敌人 AI、数值平衡。单人开发的工作量巨大
  • 像素风 vs Lowpoly 的选择：设计文档提到"用 3D Lowpoly 呈现 FC 的像素感"——这个视觉风格的实现需要特别设计，不是简单的 Lowpoly 化
  • 格斗游戏的 AI：即使简化版，格斗 AI（出招选择、距离判断）也需要一定工作量
• 推荐方案：每个小游戏独立 GameMode + 关卡。FC 横版/清版共享基础框架（角色移动、敌人 AI、关卡管理），街机格斗用简化版，RTS 用最简方案（几个单位 + 简单建造）。用 Paper2D 或简化 3D 实现像素风。
• 工期预估：每个小游戏 10-20 天，全部 5 个 50-100 天。建议分阶段：v0.5 先做 FC 横版验证，后续逐个追加
• 第三方需求：可以考虑 Marketplace 上的 2D Platformer 模板或 Beat-em-up 模板加速开发

5.5 肢体活动（简化处理）

• 技术可行性：极简。QTE 或节奏小游戏级别，UE5 完全原生支持。
• 实现复杂度：低
• 工期预估：每个活动 1-2 天，全部 5-8 天

6. 时间循环系统

• 技术可行性：UE5 完全支持。核心是一个 GameState 中的 TimeManager 组件，管理当前时段（枚举），联动 Directional Light 的旋转角度和光照参数。
• 实现复杂度：中
• 技术风险点：
  • 光影过渡的平滑性：四时段之间的光影切换如果用离散跳变会很突兀，需要平滑过渡。方案：(a) 用浮点时间连续驱动 Directional Light Rotation，(b) 在时段边界用 Timeline 做渐变过渡。两者均可行
  • 时段与 NPC 位置的联动：时段切换时 NPC 需要移动到新位置。可以用简单的 Teleport + Fade In/Out，也可以做 NPC 走路移动（更真实但工作量大）
  • 时段与活动可用性的联动：小卖部下午才开、晚上在家看电视——需要在交互系统中加入时段条件判断
• 推荐方案：C++ TimeManager（Subsystem）管理时段状态，Blueprint 响应时段变化事件（OnTimePeriodChanged），联动光照和 NPC 位置。时段推进由事件或玩家行为触发，不需要真实时间流逝。
• 工期预估：核心框架 3-5 天，光影调试 3-5 天，与 NPC/活动联动 5-8 天，合计 10-18 天
• 第三方需求：无

7. NPC 系统

• 技术可行性：UE5 完全支持。7 个核心 NPC 的 AI 用 StateTree（项目已启用）实现，简单 NPC 可以纯 Blueprint 逻辑。对话树用自定义数据结构 + UMG。
• 实现复杂度：中（AI 部分）→ 高（对话树部分）
• 技术风险点：
  • 对话树的数据量：7 个核心角色 x 多时段 x 多剧情阶段的对话内容，文本量大。对话数据需要结构化存储和管理
  • 对话编辑工具：如果对话复杂度高（分支、条件），需要对话编辑器。可以自建简单的 JSON 对话数据 + 解析器，或用 Marketplace 上的对话插件
  • NPC 位置调度：每个 NPC 有时段位置联动表，需要在场景中配置多个位置点并管理切换逻辑。工作量不大但需要仔细配置
  • NPC 的"活性"感：如果 NPC 只是站在固定位置切换，会显得很机械。加入 Idle 动画、小范围巡逻、看物品等微行为可以增加活性，但增加动画和 AI 工作量
• 推荐方案：C++ NPC 基类 + ScheduleComponent（时段位置表），StateTree 管理行为（Idle、巡逻、交互响应），对话用 JSON 数据文件 + 自建解析器。v0.1 NPC 为静态站位（不需要 AI），后续版本逐步增加活性。
• 工期预估：基础框架 5-8 天，7 个 NPC 数据配置 + AI 行为 10-15 天，对话系统 8-12 天，合计 20-35 天
• 第三方需求：建议考虑对话插件（如 Dialogue Builder 等），可节省对话编辑和渲染的工期

8. 叙事系统

• 技术可行性：UE5 支持实现。核心是事件管理系统（EventManager）+ 任务管理系统（QuestManager），都是数据驱动设计。链式任务用图结构或线性链表存储。
• 实现复杂度：中
• 技术风险点：
  • 叙事内容的创作：不是技术问题，但日常事件、关键剧情、支线结局的文本创作是巨大的内容工作量
  • 事件触发条件的复杂度：多条件组合（收集进度 + NPC 关系 + 时段 + 剧情阶段）需要灵活的条件系统
  • 多路径达成：设计文档要求"多路径"（弹珠、收集、经济都能通向目标），这需要在任务系统中实现多种完成条件的 OR 逻辑
  • 与多系统耦合：叙事系统需要监听收集事件、小游戏结果、经济变化、时间推进——耦合度高，需要清晰的事件总线设计
• 推荐方案：C++ EventManager（基于 Gameplay Tag 的事件总线），QuestManager 用 DataAsset 定义任务链（条件、目标、奖励），对话触发用 NarrativeTrigger Component 附着到场景 Actor。事件总线解耦各系统。
• 工期预估：核心框架 8-12 天，内容配置和调试视剧情规模而定
• 第三方需求：无

9. 经济系统

• 技术可行性：UE5 完全支持。核心是零花钱计数器 + 购买/消费/换币交易逻辑，本质上是一个简单的数值管理器。
• 实现复杂度：低
• 技术风险点：
  • 经济平衡：零花钱获取速率和消费速率需要平衡，但这是设计调参问题不是技术问题
  • 购买流程的 UI：小卖部购买、街机换币的 UI 交互需要精心设计，但技术上没有难点
• 推荐方案：C++ EconomyManager（Subsystem），DataAsset 定义商品价格和库存。购买 UI 用 UMG。
• 工期预估：核心框架 3-5 天，UI 交互 5-8 天，合计 8-13 天
• 第三方需求：无

10. 场景氛围（光影 / 声音 / 天气）

• 技术可行性：UE5 完全支持，且引擎在此领域功能丰富。
• 实现复杂度：低（技术）→ 中（艺术调试）
• 技术风险点：
  • 声音景观的细节度：设计文档列出了非常详细的声音分层（主街/巷子/空地/河边各有不同音景），实现需要大量音频素材和 Audio Volume 的精细配置
  • 天气效果：v0.3 之后考虑，简单的雨效果用 Cascade 粒子 + 后处理材质 + 材质 Wetness 参数即可
  • Lowpoly 风格下的光影美感：如何在 Lowpoly 简化几何体上做出温暖怀旧的光影效果，需要在材质和光照参数上反复调试
• 推荐方案：光影用 Directional Light + Skybox + PostProcess Volume（色调映射、色温），声音用 Audio Volume 分区 + Ambient Sound Actor，天气用 Cascade 粒子 + 材质变化。避开 Lumen，使用烘焙或简单动态光照以保持 Lowpoly 风格的简洁感。
• 工期预估：v0.1 基础光影 2-3 天（固定下午时段），完整四时段光影 5-8 天，声音景观 8-12 天，天气 3-5 天
• 第三方需求：大量音效素材。建议使用免费音效库（如 Freesound）或购买怀旧/城市场景音效包

---

单人开发资源瓶颈分析

最具挑战的系统（按风险排序）

排名	系统	挑战维度	瓶颈分析
1	小游戏系统（整体）	内容量	5+ 个独立小游戏 = 5+ 个小型游戏的开发量。单人同时维护多个独立玩法系统是最大的资源瓶颈
2	叙事文本与对话	内容创作	7 个 NPC x 多时段 x 多阶段 = 数百条对话文本。这是非代码工作量，但可能比写代码更耗时
3	美术资产	资产制作	完整版 150m x 120m 场景 + 室内 + 道具 + NPC，Lowpoly 虽然简化但仍有大量独特模型需要制作或采购
4	四驱车改装系统	UI 复杂度	改装 UI 是全游戏最复杂的 UI 系统，需要大量 Widget 交互逻辑
5	收集系统（完整版）	系统联动	收集系统需要与小游戏、NPC、叙事、经济四个系统联动，耦合度高，调试和测试工作量大

分阶段降低风险的策略

1. v0.1-v0.2：验证核心假设

   • 只做探索 + 弹珠。如果"在千禧年场景中漫步"和"弹珠小游戏"的体验不成立，及时调整方向
   • 弹珠只实现 1 种规则模式（画圈弹），1 种场地，验证操作手感

2. v0.3-v0.4：扩展但不跳跃

   • 时间循环 + NPC 对话 + 简单叙事。这些系统相互依赖，一起做最合理
   • NPC 先做 3 个核心角色（死党 A/B + 老板），其余后续追加

3. v0.5：内容扩展的高峰

   • 这是工作量最大的版本（四驱车 + FC/街机 + 收集扩展）
   • 建议 FC/街机先各做 1 个小游戏验证框架，不急于做全量关卡

4. v0.6-v0.7：整合与收束

   • 乡下场景是独立模块，可以在 v0.5 期间并行设计
   • 结局系统和多支线需要完整的回归测试

可以显著节省工期的决策

决策	节省工期	影响
FC/街机游戏每个只做 2-3 关而非 3-5 关	节省 15-20 天	耐玩度略降，但核心体验不变
四驱车简化赛道物理（预设路径 vs 完全物理）	节省 10-15 天	改装效果的直观感知度略降
NPC 对话用文本模板 + 关键词替换而非完全手写	节省 10-15 天	对话多样性略降，但可接受
乡下场景缩小为 3 个区域而非 4 个	节省 5-8 天	活动内容略少
PC RTS 做为最简原型（甚至推迟到 DLC）	节省 15-20 天	内容完整度略降

---

原型阶段技术路线（v0.1-v0.3）

v0.1：场景漫游 + 环境交互（验证探索感）

技术目标：验证"在千禧年城郊场景中漫步并交互"的核心体验

开发顺序：

步骤	内容	工期	依赖
1	角色控制器 + 摄像机（基于已有框架调整）	1-2 天	无
2	Enhanced Input 配置（WASD/Shift/E/ESC）	1 天	步骤 1
3	交互系统核心框架（Interface + Component + 检测）	2-3 天	步骤 1
4	交互提示 UI（UMG Widget）	1-2 天	步骤 3
5	叙事文本 UI（打字机效果）	1-2 天	步骤 4
6	推镜相机系统	1-2 天	步骤 1
7	场景白盒（6 区域）	2-3 天	无（可并行）
8	交互物数据填充（10 个第一轮 + 第二轮）	2-3 天	步骤 3-6
9	收集系统基础（拾取 + 计数）	1-2 天	步骤 3
10	调试打磨	2-3 天	全部

v0.1 总工期预估：10-18 天

技术选型：

• 全部使用 UE5 内置功能，不引入第三方插件
• C++ 做核心框架，Blueprint 做具体配置
• 角色：基于已有 ChildHoodCharacter 修改

v0.2：弹珠小游戏 + NPC 基础（验证小游戏可玩性）

技术目标：验证弹珠四维策略系统的操作手感和策略深度

开发顺序：

步骤	内容	工期
1	弹珠操作手感原型（Throwaway）	2-3 天
2	弹珠物理系统（Chaos 配置 + 材质参数）	3-5 天
3	四维策略数据框架（规则/场地/弹珠/手法 DataAsset）	3-4 天
4	弹珠 GameMode + PlayerController	3-5 天
5	NPC 基础框架（静态站位 + 简单对话文本）	3-5 天
6	蹲下系统	1-2 天
7	弹珠与收集系统联动	2-3 天
8	调试打磨	3-5 天

v0.2 总工期预估：20-32 天

关键风险：步骤 1 的操作手感验证如果不通过，需要调整操作方案，可能增加 5-10 天。

v0.3：时间循环 + 经济基础（验证节奏感）

技术目标：验证四时段时间循环带来的世界活性感

开发顺序：

步骤	内容	工期
1	TimeManager（四时段枚举 + 推进逻辑）	2-3 天
2	光影联动（Directional Light + Skybox）	3-5 天
3	EconomyManager（零花钱 + 购买）	3-5 天
4	时段与 NPC 位置联动	2-3 天
5	时段与活动可用性联动	2-3 天
6	基础音效（脚步、环境音）	3-5 天
7	调试打磨	3-5 天

v0.3 总工期预估：18-29 天

---

风险汇总表

系统	风险等级	核心风险	缓解措施
角色控制器	🟢 低	几乎无风险	基于已有框架，UE5 原生支持
交互系统	🟢 低	推镜相机位置计算	提前测试贴墙/角落场景
场景白盒	🟢 低	布局体验需迭代	分阶段扩展，v0.1 先验证小场景
收集系统（基础）	🟢 低	无显著技术风险	—
收集系统（完整）	🟡 中	多系统联动耦合	事件总线解耦，逐系统接入
时间循环系统	🟡 中	光影过渡平滑性	用 Timeline 渐变而非离散跳变
经济系统	🟢 低	无显著技术风险	—
NPC 系统	🟡 中	对话内容量大	考虑对话插件，NPC 分阶段交付
叙事系统	🟡 中	多系统耦合	事件总线设计，条件系统模块化
场景氛围	🟡 中	声音素材需求量大	使用免费音效库，分阶段填充
弹珠小游戏	🟡 中	操作手感验证	先做 Throwaway 原型再正式开发
四驱车系统	🔴 高	改装 UI 复杂度 + 赛道物理	简化赛道物理，改装 UI 分阶段
FC/街机/PC 小游戏	🔴 高	内容量巨大	每个独立迭代，先做 1 个验证
整体内容量	🔴 高	单人开发的工作量天花板	严格控制范围，分阶段验证

---

结论与建议

技术可行性判断

ChildHood 在技术上完全可行。所有系统在 UE5.7.4 中都有成熟的实现路径，不存在引擎层面的不可行项。项目的真正挑战不在"能不能做"，而在"能不能在合理时间内做完"。

关键建议

1. 小游戏是最大风险，也是最大卖点。弹珠的操作手感和策略深度必须在 v0.2 通过 Playtest 验证。如果弹珠不成立，整个小游戏支柱需要重新评估。

2. "游戏中的游戏"范围必须砍到最低。建议 FC/街机每个类型各做 1 个最小可玩版本（2-3 关），验证"坐在电视前玩游戏"的感觉。更多关卡作为内容填充在后续版本追加。PC RTS 可以推迟到 v1.0 之后。

3. 叙事文本应该尽早引入外部协助。对话文本、物品描述、内心独白——这些不是程序工作，但单人开发意味着这些也需要自己写。建议在 v0.4 叙事阶段考虑找人帮忙写文本。

4. 美术资产策略需要明确。Lowpoly 资产是否全部自制、是否使用 Marketplace、是否外包——这个决定越早越好。建议优先使用 Marketplace 资产（购买或免费），自制只限于关键特色物件。

5. 项目已有的 Variant_ 代码需要清理*。当前 Source 目录中有 Variant_Combat、Variant_Platforming、Variant_SideScrolling 三个游戏模式的遗留代码，这些与 ChildHood 的核心玩法无关，应该在 v0.1 开始前清理或归档，保持代码库整洁。

6. 原型阶段不追求完美。v0.1-v0.3 的核心目标是验证假设，不是打磨品质。推镜相机稍微不完美、动画暂时用占位、UI 朴素一些都可以接受——关键是让"在千禧年小街上漫步"的感觉立住。

开发工期总预估（单人，含调试）

版本	核心内容	预估工期
v0.1	场景漫游 + 环境交互	10-18 天
v0.2	弹珠 + NPC 基础 + 蹲下	20-32 天
v0.3	时间循环 + 经济 + 音效	18-29 天
v0.4	叙事框架 + 核心角色	20-30 天
v0.5	四驱车 + FC/街机 + 收集扩展	40-60 天
v0.6	乡下场景	15-25 天
v0.7	整合 + 多支线 + 结局	20-30 天
v1.0	打磨发布	15-25 天
总计		158-249 天（约 5-8 个月）

以上为全职投入的预估。如果兼职开发，需要按比例延长。关键路径在 v0.2（弹珠验证）和 v0.5（内容高峰）。

最终结论

建议进入原型阶段（v0.1）。技术可行性已验证通过，不存在阻塞项。v0.1 的 10-18 天投入是低风险的——即使最终发现"探索感"不成立，损失也可控。但基于设计文档的质量和参考游戏的成功先例，对 v0.1 验证通过的判断是乐观的。