Unity on Nullshow的技术博客

【Unity】从一个中型游戏学习商业化代码的写法（上）

Tue, 10 Feb 2026 19:13:30 +0800

教程参考及素材来源：油管-Code Monkey

项目简介

《Kitchen Chaos》是一款轻量版的 Overcooked 风格游戏。它是一个完整的项目，非常适合用来学习架构、模块化和事件系统。这个版本是单人厨房管理游戏，玩家扮演厨师，在限定时间内制作顾客点单的菜品。游戏节奏快、任务多，需要玩家在混乱的厨房中合理分工。

学习目标

这个课程是油管上评分最高的免费课程，有一些没有编程经验的人甚至跟随课程之后在一年时间内上线自己首款独立游戏并赚了几十到几百万美金。这个课程里，Code Monkey同样遵循他一贯的代码设计理念，只写干净的、商业级的游戏代码。因为这个项目是中等规模的程序，所以包括的可复用的系统和架构模式十分丰富。这些我都可以复用在以后自己的游戏中。

另外，本小站的笔记与其说是分享型的，不如说是私人定制型的，所以一些本人已经熟悉的好的设计，不会记录在笔记中；之前已经记录过的觉得好的点也不会重复记录。

系统包括：

玩家系统
交互系统
食材系统
厨房工作台系统
订单系统
UI 系统

架构模式包括：

事件系统（C# Events）
接口驱动的交互（IInteractable）
ScriptableObject 配置数据
状态机（Cooking State / Cutting State）

此外，由于代码整体拥有良好的可扩展性，也适合我以后做工程化扩展，可以轻松加入：

更多菜品
更多工作台
多人联机（未来你做网络版时非常有用）
难度曲线
厨房布局随机生成

核心玩法结构

接收订单（Orders）

顾客会随机生成订单（如汉堡）
玩家需要根据订单要求准备对应的食材组合
订单有时间限制，超时会扣分或失去奖励

处理食材（Ingredients）

食材需要经过不同的处理方式：
- 切菜（Chopping）
- 烹饪（Cooking / Frying）
- 组合（Assembling）
每种处理方式都有对应的工作台（Counter）

厨房操作（Kitchen Stations）

课程中会实现多个交互点，这些系统都通过事件系统 + ScriptableObjects实现解耦，是课程的亮点，需要重点学习

切菜台：按住键切到进度条完成
炉灶/平底锅：加热食材，有烧焦风险
垃圾桶：丢弃错误食材
盘子台：获取盘子
上菜窗口：提交完成的菜品

玩家控制（Player Movement & Interaction）

课程使用**接口（Interfaces）**统一交互逻辑，让所有可交互物体共享同一套规则。

玩家可以移动、拾取、放下、交互。

得分系统（Scoring）

完成订单 → 加分
超时或错误 → 扣分
连续完成订单 → Combo 奖励

开发步骤

项目设置
Post Processing
角色的控制与动画
- 角色控制
- 角色动画
- Cinemachine
Input System（输入部分代码重构）
碰撞检测
- Cast
柜台
- 空柜台
  - 交互（Raycast + LayerMask, events）
  - 选中柜台的视觉效果
厨房物品
- 在空柜台上的生成位置
- Scriptable Objects
- 厨房物体的父对象
玩家与厨房物品的交互
- 捡起
- 放下
不同类型的柜台（prefab variant）
- 空柜台（重新做成预制体变量）
- container counter
- cutting counter
  - 切菜的实现（整颗生成对应的片片）
  - 切菜进度及UI
  - 切菜进度条始终正对玩家
- Trash Counter

思路及关键步骤

输入和逻辑分离

这样的好处在此项目中，最显而易见的是在后期input重构时，逻辑部分可以在不同平台下复用。

总结这种策略的好处：

提高代码可读性与可维护性：将输入处理（如按键检测）与游戏逻辑（如角色移动、状态更新）分开，使代码结构更清晰，便于理解和修改
增强模块化与复用性：输入处理和核心逻辑解耦后，逻辑部分可在不同平台或输入方式（如手柄、触屏）下复用，只需更换输入模块
便于测试与调试：逻辑部分不依赖具体输入，可独立进行单元测试；调试时也更容易定位问题是出在输入还是逻辑
支持更灵活的架构设计：为后续引入ECS、状态机或命令模式等高级架构打下基础，提升项目扩展性

private void Update()
{
    Vector2 inputVector = new Vector2(0, 0);
    if (Input.GetKey(KeyCode.W))
    {
        inputVector.y = 1;
    }
    if (Input.GetKey(KeyCode.S))
    {
        inputVector.y = -1;
    }
    if (Input.GetKey(KeyCode.A))
    {
        inputVector.x = -1;
    }
    if (Input.GetKey(KeyCode.D))
    {
        inputVector.x = 1;
    }

    inputVector = inputVector.normalized;   // 为了让对角线的速度也是1
    Vector3 moveDirection = new Vector3(inputVector.x, 0, inputVector.y);

    transform.position += moveDirection * moveSpeed * Time.deltaTime;
}

使用 `Slerp` 处理角色的转向

Lerp 和Slerp 都可用于插值计算，两者的关键区别如下：

特性	Lerp	Slerp
插值路径	直线（欧氏空间）	球面大圆弧（旋转空间）
常用于	位置、颜色、缩放等	旋转（Quaternion）
速度均匀性	线性均匀	角速度均匀（更自然的旋转）
性能	更快	稍慢（涉及三角函数计算）

角色的动画

处理动画的注意点

点击“录制”后放置关键帧才有效。另外，如果要在不动物体的情况下设置关键帧，需要改变一下物体的位置再还原，否则无法添加关键帧。

动画的名称是区分大小写的，而且动画的部分必须使用字符串名称，无法绕开，所以要十分小心拼写、大小写等。

动画中的 visual 与 logic 分离原则

根据 visual 和 logic 分离原则，将 animator 添加到 PlayerVisual子物体上。根据松耦合的原则，不要将动画的逻辑直接放到 Player.cs 中，而是创建 PlayerAnimator.cs，挂在PlayerVisual子物体上。

拓展：CInemachine工作原理

基于“虚拟相机（Virtual Camera） + 主相机（Main Camera）”的架构：

主相机（Main Camera）

场景中通常只保留一个主相机（带有 CinemachineBrain 组件）
它本身不直接设置位置或旋转，而是被动接收来自虚拟相机的指令

虚拟相机（Virtual Camera）

虚拟相机是 Cinemachine 的核心组件，代表一种“镜头意图”（如跟随玩家、聚焦目标、过场运镜等）
每个虚拟相机可以设置：
- Follow：自动跟随某个目标（如玩家角色）
- Look At：朝向某个焦点（如敌人或交互对象）
- Body / Aim 设置：控制相机的位置偏移（如轨道、环绕、自由跟随）和朝向逻辑（如平滑对准）
- Priority：决定多个虚拟相机之间的切换优先级

CinemachineBrain

附加在主相机上，负责：
- 根据虚拟相机的 Priority 选择当前激活的虚拟相机
- 在多个虚拟相机之间进行平滑过渡（blend）
- 将选中虚拟相机计算出的最终位置/旋转应用到主相机

高级功能支持

Noise（抖动）：模拟手持摄像机效果
Impulse（冲击反馈）：配合 CinemachineImpulseSource 实现爆炸、跳跃等镜头震动
Timeline 集成：与 Unity 的 Timeline 工具无缝协作，制作电影化过场动画

所以，添加了Cinemachine后，无需/不能控制主摄像机，控制Cinamachine就可以了。本项目中，Cinemachine的初始参数设置成和原来的主摄像机一样就可以了。

输入部分的重构

为了让input和玩家的代码逻辑解耦，创建一个空的游戏物体，在其上挂载单独的脚本 GameInput.cs。这里遵循的是“单一职责原则”，一个类/函数只做一件事情。好代码原则是：管理和最小化项目的复杂度。

同时保留新旧两套输入系统：Edit => Project Settings => Player => Configuration => Active Input Handling => Both

新建一个 Input Actions，在这里我们将管理 Player 所有的输入。

WASD

创建Action（取名为 Move）=> Action Type(Value) => 删掉默认的 Binding => 新建选择 Up/Down/Left/Right Composite

生成C# class

点击之前创建的 PlayerInputActions ，勾选 Generate C# class

重构后的输入代码

使用 Input System 后重构的代码只有短短几句。用 InputSystem来控制的玩家移动都大同小异，这个脚本可以作为“积木”使用。

public class GameInput : MonoBehaviour
{
    private PlayerInputActions playerInputActions;

    private void Awake()
    {
        playerInputActions = new PlayerInputActions();
        playerInputActions.Enable();
    }

    public Vector2 GetInputVectorNormalized()
    {
        Vector2 inputVector = playerInputActions.Player.Move.ReadValue<Vector2>();

        inputVector = inputVector.normalized;   // 为了让对角线的速度也是1

        return inputVector;
    }
}

此外，代码中的 normalized 也可以交由 Input System中的 Processors 来做，真的很周到了。

3D的碰撞检测

在3D中一般使用Cast和Raycast来处理碰撞检测，它们的含义和使用场景有一些区别。

Raycast（射线检测）

从某一点沿指定方向发射一条无限细、无体积的直线（射线），检测它是否与场景中的碰撞体（Collider）相交。常用于瞄准、点击检测、视线判断等。

特点：

只检测“线”是否碰到物体
性能开销小
无法检测空心区域或复杂形状内部

Cast（投射 / 形状检测）

发射一个有体积的几何形状（如球体、胶囊体、盒子等），沿方向移动一段距离，检测是否与碰撞体重叠。常见的类型有 SphereCast、

CapsuleCast、BoxCast 等。用于角色移动预测和更真实的碰撞预判（比如角色跳跃前检测前方是否有障碍）。

特点：

考虑物体的体积和形状，比 Raycast更贴近实际碰撞
性能开销略高于 Raycast，但更精确

关于碰撞时如果同时按下两个键，玩家移动的处理

主要的思路是将速度分解，先看x轴方向能不能走，能走就走x方向的；然后再看z轴方向能不能走，能走就走z方向的。需要注意的时，由于在分解单个轴方向时矢量会变短（斜线方向矢量更大的相反情况），所以单个轴方向上的矢量仍然需要归一化，以保证分解后的速度是一样大小的。

 Vector3 moveDirection = new Vector3(inputVector.x, 0, inputVector.y);

 float playerHeight = 2f;
 float playerRadius = 0.7f;
 float moveDistance = moveSpeed * Time.deltaTime;
 // 碰撞检测 Cast
 bool canMove = !Physics.CapsuleCast(transform.position, transform.position + Vector3.up * playerHeight, playerRadius, moveDirection, moveDistance);

 if(!canMove)
 {
     // 不能移动的情况下，分解速度到每个方向上
     // 只有在x轴方向能移动
     Vector3 moveDirectionX = new Vector3(moveDirection.x, 0, 0);
     canMove = !Physics.CapsuleCast(transform.position,transform.position +Vector3.up*playerHeight,playerRadius, moveDirectionX, moveDistance);
     if (canMove)
     {
         moveDirection = moveDirectionX.normalized;
     }
     else
     {
         // 只能在z轴移动
         Vector3 moveDirectionZ = new Vector3(0,0,moveDirection.z);
         canMove = !Physics.CapsuleCast(transform.position, transform.position+Vector3.up*playerHeight,playerRadius, moveDirectionZ, moveDistance);

         if(canMove)
         {
             moveDirection = moveDirectionZ.normalized; 
         }
         else
         {
             // 一点都不能移动
         }
     }
 }

 if(canMove)
     transform.position += moveDirection * moveDistance;

与柜台的交互

使用Raycast来检测玩家是否碰到了柜台。这里需要处理的细节是，记录上一次和玩家和柜台交互的方向，这样可以解决玩家必须一直运动才显示和柜台交互的问题。另外，使用LayerMask来确保玩家和柜台交互。

private void HandleInteraction()
{
    Vector2 inputVector = gameInput.GetInputVectorNormalized();

    Vector3 moveDirection = new Vector3(inputVector.x, 0, inputVector.y);

    if (moveDirection != Vector3.zero)
    {
        lastInteractDirection = moveDirection; // 在运动，就更新lastInteractDirection
    }

    float interactDistance = 2f;
    if (Physics.Raycast(transform.position, lastInteractDirection, out RaycastHit raycastHit, interactDistance, counterLayerMask))
    {
        if (raycastHit.transform.TryGetComponent(out ClearCounter clearCounter))
        {
            clearCounter.Interact();
        }
    }
}

进一步重构：

使用事件来监听player与counter的交互，从而达到解耦的目的。

在 GameInput.cs 中我们使用委托为Interact Action添加一个调用的函数Interact_performed()。performed是 InputAction 提供的事件之一。Input System 对每个 action 提供三个常见阶段的回调：started（开始），performed（触发/完成），canceled（取消）。使用 performed 表示当输入动作被视为“完成”时（例如按下按钮，或按键触发的交互条件满足时）调用你的回调。

具体调用的方式参照我们在设置Input Action资产时所命名的：

public class GameInput : MonoBehaviour
{
    private PlayerInputActions playerInputActions;
    public event EventHandler OnInteractAction;

    private void Awake()
    {
        playerInputActions = new PlayerInputActions();
        playerInputActions.Enable();

        // 监听player 与 counter的交互
        playerInputActions.Player.Interact.performed += Interact_performed;
    }

    private void Interact_performed(InputAction.CallbackContext context)
    {
        OnInteractAction?.Invoke(this, EventArgs.Empty);
    }

    private void OnDestroy()
    {
        playerInputActions?.Disable();

        playerInputActions.Player.Interact.performed -= Interact_performed;

    }

随后在 Player.cs 中根据消息做出相应的反应：

private void Start()
{
    gameInput.OnInteractAction += GameInput_OnInteraction;
}

private void OnDestroy()
{
    gameInput.OnInteractAction -= GameInput_OnInteraction;
    
}

private void GameInput_OnInteraction(object sender, EventArgs e)
{
    HandleInteraction();
}

柜台选中时的视觉效果

我们复制 ClearCouter 下的子物体 ClearCounter_Visual，并将其命名为 Selected，为其设置对应的材质。一个需要注意的点是：

由于两个大小完全一样的物体的网格重叠时可能会形成闪烁的效果，为了避免这种情况，需要将选中效果的柜台稍微放大一些，例如本项目中将其扩大了 1%。

另外，需要事先将选中效果隐藏，只需要使选中柜台中单纯负责渲染的子物体失活即可。

在处理选中的视觉效果，有两种思路可以选择：

让当前 selectedCounter 发送通知，在处理视觉表现的脚本中订阅该事件并且做出相应的视觉效果的变化。也就是在ClearCounter.cs 中发送事件，在 SeletedCounterVisual.cs 中订阅该事件
让当前操作的角色发送通知，在处理视觉表现的脚本中订阅该事件并做出视觉效果的变化

两种方法有各自的优缺点：

第一种方法
- 好处：SeletedCounterVisual.cs 只订阅当前选中柜台的事件，如果我们需要选中时添加其他效果也可以很方便地添加
- 坏处：控制视觉效果的代码又需要出现在专门处理逻辑的ClearCounter.cs的脚本中，造成耦合
第二种方法
- 好处：更方便。控制视觉效果的代码不会出现在处理逻辑的脚本中，解耦
- 坏处：可能存在性能问题。因为所有的柜台都需要订阅由角色发送的事件

鉴于此项目规模较小，并不会带来性能瓶颈，所以此处选择了第二种方法。

因为此项目是单人版，所以我们索性将玩家设置为单例。

踩的坑

在局部优化的时候，我在 SelectedCounterVisual.cs 中，将来自 player 的事件注册到了 Enable 中：

//============ SelectedCounterVisual.cs ============
private void OnEnabe()
{
    Player.Instance.OnSelectedCounterChange += Player_OnSelectedCounterChange;
    Hide();
}

private void OnDisable()
{
    Player.Instance.OnSelectedCounterChange -= Player_OnSelectedCounterChange;
}

这引起了空引用报错。

因为在 Unity 的生命周期顺序里，OnEnable() 可能会在很多情况下很早触发（比如物体/组件一开始就是 Enabled、或者 SetActive(true) 时），它可能早于 Player 的 Awake() / Start() 执行。

虽然我的 Player.Instance = this; 是在 Awake() 里做的，那理论上应该很早，但仍可能因为 SelectedCounterVisual 启用时， Player.Instance还没赋值，导致空引用异常。所以更安全的做法是将注册事件的部分移到 Start 中：

private void Start()
{
    Player.Instance.OnSelectedCounterChange += Player_OnSelectedCounterChange;
    Hide();
}

private void OnDestroy()
{
    Player.Instance.OnSelectedCounterChange -= Player_OnSelectedCounterChange;
}

有别的脚本参与的注册事件最好放在 Start 中（类似于 GetComponent的处理一样），不要放在 Enable 中，避免空引用问题（其他脚本还没准备好就开始注册和该脚本有关的事件）

使用Scriptable Object来管理厨房物品

这是我第一次在项目中系统使用 ScriptableObject 来管理资源，所以将这部分的内容详细总结如下：

ScriptableObject

是 Unity 中的一种轻量级、数据驱动的资源类，它不依附于场景中的 GameObject，而是作为 Project 窗口中的独立资产（.asset 文件） 存在。

好处

解耦数据与逻辑
- 将配置数据（如角色属性、关卡参数、技能效果）从 MonoBehaviour 脚本中剥离，避免硬编码
- 修改数值无需改动代码，便于策划或美术协作
跨场景复用
- 一个 ScriptableObject 资产可在多个场景、Prefab 或脚本中引用，保证数据一致性（如全局游戏设置）
编辑器友好
- 在 Inspector 中直观编辑，支持自定义绘制（PropertyDrawer）、Undo/Redo、多选批量修改
节省内存
- 数据集中存储，避免每个实例重复持有相同配置（相比在 MonoBehaviour 中复制粘贴）
版本控制友好
- .asset 文件为纯文本（YAML 格式），便于 Git 等工具 diff 和合并

典型使用场景

场景	示例
游戏配置	玩家初始生命值、敌人掉落表、武器伤害参数
关卡/任务数据	关卡目标、任务奖励、对话树节点
状态机/行为树	AI 行为配置、动画状态参数
本地化文本	多语言词条表（Key-Value 对）
经济系统	商店商品价格、货币兑换规则
原型快速迭代	设计师直接调整数值，无需程序员介入

注意事项

不可用于运行时动态生成的数据（如玩家存档）→ 应使用 JSON / PlayerPrefs / Save System
不包含 MonoBehaviour 生命周期方法（如 Update）→ 仅用于静态数据容器
引用其他对象（如 Prefab、Texture）时需注意资源依赖和打包

创建 KitchenObjectSO 脚本

新建专门的脚本，继承自 ScriptableObject，然后把需要的属性设为字段。为了规范，还是采用私有字段，公开Get使其可以被外部访问。

[CreateAssetMenu()]
public class KitchenObjectSO : ScriptableObject
{
    [SerializeField] GameObject prefab;
    [SerializeField] Sprite sprite;
    [SerializeField] string objectName;

