Технические аспекты внедрения многопользовательской сети в Half-Life и Counter-Strike

Внедрение многопользовательских сетей в таких основополагающих играх, как Half-Life и Counter-Strike, потребовало решения глубоких технических проблем, которые продолжают влиять на разработку онлайн-игр сегодня. Первоначально построенный как модификация движка Quake от Valve, Counter-Strike превратился в автономный движок, который требовал высокой точности, низкой задержки и чит-устойчивого геймплея. Сетевая архитектура, разработанная для этих игр, основанная на модели клиент-сервер, пользовательской надежности по UDP и сложной компенсации задержки, установила эталон для многопользовательских шутеров в реальном времени. В этой статье рассматриваются основные технические компоненты, лежащие в основе сетевого кода Half-Life и Counter-Strike, протоколы и алгоритмы, которые заставили их работать, и наследие, которое эти решения оставили для современных онлайн-игр.

Модель клиент-сервер в деталях

Half-Life и Counter-Strike реализовали строгую архитектуру клиент-сервер, где сервер поддерживает авторитетный контроль над всем состоянием игры. Каждое действие игрока — будь то перемещение, съемка или перезагрузка — должно быть проверено сервером, прежде чем оно повлияет на симуляцию. Этот дизайн предотвращает подделку и поддерживает согласованность во всех подключенных клиентах.

Авторитетный сервер

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

Обработка входных данных клиента

Каждый клиент собирает ввод игрока в каждый кадр и упаковывает его в командную структуру, которая включает векторы движения, углы обзора, состояния кнопок и временную метку. Эти команды отправляются на сервер в виде UDP-датаграмм. Сервер выполняет их в правильной последовательности на основе порядка тиков и применяет их к авторитетному моделированию. Для сглаживания переменной задержки сервер обрабатывает команды от нескольких клиентов одновременно в течение каждого фиксированного шага времени. Любая команда, прибывающая слишком поздно или не в порядке, либо отбрасывается или перераспределяется, в зависимости от ее важности. Этот дизайн гарантирует, что симуляция сервера остается детерминированной и чит-устойчивой.

Сетевой транспорт: почему UDP и пользовательские настройки

Half-Life и Counter-Strike полагаются в первую очередь на UDP (User Datagram Protocol) для обмена данными в режиме реального времени, выбирая его вместо TCP, несмотря на гарантированную доставку TCP и преимущества заказа. Решение было обусловлено необходимостью низкой задержки и возможностью быстро восстанавливаться после потери пакетов.

UDP vs. TCP Trade-offs (недоступная ссылка)

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

Packet Loss - обработка и секвенирование

Сетевой код GoldSrc реализует свой собственный уровень надежности поверх UDP. Критические сообщения (такие как результаты стрельбы оружием или смерти игрока) отправляются с использованием надежного канала, который последовательности пакетов и запросы ретрансляции, если подтверждения не принимаются в течение периода тайм-аута. Менее критические обновления - такие как изменения положения или состояние анимации - отправляются ненадежно, позволяя системе отбрасывать старые снимки в пользу новых. Номера последовательности прикреплены к каждому пакету, чтобы приемник мог обнаруживать потерянные или неупорядоченные дейтаграммы и либо отбрасывать устаревшие данные, либо запрашивать повторную отправку. Этот гибридный подход позволил Half-Life и Counter-Strike поддерживать адаптивный геймплей даже на ограниченной полосе пропускания и соединениях с высокой задержкой конца 1990-х и начала 2000-х годов.

Для более глубокого изучения эволюции игровой сети в реальном времени, собственная презентация Valve GDC 2001 Яна Бернье предоставляет полный обзор методов, используемых в Half-Life: Методы компенсации задержек в разработке и оптимизации протокола клиент / сервер в игре .

Сглаженная игра над ненадежными сетями

Даже при UDP и пользовательской надежности игроки испытывают переменную задержку, потерю пакетов и дрожь.Для поддержания иллюзии мгновенного ответа и согласованных взглядов на мир Half-Life и Counter-Strike реализовали три критических метода: предсказание на стороне клиента, сверка сервера и интерполяция сущности.

Клиент-Помощь Предсказание и Согласование Сервера

Без предсказания на стороне клиента каждое действие игрока будет подвергаться задержке в оба конца: вы нажимаете мышь, команда перемещается на сервер, сервер обрабатывает его, и результат возвращается. Для такой игры, как Counter-Strike, где время реакции измеряется в миллисекундах, эта задержка будет неприемлемой. Прогноз на стороне клиента позволяет локальному клиенту немедленно имитировать эффект своего собственного ввода (например, двигаться вперед или стрелять) до того, как сервер подтвердит это. Клиент запускает копию игрового мира и обновляет его с использованием тех же правил движения и физики, что и сервер. Это дает игроку мгновенную визуальную обратную связь.

Однако предсказание клиента может отклоняться от авторитетного состояния сервера из-за запаздывания, потери пакетов или различий в симуляции. Выверка сервера исправляет эти отклонения. Каждый раз, когда сервер отправляет снимок состояния игры, клиент сравнивает позиции сервера с собственным предсказанным состоянием. Если есть несоответствие, клиент плавно перемещает свои локальные объекты к позициям сервера, исправляя ошибки без резких телепортаций. Эта комбинация предсказаний и выверки заставляет Counter-Strike чувствовать себя отзывчивым даже тогда, когда у игрока высокий пинг.

Интерполирование сущности

