Ссылки
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: https://godotengine.org/showcase или https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Что нового в версиии 3.2.2.
1 Поддержка C# для платформы IOS (и без неё прожили бы)
2 2D батчинг для рендера GLES2 (и без него всё работало)
3 Ре-дизайн системы плагинов Android (что это? зачем? мабилке нинужна)
4 Поддержка DTLS и ENet (серваки пока что только под линуксом, для венды завезут ближе к 3.2.3. не корчи рожу)
5 Улучшенное управление Variants указывающими на высвобождённые Objects (ну теперь-то я зделою игру мечты)
https://godotengine.org/article/maintenance-release-godot-3-2-2
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории.
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Все языки в одном месте: ##почили с миром##
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий тонет там: >>672108 (OP)
Архивы:
1 https://arhivach.ng/thread/207802/
2 https://arhivach.ng/thread/388500/
3 https://arhivach.ng/thread/388501/
4 https://arhivach.ng/thread/388502/
5 https://arhivach.ng/thread/388503/
6 https://arhivach.ng/thread/432708/
7 https://arhivach.ng/thread/433902/
8 https://arhivach.ng/thread/436355/
9 https://arhivach.ng/thread/455461/
10 https://arhivach.ng/thread/479963/
11 https://arhivach.ng/thread/489815/
12 https://arhivach.ng/thread/494513/
13 https://arhivach.ng/thread/515567/
14 https://arhivach.ng/thread/533171/
15 https://arhivach.ng/thread/555441/
16 https://arhivach.ng/thread/592945/
Надо будет на неделе бенчмарк проапгрейдить.
>Игры, созданные глобальными кириллами: https://godotengine.org/showcase
опять тухлую ссылку принёс
Полезное с прошлого треда
----
Однажды долго искал, и нашел настройку сконса, отвечающую за кэш. Вроде бы, это не описано в доках годота, да и в самом сконсе закопано. Кэш позволяет сконсу не пересобирать то, что не менялось, таким образом, пересборка движка сведется к перекомпиляции пары файлов и (все равно долгой) линковке. Оставлю тут, вдруг кому пригодится
Надо завести переменные окружения
SCONS_CACHE=C:/путь_к_папке_где_хочешь_хранить_кэш
SCONS_CACHE_LIMIT=5000
Лимит в мегабайтах, т.е. в моем варианте 5Гб. Можно поставить 10-15 если есть место. Стереть можно в любой момент.
Вполне возможно лечится повышением физического ФПС в настройках проекта.
Вот реальный баг который насилует годот, вызывая необратимые тормоза и они сохранятся даже после перезагрузки сцены.
https://github.com/godotengine/godot/issues/40059
Короче, не масштабируйте меши близко к нулю, с тенями ещё жёстче.
Там по ссылке специальные синтетические тесты устраивают поток шкварных объектов. Чтобы каждую секунду появлялись сотни объектов калечящих годот и заставляющие его как минимум течь памятью. Просто в реальных условиях реальной игры у тебя момент когда ты заметишь пиздец с производительностью начался - наступит значительно позже чем в синтетическом тесте.
> в реальных условиях реальной игры
Вне зависимости от 2д/3д, будут конфигурируемые в настройках радиусы уровней детализации по ряду параметров (трава, деревья, кубы, пирамиды), согласно данной настройке в пул предзагрузки будет попадать строго определённое количество нод-сцен. А в действующем дереве сцены из них будет строго ограниченное радиусом из настроек количество. Я конечно сейчас с дивана пишу, но тем не менее, ИМХО, траблы с производительностью происходят из недостаточно проработанной архитектуры проекта. Когда программист вместо того, чтобы сесть и спроектировать проект, а потом кодить строго по проекту, ебошит код по заветам Хуана "пишите, как пишется".
https://www.youtube.com/watch?v=K9g8TTFjIlY
Для тех, кто прогудел в дудку первый курс универа.
Я смотрел там, в итоге не нашел чего то подходящего с видом сверху, я сам вроде как начал рисовать, но вот нинравица мне, еще и который день руки не знаю как накидать. Еще и столкнулся с тем что от вида сверху в принципе проблема изобразить монстра чуть сложнее зомби, чтобы он не выглядел как каша пикселей.
Надо учиться, прокачивать воображение и уметь видеть свою игру за фиолетовыми прямоугольниками. Настоящие студии тоже так делают, потому что все работают одновременно, и высокополигональную модельку девочки-андроида с шикарной задницей ты получишь только к финалу разработки.
Или использовать плейсхолдеры, составлять новые модельки из старых и тырить всё подряд с опенгеймарта. Я тоже не умею работать с абстракциями, и сейчас прототип говна у меня собран из ассетов из интернета за исключением прото-говниста.
Для polygon2d можно назначить текстуру, вместе с отступом, масштабом, и uv координатами, что с помощью небольшой математики в скрипте делает то что тебе нужно.
У спрайта есть несколько параметров, содержащих слово region. Я бы через них делал. С ними довольно неудобно работать вручную (мышкой в редакторе), а вот из кода вполне легко.
Идея для игры 18+, только что придумал, но наверняка такая уже существует. Пятнашки на основе ню-фотографии (или арта, тут на вкус и цвет), у которой на самое пикантное место приходится пустая ячейка. Как только собираешь картинку, отсутствующая ячейка заполняется недостающей частью изображения, а там нутыпонел.
Самое быстрое решение такое: загружаешь картинку в спрайт и говоришь, что у тебя там якобы 4×4 кадра. Движок сам нарежет на 16 равных квадратов, дальше можно этот спрайт наклонировать и дать каждой копии свой номер кадра (один сделать невидимым). Но это, естественно, хорошо работает только для деления на равные кадры.
Вот, смотри. Я просто создал спрайт, закинул в него текстуру и выставил hframes и vframes на 4 (как будто у меня спрайтшит из 16 кадров). Теперь меняя Frame я получаю каждый из этих отдельных кадров. Создай 16 таких спрайтов, расставь по местам, и у каждого поставь своё значение frame, а одному поставь visible = false. Теперь чтобы поменять два кадра местами, достаточно поменять местами их frame, а сами спрайты можно и не двигать. А можно и двигать, с помощью Animation Player можно сделать всё красиво. Валяй.
>От Gonkee матчасть по прыжкам подкатила:
>https://www.youtube.com/watch?v=K9g8TTFjIlY[РАСКРЫТЬ]
Но как же так? Математика ведь нинужна? Мне на ютупчике так сказали. А еще говорили, что программировать не нужно, хнык-хнык...
Сук, чет ржу.
>Для тех, кто прогудел в дудку первый курс универа.
Да ну, окстись, парабола и производные - это еще школьная программа, вот матрицы уже универ, да.
> это еще школьная программа, вот матрицы уже универ, да
Согласен, начинается оно ещё в школе. Но именно на первом курсе универа это всё повторяется, закрепляется и увязывается с остальным матаном и ты понимаешь, что это реально нужная вещь, а не просто задрачивание бесполезной хуйни математичкой в школе.
Сейчас в платформерах более продвинутые техники делают чем просто формула гравитации
https://www.reddit.com/r/gamedev/comments/horm1a/ive_started_making_a_teaching_aid_for_people/
Можно. И уже делают.
https://youtu.be/o9MCifpQwro
>Сейчас в платформерах более продвинутые техники делают чем просто формула гравитации
Все эти техники - древние как говно мамонта и применялись еще на заре платформеров.
И, кстати, их использование не отменяет необходимости использования стандартной схемы гравитации для прыжков.
> Как чайнику такое пофиксить?
Накинь на движущуюся платформу Area, в которой пропиши замену гравитации (Replace или Replace-Combine, но не Combine-Replace и не Combine, хотя, тут еще надо подумать); в этом случае платформа будет таскать за собой эрию, а эрия будет своей гравитацией самостоятельно таскать за собой все физические тела (кроме кинематиков, разумеется) на уровне физического движка.
Если же ты пользуешься кинематиками - то сам себе злобный буратино. Побежал за упрощением - получи подарочек - реализуй всю кинематику самостоятельно.
Пока у меня код выглядит так:
var jump = 100
func _physics_process(delta):
if Input.is_action_pressed("ui_jump"):
velocity.y = -jump
На самом деле всё довольно просто. Гравитация должна действовать на него всегда, если он не стоит на полу. Есть стандартный метод is_on_floor(), но он действует мутновато, или можно сделать ray_cast вниз, который либо пересекается с хитбоксом пола, либо нет (а лучше даже два, справа и слева).
Если персонаж летит, то velocity.y += gravity, а если стоит на земле, то velocity.y = 0. Ну а прыжок можно оставить как есть.
На дельту множать пробовал, проблема разных прыжков от этого не исчезает.
>>683210
Если я обнуляю velocity.y то персонаж ходит по воздуху, время от времени резко проваливаясь вниз.
>Проверь, не может ли ещё с чем-нибудь коллайдить твой луч, может быть с хитбоксом самого персонажа или каким-нибудь другим мусором.
Как это проверить?
Решил тут забабахать на прошлой неделе спутник вокруг планеты с возможностью изменять орбиту в процессе. Сперва хотел сделать орбиту по сложным формулам, потом понял, что перебор и что-то не то. Решил проще. Эмпирическим путём с использованием листа бумаги, пластикового шарика, расчерченного простым карандашём и школьного курса геометрии пришёл к тому, что кое-как просчитывал тетта в развисимости от скорости и известного фи.
Получилось примерно ровное орбитальное движение. Кроме того факта, что пидорасить иногда начинает (плюс я не описывал всякие пограничные случаи - прототип же). Но, например, спутник просто бесконечно ускоряется. Но не это проблема.
https://pastebin.com/shGDzxW8
Этот код запускает falcon 9 мой спутник Swan.
Вчера я узнал про кватернионы, ещё раз понял, что неделю делал не то. Но вот кватернионы раскусить не могу. Вот это проблема. На годофорумах нашёл пару тем, там какие-то обрывки, понятнее не стало вообще.
Может кто-то краткий пример рабочий показать?
>>682324
Марин какой-то.
Если с кватернионами лётчик выходит, и комплексные числа не любишь, используй матрицы поворота и углы Эйлера, они более естественны, первый курс линейной алгебры/механики твёрдого тела.
Кватернионам мало где учат, потому что в доконпуктерную эру их нигде толком и не применяли, но вообще там тоже несложно: кватернион — надстройка над комплексным числом с тремя мнимыми единицами, нам нужно только уметь их перемножать и ввести правило, по которому они ставятся в соответствие поворотам на разные углы. А эти правила есть хоть в той же Википедии.
if Input.is_action_pressed("ui_left"):
velocity.x = -sp33d
elif Input.is_action_pressed("ui_right"):
velocity.x = sp33d
else:
velocity.x = 0
Как фиксить?
Почитай про контейнеры.
https://docs.godotengine.org/en/stable/tutorials/gui/gui_containers.html
Другие хвалят квартенионы.
Кому верить, если проверить не хватает мозгов?
Вообще, зачем нужен кватернион - он поворачивает по всем 3-м осям одновременно. В обычном случае тебе придется
1) Определить порядок поворота и нигде и никогда его не путать. rotate_x(a).rotate_z(b) не то же самое что rotate_z(b).rotate_x(a).
2) Гимбал лок - при определенных углах поворотах у тебя две оси "схлопнутся" навсегда и будет непонятно как вычислять дальше.
Кватернионы не нужны, если у тебя например туррель, в которой башня поворачивается только на оси Y, а пушка - чайлд нода, которая ходит только вверх-вниз. Тогда, понятно, что намного проще просто поворачивать их на заданный угол.
Квартернионы скорее всего не нужны если у тебя шутер без наклона головы. Если тебе захочется плавного сглаживания мышки, то
>можно получить кватернион из базиса трансформы, покрутить-послерпать и записать обратно.
Квартернионы нужны, если у тебя свободная ориентация камеры космосе.
Все имхо могут быть неточности в терминологии.
>Определить порядок поворота и нигде и никогда его не путать. rotate_x(a).rotate_z(b) не то же самое что rotate_z(b).rotate_x(a).
Помню, как впервые с этим столкнулся.
Гифки в https://docs.godotengine.org/en/stable/tutorials/3d/using_transforms.html очень помогли.
func _physics_process(delta):
if Input.is_action_pressed("ui_shoot"):
shoot()
func shoot():
var snowball = load("res://snowball.tcsn")
var bullet = snowball.instance()
add_child_below_node(get_tree().get_root().get_node("Game"), bullet)
Когда нажимаю на кнопку выстрела выдет ошибку пикрил. Что с этим делать?
Это означает, что ты вызываешь instance() на объекте, который не инициализирован (= null)
Возможно ты опечатался в пути к сцене. Проверь большие, маленькие буквы, папки.
Вообще прям так делать как у тебя не стоит. Ты же на каждый выстрел загружаешь файл заново. Вынеси эту переменную в начало скрипта, вне функций и вызови preload вместо load
onready var snowball = preload("res:/...")
Спасибо, анон.
Теперь возникла другая проблема: вместо того чтобы лететь по заданной траектории, пуля останавливается в центре игрока, причем пули которые были поставлены на уровне через редактор работают нормально. Убирать коллизионшейп пули пробовал, ничего от этого не меняется.
Также при нажатии на кнопку выстрела выдается вот такая ошибка в отладчике: add_child_below_node: Cannot move under node
В чем тут проблема и как ее решить?
Ты не по туторам делаешь чтоль? Глянь это хотя бы. https://www.youtube.com/watch?v=UKfzBnfh4Ak&list=PLsk-HSGFjnaFC8kEv6MaLXnnDcevGpSWf&index=4
>Каким образом ты задаешь траекторию?
extends KinematicBody2D
var velocity = Vector2()
func _ready():
velocity.x = 160
func _physics_process(delta):
move_and_slide(velocity)
>Зачем тебе именно below?
Так было в туториале и по другому игра просто крашилась выдавая ошибку
>Но заметил что разрабы скейлят текстурки и вместе с ними разрешение в 2-3 раза.
>В чем профит этого?
Современнные мониторы хреново, переключают разрешение, предпочитая работать в нативном для них. Поэтому ты вибираешь базовое разрешение для своей игры и потом скейлишь его выбранным способом. Если это пиксельарт, то скейлить надо в целочисленном выражении, иначе будет смотреться как говно. Есть правда один способ, как скейлить пиксельарт на не целые числа, но на готовых движках ты его не реализуешь, надо свой рендер писать.
>>683921
>Единственное что приходит в голову - какие-нибудь шрифты или UI можно сделать меньшими пикселями чем всю остальную игру и засунуть туда больше инфы.
Нет, так только пидоры делают. Ну уподобляйся.
Судя по коду выше в треде, если код там твой, то вынужден констатировать факт, что ты вообще основ информатики не знаешь и надо бы тебе их подучить, прежде чем лезть в геймдев. Геймдев это сложная индустрия (она тебя сожрёт), берущая в себя самые совершенные методики кодинга, а ты даже сделать переменной линк на сцену в коде не догадался. Это классика, блять, это знать надо ДО того как решил в геймдев вкатиться.
>Поэтому ты вибираешь базовое разрешение для своей игры и потом скейлишь его выбранным способом. Если это пиксельарт, то скейлить надо в целочисленном выражении, иначе будет смотреться как говно.
Так годот кажись все текстурки автоматом скейлит при ресайзе окна, ну то есть если запустить игру в 320x240 и растянуть с keep aspect, то он просто их сам как подобает увеличивает.
Типа такого:
var d1 = {"one" : 1, "two" : 2}
var d2 = {"three" : 3, "four" : 4}
var d3 = unite(d1, d2)
#теперь d3 это словарь, который содержит "one" : 1, "two" : 2, "three" : 3, "four" : 4
Не может быть простого и удобного всем метода для объединения словарей. Что делать с под-словарями? Записывать как ссылку или дубликат? Что делать с совпадающими ключами? Дублировать? Перезаписывать? Метод, который бы описывал все варианты, обладал бы кучей запутанных аргументов. Поэтому надо писать свой, подходящий под твои задачи.
Вот здесь юзеры написали несколько вариантов: https://godotengine.org/qa/8024/update-dictionary-method выбери понравившиеся.
Спасибо, анончик.
Насчёт под-словарей вообще странный вопрос. Словарю должно быть всё равно, что у него внутри. А вот насчёт совпадающих ключей... ну фиг знает, на мой взгляд, такая функция должна перезаписывать их по умолчанию.
Ок, к счастью, у меня простой случай без вложенных массивов и совпадающих ключей (а если и совпадут, то перезапишутся), так что объединю по старинке, циклом.
> Словарю должно быть всё равно, что у него внутри.
А тебе - не всё равно. Ты, например, сделал словарь-шаблон и пихаешь его подсловарём в рабочие словари, потом без задней мысли пишешь в него данные, потом без задней мысли копируешь рабочие словари. А потом хуяк!
Сам на такое натыкался. Впрочем, лечится быстро и легко встроенным методом duplicate()
Ну вроде вот победил - можно меня поздравить.
Опять же ощущение что хоть и выполнил урок кое-как, то самому подобное повторить подобное сейчас пока нереально. Хоть еще 3 раза перепроходи и запоминай что и зачем куда накликивал да кури каждую функцию.
>ничего не накликиваешь обычно, а хуяришь код и все задачи выполняешь тоже кодом
1. открой папку проекта в проводнике виндовс
2. большинство файлов можно открыть обычным блокнотом как текст
3. изучаешь структуру кода
4. пишешь такой же, только вручную, в любом удобном текстовом редакторе
Но это извращение какое-то, конечно.
Ты можешь накликивать поменьше, а хуярить кода побольше. Я тоже всю жизнь писал на сях и паскалях, пытался велосипедить свои игоры на них, но особенных проблем с переходом как-то не возникло. Попробуй сделать какую-нибудь свою игру. Воспринимай ноды как просто классы, поля в которых ты задаёшь в гуе, но методы ты всё равно пишешь в скриптах кодом. (Кроме стандартных, конечно, но стандартные описаны в документации.)
Если ещё строже говоря, можно открыть сорцы движка в ИДЕ и лепить поверх него свою игру на крестах. А потом сконпелировать. Можно вообще отказаться от системы нод и юзать только импортеры ресурсов, а игровую логику построить на своём велосипеде. Таким образом движок выступит в роли уже написанного Хуаном за тебя бойлерплейта.
На новой стартовой позиции никаких коллизий, естественно, нет, она висит в воздухе.
Да, ничем не мешает. Если это какая-то о-о-очень глубокая особенность движка, я готов забить.
>>684989
На самом деле я даже не перекидываю, это я написал не вполне корректно. И уровень и прото-говнист — дети корневой ноды, поэтому я просто удаляю старый уровень из дерева, добавляю новый уровень, меняю их местами, чтобы ГГ был выше террейна, перемещаю его в точку спавна на уровне (у всех нод начало координат в нуле, так что всё попадает куда нужно), и иду играть.
Имеем дверь - AnimatedSprite. У двери две анимации: open и close. На каждую анимацию есть несколько разных картинок: варьируется расцветка и степень поломанности. В каждой картинке одинаковое количество кадров.
А теперь вопрос. Как быстро ИЗ КОДА заменять эти картинки? И как ИЗ КОДА узнать адрес используемой в данный момент картинки? Я просто раньше это делал только из редактора, а сейчас дошли руки до сохранения/загрузки, встал вопрос о том, чтобы загружать точно такую же дверь, которая и сохранялась.
Не знаю что ты подразумеваешь под "адресом" используемой картинки. Но при загрузке это так не работает - в программе все адреса сменятся. А из за многопоточности ты даже не можешь быть уверен что у них порядок в памяти после загрузки будет такой же.
Тебе надо организовать все так, чтобы ты точно сам контролировал. Вижу тут два пути - если у тебя все-все двери в одном атласе, то анимация открывания обычной двери это кадры 0..3, закрывания 4..7, открывания сломанной двери 8..11 и так далее - то как написал этот анон >>685092
Если у тебя разные картинки, то тебе надо завести массив SpriteFrames.
Вот что то типа такого васянства:
onready var doors = [ preload("res://normaldoor_spriteframes.tres"), preload("res://brokendoor_spriteframes.tres"
) ]
...
func _ready():
frames=doors[0]
(frames во множ.числе)
Сами spriteframes можешь тупо сохранить из редактора
> Как быстро ИЗ КОДА заменять эти картинки? И как ИЗ КОДА узнать адрес используемой в данный момент картинки?
Отвечает Александр Друзь:
Никак. Нирикаминдую такой подход. Перепроектируй дизайн с другой стороны: У тебя есть объект (дверь). У объекта есть состояние (из набора допустимых состояний). Объект может получать сигнал об изменении своего состояния (при вызове своего метода set_state). При изменении своего состояния он самостоятельно меняет свои внутренние параметры, в том числе картинку/текстуру. Если тебе нужно узнать, какое у объекта сейчас состояние, сделай метод get_state. Если тебе нужно чтобы объект передавал ссылку на свою текущую текстуру, сделай метод get_texture. Надеюсь, ума хватит, как создать такие методы? Там блять по одной двум строчкам кода.
>tres
Это, по-твоему, картинка?
Данное решение, конечно, работающее, но есть у него одна важная проблема: оно требует дополнительной конвертации ресурсов. То есть, нельзя просто так взять и нарисовать новую картинку, нужно из неё делать ресурс, сохранить отдельным файлом, а потом грузить уже его. Костыльно. А если картинок много? И вообще, с таким подходом проще делать каждую дверь отдельной сценой и вообще ничего не грузить: файлов получится столько же, а кода меньше.
Я тебя понял, видимо AnimatedSprite рассчитан на другой юз кейс. Он очень упрощен. А ты хочешь один раз разметить анимации и кадры, а потом подложить новую картинку с точно таким же расположением кадров на ней. Тут логичнее делать на просто Sprite с SpriteSheet + AnimationPlayer.
Если же тебе надо именно AnimatedSprite. Это возможно, но все равно будет костыльно. Во-первых, ресурс spriteframes в текстовом редакторе, или скриптом. Просто копируешь и меняешь в нем имя картинки. Во-вторых, можно склонировать spriteframes, т.е. взять готовый, создать новый, и добавить в него по очереди все анимации и все кадры, подставляя другую картинку, но это тоже чего то многословно. Строчек 20 будет.
>Тут логичнее делать на просто Sprite с SpriteSheet + AnimationPlayer.
Знаешь, а ведь верно. Почему-то я упёрся именно в анимированный спрайт, типа, это же специализированное решение для простых пиксельных анимаций, и совершенно проигнорировал такую вот возможность. А ведь с анимейшон-плеером можно обойти несколько не очень удобных костылей, которые пришлось добавить в код: например, инвертирование направления открытия.
Пожалуй, да, так и сделаю.
Не так, как предполагалось, но ты мне помог. Бобра тебе.
>Он очень упрощен.
Скорее он недостаточно усложнён. Позволяет подгружать индивидуально текстуры для каждого кадра анимации, но не даёт к ним доступа. Кажется, будто разрабы начали пилить ноду для анимации, но потом забили, потому что сделали универсальный анимейшонплеер.
Вот собственно весь код (ну единственное что я гружу одну картинку. Там может быть массив, либо вообще сканировать всю папку)
У меня вопрос, где вы обучались кодить в mono версии, если здесь такие есть?
В том смысле что я хоть и учусь кодить на плюсах/шарпе уже несколько месяцев, но нормального, не то чтобы описания, а логики применения функционала/классов нигде не описано. В результате не знаю даже как kinematicbody заскриптить самостоятельно. Более менее нормальную схемку нашёл в жопе документации, но это лишь взаимосвязь классов.
Вобщем, шалом. Я протрезвел и готов отсыпать крупицу своей мудрости.
Во первых. Забудь про AnimatedSprite, он годится только для совсем простых анимаций. Как только у тебя появляется хоть какая-нибудь идея "а как бы мне сделать...", сразу бросай AnimatedSprite и переходи на связку Sprite + AnimationPlayer (+AnimationTree)
Это намного удобнее и пизже. Т.к. в Sprite можно точно так же спрайтшиты запихивать, а возможностей анимации у AnimationPlayer намного больше. Он вообще может анимировать все, а не только кадры.
Суть способа проста, ее уже в треде описали. Сканируешь каталог на картинки, загружаешь их как текстуры в список и по мере необходимости достаешь их оттуда и вкидываешь в свойство texture спрайта. Естественно картинки должны быть подогнаны друг под друга.
Способ рабочий, сам пользуюсь. Все что нужно есть на пике с комментариями. Да это C#, потому как я вротебал этот ваш ждскрипт.
Небольшой ньюанс на тему сканирования имен файлов в каталоге. Если делать это в режиме редактирования, то на выходе получаешь вперемешку .png и .png.import файлы. Ну ты естественно думаешь, раз мне нужны картинки то и брать я буду только png, и подсовываешь в load только их. Все работает - круто. Потом ты экспортируешь проект и внезапно все ломается. А окажется, что сами png-шки при экспорте помещаются совсем не туда где они лежат при создании проекта, сюрприз. А в каталоге где они должны быть, остаются как раз только .png.import файлы. Вот как-то так. Собственно поэтому на пике я так странно с именами фалов обхожусь. Это не баг, так и задумано. Только, естественно, в инструкции хер найдешь сходу об этом упоминание.
>У меня вопрос, где вы обучались кодить в mono версии
Если по шарпу, то х.з. как-то само методом тыка. Я слегка покодил на ждскрипте пару недель, чтобы разобраться в api движка. Потом пересел на mono версию и потихоньку начал. Там в принципе все просто. Заменяешь названия всех (99%) методов на PascalCase вместо camel_case. Исключений не слишком много, в основном в функциях типа CallDeffered, где методы вызываются в кавычках. Ну а дальше стандартное решеточное погромирование.
Учесть стоит, что отсутствует модификатор onready, поэтому в этих случаях надо разделять объявление и инициализацию переменных.
--------
А вообще поставь Visual Studio Code с плагинами C# и C# tools for godot, там в intellisense будут подсказки по всем методам.
--------
Насчет плюсов, я х.з. мне просто лень, честно говоря, с ними возиться. Была идея пиксельные коллизии прикрутить, но я забил, т.к. не хочу с компиляцией и сборкой трахаться.
---------
Если по сишарпу вопросы есть, можешь задавать попробую ответить.
>Если по сишарпу вопросы есть, можешь задавать попробую ответить.
По нему самому в общем-то вопросов нет за исключением особенностей использования модификатора public, а вот:
>методов на PascalCase
>camel_case
>функциях типа CallDeffered
>решеточное погромирование
в душе не ебу что это.
До меня еле-еле начинает доходить какая роль у ready, physics process, input в рамках древа сцены, и то из gdscript кода.
Интуитивно догадаться на счёт всех функций и иерархий/взаимодействий невозможно просто, вот в чём дело. Какую-то бы схемку на подобии того что скинул я, но с функциями и нодами.
>в душе не ебу что это.
>>685781
>+ неясно каких типов параметры функции принимают и что опять же в рамках иерархии нодов с ними производят и что возвращают и куда.
Блин, чел, ты про что вообще спрашиваешь? Если про C#, то все это в мануале подробно расписано. Что и где принимает и выдает и делает. Я не вижу смысла сюда постить целые куски оттуда.
Если же про плюсы, то я х.з. может тебе и не стоит туда лезть если ты этого не понимаешь?
В том то и дело что нихуя не описано. Отдельные функции и классы пожалуйста - но про их взаимосвязь, возможности применения и то как они влият на то, что в конечном итоге видит игрок - инфы ноль.
Вот например здесь:
https://docs.godotengine.org/ru/stable/classes/class_kinematicbody.html
Я буду переходить по охуенному множеству ссылок на функции и классы, но у меня не сложится целой картинки чтобы я самостоятельно мог найти хотя-бы 70% существующих решений для kinematicbody, к примеру хотя бы примерно представлять себе как можно "присобачить" туда вращение камеры, как головы, без поворота меша.
Это тебе надо просто демо проекты качать и разбираться в них.
К примеру вот отсюда:
https://github.com/godotengine/godot-demo-projects
Там много разных минипроектов. Качаешь, импортируешь, играешься с настройками/параметрами и изучаешь.
Когда разберешься влезать в C# и делать по аналогии.
>Небольшой ньюанс на тему сканирования имен файлов в каталоге
Тащемта я этой ерундой заниматься не собираюсь.
У меня всего одна сцена с дверью, корнем которой является спрайт. На уровне я расставляю двери и задаю каждой свою текстуру. При сохранении просто спрашиваю у этой текстуры её resource_path, каковой и записываю в файл сейва. Соответственно, при загрузке картинка грузится именно по тому пути, с которым сохранилась. С таким подходом меня вообще не касается, где именно лежат эти файлы, лишь бы за время между сохранением и загрузкой они не переместились.
А так, в общем, я уже переделал на Sprite. Только теперь тестовый уровень переделать надо.
>C#
Когда я осваивал Годот, у решётки была очень плохая поддержка. А то бы тоже на ней кодил.
Я в нулевых кодил на Delphi, ещё со времён, когда в журнале Хакер его пропиарили и был цикл статей с уроками. Потом я устраивался на галеру (молодую, развивающуюся компанию) там на дельфи хуярили большой программный комплекс. Там меня заставили выучить ООП и паттерны.
Сегодня, когда возникла необходимость учить Шарп, я его собственно говоря не совсем учил. Я просто прочитал какие у него ключевые слова, сел и начал писать код на Шарпе. По сравнению с Паскалем Шарп легче и удобнее раз в десять. И не мудрено! Ведь автор Шарпа - это тот самый чувак, который делал Паскаль для дельфи в борланде! Он понял, что Паскаль отжил своё, и пошёл дальше, а авторы фрипаскаля не поняли и зависли в прошлом со своим лазарусом.
Так вот, к чему этот пост: с моим вышеописанным бэкграундом, я лично не вижу никаких неочевидных вещей в АПИ годота. Вот реально. И меня вводят в ступор просьбы ИТТ объяснить что-то такое.
Что?
Годот сделан чотко по олдовым гайдлайнам, мне он интуитивно понятен, как будто я на миллиардах таких движков игры делал, ну вы понели, кек
У него есть некоторые переименования логических сущностей, например то, что в шиндовс называется ивентами, здесь названо сигналами, как в линуксах. И каждое такое переименование существует не просто так. Хуан действовал с презрением к зумерским трендам и я его в этом полностью поддерживаю.
Нужно быть достаточно эрудированным, чтобы понимать суть переименований в АПИ движка.
>С таким подходом меня вообще не касается, где именно лежат эти файлы
Ну я х.з., кому как, мне не по кайфу подход, когда надо в файловую систему, кроме как при инициализации проекта лезть почем зря.
Да и так мне кажется удобнее, собрать скины в одну структуру и потом выбирать их по номеру (ну или через enum, кому как)
>>685802
>Когда я осваивал Годот, у решётки была очень плохая поддержка. А то бы тоже на ней кодил.
Я начинал с версии 3.1, там непонятно было, "вроде C# есть, а вроде и хрен знает, то ли будем развивать, то ли нет". Попробовал GDScript, но он не зашел, начал делать пару проектов, но забросил. Потом вернулся к Godot-у уже на 3.2.1 и сразу решил переделать все с нуля на C# на удивление очень мало времени ушло. Сейчас в проектах GDScript вообще не использую, даже прототипирую сразу на решетке - удобнее.
------
>>685813
Thumbs up. Same shit, тоже когда-то на дельфях кодил, Когда перелез на C# сильно удивился и был рад удобству языка.
>Ведь автор Шарпа - это тот самый чувак, который делал Паскаль для дельфи в борланде! Он понял, что Паскаль отжил своё
После занесённых чемоданов
https://web.archive.org/web/20200509231352/http://techrights.org/2009/09/14/ms-admits-draining-to-destroy-borland/
>По сравнению с Паскалем Шарп легче и удобнее раз в десять
Судя по всему у тебя проблемы со скоростью печати, раз тебе {скобачки} легче и удобнее языка здорового человека.
>>685814
>меня вводят в ступор просьбы ИТТ объяснить что-то такое
В годот в 99% случаях вкатываются люди с нулевым кодерским бэкграундом. Максимум на питоне говноскрипты запускали.
>>685823
>Когда перелез на C# сильно удивился и был рад удобству языка
Я вот сижу на Pascal/Delphi/Lazarus, с моей точки зрения C# выглядит как "типичный мерзкий C". Не понимаю, кому он удобен.
>>685829
Можно tl;dr? Микрософт как всегда задушил конкурента и сделал "как у них, только своё"?
Алсо нужно отметить, что был ещё Oxygene, это почти Delphi на базе .NET, или почти C# с синтаксисом Pascal.
https://en.wikipedia.org/wiki/Oxygene_(programming_language)
А так, никто не мешает компилировать под .NET с любого ЯП, но я считаю это извращением, .NET должен сдохнуть в муках.
Такой вопрос, Godot потянет что-то уровня Worlds Adrift?
https://store.steampowered.com/app/322780/Worlds_Adrift/
Насколько сложно будет разрабатывать подобную игру на нём?
Оригинальный Worlds Adrift был сделан на Unity, с использованием каких-то закрытых дорогих технологий (в основном для организации ММО, я так понял), очень сильно лагал и глючил (сервера, разумеется, клиент был более-менее норм, но одиночной игры не было), в итоге проект высосал весь бюджет разрабов и был закрыт, оставив игроков ни с чем. Потом ещё были попытки создать клоны, типа Voids Adrift - тоже на Unity. Но, судя по всему, они провалились - проект всё-таки сложный и т.д.
Сам я сперва думал "а чо я, не погроммист шоле" и порывался написать свой движок под это дело на паскале, но столкнулся с непреодолимыми трудностями - в частности, я понятия не имею, как реализовать годную 3D физику, и вообще все эти математические расчёты вгоняют меня в депрессию. Мне бы хотелось готовый движок, который делал бы всю математику вместо меня, и делал это быстро и точно, а не как я.
Сомнения гложат меня по поводу простоты использования годота для такого проекта - не придётся ли вручную разрабатывать всё то, что должно быть в движке из коробки? Потому что я не хочу разрабатывать что-то для чужого движка, я бы лучше для своего разрабатывал. И потянет ли годот подобный опенворлд со сборкой конструкций из блоков? Хочется чтобы было просто, быстро и производительно, но юнити мне не подходит, а годот я уже щупал и более-менее понимаю (хотя вижу, что тут много чего нет, например, чарактер контроллера нет)...
>Сомнения гложат меня по поводу простоты использования годота для такого проекта - не придётся ли вручную разрабатывать всё то, что должно быть в движке из коробки?
С учетом того что он в Hello Cube умудряется показывать консольные ФПС вместо пекарских - думаю, ты ошибся движком, там всё еще хуже чем на юнити будет.
Чарактер контроллер можешь через вкладку assetlib скачать. Что толку пихать его фкаропку, если это очень интимный компонент игры, который ты все равно будешь перепиливать под свои нужды? Ради прототипа подойдет то, что в ассетлибе представлено. А если молиться на широко кастомизируемый компонент с кучей настроек в инспекторе, то у тебя получится ровно такой же пиздец в твоём проекте, как ты описал.
>Hello Cube умудряется показывать консольные ФПС вместо пекарских
Вот не надо тут, кубик вполне нормально рисуется. И меня интересует лёгкость разработки, а не число ФПС в итоге.
>>685870
>Судя по описанию, разрабы той игры именно в архитектуре проебались.
>Доверились платным закрытым компонентам и закономерно соснули.
Они просто вообще в программирование не умели, у них редкие глючные мобы давали 90% нагрузки на сервер, лол.
>Что толку пихать его фкаропку, если это очень интимный компонент игры, который ты все равно будешь перепиливать под свои нужды?
А как мне его тогда пилить? Пробовал через капсулы - глючит. Пробовал через рейкасты - глючит. Пробовал разные виды физических тел, всё равно глючит. Смотрел примеры готовых контроллеров, но у них ограничения по типу "ходить можно, но для лестниц и рамп ничего не предусмотрено" - то есть в готовых есть только то, что я и без них могу сделать, а того, что я не могу сделать, там нет.
И вообще, очень много деталей контроллера есть во всех играх, можно было бы обобщить как-то, и кодить только частные случаи.
>широко кастомизируемый компонент с кучей настроек в инспекторе
Тогда не надо вообще было инспектор делать, потому что какой тогда от него толк? Делают движок с заявкой на простоту как у конструктора, а в итоге строительных кирпичиков просто нет, и никакая библиотека ассетов не спасёт... И так со всеми "топовыми" движками. Или это со мной что-то не то. Хочется просто сделать игру, а не трахаться с математикой и всем остальным.
Я сначала плевался на гдскрипт и пытался все писать на с++. Но это дольше. Поэтому довольно быстро перешел на гдскрипт. Сейчас перехожу на C#. Самого опыта у меня в шарпе было много (со времен .NET 2.0 и Compact Framework) + несколько лет коммерческого на j2me и андроида, а как известно C# это просто улучшенный клон Джавы.
Так что могу посоветовать со своей колокольни - отдельно подучи C#, и просто переписывай туторы с GDScript на C#, они будут практически 1 в 1, просто имена немного по другому пишутся (_Ready() вместо _ready()). В большей части документации можно переключаться между вкладками с примерами на обоих языках.
>До меня еле-еле начинает доходить какая роль у ready, physics process, input в рамках древа сцены,
Это все описано в документации.
Например общий обзор тут https://docs.godotengine.org/en/stable/getting_started/step_by_step/your_first_game.html
Вообще это как бы стандарт. В какой нибудь винде все точно так же - есть стандартный список событий, а ты сам пишешь для них обработчики, которые система дергает.
Или вот например Step by Step scripting
https://docs.godotengine.org/en/stable/getting_started/step_by_step/scripting.html
https://docs.godotengine.org/en/stable/getting_started/step_by_step/scripting_continued.html
Или формальное описание самой ноды - в начале описывается примерно архитектура
https://docs.godotengine.org/en/stable/classes/class_node.html
Но вот в самих классах на C# вроде нет описания. Зато нашелся какой то сайт где можно посмотреть как называются классы, методы и поля - https://godotsharp.net/api/3.2.0/
Сначала хотел ответить нет, но потом посмотрел видео с ворлд адрифтом - и думаю все таки да, можно. Сложно, но можно. Но ведь там просто лоуполи, очень много повторяющихся ассетов, которые можно загнать в multimeshinstance, и вроде площади самих островов небольшие. Думаю, на сегодня вот такая игра примерно предел возможностей.
Пост не ради срача, я просто выбираю для себя движок.
Вот например мне нужно привязать камеру к player'у, я нашёл видео, что это можно сделать в контексте physics process методами get_parent и get_global_transform. Вопрос на миллион: что бы было, если бы я не нашёл этого видео? Откуда бы я узнал что это нужно делать в рамках physics process, а не ready? Ни в каких мануалах таких моментов не объясняется.
Тут, такая штука. Если ты не понимаешь в _process тебе надо что-то пихать или в _ready, то ты в принципе не понимаешь их суть. А она настолько проста, что если ты этого не догоняешь, то тебе вообще надо с самых основ начинать. Возьми самый обычный куб и просто подвигай его по сцене, для начала. И прочти уже мануал, там все это есть.
Новичок ни откуда ничего и не обязан знать. Но на то он и новичок. Если у него нет проблем с вниманием и усидчивостью, он прочитает всю документацию step by step. Там все это есть.
А еще нужно думать своей головой. Вот когда ты едешь в метро, у тебя есть положение как относительно вагона, так и относительно мира. Даже если бы метода глобал не было, ты мог бы догадаться как это вычислить на основе школьной математики. Это опять же стандарт в 2д и 3д в компьютерных программах.
А еще можно решать задачу разными способами. Например можно взять ноду InterpolatedCamera. Или RemoteTransform и SpringArm. Или видел кто то делал камеру на Path. Или писать код с квартернионами.
Пока ты новичок у тебя нет особого выбора кроме как постепенно читать/смотреть по все последовательно. Нейролинков пока не изобрели.
Если у тебя обычная игра для геймджема, типа платформера, ты просто не упрешься в производительность скриптов. Если у тебя сотни объектов, или карта на тысячи динамически просчитываемых ячеек, то конечно бери c#/с++
Но надо понимать что скорость разработки на них будет обратно пропорциональна.
>Новичок ни откуда ничего и не обязан знать
Изначально вопрос был в том, где материалы опытные брали во время своего обучения, базовые туторы из документации явно далеко не всё.
>он прочитает всю документацию step by step
Там элементарной вещи как камеры с привязкой к синематикбади (и как оно вообще связывается, что допустимо в контексте функции и их взаимосвязи с классами) не прописано, что в 3д сцене основа основ между прочим.
>Даже если бы метода глобал не было, ты мог бы догадаться как это вычислить на основе школьной математики.
Бляпиздец, а ничего что я в голове у разработчиков не живу и не знаю на основании чего конкретно они именуют функции/классы/структуры? Тем более что этих функций ёбаные сотни, и угадать их название и назначение невозможно, а тупое зазубривание не даст целостного представления о функционировании древа.
>Но надо понимать что скорость разработки на них будет обратно пропорциональна.
С чего бы? Алгоритмы одни и теже что на скрипте, что на нативе. Синтаксис около близок - все оно си подобно. Теже ифы, теже циклы, теже функции. Таже процедурщина, тоже ооп. Ладно бы если речь была о фунциональщине - типа лиспа. А тут языки одного уровня
Вечно несут бред про какую-то сложность нативных языков. Я хз что там сложного может быть.
Это не бред, это объективный факт. Подобны, только в си++ компиляция в разы дольше - раз, уже медленнее каждый раз запускать после изменений. Писать нормальный код без утечек памяти, без использования после удаления, без обращения за границы массивов, без UB, без ворнингов (потому что они обычно свидетельствуют о потенциальной ошибке) - это отдельно все требует времени, как и поиски волшебной порчи стека, когда у тебя написано i = 42 а в переменной оказывается 13. Плюс такие вещи как описать корректно класс - создать все эти версии копирующих-перемещающих конструкторов-операторов присванивания, виртуальных деструкторов, правильных модификаторов доступа при наследовании. Даже не пытайся утверждать что это быстрее чем просто наговнокодить на питоноподобном языке и оно даже сразу заработает, а при ошибке упадет с вменяемым сообщением об ошибке.
>Изначально вопрос был в том, где материалы опытные брали во время своего обучения
Из описаний нод, их методов. И здравого смысла (просто программистского опыта).
>Там элементарной вещи как камеры с привязкой к синематикбади (и как оно вообще связывается, что допустимо в контексте функции и их взаимосвязи с классами) не прописано
Нет нужды прописывать такую привязку как то особенно. Новичок просто бросит ноду камеры ребенком к ноде персонажа, и у него будет твердо привязанная камера со спины. Иначе все вырождается и начинает напоминать тетрис 1000 в 1: игра с машинками; игра с машинками и препятствиями; игра с машинками на время; игра с машинками и препятствиями на время и т.д. Этого не нужно - уже даны элементы из которых геймдевелопер сам соберет то что нужно. Вообще камера для TPS это сложная штука, ее все равно в один абзац не опишешь. У меня, к примеру, и сама камера это физическое тело, которое двигается в рамках заданного только для нее слоя с ограничителями. А еще ведь надо настраивать чтобы когда заходишь под потолок она хитро подлетала, или потолок становился прозрачным.
Как работают 3д трансформации описано здесь
https://docs.godotengine.org/en/stable/tutorials/3d/using_transforms.html
Или вот есть туториал про First person shooter
https://docs.godotengine.org/en/stable/tutorials/3d/fps_tutorial/index.html
>ничего что я в голове у разработчиков не живу и не знаю на основании чего конкретно они именуют функции/классы/структуры? Тем более что этих функций ёбаные сотни, и угадать их название и назначение невозможно, а тупое зазубривание не даст целостного представления о функцонировании древа.
Другого способа как прочитать все несколько раз и запомнить что запомнилось, человечество не изобрело. Вопрос только в том в каком порядке. Потому что в алфавитном скучно и не все одинаково важно.
>Подобны, только в си++ компиляция в разы дольше
но речь и про C#.
Кроме того если правильно сделать, время компиляции не будет дольше. Смотри Essential Engine - там скрипты на С++, запускается сразу. Мы уже давно живем не в девяностых.
>Писать нормальный код без утечек памяти
в C# нет ручного управления памятью. В с++.. умные указатели для неосиливших ручное управление. Какие еще утечки памяти?
И мы тут говорим о игровых скриптах, обычно в играх данные создаются один раз, удалять ничего не нужно (просто перезаписывать)..
>без обращения за границы массивов
В скриптах свои контейнеры, там есть уже все нужные проверки.
>>686168
>Плюс такие вещи как описать корректно класс - создать все эти версии копирующих-перемещающих конструкторов-операторов присванивания, виртуальных деструкторов, правильных модификаторов доступа при наследовании
Херня. А еще никто не запрещает писать в процедурном стиле без всяких там ооп и классов.
>>686168
>без UB, без ворнингов
это как раз не плюс. если у тебя где-то серьезная ошибка в логике, а скрипт все равно работает - ты ее так до релиза и не исправишь, из-за чего UB будет у твоих игроков.
Нет, мой основной язык С++, я пишу всю игровую логику на нем.
Питон быстрее для решения разных задач.
В скриптинге игр же разницы по скорости не будет - ты работаешь с сущностями движка и примитивной математикой-логикой. В скриптинге нет сложных задач на которых бы питон бы выигрывал. Ты не работаешь ни с файловой системой, ни с платформой, ни с чем-то подобным. Просто двигаешь туда-сюда модельки, да окошки показываешь-скрываешь.
Штоматьвашу? Чем ваш флоат отличается от моего флоата? Тем более что в данном случае это 0.
Вот бывает так, что кодинг вводит меня в ступор. Как это вообще возможно?
Все что видел - мультяшность.
Тыщетаешь хуйню. В любой современной системе от линукса до винды, от андроида до иос, пользователю запрещено лезть в файловую систему без рута. Годот просто следует этому годному и правильному принципу. Тебе выделено автоматом место в системе, в котором твои юзеры хранят файлы приложений. В каждой системе это место разное, тебе же дают ярлык user:// всегда указывающий в это святое место, вот и не выебывайся и храни сейвы с конфигами там. Можешь там папки сделать для удобства.
Код старый, со времён 3.0.6, возможно придётся поправить:
var img = Image.new() создаём объект-аналог-стрима паскаля
img.load(OS.get_user_data_dir()+"/"+$FileName.text) грузим в него файл по пути, указанном любым удобным тебе способом в специальном текстбоксе
var imgtex = ImageTexture.new() создаём объект-текстуру
imgtex.create_from_image(img, Texture.FLAGS_DEFAULT) грузим в неё данные из предыдущего объекта
А человек, не робот ли? В него заложили кучу программ: погладить котёнка, поебать бабу, поработать на работе, побухать с друзьями. Человек думает, что он думает, но не заложили ли в человека программу думать? Что есть человек? Самореплицирующиеся белковые нанороботы - ядра клеток. Между этими нанороботами образована химически-электрическая нейросеть.
Так что смотри, не думай слишком много, чеелоовеек.
Серьёзно? Ты такой аргумент пытаешься привести? Два гугловских бота как-то начали творить всратую хуйню - придумали свой язык и начали на нём пиздеть друг с другом, человешки обосрались и выключили их.
Я уж не говорю о научных программах, в которых эмулируется всратая хуйня наподобие искусственной жизни или фракталов каких, которая, несомненно логически детерменируема, только вот мощностей современных суперпека уже не хватит на детерминирование.
Реалистичность зависит от того какую графику засунешь.
>>686587
Фанаты загадочной-непознаваемой человечьей души, аргументируют, что роботы якобы на бинарной логике, но секундочку! На бинарной логике только нативные регистры микроконтроллеров, аппаратная же логика программируется уже уровнем повыше, где есть реальные числа с плавающей точкой, и на языках высокого уровня вполне возможно спрограммировать бота, который говорит: да/нет/не знаю/иди нахуй.
Такие пироги, человеки.
Вы думаете, что вы самоосознающие, и это делает вас не роботами на принципе самообучающейся нейросети, и благодаря этому, думаете вы, тот факт, что вы состоите из белковыех наномашин - не делает вас сложными, но механизмами.
Так вот, нихуя. Вы просто биологические механизмы с нейросетью, обслуживающей этот механизм. Deal with it.
У меня плоская картинка, на ней мосты. МНОГО мостов. Персонаж может пройти по мосту, а может под мостом; соответственно, коллайдится с разными слоями при этом; а по мосту и под мостом пролегают ареа2д, которые говорят "тут мост". Но вот только, когда персонаж проходит под мостом, он отрисовывается всё равно поверх картинки, так как это всего лишь фон. Вырезать каждый мост и делать его отдельной картинкой - это задолбаться, тем более что таких фонов планируется много. Вот я и думаю: может, шейдером как-то это можно решить?
Если ты залезешь под диван, но высунешь оттуда ногу, то тебя всего можно не отрисовывать?
>>686942
Погуглил. В любом случае надо рисовать маску. Заюзать именно полигон коллизии не получится вообще никак, няп. Ну ладно, в принципе, я уже почти все мосты из картинки вырезал, чтобы просто менять z-order персонажа при проходе под мостом.
Просто это куча механической работы, хотел от неё избавиться.
https://www.youtube.com/watch?v=VJMb88-d-js
Как лучше всего организовать РПГ-систему в порядке наследования и взаимодействия между собой? Пока что оставил набросок со всеми статами и парой основных функций, но жопа чует, что все заворачивать в один скрипт - не дело. Особенно касается конкретных моментов в виде получаемых свойств, травм, бонусов от сторонних систем и т.д., ибо по любому в таком случае будет такое спагетти, что даже Riot Games будет завидно.
Думаю да, могу потом проверить поточнее
двачерята, ВОПРОС.
Есть ли способ сделать гуй редактора худеньким?
шрифт меньше, отступы меньше, пустых пространств меньше?
чтоб тупо всё влезло на меленький экран?
типо что то вроде перфект пиксель гуй (гей)
Нормально впиливается. Когда я пилил рпгобразие, у меня было и того, и другого в достатке: каждый персонаж был наследником сцены «монстр», чтобы иметь ХПбар, манабар, статы и прочее безобразие (была ещё прокладка в виде «хуманоида», который умел носить оружие, чтобы не вышло как в байке про вооружённых свиней из «блицкрига»), а атака, например, прописывалась в скрипте оружия, которое подгружалось в ready как отдельная сцена.
В другом высере, где я дошел до статусов и краудконтроля, эффекты тоже были отдельными сценами, которые цеплялись к цели и мешали ей жить, пока не пропадали по таймеру. И ничего, всё нормально работало. Боты переходили с лука на меч, станились (точнее, отбрасывались, но тот проект я уже плохо помню, надо заглянуть) и никакому ООП это не противоречило. Не исключено, что я всё делал не по науке, но оно работало.
В годоте редактор является сценой игры, так что при желании можно даже из гдскрипта кастомизировать все под себя.
> Как лучше всего организовать РПГ-систему в порядке наследования и взаимодействия между собой?
Вопрос на миллион. Играет музыка из педерачи. На тебя смотрят Дибров и Галкин, один свирепо, второй с недоумением.
Паста Кирилла про эрпогэ не зря стала легендой копипасты. Потому что РПГ - это венец геймдевелопинга. Сложнее их нет. Ну, может быть только экономические стратегии, но я имею ввиду общепринятый жанр игор, а не специализированные. В РПГ тонны контента. Сотни параметров. Сложнейшие взаимосвязи. Движок тут не причём. Ты сначала садишься за ворд с экселем и проектируешь своё будущее эрпогэ, описываешь диздок и таблицы. Затем по результатам проектирования реализуешь проект. Идеального решения тут нет. Чем пруфом является всё многообразие ГПР от классики типо балдура и арканума, до новодела типо драгонэйдж, аутер волдс. Все они разные, несмотря на внешнее сходство обладают разными потрохами, разной механикой, разными
> моментов в виде получаемых свойств, травм, бонусов от сторонних систем и т.д.
Сразу отвечу на возможный вопрос вдогонку:
> а смогу ли я в годоте реализовать то, что напридумываю в диздоке абстрактно, в псевдокоде?
Да.
Тут, скорее, такой момент: имеет ли смысл делать конкретные категории статов персонажа отдельными узлами, а функции, связанные с ними - их наследниками? Или это лишняя ебля мозгов, когда уже надо будет взаимодействовать между разными категориями, которые может решить только главный узел?
никогда не программировал кун
Начни с простых 2д игр для начала. Там математика попроще. Уровня средней школы - координаты, векторы, скорость, ускорение. Все можно промоделировать на тетрадном листочке, это тебе не квартернионы и матрицы. Вот почитай https://habr.com/ru/post/131931/
Спрашивай что конкретно не понятно подскажем.
МУАХАХА! Я ЧУВСТВУЮ, КАК ГДСКРИПТЫ ЦИРКУЛИРУЮТ ПО МОИМ ВЕНАМ!
Нормализация - это когда вектор делают длины 1.0. Вне зависимости от того куда он повернут.
А что такое dot product я сам не понимаю. Вроде бы, это длина проекции одного вектора на другой при заданном угле между ними.
Для начала тебе хватит вот этой картинки.
Оке. Поставлю на рабочий стол, мб поможет
А рисовать так и не научился.
А то был у меня проект в кубиках, который я хотел бы проапгрейдить, так сказать.
Существуют, Gridmaps, там не самый удобный импорт моделек (или я не разобрался - дает импортить только .obj, и надо чтобы в блендере уже стояла в нужном отступе от нуля координат), но по большей части работает.
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
https://www.youtube.com/watch?v=UGltqKZFxrs
>>689054
На 100% не скажу, т.к. не копал реализацию, но порассуждаю.
GDScript вроде как интерпретируемый язык, но при экспорте проекта по идее все скрипты переводятся в некое подобие байткода, что-то вроде недо-JIT-компиляции. (.gdc файлы, вместо .gd)
Но тут два момента (даже три)
1) При запуске из редактора, скрипты скорее всего херачатся напрямую, без перевода в байткод (иначе невозможна была бы система их изменения на ходу, хотя могу ошибаться). В этом случае влиять будут даже пустые строки и строки с комментариями (хотя их влияние и будет микроскопическим).
2) Неизвестно, насколько происходит оптимизация скриптов при переводе в байткод во время экспорта. Вполне возможно там все лишнее, включая пустые pass-ы отбрасывается (что как бы по логике и должно делаться), а возможно и нет (учитывая уровень говнокодерства в некоторых решениях Хуана). Но вообще пишут об увеличении производительности при экспорте, по сравнению с запуском из редактора, даже в дебаг режиме.
3) При экспорте проекта есть опция в каком виде экспортировать скрипты. Text или Compiled, по идее это тоже должно вносить свою лепту.
------
Но если честно, все это просто мои поверхностные рассуждениия, т.к. я давно уже слез с иглы GDScript'а и пеоесел на лицо Сишарпа (чего и всем советую)
Там Моно, который поддерживает большую часть из C# 7.0. Не будет новых фишек из С# 8.0. Плюсы - выше производительность, возможность пользоваться привычными IDE, возможность копипастить готовые алгоритмы, а может быть и подключать целые либы (не уверен насчет последнего)
>Сишарпа же вроде не полноценная.
Сейчас там все ок.
>>689259
>Или, какие будут плюсы перед жидоскриптом кроме фигурных скобочек?
Скорость. Где-то от 4х до 10 раз быстрее гдскрипта.
Нормальный язык с нормальной статической типизацией.
Нормальный синтаксис (да скобки, намного лучше питоновского пиздеца с индент-форматированием)
>>689265
>а может быть и подключать целые либы (не уверен насчет последнего)
Да можно, причем как локально, так и через нюгет.
По сложности вкатывания, скорости исполнения и так далее
>По сложности вкатывания
Для того чтобы скриптовать на шарп придётся его подучить, хоть и у гдскрипта тоже си-подобный синтаксис. Да и в целом чуточку лучше код понимать будешь.
>скорости исполнения
Однозначно шарп быстрее, где-то говориться в 4, а где-то чуть-ли не в 10 раз.
>по идее всё должно быть как обычно, от левого верхнего угла
>Vector3
>Может в этой игре движение сверху вниз?
Нет, это FPS гайд
https://docs.godotengine.org/en/stable/tutorials/3d/fps_tutorial/part_one.html
>FPS гайд
А-а-а, ну тогда я понел. Собственная система координат тела построена так, что ось x идёт слева направо, а y — вдоль пинуса, так что вперёд — это по y.
А потом уже этот вектор пересчитывается в систему координат уровня, чтобы двигать тело по уровню. Должно быть как-то так.
Ну да, у тебя в шутере, если мы не рассматриваем прыжки, две степени свободы: вперёд-назад и влево-вправо. Так что ты перемещаешься по двумерному многообразию.
Но вообще говоря, этот вектор довольно бесполезный, он добавлен для читаемости кода. Можно было сразу взять нужный столбец матрицы перехода и не плодить сущностей.
Нормаль к поверхности, по которой ты ходишь.
Если я правильно понимаю их реализацию (а у меня кода нет), то вверх ты поползёшь только если в качестве пола будет вертикальная стена. А поворачивая этот inputMovementVector, ты будешь вертеться только в плоскости, параллельной полу.
Две строчки вниз от твоего скриншота.
Ось Y в годоте идёт вертикально. В двадэ она традиционно направлена вниз, ибо отсчёт алфавитно-цифровых дисплеев традиционно начинался с верхнего левого угла, из которого Y возрастал вниз, а X возрастал вправо. В триде не определились. У одних Y возрастает вниз, у других Y вверх, у третьих Z вверх, у четвёртых Z вниз. Хуан относится к тем, у кого Y увеличивается вверх. Повлиять на это нельзя. Просто живи с этим.
* Установить зависимость между
Постараюсь объяснить ничего не напутав.
Базис в Годоте - это три осевых вектора (ориентированные с учетом поворота объекта). Т.о. basis.z это сам по себе Vector3 смотрящий в сторону z относительно камеры.
Так что базисы тут не перемножаются. Умножается вектор пропорционально "тяге" в сторону в зависимости от нажатых кнопочек.
К dir (Vector3) сначала прибавляется таким образом скалированный вектор3 вдоль оси z, потом к нему прибавляется вектор вдоль оси x.
Умножение идет на величину в пределах -1..1
>почему базисы перемножаются
Матрица перехода — это матрица, переводящая вектор в одном базисе (неповёрнутом), в тот же самый вектор в другом базисе. Если ты в своём базисе (связанным с направлением твоего пинуса) прошёл на один метр вперёд, то для того, чтобы узнать, куда ты прошёл «на самом деле» в глобальном базисе, нужно домножить твой вектор (1, 0) на матрицу перехода.
Так вот, к чему весь этот высер: матрица перехода состовляется из координат базисных векторов, три столбца базисных координат тупо записываются в одну матрицу, и у тебя возникает ощущение того, что ты что-то там умножаешь на базис. Хотя строго говоря, на базис ты ничего умножать не можешь, потому что базис — это три вектора, для этого хозяйства не определена операция произведения.
Там пiддержку Lua будут делать?
> я Lua учу
> 2020
> я Lua учу, уже что-то понимаю. Зачем? Не знаю.
> Зачем?
Потому что ты прокрастинирующий ебанат. Выдыхай, бобёр! Учить надо то, что поддерживает индустрия: Си++, Си-шарп, гдскрипт, гамакоскрипт. Всё остальное просто берёшь - и игнорируешь нахуй. Питоны, луа, паскали и прочую ебанину.
>гитами
Ну допустим без него можно обойтись, скачивая в зипе.
>консоль prompt
Можно запускать прямо в VS code, я так всю разработку на плюсах веду тащемта.
>скунасами
Ну без него никак не обойтись имхо, переписывать на другую билдсистему целый движок очень затратно.
Но возможно это можно как то автоматизировать. Например у меня батник собирающий движок на основе этого https://gist.github.com/Calinou/6cd0c45f994b31f281eec66f0eeb401d
Можно как то настроить чтобы IDE дергала его вызов при сборке
Вообще добавление модулей это не такая частая задача чтобы для нее что то городить. А другие либы (по крайней мере header-only) ты можешь инклюдить прямо из своего модуля. Если либа с src, то добавить их в SCsub через *.cpp как показано тут https://docs.godotengine.org/en/stable/development/cpp/binding_to_external_libraries.html
В общем, прочитав эту портянку, пришел к выводу что собирать плагин на nativescript все равно надо сконсом.
https://godot-es-docs.readthedocs.io/en/latest/tutorials/plugins/gdnative/gdnative-cpp-example.html
>>690989
https://docs.godotengine.org/en/stable/development/compiling/introduction_to_the_buildsystem.html
Вот что мне к примеру с этим предлагает гайд сделать? Вставить куда-то или это py файл? Напоминаю что я не телепат
>>Scons с параметрами
>Что ты под этим подразумеваешь?
scons platform=list выдаст список доступных платформ:
>android
>javascript
>windows
и т.д.
scons platform=windows
соберет под винду.
>Какую именно консольку?
Системную.
В vscode у меня открыт терминал, это та же системная консолька.
Единственного Правильного Способа нет и быть не может. Учи, как тебе удобно. Главное - мотивация и искреннее желание делать игры. И во всём разобраться.
Посмотри видеоуроки сканера на русском языке в ютубе. Смотри прямо старые, невзирая на устаревшие версии движка. Скачивай те же самые версии движка и повторяй проект, ставя видос на паузу и ВРУЧНУЮ переписывай код с экрана, чтобы моторная память работала.
>туторы англоговорящих смотреть?
Смотри GDQuest (https://www.youtube.com/c/Gdquest/videos)
Нормальный инглиш, понятный без субтитров.
Под уроками обычно ссылка на гитхаб с проектом урока, где проект будет находится в состоянии Start (начальное) и End (законченое). Загружаешь и по ходу видео дорабатываешь проект из состояния Start в End и учишься.
Еще один показатель качества, что именно автора этого канала собираются привлеч в качестве майнтейнера официального годот мануала.
>Я бы под это определение назвал HeartBeast.
Да у него тоже неплохо.
----
>>692190
>но попробую старые уроки посмотреть.
>>692141
>Смотри прямо старые, невзирая на устаревшие версии движка. Скачивай те же самые версии движка и повторяй проект
Крайне не рекомендовал бы так делать. Т.к. в ранних версиях движка была куча подводных камней и косяков, для обхода которых много чего костылилось. И все это перестало работать с выходом 3.х версий годота. Ты просто потом потратишь кучу времени пытаясь понять почему у тебя в последней версии движка не работает то, что работало в предыдущих. Советую смотреть уроки только для версий движка 3.1.х и позднее. А более старые рассматривать когда уже будет понимание. что и как работает.
>У всех их основной пул туториалов на старых версиях движка.
Давно уже нет.
>Но доебался ты исключительно к сканеру.
Это был не я. Но по факту он в основном про 3Д ролики пилит, а мне оно нахуй не уперлось.
Я собственно вообще вообще по видеотуториалам не учусь, т.к. читать текст намного пизже. Просто иногда когда реализую какую-нибудь механику, делаю себе выборку роликов, чтобы посмотреть, как другие такие же штуки делают.
>Вывод: Вы просто ненавидите всё русское.
Не угадал. Я даже игры делаю сразу, как минимум двуязычными, на русском и инглише.
>Ну ладно.
Ок.
К слову об:
>>692406
>делаю сразу, как минимум двуязычными
Очень нраицца как в годоте сделана реализация локализации в играх (ну по крайней мере по сравнению с тем, с чем я раньше сталкивался). Достаточно удобно, плюс добавить дополнительный язык можно на раз-два.
ЮКак сделать рутом сцены собранную из разных нод кастом ноду?
Например так - создать скрипт в котором написать class_name CustNode
Это даст возможность добавлять CustNode как ноду, в том числе и как корневую в новой сцене.
>Данная кастом-нода не хочет обращаться к своим чайлдам.
В смысле ты не хочешь, или у тебя не получается?
Ещё раз перечитал доки и - нет. ЦСВ гораздо удобнее (мне). Столько возни с этим геттекстом, ради удобства многострочных сообщений я не готов с этим возиться. Я его прямо в годоте открываю как текстовый файл и там редактирую. Даже ексели не нужны. После сохранения надо обновить редактор, чтобы перегенерировались файлы переводов. Я без задней мысли запускаю игру и выключаю, после чего редактор обновляется.
>Емнип вся эта ебля окупается если у тебя тексты вида "Александру" принесли "четвертую" кружку -> "Fourth" cup was brought to "Alexander" и т.д. с подстановками, падежами, склонениями.
Честно говоря не вижу смысла с такой хренью заморачиваться. Проще сразу текст строить так, чтобы исключить или хотя бы минимизировать всякие согласования падежей и прочую лингвистическую хрень. Даже в большинствее ААА игр подобным не заморачиваются.
>Проще сразу текст строить так, чтобы исключить или хотя бы минимизировать всякие согласования падежей и прочую лингвистическую хрень.
Ага, напиши текст заранее так, чтобы при переводе на язык, которого ты не знаешь, не возникло лингвистических проблем. Великолепное решение!
>Даже в большинствее ААА игр подобным не заморачиваются.
В большинстве ААА игр не заморачиваются со мнооогими вещами, с которыми заморачиваются в инди. Вообще, крупные компании оптимизированы так, чтобы не прорабатывать детали, которые не дадут финансовой выгоды больше, чем стоит их проработка. С другой стороны, когда игрок включает индюшатину, он ожидает большей внимательности к деталям, как ни странно.
Пять секунд гугла https://github.com/godotengine/godot/pull/39093 Это не документация, конечно, но для ознакомления достаточно. Внутри статьи есть ещё ссылки.
Да не, это я видел.
Ещё в виде новости на сайте https://godotengine.org/article/gdscript-progress-report-new-gdscript-now-merged
Но всё равно спасибо. Я именно доки с какими нибудь основами реквестировал, думал мало ли есть.
Самые легендарные игоры не имели крутого графона.
Нахуй мне игра с вычислительными шейдерами (дождь/снег отскакивающий/прилипающий от/к динамических/им поверхностей/тям, угадал?), если в ней ни геймплея интересного, ни на худой конец сюжета глубокомысленного, цепляющего? Ну вот зачем, а?
Есть и не одна, но на мобилах. Просто у движка нет требования к неотключаемому сплешскрину и авторы банально не указывают, какой у них движок. Возьми 10 коммерчески успешных три-в-ряд китайских дрочилен-рекламу-показывателен, и 8 из них будут на годоте, причем на двушке.
Причём тут это? Претензия не к движку, а к китайцам, которые клепают однотипную хуиту на мобилки. Хотя по сути претензия даже не к китайцам, а к миллионам хомячков, которые в это играют, смотрят рекламу, переходят по ссылкам и тем самым делают эту хуиту коммерчески успешной.
>что можно сделать на годот?
Наверное можно, но это будет очень неудобно. Вообще не, в годоте не стоит с вижуалскриптом связываться, он там сбоку приделан, лучше открой документацию и step by step пройди обучение кодингу.
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
> можно ли создать 3д игру хотя бы на уровне ходячего симулятора, используя только визуально программирование
В прошлых тредах я проводил опыты и показывал сравнительные скриншоты, как три строчки простого и удобного GDScript превращаются в громадную лапшу нодов на четыре экрана.
Вот тебе еще немного пищи для размышлений. На прилагаемых пикчах код и блюпринт, которые делают то же самое. Отбросим пока что тот факт, что ноды тупо больше и подумаем вот над чем. Я всё равно изучал АПИ движка. Без этого никуда. Не зная АПИ, я бы не смог создать этот блюпринт. Я бы просто не знал, какие блоки брать и с чем их соединять.
А АПИ движка тесно связан с гдскриптом, все примеры АПИ изначально показаны на нём, а уж потом на других языках и блупринтах. Так что, чем дольше ты оттягиваешь момент с изучением языка, тем дольше не будет игор.
Обучение это балансирование между сложными и демотивирующими вещам и интересными и брутфорсными, если я сразу же начну с изучения языка то потеряю любую мотивацию на создание игор.
Но что ты написал натолкнуло меня на мысль, о том что ты делаешь неправильно лучше знать заранее и не привыкать этому способу, потому что потом будет труднее переучиваться. Спасибо, буду смотреть теперь инфу по этим АПИ штукам.
В общем вот
https://twitter.com/ZeroPointGame
Основа бродилки делается за 5 минут, за тридцать простых шага
Первый - создать проект из темплейта third person (потом контроллер игрока можно будет заменить/доработать)
2. установить ассет террейна, включить его в настройках, добавить ноду террейна, указать в ней папку куда будут писаться данные.
3. Удалить пол, сгенерировать рандомный террейн, добавить текстурку травы. Ваша пицца готова. Дальше уже пилить всякие взаимодействия с объектами.
А то там "breaks forward compatibility," для "C# projects" обещают. И чет, сцыкотно мне.
Просто делай бекапы проекта (или храни версии в git)
Судя по описанию просто когда ты создашь C# проект в 3.2.3, его будет нельзя открыть в 3.2.2
Вообще, раз поменяется только csproj, с исходниками и API же ничего не случится, в самом худшем случае просто передобавишь все .cs
>Просто делай бекапы проекта (или храни версии в git)
Уже очень давно под версиями все :) Только под ртутью.
>Судя по описанию просто когда ты создашь C# проект в 3.2.3, его будет нельзя открыть в 3.2.2
Это то, понятно.
>Вообще, раз поменяется только csproj, с исходниками и API же ничего не случится, в самом худшем случае просто передобавишь все .cs
За исходники я не опасаюсь. Судя по описанию коммита там в файле проекта еще флаги есть которые будут разными для импортированных проектов и для новых и вот насчет них я не совсем разобрался. И самое главное я не понял, что в старой системе такого было плохого, что им понадобилось делать это изменение. Ссыкотно мне больше за то, как бы они в самом годоте не поломали C#, так что пришлось бы следующей версии ждать.
Вобщем, лучше я подожду полного релиза и отзывов.
> не понял, что в старой системе такого было плохого, что им понадобилось делать это изменение.
Судя по закрытым багам, каждое добавление пакетов библиотек превращалось в боль, требующего каких то плясок для исправления. Чел писал в комментах, что в новом rc C# не сломался, и он даже использовал кейворды из C# 8.0