Розробка Play-to-Earn механік

Розробка механік Play-to-Earn

Play-to-Earn (P2E) — модель, при якій ігровий процес генерує реальну економічну цінність для гравців. Звучить просто, але за цим стоїть одна з найскладніших задач в розробці блокчейна: побудувати ігрову економіку, яка не колапсує після першого наплину користувачів.

Більшість P2E проектів першої хвилі (2021-2022) померли з однієї причини: токеноміка була побудована за схемою Понці. Нові гравці давали гроші старим через інфляцію токена. Без реального сінка (механізму спалювання або споживання токенів) — тільки зростання пропозиції, тільки падіння ціни. Розробка P2E механік сьогодні — це насамперед проектування стійкої внутрішньоігрової економіки.

Економічний фундамент: джерела та сінки

Будь-яка P2E економіка будується на балансі джерел токенів та сінків.

Джерела — звідки токени з'являються в системі:

• Нагороди за гейплей (квести, бої, рейди)
• Нагороди від стейкингу
• Призи турнірів
• Початковий розподіл токенів

Сінки — куди токени йдуть з системи:

• Крафт/апгрейд предметів (спалювання)
• Вхідні комісії для турнірів
• Комісії на маркетплейсі
• Ремонт/техніка обслуговування
• Преміум-функції
• PvP ставки

Здорова економіка: сума сінків > сума джерел у довгостроковій перспективі, або мінімум — балансуються. Якщо джерела домінують — гіперінфляція, смерть економіки.

Модель з двома токенами

Більшість зрілих P2E ігор використовує два токени:

Токен управління/преміум (наприклад, AXS в Axie Infinity, GODS в Gods Unchained) — обмежена пропозиція, для управління, преміум-покупок, стейкингу. Не повинен інфлювати від гейплею.

Утилітарний/коштовний токен (SLP в Axie, FORGE в Gods Unchained) — заробляється в грі, тратиться на крафт/апгрейд. Може мати високу інфляцію, якщо сінк достатній.

Розділення захищає токен управління від інфляції ігрових нагород. Гравець заробляє утилітарний, може обміняти на управління через DEX — але це ринкові механіки, не прямої емісії.

На ланцюгу проти позаланцюгового: де зберігати стан

Фундаментальне архітектурне питання. Більше на ланцюгу — більше прозорості та децентралізації, але дорожче та повільніше.

Повністю на-ланцюгова гра (Dark Forest, 0xMonaco): стан гри у блокчейні, кожен хід — трансакція. Працює тільки для пошагових ігор з кількома ходами. Газ робить реальний час неможливим.

Гібридна модель (переважає): ігрова логіка та стан позаланцюгово на централізованому або децентралізованому сервері. На ланцюгу — тільки NFT предмети/персонажі та фінансові операції (заробіток, витрати, передача).

Позаланцюгово з ZK доказами: гра позаланцюгово, але результати підтверджуються ZK доказами на ланцюгу. Компроміс між продуктивністю та безпеченням. Starknet/StarkEx використовуються для кількох ігор.

Для більшості P2E ігор: гібридна модель — оптимальний вибір. Гейплей позаланцюгово, NFT та токени на ланцюгу.

Розподіл нагород: антифрод та справедливість

Верифікована випадковість

P2E механіки часто вимагають випадковості: дроп предметів, генерація персонажів, жеребкування турнірів. Використовувати block.hash або block.timestamp як джерело випадковості — погана ідея, це маніпульоване.

Chainlink VRF — стандартне рішення. Запитуємо випадкове число, отримуємо його через callback з криптографічним доказом:

import {VRFConsumerBaseV2Plus} from "@chainlink/contracts/src/v0.8/vrf/dev/VRFConsumerBaseV2Plus.sol";

contract GameRewards is VRFConsumerBaseV2Plus {
    mapping(uint256 => address) private requestIdToPlayer;
    
    function requestDrop(address player) external returns (uint256 requestId) {
        requestId = s_vrfCoordinator.requestRandomWords(
            VRFV2PlusClient.RandomWordsRequest({
                keyHash: KEY_HASH,
                subId: subscriptionId,
                requestConfirmations: 3,
                callbackGasLimit: 100000,
                numWords: 1,
                extraArgs: VRFV2PlusClient._argsToBytes(
                    VRFV2PlusClient.ExtraArgsV1({nativePayment: false})
                )
            })
        );
        requestIdToPlayer[requestId] = player;
    }
    
    function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override {
        address player = requestIdToPlayer[requestId];
        uint256 roll = randomWords[0] % 100;
        
        if (roll < 5) {
            _mintLegendaryItem(player); // 5% шанс
        } else if (roll < 25) {
            _mintRareItem(player);       // 20% шанс
        } else {
            _mintCommonItem(player);     // 75% шанс
        }
    }
}

