Cursor для PUBG: как создать трекер статистики через официальный API

Cursor можно использовать для разработки внешних сервисов PUBG: трекеров статистики, турнирных таблиц, Discord-ботов и инструментов послематчевого анализа. Редактор помогает изучать код проекта, создавать серверные запросы, обрабатывать данные PUBG API, писать тесты и исправлять ошибки. Вмешательство в игровой клиент, автоматизация стрельбы и получение скрытых данных к разрешённой разработке не относятся.

Как связаны Cursor и PUBG

Cursor — редактор кода с ИИ-агентом, который способен анализировать файлы проекта, изменять несколько связанных компонентов, выполнять команды в терминале и проверять результаты. Режим Plan Mode позволяет сначала изучить кодовую базу и составить план реализации, а затем перейти к изменениям. Постоянные требования к проекту можно сохранить в Project Rules или файле AGENTS.md.

PUBG предоставляет официальный интерфейс для получения игровых данных. Через PUBG Developer Portal разработчик регистрирует приложение, получает API-ключ и создаёт собственный сервис на основе статистики игроков, матчей, сезонов, рейтингов и телеметрии. KRAFTON отдельно публикует примеры сторонних статистических сайтов, трекеров и Discord-ботов, работающих с официальными данными.

Общая тема Cursor и PUBG связана не с управлением персонажем во время матча, а с разработкой внешнего приложения:

Cursor помогает написать и проверить код, а PUBG API предоставляет данные для анализа.

Что можно разработать для PUBG

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

На основе той же архитектуры можно создать несколько видов сервисов.

Для небольшой версии достаточно трёх функций:

1. поиск игрока по нику;
2. вывод последних матчей;
3. карточка матча с местом, убийствами и нанесённым уроном.

После запуска базового трекера можно подключить сезонную статистику, сравнение участников и обработку телеметрии.

Какие данные предоставляет PUBG API

Официальная документация PUBG содержит методы для работы с игроками, сезонной и общей статистикой, оружейным мастерством, кланами, матчами, рейтингами, турнирами и телеметрией. Ответы передаются в формате JSON API.

Разные показатели нельзя без проверки объединять в одну формулу. Например, обычная сезонная статистика и Ranked Stats поступают через отдельные методы API. Режимы Solo, Duo и Squad также следует разделять по вариантам FPP и TPP.

Что содержится в телеметрии PUBG

Карточка матча показывает итог, а телеметрия помогает восстановить последовательность событий. Для её получения необходимо сначала запросить объект матча, найти связанный asset и извлечь ссылку на файл телеметрии. Файл содержит массив событий, структура которых зависит от типа записи. API-ключ для загрузки файла телеметрии не требуется.

При обработке доступны сведения о:

• перемещениях участников;
• нанесённом и полученном уроне;
• нокаутах и убийствах;
• использовании предметов;
• подборе и смене оружия;
• перемещении на транспорте;
• положении игроков на карте;
• времени отдельных событий;
• итоговом выбывании участника.

Не каждое событие требуется сохранять. Для отчёта по матчу достаточно выделить нужные типы записей, привести время к единому формату и связать участников по accountId.

Например, тепловой карте понадобятся координаты и тип события, а сводке по урону — источник атаки, цель, оружие, величина урона и отметка времени.

Как создать трекер PUBG с помощью Cursor

1. Определить минимальную версию

Разработка начинается не с генерации кода, а с описания результата.

Для первого релиза можно зафиксировать следующий сценарий:

1. посетитель вводит ник;
2. сервер находит игрока через PUBG API;
3. приложение получает список матчей;
4. сервер загружает данные выбранного матча;
5. интерфейс показывает результат игрока.

Минимальный набор полей:

• ник;
• платформа;
• режим;
• карта;
• дата матча;
• занятое место;
• количество убийств;
• нанесённый урон;
• продолжительность выживания.

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

2. Составить план в Cursor

В Plan Mode можно поручить агенту изучить структуру репозитория и подготовить порядок изменений без немедленного редактирования файлов. Документация Cursor описывает этот режим как отдельный этап исследования кодовой базы и формирования проверяемого плана реализации.

Пример запроса:

Изучи проект Next.js и составь план добавления трекера PUBG.

Требования:
- поиск игрока по нику и платформе;
- запросы к PUBG API только на сервере;
- API-ключ хранится в переменной окружения;
- результаты поиска кэшируются;
- ошибки 404, 429 и 500 обрабатываются отдельно;
- интерфейс показывает последние матчи;
- существующие страницы не изменяются без необходимости.

Сначала подготовь план. Код пока не редактируй.

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

3. Зафиксировать правила проекта

Правила уменьшают вероятность несовместимых изменений в следующих сессиях. Cursor поддерживает Project Rules, User Rules, Team Rules и AGENTS.md.

