Новости и дневники разработчиков Stellaris («Стелларис») - Страница 12 - Stellaris / Стелларис - Strategium.ru Перейти к содержимому

Новости и дневники разработчиков Stellaris («Стелларис»)

Рекомендованные сообщения

Закреплённые сообщения
Дoбро

Комментарии к дневнику разработчиков Stellaris №181 — Потоки и время загрузки

Спойлер
brantodb01:
Так это обновление уже вышло в бету?

MatRopert:

Пока что она доступна только внутри студии и для бета-тестеров под NDA. Как я уже говорил, в 2.8 будет больше всего, чем просто улучшение производительности. Подробности будут в следующих дневниках.

___________________________________________

andry18:
Бон вояж, Mat
Хотелось бы узнать до вступительной вечеринки в HoI: есть мысли, почему это не добавило производительности для EU4? И как оно показало себя в IR? Наверное, где-то посередине (лучше, чем EU4, но хуже, чем в CK3 и Stellaris)
 

MatRopert:

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

___________________________________________

Annihilat0r:
Здорово, спасибо за проделанную работу и за дневник. Улучшится ли производительность где-то ещё благодаря вашей (и, возможно, чужой) работе и переходу на DX11?
 

MatRopert:

Есть ещё одна небольшая оптимизация, о которой я не упомянул, и которая должна ускорить загрузку сохранений.

___________________________________________

magriboy0750:
Добрый день, отличный дневник. Раз в следующем патче вы переходите на Directx11 на Windows, значит на Linux и Mac будет использоваться OpenGL 4.1, как в Imperator и CK3?
Заранее спасибо за ответ.
 

MatRopert:

У вас будет возможность переключиться на dx11, а по умолчанию останется dx9. На Mac и Linux мы пока ничего менять не планируем.

___________________________________________

Me_:
Что за Джеф?
 

Caligula Caesar:

[УДАЛЕНО] [УДАЛЕНО] [УДАЛЕНО] [УДАЛЕНО] Джеф [УДАЛЕНО]

Edit: Извините, с моей автозаменой сегодня творится что-то неладное...

___________________________________________

AJGP:
Жаль, мне тоже было интересно, как выиграет от этих изменений версия на Linux. Вы пробовали сравнивать обычный билд линукса с новым рендерером на DX11, запущенным под протоном с DXVK?
Стоит ли ждать однажды перехода на Vulkan? Так могли бы выиграть все платформы.

MatRopert:

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

___________________________________________

Coconut_Cookie:
При разработке будущих расширений вы будете уделять больше внимания техническим ограничениям игры? Игра всё ещё работает куда медленнее, чем до дополнения Megacorp. Нововведения — это здорово и всё такое, но если лейтгейм продолжит так же тормозить, то я лично не буду получать от него особого удовольствия.

MatRopert:

Мы знаем, что многих беспокоит скорость игры. Я могу уделить время и немного разъяснить этот момент.
Зачастую производительность игры меняется не из-за нового контента. Megacorp оказал большое влияние в силу изменённой системы населения из бесплатного обновления. Сейчас в галактиках в 4-5 раз больше жителей, и за это приходится расплачиваться производительностью.

Если же говорить о том, почему мы вообще занялись скоростью запуска, то, во-первых, разработчики в процессе работы ОЧЕНЬ часто запускают игру (думаю, больше 20 раз за день), так что для нас это большой плюс к скорости работы. Во-вторых, как я уже сказал, эти улучшения можно распространить и на другие игры, так что они полезны для большей части PDS, а не только для команды Stellaris.

___________________________________________

Mastikator:
Приятно увидеть новый дневник разработчиков. Это улучшение производительности выглядит здорово. Мы заметим разницу во время самой игры, или только при запуске?

MatRopert:

Все эти изменения касаются только времени загрузки. Как я уже сказал, скорость самой игры ограничена совершенно иными факторами.

___________________________________________

Mastikator:
И ещё вопрос, увидим ли мы в следующем дневнике больше сведений о обновлении 2.8, возможно, о дополнении?

MatRopert:

Вы услышите подробности о контенте в обновлении 2.8 в следующих дневниках.

Хотя в основном речь пойдёт о Джефе...

___________________________________________

