1,3 Мб, 1024x723Добро пожаловать в тред любви, взаимопомощи и var root_motion : Transform = anim_tree.get_root_motion_transform()
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
• Руководство по стилю: https://docs.godotengine.org/ru/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
• Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
• Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
• Новости движка: https://godotengine.org/news/
• FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
• Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
• Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
• Игры, созданные глобальными кириллами: https://steamdb.info/tech/Engine/Godot/ https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
• Изумительный Годот: https://github.com/Calinou/awesome-godot https://github.com/godotengine/awesome-godot - подборка дополнений, модулей и минишоукейc.
• Аддон для диалоговой системы: https://godotengine.org/asset-library/asset/833
• Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
• Библиотека готовых шейдеров: https://godotshaders.com
• Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
• SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
• HeightmapTerrain для рисования 3D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/231
• Конвертор кваковских карт для ностальгирующих дидов: https://godotengine.org/asset-library/asset/446
• Конвертер блендеровских моделей в формат сцен: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
• Конвертер блендеровских файлов прямо в движок: https://github.com/V-Sekai/godot-blender Надо только в настройках проекта путь к blender.exe указать. Потом просто закидываешь .blend в папку и импортируется.
• Godot Game Tools - GGT https://viniguerrero.itch.io/godot-game-tools
• Туториал по шейдерам: https://github.com/Volkovina/GLES-2.0-2D-Fragment-Shader-Tutorial-Series-in-Godot-Beginner-to-Advanced ГЛЕС2, да, но ты сначала БАЗУ выучи, ёпт!
Для любителей пощекотать конпеляцию
• Реализация ECS для Годота: https://github.com/GodotECS/godex
• Воксельные террейны от Зилана: https://github.com/Zylann/godot_voxel
• Поддержка различных языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
• Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
• В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
• Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Предыдущий: >>867751 (OP)
Архивный: >>852131 (OP)
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
• Руководство по стилю: https://docs.godotengine.org/ru/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
• Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
• Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
• Новости движка: https://godotengine.org/news/
• FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
• Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
• Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
• Игры, созданные глобальными кириллами: https://steamdb.info/tech/Engine/Godot/ https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
• Изумительный Годот: https://github.com/Calinou/awesome-godot https://github.com/godotengine/awesome-godot - подборка дополнений, модулей и минишоукейc.
• Аддон для диалоговой системы: https://godotengine.org/asset-library/asset/833
• Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
• Библиотека готовых шейдеров: https://godotshaders.com
• Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
• SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
• HeightmapTerrain для рисования 3D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/231
• Конвертор кваковских карт для ностальгирующих дидов: https://godotengine.org/asset-library/asset/446
• Конвертер блендеровских моделей в формат сцен: https://docs.godotengine.org/en/stable/getting_started/workflow/assets/escn_exporter/index.html
• Конвертер блендеровских файлов прямо в движок: https://github.com/V-Sekai/godot-blender Надо только в настройках проекта путь к blender.exe указать. Потом просто закидываешь .blend в папку и импортируется.
• Godot Game Tools - GGT https://viniguerrero.itch.io/godot-game-tools
• Туториал по шейдерам: https://github.com/Volkovina/GLES-2.0-2D-Fragment-Shader-Tutorial-Series-in-Godot-Beginner-to-Advanced ГЛЕС2, да, но ты сначала БАЗУ выучи, ёпт!
Для любителей пощекотать конпеляцию
• Реализация ECS для Годота: https://github.com/GodotECS/godex
• Воксельные террейны от Зилана: https://github.com/Zylann/godot_voxel
• Поддержка различных языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
• Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
• В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
• Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Предыдущий: >>867751 (OP)
Архивный: >>852131 (OP)
Смотрим видосы вместе с ОПом.
https://youtu.be/EmQBLxxPV3E
Переводим предпочитаемой нейросетью. У кого своя мясная на инглиш заточена, а у кого электронная из интернетов.
https://youtu.be/EmQBLxxPV3E
Переводим предпочитаемой нейросетью. У кого своя мясная на инглиш заточена, а у кого электронная из интернетов.
>>873237
Похоже, ты только один язык знаешь, поэтому поясню лично для тебя: когда человек изучает второй язык, ему больше не нужно переводить с этого второго языка на свой родной. Твоё восприятие перестраивается и ты начинаешь понимать текст и речь на другом языке точно так же, как на родном, без перевода с языка на язык. Если ещё и говорить на втором языке научишься, то точно так же просто говоришь на втором языке, а не переводишь с родного на чужой. Второй язык врастает в тебя настолько, что ты можешь размышлять на этом втором языке, ведя внутренний диалог на нём без перевода на родной. В это тяжело поверить, когда ты ни одного языка кроме родного не знаешь, но на практике для такого уровня освоения не нужно даже обладать богатым набором слов; я по-прежнему вынужден иногда обращаться к словарю с некоторыми незнакомыми словами и путаюсь при построении предложений, но в пределах знакомых слов всё ощущается почти так же естественно, как родной русский. Переводчики, кстати, так и переводят - сначала они понимают суть сказанного на одном языке, как если бы это была родная для них речь, а потом выражают это своими словами на другом языке, опять же как если бы это был родной язык. Поэтому автоматические переводчики дико фейлились до прихода алгоритмов, способных отделить суть текста от конкретных слов и языковых правил, а затем описать эту суть словами и правилами другого языка - ранние переводчики переводили текст дословно без понимания сути и поэтому результат был очень далёк от желаемого, суть текста легко терялась.
Алсо, сегодня как нельзя проще изучить новый язык благодаря этим нейросетевым чатботам, т.к. они знают язык лучше онлайн-переводчиков и могут выполнять роль учителя языка. Пусть у них большая проблема с памятью и ограниченным контекстом, но изображать общение с носителем языка у них получается вполне достойно, так что как минимум тренировать текстовое общение на чужом для тебя языке с ними можно. Главное не воспринимать слишком буквально, они часто бред выдумывают, даже если формально всё правильно написано.
Прости за оффтоп, но ты триггернул меня.
получал "3" за присутствие на английском в школе, полностью забив на него, изучил язык по играм и руководствам к различным техническим штукам
>Переводим предпочитаемой нейросетью
>мясная на инглиш заточена
Похоже, ты только один язык знаешь, поэтому поясню лично для тебя: когда человек изучает второй язык, ему больше не нужно переводить с этого второго языка на свой родной. Твоё восприятие перестраивается и ты начинаешь понимать текст и речь на другом языке точно так же, как на родном, без перевода с языка на язык. Если ещё и говорить на втором языке научишься, то точно так же просто говоришь на втором языке, а не переводишь с родного на чужой. Второй язык врастает в тебя настолько, что ты можешь размышлять на этом втором языке, ведя внутренний диалог на нём без перевода на родной. В это тяжело поверить, когда ты ни одного языка кроме родного не знаешь, но на практике для такого уровня освоения не нужно даже обладать богатым набором слов; я по-прежнему вынужден иногда обращаться к словарю с некоторыми незнакомыми словами и путаюсь при построении предложений, но в пределах знакомых слов всё ощущается почти так же естественно, как родной русский. Переводчики, кстати, так и переводят - сначала они понимают суть сказанного на одном языке, как если бы это была родная для них речь, а потом выражают это своими словами на другом языке, опять же как если бы это был родной язык. Поэтому автоматические переводчики дико фейлились до прихода алгоритмов, способных отделить суть текста от конкретных слов и языковых правил, а затем описать эту суть словами и правилами другого языка - ранние переводчики переводили текст дословно без понимания сути и поэтому результат был очень далёк от желаемого, суть текста легко терялась.
Алсо, сегодня как нельзя проще изучить новый язык благодаря этим нейросетевым чатботам, т.к. они знают язык лучше онлайн-переводчиков и могут выполнять роль учителя языка. Пусть у них большая проблема с памятью и ограниченным контекстом, но изображать общение с носителем языка у них получается вполне достойно, так что как минимум тренировать текстовое общение на чужом для тебя языке с ними можно. Главное не воспринимать слишком буквально, они часто бред выдумывают, даже если формально всё правильно написано.
Прости за оффтоп, но ты триггернул меня.
получал "3" за присутствие на английском в школе, полностью забив на него, изучил язык по играм и руководствам к различным техническим штукам
>>873237
Похоже, ты только один язык знаешь, поэтому поясню лично для тебя: когда человек изучает второй язык, ему больше не нужно переводить с этого второго языка на свой родной. Твоё восприятие перестраивается и ты начинаешь понимать текст и речь на другом языке точно так же, как на родном, без перевода с языка на язык. Если ещё и говорить на втором языке научишься, то точно так же просто говоришь на втором языке, а не переводишь с родного на чужой. Второй язык врастает в тебя настолько, что ты можешь размышлять на этом втором языке, ведя внутренний диалог на нём без перевода на родной. В это тяжело поверить, когда ты ни одного языка кроме родного не знаешь, но на практике для такого уровня освоения не нужно даже обладать богатым набором слов; я по-прежнему вынужден иногда обращаться к словарю с некоторыми незнакомыми словами и путаюсь при построении предложений, но в пределах знакомых слов всё ощущается почти так же естественно, как родной русский. Переводчики, кстати, так и переводят - сначала они понимают суть сказанного на одном языке, как если бы это была родная для них речь, а потом выражают это своими словами на другом языке, опять же как если бы это был родной язык. Поэтому автоматические переводчики дико фейлились до прихода алгоритмов, способных отделить суть текста от конкретных слов и языковых правил, а затем описать эту суть словами и правилами другого языка - ранние переводчики переводили текст дословно без понимания сути и поэтому результат был очень далёк от желаемого, суть текста легко терялась.
Алсо, сегодня как нельзя проще изучить новый язык благодаря этим нейросетевым чатботам, т.к. они знают язык лучше онлайн-переводчиков и могут выполнять роль учителя языка. Пусть у них большая проблема с памятью и ограниченным контекстом, но изображать общение с носителем языка у них получается вполне достойно, так что как минимум тренировать текстовое общение на чужом для тебя языке с ними можно. Главное не воспринимать слишком буквально, они часто бред выдумывают, даже если формально всё правильно написано.
Прости за оффтоп, но ты триггернул меня.
получал "3" за присутствие на английском в школе, полностью забив на него, изучил язык по играм и руководствам к различным техническим штукам
>Переводим предпочитаемой нейросетью
>мясная на инглиш заточена
Похоже, ты только один язык знаешь, поэтому поясню лично для тебя: когда человек изучает второй язык, ему больше не нужно переводить с этого второго языка на свой родной. Твоё восприятие перестраивается и ты начинаешь понимать текст и речь на другом языке точно так же, как на родном, без перевода с языка на язык. Если ещё и говорить на втором языке научишься, то точно так же просто говоришь на втором языке, а не переводишь с родного на чужой. Второй язык врастает в тебя настолько, что ты можешь размышлять на этом втором языке, ведя внутренний диалог на нём без перевода на родной. В это тяжело поверить, когда ты ни одного языка кроме родного не знаешь, но на практике для такого уровня освоения не нужно даже обладать богатым набором слов; я по-прежнему вынужден иногда обращаться к словарю с некоторыми незнакомыми словами и путаюсь при построении предложений, но в пределах знакомых слов всё ощущается почти так же естественно, как родной русский. Переводчики, кстати, так и переводят - сначала они понимают суть сказанного на одном языке, как если бы это была родная для них речь, а потом выражают это своими словами на другом языке, опять же как если бы это был родной язык. Поэтому автоматические переводчики дико фейлились до прихода алгоритмов, способных отделить суть текста от конкретных слов и языковых правил, а затем описать эту суть словами и правилами другого языка - ранние переводчики переводили текст дословно без понимания сути и поэтому результат был очень далёк от желаемого, суть текста легко терялась.
Алсо, сегодня как нельзя проще изучить новый язык благодаря этим нейросетевым чатботам, т.к. они знают язык лучше онлайн-переводчиков и могут выполнять роль учителя языка. Пусть у них большая проблема с памятью и ограниченным контекстом, но изображать общение с носителем языка у них получается вполне достойно, так что как минимум тренировать текстовое общение на чужом для тебя языке с ними можно. Главное не воспринимать слишком буквально, они часто бред выдумывают, даже если формально всё правильно написано.
Прости за оффтоп, но ты триггернул меня.
получал "3" за присутствие на английском в школе, полностью забив на него, изучил язык по играм и руководствам к различным техническим штукам
899 Кб, 506x900>>873349
Игра твоя где, америкос?
Игра твоя где, америкос?
>>873349
Сильно зависит от контента, видос ОПа я понимаю спокойно, но вот например в сериалах/фильмах все говорят как уебаны дегроды и нихуя не понятно вообще.
>Твоё восприятие перестраивается и ты начинаешь понимать текст и речь на другом языке точно так же, как на родном
Сильно зависит от контента, видос ОПа я понимаю спокойно, но вот например в сериалах/фильмах все говорят как уебаны дегроды и нихуя не понятно вообще.
>>873349
Ты что такой душный? Очевидно же, ОП выразился так, потому что прикольная аналогия, типа нейронка цифровая, нейронка мясная, йоу. Просто фигура речи же. Ты б ещё приебался к тому, что мясная нейронка вообще-то не состоит из мышечной ткани, а значит не может называться мясной.
Ты что такой душный? Очевидно же, ОП выразился так, потому что прикольная аналогия, типа нейронка цифровая, нейронка мясная, йоу. Просто фигура речи же. Ты б ещё приебался к тому, что мясная нейронка вообще-то не состоит из мышечной ткани, а значит не может называться мясной.
>>873349
Тебе в /psy или где тут психологическую помощь оказывают.
Тебе в /psy или где тут психологическую помощь оказывают.
>>873482
репортнул
репортнул
>>873498
написал движкосрач, оскорбление.
написал движкосрач, оскорбление.
Конференция, годаны!
https://youtu.be/vdAwlI6NG0I
https://youtu.be/vdAwlI6NG0I
Смотрим выступление Хуана с Анонимусом:
https://youtu.be/XduuHNOGGqI
https://youtu.be/XduuHNOGGqI
>>873506
возвращайся в загон, и называй себя там как хочешь. Здесь твой тупой форс не пройдет.
возвращайся в загон, и называй себя там как хочешь. Здесь твой тупой форс не пройдет.
675 Кб, 1280x720О, пора обновиться.
Редактор полигонов сейчас конечно не очень, каждый фейс вручную прокликивать надо. Для сравнения фейс Димасика в бленделе анимировал, в годоте бы задолбался такой меш воссоздать.
>>873665
Они взяли курс на нативную интеграцию с блендером и другими опенсорцами в открытую экосистему. Такшта забей на встроенный %редакторнейм%, просто укажи путь к блендеру в настройках большого редактора и юзай бленд-файлы как сцены. Речь о четвёрке.
Они взяли курс на нативную интеграцию с блендером и другими опенсорцами в открытую экосистему. Такшта забей на встроенный %редакторнейм%, просто укажи путь к блендеру в настройках большого редактора и юзай бленд-файлы как сцены. Речь о четвёрке.
>>873665
Игры, бл, делай.
Игры, бл, делай.
621 Кб, webm,1280x720, 0:03
>>873503
Чекнул игры с видоса, вообще ноль прироста по графикам, какая же залупа этот GDC.
Чекнул игры с видоса, вообще ноль прироста по графикам, какая же залупа этот GDC.
>>873700
В смысле в по графикам стима, пользователи не прибавились, вот что я имел в виду.
>ноль прироста по графикам,
В смысле в по графикам стима, пользователи не прибавились, вот что я имел в виду.
>>873709
Практика говорит об обратном. Бывают полностью нулевые игры, которые собирают миллионы, потому что в них вбухана куча рекалмы. Бывают норм игры, которые собирают десяток отзывов.
Практика говорит об обратном. Бывают полностью нулевые игры, которые собирают миллионы, потому что в них вбухана куча рекалмы. Бывают норм игры, которые собирают десяток отзывов.
>>873722
Ты в этого бегущего гиганта пробовал играть сам или чисто по пикчам ощущаешь, что игра нулёвая?
Ты в этого бегущего гиганта пробовал играть сам или чисто по пикчам ощущаешь, что игра нулёвая?
>>873723
Да это вообще не игра. Как и прочие подобные. Там еще была игра где ты просто нажимаешь 1 кнопку и тебе показывают как будто ты выиграл баксы.
Да это вообще не игра. Как и прочие подобные. Там еще была игра где ты просто нажимаешь 1 кнопку и тебе показывают как будто ты выиграл баксы.
Ждем 4.1
>>873753
Нахуя тебе гайды именно по 4-ке? Что с тобой не так? Я могу открыть гайд со знаменитого сайта про гейм-паттерны и прямо оттуда хуярить код в годот, на лету переводя из сиобразного псевдокода в гдскрипт. Почему ты так не можешь? Почему тебе требуется, чтобы тебе всё разжёвывали по 300 раз?
Нахуя тебе гайды именно по 4-ке? Что с тобой не так? Я могу открыть гайд со знаменитого сайта про гейм-паттерны и прямо оттуда хуярить код в годот, на лету переводя из сиобразного псевдокода в гдскрипт. Почему ты так не можешь? Почему тебе требуется, чтобы тебе всё разжёвывали по 300 раз?
>>873792
Спасибо.
Спасибо.
https://youtu.be/dMYv6InQgno
Пиздец. пытаюсь вкуривать вот этот туториал, но ощущение, что просто повторяю, как макака. Есть что-то более упрощенное? Этот кажется слишком перегруженным для небольшого проекта
Пиздец. пытаюсь вкуривать вот этот туториал, но ощущение, что просто повторяю, как макака. Есть что-то более упрощенное? Этот кажется слишком перегруженным для небольшого проекта
>>873871
От пети сканера туториалы глянь. Заодно и по русски будет.
https://www.youtube.com/watch?v=ypqD5X0Nv78
> Есть что-то более упрощенное?
От пети сканера туториалы глянь. Заодно и по русски будет.
https://www.youtube.com/watch?v=ypqD5X0Nv78
Годаны, как найти это место?
Через поиск по файлам пытаюсь найти - нету. Я тот сигнал уже отовсюду выпилил, а он всё равно вызывается как-то где-то. Как найти, где именно? Раздражает ошибка.
>emit_signal: Error calling method from signal 'my_signal': 'Node(foo.gd)::bar': Method not found..
Через поиск по файлам пытаюсь найти - нету. Я тот сигнал уже отовсюду выпилил, а он всё равно вызывается как-то где-то. Как найти, где именно? Раздражает ошибка.
>>873982
Ну как обычно, стоило спросить, ответ нашёлся.
Открыл подозреваемую сцену, и там мне ошибка жёлтым показывает, какая именно нода её вызывает. Оказывается, то был не мой сигнал, а встроенный с таким же именем.
Ну как обычно, стоило спросить, ответ нашёлся.
Открыл подозреваемую сцену, и там мне ошибка жёлтым показывает, какая именно нода её вызывает. Оказывается, то был не мой сигнал, а встроенный с таким же именем.
>>874051
Именно так, Шерлок! В скрипте foo и с коллбэком bar.
Именно так, Шерлок! В скрипте foo и с коллбэком bar.
Ну чо там, когда стабильная версия четвёрки?
Мне развитие строгой типизации очень нравится, хотя и 3.5 достаточно
Мне развитие строгой типизации очень нравится, хотя и 3.5 достаточно
>>874106
Godot 4.0.2
Godot 4.0.2
>>874148
Да ты прям как математик посчитавший овец в анекдоте.
Я в блендере и сам сейчас с ними работаю, только результат то экспортируется одним куском.
А тут можно:
- если будет рантайм поддержка, процедурно генерировать на лету.
- можно прикрутить оптимизацию мультимешем. Например если у тебя домики расставляются, или подоконники на них, ит.д.
Да ты прям как математик посчитавший овец в анекдоте.
Я в блендере и сам сейчас с ними работаю, только результат то экспортируется одним куском.
А тут можно:
- если будет рантайм поддержка, процедурно генерировать на лету.
- можно прикрутить оптимизацию мультимешем. Например если у тебя домики расставляются, или подоконники на них, ит.д.
>>874158
Мне нужна, я сам собирался делать, а сейчас увидел что он делает и ему помогают. То есть уже минимум 3 людям нужна. Чини свою логику, в общем.
Мне нужна, я сам собирался делать, а сейчас увидел что он делает и ему помогают. То есть уже минимум 3 людям нужна. Чини свою логику, в общем.
Скоро, террейн для 4ки
https://youtube.com/watch?v=wdWIKuQ9b14
https://youtube.com/watch?v=wdWIKuQ9b14
2,8 Мб, 1188x795Опа как то этот проектик не заметил
https://github.com/fernandolv33/lowpoly-chmaker
https://github.com/fernandolv33/lowpoly-chmaker
1,6 Мб, 1920x1039>>874600
Хорошо, конечно. А там будут:
1. Геологическое моделирование
1.1. Ветряная эррозия
1.2. Жидкостные эррозии
1.2.1. Водные
1.2.2. Лавовые
1.3. Слои породы
1.4. Заполнение чанка водой с формированием озёр и рек, стекающих к уровню океана.
1.4.1. "Пляжная" эррозия - формирование пляжей на основе карты воды, созданной в 1.4.
2. Булевы операции.
3. Эквалайзеры.
4. Корорайзеры.
5. Формирование карт-масок с выходными данными на каждом этапе.
5.1. Сплатмапы заполнения поверхностей.
Если будет всё это бесплатно-опенсорсно, это будет просто охуенчик. И тогда останется один вопрос:
6. А там будет процедурная состыковка сгенерированного террейна между чанками (тайлами)? Бесплатно?
Хорошо, конечно. А там будут:
1. Геологическое моделирование
1.1. Ветряная эррозия
1.2. Жидкостные эррозии
1.2.1. Водные
1.2.2. Лавовые
1.3. Слои породы
1.4. Заполнение чанка водой с формированием озёр и рек, стекающих к уровню океана.
1.4.1. "Пляжная" эррозия - формирование пляжей на основе карты воды, созданной в 1.4.
2. Булевы операции.
3. Эквалайзеры.
4. Корорайзеры.
5. Формирование карт-масок с выходными данными на каждом этапе.
5.1. Сплатмапы заполнения поверхностей.
Если будет всё это бесплатно-опенсорсно, это будет просто охуенчик. И тогда останется один вопрос:
6. А там будет процедурная состыковка сгенерированного террейна между чанками (тайлами)? Бесплатно?
>>874643
Не знаю пока, возможно и будет. Но вообще на многое из этого я видел алгоритмы и код, так что даже если есть только хейтмап, это все реализуемо.
Не знаю пока, возможно и будет. Но вообще на многое из этого я видел алгоритмы и код, так что даже если есть только хейтмап, это все реализуемо.
>>873235 (OP)
Хочу вкатить после юньки, на сколько разница большая в интерфейсах и скриптах?
На 2д платформер по времени +- сколько уйдёт чтоб разобраться в архитектуре и тому как что лучше делать?
Доки, примеры, так же всё в гугле пишется и без гемора находится?
Хочу вкатить после юньки, на сколько разница большая в интерфейсах и скриптах?
На 2д платформер по времени +- сколько уйдёт чтоб разобраться в архитектуре и тому как что лучше делать?
Доки, примеры, так же всё в гугле пишется и без гемора находится?
>>874651
В зависимости от твоего расположения на кривой гауссового распределения функции Даннинга-Крюгера, разница может быть как кардинальной так и незначительной.
Если попроще, то в обоих движках есть майнлуп с коллбэками, векторы есть, линейная алгебра реализована, в этом совпадает. Но по организации объектной системы, в юнити используется композитный подход (есть только один объект и куча компонентов к нему), а в годо используется наследуемый подход (есть много объектов, наследующихся от главного объекта, выполняющих свои задачи). Однако композитный подход не запрещен.
Рабочий день.
Всё есть. Всё как в шапке написано.
> на сколько разница большая в интерфейсах и скриптах?
В зависимости от твоего расположения на кривой гауссового распределения функции Даннинга-Крюгера, разница может быть как кардинальной так и незначительной.
Если попроще, то в обоих движках есть майнлуп с коллбэками, векторы есть, линейная алгебра реализована, в этом совпадает. Но по организации объектной системы, в юнити используется композитный подход (есть только один объект и куча компонентов к нему), а в годо используется наследуемый подход (есть много объектов, наследующихся от главного объекта, выполняющих свои задачи). Однако композитный подход не запрещен.
> На 2д платформер по времени +- сколько уйдёт чтоб разобраться в архитектуре и тому как что лучше делать?
Рабочий день.
> Доки, примеры, так же всё в гугле пишется и без гемора находится?
Всё есть. Всё как в шапке написано.
>>874650
год-полтора, если сравнивать сколько шла разработка аналогичных в 3-ке.
год-полтора, если сравнивать сколько шла разработка аналогичных в 3-ке.
>>874600
ебать видос пропердывается. вроде у автора 60 фпс, а запись лагает пизда, че за хуйня, че за инвалид там это реализовывает, походу после него еще тонную фиксанов нужно будет делать
ебать видос пропердывается. вроде у автора 60 фпс, а запись лагает пизда, че за хуйня, че за инвалид там это реализовывает, походу после него еще тонную фиксанов нужно будет делать
>>874770
Очевидно, Годо человек осилил, а вот видео-кодировщик не осилил.
Очевидно, Годо человек осилил, а вот видео-кодировщик не осилил.
>>873235 (OP)
А вот и не угадали. Я сейчас пилю экспорт в веб (то что в 4-ке называется Compability render), а там же старый добрый OpenGL, и что ты думаешь, пришлось стряхивать пыль с аддона. Благо что годот сам сконвертировал .tscn и .gd и все само заработало (я для этого создаю новый проект в 3-ке, кидаю в него то что хочу сконвертировать и открываю 4-кой)
>Прекомпилер шейдеров: https://godotengine.org/asset-library/asset/977 С версии 3.5 больше не нужен.
А вот и не угадали. Я сейчас пилю экспорт в веб (то что в 4-ке называется Compability render), а там же старый добрый OpenGL, и что ты думаешь, пришлось стряхивать пыль с аддона. Благо что годот сам сконвертировал .tscn и .gd и все само заработало (я для этого создаю новый проект в 3-ке, кидаю в него то что хочу сконвертировать и открываю 4-кой)
>>874773
Compatibility*
Compatibility*
>>874770
В настоящий момент именно тормозит, поскольку ждет реализации определенной фичи в самом годоте - какминиму частичную перерисовку текстур. https://github.com/godotengine/godot-proposals/issues/6121#issuecomment-1496340232
В настоящий момент именно тормозит, поскольку ждет реализации определенной фичи в самом годоте - какминиму частичную перерисовку текстур. https://github.com/godotengine/godot-proposals/issues/6121#issuecomment-1496340232
Алсо не уверен что именно его аддон будет опенсорсным - для 3 он распространяет кастомный билд годота, но сорцы модуля и шаблон экспорта - платные. Посмотрим, как поступит с этим.
>>874773
А вот это достойно пойти в шапку! Схоронил!
> создаю новый проект в 3-ке, кидаю в него то что хочу сконвертировать и открываю 4-кой
А вот это достойно пойти в шапку! Схоронил!
>>874792
На самом деле можно это делать из командной строки но как то лень обычно
https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html#using-the-command-line
Алсо это не серебряная пуля, оно не все конвертирует, чем меньше и проще проект, тем выше шансы. По ссылке так же написано как фиксить некоторые вещи которые сами не сконвертились.
На самом деле можно это делать из командной строки но как то лень обычно
https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html#using-the-command-line
Алсо это не серебряная пуля, оно не все конвертирует, чем меньше и проще проект, тем выше шансы. По ссылке так же написано как фиксить некоторые вещи которые сами не сконвертились.
>>873235 (OP)
Не подскажите, как можно подключить шейдер через код, а не через редактор?
Не подскажите, как можно подключить шейдер через код, а не через редактор?
>>874872
у объекта есть материал, material_override, set_surface_material или что нить подобное, ему присваиваешь загруженный шейдер.
Примерно так
var shader_material = ShaderMaterial.new()
shader_material.shader = load("...shader")
mesh_instance.material_override = shader_material
либо
var surface_index := 0
mesh_instance.mesh.surface_set_material(surface_index, shader_material)
у объекта есть материал, material_override, set_surface_material или что нить подобное, ему присваиваешь загруженный шейдер.
Примерно так
var shader_material = ShaderMaterial.new()
shader_material.shader = load("...shader")
mesh_instance.material_override = shader_material
либо
var surface_index := 0
mesh_instance.mesh.surface_set_material(surface_index, shader_material)
>>874885
Большое спасибо!
Большое спасибо!
>>874870
Есть, не пробовал, есть некоторые сомнения насчет них. Видел что есть подключение к openAI, но там платные запросы к API, и во вторых, chatgpt 3 учился на старых материалах, он вряд ли напишет под годот 4, а что умеет гуглить chatgpt 4 я хз.
Есть, не пробовал, есть некоторые сомнения насчет них. Видел что есть подключение к openAI, но там платные запросы к API, и во вторых, chatgpt 3 учился на старых материалах, он вряд ли напишет под годот 4, а что умеет гуглить chatgpt 4 я хз.
Годаны!
В шапке стало слишком много ссылок. Что делать будем? Я тут погуглил, есть сервисы хранения ссылок. С одним из таких сервисов шапка будет выглядеть как-то так:
Добро пожаловать в тред любви, взаимопомощи и ...!
Шапка: https://hipolink.me/godothread
Предыдущий:
Архивный:
Норм? Ништяк? Да? Не?
В шапке стало слишком много ссылок. Что делать будем? Я тут погуглил, есть сервисы хранения ссылок. С одним из таких сервисов шапка будет выглядеть как-то так:
Добро пожаловать в тред любви, взаимопомощи и ...!
Шапка: https://hipolink.me/godothread
Предыдущий:
Архивный:
Норм? Ништяк? Да? Не?
>>874896
Да
Да
>>873235 (OP)
Можно как-нибудь отключить управление мышью в itemlist?
Можно как-нибудь отключить управление мышью в itemlist?
>>875094
Спасибо
Спасибо
анонасы, а я смогу на данном движке сделать большой не рандомизированный 2D мир (вид сверху) без пролагов?
может кто видел уже готовый ассет? пока думаю делать разделение мира на квадраты, где ближайшие к игроку будут подгружаться
может кто видел уже готовый ассет? пока думаю делать разделение мира на квадраты, где ближайшие к игроку будут подгружаться
>>875148
Ты не сможешь
>анонасы, а я смогу на данном движке сделать большой не рандомизированный 2D мир
Ты не сможешь
>>875148
Ты на реализацию чарков потратишь много времени, готовых решений нет, есть отдельные куски демок и видео от васянов зарубежных, где это реализовано. Если готов потратить месяцок на чанки, то милости прошу, пробуй.
Ты на реализацию чарков потратишь много времени, готовых решений нет, есть отдельные куски демок и видео от васянов зарубежных, где это реализовано. Если готов потратить месяцок на чанки, то милости прошу, пробуй.
>>875156
В 2д? Минут 15 на прикручивание массива к zone loader?
>Ты на реализацию чарков потратишь много времени
В 2д? Минут 15 на прикручивание массива к zone loader?
>>875158
Пока ходил наливать чай, уже придумал решение на 10 минут для новичка. Называем сцены Chunk1c1, по периметру расставляем Area которые загружают сцены ChunkXcY, где X к примеру текущий + 2. Текущий получать в скрипте распарсив имя сцены.
Можно сделать 1 сцену-префаб и рисовать потом все на основе этой.
Пока ходил наливать чай, уже придумал решение на 10 минут для новичка. Называем сцены Chunk1c1, по периметру расставляем Area которые загружают сцены ChunkXcY, где X к примеру текущий + 2. Текущий получать в скрипте распарсив имя сцены.
Можно сделать 1 сцену-префаб и рисовать потом все на основе этой.
>>874896
Ля какая красота!
Не сижу на годоте, просто захаживаю почитать тред, а тут такое!
Расскажи сложно и бесплатно замутить такую страничку? С радостью бы сделал такие шапки для пары тредов. И почему раньше до этого никто не додумался?
Ля какая красота!
Не сижу на годоте, просто захаживаю почитать тред, а тут такое!
Расскажи сложно и бесплатно замутить такую страничку? С радостью бы сделал такие шапки для пары тредов. И почему раньше до этого никто не додумался?
>>875162
Просто перейди там по основному адресу. Всё бесплатно, без смс, но с регистрацией, без этого никуда. Иначе как ты будешь изменения изменять на своей странице.
> Расскажи сложно и бесплатно замутить такую страничку?
Просто перейди там по основному адресу. Всё бесплатно, без смс, но с регистрацией, без этого никуда. Иначе как ты будешь изменения изменять на своей странице.
1,2 Мб, 1500x993Нормально ли синхронизировать проекты между компьютерами с помощью обычного бэкапа на внешний жесткий диск? Просто у меня после такой "синхронизации" почему-то годот не увидел добавленные папки и сцены, пришлось заново импортировать проект. Но воспроизвести этот "баг" мне не удалось, во второй раз годот все увидел.
>>875178
а не проще все в облаке держать?
гугл дает 15 гб
яндекс 10 гб
+ для мелочевки дропбокс юзаю, там 2 гб всего
На все хватает пока что
а не проще все в облаке держать?
гугл дает 15 гб
яндекс 10 гб
+ для мелочевки дропбокс юзаю, там 2 гб всего
На все хватает пока что
>>875192
с такими играми он спокойно купит подписку на облако
с такими играми он спокойно купит подписку на облако
>>875190
Да я раньше, когда на юнити сидел, на Гугл проекты бэкапил. Потом гугл изменил программу синхронизации, что то там перенастраивать надо было. И я подумал, надо на своих дисках все держать, потому что сторонний сервис может внезапно прикрыть лавочку. Наверно вернусь к гугл диску.
Но меня все равно буспокоит, что это за баг у меня вылез. И не могу ли я похерить проект, тупо копируя все новые файлы с одного компа на другой? Может там какие-то служебные файлы копировать не надо.
Да я раньше, когда на юнити сидел, на Гугл проекты бэкапил. Потом гугл изменил программу синхронизации, что то там перенастраивать надо было. И я подумал, надо на своих дисках все держать, потому что сторонний сервис может внезапно прикрыть лавочку. Наверно вернусь к гугл диску.
Но меня все равно буспокоит, что это за баг у меня вылез. И не могу ли я похерить проект, тупо копируя все новые файлы с одного компа на другой? Может там какие-то служебные файлы копировать не надо.
>>875208
Надо смотреть в сторону Syncthing + rclone или подобных вариантов. Т.е. опен сорсная прога делает бэкапы в любые доступные облака, причем с возможностью шифрования, чтобы твои ценные ассеты не утащили.
Надо смотреть в сторону Syncthing + rclone или подобных вариантов. Т.е. опен сорсная прога делает бэкапы в любые доступные облака, причем с возможностью шифрования, чтобы твои ценные ассеты не утащили.
Годноту нашёл:
https://youtu.be/G_seJ2Yg1GA
https://youtu.be/G_seJ2Yg1GA
>>875384
Видно, что чувак шарит.
Видно, что чувак шарит.
Подскажите с вьюпорт текстурами - Делаю по гайду (https://www.youtube.com/watch?v=Xq0wgrCmnyw) с поправками на гд4.
Импортнул из блендера модель, хочу к материалу прицепить текстуру. Добавил SubViewport, в него канвас лейер с лейблом и цветным прямоугольником. Цепляю этот вьюпорт к вьюпорттекстуре нужного материала - он встает непонятно как и криво, а у челика из видео сразу как надо и заебись.
Что я не так делаб?
Импортнул из блендера модель, хочу к материалу прицепить текстуру. Добавил SubViewport, в него канвас лейер с лейблом и цветным прямоугольником. Цепляю этот вьюпорт к вьюпорттекстуре нужного материала - он встает непонятно как и криво, а у челика из видео сразу как надо и заебись.
Что я не так делаб?
167 Кб, 582x496>>875554
Просто квадратик в развертке был.
Кароч еще раз анврап сделал в блендере и заработало всё ок. Хз что это было
Просто квадратик в развертке был.
Кароч еще раз анврап сделал в блендере и заработало всё ок. Хз что это было
277 Кб, 957x678>>875378
Требует напильника, т.к. ноги могут не заметить пол, и паук продолжает ползать по сфере, и наоборот, может пройти по полу сквозь сферу. Пока не знаю как исправить
Требует напильника, т.к. ноги могут не заметить пол, и паук продолжает ползать по сфере, и наоборот, может пройти по полу сквозь сферу. Пока не знаю как исправить
114 Кб, 941x858Возможно ли отрисовать на плоскости такую же сетку, как рисует годот в редакторе. Простейший вариант с шейдером дает некрасивые результаты, линия становится прерывистой.
>>875646
Тут как то рисуют, правда там канвас шейдер - то есть 2д по плоскости?
https://godotshaders.com/?s=GRID
Тут как то рисуют, правда там канвас шейдер - то есть 2д по плоскости?
https://godotshaders.com/?s=GRID
>>875647
Да, там на плоскости рисуется перспектива. Но попробую посмотреть разобраться, может что-то там есть полезные техники.
Да, там на плоскости рисуется перспектива. Но попробую посмотреть разобраться, может что-то там есть полезные техники.
14 Кб, 520x592>>875646
Можешь попробовать рисовать при помощи MultiMeshInstance, я такую делаю при помощи него
Суть - создаёшь прямоугольник или даже параллелепипед, находишь его центр, находишь центр меду двумя крайними точками поверхности, затем туда перемещаешь его при помощи
multimesh.set_instance_transform_2d( _index, _transfo )
Затем растягиваешь на расстояние, равное половине расстояния между точками
Потом закрашиваешь
Непонятно как поддерживает сглаживание, у меня не получилось его врубить
Второй вариант есть Line2d, просто создаешь отдельные линии между двух точек и всё, поддерживает сглаживание
Можешь попробовать рисовать при помощи MultiMeshInstance, я такую делаю при помощи него
Суть - создаёшь прямоугольник или даже параллелепипед, находишь его центр, находишь центр меду двумя крайними точками поверхности, затем туда перемещаешь его при помощи
multimesh.set_instance_transform_2d( _index, _transfo )
Затем растягиваешь на расстояние, равное половине расстояния между точками
Потом закрашиваешь
Непонятно как поддерживает сглаживание, у меня не получилось его врубить
Второй вариант есть Line2d, просто создаешь отдельные линии между двух точек и всё, поддерживает сглаживание
60 Кб, 686x385Какой правильный подход к показу меню (с выезжанием) по нажатию на кнопку?
По нажатию на кнопку у меня меняется флаг.
А анимация происходит за счет постоянной проверки в _process(delta) значения и изменение флага.
Это же тупо. Есть другой подход?
По нажатию на кнопку у меня меняется флаг.
А анимация происходит за счет постоянной проверки в _process(delta) значения и изменение флага.
Это же тупо. Есть другой подход?
>>875661
В любом языке программирования и движке всегда плохо то что засунуто в ежекадровую обработку.
Идеал это вызываемая функция с событием. Всегда и везде надо стараться уменьшить количество кода который обрабатывается каждый кадр.
>за счет постоянной проверки
В любом языке программирования и движке всегда плохо то что засунуто в ежекадровую обработку.
Идеал это вызываемая функция с событием. Всегда и везде надо стараться уменьшить количество кода который обрабатывается каждый кадр.
>>875661
Да много вариантов
Например нарисовать нужное движение в AnimationPlayer
Или добавлять ноду с таким кодом только когда надо двигать.
Или, например, можно отключать process через set-process(false) и включать только когда надо
Но в конце концов если сделал как у тебя то ничего страшного - компьютер наверняка вывезет десятки тысяч таких кнопок.
Если желаешь советов по мелочи
Можно написать settings-show = not settings-show в одну строчку
Не стоит делать $"..", ведь можно один раз в ready() запомнить переменную par = get-parent()
Вообще вроде как считается не очень управлять родителем
Забавный факт - если ты переставишь родителя и ребенка, то все вообще обойдется просто position, т.к. ребенок и будет относительно родителя.
Да много вариантов
Например нарисовать нужное движение в AnimationPlayer
Или добавлять ноду с таким кодом только когда надо двигать.
Или, например, можно отключать process через set-process(false) и включать только когда надо
Но в конце концов если сделал как у тебя то ничего страшного - компьютер наверняка вывезет десятки тысяч таких кнопок.
Если желаешь советов по мелочи
Можно написать settings-show = not settings-show в одну строчку
Не стоит делать $"..", ведь можно один раз в ready() запомнить переменную par = get-parent()
Вообще вроде как считается не очень управлять родителем
Забавный факт - если ты переставишь родителя и ребенка, то все вообще обойдется просто position, т.к. ребенок и будет относительно родителя.
369 Кб, 372x699>>875667
Воспользовался этим.
Впихнул туда set_process(enable)
>set-process(false)
Воспользовался этим.
>Можно написать settings-show = not settings-show в одну строчку
Впихнул туда set_process(enable)
Годаны, а вам не попадалось синтезатора под Годот? Ну, то есть, в теории можно написать самому при помощи AudioStreamGenerator, но лично я такое по скиллам не осилю. Да, есть gdsfxr, но им генерировать музыку проблематично. А вот хотя бы простенькую пищалку, чтобы умела играть треугольник и квадрат, в идеале бы ещё с огибающими, было бы прекрасно. Но чёт не нашёл ничего.
138 Кб, 1204x711>>875685
Вот тут нашлось, вроде играет, адср есть, формы есть, правда автор честно признался что там гумнокод, и лицензию не указал.
https://github.com/petterthowsen/epikus-8/tree/master/SFXer
Вот тут нашлось, вроде играет, адср есть, формы есть, правда автор честно признался что там гумнокод, и лицензию не указал.
https://github.com/petterthowsen/epikus-8/tree/master/SFXer
>>875698
Ну да так-то. Код-то, в общем-то, норм, но весь на гдскрипте. А на гдскрипте я и сам могу. Так-то вопрос возник, потому что в доках пишут:
>автор честно признался что там гумнокод
Ну да так-то. Код-то, в общем-то, норм, но весь на гдскрипте. А на гдскрипте я и сам могу. Так-то вопрос возник, потому что в доках пишут:
>AudioStreamGenerator
>Note: Due to performance constraints, this class is best used from C# or from a compiled language via GDNative. If you still want to use this class from GDScript, consider using a lower mix_rate such as 11,025 Hz or 22,050 Hz.
>>875705
Из поста было непонятно что ты на гдскрипте и сам можешь и тебе нужно на чем то другом. Ну тут думаю тоже не проблема - принцип остается тем же, гдскрипт играет из буффера, а твой код формирует буффер - но тут можно поискать и на c# либы, и на с++, думаю там опций десяток будет - тебе же нужно просто заполнить массив, передав параметры ноты, это движконезависимая часть.
Из поста было непонятно что ты на гдскрипте и сам можешь и тебе нужно на чем то другом. Ну тут думаю тоже не проблема - принцип остается тем же, гдскрипт играет из буффера, а твой код формирует буффер - но тут можно поискать и на c# либы, и на с++, думаю там опций десяток будет - тебе же нужно просто заполнить массив, передав параметры ноты, это движконезависимая часть.
Что мы делаем с хайтмапами? Правильно, мы пишем шейдер с дисплейсом, который из хайтмапа создаёт террейн. Террейн без пещер.
Но что если вместо того чтобы писать шейдер, мы с вами возьмем Gridmap и пользуясь данными heightmap заполним его кубами? А что если мы заполним его не кубами, а заранее заготовленными модельками булыжников? Кто-нибудь так делал?
Но что если вместо того чтобы писать шейдер, мы с вами возьмем Gridmap и пользуясь данными heightmap заполним его кубами? А что если мы заполним его не кубами, а заранее заготовленными модельками булыжников? Кто-нибудь так делал?
>>875772
Фишка готовых аддонов с террейном - готовые лоды, возможно клипмапы, а мультимеш и гридмап вроде бы не умеют в лоды и в окклюжен и там надо самому делать? Я правда давно с этим разбирался, пару лет назад. Кажется тогда надо было несколько мультимешей на разные лоды, и при этом обновлять данные когда персонаж подходит ближе.
Фишка готовых аддонов с террейном - готовые лоды, возможно клипмапы, а мультимеш и гридмап вроде бы не умеют в лоды и в окклюжен и там надо самому делать? Я правда давно с этим разбирался, пару лет назад. Кажется тогда надо было несколько мультимешей на разные лоды, и при этом обновлять данные когда персонаж подходит ближе.
>>875681
Я на 4ке большой 3д проект пилю, но для браузера там тени пока не дописали. Ну и весить то билд побольше стал. Так что я хз даже, вроде как и можно делать навороченные 2д игры и даже простые 3д гиперкажуалки, но их с таким же успехом можно и на 3.6 делать.
Я на 4ке большой 3д проект пилю, но для браузера там тени пока не дописали. Ну и весить то билд побольше стал. Так что я хз даже, вроде как и можно делать навороченные 2д игры и даже простые 3д гиперкажуалки, но их с таким же успехом можно и на 3.6 делать.
112 Кб, 780x210Кстати насчет автолодов 4-ки. Сегодня импортировал модельки и получил вот таких бетменов, если есть одежда то еще хуже. В общем решается так - клик на .glb и реимпорт с убранной галкой на Generate LODs. Подозреваю что генератор не умеет работать с костями, а возможно и блендшейпами, так что с персонажами пока только в фулл разрешении. Для домиков типа кубик вроде проблем не наблюдал
>>875782
Вроде бы как раз умеют. Искаропки.
> мультимеш и гридмап вроде бы не умеют в лоды и в окклюжен и там надо самому делать?
Вроде бы как раз умеют. Искаропки.
>>875787
Автогенерация ЛОДов это всегда боль, везде.
Автогенерация ЛОДов это всегда боль, везде.
>>875787
Я не опытен в этом, но у 3дмакса есть модификатор Multires, интересно как ты делаешь это, кроме автоматического варианта через годо
Я не опытен в этом, но у 3дмакса есть модификатор Multires, интересно как ты делаешь это, кроме автоматического варианта через годо
>>875798
Сейчас никак не делаю, просто закинул модель и чуть необосрался. Раньше делал в 3 годоте как учили - несколько мешей вручную и переключал их скриптом по on area entered. Возможно тут так же придется, только переключать в 4ке лоды можно не вручную, а просто сделав одному объекту visibility range min-max до 5 метров, другому объекту от 4 метров до 10 и так далее.
Сейчас никак не делаю, просто закинул модель и чуть необосрался. Раньше делал в 3 годоте как учили - несколько мешей вручную и переключал их скриптом по on area entered. Возможно тут так же придется, только переключать в 4ке лоды можно не вручную, а просто сделав одному объекту visibility range min-max до 5 метров, другому объекту от 4 метров до 10 и так далее.
>>875799
О, годно
Я вот хотел бы сделать игру типа Lands Of Lore 2 с воксельными объектами вокруг при помощи grid mesh или как там его, вообще авторы годо очень хорошо придумали tilemap и gridmesh, ну и я был очень доволен MultiMeshInstance, по сравнению с подобным в OPenGL просто супер легко
> лоды можно не вручную, а просто сделав одному объекту visibility range min-max до 5 метров, другому объекту от 4 метров до 10 и так далее
О, годно
Я вот хотел бы сделать игру типа Lands Of Lore 2 с воксельными объектами вокруг при помощи grid mesh или как там его, вообще авторы годо очень хорошо придумали tilemap и gridmesh, ну и я был очень доволен MultiMeshInstance, по сравнению с подобным в OPenGL просто супер легко
>>875794
Ну а что не кажуальное ты можешь придумать в 3д но без теней? Я то пилю с рассчетом что все таки хотя бы базовые тени допилят. Сейчас там просто иногда заливает все черными треугольниками.
Ну а что не кажуальное ты можешь придумать в 3д но без теней? Я то пилю с рассчетом что все таки хотя бы базовые тени допилят. Сейчас там просто иногда заливает все черными треугольниками.
>>875800
Гридмеш поначалу вызывает радостные эмоции, но потом понимаешь что если ты хочешь сделать улицу под 30 градусов то легко не будет. Можно конечно попробовать гридмап на город или городской район и ставить под нужным углом. Еще я как то скидывал набор городских тайлов где уже заложены некие кривые улочки
Гридмеш поначалу вызывает радостные эмоции, но потом понимаешь что если ты хочешь сделать улицу под 30 градусов то легко не будет. Можно конечно попробовать гридмап на город или городской район и ставить под нужным углом. Еще я как то скидывал набор городских тайлов где уже заложены некие кривые улочки
>>875792
Сделаешь тестовый проект? Я тоже могу, но сейчас пишу с картофелины, поэтому это может занять день.
Сделаешь тестовый проект? Я тоже могу, но сейчас пишу с картофелины, поэтому это может занять день.
>>875802
В LOL 2 карта как в первом вульфене прямоугольная
В LOL 2 карта как в первом вульфене прямоугольная
>>875800
Потести, не уверен что потянет если ты хочешь использовать их как мелкие воксели.
>воксельные объекты
Потести, не уверен что потянет если ты хочешь использовать их как мелкие воксели.
>>873235 (OP)
Всем ку годотеры, подскажите, хочу сделать на годоте подобие игр на ренпи и куспе раньше которые были, но немного по приятнее визуально и не с такой лапшой кодом как там.
Сам геймплей игры прост до безобразия, есть пара фонов, десяток спрайтов персонажей, диалог как в новеллах с кнопками ответов, и разные интерфейсы окон, ничего в реалтайме не будет делаться, только ожидая нажатия от игрока.
Надеюсь понятно объяснил, такое сложно будет сделать и возможно?
Всем ку годотеры, подскажите, хочу сделать на годоте подобие игр на ренпи и куспе раньше которые были, но немного по приятнее визуально и не с такой лапшой кодом как там.
Сам геймплей игры прост до безобразия, есть пара фонов, десяток спрайтов персонажей, диалог как в новеллах с кнопками ответов, и разные интерфейсы окон, ничего в реалтайме не будет делаться, только ожидая нажатия от игрока.
Надеюсь понятно объяснил, такое сложно будет сделать и возможно?
>>875806
Есть новелмейкер или типа того, это отдельная прога
А если годо, то ищи плагины чтобы не тратить время на создание всего этого и сразу делать твою задумку
Есть новелмейкер или типа того, это отдельная прога
А если годо, то ищи плагины чтобы не тратить время на создание всего этого и сразу делать твою задумку
>>875807
У меня своя задумка, и стандартные новелкомейкеры не подойдут точно.
И плагины зачем? Всё сам хочу написать чтобы понимать как, что, куда идёт, она то на вид примитивная будет, но там много окон и взаимодействий, плагинами такое не реализовать.
У меня своя задумка, и стандартные новелкомейкеры не подойдут точно.
И плагины зачем? Всё сам хочу написать чтобы понимать как, что, куда идёт, она то на вид примитивная будет, но там много окон и взаимодействий, плагинами такое не реализовать.
>>873235 (OP)
Годаны, кто реализовывал свечение отдельных объектов в проектах? Про glow в world environment в курсе, но что-то получается сомнительно. Вот есть отдельная сцена с врагом (ареа, спрайт и колижн шейп), добавляю так свечение, в итоге вся основная сцена игры, когда появляется враг, начинает светиться, как новогодняя ёлка, и фон, и гг, и предметы.
Годаны, кто реализовывал свечение отдельных объектов в проектах? Про glow в world environment в курсе, но что-то получается сомнительно. Вот есть отдельная сцена с врагом (ареа, спрайт и колижн шейп), добавляю так свечение, в итоге вся основная сцена игры, когда появляется враг, начинает светиться, как новогодняя ёлка, и фон, и гг, и предметы.
>>875812
2д? Так там вроде источники света есть. шейдеры опять же.
С другой стороны ты пишешь про ворлдэнвайр, он вроде только для 3д же. В 3д сложнее , в каком то прошлом треде обсуждали. Легко только со сферой.
2д? Так там вроде источники света есть. шейдеры опять же.
С другой стороны ты пишешь про ворлдэнвайр, он вроде только для 3д же. В 3д сложнее , в каком то прошлом треде обсуждали. Легко только со сферой.
>>875810
Да самому легко все, просто больше времени займет.
Да самому легко все, просто больше времени займет.
>>875803
Сделаю позже. Щас пока нет времени. Смотрю видосы, как правильно кидать топор https://youtu.be/6GIrjs-Qy0U
Сделаю позже. Щас пока нет времени. Смотрю видосы, как правильно кидать топор https://youtu.be/6GIrjs-Qy0U
>>875819
Смотря, какой гейплей у тебя задуман. Рутмовшон подходит для игор с минимумом вертикальности. Если у тебя много паркура, лазанья по стенам то рутмовшон не справится.
Смотря, какой гейплей у тебя задуман. Рутмовшон подходит для игор с минимумом вертикальности. Если у тебя много паркура, лазанья по стенам то рутмовшон не справится.
>>875820
Все я вспомнил что это, это Animation-driven движения, да у меня планируется больше поркура, надо подумоть.
Все я вспомнил что это, это Animation-driven движения, да у меня планируется больше поркура, надо подумоть.
Короче решил я значит значит сделать очень простой платформер (не спрашивайте зачем)
И взял этот ваш годот...В целом всё понятно, однако я неудачник и пришел к моменту выхода новой версии поэтому в интернете нихуя нет.
Собтвенно вопрос: Есть characterbody2d , беру и делаю scale.x = -1 и весь персонаж разворачивается. У меня всё работает. Однако в интернете есть полно обсуждений, что вешать негтитвное значение в scale для физических нод нельзя. Иначе всё идёт в жопу.
Но всё это датированно 2018-2022 годом.
Собственно сейчас в новом godot4 это пофикшенно, и физ ножам можно задавать отрицательный масштаб или я просто что то не так делаю?
И взял этот ваш годот...В целом всё понятно, однако я неудачник и пришел к моменту выхода новой версии поэтому в интернете нихуя нет.
Собтвенно вопрос: Есть characterbody2d , беру и делаю scale.x = -1 и весь персонаж разворачивается. У меня всё работает. Однако в интернете есть полно обсуждений, что вешать негтитвное значение в scale для физических нод нельзя. Иначе всё идёт в жопу.
Но всё это датированно 2018-2022 годом.
Собственно сейчас в новом godot4 это пофикшенно, и физ ножам можно задавать отрицательный масштаб или я просто что то не так делаю?
>>875842
Если у тебя персонаж - симметричная капсула или квадрат, тебе вообще не надо ее флипать. Тебе надо флипать только визуальный спрайт.
Если у тебя персонаж - симметричная капсула или квадрат, тебе вообще не надо ее флипать. Тебе надо флипать только визуальный спрайт.
>>875818
Идея прикольная, но почему-то 10 ФПС на объёме до 50,50,50 блоков. Если задавать объёмы больше - фепесы падают в нулину, блять. Без коллизий, без навмешей. Гридмап, блять. Оптимизированный октантами. Блять.
> Сделаю позже.
Идея прикольная, но почему-то 10 ФПС на объёме до 50,50,50 блоков. Если задавать объёмы больше - фепесы падают в нулину, блять. Без коллизий, без навмешей. Гридмап, блять. Оптимизированный октантами. Блять.
>>875848
А можешь еще потестить лоды и оклюжн куллинг на гридмапе? У меня лапки, на нетбуке не работает вулкан, а в опенжоле не показывает.
Тут написано как потыкать в редакторе, но не факт что там точно измеряет
https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod.html#comparing-mesh-lod-visuals-and-performance
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html#previewing-occlusion-culling
Или попробовать по честному вкл-выкл окклюжн где-то в настройках проекта Rendering > Occlusion Culling > Use Occlusion Culling , а лоды галочкой в импорте модельки, как я кидал выше скрин.
А можешь еще потестить лоды и оклюжн куллинг на гридмапе? У меня лапки, на нетбуке не работает вулкан, а в опенжоле не показывает.
Тут написано как потыкать в редакторе, но не факт что там точно измеряет
https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod.html#comparing-mesh-lod-visuals-and-performance
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html#previewing-occlusion-culling
Или попробовать по честному вкл-выкл окклюжн где-то в настройках проекта Rendering > Occlusion Culling > Use Occlusion Culling , а лоды галочкой в импорте модельки, как я кидал выше скрин.
>>875848
И еще вопрос как вообще настроить лоды для элементов гридмапа. В свойствах самого гридмапа? В мешлибе?
И еще вопрос как вообще настроить лоды для элементов гридмапа. В свойствах самого гридмапа? В мешлибе?
>>875848
Еще такая мысль - не знаю как у них сделана сортировка по объектам/материалам. Можешь попробовать еще сделать несколько гридмапов, но каждый в мешлибе содержит только один вид камня. Чтобы отрисовка точно шла одним батчем. Или вообще сравнить с мультимешем.
Еще такая мысль - не знаю как у них сделана сортировка по объектам/материалам. Можешь попробовать еще сделать несколько гридмапов, но каждый в мешлибе содержит только один вид камня. Чтобы отрисовка точно шла одним батчем. Или вообще сравнить с мультимешем.
>>875848
50 в кубе это 125 000, не факт что там используется instance render, хотя хрен его знает
Касаемо лод, тот тут менять в зависимости от расстояния
> но почему-то 10 ФПС
50 в кубе это 125 000, не факт что там используется instance render, хотя хрен его знает
Касаемо лод, тот тут менять в зависимости от расстояния
>>875812
Очевидно же в свойствах материала есть emission, его и крути, с glow и вовсе становится балдеж
Очевидно же в свойствах материала есть emission, его и крути, с glow и вовсе становится балдеж
>>875887
Emission сам по себе не производит свет, он просто делает участок текстуры видимым в темноте, даже если объект в тени. А глоу на всю сцену может быть нежелательным.
Нашел свой старый пост на тему с возможной эмуляцией >>850059 → >>850237 →
Emission сам по себе не производит свет, он просто делает участок текстуры видимым в темноте, даже если объект в тени. А глоу на всю сцену может быть нежелательным.
Нашел свой старый пост на тему с возможной эмуляцией >>850059 → >>850237 →
>>875851
Включил. Немного фепсов прибавилось, но всё равно не продакшен-левел. Не впечатлило. Вот скрины с куллингом и одним кубом, в объёме 100/100/50 соответственно.
> вкл-выкл окклюжн где-то в настройках проекта Rendering > Occlusion Culling > Use Occlusion Culling
Включил. Немного фепсов прибавилось, но всё равно не продакшен-левел. Не впечатлило. Вот скрины с куллингом и одним кубом, в объёме 100/100/50 соответственно.
>>875892
Если ты хочешь рядом все освещать, то явно с помощью узлов динамического света. емиссион жеж и при запечке учитывается, так что хуй знает че тебе еще надо. Да, можешь заюзать шейдер с прозрачным градиентом. На твоих пиках так же юзается емиссион, ток еще юзается дублированная геометрия, вдоль нормалей сдвиг и полупрозрачность
Если ты хочешь рядом все освещать, то явно с помощью узлов динамического света. емиссион жеж и при запечке учитывается, так что хуй знает че тебе еще надо. Да, можешь заюзать шейдер с прозрачным градиентом. На твоих пиках так же юзается емиссион, ток еще юзается дублированная геометрия, вдоль нормалей сдвиг и полупрозрачность
>>875896
хз с чего ты решил что там эмиссия, в шейдере ее нет, а зеленый засвет на белой стене это действительно источник света. А дублированная геометрия слишком заметна в местах где она накладывается. По хорошему там надо что то с вьюпортами мутить, эмулировать стенсил буфер, но это долго и лень.
хз с чего ты решил что там эмиссия, в шейдере ее нет, а зеленый засвет на белой стене это действительно источник света. А дублированная геометрия слишком заметна в местах где она накладывается. По хорошему там надо что то с вьюпортами мутить, эмулировать стенсил буфер, но это долго и лень.
А, еще вспомнил в 4-ке добавили объемный туман, может быть с его помощью можно имитировать свечение. Только придумать как в шейдер передавать форму объекта (если это анимированный человек например)
15 Кб, 270x120>>875899
в 4 есть буфер глубины
в 3 есть костыли, с вьюпортом и камерой
Не до конца просто понимаю че ты хочешь сделать.
Когда у тебя будет сцена построена со светом, без емиссона у тя будет все блекло, пока это незаметно пока ты там чета ковыряешь вне законченной композиции с выставленным светом
в 4 есть буфер глубины
в 3 есть костыли, с вьюпортом и камерой
Не до конца просто понимаю че ты хочешь сделать.
Когда у тебя будет сцена построена со светом, без емиссона у тя будет все блекло, пока это незаметно пока ты там чета ковыряешь вне законченной композиции с выставленным светом
>>875894
Скайкрафт мечты! Мой майнрим!
Скайкрафт мечты! Мой майнрим!
15 Кб, 270x120>>875903
Кстати анон, а не дохуя ли ты генеришь? Не производительней будет дохуя более мелких гридмапов 10х10х10, а не один 50х50х50?
Кстати анон, а не дохуя ли ты генеришь? Не производительней будет дохуя более мелких гридмапов 10х10х10, а не один 50х50х50?
>>875906
Дело в том, что я не силён в математике. Если ты мне покажешь как сделать так, чтобы несколько гридов бесшовно принимали значения из одного шума, тогда сделою.
Сейчас у меня была главная идея в том, чтобы был один грид, один шум, одна карта. А грид чтобы сам куллился автоматически. Он же там как-то хитро на октанты разбит, которые якобы куллятся и лодятся автоматически?
Дело в том, что я не силён в математике. Если ты мне покажешь как сделать так, чтобы несколько гридов бесшовно принимали значения из одного шума, тогда сделою.
Сейчас у меня была главная идея в том, чтобы был один грид, один шум, одна карта. А грид чтобы сам куллился автоматически. Он же там как-то хитро на октанты разбит, которые якобы куллятся и лодятся автоматически?
>>875905
Ты отвечаешь анону, который отвечал другому анону.
Что хочет тот анон не знаю, а мои эксперименты начались с того, как сделать световой меч АКА лайтсейбр, в виде цилиндра, и чтобы на сцене можно было иметь два с разным радиусом свечения (что через глоу ворлдэнвайр вроде невозможно)
Ты отвечаешь анону, который отвечал другому анону.
Что хочет тот анон не знаю, а мои эксперименты начались с того, как сделать световой меч АКА лайтсейбр, в виде цилиндра, и чтобы на сцене можно было иметь два с разным радиусом свечения (что через глоу ворлдэнвайр вроде невозможно)
16 Кб, 270x120>>875907
В смысле, ты этот шум по частям и генерь на каждый гридмап. Все тоже самое как у тебя, только ты берешь шум не с 0 до н-макс размера твоей текстуры шума, а н-заданое.
Например текстурка 256, а ты делишь все на 10, ну дык и дели 256 и получай значение каждого шага.
Так и так тебе нид разбивать все на сегменты, дабы их всегда можно было убрать из памяти\либо не рендерить и не напрягать комп.
>Если ты мне покажешь как сделать так, чтобы несколько гридов бесшовно принимали значения из одного шума, тогда сделою.
В смысле, ты этот шум по частям и генерь на каждый гридмап. Все тоже самое как у тебя, только ты берешь шум не с 0 до н-макс размера твоей текстуры шума, а н-заданое.
Например текстурка 256, а ты делишь все на 10, ну дык и дели 256 и получай значение каждого шага.
Так и так тебе нид разбивать все на сегменты, дабы их всегда можно было убрать из памяти\либо не рендерить и не напрягать комп.
17 Кб, 270x120>>875909
говорю анон, покажи мне картинку того чо ты хочешь, рефы нужны. Описания хуйня, световые мечи как раз через емиссион и глоу делаются
говорю анон, покажи мне картинку того чо ты хочешь, рефы нужны. Описания хуйня, световые мечи как раз через емиссион и глоу делаются
>>875907
Мы так до конца в этом и не убедились. Тесты надо.
По идее они и не помогут в случае 100 процентного заполнения объема, а только дадут оверхед. Ведь нарисовать надо все кубы, но при этом на каждый куб будут рассчеты. Октанты помогают в прореженной сетке, например если у тебя сеть дорог или хотя бы просто только поверхность террейна.
Создать нойс в родительской ноде один раз и брать оттуда. А циклы проводить не от -25 до 25, а по частям.
>якобы куллятся и лодятся автоматически?
Мы так до конца в этом и не убедились. Тесты надо.
>октанты
По идее они и не помогут в случае 100 процентного заполнения объема, а только дадут оверхед. Ведь нарисовать надо все кубы, но при этом на каждый куб будут рассчеты. Октанты помогают в прореженной сетке, например если у тебя сеть дорог или хотя бы просто только поверхность террейна.
> как сделать так, чтобы несколько гридов бесшовно принимали значения из одного шума
Создать нойс в родительской ноде один раз и брать оттуда. А циклы проводить не от -25 до 25, а по частям.
>>875910
ЯННП. Какая текстура? Я взаимодействую с шумом через встроенный интерфейс. Код выше посмотри. Я получаю значение шума не на текстуре, а прямо в пространстве, через .get_noise_3d(i,j,k)
ЯННП. Какая текстура? Я взаимодействую с шумом через встроенный интерфейс. Код выше посмотри. Я получаю значение шума не на текстуре, а прямо в пространстве, через .get_noise_3d(i,j,k)
>>875912
А вот собсна тест выше и был. Никакой оптимизации. ФПС на 10. Придётся всё таки юзать аддоны. А хотелось самостоятельно.
> Тесты надо.
А вот собсна тест выше и был. Никакой оптимизации. ФПС на 10. Придётся всё таки юзать аддоны. А хотелось самостоятельно.
>>875913
В общем-то я уже сам нашёл ответ, как объединить несколько "чанков" гридмапов под одним шумом. Надо добавлять координаты самого гридмапа к координатам в сетках. .get_noise_3d(pos.x + i,pos.y + j, pos.z + k)
В общем-то я уже сам нашёл ответ, как объединить несколько "чанков" гридмапов под одним шумом. Надо добавлять координаты самого гридмапа к координатам в сетках. .get_noise_3d(pos.x + i,pos.y + j, pos.z + k)
>>875917
Сложна, сложна, нипанятна! Ниасиливаю. Раз 10 пытался разобраться. Безрезультатно.
Сложна, сложна, нипанятна! Ниасиливаю. Раз 10 пытался разобраться. Безрезультатно.
17 Кб, 270x120>>875913
и че? чем отличается от текстурки 2д ток в 3д? те же координаты, и их значения. бери и отрисовывай от 1,1,1 до 10,10,10 и т.д со смещением, то бишь координаты меняются со смешением и так раз за разом генерится
и че? чем отличается от текстурки 2д ток в 3д? те же координаты, и их значения. бери и отрисовывай от 1,1,1 до 10,10,10 и т.д со смещением, то бишь координаты меняются со смешением и так раз за разом генерится
17 Кб, 270x120>>875917
я юзал мультимеши для мульонов пуль + синхронизация с физик сервером, пара косарей пуль на изи генерится, постоянно можно пересчитывать, то бишь супер быстро работает на перечитывание. Базарю, анону рили стоит пробнуть мультимеши, а физику юзать напрямую через физик сервер
я юзал мультимеши для мульонов пуль + синхронизация с физик сервером, пара косарей пуль на изи генерится, постоянно можно пересчитывать, то бишь супер быстро работает на перечитывание. Базарю, анону рили стоит пробнуть мультимеши, а физику юзать напрямую через физик сервер
>>875919
И кстати, я хочу отдельно заметить, что циклы в ready которые на скринах, выполняются очень быстро. Тормозит не вышеприведенный код, тормозит именно отрисовка готового статичного гридмапа.
И кстати, я хочу отдельно заметить, что циклы в ready которые на скринах, выполняются очень быстро. Тормозит не вышеприведенный код, тормозит именно отрисовка готового статичного гридмапа.
>>875920
Просто обидно, этот гридмап выглядит таким удобным, а по факту неюзабелен.
Просто обидно, этот гридмап выглядит таким удобным, а по факту неюзабелен.
17 Кб, 270x120>>875924
Было предложение его выпилить из 4-ки, но народ начал возмущаться. А по факту так и есть, он только совсем новичкам подходит которые собирают свою первую гташку по кварталам. Ну еще его можно юзать как массив для всякого астар, но можно и без этого обойтись.
Было предложение его выпилить из 4-ки, но народ начал возмущаться. А по факту так и есть, он только совсем новичкам подходит которые собирают свою первую гташку по кварталам. Ну еще его можно юзать как массив для всякого астар, но можно и без этого обойтись.
>>875922
>>875924
>>875918
https://pastebin.com/VgLu5GJH
создание в мультимеше, с физикой на физик сервере
Держите аноны, можете попичкать код, генерить любую н-хуйню, при желании в апи можете посмотреть другие виды капсул для колизии
Вызов функция вот, 1 значение вроде бы пакет сцены, на скрине показано что из себя представляет, оттуда берутся мешь все настройки для физик сервера
2 это координаты где будет спавнится
3 это исключения колизии, вроде нид указывать просто ссылку на просто объект аля rigidbody kinematic body и все, они будут исключатся и не будут сталкиват
4 это эффекты всякие при спавне, но я их не реализовал тогда
func projectile(packed_scene : PackedScene, spawn_transform : Transform, collision_exceptions := [], _effects := [])
сорян, мейби говнокод, но я это делал года 3 назад, я не шибко какой-то йобо кодер
аноны, пощупайте, если хотите
>>875924
>>875918
https://pastebin.com/VgLu5GJH
создание в мультимеше, с физикой на физик сервере
Держите аноны, можете попичкать код, генерить любую н-хуйню, при желании в апи можете посмотреть другие виды капсул для колизии
Вызов функция вот, 1 значение вроде бы пакет сцены, на скрине показано что из себя представляет, оттуда берутся мешь все настройки для физик сервера
2 это координаты где будет спавнится
3 это исключения колизии, вроде нид указывать просто ссылку на просто объект аля rigidbody kinematic body и все, они будут исключатся и не будут сталкиват
4 это эффекты всякие при спавне, но я их не реализовал тогда
func projectile(packed_scene : PackedScene, spawn_transform : Transform, collision_exceptions := [], _effects := [])
сорян, мейби говнокод, но я это делал года 3 назад, я не шибко какой-то йобо кодер
аноны, пощупайте, если хотите
14 Кб, 270x120>>875932
Алсо дополню. Я это юзал именно для спавна гильз дабы на сцене было их тысячи с коллизией и т.д, без пропуков. Вы же можете это оптимизировать для себя подругому, без нужды допустим чтобы они выплевывались с н-скоростью, а были сразу статик, короче там массу настроек можно сделать
Алсо дополню. Я это юзал именно для спавна гильз дабы на сцене было их тысячи с коллизией и т.д, без пропуков. Вы же можете это оптимизировать для себя подругому, без нужды допустим чтобы они выплевывались с н-скоростью, а были сразу статик, короче там массу настроек можно сделать
>>875911
На примере 3-ки.
Если менять Power в emission, меняется цвет свечения, но радиус остается тем же.
Если менять Intensity или Strength в Glow WorldEnvironment, то меняется интенсивность всего свечения - обоих мечей, фары мотоцикла, солнца, неба, аллаха.
Изобразил в 2д как я себе представляю желаемое. Также желательно например чтобы можно было анимировать радиус только одного из них.
Вулкан потестить сейчас возможности не имею, а в опенгл 4-ки Glow пока не сделан.
На примере 3-ки.
Если менять Power в emission, меняется цвет свечения, но радиус остается тем же.
Если менять Intensity или Strength в Glow WorldEnvironment, то меняется интенсивность всего свечения - обоих мечей, фары мотоцикла, солнца, неба, аллаха.
Изобразил в 2д как я себе представляю желаемое. Также желательно например чтобы можно было анимировать радиус только одного из них.
Вулкан потестить сейчас возможности не имею, а в опенгл 4-ки Glow пока не сделан.
>>875941
Добавлю, что в случае лайтсейбров, ламп дневного света, можно попробовать придумать что то вроде 3д спрайта в котором рисуется 2д текстура, все же овал не очень сложная форма, но с персонажами такое уже не прокатит.
Добавлю, что в случае лайтсейбров, ламп дневного света, можно попробовать придумать что то вроде 3д спрайта в котором рисуется 2д текстура, все же овал не очень сложная форма, но с персонажами такое уже не прокатит.
19 Кб, 270x120>>875941
А видимо все. больше вариантов не будет из стандартных. то бишь тебе придется развлекаться только со стандартным глоу, можно конечно в случае с персонажем в шейдере дублировать сетку и выдавить её по нормалям, накинуть емиссиона на это эффект, плюс с глоу поиграться дабы меньше переходов было видно. Я вот не помню, погляди в настройках, мейби там есть возможность увеличить качество глоу, а то оно у тебя рили рубленное.
Свечение лучше чем в этих видосах ты не сделаешь
https://www.youtube.com/watch?v=P-6NmnwbavY&ab_channel=GameDevChris
https://www.youtube.com/watch?v=-7jo5uUxwXE&t=5s&ab_channel=3rdMonkey
А видимо все. больше вариантов не будет из стандартных. то бишь тебе придется развлекаться только со стандартным глоу, можно конечно в случае с персонажем в шейдере дублировать сетку и выдавить её по нормалям, накинуть емиссиона на это эффект, плюс с глоу поиграться дабы меньше переходов было видно. Я вот не помню, погляди в настройках, мейби там есть возможность увеличить качество глоу, а то оно у тебя рили рубленное.
Свечение лучше чем в этих видосах ты не сделаешь
https://www.youtube.com/watch?v=P-6NmnwbavY&ab_channel=GameDevChris
https://www.youtube.com/watch?v=-7jo5uUxwXE&t=5s&ab_channel=3rdMonkey
50 Кб, 700x456>>875932
Анончик, ты просто охуенен!
Анончик, ты просто охуенен!
>>875932
Пощупал. Код зависит от синглтонов. Такшта либо тащи их, либо заведи полезную привычку описывать зависимости в комментах, чтобы сразу видеть самому от чего зависит код, либо не используй синглтоны (понимаю, сложно отказаться от удобства).
> пощупайте, если хотите
Пощупал. Код зависит от синглтонов. Такшта либо тащи их, либо заведи полезную привычку описывать зависимости в комментах, чтобы сразу видеть самому от чего зависит код, либо не используй синглтоны (понимаю, сложно отказаться от удобства).
>>875975
Не закончил мысль. Щас в туториалах на ютубе и как следствие в ассетах на ассетлибе, пошла мода вместо прописывания автолоада, прописывать export(NodePath) var в скриптах. Это явно показывает, что скрипту следует подсунуть правильную ноду для работы, и уже об этом не забудешь, и зависимость у кода будет явная.
> либо не используй синглтоны
Не закончил мысль. Щас в туториалах на ютубе и как следствие в ассетах на ассетлибе, пошла мода вместо прописывания автолоада, прописывать export(NodePath) var в скриптах. Это явно показывает, что скрипту следует подсунуть правильную ноду для работы, и уже об этом не забудешь, и зависимость у кода будет явная.
>>875894
Вот еще вспомнил недавно обсуждали воксель модуль Зилана, может тебя заинтересовать >>871412 →
Вот еще вспомнил недавно обсуждали воксель модуль Зилана, может тебя заинтересовать >>871412 →
>>876027
Надо же! Настоящий модуль воксельного террейна! Впервые вижу! Спасибо за помощь!
Очевидно же, что я пытался обойтись а) без вокселей, б) без сторонних модулей
> может тебя заинтересовать
Надо же! Настоящий модуль воксельного террейна! Впервые вижу! Спасибо за помощь!
Очевидно же, что я пытался обойтись а) без вокселей, б) без сторонних модулей
>>876059
Насчет б) насколько я понимаю стратегию развития, такие расширения будут только внешними. Но в этом случае модуль уже там скомпилирован в кастомный билд движка.
а) просто подумал, что раз ты делаешь типа воксели, то почему бы не попробовать воксели и сравнить производительность.
Насчет б) насколько я понимаю стратегию развития, такие расширения будут только внешними. Но в этом случае модуль уже там скомпилирован в кастомный билд движка.
а) просто подумал, что раз ты делаешь типа воксели, то почему бы не попробовать воксели и сравнить производительность.
>>876072
Пора бы уже мне научиться билдить самому движок с любыми модулями, какие захочу.
> скомпилирован в кастомный билд движка
Пора бы уже мне научиться билдить самому движок с любыми модулями, какие захочу.
>>873235 (OP)
А можно как-нибудь в версии 3.5 копировать коллизию тайлов? А то как-то запарно каждый раз заново её ставить
А можно как-нибудь в версии 3.5 копировать коллизию тайлов? А то как-то запарно каждый раз заново её ставить
>>876086
Не помню насчет нормального способа, но точно применял такие
1) генерировал скриптом на питоне файл с коллизиями, грубо говоря tscn же текстовый файл где можно по мелочи даже руками скопипастить
2) генерировал какие-то коллизии tool-скриптом, там конечно надо покурить api че кому назначать, но это реально, типа найти нужный тайл, взять его коллизию, назначить другому тайлу.
Может быть есть что-то даже готовое в ассетах, давно 2д не чекал.
Не помню насчет нормального способа, но точно применял такие
1) генерировал скриптом на питоне файл с коллизиями, грубо говоря tscn же текстовый файл где можно по мелочи даже руками скопипастить
2) генерировал какие-то коллизии tool-скриптом, там конечно надо покурить api че кому назначать, но это реально, типа найти нужный тайл, взять его коллизию, назначить другому тайлу.
Может быть есть что-то даже готовое в ассетах, давно 2д не чекал.
>>876098
Иногда да, я просто не люблю обезъянью работу, и если что то можно автоматизировать, я лучше час потрачу на тул скрипт, чтобы потом в любой момент копировать что-то, особенно если это надо повторить больше 16 раз. Редко конечно могу включить что то чилловое посмотреть в фоне и под это дело кликать. Но ска цена ошибки часто высока, приходится переделывать, возвращаться к пропущенным. Цикл в скрипте проще, если ошибся. просто правлю и еще раз прогоняю.
Иногда да, я просто не люблю обезъянью работу, и если что то можно автоматизировать, я лучше час потрачу на тул скрипт, чтобы потом в любой момент копировать что-то, особенно если это надо повторить больше 16 раз. Редко конечно могу включить что то чилловое посмотреть в фоне и под это дело кликать. Но ска цена ошибки часто высока, приходится переделывать, возвращаться к пропущенным. Цикл в скрипте проще, если ошибся. просто правлю и еще раз прогоняю.
>>873237
И еще на тему root motion. Есть сейчас акутальный плагин для blender+mixamo+godot? Раньше я знаю был Godot game tools, но он подглючивал, и вообще слабо поддерживается для актуальных версий блендера и годота, там куча ишью, и свежего форка не нашел чего то.
И еще на тему root motion. Есть сейчас акутальный плагин для blender+mixamo+godot? Раньше я знаю был Godot game tools, но он подглючивал, и вообще слабо поддерживается для актуальных версий блендера и годота, там куча ишью, и свежего форка не нашел чего то.
>>876208
Порылся по топикам гитхаба и нашел такой https://github.com/baracil/Mixamo2Godot
Сейчас буду опробовать
Порылся по топикам гитхаба и нашел такой https://github.com/baracil/Mixamo2Godot
Сейчас буду опробовать
15,2 Мб, mp4,1080x2340, 0:15
А как можно сделать такую анимацию аима? Пока сидел на юнити реализовывал такое через проигрывание анимации в зависимости от положения прицела, но это на каждые ~10 градусов рисовать отдельный спрайт, с учётом того, что планируется несколько видов оружия и персонажей объем работы получается не маленький. Как это упростить можно? Была мысль сделать обычный аим как во всех гайдах для топ-даун шутера с преследованием положения мыши, а руки просто привязать к плечам и оружию, чтобы они болтались как сосиски, но не знаю как такое сделать в годот.
https://godotengine.org/article/rendering-priorities-4-1/
революция близка
революция близка
>>876309
Делаешь руки отдельно от тела, анимируешь либо скелетной анимацией, либо просто кодом поворачиваешь спрайт рук, который висит чайлдом во всём теле
Делаешь руки отдельно от тела, анимируешь либо скелетной анимацией, либо просто кодом поворачиваешь спрайт рук, который висит чайлдом во всём теле
13 Кб, 270x120>>876309
Тонна челов которые реализовывали подобный поворот оружия. Основная мысль в том, что у спрайта есть pivot и благодаря этому оружие вертится не от центра спрайта.
Тонна челов которые реализовывали подобный поворот оружия. Основная мысль в том, что у спрайта есть pivot и благодаря этому оружие вертится не от центра спрайта.
31 Кб, 738x373>>876309
Зато это красиво. Вообще сейчас есть способы ускорить этот процесс, рендерить в 3д, а еще нейронки.
так ноды же вращаются относительно родительской.
Ты можешь вращать ее через rotation, а можешь сделать что то вроде $Gun.look_at( get_local_mouse_position() ) - на самом деле чуть сложнее, поскольку надо бы брать позицию мыши из камеры, уже с учетом масштаба и сдвига. Это вообще за 5 минут делается.
Или как анон выше сказал скелетную анимацию https://docs.godotengine.org/en/stable/tutorials/animation/2d_skeletons.html Но это уже позаебистее.
>на каждые ~10 градусов рисовать отдельный спрайт
Зато это красиво. Вообще сейчас есть способы ускорить этот процесс, рендерить в 3д, а еще нейронки.
>руки просто привязать к плечам и оружию, чтобы они болтались как сосиски, но не знаю как такое сделать в годот.
так ноды же вращаются относительно родительской.
Ты можешь вращать ее через rotation, а можешь сделать что то вроде $Gun.look_at( get_local_mouse_position() ) - на самом деле чуть сложнее, поскольку надо бы брать позицию мыши из камеры, уже с учетом масштаба и сдвига. Это вообще за 5 минут делается.
Или как анон выше сказал скелетную анимацию https://docs.godotengine.org/en/stable/tutorials/animation/2d_skeletons.html Но это уже позаебистее.
>>876318
Вообще можно совмещать риксели и смену спрайтов. Но в большинстве игр вообще не парятся с этим.
>Зато это красиво.
Вообще можно совмещать риксели и смену спрайтов. Но в большинстве игр вообще не парятся с этим.
>>876317
>>876318
У меня сейчас так и сделано. Я не понимаю как сделать так, чтобы один конец рук был всегда привязан к рукоятке оружия, а другие концы рук всегда был привязан к плечам. Было бы проще, если бы руки были одной длины и просто сделать их родительским объектом для оружья, но они у меня разной длины т.к. спрайт в ракурсе 3/4
>>876318
>Ты можешь вращать ее через rotation, а можешь сделать что то вроде $Gun.look_at( get_local_mouse_position() ) - на самом деле чуть сложнее, поскольку надо бы брать позицию мыши из камеры, уже с учетом масштаба и сдвига
У меня сейчас так и сделано. Я не понимаю как сделать так, чтобы один конец рук был всегда привязан к рукоятке оружия, а другие концы рук всегда был привязан к плечам. Было бы проще, если бы руки были одной длины и просто сделать их родительским объектом для оружья, но они у меня разной длины т.к. спрайт в ракурсе 3/4
>>876209
Работает. Чуть чуть все таки пришлось доработать напильником.
Воркфлоу стал побыстрее чем раньше.
1. Подготовить модель, с ригом. Можно с несколькими мешами (одежда, отдельная голова...). Тут же я масштабирую до нужного роста (около 1 метр 80 см) и применяю все трансформы, чтобы потом не возиться. Также переименовываю кости, если у них какие то дурацкие названия. Можно написать простой скрипт, если надо убрать префиксы типа ModelName_Hips
2. Экспортировать в FBX. Чтобы в миксамо видеть текстуры, в блендере надо при экспорте выбрать Copy и нажать рядом иконку коробки (упаковать)
3. Скачать с миксамо нужные анимации. Там есть целые паки, можно и их. В отдельных анимациях, галочку In Place ставить не надо, раз мы хотим Root Motion
4. Закидываем желаемые анимации в папку, туда же кидаем TPose.fbx, переименовываем анимации как нам надо, добавляем -loop если хотим зацикливание (это можно потом при импорте в годоте поменять). Idle я не делаю зацикливание, так как хочу запускать рандомные, а для этого знать когда закончилась анимация.
5. Запускаем скрипт, он создает .glb названный по имени папки. Закидываем в Годот, настраиваем дерево анимаций, любуемся RootMotionView нодой.
6. Почему то часто glb импортирует материалы как прозрачные. Не понял как запретить. Исправляю так - в Годоте дабл клик на glb, открываются опции импорта. Там нажимаю action - export materials. Выбираю .res вместо .tres, иначе создаются какие то неадекватные материалы по 80Мб и сцена грузится полчаса. Все, теперь можно редактировать прозрачность в материалах отдельно.
Работы все равно дальше много, но скрипт позволяет пропустить все ручное прокликивание каждой анимации в блендере.
В чем заключался напильник для скрипта. Почему то все скрипты для миксамо подразумевают, что модель увеличится в 100 раз, поэтому анимацию уменьшают обратно в 100 раз. Но в моем случае с миксамо все скачалось один к одному как я заливал. Поэтому наоборот рут моушн топтался почти на месте. Решение - закомментировать в скрипте строчку которая делает скейл 0.01
Из непонятных технических моментов. Блендер при экспорте glb пишет что запекает анимации, потому что что то там не совпадает в кол-ве кейфреймов. Не знаю плохо ли что он запекает или пофигу. Еще предупреждает, что есть вершины, на которые влияет больше 4 костей (вроде так). Тоже не особо представляю стоит ли париться.
Работает. Чуть чуть все таки пришлось доработать напильником.
Воркфлоу стал побыстрее чем раньше.
1. Подготовить модель, с ригом. Можно с несколькими мешами (одежда, отдельная голова...). Тут же я масштабирую до нужного роста (около 1 метр 80 см) и применяю все трансформы, чтобы потом не возиться. Также переименовываю кости, если у них какие то дурацкие названия. Можно написать простой скрипт, если надо убрать префиксы типа ModelName_Hips
2. Экспортировать в FBX. Чтобы в миксамо видеть текстуры, в блендере надо при экспорте выбрать Copy и нажать рядом иконку коробки (упаковать)
3. Скачать с миксамо нужные анимации. Там есть целые паки, можно и их. В отдельных анимациях, галочку In Place ставить не надо, раз мы хотим Root Motion
4. Закидываем желаемые анимации в папку, туда же кидаем TPose.fbx, переименовываем анимации как нам надо, добавляем -loop если хотим зацикливание (это можно потом при импорте в годоте поменять). Idle я не делаю зацикливание, так как хочу запускать рандомные, а для этого знать когда закончилась анимация.
5. Запускаем скрипт, он создает .glb названный по имени папки. Закидываем в Годот, настраиваем дерево анимаций, любуемся RootMotionView нодой.
6. Почему то часто glb импортирует материалы как прозрачные. Не понял как запретить. Исправляю так - в Годоте дабл клик на glb, открываются опции импорта. Там нажимаю action - export materials. Выбираю .res вместо .tres, иначе создаются какие то неадекватные материалы по 80Мб и сцена грузится полчаса. Все, теперь можно редактировать прозрачность в материалах отдельно.
Работы все равно дальше много, но скрипт позволяет пропустить все ручное прокликивание каждой анимации в блендере.
В чем заключался напильник для скрипта. Почему то все скрипты для миксамо подразумевают, что модель увеличится в 100 раз, поэтому анимацию уменьшают обратно в 100 раз. Но в моем случае с миксамо все скачалось один к одному как я заливал. Поэтому наоборот рут моушн топтался почти на месте. Решение - закомментировать в скрипте строчку которая делает скейл 0.01
Из непонятных технических моментов. Блендер при экспорте glb пишет что запекает анимации, потому что что то там не совпадает в кол-ве кейфреймов. Не знаю плохо ли что он запекает или пофигу. Еще предупреждает, что есть вершины, на которые влияет больше 4 костей (вроде так). Тоже не особо представляю стоит ли париться.
>>876209
Работает. Чуть чуть все таки пришлось доработать напильником.
Воркфлоу стал побыстрее чем раньше.
1. Подготовить модель, с ригом. Можно с несколькими мешами (одежда, отдельная голова...). Тут же я масштабирую до нужного роста (около 1 метр 80 см) и применяю все трансформы, чтобы потом не возиться. Также переименовываю кости, если у них какие то дурацкие названия. Можно написать простой скрипт, если надо убрать префиксы типа ModelName_Hips
2. Экспортировать в FBX. Чтобы в миксамо видеть текстуры, в блендере надо при экспорте выбрать Copy и нажать рядом иконку коробки (упаковать)
3. Скачать с миксамо нужные анимации. Там есть целые паки, можно и их. В отдельных анимациях, галочку In Place ставить не надо, раз мы хотим Root Motion
4. Закидываем желаемые анимации в папку, туда же кидаем TPose.fbx, переименовываем анимации как нам надо, добавляем -loop если хотим зацикливание (это можно потом при импорте в годоте поменять). Idle я не делаю зацикливание, так как хочу запускать рандомные, а для этого знать когда закончилась анимация.
5. Запускаем скрипт, он создает .glb названный по имени папки. Закидываем в Годот, настраиваем дерево анимаций, любуемся RootMotionView нодой.
6. Почему то часто glb импортирует материалы как прозрачные. Не понял как запретить. Исправляю так - в Годоте дабл клик на glb, открываются опции импорта. Там нажимаю action - export materials. Выбираю .res вместо .tres, иначе создаются какие то неадекватные материалы по 80Мб и сцена грузится полчаса. Все, теперь можно редактировать прозрачность в материалах отдельно.
Работы все равно дальше много, но скрипт позволяет пропустить все ручное прокликивание каждой анимации в блендере.
В чем заключался напильник для скрипта. Почему то все скрипты для миксамо подразумевают, что модель увеличится в 100 раз, поэтому анимацию уменьшают обратно в 100 раз. Но в моем случае с миксамо все скачалось один к одному как я заливал. Поэтому наоборот рут моушн топтался почти на месте. Решение - закомментировать в скрипте строчку которая делает скейл 0.01
Из непонятных технических моментов. Блендер при экспорте glb пишет что запекает анимации, потому что что то там не совпадает в кол-ве кейфреймов. Не знаю плохо ли что он запекает или пофигу. Еще предупреждает, что есть вершины, на которые влияет больше 4 костей (вроде так). Тоже не особо представляю стоит ли париться.
Работает. Чуть чуть все таки пришлось доработать напильником.
Воркфлоу стал побыстрее чем раньше.
1. Подготовить модель, с ригом. Можно с несколькими мешами (одежда, отдельная голова...). Тут же я масштабирую до нужного роста (около 1 метр 80 см) и применяю все трансформы, чтобы потом не возиться. Также переименовываю кости, если у них какие то дурацкие названия. Можно написать простой скрипт, если надо убрать префиксы типа ModelName_Hips
2. Экспортировать в FBX. Чтобы в миксамо видеть текстуры, в блендере надо при экспорте выбрать Copy и нажать рядом иконку коробки (упаковать)
3. Скачать с миксамо нужные анимации. Там есть целые паки, можно и их. В отдельных анимациях, галочку In Place ставить не надо, раз мы хотим Root Motion
4. Закидываем желаемые анимации в папку, туда же кидаем TPose.fbx, переименовываем анимации как нам надо, добавляем -loop если хотим зацикливание (это можно потом при импорте в годоте поменять). Idle я не делаю зацикливание, так как хочу запускать рандомные, а для этого знать когда закончилась анимация.
5. Запускаем скрипт, он создает .glb названный по имени папки. Закидываем в Годот, настраиваем дерево анимаций, любуемся RootMotionView нодой.
6. Почему то часто glb импортирует материалы как прозрачные. Не понял как запретить. Исправляю так - в Годоте дабл клик на glb, открываются опции импорта. Там нажимаю action - export materials. Выбираю .res вместо .tres, иначе создаются какие то неадекватные материалы по 80Мб и сцена грузится полчаса. Все, теперь можно редактировать прозрачность в материалах отдельно.
Работы все равно дальше много, но скрипт позволяет пропустить все ручное прокликивание каждой анимации в блендере.
В чем заключался напильник для скрипта. Почему то все скрипты для миксамо подразумевают, что модель увеличится в 100 раз, поэтому анимацию уменьшают обратно в 100 раз. Но в моем случае с миксамо все скачалось один к одному как я заливал. Поэтому наоборот рут моушн топтался почти на месте. Решение - закомментировать в скрипте строчку которая делает скейл 0.01
Из непонятных технических моментов. Блендер при экспорте glb пишет что запекает анимации, потому что что то там не совпадает в кол-ве кейфреймов. Не знаю плохо ли что он запекает или пофигу. Еще предупреждает, что есть вершины, на которые влияет больше 4 костей (вроде так). Тоже не особо представляю стоит ли париться.
>>876326
, но пока без анимации. Ноги и корпус стоят, ходят, бегают, а оружие просто в воздухе вращается
>У меня сейчас так и сделано
, но пока без анимации. Ноги и корпус стоят, ходят, бегают, а оружие просто в воздухе вращается
>>876326
По идее тебе надо что-то вроде 2-chain inverse kinematic
Если я правильно понял твою проблему, что тебе надо чтобы одна рука в локте сгибалась.
По идее тебе надо что-то вроде 2-chain inverse kinematic
Если я правильно понял твою проблему, что тебе надо чтобы одна рука в локте сгибалась.
148 Кб, 1045x725Накатил плагин гита, чтобы не альттабаться, а сразу коммитить с комментарием.
Показывает историю, диффы, измененные файлы. Есть какая то поддержка веток, онлайн реп.
Есть подводный - в истории не стоит кликать на строчку, где было изменение больших бинарей - редактор зависнет надолго считая диффы... Надо будет им ишью завести чтобы был таймаут.
Показывает историю, диффы, измененные файлы. Есть какая то поддержка веток, онлайн реп.
Есть подводный - в истории не стоит кликать на строчку, где было изменение больших бинарей - редактор зависнет надолго считая диффы... Надо будет им ишью завести чтобы был таймаут.
Хочу иметь систему квестов рпг-вида.
Пример - поговорил с одним NPC, он дал квест, после этого в другой локации появился другой NPC с которым надо тоже поговорить.
Первая мысль была примерно такая - иметь реестр квестов, диалогов и NPC.
В реестре NPC записи о том в какой он локации, в каком месте и какой у него сейчас диалог.
В реестре диалогов иметь записи о том какой квест активируется после этого диалога, куда перемещается NPC и какой у него будет следующий диалог
При загрузке локации проверять эти реестры и расставлять NPC согласно записям.
Довольно сложно получается. Есть какие-то способы сделать проще, может я что-то не вижу?
Пример - поговорил с одним NPC, он дал квест, после этого в другой локации появился другой NPC с которым надо тоже поговорить.
Первая мысль была примерно такая - иметь реестр квестов, диалогов и NPC.
В реестре NPC записи о том в какой он локации, в каком месте и какой у него сейчас диалог.
В реестре диалогов иметь записи о том какой квест активируется после этого диалога, куда перемещается NPC и какой у него будет следующий диалог
При загрузке локации проверять эти реестры и расставлять NPC согласно записям.
Довольно сложно получается. Есть какие-то способы сделать проще, может я что-то не вижу?
>>876533
Этапы квестов. Классика эрпогэ, существующая с хуй знает каких лет. Вкратце суть токова.
1. Реестр у тебя один, и называется он - база данных.
2. И в твоей базе данных лежат все квесты всех локаций.
3. И у каждого квеста есть поле "ЭТАП" целого типа, которое по умолчанию = 0
4. И у тебя есть сейвфайл, который организован (любым удобным тебе способом) как модификация основной базы данных. Загрузка сейва - это выполнение модифицирующего скрипта в БД.
5. И в процессе выполнения квеста у него увеличивается значение поля ЭТАП, то есть, меняется по сути этап квеста.
6. И увеличиваться он может не только на 1, а сразу на любое нужное тебе целое число, тем самым пропуская этапы. Так ты реализуешь ветвление событий.
7. А в диалогах у НПЦ у тебя будут закодированы условия появления ветвей диалога в зависимости от существующего этапа квеста. Если этап > 4 но < 7 то показать вот ту ветку.
8. И при загрузке локаций ты сможешь чекать этапы квестов и выполнять нужные действия, расставлять фурнитуру и НПЦ. Вплоть до того, что в менеджере загрузки локаций, ты сможешь чекать этапы связанных квестов и выбирать, какую из версий локации грузить в данный момент. День, ночь, война, пожар, руины, прошлое, будущее, иное измерение, и всё что пожелаешь.
А кто-то обещал, что будет легко? Эрпогэ - вершина геймдева. А Геймдев - вершина айти. Самая простая игра сложнее самого навороченного КРУДа. Самая простая эрпогэ сложнее самых навороченных кликеров.
Мне удивительно видеть, как люди без опыта в айти лезут в геймдев.
> Есть какие-то способы сделать проще, может я что-то не вижу?
Этапы квестов. Классика эрпогэ, существующая с хуй знает каких лет. Вкратце суть токова.
1. Реестр у тебя один, и называется он - база данных.
2. И в твоей базе данных лежат все квесты всех локаций.
3. И у каждого квеста есть поле "ЭТАП" целого типа, которое по умолчанию = 0
4. И у тебя есть сейвфайл, который организован (любым удобным тебе способом) как модификация основной базы данных. Загрузка сейва - это выполнение модифицирующего скрипта в БД.
5. И в процессе выполнения квеста у него увеличивается значение поля ЭТАП, то есть, меняется по сути этап квеста.
6. И увеличиваться он может не только на 1, а сразу на любое нужное тебе целое число, тем самым пропуская этапы. Так ты реализуешь ветвление событий.
7. А в диалогах у НПЦ у тебя будут закодированы условия появления ветвей диалога в зависимости от существующего этапа квеста. Если этап > 4 но < 7 то показать вот ту ветку.
8. И при загрузке локаций ты сможешь чекать этапы квестов и выполнять нужные действия, расставлять фурнитуру и НПЦ. Вплоть до того, что в менеджере загрузки локаций, ты сможешь чекать этапы связанных квестов и выбирать, какую из версий локации грузить в данный момент. День, ночь, война, пожар, руины, прошлое, будущее, иное измерение, и всё что пожелаешь.
> Довольно сложно получается.
А кто-то обещал, что будет легко? Эрпогэ - вершина геймдева. А Геймдев - вершина айти. Самая простая игра сложнее самого навороченного КРУДа. Самая простая эрпогэ сложнее самых навороченных кликеров.
Мне удивительно видеть, как люди без опыта в айти лезут в геймдев.
>>876533
Я пока глубоко систему квестов не продумывал. Но имхо это иерархический конечный автомат. Обычно вырожденный, потому что квесты обычно простые - 1. выйди за забор 2. убей 5 волков. Рестарты и повторяемые для простоты не рассматриваем. Иерархический - потому что сами квесты объединены в цепочки. После выполнения квеста 1 можно брать квест 2. Да, там могут быть графы посложнее. Например если взял квест за красных, за синих уже не можешь.
Может быть, можно обойтись событиями. Например, когда ты завершил квест, посылается событие, и оно спавнит следующего непися. Сами неписи, в таком случае, мне кажется, являются тупыми объектами наподобие кнопок. Да у них есть примитивные состояния, типа позиции на карте, которые могут быть связаны с системой сохранения. Но сами они не отслеживают состояние квеста. Пример - в какой нибудь ММО непись стоит в одном месте, но в разговоре с каждым игроком он говорит с ним лично на основе состояния игрока. Один еще только берет квест, другой уже сдает. (Опять же пропустим сложные случаи, когда непись перемещается между фазами квеста или игрок присоединился посередине рейда - это все можно продумать).
В общем, имхо, ничего особо сложного, инкапсуляция, каждый делает свою маленькую часть работы и все.
Я пока глубоко систему квестов не продумывал. Но имхо это иерархический конечный автомат. Обычно вырожденный, потому что квесты обычно простые - 1. выйди за забор 2. убей 5 волков. Рестарты и повторяемые для простоты не рассматриваем. Иерархический - потому что сами квесты объединены в цепочки. После выполнения квеста 1 можно брать квест 2. Да, там могут быть графы посложнее. Например если взял квест за красных, за синих уже не можешь.
Может быть, можно обойтись событиями. Например, когда ты завершил квест, посылается событие, и оно спавнит следующего непися. Сами неписи, в таком случае, мне кажется, являются тупыми объектами наподобие кнопок. Да у них есть примитивные состояния, типа позиции на карте, которые могут быть связаны с системой сохранения. Но сами они не отслеживают состояние квеста. Пример - в какой нибудь ММО непись стоит в одном месте, но в разговоре с каждым игроком он говорит с ним лично на основе состояния игрока. Один еще только берет квест, другой уже сдает. (Опять же пропустим сложные случаи, когда непись перемещается между фазами квеста или игрок присоединился посередине рейда - это все можно продумать).
В общем, имхо, ничего особо сложного, инкапсуляция, каждый делает свою маленькую часть работы и все.
>>876533
То есть вот это я бы изменил:
Ок
Это перенес бы в состояние квеста у игрока.
То есть вот это я бы изменил:
>В реестре NPC записи о том в какой он локации, в каком месте
Ок
>и какой у него сейчас диалог.
Это перенес бы в состояние квеста у игрока.
>>876595
Вообще мне нравится идея с графом состояний. Похоже на вот эту >>876566 систему с этапами
Есть начальный узел - это начало игры, и несколько конченых, по одному на каждый квест.
Между ними - множество узлов событий, они по умолчанию неактивны.
И есть несколько указателей, каждый указатель движется от начала к концам по узлам событий.
Узлы по умолчанию неактивны, разблокируются по событиям. Допустим ты нашел нужный предмет, инвентарь сообщает что предмет найден и следующий узел открывается. Или в конце диалога открывается следующий узел.
Узлы имеют типы - например:
- позиция NPC, при прохождени этого узла NPC перемещается в нужную локацию
- диалог NPC - это узел устанавливает NPC нужный диалог.
- квестовый узел добавляет или убирает в журнал квестов запись
тут много чего можно придумать.
Мне кажется с такой системой можно делать РПГ масштаба скайрима.
Вообще мне нравится идея с графом состояний. Похоже на вот эту >>876566 систему с этапами
Есть начальный узел - это начало игры, и несколько конченых, по одному на каждый квест.
Между ними - множество узлов событий, они по умолчанию неактивны.
И есть несколько указателей, каждый указатель движется от начала к концам по узлам событий.
Узлы по умолчанию неактивны, разблокируются по событиям. Допустим ты нашел нужный предмет, инвентарь сообщает что предмет найден и следующий узел открывается. Или в конце диалога открывается следующий узел.
Узлы имеют типы - например:
- позиция NPC, при прохождени этого узла NPC перемещается в нужную локацию
- диалог NPC - это узел устанавливает NPC нужный диалог.
- квестовый узел добавляет или убирает в журнал квестов запись
тут много чего можно придумать.
Мне кажется с такой системой можно делать РПГ масштаба скайрима.
Котаны, в чем суть использовать годот вместо условного юнити? Кроме слово опенсорс? Проще пилить проекты или что?
>>876647
Это вопрос исключительно субьективного удобства. Что нравится, тем и пользуйся. Для остального есть тред движкосрача.
>>876642
Братан, братишка, браток. Как ты ни накручивай слои абстракций, в итоге у тебя на диске будет лежать плоский список, в котором всё будет сведено к индексированным записям. Так нахуя тогда накручивать слои абстракций? Ты только запутаешься в них. Система этапов не просто так является бессмертной классикой, потому что лучше нее ничего не придумаешь, и всё что ты можешь придумать, в конечном итоге сведётся к системе этапов. Все твои вот эти графы состояний превратятся в ту же самую таблицу. Но при этом, при саппорте этой системы, тебе придется переводить плоские данные в графы с узлами и переходами, а потом снова графы с узлами и переходами переводить в плоские данные. Впрочем, похуй же как делать, главное, чтобы тебе было удобно. Именно поэтому я не люблю аддоны и ассеты. Они сделаны так, что их авторам они удобны. Но это не гарантия что это удобно мне.
Это вопрос исключительно субьективного удобства. Что нравится, тем и пользуйся. Для остального есть тред движкосрача.
>>876642
> идея с графом состояний
> множество узлов событий
> несколько указателей
> Узлы по умолчанию неактивны, разблокируются по событиям.
Братан, братишка, браток. Как ты ни накручивай слои абстракций, в итоге у тебя на диске будет лежать плоский список, в котором всё будет сведено к индексированным записям. Так нахуя тогда накручивать слои абстракций? Ты только запутаешься в них. Система этапов не просто так является бессмертной классикой, потому что лучше нее ничего не придумаешь, и всё что ты можешь придумать, в конечном итоге сведётся к системе этапов. Все твои вот эти графы состояний превратятся в ту же самую таблицу. Но при этом, при саппорте этой системы, тебе придется переводить плоские данные в графы с узлами и переходами, а потом снова графы с узлами и переходами переводить в плоские данные. Впрочем, похуй же как делать, главное, чтобы тебе было удобно. Именно поэтому я не люблю аддоны и ассеты. Они сделаны так, что их авторам они удобны. Но это не гарантия что это удобно мне.
>>876673
Потому что человеку удобнее работать с абстракциями, а не непойми каким плоским списком. Вот пусть на диске хоть ассемблер лежит, пишем то мы не на нем.
Простой пример - ты захотел вставить в первый квест дополнительную задачу. В случае графа, ты просто добавил и оно само пересчитается. В случае своего плоского списка, ты или сдвинул все последующие числа, сломав старые сейвы, или начал добавлять в конец, в результате у тебя уже не плоский список, а 1, 2, 1488. 3, 4. Что в итоге приведет к костылям, если ты где то проверял if quest < 5
>Как ты ни накручивай слои абстракций, в итоге у тебя на диске будет лежать плоский список, в котором всё будет сведено к индексированным записям. Так нахуя тогда накручивать слои абстракций?
Потому что человеку удобнее работать с абстракциями, а не непойми каким плоским списком. Вот пусть на диске хоть ассемблер лежит, пишем то мы не на нем.
Простой пример - ты захотел вставить в первый квест дополнительную задачу. В случае графа, ты просто добавил и оно само пересчитается. В случае своего плоского списка, ты или сдвинул все последующие числа, сломав старые сейвы, или начал добавлять в конец, в результате у тебя уже не плоский список, а 1, 2, 1488. 3, 4. Что в итоге приведет к костылям, если ты где то проверял if quest < 5
>>876647
Без понятия, бро, я не пользуюсь другими движками. Ты бы еще спросил, почему я с линукса на винду возвращаться на собираюсь, или почему пользуюсь блендером.
Без понятия, бро, я не пользуюсь другими движками. Ты бы еще спросил, почему я с линукса на винду возвращаться на собираюсь, или почему пользуюсь блендером.
Супертупой нюфаговопрос. Как там вообще делать адаптивный дизайн-то? Есть какие-то гайды (на 4.1 или те, что не устарели)? Я методом тыка пытаюсь разобраться и нихуя не справляюсь, это просто отвратительно. Где там вообще процентные значения, например? Я могу сделать часть интерфейса в 70% от высоты экрана?
185 Кб, 817x457>>876764
Да.
Я немного знаком с вёрсткой хтмл и легко пилил адаптивные в трёшке, поскольку оно там сделано по образу и подобию хтмл. Сейчас в четверке не касался этого вопроса. Но процентное соотношение там есть точно.
> Я могу сделать часть интерфейса в 70% от высоты экрана?
Да.
> Есть какие-то гайды (на 4.1 или те, что не устарели)?
Я немного знаком с вёрсткой хтмл и легко пилил адаптивные в трёшке, поскольку оно там сделано по образу и подобию хтмл. Сейчас в четверке не касался этого вопроса. Но процентное соотношение там есть точно.
>>876766
Там все довольно просто
Пик 1 - корневой контрол Full Rect занимает весь экран
Пик 2 - контрол с custom anchor, как раз и означает в процентах - 0 это край, 1 это дргой край, 0.2 это 20 процентов и тд
Пик 3 - контрол с custom anchor и anchor offsets, то есть когда относительно процентов еще и margin в пикселях
Пик 4 - это уже с контейнерами, контейнер сам расположен на 10 процентах, и растягивает контрол в него под это.
Там все довольно просто
Пик 1 - корневой контрол Full Rect занимает весь экран
Пик 2 - контрол с custom anchor, как раз и означает в процентах - 0 это край, 1 это дргой край, 0.2 это 20 процентов и тд
Пик 3 - контрол с custom anchor и anchor offsets, то есть когда относительно процентов еще и margin в пикселях
Пик 4 - это уже с контейнерами, контейнер сам расположен на 10 процентах, и растягивает контрол в него под это.
>>876770
Кроме этого есть всякие контейнеры в которые уже по какой то логике набиваются дети, например grid container, horizontal box, vertical box, их можно вкладывать друг в друга, сейчас вроде бы есть и flow
Контейнер управляет лейаутом детей, но дети могут указывать как они хотят размещаться в контейнере, полями container sizing; fill или shrink, а также галочкой expand. В таком случае параметр Stretch будет уже задавать пропорции между такими элементами. На пик 2 - пропорции 3-2-1.
Кроме этого есть всякие контейнеры в которые уже по какой то логике набиваются дети, например grid container, horizontal box, vertical box, их можно вкладывать друг в друга, сейчас вроде бы есть и flow
Контейнер управляет лейаутом детей, но дети могут указывать как они хотят размещаться в контейнере, полями container sizing; fill или shrink, а также галочкой expand. В таком случае параметр Stretch будет уже задавать пропорции между такими элементами. На пик 2 - пропорции 3-2-1.
44 Кб, 1188x258>>876772
>>876773
Не за что. Нюансов все равно много остается, я всех комбинаций не знаю, но база простая. Еще какие то настройки бывают не в настройках контейнеров, а в настройках темы, например отступ между элементами контейнера. Вот их похоже в процентах не задать. Но наверное можно из скрипта как то получить общий размер контейнера и высчитать. Будем считать это продвинутой темой.
>>876773
Не за что. Нюансов все равно много остается, я всех комбинаций не знаю, но база простая. Еще какие то настройки бывают не в настройках контейнеров, а в настройках темы, например отступ между элементами контейнера. Вот их похоже в процентах не задать. Но наверное можно из скрипта как то получить общий размер контейнера и высчитать. Будем считать это продвинутой темой.
>>876771
Тут я забыл написать текстом, что есть margin container он используется чисто для отступа в дереве контролов, то есть даже если у ваших контролов нет возможности явно задать отступ, можно всегда обрамить это в margin.
Тут я забыл написать текстом, что есть margin container он используется чисто для отступа в дереве контролов, то есть даже если у ваших контролов нет возможности явно задать отступ, можно всегда обрамить это в margin.
216 Кб, 1080x536>>874870
На просторах гитхаба замечен такой проект Godot-Dodo
https://github.com/minosvasilias/godot-dodo
Процесс обучения описан так: с гитхаба спарсены проекты под MIT лицензией, потом чатугпт 3.5 турбо задавался вопрос что делает каждая функция.
В репе есть ссылка на веса, как я понимаю, надо их скачать, установить пререквезиты для питона и запустить eval.py В нем уже содержаться подобные тестовые запросы
'Listen to WASD user input and move current node accordingly.',
'Apply a new metallic spatial material with a red albedo color.',
'Create a raycast and cast from active camera to current node. Return ray collisions.'
В описании сказано что модель дожна лучше писать на гдскрипте, но хуже понимает более высокоуровневые запросы
Тестите, я сам с картофелины.
На просторах гитхаба замечен такой проект Godot-Dodo
https://github.com/minosvasilias/godot-dodo
Процесс обучения описан так: с гитхаба спарсены проекты под MIT лицензией, потом чатугпт 3.5 турбо задавался вопрос что делает каждая функция.
В репе есть ссылка на веса, как я понимаю, надо их скачать, установить пререквезиты для питона и запустить eval.py В нем уже содержаться подобные тестовые запросы
'Listen to WASD user input and move current node accordingly.',
'Apply a new metallic spatial material with a red albedo color.',
'Create a raycast and cast from active camera to current node. Return ray collisions.'
В описании сказано что модель дожна лучше писать на гдскрипте, но хуже понимает более высокоуровневые запросы
Тестите, я сам с картофелины.
>>876996
Я предпочитаю LTS. Впрочем... Все равно нихуя не делаю, так что можно и попробовать.
Я предпочитаю LTS. Впрочем... Все равно нихуя не делаю, так что можно и попробовать.
8 Кб, 200x252>>876997
Делой!
Делой!
Годаны, помогите с шейдерами.
Имеется аниматед_сприте, все кадры анимации берутся из одной картинки. Или не аниматед, а просто спрайт с одной картинкой. Итоговый результат должен одинаково себя вести и с тем, и с другим.
Имеется канваситем-шейдер. Суть в трёх строках:
vec4 color = texture(TEXTURE, UV)
vec4 new_color = texture(my_uniform_sampler2D, UV)
COLOR = vec4(new_color.rgb, color.a)
То есть, простейшая штука. Скормить шейдеру текстуру и заменять на неё всё, что не прозрачное.
Но собака порылась в деталях. А именно - в анимации. Точнее, в атласах, как я понял. Для шейдера разные кадры анимации - это разные места на одной текстуре. С разным UV, соответственно. И из этого вытекают две проблемы:
1. Наложенная текстура растягивается на весь атлас, а не на выбранный кадр.
2. При проигрывании анимации анимируется и наложенная текстура.
Да, я могу подогнать шейдер под конкретный спрайт. Но у меня тут ареа должна автоматически вешать свой материал на любого кинематика или ригида, который в неё зайдёт, так что надо найти какое-то общее решение. Можно как-то скормить шейдеру то, что фактически отрисовывается, а не исходную картинку? Или ещё какие варианты решения есть?
Имеется аниматед_сприте, все кадры анимации берутся из одной картинки. Или не аниматед, а просто спрайт с одной картинкой. Итоговый результат должен одинаково себя вести и с тем, и с другим.
Имеется канваситем-шейдер. Суть в трёх строках:
vec4 color = texture(TEXTURE, UV)
vec4 new_color = texture(my_uniform_sampler2D, UV)
COLOR = vec4(new_color.rgb, color.a)
То есть, простейшая штука. Скормить шейдеру текстуру и заменять на неё всё, что не прозрачное.
Но собака порылась в деталях. А именно - в анимации. Точнее, в атласах, как я понял. Для шейдера разные кадры анимации - это разные места на одной текстуре. С разным UV, соответственно. И из этого вытекают две проблемы:
1. Наложенная текстура растягивается на весь атлас, а не на выбранный кадр.
2. При проигрывании анимации анимируется и наложенная текстура.
Да, я могу подогнать шейдер под конкретный спрайт. Но у меня тут ареа должна автоматически вешать свой материал на любого кинематика или ригида, который в неё зайдёт, так что надо найти какое-то общее решение. Можно как-то скормить шейдеру то, что фактически отрисовывается, а не исходную картинку? Или ещё какие варианты решения есть?
Так, я заебался. Как мне скруглить углы любого блока? Вот я сделал панель, настроил обводку и скруглениями, включил clip_contents и добавил TextureRect в потомки. Так какого хуя углы просвечивают? Пробовал тему панели копировать на саму текстуру - никак не реагирует. Блжад, почему нельзя просто прописать бордер-радиус: 8 и бордер: 1пкс солид вайт элементу, а надо обязательно ебаться. Почему в годоте ебаном нельзя без гайдов даже такую мелочь сделать? Я не хочу сидеть в фотошопе и каждую иконку делать со скруглениями и обводкой, а потом переделывать их всех, если мне не понравится мой дизайн.
46 Кб, 299x168>>877013
Сегодня бегаю весь день, так что сам попробовать и показать не смогу.
Вариант 1 - nine patch rect. Там фишка в том, что рисуешь одну кнопку со скругленными углами, но растягиваешь ее рамку на нужное расстояние, углы при этом не масштабируя. Это контрол, со всеми вытекающими, но можно и для игровых объектов приспособить
Вариант 2. Пишут что есть ресурс StyleBoxFlat и у него Corner Raduys. не пробовал.
https://godotengine.org/qa/132106/how-to-create-rounded-ui-elements
Сегодня бегаю весь день, так что сам попробовать и показать не смогу.
Вариант 1 - nine patch rect. Там фишка в том, что рисуешь одну кнопку со скругленными углами, но растягиваешь ее рамку на нужное расстояние, углы при этом не масштабируя. Это контрол, со всеми вытекающими, но можно и для игровых объектов приспособить
Вариант 2. Пишут что есть ресурс StyleBoxFlat и у него Corner Raduys. не пробовал.
https://godotengine.org/qa/132106/how-to-create-rounded-ui-elements
>>877013
Не исключаю что у тебя проблема в чем то другом, типа панель не использует какие то настройки темы. Тогда надо придумывать что то свое. Например использовать ту же кнопку только ненажимаемую для визуала панели. Годот - игровой движок, то есть в первую очередь это когда всякие спрайтики бегают и стреляют, а не инструмент иллюстратора в котором скопировано все что только бывает в хтмл.
Не исключаю что у тебя проблема в чем то другом, типа панель не использует какие то настройки темы. Тогда надо придумывать что то свое. Например использовать ту же кнопку только ненажимаемую для визуала панели. Годот - игровой движок, то есть в первую очередь это когда всякие спрайтики бегают и стреляют, а не инструмент иллюстратора в котором скопировано все что только бывает в хтмл.
>>877012
Самое прямолинейное решение - UV надо умножать (или делить) на количество строк и колонок в атласе. Для этого можно завести uniform переменные в шейдере и выставлять их напимер из гдскрипта, взяв данные о твоем анимспрайте. Почитай тут например.
https://www.reddit.com/r/godot/comments/w3rhzy/shaders_for_animated_sprites_using_spritesheets/
Самое прямолинейное решение - UV надо умножать (или делить) на количество строк и колонок в атласе. Для этого можно завести uniform переменные в шейдере и выставлять их напимер из гдскрипта, взяв данные о твоем анимспрайте. Почитай тут например.
https://www.reddit.com/r/godot/comments/w3rhzy/shaders_for_animated_sprites_using_spritesheets/
>>877042
Еще запасные идеи
Вариант 3. Рисовать SVG
Вариант 4. Шейдер рисующий любые линии, скругления.
Еще запасные идеи
Вариант 3. Рисовать SVG
Вариант 4. Шейдер рисующий любые линии, скругления.
>>877045
Но я не знаю количество строк и колонок в атласе. Я вешаю шейдер на рандомный спрайт, у которого даже своего скрипта нет.
Может, можно было бы в скрипте-вешалке прописать, чтобы он выковыривал эти данные из АниматедСприте. Но я не нашёл в доках способа сделать это. Можно вытащить текстуру конкретного кадра, делать это по сигналу frame_changed.
Ов щи, пока писал, придумал. Можно узнать размер текстуры кадра, скормить его шейдеру; а шейдер знает размер текстуры атласа. Костыльно, но должно сработать. Не поможет, если анимация будет использовать более одно атласа, но у меня таких нет и, видимо, теперь уже не будет.
Но я не знаю количество строк и колонок в атласе. Я вешаю шейдер на рандомный спрайт, у которого даже своего скрипта нет.
Может, можно было бы в скрипте-вешалке прописать, чтобы он выковыривал эти данные из АниматедСприте. Но я не нашёл в доках способа сделать это. Можно вытащить текстуру конкретного кадра, делать это по сигналу frame_changed.
Ов щи, пока писал, придумал. Можно узнать размер текстуры кадра, скормить его шейдеру; а шейдер знает размер текстуры атласа. Костыльно, но должно сработать. Не поможет, если анимация будет использовать более одно атласа, но у меня таких нет и, видимо, теперь уже не будет.
63 Кб, 864x522>>877133
Ты прав, я перепутал с просто спрайтом, которого есть vframes и hframes. Уже не помню почему, отговаривали исползовать AnimatedSprite, в пользу AnimationPlayer.
Что касается AnimatedSprite, сейчас проверил, он возвращает SpriteFrames, у которого есть AtlasTexture, у которого можно получить region указанного кадра указанной анимации.
Думаю этого достаточно чтобы составлять автоматически каталог для всех спрайтов в твоей игре.
Ты прав, я перепутал с просто спрайтом, которого есть vframes и hframes. Уже не помню почему, отговаривали исползовать AnimatedSprite, в пользу AnimationPlayer.
Что касается AnimatedSprite, сейчас проверил, он возвращает SpriteFrames, у которого есть AtlasTexture, у которого можно получить region указанного кадра указанной анимации.
Думаю этого достаточно чтобы составлять автоматически каталог для всех спрайтов в твоей игре.
>>877142
О, не знал, потому что в доках написано:
И прежде я уже юзал эту функцию, чтобы автоматически отрисовывать персонажа в инвентаре, и не догадывался, что там атлас.
Нушош, тогда вопрос решён.
>SpriteFrames, у которого есть AtlasTexture
О, не знал, потому что в доках написано:
>Texture get_frame ( String anim, int idx ) const
И прежде я уже юзал эту функцию, чтобы автоматически отрисовывать персонажа в инвентаре, и не догадывался, что там атлас.
Нушош, тогда вопрос решён.
>>877154
Там, наверное, не всегда атлас, есть же другой режим когда просто картинки накидываешь по одной. Но это тоже можно проверять.
Там, наверное, не всегда атлас, есть же другой режим когда просто картинки накидываешь по одной. Но это тоже можно проверять.
>>877142
Я напомню.
АниматедСпрайт нужен для одноразовых задач, например, сделать крутящуюся иконку сохранения, включать и выключать ей видимость, когда надо. Если нужно комплексно работать с анимациями, для этого создан универсальный АнимаПлеер, который хоть 2дспрайтами жонглирует, хоть 3дмешами, и состыкуется с универсальным АнимаТрии для создания стейтмашин.
Но на практике никто не мешает, конечно же юзать и АнимаСпрайт.
> Уже не помню почему, отговаривали исползовать AnimatedSprite
Я напомню.
АниматедСпрайт нужен для одноразовых задач, например, сделать крутящуюся иконку сохранения, включать и выключать ей видимость, когда надо. Если нужно комплексно работать с анимациями, для этого создан универсальный АнимаПлеер, который хоть 2дспрайтами жонглирует, хоть 3дмешами, и состыкуется с универсальным АнимаТрии для создания стейтмашин.
Но на практике никто не мешает, конечно же юзать и АнимаСпрайт.
>>877165
Анимаспрайт удобен для пикселярта, когда все анимации исключительно спрайтовые и нет никаких плавных переходов. И его очень удобно совмещать с анимаплеером и анимадеревом. Хотя, в общем-то, никто не запрещает вместо переключения кадров юзать регион в обычном спрайте.
Анимаспрайт удобен для пикселярта, когда все анимации исключительно спрайтовые и нет никаких плавных переходов. И его очень удобно совмещать с анимаплеером и анимадеревом. Хотя, в общем-то, никто не запрещает вместо переключения кадров юзать регион в обычном спрайте.
Лучший в мире инвентарь переехал на четвёрку
https://www.youtube.com/watch?v=G8upcX3MrR8
https://www.youtube.com/watch?v=G8upcX3MrR8
Вопрос знатокам. У меня есть несколько нод, у которых отрисовка детей зависит от собственного состояния. Ну например: у предмета есть енум-свойство А, и все его дочерние картинки играют одну и ту же анимацию или флипаются в зависимости от выбора этого свойства. Для этого я использую:
1. Простые сеттеры свойств, в них по две строчки: задание свойства-переменной и вызов редрав_май_обжект()
2. Функ _реади() и в нём вызов редрав_май_обжект()
3. Ну и собсно редрав_май_обжект(), который собирает вместе все нужные параметры и задаёт свойства детям.
Я вот думаю. Целесообразнее ли вместо этого заюзать виртуальный метод _draw() ? Или он вызывается каждый кадр, так что пихать туда гдскрипт плохая идея? Или есть общепринятый какой-то другой метод, которого я не знаю?
1. Простые сеттеры свойств, в них по две строчки: задание свойства-переменной и вызов редрав_май_обжект()
2. Функ _реади() и в нём вызов редрав_май_обжект()
3. Ну и собсно редрав_май_обжект(), который собирает вместе все нужные параметры и задаёт свойства детям.
Я вот думаю. Целесообразнее ли вместо этого заюзать виртуальный метод _draw() ? Или он вызывается каждый кадр, так что пихать туда гдскрипт плохая идея? Или есть общепринятый какой-то другой метод, которого я не знаю?
>>877403
Не очень понял твою терминологию. Дочерними/детьми и родительскими называют положение в дереве нод, а дальше ты говоришь про виртуальный метод. Может ты имел в виду наследованные и базовые?
Когда вызывается метод draw написано в документации.
Updating¶
The _draw() function is only called once, and then the draw commands are cached and remembered, so further calls are unnecessary.
If re-drawing is required because a state or something else changed, call CanvasItem.queue_redraw() in that same node and a new _draw() call will happen.
Стоит ли привязывать к нему логику - не уверен. Все таки мне кажется ты описываешь больше логику, а не отрисовку. Под отрисовкой там имеется в виду нарисовать линию, кружочек.
Не очень понял твою терминологию. Дочерними/детьми и родительскими называют положение в дереве нод, а дальше ты говоришь про виртуальный метод. Может ты имел в виду наследованные и базовые?
Когда вызывается метод draw написано в документации.
Updating¶
The _draw() function is only called once, and then the draw commands are cached and remembered, so further calls are unnecessary.
If re-drawing is required because a state or something else changed, call CanvasItem.queue_redraw() in that same node and a new _draw() call will happen.
Стоит ли привязывать к нему логику - не уверен. Все таки мне кажется ты описываешь больше логику, а не отрисовку. Под отрисовкой там имеется в виду нарисовать линию, кружочек.
Есть хоть одна успешная (ну или хотя-бы играбельная) 3D игра на нём? С графикой лучше чем абстрактные кубики в качестве фона для лоуполи шариков? Или фактически оно только для 2d игр, а поддержка 3д это так для галочки?
>>877469
Cruelty squad, еще какой-то забагованный ремейк Соника, хотя они все такие независимо от движка. Вообще такой вопрос сейчас не особо актуален, в 4.0 3D абсолютно другое, но естественно с момента релиза еще не прошло достаточно времени, чтобы на нем успели сделать что-то крутое.
Cruelty squad, еще какой-то забагованный ремейк Соника, хотя они все такие независимо от движка. Вообще такой вопрос сейчас не особо актуален, в 4.0 3D абсолютно другое, но естественно с момента релиза еще не прошло достаточно времени, чтобы на нем успели сделать что-то крутое.
>>877469
Естественно, та же Human Diaspora, но разраб психанул от неуспеха и удалил все видосы с ней с реддита и ютуба, а мне лень искать их на компе сохраненку.
А вообще то любой может скачать разные демки и оценить возможности рендера
https://github.com/perfoon/Abandoned-Spaceship-Godot-Demo
https://github.com/mikatomik/Godot-4-Overgrown-Subway-Demo
https://github.com/gdquest-demos/godot-4-3d-third-person-controller
Это демки на 4-ке
>а поддержка 3д это так для галочки?
Всегда нормальная поддержка была. Вот типичная игра с какого то мелкого джема.
Не забагованый. Там специально стримеры по 100 раз дрочили сейв пока память не утекала. У нормальных игроков в тот же день уже летсплеи целиком игры без пробелем были.
>или хотя-бы играбельная) 3D игра
>С графикой лучше чем абстрактные кубики
Естественно, та же Human Diaspora, но разраб психанул от неуспеха и удалил все видосы с ней с реддита и ютуба, а мне лень искать их на компе сохраненку.
А вообще то любой может скачать разные демки и оценить возможности рендера
https://github.com/perfoon/Abandoned-Spaceship-Godot-Demo
https://github.com/mikatomik/Godot-4-Overgrown-Subway-Demo
https://github.com/gdquest-demos/godot-4-3d-third-person-controller
Это демки на 4-ке
>а поддержка 3д это так для галочки?
Всегда нормальная поддержка была. Вот типичная игра с какого то мелкого джема.
>какой-то забагованный ремейк Соника
Не забагованый. Там специально стримеры по 100 раз дрочили сейв пока память не утекала. У нормальных игроков в тот же день уже летсплеи целиком игры без пробелем были.
Закину в переводчик и посмотрю. Го со мной!
https://www.youtube.com/watch?v=s9AO18j1cyE
https://www.youtube.com/watch?v=s9AO18j1cyE
>>877429
Ну да, про это и речь.
Сейчас в родителе три функции, которые так или иначе влияют на отрисовку детей. А я спрашиваю, не лучше ли все их запихнуть в один _драв().
Хз, где это написано, вот тут такого нет:
https://docs.godotengine.org/en/3.5/classes/class_canvasitem.html#class-canvasitem-method-draw
Исключительно отрисовку.
Но если _драв() всё равно надо вызывать вручную, то лучше оставлю как есть.
>Дочерними/детьми и родительскими называют положение в дереве нод
Ну да, про это и речь.
Сейчас в родителе три функции, которые так или иначе влияют на отрисовку детей. А я спрашиваю, не лучше ли все их запихнуть в один _драв().
>Когда вызывается метод draw написано в документации
Хз, где это написано, вот тут такого нет:
https://docs.godotengine.org/en/3.5/classes/class_canvasitem.html#class-canvasitem-method-draw
>Все таки мне кажется ты описываешь больше логику, а не отрисовку.
Исключительно отрисовку.
Но если _драв() всё равно надо вызывать вручную, то лучше оставлю как есть.
>>877539
там есть ссылка на Custom drawing in 2d
там есть ссылка на Custom drawing in 2d
>>877487
Демки не в счёт таккак это фактически реклама. То есть вопрос должен звучать так: Действительно ли можно использовать движок для создания жизнеспособной игры с не нулевой графикой, или он годится только для демок и прототипов которым ясно дело такая производительность не требуется
Демки не в счёт таккак это фактически реклама. То есть вопрос должен звучать так: Действительно ли можно использовать движок для создания жизнеспособной игры с не нулевой графикой, или он годится только для демок и прототипов которым ясно дело такая производительность не требуется
>>877548
Движкосрачер уходи
Движкосрачер уходи
>>877548
Странная переформулировка, ну на этот вопрос ответ да.
Это какая еще такая? Производительность в основном зависит от постпроцессинга (врубаю всякие шейдеры и падает с 120 до 60, да и вообще некоторые эффекты требуют второго вьюпорта с дублированием прорисовки), от очень больших текстур (запускал на некроПК,накидав много ассетов с 4к текстурами - вот тогда начинаются затыки, потому что приходится из памяти в видляху постоянно свопать - поменял на 512 и все летает), к тому же имеет смысл объединять текстуры в тримшиты. В третьих все эти динамические освещения - GI, voxel, Reflection probes, объемный туман и так далее.
И как можно заметить, все эти три пункта надо выносить в настройки, тогда внезапно на слабом компе можно понизить качество картинки и производительность вырастет, кто бы мог подумать.
Еще проблема может быть если пытаться тупо столкнуть кучу физических объектов (если например делать всех неписей физическими телами и они окажутся во взаимодейтсвии через какой нибудь Area все со всеми). Это решается тем что они должны ходить упрощенными методами - например навигацией, которая еще и пересчитывается не каждый кадр.
Демки, блджад, это демки. Они нужны для того чтобы проверить как что работает из коробки и что можно поменять и сколько всего потянет твой комп.
>То есть вопрос должен звучать так: Действительно ли можно использовать движок для создания жизнеспособной игры с не нулевой графикой,
Странная переформулировка, ну на этот вопрос ответ да.
> такая производительность
Это какая еще такая? Производительность в основном зависит от постпроцессинга (врубаю всякие шейдеры и падает с 120 до 60, да и вообще некоторые эффекты требуют второго вьюпорта с дублированием прорисовки), от очень больших текстур (запускал на некроПК,накидав много ассетов с 4к текстурами - вот тогда начинаются затыки, потому что приходится из памяти в видляху постоянно свопать - поменял на 512 и все летает), к тому же имеет смысл объединять текстуры в тримшиты. В третьих все эти динамические освещения - GI, voxel, Reflection probes, объемный туман и так далее.
И как можно заметить, все эти три пункта надо выносить в настройки, тогда внезапно на слабом компе можно понизить качество картинки и производительность вырастет, кто бы мог подумать.
Еще проблема может быть если пытаться тупо столкнуть кучу физических объектов (если например делать всех неписей физическими телами и они окажутся во взаимодейтсвии через какой нибудь Area все со всеми). Это решается тем что они должны ходить упрощенными методами - например навигацией, которая еще и пересчитывается не каждый кадр.
>Демки не в счёт таккак это фактически реклама
Демки, блджад, это демки. Они нужны для того чтобы проверить как что работает из коробки и что можно поменять и сколько всего потянет твой комп.
>>873235 (OP)
Делаю генератор карт (https://www.redblobgames.com/x/2022-voronoi-maps-tutorial/) и к генератору пишу некоторое подобие эмулятора цивилизаций (https://drtardigrade.itch.io/worldhistorysim):
https://gitlab.com/liaten/godot_map_course_work
Скрины приложил
Делаю генератор карт (https://www.redblobgames.com/x/2022-voronoi-maps-tutorial/) и к генератору пишу некоторое подобие эмулятора цивилизаций (https://drtardigrade.itch.io/worldhistorysim):
https://gitlab.com/liaten/godot_map_course_work
Скрины приложил
>>877696
Про азгаар знаю, хороший генератор, оттуда тоже беру некоторые фичи
Про азгаар знаю, хороший генератор, оттуда тоже беру некоторые фичи
>>877739
Спс Анон!
Спс Анон!
>>877730
Я немного предвзято распишу. 4-кой же можно начинать пользоваться, но она сыровата у нее есть несколько минусов.
1. 3д экспорт в веб в ранней разработке, нет теней, нет многих спецэффектов.
2. вулкан же не везде работает нормально. Так что для разработки на 4-ке уже нужен комп помощнее. Даже банальный запуск редактора и игры в 3-ке GLES2 ощутимо быстрее, чем в 4-ке OpenGL.
3. 3д террейна пока не запилили, и уже месяц даже обсуждений не слышно
4. Если делать 2д игру, то андроид и веб билды будут тяжелее, дольше грузиться
5. Туториалы пока будут попадаться на 3-ку больше, поэтому новичку придется разбираться как что поменять на лету.
6. Аддонов пока меньше, хотя ситуация уже выравнивается, к тому же в основном на 3-ку аддоны заморожены и не будут появляться новые или дорабатываться.
7. Редактор сыроват, в 3-ке как то получше редактируется код, в 4-ке постоянно какие то затупы с автодополнением. Иногда может упасть от неудачного клика по ноде. (Понятно что любой софт может, даже майкрософтовский, но по ощущениям в 4-ке это происходит чаще. несколько раз в день)
Так что я бы сказал так
Если хочешь вкатываться на будущее, с долгостроем, с А-АА игрой, с мощными спецэффектами, бери 4 ку. За год ее уже доведут до приемлимого состояния.
Если хочешь просто потыкаться в 2д на компе, тоже можешь взять 4-ку.
Если хочется супер мега оптимизированную игру которая будет и в вебе и на мобилках, тут я бы в ближайший год все еще 3-ку использовать буду.
Я немного предвзято распишу. 4-кой же можно начинать пользоваться, но она сыровата у нее есть несколько минусов.
1. 3д экспорт в веб в ранней разработке, нет теней, нет многих спецэффектов.
2. вулкан же не везде работает нормально. Так что для разработки на 4-ке уже нужен комп помощнее. Даже банальный запуск редактора и игры в 3-ке GLES2 ощутимо быстрее, чем в 4-ке OpenGL.
3. 3д террейна пока не запилили, и уже месяц даже обсуждений не слышно
4. Если делать 2д игру, то андроид и веб билды будут тяжелее, дольше грузиться
5. Туториалы пока будут попадаться на 3-ку больше, поэтому новичку придется разбираться как что поменять на лету.
6. Аддонов пока меньше, хотя ситуация уже выравнивается, к тому же в основном на 3-ку аддоны заморожены и не будут появляться новые или дорабатываться.
7. Редактор сыроват, в 3-ке как то получше редактируется код, в 4-ке постоянно какие то затупы с автодополнением. Иногда может упасть от неудачного клика по ноде. (Понятно что любой софт может, даже майкрософтовский, но по ощущениям в 4-ке это происходит чаще. несколько раз в день)
Так что я бы сказал так
Если хочешь вкатываться на будущее, с долгостроем, с А-АА игрой, с мощными спецэффектами, бери 4 ку. За год ее уже доведут до приемлимого состояния.
Если хочешь просто потыкаться в 2д на компе, тоже можешь взять 4-ку.
Если хочется супер мега оптимизированную игру которая будет и в вебе и на мобилках, тут я бы в ближайший год все еще 3-ку использовать буду.
>>877791
Спасибо, Антон! Значит мне подойдёт 3-ка.
Спасибо, Антон! Значит мне подойдёт 3-ка.
>>877791
Аппрув.
Аппрув.
75 Кб, 1330x588Ну что, есть еще сутки на заготовочку главного меню, а потом неделя и 2 доп дня
>>877791
Согласен с этим аноном, беру свои слова назад с советом 4-ки для начинающих. Она подходит для тех, кто уже знает как работать с годотом, но только начинает проект.
Согласен с этим аноном, беру свои слова назад с советом 4-ки для начинающих. Она подходит для тех, кто уже знает как работать с годотом, но только начинает проект.
6 Кб, 270x120>>877273
Спасибо. не слышал про такой.
Автору надо бы его в ассетлиб закинуть, да и теги на гитхабе проставить - я бы про него и не узнал, не смотрю ютупчик.
В ассетах такой мелькает постоянно в обновлениях, майнкрафтоподобный
https://godotengine.org/asset-library/asset/1650
Спасибо. не слышал про такой.
Автору надо бы его в ассетлиб закинуть, да и теги на гитхабе проставить - я бы про него и не узнал, не смотрю ютупчик.
В ассетах такой мелькает постоянно в обновлениях, майнкрафтоподобный
https://godotengine.org/asset-library/asset/1650
>>878136
Бамп
Бамп
>>878136
В параллельной вселенной победившего коммунизма, где людей кормят бесплатно.
> Где тысячи бесплатных моделек?
В параллельной вселенной победившего коммунизма, где людей кормят бесплатно.
>>878164
Извините
Извините
>>877791
ну за этот год они сказали что будет максимум 4.2
ну за этот год они сказали что будет максимум 4.2
Сколько на самом деле по времени осваивается ваш движок? А то показания разнятся чё-то.
>>878266
Ну я не дебил и не гений
Ну я не дебил и не гений
>>878232
Если до этого пользовался Юнити, то меньше недели. Если не пользовался, то две недели максимум.
Если до этого пользовался Юнити, то меньше недели. Если не пользовался, то две недели максимум.
Dev snapshot: Godot 4.1 dev 2
>>878295
Тебя наебали. На эту хуйню даже гайдов норм нет
Тебя наебали. На эту хуйню даже гайдов норм нет
>>877791
Уточнение - zylann таки портировал свой height map на 4-ку. Попробовал, текстуры работают, редактирование мышкой работает, коллайдер работает. Не сработала рандомная генерация в меню. Теоретически можно редактировать в 3ке и перекидывать в 4ку. Завтра более плотно потестирую, разные ситуации, экспорт может быть, терраформинг из скрипта.
Уточнение - zylann таки портировал свой height map на 4-ку. Попробовал, текстуры работают, редактирование мышкой работает, коллайдер работает. Не сработала рандомная генерация в меню. Теоретически можно редактировать в 3ке и перекидывать в 4ку. Завтра более плотно потестирую, разные ситуации, экспорт может быть, терраформинг из скрипта.
>>878950
Качается ветка godot4 с гитхаба
git clone -b godot4 https://github.com/Zylann/godot_heightmap_plugin
Качается ветка godot4 с гитхаба
git clone -b godot4 https://github.com/Zylann/godot_heightmap_plugin
>>878951
>>878950
А куллинг он починил?
Объясню. Когда я пользовался его плагином пару лет назад, там был баг куллинга, из за того что меш по факту под ногами, а отрисовка происходит дисплейсом в шейдере, то когда поднимаешь взгляд вверх, срабатывает искаробочный опенгл фруструм куллинг и все горы террейна тупо исчезают, потому что из области камеры ушла изначальная поверхность. Так вот, починил он это?
>>878950
А куллинг он починил?
Объясню. Когда я пользовался его плагином пару лет назад, там был баг куллинга, из за того что меш по факту под ногами, а отрисовка происходит дисплейсом в шейдере, то когда поднимаешь взгляд вверх, срабатывает искаробочный опенгл фруструм куллинг и все горы террейна тупо исчезают, потому что из области камеры ушла изначальная поверхность. Так вот, починил он это?
>>878995
Надо проверить, по твоему описанию это похоже на баг движка, чем на аддона, поискал такие ишью, вроде бы закрыты. Аддон генерит AABB и сообщает движку. По хорошему надо проверить везде, в 3, в 4 Forward+, Mobile и Opengl. Если что-то не работает - из нагугленного надо проверить как работает scale или map scale террейна (наверное в идеале надо оставить 1:1)
И еще написано что у GeometryInstance есть такое свойство как extra cull margin, то есть в теории можно любому объекту подкрутить, чтобы он был виден дальше чем надо (это часто нужно частицам). но вот тут я не уверен есть ли такая опция в террейне, но на первый взгляд ее нетрудно прикрутить, ведь террейн предположительно виден всегда.
Надо проверить, по твоему описанию это похоже на баг движка, чем на аддона, поискал такие ишью, вроде бы закрыты. Аддон генерит AABB и сообщает движку. По хорошему надо проверить везде, в 3, в 4 Forward+, Mobile и Opengl. Если что-то не работает - из нагугленного надо проверить как работает scale или map scale террейна (наверное в идеале надо оставить 1:1)
И еще написано что у GeometryInstance есть такое свойство как extra cull margin, то есть в теории можно любому объекту подкрутить, чтобы он был виден дальше чем надо (это часто нужно частицам). но вот тут я не уверен есть ли такая опция в террейне, но на первый взгляд ее нетрудно прикрутить, ведь террейн предположительно виден всегда.
>>879012
Звучит обнадёживающе. Проверь пожалуйста. Я не могу, у меня лапки.
Звучит обнадёживающе. Проверь пожалуйста. Я не могу, у меня лапки.
>>878077
Посмотрел, чем-то похоже, да
Посмотрел, чем-то похоже, да
8 Кб, 626x55>>879065
Ты ролфиш?
Ты ролфиш?
>>879065
В ютубе искаропки автогенерируемые и автопереводимые субтитры. Это без учёта того, что субтитры могут быть вручную добавлены автором видоса, и на нескольких языках. Да, надмозг иногда тупит, но в целом понять можно о чём речь.
Ну а если писать письма туда на емейл, тупо открываеш в соседней вкладке переводчик, и тупо переводишь, и тупо копипастиш.
В ютубе искаропки автогенерируемые и автопереводимые субтитры. Это без учёта того, что субтитры могут быть вручную добавлены автором видоса, и на нескольких языках. Да, надмозг иногда тупит, но в целом понять можно о чём речь.
Ну а если писать письма туда на емейл, тупо открываеш в соседней вкладке переводчик, и тупо переводишь, и тупо копипастиш.
>>879105
И это не говоря о яндекс-браузере, в котором сделали нейросетевую озвучку.
> Это без учёта того, что
И это не говоря о яндекс-браузере, в котором сделали нейросетевую озвучку.
На одной сцене ui, на другой допустим параметры персонажа (здоровье, броня).
Каким методом пробрасываются переменные из одной сцены в другую?
Каким методом пробрасываются переменные из одной сцены в другую?
>>879149
Есть несколько вариантов
Вариант 1, сигналы. ui подписывается на сигналы, вместо переменных здоровья делаешь сеттер, в нем сигнал отправляется.
Вариант 2. Тупо жесткая связь. Буквально если они в дереве рядом, то "../scene".health. Минусы понятны, что это сложно изменять. Но для джемов вполне норм.
Вариант 3. Менеджер. Похоже на вариант 2, только связь чуть послабее, потому что ты обращаешься к конкретному менеджеру, а он уже достает из нужной ноды.
Вариант 4. Объединить сцены. Отчасти похоже на вариант 2. Это, например, если говорить о полосках над персонажем. То у тебя может быть спрайт, а сцену с ui добавить ему дочерней.
Есть несколько вариантов
Вариант 1, сигналы. ui подписывается на сигналы, вместо переменных здоровья делаешь сеттер, в нем сигнал отправляется.
Вариант 2. Тупо жесткая связь. Буквально если они в дереве рядом, то "../scene".health. Минусы понятны, что это сложно изменять. Но для джемов вполне норм.
Вариант 3. Менеджер. Похоже на вариант 2, только связь чуть послабее, потому что ты обращаешься к конкретному менеджеру, а он уже достает из нужной ноды.
Вариант 4. Объединить сцены. Отчасти похоже на вариант 2. Это, например, если говорить о полосках над персонажем. То у тебя может быть спрайт, а сцену с ui добавить ему дочерней.
Сердцезверь разродился новым туториалом, уже по 4ке:
https://www.youtube.com/watch?v=M8-JVjtJlIQ
https://www.youtube.com/watch?v=M8-JVjtJlIQ
>>879155
Чтобы подписаться на сигнал, нужно знать ноду. А это связь. Таким образом пункты 1 и 3 по сути равнозначны, в случае если ты юзаешь шину сигналов (тот же менеджер) и пункты 1 и 2 равнозначны, если ЮИ знает о ноде и подключается к её сигналу напрямую.
> ui подписывается на сигналы, вместо переменных здоровья делаешь сеттер, в нем сигнал отправляется
Чтобы подписаться на сигнал, нужно знать ноду. А это связь. Таким образом пункты 1 и 3 по сути равнозначны, в случае если ты юзаешь шину сигналов (тот же менеджер) и пункты 1 и 2 равнозначны, если ЮИ знает о ноде и подключается к её сигналу напрямую.
>>879221
Далее. Варианты 2 и 4 приведут к производственному аду, даже на ТВГ, тупо в первую неделю так нахуевертишь, что ко второй неделе голова бомбанёт и с конкурса сольёшься. Проверено.
Поэтому остаётся только пункт 3, только вместо менеджера - шина сигналов (event bus (design pattern) (for googling) только такой вариант я подвачую.
Далее. Варианты 2 и 4 приведут к производственному аду, даже на ТВГ, тупо в первую неделю так нахуевертишь, что ко второй неделе голова бомбанёт и с конкурса сольёшься. Проверено.
Поэтому остаётся только пункт 3, только вместо менеджера - шина сигналов (event bus (design pattern) (for googling) только такой вариант я подвачую.
>>879222
Двачую шину. Когда я узнал, что в Годоте можно вызывать сигналы другой ноды через код и об этом паттерне в частности, то у меня практически полностью исчезли проблемы, связанные с коммуникацией различных сцен между собой.
Двачую шину. Когда я узнал, что в Годоте можно вызывать сигналы другой ноды через код и об этом паттерне в частности, то у меня практически полностью исчезли проблемы, связанные с коммуникацией различных сцен между собой.
>>879221
Все же поправлю тебя немного.
Чтобы подписаться на сигнал надо знать ноду, но связь не возникает. Связь будет существовать уже только в виде сигнала. Саму подписку сможет оформить фабрика, например из массивчика. А она сможет прицеплять ноды как угодно, поэтому не будет жесткой связи вида "../"
Поэтому варианты 1 и 3 НЕ равнозначны. В 1 фабрика знает о ноде и о ui, и только при создании. Нода и ui ничего не знают о фабрике (в отличии от менеджера в 3, о положении которого они обязаны знать чтобы общаться) и не знают о взаимном расположении друг друга, только о сигналах.
>>879222
Вариант 4 и так постоянно используется со штатными нодами годота. Например у KinematicBody обязаны быть дочерние CollisionShape, и не редкость когда родительский скрипт ими управляет. Например когда персонаж приседает и надо уменьшить его рост. Движение вверх тоже встречается, у того же персонажа может быть дочерний детектор попаданий пуль, который сообщает родителю о попадании напрямую. Так что никакого производственного ада нет, если это ближайшие соседи. Производственный ад на джемах возникает только от спешки и попытки что то начать переставлять, просто этого делать не надо и надо доделывать уже так как начал.
Все же поправлю тебя немного.
Чтобы подписаться на сигнал надо знать ноду, но связь не возникает. Связь будет существовать уже только в виде сигнала. Саму подписку сможет оформить фабрика, например из массивчика. А она сможет прицеплять ноды как угодно, поэтому не будет жесткой связи вида "../"
Поэтому варианты 1 и 3 НЕ равнозначны. В 1 фабрика знает о ноде и о ui, и только при создании. Нода и ui ничего не знают о фабрике (в отличии от менеджера в 3, о положении которого они обязаны знать чтобы общаться) и не знают о взаимном расположении друг друга, только о сигналах.
>>879222
Вариант 4 и так постоянно используется со штатными нодами годота. Например у KinematicBody обязаны быть дочерние CollisionShape, и не редкость когда родительский скрипт ими управляет. Например когда персонаж приседает и надо уменьшить его рост. Движение вверх тоже встречается, у того же персонажа может быть дочерний детектор попаданий пуль, который сообщает родителю о попадании напрямую. Так что никакого производственного ада нет, если это ближайшие соседи. Производственный ад на джемах возникает только от спешки и попытки что то начать переставлять, просто этого делать не надо и надо доделывать уже так как начал.
>>879241
Там у Хуана какая-то чорная магия, как минимум в трёшке была, что если дёрнуть сигнал на выгруженной ссылке, то просто ничего не происходит, ну и в консольку печатается еэкзепшн (хотя почему чорная магия, дописал предложение и сам понял, что экзепшн обрабатывается, раз в консольку пишется). В других движках аналогичное действие приводит к крашу.
> надо знать ноду, но связь не возникает
Там у Хуана какая-то чорная магия, как минимум в трёшке была, что если дёрнуть сигнал на выгруженной ссылке, то просто ничего не происходит, ну и в консольку печатается еэкзепшн (хотя почему чорная магия, дописал предложение и сам понял, что экзепшн обрабатывается, раз в консольку пишется). В других движках аналогичное действие приводит к крашу.
53 Кб, 1103x703Почему у vehiclebody3d + vehiclewheels колеса проваливаются? У них вообще нет collision shape?
>>879368
Есть. Почитай гайды. обычно проблема в том, что колесо надо размещать там где оно будет при сжатой рессоре, и уже потом вытолкнуто пружной, а не в конечной точке. То есть в твоем случае возможно его просто выдавливает туда или оно вообще спавнится под землей. Можешь попробовать спавнить машину в воздухе для проверки. Второй момент что колеса вообще не сильно надежны и могут при сильном воздействии провалиться, ну то есть если большая масса, сила пружины или с трамплина прилетел. Я когда авиасим пилил так и не справился с колесами, сделал свой костыль. Честно говоря даже в доках сказано что скорее всего понадобиться делать свое.
Есть. Почитай гайды. обычно проблема в том, что колесо надо размещать там где оно будет при сжатой рессоре, и уже потом вытолкнуто пружной, а не в конечной точке. То есть в твоем случае возможно его просто выдавливает туда или оно вообще спавнится под землей. Можешь попробовать спавнить машину в воздухе для проверки. Второй момент что колеса вообще не сильно надежны и могут при сильном воздействии провалиться, ну то есть если большая масса, сила пружины или с трамплина прилетел. Я когда авиасим пилил так и не справился с колесами, сделал свой костыль. Честно говоря даже в доках сказано что скорее всего понадобиться делать свое.
>>879368
Алсо можешь скачать ассет и посмотреть как в них сделано
3. https://godotengine.org/asset-library/asset/661
https://github.com/BastiaanOlij/vehicle-demo
4. https://godotengine.org/asset-library/asset/1879
Алсо можешь скачать ассет и посмотреть как в них сделано
3. https://godotengine.org/asset-library/asset/661
https://github.com/BastiaanOlij/vehicle-demo
4. https://godotengine.org/asset-library/asset/1879
>>879370
Еще машинки были в двух мультиплеер туторах, правда мне влом сейчас их искать.
Еще машинки были в двух мультиплеер туторах, правда мне влом сейчас их искать.
>>879369
странный подход
Она и так спавнится выше
Читал, мне кажется я не осилю в плане алгебры векторов (я вообще нубасик), но могу попробовать
Я думал что дело в фпс симуляции (не успевает просчитать между тиками), но добавление фпс проблему не решило.
Да качал уже, чего-то особенного не подметил. Думаю тоже на настройки подвески т.к. от нее реально что-то меняется, но это странно, что нужно искать какие-то настройки чтобы шины не проваливались. Если бы у них был нормальный collision shape то такого бы не было.
>в том, что колесо надо размещать там где оно будет при сжатой рессоре
странный подход
>Можешь попробовать спавнить машину в воздухе для проверки
Она и так спавнится выше
>Честно говоря даже в доках сказано что скорее всего понадобиться делать свое.
Читал, мне кажется я не осилю в плане алгебры векторов (я вообще нубасик), но могу попробовать
>Я когда авиасим пилил так и не справился с колесами
Я думал что дело в фпс симуляции (не успевает просчитать между тиками), но добавление фпс проблему не решило.
>Алсо можешь скачать ассет и посмотреть как в них сделано
Да качал уже, чего-то особенного не подметил. Думаю тоже на настройки подвески т.к. от нее реально что-то меняется, но это странно, что нужно искать какие-то настройки чтобы шины не проваливались. Если бы у них был нормальный collision shape то такого бы не было.
>>879372
ты себе не представляешь, СКОЛЬКО настроек надо искать когда делаешь технику. Не меньше 10.
ты себе не представляешь, СКОЛЬКО настроек надо искать когда делаешь технику. Не меньше 10.
>>879372
Мне тоже так казалось, три года назад, а щас ничего, без подсказок гугда трансформы вращаю.
> мне кажется я не осилю в плане алгебры векторов
Мне тоже так казалось, три года назад, а щас ничего, без подсказок гугда трансформы вращаю.
Сап, Годач.
Абсолютный новичок в этих ваших Годо, сижу весь день и не понимаю как это должно работать.
Цель: при нажатии соответствующей клавиши, одна из панелей инвентаря (Заданного через GridContainer) должна поменять свою текстуру.
Для пояснения - в одном положении это соответствует активной правой руке, во втором левой.
Перекопал с десяток примеров/обсуждений/глянул документацию, так нихрена и не понял как это (Изменение текстуры в stylebox) правильно делается.
Абсолютный новичок в этих ваших Годо, сижу весь день и не понимаю как это должно работать.
Цель: при нажатии соответствующей клавиши, одна из панелей инвентаря (Заданного через GridContainer) должна поменять свою текстуру.
Для пояснения - в одном положении это соответствует активной правой руке, во втором левой.
Перекопал с десяток примеров/обсуждений/глянул документацию, так нихрена и не понял как это (Изменение текстуры в stylebox) правильно делается.
>>879514
Хуйня твои объяснения, заскринь структуру сцены, саму сцену, и по скрину объясни, чё хочешь сделать
Хуйня твои объяснения, заскринь структуру сцены, саму сцену, и по скрину объясни, чё хочешь сделать
>>879514
Стили - они для другого. Их задача - обеспечить единообразие вида всех элементов интерфейса. Если тебе надо задать из кода произольную текстуру, то используй TextureRect, там тупо меняешь свойство texture и всё. Ещё посмотри в сторону TextureButton, возможно, это тебе больше подойдёт (я не оч понял, что ты хочешь сделать); к ней можно без кода прикрутить шорткат.
Стили - они для другого. Их задача - обеспечить единообразие вида всех элементов интерфейса. Если тебе надо задать из кода произольную текстуру, то используй TextureRect, там тупо меняешь свойство texture и всё. Ещё посмотри в сторону TextureButton, возможно, это тебе больше подойдёт (я не оч понял, что ты хочешь сделать); к ней можно без кода прикрутить шорткат.
>>879514
var new_panel_stylebox = self.get_stylebox('panel').duplicate()
new_panel_stylebox.bg_color = new_color
self.add_stylebox_override('panel', new_panel_stylebox)
var new_panel_stylebox = self.get_stylebox('panel').duplicate()
new_panel_stylebox.bg_color = new_color
self.add_stylebox_override('panel', new_panel_stylebox)
Привет. Есть гайд как работать с Generic6DOFJoint3D?
Скачал пример от 3 версии, он не работает на 4, хотя я его ручками подправил. Посмотрел там скрипт: он просто включает мотор и крутит его.
Вроде бы все настроил, но при нажатии на кнопку колесо чуток проворачивается вперед и все, хотя я там уже 9999 велосити накрутил, ничего это не меняет.
если крутить напрямую rigidbody3d через angular velocity (wheel_back.angular_velocity.z = 10) то крутит нормально
Это баг или там bullet где-то отдельно включается?
Скачал пример от 3 версии, он не работает на 4, хотя я его ручками подправил. Посмотрел там скрипт: он просто включает мотор и крутит его.
Вроде бы все настроил, но при нажатии на кнопку колесо чуток проворачивается вперед и все, хотя я там уже 9999 велосити накрутил, ничего это не меняет.
если крутить напрямую rigidbody3d через angular velocity (wheel_back.angular_velocity.z = 10) то крутит нормально
Это баг или там bullet где-то отдельно включается?
Ох уж эти лейблы и их percent_visible.
В чём суть. Хочу отрисовать текст красиво, чтобы он появлялся по буквам, причём каждый чётный символ перед буковками появлялось ещё "_". Количество показываемых символов - export(int) var shown_chars. Показываемый текст - export(String) var mytext.
Сначала добавляю подчёркивание:
А дальше первый вариант
или второй вариант:
Проблема в том, что в двух вариантах разный результат. Первый работает надёжнее, но есть проблемы с переносом слов: если слово не помещается на строке, оно перенесётся только тогда, когда наберёт достаточно букв. Собсно, percent_visible для этого и существует. Но во втором способе другая проблема: невозможно предугадать, какой символ будет последним. Там какая-то магия происходит в преобразовании интов во флоты.
Попробовал наоборот, сначала задавать процент,
а потом из него считать количество видимых символов:
Ну и снова, сначала добавляю подчёркивание (см. выше) первый вариант без изменений (тоже см. выше) или второй упрощённый:
Та же дребедень. Символ подчёркивания то вообще не отрисовывается (уходит за пределы видимого), то оказывается предпоследним и после него ещё один.
Как с этим совладать, я чёт пока так и не придумал. Годаны, выручайте. Хочу заюзать percent_visible, но не могу. Пока просто обрезаю текст.
В чём суть. Хочу отрисовать текст красиво, чтобы он появлялся по буквам, причём каждый чётный символ перед буковками появлялось ещё "_". Количество показываемых символов - export(int) var shown_chars. Показываемый текст - export(String) var mytext.
Сначала добавляю подчёркивание:
>mytext.erase(shown_chars - 1, 1)
>mytest = mytext.insert(shown_chars - 1, "_")
А дальше первый вариант
>label1.text = mytext.left(shown_chars)
>label1.percent_visible = 1.0
или второй вариант:
>label2.text = mytext
>label2.percent_visible = float(shown_chars) / float(mytext.length())
Проблема в том, что в двух вариантах разный результат. Первый работает надёжнее, но есть проблемы с переносом слов: если слово не помещается на строке, оно перенесётся только тогда, когда наберёт достаточно букв. Собсно, percent_visible для этого и существует. Но во втором способе другая проблема: невозможно предугадать, какой символ будет последним. Там какая-то магия происходит в преобразовании интов во флоты.
Попробовал наоборот, сначала задавать процент,
>export(float, 0, 1) var shown_percent
а потом из него считать количество видимых символов:
>var shown_chars = int(shown_percent * float(leng))
Ну и снова, сначала добавляю подчёркивание (см. выше) первый вариант без изменений (тоже см. выше) или второй упрощённый:
>label2.text = mytext
>label2.percent_visible = snown_percent
Та же дребедень. Символ подчёркивания то вообще не отрисовывается (уходит за пределы видимого), то оказывается предпоследним и после него ещё один.
Как с этим совладать, я чёт пока так и не придумал. Годаны, выручайте. Хочу заюзать percent_visible, но не могу. Пока просто обрезаю текст.
>>879701
В 4ке добавили какой то параметр который смотрит слова наперед чтобы переносы не скакали.
В 4ке добавили какой то параметр который смотрит слова наперед чтобы переносы не скакали.
>>879823
Покажи игру.
Покажи игру.
>>879823
Как деньги выводишь?
Как деньги выводишь?
Почему, блядь, ни один пидорский соевый гомосатанинский гайд от GDQuest не рассказал мне про yield/await? ПОЧЕМУ, БЛЯДЬ, Я ОБ ЧУТЬ ЛИ НЕ САМОЙ ВАЖНОЙ ФИЧЕ В МИРЕ УЗНАЮ ИЗ КАКОГО-ТО ЛЕВОГО ЮТУБ-ВИДЕО?
https://www.youtube.com/watch?v=7QvhCDsFkk0
https://www.youtube.com/watch?v=7QvhCDsFkk0
>>879830
Потому что ты не пил кофе давя питона.
На самом деле значит в уроках оно не требовалось.
Проверь gdscript keywords мб еще что интересного найдешь.
Потому что ты не пил кофе давя питона.
На самом деле значит в уроках оно не требовалось.
Проверь gdscript keywords мб еще что интересного найдешь.
>>879830
Потому что это хуйня и костыль, сраный атавизм. Как какое-нибудь GOTO. Только баги рождает, хотя всегда есть более эффективное решение.
Но вот тебе умное видео: https://www.youtube.com/watch?v=4xMaq-qVQGY
Потому что это хуйня и костыль, сраный атавизм. Как какое-нибудь GOTO. Только баги рождает, хотя всегда есть более эффективное решение.
Но вот тебе умное видео: https://www.youtube.com/watch?v=4xMaq-qVQGY
605 Кб, 1280x720>>879830
Потому что инструмент надо изучать в первую очередь по официальным докам, прочитав хотя бы 1 раз целиком
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_basics.html
Вижу гайд GDQuest по yield 4 летней давности, так что вини только себя.
Если ты не знаешь о ней из опыта программирования, то скорее всего она тебе не нужна. Анон выше может и преувеличивает насчет устаревшей, но то что новичок может ее совать где угодно и получать баги это факт. Я сам поначалу в ready костылял по два yield(get tree(), "idle frame") "чтобы все наверняка загрузилось" и потом удивлялся с трудноуловимых багов.
> Почему, блядь
Потому что инструмент надо изучать в первую очередь по официальным докам, прочитав хотя бы 1 раз целиком
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_basics.html
>ни один пидорский соевый гомосатанинский гайд от GDQuest не рассказал мне про yield/await?
Вижу гайд GDQuest по yield 4 летней давности, так что вини только себя.
>ЧУТЬ ЛИ НЕ САМОЙ ВАЖНОЙ ФИЧЕ В МИРЕ
Если ты не знаешь о ней из опыта программирования, то скорее всего она тебе не нужна. Анон выше может и преувеличивает насчет устаревшей, но то что новичок может ее совать где угодно и получать баги это факт. Я сам поначалу в ready костылял по два yield(get tree(), "idle frame") "чтобы все наверняка загрузилось" и потом удивлялся с трудноуловимых багов.
>>879850
На что заменил?
>Я сам поначалу в ready костылял по два yield(get tree(), "idle frame") "чтобы все наверняка загрузилось" и потом удивлялся с трудноуловимых багов.
На что заменил?
>>879843
Не сильно, но отличается.
Гайды на конверсию есть
Например вот выглядит вменяемым
https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976
Если быстренько по нему пройтись, с чем ты скорее всего столкнешься
Сигналы
button.connect("pressed", self, "_on_button_pressed") --> button.pressed.connect(_on_button_pressed)
yield(get_tree(), "idle_frame") --> await get_tree().process_frame
Аннотации
onready, export, tool --> @onready, @export, @tool
Спавн
tscn.instance() --> tscn.instantiate()
Функции, ноды - большой список
deg2rad --> deg_to_rad
Spatial --> Node3D
change_scene() --> change_scene_to_file/change_scene_to_packed
Свойства
setget --> set(value):... get(): ...
Физика персонажей
KinematicBody --> CharacterBody2D/3D
теперь используется встроенное поле velocity,
Т.е. не надо будет вmove_and_slide передавать переменную,
а надо прямо менять саму velocity.
Шейдеры
Надо в начале самому объявить SCREEN_TEXTURE для постобработки
hint_color --> source_color и прочие переименования
Объекты
if object: --> if object == null:
Не сильно, но отличается.
Гайды на конверсию есть
Например вот выглядит вменяемым
https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976
Если быстренько по нему пройтись, с чем ты скорее всего столкнешься
Сигналы
button.connect("pressed", self, "_on_button_pressed") --> button.pressed.connect(_on_button_pressed)
yield(get_tree(), "idle_frame") --> await get_tree().process_frame
Аннотации
onready, export, tool --> @onready, @export, @tool
Спавн
tscn.instance() --> tscn.instantiate()
Функции, ноды - большой список
deg2rad --> deg_to_rad
Spatial --> Node3D
change_scene() --> change_scene_to_file/change_scene_to_packed
Свойства
setget --> set(value):... get(): ...
Физика персонажей
KinematicBody --> CharacterBody2D/3D
теперь используется встроенное поле velocity,
Т.е. не надо будет вmove_and_slide передавать переменную,
а надо прямо менять саму velocity.
Шейдеры
Надо в начале самому объявить SCREEN_TEXTURE для постобработки
hint_color --> source_color и прочие переименования
Объекты
if object: --> if object == null:
>>879843
Не сильно, но отличается.
Гайды на конверсию есть
Например вот выглядит вменяемым
https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976
Если быстренько по нему пройтись, с чем ты скорее всего столкнешься
Сигналы
button.connect("pressed", self, "_on_button_pressed") --> button.pressed.connect(_on_button_pressed)
yield(get_tree(), "idle_frame") --> await get_tree().process_frame
Аннотации
onready, export, tool --> @onready, @export, @tool
Спавн
tscn.instance() --> tscn.instantiate()
Функции, ноды - большой список
deg2rad --> deg_to_rad
Spatial --> Node3D
change_scene() --> change_scene_to_file/change_scene_to_packed
Свойства
setget --> set(value):... get(): ...
Физика персонажей
KinematicBody --> CharacterBody2D/3D
теперь используется встроенное поле velocity,
Т.е. не надо будет вmove_and_slide передавать переменную,
а надо прямо менять саму velocity.
Шейдеры
Надо в начале самому объявить SCREEN_TEXTURE для постобработки
hint_color --> source_color и прочие переименования
Объекты
if object: --> if object == null:
Не сильно, но отличается.
Гайды на конверсию есть
Например вот выглядит вменяемым
https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976
Если быстренько по нему пройтись, с чем ты скорее всего столкнешься
Сигналы
button.connect("pressed", self, "_on_button_pressed") --> button.pressed.connect(_on_button_pressed)
yield(get_tree(), "idle_frame") --> await get_tree().process_frame
Аннотации
onready, export, tool --> @onready, @export, @tool
Спавн
tscn.instance() --> tscn.instantiate()
Функции, ноды - большой список
deg2rad --> deg_to_rad
Spatial --> Node3D
change_scene() --> change_scene_to_file/change_scene_to_packed
Свойства
setget --> set(value):... get(): ...
Физика персонажей
KinematicBody --> CharacterBody2D/3D
теперь используется встроенное поле velocity,
Т.е. не надо будет вmove_and_slide передавать переменную,
а надо прямо менять саму velocity.
Шейдеры
Надо в начале самому объявить SCREEN_TEXTURE для постобработки
hint_color --> source_color и прочие переименования
Объекты
if object: --> if object == null:
>>879850
>>879847
Во-первых, дяденька, я программист ненастоящий, я годот на стройке нашел. Во-вторых, я вижу эту хуйню и не представляю, как в принципе писать пошаговую игру без нее. Я вот в ужасе представлял, какой огород мне придется городить, чтобы ждать завершения вражеских анимаций в их ход, а тут оказывается, что я могу тупо во вражеский ход пройтись по всем врагам циклом.
>>879847
Во-первых, дяденька, я программист ненастоящий, я годот на стройке нашел. Во-вторых, я вижу эту хуйню и не представляю, как в принципе писать пошаговую игру без нее. Я вот в ужасе представлял, какой огород мне придется городить, чтобы ждать завершения вражеских анимаций в их ход, а тут оказывается, что я могу тупо во вражеский ход пройтись по всем врагам циклом.
>>879856
Стейтмашиной.
И ваще. В любой непонятной ситуации создавай стейтмашину.
> я вижу эту хуйню и не представляю, как в принципе писать пошаговую игру без нее
Стейтмашиной.
И ваще. В любой непонятной ситуации создавай стейтмашину.
>>879859
Ну вот например, курсы по юнити (для сравнения) начинаются с объяснения что такое стейтмашина и как она важна в геймдеве. Такшта думой сам, как относятся.
Ну вот например, курсы по юнити (для сравнения) начинаются с объяснения что такое стейтмашина и как она важна в геймдеве. Такшта думой сам, как относятся.
>>879862
>>879861
Я имею ввиду, там можно было и без корутины обойтись, добавив ноду таймер, сделав ей ваншот и в этой функции писать if !timer.enabled: timer.start(2.0) и потом ещё одну функцию приконнектить к таймеру, которая будет делать exit(), но для объяснения сути в рамках туториала проще влепить yield()
>>879861
Я имею ввиду, там можно было и без корутины обойтись, добавив ноду таймер, сделав ей ваншот и в этой функции писать if !timer.enabled: timer.start(2.0) и потом ещё одну функцию приконнектить к таймеру, которая будет делать exit(), но для объяснения сути в рамках туториала проще влепить yield()
>>879861
Стейт машина это что то вроде состояний и переходов changeStateTo()
1. ожидание ввода игрока -> 2. ход игрока -> 3. ход противника -> если еще есть противники, то 3 иначе 1
В общем yield тут не обязателен, changeState может вызывать подписанный на сигнал обработчик.
Стейт машина это что то вроде состояний и переходов changeStateTo()
1. ожидание ввода игрока -> 2. ход игрока -> 3. ход противника -> если еще есть противники, то 3 иначе 1
В общем yield тут не обязателен, changeState может вызывать подписанный на сигнал обработчик.
>>879969
Если что в коде со скришота angular upper И lower limit просто тестовые, должны быть (как я понимаю) 180 и -180 (полный оборот) крутится в настройках на правой панели.
Если что в коде со скришота angular upper И lower limit просто тестовые, должны быть (как я понимаю) 180 и -180 (полный оборот) крутится в настройках на правой панели.
>>879990
честно говоря судя по этому https://github.com/godotengine/godot/issues/66335 еще не имплементед в 4-ке, хотя там есть ссылка на довольно свежий бранч где уже добавлены моторы, но нет пружин все равно нет.
честно говоря судя по этому https://github.com/godotengine/godot/issues/66335 еще не имплементед в 4-ке, хотя там есть ссылка на довольно свежий бранч где уже добавлены моторы, но нет пружин все равно нет.
>>879994
Хоть бы в консоль что выпукивало... ладно я понял.
Хоть бы в консоль что выпукивало... ладно я понял.
Чем больше и чаще я пользуюсь движком и чем сложнее становится проект, тем сильнее мне хочется удушить блядь к хуям всех его разработчиков. Постоянные баги в редакторе просто нереально выбешивают.
Какую версию качать-то?
4.0.3?
И там версия с сирашпом есть и без него. Чем отличаются? Насколько вообще сишарп там норм? Или лучше их языком пользоваться?
4.0.3?
И там версия с сирашпом есть и без него. Чем отличаются? Насколько вообще сишарп там норм? Или лучше их языком пользоваться?
короче, 3.5 скачал
Хочу с 2д побаловаться
Хочу с 2д побаловаться
>>880059
Тред полистай >>877791
>>880059
сишарп как сишарп. Им мало кто пользуется, так уж сложилось, новичкам все покрывает gdscript, олдам gdscript+cpp. Но если знаком, можешь и на нем писать.
>>880062
Постоянно фиксят, на сайте же написано что сейчас бета 3.6
>>880063
3д модели как таковые технически можно, из стора хз, надо во первых смотреть лицензию позволяют ли там использовать модель вне юнити, во вторых может быть какие то особые форматы. Так то я и из анрила вытаскивал.
>Какую версию качать-то?
Тред полистай >>877791
>>880059
> Насколько вообще сишарп там норм?
сишарп как сишарп. Им мало кто пользуется, так уж сложилось, новичкам все покрывает gdscript, олдам gdscript+cpp. Но если знаком, можешь и на нем писать.
>>880062
Постоянно фиксят, на сайте же написано что сейчас бета 3.6
>>880063
3д модели как таковые технически можно, из стора хз, надо во первых смотреть лицензию позволяют ли там использовать модель вне юнити, во вторых может быть какие то особые форматы. Так то я и из анрила вытаскивал.
>>880115
3.6 будет LTS версией то есть поддержка как минимум год-два. 4-ка догонит по фичам/состоянию только в 4.2-4.3.
Скачать беты можно из новостей, там ссылки на репозиторий со всеми версиями.
3.6 будет LTS версией то есть поддержка как минимум год-два. 4-ка догонит по фичам/состоянию только в 4.2-4.3.
Скачать беты можно из новостей, там ссылки на репозиторий со всеми версиями.
>>880059
Открываешь повершелл, если ты на венде, а если не на венде, а на линуксе, то зачем качать? Юзай пакетный менеджер своего линукса.
Эм, так вот, на венде открываешь повершелл и пишешь:
Закрываешь повершелл и открываешь заново. Пишешь
Идешь в пуск -> scoop apps -> godot
Открывается свежий стабильный релиз.
Автоматически не обновится, пока не напишешь в помершеле
Такшта можешь смело девелопить, не боясь, что внезапным обновлением похерится проект.
> Какую версию качать-то?
Открываешь повершелл, если ты на венде, а если не на венде, а на линуксе, то зачем качать? Юзай пакетный менеджер своего линукса.
Эм, так вот, на венде открываешь повершелл и пишешь:
>Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
>irm get.scoop.sh | iex
Закрываешь повершелл и открываешь заново. Пишешь
>scoop install 7zip
>scoop install git
>scoop bucket add extras
>scoop install godot
Идешь в пуск -> scoop apps -> godot
Открывается свежий стабильный релиз.
Автоматически не обновится, пока не напишешь в помершеле
> scoop update godot
Такшта можешь смело девелопить, не боясь, что внезапным обновлением похерится проект.
>>880114
Ага, карп в пакете.
Из серии, прототип делается за день, а потом нерешаемые годами проблемы.
1. Видео. Годот не играет Mp4, потому что патент на H.264 до 2028 года. Значит надо мутить что то с встраиванием плеера, ffmpeg или mpv. Там без пересборки движка не обойтись, потому что надо встраивать окно внутрь opengl как то. Кроссплатформенность тоже под вопросом. Смотрел как другие делают, в Kurobe просто андроидный видеоплеер видимо, или хочешь сам ебись с libmpv.so. Собственно поэтому всякие ffmpeg или mpv распространяются в исходниках, хочешь собрать для себя - все легально, а бинарники распространяют только через какие нибудь балканские сервера где не прилетит DMCA.
С юутубом тоже непонятно, или комбинировать с yt-dlp или п.2.
2. Браузер. Например для капчи. Сейчас капча картинкой, но ведь может вылезти окно Клаудфронта. Или на какой то борде будет гуглокапча. Посмотрел аддон CEF (Chromium embedded), работает, но весит 1 гигабайт, чтобы показать капчу, карл. Может быть это дебаг, особо не ковырялся пока. Еще есть WebView но подозреваю там те же проблемы со встраиванием будут.
3. Просто много мелочевки. Те же теги парсить, прочитал что админы могут в посте любой html писать. Например оформление в /ld веселое. Кэш для загрузки картинок. Переадресация на /arch-ив. Настройки ебойки.
Ага, карп в пакете.
Из серии, прототип делается за день, а потом нерешаемые годами проблемы.
1. Видео. Годот не играет Mp4, потому что патент на H.264 до 2028 года. Значит надо мутить что то с встраиванием плеера, ffmpeg или mpv. Там без пересборки движка не обойтись, потому что надо встраивать окно внутрь opengl как то. Кроссплатформенность тоже под вопросом. Смотрел как другие делают, в Kurobe просто андроидный видеоплеер видимо, или хочешь сам ебись с libmpv.so. Собственно поэтому всякие ffmpeg или mpv распространяются в исходниках, хочешь собрать для себя - все легально, а бинарники распространяют только через какие нибудь балканские сервера где не прилетит DMCA.
С юутубом тоже непонятно, или комбинировать с yt-dlp или п.2.
2. Браузер. Например для капчи. Сейчас капча картинкой, но ведь может вылезти окно Клаудфронта. Или на какой то борде будет гуглокапча. Посмотрел аддон CEF (Chromium embedded), работает, но весит 1 гигабайт, чтобы показать капчу, карл. Может быть это дебаг, особо не ковырялся пока. Еще есть WebView но подозреваю там те же проблемы со встраиванием будут.
3. Просто много мелочевки. Те же теги парсить, прочитал что админы могут в посте любой html писать. Например оформление в /ld веселое. Кэш для загрузки картинок. Переадресация на /arch-ив. Настройки ебойки.
Еще один охуенный баг от сынов блядей, из-за которого я страдал как минимум полчаса. Просто боги кода, ничего не скажешь, я уже понял, что если что-то идет не так, то дефолтным предположением должны быть не твои кривые руки, а кривые руки дегенератов, которые программировали движок.
https://github.com/godotengine/godot/issues/74123
https://github.com/godotengine/godot/issues/74123
>>880129
Теперь ты понимаешь, что браузеры - вершина девелопинга, самый продвинутый и сложный софт на наших устройствах.
Теперь ты понимаешь, что браузеры - вершина девелопинга, самый продвинутый и сложный софт на наших устройствах.
>>880198
да он искусственно переусложнен, плюс пилился во многом некомпетентными вкатунами, плюс монолит вместо модульности и линуксвей. Та же гуглокапча - специальная подстава, я где то читал что там загружается скрипт виртуальной машины на JS, и начинает двигать невидимые квадратики и блоки, а поскольку стандарт там та еще ебанина, то вот кривой конечный результат должен совпать с эталоном на сервере.
В принципе сделать перечисленное не проблема, и плеер встроить и капчебраузер, только не приблизит меня к цели - а цель у меня была не капчевалка на годоте, а компактная, кроссплатформенная, легко и легально распространяемая капчевалка.
А сам рендер текста на годоте относительно просто делается, ну может со спойлерами повозиться придется подольше.
В общем пока писал, в очередной раз осознал, насколько прав и Мицгол со своим гипертекстовым фидонетом, и всякие линуксы распространяемые в сорцах. Ладно надо завязывать, пока templeOs2 не начал писать. А еще как вспомню про эту тяночку... https://habr.com/ru/companies/timeweb/articles/734652/
да он искусственно переусложнен, плюс пилился во многом некомпетентными вкатунами, плюс монолит вместо модульности и линуксвей. Та же гуглокапча - специальная подстава, я где то читал что там загружается скрипт виртуальной машины на JS, и начинает двигать невидимые квадратики и блоки, а поскольку стандарт там та еще ебанина, то вот кривой конечный результат должен совпать с эталоном на сервере.
В принципе сделать перечисленное не проблема, и плеер встроить и капчебраузер, только не приблизит меня к цели - а цель у меня была не капчевалка на годоте, а компактная, кроссплатформенная, легко и легально распространяемая капчевалка.
А сам рендер текста на годоте относительно просто делается, ну может со спойлерами повозиться придется подольше.
В общем пока писал, в очередной раз осознал, насколько прав и Мицгол со своим гипертекстовым фидонетом, и всякие линуксы распространяемые в сорцах. Ладно надо завязывать, пока templeOs2 не начал писать. А еще как вспомню про эту тяночку... https://habr.com/ru/companies/timeweb/articles/734652/
>>880199
Хуйня типа хромиума явно максимально переусложнена, но она также хотя бы работает относительно нормально. Если скачать какую-нибудь хуйню на кастомном движке типа Epiphany, то можно охуеть с того, как 90% сайтов либо не грузится, либо просто крашит браузер. Если бы было просто сделать альтернативу, то они бы уже появились, а так есть только полудохлая мозилла.
Хуйня типа хромиума явно максимально переусложнена, но она также хотя бы работает относительно нормально. Если скачать какую-нибудь хуйню на кастомном движке типа Epiphany, то можно охуеть с того, как 90% сайтов либо не грузится, либо просто крашит браузер. Если бы было просто сделать альтернативу, то они бы уже появились, а так есть только полудохлая мозилла.
Подскажите пожалуйста, где можно найти репетитора по Godot? На профи ру искал долго - нигде нет.
>>880255
Могу основным моментам научить. Потом будешь игру помогать мне делать :3
Пиши сюда: telescope#8606
Могу основным моментам научить. Потом будешь игру помогать мне делать :3
Пиши сюда: telescope#8606
>>880255
Спрашивай что неясно прямо итт.
Спрашивай что неясно прямо итт.
52 Кб, 1377x823ну и почему так?
angular_speed вроде как равен 3.14 радиан, т.е. 180 градусов.
А поворот на очень малый угол идет.
angular_speed вроде как равен 3.14 радиан, т.е. 180 градусов.
А поворот на очень малый угол идет.
>>880283
Да и вообще вопрос, почему эта функция запускается. Это же вроде просто ее определение (конструктор).
Или она и не запускается? А просто из-за того что вызывается поле класса (rotation) оно само считается? Ну и странно что поле класса встроенного класса никак не выделяется
Да и вообще вопрос, почему эта функция запускается. Это же вроде просто ее определение (конструктор).
Или она и не запускается? А просто из-за того что вызывается поле класса (rotation) оно само считается? Ну и странно что поле класса встроенного класса никак не выделяется
>>880284
А я понял, эта встроенная функция сама запускается каждый фрейм.
А я понял, эта встроенная функция сама запускается каждый фрейм.
>>880284
Это называется callback. Да, ты только определяешь функцию, но вызывает ее движок. В принципе большинство таких функций начинается с подчеркивания.
Это называется callback. Да, ты только определяешь функцию, но вызывает ее движок. В принципе большинство таких функций начинается с подчеркивания.
>>880283
Тут тоже понял, там же на дельту умножается, а число меду фреймами наверное 0.000001 секунд
Тут тоже понял, там же на дельту умножается, а число меду фреймами наверное 0.000001 секунд
ЧЯДНТ?
Есть функция которая возвращает значение (пик 1)
Есть функция которая использует предыдущую и сравнивает значения (пик 2)
Есть ошибка которая портит мне настроение (пик 3)
Есть значения которые первая функция возвращает (пик 4)
Почему там какой-то объект а не цифра единичка?
Есть функция которая возвращает значение (пик 1)
Есть функция которая использует предыдущую и сравнивает значения (пик 2)
Есть ошибка которая портит мне настроение (пик 3)
Есть значения которые первая функция возвращает (пик 4)
Почему там какой-то объект а не цифра единичка?
>>880309
У тебя видимо туда вывалилось то что в yield(там же не итовое значение), а не return.
Не понял, зачем функция в которой и return и yield
У тебя видимо туда вывалилось то что в yield(там же не итовое значение), а не return.
Не понял, зачем функция в которой и return и yield
>>880313
Да ты прав. Попробовал запустить без yield и все пошло как надо.
Мне нужна была штука которая запаузит выполнение функции, типо wait(). В интернете сказали использовать такую конструкцию. А то что yield что-то возвращает мне даже в голову не пришло, лол
Спасибо за наводку
Да ты прав. Попробовал запустить без yield и все пошло как надо.
Мне нужна была штука которая запаузит выполнение функции, типо wait(). В интернете сказали использовать такую конструкцию. А то что yield что-то возвращает мне даже в голову не пришло, лол
Спасибо за наводку
2,6 Мб, 640x640ради интереса попытался портануть свой проэкт с Унити на Годот и ипать тут все супер плохо, то что он в 100 раз меньше весит это конечно круто, но он и в 100 раз больше заставляет тривиальной хуйней заниматься
Вот к примеру как вообще пайплайн 3д игры делать если он не могет импортировать анимации на риг вообще, если скелет не женерик готовский
И это даже не в планах разрабов
Т.е. тут тупо каждую 3д модель надо сразу со всеми анимацими экспортировать, а если нужно добавить анимацю, то весь ассет с нуля переимпортировать
Ну хоть бесплатно
https://github.com/godotengine/godot/issues/71525
Вот к примеру как вообще пайплайн 3д игры делать если он не могет импортировать анимации на риг вообще, если скелет не женерик готовский
И это даже не в планах разрабов
Т.е. тут тупо каждую 3д модель надо сразу со всеми анимацими экспортировать, а если нужно добавить анимацю, то весь ассет с нуля переимпортировать
Ну хоть бесплатно
https://github.com/godotengine/godot/issues/71525
>>880367
То, что не так как ты привык в свовем первом движке != супер плохо. Это же не клон или копия. Блендер тоже не майя.
Но конечно ручной работы больше, с этим никто не спорит.
>>876327
Это утверждение вообще непонятно какой смысл несет. В годоте нет встроенных ригов и никаких ограничений на них тоже нет. Иначе как бы анимировали волков, драконов?
нет, это не так. Это всего лишь один из способов, самый прямолинейный, и в целом логичный и приемлимый - добавил новую пачку анимаций, импортировал, отредактировал animtree и скрипты стейт машин.
Но ничто не мешает тебе экспортировать новый gltf с только нужными новыми анимациями, импортировать их, и уже в самом годоте их перенести на первую модель. В 3-м это делается через save-load .anim файлов из аним плеера, в в 4-м там есть "библиотека анимаций" для подобного. И, кажется, уже и ретаргет для других скелетов запилили, сам не пробовал.
Я описывал воркфлоу который подходит под мои нужды. Это скетчфаб + блендер + миксамо+ годот, ну в идеале конечно еще каскадер и свои анимации.
>>880367
>тут все супер плохо
То, что не так как ты привык в свовем первом движке != супер плохо. Это же не клон или копия. Блендер тоже не майя.
Но конечно ручной работы больше, с этим никто не спорит.
>>876327
> если скелет не женерик готовский
Это утверждение вообще непонятно какой смысл несет. В годоте нет встроенных ригов и никаких ограничений на них тоже нет. Иначе как бы анимировали волков, драконов?
>тупо каждую 3д модель надо сразу со всеми анимацими экспортировать, а если нужно добавить анимацю, то весь ассет с нуля переимпортировать
нет, это не так. Это всего лишь один из способов, самый прямолинейный, и в целом логичный и приемлимый - добавил новую пачку анимаций, импортировал, отредактировал animtree и скрипты стейт машин.
Но ничто не мешает тебе экспортировать новый gltf с только нужными новыми анимациями, импортировать их, и уже в самом годоте их перенести на первую модель. В 3-м это делается через save-load .anim файлов из аним плеера, в в 4-м там есть "библиотека анимаций" для подобного. И, кажется, уже и ретаргет для других скелетов запилили, сам не пробовал.
Я описывал воркфлоу который подходит под мои нужды. Это скетчфаб + блендер + миксамо+ годот, ну в идеале конечно еще каскадер и свои анимации.
>>880367
Ссылки перепутались местами. Вот мой процесс >>876327
>>880372
Косяк был в том, что при импорте новых анимаций на основной риг происходила их поломка - стартовые вращения были не правильными, костыль состоит в том, чтобы при импорте новых анимации в -1 кадр им ставить кадр с т-позой(нулевым кадром) тогда все вращения в импортируемой анимации корректы и после этого -1 кадр можно удалять
Косяк был в том, что при импорте новых анимаций на основной риг происходила их поломка - стартовые вращения были не правильными, костыль состоит в том, чтобы при импорте новых анимации в -1 кадр им ставить кадр с т-позой(нулевым кадром) тогда все вращения в импортируемой анимации корректы и после этого -1 кадр можно удалять
>>880375
Возможно, я с таким и в других инструментах сталкивался, всегда возможна путаница между рест позой и т позой. Поэтому я стал все.в миксамо тоже от тпозы делать.
Алсо, в каком то скрипте импорта читал, что годот играет с 1 кадра, так что модет он попросту не считывал 0й. Но это уже неточно.
Возможно, я с таким и в других инструментах сталкивался, всегда возможна путаница между рест позой и т позой. Поэтому я стал все.в миксамо тоже от тпозы делать.
Алсо, в каком то скрипте импорта читал, что годот играет с 1 кадра, так что модет он попросту не считывал 0й. Но это уже неточно.
Вкатился в этот ваш игрострой неделю назад. Понемногу осваиваю кодинг. Есть пара проблем, которые мне пока не удается решить:
extends Node2D
var cell_size = 48
var cord = Vector2(0,0)
var gestures = []
func _input(event):
if Input.is_action_pressed("Clicker"):
var pos
pos = Vector2(int(get_global_mouse_position().x/cell_size),int(get_global_mouse_position().y/cell_size))
if pos != cord:
cord = pos
gestures.append(cord)
print(gestures)
Вопрос номер раз: вот у нас появляется после нажатия ПКМ первый элемент массива с координатой (x;y). Как мне вычесть из координат (1;1) координаты (x;y), а затем прибавить полученное значение (x1;y1) ко всем элементам (в том числе к первому)? Координаты (1;1) будут присвоены новой переменной Vector2, а все преобразованные значения будут внесены в новый массив.
Вопрос номер два: как мне поэлементно сравнивать два массива? Хочу, чтобы массив с преобразованными значениями на каждом этапе добавления этих значений сравнивался с некими шаблонами.
extends Node2D
var cell_size = 48
var cord = Vector2(0,0)
var gestures = []
func _input(event):
if Input.is_action_pressed("Clicker"):
var pos
pos = Vector2(int(get_global_mouse_position().x/cell_size),int(get_global_mouse_position().y/cell_size))
if pos != cord:
cord = pos
gestures.append(cord)
print(gestures)
Вопрос номер раз: вот у нас появляется после нажатия ПКМ первый элемент массива с координатой (x;y). Как мне вычесть из координат (1;1) координаты (x;y), а затем прибавить полученное значение (x1;y1) ко всем элементам (в том числе к первому)? Координаты (1;1) будут присвоены новой переменной Vector2, а все преобразованные значения будут внесены в новый массив.
Вопрос номер два: как мне поэлементно сравнивать два массива? Хочу, чтобы массив с преобразованными значениями на каждом этапе добавления этих значений сравнивался с некими шаблонами.
>>880386
Вектора поддерживают математические операции (главное чтобы с обоих сторон от знака были одинаковые типы векторов).
Если у тебя список векторов [1,2,3...n] то:
for i in range(len(твой массив)): # возможно вместо len, нужен size
твой_массив += полученное значение (x1;y1)
## возможно твой_массив = твой_массив + полученное значение (x1;y1)
возможно как-то так (не в курсах за gdscript, больше за python)
пройди курс python на stepik
Вектора поддерживают математические операции (главное чтобы с обоих сторон от знака были одинаковые типы векторов).
>прибавить полученное значение (x1;y1) ко всем элементам (в том числе к первому)?
Если у тебя список векторов [1,2,3...n] то:
for i in range(len(твой массив)): # возможно вместо len, нужен size
твой_массив += полученное значение (x1;y1)
## возможно твой_массив = твой_массив + полученное значение (x1;y1)
возможно как-то так (не в курсах за gdscript, больше за python)
пройди курс python на stepik
>>880388
Накатить? Мб накодить?
Накодить можно, но нужна инфа от гуру годота по: детализация объектов, область видимости (есть ли они из коробки)
ну т.е. должно быть дерево объектов которое при каждом шевелении камеры обрабатывается, есть оно в кадре или нет (нужно его рисовать или нет и с какой детализацией).
Накатить? Мб накодить?
Накодить можно, но нужна инфа от гуру годота по: детализация объектов, область видимости (есть ли они из коробки)
ну т.е. должно быть дерево объектов которое при каждом шевелении камеры обрабатывается, есть оно в кадре или нет (нужно его рисовать или нет и с какой детализацией).
>>880394
понял, услышал.
понял, услышал.
>>880400
Спасибо, анончик. Будем дальше штурмовать.
Спасибо, анончик. Будем дальше штурмовать.
>>880391
В общем, эта уеба не хочет прибавлять к массиву вектор. Выдает "Invalid operands 'Array' and 'Vector2' in operator '+'."
В общем, эта уеба не хочет прибавлять к массиву вектор. Выдает "Invalid operands 'Array' and 'Vector2' in operator '+'."
>>880414
Все. Исправил. Понял в чем ошибка.
Все. Исправил. Понял в чем ошибка.
Теперь другая проблема:
extends Node2D
var cell_size = 48
var cord = Vector2(0,0)
var gestures = []
func _input(event):
if Input.is_action_pressed("Clicker"):
var pos
pos = Vector2(int(get_global_mouse_position().x/cell_size),int(get_global_mouse_position().y/cell_size))
if pos != cord:
cord = pos
gestures.append(cord)
var a = Vector2(1,1) - gestures[0]
for i in range(gestures.size()): gestures += a
print(a)
print(gestures)
else: gestures = []
Переменная а прибавляется только к первому элементу массива gesture. Все остальные элементы остаются без изменений. Что-то не так с циклом for?
extends Node2D
var cell_size = 48
var cord = Vector2(0,0)
var gestures = []
func _input(event):
if Input.is_action_pressed("Clicker"):
var pos
pos = Vector2(int(get_global_mouse_position().x/cell_size),int(get_global_mouse_position().y/cell_size))
if pos != cord:
cord = pos
gestures.append(cord)
var a = Vector2(1,1) - gestures[0]
for i in range(gestures.size()): gestures += a
print(a)
print(gestures)
else: gestures = []
Переменная а прибавляется только к первому элементу массива gesture. Все остальные элементы остаются без изменений. Что-то не так с циклом for?
>>880388
Сделать - можно, но работы надо сделать много (пилю опенворлд мечты потихоньку)
Накатить в виде "закинул ассеты и оно само" - такого нет.
Есть ассет на 3/4 под названием zoneloading, но скорее всего придется делать свой на квадратные чанки. Умный куллинг (для ситуаций когда ты в городе и куча домов перекрывают друг друга) все еще под вопросом.
Сделать - можно, но работы надо сделать много (пилю опенворлд мечты потихоньку)
Накатить в виде "закинул ассеты и оно само" - такого нет.
Есть ассет на 3/4 под названием zoneloading, но скорее всего придется делать свой на квадратные чанки. Умный куллинг (для ситуаций когда ты в городе и куча домов перекрывают друг друга) все еще под вопросом.
>>880418
В годоте есть отладчик с брейкопинтами, возьми и пройдись им. Или печатай print.
Поскольку двач съедает форматирование, угадать что у тебя за код невозможно. Может быть у тебя массив всегда или с одним элементом, или стерт последней строчкой else.
В годоте есть отладчик с брейкопинтами, возьми и пройдись им. Или печатай print.
Поскольку двач съедает форматирование, угадать что у тебя за код невозможно. Может быть у тебя массив всегда или с одним элементом, или стерт последней строчкой else.
>>880375
Еще советую добавить в мастер файл анимацию RESET в которой т-поза и больше ничего. Это тоже может исправить какие-то проблемы. Анимация с таким именем выставляется при сохранении сцены.
Это может помочь если какая-то анимация, скажем idle, выставила не ту позу, и все анимации начинают играться от нее, немного перекошенные.
Еще советую добавить в мастер файл анимацию RESET в которой т-поза и больше ничего. Это тоже может исправить какие-то проблемы. Анимация с таким именем выставляется при сохранении сцены.
Это может помочь если какая-то анимация, скажем idle, выставила не ту позу, и все анимации начинают играться от нее, немного перекошенные.
>>880426
Кликнуть слева от номера строки, появится красная точка, в этой точке программа остановится, потом можно нажимать F9 и F10, чтобы выполнять по строчкам. (одна из них заходит внутрь функций).
Ну моя гипотеза та же , input получает разные события, например движения мыши, во всех эти случаях код попадает в else и опустошает массив.
Попробуй делать print(even) в начале, например.
Кликнуть слева от номера строки, появится красная точка, в этой точке программа остановится, потом можно нажимать F9 и F10, чтобы выполнять по строчкам. (одна из них заходит внутрь функций).
>вот сам код
Ну моя гипотеза та же , input получает разные события, например движения мыши, во всех эти случаях код попадает в else и опустошает массив.
Попробуй делать print(even) в начале, например.
С# как юзать?
Отдельную сборку годота надо что ли?
И как он вообще, норм? Или ебаться надо будет?
Вроде читал что если шарп, то нельзя на андроид портировать?
Отдельную сборку годота надо что ли?
И как он вообще, норм? Или ебаться надо будет?
Вроде читал что если шарп, то нельзя на андроид портировать?
>>880434
Да, отдельная сборка в любом случае.
Да, вроде в 4.0 нет C# Android, iPhone и Web HTML.
В 3.х должно быть есть все, давно не проверял, можешь скачать export templates и посмотреть что там в папках.
Да, отдельная сборка в любом случае.
Да, вроде в 4.0 нет C# Android, iPhone и Web HTML.
В 3.х должно быть есть все, давно не проверял, можешь скачать export templates и посмотреть что там в папках.
>>880452
В плане? Я когда писал клеточные автоматы (типа "Жизнь") C# очевидно быстрее был в рассчетах.
В плане? Я когда писал клеточные автоматы (типа "Жизнь") C# очевидно быстрее был в рассчетах.
Куда еще можно закинуть свою инди-хуйню ради пиара? Итч чек, реддит чек. Больше ничего не знаю.
>>880454
На торренты в Горячии новинки
На торренты в Горячии новинки
Напишите годные уроки на ютубе на русском для новичка, желательно с обзора самой программы.
>>880318
Оно и не могло прийти. Синтаксис не подразумевает этого. Я сам подорвался на этой мине пару лет назад. Если в функции есть илд, то когда он срабатывает, функция возвращает специальный функшн-стейт вместо того, что она должна возвращать.
> А то что yield что-то возвращает мне даже в голову не пришло, лол
Оно и не могло прийти. Синтаксис не подразумевает этого. Я сам подорвался на этой мине пару лет назад. Если в функции есть илд, то когда он срабатывает, функция возвращает специальный функшн-стейт вместо того, что она должна возвращать.
>>880579
Спасибо
Спасибо
>>880664
Зачем на дваче то об этом спрашивать? Хостер отвалился.
https://github.com/godotengine/godot-website/issues/648
Зачем на дваче то об этом спрашивать? Хостер отвалился.
https://github.com/godotengine/godot-website/issues/648
>>880705
Фейк
Фейк
>>880705
Ты тредом ошиблась, дура.
Ты тредом ошиблась, дура.
Сегодня обнаружил в четвёрке новый шейдер неба PhysicSky, искаропки. Там реализована смена дня и ночи, но как обычно есть куча нюансов: при дефолтных настройках небо какое-то марсианское, и солнце на горизонте уменьшается, а не увеличивается, как можно было бы ожидать. Кто работал с ним? Делитесь опытом.
>>880735
О, не дописал. Там позиция солнца автоматом привязывается к имеющемуся в дереве DirectionLight3D и вращая его получаем движение солнца по небу, в т.ч. закат и восход.
> реализована смена дня и ночи
О, не дописал. Там позиция солнца автоматом привязывается к имеющемуся в дереве DirectionLight3D и вращая его получаем движение солнца по небу, в т.ч. закат и восход.
Годаны, а что с этим делать?
Точнее, не так. А надо ли с этим что-то делать? Ну, то есть, всё равно же приложение закрывается; движок и сам за собой подчистит, да и ОСь тоже проверит, чтоб ничего не оставалось.
Или как? Или надо обязательно перед выходом всё очищать?
>WARNING: ObjectDB instances leaked at exit
Точнее, не так. А надо ли с этим что-то делать? Ну, то есть, всё равно же приложение закрывается; движок и сам за собой подчистит, да и ОСь тоже проверит, чтоб ничего не оставалось.
Или как? Или надо обязательно перед выходом всё очищать?
>>880677
Срочно. Решил попробовать в годот вкатиться. Мне даже кешированный запрос с загрузкой файла не отдавал данные
Срочно. Решил попробовать в годот вкатиться. Мне даже кешированный запрос с загрузкой файла не отдавал данные
>>880770
Так ссылки на сборки ведут сюда
https://downloads.tuxfamily.org/godotengine/
Сами сборки делаются тут
https://github.com/godotengine/godot/actions
А документация сюда
https://readthedocs.org/projects/godot
Остаются ассеты, но там в кеше ссылки на гитхаб есть.
И форум Q&A, вот это ценно.
А в остальном это просто лендинг с новостями.
Все, вкатывайся без проблем.
Так ссылки на сборки ведут сюда
https://downloads.tuxfamily.org/godotengine/
Сами сборки делаются тут
https://github.com/godotengine/godot/actions
А документация сюда
https://readthedocs.org/projects/godot
Остаются ассеты, но там в кеше ссылки на гитхаб есть.
И форум Q&A, вот это ценно.
А в остальном это просто лендинг с новостями.
Все, вкатывайся без проблем.
>>880780
Это не для полноценного девелопа, это если у тебя в метро внезапная идея пришла и хочется немедленно обкатать, а до твоей станции с полноценным пекой ещё далеко.
Это не для полноценного девелопа, это если у тебя в метро внезапная идея пришла и хочется немедленно обкатать, а до твоей станции с полноценным пекой ещё далеко.
131 Кб, 980x715Сап, годач.
У меня в игре покадровая анимация, но анимация рук и тела может отличаться. И чтобы не делать каждый раз новый спрайт, захотелось части тело анимировать отдельно.
Добавить новый трек с анимациями рук годот не дает. А при таком использовании animationplayer они перекрывают друг друга и показывается только один
Как все это дело разделить корректно, чтобы я мог тонко настраивать, какую именно анимацию рук/тела показывать?
У меня в игре покадровая анимация, но анимация рук и тела может отличаться. И чтобы не делать каждый раз новый спрайт, захотелось части тело анимировать отдельно.
Добавить новый трек с анимациями рук годот не дает. А при таком использовании animationplayer они перекрывают друг друга и показывается только один
Как все это дело разделить корректно, чтобы я мог тонко настраивать, какую именно анимацию рук/тела показывать?
>>880821
Кури Animationtree и там blend. Погугли как в контроллерах делают, там как раз смешивают например анимацию ходьбы и прицеливания с рук. Там еще есть галочки какие использовать кости. https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html
Кури Animationtree и там blend. Погугли как в контроллерах делают, там как раз смешивают например анимацию ходьбы и прицеливания с рук. Там еще есть галочки какие использовать кости. https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html
>>880802
Сможешь.
Сможешь.
Подробный гайд по автоимпорту блендер-файлов в годот
https://youtu.be/6TsdmFvkw9w
https://youtu.be/6TsdmFvkw9w
Dev snapshot: Godot 4.1 beta 1
13 Кб, 300x300И тут я попробовал свой 3д проэкт эскпортнуть в HTML5
мне нравится годот но тут уже ничего не сделаешь, для яндекс игр только унити
>загружается 15 секунд
>на Юнити 4 секунды
>весят одинаково
>3д анимации не работают
>мешы тупо не загружаются
>тач контрол не работает
мне нравится годот но тут уже ничего не сделаешь, для яндекс игр только унити
>>881031
Это у тебя в 4-ке что ли? В 3 ке на джемах часто делали 3д экшоны, с мешами и анимациями все было нормально. Время загрузки конечно не быстроею
Это у тебя в 4-ке что ли? В 3 ке на джемах часто делали 3д экшоны, с мешами и анимациями все было нормально. Время загрузки конечно не быстроею
>>875148
Зависит от плотности контента на экране и в твоих чанках. Если у тебя низкое количество уникальных спрайтов на экране, то тормозить нечему. Если у тебя есть места скопления множества уникальных спрайтов, то на слабом компьютере игра может тормозить во время загрузки и отображения тяжёлого чанка (с уровневой системой это не критично, а вот в бесшовном мире будет напрягать игрока). Также зависит от того, нужно ли тебе обрабатывать что-то далеко за пределами экрана или мир за кадром может оставаться в замороженном состоянии. Также зависит от максимальной скорости персонажа, т.к. чем быстрее движение, тем чаще нужно загружать чанки, и если скорость ничем не ограничена, рано или поздно достигается предел ресурсов любого компьютера.
>>875156
Базовая чанковая система тривиальна и делается за вечер. Тебе всё равно придётся делать какую-то свою систему сохранения и загрузки состояния мира, если ты делаешь что-то сложнее платформера. Чанковая система - лёгкая надстройка над системой сохранения и загрузки, потому что всё, что она делает - выборочно сохраняет и загружает отдельные фрагменты мира.
>>875160
Не нужно, это плодит лишние сущности.
Делаешь что-то такое:
- Game
- - Map
- - - Chunk1
- - - Chunk2
- - - Chunk3
- - - ...
- - - Player
- - - Mobs
Проверка принадлежности Player к одному из чанков выполняется двумя операциями деления его координат на размер одного чанка (чанки обычно одного размера, этим они отличаются от классических игровых уровней), после чего можно поставить в очередь загрузку необходимых чанков и выгрузку лишних (очередь снизит пиковую нагрузку). Аналогично с мобами, если они могут переходить между чанками и сохраняться в них.
Нет, если планируется делать большую карту из множества разных по форме и размеру фрагментов, скрепляя их между собой "порталами" для бесшовной загрузки, тогда твой подход с облепливанием Area имеет смысл. Можно сделать универсальную ноду-портал с полями для указания следующего фрагмента карты с точкой входа в него, а дальше можно будет сравнительно быстро скреплять между собой фрагменты геометрически невозможными способами (т.е. общую карту невозможно отобразить на двухмерной плоскости). Но я бы не стал называть такой подход "чанковой системой", даже несмотря на то, что в результате получается большой бесшовный мир. Всё-таки вместо квадратных чанков тут произвольные куски и переходы могут быть совершенно любыми, а не только в декартовой системе координат...
Но для обычного бесшовного 2D мира подход с Area не имеет смысла, т.к. чанки одного размера и располагаются в одной плоскости по сетке. Area имеет смысл размещать на входах в пещеры и дома а-ля jRPG, ради удобства левел-дизайна, т.к. такие входы могут быть в произвольных точках карты, а переходы на границах стандартного квадратного чанка расставлять - бессмысленное захламление сцены нодами и потенциально лишние операции на проверку коллизий в движке, что может стать проблемой, если чанки сравнительно маленькие (скажем, на экране умещается несколько десятков чанков при максимальном отдалении камеры - это уже больше сотни лишних Area).
>большой 2D мир (вид сверху) без пролагов?
Зависит от плотности контента на экране и в твоих чанках. Если у тебя низкое количество уникальных спрайтов на экране, то тормозить нечему. Если у тебя есть места скопления множества уникальных спрайтов, то на слабом компьютере игра может тормозить во время загрузки и отображения тяжёлого чанка (с уровневой системой это не критично, а вот в бесшовном мире будет напрягать игрока). Также зависит от того, нужно ли тебе обрабатывать что-то далеко за пределами экрана или мир за кадром может оставаться в замороженном состоянии. Также зависит от максимальной скорости персонажа, т.к. чем быстрее движение, тем чаще нужно загружать чанки, и если скорость ничем не ограничена, рано или поздно достигается предел ресурсов любого компьютера.
>>875156
>на реализацию чанков потратишь много времени
Базовая чанковая система тривиальна и делается за вечер. Тебе всё равно придётся делать какую-то свою систему сохранения и загрузки состояния мира, если ты делаешь что-то сложнее платформера. Чанковая система - лёгкая надстройка над системой сохранения и загрузки, потому что всё, что она делает - выборочно сохраняет и загружает отдельные фрагменты мира.
>>875160
>по периметру расставляем Area
Не нужно, это плодит лишние сущности.
Делаешь что-то такое:
- Game
- - Map
- - - Chunk1
- - - Chunk2
- - - Chunk3
- - - ...
- - - Player
- - - Mobs
Проверка принадлежности Player к одному из чанков выполняется двумя операциями деления его координат на размер одного чанка (чанки обычно одного размера, этим они отличаются от классических игровых уровней), после чего можно поставить в очередь загрузку необходимых чанков и выгрузку лишних (очередь снизит пиковую нагрузку). Аналогично с мобами, если они могут переходить между чанками и сохраняться в них.
Нет, если планируется делать большую карту из множества разных по форме и размеру фрагментов, скрепляя их между собой "порталами" для бесшовной загрузки, тогда твой подход с облепливанием Area имеет смысл. Можно сделать универсальную ноду-портал с полями для указания следующего фрагмента карты с точкой входа в него, а дальше можно будет сравнительно быстро скреплять между собой фрагменты геометрически невозможными способами (т.е. общую карту невозможно отобразить на двухмерной плоскости). Но я бы не стал называть такой подход "чанковой системой", даже несмотря на то, что в результате получается большой бесшовный мир. Всё-таки вместо квадратных чанков тут произвольные куски и переходы могут быть совершенно любыми, а не только в декартовой системе координат...
Но для обычного бесшовного 2D мира подход с Area не имеет смысла, т.к. чанки одного размера и располагаются в одной плоскости по сетке. Area имеет смысл размещать на входах в пещеры и дома а-ля jRPG, ради удобства левел-дизайна, т.к. такие входы могут быть в произвольных точках карты, а переходы на границах стандартного квадратного чанка расставлять - бессмысленное захламление сцены нодами и потенциально лишние операции на проверку коллизий в движке, что может стать проблемой, если чанки сравнительно маленькие (скажем, на экране умещается несколько десятков чанков при максимальном отдалении камеры - это уже больше сотни лишних Area).
>>875148
Зависит от плотности контента на экране и в твоих чанках. Если у тебя низкое количество уникальных спрайтов на экране, то тормозить нечему. Если у тебя есть места скопления множества уникальных спрайтов, то на слабом компьютере игра может тормозить во время загрузки и отображения тяжёлого чанка (с уровневой системой это не критично, а вот в бесшовном мире будет напрягать игрока). Также зависит от того, нужно ли тебе обрабатывать что-то далеко за пределами экрана или мир за кадром может оставаться в замороженном состоянии. Также зависит от максимальной скорости персонажа, т.к. чем быстрее движение, тем чаще нужно загружать чанки, и если скорость ничем не ограничена, рано или поздно достигается предел ресурсов любого компьютера.
>>875156
Базовая чанковая система тривиальна и делается за вечер. Тебе всё равно придётся делать какую-то свою систему сохранения и загрузки состояния мира, если ты делаешь что-то сложнее платформера. Чанковая система - лёгкая надстройка над системой сохранения и загрузки, потому что всё, что она делает - выборочно сохраняет и загружает отдельные фрагменты мира.
>>875160
Не нужно, это плодит лишние сущности.
Делаешь что-то такое:
- Game
- - Map
- - - Chunk1
- - - Chunk2
- - - Chunk3
- - - ...
- - - Player
- - - Mobs
Проверка принадлежности Player к одному из чанков выполняется двумя операциями деления его координат на размер одного чанка (чанки обычно одного размера, этим они отличаются от классических игровых уровней), после чего можно поставить в очередь загрузку необходимых чанков и выгрузку лишних (очередь снизит пиковую нагрузку). Аналогично с мобами, если они могут переходить между чанками и сохраняться в них.
Нет, если планируется делать большую карту из множества разных по форме и размеру фрагментов, скрепляя их между собой "порталами" для бесшовной загрузки, тогда твой подход с облепливанием Area имеет смысл. Можно сделать универсальную ноду-портал с полями для указания следующего фрагмента карты с точкой входа в него, а дальше можно будет сравнительно быстро скреплять между собой фрагменты геометрически невозможными способами (т.е. общую карту невозможно отобразить на двухмерной плоскости). Но я бы не стал называть такой подход "чанковой системой", даже несмотря на то, что в результате получается большой бесшовный мир. Всё-таки вместо квадратных чанков тут произвольные куски и переходы могут быть совершенно любыми, а не только в декартовой системе координат...
Но для обычного бесшовного 2D мира подход с Area не имеет смысла, т.к. чанки одного размера и располагаются в одной плоскости по сетке. Area имеет смысл размещать на входах в пещеры и дома а-ля jRPG, ради удобства левел-дизайна, т.к. такие входы могут быть в произвольных точках карты, а переходы на границах стандартного квадратного чанка расставлять - бессмысленное захламление сцены нодами и потенциально лишние операции на проверку коллизий в движке, что может стать проблемой, если чанки сравнительно маленькие (скажем, на экране умещается несколько десятков чанков при максимальном отдалении камеры - это уже больше сотни лишних Area).
>большой 2D мир (вид сверху) без пролагов?
Зависит от плотности контента на экране и в твоих чанках. Если у тебя низкое количество уникальных спрайтов на экране, то тормозить нечему. Если у тебя есть места скопления множества уникальных спрайтов, то на слабом компьютере игра может тормозить во время загрузки и отображения тяжёлого чанка (с уровневой системой это не критично, а вот в бесшовном мире будет напрягать игрока). Также зависит от того, нужно ли тебе обрабатывать что-то далеко за пределами экрана или мир за кадром может оставаться в замороженном состоянии. Также зависит от максимальной скорости персонажа, т.к. чем быстрее движение, тем чаще нужно загружать чанки, и если скорость ничем не ограничена, рано или поздно достигается предел ресурсов любого компьютера.
>>875156
>на реализацию чанков потратишь много времени
Базовая чанковая система тривиальна и делается за вечер. Тебе всё равно придётся делать какую-то свою систему сохранения и загрузки состояния мира, если ты делаешь что-то сложнее платформера. Чанковая система - лёгкая надстройка над системой сохранения и загрузки, потому что всё, что она делает - выборочно сохраняет и загружает отдельные фрагменты мира.
>>875160
>по периметру расставляем Area
Не нужно, это плодит лишние сущности.
Делаешь что-то такое:
- Game
- - Map
- - - Chunk1
- - - Chunk2
- - - Chunk3
- - - ...
- - - Player
- - - Mobs
Проверка принадлежности Player к одному из чанков выполняется двумя операциями деления его координат на размер одного чанка (чанки обычно одного размера, этим они отличаются от классических игровых уровней), после чего можно поставить в очередь загрузку необходимых чанков и выгрузку лишних (очередь снизит пиковую нагрузку). Аналогично с мобами, если они могут переходить между чанками и сохраняться в них.
Нет, если планируется делать большую карту из множества разных по форме и размеру фрагментов, скрепляя их между собой "порталами" для бесшовной загрузки, тогда твой подход с облепливанием Area имеет смысл. Можно сделать универсальную ноду-портал с полями для указания следующего фрагмента карты с точкой входа в него, а дальше можно будет сравнительно быстро скреплять между собой фрагменты геометрически невозможными способами (т.е. общую карту невозможно отобразить на двухмерной плоскости). Но я бы не стал называть такой подход "чанковой системой", даже несмотря на то, что в результате получается большой бесшовный мир. Всё-таки вместо квадратных чанков тут произвольные куски и переходы могут быть совершенно любыми, а не только в декартовой системе координат...
Но для обычного бесшовного 2D мира подход с Area не имеет смысла, т.к. чанки одного размера и располагаются в одной плоскости по сетке. Area имеет смысл размещать на входах в пещеры и дома а-ля jRPG, ради удобства левел-дизайна, т.к. такие входы могут быть в произвольных точках карты, а переходы на границах стандартного квадратного чанка расставлять - бессмысленное захламление сцены нодами и потенциально лишние операции на проверку коллизий в движке, что может стать проблемой, если чанки сравнительно маленькие (скажем, на экране умещается несколько десятков чанков при максимальном отдалении камеры - это уже больше сотни лишних Area).
>>881088
Попробовал свою игрулю, тоже за 15 секунд до игровой сцены, да вроде терпимо. Надо посмотреть, может если сначала только легковесное меню загружать, быстрее будет. И вообще посмотреть нельзя ли на pck разбить и грузить динамически.
Попробовал свою игрулю, тоже за 15 секунд до игровой сцены, да вроде терпимо. Надо посмотреть, может если сначала только легковесное меню загружать, быстрее будет. И вообще посмотреть нельзя ли на pck разбить и грузить динамически.
>>875926
Я не знаю, что они там в 4.0 натворили с гридмапом, но в тройке гридмап внутри оптимизируется через мультимеш следующим образом: в настройках гридмапа указаны размеры "чанка" (по умолчанию вроде бы 8x8x8), для которого создаются отдельные мультимеши на каждый использованный в чанке тип блока.
>>875848
Если у тебя настройки по умолчанию, то это примерно 343 мультимеша на каждый тип блока, при условии, что каждый чанк заполнен хотя бы одним блоком одного типа. Тебе стоило бы увеличить размер чанка в настройках гридмапа и посмотреть, как это повлияет на производительность.
Мне лично гридмап неудобен тем, что он отнимает много времени на добавление/удаление блоков. Т.е. гридмап достаточно оптимален пока статичен, но частые модификации слишком медленные. Как я понимаю, задержки вызваны необходимостью пересоздать мультимеш на каждое добавление блока. Жаль, что не догадались сделать функции типа glBegin/glEnd.
>гридмап
>мультимеш
Я не знаю, что они там в 4.0 натворили с гридмапом, но в тройке гридмап внутри оптимизируется через мультимеш следующим образом: в настройках гридмапа указаны размеры "чанка" (по умолчанию вроде бы 8x8x8), для которого создаются отдельные мультимеши на каждый использованный в чанке тип блока.
>>875848
>50,50,50 блоков
Если у тебя настройки по умолчанию, то это примерно 343 мультимеша на каждый тип блока, при условии, что каждый чанк заполнен хотя бы одним блоком одного типа. Тебе стоило бы увеличить размер чанка в настройках гридмапа и посмотреть, как это повлияет на производительность.
Мне лично гридмап неудобен тем, что он отнимает много времени на добавление/удаление блоков. Т.е. гридмап достаточно оптимален пока статичен, но частые модификации слишком медленные. Как я понимаю, задержки вызваны необходимостью пересоздать мультимеш на каждое добавление блока. Жаль, что не догадались сделать функции типа glBegin/glEnd.
>>876566
Спорно. Хотя бы потому, что есть ММОРПГ.
Алсо под "РПГ" обычно понимают "бей мобов, дрочи циферки, продавай лут", а не килотонны сюжета.
Опять же спорно, потому что есть ПО для космических аппаратов и прочих систем повышенной опасности... Это не какие-то игрушки, слепленные из говнокода и вызывающие перегрев у самых мощных игровых ПК.
Конструкторы игр давно позволяют сделать свою собственную, уникальную игру любому дошкольнику, просто тыкая на забавные пиктограммы. Кодинг сведён до нуля, достаточно сделать картинки.
Опять же не всё так просто, потому что кликеры - это максимально редуцированные РПГ. Если в РПГ ты вынужден прорываться через тонны лишней графики и скучных букв для дроча на циферки, то кликер избавляет тебя от этой рутины, давая доступ напрямую к дрочу циферок. А достаточно сложный кликер может иметь столько сюжета и уникальной графики, сколько редко найдёшь в поделках на рпг мейкере с его тайлсетами по умолчанию, которыми школьники завалили все интернеты.
Да ты сам поди школотой был, когда первый раз задумался о разработке собственной игры. В айти люди идут чаще всего не по собственному желанию, а потому что там предлагают много денег тем, кто шарит в компах. В геймдеве же всё наоборот: желающие создать игру вынужденно начинают шарить в компах. Вряд ли кто-то мечтает верстать сайты, поднимать сервисы и делать запросы к базам данных, зато многие мечтают создать нечто похожее на игру, которая впечатлила их в детстве. По-моему, это должно быть очевидно любому, кто хоть немного наблюдал за инди геймдевом...
>Эрпогэ - вершина геймдева.
Спорно. Хотя бы потому, что есть ММОРПГ.
Алсо под "РПГ" обычно понимают "бей мобов, дрочи циферки, продавай лут", а не килотонны сюжета.
>А Геймдев - вершина айти.
Опять же спорно, потому что есть ПО для космических аппаратов и прочих систем повышенной опасности... Это не какие-то игрушки, слепленные из говнокода и вызывающие перегрев у самых мощных игровых ПК.
>Самая простая игра сложнее самого навороченного КРУДа.
Конструкторы игр давно позволяют сделать свою собственную, уникальную игру любому дошкольнику, просто тыкая на забавные пиктограммы. Кодинг сведён до нуля, достаточно сделать картинки.
>Самая простая эрпогэ сложнее самых навороченных кликеров.
Опять же не всё так просто, потому что кликеры - это максимально редуцированные РПГ. Если в РПГ ты вынужден прорываться через тонны лишней графики и скучных букв для дроча на циферки, то кликер избавляет тебя от этой рутины, давая доступ напрямую к дрочу циферок. А достаточно сложный кликер может иметь столько сюжета и уникальной графики, сколько редко найдёшь в поделках на рпг мейкере с его тайлсетами по умолчанию, которыми школьники завалили все интернеты.
>Мне удивительно видеть, как люди без опыта в айти лезут в геймдев.
Да ты сам поди школотой был, когда первый раз задумался о разработке собственной игры. В айти люди идут чаще всего не по собственному желанию, а потому что там предлагают много денег тем, кто шарит в компах. В геймдеве же всё наоборот: желающие создать игру вынужденно начинают шарить в компах. Вряд ли кто-то мечтает верстать сайты, поднимать сервисы и делать запросы к базам данных, зато многие мечтают создать нечто похожее на игру, которая впечатлила их в детстве. По-моему, это должно быть очевидно любому, кто хоть немного наблюдал за инди геймдевом...
651 Кб, webm,960x960, 0:15
>>881091
Я почитал, и у Годота пока вообще проблемы с 3д браузерками - на эпле особенно, да и андройде полно косяков, которые надо безумными костылями лечить. Буду следить за его развитием, т.к. легковесный и бесплатный, но для ковки железа пока унити
Я почитал, и у Годота пока вообще проблемы с 3д браузерками - на эпле особенно, да и андройде полно косяков, которые надо безумными костылями лечить. Буду следить за его развитием, т.к. легковесный и бесплатный, но для ковки железа пока унити
>>881095
Шо поделать, у тебя специфичные требования - чтоб на мобилке, но в браузере. Для мобилок так то нативные приложения делают.
Для веба вообще много легковесных рендеров, я прямо на three.js игры продавал.
Шо поделать, у тебя специфичные требования - чтоб на мобилке, но в браузере. Для мобилок так то нативные приложения делают.
Для веба вообще много легковесных рендеров, я прямо на three.js игры продавал.
>>879856
Этот огород? Или что ты имеешь в виду?
Я правильно понял, что ты хочешь сделать так?
Лично мне первый вариант больше нравится. Не вижу никакого преимущества у второго варианта...
>Я вот в ужасе представлял, какой огород мне придется городить, чтобы ждать завершения вражеских анимаций в их ход, а тут оказывается, что я могу тупо во вражеский ход пройтись по всем врагам циклом.
Этот огород? Или что ты имеешь в виду?
>signal game_over()
>var whose_turn: int = 0
>var units: Array = []
>func _ready() -> void:
>_ units = get_children()
>_ for unit in units:
>_ _ unit.turn_done.connect(next_turn)
>_ units[whose_turn].make_turn()
>func next_turn(dead: bool) -> void:
>_ if not dead: whose_turn += 1
>_ else:
>_ _ if units[whose_turn] is Player: game_over.emit()
>_ _ else: units.remove_at(whose_turn)
>_ whose_turn %= units.size()
>_ units[whose_turn].make_turn()
Я правильно понял, что ты хочешь сделать так?
>signal game_over()
>var units: Array = []
>func _ready() -> void:
>_ units = get_children()
>_ run()
>func run() -> void:
>_ while true:
>_ _ var j: int = 0
>_ _ while j < units.size():
>_ _ _ units[j].make_turn()
>_ _ _ await units[j].turn_done()
>_ _ _ if units[j].is_dead():
>_ _ _ _ if units[j] is Player: game_over.emit()
>_ _ _ _ else: units.remove_at(j)
>_ _ _ else: j += 1
Лично мне первый вариант больше нравится. Не вижу никакого преимущества у второго варианта...
>>879856
Этот огород? Или что ты имеешь в виду?
Я правильно понял, что ты хочешь сделать так?
Лично мне первый вариант больше нравится. Не вижу никакого преимущества у второго варианта...
>Я вот в ужасе представлял, какой огород мне придется городить, чтобы ждать завершения вражеских анимаций в их ход, а тут оказывается, что я могу тупо во вражеский ход пройтись по всем врагам циклом.
Этот огород? Или что ты имеешь в виду?
>signal game_over()
>var whose_turn: int = 0
>var units: Array = []
>func _ready() -> void:
>_ units = get_children()
>_ for unit in units:
>_ _ unit.turn_done.connect(next_turn)
>_ units[whose_turn].make_turn()
>func next_turn(dead: bool) -> void:
>_ if not dead: whose_turn += 1
>_ else:
>_ _ if units[whose_turn] is Player: game_over.emit()
>_ _ else: units.remove_at(whose_turn)
>_ whose_turn %= units.size()
>_ units[whose_turn].make_turn()
Я правильно понял, что ты хочешь сделать так?
>signal game_over()
>var units: Array = []
>func _ready() -> void:
>_ units = get_children()
>_ run()
>func run() -> void:
>_ while true:
>_ _ var j: int = 0
>_ _ while j < units.size():
>_ _ _ units[j].make_turn()
>_ _ _ await units[j].turn_done()
>_ _ _ if units[j].is_dead():
>_ _ _ _ if units[j] is Player: game_over.emit()
>_ _ _ _ else: units.remove_at(j)
>_ _ _ else: j += 1
Лично мне первый вариант больше нравится. Не вижу никакого преимущества у второго варианта...
>>880367
Таки в чём проблема? У тебя там модель на 100500 терабайт лепнины? Просто закинул в папку и через 0.001 секунды всё импортировалось.
Вроде можно исходные .blend файлы закидывать.
>тут тупо каждую 3д модель надо сразу со всеми анимацими экспортировать, а если нужно добавить анимацю, то весь ассет с нуля переимпортировать
Таки в чём проблема? У тебя там модель на 100500 терабайт лепнины? Просто закинул в папку и через 0.001 секунды всё импортировалось.
Вроде можно исходные .blend файлы закидывать.
Недавно решил вкатиться в этот ваш годот. Рассказывайте, какие тут лимитации. Что в этом говне можно сделать, а что просто тупо нельзя из-за ограничений движка?
>>881126
Зачем тебе что-то всерьёз объяснять, если ты с порога ругаешься и заранее негативно настроен? Вкатывайся в движок, который для тебя не говно и безлимитный.
Лучше всего на твои вопросы ответит документация:
https://docs.godotengine.org/en/stable/about/introduction.html
Вкратце:
1. Движок опенсурс, весь код абсолютно бесплатно доступен для скачивания, модификации и компиляции без СМС и регистрации; сборки движка и игры на кастомных сборках можно распространять без разглашения изменений, даже в коммерческих целях. Единственное, что от тебя просят - оставить пометку о том, что твой продукт создан с использованием исходников Godot. Свободнее этого может быть только публичное достояние. Таким образом, умея кодить на C++, перед тобой нет никаких ограничений.
2. Если ты не знаешь C++ или не имеешь способности разбираться в чужом коде, ты можешь делать модули для движка на любом языке программирования, который умеет в компиляцию динамически подключаемых библиотек. То есть на любом серьёзном ЯП. Это не даёт модифицировать ядро движка, но может помочь с добавлением функций, для которых нужно нативное взаимодействия с целевой ОС, а также для прикручивания готовых сторонних систем на других ЯП. Можно написать всю основную логику игры как внешний модуль на любом удобном ЯП, чтобы в случае чего быстро сменить движок без переписывания своего кода.
3. Если ты вообще не программист, а вебмакака или скриптопися, то тебе остаётся только использовать доступный из коробки GDScript или какой-то другой скриптовый язык, который прикрутило сообщество, но надёжнее всего официальный GDScript. Из коробки доступно много высокоуровневых компонентов и богатое низкоуровневое API, а также возможность писать свои аддоны и модификации IDE непосредственно в самой IDE, даже без перезапусков. Т.е. ты можешь легко написать свой собственный инструмент и сразу начать его использовать, не отвлекаясь от основного проекта и окна редактора. Таким образом, большинству игр ничего кроме GDScript и встроенных функций не нужно. Ты можешь упереться в ограничение только если тебе требуется какая-то уникальная фича, доступная только на одной ОС, или если ты хочешь выпустить игру на какую-то малоизвестную платформу. Тогда придётся изучать C++ или искать кого-то, кто сможет помочь изменить исходники движка для конкретной особенной платформы.
4. Если ты яждизайнер и рассчитываешь собирать игру из блоков, адаптированных для маленьких детей, то этот движок рассчитан на людей постарше. В версии 3.x был визуальный язык, но его не смогли адаптировать для маленьких детей и поэтому вырезали из 4.x. Говорят, что при наличии желающих визуальный язык вернётся в виде опционального внешнего модуля. В общем, пока что движок не подходит для маленьких яждизайнеров, и если ты попадаешь в эту категорию, лучше посмотреть в сторону конструкторов игр наподобие Game Maker, Scirra Construct, 001 Game Creator и что там ещё опирается на создание игровой логики из визуальных кубиков... сотни их, все наступают на одни и те же грабли.
Есть один нюанс с выходом на никому не нужные игровые приставки: для сборки на них требуется их SDK, но он защищён NDA, поэтому опенсурс движки не имеют юридической возможности сделать экспорт на игровые приставки и остаться при этом опенсурс. Собственно, не велика потеря, потому что игровые приставки имеют наименьшую долю рынка и продолжают умирать, но для извращенцев и ностальгирующих есть возможность либо самостоятельно собрать движок на приставку, либо заплатить кабанчику, который подскочит и сделает это за тебя. Основные разрабы движка несколько лет планируют организовать официальный сервис для сборки на приставки, но, как я понял, это сложно организовать в опенсурс сообществе и желающих издавать игру на приставки в любом случае слишком мало, поэтому эта задача никогда не была в приоритете.
>этот ваш годот
>лимитации
>в этом говне
>тупо нельзя из-за ограничений
Зачем тебе что-то всерьёз объяснять, если ты с порога ругаешься и заранее негативно настроен? Вкатывайся в движок, который для тебя не говно и безлимитный.
Лучше всего на твои вопросы ответит документация:
https://docs.godotengine.org/en/stable/about/introduction.html
Вкратце:
1. Движок опенсурс, весь код абсолютно бесплатно доступен для скачивания, модификации и компиляции без СМС и регистрации; сборки движка и игры на кастомных сборках можно распространять без разглашения изменений, даже в коммерческих целях. Единственное, что от тебя просят - оставить пометку о том, что твой продукт создан с использованием исходников Godot. Свободнее этого может быть только публичное достояние. Таким образом, умея кодить на C++, перед тобой нет никаких ограничений.
2. Если ты не знаешь C++ или не имеешь способности разбираться в чужом коде, ты можешь делать модули для движка на любом языке программирования, который умеет в компиляцию динамически подключаемых библиотек. То есть на любом серьёзном ЯП. Это не даёт модифицировать ядро движка, но может помочь с добавлением функций, для которых нужно нативное взаимодействия с целевой ОС, а также для прикручивания готовых сторонних систем на других ЯП. Можно написать всю основную логику игры как внешний модуль на любом удобном ЯП, чтобы в случае чего быстро сменить движок без переписывания своего кода.
3. Если ты вообще не программист, а вебмакака или скриптопися, то тебе остаётся только использовать доступный из коробки GDScript или какой-то другой скриптовый язык, который прикрутило сообщество, но надёжнее всего официальный GDScript. Из коробки доступно много высокоуровневых компонентов и богатое низкоуровневое API, а также возможность писать свои аддоны и модификации IDE непосредственно в самой IDE, даже без перезапусков. Т.е. ты можешь легко написать свой собственный инструмент и сразу начать его использовать, не отвлекаясь от основного проекта и окна редактора. Таким образом, большинству игр ничего кроме GDScript и встроенных функций не нужно. Ты можешь упереться в ограничение только если тебе требуется какая-то уникальная фича, доступная только на одной ОС, или если ты хочешь выпустить игру на какую-то малоизвестную платформу. Тогда придётся изучать C++ или искать кого-то, кто сможет помочь изменить исходники движка для конкретной особенной платформы.
4. Если ты яждизайнер и рассчитываешь собирать игру из блоков, адаптированных для маленьких детей, то этот движок рассчитан на людей постарше. В версии 3.x был визуальный язык, но его не смогли адаптировать для маленьких детей и поэтому вырезали из 4.x. Говорят, что при наличии желающих визуальный язык вернётся в виде опционального внешнего модуля. В общем, пока что движок не подходит для маленьких яждизайнеров, и если ты попадаешь в эту категорию, лучше посмотреть в сторону конструкторов игр наподобие Game Maker, Scirra Construct, 001 Game Creator и что там ещё опирается на создание игровой логики из визуальных кубиков... сотни их, все наступают на одни и те же грабли.
Есть один нюанс с выходом на никому не нужные игровые приставки: для сборки на них требуется их SDK, но он защищён NDA, поэтому опенсурс движки не имеют юридической возможности сделать экспорт на игровые приставки и остаться при этом опенсурс. Собственно, не велика потеря, потому что игровые приставки имеют наименьшую долю рынка и продолжают умирать, но для извращенцев и ностальгирующих есть возможность либо самостоятельно собрать движок на приставку, либо заплатить кабанчику, который подскочит и сделает это за тебя. Основные разрабы движка несколько лет планируют организовать официальный сервис для сборки на приставки, но, как я понял, это сложно организовать в опенсурс сообществе и желающих издавать игру на приставки в любом случае слишком мало, поэтому эта задача никогда не была в приоритете.
>>881126
Зачем тебе что-то всерьёз объяснять, если ты с порога ругаешься и заранее негативно настроен? Вкатывайся в движок, который для тебя не говно и безлимитный.
Лучше всего на твои вопросы ответит документация:
https://docs.godotengine.org/en/stable/about/introduction.html
Вкратце:
1. Движок опенсурс, весь код абсолютно бесплатно доступен для скачивания, модификации и компиляции без СМС и регистрации; сборки движка и игры на кастомных сборках можно распространять без разглашения изменений, даже в коммерческих целях. Единственное, что от тебя просят - оставить пометку о том, что твой продукт создан с использованием исходников Godot. Свободнее этого может быть только публичное достояние. Таким образом, умея кодить на C++, перед тобой нет никаких ограничений.
2. Если ты не знаешь C++ или не имеешь способности разбираться в чужом коде, ты можешь делать модули для движка на любом языке программирования, который умеет в компиляцию динамически подключаемых библиотек. То есть на любом серьёзном ЯП. Это не даёт модифицировать ядро движка, но может помочь с добавлением функций, для которых нужно нативное взаимодействия с целевой ОС, а также для прикручивания готовых сторонних систем на других ЯП. Можно написать всю основную логику игры как внешний модуль на любом удобном ЯП, чтобы в случае чего быстро сменить движок без переписывания своего кода.
3. Если ты вообще не программист, а вебмакака или скриптопися, то тебе остаётся только использовать доступный из коробки GDScript или какой-то другой скриптовый язык, который прикрутило сообщество, но надёжнее всего официальный GDScript. Из коробки доступно много высокоуровневых компонентов и богатое низкоуровневое API, а также возможность писать свои аддоны и модификации IDE непосредственно в самой IDE, даже без перезапусков. Т.е. ты можешь легко написать свой собственный инструмент и сразу начать его использовать, не отвлекаясь от основного проекта и окна редактора. Таким образом, большинству игр ничего кроме GDScript и встроенных функций не нужно. Ты можешь упереться в ограничение только если тебе требуется какая-то уникальная фича, доступная только на одной ОС, или если ты хочешь выпустить игру на какую-то малоизвестную платформу. Тогда придётся изучать C++ или искать кого-то, кто сможет помочь изменить исходники движка для конкретной особенной платформы.
4. Если ты яждизайнер и рассчитываешь собирать игру из блоков, адаптированных для маленьких детей, то этот движок рассчитан на людей постарше. В версии 3.x был визуальный язык, но его не смогли адаптировать для маленьких детей и поэтому вырезали из 4.x. Говорят, что при наличии желающих визуальный язык вернётся в виде опционального внешнего модуля. В общем, пока что движок не подходит для маленьких яждизайнеров, и если ты попадаешь в эту категорию, лучше посмотреть в сторону конструкторов игр наподобие Game Maker, Scirra Construct, 001 Game Creator и что там ещё опирается на создание игровой логики из визуальных кубиков... сотни их, все наступают на одни и те же грабли.
Есть один нюанс с выходом на никому не нужные игровые приставки: для сборки на них требуется их SDK, но он защищён NDA, поэтому опенсурс движки не имеют юридической возможности сделать экспорт на игровые приставки и остаться при этом опенсурс. Собственно, не велика потеря, потому что игровые приставки имеют наименьшую долю рынка и продолжают умирать, но для извращенцев и ностальгирующих есть возможность либо самостоятельно собрать движок на приставку, либо заплатить кабанчику, который подскочит и сделает это за тебя. Основные разрабы движка несколько лет планируют организовать официальный сервис для сборки на приставки, но, как я понял, это сложно организовать в опенсурс сообществе и желающих издавать игру на приставки в любом случае слишком мало, поэтому эта задача никогда не была в приоритете.
>этот ваш годот
>лимитации
>в этом говне
>тупо нельзя из-за ограничений
Зачем тебе что-то всерьёз объяснять, если ты с порога ругаешься и заранее негативно настроен? Вкатывайся в движок, который для тебя не говно и безлимитный.
Лучше всего на твои вопросы ответит документация:
https://docs.godotengine.org/en/stable/about/introduction.html
Вкратце:
1. Движок опенсурс, весь код абсолютно бесплатно доступен для скачивания, модификации и компиляции без СМС и регистрации; сборки движка и игры на кастомных сборках можно распространять без разглашения изменений, даже в коммерческих целях. Единственное, что от тебя просят - оставить пометку о том, что твой продукт создан с использованием исходников Godot. Свободнее этого может быть только публичное достояние. Таким образом, умея кодить на C++, перед тобой нет никаких ограничений.
2. Если ты не знаешь C++ или не имеешь способности разбираться в чужом коде, ты можешь делать модули для движка на любом языке программирования, который умеет в компиляцию динамически подключаемых библиотек. То есть на любом серьёзном ЯП. Это не даёт модифицировать ядро движка, но может помочь с добавлением функций, для которых нужно нативное взаимодействия с целевой ОС, а также для прикручивания готовых сторонних систем на других ЯП. Можно написать всю основную логику игры как внешний модуль на любом удобном ЯП, чтобы в случае чего быстро сменить движок без переписывания своего кода.
3. Если ты вообще не программист, а вебмакака или скриптопися, то тебе остаётся только использовать доступный из коробки GDScript или какой-то другой скриптовый язык, который прикрутило сообщество, но надёжнее всего официальный GDScript. Из коробки доступно много высокоуровневых компонентов и богатое низкоуровневое API, а также возможность писать свои аддоны и модификации IDE непосредственно в самой IDE, даже без перезапусков. Т.е. ты можешь легко написать свой собственный инструмент и сразу начать его использовать, не отвлекаясь от основного проекта и окна редактора. Таким образом, большинству игр ничего кроме GDScript и встроенных функций не нужно. Ты можешь упереться в ограничение только если тебе требуется какая-то уникальная фича, доступная только на одной ОС, или если ты хочешь выпустить игру на какую-то малоизвестную платформу. Тогда придётся изучать C++ или искать кого-то, кто сможет помочь изменить исходники движка для конкретной особенной платформы.
4. Если ты яждизайнер и рассчитываешь собирать игру из блоков, адаптированных для маленьких детей, то этот движок рассчитан на людей постарше. В версии 3.x был визуальный язык, но его не смогли адаптировать для маленьких детей и поэтому вырезали из 4.x. Говорят, что при наличии желающих визуальный язык вернётся в виде опционального внешнего модуля. В общем, пока что движок не подходит для маленьких яждизайнеров, и если ты попадаешь в эту категорию, лучше посмотреть в сторону конструкторов игр наподобие Game Maker, Scirra Construct, 001 Game Creator и что там ещё опирается на создание игровой логики из визуальных кубиков... сотни их, все наступают на одни и те же грабли.
Есть один нюанс с выходом на никому не нужные игровые приставки: для сборки на них требуется их SDK, но он защищён NDA, поэтому опенсурс движки не имеют юридической возможности сделать экспорт на игровые приставки и остаться при этом опенсурс. Собственно, не велика потеря, потому что игровые приставки имеют наименьшую долю рынка и продолжают умирать, но для извращенцев и ностальгирующих есть возможность либо самостоятельно собрать движок на приставку, либо заплатить кабанчику, который подскочит и сделает это за тебя. Основные разрабы движка несколько лет планируют организовать официальный сервис для сборки на приставки, но, как я понял, это сложно организовать в опенсурс сообществе и желающих издавать игру на приставки в любом случае слишком мало, поэтому эта задача никогда не была в приоритете.
>>881179
Ну хуй знает, я б просто зарепортил и в движкосрач отправил. Не тот случай, когда человек заинтересован вкатиться в наше сообщество, так что ж с ним нянчиться?
Ну хуй знает, я б просто зарепортил и в движкосрач отправил. Не тот случай, когда человек заинтересован вкатиться в наше сообщество, так что ж с ним нянчиться?
>>881031
А я вот заметил что годот кэширует скачанное, может у тебя унитя тоже закешировалась?
У меня вот такая демка https://gdman.itch.io/godog
(анимированная моделька, лоуполи террйн и пара коробок)
Загружается 14 секунд в первый раз, но потом 4-6 секунд стартует.
Еще видел что gotm.io делает какую то магию перепаковывая pck, но я не смог пока это повторить. Но они уверяют что упаковывают картинки и что то еще в 2 раза, экономя еще 3 секунды.
А я вот заметил что годот кэширует скачанное, может у тебя унитя тоже закешировалась?
У меня вот такая демка https://gdman.itch.io/godog
(анимированная моделька, лоуполи террйн и пара коробок)
Загружается 14 секунд в первый раз, но потом 4-6 секунд стартует.
Еще видел что gotm.io делает какую то магию перепаковывая pck, но я не смог пока это повторить. Но они уверяют что упаковывают картинки и что то еще в 2 раза, экономя еще 3 секунды.
>>881199
Не Godot, а браузер. Браузер скачивает все файлы и затем запускает их. Godot, как и любая другая веб-программа, находится в виртуальной среде браузера, это ограничивает возможности.
На ПК можешь открыть встроенные в браузер средства отладки и посмотреть лично, сколько времени грузится каждый файл. Кэшированные на диск файлы будут отмечены как кэшированные.
>годот кэширует скачанное
Не Godot, а браузер. Браузер скачивает все файлы и затем запускает их. Godot, как и любая другая веб-программа, находится в виртуальной среде браузера, это ограничивает возможности.
На ПК можешь открыть встроенные в браузер средства отладки и посмотреть лично, сколько времени грузится каждый файл. Кэшированные на диск файлы будут отмечены как кэшированные.
>>881233
Толсто. Репортнул.
Толсто. Репортнул.
>>881233
Если он такой хороший, то почему у него так мало звёзд (6.3k) и так мало контрибьютеров (225)?
https://github.com/topics/game-engine
Очевидный лидер геймдева очевиден.
>>881265
На гитхабе релиз в мае по 2 Гб в двух архивах.
Если он такой хороший, то почему у него так мало звёзд (6.3k) и так мало контрибьютеров (225)?
https://github.com/topics/game-engine
Очевидный лидер геймдева очевиден.
>>881265
>оно занимает хуеву кучу места
На гитхабе релиз в мае по 2 Гб в двух архивах.
>>881272
Блять иди создай тред по своему любимому движку и не сри в других тредах. Не создаёшь - так всё равно для выяснений, чей инсталлятор лучше, есть движкосрач. Хули ты тут забыл?
Моча, заебал на репорты не отвечать, потри уже залётного.
Блять иди создай тред по своему любимому движку и не сри в других тредах. Не создаёшь - так всё равно для выяснений, чей инсталлятор лучше, есть движкосрач. Хули ты тут забыл?
Моча, заебал на репорты не отвечать, потри уже залётного.
>>881163
А мне понравился пост. Спасибо. Особенно про приставки и детей-яждизайнеров кекнул. Прямо в точку, бро!
мимоОП
А мне понравился пост. Спасибо. Особенно про приставки и детей-яждизайнеров кекнул. Прямо в точку, бро!
мимоОП
Анон какая площадка по обучению годо самая топовая?
Очень понравилось у юнити, простыми и понятными шагами всё делаешь, медальки дают и пр.
Очень понравилось у юнити, простыми и понятными шагами всё делаешь, медальки дают и пр.
>>881323
https://gdquest.github.io/learn-gdscript/
Я здесь пока учу сам язык (по-моему, тут уроки под старую версию годота, под 4.1 еще не запилили).
https://gdquest.github.io/learn-gdscript/
Я здесь пока учу сам язык (по-моему, тут уроки под старую версию годота, под 4.1 еще не запилили).
>>881323
Этот наш интернет. Алсо RTFM:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
Если тебе нужны медальки, чтобы изучить игровой движок, тогда, может быть, тебе не нужен никакой игровой движок? Юнити делает всё, чтобы заманить ньюфагов, не удивлюсь, если они лутбоксы/гачу с ассетами сделают, СОБЕРИ ИХ ВСЕ!
>>881330
Там скорее туториал по общему программированию, базовые концепции. Если уже знаешь какой-то другой ЯП, эффективнее всего прочитать это:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
И дальше только API движка останется изучать.
>площадка по обучению
Этот наш интернет. Алсо RTFM:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
>медальки дают
Если тебе нужны медальки, чтобы изучить игровой движок, тогда, может быть, тебе не нужен никакой игровой движок? Юнити делает всё, чтобы заманить ньюфагов, не удивлюсь, если они лутбоксы/гачу с ассетами сделают, СОБЕРИ ИХ ВСЕ!
>>881330
>учу сам язык
Там скорее туториал по общему программированию, базовые концепции. Если уже знаешь какой-то другой ЯП, эффективнее всего прочитать это:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html
И дальше только API движка останется изучать.
>>881403
Я в свое время учил питон, так что знаком со многими концепциями, но неплохо было освежить память. Кстати, я так до сих пор и не решил, пилить ли игру на годоте или лучше уж взяться за C# и начать делать на юнити. В основном отталкивает то, что для годота мало туториалов и в целом комьюнити намного меньше чем у юнити.
>Если уже знаешь какой-то другой ЯП
Я в свое время учил питон, так что знаком со многими концепциями, но неплохо было освежить память. Кстати, я так до сих пор и не решил, пилить ли игру на годоте или лучше уж взяться за C# и начать делать на юнити. В основном отталкивает то, что для годота мало туториалов и в целом комьюнити намного меньше чем у юнити.
Вы не в курсе, тайлмапу из четверки в 3.5 не собираются бэкпортнуть? Сейчас вот никак не могу выбрать, какую из версий выбрать - четвера все еще багованная и все мануалы и уроки по трехе, но тайлмапа в четвере больно батая.
Решил попробовать в 3Д разработку (раньше обходился моддингом 2Д игорь, Fonline тот-же), взор пал на Годот т.к. ВРОООДЕ весь из себя охуенный, нигде регистрировацца не надо и двигло в одном бинарнике.
Запустил значит блядь, сделал максимально примитивную сценку, и что я сука вижу? CollisionShape-ы нихуя не работают, как-бы я их не сувал, я их неправильно использую или двигло действительно настолько уёбищно и придётся танцевать с бубном из-за мелочей?
Запустил значит блядь, сделал максимально примитивную сценку, и что я сука вижу? CollisionShape-ы нихуя не работают, как-бы я их не сувал, я их неправильно использую или двигло действительно настолько уёбищно и придётся танцевать с бубном из-за мелочей?
>>881423
Я искал и не нашел планов. Скорее всего таких планов нет т.к. это ломающее изменение для 3.х.
Тоже выбрал 3 для таких целей, хоть тайлмапы и хороши в 4. Но мне хочется стабильный экспорт в веб.
Я искал и не нашел планов. Скорее всего таких планов нет т.к. это ломающее изменение для 3.х.
Тоже выбрал 3 для таких целей, хоть тайлмапы и хороши в 4. Но мне хочется стабильный экспорт в веб.
>>881428
Покажи скрин как ты их расставил. Ты какой то туториал делал? Документацию читал?
Покажи скрин как ты их расставил. Ты какой то туториал делал? Документацию читал?
>>881431
Расставлял нажимая меш - создать вогнутое стат. тело, не по туторам, без документации, да и она нихуя ответов не дала, на шейпах ещё вот такая ошибка (пик).
Расставлял нажимая меш - создать вогнутое стат. тело, не по туторам, без документации, да и она нихуя ответов не дала, на шейпах ещё вот такая ошибка (пик).
>>881437
Ну так начни с них.
Ну вот видишь, движок сам тебе пишет что у тебя неправильно - не униформное масштабирование.
>не по туторам, без документации
Ну так начни с них.
>Вот такая ошибка
Ну вот видишь, движок сам тебе пишет что у тебя неправильно - не униформное масштабирование.
>>881440
И? Мне это ни о чём говорит, фиксить как?
>Ну вот видишь, движок сам тебе пишет что у тебя неправильно - не униформное масштабирование.
И? Мне это ни о чём говорит, фиксить как?
>>881447
У тебя, судя по скрину, Area, а не StaticBody.
Area это область триггеров, а не стена.
Начни с туториалов, я не шучу.
У тебя, судя по скрину, Area, а не StaticBody.
Area это область триггеров, а не стена.
Начни с туториалов, я не шучу.
>>881420
Туториалы полезны только полным новичкам. Godot - это просто набор инструментов, а как их использовать ты должен придумать сам. Документация Godot достаточно хорошо описывает эти инструменты, а в туториалах чаще всего объясняют высокоуровневые вещи вроде инвентаря или шкалы здоровья, которые +/- одинаково делаются на любом движке, потому что высокоуровневые.
Короче, если ты хорошо знаешь Godot, тебе подойдёт практически любой туториал от движков похожего или более низкого уровня (естественно, не подойдёт туториал про то, что делается одной кнопкой на более высокоуровневом движке).
Помню, искал какую-то идею, и нашёл её в туториале для юнити или чего-то похожего, после чего понял и быстро сделал на Godot.
Ну, главное что разработчиков движка много и они слушают коммьюнити. У юнити со связью между разработчиками и коммьюнити объективно хуже, т.к. они там нацелены на максимизацию прибыли, а не на разработку инструмента для людей.
Год назад был скандал из-за этого, некоторые пользователи демонстративно ушли из-за этого на Godot, UE или другие движки, а акции юнити аж просели несколько раз.
И потом, даже если коммьюнити маленькое, оно может свободно модифицировать Godot на своё усмотрение, даже если разработчики пойдут куда-то не туда. В то время как коммьюнити юнити только ассеты делать может, никаких тебе свободных и независимых форков...
>отталкивает то, что для годота мало туториалов
Туториалы полезны только полным новичкам. Godot - это просто набор инструментов, а как их использовать ты должен придумать сам. Документация Godot достаточно хорошо описывает эти инструменты, а в туториалах чаще всего объясняют высокоуровневые вещи вроде инвентаря или шкалы здоровья, которые +/- одинаково делаются на любом движке, потому что высокоуровневые.
Короче, если ты хорошо знаешь Godot, тебе подойдёт практически любой туториал от движков похожего или более низкого уровня (естественно, не подойдёт туториал про то, что делается одной кнопкой на более высокоуровневом движке).
Помню, искал какую-то идею, и нашёл её в туториале для юнити или чего-то похожего, после чего понял и быстро сделал на Godot.
>в целом комьюнити намного меньше чем у юнити
Ну, главное что разработчиков движка много и они слушают коммьюнити. У юнити со связью между разработчиками и коммьюнити объективно хуже, т.к. они там нацелены на максимизацию прибыли, а не на разработку инструмента для людей.
Год назад был скандал из-за этого, некоторые пользователи демонстративно ушли из-за этого на Godot, UE или другие движки, а акции юнити аж просели несколько раз.
И потом, даже если коммьюнити маленькое, оно может свободно модифицировать Godot на своё усмотрение, даже если разработчики пойдут куда-то не туда. В то время как коммьюнити юнити только ассеты делать может, никаких тебе свободных и независимых форков...
>>881437
Вот это хотя бы почитай:
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
Я понимаю твоё разочарование. Я сам первый раз пытался вкатиться в Godot без чтения чего-либо, т.к. интерфейс Godot создаёт обманчивое впечатление максимальной интуитивности, как в какой-нибудь видеоигре. Типа, я думал, что может пойти не так? Щас тяп-ляп и буду играть... Но нет. Психанул и забросил примерно на полгода/год. Потом решил попробовать снова, но в этот раз я попробовал пройти официальные туториалы из документации. И получилось! Признаюсь честно, за 3+ лет экспериментов с движком я не прочитал, наверное, даже половину документации, но прочитанного оказалось более чем достаточно для реализации разных моих идей.
Так что давай не упирайся, читай. Часть старой документации даже переведена на русский, как сейчас дело обстоит с переводом не знаю (даже английскую ещё не полностью проверили после повышения мажорной версии движка, но в целом всё норм).
>>881428
Разработка игр с нуля сильно сложнее моддинга существующих игр, а разработка 3D игр по многим причинам сложнее разработки 2D игр. Кроме того, твои первые самостоятельные поделки гарантированно будут говном, которое придётся выкинуть или переделать с нуля. Поэтому лучше начни с туториалов по созданию 2D игр, прежде чем бросаться в 3D. Я и сам пытался начать с 3D, но теперь признаю свою ошибку.
>не по туторам, без документации
Вот это хотя бы почитай:
https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html
Я понимаю твоё разочарование. Я сам первый раз пытался вкатиться в Godot без чтения чего-либо, т.к. интерфейс Godot создаёт обманчивое впечатление максимальной интуитивности, как в какой-нибудь видеоигре. Типа, я думал, что может пойти не так? Щас тяп-ляп и буду играть... Но нет. Психанул и забросил примерно на полгода/год. Потом решил попробовать снова, но в этот раз я попробовал пройти официальные туториалы из документации. И получилось! Признаюсь честно, за 3+ лет экспериментов с движком я не прочитал, наверное, даже половину документации, но прочитанного оказалось более чем достаточно для реализации разных моих идей.
Так что давай не упирайся, читай. Часть старой документации даже переведена на русский, как сейчас дело обстоит с переводом не знаю (даже английскую ещё не полностью проверили после повышения мажорной версии движка, но в целом всё норм).
>>881428
>Решил попробовать в 3Д разработку (раньше обходился моддингом 2Д игорь
Разработка игр с нуля сильно сложнее моддинга существующих игр, а разработка 3D игр по многим причинам сложнее разработки 2D игр. Кроме того, твои первые самостоятельные поделки гарантированно будут говном, которое придётся выкинуть или переделать с нуля. Поэтому лучше начни с туториалов по созданию 2D игр, прежде чем бросаться в 3D. Я и сам пытался начать с 3D, но теперь признаю свою ошибку.
>Godot 4.1.beta1
@
>Reload Current Project
@
>Alert!
>Scene file 'box.tscn' appears to be invalid/corrupt.
Попробовал бету, называется...
Алсо, почему-то preload(”box.tscn").instantiate() создаёт экземпляр сцены без скрипта. У всех такое или у меня сцена сломана? Я попробовал создать новую сцену с такими же свойствами, она опять сломалась.
>>881453
Да не упираюсь, ну это пиздец просто когда в туторах говорят мол ПРОООСТО поставьте коллижн шейп, а он через раз работает, особенно те, которые сгенерены для моделей, щас тестовую руму сделал в блендере, сунул в двигло, сгенерил коллижн шейп, а он не работает.
>Не упирайся
Да не упираюсь, ну это пиздец просто когда в туторах говорят мол ПРОООСТО поставьте коллижн шейп, а он через раз работает, особенно те, которые сгенерены для моделей, щас тестовую руму сделал в блендере, сунул в двигло, сгенерил коллижн шейп, а он не работает.
>>881516
1. Перескакиваешь с темы на тему вместо изучения по порядку с самого первого урока?
2. Читаешь/слушаешь невнимательно, пропуская абзацы или перематывая видео?
3. Мог невнимательно повторить шаги. Всякое бывает.
4. Иногда в туториалах ошибки. Особенно в устаревших. Особенно на Ютубе. Особенно от пискливой школоты.
5. Иногда ошибки нет, просто туториал плохой, из-за того, что большинство авторов туториалов не учителя. Они хорошо знают предмет, которому пытаются учить, но не знают, как правильно учить новичков.
Реалистичная симуляция физики ресурсоёмка и склонна к ошибкам, поэтому во всех игровых движках физика ВСЕГДА состоит из упрощений и костылей.
В результате типичный физический движок реального времени, предназначенный для видеоигр, предлагает несколько видов физических тел и форм коллизии. Использование каждого вида тела и формы имеет преимущества и недостатки, поэтому выбирать нужно в соответствии с конкретной задачей.
Начнём с простого: статичные тела и динамические. Статичные тела неподвижны, поэтому движок может применить к ним больше вычислений. Динамические подвержены законам физики: движутся, вращаются, отскакивают, замедляются и т.д. Поэтому коллизии динамических тел необходимо делать проще.
Формы коллизий ещё более разнообразны. Самые простые представляют собой геометрические примитивы: в 2D это круги и прямоугольники, в 3D это сферы, параллелепипеды, цилиндры и т.п. Простые формы очень важны, потому что позволяют физическому движку использовать быстрейшие алгоритмы. Как правило, намного эффективнее составить большой физический объект из этих примитивов: игрок не заметит разницы, а игра будет работать быстрее и движок будет реже допускать неизбежные ошибки.
Следующей по сложности идёт выпуклая форма. Как следует из названия, эта форма коллизий изображает сложное тело, но оно всегда выпуклое. Вычисления сложнее, но всё же выпуклость позволяет экономить, поскольку формула проверки вхождения точки в выпуклое тело намного проще произвольного тела. В некоторых случаях может быть лучше использовать одну или несколько выпуклых форм, чем пытаться повторить сложную форму базовыми примитивами.
Естественно, одним выпуклым телом не симулировать коллизии помещения или пещеры. Поэтому для особо сложных случаев используется самая тяжёлая форма коллизий - т.н. "тримеш". Эта форма состоит из треугольников точно так же, как обычный 3D меш, но оптимизирована для физических вычислений. Однако вычисления всё равно очень сложны (для компьютера и разработчика движка), поэтому такие формы можно использовать лишь для статических тел.
Есть и другие специальные формы и тела, например, специальная форма для карты высот и "мягкое" тело, но ты пока этим голову не забивай.
Вот это всё ты должен был знать после чтения базовой документации. Там это так или иначе объясняется, ибо это базовая информация для разработки игр.
Конкретно в твоём случае тебе скорее всего нужен один StaticBody3D и множество CollisionShape3D в нём, которые ты должен вручную заполнить примитивами - в основном это будут параллелепипеды для стен и объектов, визуально похожих на коробку.
Конечно, ты можешь сгенерировать тримеш для целой локации. Но это может быть весьма неэффективно, особенно если у тебя очень тяжёлая геометрия меша. Всегда в первую очередь рассматривай примитивы - параллелепипеды, сферы, цилиндры, затем выпуклые формы, и только на крайний случай бери тримеш.
>говорят мол ПРОООСТО поставьте
1. Перескакиваешь с темы на тему вместо изучения по порядку с самого первого урока?
2. Читаешь/слушаешь невнимательно, пропуская абзацы или перематывая видео?
3. Мог невнимательно повторить шаги. Всякое бывает.
4. Иногда в туториалах ошибки. Особенно в устаревших. Особенно на Ютубе. Особенно от пискливой школоты.
5. Иногда ошибки нет, просто туториал плохой, из-за того, что большинство авторов туториалов не учителя. Они хорошо знают предмет, которому пытаются учить, но не знают, как правильно учить новичков.
>которые сгенерены для моделей, щас тестовую руму сделал в блендере, сунул в двигло, сгенерил коллижн шейп, а он не работает.
Реалистичная симуляция физики ресурсоёмка и склонна к ошибкам, поэтому во всех игровых движках физика ВСЕГДА состоит из упрощений и костылей.
В результате типичный физический движок реального времени, предназначенный для видеоигр, предлагает несколько видов физических тел и форм коллизии. Использование каждого вида тела и формы имеет преимущества и недостатки, поэтому выбирать нужно в соответствии с конкретной задачей.
Начнём с простого: статичные тела и динамические. Статичные тела неподвижны, поэтому движок может применить к ним больше вычислений. Динамические подвержены законам физики: движутся, вращаются, отскакивают, замедляются и т.д. Поэтому коллизии динамических тел необходимо делать проще.
Формы коллизий ещё более разнообразны. Самые простые представляют собой геометрические примитивы: в 2D это круги и прямоугольники, в 3D это сферы, параллелепипеды, цилиндры и т.п. Простые формы очень важны, потому что позволяют физическому движку использовать быстрейшие алгоритмы. Как правило, намного эффективнее составить большой физический объект из этих примитивов: игрок не заметит разницы, а игра будет работать быстрее и движок будет реже допускать неизбежные ошибки.
Следующей по сложности идёт выпуклая форма. Как следует из названия, эта форма коллизий изображает сложное тело, но оно всегда выпуклое. Вычисления сложнее, но всё же выпуклость позволяет экономить, поскольку формула проверки вхождения точки в выпуклое тело намного проще произвольного тела. В некоторых случаях может быть лучше использовать одну или несколько выпуклых форм, чем пытаться повторить сложную форму базовыми примитивами.
Естественно, одним выпуклым телом не симулировать коллизии помещения или пещеры. Поэтому для особо сложных случаев используется самая тяжёлая форма коллизий - т.н. "тримеш". Эта форма состоит из треугольников точно так же, как обычный 3D меш, но оптимизирована для физических вычислений. Однако вычисления всё равно очень сложны (для компьютера и разработчика движка), поэтому такие формы можно использовать лишь для статических тел.
Есть и другие специальные формы и тела, например, специальная форма для карты высот и "мягкое" тело, но ты пока этим голову не забивай.
Вот это всё ты должен был знать после чтения базовой документации. Там это так или иначе объясняется, ибо это базовая информация для разработки игр.
Конкретно в твоём случае тебе скорее всего нужен один StaticBody3D и множество CollisionShape3D в нём, которые ты должен вручную заполнить примитивами - в основном это будут параллелепипеды для стен и объектов, визуально похожих на коробку.
Конечно, ты можешь сгенерировать тримеш для целой локации. Но это может быть весьма неэффективно, особенно если у тебя очень тяжёлая геометрия меша. Всегда в первую очередь рассматривай примитивы - параллелепипеды, сферы, цилиндры, затем выпуклые формы, и только на крайний случай бери тримеш.
>>881516
1. Перескакиваешь с темы на тему вместо изучения по порядку с самого первого урока?
2. Читаешь/слушаешь невнимательно, пропуская абзацы или перематывая видео?
3. Мог невнимательно повторить шаги. Всякое бывает.
4. Иногда в туториалах ошибки. Особенно в устаревших. Особенно на Ютубе. Особенно от пискливой школоты.
5. Иногда ошибки нет, просто туториал плохой, из-за того, что большинство авторов туториалов не учителя. Они хорошо знают предмет, которому пытаются учить, но не знают, как правильно учить новичков.
Реалистичная симуляция физики ресурсоёмка и склонна к ошибкам, поэтому во всех игровых движках физика ВСЕГДА состоит из упрощений и костылей.
В результате типичный физический движок реального времени, предназначенный для видеоигр, предлагает несколько видов физических тел и форм коллизии. Использование каждого вида тела и формы имеет преимущества и недостатки, поэтому выбирать нужно в соответствии с конкретной задачей.
Начнём с простого: статичные тела и динамические. Статичные тела неподвижны, поэтому движок может применить к ним больше вычислений. Динамические подвержены законам физики: движутся, вращаются, отскакивают, замедляются и т.д. Поэтому коллизии динамических тел необходимо делать проще.
Формы коллизий ещё более разнообразны. Самые простые представляют собой геометрические примитивы: в 2D это круги и прямоугольники, в 3D это сферы, параллелепипеды, цилиндры и т.п. Простые формы очень важны, потому что позволяют физическому движку использовать быстрейшие алгоритмы. Как правило, намного эффективнее составить большой физический объект из этих примитивов: игрок не заметит разницы, а игра будет работать быстрее и движок будет реже допускать неизбежные ошибки.
Следующей по сложности идёт выпуклая форма. Как следует из названия, эта форма коллизий изображает сложное тело, но оно всегда выпуклое. Вычисления сложнее, но всё же выпуклость позволяет экономить, поскольку формула проверки вхождения точки в выпуклое тело намного проще произвольного тела. В некоторых случаях может быть лучше использовать одну или несколько выпуклых форм, чем пытаться повторить сложную форму базовыми примитивами.
Естественно, одним выпуклым телом не симулировать коллизии помещения или пещеры. Поэтому для особо сложных случаев используется самая тяжёлая форма коллизий - т.н. "тримеш". Эта форма состоит из треугольников точно так же, как обычный 3D меш, но оптимизирована для физических вычислений. Однако вычисления всё равно очень сложны (для компьютера и разработчика движка), поэтому такие формы можно использовать лишь для статических тел.
Есть и другие специальные формы и тела, например, специальная форма для карты высот и "мягкое" тело, но ты пока этим голову не забивай.
Вот это всё ты должен был знать после чтения базовой документации. Там это так или иначе объясняется, ибо это базовая информация для разработки игр.
Конкретно в твоём случае тебе скорее всего нужен один StaticBody3D и множество CollisionShape3D в нём, которые ты должен вручную заполнить примитивами - в основном это будут параллелепипеды для стен и объектов, визуально похожих на коробку.
Конечно, ты можешь сгенерировать тримеш для целой локации. Но это может быть весьма неэффективно, особенно если у тебя очень тяжёлая геометрия меша. Всегда в первую очередь рассматривай примитивы - параллелепипеды, сферы, цилиндры, затем выпуклые формы, и только на крайний случай бери тримеш.
>говорят мол ПРОООСТО поставьте
1. Перескакиваешь с темы на тему вместо изучения по порядку с самого первого урока?
2. Читаешь/слушаешь невнимательно, пропуская абзацы или перематывая видео?
3. Мог невнимательно повторить шаги. Всякое бывает.
4. Иногда в туториалах ошибки. Особенно в устаревших. Особенно на Ютубе. Особенно от пискливой школоты.
5. Иногда ошибки нет, просто туториал плохой, из-за того, что большинство авторов туториалов не учителя. Они хорошо знают предмет, которому пытаются учить, но не знают, как правильно учить новичков.
>которые сгенерены для моделей, щас тестовую руму сделал в блендере, сунул в двигло, сгенерил коллижн шейп, а он не работает.
Реалистичная симуляция физики ресурсоёмка и склонна к ошибкам, поэтому во всех игровых движках физика ВСЕГДА состоит из упрощений и костылей.
В результате типичный физический движок реального времени, предназначенный для видеоигр, предлагает несколько видов физических тел и форм коллизии. Использование каждого вида тела и формы имеет преимущества и недостатки, поэтому выбирать нужно в соответствии с конкретной задачей.
Начнём с простого: статичные тела и динамические. Статичные тела неподвижны, поэтому движок может применить к ним больше вычислений. Динамические подвержены законам физики: движутся, вращаются, отскакивают, замедляются и т.д. Поэтому коллизии динамических тел необходимо делать проще.
Формы коллизий ещё более разнообразны. Самые простые представляют собой геометрические примитивы: в 2D это круги и прямоугольники, в 3D это сферы, параллелепипеды, цилиндры и т.п. Простые формы очень важны, потому что позволяют физическому движку использовать быстрейшие алгоритмы. Как правило, намного эффективнее составить большой физический объект из этих примитивов: игрок не заметит разницы, а игра будет работать быстрее и движок будет реже допускать неизбежные ошибки.
Следующей по сложности идёт выпуклая форма. Как следует из названия, эта форма коллизий изображает сложное тело, но оно всегда выпуклое. Вычисления сложнее, но всё же выпуклость позволяет экономить, поскольку формула проверки вхождения точки в выпуклое тело намного проще произвольного тела. В некоторых случаях может быть лучше использовать одну или несколько выпуклых форм, чем пытаться повторить сложную форму базовыми примитивами.
Естественно, одним выпуклым телом не симулировать коллизии помещения или пещеры. Поэтому для особо сложных случаев используется самая тяжёлая форма коллизий - т.н. "тримеш". Эта форма состоит из треугольников точно так же, как обычный 3D меш, но оптимизирована для физических вычислений. Однако вычисления всё равно очень сложны (для компьютера и разработчика движка), поэтому такие формы можно использовать лишь для статических тел.
Есть и другие специальные формы и тела, например, специальная форма для карты высот и "мягкое" тело, но ты пока этим голову не забивай.
Вот это всё ты должен был знать после чтения базовой документации. Там это так или иначе объясняется, ибо это базовая информация для разработки игр.
Конкретно в твоём случае тебе скорее всего нужен один StaticBody3D и множество CollisionShape3D в нём, которые ты должен вручную заполнить примитивами - в основном это будут параллелепипеды для стен и объектов, визуально похожих на коробку.
Конечно, ты можешь сгенерировать тримеш для целой локации. Но это может быть весьма неэффективно, особенно если у тебя очень тяжёлая геометрия меша. Всегда в первую очередь рассматривай примитивы - параллелепипеды, сферы, цилиндры, затем выпуклые формы, и только на крайний случай бери тримеш.
>>881519
О, слухай, к тебе вопрос, если ты спец по кискам коллижнам. Вот я собираюсь делать шутан по типу вольфа3д, трехмерный, но в одной плоскости, и с квадратно-гнездовой картой. Как мне лучше колижны для гридмапы делать, с точки зрения производительности - тримеши, чтобы они потом запеклись в один большой тримеш, или кубы?
О, слухай, к тебе вопрос, если ты спец по кискам коллижнам. Вот я собираюсь делать шутан по типу вольфа3д, трехмерный, но в одной плоскости, и с квадратно-гнездовой картой. Как мне лучше колижны для гридмапы делать, с точки зрения производительности - тримеши, чтобы они потом запеклись в один большой тримеш, или кубы?
>>881521
Хм? А такое вообще возможно? Я не видел функций склеивания тримешей. GridMap, насколько понимаю, создаёт один StaticBody на один "чанк", заполняя его коллижен шейпами. По моим тестам, можно пихнуть примерно тысячу шейпов в один боди, прежде чем начнутся проблемы с производительностью.
Я проверил в коде движка. Да, всё верно: есть один статикбоди на чанк (октант), заполняется шейпами максимально тривиально, вот в этой строчке:
https://github.com/godotengine/godot/blob/master/modules/gridmap/grid_map.cpp#L632
Короче, лучше использовать примитивные кубы.
Хотя есть вероятность, что тримеши одного статикбоди склеиваются где-то внутри физического движка, но я бы не надеялся на это.
>колижны для гридмапы
>они потом запеклись в один большой тримеш
Хм? А такое вообще возможно? Я не видел функций склеивания тримешей. GridMap, насколько понимаю, создаёт один StaticBody на один "чанк", заполняя его коллижен шейпами. По моим тестам, можно пихнуть примерно тысячу шейпов в один боди, прежде чем начнутся проблемы с производительностью.
Я проверил в коде движка. Да, всё верно: есть один статикбоди на чанк (октант), заполняется шейпами максимально тривиально, вот в этой строчке:
https://github.com/godotengine/godot/blob/master/modules/gridmap/grid_map.cpp#L632
>PhysicsServer3D::get_singleton()->body_add_shape(g.static_body, shapes[ i ].shape->get_rid(), xform × shapes[ i ].local_transform);
Короче, лучше использовать примитивные кубы.
Хотя есть вероятность, что тримеши одного статикбоди склеиваются где-то внутри физического движка, но я бы не надеялся на это.
>>881525
В GridMap, PhysicsServer3D или в Godot Physics 3D?
В GridMap, как видишь, шейпы не склеиваются.
Самое надёжное - провести краш-тест, заполнив гридмап огромным количеством кубов.
В GridMap, PhysicsServer3D или в Godot Physics 3D?
В GridMap, как видишь, шейпы не склеиваются.
Самое надёжное - провести краш-тест, заполнив гридмап огромным количеством кубов.
>>881525
Я мельком глянул код физики - не нашёл ничего про склеивание тримешей. Они обрабатываются так же как и остальные виды шейпов, без склеивания.
Поищи сам, если хочешь:
https://github.com/godotengine/godot/tree/master/servers/physics_3d
Возможно, там, где ты это читал/слушал, перепутали склеивание нескольких тримешей в один шейп с комбинацией нескольких шейпов в один боди.
Я мельком глянул код физики - не нашёл ничего про склеивание тримешей. Они обрабатываются так же как и остальные виды шейпов, без склеивания.
Поищи сам, если хочешь:
https://github.com/godotengine/godot/tree/master/servers/physics_3d
Возможно, там, где ты это читал/слушал, перепутали склеивание нескольких тримешей в один шейп с комбинацией нескольких шейпов в один боди.
>>881486
Там вроде предупреждение перед запуском - делайте бэкапы.
4.1 пока не ковырял, вообще 4-ку пока отложил, у меня тут пара проектов на 3-ке поперла.
Там вроде предупреждение перед запуском - делайте бэкапы.
4.1 пока не ковырял, вообще 4-ку пока отложил, у меня тут пара проектов на 3-ке поперла.
>>881563
Так я новый проект начал делать для теста. Менеджер проектов 4.1 про проекты 4.0 пишет что-то типа:
- типа в 4.1 что-то вырезали? Не слежу за новостями.
Не особо ждал выход 4.0, но как-то грустно оставаться на устаревшей версии, когда всё самое интересное делается исключительно для 4.х. У меня нет какого-то большого проекта и терять особо нечего, поэтому думал постепенно перейти на 4...
>делайте бэкапы
Так я новый проект начал делать для теста. Менеджер проектов 4.1 про проекты 4.0 пишет что-то типа:
>в данной версии могут отсутствовать функции
- типа в 4.1 что-то вырезали? Не слежу за новостями.
>вообще 4-ку пока отложил, у меня тут пара проектов на 3-ке поперла.
Не особо ждал выход 4.0, но как-то грустно оставаться на устаревшей версии, когда всё самое интересное делается исключительно для 4.х. У меня нет какого-то большого проекта и терять особо нечего, поэтому думал постепенно перейти на 4...
72 Кб, 960x600Пикрил кто-нибудь помнит? Нет, я ничего не сделал за последние три месяца и хотел совсем забить на проект, но как-то жалко бросать эту идею.
Концепция игры последние лет пять была такой:
1. Игрок выбирает параметры своего персонажа и нового игрового мира (место, масштаб и т.п.).
2. Игра процедурно генерирует конечную карту с городом по центру и начинает моделировать жизнь его жителей на каком-то уровне точности.
3. Игрок делает что захочет, зарабатывает деньги, репутацию, отношения с жителями, обустраивает себе дом, возится с машиной и т.д.
Что я делал? В основном пытался сделать интересную процедурную генерацию, но не смог придумать ничего интересного. Жителей я вообще забросил, потому что без строго сформулированного мира непонятно, какие задачи они должны решать. Да и чем конкретно игроку следует заниматься я тоже не особо представлял.
Сейчас я размышляю о том, как можно переделать эту концепцию во что-то более реалистичное и интересное, оставив суть проекта без изменений.
Меня вдруг осенило, что если игрок играет в одном и том же городе, имеет в нём что-то ценное, то у него нет мотивации начинать игру в новом городе, а тогда вся эта процедурная генерация не имеет никакого практического смысла. Я даже думал о том, чтобы отказаться от процедурки в пользу ручного редактора карты, но меня это не привлекает. То есть лично мне по кайфу копаться в алгоритмах генерации, но базовый геймплей не расположен к использованию этой генерации. Значит, нужно менять геймплей.
Вторая важная проблема - в симуляции жителей. Мне хотелось максимально "честную" модель, которая не использовала бы обманные манёвры как это обычно происходит в большинстве игр. Понимаю, это сложно реализовать, но проблема в том, что игрок не увидит и процента всей этой сложности, кроме процентов в диспетчере задач, лол. Было бы приятно развивать отношения с одним NPC-персонажем, но жизнь сотни фоновых персонажей смысла не имеет.
Одним из решений мне видится превратить игру в некое подобие роад-муви: игрок может двигаться по дорогам бесконечно долго, пока игра будет генерировать новые города с временным глупым населением и полностью забывать те, из которых игрок уехал. В этом случае процедурная генерация раскрывается в полной мере, а на симуляцию жителей можно с чистой совестью положить большой гаечный ключ, которым игрок ремонтирует свой транспорт. Также игрок мог бы взять с собой NPC, обменять свой ржавый запорожец на автодом, заполнить его мебелью и т.д.
Похожие идеи у меня были и раньше, но я не пытался применить их к этому проекту. Как минимум не ясно, что должно двигать игрока вперёд кроме любопытства и скуки, потому что надвигающийся апокалипсис или другую угрозу я делать не хочу. Если у игрока полный контроль над транспортом, он может и назад повернуть, верно? Будет ли слишком странным встретить на пути назад совершенно другую местность? Или ту же самую местность с теми же самыми жителями, которые вообще никак не изменились за прошедшее в игре время? В общем, такие вопросы в своё время заставили меня отказаться от бесконечной генерации мира а-ля Майнкрафт.
Самое смешное, что временное название проекта на идею роад-муви ложится лучше всего того, что я рассматривал в прошлом, лол.
Видел игры с похожей концепцией, но там слишком примитивный геймплей и мир, уровня раннеров. Не хочу деградировать до уровня раннеров, поэтому базовый геймплей остаётся а-ля GTA.
Помню, большую часть времени регулярно генерировал заново ландшафт/город/дома, вообще не задумываясь о сохранении и загрузке, потому что они мешали бы тестировать генерацию. Если бы я сделал полноценный геймплей и начал играть, тестировать генерацию можно было бы только в отдельном новом мире. Сейчас думаю, что с геймплеем "бесконечное путешествие по дороге" генерацию можно тестировать на одном и том же сохранении, ведь города как таковые сохраняться вообще не должны.
Одной из идей было развивать сад/огород и подобную недвижимость. Однако, что мешает дать возможность сажать растения прямо на транспорте? Видел такое в некоторых играх. Тем более игрок может всегда остановиться, разбив временный лагерь или сняв на время какой-нибудь домик. Впрочем, опять не ясно, что должно стимулировать игрока на движение, если он может сидеть на одном месте.
А нужно ли вообще стимулировать к чему-то? Я вроде песочницу пытался сделать...
С технической стороны думаю сделать генерацию бесконечным графом: узлы - города и развилки, рёбра - длинные междугородние дороги. Квадратно-гнездовой подход останется, надеюсь придумать больше разнообразных блоков-тайлов. Генерировать карту высот мне не очень нравится, больше привлекает ощущение автоматизированного конструктора Лего. Может быть, доделаю редактор деталек а-ля встроенный инструмент моддинга, нужно подумать.
Думаю продолжить пока на Godot 3.x, а то 4.x намного больше проблем имеет.
Кого-нибудь здесь это вообще интересует?
Концепция игры последние лет пять была такой:
1. Игрок выбирает параметры своего персонажа и нового игрового мира (место, масштаб и т.п.).
2. Игра процедурно генерирует конечную карту с городом по центру и начинает моделировать жизнь его жителей на каком-то уровне точности.
3. Игрок делает что захочет, зарабатывает деньги, репутацию, отношения с жителями, обустраивает себе дом, возится с машиной и т.д.
Что я делал? В основном пытался сделать интересную процедурную генерацию, но не смог придумать ничего интересного. Жителей я вообще забросил, потому что без строго сформулированного мира непонятно, какие задачи они должны решать. Да и чем конкретно игроку следует заниматься я тоже не особо представлял.
Сейчас я размышляю о том, как можно переделать эту концепцию во что-то более реалистичное и интересное, оставив суть проекта без изменений.
Меня вдруг осенило, что если игрок играет в одном и том же городе, имеет в нём что-то ценное, то у него нет мотивации начинать игру в новом городе, а тогда вся эта процедурная генерация не имеет никакого практического смысла. Я даже думал о том, чтобы отказаться от процедурки в пользу ручного редактора карты, но меня это не привлекает. То есть лично мне по кайфу копаться в алгоритмах генерации, но базовый геймплей не расположен к использованию этой генерации. Значит, нужно менять геймплей.
Вторая важная проблема - в симуляции жителей. Мне хотелось максимально "честную" модель, которая не использовала бы обманные манёвры как это обычно происходит в большинстве игр. Понимаю, это сложно реализовать, но проблема в том, что игрок не увидит и процента всей этой сложности, кроме процентов в диспетчере задач, лол. Было бы приятно развивать отношения с одним NPC-персонажем, но жизнь сотни фоновых персонажей смысла не имеет.
Одним из решений мне видится превратить игру в некое подобие роад-муви: игрок может двигаться по дорогам бесконечно долго, пока игра будет генерировать новые города с временным глупым населением и полностью забывать те, из которых игрок уехал. В этом случае процедурная генерация раскрывается в полной мере, а на симуляцию жителей можно с чистой совестью положить большой гаечный ключ, которым игрок ремонтирует свой транспорт. Также игрок мог бы взять с собой NPC, обменять свой ржавый запорожец на автодом, заполнить его мебелью и т.д.
Похожие идеи у меня были и раньше, но я не пытался применить их к этому проекту. Как минимум не ясно, что должно двигать игрока вперёд кроме любопытства и скуки, потому что надвигающийся апокалипсис или другую угрозу я делать не хочу. Если у игрока полный контроль над транспортом, он может и назад повернуть, верно? Будет ли слишком странным встретить на пути назад совершенно другую местность? Или ту же самую местность с теми же самыми жителями, которые вообще никак не изменились за прошедшее в игре время? В общем, такие вопросы в своё время заставили меня отказаться от бесконечной генерации мира а-ля Майнкрафт.
Самое смешное, что временное название проекта на идею роад-муви ложится лучше всего того, что я рассматривал в прошлом, лол.
Видел игры с похожей концепцией, но там слишком примитивный геймплей и мир, уровня раннеров. Не хочу деградировать до уровня раннеров, поэтому базовый геймплей остаётся а-ля GTA.
Помню, большую часть времени регулярно генерировал заново ландшафт/город/дома, вообще не задумываясь о сохранении и загрузке, потому что они мешали бы тестировать генерацию. Если бы я сделал полноценный геймплей и начал играть, тестировать генерацию можно было бы только в отдельном новом мире. Сейчас думаю, что с геймплеем "бесконечное путешествие по дороге" генерацию можно тестировать на одном и том же сохранении, ведь города как таковые сохраняться вообще не должны.
Одной из идей было развивать сад/огород и подобную недвижимость. Однако, что мешает дать возможность сажать растения прямо на транспорте? Видел такое в некоторых играх. Тем более игрок может всегда остановиться, разбив временный лагерь или сняв на время какой-нибудь домик. Впрочем, опять не ясно, что должно стимулировать игрока на движение, если он может сидеть на одном месте.
А нужно ли вообще стимулировать к чему-то? Я вроде песочницу пытался сделать...
С технической стороны думаю сделать генерацию бесконечным графом: узлы - города и развилки, рёбра - длинные междугородние дороги. Квадратно-гнездовой подход останется, надеюсь придумать больше разнообразных блоков-тайлов. Генерировать карту высот мне не очень нравится, больше привлекает ощущение автоматизированного конструктора Лего. Может быть, доделаю редактор деталек а-ля встроенный инструмент моддинга, нужно подумать.
Думаю продолжить пока на Godot 3.x, а то 4.x намного больше проблем имеет.
Кого-нибудь здесь это вообще интересует?
72 Кб, 960x600Пикрил кто-нибудь помнит? Нет, я ничего не сделал за последние три месяца и хотел совсем забить на проект, но как-то жалко бросать эту идею.
Концепция игры последние лет пять была такой:
1. Игрок выбирает параметры своего персонажа и нового игрового мира (место, масштаб и т.п.).
2. Игра процедурно генерирует конечную карту с городом по центру и начинает моделировать жизнь его жителей на каком-то уровне точности.
3. Игрок делает что захочет, зарабатывает деньги, репутацию, отношения с жителями, обустраивает себе дом, возится с машиной и т.д.
Что я делал? В основном пытался сделать интересную процедурную генерацию, но не смог придумать ничего интересного. Жителей я вообще забросил, потому что без строго сформулированного мира непонятно, какие задачи они должны решать. Да и чем конкретно игроку следует заниматься я тоже не особо представлял.
Сейчас я размышляю о том, как можно переделать эту концепцию во что-то более реалистичное и интересное, оставив суть проекта без изменений.
Меня вдруг осенило, что если игрок играет в одном и том же городе, имеет в нём что-то ценное, то у него нет мотивации начинать игру в новом городе, а тогда вся эта процедурная генерация не имеет никакого практического смысла. Я даже думал о том, чтобы отказаться от процедурки в пользу ручного редактора карты, но меня это не привлекает. То есть лично мне по кайфу копаться в алгоритмах генерации, но базовый геймплей не расположен к использованию этой генерации. Значит, нужно менять геймплей.
Вторая важная проблема - в симуляции жителей. Мне хотелось максимально "честную" модель, которая не использовала бы обманные манёвры как это обычно происходит в большинстве игр. Понимаю, это сложно реализовать, но проблема в том, что игрок не увидит и процента всей этой сложности, кроме процентов в диспетчере задач, лол. Было бы приятно развивать отношения с одним NPC-персонажем, но жизнь сотни фоновых персонажей смысла не имеет.
Одним из решений мне видится превратить игру в некое подобие роад-муви: игрок может двигаться по дорогам бесконечно долго, пока игра будет генерировать новые города с временным глупым населением и полностью забывать те, из которых игрок уехал. В этом случае процедурная генерация раскрывается в полной мере, а на симуляцию жителей можно с чистой совестью положить большой гаечный ключ, которым игрок ремонтирует свой транспорт. Также игрок мог бы взять с собой NPC, обменять свой ржавый запорожец на автодом, заполнить его мебелью и т.д.
Похожие идеи у меня были и раньше, но я не пытался применить их к этому проекту. Как минимум не ясно, что должно двигать игрока вперёд кроме любопытства и скуки, потому что надвигающийся апокалипсис или другую угрозу я делать не хочу. Если у игрока полный контроль над транспортом, он может и назад повернуть, верно? Будет ли слишком странным встретить на пути назад совершенно другую местность? Или ту же самую местность с теми же самыми жителями, которые вообще никак не изменились за прошедшее в игре время? В общем, такие вопросы в своё время заставили меня отказаться от бесконечной генерации мира а-ля Майнкрафт.
Самое смешное, что временное название проекта на идею роад-муви ложится лучше всего того, что я рассматривал в прошлом, лол.
Видел игры с похожей концепцией, но там слишком примитивный геймплей и мир, уровня раннеров. Не хочу деградировать до уровня раннеров, поэтому базовый геймплей остаётся а-ля GTA.
Помню, большую часть времени регулярно генерировал заново ландшафт/город/дома, вообще не задумываясь о сохранении и загрузке, потому что они мешали бы тестировать генерацию. Если бы я сделал полноценный геймплей и начал играть, тестировать генерацию можно было бы только в отдельном новом мире. Сейчас думаю, что с геймплеем "бесконечное путешествие по дороге" генерацию можно тестировать на одном и том же сохранении, ведь города как таковые сохраняться вообще не должны.
Одной из идей было развивать сад/огород и подобную недвижимость. Однако, что мешает дать возможность сажать растения прямо на транспорте? Видел такое в некоторых играх. Тем более игрок может всегда остановиться, разбив временный лагерь или сняв на время какой-нибудь домик. Впрочем, опять не ясно, что должно стимулировать игрока на движение, если он может сидеть на одном месте.
А нужно ли вообще стимулировать к чему-то? Я вроде песочницу пытался сделать...
С технической стороны думаю сделать генерацию бесконечным графом: узлы - города и развилки, рёбра - длинные междугородние дороги. Квадратно-гнездовой подход останется, надеюсь придумать больше разнообразных блоков-тайлов. Генерировать карту высот мне не очень нравится, больше привлекает ощущение автоматизированного конструктора Лего. Может быть, доделаю редактор деталек а-ля встроенный инструмент моддинга, нужно подумать.
Думаю продолжить пока на Godot 3.x, а то 4.x намного больше проблем имеет.
Кого-нибудь здесь это вообще интересует?
Концепция игры последние лет пять была такой:
1. Игрок выбирает параметры своего персонажа и нового игрового мира (место, масштаб и т.п.).
2. Игра процедурно генерирует конечную карту с городом по центру и начинает моделировать жизнь его жителей на каком-то уровне точности.
3. Игрок делает что захочет, зарабатывает деньги, репутацию, отношения с жителями, обустраивает себе дом, возится с машиной и т.д.
Что я делал? В основном пытался сделать интересную процедурную генерацию, но не смог придумать ничего интересного. Жителей я вообще забросил, потому что без строго сформулированного мира непонятно, какие задачи они должны решать. Да и чем конкретно игроку следует заниматься я тоже не особо представлял.
Сейчас я размышляю о том, как можно переделать эту концепцию во что-то более реалистичное и интересное, оставив суть проекта без изменений.
Меня вдруг осенило, что если игрок играет в одном и том же городе, имеет в нём что-то ценное, то у него нет мотивации начинать игру в новом городе, а тогда вся эта процедурная генерация не имеет никакого практического смысла. Я даже думал о том, чтобы отказаться от процедурки в пользу ручного редактора карты, но меня это не привлекает. То есть лично мне по кайфу копаться в алгоритмах генерации, но базовый геймплей не расположен к использованию этой генерации. Значит, нужно менять геймплей.
Вторая важная проблема - в симуляции жителей. Мне хотелось максимально "честную" модель, которая не использовала бы обманные манёвры как это обычно происходит в большинстве игр. Понимаю, это сложно реализовать, но проблема в том, что игрок не увидит и процента всей этой сложности, кроме процентов в диспетчере задач, лол. Было бы приятно развивать отношения с одним NPC-персонажем, но жизнь сотни фоновых персонажей смысла не имеет.
Одним из решений мне видится превратить игру в некое подобие роад-муви: игрок может двигаться по дорогам бесконечно долго, пока игра будет генерировать новые города с временным глупым населением и полностью забывать те, из которых игрок уехал. В этом случае процедурная генерация раскрывается в полной мере, а на симуляцию жителей можно с чистой совестью положить большой гаечный ключ, которым игрок ремонтирует свой транспорт. Также игрок мог бы взять с собой NPC, обменять свой ржавый запорожец на автодом, заполнить его мебелью и т.д.
Похожие идеи у меня были и раньше, но я не пытался применить их к этому проекту. Как минимум не ясно, что должно двигать игрока вперёд кроме любопытства и скуки, потому что надвигающийся апокалипсис или другую угрозу я делать не хочу. Если у игрока полный контроль над транспортом, он может и назад повернуть, верно? Будет ли слишком странным встретить на пути назад совершенно другую местность? Или ту же самую местность с теми же самыми жителями, которые вообще никак не изменились за прошедшее в игре время? В общем, такие вопросы в своё время заставили меня отказаться от бесконечной генерации мира а-ля Майнкрафт.
Самое смешное, что временное название проекта на идею роад-муви ложится лучше всего того, что я рассматривал в прошлом, лол.
Видел игры с похожей концепцией, но там слишком примитивный геймплей и мир, уровня раннеров. Не хочу деградировать до уровня раннеров, поэтому базовый геймплей остаётся а-ля GTA.
Помню, большую часть времени регулярно генерировал заново ландшафт/город/дома, вообще не задумываясь о сохранении и загрузке, потому что они мешали бы тестировать генерацию. Если бы я сделал полноценный геймплей и начал играть, тестировать генерацию можно было бы только в отдельном новом мире. Сейчас думаю, что с геймплеем "бесконечное путешествие по дороге" генерацию можно тестировать на одном и том же сохранении, ведь города как таковые сохраняться вообще не должны.
Одной из идей было развивать сад/огород и подобную недвижимость. Однако, что мешает дать возможность сажать растения прямо на транспорте? Видел такое в некоторых играх. Тем более игрок может всегда остановиться, разбив временный лагерь или сняв на время какой-нибудь домик. Впрочем, опять не ясно, что должно стимулировать игрока на движение, если он может сидеть на одном месте.
А нужно ли вообще стимулировать к чему-то? Я вроде песочницу пытался сделать...
С технической стороны думаю сделать генерацию бесконечным графом: узлы - города и развилки, рёбра - длинные междугородние дороги. Квадратно-гнездовой подход останется, надеюсь придумать больше разнообразных блоков-тайлов. Генерировать карту высот мне не очень нравится, больше привлекает ощущение автоматизированного конструктора Лего. Может быть, доделаю редактор деталек а-ля встроенный инструмент моддинга, нужно подумать.
Думаю продолжить пока на Godot 3.x, а то 4.x намного больше проблем имеет.
Кого-нибудь здесь это вообще интересует?
>>881659
Конечно, редкий приятный проект на дваче, одна из причин все еще иногда заходить в /gd
>Пикрил кто-нибудь помнит?
Конечно, редкий приятный проект на дваче, одна из причин все еще иногда заходить в /gd
Вопрос.
Насколько тяжко будет в годоте запилить клон Горячей Майамы человеку, не слишком хорошо погромирующему?
Или уже есть шаблончик под такое
Насколько тяжко будет в годоте запилить клон Горячей Майамы человеку, не слишком хорошо погромирующему?
Или уже есть шаблончик под такое
>>881777
Ну давай разберём по частям тобою написанное.
1. Что значит "тяжело"? Что ты готов превозмогать, а что заставит тебя всё бросить и уныть?
2. Что значит "клон Hotline Miami"? Ты хочешь бездушную копипасту или готов импровизировать?
3. Что значит "не слишком хорошо"? Что ты реально программировал, на чём, смог ли понять свой код?
Поищи сам. Hotline Miami - топдаун шутер, весьма популярный жанр, что-то наверняка должно быть.
https://duckduckgo.com/?q=godot+top+down+shooter+template
>Насколько тяжко будет в годоте запилить клон Горячей Майамы человеку, не слишком хорошо погромирующему?
Ну давай разберём по частям тобою написанное.
1. Что значит "тяжело"? Что ты готов превозмогать, а что заставит тебя всё бросить и уныть?
2. Что значит "клон Hotline Miami"? Ты хочешь бездушную копипасту или готов импровизировать?
3. Что значит "не слишком хорошо"? Что ты реально программировал, на чём, смог ли понять свой код?
>шаблончик под такое
Поищи сам. Hotline Miami - топдаун шутер, весьма популярный жанр, что-то наверняка должно быть.
https://duckduckgo.com/?q=godot+top+down+shooter+template
>>881810
Это вопрос (вместо запятой в конце).
Это вопрос (вместо запятой в конце).
>>881659
В общем, представил как это будет, потестил прототип с одной прямой дорогой, подумал над вариантами.
Однозначно хочу чтоб было высокое разнообразие дороги, а не сплошная прямая трасса. Петляющие между холмами участки, участок спуска с отвесной скалы, участок в гору, участок с мостом через реку, участок через какое-нибудь визуально приятное поле/луг, участок вдоль моря, редко встречающиеся одинокие домики и т.п. Одним словом, чтоб было на что посмотреть и чтобы не было бездумного зажимания кнопки W, иначе смысл теряется.
Да, можно сделать всё это вручную, но тогда это будет просто набор случайно выпадающих кусочков - проехав по одному, остальные будут слишком похожими, ну и смысл тогда куда-то ехать, если тебя ждут только повторы уже виденного? А как это чисто процедурно генерировать я вообще не представляю, слишком большое количество разных вариантов, которые нужно учитывать.
Нужно применить декомпозицию, от общего (дорога без конца) к частному (участки дороги). Вообще, мне следовало бы концепт-артов накидать сначала...
На одном только вдохновении далеко не уедешь, а когда я тот пост набирал - думал за один вечер до интересного прототипа довести(
>>881664
Спасибо, конечно, хотя не верю, что ты это серьёзно. В разделе полно достойных, полноценных игр, а я несколько лет ковыряю прототип, в котором до сих пор ничего нет, кроме смутных хотелок чего-то.
>>881667
Смотря как посмотреть. Реализм не потяну, но я и не пытаюсь в него. На данный момент проблема не в потенциальном масштабе, а в том, что я не знаю точно, что именно я хочу/стоит реализовать.
Геймдизайнер из меня точно никакой...
В общем, представил как это будет, потестил прототип с одной прямой дорогой, подумал над вариантами.
Однозначно хочу чтоб было высокое разнообразие дороги, а не сплошная прямая трасса. Петляющие между холмами участки, участок спуска с отвесной скалы, участок в гору, участок с мостом через реку, участок через какое-нибудь визуально приятное поле/луг, участок вдоль моря, редко встречающиеся одинокие домики и т.п. Одним словом, чтоб было на что посмотреть и чтобы не было бездумного зажимания кнопки W, иначе смысл теряется.
Да, можно сделать всё это вручную, но тогда это будет просто набор случайно выпадающих кусочков - проехав по одному, остальные будут слишком похожими, ну и смысл тогда куда-то ехать, если тебя ждут только повторы уже виденного? А как это чисто процедурно генерировать я вообще не представляю, слишком большое количество разных вариантов, которые нужно учитывать.
Нужно применить декомпозицию, от общего (дорога без конца) к частному (участки дороги). Вообще, мне следовало бы концепт-артов накидать сначала...
На одном только вдохновении далеко не уедешь, а когда я тот пост набирал - думал за один вечер до интересного прототипа довести(
>>881664
>Конечно, редкий приятный проект на дваче, одна из причин все еще иногда заходить в /gd
Спасибо, конечно, хотя не верю, что ты это серьёзно. В разделе полно достойных, полноценных игр, а я несколько лет ковыряю прототип, в котором до сих пор ничего нет, кроме смутных хотелок чего-то.
>>881667
>Не слишком масштабно для одного?
Смотря как посмотреть. Реализм не потяну, но я и не пытаюсь в него. На данный момент проблема не в потенциальном масштабе, а в том, что я не знаю точно, что именно я хочу/стоит реализовать.
Геймдизайнер из меня точно никакой...
>>881854
Абсолютно искренне. Твой прототип выглядит очень выгодно на фоне - либо доделанных, но неинтересных или некрасивых игр (пиксельный шутемап, майнкрафтовый рогалик, прыгаюший квадрат с меню, проклятые анимепанцу), либо недоделанных и некрасивых (котлоферма), либо недоделанных красивых (что-то про летающую аниме с копьем, некоторые заброшенные поделия с твг, вроде пинк девочки). А больше ничего и не вспоминается. А, еще есть пара типа-реализмов про постсовковые дворы, но это другая направленность, у тебя как то более жизнерадостно. Ну ты продолжай пилить прототипы, так и запилишь что то.
>В разделе полно достойных, полноценных игр, а я несколько лет ковыряю прототип, в котором до сих пор ничего нет
Абсолютно искренне. Твой прототип выглядит очень выгодно на фоне - либо доделанных, но неинтересных или некрасивых игр (пиксельный шутемап, майнкрафтовый рогалик, прыгаюший квадрат с меню, проклятые анимепанцу), либо недоделанных и некрасивых (котлоферма), либо недоделанных красивых (что-то про летающую аниме с копьем, некоторые заброшенные поделия с твг, вроде пинк девочки). А больше ничего и не вспоминается. А, еще есть пара типа-реализмов про постсовковые дворы, но это другая направленность, у тебя как то более жизнерадостно. Ну ты продолжай пилить прототипы, так и запилишь что то.
>>881854
Подумал ещё и ВНЕЗАПНО вспомнил, что от честной генерации а-ля майнкрафт толку ровным счётом ноль, потому что даже если все участки карты технически разные, субъективно разница между ними как между тарелками одной и той же каши.
Тогда решил всё-таки собрать прототип на вручную смоделированных блоках и... получились какие-то рандомные американские горки?.. Кстати, пробовал ехать как можно дольше - спустя 40 км (!) надоело ждать проявления этих глитчей:
Если делать дорогу реально бесконечной, то, конечно, сдвигать мир придётся. Но для обычной игры должно хватать точности без этого сдвига. Я про ГТА, в космосимах совсем другие проблемы, конечно.
В любом случае, я вспомнил, что в попытках сделать генератор забыл о самом главном - геймплей. Его нет. По идее, главным должен быть геймплей-луп:
Раньше идея была "просто жить в городе", так что я вообще не представлял, что именно делать нужно.
Теперь... Допустим, можно так:
1. Едем куда глаза глядят по дороге;
2. Доезжаем до случайного "города" (3.5 домика);
3. Делаем мелкие задания (?) жителей, зарабатывая деньги на всякие шмотки, запчасти, топливо и т.п.;
4. Едем дальше, поскольку контент размазан между городами, в одном городе никогда нет 100% контента. Каждый город своего рода процедурный лутбокс. Ну, можно сделать ресурс каждого города конечным. Скупил всё что мог - пополнения товаров не будет.
Плюс можно напридумывать много побочных лупов, особенно в виде случайных событий на дороге. Типа подбросить кого-то до города, или поменять колесо. Следить за параметрами персонажа, чтобы не уснуть прямо за рулём в дороге, делать остановки.
Что делать с возможностью ехать в обратном направлении пока не знаю, нужно ещё подумать. Наверное, стоит сохранять на диск минимум один город вместе с дорогой до него. Потом удалять.
Глобальную мировую карту генерировать не хочу...
>>881868
Эээ, ну, даже не знаю. Я просто накидал кислотных коробок и мучаюсь с кувыркающимся VehicleBody.
Графика плейсхолдерная, чтобы прикинуть габариты и запилить геймплей раньше графики. Но да, хочу что-то сравнительно жизнерадостное...
Что там некрасивого, вроде норм. Тоже хочу что-то похожее на аниме сделать, но это сложно. А готовые модельки использовать не хочу.
>будут слишком похожими, ну и смысл...
Подумал ещё и ВНЕЗАПНО вспомнил, что от честной генерации а-ля майнкрафт толку ровным счётом ноль, потому что даже если все участки карты технически разные, субъективно разница между ними как между тарелками одной и той же каши.
Тогда решил всё-таки собрать прототип на вручную смоделированных блоках и... получились какие-то рандомные американские горки?.. Кстати, пробовал ехать как можно дольше - спустя 40 км (!) надоело ждать проявления этих глитчей:
>There may also be rendering and physics glitches due to floating point error in large worlds. You may be able to use techniques such as orienting the world around the player (rather than the other way around), or shifting the origin periodically to keep things centred around Vector3(0, 0, 0).
Если делать дорогу реально бесконечной, то, конечно, сдвигать мир придётся. Но для обычной игры должно хватать точности без этого сдвига. Я про ГТА, в космосимах совсем другие проблемы, конечно.
В любом случае, я вспомнил, что в попытках сделать генератор забыл о самом главном - геймплей. Его нет. По идее, главным должен быть геймплей-луп:
>A gameplay loop consists of a cycle of actions that you repeat over and over within a game.
Раньше идея была "просто жить в городе", так что я вообще не представлял, что именно делать нужно.
Теперь... Допустим, можно так:
1. Едем куда глаза глядят по дороге;
2. Доезжаем до случайного "города" (3.5 домика);
3. Делаем мелкие задания (?) жителей, зарабатывая деньги на всякие шмотки, запчасти, топливо и т.п.;
4. Едем дальше, поскольку контент размазан между городами, в одном городе никогда нет 100% контента. Каждый город своего рода процедурный лутбокс. Ну, можно сделать ресурс каждого города конечным. Скупил всё что мог - пополнения товаров не будет.
Плюс можно напридумывать много побочных лупов, особенно в виде случайных событий на дороге. Типа подбросить кого-то до города, или поменять колесо. Следить за параметрами персонажа, чтобы не уснуть прямо за рулём в дороге, делать остановки.
Что делать с возможностью ехать в обратном направлении пока не знаю, нужно ещё подумать. Наверное, стоит сохранять на диск минимум один город вместе с дорогой до него. Потом удалять.
Глобальную мировую карту генерировать не хочу...
>>881868
>Твой прототип выглядит очень выгодно на фоне
Эээ, ну, даже не знаю. Я просто накидал кислотных коробок и мучаюсь с кувыркающимся VehicleBody.
Графика плейсхолдерная, чтобы прикинуть габариты и запилить геймплей раньше графики. Но да, хочу что-то сравнительно жизнерадостное...
>некрасивых игр
>проклятые анимепанцу
Что там некрасивого, вроде норм. Тоже хочу что-то похожее на аниме сделать, но это сложно. А готовые модельки использовать не хочу.
>>881854
Подумал ещё и ВНЕЗАПНО вспомнил, что от честной генерации а-ля майнкрафт толку ровным счётом ноль, потому что даже если все участки карты технически разные, субъективно разница между ними как между тарелками одной и той же каши.
Тогда решил всё-таки собрать прототип на вручную смоделированных блоках и... получились какие-то рандомные американские горки?.. Кстати, пробовал ехать как можно дольше - спустя 40 км (!) надоело ждать проявления этих глитчей:
Если делать дорогу реально бесконечной, то, конечно, сдвигать мир придётся. Но для обычной игры должно хватать точности без этого сдвига. Я про ГТА, в космосимах совсем другие проблемы, конечно.
В любом случае, я вспомнил, что в попытках сделать генератор забыл о самом главном - геймплей. Его нет. По идее, главным должен быть геймплей-луп:
Раньше идея была "просто жить в городе", так что я вообще не представлял, что именно делать нужно.
Теперь... Допустим, можно так:
1. Едем куда глаза глядят по дороге;
2. Доезжаем до случайного "города" (3.5 домика);
3. Делаем мелкие задания (?) жителей, зарабатывая деньги на всякие шмотки, запчасти, топливо и т.п.;
4. Едем дальше, поскольку контент размазан между городами, в одном городе никогда нет 100% контента. Каждый город своего рода процедурный лутбокс. Ну, можно сделать ресурс каждого города конечным. Скупил всё что мог - пополнения товаров не будет.
Плюс можно напридумывать много побочных лупов, особенно в виде случайных событий на дороге. Типа подбросить кого-то до города, или поменять колесо. Следить за параметрами персонажа, чтобы не уснуть прямо за рулём в дороге, делать остановки.
Что делать с возможностью ехать в обратном направлении пока не знаю, нужно ещё подумать. Наверное, стоит сохранять на диск минимум один город вместе с дорогой до него. Потом удалять.
Глобальную мировую карту генерировать не хочу...
>>881868
Эээ, ну, даже не знаю. Я просто накидал кислотных коробок и мучаюсь с кувыркающимся VehicleBody.
Графика плейсхолдерная, чтобы прикинуть габариты и запилить геймплей раньше графики. Но да, хочу что-то сравнительно жизнерадостное...
Что там некрасивого, вроде норм. Тоже хочу что-то похожее на аниме сделать, но это сложно. А готовые модельки использовать не хочу.
>будут слишком похожими, ну и смысл...
Подумал ещё и ВНЕЗАПНО вспомнил, что от честной генерации а-ля майнкрафт толку ровным счётом ноль, потому что даже если все участки карты технически разные, субъективно разница между ними как между тарелками одной и той же каши.
Тогда решил всё-таки собрать прототип на вручную смоделированных блоках и... получились какие-то рандомные американские горки?.. Кстати, пробовал ехать как можно дольше - спустя 40 км (!) надоело ждать проявления этих глитчей:
>There may also be rendering and physics glitches due to floating point error in large worlds. You may be able to use techniques such as orienting the world around the player (rather than the other way around), or shifting the origin periodically to keep things centred around Vector3(0, 0, 0).
Если делать дорогу реально бесконечной, то, конечно, сдвигать мир придётся. Но для обычной игры должно хватать точности без этого сдвига. Я про ГТА, в космосимах совсем другие проблемы, конечно.
В любом случае, я вспомнил, что в попытках сделать генератор забыл о самом главном - геймплей. Его нет. По идее, главным должен быть геймплей-луп:
>A gameplay loop consists of a cycle of actions that you repeat over and over within a game.
Раньше идея была "просто жить в городе", так что я вообще не представлял, что именно делать нужно.
Теперь... Допустим, можно так:
1. Едем куда глаза глядят по дороге;
2. Доезжаем до случайного "города" (3.5 домика);
3. Делаем мелкие задания (?) жителей, зарабатывая деньги на всякие шмотки, запчасти, топливо и т.п.;
4. Едем дальше, поскольку контент размазан между городами, в одном городе никогда нет 100% контента. Каждый город своего рода процедурный лутбокс. Ну, можно сделать ресурс каждого города конечным. Скупил всё что мог - пополнения товаров не будет.
Плюс можно напридумывать много побочных лупов, особенно в виде случайных событий на дороге. Типа подбросить кого-то до города, или поменять колесо. Следить за параметрами персонажа, чтобы не уснуть прямо за рулём в дороге, делать остановки.
Что делать с возможностью ехать в обратном направлении пока не знаю, нужно ещё подумать. Наверное, стоит сохранять на диск минимум один город вместе с дорогой до него. Потом удалять.
Глобальную мировую карту генерировать не хочу...
>>881868
>Твой прототип выглядит очень выгодно на фоне
Эээ, ну, даже не знаю. Я просто накидал кислотных коробок и мучаюсь с кувыркающимся VehicleBody.
Графика плейсхолдерная, чтобы прикинуть габариты и запилить геймплей раньше графики. Но да, хочу что-то сравнительно жизнерадостное...
>некрасивых игр
>проклятые анимепанцу
Что там некрасивого, вроде норм. Тоже хочу что-то похожее на аниме сделать, но это сложно. А готовые модельки использовать не хочу.
Если кому интересно, как сделать плавно изогнутые дороги в блендере, то это чрезвычайно просто:
1. Делаете первую, прямую секцию дороги.
2. Кидаете модификаторы Array и Curve.
3. Создаёте Path или другую кривую.
4. ??? ...играете настройками, сабдивом и т.д.
5. Восхитительно плавная дорога!
>>881895
Была подобная идея для другой игры, а в этой я планировал сделать относительно наш мир. Да и объяснение ещё придумать нужно адекватное.
А если пропустил/забыл что-то и хочешь назад? Много причин вернуться хотя бы в последний пройденный город. Так что некоторый "хвост" стоит поддерживать. Я бы и сам этой фичей пользовался.
Представь, потерял капот по дороге, в городе нашёл подходящий, но денег не хватает, поехал дальше и случайное событие дало достаточно денег, едешь обратно весь такой в предвкушении, а там ДРУГОЙ город и никакого капота в продаже нет...
1. Делаете первую, прямую секцию дороги.
2. Кидаете модификаторы Array и Curve.
3. Создаёте Path или другую кривую.
4. ??? ...играете настройками, сабдивом и т.д.
5. Восхитительно плавная дорога!
>>881895
>лорно объясни почему города пропадают
Была подобная идея для другой игры, а в этой я планировал сделать относительно наш мир. Да и объяснение ещё придумать нужно адекватное.
>Будет что в какую бы сторону игрок не ехал он едет вперед и там всегда что-то новое.
А если пропустил/забыл что-то и хочешь назад? Много причин вернуться хотя бы в последний пройденный город. Так что некоторый "хвост" стоит поддерживать. Я бы и сам этой фичей пользовался.
Представь, потерял капот по дороге, в городе нашёл подходящий, но денег не хватает, поехал дальше и случайное событие дало достаточно денег, едешь обратно весь такой в предвкушении, а там ДРУГОЙ город и никакого капота в продаже нет...
>>881897
Так хуле проблема? Пусть игрок сюжетно от чего-то бежит. Скажем, от закона или карточных долгов. Если вернуться в прошлый город, тебя там встретит полиция или мафия, которой ты должен. Получится такое-то охуенное роуд-муви. Если вариант с долгами, то это можно даже сделать целью игры (хотя бы для одной из концовок) - заработать денег, чтобы его вернуть.
>Была подобная идея для другой игры, а в этой я планировал сделать относительно наш мир. Да и объяснение ещё придумать нужно адекватное.
Так хуле проблема? Пусть игрок сюжетно от чего-то бежит. Скажем, от закона или карточных долгов. Если вернуться в прошлый город, тебя там встретит полиция или мафия, которой ты должен. Получится такое-то охуенное роуд-муви. Если вариант с долгами, то это можно даже сделать целью игры (хотя бы для одной из концовок) - заработать денег, чтобы его вернуть.
>>881904
Ааа... Ясно, забыл сказать, что сюжета нет, игра не должна обязывать игрока делать что-то по сюжету.
Вот в ГТА тебе игра постоянно меткой на карте напоминает, ещё персонажи названивают. Иди сюда, делай то, делай это, вот 50$ на чай, теперь уходи, но оставайся на связи до следующего задания.
А в Майнкрафт есть дракон и даже титры, но игра не сообщает об этом, не показывает стрелочкой, куда идти и что делать. В Террарии есть порядок боссов и игра может наслать на тебя события, но она не принуждает тебя развиваться и вызывать боссов.
Вот сеттинг и геймплей меня в ГТА привлекает, но сюжет всегда казался лишней рутиной. Я зашёл покататься по городу и поиграть в мини-игры, а с меня тут требуют что-то, задолбали...
Так что в своей игре я задумывал 100% песочницу без принудиловки. Заспавнился в городе и делаешь что пожелаешь в рамках доступных возможностей. Не торопишься никуда, не занимаешься рутиной. Хочешь быть гангстером в бегах - будь, хочешь быть кем-то другим - тоже можешь без проблем. Всерьёз думаю о создании грузовиков и грузоперевозок - но только как опция, как та побочная миссия в GTA SA. Не хочешь возить грузы - не проблема, игра не заставит.
Ладно, эти вопросы можно потом решить.
>сюжетно
Ааа... Ясно, забыл сказать, что сюжета нет, игра не должна обязывать игрока делать что-то по сюжету.
Вот в ГТА тебе игра постоянно меткой на карте напоминает, ещё персонажи названивают. Иди сюда, делай то, делай это, вот 50$ на чай, теперь уходи, но оставайся на связи до следующего задания.
А в Майнкрафт есть дракон и даже титры, но игра не сообщает об этом, не показывает стрелочкой, куда идти и что делать. В Террарии есть порядок боссов и игра может наслать на тебя события, но она не принуждает тебя развиваться и вызывать боссов.
Вот сеттинг и геймплей меня в ГТА привлекает, но сюжет всегда казался лишней рутиной. Я зашёл покататься по городу и поиграть в мини-игры, а с меня тут требуют что-то, задолбали...
Так что в своей игре я задумывал 100% песочницу без принудиловки. Заспавнился в городе и делаешь что пожелаешь в рамках доступных возможностей. Не торопишься никуда, не занимаешься рутиной. Хочешь быть гангстером в бегах - будь, хочешь быть кем-то другим - тоже можешь без проблем. Всерьёз думаю о создании грузовиков и грузоперевозок - но только как опция, как та побочная миссия в GTA SA. Не хочешь возить грузы - не проблема, игра не заставит.
Ладно, эти вопросы можно потом решить.
>>881908
Я не говорю тебе прямо прописывать сюжет. Просто дать установку - вот мол, нельзя вернуться назад потому то потому то. Или вообще пусть ГГ при попытке вернуться в позапрошлый город говорит "Я не могу вернуться назад" и многозначительное многоточие, а еще лучше - придумай побольше всяких подобных ничего не значащих, но меланхолично звучащих фраз и выдавай их случайно.
Критики тебя потом на руках носить будут, а игроки будут СПГСить как умалишенные.
Я не говорю тебе прямо прописывать сюжет. Просто дать установку - вот мол, нельзя вернуться назад потому то потому то. Или вообще пусть ГГ при попытке вернуться в позапрошлый город говорит "Я не могу вернуться назад" и многозначительное многоточие, а еще лучше - придумай побольше всяких подобных ничего не значащих, но меланхолично звучащих фраз и выдавай их случайно.
>я не могу вернуться назад...
>я оставил былое позади...
>прошлое может настичь меня там...
Критики тебя потом на руках носить будут, а игроки будут СПГСить как умалишенные.
765 Кб, mp4,800x600, 0:25
>>881925
Меня больше волнует, что делать со всем остальным, что вокруг дороги. Растягивать тайлы на несколько километров в ширину? Делать горы, заборы и сплошные стены из деревьев а-ля первая Мафия (частично вдохновлялся одной загородной миссией, там какая-то очень длинная дорога с кучей поворотов и ландшафт прикольный, но съехать с дороги нельзя из-за заборчиков)? Или прикрутить карту высот с шумом Перлина? Я уже не уверен, что это опенворлд, если мир вытянут в бесконечную кишку с невидимыми стенами по бокам, даже если по пути этой кишки встречаются локации-города.
Блин, пока что получается что-то ближе к аркадным гонкам-раннерам, чем к ГТА.
Но, может, оно и к лучшему.
Меня больше волнует, что делать со всем остальным, что вокруг дороги. Растягивать тайлы на несколько километров в ширину? Делать горы, заборы и сплошные стены из деревьев а-ля первая Мафия (частично вдохновлялся одной загородной миссией, там какая-то очень длинная дорога с кучей поворотов и ландшафт прикольный, но съехать с дороги нельзя из-за заборчиков)? Или прикрутить карту высот с шумом Перлина? Я уже не уверен, что это опенворлд, если мир вытянут в бесконечную кишку с невидимыми стенами по бокам, даже если по пути этой кишки встречаются локации-города.
Блин, пока что получается что-то ближе к аркадным гонкам-раннерам, чем к ГТА.
Но, может, оно и к лучшему.
31 Кб, 160x160Накидайте арта для переката, плиз, годаны, а я завтра перекачу.
>>881966
делай дальнобойщиков.
делай дальнобойщиков.
233 Кб, 800x990>>881992
Алсо жиза
Алсо жиза
11,3 Мб, mp4,640x360, 3:40
>>881966
Тебя должно больше волновать что ты сам настолько не знаешь что от игры хочешь, что у тебя даже нет понимания что же у тебя за кор механика.
Я ХАЧУ СДЕЛОТЬ СВОЮ ЖТА С ПРОЦЕДУРНЫМ ГОРОДОМ ГДЕ ХЗ ЧТО ДЕЛАТЬ И МЕЖДУ ТАКИМИ ГОРАДМИ МОЖНА ЕЗДИТЬ это не кор механика и даже не примерное описание идеи.
Что ты хочешь от игры?
Чем является твоя игра?
С ответа на эти вопросы надо начинать и от этого уже плясать, а не прокрастинировать задумываясь от том что же будет по бокам дороги. Это детали, а думать нужно о сути.
>Меня больше волнует, что делать со всем остальным
Тебя должно больше волновать что ты сам настолько не знаешь что от игры хочешь, что у тебя даже нет понимания что же у тебя за кор механика.
Я ХАЧУ СДЕЛОТЬ СВОЮ ЖТА С ПРОЦЕДУРНЫМ ГОРОДОМ ГДЕ ХЗ ЧТО ДЕЛАТЬ И МЕЖДУ ТАКИМИ ГОРАДМИ МОЖНА ЕЗДИТЬ это не кор механика и даже не примерное описание идеи.
Что ты хочешь от игры?
Чем является твоя игра?
С ответа на эти вопросы надо начинать и от этого уже плясать, а не прокрастинировать задумываясь от том что же будет по бокам дороги. Это детали, а думать нужно о сути.
>>882071
Ты абсолютно прав, анон.
А какая кор механика в самой ЖТА?
Фундамент для добавления всякого интересного.
Экшн-адвенчур песочницей с симуляцией жизни.
Смотри, в жта я могу просто зайти, гоп-стопнуть понравившуюся машинку и несколько ирл часов совершенно бесцельно нарезать круги по городу. Это достаточно интересно, но надоедает, ведь:
1. Город статичный и никак не меняется. Один раз его изучив, ты ничего нового в нём не найдёшь. Даже взорвав тысячи машин и убив тысячи людей ты ровным счётом ни на что не повлияешь.
2. Человечки - тупые дроны на замкнутых маршрутах, к которым игрок может только насилие применять. 3.5 случайных сценки погоды не меняют. Только у проституток есть осмысленный выбор Y/N (GTA SA) или аж три строчки диалогового меню (GTA IV, V). Механика свиданий максимально линейная, а свидабельные персонажи захардкожены.
3. Домики - пустые кубы с текстурами, не считая 3.5 локации где что-то есть и 1.5 локации где есть интерактивные предметы с мини-играми. Не говоря о том, насколько абсурдный урон они выдерживают.
4. Машинки настолько аркадные, что способны ехать даже после сплющивания в лепёшку (GTA IV). Но ещё больше огорчает мгновенная починка любого урона и исчезновение оставленного транспорта.
5. Графон "типа реализм" навевает уныние, будто вышел на улицу и увидел знакомый гадюшник. Вбухали тонны бабла чтобы нагнетать уныние...
6. Дурацкая сюжетка про мамкиных гопников. Если бы я хотел катсцены и диалоги, я бы зашёл на ютуб...
В общем, я мечтал решить хотя бы часть этих проблем своими силами, но не модом, а созданием полностью независимой игры с аналогичным фундаментом.
1. Чарактер контроллер я накидал по-быстрому.
2. Несколько машинок я накидал на VehicleBody.
3. Генератор города я сделал аж в нескольких разных вариантах, но контентом наполнять их не стал, потому что кататься по "квадратно-гнездовым" улицам оказалось чуть более чем уныло, а что-то интереснее придумать (!) не получилось.
4. Неигровых персонажей я пробовал делать, но их проблема в отсутствии жёсткого фундамента. Нельзя сделать модель человека без тела, а тело без среды обитания, а среды обитания у меня нет, ведь я не смог придумать интересный генератор среды.
5. Графику, физику машин отложил ещё дальше: без фундамента это кажется лишней тратой времени.
Подумал вот, что можно компенсировать нехватку интереса от одного города последовательной генерацией множества разных поменьше, даже если они будут неполноценными в плане симуляции жизни, которая игроку всё равно не слишком заметна от первого лица (что там за закрытыми дверями происходит... а какая разница?). Перенести приоритет игры с полномасштабной симуляции целого города на симуляцию всего нескольких (свидабельных) персонажей вокруг игрока, в прямом смысле забывая весь остальной мир вместе с персонажами. Тогда можно просто ехать в одном направлении, получая новый контент и/или новые комбинации старого контента и множество случайных ситуаций по пути. Тем более что езда по длинной загородной дороге имеет чуть больше смысла, чем нарезание кругов по городу площадью в один жилой квартал в реальном мире. Алсо это органично и даже незаметно вписывает лутбоксы в игровой мир, а без них никуда, лутбоксы - это кровь любой современной игры, без них никто играть не будет (тут я пытаюсь пошутить, но это почти не шутка, к сожалению).
P.S. Из сливов GTA VI пришёл к выводу, что фиксить обозначенные проблемы рокстар не собираются, так что оригинальная ГТА мне пока что не конкурент. Посмотрим, что они придумают в семёрке...
>ты сам настолько не знаешь что от игры хочешь, что у тебя даже нет понимания что же у тебя за кор механика
Ты абсолютно прав, анон.
>ХАЧУ СДЕЛОТЬ СВОЮ ЖТА
>это не кор механика
А какая кор механика в самой ЖТА?
>Что ты хочешь от игры?
Фундамент для добавления всякого интересного.
>Чем является твоя игра?
Экшн-адвенчур песочницей с симуляцией жизни.
Смотри, в жта я могу просто зайти, гоп-стопнуть понравившуюся машинку и несколько ирл часов совершенно бесцельно нарезать круги по городу. Это достаточно интересно, но надоедает, ведь:
1. Город статичный и никак не меняется. Один раз его изучив, ты ничего нового в нём не найдёшь. Даже взорвав тысячи машин и убив тысячи людей ты ровным счётом ни на что не повлияешь.
2. Человечки - тупые дроны на замкнутых маршрутах, к которым игрок может только насилие применять. 3.5 случайных сценки погоды не меняют. Только у проституток есть осмысленный выбор Y/N (GTA SA) или аж три строчки диалогового меню (GTA IV, V). Механика свиданий максимально линейная, а свидабельные персонажи захардкожены.
3. Домики - пустые кубы с текстурами, не считая 3.5 локации где что-то есть и 1.5 локации где есть интерактивные предметы с мини-играми. Не говоря о том, насколько абсурдный урон они выдерживают.
4. Машинки настолько аркадные, что способны ехать даже после сплющивания в лепёшку (GTA IV). Но ещё больше огорчает мгновенная починка любого урона и исчезновение оставленного транспорта.
5. Графон "типа реализм" навевает уныние, будто вышел на улицу и увидел знакомый гадюшник. Вбухали тонны бабла чтобы нагнетать уныние...
6. Дурацкая сюжетка про мамкиных гопников. Если бы я хотел катсцены и диалоги, я бы зашёл на ютуб...
В общем, я мечтал решить хотя бы часть этих проблем своими силами, но не модом, а созданием полностью независимой игры с аналогичным фундаментом.
1. Чарактер контроллер я накидал по-быстрому.
2. Несколько машинок я накидал на VehicleBody.
3. Генератор города я сделал аж в нескольких разных вариантах, но контентом наполнять их не стал, потому что кататься по "квадратно-гнездовым" улицам оказалось чуть более чем уныло, а что-то интереснее придумать (!) не получилось.
4. Неигровых персонажей я пробовал делать, но их проблема в отсутствии жёсткого фундамента. Нельзя сделать модель человека без тела, а тело без среды обитания, а среды обитания у меня нет, ведь я не смог придумать интересный генератор среды.
5. Графику, физику машин отложил ещё дальше: без фундамента это кажется лишней тратой времени.
Подумал вот, что можно компенсировать нехватку интереса от одного города последовательной генерацией множества разных поменьше, даже если они будут неполноценными в плане симуляции жизни, которая игроку всё равно не слишком заметна от первого лица (что там за закрытыми дверями происходит... а какая разница?). Перенести приоритет игры с полномасштабной симуляции целого города на симуляцию всего нескольких (свидабельных) персонажей вокруг игрока, в прямом смысле забывая весь остальной мир вместе с персонажами. Тогда можно просто ехать в одном направлении, получая новый контент и/или новые комбинации старого контента и множество случайных ситуаций по пути. Тем более что езда по длинной загородной дороге имеет чуть больше смысла, чем нарезание кругов по городу площадью в один жилой квартал в реальном мире. Алсо это органично и даже незаметно вписывает лутбоксы в игровой мир, а без них никуда, лутбоксы - это кровь любой современной игры, без них никто играть не будет (тут я пытаюсь пошутить, но это почти не шутка, к сожалению).
P.S. Из сливов GTA VI пришёл к выводу, что фиксить обозначенные проблемы рокстар не собираются, так что оригинальная ГТА мне пока что не конкурент. Посмотрим, что они придумают в семёрке...
>>882071
Ты абсолютно прав, анон.
А какая кор механика в самой ЖТА?
Фундамент для добавления всякого интересного.
Экшн-адвенчур песочницей с симуляцией жизни.
Смотри, в жта я могу просто зайти, гоп-стопнуть понравившуюся машинку и несколько ирл часов совершенно бесцельно нарезать круги по городу. Это достаточно интересно, но надоедает, ведь:
1. Город статичный и никак не меняется. Один раз его изучив, ты ничего нового в нём не найдёшь. Даже взорвав тысячи машин и убив тысячи людей ты ровным счётом ни на что не повлияешь.
2. Человечки - тупые дроны на замкнутых маршрутах, к которым игрок может только насилие применять. 3.5 случайных сценки погоды не меняют. Только у проституток есть осмысленный выбор Y/N (GTA SA) или аж три строчки диалогового меню (GTA IV, V). Механика свиданий максимально линейная, а свидабельные персонажи захардкожены.
3. Домики - пустые кубы с текстурами, не считая 3.5 локации где что-то есть и 1.5 локации где есть интерактивные предметы с мини-играми. Не говоря о том, насколько абсурдный урон они выдерживают.
4. Машинки настолько аркадные, что способны ехать даже после сплющивания в лепёшку (GTA IV). Но ещё больше огорчает мгновенная починка любого урона и исчезновение оставленного транспорта.
5. Графон "типа реализм" навевает уныние, будто вышел на улицу и увидел знакомый гадюшник. Вбухали тонны бабла чтобы нагнетать уныние...
6. Дурацкая сюжетка про мамкиных гопников. Если бы я хотел катсцены и диалоги, я бы зашёл на ютуб...
В общем, я мечтал решить хотя бы часть этих проблем своими силами, но не модом, а созданием полностью независимой игры с аналогичным фундаментом.
1. Чарактер контроллер я накидал по-быстрому.
2. Несколько машинок я накидал на VehicleBody.
3. Генератор города я сделал аж в нескольких разных вариантах, но контентом наполнять их не стал, потому что кататься по "квадратно-гнездовым" улицам оказалось чуть более чем уныло, а что-то интереснее придумать (!) не получилось.
4. Неигровых персонажей я пробовал делать, но их проблема в отсутствии жёсткого фундамента. Нельзя сделать модель человека без тела, а тело без среды обитания, а среды обитания у меня нет, ведь я не смог придумать интересный генератор среды.
5. Графику, физику машин отложил ещё дальше: без фундамента это кажется лишней тратой времени.
Подумал вот, что можно компенсировать нехватку интереса от одного города последовательной генерацией множества разных поменьше, даже если они будут неполноценными в плане симуляции жизни, которая игроку всё равно не слишком заметна от первого лица (что там за закрытыми дверями происходит... а какая разница?). Перенести приоритет игры с полномасштабной симуляции целого города на симуляцию всего нескольких (свидабельных) персонажей вокруг игрока, в прямом смысле забывая весь остальной мир вместе с персонажами. Тогда можно просто ехать в одном направлении, получая новый контент и/или новые комбинации старого контента и множество случайных ситуаций по пути. Тем более что езда по длинной загородной дороге имеет чуть больше смысла, чем нарезание кругов по городу площадью в один жилой квартал в реальном мире. Алсо это органично и даже незаметно вписывает лутбоксы в игровой мир, а без них никуда, лутбоксы - это кровь любой современной игры, без них никто играть не будет (тут я пытаюсь пошутить, но это почти не шутка, к сожалению).
P.S. Из сливов GTA VI пришёл к выводу, что фиксить обозначенные проблемы рокстар не собираются, так что оригинальная ГТА мне пока что не конкурент. Посмотрим, что они придумают в семёрке...
>ты сам настолько не знаешь что от игры хочешь, что у тебя даже нет понимания что же у тебя за кор механика
Ты абсолютно прав, анон.
>ХАЧУ СДЕЛОТЬ СВОЮ ЖТА
>это не кор механика
А какая кор механика в самой ЖТА?
>Что ты хочешь от игры?
Фундамент для добавления всякого интересного.
>Чем является твоя игра?
Экшн-адвенчур песочницей с симуляцией жизни.
Смотри, в жта я могу просто зайти, гоп-стопнуть понравившуюся машинку и несколько ирл часов совершенно бесцельно нарезать круги по городу. Это достаточно интересно, но надоедает, ведь:
1. Город статичный и никак не меняется. Один раз его изучив, ты ничего нового в нём не найдёшь. Даже взорвав тысячи машин и убив тысячи людей ты ровным счётом ни на что не повлияешь.
2. Человечки - тупые дроны на замкнутых маршрутах, к которым игрок может только насилие применять. 3.5 случайных сценки погоды не меняют. Только у проституток есть осмысленный выбор Y/N (GTA SA) или аж три строчки диалогового меню (GTA IV, V). Механика свиданий максимально линейная, а свидабельные персонажи захардкожены.
3. Домики - пустые кубы с текстурами, не считая 3.5 локации где что-то есть и 1.5 локации где есть интерактивные предметы с мини-играми. Не говоря о том, насколько абсурдный урон они выдерживают.
4. Машинки настолько аркадные, что способны ехать даже после сплющивания в лепёшку (GTA IV). Но ещё больше огорчает мгновенная починка любого урона и исчезновение оставленного транспорта.
5. Графон "типа реализм" навевает уныние, будто вышел на улицу и увидел знакомый гадюшник. Вбухали тонны бабла чтобы нагнетать уныние...
6. Дурацкая сюжетка про мамкиных гопников. Если бы я хотел катсцены и диалоги, я бы зашёл на ютуб...
В общем, я мечтал решить хотя бы часть этих проблем своими силами, но не модом, а созданием полностью независимой игры с аналогичным фундаментом.
1. Чарактер контроллер я накидал по-быстрому.
2. Несколько машинок я накидал на VehicleBody.
3. Генератор города я сделал аж в нескольких разных вариантах, но контентом наполнять их не стал, потому что кататься по "квадратно-гнездовым" улицам оказалось чуть более чем уныло, а что-то интереснее придумать (!) не получилось.
4. Неигровых персонажей я пробовал делать, но их проблема в отсутствии жёсткого фундамента. Нельзя сделать модель человека без тела, а тело без среды обитания, а среды обитания у меня нет, ведь я не смог придумать интересный генератор среды.
5. Графику, физику машин отложил ещё дальше: без фундамента это кажется лишней тратой времени.
Подумал вот, что можно компенсировать нехватку интереса от одного города последовательной генерацией множества разных поменьше, даже если они будут неполноценными в плане симуляции жизни, которая игроку всё равно не слишком заметна от первого лица (что там за закрытыми дверями происходит... а какая разница?). Перенести приоритет игры с полномасштабной симуляции целого города на симуляцию всего нескольких (свидабельных) персонажей вокруг игрока, в прямом смысле забывая весь остальной мир вместе с персонажами. Тогда можно просто ехать в одном направлении, получая новый контент и/или новые комбинации старого контента и множество случайных ситуаций по пути. Тем более что езда по длинной загородной дороге имеет чуть больше смысла, чем нарезание кругов по городу площадью в один жилой квартал в реальном мире. Алсо это органично и даже незаметно вписывает лутбоксы в игровой мир, а без них никуда, лутбоксы - это кровь любой современной игры, без них никто играть не будет (тут я пытаюсь пошутить, но это почти не шутка, к сожалению).
P.S. Из сливов GTA VI пришёл к выводу, что фиксить обозначенные проблемы рокстар не собираются, так что оригинальная ГТА мне пока что не конкурент. Посмотрим, что они придумают в семёрке...
>>882081
- Получил миссию.
- Выполнил задачи миссии.
- Получил деньги.
- Потратил деньги.
Повторить до конца игры.
> А какая кор механика в самой ЖТА?
- Получил миссию.
- Выполнил задачи миссии.
- Получил деньги.
- Потратил деньги.
Повторить до конца игры.
>>882095
Лол, больше всего времени потратил на бесцельные скитания по миру и всякие эксперименты с физикой, машинами, пешеходами и т.д. Потом "ой, наверное, нужно миссии проходить..." и не могу вспомнить, кто эти люди и почему я им что-то должен. Поэтому предпочёл бы больше мелких, не связанных друг с другом заданий (даже процедурных и повторяющихся, как в GTA Online), чем сюжетку с длинной историей... А потом кто-то спорит, утверждая, что ГТА не песочница...
Самое смешное, что во всей серии GTA это одна из главных проблем геймдизайна. ДЕНЬГИ ТУПО НЕКУДА ТРАТИТЬ. В GTA Online это "пофиксили" безумными ценниками на всякие мафынки и их модификации, ограничением на число гаражей, платой за перенос предприятия с место на место, смену декораций и т.д. Но всё равно некоторые скапливают миллиарды честной игрой, и эти миллиарды не на что тратить, ведь самое дорогое стоит "всего" чуть больше десятка миллионов. Деньги очень быстро теряют смысл, тем более в старых GTA, где покупать практически нечего. Риска потерять деньги почти нет, штрафы смешные.
>- Получил миссию.
>- Выполнил задачи миссии.
Лол, больше всего времени потратил на бесцельные скитания по миру и всякие эксперименты с физикой, машинами, пешеходами и т.д. Потом "ой, наверное, нужно миссии проходить..." и не могу вспомнить, кто эти люди и почему я им что-то должен. Поэтому предпочёл бы больше мелких, не связанных друг с другом заданий (даже процедурных и повторяющихся, как в GTA Online), чем сюжетку с длинной историей... А потом кто-то спорит, утверждая, что ГТА не песочница...
>- Потратил деньги.
>Повторить до конца игры.
Самое смешное, что во всей серии GTA это одна из главных проблем геймдизайна. ДЕНЬГИ ТУПО НЕКУДА ТРАТИТЬ. В GTA Online это "пофиксили" безумными ценниками на всякие мафынки и их модификации, ограничением на число гаражей, платой за перенос предприятия с место на место, смену декораций и т.д. Но всё равно некоторые скапливают миллиарды честной игрой, и эти миллиарды не на что тратить, ведь самое дорогое стоит "всего" чуть больше десятка миллионов. Деньги очень быстро теряют смысл, тем более в старых GTA, где покупать практически нечего. Риска потерять деньги почти нет, штрафы смешные.
тест поста з dashchan
Я правильно понимаю что в 4 версии годота если я хочу писать логику на плючах, то путь таков?
Пишу логику
Компилирую логику в динамическую библиотеку под целевую систему
Подключаю её в проекте через нод-обёртку?
Пишу логику
Компилирую логику в динамическую библиотеку под целевую систему
Подключаю её в проекте через нод-обёртку?
>>882134
Да вроде и раньше так можно было...
GDNative -> GDExtension.
>Компилирую логику в динамическую библиотеку под целевую систему
Да вроде и раньше так можно было...
GDNative -> GDExtension.
>>882098
Ну я в основном от сан андреаса отталкиваюсь. Там набросали кучу объектов, которые надо купить для продолжения сюжета. Но и в вайс-сити надо было как минимум малибу и жёлтоетакси покупать. А что было ранее я уже не помню.
Возражение уровня "а я вместо того чтобы играть с этим ботаном, швырнул ему шахматы в еблину". Нашёл чем хвастаться. Но к чести рокстара, да, песочницу они завезли добротную. Пиздюками мы все гоняли на маффынках от ментов с аснаёбом, и только повзрослев, узнавали, что там сюжет оказывается есть.
> тем более в старых GTA
Ну я в основном от сан андреаса отталкиваюсь. Там набросали кучу объектов, которые надо купить для продолжения сюжета. Но и в вайс-сити надо было как минимум малибу и жёлтоетакси покупать. А что было ранее я уже не помню.
> больше всего времени потратил на бесцельные скитания по миру
Возражение уровня "а я вместо того чтобы играть с этим ботаном, швырнул ему шахматы в еблину". Нашёл чем хвастаться. Но к чести рокстара, да, песочницу они завезли добротную. Пиздюками мы все гоняли на маффынках от ментов с аснаёбом, и только повзрослев, узнавали, что там сюжет оказывается есть.
>>882134
Не правильно понимаешь.
В 4 как и в 3, ты можешь как писать динамическую библиотеку, так и писать модули для движка. Написание модулей - самое скоростное решение. Ты прямо в ядре движка будешь работать с максимальной скоростью, зависящей только от оптимизации твоего кода и от железа офк. Подключение либы уже будет давать накладные расходы, которые впрочем, при грамотном кодинге никто не заметит, но зато в папке с игрой будет насрано либами. Но либы ты можешь написать на любом языке, который может в компиляцию либ. А модули движка только на крестах.
Не правильно понимаешь.
В 4 как и в 3, ты можешь как писать динамическую библиотеку, так и писать модули для движка. Написание модулей - самое скоростное решение. Ты прямо в ядре движка будешь работать с максимальной скоростью, зависящей только от оптимизации твоего кода и от железа офк. Подключение либы уже будет давать накладные расходы, которые впрочем, при грамотном кодинге никто не заметит, но зато в папке с игрой будет насрано либами. Но либы ты можешь написать на любом языке, который может в компиляцию либ. А модули движка только на крестах.
>>882148
Все так играли. Мне больше всего запомнилось, как я долго и упорно пытался проникнуть на еще недоступную киностудию, подгонял автоперевозчик, использовал его как трамплин. Помню ли я что нибудь из сюжета? Вообщем то нет.
Все так играли. Мне больше всего запомнилось, как я долго и упорно пытался проникнуть на еще недоступную киностудию, подгонял автоперевозчик, использовал его как трамплин. Помню ли я что нибудь из сюжета? Вообщем то нет.
Аноны, а чего по фепесам в четвёрке? Делаю обычный платформер, и на Ryzen 3 3200g + Vega 8 (встройка от рязани) + 8gb ddr3 (или 4, не помню) получаю 20 фепесов с ёба шейдерами и 40-50 без них. Как можно адекватно глянуть, что именно столько ресурсов пожирает?
59 Кб, 1311x512>>882905
В профайлере вот так
В профайлере вот так
>>882903
Just use Unreal
Just use Unreal
>>873235 (OP)
gdscript это типа брат близнец kotlin?
gdscript это типа брат близнец kotlin?
Попробовал движок, ощущается как-то приятнее, чем Unity, без всех этих аккаунтов, говноверсий и прочего мусора. Чем еще он лучше?
33 Кб, 800x600Здарова, годаны. Вброшу и сюда тоже.
Корочи, сделал простеньку игру на Godot'е по концету геймплея из этого видео:
https://www.youtube.com/watch?v=J_qQ76ouWXI&list=PLgsD7taGtaBidBJSgyxcet_o2k0Kqr-e5&index=24
Но мой вариант больше под спидран заточен.
Скачать можно отсюда:
http://j33111470.myjino.ru/cells_game
(это мой хостинг с бесплатным доменным именем)
Там есть и веб-версия, но она тормозит и не у всех вообще работает. Предположительно, версия движка слишком старая (3.1) и/или проблемы с GLES2 на современных браузерах. Билды есть под винду и под Линукс, 32-х и 64-х битные.
Вот.
Корочи, сделал простеньку игру на Godot'е по концету геймплея из этого видео:
https://www.youtube.com/watch?v=J_qQ76ouWXI&list=PLgsD7taGtaBidBJSgyxcet_o2k0Kqr-e5&index=24
Но мой вариант больше под спидран заточен.
Скачать можно отсюда:
http://j33111470.myjino.ru/cells_game
(это мой хостинг с бесплатным доменным именем)
Там есть и веб-версия, но она тормозит и не у всех вообще работает. Предположительно, версия движка слишком старая (3.1) и/или проблемы с GLES2 на современных браузерах. Билды есть под винду и под Линукс, 32-х и 64-х битные.
Вот.
>>892931
Перемещение: стрелки, WASD, кнопки UI.
Рестарт: пробел, Enter, R, копка UI.
Звук тоже можно кнопкой отключать или на M.
Чтобы в веб-версии управление заработало, нужно после загрузки игры на экран кликнуть, чтобы окно игры было в фокусе.
Перемещение: стрелки, WASD, кнопки UI.
Рестарт: пробел, Enter, R, копка UI.
Звук тоже можно кнопкой отключать или на M.
Чтобы в веб-версии управление заработало, нужно после загрузки игры на экран кликнуть, чтобы окно игры было в фокусе.
Занимаюсь в данную единицу времени переносом одной игры на Godot, довольно таки... Успешно? Не суть.
В связи с юридическим аспектом нужно сделать так чтобы пользователь распаковал файлы оригинальной игры и сунул в папку с exe моего переноса, пока прикидывал просто выдирал файлы и совал в проект настраивая всё, сейчас понял что я лучше сейчас переделаю малый объём работы, чем буду всё переделывать на такую формулу в последний момент.
Встал вопрос - как использовать файлы из одной папки с исполняемым файлом не используя скрипты и никак не упаковывая эти файлы? Желательно, но не обязательно чтобы их было видно в редакторе.
В связи с юридическим аспектом нужно сделать так чтобы пользователь распаковал файлы оригинальной игры и сунул в папку с exe моего переноса, пока прикидывал просто выдирал файлы и совал в проект настраивая всё, сейчас понял что я лучше сейчас переделаю малый объём работы, чем буду всё переделывать на такую формулу в последний момент.
Встал вопрос - как использовать файлы из одной папки с исполняемым файлом не используя скрипты и никак не упаковывая эти файлы? Желательно, но не обязательно чтобы их было видно в редакторе.
>>887184
Типо внебрачный сын python и typescript
Типо внебрачный сын python и typescript
>>874896
А мне не нравится, извини, ОП. Какое-то всё крупное будто сделано для смартфона. Может на https://rentry.co/ или https://markdownpastebin.com/ напишешь? Оно как-то привычнее анонимусу, пынямаешь? Ну и спасибо за старания, опчик, целую в щёчку!
А мне не нравится, извини, ОП. Какое-то всё крупное будто сделано для смартфона. Может на https://rentry.co/ или https://markdownpastebin.com/ напишешь? Оно как-то привычнее анонимусу, пынямаешь? Ну и спасибо за старания, опчик, целую в щёчку!
Вопрос от ниосилятора в программирование. Существуют ли какие-то шпаргалки кода по разным тематикам на gdscript?
Я имею ввиду следующее:
например мне надо описать стандартные для игр действия - человек бежит, стреляет.
Я беру кусок кода, копирую, меняю там минимум , чтоб соответвовало моему заданию, вуаля, все готово.
Понятно, что какой то минимум придется выучить.
Я имею ввиду следующее:
например мне надо описать стандартные для игр действия - человек бежит, стреляет.
Я беру кусок кода, копирую, меняю там минимум , чтоб соответвовало моему заданию, вуаля, все готово.
Понятно, что какой то минимум придется выучить.
>>873235 (OP)
Сап, я ни в движках, ни в ЯП не шарю, но слышал про godot, смогу ли я опираясь на хульен уроков/курсов по godot'у понять как сделать простенькую игору в стиле платформера например?
Сап, я ни в движках, ни в ЯП не шарю, но слышал про godot, смогу ли я опираясь на хульен уроков/курсов по godot'у понять как сделать простенькую игору в стиле платформера например?
>>873235 (OP)
Сделайте мне плз несложный проектик на годоте за деньги.
Суть токова: нужно бросать два игральных кубика на бесконечную плоскость и выводить на экране количество очков.
Модель кубика есть максовская.
Игровой процесс:
1. Игрок нажимает ролл.
2. Он нажимает ролл, кубики падают сверху на бесконечную плоскость
- Краёв плоскости не должно быть видно.
- Кубики не должны укатываться за пределы камеры (можно например сделать невидимые стены, но главное чтобы кубики не вставали ребром у стены), или любой другой способ избежать укатывания.
- Изначально кубики должны быть в рандомном положении по осям + надо им придать какое-то ускорение (чтобы не падали просто плашмя без перекатов, и вообещ чтобы походило на рандом). Процесс должен быть похож на ирл (т.е. в игре д.б. нормальная гравитация)
3. Кубики упали, стабилизировались и на экране показывается оверлей с количеством выпавших очков и их суммой. Игрок может рерольнуть, goto 1.
Вроде как несложно для тех, кто открывал годот пару десятков раз.
Пишите в телегу lubitelivodki
Сделайте мне плз несложный проектик на годоте за деньги.
Суть токова: нужно бросать два игральных кубика на бесконечную плоскость и выводить на экране количество очков.
Модель кубика есть максовская.
Игровой процесс:
1. Игрок нажимает ролл.
2. Он нажимает ролл, кубики падают сверху на бесконечную плоскость
- Краёв плоскости не должно быть видно.
- Кубики не должны укатываться за пределы камеры (можно например сделать невидимые стены, но главное чтобы кубики не вставали ребром у стены), или любой другой способ избежать укатывания.
- Изначально кубики должны быть в рандомном положении по осям + надо им придать какое-то ускорение (чтобы не падали просто плашмя без перекатов, и вообещ чтобы походило на рандом). Процесс должен быть похож на ирл (т.е. в игре д.б. нормальная гравитация)
3. Кубики упали, стабилизировались и на экране показывается оверлей с количеством выпавших очков и их суммой. Игрок может рерольнуть, goto 1.
Вроде как несложно для тех, кто открывал годот пару десятков раз.
Пишите в телегу lubitelivodki
>>895879
Чел, даже в оф.доке есть дока как делать платформер.
Чел, даже в оф.доке есть дока как делать платформер.
Постить в старый тред - классика.
50 Кб, 1143x663Друзья, не знаете как фиксится? 3.5.2. скачанная с сайта нормально отображается, а стимовская 4 ушла в разнос чет
Аноны, а Godot подходит для 3D-игр? А то тут недавно на пикабу пост читал, там говорилось, что больше 2D-игры. Если надо 3D, то лучше брать другой движок - это правда?
И реально на Godot запилить что-то типо Roblox, SecondLife? Чтобы можно было онлайн бегать кучей народу.
И реально на Godot запилить что-то типо Roblox, SecondLife? Чтобы можно было онлайн бегать кучей народу.
Как можно реализовать настраиваемое управление?
Я пока что придумал сделать ноду которая забирает весь инпут и посылает сигналы в игру.
Нажимаешь кнопку, эта нода смотрит на какое действие ты забиндил эту кнопку - например, нажимаешь W - идет сигнал ноде игрока чтобы подвинулась на вперед немного.
Как идея?
Я пока что придумал сделать ноду которая забирает весь инпут и посылает сигналы в игру.
Нажимаешь кнопку, эта нода смотрит на какое действие ты забиндил эту кнопку - например, нажимаешь W - идет сигнал ноде игрока чтобы подвинулась на вперед немного.
Как идея?
Аноны подскажите пж, хочу сделать редактор уровней супер марио брос, но оказалось что я слишком тупой даже для этого.
Базовая концепция следующая:
1. Пользователь выбирает тайл
2. Пользователь ставит тайл на поле
3. Пользователь нажимает кноку сохранить
4. Тайлмапа конвертится в json (или сразу создается параллельный словарь который после сохраняется как json)
5. При загрузке просто расставляем обжекты по json'у
Тут все логично лаконично и понятно, но вопрос у меня больше по технической составляющей визуала.
Мне очевидно требуется сетка, начало отсчета координат и границы. В этом плане я выбрал пока примерно позицию нулевая позиция х:0 y: 300 16. Пределы соответствующие, слева сверху нули, снизу и справа 300 16. Интро к вопросу долгое но похуй.
То что меня волнует сейчас больше всего - как рисовать сетку? Мне нужна сетка что бы юзер не терялся очевидно. Как то разделять тайлы и прочее. Возможно даже как в оригинальном редакторе godot'a когда рисуешь что-то тайлами там такая небольшая обводка в виде сетки. У меня конечно последние недели времени много времени подумать над этим небыло, но я либо тупой либо задача реально нестандартная.
Какие есть советы?
Базовая концепция следующая:
1. Пользователь выбирает тайл
2. Пользователь ставит тайл на поле
3. Пользователь нажимает кноку сохранить
4. Тайлмапа конвертится в json (или сразу создается параллельный словарь который после сохраняется как json)
5. При загрузке просто расставляем обжекты по json'у
Тут все логично лаконично и понятно, но вопрос у меня больше по технической составляющей визуала.
Мне очевидно требуется сетка, начало отсчета координат и границы. В этом плане я выбрал пока примерно позицию нулевая позиция х:0 y: 300 16. Пределы соответствующие, слева сверху нули, снизу и справа 300 16. Интро к вопросу долгое но похуй.
То что меня волнует сейчас больше всего - как рисовать сетку? Мне нужна сетка что бы юзер не терялся очевидно. Как то разделять тайлы и прочее. Возможно даже как в оригинальном редакторе godot'a когда рисуешь что-то тайлами там такая небольшая обводка в виде сетки. У меня конечно последние недели времени много времени подумать над этим небыло, но я либо тупой либо задача реально нестандартная.
Какие есть советы?