Розробка PvP-ігор на блокчейні: смарт-контракти та чесність

PvP-ігри на блокчейні: чому розходяться баланси матчів

У PvP-грі блокчейн відповідає лише за зберігання стану та нарахування нагород, а сам бій обчислюється на ігровому сервері.

Між цими двома світами немає єдиного джерела правди: клієнт показує один результат, сервер фіксує другий, а смарт-контракт для pvp виконує третій — той, до якого дійшла транзакція з потрібною затримкою.

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

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

Окремий біль — спірний раунд арени. Ні в гравця, ні в оператора немає спільного доказу: журнали сервера лежать в одному місці, транзакція в іншому, і відновити картину бою постфактум майже неможливо.

Розгляд одного звернення розтягується на дні, а підтримка перетворюється на ручний аудит логів замість роботи з продуктом.

Закривається це не «переписуванням гри на блокчейн», а контрактом на фіксацію результату: детермінованим розрахунком нагород, підписами обох сторін після завершення матчу та явними правилами відкату для спірних раундів. Розбираємо, як це влаштовано.

Що дає розрахунок матчів у смарт-контракті

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

Нагороди залишаються в контракті, а не на гаманці адміністратора, тому час виплати нагород вимірюється блоками, а не строком, коли в команди дійдуть руки до ручної звірки.

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

Спір розбирається за правилом, зафіксованим до старту, а не за листуванням у підтримці, тому частка оспорених раундів падає: обидві сторони заздалегідь бачать, що результат перевіряється, а підміна не проходить.

Мережу підбираємо під профіль гри: для частих коротких раундів беремо Polygon, де підтвердження вкладається в секунди, а розрахунок раунду не впирається в чергу.

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

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

Ефект рахуємо в цифрах: строк від нарахування до зарахування, частка раундів, що дійшли до спору, і частка виплат, що пройшли без ручного втручання.

Порівняння архітектур: серверний розрахунок, гібрид, повністю мережевий

Розрахунок матчу можна тримати на ігровому сервері, у смарт-контракті або розділити між ними. Цей вибір визначає пропускну здатність арени, відзивчивість бою та те, що гравець зможе довести після спірного епізоду.

Архітектура PvP режиму рідко буває вибором «або-або»: темп бою та вимоги до доказовості тягнуть у різні боки. Нижче — три робочі варіанти й те, на чому кожен починає впиратися.

На практиці межа проходить за частотою змін стану: що частіше змінюється бій, то менше сенсу підтверджувати кожен крок у мережі.

Гібридний варіант дає доказовий результат там, де він важливий, і не платить за це затримкою на кожному влучанні — тому під змагальні арени ми зазвичай закладаємо саме його.

Етапи розробки: від моделі економіки до передачі управління

Порядок робіт у PvP-грі на блокчейні відрізняється від звичайного проєкту: економіку матчу не можна доналаштувати після запуску — правила розрахунку нагород і рейтингу зашиті в контракти й видимі гравцям.

Тому ми йдемо від механік до коду, а не навпаки: кожен наступний етап спирається на рішення, узгоджені на попередньому.

1. Розбір механік матчу. Фіксуємо, що вважається результатом: результат бою, рахунок, серія, достроковий вихід. Звідси — список подій, які контракт зобов’язаний прийняти від ігрового сервера, і перелік того, що він має відхилити.

2. Проєктування економіки матчів. Рахуємо потоки цінності всередині матчу та між ними: ставка, комісія арени, виплата переможцю, повернення при скасуванні. Перевіряємо, що за будь-якого сценарію баланс сходиться і контракт не йде в мінус.

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

4. Аудит контрактів. Перевіряємо повторне пред’явлення результату, порядок викликів, округлення під час поділу нагород, поведінку при скасуванні. Знайдене закриваємо до запуску, а не після першого інциденту.

5. Навантажувальна перевірка арени. Ганяємо масове одночасне завершення матчів і дивимося, де стає черга транзакцій і як це відображається на часі зарахування нагороди.

6. Передача управління контрактами. Переводимо володіння замовнику: доступи, ключі, регламент оновлення та план дій при збої — з прогоном на тестовій мережі.

Що передаємо на руки: контракти, схеми та регламенти

Здача не закінчується робочим прототипом: у команди замовника залишається повний комплект артефактів, за якими PvP гру на блокчейні можна розвивати й обслуговувати без нас.

