Да, я откажусь от порталов. Пока думаю, что можно применить что-то типа технологии фантастических(магических) магнитных полей, что позволить использовать термоядерную силовую установку.
Оружие можно собрать на заводах или напечатать на 3д принтере. Так как ковчегу все равно нужно колонизировать планетарную систему, то он с собой везет производственные мощности и материалы.
Да, видимо концепция с порталами создает много проблем, и проще использовать термоядерный двигатель. Мне нужно привлечь потусторонние силы для сюжета, но тогда можно заставить эти силы управлять магнитным полем для удержания плазмы и формирования магнитного сопла.
Для геймплея это даже интересно: гранаты, прыжки, рывки и движение вдоль/против вращения могут вести себя иначе, чем в обычной гравитации. Надо будет отдельно подумать, как это использовать в механиках корабельных боёв и перемещения внутри ковчега.
Например, ловить в параллельной вселенной демонов, и использовать их как двигатели корабля, перемещающие корабль силой телекинеза. Просто с порталами как-то нелогично будет.
Что касается демонов, я изначально планировал использовать их для открытия порталов. Это снимает вопрос происхождения портальной технологии и объясняет, почему людям всё ещё нужно участвовать в процессе: кто-то должен находить и ловить этих демонов.
Но для сюжета нужен не только разгон самого ковчега. Нужна ещё и логистика между звёздными системами: стационарные врата на орбите одной звезды, ведущие к вратам на орбите другой. Это позволило бы игроку исследовать разные планетные системы.
По закону сохранения импульса, движущиеся врата после этого замедлятся.
Да, этот момент я действительно не учёл. Придётся менять концепцию.
И так как я придерживаюсь гипотезы Стивена Вольфрама о том, что наша Вселенная похожа на клеточный автомат, то исходя из этого, двое врат портала должны возникать в одной и той же точке пространства, после чего расходиться. Поэтому взять и открыть вторые врата портала сразу на расстоянии многих световых лет будет невозможно.
А можно ли открыть портал около орбиты Солнца, выключить его, вторую часть неактивного портала увезти с собой к другой звезде, а потом снова открыть уже там? После этого портал можно было бы расширить до нескольких метров и использовать как стационарные врата между системами.
Гравитационное поле, распространяясь из портала, будет убывать так, как если бы сам портал был источником гравитационного поля. То есть, поле будет приблизительно обратно пропорционально квадрату расстояния от центра портала. Например, если у нас портал - в 1 метр радиусом, то на расстоянии 10 метров от портала гравитационное поле станет примерно в 100 раз меньше, чем на его поверхности. Поэтому поле не будет создавать особых проблем для достаточно длинного корабля.
Как я понял, размер портала слабо влияет на гравитацию.
Ммм... Они не в невесомости должны быть, а в равном гравитационном потенциале. А то сразу возникает идея вечного двигателя - передаём массу с орбиты Меркурия на орбиту Юпитера, потом скидываем обратно, формально и там и там невесомость, но есть нюанс.
Да, с этим я в целом согласен: если цивилизация уже умеет строить ковчеги и поддерживать большие искусственные среды сотни лет, то планеты перестают быть обязательной целью колонизации.
Но для игры это не критично. Magboots — это не глобальная стратегия про оптимальную колонизацию звёздных систем, а тактическая RPG про экипаж, миссии, аварии, заброшенные станции, ковчеги, порталы и фракции. В игре будет тот набор локаций и конфликтов, который нужен для сюжета и геймплея.
Планеты в этом сеттинге могут существовать как фон или один из вариантов развития колонии, но игра не строится вокруг идеи "обязательно заселить поверхность". Основная сцена для Magboots — это корабли, орбитальная инфраструктура, станции, ангары, технические отсеки и руины старых систем.
Планета нужна не как рудник, а как место для большой самодостаточной цивилизации. Орбитальные поселения требуют постоянного обслуживания и остаются искусственной средой. Планета же даёт готовую среду огромного масштаба: атмосферу, воду, площадь и возможность населению вырасти до миллиардов. А численность важна: больше людей — больше специалистов, промышленности, науки, культуры. Поэтому космос остаётся промышленной базой, а планета — демографической. Население в космосе при этом, скорее всего, будет более ограниченным и специализированным: инженеры, рабочие верфей, экипажи, логистика, добыча и обслуживание орбитальной инфраструктуры.
Да, беспилотники были бы проще. Ограничение здесь в основном сюжетное: в этом сеттинге портал невозможно открыть и обслуживать полностью автоматикой.
Но есть и физическая проблема с вариантом «просто связать корабль порталом с планетой». Если портал сохраняет энергию, то он не может передавать только вещество и полностью игнорировать гравитацию. Иначе через него можно было бы получать энергию из разности гравитационных потенциалов, и портал сам превращался бы в источник энергии/тяги.
Поэтому в моей версии порталы нельзя открывать между произвольными точками вроде «корабль в межзвёздном полёте» и «атмосфера газового гиганта». Газовый гигант не просто даст рабочее тело — он создаст через портал сильную гравитационную аномалию в районе корабля. Если у планеты в верхних слоях атмосферы ускорение свободного падения порядка g или нескольких g, то рядом с порталом на корабле появятся огромные нагрузки и градиенты поля. Для тяжёлой мегаструктуры это уже не заправочный шланг, а опасный источник ускорения и приливных напряжений.
Именно поэтому я ввожу ограничение: стабильный портал возможен только между областями, где нет заметного ускорения и нет большой разницы гравитационного потенциала. Условно — обе точки должны быть в свободном равномерном движении. Поэтому портал нельзя держать открытым во время работы двигателя и нельзя напрямую “воткнуть” его в атмосферу планеты или газового гиганта.
Воздействие гравитации на портал в невесомости
Идея с импульсным порталом возможна как отдельный режим: корабль выключает тягу, переходит в свободный полёт, открывает портал на короткое время, получает порцию рабочего тела или теплоносителя, закрывает портал и снова включает двигатель. Но это уже не непрерывный двигатель через портал, а циклический режим: участок тяги — свободный полёт — короткая дозаправка — снова участок тяги.
Большую часть пусти ковчег будет лететь без ускорения.
В системе имитационного моделирования межзвёздной экспансии у меня скорее получается наоборот: из-за очень малого ускорения ковчегу выгодно почти всё время находиться либо в фазе разгона, либо в фазе торможения. При ускорении порядка 0,19 milli-g разгон очень медленный. Например, на маршруте от Солнца до Проксимы, если считать профиль "разгон до середины пути - торможение вторую половину", пиковая скорость получается всего около 3% скорости света. До 0.1c на таких коротких маршрутах он просто не успевает разогнаться.
Поэтому межзвёздный перелёт здесь не выглядит как «быстро разогнались, потом 500 лет летим по инерции». Скорее это очень долгий режим слабой тяги: разгон, затем разворот, затем такое же долгое торможение. Если используется портальная технология для пополнения рабочего тела, то цикл может быть таким: участок тяги, выключение двигателя и переход в свободное движение, открытие портала и дозаправка, затем снова участок тяги.
Щит тормозится о межзвездный газ, причем неравномерно. В зависимости от ускорения корабля может получиться, что он будет тормозиться сильнее, чем сам корабль и, соответственно, произойдет столкновение. В любом случае это будет весьма нестабильная шляпка.
Да, получается, если мы отключим тягу на долгое время, например на дозаправку топливом во время включения портала, то щит потеряет стабильность. Локальные удары пыли и неоднородности будут, поэтому нужна активная стабилизация.
Поддерживать небольшое контролируемое натяжение лебёдками и демпферами.
Использовать малые двигатели ориентации на щите.
Временно подтягивать щит ближе к корпусу или переводить сцепку в более компактный режим.
Использовать второй ковчег из пары для лазерной коррекции ( Лазерный импульс испаряет тонкий слой материала, возникает плазменный факел, и щит получает маленький реактивный импульс).
Щит на тросах возможен не как пассивная плита впереди корабля, а как активная инженерная система. В режиме торможения его в основном удерживает натяжение тросов, возникающее из-за торможения корпуса. В режиме выключенной тяги эта естественная стабилизация пропадает, и щит нужно удерживать отдельно: лебёдками, демпферами, малыми двигателями или лазерной абляционной коррекцией с соседнего ковчега.
Почему вам не взять конструкцию старого доброго субсветовика вроде "Ностальгии по бесконечности": тримаран с консольными двигателями. Тогда разворачивать придется только двигатели.
Такая схема возможна, но это уже другая архитектура корабля.
Если двигатели вынесены в стороны от основного корпуса, то их тоже нужно защищать от набегающего межзвёздного потока. Значит, либо общий головной щит должен закрывать не только центральный корпус, но и боковые двигательные гондолы, либо у каждой гондолы должен быть собственный щит. В обоих случаях растёт защищаемая передняя проекция, а вместе с ней масса и сложность конструкции.
Выхлоп двигателя я бы не считал полноценной заменой щиту. Он существует только пока двигатель работает, зависит от режима тяги, расширяется в вакууме и не даёт стабильной поверхностной плотности вещества перед кораблём. Он может частично помогать с газом или мелкой пылью, но как основная защита от межзвёздной среды на скорости порядка 0,1c мне кажется ненадёжным решением.
Поэтому в моей постановке задачи цилиндр с единой защищаемой передней проекцией выглядит проще и надёжнее: вся критическая конструкция прячется в тени одного большого щита, а не превращается в набор вынесенных гондол, ферм и отдельных защитных экранов.
И криосон позволяет обойтись без колец - зачем они замороженным мумио? Одно для экипажа оставить и хватит.
Массовый криосон на сотни лет я не использую как базовую технологию колонизации. В сеттинге основная масса будущих колонистов перевозится не в виде спящих взрослых людей, а как банк гамет и эмбрионов, которые проще сохранить в замороженном виде на очень долгий срок. Уже после прибытия из них выращиваются новые поколения колонистов в искусственных матках/инкубаторах, с медицинским контролем и генетическим скринингом.
Криосон остаётся в сеттинге как редкая и дорогая технология — в основном как игровая условность для отдельных персонажей, которых нужно «перенести» через большие промежутки времени. Но это не массовый способ перевозки всего населения.
Кольца нужны не только для пассажиров. Ковчег — это не холодильник с колонистами, а обитаемая мегаструктура, которая веками летит, ремонтируется, поддерживает производство, обслуживает системы и содержит активное население. Поэтому жилые зоны с искусственной гравитацией нужны экипажу, инженерам, техникам, медикам и всем, кто поддерживает корабль как работающую экосистему.
Одно кольцо теоретически возможно, но пара встречновращающихся колец лучше: их угловые моменты частично компенсируют друг друга, и кораблю проще выполнять медленные ориентационные манёвры. Если же делать совсем другую схему с одним небольшим жилым модулем, то получится другой корабль и другой сеттинг — более автоматизированный, «холодный» субсветовик, а не ковчег-город.
И в чем проблема бунта на поверхности для экипажа субсветовика? На поверхность садят людей без возможности улететь.
Сам по себе бунт на поверхности не обязательно представляет прямую военную угрозу для орбитальной инфраструктуры. Проблема в другом: он угрожает миссии колонизации.
Да, ковчег на орбите имеет огромное силовое преимущество. С орбиты можно уничтожить поселение, инфраструктуру или промышленный объект. Но если цель миссии — построить живую колонию, то бомбардировка своей же поверхности становится не победой, а провалом. Она уничтожает людей, специалистов, оборудование, годы работы и доверие остальных поселений.
Конфликт может быть не в том, что поверхность способна сбить ковчег, а в том, что на поверхности появляются собственные элиты, интересы и политическая воля. Одно поселение может заявить о независимости, другое остаться лояльным, третье оказаться заложником ситуации. В таком конфликте орбита может быть сильнее, но не может решать всё ударом из космоса, если ей нужна не мёртвая территория, а работающее общество.
Поэтому здесь интереснее не вопрос "может ли ковчег уничтожить бунт", а вопрос "как сохранить колонизацию, когда часть колонии больше не хочет подчиняться орбите". Иногда нужно поддержать лояльные поселения, иногда устранить конкретных управляющих, иногда эвакуировать или вернуть специалиста, груз или артефакт, который невозможно заменить наверху. И вот такие задачи уже естественно превращаются в миссии для игры.
Портал все "портит".. Зачем ковчег, если можно отправить портал (тут можно вставить костыль - что через портал проходит толкьо мертвая материя или фарш). При наличии портала охлаждение можно осуществлять через него же, Вместо "головного щита" впереди может лететь портал.
Ограничение в том, что портал в этом сеттинге нельзя произвольно таскать вместе с ускоряющимся кораблём. Его можно открыть только между точками, которые находятся в свободном равномерном движении, без заметного ускорения и сильной гравитации. Поэтому вариант "поставить портал впереди вместо щита" не работает в фазах разгона и торможения: чтобы всё время оставаться перед кораблём, портал должен ускоряться вместе с ним.
С охлаждением через портал похожая проблема. В режиме без тяги это можно представить, но во время работы двигателя портал становится частью ускоряющейся системы, а именно это я и запрещаю как инженерное ограничение сеттинга.
По сути, главная задача ковчега — не просто перевезти людей, а доставить портал в другую систему. По сюжету открыть портал невозможно без людей, потому что сеттинг Magboots — это не чистая физика, а тёмное фэнтези внутри твёрдой научной фантастики. Из этой статьи я сознательно убрал большую часть лора, чтобы оставить только физическую и инженерную сторону корабля.
Зачем разворачивать весь цилиндр для торможения? можно переместить двигательный модуль на другой конец. Или просто развернуть двигатели в обратную сторону, раз сопла направлены под углом к оси.
Корабль и так разделён на две крупные части: прицепной модуль и основной бронецилиндр с двигательной установкой. То есть при развороте я стараюсь разворачивать не весь «город со всеми запасами», а минимально необходимую часть конструкции.
Вопрос в том, насколько далеко можно отделить двигатель от остального корабля. Двигателю нужны реактор, система охлаждения, рабочее тело, силовая рама, защищённые коммуникации и сопла. Всё, что не нужно для работы двигателя, можно вынести в прицепной модуль; но сам двигатель — это не отдельная маленькая турбина, которую можно просто переставить на другой конец.
Да, альтернативные схемы возможны: переставляемый двигатель, поворотные сопла, отдельный двигательный модуль. Но тогда вместе с ним придётся переносить значительную часть энергетики, охлаждения и запасов рабочего тела. То есть задача не исчезает, а превращается в другую архитектуру корабля.
Есть "подозрение", что щит при торможении не будет так красиво висеть на тросах. Нужны расчеты, конечно (завит от массы, ускорения и т.п) , но скорее всего его "перекосит" и ударит о корабль.
Тут будет стабилизацией за счёт силы натяжения в неинерциальной системе отсчёта. Пока щит летит строго по оси, эта сила просто натягивает тросы. Ели щит под действием какого-то возмущения отклонится в сторону, то возникает возвращающая сила, которая стремится вернуть щит на центральную ось. Тяга у ковчега малая, а торможение длится очень долго, поэтому щит не дёргают резким рывком, а медленно буксируют на многоточечной тросовой системе с контролем натяжения. Вместо удара о корабль у тросовых систем есть другая проблема - колебания. Щит не врежется в ковчег, но он может начать «гулять» из стороны в сторону, как маятник. И если эти колебания не гасить, они могут раскачать всю связку. Активное управлением натяжением троса при помощи лебедки позволит снизить колебание.
Вы предлагаете установить сопла под углом, чтобы выхлоп не задел щит?
Именно так. В текущем проекте сопла разведены под углом 15 градусов — это базовый компромисс, который защищает и прицепной модуль на фазе разгона, и удерживаемый на тросах щит при торможении.
Справедливое замечание. Точного теплового расчёта я не делал, но можно оценить порядок. Например, олово плавится уже при 231,9 °C, а кипит только в районе 2500–2600 °C.
таблица соотношения испаряющейся массы олова к полезно сброшенному теплу
Для грубой оценки можно взять жидкое олово как пример теплоносителя. При рабочей температуре радиатора около 1000 K, то есть примерно 727 °C, по моей прикидке получается потеря порядка 0,00018 г олова на каждый 1 МДж сброшенного тепла. Это оценка именно для выбранных допущений: давление паров олова около 6,6·10⁻⁶ Па, испарение по Герцу-Кнудсену, излучение примерно как у чёрного тела.
Тогда если радиатору нужно постоянно сбрасывать 1 ГВт тепла, это: 1 ГВт = 1000 МДж/с
Я отказался от использования SerializeReference, так как в случае рефакторинга классов, изменения неймспейсов и т.д. я теряю сохраненный контент. Так что во всех коллекциях храню ссылки на MonoBehaviour с отдельными GameObject, которые лежат в дочернем трансформе
Понятно что какие-то дерганья всегда есть, все работает с погрешностью. Но я, к примеру, не способен увидеть такие лаги, пока они не достигают критических значений. Может просто у вас зрение позволяет замечать больше, чем у большинства людей.
FixedUpdate() как правило вызывается реже, чем Update. К примеру на один FixedUpdate у вас будет вызвано 5 раз Update, в этом случае у вас 5 кадров объект будет со старыми координатами, посчитанными в FixedUpdate. Потом вызовется FixedUpdate, и изображение дернется. Ну или даже если вы сделаете частоту вызова FixedUpdate чаще, чем в Update, все равно, будет разсинхрон, который приведет к дерганию.
В итоге будет плавающая задержка между фактическим отображением кадра и текущим состоянием мира, но она колеблется в слишком небольших пределах, чтобы на что-то влиять, эффектов торможения от этого не должно быть.
Вы это пробовали сами написать? У меня всегда в таких случая были только лаги. Так можно делать, если в Update пихать интерполяцию между старыми и новыми значениями, посчитанными в FixedUpdate(), но и то, объект то будет ускоряться то замедляться.
Рассмотрим пример. Пусть частота FixedUpdate() и Update () примерно равна. В FixedUpdate() мы изменяем координату на один. x+=1; В Update отображаем эту координату. За 9 итераций FixedUpdate выводит значение x {1,2,3,4,5,6,7,8,9}, Update вызывается без синзронизации, поэтому иногда он будут запаздывать, иногда брать значение раньше, чему нужно, может получиться к примеру {1,1,3,4,4,6,6,8,9} То есть иногда объект будет слишком спешить, иногда ждать.
Да, я откажусь от порталов. Пока думаю, что можно применить что-то типа технологии фантастических(магических) магнитных полей, что позволить использовать термоядерную силовую установку.
Оружие можно собрать на заводах или напечатать на 3д принтере. Так как ковчегу все равно нужно колонизировать планетарную систему, то он с собой везет производственные мощности и материалы.
У Вахи есть права на интеллектуальную собственность
Да, видимо концепция с порталами создает много проблем, и проще использовать термоядерный двигатель.
Мне нужно привлечь потусторонние силы для сюжета, но тогда можно заставить эти силы управлять магнитным полем для удержания плазмы и формирования магнитного сопла.
Да, спасибо, это надо будет учесть.
Для геймплея это даже интересно: гранаты, прыжки, рывки и движение вдоль/против вращения могут вести себя иначе, чем в обычной гравитации. Надо будет отдельно подумать, как это использовать в механиках корабельных боёв и перемещения внутри ковчега.
Что касается демонов, я изначально планировал использовать их для открытия порталов. Это снимает вопрос происхождения портальной технологии и объясняет, почему людям всё ещё нужно участвовать в процессе: кто-то должен находить и ловить этих демонов.
Но для сюжета нужен не только разгон самого ковчега. Нужна ещё и логистика между звёздными системами: стационарные врата на орбите одной звезды, ведущие к вратам на орбите другой. Это позволило бы игроку исследовать разные планетные системы.
Да, этот момент я действительно не учёл. Придётся менять концепцию.
А можно ли открыть портал около орбиты Солнца, выключить его, вторую часть неактивного портала увезти с собой к другой звезде, а потом снова открыть уже там? После этого портал можно было бы расширить до нескольких метров и использовать как стационарные врата между системами.
Как я понял, размер портала слабо влияет на гравитацию.
Спасибо, исправил в статье ошибку
Да, с этим я в целом согласен: если цивилизация уже умеет строить ковчеги и поддерживать большие искусственные среды сотни лет, то планеты перестают быть обязательной целью колонизации.
Но для игры это не критично. Magboots — это не глобальная стратегия про оптимальную колонизацию звёздных систем, а тактическая RPG про экипаж, миссии, аварии, заброшенные станции, ковчеги, порталы и фракции. В игре будет тот набор локаций и конфликтов, который нужен для сюжета и геймплея.
Планеты в этом сеттинге могут существовать как фон или один из вариантов развития колонии, но игра не строится вокруг идеи "обязательно заселить поверхность". Основная сцена для Magboots — это корабли, орбитальная инфраструктура, станции, ангары, технические отсеки и руины старых систем.
Планета нужна не как рудник, а как место для большой самодостаточной цивилизации. Орбитальные поселения требуют постоянного обслуживания и остаются искусственной средой. Планета же даёт готовую среду огромного масштаба: атмосферу, воду, площадь и возможность населению вырасти до миллиардов.
А численность важна: больше людей — больше специалистов, промышленности, науки, культуры. Поэтому космос остаётся промышленной базой, а планета — демографической. Население в космосе при этом, скорее всего, будет более ограниченным и специализированным: инженеры, рабочие верфей, экипажи, логистика, добыча и обслуживание орбитальной инфраструктуры.
Да, беспилотники были бы проще. Ограничение здесь в основном сюжетное: в этом сеттинге портал невозможно открыть и обслуживать полностью автоматикой.
Но есть и физическая проблема с вариантом «просто связать корабль порталом с планетой». Если портал сохраняет энергию, то он не может передавать только вещество и полностью игнорировать гравитацию. Иначе через него можно было бы получать энергию из разности гравитационных потенциалов, и портал сам превращался бы в источник энергии/тяги.
Поэтому в моей версии порталы нельзя открывать между произвольными точками вроде «корабль в межзвёздном полёте» и «атмосфера газового гиганта». Газовый гигант не просто даст рабочее тело — он создаст через портал сильную гравитационную аномалию в районе корабля. Если у планеты в верхних слоях атмосферы ускорение свободного падения порядка g или нескольких g, то рядом с порталом на корабле появятся огромные нагрузки и градиенты поля. Для тяжёлой мегаструктуры это уже не заправочный шланг, а опасный источник ускорения и приливных напряжений.
Примерно такую картину я имею в виду: на канале «оптозоракс» есть моделирование ньютоновской гравитации для случая, когда один портал открыт на планете, а второй — на корабле.
Именно поэтому я ввожу ограничение: стабильный портал возможен только между областями, где нет заметного ускорения и нет большой разницы гравитационного потенциала. Условно — обе точки должны быть в свободном равномерном движении. Поэтому портал нельзя держать открытым во время работы двигателя и нельзя напрямую “воткнуть” его в атмосферу планеты или газового гиганта.
Идея с импульсным порталом возможна как отдельный режим: корабль выключает тягу, переходит в свободный полёт, открывает портал на короткое время, получает порцию рабочего тела или теплоносителя, закрывает портал и снова включает двигатель. Но это уже не непрерывный двигатель через портал, а циклический режим: участок тяги — свободный полёт — короткая дозаправка — снова участок тяги.
В системе имитационного моделирования межзвёздной экспансии у меня скорее получается наоборот: из-за очень малого ускорения ковчегу выгодно почти всё время находиться либо в фазе разгона, либо в фазе торможения. При ускорении порядка 0,19 milli-g разгон очень медленный. Например, на маршруте от Солнца до Проксимы, если считать профиль "разгон до середины пути - торможение вторую половину", пиковая скорость получается всего около 3% скорости света. До 0.1c на таких коротких маршрутах он просто не успевает разогнаться.
Поэтому межзвёздный перелёт здесь не выглядит как «быстро разогнались, потом 500 лет летим по инерции». Скорее это очень долгий режим слабой тяги: разгон, затем разворот, затем такое же долгое торможение. Если используется портальная технология для пополнения рабочего тела, то цикл может быть таким: участок тяги, выключение двигателя и переход в свободное движение, открытие портала и дозаправка, затем снова участок тяги.
Да, получается, если мы отключим тягу на долгое время, например на дозаправку топливом во время включения портала, то щит потеряет стабильность. Локальные удары пыли и неоднородности будут, поэтому нужна активная стабилизация.
Поддерживать небольшое контролируемое натяжение лебёдками и демпферами.
Использовать малые двигатели ориентации на щите.
Временно подтягивать щит ближе к корпусу или переводить сцепку в более компактный режим.
Использовать второй ковчег из пары для лазерной коррекции ( Лазерный импульс испаряет тонкий слой материала, возникает плазменный факел, и щит получает маленький реактивный импульс).
Щит на тросах возможен не как пассивная плита впереди корабля, а как активная инженерная система. В режиме торможения его в основном удерживает натяжение тросов, возникающее из-за торможения корпуса. В режиме выключенной тяги эта естественная стабилизация пропадает, и щит нужно удерживать отдельно: лебёдками, демпферами, малыми двигателями или лазерной абляционной коррекцией с соседнего ковчега.
Такая схема возможна, но это уже другая архитектура корабля.
Если двигатели вынесены в стороны от основного корпуса, то их тоже нужно защищать от набегающего межзвёздного потока. Значит, либо общий головной щит должен закрывать не только центральный корпус, но и боковые двигательные гондолы, либо у каждой гондолы должен быть собственный щит. В обоих случаях растёт защищаемая передняя проекция, а вместе с ней масса и сложность конструкции.
Выхлоп двигателя я бы не считал полноценной заменой щиту. Он существует только пока двигатель работает, зависит от режима тяги, расширяется в вакууме и не даёт стабильной поверхностной плотности вещества перед кораблём. Он может частично помогать с газом или мелкой пылью, но как основная защита от межзвёздной среды на скорости порядка 0,1c мне кажется ненадёжным решением.
Поэтому в моей постановке задачи цилиндр с единой защищаемой передней проекцией выглядит проще и надёжнее: вся критическая конструкция прячется в тени одного большого щита, а не превращается в набор вынесенных гондол, ферм и отдельных защитных экранов.
Массовый криосон на сотни лет я не использую как базовую технологию колонизации. В сеттинге основная масса будущих колонистов перевозится не в виде спящих взрослых людей, а как банк гамет и эмбрионов, которые проще сохранить в замороженном виде на очень долгий срок. Уже после прибытия из них выращиваются новые поколения колонистов в искусственных матках/инкубаторах, с медицинским контролем и генетическим скринингом.
Криосон остаётся в сеттинге как редкая и дорогая технология — в основном как игровая условность для отдельных персонажей, которых нужно «перенести» через большие промежутки времени. Но это не массовый способ перевозки всего населения.
Кольца нужны не только для пассажиров. Ковчег — это не холодильник с колонистами, а обитаемая мегаструктура, которая веками летит, ремонтируется, поддерживает производство, обслуживает системы и содержит активное население. Поэтому жилые зоны с искусственной гравитацией нужны экипажу, инженерам, техникам, медикам и всем, кто поддерживает корабль как работающую экосистему.
Одно кольцо теоретически возможно, но пара встречновращающихся колец лучше: их угловые моменты частично компенсируют друг друга, и кораблю проще выполнять медленные ориентационные манёвры. Если же делать совсем другую схему с одним небольшим жилым модулем, то получится другой корабль и другой сеттинг — более автоматизированный, «холодный» субсветовик, а не ковчег-город.
Сам по себе бунт на поверхности не обязательно представляет прямую военную угрозу для орбитальной инфраструктуры. Проблема в другом: он угрожает миссии колонизации.
Да, ковчег на орбите имеет огромное силовое преимущество. С орбиты можно уничтожить поселение, инфраструктуру или промышленный объект. Но если цель миссии — построить живую колонию, то бомбардировка своей же поверхности становится не победой, а провалом. Она уничтожает людей, специалистов, оборудование, годы работы и доверие остальных поселений.
Конфликт может быть не в том, что поверхность способна сбить ковчег, а в том, что на поверхности появляются собственные элиты, интересы и политическая воля. Одно поселение может заявить о независимости, другое остаться лояльным, третье оказаться заложником ситуации. В таком конфликте орбита может быть сильнее, но не может решать всё ударом из космоса, если ей нужна не мёртвая территория, а работающее общество.
Поэтому здесь интереснее не вопрос "может ли ковчег уничтожить бунт", а вопрос "как сохранить колонизацию, когда часть колонии больше не хочет подчиняться орбите". Иногда нужно поддержать лояльные поселения, иногда устранить конкретных управляющих, иногда эвакуировать или вернуть специалиста, груз или артефакт, который невозможно заменить наверху. И вот такие задачи уже естественно превращаются в миссии для игры.
Ограничение в том, что портал в этом сеттинге нельзя произвольно таскать вместе с ускоряющимся кораблём. Его можно открыть только между точками, которые находятся в свободном равномерном движении, без заметного ускорения и сильной гравитации. Поэтому вариант "поставить портал впереди вместо щита" не работает в фазах разгона и торможения: чтобы всё время оставаться перед кораблём, портал должен ускоряться вместе с ним.
С охлаждением через портал похожая проблема. В режиме без тяги это можно представить, но во время работы двигателя портал становится частью ускоряющейся системы, а именно это я и запрещаю как инженерное ограничение сеттинга.
По сути, главная задача ковчега — не просто перевезти людей, а доставить портал в другую систему. По сюжету открыть портал невозможно без людей, потому что сеттинг Magboots — это не чистая физика, а тёмное фэнтези внутри твёрдой научной фантастики. Из этой статьи я сознательно убрал большую часть лора, чтобы оставить только физическую и инженерную сторону корабля.
Корабль и так разделён на две крупные части: прицепной модуль и основной бронецилиндр с двигательной установкой. То есть при развороте я стараюсь разворачивать не весь «город со всеми запасами», а минимально необходимую часть конструкции.
Вопрос в том, насколько далеко можно отделить двигатель от остального корабля. Двигателю нужны реактор, система охлаждения, рабочее тело, силовая рама, защищённые коммуникации и сопла. Всё, что не нужно для работы двигателя, можно вынести в прицепной модуль; но сам двигатель — это не отдельная маленькая турбина, которую можно просто переставить на другой конец.
Да, альтернативные схемы возможны: переставляемый двигатель, поворотные сопла, отдельный двигательный модуль. Но тогда вместе с ним придётся переносить значительную часть энергетики, охлаждения и запасов рабочего тела. То есть задача не исчезает, а превращается в другую архитектуру корабля.
Тут будет стабилизацией за счёт силы натяжения в неинерциальной системе отсчёта. Пока щит летит строго по оси, эта сила просто натягивает тросы. Ели щит под действием какого-то возмущения отклонится в сторону, то возникает возвращающая сила, которая стремится вернуть щит на центральную ось. Тяга у ковчега малая, а торможение длится очень долго, поэтому щит не дёргают резким рывком, а медленно буксируют на многоточечной тросовой системе с контролем натяжения. Вместо удара о корабль у тросовых систем есть другая проблема - колебания. Щит не врежется в ковчег, но он может начать «гулять» из стороны в сторону, как маятник. И если эти колебания не гасить, они могут раскачать всю связку. Активное управлением натяжением троса при помощи лебедки позволит снизить колебание.
Именно так. В текущем проекте сопла разведены под углом 15 градусов — это базовый компромисс, который защищает и прицепной модуль на фазе разгона, и удерживаемый на тросах щит при торможении.
Справедливое замечание. Точного теплового расчёта я не делал, но можно оценить порядок. Например, олово плавится уже при 231,9 °C, а кипит только в районе 2500–2600 °C.
Для грубой оценки можно взять жидкое олово как пример теплоносителя. При рабочей температуре радиатора около 1000 K, то есть примерно 727 °C, по моей прикидке получается потеря порядка 0,00018 г олова на каждый 1 МДж сброшенного тепла. Это оценка именно для выбранных допущений: давление паров олова около 6,6·10⁻⁶ Па, испарение по Герцу-Кнудсену, излучение примерно как у чёрного тела.
Тогда если радиатору нужно постоянно сбрасывать 1 ГВт тепла, это: 1 ГВт = 1000 МДж/с
Потеря олова на испарения будет:
0,00018 г/МДж × 1000 МДж/с = 0,18 г/с
За год непрерывной работы:
0,18 г/с × 31 536 000 с ≈ 5 676 000 г ≈ 5,7 т
За 500 лет:
5,7 т/год × 500 ≈ 2800–2850 т
Нет, гражданам России дают, не дают резидентам России - это большая разница.
Я отказался от использования SerializeReference, так как в случае рефакторинга классов, изменения неймспейсов и т.д. я теряю сохраненный контент. Так что во всех коллекциях храню ссылки на MonoBehaviour с отдельными GameObject, которые лежат в дочернем трансформе
А если слетать туда и обратно, и каждый раз отправляться в прошлое, то можно скопировать объект и отменить первый запуск?
Вы это пробовали сами написать? У меня всегда в таких случая были только лаги. Так можно делать, если в Update пихать интерполяцию между старыми и новыми значениями, посчитанными в FixedUpdate(), но и то, объект то будет ускоряться то замедляться.
Рассмотрим пример. Пусть частота FixedUpdate() и Update () примерно равна. В FixedUpdate() мы изменяем координату на один. x+=1; В Update отображаем эту координату. За 9 итераций FixedUpdate выводит значение x {1,2,3,4,5,6,7,8,9}, Update вызывается без синзронизации, поэтому иногда он будут запаздывать, иногда брать значение раньше, чему нужно, может получиться к примеру {1,1,3,4,4,6,6,8,9} То есть иногда объект будет слишком спешить, иногда ждать.