What I have noticed there is this one big disadvantage, in the multiplayer behavior for 3D is that when developing a multiplayer game in GDevelop using the standard (non-P2P) Multiplayer extension, it is not possible to reliably assign unique per-player data (e.g., character selection) at scene start. This leads to a all players end up sharing or inheriting the host’s state,even when using object ownership and per-instance variables.Here’s an example, some Players cant not own the same model even if there is duplicate multiple and separate models for that one player evertying gets bugged because,Clients cannot have independent persistent state at scene start.EVERTYING RUNS FROM THE HOST the host,Ownership controls input & sync, not who initializes data which is crazy. Ever time i tried to Use a GlobalVariable it gets Shared then overwritten then broken.
Evertying what i saw is from the debug menu i am not making stuff up.
What i have Tried is:
When Player selects a character it is then (stored in a global variable)
On scene start:
it is Create a player-owned object (Collision_Box)
Assign:
Object variable Player_ID
Global variable named (CharacterChoice)
it Loop through all player objects:
it Spawn the correct character based on the (CharacterChoice)
This approach appears correct but fails consistently.
What i saw in the runing game itself:
- Player 1 (host) spawns correctly
- Player 2:
- Either gets the same character as Player 1
- Or does not spawn correctly
- Debug output shows:
- Shared or overwritten
CharacterChoice - Missing or incorrect per-player differentiation
Key Limitations:
There is no reliable way to assign unique per-player state before spawning gameplay objects using standard multiplayer.
1.No True Per-Player Variables
The standard multiplayer system does not provide player-scoped variables.
Available variable types:
- Global variables → shared across all players
- Scene variables → shared
- Object variables → require correct ownership and timing
There is no built-in equivalent of:
GetPlayerVariable(playerId, variableName)
2.Scene Initialization is Host-Driven
Events like:
“At the beginning of the scene”
Are effectively controlled by the host’s state.
This causes:
- Object creation to be initiated by the host
- Variables copied at creation time to reflect host values
- Clients not having a chance to inject their own state before spawning
3. Ownership Does Not Control Initialization
While you can assign:
Change the player owning the instance
Ownership only affects:
- Input handling
- Synchronization authority
It does not: - Allow each client to initialize their own data
- Provide a per-player execution context at scene start
4. Global Variables Cause Overwrites
Using:
GlobalVariable(CharacterChoice)
Results in:
- Last write wins (usually host or fastest client)
- All players reading the same value during spawn
- Loss of per-player individuality
5. No Built-In Synchronization Step for Player Data
There is no built-in mechanism to:
- Collect player-specific data
- Wait until all players have provided input
- Then initialize the game state consistently
Developers are forced to:
- Use global variables (incorrect)
- Or build custom message systems (complex)
My Final Statement:
The current standard multiplayer system in GDevelop lacks a fundamental concept: per-player state at initialization.
The Common multiplayer features are difficult or impossible to implement correctly and for Developers like myself and others encounter misleading behavior and silent failures i think addressing this would greatly improve Usability,Reduce frustration,Make multiplayer viable for more developers.
