IGameplayIdentity

Remarks

There are three player identities in this engine and only two of them were joined. Vixen.Net.Sessions.PlayerId is a uint the session assigns; Vixen.Live.Abstractions.PlayerKey is two Guids the database is keyed by; Vixen.Gameplay.PlayerId is a ulong every rule in doc 28 passes around. RealmPlayer already joins the first and the second. Nothing joined the third, and it is the one every durable write starts from.

The join is a widening, not a hash. A gameplay id is its session id in a wider integer. Hashing a 256-bit PlayerKey into 64 bits would collide, and two players who collided would write each other's inventory — so the map is a table populated at admission and nothing is derived.

⚠ A gameplay PlayerId is realm-scoped and must never reach the database. Doc 28 says a PlayerId is *"stable for as long as a party invite or a mute list has to be"*, and those two are not the same length: a party lasts a session and a mute list outlives every realm the player will ever be on. So durable state is keyed by PlayerKey, this is where the translation happens, and a saved row carrying a raw gameplay id would mean somebody else on the next realm.

Methods (2)

• bool TryResolve(PlayerId player, out PlayerKey key)

  Who a gameplay rule's player is, durably.

• PlayerId PlayerFor(PlayerKey key)

  What a durable player is called while they are here.

Used by (5)

• MmoRealmMmo.Realm
• GameplayIdentityMapVixen.Live.Gameplay
• LedgerBridgeVixen.Live.Gameplay
• LockoutBridgeVixen.Live.Gameplay
• SocialBridgeVixen.Live.Gameplay