>>78074

>кто-то спрашивал как использовать Vector2(x,y) в качестве координат в массиве

Там вопрос был типа "не плохо ли это в контексте производительности игры". Ответ: зависит способа использования. На реддите недавно пост был с подробным сравнением: подтвердилось, что Array немножко быстрее Dictionary в линейных операциях, однако, всё-таки хуже в рандомных операциях.

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

Также зависит от плотности заполнения. Если у вас разреженная сетка, заполненная нулями ("воздухом"), гораздо выгоднее использовать Dictionary, тем более трёхмерный. Следующие операции:

>dictionary[Vector3i(x, y, z)] = 0 # создание записи

>if Vector3i(x, y, z) in dictionary: # проверка наличия

У меня выполняются быстрее любых аналогичных действий с Array, когда я недавно это всё тестил.

В 4.4 завозят типизацию Dictionary, можно будет так:

>var cells: Dictionary[Vector3i, CellType]

Интересно будет проверить производительность...

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

>func get_cell(x, y, z) -> CellType

>func set_cell(x, y, z) -> CellType

>func cell_id(x, y, z) -> int

Делает обращения к Array медленнее Dictionary. Это означает, что писать dictionary[Vector3i(x, y, z)] будет надёжнее против случайных ошибок, достаточно производительно и при этом данные разрежены (отсутствующие данные не заполняются нулями).

Конечно, если у вас огромные данные и с ними производится много операций каждый тик, тогда придётся переписывать на C++ или хотя бы C#. Но подобное редко встречается в играх (как правило "блочные" игры типа Minecraft, Terraria и т.п., но не любая блочная игра требует огромных массивов, например, фермерские игры намного компактнее).

>>78813
Читай документацию вместо того, что читаешь.
https://docs.godotengine.org/en/stable/classes/class_signal.html

Объявить сигнал:

>signal message_sent(text: String)

Запустить сигнал:

>message_sent.emit("text")

Подключение сигнала:

>sender.message_sent.connect(_on_message)

Обработчик сигнала:

>func _on_message(text: String) -> void:

Это новый, лучший способ для Godot 4+.

>Создается экземпляр сообщения.

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

Тем более некорректно Control-ноды используешь:
1. Node2D здесь вообще не нужен, он портит Control.
2. Вместо Panel тебе явно нужен PanelContainer.
3. Для чата потребуется ScrollContainer.
4. Для адаптивного UI нужно больше контейнеров.

>нужен будет текст для обработки в других сценах

Так и храни этот текст в каком-то месте, например:

>var chat_history: PackedStringArray

https://docs.godotengine.org/en/stable/classes/class_packedstringarray.html
Если нужна дополнительная информация, такая, как отправитель, время отправки/получения сообщения и прочее, тогда Dictionary или свой кастомный класс.

А потомки Node, в частности Control - это "viewer":
https://en.wikipedia.org/wiki/Model–view–controller
Тебе необходимо сначала создать "model".

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

>>78881
Что ты вообще делаешь? Какова твоя идея?

Adult игру дейтинг сим

> Может тебе лучше присмотреться к чему-то вроде рпг мейкера?

у отвращение к играм на нем я их даже никогда не скачиваю

>Ты вообще себе представляешь процесс создания игры?

Ну там gameloop хуе-мое, несколько механик,карта мира с переключением локаций, смена день-ночь, ходить на работу, платить за квартиру

>>78878
Ну я программист системный но абсолютно не умею рисовать ниче и тем более моделить или кастомить модели так что все собирать буду из пресетов

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

>>78911
Спасибо

>>78940
По-моему в daz-3d все гораздо проще ну и мне нужна одежда а как и где я буду брать это для блендера я хз, на сколько я понял это нереально взять одежду с одной модели и натянуть ее на другую модель другого автора а в daz-3d одежда натягивается на любую модель изи что просто имба фича

>>78980
Я его смотрел, он вроде действительно заброшен

>>79157

>Траблы с переписыванием кода были, когда туториалы по трешке, а уже 4 с пол года

Я сам начинал во времена 3.2, и потом переносил прототипы на 4.0+, никаких проблем не было. Всё максимально подробно описано в документации. Разумеется, у меня не так много кода... Но там все изменения были уровня "добавить @ в начале, переименовать одну функцию в другую" и т.п.

>Мне не совсем дефолтные вещи интересны.

Конкретно что тебе интересно? К чему скрывать?

>на старте васянские практики перенимать. Когда у тебя в туториале вроде норм...

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

