> For the complete documentation index, see [llms.txt](https://arawn-software-publishing.gitbook.io/networking-layer-for-gc2/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://arawn-software-publishing.gitbook.io/networking-layer-for-gc2/fusion-overview.md).

# Fusion - Overview

A concrete `NetworkTransportBridge` implementation that wires the Game Creator 2 Networking Layer directly on top of **Photon Fusion 2.1.1**.

This integration uses the Photon Fusion SDK directly. GC2's networking drivers remain responsible for character simulation, prediction, reconciliation, and presentation.

<figure><img src="/files/tlng2MO9IilMKIknsSQO" alt=""><figcaption></figcaption></figure>

#### Requirements

* Game Creator 2 Core and the Game Creator 2 Networking Layer.
* Photon Fusion 2.1.1 installed under `Assets/Photon/Fusion/`.
* A Photon Fusion App ID configured in Photon App Settings for live sessions. Scene generation and validation remain available without one, but the optional generated session UI disables its live-session controls.
* The active gameplay scene added to Build Settings or the active Build Profile when using the included `FusionSessionBootstrap` scene loading.
* Any optional GC2 modules you want to network, such as Stats, Inventory, Melee, Shooter, Quests, Dialogue, Traversal, or Abilities.

Inventory, Melee, Shooter, and Traversal use mandatory GC2 source patches. The current requirements are:

* Inventory `3.0.0-inventory` for GC2 Inventory `2.8.x`.
* Melee `3.5.0-melee` for GC2 Melee `2.2.x`.
* Traversal `2.6.0-traversal` for GC2 Traversal `2.0.x`.
* Shooter `2.2.8-shooter` and Shooter Sight `2.2.4-shooter-sight` for GC2 Shooter `2.2.x`.

The Fusion Scene Setup Wizard verifies the patches for the modules you select and prompts before applying them. If applying a patch starts a Unity compilation, let it finish and run the wizard again. Recheck the patch status after updating or reinstalling a patched GC2 module.

#### Layout

* `FusionTransportBridge.cs` - the concrete `NetworkTransportBridge` and `INetworkRunnerCallbacks` implementation. It owns GC2 input/state routing, readiness, late-join snapshots, ownership checks, module delivery, and Shared master changes.
* `FusionRpcRouter.cs` - static Fusion RPC endpoints for unreliable, reliable, and `ReliableLargeData` delivery. The router is independent from gameplay-object lifetime and State Authority.
* `FusionPacketCodec.cs` - the versioned Fusion packet envelope and deterministic core packet codec.
* `FusionSessionBootstrap.cs` - optional Host/Shared runner owner for projects that do not already have matchmaking or their own runner lifecycle.
* `FusionNetworkIdentity.cs` - maps a Fusion `NetworkObject` to a GC2 network ID and stores the replicated logical player owner separately from Fusion State Authority.
* `FusionNetworkCharacterAuto.cs` - resolves the bridge bound to its `Runner` and initializes the matching `NetworkCharacter` role automatically. It has no scene-manager reference to assign manually.
* `FusionAuthoritySpawnRegistry.cs` and `FusionPlayerSpawner.cs` - authority-only object admission and player spawning.
* `Core/`, `Variables/`, and `AnimationMotion/` - mandatory Fusion bridges for the transport-independent GC2 managers.
* Optional module folders contain isolated Fusion bridges for Stats, Inventory, Melee, Shooter, Quests, Dialogue, Traversal, and Abilities.
* `Arawn.GameCreator2.Networking.Transport.Fusion.asmdef` - isolates Fusion SDK references so the core GC2 networking assembly remains transport-agnostic.
* Editor companion: `Assets/Arawn/NetworkingLayerForGC2/Editor/Transport/Fusion/` contains the scene setup wizard, validation, asset Undo support, and Fusion demo-scene generator.

#### Scene setup (automated)

<figure><img src="/files/X2Svx8pgqzRGFS1A9jtH" alt=""><figcaption></figcaption></figure>

Open `Game Creator > Networking Layer > Fusion Scene Setup Wizard`. The wizard is safe to run again when the scene already contains part or all of the generated setup. It will:

* Validate the Fusion SDK version, Photon settings, global `NetworkProjectConfig`, player prefab, active scene, runner ownership, selected modules, and conflicting transport components.
* Create or reuse the configured scene root (default: `Fusion Session`) and reuse compatible infrastructure already present elsewhere in the active scene.
* Create or reuse `FusionTransportBridge` and `FusionRpcRouter`; in Arawn mode create or reuse `FusionSessionBootstrap`, or in Existing/Manual mode bind to the one existing scene or runtime runner owner.
* Create or reuse the core GC2 managers: `NetworkSecurityManager`, `NetworkCoreManager`, `NetworkAnimationManager`, `NetworkMotionManager`, and `NetworkVariableManager`.
* Create or reuse the mandatory `FusionCoreTransportBridge`, `FusionVariableTransportBridge`, and `FusionAnimationMotionTransportBridge`.
* Create or reuse the selected optional networking component and matching Fusion bridge: a `Network*Manager` for Stats, Inventory, Melee, Shooter, Quests, Dialogue, and Traversal, or `NetworkAbilitiesController` for Abilities.
* Require the Inventory, Melee, Traversal, and Shooter authority patches when their modules are selected. Shooter also requires the Shooter Sight remote-camera safety patch.
* Optionally append the wizard's known installed Melee, Shooter, and Abilities example assets to their bridge registrations without replacing custom entries.
* Create or update `Assets/Arawn/NetworkingLayerForGC2/Generated/Fusion/NetworkSessionProfile.asset` from the selected session preset.
* Create or reuse `FusionAuthoritySpawnRegistry`, `FusionPlayerSpawner`, four default spawn points, and optional character-selection, controls, chat, and demo-session UI helpers.
* Prepare every selected player prefab with safe Fusion authority flags, GC2 networking components, selected module controllers, and Fusion prefab registration.
* Convert recognizable stock Inventory scene pickups when Inventory is selected and report invalid or conflicting pickup identities.
* After required source patches are in place, apply scene, prefab, generated-profile, and Fusion project-configuration changes as one Undo transaction. A failed post-setup validation rolls that transaction back.

The wizard always updates Fusion's global project configuration for this transport:

* `Peer Mode` is set to `Single` because the integration supports one runner per process.
* Player count and a Shared-compatible tick rate from 10 to 32 Hz are applied.
* Client-to-server and client-to-client-via-server-proxy reliable data modes are enabled.
* `Arawn.GameCreator2.Networking.Transport.Fusion` is added to `Assemblies To Weave`.
* Configured player prefabs receive Fusion's prefab label and the Fusion prefab table is rebuilt.

The wizard does not install a project-specific Inventory grant validator. Generic client Add Item requests remain denied until the game uses a trusted server grant, configures `CustomAddValidator`, or deliberately enables trusted-co-op compatibility. See Network Inventory.

The wizard has six pages:

1. **Project** - choose a project template, expected player count, session preset, and generated scene-root name. The prediction backend is fixed to GC2 `BuiltIn` prediction.
2. **Modules** - choose installed optional GC2 modules. Core, Variables, Animation, and Motion are always included. This page also reports required authority patches.
3. **Fusion** - choose the Arawn bootstrap or an existing/manual runner, select the demo default mode, and configure the session name, Photon region, tick rate, and default scene manager.
4. **Core** - review the mandatory managers, bridges, security infrastructure, and deterministic session profile.
5. **Scene** - assign the required editable player prefab, choose whether to author a network-ready GC2 Character kernel, enable local variable synchronization, and select optional UI or character-selection helpers.
6. **Review** - inspect validation and resolve blocking conflicts before selecting **Create / Update Scene Setup**.

Arawn bootstrap mode cannot coexist with a scene `NetworkRunner` or an active Photon `FusionBootstrap`. Existing/Manual mode requires exactly one such external owner and cannot coexist with `FusionSessionBootstrap`.

Save the active scene after setup succeeds. The wizard marks it dirty and saves generated assets, but it leaves the final scene save under your control.

#### Player prefab preparation

The primary player must be an editable prefab asset under `Assets/`. Package prefabs cannot be modified by the wizard or included in its asset Undo transaction.

The wizard adds or configures:

* Fusion `NetworkObject`.
* GC2 `Character` with `Is Player` disabled on the prefab. Runtime ownership decides which spawned character is local.
* `NetworkCharacter` configured for server authority, GC2 built-in prediction, network motion, animation, and core synchronization.
* `FusionNetworkIdentity` and `FusionNetworkCharacterAuto`.
* Selected per-player module controllers and, when requested, `NetworkVariableController`.
* A network-ready GC2 Character kernel when that option is enabled.
* Removal of legacy `NetworkCoreController` components; `NetworkCharacter` owns core networking registration in the current setup.
* Fusion prefab labeling and prefab-table registration.

The Dialogue controller is added only when the prefab already contains a GC2 `Dialogue` component.

The `NetworkObject` is configured as a persistent, non-overridable Master Client Object: `MasterClientObject` is enabled, while `AllowStateAuthorityOverride` and `DestroyWhenStateAuthorityLeaves` are disabled. In Shared mode this lets the current master retain centralized gameplay authority while `FusionNetworkIdentity.LogicalOwner` records which player may send intent for the character.

Do not add Fusion `NetworkTransform`, KCC, `NetworkRigidbody`, `NetworkCharacterController`, `NetworkTRSP`, or `NetworkMecanimAnimator` to a GC2 network character. Those components compete with the GC2 networking driver for position, rotation, physics, or animation state. The wizard treats them as blocking conflicts.

#### Scene setup (manual)

The wizard is the recommended setup path. For a manual integration:

1. Install Photon Fusion 2.1.1, configure the Fusion App ID, and add the gameplay scene to Build Settings or the active Build Profile.
2. Configure `NetworkProjectConfig` for `PeerMode.Single`, a tick rate no higher than 32 Hz, the required reliable transfer modes, the Fusion runtime assembly weave entry, and the Fusion prefab table.
3. Keep exactly one session owner: an Arawn `FusionSessionBootstrap`, one scene `NetworkRunner`, or one active Photon `FusionBootstrap`. Do not combine them.
4. Add `FusionTransportBridge` and `FusionRpcRouter`, assign the router to the transport, and bind the transport to exactly one owner: its `FusionSessionBootstrap`, one explicit scene `NetworkRunner`, or automatic binding when exactly one runtime runner will exist. Bind before `StartGame` and scene-load callbacks; if binding after an already loaded scene, call `NotifyLocalSceneReady()` when that scene is ready.
5. Create a `NetworkSessionProfile`, assign it to `FusionTransportBridge`, and add the core GC2 managers: `NetworkSecurityManager`, `NetworkCoreManager`, `NetworkAnimationManager`, `NetworkMotionManager`, and `NetworkVariableManager`.
6. Add and wire `FusionCoreTransportBridge`, `FusionVariableTransportBridge`, and `FusionAnimationMotionTransportBridge` to the same `FusionTransportBridge`.
7. Add each selected scene-side GC2 networking component and its matching Fusion module bridge. Apply the required GC2 authority patches before testing.
8. Add `FusionAuthoritySpawnRegistry` and `FusionPlayerSpawner`; wire both to the transport and the spawner to the registry, then assign at least one prepared Fusion `NetworkObject` player prefab and one valid spawn point.
9. Prepare player prefabs with `NetworkObject`, `NetworkCharacter`, `FusionNetworkIdentity`, `FusionNetworkCharacterAuto`, safe master-owned flags, and selected module controllers. Label/register every prefab in Fusion's prefab table.
10. For Inventory, convert and validate scene pickups. Runtime pickups require `NetworkObject`, `FusionNetworkIdentity`, and `FusionInventoryRuntimePickupIdentityAdapter` on the same object with the same persistent master-owned flags.

The built-in bootstrap creates a fresh `NetworkRunner` for every start because Fusion runners are single-use. It can create `NetworkSceneManagerDefault` and `NetworkObjectProviderDefault`, include the active build scene, bind the transport, and shut the runner down cleanly. Projects with their own matchmaking can omit the bootstrap and bind the transport to their externally owned runner.

#### Host / Shared session overlay

The optional `FusionDemoSessionUI` provides a smoke-test overlay with a session-name field and these controls:

* **Host** and **Join Host** for Fusion Host/Client sessions.
* **Create Shared** and **Join Shared** for Fusion Shared sessions.
* **Stop Session** to shut down the active runner.

Both peers use the same Photon App ID, region, and session name. Unlike a direct-IP transport, clients do not enter the host's IP address. Leaving Region empty selects Best Region independently on each peer; pin the same region when geographically separated test clients do not see the same named session. With no Fusion App ID, the overlay remains visible but its live session buttons are disabled.

Replace this helper with your own matchmaking and menu UI for production. An externally owned runner setup deliberately does not generate the session overlay because external code owns launch and shutdown.

#### Authority and ownership

* **Host mode:** the Fusion server is the logical GC2 server. Host-local input is short-circuited through the authority pipeline instead of making an RPC round trip.
* **Shared mode:** the current Fusion Shared master is the one logical GC2 server. Transport-managed objects remain master-owned, while `FusionNetworkIdentity.LogicalOwner` identifies the client allowed to submit intent.
* **Shared master changes:** the transport increments an authority epoch, rebuilds identity and manager state, and requires complete module snapshots before gameplay resumes. If a promoted authority cannot restore a consistent state, the integration shuts the session down rather than continue with split authority.
* **Managed objects:** in Shared mode, every `FusionNetworkIdentity`, not only players and pickups, must use the safe master-owned authority flags. Dynamic objects must be spawned through `FusionAuthoritySpawnRegistry`; objects outside the authority admission path are quarantined or rejected.

Fusion Host Migration tokens are not handled by this integration. Use Shared mode when automatic master reassignment is a project requirement.

#### Packet flow and readiness

* Client input: `SendToServer(characterId, inputs[])` → versioned `FusionPacketEnvelope` → `FusionRpcRouter` unreliable RPC → logical authority → `OnInputReceivedServer(senderClientId, characterId, inputs)`.
* Authoritative state: `SendToOwner(...)` / `Broadcast(...)` → versioned envelope → unreliable Fusion RPC → ready clients → `OnStateReceivedClient(...)`.
* Module requests, responses, broadcasts, and snapshots use deterministic module IDs and default to reliable delivery. Reliable packets over Fusion's 384-byte encoded regular-RPC limit use `ReliableLargeData` automatically; oversized unreliable packets are rejected rather than promoted. The total packet limit is 1 MiB.

Normal gameplay messages do not flow immediately after a player connects. The client first reports `SceneReady`, `FusionNetworkCharacterAuto` waits for the admitted player and active module bridges, and then the client reports `GameplayReady`. The authority produces a complete snapshot for every registered regular gameplay module, sends `SnapshotComplete`, and waits for acknowledgement before enabling normal gameplay traffic for that client. Exact pre-gameplay-only message registrations are excluded from the snapshot requirement.

By default, `FusionNetworkCharacterAuto` starts readiness checks after 0.35 seconds and fails after 10 seconds. Core, Variables, and Animation/Motion participants are mandatory, with exactly one active participant per module ID bound to the same transport. Missing, duplicate, misbound, throwing, or never-ready participants shut the session down rather than leave it connected without authoritative gameplay.

This readiness barrier is also used after a Shared master change. Every active regular gameplay module must provide its own complete snapshot producer.

#### Motion smoothing and local tests

Fusion input and character-state packets use unreliable RPC delivery, while GC2's `NetworkSessionProfile` controls input production, state broadcast, state application, interpolation, and reconciliation. The wizard defaults to 32 Hz because the generated setup must remain compatible with Fusion Shared mode.

For `NetworkCharacter` players, let the GC2 networking driver own motion presentation. Tune `serverStateBroadcastRate`, `stateApplyRate`, `interpolationDelay`, and reconciliation in the session profile instead of adding a second Fusion movement synchronizer.

For a local test, run two instances with the same App ID and session name. Start **Host** in one and **Join Host** in the other, or use **Create Shared** and **Join Shared**. The generated Fusion demos default to Shared mode.

Lag compensation remains separate from visual smoothing. `LagCompensationManager` records server-side history for authoritative hit validation; it does not render remote transforms more smoothly.

#### Delivery

Character input and state use Fusion's unreliable RPC channel to avoid stale movement packets blocking newer data. Control messages, module traffic, and late-join snapshots use reliable delivery by default. The transport adds direction validation, authority epochs, payload limits, sender rate limits, and explicit ordering/resynchronization for reliable module traffic.

#### Conflicts and limitations

* Active Ninjutsu Games Fusion Network components and active PurrNet transport bridges cannot share the same scene setup with this transport.
* PurrNet identities/components and competing Fusion movement synchronizers must be removed from, or disabled on, the Fusion player prefab before the wizard can prepare it.
* The wizard never silently deletes Ninjutsu, PurrNet, `NetworkTransform`, or KCC components. The Review page can explicitly disable compatible scene-level conflicts through Unity Undo; prefab conflicts require manual cleanup.
* The integration supports one runner per process. Fusion multi-peer mode is outside this setup.
* The built-in wizard, bootstrap, and demo UI support Host, Join Host, Create Shared, and Join Shared. A dedicated `GameMode.Server`, `Single`, or `AutoHostOrClient` launch path is not part of this documented configuration.
* Shared authority handoff requires every active regular gameplay module to produce a complete reconstructable state. In particular, a master change during an active Abilities cast shuts the session down because the running Daimahou ability task cannot be reconstructed safely.

#### Demo scenes

Generated Fusion examples are available under `Assets/Arawn/NetworkingLayerForGC2/Demo/Fusion/` for Core/Variables, Inventory, Melee, Shooter, Quests, Dialogue, Traversal, Abilities, character selection, chat, and climbing.

#### Module wiring

The Fusion integration includes bridge components for the core layer and each supported optional module. When a module is selected, the wizard creates or reuses its scene-side GC2 networking component and matching Fusion bridge, then wires the bridge to the single `FusionTransportBridge`. At runtime, each active regular gameplay Fusion module bridge participates in readiness and complete late-join snapshots.

Custom Melee weapons, Shooter weapon/model/handle mappings, and Abilities Ability/Projectile/Impact assets that cannot be discovered from spawned controllers must be registered explicitly on their Fusion bridge. Otherwise late-join snapshots cannot resolve them, and missing Shooter model mappings can also prevent remote equipment visuals.

Custom Fusion setups should follow the same public transport contract: wire outbound manager/controller delegates to transport sends, route inbound packets to the matching `Receive*` APIs, validate logical ownership on the authority, and provide a complete late-join snapshot producer for every registered module.