    public GameObject Prefab => prefab;
    public Sprite Sprite => sprite;
    public string ObjectName => objectName;
}

通过鼠标右键创建了资产后，就可以在面板上进行相应设置了：

创建 KitchenObject 脚本

为了能够识别不同的厨房物品，创建 KitchenObject .cs，绑定相应的可编程对象资产，这样玩家和柜台互动时就能识别不同的物体了。

//=========== KitchenObject .cs ===========
public class KitchenObject : MonoBehaviour
{
    [SerializeField] private KitchenObjectSO kitchenObjectSO;

     public KitchenObjectSO GetKitchenObjectSO()
    {
        return kitchenObjectSO;
    }
}

//============ ClearCounter.cs =============
public class ClearCounter : MonoBehaviour
{
    [SerializeField] private KitchenObjectSO kitchenObjectSO;
    [SerializeField] private Transform counterTopPointTransform;
    public void Interact()
    {
        print("clear counter is interacting!");
        Instantiate(kitchenObjectSO.Prefab, counterTopPointTransform.position, Quaternion.identity);

        print(kitchenObjectSO.Prefab.transform.GetComponent<KitchenObject>().GetKitchenObjectSO().ObjectName);
        
    }
}

厨房物体的父对象

游戏的设计是：玩家可以拿起物体，放在不同的柜子上，这就需要通过改变这个厨房物体的父物体来实现对厨房对象做各种不同的操作。

我们从两个方面来实现，它们是一一对应的：

空柜台需要知道自己上面是否有厨房物品
厨房物品需要知道自己在哪个柜台上

//=========== ClearCounter.cs ===========
public class ClearCounter : MonoBehaviour
{
    [SerializeField] private KitchenObjectSO kitchenObjectSO;
    [SerializeField] private Transform counterTopPointTransform;

    private KitchenObject kitchenObject;
    public void Interact()
    {
        if (kitchenObject == null)
        {
            GameObject kitchenObjectGameObject = Instantiate(kitchenObjectSO.Prefab, counterTopPointTransform);
            kitchenObjectGameObject.transform.localPosition = Vector3.zero;

            kitchenObject = kitchenObjectGameObject.GetComponent<KitchenObject>();
            kitchenObject.SetClearCounter(this);
        }
        else
        {
            print(kitchenObject.GetClearCounter());
        }
    }
}

//============= KitchenObject.cs ==============
public class KitchenObject : MonoBehaviour
{
    [SerializeField] private KitchenObjectSO kitchenObjectSO;

    private ClearCounter clearCounter;

    public KitchenObjectSO GetKitchenObjectSO()
    {
        return kitchenObjectSO;
    }

    public void SetClearCounter(ClearCounter clearCounter)
    {
        this.clearCounter = clearCounter;
    }

    public ClearCounter GetClearCounter()
    {
        return this.clearCounter;
    }
}

将厨房物品移动到另一个柜台上去，也就是说，此时厨房物品的父对象改变了。

//=========== ClearCounter.cs ===========
// 因为厨房物品是放在 counterTopPointTransform 上的
// 所以用一个函数返回
public Transform GetKitchenObjectFollowTransform()
{
    return counterTopPointTransform;
}

//============= KitchenObject.cs ==============
public void SetClearCounter(ClearCounter clearCounter)
{
    this.clearCounter = clearCounter;

    // 设置厨房物品的父对象
    transform.parent = clearCounter.GetKitchenObjectFollowTransform();
    transform.localPosition = Vector3.zero;
}

通过这样的操作，厨房物品的transform虽然已经可以到另一个柜台了，但是厨房物品的数据信息仍然留在原来的柜台上。所以也需要对其进行处理。这里有两种方法：

在ClearCounter.cs中，设置kitchenObject的父级后让新的父级去更新
在KitchenObject.cs中，当该厨房物品被设置到新的父级上时自己去更新父级

此项目中采用了第二种方法。厨房物品告诉老的父级“它已经不在那里了”，再告诉新的父级“它现在在那里”。

//=========== ClearCounter.cs ===========
// 增加一些helper函数
    // 厨房物品的 getter 和 setter，用以通知父级它的更新
public void SetKitchenObject(KitchenObject kitchenObject)
{
    this.kitchenObject = kitchenObject;
}

public KitchenObject GetKitchenObject()
{
    return kitchenObject; 
}

public void ClearKitchenObject()
{
    kitchenObject = null;
}

public bool HasKitchenObject()
{
    return kitchenObject != null; 
}

//============= KitchenObject.cs ==============
// 有厨房物品本身通知它的两个父级自己状态的变化
public void SetClearCounter(ClearCounter clearCounter)
{
    // 通知老的柜台：这个厨房物品已经不在了
    // 老柜台：this.clearCounter
    // 新柜台：参数列表中的 clearCounter（没有this）
    if(this.clearCounter != null)
    {
        // 将老柜台上的厨房物品清空
        this.clearCounter.ClearKitchenObject();
    }

    // 设置新柜台
    this.clearCounter = clearCounter;
    // 确保这真的是一个新的空柜台，上面没有任何厨房物品
    if (clearCounter.HasKitchenObject())
    {
        Debug.LogError("Counter already has a kitchen object");
    }
    // 在新柜台上设置厨房物品
    clearCounter.SetKitchenObject(this);

    // 设置厨房物品的父对象
    // Update visual
    transform.parent = clearCounter.GetKitchenObjectFollowTransform();
    transform.localPosition = Vector3.zero;
}

避坑：

这里的新老柜台因为名字都是 kitchenObjectParent ，所以非常容易搞错。

我第一次就搞乱了新老柜台，导致后面玩家无法在空柜台上正常放下物品。

所以为了保险起见，虽然很多情况下 this 都是可以省略的，但是为了清晰，以后还是需要加上。

在此过程中，Code Monkey进行了测试，复制另一个空柜台，看：

厨房物品有没有从视觉上从老柜台移动新柜台上
老柜台和新柜台中，厨房物品的数据有没有更新正确

//========= testing ==========
[SerializeField] ClearCounter clearCounter2;
[SerializeField] bool testing;

private void Update()
{
    if (testing && Input.GetKeyDown(KeyCode.T))
    {
        if (kitchenObject != null)
        {
            kitchenObject.SetClearCounter(clearCounter2);
        }
    }
}

在此项目中，Code Monkey展示了大量这样的测试过程，用打印信息，或者在播放状态下把面板调成 Debug 状态来看私有变量或者其他数据的变化情况。这是一种高效的开发方式，因为 Unity 中的断点调试不太容易，所以用这两者结合，在开始先将逻辑跑通，避免将bug堆积到后期。

玩家与厨房物品的交互

由于厨房物品既需要与空柜台交互，又需要与玩家交互，两者的逻辑某些方法是重合的——可以将空柜台和玩家都看成是厨房物品的父对象，所以设计一个接口 IKitchenObjectParent ，这样，厨房物品能同时实现针对柜台和玩家的方法，又不至于需要继承（在逻辑上也说不通）它们。

public interface IKitchenObjectParent 
{
    public Transform GetKitchenObjectFollowTransform();

    public void SetKitchenObject(KitchenObject kitchenObject);

    public KitchenObject GetKitchenObject();

    public void ClearKitchenObject();

    public bool HasKitchenObject();

}

这样，只需将原来在 ClearCounter.cs里换个名字，在 Player.cs 里也做类似实现即可，非常方便高效。

 public Transform GetKitchenObjectFollowTransform()
 {
     return counterTopPointTransform;
 }

 public void SetKitchenObject(KitchenObject kitchenObject)
 {
     this.kitchenObject = kitchenObject;
 }

 public KitchenObject GetKitchenObject()
 {
     return kitchenObject; 
 }

 public void ClearKitchenObject()
 {
     kitchenObject = null;
 }

 public bool HasKitchenObject()
 {
     return kitchenObject != null; 
 }

不同类型的柜台

教程采用了prefab variant的方式来实现。具体的做法是先从复制一个空柜台，将它设置为 _BaseCounter（名字带下划线的好处是它可以自动排在文件夹的最前面）。_BaseCounter 只需保留最基本的东西，其他的根据不同柜台的需要添加：CounterTopPoint 子物体和 BoxCollider。于是，包括前面做的 ClearCounter，都可以通过 prefab variant来实现。

使用 Prefab Variant 实现高效复用与差异化管理

好处

继承 + 差异覆盖（Inheritance with Overrides）
- Variant 自动继承父 Prefab 的所有属性（组件、参数、子对象结构等）
- 仅需修改有差异的部分（如材质、数值、是否启用某个组件），其余保持同步
批量更新，一处修改，多处生效
若基础逻辑或公共结构变更（如给所有敌人加一个新脚本），只需修改原始 Prefab，所有 Variant 自动继承更新（除非该属性已被覆盖）
清晰的差异化标识
在 Inspector 中，被修改的属性会显示为 粗体 + 覆盖标记（Override），一目了然哪些地方做了定制
减少重复资产，节省维护成本
避免复制多个几乎相同的 Prefab 导致“配置漂移”（例如：10 个敌人只有血量不同，却要维护 10 份完整 Prefab）
支持嵌套与层级化设计
- 可创建多级 Variant（如 Enemy_Base → Enemy_Ranged → Enemy_Ranged_Elite），构建灵活的配置树
  
  （比如本教程中的存放不同厨房物品的container counter就是用container counter 的 prefab variant制作的）

适用场景

除了本项目中柜台的案例外，再举几个适用的场景加深印象：

场景	示例
角色/敌人变种	基础士兵 → 精英士兵（更高血量、不同武器）
道具系统	基础药水 → 治疗药水 / 魔力药水（仅图标和效果值不同）
UI 元素	按钮模板 → 确认按钮 / 取消按钮（仅颜色和文本不同）
关卡物件	基础灯柱 → 损坏灯柱 / 闪烁灯柱（仅动画状态或材质不同）

注意事项

避免过度嵌套：Variant 层级过深会增加理解成本
慎改结构：若在 Variant 中增删子 GameObject，可能影响后续从父 Prefab 继承的更新
适合“小差异”：若两个预制体差异过大（>50% 内容不同），应考虑拆分为独立 Prefab

不同类型柜台的关系设计

由于玩家和每种类型的柜台交互是大同小异的：按下按键，在柜台上生成物品，转移物品的父级对象（柜台/玩家），所以原来玩家和空柜台的交互代码 if (raycastHit.transform.TryGetComponent(out ClearCounter clearCounter)) 需要改为玩家和它们上一级的交互。这里可以用接口或者父类实现。由于各个柜台都大同小异，并且它们确实属于同一个大类，所以用一个柜台的父类来与玩家交互，其他各种类型的柜台都继承自这个父类，不管从逻辑上还是从功能上都能说得通，所以教程使用了这种做法。

拓展

`virtual` 和 `abstract`

两者都可用于支持继承和多态，但它们在实现要求、使用场景和类约束上有所区别：

特性	`virtual`（虚方法）	`abstract`（抽象方法）
是否必须有实现	必须提供默认实现	不能有实现（只有声明）
子类是否必须重写	可选（用 `override` 覆盖）	必须重写（否则编译报错）
所在类是否可实例化	所在类可以是普通类（非抽象），能直接 `new`	所在类必须是 `abstract` 类，不能直接实例化
设计目的	提供可选扩展点（有默认行为）	定义强制契约（子类必须实现特定功能）

本项目中两种方法都可以，Code Monkey采用了 virtual 的策略。需要注意的是，此时在其子类 ClearCounter.cs 中同样的方法会有警告，这代表子类中的这个具有相同签名的方法会覆盖父类中的方法，需要加上override 代表我们重写了父类中的方法而非覆盖。

重构

由于两个柜台子类继承了父类 BaseCounter 又同时实现了接口 IKithchenObjectParent，所以索性让 BaseCounter 实现接口，这样就无需每增加一个新类型的柜台就重写一遍实现接口的代码了。

//=============== BaseCounter.cs ================
public class BaseCounter : MonoBehaviour, IKitchenObjectParent
{
    [SerializeField] private Transform counterTopPointTransform;

    private KitchenObject kitchenObject;

    public virtual void Interact(Player player)
    {
        Debug.LogError("BaseCounter.Interact();");
    }

    public Transform GetKitchenObjectFollowTransform()
    {
        return counterTopPointTransform;
    }

    public void SetKitchenObject(KitchenObject kitchenObject)
    {
        this.kitchenObject = kitchenObject;
    }

    public KitchenObject GetKitchenObject()
    {
        return kitchenObject;
    }

    public void ClearKitchenObject()
    {
        kitchenObject = null;
    }

    public bool HasKitchenObject()
    {
        return kitchenObject != null;
    }
}

切菜柜台的实现

这个柜台主要需要解决3件事情：

整颗菜需要变成对应的片片
有些菜是可以切的（卷心菜、芝士、西红柿），有些是不能的（面包、肉饼）
已经是片片的菜不能再次被切

Cutting Recipe

照例使用 Scriptable Object 来实现。我们通过同一种菜不同形态的一一对应的组合来实现切菜的功能。

//============ CuttingRecipeSO.cs ============
[CreateAssetMenu]
public class CuttingRecipeSO : ScriptableObject
{
    [SerializeField] private KitchenObjectSO input;
    [SerializeField] private KitchenObjectSO output;

