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

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

Аватар в метавселенной — это не просто картинка профиля. Это on-chain идентификатор, интероперабельный цифровой объект, который пользователь несёт из одного приложения в другое. Разработка системы аватаров — это пересечение 3D-рендеринга, NFT-стандартов, on-chain storage и кросс-чейн идентичности. Ниже — как это строится изнутри.

Архитектура хранения данных аватара

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-версию аватара как мастер
2. При импорте в платформу — конвертировать через адаптер (server-side или client-side)
3. Маппинг костей и слотов описывать в metadata аватара
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 с поддержкой metadata аватара на уровне протокола.

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

Анимации и поведенческая система

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

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

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

Эмоции и жесты — могут быть NFT-активами. Пользователь покупает "редкий танец" как NFT, и он появляется в его библиотеке жестов. Технически — это отдельный animation clip файл + on-chain запись о праве использования.

Процедурные анимации — IK (Inverse Kinematics) для взаимодействия с окружением: брать предметы, сидеть на поверхностях, реагировать на физику. Реализуется через три.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 с royalty через 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 формата с самого начала.