Networking Integrations

Integrating the Runtime Spawner into Photon PUN and Fusion

Networking Integrations

Runtime Spawner (1.6.0+) includes a network-aware factory and driver architecture that enables seamless integration with modern multiplayer frameworks.

These integrations allow Runtime Spawner to behave identically in single-player and multiplayer, while delegating instantiation, pooling, replication, and authority to your chosen networking backend.

---

Overview

At its core, the Networking Integration Layer connects Runtime Spawner’s spawn logic to external networking APIs.

This means:

• Spawner logic stays identical Waves, encounters, regions, and hint systems do not change between offline and multiplayer.

• Factories handle creation & pooling Object creation and destruction are routed through the active networking backend.

• Drivers handle authority & triggers Trigger volumes and region logic are executed deterministically under network authority.

• Lifecycle is synchronized Init, Pause, Resume, and End mirror session state (host, client, disconnects).

---

Supported Networking Stacks

Runtime Spawner currently ships with built-in support for:

• Photon Fusion 2.x

• Photon PUN 2+

All integrations share the same ObjectFactoryAsset architecture, allowing you to switch between offline, Fusion, and PUN with minimal configuration changes.

---

Two Layers: Factories vs Drivers (Important)

Runtime Spawner’s networking support is split into two complementary layers:

---

1️⃣ Object Factories (Creation & Pooling)

Factories answer the question:

How is this object created and destroyed?

They are responsible for:

• Instantiating objects

• Pooling / reuse

• Network replication

• Despawning & cleanup

Examples:

• Local mode → pooled Instantiate

• Fusion → NetworkRunner.Spawn

• PUN → PhotonNetwork.Instantiate

Factories are selected via an ObjectFactoryAsset assigned to the RuntimeSpawner.

---

2️⃣ Network Drivers (Authority & Triggers)

Drivers answer the question:

Who is allowed to decide when spawning happens?

They sit on trigger-based components and handle:

• Authority checks (Host / Master / StateAuthority)

• Replication of “inside / activated” state

• Late joiner consistency

• Deterministic trigger execution

Drivers exist per networking backend and are component-level, not global.

---

Network Drivers by Integration

Photon Fusion Drivers

Fusion uses State Authority and deterministic replication.

Available drivers:

• FusionLocalAreaSpawnerDriver Network-aware region occupancy (biomes, zones, density control)

• FusionWaveTriggerDriver Network-safe wave activation, reset, and auto-start logic

Key characteristics:

• Only the State Authority executes trigger logic

• RPCs replicate state to all peers

• Supports Shared Mode, Host/Server, and Dedicated Server setups

• Optional execution targeting (Everyone / Authority / Server-only)

---

Photon PUN Drivers

PUN uses Master Client authority.

Available drivers:

• PUNLocalAreaSpawnerDriver Master-controlled region entry/exit with optional late-join caching

• PUNWaveTriggerDriverPUN Wave Trigger Driver Master-controlled wave activation and reset via RPCs

Key characteristics:

• Master Client performs all spawning logic

• Clients request activation; Master decides

• Optional caching for late joiners

• Automatic recovery when Master Client changes

---

How It Works (High-Level Flow)

1. RuntimeSpawner decides what should spawn.

2. The active ObjectFactoryAsset decides how it’s spawned.

3. Network drivers decide who is allowed to trigger spawning.

4. The networking backend replicates results to all clients.

5. Despawns return objects to the correct pool or network lifecycle.

Spawner logic never talks directly to Photon or Fusion APIs.

---

Choosing a Networking Integration

Switching networking stacks requires no prefab or scene restructuring.

You typically change:

• The ObjectFactoryAsset

• The driver components used on triggers

Everything else remains identical.

---

Quick Start

1. Import a sample:

   • Runtime Spawner Fusion Sample

   • Runtime Spawner PUN Sample

2. Review the included bootstrap:

   • Connection flow

   • Authority setup

   • Spawner initialization

3. Verify:

   • Network prefabs are registered

   • Factory Asset is assigned

   • Correct drivers are attached to triggers

4. Test:

   • Host + Client

   • Late join

   • Host migration (PUN) or authority handoff (Fusion)

---

Key Components

• RuntimeSpawner

• ObjectFactoryAsset

• FusionObjectFactory / PUNObjectFactory

• LocalAreaSpawner

• WaveTrigger

• Network Driver Components

  • FusionLocalAreaSpawnerDriver

  • FusionWaveTriggerDriver

  • PUNLocalAreaSpawnerDriver

  • PUNWaveTriggerDriver

---

Migration Notes

• Version 1.5.0+ introduced the unified factory + driver architecture

• Older projects with manual networking calls should migrate to:

  • Factory Assets for spawning

  • Drivers for trigger authority

• Spawner lifecycle methods are now network-safe

• Pooling is automatic and backend-aware

---

Extending the System

To support a different networking backend (Mirror, NGO, custom):

1. Subclass ObjectFactoryAsset

2. Implement a runtime IObjectFactory

3. Add optional trigger drivers if authority is required

4. Assign the asset — no spawner logic changes needed

---

Related Pages

• Factory System Overview

• Photon Fusion Setup Guide

• Photon PUN 2+ Setup Guide

---

Summary

The Networking Integrations layer allows Runtime Spawner to scale from offline prototyping to fully networked co-op without rewriting game logic.

In short:

Runtime Spawner decides what and when to spawn Factories decide how objects are created Drivers decide who is allowed to trigger spawning

Everything else stays the same.