Хочешь хорошую, расширяемую архитектуру игры? Включай собственную голову и думай. Думай, что необходимо для твоей игры, в каком месте и т.д. Туториалы по движку этому тебя не научат, это ты самостоятельно должен уметь, чтобы делать игры.

Движок - инструмент, туториалы учат назначению клавиш, а мелодию выдумывать ты сам должен.

>По не дефолтным моментам из видосов узнаешь.

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

Просто помни: бесплатные туториалы снимают не ради твоего обучения, а чтобы собрать побольше просмотров на рекламном блоке. Естественно, что обозревать будут только самые популярные вещи, а также затягивать видео, сознательно вставлять ошибочный код, плохие паттерны и т.д. Лишь бы ты вляпался в tutorial hell и продолжил смотреть эти бесконечные "обучающие" видосики на Ютубе.

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

>По графену будет всякая лоу поли стилизация.

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

Но Stencil Buffer обещают добавить в ближайших версиях, уже давно работают над pull request'ом.

>Боевка,

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

>задания, лут, карта, сохранения,

Это всё не зависит от 3D графики.
Рекомендую, особенно для квестов и лута:
https://docs.godotengine.org/en/stable/tutorials/scripting/resources.html#creating-your-own-resources
Для рендеринга мини-карты пригодится:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html#viewport-container
Для сохранений есть много разных способов:
https://docs.godotengine.org/en/stable/tutorials/io/saving_games.html

>интерфейс

У Godot очень мощная UI система, на которой в т.ч. Godot Editor построен. Всё очень просто и удобно, в отличие от других движков и веба (HTML/CSS). Идейно напоминает RAD IDE Delphi - единственная проблема в том, что в Godot UI не нативный для ОС - сложнее поддержка для инвалидов ("экранные читалки", например, не видят кнопки Godot).

Т.е. базовая концепция:
- кидаешь компоненты (ноды) на "форму" (сцену);
- настраиваешь параметры нод в инспекторе;
- соединяешь события (сигналы) с обработчиками.
Можно легко делать собственные UI компоненты.

Также есть поддержка тем - применение параметров интерфейса глобально ко всем UI-компонентам.

>>79160

>Проблема годота в пост эффектах и рендере 3д

Если сравнивать с OpenGL 1.0 - у Godot просто фантастический рендерер 3D, так что мне даже пожаловаться не на что. Зачем какой-то UE? Ты раскрыть весь потенциал OpenGL 3.3 попробуй. Древние игрушки начала нулевых уже страдали избыточным фотореализмом в ущерб стилю, а вы ожидаете от движка картинки как в реальности? Создание игр - это побег от реальности, не нужно отравлять геймдев фотореализмом. Он нужен исключительно для виртуальных музеев...

Я вот сейчас в основном играю в игры со старых мобильных приставок вроде Game Boy, каждый раз удивляясь, что в таких микроскопических по весу игрушках геймплея и смысла больше, чем в любом современном ААА фотореалистичном "игрокинце".

Разрабы в погоне за фотореалистичной графикой забыли, зачем вообще игроки играют в игры. Даже индюшатина давно начала страдать от "графония".

>если вдруг тебе понадобиться на половине сцены чтото найти посчитать итд

Тогда ты явно что-то не так делаешь. Зачем тебе ИСКАТЬ что-то на сцене, которую ТЫ САМ создал?

Конечно, бывают ситуации, в которых выгоднее переписать весь алгоритм на C++. Но зачастую твоя проблема в самом алгоритме, организации сцен или геймплея, а не в языке. Т.е. твой код будет тормозить независимо от языка, просто на GDScript ты это чуть раньше почувствуешь (и это хорошо).

>>79165

>А что про работу с анимацией скажешь?

Нормально всё, читай документацию:
https://docs.godotengine.org/en/stable/tutorials/animation/

>Как со всякими родительскими-дочерними объектами дело обстоит?

Это основа дерева сцены, как ещё может быть?

>Чтоб не копипастить, когда тебе только кастомизировать надо или пару фишек добавить.

Можно попробовать Scene Inheritance. Одна общая сцена-предок может иметь множество потомков, в каждом из которых есть дополнительные данные. Изменения в предке влияют на всех потомков, но изменения в потомке влияют только на него. Все импортированные 3D сцены по умолчанию будут создавать сцену-потомка от базовой GLTF-сцены.

>если годот - это +- гамак очень условно

Давно не видел GM, много времени прошло. Но фундаментальное отличие в том, что GameMaker - закрытый продукт в руках одной компании. Godot, напротив, подвержен влиянию сообщества, которое занимается им в т.ч. на уровне исходного кода. По юзабилити тут можно сказать, что Godot заточен сообществом под сообщество, а GM заточен одной компанией под очень абстрактного "потребителя".

