Экономика социальных игр: правила активов и проверяемые операции

Совместное испытание заканчивается, игрок запрашивает награду с двух устройств и получает её дважды. Другому игроку возвращают деньги за набор валюты после того, как монеты уже потрачены. Это вопросы проектирования экономики, а не только серверной разработки: продукт должен объяснять, что игрок заработал, чем владеет сейчас и какое исправление допустимо.

Это руководство для продуктовых дизайнеров и инженеров, создающих платформу социальных игр с виртуальными активами. Оно связывает модель поступления и расходования ресурсов с достоверными записями, прогрессом, покупками и социальными функциями. Расчётный пример условный и использует игровую валюту, которую нельзя обменять на деньги; он не описывает действующий продукт и не устанавливает его юридическую классификацию. Более широкий объём работ рассмотрен в разработке социальных игр.

Определите смысл каждого актива до назначения цен

Составьте описание правил для каждой валюты, предмета, системы очков и права на контент. Профиль хранит идентификационные сведения и описание игрока; очки опыта отражают прогресс; предмет инвентаря — владение; валюта позволяет выполнять определённые обмены. Одинаковые значки не делают эти сущности взаимозаменяемыми. Например, модель ресурсов 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 описывает обнаружение аннулированных покупок и возможные действия по восстановлению, но отрицательный баланс не является универсальным правилом для любой игры. Перед ограничениями проверьте фактический продукт, требования магазина и обязательства перед потребителем; дайте поддержке достаточно сведений для объяснения результата.

Оценивайте, помогает ли экономика развитию игрока

Сверенные суммы показывают, учтены ли единицы ресурсов. При проектировании экономики нужно оценить, есть ли у игроков осмысленный выбор и реалистичный путь освоения контента. Определите характерную цель прогресса, действия для получения нужных ресурсов, ожидаемые возможности для игры и доступные альтернативы. Храните очки опыта отдельно от расходуемых балансов, если продукт намеренно не допускает их обмен.

Отслеживайте балансы, скорость заработка и расходов по времени с момента регистрации, этапу прогресса и группам покупательского поведения. Отслеживайте распределение времени до открытия выбранного контента, неиспользованный инвентарь, игроков, остановившихся из-за нехватки ресурса, и ответственные источники или механизмы изъятия. Среднее по всей аудитории может скрывать и новичков без ресурсов, и давних игроков, которым нечего покупать.

Рост общей суммы монет сам по себе не означает инфляцию. Изучайте цены, покупательную способность, накопления и спрос на доступные способы расходования. Если игроки копят, потому что магазин не предлагает ничего полезного, обязательные расходы могут ухудшить опыт. Выясните, вызвано ли изменение наградами, ценами, доступностью контента или непреднамеренно повторяемым начислением. Проверяйте изменения по конкретному результату для игрока, с понятными ценами и условиями. Избегайте решений, намеренно создающих раздражение или скрывающих расходы за запутанными конвертациями.

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

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

Для подарков и торговли до запуска оцените массовое создание учётных записей ради выгоды, сговор, переводы за счёт покупок с последующим возвратом денег и ошибочных получателей. Сходящиеся суммы не исключают кражу или перераспределение не на ту учётную запись. Задайте лимиты переводов и подтверждения соразмерно механике, обеспечьте прослеживаемость вмешательства сотрудников. Храните записи модерации и права доступа отдельно от публичных профилей; социальная блокировка не должна незаметно удалять купленные активы без утверждённой политики.

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

Запускайте экономику, которую команда может объяснить

Начните с полного цикла: подтверждённое действие создаёт награду, игрок использует её, поддержка объясняет обе операции, а команда сверяет результат. Проверьте повторное получение с двух устройств, одновременные расходы, уведомление о покупке после потери соединения, возврат набора валюты после расходования, достижение предела накопления при начислении и завершение события во время запроса награды. Определите каждый ожидаемый результат до проверки.

Сохраняйте версии правил событий и цен, определите применимое серверное время и решите, какая версия действует для операции в процессе выполнения. Храните исторические определения, чтобы новые настройки незаметно не переписывали принятые результаты. Отделите остановку новых начислений от действий для разрешения уже принятых. Проверьте всплеск при завершении события, а не только постоянный трафик; планирование пиковых событий объясняет лимиты зависимостей и восстановление после накопления очереди.

Если несколько игр или брендов используют общие сервисы, явно задайте область учётных записей и ресурсов для записи, истории и доступа сотрудников. Проверка общего ядра и границ брендов помогает определить необходимую изоляцию; одинаковое название валюты не должно объединять несвязанные балансы. Используйте планирование запуска, чтобы связать открытые зависимости, режим работы команды эксплуатации и подтверждения приёмки с решением о выпуске.

Выбирайте серверную технологию по нужному поведению: начисления под контролем сервера, одновременные обмены, проверка покупок, восстанавливаемые исправления, экспорт истории и контролируемые изменения настроек. Если купленный сервис не предоставляет нужные сведения или полномочия, оцените это ограничение до перестройки всего продукта. Сравнение собственной и готовой платформы даёт метод оценки владения и эксплуатационных обязанностей; пример казино не является спецификацией виртуальной экономики.

Если продукт также предлагает ставки на деньги, определите их отдельно. Архитектура букмекерского кошелька и расчётов относится к принятым ставкам, денежным обязательствам и исправлениям. Не заменяйте эти записи балансом игровых монет или записью награды. Полезный первый выпуск имеет понятную игрокам модель активов и историю операций, которую команда может проверить.

• Учтённые единицы: для каждого ресурса и границы периода начальные балансы плюс создание минус уничтожение сходятся с конечными балансами; переводы и исправления классифицированы явно.
• Один результат операции: повторные и одновременные запросы не создают ещё одну награду; прерванные обмены и завершение покупки в магазине восстанавливаются без двойного начисления.
• Объяснимый прогресс: согласованные группы игроков проходят предусмотренный путь открытия контента; версии цен, наград и условий получения объясняют наблюдаемые различия.
• Управляемые изменения: сотрудники видят связанные покупки, начисления, расходы и исправления; права, средства приостановки событий и процедуры восстановления продемонстрированы в согласованной среде.