    public KitchenObjectSO Input => input;
    public KitchenObjectSO Output => output;
}

//============= CuttingCounter.cs ==============
public override void InteractAlternate(Player player)
{
    if (this.HasKitchenObject())
    {
        // 切菜柜台上有东西，切它
        // 1）销毁整个的；2）生成切好的
        KitchenObjectSO outputKitchenObjectSO = GetOutputFromInput(GetKitchenObject().GetKitchenObjectSO());    // 必须放在Destroy之前

        this.GetKitchenObject().DestroySelf();   

        KitchenObject.SpawnKitchenObject(outputKitchenObjectSO, this);
    }
}

// 从输入的 cutting recipe SO 中找到对应的输出的
private KitchenObjectSO GetOutputFromInput(KitchenObjectSO inputKitchenObjectSO)
{
    foreach (CuttingRecipeSO cuttingRecipeSO in cutKichenObjectSOArray)
    {
        if (cuttingRecipeSO.Input == inputKitchenObjectSO)
            return cuttingRecipeSO.Output;
    }
    return null;
}

对于可以被切的菜的限定

//========= CuttingCounter.cs ==========
//======== 只有可以被切的菜才能放到切菜台上 ========
public override void Interact(Player player)
{
    // 玩家捡起/放下厨房物品           
    if (!HasKitchenObject())   // 如果柜台上没有厨房物品
    {
        // 那么可以放下
        if (player.HasKitchenObject())   // 玩家手里有厨房物品
        {
            // 只有在这个东西都可以被切的情况下才能放到切菜台上
            if (HasRecipeWithInput(player.GetKitchenObject().GetKitchenObjectSO()))
            {
                player.GetKitchenObject().SetKitchenObjectParent(this);
            }
            else  // 玩家手里没有物品
            {

            }
        }
    }
    else  // 如果柜台上有厨房物品
    {
        if (player.HasKitchenObject())  // 玩家手上有东西
        {
        }
        else  // 玩家手上没东西，把柜台上的厨房物品转到玩家手上 
        {
            GetKitchenObject().SetKitchenObjectParent(player);
        }

    }
}

//=========== 只有可以被切的菜才能被执行切菜的动作 ============
public override void InteractAlternate(Player player)
{
    if (this.HasKitchenObject() && HasRecipeWithInput(GetKitchenObject().GetKitchenObjectSO()))    // 玩家手上有东西，并且它可以被切的情况下才能执行切菜动作
    {
        // 切菜柜台上有东西，切它
        // 1）销毁整个的；2）生成切好的
        KitchenObjectSO outputKitchenObjectSO = GetOutputFromInput(GetKitchenObject().GetKitchenObjectSO());    // 必须放在Destroy之前

        this.GetKitchenObject().DestroySelf();   

        KitchenObject.SpawnKitchenObject(outputKitchenObjectSO, this);
    }
}

切菜的进度

因为每种菜的大小不同，所以将 cuttingProgressMax 这个参数放到 CuttingRecipeSO.cs 中。

美化切菜进度条的小技巧：

给进度条的 background 的添加 shadow 或者 outline

当然，切菜进度条的显示也是按照Code Monkey一贯的风格，使用 EventHandler 的方式来处理的。

切菜进度条正对摄像机显示

关于摄像机的更新一般都放在 LateUpdate 中，等待所有的 Update 完成后再进行，以确保没有奇怪的运动发生。

public class LookAtCamera : MonoBehaviour
{
    private void LateUpdate()
    {
        transform.LookAt(Camera.main.transform);
    }
}

如果简单这样处理，虽然看似达到了效果，但是仔细一看切菜条是反过来的。原因是进度条UI是切菜柜的子物体，会跟着它旋转，我们从柜子背面看进度条就会呈现从右向左的状态。所以索性写一个完善的脚本来应对各种LookAt的情况：

public class LookAtCamera : MonoBehaviour
{
    private enum Mode
    {
        LookAt,
        LookAtInverted,
        CameraForward,          // 永远正对摄像机的方向
        CameraForwardInverted   // 永远顺着摄像机的方向
    }

    [SerializeField] private Mode mode;

    private void LateUpdate()
    {
        switch(mode)
        {
            case Mode.LookAt:
                transform.LookAt(Camera.main.transform);
                break;
            case Mode.LookAtInverted:
                Vector3 dir = -(Camera.main.transform.position - transform.position);
                transform.LookAt(dir + transform.position);
                break;
            case Mode.CameraForward:
                transform.forward = Camera.main.transform.forward;
                break;
            case Mode.CameraForwardInverted:
                transform.forward = -(Camera.main.transform.forward);
                break;
        }
    }
}

由于笔记太长，所以分为两个部分，下半部分请见这里

【Unity】从一个入门级小游戏学习商业化代码的写法

Sat, 31 Jan 2026 08:43:30 +0800

教程参考及素材来源：油管-Code Monkey

项目简介

《Lua Lander》是一个受经典游戏《Lunar Lander》启发的 2D 物理小游戏，核心玩法是操控小型飞船在外星地表安全着陆。

经典街机游戏《lunar Lander》的主要机制是：

使用推力与旋转控制飞船方向与速度
避免高速或倾斜角度着陆，否则会坠毁
在指定着陆点轻柔降落可获得更高分数
需要管理速度、角度与燃料

《Lua Lander》是油管游戏开发大佬Code Monkey在此基础上做的复刻和扩展。除了保留以上核心机制外，项目的扩展玩法包括：

更复杂的着陆判定（速度+角度）
多种着陆平台 + 分数倍率系统
燃料系统（飞行成本）
金币收集系统（额外得分）
推进器视觉特效（粒子系统 + 事件驱动）

此外，项目还做了系统级的扩展：

完整 UI 系统
游戏状态机（Start → Playing → GameOver）
多关卡系统（Prefab 关卡，而非多 Scene）
关卡预览（Cinemachine + 自定义 2D Zoom）
多输入系统（键盘 + 手柄 + 触屏）
主菜单、暂停菜单、游戏结束场景
音效与音乐系统

学习目标

Code Monkey喜欢做的游戏一般系统复杂、项目规模大、对可维护性要求高，所以他的教程不管是哪个级别的都会采用更专业的结构，展现如何将clean code、good practice融合进他的项目之中。我希望从这个项目中不仅能学到他解决问题的思路、怎么写干净的代码，还能学到架构项目的正确方式、真正的游戏工程师思维，为以后自己做复杂项目打下基础。

所以在这个项目中我将采用步步跟随的方式，总结他的方法和思路，以便可以用在以后自己的项目中。

开发步骤

整个游戏大概按照下面步骤开发：

post processing处理（可以放在任意步骤）
ander的开发
- lander的运动
- 动力的视觉效果
terrain的开发
- 使用sprite shape
摄像机跟随
- cinemachine
背景的设置
landing
- landing的判定
- landing在平台上
landing pad预制体
- prefab variant （大小不同、得分倍率不同的平台）
- 得分倍率动态指示
燃料机制的实现
- 设置燃料额度
- lander拾取燃料
- 金币（与燃料类似）
GameManager
UI
- 数据统计板
- 加速指示箭头
- 燃料进度条
- 游戏结束UI
  - 结果和数据统计面板
  - Restart按钮
游戏状态设置
- Start
- Restart
- Gameover
爆炸特效
新关卡
- 使用prefab的方法
全景地图
Input System
- button/ Key
- Touch
- Joy Stick
Main Menu Scene
PauseUI
- 点击按钮
- 按下 Esc 键
GameOverScene
- total score
- 返回主菜单按钮
SoundManager 和 MusicManager
- 保持背景音乐在关卡切换后仍然持续播放
- 音量按钮
Polish

思路及关键步骤

PostProcessing

可以通过 Volume => Global Volume => Add Override 来对游戏中的图片和 Game 界面的背景进行视觉效果的调整。虽然此项目只调整了 Bloom 和 Vignette，但是还有大量的参数可调，到时可以根据需要去探索使用。

visual 与 logic 分离

创建一个空游戏物体，将sprite作为子物体挂载在它下面，只负责渲染。而这个空游戏物体会挂载所有的脚本/行为组件，负责所有的逻辑。如果以后有更多的视觉效果（比如粒子特效等），也都同样以单独的子物体的方式挂载。这种做法是我第一次看到的。这样做的好处是：

逻辑与表现解耦，代码更干净

如果逻辑脚本和 Sprite Renderer 在同一个 GameObject 上，你的脚本就会天然依赖视觉组件。分开以后，逻辑脚本只处理数据、状态、行为；子物体负责显示，不影响逻辑。这是“解耦”的核心。
更容易替换视觉资源（Sprite → 动画 → 3D 模型）

如果视觉和逻辑绑在一起，你要改脚本、改结构、改引用。如果分开，视觉只是子物体，那么可以直接把子物体删掉换一个新的，而逻辑脚本完全不用动。这对做长期的、需要不断扩展的项目来说非常重要。
更容易做动画、旋转、缩放

视觉作为子物体，你可以：
- 让视觉旋转，而逻辑不旋转（例如子弹旋转但逻辑方向不变）
- 让视觉抖动、缩放，而逻辑位置保持稳定
- 让视觉做动画，而逻辑不受影响
碰撞体、逻辑中心点更好控制

逻辑物体通常需要一个“干净的 Transform”来作为移动中心/ 碰撞中心/ 旋转中心/ AI逻辑参考点；而视觉往往不是严格的对齐中心，还需要特别处理。
更容易做 Prefab 复用

逻辑 prefab 不变，视觉 prefab 可以换皮肤、换主题、换颜色、换模型等。

代码要尽可能地清晰

访问修饰符要写出来

默认的访问修饰符（如类中的private和接口中的public），Unity并不会显示，也要写上

Input的方法

在Unity6 中新旧两套 Input 的方法都可以用:

private void Update()
{
    // 老版本
    if(Input.GetKey(KeyCode.UpArrow))
    {
        Debug.Log("Up");
    }
    // Unity6
    if(Keyboard.current.UpArrowKey.isPressed)
    {
         Debug.Log("Up");
    }
}

Input放的位置

一般来说，需要放在 Update() 里面，因为 Update会每帧监听是否有输入。但是在这个项目中，可以直接放在 FixedUpdate() 里，因为我们使用的是 isPressed，就是说如果一直有按键的动作（isPressed/ GetKey），那么即使在固定帧率（FixedUpdate）监听的情况下，也是可以被检测到的。但是如果使用监听按下/抬起键一瞬间的API（GetKeyDown/ GetKeyUp），那么建议放在 Update 中，因为放在FixedUpdate中可能会错过。

此外，关于物理特性的更新，一律需要放在 FixedUpdate 中。

如果不得不放在 Update 中，一定要乘以 Time.deltaTime，以确保在不同帧率的计算机上移动的速度是一样的。

虽然在 FixedUp 里无需加上 Time.fixedDeltaTime，但是加上也无所谓

坐标系的设定

由于采用了visual和logic分离的方式，所以要确保坐标系设置为 Pivot 和 Local。因为如果设置为 Center，那么中心点将是子物体和父物体之间的中心位置，设置为 Pivot，中心会是各个物体本身的中心点。

而在此项目中我们希望按下向上箭头键后，lander朝着自己本身的上方移动，那么需要将坐标参考设置为 Local。如果设置为 Global，那么不管lander本身朝向何方，我们按下向上箭头键，lander会永远朝着屏幕上方移动。

Landing 的实现思路

landing的判定有两个层面：

飞船需要以保持直立的状态着陆
飞船需要较为轻柔地着陆

从着陆的轻重层面，使用 Collision.relativeVelocity)来判断。这是Collision的一个属性，描述两个碰撞对象的相对线性速度（只读）。

着陆角度判定的实现，则使用两个向量（物体本身的向上向量transform.up和世界坐标的向上向量Vector2.up）的点乘值来进行判断。

//============ Lander.cs ===========
private void OnCollisionEnter2D(Collision2D other)
{
    float softLandingVelocityMagnitude = 3f;	// 根据游戏表现的数值设定
    if (other.relativeVelocity.magnitude > softLandingVelocityMagnitude)
    {
        print("Landing too hard!");
        return;
    }

    float minDotVector = 0.92f;	// 根据游戏表现的数值设定
    float dotVector = Vector2.Dot(Vector2.up, transform.up);
    print(dotVector);
    if (dotVector < minDotVector)
    {
        print("landing angle too steep!");
        return;
    }
    print("Safe landing!");
}

如何设定某些判定的值？

如果某些值不知道设置多少合适，可以在 console 中打印出来，然后在游戏中看不同的情况显示不同的值来决定。比如此项目中，关于landing/ crash的判定就是这样做的。

不要使用字符串来识别游戏物体

字符串只能用在文本中，不要用它来查找物体或者使用Unity自带的Tag，因为非常容易出错，比如大小写没搞清、拼错或者不当心在名字后带了一个空格，都会被判定为查找失败。

使用脚本来查询物体。

// 识别是否是landing pad
if (other.gameObject.TryGetComponent<LandingPad>(out LandingPad landingPad))
{
    print("landing pad");
}

推力特效的实现

同样出于解耦的考虑，lander.cs 里不应该有 visual 相关的代码，所以使用事件来处理。

另外，粒子系统和 transform.position 一样是只读的，意味能无法直接修改的，所以需要通过 EmissionModule 来间接得修改：

1
2

ParticleSystem.EmissionModule emissionModule = leftThrusterParticalSystem.emission;
emissionModule.enabled = false;

`Time.deltaTime` 和 `Time.fixedDeltaTime`

`deltaTime` 在 `Update()` 中的使用

• 目的：补偿可变帧率 • Update() 的调用频率取决于帧率（30fps、60fps、144fps 等都不同） • deltaTime 记录每帧的实际时间间隔 • 通过乘以 deltaTime，确保物体在不同帧率下以相同的实际速度移动

`Time.fixedDeltaTime` 在 `FixedUpdate()` 中的使用

• 目的：使用固定时间步长进行物理模拟 • FixedUpdate() 以固定间隔调用（默认 0.02 秒，即 50 次/秒），不受帧率影响 • Time.fixedDeltaTime 是这个固定值（通常是常量） • 物理引擎需要固定时间步长来保证模拟的稳定性和可预测性

两者的关键区别

	Update() + deltaTime	FixedUpdate() + fixedDeltaTime
时间间隔	可变（取决于帧率）	固定（默认 0.02 秒）
作用	补偿帧率差异	保证物理模拟稳定
适用场景	渲染、输入、非物理逻辑	物理计算、Rigidbody 操作

`EventHandler`

因为这个项目规模较小，且 GameManager 统管所有游戏数据，而且 Lander 又是游戏的核心，所以在 Lander.cs 中使用 GameManager的单例没有问题（Lander与GameManager紧密耦合）。另一种策略是，仍然使用监听的方式，通过 EventHandler让GameManager中的数据根据在 Lander.cs中的监听结果做出反应。此项目采用了第二种方式。

//=============== Lander.cs ===============
private void OnTriggerEnter2D(Collider2D other)
{
    // ...

    if (other.gameObject.TryGetComponent(out CoinPickup coinPickup))
    {
        OnCoinPickup?.Invoke(this, EventArgs.Empty);
        coinPickup.DestroySelf();
    }
}

//============== GameManager.cs =============
public class GameManager : MonoBehaviour
{
    private int score;

    [SerializeField] private Lander lander; 

    private void Start()
    {
        lander = lander.GetComponent<Lander>(); // 因为是获取另一个无关联的游戏物体的组件，所以放在Start里
        lander.OnCoinPickup += Lander_PickupCoin;
    }

    private void Lander_PickupCoin(object sender, EventArgs e)
    {
        AddScore(500);
    }

    private void AddScore(int addScoreAmount)
    {
        score += addScoreAmount;
        print(score);
    }
}

其中 Lander_PickupCoin 中的参数 object sender 和 EventArgs e 即使在方法体内没有被使用，也必须保留在参数列表中。原因是：

匹配事件签名：lander.OnCoinPickup 事件期望一个特定格式的处理器方法
C# 事件模式：这是 .NET 的标准事件处理器模式，必须匹配 EventHandler 委托的签名

如果移除这些参数，代码将无法编译。

参数的用途：

• object sender：告诉你是哪个对象触发了事件（这里是 lander 实例） • EventArgs e：传递事件数据（比如捡到的金币价值）

如果需要明确表示“不需要使用这些参数”，可以用“弃元（Discards）”的写法表示：

private void Lander_PickupCoin(object _, EventArgs _)
{
    AddScore(500);
}

EventHandler 中使用参数的例子

比如，在“根据飞船着陆质量时叠加不同的分数”这一机制的实现上：

