Разработка системы энергии/выносливости GameFi

Разработка системы энергии/выносливости GameFi

Мы сталкивались с задачей создания on-chain системы энергии, которая не сжигает газ при регенерации. Обычный подход — обновление storage каждую секунду — убивает экономику и делает игру неиграбельной. Наша реализация использует lazy evaluation, что позволяет вычислять текущую энергию без записи. За 5+ лет опыта мы выработали архитектуру, балансирующую между gas economy и защитой от читеров. В этой статье разберем ключевые механики: time-based regen без write, привязку к NFT, tradeable energy и anti-cheat.

Система энергии — механика ограничения игровой активности. Игрок тратит энергию на действия (битвы, фарминг, крафт), энергия восполняется со временем или через покупку. В Web2 это просто счётчик в базе данных. В Web3 это on-chain ресурс, что создаёт и возможности (tradeable энергия, verifiable regen), и проблемы (gas за каждое обновление, cheating prevention). Правильная архитектура энергетической системы — одна из ключевых инженерных задач GameFi. Её неправильная реализация либо делает игру неиграбельной (слишком много on-chain операций), либо открывает эксплойты (бесплатная энергия через manipulation).

Архитектура lazy evaluation для экономии газа

Интуитивное решение: хранить энергию в mapping, обновлять каждую секунду. Это плохо — бесконечное количество транзакций. Правильный подход: lazy evaluation. Храним не текущую энергию, а момент последнего изменения и значение в тот момент. Текущая энергия вычисляется on-the-fly при каждом чтении:

contract EnergySystem { struct EnergyState { uint128 storedEnergy; uint64 lastUpdateTime; uint64 maxEnergy; } mapping(address => EnergyState) private energyStates; uint256 public constant REGEN_RATE = 1e18; uint256 public constant MAX_ENERGY = 100e18; function currentEnergy(address player) public view returns (uint256) { EnergyState storage state = energyStates[player]; uint256 elapsed = block.timestamp - state.lastUpdateTime; uint256 regenerated = elapsed * REGEN_RATE; uint256 total = uint256(state.storedEnergy) + regenerated; uint256 max = state.maxEnergy == 0 ? MAX_ENERGY : uint256(state.maxEnergy); return total > max ? max : total; } function _updateEnergyState(address player) internal { EnergyState storage state = energyStates[player]; state.storedEnergy = uint128(currentEnergy(player)); state.lastUpdateTime = uint64(block.timestamp); } function spendEnergy(address player, uint256 amount) internal { uint256 current = currentEnergy(player); require(current >= amount, "Insufficient energy"); _updateEnergyState(player); energyStates[player].storedEnergy -= uint128(amount); } function addEnergy(address player, uint256 amount) internal { _updateEnergyState(player); uint256 max = energyStates[player].maxEnergy == 0 ? MAX_ENERGY : energyStates[player].maxEnergy; uint256 newEnergy = uint256(energyStates[player].storedEnergy) + amount; energyStates[player].storedEnergy = uint128(newEnergy > max ? max : newEnergy); } } 

Ключевой момент: currentEnergy() — view функция, не тратит gas. Storage обновляется только при spendEnergy/addEnergy — то есть при реальном игровом действии. Lazy evaluation снижает gas consumption в 10 раз по сравнению с постоянным обновлением storage. Согласно документации Solidity, packed structs экономят storage gas.

Как привязать энергию к NFT?

Энергия привязана к конкретному NFT, не к EOA кошельку. Это важно: игрок может иметь несколько персонажей с независимой энергией, торговать персонажами вместе с их текущей энергией.

contract CharacterEnergySystem { struct CharacterEnergy { uint128 storedEnergy; uint64 lastUpdate; uint8 tier; } mapping(uint256 => CharacterEnergy) public characterEnergy; function regenRateForTier(uint8 tier) public pure returns (uint256) { if (tier == 3) return 3e18; if (tier == 2) return 2e18; return 1e18; } function maxEnergyForTier(uint8 tier) public pure returns (uint256) { return 100e18 + uint256(tier) * 50e18; } function currentEnergy(uint256 tokenId) public view returns (uint256) { CharacterEnergy storage ce = characterEnergy[tokenId]; uint8 tier = nftContract.getTier(tokenId); uint256 elapsed = block.timestamp - ce.lastUpdate; uint256 regen = elapsed * regenRateForTier(tier); uint256 total = uint256(ce.storedEnergy) + regen; uint256 max = maxEnergyForTier(tier); return total > max ? max : total; } } 

При трансфере NFT энергия переходит с персонажем автоматически, так как хранится в маппинге по tokenId.

Почему anti-cheat критичен?

Без защиты игроки могут манипулировать регенерацией через re-org или replay атак. Наше решение использует signed actions с nonce:

struct GameAction { uint256 characterId; uint256 actionType; uint256 energyCost; uint256 nonce; uint256 deadline; } mapping(address => uint256) public actionNonces; function executeAction( GameAction calldata action, bytes calldata serverSignature ) external { bytes32 digest = _hashTypedData(action); address signer = ECDSA.recover(digest, serverSignature); require(signer == GAME_SERVER_SIGNER, "Invalid signature"); require(action.nonce == actionNonces[msg.sender], "Invalid nonce"); actionNonces[msg.sender]++; require(block.timestamp <= action.deadline, "Expired"); spendEnergy(action.characterId, action.energyCost); _processAction(action); } 

Дополнительно вводим cooldown модификатор для частых действий:

mapping(uint256 => mapping(uint8 => uint256)) public lastActionTime; uint256 public constant BOSS_FIGHT_COOLDOWN = 4 hours; modifier withCooldown(uint256 charId, uint8 actionType, uint256 cooldown) { require( block.timestamp >= lastActionTime[charId][actionType] + cooldown, "Action on cooldown" ); _; lastActionTime[charId][actionType] = block.timestamp; } function fightBoss(uint256 charId) external withCooldown(charId, ACTION_BOSS, BOSS_FIGHT_COOLDOWN) { spendEnergy(charId, BOSS_FIGHT_ENERGY_COST); // ... } 

Какие риски возникают при использовании ERC-20 энергии?

Более сложная модель: отдельный ERC-20 токен как энергия, которую можно купить/продать. Trade-off: игроки могут купить энергию на DEX → pay-to-win риск. Если это допустимо — ERC-20 энергия даёт экономическую ценность. Если нет — энергия должна быть non-transferable (не токен, а internal accounting).

Экономическая модель: sink и source

Энергетическая система работает как регулятор экономики. Важно балансировать sources и sinks. Рекомендуемые параметры:

Ориентиры по срокам и стоимости

Базовая система (lazy regen, spend, cooldowns): 2–3 недели. Полная система (tier-based regen, ERC-20 energy token, DEX интеграция, anti-cheat signed actions, dashboard аналитики): 5–7 недель. Стоимость рассчитывается индивидуально после анализа вашей механики.

Что входит в работу

• Аудит существующей механики
• Проектирование смарт-контрактов с учетом gas optimization
• Разработка и unit-тесты (Foundry с vm.warp)
• Развертывание и верификация контрактов
• Интеграция с игровым бэкендом (ethers.js, viem)
• Документация API и примеры использования
• Поддержка после релиза (1 месяц)

Мы гарантируем отсутствие реентерабельности и использование проверенных паттернов (OpenZeppelin). Наш опыт — 5+ лет в Web3, 30+ реализованных проектов. Свяжитесь с нами для консультации по вашей GameFi механике. Закажите разработку системы энергии под ключ.