Економіка соціальних ігор: правила активів і перевірювані операції

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

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

Визначте зміст кожного активу до призначення цін

Складіть опис правил для кожної валюти, предмета, системи очок і права на контент. Профіль зберігає ідентифікаційні відомості й опис гравця; очки досвіду відображають прогрес; предмет інвентарю — володіння; валюта дає змогу виконувати визначені обміни. Однакові значки не роблять ці сутності взаємозамінними. Наприклад, модель ресурсів Unity Economy розрізняє валюти, предмети інвентарю, віртуальні покупки й покупки за гроші. Це розділення корисне й за іншого серверного стеку.

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

Ці рішення також визначають питання для профільної ринкової та юридичної оцінки. Наприклад, у Великій Британії (Англії, Шотландії та Уельсі) рекомендації Gambling Commission розглядають ігрові предмети, які можна обміняти на гроші чи інші цінності, як гроші або їхній еквівалент і вимагають ліцензії, якщо з ними надаються азартні ігри. Не визначайте статус гри за словом «соціальна» або відсутністю кнопки виведення грошей.

Окремо обліковуйте створення, знищення й перекази

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

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

Розгляньмо всі облікові записи замкненої економіки за один період. Початкові баланси в сумі становлять 1 000 монет. Завдання створюють 240; підтверджені покупки — 100; крафт вилучає 180; покупки косметики — 60. За відсутності інших операцій очікуваний підсумок становить 1 000 + 240 + 100 − 180 − 60 = 1 100 монет. Подарунок у 30 монет між включеними в розрахунок обліковими записами змінює їхні окремі баланси, але не цю суму. Обліковуйте обидві сторони як переказ, а не нарахування й вилучення.

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

Ухвалюйте рішення про нагороди й витрати на сервері

Клієнт може запитати «отримати нагороду за це завдання»; він не має вирішувати «додати стільки-то монет». Приклад серверного стану гри в Unity перевіряє завершений рівень за раніше розпочатим рівнем і перевіряє надісланий результат. Загальний принцип проєктування — перевіряти саме досягнення й забезпечувати дотримання його правил на сервері. Саме серверне виконання не запобігає всім видам обману.

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

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

Зробіть видачу купленого в магазині активу відновлюваною

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

Для Google Play рекомендації з безпеки платежів передбачають серверну перевірку покупки, збереження токенів покупок і перевірку повторів. У них зазначено: видавати актив лише в стані PURCHASED, а не PENDING, і підтверджувати обробку після видачі. Для витратних продуктів завершення виконується через позначення покупки використаною; ця операція магазину відрізняється від витрачання отриманих монет гравцем. Зробіть внутрішнє нарахування безпечним за повторення, а підтвердження обробки відновлюйте окремо, не нараховуючи актив заново за повтору підтвердження. Іншим магазинам потрібен власний перевірений життєвий цикл.

Повернення грошей і відкликані права на покупки потребують явної політики виправлень. Зберігайте початкове нарахування й додавайте пов'язану зміну балансу або права на актив; не стирайте історію покупки. Вирішіть, що робити з невикористаними активами, уже витраченою валютою та отриманими за неї предметами. Google описує виявлення анульованих покупок і можливі дії з відновлення, але від'ємний баланс не є універсальним правилом для будь-якої гри. Перед обмеженнями перевірте фактичний продукт, вимоги магазину й зобов'язання перед споживачем; дайте підтримці достатньо відомостей для пояснення результату.

Оцінюйте, чи допомагає економіка розвитку гравця

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

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

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

Підключайте соціальні функції без обходу правил економіки

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

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

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

Запускайте економіку, яку команда може пояснити

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

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

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

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

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

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