[Сулариус]

Дополнение Nemesis выйдет 15 апреля! https://www.youtube.com/watch?v=xPrpQOJqA38

Дневник разработчиков Stellaris №203 — Спецэффекты в Nemesis

Скрытый текст:

Всем привет!

Меня зовут Эрик Форсстрём, и с релиза дополнения Lithoids я работаю в команде Stellaris художником по визуальным эффектам. Я отвечаю за всё, от небольших эффектов двигателей кораблей до целых систем, таких как туманности, которые мы добавили в игру в прошлом году. Если что-то двигается и не является 3D-моделью, то с высокой вероятностью это результат работы художника по визуальным эффектам.
Чем занимается художник по визуальным эффектам?

Мой рабочий процесс не такой, как у других художников, потому что по сравнению с 3D-художниками я обычно не работаю с 3D-моделями. Мой главный рабочий инструмент — частицы, которые по большому счёту представляют из себя плоскости, из которых я создаю крутые взрывы! Не буду углубляться в технические нюансы использования частиц, но попробую создать у вас представление о разнице между работой художников по визуальным эффектам и других: в то время как 3D-художники придумывают и создают 3D-модели, я занимаюсь симуляцией плоскостей, их движением, изменением размера и цвета со временем. Не могу сказать, что никогда не работал с 3D-моделями, но, как я упоминал ранее, они не являются моим основным рабочим инструментом, что видно из примеров ниже.

Всяким классным и интересным!

С деталями разобрались, время перейти к эффектам, которые мы добавим в Nemesis!

Начнём с кораблей. Я стремился с помощью эффектов сделать разные наборы кораблей более уникальными. Некоторые из вас заметили, что корабли литоидов и некроидов отличались особенными эффектами, начиная с двигателей и заканчивая взрывами. Я старался придать им всем хоть немного различный вид, и в то же время подходящий под общий стиль кораблей.

Обычно я использую разные формы, цветовые схемы или ещё что-нибудь интересное, что удаётся придумать, чтобы они выглядели неповторимо и в то же время однородно.

Большие, можно сказать, системные эффекты!

Ещё вы могли заметить, что за прошедший год мы добавили множество разных эффектов в системах, вроде туманностей, космических бурь и эффектов для систем, которыми владеет кризис конца игры. Мне всегда именно этого и не хватало в Stellaris — системы казались пустыми. В Nemesis мы добавили ещё несколько эффектов в системах, например, для каркаса эфирофазной установки, который мы упоминали в одном из предыдущих дневников.

Когда вы его улучшаете, эффекты в системе меняются от уровня к уровню, становясь всё масштабнее и мощнее на более поздних этапах. Я немного начитерил с ресурсами в скоростью строительства в видео ниже, чтобы показать вам это во всей красе, и вы можете воочию увидеть, как эффекты меняются на разных этапах строительства. От довольно жиденьких спецэффектов до мощных и накрывающих всю систему, со множеством деталей, обилием форм и движения, чтобы у вас по-настоящему создавалось впечатление грандиозности происходящего.

Как они создаются?

Системные эффекты — одни из тех эффектов, которые зачастую создаются путем смешения частиц и 3D-моделей. Их значительный размер требует более сложных фигур, чем можно создать с помощью одних только частиц. Эффект ниже создается с помощью мешей, которые видны на картинке ниже, после чего я применяю анимированные шейдеры. Таким образом создается движение текстур, которое можно наблюдать на видео. Добавьте частиц и получите готовый, полноценный эффект!

Уничтожение звезды

И моя любимая часть Nemesis! Уничтожение звёзд!
Процесс состоит из нескольких частей. Подготовка в основном представляет собой анимацию Пожирателя Звёзд со свечением посредине. Затем начинается этап выстрела — тут эффект довольно крупный. Как видите, мощность выстрела нарастает со временем и накапливается, пока не происходит большой взрыв.
На ранних этапах мощность сразу была максимальная, что выглядело круто, но не создавало ожидания выстрела. Вы смотрели на крутой эффект в течение «всего» 20 секунд без какого либо развития и без возможности понять по одним только спецэффектам, сколько ещё осталось до выстрела.
В конечном счёте мы решили разбить эффект на несколько этапов, кое-что добавить, кое-что переделать, чтобы в итоге вы буквально ощущали приближающийся взрыв звезды.

