示例 Unity 项目结构（Playable Game Template）

一、整体设计原则（先说清楚，博客加分）

这套结构遵循 4 个原则：

1. 按职责分层，而不是按类型乱放

2. 脚本 = 行为，而不是"万能控制器"

3. 数据与逻辑分离

4. 允许项目在小规模下保持简单

---

二、推荐目录结构（Assets）

Assets/
├── Scenes/
│   ├── Bootstrap.unity
│   └── Game.unity
│
├── Scripts/
│   ├── Core/
│   │   ├── GameManager.cs
│   │   └── GameState.cs
│   │
│   ├── Player/
│   │   ├── PlayerMove.cs
│   │   ├── PlayerJump.cs
│   │   └── PlayerHealth.cs
│   │
│   ├── Systems/
│   │   ├── InputSystem/
│   │   │   └── PlayerInput.cs
│   │   ├── AudioSystem/
│   │   │   └── AudioManager.cs
│   │   └── UISystem/
│   │       └── UIManager.cs
│   │
│   ├── Gameplay/
│   │   ├── Goal.cs
│   │   └── DeadZone.cs
│   │
│   └── Utils/
│       └── Timer.cs
│
├── ScriptableObjects/
│   ├── PlayerConfig.asset
│   └── LevelConfig.asset
│
├── Prefabs/
│   ├── Player.prefab
│   └── UI.prefab
│
├── Art/
│   ├── Sprites/
│   └── Animations/
│
├── Audio/
│   ├── BGM/
│   └── SFX/
│
└── Settings/
    └── InputActions.inputactions

---

三、各目录的「工程意义」（博客重点）

1️⃣ Scenes ------ 游戏流程层

Scenes/
 ├── Bootstrap.unity
 └── Game.unity

• Bootstrap：初始化全局系统（音频、配置）

• Game：真正的游戏内容

📌 工程思想：

把"启动逻辑"和"玩法逻辑"分开

后期加菜单 / 多关卡会非常舒服

---

2️⃣ Scripts/Core ------ 游戏生命周期控制

Scripts/Core/
 ├── GameManager.cs
 └── GameState.cs

• GameManager：控制流程

• GameState：枚举状态

  public enum GameState
  {
  Ready,
  Playing,
  Win,
  Lose
  }

📌 好处：

• 不用到处写 bool isGameOver

• 博客里很好解释「状态驱动」

---

3️⃣ Scripts/Player ------ 行为拆分示例

Player/
 ├── PlayerMove.cs
 ├── PlayerJump.cs
 └── PlayerHealth.cs

不要这样做：

PlayerController.cs（1000 行）

📌 博客可强调：

Unity 鼓励用 组合，而不是继承

---

4️⃣ Scripts/Systems ------ 可复用系统层

Systems/
 ├── InputSystem/
 ├── AudioSystem/
 └── UISystem/

这些系统特点：

• 不关心具体关卡

• 不绑定具体角色

• 可以跨 Scene 存活

例如：

• AudioManager 使用 DontDestroyOnLoad

• UIManager 管界面切换

---

5️⃣ Scripts/Gameplay ------ 关卡内规则

Gameplay/
 ├── Goal.cs
 └── DeadZone.cs

职责：

• 胜利条件

• 失败触发

• 与 GameManager 通信

📌 关键点：

Gameplay 只描述规则，不控制流程

---

6️⃣ ScriptableObjects ------ 数据驱动核心

ScriptableObjects/
 ├── PlayerConfig.asset
 └── LevelConfig.asset

用途：

• 移动速度

• 跳跃高度

• 关卡参数

📌 博客亮点：

把「调参」从代码中解放出来

---

7️⃣ Prefabs ------ 组合结果

Prefabs/
 ├── Player.prefab
 └── UI.prefab

• Player.prefab = Move + Jump + Health

• UI.prefab = Canvas + UIManager

📌 Prefab 是组合的最终形态

---

四、典型对象关系图（文字版）

GameManager
 ├── 控制 GameState
 ├── 接收 Goal / DeadZone 事件
 └── 通知 UIManager 切换界面

Player
 ├── PlayerMove
 ├── PlayerJump
 └── PlayerHealth

---

五、这套结构适合哪些项目？

✅ Unity 新手练手

✅ 技术博客示例

✅ 课程 / 毕设

✅ 独立游戏原型

❌ 超大型 RPG（需要更复杂架构）

---

六、博客写作建议（你可以直接用）

在博客中可以这样总结这一节：

这套项目结构并不是"唯一正确"，

但它刻意避免了早期 Unity 项目中常见的混乱问题：

• 脚本职责不清

• 逻辑高度耦合

• 后期难以扩展

对于一个「可以玩的游戏原型」，
清晰 > 完美架构。