上周有个做独立游戏的朋友半夜发消息给我说他用 Unity 折腾了两周单机射击手感已经调得挺舒服结果一加联机就崩——两边玩家各打各的子弹穿人而过血量同步像抽奖房主一掉线整局作废。他的问题不是代码写得差而是从一开始就没搞清楚 PUN2 这套东西的职责边界谁该同步位置谁该判定命中谁说了算。这篇就把 Unity 用 PUN2 插件实现多人联机射击游戏的完整链路拆开讲从房间连接到位置同步从开火射线到伤害结算再到那些文档里不写、只有真机联调才会跳出来的坑。如果你正在做 Unity 多人在线射击 Demo、课程设计或者想把单机射击玩法快速搬成联机版这篇应该能帮你省下不少试错时间。1. 为什么射击游戏原型阶段我还是推荐 PUN2先把选型这件事说透因为选错方案比写错代码更致命。Unity 做联机目前主流有几条路Mirror、Netcode for GameObjectsNGO、Photon Fusion、PUN2以及自己拿 Socket 撸一套。它们不是谁替代谁的关系而是适配完全不同的阶段和规模。PUN2 最大的价值在于它把服务器这一层完全托管了。你不需要部署、不需要管端口、不需要处理 NAT 穿透注册一个应用拿到 AppId 就能跑起来。对于射击游戏原型来说这意味着你能在两三天内看到一个两边玩家能跑能打的版本把精力全部砸在手感和玩法上而不是耗在运维上。我把几个方案的差异整理成表方便你对照自己的项目阶段做判断方案服务形态权威模型上手成本适合场景PUN2官方托管中继客户端/房主权威低房间制对战、合作、原型验证Photon Fusion官方托管支持共享/服务器权威可切换中高需要服务器权威的竞技项目Mirror自建服务器服务器权威中有运维能力、想完全掌控NGO自建或第三方托管服务器权威中官方技术栈、长期项目自研 Socket全自建自定义高特殊需求、团队有网络专精关键差异在第二列和第三列。PUN2 是中继Relay模式加客户端权威也就是说房间里某个玩家的客户端说了算数据经过官方服务器转发。这个模型的好处是简单直接坏处也明显作弊成本低玩家改个内存就能瞬移。所以 PUN2 适合 PvE 合作、朋友之间开黑、原型验证不适合做排位天梯这种强对抗竞技。射击游戏对网络的硬需求就三条延迟要低、命中判定要即时反馈、状态不能漂移。PUN2 在前两条上表现够用——官方在全球有多个区域节点选对区域后延迟通常在几十毫秒量级命中判定我们可以做本地即时反馈 房主校验的两段式处理这个后面细讲。注意PUN2 单个房间的人数上限受套餐影响免费档通常远小于大规模战场需求。如果你的设计是 32 人以上混战或者需要载具、大面积地图建议直接评估 Photon Fusion 或自建方案别硬扛。还有一点很多人忽略PUN2 的房间是临时的。当房间里最后一个玩家离开房间就销毁没有任何持久化。所以排行榜、战绩、玩家等级这些数据必须走外部存储数据库或官方其他服务不能指望房间帮你记住。2. Room、Player、PhotonView三个对象各自的职责边界搞不清这三个东西的关系后面写多少代码都是乱的。我用一个类比Room 是一场球赛Player 是场上的球员PhotonView 是那个贴在某个人或某个物体身上的号码牌——裁判其他玩家靠号码牌认出这是谁。PhotonNetwork是静态入口所有操作都从它发起连接、加入大厅、创建或加入房间、实例化对象。它不持有状态只是一个门面。Room 层面有几个关键属性值得记住PhotonNetwork.CurrentRoom.Name、PlayerCount、MaxPlayers以及最重要的MasterClient。MasterClient 是房间里被指定为主控的那个客户端房间创建者默认是它它掉线时会自动迁移到另一个玩家身上。很多人把血量、计分这些权威逻辑全挂在 MasterClient 上却没写迁移处理结果房主一掉线整局就废了这是最常见的架构性错误。Player 层面每个玩家有PlayerNumber房间内唯一从 1 开始、UserId跨房间稳定标识、NickName以及CustomProperties一个自定义属性字典。这个 CustomProperties 是把状态同步给中途加入玩家的利器后面讲血量同步时会用到。PhotonView 才是 PUN2 真正的核心。它挂在预制体上运行时被分配一个ViewID这个 ID 在房间内唯一。通过 PhotonView你能做两件事RPC 调用photonView.RPC(某个方法, RpcTarget.Others, 参数)让远端执行一个瞬时动作比如开火、播放受击特效、扣血。状态序列化实现IPunObservable接口或挂内置的PhotonTransformView让拥有者持续把状态推给其他人比如位置、旋转。这两个通道的选择是新手最容易搞混的地方。判断标准很简单特征RPCOnPhotonSerializeView数据性质离散事件一次性连续状态需要持续刷新是否补发否错过就没了是下一次序列化会带最新值典型用途开火、受伤、拾取、聊天位置、朝向、动画参数中途加入拿不到历史 RPC下一帧就能拿到最新状态一句话总结发生了什么用 RPC现在处于什么状态用序列化。开火是事件用 RPC玩家站在哪是状态用序列化。把位置用 RPC 高频发送会造成大量丢包和抖动把开火用序列化发送会漏掉连点。这条线划清楚代码结构立刻就顺了。另外一个细节PhotonView 有OwnerId可以通过photonView.IsMine判断自己是不是拥有者。位置同步的写入逻辑只能由拥有者执行其他客户端只读这是避免两边同时推位置导致抖动的根本原因。3. 从连接服务器到所有玩家出现在同一个场景骨架搭建这块我按实际顺序一步步来每一步都有它必须存在的理由。第一步在 Photon 官网注册账号、创建应用、拿到 AppId。PUN2 需要一个固定的区域Region比如亚洲、欧洲、美国。区域选得对不对直接决定底噪延迟。国内玩家建议选亚洲节点实测下来大部分情况是合理的选择。第二步导入 PUN2 包从 Asset Store 或官方提供的包导入然后在 Unity 菜单里打开 Photon Unity Networking 的配置窗口把 AppId 填进去或者更稳妥的做法是在代码里设置using Photon.Pun; using Photon.Realtime; public class Launcher : MonoBehaviourPunCallbacks { void Start() { PhotonNetwork.AutomaticallySyncScene true; // 房主切场景所有人跟着切 PhotonNetwork.GameVersion 0.1.0; // 版本号不同的客户端互相看不到 PhotonNetwork.ConnectUsingSettings(); } public override void OnConnectedToMaster() { // 连上主服务器后再进大厅才能看到房间列表 PhotonNetwork.JoinLobby(); } public override void OnJoinedLobby() { // 这里可以弹 UI让玩家点击开始游戏 PhotonNetwork.JoinRandomRoom(); } public override void OnJoinRandomFailed(short returnCode, string message) { // 没有可加入的房间就自己开一个 var options new RoomOptions { MaxPlayers 8, IsOpen true, IsVisible true }; PhotonNetwork.CreateRoom(null, options); } }这里有两处值得展开讲。GameVersion是一个很容易被忽略但很实用的字段只有版本号完全一致的客户端才会被匹配到同一个大厅这能防止旧版本客户端进了新版本房间后因为协议不一致而崩掉。AutomaticallySyncScene打开后MasterClient 调用PhotonNetwork.LoadLevel(Battle)其他玩家会自动跟着加载同一个场景。但有个前提所有人必须在同一个房间且切场景的动作要放在大家都准备好之后否则会出现有人还在加载、有人已经开打的情况。我的做法是用 Player 的 CustomProperties 打一个Ready标记等房间内所有人都 Ready 了再由房主切场景。第三步玩家角色实例化。PUN2 的实例化不能直接用Instantiate必须走PhotonNetwork.Instantiate而且预制体要放在Resources目录下或者你自己实现IPunPrefabPool接管加载public override void OnJoinedRoom() { // 注意路径不带 Resources/ 前缀也不带扩展名 PhotonNetwork.Instantiate(Player, GetSpawnPoint(), Quaternion.identity); } Vector3 GetSpawnPoint() { int index PhotonNetwork.LocalPlayer.ActorNumber - 1; return spawnPoints[index % spawnPoints.Length].position; }用ActorNumber来分摊出生点能避免所有人叠在同一个位置互相顶飞。这是个很小但很实用的技巧尤其是出生点数量少于玩家数量时取模可以让分配自动循环。4. 位置、朝向、开火、血量四类数据要分开设计同步策略这是整篇文章里我最想说清楚的一节。很多人的联机射击之所以怪怪的根源就是把所有数据都当成一种东西来同步。实际上它们对延迟的容忍度、权威归属、传输通道都不一样。数据类别权威方传输通道频率说明位置、朝向拥有者自己序列化每秒 10-20 次越高越顺滑但吃带宽开火动作拥有者自己RPC事件触发必须即时不能延迟命中与伤害MasterClientRPC事件触发需要校验防作弊血量、积分MasterClientCustomProperties变化时中途加入也能拿到先说位置。位置的写入方必须是角色的拥有者其他客户端只读并做插值。为什么不让房主统一管所有人的位置因为那样每个玩家的输入都要先绕一圈到房主再发回来延迟直接翻倍手感会糊成一团。让拥有者自己推位置是客户端权威模型下最优的选择代价就是作弊空间大。再说开火。开火这块必须做本地即时反馈也就是玩家按下鼠标的那一帧本地立刻播放枪口火焰、音效、弹道然后才把我开火了这个事件通过 RPC 发出去。如果等服务器确认再播放特效那手感就是灾难。玩家对射击游戏延迟的容忍度极低超过 80 毫秒就能明显感觉到粘手。血量这块最讲究。命中判定如果交给开火方自己做那就是我说我打中了你作弊者可以无限命中。所以流程应该是开火方本地做一次射线检测拿到即时反馈同时把射线信息发给 MasterClient由 MasterClient 再做一次校验并扣血。这个校验不需要 100% 精确只要能把明显作弊挡掉就够了。血量的同步有个坑我必须提前说如果你只用 RPC 广播血量变化中途加入的玩家永远拿不到当前血量他进房间看到的可能是所有人满血然后突然有人倒下。正确做法是把血量写进 Player 的 CustomPropertiespublic void ApplyDamage(int actorNumber, int damage) { Player target PhotonNetwork.CurrentRoom.GetPlayer(actorNumber); if (target null) return; int currentHp target.CustomProperties.TryGetValue(HP, out object hp) ? (int)hp : 100; int newHp Mathf.Max(0, currentHp - damage); var props new ExitGames.Client.Photon.Hashtable { { HP, newHp } }; target.SetCustomProperties(props); }CustomProperties 会被 Photon 自动同步给所有客户端包括后来者而且OnPlayerPropertiesUpdate回调能让你在任何时候刷新 UI。这个方案的额外好处是它自带一致性无论谁在什么时候进房间读到的血量都是权威值。5. 开火链路落地射线、伤害RPC与特效的分工把上一节的策略翻译成代码开火链路大概是这么几个环节。我按执行顺序列出来每一步都有它的作用。using UnityEngine; using Photon.Pun; public class Weapon : MonoBehaviourPun { [SerializeField] float damage 25f; [SerializeField] float fireRate 0.1f; [SerializeField] float range 100f; [SerializeField] LayerMask hitMask; [SerializeField] GameObject muzzleFlash; [SerializeField] Transform muzzlePoint; float nextFireTime; void Update() { if (!photonView.IsMine) return; // 只看自己的输入 if (Input.GetButton(Fire1) Time.time nextFireTime) { nextFireTime Time.time fireRate; Fire(); } } void Fire() { // 1. 本地即时反馈先爽了再说 PlayMuzzleFlashLocal(); // 2. 本地射线检测 Ray ray new Ray(Camera.main.transform.position, Camera.main.transform.forward); Vector3 hitPoint; int hitActor -1; if (Physics.Raycast(ray, out RaycastHit hit, range, hitMask)) { hitPoint hit.point; var targetView hit.collider.GetComponentInParentPhotonView(); if (targetView ! null !targetView.IsMine) hitActor targetView.OwnerActorNr; } else { hitPoint ray.origin ray.direction * range; } // 3. 通知所有人画弹道不包含自己避免重复 photonView.RPC(nameof(RpcDrawTracer), RpcTarget.Others, muzzlePoint.position, hitPoint); // 4. 把命中信息交给房主裁决 if (hitActor ! -1) photonView.RPC(nameof(RpcReportHit), RpcTarget.MasterClient, hitActor, ray.origin, ray.direction, hitPoint); } [PunRPC] void RpcDrawTracer(Vector3 from, Vector3 to) { /* 画弹道线 */ } [PunRPC] void RpcReportHit(int targetActor, Vector3 origin, Vector3 dir, Vector3 hitPoint) { // 只有房主执行这里 if (!PhotonNetwork.IsMasterClient) return; // 简单反作弊检查距离和方向合理性 Player shooter photonView.Owner; Player target PhotonNetwork.CurrentRoom.GetPlayer(targetActor); if (shooter null || target null) return; ApplyDamage(targetActor, (int)damage); // 广播命中特效 photonView.RPC(nameof(RpcPlayHitEffect), RpcTarget.All, hitPoint, targetActor); } [PunRPC] void RpcPlayHitEffect(Vector3 point, int targetActor) { /* 播特效、飘伤害数字 */ } }这段代码里有几个关键决策点我逐个解释。为什么枪口火焰在本地播放弹道却要广播给别人因为枪口火焰是我自己的枪的一部分只有我能看到广播出去纯属浪费带宽。而弹道是别人判断子弹从哪来的依据必须让所有人看到。为什么弹道用RpcTarget.Others而不是All这是新手最容易踩的坑之一。PUN2 的RpcTarget.All会包含发送者自己如果你已经在本地播放了特效再用All广播一遍自己的屏幕上就会出现两发子弹、两个音效。要么本地不放、全靠All要么本地放、广播用Others。我倾向后者因为本地播放没有网络延迟手感最好。为什么调ApplyDamage之前要检查IsMasterClient因为RpcTarget.MasterClient只保证发给房主但如果代码写错用了All这个方法会在所有客户端执行血量就会被扣多次。加一道防御性检查是必须的。反作弊校验怎么做才合理别想着做到完美那是服务器权威方案该干的事。PUN2 场景下你只需要挡住明显不可能的情况开火点离目标太远、方向偏差太大、开火频率超过武器射速。这三条能挡掉 90% 的低级作弊成本却很低。6. 手感和流量的拉锯战插值、量化与序列化频率联机射击的体验好坏一半取决于你怎么处理别人的位置。因为这个位置天然是滞后的——你看到的是对方几十毫秒前的状态。最粗糙的做法是直接把收到的位置transform.position 收到值结果就是远端玩家一卡一卡地瞬移。正确做法是插值把收到的位置作为目标点本地用Lerp慢慢逼近。using UnityEngine; using Photon.Pun; public class NetworkPlayer : MonoBehaviourPun, IPunObservable { [SerializeField] float interpolationSpeed 12f; Vector3 networkPosition; Quaternion networkRotation; void Awake() { networkPosition transform.position; networkRotation transform.rotation; } void Update() { if (photonView.IsMine) return; // 自己的角色不做插值 transform.position Vector3.Lerp(transform.position, networkPosition, Time.deltaTime * interpolationSpeed); transform.rotation Quaternion.Slerp(transform.rotation, networkRotation, Time.deltaTime * interpolationSpeed); } public void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info) { if (stream.IsWriting) { // 我是拥有者往外推数据 stream.SendNext(transform.position); stream.SendNext(transform.rotation); } else { // 我是观察者收数据 networkPosition (Vector3)stream.ReceiveNext(); networkRotation (Quaternion)stream.ReceiveNext(); } } }interpolationSpeed这个值调起来有讲究。太大了远端角色会追得太紧网络一抖动就跟着抖太小了角色看起来像在冰面上滑行跟不上实际位置。我一般从 10 开始试然后根据游戏节奏微调快节奏的竞技射击可以调到 15 到 20。接下来是带宽。位置的默认序列化是三个 float12 字节加四个 float 的旋转16 字节每次 28 字节乘以频率和人数很快就上去了。假设 8 人房间、每秒 15 次序列化28 × 15 × 7 ≈ 2940 字节/秒看起来不多但加上其他对象子弹、可拾取物、载具会迅速膨胀。优化的核心手段是量化。位置用short压缩范围限定在地图尺寸内旋转只发 yaw水平朝向用一个byte因为射击游戏里角色基本不会翻滚public void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info) { if (stream.IsWriting) { // 把位置映射到 short 范围精度约 1/100 米 short x (short)(transform.position.x * 100f); short y (short)(transform.position.y * 100f); short z (short)(transform.position.z * 100f); stream.SendNext(x); stream.SendNext(y); stream.SendNext(z); // 只发水平朝向把 0-360 映射到 0-255 byte yaw (byte)(transform.eulerAngles.y / 360f * 255f); stream.SendNext(yaw); } else { short x (short)stream.ReceiveNext(); short y (short)stream.ReceiveNext(); short z (short)stream.ReceiveNext(); byte yaw (byte)stream.ReceiveNext(); networkPosition new Vector3(x / 100f, y / 100f, z / 100f); networkRotation Quaternion.Euler(0f, yaw / 255f * 360f, 0f); } }改造后每次只有 7 字节带宽直接降到四分之一。但要注意地图尺寸short的范围是 ±32767除以 100 就是 ±327 米。如果你的地图超过这个尺寸得按比例缩小系数。序列化频率通过这两个静态属性控制PhotonNetwork.SendRate 30; // 网络包发送频率 PhotonNetwork.SerializationRate 15; // OnPhotonSerializeView 的调用频率这两个值的默认组合不一定适合射击游戏。SerializationRate决定位置刷新多快15 到 20 是常见区间SendRate是底层通道的发送节奏一般设成SerializationRate的两倍比较稳。改这两个值必须在连接服务器之前连上之后再改是无效的。7. 只有真机联调才会跳出来的六个坑前面都在讲应该怎么做这一节讲实际会怎么翻车。这些坑的共同特点是本地编辑器里跑得好好的一联机就出问题。坑一子弹打两发。前面提过RpcTarget.All包含发送者。排查方法是看你的特效播放代码是不是同时在本地和 RPC 里各写了一次。这个坑很隐蔽因为单机测试时根本看不出来。坑二RPC 静默失败一点报错都没有。PUN2 的 RPC 依赖 PhotonView如果目标对象上没挂 PhotonView或者ViewID不匹配RPC 会直接消失既不会报错也不会执行。排查时先确认photonView不为 null再确认对象是通过PhotonNetwork.Instantiate创建的而不是普通Instantiate。用普通Instantiate创建的对象在网络上根本不存在这是新手最常见的失联原因。坑三预制体找不到实例化报 null。PhotonNetwork.Instantiate的路径必须指向Resources目录内的预制体路径写法不带Resources/前缀、不带扩展名。比如预制体在Assets/Resources/Player.prefab路径就是Player。放在子目录里也行路径写成Prefabs/Player。如果你不想用 Resources它会影响打包体积就得自己实现IPunPrefabPool接管对象的加载和回收。坑四房主掉线整局垮掉。因为伤害结算、敌人生成这些逻辑挂在 MasterClient 上。解决办法是实现OnMasterClientSwitched回调在房主切换时把必要的状态重新初始化public override void OnMasterClientSwitched(Player newMasterClient) { Debug.Log($房主切换为: {newMasterClient.NickName}); // 重新接管敌人 AI、检查所有玩家血量状态等 if (PhotonNetwork.IsMasterClient) { RespawnMissingEnemies(); ValidateAllPlayerHealth(); } }更进一步的做法是把房主负责的状态尽量写进 CustomProperties 或 Room 的 CustomProperties这样房主换人了新来的房主也能从属性里恢复出正确的状态而不是从零开始。坑五玩家中途加入看到血量全满。前面讲过RPC 不补发。所有需要当前值的数据都应该走属性同步而不是 RPC。坑六场景切换不同步导致的顺序错乱。房主切场景时可能有人还在加载、有人已经开始跑了。典型表现是我刚进战场就被打死。解决办法是加一个准备机制用 Player 的 CustomProperties 记录 Ready 状态等所有人都 Ready 再切。排查这类问题的通用思路是先确认网络事件有没有到达再确认业务逻辑有没有执行。在关键 RPC 的第一行加Debug.Log配合PhotonNetwork.LogLevel PhotonLogLevel.Full只在调试时开正式包一定要关掉否则日志会拖慢帧率基本能定位到是哪个环节断的。8. 双开联调、延迟模拟与上线前的收尾检查最后一个实操环节怎么自己测。最省事的方案是在编辑器里跑一个、打包出来跑一个。打包版本连的是同一个 AppId进去后能互相看到。这种方式最接近真实环境缺点是每次改代码都要重新打包迭代慢。想快一点可以用 ParrelSync 这类工具它通过符号链接复制项目目录让你能在编辑器里同时打开多个实例各自独立运行。改一次代码所有实例都能用效率高很多。但要注意 ParrelSync 出来的实例共享同一个 Library 目录某些静态状态可能会串遇到诡异问题时先怀疑这个。测试过程中一定要主动模拟恶劣网络。Photon 提供了一些工具但你也可以自己在序列化环节人为加延迟// 临时测试用人为制造 150ms 延迟 System.Threading.Thread.Sleep(150);这只是个粗暴的验证手段用来确认你的插值逻辑在延迟下是否还稳测试完必须删掉。联调时我会固定检查这几项检查项预期表现不达标时的排查方向两个客户端同时移动对方位置平滑无抖动插值速度、序列化频率连点开火每发都有反馈无重复特效RPC 目标是否用了 All击杀判定只在房主端扣血是否漏了 IsMasterClient 检查中途加入血量、积分正确数据是否走 CustomProperties房主退出游戏不中断房主自动迁移OnMasterClientSwitched 处理长时间运行带宽稳定无内存增长子弹对象是否回收子弹对象回收这点特别容易忽略。如果你用PhotonNetwork.Instantiate不断生成子弹又不销毁带宽和内存都会持续上涨。解决办法是实现IPunPrefabPool做对象池或者至少给每个网络对象加一个生命周期销毁逻辑public class NetworkBullet : MonoBehaviourPun { [SerializeField] float lifeTime 5f; void Start() { if (photonView.IsMine) Invoke(nameof(DestroySelf), lifeTime); } void DestroySelf() { // 只有拥有者有权销毁网络对象 if (photonView.IsMine) PhotonNetwork.Destroy(gameObject); } }销毁网络对象的权限只在拥有者手上其他人调PhotonNetwork.Destroy是无效的这也是一个会让人困惑很久的点。上线前记得关掉所有调试日志、确认GameVersion已经规划好升级策略、检查每个PhotonNetwork.Instantiate的预制体路径是否正确、确认SendRate和SerializationRate是在连接前设置的。这几项任何一项出错都会在玩家那边变成难以复现的怪现象。我个人实际做过几个 PUN2 的射击原型最大的体会是——先把同步骨架搭稳再往上面堆玩法。很多团队急着做武器、做技能、做地图结果底下同步逻辑是歪的每加一个功能就多一层抖动和不同步。反过来如果位置、开火、血量这三条链路一开始就设计清楚了后面加什么内容都是往上叠不会返工。如果预算和团队允许等玩法验证通过、确定要做长期运营时再考虑迁移到服务器权威方案那时候你的网络层抽象如果做得足够干净迁移成本会低很多。