ESX и QBCore: сравнение фреймворков

MAATRIX GAMES

Если ты уже поднял голый FiveM-сервер и открыл витрину github в поисках готового RP-каркаса, первое, во что упрёшься — выбор между ESX и QBCore. Оба фреймворка решают одну задачу: дают тебе инвентарь, работы, банковскую систему, фракции и десятки готовых скриптов поверх них, чтобы не писать всё с нуля на чистом Lua. Разберём, чем они реально отличаются и как не пожалеть о выборе через месяц, когда сервер уже набрал игроков.

Что вообще решает фреймворк

FiveM сам по себе — это просто движок, который гоняет твои ресурсы (скрипты) и синхронизирует состояние между клиентами. Никакой встроенной экономики, инвентаря или системы работ в нём нет — это ты пишешь сам или берёшь готовое. Именно эту нишу и закрывают ESX и QBCore: базовый core-ресурс с API, вокруг которого держится вся экосистема community-скриптов.

Практически это значит следующее: когда ты видишь на GitHub скрипт вроде «продвинутый гараж» или «система наркоторговли», он почти всегда написан под конкретный фреймворк и дёргает его функции — ESX.GetPlayerFromId() в одном случае, QBCore.Functions.GetPlayer() в другом. Peчь не про два разных движка FiveM, а про два разных стандарта того, как устроены данные игрока, инвентарь и экономика внутри одного и того же движка.

Если ты ещё не поднимал базовый сервер — сначала пройди установку FiveM-сервера: без рабочего server.cfg, лицензии Cfx.re и понимания структуры resources ни один фреймворк не встанет по-человечески.

ESX: ветеран с готовым решением почти на любой случай

ESX Legacy (актуальный форк, живой на конец 2026 года) — самый старый из широко используемых RP-фреймворков для FiveM, его корни тянутся ещё к эпохе GTA:MP-сообществ. За годы вокруг него скопилась гигантская библиотека готовых ресурсов: от банальных гаражей и заправок до сложных систем наркокартелей и полицейских участков.

Архитектурно ESX построен вокруг классической MySQL-базы через mysql-async или oxmysql, объекта игрока xPlayer с набором методов и es_extended как ядра, к которому подключаются все остальные ресурсы через exports и события (AddEventHandler/TriggerEvent). Экономика в ESX — про классику жанра: у игрока есть money (нал), bank (счёт), опционально black_money под нелегальные доходы, работы задаются через Jobs-таблицу с грейдами и зарплатой.

Плюс ESX — низкий порог входа именно для новичка-разработчика, если он гуглит проблему: комьюнити огромное, форумы, Discord-серверы и тьюториалы по любой типовой задаче есть в избытке, потому что фреймворк существует дольше и через него прошло больше людей. Минус — обратная сторона возраста: часть кода в старых ресурсах написана ещё под легаси-паттерны, где-то остались синхронные MySQL-запросы, которые на нагруженном сервере ощутимо тормозят тикрейт при пиковой нагрузке.

QBCore: моложе, но переписан с оглядкой на современный FiveM

QBCore появился позже, как ответ на накопившиеся архитектурные проблемы ESX, и с самого начала строился вокруг более структурированного подхода: единый QBCore.Functions, встроенная система разрешений на основе групп (user, admin, god и кастомные), нормализованные таблицы под MySQL через oxmysql с асинхронными запросами по умолчанию.

Экономика в QBCore ближе к «одна карта — весь баланс» через cash/bank, но ключевое отличие в деталях реализации: инвентарь и предметы хранятся более гибко, система работ (qb-core/shared/jobs.lua) и гангов разделена явно, что упрощает кастомизацию под уникальную концепцию сервера — например, отдельную ветку прогрессии для банд без переписывания ядра.

QBCore активно развивается: обновления ядра, миграция на новые практики (переход многих community-ресурсов на ox_lib и ox_inventory как общий стандарт независимо от фреймворка), более чистая структура файлов с явным разделением client/server/shared. Разработчики, которые пишут новый код с нуля, чаще отзываются о QBCore как о более современной и предсказуемой базе — меньше легаси-костылей, с которыми приходится разбираться.

Обратная сторона: комьюнити и библиотека готовых ресурсов у QBCore меньше, чем у ESX, хотя разрыв заметно сократился за последние пару лет — сейчас для большинства типовых задач (гаражи, работы, банк, инвентарь) готовые скрипты под QBCore найти не проблема.

