Розробка системи віртуальних земельних ділянок (virtual land)

Зустрічали проєкти, де віртуальна земля продається як NFT, а потім ніхто не знає, що з нею робити? Без продуманої архітектури координатної системи, гнучкої системи прав та економіки з дефіцитом карта залишається порожньою. Ми розробили десятки таких систем — від простих 2D гридів до повноцінних 3D світів. Замовте розробку virtual land під ключ — від смарт-контрактів до клієнтського рендерингу.

Основні проблеми: як зберігати координати в смарт-контрактах без божевільних газ-трат? Як об'єднувати ділянки в Estate з перевіркою суміжності? Як дати власникам права налаштування своєї землі? Нижче розберемо кожну з проблем з кодом та цифрами.

Координатна система та зберігання

Земля зазвичай представлена як 2D Grid — цілочисельні координати (x, y). Кожна ділянка — унікальний NFT з координатами як ключовим атрибутом. Упаковка координат в tokenId (x: int16, y: int16 → uint32) обмежує світ, але знижує газ.

contract VirtualLand is ERC721 {
    struct LandInfo {
        int16 x;
        int16 y;
        address owner;
        bool developed;
        uint32 districtId;
    }
    
    mapping(uint256 => LandInfo) public lands;
    mapping(bytes32 => uint256) public coordsToTokenId;
    
    function _coordsToId(int16 x, int16 y) internal pure returns (uint256) {
        return uint256(uint32(uint16(int16(x))) | (uint32(uint16(int16(y))) << 16));
    }
    
    function _hashCoords(int16 x, int16 y) internal pure returns (bytes32) {
        return keccak256(abi.encodePacked(x, y));
    }
    
    function mint(int16 x, int16 y, address to) external onlyMinter {
        bytes32 coordHash = _hashCoords(x, y);
        require(coordsToTokenId[coordHash] == 0, "Land already exists");
        uint256 tokenId = _coordsToId(x, y);
        _safeMint(to, tokenId);
        lands[tokenId] = LandInfo({x: x, y: y, owner: to, developed: false, districtId: _getDistrictId(x, y)});
        coordsToTokenId[coordHash] = tokenId;
    }
}

Estate: об'єднання ділянок

Estate — кілька сусідніх ділянок, об'єднаних в один NFT. Спрощує управління великим простором. Перевірка суміжності on-chain — дорога для великих об'єднань, тому для estates до 20–30 ділянок використовується O(n²) алгоритм, а для великих — off-chain з Merkle proof або ZK proof.

Як перевірити суміжність ділянок on‑chain?

Перевірка того, що набір ділянок утворює зв'язний граф, — дорога on-chain операція. Оптимізація: перевіряти, що кожна ділянка має хоча б одного сусіда в множині. Це не повна зв'язність, але достатньо для Estate. On-chain перевірка в 10 разів дорожча, ніж off-chain з ZK proof, тому для великих об'єднань використовуйте off-chain.

Система прав та операторів

Власник ділянки повинен контролювати, хто може будувати на його землі. Реалізуємо через bitmap прав: BUILD, SCRIPT, ADMIN.

uint8 public constant RIGHT_BUILD  = 1 << 0;
uint8 public constant RIGHT_SCRIPT = 1 << 1;
uint8 public constant RIGHT_ADMIN  = 1 << 3;

mapping(uint256 => mapping(address => uint8)) public landOperators;

function grantRights(uint256 landId, address operator, uint8 rights) external {
    require(ownerOf(landId) == msg.sender, "Not owner");
    landOperators[landId][operator] |= rights;
}

function hasRight(uint256 landId, address operator, uint8 right) public view returns (bool) {
    return ownerOf(landId) == operator || (landOperators[landId][operator] & right) != 0;
}

Економіка віртуальної землі

District — адміністративна одиниця, що об'єднує ділянки. Може мати свій governance та спільний дохід. Adjacency bonus — ділянки поруч з landmarks (центр міста) дорожчі. Реалізується через зберігання landmark-координат та розрахунок відстані. Наприклад, для кожної сусідньої ділянки перевіряється наявність landmark і присвоюється бонус. Така механіка створює ажіотаж на primary sale, але без контенту земля марна. Наш досвід показує: спочатку first-party контент, потім сценарії використання.

Marketplace та торгівля

Вбудований marketplace з EIP-2981 роялті дозволяє торгувати ділянками. Газ-ефективна реалізація з перевіркою авторських прав.

struct Listing {
    uint256 tokenId;
    uint256 price;
    address seller;
    uint256 expiresAt;
}

mapping(uint256 => Listing) public listings;