//========== Lander.cs ==========
public event EventHandler<OnLandedEventArgs> OnLanded;     // 不同着陆效果有不同的分数，所以给EventArgs传入一个分数的参数
public class OnLandedEventArgs : EventArgs
{
    public int score;
}

// 飞船在平台上的着陆
private void OnCollisionEnter2D(Collision2D other)
{
	// ...

    int score = Mathf.RoundToInt(landingSpeedScore + landingAngleScore) * landingPad.GetScoreMultiplier();
    print("score: " + score);
    OnLanded?.Invoke(this, new OnLandedEventArgs	// 在Invoke时传入score参数
    {
        score = score,
    });
}

//============ GameManager.cs ===========
public class GameManager : MonoBehaviour
{
    // ...

    // 实际使用score参数
    private void Lander_OnLanded(object sender, Lander.OnLandedEventArgs e)
    {
        AddScore(e.score);
    }
}

临时给字体添加颜色的方法

`1`	`titleTxtMesh.text = "<color=#ff0000>CRUSH!</color>";`

使用状态机来设置游戏的状态

用enum设置几个游戏状态，然后和按键结合。这个过程在Lander/ Player脚本中完成，还是非常简便的。

//============ Lander.cs ============
public enum State
{
    WaitingToStart,
    Normal,
    Gameover
}

 private void FixedUpdate()
 {
     switch(state)
     {
         default:
         case State.WaitingToStart:
             if (Keyboard.current.upArrowKey.isPressed ||
                Keyboard.current.rightArrowKey.isPressed ||
                Keyboard.current.leftArrowKey.isPressed)
             {
                 // 如果任意的键按下
                 // 重力设为正常并跳转到游戏状态
                 landerRigidbody2D.gravityScale = GRAVITY_NORMAL;
                 SetState(State.Normal);
             }
             break;

         case State.Normal:
             if (fuelAmount <= 0)
                 return;

             if (Keyboard.current.upArrowKey.isPressed ||
                Keyboard.current.rightArrowKey.isPressed ||
                Keyboard.current.leftArrowKey.isPressed)
             {
                 ConsumeFuel();
             }

             if (Keyboard.current.upArrowKey.isPressed)
             {
                 landerRigidbody2D.AddForce(force * transform.up * Time.fixedDeltaTime);
                 // 播放消息
                 OnUpForce?.Invoke(this, EventArgs.Empty);
             }

             if (Keyboard.current.leftArrowKey.isPressed)
             {
                 landerRigidbody2D.AddTorque(turnSpeed * Time.fixedDeltaTime);
                 OnLeftForce?.Invoke(this, EventArgs.Empty);
             }

             if (Keyboard.current.rightArrowKey.isPressed)
             {
                 landerRigidbody2D.AddTorque(-turnSpeed * Time.fixedDeltaTime);
                 OnRightForce?.Invoke(this, EventArgs.Empty);
             }
             break;
         case State.Gameover:
             break;
     }      
 }

爆炸特效的实现：

同样通过事件的方法完成。但是需要注意的是，它（OnLanded）的注册并没有像推力特效那样直接注册在 Awake 中，而是注册在 Start 中。因为以下三个原因：

一次性事件：整个游戏过程只触发一次
可能依赖其他系统：爆炸效果、游戏状态管理等可能需要在其他对象的 Awake() 中初始化
不需要立即准备：着陆不会在游戏开始的瞬间发生

总结将爆炸特效放在 Start 中的好处：

代码组织：将初始化逻辑（高频事件）和游戏逻辑（一次性事件）分开
避免潜在问题：如果其他脚本的 Awake() 中也订阅了 OnLanded，使用 Start() 可以确保订阅顺序更可控

点击按钮的操作

项目中没有使用“在面板中绑定按钮”的方法，而是直接写在代码中：

[SerializeField] private Button nextBtn;

private void Awake()
{
    nextBtn.onClick.AddListener(() =>	// 使用lambda表达式写法，因为没有参数、没有返回值，这样写最简便
    {
    	SceneManager.LoadScene(0);
    });
}

在新增了关卡后，使用一个回调函数来决定，点击按钮是进入下一关还是重玩这一关。用Action来存储函数，而不是使用它的事件功能，这种做法很灵活。

//=========== LandedUI.cs ============
public class LandedUI : MonoBehaviour
{
    // ...
    
    [SerializeField] private Button nextBtn;

    private Action nextBtnClickAction;

    private void Awake()
    {
        nextBtn.onClick.AddListener(() =>
        {
            nextBtnClickAction();
        });
    }

    private void Start()
    {
        Lander.Instance.OnLanded += Lander_OnLanded;

        Hide();
    }

    private void Lander_OnLanded(object sender, Lander.OnLandedEventArgs e)
    {
        if(e.landingType == Lander.LandingType.Success)
        {
            titleTxtMesh.text = "SUCCESSFUL LANDING!";
            nextBtnClickAction = GameManager.Instance.GoToNextLevel;	// 根据不同的情况决定回调哪个函数
        }
        else
        {
            titleTxtMesh.text = "<color=#ff0000>CRUSH!</color>";
            nextBtnClickAction = GameManager.Instance.RetryLevel;
        }

       // ...
    }
}

Level number 不变化的处理

将 levelNumber设置为普通变量，因为在场景重载时会销毁其中的 GameManager，所以会导致场景默认值仍为1，无法进入下一场景的情况。

教程中使用的处理方式是将 levelNumber设置为static，这样它保留在内存中，当场景中所有的东西被新建时，新的GameManager会重新读取到它，从而加载到下一关。

在关卡开始时展示全景地图

因为每一关的地图都不一样，所以这个脚本需要挂在每一关上。使用控制CinemachineCamera的方法来切换游戏未开始时和游戏开始时的跟随对象。

由于 Unity 的 Cinemachine 2D（CinemachineVirtualCamera + Framing Transposer 2D）本身没有zoom的功能，所以需要自己写脚本来实现。

而在3D的模式下，CinemachineVirtualCamera 有内建的 Lens → Field of View（FOV）或 Orthographic Size 控制，可以直接当作 Zoom 使用。

新建一个空游戏物体 CinemachineCamera2D 挂载脚本

//============== CinemachineCameraZoom2D.cs ===============
public class CinemachineCameraZoom2D : MonoBehaviour
{
    private const int NORMAL_ORTHOGRAPHIC_SIZE = 10;

    public static CinemachineCameraZoom2D Instance { get; private set; }

    [SerializeField] private CinemachineCamera cinemachineCamera;

    private float targetOrthographicSize = 10f;

    private void Awake()
    {
        Instance = this;
    }

    private void Update()
    {
        cinemachineCamera.Lens.OrthographicSize = targetOrthographicSize;
    }

    public void SetTargetOrthographicSize(float targetOrthographicSize)
    {
        this.targetOrthographicSize = targetOrthographicSize;
    }

    public void SetNormalOrthographicSize()
    {
        SetTargetOrthographicSize(NORMAL_ORTHOGRAPHIC_SIZE);
    }
}

在 GameLevel 里设置放大的值，使得每一关的设置都很灵活

//============== GameLevel.cs ===============
public class GameLevel : MonoBehaviour
{
    [SerializeField] private float zoomedOutOrthographicSize;   // 这个值放在GameLevel里，这样每个level都可以自由设置

    public float GetZoomOutOrthographicSize()
    {
        return zoomedOutOrthographicSize;
    }
    
    // ...
}

在 GameManger 中具体设置

在关卡刚加载、玩家还未开始游戏时让 Cinemachine zoom out，显示全景；当玩家按下按键游戏开始时，设置Cinemachine的镜头范围恢复正常。

//============== GameManager.cs ==============
public class GameManager : MonoBehaviour
{
 	// ...

    private void LoadCurrentLevel()
    {
        foreach (GameLevel level in gameLevelList)
        {
            if (level.GetLevelNumber() == levelNumber)
            {
                GameLevel spawnedLevel = Instantiate(level, Vector3.zero, Quaternion.identity);
                Lander.Instance.transform.position = spawnedLevel.GetLanderStartingPos();

                // 用 cinemachine 展示地图
                // 本质就是将cinemachine的tracking target设置到地图中心
                // 而不是一开始就跟随lander
                cinemachineCamera.Target.TrackingTarget = spawnedLevel.GetCameraStartTargetTransform();
                // zoom out
                CinemachineCameraZoom2D.Instance.SetTargetOrthographicSize(spawnedLevel.GetZoomOutOrthographicSize());
            }
        }
    }

    private void Lander_OnStateChange(object sender, Lander.OnStateChangeEventArgs e)
    {
        // ...

        // 在游戏正常启动后，cinemachine继续跟随lander
        cinemachineCamera.Target.TrackingTarget = Lander.Instance.transform;
        // 取消zoom out， 镜头恢复正常设置
        CinemachineCameraZoom2D.Instance.SetNormalOrthographicSize();
    }
}

在镜头切换时实现平滑效果

//============== CinemachineCameraZoom2D.cs ===============
private void Update()
{
    // 实现镜头转换的平滑效果，使用Lerp
    float zoomSpeed = 2f;

    cinemachineCamera.Lens.OrthographicSize = 
        Mathf.Lerp(cinemachineCamera.Lens.OrthographicSize, targetOrthographicSize, Time.deltaTime * zoomSpeed);
}

Input 的改进（支持多个输入系统）

自己创建 InputActions => Edit Asset => Action Maps，在Action Maps中为 Player 添加输入，对 player 的三种操作（up/ left/ right）绑定对应的按键：

然后在面板上勾选创建C# class，这样可以直接通过脚本控制，是Code Monkey推荐的方法，而不是使用字符串。由此，我们自己创建的InputActions生成了一个自己的C#脚本。

创建自己的GameInput脚本

新建一个空游戏物体，在该物体上挂载一个新的脚本。这个脚本作为中间层，避免其他脚本直接依赖 InputActions.cs (紧密耦合)。这样的好处有：

解耦 - 游戏逻辑不直接依赖 InputActions 实现
统一入口 - 所有输入通过一个地方管理
易于测试 - 可以轻松模拟输入（Mock GameInput）
灵活扩展 - 未来想添加输入记录、重放功能时只需修改 GameInput

扩展

旧输入系统的缺点

Unity的旧输入系统（Input.GetKey(), Input.GetAxis()等）存在以下问题：

硬编码输入检测 - 代码中直接写死键位（如 Input.GetKey(KeyCode.W)）
难以重新绑定 - 玩家无法自定义键位
多设备支持差 - 处理手柄、触摸屏等不同设备很复杂
缺乏灵活性 - 输入逻辑分散在各处，难以维护

新 Input System的优势

InputActions 提供：

配置驱动 - 通过可视化编辑器配置输入，无需修改代码
设备无关 - 同一个Action可以同时支持键盘、手柄、触摸
易于重新绑定 - 运行时动态修改键位
更好的性能 - 事件驱动而非每帧轮询

良好实践

因为输入的本质也是一种实践，所以需要相应地调用 Enable 和 Disable ：

当调用Enable时，内部会发生：

向 Unity 的输入系统注册监听器
开始接收来自硬件的输入事件（键盘、手柄等）
消耗系统资源和内存

当调用Disable时，内部会发生：

取消所有监听器的注册
停止处理输入事件
释放相关资源

private void Awake()
{
    // ...
    
    inputActions = new InputActions();
    inputActions.Enable();
}

private void OnDestroy()
{
    inputActions?.Disable(); // 记得清理

    // ...
}

触屏输入

GamePad 的绑定和键盘绑定没有区别。触屏输入稍有区别。

在 Canvas 中新建一个空游戏物体 TouchUI
在 TouchUI 下面创建三个 UIImage 的圆
给三个圆设置 On-Screen Button 组件
可以通过simulator来查看在不同触摸设备上的效果

JoyStick输入

不同于按键，手柄的 Action 类型要选择 Value => Vector2。

然后和按键的输入一样，在相应的脚本中添加即可。

使用 SceneLoader 来管理场景

为了避免在加载场景时使用“magic number” SceneManager.LoadScene(0);，我们使用脚本来控制场景的加载。

因为它会在全局存在，所以将之设置为一个无需继承 MonoBehavior 的静态类。注意，这样一来，类里的所有成员都必须是静态的。

此外，教程中为了避免使用 magic number 和直接使用 string，采用了将场景设置为 enum 的策略。

//============ MainMenuUI.cs ============
public class MainMenuUI : MonoBehaviour
{
    [SerializeField] private Button playBtn;
    [SerializeField] private Button quitBtn;

    private void Awake()
    {
        playBtn.onClick.AddListener(() =>
        {
            SceneLoader.LoadScene(SceneLoader.Scene.GameScene);
        });

        quitBtn.onClick.AddListener(() =>
        {
            Application.Quit();
        });
    }
}

//============== SceneLoader.cs ===============
public static class SceneLoader 
{
    public enum Scene
    {
        MainMenuScene,
        GameScene
    }

    public static void LoadScene(Scene scene)
    {
        SceneManager.LoadScene(scene.ToString());
    }
}

保持背景音乐在关卡切换时不从头播放

可以通过将音乐播放的时间设置为静态的来处理。（需要跨越关卡保持统一数据的，此教程中都是通过设置为static来解决）。

public class MusicManager : MonoBehaviour
{
    private AudioSource musicAudioSource;
    private static float musicTime = 0f;

    private void Awake()
    {
        musicAudioSource = GetComponent<AudioSource>();
        musicAudioSource.time = musicTime;
    }
    private void Update()
    {
        musicTime = musicAudioSource.time;
    }
}

扩展

关于事件的取消注册

在这个项目中多处用到了事件机制来实现代码的解耦，但是绝大多数情况没有进行取消注册的操作。但这并非最佳实践。

在以下情况下，不取消操作暂时是安全的：

相同的生命周期：LanderVisual 和 lander 组件在同一个 GameObject 上

`1`	`lander = GetComponent<Lander>(); // 同一个对象`

同时销毁：当 lander 爆炸时，整个 GameObject 被禁用

`1`	`gameObject.SetActive(false); // LanderVisual 和 Lander 一起被禁用`

Unity 会在对象销毁时自动清理这些引用

最佳实践是使对象在被销毁时取消注册：

private void OnDestroy()
{
    if (lander != null)
    {
        lander.OnUpForce -= Lander_OnUpForce;
        lander.OnLeftForce -= Lander_OnLeftForce;
        lander.OnRightForce -= Lander_OnRightForce;
        lander.OnBeforeForce -= Lander_OnBeforeForce;
        lander.OnLanded -= Lander_OnLanded;
    }
}

以下情况下必须进行取消注册的操作：

订阅者生命周期比发布者短
订阅者可能被多次创建/销毁（不取消注册会导致重复订阅）
跨场景的事件

养成取消注册的习惯是更安全的做法，可以避免：

内存泄漏

重复触发

难以追踪的 bug

应该始终遵循：注册在哪里，就在对应的清理方法中取消注册

取消注册的地方

取消注册的地方一般有 Destroy 和 Disable 两个，具体应该怎么选择？根据事件取消注册的时机选择。

核心原则：配对原则

事件的注册和取消注册应该在对应的生命周期方法中配对：

注册位置	取消注册位置	使用场景
Awake() / Start()	OnDestroy()	对象生命周期内只需注册一次
OnEnable()	OnDisable()	对象会被重复启用/禁用

visual 和 logic 分开

在此项目里，Code Monkey将visual的所有脚本也都挂在主游戏物体上，而sprite只是一张干净的图片。这种做法适用于：

小型项目
视觉简单
没有皮肤系统
没有复杂动画
没有多层视觉组件
逻辑和视觉的耦合度低

还有另一种做法，是将负责visual的脚本放在sprite的子物体上，这种做法在大型项目中常用，适用于：

角色有多层视觉
有皮肤系统
有动画状态机
有 UI 绑定
有粒子、特效、灯光
有多人同步（视觉不参与同步）

优点：

完全解耦
视觉可替换
逻辑可复用
Prefab 更模块化
更适合大型项目

Polish

Code Monkey一再强调polish的重要性，我也非常认同，但是我学习这门课程主要是为了看专业独立游戏开发者如何用clean code、以模块化的方式开发松耦合的、可扩展的游戏，所以polish部分就先不做了。

关于polish的各种技巧，我计划学习一门课程去掌握。

在此记录一下code monkey在课程中所用的插件，今天我要用的时候可以参考使用：

