Жанр: смесь immersive sim и survival horror
Двигло: православный GODOT 4.4
Сеттинг/сюжет: в разработке (но планируется что-то не совсем очевидное)
Сразу отмечу три вещи:
1) Я не программист, не знаю паттернов и рот их ебал
2) if/else - это настоящая сигма мейл гигачад БАЗА
3) Я могу использовать хорошие практики движка/программирования, а могу и нет, просто потому что мне так самому удобно или проста нравится
Проект находится на ранней стадии разработки.
Пока готово:
- Базовое перемещение (+ прыжки, присед, плаванье, разные виды лестниц)
- Базовый инвентарь (подбор предметов, стаки, перемещение)
- Менеджер оружия (подбор, смена, атака, перезарядка, разные состояния во время различных действий игрока, расчет траектории атаки)
- Разное по мелочи: смена уровней, взаимодействие с предметами и т.п.
- Базовая система сохранений (уровень, состояние уровня и предметов на нем, состояние инвентаря, данные игрока)
Что дальше?
- Сейчас занимаюсь проектированием и созданием базового AI для врагов
- Далее начну работать с террейном и собирать первые прототипы уровней параллельно выпиливая допиливая необходимые механики
Сделал наброски тестового алгоритма. Только вот что начал понемногу реализовывать.
В идеале в будущем сделать менеджер боевой ситуации, чтобы враги обменивались инфой и в зависимости от этого принимали решения (не прям что-то крутое, обойдусь без GOAP).
lymboAI использовать не хочу
>immersive sim
>Godot
Вот этот проект рассматривал?
https://github.com/Phazorknight/Cogito
>>1048410
1. Compatibility рендерер выбери.
2. Сожми разрешение экрана в 2 раза.
3. Переключи физику на Jolt - он быстрее.
4. В материалах SHADING_MODE_PER_VERTEX.
В OBS выбери ultrafast в кодировщике записи.
Можно ещё заюзать встроенный режим записи:
https://godotengine.org/article/movie-maker-mode-arrives-in-godot-4/
https://docs.godotengine.org/en/stable/tutorials/animation/creating_movies.html
>>1048408
>Excalidraw
Гамбургер -> Export Image... -> PNG
(Или "Экспортировать изображение" на русском)
Или ты не хочешь, чтоб мы читали твои надписи?..
>Вот этот проект рассматривал?
>https://github.com/Phazorknight/Cogito
Не, я не настолько прошарен в движке. Если возьму что-то такое готовое и потом попробую модифицировать под себя, то запутаюсь нафиг.
Мне легче сделать попроще, но самому с минимум "черных ящиков" в проекте. Ну и самому разобраться бывает интересно.
>Можно ещё заюзать встроенный режим записи:
Спасибо, посмотрю, что там
>Или ты не хочешь, чтоб мы читали твои надписи?..
Не думал, что кто-то в серьез будет схемки читать. Так, визуально глянуть. Схема есть = работа идет.
Прикрепил черновую версию в нормальном разрешении
Главное не забудь, что цель это сделать игру, а не красивые картинки с графиками рисовать. Для многих, это становится камнем преткновения.
>127489132.png 141Кб, 590x404
Поясни мем. Не понимаю, что там не так?
Это да, понимаю. Периодически бывает много работы, так что скорость разработки варьируется.
Сегодня в основном в коде копался. Итерационно делаю BT.
Сделал крайне простую версию поля зрения врага. Далее буду делать вектор видимости, чтобы враг не замечал врага через стены
>>1048516
Ну тип вместо "правильного" использования .tres для оружия я просто запихнул сцены с ними в ноду игрока, да еще и для каждого отдельный скрипт сделал переделаю потом может быть
>"правильного" использования .tres для оружия
А кто сказал, что это правильнее отдельных нод?
>запихнул сцены с ними в ноду игрока, да еще и для каждого отдельный скрипт сделал
Я точно так же делаю. Потому что для этих нод бывает нужно добавить какие-то другие ноды: меши, частицы, звуки... А скрипт отдельный - у разных оружий разное поведение, очевидно. Зачем это пихать в ресурсы?
>переделаю потом
Если хочешь хранить PackedScene оружия и делать add_child(weapon_scene.instantiate()) при каждом переключении, то это может вызвать у тебя лишние задержки, особенно в плане системы частиц оружия. Переключение оружия должно быть быстрым, т.е. желательно держать все ноды в дереве сцены (и переключать их видимость + работу: например, process_mode = Node.PROCESS_MODE_DISABLED).
Другое дело, если у тебя 100500 вариантов оружия у неигровых персонажей, которые будут использовать единственный вариант в течение всей своей жизни: логично, что им нужна только одна нода оружия, а остальные варианты остаются нераспакованы.
>А кто сказал, что это правильнее отдельных нод?
Ну? было ощущение, что лучше делать через tres. И держать в сцене игрока только те оружия, которые он нашел. Инстанцировать их один раз при загрузке в _ready. И сохранять инфу о найденных орудиях в файле сохранения.
Но вот так не делать:
>хранить PackedScene оружия и делать add_child(weapon_scene.instantiate()) при каждом переключении
>Я точно так же делаю. Потому что для этих нод бывает нужно добавить какие-то другие ноды: меши, частицы, звуки...
Ну тогда успокоил. Значит так оставляю, спасибо
___
Еще по быстрому накидал состояние атаки для врага. Продвинутое обнаружение игрока уже завтра начну пилить
Далее займусь продвинутым преследованием и возвратом на исходную позицию
Советую сделать не один рейкаст, и не только из центра. В идеале поставь моба чуть за стенкой, и как со стороны игрока лучше и приятнее будет смотреться, так и оставить.
Советую сделать не один рейкаст, и не только из центра
Да, в будущем скорее всего так и сделаю, чтобы враги не были слепыми болванчиками. Пока так оставлю для прототипа.
>В идеале поставь моба чуть за стенкой, и как со стороны игрока лучше и приятнее будет смотреться, так и оставить.
Вот тут не совсем понял, о чем ты
У ОПа чибик из интернета в роли плейсхолдера, а ты насоветовал уже обвесить его сотней рейкастов и оценивать с точки зрения ощущений игроков, лол.
ОП делает
>immersive sim и survival horror
В переводе на русский это "ААА фотореализм с реалистичными зомби/монстрами/маньяками".
По сути он начал совсем не с того конца. Нужно было сначала посмотреть, осилит ли он хотя бы статичную сценку, где одна только графика ужасает игрока. Это движение мобов за игроком - как клей между сцен.
>>1048910
>чтобы враги не были слепыми болванчиками
Иногда лучше, чтоб игрок мог последить за мобом тайком, тем более тут survival horror: игрок должен обосраться от одного вида крякозябры за углом.
>Вот тут не совсем понял
Он предлагает тестировать методом проб и ошибок, рассматривая ситуацию с точки зрения игрока - что именно увидит игрок, прежде чем моб его заметит?
>"ААА фотореализм с реалистичными зомби/монстрами/маньяками".
Хорошее предположение, но нет. Да, раньше каждый первый второй проект на каком-нибудь юнити пытался в реалистичную графику, за неимением интересных механик. Но мне такой подход не близок, как и ААА графон.
Ну и конечно я понимаю, что пилить проект уровня deus ex или resident evil с бюджетом в полторы банки пива охота крепкое не очень реалистично. Поэтому проект будет куда компактнее.
>Иногда лучше, чтоб игрок мог последить за мобом тайком
Тут от типа моба зависит. Какие-то могут быть более "глупыми", например, люди. А какие-то наоборот более агрессивные и наблюдательные, чтобы на контрасте создать эффект опасности.
В общем, это вопрос уже геймдизайна. Я конечно такое прорабатываю (в диздоках), но внедрять такое еще рано, пока не реализованы bазовые механики
>Он предлагает тестировать методом проб и ошибок, рассматривая ситуацию с точки зрения игрока
Ну ты верно заметил
>У ОПа чибик из интернета в роли плейсхолдера
Дальше буду делать корректный возврат на маршрут патрулирования - сейчас враг возвращается не к ближайшей точке, а к последней, которая помечена "следующей".
А потом займусь более продвинутым поиском игрока, чтобы болванчик не сразу отваливался, если потерял того из виду, а шел к последней точке, где игрок был замечен и начинал поиск на какое-то время
Построить линию маршрута можно одной нодой:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
Я просто заболел + были перелеты-переезды + очень много работы.
Но сложа руки я не сидел. Что сделал:
1) Чтобы враг не сразу отваливался, когда теряет игрока из виду, а еще какое-то время его преследовал "по пятам".
2) Запилил рабочий поиск игрока на местности: Враг окончательно потерял игрока -> Идет к последней точке, где видел игрока -> Осматривается -> Произвольное кол-во раз ходит по местности -> Если не нашел, то уходит.
Анимации, чтобы осмотреться, для болванчика у меня нет. Поэтому заменил на дрыганье руками.
Пока все это пилил вылезло n-ое кол-во багов, которые я успешно пофиксил. На вроде того, что точка поиска в navigationregion3d лежит не на прямой, то болванчик сбивается с курса и идет бесконечно в одну сторону.
Переписал дочернее BT для состояния поиска, вынес движение в отдельную функцию и т.п. - все пофиксил.
Надеюсь за выхи успеть доделать состояния: рандомное брожение туда-сюда, охрану (сиреч стоять на месте и осматриваться), возврат на исходную позицию после преследования.
Но тут вроде ничего нового. Должен успеть.
Сделай нормальную тестовую локацию, чтобы она приблизительно была похожа на финальную, но без избыточных деталей и текстур. Пол, стены, потолок. Масштаб соблюдай, добавь трипланарную сеточку, например: https://kenney.nl/assets/prototype-textures Головастика тоже отмасштабируй или замени на подходящего по пропорциям к окружающей среде.
Просто сейчас ты делаешь сферическую корову в вакууме. Потом придётся подгонять под реальные локации, ограничения геймплея игрока и т.п. Гугли реальные прототипы ААА игр - там вот начинают с грейбоксов локаций, а потом уже геймплей, мобы.
>Просто сейчас ты делаешь сферическую корову в вакууме
Ага, я знаю. Просто не хотел даже более-менее нормальные модели и условия делать, пока не будет какая-никакая кодовая база (хоть пусть и придется по параметрам подгонять под реальность). А то понаставил бы красивых серых кубов, а кода ноль.
Но так-то ты прав конечно. В ближайшее время начну делать нормальную тестовую локацию.
За ссылочку спасибо, текстурки схоронил, буду использовать.
>>1050103
>Надеюсь за выхи успеть доделать состояния: рандомное брожение туда-сюда, охрану (сиреч стоять на месте и осматриваться), возврат на исходную позицию после преследования.
Сегодня все это доделал.
Завтра еще кое-чего по мелочи намучу и в пн начну тестовую локу собирать и вообще курить мануалы по Terrain3D
Начал потихоньку просчитывать основные метрики.
Но и по коду поработал. За последние несколько дней сделал перенос объектов, как в каком-нибудь half-life.
Дальше посмотрим. На выхи в планах:
1) Доделать нормальную тестовую локацию
2) Собрать первую итерацию основных метрик
3) Улучшить АИ врагов и их поведение (толкание объектов, открывание дверей, и т.п.)
4) За чашкой кофе заняться левелдизайном
Вертикальное ебо-бо было из-за того, что я делал:
>var target = Vector3(target_x, target_y, target_z)
>look_at(target, Vector3.UP)
Переделал на
>var target = Vector3(target_x, target_y, target_z)
>target.y = global_position.y
>look_at(target, Vector3.UP)
И в самом конце после move_and_slide
>model.rotation.x = 0
>model.rotation.z = 0
Теперь всегда при атаке/передвижении враг вертикален. Может попозже оставлю наклон только для атаки, но пока пусть так будет.
Еще враг у меня застревал стенах - отключил с ними коллизию, оставил только с полем (не знаю, чего раньше не додумался).
И еще была проблема, что враг выходил за пределы полигонов навмеша на острых углах. Пофиксил уменьшением значений path_desired_distance и target_desired_distance до 0.3
Все, теперь можно браться за взаимодействие ии болванчиков и объектами на уровне
>>1051780
>model.rotation.x = 0
>model.rotation.z = 0
Обнуляй
О чем игра хоть?
1) Реагируют на объект, если его кинул игрок, который вне зоны видимости. Сначала удивляются (нужной анимации не было, поэтому пока оставил "задумчивость"). Потом бегут проверять в место, откуда был бросок (видео 1)
2) Если игрок прячется за объект, но толкает его - также бегут смотреть, в чем дело. Чувствительность к замечанию настраиваю через linear_velocity.lenght() объекта. (видео 2). На видео она повышена
Ну и конечно, если игрок держит объект, но полностью за ним скрыт, то враг его заметит. Также есть разные уровни тревоги, которые отвечают как и на что реагируют враги. Например, если тревога на уровне 0, а игрок бросил в поле зрения врага объект, то враг сначала удивиться, а потом пойдет расследовать. А если уже ищет игрока, то среагирует мгновенно. Но это пока все в зачаточном состоянии
Работа со звуком (когда предмет упал за спиной врага) будет после.
Еще написал логику алгоритма (в диздоке) и подготовил код (чтобы имплементировать без переписывания) для функционала обнаружения чужеродных и неправильных объектов. Например, если игрок открыл дверь, которая должна быть закрыта. Или принес объект, который не должен был быть на маршруте патрулирования врага.
Но это пока на паузе, т.к. есть вероятность, что это оверкил фичи для моего гейм/лвл-дизайна, а вот время отладки и тестирования увеличит геометрически. В общем, тут надо думать.
Дальше будут реализовывать взаимодействие болванчиков с дверьми + чтобы игрок не мог перманентно заблокировать врагов объектами (пусть ломают их в таких случаях)
>>1051860
>О чем игра хоть?
Про
>Обнуляй
но массовое
По сюжету и лору пока молчок.
Но по атмосфере и геймплею ориентируюсь на: thief, resident evil, gloomwood (из нового) и half-life первый лол (но тут мне физика и импакт от движения вкатывают).
Но конечно же настолько же иммерсивный геймплей, как thief, я пытаться не буду делать.
>Базовый инвентарь (подбор предметов, стаки, перемещение)
ну вот есть сразу замечание по логике инвенторя. Когда ты предмет начал тянуть, он уже должен исчезать из слота в котором он лежит. Иначе получается корявый визуальный дубляж(постоянно эту ошибку вижу во многих демках). У тебя должен быть промежуточный контейнер для предмета. Собственно "рука" которой ты тянешь. Когда чел потянул предмет он переходит в "руку" и исчезает из слота, когда дропнул, исчезает из руки появляется в новом слоте. Если дроп не удался, то предмет переходит из "руки" назад в слот откуда брался. Если часть в стак влезла, а часть не влезла, то сколько влезло переходит в новый слот, а остаток из руки переходит в слот-источник. Тоже самое с выкидыванием предмета в мир и любыми другими перетаскиваниями.
done
Правда механика инвентаря у меня сейчас на переработки. Вероятно классического инвентаря не будет. Только расходники, штуки 4, и их переключение в слоте быстрого доступа. И наверное для сюжетных предметов оставлю отдельный что-то типа список в изображениями, описанием, возможностью осмотреть и повзаимодействовать/объединить
>animatablebodu3d + animationplayer
Можешь просто Tween использовать - удобнее:
https://docs.godotengine.org/en/stable/classes/class_tween.html
Попробуй EASE_OUT + TRANS_SPRING/BACK/BOUNCE.
Гифка не относится к Godot - подходящей не нашёл...
>перепиливать на rigidbody3d и честную физику
Зачем? Открывать дверь давлением тела игрового персонажа - весьма неудобная затея, особенно если позади двери что-то её блокирует. NPC это вообще неудобно будет. Если хочешь, чтобы дверь могла "слетать с петель", лучше спавнить отдельно или переключать RigidBody3D.freeze = true с режимом freeze_mode = FREEZE_MODE_KINEMATIC.
Я пробовал разные варианты, и мне "реалистично физическая" дверь меньше всего понравилась...
Если всё же хочешь попробовать, то лучше создай отдельную сцену типа "door_rb3d.tscn", чтобы было несколько разных дверей, и сравни их на практике. Буквально выстави рядом на сцене и поиграй...
А как тебе мой ебейший инвенторь тогда?
мимобыдло
>Можешь просто Tween использовать - удобнее:
>Попробуй EASE_OUT + TRANS_SPRING/BACK/BOUNCE
Посмотрю, спасибо.
>Зачем? Открывать дверь давлением тела игрового персонажа - весьма неудобная затея
Да, от этого отказался уже.
Но я хочу физику двери симулировать примерно так:
1) Дверь открывается/закрывается
2) Ударяется об объект
3) В зависимости от тяжести объекта скорость движения двери затухает
Как-то так было в half-life 2 (сейчас нет возможности проверить).
Короче что-то вроде симуляции реальной физики, но не полностью.
Пробовал hingejoint. Но даже один hingejoint в сцене в статичном состоянии роняет ее fps на моем некро ноуте.
>Как-то так было в half-life 2 (сейчас нет возможности проверить)
Проверил. Оказывается не так.
Двери в hl2 устроены куда проще, чем я думал. Судя по поведению им дается бесконечный импульс каждый тик, пока дверь не закроется/откроется. И объект, если зажимается, просто этот импульс накапливает. А игрок нет, его дверь не двигает.
а еще игра очень хорошо оптимизирована по сравнению с поделками инди-разработчиков современных
>один hingejoint в сцене в статичном состоянии роняет ее fps
Уже пробовал переключить 3D физику на "Godot Jolt" в настройках?
Он намного стабильнее и вроде даже должен быть производительнее.
>>1052797
Выглядит странно... Они не могли детектить сопротивление движению?
Если хочешь останавливать дверь перед препятствием, есть два варианта:
1. Поставить вокруг двери Area3D. С ними много подводных камней...
2. Сделать дверь как замороженный RigidBody3D, включить:
(door as RigidBody3D).contact_monitor = true
(door as RigidBody3D).max_contacts_reported = 1 # или больше
И ждать сигнала "body_entered" (на деле это не "вход", а "контакт").
Мне кажется, в отдельных случаях это будет надёжнее Area3D...
ИМХО, геймплейно будет лучше, чтоб дверь всё сносила на своём пути...
>Уже пробовал переключить 3D физику на "Godot Jolt" в настройках Он намного стабильнее и вроде даже должен быть производительнее.
Еще нет. Надо будет изучить вопрос
>Выглядит странно... Они не могли детектить сопротивление движению?
Тоже удивился. Только игрока детектит. С нпс не пробовал
>есть два варианта:
По итогу без HingeJoint3D накостылял так (упрощенно):
1) Дверь открывается-закрывает по импульсу
2) Если скорость падает, то она фризится
3) При ударе об объект, передает небольшой импульс и еще немного естественным образом двигается
4) При ударе об игрока (естественно учитывается положение игрока относительно двери) стопится сразу
5) Через код можно регулировать в какую сторону дверь открывается и на сколько широко
Я специально хотел воспроизвести вот это ощущение полу-физики и полк-аркадности двери.
Также сделал взаимодействие врагов дверей:
1) Враги двери умеют открывать, если они у них на пути. А могут и не открыть, если дверь приоткрыта и там достаточно места для проход (через rotation.y определяется)
2) Враги умеют двери ломать, если они на пути. Пока дамаг наносится упрощенно при старте анимации, для теста хватит
Да, добавил еще засовы, которые не дают двери открыться и замедляют преследование. В будущем еще добавлю систему ключей и замков.
А еще враги почти правильно обходят дверь, а также могут корректировать свой путь, если застревают рядом. Тут вообще пришлось запилить костыльную систему из точке корректировки.
Т.к. аналогично HingeJoint3d просто наличие одного NavigationObstacle3D отправляет FPS в крутое пике (падение с 34 до 20).
Зато эта система универсальна и ее можно будет присрать к любому сложному интерактивному объекту на уровне
План на ближайшие дни:
1) Чтобы враг детектил, когда игрок открывает дверь
2) Чтобы враг начинал разбивать интерактивные объекты вокруг, если застрял
3) Переработку инвентаря (хочу чтобы игрок крутил 3d модельки)
4) Добавить замки и ключи для дверей
Молодец.
>Враги двери умеют открывать
>Враги умеют двери ломать
Если у тебя игра, в которой игрок должен убегать от неигровых персонажей по сложной локации, то, мне кажется, запирание дверей будет нерациональным: запертые двери разрушаются навсегда, но если не запирать, то можно закрывать неограниченно. Как понимаю, анимация открытия двери всё равно задерживает неигрового персонажа.
Т.е. может получиться что фича есть, но игрок ею не пользуется, а если пользуется, то вредит сам себе...
И снова получается, что >>1050134
>ты делаешь сферическую корову в вакууме.
По крайней мере, так это выглядит со стороны...
>Если у тебя игра, в которой игрок должен убегать от неигровых персонажей по сложной локации
Не совсем. Запирание дверей (не всех) это просто одна из механик. Использовать ее можно по разному. Смотря, как задизайнить уровень.
Например:
1) Игрок перед ключевой комнатой может сначала устранить противников и спокойно обыскать оба помещения, но с риском.
2) Игрок может пробежать противников, забежать в следующую комнату и запереть дверь. Пока дверь не выбита (длительность же можно настроить) игрок делает какие-то ключевые действия и сбегает.
Один сегмент - два варианта прохождения.
Все это можно крутить вертеть, как угодно: сделать часть дверей не уничтожаемыми, добавить противников, которые выбивают дверь мгновенно и т.д.
>Один сегмент - два варианта прохождения
Нужна мотивация проходить по-разному...
>Все это можно крутить вертеть, как угодно
Да, но тогда усложняется баланс геймплея.
Карты будут процедурно генерироваться?
>Нужна мотивация проходить по-разному...
Ну да, ресурсы, риски, текущее состояние, возможные сюжетные последствия, пристрастия самого игрока.
Как в любом хорошем immersiv sim
>Да, но тогда усложняется баланс геймплея
Конечно
>Карты будут процедурно генерироваться?
Нет, все руками
>Нет, все руками
Эх. А я уже представил себе рогалик/рогулайт с процедурной генерацией офисов, что по-разному проходишь в зависимости от рандома и бонусов. Например, если удалось выбить автомат и броню, вырезаешь помещение, а если ракетные ботинки - проскакиваешь мимо и запираешь за собой дверь. Разнообразие механик было бы очень кстати. А генерировать карты можно из мелких модулей.
> рогалик/рогулайт с процедурной генерацией офисов
есть такая партия https://www.youtube.com/watch?v=DucFr8Uv4Vk
Что-то подобное было в Void Bastards. Правда там не офис, а заброшенные космические корабли и без вертикального геймплея. Норм игруха на пару вечеров https://youtu.be/Faoz9AR8Ap8?si=kh02nA-EjRAfhnDV
Ну в dishonored и theif были вручную собранные уровни и разнообразие механик. Проходить можно было по разному.
Вообще рандомная генерация лута, например, после каждой смерти игрок/загрузки идея не самая плохая. Главное корректно забалансить все это
По сути:
1) Добавил врагам обнаружение того, что дверь открывает персонаж
2) Пофиксил 6 разных багов в поведении ии врага
Теперь не получится наглухо перегородить путь, например, ящиками, или подпереть дверь. ИИ прочухает, что чет не то и начнет ломать движимые объекты вокруг.
1) Фиксил баги
2) Переделал динамические объекты на систему наследования, а то задолбался для тестовых объектов код копипастить а раньше лень было фиксить
3) Был баг, что переносимым объектом можно двигать врага, т.к. объект двигается за игроком через lerp, а враг перемещается через move_and_slide (как понял - проблема в том, что враг воспринимает объект, как статику в такой момент и сдвигается или типа того). Решил тем, что игрок отпускает объект, если тот касается врага. Решение топорное, но более-менее реалистичное.
Из чуть более интересного - запилил простенькую систему общения врагов между собой. Если враг А преследует/видит игрока, и в этот момент в его поле зрения есть Враг Б, то Врагу Б передаются данные игрока и он включается в погоню (Враг А как бы зовет на помощь). В обратную сторону тоже работает - если враг А видит, как враг Б гонится/атакует игрока, то он соответственно тоже присоединится.
Не, заморочился ты конечно хорошо. Но мне кажется в большинстве игорей мобы в половину тупее. Зачем так сложнишь? Спортивный интерес?
>Зачем так сложнишь?
Игра с элементами immersiv sim же!
А конкретные причины более-менее умных врагов:
1) Реалистичное поведение => погружение в атмосферу
2) Умные враги => мотивация игроку тщательнее исследовать местность, искать разные пути и использовать механики, а не тупа атаковать в лоб
>Спортивный интерес?
Есть такое, но я стараюсь вовремя себя одергивать. А то уж хотел начать пилить полноценный анализ местности, чтобы враги отмечали, открытые двери, которые не должны быть открыты, объекты не на своем месте и т.п.
К счастью успел осознать, что такое усложнение не будет вписываться в мой геймдизайн
Не люблю возню с control нодами. Надеюсь, все вместе успею за выхи сделать
Для меню с вкладками юзай это:
https://docs.godotengine.org/en/stable/classes/class_tabcontainer.html
Если тебе приходится часто дублировать какую-то специфическую группу нод - это повод аыделить её в отдельную сцену с @tool-скриптом и @export-полями. Получится свой собственный компонент интерфейса.