3D avatars (experimental)

3D avatars, enabled for everyone with a 2D fallback

We enabled 3D avatars for all users in this release, behind a fallback rather than a gate. The renderer attempts the 3D avatar, and any client that cannot handle it cleanly falls back to the existing 2D representation of the same identity. That fallback is the load-bearing piece: shipping to every user at once is only safe because no device is left without a working avatar. A player on hardware that struggles with the 3D path still sees their profile, just flattened.

The avatar derives from the identity a player already has, so enabling 3D did not require a new identity model or a migration of avatar records. It renders the existing avatar with depth instead of replacing it, which keeps the data model unchanged and lets us roll the feature out broadly without touching stored profiles.

Asset loading and the create-screen preview

Most of the engineering here is asset loading. 3D avatars pull additional model and texture assets, so the loading path was built to fetch those lazily and degrade to the 2D representation if assets fail or the device cannot render them, rather than blocking the surface on a heavy load. That keeps profiles and the rest of the app responsive even when the 3D assets are still resolving.

We also added an avatar preview to the create screen so the 3D avatar renders live during creation. The player sees the dimensional result as they build, driven by the same renderer and the same fallback logic used everywhere else, so what they preview matches what ships to their profile.

This is shipped experimentally on purpose. Enabling it for everyone with a guaranteed 2D fallback lets us collect real device coverage instead of polishing in isolation, while the worldview holds: identity should feel like the player's own, and giving creators and players an avatar with depth across hundreds of games is part of owning that identity rather than a cosmetic upsell.