Розробка системи аватарів для метавсесвіту

Розробка системи аватарів для метавселенної

Аватар в метавселенні — це не просто картинка профіля. Це on-chain ідентифікатор, інтероперабельний цифровий об'єкт, який користувач несе з одного програму в іншу. Розробка системи аватарів — це перетин 3D-рендерингу, NFT-стандартів, on-chain сховища та кросс-чейн ідентичності. Нижче — як це будується зсередини.

Архітектура сховища даних аватара

On-chain vs off-chain: що де зберігати

Перше архітектурне рішення — що живе on-chain, а що ні. Зберігати повну 3D-модель на блокчейні економічно безглуздо: один GLB-файл важить 2–20 MB, транзакція з такими даними коштувала б тисяч доларів на Ethereum mainnet.

Стандартна схема:

Trait hash — це keccak256 від JSON-об'єкту з характеристиками аватара. Він зберігається on-chain і дозволяє верифікувати, що off-chain дані не були замінені.

struct AvatarTraits {
    bytes32 traitsHash;      // keccak256 від traits JSON
    uint16 bodyType;         // enum: slim/athletic/heavy
    uint16 skinTone;         // 0-255
    uint32 equippedItems;    // bitmap екіпірованих NFT
    address customization;   // адреса кастомізаційного контракту
}

mapping(uint256 => AvatarTraits) public avatarData;

Стандарт метаданих: розширення ERC-721

Базовий ERC-721 metadata стандарт (name, description, image, attributes) недостатній для повноцінного аватара. Потрібне розширення, сумісне з OpenSea, але з 3D-специфічними полями:

{
  "name": "Avatar #4721",
  "description": "...",
  "image": "ipfs://Qm.../preview.png",
  "animation_url": "ipfs://Qm.../avatar.glb",
  "external_url": "https://metaverse.example/avatar/4721",
  "attributes": [...],
  "avatar_data": {
    "version": "1.2",
    "base_model": "ipfs://Qm.../base_athletic.glb",
    "rig": "mixamo_compatible",
    "textures": {
      "albedo": "ipfs://Qm.../skin_albedo.png",
      "normal": "ipfs://Qm.../skin_normal.png"
    },
    "vrm_url": "ipfs://Qm.../avatar.vrm",
    "ready_player_me_id": "optional_rpm_id"
  }
}

Поле animation_url з GLB/VRM файлом — це те, що дозволяє OpenSea та іншим маркетплейсам рендерити 3D-превью прямо в інтерфейсі.

Система кастомізації та екіпіровки

Модульна архітектура аватара

Базова модель аватара будується за принципом слотів: body, head, hair, top, bottom, shoes, accessories. Кожен слот може бути заповнений NFT з різних колекцій — за умови, що вони відповідають стандарту сумісності.

Smart contract рівень:

contract AvatarEquipment {
    mapping(uint256 => mapping(uint8 => EquippedItem)) public equipment;
    // avatarId => slotId => item

    struct EquippedItem {
        address nftContract;
        uint256 tokenId;
        uint8 slot;
    }

    function equip(
        uint256 avatarId,
        address nftContract,
        uint256 itemTokenId,
        uint8 slot
    ) external {
        require(ownerOf(avatarId) == msg.sender, "Not owner");
        require(
            IERC721(nftContract).ownerOf(itemTokenId) == msg.sender,
            "Don't own item"
        );
        require(
            IWearable(nftContract).isCompatible(slot),
            "Incompatible slot"
        );

        equipment[avatarId][slot] = EquippedItem(nftContract, itemTokenId, slot);
        emit ItemEquipped(avatarId, nftContract, itemTokenId, slot);
    }
}

Інтерфейс IWearable — це стандарт сумісності, який мають імплементувати всі NFT-колекції одежі/аксесуарів в екосистемі. Без нього ви отримуєте ізольовані острови контенту, які не працюють разом.

VRM та інтеграція Ready Player Me

VRM (Virtual Reality Model) — відкритий стандарт для humanoid 3D-аватарів, заснований на glTF 2.0. Підтримується у VRChat, cluster, Resonite та багатьох інших платформах. Якщо ви будуєте систему аватарів з розрахунком на інтероперабельність — VRM це базовий формат.

Ready Player Me надає SDK для генерації та кастомізації аватарів з готовим Web-редактором. Інтеграція через їхній API дозволяє вбудувати їхній редактор в вашу метавселенну за лічені дні, але накладає залежність від стороннього сервісу. Хороше рішення для MVP, вимагає заміни при масштабуванні.

Наш рекомендований стек для production:

