Монолит (Monolithic)

Собственно, начнём мы с оклемённым всеми Монолитом. Причина его включения в данный список проста: он всё ещё актуален и он всё ещё имеет свои преимущества.

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

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

Как ни крути, нам будет полезно сравнить остальные Архитектурные стили с Монолитом и ответить на вопрос: а действительно он так плох, как о нём говорят.

Сервисо-ориентированная архитектура (Service-Oriented Architecture или SOA)

Среди всех остальных Архитектурных стилей Сервисо-ориентированная самая непопулярная из-за её множества проблем, но именно она помогла отойти от концепции Монолита и тихо-мерно прийти к концепции Микросервисов.

Суть SOA заключается в попытке разбиения сервисов по логическим задачам и связывании их через некую "Сервисную шину". Сама шина занимается только тем, что забирает ответы от одних сервисов и передаёт этот ответ на выполнения другим, а потом забирает ответ и передаёт третьим и так далее до достижения некого финала (возврат ответа пользователю или занос результата в некое хранилище).

Как и Монолит, SOA так же имеет смысл внести в наш список для того, чтобы был предмет для сравнения.

Основанная на сервисах архитектура (Service-Based Architecture или SeBA)

Хоть от SOA от отказались как "неудачный опыт", найти что-либо в Гугле по нему было значительно легче, чем по Service-Based Architecture. Но сложно не невозможно, так что приступим.

Данный Архитектурный стиль является логическим развитием SOA и, относительно её, заключается в двух ключевых изменениях: первое, переход от Сервисной шины к API; второе, перевод логики определения передачи результатов сервиса на сам сервис (то есть теперь не шина решает, куда передать результат дальше на вычисление, а сам сервис). Если говорить проще, то SeBA является попытка сделать SOA проще для дальнейшей разработки. Ну и да: именно где-то тут начали пихать всё не в один исполняемый процесс, а переходить на мультипроцессное исполнение и ковайный API. А если ещё для каждого сервиса сделать свою БД и вынести Web-часть - уже получится знаменитая Микросервисная архитектура.

Эти изменения дали свои плюсы, но полностью ощутить мы их сможем только уже в ходе эксперимента.

Основанная на пространствах архитектура (Space-Based Architecture или SpBA)

Другая попытка отойти от проблем SOA есть данный Архитектурный стиль, но если SeBA нацелен больше на попытку упростить процесс разработки, SpBA нацелен на попытку решить проблему с масштабированием приложения для принятия больших нагрузок. Ну и тот факт, что информации в Гугле по SpBA значительно больше, чем по SeBA недвусмысленно говорит нам о том, что в мире ПО более важна именно работа под большой нагрузкой, чем обилие различных фич (но это не точно)

Кратно разберём данный Архитектурный стиль. В попытках принять большую нагрузку на своё приложение SOA ушло в чуть другую плоскость - использовать реплицированную In-Memory для хранения обрабатываемой информации, а так же небольшой модуль для управления всем этим процессом. Это даёт хороший буст в плане масштабировании, но и привносит ряд сложностей.

С продумыванием концепции In-Memory в Factorio у меня явно будут определённые сложности, но как-нибудь решим их.

Событийно-управляемая архитектура (Event-Driven Architecrute или EDA)

В данном Архитектурном стиле мы впервые начинаем использовать концепцию очередей - именно ими хотели во всём том же SOA закрыть проблему масштабирования и сложности разработки одновременно.

Если кратко разобрать принцип работы EDA, то можно сказать так: в SOA разбили Сервисную шину на очереди и управление очередью (т.н. "Брокер/Медиатор"). Теперь программистам достаточно кодить сами сервисы и просто задавать логику работы медиатра, а эксплуатации просто подключать к очередям столько экземпляров сервисов, сколько надо.