Пример файла AGENTS.md:

# Правила проекта PUBG Stats

- Использовать TypeScript в строгом режиме.
- Выполнять запросы к PUBG API только на сервере.
- Не передавать PUBG_API_KEY в браузер.
- Разделять внешние типы API и внутренние модели.
- Обрабатывать HTTP 429 с учётом X-RateLimit-Reset.
- Добавлять кэш для поиска игроков и сезонной статистики.
- Не изменять формулы показателей без отдельного комментария.
- Создавать тесты для преобразования данных матча.
- Не добавлять функции, взаимодействующие с клиентом PUBG.
- Не создавать макросы, оверлеи со скрытыми данными и средства автоматизации игры.

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

4. Создать серверный клиент PUBG API

API-ключ нельзя помещать в клиентский JavaScript, мобильное приложение или публичный репозиторий. Официальная документация требует выполнять запросы через защищённое серверное приложение и передавать ключ в заголовке Authorization: Bearer.

Запрос должен проходить по цепочке:

Браузер
  -> сервер приложения
  -> кэш
  -> PUBG API
  -> преобразование ответа
  -> браузер

Отдельный модуль API-клиента отвечает за:

• адрес метода;
• выбор платформы;
• заголовки запроса;
• тайм-аут;
• обработку сетевой ошибки;
• проверку HTTP-статуса;
• чтение лимитов;
• преобразование ответа;
• журналирование.

Пример запроса игрока на TypeScript:

const response = await fetch(
  `https://api.pubg.com/shards/${platform}/players?filter[playerNames]=${encodeURIComponent(playerName)}`,
  {
    headers: {
      Authorization: `Bearer ${process.env.PUBG_API_KEY}`,
      Accept: "application/vnd.api+json",
    },
  },
);

if (response.status === 429) {
  const resetAt = response.headers.get("X-RateLimit-Reset");
  throw new Error(`PUBG API rate limit exceeded. Reset: ${resetAt}`);
}

if (!response.ok) {
  throw new Error(`PUBG API returned ${response.status}`);
}

const data = await response.json();

Фрагмент показывает общий принцип. Перед публикацией необходимо проверить используемый сегмент платформы, структуру ответа и обработку отсутствующего игрока.

5. Разделить внешние и внутренние модели

Интерфейс не должен напрямую зависеть от всей структуры ответа PUBG API. Между внешними данными и страницей нужен слой преобразования.

Внутренняя модель матча может выглядеть так:

type MatchSummary = {
  id: string;
  map: string;
  mode: string;
  startedAt: string;
  durationSeconds: number;
  placement: number;
  kills: number;
  damage: number;
};

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

Подход также упрощает тестирование. Для проверки карточки матча не понадобится загружать полный JSON с участниками, командами и связанными объектами.

6. Добавить кэширование

По состоянию на июль 2026 года стандартный API-ключ PUBG имеет лимит 10 запросов в минуту. После превышения лимита сервер отвечает кодом HTTP 429. В ответах передаются заголовки с общим лимитом, оставшимся количеством запросов и временем сброса ограничения.

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

Рекомендуемая схема:

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

Методы получения матчей и телеметрии не входят в основной лимит API-ключа, однако бесконтрольная повторная загрузка создаёт лишнюю нагрузку на собственный сервер. PUBG рекомендует использовать кэширование и оптимизацию запросов.

7. Получить последние матчи

Ответ по игроку содержит идентификаторы связанных матчей. Затем каждый матч можно запросить через отдельный метод.

В документации указаны два ограничения:

• доступны данные за последние 14 дней;
• для одного игрока возвращается не более 32 идентификаторов матчей.

Поддерживаются групповые запросы статистики максимум для десяти игроков, что полезно при сравнении состава или создании клановой панели.

Сервису с длительной историей необходимо регулярно сохранять разрешённые данные в собственную базу. Получить старый матч через API после окончания периода хранения не получится.

8. Собрать интерфейс

На странице игрока полезно показать не максимум доступных показателей, а данные, которые быстро отвечают на основные вопросы:

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

Подходящая структура страницы:

1. ник и платформа;
2. краткая сезонная сводка;
3. список последних матчей;
4. фильтр по режиму;
5. карточка выбранного матча;
6. график динамики;
7. пояснение формул.

Метрики следует подписывать однозначно. Пользователь должен понимать, относится показатель к одному матчу, сезону, рейтинговому режиму или общей статистике.

9. Протестировать расчёты и ошибки

Генерация работающего интерфейса не подтверждает правильность статистики. Проверка требуется на уровне данных и формул.

Минимальный набор тестов:

