>3
У вас змеечка по диагонили ходит, алло!
Фича
Кто на итч выкладывал игру, дайте подшар какие подводные? Там ща можно игры из РФ выкладывать?
Можно. Оформи нормально, теги и прочую метадату заполни. Вот тебе гайд по скриншотам-каверам https://hedgiespresso.itch.io/itch-page-image-templates
Мертвые страницы с одним экзешником никто смотреть не будет, тем более скачивать, так что слышь оформляй, доверие завоевывай.
Из подводных - новый аккаунт, как и новая игра, могут подсидеть пару дней в фильтрах, пока алгоритм не выпустит или мочух не придет.
Принял, спасибочки.
Подводный один, туда никто не заходит, итч не льет трафик, ты сам должен раскручивать по всяким тиктокам и прочему.
Если ты уже популярен то итч активно заливает тебе трафик. Плюс иногда со своих аккаунтов в соцсетях тебя рекламит.
>nearest-neighbor scaling for 3D viewports
3д пиксель игры теперь без шейдеров получится делать?
3д пиксель игры теперь без шейдеров получится делать?
>теперь
Всегда можно было
здарова. Вопрос такой, вот у меня есть сцена control с панелькой, как лучше синхронизировать её положение на экране между сценами? Делать одну мегасцену интерфейса на всё? Чатжпт говорит просто ебани на canvaslayer и оно заработает, только оно не работает.
А зачем?
разобрался
Нет, не фича, это баг, не лги себе, я полночи сидел пытался исправить баг с диагоналями у себя, и так и не смог.
Багофича: сделано случайно, но понравилось.
>пытался исправить баг с диагоналями
Ты правда код скопировал, не осмыслив его?
Добавь на указанную строчку, например, это:
>...and new_direction.x != new_direction.y:
Это должно запретить ходы по диагоналям.
Если хочешь понять смысл строчки с dot():
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-dot
Весь тот код был написан на скорую руку.
>А я смог
Молодец.
Этот код не реагирует на нажатие. Направление изменилось и? Таймер ждёт следующего тика. Переделывай.
Нет, здесь таких нет. Поспрашивай в движкосрач-треде.
Дружище, мы уже поразвлекались с тобой на эту тему в тонувшем треде, было весело покидаться говном, теперь давай цивилизованно игры делать.
Спустя пару лет вернулся к симулятору масштабных битв армий на годоте.
В прошлый раз на чистом гдскрипте смог выжать сражения 500 на 500. Сейчас подключил C#, его либу для ECS, параллельные вычисления, рендеринг сервер, мультимеш2д, кастомный шейдер и уже 10К на 10К драки держат 100+ фпс на моём средненьком i5 процессоре.
Хотел сначала сделать видос, но шакалит люто и весит больно много, поэтому чисто скрин.
В прошлый раз на чистом гдскрипте смог выжать сражения 500 на 500. Сейчас подключил C#, его либу для ECS, параллельные вычисления, рендеринг сервер, мультимеш2д, кастомный шейдер и уже 10К на 10К драки держат 100+ фпс на моём средненьком i5 процессоре.
Хотел сначала сделать видос, но шакалит люто и весит больно много, поэтому чисто скрин.
>Круто
А гейплей в чем? Игроки должны восхититься тем, что автор освоил ецс?
Ну так не пользуйся, это опенсорс, можно любой язык подключить, например C++
Да. Технология открывает возможности для геймплея - битвы 10к на 10к.
Битва 10к на 10к это не геймплей еще. Кроме мессива на экране нужно еще что-то захватывающее. А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Выглядит клево
>Хотел сначала сделать видос, но шакалит люто и весит больно много
Можно небольшой кусок снять, условно в середине
>А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Я думаю дорога на восток многим из движкосрача треда подложила свинью, отчего некоторые и возбудились. Потому что кок ток то! Это жы гдскипт нююю он же плохой uuuu
Ты забыл потребовать признать это.
Ага, я очень доволен.
Геймплей будет, я хотел сначала сделать стресс-тест того, что это вообще жизнеспособно в годоте.
Ну вот тебе 5 секунд с середины, правда не уверен, что хоть что-то разберешь в этом месиве пикселей. Зато 300 фпс, хоть и скачущие.
Это Friflo ECS. Очень шустрая штука.
>гдскипт нююю он же плохой
Так 2 топовые игры на годоте (sts2 и восток) - обе на шарпах. Так что гдс унижают даже в рамках годотреади-языков
>сражения 500 на 500.
Это на нодах было или уже мультимеш?
Какое железо?
Вижу, что многие ругаются на GDScript и его медлительность. Думаю, всё-таки придется учить C#, как-будто это более выгодная инвестиция. Особенно учитывая то, что он и за пределами Годота используется.
Только вместо делания игры учить c# не стоит.
Да, на нодах было.
Проц i5 12600, 16 гигов оперативки, видяха тогда 3060ti была.
C++ быстрее. Учи его.
Обе этих игры начинали делать на другом движке на C#, то есть тут нет никакой объективной причины в самом гдскрипте. Просто у них уже был какой то опыт и может быть какой то игровой код написан
В СУБШОТЕ уже был твой коллега.
Все это конечно классно, но интересно бы что-то приближенное к реальной игре с поиском пути. Как вот жуки в факторио. Там, почему-то, ощущается это жутковатая масса в движение (может просто игровая иммерсивность), а тут не чувствуется этого. У чела в СУБШОТЕ вообще уже на жидкость похоже.
Скорее всего начинали с юнити и потом перекатились.
>какой то игровой код написан
Слишком большая разницам, все с нуля придется переписывать, если ты прям не гуру кодер которому делать нефиг, который умудрился писать сразу через слой абстракции (да еще обобщить между двумя движками, так как заведомо ты такой код никогда не напишешь, абстракции будут протекать)
>гуру кодер которому делать нефиг,
Да это я, я как раз пишу всю игровую логику на c++ и подключаю к разным рендерам.
Как бы на шарпах тоже надо уметь писать оптимизированный код, сам по себе шарпы тебя не спасут от гадостей в игровом цикле. Да и часть API на вариантах (динамических типах), поэтому не прокрастинируй шарпами.
Все равно дотнетовские шарпы это совершенно отдельный мир. А для хоум скриптов тебе хватит петухона, который похож на гдскрипт.
1. научись делать игры.
2. научись оптимизировать игры.
3. уже потом думай что упёрса в гдскрипт (потому что очень сильно захочется сразу прыгнуть в с++).
В реале может получиться что эффективный проект будет 95% на гдаскрипт и лишь 5% на С++
Почему ты считаешь что дело только в оптимизациях? Просто у людей могут быть предпочтения к языкам и платформам. Не только к синтаксису. Особенно если люди работали кодерами. Например чел проникся реактивным программированием и хочет использовать Rx везде где можно.
мимо
>Направление изменилось и? Таймер ждёт следующего тика.
Код написан с учётом особенностей движения "змейки":
- змейка движется ПОСТОЯННО - не способна остановиться;
- змейка движется в последнем выбранном направлении;
- змейка не может двигаться назад/задом наперёд.
Итого, когда наступает очередной цикл опроса:
1. Считываем актуальные значения ввода (get_vector()).
2. Проверяем соответствие условиям движения (см. выше).
3. Если условия соблюдены, принимаем новое значение.
4. Если условия не соблюдены - движемся куда двигались.
Примеры:
- двигались вправо - нажали вправо - движемся вправо;
- двигались вправо - нажали вверх - движемся вверх;
- двигались вправо - нажали влево - движемся вправо;
- двигались вправо - ничего не нажато - движемся вправо.
>голова не кружится, когда вы гдскрипт читаете?
Это просто с непривычки. Так с любым новым языком.
Технический опыт показывает, что лучше брать инструменты близкие к платформе.
Ты и так будешь трахаться с проблемами, так еще добавишь слой проблем от вторичного языка.
Поэтому если андроид - то это котлин.
если айос - то свифт, а не котлин
если годот это - гдскрипт.
При этом я очень не поддерживаю идею гдскрипта, он тормозит развитие. Да, облегчает вкат, но развитие создают не они, а те авторы "востока" и прочих шумных релизов (а они нередко мигранты с юнити и шарпов. Поэтому важнее было бы облегчить им миграцию, чем тем людям которые дропнуть разработку с вероятностью 99.99%).
Годоту мешает гдскрипт и система узлов. Вот сделайте нормальный шарп и систему компонентов и все... Имба будет.
Меня тоже ломало от правосторонних типов 11 лет назад. Ниче, адаптировался.
На питоне почти не писал.
Пофиг на гдскрипт, надо пинать чтобы полноценный и нормальный JIT сделали.
Годот позволяет писать без узлов (эти ваши серверы). Я не копал так глубоко, но периодично натыкаюсь на всякие заманухи, которые показывают что годот можно перелопатить довольно гибко (но зачем?)
>Технический опыт показывает, что лучше брать инструменты близкие к платформе.
А практический опыт показывает, что лучшие игры пишутся лучшими инструментами (язык - тоже инструмент), к коим гдс никаким боком не относится.
>Поэтому важнее было бы облегчить им миграцию
Согласен, лучше замедлить динамикодрисню еще одним слоем, который будет перебивать строго типизированное апи в варианты, чем делать из самого апи движка этот слой. Динамикодрисне то похуй, она и так медленная, а вот нормальным языкам - больно.
А не надо было на хуйне борландовской писать
Кто хорошо платит, тот меня и танцует.
гдСКРИПТ - это скриптовый язык. На нем, естественно, пишутся всякие легковесные скрипты (гуй, ввод контроллера и так далее), а тяжелые вычисления на с++. Поэтому да, игры делаются на связке лучших языков (c++ и скриптов). C# тут как видишь не участвует.
Ребят, завязывайте со срачем "GDScript vs C#".
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>500 на 500
>10К на 10К
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>500 на 500
>10К на 10К
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
>жертвы курсов
Почему курсов то? Сишорпу с дотнетом дофига лет. И отечественный софт на дотнете очень давно пишется.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
Видишь ли, это может показаться тебе неочевидным, но у движка открытые исходники, и ты можешь вызвать любую функцию с любым нужным типом.
>Ребят, завязывайте со срачем "GDScript vs C#".
Тогда придется идти делать игры.
>динамикодрисня с вариантами в качестве апи к движку
Это хорошо. Ты не должен обращаться к API движка слишком часто из высокопроизводительного кода. Твой код получает пакеты данных от движка, обрабатывает их у себя внутри на максимальной скорости, а потом передаёт движку одной командой. Всё. Не нужно дёргать API движка каждую наносекунду. Если тебе почему-то нужно, то тебя производительность вообще волновать не должна - тебя должна волновать кривая архитектура/дизайн игры.
>Тогда придется идти делать игры.
Вот я и пытаюсь делать игру... Открыл редактор Godot, открыл несколько скриптов, потом подумал "дай гляну тред, буквально минутку и вернусь к своим скриптам", а вы тут 50 постов успели насрать буквально за пару часов. Ну сколько можно? Потерял на вас ещё пару часов. Опять день закончился, а к игре даже не притронулся...
>ты можешь вызвать любую функцию с любым нужным типом.
По поинтеру штоле? Как деды? Это нарушение изоляции, за которое я заплачу сегфолтами, на которые я никак не повлияю, даже если я захочу дергать за яйца функции внутри движка вне общего апи. Форк движка это конечно интересно, но не очень интересно
>Чем хуже тем лучше, только выиграли, ну подумаешь что рейкастим нодой потому что рейкастить нодой быстрее чем рейкастить через апи
И это я еще не углублялся в тему renderingdevice, там скорее всего тоже есть на что посмотреть
Проблема ньюфагов, они верят что чем производительнее язык, тем быстрее будет их код.
Но проблема ньюфагов именно в их плохом коде и понимании масштабов того, как им еще далеко до кода хотя бы среднего качества.
Я как-то в сосничестве реализовывал функции пхп на С++ и они у меня работали медленней чем на пхп. Открыл сорцы и вообще не понял что там за магия, а я верил что там просто char перебирают
Но проблема ньюфагов именно в их плохом коде и понимании масштабов того, как им еще далеко до кода хотя бы среднего качества.
Я как-то в сосничестве реализовывал функции пхп на С++ и они у меня работали медленней чем на пхп. Открыл сорцы и вообще не понял что там за магия, а я верил что там просто char перебирают
Прокрастинируешь, сынок?
я сюда заглядываю утром под кофе или после работ
Почему ты считаешь что только ньюфаги хотят определенный язык использовать? Ньюфаги как раз жрут что дают, а более опытные уже имеют предпочтения исходя из своего опыта.
Ты скорее сам ньюфаг потому что все сводишь к синтаксису и какой-то мифической скорости. Не ньюфаг думал бы что хочет использовать либы к которым привык.
>использовать либы к которым привык.
Так выпьем же за то, чтобы не-ньюфаг использовал эти либы, а не срался за движки и языки вне движкосрач-треда!
> Форк движка это конечно интересно, но не очень интересно
Это единственный вариант если ты делаешь по настоящему Великую игру.
Ну так бери и используй. Опять не нюфагам что-то мешает что же такое творится то.
>Почему ты считаешь что только ньюфаги хотят определенный язык использовать?
Потому что у реального специалиста нет синдрома утёнка, он достаточно гибок.
>Не ньюфаг думал бы что хочет использовать либы к которым привык.
Завтра сделают С# первым гражданином и придет твой собрат который будет ныть так же про gdscript. Ощущаешь однобокость твоего мышления?
Отличие профессионала от ньюфага - умение адаптироваться - быть гибким, а ты ноешь, возводя свои эгоистические потребности выше профессионального скилла. Поэтому я и утрирую это поведение до ньюфажного.
Умение адаптироваться это не есть способность, когда тебя лишили авто, кататься на велосипеде сквозь ветер с дождем. Как говорится ветер в харю - я хуярю. Я таких "сенек" видел на работе. Два десятка лет пишут весь код в одном файле на десятки тысяч строк с формулировкой - так удобнее.
Как бы то ни было, ничего не изменится.
Если только МС не увидит перспективу годота и хардкорно не протолкнут свое лобби с фулл там кодерами.
Но у мелкомягких проблема с дальновидностью.
От нас с тобой ничего не зависит, даже если мы наноем 500 сообщений на двачах, все равно игру придется делать нам самим, как бы мы не злились на свою прокрастинацию и на этот неидеальный мир
>фулл тайм*
Кто то пользовался Cogitio? Я так понял по MIT лицензии просто нужно указать авторов в своей игре и все. Просто там по сути все готово, квест система, сохранения, тетрис инвентарь, какие то НПС, оружия, всякие кнопки, лифт, стул на котором можно ездить (просто заменить модель на велосипед например можно). Прикольно же.
*cogito
>Я так понял по MIT лицензии просто нужно указать авторов в своей игре и все
Главное эту MIT лицензию сохранить, в авторах можно не указывать
Сам движок по MIT лицензии же. Чего ты сомневаешься?
А когито мне не понравился, он какой-то переусложнённый.
Наоборот. MIT не требует сохранения лицензии, но требует указания авторства.
А такое для 3д работает? Ну не 10к тыщь а хотя бы орду из 100 человек воссоздать нормально
Конечно, шарп шустрее гдскрипта процентов на 10, в специально подготовленных тестах, но всё-таки главное "узкое место" - скриптовое апи движка. Так что, для критических по быстродействию мест гдскрипт или ц# - однохуйственно в сравнении с C++.
Ну и вообще, есть простое правило. Если что-то выполняется 100500 раз за кадр, то этим должен заниматься компилируемый кусок кода (если предусмотрено, то лучше сам движок); если же до пары десятков раз - то вообще похуй, хоть жабаскрипт туда впили. Все проблемы с производительностью сводятся к тому, что криворукий кодер делает скриптами то, чем должен заниматься компилируемый код. Так что вообще забей, гдскрипт не "медленный" в бытовом понимании, просто не предназначен для некоторых специфических задач, типа управления армией в стратегии-числодробилке.
НО. Выучить C# всё равно полезно просто для собственного развития. В процессе ты сам поймёшь, что он нихуя не производительнее; однако знания - это знания, они делают тебя востребованным специалистом. Знать два языка - всяко лучше, чем знать один язык.
>однохуйственно в сравнении с C++.
Остальные языки проиграют плюсам по производительности работы с годотом только в случае форкования движка и написания кода прямо в движке, не gdextension, а прямо в движок, что тянет за собой постоянную рекомпиляцию движка для проверки функционала. В случае gdextension - производительность апи равнозначна для любого языка, и гдс, и с++ и раст и с#, что приводит к тому, что один и тот же простой код (например для управления частицами через renderdevice) будет начинать пропердывать на условных 100к частицах на любом языке, компилируемом, интерпретируемом, каком угодно. Так что не пизди, дядя
Кстати, я не разбираюсь ни в чем мною написанном, просто набросил говна на вентилятор. Но рад, что спровоцировал хорошие интересные ответы.
>тянет за собой постоянную рекомпиляцию движка
Это вообще не проблема.
>500 на 500 - много
Скачи Мочи очень популярная и успешная серия игр.
Там и поболее будет в Warband.
А так это просто нагрузочный тест, я хотел посмотреть, как сильно прокачался за пару лет периодического тыканья годота и шарпа, чтобы сравнить с тем, как было раньше. Понятно, что пока это просто месиво и геймплея нет. Но уже сейчас есть огромный запас фпс для реализации обхода препятствий, разных классов юнитов и прочего. Особенно если раза в два порезать количество юнитов и сделать бои не 10К на 10К, а 5К на 5К. Там и 500 фпс спокойно держатся на среднем проце.
В теории будет, но я не уверен. Я никогда 3Д в годоте не занимался. Тут практически всё вынесено из годота, у меня буквально одна нода, которая просто гоняет ECS и рисует пискели. Даже для юнитов нод нет. Это отдельные ECS-сущности и десяток ECS-систем, которые как-то их обрабатывают.
То есть даже механика коллизий в этом проекте - это ECS, а не CollissionShape годотовский. Приходится конечно вручную всё считать, но это все равно быстрее выходит, чем 20К коллижн шейпов каждый фрейм.
Мегакрит / Slay the Spire 2 теперь донатят ~38k евро в годот. Раньше было 18к.
Крайне удачно они с юнити съебнули.
Крайне удачно они с юнити съебнули.
Когда у тебя есть команда сеньоров на зарплате? Тогда согласен. Можно из годота вообще повыдирать только самое важное (типа рендера) а остальное писать самому
>написания кода прямо в движке
Во-первых, не прямо в движке, а в отдельном модуле, статически линкуемом с движком. То есть весь твой самодельный велосипед будет изолирован в папке и обновляться на новую версию движка будет легко.
Во-вторых, 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й минуте второго часа рефандят. Уёбок.
Хуйня, мне стим после 4х часов рефанднул. Я сказал что большую часть этого времени пытался заставить игру работать.
Думойте.
Думойте.
А что думаете о F2P + donate/cosmetic DLC?
Как по мне, это имеет массу преимуществ:
- пираты и дети могут играть с остальной фанбазой;
- желающие задонатить побольше могут это сделать;
- покупателю не придётся ничего никому возвращать;
- доверительные отношения, ведь нет обязательств;
- легче получить новые взносы от старых игроков.
Основной минус - в отзывы насрать проще.
Но ненужный ассетфлип так не продашь...
И есть какие-то предрассудки (?) о F2P...
Как по мне, это имеет массу преимуществ:
- пираты и дети могут играть с остальной фанбазой;
- желающие задонатить побольше могут это сделать;
- покупателю не придётся ничего никому возвращать;
- доверительные отношения, ведь нет обязательств;
- легче получить новые взносы от старых игроков.
Основной минус - в отзывы насрать проще.
Но ненужный ассетфлип так не продашь...
И есть какие-то предрассудки (?) о F2P...
Если ты просто будешь регулярно обновлять свою игру, то пиратить её будет уже неудобно. Вдвойне если прикрутишь воркшоп. А cosmetic DLC это кал, который актуален в основном если у тебя мультиплеер и ты сервак держишь. Если делать dlc, то хорошие.
Ещё про f2p - есть такая психология лично у меня, что в халявные игры я играю меньше, чем в то за что уплочено. Это не считая сессионок всяких.
Ну, как по мне, написать модуль движка проще, чем gdextension. Я попробовал то и другое где-то год назад. Но это личные впечатления, да и в плюсах я тогда понимал сильно меньше, чем сейчас.
>В-третьих
Ну кстати да, это фича 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 человек?
Смотрю вот эти изделия игросодержащие, ну графоний/спрайты понятное дело хуета уровня каляки-маляки пятиклашки в пэйнте. Потом захожу на страницу к разрабу: там среднестатистический заводчанин 35+, проживающий где-нибудь в центральной России, нередко женатик, а то и с детьми.
Что это за особая прослойка мрачных психологов такая? Почему они так любят инди двадэ хорроры (которые вызывают не столько страх, сколько кринж). Поколение читателей Стивена Кинга?
И кто вообще в такое играет кроме самих энтих разрабов и их внутреннего круга из 5 человек?
Хоррор проще слепить и продать обывателю.
Как вообще можно хоррор в 2д сделать...
Пики - 2д хорроры, довольно годные. Сделаны на ГОДОТЕ, КСТАТИ.
Продается потому что
Спокойно вон поляк уже вполне успешно 3 раза почти одно и тоже продает
А имя студии отсылает к дедам
https://store.steampowered.com/search/?developer=Harvester%20Games
>нынче
>ХОРРОР
Сколько тебе лет, 13? С подключением! Инди-хорроры сохраняют свою популярность с нулевых, когда там индюшатинка начала развиваться на движках для нормисов. Многие старые движки уже умерли, а жанр продолжает жить, потому что он просто бесконечный.
Хоррор сделать относительно легко, потому что в нём важнее всего создать эмоции, а на качество графики, озвучки и глубину геймплея наплевать. Для людей естественно бояться темноты, а в темноте попробуй отличить плохую графику от хорошей; шум, треск и остальные дефекты звука - это плюс, а не минус; для геймплея достаточно ходить и тыкаться в кнопки... Монстров нарисовать на порядки проще, чем что-то красивое, буквально любой новичок может взять и нарисовать или смоделировать что-то мерзкое. Даже упоротые анимации - плюс, а не минус для хоррора.
Но самое главное в жанре хоррора - это отсутствие реиграбельности. Люди много чего могут бояться на протяжении всей жизни, но ты не можешь пройти классический хоррор второй раз и напугаться как в первый раз. Допустим, ты боишься темноты, но ты боишься, на самом деле, неизвестности - того, что способно скрываться в темноте. Пройдя игру, ты уже знаешь, какие там монстры или про их отсутствие, и прежнего уровня страха от этой игры уже не будет.
Но от другой, новой игры? Ты будешь бояться снова, практически как с первой игрой, ведь новая, даже с аналогичной графикой, геймплеем и т.д., таит в себе неизвестность. Ты не потерял страх темноты, и ты не знаешь, что тебя ждёт в новой игре. Поэтому можно проходить тысячи инди-хорроров и это тебе не будет надоедать, в отличие от многих других жанров игр.
Вкратце:
- создать легко => низкий порог входа;
- нет реиграбельности => ниша ненасытна.
Для сравнения, жанры с высокой реиграбельностью насыщаются очень быстро и поэтому в них высокая конкуренция за игроков; например, бестолку делать собственный аналог Minecraft или Terraria, если ты копируешь их слишком сильно - игроку нет никакого интереса играть в твою игру, когда они могут влить следующие 5000 часов в старую игру и получить удовольствие на уровне предыдущих 15000 часов. Оригинальную игру в том же жанре сделать можно, однако, это намного сложнее из-за более высоких требований как к графике, так и к геймплею, и т.д.
Поэтому многие выбирают жанр хоррора.
Хорроры и порнуха вызывают одинаково аддиктивные эмоции. Об этом еще на форумах интернета 1.0 писали.
нужно делать порнохорроры
А потом тебя итч/стим в отстойник отправят, потому что на них виза/мк давят цензурировать подобный контент.
Я выкладываю игры только на имиджбордах
Мне показалось
> порноходы
И я уже хотел написать про Вселенную-наоборот, но потом перечитал внимательнее.
Но вообще да, во Вселенной-наоборот с толщеходами есть хоррорный элемент. Тёмные полости с погасшим ядром заселяются слепыми хищниками, которые ориентируются на шум, охотятся стаями. Хрен убежишь. Догонят и выебут. Вот вам и хоррорпрон.
Касательно слова "нынче" это я спизданул к тому, что сам начал подмечать тенденцию к засилью подобного у новичков именно ближе годов с 20х. Раньше дофига было платформеров, их и сейчас дофига, но уже как будто не модно, моднявее сделать жуууткую новелку, или бродилку по жопе негра с фонариком. Если в тридэ — всё те же бессменные вариации на тему слендермена с записками в лесу.
Вот годах в 10-20х, особенно в первой половине я видел тенденцию к платформерам с "фишкой", какая-нибудь там гравитация, отмотка времени, паззлы/головоломки по типу VVVVVV. Или там копалки-подземки по лекалам Spelunky/Steamworld Dig. Плюс ко всему артстайл в эту эпоху расцвета миллениалов был какой-то с позитивом, надеждой, все эти улыбчивые мордочки Джамп Гаев, Шот Гаев, Иван Гаев, придурошно, но по доброму, и без "у-у-у, ужастег псехологея".
Может это чисто персональное восприятие, но как правило на смену парадигмы среди сообществ людей у меня чуйка натаскана.
Суть ответов ясна: "просто сделать + сложно проебаться". Надеялся, конечно, что это всё же не от того, что народ выбирает путь наименьшего сопротивления, а скорее какая-то мода/повестка/тренды/ситуация в мире. Но спорить с мнениями не буду.
Интересно. Я всегда осознавал, что sex sells, но вот конкретно хорроры думал более нишевая шняга. Сам то я их стороной обхожу просто, наигрался в нулевых во всякие калл оф ктулху, скрэтчес, и понял, что революции в жанре не будет, а жрать старое под новым соусом — нахуй надо. Из последнего заценил уже считающийся "старой игрой" алиен изолейшен, ну да, прикольно, попрятаться под столами. Но в целом тягомотина же, нудятина. Хз, не получаю видать тех же эмоций, что другие пиплы от чувства страха. Лучше уж книженцию какую почитать, так иммерсия в 10 раз интенсивнее.
Никогда не любил хорроры. От слова совсем. Зато люблю порноигры. Не похоже на что-то общее.
Ты вагину видел ваще? Это же чистый хоррор епта.
>мода/повестка/тренды/ситуация в мире
Но ужастики всегда нравились детям...
>Ты вагину видел ваще?
Очевидный хэдкраб очевиден же...
Я вижу больше 3д хорроров, чем 2д, но я слежу за зарубежьем. Пс1 стайл лоуполи с кое как сделанными моделями и текстурами это первый законченный проект и многих инди девов. AlphaBetaGamer канал на ютубе, там такого полно.
Ламар!? Ты куда опять сбежала? Прыгай мне на лысину. Вот так, моя девочка.
>Крайне удачно они
В чем удача? Они задонатили больше чем покупка про лицензия.
>Вдвойне если прикрутишь воркшоп.
Моды убьют твою игру. Посмотри как сделал стоншард. Они около 7-9 лет пилят разжиревшую полудемку, меняют цифры стат местами (как в патчах доты) и запиливают буквально одну-две механики или персонажа.
Был бы вагон модов и контента, они не смогли такими малыми силами доить корову почти 10 лет.
Пришлось бы делать реально жырные патчи или DLS (то есть реально работать), чтобы конкурировать с обилием модов. А так люди праще радуются (что по механике копия лука) или новому персонажу (просто арт с другими статами).
Стоит ли ебаться с дельтой, если код в _physics_process? Там же стабильный тик, не привязанный к фпс? Зачем тогда там вообще дельта передается?
Там "стремящийся" к какому-то значению тик, но он никогда не бывает "стабильным", даже в вакууме, поэтому дельта всегда имеет смысл.
"Стабильный" - не означает бесконечную стабильность и гарантированность. Бывают пропуки, бывают погрешности (немного больше/немного меньше константного значения шага). Потому в целом можно не ебаться, но если тебе нужна бОльшая точность - лучше задействовать дельту в расчетах.
То есть в целом, для легких игр, можно забить на дельту в физикс_прооцесс. Если только юзер не запускает игру на компе из 99 года. Спасибо.
А ее так сложно использовать, что хочется забить? Обычно же она нужна как доп коэффициент в формулах всяких и все.
Да не, просто лень держать ее в голове. Например у меня есть персонаж, следящий за игроком, поворачивающий голову с определенной скоростью, и игрок, обогнав его скорость поворота, может от него убежать. Вот туда дельту лень учитывать.
А в годо можно делать стратежки без графики, ну типа как в экселе?
А в экселе же таблица с ячейками - это же графика. Ты же меня обманываешь. Без графики - это в консольке.
В консольке такие чудеса вытворять можно - эксель позавидует.
Хочешь без графики - деды до появления мониторов печатали вывод на листках бумаги.
Так у меня пока игра в консольке. Хочу вот перейти на новый уровень
Да, а ввод на перфокартах. Что-то сразу захотелось запилить игру с эмуляцией всего этого. Ну, перфокарты можно камерой считывать
В итоге получился вот такой снак.
Невыносимо медленный при движении по таймеру.
Но можно ускорить.
Но отзывчивый при нажатии клавиш.
Без диагонального движения.
Со встроенным детектом самопересечений, стен, еды.
Создающий себе сегменты в реалтайме.
Ща как доделаю игру! Уххх, ща как доделаю!
Невыносимо медленный при движении по таймеру.
Но можно ускорить.
Но отзывчивый при нажатии клавиш.
Без диагонального движения.
Со встроенным детектом самопересечений, стен, еды.
Создающий себе сегменты в реалтайме.
Ща как доделаю игру! Уххх, ща как доделаю!
Я думал спецолимпиада закончилась еще в прошлом треде. А в чем сложности то?
Если игрок нажмет кнопку турбо, вся физика посыпиться
олды сплакнут
Намечается новый холивар - дельта не нужна, дельта для слабых.
Сделайте плавную змейку, хватит долбится в тайлы. лол еще и через таймер
Это какая-то форма мазохизма? Что мешает с нейронкой слепить за пару часов? Ещё и сегменты не инстансишь.
Плавная змейека теряет ретрошарм. А так же смысл - гораздо проще избегать столкновений, если ты можешь маняврировать как угодно, а не только в четыре стороны. Это уже не змейка короче будет, а другая игра какаято. Алсо, хз как на твоем скрине на самом деле сделано, но на вид эти черви тоже сегментирорванные, просто кружочками для гибкости.
С дельтой еще проблема что тут она учитывается движком автоматом, а вот тут ты ее должен руками вкорячивать в движковые функции.
Предлагаю прибить фпс и физикс фпс гвоздями, и если что посылать игрока нахуй.
> Это какая-то форма мазохизма?
Саморазвитие - это больно. Саморазвитие легко спутать с мазохизмом, потому что и там больно и тут.
> Что мешает с нейронкой слепить за пару часов?
Потому что с нейронкой ты так и останешься неразвитым. Вместо тебя разовьётся нейронка.
> Ещё и сегменты не инстансишь.
Инстансиш.
Ты троллишь так? Троллишь ведь? Нафига ты туда эти Area2D лепишь? Чтоб процессор пользователя греть? Создавать ощущение бурной деятельности игры? Чтоб казалось, будто игра на фоне крипту майнит? Тебе уже скинули базовый код классической змейки, которая по клеточкам ходит, чем ты недоволен-то? Или ты хочешь сделать змейко-платформер, как сейчас модно стало?.. Тогда тебе нужно CharacterBody2D вместо Area2D, лол.
>Плавная змейека теряет ретрошарм
Тогда зачем ты обмазывался Area2D, ретрофил?
>Саморазвитие
Да ты ж наговнокодил просто. В чём саморазвитие?
>Зачем тогда там вообще дельта передается?
Для каких-нибудь строгих симуляций в мультиплеере. Физика может отставать, особенно если компьютер не вытягивает 60 FPS по процессору (не по видеокарте), поэтому установленные в настройках TPS физики не гарантируются. Почитай всплывающие подсказки в настройках проекта, касающиеся настроек физики. Тестируй игру с открытым профайлером или выводи информацию из API Performance на экран в игре...
>А в годо можно делать стратежки без графики
Можно, конечно. Можно использовать Control-ноды. Учитывай, правда, что Control-ноды рендерятся через кастомный OpenGL/Vulkan/DirectX/Metal-рендерер в зависимости от платформы и настроек проекта, а не встроенным в операционку набором виджетов, т.е. взаимодействие с ОС отличается от классического, и некоторые фичи, возможно, ещё не поддерживаются.
Вот тут о том, как юзать Godot для GUI приложений:
https://docs.godotengine.org/en/stable/tutorials/ui/creating_applications.html
Но учитывай, что, хотя 3D фишки можно вырезать из движка, 2D фишки пока что не так легко вырезаются. Поэтому сделать Godot максимально тонким трудно.
Перевел проект НА ГОДОТЕ на гит наконец. Знаете почему? Потому что нейронка мне пишет нормальные саммари сделанного. Вручную всегда лень писать было, и коммиты скатывались к fix1 fix2 update123
Рекомендую.
Рекомендую.
>Тогда зачем ты обмазывался Area2D, ретрофил?
Опять бля у шиза все голоса в один слились.
Я другой шиз, не путай нас.
>fix1 fix2 update123
Просто нужно фокусироваться на одной фиче/баге, не растекаясь по всему проекту хаотичными правками, и описывать тогда будет нечего.
А зачем тебе гит? Откатываешься часто?
>А зачем тебе гит? Откатываешься часто?
Бекапы все равно нужны, а перед каждой фичей бекапить 5 гигов уже места нет. Ну и вообще, для собственной подотчетности.
> с нейронкой слепить
Нее... Нейронка пусть мне арт рисует. А прогать я сам буду.
Ты троллишь. Троллям - игнор.
>А зачем тебе гит? Откатываешься часто?
Я без гита впринципе даже тестовые заметки не веду. Не только профдеформация, но и жизнь в условиях умирающего ссд на протяжении пары лет. Хз как вы игры делаете без гита, лишняя хромосма помогает?
Ну а с нейронками это просто необходимо - это говно легкой рукой сметает к хуям хоть весь код в процессе, если надо. Поправит то, попробует там, и вот хуяк уже ихз рабочей версии полностью нерабочая - гитом откатить можно. Еще она и гит можно смести к хуям, да, как-то раз мне просто сделала гит резет хард на 10 коммитов назад, это правда восстанавливается, но так и поседеть можно, так что гитовать надо не только локально, но и на ремоты обязательно слать.
Ну и дляценителей, конечно же, относится в целом не к гиту именно, а к любым контролям версий, извращайтесь как хотите для тех же целей, хуле нет, хотя ручной бекап это пиздец, лол.
Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
Уж лучше бы тебе нейронка нормальный алгоритм сгенерировала, чем вот это вот говнокодерство. Специально для таких как ты костыли сделали.
>пусть мне арт рисует
Ага, и будет говнокод в красивом фантике.
>перед каждой фичей бекапить 5 гигов
У тебя 5 гигов кода? Или всё-таки арта? Арт не нужно бэкапить, когда с кодом работаешь. А код правится маленькими частями в отдельных папках...
Вообще, тоже подумываю подключить какую-нибудь подходящую VCS, но всё боюсь, что она сломается и поломает мне все файлы. А бэкапы пока ни разу не пригодились по сути, потому что я никогда назад не возвращаюсь из принципа. Если не идти вперёд, а возвращаться назад, то в чём тогда будет прогресс? Сохраняю бэкапы только на случай поломки диска.
>лишняя хромосма помогает?
>с нейронками это просто необходимо
Какая хромосома заставляет тебя юзать нейронки?
>полностью нерабочая - гитом откатить можно
Зачем откатывать то, что можно просто не ломать?
>хотя ручной бекап это пиздец, лол.
Зато никакая нейронка не влезет и не сломает, ибо архиватор древней версии и надёжен как часы. А гит наверняка уже заслопили мартышки из майкрософт.
>У тебя 5 гигов кода? Или всё-таки арта?
И арта, и кода, и рефов, и звуков. Но для бекапа выковыривать только код тоже лень, проще весь каталог копирнуть. Ну и да, на случай поломки диска оно хотя бы на гитхабе будет, в приватной репе. А с гитом нейронка хорошо помогает. У меня первые три коммита не от того юзера пошли (гит подтянул старые настройки), и нейронка мне быстро подсказала как это выправить, отредачив авторство уже запушенных коммитов. Сам бы я поленился это в доках искать.
>А гит наверняка уже заслопили мартышки из майкрософт.
Гит != гитхаб, балбес. Ну и юзай другие, их полно, раз гит вдруг стал майковским.
>Зато никакая нейронка не влезет и не сломает
Да она просто рм сделает под предлогом чистки мусора.
>Какая хромосома заставляет тебя юзать нейронки?
Дежурный луддит, добрый вечер, как на бересте пишется?
>Зачем откатывать то, что можно просто не ломать?
Нейронки не то чтобы именно ломают (разве что удаляют они почему-то слишком уж бездумно, наплевав на то, что могут и не восстановить уже), просто не все их высеры стоят того, чтобы их доводить до конца. После работы нейрослопа всегда надо старательно напильником обрабатывать, иногда проще откатываться, чем вникать в очевидный сгенерированный бред, даже если он рабочий. Для них это все равно быстро. Даже слишком. Собственно из-за скорости нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью.
Ну понятненько. Ты у нас и гит не признаешь, дьвольские технологии. И нейронки тоже. Луддит бинго? Че там дальше - отрицание 4к мониторов?
>для бекапа выковыривать только код тоже лень
В архиваторах можно настроить фильтры. Я просто исключил из архива все .png, .gltf и т.п. тяжести, что практически никогда не меняются, и в итоге бэкапы составляют всего несколько килобайт файлов, что изменились за сегодня (фильтр по времени). И это практически не занимает времени, всего 3-4 клика. Автоматически добавляется штамп времени и т.п. Перекатываться на кривоватый гит как-то лениво...
>раз гит вдруг стал майковским
Ну, не будешь же ты свой сервер арендовать...
>Да она просто рм сделает
Она-то сделает, но запустил её ты. Виновен ты.
>Дежурный луддит
Я не луддит, а как раз фанат ИИ технологий, и именно поэтому знаю, что нейронки на базе 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.
>Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
Откуда инфа? Есть повод для волнения?
>чем вот это вот говнокодерство
>говнокод в красивом фантике
Ты чё быкуешь, сука, человек реально обучается методом проб и ошибок, щупает синтаксис языка, своими мозгами доходит до рабочих/нерабочих методик, а ты падла подсираешь, ещё и анонов в ридонли дизморалишь. Ты вообще понимаешь как устроен процесс обучения вещам у человека? Стянул бы еблет со своей говнокритикой лучше.
>реально обучается методом проб и ошибок
>как устроен процесс обучения вещам у человека?
Так он это здесь показывает так, как будто это что-то хорошее и нужно повторять. Если он хочет критики - замечательно, но он же сразу огрызается на советы, следовательно, критики он не ожидает. Тогда зачем?
Или ты считаешь, что юзать Area2D для игры, где все элементы - квадраты на квадратной сетке - это типа нормально? Ты считаешь, что ему следует держаться данного подхода и ни в коем случае нельзя делать замечаний, что так делать (в данном случае) вредно?
Ладно бы он хотел сделать что-то современное. Но он пытается скопировать классическую змейку. В ней уж точно никаких Area2D не было и быть не могло.
>Откуда инфа? Есть повод для волнения?
Да повод вполне обычный - у нас есть хуйня импортозамещенная. С крошечными лимитами на бесплатке. И принадлежащая тоже кому надо. И даже заботливо намекающая с главной же страницы "мигрируйте к нам с гитхаба, вот тут нажать".
Правда уже довольно давно, главное почва уже имеется, войну сервисам и с меньшей подготовкой объявляли.
А повод даже выдумывать не надо - на гитхабе куда не плюнь запрещенка.
Ладно, эт я чёт сорвался. Думаю для такой хуйни как змейка из трех с половиной нод, начинающий юзверь вполне может юзать ареа2д. Опять же, гораздо эффективнее и запоминабельнее будет себе стрельнуть в ногу в проекте покрупнее, и уже исходя из этого оптимизировать подход. Ну и его реакция тоже ясна: вместо критики обозвали говнокодом, подкинули невнятных объяснений, и дали ссылку на неоткрываемую без впн документацию.
Ну ладно, хули я тут языком чешу, ситуация-то штатная в любом коммьюнити, в любом обсуждении. Пойду лучше мусолить игру мечты.
Фух, кажись тролль ушёл. Продолжим делиться своими игорами в треде, друзья!
Парни есть гайд годный на выживач на голове с мультиплеером? А то все гайды именно на сюрвалики а не выживачи.
>выживач на голове
Играть за блоху?
Новый челлендж - змейка со скроллом уровня..
У вас здесь какой то непрекращающийся змеиный перфоманс, интересно юнитеки из треда, хоть змейку смогут сделать без ассетов.
Я делал, но не на юнити. На плюсах в терминале)
Делать игры это база. Продолжайте змеиться.
Бля, збс идея так-то
Моя первая змейка такая же была. Баженная. На спор сделал. Знал только массивы, циклы, функции, все такое, да классы прям понюхал тока тока, ни архитектур нихуя не знал и не умел, ни опыта.
Смотрю на этого змеееба тредовского и думаю смогу ли я сейчас без нейронок сделать змейку уже в годоте и чтоб охуенная была. лень проверять.
Зашел я в репу и посмотрел ишью по 4.5 и 4.6. Скажите, сидит кто-нибудь на них, стабильно ли? Очень много мердж реквестов и ишью висят, мне аж не по себе, особенно за 4.5. Будут ли дальнейшие 4.5.х и 4.6.х релизы? 4.6 точно такой релиз нужен, я литерали не могу его использовать. Редактор вылетает при импорте анимаций, ишью так и висит, теперь это уже регрессия 4.6.2, хотя у меня и в 4.6.1 не работало.
>Будут ли дальнейшие 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, там часто обсуждают.
Чё за бредятина у годота с редактированием инстанцированных сцен? То есть я не могу polygonshape дочерней сцены через встроенный редактор нарисовать, мне для каждого инстанса надо прожимать "редактировать дочерние элементы" Почему не добавить возможность вынести такие вещи на корневую ноду? Думаю теперь костылить polygonshape2d в корне и area2d в рантайме себя корнем делает и принимает polygonshape2d.
Проблема Икс у тебя в чём заключается?
Какую проблему ты пытаешься решить, редактируя дочерние элементы?
Зону спавна из 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.
>а убрать уже нельзя из-за обратной совместимости.
При переходе с тройки на четверку всю совместимость поломали жи. Самый момент был для выкидывания, если на то пошло.
>не работает
Исправил ошибку - можешь попробовать снова, если хочешь.
>избыточно
Но это ускоряет работу, если нужно создавать много таких нод.
>для импортированных мешей
Если изменишь порядок/имена нод в исходном файле, то после повторного импорта 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
>просто никогда ими не пользуйся
Они не так уж и плохи в некоторых ситуациях, просто нужно знать нюансы (см. выше).
>убрать уже нельзя из-за обратной совместимости
>Самый момент был для выкидывания, если на то пошло.
"Inherited scene" существует благодаря "editable children" - их можно было получить через какие-то манипуляции с кодом сцены в файле tscn - кнопка создания "inherited scene" просто упрощает такую манипуляцию. Это важная фича системы сцен, отказаться от неё нельзя. Считайте это трюком уровня get_parent().get_parent().get_parent()... - движок позволяет так делать и никто не будет вырезать эту фичу в будущих версиях движка, потому что так работает дерево сцен и ничего с этим не поделать, но это не означает, что вы должны обмазывать все скрипты такими конструкциями. Пока "родитель" нескольких "дочерних" сцен никак не меняется (иерархия и имена узлов), всё должно быть в порядке. Проблема будет только если вы захотите изменить родителя - тогда дочерние сцены могут поломаться, утратив часть данных, закреплённых за изменёнными нодами. Повторюсь - это должны были решить UID у нод в сценах, но я не знаю, решили они это или нет.
А я продолжаю издеваться над годотом, добавил коллизии юнитам, классы стрелков и магов, и начал работу над статическими объектами на карте, которые юниты стараются обходить.
ФПС упал сильно, в пике нагрузки уже меньше 200 фпс показывает. А было 500 изначально. В целом не страшно, ведь это значит, что у меня в запасе еще 140 свободных кадров, которые можно потратить.
ФПС упал сильно, в пике нагрузки уже меньше 200 фпс показывает. А было 500 изначально. В целом не страшно, ведь это значит, что у меня в запасе еще 140 свободных кадров, которые можно потратить.
Круто конечно, но вампырики-сурвалики уже всех заебали. Ты эти волны врагов никому не продашь.
Делай лучше метроидванию. Метроидвании всегда в цене. Хороших метроивданий мало. Сделаешь хорошо - заработаешь нормально.
>Ты эти волны врагов никому не продашь.
Не рекламы ради, я тут последние 3.5 недели дрочу мобильную гиперказуалку "Gear Defenders" - и она умудряется затягивать и по своей воле смотреть 2-3 десятка рекламных видео в день, лол. Геймплей на поверхности прост: ставишь эти "шестерёнки", а они спавнят юнитов, которые идут и бьют мобов... Если копнуть глубже, имея ограниченные ресурсы, место, неудобные препятствия и т.п., собрать успешную композицию не так-то просто. К сожалению, игра на высоких уровнях скатывается в "либо повезло, либо смотри рекламу ради какого-то шанса на победу". Поэтому, рекомендовать эту игру не могу - но с т.з. геймдизайна базовая формула весьма хороша. Мне захотелось сделать похожую игру или реализовать данную формулу геймплея в игре другого жанра.
Но там не так-то много юнитов - где-то до сотни. Интересно, что бой становится месивом, где трудно разобраться, кто кого атаковал и насколько сильно, поэтому становится тяжелее принимать решения на следующей волне. Т.е. огромное число юнитов не является здесь чем-то нужным или крутым, скорее раздражает, мешает анализировать ситуацию. Алсо, большинство юнитов тупят, не могут выбрать более подходящую цель (пример: всадник имеет сильное преимущество против лучников, но если даже он технически мог бы обежать защитников по дуге, он предпочтёт умирать об этих защитников, что бесит, особенно если это в чистом поле с 2 врагами).
Короче говоря, игра с толпой может быть довольно интересной и при этом простой, но нужно правильно организовать и не перегружать игру лишним числом, поскольку слишком большая толпа не нужна и лишь отвлекает или мешает анализу и планированию.
Относится ли пикрил к "survivor-like"? Вроде бы нет. Насколько я понимаю, это вариант tower defense с укороченной дорожкой и мобильными "башнями" (интересно, "башни" - это шестерёнки или юниты?). Конечно, есть ещё куча жанров, где толпа уместна...
>метроидванию
С точки зрения геймдизайна, это в первую очередь платформер, а платформер - это экшен с высокой зависимостью от точной реакции игрока. Так что это ограничивает целевую аудиторию, которая способна поиграть и получить удовольствие. К тому же, жанр метроидваний подразумевает большой уровень с регулярными походами туда-сюда через ловушки, и, следовательно, игровая сессия даже с чекпойнтами должна быть долгой (иначе игрок забудет, куда ему двигаться и зачем), что ещё сильнее ограничивает аудиторию даже в сравнении с платформерами.
А узкой аудитории сложнее угодить:
>Хороших метроидваний мало
Потому что даже в такой узкой ЦА есть свои мелкие категории игроков, которым нравится разное в этом специфичном жанре. Что одному - шедевр 10/10, то другому может совсем не доставлять удовольствия. Ошибиться с гиперказуалкой, очевидно, сложнее.
>Сделаешь хорошо - заработаешь нормально.
А сделает норм - убьёт лет 5 на ассеты, отладку и "полировку", которую оценят 3.5 ценителя и лишь 1.5 из них похлопают по плечу и скажут "малаца", а двое других обосрут с головы до ног по пустякам...
Я не предлагаю бежать делать гиперказуалки, нет. Гиперказуалки лезут по головам друг друга, сжигая бюджеты на рекламу, которого у вас всё равно нет. Впрочем, цена обосрамса невелика - пикрил даже с графикой и геймплеем можно сделать за неделю, наверное, останется только рекламу прикрутить и оформить страничку в маркете. А потом только наполнять контентом, если игра реально взлетит. Банально более разумное вложение, если волнует исключительно прибыль с игр, а не Игра Мечты.
>уже меньше 200 фпс показывает
Это ни о чём не говорит. Сколько юнитов в пике? А вариантов юнитов (уникальных)? И на каком железе тестируешь? По графикам смотришь или просто так следишь за циферками на экране? Цифры могут и сглаживаться по сравнению с реальной нагрузкой.
>у меня в запасе еще 140 свободных кадров
Во-первых, по-хорошему считают миллисекунды - стандартные 60 фпс это 16.6 мс примерно. Это типа "бюджет кадра". С этой метрикой проще работать - к примеру, если что-то требует для вычислений 20 мс, возможно размазать вычисления по 4 кадрам, и в результате у тебя будет только +5 мс нагрузки. А в абстрактной "частоте кадров" так не посчитаешь. Аналогично если можешь использовать потоки - ресурсоёмкий процесс на 20 мс на 1 потоке может сократиться до 5-6 мс на 4 потоках, что, опять же, не посчитаешь в абстрактных "кадрах в секунду".
Во-вторых, ты должен оптимизировать сильнее, не растрачивая все 16 мс на своём железе. Нет, если ориентируешься на консоли - там да, можешь 16 мс потратить и твоя игра 100% будет хорошо работать, поскольку у всех игроков одна и та же консоль (ну, теоретически должна быть одна и та же). Но на ПК столкнёшься с тем, что разное железо даже одной ценовой категории работает по-разному, фоновые процессы по-разному отъедают ресурсы компа, и банально перегрев и троттлинг могут сделать игру неиграбельной на "рекомендованном железе". На мобилках тебя ещё будут ругать за то, что телефон раскаляется и обжигает руки с тупой 2D графикой посильнее, чем с продвинутой 3D графикой, лол.
Короче, если хочешь дрочить на оптимизацию и максимальное число юнитов - дрочи правильно. Ориентируйся на хорошие игры, а не симуляторы троттлинга с кучей лишней мишуры на экране.
>Сколько юнитов в пике? А вариантов юнитов (уникальных)?
10К vs 10К.
Пока три класса разных, воин-маг-лучник.
В целом видюха тут не сильно важна, там микро объемы памяти потребляются, а вот проц важен. У меня i5 не самый свежий.
Понятно, что железо у всех разное, но я все равно потом всё буду под геймплей затачивать, там вряд ли так много юнитов нужно будет. Просто стресс-тест.
просто круто, хоть сам в вампайр не людлю, но старик или дов, где можно анигиллировать толпы врагов и стоять на горе из трупов, любо дорого.
Что думаете о механике, которая требует от игрока двигать RIgidBody3D в пространстве без выключения физики и коллизий (т.е. без превращения в Static/Kinematic/Area3D)? Что-то вроде той штуки из Half-Life... ну, вы знаете, о чём я... Думаете, Jolt вытянет это без лишней тряски, провалов "в текстуры", резких запусков в стратосферу и т.п.? Я когда-то что-то такое прототипировал, но работало как-то не очень (какой физический движок был - не помню), так что теперь пытаюсь собрать мотивацию на вторую попытку (спустя очень много времени и версий движка). Ну и не совсем понятно, насколько "честной" такая механика считается игроками - видел всего несколько нишевых игр с ней, во всех остальных тела превращаются в статики или вообще становятся неосязаемыми для окружающей среды в "руках" игрока...
Да это вообще не вампайрик, это скорее фрейворк на основе годота чисто, чтобы можно было делать огромные армии юнитов. Геймплей в этом плане можно потом додумать, важно, что юнитов много и это работает.
В прошлый раз разве не обсуждали что стоит делать что-то типа ShapeCast?
О, кто то посмотрел видосик про откопанную 14-летнюю технологию Silhouetted Parallax Occlusion Mapping
https://godotshaders.com/shader/improved-spom-with-outline-detection-and-self-shadowing/
https://www.youtube.com/watch?v=TUAyiCswYt4
https://godotshaders.com/shader/improved-spom-with-outline-detection-and-self-shadowing/
https://www.youtube.com/watch?v=TUAyiCswYt4
>когда-то что-то такое прототипировал
Ага, нашёл свой код трёхлетней давности и немного причесал.
В общем, я сейчас поигрался и увидел следующие проблемы:
- игрок может взлететь на RigidBody3D словно Мюнхгаузен;
- RigidBody3D может продавить игрока сквозь/внутрь пола;
- трудно подобрать оптимальное расстояние/силу влияния.
Наверное, если повесить стопицот if-else, всё решаемо...
На движок такое вообще никак не влияет. Зря волновался.
>В прошлый раз
Это когда было? В 2023?
>делать что-то типа ShapeCast?
Мне внезапно захотелось "натуральное" поведение...
Но это не главное... Покажу целиком, когда/если сделаю.
https://godotengine.org/article/dev-snapshot-godot-4-7-dev-5/
Дев 5. Перекатываются на новый ассет стор, всякое для гуя-интерфейса, превью шейдеров, прямоугольные омнилайты, 3д вертекс снап в редакторе и feature freeze.
Дев 5. Перекатываются на новый ассет стор, всякое для гуя-интерфейса, превью шейдеров, прямоугольные омнилайты, 3д вертекс снап в редакторе и feature freeze.
Можно выжимку по поводу нового ассет стора? У меня без квн не открывает и я заебался юзать бесплатные прокси которые сдыхают через день
РиджидБади это самая пидаристическая хуета из всех Бади нод, что 2д что 3д. Сфера применения очень узкая походу, я их юзаю только для мелкой шняги типа гиблетов врагов/объектов.
>Assetlib: Port asset store to new API
>Did you know we have an overhaul to our asset store in the works? Well… Now you do! Michael Alexsander has been hard at work bringing our current system into this new paradigm, culminating in GH-112992 fully supporting the new API. While we hope to showcase details on this new system in the future, for now we’ll simply highlight the more obvious improvements that this PR delivers.
>Starting with the main selection screen, the way we display our asset items has been polished. Not only will it be easier to parse the asset items themselves, but more metadata and the current rating will be readily visible.
>When accessing an asset in isolation, you’ll have immediate access to the current description and all existing changelogs. What’s more, the ability to change an asset’s version is now just one click away.
Я только не понял это они существующий ассетлиб обновляют, и подгоняют опору под новый ассет СТОР, который https://store.godotengine.org
Братан, КВН 100р стоит и оплачивается картами МИР, камон, без КВНа лучше уже не станет
>превью шейдеров
Оооо, перекатываю свой проект на эту версию.
Алсо, сделали раздельную загрузку export template.
>выжимку по поводу нового ассет стора
Пофиг на него, ничего особенно важного не было, платность ассетов не сделает их лучше/надёжнее. Отключил себе вкладку "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, это для тканей всяких. Насколько я понимаю, там всё намного сложнее и проблемнее, но сам я их никогда не трогал (только в блендере с симуляцией тканей возился немного, но там-то она не в реальном времени вычисляется).
>3д вертекс снап в редакторе
Вот бы мне в тройку такое, эх эх
Сделал на ригидбоди чуть ли не больше игр, чем на кинематичном. Мяч в футболе, игры типа боулинг/гольф/бильярд, где ты пуляешь шары, пара игр с контроллером аля ракета. Гоночки, как на аркадном варианте где машинка это иллюзия на шаре, так и простые, где vehiclebody - а он наследник rigidbody. Туда же авиасим, правда я подзабил, но там тоже подход через наследование от него и воздействующие СИЛЫ через аэродинамические поверхности (уже кто-то и аддон написал за меня, удобно). 3д платформер тоже ради эксперимента делал, там физика больше на астронавта внутри полой земли была, хотя можно было гравитацию и кинематику считать в скрипте.
Каждый раз когда я чё-то пытаюсь сделать в 2д я понимаю что в 3д это сделать тупо проще. А на выходе 3д ещё дороже смотреться будет. Ну это не считая UI.
У меня обратная ситуация, всю жизнь думал вот бы замутить свой бумер шутер, чтоб всё в тридэ и с модным стильным крэйзи грэфоуни.
Но вот пришла пора вкатываться в хэймдэв, разумеется с простого и понятного ДАЖЕ ДАУНУ годотля... Теперь третий месяц пыхчу над своими двадэшками понимая, что если и решусь пытать 3D, то буду месяцами полировать табуретки, как тот чел со вкусом очка.
>что если и решусь пытать 3D
А ты решись, там не всё так страшно. Но сначала конечно свой 2д проект доделай быстренько
>feature freeze.
Какой-то слегка проходной релиз в сравнении с предыдущими. Но может хоть не развалится ничего и не придется делать кучу 4.7.x версий. Может даже удастся спокойно переехать?
Пройдись по всем девблогам, там суммарно кучу уже напихали. Думаю больше чем в 4.6
Учитывая контекст вебм - скорее звучит как сарказм.
мимо
И 2д и 3д страшно, но страшно по своему. А код страшно по другому. Поэтому нечего бояться, надо просто выбрать в чем будешь прокачиваться, что больше лежит душе и вперед. Главное не лениться
Сап, годобояре. Закончил очередную поделку на джем за неделю, можете чекнуть.
В геймплейном плане роста особо нет, однако стиль и графика стала на пару уровней выше. Плюс впервые поработал над постановкой игры — понравилось. Хотел ещё поучаствовать в ludum dare, но оказывается он уже заканчивается, лол.
https://rouw-x.itch.io/miranda-vhs
В геймплейном плане роста особо нет, однако стиль и графика стала на пару уровней выше. Плюс впервые поработал над постановкой игры — понравилось. Хотел ещё поучаствовать в 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, чтоб выделялась слюна и хотелось там жить и фантазировать как этот шейдер мягкой шёлковой травы щекочет щёки под солнышком средь чиста поля.
А в реале что? Ну выйти в лесополосу можно, да, там обоссанная примятая трава, торчки ищут клады, гавной ваняет, клещи так и норовят лишить жизни если не в ту травинку присядешь. Короче экстрим для потенциального "человека будущего".
Мне потому лоу-поли графон даже ближе к "реальности" кажется, ну висят три травинки на кочке - так и в реале они такие же реденькие и неидеальные, а под ними та же говняная текстура земли в серо-буро-зеленых тонах. Всё как в реальной жизни!
У меня сейчас под рукой нет фото, вот пик из интернета чтобы понимать
Гавно графен уровня 2008го))
С 4.3 до 4.5 и 4.6 оч много классного добавили. И кучу багофиксов и оптимизаций. Но 4.3 подозреваю где-то стабильнее, да.
Как запретить игроку пикрилы?
Кто-нибудь помнит?
Я забыл...
Кто-нибудь помнит?
Я забыл...
Эх, превью только для fragment-шейдера работает, и только для строчек, присваивающих какое-то значение какой-то переменной. Но и то достаточно полезно будет, особенно для 2D эффектов.
Ещё заметил, что они опять дизайн консоли вывода изменили. Теперь кнопки снизу, на строчке фильтра/поиска, и консоль по умолчанию имеет очень мелкий размер, строчки 3 или 4 всего. Не пугайтесь, все функции вроде бы на месте, только положение кнопок непривычное.
Мне они пока не нужны, но я всё равно пощупал AreaLight3D. Вообще не понял смысла этой ноды - свет кажется почти неотличимым от SpotLight3D с шириной около 90 градусов. Какая-то разница заметна только на тенях - у Area тени более размытые по умолчанию и, внезапно, без артефактов. На демонстрационной сцене, видимо, установлены полигоны с высоким emission, а не только лишь AreaLight3D? Я-то думал, AreaLight3D сама создаст светящийся прямоугольник, а она невидимая... Впрочем, это точно как с другими лампочками: SpotLight3D не видно без меша-фонарика... В настройках ноды AreaLight3D позволяет установить текстуру, и она как-то вроде влияет на свет, но мне не удалось увидеть какой-то особой разницы с, например, круглым "фильтром" (использовал GradientTexture2D). Почему?.. Странная нода - вроде нужная, а вроде и нет...
Также заметил, что убрали кнопку быстрой смены рендерера из правого верхнего угла... Думаю, правильно сделали, т.к. всё равно перезапуск редактора требовался, и вряд ли кому-то нужно так часто переключать рендереры, если они не делают игру одновременно под несколько платформ.
Оптимизация отображения массивов в инспекторе - самая лучшая фича этой версии, лол. Наконец-то можно нормально видеть значения в массиве даже с узким инспектором, а не какие-то огрызки, ради просмотра которых инспектор приходилось очень сильно растягивать. И почему раньше не сделали...
>AreaLight3D
Может быть, теперь анон сможет сделать световой меч
Может быть, теперь анон сможет сделать световой меч
Ну потом, когда выйдет стейбл, покажу вам как с areaLight будет выглядеть. Но хз, меня и так пока устраивает, все равно это не подразумевалось как световые мечи
А я успел навайбкодить за полдня
Вот для такого невообразимого скота мы и делаем игры. Точнее вы делаете. А я ебал. Нахуй.
Что там было? Что-то плохое?
В настоящем киберпанке живём: все развлечения запрещены большим братом, но можно попросить электронный сверхразум, но он ничего не умеет...
>прямоугольные омнилайты
>сделать световой меч
Анон ошибся в посте, а вы не поняли?
AreaLight3D светит только в одну сторону. Для меча потребуется минимум 2, а то и 4, если он толстый. И материал с высоким emission по-прежнему нужен, поскольку без него источник света будет невидим. Единственный плюс - это мягкие тени без глюков. Пиксельный шейдер эти тени всё равно скукожит...
>когда выйдет стейбл
Да вроде уже сейчас неплохо работает...
Учитывай, что AreaLight3D - это для forward+, а для остальных хуже будет работать (я не проверял, но в документации ноды много каких-то ограничений). В пиксельном стиле вообще бессмысленно, имхо...
Там 3gp с кнопочной мобилки
А ты не пробовал через архив интернета смотреть?
я б написал еще несколько простых способов, но тут неуместно наверное
купи впску за 300 руб/мес и накати туда amnezia vpn
честно говоря не понял в чем суть такой острой реакции, возможно это просто бот который хуйней бампает треды
> не понял в чем суть такой острой реакции
Потому что ты такое же гыгыкающее быдло, как и аффтар этой дрисни. Ты искренне удивлён "а чё не так та, ёпта, нах?" До тебя даже не доходит, какое это омерзительное скотство.
Маэстро, спасибо что почтили нас своим визитом! Арию споете?
Делайте игры. Для арий есть отдельная доска.
У меня кстати симулятор арий недоделан.
Спасибо, улыбнулся.
>за 300 руб/мес
Чтобы потом круглый день сидеть на этом ютубе и спонтанно кликать на каждую рекомендацию, потом очнуться в 18:00 утра следующего дня с кучей новых вкладок браузера, содержание которых не помнишь, мучаясь от обезвоживания, голода и бессонницы? И десятками гигабайт скачанной с ютуба порнухи...
>не понял в чем суть такой острой реакции
Ты запостил какие-то круги и написал "навайбкодил". Непонятно, что это означает? Ты попросил ChatGPT нарисовать тебе круги? И потом запостил сюда PNG? Странный пост. Хоть бы объяснил, чего ты хочешь. И непонятно ещё, зачем ты запостил это в ответ тому, который свою игру на итч опубликовал. Где смысл?
Завязывай с
>гыгыкающее быдло
>омерзительное скотство
Тред любви же, мы должны быть добрее ко всем.
> Спасибо, улыбнулся.
В треде любви и добра придётся относиться с пониманием к таким, кто улыбается с этого скотобожества.
Он увидел игру где непонятно что делать, какие то круги, палки, и запостил олдовый мем, такие вещи правда надо объяснять?
Вы уже спели арию?
> олдовый мем
Омерзительная быдляцкая идиотия
Собираю движок из сурса, никогда раньше таким не занимался, я хлебушек. Получится из под винды собрать экспорт темплейты под все платформы или придется сильно пердолиться? Нужно ли WSL поднимать, чтобы скомпилить шаблоны под Линух? Доки немного в ступор ввели. И честно говоря, в линухе столько дистров, что и непонятно под какой компилить. Как вы решаете эту проблему?
Поставь виртуалку с линуксом и собери там.
Хватит одной виртуалки с одним дистрибутивом, чтобы собрать под разные дистрибутивы Линукса? Если на Hyper-V подниму Убунту, этого достаточно? А как с МакОС быть, например?
Короче сообщу вам что сделал при загрузке caching room, который подтягивает все сцены, проходится по ним, и дергает их эффекты/партикли. И все это скрыто под лоадинг скрином. Теперь никаких микрофризов при компиляции в рантайме, все силки смуз. Работает лучше чем асинк и прочие убершейдеры. Просто, тупо, надежно.
Да ты какой-то махровый илитарий застрявший в позапрошлом десятилетии. Ну либо школотрон-ситх возводящий всё в абсолют.
Зачем тебе под все платформы сразу?
Под веб и Android точно получится, под iOS - нет.
Под Linux можно через WSL. Дистрибутив не важен.
Про Mac без понятия, но это очень редкая система...
А для чего собираешь? Какой-то особый модуль?
И насколько это удлиняет загрузку игры?
А что ты делаешь при повторном запуске?
>кто улыбается с этого скотобожества
Ностальгия по временам ИК-портов в телефонах...
> Зачем тебе под все платформы сразу?
Так ведь лучше сбилдить под все возможные, разве нет? Так удобнее потенциальному игроку.
> А для чего собираешь? Какой-то особый модуль?
Вырезал ненужный мне функционал, оптимизировав размер, и прикрутил пару экстеншенов для удобства, да. Ничего особо сложного, но нужный шаг.
Попробуй github actions, они же собирают все билды, сам годот же там собирается вроде под все ОС. Если правильно понимаю, если ты сделаешь публичный форк - то бесплатно, а если приватная репа - сколько то раз в месяц, но часто тебе и не нужно.
>И насколько это удлиняет загрузку игры?
На ~1 секунду.
>А что ты делаешь при повторном запуске?
Без задней мысли снова запускаю кешинг рум.
Да, большие дяди тоже это делают. В ассасинс крид недавно играл, он на каждом запуске шейдеры компилирует по минуте. Смотрел я на это и подумал что стоит сделать так же
Где можно подробнее про это изучить/почитать?
Ну то есть вернулись к технике 3-й версии пятилетней давности с вращающимся под землей кубом.
Спасибо, полезное.
Жесть какая. Для двадэ тоже таким надо обмазываться? Вот я запилил шейдер дисторшена на сцену Explosion, собсно при каждом взрыве эта сцена инстанциируется. В целом вроде норм, но емнип сталкивался с микрофризом при первом взрыве после запуска игры. Это я трясунчик и мне показалось, или реал придётся вкатываться в этот костылинг?
Конечно. 2D, 3D шейдеры - это одно и то же где-то под капотом, отличия лишь во внешнем API, упрощающем некоторые операции. Не парься, шейдеры хранятся на компьютере игрока, и после первого запуска таких микрофризов не будет, если игрок не очистит кэш.
Я б предпочёл видеть, как игровой мир постепенно погружается вокруг игрового персонажа, чем ждать мучительно долгой загрузки, теряя интерес к игре...
>лучше сбилдить под все возможные
Wine есть и на линуксе, и на маке. А для мобилок и браузеров требуется мудрить с графикой и UI/UX, в противном случае неудобно/невозможно играть. Нативные билды - это хорошо, но не прям такая уж необходимость для каждой инди-поделки v.0.0.1.
>ненужный мне функционал
Сегодня ненужный, а завтра опять билдить...
>оптимизировав размер
Для десктопа это давно уже не имеет значения.
>прикрутил пару экстеншенов для удобства
Если они работают только в редакторе, и не имеют отношения к самой игре, то тебе нужен editor build, а шаблоны экспорта можешь юзать официальные. Кастомные шаблоны экспорта нужны только если используешь модули, меняющие работу движка в процессе геймплея или загрузки ресурсов.
Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты. А мне как раз темплейты нужно скомпилить, там такое не удастся сделать.
> Wine есть и на линуксе, и на маке
Тоже правда. Вообще я почитал, оказывается, не редкость ситуация, когда через Wine работает лучше, чем нативно. С чем связано - не знаю, но много такого встретил пока изучал. Пожалуй, действительно пока обойдусь одним билдом. Так и поддерживать легче, а на мобилки я лезть не планирую, там в одну сторону дорога...
А я на тройке и сижу, лол.
Да в общем-то я все рассказал. Можешь скриптом пройтись по списку сцен и динамически их подтянуть в кешинг рум. Можешь вручную расставить-настроить. Всякие уй-элементы с шейдерами не забудь, WorldEnvironment, освещение. Потом рекурсивная функция, которая триггерит емиттинг на всех партиклях, что найдет. Если у каких-то твоих сцен есть что-то свое, что лезет в материалы и меняет им флаги, типа транспарент/емиссив, это тоже стоит триггернуть.
>не редкость ситуация, когда через Wine работает лучше, чем нативно. С чем связано - не знаю
Да, потому что криворукие игроделы вспоминают о кроссплатформе за неделю до релиза и думают что ее изи обеспечить одним чекбосом при билде. А потом оказывается что они прибились к какой-нибудь third-party либе, у которой только виндовая версия, или таргет ОС не поддерживает конкретно те вызовы, которые они используют, а кроссплатформенные вызовы они в доках вычитать поленились. Таргет платформы тестить надо всегда-постоянно. Сколько раз у меня было когда на десктопе все работает, а на мобилках идет по пизде потому что там чипы порезанные, или андроид апи пермишены хочет, или арм тупит и надо шейдер под него переписывать.
> Можешь скриптом пройтись по списку сцен и динамически их подтянуть в кешинг рум.
Шейдеры - это ресурсы. Если хранить их отдельно файлами ты можешь пройтись чисто по шейдерам, не трогая сцены, а потом сцена, когда будет загружаться, она увидит, что её шейдеры уже загружены и возьмёт их. Потому что ресурсы - синглтон.
>Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты
Хз с чего ты это вхял. Там билдится все.
И правда. Видимо я не тот воркфлоу смотрел. Не дашь ссылку?
Спасибо. Действительно, я каким-то образом в другом источнике смотрел. Изучу вопрос с github actions.
Я когда разбирался, работало вроде так. Делал форк репы, вносил свои изменения. Когда в репу прилетает новый коммит, вызывается ребилд всего. Я у себя отключал ненужные платформы соответственно.
Можно переделать на какой то другой способ, чтобы запускать вручную, но мне было лень.
Изучаем проблематику:
https://www.youtube.com/watch?v=HciqfEeUFSw
https://www.youtube.com/watch?v=HciqfEeUFSw
Если тебе интересно, на пикрилах результаты опроса пользователей Godot за 2020 и 2025 годы. Как видно, большинство работает на/таргетит Windows; Linux по популярности второй за счёт большей доступности; экспортируют на Mac больше, чем работают на нём (наверняка с помощью стандартных шаблонов).
>Потому что ресурсы - синглтон.
Это неправда, потому что их можно дублировать, и доступность ограничена локальностью. Тот факт, что загрузчик данных не делает повторных чтений, не превращает класс ресурса в "синглтон". По смыслу к синглтонам ближе всего static var/func, но это другое.
>увидит, что её шейдеры уже загружены
Для этого нужно где-то сохранить ссылку на ресурс. Отдельная от компиляции шейдеров тема, но тоже полезная, особенно касательно системы частиц - она микрофризи(т/ла) при каждом чтении с диска, т.е. рациональнее держать ссылку и не отпускать.
Если кому-то интересно, я недавно осознал, что нет необходимости выводить материалы и частицы в основном Viewport сцены и затем перекрывать его непрозрачной заслонкой. Можно использовать SubViewport, главное настроить его как-то так:
>size = Vector2i.ONE
- чтобы не было бесполезной нагрузки;
>render_target_update_mode = UPDATE_ALWAYS
- чтобы рендерилось без отображения;
>own_world_3d = true
- чтобы скрыть объекты от основного.
Дальше добавляем ноды:
>SubViewport
>_ Camera3D
>_ то, что рендерим
Созданную текстуру просто игнорируем.
Я не проверял пока, но такой подход должен быть эффективнее, чем основной вьюпорт. Если он вдруг откажется работать, попробуйте увеличить size до небольшого размера в степени двойки (x16, x32).
Пиши сразу описание видео и своё мнение.
А то твои ссылки на ютуб выглядят как спам...
А прикинь, игра: GODOTA
Там, карочи, играешь за менеджера, в качестве оружия у тебя шина сигналов, на спине у тебя сидит синглтон и играет в змейку!
Там, карочи, играешь за менеджера, в качестве оружия у тебя шина сигналов, на спине у тебя сидит синглтон и играет в змейку!
Тебе надо было на лудум даре с таким зайти побеждать, там как раз тема сингалы была
Там слишком крутые чуваки, я стремаюсь даже начинать там участвовать.
Ага, там была команда мидлов 10 человек.
Результат? "Мы не успели, игра совсем не готова".
>Ребят, а где можно посмотреть нормальную архитектуру игр на годот?
https://www.youtube.com/watch?v=xPLbrgEQLqA
Красивое показывают
Когда закончу с игровыми механиками, хочу запилить свою модель персонажа и перенести скелет, чтобы реюзнуть анимации гобота из gdquest-пака с персонажами.
1. Есть ли какие-либо автоматизированные инструменты для этого?
2. Какие подводные камни могут ожидать и как их обойти?
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 обсуждали уже? Как он на годоте себя чувствует? А то я без видимокарты сейчас, не проверить. Помню, когда он еще был на юнити, он был ужасен, но это была совсем ранняя версия.
Что-то обсуждали в прошлом треде:
Критику можешь почитать в движкосрач-треде...
Собсна обсуждать-то тут нечего. Вышел и вышел.
Ну тут можно догадаться кто подгаживает.
>кто подгаживает
Эм, кто? Я не слежу за трендами...
Они там против игры или против движка?
Конечно же тарков
Кто-кто, шизик из движкосрач-треда, создал 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д игра, 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, вот что-то из этого.
Ты радиус агентам не забыл прописать?
Так я и думал, что ответ будет - "нинужно"
а разводы от дождя ты как сделал? Типа на определенной высоте спавнишь декали и удаляешь?
Если надо сохранить временный файл в рантайме, куда его писать? К темп-директориям годот же доступа не дает? И остается только user://, за которым потом следить и вилкой чистить.
Да вроде бы норм работают тени из коробки.
Дождь я делал по этому видосу:
https://www.youtube.com/watch?v=cZ5Ang_Ji8E
Если вкратце, то следы от дождя это отдельные партиклсы, которые настроены как сабэмиттер дождя и спавнятся, когда дождь коллизится с поверхностью.
>Так я и думал, что ответ будет - "нинужно"
Ну так реально нинужно, в юнити есть аналогичная проблема с количеством скриптов, просто апи лучше прописано и пропуки начинаются не на 300 нодах, а на 3000, сути проблемы это не меняет - вызов с# метода дорогой и с этим нихуя не сделать. Для большинства случаев это терпимо
Во-первых, при каких таких обстоятельствах вообще может понадобиться сохранить не пользовательский файл в рантайме, неужели нельзя все те же данные положить просто в переменную?
Во-вторых, не забывай про многопользовательские системы. Если ребёнок играет у меня на компе, он это делает в своём профиле и не засирает мне стим своими фнафами. Софту не позволяется срать временными файлами, значимыми лишь для одного юзера, в общесистемные папки.
В-третьих, если сохраняешь временный файл, будь добр подчисть за собой в любом случае, не полагайся на системные механизмы.
Какой-то финн делает игру с явно русским названием и каким-то постсоветским сеттингом. Приходят фанаты сталкера и таркова, начинают вонять. Я не утверждаю стопроцентно, что всё так, просто предполагаю.
>Если скрипту не нужен process, зачем вообще такой ноде скрипт?
Вообще, есть много других встроенных коллбэков. Срабатывать кажды кадр нужно только всяким подвижным хуйням типа персонажей. Всем остальным надо в основном отзываться на сигналы: получать дамаг, откликаться на пересечение ареи - всякое такое.
>ответ будет - "нинужно"
Ответ на что? Промотай ветку, там вопрос был вообще о другом.
В доках есть 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+ фпс, чего достаточно для игры.
Господа Годот'еры, кто знает как можно вытащить текст из игры для собственноручного перевода?
Раньше не имел опыта перевода игр на годоте.
Имеются вот такие файлы с пиков, так понимаю сам годот их пакует?
Раньше не имел опыта перевода игр на годоте.
Имеются вот такие файлы с пиков, так понимаю сам годот их пакует?
Благодарю, потыкаю.
Обычная хентай игра, ничего такого. Можно в настройках выключить хентай элементы и играть как в обычный файтинг.
Единственная проблема со светом и тенями пока, это пиздоблятские просветы по углам в помещениях. Как это фиксить я совершенно не понимаю. Видимо придется делать дома в виде отдельных локаций с подзагрузкой.
> Лампочка должна отреагировать на нажатие кнопки единоразово, то есть у неё есть какой обработчик:
Я вам даже больше скажу, такие штуки как visible вынесены сеттерами в АПИ ноды, и вышеописанный код можно вовсе не создавать, а настроить через инспектор коннекты к сигналам.
Но, разумеется, так можно настроить только очень примитивные штуки, типа переключения видимости.
Вот так этот коннект запишется в tscn файл:
> [connection signal="toggled" from="Button" to="Icon" method="set_visible"]
Делай меши толще, с пересечениями между собой. Поправь shadow bias. Включи contact shadows
Свиндот? Что за перфоманс.
Повтори, что?
Ты поставил смысловую ловушку. Теперь, если я повторю, ты уличишь меня в том, что у меня обозначенная на пикче проблема. Правда, ты не учел, что одного признака недостаточно для постановки диагноза. А еще ты не специалист, чтобы делать такие выводы, они сложны. Можно легко запутаться, и ты уже запутался.
Так что сказать-то хотел? Чего триггеришься, столько наподчеркивал, старался, время тратил. Ты охотишься на шизов в этом треде, у тебя тут поляна?
Свиндот.
А почему раннеры никто не делоет?
Помню кто-то делал пару тысяч тредов назад
На godot 4.6.2: please don't crash edition будут ещё патчи стабильности?
Будут. На каждую. Больше нет нужды задавать этот вопрос.
сорян, я залётный. Читать тред нет времени.
Верим.
Тридешники в треде?
Кто-нибудь тут может объяснить, почему эта игра так... стрёмно выглядит? Не в обиду автору(ше), игра вроде хорошая, но визуально выбивается из современных в нехорошем смысле. Будто бы чего-то не хватает, но не понятно, чего. Это из-за чисто чёрных теней? Или там источники света какие-то не такие? Они вообще есть? Можете пощупать демку, но я чисто по скриншотам и трейлеру сужу... Видел на реддит несколько раз за последний год или два. Имхо, у этого разработчика проблема с цветовосприятием. Жалко его/её...
https://steamdb.info/app/3689220/screenshots/
Да, вроде в старых тредах обсуждали, не помню уже.
Кто-нибудь тут может объяснить, почему эта игра так... стрёмно выглядит? Не в обиду автору(ше), игра вроде хорошая, но визуально выбивается из современных в нехорошем смысле. Будто бы чего-то не хватает, но не понятно, чего. Это из-за чисто чёрных теней? Или там источники света какие-то не такие? Они вообще есть? Можете пощупать демку, но я чисто по скриншотам и трейлеру сужу... Видел на реддит несколько раз за последний год или два. Имхо, у этого разработчика проблема с цветовосприятием. Жалко его/её...
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
>стилизация
Для широкой ЦА нужна более сочная графика, в особенности с учетом сеттинга "светлое будущее". Пастельность или нет - это тут не касается никак.
...Да даже, вон, в DRG - мрачные пещеры - всё ярко и насыщенно, хотя игроку нужно буквально рыться в инопланетной грязи и говне. Так что стилизация не соответствует ни широкой ЦА, ни сеттингу игры.
В общем, жаль автора. Даже хотелось ему помочь... Наверное, можно попробовать распаковать демку и поковыряться в настройках Environment? Если там стандартный проект на GDScript, должно собраться.
ты не заметил что там текстур нет?
А это правда что ААА часто используют SQLite для сейвов?
нет, это неправда
>Сделал динамическую смену времени суток
Ты молодец, для прототипа замечательно, но у тебя основной-то геймплей игры есть? А то так можешь закопаться в тонкие настройки, добиваясь идеальной погоды, а к основной работе над игрой так и не дойти.
На будущее, во время дождливой погоды (особенно штормовой) рекомендую изменять дальность fog в настройках Environment, чтобы ландшафт и объекты вдалеке от камеры были более серыми. Тогда будет реалистичнее выглядеть без лишних частиц.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
>Единственная проблема со светом и тенями
Документацию читал? Там всё с примерами:
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. Т.е. когда противник видит игрока, он просто идёт по прямой, в противном случае ищет путь через лабиринт.
>есть ли смысл для пиксельного 2д рпж рогалика пересаживаться с 4.3 версии на актуальную?
Имеет, там много разных фиксов и оптимизаций, касающихся любых игр. Версии 4.3 и 4.4 уже не поддерживаются, т.е. не получают багфиксов. По рекомендациям разрабов Godot, до выхода 5 всем желательно обновляться до актуальной версии. Копипастишь папку проекта, открываешь копию в следующей версии, и в 99% случаев проблем нет. Рекомендую удалить шейдеры из папки .godot, они зачастую заново компилируются новой версией.
Нет, он делает правильно, что делает прототип - вертикальный срез и сразу увидит какие технические ограничения может упереться. Причем даже если он не будет делать эту игру, такие знания помогут для более мелких игр.
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 вышла. Подготовил вам пост с чейджлогом, а с компа его не запостить - бан, который мне лень вилкой вычищать. Сами квны включайте и смотрите. Вахтеры с айкью хлебушка.
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
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, который реагирует только на изменения параметров? А так разве не выйдет по одному материалу на одно дерево, или я и тут тоже туплю? Если не выйдет - вроде неплохой вариант, но это разве не костыль? Может, я какой-то очевидный базовый функционал проебал, вот и задаю тупые вопросы?
Вот у меня есть, например, один настроенный StandardMaterial3D или шейдер для деревьев. И штук 10 текстур деревьев, и, может, еще 1-2 параметра материала, которые будут меняться от дерева к дереву. Мне что, делать 10 уникальных материалов ради изменения 1-3 параметров? Хранить их прямо в сцене, или вообще сохранять все 10 материалов в папку с деревьями?..
А если надо будет изменить, не знаю, Diffuse Mode какой-нибудь - мне что, все 10 материалов прокликивать по очереди?
Ну или что, делать код, который будет подгружать один сохраненный материал и передавать в него эти самые 1-3 параметра, которые будут меняться от меша к мешу? Делать код через @tool, который реагирует только на изменения параметров? А так разве не выйдет по одному материалу на одно дерево, или я и тут тоже туплю? Если не выйдет - вроде неплохой вариант, но это разве не костыль? Может, я какой-то очевидный базовый функционал проебал, вот и задаю тупые вопросы?
Все верно, если у тебя разные текстуры, то и материалы будут разные. Так работает оптимизация, движок при рендере отсортировывает объекты по материалам, чтобы при отрисовке меньше между ними переключаться, чтобы рисовать сначала объект с одной текстурой, потом со следующей и тд (Само 3д разруливает буфер глубины).
Можно попробовать сделать один шейдер, и передавать в него разные текстуры. В 4-ке для этого приспособить instance shader uniforms.
Что сейчас разрабатываете анус, в каком жанре?
Во всех.
Маджонг клонируем.
Ничего себе, аноны уже несколько дней мои протекающие кубы обсуждают, а я про это и думать забыл.
Да я и не беспокоюсь, братан. Я просто обозначил наличие проблемы. Но это не значит, что я буду вот прям щас усираться, чтобы ее решить.
А про геймплей ты прав совершенно. Я его делаю, но он пока достаточно сыроват. Вот как доведу до какого-нибудь удобоваримого состояния, так сразу в тред запощу.
Систему динамической смены суток и погоды я вообще делать начал, чтобы отвлечься и что-нибудь новенькое попробовать. Изначально думал, что просто текстуры для скайбоксов попробую сделать, буду их как-то постепенно переключать между собой. Но в итоге эта тема меня затянула, прототип разросся и получилось (для меня по крайней мере) весьма годно.
А по теме протечек аноны выше писали использовать SDFGI, VoxelGI, дать стены толщиной в метр и т.д.
Оказалось, что у меня уже был включен SDFGI, про что я совершенно забыл, и эти утечки сильнее всего происходят именно с ним.
Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Самый лучший вариант из трех оказался VoxelGI. Подрочив настройки bias можно добиться более выраженных теней, хотя достигнуть уровня темноты SDFGI все равно не получилось. Зато почти не заметно просветов.
Делать стены толщиной в метр действительно минимизирует проблемы (но не избавляет от них полностью), но стены в метр толщиной выглядят нелепо и несуразно. Это не варик.
Другие варианты по типу отключения энвайронмента, источников солнца, запекание света и прочее не подходит по уже указанным причинам.
Да я и не беспокоюсь, братан. Я просто обозначил наличие проблемы. Но это не значит, что я буду вот прям щас усираться, чтобы ее решить.
А про геймплей ты прав совершенно. Я его делаю, но он пока достаточно сыроват. Вот как доведу до какого-нибудь удобоваримого состояния, так сразу в тред запощу.
Систему динамической смены суток и погоды я вообще делать начал, чтобы отвлечься и что-нибудь новенькое попробовать. Изначально думал, что просто текстуры для скайбоксов попробую сделать, буду их как-то постепенно переключать между собой. Но в итоге эта тема меня затянула, прототип разросся и получилось (для меня по крайней мере) весьма годно.
А по теме протечек аноны выше писали использовать SDFGI, VoxelGI, дать стены толщиной в метр и т.д.
Оказалось, что у меня уже был включен SDFGI, про что я совершенно забыл, и эти утечки сильнее всего происходят именно с ним.
Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Самый лучший вариант из трех оказался VoxelGI. Подрочив настройки bias можно добиться более выраженных теней, хотя достигнуть уровня темноты SDFGI все равно не получилось. Зато почти не заметно просветов.
Делать стены толщиной в метр действительно минимизирует проблемы (но не избавляет от них полностью), но стены в метр толщиной выглядят нелепо и несуразно. Это не варик.
Другие варианты по типу отключения энвайронмента, источников солнца, запекание света и прочее не подходит по уже указанным причинам.
рпж рогалик блят. полгода уже сука а конца и края так и не видно
Жанр писать не буду, а так делаю игру, которая покорит весь ру игромир.
Sup! Хочу вкктиться в индюшатину. Выбрал Godot. Кроме него, что ещё надо будет изучить? Blender? Если что, мне для Linux.
Чего делать-то планируешь?
Вначале что-то 2D простенькое. Потом может RPG какую. А вообще, когда набью опыта, хочу 3D бродилки делать, может хорроры.
Крита/Гимп если растром рисуешь. Аспрайт если пикселями. Блендер для 3д, блокбенч для лоуполи 3д попроще.
Посоветуйте видео уроки по Godot. Или что почитать. На русском. Спс!
Gimp больше для редактирования изображению юзаю. Вообще, тогда Блендера может хватить. Даже для 2D.
https://docs.godotengine.org/ru/4.x/getting_started/introduction/index.html
Начни с официальных туториалов, они хороши и по делу. Есть и 3д и 2д - выполни оба.
Хочю раннеры делоть
Типа Speedrunners или мобилки Vector?
Как Сабвей сёрферс и темплран
Как Haste и BOOST VECTOR EX?
Не шарю за местные преколы. Я кроме шуток хочу раннер запилить
если акк у тебя новый и игра не получает просмотры в первую неделю, то тебе надо написать в поддержку и они ручками твой новорег добавят в индексацию. Ещё очень сильно запарься с тегами и превьюшкой для игры - очень сильно решает
это шайтан на кавказе?
Да. По сюжету мы в роли горца ищем аппетитного барашка для Сабантуя. Но шайтаны балять мамю их ебаль падери не дают простым гордым народам жить
ЧЯДНТ?
Ты нахуя хардкодишь путь? Просто обьяви экспортную NodePath и в редакторе прям в нее перетяни свой лабел, он подтянет правильную дорогу и будет ее обновлять если дерево изменится.
Не ну погоди а проблема то у него в чем? Вроде и путь правильный и автодополнение сработало.
Шапка: https://hipolink.me/godothread
Предыдущий 78: (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/