Самое плохое в данном Архитектурном стиле, что медиатор может работать в двух режимах: собственно, режим Брокера (тупая, заданная последовательность) и режим Медиатора (на основании внутренней логики). Как мы будем реализовывать это в Factorio и как нам реализовать два этих режима - ещё не понятней, чем с In-Memory (но это проблемы не мои... это проблемы будущего меня... так что... иди к чёрту будущий Я).

Микросервисный (Microservices)

У нас будет самый распиаренный Архитектурный стиль из всех актуальных - Его Превосходительство Миркосервисный Архитектурный стиль.

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

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

Игра==Компания/Бизнес.

Тут всё просто: мы туда приходим, что-то строим, генерируем единицу пользы и жаждим получить со всего этого выгод

Планета==Проект.

По сюжету игры наш персонаж терпит крушение на чужой планете и всё что у него есть: это немного стартовых инструментов/предметов и локальный Гугл для изучения методов производства различных технологических штук. В общем Планета является аналогией нашего продуктового проекта.

Жуки==Бюджет.

В Мире/Проекте есть ограничивающий фактор, который ограничивает наш бесконечный рост. В компании это продуктовый бюджет, в Factorio - жуки. Если мы начнём разрастаться так, что бизнес уже начинает нервничать в виду возросших расходов на всё это добро - оно начнёт пихать в палки в колёса; если мы в ходе строительство своих зданий начнём загрязнением задевать территорию жуков - они начнут волноваться и нападать. Так или иначе, аналогия похожа: если мы переходим какие-либо пределы - начинается сопротивление. И чем дальше заходим, тем сопротивление больше. В игре жуки хорошо ещё тем, что чем больше вы хотите захватить территорий - тем сложнее эту территорию зачищать и оборонять (если кто не знает - чем дальше он спавна, тем сильнее охрана улий Жуков и тем их больше по количеству). Всё это просто идеально похоже на запрос дополнительного бюджета: чем больше/чаще мы его запрашиваем, тем больше/чаще ловим вопросы вида "Обоснуйте затраты".

Так же Жуки, при определённых обстоятельствах переквалифицируются в хакеров, но это мы рассмотрим ниже

Площадь==Расходы

Вытекающий из предыдущего пункта Жуков/Бюджета: если мы будем занимать малую площадь под свои заводы или обходиться компании малыми расходами - Бизнес нам слова не скажут. Соответственно, чем меньше у нас в итоге наши строения будут занимать площади, тем лучше мы справимся в плане расходов, но и тем больше проблем мы испытывает с ограниченным пространством (иначе говоря, можно сразу делать запас площади под постройки и сразу же наткнуться на Жуков/Бизнес, а можно экономить пространство, но зато лишний раз испытывать сложности с втулением вон той трубы через ровный строй заводов).

Исследования/Ракета==Доходы.

Что приносит Бизнесу доходы? Пользователи. Что хотят пользователи? Много фич. Что нужно сделать в Factorio? Добиться цели постройки ракеты. Что нужно, чтобы создать ракету? Провести тонны исследований и реализаций этих исследований.

В обоих случаях у нас работает правило "Чем быстрее, тем лучше", а значит тут мы попали в аналогию на 100%. В итоге у нас получается хорошая картина: чем быстрее мы сможем достичь конечной цели, тем лучше.

Единственное, тут есть пару оговорок:

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

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

Персонаж==Команда.

В игре в распоряжении у нас один человек и на него придётся взвалить все аспекты команды: он и придумывает, он и реализует, он и занимается тактикой и стратегией, он и воюет с жуками. В общем ДиректороАналитикоПрожектоАрхитектороПродуктоПрограммист в одном лице. Единственное отличие, что он всё это не может делать одновременно, но поскольку эти ограничения выступают константой - на наше исследование они погрешности не даст.

Месторождения==Пользователи.

Они приходят и просто вливают в наш продукт кучу запросов. Но Бизнес этому только рад и просит освоить ещё и ещё новых месторождений.

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

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

