Система фракций и банд на RP-сервере

MAATRIX GAMES

Голая ESX или QBCore из коробки даёт тебе одну работу "police" и общий гардероб — и всё, дальше крутись сам. Как только на сервере набирается больше 20-30 игроков, без нормальной иерархии во фракциях и понятной системы банд начинается бардак: рядовой патрульный увольняет шефа, гриферы называют себя "Ballas" и стреляют друг в друга без причины, а гражданские просто не видят смысла оставаться гражданскими. Разберём, как выстроить организованные фракции и банды так, чтобы это работало на атмосферу, а не разваливало её.

Фракции vs банды: в чём разница на уровне сервера

Технически и полиция, и банда в ESX/QBCore — это job (работа) в базе данных. Разница только в логике, которую ты на неё навешиваешь:

• Фракции (police, ambulance, mechanic) — легальные организации с чёткой иерархией, доступом к служебному транспорту/оружию и часто зарплатой из общественного счёта (society account).
• Банды — обычно тоже job, но без "duty"-статуса от государства: нет патрулей по вызову 911, зато есть территория, конкурирующие интересы и часто доступ к нелегальным точкам (наркотики, оружейные закладки, угон тачек).

В QBCore разделение делается через поле type в qb-core/shared/jobs.lua (type = 'leo' для правоохранителей) — это влияет на то, видит ли фракция диспетчер и служебные блипы. В ESX (legacy) такого встроенного флага нет, вместо этого обычно смотрят на сам job.name в скриптах диспетчера (esx_policejob, cd_dispatch и т.д.) — если добавляешь новую фракцию, не забудь прописать её вручную в конфиге диспетчерского ресурса, иначе вызовы просто не будут доходить.

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

Полиция и EMS: qb-management и esx_society на практике

QBCore: qb-management

Ресурс qb-management — это стандартный "кабинет" для boss-меню фракции: наём/увольнение, повышение рангов, склад формы, общий счёт. Подключается как зависимость к qb-policejob и qb-ambulancejob.

Минимальная настройка в qb-management/config.lua:

Config.Jobs = {
    ['police'] = {
        label = 'Полиция',
        grades = {
            [0] = 'Стажёр',
            [1] = 'Патрульный',
            [2] = 'Сержант',
            [3] = 'Лейтенант',
            [4] = 'Начальник'
        }
    },
    ['ambulance'] = {
        label = 'EMS',
        grades = {
            [0] = 'Стажёр',
            [1] = 'Парамедик',
            [2] = 'Врач',
            [3] = 'Глав. врач'
        }
    }
}

Сами ранги (grades) job'а физически хранятся не тут, а в qb-core/shared/jobs.lua — qb-management только читает их для меню. Пример структуры job'а с грейдами и правом на boss-меню:

['police'] = {
    label = 'Полиция',
    type = 'leo',
    defaultDuty = true,
    offDutyPay = false,
    grades = {
        ['0'] = { name = 'Стажёр', payment = 50 },
        ['1'] = { name = 'Патрульный', payment = 75 },
        ['2'] = { name = 'Сержант', payment = 100 },
        ['3'] = { name = 'Лейтенант', payment = 125 },
        ['4'] = { name = 'Начальник', payment = 150, isboss = true },
    },
},

Флаг isboss = true на грейде — это то, что открывает boss-меню именно этому рангу (наём, увольнение, статистика зарплат). Без него даже лейтенант не сможет управлять составом.

ESX: esx_society + esx_addonaccount

В ESX legacy иерархия хранится не в конфиге ресурса, а в таблицах базы MySQL jobs и job_grades. Добавить новый ранг — это SQL-запрос, а не редактирование Lua:

INSERT INTO job_grades (job_name, grade, name, label, salary, skin_male, skin_female)
VALUES ('police', 5, 'chief', 'Начальник полиции', 150, '{}', '{}');

Общий счёт фракции создаётся через esx_addonaccount — при старте esx_society регистрирует society-аккаунт для каждой фракции, и зарплата/штрафы списываются оттуда, а не из личного кошелька игрока. Если у тебя не работает подключение к базе на этом этапе — почти всегда дело в кривом server.cfg или правах пользователя MySQL, смотри проблему с подключением к базе MySQL.

Boss-меню в ESX даёт esx_society при выставлении grade_isboss = 1 для конкретного ранга — по той же логике, что и isboss в QBCore, просто хранится в БД, а не в Lua-таблице.

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

Частая ошибка новых серверов — дать боссовский доступ сразу трём-четырём рангам "чтобы было удобнее". На деле почти любая иерархия фракции укладывается в 4-5 уровней:

Важный нюанс: isboss/grade_isboss — это бинарный флаг, тонкой настройки "может нанимать, но не увольнять" из коробки нет ни в QBCore, ни в ESX. Если нужна такая гранулярность — придётся дописывать проверку в экспортах boss-меню самому или ставить форк с ACL (например, qb-management форки с permission-таблицей встречаются в сообществе, но версии нестабильны и часто отстают от апдейтов ядра — прежде чем тащить такой ресурс на прод, тестируй на дев-копии сервера).