Таблица сравнения

Точных цифр по FPS-приросту или разнице в тикрейте между фреймворками называть не будем — это сильно зависит от конкретного набора ресурсов, железа сервера и количества онлайн-игроков, а не от самого ядра. Любые «QBCore на 20% быстрее ESX» в интернете — маркетинг, а не измерение.

Экономика и работы: в чём практическая разница

Для игрока разница между ESX и QBCore почти незаметна — и там, и там есть нал, счёт, работы с грейдами и зарплатой, фракции (полиция, EMS, банды). А вот для тебя как админа/разработчика сервера разница ощущается на этапе кастомизации:

В ESX добавление новой работы — это обычно правка Jobs-таблицы в базе плюс серверный скрипт с ESX.RegisterUsableItem или экспортами под конкретную механику. Готовых шаблонов работ под ESX в сети масса, найти пример под любую идею — вопрос пяти минут гугления.

В QBCore работы описываются в qb-core/shared/jobs.lua с более явной структурой (grades, bankAuth, offDutyPay), что удобнее при большом количестве кастомных фракций, но требует чуть более внимательного чтения документации, если ты новичок.

Пример объявления работы в стиле QBCore для ориентира (упрощённо):

['mechanic'] = {
    label = 'Механик',
    defaultDuty = true,
    grades = {
        ['0'] = { name = 'Стажёр', payment = 50 },
        ['1'] = { name = 'Механик', payment = 75 },
        ['2'] = { name = 'Босс', payment = 100, isboss = true },
    },
},

Обрати внимание: это упрощённый учебный пример структуры, а не готовый рабочий файл — перед вставкой в свой jobs.lua сверяйся с актуальной документацией и уже установленными у тебя ресурсами, синтаксис между версиями core может отличаться.

Совместимость ресурсов: главная грабля при смешивании

Вот тут — самый частый источник боли у новичков. Скрипт, написанный под ESX, по умолчанию не заработает на QBCore-сервере и наоборот: разные объекты игрока, разные названия событий, разная структура инвентаря. Строчка local xPlayer = ESX.GetPlayerFromId(source) просто упадёт с ошибкой на QBCore-ядре, потому что там нет функции ESX.GetPlayerFromId.

Есть переходные и совместимые слои (например, часть ресурсов пишется с поддержкой обоих фреймворков через условные обёртки, определяющие, какое ядро сейчас запущено), но рассчитывать на это заранее не стоит — большинство авторов на GitHub прямо указывают в описании репозитория, под какой фреймворк писали ресурс, и адаптация под другой требует правок кода, а не просто копирования файла в resources/.

Отдельно стоит учитывать инвентарь: и ESX, и QBCore-сообщества сейчас всё активнее переходят на общие сторонние инвентари вроде ox_inventory, которые работают поверх обоих фреймворков — это немного снижает остроту проблемы совместимости именно для инвентарных предметов, но не для остальной логики core.

Как выбрать: практический совет

Если цель — быстро запустить типовой RP-сервер на готовых ресурсах, оба варианта рабочие, и зацикливаться на «какой фреймворк лучше в вакууме» смысла немного. Решающий фактор в 2026 году — не абстрактные плюсы архитектуры, а то, под что написаны конкретные скрипты и карты, которые ты уже присмотрел или планируешь купить/скачать.

Практический алгоритм:

1. Составь список ресурсов, которые точно хочешь на сервере (гараж, банда-система, конкретная карта MLO, экономика наркоторговли и т.д.).
2. Проверь у каждого в описании репозитория или на странице продажи, под какой фреймворк он написан — обычно указано прямо в README или в первой строке описания на форумах вроде Cfx.re или Tebex-магазинов авторов.
3. Если большинство нужных ресурсов под ESX — бери ESX, не пытайся портировать всё на QBCore ради архитектурной чистоты. И наоборот.
4. Если начинаешь с нуля и конкретных ресурсов ещё не выбрал — присмотрись к QBCore, если планируешь много писать сам и ценишь более предсказуемую структуру кода; бери ESX, если хочешь максимум готовых решений и меньше времени на самостоятельную разработку.

Не пытайся угодить сразу обоим лагерям, смешивая ESX-ресурсы поверх QBCore-ядра «на живую» — почти всегда это заканчивается часами дебага несовместимых ивентов вместо запуска сервера. Один core, полная экосистема вокруг него — рабочая стратегия и для новичка, и для опытного админа.

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