• игрок не найден;
• неверно указана платформа;
• список матчей пуст;
• API вернул HTTP 429;
• в ответе отсутствует ожидаемое поле;
• матч содержит несколько участников с похожими именами;
• accountId сопоставлен с нужным участником;
• урон округляется одинаково;
• K/D не вызывает деление на ноль;
• режимы FPP и TPP не объединяются;
• телеметрия содержит неизвестный тип события;
• повторный запрос получает данные из кэша.

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

Рекомендуемая архитектура трекера

Для небольшого проекта подойдёт следующий стек:

Интерфейс

• Next.js или React;
• TypeScript;
• таблицы и графики;
• адаптивная вёрстка.

Серверная часть

• серверные маршруты Next.js, Node.js или Python;
• отдельный PUBG API Client;
• проверка входных параметров;
• обработка лимитов и сетевых ошибок.

Хранилище

• PostgreSQL для игроков, матчей и рассчитанной статистики;
• Redis для краткосрочного кэша;
• объектное хранилище для подготовленных файлов при необходимости.

Фоновые задачи

• обновление профилей;
• загрузка новых матчей;
• обработка телеметрии;
• пересчёт рейтингов;
• очистка временных данных.

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

Какие показатели стоит рассчитывать

Готовые данные API можно дополнить собственными метриками. Формулы необходимо раскрывать рядом с результатом.

Средний урон

Суммарный урон делится на количество учтённых матчей. Матчи без найденного участника или с неполными данными не следует включать без отдельной пометки.

Процент побед

Количество побед делится на общее число матчей и умножается на 100. Режимы Solo, Duo и Squad лучше считать отдельно.

Попадание в топ-10

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

K/D

Классический вариант — число убийств, разделённое на количество смертей. В матчах с победой игрок может не погибнуть, поэтому разработчику нужно явно описать, как обрабатываются подобные случаи.

Динамика формы

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

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

Когда потребуется платный тариф Cursor

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

Платный тариф ускоряет работу с кодовой базой, но не проверяет достоверность игровых формул автоматически. Архитектуру, безопасность ключей и соответствие правилам PUBG необходимо контролировать отдельно.

Что нельзя создавать для PUBG

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

Условия KRAFTON запрещают разработку и распространение несанкционированных программ, включая средства перехвата связи с сервером, ботов, скрипты, автоматическое управление, макросы и программы, которые читают или изменяют игровые данные через память клиента.

В апреле 2026 года античит-команда PUBG отдельно указала, что макросы мыши, скрипты подавления отдачи и устройства, создающие аномальный ввод, нарушают правила и могут привести к ограничению аккаунта.

Не следует разрабатывать:

• антиотдачу;
• автоматическое наведение;
• макросы стрельбы;
• ботов для управления персонажем;
• радары;
• чтение памяти процесса;
• изменение файлов клиента;
• перехват игровых пакетов;
• оверлеи со скрытыми позициями противников;
• средства обхода античита.

Безопасная граница проекта определяется источником и моментом получения данных. Официальный API и послематчевый анализ подходят для статистического сервиса. Вмешательство в запущенную игру или автоматизация действий создают риск нарушения правил.

Частые вопросы

Можно ли использовать Cursor непосредственно во время матча PUBG?

Cursor предназначен для разработки программного кода, а не для управления игрой. Статистическое приложение должно работать отдельно от клиента PUBG и не вмешиваться в игровой процесс.

Есть ли у PUBG официальный API?

Да. API-ключ выдаётся через PUBG Developer Portal. С его помощью можно получать доступные данные игроков, сезонов, матчей, рейтингов, кланов и телеметрии.

Нужно ли хранить API-ключ на сервере?

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

Сколько запросов разрешено выполнять?

Стандартный лимит составляет 10 запросов в минуту. Методы матчей и телеметрии не расходуют основной лимит, но поиск игроков и получение статистики расходуют.

Можно ли получить старые матчи?

Официальный API хранит доступные данные матчей 14 дней. В ответе по игроку возвращается максимум 32 последних идентификатора. Для долгосрочной истории данные нужно сохранять заранее.

Нарушает ли трекер статистики правила PUBG?

Использование официального API для внешнего статистического сервиса само по себе не относится к вмешательству в игру. Проект должен соблюдать условия PUBG Developer Portal, защищать API-ключ и не использовать функции, влияющие на игровой процесс.

Нужна ли база данных для первого прототипа?

Нет. Минимальную версию можно собрать с серверным API-клиентом и временным кэшем. База понадобится для длительной истории матчей, пользовательских профилей, собственных рейтингов и подготовленной телеметрии.

Вывод

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

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

Ключевые требования проекта — серверное хранение API-ключа, кэширование запросов, проверка формул и отсутствие взаимодействия с игровым клиентом. При соблюдении этих условий Cursor ускоряет разработку, а сервис остаётся инструментом анализа, а не способом получить преимущество в PUBG.