Dsingis:
Так, скажу прямо, просто чтобы проверить, что всё правильно понял:
Программисты Stellaris всё лето работали, просто чтобы ускорить загрузку игры вместо того, чтобы ускорить непосредственно игровой процесс? Или нас ждёт ещё один дневник по оптимизации, в котором расскажут, что сделано для оптимизации игрового процесса?
Уж извините за глупость, но быстрый запуск игры не ускоряет саму игру.

MatRopert:

О, нет-нет, мы работали не только над этим. Это лишь одна из задач, с которыми я развлекался во время неспешных летних месяцев, с небольшой помощью со стороны.

___________________________________________

hadaev:
Почему нельзя просчитать всё на машине хоста, а потом отправить данные клиентам?

MatRopert:

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

 

Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.

 

Изменено пользователем Дoбро
Ссылка на комментарий

Дoбро

Дневник разработчиков Stellaris №182 — Риски скриптинга и как их избежать

Всем привет! На связи Caligula, один из контент-дизайнеров Stellaris. Я выполняю различные задачи, связанные с написанием сюжета и скриптингом. «Скриптинг» — это нечто схожее с программированием, но без изменения исходного кода. Иными словами, я делаю то же, что и мододелы (хотя у меня есть значительное преимущество: я также могу смотреть в исходный код и менять его при необходимости). У каждого контент-дизайнера есть своя ниша, и когда особенно сложная система нуждается в скрипте (или, зачастую, создаёт проблемы — мне всё ещё снятся кошмары с войной в небесах...), я берусь за дело.

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

Язык скриптинга Stellaris — это очень мощный инструмент, который позволяет сделать многое, но, прежде всего, замечание: если что-то можно сделать, это не обязательно нужно делать. Это замечание действительно нельзя переоценить, потому что (и я говорю по личному опыту) это почти всегда приведёт к проблемам с производительностью и нечитаемым клубкам кода, которые вы не распутаете даже через полгода, когда обнаружите, что часть скрипта сломана. Однако вы должны понимать, что написать код, по определению, быстрее: в коде можно проверить одну функцию и закончить на том, но если вы хотите получить к ней доступ через скрипт, придётся выполнить несколько необходимых функций перед проверкой вашей функции (что превращает строчку скрипта в кодовую команду с проверкой, в правильном ли скоупе она используется и т.д.) — поэтому некоторые вещи зашиты в код, и именно поэтому хакерские решения проблем могут оказаться плохими. Поэтому первый вопрос, который нужно задать себе: «Точно ли мне нужно это делать?»

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

 

Спойлер

Каждая проверка или эффект потребляет очень небольшую часть компьютерных мощностей. За исключением пары случаев, с которыми нужно обращаться осторожно (я поговорю о них позже), это совершенно нормально и нужно повсеместно. Но когда проверки повторяются часто, да ещё со множеством объектов — вот тогда и начинаются неприятности. В таком случае, обычно, во всём виноваты попы, хотя запускать какую-нибудь проверку по всем планетам в галактике — тоже не лучшая мысль.

Для начала, неплохо будет ограничивать запуск скрипта, если это возможно. Лучше всего это можно сделать, установив место срабатывания ивентов и используя их on_action (или вызывать ивенты через решения и подобное), а не просто MTTH или, что ещё хуже, пытаться запустить ивент каждый день. Если требуется некоторая степень рандома, можно вызывать скрытый ивент, скажем, раз в год, и затем вызывать основной со случайной задержкой (к примеру, посмотрите ивент action.220).

Конечно, не всё вокруг сделано через ивенты, и к сожалению, в Stellaris многое завязано на попах! В частности, вес должностей и другие триггеры в файлах должностей раньше вызывали некоторые проблемы. Как правило, даже если вы можете сделать что-то очень крутое, не стоит слишком усложнять скрипты должностей. Представьте, что вы хотите сделать зависимость веса должности от наличия других безработных попов на планете (используя planet = { any_owned_pop = { is_unemployed = yes } }). Получится, что вы делаете регулярные проверки каждого попа на планете, который потом также проверяет каждого другого попа на планете, в итоге проверяя число попов в квадрате. В поздней игре это почти наверняка будет сильно тормозить.

 