Поскольку сервер отправляет обновления только с фиксированной частотой (скоростью тика), клиент получает дискретные снимки. Интерполяция сущности заполняет пробелы, визуализируя положения объекта за раз между двумя последними полученными снимками, используя взвешенные средние значения на основе временных меток. Это создает плавное, непрерывное движение даже тогда, когда сервер обновляется только 20 или 66 раз в секунду. В Counter-Strike интерполяция видна в том, как игроки перемещаются: они не появляются, чтобы «переключаться» между позициями, потому что движок плавно смешивает анимацию и пространственное состояние между обновлениями.

Компенсация за оружие Hitscan

Одной из самых инновационных функций в нет-коде Counter-Strike является компенсация задержки для оружия сканирования (стрелки, пистолеты, снайперские винтовки). Поскольку пули мгновенно перемещаются в механике сканирования сканирования, сервер должен решить, был ли выстрел поражен в зависимости от положения цели в момент выстрела, а не когда сервер обработал его. Если игрок имеет задержку 100 мс и нацелен на врага, к тому времени, когда сервер получает команду, противник может переместиться в другое место. Без компенсации выстрел промахнется.

Решение Valve хранит короткую историю позиции каждого игрока за последние несколько сотен миллисекунд на сервере. Когда сервер получает команду выстрела, он просматривает позицию цели в то время, когда клиент стрелка видел их (соответствие временной метки в команде). Сервер затем выполняет обнаружение удара против этой исторической позиции, а не текущего состояния. Этот метод, называемый компенсацией задержки, драматично уменьшает недостаток более высокого пинга. Однако он также вводит риск «стрельбы за стенами», если сохраненная история слишком длинная или если часы сервера не синхронизированы. Для баланса справедливости сервер накладывает максимальное окно компенсации (обычно 100 мс) и использует сообщенную задержку клиента для настройки окна на игрока.

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

Tick Rate и частота обновления

Скорость тика определяет, как часто сервер обрабатывает ввод и отправляет снимки.В начале Counter-Strike 1.6 частота тика сервера по умолчанию составляла около 20 Гц (20 обновлений в секунду) на официальных серверах, в то время как конкурентные серверы часто повышались до 33 или даже 100 Гц с использованием пользовательских настроек. Более высокие скорости тика уменьшают задержку между действием игрока и ответом сервера, но они также увеличивают пропускную способность и использование процессора.

Сервер Tick Rate (sv tickrate)

Скорость клещей напрямую привязана к размеру шага моделирования сервера. При 33 Гц каждый клещ представляет примерно 30 мс игрового времени. Сервер выполняет все ожидающие команды, запускает физику, обрабатывает повреждения и отправляет полный снимок всем клиентам каждый клещ. Более высокая скорость клещей означает более точное обнаружение попадания и более плавное движение, но также увеличивает нагрузку на ЦП сервера и сеть. В современном Counter-Strike: Global Offensive скорости клещей 64 и 128 Гц являются стандартными, но основные принципы остаются прежними.

Настройки клиентской интерполяции (lerp)

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

Пропускная способность и оптимизация данных

Half-Life и Counter-Strike были разработаны для интернет-соединений своей эпохи (56k модемов для раннего широкополосного доступа). Для управления пропускной способностью сетевой код использовал несколько методов оптимизации.

Дельта компрессия

Сервер не отправляет полный режим игры с каждым моментальным снимком. Вместо этого он отправляет базовый моментальный снимок после подключения игрока, а последующие снимки сжаты в дельта-сжатии: передаются только изменения (дельта) с момента последнего признанного снимка. Это резко уменьшает размер каждого обновления. Например, если игрок стоит на месте, сервер может отправить только крошечное обновление, указывающее на отсутствие изменения позиции. Если игрок стреляет оружием, дельта включает в себя новый счетчик боеприпасов и состояние вспышки дульной вспышки, но не весь массив оружия. Сжатие дельты необходимо для поддержки большого количества игроков (до 32 в Counter-Strike) без насыщения сети.

Обновления переменной ставки

Критические события, такие как повреждение, убийства и стрельба оружием, отправляются немедленно с помощью надежного канала, в то время как обычные позиционные обновления отправляются с частотой тика с использованием ненадежного канала. Сервер также динамически регулирует скорость обновления на основе доступной полосы пропускания и качества клиентского соединения. Если клиент испытывает потерю пакетов, сервер может уменьшить частоту несущественных обновлений или переключиться на более надежный канал для критических данных. Этот адаптивный подход помог поддерживать воспроизводимость в широком диапазоне сетевых условий.

Анти-чит архитектура (VAC и выше)

Ни одно обсуждение сетей Half-Life и Counter-Strike не является полным без упоминания Valve Anti-Cheat (VAC). Хотя VAC в первую очередь является системой сканирования на стороне клиента и обнаружения на стороне сервера, его дизайн опирается на авторитетный нет-код сервера. Читы, которые изменяют память клиента или вводят пакеты, должны обходить проверки проверки сервера. VAC работает в тандеме с нет-кодом:

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

Критически авторитет сервера предотвращает многие распространенные читы: валлхак может только выявить то, что уже отправлено клиенту (сервер отправляет все позиции сущности, поэтому валлхак смягчается логикой «видимости» сервера и ограничением данных, которые клиенты получают о далеких врагах).Сочетание авторитета нет-кода и внешних анти-читерских систем остается стандартом для конкурентоспособных шутеров.

Подробнее об истории и возможностях VAC см. официальную страницу Valve Anti-Cheat .

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