Добро пожаловать в тред любви, взаимопомощи и ожидании нового ОПа
Шапка: https://hipolink.me/godothread
Предыдущий 78: >>1080508 (OP)(OP)
---
Билды и шаблоны экспорта скачать бесплатно: https://github.com/godotengine/godot-builds/releases
---
Dev snapshot: Godot 4.7 dev 4 https://godotengine.org/article/dev-snapshot-godot-4-7-dev-4/
Maintenance release: Godot 4.6.2 https://godotengine.org/article/maintenance-release-godot-4-6-2/
Dev snapshot: Godot 4.7 dev 3 https://godotengine.org/article/dev-snapshot-godot-4-7-dev-3/
Release candidate: Godot 4.6.2 RC 2 https://godotengine.org/article/release-candidate-godot-4-6-2-rc-2/
Шапка: https://hipolink.me/godothread
Предыдущий 78: >>1080508 (OP)(OP)
---
Билды и шаблоны экспорта скачать бесплатно: https://github.com/godotengine/godot-builds/releases
---
Dev snapshot: Godot 4.7 dev 4 https://godotengine.org/article/dev-snapshot-godot-4-7-dev-4/
Maintenance release: Godot 4.6.2 https://godotengine.org/article/maintenance-release-godot-4-6-2/
Dev snapshot: Godot 4.7 dev 3 https://godotengine.org/article/dev-snapshot-godot-4-7-dev-3/
Release candidate: Godot 4.6.2 RC 2 https://godotengine.org/article/release-candidate-godot-4-6-2-rc-2/
Кто на итч выкладывал игру, дайте подшар какие подводные? Там ща можно игры из РФ выкладывать?
>>3435 (Del)
Принял, спасибочки.
Принял, спасибочки.
>>3432
Подводный один, туда никто не заходит, итч не льет трафик, ты сам должен раскручивать по всяким тиктокам и прочему.
Подводный один, туда никто не заходит, итч не льет трафик, ты сам должен раскручивать по всяким тиктокам и прочему.
здарова. Вопрос такой, вот у меня есть сцена control с панелькой, как лучше синхронизировать её положение на экране между сценами? Делать одну мегасцену интерфейса на всё? Чатжпт говорит просто ебани на canvaslayer и оно заработает, только оно не работает.
>>3444 (Del)
А зачем?
А зачем?
>>3455
разобрался
разобрался
>>3417 (Del)
Нет, не фича, это баг, не лги себе, я полночи сидел пытался исправить баг с диагоналями у себя, и так и не смог.
Нет, не фича, это баг, не лги себе, я полночи сидел пытался исправить баг с диагоналями у себя, и так и не смог.
7 Кб, 585x200>>3469
Багофича: сделано случайно, но понравилось.
Ты правда код скопировал, не осмыслив его?
Добавь на указанную строчку, например, это:
Это должно запретить ходы по диагоналям.
Если хочешь понять смысл строчки с dot():
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-dot
Весь тот код был написан на скорую руку.
>>3472 (Del)
Молодец.
Багофича: сделано случайно, но понравилось.
>пытался исправить баг с диагоналями
Ты правда код скопировал, не осмыслив его?
Добавь на указанную строчку, например, это:
>...and new_direction.x != new_direction.y:
Это должно запретить ходы по диагоналям.
Если хочешь понять смысл строчки с dot():
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-dot
Весь тот код был написан на скорую руку.
>>3472 (Del)
>А я смог
Молодец.
>>3473
Этот код не реагирует на нажатие. Направление изменилось и? Таймер ждёт следующего тика. Переделывай.
Этот код не реагирует на нажатие. Направление изменилось и? Таймер ждёт следующего тика. Переделывай.
>>3492 (Del)
Нет, здесь таких нет. Поспрашивай в движкосрач-треде.
Нет, здесь таких нет. Поспрашивай в движкосрач-треде.
438 Кб, 1282x722Спустя пару лет вернулся к симулятору масштабных битв армий на годоте.
В прошлый раз на чистом гдскрипте смог выжать сражения 500 на 500. Сейчас подключил C#, его либу для ECS, параллельные вычисления, рендеринг сервер, мультимеш2д, кастомный шейдер и уже 10К на 10К драки держат 100+ фпс на моём средненьком i5 процессоре.
Хотел сначала сделать видос, но шакалит люто и весит больно много, поэтому чисто скрин.
В прошлый раз на чистом гдскрипте смог выжать сражения 500 на 500. Сейчас подключил C#, его либу для ECS, параллельные вычисления, рендеринг сервер, мультимеш2д, кастомный шейдер и уже 10К на 10К драки держат 100+ фпс на моём средненьком i5 процессоре.
Хотел сначала сделать видос, но шакалит люто и весит больно много, поэтому чисто скрин.
>>3492 (Del)
Ну так не пользуйся, это опенсорс, можно любой язык подключить, например C++
Ну так не пользуйся, это опенсорс, можно любой язык подключить, например C++
>>3503
Битва 10к на 10к это не геймплей еще. Кроме мессива на экране нужно еще что-то захватывающее. А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Битва 10к на 10к это не геймплей еще. Кроме мессива на экране нужно еще что-то захватывающее. А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
>>3496
Выглядит клево
Можно небольшой кусок снять, условно в середине
>>3506
Я думаю дорога на восток многим из движкосрача треда подложила свинью, отчего некоторые и возбудились. Потому что кок ток то! Это жы гдскипт нююю он же плохой uuuu
Выглядит клево
>Хотел сначала сделать видос, но шакалит люто и весит больно много
Можно небольшой кусок снять, условно в середине
>>3506
>А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Я думаю дорога на восток многим из движкосрача треда подложила свинью, отчего некоторые и возбудились. Потому что кок ток то! Это жы гдскипт нююю он же плохой uuuu
746 Кб, 888x503>>3508 (Del)
Ты забыл потребовать признать это.
Ты забыл потребовать признать это.
9,2 Мб, mp4,1280x720, 0:05
>>3500 (Del)
Ага, я очень доволен.
>>3501
Геймплей будет, я хотел сначала сделать стресс-тест того, что это вообще жизнеспособно в годоте.
>>3510
Ну вот тебе 5 секунд с середины, правда не уверен, что хоть что-то разберешь в этом месиве пикселей. Зато 300 фпс, хоть и скачущие.
Ага, я очень доволен.
>>3501
Геймплей будет, я хотел сначала сделать стресс-тест того, что это вообще жизнеспособно в годоте.
>>3510
Ну вот тебе 5 секунд с середины, правда не уверен, что хоть что-то разберешь в этом месиве пикселей. Зато 300 фпс, хоть и скачущие.
>>3515 (Del)
Это Friflo ECS. Очень шустрая штука.
Это Friflo ECS. Очень шустрая штука.
>>3510
Так 2 топовые игры на годоте (sts2 и восток) - обе на шарпах. Так что гдс унижают даже в рамках годотреади-языков
>гдскипт нююю он же плохой
Так 2 топовые игры на годоте (sts2 и восток) - обе на шарпах. Так что гдс унижают даже в рамках годотреади-языков
Вижу, что многие ругаются на GDScript и его медлительность. Думаю, всё-таки придется учить C#, как-будто это более выгодная инвестиция. Особенно учитывая то, что он и за пределами Годота используется.
>>3534
Только вместо делания игры учить c# не стоит.
Только вместо делания игры учить c# не стоит.
>>3534
C++ быстрее. Учи его.
C++ быстрее. Учи его.
>>3519
Обе этих игры начинали делать на другом движке на C#, то есть тут нет никакой объективной причины в самом гдскрипте. Просто у них уже был какой то опыт и может быть какой то игровой код написан
Обе этих игры начинали делать на другом движке на C#, то есть тут нет никакой объективной причины в самом гдскрипте. Просто у них уже был какой то опыт и может быть какой то игровой код написан
>>3537
В СУБШОТЕ уже был твой коллега.
>>1080088 →
Все это конечно классно, но интересно бы что-то приближенное к реальной игре с поиском пути. Как вот жуки в факторио. Там, почему-то, ощущается это жутковатая масса в движение (может просто игровая иммерсивность), а тут не чувствуется этого. У чела в СУБШОТЕ вообще уже на жидкость похоже.
В СУБШОТЕ уже был твой коллега.
>>1080088 →
Все это конечно классно, но интересно бы что-то приближенное к реальной игре с поиском пути. Как вот жуки в факторио. Там, почему-то, ощущается это жутковатая масса в движение (может просто игровая иммерсивность), а тут не чувствуется этого. У чела в СУБШОТЕ вообще уже на жидкость похоже.
>>3541
Скорее всего начинали с юнити и потом перекатились.
Слишком большая разницам, все с нуля придется переписывать, если ты прям не гуру кодер которому делать нефиг, который умудрился писать сразу через слой абстракции (да еще обобщить между двумя движками, так как заведомо ты такой код никогда не напишешь, абстракции будут протекать)
Скорее всего начинали с юнити и потом перекатились.
>какой то игровой код написан
Слишком большая разницам, все с нуля придется переписывать, если ты прям не гуру кодер которому делать нефиг, который умудрился писать сразу через слой абстракции (да еще обобщить между двумя движками, так как заведомо ты такой код никогда не напишешь, абстракции будут протекать)
>>3542
Да это я, я как раз пишу всю игровую логику на c++ и подключаю к разным рендерам.
>гуру кодер которому делать нефиг,
Да это я, я как раз пишу всю игровую логику на c++ и подключаю к разным рендерам.
>>3534
Как бы на шарпах тоже надо уметь писать оптимизированный код, сам по себе шарпы тебя не спасут от гадостей в игровом цикле. Да и часть API на вариантах (динамических типах), поэтому не прокрастинируй шарпами.
Все равно дотнетовские шарпы это совершенно отдельный мир. А для хоум скриптов тебе хватит петухона, который похож на гдскрипт.
1. научись делать игры.
2. научись оптимизировать игры.
3. уже потом думай что упёрса в гдскрипт (потому что очень сильно захочется сразу прыгнуть в с++).
В реале может получиться что эффективный проект будет 95% на гдаскрипт и лишь 5% на С++
Как бы на шарпах тоже надо уметь писать оптимизированный код, сам по себе шарпы тебя не спасут от гадостей в игровом цикле. Да и часть API на вариантах (динамических типах), поэтому не прокрастинируй шарпами.
Все равно дотнетовские шарпы это совершенно отдельный мир. А для хоум скриптов тебе хватит петухона, который похож на гдскрипт.
1. научись делать игры.
2. научись оптимизировать игры.
3. уже потом думай что упёрса в гдскрипт (потому что очень сильно захочется сразу прыгнуть в с++).
В реале может получиться что эффективный проект будет 95% на гдаскрипт и лишь 5% на С++
>>3545
Почему ты считаешь что дело только в оптимизациях? Просто у людей могут быть предпочтения к языкам и платформам. Не только к синтаксису. Особенно если люди работали кодерами. Например чел проникся реактивным программированием и хочет использовать Rx везде где можно.
мимо
Почему ты считаешь что дело только в оптимизациях? Просто у людей могут быть предпочтения к языкам и платформам. Не только к синтаксису. Особенно если люди работали кодерами. Например чел проникся реактивным программированием и хочет использовать Rx везде где можно.
мимо
>>3490
Код написан с учётом особенностей движения "змейки":
- змейка движется ПОСТОЯННО - не способна остановиться;
- змейка движется в последнем выбранном направлении;
- змейка не может двигаться назад/задом наперёд.
Итого, когда наступает очередной цикл опроса:
1. Считываем актуальные значения ввода (get_vector()).
2. Проверяем соответствие условиям движения (см. выше).
3. Если условия соблюдены, принимаем новое значение.
4. Если условия не соблюдены - движемся куда двигались.
Примеры:
- двигались вправо - нажали вправо - движемся вправо;
- двигались вправо - нажали вверх - движемся вверх;
- двигались вправо - нажали влево - движемся вправо;
- двигались вправо - ничего не нажато - движемся вправо.
>>3492 (Del)
Это просто с непривычки. Так с любым новым языком.
>Направление изменилось и? Таймер ждёт следующего тика.
Код написан с учётом особенностей движения "змейки":
- змейка движется ПОСТОЯННО - не способна остановиться;
- змейка движется в последнем выбранном направлении;
- змейка не может двигаться назад/задом наперёд.
Итого, когда наступает очередной цикл опроса:
1. Считываем актуальные значения ввода (get_vector()).
2. Проверяем соответствие условиям движения (см. выше).
3. Если условия соблюдены, принимаем новое значение.
4. Если условия не соблюдены - движемся куда двигались.
Примеры:
- двигались вправо - нажали вправо - движемся вправо;
- двигались вправо - нажали вверх - движемся вверх;
- двигались вправо - нажали влево - движемся вправо;
- двигались вправо - ничего не нажато - движемся вправо.
>>3492 (Del)
>голова не кружится, когда вы гдскрипт читаете?
Это просто с непривычки. Так с любым новым языком.
>>3546
Технический опыт показывает, что лучше брать инструменты близкие к платформе.
Ты и так будешь трахаться с проблемами, так еще добавишь слой проблем от вторичного языка.
Поэтому если андроид - то это котлин.
если айос - то свифт, а не котлин
если годот это - гдскрипт.
При этом я очень не поддерживаю идею гдскрипта, он тормозит развитие. Да, облегчает вкат, но развитие создают не они, а те авторы "востока" и прочих шумных релизов (а они нередко мигранты с юнити и шарпов. Поэтому важнее было бы облегчить им миграцию, чем тем людям которые дропнуть разработку с вероятностью 99.99%).
Технический опыт показывает, что лучше брать инструменты близкие к платформе.
Ты и так будешь трахаться с проблемами, так еще добавишь слой проблем от вторичного языка.
Поэтому если андроид - то это котлин.
если айос - то свифт, а не котлин
если годот это - гдскрипт.
При этом я очень не поддерживаю идею гдскрипта, он тормозит развитие. Да, облегчает вкат, но развитие создают не они, а те авторы "востока" и прочих шумных релизов (а они нередко мигранты с юнити и шарпов. Поэтому важнее было бы облегчить им миграцию, чем тем людям которые дропнуть разработку с вероятностью 99.99%).
Годоту мешает гдскрипт и система узлов. Вот сделайте нормальный шарп и систему компонентов и все... Имба будет.
>>3492 (Del)
Меня тоже ломало от правосторонних типов 11 лет назад. Ниче, адаптировался.
На питоне почти не писал.
Пофиг на гдскрипт, надо пинать чтобы полноценный и нормальный JIT сделали.
Меня тоже ломало от правосторонних типов 11 лет назад. Ниче, адаптировался.
На питоне почти не писал.
Пофиг на гдскрипт, надо пинать чтобы полноценный и нормальный JIT сделали.
>>3552
Годот позволяет писать без узлов (эти ваши серверы). Я не копал так глубоко, но периодично натыкаюсь на всякие заманухи, которые показывают что годот можно перелопатить довольно гибко (но зачем?)
Годот позволяет писать без узлов (эти ваши серверы). Я не копал так глубоко, но периодично натыкаюсь на всякие заманухи, которые показывают что годот можно перелопатить довольно гибко (но зачем?)
>>3550
А практический опыт показывает, что лучшие игры пишутся лучшими инструментами (язык - тоже инструмент), к коим гдс никаким боком не относится.
Согласен, лучше замедлить динамикодрисню еще одним слоем, который будет перебивать строго типизированное апи в варианты, чем делать из самого апи движка этот слой. Динамикодрисне то похуй, она и так медленная, а вот нормальным языкам - больно.
>Технический опыт показывает, что лучше брать инструменты близкие к платформе.
А практический опыт показывает, что лучшие игры пишутся лучшими инструментами (язык - тоже инструмент), к коим гдс никаким боком не относится.
>Поэтому важнее было бы облегчить им миграцию
Согласен, лучше замедлить динамикодрисню еще одним слоем, который будет перебивать строго типизированное апи в варианты, чем делать из самого апи движка этот слой. Динамикодрисне то похуй, она и так медленная, а вот нормальным языкам - больно.
>>3559
Кто хорошо платит, тот меня и танцует.
Кто хорошо платит, тот меня и танцует.
>>3558
гдСКРИПТ - это скриптовый язык. На нем, естественно, пишутся всякие легковесные скрипты (гуй, ввод контроллера и так далее), а тяжелые вычисления на с++. Поэтому да, игры делаются на связке лучших языков (c++ и скриптов). C# тут как видишь не участвует.
гдСКРИПТ - это скриптовый язык. На нем, естественно, пишутся всякие легковесные скрипты (гуй, ввод контроллера и так далее), а тяжелые вычисления на с++. Поэтому да, игры делаются на связке лучших языков (c++ и скриптов). C# тут как видишь не участвует.
Ребят, завязывайте со срачем "GDScript vs C#".
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>>3496
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>>3496
>500 на 500
>10К на 10К
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
Ребят, завязывайте со срачем "GDScript vs C#".
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>>3496
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>>3496
>500 на 500
>10К на 10К
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
>>3562
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
>>3565
Почему курсов то? Сишорпу с дотнетом дофига лет. И отечественный софт на дотнете очень давно пишется.
>жертвы курсов
Почему курсов то? Сишорпу с дотнетом дофига лет. И отечественный софт на дотнете очень давно пишется.
>>3562
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
>>3573
Видишь ли, это может показаться тебе неочевидным, но у движка открытые исходники, и ты можешь вызвать любую функцию с любым нужным типом.
Видишь ли, это может показаться тебе неочевидным, но у движка открытые исходники, и ты можешь вызвать любую функцию с любым нужным типом.
>>3573
Это хорошо. Ты не должен обращаться к API движка слишком часто из высокопроизводительного кода. Твой код получает пакеты данных от движка, обрабатывает их у себя внутри на максимальной скорости, а потом передаёт движку одной командой. Всё. Не нужно дёргать API движка каждую наносекунду. Если тебе почему-то нужно, то тебя производительность вообще волновать не должна - тебя должна волновать кривая архитектура/дизайн игры.
>динамикодрисня с вариантами в качестве апи к движку
Это хорошо. Ты не должен обращаться к API движка слишком часто из высокопроизводительного кода. Твой код получает пакеты данных от движка, обрабатывает их у себя внутри на максимальной скорости, а потом передаёт движку одной командой. Всё. Не нужно дёргать API движка каждую наносекунду. Если тебе почему-то нужно, то тебя производительность вообще волновать не должна - тебя должна волновать кривая архитектура/дизайн игры.
>>3581
Вот я и пытаюсь делать игру... Открыл редактор Godot, открыл несколько скриптов, потом подумал "дай гляну тред, буквально минутку и вернусь к своим скриптам", а вы тут 50 постов успели насрать буквально за пару часов. Ну сколько можно? Потерял на вас ещё пару часов. Опять день закончился, а к игре даже не притронулся...
>Тогда придется идти делать игры.
Вот я и пытаюсь делать игру... Открыл редактор Godot, открыл несколько скриптов, потом подумал "дай гляну тред, буквально минутку и вернусь к своим скриптам", а вы тут 50 постов успели насрать буквально за пару часов. Ну сколько можно? Потерял на вас ещё пару часов. Опять день закончился, а к игре даже не притронулся...
>>3580
По поинтеру штоле? Как деды? Это нарушение изоляции, за которое я заплачу сегфолтами, на которые я никак не повлияю, даже если я захочу дергать за яйца функции внутри движка вне общего апи. Форк движка это конечно интересно, но не очень интересно
>>3584
И это я еще не углублялся в тему renderingdevice, там скорее всего тоже есть на что посмотреть
>ты можешь вызвать любую функцию с любым нужным типом.
По поинтеру штоле? Как деды? Это нарушение изоляции, за которое я заплачу сегфолтами, на которые я никак не повлияю, даже если я захочу дергать за яйца функции внутри движка вне общего апи. Форк движка это конечно интересно, но не очень интересно
>>3584
>Чем хуже тем лучше, только выиграли, ну подумаешь что рейкастим нодой потому что рейкастить нодой быстрее чем рейкастить через апи
И это я еще не углублялся в тему renderingdevice, там скорее всего тоже есть на что посмотреть
282 Кб, 700x600Проблема ньюфагов, они верят что чем производительнее язык, тем быстрее будет их код.
Но проблема ньюфагов именно в их плохом коде и понимании масштабов того, как им еще далеко до кода хотя бы среднего качества.
Я как-то в сосничестве реализовывал функции пхп на С++ и они у меня работали медленней чем на пхп. Открыл сорцы и вообще не понял что там за магия, а я верил что там просто char перебирают
Но проблема ньюфагов именно в их плохом коде и понимании масштабов того, как им еще далеко до кода хотя бы среднего качества.
Я как-то в сосничестве реализовывал функции пхп на С++ и они у меня работали медленней чем на пхп. Открыл сорцы и вообще не понял что там за магия, а я верил что там просто char перебирают
>>3589
Почему ты считаешь что только ньюфаги хотят определенный язык использовать? Ньюфаги как раз жрут что дают, а более опытные уже имеют предпочтения исходя из своего опыта.
Ты скорее сам ньюфаг потому что все сводишь к синтаксису и какой-то мифической скорости. Не ньюфаг думал бы что хочет использовать либы к которым привык.
Почему ты считаешь что только ньюфаги хотят определенный язык использовать? Ньюфаги как раз жрут что дают, а более опытные уже имеют предпочтения исходя из своего опыта.
Ты скорее сам ньюфаг потому что все сводишь к синтаксису и какой-то мифической скорости. Не ньюфаг думал бы что хочет использовать либы к которым привык.
>>3592
Так выпьем же за то, чтобы не-ньюфаг использовал эти либы, а не срался за движки и языки вне движкосрач-треда!
>использовать либы к которым привык.
Так выпьем же за то, чтобы не-ньюфаг использовал эти либы, а не срался за движки и языки вне движкосрач-треда!
>>3588
Это единственный вариант если ты делаешь по настоящему Великую игру.
> Форк движка это конечно интересно, но не очень интересно
Это единственный вариант если ты делаешь по настоящему Великую игру.
>>3592
Ну так бери и используй. Опять не нюфагам что-то мешает что же такое творится то.
Ну так бери и используй. Опять не нюфагам что-то мешает что же такое творится то.
>>3592
Потому что у реального специалиста нет синдрома утёнка, он достаточно гибок.
Завтра сделают С# первым гражданином и придет твой собрат который будет ныть так же про gdscript. Ощущаешь однобокость твоего мышления?
Отличие профессионала от ньюфага - умение адаптироваться - быть гибким, а ты ноешь, возводя свои эгоистические потребности выше профессионального скилла. Поэтому я и утрирую это поведение до ньюфажного.
>Почему ты считаешь что только ньюфаги хотят определенный язык использовать?
Потому что у реального специалиста нет синдрома утёнка, он достаточно гибок.
>Не ньюфаг думал бы что хочет использовать либы к которым привык.
Завтра сделают С# первым гражданином и придет твой собрат который будет ныть так же про gdscript. Ощущаешь однобокость твоего мышления?
Отличие профессионала от ньюфага - умение адаптироваться - быть гибким, а ты ноешь, возводя свои эгоистические потребности выше профессионального скилла. Поэтому я и утрирую это поведение до ньюфажного.
>>3596
Умение адаптироваться это не есть способность, когда тебя лишили авто, кататься на велосипеде сквозь ветер с дождем. Как говорится ветер в харю - я хуярю. Я таких "сенек" видел на работе. Два десятка лет пишут весь код в одном файле на десятки тысяч строк с формулировкой - так удобнее.
Умение адаптироваться это не есть способность, когда тебя лишили авто, кататься на велосипеде сквозь ветер с дождем. Как говорится ветер в харю - я хуярю. Я таких "сенек" видел на работе. Два десятка лет пишут весь код в одном файле на десятки тысяч строк с формулировкой - так удобнее.
>>3600
Как бы то ни было, ничего не изменится.
Если только МС не увидит перспективу годота и хардкорно не протолкнут свое лобби с фулл там кодерами.
Но у мелкомягких проблема с дальновидностью.
От нас с тобой ничего не зависит, даже если мы наноем 500 сообщений на двачах, все равно игру придется делать нам самим, как бы мы не злились на свою прокрастинацию и на этот неидеальный мир
Как бы то ни было, ничего не изменится.
Если только МС не увидит перспективу годота и хардкорно не протолкнут свое лобби с фулл там кодерами.
Но у мелкомягких проблема с дальновидностью.
От нас с тобой ничего не зависит, даже если мы наноем 500 сообщений на двачах, все равно игру придется делать нам самим, как бы мы не злились на свою прокрастинацию и на этот неидеальный мир
Кто то пользовался Cogitio? Я так понял по MIT лицензии просто нужно указать авторов в своей игре и все. Просто там по сути все готово, квест система, сохранения, тетрис инвентарь, какие то НПС, оружия, всякие кнопки, лифт, стул на котором можно ездить (просто заменить модель на велосипед например можно). Прикольно же.
>>3613
*cogito
*cogito
>>3613
Главное эту MIT лицензию сохранить, в авторах можно не указывать
>Я так понял по MIT лицензии просто нужно указать авторов в своей игре и все
Главное эту MIT лицензию сохранить, в авторах можно не указывать
>>3613
Сам движок по MIT лицензии же. Чего ты сомневаешься?
А когито мне не понравился, он какой-то переусложнённый.
Сам движок по MIT лицензии же. Чего ты сомневаешься?
А когито мне не понравился, он какой-то переусложнённый.
>>3617
Наоборот. MIT не требует сохранения лицензии, но требует указания авторства.
Наоборот. MIT не требует сохранения лицензии, но требует указания авторства.
>>3513
А такое для 3д работает? Ну не 10к тыщь а хотя бы орду из 100 человек воссоздать нормально
А такое для 3д работает? Ну не 10к тыщь а хотя бы орду из 100 человек воссоздать нормально
>>3534
Конечно, шарп шустрее гдскрипта процентов на 10, в специально подготовленных тестах, но всё-таки главное "узкое место" - скриптовое апи движка. Так что, для критических по быстродействию мест гдскрипт или ц# - однохуйственно в сравнении с C++.
Ну и вообще, есть простое правило. Если что-то выполняется 100500 раз за кадр, то этим должен заниматься компилируемый кусок кода (если предусмотрено, то лучше сам движок); если же до пары десятков раз - то вообще похуй, хоть жабаскрипт туда впили. Все проблемы с производительностью сводятся к тому, что криворукий кодер делает скриптами то, чем должен заниматься компилируемый код. Так что вообще забей, гдскрипт не "медленный" в бытовом понимании, просто не предназначен для некоторых специфических задач, типа управления армией в стратегии-числодробилке.
НО. Выучить C# всё равно полезно просто для собственного развития. В процессе ты сам поймёшь, что он нихуя не производительнее; однако знания - это знания, они делают тебя востребованным специалистом. Знать два языка - всяко лучше, чем знать один язык.
Конечно, шарп шустрее гдскрипта процентов на 10, в специально подготовленных тестах, но всё-таки главное "узкое место" - скриптовое апи движка. Так что, для критических по быстродействию мест гдскрипт или ц# - однохуйственно в сравнении с C++.
Ну и вообще, есть простое правило. Если что-то выполняется 100500 раз за кадр, то этим должен заниматься компилируемый кусок кода (если предусмотрено, то лучше сам движок); если же до пары десятков раз - то вообще похуй, хоть жабаскрипт туда впили. Все проблемы с производительностью сводятся к тому, что криворукий кодер делает скриптами то, чем должен заниматься компилируемый код. Так что вообще забей, гдскрипт не "медленный" в бытовом понимании, просто не предназначен для некоторых специфических задач, типа управления армией в стратегии-числодробилке.
НО. Выучить C# всё равно полезно просто для собственного развития. В процессе ты сам поймёшь, что он нихуя не производительнее; однако знания - это знания, они делают тебя востребованным специалистом. Знать два языка - всяко лучше, чем знать один язык.
>>3655
Остальные языки проиграют плюсам по производительности работы с годотом только в случае форкования движка и написания кода прямо в движке, не gdextension, а прямо в движок, что тянет за собой постоянную рекомпиляцию движка для проверки функционала. В случае gdextension - производительность апи равнозначна для любого языка, и гдс, и с++ и раст и с#, что приводит к тому, что один и тот же простой код (например для управления частицами через renderdevice) будет начинать пропердывать на условных 100к частицах на любом языке, компилируемом, интерпретируемом, каком угодно. Так что не пизди, дядя
>однохуйственно в сравнении с C++.
Остальные языки проиграют плюсам по производительности работы с годотом только в случае форкования движка и написания кода прямо в движке, не gdextension, а прямо в движок, что тянет за собой постоянную рекомпиляцию движка для проверки функционала. В случае gdextension - производительность апи равнозначна для любого языка, и гдс, и с++ и раст и с#, что приводит к тому, что один и тот же простой код (например для управления частицами через renderdevice) будет начинать пропердывать на условных 100к частицах на любом языке, компилируемом, интерпретируемом, каком угодно. Так что не пизди, дядя
>>3534
Кстати, я не разбираюсь ни в чем мною написанном, просто набросил говна на вентилятор. Но рад, что спровоцировал хорошие интересные ответы.
Кстати, я не разбираюсь ни в чем мною написанном, просто набросил говна на вентилятор. Но рад, что спровоцировал хорошие интересные ответы.
>>3565
Скачи Мочи очень популярная и успешная серия игр.
Там и поболее будет в Warband.
А так это просто нагрузочный тест, я хотел посмотреть, как сильно прокачался за пару лет периодического тыканья годота и шарпа, чтобы сравнить с тем, как было раньше. Понятно, что пока это просто месиво и геймплея нет. Но уже сейчас есть огромный запас фпс для реализации обхода препятствий, разных классов юнитов и прочего. Особенно если раза в два порезать количество юнитов и сделать бои не 10К на 10К, а 5К на 5К. Там и 500 фпс спокойно держатся на среднем проце.
>>3653
В теории будет, но я не уверен. Я никогда 3Д в годоте не занимался. Тут практически всё вынесено из годота, у меня буквально одна нода, которая просто гоняет ECS и рисует пискели. Даже для юнитов нод нет. Это отдельные ECS-сущности и десяток ECS-систем, которые как-то их обрабатывают.
То есть даже механика коллизий в этом проекте - это ECS, а не CollissionShape годотовский. Приходится конечно вручную всё считать, но это все равно быстрее выходит, чем 20К коллижн шейпов каждый фрейм.
>500 на 500 - много
Скачи Мочи очень популярная и успешная серия игр.
Там и поболее будет в Warband.
А так это просто нагрузочный тест, я хотел посмотреть, как сильно прокачался за пару лет периодического тыканья годота и шарпа, чтобы сравнить с тем, как было раньше. Понятно, что пока это просто месиво и геймплея нет. Но уже сейчас есть огромный запас фпс для реализации обхода препятствий, разных классов юнитов и прочего. Особенно если раза в два порезать количество юнитов и сделать бои не 10К на 10К, а 5К на 5К. Там и 500 фпс спокойно держатся на среднем проце.
>>3653
В теории будет, но я не уверен. Я никогда 3Д в годоте не занимался. Тут практически всё вынесено из годота, у меня буквально одна нода, которая просто гоняет ECS и рисует пискели. Даже для юнитов нод нет. Это отдельные ECS-сущности и десяток ECS-систем, которые как-то их обрабатывают.
То есть даже механика коллизий в этом проекте - это ECS, а не CollissionShape годотовский. Приходится конечно вручную всё считать, но это все равно быстрее выходит, чем 20К коллижн шейпов каждый фрейм.
>>3665
Когда у тебя есть команда сеньоров на зарплате? Тогда согласен. Можно из годота вообще повыдирать только самое важное (типа рендера) а остальное писать самому
Когда у тебя есть команда сеньоров на зарплате? Тогда согласен. Можно из годота вообще повыдирать только самое важное (типа рендера) а остальное писать самому
>>3659
Во-первых, не прямо в движке, а в отдельном модуле, статически линкуемом с движком. То есть весь твой самодельный велосипед будет изолирован в папке и обновляться на новую версию движка будет легко.
Во-вторых, Godot компилируется всего лишь час на компьютере из условного 2007 года в 4 потока. А у современных домашних компов от 8 потоков, RAM значительно шустрее и всякие новые AVX есть...
В-третьих, после первичной компиляции, тебе нет необходимости повторно компилировать исходники движка, поскольку достаточно скомпилировать свои собственные исходники (модуль) и потом всё вместе слинковать. Я тоже раньше думал, что C++ таким вот образом не умеет делать, но это реально возможно. Линковка занимает намного меньше времени, чем компиляция исходников в объектные файлы.
Так что создание модуля Godot вообще не проблема.
Проблема - придумать игру...
>написания кода прямо в движке
Во-первых, не прямо в движке, а в отдельном модуле, статически линкуемом с движком. То есть весь твой самодельный велосипед будет изолирован в папке и обновляться на новую версию движка будет легко.
Во-вторых, Godot компилируется всего лишь час на компьютере из условного 2007 года в 4 потока. А у современных домашних компов от 8 потоков, RAM значительно шустрее и всякие новые AVX есть...
В-третьих, после первичной компиляции, тебе нет необходимости повторно компилировать исходники движка, поскольку достаточно скомпилировать свои собственные исходники (модуль) и потом всё вместе слинковать. Я тоже раньше думал, что C++ таким вот образом не умеет делать, но это реально возможно. Линковка занимает намного меньше времени, чем компиляция исходников в объектные файлы.
Так что создание модуля Godot вообще не проблема.
Проблема - придумать игру...
>>3671
Красиво стелишь, но есть ньюансы
Движок должен знать что твоя либа существует, т.е. внутри него должен быть размещен функционал, который встроит твой код в пайплайн рендеринга, отправит ему состояние и применит возврат заместо gdext.
В виду того что зачастую тебе нужно не внедрять что-то новое, а модифицировать что-то уже существующее но хуево работающее - такое импровизированное апи, призванное отделить либу от кода движка - потребуется во многих местах. А еще - тебе придется самому поддерживать свои правки в обновлениях, что еще более печально.
Красиво стелишь, но есть ньюансы
Движок должен знать что твоя либа существует, т.е. внутри него должен быть размещен функционал, который встроит твой код в пайплайн рендеринга, отправит ему состояние и применит возврат заместо gdext.
В виду того что зачастую тебе нужно не внедрять что-то новое, а модифицировать что-то уже существующее но хуево работающее - такое импровизированное апи, призванное отделить либу от кода движка - потребуется во многих местах. А еще - тебе придется самому поддерживать свои правки в обновлениях, что еще более печально.
>>3669
Тебе чтобы написать команду scons platform=windows target=editor / target_release нужна команда сеньоров?... Это как анекдот про вкручивание лампочки?
Тебе чтобы написать команду scons platform=windows target=editor / target_release нужна команда сеньоров?... Это как анекдот про вкручивание лампочки?
>>3667
Про твою мочу только от тебя слышу здесь время от времени, а ведь я знаю много нишевых игр, которые никогда не станут широко известны нормисам. Ты представляешь, насколько мал охват твоей мочи? Буквально ноунейм для средневековых ролевиков.
Ты о геймплее лучше думай. 500 фпс симуляции мочи, обтекающей скачи, не делает игру хорошей. В GTA нет больших скоплений народа, но она всегда была самой популярной после Minecraft, в котором количество монстров даже меньше, чем пешеходов в GTA. А это максимально популярная игра, выше просто некуда... Хорошо, если взять что-то вроде Roblox, то может и возможно побить Minecraft, но ты видел Roblox? Там значительно хуже язык, чем наш GDSctipt, их движок принципиально не тянет адекватную графику. Пока подсчитываешь fps в своей моче, кто-то уже делает очередной культурный феномен, что запомнят все.
>Скачи Мочи очень популярная
Про твою мочу только от тебя слышу здесь время от времени, а ведь я знаю много нишевых игр, которые никогда не станут широко известны нормисам. Ты представляешь, насколько мал охват твоей мочи? Буквально ноунейм для средневековых ролевиков.
>500 фпс спокойно держатся на среднем проце
Ты о геймплее лучше думай. 500 фпс симуляции мочи, обтекающей скачи, не делает игру хорошей. В GTA нет больших скоплений народа, но она всегда была самой популярной после Minecraft, в котором количество монстров даже меньше, чем пешеходов в GTA. А это максимально популярная игра, выше просто некуда... Хорошо, если взять что-то вроде Roblox, то может и возможно побить Minecraft, но ты видел Roblox? Там значительно хуже язык, чем наш GDSctipt, их движок принципиально не тянет адекватную графику. Пока подсчитываешь fps в своей моче, кто-то уже делает очередной культурный феномен, что запомнят все.
>>3673
Трудно не прописать команду, а обеспечить причину ее прописывания
Трудно не прописать команду, а обеспечить причину ее прописывания
25 Кб, 652x96>>3674
Лолблядь, как ты умудряешься обсираться раз за разом
>Про твою мочу только от тебя слышу здесь время от времени, а ведь я знаю много нишевых игр, которые никогда не станут широко известны нормисам. Ты представляешь, насколько мал охват твоей мочи? Буквально ноунейм для средневековых ролевиков.
Лолблядь, как ты умудряешься обсираться раз за разом
>>3672
Там, вроде, можно просто зарегистрировать свою собственную ноду, которую юзер будет размещать и подключаться к ней через GDScript. То есть будешь работать точно так же, как с обычными нодами.
Ты рендерер переписываешь или игру делаешь?
По-моему, речь шла о геймплейных функциях...
Ну, попробуй документацию git почитать...
>должен знать что твоя либа существует
Там, вроде, можно просто зарегистрировать свою собственную ноду, которую юзер будет размещать и подключаться к ней через GDScript. То есть будешь работать точно так же, как с обычными нодами.
>пайплайн рендеринга
Ты рендерер переписываешь или игру делаешь?
По-моему, речь шла о геймплейных функциях...
>поддерживать свои правки в обновлениях
Ну, попробуй документацию git почитать...
>>3674
Ну если для тебя игра с 222 тысячами обзоров в Стиме это что-то нишевое, то действительно, нужно целиться тогда на майнкрафт, гта и роблокс, не меньше.
Не очень понимаю ход твоих мыслей. Если в самых популярных играх нет тысяч юнитов, то и я должен сделать их мало или что? Что за бред.
Я не думаю, что пытаться искусственно вывести культовый феномен по лекалам тех, кто это смог - хорошая идея. Может лучше сделать игру, которая будет нравиться мне самому в первую очередь?
Ну если для тебя игра с 222 тысячами обзоров в Стиме это что-то нишевое, то действительно, нужно целиться тогда на майнкрафт, гта и роблокс, не меньше.
Не очень понимаю ход твоих мыслей. Если в самых популярных играх нет тысяч юнитов, то и я должен сделать их мало или что? Что за бред.
>культовый феномен
Я не думаю, что пытаться искусственно вывести культовый феномен по лекалам тех, кто это смог - хорошая идея. Может лучше сделать игру, которая будет нравиться мне самому в первую очередь?
>>3676
Напомнить число отзывов пиксельной Terraria?
А ведь в Terraria и сотни мобов на экране нет...
При том у Terraria отзывы overwhelming positive.
Делой выводы @ делой игры.
>нищие 96к отзывов на англюсике (вери позитив)
Напомнить число отзывов пиксельной Terraria?
А ведь в Terraria и сотни мобов на экране нет...
При том у Terraria отзывы overwhelming positive.
Делой выводы @ делой игры.
>>3678
Нет, это просто значит, что тебе не нужны эти тысячи юнитов, чтоб сделать потенциально популярную игру. Конечно, ты можешь делать что угодно, просто такое количество не является обязательным условием.
Конечно, лучше. Но для этого не обязательно сидеть и дрочить байты на движке, который для такого рода мастурбации вообще не предназначен. Ты мог бы нарисовать намного больше спрайтов на голом SDL. Каждый дрочит как он хочет, и не нужно заставлять местных любителей дрочить GDScript переходить на альтернативы ради 10k одинаковых юнитов.
Так понятнее?
>Если в самых популярных играх нет тысяч юнитов, то и я должен сделать их мало или что?
Нет, это просто значит, что тебе не нужны эти тысячи юнитов, чтоб сделать потенциально популярную игру. Конечно, ты можешь делать что угодно, просто такое количество не является обязательным условием.
>Может лучше сделать игру, которая будет нравиться мне самому в первую очередь?
Конечно, лучше. Но для этого не обязательно сидеть и дрочить байты на движке, который для такого рода мастурбации вообще не предназначен. Ты мог бы нарисовать намного больше спрайтов на голом SDL. Каждый дрочит как он хочет, и не нужно заставлять местных любителей дрочить GDScript переходить на альтернативы ради 10k одинаковых юнитов.
Так понятнее?
>>3679
Никого сейчас не впечатлишь еще одной террарией.
Уникальная игра с кучей юнитов - выделяется на фоне других.
Никого сейчас не впечатлишь еще одной террарией.
Уникальная игра с кучей юнитов - выделяется на фоне других.
>>3684
НИКАВО НЕ УДИВИШЬ ОЧЕРЕДНОЙ ТЕРРАРИЕЙ
@
ОЧЕРЕДНОЙ СИМУЛЯТОР МОЧИ - ВОТ ЭТО ДА!!!
Таких симуляторов были сотни, и где они все теперь?
Нужно что-то помимо текущих потоков тупых NPC...
НИКАВО НЕ УДИВИШЬ ОЧЕРЕДНОЙ ТЕРРАРИЕЙ
@
ОЧЕРЕДНОЙ СИМУЛЯТОР МОЧИ - ВОТ ЭТО ДА!!!
Таких симуляторов были сотни, и где они все теперь?
Нужно что-то помимо текущих потоков тупых NPC...
>>3683
Я и слова плохого не сказал о gdscript тут и никого не призывал срочно бросить гдскрипт и перейти на шарпы. Я и сам на нём писал раньше, и был доволен.
Но сейчас под конкретно МОЮ текущую задачу мне понадобились другие инструменты, которых в гдскрипте нет, но при этом сам движок мне нравится. Поэтому я просто перешел на другие инструменты и сделал небольшой пост тут о том, что они рабочие.
>и не нужно заставлять местных любителей дрочить GDScript переходить на альтернативы ради 10k одинаковых юнитов
Я и слова плохого не сказал о gdscript тут и никого не призывал срочно бросить гдскрипт и перейти на шарпы. Я и сам на нём писал раньше, и был доволен.
Но сейчас под конкретно МОЮ текущую задачу мне понадобились другие инструменты, которых в гдскрипте нет, но при этом сам движок мне нравится. Поэтому я просто перешел на другие инструменты и сделал небольшой пост тут о том, что они рабочие.
>>3686
Технически нужно растянуть всего на два часа, чтобы заработанные деньги не возвращали. Для этого есть разные способы, катсцены, загрузочные экраны, туториал, постепенное добавление контента, карты попросторнее с большим расстояние которое надо сначала пройти.
Технически нужно растянуть всего на два часа, чтобы заработанные деньги не возвращали. Для этого есть разные способы, катсцены, загрузочные экраны, туториал, постепенное добавление контента, карты попросторнее с большим расстояние которое надо сначала пройти.
>>3690
Таким пидарасам как ты на 59й минуте второго часа рефандят. Уёбок.
Таким пидарасам как ты на 59й минуте второго часа рефандят. Уёбок.
А что думаете о F2P + donate/cosmetic DLC?
Как по мне, это имеет массу преимуществ:
- пираты и дети могут играть с остальной фанбазой;
- желающие задонатить побольше могут это сделать;
- покупателю не придётся ничего никому возвращать;
- доверительные отношения, ведь нет обязательств;
- легче получить новые взносы от старых игроков.
Основной минус - в отзывы насрать проще.
Но ненужный ассетфлип так не продашь...
И есть какие-то предрассудки (?) о F2P...
Как по мне, это имеет массу преимуществ:
- пираты и дети могут играть с остальной фанбазой;
- желающие задонатить побольше могут это сделать;
- покупателю не придётся ничего никому возвращать;
- доверительные отношения, ведь нет обязательств;
- легче получить новые взносы от старых игроков.
Основной минус - в отзывы насрать проще.
Но ненужный ассетфлип так не продашь...
И есть какие-то предрассудки (?) о F2P...
>>3718
Если ты просто будешь регулярно обновлять свою игру, то пиратить её будет уже неудобно. Вдвойне если прикрутишь воркшоп. А cosmetic DLC это кал, который актуален в основном если у тебя мультиплеер и ты сервак держишь. Если делать dlc, то хорошие.
Если ты просто будешь регулярно обновлять свою игру, то пиратить её будет уже неудобно. Вдвойне если прикрутишь воркшоп. А cosmetic DLC это кал, который актуален в основном если у тебя мультиплеер и ты сервак держишь. Если делать dlc, то хорошие.
Ещё про f2p - есть такая психология лично у меня, что в халявные игры я играю меньше, чем в то за что уплочено. Это не считая сессионок всяких.
43 Кб, 360x640>>3719
Кхм...
Кхм...
>>3659
Ну, как по мне, написать модуль движка проще, чем gdextension. Я попробовал то и другое где-то год назад. Но это личные впечатления, да и в плюсах я тогда понимал сильно меньше, чем сейчас.
>>3671
Ну кстати да, это фича SCons. Вообще, жаль, что эту систему сборки поддерживает так мало ИДЕ, она пиздатая. Ну уж точно лучше, чем cmake.
Ну, как по мне, написать модуль движка проще, чем gdextension. Я попробовал то и другое где-то год назад. Но это личные впечатления, да и в плюсах я тогда понимал сильно меньше, чем сейчас.
>>3671
>В-третьих
Ну кстати да, это фича SCons. Вообще, жаль, что эту систему сборки поддерживает так мало ИДЕ, она пиздатая. Ну уж точно лучше, чем cmake.
>>3760
С чего ты такой вывод сделал? смаке проект тоже на разбивается на отдельные модули
cmake_minimum_required(VERSION 3.15)
project(MyProject)
add_subdirectory(module_a)
add_subdirectory(module_b)
add_executable(app main.cpp)
target_link_libraries(app PRIVATE module_a module_b)
>Ну кстати да, это фича SCons.
С чего ты такой вывод сделал? смаке проект тоже на разбивается на отдельные модули
cmake_minimum_required(VERSION 3.15)
project(MyProject)
add_subdirectory(module_a)
add_subdirectory(module_b)
add_executable(app main.cpp)
target_link_libraries(app PRIVATE module_a module_b)
>>3762
да и вообще вроде системы сборки в плюсах следят за изменениями зависимостей единиц трансляции, а не "модулей". Перекомпиляция зависящей единицы трансляции будет если заголовочные файлы в зависимостях изменились. Если изменился cpp файл зависимости, без изменения hpp то перекомпиляции каскадной не будет
да и вообще вроде системы сборки в плюсах следят за изменениями зависимостей единиц трансляции, а не "модулей". Перекомпиляция зависящей единицы трансляции будет если заголовочные файлы в зависимостях изменились. Если изменился cpp файл зависимости, без изменения hpp то перекомпиляции каскадной не будет
>>3764
Ну да, в этом и смысл хедеров, хедеры это же интерфейс. Если интерфейс не изменился, то внутренняя реализация никак не повлияет на остальное окружение, это и есть инкапсуляция.
Ну да, в этом и смысл хедеров, хедеры это же интерфейс. Если интерфейс не изменился, то внутренняя реализация никак не повлияет на остальное окружение, это и есть инкапсуляция.
Вопрос не совсем релейтед конкретно к движку треда, но тем не менее: уважаемые годотстеры, как вы считаете, почему нынче инди двадэ а порой и тридэ кал а-ля "моя первая игра" у русскоязычных хз как за кордоном, мб так же дэуэлоперов это в большинстве случаев обязательно ХОРРОР? Вне зависимости от жанра, будь то ВНка, бродилка, перделка, стрелялка, и ещё любят пиздануть слово ПСИХОЛОГИЧЕСКИЙ?
Смотрю вот эти изделия игросодержащие, ну графоний/спрайты понятное дело хуета уровня каляки-маляки пятиклашки в пэйнте. Потом захожу на страницу к разрабу: там среднестатистический заводчанин 35+, проживающий где-нибудь в центральной России, нередко женатик, а то и с детьми.
Что это за особая прослойка мрачных психологов такая? Почему они так любят инди двадэ хорроры (которые вызывают не столько страх, сколько кринж). Поколение читателей Стивена Кинга?
И кто вообще в такое играет кроме самих энтих разрабов и их внутреннего круга из 5 человек?
Смотрю вот эти изделия игросодержащие, ну графоний/спрайты понятное дело хуета уровня каляки-маляки пятиклашки в пэйнте. Потом захожу на страницу к разрабу: там среднестатистический заводчанин 35+, проживающий где-нибудь в центральной России, нередко женатик, а то и с детьми.
Что это за особая прослойка мрачных психологов такая? Почему они так любят инди двадэ хорроры (которые вызывают не столько страх, сколько кринж). Поколение читателей Стивена Кинга?
И кто вообще в такое играет кроме самих энтих разрабов и их внутреннего круга из 5 человек?
>>3804
Хоррор проще слепить и продать обывателю.
Хоррор проще слепить и продать обывателю.
>>3804
Продается потому что
>>3811
Спокойно вон поляк уже вполне успешно 3 раза почти одно и тоже продает
А имя студии отсылает к дедам
https://store.steampowered.com/search/?developer=Harvester%20Games
Продается потому что
>>3811
Спокойно вон поляк уже вполне успешно 3 раза почти одно и тоже продает
А имя студии отсылает к дедам
https://store.steampowered.com/search/?developer=Harvester%20Games
>>3804
Сколько тебе лет, 13? С подключением! Инди-хорроры сохраняют свою популярность с нулевых, когда там индюшатинка начала развиваться на движках для нормисов. Многие старые движки уже умерли, а жанр продолжает жить, потому что он просто бесконечный.
Хоррор сделать относительно легко, потому что в нём важнее всего создать эмоции, а на качество графики, озвучки и глубину геймплея наплевать. Для людей естественно бояться темноты, а в темноте попробуй отличить плохую графику от хорошей; шум, треск и остальные дефекты звука - это плюс, а не минус; для геймплея достаточно ходить и тыкаться в кнопки... Монстров нарисовать на порядки проще, чем что-то красивое, буквально любой новичок может взять и нарисовать или смоделировать что-то мерзкое. Даже упоротые анимации - плюс, а не минус для хоррора.
Но самое главное в жанре хоррора - это отсутствие реиграбельности. Люди много чего могут бояться на протяжении всей жизни, но ты не можешь пройти классический хоррор второй раз и напугаться как в первый раз. Допустим, ты боишься темноты, но ты боишься, на самом деле, неизвестности - того, что способно скрываться в темноте. Пройдя игру, ты уже знаешь, какие там монстры или про их отсутствие, и прежнего уровня страха от этой игры уже не будет.
Но от другой, новой игры? Ты будешь бояться снова, практически как с первой игрой, ведь новая, даже с аналогичной графикой, геймплеем и т.д., таит в себе неизвестность. Ты не потерял страх темноты, и ты не знаешь, что тебя ждёт в новой игре. Поэтому можно проходить тысячи инди-хорроров и это тебе не будет надоедать, в отличие от многих других жанров игр.
Вкратце:
- создать легко => низкий порог входа;
- нет реиграбельности => ниша ненасытна.
Для сравнения, жанры с высокой реиграбельностью насыщаются очень быстро и поэтому в них высокая конкуренция за игроков; например, бестолку делать собственный аналог Minecraft или Terraria, если ты копируешь их слишком сильно - игроку нет никакого интереса играть в твою игру, когда они могут влить следующие 5000 часов в старую игру и получить удовольствие на уровне предыдущих 15000 часов. Оригинальную игру в том же жанре сделать можно, однако, это намного сложнее из-за более высоких требований как к графике, так и к геймплею, и т.д.
Поэтому многие выбирают жанр хоррора.
>нынче
>ХОРРОР
Сколько тебе лет, 13? С подключением! Инди-хорроры сохраняют свою популярность с нулевых, когда там индюшатинка начала развиваться на движках для нормисов. Многие старые движки уже умерли, а жанр продолжает жить, потому что он просто бесконечный.
Хоррор сделать относительно легко, потому что в нём важнее всего создать эмоции, а на качество графики, озвучки и глубину геймплея наплевать. Для людей естественно бояться темноты, а в темноте попробуй отличить плохую графику от хорошей; шум, треск и остальные дефекты звука - это плюс, а не минус; для геймплея достаточно ходить и тыкаться в кнопки... Монстров нарисовать на порядки проще, чем что-то красивое, буквально любой новичок может взять и нарисовать или смоделировать что-то мерзкое. Даже упоротые анимации - плюс, а не минус для хоррора.
Но самое главное в жанре хоррора - это отсутствие реиграбельности. Люди много чего могут бояться на протяжении всей жизни, но ты не можешь пройти классический хоррор второй раз и напугаться как в первый раз. Допустим, ты боишься темноты, но ты боишься, на самом деле, неизвестности - того, что способно скрываться в темноте. Пройдя игру, ты уже знаешь, какие там монстры или про их отсутствие, и прежнего уровня страха от этой игры уже не будет.
Но от другой, новой игры? Ты будешь бояться снова, практически как с первой игрой, ведь новая, даже с аналогичной графикой, геймплеем и т.д., таит в себе неизвестность. Ты не потерял страх темноты, и ты не знаешь, что тебя ждёт в новой игре. Поэтому можно проходить тысячи инди-хорроров и это тебе не будет надоедать, в отличие от многих других жанров игр.
Вкратце:
- создать легко => низкий порог входа;
- нет реиграбельности => ниша ненасытна.
Для сравнения, жанры с высокой реиграбельностью насыщаются очень быстро и поэтому в них высокая конкуренция за игроков; например, бестолку делать собственный аналог Minecraft или Terraria, если ты копируешь их слишком сильно - игроку нет никакого интереса играть в твою игру, когда они могут влить следующие 5000 часов в старую игру и получить удовольствие на уровне предыдущих 15000 часов. Оригинальную игру в том же жанре сделать можно, однако, это намного сложнее из-за более высоких требований как к графике, так и к геймплею, и т.д.
Поэтому многие выбирают жанр хоррора.
>>3804
Сколько тебе лет, 13? С подключением! Инди-хорроры сохраняют свою популярность с нулевых, когда там индюшатинка начала развиваться на движках для нормисов. Многие старые движки уже умерли, а жанр продолжает жить, потому что он просто бесконечный.
Хоррор сделать относительно легко, потому что в нём важнее всего создать эмоции, а на качество графики, озвучки и глубину геймплея наплевать. Для людей естественно бояться темноты, а в темноте попробуй отличить плохую графику от хорошей; шум, треск и остальные дефекты звука - это плюс, а не минус; для геймплея достаточно ходить и тыкаться в кнопки... Монстров нарисовать на порядки проще, чем что-то красивое, буквально любой новичок может взять и нарисовать или смоделировать что-то мерзкое. Даже упоротые анимации - плюс, а не минус для хоррора.
Но самое главное в жанре хоррора - это отсутствие реиграбельности. Люди много чего могут бояться на протяжении всей жизни, но ты не можешь пройти классический хоррор второй раз и напугаться как в первый раз. Допустим, ты боишься темноты, но ты боишься, на самом деле, неизвестности - того, что способно скрываться в темноте. Пройдя игру, ты уже знаешь, какие там монстры или про их отсутствие, и прежнего уровня страха от этой игры уже не будет.
Но от другой, новой игры? Ты будешь бояться снова, практически как с первой игрой, ведь новая, даже с аналогичной графикой, геймплеем и т.д., таит в себе неизвестность. Ты не потерял страх темноты, и ты не знаешь, что тебя ждёт в новой игре. Поэтому можно проходить тысячи инди-хорроров и это тебе не будет надоедать, в отличие от многих других жанров игр.
Вкратце:
- создать легко => низкий порог входа;
- нет реиграбельности => ниша ненасытна.
Для сравнения, жанры с высокой реиграбельностью насыщаются очень быстро и поэтому в них высокая конкуренция за игроков; например, бестолку делать собственный аналог Minecraft или Terraria, если ты копируешь их слишком сильно - игроку нет никакого интереса играть в твою игру, когда они могут влить следующие 5000 часов в старую игру и получить удовольствие на уровне предыдущих 15000 часов. Оригинальную игру в том же жанре сделать можно, однако, это намного сложнее из-за более высоких требований как к графике, так и к геймплею, и т.д.
Поэтому многие выбирают жанр хоррора.
>нынче
>ХОРРОР
Сколько тебе лет, 13? С подключением! Инди-хорроры сохраняют свою популярность с нулевых, когда там индюшатинка начала развиваться на движках для нормисов. Многие старые движки уже умерли, а жанр продолжает жить, потому что он просто бесконечный.
Хоррор сделать относительно легко, потому что в нём важнее всего создать эмоции, а на качество графики, озвучки и глубину геймплея наплевать. Для людей естественно бояться темноты, а в темноте попробуй отличить плохую графику от хорошей; шум, треск и остальные дефекты звука - это плюс, а не минус; для геймплея достаточно ходить и тыкаться в кнопки... Монстров нарисовать на порядки проще, чем что-то красивое, буквально любой новичок может взять и нарисовать или смоделировать что-то мерзкое. Даже упоротые анимации - плюс, а не минус для хоррора.
Но самое главное в жанре хоррора - это отсутствие реиграбельности. Люди много чего могут бояться на протяжении всей жизни, но ты не можешь пройти классический хоррор второй раз и напугаться как в первый раз. Допустим, ты боишься темноты, но ты боишься, на самом деле, неизвестности - того, что способно скрываться в темноте. Пройдя игру, ты уже знаешь, какие там монстры или про их отсутствие, и прежнего уровня страха от этой игры уже не будет.
Но от другой, новой игры? Ты будешь бояться снова, практически как с первой игрой, ведь новая, даже с аналогичной графикой, геймплеем и т.д., таит в себе неизвестность. Ты не потерял страх темноты, и ты не знаешь, что тебя ждёт в новой игре. Поэтому можно проходить тысячи инди-хорроров и это тебе не будет надоедать, в отличие от многих других жанров игр.
Вкратце:
- создать легко => низкий порог входа;
- нет реиграбельности => ниша ненасытна.
Для сравнения, жанры с высокой реиграбельностью насыщаются очень быстро и поэтому в них высокая конкуренция за игроков; например, бестолку делать собственный аналог Minecraft или Terraria, если ты копируешь их слишком сильно - игроку нет никакого интереса играть в твою игру, когда они могут влить следующие 5000 часов в старую игру и получить удовольствие на уровне предыдущих 15000 часов. Оригинальную игру в том же жанре сделать можно, однако, это намного сложнее из-за более высоких требований как к графике, так и к геймплею, и т.д.
Поэтому многие выбирают жанр хоррора.
>>3804
Хорроры и порнуха вызывают одинаково аддиктивные эмоции. Об этом еще на форумах интернета 1.0 писали.
Хорроры и порнуха вызывают одинаково аддиктивные эмоции. Об этом еще на форумах интернета 1.0 писали.
>>3836 (Del)
Я выкладываю игры только на имиджбордах
Я выкладываю игры только на имиджбордах
>>3834
Мне показалось
И я уже хотел написать про Вселенную-наоборот, но потом перечитал внимательнее.
Но вообще да, во Вселенной-наоборот с толщеходами есть хоррорный элемент. Тёмные полости с погасшим ядром заселяются слепыми хищниками, которые ориентируются на шум, охотятся стаями. Хрен убежишь. Догонят и выебут. Вот вам и хоррорпрон.
Мне показалось
> порноходы
И я уже хотел написать про Вселенную-наоборот, но потом перечитал внимательнее.
Но вообще да, во Вселенной-наоборот с толщеходами есть хоррорный элемент. Тёмные полости с погасшим ядром заселяются слепыми хищниками, которые ориентируются на шум, охотятся стаями. Хрен убежишь. Догонят и выебут. Вот вам и хоррорпрон.
>>3824
Касательно слова "нынче" это я спизданул к тому, что сам начал подмечать тенденцию к засилью подобного у новичков именно ближе годов с 20х. Раньше дофига было платформеров, их и сейчас дофига, но уже как будто не модно, моднявее сделать жуууткую новелку, или бродилку по жопе негра с фонариком. Если в тридэ — всё те же бессменные вариации на тему слендермена с записками в лесу.
Вот годах в 10-20х, особенно в первой половине я видел тенденцию к платформерам с "фишкой", какая-нибудь там гравитация, отмотка времени, паззлы/головоломки по типу VVVVVV. Или там копалки-подземки по лекалам Spelunky/Steamworld Dig. Плюс ко всему артстайл в эту эпоху расцвета миллениалов был какой-то с позитивом, надеждой, все эти улыбчивые мордочки Джамп Гаев, Шот Гаев, Иван Гаев, придурошно, но по доброму, и без "у-у-у, ужастег псехологея".
Может это чисто персональное восприятие, но как правило на смену парадигмы среди сообществ людей у меня чуйка натаскана.
Суть ответов ясна: "просто сделать + сложно проебаться". Надеялся, конечно, что это всё же не от того, что народ выбирает путь наименьшего сопротивления, а скорее какая-то мода/повестка/тренды/ситуация в мире. Но спорить с мнениями не буду.
>>3825
Интересно. Я всегда осознавал, что sex sells, но вот конкретно хорроры думал более нишевая шняга. Сам то я их стороной обхожу просто, наигрался в нулевых во всякие калл оф ктулху, скрэтчес, и понял, что революции в жанре не будет, а жрать старое под новым соусом — нахуй надо. Из последнего заценил уже считающийся "старой игрой" алиен изолейшен, ну да, прикольно, попрятаться под столами. Но в целом тягомотина же, нудятина. Хз, не получаю видать тех же эмоций, что другие пиплы от чувства страха. Лучше уж книженцию какую почитать, так иммерсия в 10 раз интенсивнее.
Касательно слова "нынче" это я спизданул к тому, что сам начал подмечать тенденцию к засилью подобного у новичков именно ближе годов с 20х. Раньше дофига было платформеров, их и сейчас дофига, но уже как будто не модно, моднявее сделать жуууткую новелку, или бродилку по жопе негра с фонариком. Если в тридэ — всё те же бессменные вариации на тему слендермена с записками в лесу.
Вот годах в 10-20х, особенно в первой половине я видел тенденцию к платформерам с "фишкой", какая-нибудь там гравитация, отмотка времени, паззлы/головоломки по типу VVVVVV. Или там копалки-подземки по лекалам Spelunky/Steamworld Dig. Плюс ко всему артстайл в эту эпоху расцвета миллениалов был какой-то с позитивом, надеждой, все эти улыбчивые мордочки Джамп Гаев, Шот Гаев, Иван Гаев, придурошно, но по доброму, и без "у-у-у, ужастег псехологея".
Может это чисто персональное восприятие, но как правило на смену парадигмы среди сообществ людей у меня чуйка натаскана.
Суть ответов ясна: "просто сделать + сложно проебаться". Надеялся, конечно, что это всё же не от того, что народ выбирает путь наименьшего сопротивления, а скорее какая-то мода/повестка/тренды/ситуация в мире. Но спорить с мнениями не буду.
>>3825
Интересно. Я всегда осознавал, что sex sells, но вот конкретно хорроры думал более нишевая шняга. Сам то я их стороной обхожу просто, наигрался в нулевых во всякие калл оф ктулху, скрэтчес, и понял, что революции в жанре не будет, а жрать старое под новым соусом — нахуй надо. Из последнего заценил уже считающийся "старой игрой" алиен изолейшен, ну да, прикольно, попрятаться под столами. Но в целом тягомотина же, нудятина. Хз, не получаю видать тех же эмоций, что другие пиплы от чувства страха. Лучше уж книженцию какую почитать, так иммерсия в 10 раз интенсивнее.
>>3825
Никогда не любил хорроры. От слова совсем. Зато люблю порноигры. Не похоже на что-то общее.
Никогда не любил хорроры. От слова совсем. Зато люблю порноигры. Не похоже на что-то общее.
92 Кб, 2030x2030>>3804
Я вижу больше 3д хорроров, чем 2д, но я слежу за зарубежьем. Пс1 стайл лоуполи с кое как сделанными моделями и текстурами это первый законченный проект и многих инди девов. AlphaBetaGamer канал на ютубе, там такого полно.
Я вижу больше 3д хорроров, чем 2д, но я слежу за зарубежьем. Пс1 стайл лоуполи с кое как сделанными моделями и текстурами это первый законченный проект и многих инди девов. AlphaBetaGamer канал на ютубе, там такого полно.
>>3938
Ламар!? Ты куда опять сбежала? Прыгай мне на лысину. Вот так, моя девочка.
Ламар!? Ты куда опять сбежала? Прыгай мне на лысину. Вот так, моя девочка.
>>3719
Моды убьют твою игру. Посмотри как сделал стоншард. Они около 7-9 лет пилят разжиревшую полудемку, меняют цифры стат местами (как в патчах доты) и запиливают буквально одну-две механики или персонажа.
Был бы вагон модов и контента, они не смогли такими малыми силами доить корову почти 10 лет.
Пришлось бы делать реально жырные патчи или DLS (то есть реально работать), чтобы конкурировать с обилием модов. А так люди праще радуются (что по механике копия лука) или новому персонажу (просто арт с другими статами).
>Вдвойне если прикрутишь воркшоп.
Моды убьют твою игру. Посмотри как сделал стоншард. Они около 7-9 лет пилят разжиревшую полудемку, меняют цифры стат местами (как в патчах доты) и запиливают буквально одну-две механики или персонажа.
Был бы вагон модов и контента, они не смогли такими малыми силами доить корову почти 10 лет.
Пришлось бы делать реально жырные патчи или DLS (то есть реально работать), чтобы конкурировать с обилием модов. А так люди праще радуются (что по механике копия лука) или новому персонажу (просто арт с другими статами).
>>3997 (Del)
Там "стремящийся" к какому-то значению тик, но он никогда не бывает "стабильным", даже в вакууме, поэтому дельта всегда имеет смысл.
Там "стремящийся" к какому-то значению тик, но он никогда не бывает "стабильным", даже в вакууме, поэтому дельта всегда имеет смысл.
>>4001 (Del)
А ее так сложно использовать, что хочется забить? Обычно же она нужна как доп коэффициент в формулах всяких и все.
А ее так сложно использовать, что хочется забить? Обычно же она нужна как доп коэффициент в формулах всяких и все.
>>3400 (OP)
А в годо можно делать стратежки без графики, ну типа как в экселе?
А в годо можно делать стратежки без графики, ну типа как в экселе?
>>4014
А в экселе же таблица с ячейками - это же графика. Ты же меня обманываешь. Без графики - это в консольке.
А в экселе же таблица с ячейками - это же графика. Ты же меня обманываешь. Без графики - это в консольке.
>>4019
В консольке такие чудеса вытворять можно - эксель позавидует.
Хочешь без графики - деды до появления мониторов печатали вывод на листках бумаги.
В консольке такие чудеса вытворять можно - эксель позавидует.
Хочешь без графики - деды до появления мониторов печатали вывод на листках бумаги.
>>4019
Так у меня пока игра в консольке. Хочу вот перейти на новый уровень
Так у меня пока игра в консольке. Хочу вот перейти на новый уровень
>>4021
Да, а ввод на перфокартах. Что-то сразу захотелось запилить игру с эмуляцией всего этого. Ну, перфокарты можно камерой считывать
Да, а ввод на перфокартах. Что-то сразу захотелось запилить игру с эмуляцией всего этого. Ну, перфокарты можно камерой считывать
В итоге получился вот такой снак.
Невыносимо медленный при движении по таймеру.
Но можно ускорить.
Но отзывчивый при нажатии клавиш.
Без диагонального движения.
Со встроенным детектом самопересечений, стен, еды.
Создающий себе сегменты в реалтайме.
Ща как доделаю игру! Уххх, ща как доделаю!
Невыносимо медленный при движении по таймеру.
Но можно ускорить.
Но отзывчивый при нажатии клавиш.
Без диагонального движения.
Со встроенным детектом самопересечений, стен, еды.
Создающий себе сегменты в реалтайме.
Ща как доделаю игру! Уххх, ща как доделаю!
>>4028
Я думал спецолимпиада закончилась еще в прошлом треде. А в чем сложности то?
Я думал спецолимпиада закончилась еще в прошлом треде. А в чем сложности то?
53 Кб, 273x185>>4001 (Del)
Если игрок нажмет кнопку турбо, вся физика посыпиться
олды сплакнут
Намечается новый холивар - дельта не нужна, дельта для слабых.
Если игрок нажмет кнопку турбо, вся физика посыпиться
олды сплакнут
Намечается новый холивар - дельта не нужна, дельта для слабых.
>>4028
Это какая-то форма мазохизма? Что мешает с нейронкой слепить за пару часов? Ещё и сегменты не инстансишь.
Это какая-то форма мазохизма? Что мешает с нейронкой слепить за пару часов? Ещё и сегменты не инстансишь.
>>4037
Плавная змейека теряет ретрошарм. А так же смысл - гораздо проще избегать столкновений, если ты можешь маняврировать как угодно, а не только в четыре стороны. Это уже не змейка короче будет, а другая игра какаято. Алсо, хз как на твоем скрине на самом деле сделано, но на вид эти черви тоже сегментирорванные, просто кружочками для гибкости.
Плавная змейека теряет ретрошарм. А так же смысл - гораздо проще избегать столкновений, если ты можешь маняврировать как угодно, а не только в четыре стороны. Это уже не змейка короче будет, а другая игра какаято. Алсо, хз как на твоем скрине на самом деле сделано, но на вид эти черви тоже сегментирорванные, просто кружочками для гибкости.
>>4039
Саморазвитие - это больно. Саморазвитие легко спутать с мазохизмом, потому что и там больно и тут.
Потому что с нейронкой ты так и останешься неразвитым. Вместо тебя разовьётся нейронка.
Инстансиш.
> Это какая-то форма мазохизма?
Саморазвитие - это больно. Саморазвитие легко спутать с мазохизмом, потому что и там больно и тут.
> Что мешает с нейронкой слепить за пару часов?
Потому что с нейронкой ты так и останешься неразвитым. Вместо тебя разовьётся нейронка.
> Ещё и сегменты не инстансишь.
Инстансиш.
>>4028
Ты троллишь так? Троллишь ведь? Нафига ты туда эти Area2D лепишь? Чтоб процессор пользователя греть? Создавать ощущение бурной деятельности игры? Чтоб казалось, будто игра на фоне крипту майнит? Тебе уже скинули базовый код классической змейки, которая по клеточкам ходит, чем ты недоволен-то? Или ты хочешь сделать змейко-платформер, как сейчас модно стало?.. Тогда тебе нужно CharacterBody2D вместо Area2D, лол.
>>4040
Тогда зачем ты обмазывался Area2D, ретрофил?
>>4042
Да ты ж наговнокодил просто. В чём саморазвитие?
>>3997 (Del)
Для каких-нибудь строгих симуляций в мультиплеере. Физика может отставать, особенно если компьютер не вытягивает 60 FPS по процессору (не по видеокарте), поэтому установленные в настройках TPS физики не гарантируются. Почитай всплывающие подсказки в настройках проекта, касающиеся настроек физики. Тестируй игру с открытым профайлером или выводи информацию из API Performance на экран в игре...
>>4014
Можно, конечно. Можно использовать Control-ноды. Учитывай, правда, что Control-ноды рендерятся через кастомный OpenGL/Vulkan/DirectX/Metal-рендерер в зависимости от платформы и настроек проекта, а не встроенным в операционку набором виджетов, т.е. взаимодействие с ОС отличается от классического, и некоторые фичи, возможно, ещё не поддерживаются.
Вот тут о том, как юзать Godot для GUI приложений:
https://docs.godotengine.org/en/stable/tutorials/ui/creating_applications.html
Но учитывай, что, хотя 3D фишки можно вырезать из движка, 2D фишки пока что не так легко вырезаются. Поэтому сделать Godot максимально тонким трудно.
Ты троллишь так? Троллишь ведь? Нафига ты туда эти Area2D лепишь? Чтоб процессор пользователя греть? Создавать ощущение бурной деятельности игры? Чтоб казалось, будто игра на фоне крипту майнит? Тебе уже скинули базовый код классической змейки, которая по клеточкам ходит, чем ты недоволен-то? Или ты хочешь сделать змейко-платформер, как сейчас модно стало?.. Тогда тебе нужно CharacterBody2D вместо Area2D, лол.
>>4040
>Плавная змейека теряет ретрошарм
Тогда зачем ты обмазывался Area2D, ретрофил?
>>4042
>Саморазвитие
Да ты ж наговнокодил просто. В чём саморазвитие?
>>3997 (Del)
>Зачем тогда там вообще дельта передается?
Для каких-нибудь строгих симуляций в мультиплеере. Физика может отставать, особенно если компьютер не вытягивает 60 FPS по процессору (не по видеокарте), поэтому установленные в настройках TPS физики не гарантируются. Почитай всплывающие подсказки в настройках проекта, касающиеся настроек физики. Тестируй игру с открытым профайлером или выводи информацию из API Performance на экран в игре...
>>4014
>А в годо можно делать стратежки без графики
Можно, конечно. Можно использовать Control-ноды. Учитывай, правда, что Control-ноды рендерятся через кастомный OpenGL/Vulkan/DirectX/Metal-рендерер в зависимости от платформы и настроек проекта, а не встроенным в операционку набором виджетов, т.е. взаимодействие с ОС отличается от классического, и некоторые фичи, возможно, ещё не поддерживаются.
Вот тут о том, как юзать Godot для GUI приложений:
https://docs.godotengine.org/en/stable/tutorials/ui/creating_applications.html
Но учитывай, что, хотя 3D фишки можно вырезать из движка, 2D фишки пока что не так легко вырезаются. Поэтому сделать Godot максимально тонким трудно.
>>4049
Я другой шиз, не путай нас.
>>4048 (Del)
Просто нужно фокусироваться на одной фиче/баге, не растекаясь по всему проекту хаотичными правками, и описывать тогда будет нечего.
А зачем тебе гит? Откатываешься часто?
Я другой шиз, не путай нас.
>>4048 (Del)
>fix1 fix2 update123
Просто нужно фокусироваться на одной фиче/баге, не растекаясь по всему проекту хаотичными правками, и описывать тогда будет нечего.
А зачем тебе гит? Откатываешься часто?
145 Кб, mp4,568x320, 0:33
>>4051
Я без гита впринципе даже тестовые заметки не веду. Не только профдеформация, но и жизнь в условиях умирающего ссд на протяжении пары лет. Хз как вы игры делаете без гита, лишняя хромосма помогает?
Ну а с нейронками это просто необходимо - это говно легкой рукой сметает к хуям хоть весь код в процессе, если надо. Поправит то, попробует там, и вот хуяк уже ихз рабочей версии полностью нерабочая - гитом откатить можно. Еще она и гит можно смести к хуям, да, как-то раз мне просто сделала гит резет хард на 10 коммитов назад, это правда восстанавливается, но так и поседеть можно, так что гитовать надо не только локально, но и на ремоты обязательно слать.
Ну и дляценителей, конечно же, относится в целом не к гиту именно, а к любым контролям версий, извращайтесь как хотите для тех же целей, хуле нет, хотя ручной бекап это пиздец, лол.
Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
>А зачем тебе гит? Откатываешься часто?
Я без гита впринципе даже тестовые заметки не веду. Не только профдеформация, но и жизнь в условиях умирающего ссд на протяжении пары лет. Хз как вы игры делаете без гита, лишняя хромосма помогает?
Ну а с нейронками это просто необходимо - это говно легкой рукой сметает к хуям хоть весь код в процессе, если надо. Поправит то, попробует там, и вот хуяк уже ихз рабочей версии полностью нерабочая - гитом откатить можно. Еще она и гит можно смести к хуям, да, как-то раз мне просто сделала гит резет хард на 10 коммитов назад, это правда восстанавливается, но так и поседеть можно, так что гитовать надо не только локально, но и на ремоты обязательно слать.
Ну и дляценителей, конечно же, относится в целом не к гиту именно, а к любым контролям версий, извращайтесь как хотите для тех же целей, хуле нет, хотя ручной бекап это пиздец, лол.
Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
>>4063
Уж лучше бы тебе нейронка нормальный алгоритм сгенерировала, чем вот это вот говнокодерство. Специально для таких как ты костыли сделали.
Ага, и будет говнокод в красивом фантике.
>>4057 (Del)
У тебя 5 гигов кода? Или всё-таки арта? Арт не нужно бэкапить, когда с кодом работаешь. А код правится маленькими частями в отдельных папках...
Вообще, тоже подумываю подключить какую-нибудь подходящую VCS, но всё боюсь, что она сломается и поломает мне все файлы. А бэкапы пока ни разу не пригодились по сути, потому что я никогда назад не возвращаюсь из принципа. Если не идти вперёд, а возвращаться назад, то в чём тогда будет прогресс? Сохраняю бэкапы только на случай поломки диска.
>>4068
Какая хромосома заставляет тебя юзать нейронки?
Зачем откатывать то, что можно просто не ломать?
Зато никакая нейронка не влезет и не сломает, ибо архиватор древней версии и надёжен как часы. А гит наверняка уже заслопили мартышки из майкрософт.
Уж лучше бы тебе нейронка нормальный алгоритм сгенерировала, чем вот это вот говнокодерство. Специально для таких как ты костыли сделали.
>пусть мне арт рисует
Ага, и будет говнокод в красивом фантике.
>>4057 (Del)
>перед каждой фичей бекапить 5 гигов
У тебя 5 гигов кода? Или всё-таки арта? Арт не нужно бэкапить, когда с кодом работаешь. А код правится маленькими частями в отдельных папках...
Вообще, тоже подумываю подключить какую-нибудь подходящую VCS, но всё боюсь, что она сломается и поломает мне все файлы. А бэкапы пока ни разу не пригодились по сути, потому что я никогда назад не возвращаюсь из принципа. Если не идти вперёд, а возвращаться назад, то в чём тогда будет прогресс? Сохраняю бэкапы только на случай поломки диска.
>>4068
>лишняя хромосма помогает?
>с нейронками это просто необходимо
Какая хромосома заставляет тебя юзать нейронки?
>полностью нерабочая - гитом откатить можно
Зачем откатывать то, что можно просто не ломать?
>хотя ручной бекап это пиздец, лол.
Зато никакая нейронка не влезет и не сломает, ибо архиватор древней версии и надёжен как часы. А гит наверняка уже заслопили мартышки из майкрософт.
>>4069
Гит != гитхаб, балбес. Ну и юзай другие, их полно, раз гит вдруг стал майковским.
Да она просто рм сделает под предлогом чистки мусора.
Дежурный луддит, добрый вечер, как на бересте пишется?
Нейронки не то чтобы именно ломают (разве что удаляют они почему-то слишком уж бездумно, наплевав на то, что могут и не восстановить уже), просто не все их высеры стоят того, чтобы их доводить до конца. После работы нейрослопа всегда надо старательно напильником обрабатывать, иногда проще откатываться, чем вникать в очевидный сгенерированный бред, даже если он рабочий. Для них это все равно быстро. Даже слишком. Собственно из-за скорости нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью.
Ну понятненько. Ты у нас и гит не признаешь, дьвольские технологии. И нейронки тоже. Луддит бинго? Че там дальше - отрицание 4к мониторов?
>А гит наверняка уже заслопили мартышки из майкрософт.
Гит != гитхаб, балбес. Ну и юзай другие, их полно, раз гит вдруг стал майковским.
>Зато никакая нейронка не влезет и не сломает
Да она просто рм сделает под предлогом чистки мусора.
>Какая хромосома заставляет тебя юзать нейронки?
Дежурный луддит, добрый вечер, как на бересте пишется?
>Зачем откатывать то, что можно просто не ломать?
Нейронки не то чтобы именно ломают (разве что удаляют они почему-то слишком уж бездумно, наплевав на то, что могут и не восстановить уже), просто не все их высеры стоят того, чтобы их доводить до конца. После работы нейрослопа всегда надо старательно напильником обрабатывать, иногда проще откатываться, чем вникать в очевидный сгенерированный бред, даже если он рабочий. Для них это все равно быстро. Даже слишком. Собственно из-за скорости нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью.
Ну понятненько. Ты у нас и гит не признаешь, дьвольские технологии. И нейронки тоже. Луддит бинго? Че там дальше - отрицание 4к мониторов?
912 Кб, 1024x572>>4076 (Del)
Да все дружелюбно епта.
Да все дружелюбно епта.
>>4071 (Del)
В архиваторах можно настроить фильтры. Я просто исключил из архива все .png, .gltf и т.п. тяжести, что практически никогда не меняются, и в итоге бэкапы составляют всего несколько килобайт файлов, что изменились за сегодня (фильтр по времени). И это практически не занимает времени, всего 3-4 клика. Автоматически добавляется штамп времени и т.п. Перекатываться на кривоватый гит как-то лениво...
>>4072
Ну, не будешь же ты свой сервер арендовать...
Она-то сделает, но запустил её ты. Виновен ты.
Я не луддит, а как раз фанат ИИ технологий, и именно поэтому знаю, что нейронки на базе GPT используют тупейшие мартышки и скучающие лузеры по жизни, поскольку полагаться на этот чёрный ящик с мутной историей тренировки нельзя, а ТЕМ БОЛЕЕ запускать автономно на железе, которое тебе дорого и имеет собственный доступ в локальную сеть и интернет. Ты буквально добровольно запускаешь троянского коня.
Научились у зумеров с гита, у которых всё в облаке.
Любишь играть в русскую рулетку как хобби?
>для бекапа выковыривать только код тоже лень
В архиваторах можно настроить фильтры. Я просто исключил из архива все .png, .gltf и т.п. тяжести, что практически никогда не меняются, и в итоге бэкапы составляют всего несколько килобайт файлов, что изменились за сегодня (фильтр по времени). И это практически не занимает времени, всего 3-4 клика. Автоматически добавляется штамп времени и т.п. Перекатываться на кривоватый гит как-то лениво...
>>4072
>раз гит вдруг стал майковским
Ну, не будешь же ты свой сервер арендовать...
>Да она просто рм сделает
Она-то сделает, но запустил её ты. Виновен ты.
>Дежурный луддит
Я не луддит, а как раз фанат ИИ технологий, и именно поэтому знаю, что нейронки на базе GPT используют тупейшие мартышки и скучающие лузеры по жизни, поскольку полагаться на этот чёрный ящик с мутной историей тренировки нельзя, а ТЕМ БОЛЕЕ запускать автономно на железе, которое тебе дорого и имеет собственный доступ в локальную сеть и интернет. Ты буквально добровольно запускаешь троянского коня.
>удаляют они почему-то слишком уж бездумно
Научились у зумеров с гита, у которых всё в облаке.
>нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью
Любишь играть в русскую рулетку как хобби?
>>4082
Начинай в любом случае с базовых туториалов:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
Уже потом сядешь пилить свою убийцу игры в Excel.
Начинай в любом случае с базовых туториалов:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
Уже потом сядешь пилить свою убийцу игры в Excel.
>>4068
Откуда инфа? Есть повод для волнения?
>>4069
Ты чё быкуешь, сука, человек реально обучается методом проб и ошибок, щупает синтаксис языка, своими мозгами доходит до рабочих/нерабочих методик, а ты падла подсираешь, ещё и анонов в ридонли дизморалишь. Ты вообще понимаешь как устроен процесс обучения вещам у человека? Стянул бы еблет со своей говнокритикой лучше.
>Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
Откуда инфа? Есть повод для волнения?
>>4069
>чем вот это вот говнокодерство
>говнокод в красивом фантике
Ты чё быкуешь, сука, человек реально обучается методом проб и ошибок, щупает синтаксис языка, своими мозгами доходит до рабочих/нерабочих методик, а ты падла подсираешь, ещё и анонов в ридонли дизморалишь. Ты вообще понимаешь как устроен процесс обучения вещам у человека? Стянул бы еблет со своей говнокритикой лучше.
>>4088
Так он это здесь показывает так, как будто это что-то хорошее и нужно повторять. Если он хочет критики - замечательно, но он же сразу огрызается на советы, следовательно, критики он не ожидает. Тогда зачем?
Или ты считаешь, что юзать Area2D для игры, где все элементы - квадраты на квадратной сетке - это типа нормально? Ты считаешь, что ему следует держаться данного подхода и ни в коем случае нельзя делать замечаний, что так делать (в данном случае) вредно?
Ладно бы он хотел сделать что-то современное. Но он пытается скопировать классическую змейку. В ней уж точно никаких Area2D не было и быть не могло.
>реально обучается методом проб и ошибок
>как устроен процесс обучения вещам у человека?
Так он это здесь показывает так, как будто это что-то хорошее и нужно повторять. Если он хочет критики - замечательно, но он же сразу огрызается на советы, следовательно, критики он не ожидает. Тогда зачем?
Или ты считаешь, что юзать Area2D для игры, где все элементы - квадраты на квадратной сетке - это типа нормально? Ты считаешь, что ему следует держаться данного подхода и ни в коем случае нельзя делать замечаний, что так делать (в данном случае) вредно?
Ладно бы он хотел сделать что-то современное. Но он пытается скопировать классическую змейку. В ней уж точно никаких Area2D не было и быть не могло.
>>4088
Да повод вполне обычный - у нас есть хуйня импортозамещенная. С крошечными лимитами на бесплатке. И принадлежащая тоже кому надо. И даже заботливо намекающая с главной же страницы "мигрируйте к нам с гитхаба, вот тут нажать".
Правда уже довольно давно, главное почва уже имеется, войну сервисам и с меньшей подготовкой объявляли.
А повод даже выдумывать не надо - на гитхабе куда не плюнь запрещенка.
>Откуда инфа? Есть повод для волнения?
Да повод вполне обычный - у нас есть хуйня импортозамещенная. С крошечными лимитами на бесплатке. И принадлежащая тоже кому надо. И даже заботливо намекающая с главной же страницы "мигрируйте к нам с гитхаба, вот тут нажать".
Правда уже довольно давно, главное почва уже имеется, войну сервисам и с меньшей подготовкой объявляли.
А повод даже выдумывать не надо - на гитхабе куда не плюнь запрещенка.
>>4092
Ладно, эт я чёт сорвался. Думаю для такой хуйни как змейка из трех с половиной нод, начинающий юзверь вполне может юзать ареа2д. Опять же, гораздо эффективнее и запоминабельнее будет себе стрельнуть в ногу в проекте покрупнее, и уже исходя из этого оптимизировать подход. Ну и его реакция тоже ясна: вместо критики обозвали говнокодом, подкинули невнятных объяснений, и дали ссылку на неоткрываемую без впн документацию.
Ну ладно, хули я тут языком чешу, ситуация-то штатная в любом коммьюнити, в любом обсуждении. Пойду лучше мусолить игру мечты.
Ладно, эт я чёт сорвался. Думаю для такой хуйни как змейка из трех с половиной нод, начинающий юзверь вполне может юзать ареа2д. Опять же, гораздо эффективнее и запоминабельнее будет себе стрельнуть в ногу в проекте покрупнее, и уже исходя из этого оптимизировать подход. Ну и его реакция тоже ясна: вместо критики обозвали говнокодом, подкинули невнятных объяснений, и дали ссылку на неоткрываемую без впн документацию.
Ну ладно, хули я тут языком чешу, ситуация-то штатная в любом коммьюнити, в любом обсуждении. Пойду лучше мусолить игру мечты.
Фух, кажись тролль ушёл. Продолжим делиться своими игорами в треде, друзья!
Парни есть гайд годный на выживач на голове с мультиплеером? А то все гайды именно на сюрвалики а не выживачи.
274 Кб, 837x649Новый челлендж - змейка со скроллом уровня..
>>3400 (OP)
У вас здесь какой то непрекращающийся змеиный перфоманс, интересно юнитеки из треда, хоть змейку смогут сделать без ассетов.
У вас здесь какой то непрекращающийся змеиный перфоманс, интересно юнитеки из треда, хоть змейку смогут сделать без ассетов.
>>4125
Бля, збс идея так-то
Бля, збс идея так-то
>>4151
Моя первая змейка такая же была. Баженная. На спор сделал. Знал только массивы, циклы, функции, все такое, да классы прям понюхал тока тока, ни архитектур нихуя не знал и не умел, ни опыта.
Смотрю на этого змеееба тредовского и думаю смогу ли я сейчас без нейронок сделать змейку уже в годоте и чтоб охуенная была. лень проверять.
Моя первая змейка такая же была. Баженная. На спор сделал. Знал только массивы, циклы, функции, все такое, да классы прям понюхал тока тока, ни архитектур нихуя не знал и не умел, ни опыта.
Смотрю на этого змеееба тредовского и думаю смогу ли я сейчас без нейронок сделать змейку уже в годоте и чтоб охуенная была. лень проверять.
Зашел я в репу и посмотрел ишью по 4.5 и 4.6. Скажите, сидит кто-нибудь на них, стабильно ли? Очень много мердж реквестов и ишью висят, мне аж не по себе, особенно за 4.5. Будут ли дальнейшие 4.5.х и 4.6.х релизы? 4.6 точно такой релиз нужен, я литерали не могу его использовать. Редактор вылетает при импорте анимаций, ишью так и висит, теперь это уже регрессия 4.6.2, хотя у меня и в 4.6.1 не работало.
>>4191
Из официальной документации:
https://docs.godotengine.org/en/stable/about/release_policy.html#release-support-timeline
То есть 4.5 обновят, только если обнаружится некая уязвимость (например, в сетевых протоколах), либо несовместимость с платформами (типа Android); 4.6 обновляют всеми багфиксами вплоть до релиза 4.7, ожидаемого во втором или третьем квартале 2026.
У меня кастомный билд (x64 SSE2 only) 4.6 стабилен. Попробуй запустить проект на x86 версии, если тебе достаточно 4 ГБ оперативки для всего проекта - как правило, в 32-битных программах меньше проблем. Собственно, я бы мог не билдить x64, просто хотел поизвращаться с компилятором и всё такое...
>Будут ли дальнейшие 4.5.х и 4.6.х релизы?
Из официальной документации:
https://docs.godotengine.org/en/stable/about/release_policy.html#release-support-timeline
>Godot 4.5 - September 2025 - (partial) Receives fixes for security and platform support issues only.
>Godot 4.6 - January 2026 - (supported) Receives fixes for bugs and security issues, as well as patches that enable platform support.
То есть 4.5 обновят, только если обнаружится некая уязвимость (например, в сетевых протоколах), либо несовместимость с платформами (типа Android); 4.6 обновляют всеми багфиксами вплоть до релиза 4.7, ожидаемого во втором или третьем квартале 2026.
>я литерали не могу его использовать
У меня кастомный билд (x64 SSE2 only) 4.6 стабилен. Попробуй запустить проект на x86 версии, если тебе достаточно 4 ГБ оперативки для всего проекта - как правило, в 32-битных программах меньше проблем. Собственно, я бы мог не билдить x64, просто хотел поизвращаться с компилятором и всё такое...
>>4121
Зачем тебе отдельный гайд на выживач?
Для выживача ищи про:
- авторитарный мультиплеер для экшена/шутера;
- механики и контроллеры для обычного шутера;
- инвентарь, крафтинг и т.п. по твоему вкусу.
Потом просто слепишь всё вместе.
>гайд годный на выживач с мультиплеером
Зачем тебе отдельный гайд на выживач?
Для выживача ищи про:
- авторитарный мультиплеер для экшена/шутера;
- механики и контроллеры для обычного шутера;
- инвентарь, крафтинг и т.п. по твоему вкусу.
Потом просто слепишь всё вместе.
>>4195
Спасибо за ссылку, не видел это в доках. Ахуеть конечно. С одной стороны я понимаю их (совсем чуть-чуть), а с другой, что это если не принуждение обновляться если хочется багфиксов? Еще и никто не отозвался насчет 4.5 и 4.6, неужели сидят все на 3.х ветке?
Спасибо за ссылку, не видел это в доках. Ахуеть конечно. С одной стороны я понимаю их (совсем чуть-чуть), а с другой, что это если не принуждение обновляться если хочется багфиксов? Еще и никто не отозвался насчет 4.5 и 4.6, неужели сидят все на 3.х ветке?
>>4250
Все сидят на своих форках со свежайшей мастер ветки и своими изменениями исходников.
Все сидят на своих форках со свежайшей мастер ветки и своими изменениями исходников.
>>4250
У них ежегодные опросы через гуглформы, из которых следует, что большинство сидит на самой актуальной версии движка, ещё немного сидит на последней 3.x, и мизерное количество застревает на промежуточных, наверное, из-за каких-то велосипедных модулей...
Вот, например, за прошлый год (30 июня 2025):
https://godotengine.org/article/godot-community-poll-2025/
Опрос был после 4.4 (март) до 4.5 (сентябрь).
Подозреваю, что сейчас дела обстоят как-то так:
Посмотрим, что будет в опросе этим летом...
Сходи на Reddit в r/godot, там часто обсуждают.
У них ежегодные опросы через гуглформы, из которых следует, что большинство сидит на самой актуальной версии движка, ещё немного сидит на последней 3.x, и мизерное количество застревает на промежуточных, наверное, из-за каких-то велосипедных модулей...
Вот, например, за прошлый год (30 июня 2025):
https://godotengine.org/article/godot-community-poll-2025/
>Godot 4.5 (dev/master) - 16.8%
>Godot 4.4 (stable) - 71.2%
>Godot 4.2-4.3 - 8.8%
>Godot 3.5-3.6 - 2.3%
>Godot 4.0-4.1 - 0.9%
Опрос был после 4.4 (март) до 4.5 (сентябрь).
Подозреваю, что сейчас дела обстоят как-то так:
>Godot 4.7 (dev/master) - 15%
>Godot 4.6 (stable) - 70%
>Godot 4.5 - 10%
>Godot 3.5-3.6 - 2%
>всё остальное - 3%
Посмотрим, что будет в опросе этим летом...
>Еще и никто не отозвался насчет 4.5 и 4.6
Сходи на Reddit в r/godot, там часто обсуждают.
Чё за бредятина у годота с редактированием инстанцированных сцен? То есть я не могу polygonshape дочерней сцены через встроенный редактор нарисовать, мне для каждого инстанса надо прожимать "редактировать дочерние элементы" Почему не добавить возможность вынести такие вещи на корневую ноду? Думаю теперь костылить polygonshape2d в корне и area2d в рантайме себя корнем делает и принимает polygonshape2d.
>>4270
Проблема Икс у тебя в чём заключается?
Какую проблему ты пытаешься решить, редактируя дочерние элементы?
Проблема Икс у тебя в чём заключается?
Какую проблему ты пытаешься решить, редактируя дочерние элементы?
>>4273
Зону спавна из collisionpolygon на главной сцене. В итоге я инстанцирую area2d со скриптом и в дочки ему создаю форму и там же её и правлю.
Зону спавна из collisionpolygon на главной сцене. В итоге я инстанцирую area2d со скриптом и в дочки ему создаю форму и там же её и правлю.
>>4274
Так. Тебе нужна зона спавна. Ты хочешь самостоятельно выбирать зону спавна в редакторе. Я правильно понял?
Так. Тебе нужна зона спавна. Ты хочешь самостоятельно выбирать зону спавна в редакторе. Я правильно понял?
11 Кб, 384x317>>4274
Там есть нода просто Polygon2D, без привязки к коллиженам. Может тебе просто полигон нужен? Чтобы потом из него получать рандомную точку спавна?
> Зону спавна из collisionpolygon
Там есть нода просто Polygon2D, без привязки к коллиженам. Может тебе просто полигон нужен? Чтобы потом из него получать рандомную точку спавна?
3 Кб, 61x55>>4285
Тебе это неважно. На твою разработку это никак не повлияет.
Тебе это неважно. На твою разработку это никак не повлияет.
509 Кб, mp4,1152x648, 0:06
>>4282
Типа как-то так.
Типа как-то так.
76 Кб, 835x834>>4290
Так бы сразу и говорил. То есть, зона спавна должна реагировать на вход тела (игрока) и спавнить предустановленную сцену?
Штош, бесплатные токены в клауде закончились, приходите завтра.
Так бы сразу и говорил. То есть, зона спавна должна реагировать на вход тела (игрока) и спавнить предустановленную сцену?
Штош, бесплатные токены в клауде закончились, приходите завтра.
19 Кб, 408x97>>4292
Я в итоге просто так сделал и забил пока. Понял что приоритет выше у других вещей.
Я в итоге просто так сделал и забил пока. Понял что приоритет выше у других вещей.
>>4295
И в итоге это самое правильное решение. То что зона вложена как сцена - не отменяет того факта что ей коллизию можно в дети пихануть снаружи, а не лезть в детей через редактирование каждый раз.
Я даже в каком-то старом туториале видал такой трюк, ещё на трёшке.
И в итоге это самое правильное решение. То что зона вложена как сцена - не отменяет того факта что ей коллизию можно в дети пихануть снаружи, а не лезть в детей через редактирование каждый раз.
Я даже в каком-то старом туториале видал такой трюк, ещё на трёшке.
>>4270 >>4295
Зачем ты сохраняешь эту Area2D как сцену, если это одна нода?
Попробуй как-то так (не проверял, пишу в поле ввода поста):
Далее следует твой код спавнера как обычно.
Важно - как этот скрипт использовать:
1. Открываешь сцену, куда хочешь засунуть новый спавнер.
2. Нажимаешь ctrl+A или кнопку с плюсиком сверху дерева.
3. Набираешь имя класса "Spawn..." пока не найдёшь ноду.
4. Жмёшь Enter.
Твой скрипт сразу добавит себе новый CollisionPolygon2D.
Редактируешь, сохраняешь - в общем, всё как обычно.
И никаких tscn в данной ситуации создавать не нужно.
Зачем ты сохраняешь эту Area2D как сцену, если это одна нода?
Попробуй как-то так (не проверял, пишу в поле ввода поста):
>@tool # будем выполняться в редакторе
>@icon("spawn_zone_icon.svg") # для удобства в редакторе
>class_name SpawnZone # важно дать какое-нибудь имя класса
>extends Area2D
>func _ready() -> void:
>_ if Engine.is_editor_hint(): # проверяем, что мы в редакторе
>_ _ if not get_child_count() or get_child(0) is not CollisionPolygon2D:
>_ _ _ var p := CollisionPolygon2D.new()
>_ _ _ add_child(p)
>_ _ _ p.owner = owner # чтобы нода сохранилась в файле сцены
Далее следует твой код спавнера как обычно.
Важно - как этот скрипт использовать:
1. Открываешь сцену, куда хочешь засунуть новый спавнер.
2. Нажимаешь ctrl+A или кнопку с плюсиком сверху дерева.
3. Набираешь имя класса "Spawn..." пока не найдёшь ноду.
4. Жмёшь Enter.
Твой скрипт сразу добавит себе новый CollisionPolygon2D.
Редактируешь, сохраняешь - в общем, всё как обычно.
И никаких tscn в данной ситуации создавать не нужно.
>>4270
Алсо, хочу заметить, что это - от непонимания сцен Godot:
Механизм сцен Godot предполагает, что внутренние ноды сцены являются "деталями имплементации", то есть сохранение куска дерева как сцены - это что-то вроде инкапсуляции ООП объекта. Поэтому у тебя есть лёгкий доступ к свойствам корневой ноды - интерфейса сцены - и более сложный доступ к её внутренностям. Фича "редактировать дочерние ноды" - это анти-паттерн, который предусмотрен для быстрых костылей-заплаток, прототипов и тому подобного. Так что, если ты замечаешь, что ты вынужден слишком часто прибегать к этой функции, тебе следует пересмотреть то, как ты организуешь свои сцены. Кстати, механизм этот не совсем надёжный и внесённые изменения легко "слетают", если ты как-то поменяешь оригинальную сцену. Это могут поправить в новых версиях движка, но в целом лучше не полагаться на сохранность данных, введённых в режиме "редактирования дочерних нод" инстанса сцены.
Алсо, хочу заметить, что это - от непонимания сцен Godot:
>бредятина у годота с редактированием инстанцированных
>надо прожимать "редактировать дочерние элементы"
Механизм сцен Godot предполагает, что внутренние ноды сцены являются "деталями имплементации", то есть сохранение куска дерева как сцены - это что-то вроде инкапсуляции ООП объекта. Поэтому у тебя есть лёгкий доступ к свойствам корневой ноды - интерфейса сцены - и более сложный доступ к её внутренностям. Фича "редактировать дочерние ноды" - это анти-паттерн, который предусмотрен для быстрых костылей-заплаток, прототипов и тому подобного. Так что, если ты замечаешь, что ты вынужден слишком часто прибегать к этой функции, тебе следует пересмотреть то, как ты организуешь свои сцены. Кстати, механизм этот не совсем надёжный и внесённые изменения легко "слетают", если ты как-то поменяешь оригинальную сцену. Это могут поправить в новых версиях движка, но в целом лучше не полагаться на сохранность данных, введённых в режиме "редактирования дочерних нод" инстанса сцены.
>>4270
Ты хотел сказать наследованных сцен?
Ты хотел сказать наследованных сцен?
>>4270
Если да, то просто никогда ими не пользуйся.
Не все инструменты в движке нужно использовать просто потому что они там есть. Они могут быть неудачными, а убрать уже нельзя из-за обратной совместимости.
https://www.reddit.com/r/godot/comments/1m3ufb5/is_it_just_me_or_is_godots_scenes_inheritance/
Если да, то просто никогда ими не пользуйся.
Не все инструменты в движке нужно использовать просто потому что они там есть. Они могут быть неудачными, а убрать уже нельзя из-за обратной совместимости.
https://www.reddit.com/r/godot/comments/1m3ufb5/is_it_just_me_or_is_godots_scenes_inheritance/
>>4308
Чтобы скрипт не лепить каждый раз очевидно.
Задумку вроде понял, но не работает. Да и избыточно это.
Чтобы скрипт не лепить каждый раз очевидно.
> Попробуй как-то так (не проверял, пишу в поле ввода поста):
Задумку вроде понял, но не работает. Да и избыточно это.
>>4309
Ну например для импортированных мешей я включаю редактирование дочерних нод чтобы выбрать меш и добавить коллизии, хитбоксы. Обычно при импорте корень сцены это просто node3d.
Ну например для импортированных мешей я включаю редактирование дочерних нод чтобы выбрать меш и добавить коллизии, хитбоксы. Обычно при импорте корень сцены это просто node3d.
>>4328
Исправил ошибку - можешь попробовать снова, если хочешь.
Но это ускоряет работу, если нужно создавать много таких нод.
>>4329
Если изменишь порядок/имена нод в исходном файле, то после повторного импорта Godot "забудет" всё, что ты нацепил на эти внутренние (жёлтые) ноды: в коде tscn созданные тобой ноды/ресурсы имеют конкретных владельцев, и если эти владельцы меняют имя, то ноды/ресурсы становятся ничейными и игнорируются при чтении сцены/записи сцены в файл. Вроде бы это должны были пофиксить UID для нод внутри сцен, но у GLTF вроде бы ещё нет таких UID, поэтому всё полагается на имена и иерархию (если они это ещё не пофиксили как-то; давно не проверял). Учитывай это, если планируешь несколько раз экспортировать одну и ту же сцену в один и тот же GTLF файл. Т.е. нужно либо не менять имена и иерархию, либо нужно отказаться от подвешивания чего-либо на "жёлтые" ноды в редакторе (а также от механизма "inherited scene" - у него та же проблема, потому что под капотом это одна и та же фича движка).
Можно настроить автоматическое создание коллизий, добавив специальные суффиксы к именам объектов/пустышек внутри сцены Blender. Подробнее:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/node_type_customization.html#create-collisions-col-convcol-colonly-convcolonly
>>4317
Они не так уж и плохи в некоторых ситуациях, просто нужно знать нюансы (см. выше).
>>4432 (Del)
"Inherited scene" существует благодаря "editable children" - их можно было получить через какие-то манипуляции с кодом сцены в файле tscn - кнопка создания "inherited scene" просто упрощает такую манипуляцию. Это важная фича системы сцен, отказаться от неё нельзя. Считайте это трюком уровня get_parent().get_parent().get_parent()... - движок позволяет так делать и никто не будет вырезать эту фичу в будущих версиях движка, потому что так работает дерево сцен и ничего с этим не поделать, но это не означает, что вы должны обмазывать все скрипты такими конструкциями. Пока "родитель" нескольких "дочерних" сцен никак не меняется (иерархия и имена узлов), всё должно быть в порядке. Проблема будет только если вы захотите изменить родителя - тогда дочерние сцены могут поломаться, утратив часть данных, закреплённых за изменёнными нодами. Повторюсь - это должны были решить UID у нод в сценах, но я не знаю, решили они это или нет.
>не работает
Исправил ошибку - можешь попробовать снова, если хочешь.
>избыточно
Но это ускоряет работу, если нужно создавать много таких нод.
>>4329
>для импортированных мешей
Если изменишь порядок/имена нод в исходном файле, то после повторного импорта Godot "забудет" всё, что ты нацепил на эти внутренние (жёлтые) ноды: в коде tscn созданные тобой ноды/ресурсы имеют конкретных владельцев, и если эти владельцы меняют имя, то ноды/ресурсы становятся ничейными и игнорируются при чтении сцены/записи сцены в файл. Вроде бы это должны были пофиксить UID для нод внутри сцен, но у GLTF вроде бы ещё нет таких UID, поэтому всё полагается на имена и иерархию (если они это ещё не пофиксили как-то; давно не проверял). Учитывай это, если планируешь несколько раз экспортировать одну и ту же сцену в один и тот же GTLF файл. Т.е. нужно либо не менять имена и иерархию, либо нужно отказаться от подвешивания чего-либо на "жёлтые" ноды в редакторе (а также от механизма "inherited scene" - у него та же проблема, потому что под капотом это одна и та же фича движка).
>добавить коллизии, хитбоксы
Можно настроить автоматическое создание коллизий, добавив специальные суффиксы к именам объектов/пустышек внутри сцены Blender. Подробнее:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/node_type_customization.html#create-collisions-col-convcol-colonly-convcolonly
>>4317
>просто никогда ими не пользуйся
Они не так уж и плохи в некоторых ситуациях, просто нужно знать нюансы (см. выше).
>убрать уже нельзя из-за обратной совместимости
>>4432 (Del)
>Самый момент был для выкидывания, если на то пошло.
"Inherited scene" существует благодаря "editable children" - их можно было получить через какие-то манипуляции с кодом сцены в файле tscn - кнопка создания "inherited scene" просто упрощает такую манипуляцию. Это важная фича системы сцен, отказаться от неё нельзя. Считайте это трюком уровня get_parent().get_parent().get_parent()... - движок позволяет так делать и никто не будет вырезать эту фичу в будущих версиях движка, потому что так работает дерево сцен и ничего с этим не поделать, но это не означает, что вы должны обмазывать все скрипты такими конструкциями. Пока "родитель" нескольких "дочерних" сцен никак не меняется (иерархия и имена узлов), всё должно быть в порядке. Проблема будет только если вы захотите изменить родителя - тогда дочерние сцены могут поломаться, утратив часть данных, закреплённых за изменёнными нодами. Повторюсь - это должны были решить UID у нод в сценах, но я не знаю, решили они это или нет.
>>4328
Исправил ошибку - можешь попробовать снова, если хочешь.
Но это ускоряет работу, если нужно создавать много таких нод.
>>4329
Если изменишь порядок/имена нод в исходном файле, то после повторного импорта Godot "забудет" всё, что ты нацепил на эти внутренние (жёлтые) ноды: в коде tscn созданные тобой ноды/ресурсы имеют конкретных владельцев, и если эти владельцы меняют имя, то ноды/ресурсы становятся ничейными и игнорируются при чтении сцены/записи сцены в файл. Вроде бы это должны были пофиксить UID для нод внутри сцен, но у GLTF вроде бы ещё нет таких UID, поэтому всё полагается на имена и иерархию (если они это ещё не пофиксили как-то; давно не проверял). Учитывай это, если планируешь несколько раз экспортировать одну и ту же сцену в один и тот же GTLF файл. Т.е. нужно либо не менять имена и иерархию, либо нужно отказаться от подвешивания чего-либо на "жёлтые" ноды в редакторе (а также от механизма "inherited scene" - у него та же проблема, потому что под капотом это одна и та же фича движка).
Можно настроить автоматическое создание коллизий, добавив специальные суффиксы к именам объектов/пустышек внутри сцены Blender. Подробнее:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/node_type_customization.html#create-collisions-col-convcol-colonly-convcolonly
>>4317
Они не так уж и плохи в некоторых ситуациях, просто нужно знать нюансы (см. выше).
>>4432 (Del)
"Inherited scene" существует благодаря "editable children" - их можно было получить через какие-то манипуляции с кодом сцены в файле tscn - кнопка создания "inherited scene" просто упрощает такую манипуляцию. Это важная фича системы сцен, отказаться от неё нельзя. Считайте это трюком уровня get_parent().get_parent().get_parent()... - движок позволяет так делать и никто не будет вырезать эту фичу в будущих версиях движка, потому что так работает дерево сцен и ничего с этим не поделать, но это не означает, что вы должны обмазывать все скрипты такими конструкциями. Пока "родитель" нескольких "дочерних" сцен никак не меняется (иерархия и имена узлов), всё должно быть в порядке. Проблема будет только если вы захотите изменить родителя - тогда дочерние сцены могут поломаться, утратив часть данных, закреплённых за изменёнными нодами. Повторюсь - это должны были решить UID у нод в сценах, но я не знаю, решили они это или нет.
>не работает
Исправил ошибку - можешь попробовать снова, если хочешь.
>избыточно
Но это ускоряет работу, если нужно создавать много таких нод.
>>4329
>для импортированных мешей
Если изменишь порядок/имена нод в исходном файле, то после повторного импорта Godot "забудет" всё, что ты нацепил на эти внутренние (жёлтые) ноды: в коде tscn созданные тобой ноды/ресурсы имеют конкретных владельцев, и если эти владельцы меняют имя, то ноды/ресурсы становятся ничейными и игнорируются при чтении сцены/записи сцены в файл. Вроде бы это должны были пофиксить UID для нод внутри сцен, но у GLTF вроде бы ещё нет таких UID, поэтому всё полагается на имена и иерархию (если они это ещё не пофиксили как-то; давно не проверял). Учитывай это, если планируешь несколько раз экспортировать одну и ту же сцену в один и тот же GTLF файл. Т.е. нужно либо не менять имена и иерархию, либо нужно отказаться от подвешивания чего-либо на "жёлтые" ноды в редакторе (а также от механизма "inherited scene" - у него та же проблема, потому что под капотом это одна и та же фича движка).
>добавить коллизии, хитбоксы
Можно настроить автоматическое создание коллизий, добавив специальные суффиксы к именам объектов/пустышек внутри сцены Blender. Подробнее:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/node_type_customization.html#create-collisions-col-convcol-colonly-convcolonly
>>4317
>просто никогда ими не пользуйся
Они не так уж и плохи в некоторых ситуациях, просто нужно знать нюансы (см. выше).
>убрать уже нельзя из-за обратной совместимости
>>4432 (Del)
>Самый момент был для выкидывания, если на то пошло.
"Inherited scene" существует благодаря "editable children" - их можно было получить через какие-то манипуляции с кодом сцены в файле tscn - кнопка создания "inherited scene" просто упрощает такую манипуляцию. Это важная фича системы сцен, отказаться от неё нельзя. Считайте это трюком уровня get_parent().get_parent().get_parent()... - движок позволяет так делать и никто не будет вырезать эту фичу в будущих версиях движка, потому что так работает дерево сцен и ничего с этим не поделать, но это не означает, что вы должны обмазывать все скрипты такими конструкциями. Пока "родитель" нескольких "дочерних" сцен никак не меняется (иерархия и имена узлов), всё должно быть в порядке. Проблема будет только если вы захотите изменить родителя - тогда дочерние сцены могут поломаться, утратив часть данных, закреплённых за изменёнными нодами. Повторюсь - это должны были решить UID у нод в сценах, но я не знаю, решили они это или нет.
5,9 Мб, mp4,1280x720, 0:06
А я продолжаю издеваться над годотом, добавил коллизии юнитам, классы стрелков и магов, и начал работу над статическими объектами на карте, которые юниты стараются обходить.
ФПС упал сильно, в пике нагрузки уже меньше 200 фпс показывает. А было 500 изначально. В целом не страшно, ведь это значит, что у меня в запасе еще 140 свободных кадров, которые можно потратить.
ФПС упал сильно, в пике нагрузки уже меньше 200 фпс показывает. А было 500 изначально. В целом не страшно, ведь это значит, что у меня в запасе еще 140 свободных кадров, которые можно потратить.
10 Кб, 181x200>>4488
Круто конечно, но вампырики-сурвалики уже всех заебали. Ты эти волны врагов никому не продашь.
Делай лучше метроидванию. Метроидвании всегда в цене. Хороших метроивданий мало. Сделаешь хорошо - заработаешь нормально.
Круто конечно, но вампырики-сурвалики уже всех заебали. Ты эти волны врагов никому не продашь.
Делай лучше метроидванию. Метроидвании всегда в цене. Хороших метроивданий мало. Сделаешь хорошо - заработаешь нормально.
>>4492
Не рекламы ради, я тут последние 3.5 недели дрочу мобильную гиперказуалку "Gear Defenders" - и она умудряется затягивать и по своей воле смотреть 2-3 десятка рекламных видео в день, лол. Геймплей на поверхности прост: ставишь эти "шестерёнки", а они спавнят юнитов, которые идут и бьют мобов... Если копнуть глубже, имея ограниченные ресурсы, место, неудобные препятствия и т.п., собрать успешную композицию не так-то просто. К сожалению, игра на высоких уровнях скатывается в "либо повезло, либо смотри рекламу ради какого-то шанса на победу". Поэтому, рекомендовать эту игру не могу - но с т.з. геймдизайна базовая формула весьма хороша. Мне захотелось сделать похожую игру или реализовать данную формулу геймплея в игре другого жанра.
Но там не так-то много юнитов - где-то до сотни. Интересно, что бой становится месивом, где трудно разобраться, кто кого атаковал и насколько сильно, поэтому становится тяжелее принимать решения на следующей волне. Т.е. огромное число юнитов не является здесь чем-то нужным или крутым, скорее раздражает, мешает анализировать ситуацию. Алсо, большинство юнитов тупят, не могут выбрать более подходящую цель (пример: всадник имеет сильное преимущество против лучников, но если даже он технически мог бы обежать защитников по дуге, он предпочтёт умирать об этих защитников, что бесит, особенно если это в чистом поле с 2 врагами).
Короче говоря, игра с толпой может быть довольно интересной и при этом простой, но нужно правильно организовать и не перегружать игру лишним числом, поскольку слишком большая толпа не нужна и лишь отвлекает или мешает анализу и планированию.
Относится ли пикрил к "survivor-like"? Вроде бы нет. Насколько я понимаю, это вариант tower defense с укороченной дорожкой и мобильными "башнями" (интересно, "башни" - это шестерёнки или юниты?). Конечно, есть ещё куча жанров, где толпа уместна...
С точки зрения геймдизайна, это в первую очередь платформер, а платформер - это экшен с высокой зависимостью от точной реакции игрока. Так что это ограничивает целевую аудиторию, которая способна поиграть и получить удовольствие. К тому же, жанр метроидваний подразумевает большой уровень с регулярными походами туда-сюда через ловушки, и, следовательно, игровая сессия даже с чекпойнтами должна быть долгой (иначе игрок забудет, куда ему двигаться и зачем), что ещё сильнее ограничивает аудиторию даже в сравнении с платформерами.
А узкой аудитории сложнее угодить:
Потому что даже в такой узкой ЦА есть свои мелкие категории игроков, которым нравится разное в этом специфичном жанре. Что одному - шедевр 10/10, то другому может совсем не доставлять удовольствия. Ошибиться с гиперказуалкой, очевидно, сложнее.
А сделает норм - убьёт лет 5 на ассеты, отладку и "полировку", которую оценят 3.5 ценителя и лишь 1.5 из них похлопают по плечу и скажут "малаца", а двое других обосрут с головы до ног по пустякам...
Я не предлагаю бежать делать гиперказуалки, нет. Гиперказуалки лезут по головам друг друга, сжигая бюджеты на рекламу, которого у вас всё равно нет. Впрочем, цена обосрамса невелика - пикрил даже с графикой и геймплеем можно сделать за неделю, наверное, останется только рекламу прикрутить и оформить страничку в маркете. А потом только наполнять контентом, если игра реально взлетит. Банально более разумное вложение, если волнует исключительно прибыль с игр, а не Игра Мечты.
>>4488
Это ни о чём не говорит. Сколько юнитов в пике? А вариантов юнитов (уникальных)? И на каком железе тестируешь? По графикам смотришь или просто так следишь за циферками на экране? Цифры могут и сглаживаться по сравнению с реальной нагрузкой.
Во-первых, по-хорошему считают миллисекунды - стандартные 60 фпс это 16.6 мс примерно. Это типа "бюджет кадра". С этой метрикой проще работать - к примеру, если что-то требует для вычислений 20 мс, возможно размазать вычисления по 4 кадрам, и в результате у тебя будет только +5 мс нагрузки. А в абстрактной "частоте кадров" так не посчитаешь. Аналогично если можешь использовать потоки - ресурсоёмкий процесс на 20 мс на 1 потоке может сократиться до 5-6 мс на 4 потоках, что, опять же, не посчитаешь в абстрактных "кадрах в секунду".
Во-вторых, ты должен оптимизировать сильнее, не растрачивая все 16 мс на своём железе. Нет, если ориентируешься на консоли - там да, можешь 16 мс потратить и твоя игра 100% будет хорошо работать, поскольку у всех игроков одна и та же консоль (ну, теоретически должна быть одна и та же). Но на ПК столкнёшься с тем, что разное железо даже одной ценовой категории работает по-разному, фоновые процессы по-разному отъедают ресурсы компа, и банально перегрев и троттлинг могут сделать игру неиграбельной на "рекомендованном железе". На мобилках тебя ещё будут ругать за то, что телефон раскаляется и обжигает руки с тупой 2D графикой посильнее, чем с продвинутой 3D графикой, лол.
Короче, если хочешь дрочить на оптимизацию и максимальное число юнитов - дрочи правильно. Ориентируйся на хорошие игры, а не симуляторы троттлинга с кучей лишней мишуры на экране.
>Ты эти волны врагов никому не продашь.
Не рекламы ради, я тут последние 3.5 недели дрочу мобильную гиперказуалку "Gear Defenders" - и она умудряется затягивать и по своей воле смотреть 2-3 десятка рекламных видео в день, лол. Геймплей на поверхности прост: ставишь эти "шестерёнки", а они спавнят юнитов, которые идут и бьют мобов... Если копнуть глубже, имея ограниченные ресурсы, место, неудобные препятствия и т.п., собрать успешную композицию не так-то просто. К сожалению, игра на высоких уровнях скатывается в "либо повезло, либо смотри рекламу ради какого-то шанса на победу". Поэтому, рекомендовать эту игру не могу - но с т.з. геймдизайна базовая формула весьма хороша. Мне захотелось сделать похожую игру или реализовать данную формулу геймплея в игре другого жанра.
Но там не так-то много юнитов - где-то до сотни. Интересно, что бой становится месивом, где трудно разобраться, кто кого атаковал и насколько сильно, поэтому становится тяжелее принимать решения на следующей волне. Т.е. огромное число юнитов не является здесь чем-то нужным или крутым, скорее раздражает, мешает анализировать ситуацию. Алсо, большинство юнитов тупят, не могут выбрать более подходящую цель (пример: всадник имеет сильное преимущество против лучников, но если даже он технически мог бы обежать защитников по дуге, он предпочтёт умирать об этих защитников, что бесит, особенно если это в чистом поле с 2 врагами).
Короче говоря, игра с толпой может быть довольно интересной и при этом простой, но нужно правильно организовать и не перегружать игру лишним числом, поскольку слишком большая толпа не нужна и лишь отвлекает или мешает анализу и планированию.
Относится ли пикрил к "survivor-like"? Вроде бы нет. Насколько я понимаю, это вариант tower defense с укороченной дорожкой и мобильными "башнями" (интересно, "башни" - это шестерёнки или юниты?). Конечно, есть ещё куча жанров, где толпа уместна...
>метроидванию
С точки зрения геймдизайна, это в первую очередь платформер, а платформер - это экшен с высокой зависимостью от точной реакции игрока. Так что это ограничивает целевую аудиторию, которая способна поиграть и получить удовольствие. К тому же, жанр метроидваний подразумевает большой уровень с регулярными походами туда-сюда через ловушки, и, следовательно, игровая сессия даже с чекпойнтами должна быть долгой (иначе игрок забудет, куда ему двигаться и зачем), что ещё сильнее ограничивает аудиторию даже в сравнении с платформерами.
А узкой аудитории сложнее угодить:
>Хороших метроидваний мало
Потому что даже в такой узкой ЦА есть свои мелкие категории игроков, которым нравится разное в этом специфичном жанре. Что одному - шедевр 10/10, то другому может совсем не доставлять удовольствия. Ошибиться с гиперказуалкой, очевидно, сложнее.
>Сделаешь хорошо - заработаешь нормально.
А сделает норм - убьёт лет 5 на ассеты, отладку и "полировку", которую оценят 3.5 ценителя и лишь 1.5 из них похлопают по плечу и скажут "малаца", а двое других обосрут с головы до ног по пустякам...
Я не предлагаю бежать делать гиперказуалки, нет. Гиперказуалки лезут по головам друг друга, сжигая бюджеты на рекламу, которого у вас всё равно нет. Впрочем, цена обосрамса невелика - пикрил даже с графикой и геймплеем можно сделать за неделю, наверное, останется только рекламу прикрутить и оформить страничку в маркете. А потом только наполнять контентом, если игра реально взлетит. Банально более разумное вложение, если волнует исключительно прибыль с игр, а не Игра Мечты.
>>4488
>уже меньше 200 фпс показывает
Это ни о чём не говорит. Сколько юнитов в пике? А вариантов юнитов (уникальных)? И на каком железе тестируешь? По графикам смотришь или просто так следишь за циферками на экране? Цифры могут и сглаживаться по сравнению с реальной нагрузкой.
>у меня в запасе еще 140 свободных кадров
Во-первых, по-хорошему считают миллисекунды - стандартные 60 фпс это 16.6 мс примерно. Это типа "бюджет кадра". С этой метрикой проще работать - к примеру, если что-то требует для вычислений 20 мс, возможно размазать вычисления по 4 кадрам, и в результате у тебя будет только +5 мс нагрузки. А в абстрактной "частоте кадров" так не посчитаешь. Аналогично если можешь использовать потоки - ресурсоёмкий процесс на 20 мс на 1 потоке может сократиться до 5-6 мс на 4 потоках, что, опять же, не посчитаешь в абстрактных "кадрах в секунду".
Во-вторых, ты должен оптимизировать сильнее, не растрачивая все 16 мс на своём железе. Нет, если ориентируешься на консоли - там да, можешь 16 мс потратить и твоя игра 100% будет хорошо работать, поскольку у всех игроков одна и та же консоль (ну, теоретически должна быть одна и та же). Но на ПК столкнёшься с тем, что разное железо даже одной ценовой категории работает по-разному, фоновые процессы по-разному отъедают ресурсы компа, и банально перегрев и троттлинг могут сделать игру неиграбельной на "рекомендованном железе". На мобилках тебя ещё будут ругать за то, что телефон раскаляется и обжигает руки с тупой 2D графикой посильнее, чем с продвинутой 3D графикой, лол.
Короче, если хочешь дрочить на оптимизацию и максимальное число юнитов - дрочи правильно. Ориентируйся на хорошие игры, а не симуляторы троттлинга с кучей лишней мишуры на экране.
>>4492
Не рекламы ради, я тут последние 3.5 недели дрочу мобильную гиперказуалку "Gear Defenders" - и она умудряется затягивать и по своей воле смотреть 2-3 десятка рекламных видео в день, лол. Геймплей на поверхности прост: ставишь эти "шестерёнки", а они спавнят юнитов, которые идут и бьют мобов... Если копнуть глубже, имея ограниченные ресурсы, место, неудобные препятствия и т.п., собрать успешную композицию не так-то просто. К сожалению, игра на высоких уровнях скатывается в "либо повезло, либо смотри рекламу ради какого-то шанса на победу". Поэтому, рекомендовать эту игру не могу - но с т.з. геймдизайна базовая формула весьма хороша. Мне захотелось сделать похожую игру или реализовать данную формулу геймплея в игре другого жанра.
Но там не так-то много юнитов - где-то до сотни. Интересно, что бой становится месивом, где трудно разобраться, кто кого атаковал и насколько сильно, поэтому становится тяжелее принимать решения на следующей волне. Т.е. огромное число юнитов не является здесь чем-то нужным или крутым, скорее раздражает, мешает анализировать ситуацию. Алсо, большинство юнитов тупят, не могут выбрать более подходящую цель (пример: всадник имеет сильное преимущество против лучников, но если даже он технически мог бы обежать защитников по дуге, он предпочтёт умирать об этих защитников, что бесит, особенно если это в чистом поле с 2 врагами).
Короче говоря, игра с толпой может быть довольно интересной и при этом простой, но нужно правильно организовать и не перегружать игру лишним числом, поскольку слишком большая толпа не нужна и лишь отвлекает или мешает анализу и планированию.
Относится ли пикрил к "survivor-like"? Вроде бы нет. Насколько я понимаю, это вариант tower defense с укороченной дорожкой и мобильными "башнями" (интересно, "башни" - это шестерёнки или юниты?). Конечно, есть ещё куча жанров, где толпа уместна...
С точки зрения геймдизайна, это в первую очередь платформер, а платформер - это экшен с высокой зависимостью от точной реакции игрока. Так что это ограничивает целевую аудиторию, которая способна поиграть и получить удовольствие. К тому же, жанр метроидваний подразумевает большой уровень с регулярными походами туда-сюда через ловушки, и, следовательно, игровая сессия даже с чекпойнтами должна быть долгой (иначе игрок забудет, куда ему двигаться и зачем), что ещё сильнее ограничивает аудиторию даже в сравнении с платформерами.
А узкой аудитории сложнее угодить:
Потому что даже в такой узкой ЦА есть свои мелкие категории игроков, которым нравится разное в этом специфичном жанре. Что одному - шедевр 10/10, то другому может совсем не доставлять удовольствия. Ошибиться с гиперказуалкой, очевидно, сложнее.
А сделает норм - убьёт лет 5 на ассеты, отладку и "полировку", которую оценят 3.5 ценителя и лишь 1.5 из них похлопают по плечу и скажут "малаца", а двое других обосрут с головы до ног по пустякам...
Я не предлагаю бежать делать гиперказуалки, нет. Гиперказуалки лезут по головам друг друга, сжигая бюджеты на рекламу, которого у вас всё равно нет. Впрочем, цена обосрамса невелика - пикрил даже с графикой и геймплеем можно сделать за неделю, наверное, останется только рекламу прикрутить и оформить страничку в маркете. А потом только наполнять контентом, если игра реально взлетит. Банально более разумное вложение, если волнует исключительно прибыль с игр, а не Игра Мечты.
>>4488
Это ни о чём не говорит. Сколько юнитов в пике? А вариантов юнитов (уникальных)? И на каком железе тестируешь? По графикам смотришь или просто так следишь за циферками на экране? Цифры могут и сглаживаться по сравнению с реальной нагрузкой.
Во-первых, по-хорошему считают миллисекунды - стандартные 60 фпс это 16.6 мс примерно. Это типа "бюджет кадра". С этой метрикой проще работать - к примеру, если что-то требует для вычислений 20 мс, возможно размазать вычисления по 4 кадрам, и в результате у тебя будет только +5 мс нагрузки. А в абстрактной "частоте кадров" так не посчитаешь. Аналогично если можешь использовать потоки - ресурсоёмкий процесс на 20 мс на 1 потоке может сократиться до 5-6 мс на 4 потоках, что, опять же, не посчитаешь в абстрактных "кадрах в секунду".
Во-вторых, ты должен оптимизировать сильнее, не растрачивая все 16 мс на своём железе. Нет, если ориентируешься на консоли - там да, можешь 16 мс потратить и твоя игра 100% будет хорошо работать, поскольку у всех игроков одна и та же консоль (ну, теоретически должна быть одна и та же). Но на ПК столкнёшься с тем, что разное железо даже одной ценовой категории работает по-разному, фоновые процессы по-разному отъедают ресурсы компа, и банально перегрев и троттлинг могут сделать игру неиграбельной на "рекомендованном железе". На мобилках тебя ещё будут ругать за то, что телефон раскаляется и обжигает руки с тупой 2D графикой посильнее, чем с продвинутой 3D графикой, лол.
Короче, если хочешь дрочить на оптимизацию и максимальное число юнитов - дрочи правильно. Ориентируйся на хорошие игры, а не симуляторы троттлинга с кучей лишней мишуры на экране.
>Ты эти волны врагов никому не продашь.
Не рекламы ради, я тут последние 3.5 недели дрочу мобильную гиперказуалку "Gear Defenders" - и она умудряется затягивать и по своей воле смотреть 2-3 десятка рекламных видео в день, лол. Геймплей на поверхности прост: ставишь эти "шестерёнки", а они спавнят юнитов, которые идут и бьют мобов... Если копнуть глубже, имея ограниченные ресурсы, место, неудобные препятствия и т.п., собрать успешную композицию не так-то просто. К сожалению, игра на высоких уровнях скатывается в "либо повезло, либо смотри рекламу ради какого-то шанса на победу". Поэтому, рекомендовать эту игру не могу - но с т.з. геймдизайна базовая формула весьма хороша. Мне захотелось сделать похожую игру или реализовать данную формулу геймплея в игре другого жанра.
Но там не так-то много юнитов - где-то до сотни. Интересно, что бой становится месивом, где трудно разобраться, кто кого атаковал и насколько сильно, поэтому становится тяжелее принимать решения на следующей волне. Т.е. огромное число юнитов не является здесь чем-то нужным или крутым, скорее раздражает, мешает анализировать ситуацию. Алсо, большинство юнитов тупят, не могут выбрать более подходящую цель (пример: всадник имеет сильное преимущество против лучников, но если даже он технически мог бы обежать защитников по дуге, он предпочтёт умирать об этих защитников, что бесит, особенно если это в чистом поле с 2 врагами).
Короче говоря, игра с толпой может быть довольно интересной и при этом простой, но нужно правильно организовать и не перегружать игру лишним числом, поскольку слишком большая толпа не нужна и лишь отвлекает или мешает анализу и планированию.
Относится ли пикрил к "survivor-like"? Вроде бы нет. Насколько я понимаю, это вариант tower defense с укороченной дорожкой и мобильными "башнями" (интересно, "башни" - это шестерёнки или юниты?). Конечно, есть ещё куча жанров, где толпа уместна...
>метроидванию
С точки зрения геймдизайна, это в первую очередь платформер, а платформер - это экшен с высокой зависимостью от точной реакции игрока. Так что это ограничивает целевую аудиторию, которая способна поиграть и получить удовольствие. К тому же, жанр метроидваний подразумевает большой уровень с регулярными походами туда-сюда через ловушки, и, следовательно, игровая сессия даже с чекпойнтами должна быть долгой (иначе игрок забудет, куда ему двигаться и зачем), что ещё сильнее ограничивает аудиторию даже в сравнении с платформерами.
А узкой аудитории сложнее угодить:
>Хороших метроидваний мало
Потому что даже в такой узкой ЦА есть свои мелкие категории игроков, которым нравится разное в этом специфичном жанре. Что одному - шедевр 10/10, то другому может совсем не доставлять удовольствия. Ошибиться с гиперказуалкой, очевидно, сложнее.
>Сделаешь хорошо - заработаешь нормально.
А сделает норм - убьёт лет 5 на ассеты, отладку и "полировку", которую оценят 3.5 ценителя и лишь 1.5 из них похлопают по плечу и скажут "малаца", а двое других обосрут с головы до ног по пустякам...
Я не предлагаю бежать делать гиперказуалки, нет. Гиперказуалки лезут по головам друг друга, сжигая бюджеты на рекламу, которого у вас всё равно нет. Впрочем, цена обосрамса невелика - пикрил даже с графикой и геймплеем можно сделать за неделю, наверное, останется только рекламу прикрутить и оформить страничку в маркете. А потом только наполнять контентом, если игра реально взлетит. Банально более разумное вложение, если волнует исключительно прибыль с игр, а не Игра Мечты.
>>4488
>уже меньше 200 фпс показывает
Это ни о чём не говорит. Сколько юнитов в пике? А вариантов юнитов (уникальных)? И на каком железе тестируешь? По графикам смотришь или просто так следишь за циферками на экране? Цифры могут и сглаживаться по сравнению с реальной нагрузкой.
>у меня в запасе еще 140 свободных кадров
Во-первых, по-хорошему считают миллисекунды - стандартные 60 фпс это 16.6 мс примерно. Это типа "бюджет кадра". С этой метрикой проще работать - к примеру, если что-то требует для вычислений 20 мс, возможно размазать вычисления по 4 кадрам, и в результате у тебя будет только +5 мс нагрузки. А в абстрактной "частоте кадров" так не посчитаешь. Аналогично если можешь использовать потоки - ресурсоёмкий процесс на 20 мс на 1 потоке может сократиться до 5-6 мс на 4 потоках, что, опять же, не посчитаешь в абстрактных "кадрах в секунду".
Во-вторых, ты должен оптимизировать сильнее, не растрачивая все 16 мс на своём железе. Нет, если ориентируешься на консоли - там да, можешь 16 мс потратить и твоя игра 100% будет хорошо работать, поскольку у всех игроков одна и та же консоль (ну, теоретически должна быть одна и та же). Но на ПК столкнёшься с тем, что разное железо даже одной ценовой категории работает по-разному, фоновые процессы по-разному отъедают ресурсы компа, и банально перегрев и троттлинг могут сделать игру неиграбельной на "рекомендованном железе". На мобилках тебя ещё будут ругать за то, что телефон раскаляется и обжигает руки с тупой 2D графикой посильнее, чем с продвинутой 3D графикой, лол.
Короче, если хочешь дрочить на оптимизацию и максимальное число юнитов - дрочи правильно. Ориентируйся на хорошие игры, а не симуляторы троттлинга с кучей лишней мишуры на экране.
>>4502
10К vs 10К.
Пока три класса разных, воин-маг-лучник.
В целом видюха тут не сильно важна, там микро объемы памяти потребляются, а вот проц важен. У меня i5 не самый свежий.
Понятно, что железо у всех разное, но я все равно потом всё буду под геймплей затачивать, там вряд ли так много юнитов нужно будет. Просто стресс-тест.
>Сколько юнитов в пике? А вариантов юнитов (уникальных)?
10К vs 10К.
Пока три класса разных, воин-маг-лучник.
В целом видюха тут не сильно важна, там микро объемы памяти потребляются, а вот проц важен. У меня i5 не самый свежий.
Понятно, что железо у всех разное, но я все равно потом всё буду под геймплей затачивать, там вряд ли так много юнитов нужно будет. Просто стресс-тест.
>>4488
просто круто, хоть сам в вампайр не людлю, но старик или дов, где можно анигиллировать толпы врагов и стоять на горе из трупов, любо дорого.
просто круто, хоть сам в вампайр не людлю, но старик или дов, где можно анигиллировать толпы врагов и стоять на горе из трупов, любо дорого.
Что думаете о механике, которая требует от игрока двигать RIgidBody3D в пространстве без выключения физики и коллизий (т.е. без превращения в Static/Kinematic/Area3D)? Что-то вроде той штуки из Half-Life... ну, вы знаете, о чём я... Думаете, Jolt вытянет это без лишней тряски, провалов "в текстуры", резких запусков в стратосферу и т.п.? Я когда-то что-то такое прототипировал, но работало как-то не очень (какой физический движок был - не помню), так что теперь пытаюсь собрать мотивацию на вторую попытку (спустя очень много времени и версий движка). Ну и не совсем понятно, насколько "честной" такая механика считается игроками - видел всего несколько нишевых игр с ней, во всех остальных тела превращаются в статики или вообще становятся неосязаемыми для окружающей среды в "руках" игрока...
>>4522
Да это вообще не вампайрик, это скорее фрейворк на основе годота чисто, чтобы можно было делать огромные армии юнитов. Геймплей в этом плане можно потом додумать, важно, что юнитов много и это работает.
Да это вообще не вампайрик, это скорее фрейворк на основе годота чисто, чтобы можно было делать огромные армии юнитов. Геймплей в этом плане можно потом додумать, важно, что юнитов много и это работает.
О, кто то посмотрел видосик про откопанную 14-летнюю технологию Silhouetted Parallax Occlusion Mapping
https://godotshaders.com/shader/improved-spom-with-outline-detection-and-self-shadowing/
https://www.youtube.com/watch?v=TUAyiCswYt4
https://godotshaders.com/shader/improved-spom-with-outline-detection-and-self-shadowing/
https://www.youtube.com/watch?v=TUAyiCswYt4
>>4526
Ага, нашёл свой код трёхлетней давности и немного причесал.
В общем, я сейчас поигрался и увидел следующие проблемы:
- игрок может взлететь на RigidBody3D словно Мюнхгаузен;
- RigidBody3D может продавить игрока сквозь/внутрь пола;
- трудно подобрать оптимальное расстояние/силу влияния.
Наверное, если повесить стопицот if-else, всё решаемо...
На движок такое вообще никак не влияет. Зря волновался.
>>4537
Это когда было? В 2023?
Мне внезапно захотелось "натуральное" поведение...
Но это не главное... Покажу целиком, когда/если сделаю.
>когда-то что-то такое прототипировал
Ага, нашёл свой код трёхлетней давности и немного причесал.
В общем, я сейчас поигрался и увидел следующие проблемы:
- игрок может взлететь на RigidBody3D словно Мюнхгаузен;
- RigidBody3D может продавить игрока сквозь/внутрь пола;
- трудно подобрать оптимальное расстояние/силу влияния.
Наверное, если повесить стопицот if-else, всё решаемо...
На движок такое вообще никак не влияет. Зря волновался.
>>4537
>В прошлый раз
Это когда было? В 2023?
>делать что-то типа ShapeCast?
Мне внезапно захотелось "натуральное" поведение...
Но это не главное... Покажу целиком, когда/если сделаю.
>>4572 (Del)
Можно выжимку по поводу нового ассет стора? У меня без квн не открывает и я заебался юзать бесплатные прокси которые сдыхают через день
>>4547
РиджидБади это самая пидаристическая хуета из всех Бади нод, что 2д что 3д. Сфера применения очень узкая походу, я их юзаю только для мелкой шняги типа гиблетов врагов/объектов.
Можно выжимку по поводу нового ассет стора? У меня без квн не открывает и я заебался юзать бесплатные прокси которые сдыхают через день
>>4547
РиджидБади это самая пидаристическая хуета из всех Бади нод, что 2д что 3д. Сфера применения очень узкая походу, я их юзаю только для мелкой шняги типа гиблетов врагов/объектов.
>>4572 (Del)
Оооо, перекатываю свой проект на эту версию.
Алсо, сделали раздельную загрузку export template.
>>4622
Пофиг на него, ничего особенно важного не было, платность ассетов не сделает их лучше/надёжнее. Отключил себе вкладку "Asset Library" в редакторе несколько лет назад и вообще туда не заглядываю. Беспокоит только, что будет засилье кабанчиков, и энтузиасты могут испугаться и сбежать из-за них...
RigidBody - это полная симуляция реального тела (с бесконечной твёрдостью), с рядом упрощений ради оптимизации вычислений в реальном времени. Взаимодействие с ними должно быть посредством приложения сил или импульсов, которые движок интегрирует в свои вычисления каждый тик... Если попытаешься менять transform напрямую, то это, очевидно, нарушает формулы симуляции в движке, поэтому нужно управлять через приложение сил.
Если ты уже применял силы вместо трансформа, то, возможно, ты запутался со вторым параметром - он нелогично описан в документации. Чтоб применить правильно, нужно взять глобальную точку и из неё вычитать глобальную позицию самого объекта:
Здесь мы прикладываем силу в 1 единицу строго в направлении вверх от позиции ноды anchor, которая находится в потомках RigidBody3D body. Тело должно повернуться так, будто оно подвешено за эту точку.
После того, как запомнишь и будешь следовать этим правилам, особых проблем с физикой быть у тебя не должно, особенно на Jolt, который весьма стабилен. GodotPhysics имеет кучу проблем стабильности, в особенности при использовании joint-ов - почему-то трясутся и разрываются/разлетаются в стороны...
Проблемы с коллизиями не зависят от того, что ты используешь: если баг в коллизиях, тогда любой код CharacterBody пострадает не меньше, чем RigidBody.
Можно сделать персонажа целиком на RigidBody, и некоторые игры именно так и делают; там обычно специфический геймплей по правилам физики, а не банальный "шутер от первого лица", но в принципе, заставить RigidBody вести себя как кинематик (CharacterBody) возможно, хоть и сложнее.
Алсо, лайфхак: если хочешь поведение RigidBody у CharacterBody или AnimatableBody, то можно юзать RemoteTransform для точной копии компонентов трансформа или написать свой код, который будет передвигать одно тело к другому. Можно настроить физические слои так, что RigidBody неосязаем, но полностью ощущает все геймплейные препятствия.
В общем, инструмент мощный, но только если ты понимаешь, как им пользоваться, и если движок достаточно стабилен, чтоб объекты не улетали...
А ещё в Godot есть SoftBody, это для тканей всяких. Насколько я понимаю, там всё намного сложнее и проблемнее, но сам я их никогда не трогал (только в блендере с симуляцией тканей возился немного, но там-то она не в реальном времени вычисляется).
>превью шейдеров
Оооо, перекатываю свой проект на эту версию.
Алсо, сделали раздельную загрузку export template.
>>4622
>выжимку по поводу нового ассет стора
Пофиг на него, ничего особенно важного не было, платность ассетов не сделает их лучше/надёжнее. Отключил себе вкладку "Asset Library" в редакторе несколько лет назад и вообще туда не заглядываю. Беспокоит только, что будет засилье кабанчиков, и энтузиасты могут испугаться и сбежать из-за них...
>Сфера применения очень узкая походу
RigidBody - это полная симуляция реального тела (с бесконечной твёрдостью), с рядом упрощений ради оптимизации вычислений в реальном времени. Взаимодействие с ними должно быть посредством приложения сил или импульсов, которые движок интегрирует в свои вычисления каждый тик... Если попытаешься менять transform напрямую, то это, очевидно, нарушает формулы симуляции в движке, поэтому нужно управлять через приложение сил.
Если ты уже применял силы вместо трансформа, то, возможно, ты запутался со вторым параметром - он нелогично описан в документации. Чтоб применить правильно, нужно взять глобальную точку и из неё вычитать глобальную позицию самого объекта:
>body.apply_force(Vector3.UP, anchor.global_position - body.global_position)
Здесь мы прикладываем силу в 1 единицу строго в направлении вверх от позиции ноды anchor, которая находится в потомках RigidBody3D body. Тело должно повернуться так, будто оно подвешено за эту точку.
После того, как запомнишь и будешь следовать этим правилам, особых проблем с физикой быть у тебя не должно, особенно на Jolt, который весьма стабилен. GodotPhysics имеет кучу проблем стабильности, в особенности при использовании joint-ов - почему-то трясутся и разрываются/разлетаются в стороны...
Проблемы с коллизиями не зависят от того, что ты используешь: если баг в коллизиях, тогда любой код CharacterBody пострадает не меньше, чем RigidBody.
Можно сделать персонажа целиком на RigidBody, и некоторые игры именно так и делают; там обычно специфический геймплей по правилам физики, а не банальный "шутер от первого лица", но в принципе, заставить RigidBody вести себя как кинематик (CharacterBody) возможно, хоть и сложнее.
Алсо, лайфхак: если хочешь поведение RigidBody у CharacterBody или AnimatableBody, то можно юзать RemoteTransform для точной копии компонентов трансформа или написать свой код, который будет передвигать одно тело к другому. Можно настроить физические слои так, что RigidBody неосязаем, но полностью ощущает все геймплейные препятствия.
В общем, инструмент мощный, но только если ты понимаешь, как им пользоваться, и если движок достаточно стабилен, чтоб объекты не улетали...
А ещё в Godot есть SoftBody, это для тканей всяких. Насколько я понимаю, там всё намного сложнее и проблемнее, но сам я их никогда не трогал (только в блендере с симуляцией тканей возился немного, но там-то она не в реальном времени вычисляется).
>>4572 (Del)
Оооо, перекатываю свой проект на эту версию.
Алсо, сделали раздельную загрузку export template.
>>4622
Пофиг на него, ничего особенно важного не было, платность ассетов не сделает их лучше/надёжнее. Отключил себе вкладку "Asset Library" в редакторе несколько лет назад и вообще туда не заглядываю. Беспокоит только, что будет засилье кабанчиков, и энтузиасты могут испугаться и сбежать из-за них...
RigidBody - это полная симуляция реального тела (с бесконечной твёрдостью), с рядом упрощений ради оптимизации вычислений в реальном времени. Взаимодействие с ними должно быть посредством приложения сил или импульсов, которые движок интегрирует в свои вычисления каждый тик... Если попытаешься менять transform напрямую, то это, очевидно, нарушает формулы симуляции в движке, поэтому нужно управлять через приложение сил.
Если ты уже применял силы вместо трансформа, то, возможно, ты запутался со вторым параметром - он нелогично описан в документации. Чтоб применить правильно, нужно взять глобальную точку и из неё вычитать глобальную позицию самого объекта:
Здесь мы прикладываем силу в 1 единицу строго в направлении вверх от позиции ноды anchor, которая находится в потомках RigidBody3D body. Тело должно повернуться так, будто оно подвешено за эту точку.
После того, как запомнишь и будешь следовать этим правилам, особых проблем с физикой быть у тебя не должно, особенно на Jolt, который весьма стабилен. GodotPhysics имеет кучу проблем стабильности, в особенности при использовании joint-ов - почему-то трясутся и разрываются/разлетаются в стороны...
Проблемы с коллизиями не зависят от того, что ты используешь: если баг в коллизиях, тогда любой код CharacterBody пострадает не меньше, чем RigidBody.
Можно сделать персонажа целиком на RigidBody, и некоторые игры именно так и делают; там обычно специфический геймплей по правилам физики, а не банальный "шутер от первого лица", но в принципе, заставить RigidBody вести себя как кинематик (CharacterBody) возможно, хоть и сложнее.
Алсо, лайфхак: если хочешь поведение RigidBody у CharacterBody или AnimatableBody, то можно юзать RemoteTransform для точной копии компонентов трансформа или написать свой код, который будет передвигать одно тело к другому. Можно настроить физические слои так, что RigidBody неосязаем, но полностью ощущает все геймплейные препятствия.
В общем, инструмент мощный, но только если ты понимаешь, как им пользоваться, и если движок достаточно стабилен, чтоб объекты не улетали...
А ещё в Godot есть SoftBody, это для тканей всяких. Насколько я понимаю, там всё намного сложнее и проблемнее, но сам я их никогда не трогал (только в блендере с симуляцией тканей возился немного, но там-то она не в реальном времени вычисляется).
>превью шейдеров
Оооо, перекатываю свой проект на эту версию.
Алсо, сделали раздельную загрузку export template.
>>4622
>выжимку по поводу нового ассет стора
Пофиг на него, ничего особенно важного не было, платность ассетов не сделает их лучше/надёжнее. Отключил себе вкладку "Asset Library" в редакторе несколько лет назад и вообще туда не заглядываю. Беспокоит только, что будет засилье кабанчиков, и энтузиасты могут испугаться и сбежать из-за них...
>Сфера применения очень узкая походу
RigidBody - это полная симуляция реального тела (с бесконечной твёрдостью), с рядом упрощений ради оптимизации вычислений в реальном времени. Взаимодействие с ними должно быть посредством приложения сил или импульсов, которые движок интегрирует в свои вычисления каждый тик... Если попытаешься менять transform напрямую, то это, очевидно, нарушает формулы симуляции в движке, поэтому нужно управлять через приложение сил.
Если ты уже применял силы вместо трансформа, то, возможно, ты запутался со вторым параметром - он нелогично описан в документации. Чтоб применить правильно, нужно взять глобальную точку и из неё вычитать глобальную позицию самого объекта:
>body.apply_force(Vector3.UP, anchor.global_position - body.global_position)
Здесь мы прикладываем силу в 1 единицу строго в направлении вверх от позиции ноды anchor, которая находится в потомках RigidBody3D body. Тело должно повернуться так, будто оно подвешено за эту точку.
После того, как запомнишь и будешь следовать этим правилам, особых проблем с физикой быть у тебя не должно, особенно на Jolt, который весьма стабилен. GodotPhysics имеет кучу проблем стабильности, в особенности при использовании joint-ов - почему-то трясутся и разрываются/разлетаются в стороны...
Проблемы с коллизиями не зависят от того, что ты используешь: если баг в коллизиях, тогда любой код CharacterBody пострадает не меньше, чем RigidBody.
Можно сделать персонажа целиком на RigidBody, и некоторые игры именно так и делают; там обычно специфический геймплей по правилам физики, а не банальный "шутер от первого лица", но в принципе, заставить RigidBody вести себя как кинематик (CharacterBody) возможно, хоть и сложнее.
Алсо, лайфхак: если хочешь поведение RigidBody у CharacterBody или AnimatableBody, то можно юзать RemoteTransform для точной копии компонентов трансформа или написать свой код, который будет передвигать одно тело к другому. Можно настроить физические слои так, что RigidBody неосязаем, но полностью ощущает все геймплейные препятствия.
В общем, инструмент мощный, но только если ты понимаешь, как им пользоваться, и если движок достаточно стабилен, чтоб объекты не улетали...
А ещё в Godot есть SoftBody, это для тканей всяких. Насколько я понимаю, там всё намного сложнее и проблемнее, но сам я их никогда не трогал (только в блендере с симуляцией тканей возился немного, но там-то она не в реальном времени вычисляется).
>>4622
Сделал на ригидбоди чуть ли не больше игр, чем на кинематичном. Мяч в футболе, игры типа боулинг/гольф/бильярд, где ты пуляешь шары, пара игр с контроллером аля ракета. Гоночки, как на аркадном варианте где машинка это иллюзия на шаре, так и простые, где vehiclebody - а он наследник rigidbody. Туда же авиасим, правда я подзабил, но там тоже подход через наследование от него и воздействующие СИЛЫ через аэродинамические поверхности (уже кто-то и аддон написал за меня, удобно). 3д платформер тоже ради эксперимента делал, там физика больше на астронавта внутри полой земли была, хотя можно было гравитацию и кинематику считать в скрипте.
Сделал на ригидбоди чуть ли не больше игр, чем на кинематичном. Мяч в футболе, игры типа боулинг/гольф/бильярд, где ты пуляешь шары, пара игр с контроллером аля ракета. Гоночки, как на аркадном варианте где машинка это иллюзия на шаре, так и простые, где vehiclebody - а он наследник rigidbody. Туда же авиасим, правда я подзабил, но там тоже подход через наследование от него и воздействующие СИЛЫ через аэродинамические поверхности (уже кто-то и аддон написал за меня, удобно). 3д платформер тоже ради эксперимента делал, там физика больше на астронавта внутри полой земли была, хотя можно было гравитацию и кинематику считать в скрипте.
Каждый раз когда я чё-то пытаюсь сделать в 2д я понимаю что в 3д это сделать тупо проще. А на выходе 3д ещё дороже смотреться будет. Ну это не считая UI.
>>4643
У меня обратная ситуация, всю жизнь думал вот бы замутить свой бумер шутер, чтоб всё в тридэ и с модным стильным крэйзи грэфоуни.
Но вот пришла пора вкатываться в хэймдэв, разумеется с простого и понятного ДАЖЕ ДАУНУ годотля... Теперь третий месяц пыхчу над своими двадэшками понимая, что если и решусь пытать 3D, то буду месяцами полировать табуретки, как тот чел со вкусом очка.
У меня обратная ситуация, всю жизнь думал вот бы замутить свой бумер шутер, чтоб всё в тридэ и с модным стильным крэйзи грэфоуни.
Но вот пришла пора вкатываться в хэймдэв, разумеется с простого и понятного ДАЖЕ ДАУНУ годотля... Теперь третий месяц пыхчу над своими двадэшками понимая, что если и решусь пытать 3D, то буду месяцами полировать табуретки, как тот чел со вкусом очка.
136 Кб, mp4,640x352, 0:03
>>4695
А ты решись, там не всё так страшно. Но сначала конечно свой 2д проект доделай быстренько
>что если и решусь пытать 3D
А ты решись, там не всё так страшно. Но сначала конечно свой 2д проект доделай быстренько
>>4572 (Del)
Какой-то слегка проходной релиз в сравнении с предыдущими. Но может хоть не развалится ничего и не придется делать кучу 4.7.x версий. Может даже удастся спокойно переехать?
>feature freeze.
Какой-то слегка проходной релиз в сравнении с предыдущими. Но может хоть не развалится ничего и не придется делать кучу 4.7.x версий. Может даже удастся спокойно переехать?
>>4810
И 2д и 3д страшно, но страшно по своему. А код страшно по другому. Поэтому нечего бояться, надо просто выбрать в чем будешь прокачиваться, что больше лежит душе и вперед. Главное не лениться
И 2д и 3д страшно, но страшно по своему. А код страшно по другому. Поэтому нечего бояться, надо просто выбрать в чем будешь прокачиваться, что больше лежит душе и вперед. Главное не лениться
3 Мб, 800x600Сап, годобояре. Закончил очередную поделку на джем за неделю, можете чекнуть.
В геймплейном плане роста особо нет, однако стиль и графика стала на пару уровней выше. Плюс впервые поработал над постановкой игры — понравилось. Хотел ещё поучаствовать в ludum dare, но оказывается он уже заканчивается, лол.
https://rouw-x.itch.io/miranda-vhs
В геймплейном плане роста особо нет, однако стиль и графика стала на пару уровней выше. Плюс впервые поработал над постановкой игры — понравилось. Хотел ещё поучаствовать в ludum dare, но оказывается он уже заканчивается, лол.
https://rouw-x.itch.io/miranda-vhs
>>4695
Для освоения программирования 2D игры лучше, т.к. позволяют фокусироваться на геймплейном фундаменте игры без возни с матрицами, базисами и кватернионами, и векторные операции там проще представить в голове или по-быстрому набросать от руки. Но не бойся 3D математики - там всё через API делается и не так уж сложно запомнить основные правила, даже в документации есть туториалы. В плане разработки потенциально успешной игры 2D не проще 3D.
Тот анон просто все советы проигнорировал и дрочит на фотореализм, который объективно дольше делать, чем 3D стилизацию (наподобие современного лоуполи). Может, ему так комфортнее - когда делаешь простые hard surface объекты по заранее известному референсу, стараясь скопировать его, прогресс виден чётко и ясно - ты либо сделал табуретку, либо не сделал, никакой неопределённости нет, потому нет и дискомфорта от мысли "а не фигнёй ли ненужной я занимаюсь".
Если хочешь не тратить много времени на 3D, то забудь про реализм и делай лоуполи с простыми текстурами или вообще без текстур. Чтобы графика выглядела приятно, достаточно подобрать удачную цветовую палитру и следовать во всех своих ассетах одному и тому же набору правил, которые ты сам для себя определил или взял из подходящих тебе референсов. Можешь взять бесплатные наборы ассетов в стиле лоуполи, такие легче всего модифицировать под себя и дополнять чем-то своим.
ИМХО, ниша реалистичных 3D игр была переполнена лишними играми ещё лет 10-15 назад, и сейчас трудно с первого взгляда отличить ААА игру про кусты и камни и какого-то мужика в броне с автоматом от дешёвой ассетфлипной индюшки про те же кусты и камни и какого-то мужика в броне с автоматом. Нафига их вообще продолжают делать? Выйдите на улицу, потрогайте реальные кусты и камни, наденьте реальную броню и возьмите в руки реальный автомат... эээ... кхе-кхе...
>третий месяц пыхчу над своими двадэшками
Для освоения программирования 2D игры лучше, т.к. позволяют фокусироваться на геймплейном фундаменте игры без возни с матрицами, базисами и кватернионами, и векторные операции там проще представить в голове или по-быстрому набросать от руки. Но не бойся 3D математики - там всё через API делается и не так уж сложно запомнить основные правила, даже в документации есть туториалы. В плане разработки потенциально успешной игры 2D не проще 3D.
>решусь пытать 3D, то буду месяцами полировать табуретки
Тот анон просто все советы проигнорировал и дрочит на фотореализм, который объективно дольше делать, чем 3D стилизацию (наподобие современного лоуполи). Может, ему так комфортнее - когда делаешь простые hard surface объекты по заранее известному референсу, стараясь скопировать его, прогресс виден чётко и ясно - ты либо сделал табуретку, либо не сделал, никакой неопределённости нет, потому нет и дискомфорта от мысли "а не фигнёй ли ненужной я занимаюсь".
Если хочешь не тратить много времени на 3D, то забудь про реализм и делай лоуполи с простыми текстурами или вообще без текстур. Чтобы графика выглядела приятно, достаточно подобрать удачную цветовую палитру и следовать во всех своих ассетах одному и тому же набору правил, которые ты сам для себя определил или взял из подходящих тебе референсов. Можешь взять бесплатные наборы ассетов в стиле лоуполи, такие легче всего модифицировать под себя и дополнять чем-то своим.
ИМХО, ниша реалистичных 3D игр была переполнена лишними играми ещё лет 10-15 назад, и сейчас трудно с первого взгляда отличить ААА игру про кусты и камни и какого-то мужика в броне с автоматом от дешёвой ассетфлипной индюшки про те же кусты и камни и какого-то мужика в броне с автоматом. Нафига их вообще продолжают делать? Выйдите на улицу, потрогайте реальные кусты и камни, наденьте реальную броню и возьмите в руки реальный автомат... эээ... кхе-кхе...
>>4826
Я б не отказался от игры где можно потрогать реалистичную траву. Но даже современные реалистичные движки не потянут то, что можно увидеть глазами просто отойдя в лес на 100 метров.
Я б не отказался от игры где можно потрогать реалистичную траву. Но даже современные реалистичные движки не потянут то, что можно увидеть глазами просто отойдя в лес на 100 метров.
>>4800
Прошелся. Да ну как-то не. В 4.6 были крутые IK и фичи для рендеринга, в 4.5 тоже фичи для рендеринга, UID. В 4.7 скорее мелкие QoL фишки, ну разве что прямоугольный свет прикольно и полезно.
Прошелся. Да ну как-то не. В 4.6 были крутые IK и фичи для рендеринга, в 4.5 тоже фичи для рендеринга, UID. В 4.7 скорее мелкие QoL фишки, ну разве что прямоугольный свет прикольно и полезно.
>>4828
А чего бы ты хотел в новой версии? Они вроде недавно жаловались на флуд слоповыми пулл-реквестами, которые трудно разбирать, из-за чего работа усложняется. Многие старые пулл-реквесты наверняка ещё недостаточно протестированы или вообще недоделаны.
Если хочешь больше фич - заходи в пулл-реквесты, тестируй их на своей сборке движка и отчитывайся там о найденных багах или проблемах. Так автору пулл-реквеста будет проще довести его до хорошего состояния и, возможно, его примут в движок раньше.
А чего бы ты хотел в новой версии? Они вроде недавно жаловались на флуд слоповыми пулл-реквестами, которые трудно разбирать, из-за чего работа усложняется. Многие старые пулл-реквесты наверняка ещё недостаточно протестированы или вообще недоделаны.
Если хочешь больше фич - заходи в пулл-реквесты, тестируй их на своей сборке движка и отчитывайся там о найденных багах или проблемах. Так автору пулл-реквеста будет проще довести его до хорошего состояния и, возможно, его примут в движок раньше.
>>4832
А я без претензий, в самом деле. Мне Годот очень нравится, люб-дорог, я даже несколько рад, что огромных фич в 4.7 нет. 4.5 и 4.6 не очень стабильные, 4.5 вроде подлатали, а 4.6 разваливается когда проект мигрировать пытаюсь, из-за анимаций. Если бы я чего и хотел, так это выход какой-нибудь ультимативной stable версии без багов и огрехов. Если включить мечтателя, то круто было бы заиметь систему террейна и стриминг как в UE. Знаю, что решения уже есть, но круто было бы иметь что-то унифицированное и работающее из коробки.
А я без претензий, в самом деле. Мне Годот очень нравится, люб-дорог, я даже несколько рад, что огромных фич в 4.7 нет. 4.5 и 4.6 не очень стабильные, 4.5 вроде подлатали, а 4.6 разваливается когда проект мигрировать пытаюсь, из-за анимаций. Если бы я чего и хотел, так это выход какой-нибудь ультимативной stable версии без багов и огрехов. Если включить мечтателя, то круто было бы заиметь систему террейна и стриминг как в UE. Знаю, что решения уже есть, но круто было бы иметь что-то унифицированное и работающее из коробки.
>>4842
4.3
Я на ней продакшон продуцирую.
> выход какой-нибудь ультимативной stable версии без багов и огрехов
4.3
Я на ней продакшон продуцирую.
>>4827
Да даже если через н-десятков лет человечество переедет на фулл-виар гейминг, то "тру реализм" не будет популярен у масс, скорее оставят как брейнденсы из киберпанка для ценителей.
Посуди сам, в трипл-квадрипл-эй играх трава, деревья, вода, закаты и рассветы - всё заточено чтоб быть eye-candy, чтоб выделялась слюна и хотелось там жить и фантазировать как этот шейдер мягкой шёлковой травы щекочет щёки под солнышком средь чиста поля.
А в реале что? Ну выйти в лесополосу можно, да, там обоссанная примятая трава, торчки ищут клады, гавной ваняет, клещи так и норовят лишить жизни если не в ту травинку присядешь. Короче экстрим для потенциального "человека будущего".
Мне потому лоу-поли графон даже ближе к "реальности" кажется, ну висят три травинки на кочке - так и в реале они такие же реденькие и неидеальные, а под ними та же говняная текстура земли в серо-буро-зеленых тонах. Всё как в реальной жизни!
Да даже если через н-десятков лет человечество переедет на фулл-виар гейминг, то "тру реализм" не будет популярен у масс, скорее оставят как брейнденсы из киберпанка для ценителей.
Посуди сам, в трипл-квадрипл-эй играх трава, деревья, вода, закаты и рассветы - всё заточено чтоб быть eye-candy, чтоб выделялась слюна и хотелось там жить и фантазировать как этот шейдер мягкой шёлковой травы щекочет щёки под солнышком средь чиста поля.
А в реале что? Ну выйти в лесополосу можно, да, там обоссанная примятая трава, торчки ищут клады, гавной ваняет, клещи так и норовят лишить жизни если не в ту травинку присядешь. Короче экстрим для потенциального "человека будущего".
Мне потому лоу-поли графон даже ближе к "реальности" кажется, ну висят три травинки на кочке - так и в реале они такие же реденькие и неидеальные, а под ними та же говняная текстура земли в серо-буро-зеленых тонах. Всё как в реальной жизни!
2,1 Мб, 1839x641>>4847
У меня сейчас под рукой нет фото, вот пик из интернета чтобы понимать
У меня сейчас под рукой нет фото, вот пик из интернета чтобы понимать
>>4849
Гавно графен уровня 2008го))
Гавно графен уровня 2008го))
>>4843
С 4.3 до 4.5 и 4.6 оч много классного добавили. И кучу багофиксов и оптимизаций. Но 4.3 подозреваю где-то стабильнее, да.
С 4.3 до 4.5 и 4.6 оч много классного добавили. И кучу багофиксов и оптимизаций. Но 4.3 подозреваю где-то стабильнее, да.
Как запретить игроку пикрилы?
Кто-нибудь помнит?
Я забыл...
Кто-нибудь помнит?
Я забыл...
>>4572 (Del)
Эх, превью только для fragment-шейдера работает, и только для строчек, присваивающих какое-то значение какой-то переменной. Но и то достаточно полезно будет, особенно для 2D эффектов.
Ещё заметил, что они опять дизайн консоли вывода изменили. Теперь кнопки снизу, на строчке фильтра/поиска, и консоль по умолчанию имеет очень мелкий размер, строчки 3 или 4 всего. Не пугайтесь, все функции вроде бы на месте, только положение кнопок непривычное.
Мне они пока не нужны, но я всё равно пощупал AreaLight3D. Вообще не понял смысла этой ноды - свет кажется почти неотличимым от SpotLight3D с шириной около 90 градусов. Какая-то разница заметна только на тенях - у Area тени более размытые по умолчанию и, внезапно, без артефактов. На демонстрационной сцене, видимо, установлены полигоны с высоким emission, а не только лишь AreaLight3D? Я-то думал, AreaLight3D сама создаст светящийся прямоугольник, а она невидимая... Впрочем, это точно как с другими лампочками: SpotLight3D не видно без меша-фонарика... В настройках ноды AreaLight3D позволяет установить текстуру, и она как-то вроде влияет на свет, но мне не удалось увидеть какой-то особой разницы с, например, круглым "фильтром" (использовал GradientTexture2D). Почему?.. Странная нода - вроде нужная, а вроде и нет...
Также заметил, что убрали кнопку быстрой смены рендерера из правого верхнего угла... Думаю, правильно сделали, т.к. всё равно перезапуск редактора требовался, и вряд ли кому-то нужно так часто переключать рендереры, если они не делают игру одновременно под несколько платформ.
Оптимизация отображения массивов в инспекторе - самая лучшая фича этой версии, лол. Наконец-то можно нормально видеть значения в массиве даже с узким инспектором, а не какие-то огрызки, ради просмотра которых инспектор приходилось очень сильно растягивать. И почему раньше не сделали...
Эх, превью только для fragment-шейдера работает, и только для строчек, присваивающих какое-то значение какой-то переменной. Но и то достаточно полезно будет, особенно для 2D эффектов.
Ещё заметил, что они опять дизайн консоли вывода изменили. Теперь кнопки снизу, на строчке фильтра/поиска, и консоль по умолчанию имеет очень мелкий размер, строчки 3 или 4 всего. Не пугайтесь, все функции вроде бы на месте, только положение кнопок непривычное.
Мне они пока не нужны, но я всё равно пощупал AreaLight3D. Вообще не понял смысла этой ноды - свет кажется почти неотличимым от SpotLight3D с шириной около 90 градусов. Какая-то разница заметна только на тенях - у Area тени более размытые по умолчанию и, внезапно, без артефактов. На демонстрационной сцене, видимо, установлены полигоны с высоким emission, а не только лишь AreaLight3D? Я-то думал, AreaLight3D сама создаст светящийся прямоугольник, а она невидимая... Впрочем, это точно как с другими лампочками: SpotLight3D не видно без меша-фонарика... В настройках ноды AreaLight3D позволяет установить текстуру, и она как-то вроде влияет на свет, но мне не удалось увидеть какой-то особой разницы с, например, круглым "фильтром" (использовал GradientTexture2D). Почему?.. Странная нода - вроде нужная, а вроде и нет...
Также заметил, что убрали кнопку быстрой смены рендерера из правого верхнего угла... Думаю, правильно сделали, т.к. всё равно перезапуск редактора требовался, и вряд ли кому-то нужно так часто переключать рендереры, если они не делают игру одновременно под несколько платформ.
Оптимизация отображения массивов в инспекторе - самая лучшая фича этой версии, лол. Наконец-то можно нормально видеть значения в массиве даже с узким инспектором, а не какие-то огрызки, ради просмотра которых инспектор приходилось очень сильно растягивать. И почему раньше не сделали...
>>4858
Ну потом, когда выйдет стейбл, покажу вам как с areaLight будет выглядеть. Но хз, меня и так пока устраивает, все равно это не подразумевалось как световые мечи
Ну потом, когда выйдет стейбл, покажу вам как с areaLight будет выглядеть. Но хз, меня и так пока устраивает, все равно это не подразумевалось как световые мечи
>>4896
Вот для такого невообразимого скота мы и делаем игры. Точнее вы делаете. А я ебал. Нахуй.
Вот для такого невообразимого скота мы и делаем игры. Точнее вы делаете. А я ебал. Нахуй.
37 Кб, 540x400>>4911
Что там было? Что-то плохое?
В настоящем киберпанке живём: все развлечения запрещены большим братом, но можно попросить электронный сверхразум, но он ничего не умеет...
>>4572 (Del)
>>4858
Анон ошибся в посте, а вы не поняли?
AreaLight3D светит только в одну сторону. Для меча потребуется минимум 2, а то и 4, если он толстый. И материал с высоким emission по-прежнему нужен, поскольку без него источник света будет невидим. Единственный плюс - это мягкие тени без глюков. Пиксельный шейдер эти тени всё равно скукожит...
>>4859
Да вроде уже сейчас неплохо работает...
Учитывай, что AreaLight3D - это для forward+, а для остальных хуже будет работать (я не проверял, но в документации ноды много каких-то ограничений). В пиксельном стиле вообще бессмысленно, имхо...
Что там было? Что-то плохое?
В настоящем киберпанке живём: все развлечения запрещены большим братом, но можно попросить электронный сверхразум, но он ничего не умеет...
>>4572 (Del)
>прямоугольные омнилайты
>>4858
>сделать световой меч
Анон ошибся в посте, а вы не поняли?
AreaLight3D светит только в одну сторону. Для меча потребуется минимум 2, а то и 4, если он толстый. И материал с высоким emission по-прежнему нужен, поскольку без него источник света будет невидим. Единственный плюс - это мягкие тени без глюков. Пиксельный шейдер эти тени всё равно скукожит...
>>4859
>когда выйдет стейбл
Да вроде уже сейчас неплохо работает...
Учитывай, что AreaLight3D - это для forward+, а для остальных хуже будет работать (я не проверял, но в документации ноды много каких-то ограничений). В пиксельном стиле вообще бессмысленно, имхо...
1,2 Мб, mp4,192x144, 1:18
>>4923
Там 3gp с кнопочной мобилки
А ты не пробовал через архив интернета смотреть?
я б написал еще несколько простых способов, но тут неуместно наверное
Там 3gp с кнопочной мобилки
А ты не пробовал через архив интернета смотреть?
я б написал еще несколько простых способов, но тут неуместно наверное
![прогноз погоды [lJcATSomuXM].mp4](https://2ch.life/gd/thumb/1083400/17766914661990316634s.jpg)
1,2 Мб, mp4,192x144, 1:18
>>4923
купи впску за 300 руб/мес и накати туда amnezia vpn
честно говоря не понял в чем суть такой острой реакции, возможно это просто бот который хуйней бампает треды
купи впску за 300 руб/мес и накати туда amnezia vpn
честно говоря не понял в чем суть такой острой реакции, возможно это просто бот который хуйней бампает треды
>>4925
Потому что ты такое же гыгыкающее быдло, как и аффтар этой дрисни. Ты искренне удивлён "а чё не так та, ёпта, нах?" До тебя даже не доходит, какое это омерзительное скотство.
> не понял в чем суть такой острой реакции
Потому что ты такое же гыгыкающее быдло, как и аффтар этой дрисни. Ты искренне удивлён "а чё не так та, ёпта, нах?" До тебя даже не доходит, какое это омерзительное скотство.
>>4931
У меня кстати симулятор арий недоделан.
У меня кстати симулятор арий недоделан.
>>4924 >>4925
Спасибо, улыбнулся.
Чтобы потом круглый день сидеть на этом ютубе и спонтанно кликать на каждую рекомендацию, потом очнуться в 18:00 утра следующего дня с кучей новых вкладок браузера, содержание которых не помнишь, мучаясь от обезвоживания, голода и бессонницы? И десятками гигабайт скачанной с ютуба порнухи...
Ты запостил какие-то круги и написал "навайбкодил". Непонятно, что это означает? Ты попросил ChatGPT нарисовать тебе круги? И потом запостил сюда PNG? Странный пост. Хоть бы объяснил, чего ты хочешь. И непонятно ещё, зачем ты запостил это в ответ тому, который свою игру на итч опубликовал. Где смысл?
>>4927
Завязывай с
Тред любви же, мы должны быть добрее ко всем.
Спасибо, улыбнулся.
>за 300 руб/мес
Чтобы потом круглый день сидеть на этом ютубе и спонтанно кликать на каждую рекомендацию, потом очнуться в 18:00 утра следующего дня с кучей новых вкладок браузера, содержание которых не помнишь, мучаясь от обезвоживания, голода и бессонницы? И десятками гигабайт скачанной с ютуба порнухи...
>не понял в чем суть такой острой реакции
Ты запостил какие-то круги и написал "навайбкодил". Непонятно, что это означает? Ты попросил ChatGPT нарисовать тебе круги? И потом запостил сюда PNG? Странный пост. Хоть бы объяснил, чего ты хочешь. И непонятно ещё, зачем ты запостил это в ответ тому, который свою игру на итч опубликовал. Где смысл?
>>4927
Завязывай с
>гыгыкающее быдло
>омерзительное скотство
Тред любви же, мы должны быть добрее ко всем.
>>4937
В треде любви и добра придётся относиться с пониманием к таким, кто улыбается с этого скотобожества.
> Спасибо, улыбнулся.
В треде любви и добра придётся относиться с пониманием к таким, кто улыбается с этого скотобожества.
Собираю движок из сурса, никогда раньше таким не занимался, я хлебушек. Получится из под винды собрать экспорт темплейты под все платформы или придется сильно пердолиться? Нужно ли WSL поднимать, чтобы скомпилить шаблоны под Линух? Доки немного в ступор ввели. И честно говоря, в линухе столько дистров, что и непонятно под какой компилить. Как вы решаете эту проблему?
>>4947
Хватит одной виртуалки с одним дистрибутивом, чтобы собрать под разные дистрибутивы Линукса? Если на Hyper-V подниму Убунту, этого достаточно? А как с МакОС быть, например?
Хватит одной виртуалки с одним дистрибутивом, чтобы собрать под разные дистрибутивы Линукса? Если на Hyper-V подниму Убунту, этого достаточно? А как с МакОС быть, например?
>>4940
Да ты какой-то махровый илитарий застрявший в позапрошлом десятилетии. Ну либо школотрон-ситх возводящий всё в абсолют.
Да ты какой-то махровый илитарий застрявший в позапрошлом десятилетии. Ну либо школотрон-ситх возводящий всё в абсолют.
>>4942
Зачем тебе под все платформы сразу?
Под веб и Android точно получится, под iOS - нет.
Под Linux можно через WSL. Дистрибутив не важен.
Про Mac без понятия, но это очень редкая система...
А для чего собираешь? Какой-то особый модуль?
>>4950 (Del)
И насколько это удлиняет загрузку игры?
А что ты делаешь при повторном запуске?
>>4938
Ностальгия по временам ИК-портов в телефонах...
Зачем тебе под все платформы сразу?
Под веб и Android точно получится, под iOS - нет.
Под Linux можно через WSL. Дистрибутив не важен.
Про Mac без понятия, но это очень редкая система...
А для чего собираешь? Какой-то особый модуль?
>>4950 (Del)
И насколько это удлиняет загрузку игры?
А что ты делаешь при повторном запуске?
>>4938
>кто улыбается с этого скотобожества
Ностальгия по временам ИК-портов в телефонах...
>>4953
Так ведь лучше сбилдить под все возможные, разве нет? Так удобнее потенциальному игроку.
Вырезал ненужный мне функционал, оптимизировав размер, и прикрутил пару экстеншенов для удобства, да. Ничего особо сложного, но нужный шаг.
> Зачем тебе под все платформы сразу?
Так ведь лучше сбилдить под все возможные, разве нет? Так удобнее потенциальному игроку.
> А для чего собираешь? Какой-то особый модуль?
Вырезал ненужный мне функционал, оптимизировав размер, и прикрутил пару экстеншенов для удобства, да. Ничего особо сложного, но нужный шаг.
>>4942
Попробуй github actions, они же собирают все билды, сам годот же там собирается вроде под все ОС. Если правильно понимаю, если ты сделаешь публичный форк - то бесплатно, а если приватная репа - сколько то раз в месяц, но часто тебе и не нужно.
Попробуй github actions, они же собирают все билды, сам годот же там собирается вроде под все ОС. Если правильно понимаю, если ты сделаешь публичный форк - то бесплатно, а если приватная репа - сколько то раз в месяц, но часто тебе и не нужно.
>>4950 (Del)
Где можно подробнее про это изучить/почитать?
Где можно подробнее про это изучить/почитать?
27 Кб, 707x284>>4950 (Del)
Ну то есть вернулись к технике 3-й версии пятилетней давности с вращающимся под землей кубом.
Ну то есть вернулись к технике 3-й версии пятилетней давности с вращающимся под землей кубом.
>>4968
Спасибо, полезное.
Спасибо, полезное.
>>4968
Жесть какая. Для двадэ тоже таким надо обмазываться? Вот я запилил шейдер дисторшена на сцену Explosion, собсно при каждом взрыве эта сцена инстанциируется. В целом вроде норм, но емнип сталкивался с микрофризом при первом взрыве после запуска игры. Это я трясунчик и мне показалось, или реал придётся вкатываться в этот костылинг?
Жесть какая. Для двадэ тоже таким надо обмазываться? Вот я запилил шейдер дисторшена на сцену Explosion, собсно при каждом взрыве эта сцена инстанциируется. В целом вроде норм, но емнип сталкивался с микрофризом при первом взрыве после запуска игры. Это я трясунчик и мне показалось, или реал придётся вкатываться в этот костылинг?
>>4973
Конечно. 2D, 3D шейдеры - это одно и то же где-то под капотом, отличия лишь во внешнем API, упрощающем некоторые операции. Не парься, шейдеры хранятся на компьютере игрока, и после первого запуска таких микрофризов не будет, если игрок не очистит кэш.
>>4964 (Del)
Я б предпочёл видеть, как игровой мир постепенно погружается вокруг игрового персонажа, чем ждать мучительно долгой загрузки, теряя интерес к игре...
>>4957
Wine есть и на линуксе, и на маке. А для мобилок и браузеров требуется мудрить с графикой и UI/UX, в противном случае неудобно/невозможно играть. Нативные билды - это хорошо, но не прям такая уж необходимость для каждой инди-поделки v.0.0.1.
Сегодня ненужный, а завтра опять билдить...
Для десктопа это давно уже не имеет значения.
Если они работают только в редакторе, и не имеют отношения к самой игре, то тебе нужен editor build, а шаблоны экспорта можешь юзать официальные. Кастомные шаблоны экспорта нужны только если используешь модули, меняющие работу движка в процессе геймплея или загрузки ресурсов.
Конечно. 2D, 3D шейдеры - это одно и то же где-то под капотом, отличия лишь во внешнем API, упрощающем некоторые операции. Не парься, шейдеры хранятся на компьютере игрока, и после первого запуска таких микрофризов не будет, если игрок не очистит кэш.
>>4964 (Del)
Я б предпочёл видеть, как игровой мир постепенно погружается вокруг игрового персонажа, чем ждать мучительно долгой загрузки, теряя интерес к игре...
>>4957
>лучше сбилдить под все возможные
Wine есть и на линуксе, и на маке. А для мобилок и браузеров требуется мудрить с графикой и UI/UX, в противном случае неудобно/невозможно играть. Нативные билды - это хорошо, но не прям такая уж необходимость для каждой инди-поделки v.0.0.1.
>ненужный мне функционал
Сегодня ненужный, а завтра опять билдить...
>оптимизировав размер
Для десктопа это давно уже не имеет значения.
>прикрутил пару экстеншенов для удобства
Если они работают только в редакторе, и не имеют отношения к самой игре, то тебе нужен editor build, а шаблоны экспорта можешь юзать официальные. Кастомные шаблоны экспорта нужны только если используешь модули, меняющие работу движка в процессе геймплея или загрузки ресурсов.
>>4962
Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты. А мне как раз темплейты нужно скомпилить, там такое не удастся сделать.
>>4976
Тоже правда. Вообще я почитал, оказывается, не редкость ситуация, когда через Wine работает лучше, чем нативно. С чем связано - не знаю, но много такого встретил пока изучал. Пожалуй, действительно пока обойдусь одним билдом. Так и поддерживать легче, а на мобилки я лезть не планирую, там в одну сторону дорога...
Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты. А мне как раз темплейты нужно скомпилить, там такое не удастся сделать.
>>4976
> Wine есть и на линуксе, и на маке
Тоже правда. Вообще я почитал, оказывается, не редкость ситуация, когда через Wine работает лучше, чем нативно. С чем связано - не знаю, но много такого встретил пока изучал. Пожалуй, действительно пока обойдусь одним билдом. Так и поддерживать легче, а на мобилки я лезть не планирую, там в одну сторону дорога...
>>4984 (Del)
Шейдеры - это ресурсы. Если хранить их отдельно файлами ты можешь пройтись чисто по шейдерам, не трогая сцены, а потом сцена, когда будет загружаться, она увидит, что её шейдеры уже загружены и возьмёт их. Потому что ресурсы - синглтон.
> Можешь скриптом пройтись по списку сцен и динамически их подтянуть в кешинг рум.
Шейдеры - это ресурсы. Если хранить их отдельно файлами ты можешь пройтись чисто по шейдерам, не трогая сцены, а потом сцена, когда будет загружаться, она увидит, что её шейдеры уже загружены и возьмёт их. Потому что ресурсы - синглтон.
131 Кб, 1082x724>>4978
Хз с чего ты это вхял. Там билдится все.
>Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты
Хз с чего ты это вхял. Там билдится все.
>>5003
Спасибо. Действительно, я каким-то образом в другом источнике смотрел. Изучу вопрос с github actions.
Спасибо. Действительно, я каким-то образом в другом источнике смотрел. Изучу вопрос с github actions.
>>5006
Я когда разбирался, работало вроде так. Делал форк репы, вносил свои изменения. Когда в репу прилетает новый коммит, вызывается ребилд всего. Я у себя отключал ненужные платформы соответственно.
Можно переделать на какой то другой способ, чтобы запускать вручную, но мне было лень.
Я когда разбирался, работало вроде так. Делал форк репы, вносил свои изменения. Когда в репу прилетает новый коммит, вызывается ребилд всего. Я у себя отключал ненужные платформы соответственно.
Можно переделать на какой то другой способ, чтобы запускать вручную, но мне было лень.
Изучаем проблематику:
https://www.youtube.com/watch?v=HciqfEeUFSw
https://www.youtube.com/watch?v=HciqfEeUFSw
>>4978
Если тебе интересно, на пикрилах результаты опроса пользователей Godot за 2020 и 2025 годы. Как видно, большинство работает на/таргетит Windows; Linux по популярности второй за счёт большей доступности; экспортируют на Mac больше, чем работают на нём (наверняка с помощью стандартных шаблонов).
>>4992
Это неправда, потому что их можно дублировать, и доступность ограничена локальностью. Тот факт, что загрузчик данных не делает повторных чтений, не превращает класс ресурса в "синглтон". По смыслу к синглтонам ближе всего static var/func, но это другое.
Для этого нужно где-то сохранить ссылку на ресурс. Отдельная от компиляции шейдеров тема, но тоже полезная, особенно касательно системы частиц - она микрофризи(т/ла) при каждом чтении с диска, т.е. рациональнее держать ссылку и не отпускать.
Если кому-то интересно, я недавно осознал, что нет необходимости выводить материалы и частицы в основном Viewport сцены и затем перекрывать его непрозрачной заслонкой. Можно использовать SubViewport, главное настроить его как-то так:
- чтобы не было бесполезной нагрузки;
- чтобы рендерилось без отображения;
- чтобы скрыть объекты от основного.
Дальше добавляем ноды:
Созданную текстуру просто игнорируем.
Я не проверял пока, но такой подход должен быть эффективнее, чем основной вьюпорт. Если он вдруг откажется работать, попробуйте увеличить size до небольшого размера в степени двойки (x16, x32).
>>5021
Пиши сразу описание видео и своё мнение.
А то твои ссылки на ютуб выглядят как спам...
Если тебе интересно, на пикрилах результаты опроса пользователей Godot за 2020 и 2025 годы. Как видно, большинство работает на/таргетит Windows; Linux по популярности второй за счёт большей доступности; экспортируют на Mac больше, чем работают на нём (наверняка с помощью стандартных шаблонов).
>>4992
>Потому что ресурсы - синглтон.
Это неправда, потому что их можно дублировать, и доступность ограничена локальностью. Тот факт, что загрузчик данных не делает повторных чтений, не превращает класс ресурса в "синглтон". По смыслу к синглтонам ближе всего static var/func, но это другое.
>увидит, что её шейдеры уже загружены
Для этого нужно где-то сохранить ссылку на ресурс. Отдельная от компиляции шейдеров тема, но тоже полезная, особенно касательно системы частиц - она микрофризи(т/ла) при каждом чтении с диска, т.е. рациональнее держать ссылку и не отпускать.
Если кому-то интересно, я недавно осознал, что нет необходимости выводить материалы и частицы в основном Viewport сцены и затем перекрывать его непрозрачной заслонкой. Можно использовать SubViewport, главное настроить его как-то так:
>size = Vector2i.ONE
- чтобы не было бесполезной нагрузки;
>render_target_update_mode = UPDATE_ALWAYS
- чтобы рендерилось без отображения;
>own_world_3d = true
- чтобы скрыть объекты от основного.
Дальше добавляем ноды:
>SubViewport
>_ Camera3D
>_ то, что рендерим
Созданную текстуру просто игнорируем.
Я не проверял пока, но такой подход должен быть эффективнее, чем основной вьюпорт. Если он вдруг откажется работать, попробуйте увеличить size до небольшого размера в степени двойки (x16, x32).
>>5021
Пиши сразу описание видео и своё мнение.
А то твои ссылки на ютуб выглядят как спам...
>>4978
Если тебе интересно, на пикрилах результаты опроса пользователей Godot за 2020 и 2025 годы. Как видно, большинство работает на/таргетит Windows; Linux по популярности второй за счёт большей доступности; экспортируют на Mac больше, чем работают на нём (наверняка с помощью стандартных шаблонов).
>>4992
Это неправда, потому что их можно дублировать, и доступность ограничена локальностью. Тот факт, что загрузчик данных не делает повторных чтений, не превращает класс ресурса в "синглтон". По смыслу к синглтонам ближе всего static var/func, но это другое.
Для этого нужно где-то сохранить ссылку на ресурс. Отдельная от компиляции шейдеров тема, но тоже полезная, особенно касательно системы частиц - она микрофризи(т/ла) при каждом чтении с диска, т.е. рациональнее держать ссылку и не отпускать.
Если кому-то интересно, я недавно осознал, что нет необходимости выводить материалы и частицы в основном Viewport сцены и затем перекрывать его непрозрачной заслонкой. Можно использовать SubViewport, главное настроить его как-то так:
- чтобы не было бесполезной нагрузки;
- чтобы рендерилось без отображения;
- чтобы скрыть объекты от основного.
Дальше добавляем ноды:
Созданную текстуру просто игнорируем.
Я не проверял пока, но такой подход должен быть эффективнее, чем основной вьюпорт. Если он вдруг откажется работать, попробуйте увеличить size до небольшого размера в степени двойки (x16, x32).
>>5021
Пиши сразу описание видео и своё мнение.
А то твои ссылки на ютуб выглядят как спам...
Если тебе интересно, на пикрилах результаты опроса пользователей Godot за 2020 и 2025 годы. Как видно, большинство работает на/таргетит Windows; Linux по популярности второй за счёт большей доступности; экспортируют на Mac больше, чем работают на нём (наверняка с помощью стандартных шаблонов).
>>4992
>Потому что ресурсы - синглтон.
Это неправда, потому что их можно дублировать, и доступность ограничена локальностью. Тот факт, что загрузчик данных не делает повторных чтений, не превращает класс ресурса в "синглтон". По смыслу к синглтонам ближе всего static var/func, но это другое.
>увидит, что её шейдеры уже загружены
Для этого нужно где-то сохранить ссылку на ресурс. Отдельная от компиляции шейдеров тема, но тоже полезная, особенно касательно системы частиц - она микрофризи(т/ла) при каждом чтении с диска, т.е. рациональнее держать ссылку и не отпускать.
Если кому-то интересно, я недавно осознал, что нет необходимости выводить материалы и частицы в основном Viewport сцены и затем перекрывать его непрозрачной заслонкой. Можно использовать SubViewport, главное настроить его как-то так:
>size = Vector2i.ONE
- чтобы не было бесполезной нагрузки;
>render_target_update_mode = UPDATE_ALWAYS
- чтобы рендерилось без отображения;
>own_world_3d = true
- чтобы скрыть объекты от основного.
Дальше добавляем ноды:
>SubViewport
>_ Camera3D
>_ то, что рендерим
Созданную текстуру просто игнорируем.
Я не проверял пока, но такой подход должен быть эффективнее, чем основной вьюпорт. Если он вдруг откажется работать, попробуйте увеличить size до небольшого размера в степени двойки (x16, x32).
>>5021
Пиши сразу описание видео и своё мнение.
А то твои ссылки на ютуб выглядят как спам...
А прикинь, игра: GODOTA
Там, карочи, играешь за менеджера, в качестве оружия у тебя шина сигналов, на спине у тебя сидит синглтон и играет в змейку!
Там, карочи, играешь за менеджера, в качестве оружия у тебя шина сигналов, на спине у тебя сидит синглтон и играет в змейку!
>>1082595 →
https://www.youtube.com/watch?v=xPLbrgEQLqA
Красивое показывают
>Ребят, а где можно посмотреть нормальную архитектуру игр на годот?
https://www.youtube.com/watch?v=xPLbrgEQLqA
Красивое показывают
512 Кб, 1150x608Когда закончу с игровыми механиками, хочу запилить свою модель персонажа и перенести скелет, чтобы реюзнуть анимации гобота из gdquest-пака с персонажами.
1. Есть ли какие-либо автоматизированные инструменты для этого?
2. Какие подводные камни могут ожидать и как их обойти?
1. Есть ли какие-либо автоматизированные инструменты для этого?
2. Какие подводные камни могут ожидать и как их обойти?
>>5333
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/retargeting_3d_skeletons.html
Для Blender ищи аддон по "animation retargeting".
Насколько я понимаю (не разобрался до конца):
1. Скелет должен иметь ту же структуру костей. Т.е. автоматически подстраивается только трансформ.
2. Анимации могут не подходить по смыслу/стилю - например, в оригинале чибик (как у тебя на скрине), а пытаешься натянуть на нормального => будет фигня.
3. Если твой персонаж имеет дополнительные фичи, придётся возиться с комбинированием анимаций в AnimationTree... Я так делал только из одного файла, понятия не имею, можно ли из разных источников.
Из моего опыта: сделать новую анимацию на готовом персонаже с правильным скелетом - несложно, нужно только учитывать принципы анимации и знать, что ты пытаешься изобразить (найти референсы, если надо). Заригать персонажа - вот это геморрой ещё тот, т.к. замечаешься править косяки через weight painting.
Т.е. не бойся анимировать своими руками, если не получится взять готовое, а риггинг уже сделан. Для упрощённого чибика риггинг вроде бы несложный.
>1. Есть ли какие-либо автоматизированные инструменты для этого?
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/retargeting_3d_skeletons.html
Для Blender ищи аддон по "animation retargeting".
>2. Какие подводные камни могут ожидать и как их обойти?
Насколько я понимаю (не разобрался до конца):
1. Скелет должен иметь ту же структуру костей. Т.е. автоматически подстраивается только трансформ.
2. Анимации могут не подходить по смыслу/стилю - например, в оригинале чибик (как у тебя на скрине), а пытаешься натянуть на нормального => будет фигня.
3. Если твой персонаж имеет дополнительные фичи, придётся возиться с комбинированием анимаций в AnimationTree... Я так делал только из одного файла, понятия не имею, можно ли из разных источников.
Из моего опыта: сделать новую анимацию на готовом персонаже с правильным скелетом - несложно, нужно только учитывать принципы анимации и знать, что ты пытаешься изобразить (найти референсы, если надо). Заригать персонажа - вот это геморрой ещё тот, т.к. замечаешься править косяки через weight painting.
Т.е. не бойся анимировать своими руками, если не получится взять готовое, а риггинг уже сделан. Для упрощённого чибика риггинг вроде бы несложный.
>>5333
Тебе не нужен никакой инструмент. Если ты используешь тот же скелет, то анимации будут работать. Анимации привязываются непосредственно к скелету, к костям, а не к мешам (3D модели). Тебе нужно будет привязать саму модель к скелету, настроить коэффициенты весов. Изучай такие понятия как skinning, weight painting. Процесс переноса анимаций с одного скелета на другой называется ретаргентингом (retargeting), но это не тот случай.
В целом никаких, разве что ты ограничен существующим скелетом и особо отличную по пропорциям модель ты не сделаешь. Это будет скорее рескин/надстройка над существующим персонажем, чем что-то концептуально новое. Также это легко обнаруживается, так что лучше посмотри на лицензию в gdquest паке, чтобы не попасть в просак по авторским правам.
> 1. Есть ли какие-либо автоматизированные инструменты для этого?
Тебе не нужен никакой инструмент. Если ты используешь тот же скелет, то анимации будут работать. Анимации привязываются непосредственно к скелету, к костям, а не к мешам (3D модели). Тебе нужно будет привязать саму модель к скелету, настроить коэффициенты весов. Изучай такие понятия как skinning, weight painting. Процесс переноса анимаций с одного скелета на другой называется ретаргентингом (retargeting), но это не тот случай.
> 2. Какие подводные камни могут ожидать и как их обойти?
В целом никаких, разве что ты ограничен существующим скелетом и особо отличную по пропорциям модель ты не сделаешь. Это будет скорее рескин/надстройка над существующим персонажем, чем что-то концептуально новое. Также это легко обнаруживается, так что лучше посмотри на лицензию в gdquest паке, чтобы не попасть в просак по авторским правам.
>>3400 (OP)
Кста! Road to Vostok обсуждали уже? Как он на годоте себя чувствует? А то я без видимокарты сейчас, не проверить. Помню, когда он еще был на юнити, он был ужасен, но это была совсем ранняя версия.
>2
Кста! Road to Vostok обсуждали уже? Как он на годоте себя чувствует? А то я без видимокарты сейчас, не проверить. Помню, когда он еще был на юнити, он был ужасен, но это была совсем ранняя версия.
>>5363
Что-то обсуждали в прошлом треде: >>1083265 →
Критику можешь почитать в движкосрач-треде...
Собсна обсуждать-то тут нечего. Вышел и вышел.
Что-то обсуждали в прошлом треде: >>1083265 →
Критику можешь почитать в движкосрач-треде...
Собсна обсуждать-то тут нечего. Вышел и вышел.
>>5375 (Del)
Ну тут можно догадаться кто подгаживает.
Ну тут можно догадаться кто подгаживает.
>>5398
Кто-кто, шизик из движкосрач-треда, создал 460 акков в стиме, пишет что годот хуёво работает с 300 пустыми скриптами на сишарпе.
Кто-кто, шизик из движкосрач-треда, создал 460 акков в стиме, пишет что годот хуёво работает с 300 пустыми скриптами на сишарпе.
>>5435
Я не делал замеров на эту тему, но факт в том, что объявление пустого _process(delta: float) в скриптах на GDScript может снижать производительность, если использовать этот скрипт на множестве нод.
Учитывая то, что C# компилируется в отдельную динамическую библиотеку, вполне возможно, что обращения к _process и аналогичным функциям даже дороже, чем обращения к пустым _process GDScript.
Я не знаю, какой там шаблон скрипта на C#, но для GDScript Godot по умолчанию предлагает скрипт с объявленными _ready и _process, что, в большинстве случаев, вообще не нужны конкретному скрипту.
Итого, если тот движкосрачер взял "пустой" шаблон и размножил его много раз, а потом через профайлер замерял затраты на обращения - да, возможно, он в действительности наткнулся на этот "недостаток".
Но реальность такова, что тебе не нужно 300 _process, особенно на стороне C#. Обычно твой код реактивен - отвечает на события и бездействует между ответами, поэтому _process не нужен. А C# как числодробилка...
Я не делал замеров на эту тему, но факт в том, что объявление пустого _process(delta: float) в скриптах на GDScript может снижать производительность, если использовать этот скрипт на множестве нод.
Учитывая то, что C# компилируется в отдельную динамическую библиотеку, вполне возможно, что обращения к _process и аналогичным функциям даже дороже, чем обращения к пустым _process GDScript.
Я не знаю, какой там шаблон скрипта на C#, но для GDScript Godot по умолчанию предлагает скрипт с объявленными _ready и _process, что, в большинстве случаев, вообще не нужны конкретному скрипту.
Итого, если тот движкосрачер взял "пустой" шаблон и размножил его много раз, а потом через профайлер замерял затраты на обращения - да, возможно, он в действительности наткнулся на этот "недостаток".
Но реальность такова, что тебе не нужно 300 _process, особенно на стороне C#. Обычно твой код реактивен - отвечает на события и бездействует между ответами, поэтому _process не нужен. А C# как числодробилка...
>>5483
Если скрипту не нужен process, зачем вообще такой ноде скрипт? Переменные хранить? Разве не логичнее тогда использовать ресурс? Или вообще завести в родительском скрипте массивчик под данные.
> большинстве случаев, вообще не нужны конкретному скрипту.
Если скрипту не нужен process, зачем вообще такой ноде скрипт? Переменные хранить? Разве не логичнее тогда использовать ресурс? Или вообще завести в родительском скрипте массивчик под данные.
>>5485
Ты совсем новичок что ли?
На вот, почитай про базовую архитектуру:
https://ru.wikipedia.org/wiki/Событийно-ориентированная_архитектура
Конкретно в Godot это делается сигналами:
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Большая часть реальной игровой логики - это что-то наподобие "нажали кнопку - загорелась лампочка". Лампочка должна отреагировать на нажатие кнопки единоразово, то есть у неё есть какой обработчик:
Всё, это весь скрипт лампочки. Ей не нужно ничего обрабатывать каждый кадр, и даже хранить ничего не нужно сверх того, что есть в классе SpotLight3D. Остальное настраивается через редактор движка.
Бывает код, который выполняется каждый кадр - это движение аватара игрока и NPC, пуль и т.п. Но таких объектов как правило мало (обычно меньше сотни), и если необходимо больше, то используются разные специальные оптимизации. Короче, это не то, о чём большинству придётся беспокоиться когда-либо.
И главное, что GDScript для такого кода более, чем достаточно, а C#/C++ используется там, где нужно перемолоть миллионы чисел в одном цикле, и потом вернуть результат вычислений в главный поток игры. Поэтому претензии к медленности API нерелеванты.
Ты совсем новичок что ли?
На вот, почитай про базовую архитектуру:
https://ru.wikipedia.org/wiki/Событийно-ориентированная_архитектура
Конкретно в Godot это делается сигналами:
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Большая часть реальной игровой логики - это что-то наподобие "нажали кнопку - загорелась лампочка". Лампочка должна отреагировать на нажатие кнопки единоразово, то есть у неё есть какой обработчик:
>extends SpotLight3D
>func _on_button_toggled(toggled_on: bool) -> void:
>_ visible = toggled_on
Всё, это весь скрипт лампочки. Ей не нужно ничего обрабатывать каждый кадр, и даже хранить ничего не нужно сверх того, что есть в классе SpotLight3D. Остальное настраивается через редактор движка.
Бывает код, который выполняется каждый кадр - это движение аватара игрока и NPC, пуль и т.п. Но таких объектов как правило мало (обычно меньше сотни), и если необходимо больше, то используются разные специальные оптимизации. Короче, это не то, о чём большинству придётся беспокоиться когда-либо.
И главное, что GDScript для такого кода более, чем достаточно, а C#/C++ используется там, где нужно перемолоть миллионы чисел в одном цикле, и потом вернуть результат вычислений в главный поток игры. Поэтому претензии к медленности API нерелеванты.
ребят, есть какой-то способ нормально заставить работать ии для врагов так чтобы это не было пиздецки гемморно?
у меня 2д игра, top-down вид, на процедурных уровнях должно бегать по 10-20 вражин. NavigationRegion2D запекается динамически вся хуйня это уже есть, и navigationagent2d у врагов уже настроен (и переёбан всячески как только я его не менял на результат не влияет).
Короче. Болванчики тупят у острых углов (игра построена на тайлах, соотв. стены и углы тоже квадратные), втыкаются в них, не могут нормально функционировать если входят в агро но им мешает к примеру стена - будут толпиться в стену не додумываясь её обойти. как эту хуйню вообще можно починить?
у меня 2д игра, top-down вид, на процедурных уровнях должно бегать по 10-20 вражин. NavigationRegion2D запекается динамически вся хуйня это уже есть, и navigationagent2d у врагов уже настроен (и переёбан всячески как только я его не менял на результат не влияет).
Короче. Болванчики тупят у острых углов (игра построена на тайлах, соотв. стены и углы тоже квадратные), втыкаются в них, не могут нормально функционировать если входят в агро но им мешает к примеру стена - будут толпиться в стену не додумываясь её обойти. как эту хуйню вообще можно починить?
>>5497
и ещё вопрос - есть ли смысл для пиксельного 2д рпж рогалика пересаживаться с 4.3 версии на актуальную? (4.7 или какая там), а то ваще не слежу че там и как
и ещё вопрос - есть ли смысл для пиксельного 2д рпж рогалика пересаживаться с 4.3 версии на актуальную? (4.7 или какая там), а то ваще не слежу че там и как
>>5494
Так и я о том же. Если в игре будет 100 лампочек, то не надо клонировать 100 нод с 100 скриптами с пустым process, а надо просто завести один менеджер лампочек, в нем, в единственном экземпляре, будет единственный скрипт обработчик событий, который будет последним аргументом получать, какая именно лампочка послала событие...
В 3-ке имя кнопки можно было передавать последним аргументом
connect("pressed", self, "_on_button_pressed", [node.name])
В 4-ке
connect("pressed", _on_button_pressed.bind(button.name)
Так и я о том же. Если в игре будет 100 лампочек, то не надо клонировать 100 нод с 100 скриптами с пустым process, а надо просто завести один менеджер лампочек, в нем, в единственном экземпляре, будет единственный скрипт обработчик событий, который будет последним аргументом получать, какая именно лампочка послала событие...
В 3-ке имя кнопки можно было передавать последним аргументом
connect("pressed", self, "_on_button_pressed", [node.name])
В 4-ке
connect("pressed", _on_button_pressed.bind(button.name)
20,7 Мб, mp4,1280x720, 4:47
Сделал динамическую смену времени суток. Еще есть несколько состояний погоды, изменение фаз луны и прочее. Мне кажется, получилось достаточно неплохо.
>>5545
Если планируются домики, советую потестить тени в плотной застройке. Давно делал такое в 3-ке, но там было неприятное дрожание теней, еще по разному выходили тени отброшенные на вертикальную и горизонтальную поверхность (например, стену и дорогу). Читал про продвинутые техники (интерполировать тени между двумя кадрами с разным углом солнца), но забил.
Если планируются домики, советую потестить тени в плотной застройке. Давно делал такое в 3-ке, но там было неприятное дрожание теней, еще по разному выходили тени отброшенные на вертикальную и горизонтальную поверхность (например, стену и дорогу). Читал про продвинутые техники (интерполировать тени между двумя кадрами с разным углом солнца), но забил.
131 Кб, 406x293>>5551 (Del)
блин, опередил
блин, опередил
>>5551 (Del)
Погодите, это реально?
Погодите, это реально?
55 Кб, 583x540>>5483
Просто выбираешь пустой шаблон при создании скрипта, готово
> для GDScript Godot по умолчанию предлагает скрипт с объявленными _ready и _process
Просто выбираешь пустой шаблон при создании скрипта, готово
>>5497
Как нуб могу посоветовать налепить на врагов RayCast2D и проверять коллизию в _process каждые кадров 5 (чтоб проц не взорвался) через is_colliding или is_on_wall, вот что-то из этого.
Как нуб могу посоветовать налепить на врагов RayCast2D и проверять коллизию в _process каждые кадров 5 (чтоб проц не взорвался) через is_colliding или is_on_wall, вот что-то из этого.
>>5497
Ты радиус агентам не забыл прописать?
Ты радиус агентам не забыл прописать?
>>5545
а разводы от дождя ты как сделал? Типа на определенной высоте спавнишь декали и удаляешь?
а разводы от дождя ты как сделал? Типа на определенной высоте спавнишь декали и удаляешь?
Если надо сохранить временный файл в рантайме, куда его писать? К темп-директориям годот же доступа не дает? И остается только user://, за которым потом следить и вилкой чистить.
23,3 Мб, mp4,1280x720, 3:47
>>5548
Да вроде бы норм работают тени из коробки.
>>5575
Дождь я делал по этому видосу:
https://www.youtube.com/watch?v=cZ5Ang_Ji8E
Если вкратце, то следы от дождя это отдельные партиклсы, которые настроены как сабэмиттер дождя и спавнятся, когда дождь коллизится с поверхностью.
Да вроде бы норм работают тени из коробки.
>>5575
Дождь я делал по этому видосу:
https://www.youtube.com/watch?v=cZ5Ang_Ji8E
Если вкратце, то следы от дождя это отдельные партиклсы, которые настроены как сабэмиттер дождя и спавнятся, когда дождь коллизится с поверхностью.
>>5571
Ну так реально нинужно, в юнити есть аналогичная проблема с количеством скриптов, просто апи лучше прописано и пропуки начинаются не на 300 нодах, а на 3000, сути проблемы это не меняет - вызов с# метода дорогой и с этим нихуя не сделать. Для большинства случаев это терпимо
>Так я и думал, что ответ будет - "нинужно"
Ну так реально нинужно, в юнити есть аналогичная проблема с количеством скриптов, просто апи лучше прописано и пропуки начинаются не на 300 нодах, а на 3000, сути проблемы это не меняет - вызов с# метода дорогой и с этим нихуя не сделать. Для большинства случаев это терпимо
>>5596
Во-первых, при каких таких обстоятельствах вообще может понадобиться сохранить не пользовательский файл в рантайме, неужели нельзя все те же данные положить просто в переменную?
Во-вторых, не забывай про многопользовательские системы. Если ребёнок играет у меня на компе, он это делает в своём профиле и не засирает мне стим своими фнафами. Софту не позволяется срать временными файлами, значимыми лишь для одного юзера, в общесистемные папки.
В-третьих, если сохраняешь временный файл, будь добр подчисть за собой в любом случае, не полагайся на системные механизмы.
Во-первых, при каких таких обстоятельствах вообще может понадобиться сохранить не пользовательский файл в рантайме, неужели нельзя все те же данные положить просто в переменную?
Во-вторых, не забывай про многопользовательские системы. Если ребёнок играет у меня на компе, он это делает в своём профиле и не засирает мне стим своими фнафами. Софту не позволяется срать временными файлами, значимыми лишь для одного юзера, в общесистемные папки.
В-третьих, если сохраняешь временный файл, будь добр подчисть за собой в любом случае, не полагайся на системные механизмы.
>>5375 (Del)
Какой-то финн делает игру с явно русским названием и каким-то постсоветским сеттингом. Приходят фанаты сталкера и таркова, начинают вонять. Я не утверждаю стопроцентно, что всё так, просто предполагаю.
>>5485
Вообще, есть много других встроенных коллбэков. Срабатывать кажды кадр нужно только всяким подвижным хуйням типа персонажей. Всем остальным надо в основном отзываться на сигналы: получать дамаг, откликаться на пересечение ареи - всякое такое.
>>5571
Ответ на что? Промотай ветку, там вопрос был вообще о другом.
Какой-то финн делает игру с явно русским названием и каким-то постсоветским сеттингом. Приходят фанаты сталкера и таркова, начинают вонять. Я не утверждаю стопроцентно, что всё так, просто предполагаю.
>>5485
>Если скрипту не нужен process, зачем вообще такой ноде скрипт?
Вообще, есть много других встроенных коллбэков. Срабатывать кажды кадр нужно только всяким подвижным хуйням типа персонажей. Всем остальным надо в основном отзываться на сигналы: получать дамаг, откликаться на пересечение ареи - всякое такое.
>>5571
>ответ будет - "нинужно"
Ответ на что? Промотай ветку, там вопрос был вообще о другом.
>>5600
Ты проверял бенчмарком что в годоте на 300 объектах будет какое то заметное замедление, или это просто вброс в движкосрач треде?
Ты проверял бенчмарком что в годоте на 300 объектах будет какое то заметное замедление, или это просто вброс в движкосрач треде?
>>5616
Окей, я уже уходил, но специально вернулся домой.
Первый пик - фепесы с работающим вхолостую process
Второй пик - фепесы с удаленным process
Разница около 5%
Такая же проверка с 3000 объектами
Разница около 20% (2200 фпс против 1800 фпс)
Итого, игры с 3000 объектами можно делать без какой то особой оптимизации, вообще не заметите проблем. Насмехайтесь над теми, кто пишет про 300 объектов.
30000, так и быть, уже начинайте оптимизировать. Там 300 фпс против 150 с наивным подходом, с логикой можно улететь, ужас, до 60 фпс.
Окей, я уже уходил, но специально вернулся домой.
Первый пик - фепесы с работающим вхолостую process
Второй пик - фепесы с удаленным process
Разница около 5%
Такая же проверка с 3000 объектами
Разница около 20% (2200 фпс против 1800 фпс)
Итого, игры с 3000 объектами можно делать без какой то особой оптимизации, вообще не заметите проблем. Насмехайтесь над теми, кто пишет про 300 объектов.
30000, так и быть, уже начинайте оптимизировать. Там 300 фпс против 150 с наивным подходом, с логикой можно улететь, ужас, до 60 фпс.
>>5632
Я не пользуюсь C# и другим не рекомендую. Если тебе надо проверять C# - проверяй сам.
Я не пользуюсь C# и другим не рекомендую. Если тебе надо проверять C# - проверяй сам.
>>5634
База
База
20 Кб, 608x211>>5637
Я проверил, что у годота нет проблем с 3000 объектов.
Собственно, по твоей ссылке у чувака 10000 объектов дает 200+ фпс, чего достаточно для игры.
Я проверил, что у годота нет проблем с 3000 объектов.
Собственно, по твоей ссылке у чувака 10000 объектов дает 200+ фпс, чего достаточно для игры.
Господа Годот'еры, кто знает как можно вытащить текст из игры для собственноручного перевода?
Раньше не имел опыта перевода игр на годоте.
Имеются вот такие файлы с пиков, так понимаю сам годот их пакует?
Раньше не имел опыта перевода игр на годоте.
Имеются вот такие файлы с пиков, так понимаю сам годот их пакует?
>>5642
Благодарю, потыкаю.
Обычная хентай игра, ничего такого. Можно в настройках выключить хентай элементы и играть как в обычный файтинг.
Благодарю, потыкаю.
Обычная хентай игра, ничего такого. Можно в настройках выключить хентай элементы и играть как в обычный файтинг.
19,4 Мб, webm,1920x1080, 0:40
Единственная проблема со светом и тенями пока, это пиздоблятские просветы по углам в помещениях. Как это фиксить я совершенно не понимаю. Видимо придется делать дома в виде отдельных локаций с подзагрузкой.
>>5494
Я вам даже больше скажу, такие штуки как visible вынесены сеттерами в АПИ ноды, и вышеописанный код можно вовсе не создавать, а настроить через инспектор коннекты к сигналам.
Но, разумеется, так можно настроить только очень примитивные штуки, типа переключения видимости.
> Лампочка должна отреагировать на нажатие кнопки единоразово, то есть у неё есть какой обработчик:
Я вам даже больше скажу, такие штуки как visible вынесены сеттерами в АПИ ноды, и вышеописанный код можно вовсе не создавать, а настроить через инспектор коннекты к сигналам.
Но, разумеется, так можно настроить только очень примитивные штуки, типа переключения видимости.
>>5663
Вот так этот коннект запишется в tscn файл:
Вот так этот коннект запишется в tscn файл:
> [connection signal="toggled" from="Button" to="Icon" method="set_visible"]
>>5648
Делай меши толще, с пересечениями между собой. Поправь shadow bias. Включи contact shadows
Делай меши толще, с пересечениями между собой. Поправь shadow bias. Включи contact shadows
>>5551 (Del)
Свиндот? Что за перфоманс.
Свиндот? Что за перфоманс.
>>5675
Ты поставил смысловую ловушку. Теперь, если я повторю, ты уличишь меня в том, что у меня обозначенная на пикче проблема. Правда, ты не учел, что одного признака недостаточно для постановки диагноза. А еще ты не специалист, чтобы делать такие выводы, они сложны. Можно легко запутаться, и ты уже запутался.
Так что сказать-то хотел? Чего триггеришься, столько наподчеркивал, старался, время тратил. Ты охотишься на шизов в этом треде, у тебя тут поляна?
Свиндот.
Ты поставил смысловую ловушку. Теперь, если я повторю, ты уличишь меня в том, что у меня обозначенная на пикче проблема. Правда, ты не учел, что одного признака недостаточно для постановки диагноза. А еще ты не специалист, чтобы делать такие выводы, они сложны. Можно легко запутаться, и ты уже запутался.
Так что сказать-то хотел? Чего триггеришься, столько наподчеркивал, старался, время тратил. Ты охотишься на шизов в этом треде, у тебя тут поляна?
Свиндот.
>>5686
Помню кто-то делал пару тысяч тредов назад
Помню кто-то делал пару тысяч тредов назад
>>5748
Верим.
Верим.
Тридешники в треде?
Кто-нибудь тут может объяснить, почему эта игра так... стрёмно выглядит? Не в обиду автору(ше), игра вроде хорошая, но визуально выбивается из современных в нехорошем смысле. Будто бы чего-то не хватает, но не понятно, чего. Это из-за чисто чёрных теней? Или там источники света какие-то не такие? Они вообще есть? Можете пощупать демку, но я чисто по скриншотам и трейлеру сужу... Видел на реддит несколько раз за последний год или два. Имхо, у этого разработчика проблема с цветовосприятием. Жалко его/её...
https://steamdb.info/app/3689220/screenshots/
Да, вроде в старых тредах обсуждали, не помню уже.
Кто-нибудь тут может объяснить, почему эта игра так... стрёмно выглядит? Не в обиду автору(ше), игра вроде хорошая, но визуально выбивается из современных в нехорошем смысле. Будто бы чего-то не хватает, но не понятно, чего. Это из-за чисто чёрных теней? Или там источники света какие-то не такие? Они вообще есть? Можете пощупать демку, но я чисто по скриншотам и трейлеру сужу... Видел на реддит несколько раз за последний год или два. Имхо, у этого разработчика проблема с цветовосприятием. Жалко его/её...
https://steamdb.info/app/3689220/screenshots/
Да, вроде в старых тредах обсуждали, не помню уже.
>>5754
Грязные цвета - основная причина, я считаю. Автор вообще не заморачивался. Если ты знаешь что ты не можешь в теорию цветов и в палитры, возьми готовые палитры и не заставляй людей страдать.
Ну и сверху можно было бы накинуть пару эффектов через World Env хотя бы.
Грязные цвета - основная причина, я считаю. Автор вообще не заморачивался. Если ты знаешь что ты не можешь в теорию цветов и в палитры, возьми готовые палитры и не заставляй людей страдать.
Ну и сверху можно было бы накинуть пару эффектов через World Env хотя бы.
>>5754
Норм цвета, стилизация под Симс 2.
Анимации правда слишком деревянные, и музыка тошнотная, но графоний в статике в целом норм.
inb4: "у тебя проблемы с цветовосприятием"
Хз, наоборот заебала эта пастельная хуетень как из хипстерских фильтров инстаграмма 2012. Прусь от стандартной ms-paint палитры с твёрдыми как мой кал цветами.
Норм цвета, стилизация под Симс 2.
Анимации правда слишком деревянные, и музыка тошнотная, но графоний в статике в целом норм.
inb4: "у тебя проблемы с цветовосприятием"
Хз, наоборот заебала эта пастельная хуетень как из хипстерских фильтров инстаграмма 2012. Прусь от стандартной ms-paint палитры с твёрдыми как мой кал цветами.
>>5756
Нет, в том-то и дело, что он заморочился:
https://reddit.com/r/godot/comments/1kuf8jj/
...стоп, может там Tonemap неправильный?.. Вот точно помню, что некоторые варианты делают всю картинку серовато-грязной на нормальном (SDR) мониторе. На продвинутом (HDR) мониторе, может, эффект другой, однако, таких мониторов вроде бы всё ещё мало.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#tonemap
>>5763 >>5765
Для широкой ЦА нужна более сочная графика, в особенности с учетом сеттинга "светлое будущее". Пастельность или нет - это тут не касается никак.
...Да даже, вон, в DRG - мрачные пещеры - всё ярко и насыщенно, хотя игроку нужно буквально рыться в инопланетной грязи и говне. Так что стилизация не соответствует ни широкой ЦА, ни сеттингу игры.
В общем, жаль автора. Даже хотелось ему помочь... Наверное, можно попробовать распаковать демку и поковыряться в настройках Environment? Если там стандартный проект на GDScript, должно собраться.
>Автор вообще не заморачивался.
Нет, в том-то и дело, что он заморочился:
https://reddit.com/r/godot/comments/1kuf8jj/
>Грязные цвета - основная причина
...стоп, может там Tonemap неправильный?.. Вот точно помню, что некоторые варианты делают всю картинку серовато-грязной на нормальном (SDR) мониторе. На продвинутом (HDR) мониторе, может, эффект другой, однако, таких мониторов вроде бы всё ещё мало.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#tonemap
>>5763 >>5765
>стилизация
Для широкой ЦА нужна более сочная графика, в особенности с учетом сеттинга "светлое будущее". Пастельность или нет - это тут не касается никак.
...Да даже, вон, в DRG - мрачные пещеры - всё ярко и насыщенно, хотя игроку нужно буквально рыться в инопланетной грязи и говне. Так что стилизация не соответствует ни широкой ЦА, ни сеттингу игры.
В общем, жаль автора. Даже хотелось ему помочь... Наверное, можно попробовать распаковать демку и поковыряться в настройках Environment? Если там стандартный проект на GDScript, должно собраться.
>>5754
ты не заметил что там текстур нет?
ты не заметил что там текстур нет?
>>5784
нет, это неправда
нет, это неправда
>>5545
Ты молодец, для прототипа замечательно, но у тебя основной-то геймплей игры есть? А то так можешь закопаться в тонкие настройки, добиваясь идеальной погоды, а к основной работе над игрой так и не дойти.
На будущее, во время дождливой погоды (особенно штормовой) рекомендую изменять дальность fog в настройках Environment, чтобы ландшафт и объекты вдалеке от камеры были более серыми. Тогда будет реалистичнее выглядеть без лишних частиц.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
>>5648
Документацию читал? Там всё с примерами:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#shadow-mapping
Но тебе пока рано фиксить такие косяки. Сначала разработай геймплей, потом определись со стилем графики, сделай несколько моделей в этом стиле. И только тогда будешь разбираться с тенями. Сделать нормально возможно, но всё зависит от моделей и расстановки, зависящих от желаемого геймплея.
>Сделал динамическую смену времени суток
Ты молодец, для прототипа замечательно, но у тебя основной-то геймплей игры есть? А то так можешь закопаться в тонкие настройки, добиваясь идеальной погоды, а к основной работе над игрой так и не дойти.
На будущее, во время дождливой погоды (особенно штормовой) рекомендую изменять дальность fog в настройках Environment, чтобы ландшафт и объекты вдалеке от камеры были более серыми. Тогда будет реалистичнее выглядеть без лишних частиц.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
>>5648
>Единственная проблема со светом и тенями
Документацию читал? Там всё с примерами:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#shadow-mapping
Но тебе пока рано фиксить такие косяки. Сначала разработай геймплей, потом определись со стилем графики, сделай несколько моделей в этом стиле. И только тогда будешь разбираться с тенями. Сделать нормально возможно, но всё зависит от моделей и расстановки, зависящих от желаемого геймплея.
>>5497
А ты уверен, что правильно настраиваешь его? В документации сказано, что недостаточно просто накладывать ноды для объединения в одну.
Если вся игра тайлах и имеет много узких ходов, я бы на твоём месте использовал простой AStar:
https://docs.godotengine.org/en/stable/classes/class_astargrid2d.html
Двигая врагов по клеточкам вручную (без физики).
Для больших пустых площадей и, в целом, очень больших карт желательны чанковые оптимизации.
Если игра - экшн-шутер, то можно использовать комбинированное решение AStar + raycast. Т.е. когда противник видит игрока, он просто идёт по прямой, в противном случае ищет путь через лабиринт.
>>5498
Имеет, там много разных фиксов и оптимизаций, касающихся любых игр. Версии 4.3 и 4.4 уже не поддерживаются, т.е. не получают багфиксов. По рекомендациям разрабов Godot, до выхода 5 всем желательно обновляться до актуальной версии. Копипастишь папку проекта, открываешь копию в следующей версии, и в 99% случаев проблем нет. Рекомендую удалить шейдеры из папки .godot, они зачастую заново компилируются новой версией.
>на процедурных уровнях
>NavigationRegion2D запекается динамически
А ты уверен, что правильно настраиваешь его? В документации сказано, что недостаточно просто накладывать ноды для объединения в одну.
>Болванчики тупят у острых углов (игра построена на тайлах, соотв. стены и углы тоже квадратные)
Если вся игра тайлах и имеет много узких ходов, я бы на твоём месте использовал простой AStar:
https://docs.godotengine.org/en/stable/classes/class_astargrid2d.html
Двигая врагов по клеточкам вручную (без физики).
Для больших пустых площадей и, в целом, очень больших карт желательны чанковые оптимизации.
Если игра - экшн-шутер, то можно использовать комбинированное решение AStar + raycast. Т.е. когда противник видит игрока, он просто идёт по прямой, в противном случае ищет путь через лабиринт.
>>5498
>есть ли смысл для пиксельного 2д рпж рогалика пересаживаться с 4.3 версии на актуальную?
Имеет, там много разных фиксов и оптимизаций, касающихся любых игр. Версии 4.3 и 4.4 уже не поддерживаются, т.е. не получают багфиксов. По рекомендациям разрабов Godot, до выхода 5 всем желательно обновляться до актуальной версии. Копипастишь папку проекта, открываешь копию в следующей версии, и в 99% случаев проблем нет. Рекомендую удалить шейдеры из папки .godot, они зачастую заново компилируются новой версией.
230 Кб, 1488x834>>5802
Нет, он делает правильно, что делает прототип - вертикальный срез и сразу увидит какие технические ограничения может упереться. Причем даже если он не будет делать эту игру, такие знания помогут для более мелких игр.
>>5648
Light leak / bleeding довольно распространенный вопрос про Godot, и четкого ответа с решением проблемы я никогда не видел. Некоторые советуют
-использовать системы SDFGI/VoxelGI/пробы, но мы знаем что они тяжелые по производительности;
-включать тени на источниках света, (у него уже включено на Directional; но надо помнить, что если будут дополнительные фонари, надо проверять, их range например);
-тюнить bias и прочие параметры. Ну тут надо просто перебрать много комбинаций. И может оказаться, что поправив в одной ситуации, портится в другой. Я даже думал понатыкать разных зон, по аналогии с гравитацией, которые будут переключать параметры теней при перемещении по открытому миру.
-отключать источник солнца внутри комнаты - плохой вариант, когда видишь через дверь/окно;
-запекать свет - вариант только для камерных игр, а не открытого мира; возможно с каким то сложным техническим решением, смешивать запеченный свет с динамическим... не видел готового аддона; тут не просто, если домик можно ставить под разными углами или есть упомянутая смена дня и ночи ну и в принципе запекание света меня никогда не устроило, хоть его и переписали три раза.
-Как уже упомянули в треде, делать стены толстыми, в метр толщиной, а не плоскостью из бумаги; тут есть понятная проблема, известная для опенворлда, что домик внутри должен быть такого же размера как и снаружи - в старых играх то просто подгружались огромные хоромы, которые больше чем занимаемое место на карте.
--один из приемов, который вспоминается - можно сделать объект БОЛЬШЕ, чем нужно, и сделать его невидимым, но shadow caster-ом.
-Может быть, можно придумать что-то с визуальными слоями. Я пока не придумал. У источника света есть Cull Mask, который указывает, на какой визуальный слой VisualInstance3D он светит, и соответственно бросает тень.
-Можно поиграться с размером алтасов тени. Но, конечно, большой атлас требует в разы больше памяти видяхи. Тут я так и не понял, как это проверить, является ли атлас screen space или нет, иными словами, важен ли размер 3д мира. Если важен, то может помочь чанкинг, ну то есть отключение дальних участков, которые не видны или тень на которых не имеет значения.
Нет, он делает правильно, что делает прототип - вертикальный срез и сразу увидит какие технические ограничения может упереться. Причем даже если он не будет делать эту игру, такие знания помогут для более мелких игр.
>>5648
Light leak / bleeding довольно распространенный вопрос про Godot, и четкого ответа с решением проблемы я никогда не видел. Некоторые советуют
-использовать системы SDFGI/VoxelGI/пробы, но мы знаем что они тяжелые по производительности;
-включать тени на источниках света, (у него уже включено на Directional; но надо помнить, что если будут дополнительные фонари, надо проверять, их range например);
-тюнить bias и прочие параметры. Ну тут надо просто перебрать много комбинаций. И может оказаться, что поправив в одной ситуации, портится в другой. Я даже думал понатыкать разных зон, по аналогии с гравитацией, которые будут переключать параметры теней при перемещении по открытому миру.
-отключать источник солнца внутри комнаты - плохой вариант, когда видишь через дверь/окно;
-запекать свет - вариант только для камерных игр, а не открытого мира; возможно с каким то сложным техническим решением, смешивать запеченный свет с динамическим... не видел готового аддона; тут не просто, если домик можно ставить под разными углами или есть упомянутая смена дня и ночи ну и в принципе запекание света меня никогда не устроило, хоть его и переписали три раза.
-Как уже упомянули в треде, делать стены толстыми, в метр толщиной, а не плоскостью из бумаги; тут есть понятная проблема, известная для опенворлда, что домик внутри должен быть такого же размера как и снаружи - в старых играх то просто подгружались огромные хоромы, которые больше чем занимаемое место на карте.
--один из приемов, который вспоминается - можно сделать объект БОЛЬШЕ, чем нужно, и сделать его невидимым, но shadow caster-ом.
-Может быть, можно придумать что-то с визуальными слоями. Я пока не придумал. У источника света есть Cull Mask, который указывает, на какой визуальный слой VisualInstance3D он светит, и соответственно бросает тень.
-Можно поиграться с размером алтасов тени. Но, конечно, большой атлас требует в разы больше памяти видяхи. Тут я так и не понял, как это проверить, является ли атлас screen space или нет, иными словами, важен ли размер 3д мира. Если важен, то может помочь чанкинг, ну то есть отключение дальних участков, которые не видны или тень на которых не имеет значения.
230 Кб, 1488x834>>5802
Нет, он делает правильно, что делает прототип - вертикальный срез и сразу увидит какие технические ограничения может упереться. Причем даже если он не будет делать эту игру, такие знания помогут для более мелких игр.
>>5648
Light leak / bleeding довольно распространенный вопрос про Godot, и четкого ответа с решением проблемы я никогда не видел. Некоторые советуют
-использовать системы SDFGI/VoxelGI/пробы, но мы знаем что они тяжелые по производительности;
-включать тени на источниках света, (у него уже включено на Directional; но надо помнить, что если будут дополнительные фонари, надо проверять, их range например);
-тюнить bias и прочие параметры. Ну тут надо просто перебрать много комбинаций. И может оказаться, что поправив в одной ситуации, портится в другой. Я даже думал понатыкать разных зон, по аналогии с гравитацией, которые будут переключать параметры теней при перемещении по открытому миру.
-отключать источник солнца внутри комнаты - плохой вариант, когда видишь через дверь/окно;
-запекать свет - вариант только для камерных игр, а не открытого мира; возможно с каким то сложным техническим решением, смешивать запеченный свет с динамическим... не видел готового аддона; тут не просто, если домик можно ставить под разными углами или есть упомянутая смена дня и ночи ну и в принципе запекание света меня никогда не устроило, хоть его и переписали три раза.
-Как уже упомянули в треде, делать стены толстыми, в метр толщиной, а не плоскостью из бумаги; тут есть понятная проблема, известная для опенворлда, что домик внутри должен быть такого же размера как и снаружи - в старых играх то просто подгружались огромные хоромы, которые больше чем занимаемое место на карте.
--один из приемов, который вспоминается - можно сделать объект БОЛЬШЕ, чем нужно, и сделать его невидимым, но shadow caster-ом.
-Может быть, можно придумать что-то с визуальными слоями. Я пока не придумал. У источника света есть Cull Mask, который указывает, на какой визуальный слой VisualInstance3D он светит, и соответственно бросает тень.
-Можно поиграться с размером алтасов тени. Но, конечно, большой атлас требует в разы больше памяти видяхи. Тут я так и не понял, как это проверить, является ли атлас screen space или нет, иными словами, важен ли размер 3д мира. Если важен, то может помочь чанкинг, ну то есть отключение дальних участков, которые не видны или тень на которых не имеет значения.
Нет, он делает правильно, что делает прототип - вертикальный срез и сразу увидит какие технические ограничения может упереться. Причем даже если он не будет делать эту игру, такие знания помогут для более мелких игр.
>>5648
Light leak / bleeding довольно распространенный вопрос про Godot, и четкого ответа с решением проблемы я никогда не видел. Некоторые советуют
-использовать системы SDFGI/VoxelGI/пробы, но мы знаем что они тяжелые по производительности;
-включать тени на источниках света, (у него уже включено на Directional; но надо помнить, что если будут дополнительные фонари, надо проверять, их range например);
-тюнить bias и прочие параметры. Ну тут надо просто перебрать много комбинаций. И может оказаться, что поправив в одной ситуации, портится в другой. Я даже думал понатыкать разных зон, по аналогии с гравитацией, которые будут переключать параметры теней при перемещении по открытому миру.
-отключать источник солнца внутри комнаты - плохой вариант, когда видишь через дверь/окно;
-запекать свет - вариант только для камерных игр, а не открытого мира; возможно с каким то сложным техническим решением, смешивать запеченный свет с динамическим... не видел готового аддона; тут не просто, если домик можно ставить под разными углами или есть упомянутая смена дня и ночи ну и в принципе запекание света меня никогда не устроило, хоть его и переписали три раза.
-Как уже упомянули в треде, делать стены толстыми, в метр толщиной, а не плоскостью из бумаги; тут есть понятная проблема, известная для опенворлда, что домик внутри должен быть такого же размера как и снаружи - в старых играх то просто подгружались огромные хоромы, которые больше чем занимаемое место на карте.
--один из приемов, который вспоминается - можно сделать объект БОЛЬШЕ, чем нужно, и сделать его невидимым, но shadow caster-ом.
-Может быть, можно придумать что-то с визуальными слоями. Я пока не придумал. У источника света есть Cull Mask, который указывает, на какой визуальный слой VisualInstance3D он светит, и соответственно бросает тень.
-Можно поиграться с размером алтасов тени. Но, конечно, большой атлас требует в разы больше памяти видяхи. Тут я так и не понял, как это проверить, является ли атлас screen space или нет, иными словами, важен ли размер 3д мира. Если важен, то может помочь чанкинг, ну то есть отключение дальних участков, которые не видны или тень на которых не имеет значения.
>>5648
Перечитывая форумы, я вспомнил еще про такой эффект как texture uv bleeding
На пальцах сложно объяснить, ну в общем видяха же окруляет там все, и может при рисовании залезть в соседние пиксели текстуры, то есть желательно растаскивать грани по "островкам" с пустотами для безопасности между ними.
Перечитывая форумы, я вспомнил еще про такой эффект как texture uv bleeding
На пальцах сложно объяснить, ну в общем видяха же окруляет там все, и может при рисовании залезть в соседние пиксели текстуры, то есть желательно растаскивать грани по "островкам" с пустотами для безопасности между ними.
>>5648
Еще один чел написал:
the thing I found that worked honestly was turning the world environment pure black and getting rid of the light from my skybox.
Еще один чел написал:
the thing I found that worked honestly was turning the world environment pure black and getting rid of the light from my skybox.
>>5839
А ещё можно разрезы развёртки уложить максимально в дальние углы модельки.
А ещё можно разрезы развёртки уложить максимально в дальние углы модельки.
>>5828
Это не то. "Vertical slice" - это когда ты делаешь часть игры на самом высшем качестве исполнения, но в небольшом количестве. Например: в твоей игре должно быть 100 видов противников? Сделай 2 в самом лучшем качестве, например, мечника и лучника, а остальных 98 отложи на потом. В игре должна быть карта размером 15x15 километров? Сделай участок 150x150 метров в лучшем качестве, а остальное отложи на потом. Планируется 20 видов погоды? Сделай 1 вид погоды в лучшем качестве, а остальные отложи на потом. Объедини всё это в играбельную демку, которую сможешь показать людям, чтобы они получили представление о том, какой будет игра в будущем (даже если пока что 99% контента игры не существует).
У него там буквально тоненькая коробка, совершенно пустая внутри, и он умудрился разглядеть тоненькую полоску света в абсолютной тьме. Если сделать нормальную модель дома, обставить предметами внутри, добавить источники света - эта мелкая полоска будет совсем незаметной, если не искать её специально. А вот ЕСЛИ она будет бросаться в глаза - тогда можно будет просто заделать щель, например, с помощью невидимого shadow mesh, который появляется снаружи дома, когда игрок заходит внутрь дома. Но это нужно делать с финальной графикой и в конкретных случаях индивидуально, а не когда у тебя только примитивный кубик с текстурой досок и кромешная тьма внутри.
>делает прототип - вертикальный срез
Это не то. "Vertical slice" - это когда ты делаешь часть игры на самом высшем качестве исполнения, но в небольшом количестве. Например: в твоей игре должно быть 100 видов противников? Сделай 2 в самом лучшем качестве, например, мечника и лучника, а остальных 98 отложи на потом. В игре должна быть карта размером 15x15 километров? Сделай участок 150x150 метров в лучшем качестве, а остальное отложи на потом. Планируется 20 видов погоды? Сделай 1 вид погоды в лучшем качестве, а остальные отложи на потом. Объедини всё это в играбельную демку, которую сможешь показать людям, чтобы они получили представление о том, какой будет игра в будущем (даже если пока что 99% контента игры не существует).
>четкого ответа с решением проблемы я никогда не видел
У него там буквально тоненькая коробка, совершенно пустая внутри, и он умудрился разглядеть тоненькую полоску света в абсолютной тьме. Если сделать нормальную модель дома, обставить предметами внутри, добавить источники света - эта мелкая полоска будет совсем незаметной, если не искать её специально. А вот ЕСЛИ она будет бросаться в глаза - тогда можно будет просто заделать щель, например, с помощью невидимого shadow mesh, который появляется снаружи дома, когда игрок заходит внутрь дома. Но это нужно делать с финальной графикой и в конкретных случаях индивидуально, а не когда у тебя только примитивный кубик с текстурой досок и кромешная тьма внутри.
>>5923
база
база
>>5923
Расскажи чем сейчас занимаешься. Есть проекты?
Расскажи чем сейчас занимаешься. Есть проекты?
>>5923
глаза протри, там очевидно бьет в глаза свет в щелях
глаза протри, там очевидно бьет в глаза свет в щелях
Падажжите, то есть запостить оригинальную картинку с официальной ирл годот конференции == бан за "движкосрач"?
https://www.reddit.com/r/godot/comments/1suniye/godotcon_out_of_context/
Там кстати первая бета 4.7 вышла. Подготовил вам пост с чейджлогом, а с компа его не запостить - бан, который мне лень вилкой вычищать. Сами квны включайте и смотрите. Вахтеры с айкью хлебушка.
https://www.reddit.com/r/godot/comments/1suniye/godotcon_out_of_context/
Там кстати первая бета 4.7 вышла. Подготовил вам пост с чейджлогом, а с компа его не запостить - бан, который мне лень вилкой вычищать. Сами квны включайте и смотрите. Вахтеры с айкью хлебушка.
24 Кб, 300x277>>5964
ОЧЕВИДНАЯ_ПРОВОКАЦИЯ.JPEG
@
ЗАКИНУЛ В ТРЕД БЕЗ КОММЕНТАРИЕВ
@
ХЕ-ХЕ-ХЕ, ИНТЕРЕСНО, КАК ОТРЕАГИРУЮТ?
@
@
@
ОООЙ, А З-ЗА ЧТО Б-БАН-ТО? НЕВИНОВАТАЯЯ!!!
Пальцы не устали нажимать Ctrl+C/Ctrl+V?
Ничего интересного, всё было в dev-сборках:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/
Сделали как и должно быть => breaking change.
- Tween может ожидать (await) сигналы:
- Можно скукожить группы в AnimationPlayer.
- Всякие оптимизации анимаций...
Улучшения-ускорения... Нас это не касается.
- Снаппинг Path3D и вершин, уже писали.
- Копипаст категорий данных в инспекторе.
- Всякие улучшения UI сами потом заметите.
- Можно качать export template по частям!!!
Нас здесь это точно не касается... Чёт улучшили.
Теперь enum в remote scene будут читабельными.
- Трансформы у Control независимы от контейнера.
- Строчка поиска в PopupMenu сверху (для всех).
- Улучшили интуитивность тяни-и-бросай в Tree.
- Картинки RichTextLabel масштабируются текстом.
Реализовали виртуальный (экранный) джойстик.
Починили однонаправленные коллизии в 2D.
- Поддержка picture-in-picture (полезно idle играм).
- Портретный режим в редакторе скриптов.
- Кастомный сплешскрин и всякое такое.
Чёто там нахимичили в C++, чтоб сделать HDR.
- Поддержка HDR дисплеев (это для богатых).
- Начали делать рейтрейсинг через Вулкан:
https://github.com/Fahien/godot-raytracing-gdscript-demo
- Более лёгкий способ рисовать на текстуре:
https://github.com/BastiaanOlij/drawable-textures-demo
- Олдскульное масштабирование для вьюпорта.
- Новые прямоугольные (Area) источники света.
- Превью в текстовом редакторе шейдеров.
Для местных может быть важно: Godot способен подвешивать весь ПК намертво на старых GPU с новейшими драйверами NVIDIA. У меня на старой версии драйвера всё норм => виновата NVIDIA. Но наблюдается этот глюк с какой-то dev-сборки 4.6. Рекомендую не обновлять драйверы без крайней необходимости, особенно те, что для GPU нужны. Большинство обновлений только что-то ломает.
У кого официальный сайт недоступен, сборки тут:
https://github.com/godotengine/godot-builds/releases
Пишите своему провайдеру, чтоб вайтлистнул:
https://godotengine.org/
https://docs.godotengine.org/
Они 100% могут это сделать, просто ленятся.
ОЧЕВИДНАЯ_ПРОВОКАЦИЯ.JPEG
@
ЗАКИНУЛ В ТРЕД БЕЗ КОММЕНТАРИЕВ
@
ХЕ-ХЕ-ХЕ, ИНТЕРЕСНО, КАК ОТРЕАГИРУЮТ?
@
@
@
ОООЙ, А З-ЗА ЧТО Б-БАН-ТО? НЕВИНОВАТАЯЯ!!!
>пост с чейджлогом
Пальцы не устали нажимать Ctrl+C/Ctrl+V?
Ничего интересного, всё было в dev-сборках:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/
>Breaking changes
Сделали как и должно быть => breaking change.
>Animation
- Tween может ожидать (await) сигналы:
>tween.tween_await($"../Area2D".body_entered)
- Можно скукожить группы в AnimationPlayer.
- Всякие оптимизации анимаций...
>Core and buildsystem
Улучшения-ускорения... Нас это не касается.
>Editor
- Снаппинг Path3D и вершин, уже писали.
- Копипаст категорий данных в инспекторе.
- Всякие улучшения UI сами потом заметите.
- Можно качать export template по частям!!!
>GDExtension
Нас здесь это точно не касается... Чёт улучшили.
>GDScript
Теперь enum в remote scene будут читабельными.
>GUI
- Трансформы у Control независимы от контейнера.
- Строчка поиска в PopupMenu сверху (для всех).
- Улучшили интуитивность тяни-и-бросай в Tree.
- Картинки RichTextLabel масштабируются текстом.
>Input
Реализовали виртуальный (экранный) джойстик.
>Physics
Починили однонаправленные коллизии в 2D.
>Platforms - Android
- Поддержка picture-in-picture (полезно idle играм).
- Портретный режим в редакторе скриптов.
- Кастомный сплешскрин и всякое такое.
>Platforms - Windows
Чёто там нахимичили в C++, чтоб сделать HDR.
>Rendering and shaders
- Поддержка HDR дисплеев (это для богатых).
- Начали делать рейтрейсинг через Вулкан:
https://github.com/Fahien/godot-raytracing-gdscript-demo
- Более лёгкий способ рисовать на текстуре:
https://github.com/BastiaanOlij/drawable-textures-demo
- Олдскульное масштабирование для вьюпорта.
- Новые прямоугольные (Area) источники света.
- Превью в текстовом редакторе шейдеров.
>Known issues
Для местных может быть важно: Godot способен подвешивать весь ПК намертво на старых GPU с новейшими драйверами NVIDIA. У меня на старой версии драйвера всё норм => виновата NVIDIA. Но наблюдается этот глюк с какой-то dev-сборки 4.6. Рекомендую не обновлять драйверы без крайней необходимости, особенно те, что для GPU нужны. Большинство обновлений только что-то ломает.
У кого официальный сайт недоступен, сборки тут:
https://github.com/godotengine/godot-builds/releases
Пишите своему провайдеру, чтоб вайтлистнул:
https://godotengine.org/
https://docs.godotengine.org/
Они 100% могут это сделать, просто ленятся.
24 Кб, 300x277>>5964
ОЧЕВИДНАЯ_ПРОВОКАЦИЯ.JPEG
@
ЗАКИНУЛ В ТРЕД БЕЗ КОММЕНТАРИЕВ
@
ХЕ-ХЕ-ХЕ, ИНТЕРЕСНО, КАК ОТРЕАГИРУЮТ?
@
@
@
ОООЙ, А З-ЗА ЧТО Б-БАН-ТО? НЕВИНОВАТАЯЯ!!!
Пальцы не устали нажимать Ctrl+C/Ctrl+V?
Ничего интересного, всё было в dev-сборках:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/
Сделали как и должно быть => breaking change.
- Tween может ожидать (await) сигналы:
- Можно скукожить группы в AnimationPlayer.
- Всякие оптимизации анимаций...
Улучшения-ускорения... Нас это не касается.
- Снаппинг Path3D и вершин, уже писали.
- Копипаст категорий данных в инспекторе.
- Всякие улучшения UI сами потом заметите.
- Можно качать export template по частям!!!
Нас здесь это точно не касается... Чёт улучшили.
Теперь enum в remote scene будут читабельными.
- Трансформы у Control независимы от контейнера.
- Строчка поиска в PopupMenu сверху (для всех).
- Улучшили интуитивность тяни-и-бросай в Tree.
- Картинки RichTextLabel масштабируются текстом.
Реализовали виртуальный (экранный) джойстик.
Починили однонаправленные коллизии в 2D.
- Поддержка picture-in-picture (полезно idle играм).
- Портретный режим в редакторе скриптов.
- Кастомный сплешскрин и всякое такое.
Чёто там нахимичили в C++, чтоб сделать HDR.
- Поддержка HDR дисплеев (это для богатых).
- Начали делать рейтрейсинг через Вулкан:
https://github.com/Fahien/godot-raytracing-gdscript-demo
- Более лёгкий способ рисовать на текстуре:
https://github.com/BastiaanOlij/drawable-textures-demo
- Олдскульное масштабирование для вьюпорта.
- Новые прямоугольные (Area) источники света.
- Превью в текстовом редакторе шейдеров.
Для местных может быть важно: Godot способен подвешивать весь ПК намертво на старых GPU с новейшими драйверами NVIDIA. У меня на старой версии драйвера всё норм => виновата NVIDIA. Но наблюдается этот глюк с какой-то dev-сборки 4.6. Рекомендую не обновлять драйверы без крайней необходимости, особенно те, что для GPU нужны. Большинство обновлений только что-то ломает.
У кого официальный сайт недоступен, сборки тут:
https://github.com/godotengine/godot-builds/releases
Пишите своему провайдеру, чтоб вайтлистнул:
https://godotengine.org/
https://docs.godotengine.org/
Они 100% могут это сделать, просто ленятся.
ОЧЕВИДНАЯ_ПРОВОКАЦИЯ.JPEG
@
ЗАКИНУЛ В ТРЕД БЕЗ КОММЕНТАРИЕВ
@
ХЕ-ХЕ-ХЕ, ИНТЕРЕСНО, КАК ОТРЕАГИРУЮТ?
@
@
@
ОООЙ, А З-ЗА ЧТО Б-БАН-ТО? НЕВИНОВАТАЯЯ!!!
>пост с чейджлогом
Пальцы не устали нажимать Ctrl+C/Ctrl+V?
Ничего интересного, всё было в dev-сборках:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/
>Breaking changes
Сделали как и должно быть => breaking change.
>Animation
- Tween может ожидать (await) сигналы:
>tween.tween_await($"../Area2D".body_entered)
- Можно скукожить группы в AnimationPlayer.
- Всякие оптимизации анимаций...
>Core and buildsystem
Улучшения-ускорения... Нас это не касается.
>Editor
- Снаппинг Path3D и вершин, уже писали.
- Копипаст категорий данных в инспекторе.
- Всякие улучшения UI сами потом заметите.
- Можно качать export template по частям!!!
>GDExtension
Нас здесь это точно не касается... Чёт улучшили.
>GDScript
Теперь enum в remote scene будут читабельными.
>GUI
- Трансформы у Control независимы от контейнера.
- Строчка поиска в PopupMenu сверху (для всех).
- Улучшили интуитивность тяни-и-бросай в Tree.
- Картинки RichTextLabel масштабируются текстом.
>Input
Реализовали виртуальный (экранный) джойстик.
>Physics
Починили однонаправленные коллизии в 2D.
>Platforms - Android
- Поддержка picture-in-picture (полезно idle играм).
- Портретный режим в редакторе скриптов.
- Кастомный сплешскрин и всякое такое.
>Platforms - Windows
Чёто там нахимичили в C++, чтоб сделать HDR.
>Rendering and shaders
- Поддержка HDR дисплеев (это для богатых).
- Начали делать рейтрейсинг через Вулкан:
https://github.com/Fahien/godot-raytracing-gdscript-demo
- Более лёгкий способ рисовать на текстуре:
https://github.com/BastiaanOlij/drawable-textures-demo
- Олдскульное масштабирование для вьюпорта.
- Новые прямоугольные (Area) источники света.
- Превью в текстовом редакторе шейдеров.
>Known issues
Для местных может быть важно: Godot способен подвешивать весь ПК намертво на старых GPU с новейшими драйверами NVIDIA. У меня на старой версии драйвера всё норм => виновата NVIDIA. Но наблюдается этот глюк с какой-то dev-сборки 4.6. Рекомендую не обновлять драйверы без крайней необходимости, особенно те, что для GPU нужны. Большинство обновлений только что-то ломает.
У кого официальный сайт недоступен, сборки тут:
https://github.com/godotengine/godot-builds/releases
Пишите своему провайдеру, чтоб вайтлистнул:
https://godotengine.org/
https://docs.godotengine.org/
Они 100% могут это сделать, просто ленятся.
39 Кб, 259x195>>5923
Ты буквально пишешь "все перечисленное в одну демку", то есть ты правильно понимаешь смысл вертикального среза, но при этом в упор не видишь, что он именно это и сделал - добавил один домик в открытый мир, и сразу сталкивается с проблемой, что или надо ее решать, или не добавлять домики/пещеры из-за того, что сложно настроить exterior/interior освещение. В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
Ты буквально пишешь "все перечисленное в одну демку", то есть ты правильно понимаешь смысл вертикального среза, но при этом в упор не видишь, что он именно это и сделал - добавил один домик в открытый мир, и сразу сталкивается с проблемой, что или надо ее решать, или не добавлять домики/пещеры из-за того, что сложно настроить exterior/interior освещение. В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
>>6012
А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п. Чтобы они посмотрели на твой домик и сказали:
Что можно сказать, посмотрев на его видео? Что он натянул текстуру досок на CSGBox3D и воткнул на случайный террейн из бесплатных плагинов (скорее всего). То, что систему погоды сделал - молодец, но в ней ничего сверхсложного нет, и на игру в конечном итоге она мало как повлияет. Так что это не вертикальный срез его игры, а сырой прототип на куче плейсхолдеров, слепленных на скорую руку. А ты раздуваешь из этого драму, будто теперь он не может сделать игру мечты, ведь у него в абсолютно тёмной коробке видно тонкую полоску света. С такими коробками вообще безразлично, что там где видно...
Не "домик" в "открытый мир", а пустую коробку на почти пустую сцену. И не с "проблемой", а с особенностью технологии shadow mapping, которую нужно будет держать в уме, но которой не нужно бояться. Эта особенность есть во всех играх с shadow mapping, то есть практически во всех 3D играх (единственная альтернатива умерла где-то в нулевых, ничего нового пока не придумали). С ней можно справиться, если это необходимо, но - опять же - а необходимо ли? Ни игры, ни ассетов нет, а "проблема" - есть?
Если он в соло решил сделать убийцу ААА-игры без покупки готовых ассетов высокого качества - тогда да, у него может уйти несколько месяцев на один качественный домик, который будет выглядеть достойно вертикального среза игры с открытым миром с реалистичной графикой (может пойти просить деньги у издателя с этим домиком). Но не обязательно выкидывать домик, можно выкинуть открытый мир и сделать игру про домик, если тебя НАСТОЛЬКО беспокоит протекающий между брёвнами/досками/плитами свет. Или перейти на другой движок, если тебя этот не устраивает - с готовыми ассетами это будет легко, ведь ассеты ты делал в другой программе. Пока нет ни ассетов, ни какой-либо игры, такие нюансы технологии не имеют никакого значения.
Я предполагаю, что свет протекает из-за того, что чем дальше объект от камеры, тем меньшее разрешение у карты теней (shadow map), поэтому "пиксели тени" становятся крупнее и происходит такое "протекание". Если необходимо - карту теней можно в настройках проекта увеличить и изменить пропорции так, чтобы вдалеке тень была более высокого качества. Но необходимо ли? Я даже в ААА играх видел очень кривые тени, которые приходилось отключать для экономии VRAM. Если условный Rockstar не смог в тени, то чего вы хотите от очередной инди-игры на бесплатном опенсурс движке... Адекватные игроки это понимают. Только чтобы игрок заметил твою игру, тебе нужен либо геймплей, либо ассеты, а не просто кубики с тенями на пустой сцене.
>то есть ты правильно понимаешь смысл вертикального среза
А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п. Чтобы они посмотрели на твой домик и сказали:
>вах какой разработчег, какой домек зделал, нужно дать ему миллион долларов, чтобы он нам запилил ещё несколько сотен таких же домеков, тогда мы с этой игры поимеем сотню миллионов долларов или больше
Что можно сказать, посмотрев на его видео? Что он натянул текстуру досок на CSGBox3D и воткнул на случайный террейн из бесплатных плагинов (скорее всего). То, что систему погоды сделал - молодец, но в ней ничего сверхсложного нет, и на игру в конечном итоге она мало как повлияет. Так что это не вертикальный срез его игры, а сырой прототип на куче плейсхолдеров, слепленных на скорую руку. А ты раздуваешь из этого драму, будто теперь он не может сделать игру мечты, ведь у него в абсолютно тёмной коробке видно тонкую полоску света. С такими коробками вообще безразлично, что там где видно...
>добавил один домик в открытый мир, и сразу сталкивается с проблемой
Не "домик" в "открытый мир", а пустую коробку на почти пустую сцену. И не с "проблемой", а с особенностью технологии shadow mapping, которую нужно будет держать в уме, но которой не нужно бояться. Эта особенность есть во всех играх с shadow mapping, то есть практически во всех 3D играх (единственная альтернатива умерла где-то в нулевых, ничего нового пока не придумали). С ней можно справиться, если это необходимо, но - опять же - а необходимо ли? Ни игры, ни ассетов нет, а "проблема" - есть?
>В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
Если он в соло решил сделать убийцу ААА-игры без покупки готовых ассетов высокого качества - тогда да, у него может уйти несколько месяцев на один качественный домик, который будет выглядеть достойно вертикального среза игры с открытым миром с реалистичной графикой (может пойти просить деньги у издателя с этим домиком). Но не обязательно выкидывать домик, можно выкинуть открытый мир и сделать игру про домик, если тебя НАСТОЛЬКО беспокоит протекающий между брёвнами/досками/плитами свет. Или перейти на другой движок, если тебя этот не устраивает - с готовыми ассетами это будет легко, ведь ассеты ты делал в другой программе. Пока нет ни ассетов, ни какой-либо игры, такие нюансы технологии не имеют никакого значения.
Я предполагаю, что свет протекает из-за того, что чем дальше объект от камеры, тем меньшее разрешение у карты теней (shadow map), поэтому "пиксели тени" становятся крупнее и происходит такое "протекание". Если необходимо - карту теней можно в настройках проекта увеличить и изменить пропорции так, чтобы вдалеке тень была более высокого качества. Но необходимо ли? Я даже в ААА играх видел очень кривые тени, которые приходилось отключать для экономии VRAM. Если условный Rockstar не смог в тени, то чего вы хотите от очередной инди-игры на бесплатном опенсурс движке... Адекватные игроки это понимают. Только чтобы игрок заметил твою игру, тебе нужен либо геймплей, либо ассеты, а не просто кубики с тенями на пустой сцене.
>>6012
А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п. Чтобы они посмотрели на твой домик и сказали:
Что можно сказать, посмотрев на его видео? Что он натянул текстуру досок на CSGBox3D и воткнул на случайный террейн из бесплатных плагинов (скорее всего). То, что систему погоды сделал - молодец, но в ней ничего сверхсложного нет, и на игру в конечном итоге она мало как повлияет. Так что это не вертикальный срез его игры, а сырой прототип на куче плейсхолдеров, слепленных на скорую руку. А ты раздуваешь из этого драму, будто теперь он не может сделать игру мечты, ведь у него в абсолютно тёмной коробке видно тонкую полоску света. С такими коробками вообще безразлично, что там где видно...
Не "домик" в "открытый мир", а пустую коробку на почти пустую сцену. И не с "проблемой", а с особенностью технологии shadow mapping, которую нужно будет держать в уме, но которой не нужно бояться. Эта особенность есть во всех играх с shadow mapping, то есть практически во всех 3D играх (единственная альтернатива умерла где-то в нулевых, ничего нового пока не придумали). С ней можно справиться, если это необходимо, но - опять же - а необходимо ли? Ни игры, ни ассетов нет, а "проблема" - есть?
Если он в соло решил сделать убийцу ААА-игры без покупки готовых ассетов высокого качества - тогда да, у него может уйти несколько месяцев на один качественный домик, который будет выглядеть достойно вертикального среза игры с открытым миром с реалистичной графикой (может пойти просить деньги у издателя с этим домиком). Но не обязательно выкидывать домик, можно выкинуть открытый мир и сделать игру про домик, если тебя НАСТОЛЬКО беспокоит протекающий между брёвнами/досками/плитами свет. Или перейти на другой движок, если тебя этот не устраивает - с готовыми ассетами это будет легко, ведь ассеты ты делал в другой программе. Пока нет ни ассетов, ни какой-либо игры, такие нюансы технологии не имеют никакого значения.
Я предполагаю, что свет протекает из-за того, что чем дальше объект от камеры, тем меньшее разрешение у карты теней (shadow map), поэтому "пиксели тени" становятся крупнее и происходит такое "протекание". Если необходимо - карту теней можно в настройках проекта увеличить и изменить пропорции так, чтобы вдалеке тень была более высокого качества. Но необходимо ли? Я даже в ААА играх видел очень кривые тени, которые приходилось отключать для экономии VRAM. Если условный Rockstar не смог в тени, то чего вы хотите от очередной инди-игры на бесплатном опенсурс движке... Адекватные игроки это понимают. Только чтобы игрок заметил твою игру, тебе нужен либо геймплей, либо ассеты, а не просто кубики с тенями на пустой сцене.
>то есть ты правильно понимаешь смысл вертикального среза
А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п. Чтобы они посмотрели на твой домик и сказали:
>вах какой разработчег, какой домек зделал, нужно дать ему миллион долларов, чтобы он нам запилил ещё несколько сотен таких же домеков, тогда мы с этой игры поимеем сотню миллионов долларов или больше
Что можно сказать, посмотрев на его видео? Что он натянул текстуру досок на CSGBox3D и воткнул на случайный террейн из бесплатных плагинов (скорее всего). То, что систему погоды сделал - молодец, но в ней ничего сверхсложного нет, и на игру в конечном итоге она мало как повлияет. Так что это не вертикальный срез его игры, а сырой прототип на куче плейсхолдеров, слепленных на скорую руку. А ты раздуваешь из этого драму, будто теперь он не может сделать игру мечты, ведь у него в абсолютно тёмной коробке видно тонкую полоску света. С такими коробками вообще безразлично, что там где видно...
>добавил один домик в открытый мир, и сразу сталкивается с проблемой
Не "домик" в "открытый мир", а пустую коробку на почти пустую сцену. И не с "проблемой", а с особенностью технологии shadow mapping, которую нужно будет держать в уме, но которой не нужно бояться. Эта особенность есть во всех играх с shadow mapping, то есть практически во всех 3D играх (единственная альтернатива умерла где-то в нулевых, ничего нового пока не придумали). С ней можно справиться, если это необходимо, но - опять же - а необходимо ли? Ни игры, ни ассетов нет, а "проблема" - есть?
>В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
Если он в соло решил сделать убийцу ААА-игры без покупки готовых ассетов высокого качества - тогда да, у него может уйти несколько месяцев на один качественный домик, который будет выглядеть достойно вертикального среза игры с открытым миром с реалистичной графикой (может пойти просить деньги у издателя с этим домиком). Но не обязательно выкидывать домик, можно выкинуть открытый мир и сделать игру про домик, если тебя НАСТОЛЬКО беспокоит протекающий между брёвнами/досками/плитами свет. Или перейти на другой движок, если тебя этот не устраивает - с готовыми ассетами это будет легко, ведь ассеты ты делал в другой программе. Пока нет ни ассетов, ни какой-либо игры, такие нюансы технологии не имеют никакого значения.
Я предполагаю, что свет протекает из-за того, что чем дальше объект от камеры, тем меньшее разрешение у карты теней (shadow map), поэтому "пиксели тени" становятся крупнее и происходит такое "протекание". Если необходимо - карту теней можно в настройках проекта увеличить и изменить пропорции так, чтобы вдалеке тень была более высокого качества. Но необходимо ли? Я даже в ААА играх видел очень кривые тени, которые приходилось отключать для экономии VRAM. Если условный Rockstar не смог в тени, то чего вы хотите от очередной инди-игры на бесплатном опенсурс движке... Адекватные игроки это понимают. Только чтобы игрок заметил твою игру, тебе нужен либо геймплей, либо ассеты, а не просто кубики с тенями на пустой сцене.
>>6031
Ну это твое мнение. Вертикальный срез делается для разработчика, чтобы узнать что все работает и реально доделать.
>А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п.
Ну это твое мнение. Вертикальный срез делается для разработчика, чтобы узнать что все работает и реально доделать.
>>6031
Даже так можно объяснить - на первом этапе то соло инди разработчик и является "потенциальным игроком", то есть ему должно самому нравится, так и "инвестором", поскольку ему надо решить, будет ли он дальше инвестировать свое время и ресурсы.
Я вообще не понимаю, с чем ты споришь, поскольку дальше ты буквально подтверждаешь мою точку зрения, что это и надо сделать, чтобы проверить что надо менять или переходить на другие технологии.
Даже так можно объяснить - на первом этапе то соло инди разработчик и является "потенциальным игроком", то есть ему должно самому нравится, так и "инвестором", поскольку ему надо решить, будет ли он дальше инвестировать свое время и ресурсы.
Я вообще не понимаю, с чем ты споришь, поскольку дальше ты буквально подтверждаешь мою точку зрения, что это и надо сделать, чтобы проверить что надо менять или переходить на другие технологии.
>>6035
Я, все же, делаю игру на Годоте, а не на Хуане.
Я, все же, делаю игру на Годоте, а не на Хуане.
>>6032 >>6033
Я тоже не понимаю, с чем ты споришь. У него пока не вертикальный срез (судя по видео), и кривое освещение на кубиках не имеет отношения к вертикальному срезу ни в плане геймплея, ни в плане визуального качества (может только немного). То, что свет может протекать, было давно известно и можно было найти много раз на форумах. Кому надо - находят способ замаскировать. Ему же пока явно не надо - поэтому я и предлагаю заниматься более актуальными вещами в его проекте, чем тени или даже погода. Пока он будет делать свою убийцу ААА игры в соло, уже выйдет Godot 5, а там, глядишь, и тени улучшатся (или у всех будет 8+ GB VRAM).
Кстати, говорят, что Godot в больших студиях используют для геймплейных прототипов, прежде чем делать игру на другом движке. Ну, а для соло индюка визуальное качество вообще мало значения имеет, если твою игру берут только из-за жалости к инди или по большой скидке за компанию с другими такими же...
Вообще, вы тут не о том беспокоитесь. Вот вам копипаста:
Может, кому-то запомнится твоя игра только потому, что свет в помещения протекает забавно...
Я тоже не понимаю, с чем ты споришь. У него пока не вертикальный срез (судя по видео), и кривое освещение на кубиках не имеет отношения к вертикальному срезу ни в плане геймплея, ни в плане визуального качества (может только немного). То, что свет может протекать, было давно известно и можно было найти много раз на форумах. Кому надо - находят способ замаскировать. Ему же пока явно не надо - поэтому я и предлагаю заниматься более актуальными вещами в его проекте, чем тени или даже погода. Пока он будет делать свою убийцу ААА игры в соло, уже выйдет Godot 5, а там, глядишь, и тени улучшатся (или у всех будет 8+ GB VRAM).
Кстати, говорят, что Godot в больших студиях используют для геймплейных прототипов, прежде чем делать игру на другом движке. Ну, а для соло индюка визуальное качество вообще мало значения имеет, если твою игру берут только из-за жалости к инди или по большой скидке за компанию с другими такими же...
Вообще, вы тут не о том беспокоитесь. Вот вам копипаста:
>The right amount of jank in indie games can enhance their charm and personality, making them more memorable and engaging for players. Embracing imperfections allows developers to focus on core gameplay and creativity, fostering a unique player connection.
Может, кому-то запомнится твоя игра только потому, что свет в помещения протекает забавно...
>>6040
Я спорю с тем, что ты начал писать автору, что он неправильно делает что проверяет настройки света, и ему надо бросать и бежать делать всю остальную игру, модельки, а потом уже настраивать свет (и видимо в этот момент узнать что свет протекает).
Я спорю с тем, что ты начал писать автору, что он неправильно делает что проверяет настройки света, и ему надо бросать и бежать делать всю остальную игру, модельки, а потом уже настраивать свет (и видимо в этот момент узнать что свет протекает).
На оценку, сделал в годоте перед уёбыванием в армейку, спустя год посмотрю на фидбэк
https://diskonavt.itch.io/deadwing-demo
https://diskonavt.itch.io/deadwing-demo
>>6085
Ну сделал и сделал
Ну сделал и сделал
>>6085
Залипательно. Сыграл аж три катки по 30 секунд, минуте, и полторы минуты, лол.
Ты случаем не тот оп-разраб Обсурити?
Залипательно. Сыграл аж три катки по 30 секунд, минуте, и полторы минуты, лол.
>перед уёбыванием в армейку
Ты случаем не тот оп-разраб Обсурити?
>>6102
нет, это вообще мой первый проект на годот, который зашёл дальше уровня "открыть движок и повтыкать в интерфейс"
нет, это вообще мой первый проект на годот, который зашёл дальше уровня "открыть движок и повтыкать в интерфейс"
>>6113
второе. береги себя и глупостей не делай, хотя лучше всего было не идти
второе. береги себя и глупостей не делай, хотя лучше всего было не идти
>>6042
Нет, он неправильно делает, что беспокоится об этой настройке на таком раннем этапе разработки игры. Проблема известная, но фиксится по ситуации.
Если беспокоиться о ней с самого начала:
1. Кинул куб CSGBox3D с текстурой досок на сцену - забеспокоился о протекающем свете - несколько дней крутил настройки, пока не добился идеально ровного освещения простого куба с текстурой досок.
2. Решил, что ему будет нужен "перекошенный дом" и повернул свой куб с текстурой досок - свет начинает протекать снова - опять несколько дней крутил его настройски, пока не добился идального света в перекошенном кубе, но сломал в нормальном...
3. Спустя недели добился идеального света на своих кубиках, и пришла пора делать нормальные модели - внезапно у нормальных моделей другая геометрия и взаимодействие с системой светотени отличается - необходимы другие настройки - придётся минимум несколько дней перенастраивать на новые модели.
4. Через полгода его скилл в 3D поднялся и пора бы обновить самые первые модели - снова геометрия отличается - снова менять настройки светотени...
Это очень сильно демотивирует - когда ты потратил огромную кучу времени на то, что оказалось совсем ненужным в будущем. Проще с самого начала эту "проблему" игнорировать, а потом заделать дырки в финальной графике, которая уже не из кубиков...
>неправильно делает что проверяет настройки света
Нет, он неправильно делает, что беспокоится об этой настройке на таком раннем этапе разработки игры. Проблема известная, но фиксится по ситуации.
Если беспокоиться о ней с самого начала:
1. Кинул куб CSGBox3D с текстурой досок на сцену - забеспокоился о протекающем свете - несколько дней крутил настройки, пока не добился идеально ровного освещения простого куба с текстурой досок.
2. Решил, что ему будет нужен "перекошенный дом" и повернул свой куб с текстурой досок - свет начинает протекать снова - опять несколько дней крутил его настройски, пока не добился идального света в перекошенном кубе, но сломал в нормальном...
3. Спустя недели добился идеального света на своих кубиках, и пришла пора делать нормальные модели - внезапно у нормальных моделей другая геометрия и взаимодействие с системой светотени отличается - необходимы другие настройки - придётся минимум несколько дней перенастраивать на новые модели.
4. Через полгода его скилл в 3D поднялся и пора бы обновить самые первые модели - снова геометрия отличается - снова менять настройки светотени...
Это очень сильно демотивирует - когда ты потратил огромную кучу времени на то, что оказалось совсем ненужным в будущем. Проще с самого начала эту "проблему" игнорировать, а потом заделать дырки в финальной графике, которая уже не из кубиков...
>>6152
Так вот именно так делать и надо - поставить домик, покрутить настройки, добавить другой домик под другим углом, покрутить настройки, и примерно тут и станет заметно, что есть проблема, что так не получится просто накидывать домики. Тут нужно общее, системное решение, для всей игры, а не какие то ручные "фиксы по ситуации". Поэтому такие исследования и надо делать в самый ранний момент, и например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи, или пилить таки универсальную систему, а в твоем варианте будет потрачено несколько месяцев на игру, а потом выяснится, что настроить свет по ситуации станет невозможно.
Так вот именно так делать и надо - поставить домик, покрутить настройки, добавить другой домик под другим углом, покрутить настройки, и примерно тут и станет заметно, что есть проблема, что так не получится просто накидывать домики. Тут нужно общее, системное решение, для всей игры, а не какие то ручные "фиксы по ситуации". Поэтому такие исследования и надо делать в самый ранний момент, и например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи, или пилить таки универсальную систему, а в твоем варианте будет потрачено несколько месяцев на игру, а потом выяснится, что настроить свет по ситуации станет невозможно.
>>6155
Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной? Они ясно говорят в документации: если какое-то решение будет полезно 99% пользователям движка (в данном случае имеем в виду 99% 3D игр), то оно должно быть в официальных сборках; если что-то полезно только 1% пользователей, оно отлетает в аддоны/модули. Если решения не существует, то его нигде не будет - или ты думаешь, за 10+ лет существования движка не нашли способа портировать решение с движков 30+ летней давности? Сам принцип освещения придуман в 1978.
Хватит троллить. С этим настроем можно целиком от разработки игр отказаться, оптимизировав затраты - "разрабатывать игры сложно, поэтому не буду их разрабатывать - буду просто играть в готовое". Если человеку захотелось свою игру, он, очевидно, хочет разработать её любым способом, а не выкинуть из задуманного 99% из-за того, что "свет протекает" (совершенная мелочь, которую поди заметь ещё).
Всё возможно, просто нужны костыли в отдельных ситуациях. Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо. Заделывать заплатками тестовый кубик НЕ НУЖНО.
Игровой движок - это инструмент для работы, а игра формируется определённым видением автора, и от инструментов требуется реализовать это видение, не прируждая менять видение под нюансы инструмента. Костылями или универсально - не важно, важно лишь соответствовать задуманному. Если он задумал себе опенворлд с системой дня и ночи с домиками - окей, задуманное вполне реализуемо, хоть и с костылями, которые даже в ААА вынуждены применять. Главное следовать собственной задумке и не отвлекаться на пустяковые мелочи вроде "протекающего света" (на минимальных настройках графики он и в ААА течёт).
>Тут нужно общее, системное решение
Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной? Они ясно говорят в документации: если какое-то решение будет полезно 99% пользователям движка (в данном случае имеем в виду 99% 3D игр), то оно должно быть в официальных сборках; если что-то полезно только 1% пользователей, оно отлетает в аддоны/модули. Если решения не существует, то его нигде не будет - или ты думаешь, за 10+ лет существования движка не нашли способа портировать решение с движков 30+ летней давности? Сам принцип освещения придуман в 1978.
>например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи
Хватит троллить. С этим настроем можно целиком от разработки игр отказаться, оптимизировав затраты - "разрабатывать игры сложно, поэтому не буду их разрабатывать - буду просто играть в готовое". Если человеку захотелось свою игру, он, очевидно, хочет разработать её любым способом, а не выкинуть из задуманного 99% из-за того, что "свет протекает" (совершенная мелочь, которую поди заметь ещё).
>настроить свет по ситуации станет невозможно
Всё возможно, просто нужны костыли в отдельных ситуациях. Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо. Заделывать заплатками тестовый кубик НЕ НУЖНО.
Игровой движок - это инструмент для работы, а игра формируется определённым видением автора, и от инструментов требуется реализовать это видение, не прируждая менять видение под нюансы инструмента. Костылями или универсально - не важно, важно лишь соответствовать задуманному. Если он задумал себе опенворлд с системой дня и ночи с домиками - окей, задуманное вполне реализуемо, хоть и с костылями, которые даже в ААА вынуждены применять. Главное следовать собственной задумке и не отвлекаться на пустяковые мелочи вроде "протекающего света" (на минимальных настройках графики он и в ААА течёт).
>>6155
Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной? Они ясно говорят в документации: если какое-то решение будет полезно 99% пользователям движка (в данном случае имеем в виду 99% 3D игр), то оно должно быть в официальных сборках; если что-то полезно только 1% пользователей, оно отлетает в аддоны/модули. Если решения не существует, то его нигде не будет - или ты думаешь, за 10+ лет существования движка не нашли способа портировать решение с движков 30+ летней давности? Сам принцип освещения придуман в 1978.
Хватит троллить. С этим настроем можно целиком от разработки игр отказаться, оптимизировав затраты - "разрабатывать игры сложно, поэтому не буду их разрабатывать - буду просто играть в готовое". Если человеку захотелось свою игру, он, очевидно, хочет разработать её любым способом, а не выкинуть из задуманного 99% из-за того, что "свет протекает" (совершенная мелочь, которую поди заметь ещё).
Всё возможно, просто нужны костыли в отдельных ситуациях. Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо. Заделывать заплатками тестовый кубик НЕ НУЖНО.
Игровой движок - это инструмент для работы, а игра формируется определённым видением автора, и от инструментов требуется реализовать это видение, не прируждая менять видение под нюансы инструмента. Костылями или универсально - не важно, важно лишь соответствовать задуманному. Если он задумал себе опенворлд с системой дня и ночи с домиками - окей, задуманное вполне реализуемо, хоть и с костылями, которые даже в ААА вынуждены применять. Главное следовать собственной задумке и не отвлекаться на пустяковые мелочи вроде "протекающего света" (на минимальных настройках графики он и в ААА течёт).
>Тут нужно общее, системное решение
Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной? Они ясно говорят в документации: если какое-то решение будет полезно 99% пользователям движка (в данном случае имеем в виду 99% 3D игр), то оно должно быть в официальных сборках; если что-то полезно только 1% пользователей, оно отлетает в аддоны/модули. Если решения не существует, то его нигде не будет - или ты думаешь, за 10+ лет существования движка не нашли способа портировать решение с движков 30+ летней давности? Сам принцип освещения придуман в 1978.
>например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи
Хватит троллить. С этим настроем можно целиком от разработки игр отказаться, оптимизировав затраты - "разрабатывать игры сложно, поэтому не буду их разрабатывать - буду просто играть в готовое". Если человеку захотелось свою игру, он, очевидно, хочет разработать её любым способом, а не выкинуть из задуманного 99% из-за того, что "свет протекает" (совершенная мелочь, которую поди заметь ещё).
>настроить свет по ситуации станет невозможно
Всё возможно, просто нужны костыли в отдельных ситуациях. Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо. Заделывать заплатками тестовый кубик НЕ НУЖНО.
Игровой движок - это инструмент для работы, а игра формируется определённым видением автора, и от инструментов требуется реализовать это видение, не прируждая менять видение под нюансы инструмента. Костылями или универсально - не важно, важно лишь соответствовать задуманному. Если он задумал себе опенворлд с системой дня и ночи с домиками - окей, задуманное вполне реализуемо, хоть и с костылями, которые даже в ААА вынуждены применять. Главное следовать собственной задумке и не отвлекаться на пустяковые мелочи вроде "протекающего света" (на минимальных настройках графики он и в ААА течёт).
>>6170
Это не вариант во многих случаях - создающиеся генерацией миры, опенворлд в городе где дома могут стоять под любыми углами, смена дня и ночи, где направленный свет проходит плавно 360 градусов.
Она и так всегда недоделанная, а если говорить корректнее, то есть разные вводные условия, в которых она может работать, а в других не работать.
Когда я говорю про решения, то это не обязательно ядро движка. Многие вещи решены разрабами игр в виде простых правил (например, как какой то список настроек), какие-то - аддонами, как в случае террейна.
>Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо.
Это не вариант во многих случаях - создающиеся генерацией миры, опенворлд в городе где дома могут стоять под любыми углами, смена дня и ночи, где направленный свет проходит плавно 360 градусов.
>Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной?
Она и так всегда недоделанная, а если говорить корректнее, то есть разные вводные условия, в которых она может работать, а в других не работать.
Когда я говорю про решения, то это не обязательно ядро движка. Многие вещи решены разрабами игр в виде простых правил (например, как какой то список настроек), какие-то - аддонами, как в случае террейна.
64 Кб, 321x112Наглядный пример, почему у местных портянкописателей игор нет. Надо бы целую конференцию собрать на недельку чтобы разобраться когда и как правильно (и без синглтонов) решать проблему просветов.
>>6177
Невероятно! Оказывается, что если ты строишь не шалаш из веток на одну ночь, а небоскреб на сотню лет, то надо немного подумать и посчитать заранее!
Невероятно! Оказывается, что если ты строишь не шалаш из веток на одну ночь, а небоскреб на сотню лет, то надо немного подумать и посчитать заранее!
39,4 Мб, mp4,946x480, 1:42
Седня допилил для джема простенький сурвайвал хоррор. Думаю наверн как нибудь в будущем продолжу эту идею развивать добавляя других сущностей
Я осознал, что вообще не понимаю, как правильно делать файлы материалов. Вроде простая тема, но чет перебираю варианты в голове и нихуя не понимаю.
Вот у меня есть, например, один настроенный StandardMaterial3D или шейдер для деревьев. И штук 10 текстур деревьев, и, может, еще 1-2 параметра материала, которые будут меняться от дерева к дереву. Мне что, делать 10 уникальных материалов ради изменения 1-3 параметров? Хранить их прямо в сцене, или вообще сохранять все 10 материалов в папку с деревьями?..
А если надо будет изменить, не знаю, Diffuse Mode какой-нибудь - мне что, все 10 материалов прокликивать по очереди?
Ну или что, делать код, который будет подгружать один сохраненный материал и передавать в него эти самые 1-3 параметра, которые будут меняться от меша к мешу? Делать код через @tool, который реагирует только на изменения параметров? А так разве не выйдет по одному материалу на одно дерево, или я и тут тоже туплю? Если не выйдет - вроде неплохой вариант, но это разве не костыль? Может, я какой-то очевидный базовый функционал проебал, вот и задаю тупые вопросы?
Вот у меня есть, например, один настроенный StandardMaterial3D или шейдер для деревьев. И штук 10 текстур деревьев, и, может, еще 1-2 параметра материала, которые будут меняться от дерева к дереву. Мне что, делать 10 уникальных материалов ради изменения 1-3 параметров? Хранить их прямо в сцене, или вообще сохранять все 10 материалов в папку с деревьями?..
А если надо будет изменить, не знаю, Diffuse Mode какой-нибудь - мне что, все 10 материалов прокликивать по очереди?
Ну или что, делать код, который будет подгружать один сохраненный материал и передавать в него эти самые 1-3 параметра, которые будут меняться от меша к мешу? Делать код через @tool, который реагирует только на изменения параметров? А так разве не выйдет по одному материалу на одно дерево, или я и тут тоже туплю? Если не выйдет - вроде неплохой вариант, но это разве не костыль? Может, я какой-то очевидный базовый функционал проебал, вот и задаю тупые вопросы?
>>6245
Все верно, если у тебя разные текстуры, то и материалы будут разные. Так работает оптимизация, движок при рендере отсортировывает объекты по материалам, чтобы при отрисовке меньше между ними переключаться, чтобы рисовать сначала объект с одной текстурой, потом со следующей и тд (Само 3д разруливает буфер глубины).
Можно попробовать сделать один шейдер, и передавать в него разные текстуры. В 4-ке для этого приспособить instance shader uniforms.
Все верно, если у тебя разные текстуры, то и материалы будут разные. Так работает оптимизация, движок при рендере отсортировывает объекты по материалам, чтобы при отрисовке меньше между ними переключаться, чтобы рисовать сначала объект с одной текстурой, потом со следующей и тд (Само 3д разруливает буфер глубины).
Можно попробовать сделать один шейдер, и передавать в него разные текстуры. В 4-ке для этого приспособить instance shader uniforms.
>>6273
Во всех.
Во всех.
2,6 Мб, 1535x1022>>6273
Маджонг клонируем.
Маджонг клонируем.
Ничего себе, аноны уже несколько дней мои протекающие кубы обсуждают, а я про это и думать забыл.
>>6152
Да я и не беспокоюсь, братан. Я просто обозначил наличие проблемы. Но это не значит, что я буду вот прям щас усираться, чтобы ее решить.
А про геймплей ты прав совершенно. Я его делаю, но он пока достаточно сыроват. Вот как доведу до какого-нибудь удобоваримого состояния, так сразу в тред запощу.
Систему динамической смены суток и погоды я вообще делать начал, чтобы отвлечься и что-нибудь новенькое попробовать. Изначально думал, что просто текстуры для скайбоксов попробую сделать, буду их как-то постепенно переключать между собой. Но в итоге эта тема меня затянула, прототип разросся и получилось (для меня по крайней мере) весьма годно.
А по теме протечек аноны выше писали использовать SDFGI, VoxelGI, дать стены толщиной в метр и т.д.
Оказалось, что у меня уже был включен SDFGI, про что я совершенно забыл, и эти утечки сильнее всего происходят именно с ним.
Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Самый лучший вариант из трех оказался VoxelGI. Подрочив настройки bias можно добиться более выраженных теней, хотя достигнуть уровня темноты SDFGI все равно не получилось. Зато почти не заметно просветов.
Делать стены толщиной в метр действительно минимизирует проблемы (но не избавляет от них полностью), но стены в метр толщиной выглядят нелепо и несуразно. Это не варик.
Другие варианты по типу отключения энвайронмента, источников солнца, запекание света и прочее не подходит по уже указанным причинам.
>>6152
Да я и не беспокоюсь, братан. Я просто обозначил наличие проблемы. Но это не значит, что я буду вот прям щас усираться, чтобы ее решить.
А про геймплей ты прав совершенно. Я его делаю, но он пока достаточно сыроват. Вот как доведу до какого-нибудь удобоваримого состояния, так сразу в тред запощу.
Систему динамической смены суток и погоды я вообще делать начал, чтобы отвлечься и что-нибудь новенькое попробовать. Изначально думал, что просто текстуры для скайбоксов попробую сделать, буду их как-то постепенно переключать между собой. Но в итоге эта тема меня затянула, прототип разросся и получилось (для меня по крайней мере) весьма годно.
А по теме протечек аноны выше писали использовать SDFGI, VoxelGI, дать стены толщиной в метр и т.д.
Оказалось, что у меня уже был включен SDFGI, про что я совершенно забыл, и эти утечки сильнее всего происходят именно с ним.
Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Самый лучший вариант из трех оказался VoxelGI. Подрочив настройки bias можно добиться более выраженных теней, хотя достигнуть уровня темноты SDFGI все равно не получилось. Зато почти не заметно просветов.
Делать стены толщиной в метр действительно минимизирует проблемы (но не избавляет от них полностью), но стены в метр толщиной выглядят нелепо и несуразно. Это не варик.
Другие варианты по типу отключения энвайронмента, источников солнца, запекание света и прочее не подходит по уже указанным причинам.
>>6273
рпж рогалик блят. полгода уже сука а конца и края так и не видно
рпж рогалик блят. полгода уже сука а конца и края так и не видно
>>6273
Жанр писать не буду, а так делаю игру, которая покорит весь ру игромир.
Жанр писать не буду, а так делаю игру, которая покорит весь ру игромир.
87 Кб, 700x945Sup! Хочу вкктиться в индюшатину. Выбрал Godot. Кроме него, что ещё надо будет изучить? Blender? Если что, мне для Linux.
>>6318
Вначале что-то 2D простенькое. Потом может RPG какую. А вообще, когда набью опыта, хочу 3D бродилки делать, может хорроры.
Вначале что-то 2D простенькое. Потом может RPG какую. А вообще, когда набью опыта, хочу 3D бродилки делать, может хорроры.
>>6319
Крита/Гимп если растром рисуешь. Аспрайт если пикселями. Блендер для 3д, блокбенч для лоуполи 3д попроще.
Крита/Гимп если растром рисуешь. Аспрайт если пикселями. Блендер для 3д, блокбенч для лоуполи 3д попроще.
Посоветуйте видео уроки по Godot. Или что почитать. На русском. Спс!
>>6320
Gimp больше для редактирования изображению юзаю. Вообще, тогда Блендера может хватить. Даже для 2D.
Gimp больше для редактирования изображению юзаю. Вообще, тогда Блендера может хватить. Даже для 2D.
11 Кб, 255x194>>6321
https://docs.godotengine.org/ru/4.x/getting_started/introduction/index.html
Начни с официальных туториалов, они хороши и по делу. Есть и 3д и 2д - выполни оба.
https://docs.godotengine.org/ru/4.x/getting_started/introduction/index.html
Начни с официальных туториалов, они хороши и по делу. Есть и 3д и 2д - выполни оба.
>>6344
Не шарю за местные преколы. Я кроме шуток хочу раннер запилить
Не шарю за местные преколы. Я кроме шуток хочу раннер запилить
>>3432
если акк у тебя новый и игра не получает просмотры в первую неделю, то тебе надо написать в поддержку и они ручками твой новорег добавят в индексацию. Ещё очень сильно запарься с тегами и превьюшкой для игры - очень сильно решает
если акк у тебя новый и игра не получает просмотры в первую неделю, то тебе надо написать в поддержку и они ручками твой новорег добавят в индексацию. Ещё очень сильно запарься с тегами и превьюшкой для игры - очень сильно решает
>>6370
Да. По сюжету мы в роли горца ищем аппетитного барашка для Сабантуя. Но шайтаны балять мамю их ебаль падери не дают простым гордым народам жить
Да. По сюжету мы в роли горца ищем аппетитного барашка для Сабантуя. Но шайтаны балять мамю их ебаль падери не дают простым гордым народам жить
>>6393 (Del)
Не ну погоди а проблема то у него в чем? Вроде и путь правильный и автодополнение сработало.
Не ну погоди а проблема то у него в чем? Вроде и путь правильный и автодополнение сработало.
>>6405
Сквозь куб проходят, туда тоже можно отталкиватель воткнуть
Сквозь куб проходят, туда тоже можно отталкиватель воткнуть
>>6245
Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять? В любом случае, твоей целью должна быть минимизация количества отдельных материалов любой ценой. В идеале все твои деревья должны иметь один общий материал с одним текстурным атласом. Особенно это касается OpenGL/Compatibility рендерера, но и на Vulkan можно заметить тормоза, если постараться (я тестировал это во времена Godot 4.0 или около того). А вдалеке от камеры деревья в играх часто "слипаются" в один лоуполи меш для ещё большей оптимизации, и, наконец, в плоские картинки-спрайты. Встроенный механизм в Godot позволяет только упростить геометрию объекта, всё остальное зависит от тебя. Но помни, что преждевременная оптимизация вредна, и поэтому сначала слепи из того, что есть, проведи замеры, найди самые тяжёлые места и только потом оптимизируй их.
>>6297
Нет, на самом деле, на твоём скриншоте одна большая тень, просто светлая - цвета ambient lighting. Но если ты уменьшишь ambient lighting в настройках environment, тогда у тебя и снаружи дома тени будут 100% чёрными. Технически возможно менять этот параметр динамически: когда игрок заходит в тёмное помещение, ambient уменьшается до чёрного, а когда выходит на яркую улицу - поднимается обратно до серого (синеватого/зеленоватого/желтоватого). Кажется, так делали в старых играх, и это можно сделать намного эффективнее, чем любые техники GI. Если хочешь ещё больше реализма, тогда нужно ещё и bloom править относительно того, входит игрок в тёмное помещение или выходит на яркую улицу: когда только выходишь, свет бьёт в глаза и ослепляет, что можно реализовать, сильно увеличив bloom. В любом случае тебе потребуется способ определить, находится ли игрок в помещении... Что, наверное, и для геймплея пригодится (реакция NPC, стелс и т.п.), так что фича может быть намного важнее, чем может показаться на первый взгляд.
>>6343
Рекомендую разобраться с этой нодой, поможет для такого раннера:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
В классическом раннере у тебя 3 таких дорожки должно быть.
>>6393 (Del)
Не, он правильно делает, это стандартный способ связки нод.
Это совет для Godot 3.x? Сейчас можно проще: @export label: Label... только ему это не нужно делать. У него там, похоже, самостоятельная сцена, которую он хочет куда-то цеплять для какой-то отладки. Ей будет достаточно и стандартного "хардкода". Вариант с экспортом полезен в тех случаях, когда необходима универсальная система. А вариант с $ полезен для того, чтобы прибить скрипт к конкретной сцене и явным образом ломаться в случае неожиданных изменений в этой сцене.
>>6373
Открой вкладку "Remote" в дереве сцены, когда твой проект падает (или когда ты его запустил и он вот-вот упадёт). Там ты можешь развернуть все ноды, начиная с Root, и кончая этими своими Label. При нажатии на каждую ноду в инспекторе отображаются все актуальные данные этой ноды, даже те, которые не экспортируются в скриптах и недоступны при редактировании файла сцены. В этом режиме можно поковыряться и найти проблему своим умом. А по твоим скриншотам невозможно точно сказать, в чём может быть твоя проблема - ясно только, что "нода должна была быть, но её нет".
Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять? В любом случае, твоей целью должна быть минимизация количества отдельных материалов любой ценой. В идеале все твои деревья должны иметь один общий материал с одним текстурным атласом. Особенно это касается OpenGL/Compatibility рендерера, но и на Vulkan можно заметить тормоза, если постараться (я тестировал это во времена Godot 4.0 или около того). А вдалеке от камеры деревья в играх часто "слипаются" в один лоуполи меш для ещё большей оптимизации, и, наконец, в плоские картинки-спрайты. Встроенный механизм в Godot позволяет только упростить геометрию объекта, всё остальное зависит от тебя. Но помни, что преждевременная оптимизация вредна, и поэтому сначала слепи из того, что есть, проведи замеры, найди самые тяжёлые места и только потом оптимизируй их.
>>6297
>Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Нет, на самом деле, на твоём скриншоте одна большая тень, просто светлая - цвета ambient lighting. Но если ты уменьшишь ambient lighting в настройках environment, тогда у тебя и снаружи дома тени будут 100% чёрными. Технически возможно менять этот параметр динамически: когда игрок заходит в тёмное помещение, ambient уменьшается до чёрного, а когда выходит на яркую улицу - поднимается обратно до серого (синеватого/зеленоватого/желтоватого). Кажется, так делали в старых играх, и это можно сделать намного эффективнее, чем любые техники GI. Если хочешь ещё больше реализма, тогда нужно ещё и bloom править относительно того, входит игрок в тёмное помещение или выходит на яркую улицу: когда только выходишь, свет бьёт в глаза и ослепляет, что можно реализовать, сильно увеличив bloom. В любом случае тебе потребуется способ определить, находится ли игрок в помещении... Что, наверное, и для геймплея пригодится (реакция NPC, стелс и т.п.), так что фича может быть намного важнее, чем может показаться на первый взгляд.
>>6343
>Как Сабвей сёрферс и темплран
Рекомендую разобраться с этой нодой, поможет для такого раннера:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
В классическом раннере у тебя 3 таких дорожки должно быть.
>>6393 (Del)
>хардкодишь
Не, он правильно делает, это стандартный способ связки нод.
>обьяви экспортную NodePath
Это совет для Godot 3.x? Сейчас можно проще: @export label: Label... только ему это не нужно делать. У него там, похоже, самостоятельная сцена, которую он хочет куда-то цеплять для какой-то отладки. Ей будет достаточно и стандартного "хардкода". Вариант с экспортом полезен в тех случаях, когда необходима универсальная система. А вариант с $ полезен для того, чтобы прибить скрипт к конкретной сцене и явным образом ломаться в случае неожиданных изменений в этой сцене.
>>6373
Открой вкладку "Remote" в дереве сцены, когда твой проект падает (или когда ты его запустил и он вот-вот упадёт). Там ты можешь развернуть все ноды, начиная с Root, и кончая этими своими Label. При нажатии на каждую ноду в инспекторе отображаются все актуальные данные этой ноды, даже те, которые не экспортируются в скриптах и недоступны при редактировании файла сцены. В этом режиме можно поковыряться и найти проблему своим умом. А по твоим скриншотам невозможно точно сказать, в чём может быть твоя проблема - ясно только, что "нода должна была быть, но её нет".
>>6245
Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять? В любом случае, твоей целью должна быть минимизация количества отдельных материалов любой ценой. В идеале все твои деревья должны иметь один общий материал с одним текстурным атласом. Особенно это касается OpenGL/Compatibility рендерера, но и на Vulkan можно заметить тормоза, если постараться (я тестировал это во времена Godot 4.0 или около того). А вдалеке от камеры деревья в играх часто "слипаются" в один лоуполи меш для ещё большей оптимизации, и, наконец, в плоские картинки-спрайты. Встроенный механизм в Godot позволяет только упростить геометрию объекта, всё остальное зависит от тебя. Но помни, что преждевременная оптимизация вредна, и поэтому сначала слепи из того, что есть, проведи замеры, найди самые тяжёлые места и только потом оптимизируй их.
>>6297
Нет, на самом деле, на твоём скриншоте одна большая тень, просто светлая - цвета ambient lighting. Но если ты уменьшишь ambient lighting в настройках environment, тогда у тебя и снаружи дома тени будут 100% чёрными. Технически возможно менять этот параметр динамически: когда игрок заходит в тёмное помещение, ambient уменьшается до чёрного, а когда выходит на яркую улицу - поднимается обратно до серого (синеватого/зеленоватого/желтоватого). Кажется, так делали в старых играх, и это можно сделать намного эффективнее, чем любые техники GI. Если хочешь ещё больше реализма, тогда нужно ещё и bloom править относительно того, входит игрок в тёмное помещение или выходит на яркую улицу: когда только выходишь, свет бьёт в глаза и ослепляет, что можно реализовать, сильно увеличив bloom. В любом случае тебе потребуется способ определить, находится ли игрок в помещении... Что, наверное, и для геймплея пригодится (реакция NPC, стелс и т.п.), так что фича может быть намного важнее, чем может показаться на первый взгляд.
>>6343
Рекомендую разобраться с этой нодой, поможет для такого раннера:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
В классическом раннере у тебя 3 таких дорожки должно быть.
>>6393 (Del)
Не, он правильно делает, это стандартный способ связки нод.
Это совет для Godot 3.x? Сейчас можно проще: @export label: Label... только ему это не нужно делать. У него там, похоже, самостоятельная сцена, которую он хочет куда-то цеплять для какой-то отладки. Ей будет достаточно и стандартного "хардкода". Вариант с экспортом полезен в тех случаях, когда необходима универсальная система. А вариант с $ полезен для того, чтобы прибить скрипт к конкретной сцене и явным образом ломаться в случае неожиданных изменений в этой сцене.
>>6373
Открой вкладку "Remote" в дереве сцены, когда твой проект падает (или когда ты его запустил и он вот-вот упадёт). Там ты можешь развернуть все ноды, начиная с Root, и кончая этими своими Label. При нажатии на каждую ноду в инспекторе отображаются все актуальные данные этой ноды, даже те, которые не экспортируются в скриптах и недоступны при редактировании файла сцены. В этом режиме можно поковыряться и найти проблему своим умом. А по твоим скриншотам невозможно точно сказать, в чём может быть твоя проблема - ясно только, что "нода должна была быть, но её нет".
Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять? В любом случае, твоей целью должна быть минимизация количества отдельных материалов любой ценой. В идеале все твои деревья должны иметь один общий материал с одним текстурным атласом. Особенно это касается OpenGL/Compatibility рендерера, но и на Vulkan можно заметить тормоза, если постараться (я тестировал это во времена Godot 4.0 или около того). А вдалеке от камеры деревья в играх часто "слипаются" в один лоуполи меш для ещё большей оптимизации, и, наконец, в плоские картинки-спрайты. Встроенный механизм в Godot позволяет только упростить геометрию объекта, всё остальное зависит от тебя. Но помни, что преждевременная оптимизация вредна, и поэтому сначала слепи из того, что есть, проведи замеры, найди самые тяжёлые места и только потом оптимизируй их.
>>6297
>Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Нет, на самом деле, на твоём скриншоте одна большая тень, просто светлая - цвета ambient lighting. Но если ты уменьшишь ambient lighting в настройках environment, тогда у тебя и снаружи дома тени будут 100% чёрными. Технически возможно менять этот параметр динамически: когда игрок заходит в тёмное помещение, ambient уменьшается до чёрного, а когда выходит на яркую улицу - поднимается обратно до серого (синеватого/зеленоватого/желтоватого). Кажется, так делали в старых играх, и это можно сделать намного эффективнее, чем любые техники GI. Если хочешь ещё больше реализма, тогда нужно ещё и bloom править относительно того, входит игрок в тёмное помещение или выходит на яркую улицу: когда только выходишь, свет бьёт в глаза и ослепляет, что можно реализовать, сильно увеличив bloom. В любом случае тебе потребуется способ определить, находится ли игрок в помещении... Что, наверное, и для геймплея пригодится (реакция NPC, стелс и т.п.), так что фича может быть намного важнее, чем может показаться на первый взгляд.
>>6343
>Как Сабвей сёрферс и темплран
Рекомендую разобраться с этой нодой, поможет для такого раннера:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
В классическом раннере у тебя 3 таких дорожки должно быть.
>>6393 (Del)
>хардкодишь
Не, он правильно делает, это стандартный способ связки нод.
>обьяви экспортную NodePath
Это совет для Godot 3.x? Сейчас можно проще: @export label: Label... только ему это не нужно делать. У него там, похоже, самостоятельная сцена, которую он хочет куда-то цеплять для какой-то отладки. Ей будет достаточно и стандартного "хардкода". Вариант с экспортом полезен в тех случаях, когда необходима универсальная система. А вариант с $ полезен для того, чтобы прибить скрипт к конкретной сцене и явным образом ломаться в случае неожиданных изменений в этой сцене.
>>6373
Открой вкладку "Remote" в дереве сцены, когда твой проект падает (или когда ты его запустил и он вот-вот упадёт). Там ты можешь развернуть все ноды, начиная с Root, и кончая этими своими Label. При нажатии на каждую ноду в инспекторе отображаются все актуальные данные этой ноды, даже те, которые не экспортируются в скриптах и недоступны при редактировании файла сцены. В этом режиме можно поковыряться и найти проблему своим умом. А по твоим скриншотам невозможно точно сказать, в чём может быть твоя проблема - ясно только, что "нода должна была быть, но её нет".
>>6456
Пасяб. А знаешь как выводить это всё в монетизацию через рекламу на смартфонах?
>Рекомендую разобраться с этой нодой, поможет для такого раннера:
Пасяб. А знаешь как выводить это всё в монетизацию через рекламу на смартфонах?
>>6456
Да это только пример. Я в целом осознал, что нихуя не понимаю, как оптимально работать с материалами. Именно не с точки зрения оптимизации, а вот тупо удобства, чтобы не делать 10 почти одинаковых материалов и не менять в них 10 раз одну настройку в случае необходимости.
Вот анон выше написал про instance shader uniforms - думаю, это вполне может помочь. Про атласы тоже нужно будет подумать, в общем-то.
>Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять?
Да это только пример. Я в целом осознал, что нихуя не понимаю, как оптимально работать с материалами. Именно не с точки зрения оптимизации, а вот тупо удобства, чтобы не делать 10 почти одинаковых материалов и не менять в них 10 раз одну настройку в случае необходимости.
Вот анон выше написал про instance shader uniforms - думаю, это вполне может помочь. Про атласы тоже нужно будет подумать, в общем-то.
>>6457
Я сам не делал, но вот ссылки:
https://kidscancode.org/godot_recipes/3.x/games/circle_jump/circle_jump_11/index.html
- туториал для 3.x, аддон 6 лет не обновлялся, но принцип должен остаться прежним.
Актуальные (наверное) аддоны для AdMob:
https://godotengine.org/asset-library/asset?filter=admob
https://github.com/poingstudios/godot-admob-plugin (2 месяца)
https://github.com/godot-sdk-integrations/godot-admob (свежее)
>>6487
О, а я и не знал... Вот тут подробнее, если кто-то тоже не знал:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html#per-instance-uniforms
Для удобства можешь написать tool-скрипт для своей сцены/ноды, которая зачем-то требует 10+ разных вариаций одного материала. У скрипта выводишь enum или другой параметр в export, а в сеттере будешь настраивать дубликат материала или выбирать материал из заготовленных заранее. Тебе просто нужен слой абстракции между материалами и тем, чем ты хочешь управлять. Например, вместо того, чтобы управлять материалами напрямую, делаешь enum State { NORMAL, DIRTY, ANCIENT, UGLY, ROTTEN }, и уже в скрипте, который делает @export var state: State: set(v)... будешь делать что-то с материалом (если это вообще нужно в конкретном случае). Если в будущем что-то потребуется переделать, то можешь переделать реализацию, не трогая эту настройку; например, если раньше "ROTTEN" делала просто серо-буро-малиновый оттенок, то теперь это же "ROTTEN" меняет несколько текстур на другие, но суть остаётся прежней - "этот объект должен выглядеть гнилым". Соответственно, вместо того, чтобы перетыкать в каждой сцене материалы на другие, ты просто меняешь детали реализации своего скрипта-прослойки.
Но прежде, чем писать такие скрипты, лучше набросать хоть что-то из того, что есть... "Make it exist first" и всё такое... А то потом будешь переделывать свои инструменты вместо работы над игрой.
>как выводить это всё в монетизацию через рекламу на смартфонах?
Я сам не делал, но вот ссылки:
https://kidscancode.org/godot_recipes/3.x/games/circle_jump/circle_jump_11/index.html
- туториал для 3.x, аддон 6 лет не обновлялся, но принцип должен остаться прежним.
Актуальные (наверное) аддоны для AdMob:
https://godotengine.org/asset-library/asset?filter=admob
https://github.com/poingstudios/godot-admob-plugin (2 месяца)
https://github.com/godot-sdk-integrations/godot-admob (свежее)
>>6487
>instance shader uniforms
О, а я и не знал... Вот тут подробнее, если кто-то тоже не знал:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html#per-instance-uniforms
>а вот тупо удобства, чтобы не делать 10 почти одинаковых материалов
Для удобства можешь написать tool-скрипт для своей сцены/ноды, которая зачем-то требует 10+ разных вариаций одного материала. У скрипта выводишь enum или другой параметр в export, а в сеттере будешь настраивать дубликат материала или выбирать материал из заготовленных заранее. Тебе просто нужен слой абстракции между материалами и тем, чем ты хочешь управлять. Например, вместо того, чтобы управлять материалами напрямую, делаешь enum State { NORMAL, DIRTY, ANCIENT, UGLY, ROTTEN }, и уже в скрипте, который делает @export var state: State: set(v)... будешь делать что-то с материалом (если это вообще нужно в конкретном случае). Если в будущем что-то потребуется переделать, то можешь переделать реализацию, не трогая эту настройку; например, если раньше "ROTTEN" делала просто серо-буро-малиновый оттенок, то теперь это же "ROTTEN" меняет несколько текстур на другие, но суть остаётся прежней - "этот объект должен выглядеть гнилым". Соответственно, вместо того, чтобы перетыкать в каждой сцене материалы на другие, ты просто меняешь детали реализации своего скрипта-прослойки.
Но прежде, чем писать такие скрипты, лучше набросать хоть что-то из того, что есть... "Make it exist first" и всё такое... А то потом будешь переделывать свои инструменты вместо работы над игрой.
>>6457
Я сам не делал, но вот ссылки:
https://kidscancode.org/godot_recipes/3.x/games/circle_jump/circle_jump_11/index.html
- туториал для 3.x, аддон 6 лет не обновлялся, но принцип должен остаться прежним.
Актуальные (наверное) аддоны для AdMob:
https://godotengine.org/asset-library/asset?filter=admob
https://github.com/poingstudios/godot-admob-plugin (2 месяца)
https://github.com/godot-sdk-integrations/godot-admob (свежее)
>>6487
О, а я и не знал... Вот тут подробнее, если кто-то тоже не знал:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html#per-instance-uniforms
Для удобства можешь написать tool-скрипт для своей сцены/ноды, которая зачем-то требует 10+ разных вариаций одного материала. У скрипта выводишь enum или другой параметр в export, а в сеттере будешь настраивать дубликат материала или выбирать материал из заготовленных заранее. Тебе просто нужен слой абстракции между материалами и тем, чем ты хочешь управлять. Например, вместо того, чтобы управлять материалами напрямую, делаешь enum State { NORMAL, DIRTY, ANCIENT, UGLY, ROTTEN }, и уже в скрипте, который делает @export var state: State: set(v)... будешь делать что-то с материалом (если это вообще нужно в конкретном случае). Если в будущем что-то потребуется переделать, то можешь переделать реализацию, не трогая эту настройку; например, если раньше "ROTTEN" делала просто серо-буро-малиновый оттенок, то теперь это же "ROTTEN" меняет несколько текстур на другие, но суть остаётся прежней - "этот объект должен выглядеть гнилым". Соответственно, вместо того, чтобы перетыкать в каждой сцене материалы на другие, ты просто меняешь детали реализации своего скрипта-прослойки.
Но прежде, чем писать такие скрипты, лучше набросать хоть что-то из того, что есть... "Make it exist first" и всё такое... А то потом будешь переделывать свои инструменты вместо работы над игрой.
>как выводить это всё в монетизацию через рекламу на смартфонах?
Я сам не делал, но вот ссылки:
https://kidscancode.org/godot_recipes/3.x/games/circle_jump/circle_jump_11/index.html
- туториал для 3.x, аддон 6 лет не обновлялся, но принцип должен остаться прежним.
Актуальные (наверное) аддоны для AdMob:
https://godotengine.org/asset-library/asset?filter=admob
https://github.com/poingstudios/godot-admob-plugin (2 месяца)
https://github.com/godot-sdk-integrations/godot-admob (свежее)
>>6487
>instance shader uniforms
О, а я и не знал... Вот тут подробнее, если кто-то тоже не знал:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html#per-instance-uniforms
>а вот тупо удобства, чтобы не делать 10 почти одинаковых материалов
Для удобства можешь написать tool-скрипт для своей сцены/ноды, которая зачем-то требует 10+ разных вариаций одного материала. У скрипта выводишь enum или другой параметр в export, а в сеттере будешь настраивать дубликат материала или выбирать материал из заготовленных заранее. Тебе просто нужен слой абстракции между материалами и тем, чем ты хочешь управлять. Например, вместо того, чтобы управлять материалами напрямую, делаешь enum State { NORMAL, DIRTY, ANCIENT, UGLY, ROTTEN }, и уже в скрипте, который делает @export var state: State: set(v)... будешь делать что-то с материалом (если это вообще нужно в конкретном случае). Если в будущем что-то потребуется переделать, то можешь переделать реализацию, не трогая эту настройку; например, если раньше "ROTTEN" делала просто серо-буро-малиновый оттенок, то теперь это же "ROTTEN" меняет несколько текстур на другие, но суть остаётся прежней - "этот объект должен выглядеть гнилым". Соответственно, вместо того, чтобы перетыкать в каждой сцене материалы на другие, ты просто меняешь детали реализации своего скрипта-прослойки.
Но прежде, чем писать такие скрипты, лучше набросать хоть что-то из того, что есть... "Make it exist first" и всё такое... А то потом будешь переделывать свои инструменты вместо работы над игрой.
>>6523
Круто. Спасибо. А есть какие-то актуальные видеокурсы по годоту? Что-то похожее по годности к курсам по юнити?
Круто. Спасибо. А есть какие-то актуальные видеокурсы по годоту? Что-то похожее по годности к курсам по юнити?
>>6542
Понятия не имею, я таким не интересуюсь. До массовых блокировок РКН я когда-то пытался качать какие-то видеокурсы с пиратских торрентов, и в результате забил диск этим мусором, а смотреть так и не посмотрел ничего. Лучше читай официальную документацию и делай всё сам... Я как-то глянул код к одному платному видеокурсу и ужаснулся, насколько всё криво там было, так что хуже всё равно не сделаешь. А если всё-таки сделаешь и упрёшься в ограничения - наверняка ответ уже есть где-то в интернете, а если нигде нет, то этот тред (и другие форумы) существует специально для таких вопросов.
Кстати, в Unity так и не удалось вкатиться несмотря на туториалы, а вот Godot оказался интуитивно понятен (после ознакомления с документацией). Но, может, сказался имевшийся у меня опыт программирования на других языках и инструментах...
>актуальные видеокурсы
Понятия не имею, я таким не интересуюсь. До массовых блокировок РКН я когда-то пытался качать какие-то видеокурсы с пиратских торрентов, и в результате забил диск этим мусором, а смотреть так и не посмотрел ничего. Лучше читай официальную документацию и делай всё сам... Я как-то глянул код к одному платному видеокурсу и ужаснулся, насколько всё криво там было, так что хуже всё равно не сделаешь. А если всё-таки сделаешь и упрёшься в ограничения - наверняка ответ уже есть где-то в интернете, а если нигде нет, то этот тред (и другие форумы) существует специально для таких вопросов.
Кстати, в Unity так и не удалось вкатиться несмотря на туториалы, а вот Godot оказался интуитивно понятен (после ознакомления с документацией). Но, может, сказался имевшийся у меня опыт программирования на других языках и инструментах...
>>6546
Поляна пустая. Ты бы мог свои курсы запилить с юпуп-каналом. Так, к слову. Особенно на фоне ползучего перехода людей от юнити на годот.
А как с тобой связаться если вдруг появится предложение по тому или иному поводу?
Поляна пустая. Ты бы мог свои курсы запилить с юпуп-каналом. Так, к слову. Особенно на фоне ползучего перехода людей от юнити на годот.
А как с тобой связаться если вдруг появится предложение по тому или иному поводу?
39 Кб, 640x635>>6552
Нет, много всякого, даже переходят старые "учители" с Unity, типа Brackeys (часто слышал, не смотрел)...
Вообще, Godot не так быстро обновляется, так что даже туториалы для Godot 3 могут быть актуальными, если не касаются каких-то тонких деталей, и если почитать в документации, что там изменилось:
https://docs.godotengine.org/en/stable/tutorials/migrating/index.html
Я не верю в эффективность "видеоуроков" как таковых - это больше развлекательный контент, чем реально полезные уроки, если мы говорим о программировании. Вот если по моделированию для Blender, то там да, полезно увидеть процесс работы крутана, так же, как и в классическом рисовании полезно смотреть, как работает мастер. А у программиста бОльшая часть работы происходит в голове, а написание/изменение кода - это наименьшая часть... В остальном же, Godot не проще и не сложнее любой другой программы на компьютере - если ты как-то смог открыть браузер и написать на форум, то и в Godot разберёшься.
Ты чё, мы же тут все анонимусы. Да я и не так много знаю, как тебе могло показаться.
>Поляна пустая.
Нет, много всякого, даже переходят старые "учители" с Unity, типа Brackeys (часто слышал, не смотрел)...
Вообще, Godot не так быстро обновляется, так что даже туториалы для Godot 3 могут быть актуальными, если не касаются каких-то тонких деталей, и если почитать в документации, что там изменилось:
https://docs.godotengine.org/en/stable/tutorials/migrating/index.html
>Ты бы мог свои курсы запилить с юпуп-каналом.
Я не верю в эффективность "видеоуроков" как таковых - это больше развлекательный контент, чем реально полезные уроки, если мы говорим о программировании. Вот если по моделированию для Blender, то там да, полезно увидеть процесс работы крутана, так же, как и в классическом рисовании полезно смотреть, как работает мастер. А у программиста бОльшая часть работы происходит в голове, а написание/изменение кода - это наименьшая часть... В остальном же, Godot не проще и не сложнее любой другой программы на компьютере - если ты как-то смог открыть браузер и написать на форум, то и в Godot разберёшься.
>А как с тобой связаться
Ты чё, мы же тут все анонимусы. Да я и не так много знаю, как тебе могло показаться.
>>6571
А никто тут гта6 не собирает. Речь про раннер, который немного выйдет за рамки принятых стандартов.
Ну, как сказать. Когда придёт время собирать игру, механики, оптимизации кода и всё то, что связано с программированием нужно будет кого-то нанять. Зачем идти в файверы когда уже есть готовое решение
>Да я и не так много знаю, как тебе могло показаться
А никто тут гта6 не собирает. Речь про раннер, который немного выйдет за рамки принятых стандартов.
Ну, как сказать. Когда придёт время собирать игру, механики, оптимизации кода и всё то, что связано с программированием нужно будет кого-то нанять. Зачем идти в файверы когда уже есть готовое решение
>>6575
Увы, я могу только бесплатными советами помочь.
Кстати, вот про "endless runner": >>1010674 →
Там несколько постов обсуждения было.
Увы, я могу только бесплатными советами помочь.
Кстати, вот про "endless runner": >>1010674 →
Там несколько постов обсуждения было.
>>6580
Окей. Спасибо в любом случае. А свои игры делаешь?
Окей. Спасибо в любом случае. А свои игры делаешь?
>>6703
Годетту да, а тот хуй что слева слишком всрат. Впрочем, как и его ниочемная игра. У челика талант к пиару и ноль таланта к геймдеву.
Годетту да, а тот хуй что слева слишком всрат. Впрочем, как и его ниочемная игра. У челика талант к пиару и ноль таланта к геймдеву.
1,3 Мб, 2032x2612>>6703
Блазию хочу! Бла-зи-ю!
Блазию хочу! Бла-зи-ю!
>>6709
Чё за игра и про речь вообще?
Чё за игра и про речь вообще?
Похоже, скоро 4.6.3 https://github.com/godotengine/godot/commit/457333bb66ff45e1d49e786ef45239d2adac64c7
Наконец-то, блин. Скорее бы уже
Наконец-то, блин. Скорее бы уже
>>6827
Да я на 4.6 переехать не могу с его релиза, лол. Редактор крашится на импорте анимаций
4.7 мне не оч интересен по фичам, мне лучше стабильный движок с тем что есть
Да я на 4.6 переехать не могу с его релиза, лол. Редактор крашится на импорте анимаций
4.7 мне не оч интересен по фичам, мне лучше стабильный движок с тем что есть
>>6828
Логи проверял? Движок можно запустить с --verbose для подробностей. Пробовал импортировать файлы по одному, чтобы локализовать проблемный? Вдруг у тебя какая-то уникальная проблема, о которой пока никто не знает - тогда ждать фиксов бесполезно. Нужно определить реальную проблему (какая именно анимация вызывает краш и почему), потом пойти на гитхаб и найти иссуй по теме, а если нет - создать новый по шаблону. Также, вполне возможно, ты там что-то намудрил в проекте, полагаясь на старый баг движка, который пофиксили, и поэтому он крашится с твоими анимациями - тогда фиксом будет переделывание твоих файлов, а не файлов движка (знаю, больно, но что поделать).
У меня есть и GTLF-анимации, и анимации, сделанные когда-то вручную в AnimationPlayer - и никаких проблем с перекатом на разные версии 4.6 не было. Сейчас я уже перекатился на 4.7, если что. Я читал иссуи с ошибками из-за повторяющихся имён нод - вроде бы, его должны уже были пофиксить.
Очень зря, там много quality-of-life фишек редактора. Многие нахваливают. Если ты уже сидишь на >=4.5, то я не вижу смысла избегать 4.7 (вот если сидишь на <=4.4 - то с тех пор многое поменяли...).
Наверное, ты и так знаешь, но напомню: после начала работы над следующей версией, багфиксы в патч-версиях - это обычно бэкпортинг со следующей версии на старую. То есть баг фиксится внутри master-ветки (которая почти всегда впереди dev/beta/rc/stable сборок), а потом его отдельным пуллреквестом адаптируют к предыдущей стабильной ветке (в данном случае 4.6). Так что нельзя сказать, что новая версия "менее стабильная", в ней просто чуть больше улучшений, чем в старой.
Короче - зря боишься, большинство проблем поправимо. Я несколько отдельных проектов (GDScript) перекатывал с третьей версии на четвёртую и испытал не так много проблем, как могло показаться, а с минорными версиями обычно на порядок меньше проблем...
Замораживать версию движка стоит только если у тебя live-service игра уровня Genshin под мобилки. Но такого уровня команды разработчиков пилят кастомные сборки, уходящие далеко от стандартных.
>Редактор крашится на импорте анимаций
Логи проверял? Движок можно запустить с --verbose для подробностей. Пробовал импортировать файлы по одному, чтобы локализовать проблемный? Вдруг у тебя какая-то уникальная проблема, о которой пока никто не знает - тогда ждать фиксов бесполезно. Нужно определить реальную проблему (какая именно анимация вызывает краш и почему), потом пойти на гитхаб и найти иссуй по теме, а если нет - создать новый по шаблону. Также, вполне возможно, ты там что-то намудрил в проекте, полагаясь на старый баг движка, который пофиксили, и поэтому он крашится с твоими анимациями - тогда фиксом будет переделывание твоих файлов, а не файлов движка (знаю, больно, но что поделать).
У меня есть и GTLF-анимации, и анимации, сделанные когда-то вручную в AnimationPlayer - и никаких проблем с перекатом на разные версии 4.6 не было. Сейчас я уже перекатился на 4.7, если что. Я читал иссуи с ошибками из-за повторяющихся имён нод - вроде бы, его должны уже были пофиксить.
>4.7 мне не оч интересен по фичам
Очень зря, там много quality-of-life фишек редактора. Многие нахваливают. Если ты уже сидишь на >=4.5, то я не вижу смысла избегать 4.7 (вот если сидишь на <=4.4 - то с тех пор многое поменяли...).
>мне лучше стабильный движок с тем что есть
Наверное, ты и так знаешь, но напомню: после начала работы над следующей версией, багфиксы в патч-версиях - это обычно бэкпортинг со следующей версии на старую. То есть баг фиксится внутри master-ветки (которая почти всегда впереди dev/beta/rc/stable сборок), а потом его отдельным пуллреквестом адаптируют к предыдущей стабильной ветке (в данном случае 4.6). Так что нельзя сказать, что новая версия "менее стабильная", в ней просто чуть больше улучшений, чем в старой.
Короче - зря боишься, большинство проблем поправимо. Я несколько отдельных проектов (GDScript) перекатывал с третьей версии на четвёртую и испытал не так много проблем, как могло показаться, а с минорными версиями обычно на порядок меньше проблем...
Замораживать версию движка стоит только если у тебя live-service игра уровня Genshin под мобилки. Но такого уровня команды разработчиков пилят кастомные сборки, уходящие далеко от стандартных.
>>6828
Логи проверял? Движок можно запустить с --verbose для подробностей. Пробовал импортировать файлы по одному, чтобы локализовать проблемный? Вдруг у тебя какая-то уникальная проблема, о которой пока никто не знает - тогда ждать фиксов бесполезно. Нужно определить реальную проблему (какая именно анимация вызывает краш и почему), потом пойти на гитхаб и найти иссуй по теме, а если нет - создать новый по шаблону. Также, вполне возможно, ты там что-то намудрил в проекте, полагаясь на старый баг движка, который пофиксили, и поэтому он крашится с твоими анимациями - тогда фиксом будет переделывание твоих файлов, а не файлов движка (знаю, больно, но что поделать).
У меня есть и GTLF-анимации, и анимации, сделанные когда-то вручную в AnimationPlayer - и никаких проблем с перекатом на разные версии 4.6 не было. Сейчас я уже перекатился на 4.7, если что. Я читал иссуи с ошибками из-за повторяющихся имён нод - вроде бы, его должны уже были пофиксить.
Очень зря, там много quality-of-life фишек редактора. Многие нахваливают. Если ты уже сидишь на >=4.5, то я не вижу смысла избегать 4.7 (вот если сидишь на <=4.4 - то с тех пор многое поменяли...).
Наверное, ты и так знаешь, но напомню: после начала работы над следующей версией, багфиксы в патч-версиях - это обычно бэкпортинг со следующей версии на старую. То есть баг фиксится внутри master-ветки (которая почти всегда впереди dev/beta/rc/stable сборок), а потом его отдельным пуллреквестом адаптируют к предыдущей стабильной ветке (в данном случае 4.6). Так что нельзя сказать, что новая версия "менее стабильная", в ней просто чуть больше улучшений, чем в старой.
Короче - зря боишься, большинство проблем поправимо. Я несколько отдельных проектов (GDScript) перекатывал с третьей версии на четвёртую и испытал не так много проблем, как могло показаться, а с минорными версиями обычно на порядок меньше проблем...
Замораживать версию движка стоит только если у тебя live-service игра уровня Genshin под мобилки. Но такого уровня команды разработчиков пилят кастомные сборки, уходящие далеко от стандартных.
>Редактор крашится на импорте анимаций
Логи проверял? Движок можно запустить с --verbose для подробностей. Пробовал импортировать файлы по одному, чтобы локализовать проблемный? Вдруг у тебя какая-то уникальная проблема, о которой пока никто не знает - тогда ждать фиксов бесполезно. Нужно определить реальную проблему (какая именно анимация вызывает краш и почему), потом пойти на гитхаб и найти иссуй по теме, а если нет - создать новый по шаблону. Также, вполне возможно, ты там что-то намудрил в проекте, полагаясь на старый баг движка, который пофиксили, и поэтому он крашится с твоими анимациями - тогда фиксом будет переделывание твоих файлов, а не файлов движка (знаю, больно, но что поделать).
У меня есть и GTLF-анимации, и анимации, сделанные когда-то вручную в AnimationPlayer - и никаких проблем с перекатом на разные версии 4.6 не было. Сейчас я уже перекатился на 4.7, если что. Я читал иссуи с ошибками из-за повторяющихся имён нод - вроде бы, его должны уже были пофиксить.
>4.7 мне не оч интересен по фичам
Очень зря, там много quality-of-life фишек редактора. Многие нахваливают. Если ты уже сидишь на >=4.5, то я не вижу смысла избегать 4.7 (вот если сидишь на <=4.4 - то с тех пор многое поменяли...).
>мне лучше стабильный движок с тем что есть
Наверное, ты и так знаешь, но напомню: после начала работы над следующей версией, багфиксы в патч-версиях - это обычно бэкпортинг со следующей версии на старую. То есть баг фиксится внутри master-ветки (которая почти всегда впереди dev/beta/rc/stable сборок), а потом его отдельным пуллреквестом адаптируют к предыдущей стабильной ветке (в данном случае 4.6). Так что нельзя сказать, что новая версия "менее стабильная", в ней просто чуть больше улучшений, чем в старой.
Короче - зря боишься, большинство проблем поправимо. Я несколько отдельных проектов (GDScript) перекатывал с третьей версии на четвёртую и испытал не так много проблем, как могло показаться, а с минорными версиями обычно на порядок меньше проблем...
Замораживать версию движка стоит только если у тебя live-service игра уровня Genshin под мобилки. Но такого уровня команды разработчиков пилят кастомные сборки, уходящие далеко от стандартных.
>>6867
Спасибо за обстоятельный ответ, так то всё по делу.
Вчера когда на радостях увидел мерджи, обратил внимание что мою проблему замерджили. PR висел долгое время. Я не автор, но следил и ждал пока примут.
Знаю, да. Но ведь туда и новые фичи добавляют, которые вызывают проблемы. Взять ту же мою проблему импорта, она появилась именно на 4.6, а пофиксят ее аж в 4.6.3. В целом ты прав, я попробую и до 4.7 подняться как он выйдет в rc версию, там поглядим
Спасибо за обстоятельный ответ, так то всё по делу.
>Логи проверял? Движок можно запустить с --verbose для подробностей. Пробовал импортировать файлы по одному, чтобы локализовать проблемный? Вдруг у тебя какая-то уникальная проблема, о которой пока никто не знает
Вчера когда на радостях увидел мерджи, обратил внимание что мою проблему замерджили. PR висел долгое время. Я не автор, но следил и ждал пока примут.
>Наверное, ты и так знаешь, но напомню: после начала работы над следующей версией, багфиксы в патч-версиях - это обычно бэкпортинг со следующей версии на старую.
Знаю, да. Но ведь туда и новые фичи добавляют, которые вызывают проблемы. Взять ту же мою проблему импорта, она появилась именно на 4.6, а пофиксят ее аж в 4.6.3. В целом ты прав, я попробую и до 4.7 подняться как он выйдет в rc версию, там поглядим
Кстати, я вам советовал shader per-instance uniform
А потом решил проверить, работают ли они в opengl web-exporte.
Оказалось, что с какого-то времени их туда портировали, но увы, в реальных браузерах глючат, какое-то невидимое ограничение в десяток материалов.
https://github.com/godotengine/godot/issues/112674
Хотя, может баг реализации, пишут что Blender умеет подобное поверх opengl делать
А потом решил проверить, работают ли они в opengl web-exporte.
Оказалось, что с какого-то времени их туда портировали, но увы, в реальных браузерах глючат, какое-то невидимое ограничение в десяток материалов.
https://github.com/godotengine/godot/issues/112674
Хотя, может баг реализации, пишут что Blender умеет подобное поверх opengl делать
>>6879
Кто-то сомневался? Бывают ли браузеры без глюков?
Браузер без глюков - тот, что никогда не запускают...
>в реальных браузерах глючат
Кто-то сомневался? Бывают ли браузеры без глюков?
Браузер без глюков - тот, что никогда не запускают...
>>6968
Так тут вахтеры банят чуть что, с удалением всех постов в треде. Смысл постить стремится к нулю. Переполз на реддит, заодно игру там пиарить можно не шкваря ее об имиджборды.
Так тут вахтеры банят чуть что, с удалением всех постов в треде. Смысл постить стремится к нулю. Переполз на реддит, заодно игру там пиарить можно не шкваря ее об имиджборды.
>>6969
Странно, меня тут почему-то не банили...
Может, проблема в тебе, а не в твоих "вахтёрах"?
Приношу соболезнования американским товарищам.
Странно, меня тут почему-то не банили...
Может, проблема в тебе, а не в твоих "вахтёрах"?
>Переполз на реддит
Приношу соболезнования американским товарищам.
>>6979
Помню его. Нет, я не он.
Помню его. Нет, я не он.
>>6979
Хуже вахтеров только подсосы вахтеров, поддерживающие цензуру и противники свободного общения.
Хуже вахтеров только подсосы вахтеров, поддерживающие цензуру и противники свободного общения.
>>7057
Вообще никаких претензий не имел бы, если бы этот сайт не позиционировал себя как площадка для свободного общения, а, например, как институт благородных девиц.
Вообще никаких претензий не имел бы, если бы этот сайт не позиционировал себя как площадка для свободного общения, а, например, как институт благородных девиц.
19 Кб, 650x450>>7059
Пошли манёвры... У тебя проблемы со зрением или ты так троллить пытаешься?
>>7024
Цензура необходима для поддержания свободного общения:
https://ru.wikipedia.org/wiki/Парадокс_толерантности
И вообще, тут не так часто кого-то трут. Чего бухтеть-то? Делитесь играми лучше.
>если бы этот сайт не позиционировал себя как площадка для свободного общения
Пошли манёвры... У тебя проблемы со зрением или ты так троллить пытаешься?
>>7024
>поддерживающие цензуру и противники свободного общения
Цензура необходима для поддержания свободного общения:
https://ru.wikipedia.org/wiki/Парадокс_толерантности
>неограниченная толерантность ведёт к исчезновению толерантности
>сохранение толерантности требует нетерпимого отношения к нетолерантным
И вообще, тут не так часто кого-то трут. Чего бухтеть-то? Делитесь играми лучше.
>>7075
У вахтера все движкосрач. Реальный парадокс тут в том, что на том же реддите, который как раз широко рассматривается как институт благородных девиц, пост пропускают, а у местного вахтера это движсрач, бан и удаление. Такое вот свободное общение, несвободней чем на огороженном реддите. Однажды проснешься, посмотришь в зеркало, а ты уже и сам сам движкосрач.
Еще и капчу опять усложнили.
У вахтера все движкосрач. Реальный парадокс тут в том, что на том же реддите, который как раз широко рассматривается как институт благородных девиц, пост пропускают, а у местного вахтера это движсрач, бан и удаление. Такое вот свободное общение, несвободней чем на огороженном реддите. Однажды проснешься, посмотришь в зеркало, а ты уже и сам сам движкосрач.
Еще и капчу опять усложнили.
>>7075
Меня тут так часто терли, что я просто перестал выкладывать что-то полезное или показывать игры. Зачем тратить на это усилия? Так что пошел ка ты с оправданием вахтеров.
Меня тут так часто терли, что я просто перестал выкладывать что-то полезное или показывать игры. Зачем тратить на это усилия? Так что пошел ка ты с оправданием вахтеров.
>>7075
А то что ты пишешь - это формализм и демагогия. Это правило явно противоречит "общаться свободно, где любая точка зрения имеет право на жизнь" можно привести аналогию, а если в разделе добавят правило что можно только в наморднике - побежишь выполнять? - и это мы даже не рассматриваем вопрос, кто и когда ввел это правило, какая процедура пересмотра или отмены неактуальных правил. И почему в этом разделе настолько отбитые вахтеры, в других я такого практически нигде не встречал. Впрочем это все уже годами игнорируется в /d, так что господь, жги. Тут никого не жалко.
А то что ты пишешь - это формализм и демагогия. Это правило явно противоречит "общаться свободно, где любая точка зрения имеет право на жизнь" можно привести аналогию, а если в разделе добавят правило что можно только в наморднике - побежишь выполнять? - и это мы даже не рассматриваем вопрос, кто и когда ввел это правило, какая процедура пересмотра или отмены неактуальных правил. И почему в этом разделе настолько отбитые вахтеры, в других я такого практически нигде не встречал. Впрочем это все уже годами игнорируется в /d, так что господь, жги. Тут никого не жалко.
>>7076
>>7080
мне кажется тебе нужно проспаться и не драматизировать
>>6968
>>7075
я в последнюю неделю в каком-то тильте был... Пробовал найти людей себе в команду, но все отказались назвав игру говном, естественно при этом надавав своих важных советов как надо правильно делать. Но щас вроде настроение урегулировывается, и наверн завтра продолжу потихоньку пилить
>>7080
мне кажется тебе нужно проспаться и не драматизировать
>>6968
>>7075
>Игры делаете?
>Делитесь играми лучше
я в последнюю неделю в каком-то тильте был... Пробовал найти людей себе в команду, но все отказались назвав игру говном, естественно при этом надавав своих важных советов как надо правильно делать. Но щас вроде настроение урегулировывается, и наверн завтра продолжу потихоньку пилить
>>7075
Как удобно ссылаться на "правило", которое сам написал. По факту ты единолично запретил в темах движков обсуждать движки. Ты сумасбросдный тиран.
В очередной раз подтвержается правило, что есть дать слабому человеку с добрыми намерениями власть, то всегда получится тиран.
Как удобно ссылаться на "правило", которое сам написал. По факту ты единолично запретил в темах движков обсуждать движки. Ты сумасбросдный тиран.
В очередной раз подтвержается правило, что есть дать слабому человеку с добрыми намерениями власть, то всегда получится тиран.
26 Кб, 808x133А почему VSCode при отладке с помощью точек остановки не показывает значение переменных?
>>7122
Лол, я не модератор и никогда не был модератором. Насколько я понимаю, в /gd/ модераторы менялись несколько раз, а правилу "движкосрачей" уже лет, наверное, десять... Когда я сюда пришёл (кажется, шесть лет назад), тут уже действовало это правило. Несогласны с этим правилом лишь какие-то тролли, набрасывающие говно на вентилятор. Ладно бы это смешно было - но спустя столько лет срачей уже не смешно нифига. Давайте лучше играми заниматься.
Никто никогда не удалял (я не видел) посты вроде:
Удаляются только посты наподобие таких:
Ты считаешь, что удалённые посты имеют хотя бы минимальную ценность для дискуссии о движках? Буквально кидание говном на вентилятор с целью спровоцировать срач, а не адекватное обсуждение. Скажи спасибо, что разрешают срать в специально отведённом треде срачей. В любом другом чисто творческом разделе (не будем тыкать пальцами) всех таких серунов просто перебанили бы.
>По факту ты единолично запретил
Лол, я не модератор и никогда не был модератором. Насколько я понимаю, в /gd/ модераторы менялись несколько раз, а правилу "движкосрачей" уже лет, наверное, десять... Когда я сюда пришёл (кажется, шесть лет назад), тут уже действовало это правило. Несогласны с этим правилом лишь какие-то тролли, набрасывающие говно на вентилятор. Ладно бы это смешно было - но спустя столько лет срачей уже не смешно нифига. Давайте лучше играми заниматься.
>в темах движков обсуждать движки
Никто никогда не удалял (я не видел) посты вроде:
>наткнулся на баг Godot, issue номер такой-то, как-то возможно обойти его или решить до багфикса?
>в GDScript отсутствует такая-то фича, как мне быть?
>мой код медленный, как можно оптимизировать?
Удаляются только посты наподобие таких:
>ряяяя гадот гавно глючное, ничаво не работает, всё крашицца и не работает, фуууу, пруфов не будет
>ряяяяя годотяскрипт гавно, сишорп топ, яскозал
>ряяяяяяя чё так всё тормозит, фууу гавно какое
Ты считаешь, что удалённые посты имеют хотя бы минимальную ценность для дискуссии о движках? Буквально кидание говном на вентилятор с целью спровоцировать срач, а не адекватное обсуждение. Скажи спасибо, что разрешают срать в специально отведённом треде срачей. В любом другом чисто творческом разделе (не будем тыкать пальцами) всех таких серунов просто перебанили бы.
>>7177
Это ввел котел или тот шиз, у которого "сообщество сплотилось". Их тогда мастерки троллил серега и у них попка сгорела от этого, они вошли в рейдж мод и начали банить всех.
Так все и было. Сейчас в этом правиле нет смысла. Доска и так дохлая. Любые посты ее только оживят.
Это ввел котел или тот шиз, у которого "сообщество сплотилось". Их тогда мастерки троллил серега и у них попка сгорела от этого, они вошли в рейдж мод и начали банить всех.
Так все и было. Сейчас в этом правиле нет смысла. Доска и так дохлая. Любые посты ее только оживят.
>>7159
У тебя официальный плагин установлен?
https://github.com/godotengine/godot-vscode-plugin
Если установлен, поищи по issues эту проблему.
Все данные можно посмотреть в дебаггере Godot. Особенно удобно смотреть состояние нод, которое отображается в инспекторе, а не в коде скриптов.
Если честно, не использовал "точки остановки" для дебаггинга со времён Turbo Pascal 7.0... Нет лучшего дебаггера, чем выполнение кода в своей голове. К внешним дебаггерам прибегаю только если не знаю поведение API движка или забыл о чём-то...
>VSCode
У тебя официальный плагин установлен?
https://github.com/godotengine/godot-vscode-plugin
Если установлен, поищи по issues эту проблему.
>не показывает значение переменных
Все данные можно посмотреть в дебаггере Godot. Особенно удобно смотреть состояние нод, которое отображается в инспекторе, а не в коде скриптов.
Если честно, не использовал "точки остановки" для дебаггинга со времён Turbo Pascal 7.0... Нет лучшего дебаггера, чем выполнение кода в своей голове. К внешним дебаггерам прибегаю только если не знаю поведение API движка или забыл о чём-то...
>>7177
Типичный подсос вахтера, с запугиваниями "а вот в других разделах еще суровее" (ложь), "тут не удаляют посты (я не видел)" - ну конечно не видел, они же удалены, "бывают посты только двух видов и твои я записываю в плохие" - передергивание.
Типичный подсос вахтера, с запугиваниями "а вот в других разделах еще суровее" (ложь), "тут не удаляют посты (я не видел)" - ну конечно не видел, они же удалены, "бывают посты только двух видов и твои я записываю в плохие" - передергивание.
>>7181
Хочешь превратить /gd/ в филиал /b/? 4-е правило:
Все претензии направляй в /d/.
Если в /gd/ будут бестолковые срачи, новички будут поддерживать срачи, и доска станет бестолковой сральней. Если будет хоть и медленный, но высококачественный постинг, то новички будут поддерживать высококачественный постинг, и это, возможно, сделает доску великой снова. Логично?
Лично я хочу видеть качественные посты анонов о разрабатываемых ими играх или интересные посты с техническими подробностями разработки игр (или игровых движков), а не срачи уровня школьников, сцепившихся друг с другом в коридоре на перемене.
Короче: не нужно "оживлять" доску шитпостингом.
>Любые посты ее только оживят.
Хочешь превратить /gd/ в филиал /b/? 4-е правило:
>Главное — не количество, а качество. Посты и файлы, не несущие никакой полезной информации, именуются шитпостингом и могут быть удалены, а постеры — забанены. Данное правило касается всех досок, кроме /b/, если обратное не указано в правилах доски.
Все претензии направляй в /d/.
Если в /gd/ будут бестолковые срачи, новички будут поддерживать срачи, и доска станет бестолковой сральней. Если будет хоть и медленный, но высококачественный постинг, то новички будут поддерживать высококачественный постинг, и это, возможно, сделает доску великой снова. Логично?
Лично я хочу видеть качественные посты анонов о разрабатываемых ими играх или интересные посты с техническими подробностями разработки игр (или игровых движков), а не срачи уровня школьников, сцепившихся друг с другом в коридоре на перемене.
Короче: не нужно "оживлять" доску шитпостингом.
>>7188
Для этого надо устранить вахтеров. Пока есть вахтеры, качественных постов не будет, нет смысла стараться.
>Лично я хочу видеть качественные посты анонов
Для этого надо устранить вахтеров. Пока есть вахтеры, качественных постов не будет, нет смысла стараться.
>>7187
А ты попробуй зайти в другие разделы (не дохлые).
Я тут почти ежедневно и часто вижу, как пост с откровенным спамом висит несколько часов. Т.е. я видел множество срачей задолго до их удаления.
Т.е. ты признаёшь, что предпочитаешь шитпостить?
>>7189
Ты отдаёшь себе отчёт, что модераторы не только на репорты реагируют, но и сами время от времени просматривают треды? Если есть нарушения правил, модератор удаляет их даже без "вахтёров" - только наступает это чуть позже. Простой анон не может предотвратить удаление твоего срача здесь.
Ты вообще игры делаешь или только шитпостишь?
>"а вот в других разделах еще суровее" (ложь)
А ты попробуй зайти в другие разделы (не дохлые).
>ну конечно не видел, они же удалены
Я тут почти ежедневно и часто вижу, как пост с откровенным спамом висит несколько часов. Т.е. я видел множество срачей задолго до их удаления.
>твои я записываю в плохие
Т.е. ты признаёшь, что предпочитаешь шитпостить?
>>7189
>устранить вахтеров
Ты отдаёшь себе отчёт, что модераторы не только на репорты реагируют, но и сами время от времени просматривают треды? Если есть нарушения правил, модератор удаляет их даже без "вахтёров" - только наступает это чуть позже. Простой анон не может предотвратить удаление твоего срача здесь.
Ты вообще игры делаешь или только шитпостишь?
Ну вот я ньюфаг и сижу тут у вас пару месяцев. Два раза случайно начал срач C# vs gdscript, активно читал как подрывались пердаки и аноны переходили на личности. Ничего не потерли. Читал посты анонов которые пилят две игры, одну-клон Jedi Academy (кстати, где ты анон, как твой прогресс? У тебя прикольная игра) и про курьера. Вот чел который про курьера делал поех, я не удивлен что его изжили. Как-то я прислал ему кучу полезных ссылок на его проблему, на что был послан нахуй целым полотным про то, что он уже это все читал и знает и вообще он не еблан. На следующий день он писал что забросил разработку, еще на следующий что продолжил. Там чел неадекват, ладно бы с депрессией (я такой), так кидается на всех. Тереть токсичное говно - это имхо не вахтерство. А больше я и не видел чтобы что-то терли. Если это из других тредов приходят какать, может просто не будем им отвечать на их провокации? Олсо спасибо тем кто отвечает на вопросы итт, мне реально уже несколько раз помогли. Пока игры у меня нет, но если будет что готовое мб и запостю, если не постесняюсь
>>7191
А я сижу во многих разделах. Ну бывает иногда редкий бан на день, но уж точно не полугодовые с delall за какой нибудь вопрос в треде движка. Единственное исключение аниме-бототред в /b, но там какая то ебанутая история с детектом рейлганофага. Собственно и тут то проблема в том что определенных людей записали во враги и банят всех кого принимают за них
Ты не понял, что я сказал? Посты бывают намного больше чем два вида, а ты просто применил тупую манипуляцию ложной дилеммы "раз тебя банят, то твои посты точно были вида 2".
А я сижу во многих разделах. Ну бывает иногда редкий бан на день, но уж точно не полугодовые с delall за какой нибудь вопрос в треде движка. Единственное исключение аниме-бототред в /b, но там какая то ебанутая история с детектом рейлганофага. Собственно и тут то проблема в том что определенных людей записали во враги и банят всех кого принимают за них
>>твои я записываю в плохие
>Т.е. ты признаёшь, что предпочитаешь шитпостить?
Ты не понял, что я сказал? Посты бывают намного больше чем два вида, а ты просто применил тупую манипуляцию ложной дилеммы "раз тебя банят, то твои посты точно были вида 2".
>>7191
Опять манипуляции. Якобы нельзя и постить полезное и шитпостить. Или якобы можно только или делать игры, или шитпостить.
>Ты вообще игры делаешь или только шитпостишь?
Опять манипуляции. Якобы нельзя и постить полезное и шитпостить. Или якобы можно только или делать игры, или шитпостить.
>>7192
Двачую. У него вроде ИРЛ работа и на игру времени остаётся мало, поэтому он редко что-то постит.
Да... Ему лечиться нужно, явно беда с башкой хуже депрессии/ангедонии, но он не осознаёт. Ну или он настолько задолбан ИРЛ, что на нервах постоянно. Немножко жаль, правда, что потеряли его видосы...
Попробуй поделать простые аркадные игры <90-х. Публиковать саму игру куда-то не обязательно, но её программирование поможет набить руку. В играх относительно немного рабочих паттернов, так что большинство игр копируют механики старых игр.
>>7193
Учи мемы: https://ru.wiktionary.org/wiki/утрировать
>>7194
Да в Godot-тредах полно безобидных шитпостов, не связанных с хейтом движка/скриптов/пользователя конкретного движка и т.п. И их обычно не удаляют. Собственно поэтому мы и набрали 79.5 тредов, лол.
В сутках 24 часа - ты либо работаешь, либо валяешь дурака ради развлечения/прокрастинации. Кстати, отвлекаете меня (ладно, сам виноват, что отвлёкся).
>одну-клон Jedi Academy (кстати, где ты анон, как твой прогресс? У тебя прикольная игра)
Двачую. У него вроде ИРЛ работа и на игру времени остаётся мало, поэтому он редко что-то постит.
>Там чел неадекват, ладно бы с депрессией (я такой), так кидается на всех.
Да... Ему лечиться нужно, явно беда с башкой хуже депрессии/ангедонии, но он не осознаёт. Ну или он настолько задолбан ИРЛ, что на нервах постоянно. Немножко жаль, правда, что потеряли его видосы...
>Пока игры у меня нет, но если будет что готовое мб и запостю, если не постесняюсь
Попробуй поделать простые аркадные игры <90-х. Публиковать саму игру куда-то не обязательно, но её программирование поможет набить руку. В играх относительно немного рабочих паттернов, так что большинство игр копируют механики старых игр.
>>7193
>Посты бывают намного больше чем два вида
Учи мемы: https://ru.wiktionary.org/wiki/утрировать
>>7194
>Якобы нельзя и постить полезное и шитпостить.
Да в Godot-тредах полно безобидных шитпостов, не связанных с хейтом движка/скриптов/пользователя конкретного движка и т.п. И их обычно не удаляют. Собственно поэтому мы и набрали 79.5 тредов, лол.
>можно только или делать игры, или шитпостить.
В сутках 24 часа - ты либо работаешь, либо валяешь дурака ради развлечения/прокрастинации. Кстати, отвлекаете меня (ладно, сам виноват, что отвлёкся).
>>7192
Спасибо!
Вообще, никуда не уходил, просто особо смысла пока постить не вижу, я щас по большей части занимаюсь наполнением контента пилю карты и сюжет. И то, в последнее время темп заметно снизился по определенным причинам например пробовал себя немного в другом жанре, который думаю развивать после самурая; оформлял загранник сегодня забрал, а значит скоро скорее всего страничку заведу. До этого не мог потому что оказывается, паспорт не должен быть старше 7ми лет для стима и тп. Видюшку хотел записать когда будет стабильная 4.7, и то, ток наверн меч с новым лайтом просто посмотреть как будет и мапу какую нибудь, тк пока каких-то новых функций не добавляю. А так ещё хз, куда-то пропал чел с летающей карлицей, а он меня в целом вдохновлял разработкой заниматься и делится в треде
>одну-клон Jedi Academy (кстати, где ты анон, как твой прогресс? У тебя прикольная игра)
Спасибо!
Вообще, никуда не уходил, просто особо смысла пока постить не вижу, я щас по большей части занимаюсь наполнением контента пилю карты и сюжет. И то, в последнее время темп заметно снизился по определенным причинам например пробовал себя немного в другом жанре, который думаю развивать после самурая; оформлял загранник сегодня забрал, а значит скоро скорее всего страничку заведу. До этого не мог потому что оказывается, паспорт не должен быть старше 7ми лет для стима и тп. Видюшку хотел записать когда будет стабильная 4.7, и то, ток наверн меч с новым лайтом просто посмотреть как будет и мапу какую нибудь, тк пока каких-то новых функций не добавляю. А так ещё хз, куда-то пропал чел с летающей карлицей, а он меня в целом вдохновлял разработкой заниматься и делится в треде
Кто движок 4.6+ сам компилирует, вы делаете с поддержкой d3d12? Я вот хз зачем оно нужно вообще для игры где не ААА графика. Сильно ли уплоняется билд?
>>7211
Говорят, что поддержка DX12 на Windows лучше, чем поддержка Vulkan - DX стабильнее и имеет меньше проблем с драйверами (в теории). Вот здесь, например, одно из старых обсуждений:
https://github.com/godotengine/godot-proposals/discussions/7644
Если компьютер игрока не поддерживает DX12, то Godot попытается использовать Vulkan, а если и Vulkan не поддерживается, тогда OpenGL (Compatibility). Если в настройках проекта выбран Vulkan, но он не поддерживается, то Godot попытается использовать DX12, а если и DX не поддерживается, то OpenGL. Это должно быть видно в логе при запуске проекта. По крайней мере, так написано в документации:
https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html
В новых проектах с Forward+ Godot установит DX12 по умолчанию в настройках проекта:
В старом проекте останется Vulkan - это можно изменить в настройках проекта.
По моим личным ощущениям (только что проверил), с DX12 дольше компиляция шейдеров и дольше их загрузка из кэша при повторном запуске, чем с Vulkan (но у меня очень старый компьютер, на новом вряд ли заметишь разницу), но визуально ощутимых отличий не вижу (но у меня не используются сложные эффекты, и поддержка DX12 у меня на уровне "11_0").
По весу бинарного файла движка разница в считанные мегабайты, т.е. совершенно незаметная даже для инди 3D с нормальными текстурами, музыкой и т.д. Думаю, нерационально удалять его из билда, если у тебя не 2D игрушка на OpenGL (Compatibility), т.к. поддержка Vulkan пока не очень... Кстати, сейчас билды по умолчанию включают DX12, то есть никаких манипуляций для его включения не нужно.
>зачем оно нужно вообще для игры где не ААА графика
Говорят, что поддержка DX12 на Windows лучше, чем поддержка Vulkan - DX стабильнее и имеет меньше проблем с драйверами (в теории). Вот здесь, например, одно из старых обсуждений:
https://github.com/godotengine/godot-proposals/discussions/7644
Если компьютер игрока не поддерживает DX12, то Godot попытается использовать Vulkan, а если и Vulkan не поддерживается, тогда OpenGL (Compatibility). Если в настройках проекта выбран Vulkan, но он не поддерживается, то Godot попытается использовать DX12, а если и DX не поддерживается, то OpenGL. Это должно быть видно в логе при запуске проекта. По крайней мере, так написано в документации:
https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html
В новых проектах с Forward+ Godot установит DX12 по умолчанию в настройках проекта:
>rendering_device/driver.windows="d3d12"
В старом проекте останется Vulkan - это можно изменить в настройках проекта.
По моим личным ощущениям (только что проверил), с DX12 дольше компиляция шейдеров и дольше их загрузка из кэша при повторном запуске, чем с Vulkan (но у меня очень старый компьютер, на новом вряд ли заметишь разницу), но визуально ощутимых отличий не вижу (но у меня не используются сложные эффекты, и поддержка DX12 у меня на уровне "11_0").
По весу бинарного файла движка разница в считанные мегабайты, т.е. совершенно незаметная даже для инди 3D с нормальными текстурами, музыкой и т.д. Думаю, нерационально удалять его из билда, если у тебя не 2D игрушка на OpenGL (Compatibility), т.к. поддержка Vulkan пока не очень... Кстати, сейчас билды по умолчанию включают DX12, то есть никаких манипуляций для его включения не нужно.
>>7221
Спасибо. И правда, если разница всего несколько мегабайт то и не надо пренебрегать
Кстати насчет шейдеров, недавно компиляцию обсуждали, какой все-таки оптимальный путь их прекомпилировать? https://github.com/Brandt-J/ShaderPrecompiler вот такое и альтернативы?
Спасибо. И правда, если разница всего несколько мегабайт то и не надо пренебрегать
Кстати насчет шейдеров, недавно компиляцию обсуждали, какой все-таки оптимальный путь их прекомпилировать? https://github.com/Brandt-J/ShaderPrecompiler вот такое и альтернативы?
>>7222
Понятия не имею, я ни одного проекта на Godot не релизнул пока, поэтому этим вопросом особо не задавался. Но вариант с крутящимся кубиком в пределах Camera3D на загрузочном экране или в отдельном SubViewport должен быть более чем достаточным. Если будешь делать в основном вьюпорте и чем-то перекрывать - убедись, что оклюжен кулинг не срабатывает (если ты его используешь, он вроде не автоматический пока что, нужно настраивать). В отдельном SubViewport проблем быть не должно (если правильно выставить режим рендера). Какой-то специальный аддон тут точно не нужен - можно и самому всё настроить.
Вообще, я смотрю на бенчмарки - сегодня у всех настолько мощные компы, что даже самая "бюджетная сборка" мощнее раз в 10, чем мой текущий компьютер, на котором я делаю и тестирую свою игру. Даже ругаемый всеми в /hw/ ноутбук на встройке был бы мощнее в играх, чем мой ПК... Не думаю, что статтеры от шейдеров волнуют кого-то, кто купил новый компьютер специально под игры за последние несколько лет... А такие как я, кто сидит на старом ПК, давно привыкли, что новые игры тормозят так, что подвешивают всю ОС.
И вот ещё статья из документации, если ещё не читал:
https://docs.godotengine.org/en/stable/tutorials/performance/pipeline_compilations.html
Я подумываю собрать свой собственный загрузочный экран с компилятором шейдеров и менеджером ресурсов типа системы частиц, но у меня пока такой бардак в проектах, что лень разбираться и что-то такое делать.
>какой все-таки оптимальный путь их прекомпилировать
Понятия не имею, я ни одного проекта на Godot не релизнул пока, поэтому этим вопросом особо не задавался. Но вариант с крутящимся кубиком в пределах Camera3D на загрузочном экране или в отдельном SubViewport должен быть более чем достаточным. Если будешь делать в основном вьюпорте и чем-то перекрывать - убедись, что оклюжен кулинг не срабатывает (если ты его используешь, он вроде не автоматический пока что, нужно настраивать). В отдельном SubViewport проблем быть не должно (если правильно выставить режим рендера). Какой-то специальный аддон тут точно не нужен - можно и самому всё настроить.
Вообще, я смотрю на бенчмарки - сегодня у всех настолько мощные компы, что даже самая "бюджетная сборка" мощнее раз в 10, чем мой текущий компьютер, на котором я делаю и тестирую свою игру. Даже ругаемый всеми в /hw/ ноутбук на встройке был бы мощнее в играх, чем мой ПК... Не думаю, что статтеры от шейдеров волнуют кого-то, кто купил новый компьютер специально под игры за последние несколько лет... А такие как я, кто сидит на старом ПК, давно привыкли, что новые игры тормозят так, что подвешивают всю ОС.
И вот ещё статья из документации, если ещё не читал:
https://docs.godotengine.org/en/stable/tutorials/performance/pipeline_compilations.html
Я подумываю собрать свой собственный загрузочный экран с компилятором шейдеров и менеджером ресурсов типа системы частиц, но у меня пока такой бардак в проектах, что лень разбираться и что-то такое делать.
47 Кб, 973x299>>7222
Насколько я помню, если речь идет о DX12, а значит 4-ке, то там все само прекомпилируется, есть убершейдеры, что-то типа "обобщенного" шейдера, который будет рисовать твой объект, пока нужный шейдер компилируется "в фоне". Не знаю, в каком сейчас состоянии это все. Ну и надо не забывать, что современные шейдеры же кешируются где-то, то есть может быть на втором запуске игры уже и не будет перекомпиляции.
Насколько я помню, если речь идет о DX12, а значит 4-ке, то там все само прекомпилируется, есть убершейдеры, что-то типа "обобщенного" шейдера, который будет рисовать твой объект, пока нужный шейдер компилируется "в фоне". Не знаю, в каком сейчас состоянии это все. Ну и надо не забывать, что современные шейдеры же кешируются где-то, то есть может быть на втором запуске игры уже и не будет перекомпиляции.
54 Кб, 1600x1499>>7228
Вроде бы, так и должно быть, и я даже помню, что когда-то давно замечал, как у меня объекты "мигали" во время компиляции, но от статтеров это всё равно не избавляет, и прямо сейчас на 4.6/4.7 у меня игра может подвешиваться на секунду при компиляции шейдера. Но мой комп очень слабый для современных игр.
Да, по умолчанию кэш шейдеров включён (+сжатие). Иногда, вроде, может приводить к глюкам, если кэш сломался почему-то (у меня доходило до BSOD на какой-то из старых версий). Также стоит заметить, что каждая новая версия движка имеет свой отдельный кэш шейдеров, и кэш при запуске из Editor отличается от кэша при запуске проекта с того же Editor-билда, но отдельно от редактора (например, если положить билд редактора в папку проекта и запустить его). В первом случае кэш должен храниться в папке /.godot/ внутри папки проекта, а во втором случае кэш хранится в папке user:// проекта (её можно легко найти с помощью кнопки в меню редактора; на Windows она будет где-то в %appdata%/Godot/app_userdata). Это всё важно знать для того, чтобы правильно очищать кэш во время тестирования "первого" запуска игры.
Алсо, кэш шейдеров не избавляет от статтера в результате инициализации системы частиц, загрузки тяжёлых ресурсов с диска, генерации NoiseTexture и т.д. Так что кроме прекомпилятора шейдеров нужно ещё и менеджер ресурсов делать, если у вас игра сложнее одной сцены. Но это немного отдельная тема...
Я бы его постам не доверял. Его авторитет в r/Godot на уровне пикрил игрушки. Лол.
>который будет рисовать твой объект, пока нужный шейдер компилируется
Вроде бы, так и должно быть, и я даже помню, что когда-то давно замечал, как у меня объекты "мигали" во время компиляции, но от статтеров это всё равно не избавляет, и прямо сейчас на 4.6/4.7 у меня игра может подвешиваться на секунду при компиляции шейдера. Но мой комп очень слабый для современных игр.
>современные шейдеры же кешируются где-то
Да, по умолчанию кэш шейдеров включён (+сжатие). Иногда, вроде, может приводить к глюкам, если кэш сломался почему-то (у меня доходило до BSOD на какой-то из старых версий). Также стоит заметить, что каждая новая версия движка имеет свой отдельный кэш шейдеров, и кэш при запуске из Editor отличается от кэша при запуске проекта с того же Editor-билда, но отдельно от редактора (например, если положить билд редактора в папку проекта и запустить его). В первом случае кэш должен храниться в папке /.godot/ внутри папки проекта, а во втором случае кэш хранится в папке user:// проекта (её можно легко найти с помощью кнопки в меню редактора; на Windows она будет где-то в %appdata%/Godot/app_userdata). Это всё важно знать для того, чтобы правильно очищать кэш во время тестирования "первого" запуска игры.
Алсо, кэш шейдеров не избавляет от статтера в результате инициализации системы частиц, загрузки тяжёлых ресурсов с диска, генерации NoiseTexture и т.д. Так что кроме прекомпилятора шейдеров нужно ещё и менеджер ресурсов делать, если у вас игра сложнее одной сцены. Но это немного отдельная тема...
>TheDuriel
Я бы его постам не доверял. Его авторитет в r/Godot на уровне пикрил игрушки. Лол.
202 Кб, 1230x987>>7234
Обычные вахтеры, которые травят умного (95% upvoted) и в меру грубого к идиотам знатока.
Где то я такое видел... А, точно
>Я бы его постам не доверял. Его авторитет в r/Godot на уровне пикрил игрушки. Лол.
Обычные вахтеры, которые травят умного (95% upvoted) и в меру грубого к идиотам знатока.
Где то я такое видел... А, точно
>>7240
Меня выбесил его комментарий, что он якобы "invented inherited scenes", хотя всё, что он сделал - это только популяризировал эту фичу в сабреддите, а сделали её совсем другие люди (насколько я понял дальнейшее обсуждение). И он даже не исправил своё сообщение.
Это только показывает масштабы его ЧСВ. Реально умный игнорировал бы идиотов...
На Reddit вообще странная система голосов. Иногда загоняют в -100 за нормальный комментарий, иногда залайкивают на +10к за тупейшую шутку. Зависит от сабреддита, конечно, но r/Godot по ощущениям на 90% состоит из детей/школьников, новичков в геймдеве.
Я просто хочу сказать: проверяйте всё сами, не доверяя рандому из интернета, даже если у него самое большое число попугаев в какой-то местной табличке рекордов. Особенно если этот рандом имеет настолько высокое ЧСВ, что не принимает никакую критику.
Говорю как тот, кто когда-то имел высокий рейтинг на каком-то форуме. Стыдно...
Меня выбесил его комментарий, что он якобы "invented inherited scenes", хотя всё, что он сделал - это только популяризировал эту фичу в сабреддите, а сделали её совсем другие люди (насколько я понял дальнейшее обсуждение). И он даже не исправил своё сообщение.
>в меру грубого к идиотам
Это только показывает масштабы его ЧСВ. Реально умный игнорировал бы идиотов...
>95% upvoted
На Reddit вообще странная система голосов. Иногда загоняют в -100 за нормальный комментарий, иногда залайкивают на +10к за тупейшую шутку. Зависит от сабреддита, конечно, но r/Godot по ощущениям на 90% состоит из детей/школьников, новичков в геймдеве.
Я просто хочу сказать: проверяйте всё сами, не доверяя рандому из интернета, даже если у него самое большое число попугаев в какой-то местной табличке рекордов. Особенно если этот рандом имеет настолько высокое ЧСВ, что не принимает никакую критику.
Говорю как тот, кто когда-то имел высокий рейтинг на каком-то форуме. Стыдно...
https://godotengine.org/article/godot-growth-stats-2026/
Статы годота, с официального сайта годота. Годот годот. Годот. Статы официальные. С сайта, тоже официального.
Статы годота, с официального сайта годота. Годот годот. Годот. Статы официальные. С сайта, тоже официального.
>>7416 (Del)
А мне вполне верится. Гораздо больше актива по Годоту стало во всех соцсетях, это легко проверить самому
А мне вполне верится. Гораздо больше актива по Годоту стало во всех соцсетях, это легко проверить самому
Чел пилит опенворлд
https://www.youtube.com/@Gierki_Dev/videos
https://www.youtube.com/@Gierki_Dev/videos
>>7504
проиграл
проиграл
>>7504
все наверно поржнут но именно эти две кнопки в будущем я создам огромнейшую мега проработаную глубочайшую игру и заработаю миллионы долларов
все наверно поржнут но именно эти две кнопки в будущем я создам огромнейшую мега проработаную глубочайшую игру и заработаю миллионы долларов
1,3 Мб, 1844x686>>7543
Надо в шапку, а то народ все время спрашивает - что делают на годоте?
О, кстати заебок то какой делают! Это ж пасфайндер в космосе.
https://www.youtube.com/watch?v=jQse-bQ4_-s
Надо в шапку, а то народ все время спрашивает - что делают на годоте?
О, кстати заебок то какой делают! Это ж пасфайндер в космосе.
https://www.youtube.com/watch?v=jQse-bQ4_-s
>>7564
Спок, движкосрачер.
Спок, движкосрачер.
>>7547
Не надо. В шапку треда надо достижения местных с использованием Godot. Вот ты какую игру делаешь?
Ты ньюфаг? Не "народ", а один тролль. Если кому-то необходимо посмотреть на игры на Godot в Steam, существуют официальные кураторы:
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot
https://store.steampowered.com/curator/45715609-Made-with-Godot-2
А также steamdb, поиск по тегам на itch.io и т.д.
Ну делают и делают, чего бухтеть-то?
Это не для игроков сделано, а для ролевиков:
https://en.wikipedia.org/wiki/Starfinder_Roleplaying_Game
>Надо в шапку
Не надо. В шапку треда надо достижения местных с использованием Godot. Вот ты какую игру делаешь?
>народ все время спрашивает - что делают на годоте
Ты ньюфаг? Не "народ", а один тролль. Если кому-то необходимо посмотреть на игры на Godot в Steam, существуют официальные кураторы:
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot
https://store.steampowered.com/curator/45715609-Made-with-Godot-2
А также steamdb, поиск по тегам на itch.io и т.д.
>О, кстати заебок то какой делают!
Ну делают и делают, чего бухтеть-то?
>Это ж пасфайндер в космосе.
Это не для игроков сделано, а для ролевиков:
https://en.wikipedia.org/wiki/Starfinder_Roleplaying_Game
>>7588
Теперь я официальный куратор игр на Godot в Dvach.
Одно не исключает другого, будет минимум 50к игроков. Не балдурс гейт 3, конечно, но славу годоту прибавит знатно.
Никакую, конечно. Я делаю всякие симуляции, интерактивные утилиты, аддоны водички и прочих эффектов.
Теперь я официальный куратор игр на Godot в Dvach.
>Это не для игроков сделано, а для ролевиков:
Одно не исключает другого, будет минимум 50к игроков. Не балдурс гейт 3, конечно, но славу годоту прибавит знатно.
>Вот ты какую игру делаешь?
Никакую, конечно. Я делаю всякие симуляции, интерактивные утилиты, аддоны водички и прочих эффектов.
>>7603
Хорошо, тогда пости скриншоты/видео в тред, если возможно - со ссылками на github, откуда качать. И полезнее для местных, и для тебя пиар/оценка...
У Godot какая-то своя иерархия и ты в ней никто.
Впрочем, как и большинство постеров здесь...
Если б ты реально хотел их сюда приносить, мог бы предоставить ссылку на steam/steamdb, отправить скриншоты и mp4/webm трейлеры игр, обсудить, как используется движок в игре (если знаешь) и т.д. А скидывать ссылку на чей-то посторонний летсплей посторонней игры с заблокированного в РФ ютуба, совершенно без комментариев - выглядит как спам.
Мы неоднократно обсуждали чужие игры на Godot, но начиналось обсуждение с более-менее качественного поста, а не с рандомной ссылки на какой-то летсплей.
Давайте не будем делать тред каталогом ссылок.
>Я делаю всякие симуляции, интерактивные утилиты, аддоны водички и прочих эффектов.
Хорошо, тогда пости скриншоты/видео в тред, если возможно - со ссылками на github, откуда качать. И полезнее для местных, и для тебя пиар/оценка...
>официальный
У Godot какая-то своя иерархия и ты в ней никто.
Впрочем, как и большинство постеров здесь...
>куратор игр на Godot в Dvach
Если б ты реально хотел их сюда приносить, мог бы предоставить ссылку на steam/steamdb, отправить скриншоты и mp4/webm трейлеры игр, обсудить, как используется движок в игре (если знаешь) и т.д. А скидывать ссылку на чей-то посторонний летсплей посторонней игры с заблокированного в РФ ютуба, совершенно без комментариев - выглядит как спам.
Мы неоднократно обсуждали чужие игры на Godot, но начиналось обсуждение с более-менее качественного поста, а не с рандомной ссылки на какой-то летсплей.
Давайте не будем делать тред каталогом ссылок.
Ссылки - тоже оффтоп, движкосрач и бан нахуй с массделитом. Понели все? А ютуб - спам, да еще и обход блокировок роскомнадзора, сразу в гулаг. Все, а теперь 10 постов качественного обсуждения мне написали, качественность определю лично я на глаз
>>7612
Да ладно тебе. Просто удели минуту-две, чтобы хоть подписать ссылку какой-то личной информацией. В противном случае реально похож на спам-бота, что пробегает здесь иногда с непонятной целью.
Алсо, эти:
>>7539
>>7540
Ты мог запостить ОДНИМ постом, а не двумя.
Просто высказываю своё мнение, не более того...
Да ладно тебе. Просто удели минуту-две, чтобы хоть подписать ссылку какой-то личной информацией. В противном случае реально похож на спам-бота, что пробегает здесь иногда с непонятной целью.
Алсо, эти:
>>7539
>04:03:49
>>7540
>04:13:13
Ты мог запостить ОДНИМ постом, а не двумя.
Просто высказываю своё мнение, не более того...
>>7614
Нет, я пощу это двумя постами, а не одним. Если постить это одним, то это как раз будет "каталог ссылок", а так это два поста с двумя превью разных видосов про разные игры.
Кроме того, я сначала запостил одну игру, а потом наткнулся на другую.
Нет, я пощу это двумя постами, а не одним. Если постить это одним, то это как раз будет "каталог ссылок", а так это два поста с двумя превью разных видосов про разные игры.
Кроме того, я сначала запостил одну игру, а потом наткнулся на другую.
>>7608
Не было времени нарезать под лимит, там же много часовые видосы показывающие размеры /масштаб игры. Ну потом как нибудь найду время.
Не было времени нарезать под лимит, там же много часовые видосы показывающие размеры /масштаб игры. Ну потом как нибудь найду время.
>>7616
Лол. На доске лимит в 500 постов, после чего тред приходится перекатывать, чтобы он был на видном новичкам месте. Если ты постишь много мелких, не значимых постов - ты забиваешь тред быстрее, и он быстрее теряется из виду. Умышленное забивание называется "вайпом" и может быть наказуемо.
А, я уже и забыл, что такая фича когда-то была. Уже несколько лет не отображаются превью. Да и какой смысл, если на ютубе превью - это кликбейты, не соответствующие реальности? Лучше бы красивые скриншоты из самой игры притащил, а не кликбейт.
Понимаю, вот поэтому и говорю: не нужно таскать случайные игры, на которые ты случайно наткнулся, поскольку уже давно есть списки: >>7588
Алсо, я делаю игру на Godot, но меня совершенно не волнуют другие игры на Godot; меня волнуют только похожие игры и игры в похожих жанрах, т.к. в них я, возможно, найду что-нибудь для своей игры. Т.е. я занимаюсь осмысленным поиском референсов, а не просматриваю все игры на одном движке. Зачем ты просматриваешь игры, которые тебе не интересны?
Алсо, в "сделано на Godot" нет надёжности, ведь в реальности там половина движка легко могла быть переписана заново командой разработчиков, что обыкновенному соло инди вряд ли доступно. Это как приводить Genshin в пример Unity-игры, хотя там не оригинальный движок, а переработанный форк, и обыкновенным инди он никогда не будет доступен.
>>7618
Достаточно было написать что-то вроде:
Ибо даже будь у меня доступ, я бы не стал смотреть многочасовой видос непонятно для чего (лучше уж приобрести игру и оценить локации на практике).
Масштабность игры на Godot не проблема. Проблема в организации процесса загрузки/выгрузки ресурсов; автоматизации из коробки пока нет, геймдевы либо велосипедят своё решение, либо вручную делают.
Кому интересно, ищите по "asset streaming". Это одно из основных препятствий перед большим open world. Реализовать-то возможно, но из коробки нет.
>это как раз будет "каталог ссылок"
Лол. На доске лимит в 500 постов, после чего тред приходится перекатывать, чтобы он был на видном новичкам месте. Если ты постишь много мелких, не значимых постов - ты забиваешь тред быстрее, и он быстрее теряется из виду. Умышленное забивание называется "вайпом" и может быть наказуемо.
>превью разных видосов
А, я уже и забыл, что такая фича когда-то была. Уже несколько лет не отображаются превью. Да и какой смысл, если на ютубе превью - это кликбейты, не соответствующие реальности? Лучше бы красивые скриншоты из самой игры притащил, а не кликбейт.
>потом наткнулся на другую
Понимаю, вот поэтому и говорю: не нужно таскать случайные игры, на которые ты случайно наткнулся, поскольку уже давно есть списки: >>7588
Алсо, я делаю игру на Godot, но меня совершенно не волнуют другие игры на Godot; меня волнуют только похожие игры и игры в похожих жанрах, т.к. в них я, возможно, найду что-нибудь для своей игры. Т.е. я занимаюсь осмысленным поиском референсов, а не просматриваю все игры на одном движке. Зачем ты просматриваешь игры, которые тебе не интересны?
Алсо, в "сделано на Godot" нет надёжности, ведь в реальности там половина движка легко могла быть переписана заново командой разработчиков, что обыкновенному соло инди вряд ли доступно. Это как приводить Genshin в пример Unity-игры, хотя там не оригинальный движок, а переработанный форк, и обыкновенным инди он никогда не будет доступен.
>>7618
>показывающие размеры/масштаб игры
Достаточно было написать что-то вроде:
>Посмотрите, какой огромный мир смогли сделать, сколько разных локаций, мобов и декораций!
Ибо даже будь у меня доступ, я бы не стал смотреть многочасовой видос непонятно для чего (лучше уж приобрести игру и оценить локации на практике).
Масштабность игры на Godot не проблема. Проблема в организации процесса загрузки/выгрузки ресурсов; автоматизации из коробки пока нет, геймдевы либо велосипедят своё решение, либо вручную делают.
Кому интересно, ищите по "asset streaming". Это одно из основных препятствий перед большим open world. Реализовать-то возможно, но из коробки нет.
>>7616
Лол. На доске лимит в 500 постов, после чего тред приходится перекатывать, чтобы он был на видном новичкам месте. Если ты постишь много мелких, не значимых постов - ты забиваешь тред быстрее, и он быстрее теряется из виду. Умышленное забивание называется "вайпом" и может быть наказуемо.
А, я уже и забыл, что такая фича когда-то была. Уже несколько лет не отображаются превью. Да и какой смысл, если на ютубе превью - это кликбейты, не соответствующие реальности? Лучше бы красивые скриншоты из самой игры притащил, а не кликбейт.
Понимаю, вот поэтому и говорю: не нужно таскать случайные игры, на которые ты случайно наткнулся, поскольку уже давно есть списки: >>7588
Алсо, я делаю игру на Godot, но меня совершенно не волнуют другие игры на Godot; меня волнуют только похожие игры и игры в похожих жанрах, т.к. в них я, возможно, найду что-нибудь для своей игры. Т.е. я занимаюсь осмысленным поиском референсов, а не просматриваю все игры на одном движке. Зачем ты просматриваешь игры, которые тебе не интересны?
Алсо, в "сделано на Godot" нет надёжности, ведь в реальности там половина движка легко могла быть переписана заново командой разработчиков, что обыкновенному соло инди вряд ли доступно. Это как приводить Genshin в пример Unity-игры, хотя там не оригинальный движок, а переработанный форк, и обыкновенным инди он никогда не будет доступен.
>>7618
Достаточно было написать что-то вроде:
Ибо даже будь у меня доступ, я бы не стал смотреть многочасовой видос непонятно для чего (лучше уж приобрести игру и оценить локации на практике).
Масштабность игры на Godot не проблема. Проблема в организации процесса загрузки/выгрузки ресурсов; автоматизации из коробки пока нет, геймдевы либо велосипедят своё решение, либо вручную делают.
Кому интересно, ищите по "asset streaming". Это одно из основных препятствий перед большим open world. Реализовать-то возможно, но из коробки нет.
>это как раз будет "каталог ссылок"
Лол. На доске лимит в 500 постов, после чего тред приходится перекатывать, чтобы он был на видном новичкам месте. Если ты постишь много мелких, не значимых постов - ты забиваешь тред быстрее, и он быстрее теряется из виду. Умышленное забивание называется "вайпом" и может быть наказуемо.
>превью разных видосов
А, я уже и забыл, что такая фича когда-то была. Уже несколько лет не отображаются превью. Да и какой смысл, если на ютубе превью - это кликбейты, не соответствующие реальности? Лучше бы красивые скриншоты из самой игры притащил, а не кликбейт.
>потом наткнулся на другую
Понимаю, вот поэтому и говорю: не нужно таскать случайные игры, на которые ты случайно наткнулся, поскольку уже давно есть списки: >>7588
Алсо, я делаю игру на Godot, но меня совершенно не волнуют другие игры на Godot; меня волнуют только похожие игры и игры в похожих жанрах, т.к. в них я, возможно, найду что-нибудь для своей игры. Т.е. я занимаюсь осмысленным поиском референсов, а не просматриваю все игры на одном движке. Зачем ты просматриваешь игры, которые тебе не интересны?
Алсо, в "сделано на Godot" нет надёжности, ведь в реальности там половина движка легко могла быть переписана заново командой разработчиков, что обыкновенному соло инди вряд ли доступно. Это как приводить Genshin в пример Unity-игры, хотя там не оригинальный движок, а переработанный форк, и обыкновенным инди он никогда не будет доступен.
>>7618
>показывающие размеры/масштаб игры
Достаточно было написать что-то вроде:
>Посмотрите, какой огромный мир смогли сделать, сколько разных локаций, мобов и декораций!
Ибо даже будь у меня доступ, я бы не стал смотреть многочасовой видос непонятно для чего (лучше уж приобрести игру и оценить локации на практике).
Масштабность игры на Godot не проблема. Проблема в организации процесса загрузки/выгрузки ресурсов; автоматизации из коробки пока нет, геймдевы либо велосипедят своё решение, либо вручную делают.
Кому интересно, ищите по "asset streaming". Это одно из основных препятствий перед большим open world. Реализовать-то возможно, но из коробки нет.
>>7620
Ты анон, пустота, буквоки, мне твое мнение не интересно, я сам разберусь что и как делать тут.
Ты анон, пустота, буквоки, мне твое мнение не интересно, я сам разберусь что и как делать тут.
>>7649
Да, было время, я тогда как раз сюда пришел, после видосов Распа в бэ, думал во клево, сейчас что-то тоже сделаю, пошел на твг поучаствовать, а там просто затравили просто за то что игра на годоте, так что теперь мои игры в других местах.
Да, было время, я тогда как раз сюда пришел, после видосов Распа в бэ, думал во клево, сейчас что-то тоже сделаю, пошел на твг поучаствовать, а там просто затравили просто за то что игра на годоте, так что теперь мои игры в других местах.
Раньше реально было лучше, самый живой, интересный и обсуждающий тред в гд, на практически любые окологодотовые темы. Потом высрался этот мегадушнила со своими портянками и принялся свои порядки наводить, репортя все, что ему не нравится, даже если это напрямую связано с движком и он этого не понял.
>>7653
Я его просто как ллмку воспринимаю, но пишет он конечно складно и логично, впрочем от ошибок его это не страхует.
Я его просто как ллмку воспринимаю, но пишет он конечно складно и логично, впрочем от ошибок его это не страхует.
В тему компиляции шейдеров: >>7547
Это написано в системных требованиях в Steam:
https://store.steampowered.com/app/3245640/
>>7653
Вот не надо смешивать всех в одну кучу... Зачем расписывать длинный подробный ответ тому, кого зарепортил? Ответ получают лишь достойные его.
Тут у некоторых анонов странная тенденция всех смешивать в одну личность. На доске около сотни посетителей в месяц, может, даже больше. Не нужно списывать "репорты" на кого-то одного, и не нужно воспринимать ответы как от одного человека.
Здесь не принято писать "я другой анон", так что в некоторых случаях обсуждение продолжают совсем другие люди, чем те, кто его начал. Если кто-то тут запутывается, это не проблема обсуждающих...
>Framerate might drop, specially the first run due shader compilation.
Это написано в системных требованиях в Steam:
https://store.steampowered.com/app/3245640/
>>7653
>мегадушнила со своими портянками
>репортя все, что ему не нравится
Вот не надо смешивать всех в одну кучу... Зачем расписывать длинный подробный ответ тому, кого зарепортил? Ответ получают лишь достойные его.
Тут у некоторых анонов странная тенденция всех смешивать в одну личность. На доске около сотни посетителей в месяц, может, даже больше. Не нужно списывать "репорты" на кого-то одного, и не нужно воспринимать ответы как от одного человека.
Здесь не принято писать "я другой анон", так что в некоторых случаях обсуждение продолжают совсем другие люди, чем те, кто его начал. Если кто-то тут запутывается, это не проблема обсуждающих...
>>7653
Пиши в движкосраче. Там большие эксперты по годоту, чем здесь. Каждую косточку движка перемыли, есть все ответы на любые вопросы, даже на те, которые еще не придумал задавать.
Пиши в движкосраче. Там большие эксперты по годоту, чем здесь. Каждую косточку движка перемыли, есть все ответы на любые вопросы, даже на те, которые еще не придумал задавать.
Анончики, я пришёл поделиться откровением у холодильника.
Давненько не делал игорь и Годот не запускал. Щас пишу приложение на плюсах. И поймал себя на том, что постепенно получается Годот-подобное дерево. У меня уже есть универсальный объект, который умеет эмитить сигналы, а ещё call_deferred. В приложении есть два главных цикла: графика и логика. И вот для реализации этого самого деферред уже прям руки чешутся сделать полноценное дерево, чтоб были родители и дети, чтобы оно могло в строгом порядке проходить по всем объектам для выполнения основного цикла или отложенных вызовов.
Кароч что я хочу сказать. Годот классно сделан чисто с точки зрения архитектуры. Скучаю по тем временам, когда делал игры, вооот.
Кстати, как вы тут, потомки?
Давненько не делал игорь и Годот не запускал. Щас пишу приложение на плюсах. И поймал себя на том, что постепенно получается Годот-подобное дерево. У меня уже есть универсальный объект, который умеет эмитить сигналы, а ещё call_deferred. В приложении есть два главных цикла: графика и логика. И вот для реализации этого самого деферред уже прям руки чешутся сделать полноценное дерево, чтоб были родители и дети, чтобы оно могло в строгом порядке проходить по всем объектам для выполнения основного цикла или отложенных вызовов.
Кароч что я хочу сказать. Годот классно сделан чисто с точки зрения архитектуры. Скучаю по тем временам, когда делал игры, вооот.
Кстати, как вы тут, потомки?
65 Кб, 306x348>>7713
У меня в голове та самая музыка заиграла.
У меня в голове та самая музыка заиграла.
1,1 Мб, 1280x720Release candidate: Godot 4.6.3 RC 1
https://godotengine.org/article/release-candidate-godot-4-6-3-rc-1/
На шаг ближе к стабильному 4.6. Любопытно, будет ли 4.6.4?
https://godotengine.org/article/release-candidate-godot-4-6-3-rc-1/
На шаг ближе к стабильному 4.6. Любопытно, будет ли 4.6.4?
>>7709
Ты там что, велосипед с нуля изобретаешь? Почему не используешь что-нибудь наподобие C++Builder, где уже сделано всё, что нужно, и остаётся только соединить кнопочки на форме с твоей логикой через сигналы? И зачем тебе именно C++, а не C#/Java или Free Pascal?
Архитектура Godot хороша, но не уникальна. Мне она нравится в основном тем, что нет ничего лишнего, и основные фичи имеют поддержку разрабов движка. Остальные движки часто придумывают лишнее, не поддерживая старое, и это очень неудобно...
А почему бросил делать игры? Какое теперь хобби?
>>7719
Вообще без разницы, я давно перекатился на 4.7.
Ты там что, велосипед с нуля изобретаешь? Почему не используешь что-нибудь наподобие C++Builder, где уже сделано всё, что нужно, и остаётся только соединить кнопочки на форме с твоей логикой через сигналы? И зачем тебе именно C++, а не C#/Java или Free Pascal?
Архитектура Godot хороша, но не уникальна. Мне она нравится в основном тем, что нет ничего лишнего, и основные фичи имеют поддержку разрабов движка. Остальные движки часто придумывают лишнее, не поддерживая старое, и это очень неудобно...
А почему бросил делать игры? Какое теперь хобби?
>>7719
>Любопытно, будет ли 4.6.4?
Вообще без разницы, я давно перекатился на 4.7.
>>7719
Это оффтоп, спам или провокация движкосрача?
Это оффтоп, спам или провокация движкосрача?
>>7709
А вообще, не лучше ли взять тот же Godot, вырезать ненужные модули (физику, 3D рендер, GDScript и т.д.), используя оставшееся как фундамент для твоего приложения на C++? Ты же, как я понял, изобретаешь собственный UI, а не используешь готовый с готовой иерархией и сигналами. Так почему не взять Godot в качестве основы? Слишком сложно будет?
Я лично давно забил на создание приложений, т.к. всё, что может быть мне или кому-либо нужно, давно уже кем-то сделано. Нет смысла что-то изобретать. А для простого чего-нибудь нет смысла копаться в потрохах C++, можно прямо на GDScript в Godot слепить утилиту сразу с GUI. Жирновато по ресурсам, конечно, но не хуже Electron, лол.
>прям руки чешутся сделать полноценное дерево
А вообще, не лучше ли взять тот же Godot, вырезать ненужные модули (физику, 3D рендер, GDScript и т.д.), используя оставшееся как фундамент для твоего приложения на C++? Ты же, как я понял, изобретаешь собственный UI, а не используешь готовый с готовой иерархией и сигналами. Так почему не взять Godot в качестве основы? Слишком сложно будет?
Я лично давно забил на создание приложений, т.к. всё, что может быть мне или кому-либо нужно, давно уже кем-то сделано. Нет смысла что-то изобретать. А для простого чего-нибудь нет смысла копаться в потрохах C++, можно прямо на GDScript в Godot слепить утилиту сразу с GUI. Жирновато по ресурсам, конечно, но не хуже Electron, лол.
>>7726
Выглядит круто, но, похоже, очень трудно сделать.
>>7729 (Del)
Тебя за дело потёрли. Будь добрее к окружающим.
В которых немотивированная агрессия к движку?
Ты сам себе врагов придумал и злишься теперь...
Выглядит круто, но, похоже, очень трудно сделать.
>>7729 (Del)
Тебя за дело потёрли. Будь добрее к окружающим.
>тематические посты
В которых немотивированная агрессия к движку?
>пятнадцатилетний нарцисс
Ты сам себе врагов придумал и злишься теперь...
Годотеры, накиньте ресурсов где можно найти работающих за деньги РУССКИХ художиков 2д (нужны для концептов) и 3Д нужны для разработки моделей.
>>7739
Хуй его знает, слишком маленький рынок. Я пару раз вгеном пользовался и просто через соцсети рисовак на коммишенны находил, но это все не ру.
Хуй его знает, слишком маленький рынок. Я пару раз вгеном пользовался и просто через соцсети рисовак на коммишенны находил, но это все не ру.
>>7739
Почему именно русских? Чтоб подешевле было? С переводчиком можешь хоть у японцев заказывать.
Сильно сомневаюсь, что что-то поменялось за последние годы. Фриланс биржи всё те же, геймдев форумы всё те же. Поищи в Яндексе и найдёшь кучу.
>>7741
Художников много. Просто многие совсем не шарят в геймдеве, а рисуя всякие портреты и пейзажи.
Только, мне кажется, для концепт-арта сейчас уже используются нейронки, как раз за счёт того, что они способны накидать много вариантов одной сцены практически бесплатно и очень быстро. Показывать концепты игрокам ты всё равно вряд ли будешь, и поэтому качество арта тебя не должно волновать...
>РУССКИХ художиков
Почему именно русских? Чтоб подешевле было? С переводчиком можешь хоть у японцев заказывать.
Сильно сомневаюсь, что что-то поменялось за последние годы. Фриланс биржи всё те же, геймдев форумы всё те же. Поищи в Яндексе и найдёшь кучу.
>>7741
>слишком маленький рынок
Художников много. Просто многие совсем не шарят в геймдеве, а рисуя всякие портреты и пейзажи.
Только, мне кажется, для концепт-арта сейчас уже используются нейронки, как раз за счёт того, что они способны накидать много вариантов одной сцены практически бесплатно и очень быстро. Показывать концепты игрокам ты всё равно вряд ли будешь, и поэтому качество арта тебя не должно волновать...
>>7742
Потому что хочу поддержать отечественных художников,
Я предполагаю что заграничные макаки мне будут рисовать за меньший прайс
Я не знаю ничего такого ориентированного на рф (т.к. рыночек мёртв, но всё же)
> именно русских
Потому что хочу поддержать отечественных художников,
> Чтоб подешевле было?
Я предполагаю что заграничные макаки мне будут рисовать за меньший прайс
> Фриланс биржи всё те же, геймдев форумы всё те же
Я не знаю ничего такого ориентированного на рф (т.к. рыночек мёртв, но всё же)
>>7744
В каком смысле? Основные биржи не поменялись:
https://vc.ru/services/2309839-reyting-luchshikh-birzh-frilansa-v-rossii
Конкретно по геймдеву я знаю только такое:
https://gamedev.ru/job/forum/
Можешь попробовать написать в >>1079309 (OP)
Если только из Индии. Всё остальное - дороже.
>>7748 (Del)
Да не так и сложно, но уже вернули обратно, лол.
>>7753 (Del)
Разве кто-то обещал, что они "исправят ситуацию"?
>Я не знаю ничего такого ориентированного на рф
В каком смысле? Основные биржи не поменялись:
https://vc.ru/services/2309839-reyting-luchshikh-birzh-frilansa-v-rossii
Конкретно по геймдеву я знаю только такое:
https://gamedev.ru/job/forum/
Можешь попробовать написать в >>1079309 (OP)
>заграничные будут рисовать за меньший прайс
Если только из Индии. Всё остальное - дороже.
>>7748 (Del)
>ухудшили капчу, стало невозможно писать
Да не так и сложно, но уже вернули обратно, лол.
>>7753 (Del)
>якобы в /d кто то разбирается и исправит ситуацию
Разве кто-то обещал, что они "исправят ситуацию"?
>>7744
Мне вот тоже интересно было бы найти именно русских, но исключительно потому, что зарубежным хуй деньги отправишь, мы ж под железным занавесом литералли.
С другой стороны нахуя их вообще искать, если игру не толкнуть дальше мертвого вк плей и яндекса. Ну это конечно больше мои проблемы, тут есть и крутые с внж в снг или с женами казашками.
Мне вот тоже интересно было бы найти именно русских, но исключительно потому, что зарубежным хуй деньги отправишь, мы ж под железным занавесом литералли.
С другой стороны нахуя их вообще искать, если игру не толкнуть дальше мертвого вк плей и яндекса. Ну это конечно больше мои проблемы, тут есть и крутые с внж в снг или с женами казашками.
>>7990 (Del)
Ну, как сказать. Саня - это Вася на стероидах, которая в свою очередь Трёха на стероидах. В том смысле, что Саню не с нуля собирали, а была база из предыдущих двух игр.
Хотя, с третьей стороны сейчас всё настолько упростилось, что да. 20 лет прошло как никак
Ну, как сказать. Саня - это Вася на стероидах, которая в свою очередь Трёха на стероидах. В том смысле, что Саню не с нуля собирали, а была база из предыдущих двух игр.
Хотя, с третьей стороны сейчас всё настолько упростилось, что да. 20 лет прошло как никак
>>8004 (Del)
По каким параметрам ты определил что дорога на восток легче халвы 1 (1998)?
Лучше бы к экзаменам готовился.
По каким параметрам ты определил что дорога на восток легче халвы 1 (1998)?
Лучше бы к экзаменам готовился.
>>8004 (Del)
так я специально примеры игр в тред выше кидал
так я специально примеры игр в тред выше кидал
204 Кб, 1022x1024Не ведитесь на лоу эффорт байты:
>>7913
>>7914 (Del)
>>7986 (Del)
>>8004 (Del)
Он специально провоцирует срач. Потом он где-то обосрётся и его потрут везде, а ваши посты здесь останутся, и он будет писать, что это мы виноваты.
Просто игнорируйте такое.
>>7913
>>7914 (Del)
>>7986 (Del)
>>8004 (Del)
Он специально провоцирует срач. Потом он где-то обосрётся и его потрут везде, а ваши посты здесь останутся, и он будет писать, что это мы виноваты.
Просто игнорируйте такое.
>>7986 (Del)
Понятно что вброс, но отвечу. На гитхабе правда есть сорцы попытки в гта, но я даже не открывал их.
Понятно что вброс, но отвечу. На гитхабе правда есть сорцы попытки в гта, но я даже не открывал их.
>>8033 (Del)
ну да, прикольно, я смотрю у того же типа как то что я хотел еще и 3D прицел без привязки к камере, а в конце по скриншоту видно что планировал сделать рпг, с прокачкой скиллов и т.д https://m.youtube.com/watch?v=CCmZntAjYhQ
ну да, прикольно, я смотрю у того же типа как то что я хотел еще и 3D прицел без привязки к камере, а в конце по скриншоту видно что планировал сделать рпг, с прокачкой скиллов и т.д https://m.youtube.com/watch?v=CCmZntAjYhQ
>>8062
Ковыряй
https://github.com/FOSS-Supremacy/OpenLiberty
Я бы сделал ставку на 2Д опенворд-рпг, в стиле боевки и окружения stoneshard (потому что все остальные реалтайм боевки в 2Д для мрачного средневековья выглядят "по детски").
По объему работ это как-минимум достижимо для одного человека. Начни просто с роликов/туториалов top down rpg
Ковыряй
https://github.com/FOSS-Supremacy/OpenLiberty
Я бы сделал ставку на 2Д опенворд-рпг, в стиле боевки и окружения stoneshard (потому что все остальные реалтайм боевки в 2Д для мрачного средневековья выглядят "по детски").
По объему работ это как-минимум достижимо для одного человека. Начни просто с роликов/туториалов top down rpg
>>8062
Попробуй начать с клона GTA 1/2 и старых 2D JRPG.
Тебе нужен туториал на "top down rpg/racing" игры.
Для создания 3D GTA нужно очень много времени и ресурсов, никак не связанных с игровым движком. Аналогично со Skyrim. Ты задолбаешься делать 3D модельки с фототекстурами, потом задолбаешься с анимациями, а как дело дойдёт до звука и музыки - обосрёшься, высрав никому не нужный нейрослоп. Движковые нюансы тут совершенно не важны.
>реально туториал ищу
Попробуй начать с клона GTA 1/2 и старых 2D JRPG.
Тебе нужен туториал на "top down rpg/racing" игры.
Для создания 3D GTA нужно очень много времени и ресурсов, никак не связанных с игровым движком. Аналогично со Skyrim. Ты задолбаешься делать 3D модельки с фототекстурами, потом задолбаешься с анимациями, а как дело дойдёт до звука и музыки - обосрёшься, высрав никому не нужный нейрослоп. Движковые нюансы тут совершенно не важны.
3,1 Мб, mp4,948x708, 0:21
>>8079 (Del)
Не все еще с бана вышли.
Я бы перекатил со скринами доставщицы, но мне лень даже стебаться.
Не все еще с бана вышли.
Я бы перекатил со скринами доставщицы, но мне лень даже стебаться.
211 Кб, 400x600>>8079 (Del)
Да.
>>8080
Тред сделал своё дело. Пусть тонет. Теперь Годотом займутся ребята покруче нас. А мы можем отдохнуть и расслабиться в срачетреде.
мимо ОП тредов со второго по 50й
Да.
>>8080
Тред сделал своё дело. Пусть тонет. Теперь Годотом займутся ребята покруче нас. А мы можем отдохнуть и расслабиться в срачетреде.
мимо ОП тредов со второго по 50й
>>8079 (Del)
Зачем? Проще тут еще 250 постов снести.
Зачем? Проще тут еще 250 постов снести.
>>8067
>>8072
ну вот недавно играл в старую игру от создателей HoMM 5 - Ночной Дозор. Современный сеттинг, пошаговая CRPG боевка. Вроде 3D, но вот как то совсем не удобно, и душно. Хотелось бы привязать камеру к персонажу и двигаться с WASD. Но тогда нужно делать реал-тайм боевку. Хотя интересно возможно ли сделать пошаговую боевку с камерой через плечо, т.е. как тот же скайрим но представь что боевка пошаговая. Т.е. начался бой - можно пройти там 10 метров, стрельнуть пару раз, и дальше очередь нпс. Оригинально же.
https://youtu.be/uUCIY1BBhxk?si=T-uo6G2YNC1Tbx-8
>>8072
ну вот недавно играл в старую игру от создателей HoMM 5 - Ночной Дозор. Современный сеттинг, пошаговая CRPG боевка. Вроде 3D, но вот как то совсем не удобно, и душно. Хотелось бы привязать камеру к персонажу и двигаться с WASD. Но тогда нужно делать реал-тайм боевку. Хотя интересно возможно ли сделать пошаговую боевку с камерой через плечо, т.е. как тот же скайрим но представь что боевка пошаговая. Т.е. начался бой - можно пройти там 10 метров, стрельнуть пару раз, и дальше очередь нпс. Оригинально же.
https://youtu.be/uUCIY1BBhxk?si=T-uo6G2YNC1Tbx-8
>>8084
У героев дизайн - он привлекателен ностальгирующим скуфам. В реале он ужасен и надоедает почти сразу (а я ностальгирующий скуф) - вся тактика однообразна.
Если ты сможешь решить проблему - чтобы пошаговый бой не был бы одинаковым и унылым (не зудило бы его скипнуть) - у тебя бы вышла идеальная рпг.
Но у героев есть этот момент исследования мира, там юзеры десятки тысяч карт создали для себя. Вот этот момент надо эксплуатировать.
Я бы больше написал, тонна изысканий на эту тему, но увы потрут.
Сделать хорошую 2Д рпг можно, не хуже 3Д будет цеплять. Главное не начинай с процедурных миров и данжей, это понадобиться потом, будешь все равно переделывать несколько раз.
У героев дизайн - он привлекателен ностальгирующим скуфам. В реале он ужасен и надоедает почти сразу (а я ностальгирующий скуф) - вся тактика однообразна.
Если ты сможешь решить проблему - чтобы пошаговый бой не был бы одинаковым и унылым (не зудило бы его скипнуть) - у тебя бы вышла идеальная рпг.
Но у героев есть этот момент исследования мира, там юзеры десятки тысяч карт создали для себя. Вот этот момент надо эксплуатировать.
Я бы больше написал, тонна изысканий на эту тему, но увы потрут.
Сделать хорошую 2Д рпг можно, не хуже 3Д будет цеплять. Главное не начинай с процедурных миров и данжей, это понадобиться потом, будешь все равно переделывать несколько раз.
сап гадач. первая моя игра, прошу оценить анонов.
уровни полностью процедурно генерируемые, хотя надо доработать обязательно генератор, в целом работает уже недурно лично для меня.
типов врагов больше чем показано тут, просто бежать до 20-го уровня не хочется (да и тяжко, не додумался сделать норм средство для тестирования всех уровней :) ), помимо воинов лучников и защитников есть ещё маги и призыватели, по классике хуле.
также из непоказанного есть и работает система торговли и зачарований (не улучшений).
в общем и целом работать над игрой все больше и больше тяжелее так как всё зарастает и обрастает кодом, и новые фишки имплементируются с каждым разом всё медленнее, а баги отлавливать становится сложнее, но надеюсь что в этом году выпущу, хотя на данный момент даже звуков в игре нету.
(текст если что более чем читаемый, это сжатие мп4 поебало так сильно шрифты)
уровни полностью процедурно генерируемые, хотя надо доработать обязательно генератор, в целом работает уже недурно лично для меня.
типов врагов больше чем показано тут, просто бежать до 20-го уровня не хочется (да и тяжко, не додумался сделать норм средство для тестирования всех уровней :) ), помимо воинов лучников и защитников есть ещё маги и призыватели, по классике хуле.
также из непоказанного есть и работает система торговли и зачарований (не улучшений).
в общем и целом работать над игрой все больше и больше тяжелее так как всё зарастает и обрастает кодом, и новые фишки имплементируются с каждым разом всё медленнее, а баги отлавливать становится сложнее, но надеюсь что в этом году выпущу, хотя на данный момент даже звуков в игре нету.
(текст если что более чем читаемый, это сжатие мп4 поебало так сильно шрифты)
128 Кб, 484x292>>8091
>в общем и целом работать над игрой все больше и больше тяжелее так как всё зарастает и обрастает кодом, и новые фишки имплементируются с каждым разом всё медленнее, а баги отлавливать становится сложнее, но надеюсь что в этом году выпущу, хотя на данный момент даже звуков в игре нету.
>>8094
я не совсем это имел в виду друже). все (буквально) механики в игре готовы, сейчас вопрос только в звуках, музыке, и локализации по сути стоит, и отлову мелких косметических багах и балансу. это было сказано скорее к тому, что если захотеть добавить что-то что должно быть связано с несколькими системами или скриптами - будет сложновато.
да и игру я делаю не две недели, а без малого - год, и это повторюсь первый мой опыт
я не совсем это имел в виду друже). все (буквально) механики в игре готовы, сейчас вопрос только в звуках, музыке, и локализации по сути стоит, и отлову мелких косметических багах и балансу. это было сказано скорее к тому, что если захотеть добавить что-то что должно быть связано с несколькими системами или скриптами - будет сложновато.
да и игру я делаю не две недели, а без малого - год, и это повторюсь первый мой опыт
>>8091
Главное было не лень добавлять описание к репчатому луку.
Вообще, очень хорошо. Сделай боевку динамичнее, взмах оружия чтобы был таким быстрым сплешем с приятным звуком, а не кручение спрайта.
Боевка это то чем игрок будет заниматься большую часть времени - сделай её приятнее.
Уровни пустые, то что они процедурные, не делает их интереснее. Делай красивые комнаты и уже из комнат собирай данжи.
Главное было не лень добавлять описание к репчатому луку.
Вообще, очень хорошо. Сделай боевку динамичнее, взмах оружия чтобы был таким быстрым сплешем с приятным звуком, а не кручение спрайта.
Боевка это то чем игрок будет заниматься большую часть времени - сделай её приятнее.
Уровни пустые, то что они процедурные, не делает их интереснее. Делай красивые комнаты и уже из комнат собирай данжи.
>>8097
префабы будут, да, просто я их буду делать под конец так как для тестирования это вообще не особо роляет, и вид генерации изменится. т.е. в скрипте уже есть система префабов которая миксует сгенерированные комнаты с префабами, и по типам они разбиты и по назначению. просто самих префабов пока не хватает чтобы из них прям делать уровень полностью.
вот с боевкой сам понимаю что есть проблемы, не совсем понимаю как её ещё сильнее сделать лучше и динамичнее. если только добавлять блятские перевороты/стрейфы и кучу визуальных эффектов, в т.ч. для каждого из врагов.
кручение спрайта мне кажется единственный возможный вариант, просто можно поиграться с интерполяцией этого кручения и скоростью, ибо рисовать для каждого оружия отдельный спрайтщит с анимацией это будет пздец учитывая что в игре на данный момент около 60 единиц различного оружия :)
но прислушаюсь, может чего получится.
префабы будут, да, просто я их буду делать под конец так как для тестирования это вообще не особо роляет, и вид генерации изменится. т.е. в скрипте уже есть система префабов которая миксует сгенерированные комнаты с префабами, и по типам они разбиты и по назначению. просто самих префабов пока не хватает чтобы из них прям делать уровень полностью.
вот с боевкой сам понимаю что есть проблемы, не совсем понимаю как её ещё сильнее сделать лучше и динамичнее. если только добавлять блятские перевороты/стрейфы и кучу визуальных эффектов, в т.ч. для каждого из врагов.
кручение спрайта мне кажется единственный возможный вариант, просто можно поиграться с интерполяцией этого кручения и скоростью, ибо рисовать для каждого оружия отдельный спрайтщит с анимацией это будет пздец учитывая что в игре на данный момент около 60 единиц различного оружия :)
но прислушаюсь, может чего получится.
>>8100
У меня немного другой стиль, персонаж держит оружие, но не машет им, вместо этого есть анимации для разных типов оружия. Типа меч - такой белый полукруг сплеш, копье такой сплеш конуса итд. Если крит то гига красный сплеш (вместо тряски экрана).
В идеале бы делать это вместо с оружием (пик2), но у меня сильное заимствование со стоуншарда, там упор не в красоту.
>момент около 60 единиц различного оружия
У меня немного другой стиль, персонаж держит оружие, но не машет им, вместо этого есть анимации для разных типов оружия. Типа меч - такой белый полукруг сплеш, копье такой сплеш конуса итд. Если крит то гига красный сплеш (вместо тряски экрана).
В идеале бы делать это вместо с оружием (пик2), но у меня сильное заимствование со стоуншарда, там упор не в красоту.
2 Кб, 66x32>>8091
Первое что бросилось в глаза: При реализованной работе с тенями, с претензией на игровой стиль, типа как в олдовых данженкровлерах, сам персонаж не отбрасывает тень, гуляя около костра.
Первое что бросилось в глаза: При реализованной работе с тенями, с претензией на игровой стиль, типа как в олдовых данженкровлерах, сам персонаж не отбрасывает тень, гуляя около костра.
1,2 Мб, mp4,406x374, 0:12
>>8104
персонаж ОТБРАСЫВАЕТ тень от костра, просто возможно (не пересматривал запись) в этот момент у игрока был активен факел в руках - в этот момент игрок не отбрасывает тень, да.
единственное - за игроком тень не отбрасывается, т.е. только если игрок НИЖЕ источника света будет тень (ибо она немного ломает логику скрипта и за спрайтом игрока тень особо не видно - да и для оптимизона неплохо)
персонаж ОТБРАСЫВАЕТ тень от костра, просто возможно (не пересматривал запись) в этот момент у игрока был активен факел в руках - в этот момент игрок не отбрасывает тень, да.
единственное - за игроком тень не отбрасывается, т.е. только если игрок НИЖЕ источника света будет тень (ибо она немного ломает логику скрипта и за спрайтом игрока тень особо не видно - да и для оптимизона неплохо)
>>8101
видишь, просто я бы хотел чтобы визуально было видно смену оружия, поэтому и сделал так.
а так в любом случае пришлось бы делать несколько таких анимаций - ибо у меня несколько ТИПОВ оружия - мечи, топоры, ножи, булавы, двуручные мечи, двуручные топоры, двуручные молоты, копья, посохи и так далее. и для каждого из типа нужно было бы свою анимку рисовать, ибо есть например топоры с лезвием с одной стороны - а есть двухсторонние, т.е. лабриссы, и там например тоже уже другая анимка нужна.
поэтому вот такой костылик. но учту твои слова в любом случае, спасибо.
(и разрешение в игре - 16 пикселей у тайлов, там особо не разгуляешься в красоте спрайтов)
видишь, просто я бы хотел чтобы визуально было видно смену оружия, поэтому и сделал так.
а так в любом случае пришлось бы делать несколько таких анимаций - ибо у меня несколько ТИПОВ оружия - мечи, топоры, ножи, булавы, двуручные мечи, двуручные топоры, двуручные молоты, копья, посохи и так далее. и для каждого из типа нужно было бы свою анимку рисовать, ибо есть например топоры с лезвием с одной стороны - а есть двухсторонние, т.е. лабриссы, и там например тоже уже другая анимка нужна.
поэтому вот такой костылик. но учту твои слова в любом случае, спасибо.
(и разрешение в игре - 16 пикселей у тайлов, там особо не разгуляешься в красоте спрайтов)
>>8091
Помню твои предыдущие отчёты. Молодец.
А как ты систему света и тени сделал? С помощью встроенных Light2D или это твой личный шейдер? Я пытался сделать похожие тени в прошлом и не смог.
>>8097
Согласен, анимация выглядит как-то вяло.
>>8122
Он говорит об анимации через AnimationPlayer, а не покадровой перерисовке каждого оружия заново.
Делаешь одну анимацию в AnimationPlayer на каждую отдельную категорию оружия. Тебе не нужно спрайты перерисовать, но анимация должна быть сочной.
Помню твои предыдущие отчёты. Молодец.
А как ты систему света и тени сделал? С помощью встроенных Light2D или это твой личный шейдер? Я пытался сделать похожие тени в прошлом и не смог.
>>8097
>взмах оружия чтобы был таким быстрым сплешем с приятным звуком, а не кручение спрайта
Согласен, анимация выглядит как-то вяло.
>>8122
>разрешение в игре - 16 пикселей у тайлов, там особо не разгуляешься в красоте спрайтов
Он говорит об анимации через AnimationPlayer, а не покадровой перерисовке каждого оружия заново.
>в любом случае пришлось бы делать несколько таких анимаций - ибо у меня несколько ТИПОВ
Делаешь одну анимацию в AnimationPlayer на каждую отдельную категорию оружия. Тебе не нужно спрайты перерисовать, но анимация должна быть сочной.
>>8119
а почему именно на такую версию залочил ? есть какие то подводные камни что бы не ставить актуальный билд ?
а почему именно на такую версию залочил ? есть какие то подводные камни что бы не ставить актуальный билд ?
>>8117 (Del)
Легко.
Легко.
>>8122
В том и дело ты делаешь анимации к типам оружия, а не к каждому оружию (у мечей свое, у кинжалов свое итд).
Там еще по цвету сплеша зачарку видно (и когда она кончилась). Например было оранжевая (огонь), потом стала белая - значит кончилась зачарка (да, механика со скайрима).
В целом можешь анимации сколько угодно завести, главное чтобы чувствовался удар.
Оружие видно в руках (тебе надо будет удлинять спрайт героя), когда проходит анимация я еще двигаю персов. В общем, это кажется живее, просто поэкспериментируй.
пики со стоуншарда, они там тоже не махают оружием, просто держат
>а так в любом случае пришлось бы делать несколько таких анимаций
В том и дело ты делаешь анимации к типам оружия, а не к каждому оружию (у мечей свое, у кинжалов свое итд).
Там еще по цвету сплеша зачарку видно (и когда она кончилась). Например было оранжевая (огонь), потом стала белая - значит кончилась зачарка (да, механика со скайрима).
В целом можешь анимации сколько угодно завести, главное чтобы чувствовался удар.
>видишь, просто я бы хотел чтобы визуально было видно смену оружия, поэтому и сделал так.
Оружие видно в руках (тебе надо будет удлинять спрайт героя), когда проходит анимация я еще двигаю персов. В общем, это кажется живее, просто поэкспериментируй.
пики со стоуншарда, они там тоже не махают оружием, просто держат
>>8117 (Del)
На годоте можно делать любые игры, это универсальный движок.
На годоте можно делать любые игры, это универсальный движок.
>>8117 (Del)
Не знаю, что ты там под словесными играми подразумеваешь, но вот тебе "о счастливчик", 5 секунд в утке с клавдией:
Не знаю, что ты там под словесными играми подразумеваешь, но вот тебе "о счастливчик", 5 секунд в утке с клавдией:
>>8118
О, ну тогда всё ништяк, малаца!
О, ну тогда всё ништяк, малаца!
>>8125
с помощью встроенных оно работает кривее некуда, и только для статичных кое как. но там надо ебстись с окклюдерами и прочим, поэтому я шейдер написал, который копирует альфа канал спрайта (включая кадры анимации) и делает черным, накинул градиент прозрачности, и повернул. собственно всё.
насчет анимации повторюсь, я пытался это сделать, пытался нарисовать, но мне результат честно не понравился.
с помощью встроенных оно работает кривее некуда, и только для статичных кое как. но там надо ебстись с окклюдерами и прочим, поэтому я шейдер написал, который копирует альфа канал спрайта (включая кадры анимации) и делает черным, накинул градиент прозрачности, и повернул. собственно всё.
насчет анимации повторюсь, я пытался это сделать, пытался нарисовать, но мне результат честно не понравился.
>>8128
в стоуншард играл да, в целом и хотел сделать нечто похожее - но гораздо проще (не в плане сложности а в плане освоения) и реалтаймовое.
удлинять спрайты эт уже поздно - просто потому что вся броня, шлемы, щиты да и размер врагов - всё подстраивалось под этот размер. удлинять перса, значит по сути перерисовывать вообще всё - в том числе стены и окружение т.к. игрок будет просто напросто выше чем стены епта.
в стоуншард играл да, в целом и хотел сделать нечто похожее - но гораздо проще (не в плане сложности а в плане освоения) и реалтаймовое.
удлинять спрайты эт уже поздно - просто потому что вся броня, шлемы, щиты да и размер врагов - всё подстраивалось под этот размер. удлинять перса, значит по сути перерисовывать вообще всё - в том числе стены и окружение т.к. игрок будет просто напросто выше чем стены епта.
594 Кб, 1927x1051вообще был вопрос скорее в том - по вашему мнению друзья аноны - есть шанс на этой игре заработать деняк? если естественно довести её до ума.
думаю релизнуть ранний доступ, и с первой копеечки уволиться с раб оты и за быстрый срок доделать и наполнить контентом до конца (идеи по наполнению после 1.0 версии есть). но честно говоря понимания где как и что лучше - нет. сначала вообще думал на итч закидывать бля
просто сейчас хз дизморалит будто, как будто всё это зря а я хуйню полную сделал. делаю не ради денег, деньги нужны скорее исключительно чтобы я мог выкладываться в этом деле на полную, и нужен хотя бы прожиточный минимум епта.
думаю релизнуть ранний доступ, и с первой копеечки уволиться с раб оты и за быстрый срок доделать и наполнить контентом до конца (идеи по наполнению после 1.0 версии есть). но честно говоря понимания где как и что лучше - нет. сначала вообще думал на итч закидывать бля
просто сейчас хз дизморалит будто, как будто всё это зря а я хуйню полную сделал. делаю не ради денег, деньги нужны скорее исключительно чтобы я мог выкладываться в этом деле на полную, и нужен хотя бы прожиточный минимум епта.
>>8135
а, сяб бро !
а, сяб бро !
>>8133
Если дело к концу, тогда да. Но даже не меняя, мне думается можно что-то еще сделать с боевкой.
Честно говоря, стены я подумал это плейсхолдер.
>>8134
Хз насколько игра глубока по геймплею, но по видосам кажется весьма поверхностной и пустой. Но у стоуншарда вообще вроде сначала был пролог и пустой мир.
>значит по сути перерисовывать вообще всё
Если дело к концу, тогда да. Но даже не меняя, мне думается можно что-то еще сделать с боевкой.
Честно говоря, стены я подумал это плейсхолдер.
>>8134
>есть шанс на этой игре заработать деняк
Хз насколько игра глубока по геймплею, но по видосам кажется весьма поверхностной и пустой. Но у стоуншарда вообще вроде сначала был пролог и пустой мир.
87 Кб, 710x587>>8140
стены это тайлсет, узел TileMapLayer - как и пол, как и толщина стен. НЕ тайлмап это только объекты и сущности.
насчет остального - ну записывать видео со всеми механиками было бы долго, но могу кратко попытаться обьяснить, ибо из видео действительно кажется так.
суть проста действительно - наебнуть финального босса на 30-м уровне. в игре 6 локаций по 5 уровней, в конце каждой локации босс с уникальными эффектами.
игроку в этом мешают как враги (которые подразделяются на собственные классы воина, лучника, защитника, мага, призывателя), так и голод, необходимость поиска/крафта экипировки, и РАНДОМ
сама система игрока на самом деле классическая - 4 характеристики от которых зависят все остальные показатели:
сила (физ урон и способность надеть то или иное снаряжение), ловкость (коэф. уклонения, точности, скорости передвижения и регена энергии), выносливость (объем хп и энергии), магия (множитель маг. урона, реген маны и её объем).
игрок может как искать лут на уровнях, так и выбивать его с врагов, сундуков, или на худой конец крафтить сам - скрафченные игроком предметы имеют больший запас прочности, но по характеристикам стоят между основными тирами (например из рецептов выпавших на второй локации игрок может сделать броню чуть лучше брони выпадаемой на второй локе, но чуть хуже чем на третьей).
экипировку можно улучшать (плюсуя к их характеристикам) или зачаровывать редкими рунами которые дают особые эффекты, типа вампиризма, огненного удара и так далее. чинить экипировку тоже можно.
в игре помимо физических баталий есть магия. заклинания огня (разрушающие деревянные объекты, а также сжигающие горючие предметы у игрока в инвентаре), заклинания заморозки что станят сущностей, всякие иссушения, огненные кольца и дожди, направленные магические стрелы, призыв миньонов и прочее.
В игре есть классы - особо геймплей сильно они не меняют, но задают вектор - прим. маг не имеет силы вовсе, но имеет конское значение магии, которое позволяет ему быстрее регенить ману, давать + к маг. атакам и так далее, но крутое оружие как минимум по началу он брать не может пока не прокачает силу.
по сути это рогалик завязанный на чистом рандоме - если тебе повезёт найти крутой лут в начале считай ты подебил (но ошибки все равно непростительны - даже будучи танком ты можешь пососать не подготовившись к битве с боссом и быть попущен задорной бомбой которая игнорирует коэф. уклонения).
но и этот рандом можно "осадить" - как раз таки крафтом (если не повезло найти крутой гир - сделай его сам), покупкой и торговца "тотема воскрешения", или просто правильным пониманием того каких врагов стоит бить, а от каких лучше убегать.
всё что пока что вспомнил. в остальном и не было идеи сделать АААА игру - но была идея сделать простенький тайм-киллер с чувством кайфа в моменты победы над рандомом (как и в любом рогалике) и с максимально простым освоением. когда я буду это продавать, то не думаю что ценник будет больше пяти долларов.
стены это тайлсет, узел TileMapLayer - как и пол, как и толщина стен. НЕ тайлмап это только объекты и сущности.
насчет остального - ну записывать видео со всеми механиками было бы долго, но могу кратко попытаться обьяснить, ибо из видео действительно кажется так.
суть проста действительно - наебнуть финального босса на 30-м уровне. в игре 6 локаций по 5 уровней, в конце каждой локации босс с уникальными эффектами.
игроку в этом мешают как враги (которые подразделяются на собственные классы воина, лучника, защитника, мага, призывателя), так и голод, необходимость поиска/крафта экипировки, и РАНДОМ
сама система игрока на самом деле классическая - 4 характеристики от которых зависят все остальные показатели:
сила (физ урон и способность надеть то или иное снаряжение), ловкость (коэф. уклонения, точности, скорости передвижения и регена энергии), выносливость (объем хп и энергии), магия (множитель маг. урона, реген маны и её объем).
игрок может как искать лут на уровнях, так и выбивать его с врагов, сундуков, или на худой конец крафтить сам - скрафченные игроком предметы имеют больший запас прочности, но по характеристикам стоят между основными тирами (например из рецептов выпавших на второй локации игрок может сделать броню чуть лучше брони выпадаемой на второй локе, но чуть хуже чем на третьей).
экипировку можно улучшать (плюсуя к их характеристикам) или зачаровывать редкими рунами которые дают особые эффекты, типа вампиризма, огненного удара и так далее. чинить экипировку тоже можно.
в игре помимо физических баталий есть магия. заклинания огня (разрушающие деревянные объекты, а также сжигающие горючие предметы у игрока в инвентаре), заклинания заморозки что станят сущностей, всякие иссушения, огненные кольца и дожди, направленные магические стрелы, призыв миньонов и прочее.
В игре есть классы - особо геймплей сильно они не меняют, но задают вектор - прим. маг не имеет силы вовсе, но имеет конское значение магии, которое позволяет ему быстрее регенить ману, давать + к маг. атакам и так далее, но крутое оружие как минимум по началу он брать не может пока не прокачает силу.
по сути это рогалик завязанный на чистом рандоме - если тебе повезёт найти крутой лут в начале считай ты подебил (но ошибки все равно непростительны - даже будучи танком ты можешь пососать не подготовившись к битве с боссом и быть попущен задорной бомбой которая игнорирует коэф. уклонения).
но и этот рандом можно "осадить" - как раз таки крафтом (если не повезло найти крутой гир - сделай его сам), покупкой и торговца "тотема воскрешения", или просто правильным пониманием того каких врагов стоит бить, а от каких лучше убегать.
всё что пока что вспомнил. в остальном и не было идеи сделать АААА игру - но была идея сделать простенький тайм-киллер с чувством кайфа в моменты победы над рандомом (как и в любом рогалике) и с максимально простым освоением. когда я буду это продавать, то не думаю что ценник будет больше пяти долларов.
87 Кб, 710x587>>8140
стены это тайлсет, узел TileMapLayer - как и пол, как и толщина стен. НЕ тайлмап это только объекты и сущности.
насчет остального - ну записывать видео со всеми механиками было бы долго, но могу кратко попытаться обьяснить, ибо из видео действительно кажется так.
суть проста действительно - наебнуть финального босса на 30-м уровне. в игре 6 локаций по 5 уровней, в конце каждой локации босс с уникальными эффектами.
игроку в этом мешают как враги (которые подразделяются на собственные классы воина, лучника, защитника, мага, призывателя), так и голод, необходимость поиска/крафта экипировки, и РАНДОМ
сама система игрока на самом деле классическая - 4 характеристики от которых зависят все остальные показатели:
сила (физ урон и способность надеть то или иное снаряжение), ловкость (коэф. уклонения, точности, скорости передвижения и регена энергии), выносливость (объем хп и энергии), магия (множитель маг. урона, реген маны и её объем).
игрок может как искать лут на уровнях, так и выбивать его с врагов, сундуков, или на худой конец крафтить сам - скрафченные игроком предметы имеют больший запас прочности, но по характеристикам стоят между основными тирами (например из рецептов выпавших на второй локации игрок может сделать броню чуть лучше брони выпадаемой на второй локе, но чуть хуже чем на третьей).
экипировку можно улучшать (плюсуя к их характеристикам) или зачаровывать редкими рунами которые дают особые эффекты, типа вампиризма, огненного удара и так далее. чинить экипировку тоже можно.
в игре помимо физических баталий есть магия. заклинания огня (разрушающие деревянные объекты, а также сжигающие горючие предметы у игрока в инвентаре), заклинания заморозки что станят сущностей, всякие иссушения, огненные кольца и дожди, направленные магические стрелы, призыв миньонов и прочее.
В игре есть классы - особо геймплей сильно они не меняют, но задают вектор - прим. маг не имеет силы вовсе, но имеет конское значение магии, которое позволяет ему быстрее регенить ману, давать + к маг. атакам и так далее, но крутое оружие как минимум по началу он брать не может пока не прокачает силу.
по сути это рогалик завязанный на чистом рандоме - если тебе повезёт найти крутой лут в начале считай ты подебил (но ошибки все равно непростительны - даже будучи танком ты можешь пососать не подготовившись к битве с боссом и быть попущен задорной бомбой которая игнорирует коэф. уклонения).
но и этот рандом можно "осадить" - как раз таки крафтом (если не повезло найти крутой гир - сделай его сам), покупкой и торговца "тотема воскрешения", или просто правильным пониманием того каких врагов стоит бить, а от каких лучше убегать.
всё что пока что вспомнил. в остальном и не было идеи сделать АААА игру - но была идея сделать простенький тайм-киллер с чувством кайфа в моменты победы над рандомом (как и в любом рогалике) и с максимально простым освоением. когда я буду это продавать, то не думаю что ценник будет больше пяти долларов.
стены это тайлсет, узел TileMapLayer - как и пол, как и толщина стен. НЕ тайлмап это только объекты и сущности.
насчет остального - ну записывать видео со всеми механиками было бы долго, но могу кратко попытаться обьяснить, ибо из видео действительно кажется так.
суть проста действительно - наебнуть финального босса на 30-м уровне. в игре 6 локаций по 5 уровней, в конце каждой локации босс с уникальными эффектами.
игроку в этом мешают как враги (которые подразделяются на собственные классы воина, лучника, защитника, мага, призывателя), так и голод, необходимость поиска/крафта экипировки, и РАНДОМ
сама система игрока на самом деле классическая - 4 характеристики от которых зависят все остальные показатели:
сила (физ урон и способность надеть то или иное снаряжение), ловкость (коэф. уклонения, точности, скорости передвижения и регена энергии), выносливость (объем хп и энергии), магия (множитель маг. урона, реген маны и её объем).
игрок может как искать лут на уровнях, так и выбивать его с врагов, сундуков, или на худой конец крафтить сам - скрафченные игроком предметы имеют больший запас прочности, но по характеристикам стоят между основными тирами (например из рецептов выпавших на второй локации игрок может сделать броню чуть лучше брони выпадаемой на второй локе, но чуть хуже чем на третьей).
экипировку можно улучшать (плюсуя к их характеристикам) или зачаровывать редкими рунами которые дают особые эффекты, типа вампиризма, огненного удара и так далее. чинить экипировку тоже можно.
в игре помимо физических баталий есть магия. заклинания огня (разрушающие деревянные объекты, а также сжигающие горючие предметы у игрока в инвентаре), заклинания заморозки что станят сущностей, всякие иссушения, огненные кольца и дожди, направленные магические стрелы, призыв миньонов и прочее.
В игре есть классы - особо геймплей сильно они не меняют, но задают вектор - прим. маг не имеет силы вовсе, но имеет конское значение магии, которое позволяет ему быстрее регенить ману, давать + к маг. атакам и так далее, но крутое оружие как минимум по началу он брать не может пока не прокачает силу.
по сути это рогалик завязанный на чистом рандоме - если тебе повезёт найти крутой лут в начале считай ты подебил (но ошибки все равно непростительны - даже будучи танком ты можешь пососать не подготовившись к битве с боссом и быть попущен задорной бомбой которая игнорирует коэф. уклонения).
но и этот рандом можно "осадить" - как раз таки крафтом (если не повезло найти крутой гир - сделай его сам), покупкой и торговца "тотема воскрешения", или просто правильным пониманием того каких врагов стоит бить, а от каких лучше убегать.
всё что пока что вспомнил. в остальном и не было идеи сделать АААА игру - но была идея сделать простенький тайм-киллер с чувством кайфа в моменты победы над рандомом (как и в любом рогалике) и с максимально простым освоением. когда я буду это продавать, то не думаю что ценник будет больше пяти долларов.
>>8134
Конечно, есть. Но нужно собирать сообщество, и как можно раньше. Для примера, эта опенсурс (GPL) игра разрабатывается фуллтайм соло разрабом чисто на пожертвования игроков, при том что в гугл плей она доступна бесплатно и в ней нет рекламы:
https://github.com/00-Evan/shattered-pixel-dungeon
Твоя игра на первый взгляд выглядит достойной, достаточно проработанной. Но учитывай, что SPD разрабатывается с 2014 как форк игры из 2012, она достигла популярности не за один день. Т.е. если ты просто выложишь игру в стим/гугл - почти никто не заметит. Нужно формировать сообщество заранее, собирая неравнодушных со смежных сообществ.
>>8141
Много механик и контента, молодец. Возможно, тебе стоило раньше начать делать early access сборки для избранных тестеров. Тебе самому интересно играть? Пробовал кому-нибудь дать поиграть? Преимущество рогаликов в реиграбельности, т.е. рогалик можно перепроходить много раз "как первый раз", но скилл игрока тоже должен быть важен для победы, иначе получается ощущение несправедливого рандома.
>есть шанс на этой игре заработать деняк?
Конечно, есть. Но нужно собирать сообщество, и как можно раньше. Для примера, эта опенсурс (GPL) игра разрабатывается фуллтайм соло разрабом чисто на пожертвования игроков, при том что в гугл плей она доступна бесплатно и в ней нет рекламы:
https://github.com/00-Evan/shattered-pixel-dungeon
Твоя игра на первый взгляд выглядит достойной, достаточно проработанной. Но учитывай, что SPD разрабатывается с 2014 как форк игры из 2012, она достигла популярности не за один день. Т.е. если ты просто выложишь игру в стим/гугл - почти никто не заметит. Нужно формировать сообщество заранее, собирая неравнодушных со смежных сообществ.
>>8141
Много механик и контента, молодец. Возможно, тебе стоило раньше начать делать early access сборки для избранных тестеров. Тебе самому интересно играть? Пробовал кому-нибудь дать поиграть? Преимущество рогаликов в реиграбельности, т.е. рогалик можно перепроходить много раз "как первый раз", но скилл игрока тоже должен быть важен для победы, иначе получается ощущение несправедливого рандома.
>>8141
Ну это я знаю, у тебя же нет привязки к тайлам, нет необходимости делать все одного размера кругом.
По поводу всего остального. Ты уже много сделал - точно не останавливайся, это было бы глупость. Главное мерило качества - хотел ли бы ты сам играть в такую игру?
В остальном вкусы у всех расходятся. В том же стоншарде разрабы сейчас делают уклон в иммерсивность (настроение, кушать, "корованы" итд), а стримерам хочется рогалика.
У всех вкусы разные, смотри на игру со своей колокольни и задумки.
капчу снова изговнили, я манал тут сидеть
>стены это тайлсет, узел TileMapLayer - как и пол, как и толщина стен.
Ну это я знаю, у тебя же нет привязки к тайлам, нет необходимости делать все одного размера кругом.
По поводу всего остального. Ты уже много сделал - точно не останавливайся, это было бы глупость. Главное мерило качества - хотел ли бы ты сам играть в такую игру?
В остальном вкусы у всех расходятся. В том же стоншарде разрабы сейчас делают уклон в иммерсивность (настроение, кушать, "корованы" итд), а стримерам хочется рогалика.
У всех вкусы разные, смотри на игру со своей колокольни и задумки.
капчу снова изговнили, я манал тут сидеть
>>8149
я шарю про SPD, буквально с детства играю, поэтому визуально оно может быть похоже, но все же пытаюсь делать по своему.
повторюсь это первая игра как таковая, и я не шарю как лучше привлекать аудиторию, когда и как это все делать, на каких этапах и т.д. да и в еарли ассес кидать игру в которой даже звука нет… надо найти где-то бачей 200 чтобы на фрилансе звукарю дать задачу, а для меня пока что эта сумма неподъемная :)
я шарю про SPD, буквально с детства играю, поэтому визуально оно может быть похоже, но все же пытаюсь делать по своему.
повторюсь это первая игра как таковая, и я не шарю как лучше привлекать аудиторию, когда и как это все делать, на каких этапах и т.д. да и в еарли ассес кидать игру в которой даже звука нет… надо найти где-то бачей 200 чтобы на фрилансе звукарю дать задачу, а для меня пока что эта сумма неподъемная :)
у меня есть
@tool
class_name TacticalNavigationRegion3D
extends NavigationRegion3D
@export var tactical_influence_map: TacticalInfluenceMap
...
при bake генерирует граф и пишет в
class_name TacticalInfluenceMap
extends Resource
@export var influence_nodes: Array[InfluenceNode] = []
...
InfluenceNode тоже ресурс
в рантайме influence_nodes пуст, другие поля (примитивы) на месте
сам ресурс сохраняю на диск и в нем все ок. В редакторе все ок
Когда запускаю в remote ноды есть, но фактически при обращении на стеке массив пуст
поясните что не так
@tool
class_name TacticalNavigationRegion3D
extends NavigationRegion3D
@export var tactical_influence_map: TacticalInfluenceMap
...
при bake генерирует граф и пишет в
class_name TacticalInfluenceMap
extends Resource
@export var influence_nodes: Array[InfluenceNode] = []
...
InfluenceNode тоже ресурс
в рантайме influence_nodes пуст, другие поля (примитивы) на месте
сам ресурс сохраняю на диск и в нем все ок. В редакторе все ок
Когда запускаю в remote ноды есть, но фактически при обращении на стеке массив пуст
поясните что не так
>>8229
блэт нет, после перезагрузки проекта из ресурса ноды удаляются. Все еще не понимаю что не так
блэт нет, после перезагрузки проекта из ресурса ноды удаляются. Все еще не понимаю что не так
248 Кб, 1280x720>>3400 (OP)
Не будем катить до 4.7.stable? Вроде скоро выйдет.
На днях вышла вторая бета 4.7:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-2/
Фиксанули ResourceLoader::load_threaded_request():
https://github.com/godotengine/godot/pull/118824
Может, у меня загрузка игры ускорится? А то я этот загрузчик использовал несколько версий назад и ВНЕЗАПНО загрузка лишь удлинилась... Я такой: "ок, возможно, это норма, просто сцены у меня пока что маленькие, всего 4 потока ЦПУ, наверняка там есть преимущество на более тяжёлых ресурсах"... Нужно посмотреть поскорее, что получится с новой бетой.
Теперь внутренние ноды берут материал родителя:
https://github.com/godotengine/godot/pull/115637
Выгодно для тех, кто делает шейдеры для GUI.
Юзабилити: передвинули кнопку очистки лога:
https://github.com/godotengine/godot/pull/118954
Говорят, самая важная кнопка лога. Лол, всё так.
Undo/redo движения камеры в режиме пилота:
https://github.com/godotengine/godot/pull/119349
Если кто упустил, в 4.7 добавили вот этот QoL:
https://github.com/godotengine/godot/pull/109945
Мне очень не хватало этой фичи со времён 3.x.
Не будем катить до 4.7.stable? Вроде скоро выйдет.
На днях вышла вторая бета 4.7:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-2/
Фиксанули ResourceLoader::load_threaded_request():
https://github.com/godotengine/godot/pull/118824
Может, у меня загрузка игры ускорится? А то я этот загрузчик использовал несколько версий назад и ВНЕЗАПНО загрузка лишь удлинилась... Я такой: "ок, возможно, это норма, просто сцены у меня пока что маленькие, всего 4 потока ЦПУ, наверняка там есть преимущество на более тяжёлых ресурсах"... Нужно посмотреть поскорее, что получится с новой бетой.
Теперь внутренние ноды берут материал родителя:
https://github.com/godotengine/godot/pull/115637
Выгодно для тех, кто делает шейдеры для GUI.
Юзабилити: передвинули кнопку очистки лога:
https://github.com/godotengine/godot/pull/118954
Говорят, самая важная кнопка лога. Лол, всё так.
Undo/redo движения камеры в режиме пилота:
https://github.com/godotengine/godot/pull/119349
Если кто упустил, в 4.7 добавили вот этот QoL:
https://github.com/godotengine/godot/pull/109945
Мне очень не хватало этой фичи со времён 3.x.
>>8284
Я вообще на тройке сижу, но думаю там история как с гилом в питоне - многопоточностью настолько комплексно рулить, все эти мьютексы-хуютексты-дедлоки, чтобы вин перформанса по сравнению с одним потоком мизерный, и основный юзкейс это, по сути, интерактивные лоадинг скрины, пока у тебя вне основного потока что-то грузится.
>Фиксанули ResourceLoader::load_threaded_request():
Я вообще на тройке сижу, но думаю там история как с гилом в питоне - многопоточностью настолько комплексно рулить, все эти мьютексы-хуютексты-дедлоки, чтобы вин перформанса по сравнению с одним потоком мизерный, и основный юзкейс это, по сути, интерактивные лоадинг скрины, пока у тебя вне основного потока что-то грузится.
92 Кб, 720x1020>>8286
Это такой тонкий троллинг?
Ты ссылку не открывал? Там какой-то анекдот:
Т.е. раньше можно было отправить джва десятка независимых потоков грузить один и тот же ресурс, поскольку они все думают "Что, зависли? Ладно, я попробую вместо вас", и все делают ОДНО И ТО ЖЕ.
Обрати внимание на числа на пикриле.
Нет, бутылочное горлышко загрузки с диска - это исключительно скорость HDD/SSD. Поскольку SSD безразлично положение файла в памяти, они могут ускоренно переключаться с одного на другой. А всё остальное - парсинг, создание объектов и т.д. - это независимые задачи. Поэтому прирост от многих отдельных потоков должен быть большим... Но тут проблема была в том, что потоки не знали, что им необходимо грузить самим, а что - подождать.
>sage
>в поле темы
>в утонувшем треде
Это такой тонкий троллинг?
>многопоточностью настолько комплексно рулить
Ты ссылку не открывал? Там какой-то анекдот:
>When multiple threads try to load the same sub-resource the ResourceLoader's anti-deadlock protection thinks that the other threads loading the dependency are old threads blocked on a dependency.
>The current thread will then immediately start to load the sub-resource since they can't wait for it. This can then lead to multiple threads loading the same resource concurrently.
>We fix the problem by recording in the task when loading has ACTUALLY started, and if so we simply wait.
>This is no worse than before, at the point where we are waiting now we previously re-started the load entirely.
Т.е. раньше можно было отправить джва десятка независимых потоков грузить один и тот же ресурс, поскольку они все думают "Что, зависли? Ладно, я попробую вместо вас", и все делают ОДНО И ТО ЖЕ.
Обрати внимание на числа на пикриле.
>вин перформанса по сравнению с одним потоком мизерный, и основный юзкейс это, по сути, интерактивные лоадинг скрины, пока у тебя вне основного потока что-то грузится.
Нет, бутылочное горлышко загрузки с диска - это исключительно скорость HDD/SSD. Поскольку SSD безразлично положение файла в памяти, они могут ускоренно переключаться с одного на другой. А всё остальное - парсинг, создание объектов и т.д. - это независимые задачи. Поэтому прирост от многих отдельных потоков должен быть большим... Но тут проблема была в том, что потоки не знали, что им необходимо грузить самим, а что - подождать.
1,9 Мб, 1920x1080ХАЙПОВЫЙ ПЕРЕКАТ
>>1088293 (OP)
>>1088293 (OP)