Антибот та Sybil захист

P2E привертає ботів та ферм. Механіки захисту:

Сесійні нагороди — гравець не може фармити більше N ресурсів за сесію. Часове обмеження (щоденна межа).

Система енергії/витривалості — ресурс, який регенерує повільно (24 години). Боти не можуть обійти часовий constraint без багатьох аккаунтів.

Доказ гри — позаланцюговий сервер моніторить ігрові паттерни, підозрілі паттерни (занадто регулярні інтервали, однакові дії) — позначаються. Нагороди видаються тільки після верифікації.

KYC/Soulbound NFT — прив'язка акаунту до верифікованої особи через SBT або KYC. Найсильніший але найбільш інвазивний механізм.

NFT предмети: ERC-1155 vs ERC-721

Для ігрових предметів ERC-1155 переважніший над ERC-721 у більшості випадків:

// ERC-1155: одна колекція, багато типів предметів
contract GameItems is ERC1155 {
    uint256 public constant SWORD_OF_DESTINY = 1;
    uint256 public constant HEALTH_POTION    = 2;
    uint256 public constant MAGIC_DUST       = 3; // взаємозамінний
    
    // Пакетний крафт для нагород квесту
    function rewardQuest(address player, uint256 questId) external onlyGame {
        uint256[] memory ids = new uint256[](3);
        uint256[] memory amounts = new uint256[](3);
        ids[0] = HEALTH_POTION; amounts[0] = 5;
        ids[1] = MAGIC_DUST;    amounts[1] = 100;
        // ...
        _mintBatch(player, ids, amounts, "");
    }
}

Пакетні операції ERC-1155 — значна економія газу при масових нагородах. ERC-721 виправданий для унікальних персонажів/земель де кожен токен справді унікальний.

Метадані на ланцюгу vs позаланцюгово

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

struct ItemBase {
    uint8 itemType;    // тип предмету
    uint8 rarity;      // 0-4: common/uncommon/rare/epic/legendary
    uint16 baseAttack; // базові статистики
    uint16 baseDefense;
}

mapping(uint256 => ItemBase) public itemBases; // tokenId -> базові стати

Динамічні статистики (прокачані рівнем) — позаланцюгово, синхронізуються в смарт-контракт тільки при виставленні на маркетплейс через oracle або довіреного підпису сервера.

Інтеграція маркетплейсу

Користувацький маркетплейс vs інтеграція OpenSea/Blur. Зазвичай обидва: власний маркетплейс для внутрішньоігрових предметів з ігровим UI, відкриті маркетплейси для вторинної торгівлі.

Роялті через EIP-2981: встановлює роялті творця на рівні контракту, підтримується більшістю маркетплейсів:

function royaltyInfo(uint256 tokenId, uint256 salePrice)
    external view returns (address receiver, uint256 royaltyAmount)
{
    return (treasury, salePrice * 500 / 10000); // 5% роялті
}

Управління: DAO для ігрової економіки

Для зрілого P2E проекту — на-ланцюгове управління через токен управління важливо: гравці голосують за зміни ставок нагород, додавання нових механік сінків, розподіл казначейства.

Snapshot + Safe — стандартний стек. Snapshot для позаланцюгового голосування (дешево), Safe для виконання схвалених трансакцій. Для малих рішень — делегований совіт через multisig.

Стек розробки

Вибір мережі

Ігрові трансакції дорогі на mainnet. Рекомендації:

• Polygon PoS — дешево, швидко, зріла інфраструктура. Добре для випадкової P2E.
• Arbitrum — EVM-сумісний L2, низький газ, великих DeFi екосистема для торгівлі токенами.
• Immutable X / Immutable zkEVM — спеціалізовано для ігор: нульовий газ для торговель, NFT-оптимізована інфраструктура.
• Ronin (мережа Axie) — користувацький ланцюг для однієї гри. Робиться сенс тільки на гігантському масштабі.

Графік

MVP P2E механіки (базові токени, NFT предмети, прості механіки нагород, базовий маркетплейс): 2-3 місяці.

Повна P2E ігрова економіка з моделлю двох токенів, VRF лут, антибот захистом, управлінням, користувацьким маркетплейсом: 5-7 місяців.

Токеноміка — окремий deliverable. Економічне моделювання та симуляція перед розробкою: 2-3 тижні. Це не опціонально — критичний крок, що визначає виживе чи гра.