И последнее, но оттого не менее важное — сам взрыв звезды. Буду краток, поскольку взрыв не нуждается в пояснениях. Добавлю лишь, что это один из моих любимых, а возможно и самый любимый эффект из добавленных в игру.

Надеюсь, вам он понравится не меньше!

И на этом у меня всё! Надеюсь, теперь вы лучше представляете, чем и как я занимаюсь. Спасибо, что прочитали!

На следующей неделе контент-дизайнер расскажет об улучшении скриптов в обновлении!

Дневник разработчиков Stellaris №204 — Язык скриптов и улучшения для моддинга

Скрытый текст:

Всем привет! С вами Caligula, здешний волшебник скриптовой магии. Я тесно работаю с нашим языком скриптов, ежедневно используя и улучшая его, а потому невероятно рад показать новые возможности, которые моддеры (и мы сами) смогут использовать после выхода следующего обновления.

Сперва пробежимся по новым особенностям.

Шпионаж: моддеры могут добавлять новые операции, почти как археологические раскопки.
Первый контакт: всё по скриптам, так что моддеры могут менять большую часть этой системы. Однако все первые контакты теперь являются одной длинной цепочкой событий, поэтому перезапись может стать проблемой. К счастью, чтобы сгладить её, у нас появился новый эффект fire_on_action, который мы теперь кое-где используем.
Стать кризисом: особенности кода, например, интерфейс, целиком завязаны на скриптах. Поэтому в теории можно создать полностью новую систему какого-либо развития и достижения цели, если это будет нужно в моде.
Император и хранитель: эта особенность создана самым опытным контент-дизайнером студии. Вместе с ней добавилось множество сопутствующих улучшений скриптов, таких как повышенная гибкость резолюций Сообщества и возможность создавать флотилии федерации и Сообщества через скрипты.

Будет очень интересно посмотреть, что моддеры с этим сделают, но со времён выхода 2.8 мы сделали ещё очень много всего, так что...

Основные улучшения и стандартизация

Не совру, если скажу, что язык скриптов Stellaris постепенно растёт в соответствии с ростом наших нужд. Это и не удивительно, ведь игра сама стала намного обширнее. Но в этом есть ложка дёгтя, ведь с проектом работает много разных людей, и неизбежно появляются несоответствия между разными особенностями. С точки зрения пользователи это может выражаться в том, что нечто работает в одном месте, но не работает в похожем другом.

Для будущего обновления мы уделили время, чтобы целостно взглянуть на картину и внести некоторые общие улучшения и стандартизацию.

Первым выиграло от этого то, что мы называем «скрипт-листами». Это система кода, которая создаёт объекты с припиской random/every/any/count из одного блока кода — так мы можем быть уверены, что построенный таким образом массив будет всегда одинаковым. То есть, что any_owned_pop будет проверять именно те поселения, на которых выполняется every_owned_pop. Мы их используем уже довольно давно, но для некоторых скоупов были совсем старые решения, которые появились ещё до скрипт-листов. По итогу возникали странности. Например, x_pop и x_planet порой делали совершенно разное, в зависимости от того, используешь every, random, any или count (при работе с разными скоупами иногда ссылки были на все объекты в игре, а иногда на те, что принадлежат текущему скоупу...). Самое неприятное — мы обнаружили, что any_ship ссылается на «все корабли в игре», и всё это время мы использовали его неправильно. А ещё бывало, что одна из версий (зачастую count) просто отсутствовала.

В новом патче почти все решения, придуманные до появления скрипт-листов, удалены и заменены скрипт-листами. В некоторых случаях мы использовали эту возможность, чтобы прояснить назначение скрипт-листа. Например, скрипт-лист planet теперь поделён на galaxy_planet и system_planet. (Это сломает некоторые моды, о чём я немного жалею, но не особо. Это определённо того стоило, и в списке изменений мы подробно укажем, что поменялось. В большинстве случаев пройтись автозаменой будет достаточно. Кроме того, из-за скрипт-листов немалое количество count_x триггеров потеряло букву S на конце, что несколько прискорбно с грамматической точки зрения). Также расширился функционал некоторых скрипт-листов, например, owned_pop, owned_planet и system_within_border теперь работают со скоупом сектора.