Спойлер

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

Скажем, вы хотите проверить что-то у лидера федерации текущей империи. Кто-нибудь сделал бы это так:

Код:

any_country = {

is_in_federation_with = root

is_federation_leader = yes

<свои_триггеры> = yes

}

Такая проверка переберёт все империи в игре и посмотрит, состоят ли в одной федерации с вами — включая космических амёб и злобных Пашарти (кто вообще захочет вступить с ними в федерацию?). Среди них некоторые совершенно точно не подходят. Так что лучше будет проверить вот так:

Код:

any_federation_ally = {

is_federation_leader = yes

<свои_триггеры> = yes

}

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

Код:

federation.leader = {

<свои_триггеры> = yes

}

Эта версия перейдёт сразу к федерации и в коде оттуда перейдёт сразу к её лидеру. Так будет меньше всего конвертации из скрипта в код и не придётся проверять кучу триггеров на других империях, чтобы добраться до нужной. А ещё такой код легче всего читается (читаемость и производительность часто идут рука об руку...)

В этом примере первая версия кода проверит около 50 империй, вторая — около 5, и третья — всего одну. Неплохая такая оптимизация! По той же логике, всегда стоит избегать проверки всех объектов в галактике (особенно всех попов на всех планетах), и использовать вместо этого отфильтрованные списки, например any_planet_within_border вместо any_planet = { solar_system.owner = { is_same_value = prevprev } } (можете смеяться, но я видел такое). И, конечно, почти всегда можно использовать any_owned_fleet instead вместо any_owned_ship.

Другое важное улучшение, которые мы добавили в 2.6 — это список any_owned_species, который заменяет множество проверок any_owned_pop (особенно тех, что проверяют наличие трейтов и прочего у попов) и, соответственно, приходится проверять намного меньше объектов (в империях ксенофобов одна проверка any_owned_species может быть равноценна тысячам any_owned_pop).

 

Спойлер

Продолжая тему, если вы можете проверить что-то совсем без скоупа, всегда лучше делать именно так. Так что, если надо проверить, есть ли на планете более двух шахтёров, это можно сделать двумя способами:

Код:

count_owned_pop = {

count > 2

limit = {

has_job = miner

}

}

Код:

num_assigned_jobs = {

job = miner

value >= 2

}

Первый варинат проверит каждого попа на планете, не является ли тот шахтёром, а затем сравнит их число с цифрой 2. Второй же вариант проверит кешированное число, которое игра уже посчитала, и сравнит его с 2, что выйдет куда быстрее.

 

Спойлер

Не все проверки и эффекты равнозначны. Проверить флаг или значение обычно очень легко, и изменить их тоже не намного сложнее. Но если игре приходится что-то пересчитывать, это занимает больше времени, потому что нельзя просто взглянуть на уже известные значения. Создание чего-то нового тоже обходится дороже, как потому, что это само по себе сложнее (в эффекте create_species, например, не шуточные 600 строк С++ кода...), так и потому, что после этого, вероятно, придётся кучу всего пересчитывать. Может быть непросто оценить, какие эффекты и триггеры окажутся хуже остальных, но в целом стоит обращать внимание вот на что:

  • Всё, что создаёт новые скоупы, например, create_country, create_species, modify_species
  • Всё, из-за чего вам придётся считать или пересчитывать нахождение пути (например, триггер can_access_system trigger, создание новых гиперлиний, особенно создание новых систем)
  • Всё, в расчётах чего замешаны попы (изменение должностей попов на планете, к примеру)

 

Спойлер

Иногда просто необходимо делать чтото плохое. В таких случаях всё равно стоит попытаться повысить точность срабатывания. Когда игра проверяет триггеры, например, для ивента, обычно она останавливается после первого полученного false (мне сказали, что это называется «short-circuit evaluation»), поэтому стоит писать как-то так:

Код:

trigger = {

has_country_flag = флаг_который_сужает_круг_поиска

<какой-то жуткий код>

}

Недавно я делал что-то подобное для эффекта попов-беженцев. До этого там творился сущий хаос (загляните в Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.  и ужаснитесь). В общем, это проверит вариацию следующего вплоть до восьми раз:

Код:

any_relation = {

is_country_type = default

has_communications = prev #relations включает империи, которые уже встретились, но ещё не вышли друг с другом на связь

NOT = { has_policy_flag = refugees_not_allowed }

prevprev = { #так мы точно будем уверены, что это скоуп попов, потому что root им может и не быть

OR = {

has_citizenship_type = { type = citizenship_full country = prev }

has_citizenship_type = { type = citizenship_caste_system country = prev }

AND = {

has_citizenship_type = { type = citizenship_limited country = prev }

has_citizenship_type = { type = citizenship_caste_system_limited country = prev }

prev = { has_policy_flag = refugees_allowed }

}

}

}

any_owned_planet = {

is_under_colonization = no

is_controlled_by = owner

has_orbital_bombardment = no

}

}

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

Код:

every_relation = {

limit = {

has_any_habitability = yes #необходимый минимум, чтобы стать возможным пунктом назначения для беженцев

}

set_country_flag = valid_refugee_destination_for_@event_target:refugee_pop

}

Затем оставалось лишь проверить, есть ли у этой империи флаг, и если да, есть ли у неё подходящая планета:

Код:

has_good_habitability_and_housing = {

has_country_flag = valid_refugee_destination_for_@event_target:refugee_pop

any_owned_planet = {

habitability = { who = event_target:refugee_pop value >= 0.7 }

free_housing >= 1

is_under_colonization = no

is_controlled_by = owner

has_orbital_bombardment = no

}

}

Также можно использовать if-limit и else (а ещё лучше switch, если возможно — это идеально для производительности) в триггерах, чтобы ограничить проверки и сделать код читаемым. Недавно я проверил файлы прав видов и сделал триггеры allow более разумными:

(До)

Код:

custom_tooltip = {

fail_text = MACHINE_SPECIES_NOT_MACHINE

OR = {

has_trait = trait_mechanical

has_trait = trait_machine_unit

from = { has_valid_civic = civic_machine_assimilator }

}

}

custom_tooltip = {

fail_text = ASSIMILATOR_SPECIES_NOT_CYBORG

OR = {

NOT = { from = { has_valid_civic = civic_machine_assimilator } }

AND = {

OR = {

has_trait = trait_cybernetic

has_trait = trait_machine_unit

has_trait = trait_mechanical

}

from = { has_valid_civic = civic_machine_assimilator }

}

}

}

(После)

Код:

if = {

limit = {

from = { NOT = { has_valid_civic = civic_machine_assimilator } }

}

custom_tooltip = {

fail_text = MACHINE_SPECIES_NOT_MACHINE

OR = {

has_trait = trait_mechanical

has_trait = trait_machine_unit

}

}

}

else = {

custom_tooltip = {

fail_text = ASSIMILATOR_SPECIES_NOT_CYBORG

OR = {

has_trait = trait_cybernetic

has_trait = trait_machine_unit

has_trait = trait_mechanical

}

}

}

Второй вариант будет более эффективным, поскольку он только единожды проверяет, к примеру, имеет ли вид признак «механический» или имеет ли империя гражданскую модель «Ассимиляторы», а не дважды. Кроме того,триггеры во втором custom tooltip больше не такие неприлично странные. (А ещё убрал все NAND, потому что они ломают мой мозг).

 

Спойлер

Я не могу написать этот дневник разработчиков, не рассказав о баге «Счастливого Нового года». В общем, мы играли в мультиплеере с разработчиками в довольно большой галактике и дошли до поздней игры, и поскольку мы все работали удалённо на совершенно разных компьютерах и скоростях интернета, скорость игры была, пожалуй, вяловатой, но в целом приемлемой. Затем мы заметили сильные лаги, по 20 секунд и более — 1 января. Они были так заметны, что мы начали желать друг другу счастливого Нового года всякий раз при зависании игры!

Эти лаги начались как раз тогда, когда нескольких больших империй стали синтетическими и начали ассимилировать своё население. Ассимиляция, в числе прочего, выполняется в скрипте, который, если подумать, должен был сделан иначе... А работал он через событие для каждой ассимилирующей империи на каждое первое января. Это событие по очереди проходило по каждой планете, выбирало кучу попов на ней и применяло modify_species на каждом из них как минимум один раз, но иногда до четырёх. Это подсунуло производительности довольно большую свинью!