Feel（Code Monkey有review视频）
All in 1 Sprite Shader （Code Monkey有review视频）
Text Animatior
Hot Reload
Code Monkey Toolkit

复盘和下一步

即使这只是一门入门课程，我还是学到了很多东西，最主要的包括：

visual 和 logic 分离的原则

就这个体量的项目而言，sprite上不挂任何脚本，全部放在空游戏物体中
单一职责原则

每个类、每个函数都相对小，只负责一件事件
观察者模式

通过观察者模式进行了大量解耦，包括UI、音效等
使用C#标准的EventHandler的优点

除了可以正常命名外，还可以添加参数，有时非常有用
InputSystem的用法

相较于老的输入系统而言，新的输入系统连接不同输入设备时几乎不需要改代码，很方便

用prefab的方式来新增关卡

我第一次知道这种方式。总结对比在关卡设计时使用scene和prefab：

项目	Scene 做关卡	Prefab 做关卡
适合的游戏类型	大型场景、剧情关卡、独立世界	多关卡、重复结构、程序生成、roguelike
加载方式	切换场景（LoadScene）	在同一场景中实例化 Prefab
编辑体验	直观、所见即所得	模块化、可组合
性能	场景切换有开销	Prefab 实例化更快
复用性	低（每个 Scene 独立）	高（Prefab 可重复使用）
动态生成	不方便	非常方便
多人协作	场景容易冲突	Prefab 冲突更少
关卡数量	少量关卡	大量关卡

下一步：

原版课程里还有一些Bonus的游戏机制：

货物运输
钥匙开关
风区
动态陨石
大炮射击

我计划先放一下，等再学习练习一段时间后尝试自己实现。

另外，Code Monkey是我跟随学习的第一位专业游戏开发者，我会再学习2名专业游戏开发者的课程，学习他们的代码风格和对游戏整体的架构，然后尝试形成我自己的风格。

【SOLID】SOLID原则项目实践

Mon, 19 Jan 2026 09:54:30 +0800

教程参考：Udemy-Niraj Vishwakarma

素材来源：

SOLID原则简介

意大利面条式代码

这种代码指的是一团乱麻，所有行为都高度耦合的代码。比如，在 PlayerController.cs 这个脚本中，玩家的 Move(), Attack(), Jump()…等等行为都写到了一起，此外，还有 PlayAudio 等其他功能。

这样的代码极其脆弱且难以扩展，它就像意大利面一样，由于各个部分都缠绕在一起，你抽取了其中的一根，可能导致多个bug的出现。

解决方案：

抛弃意大利面条式的代码结构，改为模块化结构。

在快速制作demo或者小型游戏时可以使用意大利面条式代码以快速验证效果。

但是如果预计将来项目会越来越大，新引入的游戏物体和功能会越来越多，那么事先建构良好的架构和模块化将是非常重要的。

SOLID原则是什么

总的来说它共有五大原则：

单一职责原则 Single Responsibility Principle (SRP)
开闭原则 Open-Closed Principle (OCP)
里氏替换原则 Liskov Substitution Principle (LSP)
接口隔离原则 Interface Segregation Principle (ISP)
依赖倒置原则 Dependency Inversion Principle (DIP)

单一职责原则

基本原则

一个脚本，一个功能。SRP将大类的功能拆分成一个个小类，这些小类拥有独立的功能，可以复用且相互之间没有影响。就像乐高的小块积木一样，你可以用它来搭建各种风格各异的大模型。

好处

当每个脚本都有清晰的职责时，你就能随意替换它而不害怕破坏游戏的其他部分。

开闭原则

基本原则

类/模块/函数，对扩展开放、对修改关闭。

好处

通过创建新的类来添加新功能，从来避免破坏原来类的独立性，以此提升代码的模块化。

如何执行

为新的功能创建新的类
创建接口/抽象类，在具体的功能类中去实现接口/抽象类中的方法
用抽象方法去与不同的功能交互，而不是直接调用它们
提升多态的应用

里氏替换原则

基本原则

超类/父类物体应该可以被其子类替代而不影响其功能。

好处

允许超类/父类物体可以被其子类替代，而不用直接引用每个子类，这样可以确保系统在引入新的变量时的灵活性和可扩展性。

如何执行

创建基类并声明所有的方法
给具有相似行为的物体创建为子类
在其他需要交互的脚本中，直接引用父类而非子类

接口隔离原则

基本原则

一个类不应该去依赖一个它不会使用的方法。

总结

只写需要的、只执行相关的。

依赖倒置原则

基本原则

高级模块不应该与低级模块耦合，两者都应该依赖于抽象函数。

总结

依赖于抽象函数，而不是具体的实现。

如何执行

用接口创建抽象函数
通过具体的类来实现接口
用接口与具体的类交互

实践项目

我们通过一个2D的坦克飞机大战小游戏来展示在Unity游戏开发中如何实践SOLID原则。

核心玩法：

屏幕左侧有两种坦克，一种轻型坦克，玩家可以通过按下“L”来操作它；另一种是重型坦克，通过“H”键来操作
轻型坦克可以左右移动、旋转炮管、发射轻型炮弹
重型坦克不能移动，但是可以旋转炮管、发射重型炮弹
屏幕右侧有可以向左移动的飞机，玩家通过击中它们来增加屏幕上的分数
失败条件：如果飞机撞到坦克，坦克受损失活（无法通过按键操作）。两辆坦克均失活时，玩家失败

游戏/功能拆解

内容

背景图片、坦克（轻型和重型）、子弹（轻型和重型）、飞机、UI（分数、开始界面、游戏界面、结束界面）、音效（开火、飞机被击中、坦克被击中）

逻辑

游戏开始，按下L键可以激活轻型坦克（移动、旋转、发射炮弹）
按下H键可以激活重型坦克（旋转、发射炮弹）
飞机从右往左飞，右侧屏幕飞入、左侧屏幕飞出
坦克被飞机撞到即失活
两家坦克都失活，游戏结束

模块整理

开发步骤

场景摆放
坦克部分的开发
- 移动和旋转
- 开火
- 实现两种坦克的选择
- 生命值
飞机部分的开发
- 飞机预制体
- 飞机的生成
- 生命值
游戏管理部分开发
- 配置Game Events
- AudioManager
- UIManager
- GameManager

功能实现及遵循的原则

1. 坦克的移动

在坦克的设计上遵循ISP（接口隔离）和DSP（依赖倒置）。

2. 坦克的开火

在开火时两种弹药的设计上遵循开闭原则（OCP）。我们在每次增加新的种类弹药时应该只做扩展，而不应该对 TankFire.cs 进行修改。在 TankFire.cs 中，应该通过接口而非直接调用相应炮弹的预制体。

此处需要注意的是，由于两种子弹都是经过接口与 TankFire.cs 交互的，但是接口不继承自 MonoBehaviour，无法实例化，所以需要将其隐式转换为 Component 来解决。

public class TankFire : MonoBehaviour
{
    [SerializeField] private IProjectile iProjectile;
    [SerializeField] private Component projectileComponent;
    [SerializeField] private Transform firePos;

    private void Start()
    {
        iProjectile = projectileComponent as IProjectile;
    }

    private void Update()
    {
        if (Input.GetKeyDown(KeyCode.Space))
        {
            if (iProjectile != null)
                iProjectile.Fire(firePos);
        }
    }

3. 坦克选择器的实现

在这一部分遵循里氏替换（LSP）的原则进行设计。

如果项目比较小的话不用创建单独的 LightEngine.cs 和 HeavyEngine.cs ，全部写在 TankEngine 这个类中也可以。

4. 坦克生命值的实现

遵循依赖倒置原则（DIP），使用一个 IDamageable 的接口来和具体的类交互。这个具体的类可以是飞机、也可以是其他的碰撞物，如子弹、导弹等。

5. 飞机的移动

这部分仿照坦克移动的方式，复用 ImoveUp.cs 的代码，同样采用接口的方式实现，为将来新种类飞机的加入留下空间。

6. 飞机和子弹的自动销毁

我在此处采用统一的脚本 DestroyByTime.cs ，遵循单一职责原则，并未按照课程的方式分别处理。

7. 坦克、子弹、飞机的碰撞检测和生命值联动

这是对第四点的依赖倒置原则的最终实现。由于子弹和飞机都是碰撞后即销毁的情况，所以并没有直接实现 IDamageable接口，在坦克的生命值系统中实现了接口，这样以后即使新增了不同的子弹，对坦克造成不同的伤害，都能轻松实现。在对飞机或者其他类型的敌人中，如果需要设计不同类型的伤害，也可以设计为继承接口的方式灵活实现。

//========== IDamageable接口 ==========
public interface IDamageable
{
    public void TakeDamage(float damageValue);
}

//================ 坦克的生命值系统 ===============
public class HealthSystem : MonoBehaviour, IDamageable
{
    private float _health = 100f;
    [SerializeField] private Image healthProgressBar;
    [SerializeField] private TankEngineBase currentTankEngine;

    public void TakeDamage(float damageValue)
    {
        _health -= damageValue;
        if (_health <= 0)
        {
            _health = 0;
            currentTankEngine.StopEngine();
        }

        float progressBarValue = _health / 100;
        healthProgressBar.fillAmount = progressBarValue;
    }
}

//================ 子弹生命值 =================
public class ShellHealth : MonoBehaviour
{
    [SerializeField] private float damage = 100f;

    private void OnCollisionEnter2D(Collision2D other)
    {
        IDamageable damageable = other.gameObject.GetComponent<IDamageable>();
        if(damageable != null)
        {
            damageable.TakeDamage(damage);
        }
        Destroy(gameObject);
    }
}

//============= 飞机的生命值 ==============
public class DroneHealth : MonoBehaviour
{
    [SerializeField] private float damage = 20f;
    private void OnCollisionEnter2D(Collision2D other)
    {
        // 通过接口调用TakeDamage
        IDamageable damageable = other.gameObject.GetComponent<IDamageable>();
        if (damageable != null)
        {
            damageable.TakeDamage(damage);
        }
        Destroy(gameObject);
    }
}

8. 用观察者模式对UI、音效、游戏状态进行管理

把下面的事件进行注册，这样通过统一的更新接口，观察者们在事件发生变化的时候可以相应被调用。本质是一个监听和响应系统。同时，这样遵循了单一职责原则，在 AudioManager.cs 和 UIManager.cs 等脚本中，只负责播放音效或管理UI的作用。

关于SOLID原则的建议

先想简单的解决方案
永远不要强迫自己使用SOLID原则，只在需要的时候使用（这也是我的体会）
不要过分设计，尤其是你的设计已经超过了项目本身的范围
永远试着使用模块化方式，让每个独立的模块像乐高玩具一样可以被重复使用（这是我在其他课程中学到的最有用的方法之一，真的非常省时省力）
最初在代码设计上使用SOLID原则肯定会多花时间，但是如果是长远的扩展性很多的项目，这些投入肯定是值得的
应用 => 失败 => 学习 => 应用 => 你会得到惊喜！

项目拓展与复盘

拓展

在本项目基础上增加了以下部分：

增加中型坦克
- 玩家通过按下“M”键来操作
- 可上下移动，但是移动速度慢于轻型坦克、移动范围小于轻型坦克
根据坦克类型给坦克增加不同的子弹：激光、导弹
- 轻型坦克：激光（最少cooldown time），给敌人造成伤害最小，同时发射扇形的5束
- 中型坦克：子弹（中等cooldown time），给敌人造成伤害中等
- 重型坦克：导弹（cooldown time最长），给敌人造成伤害最大
增加重型飞机
- 在飞行中有上下随机小范围移动的变化
改变飞机的生成规则，让游戏的难度随时间而增加
- 游戏开始，重型飞机生成概率较低，随着时间而升高
不同坦克收到伤害程度不同，重型坦克最慢

项目架构总览

项目采用了组件式架构 + 事件驱动 + 策略模式的混合设计。

文件夹结构

Assets/
├── Audio/              # 音效资源（射击、爆炸、受伤）
├── Fonts/              # 字体资源
├── OtherResources/     # 第三方美术资源
├── Prefabs/            # 预制体
│   ├── Drone/          # 无人机预制体（Light、Heavy）
│   ├── Projectile/     # 弹药预制体（3种弹药类型）
│   └── Tank/           # 坦克预制体（Light、Medium、Heavy）
├── Scenes/             # 场景文件
├── Scripts/            # 脚本核心
│   ├── Drone/          # 无人机逻辑
│   ├── GameUtil/       # 游戏事件系统
│   ├── Mgr/            # 管理器（Game、Audio、UI）
│   ├── Projectile/     # 弹药逻辑
│   └── Tank/           # 坦克逻辑
│       ├── Engine/     # 引擎/选择系统
│       ├── Fire/       # 射击系统
│       ├── Health/     # 生命系统
│       └── Move/       # 移动系统
└── Sprites/            # 精灵图资源

架构总览

模块	职责	核心类
Tank/Engine	坦克引擎切换系统，玩家可通过 L/M/H 键切换不同类型坦克	`TankEngineBase` → `TankEngineLight/Medium/Heavy`，`TankEngineSelector`
Tank/Move	坦克移动系统，不同坦克有不同移动逻辑	`TankMoveBase` → `LightTankMove/MediumTankMove/HeavyTankMove`，`IMoveY`，`TankRotate`
Tank/Fire	射击系统，不同弹药类型通过 `IProjectile` 接口多态化	`TankFire`，`IProjectile` → `LightShell/MediumShell/RocketShell/LaserShellProjectile`
Tank/Health	生命系统，使用 `IDamageable` 接口实现伤害统一接口	`HealthSystem`，`IDamageable`
Drone	敌方无人机系统，含生成、移动、受击	`DroneMoveBase` → `LightDroneMove/HeavyDroneMove`，`DroneHealth`，`DroneSpawner`
Mgr	全局管理器	`GameMgr`（游戏流程）、`UIMgr`（UI面板/计分）、`AudioMgr`（音效）
GameUtil	全局事件总线	`GameEvents`（静态事件类）

架构图

代码复用

观察者模式的写法

套路都是一样的，以 AudioManager 为例:

//======== 1. 注册事件 =========
//========= GameEvents.cs =========
public static class GameEvents
{
    public static Action OnGameStarted;
    public static Action OnGameOver;
    public static Action OnTankFired;
    public static Action OnTankDamaged;
    public static Action OnDroneDestroy;
}

//========= 2. 在各个所需的地方监听事件 =========
//========= TankFire.cs =========
private void Update()
{
    if (Input.GetKeyDown(KeyCode.Space))
    {
        GameEvents.OnTankFired?.Invoke();
        if (projectile != null)
        {
            projectile.Fire(firePos);
        }

    }
}

//========== HealthSystem.cs ==========
public void TakeDamage(int damageValue)
{
    GameEvents.OnTankDamaged?.Invoke();
    _health -= damageValue;
    if (_health <= 0)
    {
        _health = 0;
        currentTankEngine.StopEngine();
    }

    float progressBarValue = _health / 100;
    healthProgressBar.fillAmount = progressBarValue;
}

//========== DroneHealth.cs ===========
public void TakeDamage(int damageValue)
{
    GameEvents.OnDroneDestroy?.Invoke();    // 飞机被子弹击中才会播放声音
    Destroy(gameObject);
}

//========== 3. 统一在AudioManager中根据监听的结果做出反应 ==========
//========== AudioMgr.cs =========
public class AudioMgr : MonoBehaviour
{
    [SerializeField] private AudioClip droneDestroyClip;
    [SerializeField] private AudioClip tankFiredClip;
    [SerializeField] private AudioClip tankDamagedClip;
    [SerializeField] private AudioSource audiosource;

    private void PlayDroneDetroyAudio()
    {
        audiosource.PlayOneShot(droneDestroyClip);
    }
    
    private void PlayTankFiredAudio()
    {
        audiosource.PlayOneShot(tankFiredClip);
    }
    
    private void PlayTankDamagedAudio()
    {
        audiosource.PlayOneShot(tankDamagedClip);
    }
    
    private void OnEnable()
    {
        SubscribeEvents();
    }

    private void OnDisable()
    {
        UnSubscribeEvents();
    }

    private void SubscribeEvents()
    {
        GameEvents.OnDroneDestroy += PlayDroneDetroyAudio;
        GameEvents.OnTankFired += PlayTankFiredAudio;
        GameEvents.OnTankDamaged += PlayTankDamagedAudio;
    }
    
