ИИ
Начнём с искусственного интеллекта. Мы не уделяли особого внимания ИИ, но нам всё же удалось добиться довольно немалого прогресса.
Мы заметили, что нередко ИИ тратил свои сплавы впустую, используя ошибочные логические циклы: он модернизировал звездные базы, а затем понижал их, или строил корабли, а затем распускал их. Мы улучшили логику в обоих случаях.
Что касается звездных баз, то теперь ИИ будет более разумно подходить к модернизации своих звездных баз в целом. Например, мы исправили логику, при которой он ошибался в подсчетах и считал, что превысил лимит, если в данный момент он модернизирует звездную базу. С другой стороны, теперь ИИ будет отменять модернизацию вместо понижения уже обновленной станции, а также будет рассматривать возможность понижения звездных баз при значительном превышении лимита во время тотальной войны. И он больше не будет спамить бастионами повсюду, а только там, где они могут быть полезны.
В версии 3.4 ИИ не строит оборонительные платформы. Теперь это исправлено, и ныне ИИ будет строить их только вокруг бастионов. Он также не очень хорошо использовал возможности орбитальных колец, теперь ИИ должен лучше их модернизировать и использовать только лучшие модули и здания.
Что касается кораблей, то теперь ИИ будет распускать корабли при превышении лимита флота, только если он действительно не может позволить себе их содержание. Это исправление заставило нас немного углубиться в изучение того, как работает бюджет ИИ, что привело к нескольким сопутствующим исправлениям:
Раньше можно было назначать ресурсы на расходы, которые ИИ активно игнорировал. Теперь это приводит к появлению ошибок в логе и больше не будет происходить.
Если мы указывали максимальное значение, которое ИИ мог назначить на определенную статью расходов, он ограничивал свои расходы этим значением, но не переназначал излишки в другое место. Теперь и это исправлено.
Результат очень заметен. ИИ часто сидел с лимитом в 60 тысяч сплавов, но только около половины этого могло быть израсходовано. Теперь такого больше не будет, и ИИ с гораздо большей вероятностью будет действительно тратить свои сплавы.
Ещё одно изменение, предназначенное для любителей минмаксинга, заключается в том, чтобы заставить ИИ понять, что цитадели — это хорошо. В поздней игре (когда ИИ начнет исследовать повторные технологии) он теперь будет считать желательными здания, увеличивающие лимит флота. Сначала ему нужно иметь солидный доход, так что это скорее всего произойдет на высоких сложностях, но в моих тестах он часто использовал более 4 тысяч лимита флота на гранд адмирале, тогда как раньше он использовал всего 1-1,5 тысячи.
В паре с этим ИИ стал более агрессивно строить мегаструктуры — особенно среды обитания и орбитальные кольца. У ИИ было несколько ограничений на строительство новых мегаструктур, например, он мог строить только одну за раз. В прошлом ему также было запрещено строить среды обитания при определенных обстоятельствах. Теперь большинство ограничений снято. Но часть разумных ограничений осталась: ИИ не будет строить новые среды, если есть места, доступные для колонизации. Аналогично, ИИ теперь всегда будет стремиться строить орбитальные кольца над планетами, если у него есть такая возможность. Ещё ИИ мог застрять кое-где. Например, он не строил новые мегаструктуры, если мог модернизировать любую из них, но это включало в себя и мегакомпозицию, для модернизации которой требуется большое количество малых артефактов, поэтому ИИ практически переставал строить мегаструктуры, если строил мегакомпозицию. Теперь это исправлено, хотя ИИ по-прежнему предпочитает экономить, чтобы модернизировать мегаструктуры, если это возможно.
В сообществе было много шума по поводу нескольких проблем с ИИ в 3.4, а именно: ИИ покидал федерации, потому что ему не нравились его вассалы, и ИИ слишком легко хотел стать вассалом. К счастью, мы смогли решить обе проблемы.
Что касается логики ИИ флота, то мы добавили определённую логику, позволяющую ИИ группировать свои флоты во время войн, так что теперь флоты ИИ гораздо реже простаивают без дела. Кроме того, мы улучшили работу преторинов по захвату колоний.
Кроме того, в войнах между империями ИИ, где ни одна из сторон не может победить другую, обе стороны теперь гораздо охотнее заключат мир. Это решает проблему, когда империи ИИ часто застревали в войнах на очень долгое время. И только при усталости в 100% они заключали мир. Это было особенно большой проблемой для геноцидных империй, у которых истощение войны растёт весьма медленно.
И, наконец, забавный момент: было замечено, что некоторые ИИ создавали анклавы наёмников, а затем немедленно атаковали их. Такого больше такого не будет.
Производительность
Теперь поговорим о производительности: я и еще несколько человек были не очень довольны производительностью поздней игры в Stellaris. Поэтому мы попытались сделать её лучше. И, честно говоря, результаты довольно многообещающие.
В общем, есть три способа улучшить производительность: исправить сложную логику, использовать кэширование и многопоточность. Но это не так просто, потому что у двух последних решений есть несколько неприятных друзей: кэш любит тусоваться с рассинхронизацией и просчётами, а многопоточность любит и вылеты, и рассинхронизацию. Но нам удалось продвинуться в решении различных проблем.
Прежде всего, обновление модификаторов было довольно непростым делом. Например, если вы включили указ, это приведёт к пересчету модификаторов на каждой планете, флоте, корабле и поселении, принадлежащем вам. В конечном итоге это приводит к большому количеству пересчетов, которые могут занять некоторое время, поскольку обновление модификаторов не совсем тривиально — в общем, приятные всплывающие подсказки у поселения, которые показывают, откуда взялись все эффекты, требуют достаточно большой вычислительной мощности.
В 3.5 есть два улучшения на этом фронте. Во-первых, мы сделали обновление модификаторов многопоточным. Раньше все это делалось последовательно, что могло привести к длительным зависаниям, а некоторые ежедневные тики занимали гораздо больше времени, чем другие. На то была веская причина — нужно было распутать множество взаимозависимостей и предотвратить вылеты. Тем не менее, это имело довольно большой эффект.
Кроме того, я заметил, что к поселениям добавляются модификаторы, которые не имеют отношения к делу, например, модификаторы стоимости мегаструктур. Поэтому в экономические категории был добавлен дополнительный параметр, указывающий на то, куда должны добавляться модификаторы, что в итоге сэкономило еще 20% времени при пересчёте модификаторов.
Помимо этого, довольно значительное улучшение произошло, когда мы заметили, что наша система многопоточности периодически даёт сбой и все потоки ожидают друг друга в течение нескольких миллисекунд. Из-за этого многопоточная обработка относительно быстрых операций в среднем выполнялась медленнее, и даже в тех случаях, когда это было целесообразно, она была медленнее, чем нужно. К счастью, наш технический директор смог спасти положение и остановить это безумие, что неизмеримо улучшило игровой опыт.
Это лишь малая часть того, что мы сделали. В основном, много времени было потрачено на анализ заведомо абсурдного сохранения игры — оно было настроено на максимальный рост населения, быстрый технологический прогресс, максимальный размер галактики и максимальное число пригодных для жизни планет, а затем запущено без кризисов и угасших империй вплоть до 2730 года. Игра немного подтормаживала (я имею в виду, что год занимал 11 минут), но оказалось, что главным виновником было движение авиации. Я не смог воспроизвести это ни на одном нормальном сохранении — вероятно, это происходит только во время битвы, а там, предположительно, происходили очень крупные сражения — но в любом случае, благодаря многопоточности, игра действительно стала несколько более быстрой.
Отсюда следовало, что можно было сделать множество постепенных исправлений. Например, игра тратила довольно много времени на выяснение того, есть ли в системе колонии, несколько раз в день — а это легко кэшировать. (Ну, я так думал. Два исправления рассинхронизации спустя я пожалел об этом). Другим крупным виновником были войны: у страны не было кэшированного набора войн, в которых она участвовала, и вместо этого она пересчитывала все войны, в которых участвовала, всякий раз, когда ей требовалась информация о любой из войн, в которых она участвовала. Излишне говорить, что это было довольно неэффективно, и, к счастью, вполне поддавалось кэшированию. Затем, всякий раз, когда игра выясняла, к какому типу относится звездная база (например, «Бастион») — включая каждые несколько кадров в планировщике — она просматривала все различные типы звездных баз и решала, какой из них здесь наиболее уместен. И кэширование тоже решило эту проблему.
Мы также сократили время, необходимое ИИ, чтобы решить, где создать филиалы. Затем мы заметили, что большая часть времени, затрачиваемого на обновление стран в последовательном режиме, уходит на оценку правильности их политики — а это можно перенести в потоковые вычисления. (Ну хорошо, это не так просто: мы смогли сделать вычисления потоковыми, кэшировать результат, а затем реализовать его в следующем последовательном обновлении, которое, по сути, будет сразу после этого). Наконец, ежемесячные тики должны стать немного быстрее, поскольку мы использовали схожую логику в расчетах того, какие поселения должны собираться, расти и уменьшаться, а также убрали около 50% пересчётов кэша во время автомиграций.
Не все было гладко — помимо как минимум трех рассинхронизаций и двух вылетов, которые были выявлены и исправлены в ходе этой работы, через некоторое время мы заметили, что игра работает не так быстро, как мы ожидали. Фактически, она временно зависала каждые несколько дней. Оказалось, это происходило потому, что ИИ очень тяжело задумывался, где разместить свои мегаструктуры. Это тоже было исправлено.
Как сильно всё это повлияет? Ну, я не могу обещать какую-то конкретную цифру по разным причинам. Во-первых, большинство этих улучшений было сделано в июле, и всегда есть вероятность, что за это время мы добавили новые не очень эффективные вещи. Также, в частности, из-за работы с ИИ, сохранение с версии 3.4 не очень совместимо с сохранением 3.5, так как ИИ будет вести себя совсем по-другому при создании этого сохранения (но с другой стороны, вы не можете загрузить сохранение из версии 3.5 в 3.4, потому что игра почти наверняка вылетит). Кроме того, в конкретном сохранении может быть что-то определённое, вызывающее лаги (например, упомянутая ранее проблема с авиацией, которая в других случаях казалась неважной). А иногда компьютеры просто темпераментны и направляют свои ресурсы на другие дела, а не на игру игры. Тем не менее, в последний раз, когда я проводил тесты на основе сохранений 3.4, игра работала более чем на 30% быстрее. В моей последней кампании поздняя игра не была быстрой (поздняя игра никогда не будет такой же быстрой, как ранняя — в ранней игре происходит так мало событий, что производительность в основном определяется скоростью рендеринга кадров), но она определенно кажется менее медленной. Но я с нетерпением жду, что подумают люди, и считают ли они, что нужно приложить больше усилий в этой области.
Моддинг
Наконец, по традиции, моддинг. Мы сделали несколько классных дополнений. Самое большое из них - встроенный скрипт: по сути, вы можете указать «inline_script = my_script» в ином месте игры. (Работает в большинстве мест, но не во всех). Тогда игра будет искать файл с именем «my_script» в common/inline_script и вставлять содержимое этого файла туда, где вы указали его использовать.
Это позволяет вам повторно использовать скрипт, поэтому вам придется делать меньше копирования-вставок, что очень радует. Особых проблем с производительностью нет, хотя при использовании в больших масштабах это может повлиять на время запуска и, возможно, на использование памяти. (К сожалению, я не проверял, что такое «особенно большой масштаб». Определенно, что от сотен использований всё будет в порядке. Но вот при сотнях тысяч всё будет работать медленнее).
Вторая важная вещь для моддеров — это профилировщик скриптов. Теперь он общедоступен с помощью консольной команды «script_profiler». Используйте её один раз, чтобы начать профилирование, и ещё раз, чтобы закончить и получить результаты. Теперь вы можете точно узнать, почему ваш мод вызывает проблемы с производительностью. Но стоит отметить, что его охват скриптов скорее 90%, чем 100%. И он не охватывает проблемы пользовательского интерфейса. Так что этот инструмент хорош, но не является панацеей.
Помимо этого, вот некоторые основные моменты:
Теперь вы можете использовать @ в целях события. То есть «save_event_target_as = something@root». Хотя имейте в виду, что это не очень хорошо обрабатывает точечную привязку и, вероятно, не сделает того, что вы хотите, если вы попытаетесь сделать что-то вроде
something@root.owner.
Теперь вы можете вставить пользовательскую подсказку custom_tooltip для планетарных особенностей. Так они смогут иметь пользовательские эффекты, которые отображаются всякими красивыми способами.
Исправлены некоторые проблемы, из-за которых вы не могли создать Ситуацию с конечным значением, не равным 100. Теперь вы можете расширять их до бесконечности, а точнее до максимальных границ наших фиксированных точек.
Добавлены модификаторы «country_naval_capacity_contribution_from_subjects _mult» и «country_naval_capacity_contribution_to_overlord_m ult», которые передают часть вместимости флота подданного сюзерену, не уменьшая вместимость флота подданного. Обратите внимание, что эти модификаторы не должны быть отрицательными.
Добавлен эффект, позволяющий сделать лидера бессмертным, а также триггер, проверяющий, является ли лидер бессмертным
Добавлен триггер «has_forbidden_jobs», который проверяет, есть ли на планете деприоритизированная работа определенного типа.
Добавлен список скриптов для «owned_nonprimary_starbase», так как «owned_starbase» возвращает только первичные звездные базы (поэтому орбитальные кольца там отсутствуют)
Добавлены значения ширины и плотности для поясов астероидов, что дает возможность большего контроля над ними, если по умолчанию не установлено значение 1.
«check_economic_production_modifier_for_job» теперь правильно учитывает срабатывающие модификаторы производительности поселений от черт (особенно рабочих/специалистов/рабов). Это также теперь должно работать немного быстрее.
Исправлен модуль звездной базы «on_finished/aborted/queued/unqueued»
Модификаторы минимума и максимума пригодности теперь могут быть применены непосредственно к планете (а не только к виду)
«modify_species» теперь корректно позволяет указать несколько записей «add_trait» или «remove_trait»
Теперь можно использовать скриптовые значения в локализации, определяя их как значение в скриптовой записи локализации
Добавлен эффект, позволяющий установить/обновить настройки флота после его создания.
