Unity双人联机冰球游戏实战：从网络同步到物理交互的完整实现

1. 项目概述与核心价值

最近在整理过去的项目资料，翻到了一个几年前做的Unity双人联机冰球游戏。这个项目虽然体量不大，但麻雀虽小五脏俱全，它完整地串联起了Unity网络编程、物理交互、UI同步和状态管理这几个游戏开发中的硬骨头。当时做这个项目的初衷，就是想找一个能快速验证联机对战玩法、且物理反馈直观有趣的原型，冰球这个题材再合适不过了——规则简单，但碰撞、加速、进球判定这些细节，每一个都够琢磨一阵子。

这个实战项目能帮你解决什么问题呢？如果你是一个刚学完Unity基础，想挑战一下网络联机功能的开发者，或者你是一个独立游戏开发者，想为自己的游戏加入一个快速匹配的PvP小游戏模式，那么这个项目就是一个绝佳的练手模板。它不涉及复杂的商业级网络架构，而是聚焦于使用Unity自带的Netcode for GameObjects（以前常叫UNET的高层API，现在官方主推这套）来实现一个稳定、可玩的双人对战核心。通过这个项目，你能清晰地掌握如何在两个客户端之间同步一个具有复杂物理行为的物体（冰球），如何处理玩家输入延迟带来的手感差异，以及如何权威地在服务器端进行关键的游戏逻辑判定，比如进球得分。

整个项目的核心关键词就是Unity、双人联机、冰球游戏和实战。它不停留在理论，而是会带着你从零开始，一步步搭建场景、编写代码、调试同步，直到你能和你的朋友通过网络真正地打上一局。下面，我就把这个项目的完整设计思路、实现细节，以及我踩过的那些“坑”和总结的经验，毫无保留地分享出来。

2. 整体架构设计与技术选型

在动手写第一行代码之前，花点时间想清楚架构是至关重要的。一个混乱的网络游戏项目后期调试起来会是噩梦。对于这个双人冰球游戏，我们的核心目标是：两个玩家通过互联网或局域网连接，分别控制一个球杆，击打同一个冰球，争夺将球打入对方球门。

2.1 网络模型选择：权威服务器与客户端预测

首先面临的是网络模型的选择。常见的有纯P2P（对等网络）和客户端-服务器（C/S）模型。对于这种强对抗、需要防止作弊的竞技游戏，基于权威服务器的C/S模型是唯一可靠的选择。在这个模型下，其中一台机器（可以是其中一个玩家的主机，也可以是独立的服务器）作为“主机”（Host），它拥有游戏状态的最终决定权。所有客户端的操作都需要发送到主机进行验证和计算，然后主机将结果广播给所有客户端。

但是，纯权威服务器会带来严重的操作延迟感。玩家按下按键，指令传到服务器，服务器计算后再同步回来，球杆才会动，这中间上百毫秒的延迟会让游戏感觉非常“粘滞”。为了解决这个问题，我们必须引入客户端预测。简单说，就是客户端在发送操作指令给服务器的同时，本地立刻根据这个指令模拟一次动作（比如移动球杆）。这样玩家会感到即时响应。之后，当服务器权威的状态同步回来时，如果客户端的预测和服务器结果有偏差（比如因为网络波动或与其他玩家操作冲突），客户端需要进行调和，通常是平滑地修正自己的位置到服务器发来的权威位置。这个“预测-调和”的循环，是保证联机游戏手感流畅的核心。

对于Unity，我们选择使用Unity Netcode for GameObjects (NGO)。它是Unity官方维护的高层网络解决方案，封装了底层的传输协议（默认使用UNET Transport，也支持自定义如Unity Transport），提供了NetworkManager、NetworkObject、NetworkVariable等开箱即用的组件。相比于直接使用底层Socket或第三方库，NGO能让我们更专注于游戏逻辑而不是网络通信细节，特别适合原型开发和中小型项目。

2.2 游戏对象网络身份规划

我们需要明确哪些对象需要在网络上同步。用NGO的术语来说，就是哪些是NetworkObject。