    private void UnSubscribeEvents()
    {
        GameEvents.OnDroneDestroy -= PlayDroneDetroyAudio;
        GameEvents.OnTankFired -= PlayTankFiredAudio;
        GameEvents.OnTankDamaged -= PlayTankDamagedAudio;
    }
}

事件总线系统 — `GameEvents`

在任何项目中创建类似的静态事件类，用于模块间解耦通信。只需修改事件名称即可适配不同游戏。

public static class GameEvents
{
    public static Action OnGameStarted;
    public static Action OnGameOver;
    public static Action OnTankFired;
    public static Action OnTankDamaged;
    public static Action OnDroneDestroy;
}

接口驱动的伤害系统— `IDamageable`

所有需要受伤的对象（玩家、敌人、可破坏物）都实现此接口。攻击方只需调用 GetComponent<IDamageable>()?.TakeDamage()，完全解耦。

public interface IDamageable
{
    void TakeDamage(int damage);
}

项目中SOLID 原则应用分析

S — 单一职责原则 (Single Responsibility Principle)

坦克的移动、射击、旋转、生命被拆分为独立组件，而非放在一个巨大的 “Tank” 类中。这是 SRP 的典型实践。

类	职责
`TankMoveBase`	只负责移动逻辑
`TankFire`	只负责射击触发
`TankRotate`	只负责旋转瞄准
`HealthSystem`	只负责生命值管理
`AudioMgr`	只负责音效播放
`UIMgr`	只负责UI显示与计分
`GameMgr`	只负责游戏流程判定
`DroneSpawner`	只负责无人机生成
`DroneHealth`	只负责无人机受击逻辑

O — 开闭原则 (Open/Closed Principle)

弹药系统：IProjectile 接口使得添加新弹药类型（如 LaserShellProjectile、 RocketShellProjectile）时，不需要修改 TankFire 的代码，只需新建一个实现 IProjectile 的类
移动系统： IMoveY接口 + TankMoveBase允许新增坦克移动方式而不修改基类
无人机移动： DroneMoveBase允许通过继承扩展新的飞行行为（如 HeavyDroneMove 的随机偏移飞行）

L — 里氏替换原则 (Liskov Substitution Principle)

TankEngineBase的三个子类（TankEngineLight、TankEngineMedium、TankEngineHeavy）可以在TankEngineSelector 和 GameMgr中被无差别替换使用。
GameMgr.CheckEngine() 遍历 List<TankEngineBase>，调用 GetStatus()，不关心具体是哪种引擎
DroneMoveBase的子类同理，可以在需要 DroneMoveBase 的地方互换

I — 接口隔离原则 (Interface Segregation Principle)

IMoveY：只定义 MoveY(float) 一个方法，不强迫实现者实现不相关的功能（如旋转、射击）
IProjectile：只定义 Fire(Transform) 一个方法，每种弹药只需关注"如何发射"
IDamageable：只定义 TakeDamage(int) 一个方法，任何可受伤对象实现它即可

接口粒度非常小，每个接口只包含一个方法，完美遵循 ISP。

D — 依赖倒置原则 (Dependency Inversion Principle)

DroneHealth中对伤害的处理依赖的是 IDamageable 接口而非具体的 HealthSystem 类：

1
2

IDamageable damageable = other.gameObject.GetComponent<IDamageable>();
damageable?.TakeDamage(damage);

TankFire依赖 IProjectile 接口来发射弹药，而非依赖具体的弹药类
TankMoveBase通过 this as IMoveY 将自身转为接口调用，高层逻辑依赖抽象而非具体实现

复盘

SOLID原则扩展性强，但是脚本量也是成倍增加。在最后用观察者模式写UI的时候几乎花了一整天，调试一个bug花了一个下午。对于初学者而言，在使用观察者模式的时候，监听代码放置的位置和其他代码的顺序也很重要，是很容易踩的坑。

另外，这是我第一次系统性地学习游戏的架构方式，在很多时候还是感觉比较抽象的，很多时候很难一下子想到。在做这个项目的时候，最直观的感受是项目扩展性确实很好，无需去老的脚本中改，只需要写新脚本新功能就可以了，也不存在新增一个功能多了三个bug的情况，这一点对大型项目或者是网络手游，真的非常重要。希望能随着我能力的不断提高、对优秀的复杂/大型项目见识的增加和个人项目复杂度的不断增加，提高我对架构的认知和实践能力。

【练手日志】Unity小游戏集锦 1

Sat, 10 Jan 2026 09:19:30 +0800

这一练手系列中的游戏都是非常小的，旨在帮我自己熟悉API的用法、锻炼思维逻辑能力，以及拓展思路，所以首要任务是快速完成原型、或者总结出一些小块的复用代码；项目整体架构和可扩展性等不在此类项目范围之内。

合成大西瓜

教程参考及素材来源：B站-游池汇

源码： on Gitee

游戏简介

《合成大西瓜》是一款由微伞游戏（Weisun Games）2021年初推出的休闲益智类网页小游戏，因其简单上手、魔性玩法和社交传播迅速走红。

核心玩法：

玩家通过点击屏幕，从上方随机掉落不同种类的水果（如葡萄、橙子、苹果等）。
相同水果碰撞后会合成更大的水果，例如两个葡萄合成一个樱桃，两个樱桃合成一个橙子，依此类推，最终目标是合成出最大的“西瓜”。
游戏采用类似“俄罗斯方块 + 2048”的机制：水果受重力影响堆叠，若堆积超过屏幕顶部，则游戏结束

游戏/功能拆解

内容

背景图片、墙壁和地板、水果（运动中水果、待命水果）、死亡判定线、UI（分数）、音效（落地、合成）

逻辑

待命水果，鼠标按下时在x轴跟随鼠标，松开鼠标水果落下
水果落地时，水果之间互相碰撞、带弹性效果，相同的水果碰撞在一起会合成更大的水果
水果如果抵达了死亡判定线，游戏失败，重新加载场景
显示当前的分数

开发步骤

场景摆放
给水果和场景等游戏物体添加重力、碰撞、弹性等组件
将水果做成预制体
创建待命水果跟随鼠标移动
待命水果在鼠标松开后落下
相同水果合成
水果碰到/超出死亡线的逻辑
显示UI分数
音效

遇到的问题及解决方法

1. 没有思路

仿照“把一只大象放进冰箱需要几步”，将要做的事尽可能拆成细到不能再细的步骤。开发步骤4为例，可以进一步细化为以下的步骤：

待命水果（1-4号水果）数组
待命水果生成点
随机从数组中生成待命水果
鼠标点下后获取鼠标的位置，并赋值给待命水果（只改变x轴的值，y和z轴保持不变）
边界检查（水果不能随鼠标一起超过两边墙壁）

2. 屏幕坐标与世界坐标的转换

// 屏幕坐标 -> 世界坐标
Vector3 screenPoint = Input.mousePosition; // 例如鼠标位置
Vector3 worldPoint = Camera.main.ScreenToWorldPoint(screenPoint);

// 世界坐标 -> 屏幕坐标
Vector3 worldPos = player.transform.position;
Vector3 screenPos = Camera.main.WorldToScreenPoint(worldPos);

需要注意的是，因为main camera在世界坐标中z轴的位置在-10，所以2D的普通游戏物体从屏幕坐标转为世界坐标要处理z轴（设置为0），否则会看不见（在main camera处）。

Unity的屏幕坐标原点在左下角

3. 延迟执行

`1`	`Invoke("funcName", second);`

4. 单例模式的赋值

// 在指定一个类为单例模式后，不要忘记在Awake中赋值
public class PlayerManager : MonoBehaviour
{
    public static PlayerManager Instance;
    
    public GameObject[] fruits;
    public Transform createPoint;
    [HideInInspector]
    public GameObject waitingFruit;

    private void Awake()
    {
        Instance = this;
    }
    
    // Other codes
}

5. 水果合成的逻辑

每个游戏物体的id都是唯一的，所以使用id来标识每一个物体。为了避免每个水果都合成一个更高级水果的情况，只允许id较大的那个水果生成更高等级的水果。

6. 自定义字体无法缩放大小

通过整体缩放解决（Scale）。

7. 落地时音效的频繁播放

设定当velocity超过一定数值时才播放音效，避免因为一点移动就播放音效从而感觉很杂乱的问题。

复盘

第一个练手的项目，代码上尽量都是自己写的，没有思路的时候才去看教程的思路，然后再自己写。遇到不会的API就翻阅自己以前的笔记或者查官方文档，感觉确实印象深刻了不少。

Demo完成了核心逻辑，虽然有一些小bug，比如在有几次测试的时候发现即使水果堆积超过了死亡线，还是没有重新加载的情况。还有合成到了大西瓜之后，需要做一个胜利的页面和场景等。待再练几个项目之后再回来处理吧。

代码复用

1. 各类“Manager”都可使用单例模式

// 以PlayerManager为例
public class PlayerManager : MonoBehaviour
{
    public static PlayerManager Instance;

    private void Awake()
    {
        Instance = this;
    }
    // Other codes
}

2. 游戏物体跟随鼠标移动

private void PlaceFruit()
{
    // 获取鼠标位置（屏幕坐标）
    // 将其转换为世界坐标
    Vector3 mousePos = Camera.main.ScreenToWorldPoint(Input.mousePosition);
    // 鼠标左键按下，待命水果随鼠标移动
    // 本例中水果只随鼠标位置在x轴移动
    if (Input.GetMouseButton(0))	
    {
        waitingFruit.transform.position = new Vector3(mousePos.x, waitingFruit.transform.position.y, 0);
    }
}

太空射击

教程参考及素材来源：B站-齐齐课-Plane

源码： on Gitee

游戏简介

《太空射击》（Space Shooter）是Unity官方的一个3D入门教程项目，旨在帮助初学者快速掌握 Unity 的基础开发流程，包括场景搭建、玩家控制、敌人生成、碰撞检测、UI 显示和音效集成等核心概念。此版本在原教程基础上进行了升级，加入了会发射子弹的敌人等。

核心玩法：

类型：2D太空射击游戏（3D俯视视角）
目标：操控飞船在太空中生存尽可能长时间，击落不断出现的敌人和小行星。
操作方式：
- 移动：使用 WASD 或方向键控制飞船在屏幕内自由移动
- 射击：按下鼠标左键发射子弹
敌人行为：
- 小行星和敌人从屏幕上方随机位置生成，以不同速度向下坠落，敌人会左右移动并发射子弹
- 玩家需躲避或摧毁它们，避免被撞击或者被敌人的子弹击中
失败条件：飞船被小行星/子弹击中即游戏结束
计分系统：每摧毁一个敌人获得分数，UI 实时显示当前得分

游戏/功能拆解

内容

场景搭建（背景缓慢向下移动）、动画（敌人爆炸、小行星爆炸、玩家左右移动时偏转、小行星翻转）、UI（分数）、音效（背景音乐、射击、击中）

逻辑

玩家可以上下左右移动、发射子弹
小行星在屏幕上方随机生成，匀速下落
敌人在屏幕上方随机生成、以更快的速度向下移动、同时左右移动并发射子弹
显示当前的分数
玩家被敌人子弹击中，或者玩家被小行星/敌人碰撞，玩家死亡，重新加载游戏场景

开发步骤

搭建背景环境
- 背景的循环移动
- 星尘特效添加
- 背景音乐添加
玩家部分的实现
- 玩家运动控制
- 玩家左右移动的偏转效果，速度越大偏转角度越大
- 实现玩家的射击
- 添加玩家子弹射击和音效
敌人和小行星部分的实现
- 随机生成小行星和敌人
- 小行星随机旋转效果
- 实现敌人的射击
- 实现敌人的左右移动（闪避）
特效：实现攻击和撞击效果
UI部分
- 搭建UI界面
- 实现UI显示逻辑

遇到的问题及解决方法

1. 背景的移动

让背景移动还是摄像机移动呢？通常选择让背景移动，因为游戏场景中还会有小行星、玩家、敌人等各种物体，保持摄像机不动是一种更简单的方式。

需要注意的是，和做“往复”有关的计算时，因为要与绝对时间同步，所以使用 Time.time；在做一般位移、计时、累加时，因为需要确保与帧率无法，使用Time.deltaTime。

// 位移的计算（一般使用API）
this.transform.Translate(Vector3.forward * 1 * Time.deltaTime, space.World); // 如果是自己坐标系：Space.Self

// 背景循环往复
private void ScrollBG()
{
    float distance = Mathf.Repeat(_scrollSpeed * Time.time, 30);
    transform.position = _startPos + distance * Vector3.forward * (-1);
}

2. 对刚体的运算要放在`FixedUpdate()`中

因为Update()中每一帧的时间可能不同，取决于设备的性能、运算的复杂程度等，所以如果将刚体运算放置其中可能会出现一些卡顿等情况。

// 通过对刚体的操作来控制玩家的运动
private void FixedUpdate()
{
    MovePlayer();
}

private void MovePlayer()
{
    float horizontalVel = Input.GetAxis("Horizontal"); // 0-1
    float verticalVel = Input.GetAxis("Vertical");
    Vector3 velocity = new Vector3(horizontalVel, 0, verticalVel);
    _playerRB.velocity = velocity * _speed;
    // Other codes
}

3. 边界检查的一种方法

通过在面板中直观地检查边界的位置，感觉比纯用代码控制简便。先在类内创建一个结构体并序列化，然后在代码中调用。(不要忘记将Border类实例化)

public class PlayerController : MonoBehaviour
{
    [Serializable]
    public struct Border
    {
        public float maxZ;
        public float minZ;
        public float minX;
        public float maxX;
    }
    
    [SerializeField] private Border _border;
    
    // Other codes
	private void MovePlayer()
    {
      	// Other codes
        
        // Border check
        float posX = Mathf.Clamp(_playerRB.position.x, _border.minX, _border.maxX);
        float posZ = Mathf.Clamp(_playerRB.position.z, _border.minZ, _border.maxZ);
        _playerRB.position = new Vector3(posX, 0, posZ);
    }
}

4. 利用刚体实现物体的偏转

// 物体绕y轴旋转30°
Quaternion rotation = Quaternion.Euler(0, 30, 0);

// 可以直接利用刚体的rotation属性
_playerRb.rotation = Quaternion.Euler(0, 0, _playerRb.velocity.x * (-1) * tilt);

5. “组件化（功能挂钩）”模式

把可复用的功能拆成小组件（例如 MoveController），再由具体行为脚本（例如 PlayerController / EnemyController）组合调用。

优点：复用性高、职责清晰、易测试、易维护；遵循 composition over inheritance。缺点：某些对象会挂多个小脚本，但这是合理的单一职责拆分，性能影响很小。 实践要点：保持组件单一职责、用接口/事件解耦、用 RequireComponent、把共享数据放到 ScriptableObject 或配置类、用 Prefab 组合复用。

“实践要点”有点难以理解。在“2048”项目中曾经看到过一次，以后对这方面的实践需要多加留意体会。

6. `GetComponent` 调用的位置/时机

在实践中推荐的做法是，如果同一物体上获取并缓存组件用 Awake()，如果依赖别的对象在 Awake() 中完成的初始化则放到 Start()。

// 要获得同一个物体MoveController身上的刚体组件
public class MoveController : MonoBehaviour
{
    private Rigidbody rb;

    private void Awake()	// 在Awake()中获取刚体组件
    {
        rb = GetComponent<Rigidbody>();
    }

    public void Move(Vector3 dir, float speed)
    {
        rb.velocity = dir.normalized * speed;
    }
}

// 依赖别的对象在 Awake() 中初始化的值，所以在 Start() 使用
public class EnemyAI : MonoBehaviour
{
    private MoveController move;
    private Transform player; // 假设 Player 在 Awake() 设置好

    private void Start()
    {
        move = GetComponent<MoveController>();	// 另一个对象MoveController在Start()中获取组件
        player = GameObject.FindWithTag("Player")?.transform; // 等待所有 Awake 完成后再查找使用更安全
    }

