Привет, друзья мои! С вами Moah, техлид Stellaris. Наконец-то я могу ответить на самый важный вопрос. Сколько новых утконосов будет в Federations? Спустя столько недель...
Что ж, наверное, нужно мне быть «более техничным». Но прежде чем погружаться в тайны кода Stellaris, я хочу поговорить о балансе между добавлением новшеств, улучшением производительности и стабильностью, особенно в плане мультиплеера и страшных рассинхронов (по крайней мере, я их боюсь).
Хрупкий баланс
Stellaris, как и любые базы кода приличных размеров, напоминает сложную игру, вроде Микадо или Дженга: каждая часть каким-то образом соединена со всеми другими. Добавляя особенности, вы добавляете больше связей. Если вы осторожны, то добавите лишь несколько, но поспешите — и их станет слишком много. Обычно это ведёт к появлению «незапланированных особенностей» (также известных как баги). Кроме этого, посмотрев на их работу непосредственно в игре, мы зачастую расширяем особенности новыми неожиданными способами, что создаёт ещё больше «незапланированных особенностей(tm)».
Осознав, что происходит, мы начинаем вести себя осторожней. Возможно, даже слишком. Проверяем слишком многое, слишком часто, удостоверяемся, что взаимодействие, которое никогда не должно происходить, действительно не происходит. Ни сейчас, ни потом. Вообще никогда.
Итак, вы избавились от незапланированных особенностей, но игра стала, эм... слишком осторожной. Можно даже сказать, медленной.
Тогда вы убираете ряд проверок. Вы понимаете, что вам не нужно проверять всю галактику, если можно проверить лишь одну крохотную планету. Затем вы делаете следующий шаг и думаете: «Что ж, эту проверку можно делать лишь раз в три недели, а все расчёты, необходимые для неё, можно хранить вот тут и использовать каждый раз, пока они не изменятся».
И теперь игра не страдает от излишней осторожности, а мы вернулись на территорию незапланированных особенностей. Но если кэширование (сохранение и повторное использование вычислений) происходит в разное время на разных машинах, то вы получите немного отличающиеся результаты (это как задавать вопрос разработчику до и после того, как он выпьет кофе).
И вот на этом небольшом расхождении в результатах пышным цветом цветут рассинхроны! У клиента и сервера стоимость отличается на 0,0001, со временем это расхождение накапливается, и вот уже корвет куплен на сервере, но не у клиента.
Так что вы удаляете свой «умный» алгоритм. Вы заменяете его правильным алгоритмом. Вы теряете половину того, что выиграли на втором шаге и вновь вносите ряд багов. Возможно.
Очистить и повторить.
Но хватит о моей утренней рутине! Давайте обсудим…
Производительность
Фанаты Stellaris — как программисты на C++, всё время думают о производительности. Если честно, в последнее время мы тоже часто о ней думаем. Мы знаем, что она далеко не идеальна, особенно в поздней игре и на больших галактиках. С этой мыслью мы потратили время, углубившись в работу над производительностью чуть сильнее обычного. Мы посмотрели, на обработку чего уходит больше всего времени, и как всем и так известно, это…
Поселения.
Есть уйма причин, почему поселения в Stellaris требуют много времени, но главная — к концу игры их становится ОЧЕНЬ МНОГО. ОЧЕНЬ Очень очень очень много. И они много чем занимаются! Каждое поселение должно рассчитывать, насколько оно хорошо на каждой из должностей (этим они занимаются каждые 7 дней). Затем они должны сразиться со всеми остальными поселениями на планете, чтобы получить работу, которая им больше всего подходит. Также им нужно проверить наличие у себя определённых принципов. Смогут ли они присоединиться к определённой фракции. Насколько они счастливы. Насколько они могут быть счастливыми. Насколько они будут счастливы вон на той планете.
Всё это запускает вычисление модификаторов. Если вы помните мой последний дневник, вы должны знать, что в Stellaris только модификаторы превосходят числом поселения. И все они зависят друг от друга. Их расчёт — будто бы потянуть за нитку и получить целый свитер.
Допустим, так что же мы всё-таки с этим сделали?
Ну, во-первых, должен признать, что я слишком упрямо держался за идею «расчёт распределения должностей должен происходить каждый день, потому что мы не знаем, когда добавляются новые должности». Мы пересмотрели это предположение, и теперь распределение должностей происходит только по требованию. Оно также было переписано, чтобы затрагивать намного меньше вещей.
Ещё мы заметили, что несколько триггеров проходят по каждому поселению в империи, чтобы проверить, является ли одно или несколько из них порабощённым, декадентным или каким-либо другим. Так что мы сделали новые триггеры для проверки этого на уровне расы. Аналогично этому, существовали события, проходящие по каждому кораблю для поиска флота, так что мы добавили триггеры на уровне флота.
Во-вторых, мы переработали подход к определению того, может ли население изменить принципы (и заставили это вновь работать) или присоединяться к фракциям.
И наконец, мы попытались найти (и нашли) больше возможностей для многопоточных расчётов.
Но хватит разговоров! Каков же результат? Что ж, если бы одна картинка стоила тысячи слов, то вот вам ответ со скоростью 30000 слов в секунду:
На этом видео вы можете видеть сравнение производительности в версиях 2.5.1 «Шелли» и 2.6 «Верн» на сохранённой игре от сообщества (которую вы сможете найти здесь), содержащей более 20000 поселений. Оно было записано на моём рабочем компьютере (Intel Core7-7900X @ 3.30ГГц, 10 ядер и 20 потоков, и AMD R9 Fury). Конечно, вы не обязательно получите такой же результат: изменение производительности будет зависеть от вашего компьютера и ситуации в игре. В среднем мы зарегистрировали прирост на 15-30% в поздней игре.
Это сохранение просто идеально подходит для демонстрации улучшения поселений.
А почему это средний показатель? Откуда вы знаете?
Ну, у нас есть синтетики, которые играют всю ночь, каждую ночь. Утром мы проверяем, как далеко они смогли дойти. Также мы спрашиваем их, сколько ошибок они встретили, как выглядел их конец игры, были ли у них рассинхронизации, и потом вставляем всё это в разноцветные таблицы и графики. Потом мы избавляемся от синтетиков, чтобы они не задавали назойливых вопросов о душе и всякой всячине.
В заключение
Хотя мы помним о производительности и делаем всё возможное, чтобы она оставалась приемлемой, мы рады, что у нас появилась возможность погрузиться глубже в эту проблему. Надеемся, что изменения принесут вам столько же счастья, сколько и нам, и мы с нетерпением ждём ваших отзывов!
Следующий дневник будет посвящён ещё одной вещи, которой вы все ждали... БОЛЬШЕ УТКОНОСОВ!
PS: Сохранение, которое мы использовали, предоставлено нам сообществом, в одной из тем, посвящённых производительности. Однако мы не уверены, откуда оно изначально там взялось. Поэтому если вы узнаете его, или это ваше, пожалуйста, сообщите нам, чтобы мы могли указать вас должным образом.
ждем сами проверить но когда 2.6 - так и непонятно
zxcpoiqwe насколько можно судить по дневникам текущим и прошлым, то релиз будет примерно в марте или начале апреля