Кожен пункт перевіряємо — за ним можна зібрати проєкт, повторити розрахунок раунду та розібрати спірний результат.

• Вихідники контрактів із коментарями та розгорнутим тестовим оточенням — збірка й перевірки відтворюються однією командою.
• Схема потоків нагород: від результату раунду до зарахування — де фіксується підсумок і що відбувається при розходженні даних.
• Політики доступу до управління: хто змінює параметри матчу, скільки підтверджень потрібно, що заборонено змінювати після запуску.
• Документація з розрахунку матчів: формули рейтингу, розподіл нагород, обробка нічиїх і дострокових виходів гравця.
• Регламент розбору спірних раундів: строки, хто ухвалює рішення, які записи слугують доказом, порядок оскарження.
• Схема журналу подій: за кожним записом видно, який раунд і за яким правилом завершено, заднім числом нічого не переписується.
• Інструкція з оновлення: випуск нової версії, перенесення стану, відкат на попередню при збої.

Такий комплект знімає головний ризик — залежність від підрядника. Передача йде з розбором: інженери замовника проходять по кожному артефакту й самі повторюють розрахунок спірного раунду на тестових даних.

Кейс: арена 1 на 1 з виплатою призів через контракт

Проєкт — Duel Arena: дуелі один на один зі ставкою, де переможець забирає банк. Розрахунок нагород жив поза грою: оператори звіряли журнали матчів, вручну підтверджували результат і надсилали виплати. На потоці це давало затримки й простір для оспорювання.

Що було до

Близько 6% раундів закінчувалися спором: гравець заявляв, що результат підмінено або приз не надійшов. Виплата займала від кількох годин до двох діб, а в пікові вечори в черзі на ручну обробку висіло до 400 заявок. Підтримка розбирала кожну за журналами, і кінця цієї черги не було видно.

Що змінили

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

Призовий фонд блокується на вході в дуель і розподіляється тим самим викликом, що фіксує результат: окремого кроку «оплатити» більше немає, як і можливості правити підсумок вручну.

Що стало після

• Виплата — у межах хвилини замість годин і діб; черга ручної обробки зникла.
• Частка спірних раундів — 0,3% проти 6%; решта розбираються за незмінним журналом.
• Пікове навантаження — розрахунок іде паралельно по всіх дуелях, оператор на зміні не потрібен.

Команда проєкту отримала не лише швидкість, а й зняту із себе роль арбітра: правила дуелі описані в контракті й однакові для всіх.

Що робити, якщо проєкт уже запущено без блокчейну?

Перезапускати гру й переносити її на нову архітектуру не потрібно. Розрахунковий шар підключається збоку: поточний сервер залишається джерелом істини з механіки бою, а на ланцюг іде володіння предметами та виплати за підсумками матчів. Це швидше за повний переїзд і не ламає те, що вже працює у гравців.

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

Другий етап — перенесення інвентаря гравців. Знімається знімок стану на узгоджену дату, предмети пакетно випускаються у власність, а таблиця відповідності пов’язує старі ідентифікатори з новими.

Інвентар залишається всередині гри, але перестає залежати від одного сервера: предмет можна перевірити й передати.

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

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

Технічні сумніви: затримки, випадковість, відкат раундів

Замовники PvP-ігор перевіряють не картинку, а поведінку раунду під навантаженням: як швидко закривається ставка, чи можна передбачити жеребкування, що відбувається з матчем при збої та як змінювати правила, коли гра вже запущена і в ній є живі ставки. Нижче — чотири сумніви, які найчастіше спливають до старту.

Як довести, що жеребкування чесне?

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

Що відбувається з матчем при збої?

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

Чи можна змінювати правила після запуску?

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

Обговоримо задачу: розберемо вашу модель матчів і ризики

Щоб обговорити задачу PvP без переказу презентації, корисно почати з ваших матеріалів — за ними розбір механік матчу йде предметно, а не за здогадками. Надішліть те, що вже є, навіть у чернетковому вигляді:

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

Далі — технічне інтерв’ю з командою: розбираємо, де учасник може вплинути на результат, що станеться при обриві зв’язку або затримці запису результату, як перевіряється чесність роздачі.

Повертаємося з оцінкою та планом робіт: порядок етапів, що перевіряємо першим, які механізми переписуємо, а які залишаємо, і де залишаються ризики.