Photon PUN 2+ - Scene Setup & Usage

This page explains how to author gameplay scenes using Runtime Spawner with Photon PUN 2+. It focuses on where components live, how triggers behave in multiplayer, and how to structure scenes safely.

If you’re looking for:

• imports, prefabs, bootstrap → Setup & Configuration

• runtime errors or desyncs → Troubleshooting

---

Core Rule (Reinforced)

Only the Master Client executes gameplay logic. All other clients observe replicated results.

This applies to:

• RuntimeSpawner

• WaveTriggers

• LocalAreaSpawners

• All spawn loops and population logic

Scene setup should assume:

• triggers exist on all clients

• only the Master Client drives them

---

1. RuntimeSpawner Placement

Each gameplay scene that should spawn content needs exactly one RuntimeSpawner.

Typical patterns:

• One RuntimeSpawner in the main gameplay scene

• One RuntimeSpawner per additive “map chunk” (advanced)

• A persistent RuntimeSpawner loaded via a bootstrap scene

Requirements

• RuntimeSpawner must exist before triggers activate

• Only the Master Client should call:

  spawner.Init();
  spawner.StartSpawners();

Clients should never call these methods.

See the PUN Bootstrap script included with the Runtime Spawner Samples in the Unity Package Manager for example code.

---

2. WaveTrigger in PUN

WaveTrigger defines when a wave starts. In PUN, it must be paired with a PUNWaveTriggerDriver.

Required Components

On the same GameObject:

• BoxCollider (isTrigger = true)

• WaveTrigger

• PUNWaveTriggerDriver

• PhotonView

How it works

• Trigger detection runs only on the Master Client

• When activated:

  • the driver replicates state to all clients

  • RuntimeSpawner starts the wave (Master only)

• Clients:

  • receive spawned enemies via Photon

  • receive trigger state via RPCs

Common use cases

• One-shot ambush rooms

• Repeatable horde zones

• Auto-start survival waves

• Scripted defense encounters

---

3. LocalAreaSpawner in PUN

LocalAreaSpawner defines where population rules apply.

In PUN, it must be paired with PUNLocalAreaSpawnerDriver.

Required Components

On the same GameObject:

• BoxCollider (isTrigger = true)

• LocalAreaSpawner

• PUNLocalAreaSpawnerDriver

• (PhotonView not required — uses RaiseEvent)

How it works

• Any client can detect entry

• Non-master clients request authority

• Master Client:

  • validates entry

  • sets region inside/outside state

  • optionally caches state for late joiners

• Only the Master Client calls:

  LocalAreaSpawner.SetPlayerInRegion(bool)

Why this matters

This prevents:

• double region activation

• client-driven spawning

• late-join population mismatch

---

4. Additive Scenes & Procedural Content

Runtime Spawner is scene-agnostic.

You may safely:

• load WaveTriggers additively

• spawn LocalAreaSpawners at runtime

• stream encounter prefabs

• use procgen tiles

As long as:

• prefabs are registered with the PUN provider

• the Master Client runs the spawner

Late joiners

• WaveTriggers replicate activation via RPC

• LocalAreaSpawners can cache inside/outside state

• Spawned objects sync automatically through Photon

---

5. Player Colliders & Trigger Detection

Unity trigger rules still apply:

• At least one collider must have a Rigidbody

• Layers and tags must match driver filters

• Root or attached Rigidbody tags are supported

Recommended:

• Put Rigidbody on the player root

• Use consistent player tags

• Filter activation layers narrowly for performance

---

6. Scene Authoring Patterns

Pattern A — Simple Encounter Room

• Place WaveTrigger in the room

• Assign WaveSpawner

• Add WaveSpawnPoints

• Add PUNWaveTriggerDriver

• Done — no scripting required

Pattern B — Region-Based Population

• Add LocalAreaSpawner volumes

• Configure min/max counts

• Assign region-specific SpawnEntries

• Add PUNLocalAreaSpawnerDriver

• RuntimeSpawner handles the rest

Pattern C — Hybrid

Use both:

• LocalAreaSpawner for ambient population

• WaveTrigger for spikes / encounters

This is the recommended pattern for:

• city blocks

• dungeon rooms

• open-world POIs

---

7. Debugging in Scene View

Both PUN drivers expose runtime snapshots in the inspector (play mode only):

• Is Master Client

• Inside state (authoritative)

• Target references

• PhotonView info (WaveTrigger)

Use these to verify:

• authority is correct

• triggers aren’t firing on clients

• state is being replicated

---

8. What Not To Do

Avoid:

• Calling spawner.Init() on clients

• Letting clients activate waves directly

• Running spawn logic in Update on networked objects

• Having multiple RuntimeSpawners active unintentionally

These mistakes lead to:

• duplicate enemies

• desyncs

• late-join bugs

• hard-to-debug Photon issues