Конвейер/Трубы==Переменная.

Мы туда что-то положили, куда-то переместили и использовали где-то в другом месте. Идеально.

Предметы/Жидкости==Данные.

Они хранятся либо в переменных (Конвейеры/Трубы типа ОЗУ), либо на долговременной памяти (Ящики/Резервуары типа ПЗУ). Соответственно, чем их больше, тем больше затрат на ту или иную ЗУ.

Завод/Фабрики/Печи==Вычисления.

Берём значение из переменных/конвейеров и как-то ими манипулируем в попытке добиться некого промежуточного итога.

Буры/Скважины==Браузер.

По сути это просто способ доставки запросов пользователей в наше приложение. Просто и тупо.

ЖД==Сеть.

Те же переменные с некой полезной информацией, но перемещаемой на большие расстояния. Ну и она не мгновенная и не резиновая - всё как в жизни.

Электроэнергия==Стенды.

Чем больше объёмов мы захотим, тем больше всего настроем и тем больше оно будет потреблять энергии. Большой проект будет требовать больше стендов как по количеству, так и по качеству, а затраты электроэнергии позволят это отследить в сумме. Так же это позволит нам ещё проверить соотношение площади застроек к потреблению электроэнергии и точно убедиться, что мы считаем Расходы верно.

Манипуляторы/Насосы==Программная логика.

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

Загрязнения==Перерасход.

Идеального кода/автоматики/стендов не бывает и по любому будет что-то неоптимизированно/криво/косо. Когда мы достигнем определённого Загрязнения/Перерасхода, то сразу же взбудоражутся Жуки/Бизнес и придётся иметь с ними дело. Именно поэтому я поставил переход на Атомную энергетику как основную цель. Именно поэтому у нас идёт настоящий пункт.

Стены/Турели==Отчёты/ИБ.

Жуки/Бизнес с определённого этапа развития продукта начнёт банально мешать производству: Бизнес будет требовать различные отчёты, объяснения, корректировки и прочее; Жуки - просто приходить и крушить. Постройка и обслуживание Стен и Турелей как раз является хорошим примером "отвлечения" на все эти мешающие аспекты.

Так же у Стен/Турелей есть и другой аспект отвлечения - это вопросы ИБ. Достаточно нередко бывает так, что команда просто пилит себе крутой продукт, а тут приходят ИБ и просят вне плана срочно закрыть какую-то уязвимость. И это будет таким же "мешающим" фактором, как и Отчёты для Бизнеса. В общем, у нас два в одном, и с учётом необходимости расширения затраты на оборону будут только расти.

Радары==Мониторинг.

Тут всё просто: затраты сравнительно малые, но позволяют следить за тем, что как работает.

Лаборатории==Бизнес-логика.

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

• Evolvability - возможность развития. Показывает, как быстро продукт может обрастать различными фичами. Относительно игры, это скорость проведения исследований и скорость достижения двух, основных целей: запустить ракету и перейти на атомную энергетику. Замерять будем по ходу игры;

  • Сценарий:

    • Если выполнилось исследование или частично/полностью выполнилась цель игры - фиксируем время игры;

    • Повторять до победы.

• Perfomance - производительность. Показывает, сколько пользователей сможет потянуть приложение. Относительно игры это соотношение производства сырья ключевых ресурсов (железные/медные плиты, различные микросхемы) к количеству финальных ресурсов (различные исследовательские пакеты, спутники, части ракеты, урановое топливо). Именно соотношение нам покажет на сколько нам придётся потратиться, чтобы сделать одну единицу пользы. Замерять будем после финала;

  • Сценарий:

    • Убиваем всех жуков;

    • Убираем манипуляторы к не целевым производствам;

    • Отключим пути для сырья от всего, кроме частей ракет и спутников;

    • Ждём, когда производство стабилизируется;

    • Замеряем производство частей ракет и спутников за 1 час.