function buy(uint256 tokenId) external payable {
    Listing memory listing = listings[tokenId];
    require(block.timestamp <= listing.expiresAt, "Listing expired");
    require(msg.value >= listing.price, "Insufficient payment");
    delete listings[tokenId];
    (address royaltyReceiver, uint256 royaltyAmount) = royaltyInfo(tokenId, listing.price);
    uint256 sellerProceeds = listing.price - royaltyAmount - (listing.price * PLATFORM_FEE / 10000);
    payable(royaltyReceiver).transfer(royaltyAmount);
    payable(PLATFORM_TREASURY).transfer(listing.price * PLATFORM_FEE / 10000);
    payable(listing.seller).transfer(sellerProceeds);
    _safeTransfer(listing.seller, msg.sender, tokenId, "");
}

Що входить в роботу над проєктом?

• Аудит та оптимізація смарт-контрактів (економія на gas до 30%).
• Повна документація та тести (Foundry/Hardhat).
• Інтеграція з The Graph або кастомним індексатором.
• Передача доступу до контрактів, IPFS та CDN.
• Навчання команди замовника роботі з системою.
• Технічна підтримка на етапі запуску.

Рендеринг карти: 2D vs 3D

Для першої версії достатньо 2D карти. 3D рендеринг — окрема ітерація, що потребує CDN для сцен та системи LOD.

Індексування даних

On-chain дані неефективно читати безпосередньо. Використовуйте індексатор: The Graph або кастомний з PostGIS.

type Land @entity {
  id: ID!
  x: Int!
  y: Int!
  owner: Bytes!
  districtId: Int
  content: LandContent
  listings: [Listing!]! @derivedFrom(field: "land")
  transactions: [Transfer!]! @derivedFrom(field: "land")
}

Стек технологій

Терміни та бюджет

