В игре появилось несколько инструментов для отслеживания важных технических показателей, таких как интернет-соединение и производительность ПК. Средства мониторинга позволят подобрать оптимальные настройки оборудования для комфортной игры. А в случае возникновения проблем специальные индикаторы оперативно уведомят вас об этом.
Виды индикаторов проблем
Индикатор низкой кадровой частоты
Появляется при низком параметре FPS (30 кадров в секунду и ниже). Данный параметр напрямую зависит от аппаратной мощности ПК, и влияет на плавность картинки. Чем больше кадров в секунду — тем лучше.
Индикатор высокого пинга
Это предупреждение можно увидеть при чрезмерно высоком пинге (от 200 миллисекунд и выше). Пинг — это время, затраченное на передачу пакета информации в компьютерных сетях, от вашего ПК к серверу и обратно от сервера к ПК. Для игры крайне желательно, чтобы время передачи пакета не превышало 50 мс, если пинг выше 50, то играть становится менее комфортно.
Индикатор потери пакетов
Иконка сигнализирует о потере пакетов и появляется когда этот показатель выше 20%. Чаще всего пакеты могут теряться в случае ошибок при передаче данных через беспроводные сети или при перегруженности сети. А также из-за неполадок в программном обеспечении или сетевом оборудовании. Если не все пакеты данных достигают клиента или сервера, в игре могут наблюдаться проблемы. Например: перемещение персонажа рывками и телепорты.
Средства мониторинга
Качественное интернет-соединение и высокая кадровая частота являются залогом комфортной игры. Поэтому для удобной и оперативной оценки состояния этих показателей в Warface добавлены специальные инструменты — средства мониторинга и индикаторы проблем.
Средства мониторинга позволяют в режиме реального времени отображать состояние основных показателей интернет-соединения и аппаратной части.
Кадровая частота (FPS).
Задержка центрального процессора (CPU time).
Задержка графического процессора (GPU time).
Задержка сети (Ping).
Потеря сетевых данных (Packet loss).
Задержка сервера (Server tick).
Общая аппаратная задержка до начала рендеринга (для видеокарт с поддержкой SDK NVIDIA Reflex и DirectX 11).
Данные могут быть показаны как в текстовом, так и в графическом виде. Включение и выбор способа отображения инструментов осуществляется в разделе «Метрики» в окне настроек игры.
Если значение одного или нескольких показателей станет критичным для игрового процесса, новые индикаторы проблем в правом верхнем углу экрана уведомят вас об этом.
Низкая кадровая частота (FPS)
Данный параметр напрямую зависит от аппаратной мощности ПК, и при недостатке ресурсов изображение станет менее плавным. В отдельных случаях это может приводить к так называемым «фризам», когда изображение на экране замирает на некоторое время.
Задержка центрального и графического процессоров
Картинка на мониторе не появляется моментально, поскольку во время игры оба процессора выполняют массу работы, на которую требуется некоторое время. Например: центральный процессор, помимо прочих вычислений занимается предварительной подготовкой кадров, а графический процессор занимается рендерингом и выводом получившейся картинки на монитор. На это всё уходит некоторое количество процессорного времени. Другими словами, задержка процессора — это время, затраченное им на обработку задачи. При высокой загруженности процессора время на обработку задач может увеличится. В таком случае будет не лишним уменьшить объем задач, выполняемых процессором. Например, путем изменения настроек игры на более низкие или уменьшив количество программ, работающих в фоновом режиме.
Высокий пинг
Сервер и клиент взаимодействуют путем обмена пакетов данных. Если время, которое требуется пакету данных для перехода от игрового клиента к серверу и обратно, будет слишком большим, качество игрового процесса значительно ухудшится (непрохождение урона, «телепорты» и прочее).
Потеря пакетов
Если пакеты данных не достигают клиента или сервера, в игре также могут наблюдаться проблемы, похожие на указанные выше (например, перемещение персонажа рывками).
Потеря соединения
При возникновении серьезных затруднений в обмене данными между клиентом и сервером дальнейший игровой процесс становится невозможен. Обычно это случается при наличии проблем с интернет-соединением.
Задержка сервера
TickRate — это серверная скорость отправки и получения данных между самим сервером и игровым клиентом. Она измеряется количеством отправок в секунду. Одной из функций в метрике является измерение серверной задержки. Значение Server tick в игре отображается в миллисекундах — это не сам TickRate, а время между отправкой пакетов. В одной секунде содержится 1000 миллисекунд и если мы разделим этот показатель (в игре он сейчас 16,6 мс), то как раз получим 60 с маленькими копейками. Это и будет текущий TickRate.
UPD: В обновлении от 10 декабря 2020 года были изменены единицы измерения для метрики серверного TickRate (с миллисекунд на герцы). Ранее при серверном значении в 60 Гц клиент отображал информацию о 16,6 мс — это корректные и равнозначные показатели. Значение в 16,6 мс появилось из формулы: 1000 мс / 60 Гц, оно отражает информацию о скорости отправки и получения данных между сервером и игровым клиентом. Именно это значение пользователь в итоге видел на своем экране. Оно привлекало внимание и неоднозначно интерпретировалось, поэтому теперь единицы измерения при переходе на герцы станут более понятными и очевидными для каждого игрока. В режиме PVE серверный TickRate составляет 30 Гц, а в PVP — 60 Гц.
Также вы можете ознакомиться с этой информацией в видеоролике.
Источник
Тема: О тикрейте, ССС, СПД, задержке урона и немного о макросах.
Опции темы
Поиск по теме
О тикрейте, ССС, СПД, задержке урона и немного о макросах.
Последнее время стали часто появляться темы про задержку урона, влиянии СПД, о том как вычислить макрос и т.п. Я просто хочу дать немного информации для обсуждающих, которую выявили мои друзья и я. Я правда надеялся, что такую тему в итоге создаст кто-то из моих более авторитетных и велеречивых друзей, но к сожалению текущие проблемы ВФ охладили их интерес к этому проекту и желания что-то выяснять пропало. Но если у них будет желание — они отпишутся в этой теме.
Еще раз повторю — тема чисто информационная, обсуждать наверное здесь ничего не стоит. И так начнем.
1. Путем несложного подсчета количества udp пакетов поступающих в адрес процесса game.exe мы выяснили, что от сервера клиенту приходит 19 пакетов в секунду, от клиента серверу отправляется 25 пакетов в секунду. На основании этого я сделал вывод, что тикрейт сервера равен 19.
Update 07.02.2017. По информации от нашего нового товарища установлена схема 20/30, которую тестировали с полгода назад. То есть все что нам втирал один небезызвестный КМ, что тикрейт сервера теперь не 20 — полная чушь. Он так и остался 20.
Для клиента: Параметры «По умолчанию(Альфа,Браво,Чарли)«: [Канал] Кол-во пакетов в секунду = 30 [Клиент] Скорость передачи пакетов = 30 Параметры «Лан(тот же опенкап)»: [Канал] Кол-во пакетов в секунду = 100 [Клиент] Скорость передачи пакетов = 100
Для сервера: Параметры «По умолчанию(Альфа,Браво,Чарли)»: [Сервер] Максимальная частота обновления выделенного сервера = 20 [Канал] Кол-во пакетов в секунду = 20 [клиент] Скорость передачи пакетов = 20
Параметры «Лан(тот же опенкап)»: [Сервер] Максимальная частота обновления выделенного сервера = 100 [Канал] Кол-во пакетов в секунду = 100 [клиент] Скорость передачи пакетов = 100
Мне тут товарищ в ютубе написал. Заинтересовался какой прогой я отслеживал входящие / исходящие пакеты. В общем замерил он вчера по моей методике. опять вернулась система 19/25.
То есть они полностью откатили обновление с улучшением сетевой синхронизации. Печально. А я еще думаю, чего это меды опять такие опасные стали :-), а мы оказывается просто вернулись к обновлению, где было чисто улучшение урона с дробовиков.
Update 01.11.2015 — «Обновление с зомби и улучшенным сетевым взаимодействием»
Что изменилось: на текущий момент количество отправленных и полученных пакетов уравняли. Их стало по 27/27 в каждую сторону (раньше было 19/25).
Размер пакетов от сервера клиенту вырос — самый маленький пакет 100 байт, самый большой 1000 байт. То есть взаимодействие клиент-сервер явно улучшили.
Чего мы не знаем: мы не знаем изменился ли внутренний тикрейт сервера.
Что ухудшилось: сервера игры похоже явно не справляются с возросшей сетевой нагрузкой и обработкой большего количества информации. Тут одновременно наложились два фактора — увеличение размера траффика и каникулы у школьников 🙂
2. Со мной несогласен один (точнее одна) из моих самых авторитетных друзей. В своих подсчетах тикрейта она использует данные по минимальной задержке прохождения урона (визуально это отображается как разница между уменьшением счетчика патронов на один и появление креста урона). Подсчет производился на основании видео от четырех- и однопалочника. Минимальная задержка получения информации об уроне — около 100мс, средняя задержка — около 150мс. Максимальная задержка достигала уже значений около секунды, но это все-таки было редко. На основании этого был сделан вывод что тикрейт сервера приблизительно 1000мс / 100мс = 10. Эта версия отличается от моей, но обе имеют право на жизнь.
3. Еще одна, более свежая точка зрения от нашего товарища, основанная на внимательном анализе видео:
Итоги анализа исходников тестов от Толи(Монтера).
Информация предварительная, основанная на статистике 1 теста, чтобы доказать ее содержательность нужно будет сделать большую выборку- провести больше тестов.
Итак что мы имеем: 1.Обмен информацией с сервера идет в 4 потока(предварительно)
1 поток- информация о том как друг друга видят противники (о правильности нанесения урона) 2 поток- информация о начале и конце какой-либо анимации персонажа 3 поток- информация о том на сколько игрок повернут. 4 поток- информация о координатах местоположения игрока в пространстве по осям X/Y/Z. И сервер может задавать этим потокам различные приоритеты.
2. Номинальный тикрейт сервера- 10 (1 точка синхронизации в 100 мс)
В случае «правильной» перестрелки, а конкретнее с подтверждением клиентов всех участников перестрелки, видимости прострела, 1 и 4 поток получает приоритет реального времени для сервера(обмен информацией с сервером идет во много раз чаще). 2 и 3 потоки остаются с номинальным приоритетом. На анимацию противника нельзя ориентироваться вообще.
3. Работа систем сглаживания пока не ясна, нужны дополнительные тесты. Но по факту 3 палочник отображался у 5 палочника с задержкой в 2-е меньшей, чем наоборот (5 палок у 3 палок). Скорее всего то как тебя будет видеть противник- воля случая. А конкретно на сколько близко к точке синхронизации ты сделал свое движение и с каким ускорением.
4. Урон засчитывается ТОЛЬКО ТОГДА, КОГДА ОБА ПРОТИВНИКА ВИДЯТ ДРУГ ДРУГА. Если быть точнее, только если клиенты обоих игроков подтвердили что противник находится на простреливаемой части.
5. Сервер, в зависимости (скорее всего) от загруженности ресурсов, может ставить информацию от клиента игрока в очередь, которая спокойно может достигать 1 и более секунд.
6. Корректировке конфликтов подвергается только поток 1 и 4. (информация о простреле и информация о местоположении) Информация об анимации персонажа, о том в какую сторону повернут игрок, как он держит оружие НЕ КОРРЕКТИРУЕТСЯ СЕРВЕРОМ МЕЖДУ 2 КЛИЕНТАМИ. Грубо говоря если у себя противник смотрит вам в живот, а у вас он смотрит в небо, перекрывая руками голову. То наносить урон вы будет по рукам, а не по голове, и серверу ПОФИГ что на самом деле ваш противник не поднимал руки.
4. Минимально комфортным играбельным тикрейтом я считаю значение — 30. И очень жду этой новости от разработчиков.
СПД (и немного об ССС)
1. Разработчик постарался по максимуму минимизировать объем информации от клиента-серверу и от сервера-клиенту. В результате размер входящих и исходящих пакетов очень маленький и только во время стрельбы в противника размер пакетов резко увеличивается (иногда более чем в 10 раз по сравнению с размером в то время когда ничего не происходит).
2. Вполне возможно что здесь кроется корень проблем, возникающих именно во время перестрелок. Канал не успевает перестроиться под бОльший размер пакета. Но это только предположение.
3. В связи с таким низким тикрейтом и малым объемом обмена информацией между сервером и клиентом основная нагрузка по отрисовке событий у вас на экране ложится на пресловутую систему предсказания движений (СПД), которая в перерывах между получением пакетов должна как-то отображать вам движения противников и союзников. Поэтому вероятность того, что противник находится именно там где вы его видите очень мала (примерно процентов 10) и вы начинаете стрелять туда, где противника нет, но к следующему тику (примерно 100мс) его положение синхронизируется с его реальным и если вы успеваете водить прицелом за перемещением противника, то вы таки его убьете.
Задержка прохождения урона
1. Первая причина. Несмотря на то, что для убийства бойца в превосходной броне из топовых моделей оружия нужно 4-5 выстрелов, что по времени занимает от 300 мс (для ктара например) до 500 мс (для ШВ из редкой ветки). Нам приходится выпускать от половины магазина до целого рожка. Происходит это потому что: сначала нужно чтобы модель игрока синхронизировалась с его хитбоксом — это 100-200мс, затем происходит регистрация попаданий — те самые 300 мс, затем задержка в получении информации об уроне (красный крест) — 100-300мс. В итоге мы успеваем выпустить 10-15 пуль вместо четырех. И если вы стреляете в прицеле — не надо забывать о времени вхождения в прицел — тайп например за что-то сильно обидели и время составляет 300мс в отличие от того же калаша, у которого 200мс.
Update 06.11.2015 Информация о синхронизации модели и хитбокса требует серьёзной проверки, поэтому прошу её не брать во внимание. По ощущениям и дополнительной информации от участников темы урон все-таки считается по модели противника, при этом только сервером проверяется, чтобы расхождение между моделью и хитбоксом не превышало заданной разработчиками дельты. И если дельта превышена, то урон не засчитывается. Эта проверка сделана видимо в первую очередь, чтобы не дать работать такому читу как «магнит», который «подтягивал» модельки противников к игроку и тот их убивал. Теперь это невозможно.
2. Вторая причина. Это лично мое мнение (мои друзья не с каждым выводом согласны). При обсчете урона сервер ждет получения сигнала от всех бойцов находящихся примерно в одном месте. Вдруг краснопингер убил вашего противника раньше чем вы, но сигнал от вас пришел быстро, а от краснопингера он плетется со скоростью черепахи. Поэтому задержка прохождения урона очень сильно зависит от того, находятся ли рядом с вами игроки с сильно отличающимся от вашего пингом. Как следствие расчеты из п.1 можно еще увеличить.
О макросах (точнее о том, можно ли их выявить по следам от пуль противника)
Должен вас огорчить — отправлять в ТП видео о том, что у противника был макрос, основываясь на следах от пуль на стене — БЕСПОЛЕЗНО.
По причинам описанным выше (малый размер пакетов и низкий тикрейт) направление стрельбы противника вам передается ПРИМЕРНО и соответственно при отображении еще накладывается результат работы СПД. То есть сервер вам сообщит только то, что противник стрелял ПРИМЕРНО ВОН В ТОМ НАПРАВЛЕНИИ.
Как следствие — следы от пуль (дроби) на вашем экране не соответствуют реальным следам от пуль противника и что-то там рассматривать, выискивая макрос не стоит.
Маленькое видео от Пушистой, сопровождающее наши эксперименты:
Последний раз редактировалось BearGentleman; 07.02.2017 в 23:53 .
