Двач.hk не отвечает.
Вы видите копию треда, сохраненную 7 ноября в 13:16.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 7 ноября в 13:16.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Добро пожаловать! Добро пожаловать в Годотред-51!
Сами вы его выбрали, или его выбрали за вас - это лучший тред из оставшихся. Я такого высокого мнения о Годотреде, что решил перекатить его здесь, в /gd/, столь заботливо предоставленной нам Абу. Спасибо, Абу! Я горжусь тем, что называю Годотред своим домом.
Итак, собираетесь ли вы остаться здесь, или же вас ждёт геймдевелопинг, добро пожаловать в Годотред-51. Тред любви, взаимопомощи и кэша процессора!Шапка: https://hipolink.me/godothread
Предыдущий: >>951925 (OP)
Архивный: >>949247 (OP)
Сами вы его выбрали, или его выбрали за вас - это лучший тред из оставшихся. Я такого высокого мнения о Годотреде, что решил перекатить его здесь, в /gd/, столь заботливо предоставленной нам Абу. Спасибо, Абу! Я горжусь тем, что называю Годотред своим домом.
Итак, собираетесь ли вы остаться здесь, или же вас ждёт геймдевелопинг, добро пожаловать в Годотред-51. Тред любви, взаимопомощи и кэша процессора!Шапка: https://hipolink.me/godothread
Предыдущий: >>951925 (OP)
Архивный: >>949247 (OP)
>>54723
Перегибаешь, вспомни где круглые меню используются в основном: обычно для каких-то быстрых действий в забитый экшеном момент, типа переключения оружия.
Перегибаешь, вспомни где круглые меню используются в основном: обычно для каких-то быстрых действий в забитый экшеном момент, типа переключения оружия.
>>54723
Годно!
Причеши, оформи - и на ассетлиб. Базарю, станешь легендой.
>>54723
Вынеси как можно больше фич в опции, пусть конечный девелопер конфигурирует на свой вкус.
>>54729
А кому-то захочется круглое меню в пошаговой игре, тут-то ему свистоперделки и пригодятся.
>>54723
Воот, а потом принимайся за карусель-контрол. Есть такой паттерн.
Годно!
Причеши, оформи - и на ассетлиб. Базарю, станешь легендой.
>>54723
>Не перегибаю ли я
Вынеси как можно больше фич в опции, пусть конечный девелопер конфигурирует на свой вкус.
>>54729
>где круглые меню используются в основном
А кому-то захочется круглое меню в пошаговой игре, тут-то ему свистоперделки и пригодятся.
>>54723
Воот, а потом принимайся за карусель-контрол. Есть такой паттерн.
269x31Глупый вопрос, почему у меня софтварный курсор под кнопкнами отрисовывается? Эти кнопки я создаю динамически, может какое-то свойство пропустил? Вроде проблема не с z-индексом, у кнопок он 0, у курсора максимальный поставил. top-level тоже пробовал включать.
5 Кб, 358x107>>54757
Да. Причем в главном меню такие же кнопки и там все норм, но там они обычные. Эти создаю в пикрелейтеде вот так
for i in len(answers):
var _option_node = Button.new()
_option_node.text = answers["text"]
_option_node.theme = load("res://Scenes/UI/dialogue_button_theme.tres")
_option_node.alignment = HORIZONTAL_ALIGNMENT_LEFT
_vbox.add_child(_option_node)
_option_node.connect("pressed", _on_answer_selected.bind(answers["next"]))
в теме настроены только цвета, шрифты и тд.
Да. Причем в главном меню такие же кнопки и там все норм, но там они обычные. Эти создаю в пикрелейтеде вот так
for i in len(answers):
var _option_node = Button.new()
_option_node.text = answers["text"]
_option_node.theme = load("res://Scenes/UI/dialogue_button_theme.tres")
_option_node.alignment = HORIZONTAL_ALIGNMENT_LEFT
_vbox.add_child(_option_node)
_option_node.connect("pressed", _on_answer_selected.bind(answers["next"]))
в теме настроены только цвета, шрифты и тд.
>>54759
Раньше в трёшке это реализовывалось путём организации ноды-спавнера в дереве так, чтобы она по дизайну находилась под курсор-нодой, и всё, что в ней спавнится, так же оставалось там. В четверке добавили возможность вручную задавать z-индексы. То есть курсору сразу задаёшь индекс 100500 и он гарантированно будет поверх всех. ХЗ, что у тебя не получается. УМВР.
Раньше в трёшке это реализовывалось путём организации ноды-спавнера в дереве так, чтобы она по дизайну находилась под курсор-нодой, и всё, что в ней спавнится, так же оставалось там. В четверке добавили возможность вручную задавать z-индексы. То есть курсору сразу задаёшь индекс 100500 и он гарантированно будет поверх всех. ХЗ, что у тебя не получается. УМВР.
>>54729
Хех, в GTA Online они максимально всрали их меню переключения оружия: категорий много и почти в каждой категории можно купить десяток пушек, которые можно листать только по одной штучке, из-за чего быстрота выбора полностью теряется. Радиостанции тоже всрали, но их хотя бы можно скрыть по вкусу, и то на эту фичу 10 лет ушло.
В нашумевшем Palworld (сделан на Unreal) билдменю максимально всратое потому, что на каждом колесе фиксированное число кнопок, и они переключаются последовательно нажатиями кнопок влево-вправо, а страниц-категорий дохрена, т.е. у них там обратная проблема колеса оружия из GTA Online.
В The Sims вроде бы вообще тупо кнопки по кругу расставлены, т.е. на них нужно наводиться точно. В полноценном круглом меню секторы регистрируют наведение и клики мыши за пределами "кнопки".
Я читал, что круглые меню в играх появились из-за консолей, на которых сложно листать списки, а вот окружность стиком легко доступна. Но ты подумай: преимущество круглого меню в том, что все кнопки одинаково удалены от центра и их фактический (т.е. тактильный) размер намного больше визуального. Идеальный способ ввода для мыши и лентяев.
Если сравнить:
Списковые меню и меню квадратной сеткой: разное расстояние от кнопки до позиции курсора мыши по умолчанию, кнопки зачастую мелкие, а большие кнопки увеличивают расстояние крайних кнопок до позиции курсора мыши по умолчанию.
Табы/страницы: те же проблемы, что и у списковых меню, но табы, как правило, достаточно большими не сделать, сеткой не разместить, и от своего контента они зачастую загнаны на самый край экрана.
Главная проблема тут - юзеру необходимо целиться мышкой в желаемую кнопку. Чем меньше кнопка, тем сложнее прицелиться; чем больше кнопка, тем шире взмахи мышкой, но широкие взмахи всегда сложнее контролировать. В ОС даже придумали специальное ускорение курсора для решения этой проблемы, но в компьютерных играх это решение только мешает. Круглое меню решает проблему, позволяя без прицеливания махнуть мышкой и попасть в сектор; прицеливаться нужно только в центр, если он есть.
Круглые меню не панацея, но показалось интересным попробовать сделать из них что-то большее, чем одно нажатие на сектор круга. Может быть, даже можно реализовать инвентарь с переносом предметов? В инвентарях часто не хватает/используются группы предметов, и всё, что нужно - перенос из/в сундуки.
Да, криворукий, близорукий, не попадаю по кнопкам.
>>54750
Да, думал об этом, но как-то не очень хочется. Как минимум, много работы для нормального релиза. И вообще устал от этих меню, хочу игру делать. А если вдруг это станет популярным, появится 9001 игра с одинаковым дизайном, а это как-то не круто. Ничего особо сложного в этих меню нет, но большинство разработчиков, скорее всего, будут просто бездумно втыкать в свой проект, не меняя никаких настроек. А кому очень надо - те и с нуля сами написать смогут.
Но чем больше опций - тем медленнее основной функционал из-за проверок в коде. Тем более пока сомневаюсь, что делать для рендеринга градиентов и текстур на место секторов (там сейчас draw_arc).
Функцию предпросмотра чего-то на карусели легко заменить круговым меню, даже если элементов несколько десятков (сотни нужно группировать, а то будет сложно). Карусель имеет смысл, когда тебе нужно убрать подальше что-то старое и ненужное (как меню последних задач или рабочие столы на Android), разве такое часто встречается в играх? Для очень большой галереи (сотни снимков) лучше уж простую сетку нарисовать, чем листать поштучно.
Уверен, что базовая карусель в Godot делается за считанные строчки кода, и это с учётом анимаций.
>быстрых действий
>типа переключения оружия
Хех, в GTA Online они максимально всрали их меню переключения оружия: категорий много и почти в каждой категории можно купить десяток пушек, которые можно листать только по одной штучке, из-за чего быстрота выбора полностью теряется. Радиостанции тоже всрали, но их хотя бы можно скрыть по вкусу, и то на эту фичу 10 лет ушло.
В нашумевшем Palworld (сделан на Unreal) билдменю максимально всратое потому, что на каждом колесе фиксированное число кнопок, и они переключаются последовательно нажатиями кнопок влево-вправо, а страниц-категорий дохрена, т.е. у них там обратная проблема колеса оружия из GTA Online.
В The Sims вроде бы вообще тупо кнопки по кругу расставлены, т.е. на них нужно наводиться точно. В полноценном круглом меню секторы регистрируют наведение и клики мыши за пределами "кнопки".
Я читал, что круглые меню в играх появились из-за консолей, на которых сложно листать списки, а вот окружность стиком легко доступна. Но ты подумай: преимущество круглого меню в том, что все кнопки одинаково удалены от центра и их фактический (т.е. тактильный) размер намного больше визуального. Идеальный способ ввода для мыши и лентяев.
Если сравнить:
Списковые меню и меню квадратной сеткой: разное расстояние от кнопки до позиции курсора мыши по умолчанию, кнопки зачастую мелкие, а большие кнопки увеличивают расстояние крайних кнопок до позиции курсора мыши по умолчанию.
Табы/страницы: те же проблемы, что и у списковых меню, но табы, как правило, достаточно большими не сделать, сеткой не разместить, и от своего контента они зачастую загнаны на самый край экрана.
Главная проблема тут - юзеру необходимо целиться мышкой в желаемую кнопку. Чем меньше кнопка, тем сложнее прицелиться; чем больше кнопка, тем шире взмахи мышкой, но широкие взмахи всегда сложнее контролировать. В ОС даже придумали специальное ускорение курсора для решения этой проблемы, но в компьютерных играх это решение только мешает. Круглое меню решает проблему, позволяя без прицеливания махнуть мышкой и попасть в сектор; прицеливаться нужно только в центр, если он есть.
Круглые меню не панацея, но показалось интересным попробовать сделать из них что-то большее, чем одно нажатие на сектор круга. Может быть, даже можно реализовать инвентарь с переносом предметов? В инвентарях часто не хватает/используются группы предметов, и всё, что нужно - перенос из/в сундуки.
Да, криворукий, близорукий, не попадаю по кнопкам.
>>54750
>Причеши, оформи - и на ассетлиб.
Да, думал об этом, но как-то не очень хочется. Как минимум, много работы для нормального релиза. И вообще устал от этих меню, хочу игру делать. А если вдруг это станет популярным, появится 9001 игра с одинаковым дизайном, а это как-то не круто. Ничего особо сложного в этих меню нет, но большинство разработчиков, скорее всего, будут просто бездумно втыкать в свой проект, не меняя никаких настроек. А кому очень надо - те и с нуля сами написать смогут.
>Вынеси как можно больше фич в опции
Но чем больше опций - тем медленнее основной функционал из-за проверок в коде. Тем более пока сомневаюсь, что делать для рендеринга градиентов и текстур на место секторов (там сейчас draw_arc).
>карусель-контрол
Функцию предпросмотра чего-то на карусели легко заменить круговым меню, даже если элементов несколько десятков (сотни нужно группировать, а то будет сложно). Карусель имеет смысл, когда тебе нужно убрать подальше что-то старое и ненужное (как меню последних задач или рабочие столы на Android), разве такое часто встречается в играх? Для очень большой галереи (сотни снимков) лучше уж простую сетку нарисовать, чем листать поштучно.
Уверен, что базовая карусель в Godot делается за считанные строчки кода, и это с учётом анимаций.
>>54729
Хех, в GTA Online они максимально всрали их меню переключения оружия: категорий много и почти в каждой категории можно купить десяток пушек, которые можно листать только по одной штучке, из-за чего быстрота выбора полностью теряется. Радиостанции тоже всрали, но их хотя бы можно скрыть по вкусу, и то на эту фичу 10 лет ушло.
В нашумевшем Palworld (сделан на Unreal) билдменю максимально всратое потому, что на каждом колесе фиксированное число кнопок, и они переключаются последовательно нажатиями кнопок влево-вправо, а страниц-категорий дохрена, т.е. у них там обратная проблема колеса оружия из GTA Online.
В The Sims вроде бы вообще тупо кнопки по кругу расставлены, т.е. на них нужно наводиться точно. В полноценном круглом меню секторы регистрируют наведение и клики мыши за пределами "кнопки".
Я читал, что круглые меню в играх появились из-за консолей, на которых сложно листать списки, а вот окружность стиком легко доступна. Но ты подумай: преимущество круглого меню в том, что все кнопки одинаково удалены от центра и их фактический (т.е. тактильный) размер намного больше визуального. Идеальный способ ввода для мыши и лентяев.
Если сравнить:
Списковые меню и меню квадратной сеткой: разное расстояние от кнопки до позиции курсора мыши по умолчанию, кнопки зачастую мелкие, а большие кнопки увеличивают расстояние крайних кнопок до позиции курсора мыши по умолчанию.
Табы/страницы: те же проблемы, что и у списковых меню, но табы, как правило, достаточно большими не сделать, сеткой не разместить, и от своего контента они зачастую загнаны на самый край экрана.
Главная проблема тут - юзеру необходимо целиться мышкой в желаемую кнопку. Чем меньше кнопка, тем сложнее прицелиться; чем больше кнопка, тем шире взмахи мышкой, но широкие взмахи всегда сложнее контролировать. В ОС даже придумали специальное ускорение курсора для решения этой проблемы, но в компьютерных играх это решение только мешает. Круглое меню решает проблему, позволяя без прицеливания махнуть мышкой и попасть в сектор; прицеливаться нужно только в центр, если он есть.
Круглые меню не панацея, но показалось интересным попробовать сделать из них что-то большее, чем одно нажатие на сектор круга. Может быть, даже можно реализовать инвентарь с переносом предметов? В инвентарях часто не хватает/используются группы предметов, и всё, что нужно - перенос из/в сундуки.
Да, криворукий, близорукий, не попадаю по кнопкам.
>>54750
Да, думал об этом, но как-то не очень хочется. Как минимум, много работы для нормального релиза. И вообще устал от этих меню, хочу игру делать. А если вдруг это станет популярным, появится 9001 игра с одинаковым дизайном, а это как-то не круто. Ничего особо сложного в этих меню нет, но большинство разработчиков, скорее всего, будут просто бездумно втыкать в свой проект, не меняя никаких настроек. А кому очень надо - те и с нуля сами написать смогут.
Но чем больше опций - тем медленнее основной функционал из-за проверок в коде. Тем более пока сомневаюсь, что делать для рендеринга градиентов и текстур на место секторов (там сейчас draw_arc).
Функцию предпросмотра чего-то на карусели легко заменить круговым меню, даже если элементов несколько десятков (сотни нужно группировать, а то будет сложно). Карусель имеет смысл, когда тебе нужно убрать подальше что-то старое и ненужное (как меню последних задач или рабочие столы на Android), разве такое часто встречается в играх? Для очень большой галереи (сотни снимков) лучше уж простую сетку нарисовать, чем листать поштучно.
Уверен, что базовая карусель в Godot делается за считанные строчки кода, и это с учётом анимаций.
>быстрых действий
>типа переключения оружия
Хех, в GTA Online они максимально всрали их меню переключения оружия: категорий много и почти в каждой категории можно купить десяток пушек, которые можно листать только по одной штучке, из-за чего быстрота выбора полностью теряется. Радиостанции тоже всрали, но их хотя бы можно скрыть по вкусу, и то на эту фичу 10 лет ушло.
В нашумевшем Palworld (сделан на Unreal) билдменю максимально всратое потому, что на каждом колесе фиксированное число кнопок, и они переключаются последовательно нажатиями кнопок влево-вправо, а страниц-категорий дохрена, т.е. у них там обратная проблема колеса оружия из GTA Online.
В The Sims вроде бы вообще тупо кнопки по кругу расставлены, т.е. на них нужно наводиться точно. В полноценном круглом меню секторы регистрируют наведение и клики мыши за пределами "кнопки".
Я читал, что круглые меню в играх появились из-за консолей, на которых сложно листать списки, а вот окружность стиком легко доступна. Но ты подумай: преимущество круглого меню в том, что все кнопки одинаково удалены от центра и их фактический (т.е. тактильный) размер намного больше визуального. Идеальный способ ввода для мыши и лентяев.
Если сравнить:
Списковые меню и меню квадратной сеткой: разное расстояние от кнопки до позиции курсора мыши по умолчанию, кнопки зачастую мелкие, а большие кнопки увеличивают расстояние крайних кнопок до позиции курсора мыши по умолчанию.
Табы/страницы: те же проблемы, что и у списковых меню, но табы, как правило, достаточно большими не сделать, сеткой не разместить, и от своего контента они зачастую загнаны на самый край экрана.
Главная проблема тут - юзеру необходимо целиться мышкой в желаемую кнопку. Чем меньше кнопка, тем сложнее прицелиться; чем больше кнопка, тем шире взмахи мышкой, но широкие взмахи всегда сложнее контролировать. В ОС даже придумали специальное ускорение курсора для решения этой проблемы, но в компьютерных играх это решение только мешает. Круглое меню решает проблему, позволяя без прицеливания махнуть мышкой и попасть в сектор; прицеливаться нужно только в центр, если он есть.
Круглые меню не панацея, но показалось интересным попробовать сделать из них что-то большее, чем одно нажатие на сектор круга. Может быть, даже можно реализовать инвентарь с переносом предметов? В инвентарях часто не хватает/используются группы предметов, и всё, что нужно - перенос из/в сундуки.
Да, криворукий, близорукий, не попадаю по кнопкам.
>>54750
>Причеши, оформи - и на ассетлиб.
Да, думал об этом, но как-то не очень хочется. Как минимум, много работы для нормального релиза. И вообще устал от этих меню, хочу игру делать. А если вдруг это станет популярным, появится 9001 игра с одинаковым дизайном, а это как-то не круто. Ничего особо сложного в этих меню нет, но большинство разработчиков, скорее всего, будут просто бездумно втыкать в свой проект, не меняя никаких настроек. А кому очень надо - те и с нуля сами написать смогут.
>Вынеси как можно больше фич в опции
Но чем больше опций - тем медленнее основной функционал из-за проверок в коде. Тем более пока сомневаюсь, что делать для рендеринга градиентов и текстур на место секторов (там сейчас draw_arc).
>карусель-контрол
Функцию предпросмотра чего-то на карусели легко заменить круговым меню, даже если элементов несколько десятков (сотни нужно группировать, а то будет сложно). Карусель имеет смысл, когда тебе нужно убрать подальше что-то старое и ненужное (как меню последних задач или рабочие столы на Android), разве такое часто встречается в играх? Для очень большой галереи (сотни снимков) лучше уж простую сетку нарисовать, чем листать поштучно.
Уверен, что базовая карусель в Godot делается за считанные строчки кода, и это с учётом анимаций.
>>54754
>>54759
А курсор находится где? Z-индекс неявно зависит от положения ноды в сцене (потомки отображаются поверх своих предков, но ниже следующих нод).
По умолчанию у всех CanvasItem нод стоит это:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-z-as-relative
Попробуй отключить.
Я бы просто поместил курсор в самый нижний конец дерева, так он 100% будет выше всех. Игру и весь остальной контент вставляешь в середину дерева. Стандартный механизм переключения сцен мне всё равно совершенно не нравится.
>Вроде проблема не с z-индексом, у кнопок он 0, у курсора максимальный поставил.
>>54759
>Button.new()
А курсор находится где? Z-индекс неявно зависит от положения ноды в сцене (потомки отображаются поверх своих предков, но ниже следующих нод).
По умолчанию у всех CanvasItem нод стоит это:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-z-as-relative
Попробуй отключить.
Я бы просто поместил курсор в самый нижний конец дерева, так он 100% будет выше всех. Игру и весь остальной контент вставляешь в середину дерева. Стандартный механизм переключения сцен мне всё равно совершенно не нравится.
>>54780
Спасибо за ответ, я разобрался, у меня эти кнопки были в отдельном канваслеере по гайду для юая с ютуба, поэтому они и были поверх, в итоге вынес курсор тоже в отдельный канваслеер и сделал его самым верхним.
Спасибо за ответ, я разобрался, у меня эти кнопки были в отдельном канваслеере по гайду для юая с ютуба, поэтому они и были поверх, в итоге вынес курсор тоже в отдельный канваслеер и сделал его самым верхним.
>>54781
Не знаю, зачем тут CanvasLayer, сцена-то простая.
Хотя я вообще не очень понимаю роль CanvasLayer. В отличие от Viewport, текстуры не создаётся, только меняется порядок отрисовки. Но порядок отрисовки уже регулируется порядком нод и Z-индексом. Ну и зачем тогда слои, если роль слоя каждая CanvasItem выполняет своим положением и индексом? Если только всё очень сложно и запутанно в проекте.
Тем более на Node3D они вообще не влияют...
>>54759
Думаю, лучше использовать .size():
len() ожидает Variant и принимает в т.ч. String.
.size() есть только у Array и Dictionary и тут ты
спрашиваешь конкретный объект, а не Variant.
Ну и как-то читать легче ("для i в ответов.размер").
Во всяком случае, никогда не видел, чтоб вот так использовали len(), и сам пользуюсь только .size() (у String, если нужна длина строки, есть .length()).
>были в отдельном канваслеере
>тоже в отдельный канваслеер
Не знаю, зачем тут CanvasLayer, сцена-то простая.
Хотя я вообще не очень понимаю роль CanvasLayer. В отличие от Viewport, текстуры не создаётся, только меняется порядок отрисовки. Но порядок отрисовки уже регулируется порядком нод и Z-индексом. Ну и зачем тогда слои, если роль слоя каждая CanvasItem выполняет своим положением и индексом? Если только всё очень сложно и запутанно в проекте.
Тем более на Node3D они вообще не влияют...
>>54759
>len(answers):
Думаю, лучше использовать .size():
len() ожидает Variant и принимает в т.ч. String.
.size() есть только у Array и Dictionary и тут ты
спрашиваешь конкретный объект, а не Variant.
Ну и как-то читать легче ("для i в ответов.размер").
Во всяком случае, никогда не видел, чтоб вот так использовали len(), и сам пользуюсь только .size() (у String, если нужна длина строки, есть .length()).
>>54783
Чтобы на ui диалога не действовал зум камеры
про size и len понял принял
> Не знаю, зачем тут CanvasLayer, сцена-то простая.
Чтобы на ui диалога не действовал зум камеры
про size и len понял принял
105 Кб, 783x1024>>54699 (OP)
ГОДО ДЕЛАТЬ ИГРА!
ГОДО ДЕЛАТЬ ИГРА!
2,2 Мб, 811x1166Чому-то не работает DOF Far Blur в html сборке (пилю под GLES2). Мож кто знает, как лечить?
>>54886
Я по-быстрому протестировал здесь, на Firefox:
https://editor.godotengine.org/releases/3.6.beta5/
Похоже, что код шейдера сломан или несовместим.
DOF Near Blur вообще вываливает странные ошибки.
Ковыряться в исходниках движка, если очень надо.
Из моего опыта на 3.x ветке, блюр очень затратный.
>DOF Far Blur в html под GLES2
Я по-быстрому протестировал здесь, на Firefox:
https://editor.godotengine.org/releases/3.6.beta5/
Похоже, что код шейдера сломан или несовместим.
DOF Near Blur вообще вываливает странные ошибки.
>как лечить?
Ковыряться в исходниках движка, если очень надо.
Из моего опыта на 3.x ветке, блюр очень затратный.
>>54894
Спасяб за подсказку.
>Похоже, что код шейдера сломан или несовместим.
>Ковыряться в исходниках движка, если очень надо.
Спасяб за подсказку.
Сап, ГДач. Делаю игрушку с физическими механиками на Godot 4.3 (пока ещё бета). У меня уже готово перемещение предметов типа grab, но во время реализации столкнулся с проблемой... Если взять большой предмет с которым игрок должен сталкиваться, и иметь возможность его двигать через grab, он может просто запрыгнуть на него, потянуть вверх и полететь как на ковре-самолёте.
Если у предмета отключать коллизию, то во время отпускания предмета если игрок находился внутри предмета, происходит толчок и игрок может провалиться через текстуры. Плюс неприятно из-за того что игрок может видеть сквозь текстуры переносимого предмета.
Как сделать так, чтобы игрок мог носить большой предмет, сталкиваться с ним, но не летать на нём? Делать проверку позиции hand по высоте относительно ног игрока, чтобы выпусткать предмет из рук при отрицательном положении Y?
Если у предмета отключать коллизию, то во время отпускания предмета если игрок находился внутри предмета, происходит толчок и игрок может провалиться через текстуры. Плюс неприятно из-за того что игрок может видеть сквозь текстуры переносимого предмета.
Как сделать так, чтобы игрок мог носить большой предмет, сталкиваться с ним, но не летать на нём? Делать проверку позиции hand по высоте относительно ног игрока, чтобы выпусткать предмет из рук при отрицательном положении Y?
>>54957
Я бы сравнивал положение игрока по обоим вертикалям с положением предмета, и если они достаточно близко и предмет ниже, то ронять. Ещё можно заделать метод, определяющий на чём игрок стоит, но тут ньюанс в том, что можно будет летать подпрыгивая на предмете и подтягивая его за собой, как в старых версиях халвы
Я бы сравнивал положение игрока по обоим вертикалям с положением предмета, и если они достаточно близко и предмет ниже, то ронять. Ещё можно заделать метод, определяющий на чём игрок стоит, но тут ньюанс в том, что можно будет летать подпрыгивая на предмете и подтягивая его за собой, как в старых версиях халвы
>>54959
СПС, сейчас попробую
СПС, сейчас попробую
>>54959
Но есть загвоздка. Если предмет широкий, как, например огромный поддон или дверь, то можно сесть на край и поднять его, тем самым снова сооружая ковёр-самолёт.
Но есть загвоздка. Если предмет широкий, как, например огромный поддон или дверь, то можно сесть на край и поднять его, тем самым снова сооружая ковёр-самолёт.
>>54961
Зная размер объекта и его поворот, можно определять его ближайшую точку к игроку. Но тут надо использовать проверку на чём стоит/находится прямо над игрок. Хотя как ни крути, а всякие приколы игрок найдёт, как летающие машины в ботве, где игрок одну вагонетку кладёт на другую, забирается на верх и магнитом поднимает нижнюю.
Зная размер объекта и его поворот, можно определять его ближайшую точку к игроку. Но тут надо использовать проверку на чём стоит/находится прямо над игрок. Хотя как ни крути, а всякие приколы игрок найдёт, как летающие машины в ботве, где игрок одну вагонетку кладёт на другую, забирается на верх и магнитом поднимает нижнюю.
Какой на ваш взгляд подход к разработке предпочтительнее? Делать уровень сначала на затычках, постепенно заменяя их настоящими механиками, или сначала сделать все механики, а потом собирать из них уровень?
62 Кб, mp4,1280x180, 0:07
Почтиежедневный вопрос в тред
Я заметил, что софтварный курсор который я сделал не точен на некоторых объектах, сначала грешил на то что хотпойнт кривовато стоит, но оказалось дело не в этом.
Выглядит будто точка от которой считается global_position у спрайта меняется при его движении или типа того.
Вот записал видео, там софтварный курсор и хардварный с одинаковой картинкой
софтварный двигаю кодом
cursor.get_child(0).global_position = player.get_global_mouse_position()
И видно что в правой части экрана расхождение между курсорами по оси х больше.
У меня это вызывает недоумение.
print(cursor.get_child(0).global_position, " ", player.get_global_mouse_position()) выдают одинаковые значения
Я заметил, что софтварный курсор который я сделал не точен на некоторых объектах, сначала грешил на то что хотпойнт кривовато стоит, но оказалось дело не в этом.
Выглядит будто точка от которой считается global_position у спрайта меняется при его движении или типа того.
Вот записал видео, там софтварный курсор и хардварный с одинаковой картинкой
софтварный двигаю кодом
cursor.get_child(0).global_position = player.get_global_mouse_position()
И видно что в правой части экрана расхождение между курсорами по оси х больше.
У меня это вызывает недоумение.
print(cursor.get_child(0).global_position, " ", player.get_global_mouse_position()) выдают одинаковые значения
>>54957
Я тоже, в каком-то смысле. Много проблем...
Планируешь заменять встроенную физику?
https://github.com/godot-jolt/godot-jolt
Почему сразу 4.3? Говорят, там ещё не всё починили. Стабильные ветки действительно стабильны, а вот все эти бета-сборочки часто могут сцены ломать. Но дороги назад нет, если не сделал бэкап 4.2 проекта.
У меня обратная проблема была: игрок должен мочь передвигаться по поверхности подвижного объекта, но не мочь толкать объект как ракетный двигатель, непосредственно на нём находясь.
В Godot 4 теперь есть решение обоих проблем:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-layer
Пример 1: игрок сканирует препятствия, но подвижное тело игрока не сканирует, результат - только игрок сталкивается с подвижным телом и двигается от него, тогда как подвижное тело игрока совсем игнорирует.
Пример 2: подвижное тело сканирует игрока, но игрок подвижное тело не сканирует, результат - подвижное тело сталкивается с игроком и двигается от него, тогда как игрок подвижное тело совсем игнорирует.
...но тут есть нюансы:
В первом примере, если игрок встанет между двумя препятствиями, они его проигнорируют и игрок будет "раздавлен", но поскольку игрок бесконечно твёрдое тело, он выскочит куда-нибудь, куда захочет движок. Решение: убивать и респавнить игрока, либо делать анимации/регдолл для этой конкретной ситуации.
Во втором примере, подвижное тело будет, конечно, отскакивать от игрока, но если игрок найдёт где-то возможность зажать тело в углу и прыгнуть на него, тогда высока вероятность, что тело уйдёт под землю или вообще улетит куда-то, ведь для тела игрок в данной ситуации - непреодолимое препятвие.
Как это решить:
- тестировать локации на защиту от дурака;
- респавнить объект, если он улетел куда-то;
- не делать лишних платформ, которые игрок может одновременно тащить и стоять на них;
- вообще отказаться от возможности тащить то, на чём ты в данный момент стоишь (лол, зачем?).
>Делаю игрушку с физическими механиками
Я тоже, в каком-то смысле. Много проблем...
Планируешь заменять встроенную физику?
https://github.com/godot-jolt/godot-jolt
>на Godot 4.3 (пока ещё бета).
Почему сразу 4.3? Говорят, там ещё не всё починили. Стабильные ветки действительно стабильны, а вот все эти бета-сборочки часто могут сцены ломать. Но дороги назад нет, если не сделал бэкап 4.2 проекта.
>Если взять большой предмет с которым игрок должен сталкиваться, и иметь возможность его двигать через grab, он может просто запрыгнуть на него, потянуть вверх и полететь как на ковре-самолёте.
У меня обратная проблема была: игрок должен мочь передвигаться по поверхности подвижного объекта, но не мочь толкать объект как ракетный двигатель, непосредственно на нём находясь.
В Godot 4 теперь есть решение обоих проблем:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-layer
>Note: Object A can detect a contact with object B only if object B is in any of the layers that object A scans.
Пример 1: игрок сканирует препятствия, но подвижное тело игрока не сканирует, результат - только игрок сталкивается с подвижным телом и двигается от него, тогда как подвижное тело игрока совсем игнорирует.
Пример 2: подвижное тело сканирует игрока, но игрок подвижное тело не сканирует, результат - подвижное тело сталкивается с игроком и двигается от него, тогда как игрок подвижное тело совсем игнорирует.
...но тут есть нюансы:
В первом примере, если игрок встанет между двумя препятствиями, они его проигнорируют и игрок будет "раздавлен", но поскольку игрок бесконечно твёрдое тело, он выскочит куда-нибудь, куда захочет движок. Решение: убивать и респавнить игрока, либо делать анимации/регдолл для этой конкретной ситуации.
Во втором примере, подвижное тело будет, конечно, отскакивать от игрока, но если игрок найдёт где-то возможность зажать тело в углу и прыгнуть на него, тогда высока вероятность, что тело уйдёт под землю или вообще улетит куда-то, ведь для тела игрок в данной ситуации - непреодолимое препятвие.
Как это решить:
- тестировать локации на защиту от дурака;
- респавнить объект, если он улетел куда-то;
- не делать лишних платформ, которые игрок может одновременно тащить и стоять на них;
- вообще отказаться от возможности тащить то, на чём ты в данный момент стоишь (лол, зачем?).
>>54957
Я тоже, в каком-то смысле. Много проблем...
Планируешь заменять встроенную физику?
https://github.com/godot-jolt/godot-jolt
Почему сразу 4.3? Говорят, там ещё не всё починили. Стабильные ветки действительно стабильны, а вот все эти бета-сборочки часто могут сцены ломать. Но дороги назад нет, если не сделал бэкап 4.2 проекта.
У меня обратная проблема была: игрок должен мочь передвигаться по поверхности подвижного объекта, но не мочь толкать объект как ракетный двигатель, непосредственно на нём находясь.
В Godot 4 теперь есть решение обоих проблем:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-layer
Пример 1: игрок сканирует препятствия, но подвижное тело игрока не сканирует, результат - только игрок сталкивается с подвижным телом и двигается от него, тогда как подвижное тело игрока совсем игнорирует.
Пример 2: подвижное тело сканирует игрока, но игрок подвижное тело не сканирует, результат - подвижное тело сталкивается с игроком и двигается от него, тогда как игрок подвижное тело совсем игнорирует.
...но тут есть нюансы:
В первом примере, если игрок встанет между двумя препятствиями, они его проигнорируют и игрок будет "раздавлен", но поскольку игрок бесконечно твёрдое тело, он выскочит куда-нибудь, куда захочет движок. Решение: убивать и респавнить игрока, либо делать анимации/регдолл для этой конкретной ситуации.
Во втором примере, подвижное тело будет, конечно, отскакивать от игрока, но если игрок найдёт где-то возможность зажать тело в углу и прыгнуть на него, тогда высока вероятность, что тело уйдёт под землю или вообще улетит куда-то, ведь для тела игрок в данной ситуации - непреодолимое препятвие.
Как это решить:
- тестировать локации на защиту от дурака;
- респавнить объект, если он улетел куда-то;
- не делать лишних платформ, которые игрок может одновременно тащить и стоять на них;
- вообще отказаться от возможности тащить то, на чём ты в данный момент стоишь (лол, зачем?).
>Делаю игрушку с физическими механиками
Я тоже, в каком-то смысле. Много проблем...
Планируешь заменять встроенную физику?
https://github.com/godot-jolt/godot-jolt
>на Godot 4.3 (пока ещё бета).
Почему сразу 4.3? Говорят, там ещё не всё починили. Стабильные ветки действительно стабильны, а вот все эти бета-сборочки часто могут сцены ломать. Но дороги назад нет, если не сделал бэкап 4.2 проекта.
>Если взять большой предмет с которым игрок должен сталкиваться, и иметь возможность его двигать через grab, он может просто запрыгнуть на него, потянуть вверх и полететь как на ковре-самолёте.
У меня обратная проблема была: игрок должен мочь передвигаться по поверхности подвижного объекта, но не мочь толкать объект как ракетный двигатель, непосредственно на нём находясь.
В Godot 4 теперь есть решение обоих проблем:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-collision-layer
>Note: Object A can detect a contact with object B only if object B is in any of the layers that object A scans.
Пример 1: игрок сканирует препятствия, но подвижное тело игрока не сканирует, результат - только игрок сталкивается с подвижным телом и двигается от него, тогда как подвижное тело игрока совсем игнорирует.
Пример 2: подвижное тело сканирует игрока, но игрок подвижное тело не сканирует, результат - подвижное тело сталкивается с игроком и двигается от него, тогда как игрок подвижное тело совсем игнорирует.
...но тут есть нюансы:
В первом примере, если игрок встанет между двумя препятствиями, они его проигнорируют и игрок будет "раздавлен", но поскольку игрок бесконечно твёрдое тело, он выскочит куда-нибудь, куда захочет движок. Решение: убивать и респавнить игрока, либо делать анимации/регдолл для этой конкретной ситуации.
Во втором примере, подвижное тело будет, конечно, отскакивать от игрока, но если игрок найдёт где-то возможность зажать тело в углу и прыгнуть на него, тогда высока вероятность, что тело уйдёт под землю или вообще улетит куда-то, ведь для тела игрок в данной ситуации - непреодолимое препятвие.
Как это решить:
- тестировать локации на защиту от дурака;
- респавнить объект, если он улетел куда-то;
- не делать лишних платформ, которые игрок может одновременно тащить и стоять на них;
- вообще отказаться от возможности тащить то, на чём ты в данный момент стоишь (лол, зачем?).
>>54962
Это легко пофиксить, если кидать рейкаст от игрока в желаемом направлении и магнитить только самый первый объект на пути рейкаста. Физически, это наиболее логично: если два предмета магнитятся, то первым примагнитится тот, что ближе.
Вопрос в том, нужно ли запрещать игроку фан?
>летающие машины в ботве, где игрок одну вагонетку кладёт на другую, забирается на верх и магнитом поднимает нижнюю
Это легко пофиксить, если кидать рейкаст от игрока в желаемом направлении и магнитить только самый первый объект на пути рейкаста. Физически, это наиболее логично: если два предмета магнитятся, то первым примагнитится тот, что ближе.
Вопрос в том, нужно ли запрещать игроку фан?
>>54957
А-а-а, стоп... Ты имеешь в виду: сначала запрыгнуть, а уже потом потянуть? Единственным практичным решением тут будет определять, на чём игрок стоит своими ногами (это легко), и запрещать цеплять руками то, на чём стоим. Реальная проблема возникает только если игрок случайно наступит на то, что уже тащит, но это решается слоями физики - предмет отодвинется от ног сам по себе.
>запрыгнуть на него, потянуть вверх и полететь
А-а-а, стоп... Ты имеешь в виду: сначала запрыгнуть, а уже потом потянуть? Единственным практичным решением тут будет определять, на чём игрок стоит своими ногами (это легко), и запрещать цеплять руками то, на чём стоим. Реальная проблема возникает только если игрок случайно наступит на то, что уже тащит, но это решается слоями физики - предмет отодвинется от ног сам по себе.
>>54975
Я думаю, всё зависит от конкретной игры.
Если хочешь создать для игрока опыт, завязанный на локации, тогда сначала делаешь локацию, потом уже подстраиваешь механики под особенности локации.
Если хочешь сделать аттракцион весёлых механик, то сначала делаешь и отлаживаешь механики, потом уже вокруг них строишь все свои локации.
Скажем, если ты делаешь автобиографическую игру, сначала ты решаешь поставить в локации забор или дерево, а потом реализуешь механику карабкания по деревьям или перелезания через забор. Если же ты делаешь просто игру про паркур и всякие трюки в воздухе, то сначала делаешь механики паркура, уже после подстраиваешь локации, чтоб было весело эти механики использовать друг за другом.
Но тебе в любом случае потребуется какая-то тестовая локация для проверки механик, даже если финальная локация будет выглядеть совсем иначе. Тот же забор необходимо где-то поставить, чтобы тестировщик мог через него перебраться, иначе механику не потестишь.
>Делать уровень сначала на затычках, постепенно заменяя их настоящими механиками, или сначала сделать все механики, а потом собирать из них уровень?
Я думаю, всё зависит от конкретной игры.
Если хочешь создать для игрока опыт, завязанный на локации, тогда сначала делаешь локацию, потом уже подстраиваешь механики под особенности локации.
Если хочешь сделать аттракцион весёлых механик, то сначала делаешь и отлаживаешь механики, потом уже вокруг них строишь все свои локации.
Скажем, если ты делаешь автобиографическую игру, сначала ты решаешь поставить в локации забор или дерево, а потом реализуешь механику карабкания по деревьям или перелезания через забор. Если же ты делаешь просто игру про паркур и всякие трюки в воздухе, то сначала делаешь механики паркура, уже после подстраиваешь локации, чтоб было весело эти механики использовать друг за другом.
Но тебе в любом случае потребуется какая-то тестовая локация для проверки механик, даже если финальная локация будет выглядеть совсем иначе. Тот же забор необходимо где-то поставить, чтобы тестировщик мог через него перебраться, иначе механику не потестишь.
>>54980
Может, у тебя там где-то масштаб не равен 1?
Естественно. Ты же их присваиваешь. Потом движок преобразует эти координаты относительно слоя:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-global-position
Попробуй получать координаты от сервера:
ИМХО, ты всё слишком усложняешь.
Сначала отладь поведение курсора в изолированной сцене курсора, а уже потом добавляй эту сцену в игру.
>расхождение между курсорами по оси х больше
Может, у тебя там где-то масштаб не равен 1?
>выдают одинаковые значения
Естественно. Ты же их присваиваешь. Потом движок преобразует эти координаты относительно слоя:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-global-position
>The node's global position, relative to the world (usually to the CanvasLayer).
>player.get_global_mouse_position()
Попробуй получать координаты от сервера:
>Returns the mouse's position in the CanvasLayer that this CanvasItem is in using the coordinate system of the CanvasLayer.
>Note: For screen-space coordinates (e.g. when using a non-embedded Popup), you can use DisplayServer.mouse_get_position.
ИМХО, ты всё слишком усложняешь.
Сначала отладь поведение курсора в изолированной сцене курсора, а уже потом добавляй эту сцену в игру.
>>55008
А, не, это вроде относительно пикселей монитора?..
Обмажутся канвас лейерами и сдвигаются неточно...
>screen-space coordinates
А, не, это вроде относительно пикселей монитора?..
Обмажутся канвас лейерами и сдвигаются неточно...
>>54980
У тебя случайно в винде не включено какое-нибудь масштабирование? Почитай вот про эту настройку и про stretch
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#hidpi-support
У тебя случайно в винде не включено какое-нибудь масштабирование? Почитай вот про эту настройку и про stretch
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#hidpi-support
>>55013
Так он это рассматривал же: >>54957
>отключай физику предмету когда он в руках.
Так он это рассматривал же: >>54957
>во время отпускания предмета если игрок находился внутри предмета, происходит толчок и игрок может провалиться через текстуры. Плюс неприятно из-за того что игрок может видеть сквозь текстуры переносимого предмета.
>>55012
Камера есть, у нее зум 0, тоже грешил на нее, пробовал удалить, но результат тоже.
Попробовал убрать курсор с отдельного канвасслоя, проблемы нет.
Просто я тогда не понимаю как правильно делать. Юай должен быть на отдельном канваслеере, чтобы не подчиняться камеере, скроллу и всему такому, так? Значит и курсор должен быть на отдельном канваслеере, чтобы он мог быть поверх интерфейса.
Пока писал увидел пост >>55012
С настройкой странно, я ее выключил и все заработало, а потом включил, но оно осталось работать. Но перед этим я пересоздал канвас леер после удаления в предыдущей проверке.
В общем я понял, что ничего не понял. Наверно я как-то починил расхождение между слоями пересоздав слой курсора, но это неутешительно.
Камера есть, у нее зум 0, тоже грешил на нее, пробовал удалить, но результат тоже.
Попробовал убрать курсор с отдельного канвасслоя, проблемы нет.
Просто я тогда не понимаю как правильно делать. Юай должен быть на отдельном канваслеере, чтобы не подчиняться камеере, скроллу и всему такому, так? Значит и курсор должен быть на отдельном канваслеере, чтобы он мог быть поверх интерфейса.
Пока писал увидел пост >>55012
С настройкой странно, я ее выключил и все заработало, а потом включил, но оно осталось работать. Но перед этим я пересоздал канвас леер после удаления в предыдущей проверке.
В общем я понял, что ничего не понял. Наверно я как-то починил расхождение между слоями пересоздав слой курсора, но это неутешительно.
>>55017
Нужно было посмотреть, какие там настройки. А лучше всего создать бэкап сцены/проекта.
В Godot (4.2.2) до сих пор часто встречается проблема обновления актуальных значений в полях инспектора у внешних сцен. Т.е. ты вроде меняешь параметры во внешней сцене, а там, где ты их ожидаешь, они не изменяются как ты хотел... Сделал вывод, что лучше закрывать все лишние сцены и держать открытой только ту, с которой ты сейчас работаешь.
Похожие проблемы при переименовании и удалении скриптов и сцен. Лучше делать это, закрыв все сцены и скрипты, в которых этот файл используется, иначе потребуется перезагружать проект.
А вчера заметил, что инспектор не подгружает сразу актуальное содержимое enum в кастомном ресурсе. Пришлось перезагружать весь проект...
Ну, это всё не страшно, исправляется самим движком.
>как-то починил расхождение между слоями пересоздав слой курсора, но это неутешительно.
Нужно было посмотреть, какие там настройки. А лучше всего создать бэкап сцены/проекта.
В Godot (4.2.2) до сих пор часто встречается проблема обновления актуальных значений в полях инспектора у внешних сцен. Т.е. ты вроде меняешь параметры во внешней сцене, а там, где ты их ожидаешь, они не изменяются как ты хотел... Сделал вывод, что лучше закрывать все лишние сцены и держать открытой только ту, с которой ты сейчас работаешь.
Похожие проблемы при переименовании и удалении скриптов и сцен. Лучше делать это, закрыв все сцены и скрипты, в которых этот файл используется, иначе потребуется перезагружать проект.
А вчера заметил, что инспектор не подгружает сразу актуальное содержимое enum в кастомном ресурсе. Пришлось перезагружать весь проект...
Ну, это всё не страшно, исправляется самим движком.
>>55014
Я имел что-то вроде, объект rigid, чтобы с ним сталкиваться/толкать, но если поднял, он переключается в kinematic, прицепляется к персонажу и он ни в какие стены с ним заходить не будет. И вообще, вряд ли надо допускать ситуацию когда игрок оказыватся в объекте.
Я имел что-то вроде, объект rigid, чтобы с ним сталкиваться/толкать, но если поднял, он переключается в kinematic, прицепляется к персонажу и он ни в какие стены с ним заходить не будет. И вообще, вряд ли надо допускать ситуацию когда игрок оказыватся в объекте.
2 Кб, 240x269>>55025
У анона проблема с пикрила:
1. Игрок встал на площадку.
2. Пытается взять площадку в руки.
3-а. Площадка толкает игрока вверх?
3-б. Площадка проходит сквозь игрока?
3-в. Площадка вылетает из-под ног?
3-г. Площадка не даётся в руки?
3-д. Площадка уменьшается?
У анона проблема с пикрила:
1. Игрок встал на площадку.
2. Пытается взять площадку в руки.
3-а. Площадка толкает игрока вверх?
3-б. Площадка проходит сквозь игрока?
3-в. Площадка вылетает из-под ног?
3-г. Площадка не даётся в руки?
3-д. Площадка уменьшается?
>>55052
Если ты предлагаешь коллиженшейп предмета добавить к коллизиям чарактербоди, тогда твой персонаж превратится из капсулы в капсулу с прямоугольником внизу.
Ну ты попробуй, потом покажешь.
Если ты предлагаешь коллиженшейп предмета добавить к коллизиям чарактербоди, тогда твой персонаж превратится из капсулы в капсулу с прямоугольником внизу.
Ну ты попробуй, потом покажешь.
>>55070
Чуть чуть сложнее, там надо еще Area детектор пола в ногах. Я просто не понимаю что именно за механику анон хочет получить. В моем предствалении, если встать, например, на валун, и взяться за него руками, то ни поднять его нельзя, ни ходить пока ты стоишь на нем. Но если у него игра про серфинг на доске то это другая история и там могут появиться повороты.
Чуть чуть сложнее, там надо еще Area детектор пола в ногах. Я просто не понимаю что именно за механику анон хочет получить. В моем предствалении, если встать, например, на валун, и взяться за него руками, то ни поднять его нельзя, ни ходить пока ты стоишь на нем. Но если у него игра про серфинг на доске то это другая история и там могут появиться повороты.
Объясните, как изменить шаг смещения при привязке? А Анрыле есть конкретный выбор шага в юнитах, а в Годоте ничего не нашёл и не нагуглил. Дефолтный шаг равен 1 метру.
12 Кб, 333x36>>55095
Я не помню точно, капчую с телефона, но одна из двух кнопок на пикриле позволяет зайти в настройки и выбрать любое значение, в т.ч. дробное.
Я не помню точно, капчую с телефона, но одна из двух кнопок на пикриле позволяет зайти в настройки и выбрать любое значение, в т.ч. дробное.
>>55101 (Del)
Зато ты там можешь любое значение ввести, а не только выбрать одно из заложенных разрабами.
Вот у тебя на скрине вижу "1, 5, 10", а "other" нет. Как сделать привязку к сетке из 2, 3, 4 юнитов? А если мне необходима привязка к 0.575, 0.3, 0.025 юнита?
Впрочем, вся эта привязка не очень-то и нужна. Я задолбался со своим перфекционизмом, хочу уже просто слепить какое-нибудь говно играбельное...
Зато ты там можешь любое значение ввести, а не только выбрать одно из заложенных разрабами.
Вот у тебя на скрине вижу "1, 5, 10", а "other" нет. Как сделать привязку к сетке из 2, 3, 4 юнитов? А если мне необходима привязка к 0.575, 0.3, 0.025 юнита?
Впрочем, вся эта привязка не очень-то и нужна. Я задолбался со своим перфекционизмом, хочу уже просто слепить какое-нибудь говно играбельное...
>>55095
https://www.reddit.com/r/godot/comments/qjqnxa/
>>55097 >>55099
А, вообще перепутал, нужно View нажимать (?).
Так редко этим пользуюсь, что не помню вообще.
>не нагуглил
https://www.reddit.com/r/godot/comments/qjqnxa/
>>55097 >>55099
А, вообще перепутал, нужно View нажимать (?).
Так редко этим пользуюсь, что не помню вообще.
>>55102
Ну а как без неё, если у тебя, допустим, модульные ассеты комнат, где метровые стены, молы и потолки? Без привязки ты не состыкуешь без щелей и наслоений.
>Впрочем, вся эта привязка не очень-то и нужна.
Ну а как без неё, если у тебя, допустим, модульные ассеты комнат, где метровые стены, молы и потолки? Без привязки ты не состыкуешь без щелей и наслоений.
>>55105
Если у тебя квадратно-гнездовая застройка, пробуй:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
- автоматически оптимизирует повторения;
- автоматическая привязка к заданной сетке;
- можно иметь несколько разных в сцене;
- поддержка физики (StaticBody3D) и навмешей;
- более-менее удобно управлять из кода.
Минусы:
- поворот блоков по 90 градусов;
- у блоков нет анимаций, скриптов;
- не отдаёт свои коллизии в RigidBody3D (если хочешь делать модульный транспорт из кубиков);
- не оптимизирует полностью скрытые блоки (тут уже сам разбирайся, что показывать юзеру);
- оптимизации через мультимеш (это не Майнкрафт, в Майнкрафте сетка полностью перестраивается).
>модульные ассеты комнат
>метровые стены, полы и потолки
Если у тебя квадратно-гнездовая застройка, пробуй:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
- автоматически оптимизирует повторения;
- автоматическая привязка к заданной сетке;
- можно иметь несколько разных в сцене;
- поддержка физики (StaticBody3D) и навмешей;
- более-менее удобно управлять из кода.
Минусы:
- поворот блоков по 90 градусов;
- у блоков нет анимаций, скриптов;
- не отдаёт свои коллизии в RigidBody3D (если хочешь делать модульный транспорт из кубиков);
- не оптимизирует полностью скрытые блоки (тут уже сам разбирайся, что показывать юзеру);
- оптимизации через мультимеш (это не Майнкрафт, в Майнкрафте сетка полностью перестраивается).
21 Кб, 687x259Вот ещё накопал инфу. ctrl+shift делает шаг ещё меньше (0.1 метра по дефолту).
>>55106
Да, про гридмапс буквально сегодня читал. Это конечно больше для всяких платформеров и аркад больше подходит. Ну или для какого-нибудь аналога Майнкрафта. Это не то.
>>55106
Да, про гридмапс буквально сегодня читал. Это конечно больше для всяких платформеров и аркад больше подходит. Ну или для какого-нибудь аналога Майнкрафта. Это не то.
>>55108
Да нормально можно высотку смастерить, если у тебя все панели одного размера - хватит одного гридмапа. Если у тебя панели разных размеров, можно использовать несколько гридмапов. Вот сделать что-то кроме панелек будет сложно.
Для воксельной игры нужен специальный аддон, потому что в воксельных играх нужны специальные оптимизации: грубо говоря, один чанк Майнкрафта - это не тысячи кубиков, а один меш со сложной процедурной текстурой. Поэтому Майнкрафт хорошо работает даже на слабых устройствах.
Тут аддоны (воксели, карты высот):
https://github.com/Zylann
Да нормально можно высотку смастерить, если у тебя все панели одного размера - хватит одного гридмапа. Если у тебя панели разных размеров, можно использовать несколько гридмапов. Вот сделать что-то кроме панелек будет сложно.
Для воксельной игры нужен специальный аддон, потому что в воксельных играх нужны специальные оптимизации: грубо говоря, один чанк Майнкрафта - это не тысячи кубиков, а один меш со сложной процедурной текстурой. Поэтому Майнкрафт хорошо работает даже на слабых устройствах.
Тут аддоны (воксели, карты высот):
https://github.com/Zylann
>>55144
Я тебе про концепт ещё в прошлом году говорил, когда ты свою раскорячку-тян еще только создавал. но ты ж не хочешь по чужому концепту работать.
Я тебе про концепт ещё в прошлом году говорил, когда ты свою раскорячку-тян еще только создавал. но ты ж не хочешь по чужому концепту работать.
Поясните за правильную стратегию обучения. Вот я прошел туториал, который "ваша первая 2д игра". Дальше как лучше поступить? Уже можно начинать пилить свою простенькую игрулю и походу разбираться? Или лучше еще игр по инструкции настругать?
>>55153
С идеи. Ты какую игру сделать хочешь?
С идеи. Ты какую игру сделать хочешь?
>>55153
Скорее всего, лучше пройти ещё туториал. Но если у тебя большой опыт в другом движке, то можешь садиться пилить игру.
Скорее всего, лучше пройти ещё туториал. Но если у тебя большой опыт в другом движке, то можешь садиться пилить игру.
>>55153
Всё понял? Получилось? Попробуй поиграть параметрами. Добавить новых функций. Переделать так, чтобы никто без подсказки не догадался, по какому туториалу ты это начинал делать. Буквальное и бездумное следование инструкциям в туториалах не способствует быстрому обучению.
Если ты только и делаешь, что повторяешь шаги этих инструкций, то толку от этого мало.
Смотря что ты считаешь "простеньким". Многие новички хотят сразу свою "убийцу ГТА" делать, но считают это "простеньким" проектом, если откажутся от фотореализма, сложной физики, сюжета и озвучки... Но это по-прежнему экшн опенворлд в большом и сложном мире => сложный проект.
>Вот я прошел туториал, который "ваша первая 2д игра".
Всё понял? Получилось? Попробуй поиграть параметрами. Добавить новых функций. Переделать так, чтобы никто без подсказки не догадался, по какому туториалу ты это начинал делать. Буквальное и бездумное следование инструкциям в туториалах не способствует быстрому обучению.
>Или лучше еще игр по инструкции настругать?
Если ты только и делаешь, что повторяешь шаги этих инструкций, то толку от этого мало.
>Уже можно начинать пилить свою простенькую игрулю и походу разбираться?
Смотря что ты считаешь "простеньким". Многие новички хотят сразу свою "убийцу ГТА" делать, но считают это "простеньким" проектом, если откажутся от фотореализма, сложной физики, сюжета и озвучки... Но это по-прежнему экшн опенворлд в большом и сложном мире => сложный проект.
>>55156
Ну процентов 90.
Пробовал.
Так может все таки лучше новую начать?
Думал с автобатлера начать. Чтоб не душится сразу с многими аспектами работы с движком, сосредоточиться на поведении мобов, анимациях, балансе для начала.
>Всё понял?
Ну процентов 90.
>Попробуй поиграть параметрами.
Пробовал.
>Переделать так, чтобы никто без подсказки не догадался
Так может все таки лучше новую начать?
>Смотря что ты считаешь "простеньким". Многие новички хотят сразу свою "убийцу ГТА" делать
Думал с автобатлера начать. Чтоб не душится сразу с многими аспектами работы с движком, сосредоточиться на поведении мобов, анимациях, балансе для начала.
Проболел неделю, пора возвращаться к убийце СХ1 про сычиху запертую в трех этажах.
Попытался сделать зеркало через рендер в SubViewport второй камерой, с зеркально отраженным вращением/положением. А там оказывается сабвьюпорт не получает информацию от источников света из основного вьюпорта (кроме Environment нода). На пикриле работа зеркала, что есть свет, что нет света, зеркальная камера в суб-вьюпорте рендерит одинаково без света.
Можно отражение в черно-белое перевести, но я хотел геймплейные моменты обыграть с зеркалами, которые работают не так как обычные в квартире.
Очередная жопа.
Попытался сделать зеркало через рендер в SubViewport второй камерой, с зеркально отраженным вращением/положением. А там оказывается сабвьюпорт не получает информацию от источников света из основного вьюпорта (кроме Environment нода). На пикриле работа зеркала, что есть свет, что нет света, зеркальная камера в суб-вьюпорте рендерит одинаково без света.
Можно отражение в черно-белое перевести, но я хотел геймплейные моменты обыграть с зеркалами, которые работают не так как обычные в квартире.
Очередная жопа.
39,4 Мб, mp4,1024x768, 2:24
>>55167
То ли в прошлом, то ли в позапрошлом треде выкладывал, базовое взаимодействие с объектами, подбор предметов, использование оных из инвентаря.
Переходы между локациями начну когда отработаю базовые функции внутри квартиры. Вот сейчас затык с зеркалом.
То ли в прошлом, то ли в позапрошлом треде выкладывал, базовое взаимодействие с объектами, подбор предметов, использование оных из инвентаря.
Переходы между локациями начну когда отработаю базовые функции внутри квартиры. Вот сейчас затык с зеркалом.
>>55168
Пилите, Шура, пилите.
Пилите, Шура, пилите.
>>55151
Конкретно её начал в 2021. По жопе определил. ( ͡° ل͜ ͡°)
Общая концепция игры тянет свои гнилые корни с 2019.
Дело не в этом. Просто... нет, всё не просто. Попробую объяснить.
Хотел игру со строительством и ремонтом летающего транспорта "из говна и палок" или "тяп-ляп", при этом хотелось разрешить строить как угодно и где угодно без ограничений (отдельный 3D редактор каркаса в столе крафтинга сразу идёт мимо). Но на практике оказалось, что "строить как угодно без ограничений" (тяп-ляп) означает кучу проблем как игроку, так и игре. Намного удобнее строить, когда игра помогает тебе привязкой к чему-либо, и намного проще решать технические вопросы, когда дизайны транспорта имеют строгие правила.
Тогда я сделал точки крепления на краях панелей, но разрешил поворачивать практически на любой угол. И снова идея казалась замечательной в теории (можно было быстро слепить почти идеальную сферу из квадратных панелек, и она даже катилась по физике как шар), но на практике любой угол кроме 90 градусов ведёт к неровным дыркам, а как обрабатывать такого монстра из кода я даже не хочу думать (нужно было как-то соединять ближайшие точки крепления, а их буквально тысячи).
Ладно, решение очевидно - запретить все углы кроме 90. Но тогда получается, что строить из квадратов можно только "кубики", и для чего-то неровного нужны кучи отдельных блоков. Проблема отдельных блоков не только в том, что их нужно как-то смоделировать и описать правила сцепления между ними, но ещё и в том, что игроку придётся в менюшках копаться в поисках подходящих под его идею блоков (или - о, ужас! - листать колёсиком). Копание в десятках подвидов блоков противоречит изначальной задумке "тяп-ляп из говна и палок и полетели". Но вместе с тем хотелось бы чего-то привлекательного внешне, а не только летающие избушки из кубов.
В итоге пришёл к такой мысли: да, постройка состоит из "кубов" (вокселей), но характеристики этих кубов выбираются по их окружению, например, если у тебя три куба буквой "Г", то генерируются дополнительные треугольные опоры, якобы удерживающие эту конструкцию (наверняка видел ИРЛ). Что-то такое рассматривал для статичных зданий в прошлом, но далеко не зашёл. Чем-то напоминает "wave function collapse" или "марширующие кубы". Получается, игроку достаточно накидать кубов, а игра сама добавит декоративные детали, никак не влияющие на геймплей. Здесь учитывается необходимость часто накидывать новые кубы взамен разрушенных.
Кроме того, думал о том, что панели можно генерировать процедурно, расставляя деревянные балки в MultiMeshInstance3D (ИМХО, лучше, чем генерировать меш, если не смотреть на текстуры), что я этой ночью и накидал в сыром виде. Берём четыре точки, из них два ребра, находим середину, по шагам расставляем, поворачиваем и растягиваем одну и ту же балку с небольшой случайной вариацией - тяп-ляп панель произвольной формы готова - сам в шоке, но это проще, чем кажется. Правда, я только две оси из трёх осилил, по третьей ломается, но это не важно. Ещё непонятно что делать с коллизиями: для плоского квадрата всё просто, а что если образуется два треугольника? Да и геймплейно это никак толком не использовать без отдельного GUI - если только игра сама будет правильные формы создавать, типа тех же треугольников в случае расстановки кубов в форме "Г".
Короче! Завидую и отвлекаюсь на дизайн кораблей из игры, где корабли по геймплею создаются один раз в специальном GUI и никак не меняются до следующей остановки, тогда как моя игра, по задумке, про отчаянные попытки заткнуть дырки в непрерывно разрушающемся, гнилом и дырявом корыте, которое в любой момент может расколоться на два дырявых корыта или осыпаться балками игроку на голову, рванув самопальным двигателем и закрутившись вокруг своей оси на оставшихся, пока игрок латал дырки в попытке сохранить плавучесть. Игроку должно быть НЕКОГДА наводить красоту и выбирать треугольники из списка треугольников, НЕКОГДА дизайнить каркас причудливой формы в особом 3D редакторе каркасов, НЕКОГДА строить огромную сферу из деревянных квадратов. Но результат хотелось бы получать более-менее привлекательный геометрически (на любителя), а не вот эти унылые одинаковые кубы поверх кубов рядом с кубами под кубами. И чтоб внутри работала AStar навигация.
Почему всё так сложно? Пытаюсь совместить несовместимое? Хочу быстро, дёшево и красиво?
>в прошлом году ... тян ещё только создавал
Конкретно её начал в 2021. По жопе определил. ( ͡° ل͜ ͡°)
Общая концепция игры тянет свои гнилые корни с 2019.
>не хочешь по чужому концепту работать
Дело не в этом. Просто... нет, всё не просто. Попробую объяснить.
Хотел игру со строительством и ремонтом летающего транспорта "из говна и палок" или "тяп-ляп", при этом хотелось разрешить строить как угодно и где угодно без ограничений (отдельный 3D редактор каркаса в столе крафтинга сразу идёт мимо). Но на практике оказалось, что "строить как угодно без ограничений" (тяп-ляп) означает кучу проблем как игроку, так и игре. Намного удобнее строить, когда игра помогает тебе привязкой к чему-либо, и намного проще решать технические вопросы, когда дизайны транспорта имеют строгие правила.
Тогда я сделал точки крепления на краях панелей, но разрешил поворачивать практически на любой угол. И снова идея казалась замечательной в теории (можно было быстро слепить почти идеальную сферу из квадратных панелек, и она даже катилась по физике как шар), но на практике любой угол кроме 90 градусов ведёт к неровным дыркам, а как обрабатывать такого монстра из кода я даже не хочу думать (нужно было как-то соединять ближайшие точки крепления, а их буквально тысячи).
Ладно, решение очевидно - запретить все углы кроме 90. Но тогда получается, что строить из квадратов можно только "кубики", и для чего-то неровного нужны кучи отдельных блоков. Проблема отдельных блоков не только в том, что их нужно как-то смоделировать и описать правила сцепления между ними, но ещё и в том, что игроку придётся в менюшках копаться в поисках подходящих под его идею блоков (или - о, ужас! - листать колёсиком). Копание в десятках подвидов блоков противоречит изначальной задумке "тяп-ляп из говна и палок и полетели". Но вместе с тем хотелось бы чего-то привлекательного внешне, а не только летающие избушки из кубов.
В итоге пришёл к такой мысли: да, постройка состоит из "кубов" (вокселей), но характеристики этих кубов выбираются по их окружению, например, если у тебя три куба буквой "Г", то генерируются дополнительные треугольные опоры, якобы удерживающие эту конструкцию (наверняка видел ИРЛ). Что-то такое рассматривал для статичных зданий в прошлом, но далеко не зашёл. Чем-то напоминает "wave function collapse" или "марширующие кубы". Получается, игроку достаточно накидать кубов, а игра сама добавит декоративные детали, никак не влияющие на геймплей. Здесь учитывается необходимость часто накидывать новые кубы взамен разрушенных.
Кроме того, думал о том, что панели можно генерировать процедурно, расставляя деревянные балки в MultiMeshInstance3D (ИМХО, лучше, чем генерировать меш, если не смотреть на текстуры), что я этой ночью и накидал в сыром виде. Берём четыре точки, из них два ребра, находим середину, по шагам расставляем, поворачиваем и растягиваем одну и ту же балку с небольшой случайной вариацией - тяп-ляп панель произвольной формы готова - сам в шоке, но это проще, чем кажется. Правда, я только две оси из трёх осилил, по третьей ломается, но это не важно. Ещё непонятно что делать с коллизиями: для плоского квадрата всё просто, а что если образуется два треугольника? Да и геймплейно это никак толком не использовать без отдельного GUI - если только игра сама будет правильные формы создавать, типа тех же треугольников в случае расстановки кубов в форме "Г".
Короче! Завидую и отвлекаюсь на дизайн кораблей из игры, где корабли по геймплею создаются один раз в специальном GUI и никак не меняются до следующей остановки, тогда как моя игра, по задумке, про отчаянные попытки заткнуть дырки в непрерывно разрушающемся, гнилом и дырявом корыте, которое в любой момент может расколоться на два дырявых корыта или осыпаться балками игроку на голову, рванув самопальным двигателем и закрутившись вокруг своей оси на оставшихся, пока игрок латал дырки в попытке сохранить плавучесть. Игроку должно быть НЕКОГДА наводить красоту и выбирать треугольники из списка треугольников, НЕКОГДА дизайнить каркас причудливой формы в особом 3D редакторе каркасов, НЕКОГДА строить огромную сферу из деревянных квадратов. Но результат хотелось бы получать более-менее привлекательный геометрически (на любителя), а не вот эти унылые одинаковые кубы поверх кубов рядом с кубами под кубами. И чтоб внутри работала AStar навигация.
Почему всё так сложно? Пытаюсь совместить несовместимое? Хочу быстро, дёшево и красиво?
>>55151
Конкретно её начал в 2021. По жопе определил. ( ͡° ل͜ ͡°)
Общая концепция игры тянет свои гнилые корни с 2019.
Дело не в этом. Просто... нет, всё не просто. Попробую объяснить.
Хотел игру со строительством и ремонтом летающего транспорта "из говна и палок" или "тяп-ляп", при этом хотелось разрешить строить как угодно и где угодно без ограничений (отдельный 3D редактор каркаса в столе крафтинга сразу идёт мимо). Но на практике оказалось, что "строить как угодно без ограничений" (тяп-ляп) означает кучу проблем как игроку, так и игре. Намного удобнее строить, когда игра помогает тебе привязкой к чему-либо, и намного проще решать технические вопросы, когда дизайны транспорта имеют строгие правила.
Тогда я сделал точки крепления на краях панелей, но разрешил поворачивать практически на любой угол. И снова идея казалась замечательной в теории (можно было быстро слепить почти идеальную сферу из квадратных панелек, и она даже катилась по физике как шар), но на практике любой угол кроме 90 градусов ведёт к неровным дыркам, а как обрабатывать такого монстра из кода я даже не хочу думать (нужно было как-то соединять ближайшие точки крепления, а их буквально тысячи).
Ладно, решение очевидно - запретить все углы кроме 90. Но тогда получается, что строить из квадратов можно только "кубики", и для чего-то неровного нужны кучи отдельных блоков. Проблема отдельных блоков не только в том, что их нужно как-то смоделировать и описать правила сцепления между ними, но ещё и в том, что игроку придётся в менюшках копаться в поисках подходящих под его идею блоков (или - о, ужас! - листать колёсиком). Копание в десятках подвидов блоков противоречит изначальной задумке "тяп-ляп из говна и палок и полетели". Но вместе с тем хотелось бы чего-то привлекательного внешне, а не только летающие избушки из кубов.
В итоге пришёл к такой мысли: да, постройка состоит из "кубов" (вокселей), но характеристики этих кубов выбираются по их окружению, например, если у тебя три куба буквой "Г", то генерируются дополнительные треугольные опоры, якобы удерживающие эту конструкцию (наверняка видел ИРЛ). Что-то такое рассматривал для статичных зданий в прошлом, но далеко не зашёл. Чем-то напоминает "wave function collapse" или "марширующие кубы". Получается, игроку достаточно накидать кубов, а игра сама добавит декоративные детали, никак не влияющие на геймплей. Здесь учитывается необходимость часто накидывать новые кубы взамен разрушенных.
Кроме того, думал о том, что панели можно генерировать процедурно, расставляя деревянные балки в MultiMeshInstance3D (ИМХО, лучше, чем генерировать меш, если не смотреть на текстуры), что я этой ночью и накидал в сыром виде. Берём четыре точки, из них два ребра, находим середину, по шагам расставляем, поворачиваем и растягиваем одну и ту же балку с небольшой случайной вариацией - тяп-ляп панель произвольной формы готова - сам в шоке, но это проще, чем кажется. Правда, я только две оси из трёх осилил, по третьей ломается, но это не важно. Ещё непонятно что делать с коллизиями: для плоского квадрата всё просто, а что если образуется два треугольника? Да и геймплейно это никак толком не использовать без отдельного GUI - если только игра сама будет правильные формы создавать, типа тех же треугольников в случае расстановки кубов в форме "Г".
Короче! Завидую и отвлекаюсь на дизайн кораблей из игры, где корабли по геймплею создаются один раз в специальном GUI и никак не меняются до следующей остановки, тогда как моя игра, по задумке, про отчаянные попытки заткнуть дырки в непрерывно разрушающемся, гнилом и дырявом корыте, которое в любой момент может расколоться на два дырявых корыта или осыпаться балками игроку на голову, рванув самопальным двигателем и закрутившись вокруг своей оси на оставшихся, пока игрок латал дырки в попытке сохранить плавучесть. Игроку должно быть НЕКОГДА наводить красоту и выбирать треугольники из списка треугольников, НЕКОГДА дизайнить каркас причудливой формы в особом 3D редакторе каркасов, НЕКОГДА строить огромную сферу из деревянных квадратов. Но результат хотелось бы получать более-менее привлекательный геометрически (на любителя), а не вот эти унылые одинаковые кубы поверх кубов рядом с кубами под кубами. И чтоб внутри работала AStar навигация.
Почему всё так сложно? Пытаюсь совместить несовместимое? Хочу быстро, дёшево и красиво?
>в прошлом году ... тян ещё только создавал
Конкретно её начал в 2021. По жопе определил. ( ͡° ل͜ ͡°)
Общая концепция игры тянет свои гнилые корни с 2019.
>не хочешь по чужому концепту работать
Дело не в этом. Просто... нет, всё не просто. Попробую объяснить.
Хотел игру со строительством и ремонтом летающего транспорта "из говна и палок" или "тяп-ляп", при этом хотелось разрешить строить как угодно и где угодно без ограничений (отдельный 3D редактор каркаса в столе крафтинга сразу идёт мимо). Но на практике оказалось, что "строить как угодно без ограничений" (тяп-ляп) означает кучу проблем как игроку, так и игре. Намного удобнее строить, когда игра помогает тебе привязкой к чему-либо, и намного проще решать технические вопросы, когда дизайны транспорта имеют строгие правила.
Тогда я сделал точки крепления на краях панелей, но разрешил поворачивать практически на любой угол. И снова идея казалась замечательной в теории (можно было быстро слепить почти идеальную сферу из квадратных панелек, и она даже катилась по физике как шар), но на практике любой угол кроме 90 градусов ведёт к неровным дыркам, а как обрабатывать такого монстра из кода я даже не хочу думать (нужно было как-то соединять ближайшие точки крепления, а их буквально тысячи).
Ладно, решение очевидно - запретить все углы кроме 90. Но тогда получается, что строить из квадратов можно только "кубики", и для чего-то неровного нужны кучи отдельных блоков. Проблема отдельных блоков не только в том, что их нужно как-то смоделировать и описать правила сцепления между ними, но ещё и в том, что игроку придётся в менюшках копаться в поисках подходящих под его идею блоков (или - о, ужас! - листать колёсиком). Копание в десятках подвидов блоков противоречит изначальной задумке "тяп-ляп из говна и палок и полетели". Но вместе с тем хотелось бы чего-то привлекательного внешне, а не только летающие избушки из кубов.
В итоге пришёл к такой мысли: да, постройка состоит из "кубов" (вокселей), но характеристики этих кубов выбираются по их окружению, например, если у тебя три куба буквой "Г", то генерируются дополнительные треугольные опоры, якобы удерживающие эту конструкцию (наверняка видел ИРЛ). Что-то такое рассматривал для статичных зданий в прошлом, но далеко не зашёл. Чем-то напоминает "wave function collapse" или "марширующие кубы". Получается, игроку достаточно накидать кубов, а игра сама добавит декоративные детали, никак не влияющие на геймплей. Здесь учитывается необходимость часто накидывать новые кубы взамен разрушенных.
Кроме того, думал о том, что панели можно генерировать процедурно, расставляя деревянные балки в MultiMeshInstance3D (ИМХО, лучше, чем генерировать меш, если не смотреть на текстуры), что я этой ночью и накидал в сыром виде. Берём четыре точки, из них два ребра, находим середину, по шагам расставляем, поворачиваем и растягиваем одну и ту же балку с небольшой случайной вариацией - тяп-ляп панель произвольной формы готова - сам в шоке, но это проще, чем кажется. Правда, я только две оси из трёх осилил, по третьей ломается, но это не важно. Ещё непонятно что делать с коллизиями: для плоского квадрата всё просто, а что если образуется два треугольника? Да и геймплейно это никак толком не использовать без отдельного GUI - если только игра сама будет правильные формы создавать, типа тех же треугольников в случае расстановки кубов в форме "Г".
Короче! Завидую и отвлекаюсь на дизайн кораблей из игры, где корабли по геймплею создаются один раз в специальном GUI и никак не меняются до следующей остановки, тогда как моя игра, по задумке, про отчаянные попытки заткнуть дырки в непрерывно разрушающемся, гнилом и дырявом корыте, которое в любой момент может расколоться на два дырявых корыта или осыпаться балками игроку на голову, рванув самопальным двигателем и закрутившись вокруг своей оси на оставшихся, пока игрок латал дырки в попытке сохранить плавучесть. Игроку должно быть НЕКОГДА наводить красоту и выбирать треугольники из списка треугольников, НЕКОГДА дизайнить каркас причудливой формы в особом 3D редакторе каркасов, НЕКОГДА строить огромную сферу из деревянных квадратов. Но результат хотелось бы получать более-менее привлекательный геометрически (на любителя), а не вот эти унылые одинаковые кубы поверх кубов рядом с кубами под кубами. И чтоб внутри работала AStar навигация.
Почему всё так сложно? Пытаюсь совместить несовместимое? Хочу быстро, дёшево и красиво?
>>55168
А ты типа компонентами все это сделал? Интерактив компонент на залупу вешаешь и она становится интерактивной. Или как?
Я просто только вкатываюсь и оче интересно, как про делают разное.
А ты типа компонентами все это сделал? Интерактив компонент на залупу вешаешь и она становится интерактивной. Или как?
Я просто только вкатываюсь и оче интересно, как про делают разное.
>>54699 (OP)
" so I learned unity by making Mario, you can watch how it went on my youtube! At the end of 2021 I switched to the Godot Engine and haven't looked back!" - https://www.twitch.tv/jackie_codes
Немного мотивации
" so I learned unity by making Mario, you can watch how it went on my youtube! At the end of 2021 I switched to the Godot Engine and haven't looked back!" - https://www.twitch.tv/jackie_codes
Немного мотивации
>>55171
Ну да, вроде того.
Интерактивный объект (у меня называется Interactable) это отдельная сцена. В этой сцене содержится Area3D, с которым можно отследить столкновение и скрипт, позволяющий задать текст при взаимодействии и возможные опции (такие как выбор "Yes" или "No", при взаимодействии с выключателем света).
У персонажа перед носом свой Area3D который детектит столкновение с любым Interactable.
Затем, в игровой сцене, на нужные объекты, вешается экземпляр Interactable, каждому из которых присваивается свой текст при взаимодействии и опции. Если какой-то Interactable требует особых заскриптованных действий, ему присваивается новый скрипт, который расширяет класс Interactable переопределяя метод `interact'. Например, предметы, это класс Pickable, который является наследником Interactable с переопределенным методом `interact`.
>залупу вешаешь и она становится интерактивной
Ну да, вроде того.
Интерактивный объект (у меня называется Interactable) это отдельная сцена. В этой сцене содержится Area3D, с которым можно отследить столкновение и скрипт, позволяющий задать текст при взаимодействии и возможные опции (такие как выбор "Yes" или "No", при взаимодействии с выключателем света).
У персонажа перед носом свой Area3D который детектит столкновение с любым Interactable.
Затем, в игровой сцене, на нужные объекты, вешается экземпляр Interactable, каждому из которых присваивается свой текст при взаимодействии и опции. Если какой-то Interactable требует особых заскриптованных действий, ему присваивается новый скрипт, который расширяет класс Interactable переопределяя метод `interact'. Например, предметы, это класс Pickable, который является наследником Interactable с переопределенным методом `interact`.
>>55178
А такое возможно?
Я просто рили тупой и компонент такой написал бы скриптомю
>Интерактивный объект (у меня называется Interactable) это отдельная сцена
А такое возможно?
Я просто рили тупой и компонент такой написал бы скриптомю
https://vods.exodrifter.space/
Вот ещё стримы, возможно, кому-то помогут
Вот ещё стримы, возможно, кому-то помогут
>>55179
Ты не тупой, ты просто документацию не читал.
https://docs.godotengine.org/en/stable/getting_started/introduction/key_concepts_overview.html#scenes
>>55171
Читай пока документацию.
Если будешь копировать кого-то без понимания основ, получится каргокультинг - когда нуб пытается внешне повторить то, что видел у кого-то, не понимания, почему этот кто-то делал именно так, а не иначе. Получаются бесполезные чучела самолётов, которые делали аборигены, думая, это такой сигнал богам для сброса качественных припасов.
>Я просто рили тупой
Ты не тупой, ты просто документацию не читал.
https://docs.godotengine.org/en/stable/getting_started/introduction/key_concepts_overview.html#scenes
>In Godot, you break down your game in reusable scenes. A scene can be a character, a weapon, a menu in the user interface, a single house, an entire level, or anything you can think of. Godot's scenes are flexible; they fill the role of both prefabs and scenes in some other game engines.
>You can also nest scenes. For example, you can put your character in a level, and drag and drop a scene as a child of it.
>>55171
>Я просто только вкатываюсь
Читай пока документацию.
>оче интересно, как про делают разное.
Если будешь копировать кого-то без понимания основ, получится каргокультинг - когда нуб пытается внешне повторить то, что видел у кого-то, не понимания, почему этот кто-то делал именно так, а не иначе. Получаются бесполезные чучела самолётов, которые делали аборигены, думая, это такой сигнал богам для сброса качественных припасов.
2,5 Мб, mp4,1024x768, 0:09
>>55179
Можно рассматривать каждую отдельную сцену как класс, построенный по принципу композиции. Фактически, каждая сцена, это твой компонент.
>>55180
Когда найду подходящую модельку тни и нейронку чтобы сгенерировать голос для начальной сцены (фраза "I'm starving" истощенным голосом).
Можно рассматривать каждую отдельную сцену как класс, построенный по принципу композиции. Фактически, каждая сцена, это твой компонент.
>>55180
>Когда звуки добавишь?
Когда найду подходящую модельку тни и нейронку чтобы сгенерировать голос для начальной сцены (фраза "I'm starving" истощенным голосом).
>>55153
Теперь поделай игры без туториала, используя только документацию.
Можешь начать с клонов простых аркадных игр: Понг, Арканоид, Космическая Гонка и т.д. Главное - доводи их до конца. Чтобы были условия победы, поражения, меню. И чтобы были соответствующие экраны, и чтобы все это работало.
Теперь поделай игры без туториала, используя только документацию.
Можешь начать с клонов простых аркадных игр: Понг, Арканоид, Космическая Гонка и т.д. Главное - доводи их до конца. Чтобы были условия победы, поражения, меню. И чтобы были соответствующие экраны, и чтобы все это работало.
43 Кб, 739x620>>55185
А ты количество полигонов в моделях как-то контролируешь? А то по внешнему виду кажется, будто эта швейная машинка может быть самым плотным сгустком полигонов в твоей сцене. Конечно, актуальные версии Godot уже могут в auto LOD, но это увеличивает затраты памяти и стремится к максимальной разумной детализации. Алсо, возможно у тебя там "бутылочка гнума" в моделях, а ты даже и не знаешь об этом, если не проверял всё вручную. Конечно, сейчас полигоны не такие дорогие, как раньше, но тормоза всё равно могут вызывать.
А ты количество полигонов в моделях как-то контролируешь? А то по внешнему виду кажется, будто эта швейная машинка может быть самым плотным сгустком полигонов в твоей сцене. Конечно, актуальные версии Godot уже могут в auto LOD, но это увеличивает затраты памяти и стремится к максимальной разумной детализации. Алсо, возможно у тебя там "бутылочка гнума" в моделях, а ты даже и не знаешь об этом, если не проверял всё вручную. Конечно, сейчас полигоны не такие дорогие, как раньше, но тормоза всё равно могут вызывать.
>>55185
Почему ты записываешь с частотой кадров то 30, то вовсе 25?
Сколько кадров может выдать твоя сцена без записи (на твоём ПК)?
https://docs.godotengine.org/en/stable/classes/class_performance.html
Почему ты записываешь с частотой кадров то 30, то вовсе 25?
Сколько кадров может выдать твоя сцена без записи (на твоём ПК)?
https://docs.godotengine.org/en/stable/classes/class_performance.html
>$Label1.text = str(Performance.get_monitor(TIME_FPS)) # больше - лучше
>$Label2.text = str(Performance.get_monitor(TIME_PROCESS)) # меньше - лучше
19 Кб, 650x502>>55188
Текущая модель это времянка для работы. Базовая механика, более подходящие анимации и параметры скоростей будут задаваться на основной модели.
>>55191
Да, стараюсь, но работы много получается, так что проскакивает на что-то забиваю с мыслью "потом заменю".
Почти. 5300 треугольников. Много. Но страшнее всего - часы на кухне, 7500 треугольников после редактуры (оригинальная модель содержит 12000+ треуголников). Стараюсь брать мелочь на 1000 и меньше, свыше 1000 только большие и заметные объекты, либо мелкие но с приблежением камеры.
>вопросы:
Текущая модель это времянка для работы. Базовая механика, более подходящие анимации и параметры скоростей будут задаваться на основной модели.
>>55191
>А ты количество полигонов в моделях как-то контролируешь?
Да, стараюсь, но работы много получается, так что проскакивает на что-то забиваю с мыслью "потом заменю".
>А то по внешнему виду кажется, будто эта швейная машинка может быть самым плотным сгустком полигонов в твоей сцене
Почти. 5300 треугольников. Много. Но страшнее всего - часы на кухне, 7500 треугольников после редактуры (оригинальная модель содержит 12000+ треуголников). Стараюсь брать мелочь на 1000 и меньше, свыше 1000 только большие и заметные объекты, либо мелкие но с приблежением камеры.
>>55165
Ну норм, отражение как в ГТА5 на настройках уровня качества "нормальное".
Ну норм, отражение как в ГТА5 на настройках уровня качества "нормальное".
>>55188
А я вот часто так хожу. Места для разворота мало, квартира тесная, кость широкая.
>Как часто ты ходишь по квартире задом, не оборачиваясь?
А я вот часто так хожу. Места для разворота мало, квартира тесная, кость широкая.
Нда, просто игнорирует освещение, но кастует тени. При усилении света от WorldEnvironment какой-то непонятный результат.
>>55170
Да.
Да.
Игроку должно быть интересно.
Загугли платоновы тела. Там и углы будут.
> Пытаюсь совместить несовместимое?
Да.
> Хочу быстро, дёшево и красиво?
Да.
> Игроку должно быть НЕКОГДА
Игроку должно быть интересно.
> на практике любой угол кроме 90 градусов ведёт к неровным дыркам
Загугли платоновы тела. Там и углы будут.
>>55246
А я может быть тоже бот. Просто я органический бот. Органический наноконгломерат на основе белкового синтеза в углеводно-аммиачном цикле. Оснащённый органической нейросетью.
А я может быть тоже бот. Просто я органический бот. Органический наноконгломерат на основе белкового синтеза в углеводно-аммиачном цикле. Оснащённый органической нейросетью.
Анон, вопрос теоретический
Есть игра про хождение по комнатам, каждая комната это своя сцена, в них можно что-то делать пойнтэндклик квест да
Нагуглил два метода сохранять состояние комнат и потенциально сохранять игру - паковать сцену в ресурсы и распааковывать при необходимости или вести где-то огромный справочник переменных о состоянии комнат и их объектов и работать только с ним.
Есть игра про хождение по комнатам, каждая комната это своя сцена, в них можно что-то делать пойнтэндклик квест да
Нагуглил два метода сохранять состояние комнат и потенциально сохранять игру - паковать сцену в ресурсы и распааковывать при необходимости или вести где-то огромный справочник переменных о состоянии комнат и их объектов и работать только с ним.
>>55275
Меня наверно обоссут, но я сцены не меняю и подгружаю/выгружаю их внутри одной основной
Меня наверно обоссут, но я сцены не меняю и подгружаю/выгружаю их внутри одной основной
>>55278
Нет, это нормальный метод работы. Тебе удобно - так делай. Какая разница, где в дереве будет игра.
>>55275
Оверхед. Оверкилл. И прочие оверы. Нирикаминдую.
Способ рабочий и старинный. Но есть много нюансов с ним. Самый главный - работа только в коде. Нет визуального представления. Если ты сделаешь к этому справочнику обёртки для доступа к данным, тебе будет легче работать. Самое простое - это сделать две функции
Пераметр key передавать полным строковым путём к ключу в словаре словарей, то есть, скажем, основной словарь называется world у него есть ключ location и у него значение тоже словарь, а у того словаря есть ключ door у которого значение тоже словарь, а того словаря есть ключ open который буль и значение true. Чтобы записать туда значение, ты вызываешь:
Чтобы получить значение
Параметр make_key нужен, чтобы вписывать в словарь значения при первом обращении. Иногда такой функционал нужен.
Функции парсят входящий путь банальным сплитом и в цикле пытаются идти по пути, проверяя, является ил следующий элемент массивом? Если нет, возможны варианты. Если да, о доходят до конца пути и работают со значением, если оно есть. Если нет, опять же, варианты.
Я делал подобную систему, только я делал ещё замороченнее. У меня менеджер сохранений при создании получал ссылку на ридонли словарь1 (эталонные данные), и получал ссылку на ридрайт словарь2 (то что будет действительно сохраняться на диск). Логика работы такова: запись данных только в словарь2. Чтение, сначала читаем словарь2, если не найдено, читаем словарь1, если не найдено возвращаем дефолт, если найдено, на любом этапе возвращаем найденное. Если третий параметр тру и ничего не найдено, в словарь2 дополнительно записываем дефолт. Кроме того, у меня были режимы чтения и записи, как мне подсказал анон в треде "если у тебя идёт сохранение, а объекты продолжают данные записывать, что будет?"
Нет, это нормальный метод работы. Тебе удобно - так делай. Какая разница, где в дереве будет игра.
>>55275
> два метода сохранять
> паковать сцену в ресурсы и распааковывать при необходимости
Оверхед. Оверкилл. И прочие оверы. Нирикаминдую.
> вести где-то огромный справочник переменных о состоянии комнат и их объектов и работать только с ним
Способ рабочий и старинный. Но есть много нюансов с ним. Самый главный - работа только в коде. Нет визуального представления. Если ты сделаешь к этому справочнику обёртки для доступа к данным, тебе будет легче работать. Самое простое - это сделать две функции
> set_data(key, value)
> get_data(key. dafault, make_key = false)
Пераметр key передавать полным строковым путём к ключу в словаре словарей, то есть, скажем, основной словарь называется world у него есть ключ location и у него значение тоже словарь, а у того словаря есть ключ door у которого значение тоже словарь, а того словаря есть ключ open который буль и значение true. Чтобы записать туда значение, ты вызываешь:
> saver.set_data("world/location/door/open", false)
Чтобы получить значение
> var door_open = saver.get_data("world/location/door/open", false)
Параметр make_key нужен, чтобы вписывать в словарь значения при первом обращении. Иногда такой функционал нужен.
Функции парсят входящий путь банальным сплитом и в цикле пытаются идти по пути, проверяя, является ил следующий элемент массивом? Если нет, возможны варианты. Если да, о доходят до конца пути и работают со значением, если оно есть. Если нет, опять же, варианты.
Я делал подобную систему, только я делал ещё замороченнее. У меня менеджер сохранений при создании получал ссылку на ридонли словарь1 (эталонные данные), и получал ссылку на ридрайт словарь2 (то что будет действительно сохраняться на диск). Логика работы такова: запись данных только в словарь2. Чтение, сначала читаем словарь2, если не найдено, читаем словарь1, если не найдено возвращаем дефолт, если найдено, на любом этапе возвращаем найденное. Если третий параметр тру и ничего не найдено, в словарь2 дополнительно записываем дефолт. Кроме того, у меня были режимы чтения и записи, как мне подсказал анон в треде "если у тебя идёт сохранение, а объекты продолжают данные записывать, что будет?"
>>55278
Нет, это нормальный метод работы. Тебе удобно - так делай. Какая разница, где в дереве будет игра.
>>55275
Оверхед. Оверкилл. И прочие оверы. Нирикаминдую.
Способ рабочий и старинный. Но есть много нюансов с ним. Самый главный - работа только в коде. Нет визуального представления. Если ты сделаешь к этому справочнику обёртки для доступа к данным, тебе будет легче работать. Самое простое - это сделать две функции
Пераметр key передавать полным строковым путём к ключу в словаре словарей, то есть, скажем, основной словарь называется world у него есть ключ location и у него значение тоже словарь, а у того словаря есть ключ door у которого значение тоже словарь, а того словаря есть ключ open который буль и значение true. Чтобы записать туда значение, ты вызываешь:
Чтобы получить значение
Параметр make_key нужен, чтобы вписывать в словарь значения при первом обращении. Иногда такой функционал нужен.
Функции парсят входящий путь банальным сплитом и в цикле пытаются идти по пути, проверяя, является ил следующий элемент массивом? Если нет, возможны варианты. Если да, о доходят до конца пути и работают со значением, если оно есть. Если нет, опять же, варианты.
Я делал подобную систему, только я делал ещё замороченнее. У меня менеджер сохранений при создании получал ссылку на ридонли словарь1 (эталонные данные), и получал ссылку на ридрайт словарь2 (то что будет действительно сохраняться на диск). Логика работы такова: запись данных только в словарь2. Чтение, сначала читаем словарь2, если не найдено, читаем словарь1, если не найдено возвращаем дефолт, если найдено, на любом этапе возвращаем найденное. Если третий параметр тру и ничего не найдено, в словарь2 дополнительно записываем дефолт. Кроме того, у меня были режимы чтения и записи, как мне подсказал анон в треде "если у тебя идёт сохранение, а объекты продолжают данные записывать, что будет?"
Нет, это нормальный метод работы. Тебе удобно - так делай. Какая разница, где в дереве будет игра.
>>55275
> два метода сохранять
> паковать сцену в ресурсы и распааковывать при необходимости
Оверхед. Оверкилл. И прочие оверы. Нирикаминдую.
> вести где-то огромный справочник переменных о состоянии комнат и их объектов и работать только с ним
Способ рабочий и старинный. Но есть много нюансов с ним. Самый главный - работа только в коде. Нет визуального представления. Если ты сделаешь к этому справочнику обёртки для доступа к данным, тебе будет легче работать. Самое простое - это сделать две функции
> set_data(key, value)
> get_data(key. dafault, make_key = false)
Пераметр key передавать полным строковым путём к ключу в словаре словарей, то есть, скажем, основной словарь называется world у него есть ключ location и у него значение тоже словарь, а у того словаря есть ключ door у которого значение тоже словарь, а того словаря есть ключ open который буль и значение true. Чтобы записать туда значение, ты вызываешь:
> saver.set_data("world/location/door/open", false)
Чтобы получить значение
> var door_open = saver.get_data("world/location/door/open", false)
Параметр make_key нужен, чтобы вписывать в словарь значения при первом обращении. Иногда такой функционал нужен.
Функции парсят входящий путь банальным сплитом и в цикле пытаются идти по пути, проверяя, является ил следующий элемент массивом? Если нет, возможны варианты. Если да, о доходят до конца пути и работают со значением, если оно есть. Если нет, опять же, варианты.
Я делал подобную систему, только я делал ещё замороченнее. У меня менеджер сохранений при создании получал ссылку на ридонли словарь1 (эталонные данные), и получал ссылку на ридрайт словарь2 (то что будет действительно сохраняться на диск). Логика работы такова: запись данных только в словарь2. Чтение, сначала читаем словарь2, если не найдено, читаем словарь1, если не найдено возвращаем дефолт, если найдено, на любом этапе возвращаем найденное. Если третий параметр тру и ничего не найдено, в словарь2 дополнительно записываем дефолт. Кроме того, у меня были режимы чтения и записи, как мне подсказал анон в треде "если у тебя идёт сохранение, а объекты продолжают данные записывать, что будет?"
>>55282
Ну это понятно, хочется верить, что я не совсем тупенький, по работе тоже разработчик, хоть и автотестов. Спасибо за ответ, буду так делать.
> Самое простое - это сделать две функции
> > set_data(key, value)
> > get_data(key. dafault, make_key = false)
Ну это понятно, хочется верить, что я не совсем тупенький, по работе тоже разработчик, хоть и автотестов. Спасибо за ответ, буду так делать.
>>55278
Это единственный вариант для любой более-менее сложной игры, особенно если опенворлд (включая метроидвании, гигахрущи и прочее подобное).
>>55275
Делаешь такое дерево сцены:
- game: game.gd
- - menu:
- - - main: menu_main.gd
- - - pause: menu_pause.gd
- - world: game_world.gd
- - - room1: world_room.gd
- - - - door: door.gd
- - - - chest: chest.gd
- - - room2: ...
У скриптов door.gd, chest.gd и world_room.gd есть общий предок game_prop.gd, в котором:
Сообщает родителю, что состояние объекта только что изменилось (если планируешь сохранять при каждом действии игрока, как в некоторых играх).
Если будешь использовать описанный сигнал.
Возвращает актуальное состояние объекта по внешнему запросу от родителя (если планируешь сохранять только во время выхода из игры или по запросу пользователя из меню паузы).
Приводит объект в требуемое состояние. Родитель вызывает это во время загрузки игры. Если вызова не было - будет состояние по умолчанию, как начало новой игры или запуск сцены по нажатию F6.
Сразу видим, что можно описать свойство:
В скрипте game_world.gd:
Если будешь использовать описанный сигнал.
Сохраняет/загружает состояние мира игры в/из файл, возвращает код ошибки. Формат файла - JSON будет удобнее всего. Файлы ресурсов (.tres) не рекомендую, формат у них меняется от версии к версии движка, а ещё их возможно заразить вирусом на GDScript (лол).
В скрипте game.gd - управление всей игрой. Из меню приходит запрос сохранить/загрузить мир, главный скрипт обращается к game_world.gd, дальше знаешь.
Преимущество такой системы в том, что всё говно остаётся локальным, и если у тебя какой-то сундук обосрался с загрузкой состояния, ты его тут же за хвост поймаешь, а ещё можешь комбинировать всё разными способами (шкаф с ящичками управляет состоянием ящичков, сам управляясь комнатой).
Более того, если всё правильно сделал, то можешь комбинировать прям через редактор сцен, соединяя сигналами через инспектор нод или автоматически соединять сигналы, если есть подходящий предок:
Тогда можно вообще не париться, само работает, сохраняя возможность запускать всё независимо.
Всё состояние игры может выглядеть так:
{
Player: { health: 100, items: [ key1, ... ], },
Room1: {
Chest: [ item1, item2, item3, ],
Door: true,
Radio: 5,
Label: "здесь был Вася",
Wardrobe: { Box1: [ ... ] , Box2: [ ... ] , },
}, Room2: { ... }, }
Т.е. не обязательно, чтобы состояние было Dictionary, конкретный тип у потомков не проверяем, поскольку каждый конкретный объект получает своё говно по собственному имени и дальше разбирается сам, что конкретно он там насохранял в прошлом. Например, игровой мир чётко знает, что его стейт - это словарь, радиоприёмник чётко знает, что 5 - это ID станции, гардероб ожидает словарь с ящиками и т.д.
В теории могут возникнуть проблемы с именами, если объекты загружаются в мир динамически и при этом получают индексы в случайном порядке. Ну тут сам разбирайся, как называть динамические объекты. В качестве простого решения можно просто игнорить ошибки, но это может привести игру в непроходимое состояние, так что устаревшие сейвы нужно помечать в меню загрузки как несовместимые (см. Minecraft).
Если сохраняешь в JSON, сейвы можно вручную пофиксить. Или сделать конвертер в новую версию.
Если игровой мир супер большой, то game_world.gd должен сохранять по чанкам (отдельные файлы в файловой системе), но это другой разговор.
>>55282
Ты меня сразу извини, но это меня триггерит:
Лёг в ванну спагетти и дрочишь синглтоном?
Ты поди ещё и get_node("/root/...") балуешься?
>>55283
Он тебя учит как себе палки в колёса вставлять.
Лучше слушай меня, я уже давно проектирую игру.
>я сцены не меняю и подгружаю/выгружаю их внутри одной основной
Это единственный вариант для любой более-менее сложной игры, особенно если опенворлд (включая метроидвании, гигахрущи и прочее подобное).
>>55275
>сохранять состояние комнат и игру
Делаешь такое дерево сцены:
- game: game.gd
- - menu:
- - - main: menu_main.gd
- - - pause: menu_pause.gd
- - world: game_world.gd
- - - room1: world_room.gd
- - - - door: door.gd
- - - - chest: chest.gd
- - - room2: ...
У скриптов door.gd, chest.gd и world_room.gd есть общий предок game_prop.gd, в котором:
>signal state_changed(who: Node, new_state: Variant)
Сообщает родителю, что состояние объекта только что изменилось (если планируешь сохранять при каждом действии игрока, как в некоторых играх).
>func _on_state_changed(who: Node, new_state: Variant) -> void:
Если будешь использовать описанный сигнал.
>func get_state() -> Variant:
Возвращает актуальное состояние объекта по внешнему запросу от родителя (если планируешь сохранять только во время выхода из игры или по запросу пользователя из меню паузы).
>func set_state(new_state: Variant) -> void:
Приводит объект в требуемое состояние. Родитель вызывает это во время загрузки игры. Если вызова не было - будет состояние по умолчанию, как начало новой игры или запуск сцены по нажатию F6.
Сразу видим, что можно описать свойство:
>var state: Variant: set = set_state, get = get_state
В скрипте game_world.gd:
>func _on_state_changed(who: Node, new_state: Variant) -> void:
Если будешь использовать описанный сигнал.
>func save(file_path: String) -> int:
>func load(file_path: String) -> int:
Сохраняет/загружает состояние мира игры в/из файл, возвращает код ошибки. Формат файла - JSON будет удобнее всего. Файлы ресурсов (.tres) не рекомендую, формат у них меняется от версии к версии движка, а ещё их возможно заразить вирусом на GDScript (лол).
В скрипте game.gd - управление всей игрой. Из меню приходит запрос сохранить/загрузить мир, главный скрипт обращается к game_world.gd, дальше знаешь.
Преимущество такой системы в том, что всё говно остаётся локальным, и если у тебя какой-то сундук обосрался с загрузкой состояния, ты его тут же за хвост поймаешь, а ещё можешь комбинировать всё разными способами (шкаф с ящичками управляет состоянием ящичков, сам управляясь комнатой).
Более того, если всё правильно сделал, то можешь комбинировать прям через редактор сцен, соединяя сигналами через инспектор нод или автоматически соединять сигналы, если есть подходящий предок:
>func _ready() -> void:
>_ var p := get_parent()
>_ if p is GameProp or p is GameWorld:
>_ _ state_changed.connect(p, _on_state_changed)
Тогда можно вообще не париться, само работает, сохраняя возможность запускать всё независимо.
Всё состояние игры может выглядеть так:
{
Player: { health: 100, items: [ key1, ... ], },
Room1: {
Chest: [ item1, item2, item3, ],
Door: true,
Radio: 5,
Label: "здесь был Вася",
Wardrobe: { Box1: [ ... ] , Box2: [ ... ] , },
}, Room2: { ... }, }
Т.е. не обязательно, чтобы состояние было Dictionary, конкретный тип у потомков не проверяем, поскольку каждый конкретный объект получает своё говно по собственному имени и дальше разбирается сам, что конкретно он там насохранял в прошлом. Например, игровой мир чётко знает, что его стейт - это словарь, радиоприёмник чётко знает, что 5 - это ID станции, гардероб ожидает словарь с ящиками и т.д.
В теории могут возникнуть проблемы с именами, если объекты загружаются в мир динамически и при этом получают индексы в случайном порядке. Ну тут сам разбирайся, как называть динамические объекты. В качестве простого решения можно просто игнорить ошибки, но это может привести игру в непроходимое состояние, так что устаревшие сейвы нужно помечать в меню загрузки как несовместимые (см. Minecraft).
Если сохраняешь в JSON, сейвы можно вручную пофиксить. Или сделать конвертер в новую версию.
Если игровой мир супер большой, то game_world.gd должен сохранять по чанкам (отдельные файлы в файловой системе), но это другой разговор.
>>55282
Ты меня сразу извини, но это меня триггерит:
>полным строковым путём
>Чтобы записать туда значение, ты вызываешь:
>>saver.set_data("world/location/door/open", false)
>Чтобы получить значение
>>var door_open = saver.get_data("world/location/door/open", false)
>парсят входящий путь банальным сплитом
>является ли следующий элемент массивом
>У меня менеджер сохранений
Лёг в ванну спагетти и дрочишь синглтоном?
Ты поди ещё и get_node("/root/...") балуешься?
>>55283
>Спасибо за ответ, буду так делать.
Он тебя учит как себе палки в колёса вставлять.
Лучше слушай меня, я уже давно проектирую игру.
>>55278
Это единственный вариант для любой более-менее сложной игры, особенно если опенворлд (включая метроидвании, гигахрущи и прочее подобное).
>>55275
Делаешь такое дерево сцены:
- game: game.gd
- - menu:
- - - main: menu_main.gd
- - - pause: menu_pause.gd
- - world: game_world.gd
- - - room1: world_room.gd
- - - - door: door.gd
- - - - chest: chest.gd
- - - room2: ...
У скриптов door.gd, chest.gd и world_room.gd есть общий предок game_prop.gd, в котором:
Сообщает родителю, что состояние объекта только что изменилось (если планируешь сохранять при каждом действии игрока, как в некоторых играх).
Если будешь использовать описанный сигнал.
Возвращает актуальное состояние объекта по внешнему запросу от родителя (если планируешь сохранять только во время выхода из игры или по запросу пользователя из меню паузы).
Приводит объект в требуемое состояние. Родитель вызывает это во время загрузки игры. Если вызова не было - будет состояние по умолчанию, как начало новой игры или запуск сцены по нажатию F6.
Сразу видим, что можно описать свойство:
В скрипте game_world.gd:
Если будешь использовать описанный сигнал.
Сохраняет/загружает состояние мира игры в/из файл, возвращает код ошибки. Формат файла - JSON будет удобнее всего. Файлы ресурсов (.tres) не рекомендую, формат у них меняется от версии к версии движка, а ещё их возможно заразить вирусом на GDScript (лол).
В скрипте game.gd - управление всей игрой. Из меню приходит запрос сохранить/загрузить мир, главный скрипт обращается к game_world.gd, дальше знаешь.
Преимущество такой системы в том, что всё говно остаётся локальным, и если у тебя какой-то сундук обосрался с загрузкой состояния, ты его тут же за хвост поймаешь, а ещё можешь комбинировать всё разными способами (шкаф с ящичками управляет состоянием ящичков, сам управляясь комнатой).
Более того, если всё правильно сделал, то можешь комбинировать прям через редактор сцен, соединяя сигналами через инспектор нод или автоматически соединять сигналы, если есть подходящий предок:
Тогда можно вообще не париться, само работает, сохраняя возможность запускать всё независимо.
Всё состояние игры может выглядеть так:
{
Player: { health: 100, items: [ key1, ... ], },
Room1: {
Chest: [ item1, item2, item3, ],
Door: true,
Radio: 5,
Label: "здесь был Вася",
Wardrobe: { Box1: [ ... ] , Box2: [ ... ] , },
}, Room2: { ... }, }
Т.е. не обязательно, чтобы состояние было Dictionary, конкретный тип у потомков не проверяем, поскольку каждый конкретный объект получает своё говно по собственному имени и дальше разбирается сам, что конкретно он там насохранял в прошлом. Например, игровой мир чётко знает, что его стейт - это словарь, радиоприёмник чётко знает, что 5 - это ID станции, гардероб ожидает словарь с ящиками и т.д.
В теории могут возникнуть проблемы с именами, если объекты загружаются в мир динамически и при этом получают индексы в случайном порядке. Ну тут сам разбирайся, как называть динамические объекты. В качестве простого решения можно просто игнорить ошибки, но это может привести игру в непроходимое состояние, так что устаревшие сейвы нужно помечать в меню загрузки как несовместимые (см. Minecraft).
Если сохраняешь в JSON, сейвы можно вручную пофиксить. Или сделать конвертер в новую версию.
Если игровой мир супер большой, то game_world.gd должен сохранять по чанкам (отдельные файлы в файловой системе), но это другой разговор.
>>55282
Ты меня сразу извини, но это меня триггерит:
Лёг в ванну спагетти и дрочишь синглтоном?
Ты поди ещё и get_node("/root/...") балуешься?
>>55283
Он тебя учит как себе палки в колёса вставлять.
Лучше слушай меня, я уже давно проектирую игру.
>я сцены не меняю и подгружаю/выгружаю их внутри одной основной
Это единственный вариант для любой более-менее сложной игры, особенно если опенворлд (включая метроидвании, гигахрущи и прочее подобное).
>>55275
>сохранять состояние комнат и игру
Делаешь такое дерево сцены:
- game: game.gd
- - menu:
- - - main: menu_main.gd
- - - pause: menu_pause.gd
- - world: game_world.gd
- - - room1: world_room.gd
- - - - door: door.gd
- - - - chest: chest.gd
- - - room2: ...
У скриптов door.gd, chest.gd и world_room.gd есть общий предок game_prop.gd, в котором:
>signal state_changed(who: Node, new_state: Variant)
Сообщает родителю, что состояние объекта только что изменилось (если планируешь сохранять при каждом действии игрока, как в некоторых играх).
>func _on_state_changed(who: Node, new_state: Variant) -> void:
Если будешь использовать описанный сигнал.
>func get_state() -> Variant:
Возвращает актуальное состояние объекта по внешнему запросу от родителя (если планируешь сохранять только во время выхода из игры или по запросу пользователя из меню паузы).
>func set_state(new_state: Variant) -> void:
Приводит объект в требуемое состояние. Родитель вызывает это во время загрузки игры. Если вызова не было - будет состояние по умолчанию, как начало новой игры или запуск сцены по нажатию F6.
Сразу видим, что можно описать свойство:
>var state: Variant: set = set_state, get = get_state
В скрипте game_world.gd:
>func _on_state_changed(who: Node, new_state: Variant) -> void:
Если будешь использовать описанный сигнал.
>func save(file_path: String) -> int:
>func load(file_path: String) -> int:
Сохраняет/загружает состояние мира игры в/из файл, возвращает код ошибки. Формат файла - JSON будет удобнее всего. Файлы ресурсов (.tres) не рекомендую, формат у них меняется от версии к версии движка, а ещё их возможно заразить вирусом на GDScript (лол).
В скрипте game.gd - управление всей игрой. Из меню приходит запрос сохранить/загрузить мир, главный скрипт обращается к game_world.gd, дальше знаешь.
Преимущество такой системы в том, что всё говно остаётся локальным, и если у тебя какой-то сундук обосрался с загрузкой состояния, ты его тут же за хвост поймаешь, а ещё можешь комбинировать всё разными способами (шкаф с ящичками управляет состоянием ящичков, сам управляясь комнатой).
Более того, если всё правильно сделал, то можешь комбинировать прям через редактор сцен, соединяя сигналами через инспектор нод или автоматически соединять сигналы, если есть подходящий предок:
>func _ready() -> void:
>_ var p := get_parent()
>_ if p is GameProp or p is GameWorld:
>_ _ state_changed.connect(p, _on_state_changed)
Тогда можно вообще не париться, само работает, сохраняя возможность запускать всё независимо.
Всё состояние игры может выглядеть так:
{
Player: { health: 100, items: [ key1, ... ], },
Room1: {
Chest: [ item1, item2, item3, ],
Door: true,
Radio: 5,
Label: "здесь был Вася",
Wardrobe: { Box1: [ ... ] , Box2: [ ... ] , },
}, Room2: { ... }, }
Т.е. не обязательно, чтобы состояние было Dictionary, конкретный тип у потомков не проверяем, поскольку каждый конкретный объект получает своё говно по собственному имени и дальше разбирается сам, что конкретно он там насохранял в прошлом. Например, игровой мир чётко знает, что его стейт - это словарь, радиоприёмник чётко знает, что 5 - это ID станции, гардероб ожидает словарь с ящиками и т.д.
В теории могут возникнуть проблемы с именами, если объекты загружаются в мир динамически и при этом получают индексы в случайном порядке. Ну тут сам разбирайся, как называть динамические объекты. В качестве простого решения можно просто игнорить ошибки, но это может привести игру в непроходимое состояние, так что устаревшие сейвы нужно помечать в меню загрузки как несовместимые (см. Minecraft).
Если сохраняешь в JSON, сейвы можно вручную пофиксить. Или сделать конвертер в новую версию.
Если игровой мир супер большой, то game_world.gd должен сохранять по чанкам (отдельные файлы в файловой системе), но это другой разговор.
>>55282
Ты меня сразу извини, но это меня триггерит:
>полным строковым путём
>Чтобы записать туда значение, ты вызываешь:
>>saver.set_data("world/location/door/open", false)
>Чтобы получить значение
>>var door_open = saver.get_data("world/location/door/open", false)
>парсят входящий путь банальным сплитом
>является ли следующий элемент массивом
>У меня менеджер сохранений
Лёг в ванну спагетти и дрочишь синглтоном?
Ты поди ещё и get_node("/root/...") балуешься?
>>55283
>Спасибо за ответ, буду так делать.
Он тебя учит как себе палки в колёса вставлять.
Лучше слушай меня, я уже давно проектирую игру.
>>55309
Или лучше будет так, в классе родителя:
Так убираем зависимость GameProp от GameWorld.
Или сделать GameWorld наследником GameProp?..
Также забыл добавить, что обработчику события изменения состояния в GameWorld следует только забирать свежие данные и отмечать необходимость сохранения на диск. А сохранение на диск должно происходить по таймеру или запросу пользователя.
Что-то не помню, нужно ли делать "if c:" в for?
>>func _ready() -> void:
>>_ var p := get_parent()
>>_ if p is GameProp or p is GameWorld:
>>_ _ state_changed.connect(p, _on_state_changed)
Или лучше будет так, в классе родителя:
>func _ready() -> void:
>_ for c: GameProp in get_children():
>_ _ if c: c.state_changed.connect(self, _on_state_changed)
Так убираем зависимость GameProp от GameWorld.
Или сделать GameWorld наследником GameProp?..
Также забыл добавить, что обработчику события изменения состояния в GameWorld следует только забирать свежие данные и отмечать необходимость сохранения на диск. А сохранение на диск должно происходить по таймеру или запросу пользователя.
Что-то не помню, нужно ли делать "if c:" в for?
>>55314
И тебе спасибо.
И тебе спасибо.
>>55210
Проспался без температуры и пришло озарение - все в порядке со светом в сабвьюпорте. Я просто забыл инвертировать камеру по оси X перед тем как перемножать ее базис на матрицу отражения.
И ни одна ебаная Кодзима в треде не сможет сказать: "ФРАТЕЛЕ! ПОСМОТРИ НА СВОЙ СКРИН! У ТЕБЯ ТАМ СВЕТ ИНВЕРТИРОВАН!".
То как временная моделька жопой вперед ходит им не нравится, то в какой последовательности игру проектировать тебя научат. А как в реальной задаче указать на косяк уставшему человеку с температурой за 38, косяк видимый на скриншотах, так жидко сренькают в штанишки своими глубокими геймдев познаниями.
Проспался без температуры и пришло озарение - все в порядке со светом в сабвьюпорте. Я просто забыл инвертировать камеру по оси X перед тем как перемножать ее базис на матрицу отражения.
И ни одна ебаная Кодзима в треде не сможет сказать: "ФРАТЕЛЕ! ПОСМОТРИ НА СВОЙ СКРИН! У ТЕБЯ ТАМ СВЕТ ИНВЕРТИРОВАН!".
То как временная моделька жопой вперед ходит им не нравится, то в какой последовательности игру проектировать тебя научат. А как в реальной задаче указать на косяк уставшему человеку с температурой за 38, косяк видимый на скриншотах, так жидко сренькают в штанишки своими глубокими геймдев познаниями.
>>55334
Блядь, да просто сделай по сюжету чтобы в квартире кто-от недавно сдох и поэтому зеркала завешаны.
Блядь, да просто сделай по сюжету чтобы в квартире кто-от недавно сдох и поэтому зеркала завешаны.
>>55298
Чето тебе никто не пишет, я поиграл, анончик, прикольно, но у меня подтормаживает камера на сильном компе.
Чето тебе никто не пишет, я поиграл, анончик, прикольно, но у меня подтормаживает камера на сильном компе.
>>55334
А ты где то писал что ты сам перемножаешь матрицы? Я вот такого не припомню, поэтому отвечаю только в рамках дефолт использования движка.
А ты где то писал что ты сам перемножаешь матрицы? Я вот такого не припомню, поэтому отвечаю только в рамках дефолт использования движка.
15 Кб, 733x52>>55309
Хуану пойди расскажи, куда он лёг и чем он дрочит. Пикрелейтед официальный шаблон скрипта CharacterBody. Подставь его в свою боевую картиночку. Триггерится он, ишь ты. Валерьянки выпей.
> Ты меня сразу извини, но это меня триггерит:
> Лёг в ванну спагетти и дрочишь синглтоном?
Хуану пойди расскажи, куда он лёг и чем он дрочит. Пикрелейтед официальный шаблон скрипта CharacterBody. Подставь его в свою боевую картиночку. Триггерится он, ишь ты. Валерьянки выпей.
>>55336
Дело не в силе компа. Я сейчас на слабом проверил.
Камера летает бодро, но ловит стандартные годотовские пропуки.
Берёшь и хуячишь рандомно васд летая по всей карте пока не словишь все пропуки, тогда камера начинает бодро и без пропуков летать.
Я запустил только первую мисию и поймал примрено 10 фризов на карте и она перестала фризить после этого.
А летала изначально быстро.
Это не баг, это фича движка, ему всегда надо пропукаться и неважно какой у тебя комп.
Дело не в силе компа. Я сейчас на слабом проверил.
Камера летает бодро, но ловит стандартные годотовские пропуки.
Берёшь и хуячишь рандомно васд летая по всей карте пока не словишь все пропуки, тогда камера начинает бодро и без пропуков летать.
Я запустил только первую мисию и поймал примрено 10 фризов на карте и она перестала фризить после этого.
А летала изначально быстро.
Это не баг, это фича движка, ему всегда надо пропукаться и неважно какой у тебя комп.
>>55344
Две вещи которые стоит оптимизировать:
Если 3-я версия движка, или gl версия в 4-ке, то надо использовать аддоны из шапки для прекомпиляции шейдеров. Еще был вариант с убершейдером, не пробовал.
Во-вторых, если делаешь средне-крупную игру, обязательно делать настройку качества текстур. На некропека это то, что у меня реально убрало пропуки. Я в своей демке накидывал все скачанные с инета ассеты, а в них часто бездумно закинуты 4К текстуры да еще нескольких видов. Видеопамять заканчивалась, поэтому когда поворачиаешь головой, текстуры вновь увиденных объектов начинают загружаться по узкой шине, вытесняя текстуры виденных.
По возможности убрать прозрачность. Самое страшное было от столика с пачкой стаканов и чайником.
Две вещи которые стоит оптимизировать:
Если 3-я версия движка, или gl версия в 4-ке, то надо использовать аддоны из шапки для прекомпиляции шейдеров. Еще был вариант с убершейдером, не пробовал.
Во-вторых, если делаешь средне-крупную игру, обязательно делать настройку качества текстур. На некропека это то, что у меня реально убрало пропуки. Я в своей демке накидывал все скачанные с инета ассеты, а в них часто бездумно закинуты 4К текстуры да еще нескольких видов. Видеопамять заканчивалась, поэтому когда поворачиаешь головой, текстуры вновь увиденных объектов начинают загружаться по узкой шине, вытесняя текстуры виденных.
По возможности убрать прозрачность. Самое страшное было от столика с пачкой стаканов и чайником.
>>55354
Да нихуя он не делает. Это пукошизик из пукотреда. Пункул в кулачок, занюхнул и прибежал к нам в тред срать.
Да нихуя он не делает. Это пукошизик из пукотреда. Пункул в кулачок, занюхнул и прибежал к нам в тред срать.
>>55358
Ну так совет всем тем кто делает, очевидно.
Ну так совет всем тем кто делает, очевидно.
>>55278
Я вообще считаю, что "смена сцены" подходит только для каких-то супер простых игр, например, на джем. Ну и нубасов учить, конечно, чтобы им не заморачиваться с комплексными системами раньше времени.
>>55275
Вот как я реализую сохранение. По крайней мере, в одной относительно большой (для соло-индюка) игре я это реализовал, и оно успешно работает без ошибок.
Есть общий словарь состояний. В нём хранится всякое, что игрок может по ходу игры поменять. Например, инфа всякие сюжетные триггеры.
Уровень имеет функцию save(), эта функция возвращает своё словарь состояний уровня. Кладём словари состояний уровней в общий словарь состояний.
Все сохраняемые ноды внутри уровня принадлежат к группе save. Внутри функции save() уровня есть что-то типа:
var nodedata = {}
for node in get_tree().get_nodes_in_group("save"):
. var path = get_path_to(node)
. if node.has_method("save"):
. . nodedata[path] = node.save()
. else:
. . nodedata[path] = default_save(node)
Ну и, соответственно, у каждой сохраняемой ноды реализована своя функция save(), которая возвращает словарь. Эта функция пишет какие-то существенные для данной конкретной ноды данные и только их. Ну или defaullt_save(node) возвращает словарь с какими-то стандартными данными, типа позиции, например. Смотря что ты сочтёшь важным для сохранения.
По итогу имеем словарь всех состояний, и выглядит он как-то так:
var global_state = {
. data1="blabla",
. data2="blublu",
. current_level = "level1"
. level_data = {
. . level1 = {
. . . node1 = {position = Vector3(1, 2, 3)},
. . . node2 = {hp = 99, text = "hui"},
. . },
. . level2 = {},
. },
}
Всё, осталось любым нравящимся способом сериализовать этот словарь (например, через var_to_bytes или через JSON.stringify, есть ещё варианты на выбор) и записать его в файл.
Для загрузки, надеюсь, не надо логику расписывать? Просто всё то же самое в обратном порядке - читаешь, десериализуешь, рекурсивно скармливаешь функциям, восстанавливающим состояния, соответствующие под-словари.
Данный метод достаточно гибкий, позволяет сохранять что угодно. Сюда же можно всунуть сохранение игрока, инвентаря, сюжетных квестов и так далее. Но, конечно, серьёзный недостаток - для каждой сохраняемой ноды надо вручную описывать функцию save(). Надо ж всё-таки как-то объяснить игре, какие переменные важны и следует писать в файл, а какие надо переинициализировать заново каждый раз.
Я вообще считаю, что "смена сцены" подходит только для каких-то супер простых игр, например, на джем. Ну и нубасов учить, конечно, чтобы им не заморачиваться с комплексными системами раньше времени.
>>55275
Вот как я реализую сохранение. По крайней мере, в одной относительно большой (для соло-индюка) игре я это реализовал, и оно успешно работает без ошибок.
Есть общий словарь состояний. В нём хранится всякое, что игрок может по ходу игры поменять. Например, инфа всякие сюжетные триггеры.
Уровень имеет функцию save(), эта функция возвращает своё словарь состояний уровня. Кладём словари состояний уровней в общий словарь состояний.
Все сохраняемые ноды внутри уровня принадлежат к группе save. Внутри функции save() уровня есть что-то типа:
var nodedata = {}
for node in get_tree().get_nodes_in_group("save"):
. var path = get_path_to(node)
. if node.has_method("save"):
. . nodedata[path] = node.save()
. else:
. . nodedata[path] = default_save(node)
Ну и, соответственно, у каждой сохраняемой ноды реализована своя функция save(), которая возвращает словарь. Эта функция пишет какие-то существенные для данной конкретной ноды данные и только их. Ну или defaullt_save(node) возвращает словарь с какими-то стандартными данными, типа позиции, например. Смотря что ты сочтёшь важным для сохранения.
По итогу имеем словарь всех состояний, и выглядит он как-то так:
var global_state = {
. data1="blabla",
. data2="blublu",
. current_level = "level1"
. level_data = {
. . level1 = {
. . . node1 = {position = Vector3(1, 2, 3)},
. . . node2 = {hp = 99, text = "hui"},
. . },
. . level2 = {},
. },
}
Всё, осталось любым нравящимся способом сериализовать этот словарь (например, через var_to_bytes или через JSON.stringify, есть ещё варианты на выбор) и записать его в файл.
Для загрузки, надеюсь, не надо логику расписывать? Просто всё то же самое в обратном порядке - читаешь, десериализуешь, рекурсивно скармливаешь функциям, восстанавливающим состояния, соответствующие под-словари.
Данный метод достаточно гибкий, позволяет сохранять что угодно. Сюда же можно всунуть сохранение игрока, инвентаря, сюжетных квестов и так далее. Но, конечно, серьёзный недостаток - для каждой сохраняемой ноды надо вручную описывать функцию save(). Надо ж всё-таки как-то объяснить игре, какие переменные важны и следует писать в файл, а какие надо переинициализировать заново каждый раз.
>>55278
Я вообще считаю, что "смена сцены" подходит только для каких-то супер простых игр, например, на джем. Ну и нубасов учить, конечно, чтобы им не заморачиваться с комплексными системами раньше времени.
>>55275
Вот как я реализую сохранение. По крайней мере, в одной относительно большой (для соло-индюка) игре я это реализовал, и оно успешно работает без ошибок.
Есть общий словарь состояний. В нём хранится всякое, что игрок может по ходу игры поменять. Например, инфа всякие сюжетные триггеры.
Уровень имеет функцию save(), эта функция возвращает своё словарь состояний уровня. Кладём словари состояний уровней в общий словарь состояний.
Все сохраняемые ноды внутри уровня принадлежат к группе save. Внутри функции save() уровня есть что-то типа:
var nodedata = {}
for node in get_tree().get_nodes_in_group("save"):
. var path = get_path_to(node)
. if node.has_method("save"):
. . nodedata[path] = node.save()
. else:
. . nodedata[path] = default_save(node)
Ну и, соответственно, у каждой сохраняемой ноды реализована своя функция save(), которая возвращает словарь. Эта функция пишет какие-то существенные для данной конкретной ноды данные и только их. Ну или defaullt_save(node) возвращает словарь с какими-то стандартными данными, типа позиции, например. Смотря что ты сочтёшь важным для сохранения.
По итогу имеем словарь всех состояний, и выглядит он как-то так:
var global_state = {
. data1="blabla",
. data2="blublu",
. current_level = "level1"
. level_data = {
. . level1 = {
. . . node1 = {position = Vector3(1, 2, 3)},
. . . node2 = {hp = 99, text = "hui"},
. . },
. . level2 = {},
. },
}
Всё, осталось любым нравящимся способом сериализовать этот словарь (например, через var_to_bytes или через JSON.stringify, есть ещё варианты на выбор) и записать его в файл.
Для загрузки, надеюсь, не надо логику расписывать? Просто всё то же самое в обратном порядке - читаешь, десериализуешь, рекурсивно скармливаешь функциям, восстанавливающим состояния, соответствующие под-словари.
Данный метод достаточно гибкий, позволяет сохранять что угодно. Сюда же можно всунуть сохранение игрока, инвентаря, сюжетных квестов и так далее. Но, конечно, серьёзный недостаток - для каждой сохраняемой ноды надо вручную описывать функцию save(). Надо ж всё-таки как-то объяснить игре, какие переменные важны и следует писать в файл, а какие надо переинициализировать заново каждый раз.
Я вообще считаю, что "смена сцены" подходит только для каких-то супер простых игр, например, на джем. Ну и нубасов учить, конечно, чтобы им не заморачиваться с комплексными системами раньше времени.
>>55275
Вот как я реализую сохранение. По крайней мере, в одной относительно большой (для соло-индюка) игре я это реализовал, и оно успешно работает без ошибок.
Есть общий словарь состояний. В нём хранится всякое, что игрок может по ходу игры поменять. Например, инфа всякие сюжетные триггеры.
Уровень имеет функцию save(), эта функция возвращает своё словарь состояний уровня. Кладём словари состояний уровней в общий словарь состояний.
Все сохраняемые ноды внутри уровня принадлежат к группе save. Внутри функции save() уровня есть что-то типа:
var nodedata = {}
for node in get_tree().get_nodes_in_group("save"):
. var path = get_path_to(node)
. if node.has_method("save"):
. . nodedata[path] = node.save()
. else:
. . nodedata[path] = default_save(node)
Ну и, соответственно, у каждой сохраняемой ноды реализована своя функция save(), которая возвращает словарь. Эта функция пишет какие-то существенные для данной конкретной ноды данные и только их. Ну или defaullt_save(node) возвращает словарь с какими-то стандартными данными, типа позиции, например. Смотря что ты сочтёшь важным для сохранения.
По итогу имеем словарь всех состояний, и выглядит он как-то так:
var global_state = {
. data1="blabla",
. data2="blublu",
. current_level = "level1"
. level_data = {
. . level1 = {
. . . node1 = {position = Vector3(1, 2, 3)},
. . . node2 = {hp = 99, text = "hui"},
. . },
. . level2 = {},
. },
}
Всё, осталось любым нравящимся способом сериализовать этот словарь (например, через var_to_bytes или через JSON.stringify, есть ещё варианты на выбор) и записать его в файл.
Для загрузки, надеюсь, не надо логику расписывать? Просто всё то же самое в обратном порядке - читаешь, десериализуешь, рекурсивно скармливаешь функциям, восстанавливающим состояния, соответствующие под-словари.
Данный метод достаточно гибкий, позволяет сохранять что угодно. Сюда же можно всунуть сохранение игрока, инвентаря, сюжетных квестов и так далее. Но, конечно, серьёзный недостаток - для каждой сохраняемой ноды надо вручную описывать функцию save(). Надо ж всё-таки как-то объяснить игре, какие переменные важны и следует писать в файл, а какие надо переинициализировать заново каждый раз.
>>55378
Ну в общем-то, это метод из документации, просто причёсан тобой по твоему вкусу. У этого метода есть существенный недостаток: запрос сохранения / загрузки выходит дорогим. В одном фрейме происходит вызов множества функций save в группе. Мне этот метод не понравился. Я предпочитаю, чтобы ноды динамически обновляли свои данные в var global_state, а при запросе сохранения вот он словарик уже готовый, лочишь запись в него, сериализуешь, готово.
Алсо, метод из документации предлагает писать в сейв-файл специфичную движкоинформацию - пути нод. А они там нежелательны. Бритва Оккама.
Ну в общем-то, это метод из документации, просто причёсан тобой по твоему вкусу. У этого метода есть существенный недостаток: запрос сохранения / загрузки выходит дорогим. В одном фрейме происходит вызов множества функций save в группе. Мне этот метод не понравился. Я предпочитаю, чтобы ноды динамически обновляли свои данные в var global_state, а при запросе сохранения вот он словарик уже готовый, лочишь запись в него, сериализуешь, готово.
Алсо, метод из документации предлагает писать в сейв-файл специфичную движкоинформацию - пути нод. А они там нежелательны. Бритва Оккама.
Ебаная работа отнимает все жизненные силы, сил делать игру вообще нет. Уже пару недель не касался проекта... Благо скоро уволюсь нахуй
367 Кб, 866x515>>55399
Двощую, как пидорнули с работы прогресс за неделю больше, чем за полгода ковыряния в свободное от галер время.
Двощую, как пидорнули с работы прогресс за неделю больше, чем за полгода ковыряния в свободное от галер время.
>>55414
Как в твоей голове из первой строки гринтекста получилась вторая? Как ты вместо "динамически" в своей голове вообразил "принудительно все свойства"? Интересна логическая цепь.
> >ноды динамически обновляли свои данные
> Как ты предлагаешь сохранять пули в шутере?
Как в твоей голове из первой строки гринтекста получилась вторая? Как ты вместо "динамически" в своей голове вообразил "принудительно все свойства"? Интересна логическая цепь.
>>55428
Какие данные нужны летящему снаряду?
- тип (ускорение, урон, траектория...);
- кто выпустил (для очков, френдлифаера...);
- где, куда и с какой скоростью летит.
Первые два достаточно записать один раз, но как минимум два вектора обновляются постоянно.
При этом снаряды - динамические объекты, они создаются игрой где-то и потом удаляются из дерева сцены, так что тебе нужно хранить адрес для размещения снарядов на загрузке игры.
Можно сделать менеджер снарядов, который будет управлять сохранением, загрузкой и полётом всех имеющихся снарядов, абстрагируя их от системы сохранения. Но это нарушает твой принцип "запись исключительно в глобальный синглтон отовсюду".
А если взять мобов/NPC, там ещё больше разных нетривиальных данных, что часто обновляются и должны всегда сохраняться по запросу игрока.
Так что глобальное хранилище длинных ключей подходит только мелким пошаговым игрушкам: визуальным новеллам всяким, пойнт-н-кликам.
Нет, если ты затачиваешь код под конкретную игру, продуманную до мелочей - может, не запутаешься, но лучше делать с возможностью повторного использования, особенно делая не пойми что.
И я не спорю, что на синглтонах удобно говнокодить, накидывая километры строк каждый день. Но потом разгребать это всё, распутывать очень неудобно.
>принудительно все свойства
Какие данные нужны летящему снаряду?
- тип (ускорение, урон, траектория...);
- кто выпустил (для очков, френдлифаера...);
- где, куда и с какой скоростью летит.
Первые два достаточно записать один раз, но как минимум два вектора обновляются постоянно.
При этом снаряды - динамические объекты, они создаются игрой где-то и потом удаляются из дерева сцены, так что тебе нужно хранить адрес для размещения снарядов на загрузке игры.
Можно сделать менеджер снарядов, который будет управлять сохранением, загрузкой и полётом всех имеющихся снарядов, абстрагируя их от системы сохранения. Но это нарушает твой принцип "запись исключительно в глобальный синглтон отовсюду".
А если взять мобов/NPC, там ещё больше разных нетривиальных данных, что часто обновляются и должны всегда сохраняться по запросу игрока.
Так что глобальное хранилище длинных ключей подходит только мелким пошаговым игрушкам: визуальным новеллам всяким, пойнт-н-кликам.
Нет, если ты затачиваешь код под конкретную игру, продуманную до мелочей - может, не запутаешься, но лучше делать с возможностью повторного использования, особенно делая не пойми что.
И я не спорю, что на синглтонах удобно говнокодить, накидывая километры строк каждый день. Но потом разгребать это всё, распутывать очень неудобно.
А годот позволяет вставить видео? Ну вот есть у меня интро в .мп4, можно его как то прикрутить к сцене без костылей?
>>55439
Да, есть готовые компоненты, только мп4 нужно перекрдировать
Да, есть готовые компоненты, только мп4 нужно перекрдировать
>>55439
Буквально первая ссылка по запросу "Godot video":
https://docs.godotengine.org/en/stable/tutorials/animation/playing_videos.html
Буквально первая ссылка по запросу "Godot video":
https://docs.godotengine.org/en/stable/tutorials/animation/playing_videos.html
>>55435
Мой принцип не
Вышеописанный принцип (не мой, он старше меня лет на 10) менеджера сохранений не обязывает создавать синглтон. Вполне реально создавать его экземпляр при старте игровой сессии и сообщать ссылку на него всем нодам, которые желают сохранять какие-либо данные.
Еще раз: >>55341 это у Хуана редактор Годота мелкий проект? Напишешь клон Годота на пару вечеров, м? Ведь именно ProjectSettings выглядит ровно так же. А еще, если вспомнить, работа с анимационными стейтмашинами из кода так же реализована.
Алсо, именно для крупных проектов нужны разветвлённые древовидные базы данных. Мелким проектам подойдёт одноуровневый ассоциативный массив.
Хорошо, давай разумно подойдём к проблеме. Критикуя предлагай. Как ещё ты предложишь обращаться к определённой ветви древовидной структуры, кроме как указанием её полного или относительного пути в дереве?
Мой принцип не
Вышеописанный принцип (не мой, он старше меня лет на 10) менеджера сохранений не обязывает создавать синглтон. Вполне реально создавать его экземпляр при старте игровой сессии и сообщать ссылку на него всем нодам, которые желают сохранять какие-либо данные.
> глобальное хранилище длинных ключей подходит только мелким пошаговым игрушкам
Еще раз: >>55341 это у Хуана редактор Годота мелкий проект? Напишешь клон Годота на пару вечеров, м? Ведь именно ProjectSettings выглядит ровно так же. А еще, если вспомнить, работа с анимационными стейтмашинами из кода так же реализована.
Алсо, именно для крупных проектов нужны разветвлённые древовидные базы данных. Мелким проектам подойдёт одноуровневый ассоциативный массив.
Хорошо, давай разумно подойдём к проблеме. Критикуя предлагай. Как ещё ты предложишь обращаться к определённой ветви древовидной структуры, кроме как указанием её полного или относительного пути в дереве?
>>55454
Еще планирую сделать сериализацию в XML на имеющемся в движке базовом парсере, там будет возможность прописывать каждой ноде и чайлды и параметры. ЖСОН так не может без костылей.
Еще планирую сделать сериализацию в XML на имеющемся в движке базовом парсере, там будет возможность прописывать каждой ноде и чайлды и параметры. ЖСОН так не может без костылей.
>>55393
А, да? Видимо, очень давно его осваивал, забыл, что по доке делал.
Энивей, документация хуйни не посоветует.
Ну, тут смотря какой геймплей и когда вызывается сохранение и как много опрашиваемых объектов. У меня между уровнями, да и нод для сохранения от силы пара десятков наберётся.
Можно составить манифест, где алиасы/IDы нод будут сопоставлены их путям. И в сейв-файл писать не пути, а эти алиасы/IDы.
Но мне кажется, это лишняя заморочка просто для удовлетворения внутреннего перфекционизма. Не могу себе представить реальный кейс уровня /gd/, где бы она была оправдана. Какой-то долгоиграющий игросервис, который в процессе жизненного цикла может поменять движок. Лично я таких не делаю.
>метод из документации, просто причёсан тобой по твоему вкусу
А, да? Видимо, очень давно его осваивал, забыл, что по доке делал.
Энивей, документация хуйни не посоветует.
>запрос сохранения / загрузки выходит дорогим
Ну, тут смотря какой геймплей и когда вызывается сохранение и как много опрашиваемых объектов. У меня между уровнями, да и нод для сохранения от силы пара десятков наберётся.
>писать в сейв-файл специфичную движкоинформацию - пути нод.
Можно составить манифест, где алиасы/IDы нод будут сопоставлены их путям. И в сейв-файл писать не пути, а эти алиасы/IDы.
Но мне кажется, это лишняя заморочка просто для удовлетворения внутреннего перфекционизма. Не могу себе представить реальный кейс уровня /gd/, где бы она была оправдана. Какой-то долгоиграющий игросервис, который в процессе жизненного цикла может поменять движок. Лично я таких не делаю.
>>55459
Если ты что-то поменял в порядке нод в процессе доработки игры - старые сохранения автоматом становятся неработоспособны. Я это в голове держу, когда высказываюсь против записи в файл сохранения движкоспецифичной инфы. Если же там будут IDы объектов в твоей собственной терминологии, то со старыми сейвами проблем будет меньше. Это опять же, как сделать.
> Не могу себе представить реальный кейс уровня
Если ты что-то поменял в порядке нод в процессе доработки игры - старые сохранения автоматом становятся неработоспособны. Я это в голове держу, когда высказываюсь против записи в файл сохранения движкоспецифичной инфы. Если же там будут IDы объектов в твоей собственной терминологии, то со старыми сейвами проблем будет меньше. Это опять же, как сделать.
>>55478
Это для тебя умные слова? Чел, ты где-нибудь учился, что-нибудь читал в своей жизни?
Если тебе до 12 лет, то еще ладно.
Это для тебя умные слова? Чел, ты где-нибудь учился, что-нибудь читал в своей жизни?
Если тебе до 12 лет, то еще ладно.
>>55454
Почему бы тогда не разделить его на несколько менеджеров в разных частях игры, которые затем объединяют всё накопленное добро в одну кучу?
Да чё ты к нему прицепился. Из настроек проекта ты раз в три года гравитацию достаёшь и больше о нём не вспоминаешь, пока не доделаешь игру и не приступишь к прикручиванию меню опций (где эти настройки изменяются игроком один раз за все 5000 часов геймплея, если не изменял ПК).
А у тебя совсем другое, ты непрерывно какие-то сомнительные данные туда кидаешь, и должен мочь достать те же данные обратно. При этом сцены в проекте за время разработки гоняются туда-сюда и на одном месте редко задерживаются, и тебе не захочется каждый раз распутывать все связи.
ProjectSettings ты никуда не выкинешь, не изменишь, гравитация там всегда в одном месте, и доступ к нему чрезвычайно редкий. Так что хрен с ним, работает - и ладно, у движка есть более серьёзные проблемы.
Это вообще совсем другое. Ты настраиваешь ноду AnimationTree где-то рядом с моделькой, создаёшь скрипт, управляющий анимациями, и обращаешься снаружи только к своему скрипту (от его родителя). Никакого глобального доступа из случайных мест.
Базы данных чего?
Так ведь Dictionary и есть древовидный, но ты не указываешь полный путь в дереве, а получаешь отдельную веточку, которая тебе нужна.
>>55455
Зачем? XML тяжёлый, медленный и не нужен.
В JSON любые данные сохранить можно.
hjson: https://hjson.github.io/try.html
NodeName: {
class: Node
children: { Node1: {}, Node2: {}, Node3: {} }
script: my_node.gd
exports: { my_var: 0 }
}
>>55481
Это легко решается версиями игры:
Версии 0.x могут ломать сейвы как хотят.
Версии 1.x должны зафиксировать сейвы.
Версия 2.x и старше могут ломать один раз.
Версии до 1.0 - альфы, версии после 1.0 - патчи.
Версию 2.0 делаем только когда очень нужно всем игрокам сломать сейвы, моды и прочее.
Кто не хочет - сидит на старой версии.
Вот если твоя система сохранения совсем ломает игру, если ты изменил порядок нод - вот это уже большая проблема, тогда ты ничего изменить не можешь без переделывания всей системы.
>Вполне реально создавать его экземпляр при старте игровой сессии и сообщать ссылку на него всем нодам, которые желают сохранять какие-либо данные.
Почему бы тогда не разделить его на несколько менеджеров в разных частях игры, которые затем объединяют всё накопленное добро в одну кучу?
>у Хуана редактор Годота
>ProjectSettings
Да чё ты к нему прицепился. Из настроек проекта ты раз в три года гравитацию достаёшь и больше о нём не вспоминаешь, пока не доделаешь игру и не приступишь к прикручиванию меню опций (где эти настройки изменяются игроком один раз за все 5000 часов геймплея, если не изменял ПК).
А у тебя совсем другое, ты непрерывно какие-то сомнительные данные туда кидаешь, и должен мочь достать те же данные обратно. При этом сцены в проекте за время разработки гоняются туда-сюда и на одном месте редко задерживаются, и тебе не захочется каждый раз распутывать все связи.
ProjectSettings ты никуда не выкинешь, не изменишь, гравитация там всегда в одном месте, и доступ к нему чрезвычайно редкий. Так что хрен с ним, работает - и ладно, у движка есть более серьёзные проблемы.
>работа с анимационными стейтмашинами
Это вообще совсем другое. Ты настраиваешь ноду AnimationTree где-то рядом с моделькой, создаёшь скрипт, управляющий анимациями, и обращаешься снаружи только к своему скрипту (от его родителя). Никакого глобального доступа из случайных мест.
>именно для крупных проектов нужны разветвлённые древовидные базы данных
Базы данных чего?
>Как ещё ты предложишь обращаться к определённой ветви древовидной структуры, кроме как указанием её полного или относительного пути в дереве?
Так ведь Dictionary и есть древовидный, но ты не указываешь полный путь в дереве, а получаешь отдельную веточку, которая тебе нужна.
>>55455
>сериализацию в XML
Зачем? XML тяжёлый, медленный и не нужен.
>ЖСОН так не может
В JSON любые данные сохранить можно.
>прописывать каждой ноде и чайлды и параметры
hjson: https://hjson.github.io/try.html
NodeName: {
class: Node
children: { Node1: {}, Node2: {}, Node3: {} }
script: my_node.gd
exports: { my_var: 0 }
}
>>55481
>поменял в порядке нод в процессе доработки
>старые сохранения неработоспособны
Это легко решается версиями игры:
Версии 0.x могут ломать сейвы как хотят.
Версии 1.x должны зафиксировать сейвы.
Версия 2.x и старше могут ломать один раз.
Версии до 1.0 - альфы, версии после 1.0 - патчи.
Версию 2.0 делаем только когда очень нужно всем игрокам сломать сейвы, моды и прочее.
Кто не хочет - сидит на старой версии.
Вот если твоя система сохранения совсем ломает игру, если ты изменил порядок нод - вот это уже большая проблема, тогда ты ничего изменить не можешь без переделывания всей системы.
>>55454
Почему бы тогда не разделить его на несколько менеджеров в разных частях игры, которые затем объединяют всё накопленное добро в одну кучу?
Да чё ты к нему прицепился. Из настроек проекта ты раз в три года гравитацию достаёшь и больше о нём не вспоминаешь, пока не доделаешь игру и не приступишь к прикручиванию меню опций (где эти настройки изменяются игроком один раз за все 5000 часов геймплея, если не изменял ПК).
А у тебя совсем другое, ты непрерывно какие-то сомнительные данные туда кидаешь, и должен мочь достать те же данные обратно. При этом сцены в проекте за время разработки гоняются туда-сюда и на одном месте редко задерживаются, и тебе не захочется каждый раз распутывать все связи.
ProjectSettings ты никуда не выкинешь, не изменишь, гравитация там всегда в одном месте, и доступ к нему чрезвычайно редкий. Так что хрен с ним, работает - и ладно, у движка есть более серьёзные проблемы.
Это вообще совсем другое. Ты настраиваешь ноду AnimationTree где-то рядом с моделькой, создаёшь скрипт, управляющий анимациями, и обращаешься снаружи только к своему скрипту (от его родителя). Никакого глобального доступа из случайных мест.
Базы данных чего?
Так ведь Dictionary и есть древовидный, но ты не указываешь полный путь в дереве, а получаешь отдельную веточку, которая тебе нужна.
>>55455
Зачем? XML тяжёлый, медленный и не нужен.
В JSON любые данные сохранить можно.
hjson: https://hjson.github.io/try.html
NodeName: {
class: Node
children: { Node1: {}, Node2: {}, Node3: {} }
script: my_node.gd
exports: { my_var: 0 }
}
>>55481
Это легко решается версиями игры:
Версии 0.x могут ломать сейвы как хотят.
Версии 1.x должны зафиксировать сейвы.
Версия 2.x и старше могут ломать один раз.
Версии до 1.0 - альфы, версии после 1.0 - патчи.
Версию 2.0 делаем только когда очень нужно всем игрокам сломать сейвы, моды и прочее.
Кто не хочет - сидит на старой версии.
Вот если твоя система сохранения совсем ломает игру, если ты изменил порядок нод - вот это уже большая проблема, тогда ты ничего изменить не можешь без переделывания всей системы.
>Вполне реально создавать его экземпляр при старте игровой сессии и сообщать ссылку на него всем нодам, которые желают сохранять какие-либо данные.
Почему бы тогда не разделить его на несколько менеджеров в разных частях игры, которые затем объединяют всё накопленное добро в одну кучу?
>у Хуана редактор Годота
>ProjectSettings
Да чё ты к нему прицепился. Из настроек проекта ты раз в три года гравитацию достаёшь и больше о нём не вспоминаешь, пока не доделаешь игру и не приступишь к прикручиванию меню опций (где эти настройки изменяются игроком один раз за все 5000 часов геймплея, если не изменял ПК).
А у тебя совсем другое, ты непрерывно какие-то сомнительные данные туда кидаешь, и должен мочь достать те же данные обратно. При этом сцены в проекте за время разработки гоняются туда-сюда и на одном месте редко задерживаются, и тебе не захочется каждый раз распутывать все связи.
ProjectSettings ты никуда не выкинешь, не изменишь, гравитация там всегда в одном месте, и доступ к нему чрезвычайно редкий. Так что хрен с ним, работает - и ладно, у движка есть более серьёзные проблемы.
>работа с анимационными стейтмашинами
Это вообще совсем другое. Ты настраиваешь ноду AnimationTree где-то рядом с моделькой, создаёшь скрипт, управляющий анимациями, и обращаешься снаружи только к своему скрипту (от его родителя). Никакого глобального доступа из случайных мест.
>именно для крупных проектов нужны разветвлённые древовидные базы данных
Базы данных чего?
>Как ещё ты предложишь обращаться к определённой ветви древовидной структуры, кроме как указанием её полного или относительного пути в дереве?
Так ведь Dictionary и есть древовидный, но ты не указываешь полный путь в дереве, а получаешь отдельную веточку, которая тебе нужна.
>>55455
>сериализацию в XML
Зачем? XML тяжёлый, медленный и не нужен.
>ЖСОН так не может
В JSON любые данные сохранить можно.
>прописывать каждой ноде и чайлды и параметры
hjson: https://hjson.github.io/try.html
NodeName: {
class: Node
children: { Node1: {}, Node2: {}, Node3: {} }
script: my_node.gd
exports: { my_var: 0 }
}
>>55481
>поменял в порядке нод в процессе доработки
>старые сохранения неработоспособны
Это легко решается версиями игры:
Версии 0.x могут ломать сейвы как хотят.
Версии 1.x должны зафиксировать сейвы.
Версия 2.x и старше могут ломать один раз.
Версии до 1.0 - альфы, версии после 1.0 - патчи.
Версию 2.0 делаем только когда очень нужно всем игрокам сломать сейвы, моды и прочее.
Кто не хочет - сидит на старой версии.
Вот если твоя система сохранения совсем ломает игру, если ты изменил порядок нод - вот это уже большая проблема, тогда ты ничего изменить не можешь без переделывания всей системы.
>>55481
Так это, игра зарелизена? Или всё ещё в разработке? Если в разработке, то похеру, сохранения поломаются только у меня. Если зарелизена - то явно никто уровни перепиливать уже не будет.
А если уровни перепиливаются после релиза, то это игра-сервис уже получается. Не уровень /gd/.
Ну или ранний доступ. Но это рак. Кто таким занимается, мы таких обоссываем. Игра должна быть готовой на релизе. Ранний доступ это альфатест за ваши деньги, и никто не гарантирует, что сейвы не поломаются.
>поменял в порядке нод в процессе доработки игры
Так это, игра зарелизена? Или всё ещё в разработке? Если в разработке, то похеру, сохранения поломаются только у меня. Если зарелизена - то явно никто уровни перепиливать уже не будет.
А если уровни перепиливаются после релиза, то это игра-сервис уже получается. Не уровень /gd/.
Ну или ранний доступ. Но это рак. Кто таким занимается, мы таких обоссываем. Игра должна быть готовой на релизе. Ранний доступ это альфатест за ваши деньги, и никто не гарантирует, что сейвы не поломаются.
>>55497
Ну, допустим, не только, но и у плейтестеров, но:
Тут полностью согласен, альфа на то и альфа.
Вот Godot - хорошая игра. Всегда предупреждают, что альфа-версии могут поломать сейвы (проекты).
Почему нет? Пилить можно бесконечно для души. Некоторые инди проекты живут больше 20 лет.
Лол, кто сказал? А если ранний доступ бесплатно? И вообще, мы бы не смогли поиграть во многие интересные проекты, не будь раннего доступа.
Вот пример, давно играл, в целом нравилось:
https://store.steampowered.com/app/251570/
- больше 10 лет в раннем доступе, и только весной 2024 они начали планировать выход 1.0:
Алсо, о сейвах:
Отзывы об игре:
Теперь представь, что они вместо раннего доступа в 2013 держали бы игру у себя, кормя народ пустыми обещаниями "как круто будет, когда сделаем релиз", только в 2024 выпустили свой кубач, когда все уже наигрались в майн, выросли, женились, умерли.
Ранний доступ - благо. А мошенников везде полно.
>Если в разработке, то похеру, сохранения поломаются только у меня.
Ну, допустим, не только, но и у плейтестеров, но:
>альфатест - не гарантирует, что сейвы не поломаются
Тут полностью согласен, альфа на то и альфа.
Вот Godot - хорошая игра. Всегда предупреждают, что альфа-версии могут поломать сейвы (проекты).
>А если уровни перепиливаются после релиза, то это игра-сервис уже получается. Не уровень /gd/.
Почему нет? Пилить можно бесконечно для души. Некоторые инди проекты живут больше 20 лет.
>ранний доступ - это рак, мы таких обоссываем
Лол, кто сказал? А если ранний доступ бесплатно? И вообще, мы бы не смогли поиграть во многие интересные проекты, не будь раннего доступа.
Вот пример, давно играл, в целом нравилось:
https://store.steampowered.com/app/251570/
- больше 10 лет в раннем доступе, и только весной 2024 они начали планировать выход 1.0:
>Q: Why release now?
>A: We have been developing 7 Days for nearly 12 years and have had over twenty large scale early access releases that have brought the game to a significantly different place and quality than where it began. <...> The Fun Pimps have and will continue to support 7 Days to Die development with a majority of their resources.
Алсо, о сейвах:
>Q: Save incompatibility between console versions? Also, will there still be Save incompatibility between patches?
>A: Due to the technical architecture of 7 Days to Die’s game engine, users will have to start a new game with each major update. Eventually, this will not be the case.
Отзывы об игре:
>Очень положительные (88% из 217,324)
Теперь представь, что они вместо раннего доступа в 2013 держали бы игру у себя, кормя народ пустыми обещаниями "как круто будет, когда сделаем релиз", только в 2024 выпустили свой кубач, когда все уже наигрались в майн, выросли, женились, умерли.
Ранний доступ - благо. А мошенников везде полно.
>>55497
Ну, допустим, не только, но и у плейтестеров, но:
Тут полностью согласен, альфа на то и альфа.
Вот Godot - хорошая игра. Всегда предупреждают, что альфа-версии могут поломать сейвы (проекты).
Почему нет? Пилить можно бесконечно для души. Некоторые инди проекты живут больше 20 лет.
Лол, кто сказал? А если ранний доступ бесплатно? И вообще, мы бы не смогли поиграть во многие интересные проекты, не будь раннего доступа.
Вот пример, давно играл, в целом нравилось:
https://store.steampowered.com/app/251570/
- больше 10 лет в раннем доступе, и только весной 2024 они начали планировать выход 1.0:
Алсо, о сейвах:
Отзывы об игре:
Теперь представь, что они вместо раннего доступа в 2013 держали бы игру у себя, кормя народ пустыми обещаниями "как круто будет, когда сделаем релиз", только в 2024 выпустили свой кубач, когда все уже наигрались в майн, выросли, женились, умерли.
Ранний доступ - благо. А мошенников везде полно.
>Если в разработке, то похеру, сохранения поломаются только у меня.
Ну, допустим, не только, но и у плейтестеров, но:
>альфатест - не гарантирует, что сейвы не поломаются
Тут полностью согласен, альфа на то и альфа.
Вот Godot - хорошая игра. Всегда предупреждают, что альфа-версии могут поломать сейвы (проекты).
>А если уровни перепиливаются после релиза, то это игра-сервис уже получается. Не уровень /gd/.
Почему нет? Пилить можно бесконечно для души. Некоторые инди проекты живут больше 20 лет.
>ранний доступ - это рак, мы таких обоссываем
Лол, кто сказал? А если ранний доступ бесплатно? И вообще, мы бы не смогли поиграть во многие интересные проекты, не будь раннего доступа.
Вот пример, давно играл, в целом нравилось:
https://store.steampowered.com/app/251570/
- больше 10 лет в раннем доступе, и только весной 2024 они начали планировать выход 1.0:
>Q: Why release now?
>A: We have been developing 7 Days for nearly 12 years and have had over twenty large scale early access releases that have brought the game to a significantly different place and quality than where it began. <...> The Fun Pimps have and will continue to support 7 Days to Die development with a majority of their resources.
Алсо, о сейвах:
>Q: Save incompatibility between console versions? Also, will there still be Save incompatibility between patches?
>A: Due to the technical architecture of 7 Days to Die’s game engine, users will have to start a new game with each major update. Eventually, this will not be the case.
Отзывы об игре:
>Очень положительные (88% из 217,324)
Теперь представь, что они вместо раннего доступа в 2013 держали бы игру у себя, кормя народ пустыми обещаниями "как круто будет, когда сделаем релиз", только в 2024 выпустили свой кубач, когда все уже наигрались в майн, выросли, женились, умерли.
Ранний доступ - благо. А мошенников везде полно.
>>54699 (OP)
Стоит ли вообще постить в этот ИТТ тред свои успехи на Godot или это только раздражает?
Стоит ли вообще постить в этот ИТТ тред свои успехи на Godot или это только раздражает?
Ебаная прокрастинация, кликер по факту готов на 90% осталась нудятина которую я благополучно откладываю каждый раз на завтра. Кучу времени убил еще на юай, думал лучше будет если стилево все сделаю, а как оказалось вышло дерьмецо, пришлось вернуться к дефолтной теме которой как оказалось более чем достаточно для того что хотел.
Возьму волю в кулак и за сегодня постараюсь доделать уже, слишком уж дохуя времени я нихуя не делаю.
Кстати, видел итт или в прошлом жалобу на локаллайт в четверке, и тащемто удваиваю, чзх, в моем пиксельном долгострое таже хуйня, разрешение текстуры света никак на это не влияет, тени тоже, фпс тупо падает до 30 с нихуя, причем если центр камеры выйдет из зоны освещения то фпс возвращается к 60 и это при том что эти же источники света все еще в зоне видимости. Я в движке по сути еще нуфаня, поэтому как фиксить хуй его знает, а почему так происходит тем более, гуглить пытался но тщетно. Это на глес3 ес че такое, как на форварде это работает не тестил, мб там нормально все. Забыл добавить что это в канвасмод только так, на вьюпорт и дисейбл все работает отлично в 60 фпс. Надеюсь в 4.3 пофиксят, и надеюсь добавят возможность делать веб билды без SAB, я хоть и к тройке привык уже, но буду честным, по сравнению с четверкой это обрубок.
Возьму волю в кулак и за сегодня постараюсь доделать уже, слишком уж дохуя времени я нихуя не делаю.
Кстати, видел итт или в прошлом жалобу на локаллайт в четверке, и тащемто удваиваю, чзх, в моем пиксельном долгострое таже хуйня, разрешение текстуры света никак на это не влияет, тени тоже, фпс тупо падает до 30 с нихуя, причем если центр камеры выйдет из зоны освещения то фпс возвращается к 60 и это при том что эти же источники света все еще в зоне видимости. Я в движке по сути еще нуфаня, поэтому как фиксить хуй его знает, а почему так происходит тем более, гуглить пытался но тщетно. Это на глес3 ес че такое, как на форварде это работает не тестил, мб там нормально все. Забыл добавить что это в канвасмод только так, на вьюпорт и дисейбл все работает отлично в 60 фпс. Надеюсь в 4.3 пофиксят, и надеюсь добавят возможность делать веб билды без SAB, я хоть и к тройке привык уже, но буду честным, по сравнению с четверкой это обрубок.
>>55563
Классика. http://ru.wikipedia.org/wiki/Закон_Парето
В чём проблема была? Вроде всё просто.
Што? Имхо, 2D свет в плане теней вообще сплошной косяк (пробовал в 3.x).
Не понимаю весь этот дрочь на тени в 2D играх, если не клон террарии...
>кликер по факту готов на 90% осталась нудятина
Классика. http://ru.wikipedia.org/wiki/Закон_Парето
>20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата
>Кучу времени убил еще на юай
В чём проблема была? Вроде всё просто.
>локаллайт
Што? Имхо, 2D свет в плане теней вообще сплошной косяк (пробовал в 3.x).
Не понимаю весь этот дрочь на тени в 2D играх, если не клон террарии...
456 Кб, 948x584Крч.
Впереди вырисовывается долгая пауза из-за множества ассетов которые придется сделать. Так что решил не тянуть и пернул своим СХ на реддит, следующий если будет то очень не скоро.
Впереди вырисовывается долгая пауза из-за множества ассетов которые придется сделать. Так что решил не тянуть и пернул своим СХ на реддит, следующий если будет то очень не скоро.
>>55572
В стиле. То что было в голове совершенно не вписалось в визуал игры.
Поинтлайт бтв.
Да на тени пох вообще, узнать бы с какого хуя фпс падает из за дефолтного света.
>В чём проблема была?
В стиле. То что было в голове совершенно не вписалось в визуал игры.
>>локаллайт
Поинтлайт бтв.
>Не понимаю весь этот дрочь на тени в 2D играх
Да на тени пох вообще, узнать бы с какого хуя фпс падает из за дефолтного света.
11 Кб, 808x194В чём проблема сделать @export var anything: Variant?
4.3 уже всё, теперь только 4.4 ждать. В 4.3 только костыль:
@export_custom(PROPERTY_HINT_NONE, "") var my_var: Variant
4.3 уже всё, теперь только 4.4 ждать. В 4.3 только костыль:
@export_custom(PROPERTY_HINT_NONE, "") var my_var: Variant
>>55577
А ты прям в редакторе проекта делал?
Обычно сначала делают концепт UI - в спец софте, в пейнте, на бумаге, хоть на салфетке...
Там же пиксели перемножаются, затраты неизбежны, больше пикселей - больше трат.
>>55563
Проверил на 4.3-beta1, в GLES3 и Forward+ одинаково 1500+ фпс независимо от света.
Смотри, что и как там у тебя отображается кроме собственно источников света.
>То что было в голове совершенно не вписалось в визуал игры.
А ты прям в редакторе проекта делал?
Обычно сначала делают концепт UI - в спец софте, в пейнте, на бумаге, хоть на салфетке...
>фпс падает из за дефолтного света
Там же пиксели перемножаются, затраты неизбежны, больше пикселей - больше трат.
>>55563
>в четверке
>фпс тупо падает до 30
>фпс возвращается к 60
>Это на глес3 ес че такое, как на форварде это работает не тестил
>Надеюсь в 4.3 пофиксят
Проверил на 4.3-beta1, в GLES3 и Forward+ одинаково 1500+ фпс независимо от света.
Смотри, что и как там у тебя отображается кроме собственно источников света.
>>55636
Ты обознался
Ты обознался
>>55519
Пиздец. 12 лет кормить людей кривым недоделанным говном и стричь бабло. Отзывы положительные: ну да, ну подождём ещё немножечко, и игра будет готова, а щас ранний доступ, ну простим ей, что она багованная, надо просто потерпеть.
Сука. Высшая степень мудачества и лицемерия - выкидывать продукт в магазин и 12 лет притворяться, что это не готовый продукт, за который ты хочешь бабло, а просто ну вот демка для выставки. Когда беседка выкатывает фоллаут 76 без неписей, еле работающий от багов, её даже метка раннего доступа не спасёт - говном закидают. Когда то же самое делает нонейм индюк - ну тут молодец чо, высрал нам кусочек счастья, спасибо. Хотя шо то игра-сервис для долговременного кормления, шо это. Никакой разницы.
А покажи мне хоть один ранний доступ бесплатно без ссылки на донат.
Пиздец. 12 лет кормить людей кривым недоделанным говном и стричь бабло. Отзывы положительные: ну да, ну подождём ещё немножечко, и игра будет готова, а щас ранний доступ, ну простим ей, что она багованная, надо просто потерпеть.
Сука. Высшая степень мудачества и лицемерия - выкидывать продукт в магазин и 12 лет притворяться, что это не готовый продукт, за который ты хочешь бабло, а просто ну вот демка для выставки. Когда беседка выкатывает фоллаут 76 без неписей, еле работающий от багов, её даже метка раннего доступа не спасёт - говном закидают. Когда то же самое делает нонейм индюк - ну тут молодец чо, высрал нам кусочек счастья, спасибо. Хотя шо то игра-сервис для долговременного кормления, шо это. Никакой разницы.
>А если ранний доступ бесплатно?
А покажи мне хоть один ранний доступ бесплатно без ссылки на донат.
Очень глупый вопрос, но ответа ни в одном гайде для вкатунов я пока не нашел. Какое разрешение экрана в настройках проекта ставить? Дефолтное или побольше, хотя бы фуллхд? Насколько это важно? Есть у меня предчувствие, что потом заколебусь все переделывать, если на старте этим вопросом не озабочусь.
>>55694
Плохо искал, лалка. Учись читать документацию.
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
Всё в порядке, переделать несложно.
>ответа ни в одном гайде не нашел
Плохо искал, лалка. Учись читать документацию.
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
>потом заколебусь все переделывать
Всё в порядке, переделать несложно.
>>55691
Вот годная бесплатная игра, донат символический:
https://store.steampowered.com/app/304930/
Прошла три/четыре стадии:
- режимы игры в роблоксе - я тогда о нём не знал
- кривая юнити-поделка 0.x-1.x? - тут не уверен
- кривая юнити-поделка 2.x - я в это играл
- ровная юнити-поделка 3.x - тоже играл
Суммарно где-то... лет -дцать? Раньше 2014 начал.
Геймплей лучше большинства ААА шутеров.
Думаю, на Godot можно сделать не хуже.
Ну, а люди и не против. Играть-то можно.
Чего? Играй. Вот ждали киберпук77 - дождались...
Разница огромная:
- инди = превозмогатор трудностей;
- ААА = просираторы полимеров.
Первым уважение, вторым нет прощения.
Ещё есть стар ситизен - это развод "китов" на бабки.
>ранний доступ бесплатно без ссылки на донат
Вот годная бесплатная игра, донат символический:
https://store.steampowered.com/app/304930/
Прошла три/четыре стадии:
- режимы игры в роблоксе - я тогда о нём не знал
- кривая юнити-поделка 0.x-1.x? - тут не уверен
- кривая юнити-поделка 2.x - я в это играл
- ровная юнити-поделка 3.x - тоже играл
Суммарно где-то... лет -дцать? Раньше 2014 начал.
Геймплей лучше большинства ААА шутеров.
Думаю, на Godot можно сделать не хуже.
>12 лет кормить людей кривым
Ну, а люди и не против. Играть-то можно.
>подождём ещё немножечко
Чего? Играй. Вот ждали киберпук77 - дождались...
>фоллаут 76
>говном закидают
>нонейм индюк - ну тут молодец чо
>Никакой разницы.
Разница огромная:
- инди = превозмогатор трудностей;
- ААА = просираторы полимеров.
Первым уважение, вторым нет прощения.
Ещё есть стар ситизен - это развод "китов" на бабки.
>>55691
Вот годная бесплатная игра, донат символический:
https://store.steampowered.com/app/304930/
Прошла три/четыре стадии:
- режимы игры в роблоксе - я тогда о нём не знал
- кривая юнити-поделка 0.x-1.x? - тут не уверен
- кривая юнити-поделка 2.x - я в это играл
- ровная юнити-поделка 3.x - тоже играл
Суммарно где-то... лет -дцать? Раньше 2014 начал.
Геймплей лучше большинства ААА шутеров.
Думаю, на Godot можно сделать не хуже.
Ну, а люди и не против. Играть-то можно.
Чего? Играй. Вот ждали киберпук77 - дождались...
Разница огромная:
- инди = превозмогатор трудностей;
- ААА = просираторы полимеров.
Первым уважение, вторым нет прощения.
Ещё есть стар ситизен - это развод "китов" на бабки.
>ранний доступ бесплатно без ссылки на донат
Вот годная бесплатная игра, донат символический:
https://store.steampowered.com/app/304930/
Прошла три/четыре стадии:
- режимы игры в роблоксе - я тогда о нём не знал
- кривая юнити-поделка 0.x-1.x? - тут не уверен
- кривая юнити-поделка 2.x - я в это играл
- ровная юнити-поделка 3.x - тоже играл
Суммарно где-то... лет -дцать? Раньше 2014 начал.
Геймплей лучше большинства ААА шутеров.
Думаю, на Godot можно сделать не хуже.
>12 лет кормить людей кривым
Ну, а люди и не против. Играть-то можно.
>подождём ещё немножечко
Чего? Играй. Вот ждали киберпук77 - дождались...
>фоллаут 76
>говном закидают
>нонейм индюк - ну тут молодец чо
>Никакой разницы.
Разница огромная:
- инди = превозмогатор трудностей;
- ААА = просираторы полимеров.
Первым уважение, вторым нет прощения.
Ещё есть стар ситизен - это развод "китов" на бабки.
Немного притормаживает, но в целом играбельно.
>>55562
Ты сам напросился.
>>55562
>Раздражает остальных - пости.
Ты сам напросился.
Вышел Godot Manager 0.2.6.
Уже почти не падает.
Всем, кому нужно держать N проектов на M версиях движка, и не переживать насчёт внезапного коррапта случайным открытием проекта не в той версии.
Уже почти не падает.
Всем, кому нужно держать N проектов на M версиях движка, и не переживать насчёт внезапного коррапта случайным открытием проекта не в той версии.
>>55956
Нет, не для этого.
Нет, не для этого.
40 Кб, 807x619>>55955
Так это она и есть. Godot Physics ощутимо медленнее.
В сцене 56 RigidBody3D летают + 56 AnimatableBody3D потомками привязаны, однако, физически ни с чем не сталкиваются. Если отключить все AnimatableBody3D, будет >75 FPS, но мне они нужны по задумке: внешний RigidBody3D прост как кирпич, а внутренние сложные коллизии отдельным слоем для игрока и неписей. Но мне достаточно будет парочку сложных пепелацев, остальное физическое должно быть намного проще устроено, так что на видео преувеличенная нагрузка.
...плюс там анимированные генераторы частиц. Неожиданно, но их влияние не так уж и высоко. AnimatableBody3D съедают больше 75% времени. Переключение на StaticBody3D лучше не делает. Понимаю, двигать статики вообще не ок. Нужно попробовать один лайфхак с телепортацией...
>Jolt физику
Так это она и есть. Godot Physics ощутимо медленнее.
В сцене 56 RigidBody3D летают + 56 AnimatableBody3D потомками привязаны, однако, физически ни с чем не сталкиваются. Если отключить все AnimatableBody3D, будет >75 FPS, но мне они нужны по задумке: внешний RigidBody3D прост как кирпич, а внутренние сложные коллизии отдельным слоем для игрока и неписей. Но мне достаточно будет парочку сложных пепелацев, остальное физическое должно быть намного проще устроено, так что на видео преувеличенная нагрузка.
...плюс там анимированные генераторы частиц. Неожиданно, но их влияние не так уж и высоко. AnimatableBody3D съедают больше 75% времени. Переключение на StaticBody3D лучше не делает. Понимаю, двигать статики вообще не ок. Нужно попробовать один лайфхак с телепортацией...
>>55949
Палю лайфхак, как не запутаться в версиях:
1. У тебя две отдельных папки:
- папка Godot с редакторами;
- папка Projects с проектами.
2. В папке проектов делаешь ярлык, указывающий на редактор нужной версии и нужную папку проекта. Можно разместить ярлык прямо в папке проекта.
3. Называешь ярлык подходящим именем:
4. Открываешь проекты только через эти ярлыки. Открывается Godot Editor, во встроенный менеджер проектов ничего не попадает, если сам не добавлял.
5. Для апгрейда проекта на новую версию:
- Ctrl+C/Ctrl+V по старому ярлыку;
- изменяешь в параметрах 4.2.2 на 4.3;
- запускаешь проект кликом по новому ярлыку.
6. Также можно сделать ярлык на запуск игры. Без экспортирования, без редактора - нажал и играешь.
Мне лично всё равно приходится папку проекта открывать, чтобы закинуть туда текстуры, модельки. Почему бы не сделать ярлыки на редактор там же?
>Всем, кому нужно держать N проектов на M версиях движка, и не переживать насчёт внезапного коррапта случайным открытием проекта не в той версии.
Палю лайфхак, как не запутаться в версиях:
1. У тебя две отдельных папки:
- папка Godot с редакторами;
- папка Projects с проектами.
2. В папке проектов делаешь ярлык, указывающий на редактор нужной версии и нужную папку проекта. Можно разместить ярлык прямо в папке проекта.
3. Называешь ярлык подходящим именем:
>Edit Project AAA with Godot 3.6.beta
>Edit Project Beta with Godot 4.2.2
>Edit Tests with Godot 4.3.beta
4. Открываешь проекты только через эти ярлыки. Открывается Godot Editor, во встроенный менеджер проектов ничего не попадает, если сам не добавлял.
5. Для апгрейда проекта на новую версию:
- Ctrl+C/Ctrl+V по старому ярлыку;
- изменяешь в параметрах 4.2.2 на 4.3;
- запускаешь проект кликом по новому ярлыку.
6. Также можно сделать ярлык на запуск игры. Без экспортирования, без редактора - нажал и играешь.
Мне лично всё равно приходится папку проекта открывать, чтобы закинуть туда текстуры, модельки. Почему бы не сделать ярлыки на редактор там же?
>>56012
1. install godot-manager
2. внутри него install godot's нужных версий
3. Добавляешь проект, прописываешь ему нужную версию.
ПРОФИТ!
3 пункта против 6 твоих, пердолинга с ярлыками. Палит он лайфхак. Пиздец просто.
1. install godot-manager
2. внутри него install godot's нужных версий
3. Добавляешь проект, прописываешь ему нужную версию.
ПРОФИТ!
3 пункта против 6 твоих, пердолинга с ярлыками. Палит он лайфхак. Пиздец просто.
>>56079
Лишняя зависимость с багами и тормозами.
Качаю сборки с официального сайта, а не васянки.
А потом у твоего godot-manager конфиг ломается.
Настроил несколько лет назад и до сих пор юзаю стабильно, пока ты ждёшь багфиксы: >>55949
Лол, "почти" - это сколько раз в день?
Ты просто не представляешь, как это круто, когда ты ПРОСТО кликаешь на ярлык на рабочем столе и твой проект моментально запускается на выполнение или в редакторе, без лишних шагов в куче менеджеров.
Мои пункты займут пару минут один раз, а твои замедляют запуск проекта регулярно, да требуют багфиксов от падений. И вообще это юнитячество.
>install godot-manager
Лишняя зависимость с багами и тормозами.
>внутри него install godot's нужных версий
Качаю сборки с официального сайта, а не васянки.
>Добавляешь проект, прописываешь
А потом у твоего godot-manager конфиг ломается.
>пердолинга с ярлыками.
Настроил несколько лет назад и до сих пор юзаю стабильно, пока ты ждёшь багфиксы: >>55949
>Уже почти не падает.
Лол, "почти" - это сколько раз в день?
Ты просто не представляешь, как это круто, когда ты ПРОСТО кликаешь на ярлык на рабочем столе и твой проект моментально запускается на выполнение или в редакторе, без лишних шагов в куче менеджеров.
>3 пункта против 6 твоих
Мои пункты займут пару минут один раз, а твои замедляют запуск проекта регулярно, да требуют багфиксов от падений. И вообще это юнитячество.
>>56082
Не продолжай, я понял, что ты Игорян.
>Ехал васян через реку
>Видит васян в реке васян
>Сунул васян васян в васян
>Васян васян васян васян
Не продолжай, я понял, что ты Игорян.
143 Кб, 1280x1024Это пыздэц анон, сидел двигал я ползунки значит, корректировал формулы, как вдруг пидоры оффнули свет, и че ты думаешь, наебнулся блять телек который юзал вместо моника, врубается и через секунду оффается картинка, такая хуйня и до этого была, только выключение и включение помогало, а сейчас нихуя.. Откопал старый 4:3 моник, ебать все конечно непривычно мелкое, пикрил чтоб понятней было, еще и блять квадрат этот ебаный, я хуй знает как теперь адекватно работать, видимо придется ближайшие пару месяцев ахуеть как терпеть ибо позволить новый пока не могу. Похуй, пляшем.
Кликер кстати готов, осталось яндекс прибить гвозядми, и аудиолибу прикрутить, да юай немного доредачить и можно уже релизить.
Кликер кстати готов, осталось яндекс прибить гвозядми, и аудиолибу прикрутить, да юай немного доредачить и можно уже релизить.
>>56089
Диды на калькуляторах игры программировали. И ты сможешь! Тем более твой проект не проебался и не закорраптился.
А вообще ибп прикупи, когда-нибудь в будущем.
Диды на калькуляторах игры программировали. И ты сможешь! Тем более твой проект не проебался и не закорраптился.
А вообще ибп прикупи, когда-нибудь в будущем.
>>56089
С телевизором всё ок. Нужно предохранитель пофиксить. В инторнете погугли статейки. Это копейки будет стоить.
>врубается и через секунду оффается картинка
С телевизором всё ок. Нужно предохранитель пофиксить. В инторнете погугли статейки. Это копейки будет стоить.
5 Кб, 473x454Сап анон, я хочу сделать средневековый лоуполи 3Д экшон с мечами.
Из фичей мне необходимы:
1. Тулзы для процедурной анимации скелетал мешей
2. Что-то что поможет реализовать расчленёнку
3. Хорошая система коллизий чтобы детектить когда меч касается меша игрока или нпц
В годоте это всё имеется?
Из фичей мне необходимы:
1. Тулзы для процедурной анимации скелетал мешей
2. Что-то что поможет реализовать расчленёнку
3. Хорошая система коллизий чтобы детектить когда меч касается меша игрока или нпц
В годоте это всё имеется?
>>56151
Да.
Да.
>>56089
Конденсаторы проверь. Блоку питания необходимо зарядить конденсаторы, если конденсаторы засохли или протекли, нормально включиться БП не сможет. Электролитические конденсаторы сохнут неизбежно, это наименее долговечный компонент (~15 лет).
Нажми Ctrl + Shift + F11. Я забиндил на просто F11.
https://docs.godotengine.org/en/stable/tutorials/editor/default_key_mapping.html#general-editor-actions
Можно вынести редактор кода в отдельное окно:
https://docs.godotengine.org/en/stable/tutorials/editor/customizing_editor.html#splitting-the-script-or-shader-editor-to-its-own-window
>врубается и через секунду оффается картинка, такая хуйня и до этого была, только выключение и включение помогало, а сейчас нихуя
Конденсаторы проверь. Блоку питания необходимо зарядить конденсаторы, если конденсаторы засохли или протекли, нормально включиться БП не сможет. Электролитические конденсаторы сохнут неизбежно, это наименее долговечный компонент (~15 лет).
>блять квадрат этот ебаный
Нажми Ctrl + Shift + F11. Я забиндил на просто F11.
https://docs.godotengine.org/en/stable/tutorials/editor/default_key_mapping.html#general-editor-actions
Можно вынести редактор кода в отдельное окно:
https://docs.godotengine.org/en/stable/tutorials/editor/customizing_editor.html#splitting-the-script-or-shader-editor-to-its-own-window
>>56147
Нормально, Godot потянет, видел такие демки.
Всё норм, можно анимировать процедурно.
Какие тебе тулзы, если анимации процедурные? Процедурные анимации - это анимации кодом, как замена ручным анимациям или motion capture.
Если ты про регдолл, для него есть встроенные функции, однако, с ним придётся повозиться...
Расчленёнка в играх бывает двух видов:
1. Части тела заранее отделены друг от друга и могут отделяться только в определённых местах. Дёшево и сердито, подходит 99% играм, но художнику нужно повозиться, создавая отдельные части тел. Какой-то особенный код тут не нужен, всё достаточно просто. Гарантированно нет проблем с анимациями мешей.
2. Цельный меш процедурно разрезается в реальном времени. Код сложный, багов много, будет нагружать компьютер игрока, разрезы нереалистичные. Зато достаточно накинуть скрипт. Видел аддоны:
https://github.com/PiCode9560/Godot-4-Concave-Mesh-Slicer
https://youtu.be/_yqTljJ0mW0
Не знаю, будет ли это работать с анимациями.
Тут довольно интересная ситуация.
Разработчики официально признают, что физический движок, встроенный в Godot, кривой и косой, так что официально рассматривают внедрение нового (Jolt). Однако, ты уже сейчас можешь попробовать его сам:
https://github.com/godot-jolt/godot-jolt
Достаточно закинуть нужную dll-ку.
Впрочем, встроенный физический движок вполне способен справиться с простыми задачами. Да, он медленный, да, глючит в определённых ситуациях, однако, его вполне хватает для быстрого прототипа, особенно когда ты от него ничего не ожидаешь.
Также есть другие альтернативы, можешь PhysX прикрутить или Havok, но они вроде как платные. Возможно прикрутить Bullet, но у него свои косяки, поэтому от него избавились при переходе на 4.0.
Короче, о физике не волнуйся - она есть, а при острой необходимости её можно заменить альтернативной.
>средневековый лоуполи 3Д экшон с мечами
Нормально, Godot потянет, видел такие демки.
>процедурной анимации скелетал мешей
Всё норм, можно анимировать процедурно.
>тулзы
Какие тебе тулзы, если анимации процедурные? Процедурные анимации - это анимации кодом, как замена ручным анимациям или motion capture.
Если ты про регдолл, для него есть встроенные функции, однако, с ним придётся повозиться...
>поможет реализовать расчленёнку
Расчленёнка в играх бывает двух видов:
1. Части тела заранее отделены друг от друга и могут отделяться только в определённых местах. Дёшево и сердито, подходит 99% играм, но художнику нужно повозиться, создавая отдельные части тел. Какой-то особенный код тут не нужен, всё достаточно просто. Гарантированно нет проблем с анимациями мешей.
2. Цельный меш процедурно разрезается в реальном времени. Код сложный, багов много, будет нагружать компьютер игрока, разрезы нереалистичные. Зато достаточно накинуть скрипт. Видел аддоны:
https://github.com/PiCode9560/Godot-4-Concave-Mesh-Slicer
https://youtu.be/_yqTljJ0mW0
Не знаю, будет ли это работать с анимациями.
>Хорошая система коллизий чтобы детектить когда меч касается меша игрока или нпц
Тут довольно интересная ситуация.
Разработчики официально признают, что физический движок, встроенный в Godot, кривой и косой, так что официально рассматривают внедрение нового (Jolt). Однако, ты уже сейчас можешь попробовать его сам:
https://github.com/godot-jolt/godot-jolt
Достаточно закинуть нужную dll-ку.
Впрочем, встроенный физический движок вполне способен справиться с простыми задачами. Да, он медленный, да, глючит в определённых ситуациях, однако, его вполне хватает для быстрого прототипа, особенно когда ты от него ничего не ожидаешь.
Также есть другие альтернативы, можешь PhysX прикрутить или Havok, но они вроде как платные. Возможно прикрутить Bullet, но у него свои косяки, поэтому от него избавились при переходе на 4.0.
Короче, о физике не волнуйся - она есть, а при острой необходимости её можно заменить альтернативной.
>>56147
Нормально, Godot потянет, видел такие демки.
Всё норм, можно анимировать процедурно.
Какие тебе тулзы, если анимации процедурные? Процедурные анимации - это анимации кодом, как замена ручным анимациям или motion capture.
Если ты про регдолл, для него есть встроенные функции, однако, с ним придётся повозиться...
Расчленёнка в играх бывает двух видов:
1. Части тела заранее отделены друг от друга и могут отделяться только в определённых местах. Дёшево и сердито, подходит 99% играм, но художнику нужно повозиться, создавая отдельные части тел. Какой-то особенный код тут не нужен, всё достаточно просто. Гарантированно нет проблем с анимациями мешей.
2. Цельный меш процедурно разрезается в реальном времени. Код сложный, багов много, будет нагружать компьютер игрока, разрезы нереалистичные. Зато достаточно накинуть скрипт. Видел аддоны:
https://github.com/PiCode9560/Godot-4-Concave-Mesh-Slicer
https://youtu.be/_yqTljJ0mW0
Не знаю, будет ли это работать с анимациями.
Тут довольно интересная ситуация.
Разработчики официально признают, что физический движок, встроенный в Godot, кривой и косой, так что официально рассматривают внедрение нового (Jolt). Однако, ты уже сейчас можешь попробовать его сам:
https://github.com/godot-jolt/godot-jolt
Достаточно закинуть нужную dll-ку.
Впрочем, встроенный физический движок вполне способен справиться с простыми задачами. Да, он медленный, да, глючит в определённых ситуациях, однако, его вполне хватает для быстрого прототипа, особенно когда ты от него ничего не ожидаешь.
Также есть другие альтернативы, можешь PhysX прикрутить или Havok, но они вроде как платные. Возможно прикрутить Bullet, но у него свои косяки, поэтому от него избавились при переходе на 4.0.
Короче, о физике не волнуйся - она есть, а при острой необходимости её можно заменить альтернативной.
>средневековый лоуполи 3Д экшон с мечами
Нормально, Godot потянет, видел такие демки.
>процедурной анимации скелетал мешей
Всё норм, можно анимировать процедурно.
>тулзы
Какие тебе тулзы, если анимации процедурные? Процедурные анимации - это анимации кодом, как замена ручным анимациям или motion capture.
Если ты про регдолл, для него есть встроенные функции, однако, с ним придётся повозиться...
>поможет реализовать расчленёнку
Расчленёнка в играх бывает двух видов:
1. Части тела заранее отделены друг от друга и могут отделяться только в определённых местах. Дёшево и сердито, подходит 99% играм, но художнику нужно повозиться, создавая отдельные части тел. Какой-то особенный код тут не нужен, всё достаточно просто. Гарантированно нет проблем с анимациями мешей.
2. Цельный меш процедурно разрезается в реальном времени. Код сложный, багов много, будет нагружать компьютер игрока, разрезы нереалистичные. Зато достаточно накинуть скрипт. Видел аддоны:
https://github.com/PiCode9560/Godot-4-Concave-Mesh-Slicer
https://youtu.be/_yqTljJ0mW0
Не знаю, будет ли это работать с анимациями.
>Хорошая система коллизий чтобы детектить когда меч касается меша игрока или нпц
Тут довольно интересная ситуация.
Разработчики официально признают, что физический движок, встроенный в Godot, кривой и косой, так что официально рассматривают внедрение нового (Jolt). Однако, ты уже сейчас можешь попробовать его сам:
https://github.com/godot-jolt/godot-jolt
Достаточно закинуть нужную dll-ку.
Впрочем, встроенный физический движок вполне способен справиться с простыми задачами. Да, он медленный, да, глючит в определённых ситуациях, однако, его вполне хватает для быстрого прототипа, особенно когда ты от него ничего не ожидаешь.
Также есть другие альтернативы, можешь PhysX прикрутить или Havok, но они вроде как платные. Возможно прикрутить Bullet, но у него свои косяки, поэтому от него избавились при переходе на 4.0.
Короче, о физике не волнуйся - она есть, а при острой необходимости её можно заменить альтернативной.
>>56167
Например контрол риг с инверс кинематикой, чтобы я не задавал IK вручную. Если есть еще заранее заданные функции для контрол рига типа aimAt ваще круто будет.
Правильный вопрос будет ли это работать с скелетал мешами. Но это уже что-то, спасибо.
Пичалька, а че там редко возникает потребность коллизии детектить? В целом могу и сам прикрутить, всё-таки тот факт что годот опен-сурс это серьезное преимущество для такого как я, который никому ничего не хочет быть должен.
>Какие тебе тулзы, если анимации процедурные? Процедурные анимации - это анимации кодом, как замена ручным анимациям или motion capture.
Например контрол риг с инверс кинематикой, чтобы я не задавал IK вручную. Если есть еще заранее заданные функции для контрол рига типа aimAt ваще круто будет.
>Не знаю, будет ли это работать с анимациями.
Правильный вопрос будет ли это работать с скелетал мешами. Но это уже что-то, спасибо.
>Разработчики официально признают, что физический движок, встроенный в Godot, кривой и косой, так что официально рассматривают внедрение нового (Jolt). Однако, ты уже сейчас можешь попробовать его сам:
Пичалька, а че там редко возникает потребность коллизии детектить? В целом могу и сам прикрутить, всё-таки тот факт что годот опен-сурс это серьезное преимущество для такого как я, который никому ничего не хочет быть должен.
>>56176
Пока что всё не очень, есть только это:
https://docs.godotengine.org/en/stable/classes/class_skeletonik3d.html
Но оно давно deprecated. Вот старое демо:
https://godotengine.org/asset-library/asset/523
Можно поискать аддоны с готовым кодом IK.
Там проблемы такого уровня:
- при движении по стыкам можно подскочить;
- бывает лютая тряска, особенно в джойнтах;
- не тянет 100500 ригидбоди, максимум ~1500.
Фиксили-фиксили, но всё ещё далеко до идеала.
>инверс кинематикой
Пока что всё не очень, есть только это:
https://docs.godotengine.org/en/stable/classes/class_skeletonik3d.html
Но оно давно deprecated. Вот старое демо:
https://godotengine.org/asset-library/asset/523
Можно поискать аддоны с готовым кодом IK.
>редко возникает потребность коллизии детектить?
Там проблемы такого уровня:
- при движении по стыкам можно подскочить;
- бывает лютая тряска, особенно в джойнтах;
- не тянет 100500 ригидбоди, максимум ~1500.
Фиксили-фиксили, но всё ещё далеко до идеала.
>>56176
Ещё есть известная проблема производительности рейкастов, из-за того, что они при запросе из кода формируют ответ большим словарём (Dictionary), существенно ограничивая число запросов. При том сторонние языки (C#, C++) тут ничем не помогут - бутылочное горлышко в API физической системы.
Т.е. ты можешь кинуть несколько сотен рейкастов в один кадр, прежде чем у тебя ФПС упадёт ниже 60, в то время как в других движках ты мог бы кинуть намного больше за один кадр. Кто-то это считает критическим недостатком и даже высрал пост с критикой, но всем остальным норм, потому что так много рейкастов практически никому не нужно.
Ещё есть известная проблема производительности рейкастов, из-за того, что они при запросе из кода формируют ответ большим словарём (Dictionary), существенно ограничивая число запросов. При том сторонние языки (C#, C++) тут ничем не помогут - бутылочное горлышко в API физической системы.
Т.е. ты можешь кинуть несколько сотен рейкастов в один кадр, прежде чем у тебя ФПС упадёт ниже 60, в то время как в других движках ты мог бы кинуть намного больше за один кадр. Кто-то это считает критическим недостатком и даже высрал пост с критикой, но всем остальным норм, потому что так много рейкастов практически никому не нужно.
Игры-то делаете?
>>55334
жутко.
жутко.
>>54699 (OP)
Здравствуйте, пилю, ради самобучения, свой клон vampire survivors (если что я в него никогда не играл, только слышал). Так вот, возник вопрос что лучше использовать CharacterBody2d или же Area2D, гугление и чтение доступных сигналов подсказало, что мне нужно использовать и то и то. Первое из-за удобный поддержки и передвижения и для коллайда с границами карты и прочими препятствиями, а второе, что бы детектить попадания и прочие регистрации урона. Только вот и Character body и Area2D требуют CollisionShape, и фигачить у одного обекта сразу две одинаковые ноды колиизии выглядит максимально костыльно. Так и надо или же существует способ сделать так, что бы обе ноды работали с одной и той же нодой коллизии?
Здравствуйте, пилю, ради самобучения, свой клон vampire survivors (если что я в него никогда не играл, только слышал). Так вот, возник вопрос что лучше использовать CharacterBody2d или же Area2D, гугление и чтение доступных сигналов подсказало, что мне нужно использовать и то и то. Первое из-за удобный поддержки и передвижения и для коллайда с границами карты и прочими препятствиями, а второе, что бы детектить попадания и прочие регистрации урона. Только вот и Character body и Area2D требуют CollisionShape, и фигачить у одного обекта сразу две одинаковые ноды колиизии выглядит максимально костыльно. Так и надо или же существует способ сделать так, что бы обе ноды работали с одной и той же нодой коллизии?
>>56347
А как тогда? У Characterbody и Colisionshape нету сигнала body_entered, а именно он нужен, что бы регистрировать дамаги.
А как тогда? У Characterbody и Colisionshape нету сигнала body_entered, а именно он нужен, что бы регистрировать дамаги.
>>56349
Используй is_colliding из рейкаста прикрепленного к пуле для вызова функции хит в чарбоди или любом другом коллайдере.
Используй is_colliding из рейкаста прикрепленного к пуле для вызова функции хит в чарбоди или любом другом коллайдере.
>>56352
Ну так дамажат не только "пули", а ещё сами враги, если ходить через них, плюс всякие слеши и другие объемные прожектайлы которые будет запускать игрок.
Ну так дамажат не только "пули", а ещё сами враги, если ходить через них, плюс всякие слеши и другие объемные прожектайлы которые будет запускать игрок.
>>56344
Как понимаю, это "буллет хелл наоборот":
1. На карте нет никаких препятствий. Совсем.
2. Мобы свободно наслаиваются друг на друга.
3. Игрок спамит атаками по чётким паттернам.
4. Мобы отлетают за 1-2 попадания от игрока.
5. Весь фан в создании новых паттернов атаки.
Из этого следует, что:
0. Нужно выдать максимум мобов и снарядов.
1. CharacterBody2D тут бесполезен и не нужен.
2. Достаточно Area2D как датчика попаданий.
3. Перемещение в сторону игрока по прямой.
Простейшая композиция сцены:
- Mob/Bullet: Area2D
- - Circle: CollisionShape2D
- - Sprite: AnimatedSprite2D
Area2D настраиваешь так:
1. У мобов: слой - mob, маска: ничего
2. У снарядов: слой: ничего, маска: mob
3. У игрока: слой: ничего, маска: mob
Снаряд бьёт моба, игрок бьётся об моба.
Сами мобы только наводятся на игрока:
Если будет медленно:
1. https://github.com/godot-jolt/godot-jolt
2. Можно попробовать Rect2.has_point()...
3. GDScript медленный, перепиши на C++))))
>vampire survivors
Как понимаю, это "буллет хелл наоборот":
1. На карте нет никаких препятствий. Совсем.
2. Мобы свободно наслаиваются друг на друга.
3. Игрок спамит атаками по чётким паттернам.
4. Мобы отлетают за 1-2 попадания от игрока.
5. Весь фан в создании новых паттернов атаки.
Из этого следует, что:
0. Нужно выдать максимум мобов и снарядов.
1. CharacterBody2D тут бесполезен и не нужен.
2. Достаточно Area2D как датчика попаданий.
3. Перемещение в сторону игрока по прямой.
Простейшая композиция сцены:
- Mob/Bullet: Area2D
- - Circle: CollisionShape2D
- - Sprite: AnimatedSprite2D
Area2D настраиваешь так:
1. У мобов: слой - mob, маска: ничего
2. У снарядов: слой: ничего, маска: mob
3. У игрока: слой: ничего, маска: mob
Снаряд бьёт моба, игрок бьётся об моба.
Сами мобы только наводятся на игрока:
>@export var player: Area2D
>func _physics_process(delta):
> position += position.direction_to(player.position) speed delta
Если будет медленно:
1. https://github.com/godot-jolt/godot-jolt
2. Можно попробовать Rect2.has_point()...
3. GDScript медленный, перепиши на C++))))
>>56344
Как понимаю, это "буллет хелл наоборот":
1. На карте нет никаких препятствий. Совсем.
2. Мобы свободно наслаиваются друг на друга.
3. Игрок спамит атаками по чётким паттернам.
4. Мобы отлетают за 1-2 попадания от игрока.
5. Весь фан в создании новых паттернов атаки.
Из этого следует, что:
0. Нужно выдать максимум мобов и снарядов.
1. CharacterBody2D тут бесполезен и не нужен.
2. Достаточно Area2D как датчика попаданий.
3. Перемещение в сторону игрока по прямой.
Простейшая композиция сцены:
- Mob/Bullet: Area2D
- - Circle: CollisionShape2D
- - Sprite: AnimatedSprite2D
Area2D настраиваешь так:
1. У мобов: слой - mob, маска: ничего
2. У снарядов: слой: ничего, маска: mob
3. У игрока: слой: ничего, маска: mob
Снаряд бьёт моба, игрок бьётся об моба.
Сами мобы только наводятся на игрока:
Если будет медленно:
1. https://github.com/godot-jolt/godot-jolt
2. Можно попробовать Rect2.has_point()...
3. GDScript медленный, перепиши на C++))))
>vampire survivors
Как понимаю, это "буллет хелл наоборот":
1. На карте нет никаких препятствий. Совсем.
2. Мобы свободно наслаиваются друг на друга.
3. Игрок спамит атаками по чётким паттернам.
4. Мобы отлетают за 1-2 попадания от игрока.
5. Весь фан в создании новых паттернов атаки.
Из этого следует, что:
0. Нужно выдать максимум мобов и снарядов.
1. CharacterBody2D тут бесполезен и не нужен.
2. Достаточно Area2D как датчика попаданий.
3. Перемещение в сторону игрока по прямой.
Простейшая композиция сцены:
- Mob/Bullet: Area2D
- - Circle: CollisionShape2D
- - Sprite: AnimatedSprite2D
Area2D настраиваешь так:
1. У мобов: слой - mob, маска: ничего
2. У снарядов: слой: ничего, маска: mob
3. У игрока: слой: ничего, маска: mob
Снаряд бьёт моба, игрок бьётся об моба.
Сами мобы только наводятся на игрока:
>@export var player: Area2D
>func _physics_process(delta):
> position += position.direction_to(player.position) speed delta
Если будет медленно:
1. https://github.com/godot-jolt/godot-jolt
2. Можно попробовать Rect2.has_point()...
3. GDScript медленный, перепиши на C++))))
>>56361
А, не, это ж только для 3D. Для 2D вот это:
https://github.com/appsinacup/godot-rapier
https://appsinacup.com/godot-physics-vs-box2d-vs-rapier2d/
>Jolt
А, не, это ж только для 3D. Для 2D вот это:
https://github.com/appsinacup/godot-rapier
>Parallel support and SIMD build for better performance.
https://appsinacup.com/godot-physics-vs-box2d-vs-rapier2d/
>Performance: Best, about 2x,3x faster than competition
Как же много времени ассеты жрут. Стенка всего-ничего, всрал в нее два дня. И это без наполнения пустых полох.
708 Кб, 480x265>>56363
Чего? Ты её с нуля моделировал что ли?
Тяжёлые у тебя проблемы, конечно.
>Стенка всего-ничего, всрал в нее два дня.
Чего? Ты её с нуля моделировал что ли?
>И это без наполнения пустых полох.
Тяжёлые у тебя проблемы, конечно.
>>56363
А игра-то где?
Моделишь блок будущей стенки джве минуты и продолжаешь кодить геймплей.
> моделил стенку джва дня
А игра-то где?
Моделишь блок будущей стенки джве минуты и продолжаешь кодить геймплей.
2,1 Мб, mp4,1224x688, 0:06
>>56363
Выглядит лампово. Я надеюсь ты не собираешь делать мужика главным гером? Пускай это будет молодая няшная тяночка с длинными волосами.
Выглядит лампово. Я надеюсь ты не собираешь делать мужика главным гером? Пускай это будет молодая няшная тяночка с длинными волосами.
82 Кб, 1077x648>>56377
Кошкодевочку пусть делает. Старая хозяйка умерла и кошкодевочка осталась сама по себе в квартире.
Кошкодевочку пусть делает. Старая хозяйка умерла и кошкодевочка осталась сама по себе в квартире.
>>56377
Надо было оставлять пепу. Теперь игра обречена.
Надо было оставлять пепу. Теперь игра обречена.
3,6 Мб, webm,1280x720, 0:04
>>56395
Да не, текущий вид прикольный, своеобразный.
Слишком мрачно, серьёзно.
Пускай будет няшная кошкодевочка. Старушка хозяйка умерла от старости, без трагедии и прочего. И кошкодевочке теперь нужно присматривать за домом, как-то выживать. Хотя это лучше бы зашло в каком-нибудь деревенском домике с животными.
>вид от первого лица
Да не, текущий вид прикольный, своеобразный.
>у него померла мать и он - ребёнок в пустой квартире
Слишком мрачно, серьёзно.
Пускай будет няшная кошкодевочка. Старушка хозяйка умерла от старости, без трагедии и прочего. И кошкодевочке теперь нужно присматривать за домом, как-то выживать. Хотя это лучше бы зашло в каком-нибудь деревенском домике с животными.
49 Кб, 700x467>>56377
Скорее всего нет. Скорее всего тян лет до 25. Но моделить персонажей это не квадратный шкаф, придется искать. Или плотить.
>Я надеюсь ты не собираешь делать мужика главным гером?
Скорее всего нет. Скорее всего тян лет до 25. Но моделить персонажей это не квадратный шкаф, придется искать. Или плотить.
>>56402
А дорого ли будет стоить такой персонаж? На геймдев.ру наверняка есть какой-нибудь чувак, который за небольшие деньги сделает неплохо.
>Или плотить
А дорого ли будет стоить такой персонаж? На геймдев.ру наверняка есть какой-нибудь чувак, который за небольшие деньги сделает неплохо.
>>56405
Знал автора (в губы не целовался) с ныне почившего форума по блендеру, его модели используют в порнушных модах, играх, артах
https://youtu.be/eFQKoI7aR0Q
Если могёт менее сексуализированно и в стиле ближе к Silent Hill, обращусь.
Думаю влетит в диапазоне 10-50 баксов. Ну или баш на баш, он хотел свою визуальную новеллу пилить. Я ему скелет игровых систем, он мне модельку. Но это вряд ли.
>А дорого ли будет стоить такой персонаж?
Знал автора (в губы не целовался) с ныне почившего форума по блендеру, его модели используют в порнушных модах, играх, артах
https://youtu.be/eFQKoI7aR0Q
Если могёт менее сексуализированно и в стиле ближе к Silent Hill, обращусь.
Думаю влетит в диапазоне 10-50 баксов. Ну или баш на баш, он хотел свою визуальную новеллу пилить. Я ему скелет игровых систем, он мне модельку. Но это вряд ли.
>>56420
Скульптинг, ретопология, текстуры, одежда, риггинг, анимация за 10 баксов? Я канеш не шарю за цены, но по-моему ты пизданулся, либо проебал пару нулей.
>Думаю влетит в диапазоне 10-50 баксов
Скульптинг, ретопология, текстуры, одежда, риггинг, анимация за 10 баксов? Я канеш не шарю за цены, но по-моему ты пизданулся, либо проебал пару нулей.
>>56420
Sex sells, зачем себе вредить?
https://en.wikipedia.org/wiki/Sex_in_advertising
Там лоупольки с хендпейт текстурами. Для такого тебе другой художник нужен, этот, похоже, по хайполькам с запеканием (такие редко рисуют текстуры вручную, только запекают с хайполи, процесс совершенно разный - запекание буквально одной кнопкой). И если ты ориентируешься на SH, разве у тебя не слишком реалистичные модели окружения? Придётся всё переделывать для такой стилизации.
А ты любишь шутить...
>менее сексуализированно
Sex sells, зачем себе вредить?
https://en.wikipedia.org/wiki/Sex_in_advertising
>в стиле ближе к Silent Hill
Там лоупольки с хендпейт текстурами. Для такого тебе другой художник нужен, этот, похоже, по хайполькам с запеканием (такие редко рисуют текстуры вручную, только запекают с хайполи, процесс совершенно разный - запекание буквально одной кнопкой). И если ты ориентируешься на SH, разве у тебя не слишком реалистичные модели окружения? Придётся всё переделывать для такой стилизации.
>10 баксов
А ты любишь шутить...
Короче, в этот решил радикально подойти к изучению геймдева. Запретил себе дрочить пока не закончу свой первый проект на годо. Итак, первое мое творение будет порноигра. Подготовил рабочие ассеты пикрилы, но не понимаю как загрузить их в годо. Нужна помощь с этим. Руки чешутся скорее взятся за дело...
79 Кб, 1280x720>>56420
Если брать SH2, то там, похоже, делали по фото лица реального человека. Сложно...
>в стиле ближе к Silent Hill
Если брать SH2, то там, похоже, делали по фото лица реального человека. Сложно...
118 Кб, 1510x687>>56444
Для прототипа - вот это используй:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Для красивого релиза - в блендере переделаешь.
>А как сделать помещение?
Для прототипа - вот это используй:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Для красивого релиза - в блендере переделаешь.
>>56431
Полигональное моделирование, материалы, одежда, текстуры. Емнип он не скульптурит, а классически редактирует сетку. Анимации/риг он так же не делает, натяну с mixamo как сделал в текущей демке. Лоуполи ретопологию проведу сам.
>>56432
Сдрочусь.
>Скульптинг, ретопология, текстуры, одежда, риггинг, анимация за 10 баксов?
Полигональное моделирование, материалы, одежда, текстуры. Емнип он не скульптурит, а классически редактирует сетку. Анимации/риг он так же не делает, натяну с mixamo как сделал в текущей демке. Лоуполи ретопологию проведу сам.
>>56432
>Sex sells, зачем себе вредить?
Сдрочусь.
>>56225
Хочу предупредить, что в 4.3 изменят модификаторы Skeleton3D, включая SkeletonIK3D:
https://github.com/godotengine/godot/pull/87888
Если что, это уже давно собирались сделать.
4.3 должна выйти через месяц-два, я думаю...
Хочу предупредить, что в 4.3 изменят модификаторы Skeleton3D, включая SkeletonIK3D:
https://github.com/godotengine/godot/pull/87888
Если что, это уже давно собирались сделать.
4.3 должна выйти через месяц-два, я думаю...
>>56450
Нет конечно, это зависит от задачи, мало где скульптуринг нужен кровь из носу как. Есть кнчно персонажи которые и квадратную коробку скульптурить будут, но это такие себе типы.
>Это разве не сложнее?
Нет конечно, это зависит от задачи, мало где скульптуринг нужен кровь из носу как. Есть кнчно персонажи которые и квадратную коробку скульптурить будут, но это такие себе типы.
>>56437
В этом конкретном случае. А прошу у нее создать скрипт для движения игрока и она дает скрипт для годо 3. Про четвертый не знает.
>Спроси у нейронки. Я спросил, она хорошо ответила.
В этом конкретном случае. А прошу у нее создать скрипт для движения игрока и она дает скрипт для годо 3. Про четвертый не знает.
711 Кб, 1566x2048Хочу задизайнерить и смоделить персонажа-маскота для годота, но мужского, в пару Годетте и выложить в опенсорс. Как вам идея, го[в/д]но?
31 Кб, 735x486>>56468
> Есть кнчно персонажи которые и квадратную коробку скульптурить будут, но это такие себе типы.
>>54699 (OP)
Годноты навалили в систему анимаций 4.3.
https://godotengine.org/article/migrating-animations-from-godot-4-0-to-4-3/
Годноты навалили в систему анимаций 4.3.
https://godotengine.org/article/migrating-animations-from-godot-4-0-to-4-3/
>>56468
Органику без скульптинга не сделать, если тебе фотореализм с прыщами и морщинками нужен. Десятки миллионов квадов на куб скульптеца!
Но если аниме-масочку, то тут скульпт не нужен.
>>56492
Открой для себя пропорциональное редактирование.
https://docs.blender.org/manual/en/latest/editors/3dview/controls/proportional_editing.html
>мало где скульптуринг нужен
Органику без скульптинга не сделать, если тебе фотореализм с прыщами и морщинками нужен. Десятки миллионов квадов на куб скульптеца!
Но если аниме-масочку, то тут скульпт не нужен.
>>56492
Открой для себя пропорциональное редактирование.
https://docs.blender.org/manual/en/latest/editors/3dview/controls/proportional_editing.html
>>56505
Открыл уже давно, но это по сути скульптинг, но можно пользоваться только одной кистью, нет ремеша и динтопо.
>Открой для себя пропорциональное редактирование.
Открыл уже давно, но это по сути скульптинг, но можно пользоваться только одной кистью, нет ремеша и динтопо.
>>56507
Нет, это не скульптинг: ты контролируешь вершины, осознавая влияние действий на структуру сетки.
Скульптинг - это когда ты совсем абстрагируешься, работая виртуальной "глиной", пока софт решает все проблемы с мешем вместо тебя. Поэтому после скульптинга нужна ретопология - восстановление меша до юзабельного состояния (ровная сетка).
Ну это примерно как мазня кисточкой vs мазня нейронками: нейронка решает все мазки за тебя, высирая неюзабельное говно, которое нужно вилкой чистить (а можно не чистить и стать знаменитым говноделом как яндередев, но это такое).
>но это по сути скульптинг
Нет, это не скульптинг: ты контролируешь вершины, осознавая влияние действий на структуру сетки.
Скульптинг - это когда ты совсем абстрагируешься, работая виртуальной "глиной", пока софт решает все проблемы с мешем вместо тебя. Поэтому после скульптинга нужна ретопология - восстановление меша до юзабельного состояния (ровная сетка).
Ну это примерно как мазня кисточкой vs мазня нейронками: нейронка решает все мазки за тебя, высирая неюзабельное говно, которое нужно вилкой чистить (а можно не чистить и стать знаменитым говноделом как яндередев, но это такое).
>>56508
Кринжа навалил, анон. Попробуй поскульптить и поредактировать прежде чем такое категоричное мнение выдавать.
Кринжа навалил, анон. Попробуй поскульптить и поредактировать прежде чем такое категоричное мнение выдавать.
>>56510
Я много лет в этой теме вообще-то.
Редактирование: чётко, гладко, полный контроль. Цепляешься за конкретные вершины, которые ты видишь глазами, они не рождаются из ниоткуда.
Скульптинг: один раз мазнул кисточкой и прога вываливает кучу треугольников. Если снять галку генерации треугольников, то будет лоуполи кринж, который совершенно не похож на ИРЛ глину.
Пропорциональное редактирование - это совсем не скульптинг. А "скульптинг" без генерации и удаления треугольников в принципе не имеет смысла.
С реальной глиной, воском, пластилином у тебя минимальная единица размером с молекулу, т.е. нет проблемы с нехваткой разрешения. Скульптинг в 3D вынужден генерировать треугольники, потому что невозможно уместить в RAM триллионы "атомов".
Я много лет в этой теме вообще-то.
Редактирование: чётко, гладко, полный контроль. Цепляешься за конкретные вершины, которые ты видишь глазами, они не рождаются из ниоткуда.
Скульптинг: один раз мазнул кисточкой и прога вываливает кучу треугольников. Если снять галку генерации треугольников, то будет лоуполи кринж, который совершенно не похож на ИРЛ глину.
Пропорциональное редактирование - это совсем не скульптинг. А "скульптинг" без генерации и удаления треугольников в принципе не имеет смысла.
С реальной глиной, воском, пластилином у тебя минимальная единица размером с молекулу, т.е. нет проблемы с нехваткой разрешения. Скульптинг в 3D вынужден генерировать треугольники, потому что невозможно уместить в RAM триллионы "атомов".
>>56518
Незаметно, если честно. Ты звучишь как человек который ни разу в жизни скульптить не пробовал. Там всё пиздец как удобно, намного удобнее чем двигать вершины самому, и уж тем более удобнее чем с реальной глиной.
>Я много лет в этой теме вообще-то.
Незаметно, если честно. Ты звучишь как человек который ни разу в жизни скульптить не пробовал. Там всё пиздец как удобно, намного удобнее чем двигать вершины самому, и уж тем более удобнее чем с реальной глиной.
>>56522
При чём тут удобство?
Речь шла о том, что скульпт - это отдельная от редактирования сетки тема, абстрагирующая художника от, собственно, сетки.
Удобно/неудобно - зависит от того, что ты делаешь. Пробовал лепить стрёмных монстров - да, удобно. Но анимешную гладенькую маску сложно сделать.
>удобно, намного удобнее
При чём тут удобство?
Речь шла о том, что скульпт - это отдельная от редактирования сетки тема, абстрагирующая художника от, собственно, сетки.
Удобно/неудобно - зависит от того, что ты делаешь. Пробовал лепить стрёмных монстров - да, удобно. Но анимешную гладенькую маску сложно сделать.
>>56570
Тащемто никакого секрету тута нету.
https://www.imagineforest.com/blog/game-name-generator/
Накидал по инструкции, разбирайте, кому надо:
Tower of Ass; Pile of Boobs; Mr. Dick Short; Cum Dump; Cumpocalypse: Days to Come; Long White Shot; Smallfun Skillful; Forbidden Jar: Escape the Goo; Short Snort; Lost Fapathon: Impotence; My Neighbour's Wife; Kill la Cum.
>Как придумать название для игры?
Тащемто никакого секрету тута нету.
https://www.imagineforest.com/blog/game-name-generator/
>1. Define the Genre of Your Game
>2. Make a List of Nouns
>3. Make a List of Adjectives
>4. Combine the Adjectives and Nouns
>5. Play around with Your Words
Накидал по инструкции, разбирайте, кому надо:
Tower of Ass; Pile of Boobs; Mr. Dick Short; Cum Dump; Cumpocalypse: Days to Come; Long White Shot; Smallfun Skillful; Forbidden Jar: Escape the Goo; Short Snort; Lost Fapathon: Impotence; My Neighbour's Wife; Kill la Cum.
>>56573
Да, вот только получается дженерик хуйня вместо названия. Этих таверов, спайров и эскейпов бесчисленное безликое множество.
Да, вот только получается дженерик хуйня вместо названия. Этих таверов, спайров и эскейпов бесчисленное безликое множество.
139 Кб, 604x604>>56574
1. Изобретаешь машину времени.
2. Путешествуешь в 70/80/90-е.
3. Забираешь лучшие имена.
4. Профит!
>бесчисленное безликое множество
1. Изобретаешь машину времени.
2. Путешествуешь в 70/80/90-е.
3. Забираешь лучшие имена.
4. Профит!
Приветики годаны. Чето меня то депресуха накроет, то прокрастинация, и вот которые сутки я нихуя не делаю с кликером, хотя казалось бы, осталось совсем чуть чуть буквально пару фуллтайм деньков потратить и релизнуть уже наконец, но чет морали не хватает. Сколько я его делаю уже? Месяц гдето? По факту за этот месяц я максимум провел за разработкой неделю. Последнее что сделал так это прикрутил локализацию и внес правки в формулы и все блять. Кстати, раз затронул локализацию, можно ли сделать так что бы в условном лейбле работало сразу несколько ключей? Знаю что tr() можно юзать, но это не то, нужно чтоб динамически переводило, спасибо блять моче яндекса за эту шизу. Адекватно нагуглить не смог как бы не пытался, пришлось васянить, для условных 1.0к юзаю 2 лейбла, один для числа, другой для значения, и это пиздец как не удобно. Есть мысли?
Постараюсь собраться с силами и на выходных все же доделать то что осталось.
Недавно кстати поймал себя на мысли что я не могу делать говноигры уровня яндекс игр, снимаю шляпу перед теми кто может просто взять за 5 минут собрать из ассетов "хагиваги против нубика" и без зазрения совести выложить это получив как минимум мрот, я так не могу, и не потому что не могу, а потому что как любитель игр не могу.
Скоро твг же будет, думаю попробовать, никогда ещё в таком не участвовал.
Ебать я конечно насрал тут, извиняюсь.
Постараюсь собраться с силами и на выходных все же доделать то что осталось.
Недавно кстати поймал себя на мысли что я не могу делать говноигры уровня яндекс игр, снимаю шляпу перед теми кто может просто взять за 5 минут собрать из ассетов "хагиваги против нубика" и без зазрения совести выложить это получив как минимум мрот, я так не могу, и не потому что не могу, а потому что как любитель игр не могу.
Скоро твг же будет, думаю попробовать, никогда ещё в таком не участвовал.
Ебать я конечно насрал тут, извиняюсь.
>>56675
Про локализацию я не знаю, просто скажу что маленький шаг вперед лучше чем отсутствие этого шага. Вперед.
Про локализацию я не знаю, просто скажу что маленький шаг вперед лучше чем отсутствие этого шага. Вперед.
182 Кб, mp4,500x500, 0:03
>>56675
Хотел похожее написать, но ты опередил...
Инкапсулируй @ профит.
Молодец. И без нас насрут.
>меня то депресуха накроет, то прокрастинация
Хотел похожее написать, но ты опередил...
>юзаю 2 лейбла
>не удобно
Инкапсулируй @ профит.
>как любитель игр не могу.
Молодец. И без нас насрут.
69 Кб, 500x698>>56710
Вкусовщина. Об этом на каждом углу говорят. Лучше сначала геймплей сделай, а уже потом обмазывай постпроцессингом и процедурными анимациями.
Самая полезная информация:
https://en.wikipedia.org/wiki/Bouba/kiki_effect
Вкусовщина. Об этом на каждом углу говорят. Лучше сначала геймплей сделай, а уже потом обмазывай постпроцессингом и процедурными анимациями.
Самая полезная информация:
>The rounded shape may most commonly be named "bouba"
https://en.wikipedia.org/wiki/Bouba/kiki_effect
>>56711
Без вопросов. Просто у людей часто представление о пиксель-арте как о самом изи арте. Вот этот полегче будет.
>сначала геймплей
Без вопросов. Просто у людей часто представление о пиксель-арте как о самом изи арте. Вот этот полегче будет.
>>56715
Ещё легче вообще ничего не делать.
Вот лично я хочу 3D игру, а не 2D головоломку.
>полегче будет
Ещё легче вообще ничего не делать.
Вот лично я хочу 3D игру, а не 2D головоломку.
>>56718
Сказали тебе делай 2д головоломку, значит делай 2д головоломку.
Сказали тебе делай 2д головоломку, значит делай 2д головоломку.
>>56691
Плохо. Нужно выбираться из этого говна, только как - хуй его знает. Вообще это бич почти каждого индюка-оркестра, и то и это надо делать, и все это еще надо уметь, бррр.
Понятное дело, не удобно в том плане что вместо одной ноды "текст KEY_1", приходится юзать три: контейнер, "текст", "KEY_1".
>Хотел похожее написать, но ты опередил...
Плохо. Нужно выбираться из этого говна, только как - хуй его знает. Вообще это бич почти каждого индюка-оркестра, и то и это надо делать, и все это еще надо уметь, бррр.
>Инкапсулируй @ профит.
Понятное дело, не удобно в том плане что вместо одной ноды "текст KEY_1", приходится юзать три: контейнер, "текст", "KEY_1".
Почему-то пока моделю депресон накатывает жуткий.
Нужного утюга не нашел, пришлось делать самому. Зато всего 1400 треугольников. Планируется на роль оружия ближне-дальнего боя после первого энкаунтера. Два дня на утюг. Если делать по модельке раз в три дня, то на сотню ассетов уйдет год. Аж плакать хочется.
Нужного утюга не нашел, пришлось делать самому. Зато всего 1400 треугольников. Планируется на роль оружия ближне-дальнего боя после первого энкаунтера. Два дня на утюг. Если делать по модельке раз в три дня, то на сотню ассетов уйдет год. Аж плакать хочется.
>>56722
1. Делаешь новый tool-скрипт.
2. Добавляешь лейбелы как internal ноды.
https://docs.godotengine.org/en/stable/classes/class_node.html#enum-node-internalmode
Либо, ещё лучше — пишешь свою версию Label, которая воспринимает сколько тебе нужно тегов.
Потом просто юзаешь как обычную ноду.
>вместо одной ноды "текст KEY_1", приходится юзать три: контейнер, "текст", "KEY_1".
1. Делаешь новый tool-скрипт.
2. Добавляешь лейбелы как internal ноды.
https://docs.godotengine.org/en/stable/classes/class_node.html#enum-node-internalmode
Либо, ещё лучше — пишешь свою версию Label, которая воспринимает сколько тебе нужно тегов.
Потом просто юзаешь как обычную ноду.
>>56725
Поэтому делай геймплей лучше
Поэтому делай геймплей лучше
53 Кб, 720x720>>56725
У тебя игра в целом депрессивная получается...
Не хватает только серого фильтра и дождя.
И тазиков, собирающих воду с потолка.
У тебя игра в целом депрессивная получается...
Не хватает только серого фильтра и дождя.
И тазиков, собирающих воду с потолка.
>>56725
А может со временем скилуха прокачается и будешь срать моделькой за час? Мне иногда попадаются стримы моделлеров всяких, они за утро персонажа высирают.
>Два дня на утюг. Если делать по модельке раз в три дня, то на сотню ассетов уйдет год. Аж плакать хочется.
А может со временем скилуха прокачается и будешь срать моделькой за час? Мне иногда попадаются стримы моделлеров всяких, они за утро персонажа высирают.
Пока гулял по городу, натыкался на пикрилы. Если расширю игру до бродилок по улице, так буду размечать места спавна монстров.
>>56729
Тогда иду в правильном направлении. Хотя может поэтому самому так грустно становится.
>>56738
Это отрепетированные стримы. Но 2 дня на утюг много конечно. Может одного вечера должно было хватить.
Попробую, к слову, выставить на продажу пару моделек где-нибудь.
>>56729
>У тебя игра в целом депрессивная получается
Тогда иду в правильном направлении. Хотя может поэтому самому так грустно становится.
>>56738
>они за утро персонажа высирают
Это отрепетированные стримы. Но 2 дня на утюг много конечно. Может одного вечера должно было хватить.
Попробую, к слову, выставить на продажу пару моделек где-нибудь.
Как решить проблему: Godot 4.3 beta 1
1) У меня Игрок на Автозагрузке.
2) Игрок подпрыгивает на большой высоте и активирует смену сцены.
3) Когда сцена меняется, Игрока телепортируют на заданную глобальную координату, которая находится ниже текущей позиции Игрока. (Координата зависит от аргумента функции для смены локации.)
4) Игра просчитывает, что Игрок не is_on_floor().
5) После телепортации игра просчитывает, что Игрок is_on_floor().
6) Игрок теряет очки здоровья как от стандартного падения.
Автозагрузку для игрока я использую чтобы не перезагружать его каждый раз при смене локации, а также для упрощения кода.
1) У меня Игрок на Автозагрузке.
2) Игрок подпрыгивает на большой высоте и активирует смену сцены.
3) Когда сцена меняется, Игрока телепортируют на заданную глобальную координату, которая находится ниже текущей позиции Игрока. (Координата зависит от аргумента функции для смены локации.)
4) Игра просчитывает, что Игрок не is_on_floor().
5) После телепортации игра просчитывает, что Игрок is_on_floor().
6) Игрок теряет очки здоровья как от стандартного падения.
Автозагрузку для игрока я использую чтобы не перезагружать его каждый раз при смене локации, а также для упрощения кода.
>>56773
Вообще по-хорошему ты должен был расчёт дамага привязать к стейт-машине, и среди стейтов можно было бы прописать "is jumping" который может переходить как в "is falling", так и в "is teleporting", во втором случае дамаг не распределяется.
Вообще по-хорошему ты должен был расчёт дамага привязать к стейт-машине, и среди стейтов можно было бы прописать "is jumping" который может переходить как в "is falling", так и в "is teleporting", во втором случае дамаг не распределяется.
>>56741
Вот это попробуй использовать:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#adjustments
- минус насыщенность (saturation)
- минус контраст (contrast)
- минус яркость (brightness)
+ добавь полупрозрачный шум Перлина на весь экран
>>игра в целом депрессивная получается
>Тогда иду в правильном направлении.
Вот это попробуй использовать:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#adjustments
- минус насыщенность (saturation)
- минус контраст (contrast)
- минус яркость (brightness)
+ добавь полупрозрачный шум Перлина на весь экран
>>56773
Это версия для тестов, а не для разработки игр.
Не стоит так делать...
У тебя формула зависит от высоты?
Что-нибудь вроде:
Получается огромный дамаг от телепорта вниз.
>>56775
Конечный автомат не решает проблему в логике.
>проблему: Godot 4.3 beta 1
Это версия для тестов, а не для разработки игр.
>Игрок на Автозагрузке
>активирует смену сцены
Не стоит так делать...
>Игрок теряет очки здоровья
У тебя формула зависит от высоты?
Что-нибудь вроде:
>fall_damage += last_height - current_height
Получается огромный дамаг от телепорта вниз.
>>56775
>расчёт дамага привязать к стейт-машине
Конечный автомат не решает проблему в логике.
>>56792
Нахуя решать проблему в логике в сложной структуре, когда её можно облегчить и проблема с логикой уйдёт сама собой?
>Конечный автомат не решает проблему в логике.
Нахуя решать проблему в логике в сложной структуре, когда её можно облегчить и проблема с логикой уйдёт сама собой?
>>56790
А чем ты комнатное освещение делаешь? Например тот источник света, который из кордиора в комнату светит? Омнилайт?
А чем ты комнатное освещение делаешь? Например тот источник света, который из кордиора в комнату светит? Омнилайт?
>>56780
Я пробовал делать стейт машину, но результатов она не дала. Затем написал одну строку, которая меняет координату последнего касания земли на координату телепорта и урон пропал. Спасибо, anyway попрактиковался в написании машин, пускай они мне пока не нужны.\
>>56792
Меня это никогда не останавливало. Просто скачиваю последнюю версию и пользуюсь новейшими фишками, а когда релизится, проект переношу на стабильную версию и экспортирую.
Я от очень многих это слышал, но подробно никто не раскрывал почему игрок не может быть синглтоном, если постоянно меняются все сцены, кроме игрока. Просто игрок в памяти находится, и всё. Разве нет? Это предоставляет кучу удобств для обращений и взаимодействий игрока с миром.
У меня не только синглтон-игрок, но и специальный системный скрипт и UI.
Понимаю, спасибо, кэп.
Так точно. Одной строкой в функции телепорта решается ВСЁ.
Я пробовал делать стейт машину, но результатов она не дала. Затем написал одну строку, которая меняет координату последнего касания земли на координату телепорта и урон пропал. Спасибо, anyway попрактиковался в написании машин, пускай они мне пока не нужны.\
>>56792
>Это версия для тестов, а не для разработки игр.
Меня это никогда не останавливало. Просто скачиваю последнюю версию и пользуюсь новейшими фишками, а когда релизится, проект переношу на стабильную версию и экспортирую.
>Не стоит так делать...
Я от очень многих это слышал, но подробно никто не раскрывал почему игрок не может быть синглтоном, если постоянно меняются все сцены, кроме игрока. Просто игрок в памяти находится, и всё. Разве нет? Это предоставляет кучу удобств для обращений и взаимодействий игрока с миром.
У меня не только синглтон-игрок, но и специальный системный скрипт и UI.
>Получается огромный дамаг от телепорта вниз.
Понимаю, спасибо, кэп.
>Конечный автомат не решает проблему в логике.
Так точно. Одной строкой в функции телепорта решается ВСЁ.
>>56802
Тыщу раз уже обсуждали в Godot-тредах.
Потому что ты его гвоздями прибиваешь.
Что, если ты захочешь сделать мультиплеер?
Что, если захочешь сделать плавный переход?
Завязывает весь код игры на реализацию Player.
Потом эти удобства могут боком выйти.
Короч, гугли low coupling, high cohesion.
Autoloaded - прямой путь к high coupling.
>подробно никто не раскрывал
Тыщу раз уже обсуждали в Godot-тредах.
>почему игрок не может быть синглтоном
Потому что ты его гвоздями прибиваешь.
Что, если ты захочешь сделать мультиплеер?
>если постоянно меняются все сцены
Что, если захочешь сделать плавный переход?
>Просто игрок в памяти находится, и всё.
Завязывает весь код игры на реализацию Player.
>кучу удобств для обращений и взаимодействий
Потом эти удобства могут боком выйти.
Короч, гугли low coupling, high cohesion.
Autoloaded - прямой путь к high coupling.
>>56808
Пиздец у тебя "что если". А что если ты из своего хруща захочешь многоразовую ракету сделать? А потом переделать в подводную лодку?
Вот так и пилят-перепиливают десяток лет, а на выхлопе тухлый пук вместо игры с геймплеем.
>Что, если ты захочешь сделать мультиплеер?
Пиздец у тебя "что если". А что если ты из своего хруща захочешь многоразовую ракету сделать? А потом переделать в подводную лодку?
Вот так и пилят-перепиливают десяток лет, а на выхлопе тухлый пук вместо игры с геймплеем.
>>56808
Спасибо, не захочу.
У меня UI синглтоновский. Когда происходит смена сцены, игрок фризится, а интерфейс включает экран загрузки.
Ну да, это синглплеерная маленькая мобильная игра, в которой не будет мультиплеера, сложных механик. В крайнем случае много переписывать не придётся, ведь Player достаточно заменить на переменную, которую будет хранить глобальный скрипт, но в этом ничего сакрального не вижу.
Когда я делал игрули и раком изъёбывался чтобы получать доступ к игроку и от игрока к миллиону других нодов через окольные пути у меня были проблемы, а сейчас их ровно ноль. Посмотрим что будет в дальнейшем. Если обосрусь, то напишу что был не прав, если нет, то поделюсь готовым проектом и отмечу, что использовал игрока в качестве синглтона.
>Потому что ты его гвоздями прибиваешь.
>Что, если ты захочешь сделать мультиплеер?
Спасибо, не захочу.
>Что, если захочешь сделать плавный переход?
У меня UI синглтоновский. Когда происходит смена сцены, игрок фризится, а интерфейс включает экран загрузки.
>Завязывает весь код игры на реализацию Player.
Ну да, это синглплеерная маленькая мобильная игра, в которой не будет мультиплеера, сложных механик. В крайнем случае много переписывать не придётся, ведь Player достаточно заменить на переменную, которую будет хранить глобальный скрипт, но в этом ничего сакрального не вижу.
>Потом эти удобства могут боком выйти.
Когда я делал игрули и раком изъёбывался чтобы получать доступ к игроку и от игрока к миллиону других нодов через окольные пути у меня были проблемы, а сейчас их ровно ноль. Посмотрим что будет в дальнейшем. Если обосрусь, то напишу что был не прав, если нет, то поделюсь готовым проектом и отмечу, что использовал игрока в качестве синглтона.
754 Кб, 750x782>>56790
Мне эта серая блевотина как-то приелась. Как в американских фильмах сериалах - мексиканский фильтр (все желтое), русский фильтр (все синее), индийский фильтр (все коричневое). В играх тоже уже затрахало.
Правда я планировал взять эффект шума вблизи монстров, хоть и калька с SH4.
Квартира, к слову - сейв зона, там должно быть депрессивно, но уютно.
>>56799
Да, в каждой комнате свой омник, плюс один солнечный источник света для света/теней из окон. Освещение у Environment стоит очень низкое, всего 0.08
>Вот это попробуй использовать:
Мне эта серая блевотина как-то приелась. Как в американских фильмах сериалах - мексиканский фильтр (все желтое), русский фильтр (все синее), индийский фильтр (все коричневое). В играх тоже уже затрахало.
Правда я планировал взять эффект шума вблизи монстров, хоть и калька с SH4.
Квартира, к слову - сейв зона, там должно быть депрессивно, но уютно.
>>56799
>Омнилайт?
Да, в каждой комнате свой омник, плюс один солнечный источник света для света/теней из окон. Освещение у Environment стоит очень низкое, всего 0.08
>>56819
Ты сначала стадию прототипа пройди. Прежде, чем переходить к продакшену и цементировать механики игры, нужно сначала придумать нормальную игру. А для этого нужна максимальная гибкость кода.
>>56822
Ты что-то не то делаешь, если у тебя "игрок" (точка доступа пользователя к игре) занимается раздачей миллионов нод другим игровым системам.
>>56833
Мне тоже, но цвет должен подходить сюжету, работать на создание настроения.
SpotLight3D не пробовал использовать?
>пилят-перепиливают десяток лет
Ты сначала стадию прототипа пройди. Прежде, чем переходить к продакшену и цементировать механики игры, нужно сначала придумать нормальную игру. А для этого нужна максимальная гибкость кода.
>>56822
>получать доступ к игроку и от игрока к миллиону других нодов через окольные пути
Ты что-то не то делаешь, если у тебя "игрок" (точка доступа пользователя к игре) занимается раздачей миллионов нод другим игровым системам.
>>56833
>серая блевотина как-то приелась
Мне тоже, но цвет должен подходить сюжету, работать на создание настроения.
>в каждой комнате свой омник
SpotLight3D не пробовал использовать?
>>56841
Так взаимодействие игрока с игрой — это единственная неотьемлимая часть любой игры. Я её поставил в приоритет и на взаимодействии игрока с игрой завязывается всё остальное.
>Ты что-то не то делаешь, если у тебя "игрок" (точка доступа пользователя к игре) занимается раздачей миллионов нод другим игровым системам.
Так взаимодействие игрока с игрой — это единственная неотьемлимая часть любой игры. Я её поставил в приоритет и на взаимодействии игрока с игрой завязывается всё остальное.
>>56857
Вообще мимо. Игры могут быть без игрока.
Игру нужно рассматривать как игровую площадку с игрушками и правилами игры. Завязывать всю игру на игрока, это как если бы ИРЛ игрушки работали только с конкретным ребёнком, по анализу ДНК.
Да, ты создаёшь "игровой опыт" для игрока, но ты создаёшь его с помощью деталей, которые от игрока никак не должны зависеть, они есть сами по себе.
Вот, например, шахматы. Где там игрок? Есть доска в клеточку - это игровая площадка. Есть фигурки - это игрушки. И есть правила перемещения фигурок. Игра существует независимо от конкретных игроков.
Можно сделать так, чтобы игрок перемещал фигуры клавиатурой, мышью, тачскрином. Можно сделать, чтобы второй игрок использовал тот же способ ввода по очереди с первым, или подключался через сеть. Можно сделать ИИ, который будет играть с игроком. Или придумать ещё что-нибудь. Игра от этого никак не меняется, меняются только игроки.
>единственная неотьемлимая часть
Вообще мимо. Игры могут быть без игрока.
Игру нужно рассматривать как игровую площадку с игрушками и правилами игры. Завязывать всю игру на игрока, это как если бы ИРЛ игрушки работали только с конкретным ребёнком, по анализу ДНК.
Да, ты создаёшь "игровой опыт" для игрока, но ты создаёшь его с помощью деталей, которые от игрока никак не должны зависеть, они есть сами по себе.
Вот, например, шахматы. Где там игрок? Есть доска в клеточку - это игровая площадка. Есть фигурки - это игрушки. И есть правила перемещения фигурок. Игра существует независимо от конкретных игроков.
Можно сделать так, чтобы игрок перемещал фигуры клавиатурой, мышью, тачскрином. Можно сделать, чтобы второй игрок использовал тот же способ ввода по очереди с первым, или подключался через сеть. Можно сделать ИИ, который будет играть с игроком. Или придумать ещё что-нибудь. Игра от этого никак не меняется, меняются только игроки.
1,9 Мб, 1280x720Сап. Полюбилась мне игра Dead End Road, и возникла идея сделать похожую игру. Оригинал состоит из езды на тачке ночью с рнг пугалками и мистикой чуть более чем полностью. Уникальный проект, но однообразный и имеющий скрытые механики и концовки на которые всем похуй, ибо игра короткая в жанре "пройти у Куплинова". Подумываю поначалу скопипастить 1,5 базовые механики, а дальше добавлять исправления от себя.
Мне очень надо выдрочить кор механику езды от 1 лица, чтоб езда была по кайфу. Как настоящий авто аутист готов дрочить этот аспект в ущерб всему остальному, делать текстуры салона и звуки своего личного автомобиля, чтобы не было дженерик авто. Ну очень меня заебало что в играх машина это коробка без инерции делающая жу-жу-жу вместо звуков и ездящая как тележка в Майнкрафте.
Мне не хватает пары наводок чтобы понять чем делаются кор механики. Первое это как делается езда от первого лица. Нашел шаблоны с ездой от 3 лица, но не понимаю как на их основе сделать 1 лицо. И второе, хочу генерировать новую сцену когда приближаюсь к концу текущей. То-есть один общий класс (сцена) на отрисовку участков дороги. И постоянно надо дорисовывать новую сцену перед текущей чтобы не было швов. Как генерировать новую сцену и подшивать перед текущей не знаю.
На работе пишу код, поэтому быстро начну ориентироваться. Приходится постоянно писать костыли, работать с объектами, и читать ебанутые чейнджлоги, так что не привыкать.
Мне очень надо выдрочить кор механику езды от 1 лица, чтоб езда была по кайфу. Как настоящий авто аутист готов дрочить этот аспект в ущерб всему остальному, делать текстуры салона и звуки своего личного автомобиля, чтобы не было дженерик авто. Ну очень меня заебало что в играх машина это коробка без инерции делающая жу-жу-жу вместо звуков и ездящая как тележка в Майнкрафте.
Мне не хватает пары наводок чтобы понять чем делаются кор механики. Первое это как делается езда от первого лица. Нашел шаблоны с ездой от 3 лица, но не понимаю как на их основе сделать 1 лицо. И второе, хочу генерировать новую сцену когда приближаюсь к концу текущей. То-есть один общий класс (сцена) на отрисовку участков дороги. И постоянно надо дорисовывать новую сцену перед текущей чтобы не было швов. Как генерировать новую сцену и подшивать перед текущей не знаю.
На работе пишу код, поэтому быстро начну ориентироваться. Приходится постоянно писать костыли, работать с объектами, и читать ебанутые чейнджлоги, так что не привыкать.
>>56773
Я бы сделал игроку неуязвимость 5 секунд после загрузки. Даже если урон будет не от падения все-равно полезно.
Я бы сделал игроку неуязвимость 5 секунд после загрузки. Даже если урон будет не от падения все-равно полезно.
>>56841
Вот тут я с тобой не соглашусь, анон. Имхо вот как раз-таки прототип можно наговнокодить, главное чтобы передавал суть игры, ведь прикол прототипа в том что его можно сделать быстро чтобы оттестировать идею. Вот если она выстрелит то да уже желательно пилить нормально по бест практисес, чтобы ты даже если в соло делаешь потом не охуевал разбираться в своей же лапше. Проблема в том когда люди как тот челик держатся за говнокод и защищают его просто потому что скорее всего неговнокодить тупо не умеют.
>Ты сначала стадию прототипа пройди. Прежде, чем переходить к продакшену и цементировать механики игры, нужно сначала придумать нормальную игру. А для этого нужна максимальная гибкость кода.
Вот тут я с тобой не соглашусь, анон. Имхо вот как раз-таки прототип можно наговнокодить, главное чтобы передавал суть игры, ведь прикол прототипа в том что его можно сделать быстро чтобы оттестировать идею. Вот если она выстрелит то да уже желательно пилить нормально по бест практисес, чтобы ты даже если в соло делаешь потом не охуевал разбираться в своей же лапше. Проблема в том когда люди как тот челик держатся за говнокод и защищают его просто потому что скорее всего неговнокодить тупо не умеют.
>>56884
Начинай с чтения документации.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Внимательно изучай, на слепом редактировании каких-то готовых примеров далеко не уедешь.
Если поиграть настройками VehicleBody, можно сделать что-то наподобие работы подвески GTA IV:
https://docs.godotengine.org/en/stable/classes/class_vehiclebody3d.html
Хватит сделать подвеску мягкой и настроить wheel_roll_influence, чтоб машина наклонялась. Но там колёсики - рейкасты, а не физические тела, поэтому телепортируются на бордюрах.
Есть вот такой автосимулятор на Godot:
https://lupine-vidya.itch.io/gdsim
Там машинки сделаны на RigidBody:
https://www.gtplanet.net/forum/threads/gdsim-v0-4a-autocross-and-custom-setups.396400/
Хотя, вроде, там тоже рейкасты (не читал).
Просто переносишь камеру в голову персонажа, т.е. положение где-то внутри салона автомобиля. Если от третьего лица не нужно, то всё очень просто. Раз возникают такие глупые вопросы - читай мануал.
Самый простой способ, справится любой:
1. Определись, что тебе вообще нужно. Тебе нужен список участков дороги, нужных по геймплею.
2. Смоделируй участки дороги в Блендере. Следи за стыками, они должны подходить друг к другу. Определи один универсальный стык участков.
3. Сделай участки дороги отдельными сценами. Коллизии можно сгенерировать автоматически, но сложную геометрию лучше заменить упрощённой (смоделировать отдельный меш для коллизий).
4. Поставь в сцене дороги датчик (Area3D), который реагирует на приближение игрока (машины).
5. При приближении игрока сцена дороги спавнит следующий участок дороги, примерно так:
6. Старые участки дороги потом удаляешь. Нужно подумать в зависимости от геймплея твоей игры, а именно возможно ли возвращаться обратно, будет ли обратная дорога такой же и т.д. Думать надо.
Сделай сначала 2-3 участка дороги, проработай алгоритмы, уже потом добавляй остальные.
Если хочешь процедурный ландшафт (heightmap) и полностью процедурные извилистые дороги, то иди смотреть аддоны. Порекомендовать ничего не могу, ничего из них не пробовал. Но советую для начала изготовить максимально простую тестовую сцену, прежде чем искать какие-то сложные инструменты. Простая сцена позволит проработать основной геймплей (езду на машине) до генератора карты.
Вообще, процедурная генерация - сплошная головная боль, особенно если ты толком не знаешь, что нужно. Рекомендую не лезть в это дело, пока нет геймплея. Статичной сцены достаточно для 99% фич геймплея.
Если не удовлетворяет встроенная физика:
https://github.com/godot-jolt/godot-jolt
Но я не уверен, как она работает с VehicleBody3D.
Также есть другие физические движки, если что.
Видео с июня 2023, там Godot 3.x с Bullet Physics.
Начинай с чтения документации.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Внимательно изучай, на слепом редактировании каких-то готовых примеров далеко не уедешь.
>машина это коробка без инерции
Если поиграть настройками VehicleBody, можно сделать что-то наподобие работы подвески GTA IV:
https://docs.godotengine.org/en/stable/classes/class_vehiclebody3d.html
Хватит сделать подвеску мягкой и настроить wheel_roll_influence, чтоб машина наклонялась. Но там колёсики - рейкасты, а не физические тела, поэтому телепортируются на бордюрах.
Есть вот такой автосимулятор на Godot:
https://lupine-vidya.itch.io/gdsim
Там машинки сделаны на RigidBody:
https://www.gtplanet.net/forum/threads/gdsim-v0-4a-autocross-and-custom-setups.396400/
Хотя, вроде, там тоже рейкасты (не читал).
>не понимаю как на их основе сделать 1 лицо
Просто переносишь камеру в голову персонажа, т.е. положение где-то внутри салона автомобиля. Если от третьего лица не нужно, то всё очень просто. Раз возникают такие глупые вопросы - читай мануал.
>Как генерировать новую сцену и подшивать
Самый простой способ, справится любой:
1. Определись, что тебе вообще нужно. Тебе нужен список участков дороги, нужных по геймплею.
2. Смоделируй участки дороги в Блендере. Следи за стыками, они должны подходить друг к другу. Определи один универсальный стык участков.
3. Сделай участки дороги отдельными сценами. Коллизии можно сгенерировать автоматически, но сложную геометрию лучше заменить упрощённой (смоделировать отдельный меш для коллизий).
4. Поставь в сцене дороги датчик (Area3D), который реагирует на приближение игрока (машины).
5. При приближении игрока сцена дороги спавнит следующий участок дороги, примерно так:
>var paths := ["road1", "road2", "road3", "road4"]
>var path := "res://%s.tscn" % [paths.pick_random()]
>var scene := load(path).instantiate()
>get_parent().add_child(scene)
>scene.global_position = to_global(next_part_position)
>$Area3D.monitoring = false # чтоб не спамить
6. Старые участки дороги потом удаляешь. Нужно подумать в зависимости от геймплея твоей игры, а именно возможно ли возвращаться обратно, будет ли обратная дорога такой же и т.д. Думать надо.
Сделай сначала 2-3 участка дороги, проработай алгоритмы, уже потом добавляй остальные.
Если хочешь процедурный ландшафт (heightmap) и полностью процедурные извилистые дороги, то иди смотреть аддоны. Порекомендовать ничего не могу, ничего из них не пробовал. Но советую для начала изготовить максимально простую тестовую сцену, прежде чем искать какие-то сложные инструменты. Простая сцена позволит проработать основной геймплей (езду на машине) до генератора карты.
Вообще, процедурная генерация - сплошная головная боль, особенно если ты толком не знаешь, что нужно. Рекомендую не лезть в это дело, пока нет геймплея. Статичной сцены достаточно для 99% фич геймплея.
Если не удовлетворяет встроенная физика:
https://github.com/godot-jolt/godot-jolt
Но я не уверен, как она работает с VehicleBody3D.
Также есть другие физические движки, если что.
Видео с июня 2023, там Godot 3.x с Bullet Physics.
>>56884
Начинай с чтения документации.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Внимательно изучай, на слепом редактировании каких-то готовых примеров далеко не уедешь.
Если поиграть настройками VehicleBody, можно сделать что-то наподобие работы подвески GTA IV:
https://docs.godotengine.org/en/stable/classes/class_vehiclebody3d.html
Хватит сделать подвеску мягкой и настроить wheel_roll_influence, чтоб машина наклонялась. Но там колёсики - рейкасты, а не физические тела, поэтому телепортируются на бордюрах.
Есть вот такой автосимулятор на Godot:
https://lupine-vidya.itch.io/gdsim
Там машинки сделаны на RigidBody:
https://www.gtplanet.net/forum/threads/gdsim-v0-4a-autocross-and-custom-setups.396400/
Хотя, вроде, там тоже рейкасты (не читал).
Просто переносишь камеру в голову персонажа, т.е. положение где-то внутри салона автомобиля. Если от третьего лица не нужно, то всё очень просто. Раз возникают такие глупые вопросы - читай мануал.
Самый простой способ, справится любой:
1. Определись, что тебе вообще нужно. Тебе нужен список участков дороги, нужных по геймплею.
2. Смоделируй участки дороги в Блендере. Следи за стыками, они должны подходить друг к другу. Определи один универсальный стык участков.
3. Сделай участки дороги отдельными сценами. Коллизии можно сгенерировать автоматически, но сложную геометрию лучше заменить упрощённой (смоделировать отдельный меш для коллизий).
4. Поставь в сцене дороги датчик (Area3D), который реагирует на приближение игрока (машины).
5. При приближении игрока сцена дороги спавнит следующий участок дороги, примерно так:
6. Старые участки дороги потом удаляешь. Нужно подумать в зависимости от геймплея твоей игры, а именно возможно ли возвращаться обратно, будет ли обратная дорога такой же и т.д. Думать надо.
Сделай сначала 2-3 участка дороги, проработай алгоритмы, уже потом добавляй остальные.
Если хочешь процедурный ландшафт (heightmap) и полностью процедурные извилистые дороги, то иди смотреть аддоны. Порекомендовать ничего не могу, ничего из них не пробовал. Но советую для начала изготовить максимально простую тестовую сцену, прежде чем искать какие-то сложные инструменты. Простая сцена позволит проработать основной геймплей (езду на машине) до генератора карты.
Вообще, процедурная генерация - сплошная головная боль, особенно если ты толком не знаешь, что нужно. Рекомендую не лезть в это дело, пока нет геймплея. Статичной сцены достаточно для 99% фич геймплея.
Если не удовлетворяет встроенная физика:
https://github.com/godot-jolt/godot-jolt
Но я не уверен, как она работает с VehicleBody3D.
Также есть другие физические движки, если что.
Видео с июня 2023, там Godot 3.x с Bullet Physics.
Начинай с чтения документации.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Внимательно изучай, на слепом редактировании каких-то готовых примеров далеко не уедешь.
>машина это коробка без инерции
Если поиграть настройками VehicleBody, можно сделать что-то наподобие работы подвески GTA IV:
https://docs.godotengine.org/en/stable/classes/class_vehiclebody3d.html
Хватит сделать подвеску мягкой и настроить wheel_roll_influence, чтоб машина наклонялась. Но там колёсики - рейкасты, а не физические тела, поэтому телепортируются на бордюрах.
Есть вот такой автосимулятор на Godot:
https://lupine-vidya.itch.io/gdsim
Там машинки сделаны на RigidBody:
https://www.gtplanet.net/forum/threads/gdsim-v0-4a-autocross-and-custom-setups.396400/
Хотя, вроде, там тоже рейкасты (не читал).
>не понимаю как на их основе сделать 1 лицо
Просто переносишь камеру в голову персонажа, т.е. положение где-то внутри салона автомобиля. Если от третьего лица не нужно, то всё очень просто. Раз возникают такие глупые вопросы - читай мануал.
>Как генерировать новую сцену и подшивать
Самый простой способ, справится любой:
1. Определись, что тебе вообще нужно. Тебе нужен список участков дороги, нужных по геймплею.
2. Смоделируй участки дороги в Блендере. Следи за стыками, они должны подходить друг к другу. Определи один универсальный стык участков.
3. Сделай участки дороги отдельными сценами. Коллизии можно сгенерировать автоматически, но сложную геометрию лучше заменить упрощённой (смоделировать отдельный меш для коллизий).
4. Поставь в сцене дороги датчик (Area3D), который реагирует на приближение игрока (машины).
5. При приближении игрока сцена дороги спавнит следующий участок дороги, примерно так:
>var paths := ["road1", "road2", "road3", "road4"]
>var path := "res://%s.tscn" % [paths.pick_random()]
>var scene := load(path).instantiate()
>get_parent().add_child(scene)
>scene.global_position = to_global(next_part_position)
>$Area3D.monitoring = false # чтоб не спамить
6. Старые участки дороги потом удаляешь. Нужно подумать в зависимости от геймплея твоей игры, а именно возможно ли возвращаться обратно, будет ли обратная дорога такой же и т.д. Думать надо.
Сделай сначала 2-3 участка дороги, проработай алгоритмы, уже потом добавляй остальные.
Если хочешь процедурный ландшафт (heightmap) и полностью процедурные извилистые дороги, то иди смотреть аддоны. Порекомендовать ничего не могу, ничего из них не пробовал. Но советую для начала изготовить максимально простую тестовую сцену, прежде чем искать какие-то сложные инструменты. Простая сцена позволит проработать основной геймплей (езду на машине) до генератора карты.
Вообще, процедурная генерация - сплошная головная боль, особенно если ты толком не знаешь, что нужно. Рекомендую не лезть в это дело, пока нет геймплея. Статичной сцены достаточно для 99% фич геймплея.
Если не удовлетворяет встроенная физика:
https://github.com/godot-jolt/godot-jolt
Но я не уверен, как она работает с VehicleBody3D.
Также есть другие физические движки, если что.
Видео с июня 2023, там Godot 3.x с Bullet Physics.
>>56871
Игры без вмешательства игрока в процесс быть не может. Даже когда игрок подбрасывает кубик, он может это сделать по-своему, а то что ты написал никак не противоречит моим словам.
>>56895 (Del)
В стойло, копроскот.
>>56902
Спасибо за идею. Может применю, если вообще буду сталкиваться с проблемой перманентного урона. Просто эта механика даёт игроку возможность абуза.
Игры без вмешательства игрока в процесс быть не может. Даже когда игрок подбрасывает кубик, он может это сделать по-своему, а то что ты написал никак не противоречит моим словам.
>>56895 (Del)
В стойло, копроскот.
>>56902
Спасибо за идею. Может применю, если вообще буду сталкиваться с проблемой перманентного урона. Просто эта механика даёт игроку возможность абуза.
>>56910
Это довольно специфический жанр:
https://ru.wikipedia.org/wiki/Zero_player_game
Что-то вроде виртуального аквариума.
>Игры без вмешательства игрока в процесс быть не может. Даже когда игрок...
Это довольно специфический жанр:
https://ru.wikipedia.org/wiki/Zero_player_game
Что-то вроде виртуального аквариума.
>>56908
Только я даже не пытался сделать реалистичную симуляцию машины, фокус был на процедурной генерации более-менее интересной дороги между процедурными городами с геймплеем а-ля ГТА.
Слишком сфокусировался на генерации сеткой... Хотелось попробовать "органичную" генерацию, но совершенно непонятно как, и меши дорог сложно генерировать с нуля, а сцеплять их ещё сложнее. Приуныл от отсутствия геймплея и забросил всё.
В теории, пикрил должен был помочь. Но было лень моделировать это, как всегда "отложил на потом". Нет, всё ещё рассматриваю этот проект, но нужно всё пересмотреть и определиться, зачем мне это надо. Первая заметка по игре - май 2019. Делойте выводы. Концепцию в целом вынашивал, наверное, с 2009...
>там Godot 3.x с Bullet Physics
Только я даже не пытался сделать реалистичную симуляцию машины, фокус был на процедурной генерации более-менее интересной дороги между процедурными городами с геймплеем а-ля ГТА.
Слишком сфокусировался на генерации сеткой... Хотелось попробовать "органичную" генерацию, но совершенно непонятно как, и меши дорог сложно генерировать с нуля, а сцеплять их ещё сложнее. Приуныл от отсутствия геймплея и забросил всё.
В теории, пикрил должен был помочь. Но было лень моделировать это, как всегда "отложил на потом". Нет, всё ещё рассматриваю этот проект, но нужно всё пересмотреть и определиться, зачем мне это надо. Первая заметка по игре - май 2019. Делойте выводы. Концепцию в целом вынашивал, наверное, с 2009...
>>56908
Спасибо. Сохранил этот пост себе в текстово файл чтобы перечитывать пока не найду все ссылки на необходимую документацию.
В Dead End Road машина покорачивает только при движении вперед, не умеет в разворот, и имеет странную инерцию (будто инпут лаг). Цель сделать аркадную напоминающую опыт ИРЛ, но без душного реализма. Звуковой банк на коленке запишу для погружения, так как мне не нравится бесплатная библиотека звуков.
Да, наверное проще наклепать 20 сцен состоящих извилистых дорог длинной в условный 1км. Просто мне кажется что если заранее настругать сцен, то рандом будет околонулевой, и придется либо дробить дорогу на очень маленькие кусочки, либо манипулировть спавном ебак и освещением чтобы игрок не выкупил уже седьмой раз едет по тому же куску дороги, только в другом месте. Тем более что если зон будет например 3 (лесная дорога, городская дорога, лес), то нельзя будет одну из 20 сцен во всех тред зонах использовать. В общем вопрос как не привести игрока в отупления от однообразие. Ну ладно, сегодня соберусь с мыслями, а завтра после работы попробую дефолтную хеллоуворлд сценку собрать.
Спасибо. Сохранил этот пост себе в текстово файл чтобы перечитывать пока не найду все ссылки на необходимую документацию.
В Dead End Road машина покорачивает только при движении вперед, не умеет в разворот, и имеет странную инерцию (будто инпут лаг). Цель сделать аркадную напоминающую опыт ИРЛ, но без душного реализма. Звуковой банк на коленке запишу для погружения, так как мне не нравится бесплатная библиотека звуков.
Да, наверное проще наклепать 20 сцен состоящих извилистых дорог длинной в условный 1км. Просто мне кажется что если заранее настругать сцен, то рандом будет околонулевой, и придется либо дробить дорогу на очень маленькие кусочки, либо манипулировть спавном ебак и освещением чтобы игрок не выкупил уже седьмой раз едет по тому же куску дороги, только в другом месте. Тем более что если зон будет например 3 (лесная дорога, городская дорога, лес), то нельзя будет одну из 20 сцен во всех тред зонах использовать. В общем вопрос как не привести игрока в отупления от однообразие. Ну ладно, сегодня соберусь с мыслями, а завтра после работы попробую дефолтную хеллоуворлд сценку собрать.
9 Кб, 500x500>>56920
Вспомнил, почему я это говно тупое забросил:
- чем больше видов блоков, тем больше нужно промежуточных комбинаций, без которых алгоритм неспособен собрать карту без дырок, т.е. каждый новый блок должен мочь стыковаться с другими, и введение новой категории умножает число блоков;
- даже когда он работает правильно, результат у него дурацкий: много петель, тоннелей и т.д., это неплохо в рогалике каком-то, но не в планировке города;
- контроля практически никакого, рандом (можно инициализировать часть клеток, можно раздать приоритеты блокам, но всё это фигня какая-то).
Переделал с нуля, вспомнил всё это и приуныл...
Есть ли выход?
>было лень моделировать
>отложил на потом
Вспомнил, почему я это говно тупое забросил:
- чем больше видов блоков, тем больше нужно промежуточных комбинаций, без которых алгоритм неспособен собрать карту без дырок, т.е. каждый новый блок должен мочь стыковаться с другими, и введение новой категории умножает число блоков;
- даже когда он работает правильно, результат у него дурацкий: много петель, тоннелей и т.д., это неплохо в рогалике каком-то, но не в планировке города;
- контроля практически никакого, рандом (можно инициализировать часть клеток, можно раздать приоритеты блокам, но всё это фигня какая-то).
Переделал с нуля, вспомнил всё это и приуныл...
Есть ли выход?
>>56937
Каждая из сцен может иметь свой набор случайных элементов, например, на сцене "прямая дорога":
- ничего нет;
- автозаправка;
- гостиница;
- авария на обочине;
И т.п. Когда ты выбираешь "едем прямо", эта сцена выбирает у себя случайные компоненты.
Тут аналогично: сцена может быть одна, но на ней спавнятся либо плотные деревья с кустами, либо случайные дома, автобусные остановки и т.д.
Т.е. у тебя есть два направления:
- добавлять сцены-категории;
- добавлять вариации имеющимся сценам.
Логично связать категории с формой дороги, а всё остальное делать вариациями.
Суммарное число сцен = категории × вариации.
На сколько часов геймплея рассчитываешь? Совсем повторений не избежать, можно только отсрочить их появление. Игры со статичной картой заставляют ездить вообще по одним и тем же дорогам, так что возможно выучить карту наизусть и ехать не глядя. Здесь же как минимум не знаешь, что за поворотом.
>рандом будет околонулевой
Каждая из сцен может иметь свой набор случайных элементов, например, на сцене "прямая дорога":
- ничего нет;
- автозаправка;
- гостиница;
- авария на обочине;
И т.п. Когда ты выбираешь "едем прямо", эта сцена выбирает у себя случайные компоненты.
>лесная дорога, городская дорога
Тут аналогично: сцена может быть одна, но на ней спавнятся либо плотные деревья с кустами, либо случайные дома, автобусные остановки и т.д.
Т.е. у тебя есть два направления:
- добавлять сцены-категории;
- добавлять вариации имеющимся сценам.
Логично связать категории с формой дороги, а всё остальное делать вариациями.
Суммарное число сцен = категории × вариации.
>привести игрока в отупления от однообразие
На сколько часов геймплея рассчитываешь? Совсем повторений не избежать, можно только отсрочить их появление. Игры со статичной картой заставляют ездить вообще по одним и тем же дорогам, так что возможно выучить карту наизусть и ехать не глядя. Здесь же как минимум не знаешь, что за поворотом.
>>56940
Суммарное число возможных комбинаций. Те самые "триллионы планет" из No Man's Sky, которые на деле отличаются в основном цветом поверхности.
Т.е. если хочешь, например, добавить новый тип леса, достаточно будет прописать пути к новым моделькам, сцены должны остаться теми же самыми (те 20 штук), но количество комбинаций умножится.
>Суммарное число сцен = категории × вариации.
Суммарное число возможных комбинаций. Те самые "триллионы планет" из No Man's Sky, которые на деле отличаются в основном цветом поверхности.
Т.е. если хочешь, например, добавить новый тип леса, достаточно будет прописать пути к новым моделькам, сцены должны остаться теми же самыми (те 20 штук), но количество комбинаций умножится.
>>56570
Отвечают на три вопроса:
1. В каком сеттинге игра? Вселенная наобо
2. В чём главная фишка игры? рот с тол
3. Какие ещё имеются геймплейные особенности? щеходами
> Как вы придумываете?
Отвечают на три вопроса:
1. В каком сеттинге игра? Вселенная наобо
2. В чём главная фишка игры? рот с тол
3. Какие ещё имеются геймплейные особенности? щеходами
>>56939
Я видел туториал по автотайлмапу в тридэ, и там автор уверял, что нужно всего 27 блоков, чтобы закрыть все варианты.
> Есть ли выход?
Я видел туториал по автотайлмапу в тридэ, и там автор уверял, что нужно всего 27 блоков, чтобы закрыть все варианты.
>>56945
Как успехи? Показывай.
>>56946
Тоже видел, но это немного другое:
https://robertheaton.com/2018/12/17/wavefunction-collapse-algorithm/
>Вселенная наоборот с толщеходами
Как успехи? Показывай.
>>56946
>автотайлмапу в тридэ
Тоже видел, но это немного другое:
https://robertheaton.com/2018/12/17/wavefunction-collapse-algorithm/
>>56939
Самый разумный выход отказаться от автогенерации на стороне игрока, перестать хуярить однотипные рогалики, дать игроку один мир, вручную проработанный тобой лично. Возможно проработанный на основе автогенерации, но ты её потом лично ручками доработал и вручную заделал все дырки интересными квестами.
> Есть ли выход?
Самый разумный выход отказаться от автогенерации на стороне игрока, перестать хуярить однотипные рогалики, дать игроку один мир, вручную проработанный тобой лично. Возможно проработанный на основе автогенерации, но ты её потом лично ручками доработал и вручную заделал все дырки интересными квестами.
>>56951
Изучаю физику, орбитальную механику.
Пока не изучу и не научусь свободно манипулировать векторами тяготения - показывать будет нечего.
> Как успехи?
Изучаю физику, орбитальную механику.
> Показывай.
Пока не изучу и не научусь свободно манипулировать векторами тяготения - показывать будет нечего.
>>56940
Расчет менее 2 часов. Езда между городами суммарно 3+4+5+6+7 минут если играет сам разраб. В городах между дорогами всякий микроменеджмент с покупкой предметов и сохранения. Неписи в городах должны объяснять куда ехать. Ебаки должны нещадно ебать чтобы срывать прохождение участков забега, заставляя быстро реагировать на них: переключать свет, выворачивать руль, менять скорость, включать дворники, выезжать на встречку в процессе. Ну и некоторым ебакам достаточно просто жутко попездывать, смачно хуесося мамку игрока, рассказывая охуительные истории и срываясь на крик. Тип чтоб концентрации мешать. И, если получится, киллер фича, забытая технология древних, возможность играть mp3 треки из папки. Радио должно то пердеть, то выключаться, то играть реверс песни когда концентрация ебак повышается.
Расчет менее 2 часов. Езда между городами суммарно 3+4+5+6+7 минут если играет сам разраб. В городах между дорогами всякий микроменеджмент с покупкой предметов и сохранения. Неписи в городах должны объяснять куда ехать. Ебаки должны нещадно ебать чтобы срывать прохождение участков забега, заставляя быстро реагировать на них: переключать свет, выворачивать руль, менять скорость, включать дворники, выезжать на встречку в процессе. Ну и некоторым ебакам достаточно просто жутко попездывать, смачно хуесося мамку игрока, рассказывая охуительные истории и срываясь на крик. Тип чтоб концентрации мешать. И, если получится, киллер фича, забытая технология древних, возможность играть mp3 треки из папки. Радио должно то пердеть, то выключаться, то играть реверс песни когда концентрация ебак повышается.
>>56913
Знаю про существование этого "жанра" "игр", но считаю его простой симуляцией. Всё равно что виндовсовский визуализатор музыки или наблюдение за размножением рыб назвать игрой. Во втором случае можно использовать азартные механики, но тогда вообще из чего угодно можно сделать игру, достаточно найти только двух игроков и поставить любое условие, которое определит кто победил, а кто нет, зависящее в конечном итоге от случайности.
Знаю про существование этого "жанра" "игр", но считаю его простой симуляцией. Всё равно что виндовсовский визуализатор музыки или наблюдение за размножением рыб назвать игрой. Во втором случае можно использовать азартные механики, но тогда вообще из чего угодно можно сделать игру, достаточно найти только двух игроков и поставить любое условие, которое определит кто победил, а кто нет, зависящее в конечном итоге от случайности.
>>57016
Зависит от игры. Мозг любит наблюдать патерны и ритмы. Если на экране происходит симуляция чего-то базового. Будет интересно смотреть.
Немного более высокого уровня но что-то похожее. Давно у меня была спутниковоя сетевая карта в компьютере. И я включал на ней "спутниковую рыбалку", - сетевуха переключалась в promiscuous mode, и ловила весь контент от всех пользователей которые висели на этом транспондере. Можно было ставить фильтры на файлы которые ты хотел чтобы ловились. Так вот помню можно было часами наблюдать как начиналась закачка многотомных архивов с фильмами и сериями из сериалов. Следить как наполняются папки с музыкой. Почитывать имейлы пользователей, и их переписку в разных мессенджарах. Видеоролики, с порнухой и приколами. Веб страницы с новостями и контентом. У меня интернета тогда не было и это было развлечением.
Так вот если игру такую создать с использованием нейронки например. Наблюдать за колонией на марсе например. Следить как разрастается колония и за каждым человеком в частности. Как они реалистично строят отношения между собой и общество. Для тех кто проходят игры на ютубе сойдет.
Зависит от игры. Мозг любит наблюдать патерны и ритмы. Если на экране происходит симуляция чего-то базового. Будет интересно смотреть.
Немного более высокого уровня но что-то похожее. Давно у меня была спутниковоя сетевая карта в компьютере. И я включал на ней "спутниковую рыбалку", - сетевуха переключалась в promiscuous mode, и ловила весь контент от всех пользователей которые висели на этом транспондере. Можно было ставить фильтры на файлы которые ты хотел чтобы ловились. Так вот помню можно было часами наблюдать как начиналась закачка многотомных архивов с фильмами и сериями из сериалов. Следить как наполняются папки с музыкой. Почитывать имейлы пользователей, и их переписку в разных мессенджарах. Видеоролики, с порнухой и приколами. Веб страницы с новостями и контентом. У меня интернета тогда не было и это было развлечением.
Так вот если игру такую создать с использованием нейронки например. Наблюдать за колонией на марсе например. Следить как разрастается колония и за каждым человеком в частности. Как они реалистично строят отношения между собой и общество. Для тех кто проходят игры на ютубе сойдет.
537 Кб, 400x300>>54699 (OP)
И почему я раньше не догадался комбинировать несколько шумов?..
И почему я раньше не догадался комбинировать несколько шумов?..
>>56953
Э... У тебя же "вселенная наоборот". Какие там орбиты? ИМХО, при рытье тоннелей можно пренебречь силой тяготения, т.к. ты заперт в тесном бесконечно заполненном пространстве, а гравитация - слабейшее взаимодействие:
У тебя толщеходы постоянно опираются на и отталкиваются от "тверди", от которой же и питаются энергией. Было бы странно реализовывать силу тяготения и орбитальную механику в такой ситуации. Всё равно что кроты, выходящие на орбиту морковок в огороде... Т.е. даже банальное трение о поверхность туннеля должно быть сильнее гравитации, тем более что толщеход по идее разработан для максимально крепкого сцепления со стенками туннеля.
Да и потом, главное - чтобы фан от игры был. Будет ли фан от орбитальной механики в игре про толщеходы?
>физику, орбитальную механику
>свободно манипулировать векторами тяготения
Э... У тебя же "вселенная наоборот". Какие там орбиты? ИМХО, при рытье тоннелей можно пренебречь силой тяготения, т.к. ты заперт в тесном бесконечно заполненном пространстве, а гравитация - слабейшее взаимодействие:
>Gravity is, by far, the weakest of the four fundamental interactions, approximately 10 times weaker than the strong interaction, 10 times weaker than the electromagnetic force and 10 times weaker than the weak interaction. As a result, it has no significant influence at the level of subatomic particles.
У тебя толщеходы постоянно опираются на и отталкиваются от "тверди", от которой же и питаются энергией. Было бы странно реализовывать силу тяготения и орбитальную механику в такой ситуации. Всё равно что кроты, выходящие на орбиту морковок в огороде... Т.е. даже банальное трение о поверхность туннеля должно быть сильнее гравитации, тем более что толщеход по идее разработан для максимально крепкого сцепления со стенками туннеля.
Да и потом, главное - чтобы фан от игры был. Будет ли фан от орбитальной механики в игре про толщеходы?
Делойте
26 Кб, 800x480>>57067
Планирую зайти с более универсальной стороны: создать очередь модификаторов карты, которые друг за другом влияют на меш (или спавнят меши?).
Воспользуюсь мощью ООП наследования.
Шейдеры пока трогать не хочу. Следовал советам из интернета модифицировать в вершинном шейдере и это было сложно и затратно. Лучше уж заранее меш модифицировать, шейдер будет попроще.
Но сначала нужно в 2D общие карты отрисовать...
Кто знает, генерация коллизий потокобезопасна? Хотелось бы вынести весь код в отдельный поток.
Планирую зайти с более универсальной стороны: создать очередь модификаторов карты, которые друг за другом влияют на меш (или спавнят меши?).
Воспользуюсь мощью ООП наследования.
Шейдеры пока трогать не хочу. Следовал советам из интернета модифицировать в вершинном шейдере и это было сложно и затратно. Лучше уж заранее меш модифицировать, шейдер будет попроще.
Но сначала нужно в 2D общие карты отрисовать...
Кто знает, генерация коллизий потокобезопасна? Хотелось бы вынести весь код в отдельный поток.
364 Кб, 1920x1080Присоединяюсь к вашей секте. За вечерок наваял халтуру с нуля. Оказывается все не сложно, просто доки официальные написаны долбаебами, а вот в ютюбе по первой ссылке понятные гайды.
>>54699 (OP)
Объясните почему годот так популярен на этой доске? Со стороны кажется что 70% всех тех кто делает игры на этой доске делают на нем. Хотя на твг всего одна/пару игр обычно.
Объясните почему годот так популярен на этой доске? Со стороны кажется что 70% всех тех кто делает игры на этой доске делают на нем. Хотя на твг всего одна/пару игр обычно.
>>57182
Грамотный пиар. Хуан много денег платит. Пиши в личку, познакомлю тебя с нужными людьми.
Грамотный пиар. Хуан много денег платит. Пиши в личку, познакомлю тебя с нужными людьми.
>>57182
Потому что на остальных движках делают молчаливые гопники, а тут тусовочка.
Потому что на остальных движках делают молчаливые гопники, а тут тусовочка.
>>57191
Хули ты музыку из Unreal Gold спиздил, блять? Никогда не применяй проприетарные плейсхолдеры, уёбище, а то блядь забудешь в релизной версии и будешь кукарекать "АМИНЯТОЗАЩО", когда игру нахер удалят с площадок.
Хули ты музыку из Unreal Gold спиздил, блять? Никогда не применяй проприетарные плейсхолдеры, уёбище, а то блядь забудешь в релизной версии и будешь кукарекать "АМИНЯТОЗАЩО", когда игру нахер удалят с площадок.
40 Кб, 380x360>>57208
Ты ёбнутый? Трек на фоне включил, просто чтоб в видео играл, проспись.
Ты ёбнутый? Трек на фоне включил, просто чтоб в видео играл, проспись.
85 Кб, 675x1200
319 Кб, 640x640>>57225
Пасиба, полистаю на сайте какие нибудь затычки которые так и останутся в игре конечно, если знакомый не напишет треки, отсюда скорее всего буду брать
Пасиба, полистаю на сайте какие нибудь затычки которые так и останутся в игре конечно, если знакомый не напишет треки, отсюда скорее всего буду брать
>>57225
Ящитаю топ скилла поиска свободной музыки - найти годный трек с загрузками/прослушиваниями <100.
Саундклауд удачен для поиска таких хидден гемов. Только там ебланы редко указывают лицензию, приходится еще теги потрошить.
>3898 download(s)
Ящитаю топ скилла поиска свободной музыки - найти годный трек с загрузками/прослушиваниями <100.
Саундклауд удачен для поиска таких хидден гемов. Только там ебланы редко указывают лицензию, приходится еще теги потрошить.
40 Кб, 1024x580>>57167
Главное - выбрать правильное направление.
>>57168
Осуждаю такие советы новичкам, вредно.
1. Почему оно "где-то там"? А если его не будет?
2. Почему оно нам нужно? А нужно ли оно нам?
>>57181
CollisionShape3D вложи в StaticBody3D.
Не знаю, вроде понятно и доступно.
>>57182
Народный движок же, от народа народу.
Там другие люди, я вот ни разу не участвовал.
>>57191
От бедра отдача идёт в руку, а не в тело.
Главное - выбрать правильное направление.
>>57168
>Somewhere else entirely -> Register with autoload
Осуждаю такие советы новичкам, вредно.
1. Почему оно "где-то там"? А если его не будет?
2. Почему оно нам нужно? А нужно ли оно нам?
>>57181
CollisionShape3D вложи в StaticBody3D.
>официальные написаны долбаебами
Не знаю, вроде понятно и доступно.
>>57182
Народный движок же, от народа народу.
>Хотя на твг всего одна/пару игр обычно.
Там другие люди, я вот ни разу не участвовал.
>>57191
От бедра отдача идёт в руку, а не в тело.
>>57261
Я тебя скоро репортить начну. Отъебись от автолоада. Это стандартный механизм движка.
> Осуждаю такие советы новичкам, вредно.
Я тебя скоро репортить начну. Отъебись от автолоада. Это стандартный механизм движка.
>>57261
Это ты там советовал переписывать всю архитектуру, на случай если ВДРУГ захочется переделать игру в мультиплеер? Таблетки прими.
Это ты там советовал переписывать всю архитектуру, на случай если ВДРУГ захочется переделать игру в мультиплеер? Таблетки прими.
>>57268
Нет, скорее всего это был я. И снова посоветую.
Нет, скорее всего это был я. И снова посоветую.
>>57182
Много анонов уважает опенсорс, по понятным причинам.
Много анонов уважает опенсорс, по понятным причинам.
2 Кб, 256x50>>57261
То-есть чтобы машина не провалилась мне надо делать шейп не только машине, но и полу? Не уловил идею. Сам факт того что все проваливается через все по дефолту меня очень смущает.
>CollisionShape3D вложи в StaticBody3D.
То-есть чтобы машина не провалилась мне надо делать шейп не только машине, но и полу? Не уловил идею. Сам факт того что все проваливается через все по дефолту меня очень смущает.
>>57267
В чём твоя проблема? Просто не советую советовать автолоад как панацею от всех проблем доступа, чтоб новички не ходили по граблям как я:
"Somewhere" - это где? Новичок будет совать в твои любимые автолоады каждый свой скрипт. И зачем вообще нужно дерево сцен, если всю игру можно написать в одном скрипте автолоада?
Команда "goto" была стандартной во многих языках и повсеместно использовалась. И где она теперь?
https://en.wikipedia.org/wiki/Goto
>>57268
Godot - движок, в первую очередь, для прототипов. Естественно, что тебе захочется всё переделать. А ещё захочется использовать свой код из старого проекта в десятках новых проектов. Не хочется?
Все эти ноды, сцены, сигналы, GDScript - тут всё адаптировано для гибких переделок, чтобы части проекта могли свободно двигаться. Автолоады противоречат этой философии, прибивая твой код гвоздями к одной всюду доступной точке проекта.
В чём твоя проблема? Просто не советую советовать автолоад как панацею от всех проблем доступа, чтоб новички не ходили по граблям как я:
>Somewhere else entirely
"Somewhere" - это где? Новичок будет совать в твои любимые автолоады каждый свой скрипт. И зачем вообще нужно дерево сцен, если всю игру можно написать в одном скрипте автолоада?
>стандартный механизм
Команда "goto" была стандартной во многих языках и повсеместно использовалась. И где она теперь?
https://en.wikipedia.org/wiki/Goto
>>57268
>если ВДРУГ захочется переделать игру
Godot - движок, в первую очередь, для прототипов. Естественно, что тебе захочется всё переделать. А ещё захочется использовать свой код из старого проекта в десятках новых проектов. Не хочется?
Все эти ноды, сцены, сигналы, GDScript - тут всё адаптировано для гибких переделок, чтобы части проекта могли свободно двигаться. Автолоады противоречат этой философии, прибивая твой код гвоздями к одной всюду доступной точке проекта.
>>57275
Почитай документацию.
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
Базовая композиция сцены с физикой:
- Node или Node3D - корень сцены
- - StaticBody3D - неподвижное тело: платформа
- - - CollisionShape3D - коллизия платформы
- - - MeshInstance3D - графика платформы
- - RigidBody3D - подвижное тело: мячик
- - - CollisionShape3D - коллизия мячика
- - - MeshInstance3D - графика мячика
- - CharacterBody3D - тело, двигаемое кодом: игрок
- - - CollisionShape3D - коллизия игрока
- - - MeshInstance3D - графика игрока
- - Area3D - датчик объектов
- - - CollisionShape3D - коллизия (форма) датчика
И т.д.
CollisionShape3D сама по себе только контейнер для Shape, что передаётся наверх, конкретному CollisionObject3D, который может быть любым.
В играх далеко не всегда нужна физика столкновений, многие объекты могут обойтись без этого. Кроме того, несколько моделей могут быть частями одного целого физического объекта, а один объект может содержать несколько независимых физических частей.
Но есть несколько способов упростить задачу.
1. У MeshInstance3D на панели сверху окна сцены специальная кнопка позволяет сгенерировать физическую форму или сразу тело. Нужно помнить, что автоматическая форма не всегда оптимальна, особенно когда твой меш большой и сложный.
2. Прототип статичных декораций можно сделать из CSG-нод, у которых есть галочка "use collision", которая автоматически включает статическое тело (тут тоже не всё гладко: CSG объекты часто имеют сложные поверхности, физика на них может глючить).
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Почитай документацию.
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
>Не уловил идею.
Базовая композиция сцены с физикой:
- Node или Node3D - корень сцены
- - StaticBody3D - неподвижное тело: платформа
- - - CollisionShape3D - коллизия платформы
- - - MeshInstance3D - графика платформы
- - RigidBody3D - подвижное тело: мячик
- - - CollisionShape3D - коллизия мячика
- - - MeshInstance3D - графика мячика
- - CharacterBody3D - тело, двигаемое кодом: игрок
- - - CollisionShape3D - коллизия игрока
- - - MeshInstance3D - графика игрока
- - Area3D - датчик объектов
- - - CollisionShape3D - коллизия (форма) датчика
И т.д.
CollisionShape3D сама по себе только контейнер для Shape, что передаётся наверх, конкретному CollisionObject3D, который может быть любым.
>Сам факт того что все проваливается через все по дефолту меня очень смущает.
В играх далеко не всегда нужна физика столкновений, многие объекты могут обойтись без этого. Кроме того, несколько моделей могут быть частями одного целого физического объекта, а один объект может содержать несколько независимых физических частей.
Но есть несколько способов упростить задачу.
1. У MeshInstance3D на панели сверху окна сцены специальная кнопка позволяет сгенерировать физическую форму или сразу тело. Нужно помнить, что автоматическая форма не всегда оптимальна, особенно когда твой меш большой и сложный.
2. Прототип статичных декораций можно сделать из CSG-нод, у которых есть галочка "use collision", которая автоматически включает статическое тело (тут тоже не всё гладко: CSG объекты часто имеют сложные поверхности, физика на них может глючить).
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
>>57275
Почитай документацию.
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
Базовая композиция сцены с физикой:
- Node или Node3D - корень сцены
- - StaticBody3D - неподвижное тело: платформа
- - - CollisionShape3D - коллизия платформы
- - - MeshInstance3D - графика платформы
- - RigidBody3D - подвижное тело: мячик
- - - CollisionShape3D - коллизия мячика
- - - MeshInstance3D - графика мячика
- - CharacterBody3D - тело, двигаемое кодом: игрок
- - - CollisionShape3D - коллизия игрока
- - - MeshInstance3D - графика игрока
- - Area3D - датчик объектов
- - - CollisionShape3D - коллизия (форма) датчика
И т.д.
CollisionShape3D сама по себе только контейнер для Shape, что передаётся наверх, конкретному CollisionObject3D, который может быть любым.
В играх далеко не всегда нужна физика столкновений, многие объекты могут обойтись без этого. Кроме того, несколько моделей могут быть частями одного целого физического объекта, а один объект может содержать несколько независимых физических частей.
Но есть несколько способов упростить задачу.
1. У MeshInstance3D на панели сверху окна сцены специальная кнопка позволяет сгенерировать физическую форму или сразу тело. Нужно помнить, что автоматическая форма не всегда оптимальна, особенно когда твой меш большой и сложный.
2. Прототип статичных декораций можно сделать из CSG-нод, у которых есть галочка "use collision", которая автоматически включает статическое тело (тут тоже не всё гладко: CSG объекты часто имеют сложные поверхности, физика на них может глючить).
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Почитай документацию.
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
>Не уловил идею.
Базовая композиция сцены с физикой:
- Node или Node3D - корень сцены
- - StaticBody3D - неподвижное тело: платформа
- - - CollisionShape3D - коллизия платформы
- - - MeshInstance3D - графика платформы
- - RigidBody3D - подвижное тело: мячик
- - - CollisionShape3D - коллизия мячика
- - - MeshInstance3D - графика мячика
- - CharacterBody3D - тело, двигаемое кодом: игрок
- - - CollisionShape3D - коллизия игрока
- - - MeshInstance3D - графика игрока
- - Area3D - датчик объектов
- - - CollisionShape3D - коллизия (форма) датчика
И т.д.
CollisionShape3D сама по себе только контейнер для Shape, что передаётся наверх, конкретному CollisionObject3D, который может быть любым.
>Сам факт того что все проваливается через все по дефолту меня очень смущает.
В играх далеко не всегда нужна физика столкновений, многие объекты могут обойтись без этого. Кроме того, несколько моделей могут быть частями одного целого физического объекта, а один объект может содержать несколько независимых физических частей.
Но есть несколько способов упростить задачу.
1. У MeshInstance3D на панели сверху окна сцены специальная кнопка позволяет сгенерировать физическую форму или сразу тело. Нужно помнить, что автоматическая форма не всегда оптимальна, особенно когда твой меш большой и сложный.
2. Прототип статичных декораций можно сделать из CSG-нод, у которых есть галочка "use collision", которая автоматически включает статическое тело (тут тоже не всё гладко: CSG объекты часто имеют сложные поверхности, физика на них может глючить).
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
>>57280
В чём ТВОЯ? Ты же не воспринял совет, ты продолжаешь доёбываться. Свали нахуй в ишью на гитхабе и доказывай там Хуану, что автолоад ненужен.
> В чём твоя проблема?
В чём ТВОЯ? Ты же не воспринял совет, ты продолжаешь доёбываться. Свали нахуй в ишью на гитхабе и доказывай там Хуану, что автолоад ненужен.
>>57309
Ты чего такой серьёзный? Нормально ж общались.
Кто сказал, что не нужен? Нужен, но редко: чтобы автоматически загружать набор нод независимо от выбранной сцены, например, надпись с числом FPS. Поэтому доступ к ним из настроек проекта, а не напрямую с главного экрана редактора. Новичку о них знать вовсе не обязательно, а то и вредно.
Пойми, я говорю о тех, кто не имеет богатого опыта разработки. Наломать дров с автолодами намного проще, чем без них, несмотря на их пользу в ряде отдельных, специфических случаев.
Ты чего такой серьёзный? Нормально ж общались.
>автолоад ненужен
Кто сказал, что не нужен? Нужен, но редко: чтобы автоматически загружать набор нод независимо от выбранной сцены, например, надпись с числом FPS. Поэтому доступ к ним из настроек проекта, а не напрямую с главного экрана редактора. Новичку о них знать вовсе не обязательно, а то и вредно.
Пойми, я говорю о тех, кто не имеет богатого опыта разработки. Наломать дров с автолодами намного проще, чем без них, несмотря на их пользу в ряде отдельных, специфических случаев.
>>57288
Кажется начинаю понимать. Название CollisionShape3D ввело в заблуждение поначалу. Да, видел что можно автоматически добавлять коллизии. Даже одну так сделал.Не туда одну коллизию поставил, даже не заметил, и машина стала проваливаться. Еще предстоит толкать машину с места, и камеру в салон ставить. Интересно что на iOS есть приложение по годоту, если кому интересно. Небольшой справочник.
Пока планирую игру, постоянно что-то рисую на бумаге. Недавно сделал заметку со скриптом для генерации дорог пока сидел на работе. Очень простой скрипт. Его задача в том чтобы дорога не сворачивала больше чем на 90 градусов, то-есть генератор не начал сворачивать дорогу в калач. Ничего не сделал еще в плане текстур и сцен, а гейм дизайн раньше в голове выстраивается раньше чем понимание как соединять объекты в редакторе годота. Главное не начать делать все и сразу, а просто описать на бумаге, перечитать и немного попуститься. Попадаю в ловушку когда пытаюсь найти в годоте сходство с классами java, а тут другое мышление, даже не программистское, а скриптизерское что-ли. В общем удаляюсь на несколько дней чтобы что-нибудь приличное сделать прежде чем заливать скриншот в тред.
Кажется начинаю понимать. Название CollisionShape3D ввело в заблуждение поначалу. Да, видел что можно автоматически добавлять коллизии. Даже одну так сделал.Не туда одну коллизию поставил, даже не заметил, и машина стала проваливаться. Еще предстоит толкать машину с места, и камеру в салон ставить. Интересно что на iOS есть приложение по годоту, если кому интересно. Небольшой справочник.
Пока планирую игру, постоянно что-то рисую на бумаге. Недавно сделал заметку со скриптом для генерации дорог пока сидел на работе. Очень простой скрипт. Его задача в том чтобы дорога не сворачивала больше чем на 90 градусов, то-есть генератор не начал сворачивать дорогу в калач. Ничего не сделал еще в плане текстур и сцен, а гейм дизайн раньше в голове выстраивается раньше чем понимание как соединять объекты в редакторе годота. Главное не начать делать все и сразу, а просто описать на бумаге, перечитать и немного попуститься. Попадаю в ловушку когда пытаюсь найти в годоте сходство с классами java, а тут другое мышление, даже не программистское, а скриптизерское что-ли. В общем удаляюсь на несколько дней чтобы что-нибудь приличное сделать прежде чем заливать скриншот в тред.
>>57334
engine_force = достаточно большое значение.
По опыту, лучше увеличивать это значение плавно, чтобы оно не было слишком большим. Со слишком большим engine_force заднеприводный автомобиль встаёт на задние колёса... Как масл-кары в GTA 5.
>толкать машину с места
engine_force = достаточно большое значение.
По опыту, лучше увеличивать это значение плавно, чтобы оно не было слишком большим. Со слишком большим engine_force заднеприводный автомобиль встаёт на задние колёса... Как масл-кары в GTA 5.
Всем привет я новенький сегодня первый день тыкался в движке по уроку в ютубе, мне очень понравилось делать свою игру
Приятно с вами познакомиться, а тут можно чатик делать и дневничок или забанят?
Приятно с вами познакомиться, а тут можно чатик делать и дневничок или забанят?
>>57030
Воспоминание разблокировано: наблюдать за дефрагментацией диска в Вин98. Он ещё похрустывал так удовлетворительно.
Олсо, полистал ветку. Мне кажется анон >>56871
имел ввиду не ZPG, а отсутствие протагониста, ака персонификации игрока, внутри игры. А потом началась какая-то дичь с наблюдением за какими-то самодвижущимися системами. Кстати даже в классической конвеевской "жизни" игрок не полностью отсутствует, он раставляет клетки по полю и запускает/останавливает симуляцию.
Воспоминание разблокировано: наблюдать за дефрагментацией диска в Вин98. Он ещё похрустывал так удовлетворительно.
Олсо, полистал ветку. Мне кажется анон >>56871
>Игры могут быть без игрока.
имел ввиду не ZPG, а отсутствие протагониста, ака персонификации игрока, внутри игры. А потом началась какая-то дичь с наблюдением за какими-то самодвижущимися системами. Кстати даже в классической конвеевской "жизни" игрок не полностью отсутствует, он раставляет клетки по полю и запускает/останавливает симуляцию.
>>57349
Можно. Лучшие пикчи в шапку добавим.
Можно. Лучшие пикчи в шапку добавим.
>>57355
Зависит от того, рассматриваем ли мы "игру" как приложение для ПК или веб-сервера с каким-либо пользовательским интерфейсом, или как систему, работающую по своим внутренним правилам.
Игра "Жизнь" Конвея может рассматриваться как программа с GUI, через который пользователь расставляет клеточки на поле, но обычно, когда обсуждают эту игру, имеют в виду набор правил, по которым меняются клеточки на поле. И этот набор правил включает только соседние клетки на том же поле - в нём нет ни слова о каком-то там "игроке".
Считаю, в любой игре полезно абстрагироваться от устройств ввода и пользователя в целом. Не важно, как игрок взаимодействует с игрой, она всегда должна следовать чётким правилам.
Конечно, часто игры подстраиваются под игрока, например, в гонках машины под управлением ИИ ускоряются, если отстают от машины игрока, либо замедляются, если обогнали машину игрока. Всё ради того, чтобы игрок был в центре событий. Но теоретически можно было бы запустить гонку без игрока и машины ИИ будут гоняться сами с собой - гоночная игра существует сама по себе как набор правил движения гоночных машин, не так ли?
>игрок не полностью отсутствует
Зависит от того, рассматриваем ли мы "игру" как приложение для ПК или веб-сервера с каким-либо пользовательским интерфейсом, или как систему, работающую по своим внутренним правилам.
Игра "Жизнь" Конвея может рассматриваться как программа с GUI, через который пользователь расставляет клеточки на поле, но обычно, когда обсуждают эту игру, имеют в виду набор правил, по которым меняются клеточки на поле. И этот набор правил включает только соседние клетки на том же поле - в нём нет ни слова о каком-то там "игроке".
Считаю, в любой игре полезно абстрагироваться от устройств ввода и пользователя в целом. Не важно, как игрок взаимодействует с игрой, она всегда должна следовать чётким правилам.
Конечно, часто игры подстраиваются под игрока, например, в гонках машины под управлением ИИ ускоряются, если отстают от машины игрока, либо замедляются, если обогнали машину игрока. Всё ради того, чтобы игрок был в центре событий. Но теоретически можно было бы запустить гонку без игрока и машины ИИ будут гоняться сами с собой - гоночная игра существует сама по себе как набор правил движения гоночных машин, не так ли?
Выдрал из видео задник и одну из анимаций бега, и скомпоновал в мини уровень, где можно водить Гава влево-вправо.
Но в оригинале тень синего цвета. Как сделать такую в годо.
Для тени, я продублировал готовый Sprite2D, наклонил, и поменял цвет. Но цвет можно сделать только черный, хоть и полупрозрачный. Иначе в тени можно разглядеть сам спрайт.
Можно ли с помощью движка залить спрайт синим цветом?
И еще мне приходится дублировать управления на спрайт и на тень. Есть ли способ сделать тень чтобы она автоматически копировала спрайт?
Но в оригинале тень синего цвета. Как сделать такую в годо.
Для тени, я продублировал готовый Sprite2D, наклонил, и поменял цвет. Но цвет можно сделать только черный, хоть и полупрозрачный. Иначе в тени можно разглядеть сам спрайт.
Можно ли с помощью движка залить спрайт синим цветом?
И еще мне приходится дублировать управления на спрайт и на тень. Есть ли способ сделать тень чтобы она автоматически копировала спрайт?
>>57372
"Game" -этимологически значит приятное совместное времяпровождение.
"Игра" - этимологически значит движение
Видеоигры называются так из-за адаптации компаний выпускающих автоматы для азартных игр к запрету на азартные игры. Атари, нинтедо, вильямс(пинбол) это изначально компании обслуживающие именно сферу азартных игр. Весь этот дроч на то что в "играх должен быть геймплей" ногами упирается тупо в этот историзм. По-настоящему, развлекательный софт может быть намного шире и существует куча игр где геймплей далеко не на первом месте, от популуса, автошахмат и текстрима до метал гирек, хэви-рейвов и стейдж лайтов.
"Game" -этимологически значит приятное совместное времяпровождение.
"Игра" - этимологически значит движение
Видеоигры называются так из-за адаптации компаний выпускающих автоматы для азартных игр к запрету на азартные игры. Атари, нинтедо, вильямс(пинбол) это изначально компании обслуживающие именно сферу азартных игр. Весь этот дроч на то что в "играх должен быть геймплей" ногами упирается тупо в этот историзм. По-настоящему, развлекательный софт может быть намного шире и существует куча игр где геймплей далеко не на первом месте, от популуса, автошахмат и текстрима до метал гирек, хэви-рейвов и стейдж лайтов.
>>57389
Можно. Напиши простейший шейдер "Если Цвет.Альфа больше 0 то цвет = вектор 4 (0.,0.,1.,0.4)". Если не хочешь писать шейдер, можешь попробовать с материалом поиграть, но я хз.
Можно. Напиши простейший шейдер "Если Цвет.Альфа больше 0 то цвет = вектор 4 (0.,0.,1.,0.4)". Если не хочешь писать шейдер, можешь попробовать с материалом поиграть, но я хз.
Хром версии >=126 ломает все веб-игры на годоте. И тройку и четверку.
145 Кб, 720x658Потихоньку разбираюсь в движке, но понял что катастрофически не хватает кодерской базы. Какие ресурсы можно почитать по оптимизации кода / ИИ для болванчиков / процедурной генерации / организации кода и архитектуре проектов?
>>57410
Решай проблемы по мере их поступления.
Решай проблемы по мере их поступления.
112 Кб, 1134x856>>57394
Спасибо за наводку, шейдеры охуительны. Просто втыкаем какой надо цвет, без всяких вычислений.
А как комбинировать шейдеры? Хочу еще один шейдер добавить, чтобы сгибал тень. Часть тени которая на земле, чтобы сильно наклонена была, а часть которая падает на стену, чтобы вообще без наклона, как на видео.
>Напиши простейший шейдер
Спасибо за наводку, шейдеры охуительны. Просто втыкаем какой надо цвет, без всяких вычислений.
А как комбинировать шейдеры? Хочу еще один шейдер добавить, чтобы сгибал тень. Часть тени которая на земле, чтобы сильно наклонена была, а часть которая падает на стену, чтобы вообще без наклона, как на видео.
>>57416
Меня интересует, во первых, можно ли напихать больше одного шейдера в материал спрайта?
И во вторых, как комбинировать вертексные шейдеры с цветовыми. Но оказалось что это разные слои одного и того же шейдра.
>Добавлять в шейдер блоки и соединять их лапшой.
Меня интересует, во первых, можно ли напихать больше одного шейдера в материал спрайта?
И во вторых, как комбинировать вертексные шейдеры с цветовыми. Но оказалось что это разные слои одного и того же шейдра.
>>57419 >>57415
Читай документацию:
https://docs.godotengine.org/en/stable/tutorials/shaders/index.html
Также есть много бесплатных:
https://godotshaders.com/
Дополнительный шейдер тебе нужен обычно только если ты хочешь модульно комбинировать несколько шейдеров, например, добавить обводку или другой спецэффект поверх имеющегося. Тень персонажа возможно нарисовать одним шейдером.
>>57389
Тебе для чего? Ты у Союзмультфильм лицензию на использование данного персонажа получил? Если нет, они имеют легальное право убрать твою игру из любого легального маркета.
Если чисто для себя и близких, то ничего страшного.
Либо прикрепи спрайт тени к спрайту персонажа в дереве сцены, либо используй эту ноду:
https://docs.godotengine.org/en/stable/classes/class_remotetransform2d.html
Ты можешь вложить тень в потомки спрайта персонажа и включить у тени вот эту галочку:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-show-behind-parent
Читай документацию:
https://docs.godotengine.org/en/stable/tutorials/shaders/index.html
Также есть много бесплатных:
https://godotshaders.com/
Дополнительный шейдер тебе нужен обычно только если ты хочешь модульно комбинировать несколько шейдеров, например, добавить обводку или другой спецэффект поверх имеющегося. Тень персонажа возможно нарисовать одним шейдером.
>>57389
>можно водить Гава влево-вправо.
Тебе для чего? Ты у Союзмультфильм лицензию на использование данного персонажа получил? Если нет, они имеют легальное право убрать твою игру из любого легального маркета.
Если чисто для себя и близких, то ничего страшного.
>дублировать управления
Либо прикрепи спрайт тени к спрайту персонажа в дереве сцены, либо используй эту ноду:
https://docs.godotengine.org/en/stable/classes/class_remotetransform2d.html
Ты можешь вложить тень в потомки спрайта персонажа и включить у тени вот эту галочку:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-show-behind-parent
215 Кб, 980x551Курю сейчас официальный гайд с сайта и параллельно разные уроки на ютубчике. Харошый, нраица. А вот юнити харошый, не очень.
>>57428
Поискал. Оказалось у двухмерных шейдеров такого нету.
>>57431
Я спрашиваю у нейронки что мне нужно от шейдера и она дает готовый пример. А комбинировать эти примеры вместе особо нет желания. Не хочу пока на этом застревать ковыряясь в их потрохах и дебажить почему не работает комбинация из двух шейдеров. Хотелось на изи разные идеи с шейдерами перепробовать, соединяя их вместе более простыми путями.
Да я просто попытался разнообразить учебный процесс. Жаль не получилось отделить персонажа от фона с помощью нейронки.
Я продублировал ноду AnimatedSprite2D. Приходится в контроле, и теперь приходится еще дополнительно включать анимации и в спрайте тени. Просто я подумал было бы классно если бы можно было сделать инстанс, основного спрайта чтобы он полностью его повторял. Наверное можно было бы добавить тень, пририсовав ее шейдером в основном спрайте без всякого дублирования. Или сделать родительскую ноду над спрайтом и тенью. И обновлять их как-то вместе.
А вообще, оказалось сложнее чем ожидал. Надо бы пока эту тень оставить и вернуться потом со свежей головой.
>next_pass
Поискал. Оказалось у двухмерных шейдеров такого нету.
>>57431
>документацию
>есть много бесплатных
>Тень персонажа возможно нарисовать одним шейдером
Я спрашиваю у нейронки что мне нужно от шейдера и она дает готовый пример. А комбинировать эти примеры вместе особо нет желания. Не хочу пока на этом застревать ковыряясь в их потрохах и дебажить почему не работает комбинация из двух шейдеров. Хотелось на изи разные идеи с шейдерами перепробовать, соединяя их вместе более простыми путями.
>Союзмультфильм
Да я просто попытался разнообразить учебный процесс. Жаль не получилось отделить персонажа от фона с помощью нейронки.
>используй эту ноду
>вложить тень в потомки спрайта
Я продублировал ноду AnimatedSprite2D. Приходится в контроле, и теперь приходится еще дополнительно включать анимации и в спрайте тени. Просто я подумал было бы классно если бы можно было сделать инстанс, основного спрайта чтобы он полностью его повторял. Наверное можно было бы добавить тень, пририсовав ее шейдером в основном спрайте без всякого дублирования. Или сделать родительскую ноду над спрайтом и тенью. И обновлять их как-то вместе.
А вообще, оказалось сложнее чем ожидал. Надо бы пока эту тень оставить и вернуться потом со свежей головой.
30,2 Мб, mp4,1280x708, 1:25
>>57191
Изменил немного арену, добавил не лицензированные треки и немног анимации поменял. Хотел ещё всякие дэш атаки боссу дать, но слишком туп для этого, займусь может после катсцен и локаций
Изменил немного арену, добавил не лицензированные треки и немног анимации поменял. Хотел ещё всякие дэш атаки боссу дать, но слишком туп для этого, займусь может после катсцен и локаций
297 Кб, 1901x1034Пацаны, я свою первую альфа версию игры сделал. Называется shit clicker.
Короче когда нажимаешь на джордж флойда оно считает количество нажатий.
Как мне теперь её в плеймаркете опубликовать чтобы рубить шекели?
И как сделал форму кнопки ровно по ебальнику флойда?
Короче когда нажимаешь на джордж флойда оно считает количество нажатий.
Как мне теперь её в плеймаркете опубликовать чтобы рубить шекели?
И как сделал форму кнопки ровно по ебальнику флойда?
>>57510
Или лучше сразу релизнуть в стиме, я считаю, что такой АААА гейминг заслуживает ценника в 70$
Или лучше сразу релизнуть в стиме, я считаю, что такой АААА гейминг заслуживает ценника в 70$
>>57393
Задорнова переслушал?
Ни в какой момент истории ни в одной ветке славянских языков слово "игра" не было даже и краешком связано со смыслом "движение".
>"Игра" - этимологически значит движение
Задорнова переслушал?
Ни в какой момент истории ни в одной ветке славянских языков слово "игра" не было даже и краешком связано со смыслом "движение".
>>57545
[jьgra] - Древнерусская фонетика слова "игра"
[jьgra] - Древнерусска фонетика слова "движение" - "ёра", от которого прозошло, например, слово "ёрзать"
[jьgra] - Древнерусская фонетика слова "игра"
[jьgra] - Древнерусска фонетика слова "движение" - "ёра", от которого прозошло, например, слово "ёрзать"
18 Кб, 200x200>>57554
Двачую этого. Латинский язык произошёл от древнерусского (Rasenna, Raśna) — древняя цивилизация, населявшая в I тысячелетии до н. э. северо-запад Апеннинского полуострова (область — древняя Этрурия, современная Тоскана) так же этруски).
Затем от латинского произошли все европейские языки.
Двачую этого. Латинский язык произошёл от древнерусского (Rasenna, Raśna) — древняя цивилизация, населявшая в I тысячелетии до н. э. северо-запад Апеннинского полуострова (область — древняя Этрурия, современная Тоскана) так же этруски).
Затем от латинского произошли все европейские языки.
Может кто подскажет, делаю механику курения, огонек сигареты сделан через 3D Patricles. В статике все нормально, конец сигареты горит, но при повороте камеры, партикл отстает и на экране на милисекунду появляется. Тоже самое при ходьбе и падениях. Как можно пофиксить? Лайфтайм и так стоит 0.01 секунда, меньше нельзя
43 Кб, 307x365>>57573В игре ничего нельзя делать кроме как доставать открывать пачку, доставать сигарету и курить ее
>>57575
ну вот получается партикл как child у сигареты, visibility AABB маленьким квадратиком выставлен тоже
ну вот получается партикл как child у сигареты, visibility AABB маленьким квадратиком выставлен тоже
>>57575
я так понимаю что это из-за того что партикл не успевает "умирать" и остается на том месте где был до поворота камеры
я так понимаю что это из-за того что партикл не успевает "умирать" и остается на том месте где был до поворота камеры
Нихуя не могу понять. У меня тело под силой гравитации (сфера коллизия) медленно опускается на StaticBody3D (плоская коллизия), которое служит полом сцены, но это пол начинает мотать круги вокруг мирно падающего предмета. Как прибить гвоздями статичное тело? Я хуею, не могу найти простую галочку "блять не шатай боди, просто прибей гвоздями". Боди крутится будто у него веса вообще нет. Чтение форумов не помогло, а в доках не знаю с какой статьи начать. Пока что заменил коллизию сферу на прямоугольник, но это просто костыль.
20 Кб, 338x350>>57578
Там внутри партикля есть опция локальных координат, как показано на прилагаемом скриншоте. Опция выключена по умолчанию. Включи её.
Там внутри партикля есть опция локальных координат, как показано на прилагаемом скриншоте. Опция выключена по умолчанию. Включи её.
25 Кб, 620x432>>57587
По одной. Но зато в ней есть высокодетализированный советский шкаф, как у бабушки в детстве.
> По скольким локациям уже можно погонять?
По одной. Но зато в ней есть высокодетализированный советский шкаф, как у бабушки в детстве.
>>57584
StaticBody3D никак движком не двигается, ты сам двигаешь его из своего кода, если хочешь.
Скорее всего ты сам запутался, где у тебя пол, а где потолок. Добавь (вывернутый) куб с координатами "это пол (Y-), это потолок (Y+), это стены (X, Z)". Без коллизий, просто висящий в пространстве куб.
>StaticBody3D, которое служит полом сцены
>Как прибить гвоздями статичное тело?
StaticBody3D никак движком не двигается, ты сам двигаешь его из своего кода, если хочешь.
Скорее всего ты сам запутался, где у тебя пол, а где потолок. Добавь (вывернутый) куб с координатами "это пол (Y-), это потолок (Y+), это стены (X, Z)". Без коллизий, просто висящий в пространстве куб.
>>57584
А, кажется, я понял твою проблему.
Ты привязал камеру к сфере без текстур? И площадка ВНЕЗАПНО начинает вращаться вокруг сферы, только когда сфера касается площадки? А небо с горизонтом у тебя пока не настроено?
Тогда всё понятно. На самом деле это не площадка вращается, а шарик катится по площадке. А камера, через которую ты смотришь, вращается вместе с шариком, и это создаёт иллюзию, будто вращается площадка. Добавь небо с горизонтом и увидишь:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#preview-environment-and-sun-low-priority
Также советую всё обмазать текстурой-сеткой:
https://kenney.nl/assets/prototype-textures
Или такой: https://uvchecker.vinzi.xyz/
А, кажется, я понял твою проблему.
Ты привязал камеру к сфере без текстур? И площадка ВНЕЗАПНО начинает вращаться вокруг сферы, только когда сфера касается площадки? А небо с горизонтом у тебя пока не настроено?
Тогда всё понятно. На самом деле это не площадка вращается, а шарик катится по площадке. А камера, через которую ты смотришь, вращается вместе с шариком, и это создаёт иллюзию, будто вращается площадка. Добавь небо с горизонтом и увидишь:
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#preview-environment-and-sun-low-priority
Также советую всё обмазать текстурой-сеткой:
https://kenney.nl/assets/prototype-textures
Или такой: https://uvchecker.vinzi.xyz/
>>57635
заорал))
заорал))
>>57578
Тебе написали про локальные координаты.
Суть в том, что если координаты глобальные, то партикл относительно глобального мира (актуально например в случае искр из под колес), а если локальные, то относительно спавнера.
Тебе написали про локальные координаты.
Суть в том, что если координаты глобальные, то партикл относительно глобального мира (актуально например в случае искр из под колес), а если локальные, то относительно спавнера.
>>57584
Показывай видео или скрин дерева сцены хотя бы. Одно предположение что ты их привязал чайлдом друг к другу и движение одного двигает и другое.
Показывай видео или скрин дерева сцены хотя бы. Одно предположение что ты их привязал чайлдом друг к другу и движение одного двигает и другое.
>>57651
Я проверял, такое почему-то не работает:
- RigidBody3D
- - StaticBody3D
Статик останется неподвижно в пространстве.
>предположение что ты их привязал чайлдом друг к другу и движение одного двигает и другое.
Я проверял, такое почему-то не работает:
- RigidBody3D
- - StaticBody3D
Статик останется неподвижно в пространстве.
>>54699 (OP)
Сегодня размышлял об ИИ для персонажей и вот вспомнил, как делал для себя аддон в ноябре.
Сначала я хотел просто фреймворк для нелинейных историй с удобным GUI, но потом этот проект начал мутировать в универсальный граф чего угодно, чтоб служить затычкой в любой разветвлённой бочке. Но почему-то приуныл тогда и забросил всё это.
Концепция была такова. Основной блок "sequence" - это линейный набор строк с тегами или чего-то ещё, если возможно (хотелось прикрутить типизацию, но непонятно как). У этого блока есть вход и выход, их можно соединять с другими блоками. Несколько соединений с выходом - это select/option, несколько соединений со входом - это merge (слияние веток). Обрабатывается граф специальной виртуальной машиной, которая делает все переходы, формирует списки опций на развилках. Что делать со строками и тегами решает сам пользователь, машина только возвращает значения из ячеек sequence.
Очень хотелось добавить условные выражения для блокирования входа в блоки и/или автоматического выбора следующего блока без внешней обработки. Однако я не разобрался, как это лучше сделать; тупо накидывать выпадающие менюшки мне надоело.
Идея с sequence возникла для решения проблемы, когда в редакторе с ниточками нужна некая длинная последовательность. У меня это столбиком, нитки в основном для развилок и слияний блоков. Нитки полезны для визуального представления ветвления, которое в линейной записи часто неудобно выглядит. Разумеется, сделал drag&drop для строк sequence, поэтому их легко делить на части по необходимости (конечно, в идеале нужно однокнопочное решение). Вообще, хотелось сделать что-то вроде инспектора ресурсов, только с ветвлением ниточками...
TL;DR: хочу всё и непонятно что => до ума не довёл.
В общем, что скажете? Ненужный велосипед?
Не помню, постил это здесь или нет?
Сегодня размышлял об ИИ для персонажей и вот вспомнил, как делал для себя аддон в ноябре.
Сначала я хотел просто фреймворк для нелинейных историй с удобным GUI, но потом этот проект начал мутировать в универсальный граф чего угодно, чтоб служить затычкой в любой разветвлённой бочке. Но почему-то приуныл тогда и забросил всё это.
Концепция была такова. Основной блок "sequence" - это линейный набор строк с тегами или чего-то ещё, если возможно (хотелось прикрутить типизацию, но непонятно как). У этого блока есть вход и выход, их можно соединять с другими блоками. Несколько соединений с выходом - это select/option, несколько соединений со входом - это merge (слияние веток). Обрабатывается граф специальной виртуальной машиной, которая делает все переходы, формирует списки опций на развилках. Что делать со строками и тегами решает сам пользователь, машина только возвращает значения из ячеек sequence.
Очень хотелось добавить условные выражения для блокирования входа в блоки и/или автоматического выбора следующего блока без внешней обработки. Однако я не разобрался, как это лучше сделать; тупо накидывать выпадающие менюшки мне надоело.
Идея с sequence возникла для решения проблемы, когда в редакторе с ниточками нужна некая длинная последовательность. У меня это столбиком, нитки в основном для развилок и слияний блоков. Нитки полезны для визуального представления ветвления, которое в линейной записи часто неудобно выглядит. Разумеется, сделал drag&drop для строк sequence, поэтому их легко делить на части по необходимости (конечно, в идеале нужно однокнопочное решение). Вообще, хотелось сделать что-то вроде инспектора ресурсов, только с ветвлением ниточками...
TL;DR: хочу всё и непонятно что => до ума не довёл.
В общем, что скажете? Ненужный велосипед?
Не помню, постил это здесь или нет?
Кароч, положняк с кликером такой, все готово, кроме скринов и видосов, которые я бля из за 4:3 моника сделать не могу в фхд, пришлось знакомого попросить сделать, жду вот когда скинет. Останется смонтировать и можно релизить.
Некст буду тдшку делать, точнее уже чутка начал. Чувствую больше всего со звуком намучаюсь.
Бывайте.
Некст буду тдшку делать, точнее уже чутка начал. Чувствую больше всего со звуком намучаюсь.
Бывайте.
>>57676
По-моему, можно сделать разрешение окна игры значительно больше разрешения экрана. И сделать скриншоты и видео с него. Конечно, кликать можно будет только в области, которая умещается в экран, однако, если у тебя весь кликабельный гуй с одной стороны, в настройках редактора есть опция для размещения окна игры в конкретном месте.
>сделать не могу в фхд
По-моему, можно сделать разрешение окна игры значительно больше разрешения экрана. И сделать скриншоты и видео с него. Конечно, кликать можно будет только в области, которая умещается в экран, однако, если у тебя весь кликабельный гуй с одной стороны, в настройках редактора есть опция для размещения окна игры в конкретном месте.
29 Кб, 1000x600>>57673
Ещё проблема: продумал возможность создания циклических связей, однако как разместить нитки визуально, чтоб легко читалось - непонятно. Вроде настройка изгиба есть, но как я посчитаю изгиб? Полностью вручную рисовать пробовал - опять же, необходимо как-то определить границы блоков...
Вот пример с тегами. В теории, их должна парсить виртуальная машина (не проблема со StringName), а дальше игра делает какие-то действия: выводит картинки, анимации, спецэффекты, надписи. Пока недоделано, но я планировал сделать менеджер, в котором к тегам можно привязать какие угодно данные, вроде png картинок. Плюс хотелось бы автодополнение при вводе тега в ячейку...
Вообще много чего придумал, но недоделал. Скажем, объединение в группы или "рабочие столы": можно разместить блоки в разных вкладках для удобства. Или вот хотелось сделать вызов метода скрипта. Вообще писать кусочки скриптов. В теории можно, но как проверять валидность кода? Сложно будет.
Какое отношение к игровому ИИ? Хотелось сделать редактор иерархических конечных автоматов или что-то в этом роде. Видел готовые аддоны, но мне совершенно не нравится юзать ноды для этого.
Приуныл и растерял мотивацию. Как всегда...
Ещё проблема: продумал возможность создания циклических связей, однако как разместить нитки визуально, чтоб легко читалось - непонятно. Вроде настройка изгиба есть, но как я посчитаю изгиб? Полностью вручную рисовать пробовал - опять же, необходимо как-то определить границы блоков...
Вот пример с тегами. В теории, их должна парсить виртуальная машина (не проблема со StringName), а дальше игра делает какие-то действия: выводит картинки, анимации, спецэффекты, надписи. Пока недоделано, но я планировал сделать менеджер, в котором к тегам можно привязать какие угодно данные, вроде png картинок. Плюс хотелось бы автодополнение при вводе тега в ячейку...
Вообще много чего придумал, но недоделал. Скажем, объединение в группы или "рабочие столы": можно разместить блоки в разных вкладках для удобства. Или вот хотелось сделать вызов метода скрипта. Вообще писать кусочки скриптов. В теории можно, но как проверять валидность кода? Сложно будет.
Какое отношение к игровому ИИ? Хотелось сделать редактор иерархических конечных автоматов или что-то в этом роде. Видел готовые аддоны, но мне совершенно не нравится юзать ноды для этого.
Приуныл и растерял мотивацию. Как всегда...
2,5 Мб, mp4,1920x1080, 0:42
>>57651
>>57657
Ощутил прилив сил вечером и стал играться с кэфами. Первое что сделал это добавил коллизию главной ноде. Просто забыл, из-за чего обидно. Потом понизил усиление пружин на колесах. В общем сделал неопрокидываемое авто, физон которому можно улучшать бесконечно. Можете использовать мой рецепт для гонащек.
>>57657
Ощутил прилив сил вечером и стал играться с кэфами. Первое что сделал это добавил коллизию главной ноде. Просто забыл, из-за чего обидно. Потом понизил усиление пружин на колесах. В общем сделал неопрокидываемое авто, физон которому можно улучшать бесконечно. Можете использовать мой рецепт для гонащек.
>>57686
Ещё такая мысль, изначально я сделал возможным сворачивать (минимизировать) блок, чтобы остался только заголовок и связи, для этого кнопка с иконкой свитка (скрипта). Но я видел где-то такой подход, что спискота отображается в отдельном боковом меню, а граф содержит только ноды с заголовками. Думаю попробовать так, но тогда нельзя будет захватить всё содержимое графа в один скриншот, и могут быть дополнительные проблемы с drag&drop'ом.
Ещё такая мысль, изначально я сделал возможным сворачивать (минимизировать) блок, чтобы остался только заголовок и связи, для этого кнопка с иконкой свитка (скрипта). Но я видел где-то такой подход, что спискота отображается в отдельном боковом меню, а граф содержит только ноды с заголовками. Думаю попробовать так, но тогда нельзя будет захватить всё содержимое графа в один скриншот, и могут быть дополнительные проблемы с drag&drop'ом.
>>57681
Сложно как то и неудобно, да и фуллскрин у меня запускается на мое разрешение а не проекта.
Сложно как то и неудобно, да и фуллскрин у меня запускается на мое разрешение а не проекта.
12 Кб, 432x227Делаю настольную 2д игру, в ней будут кубы, некоторые из них можно перебросить, как сделать так чтобы по клику можно было выбрать кубы, которые я хочу перебросить? Прикрепить анимированный спрайт к кнопке? И как это все дело выровнять горизонтально, подскажите плз
>>57701
Делай контрол нодами. Сделай грид или Хсплит контейнер и засунь свои кубы туда для автовыравнивания. И используй не анимированнвй спрайт, а Текстурированый прямоугольник. Засунь свои кубы в ресурс анимейтед текстуре и меняй номер кадра для куба.
Делай контрол нодами. Сделай грид или Хсплит контейнер и засунь свои кубы туда для автовыравнивания. И используй не анимированнвй спрайт, а Текстурированый прямоугольник. Засунь свои кубы в ресурс анимейтед текстуре и меняй номер кадра для куба.
4.3 Beta 2
https://godotengine.org/article/dev-snapshot-godot-4-3-beta-2/
Дисклеймер: делайте бэкап проектов, есть несовместимые изменения.
Однопоточный веб экспорт
Проигрыватель сэмплов, для веб аудио без заиканий. Очевидные подводные это не для процедурных звуков. И надо прогружать заранее.
Улучшенный бутскрин
Обещают улучшение работы веб экспорта на айфонах
Добавление в веб рендер недостававших: MSAA and resolution scaling, Glow, ReflectionProbes, LightMapGI, Adjustments and Color Correction
Какой то рефакторинг AnimationPlayer, пока не читал что именно https://godotengine.org/article/migrating-animations-from-godot-4-0-to-4-3/
Добавлена нода SkeletonModifier3D, вроде то что не успели к 4.0
Импорт fbx без сторонней утилиты.
Обратный буфер глубины 3д, некоторые шейдеры надо переписывать https://godotengine.org/article/introducing-reverse-z/
Некоторые улучшения для пиксель перфект 2д игр, https://godotengine.org/article/dev-snapshot-godot-4-3-beta-1/
Оптимизация рендерграфа, возможное ускорение на 10%
Автообновление версии движка из хаба
https://godotengine.org/article/dev-snapshot-godot-4-3-beta-2/
Дисклеймер: делайте бэкап проектов, есть несовместимые изменения.
Однопоточный веб экспорт
Проигрыватель сэмплов, для веб аудио без заиканий. Очевидные подводные это не для процедурных звуков. И надо прогружать заранее.
Улучшенный бутскрин
Обещают улучшение работы веб экспорта на айфонах
Добавление в веб рендер недостававших: MSAA and resolution scaling, Glow, ReflectionProbes, LightMapGI, Adjustments and Color Correction
Какой то рефакторинг AnimationPlayer, пока не читал что именно https://godotengine.org/article/migrating-animations-from-godot-4-0-to-4-3/
Добавлена нода SkeletonModifier3D, вроде то что не успели к 4.0
Импорт fbx без сторонней утилиты.
Обратный буфер глубины 3д, некоторые шейдеры надо переписывать https://godotengine.org/article/introducing-reverse-z/
Некоторые улучшения для пиксель перфект 2д игр, https://godotengine.org/article/dev-snapshot-godot-4-3-beta-1/
Оптимизация рендерграфа, возможное ускорение на 10%
Автообновление версии движка из хаба
>>57712
Или пользуйтесь godot-manager и тогда вы будете уверены, что ваш проект запускается на явно настроенной для него версии движка.
> делайте бэкап проектов
Или пользуйтесь godot-manager и тогда вы будете уверены, что ваш проект запускается на явно настроенной для него версии движка.
>>57713
Речь про ситуацию, когда ты захотел перевести проект на след. версию, например ждал какую то фичу или исправление бага, но потом не понравилось, допустим появился другой баг, и ты хочешь открыть старой версией, но так не выйдет.
Речь про ситуацию, когда ты захотел перевести проект на след. версию, например ждал какую то фичу или исправление бага, но потом не понравилось, допустим появился другой баг, и ты хочешь открыть старой версией, но так не выйдет.
>>57687
Ты подвеску убил - не держит машину.
Такие настройки попробуй.
>понизил усиление пружин на колесах
Ты подвеску убил - не держит машину.
>неопрокидываемое авто
Такие настройки попробуй.
76 Кб, 545x800>>57687
Зачем? Она (Node3D) коллизию не принимает.
Читай внимательно:
https://docs.godotengine.org/en/stable/classes/class_collisionshape3d.html
Т.е. она нужна только потомкам этого класса:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html
Лично от себя рекомендую держать CollisionShape3D в списке потомков ближе всего к её предку, чтобы в случае чего сразу видеть, к чему она относится:
- физическое тело или зона-датчик
- - форм(а/ы) коллизии
- - визуальная модель
- - колёса и всё такое прочее
>добавил коллизию главной ноде
Зачем? Она (Node3D) коллизию не принимает.
Читай внимательно:
https://docs.godotengine.org/en/stable/classes/class_collisionshape3d.html
>A node that provides a Shape3D to a CollisionObject3D parent and allows to edit it. This can give a detection shape to an Area3D or turn a PhysicsBody3D into a solid object.
Т.е. она нужна только потомкам этого класса:
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html
>Abstract base class for 3D physics objects. CollisionObject3D can hold any number of Shape3Ds for collision.
Лично от себя рекомендую держать CollisionShape3D в списке потомков ближе всего к её предку, чтобы в случае чего сразу видеть, к чему она относится:
- физическое тело или зона-датчик
- - форм(а/ы) коллизии
- - визуальная модель
- - колёса и всё такое прочее
Я покакал сделал 2д игру из официального гайда. Такие дела. Теперь я могу писать в резюме, что я разработчик компутерных игор?
>>57717
Полагаю что у VehicleBody3D из коробки откровенно всратые параметры физона по умолчанию, и поэтому многие разрабы берут сбалансированный RidgidBody3D чтобы хуяк-хуяк и сразу в игру закинуть. На данный момент у меня пружины дают адовейший body roll, который напрямую зависит от массы авто и гравитации. У тебя на видео лимузин рассекает в поле с физоном из роблокса, поэтому он устойчив. Столб с 4 колесами еще устойчивей будет, но можем ли мы его назвать машиной?
Попробую найти материал по зависимости параметров физона друг от друга. Не зря же советуют при массе 1000 делать тормоз 25. Существуют коэфы, которые предусмотрели разрабы, и при других значениях физон становится не очень.
Полагаю что у VehicleBody3D из коробки откровенно всратые параметры физона по умолчанию, и поэтому многие разрабы берут сбалансированный RidgidBody3D чтобы хуяк-хуяк и сразу в игру закинуть. На данный момент у меня пружины дают адовейший body roll, который напрямую зависит от массы авто и гравитации. У тебя на видео лимузин рассекает в поле с физоном из роблокса, поэтому он устойчив. Столб с 4 колесами еще устойчивей будет, но можем ли мы его назвать машиной?
Попробую найти материал по зависимости параметров физона друг от друга. Не зря же советуют при массе 1000 делать тормоз 25. Существуют коэфы, которые предусмотрели разрабы, и при других значениях физон становится не очень.
62 Кб, 804x395Сап, /gd/.
Хочу сохранять сцену как в различных РПГ от бефезды типа Skyrim, Fallout 3, чтобы все объекты сохранялись в том же положении, с теми же характеристиками и переменными, что и в момент игры. Я попробовал использовать методы ResourceSaver и Resourceloader. Они работают не так, как мне надо. Когда я сохраняю сцену, сохраняются только те объекты, которые были заранее на ней в момент её создания. Если добавить на сцену новый объект при помощи add_child(), он не будет сохраняться, при этом никакой ошибки редактор не выдаёт. Предметы можно свободно передвигать, физические объекты сохраняют инерцию и энергию, а новые дети сцены просто испаряются.
Сначала я попробовал это исправить через перебор всех детей сцены при помощи цикла for и метода PackedScene.pack(), но это не сработало потому что .pack() сохраняет только одну ноду, а прежнюю ноду из PackedScene стирает. Что надо сделать, чтобы сохранялись все ноды current_scene в файл PackedScene?
Хочу сохранять сцену как в различных РПГ от бефезды типа Skyrim, Fallout 3, чтобы все объекты сохранялись в том же положении, с теми же характеристиками и переменными, что и в момент игры. Я попробовал использовать методы ResourceSaver и Resourceloader. Они работают не так, как мне надо. Когда я сохраняю сцену, сохраняются только те объекты, которые были заранее на ней в момент её создания. Если добавить на сцену новый объект при помощи add_child(), он не будет сохраняться, при этом никакой ошибки редактор не выдаёт. Предметы можно свободно передвигать, физические объекты сохраняют инерцию и энергию, а новые дети сцены просто испаряются.
Сначала я попробовал это исправить через перебор всех детей сцены при помощи цикла for и метода PackedScene.pack(), но это не сработало потому что .pack() сохраняет только одну ноду, а прежнюю ноду из PackedScene стирает. Что надо сделать, чтобы сохранялись все ноды current_scene в файл PackedScene?
>>57760
Что ты имеешь ввиду? Эти функции не подходят для сейвов?
В голове есть представление как делать систему из создания новых и перезаписывания старых сохранений, это потом имплементирую. Сейчас пока с одним файлом работаю.
>Но вообще тут надо делать свою систему сейвов.
Что ты имеешь ввиду? Эти функции не подходят для сейвов?
В голове есть представление как делать систему из создания новых и перезаписывания старых сохранений, это потом имплементирую. Сейчас пока с одним файлом работаю.
11 Кб, 383x145>>57759
Сохраняешь ноду - проставляешь всем ее детям овнеров. А "своя система сейвов" не нужна. У меня два проекта на пакед сценах сделаны, полет нормальный.
Сохраняешь ноду - проставляешь всем ее детям овнеров. А "своя система сейвов" не нужна. У меня два проекта на пакед сценах сделаны, полет нормальный.
>>57759
Алсо для сохранения на диск я использую бинарный .scn вместо .tscn. С tscn был какой-то баг, уже не помню какой, писал о нем ИТТ тредов 15 назад.
Алсо для сохранения на диск я использую бинарный .scn вместо .tscn. С tscn был какой-то баг, уже не помню какой, писал о нем ИТТ тредов 15 назад.
>>57760
Блин, чёт не работает.
У меня в коде записано примерно так:
holded = объект, который игрок держит в руках
face_cast.get_collider( объект, на который смотрит игрок ).add_child( holded )
holded.set_owner( holded.get_parent() )
Почему-то не работает, хотя проверка через print(holded.owner) показывает то что ожидалось.
>>57762
А какой смысл в пикрил? Разве овнеры сразу ещё не расставлены? Вроде всё нормально сохраняется кроме добавленных нодов. Энивей, попробую, с чем чёрт не шутит!
>>57764
Посмотрим, попробуем
>owner
Блин, чёт не работает.
У меня в коде записано примерно так:
holded = объект, который игрок держит в руках
face_cast.get_collider( объект, на который смотрит игрок ).add_child( holded )
holded.set_owner( holded.get_parent() )
Почему-то не работает, хотя проверка через print(holded.owner) показывает то что ожидалось.
>>57762
А какой смысл в пикрил? Разве овнеры сразу ещё не расставлены? Вроде всё нормально сохраняется кроме добавленных нодов. Энивей, попробую, с чем чёрт не шутит!
>>57764
Посмотрим, попробуем
>>57766
Нет, овнеры не расставлены. Это не родители, это фича скорее от движка для движка.
> A node can have any other node as owner (as long as it is a valid parent, grandparent, etc. ascending in the tree). When saving a node (using PackedScene), all the nodes it owns will be saved with it. This allows for the creation of complex SceneTrees, with instancing and subinstancing.
>Note: If you want a child to be persisted to a PackedScene, you must set owner in addition to calling add_child(). This is typically relevant for tool scripts and editor plugins. 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.
Нет, овнеры не расставлены. Это не родители, это фича скорее от движка для движка.
>>57761
Потому что в отличии от второго ответившего анона, я не считаю что для игры "типа скайрима" нужен сейв сцены со всеми коллайдерами и прочими зависимостями. А нужен сейв "предметной модели" - сохранить, например, что условная телега сейчас по координатам xyz под углом uvw, а при загрузке спавнить нужную сцену с коллайдером в нужном месте.
Потому что в отличии от второго ответившего анона, я не считаю что для игры "типа скайрима" нужен сейв сцены со всеми коллайдерами и прочими зависимостями. А нужен сейв "предметной модели" - сохранить, например, что условная телега сейчас по координатам xyz под углом uvw, а при загрузке спавнить нужную сцену с коллайдером в нужном месте.
>>57762
Сработало!!! Спасибо, не все герои носят плащи
>>57767
Понял, спасибо
>>57768
Я об этом думал, но понял, что гораздо проще в моём случае (небольшие, практически комнатные сцены) всю сцену сохранять в один файл. Понятное дело, что в игре с открытым миром каждый раз сохранять всю карту на отдельный сейв просто неразумно, а загрузки будут долгими.
Сработало!!! Спасибо, не все герои носят плащи
>>57767
Понял, спасибо
>>57768
Я об этом думал, но понял, что гораздо проще в моём случае (небольшие, практически комнатные сцены) всю сцену сохранять в один файл. Понятное дело, что в игре с открытым миром каждый раз сохранять всю карту на отдельный сейв просто неразумно, а загрузки будут долгими.
>>57738
Да, параметры странные, не менялись годами.
Я несколько раз пробовал сделать велосипед на RigidBody3D, это довольно сложно, я не осилил.
Поставь roll_influence = 1 или 2, немного поможет.
Там габариты чуть короче и шире, чем у Жигулей.
Даже в GTA 5 (!) увеличили силу тяжести машинам, прижимая их к асфальту так, будто они на рельсах.
Нет. Чем выше центр тяжести, тем легче опрокинуть, поэтому специально занизил центр тяжести (смотри внимательнее на center of mass у VehicleBody3D).
На видео вообще сфера. Туториал (устарел):
https://kidscancode.org/godot_recipes/3.x/3d/3d_sphere_car/
Самое надёжное - смотреть исходники движка. Но если ты хочешь прям реалистично, то тебе нужно самостоятельно делать всё на RigidBody3D...
Однако, я тебя не понимаю. Ты хочешь повторить игру, в которой машина не может развернуться на 180 градусов, т.е. это "вагонетка на рельсах", а не настоящая машина. Я бы на твоём месте взял ноды PathFollow3D и Path3D, чтобы привязать "машину" к дороге, а физику имитировал бы смещением меша.
https://docs.godotengine.org/en/stable/classes/class_pathfollow3d.html
В старых 2.5D гонках не было настоящей физики, машинка вообще никуда не катилась - создавали иллюзию за счёт смещения сегментов дороги.
>всратые параметры физона по умолчанию
Да, параметры странные, не менялись годами.
>RidgidBody3D чтобы хуяк-хуяк и сразу в игру
Я несколько раз пробовал сделать велосипед на RigidBody3D, это довольно сложно, я не осилил.
>пружины дают адовейший body roll
Поставь roll_influence = 1 или 2, немного поможет.
>У тебя на видео лимузин
Там габариты чуть короче и шире, чем у Жигулей.
>с физоном из роблокса, поэтому он устойчив
Даже в GTA 5 (!) увеличили силу тяжести машинам, прижимая их к асфальту так, будто они на рельсах.
>Столб с 4 колесами еще устойчивей будет
Нет. Чем выше центр тяжести, тем легче опрокинуть, поэтому специально занизил центр тяжести (смотри внимательнее на center of mass у VehicleBody3D).
>но можем ли мы его назвать машиной?
На видео вообще сфера. Туториал (устарел):
https://kidscancode.org/godot_recipes/3.x/3d/3d_sphere_car/
>найти материал по зависимости параметров
Самое надёжное - смотреть исходники движка. Но если ты хочешь прям реалистично, то тебе нужно самостоятельно делать всё на RigidBody3D...
Однако, я тебя не понимаю. Ты хочешь повторить игру, в которой машина не может развернуться на 180 градусов, т.е. это "вагонетка на рельсах", а не настоящая машина. Я бы на твоём месте взял ноды PathFollow3D и Path3D, чтобы привязать "машину" к дороге, а физику имитировал бы смещением меша.
https://docs.godotengine.org/en/stable/classes/class_pathfollow3d.html
В старых 2.5D гонках не было настоящей физики, машинка вообще никуда не катилась - создавали иллюзию за счёт смещения сегментов дороги.
>>57768
Годочую.
>>57769
Проблемы с таким подходом:
1. В файл сцены можно запаковать скрипт, при чём автоматически запускаемый. Т.е. есть возможность разработать GDScript-вирус, который будет скакать по сейв-файлам и делать свои грязные дела. Это обсуждалось на GitHub, официальное мнение:
С чем я полностью согласен. Юзаем json.
2. При обновлении движка меняется формат сцен, некоторые сцены вообще приходят в негодность. Соответственно, либо сидишь на одной версии, либо ломаешь пользователям сохранения игры.
3. Если ты хоть что-то в своих сценах меняешь, все сохранения этой сцены становятся неактуальными, проверить и исправить автоматически ты это вряд ли сможешь. Соответственно игроки вынуждены начинать игру с нуля, чтобы оценить новый контент.
4. Избыточные данные. Да, ты можешь сказать "да ладно, сцены небольшие", но есть нюансы:
- сцены небольшие, но их будет много (РПГ же?);
- некоторые ресурсы в сценах очень жирные, типа массивов тайлмапа/гридмапа, некоторые Shape3D, некоторые Mesh, и т.д. Буквально десятки мегабайт может занимать визуально простенькая сцена. О бинарном формате не знаю, что там по сжатию...
Короче, если делаешь что-то больше "игры-прикола" на один раз, лучше подойти к сохранениям серьёзно.
>нужен сейв "предметной модели"
Годочую.
>>57769
>всю сцену сохранять в один файл
Проблемы с таким подходом:
1. В файл сцены можно запаковать скрипт, при чём автоматически запускаемый. Т.е. есть возможность разработать GDScript-вирус, который будет скакать по сейв-файлам и делать свои грязные дела. Это обсуждалось на GitHub, официальное мнение:
>ну, делать песочницу для кода сложна, и вообще не наша забота, пользователь сам дурак, юзайте json
С чем я полностью согласен. Юзаем json.
2. При обновлении движка меняется формат сцен, некоторые сцены вообще приходят в негодность. Соответственно, либо сидишь на одной версии, либо ломаешь пользователям сохранения игры.
3. Если ты хоть что-то в своих сценах меняешь, все сохранения этой сцены становятся неактуальными, проверить и исправить автоматически ты это вряд ли сможешь. Соответственно игроки вынуждены начинать игру с нуля, чтобы оценить новый контент.
4. Избыточные данные. Да, ты можешь сказать "да ладно, сцены небольшие", но есть нюансы:
- сцены небольшие, но их будет много (РПГ же?);
- некоторые ресурсы в сценах очень жирные, типа массивов тайлмапа/гридмапа, некоторые Shape3D, некоторые Mesh, и т.д. Буквально десятки мегабайт может занимать визуально простенькая сцена. О бинарном формате не знаю, что там по сжатию...
Короче, если делаешь что-то больше "игры-прикола" на один раз, лучше подойти к сохранениям серьёзно.
>>57773
Попробую. Вообще придется опять все коллизии проверять, а так же форму коллизий колес. Общая коллизия на машине у меня пока ящик, но я все больше убеждаюсь что это работает тогда и только тогда когда мы хотим прибить машину к полу. В идеале нужна даже не сфера, а эллипсоид как промежуточная фигура. Когда коллизия ящик, то сначала все очень удобно, но если предусматривается крен, то он становится таким резким, что машина начинает вращаться вокруг своей оси. Возможно сделаю шейп из нескольких шейпов.
Проворот тел вокруг своей оси отлично описывается здесь. У меня 1 в 1 опыт на 4.2.2..
https://forum.godotengine.org/t/issue-with-vehicle-suspension-when-applying-angular-forces/41729/6
Хочу заменить езду на более технологичную, перейти с 2.5д на 3д. Чтобы слегка укачивало, был легкий крен и опрокидывание на крышу при вывороте руля на максимальной скорости.
>roll_influence = 1
>center_of_mass
Попробую. Вообще придется опять все коллизии проверять, а так же форму коллизий колес. Общая коллизия на машине у меня пока ящик, но я все больше убеждаюсь что это работает тогда и только тогда когда мы хотим прибить машину к полу. В идеале нужна даже не сфера, а эллипсоид как промежуточная фигура. Когда коллизия ящик, то сначала все очень удобно, но если предусматривается крен, то он становится таким резким, что машина начинает вращаться вокруг своей оси. Возможно сделаю шейп из нескольких шейпов.
Проворот тел вокруг своей оси отлично описывается здесь. У меня 1 в 1 опыт на 4.2.2..
https://forum.godotengine.org/t/issue-with-vehicle-suspension-when-applying-angular-forces/41729/6
>Ты хочешь повторить игру, в которой машина не может развернуться на 180 градусов, т.е. это "вагонетка на рельсах"
Хочу заменить езду на более технологичную, перейти с 2.5д на 3д. Чтобы слегка укачивало, был легкий крен и опрокидывание на крышу при вывороте руля на максимальной скорости.
А что если сделать локал кооп (couch coop) игру? Насколько это удачная ниша? Плюс слышал что стим позволяет локал кооп одной галкой переделать в онлайн кооп.
>>57782
1. Нужны друзья.
2. ...кому нравится играть в те же игры, что и тебе.
3. ...и они должны быть в одной комнате с тобой.
4. ...и у вас должно быть минимум два геймпада или желание сидеть вдвоём за одной клавиатурой.
5. ...при этом очень желателен большой монитор.
А теперь подумай сам о том, как ты сужаешь ЦА.
Не знаю, не слышал, сильно сомневаюсь.
Там есть API для p2p мультиплеера, но локальный кооператив принципиально отличается от онлайна.
>Насколько это удачная ниша?
1. Нужны друзья.
2. ...кому нравится играть в те же игры, что и тебе.
3. ...и они должны быть в одной комнате с тобой.
4. ...и у вас должно быть минимум два геймпада или желание сидеть вдвоём за одной клавиатурой.
5. ...при этом очень желателен большой монитор.
А теперь подумай сам о том, как ты сужаешь ЦА.
>одной галкой переделать в онлайн кооп.
Не знаю, не слышал, сильно сомневаюсь.
Там есть API для p2p мультиплеера, но локальный кооператив принципиально отличается от онлайна.
>>57787
Брух, так у всех нормальных людей пункты 1-5 по дефолту присутствуют.
Погуглил - Remote Play Together называется.
Брух, так у всех нормальных людей пункты 1-5 по дефолту присутствуют.
>сильно сомневаюсь
Погуглил - Remote Play Together называется.
>>57781
Возможно, у тебя колёса в пол западают. У меня нормально с "ящиками", никаких сфер не нужно.
Так ведь там проблема была в apply_force(). Тебе эта функция вообще не нужна для VehicleBody3D.
Чисто технически, всё это возможно сделать через анимации, не используя физическую симуляцию. Физическая стимуляция нужна для неровного ландшафта, бордюров, сложных столкновений.
>Когда коллизия ящик, то сначала все очень удобно, но если предусматривается крен, то он становится таким резким, что машина начинает вращаться вокруг своей оси.
Возможно, у тебя колёса в пол западают. У меня нормально с "ящиками", никаких сфер не нужно.
>Проворот тел вокруг своей оси
Так ведь там проблема была в apply_force(). Тебе эта функция вообще не нужна для VehicleBody3D.
>Чтобы слегка укачивало, был легкий крен и опрокидывание на крышу при вывороте руля на максимальной скорости.
Чисто технически, всё это возможно сделать через анимации, не используя физическую симуляцию. Физическая стимуляция нужна для неровного ландшафта, бордюров, сложных столкновений.
Свежее обсуждение статической типизации:
https://www.reddit.com/r/godot/comments/1dkzeun/statically_typed_gdscript_should_be_the_default/
Из комментариев:
Один из крутанов пишет:
https://www.reddit.com/r/godot/comments/1dkzeun/statically_typed_gdscript_should_be_the_default/
>After having built a 3D bullet hell in GDScript, spending almost as much time doing optimizations as I spent on programming the prototype, and now building a similar prototype in C# using the physics / rendering server...I can't think of any reason to NOT statically type your GDScript code.
>I did a side-by-side optimization comparison test that directly accesses the Physics/Rendering 3D server to create 3000 bullets in GDScript and C#. Statically typed GDScript was only about 10% FPS slower than the C# version.
Из комментариев:
>And the gains going from dynamically typed GDScript to full out statically typed GDscript was literally 40-50 fps to 200+ fps.
>And this difference is only exacerbated the larger your project becomes, as games ultimately do.
Один из крутанов пишет:
>KoBeWi
>Actually, type hints are enabled by default in 4.3 and AFAIK demos/documentation are being updated to use typed code.
>>57801
Все так. ГДСкрипт с тайпхинтами довольно шустр и гораздо удобней чем без, и его давно уже всюду пихают и правильно делают. Идеально. Не удивлюсь если юнька через пару лет гдскрипт украдет и он станет де-факто дефолтом для геймдева.
Все так. ГДСкрипт с тайпхинтами довольно шустр и гораздо удобней чем без, и его давно уже всюду пихают и правильно делают. Идеально. Не удивлюсь если юнька через пару лет гдскрипт украдет и он станет де-факто дефолтом для геймдева.
>>57803
Юридически они имеют право, пусть крадут. Но эффективные менеджеры не смогут сладить с тысячами программистов, которые нужны, чтобы выкрутить лампочку виртуальную машину GDScript из Godot и вкрутить её в Unity. Дорого, тут нужны триллионы долларов, а $U всё падает и падает.
Поэтому продолжаем делать игры на Godot.
>если юнька через пару лет гдскрипт украдет
Юридически они имеют право, пусть крадут. Но эффективные менеджеры не смогут сладить с тысячами программистов, которые нужны, чтобы выкрутить лампочку виртуальную машину GDScript из Godot и вкрутить её в Unity. Дорого, тут нужны триллионы долларов, а $U всё падает и падает.
Поэтому продолжаем делать игры на Godot.
276 Кб, 421x663>>57850
Еее! Вперёд, Годот!
Еее! Вперёд, Годот!
6,4 Мб, 755x509>>57853
А у него есть бур?
А у него есть бур?
>>57717
Реализовал себе фичу из GTA 5: контроль поворота в воздухе. Знал об этой фиче много лет и активно её использовал, но и подумать не мог, как сильно она влияет на ощущения от геймплея. Разница уровня "беспомощный кирпич" vs "крутой акробат". Только теперь по-настоящему понимаю решение Rockstar.
>>57781
Я вспомнил об одной очень важной для правильной физической симуляции настройке, о которой редко упоминают: angular_damp. Суть в том, что реальные объекты замедляются сопротивлением воздуха, зависящего от формы объекта, но в игровом движке слишком дорого симулировать потоки воздуха. Так придумали упрощённую формулу, приблизительно имитирующую сопротивление воздуха.
Короче, значение по умолчанию 0.1, оно нормально подходит только сферическим объектам. Машинке необходимо поднять это значение повыше, тогда спокойнее будет реагировать на работу подвески.
На видео angular_damp должен быть равен 1.0, но я сделал это для более точного контроля в воздухе.
Реализовал себе фичу из GTA 5: контроль поворота в воздухе. Знал об этой фиче много лет и активно её использовал, но и подумать не мог, как сильно она влияет на ощущения от геймплея. Разница уровня "беспомощный кирпич" vs "крутой акробат". Только теперь по-настоящему понимаю решение Rockstar.
>>57781
>становится таким резким, что машина начинает вращаться вокруг своей оси
Я вспомнил об одной очень важной для правильной физической симуляции настройке, о которой редко упоминают: angular_damp. Суть в том, что реальные объекты замедляются сопротивлением воздуха, зависящего от формы объекта, но в игровом движке слишком дорого симулировать потоки воздуха. Так придумали упрощённую формулу, приблизительно имитирующую сопротивление воздуха.
Короче, значение по умолчанию 0.1, оно нормально подходит только сферическим объектам. Машинке необходимо поднять это значение повыше, тогда спокойнее будет реагировать на работу подвески.
На видео angular_damp должен быть равен 1.0, но я сделал это для более точного контроля в воздухе.
>>57896
Фигню какую-то сделал. У тебя только одна кнопка в главном меню? А зачем тогда она нужна? Или это экран "нажмите что угодно чтобы войти в главное меню"? Но тогда главное меню уже должно быть в дереве сцены, чтобы не тормозило.
Фигню какую-то сделал. У тебя только одна кнопка в главном меню? А зачем тогда она нужна? Или это экран "нажмите что угодно чтобы войти в главное меню"? Но тогда главное меню уже должно быть в дереве сцены, чтобы не тормозило.
>>57912
Я тоже думаю стоит переделать архитектуру, на случай если захочется сделать кнопку мультиплеерной.
Я тоже думаю стоит переделать архитектуру, на случай если захочется сделать кнопку мультиплеерной.
>>57913
Не смешно. Поведение главного меню изменится с большей вероятностью, чем дизайн геймплея.
Алсо, любую игру можно переделать в мультиплеер, а мультиплеер чрезвычайно популярен у нормисов, так что полностью сбрасывать его со счетов нельзя.
Не смешно. Поведение главного меню изменится с большей вероятностью, чем дизайн геймплея.
Алсо, любую игру можно переделать в мультиплеер, а мультиплеер чрезвычайно популярен у нормисов, так что полностью сбрасывать его со счетов нельзя.
>>57914
Так и представляю как за месяц до релиза начинаю переделывать свою визуальную новеллу в ммо.
Так и представляю как за месяц до релиза начинаю переделывать свою визуальную новеллу в ммо.
>>57919
О, ты прям как ААА студия, дедлайн себе ставишь. Кранчишь поди 24/7, премию себе урезаешь за невыполнение сроков, потом переносишь релиз несколько раз, а на выходе всё равно киберпук77.
Книжки читать тоже можно большой компанией.
>за месяц до релиза
О, ты прям как ААА студия, дедлайн себе ставишь. Кранчишь поди 24/7, премию себе урезаешь за невыполнение сроков, потом переносишь релиз несколько раз, а на выходе всё равно киберпук77.
>визуальную новеллу в ммо
Книжки читать тоже можно большой компанией.
>>57945
Я не, но даже это лучше чем как ты - бесконечно вариться в продакшн хелле, переделывая один участок кода раз за разом, в итоге выпуская игру морально устаревшую лет на 10, а то и не выпуская ничего.
Я не, но даже это лучше чем как ты - бесконечно вариться в продакшн хелле, переделывая один участок кода раз за разом, в итоге выпуская игру морально устаревшую лет на 10, а то и не выпуская ничего.
>>57946
Судьба всех труъ инди...
Лучше вообще ничего не выпускать, чем пополнить огромную коллекцию никому не нужного софта.
>морально устаревшую лет на 10
Судьба всех труъ инди...
>а то и не выпуская ничего
Лучше вообще ничего не выпускать, чем пополнить огромную коллекцию никому не нужного софта.
>>57880
Молодец!
Вчера смог исправить все проблемы с физоном. Сделал коллизию авто из трех циллиндров. Этого за глаза для npc тачек. Главная машина временно будет такая же пока не решу какой ей нужен физон. Теперь пора соденинять несколько сцен чтобы была бесконечная прямая дорога, и процедурно добавлять в них встречные машины. Потом изучать работу физона столкновений со встречкой. Есть идеи на счет сюжета чтобы был смысл идти из точки А в точку Б. А то обычно в хоррорах просто бросают игрока в сцену и говорят: "давай дальше сам как-нибудь, только красную дверь не трогай, иначе умрешь".
Еще оказалось что игра Spooky Night уже существует, поэтому переименовался. Жаль имя Night Drive тоже было занято. Кстати графическая часть в Night Drive выглядит охуенно: езда от 1 лица с графоном и ебаками SCP. Вот только сами ебаки из SCP как бревна с глазами стоят и изредка двигаются. Сюжет на уровне найти на обочине ебаку чтобы сюжет продолжился.
Молодец!
Вчера смог исправить все проблемы с физоном. Сделал коллизию авто из трех циллиндров. Этого за глаза для npc тачек. Главная машина временно будет такая же пока не решу какой ей нужен физон. Теперь пора соденинять несколько сцен чтобы была бесконечная прямая дорога, и процедурно добавлять в них встречные машины. Потом изучать работу физона столкновений со встречкой. Есть идеи на счет сюжета чтобы был смысл идти из точки А в точку Б. А то обычно в хоррорах просто бросают игрока в сцену и говорят: "давай дальше сам как-нибудь, только красную дверь не трогай, иначе умрешь".
Еще оказалось что игра Spooky Night уже существует, поэтому переименовался. Жаль имя Night Drive тоже было занято. Кстати графическая часть в Night Drive выглядит охуенно: езда от 1 лица с графоном и ебаками SCP. Вот только сами ебаки из SCP как бревна с глазами стоят и изредка двигаются. Сюжет на уровне найти на обочине ебаку чтобы сюжет продолжился.
>>57959
Спасибо, ты тоже молодец.
Ээээ... Как бы сказать...
Во-первых, колёса VehicleWheel3D, по идее, должны располагаться примерно по середине меша шины колеса. В противном случае у тебя машинка будет физически заезжать колесом на бордюр, когда визуальное колесо ещё не находится на бордюре. От первого лица это не критично, наверное, но могут возникнуть проблемы со стенками (эти колёса не являются твёрдыми, там просто рейкаст) и NPC.
Во-вторых,
Это очень странное решение. На твоём же видео машинка нереалистично покатилась из-за того, что она физически круглая. А ещё вот:
https://docs.godotengine.org/en/stable/classes/class_cylindershape3d.html
Вкратце: самая багнутая и самая медленная форма из всех примитивов, лучше пока не использовать. В альтернативных физдвижках может быть иначе.
В-третьих, попробуй менять angular_damp... или это:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-inertia
Можно настроить вращение по каждой оси.
Но ты прав в том, что лучше поработать над другими элементами игры. Как минимум тебе нужна длинная извилистая дорога для полноценного теста езды, по текущему короткому участку сложно что-то сказать.
Можно сделать что-то в этом духе:
https://ru.wikipedia.org/wiki/Мгла_(фильм)
Спасаемся от растущей зоны НЁХ, из которой лезут различные монстры. На мой взгляд, страшнее будет сделать так, чтоб монстры нападали в т.ч. друг на друга, ибо так они правдоподобнее (у них там своя экосистема, люди для них просто необычная еда). Геймплей можно завязать на том, что если хорошо водишь машину - отрываешься от монстров, а если плохо - должен чаще уворачиваться от нападений. Дальше оторвался - больше времени на заправке. Безумные водятлы, мешающие сбежать, олени на дорогах, упавшие деревья и камни, огромные ямы, перекрытые на ремонт участки дороги добавляют препятствий, повышая риск затормозить.
Кстати, повторяемость участков дороги в данном варианте геймплея не страшна, поскольку весь фан в реакции на неожиданные ситуации на дороге. Так геймплей можно сделать условно-бесконечным, чтоб было интересно проходить без конца, стараясь проехать как можно дальше, прежде чем сожрут. В общем, классическая аркадная формула.
Не парься о названии пока.
Ещё о камере. Вроде ты хотел от первого лица, но почему-то размещаешь камеру снаружи машины. Вопрос, зачем? Вид камеры сильно влияет на ощущения от геймплея. Конечно, нужно сделать салон машины и прозрачные стёкла, но в лоуполи это не так уж сложно, и наверняка есть готовые бесплатные модельки с салоном.
Для камеры от третьего лица нужно как минимум:
1. SpringArm3D для вращения по X/Y и сближения, если между камерой и объектом препятствие.
2. Убрать вращение по Z, чтобы камеру не шатало вместе с машиной. Раньше думал, что это прикольно, однако быстро начинает раздражать.
С камерой от первого лица чуть проще. Но там свои проблемы, ведь угол обзора сильно ограничен.
Спасибо, ты тоже молодец.
>смог исправить все проблемы с физоном
Ээээ... Как бы сказать...
Во-первых, колёса VehicleWheel3D, по идее, должны располагаться примерно по середине меша шины колеса. В противном случае у тебя машинка будет физически заезжать колесом на бордюр, когда визуальное колесо ещё не находится на бордюре. От первого лица это не критично, наверное, но могут возникнуть проблемы со стенками (эти колёса не являются твёрдыми, там просто рейкаст) и NPC.
Во-вторых,
>Сделал коллизию авто из трех циллиндров
Это очень странное решение. На твоём же видео машинка нереалистично покатилась из-за того, что она физически круглая. А ещё вот:
https://docs.godotengine.org/en/stable/classes/class_cylindershape3d.html
>Note: There are several known bugs with cylinder collision shapes. Using CapsuleShape3D or BoxShape3D instead is recommended.
>Performance: CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D.
Вкратце: самая багнутая и самая медленная форма из всех примитивов, лучше пока не использовать. В альтернативных физдвижках может быть иначе.
В-третьих, попробуй менять angular_damp... или это:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-inertia
Можно настроить вращение по каждой оси.
Но ты прав в том, что лучше поработать над другими элементами игры. Как минимум тебе нужна длинная извилистая дорога для полноценного теста езды, по текущему короткому участку сложно что-то сказать.
>Есть идеи на счет сюжета чтобы был смысл идти из точки А в точку Б. А то обычно в хоррорах...
Можно сделать что-то в этом духе:
https://ru.wikipedia.org/wiki/Мгла_(фильм)
Спасаемся от растущей зоны НЁХ, из которой лезут различные монстры. На мой взгляд, страшнее будет сделать так, чтоб монстры нападали в т.ч. друг на друга, ибо так они правдоподобнее (у них там своя экосистема, люди для них просто необычная еда). Геймплей можно завязать на том, что если хорошо водишь машину - отрываешься от монстров, а если плохо - должен чаще уворачиваться от нападений. Дальше оторвался - больше времени на заправке. Безумные водятлы, мешающие сбежать, олени на дорогах, упавшие деревья и камни, огромные ямы, перекрытые на ремонт участки дороги добавляют препятствий, повышая риск затормозить.
Кстати, повторяемость участков дороги в данном варианте геймплея не страшна, поскольку весь фан в реакции на неожиданные ситуации на дороге. Так геймплей можно сделать условно-бесконечным, чтоб было интересно проходить без конца, стараясь проехать как можно дальше, прежде чем сожрут. В общем, классическая аркадная формула.
>переименовался
Не парься о названии пока.
Ещё о камере. Вроде ты хотел от первого лица, но почему-то размещаешь камеру снаружи машины. Вопрос, зачем? Вид камеры сильно влияет на ощущения от геймплея. Конечно, нужно сделать салон машины и прозрачные стёкла, но в лоуполи это не так уж сложно, и наверняка есть готовые бесплатные модельки с салоном.
Для камеры от третьего лица нужно как минимум:
1. SpringArm3D для вращения по X/Y и сближения, если между камерой и объектом препятствие.
2. Убрать вращение по Z, чтобы камеру не шатало вместе с машиной. Раньше думал, что это прикольно, однако быстро начинает раздражать.
С камерой от первого лица чуть проще. Но там свои проблемы, ведь угол обзора сильно ограничен.
>>57959
Спасибо, ты тоже молодец.
Ээээ... Как бы сказать...
Во-первых, колёса VehicleWheel3D, по идее, должны располагаться примерно по середине меша шины колеса. В противном случае у тебя машинка будет физически заезжать колесом на бордюр, когда визуальное колесо ещё не находится на бордюре. От первого лица это не критично, наверное, но могут возникнуть проблемы со стенками (эти колёса не являются твёрдыми, там просто рейкаст) и NPC.
Во-вторых,
Это очень странное решение. На твоём же видео машинка нереалистично покатилась из-за того, что она физически круглая. А ещё вот:
https://docs.godotengine.org/en/stable/classes/class_cylindershape3d.html
Вкратце: самая багнутая и самая медленная форма из всех примитивов, лучше пока не использовать. В альтернативных физдвижках может быть иначе.
В-третьих, попробуй менять angular_damp... или это:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-inertia
Можно настроить вращение по каждой оси.
Но ты прав в том, что лучше поработать над другими элементами игры. Как минимум тебе нужна длинная извилистая дорога для полноценного теста езды, по текущему короткому участку сложно что-то сказать.
Можно сделать что-то в этом духе:
https://ru.wikipedia.org/wiki/Мгла_(фильм)
Спасаемся от растущей зоны НЁХ, из которой лезут различные монстры. На мой взгляд, страшнее будет сделать так, чтоб монстры нападали в т.ч. друг на друга, ибо так они правдоподобнее (у них там своя экосистема, люди для них просто необычная еда). Геймплей можно завязать на том, что если хорошо водишь машину - отрываешься от монстров, а если плохо - должен чаще уворачиваться от нападений. Дальше оторвался - больше времени на заправке. Безумные водятлы, мешающие сбежать, олени на дорогах, упавшие деревья и камни, огромные ямы, перекрытые на ремонт участки дороги добавляют препятствий, повышая риск затормозить.
Кстати, повторяемость участков дороги в данном варианте геймплея не страшна, поскольку весь фан в реакции на неожиданные ситуации на дороге. Так геймплей можно сделать условно-бесконечным, чтоб было интересно проходить без конца, стараясь проехать как можно дальше, прежде чем сожрут. В общем, классическая аркадная формула.
Не парься о названии пока.
Ещё о камере. Вроде ты хотел от первого лица, но почему-то размещаешь камеру снаружи машины. Вопрос, зачем? Вид камеры сильно влияет на ощущения от геймплея. Конечно, нужно сделать салон машины и прозрачные стёкла, но в лоуполи это не так уж сложно, и наверняка есть готовые бесплатные модельки с салоном.
Для камеры от третьего лица нужно как минимум:
1. SpringArm3D для вращения по X/Y и сближения, если между камерой и объектом препятствие.
2. Убрать вращение по Z, чтобы камеру не шатало вместе с машиной. Раньше думал, что это прикольно, однако быстро начинает раздражать.
С камерой от первого лица чуть проще. Но там свои проблемы, ведь угол обзора сильно ограничен.
Спасибо, ты тоже молодец.
>смог исправить все проблемы с физоном
Ээээ... Как бы сказать...
Во-первых, колёса VehicleWheel3D, по идее, должны располагаться примерно по середине меша шины колеса. В противном случае у тебя машинка будет физически заезжать колесом на бордюр, когда визуальное колесо ещё не находится на бордюре. От первого лица это не критично, наверное, но могут возникнуть проблемы со стенками (эти колёса не являются твёрдыми, там просто рейкаст) и NPC.
Во-вторых,
>Сделал коллизию авто из трех циллиндров
Это очень странное решение. На твоём же видео машинка нереалистично покатилась из-за того, что она физически круглая. А ещё вот:
https://docs.godotengine.org/en/stable/classes/class_cylindershape3d.html
>Note: There are several known bugs with cylinder collision shapes. Using CapsuleShape3D or BoxShape3D instead is recommended.
>Performance: CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D.
Вкратце: самая багнутая и самая медленная форма из всех примитивов, лучше пока не использовать. В альтернативных физдвижках может быть иначе.
В-третьих, попробуй менять angular_damp... или это:
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-property-inertia
Можно настроить вращение по каждой оси.
Но ты прав в том, что лучше поработать над другими элементами игры. Как минимум тебе нужна длинная извилистая дорога для полноценного теста езды, по текущему короткому участку сложно что-то сказать.
>Есть идеи на счет сюжета чтобы был смысл идти из точки А в точку Б. А то обычно в хоррорах...
Можно сделать что-то в этом духе:
https://ru.wikipedia.org/wiki/Мгла_(фильм)
Спасаемся от растущей зоны НЁХ, из которой лезут различные монстры. На мой взгляд, страшнее будет сделать так, чтоб монстры нападали в т.ч. друг на друга, ибо так они правдоподобнее (у них там своя экосистема, люди для них просто необычная еда). Геймплей можно завязать на том, что если хорошо водишь машину - отрываешься от монстров, а если плохо - должен чаще уворачиваться от нападений. Дальше оторвался - больше времени на заправке. Безумные водятлы, мешающие сбежать, олени на дорогах, упавшие деревья и камни, огромные ямы, перекрытые на ремонт участки дороги добавляют препятствий, повышая риск затормозить.
Кстати, повторяемость участков дороги в данном варианте геймплея не страшна, поскольку весь фан в реакции на неожиданные ситуации на дороге. Так геймплей можно сделать условно-бесконечным, чтоб было интересно проходить без конца, стараясь проехать как можно дальше, прежде чем сожрут. В общем, классическая аркадная формула.
>переименовался
Не парься о названии пока.
Ещё о камере. Вроде ты хотел от первого лица, но почему-то размещаешь камеру снаружи машины. Вопрос, зачем? Вид камеры сильно влияет на ощущения от геймплея. Конечно, нужно сделать салон машины и прозрачные стёкла, но в лоуполи это не так уж сложно, и наверняка есть готовые бесплатные модельки с салоном.
Для камеры от третьего лица нужно как минимум:
1. SpringArm3D для вращения по X/Y и сближения, если между камерой и объектом препятствие.
2. Убрать вращение по Z, чтобы камеру не шатало вместе с машиной. Раньше думал, что это прикольно, однако быстро начинает раздражать.
С камерой от первого лица чуть проще. Но там свои проблемы, ведь угол обзора сильно ограничен.
>>57965
В плане физона для npc машин оставляю то что есть. Вся надежда на то что машина быстро появляется в кадре, и так же быстро пропадает, из-за чего игроку ее физон вообще не важен пока поведение в пределах нормы. Камеру к машине для 1 лица еще не прикручивал. Все еще делаю тесты в 3 лице. Салон (и вся остальная машина вокруг) не в наличии, а без него 1 лицо имеет мало смысла. С новой моделькой надо заново все части машины собирать, и заново гонять параметры через тесты. Скачал Blockbench и MagicaVoxel для графона.
Пока вижу резонным не усложнять ландшафт, и иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону. Главное чтобы игрок поверил.
Все шейпы хороши, но для машин мне проще использовать циллиндр. Теоретики могут писать что хотят, но лично у меня в сценах все работает прекрасно без багов. В шейпе две оси, одна из которых напоминает куб, а вторая капсулу. Стык имеет специфичный физон, но, сюрприз, он такой же неочевидный в реальной жизни. То что "CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D" меня не удивляет, и никак не мешает. Не понимаю почему дауны ожидают от опенсурсных упрощенных шейпов в godot каких-то чудес на уровне специализированного пропиретарного движка Havok.
Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно. Мне видится что намного легче сделать этот переворот когда достигнуты определенные значения скорости и угла руля. Как только оба значения равны искомому, делаем каунтер +=1 (1 фрейм условие выполнилось). При N фреймов переворачиваемся. В нейтральном положении руля сбрасываем каунтер. Мне будет в будущем проще код показать наверное, чем объяснить. Такой костыль мне дешевле по времени написать чем стать специалистом по RigidBody3D.
Сюжет простой: главгерой автостопом едет в ебеня чтобы купить себе машину. На месте выесняет что в машине умер дед. Ну и дальше чел уже один едет и офигивает, что он дорогу не знает, пытается достучаться до местных чтобы направили. И так едет из города в город. Ну а неписи как в Морровинде такие: как поедешь там за речкой сверни, а потом налево, че как маленький.
В плане физона для npc машин оставляю то что есть. Вся надежда на то что машина быстро появляется в кадре, и так же быстро пропадает, из-за чего игроку ее физон вообще не важен пока поведение в пределах нормы. Камеру к машине для 1 лица еще не прикручивал. Все еще делаю тесты в 3 лице. Салон (и вся остальная машина вокруг) не в наличии, а без него 1 лицо имеет мало смысла. С новой моделькой надо заново все части машины собирать, и заново гонять параметры через тесты. Скачал Blockbench и MagicaVoxel для графона.
Пока вижу резонным не усложнять ландшафт, и иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону. Главное чтобы игрок поверил.
Все шейпы хороши, но для машин мне проще использовать циллиндр. Теоретики могут писать что хотят, но лично у меня в сценах все работает прекрасно без багов. В шейпе две оси, одна из которых напоминает куб, а вторая капсулу. Стык имеет специфичный физон, но, сюрприз, он такой же неочевидный в реальной жизни. То что "CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D" меня не удивляет, и никак не мешает. Не понимаю почему дауны ожидают от опенсурсных упрощенных шейпов в godot каких-то чудес на уровне специализированного пропиретарного движка Havok.
Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно. Мне видится что намного легче сделать этот переворот когда достигнуты определенные значения скорости и угла руля. Как только оба значения равны искомому, делаем каунтер +=1 (1 фрейм условие выполнилось). При N фреймов переворачиваемся. В нейтральном положении руля сбрасываем каунтер. Мне будет в будущем проще код показать наверное, чем объяснить. Такой костыль мне дешевле по времени написать чем стать специалистом по RigidBody3D.
Сюжет простой: главгерой автостопом едет в ебеня чтобы купить себе машину. На месте выесняет что в машине умер дед. Ну и дальше чел уже один едет и офигивает, что он дорогу не знает, пытается достучаться до местных чтобы направили. И так едет из города в город. Ну а неписи как в Морровинде такие: как поедешь там за речкой сверни, а потом налево, че как маленький.
>>57965
В плане физона для npc машин оставляю то что есть. Вся надежда на то что машина быстро появляется в кадре, и так же быстро пропадает, из-за чего игроку ее физон вообще не важен пока поведение в пределах нормы. Камеру к машине для 1 лица еще не прикручивал. Все еще делаю тесты в 3 лице. Салон (и вся остальная машина вокруг) не в наличии, а без него 1 лицо имеет мало смысла. С новой моделькой надо заново все части машины собирать, и заново гонять параметры через тесты. Скачал Blockbench и MagicaVoxel для графона.
Пока вижу резонным не усложнять ландшафт, и иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону. Главное чтобы игрок поверил.
Все шейпы хороши, но для машин мне проще использовать циллиндр. Теоретики могут писать что хотят, но лично у меня в сценах все работает прекрасно без багов. В шейпе две оси, одна из которых напоминает куб, а вторая капсулу. Стык имеет специфичный физон, но, сюрприз, он такой же неочевидный в реальной жизни. То что "CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D" меня не удивляет, и никак не мешает. Не понимаю почему дауны ожидают от опенсурсных упрощенных шейпов в godot каких-то чудес на уровне специализированного пропиретарного движка Havok.
Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно. Мне видится что намного легче сделать этот переворот когда достигнуты определенные значения скорости и угла руля. Как только оба значения равны искомому, делаем каунтер +=1 (1 фрейм условие выполнилось). При N фреймов переворачиваемся. В нейтральном положении руля сбрасываем каунтер. Мне будет в будущем проще код показать наверное, чем объяснить. Такой костыль мне дешевле по времени написать чем стать специалистом по RigidBody3D.
Сюжет простой: главгерой автостопом едет в ебеня чтобы купить себе машину. На месте выесняет что в машине умер дед. Ну и дальше чел уже один едет и офигивает, что он дорогу не знает, пытается достучаться до местных чтобы направили. И так едет из города в город. Ну а неписи как в Морровинде такие: как поедешь там за речкой сверни, а потом налево, че как маленький.
В плане физона для npc машин оставляю то что есть. Вся надежда на то что машина быстро появляется в кадре, и так же быстро пропадает, из-за чего игроку ее физон вообще не важен пока поведение в пределах нормы. Камеру к машине для 1 лица еще не прикручивал. Все еще делаю тесты в 3 лице. Салон (и вся остальная машина вокруг) не в наличии, а без него 1 лицо имеет мало смысла. С новой моделькой надо заново все части машины собирать, и заново гонять параметры через тесты. Скачал Blockbench и MagicaVoxel для графона.
Пока вижу резонным не усложнять ландшафт, и иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону. Главное чтобы игрок поверил.
Все шейпы хороши, но для машин мне проще использовать циллиндр. Теоретики могут писать что хотят, но лично у меня в сценах все работает прекрасно без багов. В шейпе две оси, одна из которых напоминает куб, а вторая капсулу. Стык имеет специфичный физон, но, сюрприз, он такой же неочевидный в реальной жизни. То что "CylinderShape3D is fast to check collisions against, but it is slower than CapsuleShape3D, BoxShape3D, and SphereShape3D" меня не удивляет, и никак не мешает. Не понимаю почему дауны ожидают от опенсурсных упрощенных шейпов в godot каких-то чудес на уровне специализированного пропиретарного движка Havok.
Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно. Мне видится что намного легче сделать этот переворот когда достигнуты определенные значения скорости и угла руля. Как только оба значения равны искомому, делаем каунтер +=1 (1 фрейм условие выполнилось). При N фреймов переворачиваемся. В нейтральном положении руля сбрасываем каунтер. Мне будет в будущем проще код показать наверное, чем объяснить. Такой костыль мне дешевле по времени написать чем стать специалистом по RigidBody3D.
Сюжет простой: главгерой автостопом едет в ебеня чтобы купить себе машину. На месте выесняет что в машине умер дед. Ну и дальше чел уже один едет и офигивает, что он дорогу не знает, пытается достучаться до местных чтобы направили. И так едет из города в город. Ну а неписи как в Морровинде такие: как поедешь там за речкой сверни, а потом налево, че как маленький.
>>57946
Так наоборот если говнокодить без какой-либо попытки заложить архитектуру на будущее, то увеличиваешь шансы увязнуть в лапше когда в очередной раз попытаешься добавить фичу и поймёшь что конструкция уже трещит по швам. Чистый код, паттерны и прочую залупу придумали на вот таких ошибках как у тебя, впрочем я думаю что пока говнокод тебя не ужалит в жопу, смысла втирать про бест практисес нет. Каждый должен наговнокодить свою долю прежде чем осознать зачем нужны паттерны.
>бесконечно вариться в продакшн хелле, переделывая один участок кода раз за разом
Так наоборот если говнокодить без какой-либо попытки заложить архитектуру на будущее, то увеличиваешь шансы увязнуть в лапше когда в очередной раз попытаешься добавить фичу и поймёшь что конструкция уже трещит по швам. Чистый код, паттерны и прочую залупу придумали на вот таких ошибках как у тебя, впрочем я думаю что пока говнокод тебя не ужалит в жопу, смысла втирать про бест практисес нет. Каждый должен наговнокодить свою долю прежде чем осознать зачем нужны паттерны.
>>54699 (OP)
https://github.com/godotengine/godot-proposals/issues/56
https://github.com/godotengine/godot/pull/78656
https://github.com/godotengine/godot-proposals/issues/56
>AThousandShips commented May 16, 2024
>At this time there isn't really anything that needs doing from any contributor, we're in feature freeze for 4.3 so it won't be merged right now, but hopefully it can be reviewed early in the 4.4 release cycle, it's a large feature so it's been hard for reviewers to find the time to focus on it properly.
https://github.com/godotengine/godot/pull/78656
>All core issues are resolved!
>var typed_key_value: Dictionary[int, String] = { 1: "first value", 2: "second value", 3: "etc" }
>var typed_key: Dictionary[int, Variant] = { 0: "any value", 10: 3.14, 100: null }
>var typed_value: Dictionary[Variant, int] = { "any value": 0, 123: 456, null: -1 }
>>57977
Если игрок столкнётся с ними, они должны иметь достаточно точные коллизии. У тебя, как понимаю, коллизии выходят за пределы визуальной модели, поэтому игрок может случайно зацепить встречный автомобиль за невидимый выступ. Это раздражает игрока, когда он цепляет что-то невидимое, что по логике цеплять не должен, особенно когда игра наказывает за это (даже если неявно).
Если игрок не сталкивается, а машин NPC много, то физику им можно вообще отключать и вести их по заранее известным кривым (Безье - Path3D) дороги, как это делали в разных 3D GTA (это легко наблюдать прямо в игре: машины NPC иногда глючат, проходя сквозь асфальт или двигаясь боком, никакая подвеска у них не работает). Но пока что об этой оптимизации не думай - запаса производительности движка хватит на приблизительно сотню простых VehicleBody3D. Просто предупреждаю о подводных камнях и типичных решениях, потому что кроме физики тебе нужно ещё и графику рендерить, ресурсы подгружать и т.д., рано или поздно столкнёшься с необходимостью резать фичи оптимизацией.
Ещё узкое место движка на данный момент - спавн новых CollisionShape3D. Он происходит в основном потоке и выделить в отдельный поток нельзя (небезопасно). Из-за этого узкого места нужно регулировать (ставить в очередь), сколько шейпов ты спавнишь за один кадр (иначе блокируется главный поток -> игра заикается). Когда-нибудь эту проблему решат, но она на гитхабе несколько лет висит... Опять же, пока что не парься об этом, просто это одно из главных узких мест в процедурной генерации сцены на Godot.
По моему опыту, легче использовать возможности физического движка, чем изобретать такие хитрые иллюзии. Ты же всё равно используешь VehicleBody3D, у которого всё что нужно симулируется, так зачем иллюзии?
Ясно-понятно, делай как хочешь...
Ээээм, вообще-то, у всех новичков проблема ИЗБЕЖАТЬ переворота на крышу при малейшем повороте руля на высокой скорости движения (больше 100 км/ч). VehicleBody3D достаточно стабилен на низкой скорости, но на высокой стремится перевернуться - кто-то говорит, что это реалистично (смотрел много видео про разбор условно-реалистичной физики машин в GTA IV), но в играх игроки привыкли к другому, и приходится делать "quality of life" фичи, чтоб машина не переворачивалась. В реальности, вроде бы, существуют специальные механизмы против переворота на скорости, но в стандартном VehicleBody3D этих механизмов нет (как и в старых машинах).
Вообще, тема физики машин в играх очень интересная, например, создатели одного автомобильного симулятора столкнулись с какой-то проблемой и пофиксили её, думая, что это баг их симуляции - но оказалось, что это не баг, а так и должно быть в реальности, и автомобильные производители используют какое-то решение, похожее на их "багфикс" симуляции. Во как бывает.
Если планируешь и дальше делать 3D игры, хорошее понимание RigidBody3D пригодится. Даже если забросишь Godot, 3D физика твёрдых тел (rigid body) везде плюс-минус похоже работает (отличия в стабильности, точности, скорости, багах и т.п.). Хотя, конечно, далеко не всем 3D играм нужна физика.
Прикольно. Планируешь развилки с тупиками, чтоб игрок мог реально заблудиться?
>В плане физона для npc машин оставляю то что есть.
Если игрок столкнётся с ними, они должны иметь достаточно точные коллизии. У тебя, как понимаю, коллизии выходят за пределы визуальной модели, поэтому игрок может случайно зацепить встречный автомобиль за невидимый выступ. Это раздражает игрока, когда он цепляет что-то невидимое, что по логике цеплять не должен, особенно когда игра наказывает за это (даже если неявно).
Если игрок не сталкивается, а машин NPC много, то физику им можно вообще отключать и вести их по заранее известным кривым (Безье - Path3D) дороги, как это делали в разных 3D GTA (это легко наблюдать прямо в игре: машины NPC иногда глючат, проходя сквозь асфальт или двигаясь боком, никакая подвеска у них не работает). Но пока что об этой оптимизации не думай - запаса производительности движка хватит на приблизительно сотню простых VehicleBody3D. Просто предупреждаю о подводных камнях и типичных решениях, потому что кроме физики тебе нужно ещё и графику рендерить, ресурсы подгружать и т.д., рано или поздно столкнёшься с необходимостью резать фичи оптимизацией.
Ещё узкое место движка на данный момент - спавн новых CollisionShape3D. Он происходит в основном потоке и выделить в отдельный поток нельзя (небезопасно). Из-за этого узкого места нужно регулировать (ставить в очередь), сколько шейпов ты спавнишь за один кадр (иначе блокируется главный поток -> игра заикается). Когда-нибудь эту проблему решат, но она на гитхабе несколько лет висит... Опять же, пока что не парься об этом, просто это одно из главных узких мест в процедурной генерации сцены на Godot.
>иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону.
По моему опыту, легче использовать возможности физического движка, чем изобретать такие хитрые иллюзии. Ты же всё равно используешь VehicleBody3D, у которого всё что нужно симулируется, так зачем иллюзии?
>мне проще использовать циллиндр
Ясно-понятно, делай как хочешь...
>Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно.
Ээээм, вообще-то, у всех новичков проблема ИЗБЕЖАТЬ переворота на крышу при малейшем повороте руля на высокой скорости движения (больше 100 км/ч). VehicleBody3D достаточно стабилен на низкой скорости, но на высокой стремится перевернуться - кто-то говорит, что это реалистично (смотрел много видео про разбор условно-реалистичной физики машин в GTA IV), но в играх игроки привыкли к другому, и приходится делать "quality of life" фичи, чтоб машина не переворачивалась. В реальности, вроде бы, существуют специальные механизмы против переворота на скорости, но в стандартном VehicleBody3D этих механизмов нет (как и в старых машинах).
Вообще, тема физики машин в играх очень интересная, например, создатели одного автомобильного симулятора столкнулись с какой-то проблемой и пофиксили её, думая, что это баг их симуляции - но оказалось, что это не баг, а так и должно быть в реальности, и автомобильные производители используют какое-то решение, похожее на их "багфикс" симуляции. Во как бывает.
>стать специалистом по RigidBody3D
Если планируешь и дальше делать 3D игры, хорошее понимание RigidBody3D пригодится. Даже если забросишь Godot, 3D физика твёрдых тел (rigid body) везде плюс-минус похоже работает (отличия в стабильности, точности, скорости, багах и т.п.). Хотя, конечно, далеко не всем 3D играм нужна физика.
>пытается достучаться до местных чтобы направили
Прикольно. Планируешь развилки с тупиками, чтоб игрок мог реально заблудиться?
>>57977
Если игрок столкнётся с ними, они должны иметь достаточно точные коллизии. У тебя, как понимаю, коллизии выходят за пределы визуальной модели, поэтому игрок может случайно зацепить встречный автомобиль за невидимый выступ. Это раздражает игрока, когда он цепляет что-то невидимое, что по логике цеплять не должен, особенно когда игра наказывает за это (даже если неявно).
Если игрок не сталкивается, а машин NPC много, то физику им можно вообще отключать и вести их по заранее известным кривым (Безье - Path3D) дороги, как это делали в разных 3D GTA (это легко наблюдать прямо в игре: машины NPC иногда глючат, проходя сквозь асфальт или двигаясь боком, никакая подвеска у них не работает). Но пока что об этой оптимизации не думай - запаса производительности движка хватит на приблизительно сотню простых VehicleBody3D. Просто предупреждаю о подводных камнях и типичных решениях, потому что кроме физики тебе нужно ещё и графику рендерить, ресурсы подгружать и т.д., рано или поздно столкнёшься с необходимостью резать фичи оптимизацией.
Ещё узкое место движка на данный момент - спавн новых CollisionShape3D. Он происходит в основном потоке и выделить в отдельный поток нельзя (небезопасно). Из-за этого узкого места нужно регулировать (ставить в очередь), сколько шейпов ты спавнишь за один кадр (иначе блокируется главный поток -> игра заикается). Когда-нибудь эту проблему решат, но она на гитхабе несколько лет висит... Опять же, пока что не парься об этом, просто это одно из главных узких мест в процедурной генерации сцены на Godot.
По моему опыту, легче использовать возможности физического движка, чем изобретать такие хитрые иллюзии. Ты же всё равно используешь VehicleBody3D, у которого всё что нужно симулируется, так зачем иллюзии?
Ясно-понятно, делай как хочешь...
Ээээм, вообще-то, у всех новичков проблема ИЗБЕЖАТЬ переворота на крышу при малейшем повороте руля на высокой скорости движения (больше 100 км/ч). VehicleBody3D достаточно стабилен на низкой скорости, но на высокой стремится перевернуться - кто-то говорит, что это реалистично (смотрел много видео про разбор условно-реалистичной физики машин в GTA IV), но в играх игроки привыкли к другому, и приходится делать "quality of life" фичи, чтоб машина не переворачивалась. В реальности, вроде бы, существуют специальные механизмы против переворота на скорости, но в стандартном VehicleBody3D этих механизмов нет (как и в старых машинах).
Вообще, тема физики машин в играх очень интересная, например, создатели одного автомобильного симулятора столкнулись с какой-то проблемой и пофиксили её, думая, что это баг их симуляции - но оказалось, что это не баг, а так и должно быть в реальности, и автомобильные производители используют какое-то решение, похожее на их "багфикс" симуляции. Во как бывает.
Если планируешь и дальше делать 3D игры, хорошее понимание RigidBody3D пригодится. Даже если забросишь Godot, 3D физика твёрдых тел (rigid body) везде плюс-минус похоже работает (отличия в стабильности, точности, скорости, багах и т.п.). Хотя, конечно, далеко не всем 3D играм нужна физика.
Прикольно. Планируешь развилки с тупиками, чтоб игрок мог реально заблудиться?
>В плане физона для npc машин оставляю то что есть.
Если игрок столкнётся с ними, они должны иметь достаточно точные коллизии. У тебя, как понимаю, коллизии выходят за пределы визуальной модели, поэтому игрок может случайно зацепить встречный автомобиль за невидимый выступ. Это раздражает игрока, когда он цепляет что-то невидимое, что по логике цеплять не должен, особенно когда игра наказывает за это (даже если неявно).
Если игрок не сталкивается, а машин NPC много, то физику им можно вообще отключать и вести их по заранее известным кривым (Безье - Path3D) дороги, как это делали в разных 3D GTA (это легко наблюдать прямо в игре: машины NPC иногда глючат, проходя сквозь асфальт или двигаясь боком, никакая подвеска у них не работает). Но пока что об этой оптимизации не думай - запаса производительности движка хватит на приблизительно сотню простых VehicleBody3D. Просто предупреждаю о подводных камнях и типичных решениях, потому что кроме физики тебе нужно ещё и графику рендерить, ресурсы подгружать и т.д., рано или поздно столкнёшься с необходимостью резать фичи оптимизацией.
Ещё узкое место движка на данный момент - спавн новых CollisionShape3D. Он происходит в основном потоке и выделить в отдельный поток нельзя (небезопасно). Из-за этого узкого места нужно регулировать (ставить в очередь), сколько шейпов ты спавнишь за один кадр (иначе блокируется главный поток -> игра заикается). Когда-нибудь эту проблему решат, но она на гитхабе несколько лет висит... Опять же, пока что не парься об этом, просто это одно из главных узких мест в процедурной генерации сцены на Godot.
>иметь плоскую текстуру, делающую вид будто на ней есть объемные бордюры и ямы. Яма может быть пятном на карте, у которой прописана смена гравитации чтобы подвеску вжимало, а бордюр так же, но в другую сторону.
По моему опыту, легче использовать возможности физического движка, чем изобретать такие хитрые иллюзии. Ты же всё равно используешь VehicleBody3D, у которого всё что нужно симулируется, так зачем иллюзии?
>мне проще использовать циллиндр
Ясно-понятно, делай как хочешь...
>Если нужен переворот на крышу на максимальной скорости при вывороте руля, то подгонять десятки параметров тела под этот случай можно бесконечно.
Ээээм, вообще-то, у всех новичков проблема ИЗБЕЖАТЬ переворота на крышу при малейшем повороте руля на высокой скорости движения (больше 100 км/ч). VehicleBody3D достаточно стабилен на низкой скорости, но на высокой стремится перевернуться - кто-то говорит, что это реалистично (смотрел много видео про разбор условно-реалистичной физики машин в GTA IV), но в играх игроки привыкли к другому, и приходится делать "quality of life" фичи, чтоб машина не переворачивалась. В реальности, вроде бы, существуют специальные механизмы против переворота на скорости, но в стандартном VehicleBody3D этих механизмов нет (как и в старых машинах).
Вообще, тема физики машин в играх очень интересная, например, создатели одного автомобильного симулятора столкнулись с какой-то проблемой и пофиксили её, думая, что это баг их симуляции - но оказалось, что это не баг, а так и должно быть в реальности, и автомобильные производители используют какое-то решение, похожее на их "багфикс" симуляции. Во как бывает.
>стать специалистом по RigidBody3D
Если планируешь и дальше делать 3D игры, хорошее понимание RigidBody3D пригодится. Даже если забросишь Godot, 3D физика твёрдых тел (rigid body) везде плюс-минус похоже работает (отличия в стабильности, точности, скорости, багах и т.п.). Хотя, конечно, далеко не всем 3D играм нужна физика.
>пытается достучаться до местных чтобы направили
Прикольно. Планируешь развилки с тупиками, чтоб игрок мог реально заблудиться?
>>57959
У тебя что, цилиндры поперек по дну? Там же клиренса нет, у тебя что, дорога идеальная без камушков и ям?
У тебя что, цилиндры поперек по дну? Там же клиренса нет, у тебя что, дорога идеальная без камушков и ям?
8 Кб, 444x58>>58007
В свою документацию можно эмодзи добавлять.
На Windows 10: WinKey + ./ю или WinKey + ;/ж
Теперь точно могу модный 💩код писать. 👌👴
>reviewed early in the 4.4 release cycle
В свою документацию можно эмодзи добавлять.
На Windows 10: WinKey + ./ю или WinKey + ;/ж
Теперь точно могу модный 💩код писать. 👌👴
733 Кб, 460x258>>58051
Без паники! У него всё в полном порядке:
У пингвинов вот тоже клиренса нет, а они быстро ездят.
>цилиндры поперек по дну? Там же клиренса нет
Без паники! У него всё в полном порядке:
>В идеале нужна даже не сфера, а эллипсоид
>Когда коллизия ящик, то сначала все очень удобно
>машина начинает вращаться вокруг своей оси
>Вчера смог исправить все проблемы с физоном
>Сделал коллизию авто из трех циллиндров
>для машин мне проще использовать циллиндр
>лично у меня в сценах все работает прекрасно без багов
У пингвинов вот тоже клиренса нет, а они быстро ездят.
>>58073
Сам Тодд Говард одобряет пришивание поезда вместо головы. Там чем я хуже? У меня машины неписей скрещены с пингвинами. Так сказать, коллизия червь-пидор, колизия пингвин. Машина просто катается на брюхе и слегка покачивается при поворотах на разницу в высоте между продольным и поперечными циллиндрами (анало-говнетная подвес-очка). Из пингвина можно так же сделать поезд или морское судно.
Отдельно буду делать модель машину без костылей для главного героя. Прям по докам попробую, если еще один гениальный костыль не придумаю. Шейп придется составлять из нескольких, и пока нет определенности в конечном виде. То ли кусок мыла из капсул получится, то ли стопка дров из циллиндров. Долго буду делать.
Сам Тодд Говард одобряет пришивание поезда вместо головы. Там чем я хуже? У меня машины неписей скрещены с пингвинами. Так сказать, коллизия червь-пидор, колизия пингвин. Машина просто катается на брюхе и слегка покачивается при поворотах на разницу в высоте между продольным и поперечными циллиндрами (анало-говнетная подвес-очка). Из пингвина можно так же сделать поезд или морское судно.
Отдельно буду делать модель машину без костылей для главного героя. Прям по докам попробую, если еще один гениальный костыль не придумаю. Шейп придется составлять из нескольких, и пока нет определенности в конечном виде. То ли кусок мыла из капсул получится, то ли стопка дров из циллиндров. Долго буду делать.
>>58150
Моя ставка: партикли с квад мешами-биллбордами, с кривой скалирования и цвета. Аналогично для дыма.
Моя ставка: партикли с квад мешами-биллбордами, с кривой скалирования и цвета. Аналогично для дыма.
>>58150
Годетта: Artbreeder + спрайт Годетты + скриншот огня + короткое описание + подправил косяки вручную.
Godot 3D: кучка CSG шейпов; глаза: дырки с чёрной точкой на дне, такое часто юзают в аниме моделях.
Огонь:
1. Quad меш. Поставил галочки на "unshaded", "цвет вершин как альбедо" и "билборд для партиклов + keep scale" в StandardMaterial3D, конвертировал его в шейдер. В шейдере удалил всё лишнее (дало больше FPS), оставив только преобразования матриц для билборда и альбедо из вершин и из текстуры, добавил простейшую формулу для создания полупрозрачного круга (length(UV - vec2(0.5, 0.5));), чтобы выглядело гладко по краям, без острых углов. В альбедо поставил NoiseTexture2D с каким-то из шумов, чтобы разнообразить спрайты, плюс добавил необычный градиент для имитации чего-то вроде "волн" в огне (прозрачно > темно > прозрачно > светло и т.д.), он ложится на шум и создаёт узор. Перебрал много вариантов, тут по вкусу выбирать нужно - можно сделать гладкий поток, можно сделать завихрения, лабиринты какие-то, узоры, контуры. Это основа, в ней вся красота. Самое интересное начало получаться только когда в градиент текстуры шума добавил прозрачные точки, чтобы шум сделал из круга неровную кляксу. Градиент лучше оставить чёрно-белым, но можно добавить какой-либо оттенок, общий для всех частиц. Я хотел сделать ещё реалистичнее оттенки, но устал возиться.
2. GPU партиклы. Тут пришлось сильно повозиться, но только потому что параметры разбросаны как-то не интуитивно и я наугад их подбирал. Основное: начальный вектор скорости с разбросом (нужно, чтобы частицы летели и быстро, и медленно) и рандомный поворот при спавне (чтобы не выглядело как равномерная сетка, ведь спрайт всего один на всё), гравитация строго вверх (горячий газ взлетает), масштаб (расширяется: 0.5 > 10), градиент цвета (белый > жёлтый > оранжевый полупрозрачный > почти чёрный прозрачный, чтобы плавно исчезало), градиент эмиссии (в самом начале ярче светится, чем под конец). Дальше Sub Emitter - он почему-то должен иметь минимум в 2 раза больше частиц, чтобы спамить без перерывов. Это копия первой ноды, с тем же мешем и текстурой, но со своими настройками: нулевая скорость спавна, только взлёт вверх, увеличение масштаба ещё больше (10 > 30), градиент цвета от полупрозрачно оранжевого к чёрному прозрачному. Субчастицы эти спавнятся по истечению жизни предыдущих частиц, поэтому-то они должны лететь с разной скоростью (иначе весь дым будет в одной точке, а не облаком). Пробовал разобраться с коллизиями частиц, но что-то не получилось. Пробовал рандомные вариации оттенков (hue), но выключил - градиент точнее/удобнее регулирует переходы цвета. Ещё поставил Draw Order = View Depth, но это больше актуально если спрайты непрозрачные.
Есть один странный косяк у этой системы: при определённых положениях камеры порядок отображения между главными частицами и второстепенными резко переключается, из-за чего яркий жёлтый центр проступает через чёрный дым, который всё ещё на экране и должен его собой перекрывать. Draw Order с этим не помогает, что с этим делать - непонятно. Depth Draw тоже пробовал переключать, это не то. Впрочем, мне пока и так сойдёт.
Годетта: Artbreeder + спрайт Годетты + скриншот огня + короткое описание + подправил косяки вручную.
Godot 3D: кучка CSG шейпов; глаза: дырки с чёрной точкой на дне, такое часто юзают в аниме моделях.
Огонь:
1. Quad меш. Поставил галочки на "unshaded", "цвет вершин как альбедо" и "билборд для партиклов + keep scale" в StandardMaterial3D, конвертировал его в шейдер. В шейдере удалил всё лишнее (дало больше FPS), оставив только преобразования матриц для билборда и альбедо из вершин и из текстуры, добавил простейшую формулу для создания полупрозрачного круга (length(UV - vec2(0.5, 0.5));), чтобы выглядело гладко по краям, без острых углов. В альбедо поставил NoiseTexture2D с каким-то из шумов, чтобы разнообразить спрайты, плюс добавил необычный градиент для имитации чего-то вроде "волн" в огне (прозрачно > темно > прозрачно > светло и т.д.), он ложится на шум и создаёт узор. Перебрал много вариантов, тут по вкусу выбирать нужно - можно сделать гладкий поток, можно сделать завихрения, лабиринты какие-то, узоры, контуры. Это основа, в ней вся красота. Самое интересное начало получаться только когда в градиент текстуры шума добавил прозрачные точки, чтобы шум сделал из круга неровную кляксу. Градиент лучше оставить чёрно-белым, но можно добавить какой-либо оттенок, общий для всех частиц. Я хотел сделать ещё реалистичнее оттенки, но устал возиться.
2. GPU партиклы. Тут пришлось сильно повозиться, но только потому что параметры разбросаны как-то не интуитивно и я наугад их подбирал. Основное: начальный вектор скорости с разбросом (нужно, чтобы частицы летели и быстро, и медленно) и рандомный поворот при спавне (чтобы не выглядело как равномерная сетка, ведь спрайт всего один на всё), гравитация строго вверх (горячий газ взлетает), масштаб (расширяется: 0.5 > 10), градиент цвета (белый > жёлтый > оранжевый полупрозрачный > почти чёрный прозрачный, чтобы плавно исчезало), градиент эмиссии (в самом начале ярче светится, чем под конец). Дальше Sub Emitter - он почему-то должен иметь минимум в 2 раза больше частиц, чтобы спамить без перерывов. Это копия первой ноды, с тем же мешем и текстурой, но со своими настройками: нулевая скорость спавна, только взлёт вверх, увеличение масштаба ещё больше (10 > 30), градиент цвета от полупрозрачно оранжевого к чёрному прозрачному. Субчастицы эти спавнятся по истечению жизни предыдущих частиц, поэтому-то они должны лететь с разной скоростью (иначе весь дым будет в одной точке, а не облаком). Пробовал разобраться с коллизиями частиц, но что-то не получилось. Пробовал рандомные вариации оттенков (hue), но выключил - градиент точнее/удобнее регулирует переходы цвета. Ещё поставил Draw Order = View Depth, но это больше актуально если спрайты непрозрачные.
Есть один странный косяк у этой системы: при определённых положениях камеры порядок отображения между главными частицами и второстепенными резко переключается, из-за чего яркий жёлтый центр проступает через чёрный дым, который всё ещё на экране и должен его собой перекрывать. Draw Order с этим не помогает, что с этим делать - непонятно. Depth Draw тоже пробовал переключать, это не то. Впрочем, мне пока и так сойдёт.
>>58150
Годетта: Artbreeder + спрайт Годетты + скриншот огня + короткое описание + подправил косяки вручную.
Godot 3D: кучка CSG шейпов; глаза: дырки с чёрной точкой на дне, такое часто юзают в аниме моделях.
Огонь:
1. Quad меш. Поставил галочки на "unshaded", "цвет вершин как альбедо" и "билборд для партиклов + keep scale" в StandardMaterial3D, конвертировал его в шейдер. В шейдере удалил всё лишнее (дало больше FPS), оставив только преобразования матриц для билборда и альбедо из вершин и из текстуры, добавил простейшую формулу для создания полупрозрачного круга (length(UV - vec2(0.5, 0.5));), чтобы выглядело гладко по краям, без острых углов. В альбедо поставил NoiseTexture2D с каким-то из шумов, чтобы разнообразить спрайты, плюс добавил необычный градиент для имитации чего-то вроде "волн" в огне (прозрачно > темно > прозрачно > светло и т.д.), он ложится на шум и создаёт узор. Перебрал много вариантов, тут по вкусу выбирать нужно - можно сделать гладкий поток, можно сделать завихрения, лабиринты какие-то, узоры, контуры. Это основа, в ней вся красота. Самое интересное начало получаться только когда в градиент текстуры шума добавил прозрачные точки, чтобы шум сделал из круга неровную кляксу. Градиент лучше оставить чёрно-белым, но можно добавить какой-либо оттенок, общий для всех частиц. Я хотел сделать ещё реалистичнее оттенки, но устал возиться.
2. GPU партиклы. Тут пришлось сильно повозиться, но только потому что параметры разбросаны как-то не интуитивно и я наугад их подбирал. Основное: начальный вектор скорости с разбросом (нужно, чтобы частицы летели и быстро, и медленно) и рандомный поворот при спавне (чтобы не выглядело как равномерная сетка, ведь спрайт всего один на всё), гравитация строго вверх (горячий газ взлетает), масштаб (расширяется: 0.5 > 10), градиент цвета (белый > жёлтый > оранжевый полупрозрачный > почти чёрный прозрачный, чтобы плавно исчезало), градиент эмиссии (в самом начале ярче светится, чем под конец). Дальше Sub Emitter - он почему-то должен иметь минимум в 2 раза больше частиц, чтобы спамить без перерывов. Это копия первой ноды, с тем же мешем и текстурой, но со своими настройками: нулевая скорость спавна, только взлёт вверх, увеличение масштаба ещё больше (10 > 30), градиент цвета от полупрозрачно оранжевого к чёрному прозрачному. Субчастицы эти спавнятся по истечению жизни предыдущих частиц, поэтому-то они должны лететь с разной скоростью (иначе весь дым будет в одной точке, а не облаком). Пробовал разобраться с коллизиями частиц, но что-то не получилось. Пробовал рандомные вариации оттенков (hue), но выключил - градиент точнее/удобнее регулирует переходы цвета. Ещё поставил Draw Order = View Depth, но это больше актуально если спрайты непрозрачные.
Есть один странный косяк у этой системы: при определённых положениях камеры порядок отображения между главными частицами и второстепенными резко переключается, из-за чего яркий жёлтый центр проступает через чёрный дым, который всё ещё на экране и должен его собой перекрывать. Draw Order с этим не помогает, что с этим делать - непонятно. Depth Draw тоже пробовал переключать, это не то. Впрочем, мне пока и так сойдёт.
Годетта: Artbreeder + спрайт Годетты + скриншот огня + короткое описание + подправил косяки вручную.
Godot 3D: кучка CSG шейпов; глаза: дырки с чёрной точкой на дне, такое часто юзают в аниме моделях.
Огонь:
1. Quad меш. Поставил галочки на "unshaded", "цвет вершин как альбедо" и "билборд для партиклов + keep scale" в StandardMaterial3D, конвертировал его в шейдер. В шейдере удалил всё лишнее (дало больше FPS), оставив только преобразования матриц для билборда и альбедо из вершин и из текстуры, добавил простейшую формулу для создания полупрозрачного круга (length(UV - vec2(0.5, 0.5));), чтобы выглядело гладко по краям, без острых углов. В альбедо поставил NoiseTexture2D с каким-то из шумов, чтобы разнообразить спрайты, плюс добавил необычный градиент для имитации чего-то вроде "волн" в огне (прозрачно > темно > прозрачно > светло и т.д.), он ложится на шум и создаёт узор. Перебрал много вариантов, тут по вкусу выбирать нужно - можно сделать гладкий поток, можно сделать завихрения, лабиринты какие-то, узоры, контуры. Это основа, в ней вся красота. Самое интересное начало получаться только когда в градиент текстуры шума добавил прозрачные точки, чтобы шум сделал из круга неровную кляксу. Градиент лучше оставить чёрно-белым, но можно добавить какой-либо оттенок, общий для всех частиц. Я хотел сделать ещё реалистичнее оттенки, но устал возиться.
2. GPU партиклы. Тут пришлось сильно повозиться, но только потому что параметры разбросаны как-то не интуитивно и я наугад их подбирал. Основное: начальный вектор скорости с разбросом (нужно, чтобы частицы летели и быстро, и медленно) и рандомный поворот при спавне (чтобы не выглядело как равномерная сетка, ведь спрайт всего один на всё), гравитация строго вверх (горячий газ взлетает), масштаб (расширяется: 0.5 > 10), градиент цвета (белый > жёлтый > оранжевый полупрозрачный > почти чёрный прозрачный, чтобы плавно исчезало), градиент эмиссии (в самом начале ярче светится, чем под конец). Дальше Sub Emitter - он почему-то должен иметь минимум в 2 раза больше частиц, чтобы спамить без перерывов. Это копия первой ноды, с тем же мешем и текстурой, но со своими настройками: нулевая скорость спавна, только взлёт вверх, увеличение масштаба ещё больше (10 > 30), градиент цвета от полупрозрачно оранжевого к чёрному прозрачному. Субчастицы эти спавнятся по истечению жизни предыдущих частиц, поэтому-то они должны лететь с разной скоростью (иначе весь дым будет в одной точке, а не облаком). Пробовал разобраться с коллизиями частиц, но что-то не получилось. Пробовал рандомные вариации оттенков (hue), но выключил - градиент точнее/удобнее регулирует переходы цвета. Ещё поставил Draw Order = View Depth, но это больше актуально если спрайты непрозрачные.
Есть один странный косяк у этой системы: при определённых положениях камеры порядок отображения между главными частицами и второстепенными резко переключается, из-за чего яркий жёлтый центр проступает через чёрный дым, который всё ещё на экране и должен его собой перекрывать. Draw Order с этим не помогает, что с этим делать - непонятно. Depth Draw тоже пробовал переключать, это не то. Впрочем, мне пока и так сойдёт.
904 Кб, mp4,600x600, 0:34
>>58103
Сегодня я узнал, что делать спецэффекты без референсов - всё равно что пытаться рисовать людей по памяти без знаний анатомии: получается какая-то нелепая кривота и я это интуитивно чувствую, но умом понять проблему не могу...
Сегодня я узнал, что делать спецэффекты без референсов - всё равно что пытаться рисовать людей по памяти без знаний анатомии: получается какая-то нелепая кривота и я это интуитивно чувствую, но умом понять проблему не могу...
>>57712
Захотел после этого анонса сделать следующую браузерку на 4-ке.
Пустая сцена террейн+моделька. В godot3 архив выходит 7Мб, в godot4 20Мб. Если без террейна, допустим сделаю террейн из кубиков, godot3 6Мб, godot4 12-14Мб.
Сам неупакованный wasm движка 20Мб против 60Мб.
В общем что-то опять сомнения по целесообразности вообще переползать на 4 в вебе.
Захотел после этого анонса сделать следующую браузерку на 4-ке.
Пустая сцена террейн+моделька. В godot3 архив выходит 7Мб, в godot4 20Мб. Если без террейна, допустим сделаю террейн из кубиков, godot3 6Мб, godot4 12-14Мб.
Сам неупакованный wasm движка 20Мб против 60Мб.
В общем что-то опять сомнения по целесообразности вообще переползать на 4 в вебе.
9 Кб, 198x235Подскажите про передвижение 3д объектов в редакторе. Я включаю снап. Объект двигается по секте в 1 юнит, это можно поменять в настройках, ок. Шифт+движение двигает его по 0.1 юниту, это в настройках можно поменять?
Или, альтерантивно, хочу поменять контрол+движение. Хочу 0.01 юнит вместо 0.001 как сейчас.
И еще вопрос про скалирование в редакторе. Неужели нельзя scale snap привязать к юнитам вместо процентов?
Или, альтерантивно, хочу поменять контрол+движение. Хочу 0.01 юнит вместо 0.001 как сейчас.
И еще вопрос про скалирование в редакторе. Неужели нельзя scale snap привязать к юнитам вместо процентов?
>>58242
Там вся игра в одной комнате происходит, лол. Все ресурсы загружаешь в RAM/VRAM и не паришься. Ландшафт за окном вообще может быть плоским.
>ТАК МОЖНО ЧТО ЛИ?
Там вся игра в одной комнате происходит, лол. Все ресурсы загружаешь в RAM/VRAM и не паришься. Ландшафт за окном вообще может быть плоским.
>>58248
По-моему, шифт снижает шаг привязки до 1/10 от установленного тобой значения без шифта. Но я привязкой с шифтом никогда не пользовался.
Что ты имеешь в виду? На Ctrl вроде бы зум.
Как ты себе это представляешь? Масштаб объектов вычисляется в процентах от обычного размера, например, Vector3(0.25, 1.0, 2.5): 25% по X, 100% по Y, 250% по Z. Так весь 3D софт работает по-моему. К каким таким юнитам ты хочешь это привязывать?
Но если очень нужно, можешь написать плагин. В документации есть объяснение, а тут есть примеры:
https://godotengine.org/asset-library/asset?filter=snap
>Шифт+движение двигает его по 0.1 юниту
По-моему, шифт снижает шаг привязки до 1/10 от установленного тобой значения без шифта. Но я привязкой с шифтом никогда не пользовался.
>контрол+движение. Хочу 0.01 юнит
Что ты имеешь в виду? На Ctrl вроде бы зум.
>scale snap привязать к юнитам
Как ты себе это представляешь? Масштаб объектов вычисляется в процентах от обычного размера, например, Vector3(0.25, 1.0, 2.5): 25% по X, 100% по Y, 250% по Z. Так весь 3D софт работает по-моему. К каким таким юнитам ты хочешь это привязывать?
Но если очень нужно, можешь написать плагин. В документации есть объяснение, а тут есть примеры:
https://godotengine.org/asset-library/asset?filter=snap
>>58251
Контрол+перетаскивание со снапом снапит по 0.001.
Не, например в Blockbench не так, и поскольку я все ассеты в нем делаю, хотелось бы сохранить скалирование по юнитам как в нем.
Жаль что по-дефолту такого поведения нет. Посмотрю плагины, спасибо.
>На Ctrl вроде бы зум.
Контрол+перетаскивание со снапом снапит по 0.001.
>Так весь 3D софт работает по-моему. К каким таким юнитам ты хочешь это привязывать?
Не, например в Blockbench не так, и поскольку я все ассеты в нем делаю, хотелось бы сохранить скалирование по юнитам как в нем.
Жаль что по-дефолту такого поведения нет. Посмотрю плагины, спасибо.
Как перестать мусолить один и тот же код, бесконечно его улучшая и оптимизируя, и начать жить добавлять новые вещи?
>>58254
Форма прокрастинации, чтобы игру не делать. Бороться так же как с любой прокрастинацией. Допиливаешь ммо-режим в свою кнопку в главном меню?
Форма прокрастинации, чтобы игру не делать. Бороться так же как с любой прокрастинацией. Допиливаешь ммо-режим в свою кнопку в главном меню?
>>58208
Вроде бы обещали сфокусироваться на улучшениях производительности и сокращении объёма в 4.4, не?
Да зачем эти веб-игры вообще нужны?..
Раньше, во времена Flash, Silverlight, Java апплетов, Unity Player и других подобных, игрок скачивал весь движок один раз и играл на нём во что угодно, игры в основном были простые и нетребовательные.
Потом они убили все эти плагины, объяснив это стремлением к безопасности, но реальные мотивы наверняка были в другом (монополизация вокруг гугловского хрома). Теперь каждая игра, даже самая простая, грузится как грёбанный фейсбук из 00-х.
Но ладно, игра загрузилась и... Браузер пукнул и сдох, потеряв все твои вкладки и просрав кэш, так что всё по-новой открывать и скачивать. А если не сдох, то тормозит как будто там ААА 3D в инди поделке, и это независимо от движка, потому что браузеры - говно.
На площадках типа Яндекс.Игр, где показ рекламы значительно важнее содержимого самих игр, играют только какие-то тупые школьники и старики, у кого компуктера нет и память в телефоне закончилась. Деградация аудитории связана с деградацией игр.
Короче, ящитаю, веб надо вернуть во времена где-то между Web1.0 и Web2.0, когда сайты были чистыми и лёгкими, а все эти примочки ещё не придумали, и ты заходил на сайт по делу, а не ждать закачки недоигр после ожидания закачки нескольких видов рекламы после ожидания закачки модного веб-фреймворка на 50 МБ, который используется для добавления <div>.
И это у меня ещё хорошая скорость, 8 МБ/с вроде бы, а как же люди, что живут в удалённых районах? Как раз деревенщина и есть основная ЦА веб-говна без установки, потому что они не шарят в компуктирах.
Хотите делать Игры - делайте для ПК.
>wasm движка 20Мб против 60Мб
Вроде бы обещали сфокусироваться на улучшениях производительности и сокращении объёма в 4.4, не?
>сомнения по целесообразности... в вебе
Да зачем эти веб-игры вообще нужны?..
Раньше, во времена Flash, Silverlight, Java апплетов, Unity Player и других подобных, игрок скачивал весь движок один раз и играл на нём во что угодно, игры в основном были простые и нетребовательные.
Потом они убили все эти плагины, объяснив это стремлением к безопасности, но реальные мотивы наверняка были в другом (монополизация вокруг гугловского хрома). Теперь каждая игра, даже самая простая, грузится как грёбанный фейсбук из 00-х.
Но ладно, игра загрузилась и... Браузер пукнул и сдох, потеряв все твои вкладки и просрав кэш, так что всё по-новой открывать и скачивать. А если не сдох, то тормозит как будто там ААА 3D в инди поделке, и это независимо от движка, потому что браузеры - говно.
На площадках типа Яндекс.Игр, где показ рекламы значительно важнее содержимого самих игр, играют только какие-то тупые школьники и старики, у кого компуктера нет и память в телефоне закончилась. Деградация аудитории связана с деградацией игр.
Короче, ящитаю, веб надо вернуть во времена где-то между Web1.0 и Web2.0, когда сайты были чистыми и лёгкими, а все эти примочки ещё не придумали, и ты заходил на сайт по делу, а не ждать закачки недоигр после ожидания закачки нескольких видов рекламы после ожидания закачки модного веб-фреймворка на 50 МБ, который используется для добавления <div>.
И это у меня ещё хорошая скорость, 8 МБ/с вроде бы, а как же люди, что живут в удалённых районах? Как раз деревенщина и есть основная ЦА веб-говна без установки, потому что они не шарят в компуктирах.
Хотите делать Игры - делайте для ПК.
Подскажите, как сделать разный collisionshape в зависимости от анимации? Нужно просто добавить новые ноды с animatedsprite и каждому прикрепить дочерний collisionshape? Или как-то можно сделать проще?
>>58260
Хотя там в принципе 2 получится в итоге, а не 4 для каждого. Т.е. размер спрайтов, для вверх/вниз одинаковый как и для лево/право.
Хотя там в принципе 2 получится в итоге, а не 4 для каждого. Т.е. размер спрайтов, для вверх/вниз одинаковый как и для лево/право.
>>58261
Хотя стоп, коллижн пишет мол только дочерним для ареа2д, а для анимации его привязать нельзя. Помогите тупому разобраться.
Хотя стоп, коллижн пишет мол только дочерним для ареа2д, а для анимации его привязать нельзя. Помогите тупому разобраться.
>>58252
Разве это снап? 0.001 вроде стандартный минимум изменения векторов в инспекторе. Я не знаю, где он настраивается, но все вектора округляются до 0.001, как минимум при отображении в редакторе.
Там вообще всё не как у людей, я ниасилил его. В блендере и то проще разобраться, всё как у людей.
Я не понимаю, что ты имеешь в виду. Какие юниты используются для масштаба? Масштаб в единицу - это сколько метров по расстоянию?
Я поискал, там ничего непонятно. Судя по всему, "размер" означает размер в блоках Minecraft. Это не масштабирование, это именно что "размер в блоках".
В Godot похожая настройка есть, например, у CSGBox, там можно изменить размер по каждой оси в метрах.
Короче, тут путаница в понятиях.
Масштаб (scale) - это изменение в процентах.
Размер (size) - в контексте майнкрафта - в кубиках.
>снапит по 0.001
Разве это снап? 0.001 вроде стандартный минимум изменения векторов в инспекторе. Я не знаю, где он настраивается, но все вектора округляются до 0.001, как минимум при отображении в редакторе.
>Blockbench
Там вообще всё не как у людей, я ниасилил его. В блендере и то проще разобраться, всё как у людей.
>скалирование по юнитам как в нем
Я не понимаю, что ты имеешь в виду. Какие юниты используются для масштаба? Масштаб в единицу - это сколько метров по расстоянию?
Я поискал, там ничего непонятно. Судя по всему, "размер" означает размер в блоках Minecraft. Это не масштабирование, это именно что "размер в блоках".
В Godot похожая настройка есть, например, у CSGBox, там можно изменить размер по каждой оси в метрах.
Короче, тут путаница в понятиях.
Масштаб (scale) - это изменение в процентах.
Размер (size) - в контексте майнкрафта - в кубиках.
>>58257
Потому что мне сейчас доступны только я.игры как площадка.
>Да зачем эти веб-игры вообще нужны?..
>Хотите делать Игры - делайте для ПК.
Потому что мне сейчас доступны только я.игры как площадка.
>>58260
Создаёшь в новый скрипт. В скрипте делаешь:
1. @export... для спрайта и всех коллизий.
2. Метод animate(анимация) для управления извне.
3. В методе вызываешь play() у спрайта.
4. Одновременно с этим переключаешь disabled:
Скрипт можешь повесить на отдельную Node в сцене игрока, либо на самого игрока/персонажа. В первом случае скрипт игрока должен получить ссылку на этот скрипт, т.к. управление анимацией через него.
>как сделать разный collisionshape в зависимости от анимации?
Создаёшь в новый скрипт. В скрипте делаешь:
1. @export... для спрайта и всех коллизий.
2. Метод animate(анимация) для управления извне.
3. В методе вызываешь play() у спрайта.
4. Одновременно с этим переключаешь disabled:
>for c in collisions: if c != current: c.disabled = true
>current.disabled = false
Скрипт можешь повесить на отдельную Node в сцене игрока, либо на самого игрока/персонажа. В первом случае скрипт игрока должен получить ссылку на этот скрипт, т.к. управление анимацией через него.
>>58260
Как вариант перейти с animated sprite на animation player и там вкл/выкл соответствующие коллайдеры.
https://youtu.be/8EVHNbgQCBg?si=ATq6han-WUHRktOi&t=926
Как вариант перейти с animated sprite на animation player и там вкл/выкл соответствующие коллайдеры.
https://youtu.be/8EVHNbgQCBg?si=ATq6han-WUHRktOi&t=926
>>58260 >>58265
Сразу предлагаю другой вариант.
У AnimationSprite2D есть сигнал animation_changed.
Создаём скрипт:
extends CollsionShape2D
@export var sprite: AnimationSprite2D
@export var enabling_animation: StringName
func _ready(): sprite.animation_changed.connect(_update)
func _update(): disabled = sprite.animation != enabling_animation
Связываем все коллиженшейпы ссылками на спрайт, вводим им названия анимаций, которые их должны активировать, и теперь всё работает автоматически с управлением анимациями AnimationSprite2D.play().
Сразу предлагаю другой вариант.
У AnimationSprite2D есть сигнал animation_changed.
Создаём скрипт:
extends CollsionShape2D
@export var sprite: AnimationSprite2D
@export var enabling_animation: StringName
func _ready(): sprite.animation_changed.connect(_update)
func _update(): disabled = sprite.animation != enabling_animation
Связываем все коллиженшейпы ссылками на спрайт, вводим им названия анимаций, которые их должны активировать, и теперь всё работает автоматически с управлением анимациями AnimationSprite2D.play().
>>58265
Я только учусь основам. Но примерно понял. Спасибо. Думал это немного проще делается.
Я только учусь основам. Но примерно понял. Спасибо. Думал это немного проще делается.
>>58269
Спасибо.
Спасибо.
>>58266
А, ну да, совсем забыл о нём.
>>58270
Читай вот эти страницы, там всё подробно:
https://docs.godotengine.org/en/stable/tutorials/animation/index.html
Это наиболее мощная система анимации, позволяет анимировать любые свойства любых нод и твой код.
А, ну да, совсем забыл о нём.
>>58270
>Я только учусь основам
Читай вот эти страницы, там всё подробно:
https://docs.godotengine.org/en/stable/tutorials/animation/index.html
Это наиболее мощная система анимации, позволяет анимировать любые свойства любых нод и твой код.
>>58272
Ну я понемногу мануал курю, вон игру 2д с него сделал. А сейчас решил сделать вместо доджера, что-то другое. Погуглил бесплатные ассеты на itch. Вон понравился песель. Идея простая, песель бегает по лужайке и собираем рандомно появляющиеся кости, счетчик считает количество костей. Для начала вроде будет нормально потренироваться. Тем более в учебном коде есть практически все для такого концепта.
Ну я понемногу мануал курю, вон игру 2д с него сделал. А сейчас решил сделать вместо доджера, что-то другое. Погуглил бесплатные ассеты на itch. Вон понравился песель. Идея простая, песель бегает по лужайке и собираем рандомно появляющиеся кости, счетчик считает количество костей. Для начала вроде будет нормально потренироваться. Тем более в учебном коде есть практически все для такого концепта.
>>58254
Нарисуй графическое изображение проекта со всеми отдельными компонентами на разных уровнях. Далее отметь в % прогресс разработки каждой части игры до юзабельного (можно использовать) состояния. Если слишком фокусируешься на одной части графика, то переходи к другой, чтобы % были равномерными.
Главное тут расставить приоритеты и делать то, что важнее для игры в первую очередь. Не следует переключаться на какие-то неважные детали.
>>58256
Как? Статьи о прокрастинации слишком длинные.
>>58259
А мог бы игру на ООП делать, нодами и сценами...
>Как перестать мусолить один и тот же код, бесконечно его улучшая и оптимизируя, и начать добавлять новые вещи?
Нарисуй графическое изображение проекта со всеми отдельными компонентами на разных уровнях. Далее отметь в % прогресс разработки каждой части игры до юзабельного (можно использовать) состояния. Если слишком фокусируешься на одной части графика, то переходи к другой, чтобы % были равномерными.
Главное тут расставить приоритеты и делать то, что важнее для игры в первую очередь. Не следует переключаться на какие-то неважные детали.
>>58256
>Бороться так же как с любой прокрастинацией
Как? Статьи о прокрастинации слишком длинные.
>>58259
>Долго и мучительно менял екс библиотеку
А мог бы игру на ООП делать, нодами и сценами...
>>58274
Попробую....
Или точно так же прокрастинировал бы, и переписывал бы рабочий код, потому что "не продумал архитектуру". Подозреваю тут дело не в подходе...
> Нарисуй графическое изображение
Попробую....
> А мог бы игру на ООП делать, нодами и сценами...
Или точно так же прокрастинировал бы, и переписывал бы рабочий код, потому что "не продумал архитектуру". Подозреваю тут дело не в подходе...
>>58273
Тогда оставь одну круглую коллизию, но уменьши её примерно в два раза. Спрайт собаки смести немного вверх, чтобы коллизия была ближе к ногам. Тогда, по идее, должно быть более интересно визуально (игрок должен непосредственно встать на кость, в не просто задать её, пробегая боком).
>песель бегает по лужайке и собираем рандомно появляющиеся кости, счетчик считает количество
Тогда оставь одну круглую коллизию, но уменьши её примерно в два раза. Спрайт собаки смести немного вверх, чтобы коллизия была ближе к ногам. Тогда, по идее, должно быть более интересно визуально (игрок должен непосредственно встать на кость, в не просто задать её, пробегая боком).
>>58276
Это не прокрастинация, это рефакторинг.
https://ru.wikipedia.org/wiki/Рефакторинг
Все серьёзные дяди в IT этим занимаются.
>прокрастинировал бы, и переписывал бы рабочий код, потому что "не продумал архитектуру"
Это не прокрастинация, это рефакторинг.
https://ru.wikipedia.org/wiki/Рефакторинг
Все серьёзные дяди в IT этим занимаются.
4 Кб, 256x256>>58277
Как вариант. Можно вообще на голову сместить, чтобы типа съедала, но тогда все равно 2 коллизии нужно
Как вариант. Можно вообще на голову сместить, чтобы типа съедала, но тогда все равно 2 коллизии нужно
>>58279
Не. Если хочешь чтобы типа съедала, тогда тут нужна дополнительная анимация собаки, а коллизия может остаться одной вблизи ног.
Такие коллизии вообще нужны для взаимодействия с неподвижными стенами в основном. Поэтому они должны быть простыми и, желательно, круглыми.
Коллизия, точно повторяющаяся спрайт, это обычно зоны попадания пуль или других подобных объектов.
Коллизия для сбора предметов зависит от игры, но, имхо, чаще встречается, что зона сбора предметов даже шире основной коллизии (ног/туловища).
>все равно 2 коллизии нужно
Не. Если хочешь чтобы типа съедала, тогда тут нужна дополнительная анимация собаки, а коллизия может остаться одной вблизи ног.
Такие коллизии вообще нужны для взаимодействия с неподвижными стенами в основном. Поэтому они должны быть простыми и, желательно, круглыми.
Коллизия, точно повторяющаяся спрайт, это обычно зоны попадания пуль или других подобных объектов.
Коллизия для сбора предметов зависит от игры, но, имхо, чаще встречается, что зона сбора предметов даже шире основной коллизии (ног/туловища).
7,3 Мб, mp4,1280x720, 0:22
У меня вопрос к знатокам. Как лучше всего сделать передвижение нпс в трёхмерном мире? Можно ли использовать NavigationMesh на больших плоскостях? Можно ли делить NavigationMesh на составляющие для оптимизации проекта; если да, то как (гайд или словами, буду благодарен в любом случае)?
>>58296
Да. Но обновление навмеша может быть дорогим, смотря как его сконфигурируешь. Если он строится по статик коллайдерам, а они довольно простые, то терпимо. Как делить - хз, не делил.
Это про тройку, в четверке слышал навмеш сильно прокачали.
Да. Но обновление навмеша может быть дорогим, смотря как его сконфигурируешь. Если он строится по статик коллайдерам, а они довольно простые, то терпимо. Как делить - хз, не делил.
Это про тройку, в четверке слышал навмеш сильно прокачали.
>>58299
Мне как раз надо про четвёрку, спасибо
Мне как раз надо про четвёрку, спасибо
>>58285
У меня пока появилась другая проблема, заставить проигрывать анимацию при движении по диагонали. На форумах пишут, что таки надо юзать анимейшентри, а это для начала лишняя информация. Либо через elif, но у меня чет оно не получается, где-то я туплю. Поразбираюсь пока с этим...
У меня пока появилась другая проблема, заставить проигрывать анимацию при движении по диагонали. На форумах пишут, что таки надо юзать анимейшентри, а это для начала лишняя информация. Либо через elif, но у меня чет оно не получается, где-то я туплю. Поразбираюсь пока с этим...
368 Кб, 957x518Зачем люди городят grainy shader, если можно воткнуть на весь экран полупрозрачную текстуру с шумом?
259 Кб, 1920x1030>>58301
Я сделал, чисто случайно, но сделал. Оказывается надо было 4 базовые направления через elif, а уже диагонали через if, тогда анимация играется нормально.
Я сделал, чисто случайно, но сделал. Оказывается надо было 4 базовые направления через elif, а уже диагонали через if, тогда анимация играется нормально.
>>58308
А ты возьми тетрадку с карандашом, начерти табличку и пойми как расставить условия.
Например такой вариант: вообще убрать elif, оставить if.
Или: разделить движение и анимации на отдельные блоки условий. Вызывать анимацию если velocity.x != 0
А ты возьми тетрадку с карандашом, начерти табличку и пойми как расставить условия.
Например такой вариант: вообще убрать elif, оставить if.
Или: разделить движение и анимации на отдельные блоки условий. Вызывать анимацию если velocity.x != 0
>>58310
Изначально там только if и было везде. Но тогда анимация не проигрывалась. Гуглил. Народ на зарубежных форумах писал, что надо анимейшентри юзать или елифы. Короче там связано с одновременным нажатием и тем, что пытаются проиграться 2 анимации сразу, поэтому получается только 1 кадр. Ну или я это так понял.
Изначально там только if и было везде. Но тогда анимация не проигрывалась. Гуглил. Народ на зарубежных форумах писал, что надо анимейшентри юзать или елифы. Короче там связано с одновременным нажатием и тем, что пытаются проиграться 2 анимации сразу, поэтому получается только 1 кадр. Ну или я это так понял.
>If up and left are held at the same time, the script will play the left animation and then the topleft animation every frame, which resets the animation.
>>58313
Зачем для этого что-то гуглить? Просто голову включай. По шагам проходи и понимай, что где проигрывается.
Зачем для этого что-то гуглить? Просто голову включай. По шагам проходи и понимай, что где проигрывается.
>>58308
Ты всё неправильно делаешь (неудобно). Лучше будет как-то так:
Ты всё неправильно делаешь (неудобно). Лучше будет как-то так:
>@export var speed: float = 100 # чтобы настраивать скорость из инспектора
>@onready var sprite := $AnimatedSprite2D # сохраняем ссылку - так удобнее
>func _process(delta):
> # Получаем Vector2 со всеми четырьмя направлениями, длиной не более 1:
> var input := Input.get_vector("move_left", "move_right", "move_up", "move_down")
> velocity = input x speed x delta # двач съедает звёздочку (x)
> if velocity.is_zero_approx(): sprite.stop() # никуда не идём
> else: # если куда-то идём - анимируем:
> _ # sprite.speed_scale = число x velocity.length() # если будешь делать бег (?)
> _ if velocity.y < 0: sprite.play("up")
> _ elif velocity.y > 0: sprite.play("down")
> _ if velocity.x < 0: sprite.play("left")
> _ elif velocity.x > 0: sprite.play("right")
>>58305
Зависит от того, какого эффекта ты хочешь добиться...
>воткнуть на весь экран полупрозрачную текстуру с шумом
Зависит от того, какого эффекта ты хочешь добиться...
>>58316
И как я без гугла должен был догаться почему дальше 1 кадра ничего не работает.
>>58319
У меня анимация идлы есть.
Кстати если оставлять коллижны для разных анимаций я уже догадался как это ещё можно сделать, через . disable = true/false. Можно в отдельную функцию ввести для сокращения кода, но я сделал просто под каждым ифом. Благо в самом движке можно включить отображение в дебагере и видеть, что происходит.
И как я без гугла должен был догаться почему дальше 1 кадра ничего не работает.
>>58319
У меня анимация идлы есть.
Кстати если оставлять коллижны для разных анимаций я уже догадался как это ещё можно сделать, через . disable = true/false. Можно в отдельную функцию ввести для сокращения кода, но я сделал просто под каждым ифом. Благо в самом движке можно включить отображение в дебагере и видеть, что происходит.
>>58299
Чё? Статики могут быть намного сложнее ригидов. Там ведь тримеши.
>>58296
Должно быть можно, но я не тестировал. Сложная тема вообще.
Я читал, что можно, но это не для оптимизации, а для составных сцен.
https://docs.godotengine.org/en/stable/tutorials/navigation/index.html
Это зависит от:
1. Размеры мира:
- Комнатки?
- Большой город?
- Процедурная бесконечность?
2. Используется ли высота (Y)? НЕ НЕРОВНОСТИ, а пересечения:
- Существуют ли в мире мосты/туннели, пересекающие пути?
- Можно ли прыгать, лазить по стенам, бегать по крышам?
3. Что должны делать NPC?
- находить цели или бесцельно блуждать?
- требуется ли им обходить друг друга?
- ходят ли они толпами или по одиночке?
- могут ли они ходить в неактивных чанках?
4. Как игрок влияет на маршруты? Как NPC должны реагировать?
Общие рекомендации:
- лучше AStar - он проще, чем навмеши.
- лучше упростить мир до 2D, если возможно.
- в большом мире сделать навигацию по чанкам.
- обход NPC друг друга - жопа, оставь надежду.
- в стратегиях управляй большими группами.
- лучше делой ЖРПГ с NPC-статистами))))
>по статик коллайдерам, а они довольно простые
Чё? Статики могут быть намного сложнее ригидов. Там ведь тримеши.
>>58296
>Можно ли использовать NavigationMesh на больших плоскостях?
Должно быть можно, но я не тестировал. Сложная тема вообще.
>Можно ли делить NavigationMesh на составляющие для оптимизации
Я читал, что можно, но это не для оптимизации, а для составных сцен.
>NavigationMesh гайд
https://docs.godotengine.org/en/stable/tutorials/navigation/index.html
>Как лучше всего сделать передвижение нпс в трёхмерном мире?
Это зависит от:
1. Размеры мира:
- Комнатки?
- Большой город?
- Процедурная бесконечность?
2. Используется ли высота (Y)? НЕ НЕРОВНОСТИ, а пересечения:
- Существуют ли в мире мосты/туннели, пересекающие пути?
- Можно ли прыгать, лазить по стенам, бегать по крышам?
3. Что должны делать NPC?
- находить цели или бесцельно блуждать?
- требуется ли им обходить друг друга?
- ходят ли они толпами или по одиночке?
- могут ли они ходить в неактивных чанках?
4. Как игрок влияет на маршруты? Как NPC должны реагировать?
Общие рекомендации:
- лучше AStar - он проще, чем навмеши.
- лучше упростить мир до 2D, если возможно.
- в большом мире сделать навигацию по чанкам.
- обход NPC друг друга - жопа, оставь надежду.
- в стратегиях управляй большими группами.
- лучше делой ЖРПГ с NPC-статистами))))
>>58299
Чё? Статики могут быть намного сложнее ригидов. Там ведь тримеши.
>>58296
Должно быть можно, но я не тестировал. Сложная тема вообще.
Я читал, что можно, но это не для оптимизации, а для составных сцен.
https://docs.godotengine.org/en/stable/tutorials/navigation/index.html
Это зависит от:
1. Размеры мира:
- Комнатки?
- Большой город?
- Процедурная бесконечность?
2. Используется ли высота (Y)? НЕ НЕРОВНОСТИ, а пересечения:
- Существуют ли в мире мосты/туннели, пересекающие пути?
- Можно ли прыгать, лазить по стенам, бегать по крышам?
3. Что должны делать NPC?
- находить цели или бесцельно блуждать?
- требуется ли им обходить друг друга?
- ходят ли они толпами или по одиночке?
- могут ли они ходить в неактивных чанках?
4. Как игрок влияет на маршруты? Как NPC должны реагировать?
Общие рекомендации:
- лучше AStar - он проще, чем навмеши.
- лучше упростить мир до 2D, если возможно.
- в большом мире сделать навигацию по чанкам.
- обход NPC друг друга - жопа, оставь надежду.
- в стратегиях управляй большими группами.
- лучше делой ЖРПГ с NPC-статистами))))
>по статик коллайдерам, а они довольно простые
Чё? Статики могут быть намного сложнее ригидов. Там ведь тримеши.
>>58296
>Можно ли использовать NavigationMesh на больших плоскостях?
Должно быть можно, но я не тестировал. Сложная тема вообще.
>Можно ли делить NavigationMesh на составляющие для оптимизации
Я читал, что можно, но это не для оптимизации, а для составных сцен.
>NavigationMesh гайд
https://docs.godotengine.org/en/stable/tutorials/navigation/index.html
>Как лучше всего сделать передвижение нпс в трёхмерном мире?
Это зависит от:
1. Размеры мира:
- Комнатки?
- Большой город?
- Процедурная бесконечность?
2. Используется ли высота (Y)? НЕ НЕРОВНОСТИ, а пересечения:
- Существуют ли в мире мосты/туннели, пересекающие пути?
- Можно ли прыгать, лазить по стенам, бегать по крышам?
3. Что должны делать NPC?
- находить цели или бесцельно блуждать?
- требуется ли им обходить друг друга?
- ходят ли они толпами или по одиночке?
- могут ли они ходить в неактивных чанках?
4. Как игрок влияет на маршруты? Как NPC должны реагировать?
Общие рекомендации:
- лучше AStar - он проще, чем навмеши.
- лучше упростить мир до 2D, если возможно.
- в большом мире сделать навигацию по чанкам.
- обход NPC друг друга - жопа, оставь надежду.
- в стратегиях управляй большими группами.
- лучше делой ЖРПГ с NPC-статистами))))
>>58324
Забыл ещё: как двигаются NPC?
- по клеточкам как фигурки в шахматах?
- идут строго по прямой, разворачиваясь на месте?
- едут на машине с каким-то радиусом разворота?
- летят на ракете в космосе?
Вопросов куча, ответить нужно на всё - для себя.
>3. Что должны делать NPC?
Забыл ещё: как двигаются NPC?
- по клеточкам как фигурки в шахматах?
- идут строго по прямой, разворачиваясь на месте?
- едут на машине с каким-то радиусом разворота?
- летят на ракете в космосе?
Вопросов куча, ответить нужно на всё - для себя.
>>58323
Пройтись по шагам.
var cond = 4
var x = 0
if cond > 0:
_x = 1
if cond > 2:
_x = 2
Понятно же что в такой ситуации x перезапишется внутри этого же кадра.
>И как я без гугла должен был догаться почему дальше 1 кадра ничего не работает.
Пройтись по шагам.
var cond = 4
var x = 0
if cond > 0:
_x = 1
if cond > 2:
_x = 2
Понятно же что в такой ситуации x перезапишется внутри этого же кадра.
>>58324
1. Город/Совковый ПГТ
2. В мире мосты/туннели, пересекающие пути. Ползание по стенам не планировал, но интересно как это работает.
3. Некоторые НПС просто блуждают, другие двигаются по маршруту. Из обоих типов переключение на третье состояние - преследование с последующей атакой. (через стейт машину могу сделать)
4. Маленькие НПС обходят игрока, а большие толкают. Не знаю как работать с навмешем, кроме примитивного преследования каких-то целей, когда сравниваю положение НПС и нужной точки.
>>58325
Двигаются НПС как физические объекты, к сетке не привязаны.
У меня получается делать отдельных примитивных болванчиков, которые в случайный промежуток времени выбирают случайную точку и идут к ней, а также могу делать преследование игрока, но не знаю как они должны избегать друг друга, чтобы не сталкивались во время передвижения. Документацию давно читал, вроде ничего не было про это. Надо будет снова перепрочитать.
Алсо, может есть инфа про то как в скайриме работал ии противников/НПС? Там ведь не вручную расставляли сетку перемещения и вряд-ли навигационный меш был на всю карту один здоровый.
Нет, я не делаю скайрим 2, просто у меня карта большая, это обусловлено особенностями геймплея, а не размерами ради размера, шоб как в трипл эй
Спасибо
1. Город/Совковый ПГТ
2. В мире мосты/туннели, пересекающие пути. Ползание по стенам не планировал, но интересно как это работает.
3. Некоторые НПС просто блуждают, другие двигаются по маршруту. Из обоих типов переключение на третье состояние - преследование с последующей атакой. (через стейт машину могу сделать)
4. Маленькие НПС обходят игрока, а большие толкают. Не знаю как работать с навмешем, кроме примитивного преследования каких-то целей, когда сравниваю положение НПС и нужной точки.
>>58325
Двигаются НПС как физические объекты, к сетке не привязаны.
У меня получается делать отдельных примитивных болванчиков, которые в случайный промежуток времени выбирают случайную точку и идут к ней, а также могу делать преследование игрока, но не знаю как они должны избегать друг друга, чтобы не сталкивались во время передвижения. Документацию давно читал, вроде ничего не было про это. Надо будет снова перепрочитать.
Алсо, может есть инфа про то как в скайриме работал ии противников/НПС? Там ведь не вручную расставляли сетку перемещения и вряд-ли навигационный меш был на всю карту один здоровый.
Нет, я не делаю скайрим 2, просто у меня карта большая, это обусловлено особенностями геймплея, а не размерами ради размера, шоб как в трипл эй
Спасибо
>>58324
У навмеша есть опция генерации меша по, собственно, MeshInstance. Вот он был самый медленный, потому что модельки как правило сложнее чем их коллизии. ЕМНИП он стоял по дефолту.
>Чё? Статики могут быть намного сложнее ригидов. Там ведь тримеши.
У навмеша есть опция генерации меша по, собственно, MeshInstance. Вот он был самый медленный, потому что модельки как правило сложнее чем их коллизии. ЕМНИП он стоял по дефолту.
>>58327
Если мелкий - возможно, уместится в одну сцену. Главное чтоб LODы работали. Ещё можно настроить HLOD для объединения дальних объектов в цельный объект-заглушку. Если город большой, придётся резать на чанки и уже для чанков делать HLOD, в том числе для навигации NPC. Также есть вариант разделить город не на чанки, а на районы, например, в GTA 3 по идее всего 3 вытянутых района, разделённых мостами, между которыми есть загрузочный экран (на современном ПК экран пролетает за долю секунды, но в прошлом он имел смысл).
Кстати, вспомнилось что-то: в GTA IV машины, едущие по мосту, пугаются проезжающего трамвая и пытаются его объехать по другой полосе, потому что у них навигация как-то странно в 2D запечена и для них проезжающий под мостом трамвай выглядит внезапным препятствием. Очевидно, что навигация в игре оптимизирована в 2D, игнорируя высоту, и в большинстве случаев этого хватает - кроме таких вот мостов. Но в GTA V они это как-то пофиксили.
ИМХО, это уже не задача навмеша/а-стара, т.к. поведение в непосредственной близости игрока. Если персонаж приближается к игроку, у него срабатывает логика обхода/толкания. Вопрос в том, должны ли они делать то же самое для всех персонажей в поле видимости игрока или только для игрока. Персонажи вдалеке от игрока могут вообще не использовать физику, если их нужно много... CharacterBody3D вообще сильно жрёт производительность, Area3D тоже не слишком быстра, самое быстрое - это считать квадрат расстояния или вхождение точки в Rect2, но это если тебе нужны прям сотни NPC на относительно слабом ЦПУ. Оптимизации в любом случае понадобятся...
Кстати, узнал где-то такую фичу: навигация может быть привязана к графу точек (waypoint называются), а NPC идут или едут по физике (когда она доступна), стараясь приблизительно достичь заданной точки. Т.к. доходить прямо до точки им не обязательно (допускается погрешность), в целом движение не выглядит привязанным к сетке. Точки могут быть выстроены по-разному, не обязательно сеткой.
Систему навигации сильно переделали в 4.x. Вроде бы вот тут объясняется:
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_using_navigationobstacles.html
Если использовать AStar на вейпойнтах, то точки графа можно временно отключать:
https://docs.godotengine.org/en/stable/classes/class_astar3d.html#class-astar3d-method-set-point-disabled
Не знаю, но быстрый поиск показал, что там есть навмеши на кусках карты. Но юзабельных дорог там немного, и возможно, что NPC выбирают дороги через систему вейпойнтов, а на открытой местности используют навмеш. Роль навмеша - избежать столкновения с какими-нибудь рандомными деревьями или бочками, а роль вейпойнтов - построить путь до населённого пункта по имеющимся дорогам с развилками. Но, возможно, что там что-то другое.
Если не ошибаюсь, то как минимум в старых GTA (3/VC/SA) пешеходы ходят по сети точек, расположенных на тротуарах. В игре это хорошо заметно, когда NPC, убегающий от игрока или догоняющий игрока, предпочтёт бежать по тротуару вместо того, чтобы бежать по проезжей части или траве (и это, имхо, реалистично до некоторой степени). Автомобили тоже следуют точкам, но на проезжей части - можешь представить это как игру Pacman, где вместо пакмана - машина NPC, а точки невидимые. Все эти пути можно как-то менять в файлах игры...
В целом, система вейпойнтов не так сложна для настройки, потому что вейпойнты предполагается ставить на большом друг от друга расстоянии - их не нужно спамить плотно, это может быть сильно разреженная сеть.
Запаришься с чанковой системой и подгрузкой/выгрузкой... А что уже есть, если не секрет?
Геймплей ближе к РПГ про средневековье или к ГТА про современный город? Просто интересно, почему тебя интересует именно Скайрим - РПГ с редкими лошадьми, если у тебя современный город с автомобилями...
>>58330
Для ландшафта имеет смысл тримеш (ConcavePolygonShape3D) использовать, чтобы он повторял визуальный меш, если нет возможности использовать HeightMapShape3D (у неё свои нюансы). Для дорог с частыми ямами, насыпями и бордюрами тоже тримеш лучше форму повторит, чем куча простых шейпов. Мне кажется, не стоит экономить на шейпах проходимой поверхности, чтобы ноги персонажей и колёса машин не проваливались "в текстуры" и не висели в воздухе. Экономить можно только на объектах, к которым персонаж подходит, например, статуя, стена, отвесная часть скалы - к ним нет никаких вопросов, если игрок не может подойти вплотную к чисто визуальной впадине.
>посёлок городского типа
Если мелкий - возможно, уместится в одну сцену. Главное чтоб LODы работали. Ещё можно настроить HLOD для объединения дальних объектов в цельный объект-заглушку. Если город большой, придётся резать на чанки и уже для чанков делать HLOD, в том числе для навигации NPC. Также есть вариант разделить город не на чанки, а на районы, например, в GTA 3 по идее всего 3 вытянутых района, разделённых мостами, между которыми есть загрузочный экран (на современном ПК экран пролетает за долю секунды, но в прошлом он имел смысл).
>В мире мосты/туннели
Кстати, вспомнилось что-то: в GTA IV машины, едущие по мосту, пугаются проезжающего трамвая и пытаются его объехать по другой полосе, потому что у них навигация как-то странно в 2D запечена и для них проезжающий под мостом трамвай выглядит внезапным препятствием. Очевидно, что навигация в игре оптимизирована в 2D, игнорируя высоту, и в большинстве случаев этого хватает - кроме таких вот мостов. Но в GTA V они это как-то пофиксили.
>Маленькие НПС обходят игрока, а большие толкают
ИМХО, это уже не задача навмеша/а-стара, т.к. поведение в непосредственной близости игрока. Если персонаж приближается к игроку, у него срабатывает логика обхода/толкания. Вопрос в том, должны ли они делать то же самое для всех персонажей в поле видимости игрока или только для игрока. Персонажи вдалеке от игрока могут вообще не использовать физику, если их нужно много... CharacterBody3D вообще сильно жрёт производительность, Area3D тоже не слишком быстра, самое быстрое - это считать квадрат расстояния или вхождение точки в Rect2, но это если тебе нужны прям сотни NPC на относительно слабом ЦПУ. Оптимизации в любом случае понадобятся...
>как физические объекты, к сетке не привязаны
Кстати, узнал где-то такую фичу: навигация может быть привязана к графу точек (waypoint называются), а NPC идут или едут по физике (когда она доступна), стараясь приблизительно достичь заданной точки. Т.к. доходить прямо до точки им не обязательно (допускается погрешность), в целом движение не выглядит привязанным к сетке. Точки могут быть выстроены по-разному, не обязательно сеткой.
>чтобы не сталкивались во время передвижения. Документацию давно читал, вроде ничего не было
Систему навигации сильно переделали в 4.x. Вроде бы вот тут объясняется:
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_using_navigationobstacles.html
Если использовать AStar на вейпойнтах, то точки графа можно временно отключать:
https://docs.godotengine.org/en/stable/classes/class_astar3d.html#class-astar3d-method-set-point-disabled
>как в скайриме работал ии противников/НПС?
Не знаю, но быстрый поиск показал, что там есть навмеши на кусках карты. Но юзабельных дорог там немного, и возможно, что NPC выбирают дороги через систему вейпойнтов, а на открытой местности используют навмеш. Роль навмеша - избежать столкновения с какими-нибудь рандомными деревьями или бочками, а роль вейпойнтов - построить путь до населённого пункта по имеющимся дорогам с развилками. Но, возможно, что там что-то другое.
>Там ведь не вручную расставляли сетку перемещения
Если не ошибаюсь, то как минимум в старых GTA (3/VC/SA) пешеходы ходят по сети точек, расположенных на тротуарах. В игре это хорошо заметно, когда NPC, убегающий от игрока или догоняющий игрока, предпочтёт бежать по тротуару вместо того, чтобы бежать по проезжей части или траве (и это, имхо, реалистично до некоторой степени). Автомобили тоже следуют точкам, но на проезжей части - можешь представить это как игру Pacman, где вместо пакмана - машина NPC, а точки невидимые. Все эти пути можно как-то менять в файлах игры...
В целом, система вейпойнтов не так сложна для настройки, потому что вейпойнты предполагается ставить на большом друг от друга расстоянии - их не нужно спамить плотно, это может быть сильно разреженная сеть.
>просто у меня карта большая
Запаришься с чанковой системой и подгрузкой/выгрузкой... А что уже есть, если не секрет?
>обусловлено особенностями геймплея
Геймплей ближе к РПГ про средневековье или к ГТА про современный город? Просто интересно, почему тебя интересует именно Скайрим - РПГ с редкими лошадьми, если у тебя современный город с автомобилями...
>>58330
>модельки как правило сложнее чем их коллизии
Для ландшафта имеет смысл тримеш (ConcavePolygonShape3D) использовать, чтобы он повторял визуальный меш, если нет возможности использовать HeightMapShape3D (у неё свои нюансы). Для дорог с частыми ямами, насыпями и бордюрами тоже тримеш лучше форму повторит, чем куча простых шейпов. Мне кажется, не стоит экономить на шейпах проходимой поверхности, чтобы ноги персонажей и колёса машин не проваливались "в текстуры" и не висели в воздухе. Экономить можно только на объектах, к которым персонаж подходит, например, статуя, стена, отвесная часть скалы - к ним нет никаких вопросов, если игрок не может подойти вплотную к чисто визуальной впадине.
>>58327
Если мелкий - возможно, уместится в одну сцену. Главное чтоб LODы работали. Ещё можно настроить HLOD для объединения дальних объектов в цельный объект-заглушку. Если город большой, придётся резать на чанки и уже для чанков делать HLOD, в том числе для навигации NPC. Также есть вариант разделить город не на чанки, а на районы, например, в GTA 3 по идее всего 3 вытянутых района, разделённых мостами, между которыми есть загрузочный экран (на современном ПК экран пролетает за долю секунды, но в прошлом он имел смысл).
Кстати, вспомнилось что-то: в GTA IV машины, едущие по мосту, пугаются проезжающего трамвая и пытаются его объехать по другой полосе, потому что у них навигация как-то странно в 2D запечена и для них проезжающий под мостом трамвай выглядит внезапным препятствием. Очевидно, что навигация в игре оптимизирована в 2D, игнорируя высоту, и в большинстве случаев этого хватает - кроме таких вот мостов. Но в GTA V они это как-то пофиксили.
ИМХО, это уже не задача навмеша/а-стара, т.к. поведение в непосредственной близости игрока. Если персонаж приближается к игроку, у него срабатывает логика обхода/толкания. Вопрос в том, должны ли они делать то же самое для всех персонажей в поле видимости игрока или только для игрока. Персонажи вдалеке от игрока могут вообще не использовать физику, если их нужно много... CharacterBody3D вообще сильно жрёт производительность, Area3D тоже не слишком быстра, самое быстрое - это считать квадрат расстояния или вхождение точки в Rect2, но это если тебе нужны прям сотни NPC на относительно слабом ЦПУ. Оптимизации в любом случае понадобятся...
Кстати, узнал где-то такую фичу: навигация может быть привязана к графу точек (waypoint называются), а NPC идут или едут по физике (когда она доступна), стараясь приблизительно достичь заданной точки. Т.к. доходить прямо до точки им не обязательно (допускается погрешность), в целом движение не выглядит привязанным к сетке. Точки могут быть выстроены по-разному, не обязательно сеткой.
Систему навигации сильно переделали в 4.x. Вроде бы вот тут объясняется:
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_using_navigationobstacles.html
Если использовать AStar на вейпойнтах, то точки графа можно временно отключать:
https://docs.godotengine.org/en/stable/classes/class_astar3d.html#class-astar3d-method-set-point-disabled
Не знаю, но быстрый поиск показал, что там есть навмеши на кусках карты. Но юзабельных дорог там немного, и возможно, что NPC выбирают дороги через систему вейпойнтов, а на открытой местности используют навмеш. Роль навмеша - избежать столкновения с какими-нибудь рандомными деревьями или бочками, а роль вейпойнтов - построить путь до населённого пункта по имеющимся дорогам с развилками. Но, возможно, что там что-то другое.
Если не ошибаюсь, то как минимум в старых GTA (3/VC/SA) пешеходы ходят по сети точек, расположенных на тротуарах. В игре это хорошо заметно, когда NPC, убегающий от игрока или догоняющий игрока, предпочтёт бежать по тротуару вместо того, чтобы бежать по проезжей части или траве (и это, имхо, реалистично до некоторой степени). Автомобили тоже следуют точкам, но на проезжей части - можешь представить это как игру Pacman, где вместо пакмана - машина NPC, а точки невидимые. Все эти пути можно как-то менять в файлах игры...
В целом, система вейпойнтов не так сложна для настройки, потому что вейпойнты предполагается ставить на большом друг от друга расстоянии - их не нужно спамить плотно, это может быть сильно разреженная сеть.
Запаришься с чанковой системой и подгрузкой/выгрузкой... А что уже есть, если не секрет?
Геймплей ближе к РПГ про средневековье или к ГТА про современный город? Просто интересно, почему тебя интересует именно Скайрим - РПГ с редкими лошадьми, если у тебя современный город с автомобилями...
>>58330
Для ландшафта имеет смысл тримеш (ConcavePolygonShape3D) использовать, чтобы он повторял визуальный меш, если нет возможности использовать HeightMapShape3D (у неё свои нюансы). Для дорог с частыми ямами, насыпями и бордюрами тоже тримеш лучше форму повторит, чем куча простых шейпов. Мне кажется, не стоит экономить на шейпах проходимой поверхности, чтобы ноги персонажей и колёса машин не проваливались "в текстуры" и не висели в воздухе. Экономить можно только на объектах, к которым персонаж подходит, например, статуя, стена, отвесная часть скалы - к ним нет никаких вопросов, если игрок не может подойти вплотную к чисто визуальной впадине.
>посёлок городского типа
Если мелкий - возможно, уместится в одну сцену. Главное чтоб LODы работали. Ещё можно настроить HLOD для объединения дальних объектов в цельный объект-заглушку. Если город большой, придётся резать на чанки и уже для чанков делать HLOD, в том числе для навигации NPC. Также есть вариант разделить город не на чанки, а на районы, например, в GTA 3 по идее всего 3 вытянутых района, разделённых мостами, между которыми есть загрузочный экран (на современном ПК экран пролетает за долю секунды, но в прошлом он имел смысл).
>В мире мосты/туннели
Кстати, вспомнилось что-то: в GTA IV машины, едущие по мосту, пугаются проезжающего трамвая и пытаются его объехать по другой полосе, потому что у них навигация как-то странно в 2D запечена и для них проезжающий под мостом трамвай выглядит внезапным препятствием. Очевидно, что навигация в игре оптимизирована в 2D, игнорируя высоту, и в большинстве случаев этого хватает - кроме таких вот мостов. Но в GTA V они это как-то пофиксили.
>Маленькие НПС обходят игрока, а большие толкают
ИМХО, это уже не задача навмеша/а-стара, т.к. поведение в непосредственной близости игрока. Если персонаж приближается к игроку, у него срабатывает логика обхода/толкания. Вопрос в том, должны ли они делать то же самое для всех персонажей в поле видимости игрока или только для игрока. Персонажи вдалеке от игрока могут вообще не использовать физику, если их нужно много... CharacterBody3D вообще сильно жрёт производительность, Area3D тоже не слишком быстра, самое быстрое - это считать квадрат расстояния или вхождение точки в Rect2, но это если тебе нужны прям сотни NPC на относительно слабом ЦПУ. Оптимизации в любом случае понадобятся...
>как физические объекты, к сетке не привязаны
Кстати, узнал где-то такую фичу: навигация может быть привязана к графу точек (waypoint называются), а NPC идут или едут по физике (когда она доступна), стараясь приблизительно достичь заданной точки. Т.к. доходить прямо до точки им не обязательно (допускается погрешность), в целом движение не выглядит привязанным к сетке. Точки могут быть выстроены по-разному, не обязательно сеткой.
>чтобы не сталкивались во время передвижения. Документацию давно читал, вроде ничего не было
Систему навигации сильно переделали в 4.x. Вроде бы вот тут объясняется:
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_using_navigationobstacles.html
Если использовать AStar на вейпойнтах, то точки графа можно временно отключать:
https://docs.godotengine.org/en/stable/classes/class_astar3d.html#class-astar3d-method-set-point-disabled
>как в скайриме работал ии противников/НПС?
Не знаю, но быстрый поиск показал, что там есть навмеши на кусках карты. Но юзабельных дорог там немного, и возможно, что NPC выбирают дороги через систему вейпойнтов, а на открытой местности используют навмеш. Роль навмеша - избежать столкновения с какими-нибудь рандомными деревьями или бочками, а роль вейпойнтов - построить путь до населённого пункта по имеющимся дорогам с развилками. Но, возможно, что там что-то другое.
>Там ведь не вручную расставляли сетку перемещения
Если не ошибаюсь, то как минимум в старых GTA (3/VC/SA) пешеходы ходят по сети точек, расположенных на тротуарах. В игре это хорошо заметно, когда NPC, убегающий от игрока или догоняющий игрока, предпочтёт бежать по тротуару вместо того, чтобы бежать по проезжей части или траве (и это, имхо, реалистично до некоторой степени). Автомобили тоже следуют точкам, но на проезжей части - можешь представить это как игру Pacman, где вместо пакмана - машина NPC, а точки невидимые. Все эти пути можно как-то менять в файлах игры...
В целом, система вейпойнтов не так сложна для настройки, потому что вейпойнты предполагается ставить на большом друг от друга расстоянии - их не нужно спамить плотно, это может быть сильно разреженная сеть.
>просто у меня карта большая
Запаришься с чанковой системой и подгрузкой/выгрузкой... А что уже есть, если не секрет?
>обусловлено особенностями геймплея
Геймплей ближе к РПГ про средневековье или к ГТА про современный город? Просто интересно, почему тебя интересует именно Скайрим - РПГ с редкими лошадьми, если у тебя современный город с автомобилями...
>>58330
>модельки как правило сложнее чем их коллизии
Для ландшафта имеет смысл тримеш (ConcavePolygonShape3D) использовать, чтобы он повторял визуальный меш, если нет возможности использовать HeightMapShape3D (у неё свои нюансы). Для дорог с частыми ямами, насыпями и бордюрами тоже тримеш лучше форму повторит, чем куча простых шейпов. Мне кажется, не стоит экономить на шейпах проходимой поверхности, чтобы ноги персонажей и колёса машин не проваливались "в текстуры" и не висели в воздухе. Экономить можно только на объектах, к которым персонаж подходит, например, статуя, стена, отвесная часть скалы - к ним нет никаких вопросов, если игрок не может подойти вплотную к чисто визуальной впадине.
Почему я не могу добавить одну сцену несколько раз к главной ноде?!
Это работает
draw_road_one(["road_straight", "road_straight", "road_straight"])
func draw_road_one(paths: Array):
var y = 0
var z = 0
var path = load("res://scenes/%s.tscn" % paths[0]).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Это не работает
draw_road_many(["road_straight", "road_straight", "road_straight"])
func draw_road_many(paths: Array):
var y = 0
var z = 0
for i in paths:
var path = load("res://scenes/%s.tscn" % i).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Несколько раз переписывал, но не могу уловить опечатку в коде.
Это работает
draw_road_one(["road_straight", "road_straight", "road_straight"])
func draw_road_one(paths: Array):
var y = 0
var z = 0
var path = load("res://scenes/%s.tscn" % paths[0]).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Это не работает
draw_road_many(["road_straight", "road_straight", "road_straight"])
func draw_road_many(paths: Array):
var y = 0
var z = 0
for i in paths:
var path = load("res://scenes/%s.tscn" % i).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Несколько раз переписывал, но не могу уловить опечатку в коде.
Почему я не могу добавить одну сцену несколько раз к главной ноде?!
Это работает
draw_road_one(["road_straight", "road_straight", "road_straight"])
func draw_road_one(paths: Array):
var y = 0
var z = 0
var path = load("res://scenes/%s.tscn" % paths[0]).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Это не работает
draw_road_many(["road_straight", "road_straight", "road_straight"])
func draw_road_many(paths: Array):
var y = 0
var z = 0
for i in paths:
var path = load("res://scenes/%s.tscn" % i).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Несколько раз переписывал, но не могу уловить опечатку в коде.
Это работает
draw_road_one(["road_straight", "road_straight", "road_straight"])
func draw_road_one(paths: Array):
var y = 0
var z = 0
var path = load("res://scenes/%s.tscn" % paths[0]).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Это не работает
draw_road_many(["road_straight", "road_straight", "road_straight"])
func draw_road_many(paths: Array):
var y = 0
var z = 0
for i in paths:
var path = load("res://scenes/%s.tscn" % i).instantiate()
y -= 1
z += 100
get_parent().add_child.call_deferred(path)
path.position = Vector3(0, y, z)
pass
Несколько раз переписывал, но не могу уловить опечатку в коде.
>>58334
Запусти отладчик и посмотри в remote какая реальная структура, сколько добавилось и какие у них координаты.
Запусти отладчик и посмотри в remote какая реальная структура, сколько добавилось и какие у них координаты.
>>57707 Я сделал сущность кубика, и дол ему свойство selected: bool , меняю по клику, создаю несколько кубиков с помощью .new() и они делят одно св-во на всех, как сделать так чтобу у каждого куба было свое состояние?
>>58374
нужно сделать свой класс из "кубик + новое свойство" и инстанцировать экземпляры нового класса.
нужно сделать свой класс из "кубик + новое свойство" и инстанцировать экземпляры нового класса.
>>58384
Может я в коде ошибся, вот что я накалякал и результат: все кубы ебашат одновременно
Может я в коде ошибся, вот что я накалякал и результат: все кубы ебашат одновременно
>>58387
Но тогда я должен id устанавливать снаружи MyButton, а я хочу внутри
Но тогда я должен id устанавливать снаружи MyButton, а я хочу внутри
>>58385
Наверное, надо писать texture = textureRes.duplicate()
Правда я вообще не знаю зачем там ресурс понадобился.
Наверное, надо писать texture = textureRes.duplicate()
Правда я вообще не знаю зачем там ресурс понадобился.
>>57712
Храни боже Адама за то что он решил заняться вебом. Похуй что бета, переползаю на четверку. Правда сначала нужно потестить, но не думаю что чето критичное будет.
>Однопоточный веб экспорт
>Проигрыватель сэмплов, для веб аудио без заиканий.
Храни боже Адама за то что он решил заняться вебом. Похуй что бета, переползаю на четверку. Правда сначала нужно потестить, но не думаю что чето критичное будет.
>>58274
Я тут задумался, а есть ли инструменты для
Я конечно понимаю, что всё можно текстом описать и карандашом нарисовать, но нет ли каких-нибудь удобных штук для составления диздока?
Я тут задумался, а есть ли инструменты для
> Нарисуй графическое изображение проекта
Я конечно понимаю, что всё можно текстом описать и карандашом нарисовать, но нет ли каких-нибудь удобных штук для составления диздока?
>>58412
https://excalidraw.com/ - редактор для эффективных менеджеров, хорошо работает даже на телефоне.
https://obsidian.md/ - пишешь txt-заметки, а он тебе [[ссылки]] и граф (заметки - узлы, ссылки - рёбра).
Специализированного софта для проджект-менеджмента много, но соло инди это всё обычно не нужно.
>текстом описать и карандашом нарисовать
https://excalidraw.com/ - редактор для эффективных менеджеров, хорошо работает даже на телефоне.
>удобных штук для составления диздока
https://obsidian.md/ - пишешь txt-заметки, а он тебе [[ссылки]] и граф (заметки - узлы, ссылки - рёбра).
Специализированного софта для проджект-менеджмента много, но соло инди это всё обычно не нужно.
>>58422
А что конкретно тебе нужно масштабировать?
Если ты масштабируешь объект (например, простой кубик) размером 1 на 1 на 1 метр (Vector3.ONE), то любое число в scale будет идентично размеру в метрах:
Если ты масштабируешь объект размером X на Y на Z метр, то формула такая:
Как понимаешь, если initial_size == Vector3.ONE, то получаем предыдущее выражение.
У Mesh есть get_aabb(), возвращает минимальный AABB, в который вписывается меш, но я сомневаюсь, что это надёжно для определения "размера в метрах" для общего случая.
Вроде бы в плагине можно сделать ручки управления как у CSGBox3D:
https://docs.godotengine.org/en/stable/tutorials/plugins/editor/3d_gizmos.html
И тогда можно будет наращивать/убирать размер с каждой из трёх сторон по шагам.
Но зачем тебе это нужно для мешей - непонятно...
CollisionShape3D нельзя масштабировать неравномерно - баги, изменяй Shape3D.
CollisionObject3D вообще никак нельзя масштабировать - баги, изменяй потомков.
Остальные Node3D вроде не нуждаются масштабировании...
>плагин на скалинрование по юнитам вместо процентов
А что конкретно тебе нужно масштабировать?
Если ты масштабируешь объект (например, простой кубик) размером 1 на 1 на 1 метр (Vector3.ONE), то любое число в scale будет идентично размеру в метрах:
>scale = size
Если ты масштабируешь объект размером X на Y на Z метр, то формула такая:
>scale = Vector3.ONE / initial_size × size
Как понимаешь, если initial_size == Vector3.ONE, то получаем предыдущее выражение.
У Mesh есть get_aabb(), возвращает минимальный AABB, в который вписывается меш, но я сомневаюсь, что это надёжно для определения "размера в метрах" для общего случая.
Вроде бы в плагине можно сделать ручки управления как у CSGBox3D:
https://docs.godotengine.org/en/stable/tutorials/plugins/editor/3d_gizmos.html
И тогда можно будет наращивать/убирать размер с каждой из трёх сторон по шагам.
Но зачем тебе это нужно для мешей - непонятно...
CollisionShape3D нельзя масштабировать неравномерно - баги, изменяй Shape3D.
CollisionObject3D вообще никак нельзя масштабировать - баги, изменяй потомков.
Остальные Node3D вроде не нуждаются масштабировании...
>>58419
Спасибо!
Спасибо!
>>58424
Мне нужен удобный гизмо или хотя бы хоткеи, чтобы не вбивать значения в поля scale руками. И чтобы этот гизмо/хоткей снапался по 1 юниту, без этих scale.x=11.424, которые в итоге получаются от скалирования дефолтным процентным гизмо.
Мне нужен удобный гизмо или хотя бы хоткеи, чтобы не вбивать значения в поля scale руками. И чтобы этот гизмо/хоткей снапался по 1 юниту, без этих scale.x=11.424, которые в итоге получаются от скалирования дефолтным процентным гизмо.
>>58428
Ещё раз: зачем тебе это в редакторе сцен Godot? Я так и не понял этого. Как я это понимаю:
1. Хочешь накидать прототип по-быстрому -> юзай CSGBox (сцену можно экспортировать в GLTF).
2. Хочешь делать воксельную сцену прямо в Godot -> https://github.com/Zylann/godot_voxel
3. Хочешь масштабировать импортированные модели с привязкой по кубикам -> но зачем???
Возможно, у тебя http://ru.wikipedia.org/wiki/Проблема_XY ?
>снапался по 1 юниту
Ещё раз: зачем тебе это в редакторе сцен Godot? Я так и не понял этого. Как я это понимаю:
1. Хочешь накидать прототип по-быстрому -> юзай CSGBox (сцену можно экспортировать в GLTF).
2. Хочешь делать воксельную сцену прямо в Godot -> https://github.com/Zylann/godot_voxel
3. Хочешь масштабировать импортированные модели с привязкой по кубикам -> но зачем???
Возможно, у тебя http://ru.wikipedia.org/wiki/Проблема_XY ?
>>58430
Нет, у меня не проблема XY, я строю блоковые уровни, элементы в которых должны быть расположены по сетке. А переходить на воксели - это ты из пушки по воробьям. Более-менее мою проблему решают гридмапы, но большой гридмап сажает производительность плюс имеет другие ограничения, которые все равно приходится закрывать обычными spatial сценами.
И конечно мою проблему решает пойти в свойства объекта и вручную выставить скейл 2, 3, 4 ... 14, но я заебался уже так делать, хочу оптимизировать процесс.
Нет, у меня не проблема XY, я строю блоковые уровни, элементы в которых должны быть расположены по сетке. А переходить на воксели - это ты из пушки по воробьям. Более-менее мою проблему решают гридмапы, но большой гридмап сажает производительность плюс имеет другие ограничения, которые все равно приходится закрывать обычными spatial сценами.
И конечно мою проблему решает пойти в свойства объекта и вручную выставить скейл 2, 3, 4 ... 14, но я заебался уже так делать, хочу оптимизировать процесс.
>>58434
Текстур не планируется. С удачно подобранными сплошными цветами выглядит ок, кстати.
Приведу пример проблемы. У меня есть пол. В нем - дыра, которую я хочу заделать блоком другого типа. Я знаю что размер этой дыры - целое_число на целое_число, конкретное число не знаю. Я беру блок 1х1, ставлю его в центр и начинаю вбивать значения "на глаз" в его scale свойства, чтобы растянуть его на дыру. 18 - слишком много. 11 - слишком мало. 13 - слишком мало. 15 - о, подошло, дыра была 15х15.
Гораздо удобней было бы взять scale gizmo и сразу растянуть блок как надо. Но поскольку scale gizmo работает с ебучими процентами, блок обязательно уедет на какое-нибудь 3.498, либо недоедет на 0.25, и это снова руками через свойства исправлять.
Или обратная проблема - у меня блок 8х1, я хочу уменьшить его длинную сторону. Но поскольку он уменьшается процентами, то единственное целое число, через которое я пройду - 4. А мне нужно было, например, 6.
Текстур не планируется. С удачно подобранными сплошными цветами выглядит ок, кстати.
Приведу пример проблемы. У меня есть пол. В нем - дыра, которую я хочу заделать блоком другого типа. Я знаю что размер этой дыры - целое_число на целое_число, конкретное число не знаю. Я беру блок 1х1, ставлю его в центр и начинаю вбивать значения "на глаз" в его scale свойства, чтобы растянуть его на дыру. 18 - слишком много. 11 - слишком мало. 13 - слишком мало. 15 - о, подошло, дыра была 15х15.
Гораздо удобней было бы взять scale gizmo и сразу растянуть блок как надо. Но поскольку scale gizmo работает с ебучими процентами, блок обязательно уедет на какое-нибудь 3.498, либо недоедет на 0.25, и это снова руками через свойства исправлять.
Или обратная проблема - у меня блок 8х1, я хочу уменьшить его длинную сторону. Но поскольку он уменьшается процентами, то единственное целое число, через которое я пройду - 4. А мне нужно было, например, 6.
>>58420
Мне бы такую прокрастинацию.
Добавь над машинками линию жизни. Посчитай сколько жизни они теряют от ударов.
Расстреливай их из установленным на твоей машине пистолетом, пулеметом, дробовиком, ракетницей. Плюс перки как в кармагедоне, тяжелый вес чтобы при ударе отлетали, или пружинка чтобы в зависимости от близости их с большей силой торпедировало в обратную от тебя сторону как из пращи.
>ПРОКРАСТИНАЦИЯ
Мне бы такую прокрастинацию.
Добавь над машинками линию жизни. Посчитай сколько жизни они теряют от ударов.
Расстреливай их из установленным на твоей машине пистолетом, пулеметом, дробовиком, ракетницей. Плюс перки как в кармагедоне, тяжелый вес чтобы при ударе отлетали, или пружинка чтобы в зависимости от близости их с большей силой торпедировало в обратную от тебя сторону как из пращи.
>>58463
Лучше бы подумал как мне решить проблему малой кровью, пока я тут плагин допиливаю.
Лучше бы подумал как мне решить проблему малой кровью, пока я тут плагин допиливаю.
105 Кб, 983x388>>58467
CSG Polygon положенный на бок. Позволяет мышкой перетаскивать вершины снэпом по сетке.
CSG Polygon положенный на бок. Позволяет мышкой перетаскивать вершины снэпом по сетке.
>>58469
Во-первых, не медленные. Медленные только рассчеты комбинирования, которых тут нет.
Во-вторых, элементарно конвертируются после того как закончишь прототипирование.
Хотя похоже ты просто разжигаешь.
Во-первых, не медленные. Медленные только рассчеты комбинирования, которых тут нет.
Во-вторых, элементарно конвертируются после того как закончишь прототипирование.
Хотя похоже ты просто разжигаешь.
>>58471
Я делаю что мне нужно, и параллельно с тобой беседу веду. И я сделаю что мне нужно. Чилл.
Я делаю что мне нужно, и параллельно с тобой беседу веду. И я сделаю что мне нужно. Чилл.
162 Кб, 365x441Набампайте пожалуйста до лимита, а я пока перекачу.
Фил фри ту предлагайте арт.
Фил фри ту предлагайте арт.
Короче внутри цикла технически невозможно добавлять инстансы одной сцены к текущей сцене. Выглядит как обсер разработчиков движка, благо обойти ситуацию легко. Просто присвоил по одной переменной на инстанс, и добавил их по очереди к ноде.
Так не работает:
Так не работает:
>draw_road_many(["road_straight", "road_straight", "road_straight"])
>func draw_road_many(paths: Array):
>var y = 0
>var z = 0
>for i in paths:
>var path = load("res://scenes/%s.tscn" % i).instantiate()
>y -= 1
>z += 100
>get_parent().add_child.call_deferred(path)
>path.position = Vector3(0, y, z)
>pass
>>58496
А, точно. То самый случай, когда works on my machine. Запакую в mp4 x264.
>Фаерфоксогоспода не смогут увидеть непожатый мкв
А, точно. То самый случай, когда works on my machine. Запакую в mp4 x264.
>>58501
Не ну прям с перепаковкой ебаться не надо, если у тебя OBS там в меню Файл - перепаковка (которая раньше демультиплексированием называлась).
> Запакую в mp4 x264.
Не ну прям с перепаковкой ебаться не надо, если у тебя OBS там в меню Файл - перепаковка (которая раньше демультиплексированием называлась).
>>58493
Звучит как то, что ты бездумно копипастишь строки кода откуда то, не понимая последовательности событий и что такое deferred
Звучит как то, что ты бездумно копипастишь строки кода откуда то, не понимая последовательности событий и что такое deferred
>>58568
В функции пробовал 3 способа добавлять чайлд ноду, и на момент когда я постил не закомментирован был get_parent().add_child.call_deferred(path). В актуальной версии используется просто get_child(path).
В функции пробовал 3 способа добавлять чайлд ноду, и на момент когда я постил не закомментирован был get_parent().add_child.call_deferred(path). В актуальной версии используется просто get_child(path).
334 Кб, 757x687Сап, посаны.
Поясните такую вещь, на каком языке лучше пилить штуки в годоте, чтобы потом можно было чиркануть в резюме, что ты молодец?
Или дроч шарпа в годоте никак не повлияет на конечный навык говнокодинга?
Поясните такую вещь, на каком языке лучше пилить штуки в годоте, чтобы потом можно было чиркануть в резюме, что ты молодец?
Или дроч шарпа в годоте никак не повлияет на конечный навык говнокодинга?
>>58643
Не привязывайся к инструментам. Выбери движок более подходящий для резюме, если для тебя это важно. Годот с гдскриптом хорош для многих вещей но не для резюме. Если ты новичок то шарп очень не рекомендуется.
Не привязывайся к инструментам. Выбери движок более подходящий для резюме, если для тебя это важно. Годот с гдскриптом хорош для многих вещей но не для резюме. Если ты новичок то шарп очень не рекомендуется.
>>58775
Если ты новичок то шарп в годоте очень не рекомендуется
самофикс
>Если ты новичок то шарп очень не рекомендуется.
Если ты новичок то шарп в годоте очень не рекомендуется
самофикс
>>58775
Если сможешь начать, сделать и закончить какой-то достаточно сложный проект, особенно если он будет популярным, тогда это даёт тебе жирный плюс вне зависимости от выбранных инструментов.
Вот только зачем тебе идти рабом к дяде, если ты и самостоятельно можешь начать, сделать и закончить достаточно сложный популярный проект? Ты только талант свой закопаешь, уйдя в рабство к дяде.
>Годот с гдскриптом хорош для многих вещей но не для резюме.
Если сможешь начать, сделать и закончить какой-то достаточно сложный проект, особенно если он будет популярным, тогда это даёт тебе жирный плюс вне зависимости от выбранных инструментов.
Вот только зачем тебе идти рабом к дяде, если ты и самостоятельно можешь начать, сделать и закончить достаточно сложный популярный проект? Ты только талант свой закопаешь, уйдя в рабство к дяде.
Есть тут кто-нибудь кто нвимом пользуется с годотом? У меня чёт автокомплит хуёво с сервером взаимодействует.
Если я продолжаю печатать слово, то варианты из автокомлита пропадают. Я начинают писать имя переменной, она появляется на первой строчке и если я после этого ещё символ напечатаю она пропадает. Самое отвратное, что если удалить символ то автокомплит другой почему-то предлагается и переменная не вылазит снова и приходится всё слово стирать.
Проверил автокомлит отдельно, работает нормально. В ридере и эдиторе годота, тоже всё нормально работает. Проблема только между нвимом и годотом.
Если я продолжаю печатать слово, то варианты из автокомлита пропадают. Я начинают писать имя переменной, она появляется на первой строчке и если я после этого ещё символ напечатаю она пропадает. Самое отвратное, что если удалить символ то автокомплит другой почему-то предлагается и переменная не вылазит снова и приходится всё слово стирать.
Проверил автокомлит отдельно, работает нормально. В ридере и эдиторе годота, тоже всё нормально работает. Проблема только между нвимом и годотом.
>>60226
Отписываюсь, может потом кому-нибудь поможет.
Глючит из-за этой строки в конфиге нвима:
completion = { completeopt = 'menu,menuone,noinsert' }
Пока разницы не вижу, что с ней что без неё.
Отписываюсь, может потом кому-нибудь поможет.
Глючит из-за этой строки в конфиге нвима:
completion = { completeopt = 'menu,menuone,noinsert' }
Пока разницы не вижу, что с ней что без неё.
Решил запилить неистовый твин-стик шутан, но щас задумался: а как заставить мышку быть нормальным стиком? Нужно чтобы в независимости от положения персонажа на экране, нужная амплитуда движения мышки для поворота была бы всегда одинаковой.
С камерой зафиксированной на персонаже все работает как надо, тк очевидно персонаж всегда в одной точке по центру. А вот если камеру отдалить/отключить/зафиксировать на чём-то другом – то приходится елозить мышкой по всему столу, как на втором видосе.
Щас поворот делается через обычный лук_ат
С камерой зафиксированной на персонаже все работает как надо, тк очевидно персонаж всегда в одной точке по центру. А вот если камеру отдалить/отключить/зафиксировать на чём-то другом – то приходится елозить мышкой по всему столу, как на втором видосе.
Щас поворот делается через обычный лук_ат
Наверное платина, но не могли бы пояснить за публикацию проектов? В интернетах пишут про какие-то перекомпиляции движка для дистрибуции через Стим и всякое такое. Это устаревшая инфа?
Сап, годотач, есть нарезанная моделька персонажа, надо сделать анимацию процедурную или рэгдольную, похожую на ту, что в баротравме, искал в документации, делал, но по итогу у меня нихуя не вышло, может у кого есть опыт чего-то подобного или совет?
Моя игра попала в хуавей стор, как прикрутить к ней монетизацию??
Объясните как Годот Фоундейшен зарабатывает деньги? Неужели всё на донатах только?
Also, посоветуйте ютуб каналы по годоту годные
Сап, годач. Такое дело - делаю ретрошутер в духе doom. Заметил, что есть статтеры, картинка очень дерганная, и плюс текстуры с nearest фильтром мерцают на экране. Код как в видео. Что может влиять на такое поведение, кто сталкивался?
Железо в норме, тянет всякие халфлайфы2, а в другое я не играю.
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://m.youtube.com/watch%3Fv%3DjzbgH4AMtI8&ved=2ahUKEwimqo2U3v6HAxWiJhAIHRxSDVAQwqsBegQIDxAG&usg=AOvVaw0yASfV3tq5Aej8cVXYDZsW
Железо в норме, тянет всякие халфлайфы2, а в другое я не играю.
https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://m.youtube.com/watch%3Fv%3DjzbgH4AMtI8&ved=2ahUKEwimqo2U3v6HAxWiJhAIHRxSDVAQwqsBegQIDxAG&usg=AOvVaw0yASfV3tq5Aej8cVXYDZsW
Использует ли кто нибудь C++ в Годот? Пишите только плагины или скрипты? Какие подводные и реально ли совмещая GDscript и C++ сделать проект?
116 Кб, 836x788>>54699 (OP)
Анон, можно как-нибудь включить сглаживание в редакторе, а то немного раздражает эта "пила" у линий?
Анон, можно как-нибудь включить сглаживание в редакторе, а то немного раздражает эта "пила" у линий?
>>72876
Нашел в настройках, включил FXMAA, большая часть "лесенок" исчезла, но края квадратов отрендеренных материалом все равно в лесенках.
Возвращаться в UE не хочется
Нашел в настройках, включил FXMAA, большая часть "лесенок" исчезла, но края квадратов отрендеренных материалом все равно в лесенках.
Возвращаться в UE не хочется
>>72876
В настройках проекта вкладка Сглаживание, выкручиваешь хоть MSAA хоть рендер в x2, хоть FSR2
Одновременно настройка и для игры и для редактора
В настройках проекта вкладка Сглаживание, выкручиваешь хоть MSAA хоть рендер в x2, хоть FSR2
Одновременно настройка и для игры и для редактора
>>57803
Я если честно вообще не понимаю нахрена разрабы годота создали еще один динамически типизированный язык. Ну поиграли с этим говном в 90-е, обосрались и хватит. Разработка на динамически типизированных языках уже везде мертва как концепт. Для жс придумали тайпскрипт, в пистон добавили и юзают типы, в пхп тоже есть типы.
Я если честно вообще не понимаю нахрена разрабы годота создали еще один динамически типизированный язык. Ну поиграли с этим говном в 90-е, обосрались и хватит. Разработка на динамически типизированных языках уже везде мертва как концепт. Для жс придумали тайпскрипт, в пистон добавили и юзают типы, в пхп тоже есть типы.
Сап! Я делаю арканоид как свой первый проект и у меня супер дебильная проблема: Я платформу сделал как CharacterBody2D и мяч как RigidBody2D... и когда мяч стукается об платформу, то платформа от удара сползает вниз чуток, как это исправить лол?
Говно Хрюлика
Sup двач
Знаю что не по теме, но как насчёт захейтить игру Юлика Хрюлика. Хрюлик возомнил себя мамкиным Кодзимой и решил засрать наш любимый Стим и оскорбил священный Godot. Мало того что игра говнище, так она ещё и стоит 3,5$.
https://store.steampowered.com/app/2883280/Dog_Brew/
Sup двач
Знаю что не по теме, но как насчёт захейтить игру Юлика Хрюлика. Хрюлик возомнил себя мамкиным Кодзимой и решил засрать наш любимый Стим и оскорбил священный Godot. Мало того что игра говнище, так она ещё и стоит 3,5$.
https://store.steampowered.com/app/2883280/Dog_Brew/
196 Кб, 695x368Лицо движка
Аноны, вы какую литературу читаете по гдскрипту? Хотел бы ротироваться с юнити, да только на юнити тех же книг как говна а на годот нет вообще. Посоветуйте с чего начать
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 7 ноября в 13:16.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 7 ноября в 13:16.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.