Мы перепробовали множество решений и лучше всего оказалось сперва пройти по every_owned_species в скоупе империи, проверить, должны ли эти виды ассимилироваться, и если да, то использовать modify_species, чтобы создать виды, в которые они ассимилируются, установив флаг вида для указания на вид, из которого они ассимилируются. Потом, вместо создания нового вида для каждого ассимилируемого попа, мы переписали скрипты, чтобы искать уже созданный вид, к которому теперь должен относиться поп, и просто использовать на нём change_species. Это всё ещё нечитаемый скрипт (я пожалею ваши глаза и не стану его выкладывать тут), но в моих тестах это привело к снижению ежегодной задержки более чем на 50% — всё благодаря запуску сложного эффекта (modify_species) как можно реже.

 

---

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

 

Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.

Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.

Изменено пользователем Дoбро
Ссылка на комментарий

Присоединиться к обсуждению

Вы можете оставить комментарий уже сейчас, а зарегистрироваться позже! Если у вас уже есть аккаунт, войдите, чтобы оставить сообщение через него.

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Only 75 emoji are allowed.

×   Ваша ссылка автоматически преображена.   Отображать как простую ссылку

×   Предыдущее содержимое было восстановлено..   Очистить текст в редакторе

×   You cannot paste images directly. Upload or insert images from URL.

  • Ответы 539
  • Создано
  • Последний ответ
  • Просмотры 940275

Лучшие авторы в этой теме

  • simonov-89

    224

  • СУЛАРИУС

    89

  • Дон Андрон

    86

  • Дoбро

    31

  • Dimka2010

    14

  • Platon

    13

  • mr_john

    9

  • prometeo

    8

  • Злo

    7

  • Menschenhasser

    6

  • Dota 2

    6

  • DrakonoS

    5

  • RforRush

    4

  • Максим Романов

    4

  • DemonFrumpel

    3

  • antiximik

    3

  • Mars-2030

    3

  • ryazanov

    2

  • Pshek

    2

  • Avers

    2

  • Gargonder

    2

  • JLRomik

    2

  • Soheevich

    2

  • Korvin_Melarsky

    1

Лучшие авторы в этой теме

Популярные сообщения

Максим Романов

Дневник разработчиков №121 от 16 августа 2018 года Переработка Планет (часть 1 из 4)   Привет всем и вот новый дневник разработчиков Stellaris. Сегодня мы начнем говорить об изменениях

Дон Андрон

Дневник разработчиков №91 от 26 октября 2017 года Звёздные базы   Приветствуем всех, и добро пожаловать в очередной дневник разработчиков Stellaris! Сегодняшний рабочий дневник знаменуе

Дон Андрон

Дневник разработчиков №92 от 2 ноября 2017 года Сверхсветовые путешествия и территория Галактики   Приветствуем всех, и добро пожаловать в очередной дневник разработчиков Stellaris! Сег

Дон Андрон

Дневник разработчиков №100 от 11 января 2018 года Титаны и Разрушители планет   Приветствуем всех и добро пожаловать в трижды особенный рабочий дневник Стелларис! Сегодняшний дневник ра

Дон Андрон

Дневник разработчиков №96 от 30 ноября 2017 года Флотские армады и дизайн кораблей   Приветствуем всех, и добро пожаловать в очередной дневник разработчиков Stellaris. Сегодняшний рабоч

Максим Романов

Дневник разработчиков №122 от 23 августа 2018 года Переработка Планет (часть 2 из 4)   Привет всем и добро пожаловать в очередной дневник разработчиков Stellaris. Сегодня мы продолжим т

Максим Романов

Дневник разработчиков №123 от 30.08.18 Планетарная Переработка (часть 3 из 4)   Привет всем и добро пожаловать в очередной дневник разработчиков Stellaris. Сегодня мы продолжим тему, ко

Дон Андрон

Дневник разработчиков №120 от 9 августа 2018 года Новая экономическая система   Приветствуем всех, и добро пожаловать в очередной дневник разработчиков Stellaris! Сегодня мы начинаем ра

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу


Copyright © 2008-2024 Strategium.ru Powered by Invision Community

×
×
  • Создать...