Left 4 Dead 2: лагает при большом онлайне

MAATRIX GAMES

Свежий кооп начинается ровно, а к третьей главе — как только на экране одновременно восемь выживших, орда обычных зомби и пара спешлов вроде Танка — движения персонажей начинают дёргаться, стрельба ощущается «мимо», а хост в чате пишет «у меня всё нормально, это у вас лагает». Разберём, что в Left 4 Dead 2 реально отвечает за плавность под нагрузкой, почему тут работает старая логика Source-движка, а не что-то новое, и что можно подкрутить на своём сервере, прежде чем менять тариф.

Тикрейт и серверный FPS в L4D2 — это не одно и то же

Left 4 Dead 2 работает на движке Source первого поколения (том же, что был в Counter-Strike: Source и Half-Life 2), и терминология здесь местами путает даже опытных админов. У сервера есть параметр -tickrate, который задаёт, сколько раз в секунду пересчитывается игровая логика — позиции игроков, попадания, поведение ИИ-режиссёра (Director), который спавнит орды и спешлов. По умолчанию для L4D2 это обычно 30, у части хостинг-образов можно поднять до 60 или даже 100, но нужно понимать: чем выше цифра, тем больше вычислений сервер обязан успевать за секунду.

Второй параметр — fps_max на сервере, который ограничивает, сколько кадров в секунду процесс вообще пытается просчитать. На выделенном сервере (srcds) есть смысл держать fps_max заметно выше тикрейта, чтобы движку было из чего «выбирать» — иначе даже небольшая просадка производительности сразу режет реальный тикрейт, а не только визуальный FPS, которого на dedicated-сервере без графики формально и нет.

Путаница чаще всего в том, что игроки судят о лагах по своему клиентскому FPS и пингу, а реальная причина — в том, что сервер физически не укладывается в бюджет времени на тик, когда одновременно считает: путь и поведение всех ботов и зомби, урон, физику разрушаемых объектов, спавны Director'а. Если тиков в секунду реально меньше, чем заявлено в конфиге — это ощущается как «телепорты» зомби, задержка хитрегов, рывки анимаций, даже если у всех игроков идеальный пинг.

Почему именно орды и Танк роняют плавность

Director в L4D2 — это система, которая динамически решает, когда и где заспавнить орду, спешл-заражённых и предметы, подстраиваясь под темп прохождения группы. Проблема с точки зрения нагрузки в том, что орда — это резкий всплеск: были условные 8 зомби, стало 30-40 одновременно активных сущностей с собственным ИИ, path-finding и хитбоксами. Сервер, который спокойно тянул тихий отрезок карты, может не успеть с расчётом именно в момент пика.

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

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

Смотрим реальные цифры через net_graph и rcon

Первым делом стоит отличить визуальные лаги от сетевых. В клиентской консоли (~) включаем:

net_graph 1

Смотрим на строку с интервалом обновления сервера и на loss/choke. Если во время спокойных отрезков карты всё стабильно, а именно во время орды var подскакивает и держится повышенным несколько секунд — это симптом просадки серверного тика, а не сетевой проблемы у конкретного игрока.

Со стороны сервера, если есть доступ по RCON или консоли srcds, полезная команда:

stats

Она покажет текущую загрузку CPU и реальный FPS/тикрейт сервера за последний период. Сравните с тем, что прописано в конфиге запуска:

srcds_run -game left4dead2 +map c1m1_hotel -tickrate 60 +fps_max 300

Если в параметрах стоит -tickrate 60, а stats во время орды показывает падение до 30-35 — сервер физически не успевает считать логику на пике, и дальше вопрос упирается либо в железо, либо в снижение нагрузки со стороны настроек.

Настройки, которые реально снижают нагрузку

Не все ручки дают одинаковый эффект, но несколько конваров стоит проверить в server.cfg:

sv_alltalk 0
mp_gamemode "coop"
z_max_player_zombies "32"
sv_maxrate 0
sv_minrate 40000

