Шапка: 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/
>3
У вас змеечка по диагонили ходит, алло!
Подводный один, туда никто не заходит, итч не льет трафик, ты сам должен раскручивать по всяким тиктокам и прочему.
Нет, не фича, это баг, не лги себе, я полночи сидел пытался исправить баг с диагоналями у себя, и так и не смог.
Багофича: сделано случайно, но понравилось.
>пытался исправить баг с диагоналями
Ты правда код скопировал, не осмыслив его?
Добавь на указанную строчку, например, это:
>...and new_direction.x != new_direction.y:
Это должно запретить ходы по диагоналям.
Если хочешь понять смысл строчки с dot():
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-dot
Весь тот код был написан на скорую руку.
>>1083472
>А я смог
Молодец.
Этот код не реагирует на нажатие. Направление изменилось и? Таймер ждёт следующего тика. Переделывай.
В прошлый раз на чистом гдскрипте смог выжать сражения 500 на 500. Сейчас подключил C#, его либу для ECS, параллельные вычисления, рендеринг сервер, мультимеш2д, кастомный шейдер и уже 10К на 10К драки держат 100+ фпс на моём средненьком i5 процессоре.
Хотел сначала сделать видос, но шакалит люто и весит больно много, поэтому чисто скрин.
>Круто
А гейплей в чем? Игроки должны восхититься тем, что автор освоил ецс?
Ну так не пользуйся, это опенсорс, можно любой язык подключить, например C++
Да. Технология открывает возможности для геймплея - битвы 10к на 10к.
Битва 10к на 10к это не геймплей еще. Кроме мессива на экране нужно еще что-то захватывающее. А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Выглядит клево
>Хотел сначала сделать видос, но шакалит люто и весит больно много
Можно небольшой кусок снять, условно в середине
>>1083506
>А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Я думаю дорога на восток многим из движкосрача треда подложила свинью, отчего некоторые и возбудились. Потому что кок ток то! Это жы гдскипт нююю он же плохой uuuu
Ты забыл потребовать признать это.
Ага, я очень доволен.
>>1083501
Геймплей будет, я хотел сначала сделать стресс-тест того, что это вообще жизнеспособно в годоте.
>>1083510
Ну вот тебе 5 секунд с середины, правда не уверен, что хоть что-то разберешь в этом месиве пикселей. Зато 300 фпс, хоть и скачущие.
>гдскипт нююю он же плохой
Так 2 топовые игры на годоте (sts2 и восток) - обе на шарпах. Так что гдс унижают даже в рамках годотреади-языков
>сражения 500 на 500.
Это на нодах было или уже мультимеш?
Какое железо?
Да, на нодах было.
Проц i5 12600, 16 гигов оперативки, видяха тогда 3060ti была.
Обе этих игры начинали делать на другом движке на C#, то есть тут нет никакой объективной причины в самом гдскрипте. Просто у них уже был какой то опыт и может быть какой то игровой код написан
В СУБШОТЕ уже был твой коллега.
>>1080088 →
Все это конечно классно, но интересно бы что-то приближенное к реальной игре с поиском пути. Как вот жуки в факторио. Там, почему-то, ощущается это жутковатая масса в движение (может просто игровая иммерсивность), а тут не чувствуется этого. У чела в СУБШОТЕ вообще уже на жидкость похоже.
Скорее всего начинали с юнити и потом перекатились.
>какой то игровой код написан
Слишком большая разницам, все с нуля придется переписывать, если ты прям не гуру кодер которому делать нефиг, который умудрился писать сразу через слой абстракции (да еще обобщить между двумя движками, так как заведомо ты такой код никогда не напишешь, абстракции будут протекать)
>гуру кодер которому делать нефиг,
Да это я, я как раз пишу всю игровую логику на c++ и подключаю к разным рендерам.
Как бы на шарпах тоже надо уметь писать оптимизированный код, сам по себе шарпы тебя не спасут от гадостей в игровом цикле. Да и часть API на вариантах (динамических типах), поэтому не прокрастинируй шарпами.
Все равно дотнетовские шарпы это совершенно отдельный мир. А для хоум скриптов тебе хватит петухона, который похож на гдскрипт.
1. научись делать игры.
2. научись оптимизировать игры.
3. уже потом думай что упёрса в гдскрипт (потому что очень сильно захочется сразу прыгнуть в с++).
В реале может получиться что эффективный проект будет 95% на гдаскрипт и лишь 5% на С++
Почему ты считаешь что дело только в оптимизациях? Просто у людей могут быть предпочтения к языкам и платформам. Не только к синтаксису. Особенно если люди работали кодерами. Например чел проникся реактивным программированием и хочет использовать Rx везде где можно.
мимо
>Направление изменилось и? Таймер ждёт следующего тика.
Код написан с учётом особенностей движения "змейки":
- змейка движется ПОСТОЯННО - не способна остановиться;
- змейка движется в последнем выбранном направлении;
- змейка не может двигаться назад/задом наперёд.
Итого, когда наступает очередной цикл опроса:
1. Считываем актуальные значения ввода (get_vector()).
2. Проверяем соответствие условиям движения (см. выше).
3. Если условия соблюдены, принимаем новое значение.
4. Если условия не соблюдены - движемся куда двигались.
Примеры:
- двигались вправо - нажали вправо - движемся вправо;
- двигались вправо - нажали вверх - движемся вверх;
- двигались вправо - нажали влево - движемся вправо;
- двигались вправо - ничего не нажато - движемся вправо.
>>1083492
>голова не кружится, когда вы гдскрипт читаете?
Это просто с непривычки. Так с любым новым языком.
Технический опыт показывает, что лучше брать инструменты близкие к платформе.
Ты и так будешь трахаться с проблемами, так еще добавишь слой проблем от вторичного языка.
Поэтому если андроид - то это котлин.
если айос - то свифт, а не котлин
если годот это - гдскрипт.
При этом я очень не поддерживаю идею гдскрипта, он тормозит развитие. Да, облегчает вкат, но развитие создают не они, а те авторы "востока" и прочих шумных релизов (а они нередко мигранты с юнити и шарпов. Поэтому важнее было бы облегчить им миграцию, чем тем людям которые дропнуть разработку с вероятностью 99.99%).
Меня тоже ломало от правосторонних типов 11 лет назад. Ниче, адаптировался.
На питоне почти не писал.
Пофиг на гдскрипт, надо пинать чтобы полноценный и нормальный JIT сделали.
Годот позволяет писать без узлов (эти ваши серверы). Я не копал так глубоко, но периодично натыкаюсь на всякие заманухи, которые показывают что годот можно перелопатить довольно гибко (но зачем?)
>Технический опыт показывает, что лучше брать инструменты близкие к платформе.
А практический опыт показывает, что лучшие игры пишутся лучшими инструментами (язык - тоже инструмент), к коим гдс никаким боком не относится.
>Поэтому важнее было бы облегчить им миграцию
Согласен, лучше замедлить динамикодрисню еще одним слоем, который будет перебивать строго типизированное апи в варианты, чем делать из самого апи движка этот слой. Динамикодрисне то похуй, она и так медленная, а вот нормальным языкам - больно.
гдСКРИПТ - это скриптовый язык. На нем, естественно, пишутся всякие легковесные скрипты (гуй, ввод контроллера и так далее), а тяжелые вычисления на с++. Поэтому да, игры делаются на связке лучших языков (c++ и скриптов). C# тут как видишь не участвует.
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>>1083496
>500 на 500
>10К на 10К
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
>жертвы курсов
Почему курсов то? Сишорпу с дотнетом дофига лет. И отечественный софт на дотнете очень давно пишется.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
Видишь ли, это может показаться тебе неочевидным, но у движка открытые исходники, и ты можешь вызвать любую функцию с любым нужным типом.
>Ребят, завязывайте со срачем "GDScript vs C#".
Тогда придется идти делать игры.
>динамикодрисня с вариантами в качестве апи к движку
Это хорошо. Ты не должен обращаться к API движка слишком часто из высокопроизводительного кода. Твой код получает пакеты данных от движка, обрабатывает их у себя внутри на максимальной скорости, а потом передаёт движку одной командой. Всё. Не нужно дёргать API движка каждую наносекунду. Если тебе почему-то нужно, то тебя производительность вообще волновать не должна - тебя должна волновать кривая архитектура/дизайн игры.
>Тогда придется идти делать игры.
Вот я и пытаюсь делать игру... Открыл редактор Godot, открыл несколько скриптов, потом подумал "дай гляну тред, буквально минутку и вернусь к своим скриптам", а вы тут 50 постов успели насрать буквально за пару часов. Ну сколько можно? Потерял на вас ещё пару часов. Опять день закончился, а к игре даже не притронулся...
>ты можешь вызвать любую функцию с любым нужным типом.
По поинтеру штоле? Как деды? Это нарушение изоляции, за которое я заплачу сегфолтами, на которые я никак не повлияю, даже если я захочу дергать за яйца функции внутри движка вне общего апи. Форк движка это конечно интересно, но не очень интересно
>>1083584
>Чем хуже тем лучше, только выиграли, ну подумаешь что рейкастим нодой потому что рейкастить нодой быстрее чем рейкастить через апи
И это я еще не углублялся в тему renderingdevice, там скорее всего тоже есть на что посмотреть
Но проблема ньюфагов именно в их плохом коде и понимании масштабов того, как им еще далеко до кода хотя бы среднего качества.
Я как-то в сосничестве реализовывал функции пхп на С++ и они у меня работали медленней чем на пхп. Открыл сорцы и вообще не понял что там за магия, а я верил что там просто char перебирают
Прокрастинируешь, сынок?
я сюда заглядываю утром под кофе или после работ
Почему ты считаешь что только ньюфаги хотят определенный язык использовать? Ньюфаги как раз жрут что дают, а более опытные уже имеют предпочтения исходя из своего опыта.
Ты скорее сам ньюфаг потому что все сводишь к синтаксису и какой-то мифической скорости. Не ньюфаг думал бы что хочет использовать либы к которым привык.
>использовать либы к которым привык.
Так выпьем же за то, чтобы не-ньюфаг использовал эти либы, а не срался за движки и языки вне движкосрач-треда!
> Форк движка это конечно интересно, но не очень интересно
Это единственный вариант если ты делаешь по настоящему Великую игру.
Ну так бери и используй. Опять не нюфагам что-то мешает что же такое творится то.
>Почему ты считаешь что только ньюфаги хотят определенный язык использовать?
Потому что у реального специалиста нет синдрома утёнка, он достаточно гибок.
>Не ньюфаг думал бы что хочет использовать либы к которым привык.
Завтра сделают С# первым гражданином и придет твой собрат который будет ныть так же про gdscript. Ощущаешь однобокость твоего мышления?
Отличие профессионала от ньюфага - умение адаптироваться - быть гибким, а ты ноешь, возводя свои эгоистические потребности выше профессионального скилла. Поэтому я и утрирую это поведение до ньюфажного.
Умение адаптироваться это не есть способность, когда тебя лишили авто, кататься на велосипеде сквозь ветер с дождем. Как говорится ветер в харю - я хуярю. Я таких "сенек" видел на работе. Два десятка лет пишут весь код в одном файле на десятки тысяч строк с формулировкой - так удобнее.
Как бы то ни было, ничего не изменится.
Если только МС не увидит перспективу годота и хардкорно не протолкнут свое лобби с фулл там кодерами.
Но у мелкомягких проблема с дальновидностью.
От нас с тобой ничего не зависит, даже если мы наноем 500 сообщений на двачах, все равно игру придется делать нам самим, как бы мы не злились на свою прокрастинацию и на этот неидеальный мир
>Я так понял по MIT лицензии просто нужно указать авторов в своей игре и все
Главное эту MIT лицензию сохранить, в авторах можно не указывать
Сам движок по MIT лицензии же. Чего ты сомневаешься?
А когито мне не понравился, он какой-то переусложнённый.
Наоборот. MIT не требует сохранения лицензии, но требует указания авторства.
А такое для 3д работает? Ну не 10к тыщь а хотя бы орду из 100 человек воссоздать нормально
Конечно, шарп шустрее гдскрипта процентов на 10, в специально подготовленных тестах, но всё-таки главное "узкое место" - скриптовое апи движка. Так что, для критических по быстродействию мест гдскрипт или ц# - однохуйственно в сравнении с C++.
Ну и вообще, есть простое правило. Если что-то выполняется 100500 раз за кадр, то этим должен заниматься компилируемый кусок кода (если предусмотрено, то лучше сам движок); если же до пары десятков раз - то вообще похуй, хоть жабаскрипт туда впили. Все проблемы с производительностью сводятся к тому, что криворукий кодер делает скриптами то, чем должен заниматься компилируемый код. Так что вообще забей, гдскрипт не "медленный" в бытовом понимании, просто не предназначен для некоторых специфических задач, типа управления армией в стратегии-числодробилке.
НО. Выучить C# всё равно полезно просто для собственного развития. В процессе ты сам поймёшь, что он нихуя не производительнее; однако знания - это знания, они делают тебя востребованным специалистом. Знать два языка - всяко лучше, чем знать один язык.
>однохуйственно в сравнении с C++.
Остальные языки проиграют плюсам по производительности работы с годотом только в случае форкования движка и написания кода прямо в движке, не gdextension, а прямо в движок, что тянет за собой постоянную рекомпиляцию движка для проверки функционала. В случае gdextension - производительность апи равнозначна для любого языка, и гдс, и с++ и раст и с#, что приводит к тому, что один и тот же простой код (например для управления частицами через renderdevice) будет начинать пропердывать на условных 100к частицах на любом языке, компилируемом, интерпретируемом, каком угодно. Так что не пизди, дядя
Кстати, я не разбираюсь ни в чем мною написанном, просто набросил говна на вентилятор. Но рад, что спровоцировал хорошие интересные ответы.
>тянет за собой постоянную рекомпиляцию движка
Это вообще не проблема.
>500 на 500 - много
Скачи Мочи очень популярная и успешная серия игр.
Там и поболее будет в Warband.
А так это просто нагрузочный тест, я хотел посмотреть, как сильно прокачался за пару лет периодического тыканья годота и шарпа, чтобы сравнить с тем, как было раньше. Понятно, что пока это просто месиво и геймплея нет. Но уже сейчас есть огромный запас фпс для реализации обхода препятствий, разных классов юнитов и прочего. Особенно если раза в два порезать количество юнитов и сделать бои не 10К на 10К, а 5К на 5К. Там и 500 фпс спокойно держатся на среднем проце.
>>1083653
В теории будет, но я не уверен. Я никогда 3Д в годоте не занимался. Тут практически всё вынесено из годота, у меня буквально одна нода, которая просто гоняет ECS и рисует пискели. Даже для юнитов нод нет. Это отдельные ECS-сущности и десяток ECS-систем, которые как-то их обрабатывают.
То есть даже механика коллизий в этом проекте - это ECS, а не CollissionShape годотовский. Приходится конечно вручную всё считать, но это все равно быстрее выходит, чем 20К коллижн шейпов каждый фрейм.
Когда у тебя есть команда сеньоров на зарплате? Тогда согласен. Можно из годота вообще повыдирать только самое важное (типа рендера) а остальное писать самому
>написания кода прямо в движке
Во-первых, не прямо в движке, а в отдельном модуле, статически линкуемом с движком. То есть весь твой самодельный велосипед будет изолирован в папке и обновляться на новую версию движка будет легко.
Во-вторых, Godot компилируется всего лишь час на компьютере из условного 2007 года в 4 потока. А у современных домашних компов от 8 потоков, RAM значительно шустрее и всякие новые AVX есть...
В-третьих, после первичной компиляции, тебе нет необходимости повторно компилировать исходники движка, поскольку достаточно скомпилировать свои собственные исходники (модуль) и потом всё вместе слинковать. Я тоже раньше думал, что C++ таким вот образом не умеет делать, но это реально возможно. Линковка занимает намного меньше времени, чем компиляция исходников в объектные файлы.
Так что создание модуля Godot вообще не проблема.
Проблема - придумать игру...
Красиво стелишь, но есть ньюансы
Движок должен знать что твоя либа существует, т.е. внутри него должен быть размещен функционал, который встроит твой код в пайплайн рендеринга, отправит ему состояние и применит возврат заместо gdext.
В виду того что зачастую тебе нужно не внедрять что-то новое, а модифицировать что-то уже существующее но хуево работающее - такое импровизированное апи, призванное отделить либу от кода движка - потребуется во многих местах. А еще - тебе придется самому поддерживать свои правки в обновлениях, что еще более печально.
Тебе чтобы написать команду scons platform=windows target=editor / target_release нужна команда сеньоров?... Это как анекдот про вкручивание лампочки?
>Скачи Мочи очень популярная
Про твою мочу только от тебя слышу здесь время от времени, а ведь я знаю много нишевых игр, которые никогда не станут широко известны нормисам. Ты представляешь, насколько мал охват твоей мочи? Буквально ноунейм для средневековых ролевиков.
>500 фпс спокойно держатся на среднем проце
Ты о геймплее лучше думай. 500 фпс симуляции мочи, обтекающей скачи, не делает игру хорошей. В GTA нет больших скоплений народа, но она всегда была самой популярной после Minecraft, в котором количество монстров даже меньше, чем пешеходов в GTA. А это максимально популярная игра, выше просто некуда... Хорошо, если взять что-то вроде Roblox, то может и возможно побить Minecraft, но ты видел Roblox? Там значительно хуже язык, чем наш GDSctipt, их движок принципиально не тянет адекватную графику. Пока подсчитываешь fps в своей моче, кто-то уже делает очередной культурный феномен, что запомнят все.
Трудно не прописать команду, а обеспечить причину ее прописывания
>Про твою мочу только от тебя слышу здесь время от времени, а ведь я знаю много нишевых игр, которые никогда не станут широко известны нормисам. Ты представляешь, насколько мал охват твоей мочи? Буквально ноунейм для средневековых ролевиков.
Лолблядь, как ты умудряешься обсираться раз за разом
>должен знать что твоя либа существует
Там, вроде, можно просто зарегистрировать свою собственную ноду, которую юзер будет размещать и подключаться к ней через GDScript. То есть будешь работать точно так же, как с обычными нодами.
>пайплайн рендеринга
Ты рендерер переписываешь или игру делаешь?
По-моему, речь шла о геймплейных функциях...
>поддерживать свои правки в обновлениях
Ну, попробуй документацию git почитать...
Ну если для тебя игра с 222 тысячами обзоров в Стиме это что-то нишевое, то действительно, нужно целиться тогда на майнкрафт, гта и роблокс, не меньше.
Не очень понимаю ход твоих мыслей. Если в самых популярных играх нет тысяч юнитов, то и я должен сделать их мало или что? Что за бред.
>культовый феномен
Я не думаю, что пытаться искусственно вывести культовый феномен по лекалам тех, кто это смог - хорошая идея. Может лучше сделать игру, которая будет нравиться мне самому в первую очередь?
>нищие 96к отзывов на англюсике (вери позитив)
Напомнить число отзывов пиксельной Terraria?
А ведь в Terraria и сотни мобов на экране нет...
При том у Terraria отзывы overwhelming positive.
Делой выводы @ делой игры.
>Если в самых популярных играх нет тысяч юнитов, то и я должен сделать их мало или что?
Нет, это просто значит, что тебе не нужны эти тысячи юнитов, чтоб сделать потенциально популярную игру. Конечно, ты можешь делать что угодно, просто такое количество не является обязательным условием.
>Может лучше сделать игру, которая будет нравиться мне самому в первую очередь?
Конечно, лучше. Но для этого не обязательно сидеть и дрочить байты на движке, который для такого рода мастурбации вообще не предназначен. Ты мог бы нарисовать намного больше спрайтов на голом SDL. Каждый дрочит как он хочет, и не нужно заставлять местных любителей дрочить GDScript переходить на альтернативы ради 10k одинаковых юнитов.
Так понятнее?
Никого сейчас не впечатлишь еще одной террарией.
Уникальная игра с кучей юнитов - выделяется на фоне других.
НИКАВО НЕ УДИВИШЬ ОЧЕРЕДНОЙ ТЕРРАРИЕЙ
@
ОЧЕРЕДНОЙ СИМУЛЯТОР МОЧИ - ВОТ ЭТО ДА!!!
Таких симуляторов были сотни, и где они все теперь?
Нужно что-то помимо текущих потоков тупых NPC...
Но выделится - не значит захватить внимание на несколько часов
мимо
>и не нужно заставлять местных любителей дрочить GDScript переходить на альтернативы ради 10k одинаковых юнитов
Я и слова плохого не сказал о gdscript тут и никого не призывал срочно бросить гдскрипт и перейти на шарпы. Я и сам на нём писал раньше, и был доволен.
Но сейчас под конкретно МОЮ текущую задачу мне понадобились другие инструменты, которых в гдскрипте нет, но при этом сам движок мне нравится. Поэтому я просто перешел на другие инструменты и сделал небольшой пост тут о том, что они рабочие.
Технически нужно растянуть всего на два часа, чтобы заработанные деньги не возвращали. Для этого есть разные способы, катсцены, загрузочные экраны, туториал, постепенное добавление контента, карты попросторнее с большим расстояние которое надо сначала пройти.
Таким пидарасам как ты на 59й минуте второго часа рефандят. Уёбок.
Как по мне, это имеет массу преимуществ:
- пираты и дети могут играть с остальной фанбазой;
- желающие задонатить побольше могут это сделать;
- покупателю не придётся ничего никому возвращать;
- доверительные отношения, ведь нет обязательств;
- легче получить новые взносы от старых игроков.
Основной минус - в отзывы насрать проще.
Но ненужный ассетфлип так не продашь...
И есть какие-то предрассудки (?) о F2P...
Если ты просто будешь регулярно обновлять свою игру, то пиратить её будет уже неудобно. Вдвойне если прикрутишь воркшоп. А cosmetic DLC это кал, который актуален в основном если у тебя мультиплеер и ты сервак держишь. Если делать dlc, то хорошие.
Ну, как по мне, написать модуль движка проще, чем gdextension. Я попробовал то и другое где-то год назад. Но это личные впечатления, да и в плюсах я тогда понимал сильно меньше, чем сейчас.
>>1083671
>В-третьих
Ну кстати да, это фича SCons. Вообще, жаль, что эту систему сборки поддерживает так мало ИДЕ, она пиздатая. Ну уж точно лучше, чем cmake.
>Ну кстати да, это фича 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)
да и вообще вроде системы сборки в плюсах следят за изменениями зависимостей единиц трансляции, а не "модулей". Перекомпиляция зависящей единицы трансляции будет если заголовочные файлы в зависимостях изменились. Если изменился cpp файл зависимости, без изменения hpp то перекомпиляции каскадной не будет
Ну да, в этом и смысл хедеров, хедеры это же интерфейс. Если интерфейс не изменился, то внутренняя реализация никак не повлияет на остальное окружение, это и есть инкапсуляция.
Смотрю вот эти изделия игросодержащие, ну графоний/спрайты понятное дело хуета уровня каляки-маляки пятиклашки в пэйнте. Потом захожу на страницу к разрабу: там среднестатистический заводчанин 35+, проживающий где-нибудь в центральной России, нередко женатик, а то и с детьми.
Что это за особая прослойка мрачных психологов такая? Почему они так любят инди двадэ хорроры (которые вызывают не столько страх, сколько кринж). Поколение читателей Стивена Кинга?
И кто вообще в такое играет кроме самих энтих разрабов и их внутреннего круга из 5 человек?
Продается потому что
>>1083811
Спокойно вон поляк уже вполне успешно 3 раза почти одно и тоже продает
А имя студии отсылает к дедам
https://store.steampowered.com/search/?developer=Harvester%20Games
>нынче
>ХОРРОР
Сколько тебе лет, 13? С подключением! Инди-хорроры сохраняют свою популярность с нулевых, когда там индюшатинка начала развиваться на движках для нормисов. Многие старые движки уже умерли, а жанр продолжает жить, потому что он просто бесконечный.
Хоррор сделать относительно легко, потому что в нём важнее всего создать эмоции, а на качество графики, озвучки и глубину геймплея наплевать. Для людей естественно бояться темноты, а в темноте попробуй отличить плохую графику от хорошей; шум, треск и остальные дефекты звука - это плюс, а не минус; для геймплея достаточно ходить и тыкаться в кнопки... Монстров нарисовать на порядки проще, чем что-то красивое, буквально любой новичок может взять и нарисовать или смоделировать что-то мерзкое. Даже упоротые анимации - плюс, а не минус для хоррора.
Но самое главное в жанре хоррора - это отсутствие реиграбельности. Люди много чего могут бояться на протяжении всей жизни, но ты не можешь пройти классический хоррор второй раз и напугаться как в первый раз. Допустим, ты боишься темноты, но ты боишься, на самом деле, неизвестности - того, что способно скрываться в темноте. Пройдя игру, ты уже знаешь, какие там монстры или про их отсутствие, и прежнего уровня страха от этой игры уже не будет.
Но от другой, новой игры? Ты будешь бояться снова, практически как с первой игрой, ведь новая, даже с аналогичной графикой, геймплеем и т.д., таит в себе неизвестность. Ты не потерял страх темноты, и ты не знаешь, что тебя ждёт в новой игре. Поэтому можно проходить тысячи инди-хорроров и это тебе не будет надоедать, в отличие от многих других жанров игр.
Вкратце:
- создать легко => низкий порог входа;
- нет реиграбельности => ниша ненасытна.
Для сравнения, жанры с высокой реиграбельностью насыщаются очень быстро и поэтому в них высокая конкуренция за игроков; например, бестолку делать собственный аналог Minecraft или Terraria, если ты копируешь их слишком сильно - игроку нет никакого интереса играть в твою игру, когда они могут влить следующие 5000 часов в старую игру и получить удовольствие на уровне предыдущих 15000 часов. Оригинальную игру в том же жанре сделать можно, однако, это намного сложнее из-за более высоких требований как к графике, так и к геймплею, и т.д.
Поэтому многие выбирают жанр хоррора.
Хорроры и порнуха вызывают одинаково аддиктивные эмоции. Об этом еще на форумах интернета 1.0 писали.
Мне показалось
> порноходы
И я уже хотел написать про Вселенную-наоборот, но потом перечитал внимательнее.
Но вообще да, во Вселенной-наоборот с толщеходами есть хоррорный элемент. Тёмные полости с погасшим ядром заселяются слепыми хищниками, которые ориентируются на шум, охотятся стаями. Хрен убежишь. Догонят и выебут. Вот вам и хоррорпрон.
Касательно слова "нынче" это я спизданул к тому, что сам начал подмечать тенденцию к засилью подобного у новичков именно ближе годов с 20х. Раньше дофига было платформеров, их и сейчас дофига, но уже как будто не модно, моднявее сделать жуууткую новелку, или бродилку по жопе негра с фонариком. Если в тридэ — всё те же бессменные вариации на тему слендермена с записками в лесу.
Вот годах в 10-20х, особенно в первой половине я видел тенденцию к платформерам с "фишкой", какая-нибудь там гравитация, отмотка времени, паззлы/головоломки по типу VVVVVV. Или там копалки-подземки по лекалам Spelunky/Steamworld Dig. Плюс ко всему артстайл в эту эпоху расцвета миллениалов был какой-то с позитивом, надеждой, все эти улыбчивые мордочки Джамп Гаев, Шот Гаев, Иван Гаев, придурошно, но по доброму, и без "у-у-у, ужастег псехологея".
Может это чисто персональное восприятие, но как правило на смену парадигмы среди сообществ людей у меня чуйка натаскана.
Суть ответов ясна: "просто сделать + сложно проебаться". Надеялся, конечно, что это всё же не от того, что народ выбирает путь наименьшего сопротивления, а скорее какая-то мода/повестка/тренды/ситуация в мире. Но спорить с мнениями не буду.
>>1083825
Интересно. Я всегда осознавал, что sex sells, но вот конкретно хорроры думал более нишевая шняга. Сам то я их стороной обхожу просто, наигрался в нулевых во всякие калл оф ктулху, скрэтчес, и понял, что революции в жанре не будет, а жрать старое под новым соусом — нахуй надо. Из последнего заценил уже считающийся "старой игрой" алиен изолейшен, ну да, прикольно, попрятаться под столами. Но в целом тягомотина же, нудятина. Хз, не получаю видать тех же эмоций, что другие пиплы от чувства страха. Лучше уж книженцию какую почитать, так иммерсия в 10 раз интенсивнее.
Никогда не любил хорроры. От слова совсем. Зато люблю порноигры. Не похоже на что-то общее.
>мода/повестка/тренды/ситуация в мире
Но ужастики всегда нравились детям...
>>1083911
>Ты вагину видел ваще?
Очевидный хэдкраб очевиден же...
Я вижу больше 3д хорроров, чем 2д, но я слежу за зарубежьем. Пс1 стайл лоуполи с кое как сделанными моделями и текстурами это первый законченный проект и многих инди девов. AlphaBetaGamer канал на ютубе, там такого полно.
Ламар!? Ты куда опять сбежала? Прыгай мне на лысину. Вот так, моя девочка.
>Крайне удачно они
В чем удача? Они задонатили больше чем покупка про лицензия.
>Вдвойне если прикрутишь воркшоп.
Моды убьют твою игру. Посмотри как сделал стоншард. Они около 7-9 лет пилят разжиревшую полудемку, меняют цифры стат местами (как в патчах доты) и запиливают буквально одну-две механики или персонажа.
Был бы вагон модов и контента, они не смогли такими малыми силами доить корову почти 10 лет.
Пришлось бы делать реально жырные патчи или DLS (то есть реально работать), чтобы конкурировать с обилием модов. А так люди праще радуются (что по механике копия лука) или новому персонажу (просто арт с другими статами).
Там "стремящийся" к какому-то значению тик, но он никогда не бывает "стабильным", даже в вакууме, поэтому дельта всегда имеет смысл.
"Стабильный" - не означает бесконечную стабильность и гарантированность. Бывают пропуки, бывают погрешности (немного больше/немного меньше константного значения шага). Потому в целом можно не ебаться, но если тебе нужна бОльшая точность - лучше задействовать дельту в расчетах.
А ее так сложно использовать, что хочется забить? Обычно же она нужна как доп коэффициент в формулах всяких и все.
А в годо можно делать стратежки без графики, ну типа как в экселе?
А в экселе же таблица с ячейками - это же графика. Ты же меня обманываешь. Без графики - это в консольке.
В консольке такие чудеса вытворять можно - эксель позавидует.
Хочешь без графики - деды до появления мониторов печатали вывод на листках бумаги.
Так у меня пока игра в консольке. Хочу вот перейти на новый уровень
Да, а ввод на перфокартах. Что-то сразу захотелось запилить игру с эмуляцией всего этого. Ну, перфокарты можно камерой считывать
Невыносимо медленный при движении по таймеру.
Но можно ускорить.
Но отзывчивый при нажатии клавиш.
Без диагонального движения.
Со встроенным детектом самопересечений, стен, еды.
Создающий себе сегменты в реалтайме.
Ща как доделаю игру! Уххх, ща как доделаю!
Я думал спецолимпиада закончилась еще в прошлом треде. А в чем сложности то?
Если игрок нажмет кнопку турбо, вся физика посыпиться
олды сплакнут
Намечается новый холивар - дельта не нужна, дельта для слабых.
Сделайте плавную змейку, хватит долбится в тайлы. лол еще и через таймер
Это какая-то форма мазохизма? Что мешает с нейронкой слепить за пару часов? Ещё и сегменты не инстансишь.
Плавная змейека теряет ретрошарм. А так же смысл - гораздо проще избегать столкновений, если ты можешь маняврировать как угодно, а не только в четыре стороны. Это уже не змейка короче будет, а другая игра какаято. Алсо, хз как на твоем скрине на самом деле сделано, но на вид эти черви тоже сегментирорванные, просто кружочками для гибкости.
> Это какая-то форма мазохизма?
Саморазвитие - это больно. Саморазвитие легко спутать с мазохизмом, потому что и там больно и тут.
> Что мешает с нейронкой слепить за пару часов?
Потому что с нейронкой ты так и останешься неразвитым. Вместо тебя разовьётся нейронка.
> Ещё и сегменты не инстансишь.
Инстансиш.
Ты троллишь так? Троллишь ведь? Нафига ты туда эти Area2D лепишь? Чтоб процессор пользователя греть? Создавать ощущение бурной деятельности игры? Чтоб казалось, будто игра на фоне крипту майнит? Тебе уже скинули базовый код классической змейки, которая по клеточкам ходит, чем ты недоволен-то? Или ты хочешь сделать змейко-платформер, как сейчас модно стало?.. Тогда тебе нужно CharacterBody2D вместо Area2D, лол.
>>1084040
>Плавная змейека теряет ретрошарм
Тогда зачем ты обмазывался Area2D, ретрофил?
>>1084042
>Саморазвитие
Да ты ж наговнокодил просто. В чём саморазвитие?
>>1083997
>Зачем тогда там вообще дельта передается?
Для каких-нибудь строгих симуляций в мультиплеере. Физика может отставать, особенно если компьютер не вытягивает 60 FPS по процессору (не по видеокарте), поэтому установленные в настройках TPS физики не гарантируются. Почитай всплывающие подсказки в настройках проекта, касающиеся настроек физики. Тестируй игру с открытым профайлером или выводи информацию из API Performance на экран в игре...
>>1084014
>А в годо можно делать стратежки без графики
Можно, конечно. Можно использовать Control-ноды. Учитывай, правда, что Control-ноды рендерятся через кастомный OpenGL/Vulkan/DirectX/Metal-рендерер в зависимости от платформы и настроек проекта, а не встроенным в операционку набором виджетов, т.е. взаимодействие с ОС отличается от классического, и некоторые фичи, возможно, ещё не поддерживаются.
Вот тут о том, как юзать Godot для GUI приложений:
https://docs.godotengine.org/en/stable/tutorials/ui/creating_applications.html
Но учитывай, что, хотя 3D фишки можно вырезать из движка, 2D фишки пока что не так легко вырезаются. Поэтому сделать Godot максимально тонким трудно.
>Тогда зачем ты обмазывался Area2D, ретрофил?
Опять бля у шиза все голоса в один слились.
Я другой шиз, не путай нас.
>>1084048
>fix1 fix2 update123
Просто нужно фокусироваться на одной фиче/баге, не растекаясь по всему проекту хаотичными правками, и описывать тогда будет нечего.
А зачем тебе гит? Откатываешься часто?
> с нейронкой слепить
Нее... Нейронка пусть мне арт рисует. А прогать я сам буду.
>>1084043
Ты троллишь. Троллям - игнор.
>А зачем тебе гит? Откатываешься часто?
Я без гита впринципе даже тестовые заметки не веду. Не только профдеформация, но и жизнь в условиях умирающего ссд на протяжении пары лет. Хз как вы игры делаете без гита, лишняя хромосма помогает?
Ну а с нейронками это просто необходимо - это говно легкой рукой сметает к хуям хоть весь код в процессе, если надо. Поправит то, попробует там, и вот хуяк уже ихз рабочей версии полностью нерабочая - гитом откатить можно. Еще она и гит можно смести к хуям, да, как-то раз мне просто сделала гит резет хард на 10 коммитов назад, это правда восстанавливается, но так и поседеть можно, так что гитовать надо не только локально, но и на ремоты обязательно слать.
Ну и дляценителей, конечно же, относится в целом не к гиту именно, а к любым контролям версий, извращайтесь как хотите для тех же целей, хуле нет, хотя ручной бекап это пиздец, лол.
Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
Уж лучше бы тебе нейронка нормальный алгоритм сгенерировала, чем вот это вот говнокодерство. Специально для таких как ты костыли сделали.
>пусть мне арт рисует
Ага, и будет говнокод в красивом фантике.
>>1084057
>перед каждой фичей бекапить 5 гигов
У тебя 5 гигов кода? Или всё-таки арта? Арт не нужно бэкапить, когда с кодом работаешь. А код правится маленькими частями в отдельных папках...
Вообще, тоже подумываю подключить какую-нибудь подходящую VCS, но всё боюсь, что она сломается и поломает мне все файлы. А бэкапы пока ни разу не пригодились по сути, потому что я никогда назад не возвращаюсь из принципа. Если не идти вперёд, а возвращаться назад, то в чём тогда будет прогресс? Сохраняю бэкапы только на случай поломки диска.
>>1084068
>лишняя хромосма помогает?
>с нейронками это просто необходимо
Какая хромосома заставляет тебя юзать нейронки?
>полностью нерабочая - гитом откатить можно
Зачем откатывать то, что можно просто не ломать?
>хотя ручной бекап это пиздец, лол.
Зато никакая нейронка не влезет и не сломает, ибо архиватор древней версии и надёжен как часы. А гит наверняка уже заслопили мартышки из майкрософт.
>А гит наверняка уже заслопили мартышки из майкрософт.
Гит != гитхаб, балбес. Ну и юзай другие, их полно, раз гит вдруг стал майковским.
>Зато никакая нейронка не влезет и не сломает
Да она просто рм сделает под предлогом чистки мусора.
>Какая хромосома заставляет тебя юзать нейронки?
Дежурный луддит, добрый вечер, как на бересте пишется?
>Зачем откатывать то, что можно просто не ломать?
Нейронки не то чтобы именно ломают (разве что удаляют они почему-то слишком уж бездумно, наплевав на то, что могут и не восстановить уже), просто не все их высеры стоят того, чтобы их доводить до конца. После работы нейрослопа всегда надо старательно напильником обрабатывать, иногда проще откатываться, чем вникать в очевидный сгенерированный бред, даже если он рабочий. Для них это все равно быстро. Даже слишком. Собственно из-за скорости нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью.
Ну понятненько. Ты у нас и гит не признаешь, дьвольские технологии. И нейронки тоже. Луддит бинго? Че там дальше - отрицание 4к мониторов?
>для бекапа выковыривать только код тоже лень
В архиваторах можно настроить фильтры. Я просто исключил из архива все .png, .gltf и т.п. тяжести, что практически никогда не меняются, и в итоге бэкапы составляют всего несколько килобайт файлов, что изменились за сегодня (фильтр по времени). И это практически не занимает времени, всего 3-4 клика. Автоматически добавляется штамп времени и т.п. Перекатываться на кривоватый гит как-то лениво...
>>1084072
>раз гит вдруг стал майковским
Ну, не будешь же ты свой сервер арендовать...
>Да она просто рм сделает
Она-то сделает, но запустил её ты. Виновен ты.
>Дежурный луддит
Я не луддит, а как раз фанат ИИ технологий, и именно поэтому знаю, что нейронки на базе GPT используют тупейшие мартышки и скучающие лузеры по жизни, поскольку полагаться на этот чёрный ящик с мутной историей тренировки нельзя, а ТЕМ БОЛЕЕ запускать автономно на железе, которое тебе дорого и имеет собственный доступ в локальную сеть и интернет. Ты буквально добровольно запускаешь троянского коня.
>удаляют они почему-то слишком уж бездумно
Научились у зумеров с гита, у которых всё в облаке.
>нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью
Любишь играть в русскую рулетку как хобби?
>
> Можно, конечно. Можно использовать Control-ноды.
Спасибо, возможно это то, что нужно
Начинай в любом случае с базовых туториалов:
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.
>Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
Откуда инфа? Есть повод для волнения?
>>1084069
>чем вот это вот говнокодерство
>говнокод в красивом фантике
Ты чё быкуешь, сука, человек реально обучается методом проб и ошибок, щупает синтаксис языка, своими мозгами доходит до рабочих/нерабочих методик, а ты падла подсираешь, ещё и анонов в ридонли дизморалишь. Ты вообще понимаешь как устроен процесс обучения вещам у человека? Стянул бы еблет со своей говнокритикой лучше.
>реально обучается методом проб и ошибок
>как устроен процесс обучения вещам у человека?
Так он это здесь показывает так, как будто это что-то хорошее и нужно повторять. Если он хочет критики - замечательно, но он же сразу огрызается на советы, следовательно, критики он не ожидает. Тогда зачем?
Или ты считаешь, что юзать Area2D для игры, где все элементы - квадраты на квадратной сетке - это типа нормально? Ты считаешь, что ему следует держаться данного подхода и ни в коем случае нельзя делать замечаний, что так делать (в данном случае) вредно?
Ладно бы он хотел сделать что-то современное. Но он пытается скопировать классическую змейку. В ней уж точно никаких Area2D не было и быть не могло.
>Откуда инфа? Есть повод для волнения?
Да повод вполне обычный - у нас есть хуйня импортозамещенная. С крошечными лимитами на бесплатке. И принадлежащая тоже кому надо. И даже заботливо намекающая с главной же страницы "мигрируйте к нам с гитхаба, вот тут нажать".
Правда уже довольно давно, главное почва уже имеется, войну сервисам и с меньшей подготовкой объявляли.
А повод даже выдумывать не надо - на гитхабе куда не плюнь запрещенка.
Ладно, эт я чёт сорвался. Думаю для такой хуйни как змейка из трех с половиной нод, начинающий юзверь вполне может юзать ареа2д. Опять же, гораздо эффективнее и запоминабельнее будет себе стрельнуть в ногу в проекте покрупнее, и уже исходя из этого оптимизировать подход. Ну и его реакция тоже ясна: вместо критики обозвали говнокодом, подкинули невнятных объяснений, и дали ссылку на неоткрываемую без впн документацию.
Ну ладно, хули я тут языком чешу, ситуация-то штатная в любом коммьюнити, в любом обсуждении. Пойду лучше мусолить игру мечты.
У вас здесь какой то непрекращающийся змеиный перфоманс, интересно юнитеки из треда, хоть змейку смогут сделать без ассетов.
Моя первая змейка такая же была. Баженная. На спор сделал. Знал только массивы, циклы, функции, все такое, да классы прям понюхал тока тока, ни архитектур нихуя не знал и не умел, ни опыта.
Смотрю на этого змеееба тредовского и думаю смогу ли я сейчас без нейронок сделать змейку уже в годоте и чтоб охуенная была. лень проверять.
>Будут ли дальнейшие 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, просто хотел поизвращаться с компилятором и всё такое...
>гайд годный на выживач с мультиплеером
Зачем тебе отдельный гайд на выживач?
Для выживача ищи про:
- авторитарный мультиплеер для экшена/шутера;
- механики и контроллеры для обычного шутера;
- инвентарь, крафтинг и т.п. по твоему вкусу.
Потом просто слепишь всё вместе.
Спасибо за ссылку, не видел это в доках. Ахуеть конечно. С одной стороны я понимаю их (совсем чуть-чуть), а с другой, что это если не принуждение обновляться если хочется багфиксов? Еще и никто не отозвался насчет 4.5 и 4.6, неужели сидят все на 3.х ветке?
Все сидят на своих форках со свежайшей мастер ветки и своими изменениями исходников.
У них ежегодные опросы через гуглформы, из которых следует, что большинство сидит на самой актуальной версии движка, ещё немного сидит на последней 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, там часто обсуждают.
Проблема Икс у тебя в чём заключается?
Какую проблему ты пытаешься решить, редактируя дочерние элементы?
Зону спавна из collisionpolygon на главной сцене. В итоге я инстанцирую area2d со скриптом и в дочки ему создаю форму и там же её и правлю.
Так. Тебе нужна зона спавна. Ты хочешь самостоятельно выбирать зону спавна в редакторе. Я правильно понял?
> Зону спавна из collisionpolygon
Там есть нода просто Polygon2D, без привязки к коллиженам. Может тебе просто полигон нужен? Чтобы потом из него получать рандомную точку спавна?
Тебе это неважно. На твою разработку это никак не повлияет.
Типа как-то так.
без разницы, но коллижн как будто универсальнее. Там можно on_body_entered ловить.
Так бы сразу и говорил. То есть, зона спавна должна реагировать на вход тела (игрока) и спавнить предустановленную сцену?
Штош, бесплатные токены в клауде закончились, приходите завтра.
Я в итоге просто так сделал и забил пока. Понял что приоритет выше у других вещей.
И в итоге это самое правильное решение. То что зона вложена как сцена - не отменяет того факта что ей коллизию можно в дети пихануть снаружи, а не лезть в детей через редактирование каждый раз.
Я даже в каком-то старом туториале видал такой трюк, ещё на трёшке.
Зачем ты сохраняешь эту 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 в данной ситуации создавать не нужно.
Алсо, хочу заметить, что это - от непонимания сцен Godot:
>бредятина у годота с редактированием инстанцированных
>надо прожимать "редактировать дочерние элементы"
Механизм сцен Godot предполагает, что внутренние ноды сцены являются "деталями имплементации", то есть сохранение куска дерева как сцены - это что-то вроде инкапсуляции ООП объекта. Поэтому у тебя есть лёгкий доступ к свойствам корневой ноды - интерфейса сцены - и более сложный доступ к её внутренностям. Фича "редактировать дочерние ноды" - это анти-паттерн, который предусмотрен для быстрых костылей-заплаток, прототипов и тому подобного. Так что, если ты замечаешь, что ты вынужден слишком часто прибегать к этой функции, тебе следует пересмотреть то, как ты организуешь свои сцены. Кстати, механизм этот не совсем надёжный и внесённые изменения легко "слетают", если ты как-то поменяешь оригинальную сцену. Это могут поправить в новых версиях движка, но в целом лучше не полагаться на сохранность данных, введённых в режиме "редактирования дочерних нод" инстанса сцены.
Если да, то просто никогда ими не пользуйся.
Не все инструменты в движке нужно использовать просто потому что они там есть. Они могут быть неудачными, а убрать уже нельзя из-за обратной совместимости.
https://www.reddit.com/r/godot/comments/1m3ufb5/is_it_just_me_or_is_godots_scenes_inheritance/
Чтобы скрипт не лепить каждый раз очевидно.
> Попробуй как-то так (не проверял, пишу в поле ввода поста):
Задумку вроде понял, но не работает. Да и избыточно это.
Ну например для импортированных мешей я включаю редактирование дочерних нод чтобы выбрать меш и добавить коллизии, хитбоксы. Обычно при импорте корень сцены это просто node3d.
>не работает
Исправил ошибку - можешь попробовать снова, если хочешь.
>избыточно
Но это ускоряет работу, если нужно создавать много таких нод.
>>1084329
>для импортированных мешей
Если изменишь порядок/имена нод в исходном файле, то после повторного импорта 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
>>1084317
>просто никогда ими не пользуйся
Они не так уж и плохи в некоторых ситуациях, просто нужно знать нюансы (см. выше).
>убрать уже нельзя из-за обратной совместимости
>>1084432
>Самый момент был для выкидывания, если на то пошло.
"Inherited scene" существует благодаря "editable children" - их можно было получить через какие-то манипуляции с кодом сцены в файле tscn - кнопка создания "inherited scene" просто упрощает такую манипуляцию. Это важная фича системы сцен, отказаться от неё нельзя. Считайте это трюком уровня get_parent().get_parent().get_parent()... - движок позволяет так делать и никто не будет вырезать эту фичу в будущих версиях движка, потому что так работает дерево сцен и ничего с этим не поделать, но это не означает, что вы должны обмазывать все скрипты такими конструкциями. Пока "родитель" нескольких "дочерних" сцен никак не меняется (иерархия и имена узлов), всё должно быть в порядке. Проблема будет только если вы захотите изменить родителя - тогда дочерние сцены могут поломаться, утратив часть данных, закреплённых за изменёнными нодами. Повторюсь - это должны были решить UID у нод в сценах, но я не знаю, решили они это или нет.
ФПС упал сильно, в пике нагрузки уже меньше 200 фпс показывает. А было 500 изначально. В целом не страшно, ведь это значит, что у меня в запасе еще 140 свободных кадров, которые можно потратить.
Круто конечно, но вампырики-сурвалики уже всех заебали. Ты эти волны врагов никому не продашь.
Делай лучше метроидванию. Метроидвании всегда в цене. Хороших метроивданий мало. Сделаешь хорошо - заработаешь нормально.
>Ты эти волны врагов никому не продашь.
Не рекламы ради, я тут последние 3.5 недели дрочу мобильную гиперказуалку "Gear Defenders" - и она умудряется затягивать и по своей воле смотреть 2-3 десятка рекламных видео в день, лол. Геймплей на поверхности прост: ставишь эти "шестерёнки", а они спавнят юнитов, которые идут и бьют мобов... Если копнуть глубже, имея ограниченные ресурсы, место, неудобные препятствия и т.п., собрать успешную композицию не так-то просто. К сожалению, игра на высоких уровнях скатывается в "либо повезло, либо смотри рекламу ради какого-то шанса на победу". Поэтому, рекомендовать эту игру не могу - но с т.з. геймдизайна базовая формула весьма хороша. Мне захотелось сделать похожую игру или реализовать данную формулу геймплея в игре другого жанра.
Но там не так-то много юнитов - где-то до сотни. Интересно, что бой становится месивом, где трудно разобраться, кто кого атаковал и насколько сильно, поэтому становится тяжелее принимать решения на следующей волне. Т.е. огромное число юнитов не является здесь чем-то нужным или крутым, скорее раздражает, мешает анализировать ситуацию. Алсо, большинство юнитов тупят, не могут выбрать более подходящую цель (пример: всадник имеет сильное преимущество против лучников, но если даже он технически мог бы обежать защитников по дуге, он предпочтёт умирать об этих защитников, что бесит, особенно если это в чистом поле с 2 врагами).
Короче говоря, игра с толпой может быть довольно интересной и при этом простой, но нужно правильно организовать и не перегружать игру лишним числом, поскольку слишком большая толпа не нужна и лишь отвлекает или мешает анализу и планированию.
Относится ли пикрил к "survivor-like"? Вроде бы нет. Насколько я понимаю, это вариант tower defense с укороченной дорожкой и мобильными "башнями" (интересно, "башни" - это шестерёнки или юниты?). Конечно, есть ещё куча жанров, где толпа уместна...
>метроидванию
С точки зрения геймдизайна, это в первую очередь платформер, а платформер - это экшен с высокой зависимостью от точной реакции игрока. Так что это ограничивает целевую аудиторию, которая способна поиграть и получить удовольствие. К тому же, жанр метроидваний подразумевает большой уровень с регулярными походами туда-сюда через ловушки, и, следовательно, игровая сессия даже с чекпойнтами должна быть долгой (иначе игрок забудет, куда ему двигаться и зачем), что ещё сильнее ограничивает аудиторию даже в сравнении с платформерами.
А узкой аудитории сложнее угодить:
>Хороших метроидваний мало
Потому что даже в такой узкой ЦА есть свои мелкие категории игроков, которым нравится разное в этом специфичном жанре. Что одному - шедевр 10/10, то другому может совсем не доставлять удовольствия. Ошибиться с гиперказуалкой, очевидно, сложнее.
>Сделаешь хорошо - заработаешь нормально.
А сделает норм - убьёт лет 5 на ассеты, отладку и "полировку", которую оценят 3.5 ценителя и лишь 1.5 из них похлопают по плечу и скажут "малаца", а двое других обосрут с головы до ног по пустякам...
Я не предлагаю бежать делать гиперказуалки, нет. Гиперказуалки лезут по головам друг друга, сжигая бюджеты на рекламу, которого у вас всё равно нет. Впрочем, цена обосрамса невелика - пикрил даже с графикой и геймплеем можно сделать за неделю, наверное, останется только рекламу прикрутить и оформить страничку в маркете. А потом только наполнять контентом, если игра реально взлетит. Банально более разумное вложение, если волнует исключительно прибыль с игр, а не Игра Мечты.
>>1084488
>уже меньше 200 фпс показывает
Это ни о чём не говорит. Сколько юнитов в пике? А вариантов юнитов (уникальных)? И на каком железе тестируешь? По графикам смотришь или просто так следишь за циферками на экране? Цифры могут и сглаживаться по сравнению с реальной нагрузкой.
>у меня в запасе еще 140 свободных кадров
Во-первых, по-хорошему считают миллисекунды - стандартные 60 фпс это 16.6 мс примерно. Это типа "бюджет кадра". С этой метрикой проще работать - к примеру, если что-то требует для вычислений 20 мс, возможно размазать вычисления по 4 кадрам, и в результате у тебя будет только +5 мс нагрузки. А в абстрактной "частоте кадров" так не посчитаешь. Аналогично если можешь использовать потоки - ресурсоёмкий процесс на 20 мс на 1 потоке может сократиться до 5-6 мс на 4 потоках, что, опять же, не посчитаешь в абстрактных "кадрах в секунду".
Во-вторых, ты должен оптимизировать сильнее, не растрачивая все 16 мс на своём железе. Нет, если ориентируешься на консоли - там да, можешь 16 мс потратить и твоя игра 100% будет хорошо работать, поскольку у всех игроков одна и та же консоль (ну, теоретически должна быть одна и та же). Но на ПК столкнёшься с тем, что разное железо даже одной ценовой категории работает по-разному, фоновые процессы по-разному отъедают ресурсы компа, и банально перегрев и троттлинг могут сделать игру неиграбельной на "рекомендованном железе". На мобилках тебя ещё будут ругать за то, что телефон раскаляется и обжигает руки с тупой 2D графикой посильнее, чем с продвинутой 3D графикой, лол.
Короче, если хочешь дрочить на оптимизацию и максимальное число юнитов - дрочи правильно. Ориентируйся на хорошие игры, а не симуляторы троттлинга с кучей лишней мишуры на экране.
>Сколько юнитов в пике? А вариантов юнитов (уникальных)?
10К vs 10К.
Пока три класса разных, воин-маг-лучник.
В целом видюха тут не сильно важна, там микро объемы памяти потребляются, а вот проц важен. У меня i5 не самый свежий.
Понятно, что железо у всех разное, но я все равно потом всё буду под геймплей затачивать, там вряд ли так много юнитов нужно будет. Просто стресс-тест.
просто круто, хоть сам в вампайр не людлю, но старик или дов, где можно анигиллировать толпы врагов и стоять на горе из трупов, любо дорого.
Да это вообще не вампайрик, это скорее фрейворк на основе годота чисто, чтобы можно было делать огромные армии юнитов. Геймплей в этом плане можно потом додумать, важно, что юнитов много и это работает.
В прошлый раз разве не обсуждали что стоит делать что-то типа ShapeCast?
https://godotshaders.com/shader/improved-spom-with-outline-detection-and-self-shadowing/
https://www.youtube.com/watch?v=TUAyiCswYt4
>когда-то что-то такое прототипировал
Ага, нашёл свой код трёхлетней давности и немного причесал.
В общем, я сейчас поигрался и увидел следующие проблемы:
- игрок может взлететь на RigidBody3D словно Мюнхгаузен;
- RigidBody3D может продавить игрока сквозь/внутрь пола;
- трудно подобрать оптимальное расстояние/силу влияния.
Наверное, если повесить стопицот if-else, всё решаемо...
На движок такое вообще никак не влияет. Зря волновался.
>>1084537
>В прошлый раз
Это когда было? В 2023?
>делать что-то типа ShapeCast?
Мне внезапно захотелось "натуральное" поведение...
Но это не главное... Покажу целиком, когда/если сделаю.
Можно выжимку по поводу нового ассет стора? У меня без квн не открывает и я заебался юзать бесплатные прокси которые сдыхают через день
>>1084547
РиджидБади это самая пидаристическая хуета из всех Бади нод, что 2д что 3д. Сфера применения очень узкая походу, я их юзаю только для мелкой шняги типа гиблетов врагов/объектов.
>превью шейдеров
Оооо, перекатываю свой проект на эту версию.
Алсо, сделали раздельную загрузку export template.
>>1084622
>выжимку по поводу нового ассет стора
Пофиг на него, ничего особенно важного не было, платность ассетов не сделает их лучше/надёжнее. Отключил себе вкладку "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, это для тканей всяких. Насколько я понимаю, там всё намного сложнее и проблемнее, но сам я их никогда не трогал (только в блендере с симуляцией тканей возился немного, но там-то она не в реальном времени вычисляется).
Сделал на ригидбоди чуть ли не больше игр, чем на кинематичном. Мяч в футболе, игры типа боулинг/гольф/бильярд, где ты пуляешь шары, пара игр с контроллером аля ракета. Гоночки, как на аркадном варианте где машинка это иллюзия на шаре, так и простые, где vehiclebody - а он наследник rigidbody. Туда же авиасим, правда я подзабил, но там тоже подход через наследование от него и воздействующие СИЛЫ через аэродинамические поверхности (уже кто-то и аддон написал за меня, удобно). 3д платформер тоже ради эксперимента делал, там физика больше на астронавта внутри полой земли была, хотя можно было гравитацию и кинематику считать в скрипте.
Не благодари, готово 4 года назад.
https://github.com/jgillich/godot-snappy/tree/godot-3
У меня обратная ситуация, всю жизнь думал вот бы замутить свой бумер шутер, чтоб всё в тридэ и с модным стильным крэйзи грэфоуни.
Но вот пришла пора вкатываться в хэймдэв, разумеется с простого и понятного ДАЖЕ ДАУНУ годотля... Теперь третий месяц пыхчу над своими двадэшками понимая, что если и решусь пытать 3D, то буду месяцами полировать табуретки, как тот чел со вкусом очка.
>что если и решусь пытать 3D
А ты решись, там не всё так страшно. Но сначала конечно свой 2д проект доделай быстренько
>feature freeze.
Какой-то слегка проходной релиз в сравнении с предыдущими. Но может хоть не развалится ничего и не придется делать кучу 4.7.x версий. Может даже удастся спокойно переехать?
Пройдись по всем девблогам, там суммарно кучу уже напихали. Думаю больше чем в 4.6
Учитывая контекст вебм - скорее звучит как сарказм.
мимо
И 2д и 3д страшно, но страшно по своему. А код страшно по другому. Поэтому нечего бояться, надо просто выбрать в чем будешь прокачиваться, что больше лежит душе и вперед. Главное не лениться
В геймплейном плане роста особо нет, однако стиль и графика стала на пару уровней выше. Плюс впервые поработал над постановкой игры — понравилось. Хотел ещё поучаствовать в ludum dare, но оказывается он уже заканчивается, лол.
https://rouw-x.itch.io/miranda-vhs
>третий месяц пыхчу над своими двадэшками
Для освоения программирования 2D игры лучше, т.к. позволяют фокусироваться на геймплейном фундаменте игры без возни с матрицами, базисами и кватернионами, и векторные операции там проще представить в голове или по-быстрому набросать от руки. Но не бойся 3D математики - там всё через API делается и не так уж сложно запомнить основные правила, даже в документации есть туториалы. В плане разработки потенциально успешной игры 2D не проще 3D.
>решусь пытать 3D, то буду месяцами полировать табуретки
Тот анон просто все советы проигнорировал и дрочит на фотореализм, который объективно дольше делать, чем 3D стилизацию (наподобие современного лоуполи). Может, ему так комфортнее - когда делаешь простые hard surface объекты по заранее известному референсу, стараясь скопировать его, прогресс виден чётко и ясно - ты либо сделал табуретку, либо не сделал, никакой неопределённости нет, потому нет и дискомфорта от мысли "а не фигнёй ли ненужной я занимаюсь".
Если хочешь не тратить много времени на 3D, то забудь про реализм и делай лоуполи с простыми текстурами или вообще без текстур. Чтобы графика выглядела приятно, достаточно подобрать удачную цветовую палитру и следовать во всех своих ассетах одному и тому же набору правил, которые ты сам для себя определил или взял из подходящих тебе референсов. Можешь взять бесплатные наборы ассетов в стиле лоуполи, такие легче всего модифицировать под себя и дополнять чем-то своим.
ИМХО, ниша реалистичных 3D игр была переполнена лишними играми ещё лет 10-15 назад, и сейчас трудно с первого взгляда отличить ААА игру про кусты и камни и какого-то мужика в броне с автоматом от дешёвой ассетфлипной индюшки про те же кусты и камни и какого-то мужика в броне с автоматом. Нафига их вообще продолжают делать? Выйдите на улицу, потрогайте реальные кусты и камни, наденьте реальную броню и возьмите в руки реальный автомат... эээ... кхе-кхе...
Я б не отказался от игры где можно потрогать реалистичную траву. Но даже современные реалистичные движки не потянут то, что можно увидеть глазами просто отойдя в лес на 100 метров.
Прошелся. Да ну как-то не. В 4.6 были крутые IK и фичи для рендеринга, в 4.5 тоже фичи для рендеринга, UID. В 4.7 скорее мелкие QoL фишки, ну разве что прямоугольный свет прикольно и полезно.
А чего бы ты хотел в новой версии? Они вроде недавно жаловались на флуд слоповыми пулл-реквестами, которые трудно разбирать, из-за чего работа усложняется. Многие старые пулл-реквесты наверняка ещё недостаточно протестированы или вообще недоделаны.
Если хочешь больше фич - заходи в пулл-реквесты, тестируй их на своей сборке движка и отчитывайся там о найденных багах или проблемах. Так автору пулл-реквеста будет проще довести его до хорошего состояния и, возможно, его примут в движок раньше.
А я без претензий, в самом деле. Мне Годот очень нравится, люб-дорог, я даже несколько рад, что огромных фич в 4.7 нет. 4.5 и 4.6 не очень стабильные, 4.5 вроде подлатали, а 4.6 разваливается когда проект мигрировать пытаюсь, из-за анимаций. Если бы я чего и хотел, так это выход какой-нибудь ультимативной stable версии без багов и огрехов. Если включить мечтателя, то круто было бы заиметь систему террейна и стриминг как в UE. Знаю, что решения уже есть, но круто было бы иметь что-то унифицированное и работающее из коробки.
> выход какой-нибудь ультимативной stable версии без багов и огрехов
4.3
Я на ней продакшон продуцирую.
Да даже если через н-десятков лет человечество переедет на фулл-виар гейминг, то "тру реализм" не будет популярен у масс, скорее оставят как брейнденсы из киберпанка для ценителей.
Посуди сам, в трипл-квадрипл-эй играх трава, деревья, вода, закаты и рассветы - всё заточено чтоб быть eye-candy, чтоб выделялась слюна и хотелось там жить и фантазировать как этот шейдер мягкой шёлковой травы щекочет щёки под солнышком средь чиста поля.
А в реале что? Ну выйти в лесополосу можно, да, там обоссанная примятая трава, торчки ищут клады, гавной ваняет, клещи так и норовят лишить жизни если не в ту травинку присядешь. Короче экстрим для потенциального "человека будущего".
Мне потому лоу-поли графон даже ближе к "реальности" кажется, ну висят три травинки на кочке - так и в реале они такие же реденькие и неидеальные, а под ними та же говняная текстура земли в серо-буро-зеленых тонах. Всё как в реальной жизни!
У меня сейчас под рукой нет фото, вот пик из интернета чтобы понимать
С 4.3 до 4.5 и 4.6 оч много классного добавили. И кучу багофиксов и оптимизаций. Но 4.3 подозреваю где-то стабильнее, да.
Кто-нибудь помнит?
Я забыл...
Эх, превью только для fragment-шейдера работает, и только для строчек, присваивающих какое-то значение какой-то переменной. Но и то достаточно полезно будет, особенно для 2D эффектов.
Ещё заметил, что они опять дизайн консоли вывода изменили. Теперь кнопки снизу, на строчке фильтра/поиска, и консоль по умолчанию имеет очень мелкий размер, строчки 3 или 4 всего. Не пугайтесь, все функции вроде бы на месте, только положение кнопок непривычное.
Мне они пока не нужны, но я всё равно пощупал AreaLight3D. Вообще не понял смысла этой ноды - свет кажется почти неотличимым от SpotLight3D с шириной около 90 градусов. Какая-то разница заметна только на тенях - у Area тени более размытые по умолчанию и, внезапно, без артефактов. На демонстрационной сцене, видимо, установлены полигоны с высоким emission, а не только лишь AreaLight3D? Я-то думал, AreaLight3D сама создаст светящийся прямоугольник, а она невидимая... Впрочем, это точно как с другими лампочками: SpotLight3D не видно без меша-фонарика... В настройках ноды AreaLight3D позволяет установить текстуру, и она как-то вроде влияет на свет, но мне не удалось увидеть какой-то особой разницы с, например, круглым "фильтром" (использовал GradientTexture2D). Почему?.. Странная нода - вроде нужная, а вроде и нет...
Также заметил, что убрали кнопку быстрой смены рендерера из правого верхнего угла... Думаю, правильно сделали, т.к. всё равно перезапуск редактора требовался, и вряд ли кому-то нужно так часто переключать рендереры, если они не делают игру одновременно под несколько платформ.
Оптимизация отображения массивов в инспекторе - самая лучшая фича этой версии, лол. Наконец-то можно нормально видеть значения в массиве даже с узким инспектором, а не какие-то огрызки, ради просмотра которых инспектор приходилось очень сильно растягивать. И почему раньше не сделали...
Может быть, теперь анон сможет сделать световой меч
Ну потом, когда выйдет стейбл, покажу вам как с areaLight будет выглядеть. Но хз, меня и так пока устраивает, все равно это не подразумевалось как световые мечи
А я успел навайбкодить за полдня
Вот для такого невообразимого скота мы и делаем игры. Точнее вы делаете. А я ебал. Нахуй.
Что там было? Что-то плохое?
В настоящем киберпанке живём: все развлечения запрещены большим братом, но можно попросить электронный сверхразум, но он ничего не умеет...
>>1084572
>прямоугольные омнилайты
>>1084858
>сделать световой меч
Анон ошибся в посте, а вы не поняли?
AreaLight3D светит только в одну сторону. Для меча потребуется минимум 2, а то и 4, если он толстый. И материал с высоким emission по-прежнему нужен, поскольку без него источник света будет невидим. Единственный плюс - это мягкие тени без глюков. Пиксельный шейдер эти тени всё равно скукожит...
>>1084859
>когда выйдет стейбл
Да вроде уже сейчас неплохо работает...
Учитывай, что AreaLight3D - это для forward+, а для остальных хуже будет работать (я не проверял, но в документации ноды много каких-то ограничений). В пиксельном стиле вообще бессмысленно, имхо...
Там 3gp с кнопочной мобилки
А ты не пробовал через архив интернета смотреть?
я б написал еще несколько простых способов, но тут неуместно наверное
купи впску за 300 руб/мес и накати туда amnezia vpn
честно говоря не понял в чем суть такой острой реакции, возможно это просто бот который хуйней бампает треды
> не понял в чем суть такой острой реакции
Потому что ты такое же гыгыкающее быдло, как и аффтар этой дрисни. Ты искренне удивлён "а чё не так та, ёпта, нах?" До тебя даже не доходит, какое это омерзительное скотство.
Маэстро, спасибо что почтили нас своим визитом! Арию споете?
Спасибо, улыбнулся.
>за 300 руб/мес
Чтобы потом круглый день сидеть на этом ютубе и спонтанно кликать на каждую рекомендацию, потом очнуться в 18:00 утра следующего дня с кучей новых вкладок браузера, содержание которых не помнишь, мучаясь от обезвоживания, голода и бессонницы? И десятками гигабайт скачанной с ютуба порнухи...
>не понял в чем суть такой острой реакции
Ты запостил какие-то круги и написал "навайбкодил". Непонятно, что это означает? Ты попросил ChatGPT нарисовать тебе круги? И потом запостил сюда PNG? Странный пост. Хоть бы объяснил, чего ты хочешь. И непонятно ещё, зачем ты запостил это в ответ тому, который свою игру на итч опубликовал. Где смысл?
>>1084927
Завязывай с
>гыгыкающее быдло
>омерзительное скотство
Тред любви же, мы должны быть добрее ко всем.
> Спасибо, улыбнулся.
В треде любви и добра придётся относиться с пониманием к таким, кто улыбается с этого скотобожества.
Он увидел игру где непонятно что делать, какие то круги, палки, и запостил олдовый мем, такие вещи правда надо объяснять?
>>1084938
Вы уже спели арию?
Хватит одной виртуалки с одним дистрибутивом, чтобы собрать под разные дистрибутивы Линукса? Если на Hyper-V подниму Убунту, этого достаточно? А как с МакОС быть, например?
Да ты какой-то махровый илитарий застрявший в позапрошлом десятилетии. Ну либо школотрон-ситх возводящий всё в абсолют.
Зачем тебе под все платформы сразу?
Под веб и Android точно получится, под iOS - нет.
Под Linux можно через WSL. Дистрибутив не важен.
Про Mac без понятия, но это очень редкая система...
А для чего собираешь? Какой-то особый модуль?
>>1084950
И насколько это удлиняет загрузку игры?
А что ты делаешь при повторном запуске?
>>1084938
>кто улыбается с этого скотобожества
Ностальгия по временам ИК-портов в телефонах...
> Зачем тебе под все платформы сразу?
Так ведь лучше сбилдить под все возможные, разве нет? Так удобнее потенциальному игроку.
> А для чего собираешь? Какой-то особый модуль?
Вырезал ненужный мне функционал, оптимизировав размер, и прикрутил пару экстеншенов для удобства, да. Ничего особо сложного, но нужный шаг.
Попробуй github actions, они же собирают все билды, сам годот же там собирается вроде под все ОС. Если правильно понимаю, если ты сделаешь публичный форк - то бесплатно, а если приватная репа - сколько то раз в месяц, но часто тебе и не нужно.
Ну то есть вернулись к технике 3-й версии пятилетней давности с вращающимся под землей кубом.
https://github.com/Brandt-J/ShaderPrecompiler
https://godotengine.org/asset-library/asset/977
Жесть какая. Для двадэ тоже таким надо обмазываться? Вот я запилил шейдер дисторшена на сцену Explosion, собсно при каждом взрыве эта сцена инстанциируется. В целом вроде норм, но емнип сталкивался с микрофризом при первом взрыве после запуска игры. Это я трясунчик и мне показалось, или реал придётся вкатываться в этот костылинг?
Конечно. 2D, 3D шейдеры - это одно и то же где-то под капотом, отличия лишь во внешнем API, упрощающем некоторые операции. Не парься, шейдеры хранятся на компьютере игрока, и после первого запуска таких микрофризов не будет, если игрок не очистит кэш.
>>1084964
Я б предпочёл видеть, как игровой мир постепенно погружается вокруг игрового персонажа, чем ждать мучительно долгой загрузки, теряя интерес к игре...
>>1084957
>лучше сбилдить под все возможные
Wine есть и на линуксе, и на маке. А для мобилок и браузеров требуется мудрить с графикой и UI/UX, в противном случае неудобно/невозможно играть. Нативные билды - это хорошо, но не прям такая уж необходимость для каждой инди-поделки v.0.0.1.
>ненужный мне функционал
Сегодня ненужный, а завтра опять билдить...
>оптимизировав размер
Для десктопа это давно уже не имеет значения.
>прикрутил пару экстеншенов для удобства
Если они работают только в редакторе, и не имеют отношения к самой игре, то тебе нужен editor build, а шаблоны экспорта можешь юзать официальные. Кастомные шаблоны экспорта нужны только если используешь модули, меняющие работу движка в процессе геймплея или загрузки ресурсов.
Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты. А мне как раз темплейты нужно скомпилить, там такое не удастся сделать.
>>1084976
> Wine есть и на линуксе, и на маке
Тоже правда. Вообще я почитал, оказывается, не редкость ситуация, когда через Wine работает лучше, чем нативно. С чем связано - не знаю, но много такого встретил пока изучал. Пожалуй, действительно пока обойдусь одним билдом. Так и поддерживать легче, а на мобилки я лезть не планирую, там в одну сторону дорога...
> Можешь скриптом пройтись по списку сцен и динамически их подтянуть в кешинг рум.
Шейдеры - это ресурсы. Если хранить их отдельно файлами ты можешь пройтись чисто по шейдерам, не трогая сцены, а потом сцена, когда будет загружаться, она увидит, что её шейдеры уже загружены и возьмёт их. Потому что ресурсы - синглтон.
>Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты
Хз с чего ты это вхял. Там билдится все.
И правда. Видимо я не тот воркфлоу смотрел. Не дашь ссылку?
Спасибо. Действительно, я каким-то образом в другом источнике смотрел. Изучу вопрос с github actions.
Я когда разбирался, работало вроде так. Делал форк репы, вносил свои изменения. Когда в репу прилетает новый коммит, вызывается ребилд всего. Я у себя отключал ненужные платформы соответственно.
Можно переделать на какой то другой способ, чтобы запускать вручную, но мне было лень.
https://www.youtube.com/watch?v=HciqfEeUFSw
Если тебе интересно, на пикрилах результаты опроса пользователей Godot за 2020 и 2025 годы. Как видно, большинство работает на/таргетит Windows; Linux по популярности второй за счёт большей доступности; экспортируют на Mac больше, чем работают на нём (наверняка с помощью стандартных шаблонов).
>>1084992
>Потому что ресурсы - синглтон.
Это неправда, потому что их можно дублировать, и доступность ограничена локальностью. Тот факт, что загрузчик данных не делает повторных чтений, не превращает класс ресурса в "синглтон". По смыслу к синглтонам ближе всего static var/func, но это другое.
>увидит, что её шейдеры уже загружены
Для этого нужно где-то сохранить ссылку на ресурс. Отдельная от компиляции шейдеров тема, но тоже полезная, особенно касательно системы частиц - она микрофризи(т/ла) при каждом чтении с диска, т.е. рациональнее держать ссылку и не отпускать.
Если кому-то интересно, я недавно осознал, что нет необходимости выводить материалы и частицы в основном Viewport сцены и затем перекрывать его непрозрачной заслонкой. Можно использовать SubViewport, главное настроить его как-то так:
>size = Vector2i.ONE
- чтобы не было бесполезной нагрузки;
>render_target_update_mode = UPDATE_ALWAYS
- чтобы рендерилось без отображения;
>own_world_3d = true
- чтобы скрыть объекты от основного.
Дальше добавляем ноды:
>SubViewport
>_ Camera3D
>_ то, что рендерим
Созданную текстуру просто игнорируем.
Я не проверял пока, но такой подход должен быть эффективнее, чем основной вьюпорт. Если он вдруг откажется работать, попробуйте увеличить size до небольшого размера в степени двойки (x16, x32).
>>1085021
Пиши сразу описание видео и своё мнение.
А то твои ссылки на ютуб выглядят как спам...
Там, карочи, играешь за менеджера, в качестве оружия у тебя шина сигналов, на спине у тебя сидит синглтон и играет в змейку!
Тебе надо было на лудум даре с таким зайти побеждать, там как раз тема сингалы была
Там слишком крутые чуваки, я стремаюсь даже начинать там участвовать.
Ага, там была команда мидлов 10 человек.
Результат? "Мы не успели, игра совсем не готова".
>Ребят, а где можно посмотреть нормальную архитектуру игр на годот?
https://www.youtube.com/watch?v=xPLbrgEQLqA
Красивое показывают
1. Есть ли какие-либо автоматизированные инструменты для этого?
2. Какие подводные камни могут ожидать и как их обойти?
>1. Есть ли какие-либо автоматизированные инструменты для этого?
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/retargeting_3d_skeletons.html
Для Blender ищи аддон по "animation retargeting".
>2. Какие подводные камни могут ожидать и как их обойти?
Насколько я понимаю (не разобрался до конца):
1. Скелет должен иметь ту же структуру костей. Т.е. автоматически подстраивается только трансформ.
2. Анимации могут не подходить по смыслу/стилю - например, в оригинале чибик (как у тебя на скрине), а пытаешься натянуть на нормального => будет фигня.
3. Если твой персонаж имеет дополнительные фичи, придётся возиться с комбинированием анимаций в AnimationTree... Я так делал только из одного файла, понятия не имею, можно ли из разных источников.
Из моего опыта: сделать новую анимацию на готовом персонаже с правильным скелетом - несложно, нужно только учитывать принципы анимации и знать, что ты пытаешься изобразить (найти референсы, если надо). Заригать персонажа - вот это геморрой ещё тот, т.к. замечаешься править косяки через weight painting.
Т.е. не бойся анимировать своими руками, если не получится взять готовое, а риггинг уже сделан. Для упрощённого чибика риггинг вроде бы несложный.
> 1. Есть ли какие-либо автоматизированные инструменты для этого?
Тебе не нужен никакой инструмент. Если ты используешь тот же скелет, то анимации будут работать. Анимации привязываются непосредственно к скелету, к костям, а не к мешам (3D модели). Тебе нужно будет привязать саму модель к скелету, настроить коэффициенты весов. Изучай такие понятия как skinning, weight painting. Процесс переноса анимаций с одного скелета на другой называется ретаргентингом (retargeting), но это не тот случай.
> 2. Какие подводные камни могут ожидать и как их обойти?
В целом никаких, разве что ты ограничен существующим скелетом и особо отличную по пропорциям модель ты не сделаешь. Это будет скорее рескин/надстройка над существующим персонажем, чем что-то концептуально новое. Также это легко обнаруживается, так что лучше посмотри на лицензию в gdquest паке, чтобы не попасть в просак по авторским правам.
>2
Кста! Road to Vostok обсуждали уже? Как он на годоте себя чувствует? А то я без видимокарты сейчас, не проверить. Помню, когда он еще был на юнити, он был ужасен, но это была совсем ранняя версия.
Что-то обсуждали в прошлом треде: >>1083265 →
Критику можешь почитать в движкосрач-треде...
Собсна обсуждать-то тут нечего. Вышел и вышел.
>кто подгаживает
Эм, кто? Я не слежу за трендами...
Они там против игры или против движка?
Кто-кто, шизик из движкосрач-треда, создал 460 акков в стиме, пишет что годот хуёво работает с 300 пустыми скриптами на сишарпе.
Я не делал замеров на эту тему, но факт в том, что объявление пустого _process(delta: float) в скриптах на GDScript может снижать производительность, если использовать этот скрипт на множестве нод.
Учитывая то, что C# компилируется в отдельную динамическую библиотеку, вполне возможно, что обращения к _process и аналогичным функциям даже дороже, чем обращения к пустым _process GDScript.
Я не знаю, какой там шаблон скрипта на C#, но для GDScript Godot по умолчанию предлагает скрипт с объявленными _ready и _process, что, в большинстве случаев, вообще не нужны конкретному скрипту.
Итого, если тот движкосрачер взял "пустой" шаблон и размножил его много раз, а потом через профайлер замерял затраты на обращения - да, возможно, он в действительности наткнулся на этот "недостаток".
Но реальность такова, что тебе не нужно 300 _process, особенно на стороне C#. Обычно твой код реактивен - отвечает на события и бездействует между ответами, поэтому _process не нужен. А C# как числодробилка...
> большинстве случаев, вообще не нужны конкретному скрипту.
Если скрипту не нужен process, зачем вообще такой ноде скрипт? Переменные хранить? Разве не логичнее тогда использовать ресурс? Или вообще завести в родительском скрипте массивчик под данные.
Ты совсем новичок что ли?
На вот, почитай про базовую архитектуру:
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д рпж рогалика пересаживаться с 4.3 версии на актуальную? (4.7 или какая там), а то ваще не слежу че там и как
Делаем змейку с физоном.
Так и я о том же. Если в игре будет 100 лампочек, то не надо клонировать 100 нод с 100 скриптами с пустым process, а надо просто завести один менеджер лампочек, в нем, в единственном экземпляре, будет единственный скрипт обработчик событий, который будет последним аргументом получать, какая именно лампочка послала событие...
В 3-ке имя кнопки можно было передавать последним аргументом
connect("pressed", self, "_on_button_pressed", [node.name])
В 4-ке
connect("pressed", _on_button_pressed.bind(button.name)
Если планируются домики, советую потестить тени в плотной застройке. Давно делал такое в 3-ке, но там было неприятное дрожание теней, еще по разному выходили тени отброшенные на вертикальную и горизонтальную поверхность (например, стену и дорогу). Читал про продвинутые техники (интерполировать тени между двумя кадрами с разным углом солнца), но забил.
> для GDScript Godot по умолчанию предлагает скрипт с объявленными _ready и _process
Просто выбираешь пустой шаблон при создании скрипта, готово
Как нуб могу посоветовать налепить на врагов RayCast2D и проверять коллизию в _process каждые кадров 5 (чтоб проц не взорвался) через is_colliding или is_on_wall, вот что-то из этого.
а разводы от дождя ты как сделал? Типа на определенной высоте спавнишь декали и удаляешь?
Да вроде бы норм работают тени из коробки.
>>1085575
Дождь я делал по этому видосу:
https://www.youtube.com/watch?v=cZ5Ang_Ji8E
Если вкратце, то следы от дождя это отдельные партиклсы, которые настроены как сабэмиттер дождя и спавнятся, когда дождь коллизится с поверхностью.
>Так я и думал, что ответ будет - "нинужно"
Ну так реально нинужно, в юнити есть аналогичная проблема с количеством скриптов, просто апи лучше прописано и пропуки начинаются не на 300 нодах, а на 3000, сути проблемы это не меняет - вызов с# метода дорогой и с этим нихуя не сделать. Для большинства случаев это терпимо
Во-первых, при каких таких обстоятельствах вообще может понадобиться сохранить не пользовательский файл в рантайме, неужели нельзя все те же данные положить просто в переменную?
Во-вторых, не забывай про многопользовательские системы. Если ребёнок играет у меня на компе, он это делает в своём профиле и не засирает мне стим своими фнафами. Софту не позволяется срать временными файлами, значимыми лишь для одного юзера, в общесистемные папки.
В-третьих, если сохраняешь временный файл, будь добр подчисть за собой в любом случае, не полагайся на системные механизмы.
Какой-то финн делает игру с явно русским названием и каким-то постсоветским сеттингом. Приходят фанаты сталкера и таркова, начинают вонять. Я не утверждаю стопроцентно, что всё так, просто предполагаю.
>>1085485
>Если скрипту не нужен process, зачем вообще такой ноде скрипт?
Вообще, есть много других встроенных коллбэков. Срабатывать кажды кадр нужно только всяким подвижным хуйням типа персонажей. Всем остальным надо в основном отзываться на сигналы: получать дамаг, откликаться на пересечение ареи - всякое такое.
>>1085571
>ответ будет - "нинужно"
Ответ на что? Промотай ветку, там вопрос был вообще о другом.
В доках есть OS::get_temp_dir() и FileAccess::create_temp(), не?
Ты проверял бенчмарком что в годоте на 300 объектах будет какое то заметное замедление, или это просто вброс в движкосрач треде?
Это проверяли пользователи движка. Все подтверждено нотариально заверенными issues.
Окей, я уже уходил, но специально вернулся домой.
Первый пик - фепесы с работающим вхолостую process
Второй пик - фепесы с удаленным process
Разница около 5%
Такая же проверка с 3000 объектами
Разница около 20% (2200 фпс против 1800 фпс)
Итого, игры с 3000 объектами можно делать без какой то особой оптимизации, вообще не заметите проблем. Насмехайтесь над теми, кто пишет про 300 объектов.
30000, так и быть, уже начинайте оптимизировать. Там 300 фпс против 150 с наивным подходом, с логикой можно улететь, ужас, до 60 фпс.
ты не то проверял https://github.com/godotengine/godot/issues/115960
Я не пользуюсь C# и другим не рекомендую. Если тебе надо проверять C# - проверяй сам.
мне не надо. просто ты потратил время на проверку, которая ничего не доказывает
Я проверил, что у годота нет проблем с 3000 объектов.
Собственно, по твоей ссылке у чувака 10000 объектов дает 200+ фпс, чего достаточно для игры.
Раньше не имел опыта перевода игр на годоте.
Имеются вот такие файлы с пиков, так понимаю сам годот их пакует?
Што там за NSFW игра такая?
По теме - https://github.com/GDRETools/gdsdecomp
Благодарю, потыкаю.
Обычная хентай игра, ничего такого. Можно в настройках выключить хентай элементы и играть как в обычный файтинг.
> Лампочка должна отреагировать на нажатие кнопки единоразово, то есть у неё есть какой обработчик:
Я вам даже больше скажу, такие штуки как visible вынесены сеттерами в АПИ ноды, и вышеописанный код можно вовсе не создавать, а настроить через инспектор коннекты к сигналам.
Но, разумеется, так можно настроить только очень примитивные штуки, типа переключения видимости.
Вот так этот коннект запишется в tscn файл:
> [connection signal="toggled" from="Button" to="Icon" method="set_visible"]
Делай меши толще, с пересечениями между собой. Поправь shadow bias. Включи contact shadows
Ты поставил смысловую ловушку. Теперь, если я повторю, ты уличишь меня в том, что у меня обозначенная на пикче проблема. Правда, ты не учел, что одного признака недостаточно для постановки диагноза. А еще ты не специалист, чтобы делать такие выводы, они сложны. Можно легко запутаться, и ты уже запутался.
Так что сказать-то хотел? Чего триггеришься, столько наподчеркивал, старался, время тратил. Ты охотишься на шизов в этом треде, у тебя тут поляна?
Свиндот.
Будут. На каждую. Больше нет нужды задавать этот вопрос.
Кто-нибудь тут может объяснить, почему эта игра так... стрёмно выглядит? Не в обиду автору(ше), игра вроде хорошая, но визуально выбивается из современных в нехорошем смысле. Будто бы чего-то не хватает, но не понятно, чего. Это из-за чисто чёрных теней? Или там источники света какие-то не такие? Они вообще есть? Можете пощупать демку, но я чисто по скриншотам и трейлеру сужу... Видел на реддит несколько раз за последний год или два. Имхо, у этого разработчика проблема с цветовосприятием. Жалко его/её...
https://steamdb.info/app/3689220/screenshots/
Да, вроде в старых тредах обсуждали, не помню уже.
Грязные цвета - основная причина, я считаю. Автор вообще не заморачивался. Если ты знаешь что ты не можешь в теорию цветов и в палитры, возьми готовые палитры и не заставляй людей страдать.
Ну и сверху можно было бы накинуть пару эффектов через World Env хотя бы.
Норм цвета, стилизация под Симс 2.
Анимации правда слишком деревянные, и музыка тошнотная, но графоний в статике в целом норм.
inb4: "у тебя проблемы с цветовосприятием"
Хз, наоборот заебала эта пастельная хуетень как из хипстерских фильтров инстаграмма 2012. Прусь от стандартной ms-paint палитры с твёрдыми как мой кал цветами.
>Автор вообще не заморачивался.
Нет, в том-то и дело, что он заморочился:
https://reddit.com/r/godot/comments/1kuf8jj/
>Грязные цвета - основная причина
...стоп, может там Tonemap неправильный?.. Вот точно помню, что некоторые варианты делают всю картинку серовато-грязной на нормальном (SDR) мониторе. На продвинутом (HDR) мониторе, может, эффект другой, однако, таких мониторов вроде бы всё ещё мало.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#tonemap
>>1085763 >>1085765
>стилизация
Для широкой ЦА нужна более сочная графика, в особенности с учетом сеттинга "светлое будущее". Пастельность или нет - это тут не касается никак.
...Да даже, вон, в DRG - мрачные пещеры - всё ярко и насыщенно, хотя игроку нужно буквально рыться в инопланетной грязи и говне. Так что стилизация не соответствует ни широкой ЦА, ни сеттингу игры.
В общем, жаль автора. Даже хотелось ему помочь... Наверное, можно попробовать распаковать демку и поковыряться в настройках Environment? Если там стандартный проект на GDScript, должно собраться.
>он заморочился
>Сделал динамическую смену времени суток
Ты молодец, для прототипа замечательно, но у тебя основной-то геймплей игры есть? А то так можешь закопаться в тонкие настройки, добиваясь идеальной погоды, а к основной работе над игрой так и не дойти.
На будущее, во время дождливой погоды (особенно штормовой) рекомендую изменять дальность fog в настройках Environment, чтобы ландшафт и объекты вдалеке от камеры были более серыми. Тогда будет реалистичнее выглядеть без лишних частиц.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
>>1085648
>Единственная проблема со светом и тенями
Документацию читал? Там всё с примерами:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#shadow-mapping
Но тебе пока рано фиксить такие косяки. Сначала разработай геймплей, потом определись со стилем графики, сделай несколько моделей в этом стиле. И только тогда будешь разбираться с тенями. Сделать нормально возможно, но всё зависит от моделей и расстановки, зависящих от желаемого геймплея.
>на процедурных уровнях
>NavigationRegion2D запекается динамически
А ты уверен, что правильно настраиваешь его? В документации сказано, что недостаточно просто накладывать ноды для объединения в одну.
>Болванчики тупят у острых углов (игра построена на тайлах, соотв. стены и углы тоже квадратные)
Если вся игра тайлах и имеет много узких ходов, я бы на твоём месте использовал простой AStar:
https://docs.godotengine.org/en/stable/classes/class_astargrid2d.html
Двигая врагов по клеточкам вручную (без физики).
Для больших пустых площадей и, в целом, очень больших карт желательны чанковые оптимизации.
Если игра - экшн-шутер, то можно использовать комбинированное решение AStar + raycast. Т.е. когда противник видит игрока, он просто идёт по прямой, в противном случае ищет путь через лабиринт.
>>1085498
>есть ли смысл для пиксельного 2д рпж рогалика пересаживаться с 4.3 версии на актуальную?
Имеет, там много разных фиксов и оптимизаций, касающихся любых игр. Версии 4.3 и 4.4 уже не поддерживаются, т.е. не получают багфиксов. По рекомендациям разрабов Godot, до выхода 5 всем желательно обновляться до актуальной версии. Копипастишь папку проекта, открываешь копию в следующей версии, и в 99% случаев проблем нет. Рекомендую удалить шейдеры из папки .godot, они зачастую заново компилируются новой версией.
Нет, он делает правильно, что делает прототип - вертикальный срез и сразу увидит какие технические ограничения может упереться. Причем даже если он не будет делать эту игру, такие знания помогут для более мелких игр.
>>1085648
Light leak / bleeding довольно распространенный вопрос про Godot, и четкого ответа с решением проблемы я никогда не видел. Некоторые советуют
-использовать системы SDFGI/VoxelGI/пробы, но мы знаем что они тяжелые по производительности;
-включать тени на источниках света, (у него уже включено на Directional; но надо помнить, что если будут дополнительные фонари, надо проверять, их range например);
-тюнить bias и прочие параметры. Ну тут надо просто перебрать много комбинаций. И может оказаться, что поправив в одной ситуации, портится в другой. Я даже думал понатыкать разных зон, по аналогии с гравитацией, которые будут переключать параметры теней при перемещении по открытому миру.
-отключать источник солнца внутри комнаты - плохой вариант, когда видишь через дверь/окно;
-запекать свет - вариант только для камерных игр, а не открытого мира; возможно с каким то сложным техническим решением, смешивать запеченный свет с динамическим... не видел готового аддона; тут не просто, если домик можно ставить под разными углами или есть упомянутая смена дня и ночи ну и в принципе запекание света меня никогда не устроило, хоть его и переписали три раза.
-Как уже упомянули в треде, делать стены толстыми, в метр толщиной, а не плоскостью из бумаги; тут есть понятная проблема, известная для опенворлда, что домик внутри должен быть такого же размера как и снаружи - в старых играх то просто подгружались огромные хоромы, которые больше чем занимаемое место на карте.
--один из приемов, который вспоминается - можно сделать объект БОЛЬШЕ, чем нужно, и сделать его невидимым, но shadow caster-ом.
-Может быть, можно придумать что-то с визуальными слоями. Я пока не придумал. У источника света есть Cull Mask, который указывает, на какой визуальный слой VisualInstance3D он светит, и соответственно бросает тень.
-Можно поиграться с размером алтасов тени. Но, конечно, большой атлас требует в разы больше памяти видяхи. Тут я так и не понял, как это проверить, является ли атлас screen space или нет, иными словами, важен ли размер 3д мира. Если важен, то может помочь чанкинг, ну то есть отключение дальних участков, которые не видны или тень на которых не имеет значения.
Перечитывая форумы, я вспомнил еще про такой эффект как texture uv bleeding
На пальцах сложно объяснить, ну в общем видяха же окруляет там все, и может при рисовании залезть в соседние пиксели текстуры, то есть желательно растаскивать грани по "островкам" с пустотами для безопасности между ними.
Еще один чел написал:
the thing I found that worked honestly was turning the world environment pure black and getting rid of the light from my skybox.
А ещё можно разрезы развёртки уложить максимально в дальние углы модельки.
>делает прототип - вертикальный срез
Это не то. "Vertical slice" - это когда ты делаешь часть игры на самом высшем качестве исполнения, но в небольшом количестве. Например: в твоей игре должно быть 100 видов противников? Сделай 2 в самом лучшем качестве, например, мечника и лучника, а остальных 98 отложи на потом. В игре должна быть карта размером 15x15 километров? Сделай участок 150x150 метров в лучшем качестве, а остальное отложи на потом. Планируется 20 видов погоды? Сделай 1 вид погоды в лучшем качестве, а остальные отложи на потом. Объедини всё это в играбельную демку, которую сможешь показать людям, чтобы они получили представление о том, какой будет игра в будущем (даже если пока что 99% контента игры не существует).
>четкого ответа с решением проблемы я никогда не видел
У него там буквально тоненькая коробка, совершенно пустая внутри, и он умудрился разглядеть тоненькую полоску света в абсолютной тьме. Если сделать нормальную модель дома, обставить предметами внутри, добавить источники света - эта мелкая полоска будет совсем незаметной, если не искать её специально. А вот ЕСЛИ она будет бросаться в глаза - тогда можно будет просто заделать щель, например, с помощью невидимого shadow mesh, который появляется снаружи дома, когда игрок заходит внутрь дома. Но это нужно делать с финальной графикой и в конкретных случаях индивидуально, а не когда у тебя только примитивный кубик с текстурой досок и кромешная тьма внутри.
https://www.reddit.com/r/godot/comments/1suniye/godotcon_out_of_context/
Там кстати первая бета 4.7 вышла. Подготовил вам пост с чейджлогом, а с компа его не запостить - бан, который мне лень вилкой вычищать. Сами квны включайте и смотрите. Вахтеры с айкью хлебушка.
ОЧЕВИДНАЯ_ПРОВОКАЦИЯ.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% могут это сделать, просто ленятся.
Ты буквально пишешь "все перечисленное в одну демку", то есть ты правильно понимаешь смысл вертикального среза, но при этом в упор не видишь, что он именно это и сделал - добавил один домик в открытый мир, и сразу сталкивается с проблемой, что или надо ее решать, или не добавлять домики/пещеры из-за того, что сложно настроить exterior/interior освещение. В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
Вытащил как мог, поставлю на сплешскрин своей игры
>то есть ты правильно понимаешь смысл вертикального среза
А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п. Чтобы они посмотрели на твой домик и сказали:
>вах какой разработчег, какой домек зделал, нужно дать ему миллион долларов, чтобы он нам запилил ещё несколько сотен таких же домеков, тогда мы с этой игры поимеем сотню миллионов долларов или больше
Что можно сказать, посмотрев на его видео? Что он натянул текстуру досок на CSGBox3D и воткнул на случайный террейн из бесплатных плагинов (скорее всего). То, что систему погоды сделал - молодец, но в ней ничего сверхсложного нет, и на игру в конечном итоге она мало как повлияет. Так что это не вертикальный срез его игры, а сырой прототип на куче плейсхолдеров, слепленных на скорую руку. А ты раздуваешь из этого драму, будто теперь он не может сделать игру мечты, ведь у него в абсолютно тёмной коробке видно тонкую полоску света. С такими коробками вообще безразлично, что там где видно...
>добавил один домик в открытый мир, и сразу сталкивается с проблемой
Не "домик" в "открытый мир", а пустую коробку на почти пустую сцену. И не с "проблемой", а с особенностью технологии shadow mapping, которую нужно будет держать в уме, но которой не нужно бояться. Эта особенность есть во всех играх с shadow mapping, то есть практически во всех 3D играх (единственная альтернатива умерла где-то в нулевых, ничего нового пока не придумали). С ней можно справиться, если это необходимо, но - опять же - а необходимо ли? Ни игры, ни ассетов нет, а "проблема" - есть?
>В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
Если он в соло решил сделать убийцу ААА-игры без покупки готовых ассетов высокого качества - тогда да, у него может уйти несколько месяцев на один качественный домик, который будет выглядеть достойно вертикального среза игры с открытым миром с реалистичной графикой (может пойти просить деньги у издателя с этим домиком). Но не обязательно выкидывать домик, можно выкинуть открытый мир и сделать игру про домик, если тебя НАСТОЛЬКО беспокоит протекающий между брёвнами/досками/плитами свет. Или перейти на другой движок, если тебя этот не устраивает - с готовыми ассетами это будет легко, ведь ассеты ты делал в другой программе. Пока нет ни ассетов, ни какой-либо игры, такие нюансы технологии не имеют никакого значения.
Я предполагаю, что свет протекает из-за того, что чем дальше объект от камеры, тем меньшее разрешение у карты теней (shadow map), поэтому "пиксели тени" становятся крупнее и происходит такое "протекание". Если необходимо - карту теней можно в настройках проекта увеличить и изменить пропорции так, чтобы вдалеке тень была более высокого качества. Но необходимо ли? Я даже в ААА играх видел очень кривые тени, которые приходилось отключать для экономии VRAM. Если условный Rockstar не смог в тени, то чего вы хотите от очередной инди-игры на бесплатном опенсурс движке... Адекватные игроки это понимают. Только чтобы игрок заметил твою игру, тебе нужен либо геймплей, либо ассеты, а не просто кубики с тенями на пустой сцене.
>А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п.
Ну это твое мнение. Вертикальный срез делается для разработчика, чтобы узнать что все работает и реально доделать.
Даже так можно объяснить - на первом этапе то соло инди разработчик и является "потенциальным игроком", то есть ему должно самому нравится, так и "инвестором", поскольку ему надо решить, будет ли он дальше инвестировать свое время и ресурсы.
Я вообще не понимаю, с чем ты споришь, поскольку дальше ты буквально подтверждаешь мою точку зрения, что это и надо сделать, чтобы проверить что надо менять или переходить на другие технологии.
Я тоже не понимаю, с чем ты споришь. У него пока не вертикальный срез (судя по видео), и кривое освещение на кубиках не имеет отношения к вертикальному срезу ни в плане геймплея, ни в плане визуального качества (может только немного). То, что свет может протекать, было давно известно и можно было найти много раз на форумах. Кому надо - находят способ замаскировать. Ему же пока явно не надо - поэтому я и предлагаю заниматься более актуальными вещами в его проекте, чем тени или даже погода. Пока он будет делать свою убийцу ААА игры в соло, уже выйдет 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.
Может, кому-то запомнится твоя игра только потому, что свет в помещения протекает забавно...
Я спорю с тем, что ты начал писать автору, что он неправильно делает что проверяет настройки света, и ему надо бросать и бежать делать всю остальную игру, модельки, а потом уже настраивать свет (и видимо в этот момент узнать что свет протекает).
https://diskonavt.itch.io/deadwing-demo
Залипательно. Сыграл аж три катки по 30 секунд, минуте, и полторы минуты, лол.
>перед уёбыванием в армейку
Ты случаем не тот оп-разраб Обсурити?
нет, это вообще мой первый проект на годот, который зашёл дальше уровня "открыть движок и повтыкать в интерфейс"
оптимист по поводу того, что чекну фидбэк или по поводу того, что вернусь из армии?
второе. береги себя и глупостей не делай, хотя лучше всего было не идти
>неправильно делает что проверяет настройки света
Нет, он неправильно делает, что беспокоится об этой настройке на таком раннем этапе разработки игры. Проблема известная, но фиксится по ситуации.
Если беспокоиться о ней с самого начала:
1. Кинул куб CSGBox3D с текстурой досок на сцену - забеспокоился о протекающем свете - несколько дней крутил настройки, пока не добился идеально ровного освещения простого куба с текстурой досок.
2. Решил, что ему будет нужен "перекошенный дом" и повернул свой куб с текстурой досок - свет начинает протекать снова - опять несколько дней крутил его настройски, пока не добился идального света в перекошенном кубе, но сломал в нормальном...
3. Спустя недели добился идеального света на своих кубиках, и пришла пора делать нормальные модели - внезапно у нормальных моделей другая геометрия и взаимодействие с системой светотени отличается - необходимы другие настройки - придётся минимум несколько дней перенастраивать на новые модели.
4. Через полгода его скилл в 3D поднялся и пора бы обновить самые первые модели - снова геометрия отличается - снова менять настройки светотени...
Это очень сильно демотивирует - когда ты потратил огромную кучу времени на то, что оказалось совсем ненужным в будущем. Проще с самого начала эту "проблему" игнорировать, а потом заделать дырки в финальной графике, которая уже не из кубиков...
Так вот именно так делать и надо - поставить домик, покрутить настройки, добавить другой домик под другим углом, покрутить настройки, и примерно тут и станет заметно, что есть проблема, что так не получится просто накидывать домики. Тут нужно общее, системное решение, для всей игры, а не какие то ручные "фиксы по ситуации". Поэтому такие исследования и надо делать в самый ранний момент, и например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи, или пилить таки универсальную систему, а в твоем варианте будет потрачено несколько месяцев на игру, а потом выяснится, что настроить свет по ситуации станет невозможно.
>Тут нужно общее, системное решение
Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной? Они ясно говорят в документации: если какое-то решение будет полезно 99% пользователям движка (в данном случае имеем в виду 99% 3D игр), то оно должно быть в официальных сборках; если что-то полезно только 1% пользователей, оно отлетает в аддоны/модули. Если решения не существует, то его нигде не будет - или ты думаешь, за 10+ лет существования движка не нашли способа портировать решение с движков 30+ летней давности? Сам принцип освещения придуман в 1978.
>например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи
Хватит троллить. С этим настроем можно целиком от разработки игр отказаться, оптимизировав затраты - "разрабатывать игры сложно, поэтому не буду их разрабатывать - буду просто играть в готовое". Если человеку захотелось свою игру, он, очевидно, хочет разработать её любым способом, а не выкинуть из задуманного 99% из-за того, что "свет протекает" (совершенная мелочь, которую поди заметь ещё).
>настроить свет по ситуации станет невозможно
Всё возможно, просто нужны костыли в отдельных ситуациях. Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо. Заделывать заплатками тестовый кубик НЕ НУЖНО.
Игровой движок - это инструмент для работы, а игра формируется определённым видением автора, и от инструментов требуется реализовать это видение, не прируждая менять видение под нюансы инструмента. Костылями или универсально - не важно, важно лишь соответствовать задуманному. Если он задумал себе опенворлд с системой дня и ночи с домиками - окей, задуманное вполне реализуемо, хоть и с костылями, которые даже в ААА вынуждены применять. Главное следовать собственной задумке и не отвлекаться на пустяковые мелочи вроде "протекающего света" (на минимальных настройках графики он и в ААА течёт).
>Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо.
Это не вариант во многих случаях - создающиеся генерацией миры, опенворлд в городе где дома могут стоять под любыми углами, смена дня и ночи, где направленный свет проходит плавно 360 градусов.
>Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной?
Она и так всегда недоделанная, а если говорить корректнее, то есть разные вводные условия, в которых она может работать, а в других не работать.
Когда я говорю про решения, то это не обязательно ядро движка. Многие вещи решены разрабами игр в виде простых правил (например, как какой то список настроек), какие-то - аддонами, как в случае террейна.
Невероятно! Оказывается, что если ты строишь не шалаш из веток на одну ночь, а небоскреб на сотню лет, то надо немного подумать и посчитать заранее!
Вот у меня есть, например, один настроенный StandardMaterial3D или шейдер для деревьев. И штук 10 текстур деревьев, и, может, еще 1-2 параметра материала, которые будут меняться от дерева к дереву. Мне что, делать 10 уникальных материалов ради изменения 1-3 параметров? Хранить их прямо в сцене, или вообще сохранять все 10 материалов в папку с деревьями?..
А если надо будет изменить, не знаю, Diffuse Mode какой-нибудь - мне что, все 10 материалов прокликивать по очереди?
Ну или что, делать код, который будет подгружать один сохраненный материал и передавать в него эти самые 1-3 параметра, которые будут меняться от меша к мешу? Делать код через @tool, который реагирует только на изменения параметров? А так разве не выйдет по одному материалу на одно дерево, или я и тут тоже туплю? Если не выйдет - вроде неплохой вариант, но это разве не костыль? Может, я какой-то очевидный базовый функционал проебал, вот и задаю тупые вопросы?
Все верно, если у тебя разные текстуры, то и материалы будут разные. Так работает оптимизация, движок при рендере отсортировывает объекты по материалам, чтобы при отрисовке меньше между ними переключаться, чтобы рисовать сначала объект с одной текстурой, потом со следующей и тд (Само 3д разруливает буфер глубины).
Можно попробовать сделать один шейдер, и передавать в него разные текстуры. В 4-ке для этого приспособить instance shader uniforms.
>>1086152
Да я и не беспокоюсь, братан. Я просто обозначил наличие проблемы. Но это не значит, что я буду вот прям щас усираться, чтобы ее решить.
А про геймплей ты прав совершенно. Я его делаю, но он пока достаточно сыроват. Вот как доведу до какого-нибудь удобоваримого состояния, так сразу в тред запощу.
Систему динамической смены суток и погоды я вообще делать начал, чтобы отвлечься и что-нибудь новенькое попробовать. Изначально думал, что просто текстуры для скайбоксов попробую сделать, буду их как-то постепенно переключать между собой. Но в итоге эта тема меня затянула, прототип разросся и получилось (для меня по крайней мере) весьма годно.
А по теме протечек аноны выше писали использовать SDFGI, VoxelGI, дать стены толщиной в метр и т.д.
Оказалось, что у меня уже был включен SDFGI, про что я совершенно забыл, и эти утечки сильнее всего происходят именно с ним.
Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Самый лучший вариант из трех оказался VoxelGI. Подрочив настройки bias можно добиться более выраженных теней, хотя достигнуть уровня темноты SDFGI все равно не получилось. Зато почти не заметно просветов.
Делать стены толщиной в метр действительно минимизирует проблемы (но не избавляет от них полностью), но стены в метр толщиной выглядят нелепо и несуразно. Это не варик.
Другие варианты по типу отключения энвайронмента, источников солнца, запекание света и прочее не подходит по уже указанным причинам.
рпж рогалик блят. полгода уже сука а конца и края так и не видно
Жанр писать не буду, а так делаю игру, которая покорит весь ру игромир.
Вначале что-то 2D простенькое. Потом может RPG какую. А вообще, когда набью опыта, хочу 3D бродилки делать, может хорроры.
Крита/Гимп если растром рисуешь. Аспрайт если пикселями. Блендер для 3д, блокбенч для лоуполи 3д попроще.
Gimp больше для редактирования изображению юзаю. Вообще, тогда Блендера может хватить. Даже для 2D.
https://docs.godotengine.org/ru/4.x/getting_started/introduction/index.html
Начни с официальных туториалов, они хороши и по делу. Есть и 3д и 2д - выполни оба.
Не шарю за местные преколы. Я кроме шуток хочу раннер запилить
если акк у тебя новый и игра не получает просмотры в первую неделю, то тебе надо написать в поддержку и они ручками твой новорег добавят в индексацию. Ещё очень сильно запарься с тегами и превьюшкой для игры - очень сильно решает
Да. По сюжету мы в роли горца ищем аппетитного барашка для Сабантуя. Но шайтаны балять мамю их ебаль падери не дают простым гордым народам жить
Ты нахуя хардкодишь путь? Просто обьяви экспортную NodePath и в редакторе прям в нее перетяни свой лабел, он подтянет правильную дорогу и будет ее обновлять если дерево изменится.
Не ну погоди а проблема то у него в чем? Вроде и путь правильный и автодополнение сработало.
Сквозь куб проходят, туда тоже можно отталкиватель воткнуть
Вот что в закладочках отрыл
https://github.com/abmarnie/godot-architecture-organization-advice
Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять? В любом случае, твоей целью должна быть минимизация количества отдельных материалов любой ценой. В идеале все твои деревья должны иметь один общий материал с одним текстурным атласом. Особенно это касается OpenGL/Compatibility рендерера, но и на Vulkan можно заметить тормоза, если постараться (я тестировал это во времена Godot 4.0 или около того). А вдалеке от камеры деревья в играх часто "слипаются" в один лоуполи меш для ещё большей оптимизации, и, наконец, в плоские картинки-спрайты. Встроенный механизм в Godot позволяет только упростить геометрию объекта, всё остальное зависит от тебя. Но помни, что преждевременная оптимизация вредна, и поэтому сначала слепи из того, что есть, проведи замеры, найди самые тяжёлые места и только потом оптимизируй их.
>>1086297
>Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Нет, на самом деле, на твоём скриншоте одна большая тень, просто светлая - цвета ambient lighting. Но если ты уменьшишь ambient lighting в настройках environment, тогда у тебя и снаружи дома тени будут 100% чёрными. Технически возможно менять этот параметр динамически: когда игрок заходит в тёмное помещение, ambient уменьшается до чёрного, а когда выходит на яркую улицу - поднимается обратно до серого (синеватого/зеленоватого/желтоватого). Кажется, так делали в старых играх, и это можно сделать намного эффективнее, чем любые техники GI. Если хочешь ещё больше реализма, тогда нужно ещё и bloom править относительно того, входит игрок в тёмное помещение или выходит на яркую улицу: когда только выходишь, свет бьёт в глаза и ослепляет, что можно реализовать, сильно увеличив bloom. В любом случае тебе потребуется способ определить, находится ли игрок в помещении... Что, наверное, и для геймплея пригодится (реакция NPC, стелс и т.п.), так что фича может быть намного важнее, чем может показаться на первый взгляд.
>>1086343
>Как Сабвей сёрферс и темплран
Рекомендую разобраться с этой нодой, поможет для такого раннера:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
В классическом раннере у тебя 3 таких дорожки должно быть.
>>1086393
>хардкодишь
Не, он правильно делает, это стандартный способ связки нод.
>обьяви экспортную NodePath
Это совет для Godot 3.x? Сейчас можно проще: @export label: Label... только ему это не нужно делать. У него там, похоже, самостоятельная сцена, которую он хочет куда-то цеплять для какой-то отладки. Ей будет достаточно и стандартного "хардкода". Вариант с экспортом полезен в тех случаях, когда необходима универсальная система. А вариант с $ полезен для того, чтобы прибить скрипт к конкретной сцене и явным образом ломаться в случае неожиданных изменений в этой сцене.
>>1086373
Открой вкладку "Remote" в дереве сцены, когда твой проект падает (или когда ты его запустил и он вот-вот упадёт). Там ты можешь развернуть все ноды, начиная с Root, и кончая этими своими Label. При нажатии на каждую ноду в инспекторе отображаются все актуальные данные этой ноды, даже те, которые не экспортируются в скриптах и недоступны при редактировании файла сцены. В этом режиме можно поковыряться и найти проблему своим умом. А по твоим скриншотам невозможно точно сказать, в чём может быть твоя проблема - ясно только, что "нода должна была быть, но её нет".
>Рекомендую разобраться с этой нодой, поможет для такого раннера:
Пасяб. А знаешь как выводить это всё в монетизацию через рекламу на смартфонах?
>Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять?
Да это только пример. Я в целом осознал, что нихуя не понимаю, как оптимально работать с материалами. Именно не с точки зрения оптимизации, а вот тупо удобства, чтобы не делать 10 почти одинаковых материалов и не менять в них 10 раз одну настройку в случае необходимости.
Вот анон выше написал про instance shader uniforms - думаю, это вполне может помочь. Про атласы тоже нужно будет подумать, в общем-то.