• Deployability - разворачивание. Насколько быстро можно развернуть второй и последующие экземпляры продукта. Опять же просто применим вертикальное масштабирование и замерим время. Замерять будем после финала;

  • Сценарий:

    • Убиваем жуков;

    • Изучаем скорость (10) и грузоподъёмность (3) дронов до 6;

    • Копируем основной завод на свободное место;

    • Засекаем время;

    • Строим второй завод из собственных запасов построек;

    • Подключаем столько же месторождений (только железо и медь);

    • Подключаем поставку воды;

    • Подключаем ЖД сеть.

• Scalability - масштабирование. Оно показывает, насколько безболезненно приложение сможет вырасти горизонтально или вертикально. Под горизонтальным ростом у нас будет идти попытки увеличить производительность за счёт увеличения числа заводов в существующей цепочке; вертикальное - создание второй цепочки (за одно и проверим Deployability). Замерять будем после финала;

  • Сценарий:

    • Замеряем производство при вертикальном масштабировании:

      • Строим дополнительные фабрики на территории текущего завода;

      • Замеряем производство частей ракет и спутников за 1 час.

    • Замеряем производительность при горизонтальном масштабировании:

      • Строим вторую копию завода по чертежам (то, что делали в Deployability);

      • Подключаем новую ЖД-сеть к старой;

      • Удваиваемым количество поездов (только железо и уголь);

      • Замеряем производство частей ракет и спутников за 1 час.

    • Сравниваем полученный прирост после обоих типов масштабирования с тем, что мы получили Perfomance.

• Agility - гибкость. Сколько времени требуется, чтобы разработать новую фичу. Относительно игры это сколько потребуется времени, чтобы открыть новое производство чего-либо. Замерять будем по ходу игры, но c момента изучения и внедрения ЖД;

  • Сценарий:

    • Если мы запускаем новое производство чего-либо необходимого на данный момент - фиксируем время;

    • Повторяем до победного.

• Fault Tolerance - отказоустойчивость. Насколько приложение хорошо переживает разные сбоя. В игре будем пробовать "ломать" различные участки завода и смотреть, что из этого получится. Так как поломать систему можно двумя способами (кривыми руками и чрезмерной нагрузкой), то и реализуем мы два сценария. Замерять будем после финала;

  • Сценарий 1:

    • Отключаем подачу патронов в турели;

    • Засекаем время;

    • Убегаем в безопасное место;

    • Ждём, когда прекратится производство частей ракеты;

    • Фиксируем время.

  • Сценарий 2:

    • Фиксируем текущее количество поездов;

    • Спавним локомотивы, вагоны и топливо;

    • Засекаем время;

    • Равномерно заполняем ЖД поездами под разные маршруты. До упора. С паузами ~5 минут;

    • Ждём, когда прекратится производство частей ракеты;

    • Фиксируем время;

    • Фиксируем общее количество поездов

• Configurability - возможность конфигурации. Как гибко можно управлять приложением для подстройки его под текущие приоритеты. Замерять будем путём попытки перевести избыток продукции на место, где испытывается недостаток (например, перевести всё на части ракеты). Замерять будем возможность сделать это и какой прирост получим к целевой продукции по факту реализации. Замерять будем во время игры, ближе к финалу;

  • Сценарии:

    • Фиксируем, какие производства мы перенаправляли;

    • По завершению - замеряем увеличение целевого производства за 1 час.

• Domain Partitioning - разделение обязанностей. Если к приложению можно сказать, что вон та его часть отвечает за то-то и только за это - значит у нас хороший показатель. При этом, если у нас появляется множество мелких и плотно расположенных зон - значит это плохо. Замерять будем после финала;

  • Сценарий:

    • Делаем скриншот карты без отметок;

    • Цветами разделяем различные производства;

    • Считаем количество мелких, плотноприлегающих друг к другу зон.