1. 玩家球杆 (Player Paddle)：每个玩家控制一个。它必须是NetworkObject，因为它的位置、旋转需要同步给对手。同时，它需要处理本地输入预测和服务器权威同步。
2. 冰球 (Puck)：游戏的核心交互物体。它必须是NetworkObject，并且其位置、速度（刚体的velocity）的同步至关重要。为了流畅性，我们通常会采用状态同步（服务器定期广播冰球的状态），并结合插值在客户端进行平滑渲染。
3. 游戏状态管理器 (GameStateManager)：一个单例或静态管理器，但不是NetworkObject。它应该存在于主机上，负责管理比赛状态（如比分、剩余时间、比赛是否开始/结束）。比分等信息可以通过NGO的NetworkVariable来同步给所有客户端。
4. 球门 (Goal)：静态碰撞体，不需要作为完整的NetworkObject同步其变换信息。但进球检测这个逻辑必须放在主机端执行。我们可以通过在球门物体上挂载一个脚本，并在主机端检测碰撞来实现。
5. UI元素 (如比分牌)：UI本身不需要网络同步，但显示的数据（比分、时间）来源于需要同步的NetworkVariable。UI脚本监听这些变量的变化并更新显示即可。

2.3 物理同步的挑战与方案

冰球游戏的核心乐趣来源于真实的物理碰撞。然而，物理引擎（如Unity的PhysX）在每台机器上独立运行，微小的浮点数误差或帧率差异都可能随着时间累积，导致两台机器上的冰球运动轨迹完全不同，这就是“蝴蝶效应”，是联机物理游戏最大的敌人。

我们的解决方案是：主机权威物理。

• 主机：运行完整的、权威的物理模拟。冰球的Rigidbody只在主机上受物理引擎驱动。
• 客户端：不启用冰球Rigidbody的物理模拟（即isKinematic设为true，或者直接禁用Rigidbody组件）。客户端只负责接收主机同步过来的冰球位置和速度，然后使用插值（Interpolation）或外推（Extrapolation）在本地进行平滑的视觉呈现。

这样，所有物理计算的结果都来源于主机，确保了所有客户端看到的现象是一致的。客户端只扮演一个“渲染终端”的角色。对于玩家球杆，由于其运动直接由输入驱动，我们采用之前提到的“客户端预测+服务器调和”方案，但球杆与冰球的碰撞检测结果，也必须以主机计算的为准。

3. 核心模块实现与细节拆解

有了顶层设计，我们开始进入具体的实现环节。我会按照创建项目的自然顺序，逐一拆解每个核心模块。

3.1 项目初始化与网络设置

首先，创建一个新的Unity项目（建议使用较新的LTS版本，如2022.3）。通过Package Manager安装Netcode for GameObjects包。

1. 创建网络管理器：在场景中创建一个空物体，命名为“NetworkManager”，为其添加NetworkManager组件。这将是整个网络系统的控制中心。再添加一个UnityTransport组件（如果自动添加了）作为传输层。
2. 设置玩家预制体：
   • 创建一个代表球杆的3D物体（比如一个胶囊体或扁平的圆柱体），命名为“PlayerPaddle”。
   • 为其添加NetworkObject组件。这是它在网络世界中身份的标识。
   • 添加Rigidbody组件，并冻结不需要的旋转轴（例如，冰球在桌面上，通常冻结Y轴位置和X、Z轴旋转），设置合适的质量和阻力。
   • 添加一个碰撞体（如BoxCollider）。
   • 将这个物体拖入项目资源文件夹，做成预制体（Prefab）。
   • 回到NetworkManager组件，在Player Prefab字段中，将这个“PlayerPaddle”预制体拖进去。这样，当玩家加入游戏时，NGO会自动为他们在所有客户端生成这个预制体。

3.2 玩家球杆的移动与输入同步

这是实现手感的关键。我们需要编写一个脚本来处理本地输入、预测和网络同步。

创建一个名为PlayerPaddleController的C#脚本，挂载到玩家球杆预制体上。

