如何不使用Photon View ID生成/实例化多个游戏对象并实现同步

以下三种方案均不会超出Photon ViewID上限，同时可控制带宽占用在合理范围：

方案1：确定性生成 + 自定义事件同步（优先推荐） #

• Master端仅生成全局统一的食物随机种子、生成规则、全局唯一食物ID序列，不做食物对象的网络实例化，不占用任何ViewID。
• 所有客户端使用完全相同的随机种子和生成规则，本地生成所有2000+食物的坐标、类型、ID属性，用对象池复用渲染对象即可。
• 当玩家触碰销毁食物时，Master端通过Photon的RaiseEvent接口广播被销毁的食物ID，所有客户端收到事件后本地销毁对应ID的食物即可；RaiseEvent无需绑定Photon View，不会占用ViewID配额。
• 该方案全程仅在食物状态变更时传输极小的数据包，带宽占用比单View实例化低90%以上。

方案2：地图分块批量同步（适用于大地图动态生成食物的场景） #

• 将游戏地图划分为若干个独立区块，Master端仅维护全局食物状态列表，不单独为每个食物分配ViewID。
• 当玩家进入某区块时，Master端一次性将该区块内所有食物的属性列表打包发送给对应玩家，玩家本地生成对应食物即可。
• 区块内的食物变更事件仅广播给当前处于该区块范围内的玩家，进一步降低无效带宽消耗。

方案3：单View批量同步（兜底方案） #

• 全局仅为食物管理器组件分配1个Photon View，所有食物的生成、销毁、状态变更都通过该View的RPC接口批量打包发送。
• 可按固定间隔（如100ms）打包当前窗口内所有变更的食物数据，单次发送即可完成多食物状态同步，全程仅占用1个ViewID。

补充：如果需要实现食物重生逻辑，仅需Master端生成新的食物属性后，按上述方案的同步逻辑广播即可，不需要额外分配ViewID。

内容的提问来源于stack exchange，提问作者user17128189