Factorio Dev Diary Factorio Игры
Factorio Dev Diary #411 - All about asteroids
Привет!
Добро пожаловать на «Factorio Friday Facts» от Feargall! (FFFF, если хотите.)
За последние несколько месяцев вы несколько раз видели астероиды в качестве фоновой части некоторых других FFF, но, несмотря на все их сдержанное величие, на самом деле это был довольно сложный трюк! Пойдемте со мной, и я возьму вас в путешествие 3720 к 1 через это поле астероидов.
Астероиды меня беспокоят
Сначала мы начали с астероидов-заполнителей, которые были такими же, как и любой другой спрайт — предварительно отрендеренным 2D-изображением со светом и тенями как его частью. Это сработало, но выглядело довольно странно, что все астероиды были ориентированы в одном направлении и двигались только в плоскости XY, не вращаясь.
Ранние астероиды-заполнители от v453000Итак, вращение — это то, о чем мы говорили в процессе проектирования астероидов.
Проекты астероидов (Эарендель)
Когда мы остановились на трех различных типах астероидов, мы могли приступить к созданию реальных конструкций астероидов. Учитывая обстановку, было ясно, что астероиды должны быть максимально визуально отличны друг от друга.
Мы могли бы использовать одну и ту же традиционную форму астероида для всех их подтипов и использовать цвет только для их различения, как в случае с заполнителями. Но тогда они-бы выходили более яркими, чем нам хотелось, но главная проблема в том, что в целом они будут выглядеть халтурно.
Вместо этого мы решили создать астероиды, которые будут отличаться во всех аспектах.
Во-первых, общая форма. Это важно из-за освещения на астероидах. Во многом их можно идентифицировать по форме их левой освещенной стороны. Металлические астероиды будут выглядеть как сильно деформированные вогнутые формы из изрытого металла. Углеродные астероиды будут представлять собой выпуклые массы гравия и пыли, немного больше похожие на слитые сферы, перемешанные вместе. Оксидные же астероиды будут иметь твердые ограненные формы с более прямыми линиями и острыми углами.
Что касается материалов, то металлические астероиды будут иметь металлический блеск. Углеродные астероиды будут грубыми, с более гравийными дефектами поверхности. Оксидные астероиды будут более блестящими и похожими на стекло, но менее похожими на чистый драгоценный камень и более потрепанными, пыльными или морозными.
С помощью этих приемов мы могли бы получить красивые и отчетливые астероиды, но это усугубляло еще одну проблему: астероиды были очень различимы и очень узнаваемыми, когда любой из них повторялся. Чтобы избежать заметных повторений, нам понадобится множество вариаций, а поскольку спрайты довольно большие, это будет очень дорого.
Другой вариант — скрыть часть сходства, заставив астероиды вращаться, но...
7680 причин не вращаться (Фергалл)
Обычно для спрайтов, которые необходимо вращать, например персонажа или транспортных средств, мы визуализируем отдельное изображение для каждого поворота, чтобы освещение совпадало. Хотя этот подход, вероятно, все еще работал, это был бы кошмар для производительности - поскольку каждый класс астероидов имел 5 размеров, каждый из которых потребовал бы некоторого количества вариантов и, вероятно, по крайней мере 64 кадров для убедительного вращения,. В итоге нам бы потребовалось колоссальные 7680 кадров анимации.
Очевидно, нужно было другое решение.
Представляем шейдеры
Казалось очевидным, что нам понадобится какой-то метод динамического применения информации об освещении астероида. Здесь на помощь приходит лучший друг игрового художника — карта нормалей. Для тех, кто не в курсе, карта нормалей — это изображение, которое, по сути, хранит наклон того, что оно представляет.
Чтобы использовать эту информацию о наклоне для применения освещения, нам нужно выполнить некоторые умные математические вычисления в шейдере, чтобы определить направление наклона от фиксированной точки света.Обновление освещения с вращением
Это дает нам «рассеянное» освещение, но информации о цвете нет! Поскольку мы не хотим создавать космическую оперу в стиле 50-х, нам нужно, чтобы наши астероиды не были черно-белыми. Поэтому при их рендеринге нам необходимо отделить информацию о цвете от информации об освещении.
Мы можем смешать сгенерированное освещение из карты нормалей с нашим необработанным цветным изображением, и это даст нам хороший результат.
Однако вы заметите несколько вещей: освещение очень «плоское», металл металлических астероидов и блеск льда не проступают. Это связано с тем, что шейдер еще не учитывает блеск материалов. Но мы не хотим равномерного увеличения блеска, на разных участках он должен быть разным! Итак, мы визуализируем еще один проход, на этот раз для зеркального освещения.
Мы применяем это, просто используя диффузный цвет для обработки цвета отражения и делая астероиды ярче в нужных областях.
Но лед по-прежнему выглядит неправильно! Он слишком твердый, лед пропускает сквозь себя немного света и рассеивается, придавая ему красивое голубое свечение. Это известно как подповерхностное рассеяние или SSS. Итак, еще одно изображение и проход рендеринга для них, смешанный только в тех областях, на которые косвенно падает свет.
Однако на всех астероидах по-прежнему слишком много теней. Хотя это технически точно, поскольку в космосе нет ничего, что могло бы отражать свет, для наших земных глаз это выглядит неестественно. Таким образом, мы можем уменьшить интенсивность тени и добавить дополнительный источник света под дополнительным углом к первому.
И мы закончили! Спасибо Earendel и Posila за помощь в решении некоторых вопросов с расчетами освещения.
Обновление освещения с вращением
Шейдер космической пыли (Фергалл)
Хотя шейдер звездного поля Ежи и движение астероидов в некоторой степени помогали показать игроку, что платформа движется, в целом эффект было сложно увидеть, нам нужно было что-то очевидное всеобъемлющее, но не чрезмерное.
Одним из решений мог бы быть классический эффект варп-скорости, как в «Звездном пути» или «Докторе Кто», но он казался немного мультяшным и немного оторванным от псевдореалистичного стиля Factorio. Поэтому вместо этого я остановился на компромиссе, состоящем из некоторых размытых движением микрометеоритов и межпланетной пыли, предположительно от всех взорвавшихся астероидов.
Космическая пыль пролетает мимо
Одним из способов создания этого эффекта было бы создание огромного количества дыма и частиц с некоторым размытием в движении, однако в больших количествах частицы требуют довольно много ресурсов, и поскольку этот эффект должен масштабироваться с платформой любого размера, которую вы просматриваете, это будет приведет к экспоненциальному увеличению затрат.
Вместо этого я решил создать одну текстуру со всеми «частицами» на ней. В целях дальнейшей оптимизации эта текстура затем «упаковывается» с несколькими другими текстурами, используемыми в шейдере. Это позволяет сохранить небольшое количество сэмплеров, но при этом позволяет сохранить много деталей.
Все 4 изображения объединены в 1 изображение RGBA.
Немного математики с координатами текстуры и мы можем заставить это изображение двигаться, а замаскировав красный, зеленый, синий и альфа-каналы, мы сможем получить доступ к «упакованным» данным, которые нам нужны.
Просто панорамирование всех текстур
Однако пыль все еще движется более или менее с той же скоростью, что выглядит странно. Таким образом, мы заставим пылинки и частицы двигаться с разной скоростью, просто изменяя скорость в функции панорамирования. Но мы также не хотим, чтобы все точки двигались с одинаковой скоростью, это будет слишком похоже на единую сплоченную структуру. Вот тут-то и пригодятся некоторые маскирующие текстуры. Мы можем использовать изображение №1, чтобы выборочно маскировать отдельные частицы в разное время, что помогает создать иллюзию множества мелких предметов, движущихся независимо. Это делается с помощью математических вычислений, чтобы построить график пика вокруг значения, затем мы присваиваем целевое значение переменной времени и повторяем его обратно.
«Случайный» выбор точки для отображения
В настоящее время частицы постоянно используют изображение следа на 100%, но они должны быть менее размытыми, если движутся медленно. Благодаря предварительному планированию при создании изображения мы можем сделать это, вырезав пиксели ниже порога. Поскольку изображение следа представляет собой линейный градиент, это означает, что мы можем довольно легко контролировать длину, мы просто вычитаем целевое значение из значения изображения.
По мере того, как платформа набирает обороты, пятнышки становятся более длинными.
Если мы повторим процесс пару раз с разными скоростями и масштабами, мы создадим эффект принудительного параллакса. Т.е. пыли ближе к камере больше и она движется быстрее.
Теперь все, что нам нужно сделать, это объединить все это вместе и привязать интенсивность к уровню масштабирования, чтобы это не слишком отвлекало при построении, и все готово!
Космическая пыль над движущейся платформой
В любом случае, с элементом переднего плана покончено.
Хотя пыль помогает проиллюстрировать движения, пространство по-прежнему кажется двумерным. Почему все астероиды идеально плоские с нашей платформой?
Итак, нам нужны элементы фона, больше астероидов! Опять же, мы могли бы просто создать больше астероидов, которые рендерятся за платформой и не сталкиваются, но это казалось неоптимальным.
Вместо этого я использовал технику под названием «нанесение текстур», чтобы создать бесконечное количество астероидов из одного атласа текстур, содержащего всего несколько изображений. Эта (F)FFF уже довольно длинная, поэтому я не буду вдаваться в подробности, но функция в основном разбивает экран на сетку и стремится разместить в каждой по 1 астероиду со случайным смещением.
Для тех, кто интересуется этой техникой, Дэниел Эллиот создал подробное видео о её реализации, которая является почти точной реализацией, используемой здесь.
Атлас текстур всех фоновых астероидовШейдер разбивает это изображение на отдельные астероиды, изменяя UV-координату образца текстуры. Если мы создадим сетку рандомизированных UV-разверток, мы сможем разместить в них астероиды. Однако если астероид поместить за границу двух ячеек сетки, он будет обрезан. Поэтому нам нужно было сослаться на соседние ячейки, чтобы выяснить, не перекрывают ли они текущую ячейку. К счастью, с этим можно справиться, просто используя одну и ту же функцию +/-1 в любом заданном направлении.
Здесь вы можете увидеть сетку ячеек, которую мы генерируем, а также перекрывающиеся образцы (окрашены в красный цвет).
Мы даем каждому астероиду случайную скорость вращения, движения и масштаб и проделываем все это снова в другом масштабе для параллакса. Затем мы делаем то же самое и используем те же расчеты для динамического освещения, что и раньше, и получаем бесконечные поля астероидов!
Продолжаем и продолжаем вечно
Большое спасибо, что отправились со мной в это долгое и техническое путешествие. Кажется, наш корабль уцелел.
Как всегда, пишите нам обычных местах:
Форум РедитFactorio Игры Factorio Dev Diary
Factorio Dev Diary #410 - Rocket turret & Target priorities
Мы знаем, что вы любите все взрывать, и расширение «Космическая эра» принесет еще более совершенные и мощные способы борьбы с врагами.
Ракетная турель
Ракетная турель как и ожидалось из ее названия стреляет ракетами:
- Мощная дальнобойная турель 3х3.
- Разблокируется на одной из трёх начальных планет.
- Минимальная дальность — 15, максимальная — 36 (улучшение +10% за каждый уровень качества).
- Стреляет любым типом ракеты (включая атомную бомбу).
Графика Ярослава; Звуковые эффекты от Яна
Приоритеты/фильтрация целей турелей
Использование более мощных турелей, использующих ракетные боеприпасы, приводит к еще одной проблеме: на самом деле мы не хотим тратить дорогие ракеты на маленькие астероиды, с которыми легко могут справиться пушечные или лазерные турели.
Поэтому мы добавили функцию приоритетов целей турелей с дополнительной опцией игнорирования вещей, которых нет в списке (что фактически делает ее фильтром белого списка). Мы можем использовать это, чтобы сосредоточить огонь на более крупных астероидах или даже заставить наши ракетные турели полностью игнорировать маленькие астероиды.
Артиллерийская башня не поддерживает приоритеты/фильтры из-за особенностей работы оптимизированной логики артиллерийской стрельбы. Вероятно, это не такая уж большая проблема, потому что нам все равно следует просто ВСЕХ УБИТЬ.
Есть еще одна часть расширения «Космической эры», где фильтрация целей будет играть решающую роль, но это будет на следующей неделе…
Подключение контура турели
В версии 2.0 мы добавили возможность подключать турели к сети:
- Включить/выключить
- Установка целевых приоритетов
- Установки на игнорирование не указанных в списке целей
- Считать боеприпасы
Это открывает несколько хороших возможностей, одна полезная вещь — чтение содержимого турели, чтобы включать и отключать остановку поезда, приносящего боеприпасы.
Артиллерийская башня также имеет логическую связь с сетью, но только включение/выключение и считывание боезапаса.
Заключение
Исследование ракетной турели — важная веха в путешествии в космическую эпоху. Она открывает больше возможностей для выживания платформ и заводов, а также дает вам возможность решить новые логистические дилеммы.
Хотя ракетная турель является эксклюзивной для Space Age, целевые приоритеты и подключение к сети станут доступны всем в обновлении 2.0.
Также не случайно турель имеет сходство с головой Спайдертрона. Можно было почти ожидать, что рецептом Спайдертронов космической эры будет ракетная турель + четыре экзоскелета...
Как всегда, дайте залп своих мыслей по привычным местам:
Factorio Игры Factorio Dev Diary
Factorio Dev Diary #409 - Diminishing beacons
Здравствуйте!
Сегодня мы рассмотрим функцию, которую некоторые из нас мечтали изменить уже много лет, — передачу маяка.
Основная цель маяков — позволить значительно увеличить производительность в поздней игре, оставаясь при этом нечто большим чем просто модулем или более быстрой машиной. Чтобы использовать маяки, вам необходимо настроить под них планировку здания.
Маяки справляются с этой ролью, но...
Проблема
Мы не уверены, что получившиеся раскладки настолько интересны — об этом и мы, и многие игроки говорили уже много раз.
Сборка из 12 маяковПервая из двух типичных компоновок — окружение машины максимальным количеством маяков (на каждую сборочную машину влияет 12 маяков).
- Лучшая вычислительная производительность
- Не так эффективно
- Дорогостоящие как по конструкционным материалам, так и по потребляемой мощности.
Через него легко проложить множество ремней, так как вокруг крафт-машины есть место, на самом деле это настолько просто, что кажется, что конечный макет игры не так уж и сложно построить.
Вид на карту сборки 12 маяковЕсть несколько небольших изменений, которые вы можете сделать, например, приблизить боковые маяки, но в целом большинство из 12 макетов маяков выглядят одинаково для подавляющего большинства рецептов, поэтому фабрики в поздней игре в конечном итоге выглядят как массивы квадратов.
Сборка на 8 маяков
Другой вариант — чередование рядов машин и маяков (по 8 маяков на каждую сборочную машину).
- Высокая эффективность использования пространства
- Хорошее соотношение цена/прибыль
- Мало места для ремней
Из-за зазора всего в 2 клетки между маяками и машинами вы можете пропустить лишь очень небольшое количество транспортных лент. Есть несколько приемов, которые помогут вставить до 2 транспортных лент и вытащить 1 транспортировочный ремень, но как только вы освоите эти приемы, вы просто будете повторять их снова и снова. В качестве альтернативы, поскольку это довольно экономно, это хорошо для логистики роботов, и в этом случае вы просто копируете пары сундуков запросчика + поставщика рядом с машинами, что тоже не совсем креативно.
Поскольку других существенных альтернатив этим двум макетам не так много, в целом использование маяков кажется ограничивающим разнообразием сборок и имеет тенденцию казаться монотонным и неинтересным, особенно по сравнению с тем, насколько разнообразны ранние этапы игры.
Идеи
На протяжении многих лет обсуждалась эта проблема, у нас возникали разные идеи. Также проводились различные эксперименты с тем, что позволяет API моддинга, что также является явным признаком того, что многие люди хотели бы каких-то изменений.
Перегрузка маяка
Перегрузка маяка — механика из мода Earendel Space Exploration . Это приводит к отключению любой машины, на которую воздействует более чем один маяк. Это означает, что схемы с 12 маяками, 8 маяками или любые другие схемы просто невозможны. С обычным диапазоном маяков вы все равно можете сделать обратную схему с 12 маяками и окружить один маяк машинами, но становится непрактично повторять и размещать плитки, потому что теперь есть 12 машин, которым нужны входы и выходы вместо одной.
При попытке перегрузки маяка поначалу кажется, что все в порядке. Маяки более мощные на базовом уровне и имеют больше слотов для модулей, поэтому отдельный маяк более гибок. Отключение случайного одиночного маяка для увеличения случайных областей производства дает гораздо большую выгоду, но вы должны быть осторожны, чтобы не перекрыть машину двумя маяками и не перегрузить ее. Проблема в том, что в расположении маяков нет особой гибкости: обычно вы просто строите маяки в сетке, избегающей перекрытия, поэтому это не намного интереснее, чем базовая игра. Но, по крайней мере, выглядит лучше.
Макет перегрузки маякаЧто становится более разнообразным, так это широкомасштабный маяк из Space Exploration, поскольку в конечном итоге вы проектируете целые сборки вокруг одной структуры. Однако это становится довольно неудобным для плитки, поскольку вам нужно избегать перекрытия машин с несколькими маяками. Размер всей сборки определяется дальностью действия маяка, поэтому она почти всегда группируется вокруг одного маяка или короткой линии маяков по модульному принципу.
Примеры расположения радиомаяков на большой территории от Sticklord и Oblivion, двух спидранеров Space Exploration.
Они ориентированы на прямую установку, чтобы сделать ключевой продукт в радиусе действия одного радиомаяка большой площади.
У вас есть большая гибкость в том, как вы строите в области маяка, поэтому это может быть удобно для сборок с прямой вставкой. В целом, вся свобода дизайна предоставляется при строительстве внутри пространства маяков, но варианты размещения самих маяков становятся довольно скучными, это просто еще одна сетка.
Довольно типичная установка радиомаяка в Space Exploration.
Эта сборка от Xylokite имеет 3 маяка большой площади в линию и предназначена для вертикального расположения, чтобы маяки образовывали сетку.
Скрытые маяки из мода «Built-in-Beacons»
Эксперимент, который проповедует философию того что, в игре нет надобности в существовании отдельных маяков, а вместо этого мы просто можем встроить функционал маяка в сами машины.
Стандартная, но более быстрая планировка со встроенными маяками.Результатом этого является то, что фабрикам никогда не придется переходить к повышению производительности за счет изменений в компоновке, кроме маршрутизации большего количества лент, что можно рассматривать как отрицательное, так и положительное явление.
С одной стороны, у вас все еще есть все возможности, как и на более ранних этапах, и протащить больше поясов - это здорово, но в то же время это не привносит ничего нового.
Схема прямой вставки со встроенными маяками
Единственное новое, что мод вводит, это то, что становится возможным напрямую вставлять предметы между машинами, не теряя при этом в скорости крафта. Вы можете создавать сборки, которые, например, создают полезные научные пакеты в основном из сырья, что, очевидно, можно сделать самыми разными способами. Хотя это довольно безумно разрабатывать, часто с чрезмерным использованием калькуляторов ставок. Лично мне это показалось крутым, но я не ожидаю, что многим другим это понравится.
Ограничения мода (Эарендель)
Никто из нас не предполагал, что наши моды станут правильным решением для базовой игры. Мы знали о недостатках, но моды очень ограничены в том, что они могут делать с маяками в версии 1.1.
Другие моды тоже экспериментировали с различной механикой маяков, но что-то более интересное, чем некоторые изменения базовых значений, требует множества неприятных обходных путей и сценариев во время выполнения. Существуют некоторые творческие подходы, но ни одна из этих механик не подходит для базовой игры.
Даже в контексте освоения космоса перегрузка маяка не была тем решением, которое мне нужно. Это было лучшее решение, которое я смог найти, учитывая имеющиеся у меня варианты и несколько простых сценариев. Я рассмотрел множество вариантов, но постепенно исключил большинство из них как невозможные или непрактичные из-за ограничений движка, и в итоге остановился на Beacon Overload.
Очевидно, что эти ограничения не являются проблемой, если мы можем «просто изменить игровой движок», но мы не можем менять игровой движок для каждой нашей идеи, иначе все замедлится. В идеале, если у нас есть хорошая идея, мы быстро прототипируем ее как мод для тестирования. Интерактивная демонстрация помогает другим людям оценить идею. Проблема в данном случае в том, что мы знали, что «решение» будет настолько далеко за пределами возможностей игрового движка, что создание мода для него было бы непрактично. Вместо этого нам нужно было бы детально рассмотреть все наши идеи, найти лучшую и убедиться, что она правильная, прежде чем мы создадим версию прототипа.
Решение (В453000)
Наши мечты всегда заключались в идее убывающей отдачи. Чем большим количеством маяков вы окружите машину, тем меньший эффект будет иметь каждый из них.
Однако встречные вопросы и сомнения имелись:
- Уверены ли мы, что это действительно лучше, или мы просто обмениваем одну ошибочную систему на другую?
- По крайней мере, мы знаем недостатки нынешней системы, и это не так уж и плохо.
- Не было бы хуже, если бы эффект результата было сложнее просчитать в голове, если бы он не был линейным?
- У нас нет времени реализовывать то, в чем мы не уверены.
И до версии 1.0 минусы, казалось, перевешивали потенциальные плюсы, но мечта всегда была в глубине наших мыслей (в первую очередь у меня и Эарендела). Фактически, мы были настолько известны этим, что, когда Боскид проводил рефакторинг некоторых частей кода эффекта маяка, он делал это таким образом, чтобы можно было что-то подобное, на случай, если в конечном итоге это понадобится...
И желание это было! Эарендель выдвинул свое предложение:
- Эффект передачи равен квадратному корню из количества маяков.
- Усиление базового эффекта передачи с 50% (0,5).
- Добавление масштабирования качества для передачи эффекта
Я протестировал его и окончательно определил значения.
История цифр
Первоначальная идея Эарендела включала вычисление квадратного корня, но мы предполагали увеличить передачу маяков с 0,5 до 1,0, отчасти потому, что это хорошее число.
Вдобавок ко всему, сделав маяки менее сумасшедшими при большом количестве, мы могли бы позволить им масштабироваться с повышением качества.
В более раннем FFF мы заявили, что маяки снижают потребление энергии только за счет более высокого качества, потому что мы думали, что качество уже делает вещи достаточно сумасшедшими, и мы не хотим продвигаться дальше. Но с тех пор мы в 4 раза усилили ремни с возможностью штабелирования предметов, так что теперь это звучит намного привлекательнее.
Поигравшись с этим, я быстро пришел к выводу, что 2-кратного усиления недостаточно, и небольшое количество маяков по-прежнему кажется слабым, в то время как более высокие значения также ослабляются. Я решил, что попробую удвоить его еще раз, и пошел с 4-кратным усилением - когда я позже говорил об этом с Эаренделем, он отметил, что это также значение, которое он выбрал для перегрузки маяка, и я был рад получить подтвеждение своих мыслей, когда мы независимо пришли к одному и тому же мнению.
Когда я готовил изменения и готовился презентовать их финальному боссу (Коварексу), я сделал листы и график.
Я чувствовал себя глупо, потому что не осознавал, что квадратный корень из 16 маяков равен 4, поэтому, если мы усилим маяки в 4 раза, это означает, что все сборки с количеством маяков менее 16 будут усилены. Мне показалось, что это слишком много, поэтому я остановился на 3x, что дает мощность передачи 1,5.
При усилении 4x или 3x масштабирование качества необходимо было немного снизить, поэтому вместо 1–2,5, как в большинстве других вещей, мощность передачи масштабируется от 1,5 до 2,5 для маяков, что по-прежнему отлично. В конце концов, они все еще уменьшают потребление энергии.
Я чуть не расплакался, увидев, какими красивыми оказались значения:
Для существующих заводов это изменение на удивление незначительно. Машины, на которые установлено 8 маяков, фактически будут работать на 6% быстрее, а машины с 12 маяками — на 13% медленнее.
Это удивительно, потому что это означает, что базовая игра остается почти такой же, мы получаем те усиления, которые всегда хотели, а качество позволяет еще больше прогрессировать.
Результаты
Использование маяков действительно дает эффект, даже если вы разместите всего несколько из них. В космическую эпоху это особенно важно, поскольку обычно именно тогда вы хотите увеличить производство для запуска большого количества ракет.
Поскольку модули производительности снижают скорость машины, в старой системе первые два маяка возвращают машине скорость крафта выше 100%. В этот момент вы осознаете, что сделали обновление благодаря возросшей производительности, но на самом деле это не так увлекательно, когда воспринимаемая скорость примерно такая же.
Теперь, поскольку одиночный маяк имеет в 3 раза больший эффект, этого более чем достаточно, чтобы преодолеть негативный эффект производительности, который ощущается намного лучше.
Базовая электронная схема, теперь с +24% производительностью и +50% скоростью всего с несколькими маяками.
В некоторых ситуациях речь идет не только о маяках, но и о том, что пространство здания ограничено, поэтому высокоэффективные маяки естественным образом подходят для таких мест, как космические платформы.
Космическая платформа с маяком
Будучи полной новинкой, один маяк с зелеными модулями может значительно снизить энергопотребление машины. Это становится особенно заметным с более высокими качествами, поскольку передача эффекта маяка увеличивается, модуль эффективности становится более мощным, а маяк снижает энергопотребление с более высоким качеством, так что оно того стоит еще больше. Все машины на скриншоте выше потребляют -80% энергии.
В результате космические платформы смогут выбирать баланс между скоростью создания, энергоэффективностью и производительностью. Все это действительно важно в ограниченном пространстве, так что это интересное решение, над которым стоит подумать.
Более крупные структуры, такие как Литейная, обычно имеют высокую скорость крафта, чтобы чувствовать себя мощными и достаточно эффективно использовать пространство по сравнению с меньшими объектами. Из-за размера до них можно добраться с помощью большего количества маяков (16 для Литейной плитки 5x5), что слишком сильно увеличивает их и без того сумасшедшую скорость крафта. Убывающая отдача делает эти различия более разумными.
Не волнуйтесь, Литейная по-прежнему сходит с ума, особенно со всеми бонусами качества к концу игры.
Обмен нескольких маяков на машины, расположенные рядом друг с другом, вероятно, приведет к появлению некоторых новых возможностей для некоторых сборок, оптимизированных для ИБП.
Я не смею утверждать, что это эффективная конструкция ИБП, но вы поняли идею, и я очень рад видеть, какие конструкции вы придумаете.
Благодаря качеству вы сможете еще лучше использовать несколько дорогих модулей, которые вы получили, поместив их в маяки самого высокого качества, которые вы можете получить.
Еще одна вещь, которую следует учитывать при выборе качества, это то, что, возможно, у вас не так много легендарных модулей скорости, но много модулей производительности или наоборот, что может существенно повлиять на то, какая сборка будет более доступной для вас в данный момент, и это может даже повлиять на долгосрочная стратегия: какую планету вы посетите в первую очередь.
Заключение
Я раздражал все свое окружение, включая коварекса, постоянными разговорами о механике включения и выключения маяка вот уже около 7 лет. Дошло до того, что, если бы я поднял этот вопрос, я бы получил реакцию: «О, ты снова со своими маяками» , и, честно говоря, я не мог их винить.
В последние месяцы я уже оставил надежду, что мы когда-нибудь реализуем это, поскольку расширение, казалось, становилось полнофункциональным...
Но однажды у нас была дискуссия с Эаренделем, и я спросил его, какие последние функции он хотел бы реализовать. Эарендель ответил всего одним словом, очень взволнованным и, на удивление, очень уверенным голосом: «Маяки!» .
Информация, которую мне не хватало, заключалась в том, что он ранее уже провел некоторое исследование с помощью boskid и сказал мне, что код в основном готов для этого.
Я был потрясен самым положительным образом.
Нам потребовалось всего несколько дней, чтобы получить рабочую версию, а поиск правильных значений занял всего несколько недель, что очень хорошо, учитывая масштаб изменений. Полученные значения оказались лучше, чем я когда-либо мог себе представить, что сделало изменение действительно привлекательным, поэтому убедить kovarex в этом в конечном итоге тоже не составило труда.
В версии 2.0 увеличение количества маяков по-прежнему будет хорошей практикой для быстрого выполнения задач и экономии производительности компьютера. Однако теперь появится гораздо больше возможностей для творчества, а качество окупаемости инвестиций становится под большим вопросом.
В целом это можно рассматривать как улучшение маяков, которое должно помочь вам прогрессировать быстрее, особенно на ранних этапах игры, что снова делает Space Age менее утомительным и более интересным.
Деталь, которая делает реализацию boskid неоправданно интересной, заключается в том, что это поведение определяется очень простой так называемой таблицей «профиля» в Lua.
Это означает, что моды могут возвращать маяки к работе, как в 1.1.x, тривиально реализовывать перегрузку маяков, создавать перегрузку маяков, которая допускает перекрытие, увеличивать эффект маяков с увеличением количества маяков или что-то еще, что они могут придумать.
Я невероятно рад, что Эарендель рядом со мной. Как вы, вероятно, можете сказать по тому, что мы оба пишем этот пост в блоге, вместе мы можем воплотить в жизнь очень многие мечты. Огромное спасибо также выражаем boskid, который выслушал нас и позаботился о том, чтобы очистить код, чтобы быть готовым к тому, чего мы хотим.
Мы все чрезвычайно гордимся тем, что наконец нашли способ внести изменения, к которым многие из вас призывали на протяжении многих лет.
Мы вас услышали, всему свое время и место.
Дайте нам знать, если вы так же как и мы, взволнованы эффектом, который принесет это изменение:
Форум РедитFactorio Игры Factorio Dev Diary
Factorio Dev Diary #408 - Statistics improvements, Linux adventures
Статистика(Клонан)
Любите ли вы наблюдать за тем, как растут ваши производственные графики, так же, как и мы?
График аккумулятора
Когда вы переходите от энергии пара к солнечным панелям и аккумуляторам, немного сложно узнать, достаточно ли у вас мощности в системе, чтобы пережить холодные темные ночи. Как правило, вы можете просто подождать до наступления ночи и посмотреть, отключится ли ваша фабрика, и если да, то построить больше солнечных батарей и аккумуляторов.
Было бы полезно и удобно видеть статистику уровня заряда аккумулятора, поэтому мы добавили такую информацию:
Основная причина, по которой это было более критично, заключалась в том, что на Фульгоре образование молний в ночное время гораздо менее предсказуемо, поэтому гораздо важнее видеть график заряда аккумулятора.
Научный график
Вы можете отслеживать потребление научных пакетов в производственном графическом интерфейсе, но это не учитывает такие вещи, как модули производительности и новые технологии продуктивности исследований.
Поэтому мы добавили новый специальный элемент в статистику производства, который показывает общее количество произведенной «Науки».
Производство по мирам
В первые дни тестирования планет и платформ было терпимо, что вся статистика производства была глобальной. Однако, когда вы хотите стать все более и более точным в своем игровом процессе и попытаться оптимизировать каждую его часть, это становится совершенно необходимым.
Например, на платформах нам нужно знать, производим ли мы достаточно топлива и боеприпасов, чтобы поездка продолжалась:
И это очень полезно при проверке того, достаточно ли производит конкретная планета, когда некоторые предметы создаются во многих местах.
Мы также добавили флажок для переключения в режим просмотра «Глобальная статистика», чтобы игроку были доступны все возможности.
График качества
Если пойти еще глубже, мы хотим проанализировать нашу продукцию по качеству выпускаемой продукции.
Так что вы думаете? Есть ли какие-либо другие улучшения статистики в версии 2.0, которые могут прийти вам в голову?
Linux-приключения(Рейгард)
Я уже появлялся в нескольких FFF, но никогда официально не представлялся. Меня зовут Рейгард. Я играю в Factorio с июня 2017 года, делаю моды для игры с момента выпуска версии 0.17 в марте 2019 года и, наконец, присоединился к Wube в марте 2023 года. Мои основные обязанности в компании — программирование расширений и поддержка Linux, а также представление интересов сообщества мододелов. Я ежедневно использую Linux в течение нескольких лет и все глубже погружаюсь в черную дыру настройки и минимализма.
«Почему большинство игр не поддерживают macOS и Linux?» — это мнение, которое я часто вижу в Интернете. Поддержка новой платформы — это гораздо больше, чем просто изменение некоторых флагов и компиляция. Windows, macOS, Linux и Nintendo Switch используют разные компиляторы, разные реализации стандартной библиотеки C++ и имеют разные особенности реализации, ошибки и функции. Вам необходимо настроить CI для новой платформы, расширить систему сборки для поддержки новых компиляторов и архитектуры, а также иметь в команде хотя бы одного человека, который достаточно заботится о платформе, чтобы активно ее поддерживать. Если вы занимаетесь видеоиграми, вам, вероятно, потребуется добавить поддержку другого графического интерфейса (Vulkan или OpenGL), поскольку DirectX является эксклюзивным для Windows.
Многие разработчики, взглянув на долю рынка Windows , решат, что поддержка других платформ не стоит усилий. Кроме того, с стремительным ростом Steam Deck и Proton разработчикам игр стало легче, чем когда-либо, игнорировать поддержку Linux, потому что Valve прибегает к черной магии, которая все равно позволяет их игре работать.
Factorio так хорошо поддерживает macOS и Linux, потому что в Wube всегда был кто-то, кто активно использует эти платформы и готов взять на себя бремя их поддержки. Наша встроенная поддержка Apple Silicon — отличный тому пример. Сегодня я расскажу вам о некоторых приключениях, которые произошли со мной при поддержке Linux в Factorio.
Wayland
Моей первой задачей после присоединения к команде было добавить в игру поддержку Wayland . Wayland — это новый протокол отображения, который разрабатывается для замены устаревшей и небезопасной системы X11 . Современные дистрибутивы Linux начинают переключаться на Wayland по умолчанию, поэтому поддержка его в Factorio имеет первостепенное значение.
Мы используем библиотеку SDL , которая аккуратно обрабатывает большинство низкоуровневых системных взаимодействий и абстрагирует их в общий интерфейс. SDL поддерживает Wayland, поэтому все, что мне теоретически нужно было сделать, — это собрать SDL с включенным Wayland, и он «просто заработает». Однако это не совсем просто подключи и работай. Wayland предоставляет «протоколы» в виде XML-файлов, которые вы затем используете в wayland-scanner двоичном виде для преобразования в программу C и файлы заголовков.
Поскольку в то время я был относительно новичком в C++, мое первоначальное решение было запутанным и включало проверку сгенерированных протоколов Wayland в нашем дереве исходных кодов, чтобы их можно было регенерировать вручную каждый раз, когда мы обновляли SDL. Несколько месяцев назад, вооружившись многолетним опытом, я улучшил этот рабочий процесс, чтобы автоматически генерировать файлы как часть процесса сборки, чтобы они всегда были актуальными с XML-файлами протокола, с которыми поставляется SDL.
Factorio поддерживает Wayland с версии 1.1.77, но его необходимо явно включить, настроив SDL_VIDEODRIVER=wayland в вашей среде. Для Factorio 2.0 я добавил раскрывающийся список для выбора ваших предпочтений в графическом интерфейсе:
X11 (слева) и Wayland (справа) с масштабом дисплея рабочего стола, установленным на 125%.
Обратите внимание, как игра отображается с собственным разрешением дисплея при работе под Wayland.
Оформление окон на стороне клиента
Как только поддержка Wayland была реализована, я получил отчет об ошибке , в котором говорилось, что в окне отсутствовала строка заголовка и кнопки закрытия (так называемые «декорации окна») при работе в GNOME . Большинство сред рабочего стола позволяют окнам предоставлять свои собственные украшения, если они того пожелают, но в качестве альтернативы предоставляют реализацию по умолчанию на стороне сервера. GNOME в своей бесконечной мудрости решили, что все клиенты должны предоставлять свои собственные украшения, а если клиент этого не сделает, они просто пропадут. Я не согласен с этим решением; Factorio не нуждается в оформлении какой-либо другой платформы, более того, в любой другой среде рабочего стола, но GNOME может (ab) использовать свою популярность, чтобы заставить программы соответствовать его особенностям или остаться позади.
Чтобы исправить это, мне пришлось добавить еще одну зависимость — libdecor . Он работает, и SDL даже поддерживает его, но видеоигра вообще не должна обеспечивать оформление окон.
В игре появились украшения, но тема не соответствует. Спасибо, ГНОМ!Захваты при изменении размера окна
Видео стоит больше тысячи слов:
Я использую оконный менеджер Sway , и особенность этого оконного менеджера заключается в том, что он автоматически изменяет размер плавающих окон до размера их последнего отправленного кадра. Это выявило проблему с нашим графическим стеком: игре требуется три кадра, чтобы правильно отреагировать на изменение размера окна. В результате происходит быстрое перетягивание каната: Sway отправляет массу событий изменения размера, а Factorio отвечает устаревшими размерами кадрового буфера, вызывая хаос, показанный выше.
Я провел два полных дня, рассматривая наш графический код, но не смог придумать объяснения, почему это происходит, поэтому эта работа все еще продолжается. Поскольку эта проблема возникает только при запуске игры на Wayland под управлением Sway, это не является большим приоритетом, но это было слишком интересно, чтобы не поделиться.
Динамически подключаемые библиотеки
В программе C++ существует три способа загрузки/подключения библиотеки:
Включив его в исходный двоичный файл (статическое связывание).Загрузка системы при запуске вашей программы (динамическое связывание).Ваша программа загружает его явно после запуска («динамическая загрузка» или то, что я называю «связыванием во время выполнения»).У нас есть множество библиотек, таких как SDL, FontStash и Lua, которые скомпонованы статически, но в Factorio 1.1 также есть много динамически скомпонованных библиотек.Среди этих библиотек — X11 и PulseAudio, которые устарели в пользу Wayland и PipeWire соответственно. Это вызывает кошмар совместимости, поскольку если какие-либо динамические зависимости отсутствуют, игра не запустится. Это явно не подойдет!
Наличие этих зависимостей меня смутило, поскольку мы используем SDL для большинства низкоуровневых системных вызовов, аудио и видео, а SDL полностью полагается на связывание во время выполнения. Расследование показало, что источником большинства этих зависимостей является Allegro , низкоуровневая библиотека, которую мы использовали на протяжении большей части альфа-фазы Factorio, но с тех пор заменили на SDL. Единственное оставшееся использование Allegro в версии 2.0 было в качестве вторичного аудио-сервера на случай, если у пользователя возникли проблемы с аудио-сервером SDL, но сервер SDL был стабильным в течение очень долгого времени, поэтому настало время для его удаления. Это исключило из игры 123 024 строки кода и резко сократило количество динамических зависимостей:
Проблемы с буфером обмена
Оказывается, Allegro — не единственное, что требовало от нас связывания с X11. Еще в 2017 году мы получили сообщение об ошибке , в котором пользователь не мог вставить большие строки чертежей в игру, и Oxyd исправил это, добавив поддержку инкрементной передачи данных из буфера обмена X11 в обработчик буфера обмена нашего графического интерфейса.
Я надеялся использовать встроенную в SDL функциональность буфера обмена, но, к сожалению, SDL не поддерживает инкрементную передачу. Это означает, что есть три варианта:
Продолжайте связывать с X11, требуя, чтобы пользователи установили X11 в своей системе, чтобы иметь возможность запускать игру (я не хочу возиться со статическим связыванием).Выясните, как выполнить связывание во время выполнения, и реализуйте это.Переведите наш код инкрементной передачи в SDL, чтобы мы могли использовать функции буфера обмена SDL, а другие игры на основе SDL могли бы извлечь выгоду из нашей работы.Как вы могли догадаться, я выбрал третий вариант. Работа над улучшением нашего кода продолжается, но она должна быть завершена к выпуску Factorio 2.0.
Асинхронное сохранение
Многие из вас, возможно, не знают, что Factorio поддерживает сохранение игры в фоновом режиме без зависания при этом. Эта функция спрятана в скрытых настройках и работает только на macOS и Linux. Это отличный пример использования возможностей платформы для пользы игры, которые были бы нам не доступны, если бы мы просто прошли через Proton.
Асинхронное сохранение работает с использованием системного вызова fork, по существу дублирующего игру. Основной экземпляр, с которым вы взаимодействуете, продолжает играть, но недавно разветвленный дочерний элемент запускает процесс сохранения, а затем завершает работу по завершении. Я использовал его в течение многих лет, и у меня никогда не было проблем, но настройка остается скрытой, поскольку с ней есть несколько нерешенных проблем, и для ее работы требуется значительный объем оперативной памяти.
Я бы хотел продвинуть эту функцию из ее скрытого статуса в версии 2.0. Если вы играете на Linux или macOS, включите асинхронное сохранение (ctrl+alt+нажмите «Настройки» -> «Остальное» -> non-blocking-saving) и сообщайте о любых обнаруженных проблемах. Меня особенно интересует воспроизведение, казалось бы, случайного зависания , которое происходит в конце процесса. Заранее спасибо!
Постоянное развитие
Это был лишь краткий обзор работы, которую я проделал, чтобы обеспечить наилучшее качество Factorio для Linux. По-прежнему существует много открытых отчетов об ошибках и других проблемах, но в целом я доволен положением вещей и могу с уверенностью сказать, что у Factorio отличная поддержка Linux.
Как всегда, отправьте текстовый буфер с вашими отзывами в привычные места:
Форум РедитFactorio Dev Diary Factorio Игры
Factorio Dev Diary #406 - Space Age Music
В ноябре 2021 года мы начали переговоры с Петром Вайсаром , очень талантливым чешским композитором, о создании саундтрека для расширения Factorio. С тех пор мы вместе работаем над саундтреком к Factorio Space Age. Концептуализация и поиск решений наших немалых проблем, а также наполнение расширения качественной музыкой, специально разработанной для получения наилучших впечатлений от Factorio.
Петр – особенный музыкант, поскольку он не только признанный мастер электронной музыки, но и его образование и опыт работы в консерватории позволяют ему сочинять музыку, используя весь диапазон классического оркестра. Его современный стиль перехода к более экспериментальным решениям делает его очень гибким при создании музыки для расширения Factorio Space Age.
Оркестровая музыка
Однако на этот раз, поскольку мы сочетаем электронику и оркестровую музыку, мы решили записать оркестрованные партии с настоящим оркестром в настоящей студии. Разница, как известно, между синтетическим оркестром и настоящим может быть огромной.
Ощущения от игры с таким саундтреком должны быть как минимум заметными.
Запись сеансов
Запись музыки с традиционным оркестром – это большая задача, требующая длительного процесса и очень сложной координации. От музыкальной режиссуры и сочинения до оркестровки, координации всех музыкантов, аранжировок, записи, постпродакшена и т. д.
В случае с нашим саундтреком задействовано 174 профессионала, не считая команды Factorio.
Музыкальная продюсерская компания Soundsgate , которая представляет Петра, берет на себя весь этот процесс за нас.
Запись нашего саундтрека проходит с ноября 2023 года в студии Český Rozhlas в Праге.
Я публикую здесь несколько фотографий с первой записи.
Текущий саундтрек останется саундтреком к Наувис
Стиль саундтрека к Factorio 1.1 уже придал наш дорогой Дэниел Джеймс Тейлор. Петру пришлось адаптировать свою работу, чтобы продолжить работу над саундтреком Дэниела Наувис. Это не значит, что расширение саундтрека не добавит в игру новых красок и текстур. Совершенно наоборот. Новый контент расширения, как следует из названия, расширяет звуковой ландшафт Factorio в новых измерениях.
В общем, саундтрек пытается сопровождать игрока на протяжении всех мыслительных процессов, необходимых для игры, чтобы сосредоточить внимание во время проектирования заводов и их логистики. Поэтому музыка должна создавать сбалансированную и непринужденную атмосферу, позволяющую игроку сконцентрироваться.
Музыка не является украшением, она помогает игроку лучше погрузиться в игру, а также визуализировать то, что не показано на экране.
Мотив Факторио
Постоянным элементом всего саундтрека (я добавляю также работу Дэниела) является мотив Factorio. Я уверен, что это уже вытатуировано у тебя в мозгу. Помните мелодию, которая звучит при загрузке игры? Да, так и есть. Что ж, Петр разработал целую вселенную на основе этих парочек заметок.
Эта мелодия звучит по всем планетам с множеством разных настроений, ритмов и инструментов. Хорошая часть в том, что ты не слышишь это отчетливо, ты просто чувствуешь это. Это потрясающе, потому что создает такой целостный космос, который, несомненно, принадлежит Factorio. Одним из примеров является видео Вулкануса, представленное ниже.
Все планеты также разделяют идею чувства чуда. Мы хотим выразить, насколько невероятно приятно и позитивно открытие всех этих новых миров. В основе некоторых треков на разных планетах лежит эта идея.
Ограничения движка Factorio
У движка нет возможности сообщать музыкальной системе, что происходит в игре. Другими словами, музыкальная система понятия не имеет, находится ли игрок в центре битвы, уничтожая гнезда кусачих, или тщательно размещает транспортные ленты для удовлетворения потребностей растущей фабрики.
Этот факт сильно ограничивает творческие решения на момент написания партитуры. Представьте себе, что игрок тихо расставляет трубы, чтобы просто соединить 2 машины, и внезапно на заднем плане звучит эпическая боевая музыка. Это создало бы глупую ситуацию, а мы этого не хотим.
Решение, которое мы решили принять, заключается в том, что вместо того, чтобы пытаться проиллюстрировать само действие, нам лучше перейти к описанию пейзажа в более атмосферном решении. Атмосфера планеты и ее нюансы. Настроение и его вариации.
Музыка должна быть нейтральной, без сильных эмоциональных пиков, но с другой стороны она должна быть насыщенной и динамичной, иначе она станет скучной. Поэтому очень важно контролировать баланс между нейтральностью и выразительностью.
Есть 4 новые планеты + Космос, так что у нас будет 5 уникальных звуковых ландшафтов.
Каждая планета/поверхность имеет свое настроение, формы и дух. Игрок должен чувствовать, на какой поверхности сосредоточено действие, не глядя на графику. Ну это очень субъективный вопрос, иногда кому-то понятно, иногда не очень. Но вы поняли суть.
В начале проекта нам приходилось работать почти вслепую, потому что ни графика, ни игровой процесс не были полностью проработаны, только идеи, а это то, что нужно любому, чтобы что-то начать. Но теперь все по-другому: после всей работы, проделанной командой, мы можем начать демонстрировать небольшие елементы того, как все складывается воедино.
Все музыкальные отрывки и визуальные эффекты, представленные в этом посте, находятся в стадии разработки . Видео призваны служить доказательством концепций. Я сделал их, чтобы легко визуализировать все эти концепции, о которых я говорю. Надеюсь, они вам понравятся.
Космос
Космическая платформа самая сложная, поскольку у нее есть 2 режима: неподвижный в пространстве и движущийся. Поэтому мы решили охватить оба случая двумя взаимодополняющими элементами:
- Мы используем космическую атмосферу (очевидно) с небольшим количеством синтетической электроники, пытаясь описать, каково это — плавать в холодной пустоте Вселенной.
- Мы используем ритмичный бас для ощущения движения платформы, мощные двигатели, толкающие большую массу металла. Как космический паром, «медленный», но неудержимый.
Вулкан
Мрачный, гнетущий, горячий и тяжелый. Но тоже замечательно.
Нам показалось очень связным и уместным использовать длинные аккорды духовых инструментов. Они указывают на великолепие этого фантастического ландшафта, контрастирующего с опасными вулканами и лавой.
Фульгора
Основной темой в этой области является электромагнетизм. Мы стремимся к большему количеству электрических звуков. Петр провел множество экспериментов со звуком электричества. Например, постукивать пальцем по аудиоразъему и записывать им ритмы, а затем манипулировать им для использования в композициях.
Отрывок, показанный в этом видео, хорошо это иллюстрирует.
Остальные 2 планеты
В будущем мы расскажем больше о других планетах, пока это нераскрытые темы. Но я не могу удержаться и не показать еще немного, на этот раз без графики. Послушайте этот трек и представьте себе далекую и неизведанную планету, полную...
Более 5 часов саундтрека
На каждой поверхности игры звучит около 1 часа музыки. Это значит, что нам нужно проиграть 5 часов саундтрека, +1 час Наувиса. На следующей неделе мы поговорим о некоторых методах, которые мы разработали, чтобы не только покрыть этот промежуток времени, но и превзойти его.
Что дальше?
Теперь у нас есть все демо и записи оркестрованных партий. У нас еще нет окончательных миксов, только несколько премиксов Петра. Каждый шаг в этом процессе приводит к изменениям, обычно в лучшую сторону.
Мы также начинаем лучше видеть графику и игровой процесс. Итак, я собираюсь поместить весь этот материал в движок перед окончательными миксами, чтобы протестировать его и получить обратную связь.
Я совершенно уверен, что мы сможем настроить весь саундтрек таким образом, чтобы окупить всю энергию, которую Петр (и все участники) вложили в такой сумасшедший проект.
Следите за обновлениями.
Factorio Игры Factorio Dev Diary
Factorio Dev Diary #405 - Whole belt reader, New logistics GUI
Сегодня у нас есть целый ряд новых функций и улучшений, которые появятся в версии 2.0.
Считыватель всего конвеера
Часто хочется прочитать содержимое целой линии? Возможно, вы готовите суши или просто хотите получить точную оценку того, сколько вещей у вас есть, не помещая их в сундук.
Способ сделать это — прочитать каждый конвеер, но у этого метода есть некоторые недостатки:
- Уродливость
- Неэффективность
- Скучность
- Скрывает предметы на ремнях.
- Не работает для подземных конвееров
Более быстрые последующие запуски ракет
В поздней игре вы можете создавать и готовить ракеты довольно быстро, но всегда было узкое место в производительности: красиво созданная анимация занимала много времени.
На самом деле нам не хотелось увеличивать скорость анимации, так как это могло выглядеть немного странно. Но мы нашли компромисс:
- Ракетная шахта позволяет создать и разместить внутри дополнительную ракету.
- После запуска, если есть буферизованная ракета, последовательность закрытия и открытия двери пропускается.
Фильтры для насосов
Вы запутались в каком-то поезде, и они вылили целую кучу смазки в ваши запасы сырой нефти? Раздражает, не так ли? Добавление фильтра к насосам было технически возможно уже давно, нам оставалось лишь добавить графический интерфейс.
Новый графический интерфейс логистических сетей
Графический интерфейс логистической сети был добавлен еще в версии 0.15 и с тех пор претерпел лишь косметические изменения.
Логистический графический интерфейс в версии 0.15 (первая версия).
Несмотря на свою функциональность, графический интерфейс использовался мало и оставлял желать лучшего.
Итерация 1
Новый графический интерфейс обзора поездов ( FFF-364 ) стал выигрышной формулой в моей книге, поэтому давайте просто попробуем скопировать его:
- Список сбоку для классификации вещей.
- Миникарты для предоставления конкретной информации о каждом отдельном связанном элементе.
Была большая проблема, которую я избегал, а именно выбор сети. Выпадающее решение плохое по нескольким причинам:
- Вы не можете идентифицировать сети в раскрывающемся списке, единственная информация, которую нужно указать, — это количество ячеек (робопортов).
- Для изменения сети требуются дополнительные утомительные щелчки мышью, поэтому поиск нужной сети занимает еще больше времени.
Итерация 2
Здесь я попробовал заняться выбором сети. Первым шагом был переход от раскрывающегося списка к списку. Мгновенно лучше. Вторым шагом было добавление значка спереди, чтобы различать мобильные сети и сети робопортов. Итак, мы куда-то движемся.
Но самой большой проблемой по-прежнему остаётся идентификация сетей. Я пришел к выводу, что, по сути, единственный способ идентифицировать сеть — это посмотреть на нее.
Поэтому я добавил мини-карту «Выбранная сеть». Это весьма нативно. Я могу быстро просмотреть сети в списке и визуально идентифицировать сети с помощью мини-карты.
Однако графический интерфейс начинает выглядеть монстром. У нас есть два списка, и чтобы заполнить немного места, я добавил случайную информацию о сети и множество мини-карт...
Итерация 3
После некоторого тестирования я определил, что мини-карты отдельных предметов оказались не такими уж полезными. Имея это в виду, я мог бы изменить ситуацию.
Эта итерация основывалась на идее, что список элементов не так уж и полезен. В логистических сетях вас обычно не волнует, где находятся товары, вас волнует только то, достаточно ли их в системе. Поэтому я удалил список элементов и добавил общую таблицу значков. Это означает, что мы можем разместить на экране гораздо больше из них.
Попользовавшись им некоторое время, я понял, что это правильный путь. Требовалось лишь несколько доработок:
- Это странно непропорционально.
- Миникарта имеет прямоугольную форму.
- Таблица предметов слишком широка.
Итерация 4
Итак, улучшение явное, отодвигаем предметы в сторону. Это дает нам больше высоты, а это значит, что мы можем сделать мини-карту квадратной и больше.
Второе улучшение произошло благодаря использованию последнего графического интерфейса: количество «участников» обычно довольно мало, максимум 5-10. Таким образом, вкладка «Участники» часто выглядела пустоватой по сравнению с тем, сколько места было зарезервировано на вкладке «Элементы». Так что нет особого смысла размещать их во вкладках. Мы всегда можем показать и то, и другое, потому что маловероятно, что участники станут слишком большими, чтобы мы могли с ними нормально справиться.
Остальная часть графического интерфейса здесь довольно хорошо очищена.
Поскольку у нас перед глазами эта большая красивая карта, имеет смысл заставить взаимодействие выбора работать только с миникартой. Еще одна приятная небольшая функция, которую мы добавили, — это возможность переименовывать логистические сети, чтобы вы могли отслеживать события по-своему.
Интеграция с удаленным просмотром
Однако с графическим интерфейсом все еще была проблема: это был «настоящий графический интерфейс», он занимал весь экран, а мини-карта не допускала нормального взаимодействия с картой.
Итак, последнее изменение заключалось в переработке графического интерфейса логистических сетей, чтобы он стал «приклеенной» панелью удаленного просмотра. Это позволяет нам сохранять видимыми все обычные графические интерфейсы, такие как панель быстрого доступа и инвентарь, позволяет вам создавать и изменять вещи в обычном режиме, а графический интерфейс логистики предоставляет логистическую информацию.