Войти
Короткий ответ: почему попадание засчитывается за укрытием
Вы успели.
Бетонная стена заняла весь экран, вражеский ствол исчез, палец уже отпустил клавишу движения. Можно перевести дух, поправить бронежилет, написать мемуары. И тут — БДЫЩ! — герой складывается на безопасной стороне стены, а вы начинаете объяснять монитору, что пули вообще-то не умеют заворачивать за угол.
Краткий ответ: на экране противника вы ещё не спрятались. Его выстрел дошёл до сервера с задержкой, сервер проверил более раннее состояние матча и признал попадание. Сообщение о смерти вернулось ещё позже — когда ваш клиент уже успел показать спасительное укрытие.
Это не обязательно прострел стены, низкий tickrate сервера или происки соседа, качающего восемь сезонов сериала. Чаще три участника перестрелки — стрелок, цель и сервер — просто живут в разных, слегка сдвинутых версиях настоящего.
Единой мгновенной картинки матча не существует. Ваш компьютер сразу показывает собственное движение, противник видит его с задержкой, а сервер получает команды обоих игроков ещё в другие моменты. Окончательное решение при этом принимает именно сервер.
Типичный эпизод выглядит так:
- На экране стрелка вы ещё находитесь перед укрытием.
- Стрелок нажимает огонь, и команда отправляется на сервер.
- На своём экране вы успеваете забежать за угол.
- Сервер восстанавливает состояние мира на момент выстрела и подтверждает попадание.
- Ваш клиент получает результат и показывает смерть уже за укрытием.
Именно поэтому вопрос «почему убивают за стеной в играх?» поставлен чуть неверно. Убили вас перед стеной, а за стеной доставили уведомление.
В разговорной речи всё это часто называют desync, или десинхронизацией. Сам по себе временной разрыв ещё не означает поломку: он неизбежен в сетевой игре. Настоящий прострел — отдельный случай: укрытие может быть разрушаемым или пропускать пули по правилам игры. Здесь же речь о ситуации, когда сервер подтвердил выстрел, сделанный до того, как цель скрылась в версии мира стрелка.
Почему клиент, сервер и соперник видят разные моменты
В одиночной игре мир помещается в вашем компьютере. Нажали W — солдат пошёл. Нажали кнопку мыши — оружие выстрелило. В сетевом шутере между нажатием и окончательным решением стоят интернет, сервер и другой человек, чей роутер, возможно, висит на гвозде в сарае за три области от дата-центра.
Зачем клиент предсказывает собственное движение
Если бы игра ждала подтверждения каждого шага от сервера, управление напоминало бы прогулку по колено в холодце. Поэтому применяется client prediction — клиентское предсказание. Ваш компьютер немедленно рассчитывает результат команды и показывает движение, не дожидаясь ответа.
Сервер получает команду позднее, выполняет собственный расчёт и либо соглашается, либо исправляет положение персонажа. Сильная коррекция выглядит как рывок или rubberbanding — будто невидимая резинка утаскивает бойца назад.
Почему соперников показывают с задержкой
Предсказать собственное нажатие клавиши можно, чужое — только при помощи кофейной гущи и отдела военной разведки. Клиент получает последовательность серверных снимков и плавно перемещает противников между известными позициями. Это интерполяция.
Без неё солдаты дёргались бы при каждом неравномерно пришедшем обновлении. Плавность покупается ценой небольшого временного сдвига: удалённые персонажи отображаются чуть в прошлом.
Почему последнее слово остаётся за сервером
В документации сетевой модели Source описаны все три элемента: prediction для собственных действий, interpolation для удалённых объектов и авторитетный сервер, которому принадлежит последнее слово. Такой сервер не принимает на веру сообщение клиента «я попал», иначе подменить результат выстрела было бы слишком легко.
Клиент может считать персонажа спасённым. Сервер вправе ответить: «Замечательно. Но двадцать миллисекунд назад в него уже попали».
Как работают lag compensation и server rewind
Lag compensation — это набор приёмов, компенсирующих сетевую задержку при проверке действий. Один из распространённых приёмов в шутерах — server rewind, то есть серверный откат состояния.
Сервер хранит короткую историю позиций. Получив команду выстрела, он оценивает, когда стрелок её отправил, временно возвращает цели туда, где они находились в доступной стрелку версии мира, проверяет попадание и восстанавливает текущее состояние матча. В Source при таком расчёте учитывается не только путь пакета, но и задержка интерполяции.
Конкретная реализация различается от игры к игре: разработчики могут ограничивать глубину отката, по-разному учитывать пинг и выбирать собственные правила для попаданий. Общий компромисс остаётся тем же.
Почему сервер не проверяет только текущее положение
Если проверять выстрел исключительно по состоянию мира в момент получения пакета, цель успеет переместиться. Стрелок честно наведёт прицел на видимого противника, нажмёт вовремя и получит торжественный ноль — хотя на его экране всё было правильно.
Близкий по духу откат применяется и в других жанрах, хотя rollback netcode в файтингах решает иную задачу. Файтинг пересчитывает последовательность игровых состояний после прихода запоздавшего ввода, а шутер обычно обращается к прошлому состоянию для проверки конкретного действия.
При чём здесь tickrate — и почему его повышения недостаточно
Tickrate — частота обновления серверной симуляции. При 20 Hz интервал между тиками составляет 50 мс, при 60 Hz — около 16,7 мс, при 128 Hz — примерно 7,8 мс. Чем чаще сервер обрабатывает состояние мира, тем выше временное разрешение движения и стрельбы. Это хорошо. Заверните два.
Однако высокий tickrate не телепортирует пакеты. Он не устраняет пинг обоих игроков, интерполяцию, джиттер, потерю данных, просадки клиентского FPS, серверную нагрузку и выбранные разработчиками правила rewind.
В техническом разборе Apex Legends Respawn описывала серверы с частотой 20 Hz и приводила расчёт для RTT 50 мс. В худшем случае переход с 20 на 60 Hz уменьшил бы время от ввода до обработки сервером с 75 до 41,7 мс — примерно с пяти до трёх кадров при 60 FPS. Выигрыш есть, но сервер не становится втрое отзывчивее.
Высокий tickrate полезен, однако поклонение одной цифре — техническое язычество. Можно построить великолепную часовню на 128 тиках и провести к ней интернет по мокрой бельевой верёвке.
Почему у выходящего из-за угла бывает преимущество
Игрок, резко появляющийся из-за угла, знает, что собирается сделать. Защитник сначала должен получить обновление, увидеть врага и отреагировать. Так рождается peeker’s advantage — преимущество выходящего.
Riot раскладывала его на несколько составляющих: клиентский кадр атакующего, путь данных до сервера, серверный кадр, доставку обновления защитнику и интерполяционный буфер. В опубликованном разработчиками примере для VALORANT совокупное преимущество составляло около 40–70 мс. Это не универсальное значение для всех игр, но даже такой отрыв важен в быстрой перестрелке.
Даёт ли высокий пинг преимущество
Высокий пинг — не секретное оружие. Разработчики VALORANT отмечали, что низкая задержка почти всегда выгоднее: команды быстрее достигают сервера. Высокий пинг способен увеличить неприятный временной разрыв для обоих участников, но его владелец тоже позднее получает события и результаты собственных действий.
Распределение преимуществ зависит от сетевой модели. Например, разработчики Apex прямо объясняли, что иногда позволяют серверу учитывать выстрел высокопингового игрока по прошлому состоянию мира. Поэтому нельзя переносить правила одной игры на другую.
Кого именно должен разочаровать сервер
Вариант первый — уважать экран стрелка. Если тот видел цель и точно попал, сервер применяет rewind. Стрелок доволен, а убегающий иногда умирает за укрытием и желает разработчикам провести отпуск внутри работающего реактора.
Вариант второй — учитывать только текущее положение цели. Спрятавшийся спасён. Зато стрелок видит попадание и узнаёт, что его выстрел не существует, поскольку серверная цель уже убежала вперёд. Теперь клавиатуру ест он.
Полностью устранить противоречие нельзя, пока информация распространяется не мгновенно. Это подтверждает и исследование феномена shot around a corner: на заметность проблемы влияют задержка, скорость движения и допустимая глубина компенсации.
Зато расхождение можно уменьшить: ограничить rewind, точнее синхронизировать часы, быстрее восстанавливать сетевые буферы после скачков и аккуратнее доставлять подтверждения урона. Сетевой парадокс неизбежен; его чудовищный размер — уже нет.
Desync, высокий пинг, джиттер или баг hitreg
Словом desync игроки называют всё: смерть за углом, телепортацию, no-reg, пять пуль, прилетевших одним кирпичом, и просто неудачный вечер. По одному повтору точную серверную причину обычно не определить, но симптомы можно разделить.
Когда это похоже на обычный компромисс netcode
Редкая смерть на самом краю укрытия без рывков, сетевых предупреждений и других странностей укладывается в нормальную работу lag compensation. Особенно если противник видел персонажа на долю секунды дольше, чем сам персонаж видел открытое пространство.
Когда проверять соединение и производительность
Если бойцов колбасит, пинг скачет, значки соединения мигают, а одну дверь приходится проходить дважды, стоит проверить маршрут, packet loss и то, почему высокий пинг зависит от расстояния до сервера.
Packet loss — потеря пакетов по пути, а джиттер — колебание времени их доставки. Поэтому ровный средний RTT, то есть время полного пути сигнала до сервера и обратно, способен обманывать. Краткий скачок может заполнить сетевой буфер и временно увеличить задержку даже после нормализации пинга. Riot находила подобные состояния после сетевых всплесков, просадок FPS и возвращения в игру после Alt+Tab. Подробнее — в материале о том, как джиттер превращает ровный средний пинг в нестабильное соединение.
Когда вероятнее проблема игры или сервера
No-reg, или незарегистрированное попадание, — обратная ситуация: клиент показывает выстрел по цели, но сервер не подтверждает урон. Причиной могут быть задержка, потеря пакетов или ошибка игры.
Если проблема массовая, воспроизводится с определённым оружием, картой или после конкретного патча и сопровождается одинаковыми клипами, подозрение смещается от домашнего роутера к игре. Серверные просадки обычно затрагивают сразу нескольких участников матча, а не одного игрока.
Что показывает обновление netcode в Battlefield 6
Патчноут Battlefield 6 1.3.3.0, опубликованный 26 июня 2026 года для обновления от 30 июня, интересен тем, что разработчики не выкрутили единственную ручку «СДЕЛАТЬ ХОРОШО». Они меняли сразу несколько частей системы: обработку нескольких событий урона, скорость отображения подтверждений, распределение полосы для близких и видимых противников, синхронизацию клиентских часов и поведение TimeNudge после сетевых или производительных скачков.
TimeNudge здесь — внутренний механизм временной подстройки сетевого состояния. По описанию патча он должен быстрее реагировать на изменение условий и восстанавливаться после просадок, чтобы позиции противников не оставались запоздалыми слишком долго.
Смерть за укрытием способна родиться не из одного большого провала, а из выводка мелких: позиция врага обновилась поздно, буфер не успел уменьшиться, события урона пришли пачкой, клиентские часы съехали после просадки CPU — и вот несколько пуль превращаются в один чугунный привет.
Патч показывает многосоставность проблемы, но не доказывает, что все подобные смерти исчезли. Неизбежность небольшого расхождения не выдаёт разработчикам лицензию на любое сетевое безобразие.
Что меняется в облачном гейминге
В облачном гейминге между игроком и матчем появляется ещё один участок пути: ввод отправляется на удалённый компьютер, а готовое видео возвращается обратно. Сам облачный компьютер при этом подключается к игровому серверу как обычный клиент.
Задержка видеопотока или ввода может сделать смерть визуально более поздней, но решение о попадании по-прежнему принимает сервер самого шутера. Поэтому важно разделять два явления: запоздалый кадр облачной трансляции и server rewind внутри игры. Они могут сложиться, но исправляются на разных уровнях.
Что можно проверить самостоятельно
Включите сетевую статистику игры и запишите матч. Для полезного обращения в поддержку пригодятся:
- регион и название сервера, если оно отображается;
- время матча;
- ping или RTT;
- jitter и packet loss;
- FPS и график времени кадра;
- сетевые предупреждения;
- клип, где показатели видны вместе со спорной смертью.
Один спидтест почти ничего не доказывает. Он измеряет соединение с выбранным тестовым узлом, но может не поймать плохой маршрут до игрового дата-центра, секундный скачок, потерю пакетов или задержку внутренних буферов.
Выберите ближайший регион, по возможности подключитесь кабелем, закройте фоновые загрузки и добейтесь стабильного FPS. Не копируйте древние консольные «магические настройки»: даже документация Source рекомендует сохранять стандартные сетевые параметры, если вы не понимаете последствий их изменения.
Отключить server rewind или исправить серверную обработку на стороне игрока нельзя. Зато собранные показатели помогут отличить разовый пограничный эпизод от устойчивой проблемы соединения, производительности или самой игры.
Иногда вы действительно были за стеной. На своём экране. Противник действительно попал. На своём. Серверу осталось выбрать одну реальность, и на этот раз он выбрал не вашу.
Стена невиновна. Интернет — тем более не раскаивается.