示例 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 项目中常见的混乱问题：

• 脚本职责不清

• 逻辑高度耦合

• 后期难以扩展

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