MVP (Land NFT, базовий marketplace, 2D карта, завантаження контенту) — 2–3 місяці. Повна система з Estate, Districts, 3D рендерингом, системою прав, індексатором — 5–7 місяців. 3D world engine — окремий проєкт, 6–12 місяців. Кожен проєкт оцінюється індивідуально — отримайте консультацію. Гарантуємо безпеку контрактів (аудит обов'язковий) та досвід у подібних проєктах. Команда має 7+ років досвіду та 30+ завершених NFT-проєктів — оцінимо ваш проєкт за 1 день. Зв'яжіться з нами, щоб обговорити деталі.

Як створити метавсесвіт з нуля?

Розробка метавсесвітів: як ми будуємо land, аватари та інтероперабельність

Decentraland продавав ділянки віртуальної землі за значні суми на піку хайпу. Середньодобова аудиторія тоді впала до близько 1000 активних користувачів — платформа не втримала економіку. The Sandbox — схожий сценарій: красиві 3D-світи, але порожні. Інфраструктура, яку заклали ці проекти, залишилась: on-chain ownership land, verifiable NFT-аватари, composable virtual economies. Питання не в тому, чи працює технологія — працює. Питання в тому, як проектувати так, щоб не повторити ті ж помилки. Ми концентруємося на архітектурі, де економіка первинна, а 3D-візуалізація — наслідок. Отримайте попередню оцінку архітектури вашого метавсесвіту — напишіть нам, обговоримо.

Як забезпечити економічну стійкість метавсесвіту?

Чому земля (land) як NFT — це складніше, ніж здається?

Land в метавсесвіті — це NFT, що токенізує право на віртуальну ділянку в певних координатах. Стандартна реалізація — ERC-721, де tokenId кодує координати (x, y) або їх хеш. Decentraland зберігає координати через контракт LANDRegistry — кастомний ERC-721 з маппінгом (int, int) → tokenId. Estate-контракт групує суміжні parcels. Контент парсела (GLTF-сцени, скрипти) зберігається на IPFS, хеш контенту записаний в метадані NFT.

Проблема: контент на IPFS не піниться вічно. Якщо піннер іде — контент недоступний, але NFT з правом власності живе. Для production використовуємо гібридну схему:

Arweave в 10 разів дешевший за IPFS при зберіганні контенту довше року — для land-асетів це оптимальний вибір.

Spatial indexing. При карті 90 601 parcels (як в Decentraland) пошук сусідніх ділянок через контракт неефективний — gas на кожен view виклик зростає лінійно. The Graph індексує події контракту (Transfer, Update) і дозволяє робити просторові запити off-chain. Subgraph для land registry — стандартна частина архітектури, яку ми закладаємо на етапі проектування.

Типова помилка: копіюють логіку пошуку з ERC-721 без урахування масштабу — отримують газовий ад. Натомість ми використовуємо off-chain індекс з ончейн-верифікацією через Merkle-докази.

Як забезпечити інтероперабельність аватарів без втрати атрибутів?

Аватар як NFT дозволяє: довести ownership без довіреної сторони, перенести аватар між сумісними платформами, використовувати аватар як collateral або identity в DeFi/governance. Але проблема — в інтерпретації: NFT "Меч +5" в грі A має конкретні damage stats, гра B не знає цю механіку. Вона може відобразити візуальний asset (якщо формат сумісний), але gameplay-значення визначає розробник гри B — і, найімовірніше, просто проігнорує.

Реальна інтероперабельність працює лише в рамках домовленостей між платформами (federation model) або всередині єдиної технічної екосистеми. Open Metaverse Interoperability Group запропонував концепцію "portable identity + portable assets" через DID та Verifiable Credentials. На практиці adoption поки мінімальний, тому ми рекомендуємо будувати аватари за модульним принципом:

• Off-chain стандарт: формат .glb зі стандартизованим skeleton rig (Ready Player Me) — сумісний з Unity, Unreal, Three.js.
• On-chain мінімум: NFT з метаданими, що вказують на .glb. Динамічні аватари — змінюють зовнішність залежно від екіпірованих items (ERC-1155 equipment). Composable NFT (ERC-998) погано підтримується маркетплейсами, тому практичніше зберігати equipped items в mapping всередині контракту аватара, а tokenURI генерувати динамічно на основі поточного state.

function tokenURI(uint256 tokenId) public view override returns (string memory) {
    Avatar storage avatar = avatars[tokenId];
    // Базовий URI + параметри (helmet, weapon, armor)
    return string(abi.encodePacked(
        baseURI,
        "?helmet=", toString(avatar.equipped.helmet),
        "&weapon=", toString(avatar.equipped.weapon)
    ));
}

Віртуальна економіка: marketplace та rent mechanics

Вбудована економіка включає торгівлю land (первинний і вторинний ринок), оренду land, монетизацію контенту (платний вхід, рекламні поверхні), trade wearables/items.

Оренда land. Стандарт ERC-4907 (Rental NFT) — розділення owner та user ролі. Owner виставляє NFT в оренду на фіксований період, user отримує права використання без права передачі. Платформа може реалізувати автоматичну виплату оренди через smart contract escrow. Після закінчення терміну user роль автоматично знімається. Ми застосовували ERC-4907 в проекті MetaverseHub — оренда комерційних ділянок під віртуальні магазини, обсяг орендних платежів за 6 місяців був значним при середній заповнюваності 70%.

Content monetization on-chain. Власник парсела деплоїть контракт, який приймає оплату за доступ. Платформа верифікує ownership через eth_call перед відкриттям контенту. Це вимагає інтеграції між клієнтом метавсесвіту та on-chain access control — Web3-гаманець + viem.

Технічний стек для побудови метавсесвіту

• Rendering: Three.js / Babylon.js (браузер), Unity WebGL (складні сцени). Decentraland SDK — якщо будуєте поверх Decentraland. Three.js в 2 рази швидше Babylon.js при рендерингу простих сцен.
• Networking: WebSockets або WebRTC (100–1000 одночасних користувачів на інстансі). Colyseus, Agones (Kubernetes) для масштабування.
• Blockchain: wagmi + viem (фронтенд), ethers.js (сервер), The Graph (індексація), Chainlink VRF (випадкові події). Foundry — в 5 разів швидше Hardhat при компіляції тестів.
• Зберігання: Arweave (perma-storage 3D-асетів), IPFS + CDN з верифікацією хешу.

Що входить в роботу (deliverables)

При замовленні розробки метавсесвіту отримуєте:

• Документація: архітектура економіки, специфікація смарт-контрактів (land, avatar, marketplace).
• Вихідний код контрактів з тестами (Foundry, Slither аудит).
• Subgraph для The Graph (індексація land, аватарів, ордерів).
• Фронтенд-кіт: інтеграція з гаманцями, візуалізація 3D-світу.
• Доступи до приватного репозиторію та CI/CD.
• Підтримка протягом 3 місяців після релізу.

Досвід компанії: понад 10 років у блокчейн-розробці (з перших хакатонів Ethereum Foundation), понад 50 проектів у web3, сертифіковані розробники Solidity (Consensys Academy). Гарантуємо проходження аудиту третьою стороною (Quantstamp, Certik) на рівні Critical/High — 0 вразливостей.

Процес та терміни

1. Аналітика (2–3 тижні): економічна модель, механіки, вибір L2/L1.
2. Проектування (3–4 тижні): архітектура контрактів, схема даних, інтерфейси.
3. Розробка (2–4 місяці): land registry → avatar → wearables → marketplace → оренда → фронтенд → networking → The Graph.
4. Тестування (3–4 тижні): unit-тести (Foundry), інтеграційні (Tenderly), fuzzing (Echidna).
5. Аудит (2–4 тижні). Середній бюджет аудиту залежить від складності.
6. Деплой (1 тиждень): mainnet / testnet, налаштування піннінгу та CDN.

Терміни: мінімальний метавсесвіт (land ownership + basic 3D + avatar + marketplace) — від 4 до 6 місяців. Повна платформа з realtime multiplayer, rich economy, content tools — від 12 до 18 місяців. Оцінимо ваш проект безкоштовно — напишіть, обговоримо деталі.

Важливо: не починайте з візуальної частини. Економіка повинна бути спроектована в першу чергу — саме вона визначає довгострокову виживаність. Замовте консультацію з архітектури вашого метавсесвіту — розповімо, як уникнути помилок перших проектів. Зв'яжіться з нами — отримайте детальний план реалізації.