Networking Integrations

Integrating the Runtime Spawner into Photon PUN and Fusion

Networking Integrations

Runtime Spawner 1.5.0 introduces a new network-aware factory system that enables seamless integration with modern multiplayer frameworks.

These integrations allow the spawner to operate identically in both single-player and multiplayer contexts, while delegating actual instantiation, pooling, and replication to your chosen network backend.

Overview

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

This means:

  • Spawner logic stays identical - your waves, encounters, and hint systems don’t change.

  • Factories handle replication - object creation and destruction are routed through the active network layer.

  • Lifecycle control is synchronized - spawner pause, resume, and teardown mirror session transitions.

Currently supported networking stacks:

Integration
Package
Factory Asset
Provider / Adapter

Photon Fusion 2.x

Photon Fusion

FusionFactoryAsset

FusionPoolObjectProvider

Photon PUN 2+

Photon PUN

PUNFactoryAsset

PUNPoolPrefabProvider

Single-Player / Offline

Built-in

SinglePlayerPoolFactoryAsset

PoolAdapter

All networking integrations are built on top of the shared ObjectFactoryAsset architecture, so switching between local and multiplayer modes is a simple asset swap.

How It Works

  1. The RuntimeSpawner requests an object through its assigned ObjectFactoryAsset.

  2. That asset’s runtime factory (e.g., Fusion or PUN) handles actual instantiation:

    • In local mode → from a pool (PoolAdapter).

    • In Fusion → via NetworkRunner.Spawn().

    • In PUN → via PhotonNetwork.Instantiate().

  3. When despawned, objects return to the appropriate pool or are destroyed network-wide.

  4. Lifecycle events (Init, Pause, End) propagate to the network layer automatically.

This modular design allows your spawner setup, encounter design, and hint logic to remain completely independent of the networking backend.

Choosing a Networking Integration

Scenario
Recommended Setup
Description

Offline or local testing

SinglePlayerPoolFactoryAsset

Uses local pooling only - fastest iteration path.

Authoritative co-op or client/server model

FusionFactoryAsset

Fully networked via Photon Fusion 2.x. Deterministic, scalable, supports pooling.

Lightweight peer-to-peer

PUNFactoryAsset

Uses Photon PUN 2+. Ideal for small rooms or simpler replication.

Custom / dedicated backend

Custom subclass of ObjectFactoryAsset

Implement your own instantiation and pooling logic.

Switching between integrations requires no prefab or scene changes - simply assign a different Factory Asset to the spawner.

Quick Start

  1. Import your chosen integration sample from Package Manager → Runtime Spawner → Samples.

    • Runtime Spawner Fusion Sample

    • Runtime Spawner PUN Sample

  2. Review the included Bootstrap scripts for connection flow and spawner initialization.

  3. Verify that your prefabs are network-registered (via Fusion Prefab Table or PUN Prefab Keys).

  4. Confirm your Factory Asset is assigned to the RuntimeSpawner.

  5. Enter Play mode and test host/client behavior.

Key Components

Component
Purpose

FusionFactoryAsset

Creates a FusionObjectFactory tied to a NetworkRunner.

PUNFactoryAsset

Creates a PUNObjectFactory linked to PhotonNetwork.

FusionPoolObjectProvider / PUNPoolPrefabProvider

Bridges Runtime Spawner’s pooling system to the network layer.

FusionBootstrap / PunBootstrap

Example scripts showing connection, room join, prefab registration, and spawner startup.

PUNPrefabKey

(Optional) Assigns stable prefab IDs for PUN registration.

Migration Notes

  • Version 1.5.0 introduced this unified factory architecture. Older projects using manual networking calls should migrate to use the factory assets.

  • Spawner lifecycle (Pause, Resume, End) is now network-safe and synchronized.

  • Pooling is automatic through the active factory’s provider - no manual registration required.

Extending the System

If you use a different networking layer (Mirror, Netcode for GameObjects, custom backend, etc.):

  1. Subclass ObjectFactoryAsset.

  2. Implement a matching runtime IObjectFactory that calls your networking layer’s spawn/despawn APIs.

  3. Optionally bridge to your own pooling provider.

  4. Assign your asset to the spawner - the rest of the system works unchanged.

Related Pages

✅ Summary

The Networking Integrations layer lets Runtime Spawner scale from single-player testing to fully networked co-op play without rewriting game logic. By leveraging modular factory assets, you can integrate any supported networking framework - or even your own - while keeping consistent spawn, hint, and encounter behavior.

In short: The spawner decides what and when to create - the factory (local or networked) decides how it’s created and synchronized.

PreviousAnchor & Hint TagsNextPhoton Fusion Integration Guide

Last updated