В Deathmatch, Team Deathmatch, Capture the Flag и Bombing Run - без проблем, главное чтобы пинг был небольшим, а вот Onslaught точно и может быть Assault потребуют большей пропускной способности канала, что будет вызывать лаги и глюки в игре.
1. Вступление
Этот материал - попытка разобраться в том, как UT работает онлайн, что такое пинг и лаг, как все работает и как получать информацию посредством статистики, заложенной в UT. Возможно, будет полезно всем - от продвинутых игроков до серьезных администраторов серверов. Если вам не все будет понятно в этом материале, не стоит беспокоится - на качество игры это не повлияет (как-то вы играли столько времени, не читая этого ;))
Но если вы всегда хотите знать лагает ли ваш сервер из-за перегрузки процессора или почему только что выпущенные вами ракеты прямо в лицо противнику не нанесли ему вреда - этот материал даст вам ответы.
2. Основы интернета
Здесь описывается базовая информация: что такое "скорость" и качество соединения в интернет. Если вы уже знаете, что такое пинг/задержка и потеря пакетов можете пропустить это.
Обычно, скорость соединения определяется в килобайт/сек или килобит/сек. Эта скорость называется пропускной способностью канала. Второй компонент называется задержкой и определяется временем, необходимым для передачи данных по назначению. Считается обычно в милисекундах (1/1000 секунды, ms) и определяет пинг (величина пинга как правило равна задержке, умноженной на два, поскольку данные нужно сначала передать и потом получить ответ). Значение обоих факторов можно представить на примере: машина, груженая тысячей хард-дисков по 10 гигобайт каждый едет к примеру со скоростью 50км/ч, если длина ее пути равняется 100км то скорость передачи данных на расстояние таким образом составит 1 гигобайт в секунду! Нет желания поиграть через такое "соединение"? ;)
Игроки UT знают, что есть много разных вариантов пинга, в том числе в UT но в большинстве своем это не стандартный icmp пинг.
Если вы хотите выяснить причину плохой связи с сервером, неплохо для начала проверить маршрут передаваемой вами информаци до него. Узнайте адрес сервера (ip или url), откройте окошко доса и напишите в нем "tracert (ip/url)". Вы увидите весь путь, который проходят ваши данные с указанием пинга до каждого участка "hop".
Если вы увидите увеличенный пинг в некоторых местах (к примеру в начале 30, а потом 100 и выше) можете быть уверены: в ваших проблемах виноват не сервер и не ваш компьютер, а интернет. Здесь вы ничего не сможете сделать, разве что обратится с этими данными к своему провайдеру (или сменить его или выбрать другой игровой сервер - прим. пер.)
Существует много инструментов для выяснения маршрутов помимо виндового, мне например нравится plotter (Pingplotter), вы можете выбрать любой другой.
В интернет информация передается пакетами. Если по какой-либо причине (например испорченное оборудование в одной из точек по пути) часть пакетов может потерятся и не достичь назначения, это называется потеря пакетов. Чтобы выяснить где именно это происходит, используйте программы, указанные выше (например тот же plotter). Если потеря происходит в первой же точке, проблема скорее всего с в ваших настройках или оборудовании. Если это происходит в последней точке (сервер) скорее всего что-то не так - вы уже догадались - с сервером.
Примеры хороших соединений (данные приведены для Германии, в других странах значения могут быть иными):
ISDN...............- ~20 ms до первой точки, 30 ms до сервера
TDSL (no fastpath)- ~30-60 ms до первой точки, 40-80 ms до сервера
TDSL (fastpath)....- почти нет (~5 ms) лучше чем ISDN
QDSL...............- ~10-15 ms до первой точки, 25-35 до сервера
Если ваши значения сильно разнятся с этими, значит или провайдер плохой, неправильная настройка компьютера либо длинные маршруты до серверов.
3. Основы статистики и настроек UT
В UT вы можете видеть два аида пинга. Пинг по F1 и пинг по F6. Оба отличаются друг от друга. Причина проста - они высчитываются по-разному.
Пинг по F1 показывает пинг сервера до вас, пинг по F6 показывает пинг от вас до сервера. Если icmp пинг не показывает подобной разницы, то UT показывает, поскольку серверу и клиенту необходимо различное время для отправки данных.
Вторая важная вещь - потеря пакетов. Отображается дважды в столбцах IN и OUT - IN показывает то, чо вы получаете с сервера, OUT это трафик от вас к серверу.
Потеря пакетов может происходить как в каждом направлении по отдельности так и в обоих одновременно (что наиболее часто). В этом случае вы, как клиент, будете недополучать важную информацию (такую, как летящие в вас ракеты, перемещение вокруг вас игроков) и/или сервер не будет ее получать (не будет знать куда вы прицелились, ракеты будут выстреливать вам под ноги)
Все причины потери пакетов смотрите выше во второй части статьи.
Немного о том, что вы можете настроить для онлайн-игры как клиент в UT это только скорость соединения. Первое: забудьте о рекомендованных Epic значениях. Второе: да, клиентский fps зависит от скорости соединения. Тем не менее это не играет большой роли, поскольку устанавливает некий максимум на ваши fps. Как результат вы будете иметь меньшее значение средних fps, но в важных ситуациях они не будет падать.
Принимая это во внимание, вы должны всегда устанавливать вашу скорость соединения согласно реальной пропускной способности вашей линии. Учитывая при этом трафик в обе стороны одинаков (полный дуплекс) или нет (half duplex и вариации). Для евро isdn 64k скорость должна быть 6500 (это не полный дуплекс, но может поддерживать в принципе 6.5 kb/sec в обоих направлениях одновременно). Для быстрых линий - DSL и аналогов нормальная скорость 20000 (вы по-любому никогда не получите больший одновременный трафик в обоих направлениях), но если у вас проблемы на некоторых серверах попробуйте уменьшить это значение - вполне может быть по пути от вас до сервера "бутылочное горлышко" на одном из участков маршрута пакетов. Как правило так и бывает при игре на больших расстояниях (из страны в страну или если сервер на другом континенте) .
Если указанная вами скорость слишком высока это даст вам на вид больше fps, но может принести проблемы если ваш компьютер действительно мощный, вы создадите больше трафика до сервера чем ваше соединение сможет вместить. Даже при определении сервером максимальных значений для клиентов (maxclientrate) не сможет исправить ситуацию, так как определяется сервером до вас, но не ваш трафик до сервера.
Так, вы все настроили, пинг хороший, нет потерь пакетов но все еще лагает? Это может быть по нескольким причинам. Если у вас лаги на всех серверах, в первую очередь проверьте свои настройки. Фаэрволы, вирусные сканнеры, ICQ и другие IM клиенты могут вмешиваться в онлайн-игру UT, поэтому стоит попробовать все это отключать на время игры и смотреть не стало ли лучше. Проверьте драйверы для устройства соединения (в особенности если у вас ISDN), но так же и для видеокарты и других устройств. Если вы подключаетесь к внешнему модему (DSL или кабель) через локальную сет, ваша сетевая карта возможно нуждается в новых/других драйверах либо присутствуют irq конфликты в распределении ресурсов компьютера.
Если ничего из вышеуказанного не помогло, самое время проверить сервер, что мы и сдлаем в следующем разделе.
6. Advanced netcode
Эта часть повящена целиком деталям того, как сетевой код UT реально работает. Для понимания всего написанного знание основ объектно-ориентированного программирования рекомендуется, но не обязательно.
Итак, как же работает UT онлайн? Чтобы понять это, для начала необходимо понимать основы проблем всех онлайн игр в интернет. Эта проблема - задержка, с которой отсылаются данные поэтому абсолютно невозможно полностью синхронизировать всех игроков. Это означает, что игроки никогда не видят одно и то же, всегда есть задержка прежде чем игрок А увидит что делает игрок Б.
Как большинство игр сегодня, UT использует модель сетевого кода, где главным является сервер. Это означает, что сервер определяет что "на самом деле" происходит; он руководит всей игрой. Если сервер видит, что игрок А стреляет в игрока Б, игрок Б получает дэмедж - вне зависимости от того, видит ли Б что в него стреляет А или видит ли А что попадает в Б. Это означает так же что сервер решает где на самом деле находятся игроки.
Клиенты пытаются симулировать "реальный мир" сервера настолько насколько это возможно. Меткость при этом полностью зависит от пинга. Чтобы сделать эту симуляцию как можно ближе к действительности, существует два пути в сегодняшних играх. Первый состоит в том, чтобы дать возможность клиенту попытаться предсказывать состояние "реальной игры" исходя из имеющейся информации (это то, чем занимается UT), другой путь разрешить серверу "возвращать назад" ситуацию к тому моменту, когда было выполнено действие (так работает HalfLife и zeroping, UT-мод пытающийся делать в UT что-то подобное). Вторая модель указана здесь только для информации и не имеет отношения к UT.
Обе эти модели имеют за и против. В первой модели клиент всегда имеет информацию не соответсвующую действительности, другие игроки уже переместились в новых направлениях. Клиенты других игр пытаются распределить движение других игроков в соответсвии с пингом (QW одна из таких), UT этого не делает. Тем не менее, поскольку частота кадров клиента обычно выше чем число обновлений, получаемых с сервера, UT экстраполирует движение таким же образом, указанным выше, пока не получит новую информацию о перемещении клиента. Это причина "скользящих" игроков при лагах - UT экстраполирует их "старые" движения пока не получит информации о "новом" местоположении или направлении.
Во второй модели игроки которых подстрелили на чьем-то клиенте, продолжают думать что они на сервере в "реальном мире", но через некоторое время игроку сообщат что он был подстрелен (или даже убит) некоторое время назад. Никакие его выстрелы после того момента уже не считаются. Самый цирк происходит, когда игрок уже изчез из поля зрения другого и вообще в другом месте вдруг узнает что был убит.
Теперь когда мы знаем как все устроено можно посмотреть как это реализуется. Для полной симуляции всего происходящего сервер должен слать клиенту всю информацию о происходящем, что потребует слишком большого трафика. Для уменьшения нагрузки на соединение используется несколько вещей; некоторые из них (те, что влияют на игру) будут рассмотрены здесь.
Для понимания того, как эти метод работают мы должны взглянуть как это устроено в UT. Для всего, что присутствует в игре, существуют теплаты, называемые "класс". Каждый объект (те объекты, что имеют какое-либо отношение к игре, называются "актеры" в UT) имеет свойства. Например есть класс "ракеты" и каждый раз когда ракета создается (стреляет кто-то) получает свойства, основанные на классе.
UT использует различные свойства для актеров для определения как они отсылаются клиенту (либо в случае движения игрока от клиента серверу и от сервера другим клиентам)
Теперь о методах уменьшения трафика: если клинет не может видеть или слышать актера (будь то другие игроки, рокеты, флаковые шардины или что-либо еще) нет причин сообщать коиенту что они делают. UT реально проверяет это (называется проверкой на отношение) и не воспроизводит актеров "вне поля зрения/слуха" клиента. Переменная "relevanttimeout" в ipdrv.tcpnetdriver на сервере определяет как долго актер может находиться в таком состоянии прежде чем будет иметь какое-то отношение к клиенту. Результат такой проверки можно видеть при воспроизведении клиентских демок от третьего лица (в таком режиме можно больше увидеть) - игроки, которые не видны были игроку, записавшему дему, невидимы, вы можете видеть как они реально пропадают как только игрок их не видит. Разумеется, как только они становятся видны (снова или впервые) сервер передает информацию о них клиенту.
Следующий важный метод заключается в симулировании поведения актеров где это только возможно. В перую очередь это распространяется на все метательные снаряды (типа ракет). Когда такое тело выстреливается, сервер сообщает клиенту в каком месте это рождается (создается) и в каком направлении летит. С этого момента клиент симулирует полет объекта без получения какой-либо дополнительной информации - клиент знает скорость, и, поскольку изменения направления произойти не может, серверу нет необходимости передавать клиенту обновленную информацию о местоположении объекта. Эта симуляция часто служит причиной "фантомных ракет", когда клиент видит как его ракеты попадают в другого игрока но тот не умирает. Причина проста: поскольку ракеты симулируются клиентом, клиент так же "решает" что их пора взрывать (визуально - дэмедж разумеется решается сервером). Поэтому если клиент видит что ракеты попали в игрока, они взорвались - но клиентский мир не существует, особенно для других игроков которые могли уже давно переместиться в "реальном мире" на сервере. Вы можете быть уверены в том, что нанесли дэмедж только в том случае, если увидите кровь на игроке или что его мясо воляется вокруг поскольку и кровь и моментальное изменение состояния игрока определяется только сервером.
Другой параметр, используемый для уменьшения трафика - "netupdatefrequency", определяемый для каждого класса. Поскольку одни актеры (как движения игроков) требуют обновлений, а другие нет. На игру не оказывают никакого негативного влияния такие вещи как счет, поскольку не передаются 50 раз в секунду. Netupdatefrequency определяет как должны передаваться актеры клиенту (максимальное число). Netupdatefrequency можно заметить по задержкам оповещения игрока о его арморе при попадании в него - армор обновляется только 10 раз в секунду, таким образом до 100 ms может быть задержка прежде чем игрок будет информирован что его броника уже нет. Максимальное значение netupdatefrequency может быть 100, это так же очевидно как и тикрэйты > 100 неиспользуемы - ничего не может обновляться для клиента чаще чем 100 раз в секунду в любом случае.
Зная всю эту информацию, значения "channels" и "bunches" из stat net проще понять: channels это число актеров, непосредственно относящихся к вам; bunches отображает число обновлений актеров, которые были получены за последнюю секунду. Зная эти числа легко понять важность "нет изменений переменных - нет обновлений".
Другая вещь, которую стоит знать, состоит в том, что UT серверы всегда шлют клиентам пакет в конце тика даже если актеры этого не требуют. Это означает, что в большинстве случаев UT будет слать один пакет в каждый тик даже если нечего слать. Единственная причина, по которой число пакетов в секунду может быть меньше установленного тикрэйта в процессе реальной игры (не netservermaxtickrate - смотрите объяснение проблемы linux серверов в части 5) только в ограниченной пропускной способности клиентского соединения, не способной принять слишком большое число пакетов.
Players Guide to UT Netcode
by =NUB=garfield
thanks to:
Mike "Mongo" Lambert
TNSe
помогите бодрые люди. я беру инет 8кб\сек(64кбит), хотя реальная скорость - 10-14 кб. ну почему этот хренов УТ лагает так...??? пинг я так и не понял где правильный, нажимаешь F1 там 400, смотришь в менюшке какой-то, там 100. чем можете помочь? :)
Скажите пожалуйста, можно-ли будет играть в UT 2004 по модему?