Шапка: https://hipolink.me/godothread
Предыдущий 78: >>1080508 (OP)(OP)
---
Билды и шаблоны экспорта скачать бесплатно: https://github.com/godotengine/godot-builds/releases
---
Dev snapshot: Godot 4.7 dev 4 https://godotengine.org/article/dev-snapshot-godot-4-7-dev-4/
Maintenance release: Godot 4.6.2 https://godotengine.org/article/maintenance-release-godot-4-6-2/
Dev snapshot: Godot 4.7 dev 3 https://godotengine.org/article/dev-snapshot-godot-4-7-dev-3/
Release candidate: Godot 4.6.2 RC 2 https://godotengine.org/article/release-candidate-godot-4-6-2-rc-2/
>3
У вас змеечка по диагонили ходит, алло!
Подводный один, туда никто не заходит, итч не льет трафик, ты сам должен раскручивать по всяким тиктокам и прочему.
Нет, не фича, это баг, не лги себе, я полночи сидел пытался исправить баг с диагоналями у себя, и так и не смог.
Багофича: сделано случайно, но понравилось.
>пытался исправить баг с диагоналями
Ты правда код скопировал, не осмыслив его?
Добавь на указанную строчку, например, это:
>...and new_direction.x != new_direction.y:
Это должно запретить ходы по диагоналям.
Если хочешь понять смысл строчки с dot():
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-dot
Весь тот код был написан на скорую руку.
>>1083472
>А я смог
Молодец.
Этот код не реагирует на нажатие. Направление изменилось и? Таймер ждёт следующего тика. Переделывай.
В прошлый раз на чистом гдскрипте смог выжать сражения 500 на 500. Сейчас подключил C#, его либу для ECS, параллельные вычисления, рендеринг сервер, мультимеш2д, кастомный шейдер и уже 10К на 10К драки держат 100+ фпс на моём средненьком i5 процессоре.
Хотел сначала сделать видос, но шакалит люто и весит больно много, поэтому чисто скрин.
>Круто
А гейплей в чем? Игроки должны восхититься тем, что автор освоил ецс?
Ну так не пользуйся, это опенсорс, можно любой язык подключить, например C++
Да. Технология открывает возможности для геймплея - битвы 10к на 10к.
Битва 10к на 10к это не геймплей еще. Кроме мессива на экране нужно еще что-то захватывающее. А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Выглядит клево
>Хотел сначала сделать видос, но шакалит люто и весит больно много
Можно небольшой кусок снять, условно в середине
>>1083506
>А то ты как ААА кабан рассуждаешь - въебал бабла в топ графон, а никто не играет..
Я думаю дорога на восток многим из движкосрача треда подложила свинью, отчего некоторые и возбудились. Потому что кок ток то! Это жы гдскипт нююю он же плохой uuuu
Ты забыл потребовать признать это.
Ага, я очень доволен.
>>1083501
Геймплей будет, я хотел сначала сделать стресс-тест того, что это вообще жизнеспособно в годоте.
>>1083510
Ну вот тебе 5 секунд с середины, правда не уверен, что хоть что-то разберешь в этом месиве пикселей. Зато 300 фпс, хоть и скачущие.
>гдскипт нююю он же плохой
Так 2 топовые игры на годоте (sts2 и восток) - обе на шарпах. Так что гдс унижают даже в рамках годотреади-языков
>сражения 500 на 500.
Это на нодах было или уже мультимеш?
Какое железо?
Да, на нодах было.
Проц i5 12600, 16 гигов оперативки, видяха тогда 3060ti была.
Обе этих игры начинали делать на другом движке на C#, то есть тут нет никакой объективной причины в самом гдскрипте. Просто у них уже был какой то опыт и может быть какой то игровой код написан
В СУБШОТЕ уже был твой коллега.
>>1080088 →
Все это конечно классно, но интересно бы что-то приближенное к реальной игре с поиском пути. Как вот жуки в факторио. Там, почему-то, ощущается это жутковатая масса в движение (может просто игровая иммерсивность), а тут не чувствуется этого. У чела в СУБШОТЕ вообще уже на жидкость похоже.
Скорее всего начинали с юнити и потом перекатились.
>какой то игровой код написан
Слишком большая разницам, все с нуля придется переписывать, если ты прям не гуру кодер которому делать нефиг, который умудрился писать сразу через слой абстракции (да еще обобщить между двумя движками, так как заведомо ты такой код никогда не напишешь, абстракции будут протекать)
>гуру кодер которому делать нефиг,
Да это я, я как раз пишу всю игровую логику на c++ и подключаю к разным рендерам.
Как бы на шарпах тоже надо уметь писать оптимизированный код, сам по себе шарпы тебя не спасут от гадостей в игровом цикле. Да и часть API на вариантах (динамических типах), поэтому не прокрастинируй шарпами.
Все равно дотнетовские шарпы это совершенно отдельный мир. А для хоум скриптов тебе хватит петухона, который похож на гдскрипт.
1. научись делать игры.
2. научись оптимизировать игры.
3. уже потом думай что упёрса в гдскрипт (потому что очень сильно захочется сразу прыгнуть в с++).
В реале может получиться что эффективный проект будет 95% на гдаскрипт и лишь 5% на С++
Почему ты считаешь что дело только в оптимизациях? Просто у людей могут быть предпочтения к языкам и платформам. Не только к синтаксису. Особенно если люди работали кодерами. Например чел проникся реактивным программированием и хочет использовать Rx везде где можно.
мимо
>Направление изменилось и? Таймер ждёт следующего тика.
Код написан с учётом особенностей движения "змейки":
- змейка движется ПОСТОЯННО - не способна остановиться;
- змейка движется в последнем выбранном направлении;
- змейка не может двигаться назад/задом наперёд.
Итого, когда наступает очередной цикл опроса:
1. Считываем актуальные значения ввода (get_vector()).
2. Проверяем соответствие условиям движения (см. выше).
3. Если условия соблюдены, принимаем новое значение.
4. Если условия не соблюдены - движемся куда двигались.
Примеры:
- двигались вправо - нажали вправо - движемся вправо;
- двигались вправо - нажали вверх - движемся вверх;
- двигались вправо - нажали влево - движемся вправо;
- двигались вправо - ничего не нажато - движемся вправо.
>>1083492
>голова не кружится, когда вы гдскрипт читаете?
Это просто с непривычки. Так с любым новым языком.
Технический опыт показывает, что лучше брать инструменты близкие к платформе.
Ты и так будешь трахаться с проблемами, так еще добавишь слой проблем от вторичного языка.
Поэтому если андроид - то это котлин.
если айос - то свифт, а не котлин
если годот это - гдскрипт.
При этом я очень не поддерживаю идею гдскрипта, он тормозит развитие. Да, облегчает вкат, но развитие создают не они, а те авторы "востока" и прочих шумных релизов (а они нередко мигранты с юнити и шарпов. Поэтому важнее было бы облегчить им миграцию, чем тем людям которые дропнуть разработку с вероятностью 99.99%).
Меня тоже ломало от правосторонних типов 11 лет назад. Ниче, адаптировался.
На питоне почти не писал.
Пофиг на гдскрипт, надо пинать чтобы полноценный и нормальный JIT сделали.
Годот позволяет писать без узлов (эти ваши серверы). Я не копал так глубоко, но периодично натыкаюсь на всякие заманухи, которые показывают что годот можно перелопатить довольно гибко (но зачем?)
>Технический опыт показывает, что лучше брать инструменты близкие к платформе.
А практический опыт показывает, что лучшие игры пишутся лучшими инструментами (язык - тоже инструмент), к коим гдс никаким боком не относится.
>Поэтому важнее было бы облегчить им миграцию
Согласен, лучше замедлить динамикодрисню еще одним слоем, который будет перебивать строго типизированное апи в варианты, чем делать из самого апи движка этот слой. Динамикодрисне то похуй, она и так медленная, а вот нормальным языкам - больно.
гдСКРИПТ - это скриптовый язык. На нем, естественно, пишутся всякие легковесные скрипты (гуй, ввод контроллера и так далее), а тяжелые вычисления на с++. Поэтому да, игры делаются на связке лучших языков (c++ и скриптов). C# тут как видишь не участвует.
И без вас всем давно и хорошо известно, что:
- GDScript хорош для 99.9% задач, но медленный для 0.1%;
- C# любят только из-за синдрома утёнка жертвы курсов;
- C++ быстрее, надёжнее и удобнее в контексте Godot;
- каждый волен выбирать тот язык, что ему нравится;
- разработчики Godot не читают наши треды здесь;
- недовольные могут сделать себе свой Godot.
>>1083496
>500 на 500
>10К на 10К
Во-первых, даже "500 на 500" - это слишком много для любого осмысленного геймплея. Всякие тупые "vampire survivors" выстрелили не из-за количества мобов, а из-за того, что это РОГАЛИКИ с одноклеточным геймплеем и графикой, то есть легкодоступные для зумеров и личинок зумеров. Рогаликам нафиг не нужны битвы 500 на 500, рогаликам нужны совсем другие вещи и не так много.
Во-вторых, тебе удалось выжать "10k на 10k" лишь благодаря однородности твоих юнитов - их внешности и поведения. Как только ты начнёшь добавлять больше вариантов - как внешность, так и поведение - твоя система начнёт замедляться. Если ты хотел сделать стресс-тест, тогда тебе нужно было сгенерировать 10 тысяч полностью уникальных спрайтов, и каким-то образом сгененировать 10 тысяч уникальных вариантов кода, отвечающего за поведение - и я имею в виду по-настоящему уникальное поведение, то есть разные команды в коде, а не просто изменение числа в параметре. Другими словами, тебе следовало бы развернуть генетический алгоритм с интерпретатором специализированного языка программирования и нагенерировать 10 тысяч индивидов.
Короче, применённые тобой оптимизации ограничивают вариативность твоей игры. А игра без вариативности - это как песочница с одним лишь песком без игрушек. Да, ты можешь взять руками песок и пересыпать его с одного места на другое, но на этом всё. Именно поэтому такие игры как Minecraft имеют сотни уникальных блоков с десятками различных паттернов поведения и десятки уникальных мобов в придачу, а не только один тип кубика на весь игровой мир. Тот же Minecraft возможно сильно оптимизировать, если выкинуть многие детали и оставить только один тип кубика и один тип моба - но какой ценой? Ценой интересной игры, в которую интересно играть даже без модов, а моды так легко создавать, что школьники наделали, наверное, уже миллионы модов.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
>жертвы курсов
Почему курсов то? Сишорпу с дотнетом дофига лет. И отечественный софт на дотнете очень давно пишется.
Видишь ли, есть один ньюанс у годота. апи движка у всех языков одно и то же. Ну то есть у гдс, у с#, у с++, у с, у раста, у аллаха - у них у всех динамикодрисня с вариантами в качестве апи к движку. А должно быть - наоборот. У ровных языков - типизированное апи, а у опущенной динамикодрисни для домохозяек - вариант-враппер. Все равно ЦА разницы не заметит. Пока это не будет исправлено - годот будет продолжать участвовать в спейиальных олимпиадах по обсуждению его производительности.
Видишь ли, это может показаться тебе неочевидным, но у движка открытые исходники, и ты можешь вызвать любую функцию с любым нужным типом.
>Ребят, завязывайте со срачем "GDScript vs C#".
Тогда придется идти делать игры.
>динамикодрисня с вариантами в качестве апи к движку
Это хорошо. Ты не должен обращаться к API движка слишком часто из высокопроизводительного кода. Твой код получает пакеты данных от движка, обрабатывает их у себя внутри на максимальной скорости, а потом передаёт движку одной командой. Всё. Не нужно дёргать API движка каждую наносекунду. Если тебе почему-то нужно, то тебя производительность вообще волновать не должна - тебя должна волновать кривая архитектура/дизайн игры.
>Тогда придется идти делать игры.
Вот я и пытаюсь делать игру... Открыл редактор Godot, открыл несколько скриптов, потом подумал "дай гляну тред, буквально минутку и вернусь к своим скриптам", а вы тут 50 постов успели насрать буквально за пару часов. Ну сколько можно? Потерял на вас ещё пару часов. Опять день закончился, а к игре даже не притронулся...
>ты можешь вызвать любую функцию с любым нужным типом.
По поинтеру штоле? Как деды? Это нарушение изоляции, за которое я заплачу сегфолтами, на которые я никак не повлияю, даже если я захочу дергать за яйца функции внутри движка вне общего апи. Форк движка это конечно интересно, но не очень интересно
>>1083584
>Чем хуже тем лучше, только выиграли, ну подумаешь что рейкастим нодой потому что рейкастить нодой быстрее чем рейкастить через апи
И это я еще не углублялся в тему renderingdevice, там скорее всего тоже есть на что посмотреть
Но проблема ньюфагов именно в их плохом коде и понимании масштабов того, как им еще далеко до кода хотя бы среднего качества.
Я как-то в сосничестве реализовывал функции пхп на С++ и они у меня работали медленней чем на пхп. Открыл сорцы и вообще не понял что там за магия, а я верил что там просто char перебирают
Прокрастинируешь, сынок?
я сюда заглядываю утром под кофе или после работ
Почему ты считаешь что только ньюфаги хотят определенный язык использовать? Ньюфаги как раз жрут что дают, а более опытные уже имеют предпочтения исходя из своего опыта.
Ты скорее сам ньюфаг потому что все сводишь к синтаксису и какой-то мифической скорости. Не ньюфаг думал бы что хочет использовать либы к которым привык.
>использовать либы к которым привык.
Так выпьем же за то, чтобы не-ньюфаг использовал эти либы, а не срался за движки и языки вне движкосрач-треда!
> Форк движка это конечно интересно, но не очень интересно
Это единственный вариант если ты делаешь по настоящему Великую игру.
Ну так бери и используй. Опять не нюфагам что-то мешает что же такое творится то.
>Почему ты считаешь что только ньюфаги хотят определенный язык использовать?
Потому что у реального специалиста нет синдрома утёнка, он достаточно гибок.
>Не ньюфаг думал бы что хочет использовать либы к которым привык.
Завтра сделают С# первым гражданином и придет твой собрат который будет ныть так же про gdscript. Ощущаешь однобокость твоего мышления?
Отличие профессионала от ньюфага - умение адаптироваться - быть гибким, а ты ноешь, возводя свои эгоистические потребности выше профессионального скилла. Поэтому я и утрирую это поведение до ньюфажного.
Умение адаптироваться это не есть способность, когда тебя лишили авто, кататься на велосипеде сквозь ветер с дождем. Как говорится ветер в харю - я хуярю. Я таких "сенек" видел на работе. Два десятка лет пишут весь код в одном файле на десятки тысяч строк с формулировкой - так удобнее.
Как бы то ни было, ничего не изменится.
Если только МС не увидит перспективу годота и хардкорно не протолкнут свое лобби с фулл там кодерами.
Но у мелкомягких проблема с дальновидностью.
От нас с тобой ничего не зависит, даже если мы наноем 500 сообщений на двачах, все равно игру придется делать нам самим, как бы мы не злились на свою прокрастинацию и на этот неидеальный мир
>Я так понял по MIT лицензии просто нужно указать авторов в своей игре и все
Главное эту MIT лицензию сохранить, в авторах можно не указывать
Сам движок по MIT лицензии же. Чего ты сомневаешься?
А когито мне не понравился, он какой-то переусложнённый.
Наоборот. MIT не требует сохранения лицензии, но требует указания авторства.
А такое для 3д работает? Ну не 10к тыщь а хотя бы орду из 100 человек воссоздать нормально
Конечно, шарп шустрее гдскрипта процентов на 10, в специально подготовленных тестах, но всё-таки главное "узкое место" - скриптовое апи движка. Так что, для критических по быстродействию мест гдскрипт или ц# - однохуйственно в сравнении с C++.
Ну и вообще, есть простое правило. Если что-то выполняется 100500 раз за кадр, то этим должен заниматься компилируемый кусок кода (если предусмотрено, то лучше сам движок); если же до пары десятков раз - то вообще похуй, хоть жабаскрипт туда впили. Все проблемы с производительностью сводятся к тому, что криворукий кодер делает скриптами то, чем должен заниматься компилируемый код. Так что вообще забей, гдскрипт не "медленный" в бытовом понимании, просто не предназначен для некоторых специфических задач, типа управления армией в стратегии-числодробилке.
НО. Выучить C# всё равно полезно просто для собственного развития. В процессе ты сам поймёшь, что он нихуя не производительнее; однако знания - это знания, они делают тебя востребованным специалистом. Знать два языка - всяко лучше, чем знать один язык.
>однохуйственно в сравнении с C++.
Остальные языки проиграют плюсам по производительности работы с годотом только в случае форкования движка и написания кода прямо в движке, не gdextension, а прямо в движок, что тянет за собой постоянную рекомпиляцию движка для проверки функционала. В случае gdextension - производительность апи равнозначна для любого языка, и гдс, и с++ и раст и с#, что приводит к тому, что один и тот же простой код (например для управления частицами через renderdevice) будет начинать пропердывать на условных 100к частицах на любом языке, компилируемом, интерпретируемом, каком угодно. Так что не пизди, дядя
Кстати, я не разбираюсь ни в чем мною написанном, просто набросил говна на вентилятор. Но рад, что спровоцировал хорошие интересные ответы.
>тянет за собой постоянную рекомпиляцию движка
Это вообще не проблема.
>500 на 500 - много
Скачи Мочи очень популярная и успешная серия игр.
Там и поболее будет в Warband.
А так это просто нагрузочный тест, я хотел посмотреть, как сильно прокачался за пару лет периодического тыканья годота и шарпа, чтобы сравнить с тем, как было раньше. Понятно, что пока это просто месиво и геймплея нет. Но уже сейчас есть огромный запас фпс для реализации обхода препятствий, разных классов юнитов и прочего. Особенно если раза в два порезать количество юнитов и сделать бои не 10К на 10К, а 5К на 5К. Там и 500 фпс спокойно держатся на среднем проце.
>>1083653
В теории будет, но я не уверен. Я никогда 3Д в годоте не занимался. Тут практически всё вынесено из годота, у меня буквально одна нода, которая просто гоняет ECS и рисует пискели. Даже для юнитов нод нет. Это отдельные ECS-сущности и десяток ECS-систем, которые как-то их обрабатывают.
То есть даже механика коллизий в этом проекте - это ECS, а не CollissionShape годотовский. Приходится конечно вручную всё считать, но это все равно быстрее выходит, чем 20К коллижн шейпов каждый фрейм.
Когда у тебя есть команда сеньоров на зарплате? Тогда согласен. Можно из годота вообще повыдирать только самое важное (типа рендера) а остальное писать самому
>написания кода прямо в движке
Во-первых, не прямо в движке, а в отдельном модуле, статически линкуемом с движком. То есть весь твой самодельный велосипед будет изолирован в папке и обновляться на новую версию движка будет легко.
Во-вторых, Godot компилируется всего лишь час на компьютере из условного 2007 года в 4 потока. А у современных домашних компов от 8 потоков, RAM значительно шустрее и всякие новые AVX есть...
В-третьих, после первичной компиляции, тебе нет необходимости повторно компилировать исходники движка, поскольку достаточно скомпилировать свои собственные исходники (модуль) и потом всё вместе слинковать. Я тоже раньше думал, что C++ таким вот образом не умеет делать, но это реально возможно. Линковка занимает намного меньше времени, чем компиляция исходников в объектные файлы.
Так что создание модуля Godot вообще не проблема.
Проблема - придумать игру...
Красиво стелишь, но есть ньюансы
Движок должен знать что твоя либа существует, т.е. внутри него должен быть размещен функционал, который встроит твой код в пайплайн рендеринга, отправит ему состояние и применит возврат заместо gdext.
В виду того что зачастую тебе нужно не внедрять что-то новое, а модифицировать что-то уже существующее но хуево работающее - такое импровизированное апи, призванное отделить либу от кода движка - потребуется во многих местах. А еще - тебе придется самому поддерживать свои правки в обновлениях, что еще более печально.
Тебе чтобы написать команду scons platform=windows target=editor / target_release нужна команда сеньоров?... Это как анекдот про вкручивание лампочки?
>Скачи Мочи очень популярная
Про твою мочу только от тебя слышу здесь время от времени, а ведь я знаю много нишевых игр, которые никогда не станут широко известны нормисам. Ты представляешь, насколько мал охват твоей мочи? Буквально ноунейм для средневековых ролевиков.
>500 фпс спокойно держатся на среднем проце
Ты о геймплее лучше думай. 500 фпс симуляции мочи, обтекающей скачи, не делает игру хорошей. В GTA нет больших скоплений народа, но она всегда была самой популярной после Minecraft, в котором количество монстров даже меньше, чем пешеходов в GTA. А это максимально популярная игра, выше просто некуда... Хорошо, если взять что-то вроде Roblox, то может и возможно побить Minecraft, но ты видел Roblox? Там значительно хуже язык, чем наш GDSctipt, их движок принципиально не тянет адекватную графику. Пока подсчитываешь fps в своей моче, кто-то уже делает очередной культурный феномен, что запомнят все.
Трудно не прописать команду, а обеспечить причину ее прописывания
>Про твою мочу только от тебя слышу здесь время от времени, а ведь я знаю много нишевых игр, которые никогда не станут широко известны нормисам. Ты представляешь, насколько мал охват твоей мочи? Буквально ноунейм для средневековых ролевиков.
Лолблядь, как ты умудряешься обсираться раз за разом
>должен знать что твоя либа существует
Там, вроде, можно просто зарегистрировать свою собственную ноду, которую юзер будет размещать и подключаться к ней через GDScript. То есть будешь работать точно так же, как с обычными нодами.
>пайплайн рендеринга
Ты рендерер переписываешь или игру делаешь?
По-моему, речь шла о геймплейных функциях...
>поддерживать свои правки в обновлениях
Ну, попробуй документацию git почитать...
Ну если для тебя игра с 222 тысячами обзоров в Стиме это что-то нишевое, то действительно, нужно целиться тогда на майнкрафт, гта и роблокс, не меньше.
Не очень понимаю ход твоих мыслей. Если в самых популярных играх нет тысяч юнитов, то и я должен сделать их мало или что? Что за бред.
>культовый феномен
Я не думаю, что пытаться искусственно вывести культовый феномен по лекалам тех, кто это смог - хорошая идея. Может лучше сделать игру, которая будет нравиться мне самому в первую очередь?
>нищие 96к отзывов на англюсике (вери позитив)
Напомнить число отзывов пиксельной Terraria?
А ведь в Terraria и сотни мобов на экране нет...
При том у Terraria отзывы overwhelming positive.
Делой выводы @ делой игры.
>Если в самых популярных играх нет тысяч юнитов, то и я должен сделать их мало или что?
Нет, это просто значит, что тебе не нужны эти тысячи юнитов, чтоб сделать потенциально популярную игру. Конечно, ты можешь делать что угодно, просто такое количество не является обязательным условием.
>Может лучше сделать игру, которая будет нравиться мне самому в первую очередь?
Конечно, лучше. Но для этого не обязательно сидеть и дрочить байты на движке, который для такого рода мастурбации вообще не предназначен. Ты мог бы нарисовать намного больше спрайтов на голом SDL. Каждый дрочит как он хочет, и не нужно заставлять местных любителей дрочить GDScript переходить на альтернативы ради 10k одинаковых юнитов.
Так понятнее?
Никого сейчас не впечатлишь еще одной террарией.
Уникальная игра с кучей юнитов - выделяется на фоне других.
НИКАВО НЕ УДИВИШЬ ОЧЕРЕДНОЙ ТЕРРАРИЕЙ
@
ОЧЕРЕДНОЙ СИМУЛЯТОР МОЧИ - ВОТ ЭТО ДА!!!
Таких симуляторов были сотни, и где они все теперь?
Нужно что-то помимо текущих потоков тупых NPC...
Но выделится - не значит захватить внимание на несколько часов
мимо
>и не нужно заставлять местных любителей дрочить GDScript переходить на альтернативы ради 10k одинаковых юнитов
Я и слова плохого не сказал о gdscript тут и никого не призывал срочно бросить гдскрипт и перейти на шарпы. Я и сам на нём писал раньше, и был доволен.
Но сейчас под конкретно МОЮ текущую задачу мне понадобились другие инструменты, которых в гдскрипте нет, но при этом сам движок мне нравится. Поэтому я просто перешел на другие инструменты и сделал небольшой пост тут о том, что они рабочие.
Технически нужно растянуть всего на два часа, чтобы заработанные деньги не возвращали. Для этого есть разные способы, катсцены, загрузочные экраны, туториал, постепенное добавление контента, карты попросторнее с большим расстояние которое надо сначала пройти.
Таким пидарасам как ты на 59й минуте второго часа рефандят. Уёбок.
Как по мне, это имеет массу преимуществ:
- пираты и дети могут играть с остальной фанбазой;
- желающие задонатить побольше могут это сделать;
- покупателю не придётся ничего никому возвращать;
- доверительные отношения, ведь нет обязательств;
- легче получить новые взносы от старых игроков.
Основной минус - в отзывы насрать проще.
Но ненужный ассетфлип так не продашь...
И есть какие-то предрассудки (?) о F2P...
Если ты просто будешь регулярно обновлять свою игру, то пиратить её будет уже неудобно. Вдвойне если прикрутишь воркшоп. А cosmetic DLC это кал, который актуален в основном если у тебя мультиплеер и ты сервак держишь. Если делать dlc, то хорошие.
Ну, как по мне, написать модуль движка проще, чем gdextension. Я попробовал то и другое где-то год назад. Но это личные впечатления, да и в плюсах я тогда понимал сильно меньше, чем сейчас.
>>1083671
>В-третьих
Ну кстати да, это фича SCons. Вообще, жаль, что эту систему сборки поддерживает так мало ИДЕ, она пиздатая. Ну уж точно лучше, чем cmake.
>Ну кстати да, это фича SCons.
С чего ты такой вывод сделал? смаке проект тоже на разбивается на отдельные модули
cmake_minimum_required(VERSION 3.15)
project(MyProject)
add_subdirectory(module_a)
add_subdirectory(module_b)
add_executable(app main.cpp)
target_link_libraries(app PRIVATE module_a module_b)
да и вообще вроде системы сборки в плюсах следят за изменениями зависимостей единиц трансляции, а не "модулей". Перекомпиляция зависящей единицы трансляции будет если заголовочные файлы в зависимостях изменились. Если изменился cpp файл зависимости, без изменения hpp то перекомпиляции каскадной не будет
Ну да, в этом и смысл хедеров, хедеры это же интерфейс. Если интерфейс не изменился, то внутренняя реализация никак не повлияет на остальное окружение, это и есть инкапсуляция.
Смотрю вот эти изделия игросодержащие, ну графоний/спрайты понятное дело хуета уровня каляки-маляки пятиклашки в пэйнте. Потом захожу на страницу к разрабу: там среднестатистический заводчанин 35+, проживающий где-нибудь в центральной России, нередко женатик, а то и с детьми.
Что это за особая прослойка мрачных психологов такая? Почему они так любят инди двадэ хорроры (которые вызывают не столько страх, сколько кринж). Поколение читателей Стивена Кинга?
И кто вообще в такое играет кроме самих энтих разрабов и их внутреннего круга из 5 человек?
Продается потому что
>>1083811
Спокойно вон поляк уже вполне успешно 3 раза почти одно и тоже продает
А имя студии отсылает к дедам
https://store.steampowered.com/search/?developer=Harvester%20Games
>нынче
>ХОРРОР
Сколько тебе лет, 13? С подключением! Инди-хорроры сохраняют свою популярность с нулевых, когда там индюшатинка начала развиваться на движках для нормисов. Многие старые движки уже умерли, а жанр продолжает жить, потому что он просто бесконечный.
Хоррор сделать относительно легко, потому что в нём важнее всего создать эмоции, а на качество графики, озвучки и глубину геймплея наплевать. Для людей естественно бояться темноты, а в темноте попробуй отличить плохую графику от хорошей; шум, треск и остальные дефекты звука - это плюс, а не минус; для геймплея достаточно ходить и тыкаться в кнопки... Монстров нарисовать на порядки проще, чем что-то красивое, буквально любой новичок может взять и нарисовать или смоделировать что-то мерзкое. Даже упоротые анимации - плюс, а не минус для хоррора.
Но самое главное в жанре хоррора - это отсутствие реиграбельности. Люди много чего могут бояться на протяжении всей жизни, но ты не можешь пройти классический хоррор второй раз и напугаться как в первый раз. Допустим, ты боишься темноты, но ты боишься, на самом деле, неизвестности - того, что способно скрываться в темноте. Пройдя игру, ты уже знаешь, какие там монстры или про их отсутствие, и прежнего уровня страха от этой игры уже не будет.
Но от другой, новой игры? Ты будешь бояться снова, практически как с первой игрой, ведь новая, даже с аналогичной графикой, геймплеем и т.д., таит в себе неизвестность. Ты не потерял страх темноты, и ты не знаешь, что тебя ждёт в новой игре. Поэтому можно проходить тысячи инди-хорроров и это тебе не будет надоедать, в отличие от многих других жанров игр.
Вкратце:
- создать легко => низкий порог входа;
- нет реиграбельности => ниша ненасытна.
Для сравнения, жанры с высокой реиграбельностью насыщаются очень быстро и поэтому в них высокая конкуренция за игроков; например, бестолку делать собственный аналог Minecraft или Terraria, если ты копируешь их слишком сильно - игроку нет никакого интереса играть в твою игру, когда они могут влить следующие 5000 часов в старую игру и получить удовольствие на уровне предыдущих 15000 часов. Оригинальную игру в том же жанре сделать можно, однако, это намного сложнее из-за более высоких требований как к графике, так и к геймплею, и т.д.
Поэтому многие выбирают жанр хоррора.
Хорроры и порнуха вызывают одинаково аддиктивные эмоции. Об этом еще на форумах интернета 1.0 писали.
Мне показалось
> порноходы
И я уже хотел написать про Вселенную-наоборот, но потом перечитал внимательнее.
Но вообще да, во Вселенной-наоборот с толщеходами есть хоррорный элемент. Тёмные полости с погасшим ядром заселяются слепыми хищниками, которые ориентируются на шум, охотятся стаями. Хрен убежишь. Догонят и выебут. Вот вам и хоррорпрон.
Касательно слова "нынче" это я спизданул к тому, что сам начал подмечать тенденцию к засилью подобного у новичков именно ближе годов с 20х. Раньше дофига было платформеров, их и сейчас дофига, но уже как будто не модно, моднявее сделать жуууткую новелку, или бродилку по жопе негра с фонариком. Если в тридэ — всё те же бессменные вариации на тему слендермена с записками в лесу.
Вот годах в 10-20х, особенно в первой половине я видел тенденцию к платформерам с "фишкой", какая-нибудь там гравитация, отмотка времени, паззлы/головоломки по типу VVVVVV. Или там копалки-подземки по лекалам Spelunky/Steamworld Dig. Плюс ко всему артстайл в эту эпоху расцвета миллениалов был какой-то с позитивом, надеждой, все эти улыбчивые мордочки Джамп Гаев, Шот Гаев, Иван Гаев, придурошно, но по доброму, и без "у-у-у, ужастег псехологея".
Может это чисто персональное восприятие, но как правило на смену парадигмы среди сообществ людей у меня чуйка натаскана.
Суть ответов ясна: "просто сделать + сложно проебаться". Надеялся, конечно, что это всё же не от того, что народ выбирает путь наименьшего сопротивления, а скорее какая-то мода/повестка/тренды/ситуация в мире. Но спорить с мнениями не буду.
>>1083825
Интересно. Я всегда осознавал, что sex sells, но вот конкретно хорроры думал более нишевая шняга. Сам то я их стороной обхожу просто, наигрался в нулевых во всякие калл оф ктулху, скрэтчес, и понял, что революции в жанре не будет, а жрать старое под новым соусом — нахуй надо. Из последнего заценил уже считающийся "старой игрой" алиен изолейшен, ну да, прикольно, попрятаться под столами. Но в целом тягомотина же, нудятина. Хз, не получаю видать тех же эмоций, что другие пиплы от чувства страха. Лучше уж книженцию какую почитать, так иммерсия в 10 раз интенсивнее.
Никогда не любил хорроры. От слова совсем. Зато люблю порноигры. Не похоже на что-то общее.
>мода/повестка/тренды/ситуация в мире
Но ужастики всегда нравились детям...
>>1083911
>Ты вагину видел ваще?
Очевидный хэдкраб очевиден же...
Я вижу больше 3д хорроров, чем 2д, но я слежу за зарубежьем. Пс1 стайл лоуполи с кое как сделанными моделями и текстурами это первый законченный проект и многих инди девов. AlphaBetaGamer канал на ютубе, там такого полно.
Ламар!? Ты куда опять сбежала? Прыгай мне на лысину. Вот так, моя девочка.
>Крайне удачно они
В чем удача? Они задонатили больше чем покупка про лицензия.
>Вдвойне если прикрутишь воркшоп.
Моды убьют твою игру. Посмотри как сделал стоншард. Они около 7-9 лет пилят разжиревшую полудемку, меняют цифры стат местами (как в патчах доты) и запиливают буквально одну-две механики или персонажа.
Был бы вагон модов и контента, они не смогли такими малыми силами доить корову почти 10 лет.
Пришлось бы делать реально жырные патчи или DLS (то есть реально работать), чтобы конкурировать с обилием модов. А так люди праще радуются (что по механике копия лука) или новому персонажу (просто арт с другими статами).
Там "стремящийся" к какому-то значению тик, но он никогда не бывает "стабильным", даже в вакууме, поэтому дельта всегда имеет смысл.
А ее так сложно использовать, что хочется забить? Обычно же она нужна как доп коэффициент в формулах всяких и все.
А в годо можно делать стратежки без графики, ну типа как в экселе?
А в экселе же таблица с ячейками - это же графика. Ты же меня обманываешь. Без графики - это в консольке.
В консольке такие чудеса вытворять можно - эксель позавидует.
Хочешь без графики - деды до появления мониторов печатали вывод на листках бумаги.
Так у меня пока игра в консольке. Хочу вот перейти на новый уровень
Да, а ввод на перфокартах. Что-то сразу захотелось запилить игру с эмуляцией всего этого. Ну, перфокарты можно камерой считывать
Невыносимо медленный при движении по таймеру.
Но можно ускорить.
Но отзывчивый при нажатии клавиш.
Без диагонального движения.
Со встроенным детектом самопересечений, стен, еды.
Создающий себе сегменты в реалтайме.
Ща как доделаю игру! Уххх, ща как доделаю!
Я думал спецолимпиада закончилась еще в прошлом треде. А в чем сложности то?
Если игрок нажмет кнопку турбо, вся физика посыпиться
олды сплакнут
Намечается новый холивар - дельта не нужна, дельта для слабых.
Сделайте плавную змейку, хватит долбится в тайлы. лол еще и через таймер
Это какая-то форма мазохизма? Что мешает с нейронкой слепить за пару часов? Ещё и сегменты не инстансишь.
Плавная змейека теряет ретрошарм. А так же смысл - гораздо проще избегать столкновений, если ты можешь маняврировать как угодно, а не только в четыре стороны. Это уже не змейка короче будет, а другая игра какаято. Алсо, хз как на твоем скрине на самом деле сделано, но на вид эти черви тоже сегментирорванные, просто кружочками для гибкости.
> Это какая-то форма мазохизма?
Саморазвитие - это больно. Саморазвитие легко спутать с мазохизмом, потому что и там больно и тут.
> Что мешает с нейронкой слепить за пару часов?
Потому что с нейронкой ты так и останешься неразвитым. Вместо тебя разовьётся нейронка.
> Ещё и сегменты не инстансишь.
Инстансиш.
Ты троллишь так? Троллишь ведь? Нафига ты туда эти Area2D лепишь? Чтоб процессор пользователя греть? Создавать ощущение бурной деятельности игры? Чтоб казалось, будто игра на фоне крипту майнит? Тебе уже скинули базовый код классической змейки, которая по клеточкам ходит, чем ты недоволен-то? Или ты хочешь сделать змейко-платформер, как сейчас модно стало?.. Тогда тебе нужно CharacterBody2D вместо Area2D, лол.
>>1084040
>Плавная змейека теряет ретрошарм
Тогда зачем ты обмазывался Area2D, ретрофил?
>>1084042
>Саморазвитие
Да ты ж наговнокодил просто. В чём саморазвитие?
>>1083997
>Зачем тогда там вообще дельта передается?
Для каких-нибудь строгих симуляций в мультиплеере. Физика может отставать, особенно если компьютер не вытягивает 60 FPS по процессору (не по видеокарте), поэтому установленные в настройках TPS физики не гарантируются. Почитай всплывающие подсказки в настройках проекта, касающиеся настроек физики. Тестируй игру с открытым профайлером или выводи информацию из API Performance на экран в игре...
>>1084014
>А в годо можно делать стратежки без графики
Можно, конечно. Можно использовать Control-ноды. Учитывай, правда, что Control-ноды рендерятся через кастомный OpenGL/Vulkan/DirectX/Metal-рендерер в зависимости от платформы и настроек проекта, а не встроенным в операционку набором виджетов, т.е. взаимодействие с ОС отличается от классического, и некоторые фичи, возможно, ещё не поддерживаются.
Вот тут о том, как юзать Godot для GUI приложений:
https://docs.godotengine.org/en/stable/tutorials/ui/creating_applications.html
Но учитывай, что, хотя 3D фишки можно вырезать из движка, 2D фишки пока что не так легко вырезаются. Поэтому сделать Godot максимально тонким трудно.
>Тогда зачем ты обмазывался Area2D, ретрофил?
Опять бля у шиза все голоса в один слились.
Я другой шиз, не путай нас.
>>1084048
>fix1 fix2 update123
Просто нужно фокусироваться на одной фиче/баге, не растекаясь по всему проекту хаотичными правками, и описывать тогда будет нечего.
А зачем тебе гит? Откатываешься часто?
> с нейронкой слепить
Нее... Нейронка пусть мне арт рисует. А прогать я сам буду.
>>1084043
Ты троллишь. Троллям - игнор.
>А зачем тебе гит? Откатываешься часто?
Я без гита впринципе даже тестовые заметки не веду. Не только профдеформация, но и жизнь в условиях умирающего ссд на протяжении пары лет. Хз как вы игры делаете без гита, лишняя хромосма помогает?
Ну а с нейронками это просто необходимо - это говно легкой рукой сметает к хуям хоть весь код в процессе, если надо. Поправит то, попробует там, и вот хуяк уже ихз рабочей версии полностью нерабочая - гитом откатить можно. Еще она и гит можно смести к хуям, да, как-то раз мне просто сделала гит резет хард на 10 коммитов назад, это правда восстанавливается, но так и поседеть можно, так что гитовать надо не только локально, но и на ремоты обязательно слать.
Ну и дляценителей, конечно же, относится в целом не к гиту именно, а к любым контролям версий, извращайтесь как хотите для тех же целей, хуле нет, хотя ручной бекап это пиздец, лол.
Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
Уж лучше бы тебе нейронка нормальный алгоритм сгенерировала, чем вот это вот говнокодерство. Специально для таких как ты костыли сделали.
>пусть мне арт рисует
Ага, и будет говнокод в красивом фантике.
>>1084057
>перед каждой фичей бекапить 5 гигов
У тебя 5 гигов кода? Или всё-таки арта? Арт не нужно бэкапить, когда с кодом работаешь. А код правится маленькими частями в отдельных папках...
Вообще, тоже подумываю подключить какую-нибудь подходящую VCS, но всё боюсь, что она сломается и поломает мне все файлы. А бэкапы пока ни разу не пригодились по сути, потому что я никогда назад не возвращаюсь из принципа. Если не идти вперёд, а возвращаться назад, то в чём тогда будет прогресс? Сохраняю бэкапы только на случай поломки диска.
>>1084068
>лишняя хромосма помогает?
>с нейронками это просто необходимо
Какая хромосома заставляет тебя юзать нейронки?
>полностью нерабочая - гитом откатить можно
Зачем откатывать то, что можно просто не ломать?
>хотя ручной бекап это пиздец, лол.
Зато никакая нейронка не влезет и не сломает, ибо архиватор древней версии и надёжен как часы. А гит наверняка уже заслопили мартышки из майкрософт.
>А гит наверняка уже заслопили мартышки из майкрософт.
Гит != гитхаб, балбес. Ну и юзай другие, их полно, раз гит вдруг стал майковским.
>Зато никакая нейронка не влезет и не сломает
Да она просто рм сделает под предлогом чистки мусора.
>Какая хромосома заставляет тебя юзать нейронки?
Дежурный луддит, добрый вечер, как на бересте пишется?
>Зачем откатывать то, что можно просто не ломать?
Нейронки не то чтобы именно ломают (разве что удаляют они почему-то слишком уж бездумно, наплевав на то, что могут и не восстановить уже), просто не все их высеры стоят того, чтобы их доводить до конца. После работы нейрослопа всегда надо старательно напильником обрабатывать, иногда проще откатываться, чем вникать в очевидный сгенерированный бред, даже если он рабочий. Для них это все равно быстро. Даже слишком. Собственно из-за скорости нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью.
Ну понятненько. Ты у нас и гит не признаешь, дьвольские технологии. И нейронки тоже. Луддит бинго? Че там дальше - отрицание 4к мониторов?
>для бекапа выковыривать только код тоже лень
В архиваторах можно настроить фильтры. Я просто исключил из архива все .png, .gltf и т.п. тяжести, что практически никогда не меняются, и в итоге бэкапы составляют всего несколько килобайт файлов, что изменились за сегодня (фильтр по времени). И это практически не занимает времени, всего 3-4 клика. Автоматически добавляется штамп времени и т.п. Перекатываться на кривоватый гит как-то лениво...
>>1084072
>раз гит вдруг стал майковским
Ну, не будешь же ты свой сервер арендовать...
>Да она просто рм сделает
Она-то сделает, но запустил её ты. Виновен ты.
>Дежурный луддит
Я не луддит, а как раз фанат ИИ технологий, и именно поэтому знаю, что нейронки на базе GPT используют тупейшие мартышки и скучающие лузеры по жизни, поскольку полагаться на этот чёрный ящик с мутной историей тренировки нельзя, а ТЕМ БОЛЕЕ запускать автономно на железе, которое тебе дорого и имеет собственный доступ в локальную сеть и интернет. Ты буквально добровольно запускаешь троянского коня.
>удаляют они почему-то слишком уж бездумно
Научились у зумеров с гита, у которых всё в облаке.
>нейронка как таску может сделать быстро, так и засрать весь проект с той же скоростью
Любишь играть в русскую рулетку как хобби?
>
> Можно, конечно. Можно использовать Control-ноды.
Спасибо, возможно это то, что нужно
Начинай в любом случае с базовых туториалов:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
Уже потом сядешь пилить свою убийцу игры в Excel.
>Жалко скоро лавочку бесплатных всяких гитхабов прикроют, эх.
Откуда инфа? Есть повод для волнения?
>>1084069
>чем вот это вот говнокодерство
>говнокод в красивом фантике
Ты чё быкуешь, сука, человек реально обучается методом проб и ошибок, щупает синтаксис языка, своими мозгами доходит до рабочих/нерабочих методик, а ты падла подсираешь, ещё и анонов в ридонли дизморалишь. Ты вообще понимаешь как устроен процесс обучения вещам у человека? Стянул бы еблет со своей говнокритикой лучше.
>реально обучается методом проб и ошибок
>как устроен процесс обучения вещам у человека?
Так он это здесь показывает так, как будто это что-то хорошее и нужно повторять. Если он хочет критики - замечательно, но он же сразу огрызается на советы, следовательно, критики он не ожидает. Тогда зачем?
Или ты считаешь, что юзать Area2D для игры, где все элементы - квадраты на квадратной сетке - это типа нормально? Ты считаешь, что ему следует держаться данного подхода и ни в коем случае нельзя делать замечаний, что так делать (в данном случае) вредно?
Ладно бы он хотел сделать что-то современное. Но он пытается скопировать классическую змейку. В ней уж точно никаких Area2D не было и быть не могло.
>Откуда инфа? Есть повод для волнения?
Да повод вполне обычный - у нас есть хуйня импортозамещенная. С крошечными лимитами на бесплатке. И принадлежащая тоже кому надо. И даже заботливо намекающая с главной же страницы "мигрируйте к нам с гитхаба, вот тут нажать".
Правда уже довольно давно, главное почва уже имеется, войну сервисам и с меньшей подготовкой объявляли.
А повод даже выдумывать не надо - на гитхабе куда не плюнь запрещенка.
Ладно, эт я чёт сорвался. Думаю для такой хуйни как змейка из трех с половиной нод, начинающий юзверь вполне может юзать ареа2д. Опять же, гораздо эффективнее и запоминабельнее будет себе стрельнуть в ногу в проекте покрупнее, и уже исходя из этого оптимизировать подход. Ну и его реакция тоже ясна: вместо критики обозвали говнокодом, подкинули невнятных объяснений, и дали ссылку на неоткрываемую без впн документацию.
Ну ладно, хули я тут языком чешу, ситуация-то штатная в любом коммьюнити, в любом обсуждении. Пойду лучше мусолить игру мечты.
У вас здесь какой то непрекращающийся змеиный перфоманс, интересно юнитеки из треда, хоть змейку смогут сделать без ассетов.
Моя первая змейка такая же была. Баженная. На спор сделал. Знал только массивы, циклы, функции, все такое, да классы прям понюхал тока тока, ни архитектур нихуя не знал и не умел, ни опыта.
Смотрю на этого змеееба тредовского и думаю смогу ли я сейчас без нейронок сделать змейку уже в годоте и чтоб охуенная была. лень проверять.
>Будут ли дальнейшие 4.5.х и 4.6.х релизы?
Из официальной документации:
https://docs.godotengine.org/en/stable/about/release_policy.html#release-support-timeline
>Godot 4.5 - September 2025 - (partial) Receives fixes for security and platform support issues only.
>Godot 4.6 - January 2026 - (supported) Receives fixes for bugs and security issues, as well as patches that enable platform support.
То есть 4.5 обновят, только если обнаружится некая уязвимость (например, в сетевых протоколах), либо несовместимость с платформами (типа Android); 4.6 обновляют всеми багфиксами вплоть до релиза 4.7, ожидаемого во втором или третьем квартале 2026.
>я литерали не могу его использовать
У меня кастомный билд (x64 SSE2 only) 4.6 стабилен. Попробуй запустить проект на x86 версии, если тебе достаточно 4 ГБ оперативки для всего проекта - как правило, в 32-битных программах меньше проблем. Собственно, я бы мог не билдить x64, просто хотел поизвращаться с компилятором и всё такое...
>гайд годный на выживач с мультиплеером
Зачем тебе отдельный гайд на выживач?
Для выживача ищи про:
- авторитарный мультиплеер для экшена/шутера;
- механики и контроллеры для обычного шутера;
- инвентарь, крафтинг и т.п. по твоему вкусу.
Потом просто слепишь всё вместе.
Спасибо за ссылку, не видел это в доках. Ахуеть конечно. С одной стороны я понимаю их (совсем чуть-чуть), а с другой, что это если не принуждение обновляться если хочется багфиксов? Еще и никто не отозвался насчет 4.5 и 4.6, неужели сидят все на 3.х ветке?
Все сидят на своих форках со свежайшей мастер ветки и своими изменениями исходников.
У них ежегодные опросы через гуглформы, из которых следует, что большинство сидит на самой актуальной версии движка, ещё немного сидит на последней 3.x, и мизерное количество застревает на промежуточных, наверное, из-за каких-то велосипедных модулей...
Вот, например, за прошлый год (30 июня 2025):
https://godotengine.org/article/godot-community-poll-2025/
>Godot 4.5 (dev/master) - 16.8%
>Godot 4.4 (stable) - 71.2%
>Godot 4.2-4.3 - 8.8%
>Godot 3.5-3.6 - 2.3%
>Godot 4.0-4.1 - 0.9%
Опрос был после 4.4 (март) до 4.5 (сентябрь).
Подозреваю, что сейчас дела обстоят как-то так:
>Godot 4.7 (dev/master) - 15%
>Godot 4.6 (stable) - 70%
>Godot 4.5 - 10%
>Godot 3.5-3.6 - 2%
>всё остальное - 3%
Посмотрим, что будет в опросе этим летом...
>Еще и никто не отозвался насчет 4.5 и 4.6
Сходи на Reddit в r/godot, там часто обсуждают.
Проблема Икс у тебя в чём заключается?
Какую проблему ты пытаешься решить, редактируя дочерние элементы?
Зону спавна из collisionpolygon на главной сцене. В итоге я инстанцирую area2d со скриптом и в дочки ему создаю форму и там же её и правлю.
Так. Тебе нужна зона спавна. Ты хочешь самостоятельно выбирать зону спавна в редакторе. Я правильно понял?
> Зону спавна из collisionpolygon
Там есть нода просто Polygon2D, без привязки к коллиженам. Может тебе просто полигон нужен? Чтобы потом из него получать рандомную точку спавна?
Тебе это неважно. На твою разработку это никак не повлияет.
Типа как-то так.
без разницы, но коллижн как будто универсальнее. Там можно on_body_entered ловить.
Так бы сразу и говорил. То есть, зона спавна должна реагировать на вход тела (игрока) и спавнить предустановленную сцену?
Штош, бесплатные токены в клауде закончились, приходите завтра.
Я в итоге просто так сделал и забил пока. Понял что приоритет выше у других вещей.
И в итоге это самое правильное решение. То что зона вложена как сцена - не отменяет того факта что ей коллизию можно в дети пихануть снаружи, а не лезть в детей через редактирование каждый раз.
Я даже в каком-то старом туториале видал такой трюк, ещё на трёшке.
Зачем ты сохраняешь эту Area2D как сцену, если это одна нода?
Попробуй как-то так (не проверял, пишу в поле ввода поста):
>@tool # будем выполняться в редакторе
>@icon("spawn_zone_icon.svg") # для удобства в редакторе
>class_name SpawnZone # важно дать какое-нибудь имя класса
>extends Area2D
>func _ready() -> void:
>_ if Engine.is_editor_hint(): # проверяем, что мы в редакторе
>_ _ if not get_child_count() or get_child(0) is not CollisionPolygon2D:
>_ _ _ var p := CollisionPolygon2D.new()
>_ _ _ add_child(p)
>_ _ _ p.owner = owner # чтобы нода сохранилась в файле сцены
Далее следует твой код спавнера как обычно.
Важно - как этот скрипт использовать:
1. Открываешь сцену, куда хочешь засунуть новый спавнер.
2. Нажимаешь ctrl+A или кнопку с плюсиком сверху дерева.
3. Набираешь имя класса "Spawn..." пока не найдёшь ноду.
4. Жмёшь Enter.
Твой скрипт сразу добавит себе новый CollisionPolygon2D.
Редактируешь, сохраняешь - в общем, всё как обычно.
И никаких tscn в данной ситуации создавать не нужно.
Алсо, хочу заметить, что это - от непонимания сцен Godot:
>бредятина у годота с редактированием инстанцированных
>надо прожимать "редактировать дочерние элементы"
Механизм сцен Godot предполагает, что внутренние ноды сцены являются "деталями имплементации", то есть сохранение куска дерева как сцены - это что-то вроде инкапсуляции ООП объекта. Поэтому у тебя есть лёгкий доступ к свойствам корневой ноды - интерфейса сцены - и более сложный доступ к её внутренностям. Фича "редактировать дочерние ноды" - это анти-паттерн, который предусмотрен для быстрых костылей-заплаток, прототипов и тому подобного. Так что, если ты замечаешь, что ты вынужден слишком часто прибегать к этой функции, тебе следует пересмотреть то, как ты организуешь свои сцены. Кстати, механизм этот не совсем надёжный и внесённые изменения легко "слетают", если ты как-то поменяешь оригинальную сцену. Это могут поправить в новых версиях движка, но в целом лучше не полагаться на сохранность данных, введённых в режиме "редактирования дочерних нод" инстанса сцены.
Если да, то просто никогда ими не пользуйся.
Не все инструменты в движке нужно использовать просто потому что они там есть. Они могут быть неудачными, а убрать уже нельзя из-за обратной совместимости.
https://www.reddit.com/r/godot/comments/1m3ufb5/is_it_just_me_or_is_godots_scenes_inheritance/
Чтобы скрипт не лепить каждый раз очевидно.
> Попробуй как-то так (не проверял, пишу в поле ввода поста):
Задумку вроде понял, но не работает. Да и избыточно это.
Ну например для импортированных мешей я включаю редактирование дочерних нод чтобы выбрать меш и добавить коллизии, хитбоксы. Обычно при импорте корень сцены это просто node3d.
>не работает
Исправил ошибку - можешь попробовать снова, если хочешь.
>избыточно
Но это ускоряет работу, если нужно создавать много таких нод.
>>1084329
>для импортированных мешей
Если изменишь порядок/имена нод в исходном файле, то после повторного импорта Godot "забудет" всё, что ты нацепил на эти внутренние (жёлтые) ноды: в коде tscn созданные тобой ноды/ресурсы имеют конкретных владельцев, и если эти владельцы меняют имя, то ноды/ресурсы становятся ничейными и игнорируются при чтении сцены/записи сцены в файл. Вроде бы это должны были пофиксить UID для нод внутри сцен, но у GLTF вроде бы ещё нет таких UID, поэтому всё полагается на имена и иерархию (если они это ещё не пофиксили как-то; давно не проверял). Учитывай это, если планируешь несколько раз экспортировать одну и ту же сцену в один и тот же GTLF файл. Т.е. нужно либо не менять имена и иерархию, либо нужно отказаться от подвешивания чего-либо на "жёлтые" ноды в редакторе (а также от механизма "inherited scene" - у него та же проблема, потому что под капотом это одна и та же фича движка).
>добавить коллизии, хитбоксы
Можно настроить автоматическое создание коллизий, добавив специальные суффиксы к именам объектов/пустышек внутри сцены Blender. Подробнее:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/node_type_customization.html#create-collisions-col-convcol-colonly-convcolonly
>>1084317
>просто никогда ими не пользуйся
Они не так уж и плохи в некоторых ситуациях, просто нужно знать нюансы (см. выше).
>убрать уже нельзя из-за обратной совместимости
>>1084432
>Самый момент был для выкидывания, если на то пошло.
"Inherited scene" существует благодаря "editable children" - их можно было получить через какие-то манипуляции с кодом сцены в файле tscn - кнопка создания "inherited scene" просто упрощает такую манипуляцию. Это важная фича системы сцен, отказаться от неё нельзя. Считайте это трюком уровня get_parent().get_parent().get_parent()... - движок позволяет так делать и никто не будет вырезать эту фичу в будущих версиях движка, потому что так работает дерево сцен и ничего с этим не поделать, но это не означает, что вы должны обмазывать все скрипты такими конструкциями. Пока "родитель" нескольких "дочерних" сцен никак не меняется (иерархия и имена узлов), всё должно быть в порядке. Проблема будет только если вы захотите изменить родителя - тогда дочерние сцены могут поломаться, утратив часть данных, закреплённых за изменёнными нодами. Повторюсь - это должны были решить UID у нод в сценах, но я не знаю, решили они это или нет.
ФПС упал сильно, в пике нагрузки уже меньше 200 фпс показывает. А было 500 изначально. В целом не страшно, ведь это значит, что у меня в запасе еще 140 свободных кадров, которые можно потратить.
Круто конечно, но вампырики-сурвалики уже всех заебали. Ты эти волны врагов никому не продашь.
Делай лучше метроидванию. Метроидвании всегда в цене. Хороших метроивданий мало. Сделаешь хорошо - заработаешь нормально.
>Ты эти волны врагов никому не продашь.
Не рекламы ради, я тут последние 3.5 недели дрочу мобильную гиперказуалку "Gear Defenders" - и она умудряется затягивать и по своей воле смотреть 2-3 десятка рекламных видео в день, лол. Геймплей на поверхности прост: ставишь эти "шестерёнки", а они спавнят юнитов, которые идут и бьют мобов... Если копнуть глубже, имея ограниченные ресурсы, место, неудобные препятствия и т.п., собрать успешную композицию не так-то просто. К сожалению, игра на высоких уровнях скатывается в "либо повезло, либо смотри рекламу ради какого-то шанса на победу". Поэтому, рекомендовать эту игру не могу - но с т.з. геймдизайна базовая формула весьма хороша. Мне захотелось сделать похожую игру или реализовать данную формулу геймплея в игре другого жанра.
Но там не так-то много юнитов - где-то до сотни. Интересно, что бой становится месивом, где трудно разобраться, кто кого атаковал и насколько сильно, поэтому становится тяжелее принимать решения на следующей волне. Т.е. огромное число юнитов не является здесь чем-то нужным или крутым, скорее раздражает, мешает анализировать ситуацию. Алсо, большинство юнитов тупят, не могут выбрать более подходящую цель (пример: всадник имеет сильное преимущество против лучников, но если даже он технически мог бы обежать защитников по дуге, он предпочтёт умирать об этих защитников, что бесит, особенно если это в чистом поле с 2 врагами).
Короче говоря, игра с толпой может быть довольно интересной и при этом простой, но нужно правильно организовать и не перегружать игру лишним числом, поскольку слишком большая толпа не нужна и лишь отвлекает или мешает анализу и планированию.
Относится ли пикрил к "survivor-like"? Вроде бы нет. Насколько я понимаю, это вариант tower defense с укороченной дорожкой и мобильными "башнями" (интересно, "башни" - это шестерёнки или юниты?). Конечно, есть ещё куча жанров, где толпа уместна...
>метроидванию
С точки зрения геймдизайна, это в первую очередь платформер, а платформер - это экшен с высокой зависимостью от точной реакции игрока. Так что это ограничивает целевую аудиторию, которая способна поиграть и получить удовольствие. К тому же, жанр метроидваний подразумевает большой уровень с регулярными походами туда-сюда через ловушки, и, следовательно, игровая сессия даже с чекпойнтами должна быть долгой (иначе игрок забудет, куда ему двигаться и зачем), что ещё сильнее ограничивает аудиторию даже в сравнении с платформерами.
А узкой аудитории сложнее угодить:
>Хороших метроидваний мало
Потому что даже в такой узкой ЦА есть свои мелкие категории игроков, которым нравится разное в этом специфичном жанре. Что одному - шедевр 10/10, то другому может совсем не доставлять удовольствия. Ошибиться с гиперказуалкой, очевидно, сложнее.
>Сделаешь хорошо - заработаешь нормально.
А сделает норм - убьёт лет 5 на ассеты, отладку и "полировку", которую оценят 3.5 ценителя и лишь 1.5 из них похлопают по плечу и скажут "малаца", а двое других обосрут с головы до ног по пустякам...
Я не предлагаю бежать делать гиперказуалки, нет. Гиперказуалки лезут по головам друг друга, сжигая бюджеты на рекламу, которого у вас всё равно нет. Впрочем, цена обосрамса невелика - пикрил даже с графикой и геймплеем можно сделать за неделю, наверное, останется только рекламу прикрутить и оформить страничку в маркете. А потом только наполнять контентом, если игра реально взлетит. Банально более разумное вложение, если волнует исключительно прибыль с игр, а не Игра Мечты.
>>1084488
>уже меньше 200 фпс показывает
Это ни о чём не говорит. Сколько юнитов в пике? А вариантов юнитов (уникальных)? И на каком железе тестируешь? По графикам смотришь или просто так следишь за циферками на экране? Цифры могут и сглаживаться по сравнению с реальной нагрузкой.
>у меня в запасе еще 140 свободных кадров
Во-первых, по-хорошему считают миллисекунды - стандартные 60 фпс это 16.6 мс примерно. Это типа "бюджет кадра". С этой метрикой проще работать - к примеру, если что-то требует для вычислений 20 мс, возможно размазать вычисления по 4 кадрам, и в результате у тебя будет только +5 мс нагрузки. А в абстрактной "частоте кадров" так не посчитаешь. Аналогично если можешь использовать потоки - ресурсоёмкий процесс на 20 мс на 1 потоке может сократиться до 5-6 мс на 4 потоках, что, опять же, не посчитаешь в абстрактных "кадрах в секунду".
Во-вторых, ты должен оптимизировать сильнее, не растрачивая все 16 мс на своём железе. Нет, если ориентируешься на консоли - там да, можешь 16 мс потратить и твоя игра 100% будет хорошо работать, поскольку у всех игроков одна и та же консоль (ну, теоретически должна быть одна и та же). Но на ПК столкнёшься с тем, что разное железо даже одной ценовой категории работает по-разному, фоновые процессы по-разному отъедают ресурсы компа, и банально перегрев и троттлинг могут сделать игру неиграбельной на "рекомендованном железе". На мобилках тебя ещё будут ругать за то, что телефон раскаляется и обжигает руки с тупой 2D графикой посильнее, чем с продвинутой 3D графикой, лол.
Короче, если хочешь дрочить на оптимизацию и максимальное число юнитов - дрочи правильно. Ориентируйся на хорошие игры, а не симуляторы троттлинга с кучей лишней мишуры на экране.
>Сколько юнитов в пике? А вариантов юнитов (уникальных)?
10К vs 10К.
Пока три класса разных, воин-маг-лучник.
В целом видюха тут не сильно важна, там микро объемы памяти потребляются, а вот проц важен. У меня i5 не самый свежий.
Понятно, что железо у всех разное, но я все равно потом всё буду под геймплей затачивать, там вряд ли так много юнитов нужно будет. Просто стресс-тест.
просто круто, хоть сам в вампайр не людлю, но старик или дов, где можно анигиллировать толпы врагов и стоять на горе из трупов, любо дорого.
Да это вообще не вампайрик, это скорее фрейворк на основе годота чисто, чтобы можно было делать огромные армии юнитов. Геймплей в этом плане можно потом додумать, важно, что юнитов много и это работает.
В прошлый раз разве не обсуждали что стоит делать что-то типа ShapeCast?
https://godotshaders.com/shader/improved-spom-with-outline-detection-and-self-shadowing/
https://www.youtube.com/watch?v=TUAyiCswYt4
>когда-то что-то такое прототипировал
Ага, нашёл свой код трёхлетней давности и немного причесал.
В общем, я сейчас поигрался и увидел следующие проблемы:
- игрок может взлететь на RigidBody3D словно Мюнхгаузен;
- RigidBody3D может продавить игрока сквозь/внутрь пола;
- трудно подобрать оптимальное расстояние/силу влияния.
Наверное, если повесить стопицот if-else, всё решаемо...
На движок такое вообще никак не влияет. Зря волновался.
>>1084537
>В прошлый раз
Это когда было? В 2023?
>делать что-то типа ShapeCast?
Мне внезапно захотелось "натуральное" поведение...
Но это не главное... Покажу целиком, когда/если сделаю.
Можно выжимку по поводу нового ассет стора? У меня без квн не открывает и я заебался юзать бесплатные прокси которые сдыхают через день
>>1084547
РиджидБади это самая пидаристическая хуета из всех Бади нод, что 2д что 3д. Сфера применения очень узкая походу, я их юзаю только для мелкой шняги типа гиблетов врагов/объектов.
>превью шейдеров
Оооо, перекатываю свой проект на эту версию.
Алсо, сделали раздельную загрузку export template.
>>1084622
>выжимку по поводу нового ассет стора
Пофиг на него, ничего особенно важного не было, платность ассетов не сделает их лучше/надёжнее. Отключил себе вкладку "Asset Library" в редакторе несколько лет назад и вообще туда не заглядываю. Беспокоит только, что будет засилье кабанчиков, и энтузиасты могут испугаться и сбежать из-за них...
>Сфера применения очень узкая походу
RigidBody - это полная симуляция реального тела (с бесконечной твёрдостью), с рядом упрощений ради оптимизации вычислений в реальном времени. Взаимодействие с ними должно быть посредством приложения сил или импульсов, которые движок интегрирует в свои вычисления каждый тик... Если попытаешься менять transform напрямую, то это, очевидно, нарушает формулы симуляции в движке, поэтому нужно управлять через приложение сил.
Если ты уже применял силы вместо трансформа, то, возможно, ты запутался со вторым параметром - он нелогично описан в документации. Чтоб применить правильно, нужно взять глобальную точку и из неё вычитать глобальную позицию самого объекта:
>body.apply_force(Vector3.UP, anchor.global_position - body.global_position)
Здесь мы прикладываем силу в 1 единицу строго в направлении вверх от позиции ноды anchor, которая находится в потомках RigidBody3D body. Тело должно повернуться так, будто оно подвешено за эту точку.
После того, как запомнишь и будешь следовать этим правилам, особых проблем с физикой быть у тебя не должно, особенно на Jolt, который весьма стабилен. GodotPhysics имеет кучу проблем стабильности, в особенности при использовании joint-ов - почему-то трясутся и разрываются/разлетаются в стороны...
Проблемы с коллизиями не зависят от того, что ты используешь: если баг в коллизиях, тогда любой код CharacterBody пострадает не меньше, чем RigidBody.
Можно сделать персонажа целиком на RigidBody, и некоторые игры именно так и делают; там обычно специфический геймплей по правилам физики, а не банальный "шутер от первого лица", но в принципе, заставить RigidBody вести себя как кинематик (CharacterBody) возможно, хоть и сложнее.
Алсо, лайфхак: если хочешь поведение RigidBody у CharacterBody или AnimatableBody, то можно юзать RemoteTransform для точной копии компонентов трансформа или написать свой код, который будет передвигать одно тело к другому. Можно настроить физические слои так, что RigidBody неосязаем, но полностью ощущает все геймплейные препятствия.
В общем, инструмент мощный, но только если ты понимаешь, как им пользоваться, и если движок достаточно стабилен, чтоб объекты не улетали...
А ещё в Godot есть SoftBody, это для тканей всяких. Насколько я понимаю, там всё намного сложнее и проблемнее, но сам я их никогда не трогал (только в блендере с симуляцией тканей возился немного, но там-то она не в реальном времени вычисляется).
Сделал на ригидбоди чуть ли не больше игр, чем на кинематичном. Мяч в футболе, игры типа боулинг/гольф/бильярд, где ты пуляешь шары, пара игр с контроллером аля ракета. Гоночки, как на аркадном варианте где машинка это иллюзия на шаре, так и простые, где vehiclebody - а он наследник rigidbody. Туда же авиасим, правда я подзабил, но там тоже подход через наследование от него и воздействующие СИЛЫ через аэродинамические поверхности (уже кто-то и аддон написал за меня, удобно). 3д платформер тоже ради эксперимента делал, там физика больше на астронавта внутри полой земли была, хотя можно было гравитацию и кинематику считать в скрипте.
Не благодари, готово 4 года назад.
https://github.com/jgillich/godot-snappy/tree/godot-3
У меня обратная ситуация, всю жизнь думал вот бы замутить свой бумер шутер, чтоб всё в тридэ и с модным стильным крэйзи грэфоуни.
Но вот пришла пора вкатываться в хэймдэв, разумеется с простого и понятного ДАЖЕ ДАУНУ годотля... Теперь третий месяц пыхчу над своими двадэшками понимая, что если и решусь пытать 3D, то буду месяцами полировать табуретки, как тот чел со вкусом очка.
>что если и решусь пытать 3D
А ты решись, там не всё так страшно. Но сначала конечно свой 2д проект доделай быстренько
>feature freeze.
Какой-то слегка проходной релиз в сравнении с предыдущими. Но может хоть не развалится ничего и не придется делать кучу 4.7.x версий. Может даже удастся спокойно переехать?
Пройдись по всем девблогам, там суммарно кучу уже напихали. Думаю больше чем в 4.6
Учитывая контекст вебм - скорее звучит как сарказм.
мимо
И 2д и 3д страшно, но страшно по своему. А код страшно по другому. Поэтому нечего бояться, надо просто выбрать в чем будешь прокачиваться, что больше лежит душе и вперед. Главное не лениться
В геймплейном плане роста особо нет, однако стиль и графика стала на пару уровней выше. Плюс впервые поработал над постановкой игры — понравилось. Хотел ещё поучаствовать в ludum dare, но оказывается он уже заканчивается, лол.
https://rouw-x.itch.io/miranda-vhs
>третий месяц пыхчу над своими двадэшками
Для освоения программирования 2D игры лучше, т.к. позволяют фокусироваться на геймплейном фундаменте игры без возни с матрицами, базисами и кватернионами, и векторные операции там проще представить в голове или по-быстрому набросать от руки. Но не бойся 3D математики - там всё через API делается и не так уж сложно запомнить основные правила, даже в документации есть туториалы. В плане разработки потенциально успешной игры 2D не проще 3D.
>решусь пытать 3D, то буду месяцами полировать табуретки
Тот анон просто все советы проигнорировал и дрочит на фотореализм, который объективно дольше делать, чем 3D стилизацию (наподобие современного лоуполи). Может, ему так комфортнее - когда делаешь простые hard surface объекты по заранее известному референсу, стараясь скопировать его, прогресс виден чётко и ясно - ты либо сделал табуретку, либо не сделал, никакой неопределённости нет, потому нет и дискомфорта от мысли "а не фигнёй ли ненужной я занимаюсь".
Если хочешь не тратить много времени на 3D, то забудь про реализм и делай лоуполи с простыми текстурами или вообще без текстур. Чтобы графика выглядела приятно, достаточно подобрать удачную цветовую палитру и следовать во всех своих ассетах одному и тому же набору правил, которые ты сам для себя определил или взял из подходящих тебе референсов. Можешь взять бесплатные наборы ассетов в стиле лоуполи, такие легче всего модифицировать под себя и дополнять чем-то своим.
ИМХО, ниша реалистичных 3D игр была переполнена лишними играми ещё лет 10-15 назад, и сейчас трудно с первого взгляда отличить ААА игру про кусты и камни и какого-то мужика в броне с автоматом от дешёвой ассетфлипной индюшки про те же кусты и камни и какого-то мужика в броне с автоматом. Нафига их вообще продолжают делать? Выйдите на улицу, потрогайте реальные кусты и камни, наденьте реальную броню и возьмите в руки реальный автомат... эээ... кхе-кхе...
Я б не отказался от игры где можно потрогать реалистичную траву. Но даже современные реалистичные движки не потянут то, что можно увидеть глазами просто отойдя в лес на 100 метров.
Прошелся. Да ну как-то не. В 4.6 были крутые IK и фичи для рендеринга, в 4.5 тоже фичи для рендеринга, UID. В 4.7 скорее мелкие QoL фишки, ну разве что прямоугольный свет прикольно и полезно.
А чего бы ты хотел в новой версии? Они вроде недавно жаловались на флуд слоповыми пулл-реквестами, которые трудно разбирать, из-за чего работа усложняется. Многие старые пулл-реквесты наверняка ещё недостаточно протестированы или вообще недоделаны.
Если хочешь больше фич - заходи в пулл-реквесты, тестируй их на своей сборке движка и отчитывайся там о найденных багах или проблемах. Так автору пулл-реквеста будет проще довести его до хорошего состояния и, возможно, его примут в движок раньше.
А я без претензий, в самом деле. Мне Годот очень нравится, люб-дорог, я даже несколько рад, что огромных фич в 4.7 нет. 4.5 и 4.6 не очень стабильные, 4.5 вроде подлатали, а 4.6 разваливается когда проект мигрировать пытаюсь, из-за анимаций. Если бы я чего и хотел, так это выход какой-нибудь ультимативной stable версии без багов и огрехов. Если включить мечтателя, то круто было бы заиметь систему террейна и стриминг как в UE. Знаю, что решения уже есть, но круто было бы иметь что-то унифицированное и работающее из коробки.
> выход какой-нибудь ультимативной stable версии без багов и огрехов
4.3
Я на ней продакшон продуцирую.
Да даже если через н-десятков лет человечество переедет на фулл-виар гейминг, то "тру реализм" не будет популярен у масс, скорее оставят как брейнденсы из киберпанка для ценителей.
Посуди сам, в трипл-квадрипл-эй играх трава, деревья, вода, закаты и рассветы - всё заточено чтоб быть eye-candy, чтоб выделялась слюна и хотелось там жить и фантазировать как этот шейдер мягкой шёлковой травы щекочет щёки под солнышком средь чиста поля.
А в реале что? Ну выйти в лесополосу можно, да, там обоссанная примятая трава, торчки ищут клады, гавной ваняет, клещи так и норовят лишить жизни если не в ту травинку присядешь. Короче экстрим для потенциального "человека будущего".
Мне потому лоу-поли графон даже ближе к "реальности" кажется, ну висят три травинки на кочке - так и в реале они такие же реденькие и неидеальные, а под ними та же говняная текстура земли в серо-буро-зеленых тонах. Всё как в реальной жизни!
У меня сейчас под рукой нет фото, вот пик из интернета чтобы понимать
С 4.3 до 4.5 и 4.6 оч много классного добавили. И кучу багофиксов и оптимизаций. Но 4.3 подозреваю где-то стабильнее, да.
Кто-нибудь помнит?
Я забыл...
Эх, превью только для fragment-шейдера работает, и только для строчек, присваивающих какое-то значение какой-то переменной. Но и то достаточно полезно будет, особенно для 2D эффектов.
Ещё заметил, что они опять дизайн консоли вывода изменили. Теперь кнопки снизу, на строчке фильтра/поиска, и консоль по умолчанию имеет очень мелкий размер, строчки 3 или 4 всего. Не пугайтесь, все функции вроде бы на месте, только положение кнопок непривычное.
Мне они пока не нужны, но я всё равно пощупал AreaLight3D. Вообще не понял смысла этой ноды - свет кажется почти неотличимым от SpotLight3D с шириной около 90 градусов. Какая-то разница заметна только на тенях - у Area тени более размытые по умолчанию и, внезапно, без артефактов. На демонстрационной сцене, видимо, установлены полигоны с высоким emission, а не только лишь AreaLight3D? Я-то думал, AreaLight3D сама создаст светящийся прямоугольник, а она невидимая... Впрочем, это точно как с другими лампочками: SpotLight3D не видно без меша-фонарика... В настройках ноды AreaLight3D позволяет установить текстуру, и она как-то вроде влияет на свет, но мне не удалось увидеть какой-то особой разницы с, например, круглым "фильтром" (использовал GradientTexture2D). Почему?.. Странная нода - вроде нужная, а вроде и нет...
Также заметил, что убрали кнопку быстрой смены рендерера из правого верхнего угла... Думаю, правильно сделали, т.к. всё равно перезапуск редактора требовался, и вряд ли кому-то нужно так часто переключать рендереры, если они не делают игру одновременно под несколько платформ.
Оптимизация отображения массивов в инспекторе - самая лучшая фича этой версии, лол. Наконец-то можно нормально видеть значения в массиве даже с узким инспектором, а не какие-то огрызки, ради просмотра которых инспектор приходилось очень сильно растягивать. И почему раньше не сделали...
Может быть, теперь анон сможет сделать световой меч
Ну потом, когда выйдет стейбл, покажу вам как с areaLight будет выглядеть. Но хз, меня и так пока устраивает, все равно это не подразумевалось как световые мечи
А я успел навайбкодить за полдня
Вот для такого невообразимого скота мы и делаем игры. Точнее вы делаете. А я ебал. Нахуй.
Что там было? Что-то плохое?
В настоящем киберпанке живём: все развлечения запрещены большим братом, но можно попросить электронный сверхразум, но он ничего не умеет...
>>1084572
>прямоугольные омнилайты
>>1084858
>сделать световой меч
Анон ошибся в посте, а вы не поняли?
AreaLight3D светит только в одну сторону. Для меча потребуется минимум 2, а то и 4, если он толстый. И материал с высоким emission по-прежнему нужен, поскольку без него источник света будет невидим. Единственный плюс - это мягкие тени без глюков. Пиксельный шейдер эти тени всё равно скукожит...
>>1084859
>когда выйдет стейбл
Да вроде уже сейчас неплохо работает...
Учитывай, что AreaLight3D - это для forward+, а для остальных хуже будет работать (я не проверял, но в документации ноды много каких-то ограничений). В пиксельном стиле вообще бессмысленно, имхо...
Там 3gp с кнопочной мобилки
А ты не пробовал через архив интернета смотреть?
я б написал еще несколько простых способов, но тут неуместно наверное
купи впску за 300 руб/мес и накати туда amnezia vpn
честно говоря не понял в чем суть такой острой реакции, возможно это просто бот который хуйней бампает треды
> не понял в чем суть такой острой реакции
Потому что ты такое же гыгыкающее быдло, как и аффтар этой дрисни. Ты искренне удивлён "а чё не так та, ёпта, нах?" До тебя даже не доходит, какое это омерзительное скотство.
Маэстро, спасибо что почтили нас своим визитом! Арию споете?
Спасибо, улыбнулся.
>за 300 руб/мес
Чтобы потом круглый день сидеть на этом ютубе и спонтанно кликать на каждую рекомендацию, потом очнуться в 18:00 утра следующего дня с кучей новых вкладок браузера, содержание которых не помнишь, мучаясь от обезвоживания, голода и бессонницы? И десятками гигабайт скачанной с ютуба порнухи...
>не понял в чем суть такой острой реакции
Ты запостил какие-то круги и написал "навайбкодил". Непонятно, что это означает? Ты попросил ChatGPT нарисовать тебе круги? И потом запостил сюда PNG? Странный пост. Хоть бы объяснил, чего ты хочешь. И непонятно ещё, зачем ты запостил это в ответ тому, который свою игру на итч опубликовал. Где смысл?
>>1084927
Завязывай с
>гыгыкающее быдло
>омерзительное скотство
Тред любви же, мы должны быть добрее ко всем.
> Спасибо, улыбнулся.
В треде любви и добра придётся относиться с пониманием к таким, кто улыбается с этого скотобожества.
Он увидел игру где непонятно что делать, какие то круги, палки, и запостил олдовый мем, такие вещи правда надо объяснять?
>>1084938
Вы уже спели арию?
Хватит одной виртуалки с одним дистрибутивом, чтобы собрать под разные дистрибутивы Линукса? Если на Hyper-V подниму Убунту, этого достаточно? А как с МакОС быть, например?
Да ты какой-то махровый илитарий застрявший в позапрошлом десятилетии. Ну либо школотрон-ситх возводящий всё в абсолют.
Зачем тебе под все платформы сразу?
Под веб и Android точно получится, под iOS - нет.
Под Linux можно через WSL. Дистрибутив не важен.
Про Mac без понятия, но это очень редкая система...
А для чего собираешь? Какой-то особый модуль?
>>1084950
И насколько это удлиняет загрузку игры?
А что ты делаешь при повторном запуске?
>>1084938
>кто улыбается с этого скотобожества
Ностальгия по временам ИК-портов в телефонах...
> Зачем тебе под все платформы сразу?
Так ведь лучше сбилдить под все возможные, разве нет? Так удобнее потенциальному игроку.
> А для чего собираешь? Какой-то особый модуль?
Вырезал ненужный мне функционал, оптимизировав размер, и прикрутил пару экстеншенов для удобства, да. Ничего особо сложного, но нужный шаг.
Попробуй github actions, они же собирают все билды, сам годот же там собирается вроде под все ОС. Если правильно понимаю, если ты сделаешь публичный форк - то бесплатно, а если приватная репа - сколько то раз в месяц, но часто тебе и не нужно.
Ну то есть вернулись к технике 3-й версии пятилетней давности с вращающимся под землей кубом.
https://github.com/Brandt-J/ShaderPrecompiler
https://godotengine.org/asset-library/asset/977
Жесть какая. Для двадэ тоже таким надо обмазываться? Вот я запилил шейдер дисторшена на сцену Explosion, собсно при каждом взрыве эта сцена инстанциируется. В целом вроде норм, но емнип сталкивался с микрофризом при первом взрыве после запуска игры. Это я трясунчик и мне показалось, или реал придётся вкатываться в этот костылинг?
Конечно. 2D, 3D шейдеры - это одно и то же где-то под капотом, отличия лишь во внешнем API, упрощающем некоторые операции. Не парься, шейдеры хранятся на компьютере игрока, и после первого запуска таких микрофризов не будет, если игрок не очистит кэш.
>>1084964
Я б предпочёл видеть, как игровой мир постепенно погружается вокруг игрового персонажа, чем ждать мучительно долгой загрузки, теряя интерес к игре...
>>1084957
>лучше сбилдить под все возможные
Wine есть и на линуксе, и на маке. А для мобилок и браузеров требуется мудрить с графикой и UI/UX, в противном случае неудобно/невозможно играть. Нативные билды - это хорошо, но не прям такая уж необходимость для каждой инди-поделки v.0.0.1.
>ненужный мне функционал
Сегодня ненужный, а завтра опять билдить...
>оптимизировав размер
Для десктопа это давно уже не имеет значения.
>прикрутил пару экстеншенов для удобства
Если они работают только в редакторе, и не имеют отношения к самой игре, то тебе нужен editor build, а шаблоны экспорта можешь юзать официальные. Кастомные шаблоны экспорта нужны только если используешь модули, меняющие работу движка в процессе геймплея или загрузки ресурсов.
Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты. А мне как раз темплейты нужно скомпилить, там такое не удастся сделать.
>>1084976
> Wine есть и на линуксе, и на маке
Тоже правда. Вообще я почитал, оказывается, не редкость ситуация, когда через Wine работает лучше, чем нативно. С чем связано - не знаю, но много такого встретил пока изучал. Пожалуй, действительно пока обойдусь одним билдом. Так и поддерживать легче, а на мобилки я лезть не планирую, там в одну сторону дорога...
> Можешь скриптом пройтись по списку сцен и динамически их подтянуть в кешинг рум.
Шейдеры - это ресурсы. Если хранить их отдельно файлами ты можешь пройтись чисто по шейдерам, не трогая сцены, а потом сцена, когда будет загружаться, она увидит, что её шейдеры уже загружены и возьмёт их. Потому что ресурсы - синглтон.
>Тоже подумал про гитхаб, но там уже должен быть шаблон, на который можно ссылаться для билда. Т.е. там сам эдитор и бинарники игры компилятся, а не темплейты
Хз с чего ты это вхял. Там билдится все.
И правда. Видимо я не тот воркфлоу смотрел. Не дашь ссылку?
Спасибо. Действительно, я каким-то образом в другом источнике смотрел. Изучу вопрос с github actions.
Я когда разбирался, работало вроде так. Делал форк репы, вносил свои изменения. Когда в репу прилетает новый коммит, вызывается ребилд всего. Я у себя отключал ненужные платформы соответственно.
Можно переделать на какой то другой способ, чтобы запускать вручную, но мне было лень.
https://www.youtube.com/watch?v=HciqfEeUFSw
Если тебе интересно, на пикрилах результаты опроса пользователей Godot за 2020 и 2025 годы. Как видно, большинство работает на/таргетит Windows; Linux по популярности второй за счёт большей доступности; экспортируют на Mac больше, чем работают на нём (наверняка с помощью стандартных шаблонов).
>>1084992
>Потому что ресурсы - синглтон.
Это неправда, потому что их можно дублировать, и доступность ограничена локальностью. Тот факт, что загрузчик данных не делает повторных чтений, не превращает класс ресурса в "синглтон". По смыслу к синглтонам ближе всего static var/func, но это другое.
>увидит, что её шейдеры уже загружены
Для этого нужно где-то сохранить ссылку на ресурс. Отдельная от компиляции шейдеров тема, но тоже полезная, особенно касательно системы частиц - она микрофризи(т/ла) при каждом чтении с диска, т.е. рациональнее держать ссылку и не отпускать.
Если кому-то интересно, я недавно осознал, что нет необходимости выводить материалы и частицы в основном Viewport сцены и затем перекрывать его непрозрачной заслонкой. Можно использовать SubViewport, главное настроить его как-то так:
>size = Vector2i.ONE
- чтобы не было бесполезной нагрузки;
>render_target_update_mode = UPDATE_ALWAYS
- чтобы рендерилось без отображения;
>own_world_3d = true
- чтобы скрыть объекты от основного.
Дальше добавляем ноды:
>SubViewport
>_ Camera3D
>_ то, что рендерим
Созданную текстуру просто игнорируем.
Я не проверял пока, но такой подход должен быть эффективнее, чем основной вьюпорт. Если он вдруг откажется работать, попробуйте увеличить size до небольшого размера в степени двойки (x16, x32).
>>1085021
Пиши сразу описание видео и своё мнение.
А то твои ссылки на ютуб выглядят как спам...
Там, карочи, играешь за менеджера, в качестве оружия у тебя шина сигналов, на спине у тебя сидит синглтон и играет в змейку!
Тебе надо было на лудум даре с таким зайти побеждать, там как раз тема сингалы была
Там слишком крутые чуваки, я стремаюсь даже начинать там участвовать.
Ага, там была команда мидлов 10 человек.
Результат? "Мы не успели, игра совсем не готова".
>Ребят, а где можно посмотреть нормальную архитектуру игр на годот?
https://www.youtube.com/watch?v=xPLbrgEQLqA
Красивое показывают
1. Есть ли какие-либо автоматизированные инструменты для этого?
2. Какие подводные камни могут ожидать и как их обойти?
>1. Есть ли какие-либо автоматизированные инструменты для этого?
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/retargeting_3d_skeletons.html
Для Blender ищи аддон по "animation retargeting".
>2. Какие подводные камни могут ожидать и как их обойти?
Насколько я понимаю (не разобрался до конца):
1. Скелет должен иметь ту же структуру костей. Т.е. автоматически подстраивается только трансформ.
2. Анимации могут не подходить по смыслу/стилю - например, в оригинале чибик (как у тебя на скрине), а пытаешься натянуть на нормального => будет фигня.
3. Если твой персонаж имеет дополнительные фичи, придётся возиться с комбинированием анимаций в AnimationTree... Я так делал только из одного файла, понятия не имею, можно ли из разных источников.
Из моего опыта: сделать новую анимацию на готовом персонаже с правильным скелетом - несложно, нужно только учитывать принципы анимации и знать, что ты пытаешься изобразить (найти референсы, если надо). Заригать персонажа - вот это геморрой ещё тот, т.к. замечаешься править косяки через weight painting.
Т.е. не бойся анимировать своими руками, если не получится взять готовое, а риггинг уже сделан. Для упрощённого чибика риггинг вроде бы несложный.
> 1. Есть ли какие-либо автоматизированные инструменты для этого?
Тебе не нужен никакой инструмент. Если ты используешь тот же скелет, то анимации будут работать. Анимации привязываются непосредственно к скелету, к костям, а не к мешам (3D модели). Тебе нужно будет привязать саму модель к скелету, настроить коэффициенты весов. Изучай такие понятия как skinning, weight painting. Процесс переноса анимаций с одного скелета на другой называется ретаргентингом (retargeting), но это не тот случай.
> 2. Какие подводные камни могут ожидать и как их обойти?
В целом никаких, разве что ты ограничен существующим скелетом и особо отличную по пропорциям модель ты не сделаешь. Это будет скорее рескин/надстройка над существующим персонажем, чем что-то концептуально новое. Также это легко обнаруживается, так что лучше посмотри на лицензию в gdquest паке, чтобы не попасть в просак по авторским правам.
>2
Кста! Road to Vostok обсуждали уже? Как он на годоте себя чувствует? А то я без видимокарты сейчас, не проверить. Помню, когда он еще был на юнити, он был ужасен, но это была совсем ранняя версия.
Что-то обсуждали в прошлом треде: >>1083265 →
Критику можешь почитать в движкосрач-треде...
Собсна обсуждать-то тут нечего. Вышел и вышел.
>кто подгаживает
Эм, кто? Я не слежу за трендами...
Они там против игры или против движка?
Кто-кто, шизик из движкосрач-треда, создал 460 акков в стиме, пишет что годот хуёво работает с 300 пустыми скриптами на сишарпе.
Я не делал замеров на эту тему, но факт в том, что объявление пустого _process(delta: float) в скриптах на GDScript может снижать производительность, если использовать этот скрипт на множестве нод.
Учитывая то, что C# компилируется в отдельную динамическую библиотеку, вполне возможно, что обращения к _process и аналогичным функциям даже дороже, чем обращения к пустым _process GDScript.
Я не знаю, какой там шаблон скрипта на C#, но для GDScript Godot по умолчанию предлагает скрипт с объявленными _ready и _process, что, в большинстве случаев, вообще не нужны конкретному скрипту.
Итого, если тот движкосрачер взял "пустой" шаблон и размножил его много раз, а потом через профайлер замерял затраты на обращения - да, возможно, он в действительности наткнулся на этот "недостаток".
Но реальность такова, что тебе не нужно 300 _process, особенно на стороне C#. Обычно твой код реактивен - отвечает на события и бездействует между ответами, поэтому _process не нужен. А C# как числодробилка...
> большинстве случаев, вообще не нужны конкретному скрипту.
Если скрипту не нужен process, зачем вообще такой ноде скрипт? Переменные хранить? Разве не логичнее тогда использовать ресурс? Или вообще завести в родительском скрипте массивчик под данные.
Ты совсем новичок что ли?
На вот, почитай про базовую архитектуру:
https://ru.wikipedia.org/wiki/Событийно-ориентированная_архитектура
Конкретно в Godot это делается сигналами:
https://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
Большая часть реальной игровой логики - это что-то наподобие "нажали кнопку - загорелась лампочка". Лампочка должна отреагировать на нажатие кнопки единоразово, то есть у неё есть какой обработчик:
>extends SpotLight3D
>func _on_button_toggled(toggled_on: bool) -> void:
>_ visible = toggled_on
Всё, это весь скрипт лампочки. Ей не нужно ничего обрабатывать каждый кадр, и даже хранить ничего не нужно сверх того, что есть в классе SpotLight3D. Остальное настраивается через редактор движка.
Бывает код, который выполняется каждый кадр - это движение аватара игрока и NPC, пуль и т.п. Но таких объектов как правило мало (обычно меньше сотни), и если необходимо больше, то используются разные специальные оптимизации. Короче, это не то, о чём большинству придётся беспокоиться когда-либо.
И главное, что GDScript для такого кода более, чем достаточно, а C#/C++ используется там, где нужно перемолоть миллионы чисел в одном цикле, и потом вернуть результат вычислений в главный поток игры. Поэтому претензии к медленности API нерелеванты.
у меня 2д игра, top-down вид, на процедурных уровнях должно бегать по 10-20 вражин. NavigationRegion2D запекается динамически вся хуйня это уже есть, и navigationagent2d у врагов уже настроен (и переёбан всячески как только я его не менял на результат не влияет).
Короче. Болванчики тупят у острых углов (игра построена на тайлах, соотв. стены и углы тоже квадратные), втыкаются в них, не могут нормально функционировать если входят в агро но им мешает к примеру стена - будут толпиться в стену не додумываясь её обойти. как эту хуйню вообще можно починить?
и ещё вопрос - есть ли смысл для пиксельного 2д рпж рогалика пересаживаться с 4.3 версии на актуальную? (4.7 или какая там), а то ваще не слежу че там и как
Делаем змейку с физоном.
Так и я о том же. Если в игре будет 100 лампочек, то не надо клонировать 100 нод с 100 скриптами с пустым process, а надо просто завести один менеджер лампочек, в нем, в единственном экземпляре, будет единственный скрипт обработчик событий, который будет последним аргументом получать, какая именно лампочка послала событие...
В 3-ке имя кнопки можно было передавать последним аргументом
connect("pressed", self, "_on_button_pressed", [node.name])
В 4-ке
connect("pressed", _on_button_pressed.bind(button.name)
Если планируются домики, советую потестить тени в плотной застройке. Давно делал такое в 3-ке, но там было неприятное дрожание теней, еще по разному выходили тени отброшенные на вертикальную и горизонтальную поверхность (например, стену и дорогу). Читал про продвинутые техники (интерполировать тени между двумя кадрами с разным углом солнца), но забил.
> для GDScript Godot по умолчанию предлагает скрипт с объявленными _ready и _process
Просто выбираешь пустой шаблон при создании скрипта, готово
Как нуб могу посоветовать налепить на врагов RayCast2D и проверять коллизию в _process каждые кадров 5 (чтоб проц не взорвался) через is_colliding или is_on_wall, вот что-то из этого.
а разводы от дождя ты как сделал? Типа на определенной высоте спавнишь декали и удаляешь?
Да вроде бы норм работают тени из коробки.
>>1085575
Дождь я делал по этому видосу:
https://www.youtube.com/watch?v=cZ5Ang_Ji8E
Если вкратце, то следы от дождя это отдельные партиклсы, которые настроены как сабэмиттер дождя и спавнятся, когда дождь коллизится с поверхностью.
>Так я и думал, что ответ будет - "нинужно"
Ну так реально нинужно, в юнити есть аналогичная проблема с количеством скриптов, просто апи лучше прописано и пропуки начинаются не на 300 нодах, а на 3000, сути проблемы это не меняет - вызов с# метода дорогой и с этим нихуя не сделать. Для большинства случаев это терпимо
Во-первых, при каких таких обстоятельствах вообще может понадобиться сохранить не пользовательский файл в рантайме, неужели нельзя все те же данные положить просто в переменную?
Во-вторых, не забывай про многопользовательские системы. Если ребёнок играет у меня на компе, он это делает в своём профиле и не засирает мне стим своими фнафами. Софту не позволяется срать временными файлами, значимыми лишь для одного юзера, в общесистемные папки.
В-третьих, если сохраняешь временный файл, будь добр подчисть за собой в любом случае, не полагайся на системные механизмы.
Какой-то финн делает игру с явно русским названием и каким-то постсоветским сеттингом. Приходят фанаты сталкера и таркова, начинают вонять. Я не утверждаю стопроцентно, что всё так, просто предполагаю.
>>1085485
>Если скрипту не нужен process, зачем вообще такой ноде скрипт?
Вообще, есть много других встроенных коллбэков. Срабатывать кажды кадр нужно только всяким подвижным хуйням типа персонажей. Всем остальным надо в основном отзываться на сигналы: получать дамаг, откликаться на пересечение ареи - всякое такое.
>>1085571
>ответ будет - "нинужно"
Ответ на что? Промотай ветку, там вопрос был вообще о другом.
В доках есть OS::get_temp_dir() и FileAccess::create_temp(), не?
Ты проверял бенчмарком что в годоте на 300 объектах будет какое то заметное замедление, или это просто вброс в движкосрач треде?
Это проверяли пользователи движка. Все подтверждено нотариально заверенными issues.
Окей, я уже уходил, но специально вернулся домой.
Первый пик - фепесы с работающим вхолостую process
Второй пик - фепесы с удаленным process
Разница около 5%
Такая же проверка с 3000 объектами
Разница около 20% (2200 фпс против 1800 фпс)
Итого, игры с 3000 объектами можно делать без какой то особой оптимизации, вообще не заметите проблем. Насмехайтесь над теми, кто пишет про 300 объектов.
30000, так и быть, уже начинайте оптимизировать. Там 300 фпс против 150 с наивным подходом, с логикой можно улететь, ужас, до 60 фпс.
ты не то проверял https://github.com/godotengine/godot/issues/115960
Я не пользуюсь C# и другим не рекомендую. Если тебе надо проверять C# - проверяй сам.
мне не надо. просто ты потратил время на проверку, которая ничего не доказывает
Я проверил, что у годота нет проблем с 3000 объектов.
Собственно, по твоей ссылке у чувака 10000 объектов дает 200+ фпс, чего достаточно для игры.
Раньше не имел опыта перевода игр на годоте.
Имеются вот такие файлы с пиков, так понимаю сам годот их пакует?
Што там за NSFW игра такая?
По теме - https://github.com/GDRETools/gdsdecomp
Благодарю, потыкаю.
Обычная хентай игра, ничего такого. Можно в настройках выключить хентай элементы и играть как в обычный файтинг.
> Лампочка должна отреагировать на нажатие кнопки единоразово, то есть у неё есть какой обработчик:
Я вам даже больше скажу, такие штуки как visible вынесены сеттерами в АПИ ноды, и вышеописанный код можно вовсе не создавать, а настроить через инспектор коннекты к сигналам.
Но, разумеется, так можно настроить только очень примитивные штуки, типа переключения видимости.
Вот так этот коннект запишется в tscn файл:
> [connection signal="toggled" from="Button" to="Icon" method="set_visible"]
Делай меши толще, с пересечениями между собой. Поправь shadow bias. Включи contact shadows
Ты поставил смысловую ловушку. Теперь, если я повторю, ты уличишь меня в том, что у меня обозначенная на пикче проблема. Правда, ты не учел, что одного признака недостаточно для постановки диагноза. А еще ты не специалист, чтобы делать такие выводы, они сложны. Можно легко запутаться, и ты уже запутался.
Так что сказать-то хотел? Чего триггеришься, столько наподчеркивал, старался, время тратил. Ты охотишься на шизов в этом треде, у тебя тут поляна?
Свиндот.
Будут. На каждую. Больше нет нужды задавать этот вопрос.
Кто-нибудь тут может объяснить, почему эта игра так... стрёмно выглядит? Не в обиду автору(ше), игра вроде хорошая, но визуально выбивается из современных в нехорошем смысле. Будто бы чего-то не хватает, но не понятно, чего. Это из-за чисто чёрных теней? Или там источники света какие-то не такие? Они вообще есть? Можете пощупать демку, но я чисто по скриншотам и трейлеру сужу... Видел на реддит несколько раз за последний год или два. Имхо, у этого разработчика проблема с цветовосприятием. Жалко его/её...
https://steamdb.info/app/3689220/screenshots/
Да, вроде в старых тредах обсуждали, не помню уже.
Грязные цвета - основная причина, я считаю. Автор вообще не заморачивался. Если ты знаешь что ты не можешь в теорию цветов и в палитры, возьми готовые палитры и не заставляй людей страдать.
Ну и сверху можно было бы накинуть пару эффектов через World Env хотя бы.
Норм цвета, стилизация под Симс 2.
Анимации правда слишком деревянные, и музыка тошнотная, но графоний в статике в целом норм.
inb4: "у тебя проблемы с цветовосприятием"
Хз, наоборот заебала эта пастельная хуетень как из хипстерских фильтров инстаграмма 2012. Прусь от стандартной ms-paint палитры с твёрдыми как мой кал цветами.
>Автор вообще не заморачивался.
Нет, в том-то и дело, что он заморочился:
https://reddit.com/r/godot/comments/1kuf8jj/
>Грязные цвета - основная причина
...стоп, может там Tonemap неправильный?.. Вот точно помню, что некоторые варианты делают всю картинку серовато-грязной на нормальном (SDR) мониторе. На продвинутом (HDR) мониторе, может, эффект другой, однако, таких мониторов вроде бы всё ещё мало.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#tonemap
>>1085763 >>1085765
>стилизация
Для широкой ЦА нужна более сочная графика, в особенности с учетом сеттинга "светлое будущее". Пастельность или нет - это тут не касается никак.
...Да даже, вон, в DRG - мрачные пещеры - всё ярко и насыщенно, хотя игроку нужно буквально рыться в инопланетной грязи и говне. Так что стилизация не соответствует ни широкой ЦА, ни сеттингу игры.
В общем, жаль автора. Даже хотелось ему помочь... Наверное, можно попробовать распаковать демку и поковыряться в настройках Environment? Если там стандартный проект на GDScript, должно собраться.
>он заморочился
>Сделал динамическую смену времени суток
Ты молодец, для прототипа замечательно, но у тебя основной-то геймплей игры есть? А то так можешь закопаться в тонкие настройки, добиваясь идеальной погоды, а к основной работе над игрой так и не дойти.
На будущее, во время дождливой погоды (особенно штормовой) рекомендую изменять дальность fog в настройках Environment, чтобы ландшафт и объекты вдалеке от камеры были более серыми. Тогда будет реалистичнее выглядеть без лишних частиц.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
>>1085648
>Единственная проблема со светом и тенями
Документацию читал? Там всё с примерами:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#shadow-mapping
Но тебе пока рано фиксить такие косяки. Сначала разработай геймплей, потом определись со стилем графики, сделай несколько моделей в этом стиле. И только тогда будешь разбираться с тенями. Сделать нормально возможно, но всё зависит от моделей и расстановки, зависящих от желаемого геймплея.
>на процедурных уровнях
>NavigationRegion2D запекается динамически
А ты уверен, что правильно настраиваешь его? В документации сказано, что недостаточно просто накладывать ноды для объединения в одну.
>Болванчики тупят у острых углов (игра построена на тайлах, соотв. стены и углы тоже квадратные)
Если вся игра тайлах и имеет много узких ходов, я бы на твоём месте использовал простой AStar:
https://docs.godotengine.org/en/stable/classes/class_astargrid2d.html
Двигая врагов по клеточкам вручную (без физики).
Для больших пустых площадей и, в целом, очень больших карт желательны чанковые оптимизации.
Если игра - экшн-шутер, то можно использовать комбинированное решение AStar + raycast. Т.е. когда противник видит игрока, он просто идёт по прямой, в противном случае ищет путь через лабиринт.
>>1085498
>есть ли смысл для пиксельного 2д рпж рогалика пересаживаться с 4.3 версии на актуальную?
Имеет, там много разных фиксов и оптимизаций, касающихся любых игр. Версии 4.3 и 4.4 уже не поддерживаются, т.е. не получают багфиксов. По рекомендациям разрабов Godot, до выхода 5 всем желательно обновляться до актуальной версии. Копипастишь папку проекта, открываешь копию в следующей версии, и в 99% случаев проблем нет. Рекомендую удалить шейдеры из папки .godot, они зачастую заново компилируются новой версией.
Нет, он делает правильно, что делает прототип - вертикальный срез и сразу увидит какие технические ограничения может упереться. Причем даже если он не будет делать эту игру, такие знания помогут для более мелких игр.
>>1085648
Light leak / bleeding довольно распространенный вопрос про Godot, и четкого ответа с решением проблемы я никогда не видел. Некоторые советуют
-использовать системы SDFGI/VoxelGI/пробы, но мы знаем что они тяжелые по производительности;
-включать тени на источниках света, (у него уже включено на Directional; но надо помнить, что если будут дополнительные фонари, надо проверять, их range например);
-тюнить bias и прочие параметры. Ну тут надо просто перебрать много комбинаций. И может оказаться, что поправив в одной ситуации, портится в другой. Я даже думал понатыкать разных зон, по аналогии с гравитацией, которые будут переключать параметры теней при перемещении по открытому миру.
-отключать источник солнца внутри комнаты - плохой вариант, когда видишь через дверь/окно;
-запекать свет - вариант только для камерных игр, а не открытого мира; возможно с каким то сложным техническим решением, смешивать запеченный свет с динамическим... не видел готового аддона; тут не просто, если домик можно ставить под разными углами или есть упомянутая смена дня и ночи ну и в принципе запекание света меня никогда не устроило, хоть его и переписали три раза.
-Как уже упомянули в треде, делать стены толстыми, в метр толщиной, а не плоскостью из бумаги; тут есть понятная проблема, известная для опенворлда, что домик внутри должен быть такого же размера как и снаружи - в старых играх то просто подгружались огромные хоромы, которые больше чем занимаемое место на карте.
--один из приемов, который вспоминается - можно сделать объект БОЛЬШЕ, чем нужно, и сделать его невидимым, но shadow caster-ом.
-Может быть, можно придумать что-то с визуальными слоями. Я пока не придумал. У источника света есть Cull Mask, который указывает, на какой визуальный слой VisualInstance3D он светит, и соответственно бросает тень.
-Можно поиграться с размером алтасов тени. Но, конечно, большой атлас требует в разы больше памяти видяхи. Тут я так и не понял, как это проверить, является ли атлас screen space или нет, иными словами, важен ли размер 3д мира. Если важен, то может помочь чанкинг, ну то есть отключение дальних участков, которые не видны или тень на которых не имеет значения.
Перечитывая форумы, я вспомнил еще про такой эффект как texture uv bleeding
На пальцах сложно объяснить, ну в общем видяха же окруляет там все, и может при рисовании залезть в соседние пиксели текстуры, то есть желательно растаскивать грани по "островкам" с пустотами для безопасности между ними.
Еще один чел написал:
the thing I found that worked honestly was turning the world environment pure black and getting rid of the light from my skybox.
А ещё можно разрезы развёртки уложить максимально в дальние углы модельки.
>делает прототип - вертикальный срез
Это не то. "Vertical slice" - это когда ты делаешь часть игры на самом высшем качестве исполнения, но в небольшом количестве. Например: в твоей игре должно быть 100 видов противников? Сделай 2 в самом лучшем качестве, например, мечника и лучника, а остальных 98 отложи на потом. В игре должна быть карта размером 15x15 километров? Сделай участок 150x150 метров в лучшем качестве, а остальное отложи на потом. Планируется 20 видов погоды? Сделай 1 вид погоды в лучшем качестве, а остальные отложи на потом. Объедини всё это в играбельную демку, которую сможешь показать людям, чтобы они получили представление о том, какой будет игра в будущем (даже если пока что 99% контента игры не существует).
>четкого ответа с решением проблемы я никогда не видел
У него там буквально тоненькая коробка, совершенно пустая внутри, и он умудрился разглядеть тоненькую полоску света в абсолютной тьме. Если сделать нормальную модель дома, обставить предметами внутри, добавить источники света - эта мелкая полоска будет совсем незаметной, если не искать её специально. А вот ЕСЛИ она будет бросаться в глаза - тогда можно будет просто заделать щель, например, с помощью невидимого shadow mesh, который появляется снаружи дома, когда игрок заходит внутрь дома. Но это нужно делать с финальной графикой и в конкретных случаях индивидуально, а не когда у тебя только примитивный кубик с текстурой досок и кромешная тьма внутри.
https://www.reddit.com/r/godot/comments/1suniye/godotcon_out_of_context/
Там кстати первая бета 4.7 вышла. Подготовил вам пост с чейджлогом, а с компа его не запостить - бан, который мне лень вилкой вычищать. Сами квны включайте и смотрите. Вахтеры с айкью хлебушка.
ОЧЕВИДНАЯ_ПРОВОКАЦИЯ.JPEG
@
ЗАКИНУЛ В ТРЕД БЕЗ КОММЕНТАРИЕВ
@
ХЕ-ХЕ-ХЕ, ИНТЕРЕСНО, КАК ОТРЕАГИРУЮТ?
@
@
@
ОООЙ, А З-ЗА ЧТО Б-БАН-ТО? НЕВИНОВАТАЯЯ!!!
>пост с чейджлогом
Пальцы не устали нажимать Ctrl+C/Ctrl+V?
Ничего интересного, всё было в dev-сборках:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/
>Breaking changes
Сделали как и должно быть => breaking change.
>Animation
- Tween может ожидать (await) сигналы:
>tween.tween_await($"../Area2D".body_entered)
- Можно скукожить группы в AnimationPlayer.
- Всякие оптимизации анимаций...
>Core and buildsystem
Улучшения-ускорения... Нас это не касается.
>Editor
- Снаппинг Path3D и вершин, уже писали.
- Копипаст категорий данных в инспекторе.
- Всякие улучшения UI сами потом заметите.
- Можно качать export template по частям!!!
>GDExtension
Нас здесь это точно не касается... Чёт улучшили.
>GDScript
Теперь enum в remote scene будут читабельными.
>GUI
- Трансформы у Control независимы от контейнера.
- Строчка поиска в PopupMenu сверху (для всех).
- Улучшили интуитивность тяни-и-бросай в Tree.
- Картинки RichTextLabel масштабируются текстом.
>Input
Реализовали виртуальный (экранный) джойстик.
>Physics
Починили однонаправленные коллизии в 2D.
>Platforms - Android
- Поддержка picture-in-picture (полезно idle играм).
- Портретный режим в редакторе скриптов.
- Кастомный сплешскрин и всякое такое.
>Platforms - Windows
Чёто там нахимичили в C++, чтоб сделать HDR.
>Rendering and shaders
- Поддержка HDR дисплеев (это для богатых).
- Начали делать рейтрейсинг через Вулкан:
https://github.com/Fahien/godot-raytracing-gdscript-demo
- Более лёгкий способ рисовать на текстуре:
https://github.com/BastiaanOlij/drawable-textures-demo
- Олдскульное масштабирование для вьюпорта.
- Новые прямоугольные (Area) источники света.
- Превью в текстовом редакторе шейдеров.
>Known issues
Для местных может быть важно: Godot способен подвешивать весь ПК намертво на старых GPU с новейшими драйверами NVIDIA. У меня на старой версии драйвера всё норм => виновата NVIDIA. Но наблюдается этот глюк с какой-то dev-сборки 4.6. Рекомендую не обновлять драйверы без крайней необходимости, особенно те, что для GPU нужны. Большинство обновлений только что-то ломает.
У кого официальный сайт недоступен, сборки тут:
https://github.com/godotengine/godot-builds/releases
Пишите своему провайдеру, чтоб вайтлистнул:
https://godotengine.org/
https://docs.godotengine.org/
Они 100% могут это сделать, просто ленятся.
Ты буквально пишешь "все перечисленное в одну демку", то есть ты правильно понимаешь смысл вертикального среза, но при этом в упор не видишь, что он именно это и сделал - добавил один домик в открытый мир, и сразу сталкивается с проблемой, что или надо ее решать, или не добавлять домики/пещеры из-за того, что сложно настроить exterior/interior освещение. В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
Вытащил как мог, поставлю на сплешскрин своей игры
>то есть ты правильно понимаешь смысл вертикального среза
А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п. Чтобы они посмотрели на твой домик и сказали:
>вах какой разработчег, какой домек зделал, нужно дать ему миллион долларов, чтобы он нам запилил ещё несколько сотен таких же домеков, тогда мы с этой игры поимеем сотню миллионов долларов или больше
Что можно сказать, посмотрев на его видео? Что он натянул текстуру досок на CSGBox3D и воткнул на случайный террейн из бесплатных плагинов (скорее всего). То, что систему погоды сделал - молодец, но в ней ничего сверхсложного нет, и на игру в конечном итоге она мало как повлияет. Так что это не вертикальный срез его игры, а сырой прототип на куче плейсхолдеров, слепленных на скорую руку. А ты раздуваешь из этого драму, будто теперь он не может сделать игру мечты, ведь у него в абсолютно тёмной коробке видно тонкую полоску света. С такими коробками вообще безразлично, что там где видно...
>добавил один домик в открытый мир, и сразу сталкивается с проблемой
Не "домик" в "открытый мир", а пустую коробку на почти пустую сцену. И не с "проблемой", а с особенностью технологии shadow mapping, которую нужно будет держать в уме, но которой не нужно бояться. Эта особенность есть во всех играх с shadow mapping, то есть практически во всех 3D играх (единственная альтернатива умерла где-то в нулевых, ничего нового пока не придумали). С ней можно справиться, если это необходимо, но - опять же - а необходимо ли? Ни игры, ни ассетов нет, а "проблема" - есть?
>В отличие от другого подхода, где он бы сначала месяцами делал игру, а потом оказалось, что домики нельзя добавить, и пришлось бы выкинуть месяцы работы.
Если он в соло решил сделать убийцу ААА-игры без покупки готовых ассетов высокого качества - тогда да, у него может уйти несколько месяцев на один качественный домик, который будет выглядеть достойно вертикального среза игры с открытым миром с реалистичной графикой (может пойти просить деньги у издателя с этим домиком). Но не обязательно выкидывать домик, можно выкинуть открытый мир и сделать игру про домик, если тебя НАСТОЛЬКО беспокоит протекающий между брёвнами/досками/плитами свет. Или перейти на другой движок, если тебя этот не устраивает - с готовыми ассетами это будет легко, ведь ассеты ты делал в другой программе. Пока нет ни ассетов, ни какой-либо игры, такие нюансы технологии не имеют никакого значения.
Я предполагаю, что свет протекает из-за того, что чем дальше объект от камеры, тем меньшее разрешение у карты теней (shadow map), поэтому "пиксели тени" становятся крупнее и происходит такое "протекание". Если необходимо - карту теней можно в настройках проекта увеличить и изменить пропорции так, чтобы вдалеке тень была более высокого качества. Но необходимо ли? Я даже в ААА играх видел очень кривые тени, которые приходилось отключать для экономии VRAM. Если условный Rockstar не смог в тени, то чего вы хотите от очередной инди-игры на бесплатном опенсурс движке... Адекватные игроки это понимают. Только чтобы игрок заметил твою игру, тебе нужен либо геймплей, либо ассеты, а не просто кубики с тенями на пустой сцене.
>А ты не понимаешь. Смысл "вертикального среза" - сделать демку для инвесторов, издателей, потенциальных игроков на краундфандиговых площадках и т.п.
Ну это твое мнение. Вертикальный срез делается для разработчика, чтобы узнать что все работает и реально доделать.
Даже так можно объяснить - на первом этапе то соло инди разработчик и является "потенциальным игроком", то есть ему должно самому нравится, так и "инвестором", поскольку ему надо решить, будет ли он дальше инвестировать свое время и ресурсы.
Я вообще не понимаю, с чем ты споришь, поскольку дальше ты буквально подтверждаешь мою точку зрения, что это и надо сделать, чтобы проверить что надо менять или переходить на другие технологии.
Я тоже не понимаю, с чем ты споришь. У него пока не вертикальный срез (судя по видео), и кривое освещение на кубиках не имеет отношения к вертикальному срезу ни в плане геймплея, ни в плане визуального качества (может только немного). То, что свет может протекать, было давно известно и можно было найти много раз на форумах. Кому надо - находят способ замаскировать. Ему же пока явно не надо - поэтому я и предлагаю заниматься более актуальными вещами в его проекте, чем тени или даже погода. Пока он будет делать свою убийцу ААА игры в соло, уже выйдет Godot 5, а там, глядишь, и тени улучшатся (или у всех будет 8+ GB VRAM).
Кстати, говорят, что Godot в больших студиях используют для геймплейных прототипов, прежде чем делать игру на другом движке. Ну, а для соло индюка визуальное качество вообще мало значения имеет, если твою игру берут только из-за жалости к инди или по большой скидке за компанию с другими такими же...
Вообще, вы тут не о том беспокоитесь. Вот вам копипаста:
>The right amount of jank in indie games can enhance their charm and personality, making them more memorable and engaging for players. Embracing imperfections allows developers to focus on core gameplay and creativity, fostering a unique player connection.
Может, кому-то запомнится твоя игра только потому, что свет в помещения протекает забавно...
Я спорю с тем, что ты начал писать автору, что он неправильно делает что проверяет настройки света, и ему надо бросать и бежать делать всю остальную игру, модельки, а потом уже настраивать свет (и видимо в этот момент узнать что свет протекает).
https://diskonavt.itch.io/deadwing-demo
Залипательно. Сыграл аж три катки по 30 секунд, минуте, и полторы минуты, лол.
>перед уёбыванием в армейку
Ты случаем не тот оп-разраб Обсурити?
нет, это вообще мой первый проект на годот, который зашёл дальше уровня "открыть движок и повтыкать в интерфейс"
оптимист по поводу того, что чекну фидбэк или по поводу того, что вернусь из армии?
второе. береги себя и глупостей не делай, хотя лучше всего было не идти
>неправильно делает что проверяет настройки света
Нет, он неправильно делает, что беспокоится об этой настройке на таком раннем этапе разработки игры. Проблема известная, но фиксится по ситуации.
Если беспокоиться о ней с самого начала:
1. Кинул куб CSGBox3D с текстурой досок на сцену - забеспокоился о протекающем свете - несколько дней крутил настройки, пока не добился идеально ровного освещения простого куба с текстурой досок.
2. Решил, что ему будет нужен "перекошенный дом" и повернул свой куб с текстурой досок - свет начинает протекать снова - опять несколько дней крутил его настройски, пока не добился идального света в перекошенном кубе, но сломал в нормальном...
3. Спустя недели добился идеального света на своих кубиках, и пришла пора делать нормальные модели - внезапно у нормальных моделей другая геометрия и взаимодействие с системой светотени отличается - необходимы другие настройки - придётся минимум несколько дней перенастраивать на новые модели.
4. Через полгода его скилл в 3D поднялся и пора бы обновить самые первые модели - снова геометрия отличается - снова менять настройки светотени...
Это очень сильно демотивирует - когда ты потратил огромную кучу времени на то, что оказалось совсем ненужным в будущем. Проще с самого начала эту "проблему" игнорировать, а потом заделать дырки в финальной графике, которая уже не из кубиков...
Так вот именно так делать и надо - поставить домик, покрутить настройки, добавить другой домик под другим углом, покрутить настройки, и примерно тут и станет заметно, что есть проблема, что так не получится просто накидывать домики. Тут нужно общее, системное решение, для всей игры, а не какие то ручные "фиксы по ситуации". Поэтому такие исследования и надо делать в самый ранний момент, и например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи, или пилить таки универсальную систему, а в твоем варианте будет потрачено несколько месяцев на игру, а потом выяснится, что настроить свет по ситуации станет невозможно.
>Тут нужно общее, системное решение
Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной? Они ясно говорят в документации: если какое-то решение будет полезно 99% пользователям движка (в данном случае имеем в виду 99% 3D игр), то оно должно быть в официальных сборках; если что-то полезно только 1% пользователей, оно отлетает в аддоны/модули. Если решения не существует, то его нигде не будет - или ты думаешь, за 10+ лет существования движка не нашли способа портировать решение с движков 30+ летней давности? Сам принцип освещения придуман в 1978.
>например отказываться от домиков под разными углами или от опенворлда или от смены дня и ночи
Хватит троллить. С этим настроем можно целиком от разработки игр отказаться, оптимизировав затраты - "разрабатывать игры сложно, поэтому не буду их разрабатывать - буду просто играть в готовое". Если человеку захотелось свою игру, он, очевидно, хочет разработать её любым способом, а не выкинуть из задуманного 99% из-за того, что "свет протекает" (совершенная мелочь, которую поди заметь ещё).
>настроить свет по ситуации станет невозможно
Всё возможно, просто нужны костыли в отдельных ситуациях. Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо. Заделывать заплатками тестовый кубик НЕ НУЖНО.
Игровой движок - это инструмент для работы, а игра формируется определённым видением автора, и от инструментов требуется реализовать это видение, не прируждая менять видение под нюансы инструмента. Костылями или универсально - не важно, важно лишь соответствовать задуманному. Если он задумал себе опенворлд с системой дня и ночи с домиками - окей, задуманное вполне реализуемо, хоть и с костылями, которые даже в ААА вынуждены применять. Главное следовать собственной задумке и не отвлекаться на пустяковые мелочи вроде "протекающего света" (на минимальных настройках графики он и в ААА течёт).
>Сделал дом, выбрал позицию, поворот, окружающие декорации - проверил, как это будет выглядеть, и заделал "дырки" заплатками, где надо.
Это не вариант во многих случаях - создающиеся генерацией миры, опенворлд в городе где дома могут стоять под любыми углами, смена дня и ночи, где направленный свет проходит плавно 360 градусов.
>Если бы оно было, оно было бы в ядре движка. Или ты думаешь, что разработчики движка просто так взяли и бросили систему освещения недоделанной?
Она и так всегда недоделанная, а если говорить корректнее, то есть разные вводные условия, в которых она может работать, а в других не работать.
Когда я говорю про решения, то это не обязательно ядро движка. Многие вещи решены разрабами игр в виде простых правил (например, как какой то список настроек), какие-то - аддонами, как в случае террейна.
Невероятно! Оказывается, что если ты строишь не шалаш из веток на одну ночь, а небоскреб на сотню лет, то надо немного подумать и посчитать заранее!
Вот у меня есть, например, один настроенный StandardMaterial3D или шейдер для деревьев. И штук 10 текстур деревьев, и, может, еще 1-2 параметра материала, которые будут меняться от дерева к дереву. Мне что, делать 10 уникальных материалов ради изменения 1-3 параметров? Хранить их прямо в сцене, или вообще сохранять все 10 материалов в папку с деревьями?..
А если надо будет изменить, не знаю, Diffuse Mode какой-нибудь - мне что, все 10 материалов прокликивать по очереди?
Ну или что, делать код, который будет подгружать один сохраненный материал и передавать в него эти самые 1-3 параметра, которые будут меняться от меша к мешу? Делать код через @tool, который реагирует только на изменения параметров? А так разве не выйдет по одному материалу на одно дерево, или я и тут тоже туплю? Если не выйдет - вроде неплохой вариант, но это разве не костыль? Может, я какой-то очевидный базовый функционал проебал, вот и задаю тупые вопросы?
Все верно, если у тебя разные текстуры, то и материалы будут разные. Так работает оптимизация, движок при рендере отсортировывает объекты по материалам, чтобы при отрисовке меньше между ними переключаться, чтобы рисовать сначала объект с одной текстурой, потом со следующей и тд (Само 3д разруливает буфер глубины).
Можно попробовать сделать один шейдер, и передавать в него разные текстуры. В 4-ке для этого приспособить instance shader uniforms.
>>1086152
Да я и не беспокоюсь, братан. Я просто обозначил наличие проблемы. Но это не значит, что я буду вот прям щас усираться, чтобы ее решить.
А про геймплей ты прав совершенно. Я его делаю, но он пока достаточно сыроват. Вот как доведу до какого-нибудь удобоваримого состояния, так сразу в тред запощу.
Систему динамической смены суток и погоды я вообще делать начал, чтобы отвлечься и что-нибудь новенькое попробовать. Изначально думал, что просто текстуры для скайбоксов попробую сделать, буду их как-то постепенно переключать между собой. Но в итоге эта тема меня затянула, прототип разросся и получилось (для меня по крайней мере) весьма годно.
А по теме протечек аноны выше писали использовать SDFGI, VoxelGI, дать стены толщиной в метр и т.д.
Оказалось, что у меня уже был включен SDFGI, про что я совершенно забыл, и эти утечки сильнее всего происходят именно с ним.
Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Самый лучший вариант из трех оказался VoxelGI. Подрочив настройки bias можно добиться более выраженных теней, хотя достигнуть уровня темноты SDFGI все равно не получилось. Зато почти не заметно просветов.
Делать стены толщиной в метр действительно минимизирует проблемы (но не избавляет от них полностью), но стены в метр толщиной выглядят нелепо и несуразно. Это не варик.
Другие варианты по типу отключения энвайронмента, источников солнца, запекание света и прочее не подходит по уже указанным причинам.
рпж рогалик блят. полгода уже сука а конца и края так и не видно
Жанр писать не буду, а так делаю игру, которая покорит весь ру игромир.
Вначале что-то 2D простенькое. Потом может RPG какую. А вообще, когда набью опыта, хочу 3D бродилки делать, может хорроры.
Крита/Гимп если растром рисуешь. Аспрайт если пикселями. Блендер для 3д, блокбенч для лоуполи 3д попроще.
Gimp больше для редактирования изображению юзаю. Вообще, тогда Блендера может хватить. Даже для 2D.
https://docs.godotengine.org/ru/4.x/getting_started/introduction/index.html
Начни с официальных туториалов, они хороши и по делу. Есть и 3д и 2д - выполни оба.
Не шарю за местные преколы. Я кроме шуток хочу раннер запилить
если акк у тебя новый и игра не получает просмотры в первую неделю, то тебе надо написать в поддержку и они ручками твой новорег добавят в индексацию. Ещё очень сильно запарься с тегами и превьюшкой для игры - очень сильно решает
Да. По сюжету мы в роли горца ищем аппетитного барашка для Сабантуя. Но шайтаны балять мамю их ебаль падери не дают простым гордым народам жить
Не ну погоди а проблема то у него в чем? Вроде и путь правильный и автодополнение сработало.
Сквозь куб проходят, туда тоже можно отталкиватель воткнуть
Вот что в закладочках отрыл
https://github.com/abmarnie/godot-architecture-organization-advice
Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять? В любом случае, твоей целью должна быть минимизация количества отдельных материалов любой ценой. В идеале все твои деревья должны иметь один общий материал с одним текстурным атласом. Особенно это касается OpenGL/Compatibility рендерера, но и на Vulkan можно заметить тормоза, если постараться (я тестировал это во времена Godot 4.0 или около того). А вдалеке от камеры деревья в играх часто "слипаются" в один лоуполи меш для ещё большей оптимизации, и, наконец, в плоские картинки-спрайты. Встроенный механизм в Godot позволяет только упростить геометрию объекта, всё остальное зависит от тебя. Но помни, что преждевременная оптимизация вредна, и поэтому сначала слепи из того, что есть, проведи замеры, найди самые тяжёлые места и только потом оптимизируй их.
>>1086297
>Со стандартным освещением утечек нету, однако и полноценных теней как таковых внутри помещений тоже нет.
Нет, на самом деле, на твоём скриншоте одна большая тень, просто светлая - цвета ambient lighting. Но если ты уменьшишь ambient lighting в настройках environment, тогда у тебя и снаружи дома тени будут 100% чёрными. Технически возможно менять этот параметр динамически: когда игрок заходит в тёмное помещение, ambient уменьшается до чёрного, а когда выходит на яркую улицу - поднимается обратно до серого (синеватого/зеленоватого/желтоватого). Кажется, так делали в старых играх, и это можно сделать намного эффективнее, чем любые техники GI. Если хочешь ещё больше реализма, тогда нужно ещё и bloom править относительно того, входит игрок в тёмное помещение или выходит на яркую улицу: когда только выходишь, свет бьёт в глаза и ослепляет, что можно реализовать, сильно увеличив bloom. В любом случае тебе потребуется способ определить, находится ли игрок в помещении... Что, наверное, и для геймплея пригодится (реакция NPC, стелс и т.п.), так что фича может быть намного важнее, чем может показаться на первый взгляд.
>>1086343
>Как Сабвей сёрферс и темплран
Рекомендую разобраться с этой нодой, поможет для такого раннера:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
В классическом раннере у тебя 3 таких дорожки должно быть.
>>1086393
>хардкодишь
Не, он правильно делает, это стандартный способ связки нод.
>обьяви экспортную NodePath
Это совет для Godot 3.x? Сейчас можно проще: @export label: Label... только ему это не нужно делать. У него там, похоже, самостоятельная сцена, которую он хочет куда-то цеплять для какой-то отладки. Ей будет достаточно и стандартного "хардкода". Вариант с экспортом полезен в тех случаях, когда необходима универсальная система. А вариант с $ полезен для того, чтобы прибить скрипт к конкретной сцене и явным образом ломаться в случае неожиданных изменений в этой сцене.
>>1086373
Открой вкладку "Remote" в дереве сцены, когда твой проект падает (или когда ты его запустил и он вот-вот упадёт). Там ты можешь развернуть все ноды, начиная с Root, и кончая этими своими Label. При нажатии на каждую ноду в инспекторе отображаются все актуальные данные этой ноды, даже те, которые не экспортируются в скриптах и недоступны при редактировании файла сцены. В этом режиме можно поковыряться и найти проблему своим умом. А по твоим скриншотам невозможно точно сказать, в чём может быть твоя проблема - ясно только, что "нода должна была быть, но её нет".
>Рекомендую разобраться с этой нодой, поможет для такого раннера:
Пасяб. А знаешь как выводить это всё в монетизацию через рекламу на смартфонах?
>Для чего тебе всё это? Для процедурной генерации? Или ты все деревья будешь вручную расставлять?
Да это только пример. Я в целом осознал, что нихуя не понимаю, как оптимально работать с материалами. Именно не с точки зрения оптимизации, а вот тупо удобства, чтобы не делать 10 почти одинаковых материалов и не менять в них 10 раз одну настройку в случае необходимости.
Вот анон выше написал про instance shader uniforms - думаю, это вполне может помочь. Про атласы тоже нужно будет подумать, в общем-то.
>как выводить это всё в монетизацию через рекламу на смартфонах?
Я сам не делал, но вот ссылки:
https://kidscancode.org/godot_recipes/3.x/games/circle_jump/circle_jump_11/index.html
- туториал для 3.x, аддон 6 лет не обновлялся, но принцип должен остаться прежним.
Актуальные (наверное) аддоны для AdMob:
https://godotengine.org/asset-library/asset?filter=admob
https://github.com/poingstudios/godot-admob-plugin (2 месяца)
https://github.com/godot-sdk-integrations/godot-admob (свежее)
>>1086487
>instance shader uniforms
О, а я и не знал... Вот тут подробнее, если кто-то тоже не знал:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/shading_language.html#per-instance-uniforms
>а вот тупо удобства, чтобы не делать 10 почти одинаковых материалов
Для удобства можешь написать tool-скрипт для своей сцены/ноды, которая зачем-то требует 10+ разных вариаций одного материала. У скрипта выводишь enum или другой параметр в export, а в сеттере будешь настраивать дубликат материала или выбирать материал из заготовленных заранее. Тебе просто нужен слой абстракции между материалами и тем, чем ты хочешь управлять. Например, вместо того, чтобы управлять материалами напрямую, делаешь enum State { NORMAL, DIRTY, ANCIENT, UGLY, ROTTEN }, и уже в скрипте, который делает @export var state: State: set(v)... будешь делать что-то с материалом (если это вообще нужно в конкретном случае). Если в будущем что-то потребуется переделать, то можешь переделать реализацию, не трогая эту настройку; например, если раньше "ROTTEN" делала просто серо-буро-малиновый оттенок, то теперь это же "ROTTEN" меняет несколько текстур на другие, но суть остаётся прежней - "этот объект должен выглядеть гнилым". Соответственно, вместо того, чтобы перетыкать в каждой сцене материалы на другие, ты просто меняешь детали реализации своего скрипта-прослойки.
Но прежде, чем писать такие скрипты, лучше набросать хоть что-то из того, что есть... "Make it exist first" и всё такое... А то потом будешь переделывать свои инструменты вместо работы над игрой.
Круто. Спасибо. А есть какие-то актуальные видеокурсы по годоту? Что-то похожее по годности к курсам по юнити?
>актуальные видеокурсы
Понятия не имею, я таким не интересуюсь. До массовых блокировок РКН я когда-то пытался качать какие-то видеокурсы с пиратских торрентов, и в результате забил диск этим мусором, а смотреть так и не посмотрел ничего. Лучше читай официальную документацию и делай всё сам... Я как-то глянул код к одному платному видеокурсу и ужаснулся, насколько всё криво там было, так что хуже всё равно не сделаешь. А если всё-таки сделаешь и упрёшься в ограничения - наверняка ответ уже есть где-то в интернете, а если нигде нет, то этот тред (и другие форумы) существует специально для таких вопросов.
Кстати, в Unity так и не удалось вкатиться несмотря на туториалы, а вот Godot оказался интуитивно понятен (после ознакомления с документацией). Но, может, сказался имевшийся у меня опыт программирования на других языках и инструментах...
Поляна пустая. Ты бы мог свои курсы запилить с юпуп-каналом. Так, к слову. Особенно на фоне ползучего перехода людей от юнити на годот.
А как с тобой связаться если вдруг появится предложение по тому или иному поводу?
>Поляна пустая.
Нет, много всякого, даже переходят старые "учители" с Unity, типа Brackeys (часто слышал, не смотрел)...
Вообще, Godot не так быстро обновляется, так что даже туториалы для Godot 3 могут быть актуальными, если не касаются каких-то тонких деталей, и если почитать в документации, что там изменилось:
https://docs.godotengine.org/en/stable/tutorials/migrating/index.html
>Ты бы мог свои курсы запилить с юпуп-каналом.
Я не верю в эффективность "видеоуроков" как таковых - это больше развлекательный контент, чем реально полезные уроки, если мы говорим о программировании. Вот если по моделированию для Blender, то там да, полезно увидеть процесс работы крутана, так же, как и в классическом рисовании полезно смотреть, как работает мастер. А у программиста бОльшая часть работы происходит в голове, а написание/изменение кода - это наименьшая часть... В остальном же, Godot не проще и не сложнее любой другой программы на компьютере - если ты как-то смог открыть браузер и написать на форум, то и в Godot разберёшься.
>А как с тобой связаться
Ты чё, мы же тут все анонимусы. Да я и не так много знаю, как тебе могло показаться.
>Да я и не так много знаю, как тебе могло показаться
А никто тут гта6 не собирает. Речь про раннер, который немного выйдет за рамки принятых стандартов.
Ну, как сказать. Когда придёт время собирать игру, механики, оптимизации кода и всё то, что связано с программированием нужно будет кого-то нанять. Зачем идти в файверы когда уже есть готовое решение
Увы, я могу только бесплатными советами помочь.
Кстати, вот про "endless runner": >>1010674 →
Там несколько постов обсуждения было.
Признавайтесь, хочется?
Годетту да, а тот хуй что слева слишком всрат. Впрочем, как и его ниочемная игра. У челика талант к пиару и ноль таланта к геймдеву.
Блазию хочу! Бла-зи-ю!
Наконец-то, блин. Скорее бы уже
Да я на 4.6 переехать не могу с его релиза, лол. Редактор крашится на импорте анимаций
4.7 мне не оч интересен по фичам, мне лучше стабильный движок с тем что есть
>Редактор крашится на импорте анимаций
Логи проверял? Движок можно запустить с --verbose для подробностей. Пробовал импортировать файлы по одному, чтобы локализовать проблемный? Вдруг у тебя какая-то уникальная проблема, о которой пока никто не знает - тогда ждать фиксов бесполезно. Нужно определить реальную проблему (какая именно анимация вызывает краш и почему), потом пойти на гитхаб и найти иссуй по теме, а если нет - создать новый по шаблону. Также, вполне возможно, ты там что-то намудрил в проекте, полагаясь на старый баг движка, который пофиксили, и поэтому он крашится с твоими анимациями - тогда фиксом будет переделывание твоих файлов, а не файлов движка (знаю, больно, но что поделать).
У меня есть и GTLF-анимации, и анимации, сделанные когда-то вручную в AnimationPlayer - и никаких проблем с перекатом на разные версии 4.6 не было. Сейчас я уже перекатился на 4.7, если что. Я читал иссуи с ошибками из-за повторяющихся имён нод - вроде бы, его должны уже были пофиксить.
>4.7 мне не оч интересен по фичам
Очень зря, там много quality-of-life фишек редактора. Многие нахваливают. Если ты уже сидишь на >=4.5, то я не вижу смысла избегать 4.7 (вот если сидишь на <=4.4 - то с тех пор многое поменяли...).
>мне лучше стабильный движок с тем что есть
Наверное, ты и так знаешь, но напомню: после начала работы над следующей версией, багфиксы в патч-версиях - это обычно бэкпортинг со следующей версии на старую. То есть баг фиксится внутри master-ветки (которая почти всегда впереди dev/beta/rc/stable сборок), а потом его отдельным пуллреквестом адаптируют к предыдущей стабильной ветке (в данном случае 4.6). Так что нельзя сказать, что новая версия "менее стабильная", в ней просто чуть больше улучшений, чем в старой.
Короче - зря боишься, большинство проблем поправимо. Я несколько отдельных проектов (GDScript) перекатывал с третьей версии на четвёртую и испытал не так много проблем, как могло показаться, а с минорными версиями обычно на порядок меньше проблем...
Замораживать версию движка стоит только если у тебя live-service игра уровня Genshin под мобилки. Но такого уровня команды разработчиков пилят кастомные сборки, уходящие далеко от стандартных.
Спасибо за обстоятельный ответ, так то всё по делу.
>Логи проверял? Движок можно запустить с --verbose для подробностей. Пробовал импортировать файлы по одному, чтобы локализовать проблемный? Вдруг у тебя какая-то уникальная проблема, о которой пока никто не знает
Вчера когда на радостях увидел мерджи, обратил внимание что мою проблему замерджили. PR висел долгое время. Я не автор, но следил и ждал пока примут.
>Наверное, ты и так знаешь, но напомню: после начала работы над следующей версией, багфиксы в патч-версиях - это обычно бэкпортинг со следующей версии на старую.
Знаю, да. Но ведь туда и новые фичи добавляют, которые вызывают проблемы. Взять ту же мою проблему импорта, она появилась именно на 4.6, а пофиксят ее аж в 4.6.3. В целом ты прав, я попробую и до 4.7 подняться как он выйдет в rc версию, там поглядим
А потом решил проверить, работают ли они в opengl web-exporte.
Оказалось, что с какого-то времени их туда портировали, но увы, в реальных браузерах глючат, какое-то невидимое ограничение в десяток материалов.
https://github.com/godotengine/godot/issues/112674
Хотя, может баг реализации, пишут что Blender умеет подобное поверх opengl делать
>в реальных браузерах глючат
Кто-то сомневался? Бывают ли браузеры без глюков?
Браузер без глюков - тот, что никогда не запускают...
Или все в движкосраче теперь тусуются?
Так тут вахтеры банят чуть что, с удалением всех постов в треде. Смысл постить стремится к нулю. Переполз на реддит, заодно игру там пиарить можно не шкваря ее об имиджборды.
Странно, меня тут почему-то не банили...
Может, проблема в тебе, а не в твоих "вахтёрах"?
>Переполз на реддит
Приношу соболезнования американским товарищам.
Ты тот с девочкой в дождевике? Хорошо, что тебя терли, ты злой.
Хуже вахтеров только подсосы вахтеров, поддерживающие цензуру и противники свободного общения.
Вообще никаких претензий не имел бы, если бы этот сайт не позиционировал себя как площадка для свободного общения, а, например, как институт благородных девиц.
>если бы этот сайт не позиционировал себя как площадка для свободного общения
Пошли манёвры... У тебя проблемы со зрением или ты так троллить пытаешься?
>>1087024
>поддерживающие цензуру и противники свободного общения
Цензура необходима для поддержания свободного общения:
https://ru.wikipedia.org/wiki/Парадокс_толерантности
>неограниченная толерантность ведёт к исчезновению толерантности
>сохранение толерантности требует нетерпимого отношения к нетолерантным
И вообще, тут не так часто кого-то трут. Чего бухтеть-то? Делитесь играми лучше.
У вахтера все движкосрач. Реальный парадокс тут в том, что на том же реддите, который как раз широко рассматривается как институт благородных девиц, пост пропускают, а у местного вахтера это движсрач, бан и удаление. Такое вот свободное общение, несвободней чем на огороженном реддите. Однажды проснешься, посмотришь в зеркало, а ты уже и сам сам движкосрач.
Еще и капчу опять усложнили.
Меня тут так часто терли, что я просто перестал выкладывать что-то полезное или показывать игры. Зачем тратить на это усилия? Так что пошел ка ты с оправданием вахтеров.
А то что ты пишешь - это формализм и демагогия. Это правило явно противоречит "общаться свободно, где любая точка зрения имеет право на жизнь" можно привести аналогию, а если в разделе добавят правило что можно только в наморднике - побежишь выполнять? - и это мы даже не рассматриваем вопрос, кто и когда ввел это правило, какая процедура пересмотра или отмены неактуальных правил. И почему в этом разделе настолько отбитые вахтеры, в других я такого практически нигде не встречал. Впрочем это все уже годами игнорируется в /d, так что господь, жги. Тут никого не жалко.
>>1087080
мне кажется тебе нужно проспаться и не драматизировать
>>1086968
>>1087075
>Игры делаете?
>Делитесь играми лучше
я в последнюю неделю в каком-то тильте был... Пробовал найти людей себе в команду, но все отказались назвав игру говном, естественно при этом надавав своих важных советов как надо правильно делать. Но щас вроде настроение урегулировывается, и наверн завтра продолжу потихоньку пилить
>мне кажется тебе нужно проспаться и не драматизировать
а что за идея-то? бесит вот это "ну у меня там идея кое-какая, кхе-кхе". рассказывай
мимо
Как удобно ссылаться на "правило", которое сам написал. По факту ты единолично запретил в темах движков обсуждать движки. Ты сумасбросдный тиран.
В очередной раз подтвержается правило, что есть дать слабому человеку с добрыми намерениями власть, то всегда получится тиран.
>По факту ты единолично запретил
Лол, я не модератор и никогда не был модератором. Насколько я понимаю, в /gd/ модераторы менялись несколько раз, а правилу "движкосрачей" уже лет, наверное, десять... Когда я сюда пришёл (кажется, шесть лет назад), тут уже действовало это правило. Несогласны с этим правилом лишь какие-то тролли, набрасывающие говно на вентилятор. Ладно бы это смешно было - но спустя столько лет срачей уже не смешно нифига. Давайте лучше играми заниматься.
>в темах движков обсуждать движки
Никто никогда не удалял (я не видел) посты вроде:
>наткнулся на баг Godot, issue номер такой-то, как-то возможно обойти его или решить до багфикса?
>в GDScript отсутствует такая-то фича, как мне быть?
>мой код медленный, как можно оптимизировать?
Удаляются только посты наподобие таких:
>ряяяя гадот гавно глючное, ничаво не работает, всё крашицца и не работает, фуууу, пруфов не будет
>ряяяяя годотяскрипт гавно, сишорп топ, яскозал
>ряяяяяяя чё так всё тормозит, фууу гавно какое
Ты считаешь, что удалённые посты имеют хотя бы минимальную ценность для дискуссии о движках? Буквально кидание говном на вентилятор с целью спровоцировать срач, а не адекватное обсуждение. Скажи спасибо, что разрешают срать в специально отведённом треде срачей. В любом другом чисто творческом разделе (не будем тыкать пальцами) всех таких серунов просто перебанили бы.
Это ввел котел или тот шиз, у которого "сообщество сплотилось". Их тогда мастерки троллил серега и у них попка сгорела от этого, они вошли в рейдж мод и начали банить всех.
Так все и было. Сейчас в этом правиле нет смысла. Доска и так дохлая. Любые посты ее только оживят.
>VSCode
У тебя официальный плагин установлен?
https://github.com/godotengine/godot-vscode-plugin
Если установлен, поищи по issues эту проблему.
>не показывает значение переменных
Все данные можно посмотреть в дебаггере Godot. Особенно удобно смотреть состояние нод, которое отображается в инспекторе, а не в коде скриптов.
Если честно, не использовал "точки остановки" для дебаггинга со времён Turbo Pascal 7.0... Нет лучшего дебаггера, чем выполнение кода в своей голове. К внешним дебаггерам прибегаю только если не знаю поведение API движка или забыл о чём-то...
Типичный подсос вахтера, с запугиваниями "а вот в других разделах еще суровее" (ложь), "тут не удаляют посты (я не видел)" - ну конечно не видел, они же удалены, "бывают посты только двух видов и твои я записываю в плохие" - передергивание.
>Любые посты ее только оживят.
Хочешь превратить /gd/ в филиал /b/? 4-е правило:
>Главное — не количество, а качество. Посты и файлы, не несущие никакой полезной информации, именуются шитпостингом и могут быть удалены, а постеры — забанены. Данное правило касается всех досок, кроме /b/, если обратное не указано в правилах доски.
Все претензии направляй в /d/.
Если в /gd/ будут бестолковые срачи, новички будут поддерживать срачи, и доска станет бестолковой сральней. Если будет хоть и медленный, но высококачественный постинг, то новички будут поддерживать высококачественный постинг, и это, возможно, сделает доску великой снова. Логично?
Лично я хочу видеть качественные посты анонов о разрабатываемых ими играх или интересные посты с техническими подробностями разработки игр (или игровых движков), а не срачи уровня школьников, сцепившихся друг с другом в коридоре на перемене.
Короче: не нужно "оживлять" доску шитпостингом.
>Лично я хочу видеть качественные посты анонов
Для этого надо устранить вахтеров. Пока есть вахтеры, качественных постов не будет, нет смысла стараться.
>"а вот в других разделах еще суровее" (ложь)
А ты попробуй зайти в другие разделы (не дохлые).
>ну конечно не видел, они же удалены
Я тут почти ежедневно и часто вижу, как пост с откровенным спамом висит несколько часов. Т.е. я видел множество срачей задолго до их удаления.
>твои я записываю в плохие
Т.е. ты признаёшь, что предпочитаешь шитпостить?
>>1087189
>устранить вахтеров
Ты отдаёшь себе отчёт, что модераторы не только на репорты реагируют, но и сами время от времени просматривают треды? Если есть нарушения правил, модератор удаляет их даже без "вахтёров" - только наступает это чуть позже. Простой анон не может предотвратить удаление твоего срача здесь.
Ты вообще игры делаешь или только шитпостишь?
А я сижу во многих разделах. Ну бывает иногда редкий бан на день, но уж точно не полугодовые с delall за какой нибудь вопрос в треде движка. Единственное исключение аниме-бототред в /b, но там какая то ебанутая история с детектом рейлганофага. Собственно и тут то проблема в том что определенных людей записали во враги и банят всех кого принимают за них
>>твои я записываю в плохие
>Т.е. ты признаёшь, что предпочитаешь шитпостить?
Ты не понял, что я сказал? Посты бывают намного больше чем два вида, а ты просто применил тупую манипуляцию ложной дилеммы "раз тебя банят, то твои посты точно были вида 2".
>Ты вообще игры делаешь или только шитпостишь?
Опять манипуляции. Якобы нельзя и постить полезное и шитпостить. Или якобы можно только или делать игры, или шитпостить.
>одну-клон Jedi Academy (кстати, где ты анон, как твой прогресс? У тебя прикольная игра)
Двачую. У него вроде ИРЛ работа и на игру времени остаётся мало, поэтому он редко что-то постит.
>Там чел неадекват, ладно бы с депрессией (я такой), так кидается на всех.
Да... Ему лечиться нужно, явно беда с башкой хуже депрессии/ангедонии, но он не осознаёт. Ну или он настолько задолбан ИРЛ, что на нервах постоянно. Немножко жаль, правда, что потеряли его видосы...
>Пока игры у меня нет, но если будет что готовое мб и запостю, если не постесняюсь
Попробуй поделать простые аркадные игры <90-х. Публиковать саму игру куда-то не обязательно, но её программирование поможет набить руку. В играх относительно немного рабочих паттернов, так что большинство игр копируют механики старых игр.
>>1087193
>Посты бывают намного больше чем два вида
Учи мемы: https://ru.wiktionary.org/wiki/утрировать
>>1087194
>Якобы нельзя и постить полезное и шитпостить.
Да в Godot-тредах полно безобидных шитпостов, не связанных с хейтом движка/скриптов/пользователя конкретного движка и т.п. И их обычно не удаляют. Собственно поэтому мы и набрали 79.5 тредов, лол.
>можно только или делать игры, или шитпостить.
В сутках 24 часа - ты либо работаешь, либо валяешь дурака ради развлечения/прокрастинации. Кстати, отвлекаете меня (ладно, сам виноват, что отвлёкся).
>одну-клон Jedi Academy (кстати, где ты анон, как твой прогресс? У тебя прикольная игра)
Спасибо!
Вообще, никуда не уходил, просто особо смысла пока постить не вижу, я щас по большей части занимаюсь наполнением контента пилю карты и сюжет. И то, в последнее время темп заметно снизился по определенным причинам например пробовал себя немного в другом жанре, который думаю развивать после самурая; оформлял загранник сегодня забрал, а значит скоро скорее всего страничку заведу. До этого не мог потому что оказывается, паспорт не должен быть старше 7ми лет для стима и тп. Видюшку хотел записать когда будет стабильная 4.7, и то, ток наверн меч с новым лайтом просто посмотреть как будет и мапу какую нибудь, тк пока каких-то новых функций не добавляю. А так ещё хз, куда-то пропал чел с летающей карлицей, а он меня в целом вдохновлял разработкой заниматься и делится в треде
>зачем оно нужно вообще для игры где не ААА графика
Говорят, что поддержка DX12 на Windows лучше, чем поддержка Vulkan - DX стабильнее и имеет меньше проблем с драйверами (в теории). Вот здесь, например, одно из старых обсуждений:
https://github.com/godotengine/godot-proposals/discussions/7644
Если компьютер игрока не поддерживает DX12, то Godot попытается использовать Vulkan, а если и Vulkan не поддерживается, тогда OpenGL (Compatibility). Если в настройках проекта выбран Vulkan, но он не поддерживается, то Godot попытается использовать DX12, а если и DX не поддерживается, то OpenGL. Это должно быть видно в логе при запуске проекта. По крайней мере, так написано в документации:
https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html
В новых проектах с Forward+ Godot установит DX12 по умолчанию в настройках проекта:
>rendering_device/driver.windows="d3d12"
В старом проекте останется Vulkan - это можно изменить в настройках проекта.
По моим личным ощущениям (только что проверил), с DX12 дольше компиляция шейдеров и дольше их загрузка из кэша при повторном запуске, чем с Vulkan (но у меня очень старый компьютер, на новом вряд ли заметишь разницу), но визуально ощутимых отличий не вижу (но у меня не используются сложные эффекты, и поддержка DX12 у меня на уровне "11_0").
По весу бинарного файла движка разница в считанные мегабайты, т.е. совершенно незаметная даже для инди 3D с нормальными текстурами, музыкой и т.д. Думаю, нерационально удалять его из билда, если у тебя не 2D игрушка на OpenGL (Compatibility), т.к. поддержка Vulkan пока не очень... Кстати, сейчас билды по умолчанию включают DX12, то есть никаких манипуляций для его включения не нужно.
Спасибо. И правда, если разница всего несколько мегабайт то и не надо пренебрегать
Кстати насчет шейдеров, недавно компиляцию обсуждали, какой все-таки оптимальный путь их прекомпилировать? https://github.com/Brandt-J/ShaderPrecompiler вот такое и альтернативы?
>какой все-таки оптимальный путь их прекомпилировать
Понятия не имею, я ни одного проекта на Godot не релизнул пока, поэтому этим вопросом особо не задавался. Но вариант с крутящимся кубиком в пределах Camera3D на загрузочном экране или в отдельном SubViewport должен быть более чем достаточным. Если будешь делать в основном вьюпорте и чем-то перекрывать - убедись, что оклюжен кулинг не срабатывает (если ты его используешь, он вроде не автоматический пока что, нужно настраивать). В отдельном SubViewport проблем быть не должно (если правильно выставить режим рендера). Какой-то специальный аддон тут точно не нужен - можно и самому всё настроить.
Вообще, я смотрю на бенчмарки - сегодня у всех настолько мощные компы, что даже самая "бюджетная сборка" мощнее раз в 10, чем мой текущий компьютер, на котором я делаю и тестирую свою игру. Даже ругаемый всеми в /hw/ ноутбук на встройке был бы мощнее в играх, чем мой ПК... Не думаю, что статтеры от шейдеров волнуют кого-то, кто купил новый компьютер специально под игры за последние несколько лет... А такие как я, кто сидит на старом ПК, давно привыкли, что новые игры тормозят так, что подвешивают всю ОС.
И вот ещё статья из документации, если ещё не читал:
https://docs.godotengine.org/en/stable/tutorials/performance/pipeline_compilations.html
Я подумываю собрать свой собственный загрузочный экран с компилятором шейдеров и менеджером ресурсов типа системы частиц, но у меня пока такой бардак в проектах, что лень разбираться и что-то такое делать.
Насколько я помню, если речь идет о DX12, а значит 4-ке, то там все само прекомпилируется, есть убершейдеры, что-то типа "обобщенного" шейдера, который будет рисовать твой объект, пока нужный шейдер компилируется "в фоне". Не знаю, в каком сейчас состоянии это все. Ну и надо не забывать, что современные шейдеры же кешируются где-то, то есть может быть на втором запуске игры уже и не будет перекомпиляции.
>который будет рисовать твой объект, пока нужный шейдер компилируется
Вроде бы, так и должно быть, и я даже помню, что когда-то давно замечал, как у меня объекты "мигали" во время компиляции, но от статтеров это всё равно не избавляет, и прямо сейчас на 4.6/4.7 у меня игра может подвешиваться на секунду при компиляции шейдера. Но мой комп очень слабый для современных игр.
>современные шейдеры же кешируются где-то
Да, по умолчанию кэш шейдеров включён (+сжатие). Иногда, вроде, может приводить к глюкам, если кэш сломался почему-то (у меня доходило до BSOD на какой-то из старых версий). Также стоит заметить, что каждая новая версия движка имеет свой отдельный кэш шейдеров, и кэш при запуске из Editor отличается от кэша при запуске проекта с того же Editor-билда, но отдельно от редактора (например, если положить билд редактора в папку проекта и запустить его). В первом случае кэш должен храниться в папке /.godot/ внутри папки проекта, а во втором случае кэш хранится в папке user:// проекта (её можно легко найти с помощью кнопки в меню редактора; на Windows она будет где-то в %appdata%/Godot/app_userdata). Это всё важно знать для того, чтобы правильно очищать кэш во время тестирования "первого" запуска игры.
Алсо, кэш шейдеров не избавляет от статтера в результате инициализации системы частиц, загрузки тяжёлых ресурсов с диска, генерации NoiseTexture и т.д. Так что кроме прекомпилятора шейдеров нужно ещё и менеджер ресурсов делать, если у вас игра сложнее одной сцены. Но это немного отдельная тема...
>TheDuriel
Я бы его постам не доверял. Его авторитет в r/Godot на уровне пикрил игрушки. Лол.
>Я бы его постам не доверял. Его авторитет в r/Godot на уровне пикрил игрушки. Лол.
Обычные вахтеры, которые травят умного (95% upvoted) и в меру грубого к идиотам знатока.
Где то я такое видел... А, точно
Меня выбесил его комментарий, что он якобы "invented inherited scenes", хотя всё, что он сделал - это только популяризировал эту фичу в сабреддите, а сделали её совсем другие люди (насколько я понял дальнейшее обсуждение). И он даже не исправил своё сообщение.
>в меру грубого к идиотам
Это только показывает масштабы его ЧСВ. Реально умный игнорировал бы идиотов...
>95% upvoted
На Reddit вообще странная система голосов. Иногда загоняют в -100 за нормальный комментарий, иногда залайкивают на +10к за тупейшую шутку. Зависит от сабреддита, конечно, но r/Godot по ощущениям на 90% состоит из детей/школьников, новичков в геймдеве.
Я просто хочу сказать: проверяйте всё сами, не доверяя рандому из интернета, даже если у него самое большое число попугаев в какой-то местной табличке рекордов. Особенно если этот рандом имеет настолько высокое ЧСВ, что не принимает никакую критику.
Говорю как тот, кто когда-то имел высокий рейтинг на каком-то форуме. Стыдно...
Статы годота, с официального сайта годота. Годот годот. Годот. Статы официальные. С сайта, тоже официального.
А мне вполне верится. Гораздо больше актива по Годоту стало во всех соцсетях, это легко проверить самому
https://www.youtube.com/@Gierki_Dev/videos
все наверно поржнут но именно эти две кнопки в будущем я создам огромнейшую мега проработаную глубочайшую игру и заработаю миллионы долларов
Надо в шапку, а то народ все время спрашивает - что делают на годоте?
О, кстати заебок то какой делают! Это ж пасфайндер в космосе.
https://www.youtube.com/watch?v=jQse-bQ4_-s
>Надо в шапку
Не надо. В шапку треда надо достижения местных с использованием Godot. Вот ты какую игру делаешь?
>народ все время спрашивает - что делают на годоте
Ты ньюфаг? Не "народ", а один тролль. Если кому-то необходимо посмотреть на игры на Godot в Steam, существуют официальные кураторы:
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot
https://store.steampowered.com/curator/45715609-Made-with-Godot-2
А также steamdb, поиск по тегам на itch.io и т.д.
>О, кстати заебок то какой делают!
Ну делают и делают, чего бухтеть-то?
>Это ж пасфайндер в космосе.
Это не для игроков сделано, а для ролевиков:
https://en.wikipedia.org/wiki/Starfinder_Roleplaying_Game
Теперь я официальный куратор игр на Godot в Dvach.
>Это не для игроков сделано, а для ролевиков:
Одно не исключает другого, будет минимум 50к игроков. Не балдурс гейт 3, конечно, но славу годоту прибавит знатно.
>Вот ты какую игру делаешь?
Никакую, конечно. Я делаю всякие симуляции, интерактивные утилиты, аддоны водички и прочих эффектов.
>Я делаю всякие симуляции, интерактивные утилиты, аддоны водички и прочих эффектов.
Хорошо, тогда пости скриншоты/видео в тред, если возможно - со ссылками на github, откуда качать. И полезнее для местных, и для тебя пиар/оценка...
>официальный
У Godot какая-то своя иерархия и ты в ней никто.
Впрочем, как и большинство постеров здесь...
>куратор игр на Godot в Dvach
Если б ты реально хотел их сюда приносить, мог бы предоставить ссылку на steam/steamdb, отправить скриншоты и mp4/webm трейлеры игр, обсудить, как используется движок в игре (если знаешь) и т.д. А скидывать ссылку на чей-то посторонний летсплей посторонней игры с заблокированного в РФ ютуба, совершенно без комментариев - выглядит как спам.
Мы неоднократно обсуждали чужие игры на Godot, но начиналось обсуждение с более-менее качественного поста, а не с рандомной ссылки на какой-то летсплей.
Давайте не будем делать тред каталогом ссылок.
Да ладно тебе. Просто удели минуту-две, чтобы хоть подписать ссылку какой-то личной информацией. В противном случае реально похож на спам-бота, что пробегает здесь иногда с непонятной целью.
Алсо, эти:
>>1087539
>04:03:49
>>1087540
>04:13:13
Ты мог запостить ОДНИМ постом, а не двумя.
Просто высказываю своё мнение, не более того...
Нет, я пощу это двумя постами, а не одним. Если постить это одним, то это как раз будет "каталог ссылок", а так это два поста с двумя превью разных видосов про разные игры.
Кроме того, я сначала запостил одну игру, а потом наткнулся на другую.
Не было времени нарезать под лимит, там же много часовые видосы показывающие размеры /масштаб игры. Ну потом как нибудь найду время.
>это как раз будет "каталог ссылок"
Лол. На доске лимит в 500 постов, после чего тред приходится перекатывать, чтобы он был на видном новичкам месте. Если ты постишь много мелких, не значимых постов - ты забиваешь тред быстрее, и он быстрее теряется из виду. Умышленное забивание называется "вайпом" и может быть наказуемо.
>превью разных видосов
А, я уже и забыл, что такая фича когда-то была. Уже несколько лет не отображаются превью. Да и какой смысл, если на ютубе превью - это кликбейты, не соответствующие реальности? Лучше бы красивые скриншоты из самой игры притащил, а не кликбейт.
>потом наткнулся на другую
Понимаю, вот поэтому и говорю: не нужно таскать случайные игры, на которые ты случайно наткнулся, поскольку уже давно есть списки: >>1087588
Алсо, я делаю игру на Godot, но меня совершенно не волнуют другие игры на Godot; меня волнуют только похожие игры и игры в похожих жанрах, т.к. в них я, возможно, найду что-нибудь для своей игры. Т.е. я занимаюсь осмысленным поиском референсов, а не просматриваю все игры на одном движке. Зачем ты просматриваешь игры, которые тебе не интересны?
Алсо, в "сделано на Godot" нет надёжности, ведь в реальности там половина движка легко могла быть переписана заново командой разработчиков, что обыкновенному соло инди вряд ли доступно. Это как приводить Genshin в пример Unity-игры, хотя там не оригинальный движок, а переработанный форк, и обыкновенным инди он никогда не будет доступен.
>>1087618
>показывающие размеры/масштаб игры
Достаточно было написать что-то вроде:
>Посмотрите, какой огромный мир смогли сделать, сколько разных локаций, мобов и декораций!
Ибо даже будь у меня доступ, я бы не стал смотреть многочасовой видос непонятно для чего (лучше уж приобрести игру и оценить локации на практике).
Масштабность игры на Godot не проблема. Проблема в организации процесса загрузки/выгрузки ресурсов; автоматизации из коробки пока нет, геймдевы либо велосипедят своё решение, либо вручную делают.
Кому интересно, ищите по "asset streaming". Это одно из основных препятствий перед большим open world. Реализовать-то возможно, но из коробки нет.
Ты анон, пустота, буквоки, мне твое мнение не интересно, я сам разберусь что и как делать тут.
>Ты анон, пустота, буквоки
Я в Godot-тредах 6+ лет...
Раньше было лучше...
Где же наши игры?..
Да, было время, я тогда как раз сюда пришел, после видосов Распа в бэ, думал во клево, сейчас что-то тоже сделаю, пошел на твг поучаствовать, а там просто затравили просто за то что игра на годоте, так что теперь мои игры в других местах.
Я его просто как ллмку воспринимаю, но пишет он конечно складно и логично, впрочем от ошибок его это не страхует.
>Framerate might drop, specially the first run due shader compilation.
Это написано в системных требованиях в Steam:
https://store.steampowered.com/app/3245640/
>>1087653
>мегадушнила со своими портянками
>репортя все, что ему не нравится
Вот не надо смешивать всех в одну кучу... Зачем расписывать длинный подробный ответ тому, кого зарепортил? Ответ получают лишь достойные его.
Тут у некоторых анонов странная тенденция всех смешивать в одну личность. На доске около сотни посетителей в месяц, может, даже больше. Не нужно списывать "репорты" на кого-то одного, и не нужно воспринимать ответы как от одного человека.
Здесь не принято писать "я другой анон", так что в некоторых случаях обсуждение продолжают совсем другие люди, чем те, кто его начал. Если кто-то тут запутывается, это не проблема обсуждающих...
Пиши в движкосраче. Там большие эксперты по годоту, чем здесь. Каждую косточку движка перемыли, есть все ответы на любые вопросы, даже на те, которые еще не придумал задавать.
Давненько не делал игорь и Годот не запускал. Щас пишу приложение на плюсах. И поймал себя на том, что постепенно получается Годот-подобное дерево. У меня уже есть универсальный объект, который умеет эмитить сигналы, а ещё call_deferred. В приложении есть два главных цикла: графика и логика. И вот для реализации этого самого деферред уже прям руки чешутся сделать полноценное дерево, чтоб были родители и дети, чтобы оно могло в строгом порядке проходить по всем объектам для выполнения основного цикла или отложенных вызовов.
Кароч что я хочу сказать. Годот классно сделан чисто с точки зрения архитектуры. Скучаю по тем временам, когда делал игры, вооот.
Кстати, как вы тут, потомки?
У меня в голове та самая музыка заиграла.
https://godotengine.org/article/release-candidate-godot-4-6-3-rc-1/
На шаг ближе к стабильному 4.6. Любопытно, будет ли 4.6.4?
Ты там что, велосипед с нуля изобретаешь? Почему не используешь что-нибудь наподобие C++Builder, где уже сделано всё, что нужно, и остаётся только соединить кнопочки на форме с твоей логикой через сигналы? И зачем тебе именно C++, а не C#/Java или Free Pascal?
Архитектура Godot хороша, но не уникальна. Мне она нравится в основном тем, что нет ничего лишнего, и основные фичи имеют поддержку разрабов движка. Остальные движки часто придумывают лишнее, не поддерживая старое, и это очень неудобно...
А почему бросил делать игры? Какое теперь хобби?
>>1087719
>Любопытно, будет ли 4.6.4?
Вообще без разницы, я давно перекатился на 4.7.
>прям руки чешутся сделать полноценное дерево
А вообще, не лучше ли взять тот же Godot, вырезать ненужные модули (физику, 3D рендер, GDScript и т.д.), используя оставшееся как фундамент для твоего приложения на C++? Ты же, как я понял, изобретаешь собственный UI, а не используешь готовый с готовой иерархией и сигналами. Так почему не взять Godot в качестве основы? Слишком сложно будет?
Я лично давно забил на создание приложений, т.к. всё, что может быть мне или кому-либо нужно, давно уже кем-то сделано. Нет смысла что-то изобретать. А для простого чего-нибудь нет смысла копаться в потрохах C++, можно прямо на GDScript в Godot слепить утилиту сразу с GUI. Жирновато по ресурсам, конечно, но не хуже Electron, лол.
Выглядит круто, но, похоже, очень трудно сделать.
>>1087729
Тебя за дело потёрли. Будь добрее к окружающим.
>тематические посты
В которых немотивированная агрессия к движку?
>пятнадцатилетний нарцисс
Ты сам себе врагов придумал и злишься теперь...
Хуй его знает, слишком маленький рынок. Я пару раз вгеном пользовался и просто через соцсети рисовак на коммишенны находил, но это все не ру.
>РУССКИХ художиков
Почему именно русских? Чтоб подешевле было? С переводчиком можешь хоть у японцев заказывать.
Сильно сомневаюсь, что что-то поменялось за последние годы. Фриланс биржи всё те же, геймдев форумы всё те же. Поищи в Яндексе и найдёшь кучу.
>>1087741
>слишком маленький рынок
Художников много. Просто многие совсем не шарят в геймдеве, а рисуя всякие портреты и пейзажи.
Только, мне кажется, для концепт-арта сейчас уже используются нейронки, как раз за счёт того, что они способны накидать много вариантов одной сцены практически бесплатно и очень быстро. Показывать концепты игрокам ты всё равно вряд ли будешь, и поэтому качество арта тебя не должно волновать...
> именно русских
Потому что хочу поддержать отечественных художников,
> Чтоб подешевле было?
Я предполагаю что заграничные макаки мне будут рисовать за меньший прайс
> Фриланс биржи всё те же, геймдев форумы всё те же
Я не знаю ничего такого ориентированного на рф (т.к. рыночек мёртв, но всё же)
>Я не знаю ничего такого ориентированного на рф
В каком смысле? Основные биржи не поменялись:
https://vc.ru/services/2309839-reyting-luchshikh-birzh-frilansa-v-rossii
Конкретно по геймдеву я знаю только такое:
https://gamedev.ru/job/forum/
Можешь попробовать написать в >>1079309 (OP)
>заграничные будут рисовать за меньший прайс
Если только из Индии. Всё остальное - дороже.
>>1087748
>ухудшили капчу, стало невозможно писать
Да не так и сложно, но уже вернули обратно, лол.
>>1087753
>якобы в /d кто то разбирается и исправит ситуацию
Разве кто-то обещал, что они "исправят ситуацию"?
Мне вот тоже интересно было бы найти именно русских, но исключительно потому, что зарубежным хуй деньги отправишь, мы ж под железным занавесом литералли.
С другой стороны нахуя их вообще искать, если игру не толкнуть дальше мертвого вк плей и яндекса. Ну это конечно больше мои проблемы, тут есть и крутые с внж в снг или с женами казашками.
Ой да ладно, сейчас стим забанят и случится скален.
Обсуждаете оффтоп кстати, к удалению.
Ну, как сказать. Саня - это Вася на стероидах, которая в свою очередь Трёха на стероидах. В том смысле, что Саню не с нуля собирали, а была база из предыдущих двух игр.
Хотя, с третьей стороны сейчас всё настолько упростилось, что да. 20 лет прошло как никак
По каким параметрам ты определил что дорога на восток легче халвы 1 (1998)?
Лучше бы к экзаменам готовился.
>>1087913
>>1087914
>>1087986
>>1088004
Он специально провоцирует срач. Потом он где-то обосрётся и его потрут везде, а ваши посты здесь останутся, и он будет писать, что это мы виноваты.
Просто игнорируйте такое.
Понятно что вброс, но отвечу. На гитхабе правда есть сорцы попытки в гта, но я даже не открывал их.
>>1088049
про скайрим и гта не вброс, я реально туториал ищу, но пока только на 2D нашел, может получится сделать что то в 2D и потом переделать на 3D. Проблема только сделать нормальную ветку скиллов и аттрибутов. Еще Cogito пробовал но не смог от третего лица камеру сделать
ну да, прикольно, я смотрю у того же типа как то что я хотел еще и 3D прицел без привязки к камере, а в конце по скриншоту видно что планировал сделать рпг, с прокачкой скиллов и т.д https://m.youtube.com/watch?v=CCmZntAjYhQ
Ковыряй
https://github.com/FOSS-Supremacy/OpenLiberty
Я бы сделал ставку на 2Д опенворд-рпг, в стиле боевки и окружения stoneshard (потому что все остальные реалтайм боевки в 2Д для мрачного средневековья выглядят "по детски").
По объему работ это как-минимум достижимо для одного человека. Начни просто с роликов/туториалов top down rpg
>реально туториал ищу
Попробуй начать с клона GTA 1/2 и старых 2D JRPG.
Тебе нужен туториал на "top down rpg/racing" игры.
Для создания 3D GTA нужно очень много времени и ресурсов, никак не связанных с игровым движком. Аналогично со Skyrim. Ты задолбаешься делать 3D модельки с фототекстурами, потом задолбаешься с анимациями, а как дело дойдёт до звука и музыки - обосрёшься, высрав никому не нужный нейрослоп. Движковые нюансы тут совершенно не важны.
Не все еще с бана вышли.
Я бы перекатил со скринами доставщицы, но мне лень даже стебаться.
Да.
>>1088080
Тред сделал своё дело. Пусть тонет. Теперь Годотом займутся ребята покруче нас. А мы можем отдохнуть и расслабиться в срачетреде.
мимо ОП тредов со второго по 50й
>>1088072
ну вот недавно играл в старую игру от создателей HoMM 5 - Ночной Дозор. Современный сеттинг, пошаговая CRPG боевка. Вроде 3D, но вот как то совсем не удобно, и душно. Хотелось бы привязать камеру к персонажу и двигаться с WASD. Но тогда нужно делать реал-тайм боевку. Хотя интересно возможно ли сделать пошаговую боевку с камерой через плечо, т.е. как тот же скайрим но представь что боевка пошаговая. Т.е. начался бой - можно пройти там 10 метров, стрельнуть пару раз, и дальше очередь нпс. Оригинально же.
https://youtu.be/uUCIY1BBhxk?si=T-uo6G2YNC1Tbx-8
У героев дизайн - он привлекателен ностальгирующим скуфам. В реале он ужасен и надоедает почти сразу (а я ностальгирующий скуф) - вся тактика однообразна.
Если ты сможешь решить проблему - чтобы пошаговый бой не был бы одинаковым и унылым (не зудило бы его скипнуть) - у тебя бы вышла идеальная рпг.
Но у героев есть этот момент исследования мира, там юзеры десятки тысяч карт создали для себя. Вот этот момент надо эксплуатировать.
Я бы больше написал, тонна изысканий на эту тему, но увы потрут.
Сделать хорошую 2Д рпг можно, не хуже 3Д будет цеплять. Главное не начинай с процедурных миров и данжей, это понадобиться потом, будешь все равно переделывать несколько раз.
уровни полностью процедурно генерируемые, хотя надо доработать обязательно генератор, в целом работает уже недурно лично для меня.
типов врагов больше чем показано тут, просто бежать до 20-го уровня не хочется (да и тяжко, не додумался сделать норм средство для тестирования всех уровней :) ), помимо воинов лучников и защитников есть ещё маги и призыватели, по классике хуле.
также из непоказанного есть и работает система торговли и зачарований (не улучшений).
в общем и целом работать над игрой все больше и больше тяжелее так как всё зарастает и обрастает кодом, и новые фишки имплементируются с каждым разом всё медленнее, а баги отлавливать становится сложнее, но надеюсь что в этом году выпущу, хотя на данный момент даже звуков в игре нету.
(текст если что более чем читаемый, это сжатие мп4 поебало так сильно шрифты)
>в общем и целом работать над игрой все больше и больше тяжелее так как всё зарастает и обрастает кодом, и новые фишки имплементируются с каждым разом всё медленнее, а баги отлавливать становится сложнее, но надеюсь что в этом году выпущу, хотя на данный момент даже звуков в игре нету.
я не совсем это имел в виду друже). все (буквально) механики в игре готовы, сейчас вопрос только в звуках, музыке, и локализации по сути стоит, и отлову мелких косметических багах и балансу. это было сказано скорее к тому, что если захотеть добавить что-то что должно быть связано с несколькими системами или скриптами - будет сложновато.
да и игру я делаю не две недели, а без малого - год, и это повторюсь первый мой опыт
Главное было не лень добавлять описание к репчатому луку.
Вообще, очень хорошо. Сделай боевку динамичнее, взмах оружия чтобы был таким быстрым сплешем с приятным звуком, а не кручение спрайта.
Боевка это то чем игрок будет заниматься большую часть времени - сделай её приятнее.
Уровни пустые, то что они процедурные, не делает их интереснее. Делай красивые комнаты и уже из комнат собирай данжи.
префабы будут, да, просто я их буду делать под конец так как для тестирования это вообще не особо роляет, и вид генерации изменится. т.е. в скрипте уже есть система префабов которая миксует сгенерированные комнаты с префабами, и по типам они разбиты и по назначению. просто самих префабов пока не хватает чтобы из них прям делать уровень полностью.
вот с боевкой сам понимаю что есть проблемы, не совсем понимаю как её ещё сильнее сделать лучше и динамичнее. если только добавлять блятские перевороты/стрейфы и кучу визуальных эффектов, в т.ч. для каждого из врагов.
кручение спрайта мне кажется единственный возможный вариант, просто можно поиграться с интерполяцией этого кручения и скоростью, ибо рисовать для каждого оружия отдельный спрайтщит с анимацией это будет пздец учитывая что в игре на данный момент около 60 единиц различного оружия :)
но прислушаюсь, может чего получится.
>момент около 60 единиц различного оружия
У меня немного другой стиль, персонаж держит оружие, но не машет им, вместо этого есть анимации для разных типов оружия. Типа меч - такой белый полукруг сплеш, копье такой сплеш конуса итд. Если крит то гига красный сплеш (вместо тряски экрана).
В идеале бы делать это вместо с оружием (пик2), но у меня сильное заимствование со стоуншарда, там упор не в красоту.
Первое что бросилось в глаза: При реализованной работе с тенями, с претензией на игровой стиль, типа как в олдовых данженкровлерах, сам персонаж не отбрасывает тень, гуляя около костра.
персонаж ОТБРАСЫВАЕТ тень от костра, просто возможно (не пересматривал запись) в этот момент у игрока был активен факел в руках - в этот момент игрок не отбрасывает тень, да.
единственное - за игроком тень не отбрасывается, т.е. только если игрок НИЖЕ источника света будет тень (ибо она немного ломает логику скрипта и за спрайтом игрока тень особо не видно - да и для оптимизона неплохо)
видишь, просто я бы хотел чтобы визуально было видно смену оружия, поэтому и сделал так.
а так в любом случае пришлось бы делать несколько таких анимаций - ибо у меня несколько ТИПОВ оружия - мечи, топоры, ножи, булавы, двуручные мечи, двуручные топоры, двуручные молоты, копья, посохи и так далее. и для каждого из типа нужно было бы свою анимку рисовать, ибо есть например топоры с лезвием с одной стороны - а есть двухсторонние, т.е. лабриссы, и там например тоже уже другая анимка нужна.
поэтому вот такой костылик. но учту твои слова в любом случае, спасибо.
(и разрешение в игре - 16 пикселей у тайлов, там особо не разгуляешься в красоте спрайтов)
Помню твои предыдущие отчёты. Молодец.
А как ты систему света и тени сделал? С помощью встроенных Light2D или это твой личный шейдер? Я пытался сделать похожие тени в прошлом и не смог.
>>1088097
>взмах оружия чтобы был таким быстрым сплешем с приятным звуком, а не кручение спрайта
Согласен, анимация выглядит как-то вяло.
>>1088122
>разрешение в игре - 16 пикселей у тайлов, там особо не разгуляешься в красоте спрайтов
Он говорит об анимации через AnimationPlayer, а не покадровой перерисовке каждого оружия заново.
>в любом случае пришлось бы делать несколько таких анимаций - ибо у меня несколько ТИПОВ
Делаешь одну анимацию в AnimationPlayer на каждую отдельную категорию оружия. Тебе не нужно спрайты перерисовать, но анимация должна быть сочной.
а почему именно на такую версию залочил ? есть какие то подводные камни что бы не ставить актуальный билд ?
>а так в любом случае пришлось бы делать несколько таких анимаций
В том и дело ты делаешь анимации к типам оружия, а не к каждому оружию (у мечей свое, у кинжалов свое итд).
Там еще по цвету сплеша зачарку видно (и когда она кончилась). Например было оранжевая (огонь), потом стала белая - значит кончилась зачарка (да, механика со скайрима).
В целом можешь анимации сколько угодно завести, главное чтобы чувствовался удар.
>видишь, просто я бы хотел чтобы визуально было видно смену оружия, поэтому и сделал так.
Оружие видно в руках (тебе надо будет удлинять спрайт героя), когда проходит анимация я еще двигаю персов. В общем, это кажется живее, просто поэкспериментируй.
пики со стоуншарда, они там тоже не махают оружием, просто держат
На годоте можно делать любые игры, это универсальный движок.
Не знаю, что ты там под словесными играми подразумеваешь, но вот тебе "о счастливчик", 5 секунд в утке с клавдией:
с помощью встроенных оно работает кривее некуда, и только для статичных кое как. но там надо ебстись с окклюдерами и прочим, поэтому я шейдер написал, который копирует альфа канал спрайта (включая кадры анимации) и делает черным, накинул градиент прозрачности, и повернул. собственно всё.
насчет анимации повторюсь, я пытался это сделать, пытался нарисовать, но мне результат честно не понравился.
в стоуншард играл да, в целом и хотел сделать нечто похожее - но гораздо проще (не в плане сложности а в плане освоения) и реалтаймовое.
удлинять спрайты эт уже поздно - просто потому что вся броня, шлемы, щиты да и размер врагов - всё подстраивалось под этот размер. удлинять перса, значит по сути перерисовывать вообще всё - в том числе стены и окружение т.к. игрок будет просто напросто выше чем стены епта.
думаю релизнуть ранний доступ, и с первой копеечки уволиться с раб оты и за быстрый срок доделать и наполнить контентом до конца (идеи по наполнению после 1.0 версии есть). но честно говоря понимания где как и что лучше - нет. сначала вообще думал на итч закидывать бля
просто сейчас хз дизморалит будто, как будто всё это зря а я хуйню полную сделал. делаю не ради денег, деньги нужны скорее исключительно чтобы я мог выкладываться в этом деле на полную, и нужен хотя бы прожиточный минимум епта.
говорю норм игра пока выходит, продолжай в том же духе бро
>значит по сути перерисовывать вообще всё
Если дело к концу, тогда да. Но даже не меняя, мне думается можно что-то еще сделать с боевкой.
Честно говоря, стены я подумал это плейсхолдер.
>>1088134
>есть шанс на этой игре заработать деняк
Хз насколько игра глубока по геймплею, но по видосам кажется весьма поверхностной и пустой. Но у стоуншарда вообще вроде сначала был пролог и пустой мир.
стены это тайлсет, узел TileMapLayer - как и пол, как и толщина стен. НЕ тайлмап это только объекты и сущности.
насчет остального - ну записывать видео со всеми механиками было бы долго, но могу кратко попытаться обьяснить, ибо из видео действительно кажется так.
суть проста действительно - наебнуть финального босса на 30-м уровне. в игре 6 локаций по 5 уровней, в конце каждой локации босс с уникальными эффектами.
игроку в этом мешают как враги (которые подразделяются на собственные классы воина, лучника, защитника, мага, призывателя), так и голод, необходимость поиска/крафта экипировки, и РАНДОМ
сама система игрока на самом деле классическая - 4 характеристики от которых зависят все остальные показатели:
сила (физ урон и способность надеть то или иное снаряжение), ловкость (коэф. уклонения, точности, скорости передвижения и регена энергии), выносливость (объем хп и энергии), магия (множитель маг. урона, реген маны и её объем).
игрок может как искать лут на уровнях, так и выбивать его с врагов, сундуков, или на худой конец крафтить сам - скрафченные игроком предметы имеют больший запас прочности, но по характеристикам стоят между основными тирами (например из рецептов выпавших на второй локации игрок может сделать броню чуть лучше брони выпадаемой на второй локе, но чуть хуже чем на третьей).
экипировку можно улучшать (плюсуя к их характеристикам) или зачаровывать редкими рунами которые дают особые эффекты, типа вампиризма, огненного удара и так далее. чинить экипировку тоже можно.
в игре помимо физических баталий есть магия. заклинания огня (разрушающие деревянные объекты, а также сжигающие горючие предметы у игрока в инвентаре), заклинания заморозки что станят сущностей, всякие иссушения, огненные кольца и дожди, направленные магические стрелы, призыв миньонов и прочее.
В игре есть классы - особо геймплей сильно они не меняют, но задают вектор - прим. маг не имеет силы вовсе, но имеет конское значение магии, которое позволяет ему быстрее регенить ману, давать + к маг. атакам и так далее, но крутое оружие как минимум по началу он брать не может пока не прокачает силу.
по сути это рогалик завязанный на чистом рандоме - если тебе повезёт найти крутой лут в начале считай ты подебил (но ошибки все равно непростительны - даже будучи танком ты можешь пососать не подготовившись к битве с боссом и быть попущен задорной бомбой которая игнорирует коэф. уклонения).
но и этот рандом можно "осадить" - как раз таки крафтом (если не повезло найти крутой гир - сделай его сам), покупкой и торговца "тотема воскрешения", или просто правильным пониманием того каких врагов стоит бить, а от каких лучше убегать.
всё что пока что вспомнил. в остальном и не было идеи сделать АААА игру - но была идея сделать простенький тайм-киллер с чувством кайфа в моменты победы над рандомом (как и в любом рогалике) и с максимально простым освоением. когда я буду это продавать, то не думаю что ценник будет больше пяти долларов.
>есть шанс на этой игре заработать деняк?
Конечно, есть. Но нужно собирать сообщество, и как можно раньше. Для примера, эта опенсурс (GPL) игра разрабатывается фуллтайм соло разрабом чисто на пожертвования игроков, при том что в гугл плей она доступна бесплатно и в ней нет рекламы:
https://github.com/00-Evan/shattered-pixel-dungeon
Твоя игра на первый взгляд выглядит достойной, достаточно проработанной. Но учитывай, что SPD разрабатывается с 2014 как форк игры из 2012, она достигла популярности не за один день. Т.е. если ты просто выложишь игру в стим/гугл - почти никто не заметит. Нужно формировать сообщество заранее, собирая неравнодушных со смежных сообществ.
>>1088141
Много механик и контента, молодец. Возможно, тебе стоило раньше начать делать early access сборки для избранных тестеров. Тебе самому интересно играть? Пробовал кому-нибудь дать поиграть? Преимущество рогаликов в реиграбельности, т.е. рогалик можно перепроходить много раз "как первый раз", но скилл игрока тоже должен быть важен для победы, иначе получается ощущение несправедливого рандома.
>стены это тайлсет, узел TileMapLayer - как и пол, как и толщина стен.
Ну это я знаю, у тебя же нет привязки к тайлам, нет необходимости делать все одного размера кругом.
По поводу всего остального. Ты уже много сделал - точно не останавливайся, это было бы глупость. Главное мерило качества - хотел ли бы ты сам играть в такую игру?
В остальном вкусы у всех расходятся. В том же стоншарде разрабы сейчас делают уклон в иммерсивность (настроение, кушать, "корованы" итд), а стримерам хочется рогалика.
У всех вкусы разные, смотри на игру со своей колокольни и задумки.
капчу снова изговнили, я манал тут сидеть
я шарю про SPD, буквально с детства играю, поэтому визуально оно может быть похоже, но все же пытаюсь делать по своему.
повторюсь это первая игра как таковая, и я не шарю как лучше привлекать аудиторию, когда и как это все делать, на каких этапах и т.д. да и в еарли ассес кидать игру в которой даже звука нет… надо найти где-то бачей 200 чтобы на фрилансе звукарю дать задачу, а для меня пока что эта сумма неподъемная :)
@tool
class_name TacticalNavigationRegion3D
extends NavigationRegion3D
@export var tactical_influence_map: TacticalInfluenceMap
...
при bake генерирует граф и пишет в
class_name TacticalInfluenceMap
extends Resource
@export var influence_nodes: Array[InfluenceNode] = []
...
InfluenceNode тоже ресурс
в рантайме influence_nodes пуст, другие поля (примитивы) на месте
сам ресурс сохраняю на диск и в нем все ок. В редакторе все ок
Когда запускаю в remote ноды есть, но фактически при обращении на стеке массив пуст
поясните что не так
блэт нет, после перезагрузки проекта из ресурса ноды удаляются. Все еще не понимаю что не так
Не будем катить до 4.7.stable? Вроде скоро выйдет.
На днях вышла вторая бета 4.7:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-2/
Фиксанули ResourceLoader::load_threaded_request():
https://github.com/godotengine/godot/pull/118824
Может, у меня загрузка игры ускорится? А то я этот загрузчик использовал несколько версий назад и ВНЕЗАПНО загрузка лишь удлинилась... Я такой: "ок, возможно, это норма, просто сцены у меня пока что маленькие, всего 4 потока ЦПУ, наверняка там есть преимущество на более тяжёлых ресурсах"... Нужно посмотреть поскорее, что получится с новой бетой.
Теперь внутренние ноды берут материал родителя:
https://github.com/godotengine/godot/pull/115637
Выгодно для тех, кто делает шейдеры для GUI.
Юзабилити: передвинули кнопку очистки лога:
https://github.com/godotengine/godot/pull/118954
Говорят, самая важная кнопка лога. Лол, всё так.
Undo/redo движения камеры в режиме пилота:
https://github.com/godotengine/godot/pull/119349
Если кто упустил, в 4.7 добавили вот этот QoL:
https://github.com/godotengine/godot/pull/109945
Мне очень не хватало этой фичи со времён 3.x.
>Фиксанули ResourceLoader::load_threaded_request():
Я вообще на тройке сижу, но думаю там история как с гилом в питоне - многопоточностью настолько комплексно рулить, все эти мьютексы-хуютексты-дедлоки, чтобы вин перформанса по сравнению с одним потоком мизерный, и основный юзкейс это, по сути, интерактивные лоадинг скрины, пока у тебя вне основного потока что-то грузится.
>sage
>в поле темы
>в утонувшем треде
Это такой тонкий троллинг?
>многопоточностью настолько комплексно рулить
Ты ссылку не открывал? Там какой-то анекдот:
>When multiple threads try to load the same sub-resource the ResourceLoader's anti-deadlock protection thinks that the other threads loading the dependency are old threads blocked on a dependency.
>The current thread will then immediately start to load the sub-resource since they can't wait for it. This can then lead to multiple threads loading the same resource concurrently.
>We fix the problem by recording in the task when loading has ACTUALLY started, and if so we simply wait.
>This is no worse than before, at the point where we are waiting now we previously re-started the load entirely.
Т.е. раньше можно было отправить джва десятка независимых потоков грузить один и тот же ресурс, поскольку они все думают "Что, зависли? Ладно, я попробую вместо вас", и все делают ОДНО И ТО ЖЕ.
Обрати внимание на числа на пикриле.
>вин перформанса по сравнению с одним потоком мизерный, и основный юзкейс это, по сути, интерактивные лоадинг скрины, пока у тебя вне основного потока что-то грузится.
Нет, бутылочное горлышко загрузки с диска - это исключительно скорость HDD/SSD. Поскольку SSD безразлично положение файла в памяти, они могут ускоренно переключаться с одного на другой. А всё остальное - парсинг, создание объектов и т.д. - это независимые задачи. Поэтому прирост от многих отдельных потоков должен быть большим... Но тут проблема была в том, что потоки не знали, что им необходимо грузить самим, а что - подождать.