• Abstraction Level - абстрагирование. Показывает, насколько хорошо определённые компоненты приложения выполняют какую-то глобальную задачу (бизнес-логика, оркестрация, хранение и прочее). В игре мы поделим всю нашу карту на зоны "пользователи", "сырьё", "хранение" и прочее и попробуем связать всё это стрелками друг с другом. Если у нас получится много мелких зон с парой стрелок - это хуже, чем одна большая зона с множеством стрелок. Будем замерять после финала;

  • Сценарий:

    • Делаем скриншот карты без отметок;

    • Цветами разделяем следующие зоны:

      • Ресурсы - добыча их aka "Пользователи";

      • Переработка ресурсов - переработка сырья aka "Frontend";

      • Основной завод - центральное производство конечной продукты aka "Backend";

      • Элетро - электростанция aka "ЦОД";

      • Ж/Д - точка поставки ресурсов aka "API/HTTP(S)";

      • Хранилище - место складирования чего-либо aka "БД";

      • Шина - место логического управления производством ака "Оркестрация"

    • Замеряем, сколько зон пересекаются друг с другом и сколько из них дублируется.

• Elacticity - эластичность. Как приложение может самоподстраиваться под текущую нагрузку. Тут уже отдельно замерять ничего не надо, а просто сложим показатели Scalability и Deployability. Замерять будем после финала.

  • Сценарий:

    • Получаем от горизонтального Scalability процент прироста производства;

    • Получаем от Deployability время разворачивания экземпляра завода;

    • Получаем некое контрольное число для сравнения по формуле: Scalability(%) x Deployability(min)

• Testability - тестирование. Насколько хорошо приложение поддаётся тестированию. В игре мы будем пробовать находить узкие места при помощи буста входных ресурсов и замера производительности - наша задача тут, замерить сколько потратиться времени на сам замер и на попытки улучшения производительности. Будем замерять после финала;

  • Сценарий:

    • Целимся на производство частей ракеты:

      • Засекаем время;

      • Подключаем несколько бесконечных сундуков с компонентами для частей ракеты чуть дальше непосредственного места производства этих компонентов
        Замеряем производство частей ракеты за 1 час (это будет контрольный замер);

      • Фиксируем время;

      • Засекаем время;

      • Повторяем для компонентов для модулей управления ракетами, сплавов и замерим производство частей ракеты;

      • Замеряем производство частей ракеты за 1 час;

      • Фиксируем время;

      • Повторяем для сырья для компонентов для модулей управления ракетами, сплавов и замерим производство частей ракеты;

      • Замеряем производство частей ракеты за 1 час;

      • Получаем обзор того, где находятся наиболее медленные части производства.

• Cost - стоимость. Насколько дорого обходится разработка и обслуживание продукта. По сути мы просто в игре замеряем площадь, занимаемой нашим заводом, общую площадь построек и, отдельно, сравним его с энергопотреблением. Замерять будем после финала.

  • Сценарий:

    • Делаем скриншот карты без отметок;

    • Узнаём координаты угловых частей общих построек;

    • Узнаём координаты угловых частей общего производства;

    • Высчитываем площадь двух получившихся фигур.

В общем, работы предстоит много. Самое главное тут не выбрать прямо точный регламент проведения эксперимента для замера того или иного параметра, а делать каждый эксперимент с одинаковым подходом и единым итогом - в конце концов нам важно именно сравнить Архитектурные стили друг с другом.

• Режим игры - стандартный;

• Всегда берём одну и ту же сгенерированную карту

  • Зерно - 2426146951

  • Ресурсы - стандартные;

  • Вода - максимальный масштаб, покрытие 50%;

  • Деревья - всё минимум

  • Скалы - отключены;

  • Тип местности - стандартный;

  • Враги:

    • Вражеские базы - стандартные

    • Размер начальной области без жуков - максимальная;

    • Экспансия - отключена;

    • Эволюция - отключена;

