- Регистрация
- 17 Дек 2011
- Сообщения
- 1.196
- Благодарности
- 644
- Баллы
- 380
Дисклеймер
"Данная статья была обновлена 07.09.2024 чтобы быть полезным для новых мододелов, обновленные части будут помечаться * (звездочкой).
Потоки
Итак, начнем с того что знают все. Движок не умеет работать с потоками и ядрами, на этом можно было бы закончить. В официальной группе Paradox была даже статья об этом (Дневник разработчиков Stellaris №181 — Потоки и время загрузки), однако разработчики стремительно опровергают тезисы, высказанные в ней.Многие мододелы не согласны, но мы согласимся с данным утверждением разработчиков. Действительно, потоки работают если ты играешь на Linux ОС, никаких проблем с оптимизацией не возникает.
Также игра не умеет определять количество логических и физических ядер, и у всех имеется возможность ручного указания количество используемых потоков аргументом запуска -threads= (устанавливает верхний предел размера пула потоков, установка значения 1 — отключает). К сожалению, эффект прироста производительности при этом не наблюдается.
Есть интересная статья — клик
Мы согласимся с данным утверждением и для потоков, и для мультиплеера ( который идет дальше):
*По прошествии 4-х лет с момента написании статьи мы можем дополнить и заключить следующее.
Фактически, только лишь рандом отвечает на какой-же поток упадёт в конечном итоге нагрузка.Это само по себе крайне критическое упущение, но есть один нюанс.
В данном случае особенно сильно страдают новые процессоры Intel из-за их ставки на Е-ядра.
Так как игровой движок не видит разницы, следовательно, основная нагрузка может упасть на Е-ядро. С этого оно будет вешаться, ведь это не его задача.
Intel выпустили соответствующее программное обеспечение для разработчиков приложений и ОС (Windows и Linux) что позволяет определять тип ядер и выделять нагрузку на них отдельных процессов, в итоге на одном ядре и на одном потоке будут голодные игры между HOI4 и всех остальных не основных процессов. Следов попыток добавления библиотеки интелла не нашли.
Замечали как в рандомный старт игра начинала работать особенно плохо? Это оно самое. По итогу, вам (владельцу такого процессора) нужно выключать E-ядра и работать на исключительно Р-ядрах, либо, выключать игру и запускать с надеждой что проблема не повторится вновь.
В данном случае AMD оказались менее подвержены этой проблеме, так как они продолжили выпускать процессоры с очень большим количеством полноценных ядер, что дает им преимущество в многозадачности.
И да, игра теперь действительно может определять количество ядер и потоков.
Кстати, ещё на момент написания этой статьи мы заметили один интересный нюанс, который тогда не указали. Если сравнивать с более старыми версиями HOI4, во время загрузки игры складывается впечатление, что распределение нагрузки на процессор изменилось. Это заметно в момент, когда подгружаются игровые ресурсы: начинают задействоваться рандомные потоки, и усреднённая нагрузка на ЦП значительно возрастает. Такое перераспределение нагрузки связано с решением разработчиков перенести её на случайный поток, однако проблема этого подхода в том, что реальный прирост производительности ощущается только на этапе загрузки игры.
А таких стадий всего лишь две: первая — когда загружаются основные данные игры как платформы, и вторая — когда подгружаются игровые скрипты.
Из того, что удалось заметить, задачи вроде обработки 3D-ресурсов, сохранений, графики из раздела gfx, а также нагрузка от игровых скриптов могут перемещаться на разные потоки, что теоретически должно улучшить распределение нагрузки.
Мультиплеер
Тут мы разделим на две причины:1. Отсутствие серверной версии игры в виде CLI.
Суть проблемы очевидна: необходимость в дедик-версии сервера для игры в HOI4 без нагрузки на машину хоста. Это критично, ведь в текущем подходе хост не только выполняет расчеты за всех, но и вовлечен в игру, что снижает производительность. Выделенный сервер мог бы обрабатывать весь игровой процесс на VDS/Dedicated Server, освобождая ПК игрока от задач по расчетам.
К тому же, это решение значительно повысило бы надежность игры, потому что в инфраструктуре большинства хостинг-провайдеров качество интернет-соединения куда выше, чем у типичного пользователя. Это снизило бы возникающие сетевые проблемы, улучшило бы устойчивость игры к рассинхронизациям и повысило общий комфорт при игре с большими партиями.
2. Синхронизация и алгоритмы при плохом интернет соединении.
Точнее его алгоритм работы синхронизации и решение рассинхронов. У Paradox это выглядит очень нелепо в плане синхронизации, т.к. исследуя как ведет игра при различных статусах интернета и возможности пропускной способности обнаружено, что сервер (или хост) будет замедлять у других для попытки синхронизации времени, хотя это очень губительно влияет на остальных игроков, иногда это может привести обратному эффекту, когда из-за замедления игры может произойти так, что на сервере будет получена критическая ошибка из-за неверного просчета из-за замедления.
При этом, каждый игрок используется в качестве сервера и все данные передаются друг другу, а значит, что в случае краша у одного, это может вызвать краш у всей цепи. За примером далеко идти не надо, старая хойка и Виктория 2 страдают данной проблемой.
Мы думаем, что стоит перенять опыт от … Factorio! Эта игра пример, где происходит гораздо больше вычислений, чем в HOI4, т.к. все имеет очень много параметров, но при этом в МП является очень оптимизированной и шустрой.
Пример:
1 миллион 113 тысяч сущностей, которые обновляются 60 раз в секунду. Каждая из этих сущностей имеет свою логику. И самое главное — оно совершенно не тормозит. Игра обрабатывает миллионы объектов (а у некоторых людей и миллиарды) каждые 16 мс и при этом она играбельная.
Если вы захотите прочитать как работает мегапакет в Factorio — есть отдельная статья на хабре.
*По прошествии 4-х лет
По всей видимости, разработчики, либо в спешке, либо без особого энтузиазма и вдохновения, решили на скорую руку переделать поддержку сетевых игр. Точных утверждений делать не будем.Paradox открестились от такого чуда, как Metaserver. Те, кто не застал эту причудливое и неработоспособное чудо, скорее всего не в курсе, что игра изначально разрабатывалась с её поддержкой. Но потом, когда в 2014-м году было принято окончательно закопать Metaserver (момент его отключения), разработчики поспешили переделывать систему.
Начнем с разборки того, что косвенно указывает на подобное. Ведь до HOI4 была EU4, которая тоже не поддерживала Metaserver.
- Интерфейс сетевых игр состоит из listboxType что Paradox использовали до изобретения gridBoxType.
- В интерфейс состоит из инжекта игровым движком из двух разных интерфейсов - matchmaking и frontendmultiplayerview. Без второго невозможно в принципе указать ник игрока, подключиться по ID, узнать чек-сумму и будут отсутствовать диалоговые окна подключения.
- Отображение серверов происходит сугубо при нажатии на «Обновить» что служит указателям для pops_api.dll, отправляется запрос на сервер PDX где выгружается список рабочих в данный момент серверов. (Особенно касается реализации на основе Nakama, при обычном использовании используется Steam SDK для связи между пользователями)
- Кнопка «Хост» (она же «Создать сервер») отправляет запрос на сервер PDX, после чего происходит регистрация и сервер выдает уникальный ID.
Особо любопытен момент подключения через ID, при котором функция в коде называется ConnectToIP. Это вызвало отдельные вопросы, и когда мы принялись отслеживать, как именно игра подключается к серверу, выяснилось следующее: игра открывает туннель через сервер PDX, а затем через него подключает игрока к сетевой сессии. Peer-to-Peer подключения в игре отсутствуют, что, с одной стороны, хорошо, но с другой — не лишено проблем. Проблемы с задержками и потерями пакетов оказываются критичными.
Paradox использует client-server architecture что хорошо и плохо.
Вопрос не в самом подходе, а в его реализации. О проблеме, собственно, говорили уже четыре года назад (см. выше): игра синхронно работает у всех участников, каждый получает данные от других игроков, и эти данные проходят взаимную валидацию. Если возникает Packet Loss или ошибка валидации – система выдает исключение и (раньше) приводит к крашу клиента. С годами разработки Paradox поправили краши при таких ошибках, разработав даже отдельную систему для рассинхронов (о которой будет сказано позже).Есть одна загвоздка. Обычно на сервере лежит главная роль в валидации: если данные не совпадают с теми, что на сервере, они просто отклоняются, а сервер принудительно корректирует результаты у клиентов.
Но в системах Paradox дело обстоит не так. В их играх каждый игрок действует как сервер, валидируя и обрабатывая данные всех остальных.
Кажется, это должно полностью исключить возможность читерства, верно? Но, как показывает практика, не все так просто…
Проблема заключается в том, что интернет — штука ненадежная. Всегда найдется кто-то, кто решит постучать молотком по сетевых кабелях в Красном море, или начнется тектоническое движение плит, солнечные вспышки — и все это так или иначе скажется на соединении. Результат? Подключение становится неустойчивым, и неизбежно происходит тот самый Packet Loss из-за малейшего сбоя. Даже тормоза на стороне одного из игроков могут вызвать проблему, когда потерянный или задержавшийся пакет приведет к рассинхронизации. Как конкретно Paradox справляется с этими проблемами — остается загадкой.
Так что спустя 4 года, мы можем постановить что по-настоящему безграмотные тут оказались мы сами, без вариантов.
Действительно, теперь становится понятно, почему Paradox затронули вопрос синхронизации при различной производительности у игроков. С такой сетевой архитектурой возникает необходимость буквально синхронизировать такты выполнения процессов на разных машинах — любое отклонение нарушает работу системы.
Мы предлагаем решение: сделать основным управляющим звеном именно хост, и в случае обнаружения невалидных данных — просто удалять их, отправив корректные данные с хоста к клиенту-приемнику. Такой подход позволил бы расширить временной диапазон для последующей синхронизации. Принудительная синхронизация могла бы выполняться нативно, касаясь только невалидных данных, без необходимости останавливать игрой процесс.
Интересно, что в коде игры и в локализации есть соответствующие строки, которые, по идее, должны выполнять такие функции. По неизвестным причинам они не работают. Возможно, потребуется детальнее проанализировать, как настроена эта часть архитектуры.
Отсюда вытекает другая проблема: чем больше участников в игровой сессии, тем больше точек отказа возникает. Это делает невозможным проведение крупных мультиплеерных партий.
Читерить можно, если знать как и уметь.
Если открыть консоль и ввести команды, влияющие на мир, это вызовет моментальное нарушение синхронизации игры для всей сессии. Засилье читеров в МП, вой на форуме из-за этого, последующие попытки ПДХ хоть как-то исправить ситуацию не улучшили. Как итог, мы имеем почти мертвый мультиплеер для такой игры.В придачу, если знать как, то можно скрашить игру всем в партии кому угодно, при этом испортив сохранение сетевой игры, что приводит к окончанию сессии. Не нужно для этого буквально ничего, спасает от такого только конкретное число людей, закрытое лобби на пароль и соответствующее неразглашение публично пароля.
Сломанный локализатор рассинхронизации.
Во всяком случае, мы надеемся что лишь локализатор.Дело в чем, в данный момент игра умеет распознавать 89 точек (причин) рассинхронизации, но в случае рассинхронизации мы получаем огромный щитпост из всех причин.
Связано в основном это, что некоторые данные являются источником для расчета других данных. Для примера есть те же очки опыта армии, флота и авиации, если выдать через консоль игры в текущей сессии, то причиной будет только количество очков опыта, а если вы за эти очки приобретаете доктрины или прокачиваете генералов, то это сразу пишет все точки отказа.
И да, дедик сервер для HOI4 существует в природе.
Мы много думали, что из себя в принципе представляет, зная то как устроена архитектура, было 2 рабочие версии: это полноценный сервер, без GUI, чтобы тестировать сетевую игру, либо, это сервер поддержки сетевого интерфейса лобби.И, вообщем, вот.
Теперь ответ есть, это полноценный мп
Прикольные приколы в коде прикольного игрового движка.
Как известно, Paradox не имеют единого стиля кода, в одних случаях они используют генерацию, в ином случае пишут самостоятельно, на момент редактирования статьи только игровые скрипты уже насчитывают 8 разных стилей кода.Не то чтобы кодовая стилистика была особо критическим, но как показывает кровавая практика, если отсутствует единый стиль кода то отсутствует и единое планирование и интеграция, по итогу, мы имеем следующие приколы.
В игре в данный момент существует 4 типа консольных кодов, точнее, кодов для разработчиков. Четверть из всего количества недоступны, мы не будем разбирать вопрос почему та или иная команда не доступна, там логики и здравого смысла нет, мы лучше разберем их реализацию.
Например, есть следующие приколы:
| Command available only for developers | consolecmdmanager.cpp |
| Dev only | ConsoleCmdImpl.cpp |
В общем, почему мы прикопались? А проблема в большей своей именно во второй реализации, не знаем чем думал этот человек, но это просто апофеоз гения на зарплате, проблема в том что вместо нормальной реализации с одной лишь проверкой, мы имеем 4 вида проверки при разной реализации каждой.
1 из 2
Это то что заставляет очень много подумать о качестве профнабора в команду разработчиков, но это не самое худшее. Если вы умеете читать этот код то вы уже видите очень большой прикол.
Конечно, можно частично списать на сборку компилятора и его оптимизации, но двойная реализация класса, отвечающего за обработку консоли - это гениально.
Человечек под псевдонимом Bitmode нашел и написал статью которую никто так и не разбирал в сообществе (ни в каком в принципе, мы видели лишь активность от него).
В игре мододелы знают о существовании параметра как NGame.GAME_SPEED_SECONDS что записан в defines.lua
| Состояние | Значение |
| Скорость 1 | 2 секунды |
| Скорость 2 | 0.5 секунды |
| Скорость 3 | 0.2 секунды |
| Скорость 4 | 0.1 секунды |
| Скорость 5 | 0.0 секунды |
Так как игра не может отобразить кадр и одновременно перенести внутриигровое время на следующий час. То мы имеем приколы с чередованием рендеринга кадров с игровыми вычислениями.
- Игровой час, только что завершившийся имитацией, визуализирует кадр для отображения нового состояния.
(Рендеринг в действии) - Следующий игровой час пока не планируется моделировать, рендеринг кадров по желанию.
(Рендеринг в простое) - В несколько десятков точек во время моделирования кадры можно визуализировать по мере необходимости.
(Сглаживания кадров)
Но как вы заметили по контексту, третья категория не задета, что собственно не просто так, в игре мы имеем по умолчанию включенный флаг сглаживания кадров, а у него есть своя особая логика что жестко зафиксирована игровым движком.
| Состояние | Время рендеринга |
| Пауза. Скорость 1-2 | 16.6 мс. (60 FPS) |
| Скорость 3-4 | 33.3 мс. (30 FPS) |
| Скорость 5 | 50 мс. (20 FPS) |
Таким образом, хотя сглаживания кадров способно отображать до нескольких десятков дополнительных кадров во время одного моделирования, оно будет работать только в этой степени, которая достигается эта более низкая частота кадров.
Т.е, используется элементарная логика if_else, если игра видит понижение FPS (Игра не видит счетчик, она видит время рендеринга, здесь обратная логика) на определенной скорости ниже определенного значения, то игровой движок начинает замедлять свою работу.
В коде это выглядит так:
Мы специально реализовали и написали в виде кода хойки с определенными поправками для комичности
Что любопытно, вы можете по сей день (если откатитесь на более старую версию игры, вы можете отредактировать эти значения на любые иные если модифицируете движок при помощи любой IDA. Вам нужно поменять значение в gGameSpeedRenderInterval (именно потому мы использовали это значение в смехуёчке).
К слову, при необходимости, вы можете отключить этот сегмент весь в принципе командой debug_smooth в консоль. Скорость игры увеличится, но есть нЮанс.
Вы не сможете поменять самую извращённую логику, ведь логика такова что игра диктует производительность обращая внимания лишь на значение рендеринга, а не подстраивается под производительность системы. Тут получается порочный круг, когда игра начнет замедляться даже не по общему знаменателю
Отдельно хотелось-бы отметить выбранное удивительное значение в 50 мс, что равна 20 кадрам. Особенность кадра в том что игра может свободно опускаться до значений 12, так и 27. Мне кажется что разница будет крайне ощутимой, не так страшна потеря 7 кадров на 60 фпс как на 20, лучшее что может быть так установление 30 кадров чтобы хотя-бы избежать слайдшоу.
Весь этот участок крайне, крайнЕ сильно напоминает HOI3, ведь там тоже можно получить на современной системе слайдшоу.
В итоге игра будет постоянно влетать на 5-й скорости в условия исполнения кода, а движок видя это значение будет жестко замедлять игру. Не плавно, жестко, в этом и есть беда. Плавающее значение в данном случае будет лучше.
За счет подключенных библиотек игра может получить всю нужную информацию о железе.
Сингплеер
А одиночная игра ничем от мультиплеера не отличается. Все так называемые одиночные игры есть ничто иное как мультиплеер на одного человека.* Всем по morehumans посоны.
Сохранения
Перейдём к проблеме сохранений, даже в оригинальной игре сохранения создают определённое провисание на несколько секунд, особенно сильно подобное чувствуется в масштабных модификаций, например нашей.Обратим внимание, что Paradox обещают улучшить процесс сохранений, мы действительно видим качественное улучшение системы сохранений по сравнению с 1.5 версией.
Корень проблемы мы сможем увидеть в самих сохранений, если отключим бинарный формат настройкой save_as_binary=no
При ручном сохранении сразу бросается в глаза гигантский вес сохранения — 36мб при бинарном формате, 59мб без него.
Итак, перейдём к рассмотрению файла.
Игра сохраняет каждую пустую провинцию. Мы видим максимально нерациональное использование мощностей. Почему бы не записывать провинциям значение null по умолчанию, а сохранять исключительно те, что были изменены? В данных строках сохраняются все постройки и значение «очков победы», но зачем сохранять даже пустое значение?
А теперь перейдём к более интересным находкам.
Игра сохраняет каждую технологию для каждой страны. Казалось бы правильно, однако куда рациональнее было бы единожды вводить тэг технологии и вносить все страны, которые её изучили. Сейчас же игра создаёт по блоку для каждой технологии каждой страны, это щитпост на миллионы строк. В нашем моде 360 стран, а значит 9 строк будет дублироваться каждой страной.
Подобные строки мы даже не будем комментировать.
Очередная проблема подобного характера, касающаяся и флота ( проблема пустых { } )
А почему путь к лидерам прописывается? Зачем тогда игровые ресурсы?
Поэтому мы надеемся, что Paradox исправит данные недоразумения и сделает вес файлов сохранений еще меньше, а пока что сейвы являются большим больным местом, где явно можно было сделать сразу лучше.
*По прошествии 4-х лет хотелось-бы указать что сохранения становятся лучше, работа действительно выполняется, однако, проблема пустых скобок все ещё сохраняется.
Однако, если вы хотите попытаться расшифровать бинарный сейв, то предлагаем вам хоть уже устаревший но более чем достаточно для продолжения наработок вариант.
Моддинг
А точнее, его формат. В моддинге отсутствует компиляция, как подсказывает Википедия, компиляция — это «трансляция программы, составленной на исходном языке высокого уровня, в эквивалентную программу на низкоуровневом языке, близком машинному коду (абсолютный код, объектный модуль, иногда на язык ассемблера), выполняемая компилятором». Все мододелы пишут на высокоуровневом языке, однако PDX в реальном времени преобразуют код в набор команд и выделяемое ОЗУ это подтверждает. На момент запуска диспетчер задач выделяет HOI необходимое количество ОЗУ, в нашей модификации запрос составляет свыше двух гигабайт.Переполнение пула
Скажите, вы встречались с тем что у вас число населения, или ресурсов, или ещё чего уходило в минус, хотя мгновение назад было с запасом? Думаю часто.Европа
Это очень частая напасть, и она встречается во всех играх PDX. Помните Ганди из цивилизации? Абсолютно тот же тип проблемы.
Хойка
Частично, Paradox это поправили — частично, но у скриптеров с этим проблемы никуда не делись. И ничто не предвещает того, что что-то изменится. Данной проблеме больше шести лет.
У населения, это 2.100 миллиарда, у техники это 2.7 миллиона. В случае, если ваши скрипты считывают население, или, считывают иной тип переменной, вы имеете очень большие шансы об это пострадать.
Почему это так страшно?
Чем больше алгоритмы натыкаются на подобные места, тем больше проблем это может вызвать, вплоть до просадок FPS. Простой краш будет самым лучшим исходом.
*Также, есть любопытный момент как это встречают игроки, как все мы знаем, игровая карта не может быть больше Х, но что если мы добавим 2 ряда?
А получится то что игра в попытке срендерить игровую карту получает оверпул, игровой движок замечает некорректные данные и запускает процесс вновь.
Получаем цикл загрузки.
????????
Profit!
К слову, данная ситуация была доложена разработчикам ещё в 20 году. Думоем.
DirectX
Страшно подумать, но HOI4 по сей день не умеет в более новый DirectX, а в новый DirectX по традиции, завозят хорошие инструменты по оптимизации, притом, с возможностями улучшить картинку без какого-либо вреда для оптимизации.Командой rendertype в консоли игры можно узнать тип рендера.
*Спустя 4 года
Ситуация стала лучше, от части но лучше, также, в игре замечены следы попыток внедрить Vulkan. В данный момент в игре есть лишь DirectX и OpenGL, в рендере Вулкан не участвует, встречается массово лишь в одном моменте, не известно как дальше будет, однако, что встречается:MoltenVK (привет нормальная поддержка на Mac, после того как Apple убили OpenGL ради нового Metal API).
Vulkan (Придет нормальная поддержка на Linux).
Определение ОС
Да, это не пранк. Независимо от того, у вас стоит-ли Windows 8.1, Windows 10 любых ревизий, и, даже Windows 11, игра определяет вашу систему как Windows 8.
*Спустя 4 года.
Игра научилась определять ОС, сначала отдельно через логи, создаваемые при краше игры, то теперь непосредственно сразу (setup.log). Но не без приколов, она не умеет определять тактовую частоту процессора и версию видеодрайвера.Вывод:
К сожалению, движок хойки дико устарели и находятся на этапе 2003-о года и 2007-о года.Скриптеры очень много трудятся над, тем чтобы попробовать ускорить игру, однако, проблема не в их скриптах, они ничего не могут поделать и как-то оптимизировать игру.
— Если покопаться в шейдерах и подправить определенные константы, можно улучшить ситуацию по оптимизации и рендеру, в любую из сторон. Если оформить это в мод то получится FPS-мод. Те что сейчас есть в мастерской просто заменяют текстуры на более простые что не добавляет FPS, не ускоряет загрузку и не облегчает использование даже ОЗУ. Текстуры хранятся в памяти самой видеокарты, что в играх PDX практически не используется.
В играх Paradox разница производительности у AMD Ryzen 5 1300 и Intel I7-8700 составляет всего 12%, в то время, когда реальная производительность I7 выше в десятки раз.
Мы не учитывали мелочи, сродни неиспользованных битов в bool типах, подобные масштабы в современности не играют никакой роли.
Скриптерам
Конечно, вы можете заморочиться и попытаться решать проблемы начала нулевых, базируясь на уменьшении проверок, урезании контента, и, ограничение всех операций ввода/вывода.
Это, может быть даст результат, в лучшем случае прирост на несколько процентов. Однако, проблема изначально не в вас. Исправив свои ошибки, Paradox смогут увеличить прирост в разы и сделать свои игры лучше.
В будущем мы хотим выпустить ещё одну статью с более фундаментальным пояснением."
Источник
Последнее редактирование:
