Spawning Players

The Kanda SDK uses a combination of local and remote player representations to support multiplayer functionality. Understanding the difference between these player types, their spawning order, and their structure is crucial for developers working with SDK players.

Player Parts

Players in this package are composed of multiple parts, each represented as a separate entity:

• Origin: The base position of the player in the world
• Head: Represents the player's head and typically controls the camera
• Hands: Represent the player's hands for interaction (in VR setups)

These player parts are created as root-level entities, not in a traditional hierarchical structure. This flat structure offers several benefits:

• Simplified transform logic
• More efficient querying in ECS systems
• Greater flexibility in updating and manipulating individual player parts

Local Players

Local players represent the user's own character and view in the game world. They are spawned on the client side and are fully controlled by the local user's input.

Characteristics of Local Players:

• Spawned and controlled on the client side
• Have full simulation and input processing
• Player parts are marked with the LocalPlayerPart component
• The head part typically controls the MainCamera for the player's view

Local Player Spawning Process:

1. The LocalPlayerSpawnClientSystem checks if a PlayerOrigin component with LocalPlayerPart exists in the scene.
2. If no local player origin is found, it uses the first LocalPlayerSpawner in the world to instantiate the appropriate prefabs for each player part based on the client's device type.
3. The system sets the PlayerInfo component data on the origin, including the device type and player ID.

Remote Players

Remote players represent other users in the multiplayer session. They are spawned on the server and then replicated to all clients.

Characteristics of Remote Players:

• Spawned on the server and replicated to clients
• Synchronized to match their local player counterparts
• Player parts are marked with the RemotePlayerPart component
• Have a GhostOwnerIsLocal component if they have a local counterpart

Remote Player Spawning Process:

1. The client sends a RequestRemotePresenceCommand RPC to the server using the RemotePlayerSpawnClientSystem once the local player is in the game and doesn't have a RemotePresenceRequested component.
2. The server's RemotePlayerSpawnServerSystem receives this request and processes it.
3. The server uses the RemotePlayerSpawner to instantiate the appropriate prefabs for each player part based on the requesting client's device type.
4. The server sets up the remote player entities with the correct PlayerInfo data and initial transforms.
5. The remote player entities are added to the requesting client's LinkedEntityGroup for automatic cleanup on disconnect.
6. The server replicates these new remote player entities to all connected clients.

Synchronization

The synchronization process ensures that remote player representations match their local counterparts:

1. The SynchronizePlayerPartClientSystem handles the synchronization:
   • It finds the remote player parts owned by the client.
   • Ensures it has a reference to the local player parts.
   • Writes the LocalTransform data of the local part to the MovableInput component of the remote part.
2. The PredictedMovableSystem then applies this input to update the remote player's position and rotation.

Respawn Caching

The CacheRespawnPointServerSystem continuously caches target respawn transforms for PlayerOrigin entities:

1. It performs a raycast from the PlayerHead downwards to find a valid teleport floor.
2. If a valid floor is found, it updates or adds an entry to the RespawnPoint buffer.
3. This cached data is used to respawn players at their last known valid position if they disconnect and rejoin.

Spawning Order

The spawning process typically follows this order:

1. Local player spawning:
   • Occurs immediately when the client enters the game world
   • Handled by LocalPlayerSpawnClientSystem
   • Does not require server interaction
2. Remote player request:
   • Triggered after the local player is spawned and the client is fully connected
   • RemotePlayerSpawnClientSystem sends the RequestRemotePresenceCommand
3. Remote player spawning:
   • Server receives and processes the remote player request
   • RemotePlayerSpawnServerSystem creates the remote player entities
   • Server replicates the new remote player to all clients
4. Ongoing spawning:
   • As new players join the session, steps 2-3 repeat for each new player
   • Existing clients receive new remote players as they are spawned on the server

Considerations for Developers

• Ensure that both local and remote player prefabs are properly set up in the LocalPlayerSpawner and RemotePlayerSpawner.
• Be aware of the distinction between LocalPlayerPart and RemotePlayerPart components when implementing player-specific logic.
• The PlayerOrigin, PlayerHead and PlayerHand components are used to identify specific parts of both local and remote players.
• Remember that local players are in complete control of their player parts, and remote players synchronize to match the local player.
• For teleportation and respawning logic, refer to the separate Teleportation page.