    private void Update()
    {
        if (player == null) return;
        Vector3 dir = (player.position - transform.position);
        dir.y = 0f;
        move.Move(dir, 3f);
    }
}

7. 协程的一般写法

需要注意以下几点：

定义返回类型为 IEnumerator 的方法，方法内使用 yield return 返回等待（null、new WaitForSeconds(...)、WaitForEndOfFrame 等）
用 StartCoroutine(MyCoroutine()) 启动；可用 StopCoroutine 停止
不要在主线程（比如 Start()）里写不会 yield 的 while(true)，那会卡死主线程

// 利用协程生成和销毁敌人
// 把循环放到协程里并用 Instantiate 生成敌人，用另一个协程在延时后销毁
private void Start()
{
    StartCoroutine(SpawnEnemyWave());
}

private IEnumerator SpawnEnemyWave()
{
    yield return new WaitForSeconds(startSpawnTime);
    while (true)
    {
        for (int i = 0; i < enemyCount; i++)
        {
            GameObject prefab = enemies[Random.Range(0, enemies.Length)];
            GameObject newEnemy = Instantiate(prefab);
            newEnemy.transform.position = new Vector3(Random.Range(-4, 5), 2, 10);
        }
        yield return new WaitForSeconds(spawnWaitingTime);  
    }
}

// Enemy和其子弹全部和Player的子弹一样，用KillBox统一销毁

8. 小行星自身旋转效果的实现

使用APIRandom.insideUnitSphere, 返回一个随机的 Vector3，方向和大小在单位球体内随机分布；然后通过乘以 rotationSpeed 会把这个向量缩放到期望的角速度大小；最后赋值给Rigidbody.angularVelocity：向量的方向表示旋转轴，向量的长度表示角速度（弧度/秒），所以刚体会绕该随机轴以该速度旋转。

 private void Start()
 {
     _rb.angularVelocity = Random.insideUnitSphere * rotationSpeed;
 }

9. 实现敌人发射子弹的两种方法

方法一：和玩家发射子弹的思路类似，用累加时间的方法。

方法二：使用APIInvokeRepeating(string methodName, float time, float repeatRate) 。含义：在 time 秒后调用 methodName 方法，然后每 repeatRate 秒调用一次。

// 方法一的实现
private void Update()
{
    SpawnBullet();
}

private void SpawnBullet()
{
    _waitingTime += Time.deltaTime;
    if (_waitingTime > cooldown)
    {
        Instantiate(bullet, shootPos);
        AudioMgr.Instance.PlayAudio(AudioMgr.Instance.clips[1]);
        _waitingTime = 0;
    }
}

// 方法二的实现
private void Start()
{
    InvokeRepeating("SpawnBullet", startingTime, cooldown);
}

private void SpawnBullet()
{
    Instantiate(bullet, shootPos);
    AudioMgr.Instance.PlayAudio(AudioMgr.Instance.clips[1]);
}

10. 敌人闪避的实现思路

敌人在生成一段时间（随机值）后进行闪避，如果敌人生成在屏幕的左半边则向右移动，如果在右半边则向左移动，一段时间（随机值）后停止左/右移动，继续向下移动，然后进入下一个闪避的循环，直到被自然销毁。

使用协程实现一段时间闪避然后继续保持竖直下行的行动
为了让敌人的闪避看起来平滑和自然，使用一个加速度通过APIMathf.Lerp(float a, float b, float t)来实现。a为起点值，b为终点值，t为两个浮点数之间的插值
敌人在移动过程中注意边界检查

教程中使用Mathf.MoveTowards(float current, float target, float maxDelta)实现，这个API本质上与Mathf.Lerp相同，将值current平滑地向target靠近。但是使用这个方法需要大幅提高加速度的值，否则敌人会不产生闪避的行为。原因在于这两者的本质差别：Lerp 用的是比例插值（t 是个 0~1 的比率），会按比例“拉”向目标，哪怕目标在另一侧也会生成小的反向速度；MoveTowards 用的是绝对步长（maxDelta），每帧只移动固定的量。如果用于 MoveTowards 的 maxDelta 太小（比如 acceleration 很小），每帧的速度变化被其他物理因素（摩擦、重置、阈值判断）淹没，看起来像“没有发生闪避”。

private void Start()
{
    StartCoroutine(Dodge());
}

private void FixedUpdate()
{
    // float xVel = Mathf.MoveTowards(_rb.velocity.x, _targetDodgeSpeed, Time.fixedDeltaTime * acceleration);  // 100
    float xVel = Mathf.Lerp(_rb.velocity.x, _targetDodgeSpeed, Time.fixedDeltaTime * acceleration); // 20
    _rb.velocity = new Vector3(xVel, _rb.velocity.y, _rb.velocity.z);
}

private IEnumerator Dodge()
{
    while (true)
    {
        yield return new WaitForSeconds(Random.Range(startingTimeMin, startingTimeMax));

        _targetDodgeSpeed = Random.Range(dodgeSpeedMin, dodgeSpeedMax);
        // 如果敌人出现在屏幕中线右侧向左闪避
        // 如果出现在左侧，那么自然速度是正，向左闪避，不用改
        if (_rb.position.x >= 0)   
        {
            _targetDodgeSpeed = -_targetDodgeSpeed;
        }

        float targetTime = Random.Range(movingTimeMin, movingTimeMax);

        yield return new WaitForSeconds(targetTime);
        _targetDodgeSpeed = 0;
    }
}

11. `OnTrigger`和`OnCollison`的使用时机

两者都可以用于碰撞检测。

OnCollision用于实际碰撞并产生物理反应的场景，所以开销较大，适用于物理交互时，如碰撞、反弹、受力等。

OnTrigger只检测重叠，不自动产生物理反应，因为通常不计算接触点/冲量，所以开销比OnCollision小些，适用于范围检测、触发器区域、捡取、伤害区域等。

12. 特效的销毁的方式方法（关注点分离原则）

特效的销毁放在一个单独的脚本中，不要和CollisionCheck 脚本放在一起。这样可以是关注点分离（CollisionCheck 只负责触发/判定），可复用性高，便于切换为对象池而不是每次销毁。

复盘

教程提供了一些很新颖的思路，在这个游戏中开始尝试自己写协程，并且尽量练习了上一个游戏中学到的单例模式。在一些我有疑问的时候或者觉得教程的处理超出我认知的时候问了AI，基本都得到满意的答复，感觉用这种项目驱动的学习方法真的很高效且因为有很多即时反馈，所以心理上也不太容易有疲惫感。

也有一些自己看了AI的回答和教程的讲解也不太明白的地方，比如“组件单一职责、用接口/事件解耦”等，留待在以后的游戏实战项目中慢慢实践体会。

还有很棒的一点是，学到了原来Unity开始界面的logo是可以替换的，马上做了一张小logo替换，效果真的不错！

代码复用

1. 滚动的无限背景

[SerializeField] private float _scrollSpeed;
private Vector3 _startPos;

private void Start()
{
	_startPos = transform.position;
}

private void Update()
{
	ScrollBG();
}

private void ScrollBG()
{
    float distance = Mathf.Repeat(_scrollSpeed * Time.time, 30);
    transform.position = _startPos + distance * Vector3.forward * (-1);
}

2. 旋转效果

// 球体的随机旋转
_rb.angularVelocity = Random.insideUnitSphere * rotationSpeed;

// 3D物体随某个轴的速度发生倾斜（此例中是随x轴上的速度）
 _rb.rotation = Quaternion.Euler(0, 0, _rb.velocity.x * (-1) * tilt);
float posX = Mathf.Clamp(_rb.position.x, border.minX, border.maxX);
_rb.position = new(posX, _rb.position.y, _rb.position.z);

3. `MoveController`

使用刚体，可以复用在所有在z轴方向运动的物体。

public class MoveController : MonoBehaviour
{
   [SerializeField] private float flySpeed;
   private Rigidbody _rb;
   private void Awake()
   {
      _rb = GetComponent<Rigidbody>();
   }

   private void FixedUpdate()
   {
      _rb.velocity = Vector3.forward * flySpeed;
   }
}

4. `DestroyByTime`

复用在特效的自动销毁上。

public class DestroyByTime : MonoBehaviour
{
    [SerializeField] private float delay;

    private void Start()
    {
        Destroy(gameObject, delay);
    }
}

5. `AudioManager`

复用在全部音效的管理和播放上。

public class AudioMgr : MonoBehaviour
{
    public static AudioMgr Instance;
    public AudioClip[] clips;
    private AudioSource _audioSource;

    private void Awake()
    {
        Instance = this;
        _audioSource = GetComponent<AudioSource>();
    }

    public void PlayAudio(AudioClip clip)
    {
        _audioSource.PlayOneShot(clip);
    }
}

飞翔的小鸟

教程参考及素材来源：油管-Zigurous

源码： on Gitee

游戏简介

《飞翔的小鸟》（Flappy Bird）是一款由越南开发者Dong Nguyen于2013年发行的简易2D手机游戏。游戏因其极低的画面复杂性、极高的难度和令人“上瘾”的挫败感而迅速走红，一度成为全球现象级游戏。

核心玩法：

类型：像素风格2D游戏，背景为卷轴式滚动，角色是一只简单的像素小鸟
目标：控制小鸟穿越由上下管道组成的障碍，飞得越远得分越高
操作方式：
- 点击屏幕（或按任意键），小鸟向上扇动翅膀，短暂上升
- 不操作时，小鸟受重力影响持续下落
障碍机制：
- 场景中随机出现高低不一的“绿色管道”，小鸟需从管道间隙穿过
- 触碰到管道、地面都会导致游戏立即结束
失败条件：小鸟碰到障碍物或地面则失败
计分系统：每成功穿过一对管道得1分，无最高分限制

游戏/功能拆解

内容

场景摆放（背景视差效果、无限滚动）、动画（小鸟飞翔）、UI（分数）、音效（得分、撞击）

逻辑

小鸟自动前进并随重力作用自然下落
玩家可以按下W键、上方向键或者点击鼠标左键让小鸟向上运动
如果小鸟在前进过程中碰到了管道或地面则游戏失败
显示当前的分数

开发步骤

小鸟部分
- 小鸟的移动
- 小鸟飞翔动画的实现
背景部分
- 背景的制作
- 背景视差的实现
管道部分
- 管道预制体的制作
- 管道的生成
- 管道的运动
得分
UI的设计/设置
菜单交互功能的实现
添加音效

遇到的问题及解决方法

1. 触屏模式的写法

// 以控制小鸟向上移动为例
// 触屏模式
if (Input.touchCount > 0)   // 只要手指接触到屏幕
{
    Touch touch = Input.GetTouch(0);    // 获取首次屏幕按触
    if (touch.phase == TouchPhase.Began)     // 只要刚开始按触屏幕
    {
        _dir = Vector3.up * strength;
    }
}

2. 用`InvokeRepeating` 实现简单的动画

需要注意的是，InvokeRepeating 是在 Unity 的主循环中按时间间隔调度调用指定方法，每次调用结束后会返回给引擎，等到下一个间隔再被调用。虽然它本质不是一个死循环，但是如果在被调的方法里写 while(true)（或其他不会退出的循环），该方法就不会返回，主线程会被阻塞，程序/编辑器会卡死。

另外，通常把 InvokeRepeating 放在 Start（或 Awake 后的一次性初始化处），只需要调用一次来安排重复调用，Unity 会按指定间隔循环调用该方法。如果把 InvokeRepeating 放在 Update 中，每帧都会再次注册一个重复调用，结果会累积大量并发的定时调用，导致方法被多次/更频繁执行、逻辑错误和性能问题。

用 InvokeRepeating实现小鸟飞翔的动画：

private void Start()
{
    InvokeRepeating(nameof(AnimateSprite), 0.15f, 0.15f);
}

private void AnimateSprite()
{
    _sr.sprite = sprites[_index];
    _index++;
    if (_index >= sprites.Length)
        _index = 0;
}

3. 视差+无尽背景的一种实现思路

教程中将背景全部按照3D的Quad制作，然后将2D的图片以shader：Unit/Texture的方式做成Material 。利用material中自带的Offset实现移动效果。这种方法非常简单，复用性强。

public class Parallax : MonoBehaviour
{
    [SerializeField] private float speed;
    private MeshRenderer _meshRenderer;

    private void Awake()
    {
        _meshRenderer = GetComponent<MeshRenderer>();
    }

