Баланс игровой валюты вырос сам: как проверить журнал начислений и трат

В начале теста у персонажа 100 монет. Он получил 20 за задание и потратил 30. Ожидаемый остаток — 90, но интерфейс показывает 110. Покупки за реальные деньги здесь ни при чём: ошибка может находиться в повторной выдаче награды, клиентском пересчёте или несогласованной загрузке сохранения. Пока нет журнала событий, эти причины выглядят одинаково.

Проверяем не красивое число, а его происхождение

Для каждой операции нужны устойчивый ID, тип, величина, игрок, основание и результат обработки. Начальный остаток с привязанным периодом позволяет воспроизвести дальнейшее движение. Итоговый баланс должен объясняться принятыми событиями, а не существовать как отдельная цифра, которую разные экраны редактируют по своему усмотрению.

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

Клиент просит действие, сервер проверяет право

В сетевой игре запрос «прибавить 500» не должен быть достаточным основанием изменить экономику. Клиент сообщает намерение или подтверждаемые данные, а доверенный код проверяет условия задания, стоимость и доступность. Локальный флаг «награда заслужена» не защищён от изменения пользователем.

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

Расход нельзя отделять от проверки остатка

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

Корректировка после ошибки оформляется отдельным объяснимым событием. Ручная замена баланса на «как должно быть» без основания стирает информацию, нужную для расследования. Доступ к корректировкам ограничивают, а действие сотрудника журналируют.

Граница периода тоже может удвоить событие

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

Что даст встроенный аудит

Введите начальный и наблюдаемый конечный остатки, затем учебные события в порядке применения. Тип grant увеличивает баланс, consume уменьшает. Инструмент показывает арифметический ход, отрицательные промежуточные значения и повторённые ID. При одинаковом ID с разными параметрами он отмечает конфликт отдельно.

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

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