Не путай игровые ранги фракций с серверными ACE-правами txAdmin/FXServer (add_ace, add_principal в server.cfg) — это два независимых слоя. ACE решает, кто из реальных людей может ребутнуть сервер и открыть консоль, а грейды job'а — это чисто ролплейная иерархия внутри игры, которую видят все на сервере.

Территория для банд: зоны, влияние, конфликты

У банд, в отличие от фракций, обычно нет диспетчера и служебных тачек — зато нужна территория. Стандартный подход: полигональные зоны через ox_lib (lib.zones) или отдельный PolyZone, привязанные к конкретной банде.

Базовая логика territory-скрипта:

-- Пример зоны через ox_lib
local zone = lib.zones.poly({
    points = {
        vec3(120.5, -1290.3, 29.2),
        vec3(180.2, -1310.8, 29.2),
        vec3(210.0, -1260.5, 29.2),
    },
    thickness = 10,
    onEnter = function()
        local gang = exports['gang-core']:GetControllingGang('grove')
        lib.notify({ description = ('Территория: %s'):format(gang) })
    end
})

Готовых "коробочных" turf-war систем с проверенным онлайном мало — большинство серверов либо пишут захват территории под себя (таймер удержания зоны + счётчик игроков банды внутри), либо адаптируют открытые скрипты с GitHub, качество которых сильно разнится. Не верь заявленным в описании ресурса цифрам онлайна и FPS-нагрузки без проверки на своём сервере — зависит от количества зон, тикрейта и железа хоста.

Что стабильно работает как база для территорий:

• Привязка вражды между бандами через таблицу job_name -> enemy_job_name в конфиге, а не хардкод в коде — проще балансировать.
• Кулдаун на повторный захват одной и той же зоны (иначе зона будет пинг-понгом переходить туда-сюда каждую минуту).
• Лог захватов в отдельную таблицу БД или в Discord-вебхук — админам нужно видеть историю, а не гадать, кто и когда захватил точку.

Для кастомных карт и MLO под штабы фракций и точки банд — отдельный разбор в статье про карты и MLO для FiveM-сервера.

Кастомные скины и аутфиты фракций

Единая форма — это половина ощущения "настоящей" фракции. В QBCore чаще всего используют illenium-appearance или fivem-appearance вместе с qb-clothing/qb-shops, где аутфиты фракции сохраняются как пресеты, привязанные к job + grade:

-- Пример пресета в qb-clothing (server-side outfit)
exports['qb-clothing']:SetPlayerOutfit(source, {
    label = 'Форма патрульного',
    job = 'police',
    grade = 1,
    outfit = clothingData
})

В ESX аналогичную роль играет esx_skin (сохранение внешности по умолчанию для job) или illenium-appearance в связке с кастомным экспортом на смену одежды при заходе на службу (onDuty событие). Общий принцип: скин не должен намертво прописываться в код — храни пресеты в БД (таблица вроде player_outfits с полем job), чтобы дизайнер/админ мог поменять форму без правки Lua и рестарта ресурса.

Для банд форма обычно проще — 2-3 варианта "уличной" одежды без строгого дресс-кода, но с общими цветовыми акцентами (бандана, цвет обуви/кепки) — это дешевле для доната текстур и не грузит клиента лишними custom-моделями. Если ставишь кастомные пешеходные модели под фракции/банды — учитывай нагрузку на клиентов с слабым железом, ванильные педы + перекраска обычно надёжнее, чем десятки уникальных .ydd моделей.

Баланс: гражданские против организованных игроков

Главная причина, почему RP-серверы скатываются в "все играют за копов и бандитов" — организованные роли банально выгоднее и веселее гражданской жизни. Несколько рабочих рычагов баланса:

1. Кап на количество слотов job'а. В QBCore ограничение вешается через Config.MaxPoliceCount в диспетчерском ресурсе или через -1 в grades (без хардкода — обычно кастомный exports-счётчик). Держи полицию/EMS в районе 10-15% от пикового онлайна, банды — суммарно не больше 2-3 составов гражданской экономики, иначе улицы будут пустовать без "мирных" NPC-игроков.
2. Whitelist на топовые ранги фракций, а не на саму фракцию целиком — так новичок может попробовать роль патрульного без долгого отбора, а вот "начальника" уже даёт админ вручную после отыгровки.
3. Экономика для гражданских не хуже, чем у госслужб. Если водитель такси или механик зарабатывает вдвое меньше рядового патрульного за тот же час — все побегут в полицию. Свои конфиги зарплат job_grades/shared/jobs.lua держи в одной таблице для сверки, не разносите правки по десяткам файлов.
4. Банда без легального прикрытия должна быть рискованной, а не просто "фармом денег без последствий" — трекинг полицией нелегальных точек, конфискация при аресте, разброс дропа — иначе гражданская экономика проигрывает бандитской в лоб.

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

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