ZEPETO Players

In the Hierarchy window, select ZEPETO → ZepetoPlayers tab.

You can now add it to your Scene.

Note that just adding ZepetoPlayers doesn't bring the Zepeto Player into the Scene. You need to implement a script using the character creation API of ZepetoPlayers.

If you wish to quickly create and try out only the Local Player in a Scene, refer to the guide:



For a sample on how to display a Zepeto player's name and profile picture, check out the guide:



If you're interested in the ZepetoPlayers API, refer to the documentation:



This guide primarily covers examples of using ZEPETO Players in multiplayer scenarios.



In a single-player world, only a Local Player needs to be created and since only the Local Player appears on the screen, synchronization is unnecessary.

However, in a multiplay world, not only the Local Player which you control directly but also other Players, referred to as Network Players, need to be displayed on the screen.

Every action of the Network Players - moving, jumping, and performing specific gestures - should appear identically on your screen.

This process is called synchronization.

Without implementing the synchronization script, you won't be able to see the Network Player's appearance or movement.

In a multiplay world without synchronization, the only way to know if another client has entered the Room is through the home button.



It's recommended to start by understanding the basic settings and concepts of multiplay through a multiplay tutorial video.



Your Local Player is treated as a Network Player on someone else's device.

This means that even your Local Player must send information to the server for synchronization.

All Players connected to the multiplay world should share their information.

All Clients connected to the Multiplay Room share the Multiplay Room State data.

This Room State data follows the Schema defined in Schemas.json.

(Please consider Schema as a data structure)

In this guide, you will synchronize the player's position through the Room State data. Thus, define a Schema in Schemas.json that can represent the position data for each player.





The server script can recognize when another Player has entered the Room and can send that information to the client to load that Player into the Scene.



When a Player enters the multiplay world's Room, onJoin() is called.

In the server script, add the information of the connected player to the Room State's Players.



Also, when a Player exits the Room, onLeave() is called.

The server script will remove the information of the player who left from the Room State's Players.



When creating a multiplay world, a client script is needed to communicate with the server.

Below is an example of a fundamental client script for multiplayer play.

On the client side, we manage the player data to be displayed in our client using the currentPlayers map data structure.



The pivotal line of code is illustrated below:

ZepetoPlayers.instance.CreatePlayerWithUserId(sessionId, player.zepetoUserId, spawnInfo, isLocal);

When the client receives player information from the server's Room State and a new player joins the Room, a session ID is assigned. If the session ID of the player being created matches our own session ID, the player is considered local. In this case, the player will be instantiated with isLocal = true, indicating that it's the local player.

Subsequently, players who aren't local are created with isLocal = false. This ensures that the appearances of all players, both local and non-local, are rendered on the screen.



Now, when a Player enters, you can confirm that the ZEPETO character is created on your screen.

But, the movement of the Player isn't yet reflected on the screen.



Let's move on to synchronizing the position next.



For synchronization, every time a Player moves or takes some action, they must send their status change to the server.

Sending a message containing their status change to the server is done through Room Message communication.

When the server receives a message about a Player's status change, it updates the Room State.



For instance, let's consider that your local player is named B.

When a Network Player A joins the Room, they are instantiated at the coordinates x:0, y:0, z:0.

If Player A moves to the position x: -10, y: 0, z: 0, B has no actual way of knowing that A is moving.

This is because both are being operated locally on separate devices, hence on separate clients.

Thus, the person controlling A needs to communicate their movement to the server via a Room Message.

Once the server receives this information, it informs everyone present in the Room about A's real-time position. This way, B is finally aware that A is moving.

For the server to notify other players, there are two methods:

This guide utilizes the second method of updating the Room State.



Given that a Zepeto Player loaded into the Scene possesses Zepeto character attributes, you can employ Zepeto character functions to command movements to specific locations or initiate jumps.

For B's client to visualize A's movement to x:-10, y:0, z:0, the most intuitive approach is to use MoveToPosition(). This function will move the player to A's most recent position as received from the server.

Not just position changes, but gestures, skill usage, item collection, and all state changes necessitate server-client communication for synchronization.

You'll need to implement synchronization to keep every action in harmony across the network.



In the basic server script, additional implementation is needed to update the Room State every time a message about a status change from the Local Player's client is received.



Key implementations in the basic client script are: