Ready Player Me Is Deprecated.
Here Is How to Migrate.

Why Ava-Twin

Ava-Twin was built from day one for the constraints that modern Unity developers actually face: WebGL as a first-class build target, an async API that replaces dozens of callbacks with two awaitable calls, and stylized avatars designed for real-time rendering performance rather than photorealism.

It is not a fork of RPM. It is a ground-up rethinking of what an avatar SDK should look like when browser deployment, mobile bandwidth, and developer experience are treated as primary design constraints instead of afterthoughts.

RPM vs. Ava-Twin at a Glance

Before diving into code, here is where the two SDKs diverge.

The most significant differentiator for many teams is WebGL. If your game ships to browsers — or you plan to in the future — this alone justifies the switch. We cover WebGL in depth below.

The Code Difference

This is the single most important comparison. RPM uses a callback-based pattern that requires you to configure a loader, subscribe to events, construct URLs with query parameters, and manage the avatar lifecycle manually. Ava-Twin replaces all of that with two awaitable calls.

Ready Player Me (deprecated)

// RPM: Configure loader, subscribe to events, handle callbacks
var avatarLoader = new AvatarObjectLoader();
avatarLoader.OnCompleted += (sender, args) => {
    var avatar = args.Avatar;
    AvatarAnimatorHelper.SetupAnimator(
        args.Metadata.BodyType, avatar);
    avatar.transform.SetParent(parentTransform);
};
avatarLoader.OnFailed += (sender, args) => {
    Debug.LogError("Avatar load failed: " + args.Message);
};

// Construct the URL from subdomain + avatar ID + parameters
string url = $"https://{subdomain}.readyplayer.me/"
    + $"{avatarId}.glb?morphTargets=ARKit&lod=1";
avatarLoader.LoadAvatar(url);

// Separately: open the web creator in a browser/webview
// and listen for the URL callback via deep link or JS bridge
Application.OpenURL($"https://{subdomain}.readyplayer.me/avatar");

Ava-Twin

// Ava-Twin: Two async calls. That's it.
string avatarId = await AvaTwinSDK.OpenCustomizerAsync();
GameObject avatar = await AvaTwinSDK.LoadAvatar(avatarId);

Seventeen lines of setup code become two. No event subscriptions. No URL construction. No separate browser window. The customizer opens as an embedded iframe inside your Unity WebGL canvas (or as an overlay on desktop builds). When the player finishes customizing, OpenCustomizerAsync resolves with the avatar's short ID. LoadAvatar downloads, instantiates, and rigs the avatar — ready for your Animator Controller.

Migration Step by Step

The migration can be broken into six discrete steps. Most teams complete the entire process in under a day.

Step 1: Create an Ava-Twin Account

Head to console.ava-twin.me and sign up. The onboarding wizard guides you through plan selection and app creation. At the end you will have an App ID and a publishable API key — these replace RPM's application ID and subdomain.

Step 2: Install the Ava-Twin Unity SDK

Install via the Unity Package Manager. Open Window → Package Manager → + → Add package from git URL and paste:

https://github.com/waqaszs/ava-twin-unity-sdk.git#v1.0.0

The SDK is also available on the Unity Asset Store (coming soon). Dependencies (glTFast, Newtonsoft JSON) are resolved automatically. Compatible with Unity 2021.3 LTS and above.

Step 3: Replace Avatar Loading Code

This is the core of the migration. Find every place in your codebase where you interact with RPM's AvatarObjectLoader, AvatarAnimatorHelper, or RPM URL construction and replace them with the two-call pattern shown above. A project-wide search for ReadyPlayerMe will surface every reference.

Step 4: Update Multiplayer Sync

If your game uses multiplayer, you are probably syncing avatar URLs across clients today. RPM URLs are long and contain query parameters, which means you are sending 150+ character strings over your network transport for every player join.

With Ava-Twin, you sync a short alphanumeric ID instead. Wherever you send or receive an avatar URL over the network, replace it with the short ID returned by OpenCustomizerAsync. On the receiving end, call AvaTwinSDK.LoadAvatar(id) to instantiate the remote player's avatar. Multiple concurrent loads are handled internally — no queue management required.

// Multiplayer: when a remote player joins
// Before (RPM): photonView.RPC("LoadAvatar", url);  // ~180 chars
// After (Ava-Twin): photonView.RPC("LoadAvatar", id); // ~12 chars

[PunRPC]
public async void LoadRemoteAvatar(string avatarId)
{
    GameObject avatar = await AvaTwinSDK.LoadAvatar(avatarId);
    avatar.transform.SetParent(remotePlayerRoot);
}

