Photon PUN 2+ - Setup & Configuration

This page explains how to configure your Unity project to use Runtime Spawner with Photon PUN 2+. It focuses on imports, prefabs, pooling, and bootstrap flow, not scene-level gameplay setup.

If you’re looking for:

• how to place triggers or spawners → Scene Setup & Usage

• runtime errors or desync issues → Troubleshooting

---

Requirements

Before starting, your project must have:

• Photon PUN 2+ installed and configured

• Runtime Spawner v1.5.0 or newer

• MegaCrush Object Pool package imported (included with Runtime Spawner)

• A valid Photon App ID configured in PhotonServerSettings

Runtime Spawner’s PUN integration is optional — the core spawner works offline and single-player without Photon.

---

1. Import the Runtime Spawner Samples

Runtime Spawner ships with reference implementations for PUN.

In Package Manager → Runtime Spawner → Samples, import:

• Runtime Spawner Sample

• Runtime Spawner PUN Sample

The PUN sample includes:

• a working multiplayer scene

• a PunBootstrap script

• prefab registration examples

• master-client startup logic

Use this sample as a reference, not a mandatory dependency.

---

2. Understand the Authority Model (Critical)

Runtime Spawner follows Photon’s Master Client authority model.

Key rules:

• Only the Master Client runs the Runtime Spawner

• Clients never:

  • run spawn loops

  • activate wave triggers

  • control region state

• Clients only observe replicated results

Your bootstrap code must explicitly start the spawner only on the Master Client.

if (PhotonNetwork.IsMasterClient)
{
    spawner.Init();
    spawner.StartSpawners();
}

If you violate this rule, you will see:

• duplicate spawns

• inconsistent population counts

• late-join desync issues

---

3. Player Prefab Setup

Every networked prefab spawned through PUN must have:

• PhotonView (required)

• Network-safe reset logic (recommended)

Optional but recommended:

• PUNPrefabKey component with a stable string ID

PUNPrefabKey

PUNPrefabKey provides a stable lookup key for pooled prefabs.

• If assigned → used as the prefab ID

• If omitted → prefab name is used

This allows:

• prefab renaming without breaking networking

• deterministic prefab lookup across clients

Prefabs do not need to live in Resources/.

---

4. Prefab Registration & Pooling

Runtime Spawner uses a PUN pooling bridge to connect:

• Photon instantiation

• Runtime Spawner’s object pool

• prefab registration and lookup

Automatic Registration (Recommended)

The provided PunBootstrap registers prefabs automatically:

• Player prefab

• Prefabs explicitly listed in the bootstrap

• Prefabs referenced by:

  • RuntimeSpawner

  • LocalAreaSpawner

  • WaveSpawner

  • SpecialEncounterManager

This is done via:

PUNPrefabRegistrar.RegisterFromScene(_provider);

This means:

• you don’t need to manually list every AI prefab

• scene-based workflows are supported

• additive scenes can register content dynamically

Manual Refresh (Advanced)

If you add prefabs at runtime or after a scene load:

_provider.Clear();
PUNPrefabRegistrar.RegisterFromScene(_provider, prewarmEach);

Use this sparingly; most projects won’t need it.

---

5. Bootstrap Responsibilities

Your PUN bootstrap script is responsible for:

1. Connecting to Photon

2. Joining or creating a room

3. Registering pooled prefabs

4. Spawning the local player

5. Starting Runtime Spawner on the Master Client only

The sample PunBootstrap demonstrates all of these steps.

You may:

• replace it entirely

• merge it into your existing game flow

• adapt it for lobby-based or menu-driven projects

The Runtime Spawner does not require a specific bootstrap class.

---

6. Scene Independence

Important design note:

Runtime Spawner, WaveTriggers, and LocalAreaSpawners do not need to be children of the spawner or bootstrap.

This allows:

• additive scene loading

• procedural level tiles

• encounter prefabs spawned at runtime

As long as:

• prefabs are registered

• the Master Client runs the spawner

Everything will synchronize correctly.

---

7. Master Client Migration

If the Master Client leaves the room:

• Photon automatically elects a new Master

• The new Master can safely restart the spawner

• Existing networked objects remain valid

This works because:

• spawning is centralized

• pooled objects are network-owned

• triggers replicate state explicitly

---

8. Quick Setup Checklist

Before moving on, verify:

• Player prefab has a PhotonView

• Networked AI prefabs are registered

• MegaCrush Object Pool is imported

• Only the Master Client starts the spawner

• PUN Sample scene runs correctly in multiplayer

If all of the above are true, your project is ready for scene-level setup.