PlayerProfile

Remarks

Doc 27 keeps Profile opaque on purpose — "the game's own state. Opaque here, and never queried by this layer" — because its schema is doc 28's and the game's. This is the thing that gives that blob a shape without giving the persistence layer one.

⚠ An unknown section is preserved, never dropped, and that is the whole reason the container knows nothing about types. Doc 27 § Upgrades fragments a population by version on purpose: during a rollout, an old realm and a new realm both write the same character. If the old one dropped the section the new one had added, a player who zoned the wrong way would lose it — silently, and only some of the time. A map of id to bytes cannot make that mistake, and the codecs that know types sit above it.

⚠ Sections are written in id order. Two realms that wrote the same state must produce the same bytes, or every checkpoint looks like a change and the row is rewritten on a cadence for ever.

Fields and properties (5)

• public static ReadOnlySpan<byte> Magic

  The four bytes every profile starts with.

• public const int Version

  The format this reads and writes.

• public int Count

  How many slices it holds.

• public uint Revision

  How many times it has changed since it was read.

• public IEnumerable<ProfileSectionId> Sections

  Every section it holds, in id order.

Methods (5)

• public static PlayerProfile Read(ReadOnlyMemory<byte> bytes)

  Reads one back.

• public ReadOnlyMemory<byte> Write()

  Writes it.

• public bool TryGet(ProfileSectionId id, out ReadOnlyMemory<byte> section)

  Reads a slice.

• public bool Set(ProfileSectionId id, ReadOnlyMemory<byte> section)

  Writes a slice.

• public bool Remove(ProfileSectionId id)

  Forgets a slice.

Used by (2)

• PlayerProfileTestsVixen.Live.Gameplay.Tests
• ProfileBinderVixen.Live.Gameplay