    private void Update()
    {
        _meshRenderer.material.mainTextureOffset += new Vector2(speed * Time.deltaTime, 0);
    }
}

4. 管道销毁的另一种思路

按照通常的做法会在左侧屏幕边缘增加一个触发器，管道预制体碰到这个触发器后执行 Destroy。教程中使用了一个更简单的方法，根据像素位置来进行销毁：

private float _killEdge;

private void Start()
{
    _killEdge = Camera.main.ScreenToWorldPoint(Vector3.zero).x - 1;
}

private void Update()
{
    // Other codes

    if (transform.position.x < _killEdge)
    {
        Destroy(gameObject);
    }
}

5. Unity中的几个坐标系

World 坐标（World）

Unity 的世界坐标以世界原点 (0,0,0) 为参考，单位是 Unity unit（通常当作米）
轴方向：X 向右，Y 向上，Z 向前（正 Z 朝向 Scene 视图的前方）
GameObject 的 transform.position 是世界坐标；transform.localPosition 是相对于父对象的局部坐标

屏幕坐标（Screen）

以像素为单位，原点在屏幕左下角 (0,0)，右上角是 (Screen.width, Screen.height)
旧的 IMGUI（OnGUI）以左上角为原点；UI 的坐标行为还会受 Canvas Render Mode（Screen Space / World Space）影响

视口坐标（Viewport）

归一化坐标，范围在 [0,1]，左下为 (0,0)，右上为 (1,1)
可用 Camera.ViewportToWorldPoint / WorldToViewportPoint 转换

在上述管道销毁的例子中，使用 Camera.ScreenToWorldPoint(Vector3 screenPoint) 对左下角屏幕坐标原点，（0, 0 ,0）即坐标原点Vector3.zero 进行了转换，这样才能和Update中的transform.position.x处于同一坐标系下，才有比较的可能。

6. 游戏的重启和暂停

最简单的方法就是使用 Time.timeScale。

复盘

因为是2D游戏，所以可以直接使用诸如Vector3.up、Vector3.left这样的代码来表示方向，大大简化了代码。教程中的一些设计思路非常简便好用，比如把背景做成3D quad，运用API _meshRenderer.material.mainTextureOffset 来实现无尽背景和视差效果；还有通过将某一个点的坐标从屏幕坐标转换为世界坐标，物体通过这个点后销毁，而不是依靠传统的碰撞检测，可以节省性能；还有关于简单的动画，不用Unity自带的动画系统，转而使用 InvokeRepeating 配合遍历图片的方式，简单高效地解决了问题。

在我自己的实践方面，练习了 GameManager 和 AudioManager 的单例模式，并重温了音效的播放和UI的交互设计。这个游戏虽然是个入门级的小游戏，但是我还是学到了很多。

代码复用

Spawner的一种写法

使用 InvokeRepeating 达到间隔时间生成游戏物体的效果。

private void OnEnable()
{
    InvokeRepeating(nameof(Spawn), startSpawn, spawnRate);
}

private void OnDisable()
{
    CancelInvoke();
}

private void Spawn()
{
    GameObject pipe = Instantiate(prefab, transform.position, Quaternion.identity);
    pipe.transform.position += Vector3.up * Random.Range(minHeight, maxHeight);
}

其他一些可复用的代码在上面的“问题与解决方法”部分都有提及，此处不再赘述。

乒乓球

教程参考及素材来源：油管-Zigurous

完整源码： on Gitee

游戏简介

《乒乓球》（Pong）是电子游戏史上最早、最具影响力的街机游戏之一，由 Atari 公司于 1972 年发布。它模拟了现实中的乒乓球（Table Tennis）运动，被认为是第一个取得商业成功的电子游戏。

核心玩法：

游戏画面为一个二维平面，左右两侧各有一个垂直的“球拍”（paddle），中间是一个移动的小球
玩家控制一侧的球拍上下移动（通常通过摇杆或按键），目标是将球反弹回对方场地
如果一方未能接到球，对方得一分
小球碰到上下边界会反弹，碰到左右边界则判定为得分
随着游戏进行，球速可能逐渐加快，增加难度

游戏/功能拆解

内容

场景摆放、玩家球拍、球、电脑球拍、UI（分数）

逻辑

玩家通过 W键/上箭头键 和 S键/下箭头键 移动球拍击打乒乓球
乒乓球碰到上下边界回弹
乒乓球如果落入自己边界，对方得一分，反之亦然
显示当前的分数

开发步骤

场景摆放
玩家球拍的移动
球移动的实现
电脑球拍AI的实现
球逐渐回弹增速
显示UI分数

遇到的问题及解决方法

1. `Angular Drag` 和 `Linear Drag`

在 Rigidbody 中的 Angular Drag 代表角阻力系数，如果不想要旋转的效果，要把它手动设置为0（默认为0.05），同时在 Constraints 中禁止 z轴 的旋转。在类似这个游戏的2D游戏中一般需要这样的操作。

Linear Drag 则适用于位置移动，较高的阻力值会让对象受碰撞或力影响后的旋转更快停止。

2. `FixedUpdate`的使用说明

不要在 FixedUpdate 直接读取输入。原因是FixedUpdate 按物理步长调用，可能丢失输入事件或导致输入响应不稳定。

正确做法是在 Update() 读取输入并把结果存到字段，随后在 FixedUpdate() 根据该字段施加力。

private void Update()
{
    if (Input.GetKey(KeyCode.W) || Input.GetKey(KeyCode.UpArrow))
    {
        _dir = Vector2.up;
    }
    else if (Input.GetKey(KeyCode.S) || Input.GetKey(KeyCode.DownArrow))
    {
        _dir = Vector2.down;
    }
    else
    {
        _dir = Vector2.zero;
    }
}

private void FixedUpdate()
{
    if (_dir.sqrMagnitude != 0)
    {
        Rb.AddForce(_dir * strength);
    }
}

FixedUpdate 主要用于与物理系统同步的更新。

适合放在 FixedUpdate 里的任务：

应用力/扭矩（Rb.AddForce / AddRelativeForce）或直接设置 Rigidbody.velocity
使用 Rigidbody.MovePosition / MoveRotation（针对 Kinematic Rigidbody）
与物理步长一致的计时器、物理约束与求解逻辑（确定性模拟、网络服务器物理步）
基于物理状态的查询（在物理步长内做的碰撞检测/Overlap/射线检测）
物理预测/插值/外推逻辑（以固定步长进行同步）

不适合放在 FixedUpdate 里的任务：(需要以帧为单位或更低延迟处理)

输入读取
渲染/摄像机跟随
UI 更新
动画（通常在 Update 或 LateUpdate）

3. 小球接触回弹效果的实现

使用这样的代码无法达到效果，原因可能是方向计算错误，使用 -rb.velocity 并不等同于基于碰撞法线的反射，小球可能沿着错误的方向被推动。

private void OnCollisionEnter2D(Collision2D other)
{
    if (other.transform.CompareTag("Ball"))
    {
        Rigidbody2D rb = other.gameObject.GetComponent<Rigidbody2D>();
        _dir = rb.velocity.normalized;

        rb.AddForce(-_dir * strength);
    }
}

这里应该使用碰撞接触点的法线解决：

private void OnCollisionEnter2D(Collision2D other)
{
    if (other.transform.CompareTag("Ball"))
    {
        Rigidbody2D rb = other.gameObject.GetComponent<Rigidbody2D>();
        _dir = other.GetContact(0).normal;  // 碰撞点的法线

        rb.AddForce(-_dir * strength);
    }
}

4. 使用 `EventSystem` 实现玩家和电脑的得分

感觉实现的方式和按钮很像。

代码解释：

TriggerEvent 本质上是 UnityEvent<BaseEventData> 的一个别名/子类，可以在 Inspector 或代码里注册接收 BaseEventData 的回调

构造一个 BaseEventData ，并把当前 EventSystem 作为来源，callback 可以读取这个 eventData 来获取上下文
通过 scoreTrigger.Invoke 触发已注册的所有回调，传入 eventData

public class ScoringArea : MonoBehaviour
{
    [SerializeField] private EventTrigger.TriggerEvent scoreTrigger;
    private void OnCollisionEnter2D(Collision2D other)
    {
        if (other.gameObject.CompareTag("Ball"))
        {
            BaseEventData eventData = new BaseEventData(EventSystem.current);
            scoreTrigger.Invoke(eventData); // 调用已注册的eventData
        }
    }
}

复盘

教程中使用了父类 Paddle 和两个子类PlayerPaddle和ComputerPaddle的方法，一些公共的代码，如获取组件等放在父类中，在两个子类中分别写自己的逻辑。在C++的项目里经常会用到继承的方法，但是在做Unity项目的时候我经常会忘记使用，在以后的实践中要提醒自己在合适的时机多多使用。

代码复用

本游戏中可复用的代码已在“问题和解决方法”部分提及：

小球回弹的实现
使用 EventSystem 灵活实现多个函数的回调

小行星

教程参考及素材来源：油管-Zigurous

源码： on Gitee

游戏简介

《小行星》（Asteroids）是由 Atari 公司于 1979 年推出的一款经典街机射击游戏，以其简洁的矢量图形和紧张刺激的玩法成为电子游戏史上的里程碑之作。

核心玩法：

玩家控制一艘小型飞船，在无重力的太空中自由移动（可推进、旋转、射击）
- 按下 W键/ 上箭头 或者 S键/下箭头 可以旋转
- 按下 A键/ 左键头、D键/右箭头可以左/右推进
- 按下 空格 或者点击 鼠标左键 可以发射子弹
屏幕中不断出现大小不一的“小行星”，它们会从边缘进入并随机漂移
目标：用激光炮击碎所有小行星
- 大/中行星被击中后会分裂成更小的碎片（例如：大 → 中 → 小 → 消失）
失败：
- 飞船碰到小行星会立即毁灭（通常有有限生命次数）
其他特点：
- 飞船有动量，即使停止推进也会继续滑行，需反向推进减速

游戏/功能拆解

内容

场景摆放、玩家、行星、爆炸特效

逻辑

玩家移动和射击
小行星随机生成和移动
小行星被玩家击中后分裂，直至消失
玩家碰到小行星后，这一局失败
显示当前的分数
全部局数用尽，游戏结束

开发步骤

场景设置
玩家部分
- 移动
- 射击
小行星部分
- 行星预制体（不同的形状、大小、质量、初始角度）
- 生成行星
- 实现分裂/销毁逻辑
一局的结束
- 玩家死亡与复活
- 玩家的爆炸特效
显示UI分数和玩家剩余的生命数
全部局数用尽，游戏结束

遇到的问题及解决方法

1. 物体间物理碰撞层的设置

通过 Project Setting 中的 Physics 2D 来忽略玩家和子弹、子弹与子弹之间的碰撞检测。

2. 小行星初始状态的设置

因为此项目中的小行星有不同的变体，包括大小、图片、出现时的初始角度等多个参数都不同，所以采取的策略时在小行星的预制体中就将其全部设置好。这样做的好处是在小行星的 Spawner.cs 脚本里，预制体可以直接生成，做到了脚本的各司其职。Asteroid.cs 负责小行星本身的属性，Spawner.cs 脚本负责小行星的生成。

public class Asteroid : MonoBehaviour
{
    [SerializeField] private Sprite[] sprites;
    [SerializeField] private float size = 1f;
    [SerializeField] private float speed = 1f;
    public float minSize = 0.5f;
    public float maxSize = 1.5f;
    private SpriteRenderer _sr;
    private Rigidbody2D _rb;

    private void Awake()
    {
        _sr = GetComponent<SpriteRenderer>();
        _rb = GetComponent<Rigidbody2D>();
    }

    private void Start()
    {
        _sr.sprite = sprites[Random.Range(0, sprites.Length)];
        transform.eulerAngles = new Vector3(0, 0, Random.value * 360);

        //size = Random.Range(minSize, maxSize);

        transform.localScale = Vector3.one * size;
        _rb.mass = size; // mass随着size变化

    }

    public void SetTrajectory(Vector2 dir)
    {
        _rb.AddForce(dir * speed);
    }

小行星初始的旋转角度：

使用 Random.value，这个值在0~1之间，小行星在 z轴 旋转，所以可以简单处理为 transform.eulerAngles = new Vector3(0, 0, Random.value * 360);

小行星的size部分处理：

不能放在 Asteroid.cs 里，因为这个脚本后面会进行小行星分裂的逻辑，如果在 Start() 里对 size 取随机值，会导致分裂的逻辑错误。随机size的逻辑放在 Spawner.cs 里处理。这是我在这个项目遇到的一个大坑。

3. 小行星生成和移动的实现思路

小行星生成在以屏幕为圆心，一定半径的圆内。它们向着圆心运动。为了增加随机性，增加了朝向圆心的偏移角度。因为是沿着 z轴进行偏移的，所以可以用 Quaternion.AngleAxis(float angle, Vector3.forward) 实现。

在小行星的移动上，本身方法由 Asteroid.cs 负责，Spawner.cs 通过获得一个Asteroid 的实例化对象调用。

 private void Start()
 {
     InvokeRepeating(nameof(Spawn), spawnInterval, spawnInterval);
 }

// 行星生成在离spawner为圆心的一定半径的位置
private void Spawn()
{
    Vector2 spawnOffset = Random.insideUnitCircle * spawnRadius;
    Vector2 spawnPos = (Vector2)transform.position + spawnOffset;   // 以Spawner为圆心、一定半径内的某个随机位置
    Vector2 dir = ((Vector2)transform.position - spawnPos).normalized;

    // 在方向上加上一个角度的偏移量
    float variance = Random.Range(-trajectoryAngle, trajectoryAngle);
    Quaternion rotation = Quaternion.AngleAxis(variance, Vector3.forward);

    GameObject obj = Instantiate(asteroidPrefab, spawnPos, Quaternion.identity);
    Asteroid asteroid = obj.GetComponent<Asteroid>();
    asteroid.size = Random.Range(asteroid.minSize, asteroid.maxSize);	// 在此处处理生成小行星的随机尺寸问题
    asteroid.SetTrajectory(rotation * dir);
}

需要注意的是，最终小行星的轨道方向是 rotaton * dir，rotation本身是一个四元数，这里将旋转作用于向量，即 旋转后的向量 = Quaternion * 原始向量

Quaternion 必须在乘号左边！

其中的原理在数学的相关学习中再做详尽探讨，此处不再赘述。

关于 Quaternion的补充

应该避免直接修改 Quaternion 的x, y, z, w 分量，因为它们不是角度而是复杂的复数数学，直接修改会导致异常。

始终使用Unity提供的API！

常用的API：

场景	方法
旋转一个向量	`rotatedVector = quaternion * vector;`
让物体看向某个方向	`Quaternion.LookRotation(vector);`
把(0,90,0)转为四元数	`Quaternion.Euler(0, 90, 0);`
获取四元数的度数	`quaternion.eulerAngles;`

4. 玩家无敌时间的设计思路

通过更改玩家物理碰撞层的方法 LayerMask.NameToLayer(layerName);实现，非常简单明了，再使用 Invoke 来设定需要等待的时间即可。

5. 粒子系统的设置

因为我在UI的逻辑中使用了 Time.scaleTime 来控制游戏的结束和开始，为了避免粒子系统拖到下一轮开始游戏的那一瞬间播放，需要在面板里将粒子系统的 Delta Time 设置为 Unscaled 。

复盘

这个项目中需要大量使用关于旋转的方法，常用的API要熟练使用。另外相关的数学知识也需要补充一下。

这个项目还有两个方法值得注意，可以经常尝试使用：

通过传参获得另一个脚本中的对象：

//======= GameManager.cs =======
// 函数的定义放在这里，因为里面很多用到的参数由GameManager统一管理
public void AsteroidDestroyed(Asteroid asteroid)
{
    if (asteroid.size <= 0.75f)
    {
        score += 5;
    }
    else if (asteroid.size <= 1.3f)
    {
        score += 2;
    }
    else
    {
        score += 1;
    }

    Vector2 pos = asteroid.transform.position;
    explosion.transform.position = pos;
    explosion.Play();
}

//========== Asteroid.cs =========
// 方法的调用由Asteroid类本身管理，在小行星碰撞后调用
private void OnCollisionEnter2D(Collision2D other)
{
    if (other.gameObject.CompareTag("Bullet"))
    {
        if (size * 0.5f >= minSize)
        {
            CreateHalf();
            CreateHalf();
        }

        Destroy(other.gameObject);
        Destroy(gameObject);

        GameManager.Instance.AsteroidDestroyed(this);
    }
}

在一个脚本中调用另一个脚本中的函数：

可以通过GameObject或者直接通过另一个类的游戏物体来获得：

//=========== Spawner.cs ============
// 通过实例化Asteroid对象来调用它的SetTrejactory方法
private void Spawn()
{
	// Other codes

    GameObject obj = Instantiate(asteroidPrefab, spawnPos, Quaternion.identity);
    Asteroid asteroid = obj.GetComponent<Asteroid>();
    asteroid.size = Random.Range(asteroid.minSize, asteroid.maxSize);   // 在此处处理生成小行星的随机尺寸问题
    asteroid.SetTrajectory(rotation * dir);
}

代码复用

1. 玩家无敌时间的设计

通过更改物理碰撞层，配合Invoke的使用：

private void OnCollisionEnter2D(Collision2D other)
{
    if (other.gameObject.CompareTag("Asteroid"))
    {
        GameManager.Instance.lives--;
        gameObject.SetActive(false);

        Invoke(nameof(Respawn), respawnTime);
    }
}

private void Respawn()
{
    gameObject.SetActive(true);
    gameObject.transform.position = Vector3.zero;
    gameObject.layer = LayerMask.NameToLayer("No Collision");

    Invoke(nameof(ResetLayer), invulnerableTime);
}

private void ResetLayer()
{
    gameObject.layer = LayerMask.NameToLayer("Player");
}

2. 清除场景中所有物体

在《飞翔的小鸟》和《小行星》的游戏重置中，都用到了同样的方法，使用 FindObjectsOfType 通过数组遍历场景中所有需要查找的物体进行销毁即可。

Asteroid[] asteroids = FindObjectsOfType<Asteroid>();
for (int i = 0; i < asteroids.Length; i++)
{
    Destroy(asteroids[i].gameObject);
}

Unity on Nullshow的技术博客

【Unity】从一个中型游戏学习商业化代码的写法（上）

项目简介

学习目标

核心玩法结构

开发步骤

思路及关键步骤

输入和逻辑分离

使用 Slerp 处理角色的转向

角色的动画

处理动画的注意点

动画中的 visual 与 logic 分离原则

拓展：CInemachine工作原理

输入部分的重构

WASD

生成C# class

重构后的输入代码

3D的碰撞检测

Raycast（射线检测）

Cast（投射 / 形状检测）

关于碰撞时如果同时按下两个键，玩家移动的处理

与柜台的交互

柜台选中时的视觉效果

踩的坑

使用Scriptable Object来管理厨房物品

ScriptableObject

好处

典型使用场景

注意事项

创建 KitchenObjectSO 脚本

创建 KitchenObject 脚本

厨房物体的父对象

玩家与厨房物品的交互

不同类型的柜台

使用 Prefab Variant 实现高效复用与差异化管理

好处

适用场景

注意事项

不同类型柜台的关系设计

拓展

virtual 和 abstract

重构

切菜柜台的实现

Cutting Recipe

对于可以被切的菜的限定

切菜的进度

切菜进度条正对摄像机显示

【Unity】从一个入门级小游戏学习商业化代码的写法

项目简介

学习目标

开发步骤

思路及关键步骤

PostProcessing

visual 与 logic 分离

代码要尽可能地清晰

Input的方法

Input放的位置

坐标系的设定

Landing 的实现思路

不要使用字符串来识别游戏物体

推力特效的实现

Time.deltaTime 和 Time.fixedDeltaTime

deltaTime 在 Update() 中的使用

Time.fixedDeltaTime 在 FixedUpdate() 中的使用

两者的关键区别

EventHandler

临时给字体添加颜色的方法

使用状态机来设置游戏的状态

点击按钮的操作

Level number 不变化的处理

在关卡开始时展示全景地图

新建一个空游戏物体 CinemachineCamera2D 挂载脚本

在 GameLevel 里设置放大的值，使得每一关的设置都很灵活

在 GameManger 中具体设置

在镜头切换时实现平滑效果

Input 的改进（支持多个输入系统）

扩展

旧输入系统的缺点

新 Input System的优势

良好实践

使用 `Slerp` 处理角色的转向

`virtual` 和 `abstract`

`Time.deltaTime` 和 `Time.fixedDeltaTime`

`deltaTime` 在 `Update()` 中的使用

`Time.fixedDeltaTime` 在 `FixedUpdate()` 中的使用

`EventHandler`

事件总线系统 — `GameEvents`

接口驱动的伤害系统— `IDamageable`