• Three.js / React Three Fiber — рендеринг у браузері
• @pixiv/three-vrm — парсинг та рендеринг VRM у Three.js
• Mixamo — риггінг та анімації (можна переносити на будь-який rigged mesh)
• Draco compression — стиск GLB геометрії (60-80% зменшення розміру)

Інтероперабельність та кросс-платформна ідентичність

Проблема інтероперабельності

Теоретично, якщо аватар — це NFT, він повинен працювати скрізь. На практиці Decentraland, The Sandbox та Roblox використовують різні формати, різні пропорції моделей, різні системи скелетів. Аватар з однієї платформи не можна напрямку використовувати в іншій без конвертації.

Часткове рішення — стандарти Open Metaverse Interoperability (OMI) Group та Metaverse Standards Forum. На 2024-2025 рік повної стандартизації немає, але є робочі підходи:

1. Зберігати канонічну VRM-версію аватара як master
2. При імпорту в платформу — конвертувати через адаптер (server-side або client-side)
3. Маппінг костей та слотів описувати в метаданих аватара
4. Використовувати morph targets для адаптації пропорцій

ENS та децентралізована ідентичність

Для зв'язку аватара з on-chain ідентичністю використовується кілька підходів:

ENS (Ethereum Name Service) + text records: користувач прописує token ID свого аватара в ENS записах. Додатки резолвят ENS → дістають аватар → рендерять.

avatar.vitalik.eth = eip155:1/erc721:0xAbC...123/4721

Цей формат (CAIP-19) стандартизований та підтримується зростаючою кількістю протоколів.

Lens Protocol зберігає аватар як частину профіля — NFT-based social graph з підтримкою метаданих аватара на рівні протоколу.

Ceramic Network / DID — децентралізовані документи ідентичності, де аватар — одне з полів профіля користувача.

Анімації та поведінкова система

Системи анімацій

Анімації аватара діляться на три категорії:

Базові анімації (idle, walk, run, jump) — поставляються з системою та працюють зі всіма аватарами через rigged skeleton.

Емоції та жести — можуть бути NFT-активами. Користувач купує "рідкий танець" як NFT, і він з'являється в його бібліотеці жестів. Технічно — окремий animation clip файл + on-chain запис про право використання.

Процедурні анімації — IK (Inverse Kinematics) для взаємодії з оточенням: брати предмети, сидіти на поверхнях, реагувати на фізику. Реалізується через three.js + готові IK solvers (three-ik, fabrik).

Синхронізація в мультиплеєрі

Синхронізація анімацій у реальному часі — одна з найскладніших задач. Стек для WebSocket-based метавселенної:

• State compression: передавати не полний transform, а delta + quaternion rotation
• Interpolation: клієнт інтерполює між отриманими станами (lerp/slerp)
• Dead reckoning: передбачення позиції при втраті пакетів
• Priority queue: ближчі аватари отримують більш частих оновлень

Протокол: WebRTC data channels для P2P (малі інстанси), WebSocket через сервер для великих. Формат: бінарний (MessagePack або FlatBuffers), не JSON — різниця у навантаженню в 3-5 разів.

Економіка аватарів та монетизація

NFT-шари монетизації

Система аватарів відкриває кілька рівнів монетизації:

Base avatars — колекція базових аватарів (PFP-стиль), генерація через алгоритм на основі traits. Стандартний ERC-721 mint з роялті через ERC-2981.

Wearables marketplace — NFT-одежа та аксесуари від перших та третіх сторін. Creator royalty = частина з кожної продажі.

Animation passes — підписка або разова покупка на доступ до бібліотеки анімацій.

Avatar rentals — ERC-4907 (rentable NFT) дозволяє власнику аватара здавати його в оренду на час. User role = тимчасовий користувач без права передачі.

// ERC-4907
function setUser(uint256 tokenId, address user, uint64 expires) external {
    require(ownerOf(tokenId) == msg.sender, "Not owner");
    UserInfo storage info = _users[tokenId];
    info.user = user;
    info.expires = expires;
    emit UpdateUser(tokenId, user, expires);
}

Цей механізм особливо цікавий для ігор, де аватар = персонаж з прокачкою: оренда високорівневих персонажів — окремий ринок.

Технічний стек та рекомендації з реалізації

Для проекту з нуля рекомендуємо такий стек:

Основна порада з практики: не намагайтеся побудувати повну інтероперабельність з першої версії. Почніть з VRM як внутрішнього формату, забезпечте якісний рендер всередину своєї платформи, та додавайте адаптери для інших платформ ітеративно. Архітектура повинна це дозволяти — звідси важливість стандартизованого metadata формату з самого початку.