Шапка: https://hipolink.me/godothread
Предыдущий: >>954699 (OP)
Архивный: >>951925 (OP)
2120x1080, 2:20
В моем дестстве такие игры были на флеше, и там героиню ебали в обязательном порядке, и по-другому такие игры уже не выпускали. Как в игре с фансервисом?
Она слишком деревянная. Попробуй добавить ей кошачие ушки и хвост, посмотрим если это прибавит ей кавайности.
>на шарпе с екс, используя годот для графики
Сразу предупреждаю, большинство юзает Godot как решение "всё в одном" с GDScript и без лишних либ. Поэтому твои проблемы большинству могут быть непонятны. Лучше обращаться на реддит, там вроде наибольшее комьюнити, постоянно что-то постят.
>Я хотел бы, чтобы логическая часть о знала о графической как можно меньше
А как вообще паттерн MVC ложится на ECS? По идее, использование ECS ограничено в Model, а вьювер и контроллер только обращаются к компонентам ECS?
>используя годот для графики
>Node2d, у которого пока что только Sprite
>эти ноды двигать/удалять вместе
>ссылки на ноды с айдишниками
Если у тебя ECS и Godot только рендерер, то зачем понадобились ноды? Ноды и сцены в Godot решают точно такую же задачу, как и "ECS без оптимизаций" - позволяют комбинировать компоненты в сущности с высокой степенью гибкости и реюзабельности кода. Именно поэтому Хуан против введения ECS в ядро.
Если тебе нужен только рендерер, используй сервер:
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
https://docs.godotengine.org/en/stable/classes/class_renderingserver.html
Дерево сцены оставь в покое, напиши свой мейнлуп:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Тогда ты сможешь всё что надо делать в ECS, а Godot останется в качестве рендерера (непонятно зачем, вроде существуют хорошие библиотеки для 2D). Ещё можно пойти путём "Соника" и взять только модули из исходников, но это если ты в C++ разбираешься.
Не, у него там на уровне пропорций проеб. Колени не на своем месте, плюс икры шире ляшек. И бошка приплюснутая, слегка инцельская как будто. Ну и в анимациях тоже на колени забили, нога никогда не бывыает прямой - всегда на полусогнутых. Никакие ушки тут не вытащат.
> используй сервер
Спасибо, почитаю, но боюсь что такая большая переделка может пойти во вред мотивации. Всё таки такие переделки, не показывающие сразу результата - угнетают
> непонятно зачем
Есть такое, такими темпами уйду на monogame какой-нибудь или даже robust toolbox, хотя очень не хочется переписывать игру, когда игры ещё нет толком.
> зачем понадобились ноды
Я не знаю как иначе работать с графикой Годота
> А как вообще паттерн MVC ложится на ECS?
Думаю натянуть как нибудь можно
>боюсь что такая большая переделка может пойти во вред мотивации. Всё таки такие переделки, не показывающие сразу результата - угнетают
Э, падажжи, ты еще не подготовился к внезапному добавлению мультиплеера в свою игру? А вдруг в ммо захочешь переделать? Упущение, братан.
>ты еще не подготовился к внезапному добавлению мультиплеера в свою игру? А вдруг в ммо захочешь переделать?
Падажжи, у него ЕЦС, а по ЕЦС переделка игры в ММО настолько проста, насколько добавление сущностям компонента Мультиплеер и системы Мультиплеер. По крайней мере, так говорят популяризаторы ЕЦС.
Посмотри Овервотч. Сначала делали ММО Титан, а в результате получился кооперативный шутер. Почему? Потому что ЕЦС позволила переделать одно в другое. Потом пытались добавить синглплеерный контент, но проблема была в художниках, а не программистах.
Так что добавляйте ЕЦС и сможете переделать свой синглплеер 2д пазл-платформер в ММО 3Д гоночный шутер всего одним лёгким добавлением компонента.
мимо маркетолог ецс парадигмы
Я подобную анимацию на флеше видел. Колени были согнуты чтобы обратная кинематика не сгибала их в другую сторону когда задействована физика взаимодействия между неровным полом и пяткой.
Пускай ушки с хвостом попробует, потом я физику груди посоветую.
>Всё таки такие переделки, не показывающие сразу результата - угнетают
Согласен, но что ещё поделаешь. Если хочешь сразу результат - говнокодь от души, купайся в лапше. Но потом не плачь о том, что запутался в своём коде.
>уйду на monogame какой-нибудь
Помни, что движок - инструмент, а инструмент нужно выбирать под задачу (игру). Если тот же моногейм подходит под твою задачу, то почему нет? Сказки про культизм пользователей Godot преувеличены.
>Я не знаю как иначе работать с графикой Годота
Первым делом нужно было тщательно изучить всё устройство движка, прежде чем начинать работать с конкретными компонентами. Ноды - это абстракция высокого уровня над внутренними "серверами", она призвана упростить создание игры через редактор, абстрагируя дизайнера от внутренней кухни движка.
>Думаю натянуть как нибудь можно
Вот именно этим и нужно было заняться с самого начала: разделить игру на логику (модель), графику (вьювер) и взаимодействие с юзером (контроллер). Концептуально для начала, а уже потом - в коде.
>переписывать игру, когда игры ещё нет толком
А что ты вообще делаешь? Для чего там ЕЦС?
Я делаю рогалик. ЕКС мне нравится как архитектурный подход, а не ради оптимизаций, что наделал компонентов, наделал систем и можешь плодить сущности комбинируя компоненты.
довел симуляцию до совершенства, продал бабушкину квартиру на авито и бросил геймдев
Фигня решение. Сдавать надо.
2160x1080, 2:57
>В моем дестстве такие игры были на флеше, и там героиню ебали в обязательном порядке, и по-другому такие игры уже не выпускали. Как в игре с фансервисом?
Да, он есть и буду пилить больше, как только начало сюжета запилю. За качество фансервиса так сказать извините.
>>58584
>Она слишком деревянная. Попробуй добавить ей кошачие ушки
Тут ушки как анон >>58600 выше уже писал врятли помогут. Да, кавайности прибавит, но нужно анимацию саму поменять. Это не сложно, но хочу уже базу закончить, тк постоянно что-то новое хочется добавить или исправить.
Ушки добавил, но пока без хвостика, для неё нужна ещё одна кость, и значит перелопатить все анимации
>>58541
Captivity, но всратый и пытаюсь в метроид
>на уровне пропорций проеб
Не вижу серьёзных проблем с пропорциями, всё ок.
>Колени не на своем месте,
Они чуть выше, чем обычно, но для стилизации ок.
>плюс икры шире ляшек.
Сойдёт для стилизации. Вспомни Mega Man.
>И бошка приплюснутая, слегка инцельская
Ок для стилизации + задумка автора, наверное.
>на колени забили, нога никогда не бывыает прямой
Это норма, ты ИРЛ тоже ноги никогда при ходьбе не разбигаешь на 100%, полный разгиб ноги в колене вызывает болезненное напряжение связок. Только акробаты всякие и гимнасты могут разогнуть. Это не говоря об инверсной кинематике, там свои нюансы.
Твоя проблема в том, что ты пытаешься навязать реалистичные пропорции на стилизованную игру. Реализм в графике делает игры банальными. Лучше высрать кривое говно из пейнта, но в одном своём СТИЛЕ, чем бездумно копировать реальность, как в 100500 других фОтОрЕаЛиСтИчНыХ (в 2д, лол) играх. Мультяшки вон популярны, а в них вообще клали на пропорции реальных людей, рисуют каких-то там монстров и люди их обожают, удивительно, правда?
хуя вспомнил
>Она слишком деревянная.
Потому что у него один цикл анимации повторяется бесконечно на одной и той же скорости независимо от скорости движения персонажа. Типичная ошибка.
>>58619
>нужно анимацию саму поменять.
Дело не в анимации, проблема решается легко. Тебе нужно связать скорость анимаций со скоростью движения по оси X. Легче объяснить на примерах:
1. Игрок жмёт "вбок", но персонаж упирается в стену: скорость движения 0 => скорость анимации 0. Значит, персонаж не перебирает ногами возле стены.
2. Персонаж разгоняется или замедляется: скорость движения плавно изменяется => скорость анимации тоже плавно изменяется. Если правильно подобрать коэффициент, тогда ноги будут синхронизированы с поверхностью, по которой идёт персонаж. Останется только регулировать высоту ступней (рейкасты).
3. Если что-то отталкивает персонажа со скоростью движения выше максимальной скорости ходьбы, то скорость анимации ног выше 1, либо персонаж переключается в специальный режим (регдол).
Это только на словах звучит сложно, на практике реализуется очень легко. Саму анимацию трогать не нужно, регулируется только её скорость. Также, для анимации ходьбы задом, достаточно задать скорость анимации меньше 0, чтобы ноги двигались наоборот.
Если у тебя только AnimationPlayer:
https://docs.godotengine.org/en/stable/classes/class_animationplayer.html#class-animationplayer-property-speed-scale
Если используешь AnimationTree (рекомендую):
https://docs.godotengine.org/en/stable/classes/class_animationnodetimescale.html
>>героиню ебали
>Да, он есть и буду пилить больше
Добавь возможность прокусить член в процессе изнасилования, нанося 100% урона и полностью отключая противника, но делая окружающих (если групповое изнасилование) более агрессивными. А то отсутствие возможности сопротивляться раздражает. Поиграй в Degrees of Lewdity, там при изнасиловании возможно кусаться, бить каблуками и кулаками, рвать когтями, бодаться рогами, использовать спрей. Да, с графикой будет сложнее сделать, но ведь интереснее. Кошкодевочка ликвидирует почти всех с одного кусь противнику в промежность независимо от пола.
>Она слишком деревянная.
Потому что у него один цикл анимации повторяется бесконечно на одной и той же скорости независимо от скорости движения персонажа. Типичная ошибка.
>>58619
>нужно анимацию саму поменять.
Дело не в анимации, проблема решается легко. Тебе нужно связать скорость анимаций со скоростью движения по оси X. Легче объяснить на примерах:
1. Игрок жмёт "вбок", но персонаж упирается в стену: скорость движения 0 => скорость анимации 0. Значит, персонаж не перебирает ногами возле стены.
2. Персонаж разгоняется или замедляется: скорость движения плавно изменяется => скорость анимации тоже плавно изменяется. Если правильно подобрать коэффициент, тогда ноги будут синхронизированы с поверхностью, по которой идёт персонаж. Останется только регулировать высоту ступней (рейкасты).
3. Если что-то отталкивает персонажа со скоростью движения выше максимальной скорости ходьбы, то скорость анимации ног выше 1, либо персонаж переключается в специальный режим (регдол).
Это только на словах звучит сложно, на практике реализуется очень легко. Саму анимацию трогать не нужно, регулируется только её скорость. Также, для анимации ходьбы задом, достаточно задать скорость анимации меньше 0, чтобы ноги двигались наоборот.
Если у тебя только AnimationPlayer:
https://docs.godotengine.org/en/stable/classes/class_animationplayer.html#class-animationplayer-property-speed-scale
Если используешь AnimationTree (рекомендую):
https://docs.godotengine.org/en/stable/classes/class_animationnodetimescale.html
>>героиню ебали
>Да, он есть и буду пилить больше
Добавь возможность прокусить член в процессе изнасилования, нанося 100% урона и полностью отключая противника, но делая окружающих (если групповое изнасилование) более агрессивными. А то отсутствие возможности сопротивляться раздражает. Поиграй в Degrees of Lewdity, там при изнасиловании возможно кусаться, бить каблуками и кулаками, рвать когтями, бодаться рогами, использовать спрей. Да, с графикой будет сложнее сделать, но ведь интереснее. Кошкодевочка ликвидирует почти всех с одного кусь противнику в промежность независимо от пола.
>архитектурный подход
>наделал компонентов, наделал систем и можешь плодить сущности комбинируя компоненты.
Повторюсь, но ноды в Godot ориентированы именно на такую архитектуру, только код и данные связаны в цельные ООП объекты, которыми можно оперировать независимо друг от друга и остальной игры.
Т.е. ты делаешь какую-то фичу из нод и своего кода, сохраняешь её как отдельную сцену. Далее в других каких-то сценах используешь эту сцену. Сцены могут наследоваться, т.е. ты можешь сделать абстрактную сцену и делать разные сцены-наследники. Базовый принцип "call down, signal up" позволяет абстрактно разрабатывать компоненты, которые будут работать независимо от того, где и кем они используются.
Ключевое отличие от ECS тут даже не в организации данных, а в древовидной организации всего проекта. Другими словами, ты собираешь из мелких частей средние части, из средних частей большие части, из больших частей сверхбольшие части. На каждом из уровней ты абстрагирован от верхних уровней, что позволяет сделать гибкие компоненты. Также нет проблемы пойти сверху вниз, создавая пустышки в местах, которые нужны, но пока не реализованы.
Подробнее о двух основных подходах к дизайну ПО:
https://en.wikipedia.org/wiki/Bottom–up_and_top–down_design
>Я делаю рогалик.
Генерацию уровней сделал, ходить по этажам можно? Тогда базовый геймплей у тебя, считай, уже готов, это можно назвать игрой (только скучной, очень мелкой). Главное во всех рогаликах - блуждание по процедурно генерируемым подземельям (или не подземельям). Остальное наращивается по желанию. Рогалик можно разрабатывать практически бесконечно...
>Лучше высрать кривое говно из пейнта
Да высирайте, кто ж вам запретит, только потом не удивляйтесь что челики плюются. У стилизации тоже есть свои законы гармонии и пропорций. У Морячка Попая огромные предплечия смотряться норм, а у этой Тянки огромные икры смотрятся как косяк. Вот и подумайте почему.
Сделал, всё что ты перечислил, но решил начать приводить всё в порядок и начали возникать вопросы "а как правильно, а как по уму"
Это решаеться на уровне скелета. Чисто техническая залупа которую надо осилить.
>А где анон, который создаёт симулятор бабушкинской квартиры.
Начал делать подъездные этажи.
Вспомнил что существует Makehuman и пытаюсь сгенерить ГГ.
Делаю ассеты.
Залил видео демок в ютуб чтобы прикреплять как портфолио в резюме
https://youtu.be/3s5Nn5sn1jA?list=PLHjlZ0QdzceC3Kx7Zb6xPTE84nGbTrvnq).
Ищу удаленку.
Движение сразу во все стороны и от того медленно. Больше всего хочется нормальную модельку ГГ. Держи музыку чтобы скрасить тоску ожидания
https://youtu.be/3QNjRLoIpUI
>Больше всего хочется нормальную модельку ГГ
Ссюка, у тебя была нормальная моделька лягушонка! Ты не найдешь ничего более подходящего к своему сеттингу, все остальное будет безыдейным дженерик говном.
>Больше всего хочется нормальную модельку ГГ
Да скачай болванчика и перескульпти под себя. Собери рефы, мудборды, хуёрды. Дело не простое, но осиляемое вполне
Поясните такую вещь, на каком языке лучше пилить штуки в годоте, чтобы потом можно было чиркануть в резюме, что ты молодец?
Или дроч шарпа в годоте никак не повлияет на конечный навык говнокодинга?
Сыглы, лучше грустного пепе ничего не будет.
на езыке пост-модерна
>у тебя была нормальная моделька лягушонка!
И все еще есть. Вот, даже из сцены ГГ не удалена. Ждет своего часа. Даже файлы сцены ГГ не переименовывал
>>58641
>Да скачай болванчика и перескульпти под себя. Собери рефы, мудборды, хуёрды.
Плюс-минус так и делаю.
>>58644
>чтобы потом можно было чиркануть в резюме, что ты молодец?
Godot не котируется среди работодателей и еще очень не скоро будет, а знание C# очень даже.
Одна проблема - интеграция в Godot у C# говенная. С одной стороны, шарп сам по себе быстрее, с другой - из-за прослойки API обращение к функциям движка у шарпа медленнее чем у GDScript. Еще один минус - настолько часто выскакивающий баг сборки C# руинящий разработку, что ссылка на обсуждение этого бага встроена в сообщение об ошибке:
https://github.com/godotengine/godot/issues/78513
Людям буквально приходится отказываться от шарпа потому что оно руинит проекты. Свою бабушкину кваритру я изначально писал на C#, но из-за вот этой вот штуки пришлось переписать на GDScript. Даже уже думал перенести на Unity.
В общем монопенисуально:
1) пилишь на гдскрипт нафиг никому не надо кроме годот и +- привыкания к питону
2) пилишь на шарпе тебя обоссывают за незнание фреймворков +- привыкаешь к синтаксису
Надо понимать, что это относительно специфичные штуки и заточены под конкретно годот.
>челики плюются
Как моська, что лает на слона.
В геймдеве решает количество продаж, а не то, что какие-то там реализьмодрочеры плюются на икры.
>огромные икры смотрятся как косяк
Главное, чтобы автору игры нравилось.
>Вот и подумайте почему.
Потому что ты дрочишь на ноги-спички?
Но я согласен, что толстая жопа лучше толстых икр. Нужна жопа в 3-4 раза шире талии, чтобы выглядела тяночкой, а не широкоплечим мужиком с сиськами. Толстые икры можно оставить как есть.
>чиркануть в резюме, что ты молодец?
Резюме на какую должность?
- говнокодерская мартышка
- архитектурный сверхчеловек
- весёлый геймдизайнер
- потешный арт-директор
- графоманский сценарист
- UI/UX инопланетянин
- копирастовый музыкант
- игривый тестировщик/QA
- кто-то ещё, занятый делом
- директор клоунов сверху
>на каком языке лучше пилить штуки в годоте
На любом, на котором ты способен что-то сделать и довести до презентабельного состояния. Твой навык доводить проект до играбельности важнее всего.
>Или дроч шарпа в годоте никак не повлияет на конечный навык говнокодинга?
Никак, потому что программирование - не о языках. А говнокодерской мартышкой лучше идти в веб, чтобы собирать лендинги для каких-то богатых лохов. Алсо, геймдев - самое нищее IT. Уж лучше быть дворником.
>>58651
>Godot не котируется среди работодателей
Godot часто используют для прототипирования даже в АААА студиях, потому что это т.н. "fast loop engine". Финальный продукт делают уже на другом движке (кастомном, к которому ты доступ не получишь).
>а знание C# очень даже
Да кому твой до диез нужен? Нужна либо макака, готовая на всё, либо сверхчеловек, могущий всё.
>приходится отказываться от шарпа
Ну а что ты хочешь? Это как сидеть на Windows и жаловаться, что она часто падает в BSOD и требует периодической переустановки на чистый диск. Либо кушай свой кактуС# и терпи, либо ищи альтернативы.
>>58652
>пилишь на гдскрипт нафиг никому не надо
Законченный проект важнее твоего говнокода.
>относительно специфичные штуки и заточены
Только если хочешь работать послушной макакой.
>чиркануть в резюме, что ты молодец?
Резюме на какую должность?
- говнокодерская мартышка
- архитектурный сверхчеловек
- весёлый геймдизайнер
- потешный арт-директор
- графоманский сценарист
- UI/UX инопланетянин
- копирастовый музыкант
- игривый тестировщик/QA
- кто-то ещё, занятый делом
- директор клоунов сверху
>на каком языке лучше пилить штуки в годоте
На любом, на котором ты способен что-то сделать и довести до презентабельного состояния. Твой навык доводить проект до играбельности важнее всего.
>Или дроч шарпа в годоте никак не повлияет на конечный навык говнокодинга?
Никак, потому что программирование - не о языках. А говнокодерской мартышкой лучше идти в веб, чтобы собирать лендинги для каких-то богатых лохов. Алсо, геймдев - самое нищее IT. Уж лучше быть дворником.
>>58651
>Godot не котируется среди работодателей
Godot часто используют для прототипирования даже в АААА студиях, потому что это т.н. "fast loop engine". Финальный продукт делают уже на другом движке (кастомном, к которому ты доступ не получишь).
>а знание C# очень даже
Да кому твой до диез нужен? Нужна либо макака, готовая на всё, либо сверхчеловек, могущий всё.
>приходится отказываться от шарпа
Ну а что ты хочешь? Это как сидеть на Windows и жаловаться, что она часто падает в BSOD и требует периодической переустановки на чистый диск. Либо кушай свой кактуС# и терпи, либо ищи альтернативы.
>>58652
>пилишь на гдскрипт нафиг никому не надо
Законченный проект важнее твоего говнокода.
>относительно специфичные штуки и заточены
Только если хочешь работать послушной макакой.
Хз, я вообще девопсер наносек, ничего тяжелее баша на работе не держал.
Так-то просто хочется, чтобы мой условный пет проект можно было работодателю показать.
Думал, запилить что-то околосетевое.
>>пилишь на гдскрипт нафиг никому не надо
>Законченный проект важнее твоего говнокода.
Ну вопрос был про ЯП который можно было бы указать потом в резюме в целом, но тут я согл, главное чего-то доделать до конца =)
>>моделька лягушонка!
>И все еще есть.
Добавь читкод как в Age of Empires.
https://ageofempires.fandom.com/wiki/Winsett%27s_Z
https://ageofempires.fandom.com/wiki/Cobra_Car
А как у девопса вообще будет смотреться строчка:
"запилил копросисьскомультиплеерный шутан, вот ссылка, пвп или зассал?"
да бля, я кучу говна на баше ваял, по сути, пихуй чё, главное, чтобы пайплайн работал.
я и не серчаю, вообще охренел, думал, меня тут сразу нахуй пошлют
>Людям буквально приходится отказываться от шарпа потому что оно руинит проекты
Так им не надо было его ташить изначально. Есть же с++...
> Ну вопрос был про ЯП который можно было бы указать потом в резюме в целом
Я долго думал, как тебе ответить и наконец нашёл годнейшую мысль, которую не грех и в шапку закрепить.
Знание языка - это знание его синтаксиса, знание наизусть его стандартной библиотеки, знание специфичных для языка трюков и подходов. Это предложение ни о чем не говорит. Поэтому я так долго думал. Знание шарпа, если говорить о нём, следует понимать по блокам using в начале листинга.
Если у тебя в портфолио:
> using System;
> using Collections;
> using LINQ;
- вот это и есть знание шарпа, которое не стыдно записать в резюме.
Но если у тебя:
> using Godot;
Это увы не является знанием шарпа, это знание годота.
> using Unity;
Это тоже не знание шарпа, это знание юнити.
Два файла написанные с такими юзингами будут кардинально различаться, словно написаны на двух сиподобных но разных языках.
Есть и C
А в чем смысл посылать? не вижу! ты спросил как я это понял " будет ли полезно моё хобби в плане дальнейшей работы" я тебе честно сказал, что пользы будет по минимуму.
>>58679
мой >>58652 ответ анону никак не противоречит твоему, я примерно то же самое сказал про шарп, только очень просто =))
сложности передачи текста =)
ты в интернет будто только сейчас зашёл
ну ладно, тогда нет смысла заморачиваться, можно продолжать ваять фигню на гдскрипте
>>58690
Тут главное не на чем, а сколько ты от это получишь удовлетворения и профита ( конечно зависит от поставленных целей )
Хорошего всем дня.
Шапка и так уже расползлась до нечитаемого состояния. Куча ссылок накидано. Я уже хз как их редактировать.
>Ушки добавил, но пока без хвостика, для неё нужна ещё одна кость
Я имел в виду хвост в качестве атрибута костюма. Рагдол веревка прицепленная одним концом к попе. Понимаю что для этого нужно заморочиться немного. Но зато имея это на руках, сможешь уже и косички ей колыхающиеся добавить, и не только ей, но и другим персонажам.
Насчет ютуб видео. Пускай она делает полшага назад когда входит в режим взаимодействия с предметами, а то бодается прямо в них головой.
>такими темпами уйду на monogame
Братишка, не лезь туда, там тебе почти всё с нуля писать придется, даже элементарные вещи, которые в любом движке изкаропки идут. Я так полтора месяца убил на прототип платформера, который в годотя мог бы сделать за неделю.
В принципе прикольно да, думаю оставлю эту тему, но щас физикой не оч хочется заниматься, я как раз начальную катсцену начал
Ты крут. Особо не церемонился прямо в вагину ей хвост воткнул. Аляповато, но скажу тебе честно, прибавилось динамики, занимает взгляд, деревянности не замечаю ИМХО.
Отсыплю еще идей. В этом твоем коулуне существуют разные групировки, типа бимбо-пластическая хирургия, фури, бдсм, лгбт-трансы, фитнес-бодибилдер-спортсмены. и прочее. Чтобы подмазываться к бандам надо их атрибутику на себе примерять. Начинаешь иметь дела с одной бандой и портятся отношения с другой. У каждой банды своя конкурирующая порностудия. Протагонистке нужно тренировать свои дырки чтобы увеличить вместительность, и выносливость. Потому что в начале игры она не может справится с большим членом физически.
Короче тема в том что днем она восходящая порнозвезда, или стримерша, а по ночам ниндзя ассасин.
>У каждой банды своя конкурирующая порностудия
Ну кста почему бы и нет, группировки изначально планировались, а так у игрока помимо сюжета будет желание открывать остальные студии, которые будут дарить новую одежду. Ток вот всякая там тренировка дырок ненужна, и впринципе строить всё вокруг ебли такое себе, у меня история о мести и решении судьбы населенного блока, как в нью вегасе
>история о мести и решении судьбы населенного блока
Тренировку и пошлость можно будет потом в отдельном дополнении, с другой героиней. По просьбам ценителей так сказать.
Про банды секс фриков мне видится так. В особо близких отношениях с бимбо-бандой - можешь себе сиськи и губы увеличить. У фуррей получить хвост в попу, у бдсмщиков - хлыст как у индианы джонса, у лгбт - большой страпон чтобы выебать какого-нибудь босса, или быть выебанной боссом женщиной.
Так же у некоторых персонажей могут быть определенные предпочтения, например большие сиськи, или гея можно соблазнить конским страпоном.
Понимаю что опять про секс, но мне кажется в этом есть свой потенциал. Насилие и секс, ингредиенты для хорошего боевичка. Только невозможность играть за качка, а только за бабу которую все ебут, может отвернуть часть игроков. А другим не будет хватать выбрать модель фембоя с chasity cage на писюне.
>внутри цикла технически невозможно добавлять инстансы
Всё там возможно, регулярно сру сотнями нод.
>Просто присвоил по одной переменной на инстанс
Это ни на что не влияет. Твоя проблема в чём-то другом.
Год назад, на Godot 3.5 у меня был примерно такой код (переписал под 4.x):
>var _blocks: Array[PackedScene] = [preload("simple.tscn")] # кусочки дороги
>var _spawned_next: bool = false # чтобы не спамить лишнего
>func _ready() -> void: # выбираем себе один из кусков дороги:
>_ add_child(_blocks[randi() % _blocks.size()].instantiate())
Когда игрок доехал, добавляем следующий участок дороги:
>func _on_enter_area_body_entered(body: Node) -> void:
>_ if body is Player and not _spawned_next:
>_ _ var next_block = load("world_block.tscn").instantiate()
>_ _ get_parent().add_child(next_block)
>_ _ next_block.global_position = $ExitArea.global_position
>_ _ _spawned_next = true
Это всё в файле world_block.gd, он в сцене world_block.tscn.
Проехал с этим кодом около 40 км (!), всё нормально было.
Новый модный тренд - прятать плюш годота в своих играх. По ссылке моделька, если кто из местных захочет себе утащить.
1136x640, 0:40
Сделал моё утро, содомит!
С одной стороны да, с другой если я ищу пути как не использовать фичи движка, как те же ноды, то возникает вопрос, а зачем мне этот движок, потому что я трачу в нём время не на то? Я не ухожу с годота, нет, потому что моя мотивация не выдержит месяц-другой работы по переносу прогресса с нулевым увеличением весёлости игры
Делай 2д. На реддите выкладывали ассет, но лень искать.
Еще как - делаешь ноду с 3д моделькой и камерой, выставляешь как тебе надо, в 2д части делаешь тукстурированную плашку и натягиваешь субвьюпорт на нее, сам порт не забудь добавить.
>месяц-другой работы по переносу
По идее, если у тебя уже есть какой-то прогресс в рогалике, то перенос на другой движок - это как перекинуть вилку из одной розетки в другую.
Потому что в рогаликах роль игрового движка стремится к нулю. Там весь "движок" может быть встроенным в ОС эмулятором терминала.
Да, я решил уже вечером пройтись и избавиться от всех using Godot, где это не кровь из носу как надо. Даже если впоследствии не пойду на другой движок, это хорошо поможет разделению логики и графона.
>поможет разделению логики и графона
Всё так. Алсо, в документации часто рекомендуется использовать средства конкретного языка вместо встроенных в движок, чтобы снизить количество взаимодействий между кодом DLL и приложением.
>Compared to ease with a curve value of -1.6521, smoothstep returns the smoothest possible curve with no sudden changes in the derivative.
Так в чём разница-то? Не пойму.
На графиках "return value" совпадают.
>Мне бы такую прокрастинацию.
Действительно прокрастинация, ибо по плану мне необходимо сделать процедурный мир с городами и персонажами. Но как всегда отвлёкся на случайные фантазии и сделал падающий ящик. Спавн машинок исключительно для стресс-теста Godot + Jolt.
>Добавь над машинками линию жизни.
>Расстреливай их...
Моя игра мечты сфокусирована на более мирном взаимодействии с NPC + исследовании мира. Твои предложения напоминают Hard Truck Apocalypse, но если уж копировать что-то оттуда, мне хотелось бы торговлю и квесты, а не стрельбу по болванчикам.
Понимаешь, сфокусированных на деструктивных взаимодействиях стрелялок очень много на рынке, берёшь абсолютно любую и играешь, а вот чего-то с фокусом на конструктивных взаимодействиях мало, особенно если речь о ГТА-образном геймплее, а не кукольном домике с видом сверху-сбоку, где весь геймплей вокруг управления кучкой идиотов.
Концепция этой игры родилась у меня от фрустраций, которые вызывает у меня ГТА. Там очень интересно кататься по городу и наблюдать за потоком машин и пешеходов, но если ты хочешь как-то с этой системой взаимодействовать - игра разрешает практически исключительно насильственные взаимодействия. А просто кататься и наблюдать за городом, который совершенно никак не меняется, быстро надоедает.
Поэтому у меня есть три вектора решения проблемы:
1. Сделать генератор карты. Даже статичная карта с процедурной генерацией доставляет новый интерес, стоит лишь изменить зерно или правила генерации, либо просто отъехать подальше от центра мира. Очевидно, интерес не бесконечный, но возможно с минимумом усилий создать тысячи вариаций.
2. Как-то симулировать изменения городов. Что-то разрушается, что-то достраивается. Очевидно, что необходимо параметрически генерировать город и изменения в нём. Это вроде бы сложнее генерации статичной карты, но в перспективе создаёт больше интересных событий на и без того большой карте.
3. Реализовать ненасильственные взаимодействия с персонажами. Как минимум, растянуть тот симулятор свиданий из GTA SA на всех NPC. Вместо тупого "убей или умри" получаем объёмное пространство событий, которое может содержать много интересного. Но это сложно и я даже не знаю, как к этому подступиться. Откладываю на потом, когда будет интересный мир.
Согласен, масштаб проекта большой, но мне давно хотелось что-то подобное, а делать мелкие игрушки особого желания нет, игрушек и так миллионы уже. Наверняка есть похожие проекты или готовые игры, однако мне интересно самому такое сделать...
>Мне бы такую прокрастинацию.
Действительно прокрастинация, ибо по плану мне необходимо сделать процедурный мир с городами и персонажами. Но как всегда отвлёкся на случайные фантазии и сделал падающий ящик. Спавн машинок исключительно для стресс-теста Godot + Jolt.
>Добавь над машинками линию жизни.
>Расстреливай их...
Моя игра мечты сфокусирована на более мирном взаимодействии с NPC + исследовании мира. Твои предложения напоминают Hard Truck Apocalypse, но если уж копировать что-то оттуда, мне хотелось бы торговлю и квесты, а не стрельбу по болванчикам.
Понимаешь, сфокусированных на деструктивных взаимодействиях стрелялок очень много на рынке, берёшь абсолютно любую и играешь, а вот чего-то с фокусом на конструктивных взаимодействиях мало, особенно если речь о ГТА-образном геймплее, а не кукольном домике с видом сверху-сбоку, где весь геймплей вокруг управления кучкой идиотов.
Концепция этой игры родилась у меня от фрустраций, которые вызывает у меня ГТА. Там очень интересно кататься по городу и наблюдать за потоком машин и пешеходов, но если ты хочешь как-то с этой системой взаимодействовать - игра разрешает практически исключительно насильственные взаимодействия. А просто кататься и наблюдать за городом, который совершенно никак не меняется, быстро надоедает.
Поэтому у меня есть три вектора решения проблемы:
1. Сделать генератор карты. Даже статичная карта с процедурной генерацией доставляет новый интерес, стоит лишь изменить зерно или правила генерации, либо просто отъехать подальше от центра мира. Очевидно, интерес не бесконечный, но возможно с минимумом усилий создать тысячи вариаций.
2. Как-то симулировать изменения городов. Что-то разрушается, что-то достраивается. Очевидно, что необходимо параметрически генерировать город и изменения в нём. Это вроде бы сложнее генерации статичной карты, но в перспективе создаёт больше интересных событий на и без того большой карте.
3. Реализовать ненасильственные взаимодействия с персонажами. Как минимум, растянуть тот симулятор свиданий из GTA SA на всех NPC. Вместо тупого "убей или умри" получаем объёмное пространство событий, которое может содержать много интересного. Но это сложно и я даже не знаю, как к этому подступиться. Откладываю на потом, когда будет интересный мир.
Согласен, масштаб проекта большой, но мне давно хотелось что-то подобное, а делать мелкие игрушки особого желания нет, игрушек и так миллионы уже. Наверняка есть похожие проекты или готовые игры, однако мне интересно самому такое сделать...
Ммм... Дальнобойщики 3....
Дайте мне плиз какой-нибудь огромный спрайт с годотом. Хочу чтобы когда игрок выпадал за текстуры и падал вниз в пустоту, там весь меш под сценой был огромным лицом годота. Так сказать, бля, в годота провалился!
>огромный спрайт с годотом
1. Заходишь: https://godotengine.org/press/
2. Скачиваешь любой понравившийся SVG-файл.
3. Закидываешь его в папку проекта.
4. ???
5. Профит!
>Make sure to use the SVG logos instead of PNG whenever possible to benefit from better scaling
Лол прям как мне надо! Спасибо.
Хочется научиться делать всё по-человечески с первого раза, чтобы не пришлось потом ради оптимизации переделывать весь проект заново, продираясь через горы сомнительных костылей
>Можно ли самому оценить качество своего кода?
Можно.
>Хочется научиться делать всё по-человечески с первого раза
С первого раза не получится, такие вещи приходят с опытом. Делай сначала как считаешь нужным, потом сам увидишь где у тебя в коде слабые места и как можно было бы сделать лучше.
>Регистрация коллизий есть, но CharacterBody не может пройти сквозь обюъект с которым есть коллизия. Как это фиксать?
В чём проблема? Тебе коллизии или проходить?
Твой объект не видит персонажа, только существует.
Твой персонаж видит препятствие, останавливается.
Что ты хочешь? Area2D?
>самому оценить качество своего кода
Это возможно только в пределах твоего опыта. Если ты новичок, оценить качество ты не можешь. Если ты с какой-то проблемой не сталкивался, тебе сложно понять, почему твой код приведёт к проблеме. Вот некоторые аноны защищают обмазывание лишними синглтонами - им опыта не хватает понять проблему.
>ощущение что делаю всё через жопу
Забей, это нормально в айти, так весь софт работает, за исключением прошивок космических кораблей, метрополитена, военной техники и т.п. А игрушки - вообще адский клубок говнокода в 99.9% случаев.
>делать всё по-человечески с первого раза
Я думаю, даже сильнейшие программисты на это не способны, тупо оперативной памяти мозга не хватит охватить проблему целиком с первой попытки. Алсо, затянутое планирование игры сильно демотивирует, поэтому лучше просто начать лепить хоть что-то.
Математики вон столетия на свои задачки тратят...
>чтобы не пришлось потом ради оптимизации переделывать весь проект заново
Это называется "преждевременная оптимизация".
https://habr.com/ru/articles/550926/
>Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
Лучше сделать участок кода медленным, но просто и понятно, чем быстрым, но запутанно и непонятно.
Переделывать тебе в любом случае придётся, и лучше заранее это планировать: именно поэтому существует концепция прототипа в геймдеве.
https://habr.com/ru/companies/miip/articles/308286/
>Очень важно на этапе создания прототипа реализовывать только то, что нужно проверить и в сжатые сроки. Прототип должен быть простым в реализации, т.к. после достижения поставленных перед ним целей, он должен быть «выкинут». Серьёзная ошибка начинающих разработчиков – нести временную инфраструктуру и «костыли» реализации кода в основной проект.
Ну и конечно, не всякую игру вообще возможно как-то оптимизировать. Если ты хочешь сделать планету из атомов, честно симулируя все законы физики без упрощений, это не заработает на современном ПК ни с какими оптимизациями, так что просто забей на идею.
Вкратце, программирование игры как рисование - делаешь сотни быстрых и кривых набросков без доработки, прежде чем сделаешь что-то хорошее.
>самому оценить качество своего кода
Это возможно только в пределах твоего опыта. Если ты новичок, оценить качество ты не можешь. Если ты с какой-то проблемой не сталкивался, тебе сложно понять, почему твой код приведёт к проблеме. Вот некоторые аноны защищают обмазывание лишними синглтонами - им опыта не хватает понять проблему.
>ощущение что делаю всё через жопу
Забей, это нормально в айти, так весь софт работает, за исключением прошивок космических кораблей, метрополитена, военной техники и т.п. А игрушки - вообще адский клубок говнокода в 99.9% случаев.
>делать всё по-человечески с первого раза
Я думаю, даже сильнейшие программисты на это не способны, тупо оперативной памяти мозга не хватит охватить проблему целиком с первой попытки. Алсо, затянутое планирование игры сильно демотивирует, поэтому лучше просто начать лепить хоть что-то.
Математики вон столетия на свои задачки тратят...
>чтобы не пришлось потом ради оптимизации переделывать весь проект заново
Это называется "преждевременная оптимизация".
https://habr.com/ru/articles/550926/
>Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
Лучше сделать участок кода медленным, но просто и понятно, чем быстрым, но запутанно и непонятно.
Переделывать тебе в любом случае придётся, и лучше заранее это планировать: именно поэтому существует концепция прототипа в геймдеве.
https://habr.com/ru/companies/miip/articles/308286/
>Очень важно на этапе создания прототипа реализовывать только то, что нужно проверить и в сжатые сроки. Прототип должен быть простым в реализации, т.к. после достижения поставленных перед ним целей, он должен быть «выкинут». Серьёзная ошибка начинающих разработчиков – нести временную инфраструктуру и «костыли» реализации кода в основной проект.
Ну и конечно, не всякую игру вообще возможно как-то оптимизировать. Если ты хочешь сделать планету из атомов, честно симулируя все законы физики без упрощений, это не заработает на современном ПК ни с какими оптимизациями, так что просто забей на идею.
Вкратце, программирование игры как рисование - делаешь сотни быстрых и кривых набросков без доработки, прежде чем сделаешь что-то хорошее.
> Что ты хочешь? Area2D?
Хочу персонажем проходить сквозь тайлы и при этом регистировать момент входа\выхода из них + то на какие тайлы я зашел (физический слой какой у тайлов).
Сейчас я добавил юзеру дополнительное Area2D, но он тоже регистрирует только "_on_area_body_ххххх", вместо "_on_area_ххххх".
Если персонаж вообще не нуждается в обработке препятствий, то CharacterBody2D можешь выкинуть, данная нода нужна только когда есть препятствия.
У Area2D есть несколько настроек того, что ей нужно регистрировать. Но бывают нюансы из-за багов:
https://github.com/godotengine/godot/issues?q=is%3Aissue+area2d
Актуальные баги не знаю, смотри сам.
Алсо, если тебе нужно не отдельные редкие клетки проверять, а вообще все клетки, тогда лучше это:
https://docs.godotengine.org/en/stable/classes/class_tilemap.html#class-tilemap-method-local-to-map
Вот здесь есть пример использования:
https://docs.godotengine.org/en/stable/classes/class_tilemap.html#class-tilemap-method-get-cell-tile-data
Только в твоём случае будет что-то вроде этого:
>var data := tile_map.get_cell_tile_data(0, tile_map.local_to_map(player.position))
Дальше твой код связанный с данными клетки.
Персонажу обработка препятствий нужна будет, поэтому я делал разные физические уровни. В паланых было разделение вроде:
- уровень 1 - стена, не прохожу
- уровень 2 - вода, прохожу но с трудом
- уровень 3 - болото, прохожу но с трудом
CharacterBody2D с CollisionShape упирался в тайлмапы и не шел, но регистрировал взаимодействие. Сделал Area2D и регистрация пропала по факту.
Прежде чем применять велосипеды - в чем может быть проблема? Физические слои же сделаны не только для непроходимости? Так же как и маски коллизий.
>Физические слои же сделаны не только для непроходимости? Так же как и маски коллизий.
Физические слои и маски - для CollisionObject2D:
- PhysicsBody2D сталкиваются и останавливаются.
- Area2D детектит пересечение с CollisionObject2D.
>уровень 2 - вода, прохожу но с трудом
>уровень 3 - болото, прохожу но с трудом
Это не препятствия в терминах физического движка. Определяй, на каком тайле стоишь, и соответственно изменяй скорость движения. Можно непосредственно в тайлы записывать "фактор замедления" и умножать скорость на него, а не на какую-то константу.
>применять велосипеды
TileMap.local_to_map(player.position) не велосипед, а встроенное API специально для таких задач - когда необходимо определить, на чём ты сейчас стоишь.
Повторюсь, коллизии - для стен, а не для пола.
А на счёт Area2D не знаю даже, как ответить. Нужно смотреть, что ты вообще пытаешься сделать. Она функционально отличается от твёрдых тел, т.к. это неосязаемый датчик, а не твёрдое тело.
>func clear_buffer():
for file in DirAccess.get_files_at(buffer):
DirAccess.remove_absolute(file)
print(file + " was removed")
>for file in DirAccess.get_files_at(buffer):
>_ DirAccess.remove_absolute(file)
get_files_at():
>containing filenames of the directory contents
remove_absolute():
>Static version of remove. Supports only absolute paths.
Если я правильно понял, попробуй такой код:
>for file in DirAccess.get_files_at(buffer):
>_ DirAccess.remove_absolute(buffer + "/" + file)
Годот вообще такое потянет?
>как оптимизировать большое количество врагов в 3д пространстве?
Нужно в первую очередь смотреть, что вызывает наибольшие задержки.
Возможные направления:
- физика (упростить коллизии, убрать коллизии совсем);
- графика (упростить меши, материалы, анимации);
- навигация (уменьшить число запросов, кэшировать пути);
- логика (уменьшить частоту анализа ситуации, радиус анализа).
>Накинул 11 штук бегающих дебилов, а комп что греет.
Покажи скриншоты, дай подробности. Иначе помочь не сможем.
Так делой. Я же скорее симулятор + метроид пилю, а каптивити шутанчик. Ну и я ни прогать ни рисовать не умею
https://www.youtube.com/watch?v=QSpZhG-OOgI
Ты это в движкосраче увидел? Это дикий боян.
Есть другой нюанс. Если у вас графический планшет (Wacom или другой), но зачем-то выключили сервис драйвера этого планшета, Godot выдаёт ошибку "failed WinTab context creation" (точно не помню), и это может влиять на отзывчивость GUI.
Ошибка скрыта по умолчанию, появляется с --verbose.
Картинка из интернета (мне нравится).
Не видео боян, а сам трюк из видео боян. Ставлю синглмод ещё с РЦ2.
А в чем вопрос то? В годоте скелет - это нода, и у него чайлдами меши. Эти меши могут идти из одного gltf, тогда ты hide/free те, что не нужны, или ты можешь подгрузить их из других файлов и add_child.
Другое дело, что у профи немного другой подход, никто не рисует всю кожу под одеждой, потому что это в два раза больше лишней отрисовки которую при этом никто не увидит, и во-вторых потенциальные глюки при анимации когда кожа вылезет поверх одежды. Поэтому, обычно имеют заменяющиеся, а не дополняющиеся части - например, торс в купальнике или торс в платье, а не торс+купальник+платье.
>Подписан на канал
Какая разница, что там твой васян вчера откопал?
>видео опубликовано 18 часов назад
А Хуан это всё четыре (4) года назад делал:
https://xcancel.com/reduzio/status/1235744957996163073
>6 Mar 2020
>Progress so far.. multiple window support is now fully functional at the engine level, but there is still a lot to fix and clean up in the editor itself.
>Once everything works, will try to allow undocking parts of the editor.
На гитхабе столько всего, что не могу найти точно, но где-то обсуждали эту проблему с попапами:
>PopupMenu
>Inherits: Popup < Window < Viewport < Node < Object
>PopupMenu is a modal window used to display a list of options. Useful for toolbars and context menus.
Класс Window:
>The window can either be a native system window or embedded inside another Window (see Viewport.gui_embed_subwindows).
Если Godot Editor разделяется на несколько окон, все, повторяю, В С Е PopupMenu становятся нативными окнами, что очень неэффективно с точки зрения ОС. Настройка "single window mode" тут просто костыль, возвращающий старый режим работы (из Godot 3.x).
>обычно имеют заменяющиеся
Это понятно, видел такое в играх.
>А в чем вопрос то?
>подгрузить их из других файлов
Нода Skeleton3D получает данные из GLTF, куда эти данные экспортируются из Blender. Если у меня есть скелет с мешем, всё просто: скованные одним GLTF, связанные одним скелетом. Если несколько мешей отдельными файлами, то у них нет своих скелетов. Откуда Skeleton3D узнает, как деформировать меш?
Данные для скелета хранятся в меше что ли?
Есть данные скелета (длина костей, их взаимное расположение, угол поворота) + анимации (трансформы этих костей), но в мешах хранятся веса, емнип для каждой вершины, насколько на нее влияет какая кость.
Ой, дыши глубже, шизло душное.
Ты знаешь уже четыре (4) года, молодец, возьми повесь еще один дипломчик себе на стену. А другие не знают. И не затыкай никому рот, когда в треде делятся полезными советами с людьми, которые их, возможно, не знают. А то у тебя позиция уровня зашуганного чмохи, просто:
>азаза боян, я знаю и пользуюсь, а если ты про это другим расскажешь то ты движкосрачер))0
Я привык что тут 3.5 олдфага крутится. Ньюфагам информация, возможно, пригодится, не поспоришь. Просто не верится что в /гд/ ещё кто-то приходит. Согласен, не подумал, что кто-то может не знать.
Вот совет новичкам. Если вы процедурно генерируете какие-то сцены, вы наверняка захотите видеть результат прямо в редакторе сцен, чтобы менять в инспекторе параметры и сразу видеть, что из этих параметров получается. Для этого используется аннотация @tool в начале скрипта.
Однако, если вы генерируете много каких-то данных, например, ArrayMesh для MeshInstance3D, эти данные по умолчанию будут сохранятся в .tscn-файл, даже если они вам вообще не нужны. Если вы делаете меш большим числом вершин, файл сцены быстро раздует на десятки мегабайт и сохранение/открытие сцены будет занимать существенно больше времени. Да, сцены можно сжать в бинарном .scn-формате, но зачем вообще сохранять процедурно генерируемые данные?
Решение проблемы тривиальное, но не очевидное. Посмотрите сюда:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-add-child
>If internal is different than INTERNAL_MODE_DISABLED, the child will be added as internal node. These nodes are ignored by methods like get_children, unless their parameter include_internal is true. The intended usage is to hide the internal nodes from the user, so the user won't accidentally delete or modify them. Used by some GUI nodes, e.g. ColorPicker. See InternalMode for available modes.
Дело в том, что "внутренние" ноды НЕ СОХРАНЯЮТСЯ в файл сцен. Именно это нам и нужно, если мы генерируем много данных на лету и не хотим забивать ими пространство на диске (всё равно каждый раз генерируем что-то другое, или будем загружать из JSON-сейва игры). Поэтому пишем такой код:
>var _mesh_instance: MeshInstance3D
>func _ready() -> void:
>_ _mesh_instance = MeshInstance3D.new()
>_ add_child(_mesh_instance, false, Node.INTERNAL_MODE_BACK)
Теперь вы можете работать из своего кода с _mesh_instance как с обычной нодой, но в дереве сцены редактора она не отображается и на диск не сохраняется. Нет лишних десятков мегабайт мусора и задержек сохранения/загрузки сцены. Если ваш код генерации в отдельном потоке, то сначала сцена быстро загрузится (без блокировки GUI редактора), а потом уже догенерирует всё необходимое.
Также, если вы кроме меша генерируете физическое тело, то для @tool-скрипта вставьте это:
>if not Engine.is_editor_hint():
И дальше ваш код генерации физики. Дело в том, что физика в редакторе вам скорее всего не нужна (если не делаете рейкасты в редакторе), а создание и установка коллизий (тримеш) занимает у движка существенно больше времени, чем визуальные меши с тем же количеством треугольников. Эта проверка позволяет пропустить в редакторе участок кода, предназначенный только для игры.
Вот совет новичкам. Если вы процедурно генерируете какие-то сцены, вы наверняка захотите видеть результат прямо в редакторе сцен, чтобы менять в инспекторе параметры и сразу видеть, что из этих параметров получается. Для этого используется аннотация @tool в начале скрипта.
Однако, если вы генерируете много каких-то данных, например, ArrayMesh для MeshInstance3D, эти данные по умолчанию будут сохранятся в .tscn-файл, даже если они вам вообще не нужны. Если вы делаете меш большим числом вершин, файл сцены быстро раздует на десятки мегабайт и сохранение/открытие сцены будет занимать существенно больше времени. Да, сцены можно сжать в бинарном .scn-формате, но зачем вообще сохранять процедурно генерируемые данные?
Решение проблемы тривиальное, но не очевидное. Посмотрите сюда:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-add-child
>If internal is different than INTERNAL_MODE_DISABLED, the child will be added as internal node. These nodes are ignored by methods like get_children, unless their parameter include_internal is true. The intended usage is to hide the internal nodes from the user, so the user won't accidentally delete or modify them. Used by some GUI nodes, e.g. ColorPicker. See InternalMode for available modes.
Дело в том, что "внутренние" ноды НЕ СОХРАНЯЮТСЯ в файл сцен. Именно это нам и нужно, если мы генерируем много данных на лету и не хотим забивать ими пространство на диске (всё равно каждый раз генерируем что-то другое, или будем загружать из JSON-сейва игры). Поэтому пишем такой код:
>var _mesh_instance: MeshInstance3D
>func _ready() -> void:
>_ _mesh_instance = MeshInstance3D.new()
>_ add_child(_mesh_instance, false, Node.INTERNAL_MODE_BACK)
Теперь вы можете работать из своего кода с _mesh_instance как с обычной нодой, но в дереве сцены редактора она не отображается и на диск не сохраняется. Нет лишних десятков мегабайт мусора и задержек сохранения/загрузки сцены. Если ваш код генерации в отдельном потоке, то сначала сцена быстро загрузится (без блокировки GUI редактора), а потом уже догенерирует всё необходимое.
Также, если вы кроме меша генерируете физическое тело, то для @tool-скрипта вставьте это:
>if not Engine.is_editor_hint():
И дальше ваш код генерации физики. Дело в том, что физика в редакторе вам скорее всего не нужна (если не делаете рейкасты в редакторе), а создание и установка коллизий (тримеш) занимает у движка существенно больше времени, чем визуальные меши с тем же количеством треугольников. Эта проверка позволяет пропустить в редакторе участок кода, предназначенный только для игры.
Или это из-за того, что owner не установлен? Лол, я запутался.
>If add_child is called without setting owner, the newly added Node will not be visible in the scene tree, though it will be visible in the 2D/3D view.
Никогда не пользовался полем owner, но до создания internal-нод проблемы были.
>"внутренние" ноды НЕ СОХРАНЯЮТСЯ
Но мне лень проверять. Костыли какие-то...
> ArrayMesh для MeshInstance3D, эти данные по умолчанию будут сохранятся в .tscn-файл
Попробуй сохранить сцену как .scn, там бинарник будет, возможно все будет так быстро, что ты даже не заметишь.
>internal
Полезная инфа. Даже без учета сохранений полезно. Например чтобы сделать дополнительный визуальный дебаг и не париться что споткнешься об него в коде.
Нужно больше JUICE. При столкновении добавь партикли-искры , дрожание меша, посади внутри пчелика и пусть он подпрыгивает. Показывай высокую скорость с помощью radial blur, speed lines и изменение fov.
>больше JUICE
Про это знаю, но СОК на ранних этапах только замаскирует механические проблемы.
Вот, например, машинка иногда при столкновении очень сильно закручивается. Почему - непонятно, нет какой-то логики, нельзя сознательно контролировать, поэтому раздражает (и как разработчика, и как игрока). Возле земли легко перевернуться на крышу и это раздражает, а далеко от земли контроля над вращением по осям X/Z почти нет, только Y. Вообще, идея была сделать что-то вроде этого: http://store.steampowered.com/app/1366560/ - но лететь высоко над землёй скучно, потому что абсолютно ничего не происходит. Точно такая же проблема в GTA Online с Deluxo - на земле/низко над землёй можно дрифтить, маневрировать, а вот в полёте высоко над землёй ты тупо по прямой движешься, и это скучно.
Всякие спецэффекты - это хорошо, но они должны украшать чёткий механический фундамент, а не заменять его. В игре по ссылке выше, судя по отзывам, фундамент - полное говно: классический случай красивых моделек и просто отвратительного геймплея, который они не вытягивают.
Несколько месяцев назад наткнулся на видос где чел делал цветочный магазин в годо, мне эта идея изначально приглянулась поэтому добавил ее в списочек "спиздить". И вот в поисках идей вспомнил о ней, так что тдшка пока отменяется, делаю магазин. Небольшой прототип механик уже накидал, несколько артов тоже уже нарисовал. Самое сложное это пока что рисование, пиксельарт одно дело, а вот обычные арты сложновато даются ибо рисовать мышкой ну такое, да и художник из меня никакой, и это еще я благо узнал о режимах сглаживания в крите, до этого хуеву кучу раз перерисовывал все чтоб ровно было. Да и вообще обычные арты для меня серая зона, как и 3д, хуй знает как рисовать так что бы в движке выглядело как задумывалось, да ещё и так что бы спрайты не в 4к резе были. Впрочем уже немного приловчился, и даже небольшой стояк ловлю от того как уже визуально игра выглядит.
Вообще если честно мне все сложней делать игры. Я уже как год рнн, и то что я сделал ставку на геймдев - обременяет. Дохуя сил с нулевым выхлопом, а часики то тикаю, оглянуться не успел как четверть века мне стукнуло. Еще и эти сосанкции блядские, без анальным вертением жопы хуй выложишь игру в тот же гуглплей, или стим. А хуже всего то что на это еще и деньги нужны. Да даже если изъебнешься с релизом на площадки, деньги с них так просто хуй выведешь. Вообще изначально геймдев был увлечением, но решил попробовать заработать на этом, чому бы нет. Это я все к чему, в свободное время решил почитывать книжечки по питону + вся эта хуйня которую везде требуют. Мб в бекенд куда получится.
Вот бы выпустить игру которая заработает мне пару десятков тысяч бычей. Я разве многого прошу?
По сравнению с геймдевом любой вариант будет надежнее.
А я как раз пару лет назад из питоно-бекенда выкатился в геймдев. Полет нормальный.
Ящитаю в геймдев три стабильных пути. Ты можешь позволить себе не работать (богат или пассивный доход), ты делаешь это как хобби в свободное от работы время, и ты работаешь за зарплату в геймдев компании. Варианта "быстро склепать и заработать" - нет.
А санкции да, кусаются. Меня и вебдеве они кусали. Пришлось подсуетиться. Ну, без способа обхода санкций в 2к24 остается ровно один вариант, и в вебдеве и в геймдеве - работать на компанию внутри РФ.
>А я как раз пару лет назад из питоно-бекенда выкатился в геймдев
Как так получилось? Геймдев же по сути даунгрейд, по крайней мере с моей колокольни. Что можешь посоветовать покурить дельного?
>Ящитаю в геймдев три стабильных пути
Да так и есть. Просто я решил попытать удачу, но не сказал бы что придерживаюсь "быстро склепать и заработать", мне наоборот кажется если бы клепал говно зарабатывал бы хотяб чето. Я все же за то что бы игра выглядела игрой и игралась как игра, поэтому пытаюсь делать все "качественно", жаль один хуй получается говно.
>работать на компанию внутри РФ
Еп, поэтому и решил начать с яндекса.
По деньгам/стабильности/простоте да, даунгрейд. Крипово смотреть как бывшие коллеги гребут бабло, а ты копейки центы, при этом въебываешь в три раза больше аки человек-оркестр. К счастью могу себе позволить. Прост после десятка лет в вебе заебала его безыдейность, офисность, тупость, нормисовость.
>Что можешь посоветовать покурить дельного?
Как всегда - выбираешь инструмент, читаешь документацию и сразу начинаешь делать, набивать скилл. У нас джанга была плюс пара-тройка мелких фреймворков и легаси кал на пхп. На оф.доках у джанги есть туториалы. Альтернативно по hh.ru посмотри чего сейчас востребовано.
>>59263
Поддержу анонов. Сам работаю больше инженером с серверами и связью. Тоже делаю свой проект в годоте. Долго думал что мне интересно и куда расти. Понял что душа лежит в геймдев. Знаю что лотерея и надежнее идти в бэк, но не хочу. Пусть она никому не будет нужна, но чувствую что идея меня не отпустит пока её не реализую. Пусть криво и косо но надо сделать это. Пилю в свободное от работы и семейных дел время. Хочу выпустить демку-первый уровень а потом посмотреть взлетит или нет. Взлетит - буду искать издателя, если же нет, то успокоюсь что достиг цели и будут идти дальше, может вообще в другом направлении.
648x360, 0:50
>идея была сделать что-то вроде этого
Ладно, идея херня, мне не нравится.
Лучше попробую с NPC что-то сделать.
>Взлетит - буду искать издателя, если же нет, то успокоюсь что достиг цели и будут идти дальше, может вообще в другом направлении.
Это больше из области самореализации чем из области зарабатывания денег. Ты хочешь угодить себе а не игрокам. Хороший подход. Делаешь для себя, и потом уже убираешь все препятствия чтобы передать свой драйв потенциальным фанатам.
Хорошие вопросы для медитации.
- Если бы ты сто процентов знал что игра все-равно провалится. Какой бы ты сделал эту игру.
- Если бы ты точно знал что тебя ждет гарантированный успех. Какой бы ты сделал свою игру.
Эта игра? https://reddit.com/r/godot/comments/nraofa/
Или эта? https://reddit.com/r/godot/comments/1crzs01/
>рисовать мышкой ну такое
1. Рисуй на бумаге карандашом - обводи на ПК.
2. Рисуй чисто векторный арт в Inkscape, в SVG.
>я сделал ставку на геймдев
Это можно делать только когда есть лишние деньги.
>десятков тысяч бычей. Я разве многого прошу?
Шансы выстрелить у рандомных игр минимальны. Заработок на геймдеве требует чётко планировать целевую аудиторию, рекламировать проект во всех соцсетях, поддерживать уже имеющихся фанатов. Геншин импакт, например, особо не выделяется по геймдизайну, но они подготовили свою аудиторию. Рокстаровская ГТА 5 стала бы очередным дешёвым проходняком, если бы не репутация прежних ГТА. Успешные индюки обычно имеют крепкую фанбазу.
>>59271
>за то что бы игра выглядела игрой и игралась как игра, поэтому пытаюсь делать все "качественно"
Это похвально, а игроки у тебя есть? Где ты о своих новых играх кроме двача пишешь? Поддерживаешь обсуждения игроков, помогаешь им? Если хочешь качественные игры, нужно озаботиться поддержкой комьюнити, которое будет/играет в твои игры.
Если ты просто пукаешь игрой в Яндекс.Игры и тупо ждёшь у моря погоды (прибыли), нечего удивляться. Учись у классических браузерных игр - они всегда формировали и поддерживали комьюнити, даже если их игра - синглплеерная весёлая ферма.
>>59325
>из области самореализации
>Ты хочешь угодить себе а не игрокам.
>передать свой драйв потенциальным фанатам.
Было б что передавать. Многие инди-игры создают стойкое впечатление, что автор в них не играл. Т.е. буквально высрал какой-то код и не играл. Как так? Самореализация у них... А игра-то неиграбельная.
>Какой бы ты сделал эту игру.
>Если бы ты знал что игра все-равно провалится.
Если работать в стол, то про свой личный фетиш: то, что больше всего по жизни привлекает лично тебя.
>Если бы ты точно знал что тебя ждет успех.
Успешную игру нужно делать такой, чтобы её легко было поддерживать и дополнять новым контентом, потому что без поддержки/обновлений даже самые успешные игры умирают. Скажем, успех GTA Online держится за счёт ежегодных бесплатных DLC.
Эта игра? https://reddit.com/r/godot/comments/nraofa/
Или эта? https://reddit.com/r/godot/comments/1crzs01/
>рисовать мышкой ну такое
1. Рисуй на бумаге карандашом - обводи на ПК.
2. Рисуй чисто векторный арт в Inkscape, в SVG.
>я сделал ставку на геймдев
Это можно делать только когда есть лишние деньги.
>десятков тысяч бычей. Я разве многого прошу?
Шансы выстрелить у рандомных игр минимальны. Заработок на геймдеве требует чётко планировать целевую аудиторию, рекламировать проект во всех соцсетях, поддерживать уже имеющихся фанатов. Геншин импакт, например, особо не выделяется по геймдизайну, но они подготовили свою аудиторию. Рокстаровская ГТА 5 стала бы очередным дешёвым проходняком, если бы не репутация прежних ГТА. Успешные индюки обычно имеют крепкую фанбазу.
>>59271
>за то что бы игра выглядела игрой и игралась как игра, поэтому пытаюсь делать все "качественно"
Это похвально, а игроки у тебя есть? Где ты о своих новых играх кроме двача пишешь? Поддерживаешь обсуждения игроков, помогаешь им? Если хочешь качественные игры, нужно озаботиться поддержкой комьюнити, которое будет/играет в твои игры.
Если ты просто пукаешь игрой в Яндекс.Игры и тупо ждёшь у моря погоды (прибыли), нечего удивляться. Учись у классических браузерных игр - они всегда формировали и поддерживали комьюнити, даже если их игра - синглплеерная весёлая ферма.
>>59325
>из области самореализации
>Ты хочешь угодить себе а не игрокам.
>передать свой драйв потенциальным фанатам.
Было б что передавать. Многие инди-игры создают стойкое впечатление, что автор в них не играл. Т.е. буквально высрал какой-то код и не играл. Как так? Самореализация у них... А игра-то неиграбельная.
>Какой бы ты сделал эту игру.
>Если бы ты знал что игра все-равно провалится.
Если работать в стол, то про свой личный фетиш: то, что больше всего по жизни привлекает лично тебя.
>Если бы ты точно знал что тебя ждет успех.
Успешную игру нужно делать такой, чтобы её легко было поддерживать и дополнять новым контентом, потому что без поддержки/обновлений даже самые успешные игры умирают. Скажем, успех GTA Online держится за счёт ежегодных бесплатных DLC.
>ИИ для гонок
Гонки разные бывают. Опишу несколько по своим мыслям, попыткам реализации и каким-то постам:
1. Простая гонка по трассе (может быть в городских декорациях, но путь всего один): на пути вейпойнты, неигровые машинки едут по ним. Вот это поможет:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
Геймплейно в гонках по трассе компьютер обычно подстраивается под игрока: если игрок отстаёт, все машинки впереди тормозят, если игрок опережает, отстающие машинки ускоряются (rubberbanding):
https://youtu.be/mv2yJc2Y-Io
Практически не существует гонок без этой фичи.
2. Гонка с произвольным маршрутом: путей просто несколько, машинки выбирают рандомные. Можно использовать AStar: у каждой машинки свои веса вейпойнтов => предпочитают разные маршруты.
3. Demolition Derby: машинки самонаводятся на ближайших либо рандомных противников, и тупо ускоряются до столкновения, затем повторяют.
4. Погони за игроком: машина игрока спавнит новые вейпойнты по ходу движения, и машины противника преследуют по этому пути, либо используется AStar. В ГТА отставшие копы деспавнятся и спавнятся новые, приблизительно по курсу движения игрока.
Отдельно нужно рассмотреть уклонение машин от препятствий: это СЛОЖНО и простыми рейкастами достаточно умный ИИ не сделать. Поэтому в гонках практически не бывает серьёзных препятствий, а машинки чаще всего респавнятся после аварий. За пределами видимости игрока они могут вообще полностью отключать физику и ехать сквозь все препятствия, т.к. игрок этого не заметит.
Да, с помощью рейкастов можно сделать машинку, которая будет ехать примерно по середине замкнутой трассы без вейпойнтов и навигации как таковой, но вейпойнты надёжнее, поскольку абстрагированы от физики уровня и разложены левелдизайнером.
Алгоритм наведения на цель очень прост, там нужен только процент угла между двумя векторами:
https://docs.godotengine.org/en/stable/classes/class_vector3.html#class-vector3-method-dot
Для наземных гонок можно использовать Vector2.
>ИИ для гонок
Гонки разные бывают. Опишу несколько по своим мыслям, попыткам реализации и каким-то постам:
1. Простая гонка по трассе (может быть в городских декорациях, но путь всего один): на пути вейпойнты, неигровые машинки едут по ним. Вот это поможет:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
Геймплейно в гонках по трассе компьютер обычно подстраивается под игрока: если игрок отстаёт, все машинки впереди тормозят, если игрок опережает, отстающие машинки ускоряются (rubberbanding):
https://youtu.be/mv2yJc2Y-Io
Практически не существует гонок без этой фичи.
2. Гонка с произвольным маршрутом: путей просто несколько, машинки выбирают рандомные. Можно использовать AStar: у каждой машинки свои веса вейпойнтов => предпочитают разные маршруты.
3. Demolition Derby: машинки самонаводятся на ближайших либо рандомных противников, и тупо ускоряются до столкновения, затем повторяют.
4. Погони за игроком: машина игрока спавнит новые вейпойнты по ходу движения, и машины противника преследуют по этому пути, либо используется AStar. В ГТА отставшие копы деспавнятся и спавнятся новые, приблизительно по курсу движения игрока.
Отдельно нужно рассмотреть уклонение машин от препятствий: это СЛОЖНО и простыми рейкастами достаточно умный ИИ не сделать. Поэтому в гонках практически не бывает серьёзных препятствий, а машинки чаще всего респавнятся после аварий. За пределами видимости игрока они могут вообще полностью отключать физику и ехать сквозь все препятствия, т.к. игрок этого не заметит.
Да, с помощью рейкастов можно сделать машинку, которая будет ехать примерно по середине замкнутой трассы без вейпойнтов и навигации как таковой, но вейпойнты надёжнее, поскольку абстрагированы от физики уровня и разложены левелдизайнером.
Алгоритм наведения на цель очень прост, там нужен только процент угла между двумя векторами:
https://docs.godotengine.org/en/stable/classes/class_vector3.html#class-vector3-method-dot
Для наземных гонок можно использовать Vector2.
>Да, с помощью рейкастов можно сделать машинку, которая будет ехать примерно по середине замкнутой трассы без вейпойнтов и навигации как таковой
Как понимаю примерно так беспилотные автомобили работают в ирл. Вместо рейкастов Лидар и камеры, ну и плюс гпс.
>беспилотные автомобили
Как я понимаю, там очень много проблем, поэтому технология до сих пор слабо распространена. Нужно анализировать содержимое картинки с камеры, а не просто препятствия детектить. Это требует сложных вычислений, которые в игре мы себе позволить не можем... Но в играх можно использовать множество упрощений - игра заранее знает, что и где находится.
В любом случае, ИИ в гоночках на порядки проще необходимых беспилотным автомобилям систем.
Аноны, привет вам. Геймдевлю в качестве хобби изредка. Последний раз в годоте делал что-либо 2 года назад. Сейчас решил снова сделать что-нибудь, смотрю что стало с годотом.
Поясните за текущее состояние шарпа в годоте. Его поддержка развивается или авторы потихоньку забивают на него?
Я последний раз работал с годотом года два назад еще в третьей версии (как раз когда майкрософт задонатил им бабла на "шарп мне в годоте запили").
Что меня смутило сейчас. В 3-й версии можно было на текущей на тот момент версии .Net-а делать проекты и под десктоп, андроид и под веб. Сейчас же смотрю, под десктоп поддержка .Net6, под андроид .Net7, под ios .Net8, под веб вообще нет (пиздуйте типа на 3-ю версию)
>Currently, projects written in C# cannot be exported to the web platform. To use C# on that platform, consider Godot 3 instead.
Короче какой-то зоопарк. Это теперь насовсем в годоте или все-таки у авторов есть нормальный план развития?
И второй вопрос, в 2Д графике завезли нормальный батчинг для тайловой графики? В 3-й версии там вообще пиздец был.
>состояние шарпа в годоте. Его поддержка развивается
Да, вроде как развивается, но по-прежнему GDScript лучше. Поддержка дотнета была и остаётся третьестепенной задачей, поскольку кодеров на C# исчезающе мало в сообществах Godot, большинство либо начинает и остаётся на GDScript, либо пробует его и переходит на него с C#/других языков. По производительности ты в любом случае ограничен API движка, а самый быстрый код в любом случае будет C++ с перекомпиляцией всего движка (модуль), но большинству игр на Godot не нужно выжимать эти наносекунды. По возможностям языка GDScript имеет всё, что нужно для ООП скриптования игр и даже больше. Вообще не понимаю желание людей связать себя оковами .NET-зависимости, когда можно обойтись без неё.
>какой-то зоопарк
В 4.x много чего переписали. Главным образом - рендеринг с OpenGL на Vulkan, поддержку OpenGL с нуля переписывали, но только 3.3 версии (GLES3). Дотнет прикручивали заново, но не сразу - ждали выхода какой-то новой мажорной версии дотнета, чтоб сразу актуальную версию прикрутить, чем дело кончилось - без понятия. С вебом проблем по-прежнему много, сейчас его опять переделывают, но веб, ИМХО, вообще нинужен, т.к. там никогда ничего полноценно не работает и не заработает уже - скажи спасибо браузерным монополистам, что о так называемой "безопасности" своих пользователей заботятся. Если ты делаешь игру под веб, автоматически умножай доступные тебе ресурсы на 0.1, т.е. даже на мощном ПК будет уровень начала 00-х, а на мобилках в браузере вообще практически ничего не работает, если это не актуальный флагман за 150к (пытался играть в Яндекс.Игры, говно нерабочее даже в Яндекс.Браузере, а тот же itch.io просто в целом говно). Так что это не проблема движка, те же юнити-игры в браузере такое же говно, что и все остальные браузерные игры (если говорить о современных, а не о древних).
>в 2Д графике завезли нормальный батчинг для тайловой графики?
СКАЧАЙ @ ПРОТЕСТИРУЙ, тебе лень zip-архив на 50 МБ распаковать?
Я понимаю, если б ты про юнити спрашивал (10 Гб) или УЕ (20 Гб)...
Да, я в плохом настроении, а что?
>состояние шарпа в годоте. Его поддержка развивается
Да, вроде как развивается, но по-прежнему GDScript лучше. Поддержка дотнета была и остаётся третьестепенной задачей, поскольку кодеров на C# исчезающе мало в сообществах Godot, большинство либо начинает и остаётся на GDScript, либо пробует его и переходит на него с C#/других языков. По производительности ты в любом случае ограничен API движка, а самый быстрый код в любом случае будет C++ с перекомпиляцией всего движка (модуль), но большинству игр на Godot не нужно выжимать эти наносекунды. По возможностям языка GDScript имеет всё, что нужно для ООП скриптования игр и даже больше. Вообще не понимаю желание людей связать себя оковами .NET-зависимости, когда можно обойтись без неё.
>какой-то зоопарк
В 4.x много чего переписали. Главным образом - рендеринг с OpenGL на Vulkan, поддержку OpenGL с нуля переписывали, но только 3.3 версии (GLES3). Дотнет прикручивали заново, но не сразу - ждали выхода какой-то новой мажорной версии дотнета, чтоб сразу актуальную версию прикрутить, чем дело кончилось - без понятия. С вебом проблем по-прежнему много, сейчас его опять переделывают, но веб, ИМХО, вообще нинужен, т.к. там никогда ничего полноценно не работает и не заработает уже - скажи спасибо браузерным монополистам, что о так называемой "безопасности" своих пользователей заботятся. Если ты делаешь игру под веб, автоматически умножай доступные тебе ресурсы на 0.1, т.е. даже на мощном ПК будет уровень начала 00-х, а на мобилках в браузере вообще практически ничего не работает, если это не актуальный флагман за 150к (пытался играть в Яндекс.Игры, говно нерабочее даже в Яндекс.Браузере, а тот же itch.io просто в целом говно). Так что это не проблема движка, те же юнити-игры в браузере такое же говно, что и все остальные браузерные игры (если говорить о современных, а не о древних).
>в 2Д графике завезли нормальный батчинг для тайловой графики?
СКАЧАЙ @ ПРОТЕСТИРУЙ, тебе лень zip-архив на 50 МБ распаковать?
Я понимаю, если б ты про юнити спрашивал (10 Гб) или УЕ (20 Гб)...
Да, я в плохом настроении, а что?
>ли все-таки у авторов есть нормальный план развития?
Какой "план развития" ты ожидаешь от опенсурса?
БОльшая часть работы делается по возможности и теми, кто сам хочет над этим работать. Никто никому не приказывает "а ну иди приделывай дотнет", это вы, сишарперы, пришли откуда-то и ковыряете поддержку зачем-то нужного вам дотнета, хотя из аргументов только что-то из разряда:
>+49.98% скорости в моих бенчмарках, где я числа складываю 100500 раз за кадр
>ой, мне неудобно таб нажимать, лучше писать код сплошным столбиком без отступов.
Какое-то общее направление развития есть (чат разработчиков, где они всё это обсуждают, вроде бы даже доступен публично), но на зряплате сидят считанные единицы, остальные работают бесплатно, скорее всего ради удовольствия, и средств у фонда не так много, как у каких-нибудь юнитеков или эпиков, чтобы разбрасываться на лишние фичи. В движке полно проблем и без дотнета (как и в любом сложном ПО), и их нужно решать срочно, а без дотнета можно обойтись спокойно, т.к. есть встроенный скриптовый язык. Напомню, скриптовые ЯП придумали специально для этого - говнокодить высокоуровневое поведение сложных систем, некритичных к скорости, и даже в древних ААА играх всё держится на скриптах, порой велосипедных и очень не эффективных - зато большая радость для моддеров. Только зумеры внезапно начали дрочить на производительность своей высокоуровневой лапши, будто космический корабль программируют, а не очередной бездушный ассетфлип в стимопомойку, который в любом случае утонет с от силы сотней отзывов.
Всё-всё, ухожу пить успокоительное.
Анон продающий бабушкин шкаф. Возможно тебе будет интересно:
https://kemono.su/patreon/user/17901730
Чел пилит игрушку про девушку которая переезжает в деревню и постепенно решает никогда больше не носить никакой одежды.
Подобрал референс по стилю/дизайну/хзкакэтоназывается для модельки персонажа
https://skfb.ly/oRUOT
>>59427
>продающий бабушкин шкаф.
Там модели бесплатно выставляю. Как накопиться чего показать отдаленно напоминающее игру, прикручу ссылку с донатом.
>>59427
>которая переезжает в деревню и постепенно решает никогда больше не носить никакой одежды
Ну и срань.
> Вспомнил что существует Makehuman и пытаюсь сгенерить ГГ
С мэкхуманом странная тема. Разработчики наотрез отказываются добавлять режим перспективы в камеру, искаропки есть только изометрический режим. На форумах они несут бред о том, что начтоящие скульпторы скульптинга и моделинга работают исключительно в изометрии. Сообщество послушало, покрутило пальцем у виска и запилили неофициальный мод, добавляющий перспективу. Без него в мейкхумане невозможно полноценно работать.
С перспективным модом в МН по референсам вполне реально запиливать кого захочешь.
>>59440
>неофициальный мод
Скачал этот плагин, но почему-то не удается отдалить/приблизить камеру, не реагирует на колесико мыши.
В 3 годоте были декали аддонами - может можно перенести оттуда?
Хуясе я пропустил виток эволюции! Оке теперь буду МПФБ советовать.
Экспорт обновит ссылку на ноду, если ты эту ноду подвигаешь/переименуешь в редакторе. Поиск при ините родителя - тут уже как сам зделоешь.
>поиск при инициализации родителя
Кого искать будешь? Откуда имя возьмёшь?
>выставлением ребёнка ноды через @export
Это нужно, чтобы связи между скриптом и нодами сохранялись в .tscn-файл, а не в твоих скриптах.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html
>In Godot, class members can be exported. This means their value gets saved along with the resource (such as the scene) they're attached to. They will also be available for editing in the property editor. Exporting is done by using the @export annotation.
Зачем мне тратить время на игру для конкурса, если я могу тратить его на свою?
1. Челлендж. Время ограничено 2 неделями, а не как тебе захотелось
2. Можешь получить за это 5000 руб
2. Какой-нибудь ИНФЛЮЕНСЕР решит посмотреть игры с конкурса, станет спонсором твоей игры, найдет издателя, а потом выход в стиме и на пс5
Это все здорово, дерзай. Может отработаешь идею, потом в полную силу игру запилишь.
То ли это только на годоте все такие стеснительные паникеры. То ли вообще на дваче такие девелоперы, девственники.
Да у меня и так игр за жизнь много сделано. Подтягивайтесь.
Очередной затык с блендером. Запекание текстуры занимает по часу, хотя запекание происходит с двух текстур, плюс разделитель в виде нойза вдоль синусоиды. До этого такого не было. Что поменялось - хз. Уже даже хочется положить болт и просто пересобрать текстуру стнеки шейдер нодами прямо в годот.
>пересобрать текстуру стнеки шейдер
Я не понял, но, может, использовать SubViewport?
1. Собираешь пачку текстур.
2. Рендеришь процедурную текстуру.
3. Вставляешь её в материал своих стен.
Преимущество: меньше вычислений на кадр.
Недостаток: больше видеопамяти для текстур.
Идея как превратить твою игру в высокое искусство. Игра не про мелкую пизду, а про женщину в пожилом возрасте.
Пионерка годо-чан, заглядывает в одно из зеркал, и видит там бабку с синими волосами. -рассмотреть поближе-. Камера надвигается. "Что за?". -рассмотреть еще ближе-. Камера показывает от лица пионерки, мы смотрим на бабку в отражении. Двигаем стрелками, двигается бабка. Отводим бабку от зеркала, и камера перескакивает в зазеркалье к бабке. Весь дом, предметы, и надписи отражены. И вообще оказывается что мы перескочили на пол века в будущее. Пионерка в роли бабки с альцгеймером познает современный мир, где все ветхое и засранное. Но можно подойти к чудесному зеркалу порталу и вновь сбежать в уютное детство.
А вот тут он подробно рассказывает как сделать тайлы-модели
https://www.youtube.com/watch?v=JHF3d0M59qs
>>Лучше продолжу думать
>А делать будешь?
Уже много лет пытаюсь что-то сделать, но каждый раз спотыкаюсь о какие-то проблемы, о которых не подумал заранее. Приходится выбрасывать уже сделанное (сцены, код, арт и т.д.) и переделывать с нуля, или совсем выбрасывать идею и выдумывать новую. Перебрал множество способов вести диздок, но не получается тщательно продумать игру. Без продумывания всех деталей можно только совсем тривиальные вещи делать. Десятки папок проектов, сотни выброшенных сцен и скриптов, но ни одной полноценной игры, в которой контента было бы больше, чем на пару минут - потому что без твёрдой стабильной базы контент делать нельзя, а базы у меня пока нет - не продумана. Нейронки не помогают...
A) if object: ...
B) if is_instance_valid(object): ...
C) if object != null: ...
D) if null != object: ...
Очевидно, что А, но с полным пониманием, что А это сахар, в котором под капотом В.
list_of_important_for_me_objects[]
854x480, 1:13
Не шути так.
А что делать после того, как сделал игровые механики для игры мечты? Только сюжет нужен, а его ни в голове, ни в chatGPT нет. Как вообще найти вдохновение? Поиграл в кучу индюшатины, в игры с хбох360 и пс4, в разные игры на пк попробовал, а идей ноль, даже после блек месы.
>>60036
В этом что-то есть.
> Особенно свет от sun источника
Очевидно убери его ну или как минимум отключи ему тени и оче сильно смягчи. Для интерьерной локации нужен камерный свет. Отдельными точками.
Ты охуенен!
>коридорной локации
>sun источника света
Нинужен, выключай.
>сложная навигация по коридорам
Управление на WASD используешь?
Или тебе непривычно в FPS играть?
>Только сюжет нужен
Хорошей игре не нужен.
>в chatGPT нет.
Skill issue.
Вот сюжет уровня GTA:
- опустившийся на дно герой
- хочет начать с чистого листа
- старые связи тянут обратно
- превозмогает изо всех сил
- побеждает всех злодеев
100% гарантия успеха.
>источник света из окна
Время суток меняться будет динамически?
Если нет, тогда вот это попробуй:
https://docs.godotengine.org/en/stable/tutorials/3d/global_illumination/using_lightmap_gi.html
Вообще не парься сейчас о свете и тенях. У тебя геймплея нет, локаций нет, а ты о свете думоешь.
>>60471
>сквозь щели между этажми
Где у тебя там щели? Разве это не один целый меш?
>между этажми
Разобрался, стенки оказались слишком тоники, нужно увеличить толщину в модификаторе Solidify. Но тогда стены слишком толстые. Уберу solidify, сделав стены без толщины, а вокруг, снаружи, построю невидимую литую коробку для отбрасывания тени.
Алсо, запечь свет можно и в Blender. Но для этого всю сцену необходимо собрать в самом Блендере, или экспортировать как gltf из Godot.
>>60481
>источник света из окна
Вообще, если ты делаешь игру в ретро-стиле, то в настолько старых играх с таким светом особо не парились: создавали полупрозрачный "конус света" или "лучи света".
>сделал игровые механики для игры мечты
А что у тебя за механики?
Я бы вот хотел механики для NPC друзей... Как говорится, игры нужны для реализации фантазий, недостижимых в реальности... Но это так сложно.
> Но для этого всю сцену необходимо собрать в самом Блендере
Скорее всего это единственный вариант - собирать по максимуму в блендере. Со светом впереди еще вырисовывается проблема чудовищных просадок фпс от динамический теней, то есть так и так нужно где-то запекать, а так как пк не тянет forward+, придется сопоставлять настройки освещения движка и 3д редактора.
4 омника с тенями - 1 в комнате, 1 на кухне, 1 в ванной, 1 в коридоре. В сумме просаживают фпс до 24 кадров
>4 омника с тенями
Ты уверен, что тебе позарез нужны эти тени? Вот эта полупрозрачная сопля на полу в коридоре как-то не добавляет атмосферы. А тень от персонажа на двери вообще нереалистично чёткая и тёмная. Во всех нормальных играх есть опция для отключения теней, и многие пользуются этой опцией, если у них слабая видеокарта. А в древних играх, на которые ты ориентируешься, таких сложных теней вообще не было...
>просаживают фпс до 24 кадров
Конечно. Потому что у тебя там тысячи треугольников на каждой мелкой фиговинке, сам говорил что у тебя часы на стене над холодильником содержат ~7000 треугольников вместо логичных двух, ведь они мелкие, плоские и далеко от камеры (да и вообще, такие объекты не должны отбрасывать тени). Каждый источник света с тенями рендерит как минимум часть твоей сцены ещё раз. На OpenGL каждый меш требует минимум один вызов отрисовки (draw call), может больше - если содержит несколько материалов. Всё это суммируется в сотни/тысячи вызовов, которые твой видеочип не тянет.
Кроме FPS выводи ещё Performance.RENDER_TOTAL_DRAW_CALLS_IN_FRAME.
Если хочешь сохранить динамические тени, выключи отбрасывание теней у всех лишних объектов (висящих на стенах/стоящих вплотную к стене), особенно мелких (все эти картинки, часы и т.п.). Можно объединить мелкие объекты одним невидимым мешем, отбрасывающим тень как их общий силуэт. Ещё есть вот эта настройка, для оптимизации больших мешей с мелкими деталями:
https://docs.godotengine.org/en/stable/classes/class_arraymesh.html#class-arraymesh-property-shadow-mesh
Нужно сделать примитивный меш, приблизительно похожий по форме на объект. Игрок разницы не заметит, тем более если тени будут размытыми (какими они и должны быть в условиях квартиры). Скажем, у тебя было кресло-каталка - выглядит сложно, но вряд ли ему нужна чёткая тень со всеми дырками. Кто в это будет всматриваться? У тебя же не театр теней.
Вообще, рекомендую пока выключить тени совсем и заниматься наполнением игры геймплеем, историей, локациями и т.п. Пока у тебя не финальные сцены с финальными моделями, возня с тенями будет преждевременной оптимизацией, что в будущем скорее всего потребует многое переделывать. Преждевременно вылизывать графику имеет смысл только если планируешь пораньше пиарить игру в соцсетях, завлекая красивой картинкой. Да и то, чаще всего делают фейковые рендеры из Блендера, а игра на релизе выходит с порезанной графикой, чтобы работала лучше у большинства игроков.
>4 омника с тенями
Ты уверен, что тебе позарез нужны эти тени? Вот эта полупрозрачная сопля на полу в коридоре как-то не добавляет атмосферы. А тень от персонажа на двери вообще нереалистично чёткая и тёмная. Во всех нормальных играх есть опция для отключения теней, и многие пользуются этой опцией, если у них слабая видеокарта. А в древних играх, на которые ты ориентируешься, таких сложных теней вообще не было...
>просаживают фпс до 24 кадров
Конечно. Потому что у тебя там тысячи треугольников на каждой мелкой фиговинке, сам говорил что у тебя часы на стене над холодильником содержат ~7000 треугольников вместо логичных двух, ведь они мелкие, плоские и далеко от камеры (да и вообще, такие объекты не должны отбрасывать тени). Каждый источник света с тенями рендерит как минимум часть твоей сцены ещё раз. На OpenGL каждый меш требует минимум один вызов отрисовки (draw call), может больше - если содержит несколько материалов. Всё это суммируется в сотни/тысячи вызовов, которые твой видеочип не тянет.
Кроме FPS выводи ещё Performance.RENDER_TOTAL_DRAW_CALLS_IN_FRAME.
Если хочешь сохранить динамические тени, выключи отбрасывание теней у всех лишних объектов (висящих на стенах/стоящих вплотную к стене), особенно мелких (все эти картинки, часы и т.п.). Можно объединить мелкие объекты одним невидимым мешем, отбрасывающим тень как их общий силуэт. Ещё есть вот эта настройка, для оптимизации больших мешей с мелкими деталями:
https://docs.godotengine.org/en/stable/classes/class_arraymesh.html#class-arraymesh-property-shadow-mesh
Нужно сделать примитивный меш, приблизительно похожий по форме на объект. Игрок разницы не заметит, тем более если тени будут размытыми (какими они и должны быть в условиях квартиры). Скажем, у тебя было кресло-каталка - выглядит сложно, но вряд ли ему нужна чёткая тень со всеми дырками. Кто в это будет всматриваться? У тебя же не театр теней.
Вообще, рекомендую пока выключить тени совсем и заниматься наполнением игры геймплеем, историей, локациями и т.п. Пока у тебя не финальные сцены с финальными моделями, возня с тенями будет преждевременной оптимизацией, что в будущем скорее всего потребует многое переделывать. Преждевременно вылизывать графику имеет смысл только если планируешь пораньше пиарить игру в соцсетях, завлекая красивой картинкой. Да и то, чаще всего делают фейковые рендеры из Блендера, а игра на релизе выходит с порезанной графикой, чтобы работала лучше у большинства игроков.
>проиграть анимацию задом наперед
Какую страницу из документации ты не осилил прочитать?
https://docs.godotengine.org/en/stable/classes/class_animatedsprite2d.html#class-animatedsprite2d-property-speed-scale
>If set to a negative value, the animation is played in reverse.
https://docs.godotengine.org/en/stable/classes/class_animationplayer.html#class-animationplayer-property-speed-scale
>If set to a negative value, the animation is played in reverse.
https://docs.godotengine.org/en/stable/classes/class_animationnodetimescale.html
>Allows to scale the speed of the animation (or reverse it) in any child AnimationNodes.
https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html#timescale
>Allows scaling the speed of the animation (or reverse it) connected to the in input via the scale parameter.
>Ты уверен, что тебе позарез нужны эти тени?
Да.
>>60560
>Вот эта полупрозрачная сопля на полу в коридоре как-то не добавляет атмосферы
Добавляет.
>>60560
>Потому что у тебя там тысячи треугольников на каждой мелкой фиговинке, сам говорил что у тебя часы на стене над холодильником содержат ~7000
У таких полигональных фиговин, фиговин слишком маленьких чтобы отбрасывать нормальные тени из-за параметра shadow bias, или просто не попадающих в кадр достаточно, тени были отключены сразу.
>4 омника с тенями - 1 в комнате, 1 на кухне, 1 в ванной, 1 в коридоре. В сумме просаживают фпс до 24 кадров
Попробуй так. Запекай все тени от статичных объектов с статичными источниками света. И перенеси их в отдельный слой, в котором они не будут отбрасывать тени но смогут их ловить. А главного персонажа и объекты которые можно двигать, оставь в слое, в котором они смогут отбрасывать тени. Картинка не поменяется никак, но с производительностью должно помочь. Еще можешь некоторые объекты выделить в третий слой, где они будут полу-динамичными. То есть смогут иметь несколько конкретных положений, и ты сможешь переключать для каждого положения готовую запеченную тень. Например если дверь будет открываться без анимации, а будет иметь два положения, закрыто и открыто.
>И перенеси их в отдельный слой, в котором они не будут отбрасывать тени но смогут их ловить.
Хорошая идея. Попробую, спасибо.
> Но для этого всю сцену необходимо собрать в самом Блендере
Как минимум, в блендере нужно расставить ассеты в тех же местах, чтобы потом запечь свет в текстуры, а уже потом текстуры с запечёным светом расставить по ассетам в годоте. Но в целом да, по сути, чем джва раза сцену собирать, проще уж её целиком из блендера впихнуть.
Не спеши с выводами. Я начал пост со слов попробуй.
>>60596
Еще попробуй использовать LODы(дубликаты моделей, с сильно упрощенной геометрией), для теней, вместо оригинальных тяжелых моделей.
Еще попробуй технические проблемы обсуждать с нейронками, скорее всего они выдадут целый букет советов по оптимизациям разного рода, из которых хоть что-то да пригодится.
1280x1024, 0:56
Не понимаю что за тема с тапанием на f.
Мне не нравится жить, всю жизнь тапая на f. Лучше умереть, чем так жить. Но если это только в определенных зонах делать, или в особых режимах. То наверное ОК.
Например эпизоды где герой видит сны, и надо контролировать сердцебиение чтобы он не проснулся, что не очень легко когда сон становится интенсивным. Или для поддержания режима стелс, или например берешь предмет и несешь, потерял сердцебиение, и роняешь-теряешь предмет и надо возвращаться потому что он респавнится на изначальном месте, и надо снова повторить свой путь.
Но скажем ты решаешь что всю игру надо тапать. Тогда я себе представляю такой специфический сценарий. При каждом удачном тапе должен происходить электрический разряд и из персонажа должна вырываться совсем маленькая молния, которая наносит врагам совсем небольшой дополнительный урон. Удачные тапы складываются в комбо, которые усиливают разряд и урон от него. При мощных комбо включается режим адреналин где с неба начинают бить дополнительные настоящие молнии наносящие урон всем врагам на экране. Думаю это было бы достаточно увлекательно чтобы заставить меня тапать более внимательно. Еще автотапы, когда игра сама тапает короткое время, если применить-использовать некий распространенный предмет.
Еще думаю тапы можно сделать не бинарными, а с небольшой шкалой.
Плохо - когда реально далеко тапнул,
нормально - короткая область между плохо и хорошо.
Хорошо - свит спот.
идеально - очень короткая область в самом центре свит спота.
У тебя напряженная игра и по геймплею и по атмосфере. Предлагаю усилить это - таймер в виде ограниченного количества сердцебиений. За таймер ты должен найти и добежать до нового сердца, после чего таймер вернется в исходное положение, допустим 100 ударов, и далее к новому сердцу. Бегай, паникуй, ищи, тапай, спеши.
Бесконечные, тапы будут объяснены лором, наверное. Вкратце, ты искуственно поддерживаешь жизнь, не хочешь сдохнуть - тапай. На данный момент это грубая реализация того что планирую сделать, позже тапы будут синхронизированы со звуком сердцебиения, жмакать в ритм надо будет, и на полосу смотреть не надо, я как раз этим сейчас и занят. Тапы кстати не обязательные, то есть ты можешь спокойно пропускать их и тапать при необходимости, а вот миссы уже влияют на игру.
>Тогда я себе представляю такой специфический сценарий
Это уже про боевку, она у меня по другому реализована будет ибо не вижу смысла перегружать ритмикой.
>Еще думаю тапы можно сделать не бинарными
Они шкалой и сделаны, визуально не менял просто, по факту там достаточно большая зона инпута.
Спасибо за фидбек
Хорошая идея! Взял на заметку. Возможно реализую.
1920x1080, 0:04
Олдскул рогалик, тут риспект, а то заебали со своим экшоном уже
В общем, "tap type game". Но всетаки я считаю что тапы должны быть частью боевки, чтобы усиливать удары и делать комбо. Еще представь такую фишку - два сердца. С разными буквами. Оба сердца могут быть в одном теле, или дополнительные персы. Ритм тапания оставался бы тем же, просто появились бы новые буквы. Типа надо провести двоих песов чере часть уровня. И тебе надо поддерживать сердцебиение для себя и для них обоих. Нажимая то f то g то h в случайном порядке. Каждое непопадание наносит урон соответствующему персу. Если один из них умрет, то можно будет довести второго, и потом вернутся за первым еще раз.
>Поиграл в кучу индюшатины, в игры с хбох360 и пс4, в разные игры на пк попробовал, а идей ноль, даже после блек месы
Сюжеты нужно искать в аниме. В играх сюжет - вторичный продукт, поэтому в них ты вдохновение для сюжета не найдёшь.
> LOD
Есть еще прием отдельных шэдоу кастеров. Когда сами объекты не отбрасывают тени, но делаются дополнительные примитивные, которые не отображаются, а shadow only. В 4ке, вроде при импорте есть такие опции, или сделать вручную
>Есть еще прием отдельных шэдоу кастеров
Я это и имел в виду под LOD-ами для теней. Просто не знаю как этот прием называется. Раньше в играх сами эмулировали тени разными хитростями чтобы выжать из железа все. На словах трудно обьяснить, там создаются приблизительные 2д проекции для каждой части тела, и вытягиваются в 3д обьекты в пару метров длиной, и находятся перпендикулярно от источника света, а там где пересекаются с поверхностью как-бы получается тень. Не очень точная и очень производительная. Знаю что не понятно объяснил, лучше поискать инфу про такие оптимизации или у нейронок спросить.
> Бляя. Впервые скачал игровой движок. Годот.
> Буквально за 10 минут сделал игру которую в ручную писать неделю.
Мои поздравления. Я и сам так же восторгался 6 лет назад.
1280x720, 0:18
>Сюжеты нужно искать в аниме.
Последнее время там почти все сюжеты уровня:
>супер девственник 99 уровня попал в фэнтези VRMMO и стал обычным фермером с грудастой кошкоженой
При том весь этот сюжет умещается в название.
>Мне не нравится жить, всю жизнь тапая на f. Лучше умереть, чем так жить.
Чисто технически, какая-то часть твоей центральной нервной системы постоянно "тапает на F", чтобы поддерживать определённый ритм сердечной системы. Т.е. сердце может биться само по себе, однако ЦНС использует какой-то механизм для ускорения или замедления ритма сердца по необходимости, например, адреналин - это встроенный оверклокинг сердца для усиленного насыщения мышц и нейронов кислородом.
Проблемы со стороны ЦНС могут вызывать сбои в ритмах сердца, и в некоторых случаях вживляют искусственный генератор тактов для сердца, т.е. он генерирует импульсы для сердца вместо ЦНС. Ну, я об этом только в общих чертах читал когда-то давно, так что могу сильно ошибаться, но суть ты понял. Раньше для этого генератора ещё ядерные источники топлива использовали, за счёт медленного распада ядерного топлива батарейки хватало на 10 лет или даже больше. Потом вроде перешли на обычные аккумуляторы.
Я это к чему? Можно обосновать игровую механику тем, что у героя игры сломался этот генератор импульсов и ему теперь приходится сознательно жать на кнопку у себя на груди с регулярными интервалами, чтобы поддерживать ритм сердца. В условном апокалипсисе найти и зарядить аккумулятор проще, чем найти и использовать электронный чип, так что ситуация, в которой тебе приходится вручную жать кнопку вполне правдоподобна. Хотя непонятно, что будет, если герой уснёт, но, допустим, можно оформить игру как один день, за который герой хочет выполнить что-то крайне важное перед неизбежной и скорой смертью.
>>60675
Учитывая всё вышесказанное, я бы рекомендовал вместо QTE зон на полоске сделать так, что от частоты нажатий игрока зависит частота биения сердца персонажа, от которой зависит производительность и персонажа, но слишком большая или слишком маленькая скорость приближают героя к смерти:
- слишком редкие нажатия: кислородная недостаточность, гибель нейронов, смерть;
- средняя частота нажатий: нормальная работа всего организма без урона по здоровью;
- повышенная частота нажатий: усиленная работа мышц и нейронов, т.е. у персонажа повышается скорость движений и скорость реакции, но это повышает износ сердца, что можно обыграть как периодический маленький урон по HP;
- чрезмерная частота нажатий: урон увеличивается экспоненциально, что доходит до мгновенной смерти от разрыва сердца, если нажать 2-3 раза с максимальной скоростью.
Таким образом, тупое нажатие на одну кнопку преобразуется в осмысленный регулятор, пользоваться которым нужно ещё научиться, и который усложняет игру в ситуациях, когда от игрока требуется повышенное внимание к чему-то ещё.
Также рекомендую перенести кнопку сердца на правую часть клавиатуры, чтобы на левой было движение (WASD), а на правой - использование рук. Ну или наоборот. Впрочем, по-хорошему, во всех играх должна быть возможность сменить раскладку.
>Мне не нравится жить, всю жизнь тапая на f. Лучше умереть, чем так жить.
Чисто технически, какая-то часть твоей центральной нервной системы постоянно "тапает на F", чтобы поддерживать определённый ритм сердечной системы. Т.е. сердце может биться само по себе, однако ЦНС использует какой-то механизм для ускорения или замедления ритма сердца по необходимости, например, адреналин - это встроенный оверклокинг сердца для усиленного насыщения мышц и нейронов кислородом.
Проблемы со стороны ЦНС могут вызывать сбои в ритмах сердца, и в некоторых случаях вживляют искусственный генератор тактов для сердца, т.е. он генерирует импульсы для сердца вместо ЦНС. Ну, я об этом только в общих чертах читал когда-то давно, так что могу сильно ошибаться, но суть ты понял. Раньше для этого генератора ещё ядерные источники топлива использовали, за счёт медленного распада ядерного топлива батарейки хватало на 10 лет или даже больше. Потом вроде перешли на обычные аккумуляторы.
Я это к чему? Можно обосновать игровую механику тем, что у героя игры сломался этот генератор импульсов и ему теперь приходится сознательно жать на кнопку у себя на груди с регулярными интервалами, чтобы поддерживать ритм сердца. В условном апокалипсисе найти и зарядить аккумулятор проще, чем найти и использовать электронный чип, так что ситуация, в которой тебе приходится вручную жать кнопку вполне правдоподобна. Хотя непонятно, что будет, если герой уснёт, но, допустим, можно оформить игру как один день, за который герой хочет выполнить что-то крайне важное перед неизбежной и скорой смертью.
>>60675
Учитывая всё вышесказанное, я бы рекомендовал вместо QTE зон на полоске сделать так, что от частоты нажатий игрока зависит частота биения сердца персонажа, от которой зависит производительность и персонажа, но слишком большая или слишком маленькая скорость приближают героя к смерти:
- слишком редкие нажатия: кислородная недостаточность, гибель нейронов, смерть;
- средняя частота нажатий: нормальная работа всего организма без урона по здоровью;
- повышенная частота нажатий: усиленная работа мышц и нейронов, т.е. у персонажа повышается скорость движений и скорость реакции, но это повышает износ сердца, что можно обыграть как периодический маленький урон по HP;
- чрезмерная частота нажатий: урон увеличивается экспоненциально, что доходит до мгновенной смерти от разрыва сердца, если нажать 2-3 раза с максимальной скоростью.
Таким образом, тупое нажатие на одну кнопку преобразуется в осмысленный регулятор, пользоваться которым нужно ещё научиться, и который усложняет игру в ситуациях, когда от игрока требуется повышенное внимание к чему-то ещё.
Также рекомендую перенести кнопку сердца на правую часть клавиатуры, чтобы на левой было движение (WASD), а на правой - использование рук. Ну или наоборот. Впрочем, по-хорошему, во всех играх должна быть возможность сменить раскладку.
Как правильно объяснить, что может/не может NPC в игре?
Брось курить.
1024x768, 0:51
1. Декоративные объекты состоящие из множества меньших нужно полностью собирать в Blender, пример - письменный стол с мелочевкой на нем.
2. Коллизию уровня нужно строить внутри Godot, а не в моделях суфиксом -col/-colonly, по крайней мере в СХ-лайк квесте, где движение и взаимодействие очень ограничено.
3. Каждой модели нужно добавить вручную созданный shadow mesh. Пример - письменный стол упомянутый выше - один литой лоуполи shadow mesh, покрывающий форму поверхности и мелочевки на столе.
> неделю моделит советский шкаф в блендере во всех деталях
> Окей, очень сильно не хватает модульности, нужно переработать.
Может всё таки блокинг на кубах? Как тебе джва треда настоятельно рекомендовали.
>Может всё таки блокинг на кубах?
Нипанимаиш, у него иммерсивный симулятор!!! Как тестировать симуляцию иммерсивности, если у тебя вместо настоящей советской мебели какие-то КУБЫ?
>>61056
>очень сильно не хватает модульности
Ты же панельный дом делаешь? Поищи чертежи всех типовых панелей, которые использовались для таких зданий. Там всё чётко: завод производит панели с определенными параметрами, а строители только соединяют панели, привезённые с завода.
Если отбросить реализм, нужно было чисто на голой геометрии оценить, какие модули тебе будут нужны, прежде чем браться за натягивание текстур краски.
>нужно полностью собирать в Blender, пример - письменный стол с мелочевкой
Это имеет смысл только если ты соединяешь всю мелочёвку в один объект со столом, делая его одним уникальным объектом с запечёнными тенями. Если планируется забирать мелочёвку со стола, тогда тебе придётся делать её отдельно от стола.
>Коллизию уровня нужно строить внутри Godot
Почему? Вряд ли там что-то невероятно сложное, что необходимо заменять простейшими коробками. Хотя, конечно, встроенная физика плохо переваривает всё, что не является простейшей коробкой...
>добавить вручную созданный shadow mesh.
>один литой лоуполи shadow mesh, покрывающий форму поверхности и мелочевки на столе.
Это да, но вручную создавать не обязательно: если ты объединил мелочёвку со столом, то в Блендере можно применить модификатор Remesh и поиграть с его параметрами, чтобы получить ± внешнюю форму:
https://docs.blender.org/manual/en/latest/modeling/modifiers/generate/remesh.html
Попробуй sharp с разной sharpness.
Да хуй там, он не прислушается. Ему это уже второй тред обесняют, что сначала геймплей на кубах, метрики и блокинг, а уж потом графон. Он огрызается в ответ.
мимо
А я смеялся с самогот начала, а когда дошло до гпу, я аж заорал
Меш это ресурс. Он не просто так в инспекторе загружается и жёлтый цвет имеет. Очевидно что МОЖНО и даже НУЖНО, для того их ресурсами и сделали.
>пикрил замечательно выглядит
Согласен - красиво, но там вид с высоты, есть куда побольше разнообразных деталей добавить. Хотя на мой вкус там не хватает мультяшной обводки, без неё многие детали сливаются в цветную кашу.
Если делаешь игру про квартиры, то без текстур уже никак не обойтись, как минимум обои поклеить тебе придётся, иначе будет ощущение лабораторных помещений с чистыми крашенными стенами. Нет, лаборатории - это хорошо, но речь идёт о жилом помещении, в которых порой вообще голые кирпичи оставляют ради визуального разнообразия.
Собственно текстуры вообще изобрели ради этого визуального разнообразия без добавления избытка геометрии в модели. Сегодня видеокарты способны рендерить намного больше полигонов, но возросли и запросы игроков к детализации графики: да, можно обойтись без текстур и иметь кучу деталей, но игрок хочет ещё больше деталей, чем когда-то в прошлом.
Вспоминается противостояние "полигоны vs воксели". Воксельная графика изобретена чуть ли не раньше полигональной, но видеокарты оптимизировали под отображение полигональной, потому что воксельная требовательна не только к скорости, но и к памяти. И полигоны дают добавлять кучу деталей текстурами, а воксели не имеют деталей меньше одного вокселя (не рассматриваем блочную графику а-ля Майнкрафт). И поэтому полигоны победили: у них детализация выше с меньшими затратами ресурсов.
Так что без текстур можно обойтись только если тебя привлекает картинка с низким числом деталей, или если ты можешь себе позволить лишнюю геометрию.
>>61136
>ебли с развёртками
Никогда не испытывал проблем с UV-развёрткой, там вроде бы всё интуитивно. Или ты про фотореализм?
>Так что без текстур можно обойтись только если тебя привлекает картинка с низким числом деталей, или если ты можешь себе позволить лишнюю геометрию.
Не соглашусь. Лоу поли без текстур позволяет натыкать дохуя деталей, причем большинство - простые блоки, которые можно прямо в годоте нахуячивать. И геометрия как следствие простая, полигонов мало, рендер быстрый. Более того, ты можешь брать одну и ту же меш, перекрашивать ее, скалировать не юниформно и по-всякому издеваться, и это выглядит ок.
Бля, спасибо, но это не много не то что мне нужно, но ты мне идею ебейшую подал, как это сделать потому премного благодарен
>mesh = load()
Не рекомендую, лучше использовать preload() - тогда искомый меш загружается на загрузке сцены и будет удерживаться в памяти, пока вся сцена в игре.
Ну или так, в начале скрипта:
>var meshes: Array[Mesh] = [load(), load(), load(), ...]
Тогда все меши будут заранее готовы.
>>61139
>один объект на другой моментально заменить
>просто меш на меш из папки сменить
А ты уверен, что кроме меша ничего не меняется? Как минимум физическим объектам может потребоваться заменить коллизию. А если у объектов разные фичи, придётся заменять скрипты/параметры...
Рекомендую сначала всё сделать на сценах. Только потом, если окажется необходимо, оптимизировать конструкцию объектов, заменяя сцены на ресурсы. Возможно, в процессе развития игры тебе захочется заменять намного больше, чем просто меш, и тогда придётся переделывать с ресурсов на сцены.
я уже придумал шизо-идею ща наведу красоту
>Лоу поли без текстур позволяет натыкать
С лоуполи далеко не уедешь, если хочешь реализм. Вопрос стиля графики зависит от атмосферы игры.
>это выглядит ок
У тебя примеры из чего-то вроде гиперказуалки, где квартира чисто фоном и геймплей вообще не о ней.
Представь ту же графику от первого/третьего лица.
Короче, вкусовщина же, повторюсь:
>только если тебя привлекает [такая] картинка
Не знаю как другие, я скажу чего мне не хватает для именсирвности. Шорты странновато выглядят. Было бы круто снять с нее шорты чтобы в трусиках ходила. И иметь возможность выбирать разные текстуры трусиков из меню. Типа как в нид фор спиид, камера приближается к бамперу, и ты выбираешь раскраску, и можешь крутить камеру чтобы посмотреть со всех сторон как сидят. Помещения в видео похоже как буд-то она гуляет по пустому зданию школы после уроков или в летние каникулы. Ищет ключи от подвала, они закрыты в шкафчике учителя физкультуры, в душевой.
>Типа как в нид фор спиид, камера приближается к бамперу, и ты выбираешь раскраску, и можешь крутить камеру чтобы посмотреть со всех сторон как сидят.
Вот это я понимаю, геймдизайн. Ото здешние кодзимы все какие-то сопли на кулак наматывают.
При каждом прохождении в квартирах будут генерироваться случайные журналы мод, каждый из которых добавит в коллекцию тюнинга трусов новые элементы.
Он говорил, что это временная моделька.
>Шорты странновато выглядят. Было бы круто снять с нее шорты чтобы в трусиках ходила.
У неё нет трусов, её шорты - часть тела.
>И иметь возможность выбирать разные текстуры трусиков из меню.
Видел довольно много игр, позволяющих выбрать трусики для героини... Но эту фичу нужно делать строго после всего остального, если, конечно, ты делаешь не симулятор единственной тянки.
>коллекцию тюнинга трусов
Тогда уж лучше делать трусы главным героем...
Oh wait...
https://store.steampowered.com/app/562410/
>Panty Party — это увлекательная и быстрая боевая игра. Порхайте в облике трусиков по улицам и между зданиями. Отыщите вражеские панцу и выбейте из них всё [дерьмо]!
>Очень положительные (91% из 866)
Ничего, ещё есть шанс сделать Гигахрущ про трусы.
>Очень положительные (91% из 866)
> Земля дегенератами
> Земля дегенератами
> Земля дегенератами полна
>сам меш главный узел другой сцены
Скорее всего, у тебя проблема в композиции сцен.
Меши не должны быть предками каких-то других, существенных для геймплея нод, например:
- Какое-то модульное тело: RigidBody3D (сцена)
- - Контроллер тела: Node
- - Что-то ещё тела: ...
- - Модуль: CollisionShape3D (отдельная сцена)
- - - Визуал модуля: MeshInstance3D
- - - - Визуал2 модуля: MeshInstance3D
- - - Спецэффекты модуля: ...
- - - Что-то ещё модуля: ...
- - Модуль2: ...
- - Модуль3: ...
Если ты меняешь модуль, ты меняешь весь кусочек сцены с кучей связанных нод, не отдельные ресурсы конкретных нод. Это позволяет быстро, решительно слепить прототип игровых механик. Уже потом, если получится интересная игра, можно позаботиться об оптимизации, скажем, менять меши на трансформы мультимеша или вообще на серверы перейти.
Я так пишу, потому что механизм замены меша сам по себе тривиален и любой разбирающийся в движке это знает. Значит, с таким вопросом ты скорее всего новичок и играбельной игры у тебя пока нет. Вот иди сделай что-то играбельное для начала.
>переделывателей
Игра была фактически готова в 2004, прототип .gba можно в интернете скачать и он вполне играбелен.
>But for the next two years, the pals worked extremely hard to develop Kien, taking very few breaks and crunching a lot. After a few years of development, the game was finished and ready to be published. However, the high costs of shipping the game on Game Boy carts and the risk that Kien might not be successful led to no publisher wanting to release the game.
>Eventually, only one member of the original development team remained: game designer Fabio Belsanti. Despite believing in the unpublished game, he moved on with his life, founded a new development company, and began creating educational games for kids and teens. Through it all, though, Belsanti never gave up hope for Kien. When he noticed recently that retro games and consoles were popular again, he decided to return to Kien and give it another chance.
>Belsanti teamed up with Incube8, a publisher focused on releasing and supporting new games for classic consoles, like the GBA.
TL;DR: игру сделали за 2 года в 2002-2004, но ни один издатель не решился издавать, команда распалась и игрушка пылилась у геймдизайнера 20 лет без дела, пока не начался тренд на ретро и нашёлся издатель, готовый штамповать физические картриджи.
По итогу это просто маркетинговый трюк. Этот Fabio Belsanti кинул братков, срубив бабла на ностальгии и поводе для громких заголовков в СМИ. Никто над игрой 22 года не работал, она просто пылилась.
>У неё нет трусов, её шорты - часть тела.
Я в этом и не сомневался. Но автор и так много времени проводит в блендере, пытаясь добиться максимального погружения от хрущевки. А так эффект погружения сразу бы удвоился или даже утроился. Отпала бы необходимость создавать сравнимый уровень погружения с помощью множества источников света. И можно было бы перейти к более важным вещам. Например оставлю свои идеи насчет имерсивного геймплея при себе чтобы не плодить лишних дискуссий. Надеюсь автор сконцентрирует пока свое внимание на трусиках.
>>61156
>строго после
Я не согласен. Ранние этапы разработки, не означают что нужно пялится в унылую картинку, это врезается в сознание и ужасно демотивирует. Небольшие но приятные улучшения, для души, могут оказаться хорошим стимулом почаще запускать годот, чтобы окунуться в разработку игру своей мечты. Сменяемые трусики не дадут заскучаать.
>>61154
Я представил себе обычные трусики старшекласницы, или студетки. С разными текстурами. Добавлять в игру трусы всех народов мира может оказаться довольно энергозатратно. И выхлом может не оправдать вложенного труда. Но конечно, добавить несколько вариантов с разным разрезом на попе, почему бы и нет.
>>61163
Если честно, единственно что кажется гениальным из представленного в твоих скриншотах, это то что поверженные трусики остаются лежать брошенными на земле. Персонификация трусов это больше шутка которую растянули на целую игру.
>>61172
>>61176
Сложно оценить игру по описанию. Там может быть хороший юмор и слаженная боевка. А шокирующий концепт мог быть выбран для привлечения внимания.
>Добавлять в игру трусы всех народов мира может оказаться довольно энергозатратно.
Ну давай поможем, скинемся всем двачем фотографиями своих трусов.
>можно было бы перейти к более важным вещам.
>сконцентрирует пока свое внимание на трусиках.
Эх, вот если б он так симулятор секса делал... Там и трусики имели бы смысл, и окружение не так важно.
>пялится в унылую картинку, это врезается в сознание и ужасно демотивирует
Ага, он вроде докладывал о своей депрессивности.
>Небольшие но приятные улучшения, для души, могут оказаться хорошим стимулом почаще запускать годот, чтобы окунуться в разработку игру своей мечты.
Тут согласен, но:
>Сменяемые трусики не дадут заскучаать.
Нужно геймплей сделать, и трусики не понадобятся.
>Персонификация трусов это больше шутка которую растянули на целую игру.
А что ты хотел? Всё гениальное - просто. В Японии очень распространён фетиш на трусики, даже есть торговые автоматы с грязными или ношенными.
Так что в каком-то смысле это порно-игра. Просто порнография не мейнстримная, для узкой аудитории.
>шокирующий концепт
Не понял, что там шокирующего? Трусы как трусы.
Говорю ж, вы просто не люди культуры. Человека культуры трусиками не удивить и не напугать, но положительный отзыв он непременно оставит.
>стимулом почаще запускать
>трусики не дадут заскучать.
Мой геймплей требует смотреть под юбку, а я в очередной раз приуныл и всё это забросил...
Какие мне советы дашь? Добавить лифчик?
А теперь че по прогрессу, да нихуя его нету. После залития демки сидел несколько часов разбирался как синхронизировать тапы под ритм, понял что слишком дохуя времени потрачу на это поэтому забил и сделал топорно. Из последнего что сделал: добавил деш, дабл джамп, анимации атаки, собсно и атаку добавил, трейл деша/атаки сделал, начал работать над системой линейных квестов, намутил телепорты, нарисовал и добавил пару мобов, нарисовал несколько объектов, анимировал много чего, а самое главное навалил звука, теперь по кайфу тупо бегать даже по пустой локе. Осталось теперь с геймплеем разобрать, неделя ещё есть благо, надеюсь уложиться.
А знаешь что самое хуевое анон? Я изначально хуй ложил на код дабы побыстрее склепать визуально и технически рабочее чтоб начать от чего то отталкиваться, так что внутри лютейший говнокод в котором черт ногу сломит, рефакторить времени уже нихуя нету, слишком много всего, так что приходится дальше говнокодить, благо что все читабельное хотяб.
Некст шаги: левелдизайн, рисовать, анимировать, и ещё рисовать.
Работы короче выше крыши.
анон с демкой на твг выше по треду
>Нужно геймплей сделать, и трусики не понадобятся.
Ложная дихотомия. Трусики и геймплей гармонично дополняют друг друга.
>>61253
>смотреть под юбку
Убери юбку.
>Добавить лифчик?
Кошачьи ушки и хвост.
https://www.youtube.com/watch?v=wk7bNlVyYt4
>>61267
Бедный godot тред. Нужно больше внимания и поддержки выказывать анонам которые хоть какой-то свой прогресс выкладывают сюда. И нужно больше хороших godot проектов, чтобы треды с другими движками воспринимали нас всерьез.
Пофиксил, проблема с пакованой сценой была. Ради интереса сцену в блокноте открыл, и убрал пакованые сцены и экспертов.
>системой линейных квестов
ИМХО Для демки сделай всего два-три сочных квеста, включающих разные механники. Двойной прыжок и дэш, открывай по ходу игры, а не давай сразу. Например место где спавнится герой. На лево можно идти а на право надо двойной прыжок. Идешь влево недолго и получаешь двойной прыжок. Если вернутся и перепрыгнуть, найдешь уникальный предмет или другой бонус. А еще дальше на право уже нужен двойной прыжок + дэш чтобы допрыгнуть. Поставь персонажа который бы это объяснил игроку. Я это все к тому чтобы у игрока появлялась сразу перспектива для роста.
Сделай нпк который дает доступ к арене, где идут волны противников, пока не умрешь. С арены, получаешь прокачку и ставишь рекорды которые сохраняются. Так как демка короткая, спрячь куда-нибудь черта, очень сильного. Специально для тех кто решит задрочится на арене. Чтобы можно было использовать прокачку для убийства этого черта.
Панцушоты не подойдут серьёзной игре.
>Убери юбку.
Ха-ха, как смешно.
>Кошачьи ушки и хвост.
Думал об этом, но мотивация иссякла.
>Mixamo
Не хочу анимации людей, хочу мультяшек...
>Бедный godot тред.
Всё нормально с тредом, смешно же.
>чтобы воспринимали нас всерьез.
Зачем? Мы весёлые, шутливые, с нами хорошо.
А в других тредах какие-то злобные корпораты.
>похерилась ворлд сцена
>переделать проблем нету
На такой случай я бэкапы делаю. В идеале нужно репозиторий создавать, там, говорят, всё круто...
>Из последнего что сделал
>Осталось теперь с геймплеем разобрать
Мне кажется, для джема ты слишком много лишних механик накрутил, тогда как геймплея толком нет. Я думаю, побеждают те, кто делает упор на одну фичу, потому что могут посвятить ей всё время конкурса.
Вот, скажем, у SUPERHOT версия с джема была совсем минимальной, чисто пыщ-пыщ. Но автор(ы) продумали механику замедления времени и игра выстрелила. Уже после джема добавили кучу всего и сюжет какой-то. Соотношение 7 дней джема и 2 года доделывания.
Но я, если что, в джемах никогда не участвовал...
>рисовать, анимировать, и ещё рисовать.
ИМХО, рисование слишком много времени отнимает, поэтому необходимо выбрать простейший стиль, в котором ты можешь быстрее всего работать.
>>61306
Это всё хорошо, но успеет ли он за неделю? Хуже отсутствия контента только баги, ломающие игру.
Потом, насколько я понял, искусственно растягивать время для прохождения не стоит, т.к. оценивающий может бросить до того, как откроет весь контент. Особенно учитывая тему "нонстоп": игры будут бесконечными, определить "прохождение" нельзя.
Preload криво работает, надоело возиться, перешел на Load
>Кто-то из местных переделывателей кнопок под мультиплеер архитектуру?
Слабаки! У них в игре даже одной мультиплеерной архитектуры нет. А в моей игре будет несколько мультиплеерных архитектур. Пруф на пикриле.
Ну тащемто я так и планировал постепенно открывать игроку возможности по мере прохождения.
>>61367
На каждый пук в сцене мне лично впадлу бекап делать, но навсякий уже сделал один.
>Мне кажется, для джема ты слишком много лишних механик накрути
Всмысле, это дефолтные механики для того что бы игра игралась. Мне лично не по кайфу управлять болванчиком который бегает и прыгает только, ещё и имеет на это одну анимацию.
>рисование слишком много времени отнимает,
Есть такое, но это оправдано. Чем живее выглядит мир, тем приятнее играть, даже если геймплея как такого и нету.
>мне лично впадлу бекап делать
Настроил WinRAR так, чтобы создавались архивы с названием "проект-дата-время", исключая некоторые лишние папки и файлы (.godot, .png, .gltf и т.п.). Вынес шорткат в выпадающее меню, так что бэкап сделать можно за секунды. Делаю бэкап раз в день, когда отвлекаюсь от проекта на несколько часов, когда собираюсь сделать радикальные изменения.
Понимаю, гит функциональнее, но я такие бекапы уже несколько лет делаю, так что переучиваться лень...
>болванчиком который бегает и прыгает только
Если основная механика не связана с платформингом, тогда зачем все эти трюки? У тебя вроде как смысл в бесконечном нажатии на F, а не в трюках персонажа. Следовательно, нужно отточить механику "сердца".
>Чем живее выглядит мир, тем приятнее играть, даже если геймплея как такого и нету.
Технически сделать затягивающий надолго геймплей проще, чем нарисовать затягивающий надолго мир. И конкурс вроде бы разрешает брать бесплатные паки ресурсов, так что можно взять готовые тайлсеты. А кроме того, плохой геймплей/баги доставляют игроку больше неудобств, чем некрасивая/кривая графика.
Но если ты крутой художник и планируешь сразить всех уникальным артом, тогда никаких проблем.
Моды для мультиплеерной кнопки - база.
>У тебя вроде как смысл в бесконечном нажатии на F
С чего ты взял? Я такого не говорил. Это скорее геймплейная условность обусловленая сюжетом, и ни в коем случае не кор механика. Хотя я понимаю с чего ты так решил, на шебме и вправду нихуя нету кроме тапанья.
>Технически сделать затягивающий надолго геймплей проще, чем нарисовать затягивающий надолго мир.
Возможно. Но геймплей без картинки хуже, нежели чем баланс и того и того. Золотая середина должна быть.
>И конкурс вроде бы разрешает брать бесплатные паки ресурсов
Я противник ассетов, и нейронок тоже. Был бы я оргом, запрещал бы нахуй все это ибо какой смысл тогда в твг, лутануть денег, и то если повезет? Хотя твг наверное больше про фо фан, нежели про поиск идей и показ скиллов, поэтому.
>Но если ты крутой художник и планируешь сразить всех уникальным артом, тогда никаких проблем.
Было бы неплохо если бы я был им. Сам же видишь мой скилл, о крутых артах можно забыть. Поэтому сделаю ставку на атмосферу.
Поспал 3 часика, опять выспаться нихуя не могу, прям как тогда когда пилил первую браузерку. Счастья буду левел дизигнить.
> >Mixamo
> Не хочу анимации людей, хочу мультяшек...
Туда можно свою модель загрузить толстожопку-раскорячку и после нескольких настроек все тамошние анимации откалибруются под твою модель.
Но это всё хуйня, потому что как мне сорока на хвосте принесла, миксамо заброшен, проект помер, новых анимаций нет, старые не везде подходят.
Тебя поймаю и к стулу привяжу.
Я разобрался, что путь к ним лежит через sprite_name.material.set("shader_parameter/amplitutde" ... - а дальше что?
Спс!
>В Японии очень распространён фетиш
Основывать свои проекты на распространённых в Японии фетишах, это правило хорошего тона.
https://www.youtube.com/watch?v=eeyDoE26aGI&t=215s
Улавливаю. О том и речь.
Интересно можно ли распознавание речи в андройде как-то адаптировать, чтобы наговаривать GDScript? Видимо придется интенсивно использовать нейронки, чтобы они писали код, и я только его вставлял с небольшими правками. Жаль разрабы движка выбросили в окно визуальное программирование. Для тача было бы очень кстати.
> Для тача было бы очень кстати.
Для тача там весь интерфейс следует переделывать с нуля. Дефолтный интерфейс пригоден максимум для планшета, но не для мобилы. Тут нужно отдельными панелями на весь экран выводить каждый отдельный элемент. И меню сверху, чтобы переключаться между окнами. Ну например, как дашчан двача: есть галерея со всеми тредами и по тапу на иконку ты открываешь тред отдельным полноэкранным видом. Свайп вправо открывает список открытых видов. И т.д.
>визуальное программирование. Для тача было бы очень кстати.
Звучит как отличная идея для плугина.
Ну привет
Да всем поебать. Главное геймплей интересный, а не циферки на планировках. А ностальгирующие игроки и по нулевым поностальгируют не хуже чем по девяностым.
Играюсь с годот в телефоне на андройд. Пытаюсь пройти вот этот туториал: https://www.youtube.com/watch?v=LOhfqjmasi0
Из особенностей.
Чтобы добавить свои текстуры и ассеты, надо найти папку своего проекта в папке /Documents/ андройда. И закинуть ассеты туда.
Если без физической клавиатуры, то рекомендую Unexpected Keyboard. https://play.google.com/store/apps/details?id=juloo.keyboard2&hl=en_US . Чтобы зажимать ctrl и tab в коде.
Охват камеры неправильно отображается в редакторе. Видимо неправильно определяется соотношение сторон экрана телефона.
Вместо физических кнопок, чтобы двигать персонажа. Добавил наэкранные тач кнопки. С пустой прозрачной текстурой и текстовыми смайликами в виде рук указывающих направление движения.
Но что-то пошло не так. Тач кнопки привязаны не к конечным движениям камеры, а к ее формальному местоположению, до приминения ограничений и сглаживания.
> Как сделать чтобы тач кнопки были зафиксированы на экране.
Отдельный CanvasLayer обернуть в.
Да пребудет со всеми нами сила годота, возлюбленный брат Феодосий. Ибо благословенны ноды его. И спагети скрипты его тянутся по злачным пастбищам...
>>И спагети скрипты
>Воу-воу
Ды. Мы тут кнопку под несколько мультиплеерных архитектур переписываем вообще-то. Это вам не спагетти какое-то, а натуральная, отварная лапша.
Щас ты идёшь на любую энциклопедию, изучаешь матчасть по спагетти-коду, осознаёшь какой хуйни насрал в тред, возвращаешься и извиняешься. И МЫ ТЕБЯ ПРОСТИМ! ГОДОТРЕД ЖЕ!
Спасибо. Сработало. Хотя я в начале не мог найти свои кнопки. Потом понял что надо переместить в правый нижний квадрант относительно оси ху, и увеличить в четыре раза. Причем на ощупь, не имея понятия как оно будет выглядеть. Странный экспириенс. Но получилось.
>Установил годот в телефон.
Мой опыт несколько месяцев назад:
- GUI слишком мелкий (6.4 дюйма);
- Vulkan глючит, работает только GLES3;
- редактор кода плохо дружит с Gboard;
- жрёт батарейку за 2 ч (в браузере 12 ч).
Итог: нинужно, лучше потерпеть до компа.
>>61717
>интерфейс следует переделывать с нуля.
Согласен, нужен отдельный мобильный GUI.
>>61718
>даже простой код не могу писать на мобиле.
Skill issue или у тебя телефон 3 дюйма из 00-х? Щас мобильные виртуальные клавиатуры такие, что чуть ли не удобнее физической, когда привыкаешь. Хотя, на физической у меня всё же скорость набора выше.
>>визуальное программирование.
>Его нигде нет нормального.
Предметно-ориентированный язык может быть чрезвычайно удобным в визуальном плане. Ты же не будешь спорить, что тебе удобнее набирать .tscn в текстовом виде, а не двигать ноды в редакторе?
Нужно просто понимать, ЗАЧЕМ тебе визуальное представление кода на каком-то языке. Чтобы что? Отобразить взаимосвязи в коде? Ветвление кода?
>>61727
>школьники хуячат код прямо на мобиле
Обижаешь. Я уже давно не школьник, но до сих пор предпочитаю что-нибудь напечатать с кровати, чем садиться за компьютер. С ноутбуком лежать не так удобно, как с телефоном, вентиляторы забиваются.
>Так что годот в этом плане идет куда надо.
В текущем виде Godot не подходит смартфонам.
>Установил годот в телефон.
Мой опыт несколько месяцев назад:
- GUI слишком мелкий (6.4 дюйма);
- Vulkan глючит, работает только GLES3;
- редактор кода плохо дружит с Gboard;
- жрёт батарейку за 2 ч (в браузере 12 ч).
Итог: нинужно, лучше потерпеть до компа.
>>61717
>интерфейс следует переделывать с нуля.
Согласен, нужен отдельный мобильный GUI.
>>61718
>даже простой код не могу писать на мобиле.
Skill issue или у тебя телефон 3 дюйма из 00-х? Щас мобильные виртуальные клавиатуры такие, что чуть ли не удобнее физической, когда привыкаешь. Хотя, на физической у меня всё же скорость набора выше.
>>визуальное программирование.
>Его нигде нет нормального.
Предметно-ориентированный язык может быть чрезвычайно удобным в визуальном плане. Ты же не будешь спорить, что тебе удобнее набирать .tscn в текстовом виде, а не двигать ноды в редакторе?
Нужно просто понимать, ЗАЧЕМ тебе визуальное представление кода на каком-то языке. Чтобы что? Отобразить взаимосвязи в коде? Ветвление кода?
>>61727
>школьники хуячат код прямо на мобиле
Обижаешь. Я уже давно не школьник, но до сих пор предпочитаю что-нибудь напечатать с кровати, чем садиться за компьютер. С ноутбуком лежать не так удобно, как с телефоном, вентиляторы забиваются.
>Так что годот в этом плане идет куда надо.
В текущем виде Godot не подходит смартфонам.
>геймплейно получается интересный лабиринт
Где ты там лабиринт нашёл? Пикрил - все пути этажа.
>началась в нулевых, а у меня начало-середина 90х
Да пофиг вообще, скажешь "игровая условность".
Главное - передать атмосферу, а не факты.
>Где ты там лабиринт нашёл?
На одном из этажей одна двушка будет объединена с однушкой в четырешку, некоторые переходы будут через балкон/окно (одна из квартир принадлежит монтажнику, где можно найти снаряжение).
>правый нижний квадрант относительно оси ху
>Причем на ощупь, не имея понятия
1. Создай отдельную сцену ТОЛЬКО с кнопками:
- TouchUI: CanvasLayer
- - MoveLeft: TouchScreenButton
- - MoveRight: TouchScreenButton
- - Jump: TouchScreenButton
2. Видишь: рамка экрана¹ справа внизу от (0; 0).
3. Двигаешь кнопки относительно этой рамки.
4. Вставляешь эту сцену в основную сцену игры.
5. ???
6. Всё работает как надо и понятно.
¹: Рамка экрана повторяет размеры окна из настроек проекта, так что на твоём экране всё растянется. Тут проблема в том, что, в отличие от Control-нод, Node2D никак не адаптируется под размер/пропорции окна.
Если делаешь игру чисто для себя, достаточно в настройках проекта установить размер окна, равный разрешению экрана твоего устройства. Но для релиза требуется учитывать разные пропорции экранов. Для этого можно использовать структуру типа такой:
- CanvasLayer
- - MoveLeftC: Control
- - MoveRightC: Control
- - JumpC: Control
- - ... # тачскрин кнопки
И дальше нужно написать код, перемещающий Node2D-кнопки в места Control-нод на экране.
Другого способа не знаю. Нужно протестировать...
>На одном из этажей...
Если свободно менять планировку как вздумается - конечно, можно создать лабиринты на любой вкус. Однако речь шла о стандартной планировке, нет?
Стандартная планировка вообще не лабиринт:
- лифты/лестница
- - квартира 1
- - - комната 1
- - - комната 2
- - квартира 2
- - - комната 1
- - - комната 2
В чём же тут лабиринтовость?
По определению:
>Лабиринт — структура, состоящая из запутанных путей к выходу (и/или путей, ведущих в тупик).
А тут просто идёшь к общей лестнице.
Другое дело, если в стенах дырки, а дверях завалы.
Банальный вопрос тащемто.
1. Фокусируйся на своих киллер-фичах.
2. Сделой графику простой, но стильной.
3. Развивай комьюнити вокруг своей игры.
4. Обновляй и дорабатывай свою игру.
СМОТРИТЕ ЧЁ НАШЕЛ, НРАВЯТСЯ ТАКИЕ БАШНИ
@
НО, БЛИН, ТАКИЕ ДОМА СТРОИЛИ В НАЧАЛЕ 00-Х, А У МЕНЯ НОСТАЛЬГИЧЕСКАЯ ИГРА ПРО КОНЕЦ 90-Х
@
ЗАТО ПЛАНИРОВКА ЛАБИРИНТООБРАЗНАЯ, ОЧЕНЬ ЛЕГКО ЗАБЛУДИТЬСЯ В ПРЕДЕЛАХ ОДНОГО ЭТАЖА
@
НУ ТО ЕСТЬ ЕСЛИ ДВЕРИ В ЛЮБЫХ МЕСТАХ УСТАНАВЛИВАТЬ, ТОГДА ПРЯМО ЛАБИРИНТ
Итс бьютифул энд эвокатив. Тэнк ю.
В игрострое звёзды ближе,
Где Хуан учит нас летать.
Каждый шаг - это приключение,
Где сердца бьют в унисон с ветром.
В этом мире нет пределов,
Где фантазия - наш компас.
Мы готовы к новым открытиям,
Где каждый день - это праздник.
Хуан улыбается нам,
Когда мы делаем первый шаг.
В его глазах - наша победа,
Когда мы учимся не бояться.
А игры-то делать будем?
Расскажу как делаю я. Мой опыт с 3-ки, но в 4-ке делаю так же.
- CanvasLayer
-- RootControl (обычный Control) с anchor-якорем поставленным на full rect. Емнип ему надо поставить Mouse - Filter - Ignore чтобы он не сжирал тачи, предназначенные всему игровому экрану.
--- Кнопки, которые сначала расставлены по нужным углам через anchors, и потом подвинуты на какое-то расстояние.
Дальше, поскольку у меня сридээ игра, в проекте стоит window - stretch mode - viewport + expand. Это дает мне кнопки, пропорционально растягивающиеся, и в 3д нет черных полос по сторонам.
Сетап простой, ошибиться вроде сложно.
Второй вариант, который возможно подойдет каким-то 2д играм типа викторин. Это stretch mode - disabled + viewport. Он не скалирует кнопки, только сдвигает, поэтому могут получиться наложения.
>Кнопки
У нас два стула. Либо кнопки, курсором точёные:
https://docs.godotengine.org/en/stable/classes/class_button.html
>Note: Buttons do not interpret touch input and therefore don't support multitouch, since mouse emulation can only press one button at a given time. Use TouchScreenButton for buttons that trigger gameplay movement or actions.
Либо мультитач, множеством пальцев дрочёный:
https://docs.godotengine.org/en/stable/classes/class_touchscreenbutton.html
>This node inherits from Node2D. Unlike with Control nodes, you cannot set anchors on it. If you want to create menus or user interfaces, you may want to use Button nodes instead. To make button nodes react to touch events, you can enable the Emulate Mouse option in the Project Settings.
Нет ты!
Конечно это больше игрушка. Но должны же быть какие-то задачи которые он не плохо выполняет. Ну или по крайней мере смог бы выполнить если сдобрить процесс толковыми плагинами. Все-таки под капотом там полноценный годот.
GUI никто менять не будет. Андройд версия, это сторонний проект. Цель не мобилки, а хромбуки с поддержкой андройд приложений, компьютеры на андройде, и планшеты.
>>61996
>жрёт батарейку за 2 ч
3Д? Чисто ковыряние в интефейсе, или с запуском игровых сцен?
>Чисто ковыряние в интефейсе
Не знаю, не помню. Но GUI в Godot достаточно тяжёл для рендеринга по сравнению с нативным софтом. Особенно это касается Godot Editor. У меня даже на компьютере редактор не так быстро работает из-за огромного количества элементов в инспекторе нод.
>задачи которые он не плохо выполняет
Чисто запуск проекта без установки отдельного APK - замечательная фича. Ставишь Godot Editor, копируешь проекты с компа и запускаешь что захочешь без установки десятков отдельных приложений.
>GUI никто менять не будет
Если сделаешь нормально, должны принять. Билд под Андроид отдельно делается, поэтому основные билды раздувать отдельный мобильный интерфейс не будет.
>Андройд версия, это сторонний проект.
Это официально поддерживаемая версия:
https://godotengine.org/download/android/
>Цель не мобилки
Где это написано?
>The Android editor is currently in an experimental stage. The UI has not been adapted for touch screens yet; using a hardware keyboard and mouse is strongly recommended.
Сеймич. На твг делаю игру 90% на мабиле. Если еще займу призовое место, то можно обоссать всех хейтеров мабилак
Окей, я потратил 15 минут чтобы вам не пришлось тратить 5.
Минимальное изменение, Button заменена на пустой TextureRect, ему ребенком повешена синяя нода TouchScreenButton.
Масштабирование и позиционирование работает, передается от контрола тач-кнопке. Протестировано на мобиле в веб-версии, мультитач работает (на скринах показаны нажатые 2 кнопки). Подводных не вижу.
P.s. а на itch и Я.И. вряд ли получится различать по юзерагенту и отдавать нужный билд.
>пустой TextureRect
Для чего TextureRect?
Достаточно задать custom_minimal_size:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-custom-minimum-size
И то, это нужно только для контейнеров. Если нет контейнеров, можно просто size задавать.
Да просто для наглядности, чтобы рамочка была. Не помню как себя ведет пустой базовый Control
вводишь например айпи приятеля и ты с ним в одном лобби, возможно?
Возможно, но сложно. На ютубе гайдов полно, ИТТ это расписывать долго.
Сделай лучше кооп на одном экране и пригласи приятеля домой. Может поебетесь даже.
>на компьютере редактор не так быстро работает из-за огромного
Видел видео как сделать новый интерфейс годот отзывчивее. Разрабы поменяли способ отрисовки для многооконного интефейса. Если включить в настройках старую отрисовку, начинают шустрее отрисовываться элементы. У тебя проблема точно не в этом?
>>62055
>запуск проекта без установки отдельного APK.
Двачую. Еще бы отслеживать версии и пушить на мобилку только диффы...
>Если сделаешь нормально
Не факт
>официально поддерживаемая версия
Не помню уже где прочитал. То ли реддит то ли баг треккер. Кто-то писал что многи возмущались почему рарабы тратят ресурсы на такое бесполезное дело. И на самом деле в портирование, команда годот не учавствовала, и инициатор проекта кто-то другой.
>Где это написано?
В официальной документации.
https://docs.godotengine.org/en/stable/tutorials/editor/using_the_android_editor.html
> P.s. а на itch и Я.И. вряд ли получится различать по юзерагенту и отдавать нужный билд.
Возможно я сейчас оверхед предложу, но в годоте есть механизм загрузки пак-файлов. Предполагается, что он будет использован для модов/ДЛЦ, но вполне реально через этот механизм грузить паки текстур под сдетектированную в запущенной игре платформу.
>>62034
>>62036
>>62060
>>62066
>>62067
Спасибо за доступный разбор. Многого не знал.
Мой опыт:
Я когда открыл годот на смартфоне. То первое о чем подумал, использовать сгенерированые самим годотом текстуры, чтобы не возится с импортированием. Удивился что функция рисования кружочков есть, а ноды такой нету, по аналогии с 3д где есть геометрические csg фигуры. Туториал по рисованию вообще разочаровал. То есть мне надо рисовать все эти тангенты и косинусы в голове, и транслировать сразу в код, полный бардак.
> рисовать все эти тангенты и косинусы в голове, и транслировать сразу в код, полный бардак
Эх, да, Хуану оставался всего один маленький шаг, чтобы сделать полнофункциональный опенсорсный клон флеша/аниматора. И он его не сделал.
По идее, если игра оптимизируется под мобилки и веб, которые слабее пк, то дополнительная распаковка мобильных текстур на десктопе не должна давать ощутимой нагрузки на производительность. По крайней мере, во многих случаях такой костыль будет предпочтительнее чем раздутый файл установки.
>распаковка
То есть перепаковка, как в ранних гта, где при первом запуске надо было ждать пока текстуры перепакуются. Могли бы такой костыль добавить в годот.
> Могли бы такой костыль добавить в годот.
Они дали нам удочку (инструменты), чтобы тот кому надо, сам запилил себе вышеописанную рыбу.
>Рамка экрана повторяет размеры окна из настроек проекта
У меня, в андройдовском годоте, не повторяет. Рамка экрана и рамка камеры, по замерам, выходят где-то в два раза меньше чем должны быть, в пейзажной ориентации на смартфоне. В портретной ориентации эти рамки вписываются по ширине правильно в экран.
Растянутый на экран рутконтрол с приякореными к углам контролами с кнопками внутри, помогает растянуть неправильного размера рамку на весь экран. Но кнопки надо сильно увеличивать чтобы они отображались нормального размера в игре.
>>62060
>TextureRect, ему ребенком повешена синяя нода TouchScreenButton
А зачем TextureRect? Чтобы нажатия ловить?
У меня текстура присвоена внутри тачь кнопки. На ее площадь ловятся нажатия.
>>62066
>custom_minimal_size
А зачем? Что дает эта опция?
>Они дали нам удочку (инструменты), чтобы тот кому надо, сам запилил себе вышеописанную рыбу.
А что за инструменты? В смысле плагины свои писать? Просто очень не хватает одной рыбы. Во флеше можно было сохранять используемые буквы из шрифтов, себе в проект. В пдф тоже такая фича есть. Я бы целую игру запилил, только используя эмодзи. Столько векторного добра без надобности валяется... Вот бы добавить эту функцию чтобы можно было сохранять набор символов в отдельный шрифт и импортировать в проект.
>Я бы целую игру запилил, только используя эмодзи
Я в вашем диалоге не участвовал, но в чем проблема? Качаешь иконочный фонт в свг-формате и используешь. У меня валяется один проект сделанный на https://icons.getbootstrap.com
Плюс в интернете хватает ttf-to-svg конвертеров, если изкоробки фонт неудобно тебе свг дает.
Мне казалрсь что в 4ку такой способ добавили через texturerect + radialgradient. Еще можнр шейдером рисовать. Но да 2д шейпов вроде нет. Можно почитать тут как рисрвать с помощью полигонов, но там вроде везде скрипты иди аддоны фигурируют. github.com/godotengine/godot-proposals/issues/1126
Еще может быть можно использовать маску чтобы вырезать круг
>Если ставить обе, то работает, но билд вырастает вдвое, соответственно и время запуска скачивания.
Делай это. И пройдись по своим ресурсам, выкинь/ужми лишнее.
Еще вот это наверни: https://docs.godotengine.org/en/stable/contributing/development/compiling/optimizing_for_size.html
>айпи приятеля
Если у вас локальная сеть или VPN, то несложно. В локальной сети можно вообще забыть про пинг и связанные с ним проблемы (лаги).
Туториал:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Официальные демо:
https://github.com/godotengine/godot-demo-projects/tree/master/networking
Неофициальные:
https://godotengine.org/asset-library/asset?filter=multiplayer
>>62074
>сложно
Зачем ньюфага зря пугаешь? Ему же локально.
>На ютубе гайдов
Почему на документацию и демки не ссылаешься?
>Разрабы поменяли способ отрисовки
Они не "способ отрисовки" поменяли, а иерархию нод, сделав попапы потомком нового класса Window, что создаёт новое системное окно, что может вызывать задержку из-за создания контекста Vulkan.
>У тебя проблема точно не в этом?
Не в этом. При нажатии на ноду в сцене происходит переключение инспектора, а там куча всего...
>пушить на мобилку только диффы...
Поставь гит-клиент какой-нибудь. Вроде spck editor поддерживает гит, но это редактор для HTML/CSS/JS.
>портирование, команда годот не учавствовала, и инициатор проекта кто-то другой.
Лол, "команда годот"? Скорее "core contributors"? Знаю, однако, сборка доступна с официального сайта. Есть множество неофициальных сборок, которых на сайте никогда не было и не будет, а сборка под Андроид есть.
>>>Цель не мобилки
>>Где это написано?
>В официальной документации.
>...and large phones
Это ты называешь "цель не мобилки"?
У меня AIDA64 пишет "тип устройства: фаблет".
>Фа́блет (англ. phablet от phone телефон и tablet планшет) — смартфон, размер которого находится между размером типичного смартфона и планшетного компьютера: c диагональю от 5,7-6,0 (ранее в качестве фаблетов рассматривали модели с диагональю экрана от 5,5 дюймов, ещё ранее — и от 5,0) до 6,9 дюймов и шириной не более 135 мм. Также известен под неофициальными названиями «плафон» (планшет+телефон) и «лопатофон».
Тем не менее, с диагональю 6,43 всё ещё неудобно.
Уже не представляю себе, как использовать телефон с диагональю меньше 6'', а ведь когда-то в детстве был в восторге от кнопочного с ч/б экраном и змейкой...
>по юзер агенту различать моб и десктрп браузеры
https://docs.godotengine.org/en/stable/classes/class_string.html#class-string-method-contains
>for desktop in ["Windows", "Macintosh", ...]:
>_ if desktop in user_agent: load_desktop(); return
>for mobile in ["Android", "iPhone", ...]:
>_ if mobile in user_agent: load_mobile(); return
Надо, конечно, погуглить точный список строчек.
Вот что меня смущает: а разрешают ли Я.Игры твоей игре скачивать какие-то дополнительные файлы?
Так не факт что юзер агент честный. Может там везде будет стоять одинаковый, и фиг узнаешь запустили его на пк или мобилке.
Я вот с утра подумал, может хранить текстуры как то по другому, просто как png и загружать на лету.
>: а разрешают ли Я.Игры твоей игре скачивать какие-то дополнительные файлы?
Не знаю, но по идее все файлы у меня есть изначально. Их можно просто хранить в архиве который заливается, не обязательно быть где-то по другой ссылке. Ну как делали со звуком для 3-ки с web audio player.
Лучше сразу. Положение костей зависит от пропорций персонажа, в идеале вроде бы нужно их по середине оболочки (меша) размещать, а не как в ИРЛ туловище. Короче, под вайфучку, возможно, придётся править, особенно вайфучке с выдающимися достоинствами.
Но если ты сам делаешь модель с нуля, то можешь приблизительно набросать лоупольку, чтобы все пропорции примерно совпадали с финальной.
Картинка из интернета для примера.
>Так не факт что юзер агент честный
Да и хрен с этими анонимусами. Ты ещё скажи:
>а вдруг у игрока JS/WASM недоступен???
>а вдруг игрок с IE на Windows 95 зашёл???
>а вдруг игрок с текстового браузера зашёл???
>будет стоять одинаковый
Если это Я.Игры делают, пиши им в техподдержку.
>просто как png
Так речь шла о VRAM Compression, это же другое?
Просто сними обе галки и всё, не пробовал?
>Удивился что функция рисования кружочков есть, а ноды такой нету, по аналогии с 3д где есть геометрические csg фигуры.
Потому что НИНУЖНА и engine bloat.
CSG существует, потому что чисто кубы малополезны в трёхмерных играх. Условный столик и стульчик чтоб накидать, не бегая в отдельную программу. Это не финальная графика, а чтоб видеть, что тут будет - чрезвычайно полезно для любых 3D прототипов.
В 2D же такая фича мало кому нужна будет. Банально быстрее накидать мышкой в пейнте условный спрайт крокодила, чем нодами выставлять треугольники, изображая зубы в пасти. Чтобы эта фича была хоть немного полезной, нужен функционал полноценного графического редактора, а это уже повод для аддона.
https://godotengine.org/asset-library/asset/1593
>кнопки надо сильно увеличивать
Ну, я не знаю, в чём проблема. Это почитай:
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
+ можно иссуи на гитхабе глянуть...
>А зачем TextureRect?
Он же сказал: чтоб рамочка была.
Но рамка и у обычных Contol есть.
>>custom_minimal_size
>А зачем? Что дает эта опция?
Наследники класса Container управляют свойствами position, size и т.п. у своих потомков. Т.е. если Control внутри контейнера, она может быть сжата до своего минимального размера. Минимальный размер у нод может отсутствовать или не подходить под твою задачу, для этого и добавили custom_minimal_size.
>Так речь шла о VRAM Compression, это же другое?
>Просто сними обе галки и всё, не пробовал?
Тогда, белые модели без текстур и в десктопном и мобильном браузере.
А на панели импорта текстур у тебя что стоит?
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_images.html#compress-mode
Скорее всего у тебя VRAM Compressed.
Интересно, как работает Basis Universal?
Сейчас пробую перетыкать в каждой текстуре на uncompressed, но это небыстрый процесс. Хотя, конечно, этот сценарий воркфлоу выглядит как совсем сломанный. Логично, что я бы хотел компрессед текстуры для мобилы и фоллбек на обычные для десктопа. Иначе, получается, эти галочки вообще лишние и их не должно быть.
>Интересно, как работает Basis Universal?
По документации звучит как то что нужно. Но надо все переимпортировать.
Да, похоже это работает для обоих десктоп/мобайл браузеров, хранится один комплект текстур, галочки vram compression перестают влиять на экспорт. Вечером потщательнее потестирую и еще сравню размеры.
540x304, 0:05
>Но надо все переимпортировать.
Есть несколько способов быстро всё поменять:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/import_process.html
Там четыре модели:
GPT-3.5 Turbo
Claude 3 Haiku
Llama 3 70B
Mixtral 8x7B
Пытался выудить у них скрипты для гдота, но там черт ногу сломит, так как они для годот3, и сами нейронки не понимают как их под годот 4 проапгрейдить.
Я взял и каждую модель по очереди спросил, имеют ли они доступ к документации годота. Все кроме лламы сказали что нет. Я сказал что их информация устаревшая, и они ответили что на момент тренировки их модели годот 4 еще только в разработке был и у них не достает знаний и лучше обратится к оригинальной документации. Но Llama 3 70B сказала что имеет доступ к документации и может попробовать адаптировать код под годот 4. Я попросил скрипт для стрельбы в сторону оси -y, и она дала мне правильный скрипт подчеркнув что он для годот 4. Больше не буду как баран биться головой о закрытые ворота, и писать промты в не те нейронки, которые считают что я должен читать мануалы. Нашел нейронку которая сама умеет читать.
Спасибо за инфу. Мне до сих пор стрёмно общаться с чатботами. Фобия какая-то. Ну, пусть будет.
ГПТ 4о на оффсайте бесплатный, но у него 10 реквестов в сутки. Он меня пару раз спасал лучше любого гугла.
После него по качеству годот-релевантных запросов, по моему опыту, идет гугловский гемини - он бесплатный с неограниченным количеством запросов. Спрашивай до посинения.
Клауд Соннет (старший брат хайки) был плюс-минус на уровне гемини, но меня оттуда пидорнули до того как распробовал. Там тоже ограничение на реквесты.
Везде нужен не-рфшный прокси, ясно дело.
Ты плохо обрезал. Если ошибка только одна, то справа появляется кнопка 'скопировать'. А если ошибок несколько, то справа появляется красный кружок с х, и рядом число указывающее количество ошибок. Надо кликнуть по иксу и снизу выдвинется панель с описанием всех ошибок, там текст можно выделять.
Ок спс, хотя я всё равно хз нахера они сделали эту хуйню некопируемой
Можешь скопировать, разрешаю.
В первую очередь это надо прочитать и обдумать. Гугл тут мало чем поможет.
Там всего 3 простых части.
После объявления переменной,
ожидается конец выражения,
вместо этого у тебя там идентификатор.
Meh, все равно не быстро. Надо сначала было экстракнуть из каждой импортированной модельки материалы, потом в каждой папке выделить эти текстуры и прожать реимпорт. Пакетные операции в таком софте редко предусмотрены. Да пофиг. Я под какие нибудь саморазвивающие видосы рутинным делами занимаюсь.
Кстати да, осваиваю сейчас годот и если на работе с жсом мне гопота помогает пиздец, то в годоте он мне высирает какие-то невероятно идиотские скрипты. Сорок минут пытался заставить его скрипт работать, в итоге написал сам за 10 минут в разы лучше.
Вряд ли причина в нинужна и блоат, потому что Polygon2D то в коре есть, а он потяжелее будет.
Но я все-таки вспомнил, как в четверке сделать кружок накликиванием встроенных средств.
Sprite2D либо TextureRect, в нем новая GradientTexture2D, Width/Height разрешение в пикселях
В градиенте сдвинуть ползунки близко к одному краю, например 1 и 0.9 (или 0.97, 0.991 - от этого будет зависить насколько размытый/сглаженный или резкий край можно еще попробовать виды сглаживания - Cubic, Linear)
Альясинга в буквальном смысле там нет, но можно получить его сочетанием параметра выше, + завысить разрешение и уменьшить scale спрайта.
Выставить желаемый цвет и второй прозрачным.
Тип Fill - Radial, от (0.5, 0.5) до (0, 0.5), хз почему так, не спрашивайте.
Датасет обучающий скорее всего маленький был. Вроде читал, что кто-то обучал нейронку на куче гдскрипт исходников с гитхаба, но фиг знает это тоже много не лучших примеров.
Спасибо, ценная информация. Я хотел рамку в виде кружков без заливки вокруг кнопок нарисовать. Как на тач кнопках управления в гта на андройде. С помощью градиента с прозрачностью, должно получится.
Ну, еще всегда есть шейдеры. Особенно если тебе нужно кольцо, а не круг. Напртимер, https://godotshaders.com/shader/dotted-circle/
Кольцо градиентом тоже получилось, просто еще 2 стопа на градиенте с такой же логикой.
>сказала что имеет доступ к документации
Ты мог неправильно понять её слова.
>>62249
>Мне до сих пор стрёмно общаться с чатботами
А мне с мясными мешками стрёмно общаться...
>>62251
>Это тупо инструмент.
Как и мясные мешки. Игру делай давай, мясо!
>>62307
>пытался заставить его скрипт работать
А ты не скрипт спрашивай, а алгоритм работы.
>Надо сначала было экстракнуть из каждой импортированной модельки материалы
А при чём тут материалы? Текстуры в gltf зашиты? Рекомендую делать раздельный экспорт:
https://docs.blender.org/manual/en/latest/addons/import_export/scene_gltf2.html#gltf-separate-gltf-bin-textures
>потом в каждой папке выделить эти текстуры
В доке файловой системы вводишь звёздочку, точку и расширение png/jpg. Выдаст все картинки проекта.
>вводишь звёздочку
А, не, не обязательно. Достаточно начать набирать символы и док выдаёт список файлов с ними. Очень удобно, особенно если даёшь названия с префиксом, суффиксом и другими идентификаторами.
Я слышал, в ААА вообще всё строго с именованием файлов проекта, всё должно быть по системе.
Да, в общем это оказалось лучшим в плане фпс решением. Мне нужно было скрывать пару мешей при нахождении в воде, сначала шейдером сделал, но фпс пострадал. Переделал на коллизии и 2 строки гдскрипта.
>Как дешевле всего
Преждевременная оптимизация.
Ты сначала:
1. Сделай геймплей.
2. Сделай большой уровень.
3. Проверь, что игра тормозит на минималке.
4. Проверь, что отнимает больше всего времени.
5. Оптимизируй только это, остальное не трогай.
6. Повторяй пункты 3-5.
Или у тебя вся игра - это только
>определять что персонаж находится в воде
?
>Ты мог неправильно понять её слова.
Я правильно понял. Видимо позднее была натренирована и успела лучше пересечься с годот 4. Я после этого еще начал задавать разным моделям вопросы связанные с их последними версиями. GPT 3.5 уверена что GPT 4 не существует в природе...
>>62386
Ниже, ответ нейронки. Я лолнул с рейкастинга, потом вспомнил что в гта можно ходить под водой, если ты туда попадаешь минуя повехность. Так что наиболее ходовой вариант, наверное.
To determine if a character is in water, considering that water areas can be scattered throughout the level at different heights, here are a few approaches:
1. Raycasting: Cast a ray down from the character's position, and check if it hits a water surface within a certain distance (e.g., the character's height). If it does, the character is in water. You can adjust the ray's length and direction to suit your game's needs.
2. Sphere casting: Similar to raycasting, but use a sphere (e.g., the character's bounding sphere) to detect collisions with water surfaces. This method is more suitable for characters with a larger radius.
3. Grid-based detection: Divide your level into a grid, and mark water areas with a specific value (e.g., 1 for water, 0 for non-water). Then, check the grid cell(s) the character is currently occupying. If the cell value indicates water, the character is in water.
4. Water volume detection: Create a 3D volume (e.g., a box or sphere) around the character, and check if it overlaps with any water volumes in the level. You can use techniques like sphere-sphere or box-box overlap detection.
5. Physics-based detection: Use a physics engine to simulate the character's movement and interactions with the environment. If the character is in water, the physics engine will detect the collision and respond accordingly.
These methods can be combined or modified to fit your game's specific requirements. For example, you might use raycasting for initial detection and then use sphere casting for more precise checks.
>лолнул с рейкастинга
Скилл иссуе.
A simple method to detect object submersion in water is to use a bounding box or bounding sphere check.
Here's how it works:
1. Create a bounding box or sphere around the object.
2. Create a bounding box or sphere around the water body.
3. Check if the two bounding boxes or spheres overlap.
If they overlap, it means the object is at least partially submerged in the water. You can then use the overlap volume or distance to determine the submersion level.
This method is simple, fast, and easy to implement. It's not as accurate as mesh overlap detection, but it's a good starting point and can be sufficient for many use cases.
Keep in mind that this method assumes the object and water body are roughly convex shapes. If your objects or water bodies have complex concave shapes, you may need to use a more advanced method.
Самый легкий способ проверить если персонаж находится в воде это:
keep_swimming_bitch = is_valera_in_water("valera, where are you?")
В gltf и fbx, конечно, скачанные с интернета, там полный зоопарк.
Увидел в одном из тредов идею того, как лучше сделать "приближенный к реальности" рост растений на локации (каждые N секунд брать N% растений и пробовать увеличивать их значение роста), выглядит заебись разнообразно.
Сейчас делаю логику разрастания растений (захват ими новых клеток), завязал это на тоже на росте, когда растение достигает своего максимального уровня я беру свободные клетки-соседи, выбираю из них одну рандомную и "высаживаю" туда новое растение.
Выглядит вроде заебись, но может есть какие-то более применяемые стратегии для таких задач?
В идеале хочется получить рост растений как деревьев на ферме в stardew valley.
То что ты хочешь называется "генетические алгоритмы". Гугли.
https://www.youtube.com/watch?v=_Aow6P3oBAg
Ты не представляешь как глупо ты сейвас выглядишь.
Код был написан под квантовые вычисления.
переменная keep_swimming_bitch это bool, но не бинарный а квантовый. То есть значение занимает не один бит а один кубит.
А метод is_valera_in_water возвращает суперпозицию валеры. Которая будет находится в таком состоянии пока мы лично не посмотрим на валеру, или он сам себя не осознает, и сможет передать нам свое состояние, которое является конкретным для нашей вселенной. Каждый раз когда мы узнаем состояние валеры, состояние суперпозиции колапсирует, и наша вселенная разветвляется в бесконечное количество вселенных, в каждой из которых состояние валеры уникально.
Спок, тебе сейчас еще мультиплеером посоветуют это все сделать. У нас тут олимпиадник-дипломник обезумел, не можем с ним совладать.
Я закончил вроде весь механ базовый: есть инвентарь, можно подбирать предметы, бросать на землю, драться вблизи и вдали, использовать предметы, кушать-пить, есть сундуки с лутом, есть ИИ со всем базовым функционалом, есть ФОВ, пошаговость, скорость ходов, смерть.
Дальше только рабочие диалоги добавить и можно основную игру делать и графику...
Нойс. Одобряем. Разрешаем. Делай.
Напоминает спрайты из старбаунда, ток с красивыми глазами
>В идеале хочется получить рост растений как деревьев на ферме в stardew valley.
Там всё достаточно просто, тупо рандом. Из вики:
>...mature trees (excluding stumps) on the farm have a 15% chance each night of trying to spontaneously plant one seed in the ground. One tile is randomly chosen, up to 3 tiles away from the parent tree in any direction. The seed becomes "planted", creating a new stage 1 tree, only if the tile is a valid location for a new tree. In particular, the chosen tile must be empty; trees will not destroy paths or crops.
>Without fertilizer, seedlings have a 20% chance each night of growing to the next stage, except at stage 4, where seedlings spend twice as long. The median growth time from seed to maturity is 24 days, although individual tree growth times will vary considerably. Statistically, 90% of seeds should reach maturity in 38 days (excluding winter), and 99% in 55 days.
>>62533
>генетические алгоритмы
ГА вообще про другое. ГА используют для эволюции виртуальных организмов или программного кода. Там обязательным шагом является отсев неудачников и размножение выживших, чтобы получить более жизнеспособное потомство. А у анону нужно всего-то расставить деревья в случайном порядке, зачем ГА?
>>62605
>Ну так ты упрости
Куда уж проще, лол?
ГА в самом простом виде:
1. Берём индивидов с генами: АБ, БА, ВГ, ГВ.
2. Проводим тест выживаемости/эффективности.
3. Сортируем список индивидов по результатам.
4. Скрещиваем лучших: АБ, АБ, ВГ, ВГ, АГ, ВБ.
5. Мутируем некоторых: АБ, ББ, ВГ, ГГ, АГ, ВБ.
6. Повторяем шаги 2-5 в поиске идеальных.
Зачем применять ГА к деревьям в Stardew Valley?
>беру свободные клетки-соседи, выбираю из них одну рандомную
Лучше брать любые рандомные клетки, чем список свободных соседей. Так тупо быстрее, даже если большинство соседних клеток уже заняты.
Это позволяет осматриваться, я думаю полезная фича с учетом что радиус обзора не сильно большой
Чекни "Жизнь" Конвея. И на хабре большой цикл обзора разных клеточных автоматов от TLHE. Там можно полистать гифки и посмотреть получающиеся узоры.
>получающиеся узоры
Так ему нужно спрайты деревьев размещать, а не точечные узоры по строгим правилам. Для спрайтов лучше использовать рандом, чтоб органичнее было.
>>62695
>олдскул рогаликов
>огромные спрайты на полэкрана
В олдскул рогаликах ASCII в текстовом терминале.
>>62664
Достаточно будет сгладить возврат камеры.
Те кто понимают в шейдерах, поясните как трансформы использовать. Я пониаю что их нужно как-то умножить на векторы. Но на какие? ЮВ развертка вроде не при чем...Но что именно кормить в альбедо? Допустим я хочу скрин-спейс текстуру отображать на модели. Куда мне VIEW_MATRIX подключать?
Братан, это довольно сложно объяснить на пальцах в рамках постов-тредов. Ты бы матчасть загуглил.
Я бы сделал себе некоторые удобства для андройдовского годота. Первое чего не хватает, это вызвать экранную клавиатур в любом месте, чтобы можно было вводить горячие клавиши. Второе это собрать список элементов которые не использую и скрыть их всех. А остальные элементы скрывать и показывать при разных сценариях. Например хочу возможность отдельную панель растянуть на на весь экран и увеличить содержимое, или определенную часть экрана "приблизить". Самое простое, это наверное сделать когда нажимаешь на кнопку которая скрывает боковые панели, чтобы скрывалась также верхняя панель. Также хотелось бы задействовать кнопки громкости на телефоне под горячие клавиши, например убить процесс игры если тот не отвечает. Еще хотелось бы чтобы консоль сама закрывалась если не было никаких ошибок.
Я имел в виду, насколько можно изменять интерфейс с помощью плагинов.
Но в таком распределении же нет логики?
Лес, к примеру, "наступает" стеной с небольшим кол-вом выбивающихся вперед деревьев. Именно такое я пытаюсь повторить.
После обосрамса с РПГ Мейкер юнити, ГГГеймс увидели свет.
Это скорее всего будет пак ассетов и темплейтов. Но я не пишу это как что-то плохое. Если этот пак будет сочетаться между собой, это будет хорошее решение для вката богатых буратин. Работа по предпродакшену за тебя уже сделана. Плати.
Открой шейдер который так делает и посмотри
Напримре
godotshaders.com/shader/redacted/
godotshaders.com/shader/screenspace-tiled-texturing/
Полагаю там или вью матрица, или uv, не одновременно
В теории да, ведь редактор сам по себе сцена на годоте
godotengine.org/asset-library/asset/2003
>Лес, к примеру, "наступает" стеной
Лес никуда не наступает. Дерево разбрасывает вокруг себя семена, которые может подхватить ветром и разнести на большое расстояние. Если семя упадёт в благоприятных условиях, оно вырастает дерево. Если семя упадёт на голый камень, целый асфальт, крепкий дощатый пол, свежий пень, тогда оно просто погибнет. При этом дерево не выбирает, куда бросать семена, и может произвести только строго ограниченное число семян. Что тут непонятного?
>нет логики
Логика в том, чтобы вместо 8/24/48 проверок всех соседних клеток каждый тик таймера делать только 1 проверку случайной соседней клетки, которая может оказаться непригодной, но для ОБЩЕЙ КАРТИНЫ (размножение деревьев) это значения не имеет. Если хочешь, можешь дропать семечко как лут, чтобы игрок мог его спасти, если успеет вовремя подобрать и посадить в каком-то другом, благоприятном месте - бонус к реализму.
Алсо, деревья в лесу всегда держат расстояние друг от друга, потому что им нужен свет и воздух, а для этого необходимо свободное пространство. Слишком близко друг к другу деревья не выживают или слишком ослаблены, ожидая гибели огромных соседей. Даже в тропическом лесу деревья не срастаются в сплошную стену, эффект "стены" создают другие виды растений - лианы, кустарники и т.п. Если хочешь реалистичный лес, тебе нужно несколько видов растений с разными правилами роста и размножения. Смешанный лес в средней полосе вообще проходит несколько стадий эволюции с гибелью растений предыдущей стадии на промежутке в пару сотен лет.
Но для игры в первую очередь важен геймплей. Если геймплей с реалистичными растениями скучный, то необходимо сделать нереалистичные растения. Именно поэтому, в частности, рост растений в играх обычно в тысячи раз быстрее реальных.
Да нашел. Теперь надо посмотреть что внутри. И сделать себе отдельную вкладку для плагина, на которой будет список элементов который можно пополнять, и галочку чтобы скрыть или вернуть все эти элементы одним махом, хотя эту галочку можно и в более доступное место поставить чтоб не лезть за ней в настройки плагина. Таким образом элементы которые редко используются, можно скрыть, а если понадобятся, то можно все барахло вернуть, сделать свое грязное дело, и потом опять скрыть.
> Лес никуда не наступает.
Поэтому я и написал "наступает" имея ввиду продвижение леса на свободные незанятые ничем пространства, к примеру на заброшенные сельхоз поля.
> Логика в том, чтобы вместо 8/24/48 проверок всех соседних клеток каждый тик таймера делать только 1 проверку случайной соседней клетки
Я примерно так и сделал. Когда растение достигает своего максимального уровня оно имеет возможность "размножаться", с определенным шансом. Если растению выпадает такой шанс, то я беру массив всех клеток вокруг (с радиусом зависящим от параметров растения + есть минимальный радиус внутри которого это растение точно не размножится) и выбираю случайным образом одну клетку, проверяю ее на доступность для роста, если успех - сажу растение, если провал - фиаско, живу дальше.
Для тестов сделал 3 вида растений, каждый со своим набором параметров для роста и размножения + 4 вида поверхностей которые влияют на скорость роста растений.
Я решил начать с механик т.к. потом на это ядро будет проще крутить все остальное.
Спасибо за идеи, антош.
Как у вас мироощущение?
Сильно перформанс вырос?
Не жалеете, что не пишите на шарпе или гдскрипте?
Каждый дрочит как хочет
Визуальные изменения сделать решил, снизил разрешение спрайтов с 64х64 до 32х32, удобней так будет рисовать
Но 3.6 еще не
Годачую вопрос. Подумываю переписать один цикл на чистый Си, но останавливает плохое знание этого самого Си. Стоит ли заморачиваться, каков прирост?
1920x1080, 0:04
Ну разрешение я снизил, сделал все более простым визуально, мне так легче будет работать над игрой дальше, 64х64 все таки это многовато пикселей и на графон будет уходить много времени
Ты прости, может в следующий раз. А сейчас. Пора. Спать.
Ладно, Арни, сейчас я сделаю ускорение при выходе из портала. Будет вылетать на жопной тяге.
Зделол, плюс пару анрелейтед багов пофиксил. Пойду тоже спать. Бай, Арни.
А мне наоборот понравилось.
Не забивай сейчас свой мозг графикой. Используй картинки плейсхолдеры из интернета, чтобы скорее это скипнуть и вернутся к разработке. Максимум времени и мозговой нагрузки трать на интересную механику. Остальное потооооооом.
> Максимум времени и мозговой нагрузки трать на интересную механику.
Так ему графика наиболее интересна.
Нет, нельзя чтобы графика была более интересна. Запрещено.
>то я беру массив всех клеток вокруг
Но зачем тут массив-то?
>try_plant(Vector2i(x, y), Vector2i(
> randi_range(x - radius, x + radius),
> randi_range(y - radius, y + radius)))
>func try_plant(from, at):
> if can_plant(at): сажаем
Я весь механ основной уже закодил по сути. Ну я месяц провел не трогая графику вообще и писал базу, сейчас дошел уже до момента когда мне из базы нечего накручивать и пора саму игру делать, так что начал работу над крепостью и заодно подогнал стиль и разрешение под то с чем смогу работать долгое время.
За минувшую ночь много всего сделал, добавил столы на которые можно айтемы ложить, добавил бочки которые как сундуки, добавил разрушаемые объекты, в частности решетку, которую можно сломать три раза ударив любым оружием ближнего боя. Улучшил ИИ пупсиков чтобы они могли ориентироваться не только по твердым тайлам, но и по твердым сущностям статичным. А еще добавил "летающие сущности", прожектайлы аля фаербол входят в их категорию, у них свой слой навигации и они могут летать над столами например и всякими такими препятствиями которые по логике не должны им мешать, но вот нпс например их обходят.
Кстати угараю гусь автоматически двери открывать научился. Я не учил его, просто код так написан что он сам научился. Я убегаю от него по крепости и двери за собой закрываю, чтобы замедлить его, пока он их открывает целый ход проходит. Забыл написать что добавил двери.
>переписать один цикл на чистый Си
>каков прирост?
Если у тебя вызовы API движка: никакого.
Если меньше мюльона операций: никакого.
Если мюльоны операций: ты чё там творишь?
Короче, нужно смотреть по ситуации.
Это игровые спрайты, я для сексов буду рисовать отдельные более хайрез как в Лоне короче
Да я уже на ютубе глянул и понял что это слишком геморройное дело для меня. Оставлю так, не критично.
>Делайте игры
Быть может,настоящей игрой мечты была Годетта, которую мы завели на нашем пути к созданию игр...
Взгрустнул.
func _physics_process(delta):
var space_state = get_world_2d().direct_space_state
# use global coordinates, not local to node
var query = PhysicsRayQueryParameters2D.create(Vector2(0, 0), Vector2(50, 100))
var result = space_state.intersect_ray(query)
у меня есть нода enemies. я добавил ее в game в (0, 0). Правильно, что если я в query впишу (128, 128) (192, 128) при размере вью 256х256, то рейкаст будет смотреть вправо из середины, как стрелка на 3 часа? Что-то у меня ничего не детектит. там еще есть маска, если я введу туда 1, когда в проекте 1 занят под маску коллизий ноды машины, то в query будет залетать все, с чем и машина может сталкиваться? просто рейкаст через код в дебаге не отображается, ничего не понимаю. это же аналог RayCast2D?
Поставь в интересующем тебя месте любую ноду3д и чтобы она у себя в реди писала в консоль свои глобальные координаты. И смотри что напечатает.
>это же аналог RayCast2D?
Если тебе достаточно RayCast2D, лучше используй пока его и не заморачивайся с лучами из кода. Лучи из кода нужны только если тебе изредка нужен один рейкаст, а нода нужна, когда тебе нужно непрерывно или долго детектить столкновения.
>маска, если я введу туда 1, когда в проекте 1 занят под маску коллизий ноды машины, то в query будет залетать все, с чем и машина может сталкиваться?
Слои и маски - это разные понятия.
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html#collision-layers-and-masks
>collision_layer: This describes the layers that the object appears in. By default, all bodies are on layer 1.
>collision_mask: This describes what layers the body will scan for collisions. If an object isn't in one of the mask layers, the body will ignore it. By default, all bodies scan layer 1.
По идее, твоя машина находится в, скажем, слое 4, но сканирует несколько слоёв: земля (1), персонажи (2), предметы (3), машины (4), но игнорирует остальные слои: здания (5), интерьер (6), вода (7), эффекты (8). Машина сталкивается только с тем, что сканирует; другие могут сталкиваться с машиной, но машина игнорирует эти объекты, будто бы их и не было.
Маска рейкаста - это слои, которые рейкаст должен просканировать, скажем, хочешь детектить машины - ставишь слой 4, хочешь детектить воду - ставишь 7. Детектить всё, с чем машина может столкнуться - копируешь маску машины; это без учёта объектов, сталкивающихся с машиной, но игнорируемых ей.
> Как быть?
Группировать объекты в сценах. Держать сцены в порядке. Вместо папок использовать простую Node3D.
Ладно, отбой, не знаю как но раза с десятого выделилось примерно как надо, остальное вручную перетащу.
> Почему часть выделяется, а часть нет?
Лимит возможно по глубине охвата пространства выделяющим жестом. Возможно стоит во вьюпорте редактора настроить параметр FAR камеры, чтобы охватывать дальние объекты.
Потыкал, не особо помогает. Пока ощущение что больше зависит от угла внутриредакторной камеры, под которым ты смотришь. Алсо, у меня тройка, может в 4 такой проблемы нет.
Тогда шифт+клик, выделение предка или пикрил.
А мне нужно на постоянке, придется куда-то ноду впихивать. С масками пока не разобрался в той функции, но отдельно понял. Спсыч. Жаль, все-таки через код не так гибко получается по мне.
>Перекати тред.
Нет. Мне нравятся твои перекаты. ( ͡° ͜ʖ ͡°)
>Попробуй что-нибудь новенькое.
Как-то тяжело начинать что-то новое...
Удалил пару абзацев потока мыслей.
Учись заканчивать. Выбери уже начатый проект, обрежь ему скоп масштаб до недели-двух работы, и опубликуй. У меня так самый популярный мой проект релизнулся, лул.
>заканчивать
Интересные мне проекты: "Scope Creep: The Game".
>обрежь ему масштаб до недели-двух
Импоссибру, я неделю-две одну базовую механику пытаюсь сделать, а потом понимаю, что нужно с нуля всё переделывать и совершенно по-другому.
И не интересно мне публиковать микроигры. Зачем публиковать инди-игру, клон которой есть в игровом автомате внутри какой-нибудь AAA песочницы? Лол. Пересыщение рынка плюс бесполезность мини-игр.
>Удалил пару абзацев потока мыслей.
А я вообще пишу длинные ответы на посты и вместо того чтобы жать отправить удаляю. Потому что они мне кажутся не совершенными.
Это ценный опыт, аудитория, фолловеры, внимание, нетворкинг, понимание что вызывает интерес у людей, а что нет - все это поможет в дальнейшем. У популярных индюков часто по десятку никакующих игр бывало до того, как они приходили к успеху. А ты сейчас пытаешься напрямую с дивана на Эверест залезть.
Лично мне сложно представить более дизморалящую ситуацию, чем тот же Tail Quest, который пилили лет 5, пиарили на сайте годота, на баннерах годами висел, сам Хуан праздновал его релиз как годотовский долгострой, а в итоге вышло заунывное неудобное дрочилово.
Впрочем, мне нет нужды тебя уговаривать. Так, поделился своим взглядом. Ты делай как тебе норм.
>пишу длинные ответы на посты и вместо того чтобы жать отправить удаляю.
О, у меня тоже такое много раз бывало.
>Потому что они мне кажутся не совершенными.
У меня причин намного больше...
>>63629
У нас с тобой просто интересы разные.
>Это ценный опыт
Пукнуть три-в-ряд на итч - о да, ценнейший попыт.
>аудитория, фолловеры
Будут ждать от меня новых мини-игр. На ту же тему.
>внимание
Засрут токсичной критикой @ превратят в lolcow.
>нетворкинг
Толку от школоты, качающей бесплатные миниигры?
>понимание что вызывает интерес у людей
Для этого нужно рынок изучать. И вообще, не хочу прогибаться под наиболее популярные тренды.
>напрямую с дивана на Эверест залезть
А ты предлагаешь с аквалангом нырять.
>пиарили на сайте годота
Разработчики игр - не ЦА отдельной игры.
>вышло заунывное неудобное дрочилово
Кто виноват, что они не проводили ранние плейтесты с живыми игроками и/или не прислушивались к ним? Да и потом, это ж тавердефенс. Они все унылые...
>Пукнуть три-в-ряд на итч - о да, ценнейший попыт.
А ты не пукай. Сделай нормально.
Сделать проект конфетку, это действительно хороший опыт. И если с три-в-ряд у тебя есть шанс добиться совершенства. То со сферическими конями в вакууме они равны нулю.
У тебя какая-то элитистская болезнь, чел, хотя ты еще ничего не выложил. Спойлер - и не выложишь. Твои шедевры останутся только для тебя.
>шанс добиться совершенства
Перфекционизм только вредит, замедляет.
Да и потом... В играх "совершенство" субъективно.
>>63688
>Твои шедевры останутся только для тебя.
Что плохого? Были б шедевры, выложить несложно.
Обсуждение началось с того, что я:
- планировал сделать что-то презентабельное;
- ниасилил, приуныл и забил на всё задуманное;
- не могу усидеть на месте, ничего не делая.
А тут началось "сделай игру за неделю"...