Step 5: Update Animation Setup

Good news: both RPM and Ava-Twin use Unity's Humanoid rig type. Your existing Mecanim Animator Controllers, animation clips, blend trees, and state machines work without modification. Simply assign your Animator Controller to the avatar's Animator component after loading.

Ava-Twin's LoadAvatar returns a GameObject with a properly configured Animator already attached. If you were using RPM's AvatarAnimatorHelper.SetupAnimator utility, you can remove that call entirely — the SDK handles rig setup internally.

Step 6: Remove the RPM SDK

Once you have verified that avatar loading, customization, and multiplayer sync work with Ava-Twin, remove the Ready Player Me SDK package and its dependencies. This typically involves removing the RPM UPM package, any RPM-specific prefabs or scriptable objects in your Assets folder, and cleaning up leftover using ReadyPlayerMe directives.

WebGL — The Killer Advantage

Browser-based gaming is not a niche anymore. Platforms like CrazyGames, Poki, and itch.io see billions of monthly plays. Major studios are shipping WebGL builds to reach players who will never install a desktop client. If your game targets browsers — now or in the future — your avatar SDK needs to work seamlessly in that environment.

Ready Player Me's avatar creator was designed as a standalone web application. In a WebGL Unity build, this created friction: the SDK either opened a new browser tab (breaking fullscreen state), relied on popups (blocked by most browsers), or required a redirect flow that lost session state. On mobile browsers, these workarounds frequently broke entirely — iOS Safari blocks popups aggressively, and redirect flows lose context when the browser reclaims memory.

Ava-Twin takes a fundamentally different approach. The customizer is embedded as an iframe directly inside the Unity WebGL canvas. The player never leaves your game. The iframe communicates with the SDK through postMessage — a browser-native API that works reliably across all modern browsers, including mobile Safari and Chrome on Android. No popups, no redirects, no lost state.

This embedded approach also means the customizer inherits your game's viewport. On a phone, it fills the screen. On a desktop, it overlays the canvas. The transition is smooth and feels native to the game, not like an external tool was bolted on.

Every popup that gets blocked is a player who abandons the avatar flow. Every redirect that fails on mobile is a support ticket. Ava-Twin eliminates both failure modes by design.

What You Keep After Migration

Migration does not mean starting over. Most of your existing work carries forward with minimal or no changes.

Mecanim Animations

Both SDKs produce Humanoid-rigged avatars. Your Animator Controllers, animation clips, avatar masks, blend trees, and state machines all work as-is. You do not need to re-target or re-record animations. If you purchased animation packs from the Asset Store, they remain compatible.

Networking Code

Your multiplayer infrastructure stays the same. Whether you use Photon, Mirror, Netcode for GameObjects, or a custom solution, the only change is the data you sync: a short ID string instead of a full URL. The RPC signatures, network object spawning, and ownership logic remain untouched.

UI and Game Logic

The player-facing flow is the same pattern: click a button, the customizer opens, design an avatar, load it into the scene. Your UI buttons, menu screens, and event handlers need only point to the new SDK method. Your game logic — inventory, progression, social features — is completely unaffected.

Render Pipeline Setup

Ava-Twin auto-detects whether your project uses URP or the Built-in Render Pipeline and applies the correct materials automatically. You do not need to configure shader variants or maintain separate material sets for different pipelines.

Frequently Asked Questions

How long does migration take?

Typically under a day for most projects. The SDK swap itself takes an hour or two. The remaining time is spent updating multiplayer sync (if applicable), testing across your target platforms, and removing the old SDK. Projects with extensive RPM-specific customization (custom GLB processing, morph target pipelines) may take longer.

What about mobile platforms?

Ava-Twin currently supports standalone (Windows, macOS, Linux) and WebGL builds. Native mobile support with an in-app customizer is coming soon. In the meantime, mobile WebGL builds work with the embedded iframe approach, and avatar loading via LoadAvatar works on all platforms today — the customizer is the only component with platform constraints.

What if I need help during migration?

Reach out to hello@ava-twin.me and our team will help you through the process. We have assisted teams migrating from RPM, Wolf3D, and custom avatar pipelines — we know the gotchas and can save you time.

Get Started

Ready to migrate? Here is everything you need:

• Getting Started Guide — account setup, SDK installation, and your first avatar in under 10 minutes
• Unity SDK Documentation — full API reference, configuration options, and platform-specific notes
• Multiplayer Guide — avatar sync with Photon, Mirror, Netcode, and custom transports
• Ava-Twin Console — create your account and get your API key

Questions? Contact us at hello@ava-twin.me. We are happy to help.