# 技术可行性评估 — 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 验证通过的判断是乐观的。