• z_max_player_zombies — ограничивает, сколько «толпы» одновременно может быть привязано к игрокам. Снижение с дефолтных значений уменьшает пиковую нагрузку от орд ценой чуть менее плотных волн — компромисс, который на слабом железе часто того стоит.
• sv_maxrate/sv_minrate — управляют сетевой пропускной способностью на клиента. Это не решает проблему CPU, но снижает риск, что сетевая рассылка пакетов во время пиковой нагрузки станет вторым узким местом поверх первого.
• Отключение лишних ботов-заполнителей (sv_cheats 0 и связанные с ним debug-команды точно не нужны на проде) и лишних плагинов SourceMod, если они висят на каждом тике, а не по таймеру.

Если у вас стоит SourceMod с набором плагинов — стоит временно отключить часть из них (sm plugins unload) и сравнить нагрузку через stats во время следующей орды. Плагины, которые перехватывают события каждого зомби или считают что-то в цикле на каждый тик, легко становятся причиной именно пиковых просадок, а не постоянного фона лагов.

Главная причина на практике — процессор, а не количество ядер

L4D2, как и весь классический движок Source, считает игровую логику в основном одним потоком. Это значит, что сервер с формально «мощным» многоядерным CPU, но низкой частотой на ядро, может справляться с ордами хуже, чем сервер с меньшим числом ядер, но высокой частотой и хорошим IPC на ядро. Подробнее логика «почему ядра не главное» разобрана в статье сколько ядер CPU нужно под стабильный тикрейт — там же объяснено, когда дополнительные ядра всё-таки помогают (например, если на той же машине крутится ещё несколько игровых процессов).

При выборе тарифа под L4D2 с высоким онлайном (7-8 игроков плюс насыщенные орды на кооперативных или Versus-картах) стоит смотреть в первую очередь на:

Таблица — ориентир по значимости параметров, не результат конкретных бенчмарков: точные цифры сильно зависят от карты, числа ботов и набора плагинов на вашем сервере.

Карты, боты и Versus-режим — где нагрузка выше всего

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

Боты-компаньоны (когда людей меньше 4) считаются сервером почти как полноценные игроки с собственным ИИ, что добавляет нагрузку, хотя и меньшую, чем реальные орды зомби. Versus-режим при этом обычно тяжелее для сервера, чем Coop: там одновременно активны и команда выживших, и команда заражённых, управляющая спешлами вручную, — это два параллельных потока действий, которые серверу нужно синхронизировать чаще.

Если проблема проявляется именно на кастомных кампаниях из Steam Workshop — часть из них написана с избыточным количеством скриптованных сущностей или триггеров, что заметно поднимает нагрузку на тик по сравнению с оригинальными кампаниями Valve. Стоит проверить, воспроизводится ли лаг и на стоковых картах — если нет, дело именно в конкретной пользовательской карте.

Диагностика по шагам, если непонятно, с чего начать

1. Зафиксируйте, лагает ли постоянно или только в пиках (орда, Танк, финалы). Это сразу разделяет «проблема с CPU/тиком» и «проблема с сетью или картой».
2. Сравните -tickrate в конфиге запуска с реальными цифрами из stats во время пиковой нагрузки.
3. Проверьте net_graph 1/net_graph 4 у нескольких игроков одновременно — если у всех разом растёт loss/choke, это сеть, а не сервер.
4. Временно отключите SourceMod-плагины и сравните нагрузку — если лаги ушли, ищите виновника среди плагинов.
5. Если всё перечисленное чисто, а просадки остаются именно в пиках — переходите к тарифу с более высокочастотным CPU или без переподписки ядра. Общая логика такой диагностики (не привязанная к конкретной игре) разобрана в статье про мониторинг TPS и лагов на игровом сервере, а конкретные шаги по снижению нагрузки под пиковый онлайн — в статье оптимизация сервера под высокую нагрузку.

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