>быстро запилить базовую логику, а потом возиться с геймплеем и масштабировать,

А это уже от тебя зависит, а не от движка. В любом движке можно наломать немасштабируемых дров.

Для масштабируемости рекомендую следующее:

1. "Call down, signal up" - вызывай методы только у непосредственных потомков (детей) ноды, никогда не взаимодействуя с внуками/братьями/предками. Оповещение предков - только через сигналы. Эта концепция позволяет сделать игровые объекты намного более независимыми друг от друга.

2. Обязательно указывай типы данных и объектов везде, где это возможно. В настройках включай предупреждение об отсутствии конкретного типа и автоматическое дополнение типов для встроенных методов. Для любых сложных объектов указывай class_name с читаемым именем, чтобы эти объекты можно было использовать по имени, с бонусом к автодополнению и статической проверке кода. Дополнительно указывай тип данных в Array, и в ближайшее время (Godot 4.4) - тип в Dictionary.

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

4. Избегай создания глобальных сущностей. Godot поддерживает создание глобальных сущностей несколькими разными способами - это может быть удобно для маленьких проектов, но на длинной дистанции ты хочешь иметь как можно меньше глобальных сущностей. Это касается статических полей классов, "autoload"-сцен, а также ресурсов, глобально передаваемых множеству объектов. Глобальные сущности усложняют поддержку из-за связывания всего кода проекта в одной точке.

5. Почаще нажимай F6 (вместо F5). F6 запускает отдельную сцену вместо главной. Если твои сцены адекватно работают после нажатия F6, то выше вероятность, что они будут работать хорошо и в композиции с другими сценами. Это ключевая концепция Godot, на мой взгляд.

6. Изучи дебаггер, способы поиска ошибок и т.д. Естественно, по официальной документации. Способность понять и исправить ошибку в своём проекте поможет лучше, чем любые туториалы.

>>79387

>кастомизировать, а не писать с нуля

>Знаю, как реализовать инверсную кинематику

Знаешь ли? Или ты про то, какие кнопки в GUI жать? Инверсная кинематика, например, это очень сложно алгоритмически, поэтому идеальных решений нет. В условном Blender нет требований работы в реальном времени, однако даже там IK алгоритмы глючные. Реализовывать такое самому крайне сложно, и в UE наверняка есть какое-то уже готовое решение. Ну и зачем реализовывать то, что уже есть из коробки?

>без васянства что-то подобное

В Godot сознательно ограничен набор встроенных инструментов. Ты можешь получить что-то очень отдалённое на "однокнопочные" решения, скачав пользовательские аддоны, где всё "васянство" уже разработано вместо тебя. Но качество у аддонов обычно так себе и на поддержку можно только надеяться. По этому на Godot ты либо сам будешь разработчиком Васяном, либо работаешь в паре со знакомым Васяном, а с тебя только арт/звук/текст.

Собственно, как и на любом другом движке. Вот за это пользователи Godot и любят его: можно просто писать код игры без лишних проблем, как раньше. Открываешь редактор за секунды и васянишь...

А вот если тебе нужен конструктор игр совсем без программирования, то ты не туда обращаешься.

>т.е. ты в несколько строк кода можешь запилить тот же контроллер, который будет норм

Максимально упрощённый контроллер:

>extends CharacterBody3D

>func _physics_process(_delta: float) -> void:

> var v := Input.get_vector("left", "right", "up", "down")

> velocity = Vector3(v.x, -9.8, v.y)

> move_and_slide()

Это заставит твою ноду CharacterBody3D двигаться соответственно нажатиям 4 клавиш, "скользить" по препятствиям и падать в случае отсутствия опоры. Достаточно для простенькой игры типа "Sokoban". Подробнее читай в документации:
https://docs.godotengine.org/en/stable/classes/class_characterbody3d.html
https://docs.godotengine.org/en/stable/classes/class_input.html
Но тебе наверняка будет мало этого. Ожидаемо. Тебе придётся написать несколько сотен строк для чего-то продвинутого (в хорошем стиле с комментариями, не складывая кучу выражений в одну строчку), либо ты можешь попробовать посмотреть готовые решения:
https://godotengine.org/asset-library/asset?filter=Character
https://godotengine.org/asset-library/asset?filter=Controller
Не обязательно брать готовое как есть. Можно взять исходники, изучить их и многие другие, и сделать собственные так, как тебе будет удобнее всего.

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