• Сложность:

  • Стоимость рецептов - стандартная;

  • Загрязнение - стандартная;

  • Во время основной игры - можно использовать:

    • Команду на замер времени жизни карты - для фиксации времени важных событий;

    • Команду на вывод координат (мало ли пригодится);

    • Чит на перемотку времени. Стоять без дело придётся часто и пожалейте моё время

    • Чит на спав стартового комплекта вещей (об этом ниже) для идентичности лабораторных условий;

      • Если часть стартового комплекта потеряется во время игры (кроме тех, что с меткой "невосполнимый") - можно заспавнить новый взамен;

  • После финала - можно:

    • Всё вышеуказанное;

    • Чит на удаление врагов;

    • Чит на спавн вещей для создания логических цепей;

• Искусственные ограничения:

  • Нельзя производить предметы руками - исключительно в зданиях. Причина проста - чтобы не сбивать ручным производство итоговую статистику;

  • Нельзя использовать "синие" типы конвейеров. Возьмём красные конвейера как максимально возможные для того, чтобы сравнение Архитектурных стилей было максимально лабораторным;

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

  • Нельзя наполнять заводы вручную - только выкладывать на конвейер (вручную или через манипулятор). Исключение - добавление твердотельного топлива. Сделано это, чтобы не возникал соблазн перетаскивать сырьё вручную в разные части базы и тем самым вручную увеличивать производительность (реально, выглятит так, как будто если посадить программиста на Прод, то он будет производить расчёты вместе с компьютером... бред);

  • Нельзя использовать транспортные или строительные дроны (кроме стартовых строительных на персональной дронстанции). Дроны дают хороший буст в производстве под конец игры, но при этом сводят архитектурный аспект к минимуму - поэтому на это накладывается запрет;

  • Нельзя использовать логические сети до финала игры. Логические сети сильно скажутся на времени постройки завода: они имеют непредсказуемое время реализации и непредсказуемое окупаемость. И то и то будет паразитно в сравнении;

  • Нельзя ставить игру на паузу для продумывания дальнейших действий - пауза только для перерывов и естественных потребностей. Это позволит учитывать и время обдумывания какого-то решения, которое всегда присутствует в работе команды разработки. В общем, берём это в учёт;

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

  • Никаких модов. Только стандартный геймплей.

• Искусственные привилегии:

  • Стартовый набор вещей:

    • Силовая брона МК2 х1

    • Портативный термоядерный реактор х2

    • Экзоскелет х4

    • ПНВ х1

    • Устройство игнорирования конвейров х1

    • Персональная дронстанция МК2 х4 (игра без дронов всё ровно что написание кода без копипаста)

    • Малый блок аккумуляторов х7

    • Строительные дроны х100

    • Автомобиль х1

    • Пистолет-пулемёт х1

    • Патроны х210 (невосп)

    • Деревянный ящик х100 (невосп)

    • Желтый конвейер х5000 (невосп)

    • Подземный желтый конвейер х100 (невосп)

    • Разделительный желтый конвейер х100 (невосп)

    • Желтый манипулятор х200 (невосп)

    • Красный манипулятор х100 (невосп)

    • Деревянный ЛЭП х1000 (невосп)

    • Труба х5 (невосп)

    • Бойлер х5 (невосп)

    • Паровой генератор х5 (невосп)

    • Бур х50 (невосп)

    • Насос х1 (невосп)

    • Твердотельный бур х31 (невосп)

    • Каменная печь х51 (невосп)

    • Серая фабрика х50 (невосп)

    • Разбитый корабль х1 (невосп)

    • Древесина х1 (невосп)

    • Пистолет х1 (невосп)

    • Железная плита х8 (невосп)

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

В общем, всё это выглядит вот так:

Ссылка на сценарий (Поместить в %USER%\AppData\Roaming\Factorio\scenarios)

Так же сценарий позволяет делать одну крутую вещь - записывать реплей.

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