# Networking Integrations

## 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**](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/networking-integrations/photon-fusion-integration-guide)
* [**Photon PUN 2+**](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/networking-integrations/photon-pun-2+-integration-guide)

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**](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/broken-reference)\
  Network-aware region occupancy (biomes, zones, density control)
* [**FusionWaveTriggerDriver**](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/broken-reference)\
  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**](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/broken-reference)\
  Master-controlled region entry/exit with optional late-join caching
* [**PUNWaveTriggerDriver**](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/broken-reference)[Broken link](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/broken-reference "mention")\
  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](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/technical-details/factory-system-overview)
* [Photon Fusion Setup Guide](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/networking-integrations/photon-fusion-integration-guide)
* [Photon PUN 2+ Setup Guide](https://megacrush.gitbook.io/megacrush-unity-assets/runtime-spawner/runtime-spawner-user-manual/networking-integrations/photon-pun-2+-integration-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.