Шапка: https://hipolink.me/godothread
Предыдущий: >>895906 (OP)
Архивный: >>890164 (OP)
>>901899
От себя - полторы. Микро-игру на 4 кнопки, но законченную. Сейчас жду одобрения в гугл плее и работаю над второй, побольше, в 3д.
> Докладывайте, кто сколько игор сделал?
Я недавно узнал о программе MagicaVoxel и сейчас пилю ассеты воксельные для своей игры мечты. А так же там есть прямой импорт прямо в двиг.
Хороший выбор, простой. А я в блокбенче хуярю. Тоже изи плюс в анимацию умеет.
На реддите мелькали статы по гугл-поиску и популярности сабреддита.
Не, блокбенч какой-то сложный. Вот бывает же такое, когда скачиваешь прогу, запускаешь и всё сразу ясно без туториалов.
Круто мотивируют видосы челов, которые делают игры под game jam'ы. Подумываю самим попробовать как освоюсь, только вот немного удручает что надо самому учиться ассеты пилить
Так и думал. Но все равно игра в таком случае кажется "не своей". Да и фантазия ограничивается доступными ассетами. Надо будет курсы по бленедеру пройти
> курсы по бленедеру
Годное решение. Одно из лучших в твоей жизни. Не откладывай. Вот тебе для затравки.
Пройди официальные гайды, your first 2d game, your first 3d game, валяются в официальной документации. Дальше делаешь свои проекты по документации и, опционально, подглядывая за гайдами на ютубе.
Сделай какую нибудь простую игру. Платформер 2д или run-n-gun или топдаун шутер что то такое. Чтобы попробовать все аспекты, от загрузки ресурсов, уровней, анимаций, физики прыжков, гуя, настроек, звуков. Поведения врагов, спавны, логику хитов, рестарта, смерти, базовую камеру, взаимодействие с предметами типа дверей. Потом можешь прикрутить фичи типа смены оружия, апгрейдов, визуальных спецэффектов, освещения, поиска пути, диалогов, катсцен, инвентарь и тд
Кстати, для вокселей есть ещё вспомогательная утилита SLAB6. Узнал о ней из видосов чела, который дум в воксель перенёс: https://www.youtube.com/watch?v=RJ7MH2FqUIg
Успел 0, сломался компьютер и перестал работать блендер. Придется вернуться к 2д проектам или тупо делать на чужих лоуполи ассетах
Можно в самом годоте делать. Надо просто написать простенький редактор для csgpolygon который будет uv текстуру натягивать.
>csgpolygon
Они же только для разработки предназначены, как плейсхолдеры, не? В том смысле, что роняют производительность.
А ты потести. Ну и есть аддоны/скрипты для конвертирования в obj
Мое почтение.
>>902161
А у этого собака домашку съела. Не сдавайся, делай, и помни что со временем приходит опыт, а с опытом все получится. Где бы время еще взять, бля.
Мне этот опыт уже девать некуда блджад курсы что ли запустить уже.
Да, но звуковой плеер очень пердежно импортирует огг. Нормальный звук эффекты можно только встроенным синтом сделать. Мне поэтому не подошел.
Я сейчас по этому гайду занимаюсь
https://www.youtube.com/watch?v=nAh_Kx5Zh5Q
Блять, 11 часов, охуеть! Яндекс-переводчик отказывается озвучивать.
Английский - самый полезный скилл для любого айтишника. А технический английский еще и простой. Даже индусы в него могут.
Теперь ты знаешь какой скилл тебе прокачивать.
>Английский
Из твоих уст доносятся мерзкие слова
Ес айм гет вот эбаут ю спокен, бат лец американс го фак ёселф виз.ем тонг. Андестенд?
китайский кривой и тоновый, а хинди хоть на человеческий похож
Причём тут санскрит, если в индии хинди + множество местных + англ.
Если тебе нужны подробные отзывы, то ты находишься сейчас на этом ресурсе. Неиронично.
Пока ты свою игру доведешь до релизного состояния уже годот 6 выйдет.
Увидимся снова когда ваш Джон решит выплатить положенное инвесторам. То есть скоро и неизбежно. Заходи.
К сожалению, аудитория годота пока не на столько велика, чтобы было много качественных материалов на русском. Там в принципе язык не сложный, в крайнем случае - можно тупо за автором повторять
Чё как лох-то? Скачай, раздели на половинки, а потом залей на ютаб и яндек переведёт.
Бля, братишка, это был лучший сон в моей жизни. Я всю ночь периодически просыпался и слушал его бубнёж, а потом опять засыпал и мне снились великолепные сны!
> почему сисярп в годоте настолько лучше?
Потому что объекты создаются по паттернам, по классике, через инстансы, а не как богомерзкий монобех, через геткомпонент<T>
> Я до сих пор искренне не понимаю как сделать игру
> Ну пиздец, не понятно ничего.
> как сделать жесткий вкат
Бля, анон.
Всё, что тебе нужно уяснить это шесть вещей:
1. Start это _Ready
2. Update/FixedUpdate это _Process/_PhysicsProcess
3. Иерархия сцены состоит не из объектов Monobekh, а из объектов Node.
4. Объекты Node обладают несколькими уровнями наследования.
5. При создании игры ты опираешься на иерархию нод, а не на компоненты.
6. При желании, ты можешь самостоятельно реализовать компонентную систему, но в большинстве случаев она соснёт у иерархической системы.
Если остались вопросы, задавай. Я в равной степени знаком с обоими движками.
Просто и без задней мысли берешь и делаешь. На десятый раз разберешься. Я только к третьей релизнутой игры получил ощущение хоть какого-то понимания, и научился ходить своими ногами, без туториалов/документации.
Спасибо, но больше был вопрос "глобального вката". Курсы, документация, видео на ютубе, где точка старта, как понимать?
Впрочем лень, что то писать, за меня всё сказал Хуан: https://docs.godotengine.org/en/3.1/getting_started/editor/unity_to_godot.html
Вот ещё это послушай https://www.youtube.com/watch?v=2efd_2SV1Z8
Но, если за неделю с начала юнитипиздеца ты не вкотился, то годот не твоё. Просто иди дальше, не еби мозги ни себе, ни нам.
Сижу в оджидании 4.2, но выпустят ли его, надеюсь в этом году сделают.
>6.
Тащемта ноды прекрасно выполняют роль компонентов.
>>902737
Лично я вкатывался с видосов HeartBeast'a, его приятнее всех слушать. Но только для ознакомления с движком и общими принципами работы. Никогда никакие туторы не перепечатывал. Ну и переучиваться со всяких юнитей тогда тоже не приходилось, с нуля заходил, так что не знаю, насколько тебе такое подойдёт.
>>6. При желании, ты можешь самостоятельно реализовать >>компонентную систему, но в большинстве случаев она соснёт у >>иерархической системы
Не совсем понял почему? Разве не удобно иметь независимые объекты с возможностью создавать префабы, чем зависимые ноды, изменение/использование которых тянет другие связи?
> ноды прекрасно выполняют роль компонентов
Мы говорим о перекате. Челику нужно видеть перед глазами что-то знакомое, что он автоматически понимает. Поэтому, массив типа Array[Reference] ему на первых порах будет привычнее, чем искаробочный массив Array[Node] который мы получаем по get_children().
>>902866
> Не совсем понял почему?
Потому что там другая архитектура. И мы в данном случае (как я надеюсь) говорим о перекате готовых наработок вкатунов, при этом правки архитектуры должны быть минимальны. Если у вкатуна куча самописных скриптов, наследующихся от монобеха, то в годоте ему проще всего сделать абстрактный класс MonoBehaviourProxy extends Reference, а затем переписать все свои невизуальные компоненты под этот абстрактный класс. Затем в нодах, где нужно, он создаёт @export var components : Array[MonoBehaviourProxy] и спокойно, привычным для себя образом закидывает "компоненты" в ноду через инспектор редактора.
Но как я выше написал:
>>902734
> в большинстве случаев она соснёт у иерархической системы
Но ваще вместо вышеописанного велосипеда, если есть потребность организовать "компоненты", лучше делать их на "белых" нодах, которые по сути пустые и содержат только минимальный функционал: добавление в дерево и обработка колбэков.
Таким образом, наш сферический юнитиперекатун добавляет своему объекту несколько нод, называет их ,как ему надо, а им пишет скрипты, которые при своём старте получают ссылку на хост-ноду, как показано на втором скрине, которая устанавливается через инспектор, как показано на третьем скрине.
Мать полячка, отец латыш. Родился в Киеве, живу в Саратове. Кто я?
Хватит срать, давайте лучше обсудим, подходит ли нода CharacterBody3D (бывшая KinematicBody) для реальной разработки игор с физикой? Потому что я тут подумал, в случаях, когда мне надо будет забрать у перса управление и включить ему рэгдол (например, после взрыва и т.п.), то с этой нодой мне придётся велосипедить движение.
Не проще ли делать персонажа на RigidBody3D в режиме Freeze.Kinematic?
Не знаю. Попробуй оба варианта и расскажи плюсы и минусы в треде.
Щас буду делать, но поскольку я нуб в физон-матане, буду юзать туториалы. Вот нашёл неплохой. Чувак с умным видом хуячит хелпер-классы с вычислением интегральной ошибки (какой-то). Похоже, это то, что нужно.
https://youtu.be/zTp7bWnlicY
Я на тройке делал так. Кинематик - это сам персонаж. А внутри него части тела ригиды и джойнты между ними. Пока перс живой, физика кинематика включена, физика ригидов выключена; умер - кинематик и анимацию выключаем, ригиды включаем.
А вот что мне интересно - это PhysicalBone2D/3D в четвёрке (ну, в основном 2д). Судя по названию и описанию они больше подходят для рэгдоллов; но какие именно плюшки они дают и как именно ими правильно пользоваться, чёт я не вкурил.
>Хорошо. Начну делать игру после 450-го поста.
>Разбудите меня, когда будет пора делать игру.
Вы меня так и не разбудили... >>901899
>Докладывайте, кто сколько игор сделал?
Я думаю захотеть попробовать начать делать прототип чего-то вроде https://ru.wikipedia.org/wiki/Виртуальный_питомец Ибо мучаюсь от одиночества и экзистенциального кризиса...
>включить ему рэгдол
Просто делаешь отдельную физическую куклу и включаешь её, когда она нужна. Так почти все игры делают. Реально физическая кукла в обычных движениях применяется только в GTA IV благодаря Euphoria, которая давала возможность симулировать мышцы людей на достаточно точном рэгдолле так, что он буквально ходит как человек, а не как анимированная 3D сетка. Но это уже натуральный rocket science, эйфория была очень сложной и её компания разработчик вроде как разорилась, а Rockstar забросили и даунгрейднули персонажей в RAGE 2 (GTA 5). Были ещё какие-то игры с эйфорией, но так и не дожили до релиза. Сурово, в общем, в одиночку такое не осилить.
>Не проще ли делать персонажа на RigidBody3D в режиме Freeze.Kinematic?
Сложнее. У ригидов нет удобных проверок столкновения, придётся велосипедить свои. Кроме того, стандартный кинематик останавливается в миллиметрах от любого препятствия, а ригидбоди в режиме кинематика будет переть на таран, пока ты сам проверками не обмажешься. А если делать движение в стандартном режиме ригидбоди (через приложение физических сил), тогда твой персонаж будет плавно разгоняться и плавно замедляться - каким-то играм это выгодно (в той же GTA 4/5 персонажи делают всё с задержкой, а не резко бегут в любом направлении как раньше), но далеко не всем. Плюс эти силы действуют как ракетный двигатель, создавая парадоксы вроде опрокидывания грузовика бегом внутри его кузова (если бежать в борт кузова, ты как будто отталкиваешься от воздуха, а не от пола кузова), как это фиксить - я так и не понял, какие-то особые проверки коллизий нужны.
> Я на тройке делал так. Кинематик - это сам персонаж. А внутри него части тела ригиды и джойнты между ними.
Мне нужно бегать по шару (планете), синхронизируя вектор гравитации с центром шара. Может быть я впал в проблему икс-игрек? Может мне на кинематике будет проще сделать? Потому что я подумал "такс, в движке есть Area у которых можно сделать точечную гравитацию к центру. Я делаю планету, накидываю на неё сферическую область гравитации - и вуаля, персонаж автоматически синхронизирован со сферическим гравитационным полем".
А тут посидел джва часа в редакторе, параллельно смотря туториалы, и нихуя подобного. Чуваки лепят управление на плоскости. Поэтому мне от этого ригид-боди пользы ноль. Единственная польза - другие тела смогут воздействовать на тело игрока, отталкивать. Но это у меня не главная задача. Бля, кинематика сложная, сука.
Господа, я уже давно все собираюсь и собираюсь вкатиться в геймдев через юнити, но из-за собственного ебланства, дальше сделанным по видеогайдам катающихся по плоскости шаров не ушел, но это давно было, пару лет назад. Сейчас появились силы ебашить и снова попытаться вкатиться, но тут юнити поменял политику монетизации и из каждого утюга начали трубить, что все, нужно уходить.
Помимо юнити мне приглянулся годот, могут, ли те кто трогал то и то описать преимущества и недостатки обеих движков?
Есть ли большая разница в сложности вкатывания? Английским владею.
Насколько удобно и просто делать 2d игры? Простенькие стилизованные 3d?
Насколько тяжело в случае чего перекатиться из одного движка в другой?
Какие перспективы у обоих движков если я буду делать карьеру в геймдеве в качестве геймдизайнера?
> Насколько удобно и просто делать 2d игры?
7/10
> Простенькие стилизованные 3d?
7/10
> Насколько тяжело в случае чего перекатиться из одного движка в другой?
Если ты используешь паттерн MVP - просто. С паттерном MVP ты можешь хуярить одну игру на нескольких движках сразу.
> если я буду делать карьеру
Если ты такие вопросы не гуглишь сам, а спрашиваешь на форумах - никакой карьеры тебе не светит. Без обид, анон, но таким не перезванивают.
>Мне нужно бегать по шару (планете), синхронизируя вектор гравитации с центром шара.
А, тогда делай на ригидбоди, лол. Тебе в любом случае придётся вращать персонажа ногами в сторону центра планеты, а стандартный кинематик на такое не рассчитан - он для плоского мира.
>в движке есть Area у которых можно сделать точечную гравитацию к центру
Если они этот баг не пофиксили, то учитывай, что Area с гравитацией будет всасывать в себя объекты даже если они уже вылетели из её "области действия". Так что для симулятора "прыжка с луны" придётся велосипедить свою гравитацию, впрочем, это несложно (достаточно прикладывать силу гравитации ко всем ригидбоди, находящимся в зоне действия Area).
Алсо учитывай, что физический движок начинает дико колбасить на коллиженшейпах размером больше 250-500 метров (точно не помню, это старый баг), поэтому тебе скорее всего придётся резать планету на куски, если у тебя не малюсенький камень диаметром в жилой квартал. Скорее всего виноват float в вычислениях движка.
>Поэтому мне от этого ригид-боди пользы ноль.
Наоборот, такого персонажа проще всего на ригидбоди сделать, т.к. ему плевать, куда лететь.
Удачная тема для детей и домохозяек. Те же бородатые тамагочи.
>мучаюсь от одиночества
тнуса заведи
Для карьеры мне сначала нужно, хоть что-то сделать. А вопрос выбора движка слишком важен, помимо гугления хочется спросить самостоятельно на живом форуме.
>преимущества и недостатки обеих движков?
Смотри Ютуб, читай форумы. Всё уже обсудили тысячу раз. Но Godot ты можешь сам быстро пощупать, он весит около 50 МБ в архиве и не требует установки, запускается за секунду на слабом ПК и для старта изучения не требует ничего дополнительного скачивать (если использовать стандартную сборку без C#).
>большая разница в сложности вкатывания?
Я считаю, Godot сильно проще для вката.
>Насколько удобно и просто делать 2d игры?
Очень удобно, легко и просто. Godot имеет отдельные субдвижки под 2D с оптимальным API, в отличие от костылей Unity (там "2D" на самом деле в 3D).
>Простенькие стилизованные 3d?
Очень просто, если у тебя маленький мирок без процедурного ландшафта и с маленьким числом объектов (несколько сотен прыгающих мячиков). Для чего-то большого и сложного нужно либо искать сторонние дополнения к движку (аддоны или модули), либо делать свои велосипеды.
>Насколько тяжело в случае чего перекатиться из одного движка в другой?
Несложно, они достаточно похожи по концепциям. Все основные отличия в современном геймдеве абстрагированы от пользователя под капотом.
>Какие перспективы у обоих движков если я буду делать карьеру в геймдеве в качестве геймдизайнера?
Unity имеет очень высокую популярность, но последние пару лет из-за руководства теряет былое доверие. Godot только недавно заметили и крупные студии его только "щупают", но недавно обратили больше внимания. В вакансиях давно как-то я видел что знание Godot будет плюсом даже если берут на другой движок; но конкретно геймдизайнеру, наверное, движок вообще не важен, потому что от геймдизайнера требуется написать чёткий дизайн-документ и потом следить за работой остальной команды, внося правки в документ по ходу работы. Короче, геймдизайнер больше с бумагами работает, чем с игровыми движками, его цель - формализовать конкретную задачу (которая принесёт профиты) для гребцов на галере. Но я могу ошибаться, я никогда нигде не работал.
>Удачная тема для детей и домохозяек.
Мне не для маркета, а для себя, "для души". Маркет подобным переполнен, а после LLM/GPT подобные игрушки скорее всего для многих теряют смысл.
>Те же бородатые тамагочи.
Ага, в разные подобные игры играл. Но всё не то. Хочется чего-то реально своего, чисто под себя...
>тнуса заведи
Не хочу. Хочу собственную DIY роботян.
> тнуса заведи
А где их выдают? Я всё пропустил и теперь они не заводятся.
>А где их выдают?
На дваче есть спецразделы.
>теперь они не заводятся
Аккумулятор замени, дурень, посадил же.
Я своей тян два аккумуляторных блока сделаю, чтобы можно было горячую замену делать...
Кстати, что там с Godot в автомобиле? Живой ещё?
>>903002
>Совсем?
Пробовал фрилансить, но забросил.
>Кстати, что там с Godot в автомобиле? Живой ещё?
Читал что тесла на нем ГУЙ себе сделала.
> вопрос выбора движка слишком важен
Заблуждаешься.
Алгоритмы везде одинаковы:
1. Есть главный цикл приложения. Он есть везде. В оконных приложениях главный цикл обрабатывает сообщения оконной подсистемы ОС. В графических главный цикл обрабатывает фреймы.
2. Ресурсы есть везде. Это общекомпьютерная база, не зависящая от движка. Како движок ты не выберешь - модели будут лежать на диске и тебе их нужно грузить в память.
3. Языки программирования все одинаковы, все начинаются с объявления переменных, продолжаются ветвлениями и циклами, заканчиваются выводом результатов.
4. Учитывая всё вышесказанное, ты можешь легко учить движки как иностранные языки. Самое трудное - выучить первый, а остальные учатся уже легче.
Двачую этого. Люди на голом опенжл хуячат шедевры, а не вот это вот все, то тут не так, то там не так, то вот тут фича сыровата, то хуй сопливится, то в анус дует.
Просто и без задней мысли берете и делаете игры. Снова и снова и снова. Хватит отмазы лепить.
>Языки программирования все одинаковы
Императивные - да, в основном. Другие парадигмы освоить сложнее, даже с опытом императивных. Но больше всего используются императивные ЯП.
>>903081
>Люди на голом опенжл хуячат шедевры
А на юнити ассетфлиперы в основном. Они не велосипеды изобретать хотят, а лёгкие бабки стричь.
> Другие парадигмы
Ветвления и циклы спрятаны за обёрткой маппинга списков. Как только ты это осознаёшь, все эти лиспы становятся всё той же парадигмой.
>маппинга списков
Ты не понял.
Как приготовить яичницу:
1. Найти яйцо.
2. Разбить яйцо в сковороду.
3. Разогреть сковороду.
4. Ждать приготовления.
Как_приготовить_яичницу();
Известно, что:
1. Яичница - это жаренное содержимое яйца.
2. Яйцо может быть разбито.
3. Из разбитого яйца вытекает содержимое.
4. В скороду можно поместить ингредиенты.
5. Содержимое яйца - ингредиент.
6. Огонь плиты нагревает посуду.
7. Сковорода - это посуда для плиты.
8. Горячая сковорода жарит ингредиенты.
9. Содержимое яйца жарится за 5 минут.
Требуется: 1 яичница.
Позволено. Я доки правил. Полистай тут, чтобы в лужу не сесть:
https://github.com/godotengine/godot/blob/master/CONTRIBUTING.md
https://docs.godotengine.org/en/stable/contributing/ways_to_contribute.html
https://docs.godotengine.org/en/stable/contributing/development/best_practices_for_engine_contributors.html
Я контрибутил. Ну тут как. Если ты исправляешь очевидную мелочь то это легко. Если твое исправление неоднозначно, имеет влияние на архитектуру движка, или потом требует поддержки, то скорее всего выльется в обсуждение. Тут уж сначала имеет смысл пообщаться в дискорде или гитхабе и узнать нужно ли такое и реально ли пропихнуть. Запилить прототип, показать с пруфами и бенчмарками что это нужно. Так делали clayjohn и lawnjely. Если что то узко специальное, то скорее всего без шансов, философия такая чтобы движок не раздувать и все такое выносить в аддоны. В них кстати тоже можно контрибьютить, или пилить свои.
Мой кодер ебашит вообще адовые пулл-реквесты. Ну такой вот примерно рецепт усредненный, потому что вариаций масса. Берется код, он не читается, читать — это не про моего кодера. Он берет этот код, коммитит его в наш репозиторий и начинает оформлять пулл-реквест. Добавляет в него огромное количество описаний, ссылок, маркдауна и тегов HTML для вязкости, красивый заголовок сверху. Все это пулл-реквестится до комментариев. Потом требуемые правки обсуждаются в комментариях. Потом кодер заходит ко мне и щедро полив комментаторов матом начинает ругаться. При этом ругается с клавиатурой под мышкой, шкрябая по ней ногтями. Ругается и приговаривает полушепотом ух бля. При этом у него на лбу аж пот выступает. Любезно мне иногда предлагает самому лично комментарии к его пулл-реквесту глянуть, но я отказываюсь. Надо ли говорить о том какой дичайший пердеж потом? Вонища такая, что баги в легаси коде сами фиксятся.
Што ты несёшь?
>подрубать по IP
Не нужно, он сам работает (F5 - запуск проекта).
>который тебе даже сцену не выдаст
Так вот же:
https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#remote-in-scene-dock
>список нод
Ну, а что ты хочешь? Жми на хлопушку.
>>903268
>привык к удобству и пиздатости Юнити
Я пробовал делать прототипы в Юнити разных версий, она всегда была кривой и глючной, а C# вообще порождение корпорации зла. Не понимаю, кто может находить её удобной (кроме утят).
Тебе в Blender удобно работать? Скажи честно.
Ееее бои, 3.5.3.
Ачевсмысле, разве там не просто экспортишь под веб и заливаешь как html?
Там по правилам обязан сдк интегрировать вроде. Да и лучше я это сделаю, там можно хранить инфу о микропокупках и прокачке на сервере яндекса, можно ник игрока подтягивать.
Неплохо. Я видел что на ньюграундс веб-игры умеют в ачивки и интеграцию с сайтом, но сам заморачиваться не стал. Видимо там оно через аналогичную интеграцию делается
Начал новый проект, чтобы перелезть наконец уже с тройки на четвёрку. Такие дела.
А я еще подожду, пока допиливаю текущий проект. Посижу с тянучькой на лавочке, так сказать.
В тройке кстати шрифты настраивались. В четверке тоже должны.
Молодец, продолжай работать в этом направлении. Я вот пока нихуя не заработал.
База на самом деле. Рассказывай стратегию поднятия трехзначных сумм.
Я открыл самый простой туториал и просто добавил своего, просто то, что в голову приходило и мог сделать вообще без знаний и опыта. Старался понять каждую строчку кода, если была хоть одна строчка, где я чётко не могу понять, что она делает, то либо переписывал по-своему, либо переделывал вообще механику. Ещё сразу использовал новые элементы, про которые узнал из тутора. Например узнал, про горизонтальные контейнеры и сразу придумал, как их использовать. Дальше нарисовал всратый спрайт в аналоге асеспрайта за полчаса, из ассет-пака бесплатного взял проджектайлы, фон тоже взял бесплатный. Все слепил вместе, получилась игра. Очень невнятная, всратая, хуевая, маленькая и слабенькая. Потом залил и прошел модерацию, получил 100 рублей.
Не дают ссылку на код.
Не показывают код в видосе целиком.
Помидоpки.
Это чтобы делать игори даже сидя на толчке?
Дети так и делают. На реддите уже пару раз видел как школьники на телефонах делают игори. Не то что вы, ноудевы.
Это же в первую очередь не для мобилок, а для каких то планшетов или недонетбуков, без клавы там все равно делать нечего.
>Не показывают код в видосе целиком.
Посмотрел видео, там показали весь основной код - достаточно, чтобы повторить проект своими руками.
>Не дают ссылку на код.
Бездумной копипастой ты ничему не научишься.
Мне нужно проспаться или они перестали шестерку поддерживать?
Я сонный, нужно подкорректировать версии пакетов всяких было
https://docs.godotengine.org/en/4.1/tutorials/export/exporting_for_android.html
Это троллинг издевательски коротким ответом?
1. Опиши, что конкретно сделать хочешь.
2. Рассказывай, что там у тебя не получается.
Если ты просто жалуешься "ой, у меня не получилось, готовый код не работает, вы все бяки, фу на вас" - это выглядит как троллинг, таких тут не любят.
В видео 3.3.1, вышла в мае 2021, это очень давно.
>>899133 →
Вчера возился с 3д и вспомнил твой пост
Одна из причин - плохо работает импорт fbx.
Надо сначала загнать их блендером в gltf или glb
Одни и те же анимации у меня не работали из fbx и заработали из glb
Мой прошлый пост
>>876327 →
Вот скрипт https://github.com/baracil/Mixamo2Godot
При необходимости закомментируй вызов функции scale_animation() некоторым моделям со скетчфаба она мешает
Запускается командой blender --background --python mixamo2godot.py--/path/to/directory/of/animations
Этот скрипт добавляет root motion, но имхо для миксамо это имеет смысл
>плохо работает импорт fbx
Ваще надо выпилить, вражеский закрытый стандарт, наследие древних монструозных 3D пакетов от тупых и жадных до денег автостолов. Либо blend, либо gltf.
>>903621
кстати аноны, а есть фикс того, что экспорт шейп кейсов не переносится в годот? Юзаю 4 версию, пробовал разные варианты от blend до gltf и fbx, нихуя не работает и не переносятся шейп кейсы у анимации, это пиздец. Какого хуя?
Запекание не катит - нужны реалтаймовые тени. Нужно что-то типа "вот в этом квадрате свети, а в этом не свети". Комнаты/порталы - они для этого?
Не уверен о чем ты, бленд шейпы переносятся. Они не в анимациях, а в пропертях меша (под скином, скелетои), позже ты можешь их анимировать сам.
дык а какого хуя они не переносятся в анимациях то? обезьяна пахом там совсем ебанулся что ли, это же основа основ анимации. аниматор делает контент в н-проге и переносит это, в а тут блядь в движке надо допиливать, это же пиздец
У света есть "слои" (cull mask)
Соответственно помещаешь такой свет на слой 1 и он светит только на объекты слоя 1, и не светит на 0. Террейн придется нарезать как то, аозможно двигать кусок вместе с камерой, как трава рендерится.
А почему они должны быть в анимациях, когда в блендере это данные групп вершин?
А вообще ответ такой - потому что годот это не блендер и не аддон к блендеру.
Спасибо. Вариант геморройный, оставлю его на крайний случай. Сейчас пытаюсь заменить directional на spot и двигать вместе с камерой. Почти то, что нужно, но под необходимым мне углом у него ебучая теневая сыпь лезет, как на пике слева.
Играюсь с настройками пока.
>вот в этом квадрате свети, а в этом не свети
>>903640
>Сейчас пытаюсь заменить directional на spot и двигать вместе с камерой
Что КОНКРЕТНО ты хочешь сделать?
Тебе нужна маленькая локация снаружи, тогда как всё остальное время игрок в помещениях? Просто выключи "солнце", когда игрок заходит в помещение без окон. А если тебе для мобилок, наверняка лучше будет нарезать твою большую карту на куски и сделать загрузочные экраны.
А, погоди...
>для мобильной игры
>нужны реалтаймовые тени
Вообще бред. Я даже на ПК тени в играх отключаю, а на телефоне тени - просто издевательство.
Падажжи, там есть настройка shadow max range, может ее хватит.
>настройка shadow max range
Хотел сперва посоветовать, но это не то. Источник света, изображающий солнце, не находится в какой-либо точке пространства - он считается бесконечно далёким от налюдателя, поэтому у него параллельные лучи света. Поэтому эта настройка только сужает область вокруг наблюдателя (камеры), на которую накладываются тени. Если посмотреть вдаль, дальше этой величины теней никогда не будет. А от пишет, что ему нужны тени в отдельном "квартале".
Так по идее в топ дауне это и поможет. А если нет, то чанки пилить не так уж сложно. Так то слой объекту на лету менять можно, вечером потестю. Может даже банально enter/exit area обработчика хватит (инб4 нет, это не оптимально, а что если там 3440 объекта)
Вообще меня давно интересует вопрос как работает атлас directional shadow
Допустим у меня куб кидает тень на плошадку метр на метр. Теперь я добавляю объект в 1000км. Качество тени в эиот момент резко упадет? Ведь атлас старого разрешения теперь натянут на мир в разы больший. И я что то не припомню методов контролировать размер этого "затененного " участка, это черный ящик с автоопределением
Скажу честно, за несколько лет и с большим опытом геймдева я подобрать не смог. Так что пока от смены дня ночи отказался. Возможно, надо просто сесть и подобрать массивчик значений на определенный набор углов, скажем с шагом 15 градусов. И это на группы объектов разного вида - и с учетом куда падает тень, на пол или стену, а также вдоль или поперек камеры. Но вот универсального значения похоже не подобрать
Сделал я "префаб" объекта, сохранил в ресурсы. Теперь когда я ставлю его на сцену, он появляеться там закрытой нодой. В юнити было очень удобно оверрайдить проперти у префаба, в данном случае я например хочу поставить уникальный звук каждому обьекту. Как такое вообще делаеться в годоте? Прицеплять к верхней ноде скрипт, который прокидывает оверрайды с моей колокольни какое-то извращение.
Есть несколько вариантов
1. Создать Inherited сцену. Не пользуюсь, может аноны пояснят.
2. Можно сделать объект Local to scene, заинстансить его по полной. Это уже будет не префаб
3. Можно сделать его Editable children. Тогда он будет префабом, но конкретику в нем можно перекрыть.
4. Я пользуюсь более программистским способом
В скрипте делаю export настроечных переменных
Сам скрипт tool, то есть работает в редакторе.
Например я могу сделать настройку цвета юнита или выбор спрайта прямо в инспекторе. Есть какие то подводные, не помню какие, мб со вложенными сценами
Ну тут загвоздка в том, что анимации Mixamo раздаются только в Fbx. Уж не знаю зачем это адобе.
Адобе забили на миксамо с момента покупки проекта. Все эти годы он ни жив. ни мертв. А жаль. Многообещающая штука была.
Ждут, потом просто лицензию ретроактивно поменяют чтобы 2 цента за каждое проигрывание анимации брать
Помню пару тредов назад анон спрашивал как вращать билборды в их плоскости. Ну вот кто то шейдер запилил.
https://godotshaders.com/shader/local-space-y-billboard-shader/
И еще вот такой (не очень понял, вроде как его можно положить на любой угол)
>>903640
>>903630
В общем, решил свое освещение с помощью spotlight с reverse cull face и включенными тенями, эмбиент освещением через world properties и запеченными то тут то там омнилайтами без теней. Выглядит ок, тени динамичат, свет следует за персонажем без освещения всей огромной сцены, фпс упало с 1500 до 1200 на пеке.
Удивительно на что способна трешка и GLES2. Интересно даже чего там в четвертой годоти с вулканом можно накрутить.
>анимации Mixamo раздаются только в Fbx
Конвертируй. Blender вроде поддерживает fbx.
А вообще, мне лично не нравится идея брать анимации с какого-то сайта, тем более бесплатные. Это лишает игру уникальности, тем более если эти анимации используются повсеместно. Лучше запилить кривое говно, но своими руками, чем брать ассеты и флипать как попало, в надежде что незнакомый с играми ньюфаг схавает это.
Посмотрим вместе подробный гайд по UI?
https://www.youtube.com/watch?v=1_OFJLyqlXI
>Конвертируй. Blender вроде поддерживает fbx.
Там выше я же и дал скрипт для блендера.
>А вообще, мне лично не нравится идея брать анимации с какого-то сайта, тем более бесплатные. Это лишает игру уникальности, тем более если эти анимации используются повсеместно.
Анимации делать геморнее чем модельки. Да и узнать анимацию ходьбы на другом скелете - это уже надо савантом аутистом быть.
>атлас directional shadow
>Теперь я добавляю объект в 1000км. Качество тени в эиот момент резко упадет? Ведь атлас старого разрешения теперь натянут на мир
Ничего там не натягивается.
Как работают тени? Это отдельный рендеринг сцены от лица источника света. Т.е. движок поворачивает сцену лицом к источнику света и делает рендеринг всех видимых объектов в чёрном цвете. Затем полученная текстура используется в качестве теней на следующем этапе рендеринга уже от лица твоей игровой камеры. Поэтому источник света умножает число render calls в сцене - движок вынужден рендерить сцену +1 раз для каждого источника света. Чтобы сократить нагрузку на видеокарту, можно сказать "ладно, не рендерь объекты дальше N метров от источника света", а в случае атласа "рендерь дальние объекты в текстуру маленького размера (для скорости), а ближние объекты в текстуру большого размера (для более чётких краёв тени)". DirectionalLight отличается тем, что рендерит сцену в ортогональной проекции вокруг текущей камеры... или что-то вроде того, я точно не знаю.
>Создать Inherited сцену. Не пользуюсь, может аноны пояснят.
Это ООПышное же. Создаёшь item, который содержит всё необходимое для предметов в твоей игре, а затем - потомков item: knife, sword, shield, pistol, dildo... Если тебе нужно изменить общее для всех item свойство, ты меняешь его в item.tscn и это отразится везде сразу. Оригинальный item.tscn ты нигде использовать скорее всего не будешь, он нужен только как общий предок.
Некоторые моменты непонятны, например если навешивать новый скрипт на инхеритед, он же полностью заменяет старый скрипт. Еще там неочевидности могут быть с editable children
>этот свет роняет фпс
>>903741
>решил свое освещение
>фпс упало с 1500 до 1200 на пеке.
Я не понял, ты стремился снизить ФПС?
>>903741
>Интересно даже чего там в четвертой годоти с вулканом можно накрутить.
Там минимальная сцена больше нагружает, по обещаниям Vulkan лучше масштабируется - т.е. будет производительным на больших сценах, но по факту он оказался даже медленнее OpenGL на больших сценах.
Ключевым разработчикам давно известно:
https://github.com/godotengine/godot/issues/68959#issuecomment-1528132865
>если навешивать новый скрипт на инхеритед, он же полностью заменяет старый скрипт
Для этого достаточно сделать так:
>item.gd
>class_name Item extends Node
>dildo.gd
>extends Item
Наследуемость сцен касается только tscn файлов.
>Анимации делать геморнее чем модельки.
Думаю, зависит от требований.
>Да и узнать анимацию ходьбы на другом скелете - это уже надо савантом аутистом быть.
Как будто ты не узнаешь пикрил. А вот если я хочу в игре что-то вроде пикрила, но немного другое, оно на миксамо тоже есть? Вряд ли, там же унылый захват движений с каких-то актёров.
Половины нужных анимаций нет (правда есть некоторые другие сомнительные источники анимаций, но я ими пока не пользовался). Но это все равно в разы быстрее сделать прототип. Анимировать все это пришлось бы неделю или месяц, а так ты сразу качаешь пак и настраиваешь дерево анимаций за день. Будет время или деньги - перерисовывай сколько угодно.
>быстрее сделать прототип
А зачем в прототипе анимации? Я несколько лет цинидром по сценам ездил, проверяя свои идеи.
Если у тебя игра, в которой важны анимации героев, тогда их с самого начала нужно делать свои, потому что они влияют на атмосферу игры.
>Я не понял, ты стремился снизить ФПС?
Предыдущий сетап с directional light на всю сцену ронял с 1500 до 800. Этот быстрее, и выглядит ближе к тому, что мне надо.
Ну сам подумай мне надо чтобы человечек ходил. Или пешеходы ходили. Зачем мне тратить время на анимирование их в начале разработки, когда мне надо просто чтобы они "ходили" и это делается двумя кликами?
>https://github.com/godotengine/godot/issues/68959#issuecomment-1528132865
Дауш. Ну, пофиксят. А на текущий проект все равно на тройке сижу.
Ты бы лучше сразу на мобилке мерял, а то окажется, что подход на ПК не подходит. Вон там автор Айрон Мита в соседнем треде на соседнем движке писал, что у него перенесли выход на консоли из-за обилия вьюпортов.
>directional light на всю сцену
По умолчанию он охватывает только 100 метров вперёд от камеры, дальше теней нет. Не пробовал включать/выключать с помощью Area в зоне?
>быстрее, и выглядит ближе к тому, что мне надо.
Покажешь хоть скриншоты? А то все такие деловые, игры делают аж обои отклеиваются, а показать боятся, как будто это на что-то повлияет.
У меня от вулкана одни неприятности. На некроноуте не запускается вообще из-за дров, на мобилке 3д не рисовалось, веб версия 4-ки на опенжл недописана. Сначала хотел переходить, но совсем передумал. 4-ка это только для какого-то АА пека гейминга.
>мне надо чтобы человечек ходил.
>Или пешеходы ходили.
>мне надо просто чтобы они "ходили"
Ну вот капсулы по маршрутам ездят - и всё. Им не нужно двигать ногами и руками, потому что тебя должно волновать только что они с пути не сбиваются, не застревают и не проваливаются.
>это делается двумя кликами
А ведь можно вообще не кликать.
Зачем мне смотреть на парящие капсулы, когда я могу сразу смотреть на ходьбу?
>Зачем мне смотреть на парящие капсулы
Допустим, ты сделал пешеходов, вдруг видишь как один пешеход застрял и перебирает ногами в воздухе. Что делать будешь? Включать отображение коллизий. А мог бы просто капсулу оставить...
Алсо, даже ААА игры начинаются с капсул и парящих в Т-позе болванчиков. Почему? "Временные" ассеты с высокой детализацией отвлекают от геймплея, который и нужно в прототипе отточить, поэтому без них проще сфокусироваться на главном. Тебе же в первую очередь геймплей нужен; ножками двигать - это не геймплей, а декорация.
https://godotengine.org/community/
Он много где появляется, но
>напрямую спрашивать дибильные ответы
у него не стоит - во-первых, ему некогда с такими ньюфагами возиться, во-вторых, он не знает всех подробностей движка, т.к. части движка написаны разными людьми в разное время. Так что лучше в публичные коммьюнити заходить, кто-нибудь с достаточным свободным временем поможет.
https://docs.godotengine.org/en/stable/community/channels.html
Как минимум, есть чат контриьюторов. Или если сильно разозлить, написав большую статью, то прямо в гитхабе ответит.
Ты говоришь о разных вещах. Естественно если я буду отлаживать коллизии, то буду смотреть коллизии. (Пропустим то, что я не говорил, что у меня человечки на физике). Но тебе нужно иметь дерево анимаций. Чтобы оно переключалось с ходьбы на удары на смерть на бег. И вот тут и нужны плейсхолдерные анимации.
Вот как раз чтобы пешеход не перебирал ногами в воздухе - если он застрял, то у него скорость 0 и он должен переключиться в стоять. Или, если ты считаешь, что у тебя тут противоречие, и он хочет идти но не может, пускай подпрыгивает и руками машет, привлекая твое внимание.
Здесь официально сказано, что ты можешь сконтактироваться с ними за платной поддержкой, включая почасовую. Правда, это писалось до основания W4, но думаю это уже детали, с каким юрлицом договор.
Дискорд полезней чата котрибьюторов. В рокете они пулл реквесты обсуждают, а в дискорде толпы пользователей движка, кто-нибудь да поможет.
Ненавижу ебучий дискорд с его ублюдочным поиском.
Не люблю дискорды как то заходил в некоторые и задавал вопрос но его все проигнорили потому что местный ероха в это время анекдоты рассказывал и все ему отвечали.
Я собираюсь сделать несколько штук для Я.Игр, как думаешь я буду заморачиваться с модельками и анимациями? Нет, я буду ассетфлипать все что можно. И только потом уже вернусь к игре мечты, которую пилю уже несколько лет.
>Я.Игр
Как там с аудиторией? Я полистал их главную страницу, игры в основном какой-то сблев полурабочий. Неужели там люди активно играют?
Недооцененный пост треда. Принялись какую-то хуйню обсуждать. Двачую этот пост.
Сеймщит. Джва месяца уже вожусь с четвёркой и всё очевиднее вырисовывается, что трёшка лучше. В четвёрке поломали сортировку интеллисенца. Вот тупо пишу pri и мне автодополняет как print() а в четвёрке простой print() в списке автодополнения торчит внизу. Что это? И так в большинстве случаев. Раньше в автодополнении очевидные частоиспользуемые строки подбивались вверх. Сейчас нет. Удобство кодинга скатилось в нулину. Версия уже 4.1.1 а трогать нет желания.
В код насрали спецсимволов. Непонятно ради чего? Похоже на саботаж. Был элегантный язык onready var foo. Теперь @onready. Нахуя? Чтобы что? Посмотрев на эти приколы руки опускаются просто.
В трёшку завезли асинхронную компиляцию+кэш шейдеров. В четвёрке с вулканом якобы это не надо. Я не поленился и скачал TPS Demo. И что я вижу? На хвалёном вулкане, при первом выстреле что? Оно самое. ПРОЛАГ ленивой компиляции шейдера пульки. А в трёшке нет. TPS Demo идёт ровно. Первый выстрел шмаляет уже предпрогруженным.
Короче. Четвёрка станет боли-лимени работоспособна года через два, не раньше, как трёшка, только через два года после релиза стала норм, а до того все олды на двушке ебашили по хардкору.
Без понятия, но от скуки буду что то делать. В стим пока не попадаю все равно
Поддерживаю. Пока платформа новая с кучей шлака, ты реально можешь стать легендой, запилив туда годноту.
Годоти, вы готовы к новым беженцам?
Ну тут Хуан предвидел или имел инсайд, предусмотрительно выпилив вижуал скрипт. А плюсовики хорошо, такие могут сильно бустануть движок, в отличии от шарпомух сами знаете откуда
>В код насрали спецсимволов. Непонятно ради чего? Похоже на саботаж. Был элегантный язык onready var foo. Теперь @onready. Нахуя? Чтобы что? Посмотрев на эти приколы руки опускаются просто.
Если кратко, они ввели механизм аннотаций, чтобы перенести часть ключевых слов в аннотации, т.к. парсить все ключевые слова стало слишком сложно, особенно такие сложные, как export. Планировалось сделать это ещё в 2017/2018 году, ты просто не в теме.
Большинство поддержало:
https://github.com/godotengine/godot/issues/20318
https://github.com/godotengine/godot-proposals/issues/828
>>903973
>>903970
Тут не крутость движка главное, а удобство. В этом разрабы годота правы. Нужно чтобы движком мог пользоваться не 100500 айкью гений квантового матана, а средний васян, как вы и я.
Вон, есть движок от того самого КРУЗИСА ЕБАНЫЙ В РОТ. Он же CryEngine, он же Lumberyard, он же O3DE - теперь даже опенсорсный. И никому нахуй не нужен, потому что без выворачивания наизнанку через жопу ты там банально спрайт не сдвинешь.
Так что сидите пилите игры на годоте и не бухтите, у Хуана все схвачено.
>O3DE - теперь даже опенсорсный
Там в системных требованиях минимум 100 Гб для сборки, либо 40 Гб "using the pre-built installer":
https://www.docs.o3de.org/docs/welcome-guide/requirements/
А ведь это ещё компилировать... а это C++...
>от того самого КРУЗИСА
Крузис стал мемом из-за высокой нагрузки на видеокарту, а не из-за какой-то особой крутизны.
>Блять, как я мог самое главное забыть?
Нет, анон, самое главное все забыли - ID Tech. Молодёжь.
>>903907
>Короче. Четвёрка
Помню, было в районе 3.3 какое-то обновление, там писали типа "всё, переключаем внимание на четвёрку, а тут теперь только улучшение производительности". И как улучшили, я аж прихуел, оно запускаться стало вообще моментально.
Есть ли Y Sort Original или что-то подобное для тайлсетов в 3.5?
Привет годотоаноны!
Прошу совета, на сколько приятно, быстро можно на годоте сделать трехмерный мультплеерный шутер? Просто приключение на 15 минут, зашел, пострелял, вышел. Я сейчас на анриле, и осваиваю его, пока не далеко зашел. Присматриваюсь к годоту, нравится его минимализм.
>мультплеерный
На любом движке заебешься, а если не заебешься, то твой шутер поставит раком первый же школочитер.
>трехмерный мультплеерный шутер
>Просто приключение на 15 минут
Ну смотри, для сессионки на 15 минут карты нужны совсем маленькие, так что возможностей Godot хватит без каких-либо хитрых оптимизаций, если не наглеть с 4К текстурами и миллионами полигонов.
Также есть встроенные инструменты для прототипирования карт, так что накидать тестовую карту можешь за пару минут, см. туториал здесь:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Встроенного "ландшафта" нет, но тебе скорее всего будет лучше сделать ландшафт в Blender, т.к. у тебя статичные карты для сессионки, а не опенворлд. Но если очень нужно, есть аддоны от третьих лиц плюс вроде как обещают официальный аддон.
С контроллером персонажа не всё так просто, в отличие от UE у нас нет готового решения "кинул и играешь", нужно писать что-то своё под конкретную игру или искать готовый шаблон. Официальные демо самые простые, в современных шутерах контроллер персонажа учитывает намного больше.
Если хочешь ботов, то в Godot есть система навигации по навмешам и более абстрактные реализации AStar, а всю остальную логику придётся думать самому, но тут тоже есть сторонние решения, например, можешь погуглить Godot GOAP.
По мультиплееру есть встроенное решение, я его не использовал и мультиплеерных игр не делал, но оно выглядит больше подходящим для кооперативных игр, чем для сессионных DM/TDM/CTF:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Для сессионки тебе вообще в первую очередь нужен мастер-сервер, который будет собирать всех клиентов и раздавать им список лобби/матчей. В смысле, если ты хочешь прям запустить игру и сразу с рандомами поиграть, как это обычно бывает.
Если хочешь античит, лучше сразу на сервере всё делай, чем меньше доверяешь клиенту - тем меньше у читера потенциальных возможностей навредить. Это так, общая рекомендация, когда-то где-то читал.
Главное, не питай слишком больших надежд, это не многомиллиардная дойная корова мегакорпорации, а проект любителей инди-геймдева для инди-геймдева, который только недавно начал получать широкую огласку и крупные пожертвования.
Не забывай про документацию, она здесь очень хорошая, и обсуждения проблем/предложений на GitHub, также ты можешь копаться в исходниках и собирать движок сам, но в твоём случае это скорее всего вообще не понадобится.
Проще всего порыться в ассетах и репозиториях, я там насчитывал штук 5 демок мультиплеера. Могу ближе к ночи посмотреть какие скачивал. И потом поверх них навернуть свою игру.
Сам в блендере не работал и в целом в моделировании или рисовании ноль, поэтому надо будет брать ассеты и анимации откуда-то... Либо учиться делать простые модели, но это дел на месяц, страшно думать о том, что чтобы сделать простую тестовую игру придется целый месяц учиться новому скиллу
Есть ряд вопросов по планируемой игре мечты. Скажу прямо, планирую 2д порно игру с видом сверху, сначала думал вкатываться в рпг мейкер но вовремя одумался.
Насколько сложно реализовать диалоги как в визуальных новеллах, с выборами, картинками и прочим, инвентарь, простенькую боевую систему хотя бы по типу камень ножницы бумага?
Ну и вопрос не по движку, очевидно, что визуал должен быть на уровне чтобы можно было дрочить, а я не особо художник, поэтому надеюсь на нейросети, подскажите, какие из них могут внятные 18+ 2д картинки для игры сделать.
Для ветвистых диалогов есть плагин - Dialogic, фактически на всем готовом ехать будешь. Но да, твоя главная проблема - арт. Вроде stablediffusion умеет в прон. Видел у анонов с форча гайды. Покопайся тут:
https://boards.4channel.org/g/thread/96309968
https://boards.4channel.org/g/thread/96312849
Полные нюдесы они там не постят потому что борда синяя.
Спасибо! Буду изучать, хватило бы только моей ноутбучной затычки mx250 на рендер
Во первых не бойся, не кусает.
Во вторых год это разве срок для такого навыка?
Делай по чуть чуть. Научись вставлять готовую модельку с анимацией. Научись добавлять другую готовую анимацию. Сделай свою анимацию. Сделай бублик из куба по гайду.Сделай свою модельку по гайду лоуполи за час. Сделай ей скелет для анимаций. Сами по себе это несложные задачи на час-день, надо только разобраться. Пара видосов для вдохновения
https://www.youtube.com/watch?v=59vKbXKuaNI
https://www.youtube.com/watch?v=WY2cN9uG6W8
https://www.youtube.com/watch?v=csR8LfgTKNE
https://www.youtube.com/watch?v=gJ-XW5xLNsw
Да, с первого раза не все понятно, не стесняйся ставить на паузу, пересматривать. Ищи другие если эти не понравятся.
>Сделай свою анимацию. Сделай бублик из куба по гайду.Сделай свою модельку по гайду лоуполи за час. Сделай ей скелет для анимаций.
надеюсь, что ты знаешь, что такое структура дерево, если нет, то погугли картинку
так вот твоя игра всегда содержит такое дерево, когда запущена, туда помещаются ноды - узлы этого дерева
корнем дерева является нода subviewport, только она тебе не отображается, считай, что ты просто к ней достраиваешь дерево своей игры
сцена - это точно такая же нода в твоем дереве со своими дочерними узлами, просто выделили так, чтобы удобнее было загрузить и выгрузить по необходимости
как именно в своей игре будешь формировать это дерево - зависит от задачи, можешь например создать в игре базовый узел node, в нем напишешь скрипт, который будет к нему загружать и выгружать сцены твоей игры (сцену главного меню, сцену уровня ...)
в принципе в ассетах есть много реализаций подобных штук, которых можно поискать по фразам "state ..." и тому подобных
у нас в команде новый проект начинают на гдскрипте, потом критичные участки переносят на плюсы (хотя большая часть требуемых задач уже перенесена, так что от программиста требуется только по больше части поддержка)
прямо писать особых проблем нет, хотя совсем верхнюю логику все равно проще держать в скриптах или модинг игры, если предусматривается
а так пишешь модули к движку и дергаешь
можно хоть сам движок собрать с нужными кусками в том числе своими, только там еще питон накатить нужно будет для системы сборки вроде бы
Вполне комфортно пишется, насколько это применимо к c++ в принципе, после единоразовой долгой настройки.
Я писал как то как у меня сделано. Игровая логика на c++ и она отделена от движков (там ecs модель мира и сущностей) собирается в dll/so.
И вторая либа, которая scons собирает gdnative/gdextension, эта либа инклюдит Godot.hpp, она дергает логику первой либы, при этом видна для гдскрипта как обычный класс. Гуй обычные сцены с гдскриптом. Итого MVVC. Пишу я в vscode или geany, сборка 5 секунд батником.
Также в качестве эксперимента я пепеписывал 1 в 1 туториалы, без особых проблем, но полностью так писать игру дольше, чем на гдскрипте, еще думать про все эти Ref<Type> и memnew()
Я уже спрашивал, но вопрос скорее всего никто не заметил. Как в годо поставить точку с которой будет сортироваться по Y тайлы для каждого тайла?
>вопрос скорее всего никто не заметил.
>поставить точку с которой будет сортироваться по Y тайлы для каждого тайла
Я тот раз заметил, но так и не понял, что ты хочешь.
>Мне начинать с отдельных элементов, а последная и главная сцена это будет главный экран, где после нажатия новой игры все запустится?
В разработке есть два подхода:
https://en.wikipedia.org/wiki/Bottom-up_and_top-down_design
Сверху-вниз: от главной сцены к отдельным нодам.
Снизу-вверх: от отдельных нод к главной сцене.
Godot поощряет подход снизу-вверх, но его можно использовать и в подходе сверху-вниз. На практике удобнее смешивать, что-то делая в виде пустышки и дополняя деталями, что-то делая мелкими частями и объединяя их в одну большую систему. Выбирай сам.
>>904640
Спасибо аноны! Более менее разбираюсь. Сейчас в тупике по поводу коллизий, мой игрок (characterbody 2d) почему то проходит сквозь объекты, хотя если я создам rigidbody 2d и на него накину скрипт управления, то он уже нормально себя ведёт. Маски и слои настроены одинаково, 2д вид сверху с 0 гравитацией если это важно
Все починилось само, если вчера ничего не работало, то сегодня вдруг стало работать как должно
В целом всё верно.
В этот скрипт ещё прикрутить бы таблицу базы данных с именами сцен, куда возможно переходить, и менеджер сцен, который по имени производит фоновую загрузку сцены, и будет ваще мидл-левел.
Просто при сортировки тайлов в ноде Y-sort они используют точку сортировки из настроен tilemap, а именно настройки tile original и она для всех тайлов из tilemap одинаковая. А я хочу установить её для некоторых тайлов в другом месте. Например, не в центе, а в левом верхнем углу
Forward видимо старается максимальный на платформе использовать типа DX на винде, Metal на маке или они все там в основе имеют Angle и просто разные прослойки вызовов с разным функционалом?
>Forward видимо старается максимальный на платформе использовать типа DX на винде, Metal на маке или они все там в основе имеют Angle и просто разные прослойки вызовов с разным функционалом?
Forward и Mobile - два разных набора настроек Vulkan.
Подробнее: https://www.vulkan.org/
>Vulkan is a cross-platform industry standard enabling developers to target a wide range of devices with the same graphics API.
Наследник OpenGL от Khronos Group, он же glNext.
1. Если не планируется никаких модификаций строки, тогда лучше вместо String использовать StringName. Хотя в твоём случае разницы особо не будет.
2. Лучше явно указывать типы везде, где должен храниться только определённый тип данных, скажем, нужно указать var Vzone: bool, так как это флаг и он должен принимать только true или false.
2.1. Также лучше явно указать начальное значение, даже если это ноль/false: var Vzone: bool = false. Без явно указанного типа начальным значением по умолчанию вообще является null (если не ошибаюсь).
3. Тогда вместо Vzone == true достаточно будет указать Input.is_action(...) and Vzone: get_tree()... - новички часто переусложняют булевы выражения, так вот, следует упрощать: Vzone уже либо true, либо false.
4. Соблюдай правила именования, которые ты сам и принял: если у тебя одно поле называется next_scene, то поле Vzone должно называться v_zone.
5. И что за "v_zone"? "victory_zone"? Не жалей букв, тебе же потом читать этот код и вспоминать его смысл.
5.1. По смыслу лучше назвать "victory_achieved": это флаг, сообщающий о достижении игроком условия, а не хранилище объекта ("zone" - существительное, "achieved" - глагол в прошедшем времени).
5.2. Алсо, принято именовать приватные поля класса начиная с подчёркивания: "_victory_achived", несмотря на отсутствие приватных полей в GDScript.
6. В _body_entered и _body_exited имеет смысл сделать дополнительную проверку вроде if body is Player, если у тебя игрок имеет class_name Player. Да, ты можешь ограничить срабатывание Area отдельным слоем, но вдруг ты что-то напутаешь и сломаешь, потом будет сложно найти причину, почему рандомный предмет вызывает переход на следующий уровень.
7. change_scene_to_file имеет смысл только в очень простых играх с уровнями, где игрок стартует всегда в одном состоянии. В более сложной игре придётся переносить данные между локациями и сохранять предыдущее состояние локации. Просто напоминаю.
>>904712
>ещё прикрутить бы таблицу базы данных с именами сцен, куда возможно переходить
Зачем? У него этот скрипт висит на флажке в конце уровня, что-то по типу Марио получается.
>менеджер сцен, который по имени производит фоновую загрузку сцены
Зачем? В игре типа Марио лучше дать подождать загрузки уровня в конце уровня, чем тормозить игру асинхронной загрузкой в процессе уровня. Другое дело, сюда бы загрузочный экран прикрутить, если уровни действительно большие и долго грузятся...
Почитай вот это ещё:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
Можно где-то в настройках редактора включить добавление типов в заголовки стандартных функций.
>>904813
>Input.is_action(...) and Vzone: get_tree()
Ещё лучше будет сделать так:
>if victory_achived and Input.is_action...
Потому что значение флага известно заранее, а метод класса Input требует какой-то дополнительной работы. Поскольку выражение у нас and, если первый элемент false, то результат тоже false. Интерпретатор имеет возможность оптимизировать этот момент, исключив лишнюю работу по вызову функции. Хотя происходит ли это в GDScript - не знаю, но если нет, можно разбить условие на два: if victory_achived: if Input.is_action...
...вообще, самое главное я не увидел сразу: вместо _process здесь следует использовать _unhandled_input:
>func _unhandled_input(event: InputEvent) -> void:
> if victory_achived and event.is_action("ui_accept"): ...
Потому что _process происходит столько раз в секунду, сколько игра рендерит кадров, а _input срабатывает только при нажатии клавиш, и в свою очередь _unhandled_input работает только когда остальные элементы сцены проигнорировали нажатие клавиши.
А вообще, я бы сделал так:
1. Попадание игрока в финишную зону открывает окно "вы победили, перейти на следующий уровень?"
2. Игрок всё ещё может двигаться, если он уходит, окно скрывается, либо игрок может сам его убрать.
3. Скрипт перехода на следующий уровень - это уже часть окна "вы победили", а не часть финишной зоны.
Таким образом можно повторно использовать то же окно с тем же кодом для любого другого условия победы, вроде того, что игрок съел всю еду на уровне, убил всех мобов или выполнил все задания. Флажок в стиле Марио только вызывает это окно, ничего не зная о предназначении и дальнейших действиях окна.
>при сортировки тайлов в ноде Y-sort
>точку сортировки из настроен tilemap
Как это вообще связано? Нода YSort в версиях 3.x нужна была для сортировки CanvasItem:
https://docs.godotengine.org/en/3.5/classes/class_ysort.html
Внутри TileMap тайлы сортируются автоматически.
Если тебе нужно расположить спрайты персонажей между высокими тайлами, тогда включи это:
https://docs.godotengine.org/en/3.5/classes/class_tilemap.html#class-tilemap-property-cell-y-sort
И расположи персонажей в потомках TileMap.
>она для всех тайлов из tilemap одинаковая. А я хочу установить её для некоторых тайлов в другом месте.
Так и не понял до конца, но ты пробовал создать отдельный второй TileMap с другими настройками?
>>904817
>>904813
>>904712
Спасибо за оценки, подправил немного
>менеджер сцен и фоновая загрузка
Пока что для меня это вообще темный лес
>разные названия переменных
переменную с _ я подсмотрел в гайде,поэтому так и написал, а самому ставить _ постоянно меня угнетает, Взоне буквально значит в зоне (рядом с дверью)
>unhandled_input
Я честно попытался понять как это работает и чем будет лучше в моем случае и не смог.
>переусложнение условий
единственный язык который я немного знаю это школьный паскаль, поэтому так пишу, а как упрощать я вообще не понял, так для меня код логику сразу теряет
Дополнительно прикрутил картинку-подсказку нажать кнопку для перехода, у меня 2д вид сверху с открытым миром если что, на примере это вход в здание. сами иконки и скрипт отдельной сценой, планирую во всех переходах ее ставить. И да, все спрайты всратые потому что я их спиздил на скорую руку. Сейчас даже не игру делаю, а технодемку, чтобы освоить механики, как доделаю, скину сюда проект я тот анон с порноигрой
>самому ставить _ постоянно меня угнетает
Автодополнение в коде позволяет быстро набирать код, не набирая большую часть символов в словах.
>Взоне буквально значит в зоне (рядом с дверью)
Ясно, я неправильно понял.
>чем будет лучше в моем случае
Вот смотри, допустим, у тебя частота кадров 60. На твоей карте одна дверь, значит, ты 60 раз в секунду проверяешь условие:
>if Input.is_action_pressed()...
Если ты добавишь вторую дверь, эта проверка будет гоняться уже 120 раз в секунду. 10 дверей - 600 раз в секунду. Если теперь твою игру с десятью дверьми запустить на компьютере с монитором 120 Гц, тогда у тебя будет уже 1200 проверок в секунду.
А самое главное, тебе 99.99999% этих операций не нужны, т.к. игрок переходит от двери к двери редко. Так что ты просто впустую гоняешь процессор.
Yandere Simulator знаешь? Там одно время были дичайщие тормоза от того, что каждый студент 60 раз в секунду "смотрел на часы", чтобы узнать, не пора ли ему отправиться на урок - здесь суть та же.
>единственный язык который я немного знаю это школьный паскаль, поэтому так пишу
Я тоже с него начинал, там всё так же работает.
>а как упрощать я вообще не понял, так для меня код логику сразу теряет
Почему теряет-то? Ты буквально пишешь:
>ЕСЛИ нажата клавиша Enter И игрок находится в зоне действия двери ТОГДА: загрузить комнату
Зачем тебе писать Vzone==true, если ты можешь ПРОСТО написать Vzone и смысл будет тот же?
>2д вид сверху с открытым миром
>это вход в здание
Ну так бы сразу и сказал, что jRPG, там простым переключением сцен лучше ничего не делать. Нужно специальный менеджер писать, чтобы все состояния сохранялись и переходы были достаточно быстрыми.
>спрайты всратые
Нормальные спрайты для таких игр. Мне нравится.
>Там одно время были дичайщие тормоза от того, что каждый студент 60 раз в секунду "смотрел на часы", чтобы узнать, не пора ли ему отправиться на урок - здесь суть та же.
Вообще, тормоза были из-за того, как он использовал ассет на поиск пути, а эти проверки расписания почти не влияли на производительность
>unhanded
Я переделал дверь под это, хотя я все ещё не понимаю логику этой функции, типо не игра проверяет нажатие кнопки каждую дельту, а кнопка запускает функцию сама?
>все ещё не понимаю логику этой функции
Почитай документацию что ли:
https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html
Даже перевод (частично) на русский есть:
https://docs.godotengine.org/ru/4.x/tutorials/inputs/inputevent.html
Для тройки перевод полный:
https://docs.godotengine.org/ru/3.x/tutorials/inputs/inputevent.html
>кнопка запускает функцию сама?
Не совсем. ОС генерирует т.н. "события", приложение (Godot) их принимает и что-то с ними делает. Есть стандартные обработчики, например, при клике на Button кнопка на экране меняет свой внешний вид, будто надавливается; при нажатии стрелок курсор (фокус) переходит с одного Control на другой или внутри одного (LineEdit). А есть ситуации, в которых ты хочешь сделать что-то сам, заложить какое-то специфическое поведение. Для этого существуют обработчики _input и два других. Они вызываются движком, когда возникает событие ввода, и ты там можешь что-то делать в зависимости от того, что за событие ты получил.
Хотя, я тут подумал, на самом деле _input вовсе не обязательно эффективнее _process. У меня мышка генерирует события ввода до 500 раз в секунду, так что моя игра начинала лагать просто из-за тысяч попыток сдвинуть камеру в 3D игре за секунду, лол. Вроде, не так давно в треде обсуждали, не помню, к чему пришли... Для дверей лучше какой-то другой подход, например, чтобы персонаж посылал двери запрос на взаимодействие, тогда у тебя обработка ввода будет только в одном месте - в персонаже, независимо от числа дверей. Двери вообще не будут проверять нажатие клавиш, а в персонаже ты в любом случае должен проверять ввод - тогда лишних операций проверки не будет. Короче, я с самого начала не туда глядел, извини, если запутал.
>Двери вообще не будут проверять нажатие клавиш
Собсна, нужно было с самого начала задаться таким вопросом: почему дверь слушает ввод пользователя? Игровая дверь - пассивный объект игрового мира, она не управляется игроком напрямую. Игрок управляет персонажем, а уже персонаж активирует кнопки, рычаги, двери, раздвижные мосты и прочее. Ведь когда вы делаете в игре врага, вы не ставите ему обработчик кликов мыши, вы ставите ему обработчик попадания удара или пули, которые могли возникнуть со стороны персонажа игрока по нажатию кнопки мыши, а могли и по другой причине (ловушка, напарник игрока, общий враг и т.п.).
Т.е. дверь просто ждёт запрос от игрового персонажа, а игровой персонаж ждёт нажатий клавиш игроком.
Я бы вообще немного архитектурно переделал.
Вот у тебя иконка двери же появляется когда подходишь.
Значит ты вообще можешь избавиться от Vzone
Алсо, есть такая функция, как set_process(bool)
То есть ты можешь включать process когда срабатывает твой on enter и выключать в on exit. Так скрипт вообще не будет молотить когда ты не зашел в триггер.
>при нажатии кнопки должна проигриваться анимация на объекте и в поле для текста должен виводиться текст
>РРРРЯЯЯЯЯЯЯЯЯЯЯЯ НУУУЛЛЛЛЬ ИНСТАААААНССС НЕ НАЙДЕНААА ТАКОВАААААА
>>904880
Я переделал логику, теперь в игроке идёт проверка нажатия ентера, если да то посылается сигнал. А дверь при получении смотрит, если игрок в зоне, то переключает лвл. Минус в том, что на каждом уровне надо вручную подключать каждую такую дверь к игроку, но это мелочи. Я нашел event bus, но так и не смог настроить у себя, и забил хуй, буду руками подключать.
Ты вручную анимации делал? Проверь что масштаб не трогал.
Вроде все очевидно, не? Ты вызываешь Head/BoxContainer относительно текущей ноды, но скрипт пишешь не в Player а на две ноды глубже. Тогда тебе надо что то вроде $"../../Head/Boxитд"
Это можно сделать несколькими простыми способами.
Например при загрузке уровня игрок сам в цикле проверяет все объекты (по имени или группе) и добавляет двери. Или, наоборот, каждая дверь сама себя регистрирует. Можно вообще самому сделать без всяких eventbus. В скрипте уровня завести массив дверей, каждая дверь онреди себя туда записывает, при спавне игрока он подписываеи каждую дверь из массива на события
Ладно, это уже для больших игр и студий, мне кажется проще 5 минут потратить на ручную настройку условных 100 дверей в игре, чем писать код как минимум несколько часов по крайней мере с моим уровнем
Да не, это для любительского соло геймдева простой вариант, сложные для студии я не стал расписывать
Не думаю что тут полно спецов по вулкану
В самой свежей бете 4.2.dev6 есть такая инфа
An optional ANGLE-backed OpenGL renderer was added for macOS and Windows (GH-72831). ANGLE is a compatibility layer for OpenGL on top of Metal and Direct3D 11, which allows us to work around the deprecated and unmaintained OpenGL drivers on macOS, and similarly outdated OpenGL drivers on Windows for some older integrated chipsets. This should increase the portability of Godot games on lower end devices.
>>904990
Ой, поцики, забил сказать, шо я это пофиксил уже.
Часов в 13-14. Спасибо.
>>904992
>Вроде все очевидно, не? Ты вызываешь Head/BoxContainer относительно текущей ноды, но скрипт пишешь не в Player а на две ноды глубже
Ну да, я это понял примерно где-то через минуту после постинга и пофиксил чуть позже. Так сложно на самом деле. Неприятно.
Спасибо.
>подключать каждую такую дверь к игроку
Не нужно подключать заранее ничего.
В 3D можно сделать так:
1. Из игрока торчит RayCast3D в направлении взгляда.
2. Когда игрок нажимает кнопку "использовать":
- проверяем, с чем пересекается наш луч взгляда:
>if ray.is_colliding(): var body := ray.get_collider()
- проверяем наличие метода и вызываем его:
>if body.has_method("interact"): body.interact(self)
3. Далее любой интерактивный объект должен реализовать свой метод interact(target), который реагирует на нажатие кнопки "использовать".
В 2D на квадратной сетке можно сделать проще, без бросания лучей и без Area, просто проверяя, на какой клетке стоит фигурка игрока и куда она смотрит. Но ради быстрого прототипа можно и RayCast2D...
ага, значит скорее всего просто стандартизовали api через Angle, чтобы удобно было
спасибо
Ну ты ну! По ссылкам переходи всё таки
> Q: What difference with Dialogic ?
> A: Our project use normal coding with our own scripting langue inspired by Ren'Py, instead of visual. Plus is just a core, simple as possible, autoloaded when you enabled the plugin. If you want more check our addons and kits bellow.
Я нашел это, но в чем лучше то? Отсутствие визуального программирования преподносится как плюс?
Как я понял диаложик в принципе для диалогов, тогда как ракуго специализируется именно на ВН, именно на подобии РенПу
> Призываю в тред раст-куна, которого видел на неделе в каком-то из тредов. Раст-кун, приди. Научи как сделать свою сбоpку с волшебной интерполированной дельтой и скриптингом на расте.
Призываю в тред раст-куна, которого видел на неделе в каком-то из тредов. Раст-кун, приди. Научи как сделать свою сбоpку с волшебной интерполированной дельтой и скриптингом на расте.
>with our own scripting langue
Я установил в твой собственный скриптовый язык еще один собственный скриптовый язык, чтобы ты мог скриптить пока скриптишь
> Какой плагин для диалогов как в визуальной новелле лучше?
> Пока остановился на
> но в ассетах видел много других
Позагружай все. В отдельные тестовые проекты, разумеется. Погоняй-посмотри. Выбери наиболее подходящий тебе.
Помни!
Лучших нет. Есть только подходящие.
Отзываю из треда раст-куна, не хватало нам ещё ржавчины в движке, и без неё всё еле работает.
>сбоpку
Зачем? https://godot-rust.github.io/
>Тот который ты пишешь сам - лучший
Получается лучшая игра - та, которую ты написал? Все ГОТИ мои?
>Тот который ты пишешь сам
Визуальные новеллы делают всякие писаки-забияки и яжхудожники, они не хотят разбираться в кодинге и изобретать велосипед с нуля, они хотят ЕХАТЬ.
Поэтому они берут готовое и пишут скрипты вроде:
>{Вася} Машка, го трахаться!
>{Маша} Ах, Василий, вы такой дерзкий!
>{sex_scene_69.png}
Вот и вся "разработка игры".
>>905179
>еще один собственный скриптовый язык
https://ru.wikipedia.org/wiki/Предметно-ориентированный_язык
>Предметно-ориентированный язык (англ. domain-specific language, DSL — «язык, специфический для предметной области») — компьютерный язык, специализированный для конкретной области применения (в противоположность языку общего назначения, применимому к широкому спектру областей и не учитывающему особенности конкретных сфер знаний). Построение такого языка и/или его структура данных отражают специфику решаемых с его помощью задач.
GDScript - язык общего назначения.
%твой язык в игре% - язык для конкретной игры, учитывающий особенности разработки этой игры.
Алсо,
>Строго говоря, деление языков программирования на языки общего назначения и предметно-ориентированные весьма условно, особенно, если учесть, что формально любой протокол или формат файлов является языком.
Так что в Godot кроме GDScript есть ещё безымянный декларативный язык сцен и ресурсов (tscn/tres) и наверняка что-то ещё, тоже специализированное.
> безымянный декларативный язык сцен и ресурсов
На TOML похож.
Падажжи. Как так? В том же диалоджике вместе с ассетом поставляется сцена-пример. Ты не можешь её штоле открыть и тупо скопировать со своим текстом и артом?
Обычно сложно интегрировать чужие решения в свою игру. Например инвентарь. Хоть и есть прикольные проекты, но мне было проще сделать самому, чем пытаться впендюрить в свой код
мимо
> буду делать собственную примитивную систему диалогов
Ну вот тебе совет от бывалого участника ТВГ, занимавшего 10е-12е места, лол.
Юзай JSON для описания диалогов, его экстремально легко парсить, то есть, если он у тебя корректно написан, то при загрузке ты получаешь готовый словарь в котором просто обращаешься к ветвям по мере проигрывания диалога.
Фишка в том, что при написании парсера заложи, что каждое возвращаемое значение может быть либо словарём (типизированным, с полем "type" и строковым значением типа), либо массивом типизированных словарей, либо переменной системного типа. Благодаря этому, как показано на скрине, ты можешь писать небольшие фрагменты диалогов и ссылаться на них, а так же ты можешь в диалоге описать типизированные объекты и опять же ссылаться на них, но тебе ничего не помешает внутри одного файла описать несколько ветвей диалога, а поскольку корневой элемент имеет имя, то между ветвями можно ссылаться на другие ветви по имени корневого элемента в поле "next".
В строке 26 я написал образно просто строку с якобы обращением к игровому синглтону, но если ты решишь реализовывать этот вариант, то там будет немного иначе, есть пара подводных камней, но в целом ты и такую строку сможешь распарсить, движок в этом тебя не ограничит.
Теперь подробно распишу алгоритм парсинга скрина.
Сначала парсер ожидает словарь типа "диалог-файл", если получено иное, выдаёт ошибку. У этого типа словаря парсер ожидает найти поля "персонажи" и "беседы" каждый из которых может быть как встроенным словарём, так и строкой-ссылкой на общий файл в базе данных.
Далее парсер загружает словарь с персонажами, и держит их в переменной, чтобы ссылаться на них.
Далее парсер загружает словарь с беседами, если у него нет данных о том, с какого корневого узла начать/продолжить, он открывает первую по индексу (помним, что словарь всё равно массив) и ожидает типизированный словарь "строчка", у которого ожидает наличие поля "условия".
Далее парсер парсит условия по списку, если найдены условия "на_старте", то выполняет их, и если они тру, выводит текст на экран, выводит имя на экран, находя его по ссылке, иконку, так же.
Далее парсер рекурсивно загружает типизированный словарь из поля "следующий". Если в поле строковый путь к файлу - предварительно загружает файл.
И так пока весь диалог не покажет.
Система охуенно масштабируема. Можно тупо в одном файле всё описать, а можно навернуть сложнейшее эрпоге с базой данных персонажей, стат/скилл-чеками, дайс-роллами, и прочими блек-джеками.
Систему условий ты тоже реализуешь сам. Можно реализовать енум из трёх констант: на_старте, в_середине, в_конце. На старте мы решаем показать ли строку или скипнуть. Если строка это корень, и условие провалено, то скипается весь диалог вообще. Если условие в конце, то скипаем некст. Если условие в середине, то нужно например в тексте поставить метку, в какой момент вывода текста нужно чекнуть условие. И соответственно, ЮИ при выводе текста должен уметь скрывать метку с глаз и посылать сигнал парсеру, а парсеру на этот сигнал быть подписанным.
Поле некст (следующий) может быть списком ответов, и тогда там нужно описать отдельный тип словаря, у которого кроме поля "текст" есть поле "заголовок" (caption). которое будет выведено на кнопке у игрока в ЮИ. При проектировании более сложных диалоговых систем уровня РПГ, ответами смогут быть все строчки, просто если их "выбирает" непись, игрок не видит заголовка.
На самом деле, я тут перечитал написанное и понял, что неправильно обрисовал тебе часть с условиями. Вообще говоря, следует в диалогах держать поле "скрипты" в котором будет список из типов скрипта: условие, действие. Условия возвращают булево значение. Действия просто делают, например, устанавливают переменные.
Спасибо за такой развернутый ответ, но я все равно ничего пока не понимаю годот скачал неделю назад. Надо будет выделить вечер и сесть разбираться со всем этим.
> но я
А меня уже понесло 😁 продолжил продумывать дизайн пикрелейтед.
Ну ладно. Как освоишься, и если не сбежишь, приходи - возобновим беседу.
Это вариант INI-файлов, называют ConfigFile:
https://docs.godotengine.org/en/stable/classes/class_configfile.html
>This helper class can be used to store Variant values on the filesystem using INI-style formatting. The stored values are identified by a section and a key:
>[section]
>some_key=42
>string_example="Hello World3D!"
>a_vector=Vector3(1, 0, 2)
>ConfigFiles can also contain manually written comment lines starting with a semicolon (;). Those lines will be ignored when parsing the file.
>Note: The file extension given to a ConfigFile does not have any impact on its formatting or behavior. By convention, the .cfg extension is used here, but any other extension such as .ini is also valid. Since neither .cfg nor .ini are standardized, Godot's ConfigFile formatting may differ from files written by other programs.
>10е-12е места
Что?.. Как ты занимал такое место?
>10e-12 in decimal form
>0.000000000010
Ох уж эти ТВГ...
>Юзай JSON для описания диалогов
Лучше https://hjson.github.io/ - его намного легче писать вручную, чем корректный JSON.
Проблема подхода "всё в JSON" в том, что ты должен описывать буквально структуру в памяти, что не обязательно наиболее удобная запись для человека, а костыли не обязательно удобны для программы.
уххх, скоро бетки пойдут
> 10e-12 in decimal form
Смишно пошутил, петросян.
> его намного легче писать вручную, чем корректный JSON
Да это всё понятно. Суть в том, что корректный жсон поддерживается гдскриптом искаропки, а для некорректного придётся парсер писать. А мог бы игры делать.
Хз как можно писать не на json. Есть миллиарды инструментов, которые позволяют очень удобно на нем писать. Зато костыли никакие не нужны и это де факто стандарт
Годотеры, у меня вот у персонажей есть различные скилы, котоыре сделаны отдельными нодами, прикрепляемыми к персонажам. Что будет лучше для производительности: прикреплять все ноды скиллов при создании сцены или при использовании скилла прикреплять только необходимую?
> Что будет лучше для производительности
Наследоваться от RefCounted.
> class_name Skill extends RefCounted
Прикреплять скиллы в локальный массив персонажа.
> var skills : Array[Skill]
> skills.append(Skill.new())
На одну сущность до 15 скиллов приходится пока что. Игра - пошаговая тактика.
У меня скиллы это не просто объекты, а каждый скилл целая сцена.
>>905442
>>905436
Если тебе надо удобную поддержку в редакторе, то наследуйся от Resource, затем у персонажа сделай
> @export var skills : Array[Skill]
И получишь удобную форму для прикрепления скиллов к персу в инспекторе.
В обоих случаях ты не будешь в скиллах тянуть ненужный тебе функционал Нод.
> каждый скилл целая сцена
Я предъявляю претензию к твоей архитектуре. Скилл это ресурс. Он может добавлять сцену при необходимости, но ему незачем держать в себе сцену. Подумай над архитектурой ещё.
>Если тебе надо удобную поддержку в редакторе
Ну, через редактор я их все равно добавлять не буду, так что не надо.
>>905448
Тогда зачем ресурс? Если он все равно будет добавлять сцену, как у меня во втором варианте, то я просто смогу узнать скилл, который нужен, по его id?
>>905446
Хочется, чтоб даже на древней картошке игра шла все таки.
Это экономия на спичках, для пошага. Ты проверял на древней картошке? Какие цифры получил?
> скилл это сцена
Просто покажи мне это. покажи скринами код и иерархию сцены. Я просто не могу себе представить ЗАЧЕМ???
В основной сцене, локации/мира и т.п. должен быть скрипт, который принимает сигналы/запросы на добавление спецэффектов в требуемых координатах. Скиллы должны уметь посылать такой запрос. И всё.
Продолжаю не понимать.
Пока что фпс высокий, а загрузка системы низкая, но насмотревшись на игры, где лагать может даже менюшка, то хочется, чтоб у собственной игры так не было
>>905454
В зависимости от скилла в ноде содержатся animation player, tween, sprite, particles2D
У меня примерно похожая система, только не пошаг, а платформер. Персонаж театрстейт-машина, а ноды в нём - актёрыстейты. Опрашивается это всё в физикс_процессе. Работает нормально на слабом железе, в том числе и на морально устаревшем андроидофоне.
И да, очень удобно в такие скиллы-сцены добавлять всякие штуки типа партиклей, рейкастов и вообще всего такого, что им может понадобиться. Мне кажется, это очень годошный подход. Да, нода в памяти занимает чуть больше места, чем ресурс; но зато у неё есть колбэки, которые можно быстро задействовать (а если не задействовать, то их как будто и нет) и все плюшки нод вообще.
>>905462
Ладно, делайте как хотите. Но вы мешаете данные и логику. Вы не видите разницы между скиллами как данными и скиллами как эффектами, которые они порождают при их применении. Я напоследок предупреждаю, что такой "удобный" подход вероятно приведет вас к производственному аду. Засим умолкаю.
Мне самому показалось это очень удобным и, пока что, на практике тоже, но вот я не знаю будут ли проблемы с количеством этих самых нод.
>>905466
>данные и логику
Данные о скиллах, вроде расхода маны, цены и т.д лежат в словаре, а логика в скрипте ноды. Где тут смешивание? Или что ты под этим имеешь ввиду?
До тех пор, пока у тебя не пара тысяч персонажей, в каждом по два десятка нод-скиллов, движок прекрасно вывезет из обработку в реалтайме. В пошаге - умножай на 10.
ФПС, как я заметил, просаживается от большого числа графических объектов. И сложная физика тоже может съедать фепесы. А, и, конечно, вот такие советы:
>>905458
>сигналы/запросы на добавление спецэффектов в требуемых координатах
Нода, висящая в дереве, сама по себе почти не потребляет вычислительные ресурсы. Партикля, которая время от времени включается, гораздо производительнее, чем партикля, которая добавляется в дерево, отрабатывает и удаляется. И вообще, это чревато утечками памяти.
>>905466
1. Производственный ад в соло-разработке? Ну да.
2. Я без проблем могу описывать персонажа в жсоне, а потом собирать его из нод, парся жсон. Например. Используя ресурсы вместо нод, я не выигрываю ничего, но теряю в гибкости.
3. А файл tscn это данные или логика, по-твоему? А скрипт, всё содержимое которого это просто один большой словарь, это данные или логика?
Ну то есть, сам поинт понятен, разделять действительно следует. Но это не тот случай, как по мне. Движок даёт удобные средства, и я не вижу причин ими не пользоваться.
>До тех пор, пока у тебя не пара тысяч персонажей, в каждом по два десятка нод-скиллов, движок прекрасно вывезет из обработку в реалтайме. В пошаге - умножай на 10.
Спасибо за ответ, если вывезет, то прекрасно. На уровнях, которые уже есть, максимум 40 персонажей есть.
>Суть в том, что корректный жсон поддерживается гдскриптом искаропки
У тебя и будет 100% корректный JSON на выходе, без необходимости подсчитывать скобки, кавычки и запятые. А в исходниках даже комментарии будут!
>а для некорректного придётся парсер писать.
Зачем писать, если всё давно написано?
https://hjson.github.io/users.html
>To use Hjson with an application that does not support Hjson (yet) but has JSON configs:
>Convert your existing config to Hjson (do this only once)
>run: hjson CONFIG.json > CONFIG.hjson
>Edit your config
>Whenever you make changes in CONFIG.hjson you need to update CONFIG.json.
>run: hjson -j CONFIG.hjson > CONFIG.json
А можно сделать себе сборочку Godot + Hjson...
>>905392
>{"Хз":"как","можно":"писать","не":"на","json":"."}
Пофиксил тебя.
>Есть миллиарды инструментов
>Зато костыли никакие не нужны
Ты не понимаешь, что эти инструменты - костыли?
Я просто предлагаю лучший из всех этих костылей.
>>905503
Какая разница в каком формате хранить, если все равно придешь к написанию редактора диалогов?
Кто-нибудь, исправьте "Вперёд+" на "Передовой+"...
https://wooordhunt.ru/word/forward
>придешь к написанию редактора диалогов
А зачем? Это как визуальный язык вместо обычного текстового - вечно суют куда попало, а на практике написать несколько строк текстом всё равно проще.
>Но вы мешаете данные и логику.
Это суть ООП: данные + логика = объекты.
>Вы не видите разницы между скиллами как данными и скиллами как эффектами, которые они порождают при их применении.
Не вижу. Если у мага навык позволяет стрелять огненными шарами, это то же самое, что оружие в шутере, только без явно видимого оружия в руках.
Если ты делаешь пистолет в шутере, ты сделаешь сцену pistol.tscn, в которой скрипт генерирует все пульки, рейкасты, вспышки света, дым и т.д.
Так и с навыками. Считай, это биомодификации.
>приведет вас к производственному аду
К аду приводят преждевременные оптимизации, когда такие как ты прибивают гвоздями что-то к чему-то, а потом пистолет не пистолет и пульки из жопы вылетают, а не с кончика ствола.
Оптимизация - это всегда жертва чем-то. В данном случае в жертву приносится удобство разработки - вместо простого и понятного пистолета, который одинаково надёжно стреляет, где бы ни оказался, предлагается накрутить какую-то оптимизацию...
Потому что графы, стейтмашины, последовательности событий, квесты, диалоги как подмножество, удобнее редактировать лапшой.
Проблема в переносимости кастомных форматов лапши.
Тут мог бы помочь какой то фокус с спец текстовым форматом, изменения в котором подхватывались бы в визуальном, и редактирование визуала вносило строчки в текст.
Ты прибил пистолет к волшебнику и лишил себя возможности сделать скилл, когда волшебник призывает несколько пистолетов в воздухе, стреляющих по разным целям.
Есть несколько перетаскиваемых объектов которые можно кинуть в одну зону, они в зависимости от типа увеличат нужную переменную на 1 и вернутся на место.
Соприкосновение с зоной находить я научился, но не могу понять как можно отловить когда объект не держат, за основу брал код из какого-то пиндосского гайда+писал наспех, поэтому не бейте. https://pastebin.com/9iVGjPii
Так, похоже сам нашёл проблему, selected всё ещё true когда вызывается area_entered, похоже просто нужно завести какую-то переменную для соприкосновения и перевести всё в процесс-функции, звиняюсь за мудозвонство и спам-постинг.
> run: hjson CONFIG.json > CONFIG.hjson
Хмм... Почти убедительно, кроме небольшой детали. Ровно то же самое я могу делать в редакторе, только вместо консольной команды, у меня возможность прямо в скрипте описать словарь в джавовском стиле:
>var config = {
>>key1 = 123,
>>key2 = {
>>>key_x = 12,
>>>key_y = 24
>>}
>>key3 = SomeNode.SomeValue
>}
Так кроме того, я могу привязать часть значений прямо к внутриигровым переменным. Затем одной строчкой я получаю жсон-строку на сохранение или передачу. От забытых запятых меня защитит встроенная проверка синтаксиса. Если мне нужны ключи в виде цифр или ключевых слов, то описываю словарь в стиле словаря.
>var config = {
>>"321" : 123,
>>"onready" : {
>>>"tool" : 12,
>>>"signal" : 24
>>}
>>"func" : SomeNode.SomeValue
>}
> удобнее редактировать лапшой
Создатель Dialogic предоставил еще более удобное редактирование - ивентщитом, так же известным как скретч. Это когда поток логики пишется сверху вниз специальными стыкующимися блоками, при этом есть блок-область, так же известный как С-блок, в который вкладываются другие блоки слева-направо.
Узнали? Согласны?
Есть лучше вариант. Внедряем в годот программирование с помощью машины Тьюринга.
Такой блочный подход в рпг мейкер используется. Жутко неудобная штука для больших, разветвленных диалогов
Всё норм. Иногда нужно запостить проблему, чтобы её самостоятельно решить. Сам такой же.
>>905514
Нихуя вообще. Если пистолет это нода, то ему плевать вообще, в руках он или в воздухе. Он же сам стреляет. Просто делаем скилл, в котором несколько пистолетов, например.
>влом линкать все посты с обуждением форматов хранения данных
Эх, годаны. Сразу видно - у вас луа нормального не было. Луашники ВСЁ хранят в луа. Скрипты на луа, конечно. Конфиги - тоже луа. Всякие там сцены или что-то типа того - на луа. И им абсолютно норм. Если бы в Годо был луа вместо гдскрипта, то гарантирую - все tscn и tres файлы были бы написаны на луа. Я уверен, дай луашникам такую возможность, они бы и графику хранили в луа.
Суть-то в чём. Разделение данных и логики - оно в голове программиста, а не в системах. Если у меня пачка файлов, одни из которых скрипты, а другие данные, я могу просто положить одни в папку scripts, а другие в папку data, и всё! Я разделиль. В соло или в очень маленькой команде этого будет достаточно. Все пляски с построением уровня абстракции между логикой и данными начинаются тогда, когда это разделение надо расшарить между несколькими кодерами, причём с рассчётом на некоторую текучку кадров. Тогда и желательно строить и сллой абстракции от движка, на всякий случай. Но если я в солямбу пилю условный проект на итч - мне эти все пляски не нужны. Для такого следует использовать по максимуму встроенные средства движка.
Я кончил.
Забыл упомянуть, что в настройках проекта плагин включил и затем экспортировал.
Я тебе его вроде и предлагал попробовать, там и дальнейшие шаги были - просить техсаппорт включить на сервере или перекатываться на 3
Да, тебе нужна галка shared buffer array. Она должна быть на платформе, на которую заливаешь. Если у яндекса нет, то он хуй.
Альтернативно ты можешь попытаться избавиться от необходимости в в этой изоляции. В тройке изоляция была нужна если ты экспортишь под веб с тредами - выбиралось в опциях экспорта в годоте. В четверке не знаю, но возможно аналогично.
Про плагины не знаю.
Я убил пол дня, но сделал супер примитивную систему диалогов. В начале не знал что такое словари, массивы и тем более синглтоны, но по документации и гайдам чуть чуть разобрался. Подгрузку файлов диалогов я откровенно не осилил, поэтому вписал диалог прямо в скрипт нпс. Система поддерживает максимум 2 говорящих, никаких условий, выборов и прочего нет. Но я добился того, чего хотел: оно хотя бы работает, по ентеру следующая реплика, пауза во время диалога. Еще хочу добавить подгрузку спрайта под говорящего и забить пока хуй и заняться другими аспектами, а то заебали меня эти диалоги.
> Жутко неудобная штука для больших, разветвленных диалогов
Приведи пример. На Диалоджике. В чём неудобство?
> Если бы в Годо был луа вместо гдскрипта
Есть же. И где твои игры?
https://github.com/gilzoide/godot-lua-pluginscript
Он так всем нужен, как я погляжу, что его до сих пор на 4.х не портировали.
Не пользовался диалоджик, но выглядит так, что так очень геморно будет прыгать из одной ветки в другую и создавать альтернативные пути развития в зависимости от провала/успеха скиллчека, пола персонажа и т.д
> но выглядит так, что так очень геморно будет
Ничего подобного.
И результат.
А это тут к чему? Прямой, как палка, диалог он вывезет, ясно дело, и легко. Я про тот вариант, когда ты идешь по одной ветке диалогов и надо переключиться на другую.
Ветка 1
Ветка 2
> надо переключиться на другую
Я про такие переходы. Когда из пойти в кино можно вырулить на "я б вдул".
И вот про это я говорю. Пипец неудобно. Чтоб отследить куда ты прыгнул нужно искать лейбел, вместо простой и понятной связи.
Ладно бы просто неудобно. Я щас попытался твой скрин в диаложэике написать и обломался. Там ярлыки не работают. Бета версия, хуле. Либо я тупоя и не понял великий замысел копполы эмилио Такшта, да. Либо ждать, либо своё пилить.
> нужно искать лейбел, вместо простой и понятной связи
И кстати, если у тебя аналогичная твоему скрину лапша будет простираться на три экрана вправо и на десять экранов вниз, ты тоже заебёшься искать "простую и понятную связь".
Вот я и решил, что лучше запилить своё. Мне и лапша кажется удобнее и поддерживаю я сам, а не жду, пока разработчик снизойдет.
>>905628
Тут я могу сделать одну из двух вещей: 1) Уменьшу размер окна и пройду по линии. 2) Кликну на линию и перемещусь к месту, куда она ведет.
Неа. Это делается одним широким движением (колесико для зумаута, проследить мышкой путь, колесиком зум ин)
>>905629
Могу предложить вот такой аддон от японца https://github.com/nagidev/DialogueNodes
И опять же главный минус современной лапши, она движется слева направо, хотя у тебя в блок схеме >>905621 прописано движение сверху вниз. Это главная проблема всей лапши от анриала, до блендера, годота, и т.п.
Почему-то среди разрабов утвердилось ошибочное мнение, что направлять поток логики справа-налево лучше, чем двигать его адаптивно. Никто из тех кого я видел, не пытается делать адаптивную лапшу. Если второй блок снизу - линия проводится вниз. Если второй блок слева, линия проводится влево. Нет. Линия выходных пинов жёстко прибита гвоздями к левой границе блока.
Смотри как уёбищно:
Сам не понимаю такого подхода. У меня, вообще, линии выходят из центра блока потому их, думаю, можно назвать адативными. Но мне удобнее всего строить сверху вниз
> У меня
Ну ты это где нарисовал? Пейнт? Фотошоп? Это понятно, нарисовать можно как угодно, но это останется рисунком. Проблема в том, чтобы рисунок грамотно воспроизвести в программной среде. Чтобы не потерять суть. А с этим-то как раз в 2к23 проблемы.
Я как-то набрасывал концепт нод-ориентированной-граф-лапши, у которой адаптивные входные и выходные пины ездят по границам блока вслед за линией. Но. Лень матушка. Эххх.
Это редактор диалогов, который я написал для своей игры. Написал на годоте, кстати
Подожди. Ты другой анон. С предыдущим аноном я беседовал, который годот позавчера установил и ни черта не шарил.
А на твой редактор я бы взглянул. Скинешь сорцы?
> можно назвать адативными
АдаПтивными.
Проверочное слово - адаптация.
Я б скинул, но я черт знает куда залить, чтоб нельзя было сдеанонить меня да, я капец мнительный
>>905644
Забавная очепятка получилась
>И где твои игры?
Прямо сейчас готовлю к релизу на ЯИ и пытаюсь вкурить, как правильно подключить переключение в фуллскрин через сдк, ибо жабаскрипта я не знаю.
А луа на Годо действительно не нужен. Там нет полноценного ООП, можно разве что собрать костыльно-велоипедный аналог. Как бы я ни любил луа, но конкретно тут он не нужен. Гдскрипт умеет всё то же самое, но лучше. Разве что в тройке немножко не хватает типа callable.
Касательно приведённой тобой ссылки. Там нет поддержки луа 5.2+, но это терпимо. Главное - там нет поддержки дебажных коллбэков. Исполнение останавливается из-за ошибки, но что за ошибка и в каком месте кода - гадай сам. Это пиздец, так работать невозможно.
> куда залить, чтоб нельзя было сдеанонить
В топ-5 конкурентов anonfiles.com, по данным на сентябрь 2023, входят gofile.io, mega.nz, mediafire.com, 1fichier.com и другие сайты.
Пакуешь в архив с паролем. Пароль - стандартный. 2ch Архив на любой бесплатный файлообменник. Ссылку сюда.
>Почти убедительно, кроме небольшой детали. Ровно то же самое я могу делать в редакторе
>>var config = {
>>>key1 = 123,
>>>key2 = {
При чём тут GDScript? Речь шла про скрипты для сценариста/писателя, который будет их тебе писать.
Это просто дополнительный слой абстракции.
Мне зашла система типажей раста (которая не растом придумана, офк). Уже джва месяца восхищаюсь этой идеей. Это ж как охуенно придумали, и почему я раньше об этом не узнал?
И главное, я размышлял, вот есть структы и классы, но зачем? Вот были бы только структы, а вместо классов интерфейсы, в которых объявляются методы, а потом ты пишешь что-то типа
> var foo = new IMyInterface<MyStruct>(); #псевдошарп
то есть, чтобы к интерфейсу с методами при создании инстанса биндился подходящий структ. Но никто мне не подсказал. На раст и на системы типажей (трейтов) я наткнулся случайно, гугля совершенно другое.
Вроде они это из Го спиздили. Когда Го учил натолкнулся на это и тоже впечатлился, просто свежий воздух после душных классов плюсов/сисярпа.
>>905617 >>905621
>>905634 >>905635
Чем это лучше пикрила?
P R O T I P: use [ Ctrl ] + [ F ].
Тем, что у тебя вообще невозможно проследить возможные пути.
>Бывает лишь подходящее тебе
Так можно любое обсуждение прервать.
>>905697
>Хорошая, годная утилита
Не понял, ты про Hjson?
>>905767
>вообще невозможно проследить возможные пути
Если ты не можешь последить пути в такой простой текстовой записи, то это с тобой что-то не так. Как ты вообще код пишешь? В коде постоянно есть "возможные пути" (вызовы функций, обращения к полям класса и т.д.), но ты как-то их видишь без подсказок. VisualScript убрали за ненадобностью и правильно сделали - от подобной визуализации кода толку нет, она только вводит в заблуждение и мешает освоить нормальный кодинг.
В принципе, можно автоматически генерировать визуализацию графа, но есть один нюанс: сколь-либо сложная история визуально будет таким хаосом, что толку от визуализации не будет, как нет толку от хаотичной визуальной лапши императивного кода. Вот даже эта история на 10 нод оказалась визуально сложнее, чем я предполагал, а ведь я писал простым текстом и "отлаживал" мысленно без визуализации (представлял только GUI визуальной новеллы с точки зрения игрока, "играя" мысленно).
Написание интерактивных историй по сути не отличается от процедурного программирования: линейный код = линейная история, if/match = развилки, for/while = повторы, процедуры = странички/реплики. В коде визуализации не нужны, так зачем визуализация интерактивных историй?
Отдельный скриптовый язык нужен только как абстракция над конкретным движком, т.е. вот такой скрипт на скриншоте будет легче перенести на другой движок и легче его составлять, не задумываясь о нюансах реализации (как движок будет рендерить сцены, как он будет запрашивать ввод у игрока и т.д.). А так, хоть на ассемблере пиши интерактивные истории, суть не изменится, только портировать будет намного сложнее.
>сложнее, чем я предполагал
Ладно, это из-за того, что я от руки рисовал.
>автоматически генерировать
Вот, например: https://mermaid.js.org/
Можно подключить аддоном к TiddlyWiki, чтобы совместить с вики-диздоком игры:
https://github.com/efurlanm/mermaid-tw5
Но всё равно... В чём польза? Смотря на этот граф, можно представить себе обычную программу с несколькими if-else и одним большим циклом while true. Не вижу пользы от такого рода визуализаций, если пишешь историю сам. Может быть, для командной работы оно бы имело какой-то смысл, типа, видеть кто сколько лапши на вилки накрутить успел, или чтобы похвастаться своей лапшой перед товарищами. Но командная писанина - это уже совершенно отдельная тема.
Да, я пробовал использовать графические редакторы. Неудобно. Все эти визуализации растягиваются на огромное полотно и ты больше возишься с GUI редактора, чем печатаешь текст. Нет того UX, который ожидаешь от полезного и удобного инструмента; постоянное ощущение борьбы с костылями (особенно когда нет поддержки привычных стрелочек, таба, энтер и т.д.). Поэтому я несколько раз придумывал свои велосипеды...
Большое преимущество набора текста в том, что можно печатать в любом, даже самом примитивном редакторе текста, на любом устройстве. Те же аддоны для Godot требуют сам Godot, верно? А текстовый файл ты можешь на ходу печатать без Godot. Потом скинешь на компьютер и, если очень сильно надо, сделаешь визуализацию или конвертацию в другой формат. Но чтобы это было удобно, формат записи должен быть удобен для ручной записи, никакого XML с его тегами, GDScript с кучей длинных имён функций и т.п. - т.е. нужен свой формат/язык.
так это нам кодерам, сценаристам проще таскать полотно с нодами графа, колесиком масштабировать и мышкой тыкоть в нужные поля для заполнения
Сходу сразу видно два преимущества
1. Видно сколько и откуда ВХОДИТ в ноду. Изначальный текст явно описывает только выходы.
2. Видны обходные пути целиком. В исходном тексте видно только выходы, чтобы узнать, что они сойдутся, надо скакать по всему файлу.
В коде есть удобные инструменты, такие как вынос в функцию или инкапсуляция в объект. Тогда ифы остаются компактными. Еще есть сворачивание блоков кода в ide. Но такой блок не свернуть, вернее он свернется целиком, и информации о связях скроются.
Откат у меня сделан несколько лет назад, откатил твой откат
Случайно неловким движением тачпада перетащил папку scenes в другое место, и это хуйня не только не спросила, хочу ли я вообще это делать, так она мне перелопатила зависимости сцен под это перемещение, сохранила проект и отказалась делать ctrl+z; но по опончании перемещения всё-таки выругалась, что что-то там не может сохранить. А при обратном перемещении пересохранила часть, но не пересохранила другую. Ну и конечно же последний бэкап я делал давно, потому что ну что может пойти не так?
Спрашивается: какого хуя перед таким массивным изменением, которое можно сделать абсолютно случайно одним движением пальца, не вылезает какого-то предупредительного окошка?
Сочуствую. Как говорится, есть те, кто не делают бэкапов, те. кто уже делает, и те, кто делают их регулярно, а еще проверяют восстанавливаемость. Что же касается твоей претензии, хз как это можно разрулить. Можно попробовать написать аддон который будет блочить операции над файлами, или патч в сам редактор.
>Ну и конечно же последний бэкап я делал давно, потому что ну что может пойти не так?
Вот почему надо вести свой проект в git даже если ты работаешь один, и рубить изменения на небольшие коммиты.
От того что ты в гит переедешь дисциплина не появится. Раньше бекапы не делал, теперь коммитить не будешь. А когда завалишься с конфликтующими изменениями - вообще забьешь.
Работаю с гитом больше 5 лет со своими и чужими проектами, хз. Наверное то что я начинал вообще с проектов в опенсурсе меня многому научило.
А так skill issue.
А какая разница, гит или зип, если "ладно, потом забэкаплю"?
>>905884
Меня удивляет другое. Схуяли всё сохраняется без явной на то команды? Почему бы перед таким изменением не высветить хотя бы "Для продолжения потребуется сохранить проект и все открытые сцены. [Продолжить][отмена]".
>>905887
А что в тачпаде не так? Сижу с ноутом в кресле, обложившись подушками. Удобно. Мышь в таком положении не подключить.
>А какая разница, гит или зип, если "ладно, потом забэкаплю"?
Потому что это система контроля версий, адекватная и проверенная.
Я не знаю как вы тут вообще живете без гита нахуй. Сломал проект жирным багом - откатил назад (сделал чекаут) - узнал в каком коммите ты насрал себе в штаны - дебажишь именно эти изменения. И это минимум того что им можно делать, я уж не говорю о том что другого человека на проект позвать с минимум ебли или как вообще релизы делать хоть куда-то без гита.
Гит это не единственная система контроля версий, но самая популярная. Пиздуйте знакомится чтоб не быть как вон тот анон >>905878 благо там за пару часов разобраться можно.
Из клиентов для начала есть базовый клиент Гитхаба, но он трехкнопочный и мало что может. Впрочем для работы в соляну самое то, нахуя тебе конфликты мержа вообще резолвить если ты делаешь все в одной ветке скорее всего. Тупо сри малыми порциями в мастер/мейн.
Вырезаю текстуру из атласа, накладываю на нее шейдер аутлайна.
В этой ситуации шейдится весь атлас целиком, как я понял? Он довольно большой, наверняка жрет немало.
Я бы хотел шейдить только отдельные куски, как этого добиться?
Git похож на c++. Или на ffmpeg. Пока пользуешься им в поверхностном режиме, ну там только clone или только add/commit то все хорошо. Как только что-то сложнее такие танцы с бубном начинаются. То HEAD куда то слетит то не дает ничего делать ругаясь на какие-нибудь конфликты. Помню, даже отказаться от несохраненных изменений сложнее, чем сохранить их и откатить. Вырезать предпоследнее изменение тоже был веселый квест.
Но вот самая жесть была когда я попробовал впервые за 3 года разрабатывать как у серьезных людей, с фиче-ветками. Создал я ветку на фичу, что-то дописал, а потом увидел пару косяков в другом месте и походу исправил. Ну и результат понятен, фичеветка забивается нерелейтедом, а если переключиться то эти фиксы надо вспоминать и черрипикать. Ну в самом деле получается что мне исправление это пару кнопок за секунду нажать, но для этого надо по минуте между ветками переключаться.
>Как только что-то сложнее такие танцы с бубном начинаются.
Простейшие конфликты резолвятся без проблем если делать мерж через гит клиент, регулярно делаю это сам на работе. Просто через IDE смотреть где насрано и вилкой чистить каждый раз, а гит клиент потом тебе соберет мерж коммит.
>Но вот самая жесть была когда я попробовал впервые за 3 года разрабатывать как у серьезных людей, с фиче-ветками. Создал я ветку на фичу, что-то дописал, а потом увидел пару косяков в другом месте и походу исправил. Ну и результат понятен, фичеветка забивается нерелейтедом, а если переключиться то эти фиксы надо вспоминать и черрипикать.
У тебя должна быть одна ветка dev в которую ты стабильно льешь все говно, и ты мержишь её в свои фичеветки. Чтобы служить как раз таки центром для всех этих фиксов. Гит он не для того чтобы делать разветвления и сидеть на разных ветках месяцами, отличия накапливаются и их нужно регулярно резолвить.
Но опять же, солодевелоперу это нахуй не нужно. Тупо ветка для работы и ветка для релизов, dev и main, так и сидишь.
/r/ мастер-класс по гиту. Моё взаимодействие с ним ограничивается заливкой кода через веб-морду, чтобы этот код заопенсурсить. Пытался по гайдам в более сложные взаимодействия - не понял, как и зачем. В итоге сломал об него зубы и забил.
Гит это профессиональный инструмент, которым при умелом использовании можно увеличить член, но при неумелом получится скорее его отстрелить. Как всякий профессиональный инструмент, он вываливает перед тобой весь свой функционал и предполагает, что ты знаешь, зачем это тебе нужно, в каких ситуациях и как этим всем пользоваться.
>>905915
Никак. Нет, серьёзно, я сталкивался буквально с этой же проблемой. При использовании атласов (спрайтшитов, текстур с кадрами анимаци и т.п.) шейдеру отдаётся весь атлас целиком, и это никак не изменить. Ты разве что можешь силами гдскрипта вырезать нужный тебе кусок, создать из него новую текстуру и скормить её шейдеру. Но выглядит не очень рационально.
"Дизайн должен быть функциональным, а функциональность должна быть переведена в визуальную эстетику, без какой-либо зависимости от трюков, которые необходимо объяснять."
>не понял, как и зачем
Твой код - это многомерное фрактальное дерево правок и исправлений, реализующих полёт твоей мысли. Чтобы уместить это дерево в сколь бы то ни было удобоваримом виде, придуманы системы контроля версий. Ну и конечно же для коллаборации команд, у которых Лебедь кодит вверх, Рак кодит в сторону, Шука кодит вниз, а продукт должен работать.
Ты ничего не понял? Оттож.
От гита тебе на начальном этапе нужно выучить три команды:
1. Залогиниться в гит-хабе.
2. Отправить проект в репозиторий.
3. Скачать проект из репозитория.
Я надеюсь ты пробовал ставить любой ui гит клиент (соурстри всякие, форки и т.д.) или ты чисто с башем сидишь?
Если ставил, то я не понимаю что с тобой не так, там 3-4 кнопки жмешь и ещё столько же при черепиках, обновлении подмодулей и прочих не частых операциях
Если кто-то говорит, что только консоль тру, шли нахуй
Для годота есть официальный гит плагин.
Есть подводный - если кликнуть на коммит с большим бинарным изменением, например импортом 3д уровня, можно надолго идти пить кофе.
Игры делайте
>коммит с большим бинарным изменением, например импортом 3д уровня
А зачем бинарные данные в гите? Они отдельно должны быть, разве нет? Максимум иконки, но не огромные файлы на несколько мегабайт данных...
>встроенный браузер файлов
Пользуюсь им только для составления новых сцен их сохранённых сцен. В остальном он не нужен. Перенос файлов осуществляю через проводник Windows.
Глючность встроенного менеджера файлов хорошо известна уже много лет. Ньюфаги охреневают, но на практике такие же проблемы что у Unity, что у UE. Рекомендуется вообще файлы проекта не двигать, чтобы не было таких последствий. В 4.0 начали реализовывать систему UID, но она тоже пока что (на момент 4.1) глючная и доставляет проблем, а главное - теперь вручную tscn сложнее фиксить.
>Случайно неловким движением тачпада
Рекомендую выключить жест "тап == клик" или "двойной так == захват для переноса", чтобы избегать подобных проблем. Пользуйся физической кнопкой для кликов, она должна быть жёсткой и поэтому не так сильно подвержена случайностям.
>Ну и конечно же последний бэкап я делал давно, потому что ну что может пойти не так?
Почему? Храни файлы данных в другом месте, а код всего проекта будет занимать очень мало места. Я настроил шорткаты, чтобы в два клика делать бекап.
>перед таким массивным изменением, которое можно сделать абсолютно случайно одним движением пальца, не вылезает какого-то предупредительного окошка
Потому что в идеале это массивное изменение не должно приводить к каким-либо негативным последствиям. То есть, если бы всё работало без ошибок, случайный перенос можно было бы вернуть обратно простым переносом файла. Беда в том, что какие-то скрытые ошибки ломают процесс переноса файлов, даже если ты всего один файл переносишь.
>>905910
>Схуяли всё сохраняется без явной на то команды? Почему бы перед таким изменением не высветить хотя бы "Для продолжения потребуется сохранить проект и все открытые сцены.
А что такого в сохранении? Меня больше удивляет, почему кто-то работает с проектом, ничего долго не сохраняя. Это же гарантированный путь к фейлу по множеству причин. В идеале проект и все файлы должны автоматически сохраняться на диск спустя несколько секунд после внесения изменений.
Неоднократно сталкивался с тем, что настроил новую большую сцену и забыл её сохранить, редактор из-за какой-то ошибки крашнулся и ничего не сохранилось - пришлось воссоздавать сцену с нуля по памяти.
Если ты хочешь поработать над чем-то и затем это удалить, просто сделай копию файлов/проекта.
>А зачем бинарные данные в гите? Они отдельно должны быть, разве нет?
Ну тебе историю проекта как-то хранить надо же. Хз, у Юнити и гитом такая же трабла, всем похуй пока размер истории коммитов не превышает лимиты гитхаба. Тогда просто срезают историю.
>Я не знаю как вы тут вообще живете без гита
Нормально. Просто нужно следовать этому подходу:
https://ru.wikipedia.org/wiki/Итеративная_разработка
Тогда ты не будешь высирать 100500 строк кода без единого теста, а потом "ой, что-то не работает, но я понятия не имею, что". Очевидно, если ты высрал строчку кода и что-то сломал, виновата эта строчка, ведь все остальные части проекта тесты проходят.
Godot идеально подходит для этого. Ты разделяешь проект на множество независимых частей, каждая из которых способна существовать отдельно от других, и поэтому её можно разработать и протестировать независимо от остального проекта. У тебя нет шанса обосраться где-то и не заметить этого, а если ты даже обосрёшься, твой обсёр изолирован в небольшом фрагменте, без которого проект может работать.
>узнал в каком коммите ты насрал себе в штаны
Зачем делать коммит, если ты только что обосрался?
>другого человека на проект позвать
Чтобы он свои грязные ручонки в мой идеальный, красивый, любимый код совал? NO WAY!
>историю проекта как-то хранить
Зачем мне в истории проекта все обновления .blend весом несколько десятков мегабайт? Если нужны промежуточные версии .blend, я сохраню их отдельно от файлов/бэкапов/гита проекта.
>Зачем мне в истории проекта все обновления .blend весом несколько десятков мегабайт?
Ну так не лей в главную ветку свои промежуточные изменения, делай мерж с модельками сквошем (хотя это фича ГИТХАБА а не ГИТа, что важно) и удаляй ветку где ты перебирал варианты модельки.
>Зачем делать коммит, если ты только что обосрался?
Это порой можно понять только на тестах других людей 10 коммитов спустя.
Работал в геймдеве на нескольких кабанов в команде, имею опыт именно коллективной разработки больше чем у многих тут. При этом 99% времени в гите использую 3,5 кнопки, лишь в 1% требуется открыть консоль и выебнуться, и то исключительно из-за обсера коллектива.
В гите нет нихуя сложного и страшного. Хватит людей пугать, о ужас, десятком мегабайт в истории.
>Хватит людей пугать
Я не пытаюсь никого напугать. Если убедишь, что гит жизненно необходим любому хелло ворлду, тогда я и сам буду его использовать. Пока что не убедил.
>делай мерж с модельками сквошем
>ветку где ты перебирал варианты модельки
Ещё раз, зачем коммитить модельки в репозиторий? Неоднократно видел опенсурс игры, где пакет ресурсов находится где-то отдельно от скриптов.
>понять только на тестах других людей
Тогда это уже проблема специфического железа, а не конкретной игры. Или какой-то скрытый баг, который большинство игроков никогда не встретит. Пока это не влияет на всех и сразу, это, считай, не баг. Иначе ПО вообще никогда бы не релизили...
>10 коммитов спустя
У меня это будет 1.5 недели работы. Мне что, 1.5 недели удалить ради поиска бага, который никто кроме одного игрока не нашёл? Как я за 1.5 недели сам не заметил баг, а другой игрок нашёл, требуя откат всей моей работы почти на две недели?
Покажи на примере, где гит полезен и затраты на его поддержку окупаются - т.е. лишняя работа сейчас компенсируется автоматизацией в будущем.
Вот представим, я перепутал значение переменной и персонаж в игре улетает в небо с одного тычка, как мне гит поможет? Мне для исправления проблемы достаточно одну переменную поменять, зачем мне откатывать все файлы проекта, в которых могли быть сотни изменений после этой переменной? А главное, если я не знаю причину проблемы, как мне поможет откат всего проекта найти эту причину?
>Мне что, 1.5 недели удалить ради поиска бага
Наркоман. Тебе другое предлагается.
Нужно просто сделать чекаут на несколько коммитов вглубь и посмотреть где именно жопа отваливается, на каком коммите именно. Моментально локализуешь проблему до небольшого коммита и сможешь её исправить уже путем исключения из того кода что ты писал.
При том не надо сидеть пердеть и думать чтож там такое могло сломаться, это 100% рабочий способ исправлять любое сложное говно, который нужен в арсенале любого разраба.
Разумеется, большую часть времени баги очевидны и это делать не нужно. Но этот метод на случай когда тебе грозит 3-4 часа дебага туманного говна.
>Как я за 1.5 недели сам не заметил баг, а другой игрок нашёл, требуя откат всей моей работы почти на две недели?
Запросто если ты делаешь проект сложнее чем симулятор унитаза или визуальной новеллы про Семена в гулаге. Чем больше проект, тем больше такой хуйни лезет.
Не знать гита и быть программистом это все равно что не знать английского и быть программистом. Жить можно, но нахуй так жить?
>Пока это не влияет на всех и сразу, это, считай, не баг.
Проиграл с тебя
мимо-QA
>зачем мне откатывать все файлы проекта, в которых могли быть сотни изменений после этой переменной? А главное, если я не знаю причину проблемы, как мне поможет откат всего проекта найти эту причину?
Поможет если делаешь часто небольшие коммиты, а не всё сразу раз в месяц.
К сожалению да, это зафоршенная херота которую необходимо знать. Как маркдаун или cmake, притом что они крайне неудачные инструменты, но слишком популярные.
>>906007
>Хватит людей пугать
Гит работает хорошо, пока не косячнет или ты не косячнешь. А потом начинается не то что пугать, а натральный хоррор. Иногда проще было скопировать папку, руками сделать дифф всех файлов, и сделать новый коммит с готовых файлов.
Можно ходить. Можно тыкать на объекты на кнопку E, сидеть на стуле. Можно разговаривать с персонажами и даже включить телевизор.
https://www.mediafire.com/file/24n6nxc6i24yf0r/WatermelonBarGame.zip/file
А вот тут исходники проекта в Годоте
https://www.mediafire.com/file/m7jb5i5043deewe/WatermelonBar.zip/file
Что б пост был не бесполезным, поделюсь проблемами, которые возникли с моим первым проектом на Годот.
1.На Леново Х230 разъёбывает скелеты персонажей.
Очень долго ходил вокруг этой проблемы. Пытался делать свой скелет в ручную, качал чужие с Миксамо. А оказалось что просто запускаешь проект на нормальном компе и там всё работает!
А вот на древней встройке нихуя. Не используйте скелеты на древних встройках на Годоте.
2.Годот предлагает три рендера. Для калькуляторов, для телефонов и для людей.
На рендере для калькуляторов у меня нормально работает телевизор. Показывает и видео и звук.
На рендере Форвард+ звук есть, а вот видеотекстура на кубике нихуя не кажет!
3.Если на одной модели у тебя два объекта и у каждой анимация, то их не получается проиграть одновременно.
Пример. Стоит Двач-тян, у неё в руках кружка. Кружка отдельн о и Двач-тян отдельно. И обе этих анимации не запускались одновременно.
Способ простой - пришить кружку к руке намертво, сделав её частью тела персонажа.
Способ сложный - сделать второй аниматор и во второй аниматор скопировать анимацию из первого, а в первом удалить.
Я пока что придумал сделать ноду которая забирает весь инпут и посылает сигналы в игру.
Нажимаешь кнопку, эта нода смотрит на какое действие ты забиндил эту кнопку - например, нажимаешь W - идет сигнал ноде игрока чтобы подвинулась вперед немного.
Как идея?
ты так гришь, будто в годоте нет встроенного ребиндинга, лул
>А вот на древней встройке нихуя. Не используйте скелеты на древних встройках на Годоте.
Там сейчас вроде слой совместимости с говном мамонта пилят.
Модельки сам делал? В блендере? Не заебался столько моделить ради двачедемки? А вообще молодца.
бля, действительно есть.
Я почему-то думал что это только в настройках проекта ставится.
>Модельки сам делал?
Да, все модельки делал сам, в блендере.
Кроме Чёрного Властелина и Двач-тян. Они были сгенерированы в Мейк Хюман.
Выбрал его как бесплатную свободную замену Метахьюману. Ну и, за бесплатно результат очевиден. Мейк Хьюману до Метахьюмана как до луны пешком.
>А что такого в сохранении?
То, что я не хочу сохранять ЭТИ изменения. Я хочу их откатить взад. А они уже сохранились. Тащемта, я обычно сохраняюсь чуть ли не после каждого напечатанного слова. Но если что-то сделано случайно, так хотя бы не сохранять.
Сегодня досматриваю сериал, потом запланировал просмотр трилогии одной, так что вряд ли получится раздуплиться, может завтра.
Сначала читаем доки, если что непонятно, смотрим туториалы, а потом повторно читаем доки. И вот если после этого непонятно, тогда есть смысл вопрошать на форумах.
> Мейк Хьюману до Метахьюмана как до луны пешком
Ну хз, в плане готовыг лицевых анимаций, наверное да. А в целом, вполне сносно моделирует, как по мне.
Еще можно ассеты чекнуть. Штуки 2-3 с настройками кнопок игроком точно было. Хотя красивого не попадалось.
НО у меня есть другой синглтон - менеджер диалогов (пик 2). И когда я посмотрю диалог и после этого меняю сцену например выхожу через дверь, то менеджер сцен удаляет последнюю сцену (диалог - которая итак уже удалена), а не ту что должен по идеи и все идет по пизде, на пик 1 обозначена проблемная строка, но как переделать я не знаю.
Можно поправить логику в той строчке или надо все переделывать и объединять синглтоны?
вроде как ты работаешь через индексы дочерних нод в этой строчке, лучше пока разбираешься так не делай, а присвой ноде с "картами" или что там меняется имя и она будет дочкой рута, потом сделай ноду для диалогов и ее тоже сделай дочкой рута
потом просто у ноды карты будешь удалять все старой и загружать в нее все новое и делать это по ее имени или ссылке
да, в ней
вопрос не понял
но у нас не только годот, есть даже юнька на старых проктах еще поддерживаем на ней, но новые уже не начинаем, дефолд тыкаем, какие-то свои либы пишем, а так основное сейчас годо
https://godotengine.org/article/dev-snapshot-godot-4-2-beta-1/
У тебя какая-то зарубежная компания или рф? Я просто думал пойти в геймдев на годоте, но хз что с вакансиями на нём
1. Прекращай писать транслитом, бесит. Если ты не знаешь каких-то слов, юзай словарь - прокачаешь инглиш заодно, он очень важен в айти и геймдеве.
2. Прекращай писать "if something == true:", я тебе уже объяснял, что это избыточно. Код должен читаться естественно, т.е. следующие записи идентичны:
>если диалог идёт, тогда возврат
>if dialogue_is_ongoing then exit; // Pascal
>if dialogue_is_ongoing: return # GDScript
3. Привыкай писать код без комментариев. Плох тот код, который приходится пояснять в комментариях. Для примера, change_scene_to(path: String) в заголовке явно указывает, что ждёт строку, поэтому лишнего пояснения про кавычки не нужно.
3.1. Комментарии для автоматического генератора документации пишутся в специальном формате:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_documentation_comments.html
4. Метод Object.free() не безопасный, т.к. он удаляет объект сразу. Напротив, Node.queue_free() ставит удаление ноды в очередь, и тогда она продолжит существовать вплоть до конца текущего кадра.
5. Синглтоны вообще рекомендую не использовать. Правильнее сказать, глобальные переменные, ведь Godot не гарантирует, что твоя глобальная сцена не будет создана повторно; он только создаёт ссылку, доступную глобально, а это очень плохо в плане архитектуры - проект превращается в лапшу.
5.1. С этим связана твоя проблема. Ты создал сразу две глобальных сущности и уже успел запутаться в их поведении, хотя они ничего толком не делают. Вот видишь, насколько всё плохо. Не надо так.
Повторюсь в который раз: лучше иметь главную сцену game.tscn и руководить всем сверху вниз (от главного скрипта game.gd), делая снизу вверх (от конкретных игровых объектов) только запросы (сигналы), чем накручивать клубок глобальной лапши, в котором вы быстро запутаетесь.
Глобальные сущности выглядят привлекательно только в самом начале. Потом начинается жесть.
юзаем годот, но совсем не геймдев
сейманы на месте? кроме серёги
> Повторюсь в который раз: лучше иметь главную сцену game.tscn и руководить всем сверху вниз (от главного скрипта game.gd), делая снизу вверх (от конкретных игровых объектов) только запросы (сигналы), чем накручивать клубок глобальной лапши, в котором вы быстро запутаетесь.
> Глобальные сущности выглядят привлекательно только в самом начале. Потом начинается жесть.
В годоте нет синглтонов. Каждая нода-автозагрузка с глобальным именем - это по сути ветка в дереве. Поэтому вышеописанный тобой совет реализуется через get_tree() или как вариант через get_node("/"), которое возвращает то же самое (get_root() аналогично get_node("/root")). Достаточно взглянуть на удалённо приаттаченное дерево при выполнении проекта, чтобы всё это увидеть и осознать. Поэтому "синглтоны" автозагрузки, это просто удобный способ добавить чайлды в "/root". Как ни крути, проект сложнее тетриса, будет обладать специфическими объектами в дереве. Обращаться к ним через имена в автозагрузках, или через главную сцену, как ты предлагаешь "/root/main_scene" - однохуйственно. Разницы нет. Истинная инкапсуляция делается через сигналы. Тольк так менеджеры сцен (локаций, я полагаю) и менеджеры диалогов будут независимы и не вызовут ошибок при выгрузке друг друга.
>>906766
В целом тебе следует ещё раз крепко подумать об архитектуре своего проекта. Я тебе образно опишу, а реализацию гугли сам.
1. Сцены - это семантика движка. Тебе не обязательно придерживаться аналогичной семантики в своей игре. Проще говоря, у тебя может вовсе не быть никаких сцен. И в коде ты это можешь отразить, не называя сценами всё подряд.
2. В исполняющемся проекте есть только одна сцена, которая описана деревом сцены. Scene tree - единственное число, когда в русской документации его переводят "дерево сцен" - это ошибка перевода. Дерево сцен по английски называлось бы scenes tree.
3. Как подсказал анон выше, ты можешь реализовать всю связующую логику в корневом узле дерева, но это ничем не будет отличаться от синглтонов из автозагрузки, просто а) всё сместится на один уровень вниз по дереву сцены (ед.ч.), б) имена переменных, в которые ты загрузишь чайлды самодельного корневого узла, ты будешь описывать сам в скрипте, а не во вкладке автозагрузок редактора.
4. Поскольку п.3. объясняет, что оба варианта однохуйственны, рассмотри вариант реализации в своём проекте шины событий. Это архитектурный паттерн. Он гуглится. Шину событий тоже засовываем в дерево, любым из вариантов п.3. после чего все остальные скрипты не видят ничего кроме шины событий. Они могут подписываться на излучаемые шиной сигналы. Они могут заставлять излучать шину сигналы. Сигналы можно излучать с аргументами. Аргументы можно передавать ссылочными типами (например, словарём). Таким образом разные инкапсулированные в себе и скрытые друг от друга ноды через сигналы смогут обмениваться полноценной инфой, но при этом никак не вредить друг другу. Если нода выгрузилась, она просо не отреагирует на сигнал.
Щас попробую в общих чертах изобразить тебе скриншотами твой код, переписанный на шину событий.
Я другой анон, но блять.
>Прекращай писать "if something == true:"
Раздражает подобное написание. Читается плохо, глаз не сразу улавливает суть ифа. Хотя булевские таки да, сравнивать с труъ избыточно, но это экономия на спичках.
Больше этого меня раздражает разве что "if !something". Три знака экономия, зато потенциальное место для ошибки по слепошарости.
>Привыкай писать код без комментариев.
Сразу нахуй. Стена кода без комментов - это нечитаемое говно. Да, код писать надо сразу такой, чтобы его сходу можно было понять без комментариев. Но писать их, тем не менее, всё равно необходимо, чтобы улучшить читаемость.
>Синглтоны вообще рекомендую не использовать
А, ты из этих.
Вот иллюстрация, о чём я надлиннопостил.
А потом ты начинаешь эмиттить сигналы по необходимости:
> Стена кода без комментов
В одном месте прочитал хороший совет - коммент должен быть про то, зачем делают, а не какие действия делают.
Иначе комент становится дублем кода
Плохой пример
scene.instance() #инстанцируем сцену - кэп!
Хороший пример
scene.instance() #спавним пулю
В идеале меняем на то, чтобы коменты были не нужны
bulletscene.instance()
Но тут уже могут быть коменты именно о том почему это делается здесь
bulletscene.instance() #нам нужна эта сцена чтобы потом вычислить вектор для прицела
Я сегодня сделал три нормы за смену. А теперь я пойду спать.
>Читается плохо, глаз не сразу улавливает суть
Что тебе плохо читается? Слова английского языка? Тогда на русском пиши, Godot поддерживает Unicode.
>экономия на спичках
Дело не в экономии, а в том, что "== true" почём зря цепляет взгляд, затрудняя чтение/понимание кода.
>if !something
Это от сишников, они любят спецсимволы вместо читабельных слов. Благо, в GDScript есть слово not.
>Стена кода без комментов
>необходимо, чтобы улучшить читаемость
НЕ ПИШИ НЕЧИТАЕМУЮ СТЕНУ КОДА
@
НЕ ПРИДЁТСЯ ПИСАТЬ СТЕНУ КОММЕНТАРИЕВ
Если ты хочешь написать комментарий - знай, твой код нечитаемое говно, которое нужно переписать. Не всегда, конечно, но чаще всего так и получается.
>А, ты из этих.
Любишь обмазаться глобальными переменными и дрочить на извилистую лапшу в портянках кода?
>>906834
>В годоте нет синглтонов.
Да. Но синглтоны вредны потому, что они глобальны по своей природе. Автозагрузка в Godot как раз даёт возможность сделать глобальную лапшу.
>Каждая нода-автозагрузка с глобальным именем - это по сути ветка в дереве.
Которая провоцирует создание лапши в проекте.
>Поэтому вышеописанный тобой совет реализуется через get_tree() или как вариант через get_node("/"), которое возвращает то же самое (get_root() аналогично get_node("/root")).
Бред какой-то. Не стоит обращаться к вышестоящим системам по имени, это даже в доках замечено. В крайнем случае можешь запрашивать get_parent(), но только один раз - никаких дедов и прадедов.
>Поэтому "синглтоны" автозагрузки, это просто удобный способ добавить чайлды в "/root".
Зачем? З А Ч Е М? Выглядит как древний костыль.
>Как ни крути, проект сложнее тетриса, будет обладать специфическими объектами в дереве.
Я как-то тетрис писал. С глобальными переменными. Забросил, когда осознал, что не могу понять, как оно работает, из-за той туго затянутой глобальной лапши.
>Обращаться к ним через имена в автозагрузках
Повторяю, не нужно этого делать.
>ты предлагаешь "/root/main_scene"
Я этого не предлагал. Обращаться к главной сцене не нужно, потому что она главная. Директора своей компании ты не отвлекаешь от его работы своими бестолковыми приказами, а пишешь письмо, которое передаётся через несколько ступеней иерархии, возможно, теряясь в процессе, потому что ты всего лишь заменимая шестерёнка в системе.
В частности, дверь в игре не должна вызывать переключение сцен. Она должна сообщать наверх о том, что требуется переключение сцен. Произойдёт ли переключение сцен или нет её волновать не должно. Аналогично менеджер диалогов не должен тянуть шаловливые ручонки туда, куда ему не положено, а его, в свою очередь, не должны тянуть за руки NPC.
Новички этого не понимают, а автозагрузка с её глобальными именами наставляет их на ложный путь с кучей граблей и огромным лапшичным монстром. Вообще, get_node() тоже позволяет слишком многое, но это хотя бы "секретная" фича, а не пункт в меню.
>имена переменных, в которые ты загрузишь чайлды самодельного корневого узла
А вот это делать не надо. Но даже если так делать, ты явным образом связываешь свои скрипты, не пряча зависимости куда-то в настройки проекта.
>шины событий
Имхо, это избыточно.
То, что я предлагаю:
1. Предки манипулируют только своими потомками.
2. Потомки только излучают сигналы.
3. Никаких манипуляций с:
3.1. Предками, предками предков и т.д.
3.2. Братьями, дядями, племянниками и т.д.
3.3. Внуками, правнуками и т.д.
В редких случаях можно обращаться к своему родителю напрямую, но это особый случай, который необходимо как-то обозначать, например, нода должна проверять тип родителя и выдавать ошибку в случае, если дизайнер поместил её не туда.
Самое смешное что в С++ в стандарте тоже есть not, and
https://en.cppreference.com/w/cpp/language/operator_alternative
Некоторые очень смешно подрываются, если им показать что такой код валиден на с++
>Если ты хочешь написать комментарий - знай, твой код нечитаемое говно
Да ты даже пост на дваче прочитать не можешь, вот и на комменты не залупайся. Эти два утверждения не противоречат друг другу, но дополняют:
1. Код надо писать такой, чтобы его было легко понять без комментов.
2. Разбавлять стену кода комментами необходимо для читаемости.
Речь не про то, что я пишу код, который непонятный без комментариев. Он понятный. Речь про то, что я оформляю код при помощи комментов, делаю его визуально чище, логичнее на уровне расположения элементов. Комменты в таком отношении это скорее заголовки, а код - контент.
>"== true" почём зря цепляет взгляд
Нет. При == true я вижу явную операцию сравнения; без этого - ну там переменная; да, она своим именем отражает смысл, но я один хуй не воспринимаю код как естественный язык, так что не вижу смысла в этих потугах.
И да, для меня как раз отсутствие "== true" затрудняет чтение/понимание, а не наоборот. По крайней мере, когда чужой код читаю.
>>906854
>Автозагрузка в Godot как раз даёт возможность сделать глобальную лапшу
А ты не делай глобальную лапшу. Видишь, я тоже умею в такую аргументацию.
Нет, серьёзно. Что мешает использовать синглтоны по назначению? Как:
1. Словарь глобальных констант,
2. Класс вспомогательных функций, которые могут понадобиться в любом месте кода,
3. Шину взаимодействия, например, между игровыми объектами и гуём,
4. Постоянно висящий в памяти менеджер чего-либо, например, музыки.
>То, что я предлагаю:
Не, ну тут база, конечно.
Думал, ты предлагал реализовать аналог InputEvent...
Твой подход ничем не лучше и не решает проблему.
1. У тебя глобальный объект. Ещё и божественный.
2. К которому обращаются из рандомных скриптов.
3. Который владеет тем, что ему не принадлежит.
И всё это снова ведёт к тугому клубку лапши:
https://ru.wikipedia.org/wiki/Спагетти-код
https://en.wikipedia.org/wiki/Spaghetti_code
Любую игру можно представить как иерархичное сообщество систем. Системы можно разделить по размерам: чем больше систем в подчинении у конкретной системы, тем она больше. Как можно догадаться, самая большая система - это сама игра, включающая в себя вообще всё, что в твоей игре реализовано. Самая маленькая система в Godot выражается одной нодой, например, Label: она не делает ничего, кроме вывода предоставленного ей текста. Средняя по размеру система - это, например, главное меню, в котором есть несколько разных надписей и кнопок, но оно находится в подчинении у системы бОльшего размера - главной системы - игры. Если представлять проект в таком виде, то будет легче избежать запутывания в лапше, т.к. независимые системы друг о друге гарантированно не знают.
Вот твоя игра запускается.
- Игра показывает заставку.
- - Заставка проигрывает анимацию.
- - Заставка сообщает Игре, что она закончила.
- Игра вызывает Главное меню.
- - Главное меню показывает Надпись.
- - - Надпись проигрывает анимацию текста.
- - Главное меню показывает Кнопки.
- - - Кнопки регистрируют движения мыши.
- - - Кнопки передают подсказки Главному меню.
- - Главное меню передает подсказки в Надпись.
- - - Надпись отображает полученный текст.
- - - Кнопка "начать игру" получает клик мышкой.
- - Главное меню сообщает Игре об этом.
- Игра скрывает Главное меню.
- - Главное меню убирает лишние элементы.
- - - Лишние элементы прибираются за собой.
- Игра загружает Менеджер мира.
- - Менеджер мира загружает Карту.
- - - Карта спавнит декорации.
и т.д.
Может показаться, что это слишком много лишней работы, но это даст преимущество в будущем, когда придётся искать ошибки, создавать новые фичи, следующий проект в той же серии игр или новый проект в том же или похожем жанре.
Скажем, можно будет взять главное меню и целиком перенести в новый проект, заменив только спрайты, ведь главное меню не суёт нос куда не следует, а только сообщает "нажата такая-то кнопка". А уже тот, кто вызвал главное меню, пускай разбирается, что ему делать с событием нажатия кнопки.
>Разбавлять стену кода комментами
>оформляю код при помощи комментов
>Комменты в таком отношении это заголовки
https://ru.wikipedia.org/wiki/Подпрограмма
>вижу явную операцию сравнения
Представляешь, "if" - это явная операция проверки выражения на истинность. По сути ты проверяешь истинность того, что истина равна истине. Лол.
А ещё можно делать так:
>func check_value(value: bool) -> bool:
>_ # ~~≈≈ Let's start 🚀 with an if statement ≈≈~~
>_ if value == true:
>_ _ return true
>_ # ~~≈≈ Now it's time ⏰ for an else if statement ≈≈~~
>_ elif value == false:
>_ _ return false
>_ # ~~≈≈ And a little bit of code magic 🪄 here ≈≈~~
>_ else:
>_ _ printerr("Panic! %s isn't true nor false!” % [value])
>_ _ return false
>_ # ~~≈≈ Just a little check to be 💯 sure ≈≈~~
>_ printerr("PANIC!!! Return isn't working!!!")
>_ # P A N I C ! ! ! Can't understand this code!!! 😱
>_ # Phew. Now I can understand. 🤭🤣😏
>_ # 🙈🙉🙊 <- people involved in coding this 🧱🖥️
>Словарь глобальных констант,
Чтобы заниматься ctrl+c/ctrl+v, когда захочешь перенести пару объектов в другую игру? Или тянуть за собой стену кода с лишними константами? Самое весёлое, наверное, ctrl+f и поиск в файле на тысячу констант в той самой игре "сложнее тетриса"...
>Класс вспомогательных функций, которые могут понадобиться в любом месте кода,
Создаёшь файл res://utils/magic_utils.gd
>class_name MagicUtils
>static func do_magic_trick(hat: Hat) -> Rabbit: ...
Использовать так:
>var rabbit := MagicUtils.do_magic_trick(hats.pop_back())
>Шину взаимодействия, например, между игровыми объектами и гуём,
Ты либо собираешь гуй в одном месте и потом соединяешь сигналами кому нужно, либо делишь гуй на части и каждый объект имеет свою часть гуя.
Пример с меню выше был. Игровым объектам не нужен прямой доступ к элементам меню, а шкала здоровья над врагом должна подчиняться только тому врагу, которому она принадлежит.
>Постоянно висящий в памяти менеджер чего-либо, например, музыки.
Рискуешь прибить гвоздями что-нибудь к этому "постоянно висящему" менеджеру и забыть об этом. А потом "ой" и переделывать кучу скриптов или смириться и доделывать игру на костылях, без последующего повторного использования кода.
Я не говорю, что вообще нельзя использовать. Просто нужно подходить к этому с большой осторожностью, а не насыпать гору кода не глядя, а потом спрашивать советов на форумах, а чё там ничего не работает.
Нужно ввести в редактор ограничения по уровню. Делаешь игры - получаешь очки опыта; чем больше очков опыта, тем больше функций разблокируется.
Вот я делаю экспорт на андроид. Для релиза надо сгенерить ключ. Ок, генерю. Но тут https://developer.android.com/studio/publish/app-signing написано, что это ключ не совсем ключ, его можно давать только гуглу при заливе в стор, а гугл на его основе сделает свой ключ, и вот тогдаааа...
Кароч. Я в аппстор лить не собираюсь. На итч безопасно заливать с тем ключом, который я по инструкции https://docs.godotengine.org/en/3.5/tutorials/export/exporting_for_android.html генерю?
Сделай отдельный ключ для резиза на итч. А потом забудь его поменять.
Вообще я бы даже сделал так - написал батники, которые вызывают
экспорт из годота с нужными параметрами.
В гугл я не выкладывал, но читал что он больше не принимает apk, а принимает aab, это архив всех билдов, а юзеру он сам отдает сборку только под его телефон, поэтому, увы, подписывать будет действительно гугл, а не ты.
>батники, которые вызывают экспорт из годота с нужными параметрами.
"Предустановки" называется. Ты можешь прямо в окне экспорта создать несколько разных предустановок с разными параметрами на одну и ту же платформу. А потом в один клик экспортировать все.
В общем да, так тоже можно. Но все равно надо быть внимательным чтобы не залить потом версию не из той папки. Не знаю, автоматизирована ли заливка на гугл, на итч заливаю butler-ом.
Не только возможна, но и будет. Я десяток тредов назад скидывал тест в 2д, да ты и сам его можешь повторить. Возьми 2 Area одна символизирует игрока, вторая стену, подключи сигналы, и пуляй прожектайл. Наблюдай порядок получения сигналов и будет ли их наличие.
самое первое что приходит в голову - для таких быстрых объектов рэйкастить из точки а в точку б и смотреть в чё там можно врезаться
Окей.
>>906926
Значит надо не просто проджектайлить, а с учётом баллистики. Пуля пролетает кадр, к её вектору прибавляется гравитация, пуля кидает рейкаст к месту своего предыдущего положения, наносит урон всему, что попало в рейкаст и уничтожается, если рейкаст ничего не нашёл, ищет столкновение и наносит урон и уничтожается, если столкновения нет, летит дальше.
В таком алгоритме можно и пробивную силу реализовать. В стене пуля сразу уничтожается, а в туше - убавляет своё ХП и скорость, и летит дальше.
> пуля кидает рейкаст к месту своего предыдущего положения, наносит урон всему, что попало в рейкаст
Ну тоесть, не всему, а самому дальнему объекту, потому что рейкаст кидается назад. Кстати, надо выяснить, от рейкаста приходит массив отсортированный по расстоянию или самому сортировать?
>This method takes one parameter: a Vector2 indicating the body's relative movement. Typically, this is your velocity vector multiplied by the frame timestep (delta). If the engine detects a collision anywhere along this vector, the body will immediately stop moving.
>>907012
>>906997
>>906926
>>906923
>>906919
Используй силу движка, Люк. Метод уже реализован.
Хотя, если речь про 3д, то там я информации не нашёл.
Визуализации делаете?
Делитесь графами.
все заняты пиздежом в интернете и спорами о синтаксисе,никто игры не делает на самом деле
Поставил дедлайн - прототип к концу месяца. Механики продуманы, но надо интерфейс и генерить тонны спрайтов.
Я пару раз на бумаге такую хуйню рисовал когда надо было прям залупу с кучей вложений отрефакторить.
>833 м/с, при средних фепесах в 60 это получается 14 метров за один кадр
Обычно физические пульки в играх двигаются значительно медленнее, чтобы игрок мог их визуально заметить, иначе смысла нет - буллетхелл и всё такое, где игроку нужно уворачиваться от пуль. Реалистичное оружие делается простым рейкастом - пуля попадает в цель в момент нажатия кнопки стрельбы, безо всякой баллистики, при том рейкаст зачастую короткий. Для визуализации рейкаста могут растягивать текстуру, типа это пуля трассирующая, но это только декорация, а не физическая модель. Другое дело - гранаты и ракеты, они обычно двигаются медленно и поэтому у них есть полноценная физическая модель (вплоть до того, что их можно сбить с курса или отбить в сторону, или они сами отскакивают). Тут всё зависит от того, какую игру ты делаешь, какую роль играет стрельба и т.д.
>>906997
Можешь попробовать встроенную фичу:
https://docs.godotengine.org/en/stable/classes/class_rigidbody2d.html#class-rigidbody2d-property-continuous-cd
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-continuous-cd
Я не делаю диздоки на своем этапе, мне морально тяжело обрубать то, что я не могу сделать. Поэтому я просто в редакторе делаю, что могу, а потом смотрю, есть ли тут игра.
>прототип к концу месяца
>Механики продуманы
>генерить тонны спрайтов
Эм... Вообще-то, прототип игры - это голые механики. Графика в прототипе - условные кубы/квадраты, так, чтобы было понятно назначение каждого объекта. "Тонны спрайтов" к прототипу отношения не имеют, независимо от того, какую игру ты делаешь.
Цель прототипа - проверка механик. Мозг человека устроен так, что не способен отличить, когда его привлекает процесс игры, а когда - графика/звуки. Поэтому, если в прототипе приятная графика, если разработка начата с графики без прототипа, тогда высока вероятность, что твоя механика не работает должным образом, но твой мозг видит приятную картинку на экране и думает "хорошая игра".
Скорее всего именно по этой причине рождаются неполноценные игры с шикарной графикой и просто ужасным геймплеем - разработчик играл, конечно, но его мозг обманул сам себя из-за графики.
Алсо, вложив силы и время в арт, будет тяжелее выбросить прототип нерабочей механики/игры. Прототипы создаются как раз чтобы выбрасывать лишнее до того, как потратишься на графон.
>inb4 нейроарт ничего не стоит
Ты всё равно вкладываешь в это какое-то время.
>inb4 игра жёстко завязана на графон
Тогда это книжка с картинками, а не игра, если без качественной графики от игры ничего не остаётся.
Графика - обёртка для игры, а прототип - попытка отсеять конфеты от говна до стадии упаковки.
Не, я про прототип готового продукта. Прототип механик на кубах мне не нужен, потому что что механики работают мне известно из других источников, а вот без картинки я игру раскрутить не смогу. Мне нужен хотя бы срез арта чтобы можно было делать промо материалы, даже если основная графика и механики еще не доделаны. Да, нейроарт придется использовать, только тихо.
>тяжело обрубать то, что я не могу сделать
Тогда будет тяжело расти как разработчик и твои проекты не вырастут больше мелких прототипов.
Диздок соло разработчику нужен, чтобы:
- не забыть то, что придумал, пока реализуешь, ибо реализация тратит очень много времени, а память у человека как правило очень слаба;
- организовать системы игры заранее, чтобы потом не приходилось перебрасывать и править файлы;
- заранее выявить логические нестыковки, например, когда твои хотелки противоречат друг другу (хотел динамичную игру, но механика тормозит игрока);
- разбить большие системы на мелкие части, которые намного легче понять и реализовать на практике, что может помочь в борьбе с прокрастинацией;
- сохранить свидетельство проверенных нерабочих механик, чтоб не бегать по одним и тем же граблям;
- более реалистично оценить масштаб работ, чтобы сократить слишком масштабные планы до того, как бросишься рисовать/моделировать;
- бороться с feature creep, хаотичным добавлением дополнительных фич, нарушающих простой дизайн и размывающих фокус игры лишними деталями;
- поддерживать игру в будущем, при условии, что поддерживаешь диздок в актуальном состоянии.
> какую игру ты делаешь
Ремейк игоры из 90х про снайперов. (зельда трифорс)
> безо всякой баллистики
Там без баллистики и поправки на ветер никак.
>Мне нужен хотя бы срез арта чтобы можно было делать промо материалы, даже если основная графика и механики еще не доделаны.
Это называют вертикальным срезом:
https://habr.com/ru/companies/miip/articles/308286/
https://askagamedev.tumblr.com/post/77406994278/game-development-glossary-the-vertical-slice
>механики работают мне известно из других источников
У тебя 100% клон с другой шкуркой? Или это механики уровня кликера с одной кнопкой? Просто интересно.
>Объясните
Читай сам.
https://gdscript.com/solutions/coroutines-and-yield/
>Это вообще важно
Некоторые вещи от движка можно добиться только на следующем кадре, поэтому приходится ждать.
Меня не совсем вертикальный срез интересует, он подразумевает что все что можно закодили, а для промо материалов мне достаточно иллюзии. Я могу просто заанимировать катсцену как кто то подходит и бьет и вылетают цифирки, мне не надо честные механики поиска пути, выбора персонажей, самих механик, рассчета сколько именно урон
будешь 5 лет срать гифками, а потом уже игру сделаешь(как инмост)?
Годетта для переката.
Хотел тебя поблагодарить апскейленным мемом, но апскейлер облажался и эмоция исчезает после апскейла. Но все равно держи.
>заанимировать катсцену как кто то подходит и бьет и вылетают цифирки, мне не надо честные механики поиска пути, выбора персонажей, самих механик, рассчета сколько именно урон
АНИМИРОВАЛ КАТСЦЕНЫ
@
ПОЛУЧИЛ ИНВЕСТИЦИИ
@
МЕХАНИКИ СДЕЛАТЬ НЕ СМОГ
@
ЧУВСТВУЕШЬ БОЛЬ В ЖОПЕ
@
НО ЗАПАХА ГАРИ НЕТ
Забыл ссылку на модель, если кто хочет:
https://sketchfab.com/3d-models/godette-rigged-dd05b69799a2438e97c90d166f6e416a
Я раньше тоже думал, что хуйня какаята. Но вот реальный пример использования.
Допустим юзерданные хранятся на облаке. Чтобы загрузить их, шлём запрос к серверу и ждём ответа. И не городим дикую конструкцию, а просто в одной функции:
> send_request_to_server()
> var data = yield(self, "data_loaded")
> do_something_with(data)
Так если цель заработать, то она достигнута, в чем боль? В крайнем случае нанять кого то можно будет.