Ещё одна выбивавшаяся область, которую надо было улучшить — ссылки на скоупы в эффектах и триггерах, к примеру, create_pop = { species = <что-нибудь> }. Оказалось, что есть довольно большие расхождения в том, чем это <что-нибудь> может быть, в зависимости от эффекта или триггера. Иногда доступны были только расы, иногда расы, лидер, государство и поселение, иногда всё то же, но без поселений... А иногда мы даже использовали нечто под названием owner_main_species, которое работало только здесь (в отличие от owner_species, которое работало везде...). Решением было пройтись по каждому триггеру и эффекту и привести всё в единообразие, чтобы в каждом случае и во всех скриптах использовались одни и те же функции: расы, государства, планеты, лидеры и солнечные системы. Хватит терпеть, что нечто работает тут, но не работает там!

Благодаря этому мы также можем быть уверены, что ошибки всегда записываются правильно (и информативно), если в скриптах что-то пошло не так. (Примечание для моддеров, если кто-то не знает: лог ошибок можно найти в Documents/Paradox Interactive/Stellaris/logs/error.log). Сама запись ошибок тоже стала лучше по всему языку. Мы обновили множество сообщений об ошибках, которым не хватало важной информации (где лежит файл, например) — я как хранитель логов с наших ночных тестов лично отправился в крестовый поход против бесполезных сообщений об ошибках. Более того, мы исправили пугающее число случаев, когда что-то не работало, но не сообщало об этом, например, если в триггере что-то не так и он всегда будет возвращать false, или если в эффекте ошибка, из-за которой он ничего не будет делать. Не могу обещать, что такого больше никогда не повторится, но мы приложили немало усилий, чтобы избавиться от подобных случаев. Моддеры могут рассчитывать на то, что их лог ошибок заметно увеличится как при запуске игры, так и по ходу кампании. А ещё теперь нам легче исправлять баги скриптов, потому что большая их часть сразу всплывает в ночных тестах.

Переменные

Поговорим теперь немного о другом. И наши разработчики, работающие со скриптами Stellaris, и моддеры давно завидуют возможностям более новых версий движков игр PDS, особенно способности работать с математикой внутри скриптов. Мы использовали переменные, но их возможности более ограничены, чем нам бы хотелось. На самом деле, я видел некоторые способы, которыми пользовались моддеры, чтобы обойти эти ограничения, и это послужило для нас сильной мотивацией устранить нужды в подобных ужасных скриптах.

В 2.8 с переменными можно было делать следующее:

сравнивать, приравнивать, добавлять, отнимать, делить или умножать переменную на число, другую переменную в той же скоупе, или ту же переменную из другого скоупа;
экспортировать различные настройки создания галактики в виде переменной;
использовать переменные в локализации, но если значение переменной было 0, то она отображалась в виде пробела, потому что очищалась;
использовать переменные в качестве параметра в некоторых случаях, например, как счётчик в эффекте while.

С тех пор мы многое усовершенствовали, и ещё есть планы на ближайшее будущее. В грядущем патче:

можно сравнивать, приравнивать, добавлять, отнимать, делить или умножать переменную ещё и на другую переменную из другого скоупа;
новые эффекты для получения остатка от деления (оператор %), округления вверх, вниз, и к ближайшему целому числу;
новый триггер check_variable_arithmetic проверяет значение переменной, если бы вы произвели с ней какие-то арифметические операции, например, умножили на другое число или переменную (работает для сложения, вычитания, умножения, деления и остатка от деления);
новые эффекты для экспорта различных игровых значений в переменные. За это отвечают: export_modifier_to_variable (check_modifier_value теперь тоже есть), export_resource_stockpile_to_variable и export_resource_income_to_variable;
add_modifier, add_resource, resource_stockpile_compare теперь имеют параметры mult, в которых принимается переменная. Так что теперь можно масштабировать стоимости в ресурсах и бонусы от эффектов при помощи переменной;
переменные больше не очищаются при значении 0, для этого появилась команда clear_variable, и их можно свободнее использовать в локализации;
в некоторых случаях использование переменных будет создавать запись в логе ошибок, если вы вдруг попытаетесь использовать переменную, не определив её.

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

