Docs/Player Identities

Player Identities

Every player and every NPC that can take part in a conversation gets a canonical, project-scoped Identity. This is what memory, relationships, and chat history are actually tracked against — separate from an NPC's own character identity (name, voice, personality).

Every participant that can talk to an NPC — a player, or the NPC itself — gets a canonical Identity, scoped to your project. This is not the same thing as an NPC's own character identity (name, voice, personality — see NPCs & Neural Identity). An Identity is about who is in the conversation, not who the NPC is.

How identities get created

NPC identities
Created automatically the moment you create an NPC in the dashboard. No action needed.
Player identities
Created (or looked up, if this device has one already) by an explicit step the SDK runs right after connecting — never as a side effect of sending a chat message.
Identity is resolved before you can chat, not inline with your first message
The SDK sends a dedicated identity-resolution request the moment a MistscaleNPC connects, before any chat or voice message is allowed. If that hasn't completed yet, SendChat is a no-op (it logs a warning) and the server rejects a chat message outright with an IDENTITY_REQUIRED error — there is no automatic identity creation as a byproduct of chatting.

Giving players a stable identity

In the Unity SDK, call SetPlayerId(yourPlayerId) on the MistscaleNPC component before Play — pass your own account id, save-slot id, or platform user id, whatever your game already treats as a stable player reference. The SDK sends it as part of the identity-resolution step described above.

Why this matters
If you never call it, the SDK still resolves an identity automatically (it falls back to a GUID it generates once and persists on-device), so a chat still works — but every player on that shared device collapses into the same identity, since there is no way to tell them apart without a real id. Calling SetPlayerId with a real, stable id is the fix.

What's cached, and why

The very first time a device resolves an identity, the server creates one and returns its internal identity_id — a UUID. The SDK stores that UUID locally (PlayerPrefs) and presents it directly on every later connection, instead of resending the raw player id you supplied. This is deliberate: your external id is only ever the input used to find or create the identity once. From then on, MistScale tracks everything against its own internal id, not yours — so if your game ever changes how it generates player ids, existing players are unaffected.

Project isolation

Identities are scoped to the project they were created in. The same external id in two different projects — two different games, or a dev and a prod project — always resolves to two separate identities. There is no cross-project sharing by default.

Verifying it in the dashboard

Open your project and go to Identities in the sidebar. Every player and NPC identity created so far shows up there — type, status, and when it was first seen. A new player row appears as soon as a MistscaleNPC connects for the first time from a given device — before that player has even sent a message. If you connect and don't see a row appear, check the Console for an IDENTITY_REQUIRED or IDENTITY_SUSPENDED warning; either means resolution failed rather than silently not happening.