324 Кб, 1280x720Добро пожаловать в тред любви и взаимопомощи, и чтобы к концу треда все сделали по игре!
Шапка: https://hipolink.me/godothread
Предыдущий: >>895906 (OP)
Архивный: >>890164 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>895906 (OP)
Архивный: >>890164 (OP)
Очитались о выполнении задания >>895915 →!
106 Кб, 628x528>>1899
Я недавно узнал о программе MagicaVoxel и сейчас пилю ассеты воксельные для своей игры мечты. А так же там есть прямой импорт прямо в двиг.
> Докладывайте, кто сколько игор сделал?
Я недавно узнал о программе MagicaVoxel и сейчас пилю ассеты воксельные для своей игры мечты. А так же там есть прямой импорт прямо в двиг.
Ну чё там, годото разрабы отчитались, насколько трафик увеличился в свете последних событий?
>>1936
На реддите мелькали статы по гугл-поиску и популярности сабреддита.
На реддите мелькали статы по гугл-поиску и популярности сабреддита.
>>1932
Не, блокбенч какой-то сложный. Вот бывает же такое, когда скачиваешь прогу, запускаешь и всё сразу ясно без туториалов.
Не, блокбенч какой-то сложный. Вот бывает же такое, когда скачиваешь прогу, запускаешь и всё сразу ясно без туториалов.
Работаю в вебе, решил попробовать вкатиться в геймдев. Уже недельку по чуть-чуть ковыряю туториалы. Несколько раз пробовал вкатиться в юнити, но что-то прям не заходило. А с godot все идет как по маслу, интерес не пропадает.
Круто мотивируют видосы челов, которые делают игры под game jam'ы. Подумываю самим попробовать как освоюсь, только вот немного удручает что надо самому учиться ассеты пилить
Круто мотивируют видосы челов, которые делают игры под game jam'ы. Подумываю самим попробовать как освоюсь, только вот немного удручает что надо самому учиться ассеты пилить
>>1969
Так и думал. Но все равно игра в таком случае кажется "не своей". Да и фантазия ограничивается доступными ассетами. Надо будет курсы по бленедеру пройти
Так и думал. Но все равно игра в таком случае кажется "не своей". Да и фантазия ограничивается доступными ассетами. Надо будет курсы по бленедеру пройти
701 Кб, 2500x1700>>1972
Годное решение. Одно из лучших в твоей жизни. Не откладывай. Вот тебе для затравки.
> курсы по бленедеру
Годное решение. Одно из лучших в твоей жизни. Не откладывай. Вот тебе для затравки.
545 Кб, 941x1403Ананасы, нужен гайд от тех кто вкатился. Как начатать быстрее и эфективнее всего работу с годот имея базовые навыки в создании игр, спасибо.
>>2145
Пройди официальные гайды, your first 2d game, your first 3d game, валяются в официальной документации. Дальше делаешь свои проекты по документации и, опционально, подглядывая за гайдами на ютубе.
Пройди официальные гайды, your first 2d game, your first 3d game, валяются в официальной документации. Дальше делаешь свои проекты по документации и, опционально, подглядывая за гайдами на ютубе.
>>2145
Сделай какую нибудь простую игру. Платформер 2д или run-n-gun или топдаун шутер что то такое. Чтобы попробовать все аспекты, от загрузки ресурсов, уровней, анимаций, физики прыжков, гуя, настроек, звуков. Поведения врагов, спавны, логику хитов, рестарта, смерти, базовую камеру, взаимодействие с предметами типа дверей. Потом можешь прикрутить фичи типа смены оружия, апгрейдов, визуальных спецэффектов, освещения, поиска пути, диалогов, катсцен, инвентарь и тд
Сделай какую нибудь простую игру. Платформер 2д или run-n-gun или топдаун шутер что то такое. Чтобы попробовать все аспекты, от загрузки ресурсов, уровней, анимаций, физики прыжков, гуя, настроек, звуков. Поведения врагов, спавны, логику хитов, рестарта, смерти, базовую камеру, взаимодействие с предметами типа дверей. Потом можешь прикрутить фичи типа смены оружия, апгрейдов, визуальных спецэффектов, освещения, поиска пути, диалогов, катсцен, инвентарь и тд
>>1928
Кстати, для вокселей есть ещё вспомогательная утилита SLAB6. Узнал о ней из видосов чела, который дум в воксель перенёс: https://www.youtube.com/watch?v=RJ7MH2FqUIg
Кстати, для вокселей есть ещё вспомогательная утилита SLAB6. Узнал о ней из видосов чела, который дум в воксель перенёс: https://www.youtube.com/watch?v=RJ7MH2FqUIg
>>1899
Успел 0, сломался компьютер и перестал работать блендер. Придется вернуться к 2д проектам или тупо делать на чужих лоуполи ассетах
Успел 0, сломался компьютер и перестал работать блендер. Придется вернуться к 2д проектам или тупо делать на чужих лоуполи ассетах
>>1932
Можно в самом годоте делать. Надо просто написать простенький редактор для csgpolygon который будет uv текстуру натягивать.
Можно в самом годоте делать. Надо просто написать простенький редактор для csgpolygon который будет uv текстуру натягивать.
>>2162
Они же только для разработки предназначены, как плейсхолдеры, не? В том смысле, что роняют производительность.
>csgpolygon
Они же только для разработки предназначены, как плейсхолдеры, не? В том смысле, что роняют производительность.
>>2164
А ты потести. Ну и есть аддоны/скрипты для конвертирования в obj
А ты потести. Ну и есть аддоны/скрипты для конвертирования в obj
>>2172
Давай.
Давай.
>>1928
Да, но звуковой плеер очень пердежно импортирует огг. Нормальный звук эффекты можно только встроенным синтом сделать. Мне поэтому не подошел.
Да, но звуковой плеер очень пердежно импортирует огг. Нормальный звук эффекты можно только встроенным синтом сделать. Мне поэтому не подошел.
>>1998
За cheatsheet от души
За cheatsheet от души
А я сейчас занялся изучением мультитрединга путём переписывания скриптов на шарпе обратно в гдскрипт. В качастве поциента выбран GodotManager (кажется, он есть в шапке).
>>2257
Английский - самый полезный скилл для любого айтишника. А технический английский еще и простой. Даже индусы в него могут.
Теперь ты знаешь какой скилл тебе прокачивать.
Английский - самый полезный скилл для любого айтишника. А технический английский еще и простой. Даже индусы в него могут.
Теперь ты знаешь какой скилл тебе прокачивать.
>>2264
Ес айм гет вот эбаут ю спокен, бат лец американс го фак ёселф виз.ем тонг. Андестенд?
Ес айм гет вот эбаут ю спокен, бат лец американс го фак ёселф виз.ем тонг. Андестенд?
>>2278
Проиграл с этого корявого селючьего нахрюка.
Проиграл с этого корявого селючьего нахрюка.
>>2325
китайский кривой и тоновый, а хинди хоть на человеческий похож
китайский кривой и тоновый, а хинди хоть на человеческий похож
Зарепортил нерелейтед. Игры делай.
>>2358
Ну сорян. Все равно полезно.
Ну сорян. Все равно полезно.
>>2328
Причём тут санскрит, если в индии хинди + множество местных + англ.
Причём тут санскрит, если в индии хинди + множество местных + англ.
Где найти людей, способных потестить и дать подробные отзывы о ранней версии игры? Подразумевая что ты не ютубер с сотней тыщ подписчиков. На реддите овощи какие-то, хуй заставишь их.
>>2597
Если тебе нужны подробные отзывы, то ты находишься сейчас на этом ресурсе. Неиронично.
Если тебе нужны подробные отзывы, то ты находишься сейчас на этом ресурсе. Неиронично.
Только что узнал что 4й годот на шарпе не экспортируется на андроид, и в связи с этим возникла дилемма - делать на 4ке, но мучаясь с гдс скриптом, или откатиться на 3ю версию и спокойно делать на шарпе. Игру планирую сделать простенькую без 3д, так что склоняюсь к первому варианту. А как вы считаете, 4ка стоит того или разницы особой нет?
>>2600
Пока ты свою игру доведешь до релизного состояния уже годот 6 выйдет.
Пока ты свою игру доведешь до релизного состояния уже годот 6 выйдет.
871 Кб, 1200x1200>>2602
трясутся что украдут
трясутся что украдут
28 Кб, 517x423Тем временем пробили 50к донатов.
>>2612
Да, валите уже обратно, залетухи
Да, валите уже обратно, залетухи
Я валю обратно, но годот должен оставаться великим и становится лучше. Открытое ПО это православно, это правильно. Когда годот станет по настоящему крутым (а теперь, с 50 к донатов в месяц и их кол-во становится ещё больше) это будет по настоящему ультимативный двиг под все задачи. Для этого не хватает немногого - джолт, производительный рендер, какой нибудь аналог IL2CPP и всё. Вот тогда это будет
>>2622
Спич уровня нью васюки
Спич уровня нью васюки
https://www.youtube.com/watch?v=8v5SrgkC_dI почему сисярп в годоте настолько лучше?
>>2622
Увидимся снова когда ваш Джон решит выплатить положенное инвесторам. То есть скоро и неизбежно. Заходи.
Увидимся снова когда ваш Джон решит выплатить положенное инвесторам. То есть скоро и неизбежно. Заходи.
Ну, хайпанули немножечко, можно и дальше сидеть на дне, не очень-то и хотелось становиться популярным движком.
>>2257
К сожалению, аудитория годота пока не на столько велика, чтобы было много качественных материалов на русском. Там в принципе язык не сложный, в крайнем случае - можно тупо за автором повторять
К сожалению, аудитория годота пока не на столько велика, чтобы было много качественных материалов на русском. Там в принципе язык не сложный, в крайнем случае - можно тупо за автором повторять
>>2257
Чё как лох-то? Скачай, раздели на половинки, а потом залей на ютаб и яндек переведёт.
Чё как лох-то? Скачай, раздели на половинки, а потом залей на ютаб и яндек переведёт.
>>2217
Бля, братишка, это был лучший сон в моей жизни. Я всю ночь периодически просыпался и слушал его бубнёж, а потом опять засыпал и мне снились великолепные сны!
Бля, братишка, это был лучший сон в моей жизни. Я всю ночь периодически просыпался и слушал его бубнёж, а потом опять засыпал и мне снились великолепные сны!
>>2633
Потому что объекты создаются по паттернам, по классике, через инстансы, а не как богомерзкий монобех, через геткомпонент<T>
> почему сисярп в годоте настолько лучше?
Потому что объекты создаются по паттернам, по классике, через инстансы, а не как богомерзкий монобех, через геткомпонент<T>
Ананасы, как сделать жесткий вкат если делал несколько базовых игр на юнити. Я до сих пор искренне не понимаю как сделать игру, читать документацию? Ну пиздец, не понятно ничего. Кто как вкатился в годот, может курсов сольете, спасибо.
>>2730
Бля, анон.
Всё, что тебе нужно уяснить это шесть вещей:
1. Start это _Ready
2. Update/FixedUpdate это _Process/_PhysicsProcess
3. Иерархия сцены состоит не из объектов Monobekh, а из объектов Node.
4. Объекты Node обладают несколькими уровнями наследования.
5. При создании игры ты опираешься на иерархию нод, а не на компоненты.
6. При желании, ты можешь самостоятельно реализовать компонентную систему, но в большинстве случаев она соснёт у иерархической системы.
Если остались вопросы, задавай. Я в равной степени знаком с обоими движками.
> Я до сих пор искренне не понимаю как сделать игру
> Ну пиздец, не понятно ничего.
> как сделать жесткий вкат
Бля, анон.
Всё, что тебе нужно уяснить это шесть вещей:
1. Start это _Ready
2. Update/FixedUpdate это _Process/_PhysicsProcess
3. Иерархия сцены состоит не из объектов Monobekh, а из объектов Node.
4. Объекты Node обладают несколькими уровнями наследования.
5. При создании игры ты опираешься на иерархию нод, а не на компоненты.
6. При желании, ты можешь самостоятельно реализовать компонентную систему, но в большинстве случаев она соснёт у иерархической системы.
Если остались вопросы, задавай. Я в равной степени знаком с обоими движками.
>>2730
Просто и без задней мысли берешь и делаешь. На десятый раз разберешься. Я только к третьей релизнутой игры получил ощущение хоть какого-то понимания, и научился ходить своими ногами, без туториалов/документации.
Просто и без задней мысли берешь и делаешь. На десятый раз разберешься. Я только к третьей релизнутой игры получил ощущение хоть какого-то понимания, и научился ходить своими ногами, без туториалов/документации.
>>2734
Спасибо, но больше был вопрос "глобального вката". Курсы, документация, видео на ютубе, где точка старта, как понимать?
Спасибо, но больше был вопрос "глобального вката". Курсы, документация, видео на ютубе, где точка старта, как понимать?
>>2736
Спасибо, принято
Спасибо, принято
>>2745
Впрочем лень, что то писать, за меня всё сказал Хуан: https://docs.godotengine.org/en/3.1/getting_started/editor/unity_to_godot.html
Впрочем лень, что то писать, за меня всё сказал Хуан: https://docs.godotengine.org/en/3.1/getting_started/editor/unity_to_godot.html
>>2730
Вот ещё это послушай https://www.youtube.com/watch?v=2efd_2SV1Z8
Но, если за неделю с начала юнитипиздеца ты не вкотился, то годот не твоё. Просто иди дальше, не еби мозги ни себе, ни нам.
Вот ещё это послушай https://www.youtube.com/watch?v=2efd_2SV1Z8
Но, если за неделю с начала юнитипиздеца ты не вкотился, то годот не твоё. Просто иди дальше, не еби мозги ни себе, ни нам.
Пишу в мёртвом треде мёртвого движка.
Сижу в оджидании 4.2, но выпустят ли его, надеюсь в этом году сделают.
Сижу в оджидании 4.2, но выпустят ли его, надеюсь в этом году сделают.
Делайте игры
>>2734
Тащемта ноды прекрасно выполняют роль компонентов.
>>2737
Лично я вкатывался с видосов HeartBeast'a, его приятнее всех слушать. Но только для ознакомления с движком и общими принципами работы. Никогда никакие туторы не перепечатывал. Ну и переучиваться со всяких юнитей тогда тоже не приходилось, с нуля заходил, так что не знаю, насколько тебе такое подойдёт.
>6.
Тащемта ноды прекрасно выполняют роль компонентов.
>>2737
Лично я вкатывался с видосов HeartBeast'a, его приятнее всех слушать. Но только для ознакомления с движком и общими принципами работы. Никогда никакие туторы не перепечатывал. Ну и переучиваться со всяких юнитей тогда тоже не приходилось, с нуля заходил, так что не знаю, насколько тебе такое подойдёт.
>>2734
Не совсем понял почему? Разве не удобно иметь независимые объекты с возможностью создавать префабы, чем зависимые ноды, изменение/использование которых тянет другие связи?
>>6. При желании, ты можешь самостоятельно реализовать >>компонентную систему, но в большинстве случаев она соснёт у >>иерархической системы
Не совсем понял почему? Разве не удобно иметь независимые объекты с возможностью создавать префабы, чем зависимые ноды, изменение/использование которых тянет другие связи?
>>2820
Мы говорим о перекате. Челику нужно видеть перед глазами что-то знакомое, что он автоматически понимает. Поэтому, массив типа Array[Reference] ему на первых порах будет привычнее, чем искаробочный массив Array[Node] который мы получаем по get_children().
>>2866
Потому что там другая архитектура. И мы в данном случае (как я надеюсь) говорим о перекате готовых наработок вкатунов, при этом правки архитектуры должны быть минимальны. Если у вкатуна куча самописных скриптов, наследующихся от монобеха, то в годоте ему проще всего сделать абстрактный класс MonoBehaviourProxy extends Reference, а затем переписать все свои невизуальные компоненты под этот абстрактный класс. Затем в нодах, где нужно, он создаёт @export var components : Array[MonoBehaviourProxy] и спокойно, привычным для себя образом закидывает "компоненты" в ноду через инспектор редактора.
Но как я выше написал:
>>2734
> ноды прекрасно выполняют роль компонентов
Мы говорим о перекате. Челику нужно видеть перед глазами что-то знакомое, что он автоматически понимает. Поэтому, массив типа Array[Reference] ему на первых порах будет привычнее, чем искаробочный массив Array[Node] который мы получаем по get_children().
>>2866
> Не совсем понял почему?
Потому что там другая архитектура. И мы в данном случае (как я надеюсь) говорим о перекате готовых наработок вкатунов, при этом правки архитектуры должны быть минимальны. Если у вкатуна куча самописных скриптов, наследующихся от монобеха, то в годоте ему проще всего сделать абстрактный класс MonoBehaviourProxy extends Reference, а затем переписать все свои невизуальные компоненты под этот абстрактный класс. Затем в нодах, где нужно, он создаёт @export var components : Array[MonoBehaviourProxy] и спокойно, привычным для себя образом закидывает "компоненты" в ноду через инспектор редактора.
Но как я выше написал:
>>2734
> в большинстве случаев она соснёт у иерархической системы
>>2874
Но ваще вместо вышеописанного велосипеда, если есть потребность организовать "компоненты", лучше делать их на "белых" нодах, которые по сути пустые и содержат только минимальный функционал: добавление в дерево и обработка колбэков.
Таким образом, наш сферический юнитиперекатун добавляет своему объекту несколько нод, называет их ,как ему надо, а им пишет скрипты, которые при своём старте получают ссылку на хост-ноду, как показано на втором скрине, которая устанавливается через инспектор, как показано на третьем скрине.
Но ваще вместо вышеописанного велосипеда, если есть потребность организовать "компоненты", лучше делать их на "белых" нодах, которые по сути пустые и содержат только минимальный функционал: добавление в дерево и обработка колбэков.
Таким образом, наш сферический юнитиперекатун добавляет своему объекту несколько нод, называет их ,как ему надо, а им пишет скрипты, которые при своём старте получают ссылку на хост-ноду, как показано на втором скрине, которая устанавливается через инспектор, как показано на третьем скрине.
>>2899
Хватит срать, давайте лучше обсудим, подходит ли нода CharacterBody3D (бывшая KinematicBody) для реальной разработки игор с физикой? Потому что я тут подумал, в случаях, когда мне надо будет забрать у перса управление и включить ему рэгдол (например, после взрыва и т.п.), то с этой нодой мне придётся велосипедить движение.
Не проще ли делать персонажа на RigidBody3D в режиме Freeze.Kinematic?
Хватит срать, давайте лучше обсудим, подходит ли нода CharacterBody3D (бывшая KinematicBody) для реальной разработки игор с физикой? Потому что я тут подумал, в случаях, когда мне надо будет забрать у перса управление и включить ему рэгдол (например, после взрыва и т.п.), то с этой нодой мне придётся велосипедить движение.
Не проще ли делать персонажа на RigidBody3D в режиме Freeze.Kinematic?
>>2908
Щас буду делать, но поскольку я нуб в физон-матане, буду юзать туториалы. Вот нашёл неплохой. Чувак с умным видом хуячит хелпер-классы с вычислением интегральной ошибки (какой-то). Похоже, это то, что нужно.
https://youtu.be/zTp7bWnlicY
Щас буду делать, но поскольку я нуб в физон-матане, буду юзать туториалы. Вот нашёл неплохой. Чувак с умным видом хуячит хелпер-классы с вычислением интегральной ошибки (какой-то). Похоже, это то, что нужно.
https://youtu.be/zTp7bWnlicY
>>2904
Я на тройке делал так. Кинематик - это сам персонаж. А внутри него части тела ригиды и джойнты между ними. Пока перс живой, физика кинематика включена, физика ригидов выключена; умер - кинематик и анимацию выключаем, ригиды включаем.
А вот что мне интересно - это PhysicalBone2D/3D в четвёрке (ну, в основном 2д). Судя по названию и описанию они больше подходят для рэгдоллов; но какие именно плюшки они дают и как именно ими правильно пользоваться, чёт я не вкурил.
Я на тройке делал так. Кинематик - это сам персонаж. А внутри него части тела ригиды и джойнты между ними. Пока перс живой, физика кинематика включена, физика ригидов выключена; умер - кинематик и анимацию выключаем, ригиды включаем.
А вот что мне интересно - это PhysicalBone2D/3D в четвёрке (ну, в основном 2д). Судя по названию и описанию они больше подходят для рэгдоллов; но какие именно плюшки они дают и как именно ими правильно пользоваться, чёт я не вкурил.
Почему я не могу сделать get("position.x")?
36 Кб, 720x505>>896061 →
Вы меня так и не разбудили... >>1899
Я думаю захотеть попробовать начать делать прототип чего-то вроде https://ru.wikipedia.org/wiki/Виртуальный_питомец Ибо мучаюсь от одиночества и экзистенциального кризиса...
>Хорошо. Начну делать игру после 450-го поста.
>Разбудите меня, когда будет пора делать игру.
Вы меня так и не разбудили... >>1899
>Докладывайте, кто сколько игор сделал?
Я думаю захотеть попробовать начать делать прототип чего-то вроде https://ru.wikipedia.org/wiki/Виртуальный_питомец Ибо мучаюсь от одиночества и экзистенциального кризиса...
>>2904
Просто делаешь отдельную физическую куклу и включаешь её, когда она нужна. Так почти все игры делают. Реально физическая кукла в обычных движениях применяется только в GTA IV благодаря Euphoria, которая давала возможность симулировать мышцы людей на достаточно точном рэгдолле так, что он буквально ходит как человек, а не как анимированная 3D сетка. Но это уже натуральный rocket science, эйфория была очень сложной и её компания разработчик вроде как разорилась, а Rockstar забросили и даунгрейднули персонажей в RAGE 2 (GTA 5). Были ещё какие-то игры с эйфорией, но так и не дожили до релиза. Сурово, в общем, в одиночку такое не осилить.
Сложнее. У ригидов нет удобных проверок столкновения, придётся велосипедить свои. Кроме того, стандартный кинематик останавливается в миллиметрах от любого препятствия, а ригидбоди в режиме кинематика будет переть на таран, пока ты сам проверками не обмажешься. А если делать движение в стандартном режиме ригидбоди (через приложение физических сил), тогда твой персонаж будет плавно разгоняться и плавно замедляться - каким-то играм это выгодно (в той же GTA 4/5 персонажи делают всё с задержкой, а не резко бегут в любом направлении как раньше), но далеко не всем. Плюс эти силы действуют как ракетный двигатель, создавая парадоксы вроде опрокидывания грузовика бегом внутри его кузова (если бежать в борт кузова, ты как будто отталкиваешься от воздуха, а не от пола кузова), как это фиксить - я так и не понял, какие-то особые проверки коллизий нужны.
>включить ему рэгдол
Просто делаешь отдельную физическую куклу и включаешь её, когда она нужна. Так почти все игры делают. Реально физическая кукла в обычных движениях применяется только в GTA IV благодаря Euphoria, которая давала возможность симулировать мышцы людей на достаточно точном рэгдолле так, что он буквально ходит как человек, а не как анимированная 3D сетка. Но это уже натуральный rocket science, эйфория была очень сложной и её компания разработчик вроде как разорилась, а Rockstar забросили и даунгрейднули персонажей в RAGE 2 (GTA 5). Были ещё какие-то игры с эйфорией, но так и не дожили до релиза. Сурово, в общем, в одиночку такое не осилить.
>Не проще ли делать персонажа на RigidBody3D в режиме Freeze.Kinematic?
Сложнее. У ригидов нет удобных проверок столкновения, придётся велосипедить свои. Кроме того, стандартный кинематик останавливается в миллиметрах от любого препятствия, а ригидбоди в режиме кинематика будет переть на таран, пока ты сам проверками не обмажешься. А если делать движение в стандартном режиме ригидбоди (через приложение физических сил), тогда твой персонаж будет плавно разгоняться и плавно замедляться - каким-то играм это выгодно (в той же GTA 4/5 персонажи делают всё с задержкой, а не резко бегут в любом направлении как раньше), но далеко не всем. Плюс эти силы действуют как ракетный двигатель, создавая парадоксы вроде опрокидывания грузовика бегом внутри его кузова (если бежать в борт кузова, ты как будто отталкиваешься от воздуха, а не от пола кузова), как это фиксить - я так и не понял, какие-то особые проверки коллизий нужны.
33 Кб, 1280x720>>2951
Мне нужно бегать по шару (планете), синхронизируя вектор гравитации с центром шара. Может быть я впал в проблему икс-игрек? Может мне на кинематике будет проще сделать? Потому что я подумал "такс, в движке есть Area у которых можно сделать точечную гравитацию к центру. Я делаю планету, накидываю на неё сферическую область гравитации - и вуаля, персонаж автоматически синхронизирован со сферическим гравитационным полем".
А тут посидел джва часа в редакторе, параллельно смотря туториалы, и нихуя подобного. Чуваки лепят управление на плоскости. Поэтому мне от этого ригид-боди пользы ноль. Единственная польза - другие тела смогут воздействовать на тело игрока, отталкивать. Но это у меня не главная задача. Бля, кинематика сложная, сука.
> Я на тройке делал так. Кинематик - это сам персонаж. А внутри него части тела ригиды и джойнты между ними.
Мне нужно бегать по шару (планете), синхронизируя вектор гравитации с центром шара. Может быть я впал в проблему икс-игрек? Может мне на кинематике будет проще сделать? Потому что я подумал "такс, в движке есть Area у которых можно сделать точечную гравитацию к центру. Я делаю планету, накидываю на неё сферическую область гравитации - и вуаля, персонаж автоматически синхронизирован со сферическим гравитационным полем".
А тут посидел джва часа в редакторе, параллельно смотря туториалы, и нихуя подобного. Чуваки лепят управление на плоскости. Поэтому мне от этого ригид-боди пользы ноль. Единственная польза - другие тела смогут воздействовать на тело игрока, отталкивать. Но это у меня не главная задача. Бля, кинематика сложная, сука.
>>1894 (OP)
Господа, я уже давно все собираюсь и собираюсь вкатиться в геймдев через юнити, но из-за собственного ебланства, дальше сделанным по видеогайдам катающихся по плоскости шаров не ушел, но это давно было, пару лет назад. Сейчас появились силы ебашить и снова попытаться вкатиться, но тут юнити поменял политику монетизации и из каждого утюга начали трубить, что все, нужно уходить.
Помимо юнити мне приглянулся годот, могут, ли те кто трогал то и то описать преимущества и недостатки обеих движков?
Есть ли большая разница в сложности вкатывания? Английским владею.
Насколько удобно и просто делать 2d игры? Простенькие стилизованные 3d?
Насколько тяжело в случае чего перекатиться из одного движка в другой?
Какие перспективы у обоих движков если я буду делать карьеру в геймдеве в качестве геймдизайнера?
Господа, я уже давно все собираюсь и собираюсь вкатиться в геймдев через юнити, но из-за собственного ебланства, дальше сделанным по видеогайдам катающихся по плоскости шаров не ушел, но это давно было, пару лет назад. Сейчас появились силы ебашить и снова попытаться вкатиться, но тут юнити поменял политику монетизации и из каждого утюга начали трубить, что все, нужно уходить.
Помимо юнити мне приглянулся годот, могут, ли те кто трогал то и то описать преимущества и недостатки обеих движков?
Есть ли большая разница в сложности вкатывания? Английским владею.
Насколько удобно и просто делать 2d игры? Простенькие стилизованные 3d?
Насколько тяжело в случае чего перекатиться из одного движка в другой?
Какие перспективы у обоих движков если я буду делать карьеру в геймдеве в качестве геймдизайнера?
>>2966
7/10
7/10
Если ты используешь паттерн MVP - просто. С паттерном MVP ты можешь хуярить одну игру на нескольких движках сразу.
Если ты такие вопросы не гуглишь сам, а спрашиваешь на форумах - никакой карьеры тебе не светит. Без обид, анон, но таким не перезванивают.
> Насколько удобно и просто делать 2d игры?
7/10
> Простенькие стилизованные 3d?
7/10
> Насколько тяжело в случае чего перекатиться из одного движка в другой?
Если ты используешь паттерн MVP - просто. С паттерном MVP ты можешь хуярить одну игру на нескольких движках сразу.
> если я буду делать карьеру
Если ты такие вопросы не гуглишь сам, а спрашиваешь на форумах - никакой карьеры тебе не светит. Без обид, анон, но таким не перезванивают.
>>2963
А, тогда делай на ригидбоди, лол. Тебе в любом случае придётся вращать персонажа ногами в сторону центра планеты, а стандартный кинематик на такое не рассчитан - он для плоского мира.
Если они этот баг не пофиксили, то учитывай, что Area с гравитацией будет всасывать в себя объекты даже если они уже вылетели из её "области действия". Так что для симулятора "прыжка с луны" придётся велосипедить свою гравитацию, впрочем, это несложно (достаточно прикладывать силу гравитации ко всем ригидбоди, находящимся в зоне действия Area).
Алсо учитывай, что физический движок начинает дико колбасить на коллиженшейпах размером больше 250-500 метров (точно не помню, это старый баг), поэтому тебе скорее всего придётся резать планету на куски, если у тебя не малюсенький камень диаметром в жилой квартал. Скорее всего виноват float в вычислениях движка.
Наоборот, такого персонажа проще всего на ригидбоди сделать, т.к. ему плевать, куда лететь.
>Мне нужно бегать по шару (планете), синхронизируя вектор гравитации с центром шара.
А, тогда делай на ригидбоди, лол. Тебе в любом случае придётся вращать персонажа ногами в сторону центра планеты, а стандартный кинематик на такое не рассчитан - он для плоского мира.
>в движке есть Area у которых можно сделать точечную гравитацию к центру
Если они этот баг не пофиксили, то учитывай, что Area с гравитацией будет всасывать в себя объекты даже если они уже вылетели из её "области действия". Так что для симулятора "прыжка с луны" придётся велосипедить свою гравитацию, впрочем, это несложно (достаточно прикладывать силу гравитации ко всем ригидбоди, находящимся в зоне действия Area).
Алсо учитывай, что физический движок начинает дико колбасить на коллиженшейпах размером больше 250-500 метров (точно не помню, это старый баг), поэтому тебе скорее всего придётся резать планету на куски, если у тебя не малюсенький камень диаметром в жилой квартал. Скорее всего виноват float в вычислениях движка.
>Поэтому мне от этого ригид-боди пользы ноль.
Наоборот, такого персонажа проще всего на ригидбоди сделать, т.к. ему плевать, куда лететь.
>>2958
Удачная тема для детей и домохозяек. Те же бородатые тамагочи.
тнуса заведи
Удачная тема для детей и домохозяек. Те же бородатые тамагочи.
>мучаюсь от одиночества
тнуса заведи
>>2972
Для карьеры мне сначала нужно, хоть что-то сделать. А вопрос выбора движка слишком важен, помимо гугления хочется спросить самостоятельно на живом форуме.
Для карьеры мне сначала нужно, хоть что-то сделать. А вопрос выбора движка слишком важен, помимо гугления хочется спросить самостоятельно на живом форуме.
>>2966
Смотри Ютуб, читай форумы. Всё уже обсудили тысячу раз. Но Godot ты можешь сам быстро пощупать, он весит около 50 МБ в архиве и не требует установки, запускается за секунду на слабом ПК и для старта изучения не требует ничего дополнительного скачивать (если использовать стандартную сборку без C#).
Я считаю, Godot сильно проще для вката.
Очень удобно, легко и просто. Godot имеет отдельные субдвижки под 2D с оптимальным API, в отличие от костылей Unity (там "2D" на самом деле в 3D).
Очень просто, если у тебя маленький мирок без процедурного ландшафта и с маленьким числом объектов (несколько сотен прыгающих мячиков). Для чего-то большого и сложного нужно либо искать сторонние дополнения к движку (аддоны или модули), либо делать свои велосипеды.
Несложно, они достаточно похожи по концепциям. Все основные отличия в современном геймдеве абстрагированы от пользователя под капотом.
Unity имеет очень высокую популярность, но последние пару лет из-за руководства теряет былое доверие. Godot только недавно заметили и крупные студии его только "щупают", но недавно обратили больше внимания. В вакансиях давно как-то я видел что знание Godot будет плюсом даже если берут на другой движок; но конкретно геймдизайнеру, наверное, движок вообще не важен, потому что от геймдизайнера требуется написать чёткий дизайн-документ и потом следить за работой остальной команды, внося правки в документ по ходу работы. Короче, геймдизайнер больше с бумагами работает, чем с игровыми движками, его цель - формализовать конкретную задачу (которая принесёт профиты) для гребцов на галере. Но я могу ошибаться, я никогда нигде не работал.
>преимущества и недостатки обеих движков?
Смотри Ютуб, читай форумы. Всё уже обсудили тысячу раз. Но Godot ты можешь сам быстро пощупать, он весит около 50 МБ в архиве и не требует установки, запускается за секунду на слабом ПК и для старта изучения не требует ничего дополнительного скачивать (если использовать стандартную сборку без C#).
>большая разница в сложности вкатывания?
Я считаю, Godot сильно проще для вката.
>Насколько удобно и просто делать 2d игры?
Очень удобно, легко и просто. Godot имеет отдельные субдвижки под 2D с оптимальным API, в отличие от костылей Unity (там "2D" на самом деле в 3D).
>Простенькие стилизованные 3d?
Очень просто, если у тебя маленький мирок без процедурного ландшафта и с маленьким числом объектов (несколько сотен прыгающих мячиков). Для чего-то большого и сложного нужно либо искать сторонние дополнения к движку (аддоны или модули), либо делать свои велосипеды.
>Насколько тяжело в случае чего перекатиться из одного движка в другой?
Несложно, они достаточно похожи по концепциям. Все основные отличия в современном геймдеве абстрагированы от пользователя под капотом.
>Какие перспективы у обоих движков если я буду делать карьеру в геймдеве в качестве геймдизайнера?
Unity имеет очень высокую популярность, но последние пару лет из-за руководства теряет былое доверие. Godot только недавно заметили и крупные студии его только "щупают", но недавно обратили больше внимания. В вакансиях давно как-то я видел что знание Godot будет плюсом даже если берут на другой движок; но конкретно геймдизайнеру, наверное, движок вообще не важен, потому что от геймдизайнера требуется написать чёткий дизайн-документ и потом следить за работой остальной команды, внося правки в документ по ходу работы. Короче, геймдизайнер больше с бумагами работает, чем с игровыми движками, его цель - формализовать конкретную задачу (которая принесёт профиты) для гребцов на галере. Но я могу ошибаться, я никогда нигде не работал.
>>2979
Мне не для маркета, а для себя, "для души". Маркет подобным переполнен, а после LLM/GPT подобные игрушки скорее всего для многих теряют смысл.
Ага, в разные подобные игры играл. Но всё не то. Хочется чего-то реально своего, чисто под себя...
Не хочу. Хочу собственную DIY роботян.
>Удачная тема для детей и домохозяек.
Мне не для маркета, а для себя, "для души". Маркет подобным переполнен, а после LLM/GPT подобные игрушки скорее всего для многих теряют смысл.
>Те же бородатые тамагочи.
Ага, в разные подобные игры играл. Но всё не то. Хочется чего-то реально своего, чисто под себя...
>тнуса заведи
Не хочу. Хочу собственную DIY роботян.
>>2963
На хабре была статья про шарообразный мир в годоте
На хабре была статья про шарообразный мир в годоте
>>2990
Заблуждаешься.
Алгоритмы везде одинаковы:
1. Есть главный цикл приложения. Он есть везде. В оконных приложениях главный цикл обрабатывает сообщения оконной подсистемы ОС. В графических главный цикл обрабатывает фреймы.
2. Ресурсы есть везде. Это общекомпьютерная база, не зависящая от движка. Како движок ты не выберешь - модели будут лежать на диске и тебе их нужно грузить в память.
3. Языки программирования все одинаковы, все начинаются с объявления переменных, продолжаются ветвлениями и циклами, заканчиваются выводом результатов.
4. Учитывая всё вышесказанное, ты можешь легко учить движки как иностранные языки. Самое трудное - выучить первый, а остальные учатся уже легче.
> вопрос выбора движка слишком важен
Заблуждаешься.
Алгоритмы везде одинаковы:
1. Есть главный цикл приложения. Он есть везде. В оконных приложениях главный цикл обрабатывает сообщения оконной подсистемы ОС. В графических главный цикл обрабатывает фреймы.
2. Ресурсы есть везде. Это общекомпьютерная база, не зависящая от движка. Како движок ты не выберешь - модели будут лежать на диске и тебе их нужно грузить в память.
3. Языки программирования все одинаковы, все начинаются с объявления переменных, продолжаются ветвлениями и циклами, заканчиваются выводом результатов.
4. Учитывая всё вышесказанное, ты можешь легко учить движки как иностранные языки. Самое трудное - выучить первый, а остальные учатся уже легче.
>>3078
Двачую этого. Люди на голом опенжл хуячат шедевры, а не вот это вот все, то тут не так, то там не так, то вот тут фича сыровата, то хуй сопливится, то в анус дует.
Просто и без задней мысли берете и делаете игры. Снова и снова и снова. Хватит отмазы лепить.
Двачую этого. Люди на голом опенжл хуячат шедевры, а не вот это вот все, то тут не так, то там не так, то вот тут фича сыровата, то хуй сопливится, то в анус дует.
Просто и без задней мысли берете и делаете игры. Снова и снова и снова. Хватит отмазы лепить.
>>3078
Императивные - да, в основном. Другие парадигмы освоить сложнее, даже с опытом императивных. Но больше всего используются императивные ЯП.
>>3081
А на юнити ассетфлиперы в основном. Они не велосипеды изобретать хотят, а лёгкие бабки стричь.
>Языки программирования все одинаковы
Императивные - да, в основном. Другие парадигмы освоить сложнее, даже с опытом императивных. Но больше всего используются императивные ЯП.
>>3081
>Люди на голом опенжл хуячат шедевры
А на юнити ассетфлиперы в основном. Они не велосипеды изобретать хотят, а лёгкие бабки стричь.
>>3085
Ветвления и циклы спрятаны за обёрткой маппинга списков. Как только ты это осознаёшь, все эти лиспы становятся всё той же парадигмой.
> Другие парадигмы
Ветвления и циклы спрятаны за обёрткой маппинга списков. Как только ты это осознаёшь, все эти лиспы становятся всё той же парадигмой.
>>3086
Ты не понял.
Как приготовить яичницу:
1. Найти яйцо.
2. Разбить яйцо в сковороду.
3. Разогреть сковороду.
4. Ждать приготовления.
Как_приготовить_яичницу();
Известно, что:
1. Яичница - это жаренное содержимое яйца.
2. Яйцо может быть разбито.
3. Из разбитого яйца вытекает содержимое.
4. В скороду можно поместить ингредиенты.
5. Содержимое яйца - ингредиент.
6. Огонь плиты нагревает посуду.
7. Сковорода - это посуда для плиты.
8. Горячая сковорода жарит ингредиенты.
9. Содержимое яйца жарится за 5 минут.
Требуется: 1 яичница.
>маппинга списков
Ты не понял.
Как приготовить яичницу:
1. Найти яйцо.
2. Разбить яйцо в сковороду.
3. Разогреть сковороду.
4. Ждать приготовления.
Как_приготовить_яичницу();
Известно, что:
1. Яичница - это жаренное содержимое яйца.
2. Яйцо может быть разбито.
3. Из разбитого яйца вытекает содержимое.
4. В скороду можно поместить ингредиенты.
5. Содержимое яйца - ингредиент.
6. Огонь плиты нагревает посуду.
7. Сковорода - это посуда для плиты.
8. Горячая сковорода жарит ингредиенты.
9. Содержимое яйца жарится за 5 минут.
Требуется: 1 яичница.
143 Кб, 576x576А простому хую позволено контрибутить и репу? Или там только для уважаемых людей?
>>3164
Позволено. Я доки правил. Полистай тут, чтобы в лужу не сесть:
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
Позволено. Я доки правил. Полистай тут, чтобы в лужу не сесть:
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
>>3164
Я контрибутил. Ну тут как. Если ты исправляешь очевидную мелочь то это легко. Если твое исправление неоднозначно, имеет влияние на архитектуру движка, или потом требует поддержки, то скорее всего выльется в обсуждение. Тут уж сначала имеет смысл пообщаться в дискорде или гитхабе и узнать нужно ли такое и реально ли пропихнуть. Запилить прототип, показать с пруфами и бенчмарками что это нужно. Так делали clayjohn и lawnjely. Если что то узко специальное, то скорее всего без шансов, философия такая чтобы движок не раздувать и все такое выносить в аддоны. В них кстати тоже можно контрибьютить, или пилить свои.
Я контрибутил. Ну тут как. Если ты исправляешь очевидную мелочь то это легко. Если твое исправление неоднозначно, имеет влияние на архитектуру движка, или потом требует поддержки, то скорее всего выльется в обсуждение. Тут уж сначала имеет смысл пообщаться в дискорде или гитхабе и узнать нужно ли такое и реально ли пропихнуть. Запилить прототип, показать с пруфами и бенчмарками что это нужно. Так делали clayjohn и lawnjely. Если что то узко специальное, то скорее всего без шансов, философия такая чтобы движок не раздувать и все такое выносить в аддоны. В них кстати тоже можно контрибьютить, или пилить свои.
>>3164
Мой кодер ебашит вообще адовые пулл-реквесты. Ну такой вот примерно рецепт усредненный, потому что вариаций масса. Берется код, он не читается, читать — это не про моего кодера. Он берет этот код, коммитит его в наш репозиторий и начинает оформлять пулл-реквест. Добавляет в него огромное количество описаний, ссылок, маркдауна и тегов HTML для вязкости, красивый заголовок сверху. Все это пулл-реквестится до комментариев. Потом требуемые правки обсуждаются в комментариях. Потом кодер заходит ко мне и щедро полив комментаторов матом начинает ругаться. При этом ругается с клавиатурой под мышкой, шкрябая по ней ногтями. Ругается и приговаривает полушепотом ух бля. При этом у него на лбу аж пот выступает. Любезно мне иногда предлагает самому лично комментарии к его пулл-реквесту глянуть, но я отказываюсь. Надо ли говорить о том какой дичайший пердеж потом? Вонища такая, что баги в легаси коде сами фиксятся.
Мой кодер ебашит вообще адовые пулл-реквесты. Ну такой вот примерно рецепт усредненный, потому что вариаций масса. Берется код, он не читается, читать — это не про моего кодера. Он берет этот код, коммитит его в наш репозиторий и начинает оформлять пулл-реквест. Добавляет в него огромное количество описаний, ссылок, маркдауна и тегов HTML для вязкости, красивый заголовок сверху. Все это пулл-реквестится до комментариев. Потом требуемые правки обсуждаются в комментариях. Потом кодер заходит ко мне и щедро полив комментаторов матом начинает ругаться. При этом ругается с клавиатурой под мышкой, шкрябая по ней ногтями. Ругается и приговаривает полушепотом ух бля. При этом у него на лбу аж пот выступает. Любезно мне иногда предлагает самому лично комментарии к его пулл-реквесту глянуть, но я отказываюсь. Надо ли говорить о том какой дичайший пердеж потом? Вонища такая, что баги в легаси коде сами фиксятся.
>>3266 (Del)
Што ты несёшь?
Не нужно, он сам работает (F5 - запуск проекта).
Так вот же:
https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#remote-in-scene-dock
Ну, а что ты хочешь? Жми на хлопушку.
>>3268 (Del)
Я пробовал делать прототипы в Юнити разных версий, она всегда была кривой и глючной, а C# вообще порождение корпорации зла. Не понимаю, кто может находить её удобной (кроме утят).
Тебе в Blender удобно работать? Скажи честно.
Што ты несёшь?
>подрубать по IP
Не нужно, он сам работает (F5 - запуск проекта).
>который тебе даже сцену не выдаст
Так вот же:
https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#remote-in-scene-dock
>список нод
Ну, а что ты хочешь? Жми на хлопушку.
>>3268 (Del)
>привык к удобству и пиздатости Юнити
Я пробовал делать прототипы в Юнити разных версий, она всегда была кривой и глючной, а C# вообще порождение корпорации зла. Не понимаю, кто может находить её удобной (кроме утят).
Тебе в Blender удобно работать? Скажи честно.
>>3279
Зачем ты его кормишь?
Зачем ты его кормишь?
С движкосрачем в отдельный тред.
48 Кб, 503x330Ну что. Я тут начал на 3-ке пилить игру в яндекс, и тут вселенная подает сигнал что я на верном пути.
>>3311
Там по правилам обязан сдк интегрировать вроде. Да и лучше я это сделаю, там можно хранить инфу о микропокупках и прокачке на сервере яндекса, можно ник игрока подтягивать.
Там по правилам обязан сдк интегрировать вроде. Да и лучше я это сделаю, там можно хранить инфу о микропокупках и прокачке на сервере яндекса, можно ник игрока подтягивать.
>>3313
Неплохо. Я видел что на ньюграундс веб-игры умеют в ачивки и интеграцию с сайтом, но сам заморачиваться не стал. Видимо там оно через аналогичную интеграцию делается
Неплохо. Я видел что на ньюграундс веб-игры умеют в ачивки и интеграцию с сайтом, но сам заморачиваться не стал. Видимо там оно через аналогичную интеграцию делается
А мне не нравится дефолтный шрифт в редакторе кода в четвёрке. В 3.х шрифт такой леденцовый, почти комик санс, но гейминг санс. Такой приятный и ламповый, будто с тяночкой на лавочке сидишь. А в 4.х сделали шрифт как у деда на старых чертежах для токарного. Не забалуешь. Ещё и собака эта перед экспортами. Оранжевая.
Начал новый проект, чтобы перелезть наконец уже с тройки на четвёрку. Такие дела.
Начал новый проект, чтобы перелезть наконец уже с тройки на четвёрку. Такие дела.
>>3347
А я еще подожду, пока допиливаю текущий проект. Посижу с тянучькой на лавочке, так сказать.
В тройке кстати шрифты настраивались. В четверке тоже должны.
А я еще подожду, пока допиливаю текущий проект. Посижу с тянучькой на лавочке, так сказать.
В тройке кстати шрифты настраивались. В четверке тоже должны.
>>3360
Официальная дока
Официальная дока
405 Кб, 884x896подожду выхода 4.2, тогда начну раздупляться
>>3376
Молодец, продолжай работать в этом направлении. Я вот пока нихуя не заработал.
Молодец, продолжай работать в этом направлении. Я вот пока нихуя не заработал.
>>3398
Я открыл самый простой туториал и просто добавил своего, просто то, что в голову приходило и мог сделать вообще без знаний и опыта. Старался понять каждую строчку кода, если была хоть одна строчка, где я чётко не могу понять, что она делает, то либо переписывал по-своему, либо переделывал вообще механику. Ещё сразу использовал новые элементы, про которые узнал из тутора. Например узнал, про горизонтальные контейнеры и сразу придумал, как их использовать. Дальше нарисовал всратый спрайт в аналоге асеспрайта за полчаса, из ассет-пака бесплатного взял проджектайлы, фон тоже взял бесплатный. Все слепил вместе, получилась игра. Очень невнятная, всратая, хуевая, маленькая и слабенькая. Потом залил и прошел модерацию, получил 100 рублей.
Я открыл самый простой туториал и просто добавил своего, просто то, что в голову приходило и мог сделать вообще без знаний и опыта. Старался понять каждую строчку кода, если была хоть одна строчка, где я чётко не могу понять, что она делает, то либо переписывал по-своему, либо переделывал вообще механику. Ещё сразу использовал новые элементы, про которые узнал из тутора. Например узнал, про горизонтальные контейнеры и сразу придумал, как их использовать. Дальше нарисовал всратый спрайт в аналоге асеспрайта за полчаса, из ассет-пака бесплатного взял проджектайлы, фон тоже взял бесплатный. Все слепил вместе, получилась игра. Очень невнятная, всратая, хуевая, маленькая и слабенькая. Потом залил и прошел модерацию, получил 100 рублей.
https://www.youtube.com/watch?v=_QHvKMRtJD0
Не дают ссылку на код.
Не показывают код в видосе целиком.
Помидоpки.
Не дают ссылку на код.
Не показывают код в видосе целиком.
Помидоpки.
Годот есть на андроид, охуеть. С лопаты даже не слишком мелко. Надо тыкать, но на первый взгляд всё работает.
Это чтобы делать игори даже сидя на толчке?
Это чтобы делать игори даже сидя на толчке?
>>3514
Дети так и делают. На реддите уже пару раз видел как школьники на телефонах делают игори. Не то что вы, ноудевы.
Дети так и делают. На реддите уже пару раз видел как школьники на телефонах делают игори. Не то что вы, ноудевы.
>>3514
Это же в первую очередь не для мобилок, а для каких то планшетов или недонетбуков, без клавы там все равно делать нечего.
Это же в первую очередь не для мобилок, а для каких то планшетов или недонетбуков, без клавы там все равно делать нечего.
>>3405
Посмотрел видео, там показали весь основной код - достаточно, чтобы повторить проект своими руками.
Бездумной копипастой ты ничему не научишься.
>Не показывают код в видосе целиком.
Посмотрел видео, там показали весь основной код - достаточно, чтобы повторить проект своими руками.
>Не дают ссылку на код.
Бездумной копипастой ты ничему не научишься.
перекатился на 4.1, экспортирую apk, запускают под android 6.0 - "Ошибка при синтаксическом анализе пакета".
Мне нужно проспаться или они перестали шестерку поддерживать?
Мне нужно проспаться или они перестали шестерку поддерживать?
>>3587
Я сонный, нужно подкорректировать версии пакетов всяких было
https://docs.godotengine.org/en/4.1/tutorials/export/exporting_for_android.html
Я сонный, нужно подкорректировать версии пакетов всяких было
https://docs.godotengine.org/en/4.1/tutorials/export/exporting_for_android.html
>>3607
Это троллинг издевательски коротким ответом?
1. Опиши, что конкретно сделать хочешь.
2. Рассказывай, что там у тебя не получается.
Если ты просто жалуешься "ой, у меня не получилось, готовый код не работает, вы все бяки, фу на вас" - это выглядит как троллинг, таких тут не любят.
В видео 3.3.1, вышла в мае 2021, это очень давно.
Это троллинг издевательски коротким ответом?
1. Опиши, что конкретно сделать хочешь.
2. Рассказывай, что там у тебя не получается.
Если ты просто жалуешься "ой, у меня не получилось, готовый код не работает, вы все бяки, фу на вас" - это выглядит как троллинг, таких тут не любят.
В видео 3.3.1, вышла в мае 2021, это очень давно.
>>899096 →
>>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, но имхо для миксамо это имеет смысл
>>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, но имхо для миксамо это имеет смысл
>>3621
Ваще надо выпилить, вражеский закрытый стандарт, наследие древних монструозных 3D пакетов от тупых и жадных до денег автостолов. Либо blend, либо gltf.
>плохо работает импорт fbx
Ваще надо выпилить, вражеский закрытый стандарт, наследие древних монструозных 3D пакетов от тупых и жадных до денег автостолов. Либо blend, либо gltf.
>>3623
OBJ еще норм.
OBJ еще норм.
Каким образом можно ограничить directional light на часть сцены? У меня огромная сцена, и этот свет роняет фпс, что для мобильной игры не ок.
Запекание не катит - нужны реалтаймовые тени. Нужно что-то типа "вот в этом квадрате свети, а в этом не свети". Комнаты/порталы - они для этого?
Запекание не катит - нужны реалтаймовые тени. Нужно что-то типа "вот в этом квадрате свети, а в этом не свети". Комнаты/порталы - они для этого?
12 Кб, 640x348>>3625
Не уверен о чем ты, бленд шейпы переносятся. Они не в анимациях, а в пропертях меша (под скином, скелетои), позже ты можешь их анимировать сам.
Не уверен о чем ты, бленд шейпы переносятся. Они не в анимациях, а в пропертях меша (под скином, скелетои), позже ты можешь их анимировать сам.
>>3631
дык а какого хуя они не переносятся в анимациях то? обезьяна пахом там совсем ебанулся что ли, это же основа основ анимации. аниматор делает контент в н-проге и переносит это, в а тут блядь в движке надо допиливать, это же пиздец
дык а какого хуя они не переносятся в анимациях то? обезьяна пахом там совсем ебанулся что ли, это же основа основ анимации. аниматор делает контент в н-проге и переносит это, в а тут блядь в движке надо допиливать, это же пиздец
>>3630
У света есть "слои" (cull mask)
Соответственно помещаешь такой свет на слой 1 и он светит только на объекты слоя 1, и не светит на 0. Террейн придется нарезать как то, аозможно двигать кусок вместе с камерой, как трава рендерится.
У света есть "слои" (cull mask)
Соответственно помещаешь такой свет на слой 1 и он светит только на объекты слоя 1, и не светит на 0. Террейн придется нарезать как то, аозможно двигать кусок вместе с камерой, как трава рендерится.
>>3632
А почему они должны быть в анимациях, когда в блендере это данные групп вершин?
А вообще ответ такой - потому что годот это не блендер и не аддон к блендеру.
А почему они должны быть в анимациях, когда в блендере это данные групп вершин?
А вообще ответ такой - потому что годот это не блендер и не аддон к блендеру.
47 Кб, 700x153>>3633
Спасибо. Вариант геморройный, оставлю его на крайний случай. Сейчас пытаюсь заменить directional на spot и двигать вместе с камерой. Почти то, что нужно, но под необходимым мне углом у него ебучая теневая сыпь лезет, как на пике слева.
Играюсь с настройками пока.
Спасибо. Вариант геморройный, оставлю его на крайний случай. Сейчас пытаюсь заменить directional на spot и двигать вместе с камерой. Почти то, что нужно, но под необходимым мне углом у него ебучая теневая сыпь лезет, как на пике слева.
Играюсь с настройками пока.
>>3632
Не знаю, поищи в issues, а может и исправили уже.
Не знаю, поищи в issues, а может и исправили уже.
>>3630
>>3640
Что КОНКРЕТНО ты хочешь сделать?
Тебе нужна маленькая локация снаружи, тогда как всё остальное время игрок в помещениях? Просто выключи "солнце", когда игрок заходит в помещение без окон. А если тебе для мобилок, наверняка лучше будет нарезать твою большую карту на куски и сделать загрузочные экраны.
А, погоди...
Вообще бред. Я даже на ПК тени в играх отключаю, а на телефоне тени - просто издевательство.
>вот в этом квадрате свети, а в этом не свети
>>3640
>Сейчас пытаюсь заменить directional на spot и двигать вместе с камерой
Что КОНКРЕТНО ты хочешь сделать?
Тебе нужна маленькая локация снаружи, тогда как всё остальное время игрок в помещениях? Просто выключи "солнце", когда игрок заходит в помещение без окон. А если тебе для мобилок, наверняка лучше будет нарезать твою большую карту на куски и сделать загрузочные экраны.
А, погоди...
>для мобильной игры
>нужны реалтаймовые тени
Вообще бред. Я даже на ПК тени в играх отключаю, а на телефоне тени - просто издевательство.
>>3643
Ну может у него артхаус где все дело в тенях
Ну может у него артхаус где все дело в тенях
>>3644
Хотел сперва посоветовать, но это не то. Источник света, изображающий солнце, не находится в какой-либо точке пространства - он считается бесконечно далёким от налюдателя, поэтому у него параллельные лучи света. Поэтому эта настройка только сужает область вокруг наблюдателя (камеры), на которую накладываются тени. Если посмотреть вдаль, дальше этой величины теней никогда не будет. А от пишет, что ему нужны тени в отдельном "квартале".
>настройка shadow max range
Хотел сперва посоветовать, но это не то. Источник света, изображающий солнце, не находится в какой-либо точке пространства - он считается бесконечно далёким от налюдателя, поэтому у него параллельные лучи света. Поэтому эта настройка только сужает область вокруг наблюдателя (камеры), на которую накладываются тени. Если посмотреть вдаль, дальше этой величины теней никогда не будет. А от пишет, что ему нужны тени в отдельном "квартале".
>>3648
Так по идее в топ дауне это и поможет. А если нет, то чанки пилить не так уж сложно. Так то слой объекту на лету менять можно, вечером потестю. Может даже банально enter/exit area обработчика хватит (инб4 нет, это не оптимально, а что если там 3440 объекта)
Так по идее в топ дауне это и поможет. А если нет, то чанки пилить не так уж сложно. Так то слой объекту на лету менять можно, вечером потестю. Может даже банально enter/exit area обработчика хватит (инб4 нет, это не оптимально, а что если там 3440 объекта)
>>3648
Вообще меня давно интересует вопрос как работает атлас directional shadow
Допустим у меня куб кидает тень на плошадку метр на метр. Теперь я добавляю объект в 1000км. Качество тени в эиот момент резко упадет? Ведь атлас старого разрешения теперь натянут на мир в разы больший. И я что то не припомню методов контролировать размер этого "затененного " участка, это черный ящик с автоопределением
Вообще меня давно интересует вопрос как работает атлас directional shadow
Допустим у меня куб кидает тень на плошадку метр на метр. Теперь я добавляю объект в 1000км. Качество тени в эиот момент резко упадет? Ведь атлас старого разрешения теперь натянут на мир в разы больший. И я что то не припомню методов контролировать размер этого "затененного " участка, это черный ящик с автоопределением
>>3640
Скажу честно, за несколько лет и с большим опытом геймдева я подобрать не смог. Так что пока от смены дня ночи отказался. Возможно, надо просто сесть и подобрать массивчик значений на определенный набор углов, скажем с шагом 15 градусов. И это на группы объектов разного вида - и с учетом куда падает тень, на пол или стену, а также вдоль или поперек камеры. Но вот универсального значения похоже не подобрать
Скажу честно, за несколько лет и с большим опытом геймдева я подобрать не смог. Так что пока от смены дня ночи отказался. Возможно, надо просто сесть и подобрать массивчик значений на определенный набор углов, скажем с шагом 15 градусов. И это на группы объектов разного вида - и с учетом куда падает тень, на пол или стену, а также вдоль или поперек камеры. Но вот универсального значения похоже не подобрать
75 Кб, 1544x889Вопрос от юнити-дибила.
Сделал я "префаб" объекта, сохранил в ресурсы. Теперь когда я ставлю его на сцену, он появляеться там закрытой нодой. В юнити было очень удобно оверрайдить проперти у префаба, в данном случае я например хочу поставить уникальный звук каждому обьекту. Как такое вообще делаеться в годоте? Прицеплять к верхней ноде скрипт, который прокидывает оверрайды с моей колокольни какое-то извращение.
Сделал я "префаб" объекта, сохранил в ресурсы. Теперь когда я ставлю его на сцену, он появляеться там закрытой нодой. В юнити было очень удобно оверрайдить проперти у префаба, в данном случае я например хочу поставить уникальный звук каждому обьекту. Как такое вообще делаеться в годоте? Прицеплять к верхней ноде скрипт, который прокидывает оверрайды с моей колокольни какое-то извращение.
>>3671
Есть несколько вариантов
1. Создать Inherited сцену. Не пользуюсь, может аноны пояснят.
2. Можно сделать объект Local to scene, заинстансить его по полной. Это уже будет не префаб
3. Можно сделать его Editable children. Тогда он будет префабом, но конкретику в нем можно перекрыть.
4. Я пользуюсь более программистским способом
В скрипте делаю export настроечных переменных
Сам скрипт tool, то есть работает в редакторе.
Например я могу сделать настройку цвета юнита или выбор спрайта прямо в инспекторе. Есть какие то подводные, не помню какие, мб со вложенными сценами
Есть несколько вариантов
1. Создать Inherited сцену. Не пользуюсь, может аноны пояснят.
2. Можно сделать объект Local to scene, заинстансить его по полной. Это уже будет не префаб
3. Можно сделать его Editable children. Тогда он будет префабом, но конкретику в нем можно перекрыть.
4. Я пользуюсь более программистским способом
В скрипте делаю export настроечных переменных
Сам скрипт tool, то есть работает в редакторе.
Например я могу сделать настройку цвета юнита или выбор спрайта прямо в инспекторе. Есть какие то подводные, не помню какие, мб со вложенными сценами
>>3623
Ну тут загвоздка в том, что анимации Mixamo раздаются только в Fbx. Уж не знаю зачем это адобе.
Ну тут загвоздка в том, что анимации Mixamo раздаются только в Fbx. Уж не знаю зачем это адобе.
>>3696
Адобе забили на миксамо с момента покупки проекта. Все эти годы он ни жив. ни мертв. А жаль. Многообещающая штука была.
Адобе забили на миксамо с момента покупки проекта. Все эти годы он ни жив. ни мертв. А жаль. Многообещающая штука была.
>>3711
Ждут, потом просто лицензию ретроактивно поменяют чтобы 2 цента за каждое проигрывание анимации брать
Ждут, потом просто лицензию ретроактивно поменяют чтобы 2 цента за каждое проигрывание анимации брать
https://godotshaders.com/shader/rotating-billboard-sprite-3d/
Помню пару тредов назад анон спрашивал как вращать билборды в их плоскости. Ну вот кто то шейдер запилил.
https://godotshaders.com/shader/local-space-y-billboard-shader/
И еще вот такой (не очень понял, вроде как его можно положить на любой угол)
Помню пару тредов назад анон спрашивал как вращать билборды в их плоскости. Ну вот кто то шейдер запилил.
https://godotshaders.com/shader/local-space-y-billboard-shader/
И еще вот такой (не очень понял, вроде как его можно положить на любой угол)
>>3659
>>3640
>>3630
В общем, решил свое освещение с помощью spotlight с reverse cull face и включенными тенями, эмбиент освещением через world properties и запеченными то тут то там омнилайтами без теней. Выглядит ок, тени динамичат, свет следует за персонажем без освещения всей огромной сцены, фпс упало с 1500 до 1200 на пеке.
Удивительно на что способна трешка и GLES2. Интересно даже чего там в четвертой годоти с вулканом можно накрутить.
>>3640
>>3630
В общем, решил свое освещение с помощью spotlight с reverse cull face и включенными тенями, эмбиент освещением через world properties и запеченными то тут то там омнилайтами без теней. Выглядит ок, тени динамичат, свет следует за персонажем без освещения всей огромной сцены, фпс упало с 1500 до 1200 на пеке.
Удивительно на что способна трешка и GLES2. Интересно даже чего там в четвертой годоти с вулканом можно накрутить.
>>3696
Конвертируй. Blender вроде поддерживает fbx.
А вообще, мне лично не нравится идея брать анимации с какого-то сайта, тем более бесплатные. Это лишает игру уникальности, тем более если эти анимации используются повсеместно. Лучше запилить кривое говно, но своими руками, чем брать ассеты и флипать как попало, в надежде что незнакомый с играми ньюфаг схавает это.
>анимации Mixamo раздаются только в Fbx
Конвертируй. Blender вроде поддерживает fbx.
А вообще, мне лично не нравится идея брать анимации с какого-то сайта, тем более бесплатные. Это лишает игру уникальности, тем более если эти анимации используются повсеместно. Лучше запилить кривое говно, но своими руками, чем брать ассеты и флипать как попало, в надежде что незнакомый с играми ньюфаг схавает это.
>>3780
Там выше я же и дал скрипт для блендера.
Анимации делать геморнее чем модельки. Да и узнать анимацию ходьбы на другом скелете - это уже надо савантом аутистом быть.
>Конвертируй. Blender вроде поддерживает fbx.
Там выше я же и дал скрипт для блендера.
>А вообще, мне лично не нравится идея брать анимации с какого-то сайта, тем более бесплатные. Это лишает игру уникальности, тем более если эти анимации используются повсеместно.
Анимации делать геморнее чем модельки. Да и узнать анимацию ходьбы на другом скелете - это уже надо савантом аутистом быть.
>>3658
Ничего там не натягивается.
Как работают тени? Это отдельный рендеринг сцены от лица источника света. Т.е. движок поворачивает сцену лицом к источнику света и делает рендеринг всех видимых объектов в чёрном цвете. Затем полученная текстура используется в качестве теней на следующем этапе рендеринга уже от лица твоей игровой камеры. Поэтому источник света умножает число render calls в сцене - движок вынужден рендерить сцену +1 раз для каждого источника света. Чтобы сократить нагрузку на видеокарту, можно сказать "ладно, не рендерь объекты дальше N метров от источника света", а в случае атласа "рендерь дальние объекты в текстуру маленького размера (для скорости), а ближние объекты в текстуру большого размера (для более чётких краёв тени)". DirectionalLight отличается тем, что рендерит сцену в ортогональной проекции вокруг текущей камеры... или что-то вроде того, я точно не знаю.
>атлас directional shadow
>Теперь я добавляю объект в 1000км. Качество тени в эиот момент резко упадет? Ведь атлас старого разрешения теперь натянут на мир
Ничего там не натягивается.
Как работают тени? Это отдельный рендеринг сцены от лица источника света. Т.е. движок поворачивает сцену лицом к источнику света и делает рендеринг всех видимых объектов в чёрном цвете. Затем полученная текстура используется в качестве теней на следующем этапе рендеринга уже от лица твоей игровой камеры. Поэтому источник света умножает число render calls в сцене - движок вынужден рендерить сцену +1 раз для каждого источника света. Чтобы сократить нагрузку на видеокарту, можно сказать "ладно, не рендерь объекты дальше N метров от источника света", а в случае атласа "рендерь дальние объекты в текстуру маленького размера (для скорости), а ближние объекты в текстуру большого размера (для более чётких краёв тени)". DirectionalLight отличается тем, что рендерит сцену в ортогональной проекции вокруг текущей камеры... или что-то вроде того, я точно не знаю.
>>3676
Это ООПышное же. Создаёшь item, который содержит всё необходимое для предметов в твоей игре, а затем - потомков item: knife, sword, shield, pistol, dildo... Если тебе нужно изменить общее для всех item свойство, ты меняешь его в item.tscn и это отразится везде сразу. Оригинальный item.tscn ты нигде использовать скорее всего не будешь, он нужен только как общий предок.
>Создать Inherited сцену. Не пользуюсь, может аноны пояснят.
Это ООПышное же. Создаёшь item, который содержит всё необходимое для предметов в твоей игре, а затем - потомков item: knife, sword, shield, pistol, dildo... Если тебе нужно изменить общее для всех item свойство, ты меняешь его в item.tscn и это отразится везде сразу. Оригинальный item.tscn ты нигде использовать скорее всего не будешь, он нужен только как общий предок.
>>3799
Некоторые моменты непонятны, например если навешивать новый скрипт на инхеритед, он же полностью заменяет старый скрипт. Еще там неочевидности могут быть с editable children
Некоторые моменты непонятны, например если навешивать новый скрипт на инхеритед, он же полностью заменяет старый скрипт. Еще там неочевидности могут быть с editable children
>>3630
>>3741
Я не понял, ты стремился снизить ФПС?
>>3741
Там минимальная сцена больше нагружает, по обещаниям Vulkan лучше масштабируется - т.е. будет производительным на больших сценах, но по факту он оказался даже медленнее OpenGL на больших сценах.
Ключевым разработчикам давно известно:
https://github.com/godotengine/godot/issues/68959#issuecomment-1528132865
>этот свет роняет фпс
>>3741
>решил свое освещение
>фпс упало с 1500 до 1200 на пеке.
Я не понял, ты стремился снизить ФПС?
>>3741
>Интересно даже чего там в четвертой годоти с вулканом можно накрутить.
Там минимальная сцена больше нагружает, по обещаниям Vulkan лучше масштабируется - т.е. будет производительным на больших сценах, но по факту он оказался даже медленнее OpenGL на больших сценах.
Ключевым разработчикам давно известно:
https://github.com/godotengine/godot/issues/68959#issuecomment-1528132865
>>3805
Для этого достаточно сделать так:
Наследуемость сцен касается только tscn файлов.
>если навешивать новый скрипт на инхеритед, он же полностью заменяет старый скрипт
Для этого достаточно сделать так:
>item.gd
>class_name Item extends Node
>dildo.gd
>extends Item
Наследуемость сцен касается только tscn файлов.
981 Кб, 414x498>>3785
Думаю, зависит от требований.
Как будто ты не узнаешь пикрил. А вот если я хочу в игре что-то вроде пикрила, но немного другое, оно на миксамо тоже есть? Вряд ли, там же унылый захват движений с каких-то актёров.
>Анимации делать геморнее чем модельки.
Думаю, зависит от требований.
>Да и узнать анимацию ходьбы на другом скелете - это уже надо савантом аутистом быть.
Как будто ты не узнаешь пикрил. А вот если я хочу в игре что-то вроде пикрила, но немного другое, оно на миксамо тоже есть? Вряд ли, там же унылый захват движений с каких-то актёров.
>>3811
Половины нужных анимаций нет (правда есть некоторые другие сомнительные источники анимаций, но я ими пока не пользовался). Но это все равно в разы быстрее сделать прототип. Анимировать все это пришлось бы неделю или месяц, а так ты сразу качаешь пак и настраиваешь дерево анимаций за день. Будет время или деньги - перерисовывай сколько угодно.
Половины нужных анимаций нет (правда есть некоторые другие сомнительные источники анимаций, но я ими пока не пользовался). Но это все равно в разы быстрее сделать прототип. Анимировать все это пришлось бы неделю или месяц, а так ты сразу качаешь пак и настраиваешь дерево анимаций за день. Будет время или деньги - перерисовывай сколько угодно.
>>3813
А зачем в прототипе анимации? Я несколько лет цинидром по сценам ездил, проверяя свои идеи.
Если у тебя игра, в которой важны анимации героев, тогда их с самого начала нужно делать свои, потому что они влияют на атмосферу игры.
>быстрее сделать прототип
А зачем в прототипе анимации? Я несколько лет цинидром по сценам ездил, проверяя свои идеи.
Если у тебя игра, в которой важны анимации героев, тогда их с самого начала нужно делать свои, потому что они влияют на атмосферу игры.
>>3807
Предыдущий сетап с directional light на всю сцену ронял с 1500 до 800. Этот быстрее, и выглядит ближе к тому, что мне надо.
>Я не понял, ты стремился снизить ФПС?
Предыдущий сетап с directional light на всю сцену ронял с 1500 до 800. Этот быстрее, и выглядит ближе к тому, что мне надо.
>>3820
Ну сам подумай мне надо чтобы человечек ходил. Или пешеходы ходили. Зачем мне тратить время на анимирование их в начале разработки, когда мне надо просто чтобы они "ходили" и это делается двумя кликами?
Ну сам подумай мне надо чтобы человечек ходил. Или пешеходы ходили. Зачем мне тратить время на анимирование их в начале разработки, когда мне надо просто чтобы они "ходили" и это делается двумя кликами?
>>3807
Дауш. Ну, пофиксят. А на текущий проект все равно на тройке сижу.
>https://github.com/godotengine/godot/issues/68959#issuecomment-1528132865
Дауш. Ну, пофиксят. А на текущий проект все равно на тройке сижу.
>>3821
Ты бы лучше сразу на мобилке мерял, а то окажется, что подход на ПК не подходит. Вон там автор Айрон Мита в соседнем треде на соседнем движке писал, что у него перенесли выход на консоли из-за обилия вьюпортов.
Ты бы лучше сразу на мобилке мерял, а то окажется, что подход на ПК не подходит. Вон там автор Айрон Мита в соседнем треде на соседнем движке писал, что у него перенесли выход на консоли из-за обилия вьюпортов.
>>3821
По умолчанию он охватывает только 100 метров вперёд от камеры, дальше теней нет. Не пробовал включать/выключать с помощью Area в зоне?
Покажешь хоть скриншоты? А то все такие деловые, игры делают аж обои отклеиваются, а показать боятся, как будто это на что-то повлияет.
>directional light на всю сцену
По умолчанию он охватывает только 100 метров вперёд от камеры, дальше теней нет. Не пробовал включать/выключать с помощью Area в зоне?
>быстрее, и выглядит ближе к тому, что мне надо.
Покажешь хоть скриншоты? А то все такие деловые, игры делают аж обои отклеиваются, а показать боятся, как будто это на что-то повлияет.
>>3807
У меня от вулкана одни неприятности. На некроноуте не запускается вообще из-за дров, на мобилке 3д не рисовалось, веб версия 4-ки на опенжл недописана. Сначала хотел переходить, но совсем передумал. 4-ка это только для какого-то АА пека гейминга.
У меня от вулкана одни неприятности. На некроноуте не запускается вообще из-за дров, на мобилке 3д не рисовалось, веб версия 4-ки на опенжл недописана. Сначала хотел переходить, но совсем передумал. 4-ка это только для какого-то АА пека гейминга.
>>3823
Ну вот капсулы по маршрутам ездят - и всё. Им не нужно двигать ногами и руками, потому что тебя должно волновать только что они с пути не сбиваются, не застревают и не проваливаются.
А ведь можно вообще не кликать.
>мне надо чтобы человечек ходил.
>Или пешеходы ходили.
>мне надо просто чтобы они "ходили"
Ну вот капсулы по маршрутам ездят - и всё. Им не нужно двигать ногами и руками, потому что тебя должно волновать только что они с пути не сбиваются, не застревают и не проваливаются.
>это делается двумя кликами
А ведь можно вообще не кликать.
Есть какие-то гайды как лучше всего оптимизировать проект именно под веб?
А жуан обитает на каком-нить форуме, чтоб у него напрямую спрашивать дибильные ответы?
>>3829
Допустим, ты сделал пешеходов, вдруг видишь как один пешеход застрял и перебирает ногами в воздухе. Что делать будешь? Включать отображение коллизий. А мог бы просто капсулу оставить...
Алсо, даже ААА игры начинаются с капсул и парящих в Т-позе болванчиков. Почему? "Временные" ассеты с высокой детализацией отвлекают от геймплея, который и нужно в прототипе отточить, поэтому без них проще сфокусироваться на главном. Тебе же в первую очередь геймплей нужен; ножками двигать - это не геймплей, а декорация.
>Зачем мне смотреть на парящие капсулы
Допустим, ты сделал пешеходов, вдруг видишь как один пешеход застрял и перебирает ногами в воздухе. Что делать будешь? Включать отображение коллизий. А мог бы просто капсулу оставить...
Алсо, даже ААА игры начинаются с капсул и парящих в Т-позе болванчиков. Почему? "Временные" ассеты с высокой детализацией отвлекают от геймплея, который и нужно в прототипе отточить, поэтому без них проще сфокусироваться на главном. Тебе же в первую очередь геймплей нужен; ножками двигать - это не геймплей, а декорация.
>>3849
Да, твиттер и мастодон.
Да, твиттер и мастодон.
>>3849
https://godotengine.org/community/
Он много где появляется, но
у него не стоит - во-первых, ему некогда с такими ньюфагами возиться, во-вторых, он не знает всех подробностей движка, т.к. части движка написаны разными людьми в разное время. Так что лучше в публичные коммьюнити заходить, кто-нибудь с достаточным свободным временем поможет.
https://godotengine.org/community/
Он много где появляется, но
>напрямую спрашивать дибильные ответы
у него не стоит - во-первых, ему некогда с такими ньюфагами возиться, во-вторых, он не знает всех подробностей движка, т.к. части движка написаны разными людьми в разное время. Так что лучше в публичные коммьюнити заходить, кто-нибудь с достаточным свободным временем поможет.
>>3849
https://docs.godotengine.org/en/stable/community/channels.html
Как минимум, есть чат контриьюторов. Или если сильно разозлить, написав большую статью, то прямо в гитхабе ответит.
https://docs.godotengine.org/en/stable/community/channels.html
Как минимум, есть чат контриьюторов. Или если сильно разозлить, написав большую статью, то прямо в гитхабе ответит.
>>3850
Ты говоришь о разных вещах. Естественно если я буду отлаживать коллизии, то буду смотреть коллизии. (Пропустим то, что я не говорил, что у меня человечки на физике). Но тебе нужно иметь дерево анимаций. Чтобы оно переключалось с ходьбы на удары на смерть на бег. И вот тут и нужны плейсхолдерные анимации.
Вот как раз чтобы пешеход не перебирал ногами в воздухе - если он застрял, то у него скорость 0 и он должен переключиться в стоять. Или, если ты считаешь, что у тебя тут противоречие, и он хочет идти но не может, пускай подпрыгивает и руками машет, привлекая твое внимание.
Ты говоришь о разных вещах. Естественно если я буду отлаживать коллизии, то буду смотреть коллизии. (Пропустим то, что я не говорил, что у меня человечки на физике). Но тебе нужно иметь дерево анимаций. Чтобы оно переключалось с ходьбы на удары на смерть на бег. И вот тут и нужны плейсхолдерные анимации.
Вот как раз чтобы пешеход не перебирал ногами в воздухе - если он застрял, то у него скорость 0 и он должен переключиться в стоять. Или, если ты считаешь, что у тебя тут противоречие, и он хочет идти но не может, пускай подпрыгивает и руками машет, привлекая твое внимание.
54 Кб, 942x222>>3849
Здесь официально сказано, что ты можешь сконтактироваться с ними за платной поддержкой, включая почасовую. Правда, это писалось до основания W4, но думаю это уже детали, с каким юрлицом договор.
Здесь официально сказано, что ты можешь сконтактироваться с ними за платной поддержкой, включая почасовую. Правда, это писалось до основания W4, но думаю это уже детали, с каким юрлицом договор.
>>3854
Дискорд полезней чата котрибьюторов. В рокете они пулл реквесты обсуждают, а в дискорде толпы пользователей движка, кто-нибудь да поможет.
Ненавижу ебучий дискорд с его ублюдочным поиском.
Дискорд полезней чата котрибьюторов. В рокете они пулл реквесты обсуждают, а в дискорде толпы пользователей движка, кто-нибудь да поможет.
Ненавижу ебучий дискорд с его ублюдочным поиском.
>>3858
Не люблю дискорды как то заходил в некоторые и задавал вопрос но его все проигнорили потому что местный ероха в это время анекдоты рассказывал и все ему отвечали.
Не люблю дискорды как то заходил в некоторые и задавал вопрос но его все проигнорили потому что местный ероха в это время анекдоты рассказывал и все ему отвечали.
>>3820
Я собираюсь сделать несколько штук для Я.Игр, как думаешь я буду заморачиваться с модельками и анимациями? Нет, я буду ассетфлипать все что можно. И только потом уже вернусь к игре мечты, которую пилю уже несколько лет.
Я собираюсь сделать несколько штук для Я.Игр, как думаешь я буду заморачиваться с модельками и анимациями? Нет, я буду ассетфлипать все что можно. И только потом уже вернусь к игре мечты, которую пилю уже несколько лет.
>>3870
Как там с аудиторией? Я полистал их главную страницу, игры в основном какой-то сблев полурабочий. Неужели там люди активно играют?
>Я.Игр
Как там с аудиторией? Я полистал их главную страницу, игры в основном какой-то сблев полурабочий. Неужели там люди активно играют?
>>3675
Недооцененный пост треда. Принялись какую-то хуйню обсуждать. Двачую этот пост.
Недооцененный пост треда. Принялись какую-то хуйню обсуждать. Двачую этот пост.
>>3827
Сеймщит. Джва месяца уже вожусь с четвёркой и всё очевиднее вырисовывается, что трёшка лучше. В четвёрке поломали сортировку интеллисенца. Вот тупо пишу pri и мне автодополняет как print() а в четвёрке простой print() в списке автодополнения торчит внизу. Что это? И так в большинстве случаев. Раньше в автодополнении очевидные частоиспользуемые строки подбивались вверх. Сейчас нет. Удобство кодинга скатилось в нулину. Версия уже 4.1.1 а трогать нет желания.
В код насрали спецсимволов. Непонятно ради чего? Похоже на саботаж. Был элегантный язык onready var foo. Теперь @onready. Нахуя? Чтобы что? Посмотрев на эти приколы руки опускаются просто.
В трёшку завезли асинхронную компиляцию+кэш шейдеров. В четвёрке с вулканом якобы это не надо. Я не поленился и скачал TPS Demo. И что я вижу? На хвалёном вулкане, при первом выстреле что? Оно самое. ПРОЛАГ ленивой компиляции шейдера пульки. А в трёшке нет. TPS Demo идёт ровно. Первый выстрел шмаляет уже предпрогруженным.
Короче. Четвёрка станет боли-лимени работоспособна года через два, не раньше, как трёшка, только через два года после релиза стала норм, а до того все олды на двушке ебашили по хардкору.
Сеймщит. Джва месяца уже вожусь с четвёркой и всё очевиднее вырисовывается, что трёшка лучше. В четвёрке поломали сортировку интеллисенца. Вот тупо пишу pri и мне автодополняет как print() а в четвёрке простой print() в списке автодополнения торчит внизу. Что это? И так в большинстве случаев. Раньше в автодополнении очевидные частоиспользуемые строки подбивались вверх. Сейчас нет. Удобство кодинга скатилось в нулину. Версия уже 4.1.1 а трогать нет желания.
В код насрали спецсимволов. Непонятно ради чего? Похоже на саботаж. Был элегантный язык onready var foo. Теперь @onready. Нахуя? Чтобы что? Посмотрев на эти приколы руки опускаются просто.
В трёшку завезли асинхронную компиляцию+кэш шейдеров. В четвёрке с вулканом якобы это не надо. Я не поленился и скачал TPS Demo. И что я вижу? На хвалёном вулкане, при первом выстреле что? Оно самое. ПРОЛАГ ленивой компиляции шейдера пульки. А в трёшке нет. TPS Demo идёт ровно. Первый выстрел шмаляет уже предпрогруженным.
Короче. Четвёрка станет боли-лимени работоспособна года через два, не раньше, как трёшка, только через два года после релиза стала норм, а до того все олды на двушке ебашили по хардкору.
>>3908
Поддерживаю. Пока платформа новая с кучей шлака, ты реально можешь стать легендой, запилив туда годноту.
Поддерживаю. Пока платформа новая с кучей шлака, ты реально можешь стать легендой, запилив туда годноту.
Там у эпиков массовые сокращения штата пошли. Уже предвижу ввод процента за установку игры на Унрыл Ынжине.
Годоти, вы готовы к новым беженцам?
Годоти, вы готовы к новым беженцам?
>>3926
Ну тут Хуан предвидел или имел инсайд, предусмотрительно выпилив вижуал скрипт. А плюсовики хорошо, такие могут сильно бустануть движок, в отличии от шарпомух сами знаете откуда
Ну тут Хуан предвидел или имел инсайд, предусмотрительно выпилив вижуал скрипт. А плюсовики хорошо, такие могут сильно бустануть движок, в отличии от шарпомух сами знаете откуда
>>3930
Хуан какой-то серый кардинал от геймдева нахуй.
Хуан какой-то серый кардинал от геймдева нахуй.
>>3972 (Del)
Похуй, еще слово и в бан.
Похуй, еще слово и в бан.
>>3907
Если кратко, они ввели механизм аннотаций, чтобы перенести часть ключевых слов в аннотации, т.к. парсить все ключевые слова стало слишком сложно, особенно такие сложные, как export. Планировалось сделать это ещё в 2017/2018 году, ты просто не в теме.
Большинство поддержало:
https://github.com/godotengine/godot/issues/20318
https://github.com/godotengine/godot-proposals/issues/828
>В код насрали спецсимволов. Непонятно ради чего? Похоже на саботаж. Был элегантный язык onready var foo. Теперь @onready. Нахуя? Чтобы что? Посмотрев на эти приколы руки опускаются просто.
Если кратко, они ввели механизм аннотаций, чтобы перенести часть ключевых слов в аннотации, т.к. парсить все ключевые слова стало слишком сложно, особенно такие сложные, как export. Планировалось сделать это ещё в 2017/2018 году, ты просто не в теме.
Большинство поддержало:
https://github.com/godotengine/godot/issues/20318
https://github.com/godotengine/godot-proposals/issues/828
>>3972 (Del)
>>3973 (Del)
>>3970 (Del)
Тут не крутость движка главное, а удобство. В этом разрабы годота правы. Нужно чтобы движком мог пользоваться не 100500 айкью гений квантового матана, а средний васян, как вы и я.
Вон, есть движок от того самого КРУЗИСА ЕБАНЫЙ В РОТ. Он же CryEngine, он же Lumberyard, он же O3DE - теперь даже опенсорсный. И никому нахуй не нужен, потому что без выворачивания наизнанку через жопу ты там банально спрайт не сдвинешь.
Так что сидите пилите игры на годоте и не бухтите, у Хуана все схвачено.
>>3973 (Del)
>>3970 (Del)
Тут не крутость движка главное, а удобство. В этом разрабы годота правы. Нужно чтобы движком мог пользоваться не 100500 айкью гений квантового матана, а средний васян, как вы и я.
Вон, есть движок от того самого КРУЗИСА ЕБАНЫЙ В РОТ. Он же CryEngine, он же Lumberyard, он же O3DE - теперь даже опенсорсный. И никому нахуй не нужен, потому что без выворачивания наизнанку через жопу ты там банально спрайт не сдвинешь.
Так что сидите пилите игры на годоте и не бухтите, у Хуана все схвачено.
>>3985
Там в системных требованиях минимум 100 Гб для сборки, либо 40 Гб "using the pre-built installer":
https://www.docs.o3de.org/docs/welcome-guide/requirements/
А ведь это ещё компилировать... а это C++...
Крузис стал мемом из-за высокой нагрузки на видеокарту, а не из-за какой-то особой крутизны.
>O3DE - теперь даже опенсорсный
Там в системных требованиях минимум 100 Гб для сборки, либо 40 Гб "using the pre-built installer":
https://www.docs.o3de.org/docs/welcome-guide/requirements/
А ведь это ещё компилировать... а это C++...
>от того самого КРУЗИСА
Крузис стал мемом из-за высокой нагрузки на видеокарту, а не из-за какой-то особой крутизны.
>>3971 (Del)
Нет, анон, самое главное все забыли - ID Tech. Молодёжь.
>>3907
Помню, было в районе 3.3 какое-то обновление, там писали типа "всё, переключаем внимание на четвёрку, а тут теперь только улучшение производительности". И как улучшили, я аж прихуел, оно запускаться стало вообще моментально.
>Блять, как я мог самое главное забыть?
Нет, анон, самое главное все забыли - ID Tech. Молодёжь.
>>3907
>Короче. Четвёрка
Помню, было в районе 3.3 какое-то обновление, там писали типа "всё, переключаем внимание на четвёрку, а тут теперь только улучшение производительности". И как улучшили, я аж прихуел, оно запускаться стало вообще моментально.
>>1894 (OP)
Есть ли Y Sort Original или что-то подобное для тайлсетов в 3.5?
Есть ли Y Sort Original или что-то подобное для тайлсетов в 3.5?
>>1894 (OP)
Привет годотоаноны!
Прошу совета, на сколько приятно, быстро можно на годоте сделать трехмерный мультплеерный шутер? Просто приключение на 15 минут, зашел, пострелял, вышел. Я сейчас на анриле, и осваиваю его, пока не далеко зашел. Присматриваюсь к годоту, нравится его минимализм.
Привет годотоаноны!
Прошу совета, на сколько приятно, быстро можно на годоте сделать трехмерный мультплеерный шутер? Просто приключение на 15 минут, зашел, пострелял, вышел. Я сейчас на анриле, и осваиваю его, пока не далеко зашел. Присматриваюсь к годоту, нравится его минимализм.
>>4024
На любом движке заебешься, а если не заебешься, то твой шутер поставит раком первый же школочитер.
>мультплеерный
На любом движке заебешься, а если не заебешься, то твой шутер поставит раком первый же школочитер.
>>4024
Ну смотри, для сессионки на 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, также ты можешь копаться в исходниках и собирать движок сам, но в твоём случае это скорее всего вообще не понадобится.
>трехмерный мультплеерный шутер
>Просто приключение на 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, также ты можешь копаться в исходниках и собирать движок сам, но в твоём случае это скорее всего вообще не понадобится.
>>4024
Ну смотри, для сессионки на 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, также ты можешь копаться в исходниках и собирать движок сам, но в твоём случае это скорее всего вообще не понадобится.
>трехмерный мультплеерный шутер
>Просто приключение на 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, также ты можешь копаться в исходниках и собирать движок сам, но в твоём случае это скорее всего вообще не понадобится.
>>4043
Спасибо!
Спасибо!
>>4024
Проще всего порыться в ассетах и репозиториях, я там насчитывал штук 5 демок мультиплеера. Могу ближе к ночи посмотреть какие скачивал. И потом поверх них навернуть свою игру.
Проще всего порыться в ассетах и репозиториях, я там насчитывал штук 5 демок мультиплеера. Могу ближе к ночи посмотреть какие скачивал. И потом поверх них навернуть свою игру.
>>4178
Все правильно делаете. Я тоже посреди ночи.
Все правильно делаете. Я тоже посреди ночи.
Боюсь начинать делать 3д игру.
Сам в блендере не работал и в целом в моделировании или рисовании ноль, поэтому надо будет брать ассеты и анимации откуда-то... Либо учиться делать простые модели, но это дел на месяц, страшно думать о том, что чтобы сделать простую тестовую игру придется целый месяц учиться новому скиллу
Сам в блендере не работал и в целом в моделировании или рисовании ноль, поэтому надо будет брать ассеты и анимации откуда-то... Либо учиться делать простые модели, но это дел на месяц, страшно думать о том, что чтобы сделать простую тестовую игру придется целый месяц учиться новому скиллу
Вкатываюсь в этот ваш годот, за вчера и сегодня разобрал первые уроки и почти доделал 2д игру из офф гайда. При этом даже что то понял в части скриптов, но общая логика работы главной сцены и узлов туманна, как оно там все с друг другом работает не понятно.
Есть ряд вопросов по планируемой игре мечты. Скажу прямо, планирую 2д порно игру с видом сверху, сначала думал вкатываться в рпг мейкер но вовремя одумался.
Насколько сложно реализовать диалоги как в визуальных новеллах, с выборами, картинками и прочим, инвентарь, простенькую боевую систему хотя бы по типу камень ножницы бумага?
Ну и вопрос не по движку, очевидно, что визуал должен быть на уровне чтобы можно было дрочить, а я не особо художник, поэтому надеюсь на нейросети, подскажите, какие из них могут внятные 18+ 2д картинки для игры сделать.
Есть ряд вопросов по планируемой игре мечты. Скажу прямо, планирую 2д порно игру с видом сверху, сначала думал вкатываться в рпг мейкер но вовремя одумался.
Насколько сложно реализовать диалоги как в визуальных новеллах, с выборами, картинками и прочим, инвентарь, простенькую боевую систему хотя бы по типу камень ножницы бумага?
Ну и вопрос не по движку, очевидно, что визуал должен быть на уровне чтобы можно было дрочить, а я не особо художник, поэтому надеюсь на нейросети, подскажите, какие из них могут внятные 18+ 2д картинки для игры сделать.
>>4272
Для ветвистых диалогов есть плагин - Dialogic, фактически на всем готовом ехать будешь. Но да, твоя главная проблема - арт. Вроде stablediffusion умеет в прон. Видел у анонов с форча гайды. Покопайся тут:
https://boards.4channel.org/g/thread/96309968
https://boards.4channel.org/g/thread/96312849
Полные нюдесы они там не постят потому что борда синяя.
Для ветвистых диалогов есть плагин - Dialogic, фактически на всем готовом ехать будешь. Но да, твоя главная проблема - арт. Вроде stablediffusion умеет в прон. Видел у анонов с форча гайды. Покопайся тут:
https://boards.4channel.org/g/thread/96309968
https://boards.4channel.org/g/thread/96312849
Полные нюдесы они там не постят потому что борда синяя.
>>4275
Спасибо! Буду изучать, хватило бы только моей ноутбучной затычки mx250 на рендер
Спасибо! Буду изучать, хватило бы только моей ноутбучной затычки mx250 на рендер
>>4227
Во первых не бойся, не кусает.
Во вторых год это разве срок для такого навыка?
Делай по чуть чуть. Научись вставлять готовую модельку с анимацией. Научись добавлять другую готовую анимацию. Сделай свою анимацию. Сделай бублик из куба по гайду.Сделай свою модельку по гайду лоуполи за час. Сделай ей скелет для анимаций. Сами по себе это несложные задачи на час-день, надо только разобраться. Пара видосов для вдохновения
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
Да, с первого раза не все понятно, не стесняйся ставить на паузу, пересматривать. Ищи другие если эти не понравятся.
Во первых не бойся, не кусает.
Во вторых год это разве срок для такого навыка?
Делай по чуть чуть. Научись вставлять готовую модельку с анимацией. Научись добавлять другую готовую анимацию. Сделай свою анимацию. Сделай бублик из куба по гайду.Сделай свою модельку по гайду лоуполи за час. Сделай ей скелет для анимаций. Сами по себе это несложные задачи на час-день, надо только разобраться. Пара видосов для вдохновения
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
Да, с первого раза не все понятно, не стесняйся ставить на паузу, пересматривать. Ищи другие если эти не понравятся.
281 Кб, 634x400>>4281
>Сделай свою анимацию. Сделай бублик из куба по гайду.Сделай свою модельку по гайду лоуполи за час. Сделай ей скелет для анимаций.
C виртуальными тач-стиками кто работал? Почему они ощущаются будто маслом намазанные? Это реально так люди играют на мобилках, или я что-то упускаю?
Поясните или скиньте гайд на логику сцен и узлов. Вот я накидал себе план из того, что хочу реализовать в игре. Мне начинать с отдельных элементов, а последная и главная сцена это будет главный экран, где после нажатия новой игры все запустится?
>>4436
надеюсь, что ты знаешь, что такое структура дерево, если нет, то погугли картинку
так вот твоя игра всегда содержит такое дерево, когда запущена, туда помещаются ноды - узлы этого дерева
корнем дерева является нода subviewport, только она тебе не отображается, считай, что ты просто к ней достраиваешь дерево своей игры
сцена - это точно такая же нода в твоем дереве со своими дочерними узлами, просто выделили так, чтобы удобнее было загрузить и выгрузить по необходимости
как именно в своей игре будешь формировать это дерево - зависит от задачи, можешь например создать в игре базовый узел node, в нем напишешь скрипт, который будет к нему загружать и выгружать сцены твоей игры (сцену главного меню, сцену уровня ...)
в принципе в ассетах есть много реализаций подобных штук, которых можно поискать по фразам "state ..." и тому подобных
надеюсь, что ты знаешь, что такое структура дерево, если нет, то погугли картинку
так вот твоя игра всегда содержит такое дерево, когда запущена, туда помещаются ноды - узлы этого дерева
корнем дерева является нода subviewport, только она тебе не отображается, считай, что ты просто к ней достраиваешь дерево своей игры
сцена - это точно такая же нода в твоем дереве со своими дочерними узлами, просто выделили так, чтобы удобнее было загрузить и выгрузить по необходимости
как именно в своей игре будешь формировать это дерево - зависит от задачи, можешь например создать в игре базовый узел node, в нем напишешь скрипт, который будет к нему загружать и выгружать сцены твоей игры (сцену главного меню, сцену уровня ...)
в принципе в ассетах есть много реализаций подобных штук, которых можно поискать по фразам "state ..." и тому подобных
>>4461
у нас в команде новый проект начинают на гдскрипте, потом критичные участки переносят на плюсы (хотя большая часть требуемых задач уже перенесена, так что от программиста требуется только по больше части поддержка)
прямо писать особых проблем нет, хотя совсем верхнюю логику все равно проще держать в скриптах или модинг игры, если предусматривается
а так пишешь модули к движку и дергаешь
можно хоть сам движок собрать с нужными кусками в том числе своими, только там еще питон накатить нужно будет для системы сборки вроде бы
у нас в команде новый проект начинают на гдскрипте, потом критичные участки переносят на плюсы (хотя большая часть требуемых задач уже перенесена, так что от программиста требуется только по больше части поддержка)
прямо писать особых проблем нет, хотя совсем верхнюю логику все равно проще держать в скриптах или модинг игры, если предусматривается
а так пишешь модули к движку и дергаешь
можно хоть сам движок собрать с нужными кусками в том числе своими, только там еще питон накатить нужно будет для системы сборки вроде бы
370 Кб, 1920x1080>>4461
Вполне комфортно пишется, насколько это применимо к c++ в принципе, после единоразовой долгой настройки.
Я писал как то как у меня сделано. Игровая логика на c++ и она отделена от движков (там ecs модель мира и сущностей) собирается в dll/so.
И вторая либа, которая scons собирает gdnative/gdextension, эта либа инклюдит Godot.hpp, она дергает логику первой либы, при этом видна для гдскрипта как обычный класс. Гуй обычные сцены с гдскриптом. Итого MVVC. Пишу я в vscode или geany, сборка 5 секунд батником.
Также в качестве эксперимента я пепеписывал 1 в 1 туториалы, без особых проблем, но полностью так писать игру дольше, чем на гдскрипте, еще думать про все эти Ref<Type> и memnew()
Вполне комфортно пишется, насколько это применимо к c++ в принципе, после единоразовой долгой настройки.
Я писал как то как у меня сделано. Игровая логика на c++ и она отделена от движков (там ecs модель мира и сущностей) собирается в dll/so.
И вторая либа, которая scons собирает gdnative/gdextension, эта либа инклюдит Godot.hpp, она дергает логику первой либы, при этом видна для гдскрипта как обычный класс. Гуй обычные сцены с гдскриптом. Итого MVVC. Пишу я в vscode или geany, сборка 5 секунд батником.
Также в качестве эксперимента я пепеписывал 1 в 1 туториалы, без особых проблем, но полностью так писать игру дольше, чем на гдскрипте, еще думать про все эти Ref<Type> и memnew()
>>1894 (OP)
Я уже спрашивал, но вопрос скорее всего никто не заметил. Как в годо поставить точку с которой будет сортироваться по Y тайлы для каждого тайла?
Я уже спрашивал, но вопрос скорее всего никто не заметил. Как в годо поставить точку с которой будет сортироваться по Y тайлы для каждого тайла?
>>4531
Я тот раз заметил, но так и не понял, что ты хочешь.
>вопрос скорее всего никто не заметил.
>поставить точку с которой будет сортироваться по Y тайлы для каждого тайла
Я тот раз заметил, но так и не понял, что ты хочешь.
>>4436
В разработке есть два подхода:
https://en.wikipedia.org/wiki/Bottom-up_and_top-down_design
Сверху-вниз: от главной сцены к отдельным нодам.
Снизу-вверх: от отдельных нод к главной сцене.
Godot поощряет подход снизу-вверх, но его можно использовать и в подходе сверху-вниз. На практике удобнее смешивать, что-то делая в виде пустышки и дополняя деталями, что-то делая мелкими частями и объединяя их в одну большую систему. Выбирай сам.
>Мне начинать с отдельных элементов, а последная и главная сцена это будет главный экран, где после нажатия новой игры все запустится?
В разработке есть два подхода:
https://en.wikipedia.org/wiki/Bottom-up_and_top-down_design
Сверху-вниз: от главной сцены к отдельным нодам.
Снизу-вверх: от отдельных нод к главной сцене.
Godot поощряет подход снизу-вверх, но его можно использовать и в подходе сверху-вниз. На практике удобнее смешивать, что-то делая в виде пустышки и дополняя деталями, что-то делая мелкими частями и объединяя их в одну большую систему. Выбирай сам.
>>4459
>>4640
Спасибо аноны! Более менее разбираюсь. Сейчас в тупике по поводу коллизий, мой игрок (characterbody 2d) почему то проходит сквозь объекты, хотя если я создам rigidbody 2d и на него накину скрипт управления, то он уже нормально себя ведёт. Маски и слои настроены одинаково, 2д вид сверху с 0 гравитацией если это важно
>>4640
Спасибо аноны! Более менее разбираюсь. Сейчас в тупике по поводу коллизий, мой игрок (characterbody 2d) почему то проходит сквозь объекты, хотя если я создам rigidbody 2d и на него накину скрипт управления, то он уже нормально себя ведёт. Маски и слои настроены одинаково, 2д вид сверху с 0 гравитацией если это важно
>>4644
Все починилось само, если вчера ничего не работало, то сегодня вдруг стало работать как должно
Все починилось само, если вчера ничего не работало, то сегодня вдруг стало работать как должно
31 Кб, 573x324Написал скрипт для перехода с подтверждением по кнопке, оцените. учусь писать скрипты
>>4710
В целом всё верно.
В этот скрипт ещё прикрутить бы таблицу базы данных с именами сцен, куда возможно переходить, и менеджер сцен, который по имени производит фоновую загрузку сцены, и будет ваще мидл-левел.
В целом всё верно.
В этот скрипт ещё прикрутить бы таблицу базы данных с именами сцен, куда возможно переходить, и менеджер сцен, который по имени производит фоновую загрузку сцены, и будет ваще мидл-левел.
>>4636
Просто при сортировки тайлов в ноде Y-sort они используют точку сортировки из настроен tilemap, а именно настройки tile original и она для всех тайлов из tilemap одинаковая. А я хочу установить её для некоторых тайлов в другом месте. Например, не в центе, а в левом верхнем углу
Просто при сортировки тайлов в ноде Y-sort они используют точку сортировки из настроен tilemap, а именно настройки tile original и она для всех тайлов из tilemap одинаковая. А я хочу установить её для некоторых тайлов в другом месте. Например, не в центе, а в левом верхнем углу
Делайте игры. Я последнее время не делал, но сейчас начну.
Призываю в тред раст-куна, которого видел на неделе в каком-то из тредов. Раст-кун, приди. Научи как сделать свою сбоpку с волшебной интерполированной дельтой и скриптингом на расте.
21 Кб, 839x280про GL Compatibility написано на чем он основывается при рендере, а другие что используют?
Forward видимо старается максимальный на платформе использовать типа DX на винде, Metal на маке или они все там в основе имеют Angle и просто разные прослойки вызовов с разным функционалом?
Forward видимо старается максимальный на платформе использовать типа DX на винде, Metal на маке или они все там в основе имеют Angle и просто разные прослойки вызовов с разным функционалом?
>>4805
Forward и Mobile - два разных набора настроек Vulkan.
Подробнее: https://www.vulkan.org/
Наследник OpenGL от Khronos Group, он же glNext.
>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.
>>4808
да я в курсе, что такое вулкан, вопрос-то не в том был
да я в курсе, что такое вулкан, вопрос-то не в том был
>>4710
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 имеет смысл только в очень простых играх с уровнями, где игрок стартует всегда в одном состоянии. В более сложной игре придётся переносить данные между локациями и сохранять предыдущее состояние локации. Просто напоминаю.
>>4712
Зачем? У него этот скрипт висит на флажке в конце уровня, что-то по типу Марио получается.
Зачем? В игре типа Марио лучше дать подождать загрузки уровня в конце уровня, чем тормозить игру асинхронной загрузкой в процессе уровня. Другое дело, сюда бы загрузочный экран прикрутить, если уровни действительно большие и долго грузятся...
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 имеет смысл только в очень простых играх с уровнями, где игрок стартует всегда в одном состоянии. В более сложной игре придётся переносить данные между локациями и сохранять предыдущее состояние локации. Просто напоминаю.
>>4712
>ещё прикрутить бы таблицу базы данных с именами сцен, куда возможно переходить
Зачем? У него этот скрипт висит на флажке в конце уровня, что-то по типу Марио получается.
>менеджер сцен, который по имени производит фоновую загрузку сцены
Зачем? В игре типа Марио лучше дать подождать загрузки уровня в конце уровня, чем тормозить игру асинхронной загрузкой в процессе уровня. Другое дело, сюда бы загрузочный экран прикрутить, если уровни действительно большие и долго грузятся...
>>4710
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 имеет смысл только в очень простых играх с уровнями, где игрок стартует всегда в одном состоянии. В более сложной игре придётся переносить данные между локациями и сохранять предыдущее состояние локации. Просто напоминаю.
>>4712
Зачем? У него этот скрипт висит на флажке в конце уровня, что-то по типу Марио получается.
Зачем? В игре типа Марио лучше дать подождать загрузки уровня в конце уровня, чем тормозить игру асинхронной загрузкой в процессе уровня. Другое дело, сюда бы загрузочный экран прикрутить, если уровни действительно большие и долго грузятся...
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 имеет смысл только в очень простых играх с уровнями, где игрок стартует всегда в одном состоянии. В более сложной игре придётся переносить данные между локациями и сохранять предыдущее состояние локации. Просто напоминаю.
>>4712
>ещё прикрутить бы таблицу базы данных с именами сцен, куда возможно переходить
Зачем? У него этот скрипт висит на флажке в конце уровня, что-то по типу Марио получается.
>менеджер сцен, который по имени производит фоновую загрузку сцены
Зачем? В игре типа Марио лучше дать подождать загрузки уровня в конце уровня, чем тормозить игру асинхронной загрузкой в процессе уровня. Другое дело, сюда бы загрузочный экран прикрутить, если уровни действительно большие и долго грузятся...
>>4710
Почитай вот это ещё:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
Можно где-то в настройках редактора включить добавление типов в заголовки стандартных функций.
>>4813
Ещё лучше будет сделать так:
Потому что значение флага известно заранее, а метод класса Input требует какой-то дополнительной работы. Поскольку выражение у нас and, если первый элемент false, то результат тоже false. Интерпретатор имеет возможность оптимизировать этот момент, исключив лишнюю работу по вызову функции. Хотя происходит ли это в GDScript - не знаю, но если нет, можно разбить условие на два: if victory_achived: if Input.is_action...
...вообще, самое главное я не увидел сразу: вместо _process здесь следует использовать _unhandled_input:
Потому что _process происходит столько раз в секунду, сколько игра рендерит кадров, а _input срабатывает только при нажатии клавиш, и в свою очередь _unhandled_input работает только когда остальные элементы сцены проигнорировали нажатие клавиши.
Почитай вот это ещё:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
Можно где-то в настройках редактора включить добавление типов в заголовки стандартных функций.
>>4813
>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 работает только когда остальные элементы сцены проигнорировали нажатие клавиши.
>>4710 >>4817
А вообще, я бы сделал так:
1. Попадание игрока в финишную зону открывает окно "вы победили, перейти на следующий уровень?"
2. Игрок всё ещё может двигаться, если он уходит, окно скрывается, либо игрок может сам его убрать.
3. Скрипт перехода на следующий уровень - это уже часть окна "вы победили", а не часть финишной зоны.
Таким образом можно повторно использовать то же окно с тем же кодом для любого другого условия победы, вроде того, что игрок съел всю еду на уровне, убил всех мобов или выполнил все задания. Флажок в стиле Марио только вызывает это окно, ничего не зная о предназначении и дальнейших действиях окна.
А вообще, я бы сделал так:
1. Попадание игрока в финишную зону открывает окно "вы победили, перейти на следующий уровень?"
2. Игрок всё ещё может двигаться, если он уходит, окно скрывается, либо игрок может сам его убрать.
3. Скрипт перехода на следующий уровень - это уже часть окна "вы победили", а не часть финишной зоны.
Таким образом можно повторно использовать то же окно с тем же кодом для любого другого условия победы, вроде того, что игрок съел всю еду на уровне, убил всех мобов или выполнил все задания. Флажок в стиле Марио только вызывает это окно, ничего не зная о предназначении и дальнейших действиях окна.
>>4753
Как это вообще связано? Нода 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 с другими настройками?
>при сортировки тайлов в ноде 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 с другими настройками?
>>4819
>>4817
>>4813
>>4712
Спасибо за оценки, подправил немного
Пока что для меня это вообще темный лес
переменную с _ я подсмотрел в гайде,поэтому так и написал, а самому ставить _ постоянно меня угнетает, Взоне буквально значит в зоне (рядом с дверью)
Я честно попытался понять как это работает и чем будет лучше в моем случае и не смог.
единственный язык который я немного знаю это школьный паскаль, поэтому так пишу, а как упрощать я вообще не понял, так для меня код логику сразу теряет
Дополнительно прикрутил картинку-подсказку нажать кнопку для перехода, у меня 2д вид сверху с открытым миром если что, на примере это вход в здание. сами иконки и скрипт отдельной сценой, планирую во всех переходах ее ставить. И да, все спрайты всратые потому что я их спиздил на скорую руку. Сейчас даже не игру делаю, а технодемку, чтобы освоить механики, как доделаю, скину сюда проект я тот анон с порноигрой
>>4817
>>4813
>>4712
Спасибо за оценки, подправил немного
>менеджер сцен и фоновая загрузка
Пока что для меня это вообще темный лес
>разные названия переменных
переменную с _ я подсмотрел в гайде,поэтому так и написал, а самому ставить _ постоянно меня угнетает, Взоне буквально значит в зоне (рядом с дверью)
>unhandled_input
Я честно попытался понять как это работает и чем будет лучше в моем случае и не смог.
>переусложнение условий
единственный язык который я немного знаю это школьный паскаль, поэтому так пишу, а как упрощать я вообще не понял, так для меня код логику сразу теряет
Дополнительно прикрутил картинку-подсказку нажать кнопку для перехода, у меня 2д вид сверху с открытым миром если что, на примере это вход в здание. сами иконки и скрипт отдельной сценой, планирую во всех переходах ее ставить. И да, все спрайты всратые потому что я их спиздил на скорую руку. Сейчас даже не игру делаю, а технодемку, чтобы освоить механики, как доделаю, скину сюда проект я тот анон с порноигрой
>>4838
Автодополнение в коде позволяет быстро набирать код, не набирая большую часть символов в словах.
Ясно, я неправильно понял.
Вот смотри, допустим, у тебя частота кадров 60. На твоей карте одна дверь, значит, ты 60 раз в секунду проверяешь условие:
Если ты добавишь вторую дверь, эта проверка будет гоняться уже 120 раз в секунду. 10 дверей - 600 раз в секунду. Если теперь твою игру с десятью дверьми запустить на компьютере с монитором 120 Гц, тогда у тебя будет уже 1200 проверок в секунду.
А самое главное, тебе 99.99999% этих операций не нужны, т.к. игрок переходит от двери к двери редко. Так что ты просто впустую гоняешь процессор.
Yandere Simulator знаешь? Там одно время были дичайщие тормоза от того, что каждый студент 60 раз в секунду "смотрел на часы", чтобы узнать, не пора ли ему отправиться на урок - здесь суть та же.
Я тоже с него начинал, там всё так же работает.
Почему теряет-то? Ты буквально пишешь:
Зачем тебе писать Vzone==true, если ты можешь ПРОСТО написать Vzone и смысл будет тот же?
Ну так бы сразу и сказал, что jRPG, там простым переключением сцен лучше ничего не делать. Нужно специальный менеджер писать, чтобы все состояния сохранялись и переходы были достаточно быстрыми.
Нормальные спрайты для таких игр. Мне нравится.
>самому ставить _ постоянно меня угнетает
Автодополнение в коде позволяет быстро набирать код, не набирая большую часть символов в словах.
>Взоне буквально значит в зоне (рядом с дверью)
Ясно, я неправильно понял.
>чем будет лучше в моем случае
Вот смотри, допустим, у тебя частота кадров 60. На твоей карте одна дверь, значит, ты 60 раз в секунду проверяешь условие:
>if Input.is_action_pressed()...
Если ты добавишь вторую дверь, эта проверка будет гоняться уже 120 раз в секунду. 10 дверей - 600 раз в секунду. Если теперь твою игру с десятью дверьми запустить на компьютере с монитором 120 Гц, тогда у тебя будет уже 1200 проверок в секунду.
А самое главное, тебе 99.99999% этих операций не нужны, т.к. игрок переходит от двери к двери редко. Так что ты просто впустую гоняешь процессор.
Yandere Simulator знаешь? Там одно время были дичайщие тормоза от того, что каждый студент 60 раз в секунду "смотрел на часы", чтобы узнать, не пора ли ему отправиться на урок - здесь суть та же.
>единственный язык который я немного знаю это школьный паскаль, поэтому так пишу
Я тоже с него начинал, там всё так же работает.
>а как упрощать я вообще не понял, так для меня код логику сразу теряет
Почему теряет-то? Ты буквально пишешь:
>ЕСЛИ нажата клавиша Enter И игрок находится в зоне действия двери ТОГДА: загрузить комнату
Зачем тебе писать Vzone==true, если ты можешь ПРОСТО написать Vzone и смысл будет тот же?
>2д вид сверху с открытым миром
>это вход в здание
Ну так бы сразу и сказал, что jRPG, там простым переключением сцен лучше ничего не делать. Нужно специальный менеджер писать, чтобы все состояния сохранялись и переходы были достаточно быстрыми.
>спрайты всратые
Нормальные спрайты для таких игр. Мне нравится.
>>4838
Автодополнение в коде позволяет быстро набирать код, не набирая большую часть символов в словах.
Ясно, я неправильно понял.
Вот смотри, допустим, у тебя частота кадров 60. На твоей карте одна дверь, значит, ты 60 раз в секунду проверяешь условие:
Если ты добавишь вторую дверь, эта проверка будет гоняться уже 120 раз в секунду. 10 дверей - 600 раз в секунду. Если теперь твою игру с десятью дверьми запустить на компьютере с монитором 120 Гц, тогда у тебя будет уже 1200 проверок в секунду.
А самое главное, тебе 99.99999% этих операций не нужны, т.к. игрок переходит от двери к двери редко. Так что ты просто впустую гоняешь процессор.
Yandere Simulator знаешь? Там одно время были дичайщие тормоза от того, что каждый студент 60 раз в секунду "смотрел на часы", чтобы узнать, не пора ли ему отправиться на урок - здесь суть та же.
Я тоже с него начинал, там всё так же работает.
Почему теряет-то? Ты буквально пишешь:
Зачем тебе писать Vzone==true, если ты можешь ПРОСТО написать Vzone и смысл будет тот же?
Ну так бы сразу и сказал, что jRPG, там простым переключением сцен лучше ничего не делать. Нужно специальный менеджер писать, чтобы все состояния сохранялись и переходы были достаточно быстрыми.
Нормальные спрайты для таких игр. Мне нравится.
>самому ставить _ постоянно меня угнетает
Автодополнение в коде позволяет быстро набирать код, не набирая большую часть символов в словах.
>Взоне буквально значит в зоне (рядом с дверью)
Ясно, я неправильно понял.
>чем будет лучше в моем случае
Вот смотри, допустим, у тебя частота кадров 60. На твоей карте одна дверь, значит, ты 60 раз в секунду проверяешь условие:
>if Input.is_action_pressed()...
Если ты добавишь вторую дверь, эта проверка будет гоняться уже 120 раз в секунду. 10 дверей - 600 раз в секунду. Если теперь твою игру с десятью дверьми запустить на компьютере с монитором 120 Гц, тогда у тебя будет уже 1200 проверок в секунду.
А самое главное, тебе 99.99999% этих операций не нужны, т.к. игрок переходит от двери к двери редко. Так что ты просто впустую гоняешь процессор.
Yandere Simulator знаешь? Там одно время были дичайщие тормоза от того, что каждый студент 60 раз в секунду "смотрел на часы", чтобы узнать, не пора ли ему отправиться на урок - здесь суть та же.
>единственный язык который я немного знаю это школьный паскаль, поэтому так пишу
Я тоже с него начинал, там всё так же работает.
>а как упрощать я вообще не понял, так для меня код логику сразу теряет
Почему теряет-то? Ты буквально пишешь:
>ЕСЛИ нажата клавиша Enter И игрок находится в зоне действия двери ТОГДА: загрузить комнату
Зачем тебе писать Vzone==true, если ты можешь ПРОСТО написать Vzone и смысл будет тот же?
>2д вид сверху с открытым миром
>это вход в здание
Ну так бы сразу и сказал, что jRPG, там простым переключением сцен лучше ничего не делать. Нужно специальный менеджер писать, чтобы все состояния сохранялись и переходы были достаточно быстрыми.
>спрайты всратые
Нормальные спрайты для таких игр. Мне нравится.
>>4850
Вообще, тормоза были из-за того, как он использовал ассет на поиск пути, а эти проверки расписания почти не влияли на производительность
>Там одно время были дичайщие тормоза от того, что каждый студент 60 раз в секунду "смотрел на часы", чтобы узнать, не пора ли ему отправиться на урок - здесь суть та же.
Вообще, тормоза были из-за того, как он использовал ассет на поиск пути, а эти проверки расписания почти не влияли на производительность
>>4850
Я переделал дверь под это, хотя я все ещё не понимаю логику этой функции, типо не игра проверяет нажатие кнопки каждую дельту, а кнопка запускает функцию сама?
>unhanded
Я переделал дверь под это, хотя я все ещё не понимаю логику этой функции, типо не игра проверяет нажатие кнопки каждую дельту, а кнопка запускает функцию сама?
>>4870
Почитай документацию что ли:
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 игре за секунду, лол. Вроде, не так давно в треде обсуждали, не помню, к чему пришли... Для дверей лучше какой-то другой подход, например, чтобы персонаж посылал двери запрос на взаимодействие, тогда у тебя обработка ввода будет только в одном месте - в персонаже, независимо от числа дверей. Двери вообще не будут проверять нажатие клавиш, а в персонаже ты в любом случае должен проверять ввод - тогда лишних операций проверки не будет. Короче, я с самого начала не туда глядел, извини, если запутал.
>все ещё не понимаю логику этой функции
Почитай документацию что ли:
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 игре за секунду, лол. Вроде, не так давно в треде обсуждали, не помню, к чему пришли... Для дверей лучше какой-то другой подход, например, чтобы персонаж посылал двери запрос на взаимодействие, тогда у тебя обработка ввода будет только в одном месте - в персонаже, независимо от числа дверей. Двери вообще не будут проверять нажатие клавиш, а в персонаже ты в любом случае должен проверять ввод - тогда лишних операций проверки не будет. Короче, я с самого начала не туда глядел, извини, если запутал.
>>4880
Собсна, нужно было с самого начала задаться таким вопросом: почему дверь слушает ввод пользователя? Игровая дверь - пассивный объект игрового мира, она не управляется игроком напрямую. Игрок управляет персонажем, а уже персонаж активирует кнопки, рычаги, двери, раздвижные мосты и прочее. Ведь когда вы делаете в игре врага, вы не ставите ему обработчик кликов мыши, вы ставите ему обработчик попадания удара или пули, которые могли возникнуть со стороны персонажа игрока по нажатию кнопки мыши, а могли и по другой причине (ловушка, напарник игрока, общий враг и т.п.).
Т.е. дверь просто ждёт запрос от игрового персонажа, а игровой персонаж ждёт нажатий клавиш игроком.
>Двери вообще не будут проверять нажатие клавиш
Собсна, нужно было с самого начала задаться таким вопросом: почему дверь слушает ввод пользователя? Игровая дверь - пассивный объект игрового мира, она не управляется игроком напрямую. Игрок управляет персонажем, а уже персонаж активирует кнопки, рычаги, двери, раздвижные мосты и прочее. Ведь когда вы делаете в игре врага, вы не ставите ему обработчик кликов мыши, вы ставите ему обработчик попадания удара или пули, которые могли возникнуть со стороны персонажа игрока по нажатию кнопки мыши, а могли и по другой причине (ловушка, напарник игрока, общий враг и т.п.).
Т.е. дверь просто ждёт запрос от игрового персонажа, а игровой персонаж ждёт нажатий клавиш игроком.
>>4838
Я бы вообще немного архитектурно переделал.
Вот у тебя иконка двери же появляется когда подходишь.
Значит ты вообще можешь избавиться от Vzone
Алсо, есть такая функция, как set_process(bool)
То есть ты можешь включать process когда срабатывает твой on enter и выключать в on exit. Так скрипт вообще не будет молотить когда ты не зашел в триггер.
Я бы вообще немного архитектурно переделал.
Вот у тебя иконка двери же появляется когда подходишь.
Значит ты вообще можешь избавиться от Vzone
Алсо, есть такая функция, как set_process(bool)
То есть ты можешь включать process когда срабатывает твой on enter и выключать в on exit. Так скрипт вообще не будет молотить когда ты не зашел в триггер.
22,4 Мб, mp4,852x480, 1:17
Делою хиии.
389 Кб, 1366x768Wtf man! Что он требует от меня?! Что там в ошибках? Что нормализовать надо?
>создал контейнер с полем для текста
>при нажатии кнопки должна проигриваться анимация на объекте и в поле для текста должен виводиться текст
>РРРРЯЯЯЯЯЯЯЯЯЯЯЯ НУУУЛЛЛЛЬ ИНСТАААААНССС НЕ НАЙДЕНААА ТАКОВАААААА
>>4882
>>4880
Я переделал логику, теперь в игроке идёт проверка нажатия ентера, если да то посылается сигнал. А дверь при получении смотрит, если игрок в зоне, то переключает лвл. Минус в том, что на каждом уровне надо вручную подключать каждую такую дверь к игроку, но это мелочи. Я нашел event bus, но так и не смог настроить у себя, и забил хуй, буду руками подключать.
>>4880
Я переделал логику, теперь в игроке идёт проверка нажатия ентера, если да то посылается сигнал. А дверь при получении смотрит, если игрок в зоне, то переключает лвл. Минус в том, что на каждом уровне надо вручную подключать каждую такую дверь к игроку, но это мелочи. Я нашел event bus, но так и не смог настроить у себя, и забил хуй, буду руками подключать.
>>4975
Вроде все очевидно, не? Ты вызываешь Head/BoxContainer относительно текущей ноды, но скрипт пишешь не в Player а на две ноды глубже. Тогда тебе надо что то вроде $"../../Head/Boxитд"
Вроде все очевидно, не? Ты вызываешь Head/BoxContainer относительно текущей ноды, но скрипт пишешь не в Player а на две ноды глубже. Тогда тебе надо что то вроде $"../../Head/Boxитд"
>>4978
Это можно сделать несколькими простыми способами.
Например при загрузке уровня игрок сам в цикле проверяет все объекты (по имени или группе) и добавляет двери. Или, наоборот, каждая дверь сама себя регистрирует. Можно вообще самому сделать без всяких eventbus. В скрипте уровня завести массив дверей, каждая дверь онреди себя туда записывает, при спавне игрока он подписываеи каждую дверь из массива на события
Это можно сделать несколькими простыми способами.
Например при загрузке уровня игрок сам в цикле проверяет все объекты (по имени или группе) и добавляет двери. Или, наоборот, каждая дверь сама себя регистрирует. Можно вообще самому сделать без всяких eventbus. В скрипте уровня завести массив дверей, каждая дверь онреди себя туда записывает, при спавне игрока он подписываеи каждую дверь из массива на события
>>4993
Ладно, это уже для больших игр и студий, мне кажется проще 5 минут потратить на ручную настройку условных 100 дверей в игре, чем писать код как минимум несколько часов по крайней мере с моим уровнем
Ладно, это уже для больших игр и студий, мне кажется проще 5 минут потратить на ручную настройку условных 100 дверей в игре, чем писать код как минимум несколько часов по крайней мере с моим уровнем
>>5002
Да не, это для любительского соло геймдева простой вариант, сложные для студии я не стал расписывать
Да не, это для любительского соло геймдева простой вариант, сложные для студии я не стал расписывать
>>4805
Не думаю что тут полно спецов по вулкану
В самой свежей бете 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.
Не думаю что тут полно спецов по вулкану
В самой свежей бете 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.
>>4978
Не нужно подключать заранее ничего.
В 3D можно сделать так:
1. Из игрока торчит RayCast3D в направлении взгляда.
2. Когда игрок нажимает кнопку "использовать":
- проверяем, с чем пересекается наш луч взгляда:
- проверяем наличие метода и вызываем его:
3. Далее любой интерактивный объект должен реализовать свой метод interact(target), который реагирует на нажатие кнопки "использовать".
В 2D на квадратной сетке можно сделать проще, без бросания лучей и без Area, просто проверяя, на какой клетке стоит фигурка игрока и куда она смотрит. Но ради быстрого прототипа можно и RayCast2D...
>подключать каждую такую дверь к игроку
Не нужно подключать заранее ничего.
В 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...
>>5094
Так я ж бог этой игри. Что я, на себя молиться буду?!
Так я ж бог этой игри. Что я, на себя молиться буду?!
Какой плагин для диалогов как в визуальной новелле лучше? Пока остановился на dialogic от coppolaemilio, но в ассетах видел много других вариантов
>>5145
Ну ты ну! По ссылкам переходи всё таки
Ну ты ну! По ссылкам переходи всё таки
> 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.
>>5146
Я нашел это, но в чем лучше то? Отсутствие визуального программирования преподносится как плюс?
Я нашел это, но в чем лучше то? Отсутствие визуального программирования преподносится как плюс?
>>5148
Как я понял диаложик в принципе для диалогов, тогда как ракуго специализируется именно на ВН, именно на подобии РенПу
Как я понял диаложик в принципе для диалогов, тогда как ракуго специализируется именно на ВН, именно на подобии РенПу
359 Кб, 994x1400>>4769
Призываю в тред раст-куна, которого видел на неделе в каком-то из тредов. Раст-кун, приди. Научи как сделать свою сбоpку с волшебной интерполированной дельтой и скриптингом на расте.
> Призываю в тред раст-куна, которого видел на неделе в каком-то из тредов. Раст-кун, приди. Научи как сделать свою сбоpку с волшебной интерполированной дельтой и скриптингом на расте.
Призываю в тред раст-куна, которого видел на неделе в каком-то из тредов. Раст-кун, приди. Научи как сделать свою сбоpку с волшебной интерполированной дельтой и скриптингом на расте.
>>5146
Я установил в твой собственный скриптовый язык еще один собственный скриптовый язык, чтобы ты мог скриптить пока скриптишь
>with our own scripting langue
Я установил в твой собственный скриптовый язык еще один собственный скриптовый язык, чтобы ты мог скриптить пока скриптишь
>>5139
Позагружай все. В отдельные тестовые проекты, разумеется. Погоняй-посмотри. Выбери наиболее подходящий тебе.
Помни!
Лучших нет. Есть только подходящие.
> Какой плагин для диалогов как в визуальной новелле лучше?
> Пока остановился на
> но в ассетах видел много других
Позагружай все. В отдельные тестовые проекты, разумеется. Погоняй-посмотри. Выбери наиболее подходящий тебе.
Помни!
Лучших нет. Есть только подходящие.
>>4769 >>5176
Отзываю из треда раст-куна, не хватало нам ещё ржавчины в движке, и без неё всё еле работает.
Зачем? https://godot-rust.github.io/
Отзываю из треда раст-куна, не хватало нам ещё ржавчины в движке, и без неё всё еле работает.
>сбоpку
Зачем? https://godot-rust.github.io/
>>5188
Получается лучшая игра - та, которую ты написал? Все ГОТИ мои?
>Тот который ты пишешь сам - лучший
Получается лучшая игра - та, которую ты написал? Все ГОТИ мои?
>>5191
Да. Шайн он ю крейзи даймонд
Да. Шайн он ю крейзи даймонд
>>5188
Визуальные новеллы делают всякие писаки-забияки и яжхудожники, они не хотят разбираться в кодинге и изобретать велосипед с нуля, они хотят ЕХАТЬ.
Поэтому они берут готовое и пишут скрипты вроде:
Вот и вся "разработка игры".
>>5179
https://ru.wikipedia.org/wiki/Предметно-ориентированный_язык
GDScript - язык общего назначения.
%твой язык в игре% - язык для конкретной игры, учитывающий особенности разработки этой игры.
Алсо,
Так что в Godot кроме GDScript есть ещё безымянный декларативный язык сцен и ресурсов (tscn/tres) и наверняка что-то ещё, тоже специализированное.
>Тот который ты пишешь сам
Визуальные новеллы делают всякие писаки-забияки и яжхудожники, они не хотят разбираться в кодинге и изобретать велосипед с нуля, они хотят ЕХАТЬ.
Поэтому они берут готовое и пишут скрипты вроде:
>{Вася} Машка, го трахаться!
>{Маша} Ах, Василий, вы такой дерзкий!
>{sex_scene_69.png}
Вот и вся "разработка игры".
>>5179
>еще один собственный скриптовый язык
https://ru.wikipedia.org/wiki/Предметно-ориентированный_язык
>Предметно-ориентированный язык (англ. domain-specific language, DSL — «язык, специфический для предметной области») — компьютерный язык, специализированный для конкретной области применения (в противоположность языку общего назначения, применимому к широкому спектру областей и не учитывающему особенности конкретных сфер знаний). Построение такого языка и/или его структура данных отражают специфику решаемых с его помощью задач.
GDScript - язык общего назначения.
%твой язык в игре% - язык для конкретной игры, учитывающий особенности разработки этой игры.
Алсо,
>Строго говоря, деление языков программирования на языки общего назначения и предметно-ориентированные весьма условно, особенно, если учесть, что формально любой протокол или формат файлов является языком.
Так что в Godot кроме GDScript есть ещё безымянный декларативный язык сцен и ресурсов (tscn/tres) и наверняка что-то ещё, тоже специализированное.
Короче я поебался с некоторыми плагинами диалогов, смог их запустить, но нормально интегрировать это все в мою игру не смог, где то я откровенно нихуя не понимал, а где то ничего не работало, так как код/документация были под годот 3 и я опять же нихуя не понимал и ловил ошибки. Поэтому буду делать собственную примитивную систему диалогов, благо нашел вроде рабочий гайд на ютубе
>>5198
Падажжи. Как так? В том же диалоджике вместе с ассетом поставляется сцена-пример. Ты не можешь её штоле открыть и тупо скопировать со своим текстом и артом?
Падажжи. Как так? В том же диалоджике вместе с ассетом поставляется сцена-пример. Ты не можешь её штоле открыть и тупо скопировать со своим текстом и артом?
>>5214
Обычно сложно интегрировать чужие решения в свою игру. Например инвентарь. Хоть и есть прикольные проекты, но мне было проще сделать самому, чем пытаться впендюрить в свой код
мимо
Обычно сложно интегрировать чужие решения в свою игру. Например инвентарь. Хоть и есть прикольные проекты, но мне было проще сделать самому, чем пытаться впендюрить в свой код
мимо
53 Кб, 762x775>>5198
Ну вот тебе совет от бывалого участника ТВГ, занимавшего 10е-12е места, лол.
Юзай JSON для описания диалогов, его экстремально легко парсить, то есть, если он у тебя корректно написан, то при загрузке ты получаешь готовый словарь в котором просто обращаешься к ветвям по мере проигрывания диалога.
Фишка в том, что при написании парсера заложи, что каждое возвращаемое значение может быть либо словарём (типизированным, с полем "type" и строковым значением типа), либо массивом типизированных словарей, либо переменной системного типа. Благодаря этому, как показано на скрине, ты можешь писать небольшие фрагменты диалогов и ссылаться на них, а так же ты можешь в диалоге описать типизированные объекты и опять же ссылаться на них, но тебе ничего не помешает внутри одного файла описать несколько ветвей диалога, а поскольку корневой элемент имеет имя, то между ветвями можно ссылаться на другие ветви по имени корневого элемента в поле "next".
В строке 26 я написал образно просто строку с якобы обращением к игровому синглтону, но если ты решишь реализовывать этот вариант, то там будет немного иначе, есть пара подводных камней, но в целом ты и такую строку сможешь распарсить, движок в этом тебя не ограничит.
> буду делать собственную примитивную систему диалогов
Ну вот тебе совет от бывалого участника ТВГ, занимавшего 10е-12е места, лол.
Юзай JSON для описания диалогов, его экстремально легко парсить, то есть, если он у тебя корректно написан, то при загрузке ты получаешь готовый словарь в котором просто обращаешься к ветвям по мере проигрывания диалога.
Фишка в том, что при написании парсера заложи, что каждое возвращаемое значение может быть либо словарём (типизированным, с полем "type" и строковым значением типа), либо массивом типизированных словарей, либо переменной системного типа. Благодаря этому, как показано на скрине, ты можешь писать небольшие фрагменты диалогов и ссылаться на них, а так же ты можешь в диалоге описать типизированные объекты и опять же ссылаться на них, но тебе ничего не помешает внутри одного файла описать несколько ветвей диалога, а поскольку корневой элемент имеет имя, то между ветвями можно ссылаться на другие ветви по имени корневого элемента в поле "next".
В строке 26 я написал образно просто строку с якобы обращением к игровому синглтону, но если ты решишь реализовывать этот вариант, то там будет немного иначе, есть пара подводных камней, но в целом ты и такую строку сможешь распарсить, движок в этом тебя не ограничит.
>>5221
Теперь подробно распишу алгоритм парсинга скрина.
Сначала парсер ожидает словарь типа "диалог-файл", если получено иное, выдаёт ошибку. У этого типа словаря парсер ожидает найти поля "персонажи" и "беседы" каждый из которых может быть как встроенным словарём, так и строкой-ссылкой на общий файл в базе данных.
Далее парсер загружает словарь с персонажами, и держит их в переменной, чтобы ссылаться на них.
Далее парсер загружает словарь с беседами, если у него нет данных о том, с какого корневого узла начать/продолжить, он открывает первую по индексу (помним, что словарь всё равно массив) и ожидает типизированный словарь "строчка", у которого ожидает наличие поля "условия".
Далее парсер парсит условия по списку, если найдены условия "на_старте", то выполняет их, и если они тру, выводит текст на экран, выводит имя на экран, находя его по ссылке, иконку, так же.
Далее парсер рекурсивно загружает типизированный словарь из поля "следующий". Если в поле строковый путь к файлу - предварительно загружает файл.
И так пока весь диалог не покажет.
Система охуенно масштабируема. Можно тупо в одном файле всё описать, а можно навернуть сложнейшее эрпоге с базой данных персонажей, стат/скилл-чеками, дайс-роллами, и прочими блек-джеками.
Систему условий ты тоже реализуешь сам. Можно реализовать енум из трёх констант: на_старте, в_середине, в_конце. На старте мы решаем показать ли строку или скипнуть. Если строка это корень, и условие провалено, то скипается весь диалог вообще. Если условие в конце, то скипаем некст. Если условие в середине, то нужно например в тексте поставить метку, в какой момент вывода текста нужно чекнуть условие. И соответственно, ЮИ при выводе текста должен уметь скрывать метку с глаз и посылать сигнал парсеру, а парсеру на этот сигнал быть подписанным.
Поле некст (следующий) может быть списком ответов, и тогда там нужно описать отдельный тип словаря, у которого кроме поля "текст" есть поле "заголовок" (caption). которое будет выведено на кнопке у игрока в ЮИ. При проектировании более сложных диалоговых систем уровня РПГ, ответами смогут быть все строчки, просто если их "выбирает" непись, игрок не видит заголовка.
Теперь подробно распишу алгоритм парсинга скрина.
Сначала парсер ожидает словарь типа "диалог-файл", если получено иное, выдаёт ошибку. У этого типа словаря парсер ожидает найти поля "персонажи" и "беседы" каждый из которых может быть как встроенным словарём, так и строкой-ссылкой на общий файл в базе данных.
Далее парсер загружает словарь с персонажами, и держит их в переменной, чтобы ссылаться на них.
Далее парсер загружает словарь с беседами, если у него нет данных о том, с какого корневого узла начать/продолжить, он открывает первую по индексу (помним, что словарь всё равно массив) и ожидает типизированный словарь "строчка", у которого ожидает наличие поля "условия".
Далее парсер парсит условия по списку, если найдены условия "на_старте", то выполняет их, и если они тру, выводит текст на экран, выводит имя на экран, находя его по ссылке, иконку, так же.
Далее парсер рекурсивно загружает типизированный словарь из поля "следующий". Если в поле строковый путь к файлу - предварительно загружает файл.
И так пока весь диалог не покажет.
Система охуенно масштабируема. Можно тупо в одном файле всё описать, а можно навернуть сложнейшее эрпоге с базой данных персонажей, стат/скилл-чеками, дайс-роллами, и прочими блек-джеками.
Систему условий ты тоже реализуешь сам. Можно реализовать енум из трёх констант: на_старте, в_середине, в_конце. На старте мы решаем показать ли строку или скипнуть. Если строка это корень, и условие провалено, то скипается весь диалог вообще. Если условие в конце, то скипаем некст. Если условие в середине, то нужно например в тексте поставить метку, в какой момент вывода текста нужно чекнуть условие. И соответственно, ЮИ при выводе текста должен уметь скрывать метку с глаз и посылать сигнал парсеру, а парсеру на этот сигнал быть подписанным.
Поле некст (следующий) может быть списком ответов, и тогда там нужно описать отдельный тип словаря, у которого кроме поля "текст" есть поле "заголовок" (caption). которое будет выведено на кнопке у игрока в ЮИ. При проектировании более сложных диалоговых систем уровня РПГ, ответами смогут быть все строчки, просто если их "выбирает" непись, игрок не видит заголовка.
>>5221
Теперь подробно распишу алгоритм парсинга скрина.
Сначала парсер ожидает словарь типа "диалог-файл", если получено иное, выдаёт ошибку. У этого типа словаря парсер ожидает найти поля "персонажи" и "беседы" каждый из которых может быть как встроенным словарём, так и строкой-ссылкой на общий файл в базе данных.
Далее парсер загружает словарь с персонажами, и держит их в переменной, чтобы ссылаться на них.
Далее парсер загружает словарь с беседами, если у него нет данных о том, с какого корневого узла начать/продолжить, он открывает первую по индексу (помним, что словарь всё равно массив) и ожидает типизированный словарь "строчка", у которого ожидает наличие поля "условия".
Далее парсер парсит условия по списку, если найдены условия "на_старте", то выполняет их, и если они тру, выводит текст на экран, выводит имя на экран, находя его по ссылке, иконку, так же.
Далее парсер рекурсивно загружает типизированный словарь из поля "следующий". Если в поле строковый путь к файлу - предварительно загружает файл.
И так пока весь диалог не покажет.
Система охуенно масштабируема. Можно тупо в одном файле всё описать, а можно навернуть сложнейшее эрпоге с базой данных персонажей, стат/скилл-чеками, дайс-роллами, и прочими блек-джеками.
Систему условий ты тоже реализуешь сам. Можно реализовать енум из трёх констант: на_старте, в_середине, в_конце. На старте мы решаем показать ли строку или скипнуть. Если строка это корень, и условие провалено, то скипается весь диалог вообще. Если условие в конце, то скипаем некст. Если условие в середине, то нужно например в тексте поставить метку, в какой момент вывода текста нужно чекнуть условие. И соответственно, ЮИ при выводе текста должен уметь скрывать метку с глаз и посылать сигнал парсеру, а парсеру на этот сигнал быть подписанным.
Поле некст (следующий) может быть списком ответов, и тогда там нужно описать отдельный тип словаря, у которого кроме поля "текст" есть поле "заголовок" (caption). которое будет выведено на кнопке у игрока в ЮИ. При проектировании более сложных диалоговых систем уровня РПГ, ответами смогут быть все строчки, просто если их "выбирает" непись, игрок не видит заголовка.
Теперь подробно распишу алгоритм парсинга скрина.
Сначала парсер ожидает словарь типа "диалог-файл", если получено иное, выдаёт ошибку. У этого типа словаря парсер ожидает найти поля "персонажи" и "беседы" каждый из которых может быть как встроенным словарём, так и строкой-ссылкой на общий файл в базе данных.
Далее парсер загружает словарь с персонажами, и держит их в переменной, чтобы ссылаться на них.
Далее парсер загружает словарь с беседами, если у него нет данных о том, с какого корневого узла начать/продолжить, он открывает первую по индексу (помним, что словарь всё равно массив) и ожидает типизированный словарь "строчка", у которого ожидает наличие поля "условия".
Далее парсер парсит условия по списку, если найдены условия "на_старте", то выполняет их, и если они тру, выводит текст на экран, выводит имя на экран, находя его по ссылке, иконку, так же.
Далее парсер рекурсивно загружает типизированный словарь из поля "следующий". Если в поле строковый путь к файлу - предварительно загружает файл.
И так пока весь диалог не покажет.
Система охуенно масштабируема. Можно тупо в одном файле всё описать, а можно навернуть сложнейшее эрпоге с базой данных персонажей, стат/скилл-чеками, дайс-роллами, и прочими блек-джеками.
Систему условий ты тоже реализуешь сам. Можно реализовать енум из трёх констант: на_старте, в_середине, в_конце. На старте мы решаем показать ли строку или скипнуть. Если строка это корень, и условие провалено, то скипается весь диалог вообще. Если условие в конце, то скипаем некст. Если условие в середине, то нужно например в тексте поставить метку, в какой момент вывода текста нужно чекнуть условие. И соответственно, ЮИ при выводе текста должен уметь скрывать метку с глаз и посылать сигнал парсеру, а парсеру на этот сигнал быть подписанным.
Поле некст (следующий) может быть списком ответов, и тогда там нужно описать отдельный тип словаря, у которого кроме поля "текст" есть поле "заголовок" (caption). которое будет выведено на кнопке у игрока в ЮИ. При проектировании более сложных диалоговых систем уровня РПГ, ответами смогут быть все строчки, просто если их "выбирает" непись, игрок не видит заголовка.
34 Кб, 751x526>>5225
На самом деле, я тут перечитал написанное и понял, что неправильно обрисовал тебе часть с условиями. Вообще говоря, следует в диалогах держать поле "скрипты" в котором будет список из типов скрипта: условие, действие. Условия возвращают булево значение. Действия просто делают, например, устанавливают переменные.
На самом деле, я тут перечитал написанное и понял, что неправильно обрисовал тебе часть с условиями. Вообще говоря, следует в диалогах держать поле "скрипты" в котором будет список из типов скрипта: условие, действие. Условия возвращают булево значение. Действия просто делают, например, устанавливают переменные.
>>5228
Спасибо за такой развернутый ответ, но я все равно ничего пока не понимаю годот скачал неделю назад. Надо будет выделить вечер и сесть разбираться со всем этим.
Спасибо за такой развернутый ответ, но я все равно ничего пока не понимаю годот скачал неделю назад. Надо будет выделить вечер и сесть разбираться со всем этим.
34 Кб, 955x506>>5229
А меня уже понесло 😁 продолжил продумывать дизайн пикрелейтед.
Ну ладно. Как освоишься, и если не сбежишь, приходи - возобновим беседу.
> но я
А меня уже понесло 😁 продолжил продумывать дизайн пикрелейтед.
Ну ладно. Как освоишься, и если не сбежишь, приходи - возобновим беседу.
>>5213
Это вариант INI-файлов, называют ConfigFile:
https://docs.godotengine.org/en/stable/classes/class_configfile.html
Это вариант 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.
>>5221
Что?.. Как ты занимал такое место?
Ох уж эти ТВГ...
Лучше https://hjson.github.io/ - его намного легче писать вручную, чем корректный JSON.
Проблема подхода "всё в JSON" в том, что ты должен описывать буквально структуру в памяти, что не обязательно наиболее удобная запись для человека, а костыли не обязательно удобны для программы.
>10е-12е места
Что?.. Как ты занимал такое место?
>10e-12 in decimal form
>0.000000000010
Ох уж эти ТВГ...
>Юзай JSON для описания диалогов
Лучше https://hjson.github.io/ - его намного легче писать вручную, чем корректный JSON.
Проблема подхода "всё в JSON" в том, что ты должен описывать буквально структуру в памяти, что не обязательно наиболее удобная запись для человека, а костыли не обязательно удобны для программы.
Эх, вот бы игры поделать...
>>5252
Смишно пошутил, петросян.
Да это всё понятно. Суть в том, что корректный жсон поддерживается гдскриптом искаропки, а для некорректного придётся парсер писать. А мог бы игры делать.
> 10e-12 in decimal form
Смишно пошутил, петросян.
> его намного легче писать вручную, чем корректный JSON
Да это всё понятно. Суть в том, что корректный жсон поддерживается гдскриптом искаропки, а для некорректного придётся парсер писать. А мог бы игры делать.
>>5387
Хз как можно писать не на json. Есть миллиарды инструментов, которые позволяют очень удобно на нем писать. Зато костыли никакие не нужны и это де факто стандарт
Хз как можно писать не на json. Есть миллиарды инструментов, которые позволяют очень удобно на нем писать. Зато костыли никакие не нужны и это де факто стандарт
>>1894 (OP)
Годотеры, у меня вот у персонажей есть различные скилы, котоыре сделаны отдельными нодами, прикрепляемыми к персонажам. Что будет лучше для производительности: прикреплять все ноды скиллов при создании сцены или при использовании скилла прикреплять только необходимую?
Годотеры, у меня вот у персонажей есть различные скилы, котоыре сделаны отдельными нодами, прикрепляемыми к персонажам. Что будет лучше для производительности: прикреплять все ноды скиллов при создании сцены или при использовании скилла прикреплять только необходимую?
>>5436
Наследоваться от RefCounted.
Прикреплять скиллы в локальный массив персонажа.
> Что будет лучше для производительности
Наследоваться от RefCounted.
> class_name Skill extends RefCounted
Прикреплять скиллы в локальный массив персонажа.
> var skills : Array[Skill]
> skills.append(Skill.new())
>>5444
Я предъявляю претензию к твоей архитектуре. Скилл это ресурс. Он может добавлять сцену при необходимости, но ему незачем держать в себе сцену. Подумай над архитектурой ещё.
> каждый скилл целая сцена
Я предъявляю претензию к твоей архитектуре. Скилл это ресурс. Он может добавлять сцену при необходимости, но ему незачем держать в себе сцену. Подумай над архитектурой ещё.
>>5445
Ну, через редактор я их все равно добавлять не буду, так что не надо.
>>5448
Тогда зачем ресурс? Если он все равно будет добавлять сцену, как у меня во втором варианте, то я просто смогу узнать скилл, который нужен, по его id?
>>5446
Хочется, чтоб даже на древней картошке игра шла все таки.
>Если тебе надо удобную поддержку в редакторе
Ну, через редактор я их все равно добавлять не буду, так что не надо.
>>5448
Тогда зачем ресурс? Если он все равно будет добавлять сцену, как у меня во втором варианте, то я просто смогу узнать скилл, который нужен, по его id?
>>5446
Хочется, чтоб даже на древней картошке игра шла все таки.
>>5452
Это экономия на спичках, для пошага. Ты проверял на древней картошке? Какие цифры получил?
Это экономия на спичках, для пошага. Ты проверял на древней картошке? Какие цифры получил?
>>5452
Просто покажи мне это. покажи скринами код и иерархию сцены. Я просто не могу себе представить ЗАЧЕМ???
> скилл это сцена
Просто покажи мне это. покажи скринами код и иерархию сцены. Я просто не могу себе представить ЗАЧЕМ???
>>5455
В основной сцене, локации/мира и т.п. должен быть скрипт, который принимает сигналы/запросы на добавление спецэффектов в требуемых координатах. Скиллы должны уметь посылать такой запрос. И всё.
Продолжаю не понимать.
В основной сцене, локации/мира и т.п. должен быть скрипт, который принимает сигналы/запросы на добавление спецэффектов в требуемых координатах. Скиллы должны уметь посылать такой запрос. И всё.
Продолжаю не понимать.
>>5436
У меня примерно похожая система, только не пошаг, а платформер. Персонаж театрстейт-машина, а ноды в нём - актёрыстейты. Опрашивается это всё в физикс_процессе. Работает нормально на слабом железе, в том числе и на морально устаревшем андроидофоне.
И да, очень удобно в такие скиллы-сцены добавлять всякие штуки типа партиклей, рейкастов и вообще всего такого, что им может понадобиться. Мне кажется, это очень годошный подход. Да, нода в памяти занимает чуть больше места, чем ресурс; но зато у неё есть колбэки, которые можно быстро задействовать (а если не задействовать, то их как будто и нет) и все плюшки нод вообще.
У меня примерно похожая система, только не пошаг, а платформер. Персонаж театрстейт-машина, а ноды в нём - актёрыстейты. Опрашивается это всё в физикс_процессе. Работает нормально на слабом железе, в том числе и на морально устаревшем андроидофоне.
И да, очень удобно в такие скиллы-сцены добавлять всякие штуки типа партиклей, рейкастов и вообще всего такого, что им может понадобиться. Мне кажется, это очень годошный подход. Да, нода в памяти занимает чуть больше места, чем ресурс; но зато у неё есть колбэки, которые можно быстро задействовать (а если не задействовать, то их как будто и нет) и все плюшки нод вообще.
>>5465
>>5462
Ладно, делайте как хотите. Но вы мешаете данные и логику. Вы не видите разницы между скиллами как данными и скиллами как эффектами, которые они порождают при их применении. Я напоследок предупреждаю, что такой "удобный" подход вероятно приведет вас к производственному аду. Засим умолкаю.
>>5462
Ладно, делайте как хотите. Но вы мешаете данные и логику. Вы не видите разницы между скиллами как данными и скиллами как эффектами, которые они порождают при их применении. Я напоследок предупреждаю, что такой "удобный" подход вероятно приведет вас к производственному аду. Засим умолкаю.
>>5465
Мне самому показалось это очень удобным и, пока что, на практике тоже, но вот я не знаю будут ли проблемы с количеством этих самых нод.
>>5466
Данные о скиллах, вроде расхода маны, цены и т.д лежат в словаре, а логика в скрипте ноды. Где тут смешивание? Или что ты под этим имеешь ввиду?
Мне самому показалось это очень удобным и, пока что, на практике тоже, но вот я не знаю будут ли проблемы с количеством этих самых нод.
>>5466
>данные и логику
Данные о скиллах, вроде расхода маны, цены и т.д лежат в словаре, а логика в скрипте ноды. Где тут смешивание? Или что ты под этим имеешь ввиду?
>>5462
До тех пор, пока у тебя не пара тысяч персонажей, в каждом по два десятка нод-скиллов, движок прекрасно вывезет из обработку в реалтайме. В пошаге - умножай на 10.
ФПС, как я заметил, просаживается от большого числа графических объектов. И сложная физика тоже может съедать фепесы. А, и, конечно, вот такие советы:
>>5458
Нода, висящая в дереве, сама по себе почти не потребляет вычислительные ресурсы. Партикля, которая время от времени включается, гораздо производительнее, чем партикля, которая добавляется в дерево, отрабатывает и удаляется. И вообще, это чревато утечками памяти.
>>5466
1. Производственный ад в соло-разработке? Ну да.
2. Я без проблем могу описывать персонажа в жсоне, а потом собирать его из нод, парся жсон. Например. Используя ресурсы вместо нод, я не выигрываю ничего, но теряю в гибкости.
3. А файл tscn это данные или логика, по-твоему? А скрипт, всё содержимое которого это просто один большой словарь, это данные или логика?
Ну то есть, сам поинт понятен, разделять действительно следует. Но это не тот случай, как по мне. Движок даёт удобные средства, и я не вижу причин ими не пользоваться.
До тех пор, пока у тебя не пара тысяч персонажей, в каждом по два десятка нод-скиллов, движок прекрасно вывезет из обработку в реалтайме. В пошаге - умножай на 10.
ФПС, как я заметил, просаживается от большого числа графических объектов. И сложная физика тоже может съедать фепесы. А, и, конечно, вот такие советы:
>>5458
>сигналы/запросы на добавление спецэффектов в требуемых координатах
Нода, висящая в дереве, сама по себе почти не потребляет вычислительные ресурсы. Партикля, которая время от времени включается, гораздо производительнее, чем партикля, которая добавляется в дерево, отрабатывает и удаляется. И вообще, это чревато утечками памяти.
>>5466
1. Производственный ад в соло-разработке? Ну да.
2. Я без проблем могу описывать персонажа в жсоне, а потом собирать его из нод, парся жсон. Например. Используя ресурсы вместо нод, я не выигрываю ничего, но теряю в гибкости.
3. А файл tscn это данные или логика, по-твоему? А скрипт, всё содержимое которого это просто один большой словарь, это данные или логика?
Ну то есть, сам поинт понятен, разделять действительно следует. Но это не тот случай, как по мне. Движок даёт удобные средства, и я не вижу причин ими не пользоваться.
>>5471
Спасибо за ответ, если вывезет, то прекрасно. На уровнях, которые уже есть, максимум 40 персонажей есть.
>До тех пор, пока у тебя не пара тысяч персонажей, в каждом по два десятка нод-скиллов, движок прекрасно вывезет из обработку в реалтайме. В пошаге - умножай на 10.
Спасибо за ответ, если вывезет, то прекрасно. На уровнях, которые уже есть, максимум 40 персонажей есть.
>>5387
У тебя и будет 100% корректный JSON на выходе, без необходимости подсчитывать скобки, кавычки и запятые. А в исходниках даже комментарии будут!
Зачем писать, если всё давно написано?
https://hjson.github.io/users.html
А можно сделать себе сборочку Godot + Hjson...
>>5392
Пофиксил тебя.
Ты не понимаешь, что эти инструменты - костыли?
Я просто предлагаю лучший из всех этих костылей.
>Суть в том, что корректный жсон поддерживается гдскриптом искаропки
У тебя и будет 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...
>>5392
>{"Хз":"как","можно":"писать","не":"на","json":"."}
Пофиксил тебя.
>Есть миллиарды инструментов
>Зато костыли никакие не нужны
Ты не понимаешь, что эти инструменты - костыли?
Я просто предлагаю лучший из всех этих костылей.
>>5504
А зачем? Это как визуальный язык вместо обычного текстового - вечно суют куда попало, а на практике написать несколько строк текстом всё равно проще.
>придешь к написанию редактора диалогов
А зачем? Это как визуальный язык вместо обычного текстового - вечно суют куда попало, а на практике написать несколько строк текстом всё равно проще.
>>5466
Это суть ООП: данные + логика = объекты.
Не вижу. Если у мага навык позволяет стрелять огненными шарами, это то же самое, что оружие в шутере, только без явно видимого оружия в руках.
Если ты делаешь пистолет в шутере, ты сделаешь сцену pistol.tscn, в которой скрипт генерирует все пульки, рейкасты, вспышки света, дым и т.д.
Так и с навыками. Считай, это биомодификации.
К аду приводят преждевременные оптимизации, когда такие как ты прибивают гвоздями что-то к чему-то, а потом пистолет не пистолет и пульки из жопы вылетают, а не с кончика ствола.
Оптимизация - это всегда жертва чем-то. В данном случае в жертву приносится удобство разработки - вместо простого и понятного пистолета, который одинаково надёжно стреляет, где бы ни оказался, предлагается накрутить какую-то оптимизацию...
>Но вы мешаете данные и логику.
Это суть ООП: данные + логика = объекты.
>Вы не видите разницы между скиллами как данными и скиллами как эффектами, которые они порождают при их применении.
Не вижу. Если у мага навык позволяет стрелять огненными шарами, это то же самое, что оружие в шутере, только без явно видимого оружия в руках.
Если ты делаешь пистолет в шутере, ты сделаешь сцену pistol.tscn, в которой скрипт генерирует все пульки, рейкасты, вспышки света, дым и т.д.
Так и с навыками. Считай, это биомодификации.
>приведет вас к производственному аду
К аду приводят преждевременные оптимизации, когда такие как ты прибивают гвоздями что-то к чему-то, а потом пистолет не пистолет и пульки из жопы вылетают, а не с кончика ствола.
Оптимизация - это всегда жертва чем-то. В данном случае в жертву приносится удобство разработки - вместо простого и понятного пистолета, который одинаково надёжно стреляет, где бы ни оказался, предлагается накрутить какую-то оптимизацию...
>>5506
Потому что графы, стейтмашины, последовательности событий, квесты, диалоги как подмножество, удобнее редактировать лапшой.
Проблема в переносимости кастомных форматов лапши.
Тут мог бы помочь какой то фокус с спец текстовым форматом, изменения в котором подхватывались бы в визуальном, и редактирование визуала вносило строчки в текст.
Потому что графы, стейтмашины, последовательности событий, квесты, диалоги как подмножество, удобнее редактировать лапшой.
Проблема в переносимости кастомных форматов лапши.
Тут мог бы помочь какой то фокус с спец текстовым форматом, изменения в котором подхватывались бы в визуальном, и редактирование визуала вносило строчки в текст.
12 Кб, 267x189>>5508
Ты прибил пистолет к волшебнику и лишил себя возможности сделать скилл, когда волшебник призывает несколько пистолетов в воздухе, стреляющих по разным целям.
Ты прибил пистолет к волшебнику и лишил себя возможности сделать скилл, когда волшебник призывает несколько пистолетов в воздухе, стреляющих по разным целям.
9 Кб, 253x208Дарова, годаны, щас занят воссозданием одной игори, появилась нужда сделать drag&drop систему, суть в чём:
Есть несколько перетаскиваемых объектов которые можно кинуть в одну зону, они в зависимости от типа увеличат нужную переменную на 1 и вернутся на место.
Соприкосновение с зоной находить я научился, но не могу понять как можно отловить когда объект не держат, за основу брал код из какого-то пиндосского гайда+писал наспех, поэтому не бейте. https://pastebin.com/9iVGjPii
Есть несколько перетаскиваемых объектов которые можно кинуть в одну зону, они в зависимости от типа увеличат нужную переменную на 1 и вернутся на место.
Соприкосновение с зоной находить я научился, но не могу понять как можно отловить когда объект не держат, за основу брал код из какого-то пиндосского гайда+писал наспех, поэтому не бейте. https://pastebin.com/9iVGjPii
>>5535
Так, похоже сам нашёл проблему, selected всё ещё true когда вызывается area_entered, похоже просто нужно завести какую-то переменную для соприкосновения и перевести всё в процесс-функции, звиняюсь за мудозвонство и спам-постинг.
Так, похоже сам нашёл проблему, selected всё ещё true когда вызывается area_entered, похоже просто нужно завести какую-то переменную для соприкосновения и перевести всё в процесс-функции, звиняюсь за мудозвонство и спам-постинг.
>>5503
Хмм... Почти убедительно, кроме небольшой детали. Ровно то же самое я могу делать в редакторе, только вместо консольной команды, у меня возможность прямо в скрипте описать словарь в джавовском стиле:
Так кроме того, я могу привязать часть значений прямо к внутриигровым переменным. Затем одной строчкой я получаю жсон-строку на сохранение или передачу. От забытых запятых меня защитит встроенная проверка синтаксиса. Если мне нужны ключи в виде цифр или ключевых слов, то описываю словарь в стиле словаря.
> 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
>}
>>5512
Создатель Dialogic предоставил еще более удобное редактирование - ивентщитом, так же известным как скретч. Это когда поток логики пишется сверху вниз специальными стыкующимися блоками, при этом есть блок-область, так же известный как С-блок, в который вкладываются другие блоки слева-направо.
Узнали? Согласны?
> удобнее редактировать лапшой
Создатель Dialogic предоставил еще более удобное редактирование - ивентщитом, так же известным как скретч. Это когда поток логики пишется сверху вниз специальными стыкующимися блоками, при этом есть блок-область, так же известный как С-блок, в который вкладываются другие блоки слева-направо.
Узнали? Согласны?
212 Кб, 802x771>>5546
Есть лучше вариант. Внедряем в годот программирование с помощью машины Тьюринга.
Есть лучше вариант. Внедряем в годот программирование с помощью машины Тьюринга.
>>5546
Такой блочный подход в рпг мейкер используется. Жутко неудобная штука для больших, разветвленных диалогов
Такой блочный подход в рпг мейкер используется. Жутко неудобная штука для больших, разветвленных диалогов
>>5537
Всё норм. Иногда нужно запостить проблему, чтобы её самостоятельно решить. Сам такой же.
>>5514
Нихуя вообще. Если пистолет это нода, то ему плевать вообще, в руках он или в воздухе. Он же сам стреляет. Просто делаем скилл, в котором несколько пистолетов, например.
Эх, годаны. Сразу видно - у вас луа нормального не было. Луашники ВСЁ хранят в луа. Скрипты на луа, конечно. Конфиги - тоже луа. Всякие там сцены или что-то типа того - на луа. И им абсолютно норм. Если бы в Годо был луа вместо гдскрипта, то гарантирую - все tscn и tres файлы были бы написаны на луа. Я уверен, дай луашникам такую возможность, они бы и графику хранили в луа.
Суть-то в чём. Разделение данных и логики - оно в голове программиста, а не в системах. Если у меня пачка файлов, одни из которых скрипты, а другие данные, я могу просто положить одни в папку scripts, а другие в папку data, и всё! Я разделиль. В соло или в очень маленькой команде этого будет достаточно. Все пляски с построением уровня абстракции между логикой и данными начинаются тогда, когда это разделение надо расшарить между несколькими кодерами, причём с рассчётом на некоторую текучку кадров. Тогда и желательно строить и сллой абстракции от движка, на всякий случай. Но если я в солямбу пилю условный проект на итч - мне эти все пляски не нужны. Для такого следует использовать по максимуму встроенные средства движка.
Я кончил.
Всё норм. Иногда нужно запостить проблему, чтобы её самостоятельно решить. Сам такой же.
>>5514
Нихуя вообще. Если пистолет это нода, то ему плевать вообще, в руках он или в воздухе. Он же сам стреляет. Просто делаем скилл, в котором несколько пистолетов, например.
>влом линкать все посты с обуждением форматов хранения данных
Эх, годаны. Сразу видно - у вас луа нормального не было. Луашники ВСЁ хранят в луа. Скрипты на луа, конечно. Конфиги - тоже луа. Всякие там сцены или что-то типа того - на луа. И им абсолютно норм. Если бы в Годо был луа вместо гдскрипта, то гарантирую - все tscn и tres файлы были бы написаны на луа. Я уверен, дай луашникам такую возможность, они бы и графику хранили в луа.
Суть-то в чём. Разделение данных и логики - оно в голове программиста, а не в системах. Если у меня пачка файлов, одни из которых скрипты, а другие данные, я могу просто положить одни в папку scripts, а другие в папку data, и всё! Я разделиль. В соло или в очень маленькой команде этого будет достаточно. Все пляски с построением уровня абстракции между логикой и данными начинаются тогда, когда это разделение надо расшарить между несколькими кодерами, причём с рассчётом на некоторую текучку кадров. Тогда и желательно строить и сллой абстракции от движка, на всякий случай. Но если я в солямбу пилю условный проект на итч - мне эти все пляски не нужны. Для такого следует использовать по максимуму встроенные средства движка.
Я кончил.
Хочу выложить игрушку в Яндекс, но когда на движке Godot 4.1.1 stable экспортирую проект и запускаю файл index.html, у меня возникает ошибка пикрил 1. Пробовал установить плагин пикрил 2, не помогло. В Ютубе видел ролик, где человек заливал проект на itch io, но там была возможность включить SharedArrayBuffer и Cross Origin Isolation, но в Яндексе так сделать вряд-ли получится, поскольку там можно только просто загрузить зип-файл с файлами игры. В редакторе всё работает. Объясните, что нужно сделать для запуска в браузере?
>>5582
Забыл упомянуть, что в настройках проекта плагин включил и затем экспортировал.
Забыл упомянуть, что в настройках проекта плагин включил и затем экспортировал.
>>5582
Я тебе его вроде и предлагал попробовать, там и дальнейшие шаги были - просить техсаппорт включить на сервере или перекатываться на 3
Я тебе его вроде и предлагал попробовать, там и дальнейшие шаги были - просить техсаппорт включить на сервере или перекатываться на 3
>>5582
Да, тебе нужна галка shared buffer array. Она должна быть на платформе, на которую заливаешь. Если у яндекса нет, то он хуй.
Альтернативно ты можешь попытаться избавиться от необходимости в в этой изоляции. В тройке изоляция была нужна если ты экспортишь под веб с тредами - выбиралось в опциях экспорта в годоте. В четверке не знаю, но возможно аналогично.
Про плагины не знаю.
Да, тебе нужна галка shared buffer array. Она должна быть на платформе, на которую заливаешь. Если у яндекса нет, то он хуй.
Альтернативно ты можешь попытаться избавиться от необходимости в в этой изоляции. В тройке изоляция была нужна если ты экспортишь под веб с тредами - выбиралось в опциях экспорта в годоте. В четверке не знаю, но возможно аналогично.
Про плагины не знаю.
>>5232
Я убил пол дня, но сделал супер примитивную систему диалогов. В начале не знал что такое словари, массивы и тем более синглтоны, но по документации и гайдам чуть чуть разобрался. Подгрузку файлов диалогов я откровенно не осилил, поэтому вписал диалог прямо в скрипт нпс. Система поддерживает максимум 2 говорящих, никаких условий, выборов и прочего нет. Но я добился того, чего хотел: оно хотя бы работает, по ентеру следующая реплика, пауза во время диалога. Еще хочу добавить подгрузку спрайта под говорящего и забить пока хуй и заняться другими аспектами, а то заебали меня эти диалоги.
Я убил пол дня, но сделал супер примитивную систему диалогов. В начале не знал что такое словари, массивы и тем более синглтоны, но по документации и гайдам чуть чуть разобрался. Подгрузку файлов диалогов я откровенно не осилил, поэтому вписал диалог прямо в скрипт нпс. Система поддерживает максимум 2 говорящих, никаких условий, выборов и прочего нет. Но я добился того, чего хотел: оно хотя бы работает, по ентеру следующая реплика, пауза во время диалога. Еще хочу добавить подгрузку спрайта под говорящего и забить пока хуй и заняться другими аспектами, а то заебали меня эти диалоги.
>>5595
Быдло!
Быдло!
>>5554
Приведи пример. На Диалоджике. В чём неудобство?
> Жутко неудобная штука для больших, разветвленных диалогов
Приведи пример. На Диалоджике. В чём неудобство?
>>5557
Есть же. И где твои игры?
https://github.com/gilzoide/godot-lua-pluginscript
Он так всем нужен, как я погляжу, что его до сих пор на 4.х не портировали.
> Если бы в Годо был луа вместо гдскрипта
Есть же. И где твои игры?
https://github.com/gilzoide/godot-lua-pluginscript
Он так всем нужен, как я погляжу, что его до сих пор на 4.х не портировали.
>>5589
Ужас. Кошмар. Впрочем, делай дальше.
Ужас. Кошмар. Впрочем, делай дальше.
>>5602
Не пользовался диалоджик, но выглядит так, что так очень геморно будет прыгать из одной ветки в другую и создавать альтернативные пути развития в зависимости от провала/успеха скиллчека, пола персонажа и т.д
Не пользовался диалоджик, но выглядит так, что так очень геморно будет прыгать из одной ветки в другую и создавать альтернативные пути развития в зависимости от провала/успеха скиллчека, пола персонажа и т.д
>>5610
А это тут к чему? Прямой, как палка, диалог он вывезет, ясно дело, и легко. Я про тот вариант, когда ты идешь по одной ветке диалогов и надо переключиться на другую.
А это тут к чему? Прямой, как палка, диалог он вывезет, ясно дело, и легко. Я про тот вариант, когда ты идешь по одной ветке диалогов и надо переключиться на другую.
102 Кб, 1075x691>>5617
Я про такие переходы. Когда из пойти в кино можно вырулить на "я б вдул".
Я про такие переходы. Когда из пойти в кино можно вырулить на "я б вдул".
>>5620
И вот про это я говорю. Пипец неудобно. Чтоб отследить куда ты прыгнул нужно искать лейбел, вместо простой и понятной связи.
И вот про это я говорю. Пипец неудобно. Чтоб отследить куда ты прыгнул нужно искать лейбел, вместо простой и понятной связи.
>>5624
Ладно бы просто неудобно. Я щас попытался твой скрин в диаложэике написать и обломался. Там ярлыки не работают. Бета версия, хуле. Либо я тупоя и не понял великий замысел копполы эмилио Такшта, да. Либо ждать, либо своё пилить.
Ладно бы просто неудобно. Я щас попытался твой скрин в диаложэике написать и обломался. Там ярлыки не работают. Бета версия, хуле. Либо я тупоя и не понял великий замысел копполы эмилио Такшта, да. Либо ждать, либо своё пилить.
>>5624
И кстати, если у тебя аналогичная твоему скрину лапша будет простираться на три экрана вправо и на десять экранов вниз, ты тоже заебёшься искать "простую и понятную связь".
> нужно искать лейбел, вместо простой и понятной связи
И кстати, если у тебя аналогичная твоему скрину лапша будет простираться на три экрана вправо и на десять экранов вниз, ты тоже заебёшься искать "простую и понятную связь".
>>5628
Неа. Это делается одним широким движением (колесико для зумаута, проследить мышкой путь, колесиком зум ин)
Неа. Это делается одним широким движением (колесико для зумаута, проследить мышкой путь, колесиком зум ин)
60 Кб, 772x794>>5634
И опять же главный минус современной лапши, она движется слева направо, хотя у тебя в блок схеме >>5621 прописано движение сверху вниз. Это главная проблема всей лапши от анриала, до блендера, годота, и т.п.
Почему-то среди разрабов утвердилось ошибочное мнение, что направлять поток логики справа-налево лучше, чем двигать его адаптивно. Никто из тех кого я видел, не пытается делать адаптивную лапшу. Если второй блок снизу - линия проводится вниз. Если второй блок слева, линия проводится влево. Нет. Линия выходных пинов жёстко прибита гвоздями к левой границе блока.
Смотри как уёбищно:
И опять же главный минус современной лапши, она движется слева направо, хотя у тебя в блок схеме >>5621 прописано движение сверху вниз. Это главная проблема всей лапши от анриала, до блендера, годота, и т.п.
Почему-то среди разрабов утвердилось ошибочное мнение, что направлять поток логики справа-налево лучше, чем двигать его адаптивно. Никто из тех кого я видел, не пытается делать адаптивную лапшу. Если второй блок снизу - линия проводится вниз. Если второй блок слева, линия проводится влево. Нет. Линия выходных пинов жёстко прибита гвоздями к левой границе блока.
Смотри как уёбищно:
>>5635
Сам не понимаю такого подхода. У меня, вообще, линии выходят из центра блока потому их, думаю, можно назвать адативными. Но мне удобнее всего строить сверху вниз
Сам не понимаю такого подхода. У меня, вообще, линии выходят из центра блока потому их, думаю, можно назвать адативными. Но мне удобнее всего строить сверху вниз
>>5637
Ну ты это где нарисовал? Пейнт? Фотошоп? Это понятно, нарисовать можно как угодно, но это останется рисунком. Проблема в том, чтобы рисунок грамотно воспроизвести в программной среде. Чтобы не потерять суть. А с этим-то как раз в 2к23 проблемы.
> У меня
Ну ты это где нарисовал? Пейнт? Фотошоп? Это понятно, нарисовать можно как угодно, но это останется рисунком. Проблема в том, чтобы рисунок грамотно воспроизвести в программной среде. Чтобы не потерять суть. А с этим-то как раз в 2к23 проблемы.
>>5635
Я как-то набрасывал концепт нод-ориентированной-граф-лапши, у которой адаптивные входные и выходные пины ездят по границам блока вслед за линией. Но. Лень матушка. Эххх.
Я как-то набрасывал концепт нод-ориентированной-граф-лапши, у которой адаптивные входные и выходные пины ездят по границам блока вслед за линией. Но. Лень матушка. Эххх.
>>5641
Подожди. Ты другой анон. С предыдущим аноном я беседовал, который годот позавчера установил и ни черта не шарил.
А на твой редактор я бы взглянул. Скинешь сорцы?
Подожди. Ты другой анон. С предыдущим аноном я беседовал, который годот позавчера установил и ни черта не шарил.
А на твой редактор я бы взглянул. Скинешь сорцы?
>>5605
Прямо сейчас готовлю к релизу на ЯИ и пытаюсь вкурить, как правильно подключить переключение в фуллскрин через сдк, ибо жабаскрипта я не знаю.
А луа на Годо действительно не нужен. Там нет полноценного ООП, можно разве что собрать костыльно-велоипедный аналог. Как бы я ни любил луа, но конкретно тут он не нужен. Гдскрипт умеет всё то же самое, но лучше. Разве что в тройке немножко не хватает типа callable.
Касательно приведённой тобой ссылки. Там нет поддержки луа 5.2+, но это терпимо. Главное - там нет поддержки дебажных коллбэков. Исполнение останавливается из-за ошибки, но что за ошибка и в каком месте кода - гадай сам. Это пиздец, так работать невозможно.
>И где твои игры?
Прямо сейчас готовлю к релизу на ЯИ и пытаюсь вкурить, как правильно подключить переключение в фуллскрин через сдк, ибо жабаскрипта я не знаю.
А луа на Годо действительно не нужен. Там нет полноценного ООП, можно разве что собрать костыльно-велоипедный аналог. Как бы я ни любил луа, но конкретно тут он не нужен. Гдскрипт умеет всё то же самое, но лучше. Разве что в тройке немножко не хватает типа callable.
Касательно приведённой тобой ссылки. Там нет поддержки луа 5.2+, но это терпимо. Главное - там нет поддержки дебажных коллбэков. Исполнение останавливается из-за ошибки, но что за ошибка и в каком месте кода - гадай сам. Это пиздец, так работать невозможно.
>>5656
В топ-5 конкурентов anonfiles.com, по данным на сентябрь 2023, входят gofile.io, mega.nz, mediafire.com, 1fichier.com и другие сайты.
Пакуешь в архив с паролем. Пароль - стандартный. 2ch Архив на любой бесплатный файлообменник. Ссылку сюда.
> куда залить, чтоб нельзя было сдеанонить
В топ-5 конкурентов anonfiles.com, по данным на сентябрь 2023, входят gofile.io, mega.nz, mediafire.com, 1fichier.com и другие сайты.
Пакуешь в архив с паролем. Пароль - стандартный. 2ch Архив на любой бесплатный файлообменник. Ссылку сюда.
>>5545
При чём тут GDScript? Речь шла про скрипты для сценариста/писателя, который будет их тебе писать.
Это просто дополнительный слой абстракции.
>Почти убедительно, кроме небольшой детали. Ровно то же самое я могу делать в редакторе
>>var config = {
>>>key1 = 123,
>>>key2 = {
При чём тут GDScript? Речь шла про скрипты для сценариста/писателя, который будет их тебе писать.
Это просто дополнительный слой абстракции.
>>5665
Мне зашла система типажей раста (которая не растом придумана, офк). Уже джва месяца восхищаюсь этой идеей. Это ж как охуенно придумали, и почему я раньше об этом не узнал?
И главное, я размышлял, вот есть структы и классы, но зачем? Вот были бы только структы, а вместо классов интерфейсы, в которых объявляются методы, а потом ты пишешь что-то типа
то есть, чтобы к интерфейсу с методами при создании инстанса биндился подходящий структ. Но никто мне не подсказал. На раст и на системы типажей (трейтов) я наткнулся случайно, гугля совершенно другое.
Мне зашла система типажей раста (которая не растом придумана, офк). Уже джва месяца восхищаюсь этой идеей. Это ж как охуенно придумали, и почему я раньше об этом не узнал?
И главное, я размышлял, вот есть структы и классы, но зачем? Вот были бы только структы, а вместо классов интерфейсы, в которых объявляются методы, а потом ты пишешь что-то типа
> var foo = new IMyInterface<MyStruct>(); #псевдошарп
то есть, чтобы к интерфейсу с методами при создании инстанса биндился подходящий структ. Но никто мне не подсказал. На раст и на системы типажей (трейтов) я наткнулся случайно, гугля совершенно другое.
>>5675
Вроде они это из Го спиздили. Когда Го учил натолкнулся на это и тоже впечатлился, просто свежий воздух после душных классов плюсов/сисярпа.
Вроде они это из Го спиздили. Когда Го учил натолкнулся на это и тоже впечатлился, просто свежий воздух после душных классов плюсов/сисярпа.
59 Кб, 422x1785>>5694
Так можно любое обсуждение прервать.
>>5697
Не понял, ты про Hjson?
>>5767
Если ты не можешь последить пути в такой простой текстовой записи, то это с тобой что-то не так. Как ты вообще код пишешь? В коде постоянно есть "возможные пути" (вызовы функций, обращения к полям класса и т.д.), но ты как-то их видишь без подсказок. VisualScript убрали за ненадобностью и правильно сделали - от подобной визуализации кода толку нет, она только вводит в заблуждение и мешает освоить нормальный кодинг.
В принципе, можно автоматически генерировать визуализацию графа, но есть один нюанс: сколь-либо сложная история визуально будет таким хаосом, что толку от визуализации не будет, как нет толку от хаотичной визуальной лапши императивного кода. Вот даже эта история на 10 нод оказалась визуально сложнее, чем я предполагал, а ведь я писал простым текстом и "отлаживал" мысленно без визуализации (представлял только GUI визуальной новеллы с точки зрения игрока, "играя" мысленно).
Написание интерактивных историй по сути не отличается от процедурного программирования: линейный код = линейная история, if/match = развилки, for/while = повторы, процедуры = странички/реплики. В коде визуализации не нужны, так зачем визуализация интерактивных историй?
Отдельный скриптовый язык нужен только как абстракция над конкретным движком, т.е. вот такой скрипт на скриншоте будет легче перенести на другой движок и легче его составлять, не задумываясь о нюансах реализации (как движок будет рендерить сцены, как он будет запрашивать ввод у игрока и т.д.). А так, хоть на ассемблере пиши интерактивные истории, суть не изменится, только портировать будет намного сложнее.
>Бывает лишь подходящее тебе
Так можно любое обсуждение прервать.
>>5697
>Хорошая, годная утилита
Не понял, ты про Hjson?
>>5767
>вообще невозможно проследить возможные пути
Если ты не можешь последить пути в такой простой текстовой записи, то это с тобой что-то не так. Как ты вообще код пишешь? В коде постоянно есть "возможные пути" (вызовы функций, обращения к полям класса и т.д.), но ты как-то их видишь без подсказок. VisualScript убрали за ненадобностью и правильно сделали - от подобной визуализации кода толку нет, она только вводит в заблуждение и мешает освоить нормальный кодинг.
В принципе, можно автоматически генерировать визуализацию графа, но есть один нюанс: сколь-либо сложная история визуально будет таким хаосом, что толку от визуализации не будет, как нет толку от хаотичной визуальной лапши императивного кода. Вот даже эта история на 10 нод оказалась визуально сложнее, чем я предполагал, а ведь я писал простым текстом и "отлаживал" мысленно без визуализации (представлял только GUI визуальной новеллы с точки зрения игрока, "играя" мысленно).
Написание интерактивных историй по сути не отличается от процедурного программирования: линейный код = линейная история, if/match = развилки, for/while = повторы, процедуры = странички/реплики. В коде визуализации не нужны, так зачем визуализация интерактивных историй?
Отдельный скриптовый язык нужен только как абстракция над конкретным движком, т.е. вот такой скрипт на скриншоте будет легче перенести на другой движок и легче его составлять, не задумываясь о нюансах реализации (как движок будет рендерить сцены, как он будет запрашивать ввод у игрока и т.д.). А так, хоть на ассемблере пиши интерактивные истории, суть не изменится, только портировать будет намного сложнее.
15 Кб, 512x643>>5778
Ладно, это из-за того, что я от руки рисовал.
Вот, например: https://mermaid.js.org/
Можно подключить аддоном к TiddlyWiki, чтобы совместить с вики-диздоком игры:
https://github.com/efurlanm/mermaid-tw5
Но всё равно... В чём польза? Смотря на этот граф, можно представить себе обычную программу с несколькими if-else и одним большим циклом while true. Не вижу пользы от такого рода визуализаций, если пишешь историю сам. Может быть, для командной работы оно бы имело какой-то смысл, типа, видеть кто сколько лапши на вилки накрутить успел, или чтобы похвастаться своей лапшой перед товарищами. Но командная писанина - это уже совершенно отдельная тема.
Да, я пробовал использовать графические редакторы. Неудобно. Все эти визуализации растягиваются на огромное полотно и ты больше возишься с GUI редактора, чем печатаешь текст. Нет того UX, который ожидаешь от полезного и удобного инструмента; постоянное ощущение борьбы с костылями (особенно когда нет поддержки привычных стрелочек, таба, энтер и т.д.). Поэтому я несколько раз придумывал свои велосипеды...
Большое преимущество набора текста в том, что можно печатать в любом, даже самом примитивном редакторе текста, на любом устройстве. Те же аддоны для Godot требуют сам Godot, верно? А текстовый файл ты можешь на ходу печатать без Godot. Потом скинешь на компьютер и, если очень сильно надо, сделаешь визуализацию или конвертацию в другой формат. Но чтобы это было удобно, формат записи должен быть удобен для ручной записи, никакого XML с его тегами, GDScript с кучей длинных имён функций и т.п. - т.е. нужен свой формат/язык.
>сложнее, чем я предполагал
Ладно, это из-за того, что я от руки рисовал.
>автоматически генерировать
Вот, например: https://mermaid.js.org/
Можно подключить аддоном к TiddlyWiki, чтобы совместить с вики-диздоком игры:
https://github.com/efurlanm/mermaid-tw5
Но всё равно... В чём польза? Смотря на этот граф, можно представить себе обычную программу с несколькими if-else и одним большим циклом while true. Не вижу пользы от такого рода визуализаций, если пишешь историю сам. Может быть, для командной работы оно бы имело какой-то смысл, типа, видеть кто сколько лапши на вилки накрутить успел, или чтобы похвастаться своей лапшой перед товарищами. Но командная писанина - это уже совершенно отдельная тема.
Да, я пробовал использовать графические редакторы. Неудобно. Все эти визуализации растягиваются на огромное полотно и ты больше возишься с GUI редактора, чем печатаешь текст. Нет того UX, который ожидаешь от полезного и удобного инструмента; постоянное ощущение борьбы с костылями (особенно когда нет поддержки привычных стрелочек, таба, энтер и т.д.). Поэтому я несколько раз придумывал свои велосипеды...
Большое преимущество набора текста в том, что можно печатать в любом, даже самом примитивном редакторе текста, на любом устройстве. Те же аддоны для Godot требуют сам Godot, верно? А текстовый файл ты можешь на ходу печатать без Godot. Потом скинешь на компьютер и, если очень сильно надо, сделаешь визуализацию или конвертацию в другой формат. Но чтобы это было удобно, формат записи должен быть удобен для ручной записи, никакого XML с его тегами, GDScript с кучей длинных имён функций и т.п. - т.е. нужен свой формат/язык.
>>5790
так это нам кодерам, сценаристам проще таскать полотно с нодами графа, колесиком масштабировать и мышкой тыкоть в нужные поля для заполнения
так это нам кодерам, сценаристам проще таскать полотно с нодами графа, колесиком масштабировать и мышкой тыкоть в нужные поля для заполнения
>>5790
Сходу сразу видно два преимущества
1. Видно сколько и откуда ВХОДИТ в ноду. Изначальный текст явно описывает только выходы.
2. Видны обходные пути целиком. В исходном тексте видно только выходы, чтобы узнать, что они сойдутся, надо скакать по всему файлу.
Сходу сразу видно два преимущества
1. Видно сколько и откуда ВХОДИТ в ноду. Изначальный текст явно описывает только выходы.
2. Видны обходные пути целиком. В исходном тексте видно только выходы, чтобы узнать, что они сойдутся, надо скакать по всему файлу.
>>5778
В коде есть удобные инструменты, такие как вынос в функцию или инкапсуляция в объект. Тогда ифы остаются компактными. Еще есть сворачивание блоков кода в ide. Но такой блок не свернуть, вернее он свернется целиком, и информации о связях скроются.
В коде есть удобные инструменты, такие как вынос в функцию или инкапсуляция в объект. Тогда ифы остаются компактными. Еще есть сворачивание блоков кода в ide. Но такой блок не свернуть, вернее он свернется целиком, и информации о связях скроются.
Хочу сделать игру суть такова, смесь ангри бердс, флаппи берд, зельды и принца персии. Подводные?
>>5873
Откат у меня сделан несколько лет назад, откатил твой откат
Откат у меня сделан несколько лет назад, откатил твой откат
Сукаблять ёбаный встроенный браузер файлов.
Случайно неловким движением тачпада перетащил папку scenes в другое место, и это хуйня не только не спросила, хочу ли я вообще это делать, так она мне перелопатила зависимости сцен под это перемещение, сохранила проект и отказалась делать ctrl+z; но по опончании перемещения всё-таки выругалась, что что-то там не может сохранить. А при обратном перемещении пересохранила часть, но не пересохранила другую. Ну и конечно же последний бэкап я делал давно, потому что ну что может пойти не так?
Спрашивается: какого хуя перед таким массивным изменением, которое можно сделать абсолютно случайно одним движением пальца, не вылезает какого-то предупредительного окошка?
Случайно неловким движением тачпада перетащил папку scenes в другое место, и это хуйня не только не спросила, хочу ли я вообще это делать, так она мне перелопатила зависимости сцен под это перемещение, сохранила проект и отказалась делать ctrl+z; но по опончании перемещения всё-таки выругалась, что что-то там не может сохранить. А при обратном перемещении пересохранила часть, но не пересохранила другую. Ну и конечно же последний бэкап я делал давно, потому что ну что может пойти не так?
Спрашивается: какого хуя перед таким массивным изменением, которое можно сделать абсолютно случайно одним движением пальца, не вылезает какого-то предупредительного окошка?
>>5878
Сочуствую. Как говорится, есть те, кто не делают бэкапов, те. кто уже делает, и те, кто делают их регулярно, а еще проверяют восстанавливаемость. Что же касается твоей претензии, хз как это можно разрулить. Можно попробовать написать аддон который будет блочить операции над файлами, или патч в сам редактор.
Сочуствую. Как говорится, есть те, кто не делают бэкапов, те. кто уже делает, и те, кто делают их регулярно, а еще проверяют восстанавливаемость. Что же касается твоей претензии, хз как это можно разрулить. Можно попробовать написать аддон который будет блочить операции над файлами, или патч в сам редактор.
142 Кб, 1280x1043>>5878
Вот почему надо вести свой проект в git даже если ты работаешь один, и рубить изменения на небольшие коммиты.
>Ну и конечно же последний бэкап я делал давно, потому что ну что может пойти не так?
Вот почему надо вести свой проект в git даже если ты работаешь один, и рубить изменения на небольшие коммиты.
>>5906
От того что ты в гит переедешь дисциплина не появится. Раньше бекапы не делал, теперь коммитить не будешь. А когда завалишься с конфликтующими изменениями - вообще забьешь.
От того что ты в гит переедешь дисциплина не появится. Раньше бекапы не делал, теперь коммитить не будешь. А когда завалишься с конфликтующими изменениями - вообще забьешь.
>>5907
Работаю с гитом больше 5 лет со своими и чужими проектами, хз. Наверное то что я начинал вообще с проектов в опенсурсе меня многому научило.
А так skill issue.
Работаю с гитом больше 5 лет со своими и чужими проектами, хз. Наверное то что я начинал вообще с проектов в опенсурсе меня многому научило.
А так skill issue.
>>5907
Автоматизируетя.
Автоматизируетя.
>>5906
А какая разница, гит или зип, если "ладно, потом забэкаплю"?
>>5884
Меня удивляет другое. Схуяли всё сохраняется без явной на то команды? Почему бы перед таким изменением не высветить хотя бы "Для продолжения потребуется сохранить проект и все открытые сцены. [Продолжить][отмена]".
>>5887
А что в тачпаде не так? Сижу с ноутом в кресле, обложившись подушками. Удобно. Мышь в таком положении не подключить.
А какая разница, гит или зип, если "ладно, потом забэкаплю"?
>>5884
Меня удивляет другое. Схуяли всё сохраняется без явной на то команды? Почему бы перед таким изменением не высветить хотя бы "Для продолжения потребуется сохранить проект и все открытые сцены. [Продолжить][отмена]".
>>5887
А что в тачпаде не так? Сижу с ноутом в кресле, обложившись подушками. Удобно. Мышь в таком положении не подключить.
45 Кб, 1280x535>>5910
Потому что это система контроля версий, адекватная и проверенная.
Я не знаю как вы тут вообще живете без гита нахуй. Сломал проект жирным багом - откатил назад (сделал чекаут) - узнал в каком коммите ты насрал себе в штаны - дебажишь именно эти изменения. И это минимум того что им можно делать, я уж не говорю о том что другого человека на проект позвать с минимум ебли или как вообще релизы делать хоть куда-то без гита.
Гит это не единственная система контроля версий, но самая популярная. Пиздуйте знакомится чтоб не быть как вон тот анон >>5878 благо там за пару часов разобраться можно.
Из клиентов для начала есть базовый клиент Гитхаба, но он трехкнопочный и мало что может. Впрочем для работы в соляну самое то, нахуя тебе конфликты мержа вообще резолвить если ты делаешь все в одной ветке скорее всего. Тупо сри малыми порциями в мастер/мейн.
>А какая разница, гит или зип, если "ладно, потом забэкаплю"?
Потому что это система контроля версий, адекватная и проверенная.
Я не знаю как вы тут вообще живете без гита нахуй. Сломал проект жирным багом - откатил назад (сделал чекаут) - узнал в каком коммите ты насрал себе в штаны - дебажишь именно эти изменения. И это минимум того что им можно делать, я уж не говорю о том что другого человека на проект позвать с минимум ебли или как вообще релизы делать хоть куда-то без гита.
Гит это не единственная система контроля версий, но самая популярная. Пиздуйте знакомится чтоб не быть как вон тот анон >>5878 благо там за пару часов разобраться можно.
Из клиентов для начала есть базовый клиент Гитхаба, но он трехкнопочный и мало что может. Впрочем для работы в соляну самое то, нахуя тебе конфликты мержа вообще резолвить если ты делаешь все в одной ветке скорее всего. Тупо сри малыми порциями в мастер/мейн.
Алсо никогда не используйте Гит Кракен, это параша у меня уже три раза ветки ломала, и у знакомых тоже.
2Д.
Вырезаю текстуру из атласа, накладываю на нее шейдер аутлайна.
В этой ситуации шейдится весь атлас целиком, как я понял? Он довольно большой, наверняка жрет немало.
Я бы хотел шейдить только отдельные куски, как этого добиться?
Вырезаю текстуру из атласа, накладываю на нее шейдер аутлайна.
В этой ситуации шейдится весь атлас целиком, как я понял? Он довольно большой, наверняка жрет немало.
Я бы хотел шейдить только отдельные куски, как этого добиться?
>>5911
Git похож на c++. Или на ffmpeg. Пока пользуешься им в поверхностном режиме, ну там только clone или только add/commit то все хорошо. Как только что-то сложнее такие танцы с бубном начинаются. То HEAD куда то слетит то не дает ничего делать ругаясь на какие-нибудь конфликты. Помню, даже отказаться от несохраненных изменений сложнее, чем сохранить их и откатить. Вырезать предпоследнее изменение тоже был веселый квест.
Но вот самая жесть была когда я попробовал впервые за 3 года разрабатывать как у серьезных людей, с фиче-ветками. Создал я ветку на фичу, что-то дописал, а потом увидел пару косяков в другом месте и походу исправил. Ну и результат понятен, фичеветка забивается нерелейтедом, а если переключиться то эти фиксы надо вспоминать и черрипикать. Ну в самом деле получается что мне исправление это пару кнопок за секунду нажать, но для этого надо по минуте между ветками переключаться.
Git похож на c++. Или на ffmpeg. Пока пользуешься им в поверхностном режиме, ну там только clone или только add/commit то все хорошо. Как только что-то сложнее такие танцы с бубном начинаются. То HEAD куда то слетит то не дает ничего делать ругаясь на какие-нибудь конфликты. Помню, даже отказаться от несохраненных изменений сложнее, чем сохранить их и откатить. Вырезать предпоследнее изменение тоже был веселый квест.
Но вот самая жесть была когда я попробовал впервые за 3 года разрабатывать как у серьезных людей, с фиче-ветками. Создал я ветку на фичу, что-то дописал, а потом увидел пару косяков в другом месте и походу исправил. Ну и результат понятен, фичеветка забивается нерелейтедом, а если переключиться то эти фиксы надо вспоминать и черрипикать. Ну в самом деле получается что мне исправление это пару кнопок за секунду нажать, но для этого надо по минуте между ветками переключаться.
>>5916
или сливаешь две ветки в одну, а потом приходит пиздец
или сливаешь две ветки в одну, а потом приходит пиздец
>>5916
Простейшие конфликты резолвятся без проблем если делать мерж через гит клиент, регулярно делаю это сам на работе. Просто через IDE смотреть где насрано и вилкой чистить каждый раз, а гит клиент потом тебе соберет мерж коммит.
У тебя должна быть одна ветка dev в которую ты стабильно льешь все говно, и ты мержишь её в свои фичеветки. Чтобы служить как раз таки центром для всех этих фиксов. Гит он не для того чтобы делать разветвления и сидеть на разных ветках месяцами, отличия накапливаются и их нужно регулярно резолвить.
Но опять же, солодевелоперу это нахуй не нужно. Тупо ветка для работы и ветка для релизов, dev и main, так и сидишь.
>Как только что-то сложнее такие танцы с бубном начинаются.
Простейшие конфликты резолвятся без проблем если делать мерж через гит клиент, регулярно делаю это сам на работе. Просто через IDE смотреть где насрано и вилкой чистить каждый раз, а гит клиент потом тебе соберет мерж коммит.
>Но вот самая жесть была когда я попробовал впервые за 3 года разрабатывать как у серьезных людей, с фиче-ветками. Создал я ветку на фичу, что-то дописал, а потом увидел пару косяков в другом месте и походу исправил. Ну и результат понятен, фичеветка забивается нерелейтедом, а если переключиться то эти фиксы надо вспоминать и черрипикать.
У тебя должна быть одна ветка dev в которую ты стабильно льешь все говно, и ты мержишь её в свои фичеветки. Чтобы служить как раз таки центром для всех этих фиксов. Гит он не для того чтобы делать разветвления и сидеть на разных ветках месяцами, отличия накапливаются и их нужно регулярно резолвить.
Но опять же, солодевелоперу это нахуй не нужно. Тупо ветка для работы и ветка для релизов, dev и main, так и сидишь.
>>5911
/r/ мастер-класс по гиту. Моё взаимодействие с ним ограничивается заливкой кода через веб-морду, чтобы этот код заопенсурсить. Пытался по гайдам в более сложные взаимодействия - не понял, как и зачем. В итоге сломал об него зубы и забил.
Гит это профессиональный инструмент, которым при умелом использовании можно увеличить член, но при неумелом получится скорее его отстрелить. Как всякий профессиональный инструмент, он вываливает перед тобой весь свой функционал и предполагает, что ты знаешь, зачем это тебе нужно, в каких ситуациях и как этим всем пользоваться.
>>5915
Никак. Нет, серьёзно, я сталкивался буквально с этой же проблемой. При использовании атласов (спрайтшитов, текстур с кадрами анимаци и т.п.) шейдеру отдаётся весь атлас целиком, и это никак не изменить. Ты разве что можешь силами гдскрипта вырезать нужный тебе кусок, создать из него новую текстуру и скормить её шейдеру. Но выглядит не очень рационально.
/r/ мастер-класс по гиту. Моё взаимодействие с ним ограничивается заливкой кода через веб-морду, чтобы этот код заопенсурсить. Пытался по гайдам в более сложные взаимодействия - не понял, как и зачем. В итоге сломал об него зубы и забил.
Гит это профессиональный инструмент, которым при умелом использовании можно увеличить член, но при неумелом получится скорее его отстрелить. Как всякий профессиональный инструмент, он вываливает перед тобой весь свой функционал и предполагает, что ты знаешь, зачем это тебе нужно, в каких ситуациях и как этим всем пользоваться.
>>5915
Никак. Нет, серьёзно, я сталкивался буквально с этой же проблемой. При использовании атласов (спрайтшитов, текстур с кадрами анимаци и т.п.) шейдеру отдаётся весь атлас целиком, и это никак не изменить. Ты разве что можешь силами гдскрипта вырезать нужный тебе кусок, создать из него новую текстуру и скормить её шейдеру. Но выглядит не очень рационально.
>>1894 (OP)
"Дизайн должен быть функциональным, а функциональность должна быть переведена в визуальную эстетику, без какой-либо зависимости от трюков, которые необходимо объяснять."
"Дизайн должен быть функциональным, а функциональность должна быть переведена в визуальную эстетику, без какой-либо зависимости от трюков, которые необходимо объяснять."
>>5921
Твой код - это многомерное фрактальное дерево правок и исправлений, реализующих полёт твоей мысли. Чтобы уместить это дерево в сколь бы то ни было удобоваримом виде, придуманы системы контроля версий. Ну и конечно же для коллаборации команд, у которых Лебедь кодит вверх, Рак кодит в сторону, Шука кодит вниз, а продукт должен работать.
Ты ничего не понял? Оттож.
От гита тебе на начальном этапе нужно выучить три команды:
1. Залогиниться в гит-хабе.
2. Отправить проект в репозиторий.
3. Скачать проект из репозитория.
>не понял, как и зачем
Твой код - это многомерное фрактальное дерево правок и исправлений, реализующих полёт твоей мысли. Чтобы уместить это дерево в сколь бы то ни было удобоваримом виде, придуманы системы контроля версий. Ну и конечно же для коллаборации команд, у которых Лебедь кодит вверх, Рак кодит в сторону, Шука кодит вниз, а продукт должен работать.
Ты ничего не понял? Оттож.
От гита тебе на начальном этапе нужно выучить три команды:
1. Залогиниться в гит-хабе.
2. Отправить проект в репозиторий.
3. Скачать проект из репозитория.
>>5921
Я надеюсь ты пробовал ставить любой ui гит клиент (соурстри всякие, форки и т.д.) или ты чисто с башем сидишь?
Если ставил, то я не понимаю что с тобой не так, там 3-4 кнопки жмешь и ещё столько же при черепиках, обновлении подмодулей и прочих не частых операциях
Если кто-то говорит, что только консоль тру, шли нахуй
Я надеюсь ты пробовал ставить любой ui гит клиент (соурстри всякие, форки и т.д.) или ты чисто с башем сидишь?
Если ставил, то я не понимаю что с тобой не так, там 3-4 кнопки жмешь и ещё столько же при черепиках, обновлении подмодулей и прочих не частых операциях
Если кто-то говорит, что только консоль тру, шли нахуй
142 Кб, 1045x725Гайды по гиту были в /pr
Для годота есть официальный гит плагин.
Есть подводный - если кликнуть на коммит с большим бинарным изменением, например импортом 3д уровня, можно надолго идти пить кофе.
Игры делайте
Для годота есть официальный гит плагин.
Есть подводный - если кликнуть на коммит с большим бинарным изменением, например импортом 3д уровня, можно надолго идти пить кофе.
Игры делайте
Делаю игру. Экспортнул в свою игру первую полупрозрачную 3д модельку.
>>5963
А зачем бинарные данные в гите? Они отдельно должны быть, разве нет? Максимум иконки, но не огромные файлы на несколько мегабайт данных...
>коммит с большим бинарным изменением, например импортом 3д уровня
А зачем бинарные данные в гите? Они отдельно должны быть, разве нет? Максимум иконки, но не огромные файлы на несколько мегабайт данных...
>>5878
Пользуюсь им только для составления новых сцен их сохранённых сцен. В остальном он не нужен. Перенос файлов осуществляю через проводник Windows.
Глючность встроенного менеджера файлов хорошо известна уже много лет. Ньюфаги охреневают, но на практике такие же проблемы что у Unity, что у UE. Рекомендуется вообще файлы проекта не двигать, чтобы не было таких последствий. В 4.0 начали реализовывать систему UID, но она тоже пока что (на момент 4.1) глючная и доставляет проблем, а главное - теперь вручную tscn сложнее фиксить.
Рекомендую выключить жест "тап == клик" или "двойной так == захват для переноса", чтобы избегать подобных проблем. Пользуйся физической кнопкой для кликов, она должна быть жёсткой и поэтому не так сильно подвержена случайностям.
Почему? Храни файлы данных в другом месте, а код всего проекта будет занимать очень мало места. Я настроил шорткаты, чтобы в два клика делать бекап.
>встроенный браузер файлов
Пользуюсь им только для составления новых сцен их сохранённых сцен. В остальном он не нужен. Перенос файлов осуществляю через проводник Windows.
Глючность встроенного менеджера файлов хорошо известна уже много лет. Ньюфаги охреневают, но на практике такие же проблемы что у Unity, что у UE. Рекомендуется вообще файлы проекта не двигать, чтобы не было таких последствий. В 4.0 начали реализовывать систему UID, но она тоже пока что (на момент 4.1) глючная и доставляет проблем, а главное - теперь вручную tscn сложнее фиксить.
>Случайно неловким движением тачпада
Рекомендую выключить жест "тап == клик" или "двойной так == захват для переноса", чтобы избегать подобных проблем. Пользуйся физической кнопкой для кликов, она должна быть жёсткой и поэтому не так сильно подвержена случайностям.
>Ну и конечно же последний бэкап я делал давно, потому что ну что может пойти не так?
Почему? Храни файлы данных в другом месте, а код всего проекта будет занимать очень мало места. Я настроил шорткаты, чтобы в два клика делать бекап.
>>5878
Потому что в идеале это массивное изменение не должно приводить к каким-либо негативным последствиям. То есть, если бы всё работало без ошибок, случайный перенос можно было бы вернуть обратно простым переносом файла. Беда в том, что какие-то скрытые ошибки ломают процесс переноса файлов, даже если ты всего один файл переносишь.
>>5910
А что такого в сохранении? Меня больше удивляет, почему кто-то работает с проектом, ничего долго не сохраняя. Это же гарантированный путь к фейлу по множеству причин. В идеале проект и все файлы должны автоматически сохраняться на диск спустя несколько секунд после внесения изменений.
Неоднократно сталкивался с тем, что настроил новую большую сцену и забыл её сохранить, редактор из-за какой-то ошибки крашнулся и ничего не сохранилось - пришлось воссоздавать сцену с нуля по памяти.
Если ты хочешь поработать над чем-то и затем это удалить, просто сделай копию файлов/проекта.
>перед таким массивным изменением, которое можно сделать абсолютно случайно одним движением пальца, не вылезает какого-то предупредительного окошка
Потому что в идеале это массивное изменение не должно приводить к каким-либо негативным последствиям. То есть, если бы всё работало без ошибок, случайный перенос можно было бы вернуть обратно простым переносом файла. Беда в том, что какие-то скрытые ошибки ломают процесс переноса файлов, даже если ты всего один файл переносишь.
>>5910
>Схуяли всё сохраняется без явной на то команды? Почему бы перед таким изменением не высветить хотя бы "Для продолжения потребуется сохранить проект и все открытые сцены.
А что такого в сохранении? Меня больше удивляет, почему кто-то работает с проектом, ничего долго не сохраняя. Это же гарантированный путь к фейлу по множеству причин. В идеале проект и все файлы должны автоматически сохраняться на диск спустя несколько секунд после внесения изменений.
Неоднократно сталкивался с тем, что настроил новую большую сцену и забыл её сохранить, редактор из-за какой-то ошибки крашнулся и ничего не сохранилось - пришлось воссоздавать сцену с нуля по памяти.
Если ты хочешь поработать над чем-то и затем это удалить, просто сделай копию файлов/проекта.
>>5975
Ну тебе историю проекта как-то хранить надо же. Хз, у Юнити и гитом такая же трабла, всем похуй пока размер истории коммитов не превышает лимиты гитхаба. Тогда просто срезают историю.
>А зачем бинарные данные в гите? Они отдельно должны быть, разве нет?
Ну тебе историю проекта как-то хранить надо же. Хз, у Юнити и гитом такая же трабла, всем похуй пока размер истории коммитов не превышает лимиты гитхаба. Тогда просто срезают историю.
>>5911
Нормально. Просто нужно следовать этому подходу:
https://ru.wikipedia.org/wiki/Итеративная_разработка
Тогда ты не будешь высирать 100500 строк кода без единого теста, а потом "ой, что-то не работает, но я понятия не имею, что". Очевидно, если ты высрал строчку кода и что-то сломал, виновата эта строчка, ведь все остальные части проекта тесты проходят.
Godot идеально подходит для этого. Ты разделяешь проект на множество независимых частей, каждая из которых способна существовать отдельно от других, и поэтому её можно разработать и протестировать независимо от остального проекта. У тебя нет шанса обосраться где-то и не заметить этого, а если ты даже обосрёшься, твой обсёр изолирован в небольшом фрагменте, без которого проект может работать.
Зачем делать коммит, если ты только что обосрался?
Чтобы он свои грязные ручонки в мой идеальный, красивый, любимый код совал? NO WAY!
>Я не знаю как вы тут вообще живете без гита
Нормально. Просто нужно следовать этому подходу:
https://ru.wikipedia.org/wiki/Итеративная_разработка
Тогда ты не будешь высирать 100500 строк кода без единого теста, а потом "ой, что-то не работает, но я понятия не имею, что". Очевидно, если ты высрал строчку кода и что-то сломал, виновата эта строчка, ведь все остальные части проекта тесты проходят.
Godot идеально подходит для этого. Ты разделяешь проект на множество независимых частей, каждая из которых способна существовать отдельно от других, и поэтому её можно разработать и протестировать независимо от остального проекта. У тебя нет шанса обосраться где-то и не заметить этого, а если ты даже обосрёшься, твой обсёр изолирован в небольшом фрагменте, без которого проект может работать.
>узнал в каком коммите ты насрал себе в штаны
Зачем делать коммит, если ты только что обосрался?
>другого человека на проект позвать
Чтобы он свои грязные ручонки в мой идеальный, красивый, любимый код совал? NO WAY!
>>5999
Зачем мне в истории проекта все обновления .blend весом несколько десятков мегабайт? Если нужны промежуточные версии .blend, я сохраню их отдельно от файлов/бэкапов/гита проекта.
>историю проекта как-то хранить
Зачем мне в истории проекта все обновления .blend весом несколько десятков мегабайт? Если нужны промежуточные версии .blend, я сохраню их отдельно от файлов/бэкапов/гита проекта.
>>6003
Ну так не лей в главную ветку свои промежуточные изменения, делай мерж с модельками сквошем (хотя это фича ГИТХАБА а не ГИТа, что важно) и удаляй ветку где ты перебирал варианты модельки.
Это порой можно понять только на тестах других людей 10 коммитов спустя.
Работал в геймдеве на нескольких кабанов в команде, имею опыт именно коллективной разработки больше чем у многих тут. При этом 99% времени в гите использую 3,5 кнопки, лишь в 1% требуется открыть консоль и выебнуться, и то исключительно из-за обсера коллектива.
В гите нет нихуя сложного и страшного. Хватит людей пугать, о ужас, десятком мегабайт в истории.
>Зачем мне в истории проекта все обновления .blend весом несколько десятков мегабайт?
Ну так не лей в главную ветку свои промежуточные изменения, делай мерж с модельками сквошем (хотя это фича ГИТХАБА а не ГИТа, что важно) и удаляй ветку где ты перебирал варианты модельки.
>Зачем делать коммит, если ты только что обосрался?
Это порой можно понять только на тестах других людей 10 коммитов спустя.
Работал в геймдеве на нескольких кабанов в команде, имею опыт именно коллективной разработки больше чем у многих тут. При этом 99% времени в гите использую 3,5 кнопки, лишь в 1% требуется открыть консоль и выебнуться, и то исключительно из-за обсера коллектива.
В гите нет нихуя сложного и страшного. Хватит людей пугать, о ужас, десятком мегабайт в истории.
896 Кб, 600x585Годаны у меня от гита стул взорвался, прямо подо мной. Вот пруф, я не троль.
>>6007
Я не пытаюсь никого напугать. Если убедишь, что гит жизненно необходим любому хелло ворлду, тогда я и сам буду его использовать. Пока что не убедил.
Ещё раз, зачем коммитить модельки в репозиторий? Неоднократно видел опенсурс игры, где пакет ресурсов находится где-то отдельно от скриптов.
Тогда это уже проблема специфического железа, а не конкретной игры. Или какой-то скрытый баг, который большинство игроков никогда не встретит. Пока это не влияет на всех и сразу, это, считай, не баг. Иначе ПО вообще никогда бы не релизили...
У меня это будет 1.5 недели работы. Мне что, 1.5 недели удалить ради поиска бага, который никто кроме одного игрока не нашёл? Как я за 1.5 недели сам не заметил баг, а другой игрок нашёл, требуя откат всей моей работы почти на две недели?
Покажи на примере, где гит полезен и затраты на его поддержку окупаются - т.е. лишняя работа сейчас компенсируется автоматизацией в будущем.
Вот представим, я перепутал значение переменной и персонаж в игре улетает в небо с одного тычка, как мне гит поможет? Мне для исправления проблемы достаточно одну переменную поменять, зачем мне откатывать все файлы проекта, в которых могли быть сотни изменений после этой переменной? А главное, если я не знаю причину проблемы, как мне поможет откат всего проекта найти эту причину?
>Хватит людей пугать
Я не пытаюсь никого напугать. Если убедишь, что гит жизненно необходим любому хелло ворлду, тогда я и сам буду его использовать. Пока что не убедил.
>делай мерж с модельками сквошем
>ветку где ты перебирал варианты модельки
Ещё раз, зачем коммитить модельки в репозиторий? Неоднократно видел опенсурс игры, где пакет ресурсов находится где-то отдельно от скриптов.
>понять только на тестах других людей
Тогда это уже проблема специфического железа, а не конкретной игры. Или какой-то скрытый баг, который большинство игроков никогда не встретит. Пока это не влияет на всех и сразу, это, считай, не баг. Иначе ПО вообще никогда бы не релизили...
>10 коммитов спустя
У меня это будет 1.5 недели работы. Мне что, 1.5 недели удалить ради поиска бага, который никто кроме одного игрока не нашёл? Как я за 1.5 недели сам не заметил баг, а другой игрок нашёл, требуя откат всей моей работы почти на две недели?
Покажи на примере, где гит полезен и затраты на его поддержку окупаются - т.е. лишняя работа сейчас компенсируется автоматизацией в будущем.
Вот представим, я перепутал значение переменной и персонаж в игре улетает в небо с одного тычка, как мне гит поможет? Мне для исправления проблемы достаточно одну переменную поменять, зачем мне откатывать все файлы проекта, в которых могли быть сотни изменений после этой переменной? А главное, если я не знаю причину проблемы, как мне поможет откат всего проекта найти эту причину?
>>6021
Наркоман. Тебе другое предлагается.
Нужно просто сделать чекаут на несколько коммитов вглубь и посмотреть где именно жопа отваливается, на каком коммите именно. Моментально локализуешь проблему до небольшого коммита и сможешь её исправить уже путем исключения из того кода что ты писал.
При том не надо сидеть пердеть и думать чтож там такое могло сломаться, это 100% рабочий способ исправлять любое сложное говно, который нужен в арсенале любого разраба.
Разумеется, большую часть времени баги очевидны и это делать не нужно. Но этот метод на случай когда тебе грозит 3-4 часа дебага туманного говна.
>Мне что, 1.5 недели удалить ради поиска бага
Наркоман. Тебе другое предлагается.
Нужно просто сделать чекаут на несколько коммитов вглубь и посмотреть где именно жопа отваливается, на каком коммите именно. Моментально локализуешь проблему до небольшого коммита и сможешь её исправить уже путем исключения из того кода что ты писал.
При том не надо сидеть пердеть и думать чтож там такое могло сломаться, это 100% рабочий способ исправлять любое сложное говно, который нужен в арсенале любого разраба.
Разумеется, большую часть времени баги очевидны и это делать не нужно. Но этот метод на случай когда тебе грозит 3-4 часа дебага туманного говна.
>>6021
Запросто если ты делаешь проект сложнее чем симулятор унитаза или визуальной новеллы про Семена в гулаге. Чем больше проект, тем больше такой хуйни лезет.
>Как я за 1.5 недели сам не заметил баг, а другой игрок нашёл, требуя откат всей моей работы почти на две недели?
Запросто если ты делаешь проект сложнее чем симулятор унитаза или визуальной новеллы про Семена в гулаге. Чем больше проект, тем больше такой хуйни лезет.
226 Кб, 720x720А еще гит это просто хороший способ самодокументации проекта, строчка в резюме которая позволит найти работу в случае чего. А так же нативное понимание того как работать в сообществе разработчиков, что они делают, как они делают, и почему опенсурс очень часто кормит тебя говном с лопаты.
Не знать гита и быть программистом это все равно что не знать английского и быть программистом. Жить можно, но нахуй так жить?
Не знать гита и быть программистом это все равно что не знать английского и быть программистом. Жить можно, но нахуй так жить?
>>6018
Проиграл с тебя
мимо-QA
Поможет если делаешь часто небольшие коммиты, а не всё сразу раз в месяц.
>Пока это не влияет на всех и сразу, это, считай, не баг.
Проиграл с тебя
мимо-QA
>зачем мне откатывать все файлы проекта, в которых могли быть сотни изменений после этой переменной? А главное, если я не знаю причину проблемы, как мне поможет откат всего проекта найти эту причину?
Поможет если делаешь часто небольшие коммиты, а не всё сразу раз в месяц.
>>6036
К сожалению да, это зафоршенная херота которую необходимо знать. Как маркдаун или cmake, притом что они крайне неудачные инструменты, но слишком популярные.
>>6007
Гит работает хорошо, пока не косячнет или ты не косячнешь. А потом начинается не то что пугать, а натральный хоррор. Иногда проще было скопировать папку, руками сделать дифф всех файлов, и сделать новый коммит с готовых файлов.
К сожалению да, это зафоршенная херота которую необходимо знать. Как маркдаун или cmake, притом что они крайне неудачные инструменты, но слишком популярные.
>>6007
>Хватит людей пугать
Гит работает хорошо, пока не косячнет или ты не косячнешь. А потом начинается не то что пугать, а натральный хоррор. Иногда проще было скопировать папку, руками сделать дифф всех файлов, и сделать новый коммит с готовых файлов.
>>6211
Нет ты.
Нет ты.
Оставлю этот артефакт здесь.
Можно ходить. Можно тыкать на объекты на кнопку E, сидеть на стуле. Можно разговаривать с персонажами и даже включить телевизор.
https://www.mediafire.com/file/24n6nxc6i24yf0r/WatermelonBarGame.zip/file
А вот тут исходники проекта в Годоте
https://www.mediafire.com/file/m7jb5i5043deewe/WatermelonBar.zip/file
Что б пост был не бесполезным, поделюсь проблемами, которые возникли с моим первым проектом на Годот.
1.На Леново Х230 разъёбывает скелеты персонажей.
Очень долго ходил вокруг этой проблемы. Пытался делать свой скелет в ручную, качал чужие с Миксамо. А оказалось что просто запускаешь проект на нормальном компе и там всё работает!
А вот на древней встройке нихуя. Не используйте скелеты на древних встройках на Годоте.
2.Годот предлагает три рендера. Для калькуляторов, для телефонов и для людей.
На рендере для калькуляторов у меня нормально работает телевизор. Показывает и видео и звук.
На рендере Форвард+ звук есть, а вот видеотекстура на кубике нихуя не кажет!
3.Если на одной модели у тебя два объекта и у каждой анимация, то их не получается проиграть одновременно.
Пример. Стоит Двач-тян, у неё в руках кружка. Кружка отдельн о и Двач-тян отдельно. И обе этих анимации не запускались одновременно.
Способ простой - пришить кружку к руке намертво, сделав её частью тела персонажа.
Способ сложный - сделать второй аниматор и во второй аниматор скопировать анимацию из первого, а в первом удалить.
Можно ходить. Можно тыкать на объекты на кнопку E, сидеть на стуле. Можно разговаривать с персонажами и даже включить телевизор.
https://www.mediafire.com/file/24n6nxc6i24yf0r/WatermelonBarGame.zip/file
А вот тут исходники проекта в Годоте
https://www.mediafire.com/file/m7jb5i5043deewe/WatermelonBar.zip/file
Что б пост был не бесполезным, поделюсь проблемами, которые возникли с моим первым проектом на Годот.
1.На Леново Х230 разъёбывает скелеты персонажей.
Очень долго ходил вокруг этой проблемы. Пытался делать свой скелет в ручную, качал чужие с Миксамо. А оказалось что просто запускаешь проект на нормальном компе и там всё работает!
А вот на древней встройке нихуя. Не используйте скелеты на древних встройках на Годоте.
2.Годот предлагает три рендера. Для калькуляторов, для телефонов и для людей.
На рендере для калькуляторов у меня нормально работает телевизор. Показывает и видео и звук.
На рендере Форвард+ звук есть, а вот видеотекстура на кубике нихуя не кажет!
3.Если на одной модели у тебя два объекта и у каждой анимация, то их не получается проиграть одновременно.
Пример. Стоит Двач-тян, у неё в руках кружка. Кружка отдельн о и Двач-тян отдельно. И обе этих анимации не запускались одновременно.
Способ простой - пришить кружку к руке намертво, сделав её частью тела персонажа.
Способ сложный - сделать второй аниматор и во второй аниматор скопировать анимацию из первого, а в первом удалить.
Как можно реализовать настраиваемое управление?
Я пока что придумал сделать ноду которая забирает весь инпут и посылает сигналы в игру.
Нажимаешь кнопку, эта нода смотрит на какое действие ты забиндил эту кнопку - например, нажимаешь W - идет сигнал ноде игрока чтобы подвинулась вперед немного.
Как идея?
Я пока что придумал сделать ноду которая забирает весь инпут и посылает сигналы в игру.
Нажимаешь кнопку, эта нода смотрит на какое действие ты забиндил эту кнопку - например, нажимаешь W - идет сигнал ноде игрока чтобы подвинулась вперед немного.
Как идея?
>>6216
Там сейчас вроде слой совместимости с говном мамонта пилят.
Модельки сам делал? В блендере? Не заебался столько моделить ради двачедемки? А вообще молодца.
>А вот на древней встройке нихуя. Не используйте скелеты на древних встройках на Годоте.
Там сейчас вроде слой совместимости с говном мамонта пилят.
Модельки сам делал? В блендере? Не заебался столько моделить ради двачедемки? А вообще молодца.
259 Кб, 1708x1019>>6234
Да, все модельки делал сам, в блендере.
Кроме Чёрного Властелина и Двач-тян. Они были сгенерированы в Мейк Хюман.
Выбрал его как бесплатную свободную замену Метахьюману. Ну и, за бесплатно результат очевиден. Мейк Хьюману до Метахьюмана как до луны пешком.
>Модельки сам делал?
Да, все модельки делал сам, в блендере.
Кроме Чёрного Властелина и Двач-тян. Они были сгенерированы в Мейк Хюман.
Выбрал его как бесплатную свободную замену Метахьюману. Ну и, за бесплатно результат очевиден. Мейк Хьюману до Метахьюмана как до луны пешком.
>>5994
То, что я не хочу сохранять ЭТИ изменения. Я хочу их откатить взад. А они уже сохранились. Тащемта, я обычно сохраняюсь чуть ли не после каждого напечатанного слова. Но если что-то сделано случайно, так хотя бы не сохранять.
>А что такого в сохранении?
То, что я не хочу сохранять ЭТИ изменения. Я хочу их откатить взад. А они уже сохранились. Тащемта, я обычно сохраняюсь чуть ли не после каждого напечатанного слова. Но если что-то сделано случайно, так хотя бы не сохранять.
365 Кб, 685x692>>6462
Сейчас прямо что ли?
Сейчас прямо что ли?
>>6464
Экран тряс. С помощью твинеров (младших братьев твинов).
Экран тряс. С помощью твинеров (младших братьев твинов).
>>6462
Сегодня досматриваю сериал, потом запланировал просмотр трилогии одной, так что вряд ли получится раздуплиться, может завтра.
Сегодня досматриваю сериал, потом запланировал просмотр трилогии одной, так что вряд ли получится раздуплиться, может завтра.
>>6218
Сначала читаем доки, если что непонятно, смотрим туториалы, а потом повторно читаем доки. И вот если после этого непонятно, тогда есть смысл вопрошать на форумах.
Сначала читаем доки, если что непонятно, смотрим туториалы, а потом повторно читаем доки. И вот если после этого непонятно, тогда есть смысл вопрошать на форумах.
>>6311
Ну хз, в плане готовыг лицевых анимаций, наверное да. А в целом, вполне сносно моделирует, как по мне.
> Мейк Хьюману до Метахьюмана как до луны пешком
Ну хз, в плане готовыг лицевых анимаций, наверное да. А в целом, вполне сносно моделирует, как по мне.
>>6521
Еще можно ассеты чекнуть. Штуки 2-3 с настройками кнопок игроком точно было. Хотя красивого не попадалось.
Еще можно ассеты чекнуть. Штуки 2-3 с настройками кнопок игроком точно было. Хотя красивого не попадалось.
Геймдев - идеальный манямирочный эскапизм. Еще и денег на пивас поднять можно. Хоспаде, спасибо Хуану за Годотю.
>>6522
Шрек какой-то....
Шрек какой-то....
Fyjyfcs, здесь есть кто-нибудь, кто работает в какой-нибудь студии, где гадот используют? Можете рассказать как всё у вас там происходит?
Помогите с сменой сцен. С офф документации взял код (пик 1) и через синглтон сделал менеджер сцен, все нормально работает, сцены переключает как надо.
НО у меня есть другой синглтон - менеджер диалогов (пик 2). И когда я посмотрю диалог и после этого меняю сцену например выхожу через дверь, то менеджер сцен удаляет последнюю сцену (диалог - которая итак уже удалена), а не ту что должен по идеи и все идет по пизде, на пик 1 обозначена проблемная строка, но как переделать я не знаю.
Можно поправить логику в той строчке или надо все переделывать и объединять синглтоны?
НО у меня есть другой синглтон - менеджер диалогов (пик 2). И когда я посмотрю диалог и после этого меняю сцену например выхожу через дверь, то менеджер сцен удаляет последнюю сцену (диалог - которая итак уже удалена), а не ту что должен по идеи и все идет по пизде, на пик 1 обозначена проблемная строка, но как переделать я не знаю.
Можно поправить логику в той строчке или надо все переделывать и объединять синглтоны?
>>6765
Так же, как и в других студиях.
Так же, как и в других студиях.
>>6766
вроде как ты работаешь через индексы дочерних нод в этой строчке, лучше пока разбираешься так не делай, а присвой ноде с "картами" или что там меняется имя и она будет дочкой рута, потом сделай ноду для диалогов и ее тоже сделай дочкой рута
потом просто у ноды карты будешь удалять все старой и загружать в нее все новое и делать это по ее имени или ссылке
вроде как ты работаешь через индексы дочерних нод в этой строчке, лучше пока разбираешься так не делай, а присвой ноде с "картами" или что там меняется имя и она будет дочкой рута, потом сделай ноду для диалогов и ее тоже сделай дочкой рута
потом просто у ноды карты будешь удалять все старой и загружать в нее все новое и делать это по ее имени или ссылке
>>6765
да, в ней
вопрос не понял
но у нас не только годот, есть даже юнька на старых проктах еще поддерживаем на ней, но новые уже не начинаем, дефолд тыкаем, какие-то свои либы пишем, а так основное сейчас годо
да, в ней
вопрос не понял
но у нас не только годот, есть даже юнька на старых проктах еще поддерживаем на ней, но новые уже не начинаем, дефолд тыкаем, какие-то свои либы пишем, а так основное сейчас годо
>>6803
У тебя какая-то зарубежная компания или рф? Я просто думал пойти в геймдев на годоте, но хз что с вакансиями на нём
У тебя какая-то зарубежная компания или рф? Я просто думал пойти в геймдев на годоте, но хз что с вакансиями на нём
>>6766
1. Прекращай писать транслитом, бесит. Если ты не знаешь каких-то слов, юзай словарь - прокачаешь инглиш заодно, он очень важен в айти и геймдеве.
2. Прекращай писать "if something == true:", я тебе уже объяснял, что это избыточно. Код должен читаться естественно, т.е. следующие записи идентичны:
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), делая снизу вверх (от конкретных игровых объектов) только запросы (сигналы), чем накручивать клубок глобальной лапши, в котором вы быстро запутаетесь.
Глобальные сущности выглядят привлекательно только в самом начале. Потом начинается жесть.
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), делая снизу вверх (от конкретных игровых объектов) только запросы (сигналы), чем накручивать клубок глобальной лапши, в котором вы быстро запутаетесь.
Глобальные сущности выглядят привлекательно только в самом начале. Потом начинается жесть.
>>6820
В годоте нет синглтонов. Каждая нода-автозагрузка с глобальным именем - это по сути ветка в дереве. Поэтому вышеописанный тобой совет реализуется через get_tree() или как вариант через get_node("/"), которое возвращает то же самое (get_root() аналогично get_node("/root")). Достаточно взглянуть на удалённо приаттаченное дерево при выполнении проекта, чтобы всё это увидеть и осознать. Поэтому "синглтоны" автозагрузки, это просто удобный способ добавить чайлды в "/root". Как ни крути, проект сложнее тетриса, будет обладать специфическими объектами в дереве. Обращаться к ним через имена в автозагрузках, или через главную сцену, как ты предлагаешь "/root/main_scene" - однохуйственно. Разницы нет. Истинная инкапсуляция делается через сигналы. Тольк так менеджеры сцен (локаций, я полагаю) и менеджеры диалогов будут независимы и не вызовут ошибок при выгрузке друг друга.
>>6766
В целом тебе следует ещё раз крепко подумать об архитектуре своего проекта. Я тебе образно опишу, а реализацию гугли сам.
1. Сцены - это семантика движка. Тебе не обязательно придерживаться аналогичной семантики в своей игре. Проще говоря, у тебя может вовсе не быть никаких сцен. И в коде ты это можешь отразить, не называя сценами всё подряд.
2. В исполняющемся проекте есть только одна сцена, которая описана деревом сцены. Scene tree - единственное число, когда в русской документации его переводят "дерево сцен" - это ошибка перевода. Дерево сцен по английски называлось бы scenes tree.
3. Как подсказал анон выше, ты можешь реализовать всю связующую логику в корневом узле дерева, но это ничем не будет отличаться от синглтонов из автозагрузки, просто а) всё сместится на один уровень вниз по дереву сцены (ед.ч.), б) имена переменных, в которые ты загрузишь чайлды самодельного корневого узла, ты будешь описывать сам в скрипте, а не во вкладке автозагрузок редактора.
4. Поскольку п.3. объясняет, что оба варианта однохуйственны, рассмотри вариант реализации в своём проекте шины событий. Это архитектурный паттерн. Он гуглится. Шину событий тоже засовываем в дерево, любым из вариантов п.3. после чего все остальные скрипты не видят ничего кроме шины событий. Они могут подписываться на излучаемые шиной сигналы. Они могут заставлять излучать шину сигналы. Сигналы можно излучать с аргументами. Аргументы можно передавать ссылочными типами (например, словарём). Таким образом разные инкапсулированные в себе и скрытые друг от друга ноды через сигналы смогут обмениваться полноценной инфой, но при этом никак не вредить друг другу. Если нода выгрузилась, она просо не отреагирует на сигнал.
Щас попробую в общих чертах изобразить тебе скриншотами твой код, переписанный на шину событий.
> Повторюсь в который раз: лучше иметь главную сцену game.tscn и руководить всем сверху вниз (от главного скрипта game.gd), делая снизу вверх (от конкретных игровых объектов) только запросы (сигналы), чем накручивать клубок глобальной лапши, в котором вы быстро запутаетесь.
> Глобальные сущности выглядят привлекательно только в самом начале. Потом начинается жесть.
В годоте нет синглтонов. Каждая нода-автозагрузка с глобальным именем - это по сути ветка в дереве. Поэтому вышеописанный тобой совет реализуется через get_tree() или как вариант через get_node("/"), которое возвращает то же самое (get_root() аналогично get_node("/root")). Достаточно взглянуть на удалённо приаттаченное дерево при выполнении проекта, чтобы всё это увидеть и осознать. Поэтому "синглтоны" автозагрузки, это просто удобный способ добавить чайлды в "/root". Как ни крути, проект сложнее тетриса, будет обладать специфическими объектами в дереве. Обращаться к ним через имена в автозагрузках, или через главную сцену, как ты предлагаешь "/root/main_scene" - однохуйственно. Разницы нет. Истинная инкапсуляция делается через сигналы. Тольк так менеджеры сцен (локаций, я полагаю) и менеджеры диалогов будут независимы и не вызовут ошибок при выгрузке друг друга.
>>6766
В целом тебе следует ещё раз крепко подумать об архитектуре своего проекта. Я тебе образно опишу, а реализацию гугли сам.
1. Сцены - это семантика движка. Тебе не обязательно придерживаться аналогичной семантики в своей игре. Проще говоря, у тебя может вовсе не быть никаких сцен. И в коде ты это можешь отразить, не называя сценами всё подряд.
2. В исполняющемся проекте есть только одна сцена, которая описана деревом сцены. Scene tree - единственное число, когда в русской документации его переводят "дерево сцен" - это ошибка перевода. Дерево сцен по английски называлось бы scenes tree.
3. Как подсказал анон выше, ты можешь реализовать всю связующую логику в корневом узле дерева, но это ничем не будет отличаться от синглтонов из автозагрузки, просто а) всё сместится на один уровень вниз по дереву сцены (ед.ч.), б) имена переменных, в которые ты загрузишь чайлды самодельного корневого узла, ты будешь описывать сам в скрипте, а не во вкладке автозагрузок редактора.
4. Поскольку п.3. объясняет, что оба варианта однохуйственны, рассмотри вариант реализации в своём проекте шины событий. Это архитектурный паттерн. Он гуглится. Шину событий тоже засовываем в дерево, любым из вариантов п.3. после чего все остальные скрипты не видят ничего кроме шины событий. Они могут подписываться на излучаемые шиной сигналы. Они могут заставлять излучать шину сигналы. Сигналы можно излучать с аргументами. Аргументы можно передавать ссылочными типами (например, словарём). Таким образом разные инкапсулированные в себе и скрытые друг от друга ноды через сигналы смогут обмениваться полноценной инфой, но при этом никак не вредить друг другу. Если нода выгрузилась, она просо не отреагирует на сигнал.
Щас попробую в общих чертах изобразить тебе скриншотами твой код, переписанный на шину событий.
>>6820
В годоте нет синглтонов. Каждая нода-автозагрузка с глобальным именем - это по сути ветка в дереве. Поэтому вышеописанный тобой совет реализуется через get_tree() или как вариант через get_node("/"), которое возвращает то же самое (get_root() аналогично get_node("/root")). Достаточно взглянуть на удалённо приаттаченное дерево при выполнении проекта, чтобы всё это увидеть и осознать. Поэтому "синглтоны" автозагрузки, это просто удобный способ добавить чайлды в "/root". Как ни крути, проект сложнее тетриса, будет обладать специфическими объектами в дереве. Обращаться к ним через имена в автозагрузках, или через главную сцену, как ты предлагаешь "/root/main_scene" - однохуйственно. Разницы нет. Истинная инкапсуляция делается через сигналы. Тольк так менеджеры сцен (локаций, я полагаю) и менеджеры диалогов будут независимы и не вызовут ошибок при выгрузке друг друга.
>>6766
В целом тебе следует ещё раз крепко подумать об архитектуре своего проекта. Я тебе образно опишу, а реализацию гугли сам.
1. Сцены - это семантика движка. Тебе не обязательно придерживаться аналогичной семантики в своей игре. Проще говоря, у тебя может вовсе не быть никаких сцен. И в коде ты это можешь отразить, не называя сценами всё подряд.
2. В исполняющемся проекте есть только одна сцена, которая описана деревом сцены. Scene tree - единственное число, когда в русской документации его переводят "дерево сцен" - это ошибка перевода. Дерево сцен по английски называлось бы scenes tree.
3. Как подсказал анон выше, ты можешь реализовать всю связующую логику в корневом узле дерева, но это ничем не будет отличаться от синглтонов из автозагрузки, просто а) всё сместится на один уровень вниз по дереву сцены (ед.ч.), б) имена переменных, в которые ты загрузишь чайлды самодельного корневого узла, ты будешь описывать сам в скрипте, а не во вкладке автозагрузок редактора.
4. Поскольку п.3. объясняет, что оба варианта однохуйственны, рассмотри вариант реализации в своём проекте шины событий. Это архитектурный паттерн. Он гуглится. Шину событий тоже засовываем в дерево, любым из вариантов п.3. после чего все остальные скрипты не видят ничего кроме шины событий. Они могут подписываться на излучаемые шиной сигналы. Они могут заставлять излучать шину сигналы. Сигналы можно излучать с аргументами. Аргументы можно передавать ссылочными типами (например, словарём). Таким образом разные инкапсулированные в себе и скрытые друг от друга ноды через сигналы смогут обмениваться полноценной инфой, но при этом никак не вредить друг другу. Если нода выгрузилась, она просо не отреагирует на сигнал.
Щас попробую в общих чертах изобразить тебе скриншотами твой код, переписанный на шину событий.
> Повторюсь в который раз: лучше иметь главную сцену game.tscn и руководить всем сверху вниз (от главного скрипта game.gd), делая снизу вверх (от конкретных игровых объектов) только запросы (сигналы), чем накручивать клубок глобальной лапши, в котором вы быстро запутаетесь.
> Глобальные сущности выглядят привлекательно только в самом начале. Потом начинается жесть.
В годоте нет синглтонов. Каждая нода-автозагрузка с глобальным именем - это по сути ветка в дереве. Поэтому вышеописанный тобой совет реализуется через get_tree() или как вариант через get_node("/"), которое возвращает то же самое (get_root() аналогично get_node("/root")). Достаточно взглянуть на удалённо приаттаченное дерево при выполнении проекта, чтобы всё это увидеть и осознать. Поэтому "синглтоны" автозагрузки, это просто удобный способ добавить чайлды в "/root". Как ни крути, проект сложнее тетриса, будет обладать специфическими объектами в дереве. Обращаться к ним через имена в автозагрузках, или через главную сцену, как ты предлагаешь "/root/main_scene" - однохуйственно. Разницы нет. Истинная инкапсуляция делается через сигналы. Тольк так менеджеры сцен (локаций, я полагаю) и менеджеры диалогов будут независимы и не вызовут ошибок при выгрузке друг друга.
>>6766
В целом тебе следует ещё раз крепко подумать об архитектуре своего проекта. Я тебе образно опишу, а реализацию гугли сам.
1. Сцены - это семантика движка. Тебе не обязательно придерживаться аналогичной семантики в своей игре. Проще говоря, у тебя может вовсе не быть никаких сцен. И в коде ты это можешь отразить, не называя сценами всё подряд.
2. В исполняющемся проекте есть только одна сцена, которая описана деревом сцены. Scene tree - единственное число, когда в русской документации его переводят "дерево сцен" - это ошибка перевода. Дерево сцен по английски называлось бы scenes tree.
3. Как подсказал анон выше, ты можешь реализовать всю связующую логику в корневом узле дерева, но это ничем не будет отличаться от синглтонов из автозагрузки, просто а) всё сместится на один уровень вниз по дереву сцены (ед.ч.), б) имена переменных, в которые ты загрузишь чайлды самодельного корневого узла, ты будешь описывать сам в скрипте, а не во вкладке автозагрузок редактора.
4. Поскольку п.3. объясняет, что оба варианта однохуйственны, рассмотри вариант реализации в своём проекте шины событий. Это архитектурный паттерн. Он гуглится. Шину событий тоже засовываем в дерево, любым из вариантов п.3. после чего все остальные скрипты не видят ничего кроме шины событий. Они могут подписываться на излучаемые шиной сигналы. Они могут заставлять излучать шину сигналы. Сигналы можно излучать с аргументами. Аргументы можно передавать ссылочными типами (например, словарём). Таким образом разные инкапсулированные в себе и скрытые друг от друга ноды через сигналы смогут обмениваться полноценной инфой, но при этом никак не вредить друг другу. Если нода выгрузилась, она просо не отреагирует на сигнал.
Щас попробую в общих чертах изобразить тебе скриншотами твой код, переписанный на шину событий.
>>6820
Я другой анон, но блять.
Раздражает подобное написание. Читается плохо, глаз не сразу улавливает суть ифа. Хотя булевские таки да, сравнивать с труъ избыточно, но это экономия на спичках.
Больше этого меня раздражает разве что "if !something". Три знака экономия, зато потенциальное место для ошибки по слепошарости.
Сразу нахуй. Стена кода без комментов - это нечитаемое говно. Да, код писать надо сразу такой, чтобы его сходу можно было понять без комментариев. Но писать их, тем не менее, всё равно необходимо, чтобы улучшить читаемость.
А, ты из этих.
Я другой анон, но блять.
>Прекращай писать "if something == true:"
Раздражает подобное написание. Читается плохо, глаз не сразу улавливает суть ифа. Хотя булевские таки да, сравнивать с труъ избыточно, но это экономия на спичках.
Больше этого меня раздражает разве что "if !something". Три знака экономия, зато потенциальное место для ошибки по слепошарости.
>Привыкай писать код без комментариев.
Сразу нахуй. Стена кода без комментов - это нечитаемое говно. Да, код писать надо сразу такой, чтобы его сходу можно было понять без комментариев. Но писать их, тем не менее, всё равно необходимо, чтобы улучшить читаемость.
>Синглтоны вообще рекомендую не использовать
А, ты из этих.
>>6834
Вот иллюстрация, о чём я надлиннопостил.
Вот иллюстрация, о чём я надлиннопостил.
>>6839
А потом ты начинаешь эмиттить сигналы по необходимости:
А потом ты начинаешь эмиттить сигналы по необходимости:
>>6836
В одном месте прочитал хороший совет - коммент должен быть про то, зачем делают, а не какие действия делают.
Иначе комент становится дублем кода
Плохой пример
scene.instance() #инстанцируем сцену - кэп!
Хороший пример
scene.instance() #спавним пулю
В идеале меняем на то, чтобы коменты были не нужны
bulletscene.instance()
Но тут уже могут быть коменты именно о том почему это делается здесь
bulletscene.instance() #нам нужна эта сцена чтобы потом вычислить вектор для прицела
> Стена кода без комментов
В одном месте прочитал хороший совет - коммент должен быть про то, зачем делают, а не какие действия делают.
Иначе комент становится дублем кода
Плохой пример
scene.instance() #инстанцируем сцену - кэп!
Хороший пример
scene.instance() #спавним пулю
В идеале меняем на то, чтобы коменты были не нужны
bulletscene.instance()
Но тут уже могут быть коменты именно о том почему это делается здесь
bulletscene.instance() #нам нужна эта сцена чтобы потом вычислить вектор для прицела
>>6847
Я сегодня сделал три нормы за смену. А теперь я пойду спать.
Я сегодня сделал три нормы за смену. А теперь я пойду спать.
>>6836
Что тебе плохо читается? Слова английского языка? Тогда на русском пиши, Godot поддерживает Unicode.
Дело не в экономии, а в том, что "== true" почём зря цепляет взгляд, затрудняя чтение/понимание кода.
Это от сишников, они любят спецсимволы вместо читабельных слов. Благо, в GDScript есть слово not.
НЕ ПИШИ НЕЧИТАЕМУЮ СТЕНУ КОДА
@
НЕ ПРИДЁТСЯ ПИСАТЬ СТЕНУ КОММЕНТАРИЕВ
Если ты хочешь написать комментарий - знай, твой код нечитаемое говно, которое нужно переписать. Не всегда, конечно, но чаще всего так и получается.
Любишь обмазаться глобальными переменными и дрочить на извилистую лапшу в портянках кода?
>>6834
Да. Но синглтоны вредны потому, что они глобальны по своей природе. Автозагрузка в Godot как раз даёт возможность сделать глобальную лапшу.
Которая провоцирует создание лапши в проекте.
Бред какой-то. Не стоит обращаться к вышестоящим системам по имени, это даже в доках замечено. В крайнем случае можешь запрашивать get_parent(), но только один раз - никаких дедов и прадедов.
Зачем? З А Ч Е М? Выглядит как древний костыль.
Я как-то тетрис писал. С глобальными переменными. Забросил, когда осознал, что не могу понять, как оно работает, из-за той туго затянутой глобальной лапши.
Повторяю, не нужно этого делать.
Я этого не предлагал. Обращаться к главной сцене не нужно, потому что она главная. Директора своей компании ты не отвлекаешь от его работы своими бестолковыми приказами, а пишешь письмо, которое передаётся через несколько ступеней иерархии, возможно, теряясь в процессе, потому что ты всего лишь заменимая шестерёнка в системе.
В частности, дверь в игре не должна вызывать переключение сцен. Она должна сообщать наверх о том, что требуется переключение сцен. Произойдёт ли переключение сцен или нет её волновать не должно. Аналогично менеджер диалогов не должен тянуть шаловливые ручонки туда, куда ему не положено, а его, в свою очередь, не должны тянуть за руки NPC.
Новички этого не понимают, а автозагрузка с её глобальными именами наставляет их на ложный путь с кучей граблей и огромным лапшичным монстром. Вообще, get_node() тоже позволяет слишком многое, но это хотя бы "секретная" фича, а не пункт в меню.
А вот это делать не надо. Но даже если так делать, ты явным образом связываешь свои скрипты, не пряча зависимости куда-то в настройки проекта.
Имхо, это избыточно.
То, что я предлагаю:
1. Предки манипулируют только своими потомками.
2. Потомки только излучают сигналы.
3. Никаких манипуляций с:
3.1. Предками, предками предков и т.д.
3.2. Братьями, дядями, племянниками и т.д.
3.3. Внуками, правнуками и т.д.
В редких случаях можно обращаться к своему родителю напрямую, но это особый случай, который необходимо как-то обозначать, например, нода должна проверять тип родителя и выдавать ошибку в случае, если дизайнер поместил её не туда.
>Читается плохо, глаз не сразу улавливает суть
Что тебе плохо читается? Слова английского языка? Тогда на русском пиши, Godot поддерживает Unicode.
>экономия на спичках
Дело не в экономии, а в том, что "== true" почём зря цепляет взгляд, затрудняя чтение/понимание кода.
>if !something
Это от сишников, они любят спецсимволы вместо читабельных слов. Благо, в GDScript есть слово not.
>Стена кода без комментов
>необходимо, чтобы улучшить читаемость
НЕ ПИШИ НЕЧИТАЕМУЮ СТЕНУ КОДА
@
НЕ ПРИДЁТСЯ ПИСАТЬ СТЕНУ КОММЕНТАРИЕВ
Если ты хочешь написать комментарий - знай, твой код нечитаемое говно, которое нужно переписать. Не всегда, конечно, но чаще всего так и получается.
>А, ты из этих.
Любишь обмазаться глобальными переменными и дрочить на извилистую лапшу в портянках кода?
>>6834
>В годоте нет синглтонов.
Да. Но синглтоны вредны потому, что они глобальны по своей природе. Автозагрузка в 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. Внуками, правнуками и т.д.
В редких случаях можно обращаться к своему родителю напрямую, но это особый случай, который необходимо как-то обозначать, например, нода должна проверять тип родителя и выдавать ошибку в случае, если дизайнер поместил её не туда.
>>6836
Что тебе плохо читается? Слова английского языка? Тогда на русском пиши, Godot поддерживает Unicode.
Дело не в экономии, а в том, что "== true" почём зря цепляет взгляд, затрудняя чтение/понимание кода.
Это от сишников, они любят спецсимволы вместо читабельных слов. Благо, в GDScript есть слово not.
НЕ ПИШИ НЕЧИТАЕМУЮ СТЕНУ КОДА
@
НЕ ПРИДЁТСЯ ПИСАТЬ СТЕНУ КОММЕНТАРИЕВ
Если ты хочешь написать комментарий - знай, твой код нечитаемое говно, которое нужно переписать. Не всегда, конечно, но чаще всего так и получается.
Любишь обмазаться глобальными переменными и дрочить на извилистую лапшу в портянках кода?
>>6834
Да. Но синглтоны вредны потому, что они глобальны по своей природе. Автозагрузка в Godot как раз даёт возможность сделать глобальную лапшу.
Которая провоцирует создание лапши в проекте.
Бред какой-то. Не стоит обращаться к вышестоящим системам по имени, это даже в доках замечено. В крайнем случае можешь запрашивать get_parent(), но только один раз - никаких дедов и прадедов.
Зачем? З А Ч Е М? Выглядит как древний костыль.
Я как-то тетрис писал. С глобальными переменными. Забросил, когда осознал, что не могу понять, как оно работает, из-за той туго затянутой глобальной лапши.
Повторяю, не нужно этого делать.
Я этого не предлагал. Обращаться к главной сцене не нужно, потому что она главная. Директора своей компании ты не отвлекаешь от его работы своими бестолковыми приказами, а пишешь письмо, которое передаётся через несколько ступеней иерархии, возможно, теряясь в процессе, потому что ты всего лишь заменимая шестерёнка в системе.
В частности, дверь в игре не должна вызывать переключение сцен. Она должна сообщать наверх о том, что требуется переключение сцен. Произойдёт ли переключение сцен или нет её волновать не должно. Аналогично менеджер диалогов не должен тянуть шаловливые ручонки туда, куда ему не положено, а его, в свою очередь, не должны тянуть за руки NPC.
Новички этого не понимают, а автозагрузка с её глобальными именами наставляет их на ложный путь с кучей граблей и огромным лапшичным монстром. Вообще, get_node() тоже позволяет слишком многое, но это хотя бы "секретная" фича, а не пункт в меню.
А вот это делать не надо. Но даже если так делать, ты явным образом связываешь свои скрипты, не пряча зависимости куда-то в настройки проекта.
Имхо, это избыточно.
То, что я предлагаю:
1. Предки манипулируют только своими потомками.
2. Потомки только излучают сигналы.
3. Никаких манипуляций с:
3.1. Предками, предками предков и т.д.
3.2. Братьями, дядями, племянниками и т.д.
3.3. Внуками, правнуками и т.д.
В редких случаях можно обращаться к своему родителю напрямую, но это особый случай, который необходимо как-то обозначать, например, нода должна проверять тип родителя и выдавать ошибку в случае, если дизайнер поместил её не туда.
>Читается плохо, глаз не сразу улавливает суть
Что тебе плохо читается? Слова английского языка? Тогда на русском пиши, Godot поддерживает Unicode.
>экономия на спичках
Дело не в экономии, а в том, что "== true" почём зря цепляет взгляд, затрудняя чтение/понимание кода.
>if !something
Это от сишников, они любят спецсимволы вместо читабельных слов. Благо, в GDScript есть слово not.
>Стена кода без комментов
>необходимо, чтобы улучшить читаемость
НЕ ПИШИ НЕЧИТАЕМУЮ СТЕНУ КОДА
@
НЕ ПРИДЁТСЯ ПИСАТЬ СТЕНУ КОММЕНТАРИЕВ
Если ты хочешь написать комментарий - знай, твой код нечитаемое говно, которое нужно переписать. Не всегда, конечно, но чаще всего так и получается.
>А, ты из этих.
Любишь обмазаться глобальными переменными и дрочить на извилистую лапшу в портянках кода?
>>6834
>В годоте нет синглтонов.
Да. Но синглтоны вредны потому, что они глобальны по своей природе. Автозагрузка в 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. Внуками, правнуками и т.д.
В редких случаях можно обращаться к своему родителю напрямую, но это особый случай, который необходимо как-то обозначать, например, нода должна проверять тип родителя и выдавать ошибку в случае, если дизайнер поместил её не туда.
а могли бы игры делать
>>6854
Самое смешное что в С++ в стандарте тоже есть not, and
https://en.cppreference.com/w/cpp/language/operator_alternative
Некоторые очень смешно подрываются, если им показать что такой код валиден на с++
Самое смешное что в С++ в стандарте тоже есть not, and
https://en.cppreference.com/w/cpp/language/operator_alternative
Некоторые очень смешно подрываются, если им показать что такой код валиден на с++
>>6854
Да ты даже пост на дваче прочитать не можешь, вот и на комменты не залупайся. Эти два утверждения не противоречат друг другу, но дополняют:
1. Код надо писать такой, чтобы его было легко понять без комментов.
2. Разбавлять стену кода комментами необходимо для читаемости.
Речь не про то, что я пишу код, который непонятный без комментариев. Он понятный. Речь про то, что я оформляю код при помощи комментов, делаю его визуально чище, логичнее на уровне расположения элементов. Комменты в таком отношении это скорее заголовки, а код - контент.
Нет. При == true я вижу явную операцию сравнения; без этого - ну там переменная; да, она своим именем отражает смысл, но я один хуй не воспринимаю код как естественный язык, так что не вижу смысла в этих потугах.
И да, для меня как раз отсутствие "== true" затрудняет чтение/понимание, а не наоборот. По крайней мере, когда чужой код читаю.
>>6854
А ты не делай глобальную лапшу. Видишь, я тоже умею в такую аргументацию.
Нет, серьёзно. Что мешает использовать синглтоны по назначению? Как:
1. Словарь глобальных констант,
2. Класс вспомогательных функций, которые могут понадобиться в любом месте кода,
3. Шину взаимодействия, например, между игровыми объектами и гуём,
4. Постоянно висящий в памяти менеджер чего-либо, например, музыки.
Не, ну тут база, конечно.
>Если ты хочешь написать комментарий - знай, твой код нечитаемое говно
Да ты даже пост на дваче прочитать не можешь, вот и на комменты не залупайся. Эти два утверждения не противоречат друг другу, но дополняют:
1. Код надо писать такой, чтобы его было легко понять без комментов.
2. Разбавлять стену кода комментами необходимо для читаемости.
Речь не про то, что я пишу код, который непонятный без комментариев. Он понятный. Речь про то, что я оформляю код при помощи комментов, делаю его визуально чище, логичнее на уровне расположения элементов. Комменты в таком отношении это скорее заголовки, а код - контент.
>"== true" почём зря цепляет взгляд
Нет. При == true я вижу явную операцию сравнения; без этого - ну там переменная; да, она своим именем отражает смысл, но я один хуй не воспринимаю код как естественный язык, так что не вижу смысла в этих потугах.
И да, для меня как раз отсутствие "== true" затрудняет чтение/понимание, а не наоборот. По крайней мере, когда чужой код читаю.
>>6854
>Автозагрузка в Godot как раз даёт возможность сделать глобальную лапшу
А ты не делай глобальную лапшу. Видишь, я тоже умею в такую аргументацию.
Нет, серьёзно. Что мешает использовать синглтоны по назначению? Как:
1. Словарь глобальных констант,
2. Класс вспомогательных функций, которые могут понадобиться в любом месте кода,
3. Шину взаимодействия, например, между игровыми объектами и гуём,
4. Постоянно висящий в памяти менеджер чего-либо, например, музыки.
>То, что я предлагаю:
Не, ну тут база, конечно.
>>6839 >>6841
Думал, ты предлагал реализовать аналог InputEvent...
Твой подход ничем не лучше и не решает проблему.
1. У тебя глобальный объект. Ещё и божественный.
2. К которому обращаются из рандомных скриптов.
3. Который владеет тем, что ему не принадлежит.
И всё это снова ведёт к тугому клубку лапши:
https://ru.wikipedia.org/wiki/Спагетти-код
https://en.wikipedia.org/wiki/Spaghetti_code
Любую игру можно представить как иерархичное сообщество систем. Системы можно разделить по размерам: чем больше систем в подчинении у конкретной системы, тем она больше. Как можно догадаться, самая большая система - это сама игра, включающая в себя вообще всё, что в твоей игре реализовано. Самая маленькая система в Godot выражается одной нодой, например, Label: она не делает ничего, кроме вывода предоставленного ей текста. Средняя по размеру система - это, например, главное меню, в котором есть несколько разных надписей и кнопок, но оно находится в подчинении у системы бОльшего размера - главной системы - игры. Если представлять проект в таком виде, то будет легче избежать запутывания в лапше, т.к. независимые системы друг о друге гарантированно не знают.
Вот твоя игра запускается.
- Игра показывает заставку.
- - Заставка проигрывает анимацию.
- - Заставка сообщает Игре, что она закончила.
- Игра вызывает Главное меню.
- - Главное меню показывает Надпись.
- - - Надпись проигрывает анимацию текста.
- - Главное меню показывает Кнопки.
- - - Кнопки регистрируют движения мыши.
- - - Кнопки передают подсказки Главному меню.
- - Главное меню передает подсказки в Надпись.
- - - Надпись отображает полученный текст.
- - - Кнопка "начать игру" получает клик мышкой.
- - Главное меню сообщает Игре об этом.
- Игра скрывает Главное меню.
- - Главное меню убирает лишние элементы.
- - - Лишние элементы прибираются за собой.
- Игра загружает Менеджер мира.
- - Менеджер мира загружает Карту.
- - - Карта спавнит декорации.
и т.д.
Может показаться, что это слишком много лишней работы, но это даст преимущество в будущем, когда придётся искать ошибки, создавать новые фичи, следующий проект в той же серии игр или новый проект в том же или похожем жанре.
Скажем, можно будет взять главное меню и целиком перенести в новый проект, заменив только спрайты, ведь главное меню не суёт нос куда не следует, а только сообщает "нажата такая-то кнопка". А уже тот, кто вызвал главное меню, пускай разбирается, что ему делать с событием нажатия кнопки.
Думал, ты предлагал реализовать аналог InputEvent...
Твой подход ничем не лучше и не решает проблему.
1. У тебя глобальный объект. Ещё и божественный.
2. К которому обращаются из рандомных скриптов.
3. Который владеет тем, что ему не принадлежит.
И всё это снова ведёт к тугому клубку лапши:
https://ru.wikipedia.org/wiki/Спагетти-код
https://en.wikipedia.org/wiki/Spaghetti_code
Любую игру можно представить как иерархичное сообщество систем. Системы можно разделить по размерам: чем больше систем в подчинении у конкретной системы, тем она больше. Как можно догадаться, самая большая система - это сама игра, включающая в себя вообще всё, что в твоей игре реализовано. Самая маленькая система в Godot выражается одной нодой, например, Label: она не делает ничего, кроме вывода предоставленного ей текста. Средняя по размеру система - это, например, главное меню, в котором есть несколько разных надписей и кнопок, но оно находится в подчинении у системы бОльшего размера - главной системы - игры. Если представлять проект в таком виде, то будет легче избежать запутывания в лапше, т.к. независимые системы друг о друге гарантированно не знают.
Вот твоя игра запускается.
- Игра показывает заставку.
- - Заставка проигрывает анимацию.
- - Заставка сообщает Игре, что она закончила.
- Игра вызывает Главное меню.
- - Главное меню показывает Надпись.
- - - Надпись проигрывает анимацию текста.
- - Главное меню показывает Кнопки.
- - - Кнопки регистрируют движения мыши.
- - - Кнопки передают подсказки Главному меню.
- - Главное меню передает подсказки в Надпись.
- - - Надпись отображает полученный текст.
- - - Кнопка "начать игру" получает клик мышкой.
- - Главное меню сообщает Игре об этом.
- Игра скрывает Главное меню.
- - Главное меню убирает лишние элементы.
- - - Лишние элементы прибираются за собой.
- Игра загружает Менеджер мира.
- - Менеджер мира загружает Карту.
- - - Карта спавнит декорации.
и т.д.
Может показаться, что это слишком много лишней работы, но это даст преимущество в будущем, когда придётся искать ошибки, создавать новые фичи, следующий проект в той же серии игр или новый проект в том же или похожем жанре.
Скажем, можно будет взять главное меню и целиком перенести в новый проект, заменив только спрайты, ведь главное меню не суёт нос куда не следует, а только сообщает "нажата такая-то кнопка". А уже тот, кто вызвал главное меню, пускай разбирается, что ему делать с событием нажатия кнопки.
>>6839 >>6841
Думал, ты предлагал реализовать аналог InputEvent...
Твой подход ничем не лучше и не решает проблему.
1. У тебя глобальный объект. Ещё и божественный.
2. К которому обращаются из рандомных скриптов.
3. Который владеет тем, что ему не принадлежит.
И всё это снова ведёт к тугому клубку лапши:
https://ru.wikipedia.org/wiki/Спагетти-код
https://en.wikipedia.org/wiki/Spaghetti_code
Любую игру можно представить как иерархичное сообщество систем. Системы можно разделить по размерам: чем больше систем в подчинении у конкретной системы, тем она больше. Как можно догадаться, самая большая система - это сама игра, включающая в себя вообще всё, что в твоей игре реализовано. Самая маленькая система в Godot выражается одной нодой, например, Label: она не делает ничего, кроме вывода предоставленного ей текста. Средняя по размеру система - это, например, главное меню, в котором есть несколько разных надписей и кнопок, но оно находится в подчинении у системы бОльшего размера - главной системы - игры. Если представлять проект в таком виде, то будет легче избежать запутывания в лапше, т.к. независимые системы друг о друге гарантированно не знают.
Вот твоя игра запускается.
- Игра показывает заставку.
- - Заставка проигрывает анимацию.
- - Заставка сообщает Игре, что она закончила.
- Игра вызывает Главное меню.
- - Главное меню показывает Надпись.
- - - Надпись проигрывает анимацию текста.
- - Главное меню показывает Кнопки.
- - - Кнопки регистрируют движения мыши.
- - - Кнопки передают подсказки Главному меню.
- - Главное меню передает подсказки в Надпись.
- - - Надпись отображает полученный текст.
- - - Кнопка "начать игру" получает клик мышкой.
- - Главное меню сообщает Игре об этом.
- Игра скрывает Главное меню.
- - Главное меню убирает лишние элементы.
- - - Лишние элементы прибираются за собой.
- Игра загружает Менеджер мира.
- - Менеджер мира загружает Карту.
- - - Карта спавнит декорации.
и т.д.
Может показаться, что это слишком много лишней работы, но это даст преимущество в будущем, когда придётся искать ошибки, создавать новые фичи, следующий проект в той же серии игр или новый проект в том же или похожем жанре.
Скажем, можно будет взять главное меню и целиком перенести в новый проект, заменив только спрайты, ведь главное меню не суёт нос куда не следует, а только сообщает "нажата такая-то кнопка". А уже тот, кто вызвал главное меню, пускай разбирается, что ему делать с событием нажатия кнопки.
Думал, ты предлагал реализовать аналог InputEvent...
Твой подход ничем не лучше и не решает проблему.
1. У тебя глобальный объект. Ещё и божественный.
2. К которому обращаются из рандомных скриптов.
3. Который владеет тем, что ему не принадлежит.
И всё это снова ведёт к тугому клубку лапши:
https://ru.wikipedia.org/wiki/Спагетти-код
https://en.wikipedia.org/wiki/Spaghetti_code
Любую игру можно представить как иерархичное сообщество систем. Системы можно разделить по размерам: чем больше систем в подчинении у конкретной системы, тем она больше. Как можно догадаться, самая большая система - это сама игра, включающая в себя вообще всё, что в твоей игре реализовано. Самая маленькая система в Godot выражается одной нодой, например, Label: она не делает ничего, кроме вывода предоставленного ей текста. Средняя по размеру система - это, например, главное меню, в котором есть несколько разных надписей и кнопок, но оно находится в подчинении у системы бОльшего размера - главной системы - игры. Если представлять проект в таком виде, то будет легче избежать запутывания в лапше, т.к. независимые системы друг о друге гарантированно не знают.
Вот твоя игра запускается.
- Игра показывает заставку.
- - Заставка проигрывает анимацию.
- - Заставка сообщает Игре, что она закончила.
- Игра вызывает Главное меню.
- - Главное меню показывает Надпись.
- - - Надпись проигрывает анимацию текста.
- - Главное меню показывает Кнопки.
- - - Кнопки регистрируют движения мыши.
- - - Кнопки передают подсказки Главному меню.
- - Главное меню передает подсказки в Надпись.
- - - Надпись отображает полученный текст.
- - - Кнопка "начать игру" получает клик мышкой.
- - Главное меню сообщает Игре об этом.
- Игра скрывает Главное меню.
- - Главное меню убирает лишние элементы.
- - - Лишние элементы прибираются за собой.
- Игра загружает Менеджер мира.
- - Менеджер мира загружает Карту.
- - - Карта спавнит декорации.
и т.д.
Может показаться, что это слишком много лишней работы, но это даст преимущество в будущем, когда придётся искать ошибки, создавать новые фичи, следующий проект в той же серии игр или новый проект в том же или похожем жанре.
Скажем, можно будет взять главное меню и целиком перенести в новый проект, заменив только спрайты, ведь главное меню не суёт нос куда не следует, а только сообщает "нажата такая-то кнопка". А уже тот, кто вызвал главное меню, пускай разбирается, что ему делать с событием нажатия кнопки.
>>6861
https://ru.wikipedia.org/wiki/Подпрограмма
Представляешь, "if" - это явная операция проверки выражения на истинность. По сути ты проверяешь истинность того, что истина равна истине. Лол.
А ещё можно делать так:
Чтобы заниматься ctrl+c/ctrl+v, когда захочешь перенести пару объектов в другую игру? Или тянуть за собой стену кода с лишними константами? Самое весёлое, наверное, ctrl+f и поиск в файле на тысячу констант в той самой игре "сложнее тетриса"...
Создаёшь файл res://utils/magic_utils.gd
Использовать так:
Ты либо собираешь гуй в одном месте и потом соединяешь сигналами кому нужно, либо делишь гуй на части и каждый объект имеет свою часть гуя.
Пример с меню выше был. Игровым объектам не нужен прямой доступ к элементам меню, а шкала здоровья над врагом должна подчиняться только тому врагу, которому она принадлежит.
Рискуешь прибить гвоздями что-нибудь к этому "постоянно висящему" менеджеру и забыть об этом. А потом "ой" и переделывать кучу скриптов или смириться и доделывать игру на костылях, без последующего повторного использования кода.
Я не говорю, что вообще нельзя использовать. Просто нужно подходить к этому с большой осторожностью, а не насыпать гору кода не глядя, а потом спрашивать советов на форумах, а чё там ничего не работает.
Нужно ввести в редактор ограничения по уровню. Делаешь игры - получаешь очки опыта; чем больше очков опыта, тем больше функций разблокируется.
>Разбавлять стену кода комментами
>оформляю код при помощи комментов
>Комменты в таком отношении это заголовки
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())
>Шину взаимодействия, например, между игровыми объектами и гуём,
Ты либо собираешь гуй в одном месте и потом соединяешь сигналами кому нужно, либо делишь гуй на части и каждый объект имеет свою часть гуя.
Пример с меню выше был. Игровым объектам не нужен прямой доступ к элементам меню, а шкала здоровья над врагом должна подчиняться только тому врагу, которому она принадлежит.
>Постоянно висящий в памяти менеджер чего-либо, например, музыки.
Рискуешь прибить гвоздями что-нибудь к этому "постоянно висящему" менеджеру и забыть об этом. А потом "ой" и переделывать кучу скриптов или смириться и доделывать игру на костылях, без последующего повторного использования кода.
Я не говорю, что вообще нельзя использовать. Просто нужно подходить к этому с большой осторожностью, а не насыпать гору кода не глядя, а потом спрашивать советов на форумах, а чё там ничего не работает.
Нужно ввести в редактор ограничения по уровню. Делаешь игры - получаешь очки опыта; чем больше очков опыта, тем больше функций разблокируется.
>>6861
https://ru.wikipedia.org/wiki/Подпрограмма
Представляешь, "if" - это явная операция проверки выражения на истинность. По сути ты проверяешь истинность того, что истина равна истине. Лол.
А ещё можно делать так:
Чтобы заниматься ctrl+c/ctrl+v, когда захочешь перенести пару объектов в другую игру? Или тянуть за собой стену кода с лишними константами? Самое весёлое, наверное, ctrl+f и поиск в файле на тысячу констант в той самой игре "сложнее тетриса"...
Создаёшь файл res://utils/magic_utils.gd
Использовать так:
Ты либо собираешь гуй в одном месте и потом соединяешь сигналами кому нужно, либо делишь гуй на части и каждый объект имеет свою часть гуя.
Пример с меню выше был. Игровым объектам не нужен прямой доступ к элементам меню, а шкала здоровья над врагом должна подчиняться только тому врагу, которому она принадлежит.
Рискуешь прибить гвоздями что-нибудь к этому "постоянно висящему" менеджеру и забыть об этом. А потом "ой" и переделывать кучу скриптов или смириться и доделывать игру на костылях, без последующего повторного использования кода.
Я не говорю, что вообще нельзя использовать. Просто нужно подходить к этому с большой осторожностью, а не насыпать гору кода не глядя, а потом спрашивать советов на форумах, а чё там ничего не работает.
Нужно ввести в редактор ограничения по уровню. Делаешь игры - получаешь очки опыта; чем больше очков опыта, тем больше функций разблокируется.
>Разбавлять стену кода комментами
>оформляю код при помощи комментов
>Комменты в таком отношении это заголовки
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())
>Шину взаимодействия, например, между игровыми объектами и гуём,
Ты либо собираешь гуй в одном месте и потом соединяешь сигналами кому нужно, либо делишь гуй на части и каждый объект имеет свою часть гуя.
Пример с меню выше был. Игровым объектам не нужен прямой доступ к элементам меню, а шкала здоровья над врагом должна подчиняться только тому врагу, которому она принадлежит.
>Постоянно висящий в памяти менеджер чего-либо, например, музыки.
Рискуешь прибить гвоздями что-нибудь к этому "постоянно висящему" менеджеру и забыть об этом. А потом "ой" и переделывать кучу скриптов или смириться и доделывать игру на костылях, без последующего повторного использования кода.
Я не говорю, что вообще нельзя использовать. Просто нужно подходить к этому с большой осторожностью, а не насыпать гору кода не глядя, а потом спрашивать советов на форумах, а чё там ничего не работает.
Нужно ввести в редактор ограничения по уровню. Делаешь игры - получаешь очки опыта; чем больше очков опыта, тем больше функций разблокируется.
Руки зачесались написать авто конвертер ассетов из 4 в 3.
Годаны, поясните.
Вот я делаю экспорт на андроид. Для релиза надо сгенерить ключ. Ок, генерю. Но тут https://developer.android.com/studio/publish/app-signing написано, что это ключ не совсем ключ, его можно давать только гуглу при заливе в стор, а гугл на его основе сделает свой ключ, и вот тогдаааа...
Кароч. Я в аппстор лить не собираюсь. На итч безопасно заливать с тем ключом, который я по инструкции https://docs.godotengine.org/en/3.5/tutorials/export/exporting_for_android.html генерю?
Вот я делаю экспорт на андроид. Для релиза надо сгенерить ключ. Ок, генерю. Но тут https://developer.android.com/studio/publish/app-signing написано, что это ключ не совсем ключ, его можно давать только гуглу при заливе в стор, а гугл на его основе сделает свой ключ, и вот тогдаааа...
Кароч. Я в аппстор лить не собираюсь. На итч безопасно заливать с тем ключом, который я по инструкции https://docs.godotengine.org/en/3.5/tutorials/export/exporting_for_android.html генерю?
>>6903
Сделай отдельный ключ для резиза на итч. А потом забудь его поменять.
Вообще я бы даже сделал так - написал батники, которые вызывают
экспорт из годота с нужными параметрами.
В гугл я не выкладывал, но читал что он больше не принимает apk, а принимает aab, это архив всех билдов, а юзеру он сам отдает сборку только под его телефон, поэтому, увы, подписывать будет действительно гугл, а не ты.
Сделай отдельный ключ для резиза на итч. А потом забудь его поменять.
Вообще я бы даже сделал так - написал батники, которые вызывают
экспорт из годота с нужными параметрами.
В гугл я не выкладывал, но читал что он больше не принимает apk, а принимает aab, это архив всех билдов, а юзеру он сам отдает сборку только под его телефон, поэтому, увы, подписывать будет действительно гугл, а не ты.
>>6909
"Предустановки" называется. Ты можешь прямо в окне экспорта создать несколько разных предустановок с разными параметрами на одну и ту же платформу. А потом в один клик экспортировать все.
>батники, которые вызывают экспорт из годота с нужными параметрами.
"Предустановки" называется. Ты можешь прямо в окне экспорта создать несколько разных предустановок с разными параметрами на одну и ту же платформу. А потом в один клик экспортировать все.
>>6910
Может быть, не смотрел есть ли такой функционал.
Может быть, не смотрел есть ли такой функционал.
>>6910
В общем да, так тоже можно. Но все равно надо быть внимательным чтобы не залить потом версию не из той папки. Не знаю, автоматизирована ли заливка на гугл, на итч заливаю butler-ом.
В общем да, так тоже можно. Но все равно надо быть внимательным чтобы не залить потом версию не из той папки. Не знаю, автоматизирована ли заливка на гугл, на итч заливаю butler-ом.
32 Кб, 676x156Я уже несколько дней размышляю о пулях. Пули летят. Летят быстро. 833 м/с, при средних фепесах в 60 это получается 14 метров за один кадр. Правильно ли я понимаю, что если реализовать пулю втупую, проджектайлом, то возможна ситуация, когда в 10 метрах от стрелка стоит объект, стрелок стреляет, но вместо объекта пуля попадает в стену у него за спиной?
>>6919
Не только возможна, но и будет. Я десяток тредов назад скидывал тест в 2д, да ты и сам его можешь повторить. Возьми 2 Area одна символизирует игрока, вторая стену, подключи сигналы, и пуляй прожектайл. Наблюдай порядок получения сигналов и будет ли их наличие.
Не только возможна, но и будет. Я десяток тредов назад скидывал тест в 2д, да ты и сам его можешь повторить. Возьми 2 Area одна символизирует игрока, вторая стену, подключи сигналы, и пуляй прожектайл. Наблюдай порядок получения сигналов и будет ли их наличие.
>>6919
самое первое что приходит в голову - для таких быстрых объектов рэйкастить из точки а в точку б и смотреть в чё там можно врезаться
самое первое что приходит в голову - для таких быстрых объектов рэйкастить из точки а в точку б и смотреть в чё там можно врезаться
43 Кб, 1704x827>>6923
Окей.
>>6926
Значит надо не просто проджектайлить, а с учётом баллистики. Пуля пролетает кадр, к её вектору прибавляется гравитация, пуля кидает рейкаст к месту своего предыдущего положения, наносит урон всему, что попало в рейкаст и уничтожается, если рейкаст ничего не нашёл, ищет столкновение и наносит урон и уничтожается, если столкновения нет, летит дальше.
В таком алгоритме можно и пробивную силу реализовать. В стене пуля сразу уничтожается, а в туше - убавляет своё ХП и скорость, и летит дальше.
Окей.
>>6926
Значит надо не просто проджектайлить, а с учётом баллистики. Пуля пролетает кадр, к её вектору прибавляется гравитация, пуля кидает рейкаст к месту своего предыдущего положения, наносит урон всему, что попало в рейкаст и уничтожается, если рейкаст ничего не нашёл, ищет столкновение и наносит урон и уничтожается, если столкновения нет, летит дальше.
В таком алгоритме можно и пробивную силу реализовать. В стене пуля сразу уничтожается, а в туше - убавляет своё ХП и скорость, и летит дальше.
>>6997
Ну тоесть, не всему, а самому дальнему объекту, потому что рейкаст кидается назад. Кстати, надо выяснить, от рейкаста приходит массив отсортированный по расстоянию или самому сортировать?
> пуля кидает рейкаст к месту своего предыдущего положения, наносит урон всему, что попало в рейкаст
Ну тоесть, не всему, а самому дальнему объекту, потому что рейкаст кидается назад. Кстати, надо выяснить, от рейкаста приходит массив отсортированный по расстоянию или самому сортировать?
>move_and_collide
>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.
>>7012
>>6997
>>6926
>>6923
>>6919
Используй силу движка, Люк. Метод уже реализован.
Хотя, если речь про 3д, то там я информации не нашёл.
Объясните кто-нибудь в каких ситуациях надо использовать yield()? Это вообще важно/полезно/круто?
Диздоки-то к играм пишете?
Визуализации делаете?
Делитесь графами.
Визуализации делаете?
Делитесь графами.
>>7056
все заняты пиздежом в интернете и спорами о синтаксисе,никто игры не делает на самом деле
все заняты пиздежом в интернете и спорами о синтаксисе,никто игры не делает на самом деле
>>7056
Поставил дедлайн - прототип к концу месяца. Механики продуманы, но надо интерфейс и генерить тонны спрайтов.
Поставил дедлайн - прототип к концу месяца. Механики продуманы, но надо интерфейс и генерить тонны спрайтов.
>>7056
Я пару раз на бумаге такую хуйню рисовал когда надо было прям залупу с кучей вложений отрефакторить.
Я пару раз на бумаге такую хуйню рисовал когда надо было прям залупу с кучей вложений отрефакторить.
>>6919
Обычно физические пульки в играх двигаются значительно медленнее, чтобы игрок мог их визуально заметить, иначе смысла нет - буллетхелл и всё такое, где игроку нужно уворачиваться от пуль. Реалистичное оружие делается простым рейкастом - пуля попадает в цель в момент нажатия кнопки стрельбы, безо всякой баллистики, при том рейкаст зачастую короткий. Для визуализации рейкаста могут растягивать текстуру, типа это пуля трассирующая, но это только декорация, а не физическая модель. Другое дело - гранаты и ракеты, они обычно двигаются медленно и поэтому у них есть полноценная физическая модель (вплоть до того, что их можно сбить с курса или отбить в сторону, или они сами отскакивают). Тут всё зависит от того, какую игру ты делаешь, какую роль играет стрельба и т.д.
>>6997
Можешь попробовать встроенную фичу:
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
>833 м/с, при средних фепесах в 60 это получается 14 метров за один кадр
Обычно физические пульки в играх двигаются значительно медленнее, чтобы игрок мог их визуально заметить, иначе смысла нет - буллетхелл и всё такое, где игроку нужно уворачиваться от пуль. Реалистичное оружие делается простым рейкастом - пуля попадает в цель в момент нажатия кнопки стрельбы, безо всякой баллистики, при том рейкаст зачастую короткий. Для визуализации рейкаста могут растягивать текстуру, типа это пуля трассирующая, но это только декорация, а не физическая модель. Другое дело - гранаты и ракеты, они обычно двигаются медленно и поэтому у них есть полноценная физическая модель (вплоть до того, что их можно сбить с курса или отбить в сторону, или они сами отскакивают). Тут всё зависит от того, какую игру ты делаешь, какую роль играет стрельба и т.д.
>>6997
Можешь попробовать встроенную фичу:
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
>>7056
Я не делаю диздоки на своем этапе, мне морально тяжело обрубать то, что я не могу сделать. Поэтому я просто в редакторе делаю, что могу, а потом смотрю, есть ли тут игра.
Я не делаю диздоки на своем этапе, мне морально тяжело обрубать то, что я не могу сделать. Поэтому я просто в редакторе делаю, что могу, а потом смотрю, есть ли тут игра.
>>7070
Эм... Вообще-то, прототип игры - это голые механики. Графика в прототипе - условные кубы/квадраты, так, чтобы было понятно назначение каждого объекта. "Тонны спрайтов" к прототипу отношения не имеют, независимо от того, какую игру ты делаешь.
Цель прототипа - проверка механик. Мозг человека устроен так, что не способен отличить, когда его привлекает процесс игры, а когда - графика/звуки. Поэтому, если в прототипе приятная графика, если разработка начата с графики без прототипа, тогда высока вероятность, что твоя механика не работает должным образом, но твой мозг видит приятную картинку на экране и думает "хорошая игра".
Скорее всего именно по этой причине рождаются неполноценные игры с шикарной графикой и просто ужасным геймплеем - разработчик играл, конечно, но его мозг обманул сам себя из-за графики.
Алсо, вложив силы и время в арт, будет тяжелее выбросить прототип нерабочей механики/игры. Прототипы создаются как раз чтобы выбрасывать лишнее до того, как потратишься на графон.
Ты всё равно вкладываешь в это какое-то время.
Тогда это книжка с картинками, а не игра, если без качественной графики от игры ничего не остаётся.
Графика - обёртка для игры, а прототип - попытка отсеять конфеты от говна до стадии упаковки.
>прототип к концу месяца
>Механики продуманы
>генерить тонны спрайтов
Эм... Вообще-то, прототип игры - это голые механики. Графика в прототипе - условные кубы/квадраты, так, чтобы было понятно назначение каждого объекта. "Тонны спрайтов" к прототипу отношения не имеют, независимо от того, какую игру ты делаешь.
Цель прототипа - проверка механик. Мозг человека устроен так, что не способен отличить, когда его привлекает процесс игры, а когда - графика/звуки. Поэтому, если в прототипе приятная графика, если разработка начата с графики без прототипа, тогда высока вероятность, что твоя механика не работает должным образом, но твой мозг видит приятную картинку на экране и думает "хорошая игра".
Скорее всего именно по этой причине рождаются неполноценные игры с шикарной графикой и просто ужасным геймплеем - разработчик играл, конечно, но его мозг обманул сам себя из-за графики.
Алсо, вложив силы и время в арт, будет тяжелее выбросить прототип нерабочей механики/игры. Прототипы создаются как раз чтобы выбрасывать лишнее до того, как потратишься на графон.
>inb4 нейроарт ничего не стоит
Ты всё равно вкладываешь в это какое-то время.
>inb4 игра жёстко завязана на графон
Тогда это книжка с картинками, а не игра, если без качественной графики от игры ничего не остаётся.
Графика - обёртка для игры, а прототип - попытка отсеять конфеты от говна до стадии упаковки.
>>7085
Не, я про прототип готового продукта. Прототип механик на кубах мне не нужен, потому что что механики работают мне известно из других источников, а вот без картинки я игру раскрутить не смогу. Мне нужен хотя бы срез арта чтобы можно было делать промо материалы, даже если основная графика и механики еще не доделаны. Да, нейроарт придется использовать, только тихо.
Не, я про прототип готового продукта. Прототип механик на кубах мне не нужен, потому что что механики работают мне известно из других источников, а вот без картинки я игру раскрутить не смогу. Мне нужен хотя бы срез арта чтобы можно было делать промо материалы, даже если основная графика и механики еще не доделаны. Да, нейроарт придется использовать, только тихо.
>>7080
Тогда будет тяжело расти как разработчик и твои проекты не вырастут больше мелких прототипов.
Диздок соло разработчику нужен, чтобы:
- не забыть то, что придумал, пока реализуешь, ибо реализация тратит очень много времени, а память у человека как правило очень слаба;
- организовать системы игры заранее, чтобы потом не приходилось перебрасывать и править файлы;
- заранее выявить логические нестыковки, например, когда твои хотелки противоречат друг другу (хотел динамичную игру, но механика тормозит игрока);
- разбить большие системы на мелкие части, которые намного легче понять и реализовать на практике, что может помочь в борьбе с прокрастинацией;
- сохранить свидетельство проверенных нерабочих механик, чтоб не бегать по одним и тем же граблям;
- более реалистично оценить масштаб работ, чтобы сократить слишком масштабные планы до того, как бросишься рисовать/моделировать;
- бороться с feature creep, хаотичным добавлением дополнительных фич, нарушающих простой дизайн и размывающих фокус игры лишними деталями;
- поддерживать игру в будущем, при условии, что поддерживаешь диздок в актуальном состоянии.
>тяжело обрубать то, что я не могу сделать
Тогда будет тяжело расти как разработчик и твои проекты не вырастут больше мелких прототипов.
Диздок соло разработчику нужен, чтобы:
- не забыть то, что придумал, пока реализуешь, ибо реализация тратит очень много времени, а память у человека как правило очень слаба;
- организовать системы игры заранее, чтобы потом не приходилось перебрасывать и править файлы;
- заранее выявить логические нестыковки, например, когда твои хотелки противоречат друг другу (хотел динамичную игру, но механика тормозит игрока);
- разбить большие системы на мелкие части, которые намного легче понять и реализовать на практике, что может помочь в борьбе с прокрастинацией;
- сохранить свидетельство проверенных нерабочих механик, чтоб не бегать по одним и тем же граблям;
- более реалистично оценить масштаб работ, чтобы сократить слишком масштабные планы до того, как бросишься рисовать/моделировать;
- бороться с feature creep, хаотичным добавлением дополнительных фич, нарушающих простой дизайн и размывающих фокус игры лишними деталями;
- поддерживать игру в будущем, при условии, что поддерживаешь диздок в актуальном состоянии.
>>7074
Ремейк игоры из 90х про снайперов. (зельда трифорс)
Там без баллистики и поправки на ветер никак.
> какую игру ты делаешь
Ремейк игоры из 90х про снайперов. (зельда трифорс)
> безо всякой баллистики
Там без баллистики и поправки на ветер никак.
>>7092
Это называют вертикальным срезом:
https://habr.com/ru/companies/miip/articles/308286/
https://askagamedev.tumblr.com/post/77406994278/game-development-glossary-the-vertical-slice
У тебя 100% клон с другой шкуркой? Или это механики уровня кликера с одной кнопкой? Просто интересно.
>Мне нужен хотя бы срез арта чтобы можно было делать промо материалы, даже если основная графика и механики еще не доделаны.
Это называют вертикальным срезом:
https://habr.com/ru/companies/miip/articles/308286/
https://askagamedev.tumblr.com/post/77406994278/game-development-glossary-the-vertical-slice
>механики работают мне известно из других источников
У тебя 100% клон с другой шкуркой? Или это механики уровня кликера с одной кнопкой? Просто интересно.
>>7052
Читай сам.
https://gdscript.com/solutions/coroutines-and-yield/
Некоторые вещи от движка можно добиться только на следующем кадре, поэтому приходится ждать.
>Объясните
Читай сам.
https://gdscript.com/solutions/coroutines-and-yield/
>Это вообще важно
Некоторые вещи от движка можно добиться только на следующем кадре, поэтому приходится ждать.
>>7119
Меня не совсем вертикальный срез интересует, он подразумевает что все что можно закодили, а для промо материалов мне достаточно иллюзии. Я могу просто заанимировать катсцену как кто то подходит и бьет и вылетают цифирки, мне не надо честные механики поиска пути, выбора персонажей, самих механик, рассчета сколько именно урон
Меня не совсем вертикальный срез интересует, он подразумевает что все что можно закодили, а для промо материалов мне достаточно иллюзии. Я могу просто заанимировать катсцену как кто то подходит и бьет и вылетают цифирки, мне не надо честные механики поиска пути, выбора персонажей, самих механик, рассчета сколько именно урон
>>7131
Ну я себе ставлю более жесткие рамки, не больше года.
Ну я себе ставлю более жесткие рамки, не больше года.
>>7140
Принято.
Принято.
315 Кб, 1816x1004>>7140
Хотел тебя поблагодарить апскейленным мемом, но апскейлер облажался и эмоция исчезает после апскейла. Но все равно держи.
Хотел тебя поблагодарить апскейленным мемом, но апскейлер облажался и эмоция исчезает после апскейла. Но все равно держи.
86 Кб, mp4,1280x720, 0:03
>>7125
АНИМИРОВАЛ КАТСЦЕНЫ
@
ПОЛУЧИЛ ИНВЕСТИЦИИ
@
МЕХАНИКИ СДЕЛАТЬ НЕ СМОГ
@
ЧУВСТВУЕШЬ БОЛЬ В ЖОПЕ
@
НО ЗАПАХА ГАРИ НЕТ
>заанимировать катсцену как кто то подходит и бьет и вылетают цифирки, мне не надо честные механики поиска пути, выбора персонажей, самих механик, рассчета сколько именно урон
АНИМИРОВАЛ КАТСЦЕНЫ
@
ПОЛУЧИЛ ИНВЕСТИЦИИ
@
МЕХАНИКИ СДЕЛАТЬ НЕ СМОГ
@
ЧУВСТВУЕШЬ БОЛЬ В ЖОПЕ
@
НО ЗАПАХА ГАРИ НЕТ
>>7140
Забыл ссылку на модель, если кто хочет:
https://sketchfab.com/3d-models/godette-rigged-dd05b69799a2438e97c90d166f6e416a
Забыл ссылку на модель, если кто хочет:
https://sketchfab.com/3d-models/godette-rigged-dd05b69799a2438e97c90d166f6e416a
>>7052
Я раньше тоже думал, что хуйня какаята. Но вот реальный пример использования.
Допустим юзерданные хранятся на облаке. Чтобы загрузить их, шлём запрос к серверу и ждём ответа. И не городим дикую конструкцию, а просто в одной функции:
Я раньше тоже думал, что хуйня какаята. Но вот реальный пример использования.
Допустим юзерданные хранятся на облаке. Чтобы загрузить их, шлём запрос к серверу и ждём ответа. И не городим дикую конструкцию, а просто в одной функции:
> send_request_to_server()
> var data = yield(self, "data_loaded")
> do_something_with(data)
>>7150
Так если цель заработать, то она достигнута, в чем боль? В крайнем случае нанять кого то можно будет.
Так если цель заработать, то она достигнута, в чем боль? В крайнем случае нанять кого то можно будет.
>>7150
Механики я делал там ничего сложного. Большую проблему доставляет задизайнить удобный интерфейс, чтобы игроку были все эти механики доступны и понятны.
Механики я делал там ничего сложного. Большую проблему доставляет задизайнить удобный интерфейс, чтобы игроку были все эти механики доступны и понятны.