эффекты должны позволять вам использовать переменные, а также брать значение этих переменных;
триггеры также должны позволять вам использовать переменные, а также сравнивать себя со значением этих переменных;
триггеры должны позволять сравнение с другим скоупом, где они могли бы сработать. Таким образом, num_pops > from будет проверять, больше ли поселений в текущем объекте, чем в from.
должна быть возможность экспортировать текущее значение триггера в переменную при помощи эффекта, т.е. чтобы export_trigger_value_to_variable = { trigger = num_pops variable = my_var } записывало в my_var количество поселений в текущем скоупе.

К сожалению, эти изменения стали возможны только недавно, и хоть основу мы заложили, они ещё не полностью введены в игру — завершение работы над Nemesis и сопутствующим обновлением было более приоритетной задачей (эти изменения не безопасны, мы изменили многие строки кода ради них). Так что считайте этот дневник анонсом того, как код начнёт работать в (надеемся) ближайшем будущем. Пока же по описанному принципу будет работать триггер fleet_power, и export_trigger_value_to_variable тоже включён в обновление, хотя и работает только с этим триггером.

Эффекты кнопок

При разработке интерфейса мы прикрепляем функцию к кнопкам в исходном коде. Но есть также и поддержка кнопок интерфейса, которые вы можете добавить модами. В предыдущих версиях они не подхватывали скоуп объекта, к которому были прикреплены, поэтому кнопка у планеты применяла эффект для всего вашего государства, а не только лишь для планеты. Для ряда случаев мы это исправили: теперь кнопки способны распознавать, относятся ли они к планете, флотилии, кораблю, системе, фоновому объекту, мегасооружению, федерации, месту раскопок, месту первого контакта, агентурной сети или шпионской операции. И случайно так вышло, что консольные команды отладки, вроде «effect ...» и «trigger ...», теперь работают в тех же скоупах.

Уточнение: принцип работы этих эффектов не совсем честный, и систему можно ввести в заблуждение, открыв одновременно несколько окон. Я советую проверять строку is_scope_type = planet/что-нибудь в секциях allow и effect эффекта кнопки. Но, судя по всему, в большинстве случаев всё должно работать как надо, а это лучше, чем ничего.

Ещё больше приятных новинок

В большинстве мест, где ранее можно было использовать логические операторы >, >=, =<, <, теперь можно использовать != в значении «не равно».
Типы сообщений получили собственную директорию, поэтому моды могут добавлять новые типы, не переписывая весь файл (отличная новость для совместимости модов, к тому же мододелы теперь смогут добавлять улучшения качества жизни, не мешая друг другу).
Сообщения, вызываемые эффектом create_message, теперь поддерживают использование команд локализаций, например [This.GetName], где This является целью сообщения.
А ещё из-за того, что нам много где пришлось исправлять Галактическое сообщество на Империум, переменные локализации теперь работают в некоторых новых местах.
Добавлены эффекты add_victory_score = <число> и win = yes. Уверен, никто не станет ими злоупотреблять.
Добавлены новые типы событий: leader_event, system_event, starbase_event, first_contact_event и espionage_operation_event. Однако среднее время срабатывания (MTTH) для них пока не работает. Исправление этого упущения не было для нас приоритетным, да и в целом лучше избегать использования MTTH.
Прописанное в коде поведение джаггернаута теперь привязано к размеру корабля, являющегося мобильной космической базой, а не к ключу juggernaut. То есть теперь можно добавлять джаггернауты в модах, и они не будут страдать от критических ошибок.
Теперь можно скрывать статичные модификаторы из списка модификаторов государства.
Теперь можно проверять расстояние до объектов в пределах одной солнечной системы, добавив к триггеру расстояния строку same_system = yes.
Появилось много новых on_action, и вы теперь можете делать свои с помощью эффекта fire_on_action.
И многое другое.