Недоигра
Не знаю зачем я это выкладываю, но вот мой недопроект, являющийся дипломной работой по курсам.
Вот сам недопроект для Linux систем:
https://github.com/vertil/heli_game
Не знаю зачем я это выкладываю, но вот мой недопроект, являющийся дипломной работой по курсам.
Вот сам недопроект для Linux систем:
https://github.com/vertil/heli_game
Я всех горячо приветствую!
Постов не было примерно две недели. За это время я:
- добавил поддержку двух языков, русского и английского;
- навел порядок с код-стайлом и залил всё в репозиторий на гитхабе;
- занимался поиском референсов для UI/UX дизайна.
Дело понемногу идет вперёд, ведь:
«Неважно, как медленно ты движешься. Главное, что ты не останавливаешься». — (с) Гача актёры.
По проекту:
- художник прислал мне новые ресурсы;
- один мой знакомый предложил мне помощь по прогерской части.
Следующее на очереди: менеджер окон и тултипы.
сегодня практикуем лаконичность =)
всем спасибо и до новых встреч!
Дневник разработки. the_proger
Я никогда не умел писать, но мой коллега уговорил меня завести блог, в котором я мог бы поделиться ходом разработки моей инди-игры. делается она моими нежными ручками, в свободное от работы время.
У меня есть некоторый опыт разработки игр, а именно около 2-х лет. этот проект я решил твердо довести до конца(уровень твердости - шоколадка на батарее).
что мы имеем сейчас:
- несколько спрайтов нарисованных мною в Paint.
- некоторую базовую логику.
- реализацию схемы event-subscribers для оповещения о внутриигровых событиях.
- классы кнопок
- некоторые другие плюшки.
Что касается технической части:
- C++ 20
- SFML
если будет разрастаться придется переписывать на какой-нибудь более приличный движок, поэтому стараюсь не путать уровни абстракций - не мешать движковую часть, игровую логику, логику ui и тд.
Все спрайты будут заменены на нормальные, сейчас на этапе поиска художников и согласования стиля. Визуал вообще в бете претерпит изменения все что есть сейчас нужно для разработки и является грубым наброском... но ковер конечно шикарный.
Описание концепта возможно будет позже...
До новых встреч.
Include-What-You-Use (IWYU), означает, что исходный код движка включает в себя только те зависимости, которые ему необходимы для компиляции. Цель IWYU состоит в том, чтобы избежать включения монолитных заголовочных файлов, таких как Engine.h или UnrealEd.h, тем самым уменьшая лишние зависимости. Следующее справочное руководство расскажет вам, что это значит для IWYU, включая объяснение того, как включить IWYU для вашего проекта. Кроме того, если вы решите использовать режим IWYU для своих игровых проектов, вы узнаете несколько общих советов, которые помогут вам получить максимальную отдачу от работы в режиме IWYU.
Режим IWYU по умолчанию отключен для игр и игровых плагинов; однако режим IWYU по умолчанию включен для модулей Engine и Engine.
В предыдущих версиях Unreal Engine 4 (UE4) большинство функциональных возможностей движка было включено через большие, ориентированные на модули заголовочные файлы, такие как Engine.h и UnrealEd.h и быстрое время компиляции зависело от того, какие файлы быстро компилируются с помощью Precompiled Header (PCH).
С IWYU каждый файл включает в себя только то, что ему нужно, а любой файл PCH, который мы выбираем для использования, действует как слой оптимизации поверх базовых исходных файлов. Их можно изменить, чтобы уменьшить время сборки, независимо от изменения самих исходных файлов и без влияния на то, успешно ли компилируется код.
При написании кода IWYU мы принимаем 4 конкретных соглашения:
1. Все заголовочные файлы содержат свои необходимые зависимости.
2. Файлы .cpp сначала включают соответствующие им файлы * .h.
3. Файлы PCH больше не включены явно.
4. Монолитные заголовочные файлы больше не включены.
Соглашения IWYU
Следующие описания соглашений IWYU должны дать вам хорошее представление о правилах для IWYU.
1. Все заголовочные файлы содержат свои необходимые зависимости.
- Существует заголовочный файл CoreMinimal, содержащий набор вездесущих типов (включая FString, FName, TArray и т.д.) из UE4 Core.
- Заголовочный файл CoreMinimal (расположенный в корневом каталоге UE4 по адресу \Engine\Source\Runtime\Core\Public\CoreMinimal.h) сначала включается в большинство заголовочных файлов движка.
- В модуле Core большинство заголовочных файлов включают в себя заголовочный файл CoreTypes.h. Это включает только определения типов для примитивных типов C++, макросы сборки UE4 и директивы для настройки среды компиляции.
Основной вывод заключается в том, что каждый заголовочный файл теперь содержит все, что ему нужно для компиляции.
2. Файлы .cpp сначала включают соответствующие им файлы * .h.
- Чтобы убедиться, что все ваши исходные файлы включают в себя все необходимые зависимости, скомпилируйте игровой проект в режиме non-unity с отключенными файлами PCH.
3. Файлы PCH больше не включены явно.
- Хотя файлы PCH все еще используются, они принудительно включаются в командную строку компилятора UnrealBuildTool (UBT).
4. Монолитные заголовочные файлы больше не включены.
- Компилятор выдаст предупреждение, если ваш код содержит монолитные заголовочные файлы (такие как Engine.h или UnrealEd.h).
Монолитные заголовочные файлы все еще существуют в UE4 для совместимости с игровыми проектами, и (по умолчанию) предупреждение не будет выводиться, если ваши игровые проекты включают их.
Включен ли IWYU
До установления соглашений IWYU с выпуском версии 4.15 код UE4 обычно включал файл PCH вверху каждого файла CPP, что противоречит тому, что разработчик хочет, чтобы код был совместимый с IWYU. Следуя соглашениям IWYU, файлы PCH можно рассматривать как уровни оптимизации во время компиляции, которые применяются отдельно от того, как изначально создавался код. Таким образом, вместо того, чтобы создавать и включать файлы PCH, мы оставляем за UBT решать, какой файл PCH использовать (если он есть).
Если вы хотите убедиться, что IWYU включен, и убедитесь, что модуль соответствует соглашениям IWYU, откройте файл модуля * .build.cs и убедитесь, что для PCHUsage установлено значение PCHUsageMode.UseExplicitOrSharedPCHs.
Установка PCHUsageMode.UseExplicitOrSharedPCHs в PCHUsage создает явный файл PCH для модуля, только если он имеет параметр PrivatePCHHeaderFile в файле * .build.cs модуля. В противном случае модуль использует общий PCH с другим модулем, что избавляет инструмент от создания большего количества файлов PCH, чем необходимо. Также имейте в виду, что при включении режима UseExplicitOrSharedPCHs исходный файл должен включать соответствующий ему заголовочный файл. В качестве альтернативы, если вы хотите, чтобы модуль отказался от соблюдения соглашений IWYU, вы можете установить для PCHUsage значение PCHUsageMode.UseSharedPCHs.
После преобразования кода в модель IWYU мы наблюдали значительные улучшения со временем компиляции UE4.
Работа в режиме IWYU
Если вы запускаете свою игру в режиме IWYU, вам необходимо убедиться, что ваши файлы .cpp включают в себя соответствующие им файлы .h. Это полезная практика, поскольку она позволяет компилятору гарантировать, что файл * .h включает все необходимые ему зависимости (когда файлы PCH и сборки Unity отключены). Unreal Build Tool (UBT) выдаст предупреждение, если вы не включите соответствующий заголовочный файл в начале (для соответствующего CPP-файла).
Если вы хотите отключить компилятор от выдачи предупреждений, вы можете установить для bEnforceIWYU значение false в файле модуля * .build.cs.
Если вы хотите отключить предупреждение для всего таргета, вы можете установить для bEnforceIWYU значение false в файле * .target.cs.
Общие советы
Если вы хотите выбрать IWYU для вашей игры, необходимо помнить несколько советов:
1. Включите CoreMinimal.h вверху каждого заголовочного файла.
2. Чтобы убедиться, что все ваши исходные файлы включают в себя все необходимые зависимости, скомпилируйте игровой проект в режиме non-unity с отключенными файлами PCH.
3. Если вам нужен доступ к UEngine или GEngine, подключите заголовочный файл находящийся по этому пути: Runtime\Engine\Classes\Engine\Engine.h (вместо монолитного заголовочного файла, который находится в Runtime\Engine\Public\Engine.h).
4. Если вы используете класс, который компилятор не распознает и вы не знаете какие заголовочные файлы нужно подключить, заголовочный файл класс можно убрать. Это особенно актуально если вы конвертируете код не принадлежащий IWYU, который скомпилирован правильно. Вы можете найти класс в документации API и найти необходимые модули и заголовочные файлы.
Чтобы помочь пользователям преобразовать существующие проекты на C++ в стиль IWYU, разработчики выпустили IncludeTool, который вы можете найти в \Engine\Source\Programs\IncludeTool.
IncludeTool можно найти только в исходном коде движка на GitHub, в обычных версиях этой программы нету.
И снова здравствуйте. Год назад я выкладывал пост, под названием «Вся наша жизнь спираль», в котором немножко рассказал об игре, над которой работаю. Вот он: https://pikabu.ru/story/vsya_nasha_zhizn_spiral_5831544 Этот пост можно считать его продолжением.
Не писал достаточно долго по нескольким причинам. Основная, я опять подзабил на проект и занимался основной работой, также появились некоторые трудности, которые заставили меня снова залезть в дебри Unreal Engine 4 и смотреть, что Эпики там понакрутили. Но я снова в седле, и т.к. очередной этап разработки завершен, то можно и написать статью об этом.
Начну, пожалуй, с новостей. Их всего две:
1) Мы относительно недавно обзавелись сервером в дискорде: https://discordapp.com/invite/aNfW5FQ , т.ч. милости просим.
2) Мы приняли решение часть неигровых модулей выложить в Open Source под BSD лицензий.
Вот об одном (единственном доступном широкой публике на данный момент) open Source модуле, под названием Client Authority Network (CANet) мы и поговорим.
Данный модуль был написан с одной единственной целью: решить проблему синхронизации игроков в сетевом режиме игры. Казалось бы, в чем проблема? Объясняю, в стандартной сетевая модель UE4 постулирует следующие законы.
• Все игроки должны находится на одной локации в рамках одного сервера.
• Все игроки должны считать логику на сервере, на клиенты транслируется только результаты обработки.
• Все игроки должны иметь на сервере координаты в глобальной сетке карты.
Что из этого следует: в нашем проекте, чтобы игроки были синхронизированы с картой, нужно будет постоянно держать загруженной всю галактику, со всеми планетами, станциями, итд, а также сохранять глобальные координаты игроков (а это, на минуточку числа, которые современные компьютеры не умеют считать. Для знающих: int256 и выше). И кроме того, невозможно применить стандартные «хаки» (динамическое масштабирование, World Shifting, и прочее) для поджатия мира, т.к. в этом случае будет нарушаться третий закон.
Решение, казалось бы, напрашивается само собой: написать свою сетевую модель, которая не будет столь категорична к позициям игроков. Примерно это, CANEt и делает. Однако, чтобы написать свою сеть в UE4, это нужно переписать туеву кучу кода, и не факт, что после очередного обновления движка все будет работать так, как было задумано. Посему я решили схитрить. Я не стали переделывать всю сеть, а заместо этого перевернул работу оригинального, получив заместо стандартной модели сервер-клиент, модель клиент-роутер-клиент (почти честная PTP). В результате, все три закона стандартной модели стали недействительными. И проблема частично была решена. Почему частично? Осталась проблема синхронизации игроков в отдельно взятых локациях. Эту проблему модуль не решает, но, зато ее способна решить фича, которая перекочевала в UE4 прямо из Фортнайта, а именно Replication Graph, но сегодня речь не о нем.
Итак, как же работает CANet. CANet, как я уже говорил, переворачивает принцип работы сети в UE4 с ног на голову. Начинается все так-же, как и в оригинале. На сервер создаётся Game Mode, которая ждет подключения игрока. Как только игрок подключился, создается Player Controller и Player State, которые реплицируется на клиенты (Player Controller только владельцу подключения), а вот дальше начинаются отличия.
В оригинале, следующим этапом было бы создать на сервере чарактер игрока (ACharacter/APawn) и среплицировать его на клиенты. В случае CANet это происходит немножко иначе:
• На сервере создается специальный класс UClientChannel, который привязан к APlayerState в качестве компонента и реплицируется вместе с ним.
• При первой репликации UClientChannel создается карта всех реплицируемых свойств чарактера игрока, считаются их контрольные суммы и записываются в буфер.
• Если APlayerState привязан к APlayerController, то UClientChannel начинает считаться авторитетным и начинается покадровая проверка свойств из буфера.
• При проверке, если контрольная сумма свойства в буфере не сошлась с суммой свойства чарактера, то свойство помечается как изменившееся и записывается во второй буфер.
• В конце кадра, если буфер имеет не нулевую длину, то отправляем его на сервер.
• Сервер сохраняет себе свойства в свой буфер и перенаправляет его остальным клиентам.
• Клиенты в свою очередь опять сверяют контрольные суммы, и если они не сошлись, то записывают свойство в чарактер.
Иными словами, обязанности сервера плавно переходят на клиенты, а на самом сервере, чарактеров и прочих актеров просто не существует.
Существует и ряд проблем: в частности, нужно понимать, что, отдав права на изменение переменных на клиенты мы, по сути, открываем особо одаренным товарищам целый плацдарм для читерства. Для противоборства этому, как раз и существует отдельный буфер на сервере. Этот буфер в будущем будет передаваться подсистеме чит-детектора, который по определенным правилам будет выискивать читеров, и отключать их от игровой сессии.
Написание такого детектора, одна из причин, выкладки модуля в Open Source. Нужна действительно большая команда, чтобы предусмотреть все возможные варианты и подводные камни, а так-как разработка держится исключительно на моем энтузиазме, то самым простым решением было выложить его в Open Source, иными словами, разработчики помогут довести модуль до ума, а взамен смогут свободно его использовать в своих проектах.
На этой ноте, наверно можно и заканчивать. Сам модуль можно найти по адресу: https://github.com/TehnoMag/UE4-Module-CANet , а в следующий раз мы поговорим либо о Replication Graph либо о Wave Function Collapse (WFC) генерации в UE4 и его роли в L.I.M.A. strace_.
В общем хотел еще вчера залепить пост о том, как я перешел на каскадные модули, но вместо этого придется просить помощи, ибо я себе уже мозг сломал =/
В общем суть. Это кусок дебага в конфигурации DevEditor x64; юнит Runtime/Engine/Private/Particles/ParticleGPUSimulation.cpp
Из моего кастомного каскадного модуля приходят локация и размер частицы. Дальше это передается уже штатным кодом на указанный выше юнит. Локация выставляется; а вот с размером происходит следующая фигня:
Она попадает в переменную BaseSize (1.5 по X и Y это норм);
Дальше высчитывается UVFlipSizeOffset. Оно 0.5 по условию
потом идет пересчет сайза по X и Y. Тут уже странность, ибо он становится 7.49 по осям
А вот после суммирования с UVFlipSizeOffset происходит какая-то магия, ибо на выходе у меня всегда 0.5 по осям (независимо от BaseSize).
За любую помощь буду признателен.
Ну начнем по маненьку.
Для начала, хотелось бы рассказать технической части (из готового) и немножко о геймплее.
Если кто заходил ко мне в контактик (на всякий случай ссылка: https://vk.com/lima_strace), то вы видели, что записи посвящены мультиплееру и генераторам L1 и L2, вот о последних и поговорим.
Весь игровой мир можно условно разделить на слои (layer). Всего их 4, начиная с нуля:
L0 – или слой Вселенной. По задумке, на поздней стадии разработки будет добавлен в сетевом режиме игры и будет показывать ближайшие игровые галактики, созданные другими игроками и добавленными на текущий игровой Хаб.
L1 – слой галактики. Представлен в виде структуры, содержащими такие параметры, как позиция, цвет основной звезды, сид звездной системы и набор бит флагов. Самое интересное здесь бит флаги, т.к. в них содержатся все данные об экономике, политике, фракциях, итд. Таким образом можно сохранить все необходимые данные, не разворачивая звездную систему из сида. Для одиночной игры это экономит место на диске/в оперативке. Для сетевой игры это сильно экономит траффик, хоть и наводит некоторые ограничения по кол-ву флагов на систему. Также на этом слое будет происходит генерация туманностей (когда я придумаю как их быстро рисовать)
L2 – слой звездной системы. Как и L1 он представлен в виде небольшой структуры, в которой хранятся сиды планет, их стартовые (момент времени t0) позиции. В отличии от L1 этот слой разворачивается только в момент прибытия игрока в конкретную систему.
L3 – слой орбиты. Он присутствует только у тех планет, где L2 разместил станции. И содержит шаблон станции, данные по импортам-экспортам, продаваемых на верфях модулей кораблей.
Для генерации галактики был взят очень простой и быстрый метод.
Сначала генерируется Балдж (Bulge), по формулам эллипса и шумом в расположении звезд таким образом, чтобы в условных нулях осталось достаточно места для размещения массивной черной дыры.
Потом генерируется диск. Для него снова берутся те же формулы, но в отличии от балджа берется не один, а N эллипсов, причем больший радиус следующего эллипса (A) несколько больше предыдущего. Все эллипсы, кроме самого малого, повернуты на некоторое одинаковое кол-во градусов относительно друг друга таким образом, чтобы самый больший эллипс был повернут относительно самого малого эллипса на 2Пи радиан. Таким образом получаются рукава.
Разумеется, все это сдабривается шумом для придания объема. В результате получается следующая картинка:
Сами звезды рисуются через единую систему частиц. Приходится использовать не совсем обычные функции для этого, т.к. необходимо передать достаточно внушительный объем данных на конвеер визуализации. Раньше для этого использовалась текстура, в которой каждый пиксель обозначал конкретную звезду. В формате R32G32B32A32, можно было задать 4 вектора, которых было достаточно для позиционирования, масштабирования и окрашивания, однако при тестировании оказалось, что метод не совсем удачный, т.к. не было учтено то, что для получении пробы точка выбирается по текстурным координатам (UV 0..1) и в некоторые моменты в качестве пробы могло прийти интерполированное значение от нескольких смежных пикселей, что в результате давало либо мерцание, либо наложение нескольких звезд в одной точке:
https://www.youtube.com/watch?v=L07smX_Fs9k (вставить видео не могу, поэтому ссылка)
Поэтому от этого метода было решено отказаться, а заместо него использовать другой. Этот новый метод основан на двух путях:
Путь 1 – простой. У Эмиттера в UnrealEngine4 есть не экспортируемая в редактор функция ForceSpawn, который позволят создать один или несколько партиклов в заданной локации и, если необходимо, с заданной скоростью. В дальнейшем можно получить объект этого партикла и установить параметры, такие как цвет, размер на необходимые. Из минуса этого метода можно назвать невозможность использования с GPU партиклами (банально не вернется объект), а также приличную нагрузку на процессор при обходе массива с ними.
Путь 2 – каскадный. Более сложный, т.к. требует понимания того, как реализованы частицы в UE4. Из минусов можно назвать то, что при работе каскадного модуля нельзя узнать точно, какая из частичек сейчас обрабатывается (на самом деле можно: если система частиц не имеет модуля Lifetime, а сама система частиц настроена только на один единственный прогон, то можно взять переменную ActiveParticles и отнять от нее единицу, и таким образом получить текущий индекс частицы), а также невозможность получить из этого модуля данные из игрового треда простым путем.
Сейчас, временно используется первый путь из-за его простоты. Чуть позднее перейду на второй (когда разберусь с передачей данных при GPU частицах)
С планетами все несколько проще. Берется SimplexNose, который генерируется из сида планеты, мерджится с несколькими подобными нойсами и выбирается цвет, в зависимости от цветности точки по типу поверхности. Также из результирующего шума можно сгенерировать NormalMap и/или HeightMap для штатного тасселятора.
С планетами все несколько проще. Берется SimplexNose, который генерируется из сида планеты, мерджится с несколькими подобными нойсами и выбирается цвет, в зависимости от цветности точки по типу поверхности. Также из результирующего шума можно сгенерировать NormalMap и/или HeightMap для штатного тасселятора.
А вот самих локаций планет (т.е. посадок на них) не будет. Не будет их по нескольким причинам:
1) Нет и не будет достаточного кол-ва контента для их заполнения (Брабен, Крис, привет)
2) Для них необходима совершенно другая физика полета.
3) Полноценная терра генерация занимает приличное к-во времени, которое можно было бы потратить на более интересные для игрока вещи (например, квесты).
Теперь кратенько о геймплее и мультиплеере. Подробно буду рассказывать в последующих постах.
Геймплей можно условно разделить на 3 части:
Прибытие – Когда игрок только прибывает в новую галактику в ней никого нет (или есть, если включен сетевой режим). Нам дается небольшой корабль без команды, шахтерское и простенькое сборочное оборудование и, собственно, все. У нас несколько задач: первая – это найти как можно больше пригодных для заселения и богатых ресурсами планет; вторая – найти ресурсы и собрать маяк для моста Эйнштейна-Розена, ну а третья доставить и установить этот маяк в центре галактики недалеко от массивной черной дыры.
Воссоединение – Как только мост будет активирован, через него начнут прибывать колонисты. На этом этапе задача игрока помогать кораблям добраться до найденных ранее планет и всячески помогать им обустроить свой быт. Также игрок продолжает искать новые пригодные планеты.
Со временем колонии начнут выходить в космос, строить свои корабли и объединятся с соседями во фракции, налаживать торговые связи. Появляются местные валюты (может быть одна, может быть несколько [зависит от расположения фракций относительно друг друга]). Когда некоторое кол-во фракций будет сформировано, а их границы соприкоснутся начнется третий этап игры.
Передел – На данный момент это последний планируемый этап игры. Он основан на политических и военных играх между фракциями, гонкой вооружения и прочими вкусностями высоко развитых миров. На этом этапе самые развитые фракции начинают поглощение и ассимиляцию малых фракций, также возможны конфликты между высоко развитыми, которые могут привести к полномасштабной войне. В прочем, игрок может и не вмешиваться, а спокойно заниматься своими делами в сторонке.
Конец игры наступает в случае, если в галактике остается только одна фракция и игрока отсылают исследовать новую галактику для начала нового цикла (событие «Новый день»); если игрок находит и активирует событие под кодовым названием «Мистерия»; если происходит событие «Дорога домой»
Мультиплеер это отдельный режим игры, в котором игрок волен выбирать свою роль. Он может стать пилигримом и найти новую галактику для заселения, либо присоединится к колонистам в уже обжитой.
Топология игры создается таким образом, что каждый отдельно взятый игрок может создать свой собственный сервер со своей собственной галактикой. В этом случае он может играть со своими друзьями, или же добавить свой сервер на игровой Хаб, тем самым расширив пределы игрового мира (и контента) на общее кол-во серверов внутри хаба. В этом случае будет возможно путешествие по мосту Эйнштейна-Розена в центре галактики (при условии, что установлен маяк) к соседям, и, соответственно соседей к нам.
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Всех приветствую и сразу извиняюсь - чукча не чукча.
Хочу поделится с вами своим проектиком.
Началось все примерно тогда, когда на кикстартере появилась и успешно прошла его Elite: Dangerous, а тов. Робертс начал нас кормить обещаниями и завтраками. В то время мы работали над ремеком Elite3, под названием EliteD3D, основанным на дизасьме оригинальной игры, полученной нашим тимлидом, если не ошибаюсь, от ДжангВаров. Работали мы над ним ровно до того момента, как наш тимлид ушел из проекта «по-английски» и у нас в команде не осталось человека, который знал бы асьму достаточно хорошо. Так мы начали задумываться над тем, чтобы перевести проект целиком на новые рельсы. Во-первых, чтобы убрать код ассемблера из проекта, а во-вторых, чтобы не привлечь не нужное внимание Брабена. Пока мы думали, меня призвали, а когда я вернулся с мест службы команда уже разбежалась кто-куда. Так нас осталось только двое (как в песне): я, да один специалист по 3д арту. И так начался проект под кодовым названием L.I.M.A. strace_. Делаем мы его очень не торопясь, в основном по выходным и с эпизодическими большими перерывами. Без денег, без оборудования, без сроков. Это больше хобби, нежели что-то еще. От оригинала мы избавились чуть более, чем полностью. Сейчас это полностью другой мир и другой геймплей. Получится ли его довести до точки? Честно, я не знаю. Много раз уже задавался этим вопросом; много раз забрасывал его. Но каждый раз возвращаюсь. И буду возвращаться до тех пор, пока не сделаю.
Теперь о самом проекте:
L.I.M.A – это космическая песочница с элементами RPG в открытом мире.
Игрок – пилигрим, задача которого исследовать галактику на предмет перспективности ее колонизации человечеством, подготовка и активация маяка для моста Эйнштейна-Розена, через который колонисты и другие пилигримы будут прибывать в нашу галактику. Всячески содействовать их быту и защищать их от внешних и внутренних угроз. Между делом, есть вероятность того, что в своих странствиях игроку удастся выяснить, что происходило в мире за время его длительного путешествия из Млечного пути, а может быть и приоткрыть завесу тайны создания Вселенной.
Если кому будет интересно, расскажу о проекте более подробно.