using Unity.Netcode; using UnityEngine; public class PlayerPaddleController : NetworkBehaviour { [SerializeField] private float moveSpeed = 10f; private Rigidbody rb; private Vector3 moveInput; // 用于存储服务器权威位置，以便调和 private NetworkVariable<Vector3> networkPosition = new NetworkVariable<Vector3>(writePerm: NetworkVariableWritePermission.Server); // 用于存储服务器权威速度，同步给其他客户端看 private NetworkVariable<Vector3> networkVelocity = new NetworkVariable<Vector3>(writePerm: NetworkVariableWritePermission.Server); private void Awake() { rb = GetComponent<Rigidbody>(); } private void Update() { // 只有本地玩家控制的物体，才处理输入 if (!IsOwner) return; float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); moveInput = new Vector3(horizontal, 0, vertical).normalized; } private void FixedUpdate() { if (IsOwner) { // 客户端预测：立即应用移动 Vector3 moveForce = moveInput * moveSpeed * Time.fixedDeltaTime; rb.MovePosition(rb.position + moveForce); // 将输入发送到服务器进行权威移动 MoveServerRpc(moveInput); } else { // 非本地玩家：根据服务器同步的networkVelocity进行平滑移动（或直接应用networkPosition） // 这里为了简单，我们直接插值到networkPosition。更优方案是使用networkVelocity进行模拟。 rb.MovePosition(Vector3.Lerp(rb.position, networkPosition.Value, Time.fixedDeltaTime * 10f)); } // 如果是服务器，始终更新NetworkVariable if (IsServer) { networkPosition.Value = rb.position; networkVelocity.Value = rb.velocity; } } [ServerRpc] private void MoveServerRpc(Vector3 direction) { // 服务器收到RPC后，进行权威移动计算 // 这里可以进行作弊检测（如速度上限、瞬移检测等） Vector3 moveForce = direction * moveSpeed * Time.fixedDeltaTime; rb.MovePosition(rb.position + moveForce); // 移动后，networkPosition和networkVelocity会在FixedUpdate中被更新，并自动同步 } }

代码解析与注意事项：

• NetworkBehaviour：所有需要网络功能的脚本都必须继承自此类。
• IsOwner：判断当前客户端是否是此网络物体的所有者（控制者）。
• IsServer：判断当前实例是否运行在主机/服务器端。
• ServerRpc：标记一个方法，客户端可以调用它，但只在服务器上执行。这是客户端向服务器发送指令的标准方式。
• NetworkVariable：一种自动同步的变量。当服务器修改它的值，所有客户端都会自动收到更新。writePerm: NetworkVariableWritePermission.Server确保了只有服务器能修改它，防止客户端作弊。
• 调和策略：上述代码中，非所有者客户端简单地使用Lerp插值到networkPosition。这是一个基础的调和。更复杂的方案需要缓存历史状态，在收到服务器更新时进行回溯和重新模拟，这对于高速运动的物体（如冰球）更为必要。对于球杆，由于是直接输入控制，简单的插值在延迟不高时通常可以接受。

注意：在FixedUpdate中同时处理预测移动和发送RPC，可能会因为网络帧率（tick rate）和物理帧率不同步导致问题。一个更健壮的做法是在Update中收集输入，在FixedUpdate中执行物理移动和发送包含输入序列号的RPC，服务器按序处理。这里为了示例清晰做了简化。

3.3 冰球的网络同步与主机权威物理

冰球是游戏的核心，它的同步必须保证流畅和一致。我们创建一个NetworkPuck脚本。

using Unity.Netcode; using UnityEngine; public class NetworkPuck : NetworkBehaviour { private Rigidbody rb; // 同步位置和速度 private NetworkVariable<Vector3> netPosition = new NetworkVariable<Vector3>(); private NetworkVariable<Vector3> netVelocity = new NetworkVariable<Vector3>(); // 插值用的目标位置和速度 private Vector3 targetPosition; private Vector3 targetVelocity; private void Awake() { rb = GetComponent<Rigidbody>(); } public override void OnNetworkSpawn() { base.OnNetworkSpawn(); if (!IsServer) { // 客户端：禁用物理模拟，由网络数据驱动 rb.isKinematic = true; // 初始化目标值 targetPosition = netPosition.Value; targetVelocity = netVelocity.Value; } } private void FixedUpdate() { if (IsServer) { // 服务器：正常进行物理模拟，并更新NetworkVariable netPosition.Value = rb.position; netVelocity.Value = rb.velocity; } else { // 客户端：根据同步的数据进行插值渲染 // 更新目标值（NetworkVariable变化时会自动触发OnValueChanged，这里为简化在Update中读取） targetPosition = netPosition.Value; targetVelocity = netVelocity.Value; // 使用插值平滑移动，而不是直接赋值 // 直接赋值：transform.position = targetPosition; // 会抖动 // 插值： rb.MovePosition(Vector3.Lerp(rb.position, targetPosition, Time.fixedDeltaTime * 15f)); // 对于视觉旋转，也可以根据速度进行插值 } } // 可选：监听NetworkVariable变化，进行更精细的插值管理 private void OnNetPositionChanged(Vector3 oldValue, Vector3 newValue) { // 可以在这里计算位置差，决定是直接跳转还是插值 // 如果位置差过大，可能是发生了瞬移（如重置位置），直接跳转 if (Vector3.Distance(rb.position, newValue) > 5f) { rb.MovePosition(newValue); } else { targetPosition = newValue; } } }

关键点解析：

• OnNetworkSpawn：当网络物体在所有客户端生成时调用。在这里，我们让客户端将冰球的Rigidbody设为isKinematic = true，这意味着物理引擎不会驱动它，我们可以完全通过脚本控制其变换。
• 服务器权威：只有服务器（IsServer）的冰球在进行真实的物理计算。客户端的冰球只是一个“视觉幽灵”。
• 插值（Interpolation）：我们使用Vector3.Lerp在当前位置和目标位置（从服务器同步来的位置）之间进行平滑过渡。15f是插值系数，值越大，跟随越快，但可能不平滑；值越小，延迟感越强，但更平滑。这个系数需要根据游戏的网络Tick Rate和物理表现进行微调。
• 外推（Extrapolation）：更高级的同步策略。客户端不仅插值，还会根据最后收到的速度和位置，预测下一帧的位置。这对于高速物体可以减少延迟感，但预测错误时会产生“回溯”现象。冰球游戏对一致性要求极高，建议初期以插值为主，确保稳定。

3.4 进球检测与游戏状态管理

进球逻辑必须是服务器权威的，否则会出现“我明明没进，他却得分了”的争议。我们在两个球门物体上添加碰撞检测。

创建一个GoalTrigger脚本：

using Unity.Netcode; using UnityEngine; public class GoalTrigger : NetworkBehaviour { [SerializeField] private bool isPlayerAGoal; // 在Inspector中设置，标记是哪个玩家的球门 private GameStateManager gameStateManager; private void Start() { gameStateManager = FindObjectOfType<GameStateManager>(); // 简单查找，更好的做法是依赖注入 } private void OnTriggerEnter(Collider other) { if (!IsServer) return; // 只在服务器端检测 NetworkPuck puck = other.GetComponent<NetworkPuck>(); if (puck != null) { // 冰球进入球门 Debug.Log($"Goal scored in {(isPlayerAGoal ? "Player A" : "Player B")}'s goal!"); // 通知游戏状态管理器得分 if (gameStateManager != null) { gameStateManager.OnGoalScoredClientRpc(isPlayerAGoal); } // 服务器重置冰球位置和速度 ResetPuckServerRpc(); } } [ServerRpc(RequireOwnership = false)] private void ResetPuckServerRpc() { // 将冰球重置到场地中央 NetworkObject puckObject = FindObjectOfType<NetworkPuck>()?.GetComponent<NetworkObject>(); if (puckObject != null) { puckObject.transform.position = Vector3.zero; Rigidbody puckRb = puckObject.GetComponent<Rigidbody>(); if (puckRb != null) { puckRb.velocity = Vector3.zero; puckRb.angularVelocity = Vector3.zero; } } } }

接下来，创建一个GameStateManager脚本，管理比分和游戏流程。它应该是一个NetworkBehaviour并存在于场景中一个永久的网络物体上（比如一个空的GameManager物体）。

using Unity.Netcode; using UnityEngine; using UnityEngine.UI; public class GameStateManager : NetworkBehaviour { // 使用NetworkVariable同步比分 public NetworkVariable<int> scorePlayerA = new NetworkVariable<int>(0, NetworkVariableReadPermission.Everyone, NetworkVariableWritePermission.Server); public NetworkVariable<int> scorePlayerB = new NetworkVariable<int>(0, NetworkVariableReadPermission.Everyone, NetworkVariableWritePermission.Server); public Text scoreTextA; // UI Text组件 public Text scoreTextB; public override void OnNetworkSpawn() { base.OnNetworkSpawn(); // 监听分数变化，更新UI scorePlayerA.OnValueChanged += OnScoreAChanged; scorePlayerB.OnValueChanged += OnScoreBChanged; UpdateScoreUI(); } private void OnScoreAChanged(int oldValue, int newValue) { UpdateScoreUI(); } private void OnScoreBChanged(int oldValue, int newValue) { UpdateScoreUI(); } private void UpdateScoreUI() { if (scoreTextA != null) scoreTextA.text = $"Player A: {scorePlayerA.Value}"; if (scoreTextB != null) scoreTextB.text = $"Player B: {scorePlayerB.Value}"; } [ClientRpc] public void OnGoalScoredClientRpc(bool isPlayerAGoal) { // 这个RPC由GoalTrigger在服务器端调用，通知所有客户端 if (IsServer) // 服务器端处理逻辑 { if (isPlayerAGoal) { // 球进了A的球门，B得分 scorePlayerB.Value += 1; } else { // 球进了B的球门，A得分 scorePlayerA.Value += 1; } // 可以在这里触发进球特效、音效等 Debug.Log($"Score updated: A {scorePlayerA.Value} - B {scorePlayerB.Value}"); } // 所有客户端都可以在这里播放进球音效或动画 PlayGoalEffectsClientRpc(isPlayerAGoal); } [ClientRpc] private void PlayGoalEffectsClientRpc(bool isPlayerAGoal) { // 在所有客户端播放进球特效和音效 // 例如：FindObjectOfType<AudioSource>().PlayOneShot(goalSound); Debug.Log($"Play goal effect for goal on side: {(isPlayerAGoal ? "A" : "B")}"); } }

流程梳理：

1. 冰球（服务器权威物理）进入球门碰撞体。
2. 球门上的GoalTrigger脚本（仅在服务器端运行）检测到碰撞。
3. GoalTrigger调用GameStateManager的OnGoalScoredClientRpc方法。
4. 在OnGoalScoredClientRpc中，服务器（IsServer判断）更新对应的NetworkVariable分数。
5. NetworkVariable的值变化自动同步到所有客户端。
6. 所有客户端的GameStateManager通过OnValueChanged事件监听到分数变化，更新本地UI。
7. 同时，PlayGoalEffectsClientRpc被调用，在所有客户端播放进球特效和音效，保持视听同步。

4. 网络连接与游戏流程实战

有了核心功能，我们需要搭建一个简单的UI来启动和连接游戏。

4.1 创建连接UI

创建一个Canvas，添加几个按钮：

• “Host (作为主机开始)”
• “Client (作为客户端加入)”
• “IP Address Input Field (输入主机IP)”

创建一个ConnectionManager脚本（无需继承NetworkBehaviour，挂在Canvas上即可）：

using Unity.Netcode; using UnityEngine; using UnityEngine.UI; public class ConnectionManager : MonoBehaviour { [SerializeField] private InputField ipInputField; [SerializeField] private string defaultIp = "127.0.0.1"; // 本地回环地址，用于本地测试 public void StartHost() { NetworkManager.Singleton.StartHost(); HideConnectionUI(); } public void StartClient() { string ip = string.IsNullOrEmpty(ipInputField.text) ? defaultIp : ipInputField.text; // 这里需要设置UnityTransport的连接地址。NGO的NetworkManager配置中需允许设置。 // 一种常见做法是获取Transport并设置： UnityTransport transport = NetworkManager.Singleton.GetComponent<UnityTransport>(); if (transport != null) { transport.SetConnectionData(ip, 7777); // 7777是端口号，需与主机一致 } NetworkManager.Singleton.StartClient(); HideConnectionUI(); } private void HideConnectionUI() { // 隐藏连接按钮和输入框 gameObject.SetActive(false); } }

在Unity Editor中测试时，你可以同时运行多个游戏实例（通过菜单栏 File -> Build Settings -> Open Download Scene -> 勾选“Development Build”和“Server Build”？ 更简单的方法是直接运行两个编辑器实例，或者使用ParrelSync等工具）。在一个实例中点击“Host”，在另一个实例中点击“Client”并输入主机的本地IP（如127.0.0.1），即可实现本地联机测试。

4.2 玩家生成与初始位置

默认情况下，NGO生成的玩家预制体会放在NetworkManager中定义的默认位置。对于冰球游戏，我们需要让两个玩家生成在各自半场的底端。

修改PlayerPaddleController脚本，在OnNetworkSpawn中加入位置初始化逻辑：

public override void OnNetworkSpawn() { base.OnNetworkSpawn(); if (IsServer) { // 服务器决定玩家的初始位置 // 可以根据NetworkObject.OwnerClientId来区分玩家 // 简单起见，假设先连接的是PlayerA，后连接的是PlayerB // 更健壮的做法是使用NetworkVariable存储玩家队伍信息 Vector3 spawnPos = Vector3.zero; if (OwnerClientId == NetworkManager.Singleton.LocalClientId) // 第一个玩家（主机） { spawnPos = new Vector3(0, 0.5f, -8f); // 底部位置 } else // 第二个玩家（客户端） { spawnPos = new Vector3(0, 0.5f, 8f); // 顶部位置 } transform.position = spawnPos; } }

注意：上述方法在纯客户端作为主机时可行，但在专用服务器模式下，LocalClientId不适用。生产环境建议使用一个独立的PlayerSpawnSystem，通过RPC为每个新玩家分配生成点和队伍。

5. 性能优化、调试与常见问题排查

项目基本能跑起来后，接下来就是打磨和排坑阶段。这部分经验往往比实现功能本身更有价值。

5.1 网络带宽与同步频率优化

默认设置可能同步频率过高，浪费带宽。我们需要优化：

1. 调整Tick Rate：在NetworkManager的NetworkConfig里，降低Tick Rate（如从默认的60降到30）。这降低了服务器广播状态的频率，但会增加延迟。对于冰球这种快节奏游戏，需要权衡。30-45可能是合理的起点。
2. 优化NetworkVariable同步：对于玩家球杆的NetworkVariable<Vector3>，可以设置一个阈值，只有当位置变化超过一定距离时才同步，而不是每帧都同步。

   // 在PlayerPaddleController中 private Vector3 lastSyncedPos; private float syncThreshold = 0.01f; if (IsServer && Vector3.Distance(rb.position, lastSyncedPos) > syncThreshold) { networkPosition.Value = rb.position; lastSyncedPos = rb.position; }

3. 冰球同步插值补偿：由于同步频率降低，客户端在收到冰球新位置时，这个位置已经是服务器若干帧之前的状态了。为了补偿，服务器在发送位置时，可以附带一个时间戳。客户端收到后，根据当前时间、时间戳和冰球的速度进行延迟补偿渲染，即把冰球“画”到它当前应该所在的位置（预测位置），而不是它过去的位置。这能显著改善高速运动物体的视觉延迟。Unity NGO本身不直接提供此功能，需要自己实现。

5.2 物理同步一致性调试

这是联机物理游戏最大的坑。现象可能是：两个玩家看到的冰球位置逐渐不一样，或者碰撞结果不同。

• 确保物理引擎确定性：Unity的PhysX默认不是完全确定性的，尤其是在不同硬件或帧率下。尽量确保所有客户端有相似的帧率（使用Application.targetFrameRate），并考虑使用固定时间步长（Time.fixedDeltaTime）。
• 禁用客户端的物理模拟：再次检查，冰球在客户端上Rigidbody.isKinematic是否设置为true。这是最重要的步骤。
• 使用网络调试工具：NGO提供了NetworkTransform组件，但它可能不适合需要精细控制的物理物体。我们可以自己写一个简单的调试脚本来可视化同步差异：

  // 挂在冰球上，仅开发使用 public class SyncDebugger : NetworkBehaviour { public GameObject serverModelPrefab; // 一个红色方块，用于在客户端显示服务器权威位置 private GameObject serverModel; void Update() { if (!IsOwner && IsClient) // 在非控制者的客户端上 { if (serverModel == null) { serverModel = Instantiate(serverModelPrefab); } // 假设有一个NetworkVariable叫serverSyncedPos // serverModel.transform.position = serverSyncedPos.Value; } } }

  这样你就能在客户端看到一个代表服务器位置的标记，和本地渲染的冰球位置进行对比，直观看到同步延迟和误差。

5.3 常见问题速查表

5.4 输入处理与延迟补偿进阶技巧

对于追求极致手感的项目，基础的预测和调和可能不够。这里分享一个更成熟的方案：带缓冲和序列号的客户端输入处理。

1. 客户端：在Update中收集输入，存储在一个带递增序列号的命令缓冲区里。在FixedUpdate中，发送尚未发送的最新输入命令（或一批命令）到服务器，同时立即在本地应用这些命令进行预测。
2. 服务器：收到客户端的输入命令（带序列号）后，按顺序在固定的物理时间步长（FixedUpdate）中执行。服务器维护每个客户端最后处理的序列号。
3. 服务器同步：服务器定期将游戏状态（包括所有物体的权威状态和最后处理的客户端输入序列号）广播给所有客户端。
4. 客户端调和：客户端收到服务器状态后，对比服务器确认的序列号。将本地预测缓冲区中序列号小于等于服务器确认号的命令移除（因为这些命令已经被服务器权威执行了）。对于序列号更高的命令（服务器还没处理到的），客户端继续进行预测。如果客户端发现自己的状态与服务器状态有偏差（比如由于丢包导致服务器没执行某个命令），它需要回滚到与服务器一致的状态，然后重新应用所有未确认的输入命令。这就是所谓的“客户端预测与服务器调和”（Client-side Prediction with Server Reconciliation）。

实现这套机制复杂度较高，但对于快节奏竞技游戏是必要的。Unity的NGO目前没有开箱即用的此类高级网络状态同步方案，你可能需要参考像Fish-Net、Mirror等更专注于游戏网络的第三方库的设计，或者基于NGO自行构建这套逻辑。

6. 项目扩展与进阶方向

当基础的双人对战功能稳定后，你可以考虑以下方向来丰富你的项目：

1. 加入AI对手：实现一个单机模式。AI的逻辑可以完全在本地运行，使用导航网格（NavMesh）或简单的行为树（Behavior Tree）来控制球杆移动和击球。关键是要让AI的行为看起来自然，有挑战性但又不至于完美无缺。
2. 房间与匹配系统：使用Unity的Relay服务（Netcode附带的）或自建信令服务器，实现一个大厅系统，让玩家可以创建房间、分享房间码、自动匹配对手。这涉及到更复杂的网络架构和UI状态管理。
3. 游戏节奏与道具系统：为游戏加入倒计时、局间休息。还可以加入随机出现的道具，如“加速”、“球杆变大”、“冰冻对手”等。道具的生成和效果应用都需要网络同步，确保公平。
4. 更丰富的物理与特效：为冰球和球杆加入击打音效（根据击打力度变化）、碰撞火花粒子特效、冰面划痕轨迹渲染等。这些视听元素能极大提升游戏质感。注意，音效和粒子特效的播放也需要通过ClientRpc在所有人客户端同步触发。
5. 移动平台适配：将游戏移植到手机，用虚拟摇杆或触摸滑动来控制球杆。需要重新设计输入系统，并注意移动设备的性能优化（减少Draw Call，简化物理计算等）。

这个双人联机冰球项目，就像是一个微缩的网络游戏实验室。它几乎触及了实时对战游戏的所有核心难题：权威、同步、预测、调和、状态管理。把它吃透，你再去看那些复杂的多人游戏项目，会发现很多概念都是相通的。我建议你在实现过程中，多使用Unity的Profiler和Network Profiler工具，观察带宽使用和性能瓶颈，不断地调试和优化。网络编程没有银弹，每一个流畅的联机游戏背后，都是开发者与延迟、丢包和不同步现象反复斗争的结果。动手实现一遍，踩过这些坑，你对Unity网络开发的理解才会真正深刻起来。