1,5 Мб, 1920x1080Добро пожаловать в тред любви, взаимопомощи и рандомных подвисаний!
Итак, релизнулась четвёрка. Все рады, и я немножко.
Краткий гайд по вкату в движок:
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 в папку и импортируется.
• Туториал по шейдерам: 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
Предыдущий: >>852131 (OP)
Архивный: >>841833 (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 в папку и импортируется.
• Туториал по шейдерам: 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
Предыдущий: >>852131 (OP)
Архивный: >>841833 (OP)
99%примеров сети одинаковые и низкоуровневые,которые не помогают вам в росте знаний
8,2 Мб, 1800x2492>>67757
Традиции чтим! Вот тебе награда:
Традиции чтим! Вот тебе награда:
>>67760
Давай я тебя научу на высоком уровне прямо ИТТ. Хошь? Спрашивай.
Давай я тебя научу на высоком уровне прямо ИТТ. Хошь? Спрашивай.
Я ещё я не понимаю английский на слух,что ведёт к отсечению огромного пласта знаний.
Итого- тупик
Итого- тупик
>>67760
Мне движок нужен чтобы игры делать, а не росте знаний.
Мне движок нужен чтобы игры делать, а не росте знаний.
>>67768
... однако, чтобы понимать робота-переводчика, нужно в общих чертах понимать, что говорят на инглише. Потому что например, вместо
можно услышать
и кринжануть.
... однако, чтобы понимать робота-переводчика, нужно в общих чертах понимать, что говорят на инглише. Потому что например, вместо
> это зависит от того какие значения вы передаёте в состояние
можно услышать
> это зависит от того какие ценности вы передаёте в государство
и кринжануть.
>>67751 (OP)
Аноны, помогите, пожалуйста. Я разобрался, как сделать поиск путей с помощью Astar по клеткам. Для игры с передвижением по клеткам это пойдет, но как сделать пусть с попиксельным передвижением? Например у меня есть игрок, который ходит попиксельно и мне нужно, чтоб враг мог подойти к нему на расстояние удара. Может есть какой гайд?
Аноны, помогите, пожалуйста. Я разобрался, как сделать поиск путей с помощью Astar по клеткам. Для игры с передвижением по клеткам это пойдет, но как сделать пусть с попиксельным передвижением? Например у меня есть игрок, который ходит попиксельно и мне нужно, чтоб враг мог подойти к нему на расстояние удара. Может есть какой гайд?
>>67760
Эти примеры такие потому что человеку, который делает нужно БЫСТРО узнать как делать что-то конкретное, из таких мелочей собираются общие знания.
Все крутые курсы это набор коротких видео, каждое про какую-то свою конкретную тему.
Разглагольствования на час+ херня
Эти примеры такие потому что человеку, который делает нужно БЫСТРО узнать как делать что-то конкретное, из таких мелочей собираются общие знания.
Все крутые курсы это набор коротких видео, каждое про какую-то свою конкретную тему.
Разглагольствования на час+ херня
>>67765
Просто смотришь на английском и всё, какие-то слова смотришь в словаре, потом втянешься, больше интуиции доверяй, точно перевод не поймёшь конкретного слова, но общий посыл легко
Просто смотришь на английском и всё, какие-то слова смотришь в словаре, потом втянешься, больше интуиции доверяй, точно перевод не поймёшь конкретного слова, но общий посыл легко
>>67810
https://docs.godotengine.org/en/stable/tutorials/math/interpolation.html
Скорее всего не то, но вдруг наведёт на мысли
> с попиксельным передвижением
> lerp
https://docs.godotengine.org/en/stable/tutorials/math/interpolation.html
Скорее всего не то, но вдруг наведёт на мысли
Gotot 4 !!!
>>67822
Это не то, что мне нужно. Мне бы именно поиск пути, а не реализацию самого движения. Потому что если использовать Astar на сетке, то противника косоёбит и он стремится пойти на координаты начала точки и не может остановиться там, где надо, а только в центре клетки. У меня было две идеи:
1) Сделать размер клетки равным размеру дистанции атаки, но тогда придется для каждого противника делать свою. Мне кажется, это не очень правильно
2) Сделать передвижение по клеточкам размером 1 пиксель, но тоже звучит как-то не правильно.
Это не то, что мне нужно. Мне бы именно поиск пути, а не реализацию самого движения. Потому что если использовать Astar на сетке, то противника косоёбит и он стремится пойти на координаты начала точки и не может остановиться там, где надо, а только в центре клетки. У меня было две идеи:
1) Сделать размер клетки равным размеру дистанции атаки, но тогда придется для каждого противника делать свою. Мне кажется, это не очень правильно
2) Сделать передвижение по клеточкам размером 1 пиксель, но тоже звучит как-то не правильно.
>>67837
Сегодня смотрел про динамические Quad Tree, как вариант, а перемещение вообще делать с дельтой и float, касаемо поиска пути я поискал и оно таки существует
https://www.youtube.com/watch?v=95aHGzzNCY8
https://www.youtube.com/watch?v=eqwVGOChHcA
Сегодня смотрел про динамические Quad Tree, как вариант, а перемещение вообще делать с дельтой и float, касаемо поиска пути я поискал и оно таки существует
https://www.youtube.com/watch?v=95aHGzzNCY8
https://www.youtube.com/watch?v=eqwVGOChHcA
>>67839
Спасибо, погуглю про это, выглядит, вроде, правильно на видео.
Хотя может кто ещё варианты напишет.
А то во всех туториалах либо пошаговая игра, либо враги прут в тупую без обхода препятствий.
> Quad Tree
Спасибо, погуглю про это, выглядит, вроде, правильно на видео.
Хотя может кто ещё варианты напишет.
А то во всех туториалах либо пошаговая игра, либо враги прут в тупую без обхода препятствий.
1,7 Мб, 2480x3508С выходом новой версии, аноны!
>>67845
Емнип это называется Steering. То есть навигация рассчитывает путь, вектор к следующей клетке, а уже логика бота ведет его туда, например физическим move and slide, или как угодно, хоть внутри клетки рассчитывай навигацию с размером клетки=1пикс, хоть анимациями, хоть position.x += 1, чем угодно.
Емнип это называется Steering. То есть навигация рассчитывает путь, вектор к следующей клетке, а уже логика бота ведет его туда, например физическим move and slide, или как угодно, хоть внутри клетки рассчитывай навигацию с размером клетки=1пикс, хоть анимациями, хоть position.x += 1, чем угодно.
>>67872
Я понимаю, как двигать бота плавно из клетки в клетку. У меня вопрос в другом, как заставить моба двигаться с текущего положения, которое опредеденно не является центром клетки, чтоб он не бежал сломя голову в центр клетки и как сделать так, чтоб он останавливался не в центре клетки, а за опредеденное расстояние от конечной точки(игрока)
Я понимаю, как двигать бота плавно из клетки в клетку. У меня вопрос в другом, как заставить моба двигаться с текущего положения, которое опредеденно не является центром клетки, чтоб он не бежал сломя голову в центр клетки и как сделать так, чтоб он останавливался не в центре клетки, а за опредеденное расстояние от конечной точки(игрока)
>>67876
Ну а куда он по твоему должен бежать, если у него навигация проложена через центр клетки? Ну тогда прокладывай ее не через центры клеток. Или пусть бежит к следующей клетке.
>чтоб он не бежал сломя голову в центр клетки
Ну а куда он по твоему должен бежать, если у него навигация проложена через центр клетки? Ну тогда прокладывай ее не через центры клеток. Или пусть бежит к следующей клетке.
>Чтоб он останавливался не в центре клетки, а за опредеденное расстояние от конечной точки(игрока)
>например физическим move and slide,
>хоть внутри клетки рассчитывай навигацию с размером клетки=1пикс,
>хоть анимациями
>хоть position.x += 1
>>67876
Обычно в 2д игре область для вычислений столкновений это круг, далее с учётом радиуса круга ты перемещаешь объект ровно до точка_завершения_движения минус радиус объекта, если таких объекта два, до точка_завершения_движения минус радиус_врага + радиус_текущего_игрока-объекта
Обычно в 2д игре область для вычислений столкновений это круг, далее с учётом радиуса круга ты перемещаешь объект ровно до точка_завершения_движения минус радиус объекта, если таких объекта два, до точка_завершения_движения минус радиус_врага + радиус_текущего_игрока-объекта
>>67920
тогда уж сразу 4.5.1 LTS
тогда уж сразу 4.5.1 LTS
основные фичи новой версии
https://www.opennet.ru/opennews/art.shtml?num=58730
https://www.opennet.ru/opennews/art.shtml?num=58730
Разные фреймы- разная "форма" тела. Правильно понимаю, что есть два варианта:
1) Делать один коллижн шейп под все движения. Слегка менять его размер и положение в зависимости от фрейма
2) Рисовать коллижн полигоны для каждого фрейма.
И лучше использовать первый?
1) Делать один коллижн шейп под все движения. Слегка менять его размер и положение в зависимости от фрейма
2) Рисовать коллижн полигоны для каждого фрейма.
И лучше использовать первый?
>>67974
Буллет убрали. Даже не знаю, плюс это или минус? Но буллета больше нет.
>>68026
Самый распространённый вариант - сделать квадрат, внутри которого все положения тела персонажа и не париться. Если тебе нужно, чтобы между ручками и ножками персонажа не было коллизии, то делай скелет, на джойнтах соединяющий несколько отдельных тел-костей в единое тело. Менять и двигать коллиженшейп не рекомендовал сам Хуан (не помню почему) - так делать нельзя. Табу! Банан!
Буллет убрали. Даже не знаю, плюс это или минус? Но буллета больше нет.
>>68026
Самый распространённый вариант - сделать квадрат, внутри которого все положения тела персонажа и не париться. Если тебе нужно, чтобы между ручками и ножками персонажа не было коллизии, то делай скелет, на джойнтах соединяющий несколько отдельных тел-костей в единое тело. Менять и двигать коллиженшейп не рекомендовал сам Хуан (не помню почему) - так делать нельзя. Табу! Банан!
>>68033
Надо потестить, может быть уже пофиксиле это. Проблема емнип была в том, что если ты двигаешь коллайдер, то это проходит в обход физического движка, и он либо не замечает этого, либо какой то оверхед на сброс состояния мира и пересчет. Но сейчас же много всяких улучшателей добавили, те же анимированные статикбоди платформы, значит есть механизмы, позволяющие анимировать коллайдеры.
>Менять и двигать коллиженшейп не рекомендовал
Надо потестить, может быть уже пофиксиле это. Проблема емнип была в том, что если ты двигаешь коллайдер, то это проходит в обход физического движка, и он либо не замечает этого, либо какой то оверхед на сброс состояния мира и пересчет. Но сейчас же много всяких улучшателей добавили, те же анимированные статикбоди платформы, значит есть механизмы, позволяющие анимировать коллайдеры.
25 Кб, 443x369>>68042
Всё надо пробовать самому, пробуй. Отпишись о результатах. Ну, всё, я убегаю. У меня тут ТАС-спидран марио на созвоне. Обнял.
Всё надо пробовать самому, пробуй. Отпишись о результатах. Ну, всё, я убегаю. У меня тут ТАС-спидран марио на созвоне. Обнял.
>>68060
Ну, это же распространенная вещь. Каждая вторая игра экшен, мне казалось должен быть урок на тему поиска пути в таких играх, ведь он нужен везде.
Ну, это же распространенная вещь. Каждая вторая игра экшен, мне казалось должен быть урок на тему поиска пути в таких играх, ведь он нужен везде.
1 Кб, 250x340>>68076
Синий враг, красный игрок. Зеленый путь, по которому враг идет, а желтый, как хочется, чтоб он шел. Чтоб как в других играх.
Синий враг, красный игрок. Зеленый путь, по которому враг идет, а желтый, как хочется, чтоб он шел. Чтоб как в других играх.
>>68084
Вариант 1 - искать путь по пиксельной сетке.
Вариант 2 - искать путь со следующей клетки (той, что ближе к врагу)
Вариант 3 - если враг внутри радиуса обнаружения, отключить навигацию и бежать по прямой.
Вариант 1 - искать путь по пиксельной сетке.
Вариант 2 - искать путь со следующей клетки (той, что ближе к врагу)
Вариант 3 - если враг внутри радиуса обнаружения, отключить навигацию и бежать по прямой.
>>68095
Вариант 1 - а не будет это сильно плохо для производительности?
Вариант 3 - а тут не вариант. Он так препятствия обходить не будет
Вариант 1 - а не будет это сильно плохо для производительности?
Вариант 3 - а тут не вариант. Он так препятствия обходить не будет
17 Кб, 147x200>>68086
На показанной пикче твоему боту следует пересчитать навигацию заново. Потому что у него одна точка дальше, чем игрок. Когда он пересчитает навигацию, эта точка естественным образом исчезнет.
Кроме того, на расстоянии атаки проще вовсе отключить навигацию и юзая lerp приблизаться к игроку на расстояние атаки, и уклоняться, и ваще.
На показанной пикче твоему боту следует пересчитать навигацию заново. Потому что у него одна точка дальше, чем игрок. Когда он пересчитает навигацию, эта точка естественным образом исчезнет.
Кроме того, на расстоянии атаки проще вовсе отключить навигацию и юзая lerp приблизаться к игроку на расстояние атаки, и уклоняться, и ваще.
>>68101
У меня описание было, как пример того, как он ходит и как надо. Обход препятствий тоже нужен.
>>68104
Просто эта точка сама близкая к нему по сетке, вот он так и считает похоже
Вообще, перефразирую вопрос, если кто делал Top Down shooter, Action RPG или что-то такое, как вы вообще делали передвижение врага и поиск его пути?
У меня описание было, как пример того, как он ходит и как надо. Обход препятствий тоже нужен.
>>68104
Просто эта точка сама близкая к нему по сетке, вот он так и считает похоже
Вообще, перефразирую вопрос, если кто делал Top Down shooter, Action RPG или что-то такое, как вы вообще делали передвижение врага и поиск его пути?
>>67751 (OP)
т.е. делая игру условные Homm3, чтобы человек добавил своего юнита в виде текстового файлика и картинки с ним, мододелу потребуется какой-то редактор непонятный ему использовать?
> невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново
т.е. делая игру условные Homm3, чтобы человек добавил своего юнита в виде текстового файлика и картинки с ним, мододелу потребуется какой-то редактор непонятный ему использовать?
15 Кб, 147x200>>68105
Так ты подумай какой ответ на вопрос.
Черная клетка - препятствие. Навигация проложила маршрут по зеленой. А ты хочешь чтобы шел по желтой, через препятствие. Как ты разрешишь это противоречие?
Так ты подумай какой ответ на вопрос.
Черная клетка - препятствие. Навигация проложила маршрут по зеленой. А ты хочешь чтобы шел по желтой, через препятствие. Как ты разрешишь это противоречие?
>>68105
Я тебе ещё раз русским по белому пишу: бот должен пересчитать маршрут. Ты понимаешь это?
Пересчётом маршрута, после того как вражеский юнит переместился.
> вот он так и считает похоже
Я тебе ещё раз русским по белому пишу: бот должен пересчитать маршрут. Ты понимаешь это?
> как вы вообще делали передвижение врага и поиск его пути?
Пересчётом маршрута, после того как вражеский юнит переместился.
>>68106
Как сделаешь так и будет. Хоть внутриигровой редактор ему сделай, хоть текстовые файлы и картинки загружай.
Штатный режим - при сборке годот упаковывает и оптимизирует текстуры. Но никто не мешает загружать картинки с любого файла на диске кодом.
Как сделаешь так и будет. Хоть внутриигровой редактор ему сделай, хоть текстовые файлы и картинки загружай.
Штатный режим - при сборке годот упаковывает и оптимизирует текстуры. Но никто не мешает загружать картинки с любого файла на диске кодом.
>>68106
Начал катать простыню, а анон выше уже ответил. Если ты, как разраб, предусмотрел возможность создания текстур из внешних пикч, то да, всё будет работать. Если не предусмотрел, то не работать будет только то, о чем описано в том разделе шапки, то есть, запуск распакованного проекта через шаблон экспорта. Созданием текстур и складыванием их в отдельную папочку, занимается редактор, которого в шаблоне экспорта нет.
Начал катать простыню, а анон выше уже ответил. Если ты, как разраб, предусмотрел возможность создания текстур из внешних пикч, то да, всё будет работать. Если не предусмотрел, то не работать будет только то, о чем описано в том разделе шапки, то есть, запуск распакованного проекта через шаблон экспорта. Созданием текстур и складыванием их в отдельную папочку, занимается редактор, которого в шаблоне экспорта нет.
2 Кб, 250x340>>68114
Может быть ты считаешь не от туда? Ну например у тебя спрайт сдвинут относительно клетки?
Может быть ты считаешь не от туда? Ну например у тебя спрайт сдвинут относительно клетки?
>>68118
Так я ему говорю и он так же строит.
>>68119
Так в этом и дело, что мне надо чтоб он с любой точки клетки мог двигаться в любую. А он двигается четко по центрам клетки. Я понимаю, что о не знает, как по другому, но как ему объяснить то, как надо? Может нужно не Astar использовать, а что другое? У меня опыта просто 0 и смотрел уроки и понимал как делать, а на этом застрял
Так я ему говорю и он так же строит.
>>68119
Так в этом и дело, что мне надо чтоб он с любой точки клетки мог двигаться в любую. А он двигается четко по центрам клетки. Я понимаю, что о не знает, как по другому, но как ему объяснить то, как надо? Может нужно не Astar использовать, а что другое? У меня опыта просто 0 и смотрел уроки и понимал как делать, а на этом застрял
>>68114
Если у акторов будет коллайдер сфера, а у препятствия квадрат, то физический move and slide должен работать.
>>68122
Потому что у тебя навигация по клеткам, а не из любой точки в любую. Попробуй либо по пикселям, или если как говоришь это тормозит, то по клеткам, но когда видит близко врага - переключаться на по пикселям.
Пойду что ли бенчмарк писать.
Если у акторов будет коллайдер сфера, а у препятствия квадрат, то физический move and slide должен работать.
>>68122
>Так в этом и дело, что мне надо чтоб он с любой точки клетки мог двигаться в любую. А он двигается четко по центрам клетки
Потому что у тебя навигация по клеткам, а не из любой точки в любую. Попробуй либо по пикселям, или если как говоришь это тормозит, то по клеткам, но когда видит близко врага - переключаться на по пикселям.
Пойду что ли бенчмарк писать.
>>68114
Анон имеет в виду, что путь надо пересчитывать с какой то периодичностью. Можно не каждый кадр, а раза 4 в секунду.
>Он так считает. Как ему сказать пересчитать по другому?
Анон имеет в виду, что путь надо пересчитывать с какой то периодичностью. Можно не каждый кадр, а раза 4 в секунду.
>>68125
Видимо, так и придется. Надеюсь это реально правильный способ, как оно и должно выглядеть, а не просто мой тупняк
>>68127
Но он и так пересчитывает и всё равно его тянет назад, если он не в центре клекти.
>Попробуй либо по пикселям, или если как говоришь это тормозит, то по клеткам, но когда видит близко врага - переключаться на по пикселям.
Видимо, так и придется. Надеюсь это реально правильный способ, как оно и должно выглядеть, а не просто мой тупняк
>>68127
Но он и так пересчитывает и всё равно его тянет назад, если он не в центре клекти.
>>68122
Ну ладно. Показывай код. Что ты там нахуевертил. Версия движка какая?
> Так я ему говорю и он так же строит.
Ну ладно. Показывай код. Что ты там нахуевертил. Версия движка какая?
>>68133
Конкретно я делал по этой статье, но смотрел и другие. Там всё похоже и одинаково в итоге работает. От себя добавил только перепоиск пути. Просто заново стартует путь по истечению таймера
https://escada-games.itch.io/randungeon/devlog/261991/how-to-use-godots-astar2d-for-path-finding
Версия 3.5
Конкретно я делал по этой статье, но смотрел и другие. Там всё похоже и одинаково в итоге работает. От себя добавил только перепоиск пути. Просто заново стартует путь по истечению таймера
https://escada-games.itch.io/randungeon/devlog/261991/how-to-use-godots-astar2d-for-path-finding
Версия 3.5
2 Кб, 158x162>>68136
Он ходит сквозь стены, очевидно это подходит только пошаговым играм не очень требовательным к срезанию углов.
Он ходит сквозь стены, очевидно это подходит только пошаговым играм не очень требовательным к срезанию углов.
12 Кб, 826x510>>67810
Делай как на пикриле и получишь поведение из 99% топ-даун игр, главное не забудь сделать героев на основе кинематикбоди с коллайдером-кружочком радиусом меньше одной клетки, чтобы они углы плавно обходили.
Алгоритм такой:
1. Если игрок вне радиуса агрессии моба, моб мирно занимается своими делами (обычно патрулирует местность или просто бесцельно бродит).
2. Если игрок попал в радиус агрессии и привлёк к себе внимание моба (ну там стелс и всё такое, в документации есть пример на простую проверку поля зрения через Vector2.dot()), то моб переходит в режим преследования, у которого две стадии:
2.1. Если игрок прячется за препятствиями, которые моб проверяет простым рейкастом, то моб запрашивает у навигационной системы (в данном случае а-стар) оптимальный маршрут и топает по клеточкам.
2.2. Периодически он проверяет, не показался ли игрок на прямой линии рейкаста, и если показался, то переходит во второй режим - тупое движение по прямой, которое позволяет автоматически обойти все углы благодаря скольжению вокруг этих углов. Если игрок снова скрылся за углом, моб запрашивает новый маршрут и переходит в первый режим следования клеткам.
3. Если необходимо, чтобы моб умно скрывался за препятствиями, отступал и т.д., рейкасты нужно кидать уже не от моба, а от игрока, чтобы моб, видящий игрока, смог найти место на карте, которое игрок не видит, и спрятался за него. Но это уже следующий уровень сложности.
Делай как на пикриле и получишь поведение из 99% топ-даун игр, главное не забудь сделать героев на основе кинематикбоди с коллайдером-кружочком радиусом меньше одной клетки, чтобы они углы плавно обходили.
Алгоритм такой:
1. Если игрок вне радиуса агрессии моба, моб мирно занимается своими делами (обычно патрулирует местность или просто бесцельно бродит).
2. Если игрок попал в радиус агрессии и привлёк к себе внимание моба (ну там стелс и всё такое, в документации есть пример на простую проверку поля зрения через Vector2.dot()), то моб переходит в режим преследования, у которого две стадии:
2.1. Если игрок прячется за препятствиями, которые моб проверяет простым рейкастом, то моб запрашивает у навигационной системы (в данном случае а-стар) оптимальный маршрут и топает по клеточкам.
2.2. Периодически он проверяет, не показался ли игрок на прямой линии рейкаста, и если показался, то переходит во второй режим - тупое движение по прямой, которое позволяет автоматически обойти все углы благодаря скольжению вокруг этих углов. Если игрок снова скрылся за углом, моб запрашивает новый маршрут и переходит в первый режим следования клеткам.
3. Если необходимо, чтобы моб умно скрывался за препятствиями, отступал и т.д., рейкасты нужно кидать уже не от моба, а от игрока, чтобы моб, видящий игрока, смог найти место на карте, которое игрок не видит, и спрятался за него. Но это уже следующий уровень сложности.
>>68140
Включи отображение коллайдеров, у тебя какая-то проблема с коллайдерами, если персонаж входит в стены, вместо того, чтобы обходить их.
>Он ходит сквозь стены
Включи отображение коллайдеров, у тебя какая-то проблема с коллайдерами, если персонаж входит в стены, вместо того, чтобы обходить их.
>>68148
Ты не понял, там туториал так и сделан. Это пошаговая игра, там можно пойти по диагонали между клетками, а движения наверное просто анимацией сделаны для красоты. Ну как в настольной игре.
Ты не понял, там туториал так и сделан. Это пошаговая игра, там можно пойти по диагонали между клетками, а движения наверное просто анимацией сделаны для красоты. Ну как в настольной игре.
>>68144
Да как? Объясните, как сделать лерпом с обходом препятствий?
>>68143
Выглядит правдоподобно. Только интересно, как будет выглядить скольжение, не слишком ли уродливо и нелепо.
Вообще, тут на доске ещё есть The Excrawlers, в котором всё это выглядит хорошо. Этим можно добиться такого же хорошего эффекта?
Да как? Объясните, как сделать лерпом с обходом препятствий?
>>68143
Выглядит правдоподобно. Только интересно, как будет выглядить скольжение, не слишком ли уродливо и нелепо.
Вообще, тут на доске ещё есть The Excrawlers, в котором всё это выглядит хорошо. Этим можно добиться такого же хорошего эффекта?
>>68149
А, понятно, я думал, это твоя игра.
Для топ-даун экшена делай так: >>68143
Движение мобов за препятствиями пусть будет по клеткам, они ведь всё равно в коридорах, а коридоры у тебя наверняка тайловые, а не рандомные кишки в стиле Worms. Если у тебя кишки в стиле Worms, тогда тебе вообще не сетка клеток нужна, а точки по середине сегментов кишок, тут уже зависит от того, как ты делаешь карту (вручную или процедурно).
>туториал так и сделан
А, понятно, я думал, это твоя игра.
Для топ-даун экшена делай так: >>68143
Движение мобов за препятствиями пусть будет по клеткам, они ведь всё равно в коридорах, а коридоры у тебя наверняка тайловые, а не рандомные кишки в стиле Worms. Если у тебя кишки в стиле Worms, тогда тебе вообще не сетка клеток нужна, а точки по середине сегментов кишок, тут уже зависит от того, как ты делаешь карту (вручную или процедурно).
>>68152
Зависит от твоей графики. Графику-то ты не показал. Обычно в топ-даун играх все персонажи - плоские колобки, из которых торчит только ствол пушки.
Не видел, нужно посмотреть.
>не слишком ли уродливо и нелепо
Зависит от твоей графики. Графику-то ты не показал. Обычно в топ-даун играх все персонажи - плоские колобки, из которых торчит только ствол пушки.
>The Excrawlers
Не видел, нужно посмотреть.
647 Кб, 1024x1024>>68156
А, блин, я всю жизнь путаю топ-даун и проекцию "чисто сверху". Для меня "топ-даун шутер" - это проекция чисто сверху про колобков с пушками. Никогда не задумывался, как называется графика в большинстве JRPG, и никогда не считал её топ-дауном, а оно оказывается и есть топ-даун...
>Обычно в топ-даун играх все персонажи - плоские колобки, из которых торчит только ствол пушки.
А, блин, я всю жизнь путаю топ-даун и проекцию "чисто сверху". Для меня "топ-даун шутер" - это проекция чисто сверху про колобков с пушками. Никогда не задумывался, как называется графика в большинстве JRPG, и никогда не считал её топ-дауном, а оно оказывается и есть топ-даун...
13 Кб, 1160x672>>867727 →
У гитхаба сервера всегда так медленно в один поток отдают, поэтому крупные файлы лучше качать через менеджер, поддерживающий многопоточный режим (если сервер поддерживает отдачу частями, то скачивание будет сразу с нескольких точек в файле и суммарная скорость в 10-20 раз быстрее, чем если качать через браузер или примитивный загрузчик). Не понимаю, почему они разрешают скачивание в несколько потоков, если один поток искусственно ограничивают, обычно для снижения нагрузок на раздающий сервер опцию скачивания в несколько потоков отключают.
>>867884 →
Релизы на гитхабе давно уже выкладывают. Старый репозиторий по-прежнему доступен:
https://downloads.tuxfamily.org/godotengine/4.0/
Почему они до сих пор не могут разделить шаблоны экспорта на несколько архивов? Сначала они хвастаются, что у них движок занимает всего 20 30 50 МБ в целом в архиве, а потом они пихают все официальные шаблоны экспорта в один почти гиговый архив. Где логика? А если моя игра в принципе никогда не будет работать в вебе и на мобилках из-за ресурсоёмкости, а мака для тестов у меня всё равно нет? Нет, качай всё сразу. Движок Bullet они выкинули, мол, чтобы лишний вес с движка сбросить, а лишние шаблоны экспорта им не лень раздавать для каждой пре-пре-альфа сборки...
>Чот у них ЦДН видимо напрягся. Все качают.
У гитхаба сервера всегда так медленно в один поток отдают, поэтому крупные файлы лучше качать через менеджер, поддерживающий многопоточный режим (если сервер поддерживает отдачу частями, то скачивание будет сразу с нескольких точек в файле и суммарная скорость в 10-20 раз быстрее, чем если качать через браузер или примитивный загрузчик). Не понимаю, почему они разрешают скачивание в несколько потоков, если один поток искусственно ограничивают, обычно для снижения нагрузок на раздающий сервер опцию скачивания в несколько потоков отключают.
>>867884 →
>Там вроде с гитхаба скачивается теперь
Релизы на гитхабе давно уже выкладывают. Старый репозиторий по-прежнему доступен:
https://downloads.tuxfamily.org/godotengine/4.0/
Почему они до сих пор не могут разделить шаблоны экспорта на несколько архивов? Сначала они хвастаются, что у них движок занимает всего 20 30 50 МБ в целом в архиве, а потом они пихают все официальные шаблоны экспорта в один почти гиговый архив. Где логика? А если моя игра в принципе никогда не будет работать в вебе и на мобилках из-за ресурсоёмкости, а мака для тестов у меня всё равно нет? Нет, качай всё сразу. Движок Bullet они выкинули, мол, чтобы лишний вес с движка сбросить, а лишние шаблоны экспорта им не лень раздавать для каждой пре-пре-альфа сборки...
>>68156
У меня как раз графика похожая на рпг, похоже на The Excrawlers как раз, потому её в пример и привёл. Мне главное, чтоб не выглядело, будто он врезается в стену, а просто идёт вдоль.
У меня как раз графика похожая на рпг, похоже на The Excrawlers как раз, потому её в пример и привёл. Мне главное, чтоб не выглядело, будто он врезается в стену, а просто идёт вдоль.
Не пойму, пишут про новый окклюжн куллинг, но ссылка идет на коммит 2021 года, а я помню, что когда щупал в альфе, там было сыровато, не всегда работало, еще было ограничение на какое-то смешное (8?) окклюдеров, что-то не сходится, так каков статус сейчас?
да, что-то готовые билды существенно пожирнели, для того же андроида с 13-15мб до 20-21мб
11 Кб, 303x139>>68307
Играюсь в годо с нейронками спизженными и столкнулся с проблемой фипсов. На 50-ти активных мозгах жоско рыгает фреймтайм из-за дроча матриц.
Надо переписать класс с матрицами на шарп? И как, если у меня нет его в списках пикрилейтед?
Играюсь в годо с нейронками спизженными и столкнулся с проблемой фипсов. На 50-ти активных мозгах жоско рыгает фреймтайм из-за дроча матриц.
Надо переписать класс с матрицами на шарп? И как, если у меня нет его в списках пикрилейтед?
>>68319
Кочать версию с поддержкой шарпма
Кочать версию с поддержкой шарпма
>>68319
на шарп ничего переписывать с gdscript смысла нет, в них разница только вкусовщина в каком стиле привык кодить, производительность у них примерно одинаковая
для ускорения работы нужно переходить на native script/плюсы
на шарп ничего переписывать с gdscript смысла нет, в них разница только вкусовщина в каком стиле привык кодить, производительность у них примерно одинаковая
для ускорения работы нужно переходить на native script/плюсы
50 Кб, 619x435Теперь при обращении к проперти даже внутри класса будут вызывать сеттеры и геттеры. Даже если в сеттере прочитать значение через имя проперти, будет вызван геттер.
26 Кб, 509x483Похоже добавили новые проекты
57 Кб, 674x381>>68344
Еще теперь в зарезервированных методах не вызывается super по умолчанию.
Да и такой однострочник как в _process в предыдущей версии не работает
Еще теперь в зарезервированных методах не вызывается super по умолчанию.
Да и такой однострочник как в _process в предыдущей версии не работает
>>68338
У меня есть, дай побаловаться.
У меня есть, дай побаловаться.
Анончики, как теперь быть? Если я соберусь делать игру заточенную на хорошую прозводительность на посредственном устройстве (ноутбук со встройкой) - какую версию использовать? 3.5.1 LTS или 4.0? В плане легковестности рулит OpenGL или Vulkan?
>>68404
Возьми и потести, ебана.
В 3 многие жаловались что на встройке было тяжело, 4 хз, если вообще запустится.
Возьми и потести, ебана.
В 3 многие жаловались что на встройке было тяжело, 4 хз, если вообще запустится.
>>68411
Ну демка от gdquest выдает слайдшоу на UHD Graphics 620. Хотя сцены сами по себе примитивные.
Ну демка от gdquest выдает слайдшоу на UHD Graphics 620. Хотя сцены сами по себе примитивные.
>>68404
Начинай с 3.5, потом на новый перекатывайся
Начинай с 3.5, потом на новый перекатывайся
>>68404
Протестируй сам, делов-то - два файла скачать и поиграться немного в демки. На некотором железе даже Godot 3.x вообще не запускается, наверное, из-за кривых драйверов на встроенную карту.
Это зависит от сцены, которую ты хочешь рисовать.
По официальным заявлениям получается так:
1. OpenGL разрабатывался как простое средство отображения типичных графических фигур в те времена, когда о сложном графонии даже не думали. Поэтому он имеет высокоуровневое API, абстрагирующее разраба графики от всех тонкостей работы оборудования, позволяющее автоматически использовать все индивидуальные оптимизации под разное железо. Ты просто инициализируешь API и рисуешь что-то, и оно рисуется как-то там само собой. Это накладывало серьёзные ограничения на возможности, поэтому в новые версии OpenGL добавляли более низкоуровневые функции, но основа всегда оставалась неизменной, и какие-то ограничения обойти так и не удалось, в результате чего сообщество разработчиков OpenGL создало новый стандарт, назвав его Vulkan (glNext изначально, так что это потомок OpenGL). Вот эти ограничения вроде как не позволяют тебе быстро рендерить очень большие сцены и сложные спецэффекты. Т.е. OpenGL оптимален для маленьких, простых сцен, но сильно сдаёт позиции, если ты накидываешь в сцену кучу всего и обмазываешься спецэффектами.
2. Vulkan, как понятно из вышесказанного, разрабатывался с учётом опыта OpenGL, поэтому его сделали максимально низкоуровневым. Условно, если в OpenGL ты можешь нарисовать треугольник за 3 строчки, то в Vulkan для рисования треугольника тебе нужно 300 строчек кода (инициализации всего, что нужно инициализировать). Соответственно, Vulkan даёт больше потенциальных возможностей для больших сцен со сложными спецэффектами, но цена этому - высокая сложность базовых операций, которые в OpenGL делались легко. То есть, по заявлениям разработчиков, на маленькой сцене Vulkan проигрывает OpenGL в скорости, но на большой сцене OpenGL проигрывает Vulkan и в скорости, и в графических возможностях. Поэтому следует ожидать постепенный переход на Vulkan всех крупных игровых проектов, тогда как OpenGL отстанется для поддержки старых программ, особенно когда их невозможно обновить (медицинское ПО и т.п., где графика имеет чисто прикладное значение и свистелки не нужны).
Godot 4.x продолжит поддержку OpenGL 3.3 (GLES3) для совместимости со старыми ПК, мобильными устройствами и вебом, так что причин оставаться на 3.x в твоём случае мало, если только у тебя не очень старое железо. Хотя они вроде говорили, что поддержка OpenGL в новой версии пока неполная из-за того, что переделывали всё с нуля, когда писали рендерер на Vulkan.
>ноутбук со встройкой
Протестируй сам, делов-то - два файла скачать и поиграться немного в демки. На некотором железе даже Godot 3.x вообще не запускается, наверное, из-за кривых драйверов на встроенную карту.
>В плане легковестности рулит OpenGL или Vulkan?
Это зависит от сцены, которую ты хочешь рисовать.
По официальным заявлениям получается так:
1. OpenGL разрабатывался как простое средство отображения типичных графических фигур в те времена, когда о сложном графонии даже не думали. Поэтому он имеет высокоуровневое API, абстрагирующее разраба графики от всех тонкостей работы оборудования, позволяющее автоматически использовать все индивидуальные оптимизации под разное железо. Ты просто инициализируешь API и рисуешь что-то, и оно рисуется как-то там само собой. Это накладывало серьёзные ограничения на возможности, поэтому в новые версии OpenGL добавляли более низкоуровневые функции, но основа всегда оставалась неизменной, и какие-то ограничения обойти так и не удалось, в результате чего сообщество разработчиков OpenGL создало новый стандарт, назвав его Vulkan (glNext изначально, так что это потомок OpenGL). Вот эти ограничения вроде как не позволяют тебе быстро рендерить очень большие сцены и сложные спецэффекты. Т.е. OpenGL оптимален для маленьких, простых сцен, но сильно сдаёт позиции, если ты накидываешь в сцену кучу всего и обмазываешься спецэффектами.
2. Vulkan, как понятно из вышесказанного, разрабатывался с учётом опыта OpenGL, поэтому его сделали максимально низкоуровневым. Условно, если в OpenGL ты можешь нарисовать треугольник за 3 строчки, то в Vulkan для рисования треугольника тебе нужно 300 строчек кода (инициализации всего, что нужно инициализировать). Соответственно, Vulkan даёт больше потенциальных возможностей для больших сцен со сложными спецэффектами, но цена этому - высокая сложность базовых операций, которые в OpenGL делались легко. То есть, по заявлениям разработчиков, на маленькой сцене Vulkan проигрывает OpenGL в скорости, но на большой сцене OpenGL проигрывает Vulkan и в скорости, и в графических возможностях. Поэтому следует ожидать постепенный переход на Vulkan всех крупных игровых проектов, тогда как OpenGL отстанется для поддержки старых программ, особенно когда их невозможно обновить (медицинское ПО и т.п., где графика имеет чисто прикладное значение и свистелки не нужны).
Godot 4.x продолжит поддержку OpenGL 3.3 (GLES3) для совместимости со старыми ПК, мобильными устройствами и вебом, так что причин оставаться на 3.x в твоём случае мало, если только у тебя не очень старое железо. Хотя они вроде говорили, что поддержка OpenGL в новой версии пока неполная из-за того, что переделывали всё с нуля, когда писали рендерер на Vulkan.
>>68404
Протестируй сам, делов-то - два файла скачать и поиграться немного в демки. На некотором железе даже Godot 3.x вообще не запускается, наверное, из-за кривых драйверов на встроенную карту.
Это зависит от сцены, которую ты хочешь рисовать.
По официальным заявлениям получается так:
1. OpenGL разрабатывался как простое средство отображения типичных графических фигур в те времена, когда о сложном графонии даже не думали. Поэтому он имеет высокоуровневое API, абстрагирующее разраба графики от всех тонкостей работы оборудования, позволяющее автоматически использовать все индивидуальные оптимизации под разное железо. Ты просто инициализируешь API и рисуешь что-то, и оно рисуется как-то там само собой. Это накладывало серьёзные ограничения на возможности, поэтому в новые версии OpenGL добавляли более низкоуровневые функции, но основа всегда оставалась неизменной, и какие-то ограничения обойти так и не удалось, в результате чего сообщество разработчиков OpenGL создало новый стандарт, назвав его Vulkan (glNext изначально, так что это потомок OpenGL). Вот эти ограничения вроде как не позволяют тебе быстро рендерить очень большие сцены и сложные спецэффекты. Т.е. OpenGL оптимален для маленьких, простых сцен, но сильно сдаёт позиции, если ты накидываешь в сцену кучу всего и обмазываешься спецэффектами.
2. Vulkan, как понятно из вышесказанного, разрабатывался с учётом опыта OpenGL, поэтому его сделали максимально низкоуровневым. Условно, если в OpenGL ты можешь нарисовать треугольник за 3 строчки, то в Vulkan для рисования треугольника тебе нужно 300 строчек кода (инициализации всего, что нужно инициализировать). Соответственно, Vulkan даёт больше потенциальных возможностей для больших сцен со сложными спецэффектами, но цена этому - высокая сложность базовых операций, которые в OpenGL делались легко. То есть, по заявлениям разработчиков, на маленькой сцене Vulkan проигрывает OpenGL в скорости, но на большой сцене OpenGL проигрывает Vulkan и в скорости, и в графических возможностях. Поэтому следует ожидать постепенный переход на Vulkan всех крупных игровых проектов, тогда как OpenGL отстанется для поддержки старых программ, особенно когда их невозможно обновить (медицинское ПО и т.п., где графика имеет чисто прикладное значение и свистелки не нужны).
Godot 4.x продолжит поддержку OpenGL 3.3 (GLES3) для совместимости со старыми ПК, мобильными устройствами и вебом, так что причин оставаться на 3.x в твоём случае мало, если только у тебя не очень старое железо. Хотя они вроде говорили, что поддержка OpenGL в новой версии пока неполная из-за того, что переделывали всё с нуля, когда писали рендерер на Vulkan.
>ноутбук со встройкой
Протестируй сам, делов-то - два файла скачать и поиграться немного в демки. На некотором железе даже Godot 3.x вообще не запускается, наверное, из-за кривых драйверов на встроенную карту.
>В плане легковестности рулит OpenGL или Vulkan?
Это зависит от сцены, которую ты хочешь рисовать.
По официальным заявлениям получается так:
1. OpenGL разрабатывался как простое средство отображения типичных графических фигур в те времена, когда о сложном графонии даже не думали. Поэтому он имеет высокоуровневое API, абстрагирующее разраба графики от всех тонкостей работы оборудования, позволяющее автоматически использовать все индивидуальные оптимизации под разное железо. Ты просто инициализируешь API и рисуешь что-то, и оно рисуется как-то там само собой. Это накладывало серьёзные ограничения на возможности, поэтому в новые версии OpenGL добавляли более низкоуровневые функции, но основа всегда оставалась неизменной, и какие-то ограничения обойти так и не удалось, в результате чего сообщество разработчиков OpenGL создало новый стандарт, назвав его Vulkan (glNext изначально, так что это потомок OpenGL). Вот эти ограничения вроде как не позволяют тебе быстро рендерить очень большие сцены и сложные спецэффекты. Т.е. OpenGL оптимален для маленьких, простых сцен, но сильно сдаёт позиции, если ты накидываешь в сцену кучу всего и обмазываешься спецэффектами.
2. Vulkan, как понятно из вышесказанного, разрабатывался с учётом опыта OpenGL, поэтому его сделали максимально низкоуровневым. Условно, если в OpenGL ты можешь нарисовать треугольник за 3 строчки, то в Vulkan для рисования треугольника тебе нужно 300 строчек кода (инициализации всего, что нужно инициализировать). Соответственно, Vulkan даёт больше потенциальных возможностей для больших сцен со сложными спецэффектами, но цена этому - высокая сложность базовых операций, которые в OpenGL делались легко. То есть, по заявлениям разработчиков, на маленькой сцене Vulkan проигрывает OpenGL в скорости, но на большой сцене OpenGL проигрывает Vulkan и в скорости, и в графических возможностях. Поэтому следует ожидать постепенный переход на Vulkan всех крупных игровых проектов, тогда как OpenGL отстанется для поддержки старых программ, особенно когда их невозможно обновить (медицинское ПО и т.п., где графика имеет чисто прикладное значение и свистелки не нужны).
Godot 4.x продолжит поддержку OpenGL 3.3 (GLES3) для совместимости со старыми ПК, мобильными устройствами и вебом, так что причин оставаться на 3.x в твоём случае мало, если только у тебя не очень старое железо. Хотя они вроде говорили, что поддержка OpenGL в новой версии пока неполная из-за того, что переделывали всё с нуля, когда писали рендерер на Vulkan.
>>68330
У меня на встройке HD2000 не запускалось ничего пока я не тыкнул галку Fallaback To GLES2.
> На некотором железе даже Godot 3.x вообще не запускается
У меня на встройке HD2000 не запускалось ничего пока я не тыкнул галку Fallaback To GLES2.
9 Кб, 228x141Это правильно или я дэбил?
Мне нужны и чек столкновений и чтобы рейкаст работал, как на пике работает, но приходится тупо копировать коллижн полигон.
Мне нужны и чек столкновений и чтобы рейкаст работал, как на пике работает, но приходится тупо копировать коллижн полигон.
>>68488
Не сталкивается. А мув_анд_коллайд не сталкивается с Ареа2д.
Не сталкивается. А мув_анд_коллайд не сталкивается с Ареа2д.
5 Кб, 287x84>>68494
Так по умолчанию так и есть
Так по умолчанию так и есть
спорить о движках - это кал, надо спорить о механиках, о маркетинговых стратегиях, об удачных решениях и т.д., движки вообще не стоят этого времени
>>68494
Вот тебе серьёзно не лень было наделать скриншотов со стрелочками в пейнте и написать несколько постов, вместо того, чтобы просто внимательно изучить свойства ноды в инспекторе и документацию на API, встроенную в редактор? А потом фантазируют о видеоуроках на каждую ноду, чтобы их носом ткнули в каждое свойство и сказочку на ночь рассказали о том, как это свойство можно использовать.
>>68536
Ты тредом ошибся. О геймдизайне, маркетинге и других решениях, не связанных с конкретным движком, уже давно есть другие треды (или нет, тогда можно создать). Ты хотя бы иногда каталог листай, там не только движкосрачи. А здесь вообще тред конкретного движка, никто о движках в целом не спорит, сидим, ноды в дереве размещаем, на GDScript скриптики пишем...
Вот тебе серьёзно не лень было наделать скриншотов со стрелочками в пейнте и написать несколько постов, вместо того, чтобы просто внимательно изучить свойства ноды в инспекторе и документацию на API, встроенную в редактор? А потом фантазируют о видеоуроках на каждую ноду, чтобы их носом ткнули в каждое свойство и сказочку на ночь рассказали о том, как это свойство можно использовать.
>>68536
Ты тредом ошибся. О геймдизайне, маркетинге и других решениях, не связанных с конкретным движком, уже давно есть другие треды (или нет, тогда можно создать). Ты хотя бы иногда каталог листай, там не только движкосрачи. А здесь вообще тред конкретного движка, никто о движках в целом не спорит, сидим, ноды в дереве размещаем, на GDScript скриптики пишем...
>>68492
А почему у тебя машина не RigidBody2D?
RigidBody2D лучше подходит для быстрой симуляции автомобилей, т.к. автоматически считает все приложенные силы/импульсы и автоматически рассчитывает столкновения с другими RigidBody2D. На основе KinematicBody2D придётся дополнительные велосипеды изобретать.
Эта функция упирает тело в стену и не двигает никуда, даже если твоё препятствие - угол тонкой стены. Для большинства ситуаций выгоднее использовать move_and_slide(), но в твоём случае (2D гонка?) лучше вообще перейти на RigidBody2D.
>Car
>KinematicBody2D
А почему у тебя машина не RigidBody2D?
RigidBody2D лучше подходит для быстрой симуляции автомобилей, т.к. автоматически считает все приложенные силы/импульсы и автоматически рассчитывает столкновения с другими RigidBody2D. На основе KinematicBody2D придётся дополнительные велосипеды изобретать.
>мув_анд_коллайд
Эта функция упирает тело в стену и не двигает никуда, даже если твоё препятствие - угол тонкой стены. Для большинства ситуаций выгоднее использовать move_and_slide(), но в твоём случае (2D гонка?) лучше вообще перейти на RigidBody2D.
>>68573
Чего? Невротизм?
Решается одной галочкой в инспекторе RigidBody2D. Лучше иметь возможность переключить фичу одной галочкой, чем изобретать велосипед.
В смысле feedback? Типа отскоки от стен?
1. Увеличиваешь bounce в параметрах стен.
2. Опционально регулируешь friction там же.
3. Машины отскакивают от стен как мячики.
4. Подстраиваешь параметры под свой вкус.
"Облизывание стен" - это quality of life фича, без неё большинство типов игр очень страдают. Особенно гонки, в которых мгновенная остановка с 200 км/ч от одного случайного касания сраного бордюрчика вызовет бурю негативных эмоций. В большинстве случаев машина должна только слегка изменить курс, а не остановиться так, будто врезалась лбом в гору.
>У меня нейроаутизм
Чего? Невротизм?
>В широком смысле невротизм можно определять как неспособность эффективно регулировать негативные эмоции. Негативные эмоции склонны возникать, когда люди полагают, что они плохо справляются с достижением своих целей.
>не надо чтобы машинки сталкивались
Решается одной галочкой в инспекторе RigidBody2D. Лучше иметь возможность переключить фичу одной галочкой, чем изобретать велосипед.
>при коллайде со стеной фидили, а не облизывали ее
>фидили
В смысле feedback? Типа отскоки от стен?
1. Увеличиваешь bounce в параметрах стен.
2. Опционально регулируешь friction там же.
3. Машины отскакивают от стен как мячики.
4. Подстраиваешь параметры под свой вкус.
"Облизывание стен" - это quality of life фича, без неё большинство типов игр очень страдают. Особенно гонки, в которых мгновенная остановка с 200 км/ч от одного случайного касания сраного бордюрчика вызовет бурю негативных эмоций. В большинстве случаев машина должна только слегка изменить курс, а не остановиться так, будто врезалась лбом в гору.
7,3 Мб, mp4,1280x720, 0:24
>>68578
Невротизм тоже есть.
Фидили всмысле "мгновенно останавливались с 200км/ч от одного случайного касания".
Велосипедов я вроде не изобретал, мне достаточно того что есть, у RigidBody2D сильно больше параметров которые мне не нужны.
Невротизм тоже есть.
Фидили всмысле "мгновенно останавливались с 200км/ч от одного случайного касания".
Велосипедов я вроде не изобретал, мне достаточно того что есть, у RigidBody2D сильно больше параметров которые мне не нужны.
>>68703
Почему это нейронками называют? Это генетические алгоритмы. Может, там внутри и есть граф, внешне напоминающий нейросеть, но он не обучается как нейросеть - вместо обучения в таких симуляциях копируют данные наиболее удачного экземпляра и затем немного меняют их, запуская в симуляцию и снова отслеживая наиболее удачных. От нейронки тут только граф, но чтобы граф был нейронкой, он должен обучаться же, а обучения тут нет - только эволюционный отбор и мутации "генов".
Или, по-твоему, ДНК тоже чему-то обучается, когда из множества клеток выживают только те, у которых ДНК хорошо приспособлена к выживанию? Можно сказать, что обучается целая популяция, но отдельные организмы ничему не обучаются - они просто дохнут, не давая бракованным данным перейти в следующее поколение (итерацию) своей популяции.
>>68658
Понятно, ты не гонку делаешь, так бы и сказал.
Вообще-то в этом самое интересное. У тебя сейчас среда крайне примитивная, поэтому и результаты не впечатляют. Добавь больше физики, будет любопытнее, до чего дойдёт эволюция. Алсо в идеале нужно менять количество колёс, длину/ширину машин, прицепов и т.д. Одна только логика поворотов на примитивной "машине" - слишком просто, такое и вручную несложно закодить.
И самое любопытное - решить задачу в общем случае. Чтобы машинка ехала по любой трассе без ошибок, а не только по одной конкретной.
Почему это нейронками называют? Это генетические алгоритмы. Может, там внутри и есть граф, внешне напоминающий нейросеть, но он не обучается как нейросеть - вместо обучения в таких симуляциях копируют данные наиболее удачного экземпляра и затем немного меняют их, запуская в симуляцию и снова отслеживая наиболее удачных. От нейронки тут только граф, но чтобы граф был нейронкой, он должен обучаться же, а обучения тут нет - только эволюционный отбор и мутации "генов".
Или, по-твоему, ДНК тоже чему-то обучается, когда из множества клеток выживают только те, у которых ДНК хорошо приспособлена к выживанию? Можно сказать, что обучается целая популяция, но отдельные организмы ничему не обучаются - они просто дохнут, не давая бракованным данным перейти в следующее поколение (итерацию) своей популяции.
>>68658
Понятно, ты не гонку делаешь, так бы и сказал.
>у RigidBody2D сильно больше параметров
Вообще-то в этом самое интересное. У тебя сейчас среда крайне примитивная, поэтому и результаты не впечатляют. Добавь больше физики, будет любопытнее, до чего дойдёт эволюция. Алсо в идеале нужно менять количество колёс, длину/ширину машин, прицепов и т.д. Одна только логика поворотов на примитивной "машине" - слишком просто, такое и вручную несложно закодить.
И самое любопытное - решить задачу в общем случае. Чтобы машинка ехала по любой трассе без ошибок, а не только по одной конкретной.
>>68724
Там есть второй вариант где можно указать ожидаемый аутпут при заданных параметрах (прыгать если ниже в трубы в случае с флаапи берд например) и оно будет строить себе сеть, это уже будет называться нейронкой?
Я не знаю как сделать рандомные дороги, мне даже лень текущим способом делать большой уровень, слишком геморно.
>Это генетические алгоритмы.
Там есть второй вариант где можно указать ожидаемый аутпут при заданных параметрах (прыгать если ниже в трубы в случае с флаапи берд например) и оно будет строить себе сеть, это уже будет называться нейронкой?
>И самое любопытное - решить задачу в общем случае. Чтобы машинка ехала по любой трассе без ошибок, а не только по одной конкретной.
Я не знаю как сделать рандомные дороги, мне даже лень текущим способом делать большой уровень, слишком геморно.
>>68729
https://github.com/stoicaandrei/godot-neural-network
Спиздил отсюда бтв. Но у него не работает, а я разобрался почему и пофиксил.
https://github.com/stoicaandrei/godot-neural-network
Спиздил отсюда бтв. Но у него не работает, а я разобрался почему и пофиксил.
>>68724
Зыс.
Кроме того, неросеть сама по себе - это генетический алгоритм.
> Или, по-твоему, ДНК тоже чему-то обучается, когда из множества клеток выживают только те, у которых ДНК хорошо приспособлена к выживанию?
Зыс.
Кроме того, неросеть сама по себе - это генетический алгоритм.
>>68729
Есть охуенный туториал
https://www.youtube.com/watch?v=Yvy8vQ-5O_w&list=PLe63S5Eft1KapdW0-o824gCbG8LPvzxSA&index=2
Тут сразу весь плейлист. Рекомендую сначала смотреть. Но эта ссылка на начало построения дороги.
> как сделать рандомные дороги
Есть охуенный туториал
https://www.youtube.com/watch?v=Yvy8vQ-5O_w&list=PLe63S5Eft1KapdW0-o824gCbG8LPvzxSA&index=2
Тут сразу весь плейлист. Рекомендую сначала смотреть. Но эта ссылка на начало построения дороги.
>>68771
Точнее есть, но не для 2д, а запиливать генерацию Polygon2D и CollisionPolygon2D по Path2D я не осилю.
Точнее есть, но не для 2д, а запиливать генерацию Polygon2D и CollisionPolygon2D по Path2D я не осилю.
>>68779
Там буквально массив точек заполнить и всё.
1. Извлекаешь точки из Curve2D.
2. Дублируешь их.
3. Половину смещаешь влево.
4. Вторую половину вправо.
5. Упорядочиваешь.
6. Загоняешь в свои ноды.
7. ???
8. Ты восхитительная геймдева.
>запиливать генерацию Polygon2D и CollisionPolygon2D по Path2D я не осилю
Там буквально массив точек заполнить и всё.
1. Извлекаешь точки из Curve2D.
2. Дублируешь их.
3. Половину смещаешь влево.
4. Вторую половину вправо.
5. Упорядочиваешь.
6. Загоняешь в свои ноды.
7. ???
8. Ты восхитительная геймдева.
>>68799
Ухх какой неверный ответ.
Курв хранит не точки линит, а хендлы Безье.
У точек нет понятий лево и право. Если ты сдвинешь фигуру L влево, ты получишь ┖ с тонкой горизонталью и толстой вертикалью
На поворотах у тебя могут наложиться грани
А что скажет физический движок, если полигон окажется с петлями и восьмерками, я даже не представляю.
Ухх какой неверный ответ.
Курв хранит не точки линит, а хендлы Безье.
У точек нет понятий лево и право. Если ты сдвинешь фигуру L влево, ты получишь ┖ с тонкой горизонталью и толстой вертикалью
На поворотах у тебя могут наложиться грани
А что скажет физический движок, если полигон окажется с петлями и восьмерками, я даже не представляю.
>>68817
Хранит. Вернее, кэширует с заданной точностью.
https://docs.godotengine.org/en/stable/classes/class_curve2d.html#class-curve2d-method-get-baked-points
Но мы можем посчитать нормали вершин линии.
https://docs.godotengine.org/en/stable/classes/class_vector2.html
Мы о 2D говорим ведь? Какие грани?
Рёбра просто сожмутся или растянутся.
Ну так рисуй свой Path2D без петель и восьмёрок.
Мы же вроде обсуждали создание бордюрчиков?
>Курв хранит не точки линит
Хранит. Вернее, кэширует с заданной точностью.
https://docs.godotengine.org/en/stable/classes/class_curve2d.html#class-curve2d-method-get-baked-points
>У точек нет понятий лево и право
Но мы можем посчитать нормали вершин линии.
https://docs.godotengine.org/en/stable/classes/class_vector2.html
>На поворотах у тебя могут наложиться грани
Мы о 2D говорим ведь? Какие грани?
Рёбра просто сожмутся или растянутся.
>окажется с петлями и восьмерками
Ну так рисуй свой Path2D без петель и восьмёрок.
Мы же вроде обсуждали создание бордюрчиков?
>>68828
В Curve2D можно постучать через Path2D?
Вообще я думал строить бордюрчики через PathFollow2D по оффсетам, короче как тут предложили судя по всему >>68799
Только не знаю как замкнуть Polygon2D под конец.
>>68796
Не нашел, может плохо, или не то, искал.
p.s. я немного туповат и до меня все долго доходит, но дойти может
В Curve2D можно постучать через Path2D?
Вообще я думал строить бордюрчики через PathFollow2D по оффсетам, короче как тут предложили судя по всему >>68799
Только не знаю как замкнуть Polygon2D под конец.
>>68796
Не нашел, может плохо, или не то, искал.
p.s. я немного туповат и до меня все долго доходит, но дойти может
7 Кб, 160x238>>68828
Но это уже не то же самое что ты писал "одну половину влево, другую вправо".
Обычные. Мы же про полигон говорим.
Перекроются на повороте.
Так они могут возникнуть из кривой Безье.
Если этим пользоваться будет только автор, то надо бы как минимум выдавать ошибку при генерации полигона
А если игроку позволить рисовать карты, то тут уже простым алгоритмом не обойтись.
Хз, ветка вроде про дороги, то есть дорожное полотно?
В общем, строить такой полигон довольно нетривиальная задача с кучей разного матана, не надо вводить заблуждение ложным описание что просто точки влево-вправо подвигаешь.
>>68848
Я тоже не нашел. Есть Trail для 3d, может быть можно адаптировать.
>Но мы можем посчитать нормали вершин линии.
Но это уже не то же самое что ты писал "одну половину влево, другую вправо".
>Мы о 2D говорим ведь? Какие грани?
Обычные. Мы же про полигон говорим.
>Рёбра просто сожмутся или растянутся.
Перекроются на повороте.
>Ну так рисуй свой Path2D без петель и восьмёрок.
Так они могут возникнуть из кривой Безье.
Если этим пользоваться будет только автор, то надо бы как минимум выдавать ошибку при генерации полигона
А если игроку позволить рисовать карты, то тут уже простым алгоритмом не обойтись.
>Мы же вроде обсуждали создание бордюрчиков?
Хз, ветка вроде про дороги, то есть дорожное полотно?
В общем, строить такой полигон довольно нетривиальная задача с кучей разного матана, не надо вводить заблуждение ложным описание что просто точки влево-вправо подвигаешь.
>>68848
>Не нашел, может плохо, или не то, искал.
Я тоже не нашел. Есть Trail для 3d, может быть можно адаптировать.
В принципе работает.
Polygon2D можно вывернуть наизнанку, а машинки запереть в коллижене, потому что проверяется только граница, и внутри полигонов коллижена не прокает столкновение, нужно только билд мод на сегменты переключить.
Осталось только сделать так чтобы строилась собственно дорожка по Path2D. Пойду искать как добавлять к вектору2 нужное мне смещение в стороны и повороты относительно дороги.
Polygon2D можно вывернуть наизнанку, а машинки запереть в коллижене, потому что проверяется только граница, и внутри полигонов коллижена не прокает столкновение, нужно только билд мод на сегменты переключить.
Осталось только сделать так чтобы строилась собственно дорожка по Path2D. Пойду искать как добавлять к вектору2 нужное мне смещение в стороны и повороты относительно дороги.
В движке есть возможность взаимодействия с файловой системой винды? Ну типа там папки перемещать и удалять? Я просто больной извращенец который хотел бы попробовать написать простенькую прогу для своих нужд
>>68877
API есть, не знаю насколько полно покрывает задачи
https://docs.godotengine.org/en/3.6/classes/class_directory.html#class-directory-method-rename
Если чего то нет, можно вызвать cmd.exe, хехе.
API есть, не знаю насколько полно покрывает задачи
https://docs.godotengine.org/en/3.6/classes/class_directory.html#class-directory-method-rename
Если чего то нет, можно вызвать cmd.exe, хехе.
Разрешает лт лицензия годота сделать свой движок на его основе? И скрыть сорцы
>>68903
Да.
Да.
>>68903
Разрещает. Вот пруфы здесь:
https://habr.com/ru/post/310976/
Конкретнее, вот тут:
Разрещает. Вот пруфы здесь:
https://habr.com/ru/post/310976/
Конкретнее, вот тут:
>Данная лицензия разрешает лицам, получившим копию данного программного обеспечения и сопутствующей документации (в дальнейшем именуемыми «Программное Обеспечение»), безвозмездно использовать Программное Обеспечение без ограничений, включая неограниченное право на использование, копирование, изменение, слияние, публикацию, распространение, сублицензирование
>>68882
Можно добавить еще один Polygon2D без маски коллизий с текстурой дороги, скрыть внешний, и будет заебись. Но мне лень.
Восьмерки и резкие повороты не переваривает, даже в луп не завернуть, но я доволен.
Еще сделал чтобы в редакторе рисовалось, в общем, то чего хотел я добился.
Можно добавить еще один Polygon2D без маски коллизий с текстурой дороги, скрыть внешний, и будет заебись. Но мне лень.
Восьмерки и резкие повороты не переваривает, даже в луп не завернуть, но я доволен.
Еще сделал чтобы в редакторе рисовалось, в общем, то чего хотел я добился.
>>68903
Да, но кроме логотипа и названия.
Да, но кроме логотипа и названия.
>>68848
https://docs.godotengine.org/en/stable/classes/class_path2d.html
https://docs.godotengine.org/en/stable/classes/class_polygon2d.html#class-polygon2d-property-polygon
>>68855
Это то же самое. У нас есть линия из точек, у линии в каждой точке есть "лево" и "право", мы определяем конкретные направления и сдвигаем точки. Всё. Ладно, согласен, нужно было конкретнее написать.
Polygon2D автоматически триангулируется. Ты просто перечисляешь точки по кругу. Дальше движок сам триангулирует всё лучшим возможным способом. Ты можешь добавить в ноду Polygon2D несколько независимых полигонов, но и они - такое же простое перечисление точек по кругу, которое потом триангулируется автоматически. Так что о гранях тебе беспокоиться не нужно, пока ты делаешь замкнутую фигуру вытянутой формы (о чём изначально речь шла - расширить кривые линии и дать им коллизии).
Ещё раз, мы обсуждали какой-то прототип полигона для тренировки нейросетевых ботов, анон писал, мол, ему лень делать сложную трассу, ни о каком редакторе карты в игре речи не шло. Для игрового редактора карты нужны другие алгоритмы, зависящие от того, что за игра и что должен позволять сделать редактор. Для дорог, на мой взгляд, рационально будет сделать граф, рёбра которого соединяются линиями, а вершины образуют пересечения, при этом пересечения рёбер без вершин образуют многослойный трек (машинки на разных дорогах не смогут столкнуться друг с другом, но для этого придётся регулярно менять их физические слои).
У него боты рейкастами щупают стены. Ему предложили сделать больше разных дорог (иначе нейронка запоминает один маршрут и фейлится на любом другом, чего обычно стараются избегать). Он отказался, мотивировав тем, что ему лень расставлять стены вручную. Ему предложили генерировать стены из Path2D, чтобы быстрее делать более сложные трассы. Дорожного полотна на его видео вообще не видно, там просто туннель в пещере, машинки по сплошной фоновой заливке ползут.
>В Curve2D можно постучать через Path2D?
https://docs.godotengine.org/en/stable/classes/class_path2d.html
>Property Descriptions
>Curve2D curve
>void set_curve ( Curve2D value )
>Curve2D get_curve ( )
>A Curve2D describing the path.
>Только не знаю как замкнуть Polygon2D под конец.
https://docs.godotengine.org/en/stable/classes/class_polygon2d.html#class-polygon2d-property-polygon
>The polygon's list of vertices. The final point will be connected to the first.
>>68855
>Но это уже не то же самое что ты писал "одну половину влево, другую вправо".
Это то же самое. У нас есть линия из точек, у линии в каждой точке есть "лево" и "право", мы определяем конкретные направления и сдвигаем точки. Всё. Ладно, согласен, нужно было конкретнее написать.
>Мы же про полигон говорим.
Polygon2D автоматически триангулируется. Ты просто перечисляешь точки по кругу. Дальше движок сам триангулирует всё лучшим возможным способом. Ты можешь добавить в ноду Polygon2D несколько независимых полигонов, но и они - такое же простое перечисление точек по кругу, которое потом триангулируется автоматически. Так что о гранях тебе беспокоиться не нужно, пока ты делаешь замкнутую фигуру вытянутой формы (о чём изначально речь шла - расширить кривые линии и дать им коллизии).
>А если игроку позволить рисовать карты
Ещё раз, мы обсуждали какой-то прототип полигона для тренировки нейросетевых ботов, анон писал, мол, ему лень делать сложную трассу, ни о каком редакторе карты в игре речи не шло. Для игрового редактора карты нужны другие алгоритмы, зависящие от того, что за игра и что должен позволять сделать редактор. Для дорог, на мой взгляд, рационально будет сделать граф, рёбра которого соединяются линиями, а вершины образуют пересечения, при этом пересечения рёбер без вершин образуют многослойный трек (машинки на разных дорогах не смогут столкнуться друг с другом, но для этого придётся регулярно менять их физические слои).
>ветка вроде про дороги, то есть дорожное полотно?
У него боты рейкастами щупают стены. Ему предложили сделать больше разных дорог (иначе нейронка запоминает один маршрут и фейлится на любом другом, чего обычно стараются избегать). Он отказался, мотивировав тем, что ему лень расставлять стены вручную. Ему предложили генерировать стены из Path2D, чтобы быстрее делать более сложные трассы. Дорожного полотна на его видео вообще не видно, там просто туннель в пещере, машинки по сплошной фоновой заливке ползут.
>>68848
https://docs.godotengine.org/en/stable/classes/class_path2d.html
https://docs.godotengine.org/en/stable/classes/class_polygon2d.html#class-polygon2d-property-polygon
>>68855
Это то же самое. У нас есть линия из точек, у линии в каждой точке есть "лево" и "право", мы определяем конкретные направления и сдвигаем точки. Всё. Ладно, согласен, нужно было конкретнее написать.
Polygon2D автоматически триангулируется. Ты просто перечисляешь точки по кругу. Дальше движок сам триангулирует всё лучшим возможным способом. Ты можешь добавить в ноду Polygon2D несколько независимых полигонов, но и они - такое же простое перечисление точек по кругу, которое потом триангулируется автоматически. Так что о гранях тебе беспокоиться не нужно, пока ты делаешь замкнутую фигуру вытянутой формы (о чём изначально речь шла - расширить кривые линии и дать им коллизии).
Ещё раз, мы обсуждали какой-то прототип полигона для тренировки нейросетевых ботов, анон писал, мол, ему лень делать сложную трассу, ни о каком редакторе карты в игре речи не шло. Для игрового редактора карты нужны другие алгоритмы, зависящие от того, что за игра и что должен позволять сделать редактор. Для дорог, на мой взгляд, рационально будет сделать граф, рёбра которого соединяются линиями, а вершины образуют пересечения, при этом пересечения рёбер без вершин образуют многослойный трек (машинки на разных дорогах не смогут столкнуться друг с другом, но для этого придётся регулярно менять их физические слои).
У него боты рейкастами щупают стены. Ему предложили сделать больше разных дорог (иначе нейронка запоминает один маршрут и фейлится на любом другом, чего обычно стараются избегать). Он отказался, мотивировав тем, что ему лень расставлять стены вручную. Ему предложили генерировать стены из Path2D, чтобы быстрее делать более сложные трассы. Дорожного полотна на его видео вообще не видно, там просто туннель в пещере, машинки по сплошной фоновой заливке ползут.
>В Curve2D можно постучать через Path2D?
https://docs.godotengine.org/en/stable/classes/class_path2d.html
>Property Descriptions
>Curve2D curve
>void set_curve ( Curve2D value )
>Curve2D get_curve ( )
>A Curve2D describing the path.
>Только не знаю как замкнуть Polygon2D под конец.
https://docs.godotengine.org/en/stable/classes/class_polygon2d.html#class-polygon2d-property-polygon
>The polygon's list of vertices. The final point will be connected to the first.
>>68855
>Но это уже не то же самое что ты писал "одну половину влево, другую вправо".
Это то же самое. У нас есть линия из точек, у линии в каждой точке есть "лево" и "право", мы определяем конкретные направления и сдвигаем точки. Всё. Ладно, согласен, нужно было конкретнее написать.
>Мы же про полигон говорим.
Polygon2D автоматически триангулируется. Ты просто перечисляешь точки по кругу. Дальше движок сам триангулирует всё лучшим возможным способом. Ты можешь добавить в ноду Polygon2D несколько независимых полигонов, но и они - такое же простое перечисление точек по кругу, которое потом триангулируется автоматически. Так что о гранях тебе беспокоиться не нужно, пока ты делаешь замкнутую фигуру вытянутой формы (о чём изначально речь шла - расширить кривые линии и дать им коллизии).
>А если игроку позволить рисовать карты
Ещё раз, мы обсуждали какой-то прототип полигона для тренировки нейросетевых ботов, анон писал, мол, ему лень делать сложную трассу, ни о каком редакторе карты в игре речи не шло. Для игрового редактора карты нужны другие алгоритмы, зависящие от того, что за игра и что должен позволять сделать редактор. Для дорог, на мой взгляд, рационально будет сделать граф, рёбра которого соединяются линиями, а вершины образуют пересечения, при этом пересечения рёбер без вершин образуют многослойный трек (машинки на разных дорогах не смогут столкнуться друг с другом, но для этого придётся регулярно менять их физические слои).
>ветка вроде про дороги, то есть дорожное полотно?
У него боты рейкастами щупают стены. Ему предложили сделать больше разных дорог (иначе нейронка запоминает один маршрут и фейлится на любом другом, чего обычно стараются избегать). Он отказался, мотивировав тем, что ему лень расставлять стены вручную. Ему предложили генерировать стены из Path2D, чтобы быстрее делать более сложные трассы. Дорожного полотна на его видео вообще не видно, там просто туннель в пещере, машинки по сплошной фоновой заливке ползут.
>>68877
Конечно, есть. Они сделали из Godot полноценную RAD IDE, так называемый Godot Editor является демонстрацией возможностей этой системы. Твои приложения могут почти всё, что может редактор.
Никакого извращения тут нет, многие используют Godot для создания неигровых программ, также на гитхабе уже несколько лет ведётся работа по созданию специальных билдов движка для приложений, нуждающихся только в GUI. На данный момент, как я понял, всё ещё сложно отделить GUI от остальных модулей, в идеале они хотят дать возможность полностью выкинуть из движка всё, кроме GUI, чтобы прикладные программы на Godot не тащили в себе совершенно лишние им модули.
>>68903
Ты имеешь в виду "сделать форк и продавать его третьим лицам, не раздавая исходники"? Да, можно, но ты должен будешь указывать, что твой движок основан на движке Godot, который разработан такими-то людьми (список) и распространяется по такой-то лицензии. Алсо помни, что в Godot есть модули, лицензия на которые отличается от лицензии на движок в целом.
Если же ты имеешь в виду модификации движка для личного использования, то тут вообще никаких проблем нет, тебе не нужно никому сообщать о том, что ты у себя дома играешься с движком и делаешь в нём какие-то модификации. Это просто фанаты/любители любят хвастаться, что они делают на движке, а так никто их не обязывает разглашать, пока они не публикуют свои проекты в исполняемой форме. Только в опубликованной игре должна быть запись, что игра сделана на Godot (так же, как и в кастомном движке на его основе).
>В движке есть возможность взаимодействия с файловой системой винды? Ну типа там папки перемещать и удалять?
Конечно, есть. Они сделали из Godot полноценную RAD IDE, так называемый Godot Editor является демонстрацией возможностей этой системы. Твои приложения могут почти всё, что может редактор.
>Я просто больной извращенец который хотел бы попробовать написать простенькую прогу для своих нужд
Никакого извращения тут нет, многие используют Godot для создания неигровых программ, также на гитхабе уже несколько лет ведётся работа по созданию специальных билдов движка для приложений, нуждающихся только в GUI. На данный момент, как я понял, всё ещё сложно отделить GUI от остальных модулей, в идеале они хотят дать возможность полностью выкинуть из движка всё, кроме GUI, чтобы прикладные программы на Godot не тащили в себе совершенно лишние им модули.
>>68903
>свой движок на его основе? И скрыть сорцы
Ты имеешь в виду "сделать форк и продавать его третьим лицам, не раздавая исходники"? Да, можно, но ты должен будешь указывать, что твой движок основан на движке Godot, который разработан такими-то людьми (список) и распространяется по такой-то лицензии. Алсо помни, что в Godot есть модули, лицензия на которые отличается от лицензии на движок в целом.
Если же ты имеешь в виду модификации движка для личного использования, то тут вообще никаких проблем нет, тебе не нужно никому сообщать о том, что ты у себя дома играешься с движком и делаешь в нём какие-то модификации. Это просто фанаты/любители любят хвастаться, что они делают на движке, а так никто их не обязывает разглашать, пока они не публикуют свои проекты в исполняемой форме. Только в опубликованной игре должна быть запись, что игра сделана на Godot (так же, как и в кастомном движке на его основе).
>>68964
Это чтобы замкнуть луп и получить собсвенно полигон. Мне же нужно замкнуть луп из полигонов.
С курвом и как его применить я уже разобрался, спасибо.
Дорожное полотно я тоже придумал как сделать, еще один полигон2д на другом слое и с текстурой, а внешку скрыть, но это завтра.
>The polygon's list of vertices. The final point will be connected to the first.
Это чтобы замкнуть луп и получить собсвенно полигон. Мне же нужно замкнуть луп из полигонов.
С курвом и как его применить я уже разобрался, спасибо.
Дорожное полотно я тоже придумал как сделать, еще один полигон2д на другом слое и с текстурой, а внешку скрыть, но это завтра.
Годаны, а как в четвёрке настроить работу с мышью в 2д-редакторе?
Раньше было как. Кручу колесо = перемещается камера; контрол + кручу колесо = масштаб. А тут наоборот, и я чёт не уверен даже, по умолчанию ли такое поведение в Г4 или я что-то не то нажал. Где смотреть?
А то как-то неконвенционально, раздражает.
Раньше было как. Кручу колесо = перемещается камера; контрол + кручу колесо = масштаб. А тут наоборот, и я чёт не уверен даже, по умолчанию ли такое поведение в Г4 или я что-то не то нажал. Где смотреть?
А то как-то неконвенционально, раздражает.
9 Кб, 549x301>>69008
У тебя настройки были изменены в 3.x.
Поведение по умолчанию в основном осталось прежним, только часть настроек переехала в другой раздел и при импорте старых настроек новая версия, видимо, не нашла нужные ключи, сбросив их в значение по умолчанию. К тому же, теперь вместо галочки - выпадающий список, но смысл почти тот же.
По-моему, такое удобно только в редакторах, где у тебя всего одна ось смещения (текст). В 2D редакторе тебе зачастую нужно смещаться по двум осям и поэтому крутить колёсико неудобно, лучше его зажимать и смешать мышь. Поэтому колёсиком лучше регулировать приближение, без нажатия лишних клавиш, а не смещение по одной оси. Вот если у тебя мышь с двумя колёсиками или на колёсике есть возможность крутить по двум осям (слышал, вроде, были такие мыши), тогда можно понять, а так какая-то фигня получается - по вертикали крутишь колесо, а по горизонтали отдельные костыли используешь. Да и в чём проблема зажать колёсико? Обычно оно не такое уж тугое, либо можно разработать со временем. Думаю, поэтому настройка по умолчанию - зум колесом, а смещение - зажатием кнопки колеса.
Хех, пришлось покрутиться в обоих версиях редактора, прежде чем я смог понять, что тебя вообще интересует. Но я прекрасно тебя понимаю... недавно мучился из-за того, что в Blender вертикальная ось Z, а не Y, как в Godot, а я давно в Blender не заходил и уже привык к осям Godot... Когда уже запилят все функции Blender в Godot, лол? Шучу.
>Раньше было как.
У тебя настройки были изменены в 3.x.
>неконвенционально
Поведение по умолчанию в основном осталось прежним, только часть настроек переехала в другой раздел и при импорте старых настроек новая версия, видимо, не нашла нужные ключи, сбросив их в значение по умолчанию. К тому же, теперь вместо галочки - выпадающий список, но смысл почти тот же.
>Кручу колесо = перемещается камера;
По-моему, такое удобно только в редакторах, где у тебя всего одна ось смещения (текст). В 2D редакторе тебе зачастую нужно смещаться по двум осям и поэтому крутить колёсико неудобно, лучше его зажимать и смешать мышь. Поэтому колёсиком лучше регулировать приближение, без нажатия лишних клавиш, а не смещение по одной оси. Вот если у тебя мышь с двумя колёсиками или на колёсике есть возможность крутить по двум осям (слышал, вроде, были такие мыши), тогда можно понять, а так какая-то фигня получается - по вертикали крутишь колесо, а по горизонтали отдельные костыли используешь. Да и в чём проблема зажать колёсико? Обычно оно не такое уж тугое, либо можно разработать со временем. Думаю, поэтому настройка по умолчанию - зум колесом, а смещение - зажатием кнопки колеса.
Хех, пришлось покрутиться в обоих версиях редактора, прежде чем я смог понять, что тебя вообще интересует. Но я прекрасно тебя понимаю... недавно мучился из-за того, что в Blender вертикальная ось Z, а не Y, как в Godot, а я давно в Blender не заходил и уже привык к осям Godot... Когда уже запилят все функции Blender в Godot, лол? Шучу.
>>69016
Вообще, я согласен, по эргономике лучше не жать лишних клавиш. Но всё же в софте, где есть прокрутка по двум измерениям и масштабирование, повсеместно используется такое управление:
Колесо = вертикальный скролл
Счифт+колесо = горизонтальный скролл
Цтрл+колесо = масштабирование по положению мыши
Когда разные интерфейсы ведут себя одинаково не по гайдлайнам или эргономике, а потому что так принято, это и называется конвенциональностью. И если какая-то одна софтина выбивается, например, потому что она дохуя заботится об удобстве пользователя, это жутко бесит. Вместо удобства выходит, что каждый раз нужно вспоминать, что тут другое управление. Обычно даже - ошибиться, разозлиться, вспомнить. Это отвлекает от работы собственно в приложении. Ну, то есть, если бы я только этим приложением пользовался, не вылезая даже в браузер, было бы норм; но везде принята другая схема управления, под которую и адаптируется мышечная память.
Ну хз, я полгода в годо не заглядывал, а щас решил четвёрку пощупать.
В общем, спасибо, анонче, без тебя бы я эту опцию там не нашёл.
>По-моему, такое удобно только в редакторах, где у тебя всего одна ось смещения (текст).
Вообще, я согласен, по эргономике лучше не жать лишних клавиш. Но всё же в софте, где есть прокрутка по двум измерениям и масштабирование, повсеместно используется такое управление:
Колесо = вертикальный скролл
Счифт+колесо = горизонтальный скролл
Цтрл+колесо = масштабирование по положению мыши
Когда разные интерфейсы ведут себя одинаково не по гайдлайнам или эргономике, а потому что так принято, это и называется конвенциональностью. И если какая-то одна софтина выбивается, например, потому что она дохуя заботится об удобстве пользователя, это жутко бесит. Вместо удобства выходит, что каждый раз нужно вспоминать, что тут другое управление. Обычно даже - ошибиться, разозлиться, вспомнить. Это отвлекает от работы собственно в приложении. Ну, то есть, если бы я только этим приложением пользовался, не вылезая даже в браузер, было бы норм; но везде принята другая схема управления, под которую и адаптируется мышечная память.
>У тебя настройки были изменены в 3.x.
Ну хз, я полгода в годо не заглядывал, а щас решил четвёрку пощупать.
В общем, спасибо, анонче, без тебя бы я эту опцию там не нашёл.
>>69020
Я, наоборот, много где использую прокрутку зажатой кнопкой колеса + сдвигом мыши, и меня бесит, если приложение так не умеет, но при этом требуется двигать что-то сразу по двум осям.
Что я использую, из недавнего:
- с зажатым колесом:
-- Inkscape, Krita, Paint.NET, Blender, Godot;
- с зажатой левой кнопкой:
-- FastStone Image Viewer, Freeplane;
- клик колёсиком -> установка метки сдвига:
-- Firefox - часто так делаю вместо вращения;
-- Adobe Acrobat Reader - похоже, но с зажатием;
-- LibreOffice - есть, но как-то не очень удобно.
Возможно, частично сказывается то, что у меня уже давно на мыши стёрлость колёсико и прокрутка теперь недостаточно точная, рывками, но вот этот прикол с зажатием колёсика и сдвигом я начал использовать очень давно, колёсико тогда было исправно. Не представляю, как может существовать приложение с прокруткой по двум осям и без возможности зажать (среднюю) кнопку мыши хотя бы в качестве альтернативы. По-моему, я даже на тачпаде ноутбука этой фичей пользовался, там вроде два пальца прикладывать нужно было для клика средней кнопкой и мне было это удобнее прокрутки сбоку тачпада (при том что у него как раз "два колёсика" - две стороны для прокрутки).
Не знаю, как в хромиумах, а в Firefox нажатие колёсика ставит метку, которой прокручивать очень удобно в любом направлении - достаточно сместить мышку вбок и страница будет двигаться самостоятельно с заданной скоростью, от очень медленной до очень быстрой - мышь можно оставить в покое и читать страницу, пока она движется, колёсиком/боковым скроллом такой удобный трюк ты точно не проделаешь. В некоторых других программах часто похожее вижу, где что-то очень длинное листать колесом было бы утомительно. Наверное, это неочевидная фича, поэтому ей мало кто пользуется, сам обнаружил в своё время чисто случайно.
>повсеместно используется такое управление
Я, наоборот, много где использую прокрутку зажатой кнопкой колеса + сдвигом мыши, и меня бесит, если приложение так не умеет, но при этом требуется двигать что-то сразу по двум осям.
Что я использую, из недавнего:
- с зажатым колесом:
-- Inkscape, Krita, Paint.NET, Blender, Godot;
- с зажатой левой кнопкой:
-- FastStone Image Viewer, Freeplane;
- клик колёсиком -> установка метки сдвига:
-- Firefox - часто так делаю вместо вращения;
-- Adobe Acrobat Reader - похоже, но с зажатием;
-- LibreOffice - есть, но как-то не очень удобно.
Возможно, частично сказывается то, что у меня уже давно на мыши стёрлость колёсико и прокрутка теперь недостаточно точная, рывками, но вот этот прикол с зажатием колёсика и сдвигом я начал использовать очень давно, колёсико тогда было исправно. Не представляю, как может существовать приложение с прокруткой по двум осям и без возможности зажать (среднюю) кнопку мыши хотя бы в качестве альтернативы. По-моему, я даже на тачпаде ноутбука этой фичей пользовался, там вроде два пальца прикладывать нужно было для клика средней кнопкой и мне было это удобнее прокрутки сбоку тачпада (при том что у него как раз "два колёсика" - две стороны для прокрутки).
>не вылезая даже в браузер
Не знаю, как в хромиумах, а в Firefox нажатие колёсика ставит метку, которой прокручивать очень удобно в любом направлении - достаточно сместить мышку вбок и страница будет двигаться самостоятельно с заданной скоростью, от очень медленной до очень быстрой - мышь можно оставить в покое и читать страницу, пока она движется, колёсиком/боковым скроллом такой удобный трюк ты точно не проделаешь. В некоторых других программах часто похожее вижу, где что-то очень длинное листать колесом было бы утомительно. Наверное, это неочевидная фича, поэтому ей мало кто пользуется, сам обнаружил в своё время чисто случайно.
>>69023
Ну я тоже ей пользуюсь, но обычно для точных небольших перемещений. А если надо сдвинуться на расстояние, сравнимое с отображаемой картинкой, я уже кручу колесо.
Тащемта проблема была же не в нажатии колеса, а в его вращении.
Ну хз, я линухами пользуюсь, тут это далеко не везде есть. В том же фаерфоксе, например, нету.
Бля, даже читать больно. А потом оно начинает вообще тупить: крутишь в одну сторону, а крутит то туда, то обратно. И при нажатии тоже норовит крутануться.
Я в итоге плюнул и купил "игровую" мышь. Вроде уже полгода живёт и не пытается ломаться.
>прокрутку зажатой кнопкой колеса
Ну я тоже ей пользуюсь, но обычно для точных небольших перемещений. А если надо сдвинуться на расстояние, сравнимое с отображаемой картинкой, я уже кручу колесо.
Тащемта проблема была же не в нажатии колеса, а в его вращении.
>Не представляю, как может существовать приложение с прокруткой по двум осям и без возможности зажать (среднюю) кнопку мыши хотя бы в качестве альтернативы.
Ну хз, я линухами пользуюсь, тут это далеко не везде есть. В том же фаерфоксе, например, нету.
>у меня уже давно на мыши стёрлость колёсико и прокрутка теперь недостаточно точная, рывками
Бля, даже читать больно. А потом оно начинает вообще тупить: крутишь в одну сторону, а крутит то туда, то обратно. И при нажатии тоже норовит крутануться.
Я в итоге плюнул и купил "игровую" мышь. Вроде уже полгода живёт и не пытается ломаться.
Второй день делаю свою 2D вайфу в стиле Live2D, используя лишь встроенные возможности Godot.
Что я узнал/понял на данный момент:
0. Визуальный редактор Polygon2D явно не доделан до комфортного состояния: зум в левый верхний угол, в случае ошибки нельзя откатиться на одну точку назад (как можно, например, в Inkscape, нажав ПКМ) и нельзя добавить/удалить точки в уже законченном полигоне - только начинать с нуля или двигать уже имеющиеся, либо добавить "внутренние точки" и делать свои собственные полигоны. Это всё неудобно, но терпимо. Также триангуляция по умолчанию плохо деформирует спрайт, но об этом в документации написано, нужно просто кастомные полигоны делать (рутина, но это как раз сделано достаточно удобно, просто тыкаешь точки и всё).
1. Функций Godot достаточно для создания анимаций в этом стиле. В худшем случае нужно будет смешать 2D с 3D в одной модели через вьюпорты - это следствие того, что у нас в 2D рендерере вращение только по одной оси Z, а в Live2D вроде бы по всем осям можно (?), либо можно сымитировать вращение, добавив больше костей. Главный недостаток в том, что Godot существует сам по себе, а модели из Live2D можно в самых разных программах использовать. Но для меня это не проблема.
2. Не знаю, как делают в Live2D (сам не пробовал), но некоторые вещи через анимации в Godot делать сложно, однако, на GDScript такие вещи решаются легко. Вот, скажем, поворот головы я сделал как 4 анимации по одному кадру, которые комбинируются в BlendSpace2D, но Z-order ушей таким способом настроить сложно, поэтому управляю ушами через код. Костыльно, но какие альтернативы? Если я в анимации меняю bool или +1/-1 по Z, то BlendSpace2D не интерполирует как я хочу и не даёт точной настройки интерполяции. Делать отдельные анимации под уши я не хочу, это всё усложнит и увеличит количество рутины, поэтому решил пока костыльнуть через код, там буквально одна строчка под каждое ухо. Скриптить модель в любом случае придётся, поскольку я хочу дать ей процедурное поведение - поэтому BlendSpace2D, а не простые анимации.
3. Очень много рутины. В идеале, для правильной интерполяции поворотов головы, нужно 8 анимаций, по одной на каждую сторону и ещё диагонали. Костей уже сейчас много, а будет ещё больше, т.к. волосы я пока даже не рисовал. При этом противоположные анимации должны быть симметричными, иначе будет фигня. Выворачивать спрайты по X/Y не вариант, т.к. лицо изначально может быть асимметричным (представьте себе глаза разного цвета или монокль - отражать такое не вариант). Сначала думал вручную сделать, но теперь пишу tool скрипт для автоматического отражения заданных анимаций - тогда мне нужно будет сделать в 2 или даже 4 раза меньше работы, и получить гарантированно точный результат. По понятным причинам такой утилиты из коробки в движке никогда не будет - она слишком специфична. Да и я уже не уверен, что мой скрипт что-то решит, т.к. если кости расположены не симметрично, то всё равно вручную править каждую из сторон придётся. Но, мне кажется, в Live2D рутины не сильно меньше, по скриншотам там очень сложный GUI и настроек много, по обсуждениям - они там часами возятся для тривиальной анимации, лол.
4. Готовая сцена имеет низкую реюзабельность, т.к. если другой персонаж имеет что-то другое в геометрии лица, то правок не избежать. Но в целом, по идее, можно переиспользовать готовую сцену хотя бы частично. Только 100% рабочих и анимированных в стиле Live2D я не нашёл, да и мне хочется самому велосипед сделать, а не натягивать спрайты на чужую модель. Вдохновил образец в библиотеке ассетов, но там анимаций почти нет, а вся рутина заключается именно в анимациях - склеить модельку из спрайтов ничего не стоит по сравнению с попытками правильно анимировать.
В конечном итоге хочу получить живые обои на смартфон или хотя бы мини-игрушку, чтобы можно было потыкать пальцем и получить реакцию. Много лет играюсь с одной такой моделькой на базе Live2D, перенося её со смартфона на смартфон, и давно хотел сделать что-то похожее, но мне не хотелось изучать Live2D или аналоги (они все платные и на японском с уродским гуем а-ля юнити, а использовать результат работы нужно в каком-то движке - и, конечно, официально они только юнити поддерживают, а под Godot никаких разработок я не видел).
Что я узнал/понял на данный момент:
0. Визуальный редактор Polygon2D явно не доделан до комфортного состояния: зум в левый верхний угол, в случае ошибки нельзя откатиться на одну точку назад (как можно, например, в Inkscape, нажав ПКМ) и нельзя добавить/удалить точки в уже законченном полигоне - только начинать с нуля или двигать уже имеющиеся, либо добавить "внутренние точки" и делать свои собственные полигоны. Это всё неудобно, но терпимо. Также триангуляция по умолчанию плохо деформирует спрайт, но об этом в документации написано, нужно просто кастомные полигоны делать (рутина, но это как раз сделано достаточно удобно, просто тыкаешь точки и всё).
1. Функций Godot достаточно для создания анимаций в этом стиле. В худшем случае нужно будет смешать 2D с 3D в одной модели через вьюпорты - это следствие того, что у нас в 2D рендерере вращение только по одной оси Z, а в Live2D вроде бы по всем осям можно (?), либо можно сымитировать вращение, добавив больше костей. Главный недостаток в том, что Godot существует сам по себе, а модели из Live2D можно в самых разных программах использовать. Но для меня это не проблема.
2. Не знаю, как делают в Live2D (сам не пробовал), но некоторые вещи через анимации в Godot делать сложно, однако, на GDScript такие вещи решаются легко. Вот, скажем, поворот головы я сделал как 4 анимации по одному кадру, которые комбинируются в BlendSpace2D, но Z-order ушей таким способом настроить сложно, поэтому управляю ушами через код. Костыльно, но какие альтернативы? Если я в анимации меняю bool или +1/-1 по Z, то BlendSpace2D не интерполирует как я хочу и не даёт точной настройки интерполяции. Делать отдельные анимации под уши я не хочу, это всё усложнит и увеличит количество рутины, поэтому решил пока костыльнуть через код, там буквально одна строчка под каждое ухо. Скриптить модель в любом случае придётся, поскольку я хочу дать ей процедурное поведение - поэтому BlendSpace2D, а не простые анимации.
3. Очень много рутины. В идеале, для правильной интерполяции поворотов головы, нужно 8 анимаций, по одной на каждую сторону и ещё диагонали. Костей уже сейчас много, а будет ещё больше, т.к. волосы я пока даже не рисовал. При этом противоположные анимации должны быть симметричными, иначе будет фигня. Выворачивать спрайты по X/Y не вариант, т.к. лицо изначально может быть асимметричным (представьте себе глаза разного цвета или монокль - отражать такое не вариант). Сначала думал вручную сделать, но теперь пишу tool скрипт для автоматического отражения заданных анимаций - тогда мне нужно будет сделать в 2 или даже 4 раза меньше работы, и получить гарантированно точный результат. По понятным причинам такой утилиты из коробки в движке никогда не будет - она слишком специфична. Да и я уже не уверен, что мой скрипт что-то решит, т.к. если кости расположены не симметрично, то всё равно вручную править каждую из сторон придётся. Но, мне кажется, в Live2D рутины не сильно меньше, по скриншотам там очень сложный GUI и настроек много, по обсуждениям - они там часами возятся для тривиальной анимации, лол.
4. Готовая сцена имеет низкую реюзабельность, т.к. если другой персонаж имеет что-то другое в геометрии лица, то правок не избежать. Но в целом, по идее, можно переиспользовать готовую сцену хотя бы частично. Только 100% рабочих и анимированных в стиле Live2D я не нашёл, да и мне хочется самому велосипед сделать, а не натягивать спрайты на чужую модель. Вдохновил образец в библиотеке ассетов, но там анимаций почти нет, а вся рутина заключается именно в анимациях - склеить модельку из спрайтов ничего не стоит по сравнению с попытками правильно анимировать.
В конечном итоге хочу получить живые обои на смартфон или хотя бы мини-игрушку, чтобы можно было потыкать пальцем и получить реакцию. Много лет играюсь с одной такой моделькой на базе Live2D, перенося её со смартфона на смартфон, и давно хотел сделать что-то похожее, но мне не хотелось изучать Live2D или аналоги (они все платные и на японском с уродским гуем а-ля юнити, а использовать результат работы нужно в каком-то движке - и, конечно, официально они только юнити поддерживают, а под Godot никаких разработок я не видел).
Второй день делаю свою 2D вайфу в стиле Live2D, используя лишь встроенные возможности Godot.
Что я узнал/понял на данный момент:
0. Визуальный редактор Polygon2D явно не доделан до комфортного состояния: зум в левый верхний угол, в случае ошибки нельзя откатиться на одну точку назад (как можно, например, в Inkscape, нажав ПКМ) и нельзя добавить/удалить точки в уже законченном полигоне - только начинать с нуля или двигать уже имеющиеся, либо добавить "внутренние точки" и делать свои собственные полигоны. Это всё неудобно, но терпимо. Также триангуляция по умолчанию плохо деформирует спрайт, но об этом в документации написано, нужно просто кастомные полигоны делать (рутина, но это как раз сделано достаточно удобно, просто тыкаешь точки и всё).
1. Функций Godot достаточно для создания анимаций в этом стиле. В худшем случае нужно будет смешать 2D с 3D в одной модели через вьюпорты - это следствие того, что у нас в 2D рендерере вращение только по одной оси Z, а в Live2D вроде бы по всем осям можно (?), либо можно сымитировать вращение, добавив больше костей. Главный недостаток в том, что Godot существует сам по себе, а модели из Live2D можно в самых разных программах использовать. Но для меня это не проблема.
2. Не знаю, как делают в Live2D (сам не пробовал), но некоторые вещи через анимации в Godot делать сложно, однако, на GDScript такие вещи решаются легко. Вот, скажем, поворот головы я сделал как 4 анимации по одному кадру, которые комбинируются в BlendSpace2D, но Z-order ушей таким способом настроить сложно, поэтому управляю ушами через код. Костыльно, но какие альтернативы? Если я в анимации меняю bool или +1/-1 по Z, то BlendSpace2D не интерполирует как я хочу и не даёт точной настройки интерполяции. Делать отдельные анимации под уши я не хочу, это всё усложнит и увеличит количество рутины, поэтому решил пока костыльнуть через код, там буквально одна строчка под каждое ухо. Скриптить модель в любом случае придётся, поскольку я хочу дать ей процедурное поведение - поэтому BlendSpace2D, а не простые анимации.
3. Очень много рутины. В идеале, для правильной интерполяции поворотов головы, нужно 8 анимаций, по одной на каждую сторону и ещё диагонали. Костей уже сейчас много, а будет ещё больше, т.к. волосы я пока даже не рисовал. При этом противоположные анимации должны быть симметричными, иначе будет фигня. Выворачивать спрайты по X/Y не вариант, т.к. лицо изначально может быть асимметричным (представьте себе глаза разного цвета или монокль - отражать такое не вариант). Сначала думал вручную сделать, но теперь пишу tool скрипт для автоматического отражения заданных анимаций - тогда мне нужно будет сделать в 2 или даже 4 раза меньше работы, и получить гарантированно точный результат. По понятным причинам такой утилиты из коробки в движке никогда не будет - она слишком специфична. Да и я уже не уверен, что мой скрипт что-то решит, т.к. если кости расположены не симметрично, то всё равно вручную править каждую из сторон придётся. Но, мне кажется, в Live2D рутины не сильно меньше, по скриншотам там очень сложный GUI и настроек много, по обсуждениям - они там часами возятся для тривиальной анимации, лол.
4. Готовая сцена имеет низкую реюзабельность, т.к. если другой персонаж имеет что-то другое в геометрии лица, то правок не избежать. Но в целом, по идее, можно переиспользовать готовую сцену хотя бы частично. Только 100% рабочих и анимированных в стиле Live2D я не нашёл, да и мне хочется самому велосипед сделать, а не натягивать спрайты на чужую модель. Вдохновил образец в библиотеке ассетов, но там анимаций почти нет, а вся рутина заключается именно в анимациях - склеить модельку из спрайтов ничего не стоит по сравнению с попытками правильно анимировать.
В конечном итоге хочу получить живые обои на смартфон или хотя бы мини-игрушку, чтобы можно было потыкать пальцем и получить реакцию. Много лет играюсь с одной такой моделькой на базе Live2D, перенося её со смартфона на смартфон, и давно хотел сделать что-то похожее, но мне не хотелось изучать Live2D или аналоги (они все платные и на японском с уродским гуем а-ля юнити, а использовать результат работы нужно в каком-то движке - и, конечно, официально они только юнити поддерживают, а под Godot никаких разработок я не видел).
Что я узнал/понял на данный момент:
0. Визуальный редактор Polygon2D явно не доделан до комфортного состояния: зум в левый верхний угол, в случае ошибки нельзя откатиться на одну точку назад (как можно, например, в Inkscape, нажав ПКМ) и нельзя добавить/удалить точки в уже законченном полигоне - только начинать с нуля или двигать уже имеющиеся, либо добавить "внутренние точки" и делать свои собственные полигоны. Это всё неудобно, но терпимо. Также триангуляция по умолчанию плохо деформирует спрайт, но об этом в документации написано, нужно просто кастомные полигоны делать (рутина, но это как раз сделано достаточно удобно, просто тыкаешь точки и всё).
1. Функций Godot достаточно для создания анимаций в этом стиле. В худшем случае нужно будет смешать 2D с 3D в одной модели через вьюпорты - это следствие того, что у нас в 2D рендерере вращение только по одной оси Z, а в Live2D вроде бы по всем осям можно (?), либо можно сымитировать вращение, добавив больше костей. Главный недостаток в том, что Godot существует сам по себе, а модели из Live2D можно в самых разных программах использовать. Но для меня это не проблема.
2. Не знаю, как делают в Live2D (сам не пробовал), но некоторые вещи через анимации в Godot делать сложно, однако, на GDScript такие вещи решаются легко. Вот, скажем, поворот головы я сделал как 4 анимации по одному кадру, которые комбинируются в BlendSpace2D, но Z-order ушей таким способом настроить сложно, поэтому управляю ушами через код. Костыльно, но какие альтернативы? Если я в анимации меняю bool или +1/-1 по Z, то BlendSpace2D не интерполирует как я хочу и не даёт точной настройки интерполяции. Делать отдельные анимации под уши я не хочу, это всё усложнит и увеличит количество рутины, поэтому решил пока костыльнуть через код, там буквально одна строчка под каждое ухо. Скриптить модель в любом случае придётся, поскольку я хочу дать ей процедурное поведение - поэтому BlendSpace2D, а не простые анимации.
3. Очень много рутины. В идеале, для правильной интерполяции поворотов головы, нужно 8 анимаций, по одной на каждую сторону и ещё диагонали. Костей уже сейчас много, а будет ещё больше, т.к. волосы я пока даже не рисовал. При этом противоположные анимации должны быть симметричными, иначе будет фигня. Выворачивать спрайты по X/Y не вариант, т.к. лицо изначально может быть асимметричным (представьте себе глаза разного цвета или монокль - отражать такое не вариант). Сначала думал вручную сделать, но теперь пишу tool скрипт для автоматического отражения заданных анимаций - тогда мне нужно будет сделать в 2 или даже 4 раза меньше работы, и получить гарантированно точный результат. По понятным причинам такой утилиты из коробки в движке никогда не будет - она слишком специфична. Да и я уже не уверен, что мой скрипт что-то решит, т.к. если кости расположены не симметрично, то всё равно вручную править каждую из сторон придётся. Но, мне кажется, в Live2D рутины не сильно меньше, по скриншотам там очень сложный GUI и настроек много, по обсуждениям - они там часами возятся для тривиальной анимации, лол.
4. Готовая сцена имеет низкую реюзабельность, т.к. если другой персонаж имеет что-то другое в геометрии лица, то правок не избежать. Но в целом, по идее, можно переиспользовать готовую сцену хотя бы частично. Только 100% рабочих и анимированных в стиле Live2D я не нашёл, да и мне хочется самому велосипед сделать, а не натягивать спрайты на чужую модель. Вдохновил образец в библиотеке ассетов, но там анимаций почти нет, а вся рутина заключается именно в анимациях - склеить модельку из спрайтов ничего не стоит по сравнению с попытками правильно анимировать.
В конечном итоге хочу получить живые обои на смартфон или хотя бы мини-игрушку, чтобы можно было потыкать пальцем и получить реакцию. Много лет играюсь с одной такой моделькой на базе Live2D, перенося её со смартфона на смартфон, и давно хотел сделать что-то похожее, но мне не хотелось изучать Live2D или аналоги (они все платные и на японском с уродским гуем а-ля юнити, а использовать результат работы нужно в каком-то движке - и, конечно, официально они только юнити поддерживают, а под Godot никаких разработок я не видел).
>>69016
Че? Шифт + скролл горизонтально стандарт практически везде.
Неестественное напряжение мышц среднего пальца сбивает точность. Хотя, просто в пане это может быть не критично. Хуже, когда на среднюю+drag вешают что то важное, типа перемещения вертексов, вот тут обычно такая кривизна начинается.
>по вертикали крутишь колесо, а по горизонтали отдельные костыли используешь.
Че? Шифт + скролл горизонтально стандарт практически везде.
>Да и в чём проблема зажать колёсико?
Неестественное напряжение мышц среднего пальца сбивает точность. Хотя, просто в пане это может быть не критично. Хуже, когда на среднюю+drag вешают что то важное, типа перемещения вертексов, вот тут обычно такая кривизна начинается.
>>69114
Самый популярный и самый тупой КОСТЫЛЬ, я никогда не мог его понять. Зачем мне вообще мышь нужна, если клавиатуру использовать заставляют вместе с ней? Я бы мог просто на клавиатуре стрелочки нажимать (одной рукой!), но раз уж я взял в руку мышь... Как я одной рукой буду и мышь крутить, и контрл нажимать? Т.е. этот костыль вынуждает использовать две руки для единственной операции, если у тебя не геймерская мышь с десятком кнопок под любые хоткеи. Нет, я не однорукий инвалид, но не понимаю, зачем раскладывать одно действие (сдвиг рабочего стола на 2D вектор) на две руки, когда можно обойтись без этого, освободив вторую руку (считай, половину мозга) для других, независимых операций. Крайне раздражает этот костыль.
Средний палец - для правой кнопки, а указательный палец - для левой кнопки и колёсика. Никакого напряжения нет (с разными мышами пробовал). Или ты сразу три пальца задействуешь, нажимая ПКМ безымянным? Никогда не думал, что кто-то так делает, пальцы же мешать друг другу будут и средним колёсико крутить неудобно...
Это другое, очевидно, что на ЛКМ двигаешь предметы, СКМ двигаешь "стол" со всем, что на нём есть, ПКМ вращаешь камеру, отменяешь операции и т.п.
>Шифт + скролл горизонтально
Самый популярный и самый тупой КОСТЫЛЬ, я никогда не мог его понять. Зачем мне вообще мышь нужна, если клавиатуру использовать заставляют вместе с ней? Я бы мог просто на клавиатуре стрелочки нажимать (одной рукой!), но раз уж я взял в руку мышь... Как я одной рукой буду и мышь крутить, и контрл нажимать? Т.е. этот костыль вынуждает использовать две руки для единственной операции, если у тебя не геймерская мышь с десятком кнопок под любые хоткеи. Нет, я не однорукий инвалид, но не понимаю, зачем раскладывать одно действие (сдвиг рабочего стола на 2D вектор) на две руки, когда можно обойтись без этого, освободив вторую руку (считай, половину мозга) для других, независимых операций. Крайне раздражает этот костыль.
>мышц среднего пальца
Средний палец - для правой кнопки, а указательный палец - для левой кнопки и колёсика. Никакого напряжения нет (с разными мышами пробовал). Или ты сразу три пальца задействуешь, нажимая ПКМ безымянным? Никогда не думал, что кто-то так делает, пальцы же мешать друг другу будут и средним колёсико крутить неудобно...
>перемещения вертексов
Это другое, очевидно, что на ЛКМ двигаешь предметы, СКМ двигаешь "стол" со всем, что на нём есть, ПКМ вращаешь камеру, отменяешь операции и т.п.
>>69120
Уверен, что у большинства все же левый палец на лкм, а средний - на пкм либо колесике.
Уверен, что у большинства все же левый палец на лкм, а средний - на пкм либо колесике.
Аноны, как сделать, чтобы контрол нод с большим z индексом получал инпут ивенты вперед тех, у кого этот индекс меньше?
а draw_line она один раз на текстуре нарисует или создаст правило, чтобы потом каждый кадр это рисовать?
если я у контрола рисую draw_line, то он мне размер текстуры расширяет?
если я у контрола рисую draw_line, то он мне размер текстуры расширяет?
>>69123
нет, на колесике тоже указательный
> Уверен, что у большинства все же левый палец на лкм, а средний - на пкм либо колесике.
нет, на колесике тоже указательный
Бля, я что-то сломал и теперь режим тренировки не тренит NN, когда его выключаешь они просто едут в стену. А генетический вариант не так интересен.
Но это уже не для треда вопросы я думаю.
Ну и хуй с ней, придумаю другое занятие. Или нихуя не буду делать полгода, как до этого.
Но это уже не для треда вопросы я думаю.
Ну и хуй с ней, придумаю другое занятие. Или нихуя не буду делать полгода, как до этого.
>>67818
ЕБАТЬ НАХУЙ! Истина! Как я ахуеваю с этих, блять, Оксфордо-Гарвардских лекций по 300 часов+ на одну только тему переменных. Ебать, прежде, чем что-то выучить, заебешься искать норм атериал, чтоб приятно было слушать, строго по делу, ясно, понятно и КОРОТКО. Учил тот же Питон по Лутцу, чуть не захлебнулся от воды и занудности. Пошел на ютуб, там лекции о переменных в питоне по 2 часа. Да ебать. Такие занудные, унылые ебанаты только отбивают желание что-либо учить. Заикающимся голсоом умирающего лебедя чё-то бормочет себе под нос три часа. Я хуею с долбоебов.
P. S. Мани, которые хотят таких защитить, высрав что-то типа "ну-ну, учи свои 5-минутные уроки, поверхностно всё нахватаешь и нихуя знать не будешь". Да нихуя. От того что два человека отвечают на один вопрос по-разному - нихуя не меняется. К примеру, спрашивают "Сколько букв в слове ХУЙ?"
1. Один отвечает "Три".
2. А второй начинает заикаться, пердеть, сморкаться, пошел поссать на пару минут, потом в тетрадку заглянул, потом начал кукарекать "В слове ХУЙ содержится три буквы русского алфавита - Х, У, Й".
Пиздец, я вторую категорию в рот ебал. Обмороки хуевы. Нахуя так растягивать то, что можно за сотую долю секунды ответить и всё? Если мне, потом, что-то понадобится более углубленно изучить - я изучу, уже сам, на интересе. Я сразу хочу принимать активное участие и набивать руку, видеть маленькие результаты своих действий, программировать, а не слушать об оттенках интерфейса Годот или Visaual Studio Code, целых полгода, по три часа в день. Типа, блять, ПОЛНЫЙ КУРС. Настоящий мастер объясняет коротко и ясно, и понятно, а не рассусоливает 2+2=4 на месяц.
ЕБАТЬ НАХУЙ! Истина! Как я ахуеваю с этих, блять, Оксфордо-Гарвардских лекций по 300 часов+ на одну только тему переменных. Ебать, прежде, чем что-то выучить, заебешься искать норм атериал, чтоб приятно было слушать, строго по делу, ясно, понятно и КОРОТКО. Учил тот же Питон по Лутцу, чуть не захлебнулся от воды и занудности. Пошел на ютуб, там лекции о переменных в питоне по 2 часа. Да ебать. Такие занудные, унылые ебанаты только отбивают желание что-либо учить. Заикающимся голсоом умирающего лебедя чё-то бормочет себе под нос три часа. Я хуею с долбоебов.
P. S. Мани, которые хотят таких защитить, высрав что-то типа "ну-ну, учи свои 5-минутные уроки, поверхностно всё нахватаешь и нихуя знать не будешь". Да нихуя. От того что два человека отвечают на один вопрос по-разному - нихуя не меняется. К примеру, спрашивают "Сколько букв в слове ХУЙ?"
1. Один отвечает "Три".
2. А второй начинает заикаться, пердеть, сморкаться, пошел поссать на пару минут, потом в тетрадку заглянул, потом начал кукарекать "В слове ХУЙ содержится три буквы русского алфавита - Х, У, Й".
Пиздец, я вторую категорию в рот ебал. Обмороки хуевы. Нахуя так растягивать то, что можно за сотую долю секунды ответить и всё? Если мне, потом, что-то понадобится более углубленно изучить - я изучу, уже сам, на интересе. Я сразу хочу принимать активное участие и набивать руку, видеть маленькие результаты своих действий, программировать, а не слушать об оттенках интерфейса Годот или Visaual Studio Code, целых полгода, по три часа в день. Типа, блять, ПОЛНЫЙ КУРС. Настоящий мастер объясняет коротко и ясно, и понятно, а не рассусоливает 2+2=4 на месяц.
>>69271
закрой для себя мир видео и открой мир письменности. начни с туториалов.
ты ахуеешь конда поймешь что в тексте НЕВОЗМОЖНО гундеть, пердеть, мямлить и отходить поссать :) просто косом по сравнению с ютьюбным байтом для начинающих даунов
закрой для себя мир видео и открой мир письменности. начни с туториалов.
ты ахуеешь конда поймешь что в тексте НЕВОЗМОЖНО гундеть, пердеть, мямлить и отходить поссать :) просто косом по сравнению с ютьюбным байтом для начинающих даунов
>>69274
В чем и почему?
В чем и почему?
>>69288
Все работает и веса меняются, но не устаканиваются, может мало держу, хз. Тренится по ходу.
Все работает и веса меняются, но не устаканиваются, может мало держу, хз. Тренится по ходу.
>>69256
Чего не можешь? Рисовать? Анимировать?
Тащемто я уже забил на этот проект по причине того, что слишком много рутины, автоматизировать которую... ещё больше рутины.
Я думаю, нужно вообще отказаться от анимаций и управлять скелетом чисто процедурно, из кода. Анимационная система лучше подходит для каких-то захардкоженных вещей, а повороты головы в Live2D делаются скелетом, это не анимации. Я просто не нашёл способа сделать так, чтобы голова поворачивалась единственной костью...
Обычный 2D скелет подразумевает, что связанные друг с другом кости наследуют смещение, масштаб и поворот. Но Live2D моделька подразумевает, что зависящие кости могут смещаться и масштабироваться нелинейно, по каким-то заданным формулам (вроде того, что при повороте головы налево левый глаз должен слегка сжиматься по горизонтали, имитируя 3D перспективу). Я не нашёл способа задать эти формулы в Godot, кроме как писать скрипт на GDScript или использовать BlendSpace2D между несколькими заданными положениями...
>Жаль что я не могу так же...
Чего не можешь? Рисовать? Анимировать?
Тащемто я уже забил на этот проект по причине того, что слишком много рутины, автоматизировать которую... ещё больше рутины.
Я думаю, нужно вообще отказаться от анимаций и управлять скелетом чисто процедурно, из кода. Анимационная система лучше подходит для каких-то захардкоженных вещей, а повороты головы в Live2D делаются скелетом, это не анимации. Я просто не нашёл способа сделать так, чтобы голова поворачивалась единственной костью...
Обычный 2D скелет подразумевает, что связанные друг с другом кости наследуют смещение, масштаб и поворот. Но Live2D моделька подразумевает, что зависящие кости могут смещаться и масштабироваться нелинейно, по каким-то заданным формулам (вроде того, что при повороте головы налево левый глаз должен слегка сжиматься по горизонтали, имитируя 3D перспективу). Я не нашёл способа задать эти формулы в Godot, кроме как писать скрипт на GDScript или использовать BlendSpace2D между несколькими заданными положениями...
>>69253
Мне кажется, никак. Порядок получения событий зависит от порядка в дереве сцены, а не Z индекса.
https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html#how-does-it-work
>>69261
Если ты реализуешь свой метод _draw:
1. Твой код выполняется единожды после каждого update, после чего результат кэшируется и твой метод не выполняется, но картинка рисуется.
2. Если тебе нужно сместить что-то на рисунке, тебе нужно вызывать update принудительно, только тогда твой код в _draw сможет изменить картинку.
3. Если у тебя очень сложная графика в _draw, несмотря на кэширование, она будет сильно тормозить игру; для оптимизации используй вьюпорты.
Чего? У тебя нет никакой текстуры. Контрол рисует не на текстуре, а прямо поверх экрана. Поэтому тебе нужно использовать вьюпорты, если ты планируешь рисовать очень много всего.
Узнал об этом опытным путём на 3.x, рисуя карту.
>получал инпут ивенты вперед
Мне кажется, никак. Порядок получения событий зависит от порядка в дереве сцены, а не Z индекса.
https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html#how-does-it-work
>>69261
>draw_line она один раз на текстуре нарисует или создаст правило, чтобы потом каждый кадр это рисовать?
Если ты реализуешь свой метод _draw:
1. Твой код выполняется единожды после каждого update, после чего результат кэшируется и твой метод не выполняется, но картинка рисуется.
2. Если тебе нужно сместить что-то на рисунке, тебе нужно вызывать update принудительно, только тогда твой код в _draw сможет изменить картинку.
3. Если у тебя очень сложная графика в _draw, несмотря на кэширование, она будет сильно тормозить игру; для оптимизации используй вьюпорты.
>если я у контрола рисую draw_line, то он мне размер текстуры расширяет?
Чего? У тебя нет никакой текстуры. Контрол рисует не на текстуре, а прямо поверх экрана. Поэтому тебе нужно использовать вьюпорты, если ты планируешь рисовать очень много всего.
Узнал об этом опытным путём на 3.x, рисуя карту.
>>69271 >>69284
В предыдущем треде обсуждали, почему видео-"уроки" - УГ, служащее только для развлечения школоты и набивания карманов "преподавателей".
Такое ощущение, что кому-то по фану было сидеть за партой в школе, поэтому они так сильно стремятся смотреть видосики, где какой-то хрен светит своей мордой на камеру и чё-то там бормочет.
Если бы я хотел посмотреть на твою морду, я пошёл бы в соцсеть какую-нибудь, где ты высрал целый альбом со своей унылой мордой... Почему так много видео, где автор светит лицом на вебку? Возмутительно, как будто силой на нудистский пляж притащили.
В предыдущем треде обсуждали, почему видео-"уроки" - УГ, служащее только для развлечения школоты и набивания карманов "преподавателей".
Такое ощущение, что кому-то по фану было сидеть за партой в школе, поэтому они так сильно стремятся смотреть видосики, где какой-то хрен светит своей мордой на камеру и чё-то там бормочет.
Если бы я хотел посмотреть на твою морду, я пошёл бы в соцсеть какую-нибудь, где ты высрал целый альбом со своей унылой мордой... Почему так много видео, где автор светит лицом на вебку? Возмутительно, как будто силой на нудистский пляж притащили.
>>69319
По очень прагматичной причине. Если ты будешь стримить только разработку, то есть только экран годота, то среди потока всех видео будет непонятно кто именно стримит, ничем не выделишься среди превьюшек видосов. Короче, создается привязка что именно некто тебя учит, и зритель потом идет именно к этому автору. Плюс еще конечно если нормальная мимика и зритель не аутист, то создается эмоциональный отклик, что рассказывает живой человек, используется невербальное общение - если что-то не получилось, ты увидешь как он покачает головой.
Конечно, некоторые ставят аниме кошкодевочек на аватарку, но тут можно нарваться на анимехейтеров или собачников
По очень прагматичной причине. Если ты будешь стримить только разработку, то есть только экран годота, то среди потока всех видео будет непонятно кто именно стримит, ничем не выделишься среди превьюшек видосов. Короче, создается привязка что именно некто тебя учит, и зритель потом идет именно к этому автору. Плюс еще конечно если нормальная мимика и зритель не аутист, то создается эмоциональный отклик, что рассказывает живой человек, используется невербальное общение - если что-то не получилось, ты увидешь как он покачает головой.
Конечно, некоторые ставят аниме кошкодевочек на аватарку, но тут можно нарваться на анимехейтеров или собачников
>>69302
Не могу кодить
Не могу кодить
>>69320
Как будто так трудно нарисовать превьюшку со своим логотипом.
>>69319
Один шиз высрал тезис о каких-то там ютуберах с монетизацией, на что ему ответили, что большинство каналов с годотоуроками на 1к подписоты и в среднем 300 просмотрами делаются из чистого альтруизма. На самых крупных каналах есть патреон, но там тоже капает максимум баксов 50 в месяц.
>ничем не выделишься среди превьюшек видосов
Как будто так трудно нарисовать превьюшку со своим логотипом.
>>69319
>В предыдущем треде обсуждали
Один шиз высрал тезис о каких-то там ютуберах с монетизацией, на что ему ответили, что большинство каналов с годотоуроками на 1к подписоты и в среднем 300 просмотрами делаются из чистого альтруизма. На самых крупных каналах есть патреон, но там тоже капает максимум баксов 50 в месяц.
>>69306
просто мне кажется, что когда я вызывают что-то около сотни draw_line() у control-а, то он как будто каждый их рисует, потому что это начинает тормозить
а второе предположение было, что он их рисует и кеширует текстуру, потому что если рисовать что-то в гораздо больших координатах, то оно тоже тормозит, вот и ищу причину в чем именно эти тормоза
ведь получается, что если он единожды вызывает, то значит кеширует текстуру, значит если сильно за пределами рисовать, то и получается, что большую хранить начинает и идут лаги
просто мне кажется, что когда я вызывают что-то около сотни draw_line() у control-а, то он как будто каждый их рисует, потому что это начинает тормозить
а второе предположение было, что он их рисует и кеширует текстуру, потому что если рисовать что-то в гораздо больших координатах, то оно тоже тормозит, вот и ищу причину в чем именно эти тормоза
ведь получается, что если он единожды вызывает, то значит кеширует текстуру, значит если сильно за пределами рисовать, то и получается, что большую хранить начинает и идут лаги
>>69366
Про display list в OpenGL знаешь?
http://www.songho.ca/opengl/gl_displaylist.html
Вот _draw в Godot делает что-то похожее по сути. Движок вызывает твой код, и сохраняет последовательность команд, которые твой код запрашивает. Дальше твой код не выполняется повторно - вместо него выполняется некая последовательность команд, сформированная движком. Каждый кадр. С одной стороны, это экономно для простых рисунков, которые можно неограниченно масштабировать (т.к. рисунок векторный, без растрирования в текстуру), но когда ты запрашиваешь сотни команд за один _draw, это бьёт по производительности и поэтому требует оптимизации путём рендеринга в текстуру.
Почему Godot не оптимизирует _draw через текстуру вместо нас? Потому что в простом случае необходимости в текстуре нет, а когда необходимость появляется, нельзя заранее предугадать необходимый размер и параметры текстуры - пусть лучше разработчик игры сам всё настроит.
Но это всё мои предположения. Нужно идти смотреть исходники на гитхабе и искать обсуждения, если тебе нужно знать точно, как это всё работает и почему.
Про display list в OpenGL знаешь?
http://www.songho.ca/opengl/gl_displaylist.html
Вот _draw в Godot делает что-то похожее по сути. Движок вызывает твой код, и сохраняет последовательность команд, которые твой код запрашивает. Дальше твой код не выполняется повторно - вместо него выполняется некая последовательность команд, сформированная движком. Каждый кадр. С одной стороны, это экономно для простых рисунков, которые можно неограниченно масштабировать (т.к. рисунок векторный, без растрирования в текстуру), но когда ты запрашиваешь сотни команд за один _draw, это бьёт по производительности и поэтому требует оптимизации путём рендеринга в текстуру.
Почему Godot не оптимизирует _draw через текстуру вместо нас? Потому что в простом случае необходимости в текстуре нет, а когда необходимость появляется, нельзя заранее предугадать необходимый размер и параметры текстуры - пусть лучше разработчик игры сам всё настроит.
Но это всё мои предположения. Нужно идти смотреть исходники на гитхабе и искать обсуждения, если тебе нужно знать точно, как это всё работает и почему.
>>69418
а как еще рисовать способы есть, кроме put_pixel у имеджей? только там свои алгоритмы для линий накидать нужно будет, но должно точно тогда экономнее быть, хоть и изначально дольше строить
а как еще рисовать способы есть, кроме put_pixel у имеджей? только там свои алгоритмы для линий накидать нужно будет, но должно точно тогда экономнее быть, хоть и изначально дольше строить
Возвращаюсь в разработку, смотрю чего нового.
Zylann не будет портировать Heightmap terrain в 4.
Он сосредоточится на воксельном террейне.
Под 3 сделали еще один террейн: https://github.com/ozzr/godot_terrain
Под 4 хотят сделать официальный плагин, но который не будет частью движка.
Предложение здесь https://github.com/godotengine/godot-proposals/issues/6121 кажется, Хуан просто описал фичи зиланновского
Репа, кажется эта https://github.com/outobugi/Terrain3D
Zylann не будет портировать Heightmap terrain в 4.
Он сосредоточится на воксельном террейне.
Под 3 сделали еще один террейн: https://github.com/ozzr/godot_terrain
Под 4 хотят сделать официальный плагин, но который не будет частью движка.
Предложение здесь https://github.com/godotengine/godot-proposals/issues/6121 кажется, Хуан просто описал фичи зиланновского
Репа, кажется эта https://github.com/outobugi/Terrain3D
>>69434
угу, тоже хотим в этот проект вписаться, чтобы релизнулся
угу, тоже хотим в этот проект вписаться, чтобы релизнулся
Пидорский движок обновился сам до версии 4.0 и сломал мне все нахуй. Как вернуть все назад?
>>69466
Подстава конечно. Поэтому просто скачивай с сайта нужную версию. Ему же не нужна установка.
Подстава конечно. Поэтому просто скачивай с сайта нужную версию. Ему же не нужна установка.
>>69463
ну если ты такой криворукий, что даже не можешь скачать предыдущую версию движка, то тебе стоит оплатить услуги программиста
> Пидорский движок обновился сам до версии 4.0 и сломал мне все нахуй. Как вернуть все назад?
ну если ты такой криворукий, что даже не можешь скачать предыдущую версию движка, то тебе стоит оплатить услуги программиста
>>69424
1. Создаёшь SubViewport и настраиваешь.
2. Добавляешь в него свой Control с _draw.
3. Вьюпорту ставишь параметр UPDATE_ONCE:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html#class-subviewport-property-render-target-update-mode
4. Получаешь текстуру, которую можешь использовать как любую обычную текстуру.
>а как еще рисовать
>экономнее
1. Создаёшь SubViewport и настраиваешь.
2. Добавляешь в него свой Control с _draw.
3. Вьюпорту ставишь параметр UPDATE_ONCE:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html#class-subviewport-property-render-target-update-mode
4. Получаешь текстуру, которую можешь использовать как любую обычную текстуру.
Так, всё, террейн в годоте уже изобрели, нужно что-то другое придумать, чтобы оригинально было...
снова забил на игру и прокрастинирую
снова забил на игру и прокрастинирую
55 Кб, 636x725>>69504
На пикриле я, после нескольких лет ковыряния в прототипах игры мечты, думаю о том, что пора начинать с чистого листа... снова.
Прощайте, увидимся завтра.
На пикриле я, после нескольких лет ковыряния в прототипах игры мечты, думаю о том, что пора начинать с чистого листа... снова.
Прощайте, увидимся завтра.
>>69319
>>69284
Годотеры, уважаю вас, братва, но не порите хуйни. Видео-уркои нужны и видео-уркои ВАЖНЫ. Бывает сталкиваешься с какой-то вещью, которую никак сам не поймешь, че и как. И прочел кучу материала уже, но просто врубаешь ролик, там в две секунды показывают куда и че нажать, и как прописать и всё сразу ясно. Сам я ща прочел офф.документацию по созданию 2Д-платформера и после чтения и самотыкания в годоте всей этой хуйни, я пошел смотреть уркои на ютубе по 2Д-платформерам, и читать статьи на других сайтах, чтоб посмотреть как другие это делают, че добавляют, как усложняют игру и т.д. и т.д.. А офф.документалка стала отправной точкой.
>>69284
Годотеры, уважаю вас, братва, но не порите хуйни. Видео-уркои нужны и видео-уркои ВАЖНЫ. Бывает сталкиваешься с какой-то вещью, которую никак сам не поймешь, че и как. И прочел кучу материала уже, но просто врубаешь ролик, там в две секунды показывают куда и че нажать, и как прописать и всё сразу ясно. Сам я ща прочел офф.документацию по созданию 2Д-платформера и после чтения и самотыкания в годоте всей этой хуйни, я пошел смотреть уркои на ютубе по 2Д-платформерам, и читать статьи на других сайтах, чтоб посмотреть как другие это делают, че добавляют, как усложняют игру и т.д. и т.д.. А офф.документалка стала отправной точкой.
16 Кб, 1157x39Предупреждения в 4 такие же обскурные, как и в 3 бывали.
2,5 Мб, 1920x1080Ну что, перекатываюсь потихоньку.
2,4 Мб, 1920x1080>>69548
В общем, чуда с вулканом не произошло.
Травка убивает фпс, но и просто куча пбр объектов даже с 512 текстурами и выключенным VoxelGI
Причем вулкан ведет себя очень странно. Он работает секунду быстро, до 24 фпс, а потом секунду висит, не понятно что он там делает, взад вперед загружает все что ли.
На этом переходить на 4.0 я передумал, на 3.5 у меня получше результаты.
В общем, чуда с вулканом не произошло.
Травка убивает фпс, но и просто куча пбр объектов даже с 512 текстурами и выключенным VoxelGI
Причем вулкан ведет себя очень странно. Он работает секунду быстро, до 24 фпс, а потом секунду висит, не понятно что он там делает, взад вперед загружает все что ли.
На этом переходить на 4.0 я передумал, на 3.5 у меня получше результаты.
>>69463
Ну так в стиме можно выбирать версии в ручную же, через настройку. А у меня кста в стиме он сам не обновился и пришлось самому в настройках ставить 4 версию.
Ну так в стиме можно выбирать версии в ручную же, через настройку. А у меня кста в стиме он сам не обновился и пришлось самому в настройках ставить 4 версию.
>>69552
А я передумал переходить на четвёрку, когда она попортила сцену, от которой наследовали другие сцены. Хорошо, что это был всего лишь тестовый проект, чтобы разобраться в нововведениях.
>На этом переходить на 4.0 я передумал
А я передумал переходить на четвёрку, когда она попортила сцену, от которой наследовали другие сцены. Хорошо, что это был всего лишь тестовый проект, чтобы разобраться в нововведениях.
>>69623
Уже после беты? Ну, так то обычно сцену легко исправить. Это текстовый файл, можно руками что-то переписать, можно сравнивать изменения с прошлыми версиями, если вести проект в гите.
Уже после беты? Ну, так то обычно сцену легко исправить. Это текстовый файл, можно руками что-то переписать, можно сравнивать изменения с прошлыми версиями, если вести проект в гите.
>>69552
В общем, поигрался с параметрами, попробовал разные сочетания, пока не получается найти однозначно причину.
SSAO не вызывает застреваний, просто снижает с 90 фпс до 30, но все стабильно.
Небо HDR не вызывает
SDFGI вызывает, но на слабом компе это ожидаемо.
Один из подозреваемых - VoxelGI вызывает, даже если сделан невидимым.
Второй подозреваемый - эти два объекта, со сложной геометрией и кучей отражений/прозрачностей.
При этом, дома с отражением неба в окнах - не вызывают.
Пока основная гипотеза - какие-нибудь сложные геометрии в сочетании с (пере)отражениями при рассчете света или теней, выполняют в вулкане какие-то циклы или рекурсию, как они там считаются хз.
После удаления VoxelGI и вазы с тележкой - стабильные 90 фпс.
Вечером еще попробую большие лоу-поли города погонять.
В общем, поигрался с параметрами, попробовал разные сочетания, пока не получается найти однозначно причину.
SSAO не вызывает застреваний, просто снижает с 90 фпс до 30, но все стабильно.
Небо HDR не вызывает
SDFGI вызывает, но на слабом компе это ожидаемо.
Один из подозреваемых - VoxelGI вызывает, даже если сделан невидимым.
Второй подозреваемый - эти два объекта, со сложной геометрией и кучей отражений/прозрачностей.
При этом, дома с отражением неба в окнах - не вызывают.
Пока основная гипотеза - какие-нибудь сложные геометрии в сочетании с (пере)отражениями при рассчете света или теней, выполняют в вулкане какие-то циклы или рекурсию, как они там считаются хз.
После удаления VoxelGI и вазы с тележкой - стабильные 90 фпс.
Вечером еще попробую большие лоу-поли города погонять.
>>69632
Хотя странно, тогда бы было постоянно медленно, а не burst-ами быстро. Может быть какая-то карта отражений гоняется или пересчитывается.
>какие-нибудь сложные геометрии в сочетании с (пере)отражениями при рассчете света или теней, выполняют в вулкане какие-то циклы или рекурсию, как они там считаются хз.
Хотя странно, тогда бы было постоянно медленно, а не burst-ами быстро. Может быть какая-то карта отражений гоняется или пересчитывается.
>>69507
Задолбал, тебе мало в движкосраче досталось?
Я от синглтонов давно избавился. Стало легче.
>Изобрети синглтон.
Задолбал, тебе мало в движкосраче досталось?
Я от синглтонов давно избавился. Стало легче.
>>69531
Мои соболезнования твоей афантазии, таких как ты 2%, которые не видят картинки у себя в мыслях в процессе чтения текста.
Я не говорю, что видеоуроки вообще бесполезны, в каких-то отдельных областях они полезнее, например, в рисовании лучше увидеть как именно кто-то рисует, чем прочитать описание того, как надо рисовать. Но смотреть видеоуроки про программирование - это абсурд, с тем же успехом можно смотреть видеоуроки про писательство, где какой-то чувак от руки на бумаге старинным пером пишет рассказ, записывая это на камеру у себя на лбу. А ты всего-то хотел узнать, как структурировать рассказ (начало, развитие сюжета, конец, что там ещё), а не смотреть эту унылую рутину, которую любой дурак знает (кроме совсем уж дошкольников, которые ещё не научились писать или печатать).
>врубаешь ролик, там в две секунды показывают куда и че нажать, и как прописать
Мои соболезнования твоей афантазии, таких как ты 2%, которые не видят картинки у себя в мыслях в процессе чтения текста.
Я не говорю, что видеоуроки вообще бесполезны, в каких-то отдельных областях они полезнее, например, в рисовании лучше увидеть как именно кто-то рисует, чем прочитать описание того, как надо рисовать. Но смотреть видеоуроки про программирование - это абсурд, с тем же успехом можно смотреть видеоуроки про писательство, где какой-то чувак от руки на бумаге старинным пером пишет рассказ, записывая это на камеру у себя на лбу. А ты всего-то хотел узнать, как структурировать рассказ (начало, развитие сюжета, конец, что там ещё), а не смотреть эту унылую рутину, которую любой дурак знает (кроме совсем уж дошкольников, которые ещё не научились писать или печатать).
>>69624
Ты сам-то пробовал?
Некоторые вещи в сценах действительно можно поправить в текстовом файле. Вроде именования и типов нод, ссылок на файлы и т.д. Но ты замечал в самом начале файла сцены запись про версию и количество проходов? Вот это количество проходов смущает. Я не знаю, есть ли где-то документация на эту тему, я не видел. Но, судя по всему, движок не сможет загрузить сцену, если у неё будет неправильно объявлено это число проходов. Из чего оно формируется? Из добавленных ресурсов? Ссылок на внешние файлы? Хрен его знает. Я пытался автоматически портировать проект на 4.0, в результате одна из сцен вообще перестала открываться. Открыв в блокноте не увидел никаких аномалий. Наверняка ошибка в где-то процессе загрузки, какие-то параметры заданы неверно, но какие именно? Движок ничего об этом не говорит, просто "сцена не загрузилась" и всё. Единственным выходом вижу открыть эту сцену в 3.5 и вручную воссоздать в 4.0. Но мне лень, всё равно всё буду переделывать...
>текстовый файл, можно руками что-то переписать
Ты сам-то пробовал?
Некоторые вещи в сценах действительно можно поправить в текстовом файле. Вроде именования и типов нод, ссылок на файлы и т.д. Но ты замечал в самом начале файла сцены запись про версию и количество проходов? Вот это количество проходов смущает. Я не знаю, есть ли где-то документация на эту тему, я не видел. Но, судя по всему, движок не сможет загрузить сцену, если у неё будет неправильно объявлено это число проходов. Из чего оно формируется? Из добавленных ресурсов? Ссылок на внешние файлы? Хрен его знает. Я пытался автоматически портировать проект на 4.0, в результате одна из сцен вообще перестала открываться. Открыв в блокноте не увидел никаких аномалий. Наверняка ошибка в где-то процессе загрузки, какие-то параметры заданы неверно, но какие именно? Движок ничего об этом не говорит, просто "сцена не загрузилась" и всё. Единственным выходом вижу открыть эту сцену в 3.5 и вручную воссоздать в 4.0. Но мне лень, всё равно всё буду переделывать...
>>69662
Да, несколько раз приходилось, при смене какой нибудь беты. Создавал тестовый проект, там в редакторе делал ноды, смотрел какой будет синтакс, правил в рабочем проекте.
>Ты сам-то пробовал?
Да, несколько раз приходилось, при смене какой нибудь беты. Создавал тестовый проект, там в редакторе делал ноды, смотрел какой будет синтакс, правил в рабочем проекте.
>>69632
Не вижу на твоих объектах прозрачности.
С прозрачностью у видеокарт всегда проблемы, т.к. она требует ветвление в шейдере. Старайся вместо прозрачности добавить геометрии.
Даже несмотря на то, что добавили (судя по старым описаниям) автоматические LOD и ещё что-то про скрытие объектов, я сомневаюсь, что большая модель города будет сама собой оптимизироваться. Как минимум придётся порезать её на части.
Алсо, что значит "лоу-поли"? У меня лоу-поли "город" рендерился без проблем в 3.x, ведь кубы без текстур никакой особой оптимизации не требуют.
И опиши своё железо, это имеет значение.
>два объекта... кучей... прозрачностей
Не вижу на твоих объектах прозрачности.
С прозрачностью у видеокарт всегда проблемы, т.к. она требует ветвление в шейдере. Старайся вместо прозрачности добавить геометрии.
>большие лоу-поли города
Даже несмотря на то, что добавили (судя по старым описаниям) автоматические LOD и ещё что-то про скрытие объектов, я сомневаюсь, что большая модель города будет сама собой оптимизироваться. Как минимум придётся порезать её на части.
Алсо, что значит "лоу-поли"? У меня лоу-поли "город" рендерился без проблем в 3.x, ведь кубы без текстур никакой особой оптимизации не требуют.
И опиши своё железо, это имеет значение.
>>69666
Может быть там нет прозрачности, я модель детально не изучал. Подумал, что может быть там прозрачные колбы, но может и нет, тогда остается пока все тот же общий фактор для тех объектов - отражающие поверхности.
Ну вот я и хочу попробовать. И одной моделью, и много домиков спавнить, и порасставлять окклюдеры.
Что-то из такого плана.
Алсо домики и без текстур могут быть не кубами, а довольно сложной геометрией.
Но ты прав, надо и с текстурами попробовать. С текстурами у меня большой пак скачан, под CC-BY
Да не особо, слишком специфичное поведение. Я такого не видел. Чтобы просто медленно работало - видел, чтобы загружались чанки в гта5 - видел.
>Не вижу на твоих объектах прозрачности.
Может быть там нет прозрачности, я модель детально не изучал. Подумал, что может быть там прозрачные колбы, но может и нет, тогда остается пока все тот же общий фактор для тех объектов - отражающие поверхности.
>добавили (судя по старым описаниям) автоматические LOD и ещё что-то про скрытие объектов, я сомневаюсь, что большая модель города будет сама собой оптимизироваться.
Ну вот я и хочу попробовать. И одной моделью, и много домиков спавнить, и порасставлять окклюдеры.
Что-то из такого плана.
Алсо домики и без текстур могут быть не кубами, а довольно сложной геометрией.
Но ты прав, надо и с текстурами попробовать. С текстурами у меня большой пак скачан, под CC-BY
>И опиши своё железо, это имеет значение.
Да не особо, слишком специфичное поведение. Я такого не видел. Чтобы просто медленно работало - видел, чтобы загружались чанки в гта5 - видел.
>>69668
Всё ясно с тобой, ассет-флипать захотелось?
СКАЧАЛ КАКОГО-ТО ГНОМА ИЗ ИНТЕРНЕТОВ
@
ТАКИ ПОЧЕМУ ВАШ ДВИЖОК ТОРМОЗИТ???
"Лоу-поли город" подразумевает "кубы вместо домов", как в каком-нибудь градостроительном симуляторе.
Не знаю, у меня много игр "пропукивается", т.е. стабильный FPS в играх редко бывает.
У тебя диск медленный или процессор <4 ядер, с SSD и 4 ядра чанки грузятся мгновенно. По крайней мере, на минимальных моделях/текстурах (мыло).
>модель детально не изучал
Всё ясно с тобой, ассет-флипать захотелось?
СКАЧАЛ КАКОГО-ТО ГНОМА ИЗ ИНТЕРНЕТОВ
@
ТАКИ ПОЧЕМУ ВАШ ДВИЖОК ТОРМОЗИТ???
>не кубами, а довольно сложной геометрией
"Лоу-поли город" подразумевает "кубы вместо домов", как в каком-нибудь градостроительном симуляторе.
>слишком специфичное поведение
Не знаю, у меня много игр "пропукивается", т.е. стабильный FPS в играх редко бывает.
>загружались чанки в гта5 - видел
У тебя диск медленный или процессор <4 ядер, с SSD и 4 ядра чанки грузятся мгновенно. По крайней мере, на минимальных моделях/текстурах (мыло).
>>69670
Вообще то не какого-то, а тестовую сцену GodotGarden которую ассетфлипнул Calinou для тестов. Только я еще добавил террейн, чуть травы, и контроллер персонажа, чтобы было хоть немного ближе к реальному кейсу.
Это вообще другое. Тут секунду нормальная скорость (30), секунду вообще пауза. Если бы было постоянно 5 фпс, это было бы объяснимо.
Только если неспешно идти, а вот если на максимальной скорости гнать на моцике, там как раз чуууточку не хватает.
Но это опять же не так важно, поскольку как тут может участвовать SSD? Если я стою на месте и смотрю на одну сцену. Что может загружаться туда сюда? Если разобраться, то это можно отключить или не использовать. инб4 годот
>СКАЧАЛ КАКОГО-ТО ГНОМА ИЗ ИНТЕРНЕТОВ
Вообще то не какого-то, а тестовую сцену GodotGarden которую ассетфлипнул Calinou для тестов. Только я еще добавил террейн, чуть травы, и контроллер персонажа, чтобы было хоть немного ближе к реальному кейсу.
>т.е. стабильный FPS в играх редко бывает.
Это вообще другое. Тут секунду нормальная скорость (30), секунду вообще пауза. Если бы было постоянно 5 фпс, это было бы объяснимо.
>SSD и 2 ядра чанки грузятся мгновенно, на минимальных моделях/текстурах
Только если неспешно идти, а вот если на максимальной скорости гнать на моцике, там как раз чуууточку не хватает.
Но это опять же не так важно, поскольку как тут может участвовать SSD? Если я стою на месте и смотрю на одну сцену. Что может загружаться туда сюда? Если разобраться, то это можно отключить или не использовать. инб4 годот
>>69670
Ты волен называть лоу поли что хочешь, я говорю про низкополигональные домики, скажем до 10к полигонов, в идеале ближе к 1к за хрущевку без изысков. Церковь на 3 скрине 16к поликов, но она как бы состоит из 5 домиков. Лоу поли не означает ровно 6 граней в кубе, балкончики, бордюры, подоконники, колоннады, это все еще простые конструкции.
Ты волен называть лоу поли что хочешь, я говорю про низкополигональные домики, скажем до 10к полигонов, в идеале ближе к 1к за хрущевку без изысков. Церковь на 3 скрине 16к поликов, но она как бы состоит из 5 домиков. Лоу поли не означает ровно 6 граней в кубе, балкончики, бордюры, подоконники, колоннады, это все еще простые конструкции.
>>69673
Про чанки в ГТА я имел в виду, что это другое - там тебе ядер ЦПУ не хватает, чтобы вовремя закидывать данные в видеокарту, при том что на ЦПУ ещё физика работает и игровые скрипты.
Здесь же всё сразу в видеокарту загружаться должно... С другой стороны, если есть прозрачные материалы (вернее, идущие в отдельный "прозрачный" пайплайн (?)), то их процессор как-то сортирует каждый раз, чтобы они нормально отображались.
Проверь в дебаггере Годо и ещё по диспетчеру задач, что именно у тебя вызывает нагрузку. В идеале, для точного поиска проблемы, нужна та программа, которая ковыряется в процессе рендеринга любой игры, позволяя рассмотреть каждый дроу колл, но я не помню название программы.
Напиши в комменты этой демо-сцены, что вот такая-то конкретная модель на твоём железе на такой-то версии Годо вызывает серьёзную просадку + пропуки, создателям сцены должно быть виднее, в чём проблема. А откуда конкретно ты взял эту демку? Я нашёл только это:
https://github.com/godotengine/godot/issues/63374
>>69674
Да уж, лоу-поли сегодня не очень лоу...
Про чанки в ГТА я имел в виду, что это другое - там тебе ядер ЦПУ не хватает, чтобы вовремя закидывать данные в видеокарту, при том что на ЦПУ ещё физика работает и игровые скрипты.
Здесь же всё сразу в видеокарту загружаться должно... С другой стороны, если есть прозрачные материалы (вернее, идущие в отдельный "прозрачный" пайплайн (?)), то их процессор как-то сортирует каждый раз, чтобы они нормально отображались.
>секунду вообще пауза
Проверь в дебаггере Годо и ещё по диспетчеру задач, что именно у тебя вызывает нагрузку. В идеале, для точного поиска проблемы, нужна та программа, которая ковыряется в процессе рендеринга любой игры, позволяя рассмотреть каждый дроу колл, но я не помню название программы.
>GodotGarden
Напиши в комменты этой демо-сцены, что вот такая-то конкретная модель на твоём железе на такой-то версии Годо вызывает серьёзную просадку + пропуки, создателям сцены должно быть виднее, в чём проблема. А откуда конкретно ты взял эту демку? Я нашёл только это:
https://github.com/godotengine/godot/issues/63374
>>69674
>16к поликов
Да уж, лоу-поли сегодня не очень лоу...
>>69677
RenderDoc валялся где то, не помню че там по вулкану.
> которая ковыряется в процессе рендеринга любой игры, позволяя рассмотреть каждый дроу колл
RenderDoc валялся где то, не помню че там по вулкану.
>>69678
Есть.
Интересно, как они андроид и свитч перехватывают?
>не помню че там по вулкану
Есть.
>RenderDoc is a free MIT licensed stand-alone graphics debugger that allows quick and easy single-frame capture and detailed introspection of any application using Vulkan, D3D11, OpenGL & OpenGL ES or D3D12 across Windows, Linux, Android, or Nintendo Switch™.
Интересно, как они андроид и свитч перехватывают?
>>69677
Да, это оно, перепутал, ее упоминал TokisanGames В этом списке.
https://github.com/godotengine/godot-docs/pull/6393#issuecomment-1333262553
У Calinou много демок в его репе, но этой нет.
>Я нашёл только это:
Да, это оно, перепутал, ее упоминал TokisanGames В этом списке.
https://github.com/godotengine/godot-docs/pull/6393#issuecomment-1333262553
У Calinou много демок в его репе, но этой нет.
1,9 Мб, 1920x1080Запустил сейчас снова движок, добавил вазу и тележку - не лагает.
Добавил VoxelGI - лагает. Убрал - не лагает.
Возможно он неправильно удаляется, может быть даже ссылка на него оставалась в объектах с отражающей поверхностью, раз их удаление помогало, ведь они по идее принимают GI.
Добавил VoxelGI - лагает. Убрал - не лагает.
Возможно он неправильно удаляется, может быть даже ссылка на него оставалась в объектах с отражающей поверхностью, раз их удаление помогало, ведь они по идее принимают GI.
Пасаны, вкатываюсь в Годот, хочу делоть, для начала, 2D-игоры. Стану новый Джон Кармак. Прочел гайд на офф.сайте, по созданию игоря про человечка, который уклоняется от других таких же человечков, а че дальше? Есть ресурсы для 2Д-девелоперов на годоте? Я еще параллельно ковыряю Aseprite, прикольная тема эта, пиксель арт. На ДэвиантАрте люди ваще вещи делают! Есть базовый урвоень знания Питона, но он, блять, перестал поддерживаться в Годоте, ёбаный С# или С++ только, а мне лень их учить, ну их нахуй, с этими их точками с запятыми.
P. S. Нихуя ни понЕл как установить SmartShape2D
P. S. Нихуя ни понЕл как установить SmartShape2D
>>69686
Игори делать. За все эти годы в интернете накопилось очень много всяких книг, статей, видео и т.п. про разработку игр. Берёшь что нравится... Разницы в плане движка особой нет. Главное знать базовые инструменты движка: дерево сцены, ноды, скрипты и всё такое. Освой базовые возможности движка и скриптинг и сможешь делать простые игры без каких-либо туториалов.
Большинство игр на Годо в 2Д, 3Д игр мало. Так что просто ищи ресурсы по Годо. В шапке треда смотри.
Чего? Python в Godot официально никогда не поддерживался, официально есть только GDScript и с ним всё в порядке. Официальной поддержки лишился только VisualScript, который в процессе жизни 3.x оказался практически никому не нужен. Есть неофициальная поддержка множества сторонних языков, среди которых, возможно, есть и Python, но смысла в этом нет, т.к. GDScript достаточно похож на Python. Я не понимаю, как ты умудрился пройти официальный туториал и не знаешь про GDScript...
В GDScript можно ставить точку с запятой после любой команды, но это по желанию. Без точки с запятой следующая команда должна быть на новой строке, а с точкой с запятой можно собирать кучу команд на одной строке, как диды делали, да.
У него пока нет поддержки для 4.0. Подожди авторов этого аддона, чтобы они портировали его на 4.0, т.к. сам ты вряд ли сможешь переписать код (но это возможно).
>че дальше?
Игори делать. За все эти годы в интернете накопилось очень много всяких книг, статей, видео и т.п. про разработку игр. Берёшь что нравится... Разницы в плане движка особой нет. Главное знать базовые инструменты движка: дерево сцены, ноды, скрипты и всё такое. Освой базовые возможности движка и скриптинг и сможешь делать простые игры без каких-либо туториалов.
>Есть ресурсы для 2Д-девелоперов на годоте?
Большинство игр на Годо в 2Д, 3Д игр мало. Так что просто ищи ресурсы по Годо. В шапке треда смотри.
>Есть базовый урвоень знания Питона, но он, блять, перестал поддерживаться в Годоте, ёбаный С# или С++ только, а мне лень их учить
Чего? Python в Godot официально никогда не поддерживался, официально есть только GDScript и с ним всё в порядке. Официальной поддержки лишился только VisualScript, который в процессе жизни 3.x оказался практически никому не нужен. Есть неофициальная поддержка множества сторонних языков, среди которых, возможно, есть и Python, но смысла в этом нет, т.к. GDScript достаточно похож на Python. Я не понимаю, как ты умудрился пройти официальный туториал и не знаешь про GDScript...
>точками с запятыми
В GDScript можно ставить точку с запятой после любой команды, но это по желанию. Без точки с запятой следующая команда должна быть на новой строке, а с точкой с запятой можно собирать кучу команд на одной строке, как диды делали, да.
>установить SmartShape2D
У него пока нет поддержки для 4.0. Подожди авторов этого аддона, чтобы они портировали его на 4.0, т.к. сам ты вряд ли сможешь переписать код (но это возможно).
>>69686 >>69688
И правда, есть неофициальная поддержка Python:
https://github.com/touilleMan/godot-python
Но её необходимо портировать на 4.0, т.к. всё слишком изменилось в движке.
И правда, есть неофициальная поддержка Python:
https://github.com/touilleMan/godot-python
Но её необходимо портировать на 4.0, т.к. всё слишком изменилось в движке.
>>69624
Всё созраняю в бинарных .scn, во имя быстродействия.
>>69658
Нет, это таких, которые видят картинки в процессе чтения технического текста, вот таких как раз 2%. У всех остальных всё-таки знания лучше усваиваются в мультимедийном формате.
Сразу видно, ни одного видеоурока ты ни разу не смотрел.
Вообще-то в видео-туторах не просто программирование на камеру. Там комплексная аудиовизуальная информация с пояснением каждого шага. Она работает сразу на нескольких уровнях:
1. Текст - ты видишь готовый код, который тебе в процессе разъясняют, чуть ли не каждое слово;
2. Звук - разъяснение идёт голосом, так что включается сдуховой канал восприятия;
3. Результат - тебе не просто говорят, что делать, но ещё сразу показывают, как это будет работать в частично готовой игре;
4. Чувство причастности - если ты повторяешь за показанным в ролике;
5. Развлечение - авторы видосов заинтересованы делать их увлекательными и визуально привлекательными, чтобы удержать аудиторию, так устроен ютуб.
В видео-уроках принципиально иной подход к подаче материала, нежели в текстовых туторах. Они буквально за ручку тебя ведут через процесс создания игры, создают её вместе с тобой. Текстовые зачастую пропускают важные стадии, например, ожидая от тебя, что ты сам догадаешься пройти по ссылке и почитать. Ну и конечно же, повторяя за видео, ты ощущаешь уверенность, что всё, что ты делаешь, должно работать, ведь тебе это показали; копируя код из текстового тутора, ты этой уверенности лишён, так что, если что-то не работает, неизвестно, это ты скопировал неправильно или что вообще пошло не так.
Ну а доки так вообще. Туда можно лезть только если ты уже точно знаешь, что хочешь получить, и тебе нужно просто узнать, какая функция в апи за это отвечает.
Нет, я всё же считаю, что доки у годота охуенные. И текстовые туториалы тоже. Но видео всё же более эффективны в качестве обучающего материала. Это как если бы в школе были только учебники, никаких учителей.
>Это текстовый файл
Всё созраняю в бинарных .scn, во имя быстродействия.
>>69658
>таких как ты 2%, которые не видят картинки у себя в мыслях в процессе чтения текста.
Нет, это таких, которые видят картинки в процессе чтения технического текста, вот таких как раз 2%. У всех остальных всё-таки знания лучше усваиваются в мультимедийном формате.
>Но смотреть видеоуроки про программирование - это абсурд(...)
Сразу видно, ни одного видеоурока ты ни разу не смотрел.
Вообще-то в видео-туторах не просто программирование на камеру. Там комплексная аудиовизуальная информация с пояснением каждого шага. Она работает сразу на нескольких уровнях:
1. Текст - ты видишь готовый код, который тебе в процессе разъясняют, чуть ли не каждое слово;
2. Звук - разъяснение идёт голосом, так что включается сдуховой канал восприятия;
3. Результат - тебе не просто говорят, что делать, но ещё сразу показывают, как это будет работать в частично готовой игре;
4. Чувство причастности - если ты повторяешь за показанным в ролике;
5. Развлечение - авторы видосов заинтересованы делать их увлекательными и визуально привлекательными, чтобы удержать аудиторию, так устроен ютуб.
В видео-уроках принципиально иной подход к подаче материала, нежели в текстовых туторах. Они буквально за ручку тебя ведут через процесс создания игры, создают её вместе с тобой. Текстовые зачастую пропускают важные стадии, например, ожидая от тебя, что ты сам догадаешься пройти по ссылке и почитать. Ну и конечно же, повторяя за видео, ты ощущаешь уверенность, что всё, что ты делаешь, должно работать, ведь тебе это показали; копируя код из текстового тутора, ты этой уверенности лишён, так что, если что-то не работает, неизвестно, это ты скопировал неправильно или что вообще пошло не так.
Ну а доки так вообще. Туда можно лезть только если ты уже точно знаешь, что хочешь получить, и тебе нужно просто узнать, какая функция в апи за это отвечает.
Нет, я всё же считаю, что доки у годота охуенные. И текстовые туториалы тоже. Но видео всё же более эффективны в качестве обучающего материала. Это как если бы в школе были только учебники, никаких учителей.
>>69624
Всё созраняю в бинарных .scn, во имя быстродействия.
>>69658
Нет, это таких, которые видят картинки в процессе чтения технического текста, вот таких как раз 2%. У всех остальных всё-таки знания лучше усваиваются в мультимедийном формате.
Сразу видно, ни одного видеоурока ты ни разу не смотрел.
Вообще-то в видео-туторах не просто программирование на камеру. Там комплексная аудиовизуальная информация с пояснением каждого шага. Она работает сразу на нескольких уровнях:
1. Текст - ты видишь готовый код, который тебе в процессе разъясняют, чуть ли не каждое слово;
2. Звук - разъяснение идёт голосом, так что включается сдуховой канал восприятия;
3. Результат - тебе не просто говорят, что делать, но ещё сразу показывают, как это будет работать в частично готовой игре;
4. Чувство причастности - если ты повторяешь за показанным в ролике;
5. Развлечение - авторы видосов заинтересованы делать их увлекательными и визуально привлекательными, чтобы удержать аудиторию, так устроен ютуб.
В видео-уроках принципиально иной подход к подаче материала, нежели в текстовых туторах. Они буквально за ручку тебя ведут через процесс создания игры, создают её вместе с тобой. Текстовые зачастую пропускают важные стадии, например, ожидая от тебя, что ты сам догадаешься пройти по ссылке и почитать. Ну и конечно же, повторяя за видео, ты ощущаешь уверенность, что всё, что ты делаешь, должно работать, ведь тебе это показали; копируя код из текстового тутора, ты этой уверенности лишён, так что, если что-то не работает, неизвестно, это ты скопировал неправильно или что вообще пошло не так.
Ну а доки так вообще. Туда можно лезть только если ты уже точно знаешь, что хочешь получить, и тебе нужно просто узнать, какая функция в апи за это отвечает.
Нет, я всё же считаю, что доки у годота охуенные. И текстовые туториалы тоже. Но видео всё же более эффективны в качестве обучающего материала. Это как если бы в школе были только учебники, никаких учителей.
>Это текстовый файл
Всё созраняю в бинарных .scn, во имя быстродействия.
>>69658
>таких как ты 2%, которые не видят картинки у себя в мыслях в процессе чтения текста.
Нет, это таких, которые видят картинки в процессе чтения технического текста, вот таких как раз 2%. У всех остальных всё-таки знания лучше усваиваются в мультимедийном формате.
>Но смотреть видеоуроки про программирование - это абсурд(...)
Сразу видно, ни одного видеоурока ты ни разу не смотрел.
Вообще-то в видео-туторах не просто программирование на камеру. Там комплексная аудиовизуальная информация с пояснением каждого шага. Она работает сразу на нескольких уровнях:
1. Текст - ты видишь готовый код, который тебе в процессе разъясняют, чуть ли не каждое слово;
2. Звук - разъяснение идёт голосом, так что включается сдуховой канал восприятия;
3. Результат - тебе не просто говорят, что делать, но ещё сразу показывают, как это будет работать в частично готовой игре;
4. Чувство причастности - если ты повторяешь за показанным в ролике;
5. Развлечение - авторы видосов заинтересованы делать их увлекательными и визуально привлекательными, чтобы удержать аудиторию, так устроен ютуб.
В видео-уроках принципиально иной подход к подаче материала, нежели в текстовых туторах. Они буквально за ручку тебя ведут через процесс создания игры, создают её вместе с тобой. Текстовые зачастую пропускают важные стадии, например, ожидая от тебя, что ты сам догадаешься пройти по ссылке и почитать. Ну и конечно же, повторяя за видео, ты ощущаешь уверенность, что всё, что ты делаешь, должно работать, ведь тебе это показали; копируя код из текстового тутора, ты этой уверенности лишён, так что, если что-то не работает, неизвестно, это ты скопировал неправильно или что вообще пошло не так.
Ну а доки так вообще. Туда можно лезть только если ты уже точно знаешь, что хочешь получить, и тебе нужно просто узнать, какая функция в апи за это отвечает.
Нет, я всё же считаю, что доки у годота охуенные. И текстовые туториалы тоже. Но видео всё же более эффективны в качестве обучающего материала. Это как если бы в школе были только учебники, никаких учителей.
>>69690
Делаешь - не работает, потому что автор видео мудила и исправляет незамеченные баги в следующей серии. А так как тебя ведут за ручку все время, искать информацию сам ты не обучен, в итоге не дождавшись следующей серии своей гайд-иконы ты дропаешь годо по причине "да должно же работать, ведь все как в видосе".
Зачем вообще разделять текстовые/видео гайды, лутай инфу из всего до чего дотянешься.
>повторяя за видео, ты ощущаешь уверенность, что всё, что ты делаешь, должно работать, ведь тебе это показали
Делаешь - не работает, потому что автор видео мудила и исправляет незамеченные баги в следующей серии. А так как тебя ведут за ручку все время, искать информацию сам ты не обучен, в итоге не дождавшись следующей серии своей гайд-иконы ты дропаешь годо по причине "да должно же работать, ведь все как в видосе".
Зачем вообще разделять текстовые/видео гайды, лутай инфу из всего до чего дотянешься.
>>69711
ну общая задача - в реалтайме выдавать текстуру, у которой будет изменятся цвет пикселя по какому-либо алгоритму, зависящему от параметров, которые тоже могут меняться каждый кадр
с передачей в шейдер попробовал, там больше вроде тормозит или как минимум на том же примерно уровне, пока самое быстрое - это дату имиджа менять
ну общая задача - в реалтайме выдавать текстуру, у которой будет изменятся цвет пикселя по какому-либо алгоритму, зависящему от параметров, которые тоже могут меняться каждый кадр
с передачей в шейдер попробовал, там больше вроде тормозит или как минимум на том же примерно уровне, пока самое быстрое - это дату имиджа менять
>>69718
Зачем? 2D не требует каких-то особых механизмов. Скачиваешь картинку (с доступной лицензией, конечно) в любом месте, например opengameart, itch. Перетаскиваешь спрайт в папку и готово.
Я просто окуеваю. На днях видел человек продавал 3D камень для Годота за $15. Почему именно для годота, непонятно, обычно пишут совместимо с такими то движками, но даже если нет, тривиально конвертируется.
Зачем? 2D не требует каких-то особых механизмов. Скачиваешь картинку (с доступной лицензией, конечно) в любом месте, например opengameart, itch. Перетаскиваешь спрайт в папку и готово.
Я просто окуеваю. На днях видел человек продавал 3D камень для Годота за $15. Почему именно для годота, непонятно, обычно пишут совместимо с такими то движками, но даже если нет, тривиально конвертируется.
>>69726
короче бизнес-схема, конвертим 3D модель в .import годота и продаем как специализированный готовый формат для движка, за дополнительную плату можем конвертить в форматы других движков, план-огонь
короче бизнес-схема, конвертим 3D модель в .import годота и продаем как специализированный готовый формат для движка, за дополнительную плату можем конвертить в форматы других движков, план-огонь
>>69735
А может ты долбоеб? Что тебе нужно от ассет стора?
2500+ пак материалов или десяток скролл бекграндов за 70 баксов?
А может ты долбоеб? Что тебе нужно от ассет стора?
2500+ пак материалов или десяток скролл бекграндов за 70 баксов?
>>69688
Знаю, на нем и писал игрулю. Мне он понравился, прикольный и понятный зык. Но есть ли профит учить его полоценно, как какой-нибудь С++ или Пайтон - вот в чем вопрос.
>>69689
Тож уже шерстил эту тему, но эт костыли ебаные
>>69690
Сыглы)) Пацаны, походу, смотрели видео-туторы чуваков из гайда "Как рисовать сову" - сначала рисуем круг, потом всё остальное))
> GDScript достаточно похож на Python. Я не понимаю, как ты умудрился пройти официальный туториал и не знаешь про GDScript
Знаю, на нем и писал игрулю. Мне он понравился, прикольный и понятный зык. Но есть ли профит учить его полоценно, как какой-нибудь С++ или Пайтон - вот в чем вопрос.
>>69689
Тож уже шерстил эту тему, но эт костыли ебаные
>>69690
Сыглы)) Пацаны, походу, смотрели видео-туторы чуваков из гайда "Как рисовать сову" - сначала рисуем круг, потом всё остальное))
>>69742
Так он маленький, меньше питона. А с++ можно учить и 20 лет и не выучить.
>Но есть ли профит учить его полоценно, как какой-нибудь С++ или Пайтон
Так он маленький, меньше питона. А с++ можно учить и 20 лет и не выучить.
>>69434
>>69490
Я пришёл к выводу, что заморачиваться с навороченными террейн-ассетами нет смысла. Опенворлд в соло не запилить (если кто-то желает возразить, запилите в соло и покажите здесь опенворлд хотя бы уровня скайрима, 2011 года, слабо?) поэтому стоит сконцентрироваться на камерных проектах (камерность, это когда ворлд не опен), а тут террейны не нужны, тут нужнее генерация динамических коридоров с комнатами.
>>69490
Я пришёл к выводу, что заморачиваться с навороченными террейн-ассетами нет смысла. Опенворлд в соло не запилить (если кто-то желает возразить, запилите в соло и покажите здесь опенворлд хотя бы уровня скайрима, 2011 года, слабо?) поэтому стоит сконцентрироваться на камерных проектах (камерность, это когда ворлд не опен), а тут террейны не нужны, тут нужнее генерация динамических коридоров с комнатами.
>>69745
скайрим в одно лицо не вывезешь тем, что там физически контента столько одно лицо не сделает
скайрим в одно лицо не вывезешь тем, что там физически контента столько одно лицо не сделает
>>69749
А я вот пилю свою игру мечты потихоньку. Полагаюсь на генерацию, в частности на блендер геометри ноды. Прикол в том, что надо просто сосредоточиться и продумать схему, тогда потом контент клепать легко. Прямо как в какой то книге сказано, work smart, not hard.
А я вот пилю свою игру мечты потихоньку. Полагаюсь на генерацию, в частности на блендер геометри ноды. Прикол в том, что надо просто сосредоточиться и продумать схему, тогда потом контент клепать легко. Прямо как в какой то книге сказано, work smart, not hard.
>>69715
Разве лицензия годота позволяет торговать? Я где-то читал, что лизенционое требование, чтобы всё было бесплатно.
Разве лицензия годота позволяет торговать? Я где-то читал, что лизенционое требование, чтобы всё было бесплатно.
>>69757
позволяет
позволяет
>>69757
Нет, такого требования в принципе не может быть. Даже в блендере аддоны под gpl продаются.
А сам Годот вообще под MIT лицензией, то есть можно продавать даже его. Более того, такая лицензия специально выбрана, чтобы ни у кого, делающего под движок контент, не возникало проблем.
Просто, поскольку сам движок опен сорс, то в сообществе считается хорошим тоном делиться своими наработками в опенсорс, выкладывать аддоны, показывать код, делать туториалы.
А то бывает в реддит других движков заглядываешь - а там только хвастовство картинками или реклама платного, а в годот заходишь - сразу с радостью рассказывают, что и как сделано.
Нет, такого требования в принципе не может быть. Даже в блендере аддоны под gpl продаются.
А сам Годот вообще под MIT лицензией, то есть можно продавать даже его. Более того, такая лицензия специально выбрана, чтобы ни у кого, делающего под движок контент, не возникало проблем.
Просто, поскольку сам движок опен сорс, то в сообществе считается хорошим тоном делиться своими наработками в опенсорс, выкладывать аддоны, показывать код, делать туториалы.
А то бывает в реддит других движков заглядываешь - а там только хвастовство картинками или реклама платного, а в годот заходишь - сразу с радостью рассказывают, что и как сделано.
>>69695
Как-то так ты рассуждаешь
>>69705
Двачаю.
Я сам начинал с видосов, потом перелез чисто на доки, щас посматриваю некоторых мудрых семпаев, которые скорее делятся размышлениями, фишечками и опытом, чем дают какие-то конкретные гайды.
>>69745
Ну ты дал. Но вот уровня Тени Чернобыля - вполне реально в соло запилить..
>>69717
Хз, мне аноны в треде посоветовали, когда самый первый проект у меня люто тормозить стал. Переделал на scn, больше не тормозил.
>Другие люди отличаются от меня = все вокруг инфантильные дебилы
Как-то так ты рассуждаешь
>>69705
>Зачем вообще разделять текстовые/видео гайды, лутай инфу из всего до чего дотянешься
Двачаю.
Я сам начинал с видосов, потом перелез чисто на доки, щас посматриваю некоторых мудрых семпаев, которые скорее делятся размышлениями, фишечками и опытом, чем дают какие-то конкретные гайды.
>>69745
>запилите в соло и покажите здесь опенворлд хотя бы уровня скайрима, 2011 года, слабо?
Ну ты дал. Но вот уровня Тени Чернобыля - вполне реально в соло запилить..
>>69717
>И какой прирост? Ты замерял?
Хз, мне аноны в треде посоветовали, когда самый первый проект у меня люто тормозить стал. Переделал на scn, больше не тормозил.
>>69690
Сам виноват. Пересохрани в tscn в версии 3.5.
Вряд ли там существенная разница. Если разница и есть, то можно перед релизом всё пересохранить.
Сомневаюсь. Когда ты читаешь технический текст, там в любом случае описывают что-то, что ты обычно видишь глазами: GUI, 2D/3D сцены, ноды в дереве сцены, код в редакторе и т.д. Вот читаешь описание и видишь перед глазами как вживую.
Пруфы есть? Нет у тебя пруфов.
К большому сожалению, я слишком часто натыкаюсь на видеоуроки и пытался их смотреть, поэтому и говорю, что в них нет никакой пользы.
В тексте я его тоже вижу. Проблема видео:
1. Нужно найти кадр с кодом и поставить на паузу.
2. Часто качество видео плохое и текст испорчен.
3. Картинку зачастую невозможно приблизить.
4. Невозможно скопировать часть кода с картинки.
Проще говоря, тебе приходится напрягаться, чтобы расшифровать это пуканье в микрофон на каком-то незнакомом тебе диалекте ингриша. А ещё узнать о том, кто у автора родил и кто умер, а также очень важную рекламу его других видео и канала в целом.
Единственная польза от видео. На данный момент, если я натыкаюсь на видеоурок, я сразу ищу в нём фрагмент с готовым результатом, после чего закрываю видео и больше не смотрю его.
Мне не 5 лет, мне нужны знания, а не чувства.
Опять же, я открыл ссылку для получения знаний, а не чтобы тупо поржать над мемами. Все эти шутки растягивают видео и отвлекают от сути. Я прекрасно понимаю, почему их добавляют, но это не приносит пользы видео как обучающему материалу. Шутки только накручивают просмотры за счёт тех, кто смотрит только ради шуток.
Не все видео, и не всегда это уместно.
Не все текстовые уроки. Обычно это полезно, т.к. ты уже знаешь всё необходимое по предыдущим урокам серии, и тебя не нужно учить "как открыть Godot, создать проект и новую пустую сцену".
Особенно на видео двухлетней давности, к старой версии движка, у которой всё по-другому. Текстовые уроки намного проще обновить до актуального состояния, кроме того, хороший текстовый урок не зависит от изменений в GUI редактора, тогда как видео целиком переснимать придётся даже если одну надпись изменили или кнопку передвинули.
Изучил множество нод только через встроенную в редактор документацию по API этих нод.
В школе учителя нужны, чтобы навязать дисциплину, угомонить и заставить балбесов читать книги. Если ты не инфантил с СДВГ, учитель тебе не нужен.
>Всё созраняю в бинарных .scn
Сам виноват. Пересохрани в tscn в версии 3.5.
>во имя быстродействия
Вряд ли там существенная разница. Если разница и есть, то можно перед релизом всё пересохранить.
>Нет, это таких, которые видят картинки в процессе чтения технического текста, вот таких как раз 2%.
Сомневаюсь. Когда ты читаешь технический текст, там в любом случае описывают что-то, что ты обычно видишь глазами: GUI, 2D/3D сцены, ноды в дереве сцены, код в редакторе и т.д. Вот читаешь описание и видишь перед глазами как вживую.
>У всех остальных всё-таки знания лучше усваиваются в мультимедийном формате.
Пруфы есть? Нет у тебя пруфов.
>ни одного видеоурока ты ни разу не смотрел
К большому сожалению, я слишком часто натыкаюсь на видеоуроки и пытался их смотреть, поэтому и говорю, что в них нет никакой пользы.
>ты видишь готовый код
В тексте я его тоже вижу. Проблема видео:
1. Нужно найти кадр с кодом и поставить на паузу.
2. Часто качество видео плохое и текст испорчен.
3. Картинку зачастую невозможно приблизить.
4. Невозможно скопировать часть кода с картинки.
>Звук - разъяснение идёт голосом, так что включается сдуховой канал восприятия;
Проще говоря, тебе приходится напрягаться, чтобы расшифровать это пуканье в микрофон на каком-то незнакомом тебе диалекте ингриша. А ещё узнать о том, кто у автора родил и кто умер, а также очень важную рекламу его других видео и канала в целом.
>показывают, как это будет работать
Единственная польза от видео. На данный момент, если я натыкаюсь на видеоурок, я сразу ищу в нём фрагмент с готовым результатом, после чего закрываю видео и больше не смотрю его.
>Чувство причастности - если ты повторяешь за показанным в ролике
Мне не 5 лет, мне нужны знания, а не чувства.
>Развлечение - авторы видосов заинтересованы делать их увлекательными
Опять же, я открыл ссылку для получения знаний, а не чтобы тупо поржать над мемами. Все эти шутки растягивают видео и отвлекают от сути. Я прекрасно понимаю, почему их добавляют, но это не приносит пользы видео как обучающему материалу. Шутки только накручивают просмотры за счёт тех, кто смотрит только ради шуток.
>буквально за ручку тебя ведут
Не все видео, и не всегда это уместно.
>пропускают важные стадии
Не все текстовые уроки. Обычно это полезно, т.к. ты уже знаешь всё необходимое по предыдущим урокам серии, и тебя не нужно учить "как открыть Godot, создать проект и новую пустую сцену".
>повторяя за видео, ты ощущаешь уверенность
Особенно на видео двухлетней давности, к старой версии движка, у которой всё по-другому. Текстовые уроки намного проще обновить до актуального состояния, кроме того, хороший текстовый урок не зависит от изменений в GUI редактора, тогда как видео целиком переснимать придётся даже если одну надпись изменили или кнопку передвинули.
>Туда можно лезть только если ты уже точно знаешь, что хочешь получить, и тебе нужно просто узнать, какая функция в апи за это отвечает.
Изучил множество нод только через встроенную в редактор документацию по API этих нод.
>Это как если бы в школе были только учебники, никаких учителей.
В школе учителя нужны, чтобы навязать дисциплину, угомонить и заставить балбесов читать книги. Если ты не инфантил с СДВГ, учитель тебе не нужен.
>>69690
Сам виноват. Пересохрани в tscn в версии 3.5.
Вряд ли там существенная разница. Если разница и есть, то можно перед релизом всё пересохранить.
Сомневаюсь. Когда ты читаешь технический текст, там в любом случае описывают что-то, что ты обычно видишь глазами: GUI, 2D/3D сцены, ноды в дереве сцены, код в редакторе и т.д. Вот читаешь описание и видишь перед глазами как вживую.
Пруфы есть? Нет у тебя пруфов.
К большому сожалению, я слишком часто натыкаюсь на видеоуроки и пытался их смотреть, поэтому и говорю, что в них нет никакой пользы.
В тексте я его тоже вижу. Проблема видео:
1. Нужно найти кадр с кодом и поставить на паузу.
2. Часто качество видео плохое и текст испорчен.
3. Картинку зачастую невозможно приблизить.
4. Невозможно скопировать часть кода с картинки.
Проще говоря, тебе приходится напрягаться, чтобы расшифровать это пуканье в микрофон на каком-то незнакомом тебе диалекте ингриша. А ещё узнать о том, кто у автора родил и кто умер, а также очень важную рекламу его других видео и канала в целом.
Единственная польза от видео. На данный момент, если я натыкаюсь на видеоурок, я сразу ищу в нём фрагмент с готовым результатом, после чего закрываю видео и больше не смотрю его.
Мне не 5 лет, мне нужны знания, а не чувства.
Опять же, я открыл ссылку для получения знаний, а не чтобы тупо поржать над мемами. Все эти шутки растягивают видео и отвлекают от сути. Я прекрасно понимаю, почему их добавляют, но это не приносит пользы видео как обучающему материалу. Шутки только накручивают просмотры за счёт тех, кто смотрит только ради шуток.
Не все видео, и не всегда это уместно.
Не все текстовые уроки. Обычно это полезно, т.к. ты уже знаешь всё необходимое по предыдущим урокам серии, и тебя не нужно учить "как открыть Godot, создать проект и новую пустую сцену".
Особенно на видео двухлетней давности, к старой версии движка, у которой всё по-другому. Текстовые уроки намного проще обновить до актуального состояния, кроме того, хороший текстовый урок не зависит от изменений в GUI редактора, тогда как видео целиком переснимать придётся даже если одну надпись изменили или кнопку передвинули.
Изучил множество нод только через встроенную в редактор документацию по API этих нод.
В школе учителя нужны, чтобы навязать дисциплину, угомонить и заставить балбесов читать книги. Если ты не инфантил с СДВГ, учитель тебе не нужен.
>Всё созраняю в бинарных .scn
Сам виноват. Пересохрани в tscn в версии 3.5.
>во имя быстродействия
Вряд ли там существенная разница. Если разница и есть, то можно перед релизом всё пересохранить.
>Нет, это таких, которые видят картинки в процессе чтения технического текста, вот таких как раз 2%.
Сомневаюсь. Когда ты читаешь технический текст, там в любом случае описывают что-то, что ты обычно видишь глазами: GUI, 2D/3D сцены, ноды в дереве сцены, код в редакторе и т.д. Вот читаешь описание и видишь перед глазами как вживую.
>У всех остальных всё-таки знания лучше усваиваются в мультимедийном формате.
Пруфы есть? Нет у тебя пруфов.
>ни одного видеоурока ты ни разу не смотрел
К большому сожалению, я слишком часто натыкаюсь на видеоуроки и пытался их смотреть, поэтому и говорю, что в них нет никакой пользы.
>ты видишь готовый код
В тексте я его тоже вижу. Проблема видео:
1. Нужно найти кадр с кодом и поставить на паузу.
2. Часто качество видео плохое и текст испорчен.
3. Картинку зачастую невозможно приблизить.
4. Невозможно скопировать часть кода с картинки.
>Звук - разъяснение идёт голосом, так что включается сдуховой канал восприятия;
Проще говоря, тебе приходится напрягаться, чтобы расшифровать это пуканье в микрофон на каком-то незнакомом тебе диалекте ингриша. А ещё узнать о том, кто у автора родил и кто умер, а также очень важную рекламу его других видео и канала в целом.
>показывают, как это будет работать
Единственная польза от видео. На данный момент, если я натыкаюсь на видеоурок, я сразу ищу в нём фрагмент с готовым результатом, после чего закрываю видео и больше не смотрю его.
>Чувство причастности - если ты повторяешь за показанным в ролике
Мне не 5 лет, мне нужны знания, а не чувства.
>Развлечение - авторы видосов заинтересованы делать их увлекательными
Опять же, я открыл ссылку для получения знаний, а не чтобы тупо поржать над мемами. Все эти шутки растягивают видео и отвлекают от сути. Я прекрасно понимаю, почему их добавляют, но это не приносит пользы видео как обучающему материалу. Шутки только накручивают просмотры за счёт тех, кто смотрит только ради шуток.
>буквально за ручку тебя ведут
Не все видео, и не всегда это уместно.
>пропускают важные стадии
Не все текстовые уроки. Обычно это полезно, т.к. ты уже знаешь всё необходимое по предыдущим урокам серии, и тебя не нужно учить "как открыть Godot, создать проект и новую пустую сцену".
>повторяя за видео, ты ощущаешь уверенность
Особенно на видео двухлетней давности, к старой версии движка, у которой всё по-другому. Текстовые уроки намного проще обновить до актуального состояния, кроме того, хороший текстовый урок не зависит от изменений в GUI редактора, тогда как видео целиком переснимать придётся даже если одну надпись изменили или кнопку передвинули.
>Туда можно лезть только если ты уже точно знаешь, что хочешь получить, и тебе нужно просто узнать, какая функция в апи за это отвечает.
Изучил множество нод только через встроенную в редактор документацию по API этих нод.
>Это как если бы в школе были только учебники, никаких учителей.
В школе учителя нужны, чтобы навязать дисциплину, угомонить и заставить балбесов читать книги. Если ты не инфантил с СДВГ, учитель тебе не нужен.
>>69745
Всё так. Статичный ландшафт можно в блендере смоделировать и на чанки порезать. Динамически его создавать в движке имеет смысл только для игр типа Майнкрафта, но там воксели лучше.
В Скайрим не играл, но это вопрос количества контента, а не используемых технологий и не геймдизайна. Даже если ты будешь делать такое же количество контента в коридорной игре, ты не сможешь сделать быстро и в соло. Напротив, ты можешь сделать опенворлд с малым количеством контента.
Ты путаешь несколько понятий.
Опенворлд - это не "равнины да горы, а вокруг море", а свобода перемещения. Если тебя геймдизайнер гонит по дороге без развилок через огромную равнину - это ни разу не опенворлд, это коридорная игра в стиле старых коридорных шутеров, только вместо декоративных стен тут теперь декоративные поля да луга.
Коридорная игра - это когда тебя гонят по "коридору" в единственно возможном направлении, заставляя проходить контент в строго определённой последовательности (крайне редко игра заставляет вернуться, сделать петлю или пройти по ответвлению, но сути это не меняет). Если ты запускаешь игрока в большое здание с кучей комнат и коридоров, давая возможность идти в любом направлении без ограничений, то это опенворлд, а не коридорная игра, несмотря на то, что визуально на экране только коридоры.
Т.е. опенворлд - это не про тип ландшафта, а только про свободу перемещения. Ранние игры могли показывать игроку широкие просторы, но ограничивали его узкими коридорами невидимых стен, либо просто не давали никаких задач за пределами узкого коридора. В то же время могут существовать игры про закрытые пространства вроде подземелья, башни или гигахруща, но с максимальной свободой движения, разбрасывая контент по большой площади/объёму и разрешая проходить контент в произвольном порядке - это оперворлды. Настоящих опенворлдов весьма мало...
>Я пришёл к выводу, что заморачиваться с навороченными террейн-ассетами нет смысла.
Всё так. Статичный ландшафт можно в блендере смоделировать и на чанки порезать. Динамически его создавать в движке имеет смысл только для игр типа Майнкрафта, но там воксели лучше.
>Опенворлд в соло не запилить (если кто-то желает возразить, запилите в соло и покажите здесь опенворлд хотя бы уровня скайрима, 2011 года, слабо?)
В Скайрим не играл, но это вопрос количества контента, а не используемых технологий и не геймдизайна. Даже если ты будешь делать такое же количество контента в коридорной игре, ты не сможешь сделать быстро и в соло. Напротив, ты можешь сделать опенворлд с малым количеством контента.
>поэтому стоит сконцентрироваться на камерных проектах (камерность, это когда ворлд не опен), а тут террейны не нужны, тут нужнее генерация динамических коридоров с комнатами.
Ты путаешь несколько понятий.
Опенворлд - это не "равнины да горы, а вокруг море", а свобода перемещения. Если тебя геймдизайнер гонит по дороге без развилок через огромную равнину - это ни разу не опенворлд, это коридорная игра в стиле старых коридорных шутеров, только вместо декоративных стен тут теперь декоративные поля да луга.
Коридорная игра - это когда тебя гонят по "коридору" в единственно возможном направлении, заставляя проходить контент в строго определённой последовательности (крайне редко игра заставляет вернуться, сделать петлю или пройти по ответвлению, но сути это не меняет). Если ты запускаешь игрока в большое здание с кучей комнат и коридоров, давая возможность идти в любом направлении без ограничений, то это опенворлд, а не коридорная игра, несмотря на то, что визуально на экране только коридоры.
Т.е. опенворлд - это не про тип ландшафта, а только про свободу перемещения. Ранние игры могли показывать игроку широкие просторы, но ограничивали его узкими коридорами невидимых стен, либо просто не давали никаких задач за пределами узкого коридора. В то же время могут существовать игры про закрытые пространства вроде подземелья, башни или гигахруща, но с максимальной свободой движения, разбрасывая контент по большой площади/объёму и разрешая проходить контент в произвольном порядке - это оперворлды. Настоящих опенворлдов весьма мало...
>>69745
Всё так. Статичный ландшафт можно в блендере смоделировать и на чанки порезать. Динамически его создавать в движке имеет смысл только для игр типа Майнкрафта, но там воксели лучше.
В Скайрим не играл, но это вопрос количества контента, а не используемых технологий и не геймдизайна. Даже если ты будешь делать такое же количество контента в коридорной игре, ты не сможешь сделать быстро и в соло. Напротив, ты можешь сделать опенворлд с малым количеством контента.
Ты путаешь несколько понятий.
Опенворлд - это не "равнины да горы, а вокруг море", а свобода перемещения. Если тебя геймдизайнер гонит по дороге без развилок через огромную равнину - это ни разу не опенворлд, это коридорная игра в стиле старых коридорных шутеров, только вместо декоративных стен тут теперь декоративные поля да луга.
Коридорная игра - это когда тебя гонят по "коридору" в единственно возможном направлении, заставляя проходить контент в строго определённой последовательности (крайне редко игра заставляет вернуться, сделать петлю или пройти по ответвлению, но сути это не меняет). Если ты запускаешь игрока в большое здание с кучей комнат и коридоров, давая возможность идти в любом направлении без ограничений, то это опенворлд, а не коридорная игра, несмотря на то, что визуально на экране только коридоры.
Т.е. опенворлд - это не про тип ландшафта, а только про свободу перемещения. Ранние игры могли показывать игроку широкие просторы, но ограничивали его узкими коридорами невидимых стен, либо просто не давали никаких задач за пределами узкого коридора. В то же время могут существовать игры про закрытые пространства вроде подземелья, башни или гигахруща, но с максимальной свободой движения, разбрасывая контент по большой площади/объёму и разрешая проходить контент в произвольном порядке - это оперворлды. Настоящих опенворлдов весьма мало...
>Я пришёл к выводу, что заморачиваться с навороченными террейн-ассетами нет смысла.
Всё так. Статичный ландшафт можно в блендере смоделировать и на чанки порезать. Динамически его создавать в движке имеет смысл только для игр типа Майнкрафта, но там воксели лучше.
>Опенворлд в соло не запилить (если кто-то желает возразить, запилите в соло и покажите здесь опенворлд хотя бы уровня скайрима, 2011 года, слабо?)
В Скайрим не играл, но это вопрос количества контента, а не используемых технологий и не геймдизайна. Даже если ты будешь делать такое же количество контента в коридорной игре, ты не сможешь сделать быстро и в соло. Напротив, ты можешь сделать опенворлд с малым количеством контента.
>поэтому стоит сконцентрироваться на камерных проектах (камерность, это когда ворлд не опен), а тут террейны не нужны, тут нужнее генерация динамических коридоров с комнатами.
Ты путаешь несколько понятий.
Опенворлд - это не "равнины да горы, а вокруг море", а свобода перемещения. Если тебя геймдизайнер гонит по дороге без развилок через огромную равнину - это ни разу не опенворлд, это коридорная игра в стиле старых коридорных шутеров, только вместо декоративных стен тут теперь декоративные поля да луга.
Коридорная игра - это когда тебя гонят по "коридору" в единственно возможном направлении, заставляя проходить контент в строго определённой последовательности (крайне редко игра заставляет вернуться, сделать петлю или пройти по ответвлению, но сути это не меняет). Если ты запускаешь игрока в большое здание с кучей комнат и коридоров, давая возможность идти в любом направлении без ограничений, то это опенворлд, а не коридорная игра, несмотря на то, что визуально на экране только коридоры.
Т.е. опенворлд - это не про тип ландшафта, а только про свободу перемещения. Ранние игры могли показывать игроку широкие просторы, но ограничивали его узкими коридорами невидимых стен, либо просто не давали никаких задач за пределами узкого коридора. В то же время могут существовать игры про закрытые пространства вроде подземелья, башни или гигахруща, но с максимальной свободой движения, разбрасывая контент по большой площади/объёму и разрешая проходить контент в произвольном порядке - это оперворлды. Настоящих опенворлдов весьма мало...
>>69865
Сцена-предок, от которой наследует некоторое количество потомков, к тому же размещённых на уровнях. Такое пересохранять - это, считай, половину проекта создавать заново.
Эта стадия наступает уже после того, как ты освоился и изучил редактор. А видеоуроки смотрят новички, ещё плохо с ним знакомые.
https://youtu.be/rhgwIhB58PA
Видос, да, но под ним в описании ссылки на научные публикации.
Антош, не как что-то плохое, но ты аутист и ёбаный терминатор, помноженный на вечность. Таких, как ты, совсем мало. Большинству людей, чтобы лучше понимать тему, нужно получать информацию через несколько каналов, развлекательный формат помогает им сфокусироваться, а чувство причастности удерживает интерес. И большинству людей комфортнее видосы, как раз потому что полезная информация в них не так плотно сконцентрирована, как в текстовых туторах и доках. Большинству людей нужен живой человек-учитель, искренне эмоционально вовлечённый в предмет, а не бездушный текст. То, что тебе это всё не нужно, это не люди дебилы, а ты дохуя умный. Просто смирись с тем фактом, что другие люди не такие целеустремлённые, сфокусированные и душные, как ты.
>пересохранить
Сцена-предок, от которой наследует некоторое количество потомков, к тому же размещённых на уровнях. Такое пересохранять - это, считай, половину проекта создавать заново.
>Вот читаешь описание и видишь перед глазами как вживую.
Эта стадия наступает уже после того, как ты освоился и изучил редактор. А видеоуроки смотрят новички, ещё плохо с ним знакомые.
>Пруфы есть? Нет у тебя пруфов.
https://youtu.be/rhgwIhB58PA
Видос, да, но под ним в описании ссылки на научные публикации.
>Изучил множество нод только через встроенную в редактор документацию по API этих нод.
Антош, не как что-то плохое, но ты аутист и ёбаный терминатор, помноженный на вечность. Таких, как ты, совсем мало. Большинству людей, чтобы лучше понимать тему, нужно получать информацию через несколько каналов, развлекательный формат помогает им сфокусироваться, а чувство причастности удерживает интерес. И большинству людей комфортнее видосы, как раз потому что полезная информация в них не так плотно сконцентрирована, как в текстовых туторах и доках. Большинству людей нужен живой человек-учитель, искренне эмоционально вовлечённый в предмет, а не бездушный текст. То, что тебе это всё не нужно, это не люди дебилы, а ты дохуя умный. Просто смирись с тем фактом, что другие люди не такие целеустремлённые, сфокусированные и душные, как ты.
1,3 Мб, 1920x1080ЖТА - начало.
Пока продолжаю искать причину фризов, и в сцене с 5 домиками и 10 человечками.
Еще идея что возможно начинает свопить оперативку. Но непонятно из-за чего - ведь в редакторе все работает плавно.
Пока продолжаю искать причину фризов, и в сцене с 5 домиками и 10 человечками.
Еще идея что возможно начинает свопить оперативку. Но непонятно из-за чего - ведь в редакторе все работает плавно.
>>69929
А я вот не уверен. Я вот тоже учил программирование по книгам, причем у меня и компьютера тогда толком не было, я читал даже про несуществующие у меня пролог, PL/1 и паскаль, диалекты бейсика от другого компьютера, а так же про ассемблер 6502 в немецкой книге не зная немецкого. Потом по дороге в метро я читал книги по алгоритмам. И вот как то не требовалось чтобы кто то за руку по шагам вел (авторы качественной книги если только, поскольку дают материал структурировано) и какие то клоуны увеселяющие (хотя в книгах немного юмора было, но уместно и деликатно, а не как VSause посередине объяснения достает из под стола Йоду и начинает ебошить им об стол с воплями).
Я бы осторожно относился к ютуберам, которые поясняют за learning - это их хлеб, они могут навязывать нужную им точку зрения
> это не люди дебилы
А я вот не уверен. Я вот тоже учил программирование по книгам, причем у меня и компьютера тогда толком не было, я читал даже про несуществующие у меня пролог, PL/1 и паскаль, диалекты бейсика от другого компьютера, а так же про ассемблер 6502 в немецкой книге не зная немецкого. Потом по дороге в метро я читал книги по алгоритмам. И вот как то не требовалось чтобы кто то за руку по шагам вел (авторы качественной книги если только, поскольку дают материал структурировано) и какие то клоуны увеселяющие (хотя в книгах немного юмора было, но уместно и деликатно, а не как VSause посередине объяснения достает из под стола Йоду и начинает ебошить им об стол с воплями).
Я бы осторожно относился к ютуберам, которые поясняют за learning - это их хлеб, они могут навязывать нужную им точку зрения
>>69929
чел, это ты не такой, оскорбляешь другого анона, перекладываешь с больной головы на здоровую
давайте уже ближе к движку и играм, а для подобных срачей есть соседний тред
чел, это ты не такой, оскорбляешь другого анона, перекладываешь с больной головы на здоровую
давайте уже ближе к движку и играм, а для подобных срачей есть соседний тред
>>69935
Согласен, я попал в логическое заблуждение, ведь среди книг тоже есть всякие инфоцыганские.
Могу только сказать в оправдание что нормальные книги обычно проходят редактуру и рецензию издательства, то есть планка повыше чем у обычного ютубера.
Согласен, я попал в логическое заблуждение, ведь среди книг тоже есть всякие инфоцыганские.
Могу только сказать в оправдание что нормальные книги обычно проходят редактуру и рецензию издательства, то есть планка повыше чем у обычного ютубера.
>>69931
Ты решил полноценную игру делать?
Так ты проверь потребление памяти у процесса и сколько у тебя доступно сейчас. Windows всегда берёт в приоритет приложение, имеющее фокус, так что если у тебя хватает физической памяти для игры, она будет всегда в физической памяти, пока ты не альт-табнешься в другое приложение. Попробуй поиграть немного, ОС должна все фоновые приложения убрать в своп, если твоя игра занимает большую часть физической памяти. Выяснил это на собственном опыте работы с 1 ГБ оперативной памяти и единственным мобильным HDD.
>ЖТА - начало
Ты решил полноценную игру делать?
>начинает свопить оперативку
Так ты проверь потребление памяти у процесса и сколько у тебя доступно сейчас. Windows всегда берёт в приоритет приложение, имеющее фокус, так что если у тебя хватает физической памяти для игры, она будет всегда в физической памяти, пока ты не альт-табнешься в другое приложение. Попробуй поиграть немного, ОС должна все фоновые приложения убрать в своп, если твоя игра занимает большую часть физической памяти. Выяснил это на собственном опыте работы с 1 ГБ оперативной памяти и единственным мобильным HDD.
>>70039
Из этой - нет, но мне надо знать возможности для своей полноценной игры. Там планируется какой-никакой город.
Я пробовал и только экспорт релиз запускать, с закрытым браузером и редактором годота, ничего не улучшилось.
Буду искать дальше, когда время будет.
>Ты решил полноценную игру делать?
Из этой - нет, но мне надо знать возможности для своей полноценной игры. Там планируется какой-никакой город.
Я пробовал и только экспорт релиз запускать, с закрытым браузером и редактором годота, ничего не улучшилось.
Буду искать дальше, когда время будет.
>>70053
Это еще что! Мне еще надо персонажей замоделить. Ну и сидеть вникать в анатомию, мышцы, кости (человеческие)...
Это еще что! Мне еще надо персонажей замоделить. Ну и сидеть вникать в анатомию, мышцы, кости (человеческие)...
>>70040
Так что город тут еще самое простое... Тупо коробки как ты говоришь.
Так что город тут еще самое простое... Тупо коробки как ты говоришь.
А какой язык программирования нужно знать, чтобы делать игры на Godot?
Где-то говорят про сишарп, где-то про плюсы
Где-то говорят про сишарп, где-то про плюсы
>>70058
Самый простой - gdscript, похожий на питон
Есть версия движка где пишешь на c#, но им меньше пользуются, профит не такой большой.
C++ для тех кому надо уже перепиливать сам движок или подключать готовые либы на нем.
Самый простой - gdscript, похожий на питон
Есть версия движка где пишешь на c#, но им меньше пользуются, профит не такой большой.
C++ для тех кому надо уже перепиливать сам движок или подключать готовые либы на нем.
>>70040
А в диспетчер задач пробовал смотреть?
Лайвхаки для новичков, бесплатно:
1. ctrl+alt+delete
2. ctrl+shift+escape
Время настало советов мудрых, хорошо.
Реализуй самые важные геймплейные элементы на статичной сцене из пары домов и участка дороги или маленького квадратного квартала, огородив все выходы заборами, чтобы игра была на 100% играбельна и хорошо отражала Суть™ полной игры. Отладь все ключевые Системы а.к.а. Механики на этой сцене, отбросив все незначительные функции и контент. Не задумывайся об оптимизации "целого города" и его планировке: это пустая трата времени, пока у тебя нет реальной игры. Ты должен добиться того, чтобы ты мог запустить свой проект и поиграть в Свою Игру, даже если заборы не дают выйти с пятачка доступной для перемещения сцены.
Только когда ты убедишься, что твоя игра действительно доставляет фан а.к.а. твои идеи "работают" на этой ограниченной площадке, ты можешь начинать расширять сцену до целого города, и, по мере необходимости, решать проблемы производительности: материалы, текстурные атласы, меши, лоды, чанки, вот это всё скучное и низкоуровневое, что есть во многих играх, но игры вокруг себя не создаёт.
Главное, не ожидать того, что скучный геймплей на маленькой ограниченной сцене внезапно станет интересным и весёлым на некой абстрактной огромной карте с кучей оптимизирующих систем. Скорее всего не станет, потому что пространство - это чисто количественная характеристика, не добавляющая никакого качества в базовый геймплей. Если в игре нельзя заняться ничем интересным, то пусть в ней хоть целая планета - в ней по-прежнему нечем заняться. Ну, кроме симуляторов дальнобойщика/машиниста/пилота, но это совершенно другой жанр, там города - кучки примитивов, главное разработать сам транспорт.
Всё это нужно по двум причинам. Во-первых, поскольку ты работаешь один и сам на себя, тебе важно сохранять мотивацию. Если ты будешь месяцами ковырять оптимизацию целого города, не имея практически ничего из будущей игры, то ты неизбежно будешь терять мотивацию, т.к. время идёт, а к реализации игры ты ни на шаг не приблизился, и поиграть в свою игру не можешь, а сцена с огромным городом - не игра. Поэтому важно накидать базу игры на минимальной сцене и уже потом расширять её, чтобы было чувство, что ты реально делаешь игру, а не ковыряешь очередной никчёмный велосипед. Не оправдывайся, я уверен, это всё на бессознательном уровне действует на настроение и поведение, даже если на словах ты герой и готов пилить оптимальный рендеринг города, отложив саму игру на неопределённое будущее.
Во-вторых, нужно осознавать, что если твоя игра предполагает управление персонажем, то игрок 99% времени не будет видеть весь город целиком. Ему, по большому счёту, насрать на некий абстрактный город, количество квадратных километров и домиков. Игрок играет в каждый момент времени на какой-то сильно ограниченной локации. Он взаимодействует только с небольшими предметами и персонажами, а не целыми кварталами и километрами автодорог. Поэтому ты должен фокусироваться на опыте, который игрок получает, стоя между двумя домами или в каком-то переулке. И общую карту мира ты будешь рисовать, опираясь на то, как игрок будет играть на отдельных участках карты. Если ты поступишь наоборот, пытаясь заполнить большую карту локальным геймплеем, ты рискуешь слишком растянуть пустые участки, на которых игроку нечем заняться. Игроку нет пользы от гигантской горы в центре карты, на которой совершенно нечем заняться, и ты вряд ли сможешь придумать кучу развлечений для таких пустых, сильно растянутых участков. Даже в Майнкрафте это поняли и начали переделывать слишком пустые биомы, лол, а в игре типа ГТА от пустых пространств вообще никакой пользы. Поэтому рациональнее будет расширять маленький участок до большого города, а не натягивать геймплей на некий абстрактный большой город. Хотя, опять же, зависит от геймплея (ну, дальнобойщик въехал в город и почти сразу выехал, достаточно коробок накидать и готово, 10/10, буду возить контейнеры ещё, дайте повозить цистерну).
Я всё это осознал/признал спустя годы ковыряния в велосипедах и прототипах, так и не приступив к созданию реальной игры. Лучше поздно, чем никогда... А ты, давай, не повторяй моих ошибок - сделай сначала игру, а город как-нибудь потом.
Чтобы развеять твои сомнения по поводу движка: во-первых, оптимизировать можно что угодно, тем более в опенсурсе, а во-вторых, пока ты будешь делать игру на маленькой локации, выкатят уже не то, что 4.1, а даже 4.2, со всеми обещанными оптимизациями и багфиксами. Даже если ты решил флипать халявные ассетики, на достойный геймплей много времени уйдёт, движок сравнительно быстро развивается (уж точно быстрее 3D GTA от соло инди, оценивающего оптимизацию домиков до разработки игры вокруг/внутри этих домиков, говорю по своему опыту).
>>70053
К чему такой пессимизм? Вполне реально, имея чёткую цель и мотивацию, не ленясь и работая.
>>70056
Ну вот пока ты на это года два-три убьёшь, движок уже начнёт плавный переход к 5.0 версии...
>Я пробовал и только экспорт релиз запускать
А в диспетчер задач пробовал смотреть?
Лайвхаки для новичков, бесплатно:
1. ctrl+alt+delete
2. ctrl+shift+escape
>своей полноценной игры
>планируется какой-никакой город
Время настало советов мудрых, хорошо.
Реализуй самые важные геймплейные элементы на статичной сцене из пары домов и участка дороги или маленького квадратного квартала, огородив все выходы заборами, чтобы игра была на 100% играбельна и хорошо отражала Суть™ полной игры. Отладь все ключевые Системы а.к.а. Механики на этой сцене, отбросив все незначительные функции и контент. Не задумывайся об оптимизации "целого города" и его планировке: это пустая трата времени, пока у тебя нет реальной игры. Ты должен добиться того, чтобы ты мог запустить свой проект и поиграть в Свою Игру, даже если заборы не дают выйти с пятачка доступной для перемещения сцены.
Только когда ты убедишься, что твоя игра действительно доставляет фан а.к.а. твои идеи "работают" на этой ограниченной площадке, ты можешь начинать расширять сцену до целого города, и, по мере необходимости, решать проблемы производительности: материалы, текстурные атласы, меши, лоды, чанки, вот это всё скучное и низкоуровневое, что есть во многих играх, но игры вокруг себя не создаёт.
Главное, не ожидать того, что скучный геймплей на маленькой ограниченной сцене внезапно станет интересным и весёлым на некой абстрактной огромной карте с кучей оптимизирующих систем. Скорее всего не станет, потому что пространство - это чисто количественная характеристика, не добавляющая никакого качества в базовый геймплей. Если в игре нельзя заняться ничем интересным, то пусть в ней хоть целая планета - в ней по-прежнему нечем заняться. Ну, кроме симуляторов дальнобойщика/машиниста/пилота, но это совершенно другой жанр, там города - кучки примитивов, главное разработать сам транспорт.
Всё это нужно по двум причинам. Во-первых, поскольку ты работаешь один и сам на себя, тебе важно сохранять мотивацию. Если ты будешь месяцами ковырять оптимизацию целого города, не имея практически ничего из будущей игры, то ты неизбежно будешь терять мотивацию, т.к. время идёт, а к реализации игры ты ни на шаг не приблизился, и поиграть в свою игру не можешь, а сцена с огромным городом - не игра. Поэтому важно накидать базу игры на минимальной сцене и уже потом расширять её, чтобы было чувство, что ты реально делаешь игру, а не ковыряешь очередной никчёмный велосипед. Не оправдывайся, я уверен, это всё на бессознательном уровне действует на настроение и поведение, даже если на словах ты герой и готов пилить оптимальный рендеринг города, отложив саму игру на неопределённое будущее.
Во-вторых, нужно осознавать, что если твоя игра предполагает управление персонажем, то игрок 99% времени не будет видеть весь город целиком. Ему, по большому счёту, насрать на некий абстрактный город, количество квадратных километров и домиков. Игрок играет в каждый момент времени на какой-то сильно ограниченной локации. Он взаимодействует только с небольшими предметами и персонажами, а не целыми кварталами и километрами автодорог. Поэтому ты должен фокусироваться на опыте, который игрок получает, стоя между двумя домами или в каком-то переулке. И общую карту мира ты будешь рисовать, опираясь на то, как игрок будет играть на отдельных участках карты. Если ты поступишь наоборот, пытаясь заполнить большую карту локальным геймплеем, ты рискуешь слишком растянуть пустые участки, на которых игроку нечем заняться. Игроку нет пользы от гигантской горы в центре карты, на которой совершенно нечем заняться, и ты вряд ли сможешь придумать кучу развлечений для таких пустых, сильно растянутых участков. Даже в Майнкрафте это поняли и начали переделывать слишком пустые биомы, лол, а в игре типа ГТА от пустых пространств вообще никакой пользы. Поэтому рациональнее будет расширять маленький участок до большого города, а не натягивать геймплей на некий абстрактный большой город. Хотя, опять же, зависит от геймплея (ну, дальнобойщик въехал в город и почти сразу выехал, достаточно коробок накидать и готово, 10/10, буду возить контейнеры ещё, дайте повозить цистерну).
Я всё это осознал/признал спустя годы ковыряния в велосипедах и прототипах, так и не приступив к созданию реальной игры. Лучше поздно, чем никогда... А ты, давай, не повторяй моих ошибок - сделай сначала игру, а город как-нибудь потом.
Чтобы развеять твои сомнения по поводу движка: во-первых, оптимизировать можно что угодно, тем более в опенсурсе, а во-вторых, пока ты будешь делать игру на маленькой локации, выкатят уже не то, что 4.1, а даже 4.2, со всеми обещанными оптимизациями и багфиксами. Даже если ты решил флипать халявные ассетики, на достойный геймплей много времени уйдёт, движок сравнительно быстро развивается (уж точно быстрее 3D GTA от соло инди, оценивающего оптимизацию домиков до разработки игры вокруг/внутри этих домиков, говорю по своему опыту).
>>70053
>город
>в одно рыло
К чему такой пессимизм? Вполне реально, имея чёткую цель и мотивацию, не ленясь и работая.
>>70056
>Мне еще надо персонажей замоделить. Ну и сидеть вникать в анатомию, мышцы, кости (человеческие)...
Ну вот пока ты на это года два-три убьёшь, движок уже начнёт плавный переход к 5.0 версии...
>>70040
А в диспетчер задач пробовал смотреть?
Лайвхаки для новичков, бесплатно:
1. ctrl+alt+delete
2. ctrl+shift+escape
Время настало советов мудрых, хорошо.
Реализуй самые важные геймплейные элементы на статичной сцене из пары домов и участка дороги или маленького квадратного квартала, огородив все выходы заборами, чтобы игра была на 100% играбельна и хорошо отражала Суть™ полной игры. Отладь все ключевые Системы а.к.а. Механики на этой сцене, отбросив все незначительные функции и контент. Не задумывайся об оптимизации "целого города" и его планировке: это пустая трата времени, пока у тебя нет реальной игры. Ты должен добиться того, чтобы ты мог запустить свой проект и поиграть в Свою Игру, даже если заборы не дают выйти с пятачка доступной для перемещения сцены.
Только когда ты убедишься, что твоя игра действительно доставляет фан а.к.а. твои идеи "работают" на этой ограниченной площадке, ты можешь начинать расширять сцену до целого города, и, по мере необходимости, решать проблемы производительности: материалы, текстурные атласы, меши, лоды, чанки, вот это всё скучное и низкоуровневое, что есть во многих играх, но игры вокруг себя не создаёт.
Главное, не ожидать того, что скучный геймплей на маленькой ограниченной сцене внезапно станет интересным и весёлым на некой абстрактной огромной карте с кучей оптимизирующих систем. Скорее всего не станет, потому что пространство - это чисто количественная характеристика, не добавляющая никакого качества в базовый геймплей. Если в игре нельзя заняться ничем интересным, то пусть в ней хоть целая планета - в ней по-прежнему нечем заняться. Ну, кроме симуляторов дальнобойщика/машиниста/пилота, но это совершенно другой жанр, там города - кучки примитивов, главное разработать сам транспорт.
Всё это нужно по двум причинам. Во-первых, поскольку ты работаешь один и сам на себя, тебе важно сохранять мотивацию. Если ты будешь месяцами ковырять оптимизацию целого города, не имея практически ничего из будущей игры, то ты неизбежно будешь терять мотивацию, т.к. время идёт, а к реализации игры ты ни на шаг не приблизился, и поиграть в свою игру не можешь, а сцена с огромным городом - не игра. Поэтому важно накидать базу игры на минимальной сцене и уже потом расширять её, чтобы было чувство, что ты реально делаешь игру, а не ковыряешь очередной никчёмный велосипед. Не оправдывайся, я уверен, это всё на бессознательном уровне действует на настроение и поведение, даже если на словах ты герой и готов пилить оптимальный рендеринг города, отложив саму игру на неопределённое будущее.
Во-вторых, нужно осознавать, что если твоя игра предполагает управление персонажем, то игрок 99% времени не будет видеть весь город целиком. Ему, по большому счёту, насрать на некий абстрактный город, количество квадратных километров и домиков. Игрок играет в каждый момент времени на какой-то сильно ограниченной локации. Он взаимодействует только с небольшими предметами и персонажами, а не целыми кварталами и километрами автодорог. Поэтому ты должен фокусироваться на опыте, который игрок получает, стоя между двумя домами или в каком-то переулке. И общую карту мира ты будешь рисовать, опираясь на то, как игрок будет играть на отдельных участках карты. Если ты поступишь наоборот, пытаясь заполнить большую карту локальным геймплеем, ты рискуешь слишком растянуть пустые участки, на которых игроку нечем заняться. Игроку нет пользы от гигантской горы в центре карты, на которой совершенно нечем заняться, и ты вряд ли сможешь придумать кучу развлечений для таких пустых, сильно растянутых участков. Даже в Майнкрафте это поняли и начали переделывать слишком пустые биомы, лол, а в игре типа ГТА от пустых пространств вообще никакой пользы. Поэтому рациональнее будет расширять маленький участок до большого города, а не натягивать геймплей на некий абстрактный большой город. Хотя, опять же, зависит от геймплея (ну, дальнобойщик въехал в город и почти сразу выехал, достаточно коробок накидать и готово, 10/10, буду возить контейнеры ещё, дайте повозить цистерну).
Я всё это осознал/признал спустя годы ковыряния в велосипедах и прототипах, так и не приступив к созданию реальной игры. Лучше поздно, чем никогда... А ты, давай, не повторяй моих ошибок - сделай сначала игру, а город как-нибудь потом.
Чтобы развеять твои сомнения по поводу движка: во-первых, оптимизировать можно что угодно, тем более в опенсурсе, а во-вторых, пока ты будешь делать игру на маленькой локации, выкатят уже не то, что 4.1, а даже 4.2, со всеми обещанными оптимизациями и багфиксами. Даже если ты решил флипать халявные ассетики, на достойный геймплей много времени уйдёт, движок сравнительно быстро развивается (уж точно быстрее 3D GTA от соло инди, оценивающего оптимизацию домиков до разработки игры вокруг/внутри этих домиков, говорю по своему опыту).
>>70053
К чему такой пессимизм? Вполне реально, имея чёткую цель и мотивацию, не ленясь и работая.
>>70056
Ну вот пока ты на это года два-три убьёшь, движок уже начнёт плавный переход к 5.0 версии...
>Я пробовал и только экспорт релиз запускать
А в диспетчер задач пробовал смотреть?
Лайвхаки для новичков, бесплатно:
1. ctrl+alt+delete
2. ctrl+shift+escape
>своей полноценной игры
>планируется какой-никакой город
Время настало советов мудрых, хорошо.
Реализуй самые важные геймплейные элементы на статичной сцене из пары домов и участка дороги или маленького квадратного квартала, огородив все выходы заборами, чтобы игра была на 100% играбельна и хорошо отражала Суть™ полной игры. Отладь все ключевые Системы а.к.а. Механики на этой сцене, отбросив все незначительные функции и контент. Не задумывайся об оптимизации "целого города" и его планировке: это пустая трата времени, пока у тебя нет реальной игры. Ты должен добиться того, чтобы ты мог запустить свой проект и поиграть в Свою Игру, даже если заборы не дают выйти с пятачка доступной для перемещения сцены.
Только когда ты убедишься, что твоя игра действительно доставляет фан а.к.а. твои идеи "работают" на этой ограниченной площадке, ты можешь начинать расширять сцену до целого города, и, по мере необходимости, решать проблемы производительности: материалы, текстурные атласы, меши, лоды, чанки, вот это всё скучное и низкоуровневое, что есть во многих играх, но игры вокруг себя не создаёт.
Главное, не ожидать того, что скучный геймплей на маленькой ограниченной сцене внезапно станет интересным и весёлым на некой абстрактной огромной карте с кучей оптимизирующих систем. Скорее всего не станет, потому что пространство - это чисто количественная характеристика, не добавляющая никакого качества в базовый геймплей. Если в игре нельзя заняться ничем интересным, то пусть в ней хоть целая планета - в ней по-прежнему нечем заняться. Ну, кроме симуляторов дальнобойщика/машиниста/пилота, но это совершенно другой жанр, там города - кучки примитивов, главное разработать сам транспорт.
Всё это нужно по двум причинам. Во-первых, поскольку ты работаешь один и сам на себя, тебе важно сохранять мотивацию. Если ты будешь месяцами ковырять оптимизацию целого города, не имея практически ничего из будущей игры, то ты неизбежно будешь терять мотивацию, т.к. время идёт, а к реализации игры ты ни на шаг не приблизился, и поиграть в свою игру не можешь, а сцена с огромным городом - не игра. Поэтому важно накидать базу игры на минимальной сцене и уже потом расширять её, чтобы было чувство, что ты реально делаешь игру, а не ковыряешь очередной никчёмный велосипед. Не оправдывайся, я уверен, это всё на бессознательном уровне действует на настроение и поведение, даже если на словах ты герой и готов пилить оптимальный рендеринг города, отложив саму игру на неопределённое будущее.
Во-вторых, нужно осознавать, что если твоя игра предполагает управление персонажем, то игрок 99% времени не будет видеть весь город целиком. Ему, по большому счёту, насрать на некий абстрактный город, количество квадратных километров и домиков. Игрок играет в каждый момент времени на какой-то сильно ограниченной локации. Он взаимодействует только с небольшими предметами и персонажами, а не целыми кварталами и километрами автодорог. Поэтому ты должен фокусироваться на опыте, который игрок получает, стоя между двумя домами или в каком-то переулке. И общую карту мира ты будешь рисовать, опираясь на то, как игрок будет играть на отдельных участках карты. Если ты поступишь наоборот, пытаясь заполнить большую карту локальным геймплеем, ты рискуешь слишком растянуть пустые участки, на которых игроку нечем заняться. Игроку нет пользы от гигантской горы в центре карты, на которой совершенно нечем заняться, и ты вряд ли сможешь придумать кучу развлечений для таких пустых, сильно растянутых участков. Даже в Майнкрафте это поняли и начали переделывать слишком пустые биомы, лол, а в игре типа ГТА от пустых пространств вообще никакой пользы. Поэтому рациональнее будет расширять маленький участок до большого города, а не натягивать геймплей на некий абстрактный большой город. Хотя, опять же, зависит от геймплея (ну, дальнобойщик въехал в город и почти сразу выехал, достаточно коробок накидать и готово, 10/10, буду возить контейнеры ещё, дайте повозить цистерну).
Я всё это осознал/признал спустя годы ковыряния в велосипедах и прототипах, так и не приступив к созданию реальной игры. Лучше поздно, чем никогда... А ты, давай, не повторяй моих ошибок - сделай сначала игру, а город как-нибудь потом.
Чтобы развеять твои сомнения по поводу движка: во-первых, оптимизировать можно что угодно, тем более в опенсурсе, а во-вторых, пока ты будешь делать игру на маленькой локации, выкатят уже не то, что 4.1, а даже 4.2, со всеми обещанными оптимизациями и багфиксами. Даже если ты решил флипать халявные ассетики, на достойный геймплей много времени уйдёт, движок сравнительно быстро развивается (уж точно быстрее 3D GTA от соло инди, оценивающего оптимизацию домиков до разработки игры вокруг/внутри этих домиков, говорю по своему опыту).
>>70053
>город
>в одно рыло
К чему такой пессимизм? Вполне реально, имея чёткую цель и мотивацию, не ленясь и работая.
>>70056
>Мне еще надо персонажей замоделить. Ну и сидеть вникать в анатомию, мышцы, кости (человеческие)...
Ну вот пока ты на это года два-три убьёшь, движок уже начнёт плавный переход к 5.0 версии...
>>70059
А совмещать языки можно?
Просто я представляю как напишу игру и решу добавить в неё рекламу, а не смогу на GDScript
А совмещать языки можно?
Просто я представляю как напишу игру и решу добавить в неё рекламу, а не смогу на GDScript
>>69929
Расписал тебе пост почти до лимита символов, но потом плюнул и удалил. Смысла объяснять тебе что-то нет, ведь ты текст не воспринимаешь - тебе обязательно нужно видео записать. С шутками и мемами. Растянув на несколько часов...
Расписал тебе пост почти до лимита символов, но потом плюнул и удалил. Смысла объяснять тебе что-то нет, ведь ты текст не воспринимаешь - тебе обязательно нужно видео записать. С шутками и мемами. Растянув на несколько часов...
>>70058
Обязательно нужно GDScript - это внутренний язык движка, на котором происходит разработка у большинства пользователей движка. Как минимум требуется понимать то, что пишут другие.
>>70062
Да, любые языки, в любых комбинациях.
Для 3.x видел готовые аддоны, для 4.0 не знаю.
>какой язык программирования нужно знать
Обязательно нужно GDScript - это внутренний язык движка, на котором происходит разработка у большинства пользователей движка. Как минимум требуется понимать то, что пишут другие.
>>70062
>А совмещать языки можно?
Да, любые языки, в любых комбинациях.
>добавить в неё рекламу
Для 3.x видел готовые аддоны, для 4.0 не знаю.
>>70058
gsdcript, если потребуются производительные места, в которых будет упор, то немного плюсы на уровне для чайника за 21 день
> А какой язык программирования нужно знать, чтобы делать игры на Godot?
gsdcript, если потребуются производительные места, в которых будет упор, то немного плюсы на уровне для чайника за 21 день
>>70067
Честно говоря, сомнительная рекомендация. Реально оптимизировать алгоритмы нужно уметь, со знанием работы компьютера, структур данных, затрат на конкретные операции и т.п. Так что способности написать хэллоу ворлд на C++ вряд ли достаточно.
Может так получиться, что после месяца перевода алгоритма с GDScript на C++ у новичка не будет существенного выигрыша производительности, но зато появится утечка памяти, которую он не заметит. Вот весело ему будет дебажить всё это...
>потребуются производительные места
>плюсы на уровне для чайника за 21 день
Честно говоря, сомнительная рекомендация. Реально оптимизировать алгоритмы нужно уметь, со знанием работы компьютера, структур данных, затрат на конкретные операции и т.п. Так что способности написать хэллоу ворлд на C++ вряд ли достаточно.
Может так получиться, что после месяца перевода алгоритма с GDScript на C++ у новичка не будет существенного выигрыша производительности, но зато появится утечка памяти, которую он не заметит. Вот весело ему будет дебажить всё это...
https://www.youtube.com/watch?v=ynZVK_XyaRc
Есть ли лучше примеры разрезания мешей в Годоте? Чёт тут всё так топорно и лагает пиздец. В юнити и анриле намного лучше примеры видел.
Есть ли лучше примеры разрезания мешей в Годоте? Чёт тут всё так топорно и лагает пиздец. В юнити и анриле намного лучше примеры видел.
>>70161
Код на гитхабе смотрел? Там велосипед на 600+ строк генерации меша на GDScript. Конечно, это глючно и медленно, тут матан задействован.
Если хочешь без матана и из коробки:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
https://docs.godotengine.org/en/stable/classes/class_csgmesh3d.html
1. Делаешь объект из CSG шейпов.
2. Добавляешь CSG коробку нужного размера.
3. Выбираешь OPERATION_SUBTRACTION.
4. Готово, от меша остался огрызок.
Всё это производится на ЦПУ, так что ожидай лагов при слишком хайполи геометрии, алсо результирующий меш зачастую говно и может иметь небольшие артефакты, но зато это встроено в движок на C++ и для использования не нужно знать никакой матан, как обезьяна кидаешь ноды и радуисся результатам.
Если хочешь прям что-то супер-пупер, тут остаётся только самому пилить велосипед низкоуровневый.
Это ты, >>70056? Хочешь людей резать на мясо?
Забей на матан, делай как в Dead Island 1 - заранее заготовленные куски тел, которые отрубаются строго в определённых местах. Главное чтобы игра была, а это всё лишние декорации, пустая трата сил.
>всё так топорно и лагает
Код на гитхабе смотрел? Там велосипед на 600+ строк генерации меша на GDScript. Конечно, это глючно и медленно, тут матан задействован.
>примеры разрезания мешей
Если хочешь без матана и из коробки:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
https://docs.godotengine.org/en/stable/classes/class_csgmesh3d.html
1. Делаешь объект из CSG шейпов.
2. Добавляешь CSG коробку нужного размера.
3. Выбираешь OPERATION_SUBTRACTION.
4. Готово, от меша остался огрызок.
Всё это производится на ЦПУ, так что ожидай лагов при слишком хайполи геометрии, алсо результирующий меш зачастую говно и может иметь небольшие артефакты, но зато это встроено в движок на C++ и для использования не нужно знать никакой матан, как обезьяна кидаешь ноды и радуисся результатам.
Если хочешь прям что-то супер-пупер, тут остаётся только самому пилить велосипед низкоуровневый.
Это ты, >>70056? Хочешь людей резать на мясо?
Забей на матан, делай как в Dead Island 1 - заранее заготовленные куски тел, которые отрубаются строго в определённых местах. Главное чтобы игра была, а это всё лишние декорации, пустая трата сил.
>>70156
в плюсах уже около 15 лет также просто баловаться динамическим выделением памяти и не следить, что что-то не высвободил, держу в курсе
в плюсах уже около 15 лет также просто баловаться динамическим выделением памяти и не следить, что что-то не высвободил, держу в курсе
>>70173
Ну нет, ты не пони, я хочу загружать любой меш и рубить его.
Пичаль/бида, на анриле и юньке всё это без проблем
Пиздос. Мне игру делать надо а не это ваше низкоуровневое говно!
Не, я вообще тут почти не сижу. Выбираю сейчас на каком движке игру пилить.
Ну не, если можно это реализовать с меньшим гемором на другом двигле, я просто выберу другое двигло. У меня есть набор параметров, по которым я выбираю, и сейчас лбами столкнулись анрил и юнити, годот с каждым разом всё больше и больше уходит на второй план, у него из очевидных плюсов только бесплатность пока что.
>>70182
Тогда зачем страуструп в своей книге такое пристальное внимание уделяет этому?
>Делаешь объект из CSG шейпов.
Ну нет, ты не пони, я хочу загружать любой меш и рубить его.
>Всё это производится на ЦПУ, так что ожидай лагов при слишком хайполи геометрии, алсо результирующий меш зачастую говно и может иметь небольшие артефакты, но зато это встроено в движок на C++ и для использования не нужно знать никакой матан, как обезьяна кидаешь ноды и радуисся результатам.
Пичаль/бида, на анриле и юньке всё это без проблем
>Если хочешь прям что-то супер-пупер, тут остаётся только самому пилить велосипед низкоуровневый.
Пиздос. Мне игру делать надо а не это ваше низкоуровневое говно!
>Это ты, >>70056? Хочешь людей резать на мясо?
Не, я вообще тут почти не сижу. Выбираю сейчас на каком движке игру пилить.
>Забей на матан, делай как в Dead Island 1 - заранее заготовленные куски тел, которые отрубаются строго в определённых местах. Главное чтобы игра была, а это всё лишние декорации, пустая трата сил.
Ну не, если можно это реализовать с меньшим гемором на другом двигле, я просто выберу другое двигло. У меня есть набор параметров, по которым я выбираю, и сейчас лбами столкнулись анрил и юнити, годот с каждым разом всё больше и больше уходит на второй план, у него из очевидных плюсов только бесплатность пока что.
>>70182
Тогда зачем страуструп в своей книге такое пристальное внимание уделяет этому?
86 Кб, 676x545>>70185
Нет ты не пони. Берешь CSGMesh и грузишь в него свой меш. Узнаёшь обезьянку на пикче?
> Ну нет, ты не пони, я хочу загружать любой меш и рубить его.
Нет ты не пони. Берешь CSGMesh и грузишь в него свой меш. Узнаёшь обезьянку на пикче?
>>70216
Сложные меши плохо режутся. В Holer стримеры ныли что из простреленной утки торчат цилиндры.
Сложные меши плохо режутся. В Holer стримеры ныли что из простреленной утки торчат цилиндры.
>>70216
Когда-то давным давно пытался вкатиться в блендер. Не удалось, но с обезьянкой успел познакомиться.
>Узнаёшь обезьянку на пикче?
Когда-то давным давно пытался вкатиться в блендер. Не удалось, но с обезьянкой успел познакомиться.
>>70185
1) потому что это часть возможностей языка и она сложнее прочих
2) она требуется буквально небольшому количеству кодеров на плюсах, у остальных уже готовые контейнеры и алгоритмы в библиотеках есть, которыми они просто жонгрлируют
3) потому что остальная часть плюсов уже простая, поэтому и кажется, что им уделяется не столь важное место, хотя там просто почти и не о чем рассказывать, там все не сильно сложнее хипстерских питонов, на которых тоже байтоебством занимаются к слову, что также не избавляет от того, что программисту все равно стоит это знать
> Тогда зачем страуструп в своей книге такое пристальное внимание уделяет этому?
1) потому что это часть возможностей языка и она сложнее прочих
2) она требуется буквально небольшому количеству кодеров на плюсах, у остальных уже готовые контейнеры и алгоритмы в библиотеках есть, которыми они просто жонгрлируют
3) потому что остальная часть плюсов уже простая, поэтому и кажется, что им уделяется не столь важное место, хотя там просто почти и не о чем рассказывать, там все не сильно сложнее хипстерских питонов, на которых тоже байтоебством занимаются к слову, что также не избавляет от того, что программисту все равно стоит это знать
>>70222
Годно, схоронил. Но не вкатился я тогда в по той же причине почему тогда же не вкатился в геймдев - я был другим человеком.
Годно, схоронил. Но не вкатился я тогда в по той же причине почему тогда же не вкатился в геймдев - я был другим человеком.
>>70061
Смотрел, но там ничего не понятно. Впрочем, в process explorer тоже непонятно. Выделение памяти в винде это еще те загадки, с working set-ами.
Я с этого и начал, но 4-ка уже на этом пукнула. Она не пукает только совсем в простом тестовом случае с кубами и текстурами для прототипинга.
С самим геймплеем все в порядке, я его уже тестировал год назад, правда его никто особо не заценил, но с тех пор я еще поиграл в схожие игры и буду копировать оттуда многое, что понравилось.
Собственно, и город я тоже собирался скопировать, ведь на этом же компе в той игре он не тормозит, значит в нем никаких проблем нет. Алсо, город в основном на фоне, не обязательно даже чтобы туда везде ходить можно было (хотя было бы неплохо). Но тут вот какой то фундаментальный затык в 4-ке.
Да, если ты не понял, меня не интересуют советы по геймдизайну. Тут меня только интересует, как пофиксить 4-ку.
Больше всего удивляет, что в редакторе нет никаких тормозов, я могу свободно летать по городу, то есть отличия только в полной версии, которая запускается. Даже если закрыть все и запускать только экспорт.
причем я пробовал и свет удалять, и ворлд энвайронмент, и понижать разрешения атласов.
Сейчас попробовал минимальные условия. Контроллер+ворлд работает, контроллер+директ лайт работает, контроллер+ворлд+директ лайт уже пукает. Но, контроллер+домики без ворлд и директ лайт тоже пукают.
Но почему в редакторе не пукает, в чем разница. Пока только мысль, что что-то включается и жрет неадекватно много памяти.
>А в диспетчер задач пробовал смотреть?
Смотрел, но там ничего не понятно. Впрочем, в process explorer тоже непонятно. Выделение памяти в винде это еще те загадки, с working set-ами.
>Реализуй самые важные геймплейные элементы на статичной сцене из пары домов и участка дороги
Я с этого и начал, но 4-ка уже на этом пукнула. Она не пукает только совсем в простом тестовом случае с кубами и текстурами для прототипинга.
С самим геймплеем все в порядке, я его уже тестировал год назад, правда его никто особо не заценил, но с тех пор я еще поиграл в схожие игры и буду копировать оттуда многое, что понравилось.
Собственно, и город я тоже собирался скопировать, ведь на этом же компе в той игре он не тормозит, значит в нем никаких проблем нет. Алсо, город в основном на фоне, не обязательно даже чтобы туда везде ходить можно было (хотя было бы неплохо). Но тут вот какой то фундаментальный затык в 4-ке.
Да, если ты не понял, меня не интересуют советы по геймдизайну. Тут меня только интересует, как пофиксить 4-ку.
Больше всего удивляет, что в редакторе нет никаких тормозов, я могу свободно летать по городу, то есть отличия только в полной версии, которая запускается. Даже если закрыть все и запускать только экспорт.
причем я пробовал и свет удалять, и ворлд энвайронмент, и понижать разрешения атласов.
Сейчас попробовал минимальные условия. Контроллер+ворлд работает, контроллер+директ лайт работает, контроллер+ворлд+директ лайт уже пукает. Но, контроллер+домики без ворлд и директ лайт тоже пукают.
Но почему в редакторе не пукает, в чем разница. Пока только мысль, что что-то включается и жрет неадекватно много памяти.
>>70362
У четвёрки вообще проблема с релизным билдом. Я ранее жаловался. Там тупо пустой проект притормаживает, экспортированный. Но видать Хуану не до того. Ждём фиксов.
А пока что экспортируй в режиме дебага.
У четвёрки вообще проблема с релизным билдом. Я ранее жаловался. Там тупо пустой проект притормаживает, экспортированный. Но видать Хуану не до того. Ждём фиксов.
А пока что экспортируй в режиме дебага.
>>70287
У меня такая же модель, можешь скинуть мне свои пукающие проекты? Я попробую запустить, может, смогу найти причину тормозов. Если не лень будет.
Ну, ты удали лишнее, конечно. Сами модели скинь, или ссылки на официальную страницу с ними.
А то мне уже любопытно, что там у тебя творится. Я сейчас думаю начать разработку с нуля, в четвёрке разобраться получше нужно.
Хм... А ты компьютер часто выключаешь? Не в режим гибернации, а полностью. Т.е. полную перезагрузку часто делаешь? У меня сейчас 50 дней непрерывно компьютер работает, и я совершенно случайно обнаружил медленную утечку (видео)памяти в Explorer, которая, по слухам, из-за драйверов видеокарты. Если ты долго не перезагружаешь комп и у тебя похожая версия драйвера, вполне может быть, что у тебя сейчас почти вся память заполнена Explorer'ом, из-за чего возникают проблемы. Обнаружил так: у меня суммарно 24 ГБ памяти, 8 физической и 16 виртуальной, было занято 20/24 ГБ и Майнкрафт крашился во время загрузки, а когда я перезапустил Explorer (рабочий стол), память освободилась до 3/24 ГБ и всё заработало. Очень странная утечка, раньше замечал её, но не придавал значения и не понимал, откуда она. В диспетчере задач не было точного потребления Explorer, только то, что он выделил под себя почти 2 ГБ видеопамяти и 500 МБ оперативной, куда он заныкал 17 ГБ - непонятно. В интернете нашёл мало обсуждений, но говорят, что это может быть из-за компиляции шейдеров видеокартой, потому что Explorer что-то неправильно рисует.
>GTX 750 Ti
У меня такая же модель, можешь скинуть мне свои пукающие проекты? Я попробую запустить, может, смогу найти причину тормозов. Если не лень будет.
Ну, ты удали лишнее, конечно. Сами модели скинь, или ссылки на официальную страницу с ними.
А то мне уже любопытно, что там у тебя творится. Я сейчас думаю начать разработку с нуля, в четвёрке разобраться получше нужно.
Хм... А ты компьютер часто выключаешь? Не в режим гибернации, а полностью. Т.е. полную перезагрузку часто делаешь? У меня сейчас 50 дней непрерывно компьютер работает, и я совершенно случайно обнаружил медленную утечку (видео)памяти в Explorer, которая, по слухам, из-за драйверов видеокарты. Если ты долго не перезагружаешь комп и у тебя похожая версия драйвера, вполне может быть, что у тебя сейчас почти вся память заполнена Explorer'ом, из-за чего возникают проблемы. Обнаружил так: у меня суммарно 24 ГБ памяти, 8 физической и 16 виртуальной, было занято 20/24 ГБ и Майнкрафт крашился во время загрузки, а когда я перезапустил Explorer (рабочий стол), память освободилась до 3/24 ГБ и всё заработало. Очень странная утечка, раньше замечал её, но не придавал значения и не понимал, откуда она. В диспетчере задач не было точного потребления Explorer, только то, что он выделил под себя почти 2 ГБ видеопамяти и 500 МБ оперативной, куда он заныкал 17 ГБ - непонятно. В интернете нашёл мало обсуждений, но говорят, что это может быть из-за компиляции шейдеров видеокартой, потому что Explorer что-то неправильно рисует.
21,9 Мб, mp4,1920x1080, 0:30
>>70362
Поужимал текстурки, избавился от некоторых тяжелых моделей, и заработало в релизе.
Очевидное неудобство в том, что одновременно редактор и дебаг у меня комп не тянет, поэтому для запуска приходится закрывать редактор. Но все таки думаю, что что-то там нездорово память кушает, если даже с пустой сценой с человечком были траблы.
Поужимал текстурки, избавился от некоторых тяжелых моделей, и заработало в релизе.
Очевидное неудобство в том, что одновременно редактор и дебаг у меня комп не тянет, поэтому для запуска приходится закрывать редактор. Но все таки думаю, что что-то там нездорово память кушает, если даже с пустой сценой с человечком были траблы.
>>70387
Опс, случайно конвертнулось.
>>70372
Как нибудь попозже. Может немного еще оптимизну, папка (и пак) весит 750 Мб, как то многовато для такого лоу поли контента. У машинок еще что-то продублировалось. А в остальном около 60 уникальных домиков, там вроде нечего уже ужимать, но думаю для моих задач достаточно.
Опс, случайно конвертнулось.
>>70372
Как нибудь попозже. Может немного еще оптимизну, папка (и пак) весит 750 Мб, как то многовато для такого лоу поли контента. У машинок еще что-то продублировалось. А в остальном около 60 уникальных домиков, там вроде нечего уже ужимать, но думаю для моих задач достаточно.
>>70387
а оно точно уже подходит для такого рода 3d игр?
у нас после бэток еще не совсем идеально гладко с мобилочными 2d, хоть и ничего критичного
думаю, что для gta-подобных игр там на одних скриптах не уедешь, нужно будет спускаться на уровень плюсов
а оно точно уже подходит для такого рода 3d игр?
у нас после бэток еще не совсем идеально гладко с мобилочными 2d, хоть и ничего критичного
думаю, что для gta-подобных игр там на одних скриптах не уедешь, нужно будет спускаться на уровень плюсов
>>70387
Будет очень тяжко девелопить видеоигру на калькуляторе. Сочувствую.
> одновременно редактор и дебаг у меня комп не тянет
Будет очень тяжко девелопить видеоигру на калькуляторе. Сочувствую.
6 Кб, 528x124Главное что при разрастании проекта, стали проявляться снова косяки вулкана, которые были в альфе. Когда картинка сыпется.
3,1 Мб, 1920x1080С ассетом травой и террейном 30 фпс, но они конечно не готовы для проды.
Но в целом некая вера в 4 появилась, это уже сравнимо с тем, что я на 3 делал 3 года назад
Но в целом некая вера в 4 появилась, это уже сравнимо с тем, что я на 3 делал 3 года назад
>>70513
Пока просто эту тиснул не разбираясь https://godotengine.org/asset-library/asset/1623
Он на основе мультимеша, есть ветер, должна еще приминаться, но что-то координаты игрока в шейдер не передались.
Есть какая-то оптимизация по дальности.
Ну и она криво расставилась, местами в воздухе висит.
В террейне тоже заявлена трава, но ее еще не пробовал, скорее всего там мало чего есть.
Пока просто эту тиснул не разбираясь https://godotengine.org/asset-library/asset/1623
Он на основе мультимеша, есть ветер, должна еще приминаться, но что-то координаты игрока в шейдер не передались.
Есть какая-то оптимизация по дальности.
Ну и она криво расставилась, местами в воздухе висит.
В террейне тоже заявлена трава, но ее еще не пробовал, скорее всего там мало чего есть.
>>70517
Надо еще попробовать траве тени отключить.
Надо еще попробовать траве тени отключить.
>>70519
Вдохновляющая демка. Класс! Так и хочется сесть уже и начать делать игру, только вот за годы изучения годота мотивация окончательно ушла.
Вдохновляющая демка. Класс! Так и хочется сесть уже и начать делать игру, только вот за годы изучения годота мотивация окончательно ушла.
554 Кб, 1180x311>>70526
Видяха больше нигде не сыпется, впрочем на вулкане я редко что-то запускаю, но это очевидно его особенность.
https://www.reddit.com/r/vulkan/comments/y4l3cu/how_to_debug_vulkan_graphics_artifacts/
Ну и вроде были подтвержденные, опять же они только в 4 появились, в 3 такого нет.
Видяха больше нигде не сыпется, впрочем на вулкане я редко что-то запускаю, но это очевидно его особенность.
https://www.reddit.com/r/vulkan/comments/y4l3cu/how_to_debug_vulkan_graphics_artifacts/
Ну и вроде были подтвержденные, опять же они только в 4 появились, в 3 такого нет.
>>70527
Но сцена опять небольшая. Но приятная. Немного Black Mesa Xen напомнило.
Но сцена опять небольшая. Но приятная. Немного Black Mesa Xen напомнило.
>>70527
Не понял. Godot лишает мотивации к геймдеву?
>Так и хочется сесть уже и начать делать игру, только вот за годы изучения годота мотивация окончательно ушла.
Не понял. Godot лишает мотивации к геймдеву?
>>70556
Ты пытаешься понять каждого рандома написавшего что-то в интернете? Бросай, это бесполезное занятие.
Ты пытаешься понять каждого рандома написавшего что-то в интернете? Бросай, это бесполезное занятие.
20 Кб, 603x170Едрить заявочка, лол.
Мда, на слабом ноуте четверка вообще не работает. Просто фризится намертво каждые несколько минут, даже если редактируешь простую 2D-сцену и не используешь вулкан, хотя 3.5 версия как работала отлично, так и работает. Придется ждать 4.1 похоже, может пофиксят.
>>70702
А игры запускал?
А игры запускал?
>>70833
С 3 раза открылась. Сначала просто упала, потом ругалась на то, что класс скрывает сам себя, видимо закешировался. В остальном вроде все так же.
С 3 раза открылась. Сначала просто упала, потом ругалась на то, что класс скрывает сам себя, видимо закешировался. В остальном вроде все так же.
>>70836
Полчаса пытался заставить работать на андроиде. Вулкан версия рисует 2д гуй, но вместо 3д черный экран и куча ошибок в логах про vulkan. Как нибудь соберу инфы на багрепорт. ОпенГЛ версия просто падает без объяснений, но она, возможно, и не экспортнулась, так как там какие то траблы с переключением рендера в свойствах проекта. Печально.
Алсо телефон не новый, вулкан на нем до этого не пробовал, но и обновить я на нем ничего не смогу.
Полчаса пытался заставить работать на андроиде. Вулкан версия рисует 2д гуй, но вместо 3д черный экран и куча ошибок в логах про vulkan. Как нибудь соберу инфы на багрепорт. ОпенГЛ версия просто падает без объяснений, но она, возможно, и не экспортнулась, так как там какие то траблы с переключением рендера в свойствах проекта. Печально.
Алсо телефон не новый, вулкан на нем до этого не пробовал, но и обновить я на нем ничего не смогу.
>>70849
AIDA64 > Отображение > Рендерер ГП
Копируешь долгим нажатием и ищешь:
https://www.notebookcheck.net
Если телефон старше 2016, вулкана в нём нет.
>телефон не новый
AIDA64 > Отображение > Рендерер ГП
Копируешь долгим нажатием и ищешь:
https://www.notebookcheck.net
Если телефон старше 2016, вулкана в нём нет.
>>70855
Если бы в нем не было, то гуй не отрисовался бы. Игра не падает, но вот под 3д там много ошибок вулкана, я в нем не разбираюсь. Что-то про то, что не создан буффер, и что не то количество каких то данных при вызове.
Если бы в нем не было, то гуй не отрисовался бы. Игра не падает, но вот под 3д там много ошибок вулкана, я в нем не разбираюсь. Что-то про то, что не создан буффер, и что не то количество каких то данных при вызове.
>>70857
Конечно, вот завтра поменяю домики на хрущевки и тачки на жигули и будет ГТА в Питере, как мечтали в детстве.
На самом деле стриминга же в движке нет, поэтому просто статичный город для теста.
Машина - за полчаса сделанный порт "аркадного шарика".
https://kidscancode.org/godot_recipes/3.x/3d/3d_sphere_car/
Для 4-ки не было под рукой ассета с машинками. Потом видел парочку, но там как то заебисто все, и колеса там на рейкастах.
>Не могу понять, ты всерьёз ГТА делаешь?
Конечно, вот завтра поменяю домики на хрущевки и тачки на жигули и будет ГТА в Питере, как мечтали в детстве.
На самом деле стриминга же в движке нет, поэтому просто статичный город для теста.
>Машина - KinematicBody?
Машина - за полчаса сделанный порт "аркадного шарика".
https://kidscancode.org/godot_recipes/3.x/3d/3d_sphere_car/
Для 4-ки не было под рукой ассета с машинками. Потом видел парочку, но там как то заебисто все, и колеса там на рейкастах.
>>70859
Всё есть: add_child(load("путь").instance())
Что мешало использовать встроенные ноды?
https://docs.godotengine.org/en/stable/classes/class_vehiclebody3d.html
https://docs.godotengine.org/en/stable/classes/class_vehiclewheel3d.html
Они никак с тройки не изменились (вроде бы).
Параметры по умолчанию не очень, но ехать можно.
>стриминга же в движке нет
Всё есть: add_child(load("путь").instance())
>за полчаса сделанный
>не было под рукой ассета
Что мешало использовать встроенные ноды?
https://docs.godotengine.org/en/stable/classes/class_vehiclebody3d.html
https://docs.godotengine.org/en/stable/classes/class_vehiclewheel3d.html
Они никак с тройки не изменились (вроде бы).
Параметры по умолчанию не очень, но ехать можно.
>>70862
Да помню я как там было, надо двигать пружины, и все равно колеса проваливались под хейтмап и застревали. Ну, после жесткого приземления с холма скажем. Плюс кодить поворот колес.
Да помню я как там было, надо двигать пружины, и все равно колеса проваливались под хейтмап и застревали. Ну, после жесткого приземления с холма скажем. Плюс кодить поворот колес.
>>70863
Не замечал такого. Может, ты слишком ослабил пружины, т.к. в объектах они вообще застрять не могут - там вроде рейкаст используется.
Это намного проще, чем делать с нуля более-менее реалистичную машину на основе катящейся сферы. Графоний чёт не похож на гиперказуалку.
>>70859
Я тебя серьёзно спрашивал. Смысл тестировать вот это вот всё, если у тебя совсем другая игра?
>колеса проваливались под хейтмап и застревали
Не замечал такого. Может, ты слишком ослабил пружины, т.к. в объектах они вообще застрять не могут - там вроде рейкаст используется.
>Плюс кодить поворот колес.
Это намного проще, чем делать с нуля более-менее реалистичную машину на основе катящейся сферы. Графоний чёт не похож на гиперказуалку.
>>70859
>Конечно, вот завтра поменяю домики на хрущевки и тачки на жигули и будет ГТА в Питере
Я тебя серьёзно спрашивал. Смысл тестировать вот это вот всё, если у тебя совсем другая игра?
737 Кб, 943x796>>70862
Полноценный стриминг это минимум 1000 строк. Как минимум надо многопоточность, текстуры же грузятся, но по хорошему пул, чтобы проверял, что такой материал уже есть в чанках. Также неизвестно пока как этот террейн себя поведет на стыках и вообще можно ли его перенести с 0,0,0. Надо смотреть что будет с навигейшн мешем, который я еще не делал, сможет ли он сам бесшовно склеиться, аналогично коллайдеры, посмотреть не будет ли подпрыгивать на стыках. Не забыть про грамотную выгрузку, чтобы что-то не провалилось под землю.
Лоды теперь есть автоматические, но глаз цепляется за какой то артефакт, либо это тени, либо изменение лода. На этом видео >>70388 на первых секундах заметно, если смотреть куда я отметил, перед камерой как бы бежит "волна" смены качества на одном расстоянии.
Полноценный стриминг это минимум 1000 строк. Как минимум надо многопоточность, текстуры же грузятся, но по хорошему пул, чтобы проверял, что такой материал уже есть в чанках. Также неизвестно пока как этот террейн себя поведет на стыках и вообще можно ли его перенести с 0,0,0. Надо смотреть что будет с навигейшн мешем, который я еще не делал, сможет ли он сам бесшовно склеиться, аналогично коллайдеры, посмотреть не будет ли подпрыгивать на стыках. Не забыть про грамотную выгрузку, чтобы что-то не провалилось под землю.
Лоды теперь есть автоматические, но глаз цепляется за какой то артефакт, либо это тени, либо изменение лода. На этом видео >>70388 на первых секундах заметно, если смотреть куда я отметил, перед камерой как бы бежит "волна" смены качества на одном расстоянии.
>>70864
Так физ объекту достаточно на большой скорости пройти сквозь, и обратно у него уже выйти не получается. Ну потом могу показать, если время будет.
Там строчек 30 копипастнуть, конкретная физика заносов для тестов не важна.
Количество домиков, разрешение текстур, количество персонажей, количество объектов эквивалентных машинкам с блестящими поверхностями, террейн, будет в таких же количествах. Естественно проект на дваче палить я не буду, а этот собран из ассетов, так что его можно будет и выложить без проблем со временем.
> т.к. в объектах они вообще застрять не могут - там вроде рейкаст используется.
Так физ объекту достаточно на большой скорости пройти сквозь, и обратно у него уже выйти не получается. Ну потом могу показать, если время будет.
>чем делать с нуля более-менее реалистичную машину на основе катящейся сферы.
Там строчек 30 копипастнуть, конкретная физика заносов для тестов не важна.
> Смысл тестировать вот это вот всё, если у тебя совсем другая игра?
Количество домиков, разрешение текстур, количество персонажей, количество объектов эквивалентных машинкам с блестящими поверхностями, террейн, будет в таких же количествах. Естественно проект на дваче палить я не буду, а этот собран из ассетов, так что его можно будет и выложить без проблем со временем.
>>70865
Ты вроде писал, что у тебя уже игра полностью готова на тройке и ты её на четвёрку планируешь перенести, когда баги рендеринга пофиксят?
Честно говоря, с таким уровнем графики вряд ли он вообще нужен, сейчас не начало 00-х всё-таки.
Так у тебя же нет террейна на видео...
С таким полигонажем лоды вряд ли ощутимы.
Может быть, это из-за текстур? Если смотреть на плоскость с текстурой под крутым углом, на ней будут заметные артефакты от сжатия текстуры.
>>70866
Возможно, ты неправильно настроил колёса. Точка крепления колёс находится выше нижней границы корпуса машины (коллижншейпа), поэтому ты чисто физически не можешь вогнать колесо под землю, не вогнав под землю весь автомобиль до уровня крепления колёс. Если у тебя автомобиль всем корпусом уходит под землю, то ошибка где угодно, но не в колёсах.
А потом окажется, что в твоих собственных ассетах ошибок нет, либо совсем другие ошибки. Кстати, во время альфы и беты людей просили портировать свои игры на четвёрку и репортить баги, чтобы успели найти и пофиксить до релиза, где ты был?
Ой, всё...
Ты вроде писал, что у тебя уже игра полностью готова на тройке и ты её на четвёрку планируешь перенести, когда баги рендеринга пофиксят?
>Полноценный стриминг
Честно говоря, с таким уровнем графики вряд ли он вообще нужен, сейчас не начало 00-х всё-таки.
>этот террейн
Так у тебя же нет террейна на видео...
>Лоды теперь есть автоматические
С таким полигонажем лоды вряд ли ощутимы.
>глаз цепляется за какой то артефакт
>бежит "волна" смены качества
Может быть, это из-за текстур? Если смотреть на плоскость с текстурой под крутым углом, на ней будут заметные артефакты от сжатия текстуры.
>>70866
>физ объекту достаточно на большой скорости пройти сквозь, и обратно у него уже выйти не получается
Возможно, ты неправильно настроил колёса. Точка крепления колёс находится выше нижней границы корпуса машины (коллижншейпа), поэтому ты чисто физически не можешь вогнать колесо под землю, не вогнав под землю весь автомобиль до уровня крепления колёс. Если у тебя автомобиль всем корпусом уходит под землю, то ошибка где угодно, но не в колёсах.
>собран из ассетов
А потом окажется, что в твоих собственных ассетах ошибок нет, либо совсем другие ошибки. Кстати, во время альфы и беты людей просили портировать свои игры на четвёрку и репортить баги, чтобы успели найти и пофиксить до релиза, где ты был?
>проект на дваче палить я не буду
Ой, всё...
>>70867
Это кто-то другой писал, может быть? У меня есть демка, где был геймплей, но сейчас все равно переделывается весь визуал и много чего еще.
Да, я его добавил позже, на скриншоте он есть. Холмик и горы вдали >>70508
Может быть, пока забью на этот момент.
Маловероятно. Тогда это уже какая-то лотерея была бы. Допускаю, что геометрия может заролять, но поэтому и домики достаточно разнообразные.
Я даже ПРы отправлял, чел...
Я уже давно для себя выводы сделал, что сюда идет, а что нет. Вот метание говна могу добавить, будет гта про метание говном.
>Ты вроде писал, что у тебя уже игра полностью готова на тройке
Это кто-то другой писал, может быть? У меня есть демка, где был геймплей, но сейчас все равно переделывается весь визуал и много чего еще.
>Так у тебя же нет террейна на видео...
Да, я его добавил позже, на скриншоте он есть. Холмик и горы вдали >>70508
> Если смотреть на плоскость с текстурой под крутым углом, на ней будут заметные артефакты от сжатия текстуры.
Может быть, пока забью на этот момент.
>А потом окажется, что в твоих собственных ассетах ошибок нет, либо совсем другие ошибки
Маловероятно. Тогда это уже какая-то лотерея была бы. Допускаю, что геометрия может заролять, но поэтому и домики достаточно разнообразные.
>Кстати, во время альфы и беты людей просили портировать свои игры на четвёрку и репортить баги, чтобы успели найти и пофиксить до релиза, где ты был?
Я даже ПРы отправлял, чел...
>Ой, всё...
Я уже давно для себя выводы сделал, что сюда идет, а что нет. Вот метание говна могу добавить, будет гта про метание говном.
>>70878
о, возрождение lada street racing
о, возрождение lada street racing
1 Кб, 130x52>>70944
Возьми движок, в котором есть стриминг и повтори в годоте. Что вообще такое стриминг? Не гуглится по очевидным причинам. Почему стриминг есть в каких-то упорно неназываемых тобой движках, но его нет в годоте?
Возьми движок, в котором есть стриминг и повтори в годоте. Что вообще такое стриминг? Не гуглится по очевидным причинам. Почему стриминг есть в каких-то упорно неназываемых тобой движках, но его нет в годоте?
>>70954
реклама на почту упала от Zenva
реклама на почту упала от Zenva
>>70965
Не понял твою "очевидную" причину.
https://duckduckgo.com/?q=gamedev+asset+data+streaming
>>70939
В другом движке наверняка есть что-то вроде load(), а всё остальное вообще идентично - массивы, циклы, условные выражения... Просто берёшь общий алгоритм и переносишь, в чём проблема?
Я лично лучше велосипед сам напишу. Мне по кайфу высирать тысячи строк кода и потом дебажить. В этом смысл разработки игр, иначе зачем это всё.
>>70869
Боишься, что агрессивные битарды набегут на твою игру и заспамят отрицательными отзывами?
>Не гуглится по очевидным причинам.
Не понял твою "очевидную" причину.
https://duckduckgo.com/?q=gamedev+asset+data+streaming
>>70939
>как я из него стриминг перенесу в годот
В другом движке наверняка есть что-то вроде load(), а всё остальное вообще идентично - массивы, циклы, условные выражения... Просто берёшь общий алгоритм и переносишь, в чём проблема?
Я лично лучше велосипед сам напишу. Мне по кайфу высирать тысячи строк кода и потом дебажить. В этом смысл разработки игр, иначе зачем это всё.
>>70869
>что сюда идет, а что нет
Боишься, что агрессивные битарды набегут на твою игру и заспамят отрицательными отзывами?
347 Кб, 1080x2400Есть хорошие, годные туториалы по созданию фонарей с динамическим освещением? Типа, двигается игрок - двигается свет. При этом предметы свет блокируют. Плюс мерцание и прочий фарш
>>70977
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html
Просто даёшь игроку в руку эту ноду:
https://docs.godotengine.org/en/stable/classes/class_spotlight3d.html
И получаешь свой фонарик. Могут быть артефакты с тенями, исправляется настройками.
А это ты уже сам делай, управляя настройками ноды SpotLight3D в своём скрипте фонарика.
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html
>двигается игрок - двигается свет
>При этом предметы свет блокируют
Просто даёшь игроку в руку эту ноду:
https://docs.godotengine.org/en/stable/classes/class_spotlight3d.html
И получаешь свой фонарик. Могут быть артефакты с тенями, исправляется настройками.
>мерцание
А это ты уже сам делай, управляя настройками ноды SpotLight3D в своём скрипте фонарика.
>>70977
Или тебе для 2D? Тогда это пробуй:
https://docs.godotengine.org/en/stable/tutorials/2d/2d_lights_and_shadows.html
Но встроенная система не всем 2D играм подходит. В частности, для игры типа Terraria нужно что-то совсем другое велосипедить (я не смог).
Или тебе для 2D? Тогда это пробуй:
https://docs.godotengine.org/en/stable/tutorials/2d/2d_lights_and_shadows.html
Но встроенная система не всем 2D играм подходит. В частности, для игры типа Terraria нужно что-то совсем другое велосипедить (я не смог).
>>70975
Да вот же она, на скрине страницы по твоей же ссылке. Но ладно, проблему я понял. Однако в результатах поиска по ссылке я обнаружил форумы "другого движка" где народ кодит на шарпе велосипеды с асинхронщиной.
>>70968
Скачай годот шарп и кодь велосипеды с асинхронщиной, если тебе так хочется заниматься преждевременной оптимизацией.
Насколько я знаю, ларж террейн датасетс в годоте прекрасно стримится при помощи мипмапов, которые годот самостоятельно генерирует при экспорте лардж хайтмап дата.
> Не понял твою "очевидную" причину.
Да вот же она, на скрине страницы по твоей же ссылке. Но ладно, проблему я понял. Однако в результатах поиска по ссылке я обнаружил форумы "другого движка" где народ кодит на шарпе велосипеды с асинхронщиной.
>>70968
Скачай годот шарп и кодь велосипеды с асинхронщиной, если тебе так хочется заниматься преждевременной оптимизацией.
Насколько я знаю, ларж террейн датасетс в годоте прекрасно стримится при помощи мипмапов, которые годот самостоятельно генерирует при экспорте лардж хайтмап дата.
>>70982
Спасибо, анон
Спасибо, анон
>>70999
Значение знаешь? Это набор сжатых версий одной и той же текстуры. Генерируются они для того, чтобы текстуры не слишком портились при сжатии и быстрее читались видеокартой. Если ты накладываешь текстуру на маленький квадрат далеко от камеры, то на него накладывается не твоя 4К оригинальная текстура, а мипмап версия размером, допустим, 16x16 пикселей. А если ты подходишь к этому квадрату ближе, то видеокарта постепенно выбирает мипмап разрешением больше и больше, вплоть до оригинального. Естественно, затраты памяти в данном случае увеличиваются, поэтому стриминг данных становится более необходимым.
Стриминг решает проблему нехватки оперативной и видеопамяти, по необходимости считывая новую порцию данных с диска и отправляя их в видеокарту, а также по необходимости удаляя из памяти лишние данные. Если у тебя игра весом 100 ГБ на компьютере с 2 ГБ видеопамяти и 8 ГБ оперативной, то тебе придётся постоянно обращаться к диску за новой порцией данных. Если же у тебя весь контент игры умещается в 750 МБ, то забей на стриминг, ты можешь хоть целую планету размером с Землю крутить и тебе не придётся обращаться к диску, т.к. все твои данные влезли в оперативную и видеопамять. Но тебе по-прежнему понадобится чанковая система, если у тебя много копий одного и того же объекта далеко от игрока, чтобы компьютер не делал лишнюю работу - это уже не стриминг, то есть не оптимизация памяти, а оптимизация по циклам процессора (объекты) и видеокарты (меши на экране).
Короче, для ЖТА анона сверху стриминг не нужен, но может потребоваться чанковая система. Я пробовал, чанковая система весьма проста.
Асинхронный код можно и на GDScript писать.
https://docs.godotengine.org/en/stable/classes/class_thread.html
C# может быть более производительным на больших массивах данных, но в остальном не нужен.
>мипмапов
Значение знаешь? Это набор сжатых версий одной и той же текстуры. Генерируются они для того, чтобы текстуры не слишком портились при сжатии и быстрее читались видеокартой. Если ты накладываешь текстуру на маленький квадрат далеко от камеры, то на него накладывается не твоя 4К оригинальная текстура, а мипмап версия размером, допустим, 16x16 пикселей. А если ты подходишь к этому квадрату ближе, то видеокарта постепенно выбирает мипмап разрешением больше и больше, вплоть до оригинального. Естественно, затраты памяти в данном случае увеличиваются, поэтому стриминг данных становится более необходимым.
Стриминг решает проблему нехватки оперативной и видеопамяти, по необходимости считывая новую порцию данных с диска и отправляя их в видеокарту, а также по необходимости удаляя из памяти лишние данные. Если у тебя игра весом 100 ГБ на компьютере с 2 ГБ видеопамяти и 8 ГБ оперативной, то тебе придётся постоянно обращаться к диску за новой порцией данных. Если же у тебя весь контент игры умещается в 750 МБ, то забей на стриминг, ты можешь хоть целую планету размером с Землю крутить и тебе не придётся обращаться к диску, т.к. все твои данные влезли в оперативную и видеопамять. Но тебе по-прежнему понадобится чанковая система, если у тебя много копий одного и того же объекта далеко от игрока, чтобы компьютер не делал лишнюю работу - это уже не стриминг, то есть не оптимизация памяти, а оптимизация по циклам процессора (объекты) и видеокарты (меши на экране).
Короче, для ЖТА анона сверху стриминг не нужен, но может потребоваться чанковая система. Я пробовал, чанковая система весьма проста.
>Скачай годот шарп и кодь велосипеды с асинхронщиной, если тебе так хочется заниматься преждевременной оптимизацией.
Асинхронный код можно и на GDScript писать.
https://docs.godotengine.org/en/stable/classes/class_thread.html
C# может быть более производительным на больших массивах данных, но в остальном не нужен.
>>71009
Да и я пробовал. Я в общем-то уже 4 поста как намекаю тому анону, чтобы он выкатывался в соседний движкосрач тред, откуда он и прикатился сюда, рассказывать нам, чего у нас тут нет в движке.
> Короче, для ЖТА анона сверху стриминг не нужен, но может потребоваться чанковая система. Я пробовал, чанковая система весьма проста.
Да и я пробовал. Я в общем-то уже 4 поста как намекаю тому анону, чтобы он выкатывался в соседний движкосрач тред, откуда он и прикатился сюда, рассказывать нам, чего у нас тут нет в движке.
>>71011
Хм? Разве? Он же вроде свой проект на Godot 3.x собирается перекатывать на 4.0? А то, что у нас чего-то нет, ни для кого не секрет. Просто тот же стриминг сильно зависит от типа игры и поэтому сделать универсальное решение невозможно. Какие-то движки имеют стриминг, подходящий определённому жанру, но шаг в сторону - и приходится пилить велосипед или костыли... В некоторых случаях да, конечно, лучше взять специальный движок под конкретный жанр, но Godot в своей основе универсален, поэтому сильно узкоспециализированных решений в нём стараются избегать.
>выкатывался в соседний движкосрач тред, откуда он и прикатился сюда, рассказывать нам
Хм? Разве? Он же вроде свой проект на Godot 3.x собирается перекатывать на 4.0? А то, что у нас чего-то нет, ни для кого не секрет. Просто тот же стриминг сильно зависит от типа игры и поэтому сделать универсальное решение невозможно. Какие-то движки имеют стриминг, подходящий определённому жанру, но шаг в сторону - и приходится пилить велосипед или костыли... В некоторых случаях да, конечно, лучше взять специальный движок под конкретный жанр, но Godot в своей основе универсален, поэтому сильно узкоспециализированных решений в нём стараются избегать.
>>71011
Может ты сразу огласишь сразу весь список, что мне можно и нельзя делать в треде и с годотом, чтобы твоя чувствительная натура не разнервничалась.
Может ты сразу огласишь сразу весь список, что мне можно и нельзя делать в треде и с годотом, чтобы твоя чувствительная натура не разнервничалась.
>>71013
Ты мне это объясняешь? Я это и так знаю. Ты вот этому обесни, у которого некий другой волшебный движок обладает неким стримингом искаропки. (На ютуб стримить штоле можно как делоешь игру?)
Ты мне это объясняешь? Я это и так знаю. Ты вот этому обесни, у которого некий другой волшебный движок обладает неким стримингом искаропки. (На ютуб стримить штоле можно как делоешь игру?)
>>71016
Стримить на ютуб разрешаю. Стримить на твич - нет.
Стримить на ютуб разрешаю. Стримить на твич - нет.
>>70859
Как это нет стриминга в движке? Это какая-то чудовищная ошибка! Срочно звоните товарищу Хуану!
> На самом деле стриминга же в движке нет
Как это нет стриминга в движке? Это какая-то чудовищная ошибка! Срочно звоните товарищу Хуану!
>>71031
Тебе понадобится quadTree, как выделять персонажей и как они будут искать путь
Тебе понадобится quadTree, как выделять персонажей и как они будут искать путь
Я влезу в спор по поводу подгрузки текстур.
По мне так это нахрен не нужно и выше анон верно отметил, что это преждевременная оптимизация, лучше или готовое искать или подход к игре менять.
Ну или нанимать местных анонов писать этот потоковый загрузчик текстур.
Проблема в том, что напишешь ты его, а игру нет и всё.
По мне так это нахрен не нужно и выше анон верно отметил, что это преждевременная оптимизация, лучше или готовое искать или подход к игре менять.
Ну или нанимать местных анонов писать этот потоковый загрузчик текстур.
Проблема в том, что напишешь ты его, а игру нет и всё.
>>71083
Какой товарищ Хуан всё-таки умный. Отсутствие стриминга в движке - это не баг, а спланированная фича! Верной дорогой идём, товарищи! Godot 5.0 за три года запилим и будем печь АААА как пирожки!
>от него и узнал
Какой товарищ Хуан всё-таки умный. Отсутствие стриминга в движке - это не баг, а спланированная фича! Верной дорогой идём, товарищи! Godot 5.0 за три года запилим и будем печь АААА как пирожки!
>>71070
Всё верно. Ведь даже если компьютер слабый, можно сделать полноценную игру с лоу-поли модельками и текстурами низкого разрешения, которые целиком в твою память залезают, а уже потом можно менять модельки и текстурки на более тяжёлые и пилить загрузчик, который будет как-то хитро жонглировать данными в памяти, впихивая невпихуемое.
>преждевременная оптимизация
>напишешь ты его, а игру нет и всё
Всё верно. Ведь даже если компьютер слабый, можно сделать полноценную игру с лоу-поли модельками и текстурами низкого разрешения, которые целиком в твою память залезают, а уже потом можно менять модельки и текстурки на более тяжёлые и пилить загрузчик, который будет как-то хитро жонглировать данными в памяти, впихивая невпихуемое.
>>71179
Разница тут проходит между градостроительным симулятором и гта. В первом тебе надо видеть все домики сразу, поэтому ты вынужден зарезать им качество, игрок будет терпеть. Во втором случае, когда ты едешь по разным районам, в них разные тематические домики. Без стриминга тут именно невозможно сделать всю игру, поскольку невозможно деражть все домики всех районов в памяти.
Разница тут проходит между градостроительным симулятором и гта. В первом тебе надо видеть все домики сразу, поэтому ты вынужден зарезать им качество, игрок будет терпеть. Во втором случае, когда ты едешь по разным районам, в них разные тематические домики. Без стриминга тут именно невозможно сделать всю игру, поскольку невозможно деражть все домики всех районов в памяти.
>>71175
Нахуя в движке стриминг, если стриминг очень сильно зависит от реализации конкретной игры? Зачем пихать в движок стриминг, если им всё равно большинство пользоваться не будет, потому что под свои задачи будут с нуля велосипедить? Вопросы, вопросы. Ответов нет.
> Отсутствие стриминга в движке
Нахуя в движке стриминг, если стриминг очень сильно зависит от реализации конкретной игры? Зачем пихать в движок стриминг, если им всё равно большинство пользоваться не будет, потому что под свои задачи будут с нуля велосипедить? Вопросы, вопросы. Ответов нет.
>>71310
Это просто значит, что должны быть гибкие настройки.
> если стриминг очень сильно зависит от реализации конкретной игры
Это просто значит, что должны быть гибкие настройки.
>>71316
Ну у буллета были гибкие настройки - целый сервер с полным доступом к физике. Управляй - не хочу. И что? Не захотели. Поэтому буллет был выпилен в чётверке, как никому не нужный. Так же было бы и с этим вашим стримингом. Такие алгоритмы пишутся под конкретную игру.
Да ты просто логически подумай. Твоя игра должна знать, какие объекты и в каком порядке подгружать с диска, что кэшировать, что уничтожать. Игра, а не движок. От движка требуется предоставить инструментарий: треды, файловые ассоциации, чтобы на их основе уже игроделы организовывали прикладную логику. Стриминг, в том виде, в котором он описан выше ( >>71009 ) - это чисто прикладная логика.
Ну у буллета были гибкие настройки - целый сервер с полным доступом к физике. Управляй - не хочу. И что? Не захотели. Поэтому буллет был выпилен в чётверке, как никому не нужный. Так же было бы и с этим вашим стримингом. Такие алгоритмы пишутся под конкретную игру.
Да ты просто логически подумай. Твоя игра должна знать, какие объекты и в каком порядке подгружать с диска, что кэшировать, что уничтожать. Игра, а не движок. От движка требуется предоставить инструментарий: треды, файловые ассоциации, чтобы на их основе уже игроделы организовывали прикладную логику. Стриминг, в том виде, в котором он описан выше ( >>71009 ) - это чисто прикладная логика.
>>71319
Это просто значит, что это указывается в свойствах объектов.
А в идеале, конечно, движок сам определяет точными вычислениями.
>какие объекты и в каком порядке подгружать с диска, что кэшировать, что уничтожать.
Это просто значит, что это указывается в свойствах объектов.
А в идеале, конечно, движок сам определяет точными вычислениями.
А кто-нибудь юзал ChatGPT, на других языках он очень хорошо объединяет и объясняет инфу, которые иногда задолбаешься искать. Я полный нуб и думаю его использовать как помощника, но у него база только до сентября 2021, для годот это устаревшее все будет?
>>71326
Не рекомендую новичку пользоваться ChatGPT ни для чего. Он часто начинает сочинять отсебятину, а новичок не сможет отличить от правды и проглотит.
Не рекомендую новичку пользоваться ChatGPT ни для чего. Он часто начинает сочинять отсебятину, а новичок не сможет отличить от правды и проглотит.
Хочу пилить игру по типу вальхейма, с процедурной генерацией воксельного мира (сглаженного), который также является разрушаемым. По уровню графики опять же вальхейм.
Изначально я изучал для этого ue5, но вдруг меня осенило, что я не собираюсь использовать ни люмен, ни нанит, и даже без них моя игра скорее всего будет очень требовательной (а вальхейм вот на калькуляторах работает!!1).
Так вот, в чем вопрос, аноны. Я правильно пришел сюда?
P.S. сам работаю в машобе, геймдев это хобби, и как показалось годот больше подходит для любителей, а уе для серьезных дядь с серьезными планами на проект
Изначально я изучал для этого ue5, но вдруг меня осенило, что я не собираюсь использовать ни люмен, ни нанит, и даже без них моя игра скорее всего будет очень требовательной (а вальхейм вот на калькуляторах работает!!1).
Так вот, в чем вопрос, аноны. Я правильно пришел сюда?
P.S. сам работаю в машобе, геймдев это хобби, и как показалось годот больше подходит для любителей, а уе для серьезных дядь с серьезными планами на проект
>>71406
Анон, есть готовый модуль https://github.com/Zylann/godot_voxel
Я читал что автор пилит его сейчас для 4 версии движка.
Для 3-й тоже когда то была демка, но кажется она не поддерживалась в актуальном состоянии.
Сейчас есть кастомные билды у автора в гитхабе
https://github.com/Zylann/godot_voxel/actions (надо быть залогиненым)
И есть демка https://github.com/Zylann/solar_system_demo
https://www.youtube.com/watch?v=8OrZX347MoE
Я ее сейчас запустил, могу сказать, что все работает, но видны стыки (которые я сначала принял за реки).
Сам пробуй, решай.
Анон, есть готовый модуль https://github.com/Zylann/godot_voxel
Я читал что автор пилит его сейчас для 4 версии движка.
Для 3-й тоже когда то была демка, но кажется она не поддерживалась в актуальном состоянии.
Сейчас есть кастомные билды у автора в гитхабе
https://github.com/Zylann/godot_voxel/actions (надо быть залогиненым)
И есть демка https://github.com/Zylann/solar_system_demo
https://www.youtube.com/watch?v=8OrZX347MoE
Я ее сейчас запустил, могу сказать, что все работает, но видны стыки (которые я сначала принял за реки).
Сам пробуй, решай.
>>71412
Смотрел демку ровно 22 минуты. А потом в голове заиграла эта музыка: https://www.youtube.com/watch?v=WVGlXbApOCs
Смотрел демку ровно 22 минуты. А потом в голове заиграла эта музыка: https://www.youtube.com/watch?v=WVGlXbApOCs
1,2 Мб, 1920x1080>>71412
Хотя, заметил что коллайдеры там работают плохо, и пролетает сквозь поверхность. Но я смог высадиться на какой то клочок и выкопать туннель. Так что, как и 4, пока сыровато, но сделано много.
Хотя, заметил что коллайдеры там работают плохо, и пролетает сквозь поверхность. Но я смог высадиться на какой то клочок и выкопать туннель. Так что, как и 4, пока сыровато, но сделано много.
>>71412
Спасибо, анон, что затестил демку. Я решил попробовать годот как раз потому, что нашел этот репозиторий искал подобное для уе5, нашел говно за 350 баксов.
Посмотрим, что из этого выйдет
Спасибо, анон, что затестил демку. Я решил попробовать годот как раз потому, что нашел этот репозиторий искал подобное для уе5, нашел говно за 350 баксов.
Посмотрим, что из этого выйдет
>>71412
Зилан ваще гений нашего времени! Какую мощную штуку накодил, и главное, отдал людям бесплатно. Воксельные миры до него я только либо за круглые суммы в продаже видел, либо как часть сторонней игры без возможности пилить свой отдельный продукт, только как мод к существующей игре. Либо как дохлые концепты с танчиками, существующие только на ютубе.
Зилан ваще гений нашего времени! Какую мощную штуку накодил, и главное, отдал людям бесплатно. Воксельные миры до него я только либо за круглые суммы в продаже видел, либо как часть сторонней игры без возможности пилить свой отдельный продукт, только как мод к существующей игре. Либо как дохлые концепты с танчиками, существующие только на ютубе.
>>71418
Ну блять, придирки конечно, как будто ты 350 баксов за это заплатил. Сыровато? Что сыровато? Это не игра, это демка технического инструмента. О какой сырости тут может идти речь?
Ты когда если будешь на зилановском модуле игру делать, сам должен лично прописать и настроить коллизии, точность, ограничения.
Я вот этого никогда не понимал и не пойму. К инструментам относятся как к готовому продукту. Требуют от них готовой реализации ВСЕХ механик. А, извините, ты что будешь делать, когда Хуан с Зиланом тебе поставят под видом движка готовую игру? В чём будет твой вклад разработчика?
Ну блять, придирки конечно, как будто ты 350 баксов за это заплатил. Сыровато? Что сыровато? Это не игра, это демка технического инструмента. О какой сырости тут может идти речь?
Ты когда если будешь на зилановском модуле игру делать, сам должен лично прописать и настроить коллизии, точность, ограничения.
Я вот этого никогда не понимал и не пойму. К инструментам относятся как к готовому продукту. Требуют от них готовой реализации ВСЕХ механик. А, извините, ты что будешь делать, когда Хуан с Зиланом тебе поставят под видом движка готовую игру? В чём будет твой вклад разработчика?
>>71421
Нет, лол, я про коллайдер террейна. Подразумевается, что коллайдер террейна повторяет визуал 1 в 1. Собственно на видео он садится где угодно, но видео старое. Очевидный серьезный баг, ну так их никто и не торопит, 4 ка только релизнулась.
К механикам игры это отношения не имеет.
Прописывать урон врагам, например. Не юродичай.
Нет, лол, я про коллайдер террейна. Подразумевается, что коллайдер террейна повторяет визуал 1 в 1. Собственно на видео он садится где угодно, но видео старое. Очевидный серьезный баг, ну так их никто и не торопит, 4 ка только релизнулась.
К механикам игры это отношения не имеет.
>звините, ты что будешь делать, когда Хуан с Зиланом
Прописывать урон врагам, например. Не юродичай.
Помочь с простым кликером они не могут... А создать новый вархаммер с нуля сразу знатоки с помощью прибежали и начали советы раздавать! Что с этим миром не так?
>>71440
Всмысле?
Где не смогли?
Ссылку на пост плиз. Как мы могли так проебаться? Щас поможем.
>Помочь с простым кликером они не могут
Всмысле?
Где не смогли?
Ссылку на пост плиз. Как мы могли так проебаться? Щас поможем.
>>71460
Ему 2 треда помогали, но он морозился.
Ну думаю сейчас чатгпт может помочь с простыми 2д кликерами, а мы сосредоточимся на сложных 3д опенворлдах.
Ему 2 треда помогали, но он морозился.
Ну думаю сейчас чатгпт может помочь с простыми 2д кликерами, а мы сосредоточимся на сложных 3д опенворлдах.
Запилил уже первое 2д по документации. Мне нравится простота этого движка, больше фокусируешься именно на логике игры. Не думал конечно, что он такой маловесный, немного смутило, что движок состоит только из вьюпорта, ide и дерева с инспектором. Конечно, я еще многого не видел в этом движке, но на первый взгляд, функционала намного меньше из коробки, чем в уе. Хотя, справедливости ради, в уе была тысяча и одна функция, которые я вообще не юзал. Но наличие отдельных средств для работы с мешами/анимациями/материлами/итд мне очень нравилось.
Насколько я понял, движок идет с минимальным функционалом, а остальное можно прикручивать как модули, лишь бы было реализовано кем-то. Если не так, то поправьте.
А я пошел чекать 3д
Насколько я понял, движок идет с минимальным функционалом, а остальное можно прикручивать как модули, лишь бы было реализовано кем-то. Если не так, то поправьте.
А я пошел чекать 3д
>>71501
Если у тебя будет материал, то соотвтетственно откроются проперти матиериала, а если анимация - то редактор анимации. А если дерево анимации или визуальный шейдер - то редактор нод.
Если у тебя будет материал, то соотвтетственно откроются проперти матиериала, а если анимация - то редактор анимации. А если дерево анимации или визуальный шейдер - то редактор нод.
>>71501
Редактора мешей там нет, но есть CSG для прототипирования (который в принципе можно экспортнуть в меш), а так же какие то базовые операции с импортированными моделями - скажем, если она состоит из нескольких мешей, то их можно по отдельности сохранить, делать невидимыми и т.д.
Редактора мешей там нет, но есть CSG для прототипирования (который в принципе можно экспортнуть в меш), а так же какие то базовые операции с импортированными моделями - скажем, если она состоит из нескольких мешей, то их можно по отдельности сохранить, делать невидимыми и т.д.
>>71508
Неловкий момент.
Неловкий момент.
Аноны, вы код для управления игроком накидываете прям в ноду игрока, или создаете отдельную ноду-контроллер и к ней игрока крепите?
>>71578
Скорее похоже на ECS, когда к игроку крепятся ноды описывающие поведение в конкретных ситуациях (прыжок, плаванье и тд)
Скорее похоже на ECS, когда к игроку крепятся ноды описывающие поведение в конкретных ситуациях (прыжок, плаванье и тд)
>>71580
то есть ты грубо говоря пилишь компонент InputDriven и туда выносишь логику инпута?
то есть ты грубо говоря пилишь компонент InputDriven и туда выносишь логику инпута?
>>71582
Возможно. Ну можно написать типа - в самом player перебираешь чайлдов, получаешь от них векторы и применяешь.
Возможно. Ну можно написать типа - в самом player перебираешь чайлдов, получаешь от них векторы и применяешь.
>>71583
Идею понял, спасибо
Идею понял, спасибо
>>71582
Это не может противоречить идеям годота, это напрямую развивает идеи годота.
Потому что идея годота как раз в том, что поведение сцены (родителя) - это и есть сумма поведений всех её детей.
Главнейший пример здесь: ноды-наследники PhysicsBody, которым обязательно нужны дети CollisionShape, изменяющие поведение родителя, а именно, придающие родителю физическую форму.
>ребенок будет изменять состояние родительского узла, это не будет противоречить идеям годота?
Это не может противоречить идеям годота, это напрямую развивает идеи годота.
Потому что идея годота как раз в том, что поведение сцены (родителя) - это и есть сумма поведений всех её детей.
Главнейший пример здесь: ноды-наследники PhysicsBody, которым обязательно нужны дети CollisionShape, изменяющие поведение родителя, а именно, придающие родителю физическую форму.
>>71578
Сначала я лепил код прямо в ноду игрока.
Теперь же я доразвился и креплю в отдельные ноды. Причём эти ноды не просто контроллеры, а стейты стейтмашины. Как верно заметил анон в прошлом треде, дизайнить игру следует начинать с создания стейтмашин, которые и будут обрабатывать игровой процесс. Любой туториал, который не даёт инфу по стейтмашинам следует отбрасывать как фейловый, он вас ничему полезному не научит.
>Аноны, вы код для управления игроком накидываете прям в ноду игрока, или создаете отдельную ноду-контроллер и к ней игрока крепите?
Сначала я лепил код прямо в ноду игрока.
Теперь же я доразвился и креплю в отдельные ноды. Причём эти ноды не просто контроллеры, а стейты стейтмашины. Как верно заметил анон в прошлом треде, дизайнить игру следует начинать с создания стейтмашин, которые и будут обрабатывать игровой процесс. Любой туториал, который не даёт инфу по стейтмашинам следует отбрасывать как фейловый, он вас ничему полезному не научит.
>>71617
Вы ещё не видите проблему? А она нарастает, как снежный ком. Даю подсказку. Строка 17.
Вы ещё не видите проблему? А она нарастает, как снежный ком. Даю подсказку. Строка 17.
>>71618
Переделываем нашу стейтмашину. И тут мы вспоминаем, что на предыдущем шаге добавили стейт fly в стейты. И хватаемся за голову! Как же так?? Швятая волшебная штейтмашина не упрощает девелоп, а усложняет?
Внимание, уважаемые знатоки. Где же мы проебались в построении стейтмашины?
Переделываем нашу стейтмашину. И тут мы вспоминаем, что на предыдущем шаге добавили стейт fly в стейты. И хватаемся за голову! Как же так?? Швятая волшебная штейтмашина не упрощает девелоп, а усложняет?
Внимание, уважаемые знатоки. Где же мы проебались в построении стейтмашины?
>>71626
Не то чтобы сложно, а дело в том, что в таком виде добавление новых состояний приводит к постоянному переписыванию кода.
Не то чтобы сложно, а дело в том, что в таком виде добавление новых состояний приводит к постоянному переписыванию кода.
>>71627
А какой паттерн более целесообразный?
А какой паттерн более целесообразный?
>>71613
Если у тебя платформер на 10 сущностей это ок. Чих на каждую ноду лишнюю нагрузку создаёт, в итоге у тебя 20000 нод снихуя в каком-нибудь рогалике и начинается пиздец.
Ноды это конечно удобно, но чтобы годо-вей в полной мере работал там нужен массивное переосмысление производительности.
Если у тебя платформер на 10 сущностей это ок. Чих на каждую ноду лишнюю нагрузку создаёт, в итоге у тебя 20000 нод снихуя в каком-нибудь рогалике и начинается пиздец.
Ноды это конечно удобно, но чтобы годо-вей в полной мере работал там нужен массивное переосмысление производительности.
>>71621
Все разносится по отдельным файлам.
Заводится базовый BaseState
Все _handle_... заменяются одним current_state.handle()
StateMachine переделываешь так, что она занимается только обслуживанием собственно машины, а не логикой.
Выполняет всякие request_state_transition
Смотри как делают другие
https://github.com/GDQuest/godot-3d-mannequin/tree/master/godot/src/Player/States
https://github.com/selgesel/godot4-third-person-controller/tree/master/player
Все разносится по отдельным файлам.
Заводится базовый BaseState
Все _handle_... заменяются одним current_state.handle()
StateMachine переделываешь так, что она занимается только обслуживанием собственно машины, а не логикой.
Выполняет всякие request_state_transition
Смотри как делают другие
https://github.com/GDQuest/godot-3d-mannequin/tree/master/godot/src/Player/States
https://github.com/selgesel/godot4-third-person-controller/tree/master/player
>>71635
Приз в студию! У нас победитель!
Приз в студию! У нас победитель!
>>71634
Хуан в своей статье писал, что нагрузка там минимальна.
> Чих на каждую ноду лишнюю нагрузку создаёт
Хуан в своей статье писал, что нагрузка там минимальна.
Насколько хорошо годот подойдет для создания лоуполи 3д клона вальхейма? Почему все готовые проекты в 2д? СОМНЕНИЯ ВСЕ ЕЩЕ ТЕРЗАЮТ МЕНЯ
>>71662
Потому что годот-комьюнити в основном из пиксельартеров состоит.
> Почему все готовые проекты в 2д?
Потому что годот-комьюнити в основном из пиксельартеров состоит.
462 Кб, mp4,1280x720, 0:10
Версия 3.5.2
Работаю с Light2d, lightoccluder2d и occluderpolygon 2d для tilemap
Сейчас есть такая проблема:
Для tilemap использую clockwise при этом наблюдаю эффект "шестеренки". Правильно понимаю, что это решается только ручным выставлением occulder полигона на сцене?
Есть ли решение "поставить галочку" и убрать такой эффект?
Алсо, есть годные туториалы по системе инвентаря? А то большая часть - это хтонический пиздец
Работаю с Light2d, lightoccluder2d и occluderpolygon 2d для tilemap
Сейчас есть такая проблема:
Для tilemap использую clockwise при этом наблюдаю эффект "шестеренки". Правильно понимаю, что это решается только ручным выставлением occulder полигона на сцене?
Есть ли решение "поставить галочку" и убрать такой эффект?
Алсо, есть годные туториалы по системе инвентаря? А то большая часть - это хтонический пиздец
>>71670
Извини, не знаю.
Вот этот смотрел? Вроде неплох.
https://www.youtube.com/watch?v=dMYv6InQgno
> Есть ли решение "поставить галочку" и убрать такой эффект?
Извини, не знаю.
> годные туториалы по системе инвентаря?
Вот этот смотрел? Вроде неплох.
https://www.youtube.com/watch?v=dMYv6InQgno
>>71698
пососав хуй сказало быдло
пососав хуй сказало быдло
Хотя даже при ручном назначении окклюзии тени уходят в пол, что не очень красиво
21 Кб, 955x643
24 Кб, 771x541>>71723
Не совсем, см пик 1 - нужно чтобы часть "земли" aka тайлмапы освещалось, чтобы игрок видел, по какой поверхности идет. Но, если впереди преграда, тень от которой загораживает то, что впереди, то часть тени перекрывает и тайлмапу. Вот от этого мне нужно избавиться.
(конкретно на этом пике у куска земли перед игроком отдельная окклюзия)
Как костыльный вариант - квадратный источник света ровно под предметом, но думается мне, что идея не самая верная.
>>71718
Спасибо, попробую
Не совсем, см пик 1 - нужно чтобы часть "земли" aka тайлмапы освещалось, чтобы игрок видел, по какой поверхности идет. Но, если впереди преграда, тень от которой загораживает то, что впереди, то часть тени перекрывает и тайлмапу. Вот от этого мне нужно избавиться.
(конкретно на этом пике у куска земли перед игроком отдельная окклюзия)
Как костыльный вариант - квадратный источник света ровно под предметом, но думается мне, что идея не самая верная.
>>71718
Спасибо, попробую
Есть тут гуру, что поведает мне почему в годо координаты прямоугольника с цветом округляются при отображении, хотя по факту дробные?
Суть, квадрат двигается вместе с курсором, но на большом масштабе он двигается скачками, то самое округление, при выводе например в консоль координаты отображаются как дробные, но прямоугольник фактически стоит на месте, пока координата мыши не превысит некоторый порог, а потом скачком меняет позицию.
На большом масштабе такое естественно не заметно.
В настройках смотрел, но ничо не нашёл, разве что обратил внимание на bvh
Суть, квадрат двигается вместе с курсором, но на большом масштабе он двигается скачками, то самое округление, при выводе например в консоль координаты отображаются как дробные, но прямоугольник фактически стоит на месте, пока координата мыши не превысит некоторый порог, а потом скачком меняет позицию.
На большом масштабе такое естественно не заметно.
В настройках смотрел, но ничо не нашёл, разве что обратил внимание на bvh
>>71764
Мне кажется ты хочешь невозможного. Либо тайлы оклюдят, либо нет. Тогда для земли юзай один набор тайлов, для преград - другой. Либо мы друг друга не понимаем.
Мне кажется ты хочешь невозможного. Либо тайлы оклюдят, либо нет. Тогда для земли юзай один набор тайлов, для преград - другой. Либо мы друг друга не понимаем.
>>71770
Control-нода?
Не стоит её масштабировать в камере. Интерфейсы масштабируются своими внутренними алгоритмами, а их координаты (как я понимаю, поправьте, если ошибаюсь) округляются до целых.
> координаты прямоугольника с цветом округляются при отображении
Control-нода?
Не стоит её масштабировать в камере. Интерфейсы масштабируются своими внутренними алгоритмами, а их координаты (как я понимаю, поправьте, если ошибаюсь) округляются до целых.
>>71779
Понятно, надо уточнить
На первой картинке то как вычисляются координаты ColorRectangle относительно координат мыши
Координаты мыши берутся из второго ViewPort
На второй картинке иерархия объектов, main корневой, круг рисуется в ViewPort с учётом масштаба и координат камеры
Понятно, надо уточнить
На первой картинке то как вычисляются координаты ColorRectangle относительно координат мыши
Координаты мыши берутся из второго ViewPort
На второй картинке иерархия объектов, main корневой, круг рисуется в ViewPort с учётом масштаба и координат камеры
>>71784
Объект, бросающий тень рисуется первым вместе с тенью, поверх тайлмап
Объект, бросающий тень рисуется первым вместе с тенью, поверх тайлмап
>>71786
Кажется я понял в чём проблема, сам движок округляет до ближайшего пикселя, хотя по факту координаты дробные
Один из вариантов решения в десять раз большее разрешение, но это такое себе
Кажется я понял в чём проблема, сам движок округляет до ближайшего пикселя, хотя по факту координаты дробные
Один из вариантов решения в десять раз большее разрешение, но это такое себе
>>71792
Другой вариант решения, не использовать контрол-ноды с масштабированием, а использовать ноды2д. Например, накидай в пейнте белый квадрат, загрузи в спрайт и настрой селфмодуляцию цвета.
Другой вариант решения, не использовать контрол-ноды с масштабированием, а использовать ноды2д. Например, накидай в пейнте белый квадрат, загрузи в спрайт и настрой селфмодуляцию цвета.
>>71799
Это особенность всех интерфейсных контрол-нод. О чём я сразу и написал:
>>71779
> это особенность конкретно ColorRectangle
Это особенность всех интерфейсных контрол-нод. О чём я сразу и написал:
>>71779
> Control-нода?
> Не стоит её масштабировать в камере. Интерфейсы масштабируются своими внутренними алгоритмами, а их координаты (как я понимаю, поправьте, если ошибаюсь) округляются до целых.
>>71697
Вот ещё один https://youtu.be/hYRN0eYttLc
Этот несколько душнее, но зато тут рассмотрена реализация инвентаря на ресурсах, что может быть полезнее в некоторых случаях.
> Спасибо, вроде годный. Поизучаю
Вот ещё один https://youtu.be/hYRN0eYttLc
Этот несколько душнее, но зато тут рассмотрена реализация инвентаря на ресурсах, что может быть полезнее в некоторых случаях.
>>71478
Зря я обратно зашёл, пойду дальше своей дорогой.
>Ему 2 треда помогали
>Сходу обвинили в пълътике.
>После говорили что я тролль
Зря я обратно зашёл, пойду дальше своей дорогой.
>>71828
Насколько мне известно, лицензия MIT не запрещает делать политические, военизированные игры. Ну а мнение других тебе надо научиться фильтровать.
Насколько мне известно, лицензия MIT не запрещает делать политические, военизированные игры. Ну а мнение других тебе надо научиться фильтровать.
>>67751 (OP)
Ля кокая годнота!
https://godotengine.org/asset-library/asset/1432
Вместо неповоротливых блоков диалоджика пишешь диалоги как прямую речь в книгах. Нойс!
Ля кокая годнота!
https://godotengine.org/asset-library/asset/1432
Вместо неповоротливых блоков диалоджика пишешь диалоги как прямую речь в книгах. Нойс!
>>71828
Тебя затроллили тролльблэймингом (тролльным обвинением в троллинге). Растролливайся давай. Удачи!
Тебя затроллили тролльблэймингом (тролльным обвинением в троллинге). Растролливайся давай. Удачи!
>>71635
во втором примере состояние меняются не только внутри машины, но и внутри плеера тк к нему привязаны датчики воды. Это норм? Немного запутанно получается.
во втором примере состояние меняются не только внутри машины, но и внутри плеера тк к нему привязаны датчики воды. Это норм? Немного запутанно получается.
>>71943
Затрудняюсь сказать. Скорее всего нет, должно быть внутри стейтов.
Вообще идеально было бы иметь еще и схему стейтов нарисованную нодами чтобы наглядно видеть условия.
Затрудняюсь сказать. Скорее всего нет, должно быть внутри стейтов.
Вообще идеально было бы иметь еще и схему стейтов нарисованную нодами чтобы наглядно видеть условия.
>>71578
У меня персонаж это стейт-машина. А инпут-контроллер манагерит все виды управления (клавамыш, джой, тач) и отсылает унифицированные команды как игроку, так и различным элементам интерфейса, если им нужно единое управление с разных устройств ввода.
Да, я знаю, что это велосипед в обход встроенного в Годо мотоцикла. Но он плохо понимает тач, да и контроль у меня получается попроще.
У меня персонаж это стейт-машина. А инпут-контроллер манагерит все виды управления (клавамыш, джой, тач) и отсылает унифицированные команды как игроку, так и различным элементам интерфейса, если им нужно единое управление с разных устройств ввода.
Да, я знаю, что это велосипед в обход встроенного в Годо мотоцикла. Но он плохо понимает тач, да и контроль у меня получается попроще.
Как добавить AntiAliasing к геометрии оно же Mesh, которые создаются программно - положение вершин, индексы треугольников.
Что уже пробовал.
Игрался с MSAA в настройках, видел указания отключить HDR, тоже пробовал в настройках камеры, но без результатов
Что уже пробовал.
Игрался с MSAA в настройках, видел указания отключить HDR, тоже пробовал в настройках камеры, но без результатов
>>72070
AA влияет на постабработку пиксельной картинки, ей все равно как ты получил меш, загрузил или сгенерировал, не?
AA влияет на постабработку пиксельной картинки, ей все равно как ты получил меш, загрузил или сгенерировал, не?
>>72072
Да, но как включить то?
Хотя, у Line2D есть флажок с лесенкоубиралкой, так что неизвестно на каком этапе оно сглаживается
Да, но как включить то?
Хотя, у Line2D есть флажок с лесенкоубиралкой, так что неизвестно на каком этапе оно сглаживается
156 Кб, webm,640x270, 0:02
Сегодня попробовал MultiMeshInstance для 2D, общие впечатления на видео
>>72087
Так батчинг одинаковых спрайтов и так есть давно. В чем выгода?
Так батчинг одинаковых спрайтов и так есть давно. В чем выгода?
>>72073
Ой, да просто купи 4к монитор.
Ой, да просто купи 4к монитор.
>>71319
На 3.X для 3D я пользуюсь только Bullet, потому что Godot Physics со всеми багфиксами и оптимизациями всё ещё глючное тормознутое говно в сравнении с Bullet. Я вообще не понимаю, зачем они запилили свой велосипед, когда можно было сделать форк Bullet, пофиксить баги конкретно Bullet и уже им пользоваться, а не изобретать свой глючный и тормозной велосипед. Ладно, в 4.0 физика вроде должна быть лучше - стабильнее, быстрее. Но всё равно ощущается, как будто вложили кучу человекочасов в то, что никому изначально не было нужно, ведь все использовали Bullet (по умолчанию!) и даже не задумывались об этом велосипеде... Я несколько раз давал шанс Godot Physics и был вынужден переключиться обратно на Bullet, а теперь они взяли и выпилили его. Выглядит как выстрел себе в ногу...
>>71322
Предлагай свойства, которые ты планируешь использовать для стриминга данных.
И будет ещё больше пропуков из-за того, что движок пытается по каким-то универсальным формулам предсказать поведение твоей уникальной игры, не укладывающейся ни в какой известный жанр.
В Unreal есть стриминг, потому что Unreal заточен под фотореалистичные 3D шутеры на статичном ландшафте, для всего остального он подходит так же, как микроскоп для забивания гвоздей. А Godot позиционирует себя как швейцарский нож - инструмент для любого жанра игр и любых других прикладных приложений. Редактор Godot может напоминать конструктор игр из-за нодовой системы, встроенного скриптового языка и низкого порога освоения, но в своей основе это низкоуровневый универсальный инструмент, не заточенный под лёгкое создание какого-либо конкретного жанра игр. Поэтому ожидать от него интеллектуальной подстройки под каждую игру глупо.
Что касается стриминга... Представим на секунду, что разработчики движка сделали автоматическую систему для 2D и 3D игр и тщательно отладили её на популярных жанрах. Приходит разработчик игры и пытается сделать 4D или 5D игру и начинает жаловаться, что встроенная автоматическая система неправильно предсказывает необходимые ресурсы и мешает ему, а не помогает. Отправлять его компилировать движок без этой системы? Но зачем, если можно просто не делать эту систему?
>буллет был выпилен в чётверке, как никому не нужный
На 3.X для 3D я пользуюсь только Bullet, потому что Godot Physics со всеми багфиксами и оптимизациями всё ещё глючное тормознутое говно в сравнении с Bullet. Я вообще не понимаю, зачем они запилили свой велосипед, когда можно было сделать форк Bullet, пофиксить баги конкретно Bullet и уже им пользоваться, а не изобретать свой глючный и тормозной велосипед. Ладно, в 4.0 физика вроде должна быть лучше - стабильнее, быстрее. Но всё равно ощущается, как будто вложили кучу человекочасов в то, что никому изначально не было нужно, ведь все использовали Bullet (по умолчанию!) и даже не задумывались об этом велосипеде... Я несколько раз давал шанс Godot Physics и был вынужден переключиться обратно на Bullet, а теперь они взяли и выпилили его. Выглядит как выстрел себе в ногу...
>>71322
>указывается в свойствах объектов
Предлагай свойства, которые ты планируешь использовать для стриминга данных.
>движок сам определяет точными вычислениями
И будет ещё больше пропуков из-за того, что движок пытается по каким-то универсальным формулам предсказать поведение твоей уникальной игры, не укладывающейся ни в какой известный жанр.
В Unreal есть стриминг, потому что Unreal заточен под фотореалистичные 3D шутеры на статичном ландшафте, для всего остального он подходит так же, как микроскоп для забивания гвоздей. А Godot позиционирует себя как швейцарский нож - инструмент для любого жанра игр и любых других прикладных приложений. Редактор Godot может напоминать конструктор игр из-за нодовой системы, встроенного скриптового языка и низкого порога освоения, но в своей основе это низкоуровневый универсальный инструмент, не заточенный под лёгкое создание какого-либо конкретного жанра игр. Поэтому ожидать от него интеллектуальной подстройки под каждую игру глупо.
Что касается стриминга... Представим на секунду, что разработчики движка сделали автоматическую систему для 2D и 3D игр и тщательно отладили её на популярных жанрах. Приходит разработчик игры и пытается сделать 4D или 5D игру и начинает жаловаться, что встроенная автоматическая система неправильно предсказывает необходимые ресурсы и мешает ему, а не помогает. Отправлять его компилировать движок без этой системы? Но зачем, если можно просто не делать эту систему?
>>71319
На 3.X для 3D я пользуюсь только Bullet, потому что Godot Physics со всеми багфиксами и оптимизациями всё ещё глючное тормознутое говно в сравнении с Bullet. Я вообще не понимаю, зачем они запилили свой велосипед, когда можно было сделать форк Bullet, пофиксить баги конкретно Bullet и уже им пользоваться, а не изобретать свой глючный и тормозной велосипед. Ладно, в 4.0 физика вроде должна быть лучше - стабильнее, быстрее. Но всё равно ощущается, как будто вложили кучу человекочасов в то, что никому изначально не было нужно, ведь все использовали Bullet (по умолчанию!) и даже не задумывались об этом велосипеде... Я несколько раз давал шанс Godot Physics и был вынужден переключиться обратно на Bullet, а теперь они взяли и выпилили его. Выглядит как выстрел себе в ногу...
>>71322
Предлагай свойства, которые ты планируешь использовать для стриминга данных.
И будет ещё больше пропуков из-за того, что движок пытается по каким-то универсальным формулам предсказать поведение твоей уникальной игры, не укладывающейся ни в какой известный жанр.
В Unreal есть стриминг, потому что Unreal заточен под фотореалистичные 3D шутеры на статичном ландшафте, для всего остального он подходит так же, как микроскоп для забивания гвоздей. А Godot позиционирует себя как швейцарский нож - инструмент для любого жанра игр и любых других прикладных приложений. Редактор Godot может напоминать конструктор игр из-за нодовой системы, встроенного скриптового языка и низкого порога освоения, но в своей основе это низкоуровневый универсальный инструмент, не заточенный под лёгкое создание какого-либо конкретного жанра игр. Поэтому ожидать от него интеллектуальной подстройки под каждую игру глупо.
Что касается стриминга... Представим на секунду, что разработчики движка сделали автоматическую систему для 2D и 3D игр и тщательно отладили её на популярных жанрах. Приходит разработчик игры и пытается сделать 4D или 5D игру и начинает жаловаться, что встроенная автоматическая система неправильно предсказывает необходимые ресурсы и мешает ему, а не помогает. Отправлять его компилировать движок без этой системы? Но зачем, если можно просто не делать эту систему?
>буллет был выпилен в чётверке, как никому не нужный
На 3.X для 3D я пользуюсь только Bullet, потому что Godot Physics со всеми багфиксами и оптимизациями всё ещё глючное тормознутое говно в сравнении с Bullet. Я вообще не понимаю, зачем они запилили свой велосипед, когда можно было сделать форк Bullet, пофиксить баги конкретно Bullet и уже им пользоваться, а не изобретать свой глючный и тормозной велосипед. Ладно, в 4.0 физика вроде должна быть лучше - стабильнее, быстрее. Но всё равно ощущается, как будто вложили кучу человекочасов в то, что никому изначально не было нужно, ведь все использовали Bullet (по умолчанию!) и даже не задумывались об этом велосипеде... Я несколько раз давал шанс Godot Physics и был вынужден переключиться обратно на Bullet, а теперь они взяли и выпилили его. Выглядит как выстрел себе в ногу...
>>71322
>указывается в свойствах объектов
Предлагай свойства, которые ты планируешь использовать для стриминга данных.
>движок сам определяет точными вычислениями
И будет ещё больше пропуков из-за того, что движок пытается по каким-то универсальным формулам предсказать поведение твоей уникальной игры, не укладывающейся ни в какой известный жанр.
В Unreal есть стриминг, потому что Unreal заточен под фотореалистичные 3D шутеры на статичном ландшафте, для всего остального он подходит так же, как микроскоп для забивания гвоздей. А Godot позиционирует себя как швейцарский нож - инструмент для любого жанра игр и любых других прикладных приложений. Редактор Godot может напоминать конструктор игр из-за нодовой системы, встроенного скриптового языка и низкого порога освоения, но в своей основе это низкоуровневый универсальный инструмент, не заточенный под лёгкое создание какого-либо конкретного жанра игр. Поэтому ожидать от него интеллектуальной подстройки под каждую игру глупо.
Что касается стриминга... Представим на секунду, что разработчики движка сделали автоматическую систему для 2D и 3D игр и тщательно отладили её на популярных жанрах. Приходит разработчик игры и пытается сделать 4D или 5D игру и начинает жаловаться, что встроенная автоматическая система неправильно предсказывает необходимые ресурсы и мешает ему, а не помогает. Отправлять его компилировать движок без этой системы? Но зачем, если можно просто не делать эту систему?
>>72146
Будем посмотреть.
Для тех проектов, что я задумал, физика особо и не нужна (только базовые вещи типа триггеров через коллизию), поэтому мне в целом похуй.
> Выглядит как выстрел себе в ногу
Будем посмотреть.
Для тех проектов, что я задумал, физика особо и не нужна (только базовые вещи типа триггеров через коллизию), поэтому мне в целом похуй.
>>72146
Двачую. И еще добавлю от себя, что в движок заложена модульность. Кому чего не хватает - АПИ есть, СИ есть, конпелируйте модуль.
> Поэтому ожидать от него интеллектуальной подстройки под каждую игру глупо.
Двачую. И еще добавлю от себя, что в движок заложена модульность. Кому чего не хватает - АПИ есть, СИ есть, конпелируйте модуль.
>>71420
Minetest: (существует)
Анон с двачей, которого воксельные миры в играх вообще никак не интересуют:
Тем временем Minetest:
https://www.minetest.net/
Minetest: (существует)
Анон с двачей, которого воксельные миры в играх вообще никак не интересуют:
>Воксельные миры до него я только либо за круглые суммы в продаже видел, либо как часть сторонней игры без возможности пилить свой отдельный продукт, только как мод к существующей игре.
Тем временем Minetest:
>Initial release0.0.1 / November 2, 2010; 12 years ago
>Stable release 5.6.1 Edit this on Wikidata / 19 September 2022
https://www.minetest.net/
. Play one of our many games, mod a game to your liking, make your own game, or play on a multiplayer server.>An open source voxel game engine
>Available for Windows, macOS, GNU/Linux, FreeBSD, OpenBSD, DragonFly BSD, and Android.
>>71421
Ты когда в строительном магазине молоток покупаешь, ожидаешь от него точного и стабильного выполнения работы. Если ты купил молоток, а у него рукоять гнётся и головка лёгкая, а в инструкции ты читаешь "известные баги версии, будут исправлены в будущем: рукоять гнётся; головка лёгкая", то ты, скорее всего, быстро вернёшься в магазин и потребуешь вернуть деньги за товар, не соответствующий своему описанию. Если же ты этот молоток не купил, а нашёл на улице или взял бесплатно у друга, ты его просто выкинешь или вернёшь другу, а не будешь плеваться и пытаться использовать по назначению, к которому он совершенно не приспособлен в текущем состоянии. Ты можешь, конечно, прикрутить его мягкую рукоять к твёрдой палке изолентой и привязать к головке гирю, но зачем так извращаться, когда можно взять другой, нормальный молоток?
Вот от игрового движка в стабильной версии, а также любых дополнений к нему ожидают, что это будет полноценный надёжный инструмент, а не какая-то фигня, которую нужно изолентой обматывать и придумывать костыли, чтобы заработала основная функция.
От того же воксельного ландшафта, очевидно, требуются коллизии, иначе зачем он вообще нужен? Это ландшафт, т.е. по нему ходят/ездят, а не просто абстрактная воксельная моделька. Если у ландшафта кривые коллизии, то он просто не подходит для использования, и нечего оправдываться тем, что тебе нужно самому что-то там подкручивать и настраивать для своей игры. Воксельный ландшафт в любой игре - воксельный ландшафт, т.е. твёрдая поверхность из кубиков. Если твоей игре нужен воксельный "ландшафт" без коллизий, то тебе нужна просто воксельная модель, а не ладншафт...
Многие конструкторы игр предоставляют что-то вроде готовой игры, в которую достаточно закинуть свои (или бесплатные) картинки, нарисовать карту, прописать реплики персонажей и играть. Они дают отточенные за десятилетия системы одного конкретного жанра и ожидают от тебя только контент и историю, которую ты хочешь рассказать. У них своя аудитория, их достаточно активно покупают и используют. Постепенно конструктор может начать поддерживать больше игр, реализуя больше игровых систем...
А в чём вклад моддера, создающего модификации к существующим играм? В создании нового контента, с которым игрок взаимодействует через уже существующие системы (создание новых систем достаточно редко из-за сложности и малого спроса). Нет смысла в 100500-й раз изобретать систему ходьбы, если тебе хочется поскорее расставить свои домики со своими персонажами и пройтись между ними. Поэтому конструкторы игр, как и моддинг существующих игр, достаточно популярны, игры на них продаются и даже некоторые глобальные моды к существующим играм становятся отдельной игрой (Valve вроде даже разрешает/разрешал продавать игры, созданные как глобальный мод к играм Valve).
>К инструментам относятся как к готовому продукту. Требуют от них готовой реализации...
Ты когда в строительном магазине молоток покупаешь, ожидаешь от него точного и стабильного выполнения работы. Если ты купил молоток, а у него рукоять гнётся и головка лёгкая, а в инструкции ты читаешь "известные баги версии, будут исправлены в будущем: рукоять гнётся; головка лёгкая", то ты, скорее всего, быстро вернёшься в магазин и потребуешь вернуть деньги за товар, не соответствующий своему описанию. Если же ты этот молоток не купил, а нашёл на улице или взял бесплатно у друга, ты его просто выкинешь или вернёшь другу, а не будешь плеваться и пытаться использовать по назначению, к которому он совершенно не приспособлен в текущем состоянии. Ты можешь, конечно, прикрутить его мягкую рукоять к твёрдой палке изолентой и привязать к головке гирю, но зачем так извращаться, когда можно взять другой, нормальный молоток?
Вот от игрового движка в стабильной версии, а также любых дополнений к нему ожидают, что это будет полноценный надёжный инструмент, а не какая-то фигня, которую нужно изолентой обматывать и придумывать костыли, чтобы заработала основная функция.
От того же воксельного ландшафта, очевидно, требуются коллизии, иначе зачем он вообще нужен? Это ландшафт, т.е. по нему ходят/ездят, а не просто абстрактная воксельная моделька. Если у ландшафта кривые коллизии, то он просто не подходит для использования, и нечего оправдываться тем, что тебе нужно самому что-то там подкручивать и настраивать для своей игры. Воксельный ландшафт в любой игре - воксельный ландшафт, т.е. твёрдая поверхность из кубиков. Если твоей игре нужен воксельный "ландшафт" без коллизий, то тебе нужна просто воксельная модель, а не ладншафт...
>тебе поставят под видом движка готовую игру
Многие конструкторы игр предоставляют что-то вроде готовой игры, в которую достаточно закинуть свои (или бесплатные) картинки, нарисовать карту, прописать реплики персонажей и играть. Они дают отточенные за десятилетия системы одного конкретного жанра и ожидают от тебя только контент и историю, которую ты хочешь рассказать. У них своя аудитория, их достаточно активно покупают и используют. Постепенно конструктор может начать поддерживать больше игр, реализуя больше игровых систем...
>В чём будет твой вклад разработчика?
А в чём вклад моддера, создающего модификации к существующим играм? В создании нового контента, с которым игрок взаимодействует через уже существующие системы (создание новых систем достаточно редко из-за сложности и малого спроса). Нет смысла в 100500-й раз изобретать систему ходьбы, если тебе хочется поскорее расставить свои домики со своими персонажами и пройтись между ними. Поэтому конструкторы игр, как и моддинг существующих игр, достаточно популярны, игры на них продаются и даже некоторые глобальные моды к существующим играм становятся отдельной игрой (Valve вроде даже разрешает/разрешал продавать игры, созданные как глобальный мод к играм Valve).
>>71421
Ты когда в строительном магазине молоток покупаешь, ожидаешь от него точного и стабильного выполнения работы. Если ты купил молоток, а у него рукоять гнётся и головка лёгкая, а в инструкции ты читаешь "известные баги версии, будут исправлены в будущем: рукоять гнётся; головка лёгкая", то ты, скорее всего, быстро вернёшься в магазин и потребуешь вернуть деньги за товар, не соответствующий своему описанию. Если же ты этот молоток не купил, а нашёл на улице или взял бесплатно у друга, ты его просто выкинешь или вернёшь другу, а не будешь плеваться и пытаться использовать по назначению, к которому он совершенно не приспособлен в текущем состоянии. Ты можешь, конечно, прикрутить его мягкую рукоять к твёрдой палке изолентой и привязать к головке гирю, но зачем так извращаться, когда можно взять другой, нормальный молоток?
Вот от игрового движка в стабильной версии, а также любых дополнений к нему ожидают, что это будет полноценный надёжный инструмент, а не какая-то фигня, которую нужно изолентой обматывать и придумывать костыли, чтобы заработала основная функция.
От того же воксельного ландшафта, очевидно, требуются коллизии, иначе зачем он вообще нужен? Это ландшафт, т.е. по нему ходят/ездят, а не просто абстрактная воксельная моделька. Если у ландшафта кривые коллизии, то он просто не подходит для использования, и нечего оправдываться тем, что тебе нужно самому что-то там подкручивать и настраивать для своей игры. Воксельный ландшафт в любой игре - воксельный ландшафт, т.е. твёрдая поверхность из кубиков. Если твоей игре нужен воксельный "ландшафт" без коллизий, то тебе нужна просто воксельная модель, а не ладншафт...
Многие конструкторы игр предоставляют что-то вроде готовой игры, в которую достаточно закинуть свои (или бесплатные) картинки, нарисовать карту, прописать реплики персонажей и играть. Они дают отточенные за десятилетия системы одного конкретного жанра и ожидают от тебя только контент и историю, которую ты хочешь рассказать. У них своя аудитория, их достаточно активно покупают и используют. Постепенно конструктор может начать поддерживать больше игр, реализуя больше игровых систем...
А в чём вклад моддера, создающего модификации к существующим играм? В создании нового контента, с которым игрок взаимодействует через уже существующие системы (создание новых систем достаточно редко из-за сложности и малого спроса). Нет смысла в 100500-й раз изобретать систему ходьбы, если тебе хочется поскорее расставить свои домики со своими персонажами и пройтись между ними. Поэтому конструкторы игр, как и моддинг существующих игр, достаточно популярны, игры на них продаются и даже некоторые глобальные моды к существующим играм становятся отдельной игрой (Valve вроде даже разрешает/разрешал продавать игры, созданные как глобальный мод к играм Valve).
>К инструментам относятся как к готовому продукту. Требуют от них готовой реализации...
Ты когда в строительном магазине молоток покупаешь, ожидаешь от него точного и стабильного выполнения работы. Если ты купил молоток, а у него рукоять гнётся и головка лёгкая, а в инструкции ты читаешь "известные баги версии, будут исправлены в будущем: рукоять гнётся; головка лёгкая", то ты, скорее всего, быстро вернёшься в магазин и потребуешь вернуть деньги за товар, не соответствующий своему описанию. Если же ты этот молоток не купил, а нашёл на улице или взял бесплатно у друга, ты его просто выкинешь или вернёшь другу, а не будешь плеваться и пытаться использовать по назначению, к которому он совершенно не приспособлен в текущем состоянии. Ты можешь, конечно, прикрутить его мягкую рукоять к твёрдой палке изолентой и привязать к головке гирю, но зачем так извращаться, когда можно взять другой, нормальный молоток?
Вот от игрового движка в стабильной версии, а также любых дополнений к нему ожидают, что это будет полноценный надёжный инструмент, а не какая-то фигня, которую нужно изолентой обматывать и придумывать костыли, чтобы заработала основная функция.
От того же воксельного ландшафта, очевидно, требуются коллизии, иначе зачем он вообще нужен? Это ландшафт, т.е. по нему ходят/ездят, а не просто абстрактная воксельная моделька. Если у ландшафта кривые коллизии, то он просто не подходит для использования, и нечего оправдываться тем, что тебе нужно самому что-то там подкручивать и настраивать для своей игры. Воксельный ландшафт в любой игре - воксельный ландшафт, т.е. твёрдая поверхность из кубиков. Если твоей игре нужен воксельный "ландшафт" без коллизий, то тебе нужна просто воксельная модель, а не ладншафт...
>тебе поставят под видом движка готовую игру
Многие конструкторы игр предоставляют что-то вроде готовой игры, в которую достаточно закинуть свои (или бесплатные) картинки, нарисовать карту, прописать реплики персонажей и играть. Они дают отточенные за десятилетия системы одного конкретного жанра и ожидают от тебя только контент и историю, которую ты хочешь рассказать. У них своя аудитория, их достаточно активно покупают и используют. Постепенно конструктор может начать поддерживать больше игр, реализуя больше игровых систем...
>В чём будет твой вклад разработчика?
А в чём вклад моддера, создающего модификации к существующим играм? В создании нового контента, с которым игрок взаимодействует через уже существующие системы (создание новых систем достаточно редко из-за сложности и малого спроса). Нет смысла в 100500-й раз изобретать систему ходьбы, если тебе хочется поскорее расставить свои домики со своими персонажами и пройтись между ними. Поэтому конструкторы игр, как и моддинг существующих игр, достаточно популярны, игры на них продаются и даже некоторые глобальные моды к существующим играм становятся отдельной игрой (Valve вроде даже разрешает/разрешал продавать игры, созданные как глобальный мод к играм Valve).
>>71504
Экспорт CSG в obj - сравнительно бесполезная фича. Я пробовал - не слишком сложная модель была ужасно порезана веерами из треугольников и этот хаос было тяжело пофиксить в Blender (для дальнейшей работы). Проще всего с нуля переделать в Blender, используя экспортированное месиво треугольников только как образец внешней формы, тем более что булевы операции с мешами в Blender тоже есть и результат у них вроде бы получше CSG в Godot. Просто предупреждаю, чтобы никто не фантазировал как я о том, как он будет сложные модели моделировать прямо в Godot - CSG официально заявлен только для прототипирования и нормальные модели от него ожидать не следует (нормальные - в смысле оптимальные по числу и форме треугольников, вершинам и т.д.). Накидать прототип уровня "из говна и палок" - очень хорошо, но потом всё равно придётся практически с нуля переделывать в том же Blender.
>CSG для прототипирования (который в принципе можно экспортнуть в меш)
Экспорт CSG в obj - сравнительно бесполезная фича. Я пробовал - не слишком сложная модель была ужасно порезана веерами из треугольников и этот хаос было тяжело пофиксить в Blender (для дальнейшей работы). Проще всего с нуля переделать в Blender, используя экспортированное месиво треугольников только как образец внешней формы, тем более что булевы операции с мешами в Blender тоже есть и результат у них вроде бы получше CSG в Godot. Просто предупреждаю, чтобы никто не фантазировал как я о том, как он будет сложные модели моделировать прямо в Godot - CSG официально заявлен только для прототипирования и нормальные модели от него ожидать не следует (нормальные - в смысле оптимальные по числу и форме треугольников, вершинам и т.д.). Накидать прототип уровня "из говна и палок" - очень хорошо, но потом всё равно придётся практически с нуля переделывать в том же Blender.
>>72146
Я??
Не драматизируй. Пускай делает это, например, во время запекания, или просто как предупреждения что вот в этом чанке вы используете слишком много текстур, передвиньте домики. Или показывает в специальном режиме как в overdraw.
Это миф, у них есть игры всех жанров от файтингов до гонок то стратегий.
Но вообще это словоблудие. Например большинству игр физика не нужна, но почему то никто не отказывается от нее в движке, хотя ровно по твоим же аргументам могли говорить - вам не нужна физика, напишите свою, вот вам Си и т.д.
Стриминг требует слишком глубокой интеграции в движок, поэтому логичнее иметь его в ядре.
>Предлагай свойства
Я??
> из-за того, что движок пытается по каким-то универсальным формулам предсказать поведение твоей уникальной игры
Не драматизируй. Пускай делает это, например, во время запекания, или просто как предупреждения что вот в этом чанке вы используете слишком много текстур, передвиньте домики. Или показывает в специальном режиме как в overdraw.
>для всего остального он подходит так же, как микроскоп для забивания гвоздей.
Это миф, у них есть игры всех жанров от файтингов до гонок то стратегий.
Но вообще это словоблудие. Например большинству игр физика не нужна, но почему то никто не отказывается от нее в движке, хотя ровно по твоим же аргументам могли говорить - вам не нужна физика, напишите свою, вот вам Си и т.д.
Стриминг требует слишком глубокой интеграции в движок, поэтому логичнее иметь его в ядре.
>>72153
Игровой движок некорректно сравнивать с молотком. Сравнивай с комплектом радиодеталей для сборки радиоконструктора.
Игровой движок некорректно сравнивать с молотком. Сравнивай с комплектом радиодеталей для сборки радиоконструктора.
>>72154
Ознакомься с инструментами ремеша.
https://www.youtube.com/watch?v=OccVb-fbCYI
> этот хаос было тяжело пофиксить в Blender
Ознакомься с инструментами ремеша.
https://www.youtube.com/watch?v=OccVb-fbCYI
>>72166
Это не панацея, тут простыми алгоритмами дело не решается, нужен сильный интеллект.
Это не панацея, тут простыми алгоритмами дело не решается, нужен сильный интеллект.
>>71578
Для большинства игр этого более чем достаточно.
Такое может быть необходимо, если ты хочешь сделать несколько разных управляемых игроком моделей, которые одновременно могут управляться компьютером. Но даже в таком случае, можно просто заменить скрипт на ноде прямо в рантайме, главное не забыть его инициализировать, если требуется.
>>71580
Это сомнительный подход, плодящий сущности без необходимости. Может сработать в небольшой игре, но если у тебя будет много таких персонажей и других сущностей, то ты в конечном итоге упрёшься в производительность цикла, обходящего дерево сцены в одном потоке. Не зря Godot предоставляет тебе низкоуровневые серверы для более оптимальной работы с графикой, физикой и другими компонентами движка без использования нодовой системы и дерева сцены.
Тем более сложно представить себе игру, в которой тебе регулярно требуется лишать игрока базовых способностей, вроде плавания, прыгания или бега. Если у тебя игрок перегружен или парализован, легко проверить это условие и запретить ему плавание, прыжки и бег. А если у тебя игрок может трансформироваться в животных, то ему нужно много чего менять (визуальный меш, коллизии, настройки физического тела и т.п.), а не просто давать дополнительную способность...
>>71582
Это нормально, если твой ребёнок никогда не используется отдельно от конкретного родительского узла. Ребёнок должен быть независим от родителя только если ты планируешь использовать его отдельно от какого-то конкретного родителя. Нода, которая ждёт ввод игрока и двигает родителя, скорее всего не будет лежать сама по себе - она всегда будет цепляться к тому, кого она может двигать.
В случае с персонажами, у тебя по-прежнему есть скрипт в KinematicBody, который объявляет методы движения, вроде move_to(point) или turn_left(). Дальше ты можешь реализовать два дополнительных скрипта: управление компьютером и управление игроком. Оба скрипта вызывают move_to() родителя, но первый делает это по какому-то алгоритму (ИИ), а второй делает это по требованию игрока. Тогда ты можешь менять схему управления персонажем, заменяя ноду. В то же время ты можешь пойти путём ООП, сделав эти два скрипта дочерними от основного скрипта, и заменяя скрипт KinematicBody. Особой разницы нет, кроме того, что в первом случае тебе нужна дополнительная нода, захламляющая дерево сцены, а во втором случае ты уже не можешь накинуть свой контроллер на другой объект с методом move_to(point). Конкретный выбор стоит за тобой, в зависимости от потребностей твоей игры или твоих предпочтений.
>>71612
Глупости не говори, это не "идея годота".
Во-первых, нода CollisionObject может существовать без CollisionShape, а CollisionShape может существовать без CollisionObject; да, они могут выводить сообщение об ошибке, но это ни на что не влияет. Во-вторых, CollisionShape не "меняет поведение" - она только несёт в себе данные, которые отправляются в PhysicsServer для конкретного физического тела, созданного CollisionObject, и дальнейшая работа уже зависит от PhysicsServer, а не дерева сцены. В-третьих, CollisionShape вообще задумывалась и остаётся как нода-помощник для редактора сцен:
Намного чаще можно встретить обратную ситуацию, когда нода-родитель управляет своими потомками, в частности, это хорошо видно на примере контейнеров Control-нод: ты закидываешь ноду в контейнер и дальше контейнер управляет свойствами этой ноды, размещая её относительно других своих нод, а не наоборот. Если применить ту же логику на физику, то становится ясно, что это CollisionObject использует предоставленные ему CollisionShape, наделяя их каким-то поведением (физическое тело, зона/триггер), а не наоборот. Аналогично с VehicleBody, который использует предоставленные VehicleWheel, а не VehicleWheel действует на VehicleBody. Если бы было наоборот, то тебе следовало бы ожидать, что VehicleWheel позволяет приделать колёсико к любой ноде помимо VehicleBody, что CollisionShape позволяет наделить коллизиями любую ноду помимо CollisionObject, что любая Control нода может упорядочить себя относительно своих соседей внутри любой ноды помимо контейнеров, что любой Sprite/MeshInstance может нарисовать себя на любой другой ноде помимо Viewport и т.д.
>>71613
И будет у тебя по 100500 нод на каждом персонаже сложнее болванчика-статиста. Сначала начнутся пропуки, когда ты добавляешь нового персонажа со 100500 нодами-"стейтами", а потом начнутся пропуки, когда ты захочешь больше десятка таких персонажей. В документации уже несколько лет визит гайд по оптимизации игры, в котором с порога заявляется недостаток дерева сцены и объясняется причина, по которой безрассудно спамить нодами - плохо.
Что конкретно заставляет тебя реализовывать "стейты стейтмашины" (описывать состояния конечного автомата, если по-русски) в виде нод дерева сцены? По-моему это бессмысленно, не будешь же ты составлять конечный автомат вручную прямо в редакторе сцен, а для изменений в рантайме можно использовать любой другой способ.
>>71639
И тем не менее, официально рекомендуется избегать создания лишних нод, и предоставляется множество доступных из коробки инструментов, работающих без дерева сцены. Можно даже написать свой игровой цикл, который не будет реализовать дерево сцены. Встроенное дерево сцены идеально для мелких игр, но плохо подходит для игр с большим количеством сущностей.
>>71634
Ты можешь реализовать своё дерево сцены даже на GDScript, хотя лучше, конечно, использовать C++. Проблема в том, что текущая концепция дерева сцены не позволяет применить на него многопоточность: ноды должны обрабатываться в строго определённом порядке, иначе начнётся хаос, неуловимые ошибки из-за того, что какая-то нода опередила другую, просто из-за того, что одно ядро процессора нагружено меньше другого. Тем более что мы говорим не о базовых нодах, а нодах с кастомными скриптами, в которых будет ещё больше проблем из-за принудительной многопоточности.
>код для управления игроком накидываете прям в ноду игрока
Для большинства игр этого более чем достаточно.
>создаете отдельную ноду-контроллер и к ней игрока крепите
Такое может быть необходимо, если ты хочешь сделать несколько разных управляемых игроком моделей, которые одновременно могут управляться компьютером. Но даже в таком случае, можно просто заменить скрипт на ноде прямо в рантайме, главное не забыть его инициализировать, если требуется.
>>71580
>ноды описывающие поведение в конкретных ситуациях (прыжок, плаванье и тд)
Это сомнительный подход, плодящий сущности без необходимости. Может сработать в небольшой игре, но если у тебя будет много таких персонажей и других сущностей, то ты в конечном итоге упрёшься в производительность цикла, обходящего дерево сцены в одном потоке. Не зря Godot предоставляет тебе низкоуровневые серверы для более оптимальной работы с графикой, физикой и другими компонентами движка без использования нодовой системы и дерева сцены.
Тем более сложно представить себе игру, в которой тебе регулярно требуется лишать игрока базовых способностей, вроде плавания, прыгания или бега. Если у тебя игрок перегружен или парализован, легко проверить это условие и запретить ему плавание, прыжки и бег. А если у тебя игрок может трансформироваться в животных, то ему нужно много чего менять (визуальный меш, коллизии, настройки физического тела и т.п.), а не просто давать дополнительную способность...
>>71582
>ребенок будет изменять состояние родительского узла
Это нормально, если твой ребёнок никогда не используется отдельно от конкретного родительского узла. Ребёнок должен быть независим от родителя только если ты планируешь использовать его отдельно от какого-то конкретного родителя. Нода, которая ждёт ввод игрока и двигает родителя, скорее всего не будет лежать сама по себе - она всегда будет цепляться к тому, кого она может двигать.
В случае с персонажами, у тебя по-прежнему есть скрипт в KinematicBody, который объявляет методы движения, вроде move_to(point) или turn_left(). Дальше ты можешь реализовать два дополнительных скрипта: управление компьютером и управление игроком. Оба скрипта вызывают move_to() родителя, но первый делает это по какому-то алгоритму (ИИ), а второй делает это по требованию игрока. Тогда ты можешь менять схему управления персонажем, заменяя ноду. В то же время ты можешь пойти путём ООП, сделав эти два скрипта дочерними от основного скрипта, и заменяя скрипт KinematicBody. Особой разницы нет, кроме того, что в первом случае тебе нужна дополнительная нода, захламляющая дерево сцены, а во втором случае ты уже не можешь накинуть свой контроллер на другой объект с методом move_to(point). Конкретный выбор стоит за тобой, в зависимости от потребностей твоей игры или твоих предпочтений.
>>71612
>идея годота как раз в том, что поведение сцены (родителя) - это и есть сумма поведений всех её детей
Глупости не говори, это не "идея годота".
>Главнейший пример здесь: ноды-наследники PhysicsBody, которым обязательно нужны дети CollisionShape, изменяющие поведение родителя, а именно, придающие родителю физическую форму.
Во-первых, нода CollisionObject может существовать без CollisionShape, а CollisionShape может существовать без CollisionObject; да, они могут выводить сообщение об ошибке, но это ни на что не влияет. Во-вторых, CollisionShape не "меняет поведение" - она только несёт в себе данные, которые отправляются в PhysicsServer для конкретного физического тела, созданного CollisionObject, и дальнейшая работа уже зависит от PhysicsServer, а не дерева сцены. В-третьих, CollisionShape вообще задумывалась и остаётся как нода-помощник для редактора сцен:
>Editor facility for creating and editing collision shapes in 3D space. Set the shape property to configure the shape. IMPORTANT: this is an Editor-only helper to create shapes, use CollisionObject3D.shape_owner_get_shape to get the actual shape.
Намного чаще можно встретить обратную ситуацию, когда нода-родитель управляет своими потомками, в частности, это хорошо видно на примере контейнеров Control-нод: ты закидываешь ноду в контейнер и дальше контейнер управляет свойствами этой ноды, размещая её относительно других своих нод, а не наоборот. Если применить ту же логику на физику, то становится ясно, что это CollisionObject использует предоставленные ему CollisionShape, наделяя их каким-то поведением (физическое тело, зона/триггер), а не наоборот. Аналогично с VehicleBody, который использует предоставленные VehicleWheel, а не VehicleWheel действует на VehicleBody. Если бы было наоборот, то тебе следовало бы ожидать, что VehicleWheel позволяет приделать колёсико к любой ноде помимо VehicleBody, что CollisionShape позволяет наделить коллизиями любую ноду помимо CollisionObject, что любая Control нода может упорядочить себя относительно своих соседей внутри любой ноды помимо контейнеров, что любой Sprite/MeshInstance может нарисовать себя на любой другой ноде помимо Viewport и т.д.
>>71613
>Причём эти ноды не просто контроллеры, а стейты стейтмашины
И будет у тебя по 100500 нод на каждом персонаже сложнее болванчика-статиста. Сначала начнутся пропуки, когда ты добавляешь нового персонажа со 100500 нодами-"стейтами", а потом начнутся пропуки, когда ты захочешь больше десятка таких персонажей. В документации уже несколько лет визит гайд по оптимизации игры, в котором с порога заявляется недостаток дерева сцены и объясняется причина, по которой безрассудно спамить нодами - плохо.
Что конкретно заставляет тебя реализовывать "стейты стейтмашины" (описывать состояния конечного автомата, если по-русски) в виде нод дерева сцены? По-моему это бессмысленно, не будешь же ты составлять конечный автомат вручную прямо в редакторе сцен, а для изменений в рантайме можно использовать любой другой способ.
>>71639
>нагрузка там минимальна
И тем не менее, официально рекомендуется избегать создания лишних нод, и предоставляется множество доступных из коробки инструментов, работающих без дерева сцены. Можно даже написать свой игровой цикл, который не будет реализовать дерево сцены. Встроенное дерево сцены идеально для мелких игр, но плохо подходит для игр с большим количеством сущностей.
>>71634
>массивное переосмысление производительности
Ты можешь реализовать своё дерево сцены даже на GDScript, хотя лучше, конечно, использовать C++. Проблема в том, что текущая концепция дерева сцены не позволяет применить на него многопоточность: ноды должны обрабатываться в строго определённом порядке, иначе начнётся хаос, неуловимые ошибки из-за того, что какая-то нода опередила другую, просто из-за того, что одно ядро процессора нагружено меньше другого. Тем более что мы говорим не о базовых нодах, а нодах с кастомными скриптами, в которых будет ещё больше проблем из-за принудительной многопоточности.
>>71578
Для большинства игр этого более чем достаточно.
Такое может быть необходимо, если ты хочешь сделать несколько разных управляемых игроком моделей, которые одновременно могут управляться компьютером. Но даже в таком случае, можно просто заменить скрипт на ноде прямо в рантайме, главное не забыть его инициализировать, если требуется.
>>71580
Это сомнительный подход, плодящий сущности без необходимости. Может сработать в небольшой игре, но если у тебя будет много таких персонажей и других сущностей, то ты в конечном итоге упрёшься в производительность цикла, обходящего дерево сцены в одном потоке. Не зря Godot предоставляет тебе низкоуровневые серверы для более оптимальной работы с графикой, физикой и другими компонентами движка без использования нодовой системы и дерева сцены.
Тем более сложно представить себе игру, в которой тебе регулярно требуется лишать игрока базовых способностей, вроде плавания, прыгания или бега. Если у тебя игрок перегружен или парализован, легко проверить это условие и запретить ему плавание, прыжки и бег. А если у тебя игрок может трансформироваться в животных, то ему нужно много чего менять (визуальный меш, коллизии, настройки физического тела и т.п.), а не просто давать дополнительную способность...
>>71582
Это нормально, если твой ребёнок никогда не используется отдельно от конкретного родительского узла. Ребёнок должен быть независим от родителя только если ты планируешь использовать его отдельно от какого-то конкретного родителя. Нода, которая ждёт ввод игрока и двигает родителя, скорее всего не будет лежать сама по себе - она всегда будет цепляться к тому, кого она может двигать.
В случае с персонажами, у тебя по-прежнему есть скрипт в KinematicBody, который объявляет методы движения, вроде move_to(point) или turn_left(). Дальше ты можешь реализовать два дополнительных скрипта: управление компьютером и управление игроком. Оба скрипта вызывают move_to() родителя, но первый делает это по какому-то алгоритму (ИИ), а второй делает это по требованию игрока. Тогда ты можешь менять схему управления персонажем, заменяя ноду. В то же время ты можешь пойти путём ООП, сделав эти два скрипта дочерними от основного скрипта, и заменяя скрипт KinematicBody. Особой разницы нет, кроме того, что в первом случае тебе нужна дополнительная нода, захламляющая дерево сцены, а во втором случае ты уже не можешь накинуть свой контроллер на другой объект с методом move_to(point). Конкретный выбор стоит за тобой, в зависимости от потребностей твоей игры или твоих предпочтений.
>>71612
Глупости не говори, это не "идея годота".
Во-первых, нода CollisionObject может существовать без CollisionShape, а CollisionShape может существовать без CollisionObject; да, они могут выводить сообщение об ошибке, но это ни на что не влияет. Во-вторых, CollisionShape не "меняет поведение" - она только несёт в себе данные, которые отправляются в PhysicsServer для конкретного физического тела, созданного CollisionObject, и дальнейшая работа уже зависит от PhysicsServer, а не дерева сцены. В-третьих, CollisionShape вообще задумывалась и остаётся как нода-помощник для редактора сцен:
Намного чаще можно встретить обратную ситуацию, когда нода-родитель управляет своими потомками, в частности, это хорошо видно на примере контейнеров Control-нод: ты закидываешь ноду в контейнер и дальше контейнер управляет свойствами этой ноды, размещая её относительно других своих нод, а не наоборот. Если применить ту же логику на физику, то становится ясно, что это CollisionObject использует предоставленные ему CollisionShape, наделяя их каким-то поведением (физическое тело, зона/триггер), а не наоборот. Аналогично с VehicleBody, который использует предоставленные VehicleWheel, а не VehicleWheel действует на VehicleBody. Если бы было наоборот, то тебе следовало бы ожидать, что VehicleWheel позволяет приделать колёсико к любой ноде помимо VehicleBody, что CollisionShape позволяет наделить коллизиями любую ноду помимо CollisionObject, что любая Control нода может упорядочить себя относительно своих соседей внутри любой ноды помимо контейнеров, что любой Sprite/MeshInstance может нарисовать себя на любой другой ноде помимо Viewport и т.д.
>>71613
И будет у тебя по 100500 нод на каждом персонаже сложнее болванчика-статиста. Сначала начнутся пропуки, когда ты добавляешь нового персонажа со 100500 нодами-"стейтами", а потом начнутся пропуки, когда ты захочешь больше десятка таких персонажей. В документации уже несколько лет визит гайд по оптимизации игры, в котором с порога заявляется недостаток дерева сцены и объясняется причина, по которой безрассудно спамить нодами - плохо.
Что конкретно заставляет тебя реализовывать "стейты стейтмашины" (описывать состояния конечного автомата, если по-русски) в виде нод дерева сцены? По-моему это бессмысленно, не будешь же ты составлять конечный автомат вручную прямо в редакторе сцен, а для изменений в рантайме можно использовать любой другой способ.
>>71639
И тем не менее, официально рекомендуется избегать создания лишних нод, и предоставляется множество доступных из коробки инструментов, работающих без дерева сцены. Можно даже написать свой игровой цикл, который не будет реализовать дерево сцены. Встроенное дерево сцены идеально для мелких игр, но плохо подходит для игр с большим количеством сущностей.
>>71634
Ты можешь реализовать своё дерево сцены даже на GDScript, хотя лучше, конечно, использовать C++. Проблема в том, что текущая концепция дерева сцены не позволяет применить на него многопоточность: ноды должны обрабатываться в строго определённом порядке, иначе начнётся хаос, неуловимые ошибки из-за того, что какая-то нода опередила другую, просто из-за того, что одно ядро процессора нагружено меньше другого. Тем более что мы говорим не о базовых нодах, а нодах с кастомными скриптами, в которых будет ещё больше проблем из-за принудительной многопоточности.
>код для управления игроком накидываете прям в ноду игрока
Для большинства игр этого более чем достаточно.
>создаете отдельную ноду-контроллер и к ней игрока крепите
Такое может быть необходимо, если ты хочешь сделать несколько разных управляемых игроком моделей, которые одновременно могут управляться компьютером. Но даже в таком случае, можно просто заменить скрипт на ноде прямо в рантайме, главное не забыть его инициализировать, если требуется.
>>71580
>ноды описывающие поведение в конкретных ситуациях (прыжок, плаванье и тд)
Это сомнительный подход, плодящий сущности без необходимости. Может сработать в небольшой игре, но если у тебя будет много таких персонажей и других сущностей, то ты в конечном итоге упрёшься в производительность цикла, обходящего дерево сцены в одном потоке. Не зря Godot предоставляет тебе низкоуровневые серверы для более оптимальной работы с графикой, физикой и другими компонентами движка без использования нодовой системы и дерева сцены.
Тем более сложно представить себе игру, в которой тебе регулярно требуется лишать игрока базовых способностей, вроде плавания, прыгания или бега. Если у тебя игрок перегружен или парализован, легко проверить это условие и запретить ему плавание, прыжки и бег. А если у тебя игрок может трансформироваться в животных, то ему нужно много чего менять (визуальный меш, коллизии, настройки физического тела и т.п.), а не просто давать дополнительную способность...
>>71582
>ребенок будет изменять состояние родительского узла
Это нормально, если твой ребёнок никогда не используется отдельно от конкретного родительского узла. Ребёнок должен быть независим от родителя только если ты планируешь использовать его отдельно от какого-то конкретного родителя. Нода, которая ждёт ввод игрока и двигает родителя, скорее всего не будет лежать сама по себе - она всегда будет цепляться к тому, кого она может двигать.
В случае с персонажами, у тебя по-прежнему есть скрипт в KinematicBody, который объявляет методы движения, вроде move_to(point) или turn_left(). Дальше ты можешь реализовать два дополнительных скрипта: управление компьютером и управление игроком. Оба скрипта вызывают move_to() родителя, но первый делает это по какому-то алгоритму (ИИ), а второй делает это по требованию игрока. Тогда ты можешь менять схему управления персонажем, заменяя ноду. В то же время ты можешь пойти путём ООП, сделав эти два скрипта дочерними от основного скрипта, и заменяя скрипт KinematicBody. Особой разницы нет, кроме того, что в первом случае тебе нужна дополнительная нода, захламляющая дерево сцены, а во втором случае ты уже не можешь накинуть свой контроллер на другой объект с методом move_to(point). Конкретный выбор стоит за тобой, в зависимости от потребностей твоей игры или твоих предпочтений.
>>71612
>идея годота как раз в том, что поведение сцены (родителя) - это и есть сумма поведений всех её детей
Глупости не говори, это не "идея годота".
>Главнейший пример здесь: ноды-наследники PhysicsBody, которым обязательно нужны дети CollisionShape, изменяющие поведение родителя, а именно, придающие родителю физическую форму.
Во-первых, нода CollisionObject может существовать без CollisionShape, а CollisionShape может существовать без CollisionObject; да, они могут выводить сообщение об ошибке, но это ни на что не влияет. Во-вторых, CollisionShape не "меняет поведение" - она только несёт в себе данные, которые отправляются в PhysicsServer для конкретного физического тела, созданного CollisionObject, и дальнейшая работа уже зависит от PhysicsServer, а не дерева сцены. В-третьих, CollisionShape вообще задумывалась и остаётся как нода-помощник для редактора сцен:
>Editor facility for creating and editing collision shapes in 3D space. Set the shape property to configure the shape. IMPORTANT: this is an Editor-only helper to create shapes, use CollisionObject3D.shape_owner_get_shape to get the actual shape.
Намного чаще можно встретить обратную ситуацию, когда нода-родитель управляет своими потомками, в частности, это хорошо видно на примере контейнеров Control-нод: ты закидываешь ноду в контейнер и дальше контейнер управляет свойствами этой ноды, размещая её относительно других своих нод, а не наоборот. Если применить ту же логику на физику, то становится ясно, что это CollisionObject использует предоставленные ему CollisionShape, наделяя их каким-то поведением (физическое тело, зона/триггер), а не наоборот. Аналогично с VehicleBody, который использует предоставленные VehicleWheel, а не VehicleWheel действует на VehicleBody. Если бы было наоборот, то тебе следовало бы ожидать, что VehicleWheel позволяет приделать колёсико к любой ноде помимо VehicleBody, что CollisionShape позволяет наделить коллизиями любую ноду помимо CollisionObject, что любая Control нода может упорядочить себя относительно своих соседей внутри любой ноды помимо контейнеров, что любой Sprite/MeshInstance может нарисовать себя на любой другой ноде помимо Viewport и т.д.
>>71613
>Причём эти ноды не просто контроллеры, а стейты стейтмашины
И будет у тебя по 100500 нод на каждом персонаже сложнее болванчика-статиста. Сначала начнутся пропуки, когда ты добавляешь нового персонажа со 100500 нодами-"стейтами", а потом начнутся пропуки, когда ты захочешь больше десятка таких персонажей. В документации уже несколько лет визит гайд по оптимизации игры, в котором с порога заявляется недостаток дерева сцены и объясняется причина, по которой безрассудно спамить нодами - плохо.
Что конкретно заставляет тебя реализовывать "стейты стейтмашины" (описывать состояния конечного автомата, если по-русски) в виде нод дерева сцены? По-моему это бессмысленно, не будешь же ты составлять конечный автомат вручную прямо в редакторе сцен, а для изменений в рантайме можно использовать любой другой способ.
>>71639
>нагрузка там минимальна
И тем не менее, официально рекомендуется избегать создания лишних нод, и предоставляется множество доступных из коробки инструментов, работающих без дерева сцены. Можно даже написать свой игровой цикл, который не будет реализовать дерево сцены. Встроенное дерево сцены идеально для мелких игр, но плохо подходит для игр с большим количеством сущностей.
>>71634
>массивное переосмысление производительности
Ты можешь реализовать своё дерево сцены даже на GDScript, хотя лучше, конечно, использовать C++. Проблема в том, что текущая концепция дерева сцены не позволяет применить на него многопоточность: ноды должны обрабатываться в строго определённом порядке, иначе начнётся хаос, неуловимые ошибки из-за того, что какая-то нода опередила другую, просто из-за того, что одно ядро процессора нагружено меньше другого. Тем более что мы говорим не о базовых нодах, а нодах с кастомными скриптами, в которых будет ещё больше проблем из-за принудительной многопоточности.
>>72153
Нет, ну почему, воксельный ландшафт может быть с коллизией и без коллизий (например, если тебе нужна просто генерация красивых гор на фоне, да или вообще у тебя игра не про хождение, а про созерцание ланшафтов - при этом генерация и модифицируемость по прежнему важна). Просто в том конкретном случае это очевидный баг.
Нет, ну почему, воксельный ландшафт может быть с коллизией и без коллизий (например, если тебе нужна просто генерация красивых гор на фоне, да или вообще у тебя игра не про хождение, а про созерцание ланшафтов - при этом генерация и модифицируемость по прежнему важна). Просто в том конкретном случае это очевидный баг.
18 Кб, 569x226>>72166
Ты видео своё смотрел? Там с первого кадра сразу видна проблема этого модификатора, см. пикрил. Он предоставляет тебе аж четыре способа высрать говно вместо модели, которое вообще непонятно как потом использовать. Может быть, оно подойдёт для дальнейшей лепки, или ещё чего-то, но аккуратную лоупольку оно только похерить может, а с месивом из CSG вообще не справится.
>инструментами ремеша
Ты видео своё смотрел? Там с первого кадра сразу видна проблема этого модификатора, см. пикрил. Он предоставляет тебе аж четыре способа высрать говно вместо модели, которое вообще непонятно как потом использовать. Может быть, оно подойдёт для дальнейшей лепки, или ещё чего-то, но аккуратную лоупольку оно только похерить может, а с месивом из CSG вообще не справится.
>>72168
Нет.
Не факт что упрешься, без конкретных измерений это пустые слова.
Не факт что проверки в гдскрипте условий будут быстрее, чем обход нод внутри движка.
А это вообще перпендикулярно способностям. Ничего не мешает менять визуал в одном месте, а способности раздавать в стиле ECS.
>Это сомнительный подход
Нет.
>. Может сработать в небольшой игре, но если у тебя будет много таких персонажей и других сущностей, то ты в конечном итоге упрёшься в производительность цикла,
Не факт что упрешься, без конкретных измерений это пустые слова.
> легко проверить это условие и запретить ему плавание, прыжки и бег
Не факт что проверки в гдскрипте условий будут быстрее, чем обход нод внутри движка.
> А если у тебя игрок может трансформироваться в животных, то ему нужно много чего менять (визуальный меш, коллизии, настройки физического тела и т.п.), а не просто давать дополнительную способность...
А это вообще перпендикулярно способностям. Ничего не мешает менять визуал в одном месте, а способности раздавать в стиле ECS.
>>72170
Да. Загуглил, запостил и пошёл смотреть.
Пошёл нахуй. В срачетред.
> Ты видео своё смотрел?
Да. Загуглил, запостил и пошёл смотреть.
> проблема этого модификатора, см. пикрил. Он предоставляет тебе аж четыре способа высрать говно
Пошёл нахуй. В срачетред.
>>72172
А зачем ты тогда запостил заведомо нерабочее решение? Чтобы разжигать срач? Тебя зарепортить?
А зачем ты тогда запостил заведомо нерабочее решение? Чтобы разжигать срач? Тебя зарепортить?
>>72168
Я вот не особо кодер и нихуя не понял изъебов в тех двух примерах стейт машин что сюда постили. Как-то перегружено все и нихуя не читается толком.
Я вот не особо кодер и нихуя не понял изъебов в тех двух примерах стейт машин что сюда постили. Как-то перегружено все и нихуя не читается толком.
>>72155
А кто, я? Это ты хочешь универсальный стриминг из коробки с какими-то свойствами для объектов, которые каким-то образом должны указывать, когда и как загружается этот ресурс. Предлагай свойства, мне лень думать об этом сейчас (я ещё не сталкивался с необходимостью выгружать ресурсы из памяти, за исключением выхода из игры в главное меню).
Как ты предлагаешь "запечь" поведение игрока, который может сначала захотеть пойти туда, а потом совершено внезапно в противоположном направлении, или телепортируется, или будет убит и воскрешён в совершенно другом месте? Игра должна предсказывать и подгружать ресурсы, чтобы игрок не сталкивался с падением в пустоту или загрузочным экраном. Раньше игры часто использовали загрузочные экраны как раз потому, что им не хватало возможностей железа тех лет для динамической подгрузки данных, поэтому просто отображали экран-заглушку, пока грузится следующая часть мира.
Вот у тебя в коде есть метод teleport(x, y, z), как движок узнает, что он должен успеть загрузить все необходимые ресурсы в той локации, пока проигрывается анимация телепортации? Тебе в любом случае придётся делать какие-то низкоуровневые запросы, типа load_world_data_at(x, y, z), вот только содержание этой функции будет сильно зависеть от того, как устроен твой игровой мир. Если у тебя просто статичные декорации - это легко, а если тебе нужно кроме загрузки данных вычислить положение и состояние ИИ-персонажей? Универсального решения для всех не выйдет, тебе всё равно придётся велосипедить что-то вокруг низкоуровнего API (которое в Godot есть) или использовать готовые ассеты, подходящие под твой жанр.
Ты же не знаешь, как они внутри устроены...
Таки физика нужна многим играм. Простая проверка коллизий нужна ещё чаще, чем симуляция правдоподобной физики, но симуляция физики тоже нужна часто. Намного чаще, чем чанковая система и динамическая загрузка данных огромного мира.
В каком смысле? Загрузчики данных в движке есть. Если ты никак данные не используешь (нигде не сохраняешь ссылку или перезаписываешь её nil), то они автоматически выгружаются. Тебе нужна только высокоуровневая логика - когда, где и как подгружать конкретные модели и текстуры. Если у тебя игрок телепортируется в деревню, которую разрушили в его отсутствие, ты в своём коде должен подгрузить ассеты разрушенной деревни, а не полагаться на движок, который должен каким-то чудом догадаться, что после телепортации игрок должен сразу увидеть вокруг себя руины, а не обычную деревню.
>>Предлагай свойства
>Я??
А кто, я? Это ты хочешь универсальный стриминг из коробки с какими-то свойствами для объектов, которые каким-то образом должны указывать, когда и как загружается этот ресурс. Предлагай свойства, мне лень думать об этом сейчас (я ещё не сталкивался с необходимостью выгружать ресурсы из памяти, за исключением выхода из игры в главное меню).
>Пускай делает это, например, во время запекания
Как ты предлагаешь "запечь" поведение игрока, который может сначала захотеть пойти туда, а потом совершено внезапно в противоположном направлении, или телепортируется, или будет убит и воскрешён в совершенно другом месте? Игра должна предсказывать и подгружать ресурсы, чтобы игрок не сталкивался с падением в пустоту или загрузочным экраном. Раньше игры часто использовали загрузочные экраны как раз потому, что им не хватало возможностей железа тех лет для динамической подгрузки данных, поэтому просто отображали экран-заглушку, пока грузится следующая часть мира.
Вот у тебя в коде есть метод teleport(x, y, z), как движок узнает, что он должен успеть загрузить все необходимые ресурсы в той локации, пока проигрывается анимация телепортации? Тебе в любом случае придётся делать какие-то низкоуровневые запросы, типа load_world_data_at(x, y, z), вот только содержание этой функции будет сильно зависеть от того, как устроен твой игровой мир. Если у тебя просто статичные декорации - это легко, а если тебе нужно кроме загрузки данных вычислить положение и состояние ИИ-персонажей? Универсального решения для всех не выйдет, тебе всё равно придётся велосипедить что-то вокруг низкоуровнего API (которое в Godot есть) или использовать готовые ассеты, подходящие под твой жанр.
>у них есть игры всех жанров
Ты же не знаешь, как они внутри устроены...
>большинству игр физика не нужна
Таки физика нужна многим играм. Простая проверка коллизий нужна ещё чаще, чем симуляция правдоподобной физики, но симуляция физики тоже нужна часто. Намного чаще, чем чанковая система и динамическая загрузка данных огромного мира.
>Стриминг требует слишком глубокой интеграции в движок
В каком смысле? Загрузчики данных в движке есть. Если ты никак данные не используешь (нигде не сохраняешь ссылку или перезаписываешь её nil), то они автоматически выгружаются. Тебе нужна только высокоуровневая логика - когда, где и как подгружать конкретные модели и текстуры. Если у тебя игрок телепортируется в деревню, которую разрушили в его отсутствие, ты в своём коде должен подгрузить ассеты разрушенной деревни, а не полагаться на движок, который должен каким-то чудом догадаться, что после телепортации игрок должен сразу увидеть вокруг себя руины, а не обычную деревню.
>>72155
А кто, я? Это ты хочешь универсальный стриминг из коробки с какими-то свойствами для объектов, которые каким-то образом должны указывать, когда и как загружается этот ресурс. Предлагай свойства, мне лень думать об этом сейчас (я ещё не сталкивался с необходимостью выгружать ресурсы из памяти, за исключением выхода из игры в главное меню).
Как ты предлагаешь "запечь" поведение игрока, который может сначала захотеть пойти туда, а потом совершено внезапно в противоположном направлении, или телепортируется, или будет убит и воскрешён в совершенно другом месте? Игра должна предсказывать и подгружать ресурсы, чтобы игрок не сталкивался с падением в пустоту или загрузочным экраном. Раньше игры часто использовали загрузочные экраны как раз потому, что им не хватало возможностей железа тех лет для динамической подгрузки данных, поэтому просто отображали экран-заглушку, пока грузится следующая часть мира.
Вот у тебя в коде есть метод teleport(x, y, z), как движок узнает, что он должен успеть загрузить все необходимые ресурсы в той локации, пока проигрывается анимация телепортации? Тебе в любом случае придётся делать какие-то низкоуровневые запросы, типа load_world_data_at(x, y, z), вот только содержание этой функции будет сильно зависеть от того, как устроен твой игровой мир. Если у тебя просто статичные декорации - это легко, а если тебе нужно кроме загрузки данных вычислить положение и состояние ИИ-персонажей? Универсального решения для всех не выйдет, тебе всё равно придётся велосипедить что-то вокруг низкоуровнего API (которое в Godot есть) или использовать готовые ассеты, подходящие под твой жанр.
Ты же не знаешь, как они внутри устроены...
Таки физика нужна многим играм. Простая проверка коллизий нужна ещё чаще, чем симуляция правдоподобной физики, но симуляция физики тоже нужна часто. Намного чаще, чем чанковая система и динамическая загрузка данных огромного мира.
В каком смысле? Загрузчики данных в движке есть. Если ты никак данные не используешь (нигде не сохраняешь ссылку или перезаписываешь её nil), то они автоматически выгружаются. Тебе нужна только высокоуровневая логика - когда, где и как подгружать конкретные модели и текстуры. Если у тебя игрок телепортируется в деревню, которую разрушили в его отсутствие, ты в своём коде должен подгрузить ассеты разрушенной деревни, а не полагаться на движок, который должен каким-то чудом догадаться, что после телепортации игрок должен сразу увидеть вокруг себя руины, а не обычную деревню.
>>Предлагай свойства
>Я??
А кто, я? Это ты хочешь универсальный стриминг из коробки с какими-то свойствами для объектов, которые каким-то образом должны указывать, когда и как загружается этот ресурс. Предлагай свойства, мне лень думать об этом сейчас (я ещё не сталкивался с необходимостью выгружать ресурсы из памяти, за исключением выхода из игры в главное меню).
>Пускай делает это, например, во время запекания
Как ты предлагаешь "запечь" поведение игрока, который может сначала захотеть пойти туда, а потом совершено внезапно в противоположном направлении, или телепортируется, или будет убит и воскрешён в совершенно другом месте? Игра должна предсказывать и подгружать ресурсы, чтобы игрок не сталкивался с падением в пустоту или загрузочным экраном. Раньше игры часто использовали загрузочные экраны как раз потому, что им не хватало возможностей железа тех лет для динамической подгрузки данных, поэтому просто отображали экран-заглушку, пока грузится следующая часть мира.
Вот у тебя в коде есть метод teleport(x, y, z), как движок узнает, что он должен успеть загрузить все необходимые ресурсы в той локации, пока проигрывается анимация телепортации? Тебе в любом случае придётся делать какие-то низкоуровневые запросы, типа load_world_data_at(x, y, z), вот только содержание этой функции будет сильно зависеть от того, как устроен твой игровой мир. Если у тебя просто статичные декорации - это легко, а если тебе нужно кроме загрузки данных вычислить положение и состояние ИИ-персонажей? Универсального решения для всех не выйдет, тебе всё равно придётся велосипедить что-то вокруг низкоуровнего API (которое в Godot есть) или использовать готовые ассеты, подходящие под твой жанр.
>у них есть игры всех жанров
Ты же не знаешь, как они внутри устроены...
>большинству игр физика не нужна
Таки физика нужна многим играм. Простая проверка коллизий нужна ещё чаще, чем симуляция правдоподобной физики, но симуляция физики тоже нужна часто. Намного чаще, чем чанковая система и динамическая загрузка данных огромного мира.
>Стриминг требует слишком глубокой интеграции в движок
В каком смысле? Загрузчики данных в движке есть. Если ты никак данные не используешь (нигде не сохраняешь ссылку или перезаписываешь её nil), то они автоматически выгружаются. Тебе нужна только высокоуровневая логика - когда, где и как подгружать конкретные модели и текстуры. Если у тебя игрок телепортируется в деревню, которую разрушили в его отсутствие, ты в своём коде должен подгрузить ассеты разрушенной деревни, а не полагаться на движок, который должен каким-то чудом догадаться, что после телепортации игрок должен сразу увидеть вокруг себя руины, а не обычную деревню.
>>72172
А я в Blender сижу как минимум с 2015 года, если не раньше. И прекрасно знаю про его модификаторы и как они могут накосячить. Да, я не знаю точно, зачем конкретно нужен ремеш, но мне не удавалось использовать его для исправления сетки. Он может подойти для создания равномерной сетки для/после скульптинга и может редуцировать количество граней, но результат не оправдывает моих ожиданий...
Ещё раз, CSG в Godot позволяет тебе быстро набросать неплохо выглядящую лоупольку, которая в 90% случаев не имеет слишком заметных артефактов (в основном это дырки). Но если ты её экспортируешь, желая немного поправить во внешнем редакторе и использовать дальше, то ты обнаруживаешь хаос, месиво из треугольников, которые только со стороны выглядят неплохо (если не смотреть на сетку), а редактировать это вручную во внешнем редакторе - Б О Л Ь . Повторюсь, проще переделать вручную в том же Blender, чем пытаться пофиксить косяки генератора.
Я пробовал и я знаю, что говорю. Мне не нужно гуглить какие-то видео.
>Да. Загуглил, запостил и пошёл смотреть.
А я в Blender сижу как минимум с 2015 года, если не раньше. И прекрасно знаю про его модификаторы и как они могут накосячить. Да, я не знаю точно, зачем конкретно нужен ремеш, но мне не удавалось использовать его для исправления сетки. Он может подойти для создания равномерной сетки для/после скульптинга и может редуцировать количество граней, но результат не оправдывает моих ожиданий...
Ещё раз, CSG в Godot позволяет тебе быстро набросать неплохо выглядящую лоупольку, которая в 90% случаев не имеет слишком заметных артефактов (в основном это дырки). Но если ты её экспортируешь, желая немного поправить во внешнем редакторе и использовать дальше, то ты обнаруживаешь хаос, месиво из треугольников, которые только со стороны выглядят неплохо (если не смотреть на сетку), а редактировать это вручную во внешнем редакторе - Б О Л Ь . Повторюсь, проще переделать вручную в том же Blender, чем пытаться пофиксить косяки генератора.
Я пробовал и я знаю, что говорю. Мне не нужно гуглить какие-то видео.
>>72168
В итоге, какой вариант ты бы сам предпочел для 3д игры? ECS, стейты или просто if Input.is_pressed в скрипте персонажа?
В итоге, какой вариант ты бы сам предпочел для 3д игры? ECS, стейты или просто if Input.is_pressed в скрипте персонажа?
>>72177
Например, разработчики движка. Они же делают как-то все эти настройки для, например, лодов или навмешей.
Ну а как в гта или хотя бы лада рейсинг запечено? Очевидно у агента есть что-то вроде радиуса видимости и макс скорости. Но это старые игры, а сейчас большую часть этого можно автоматизировать.
Стриминг не подразумевает телепорты, вот там как раз и рисуются экраны загрузки. Хотя в гта 5, там, кажется, был зум камеры до вида на город с низкими лодами, и потом зум в новую точку.
Ну, тут в движке может быть предусмотрено несколько апи, либо для того чтобы за персонажей отвечал уже разраб игры, либо чтобы система стриминга сохраняла какую-то низко лодовую карту. В геншине я точно видел как босс вдалеке ходит сквозь меши, значит, у него есть плоскость для всей локации, чтобы не провалился.
А ты знаешь? Или к чему ты это сказал?
Не уверен, я вот считаю что рукописная проверка простых коллизий работала бы лучше и надежнее, чем все эти физ капсулы которые норовят где-то застрять в углах или подскочить на стыках.
То есть имхо система триггеров и коллайдеров была бы лучше чем честная физика.
В прямом. Внутри движка это может быть намного оптимальнее, чем просто пользовательские объекты которые загружаются и удаляются. Какие нибудь пулы, батчинги, виртуальные текстуры.
>А кто, я?
Например, разработчики движка. Они же делают как-то все эти настройки для, например, лодов или навмешей.
>Как ты предлагаешь "запечь" поведение игрока, который может сначала захотеть пойти туда, а потом совершено внезапно в противоположном направлении
Ну а как в гта или хотя бы лада рейсинг запечено? Очевидно у агента есть что-то вроде радиуса видимости и макс скорости. Но это старые игры, а сейчас большую часть этого можно автоматизировать.
>метод teleport
Стриминг не подразумевает телепорты, вот там как раз и рисуются экраны загрузки. Хотя в гта 5, там, кажется, был зум камеры до вида на город с низкими лодами, и потом зум в новую точку.
>вычислить положение и состояние ИИ-персонажей?
Ну, тут в движке может быть предусмотрено несколько апи, либо для того чтобы за персонажей отвечал уже разраб игры, либо чтобы система стриминга сохраняла какую-то низко лодовую карту. В геншине я точно видел как босс вдалеке ходит сквозь меши, значит, у него есть плоскость для всей локации, чтобы не провалился.
>Ты же не знаешь, как они внутри устроены...
А ты знаешь? Или к чему ты это сказал?
> Простая проверка коллизий
Не уверен, я вот считаю что рукописная проверка простых коллизий работала бы лучше и надежнее, чем все эти физ капсулы которые норовят где-то застрять в углах или подскочить на стыках.
То есть имхо система триггеров и коллайдеров была бы лучше чем честная физика.
>В каком смысле?
В прямом. Внутри движка это может быть намного оптимальнее, чем просто пользовательские объекты которые загружаются и удаляются. Какие нибудь пулы, батчинги, виртуальные текстуры.
>>72171
Ладно, в чём-то ты прав. Я провёл небольшой тест, и выяснил, что при прочих равных 15000 Node дереве сцены, у которых постоянно работает какой-то код в _process(), работают на 5 мс быстрее, чем цикл(ы) for в GDScript для перебора списка компонентов Resource и ручного запуска process() в них: 20 мс против 25 мс, в кадрах в секунду получается 50 против 40. Код в process() в обоих случаях одинаковый, он считает время и вызывает randi(). Пробовал разделять компоненты по "юнитам", по 100 и по 10 компонентов на каждый, ощутимой разницы нет. Однако, при использовании дерева сцены наблюдаются сильные просадки производительности при добавлении и удалении большого числа нод, тогда как в случае с массивом Resource и их перебором циклом for добавление и удаление практически не влияет на производительность (независимо от того, простой это список компонентов или куча юнитов с компонентами). Учитывая то, что я делал это на GDScript в версии Godot 3.5, можно предположить, что в Godot 4.0 результаты могут быть получше, а на C# или C++ результаты должны быть намного лучше.
Вывод из всего этого: если тебе нужно добавить 15000 сущностей одной пачкой и больше ты их трогать не будешь, то лучше сделать это через дерево сцены, т.к. тогда будет постоянный плюс к производительности, но если тебе нужно регулярно добавлять и удалять сущности в больших объёмах, то лучше не трогать дерево сцены, т.к. дерево сцены вызывает задержки до 0 фпс если ты слишком часто и много чего-то добавляешь и удаляешь, потому что небольшая стабильная просадка лучше, чем периодические провалы в производительности.
Не забывай о том, что bool переключить намного проще, чем вставлять и вынимать ноды в дереве сцены. Я проверил, массивные операции с нодами в дереве значительно сильнее бьют по производительности, чем любой другой код. У тебя может быть задержка больше 100 мс только из-за того, что у тебя 100 юнитов решили одновременно присесть, вставив в дерево сцены 100 нод "crouching_state" или что ты там хочешь вставлять. Т.е. не забывай о том, что кроме обхода дерева есть ещё добавление и удаление нод. Мне кажется, Godot оптимизирован на статичное дерево, а не на постоянные передвижения нод туда-сюда.
Зачем? Выкинь сцену человечка и загрузи сцену птицы или рыбы, в которых человечек превратился. Это будет легче поддерживать, чем если у тебя в нескольких местах разбросано переключение визуала и отдельно переключение способностей, строго зависящих от визуала.
>без конкретных измерений это пустые слова
Ладно, в чём-то ты прав. Я провёл небольшой тест, и выяснил, что при прочих равных 15000 Node дереве сцены, у которых постоянно работает какой-то код в _process(), работают на 5 мс быстрее, чем цикл(ы) for в GDScript для перебора списка компонентов Resource и ручного запуска process() в них: 20 мс против 25 мс, в кадрах в секунду получается 50 против 40. Код в process() в обоих случаях одинаковый, он считает время и вызывает randi(). Пробовал разделять компоненты по "юнитам", по 100 и по 10 компонентов на каждый, ощутимой разницы нет. Однако, при использовании дерева сцены наблюдаются сильные просадки производительности при добавлении и удалении большого числа нод, тогда как в случае с массивом Resource и их перебором циклом for добавление и удаление практически не влияет на производительность (независимо от того, простой это список компонентов или куча юнитов с компонентами). Учитывая то, что я делал это на GDScript в версии Godot 3.5, можно предположить, что в Godot 4.0 результаты могут быть получше, а на C# или C++ результаты должны быть намного лучше.
Вывод из всего этого: если тебе нужно добавить 15000 сущностей одной пачкой и больше ты их трогать не будешь, то лучше сделать это через дерево сцены, т.к. тогда будет постоянный плюс к производительности, но если тебе нужно регулярно добавлять и удалять сущности в больших объёмах, то лучше не трогать дерево сцены, т.к. дерево сцены вызывает задержки до 0 фпс если ты слишком часто и много чего-то добавляешь и удаляешь, потому что небольшая стабильная просадка лучше, чем периодические провалы в производительности.
>Не факт что проверки в гдскрипте условий будут быстрее, чем обход нод внутри движка
Не забывай о том, что bool переключить намного проще, чем вставлять и вынимать ноды в дереве сцены. Я проверил, массивные операции с нодами в дереве значительно сильнее бьют по производительности, чем любой другой код. У тебя может быть задержка больше 100 мс только из-за того, что у тебя 100 юнитов решили одновременно присесть, вставив в дерево сцены 100 нод "crouching_state" или что ты там хочешь вставлять. Т.е. не забывай о том, что кроме обхода дерева есть ещё добавление и удаление нод. Мне кажется, Godot оптимизирован на статичное дерево, а не на постоянные передвижения нод туда-сюда.
>Ничего не мешает менять визуал в одном месте, а способности раздавать в стиле ECS.
Зачем? Выкинь сцену человечка и загрузи сцену птицы или рыбы, в которых человечек превратился. Это будет легче поддерживать, чем если у тебя в нескольких местах разбросано переключение визуала и отдельно переключение способностей, строго зависящих от визуала.
>>72171
Ладно, в чём-то ты прав. Я провёл небольшой тест, и выяснил, что при прочих равных 15000 Node дереве сцены, у которых постоянно работает какой-то код в _process(), работают на 5 мс быстрее, чем цикл(ы) for в GDScript для перебора списка компонентов Resource и ручного запуска process() в них: 20 мс против 25 мс, в кадрах в секунду получается 50 против 40. Код в process() в обоих случаях одинаковый, он считает время и вызывает randi(). Пробовал разделять компоненты по "юнитам", по 100 и по 10 компонентов на каждый, ощутимой разницы нет. Однако, при использовании дерева сцены наблюдаются сильные просадки производительности при добавлении и удалении большого числа нод, тогда как в случае с массивом Resource и их перебором циклом for добавление и удаление практически не влияет на производительность (независимо от того, простой это список компонентов или куча юнитов с компонентами). Учитывая то, что я делал это на GDScript в версии Godot 3.5, можно предположить, что в Godot 4.0 результаты могут быть получше, а на C# или C++ результаты должны быть намного лучше.
Вывод из всего этого: если тебе нужно добавить 15000 сущностей одной пачкой и больше ты их трогать не будешь, то лучше сделать это через дерево сцены, т.к. тогда будет постоянный плюс к производительности, но если тебе нужно регулярно добавлять и удалять сущности в больших объёмах, то лучше не трогать дерево сцены, т.к. дерево сцены вызывает задержки до 0 фпс если ты слишком часто и много чего-то добавляешь и удаляешь, потому что небольшая стабильная просадка лучше, чем периодические провалы в производительности.
Не забывай о том, что bool переключить намного проще, чем вставлять и вынимать ноды в дереве сцены. Я проверил, массивные операции с нодами в дереве значительно сильнее бьют по производительности, чем любой другой код. У тебя может быть задержка больше 100 мс только из-за того, что у тебя 100 юнитов решили одновременно присесть, вставив в дерево сцены 100 нод "crouching_state" или что ты там хочешь вставлять. Т.е. не забывай о том, что кроме обхода дерева есть ещё добавление и удаление нод. Мне кажется, Godot оптимизирован на статичное дерево, а не на постоянные передвижения нод туда-сюда.
Зачем? Выкинь сцену человечка и загрузи сцену птицы или рыбы, в которых человечек превратился. Это будет легче поддерживать, чем если у тебя в нескольких местах разбросано переключение визуала и отдельно переключение способностей, строго зависящих от визуала.
>без конкретных измерений это пустые слова
Ладно, в чём-то ты прав. Я провёл небольшой тест, и выяснил, что при прочих равных 15000 Node дереве сцены, у которых постоянно работает какой-то код в _process(), работают на 5 мс быстрее, чем цикл(ы) for в GDScript для перебора списка компонентов Resource и ручного запуска process() в них: 20 мс против 25 мс, в кадрах в секунду получается 50 против 40. Код в process() в обоих случаях одинаковый, он считает время и вызывает randi(). Пробовал разделять компоненты по "юнитам", по 100 и по 10 компонентов на каждый, ощутимой разницы нет. Однако, при использовании дерева сцены наблюдаются сильные просадки производительности при добавлении и удалении большого числа нод, тогда как в случае с массивом Resource и их перебором циклом for добавление и удаление практически не влияет на производительность (независимо от того, простой это список компонентов или куча юнитов с компонентами). Учитывая то, что я делал это на GDScript в версии Godot 3.5, можно предположить, что в Godot 4.0 результаты могут быть получше, а на C# или C++ результаты должны быть намного лучше.
Вывод из всего этого: если тебе нужно добавить 15000 сущностей одной пачкой и больше ты их трогать не будешь, то лучше сделать это через дерево сцены, т.к. тогда будет постоянный плюс к производительности, но если тебе нужно регулярно добавлять и удалять сущности в больших объёмах, то лучше не трогать дерево сцены, т.к. дерево сцены вызывает задержки до 0 фпс если ты слишком часто и много чего-то добавляешь и удаляешь, потому что небольшая стабильная просадка лучше, чем периодические провалы в производительности.
>Не факт что проверки в гдскрипте условий будут быстрее, чем обход нод внутри движка
Не забывай о том, что bool переключить намного проще, чем вставлять и вынимать ноды в дереве сцены. Я проверил, массивные операции с нодами в дереве значительно сильнее бьют по производительности, чем любой другой код. У тебя может быть задержка больше 100 мс только из-за того, что у тебя 100 юнитов решили одновременно присесть, вставив в дерево сцены 100 нод "crouching_state" или что ты там хочешь вставлять. Т.е. не забывай о том, что кроме обхода дерева есть ещё добавление и удаление нод. Мне кажется, Godot оптимизирован на статичное дерево, а не на постоянные передвижения нод туда-сюда.
>Ничего не мешает менять визуал в одном месте, а способности раздавать в стиле ECS.
Зачем? Выкинь сцену человечка и загрузи сцену птицы или рыбы, в которых человечек превратился. Это будет легче поддерживать, чем если у тебя в нескольких местах разбросано переключение визуала и отдельно переключение способностей, строго зависящих от визуала.
>>72179
Какой 3D игры? Что в ней будет-то? Игры разные бывают. Настолько разные, что перечислять все варианты будет слишком долго. Если тебе нужен просто человечек, которым можно побегать по декорациям - тупо напиши скрипт и всё. Главное сделай прототип играбельный, а переделывать и оптимизировать будешь, когда будет что переделывать и оптимизировать...
Я несколько лет назад написал скрипт player.gd и практически никак его не трогал. Потом я ещё в других прототипах писал другие версии скрипта player.gd и опять же не трогал. В результате ни одну игру я за все эти годы так и не сделал, ни один прототип не довёл до играбельной стадии, поэтому мне никогда не потребовалось вводить ни конечные автоматы, ни какую-то компонентную систему, ни какие-либо оптимизации. Нет игры - нет и проблем, а с простым перемещением по неигровым сценам player.gd спокойно справляется. Вот сначала сделай что-то играбельное, а потом будешь думать, что тебе нужно переделать и оптимизировать...
>предпочел для 3д игры
Какой 3D игры? Что в ней будет-то? Игры разные бывают. Настолько разные, что перечислять все варианты будет слишком долго. Если тебе нужен просто человечек, которым можно побегать по декорациям - тупо напиши скрипт и всё. Главное сделай прототип играбельный, а переделывать и оптимизировать будешь, когда будет что переделывать и оптимизировать...
Я несколько лет назад написал скрипт player.gd и практически никак его не трогал. Потом я ещё в других прототипах писал другие версии скрипта player.gd и опять же не трогал. В результате ни одну игру я за все эти годы так и не сделал, ни один прототип не довёл до играбельной стадии, поэтому мне никогда не потребовалось вводить ни конечные автоматы, ни какую-то компонентную систему, ни какие-либо оптимизации. Нет игры - нет и проблем, а с простым перемещением по неигровым сценам player.gd спокойно справляется. Вот сначала сделай что-то играбельное, а потом будешь думать, что тебе нужно переделать и оптимизировать...
>>72190
Опережая >>71613, который обязательно напишет что-то вроде:
Я не сделал игру не потому, что не использовал конечные автоматы, а потому что не смог придумать интересный дизайн игры, который бы я хотел реализовать. Конечный автомат в контроллере персонажа может помочь реализовать сложное поведение с бегом, прыжками, перекатами, приседаниями, ползанием, плаванием, карабканьем, ездой, полётом и ещё бесконечным числом возможных состояний персонажа, но если у тебя нет игры, в которой ты можешь этим сложным персонажем всё это безобразие делать, то зачем тебе нужен этот персонаж? Не нужен он тебе. В интернете часто можно найти туториалы "как сделать контроллер персонажа на конечном автомате", и там этим персонажем бегают по серым кубам, серым холмам, серым лестницам и т.д. Это разве игра? Нет, это не игра. В то же время есть куча игр с примитивнейшим контроллером персонажа и в эти игры можно играть часами, в отличие от бегающего по серым кубам персонажа с огромным списком бесполезных возможностей. Поэтому сначала нужно сделать игру, а уже потом давать персонажу какие-то способности, если они вообще нужны конкретной игре (я видел столько игр без казалось бы естественного прыжка, не говоря уж о ещё более редких возможностях вроде приседания или, тем более, плавания, что я даже не представляю, зачем в туториалах описывают прыжок, если эта фича в играх практически нигде не нужна, кроме платформеров).
>ни один прототип не довёл до играбельной стадии
>не потребовалось вводить ни конечные автоматы
Опережая >>71613, который обязательно напишет что-то вроде:
>хехехе, а вот если бы использовал конечные автоматы, сделал бы игру...
Я не сделал игру не потому, что не использовал конечные автоматы, а потому что не смог придумать интересный дизайн игры, который бы я хотел реализовать. Конечный автомат в контроллере персонажа может помочь реализовать сложное поведение с бегом, прыжками, перекатами, приседаниями, ползанием, плаванием, карабканьем, ездой, полётом и ещё бесконечным числом возможных состояний персонажа, но если у тебя нет игры, в которой ты можешь этим сложным персонажем всё это безобразие делать, то зачем тебе нужен этот персонаж? Не нужен он тебе. В интернете часто можно найти туториалы "как сделать контроллер персонажа на конечном автомате", и там этим персонажем бегают по серым кубам, серым холмам, серым лестницам и т.д. Это разве игра? Нет, это не игра. В то же время есть куча игр с примитивнейшим контроллером персонажа и в эти игры можно играть часами, в отличие от бегающего по серым кубам персонажа с огромным списком бесполезных возможностей. Поэтому сначала нужно сделать игру, а уже потом давать персонажу какие-то способности, если они вообще нужны конкретной игре (я видел столько игр без казалось бы естественного прыжка, не говоря уж о ещё более редких возможностях вроде приседания или, тем более, плавания, что я даже не представляю, зачем в туториалах описывают прыжок, если эта фича в играх практически нигде не нужна, кроме платформеров).
>>72182
Они всё знают, но никуда не торопятся, ибо фича малопопулярная:
https://github.com/godotengine/godot-proposals/issues/1197
https://github.com/godotengine/godot-proposals/issues/2889
https://github.com/godotengine/godot-proposals/issues/3177
Из всего этого обещают только стримящиеся текстуры, отдельно от обычных...
Есть отдельные планы на систему ландшафта, но она, вроде, будет отдельно от движка.
Ничего там не "запечено". В GTA 3 и GTA VC есть загрузочные экраны, они появляются при переезде через мост - судя по всему, игра просто загружает целый город, а не отдельные его куски. В GTA SA не знаю как сделано (загрузочных экранов нет, по LODам трудно понять), а в GTA IV/V мир поделён на, вероятно, квадратные чанки по типу майнкрафта, только значительно больше по площади (в майне чанк 16x16 метров, в GTA V чисто по ощущениям - один квартал с границами возле дорог, но это не точно). Может быть, в GTA чанки не всегда одинаковые, в смысле, там много пустых областей, которые можно было бы описать одним большим квадратом, но равномерная сетка удобнее для вычислений.
Игра проверяет, в каком ты чанке находишься (две/три математических операции с координатами), и подгружает ресурсы в окружающих чанках. Чанки, от которых игрок удалился, выгружаются из памяти. Если жёсткий диск не успевает загрузить чанк из-за слишком высокой скорости движения игрока, то ты будешь ходить в пустоте без текстур, окружённый людьми и машинами (с ними тоже много хитростей, например, машина игрока часто дублируется в городском трафике вокруг игрока - экономия памяти за счёт повторяющихся объектов), потом вокруг тебя появятся КУБЫ с мыльными текстурами (LODы), а потом уже загрузятся нормальные модели. Реализовать подобную систему ты легко можешь и на GDScript. Тем более что чанковая система тебе всё равно нужна, чтобы управлять мозгами персонажей, физикой объектов и другими процессами.
Нужна ли встроенная в движок чанковая система? Сомневаюсь. Там буквально пара операций для проверки, где в данный момент находится игрок (или камера). Дальше тебе остаётся раздать команды своим игровым объектам, чтобы они загрузили или выгрузили данные и всё. Что здесь автоматизировать со стороны движка?
Ты просто не пробовал писать эту "рукописную проверку". Я пробовал для 2D, и даже после гугления не смог исправить баг, когда персонаж-прямоугольник способен зацепиться за угол многоугольника и совершенно спокойно войти внутрь него. Для 3D уровень сложности формул даже представлять не хочу. Именно поэтому все универсальные игровые движки имеют готовую систему коллизий из коробки, как для 2D, так и для 3D. Симуляция физики уже строится поверх этой системы коллизий, но её использовать не обязательно.
>разработчики движка
Они всё знают, но никуда не торопятся, ибо фича малопопулярная:
https://github.com/godotengine/godot-proposals/issues/1197
https://github.com/godotengine/godot-proposals/issues/2889
https://github.com/godotengine/godot-proposals/issues/3177
Из всего этого обещают только стримящиеся текстуры, отдельно от обычных...
Есть отдельные планы на систему ландшафта, но она, вроде, будет отдельно от движка.
>Ну а как в гта или хотя бы лада рейсинг запечено?
Ничего там не "запечено". В GTA 3 и GTA VC есть загрузочные экраны, они появляются при переезде через мост - судя по всему, игра просто загружает целый город, а не отдельные его куски. В GTA SA не знаю как сделано (загрузочных экранов нет, по LODам трудно понять), а в GTA IV/V мир поделён на, вероятно, квадратные чанки по типу майнкрафта, только значительно больше по площади (в майне чанк 16x16 метров, в GTA V чисто по ощущениям - один квартал с границами возле дорог, но это не точно). Может быть, в GTA чанки не всегда одинаковые, в смысле, там много пустых областей, которые можно было бы описать одним большим квадратом, но равномерная сетка удобнее для вычислений.
Игра проверяет, в каком ты чанке находишься (две/три математических операции с координатами), и подгружает ресурсы в окружающих чанках. Чанки, от которых игрок удалился, выгружаются из памяти. Если жёсткий диск не успевает загрузить чанк из-за слишком высокой скорости движения игрока, то ты будешь ходить в пустоте без текстур, окружённый людьми и машинами (с ними тоже много хитростей, например, машина игрока часто дублируется в городском трафике вокруг игрока - экономия памяти за счёт повторяющихся объектов), потом вокруг тебя появятся КУБЫ с мыльными текстурами (LODы), а потом уже загрузятся нормальные модели. Реализовать подобную систему ты легко можешь и на GDScript. Тем более что чанковая система тебе всё равно нужна, чтобы управлять мозгами персонажей, физикой объектов и другими процессами.
Нужна ли встроенная в движок чанковая система? Сомневаюсь. Там буквально пара операций для проверки, где в данный момент находится игрок (или камера). Дальше тебе остаётся раздать команды своим игровым объектам, чтобы они загрузили или выгрузили данные и всё. Что здесь автоматизировать со стороны движка?
>рукописная проверка простых коллизий работала бы лучше и надежнее
Ты просто не пробовал писать эту "рукописную проверку". Я пробовал для 2D, и даже после гугления не смог исправить баг, когда персонаж-прямоугольник способен зацепиться за угол многоугольника и совершенно спокойно войти внутрь него. Для 3D уровень сложности формул даже представлять не хочу. Именно поэтому все универсальные игровые движки имеют готовую систему коллизий из коробки, как для 2D, так и для 3D. Симуляция физики уже строится поверх этой системы коллизий, но её использовать не обязательно.
>>72182
Они всё знают, но никуда не торопятся, ибо фича малопопулярная:
https://github.com/godotengine/godot-proposals/issues/1197
https://github.com/godotengine/godot-proposals/issues/2889
https://github.com/godotengine/godot-proposals/issues/3177
Из всего этого обещают только стримящиеся текстуры, отдельно от обычных...
Есть отдельные планы на систему ландшафта, но она, вроде, будет отдельно от движка.
Ничего там не "запечено". В GTA 3 и GTA VC есть загрузочные экраны, они появляются при переезде через мост - судя по всему, игра просто загружает целый город, а не отдельные его куски. В GTA SA не знаю как сделано (загрузочных экранов нет, по LODам трудно понять), а в GTA IV/V мир поделён на, вероятно, квадратные чанки по типу майнкрафта, только значительно больше по площади (в майне чанк 16x16 метров, в GTA V чисто по ощущениям - один квартал с границами возле дорог, но это не точно). Может быть, в GTA чанки не всегда одинаковые, в смысле, там много пустых областей, которые можно было бы описать одним большим квадратом, но равномерная сетка удобнее для вычислений.
Игра проверяет, в каком ты чанке находишься (две/три математических операции с координатами), и подгружает ресурсы в окружающих чанках. Чанки, от которых игрок удалился, выгружаются из памяти. Если жёсткий диск не успевает загрузить чанк из-за слишком высокой скорости движения игрока, то ты будешь ходить в пустоте без текстур, окружённый людьми и машинами (с ними тоже много хитростей, например, машина игрока часто дублируется в городском трафике вокруг игрока - экономия памяти за счёт повторяющихся объектов), потом вокруг тебя появятся КУБЫ с мыльными текстурами (LODы), а потом уже загрузятся нормальные модели. Реализовать подобную систему ты легко можешь и на GDScript. Тем более что чанковая система тебе всё равно нужна, чтобы управлять мозгами персонажей, физикой объектов и другими процессами.
Нужна ли встроенная в движок чанковая система? Сомневаюсь. Там буквально пара операций для проверки, где в данный момент находится игрок (или камера). Дальше тебе остаётся раздать команды своим игровым объектам, чтобы они загрузили или выгрузили данные и всё. Что здесь автоматизировать со стороны движка?
Ты просто не пробовал писать эту "рукописную проверку". Я пробовал для 2D, и даже после гугления не смог исправить баг, когда персонаж-прямоугольник способен зацепиться за угол многоугольника и совершенно спокойно войти внутрь него. Для 3D уровень сложности формул даже представлять не хочу. Именно поэтому все универсальные игровые движки имеют готовую систему коллизий из коробки, как для 2D, так и для 3D. Симуляция физики уже строится поверх этой системы коллизий, но её использовать не обязательно.
>разработчики движка
Они всё знают, но никуда не торопятся, ибо фича малопопулярная:
https://github.com/godotengine/godot-proposals/issues/1197
https://github.com/godotengine/godot-proposals/issues/2889
https://github.com/godotengine/godot-proposals/issues/3177
Из всего этого обещают только стримящиеся текстуры, отдельно от обычных...
Есть отдельные планы на систему ландшафта, но она, вроде, будет отдельно от движка.
>Ну а как в гта или хотя бы лада рейсинг запечено?
Ничего там не "запечено". В GTA 3 и GTA VC есть загрузочные экраны, они появляются при переезде через мост - судя по всему, игра просто загружает целый город, а не отдельные его куски. В GTA SA не знаю как сделано (загрузочных экранов нет, по LODам трудно понять), а в GTA IV/V мир поделён на, вероятно, квадратные чанки по типу майнкрафта, только значительно больше по площади (в майне чанк 16x16 метров, в GTA V чисто по ощущениям - один квартал с границами возле дорог, но это не точно). Может быть, в GTA чанки не всегда одинаковые, в смысле, там много пустых областей, которые можно было бы описать одним большим квадратом, но равномерная сетка удобнее для вычислений.
Игра проверяет, в каком ты чанке находишься (две/три математических операции с координатами), и подгружает ресурсы в окружающих чанках. Чанки, от которых игрок удалился, выгружаются из памяти. Если жёсткий диск не успевает загрузить чанк из-за слишком высокой скорости движения игрока, то ты будешь ходить в пустоте без текстур, окружённый людьми и машинами (с ними тоже много хитростей, например, машина игрока часто дублируется в городском трафике вокруг игрока - экономия памяти за счёт повторяющихся объектов), потом вокруг тебя появятся КУБЫ с мыльными текстурами (LODы), а потом уже загрузятся нормальные модели. Реализовать подобную систему ты легко можешь и на GDScript. Тем более что чанковая система тебе всё равно нужна, чтобы управлять мозгами персонажей, физикой объектов и другими процессами.
Нужна ли встроенная в движок чанковая система? Сомневаюсь. Там буквально пара операций для проверки, где в данный момент находится игрок (или камера). Дальше тебе остаётся раздать команды своим игровым объектам, чтобы они загрузили или выгрузили данные и всё. Что здесь автоматизировать со стороны движка?
>рукописная проверка простых коллизий работала бы лучше и надежнее
Ты просто не пробовал писать эту "рукописную проверку". Я пробовал для 2D, и даже после гугления не смог исправить баг, когда персонаж-прямоугольник способен зацепиться за угол многоугольника и совершенно спокойно войти внутрь него. Для 3D уровень сложности формул даже представлять не хочу. Именно поэтому все универсальные игровые движки имеют готовую систему коллизий из коробки, как для 2D, так и для 3D. Симуляция физики уже строится поверх этой системы коллизий, но её использовать не обязательно.
>>72182
Вот тебе главный инструмент:
Дальше всё просто, разберёшься сам.
>Ну а как в гта
>радиус видимости
Вот тебе главный инструмент:
>func position_to_chunk(pos: Vector3) -> Vector2:
>return Vector2(int(pos.x / chunk_size), int(pos.z / chunk_size))
Дальше всё просто, разберёшься сам.
>>72192
А вот это самая главная проблема, которая многих из нас объединяет. Мы приходим в гд кириллами с мыслью запилить свою игру мечты как скайримогэтэашечку с автоматической генерацией планет и космических кораблей. И мы по какой-то неведомой причине убеждены, что сможем это в одинчку запилить. Нужно только...
>не смог придумать интересный дизайн игры, который бы я хотел реализовать
А вот это самая главная проблема, которая многих из нас объединяет. Мы приходим в гд кириллами с мыслью запилить свою игру мечты как скайримогэтэашечку с автоматической генерацией планет и космических кораблей. И мы по какой-то неведомой причине убеждены, что сможем это в одинчку запилить. Нужно только...
Гуру, снова взываю к вам!
Я пытаюсь задать трансформацию как на первой картинке, но при использовании этой трансформации, результата нет, то есть по какой-то причине такой подход не срабатывает
Если же использовать как на второй, то всё работает как надо, но нету конструктора в 3.5 с масштабированием, в 4 есть, я уже видел.
Вобщем мне нужно масштабировать объект
Я пытаюсь задать трансформацию как на первой картинке, но при использовании этой трансформации, результата нет, то есть по какой-то причине такой подход не срабатывает
Если же использовать как на второй, то всё работает как надо, но нету конструктора в 3.5 с масштабированием, в 4 есть, я уже видел.
Вобщем мне нужно масштабировать объект
спасибо за тред!!!
71 Кб, 804x128>>72238
Отбой, разобрался
На будущее решение на картинке
Сначала задаём смещение, потом умножаем на вращение и потом на масштаб
Отбой, разобрался
На будущее решение на картинке
Сначала задаём смещение, потом умножаем на вращение и потом на масштаб
>>72238
Потому что есть функция rotate(), она меняет трансформ, а есть функция rotated(), она возвращает новый объект, но ты ничему не присваиваешь и просто выкидываешь результат.
В следующем посте ты случайно используешь *=, который состоит из умножения И присваивания.
Потому что есть функция rotate(), она меняет трансформ, а есть функция rotated(), она возвращает новый объект, но ты ничему не присваиваешь и просто выкидываешь результат.
В следующем посте ты случайно используешь *=, который состоит из умножения И присваивания.
81 Кб, 746x597>>72246
Ах если бы всё было так просто...
Без этого получить нужные мне преобразования разом не получается
Ах если бы всё было так просто...
> В следующем посте ты случайно используешь *=, который состоит из умножения И присваивания
Без этого получить нужные мне преобразования разом не получается
>>72254
Пробовал, простое присваивание результата не даёт, ты просто получаешь новый trasform, но с поворотом и так с каждым результатом
Я удивлён, что они добавили конструктор с масштабированием только в четвёрке, потому такая возня
Пробовал, простое присваивание результата не даёт, ты просто получаешь новый trasform, но с поворотом и так с каждым результатом
Я удивлён, что они добавили конструктор с масштабированием только в четвёрке, потому такая возня
>>72255
Ещё и порядок важен
Ещё и порядок важен
>>72255
Ну, да.
tr = tr.rotated(...)
tr = tr.scaled(..) #соответственно повернутый и масштабированный
> но с поворотом и так с каждым результатом
Ну, да.
tr = tr.rotated(...)
tr = tr.scaled(..) #соответственно повернутый и масштабированный
>>72246
Двачую. А ещё об этом прямо пишется в дебаггере и внимательный анон бы всё прочёл и сделал выводы.
> она возвращает новый объект, но ты ничему не присваиваешь и просто выкидываешь результат
Двачую. А ещё об этом прямо пишется в дебаггере и внимательный анон бы всё прочёл и сделал выводы.
Я вчера прочёл интересное, оказывается на gdScript методы вызываются быстрее чем C#, недостаток в скорости у gdScript при работе с массивами похоже только
Получается, что лучший союз это gdScript + C++ самописные модули небольшие под конкретные задачи
Думаю, что визуальное программирование нодами всё же уступает питоноподобному языку и самописным модулям, мне при использовании С++ очень не хватало именно быстрого создания окна и прочих мелочей типа менюшек.
Правда попытки собрать со своей библиотекой годо не взлетели, да и не нужно особо пока
>>72258
Короче понятно
>>72350
Вот тут подробнее, я обнаружил всё это дело просто выводя при помощи print результат трансформации
Получается, что лучший союз это gdScript + C++ самописные модули небольшие под конкретные задачи
Думаю, что визуальное программирование нодами всё же уступает питоноподобному языку и самописным модулям, мне при использовании С++ очень не хватало именно быстрого создания окна и прочих мелочей типа менюшек.
Правда попытки собрать со своей библиотекой годо не взлетели, да и не нужно особо пока
>>72258
Короче понятно
>>72350
> А ещё об этом прямо пишется в дебаггере
Вот тут подробнее, я обнаружил всё это дело просто выводя при помощи print результат трансформации
>>72353
Пришел еще года 2 назад к такому же выводу.
C# в любом случае еще и билд раздувает, на мобилке на 1 сек. точно дольше загрузка будет.
Про C# веб тоже подозреваю не все гладко
>лучший союз это gdScript + C++ самописные модули
Пришел еще года 2 назад к такому же выводу.
C# в любом случае еще и билд раздувает, на мобилке на 1 сек. точно дольше загрузка будет.
Про C# веб тоже подозреваю не все гладко
>>72353
Если ты на четверке, то не выводится (странно). На трёшке выводится предупреждение (жёлтое), типа "функция возвращает значение, но вы никуда не присвоили".
> Вот тут подробнее
Если ты на четверке, то не выводится (странно). На трёшке выводится предупреждение (жёлтое), типа "функция возвращает значение, но вы никуда не присвоили".
>>72229
Проблема не в том, что в одиночку пилить сложно. Основная проблема в том, что фантазии кирилла на практике зачастую оказываются совсем не такими интересными, как ему казалось, пока он фантазировал. Фантазии оказываются бесполезными и это демотивирует намного сильнее, чем любые другие сложности. Ты можешь в одиночку сделать свою ГТА, но когда ты понимаешь, что твои идеи не имеют практического смысла, у тебя опускаются руки и ты бросаешь работу. Если бы работа была намного проще, у нас было бы намного больше совершенно бесполезных игр, в которые никто не играл бы, процент действительно достойных игр был бы намного меньше, чем сейчас, меньше, чем после наводнения рынка индюшатиной.
Вот, скажем, "домики на курьих ножках набегают" или "можно грабить корованы" - это интересные идеи? Может быть, можно посмотреть и посмеяться пару минут. Но в конечном итоге это всего лишь смешные декорации, с которыми быстро надоест играть. Их совсем не сложно реализовать, не нужно быть профессионалом или иметь большую команду специалистов. Тогда почему у нас нет набегающих домиков и корованов в каждой второй игре? Потому что они просто никому не нужны. И когда кирилл осознаёт это, он бросает работу. Даже если бы у кирилла была волшебная кнопка "сделать игру", её не было бы никакого смысла нажимать...
>Мы приходим в гд кириллами с мыслью запилить свою игру мечты как скайримогэтэашечку с автоматической генерацией планет и космических кораблей. И мы по какой-то неведомой причине убеждены, что сможем это в одинчку запилить.
Проблема не в том, что в одиночку пилить сложно. Основная проблема в том, что фантазии кирилла на практике зачастую оказываются совсем не такими интересными, как ему казалось, пока он фантазировал. Фантазии оказываются бесполезными и это демотивирует намного сильнее, чем любые другие сложности. Ты можешь в одиночку сделать свою ГТА, но когда ты понимаешь, что твои идеи не имеют практического смысла, у тебя опускаются руки и ты бросаешь работу. Если бы работа была намного проще, у нас было бы намного больше совершенно бесполезных игр, в которые никто не играл бы, процент действительно достойных игр был бы намного меньше, чем сейчас, меньше, чем после наводнения рынка индюшатиной.
Вот, скажем, "домики на курьих ножках набегают" или "можно грабить корованы" - это интересные идеи? Может быть, можно посмотреть и посмеяться пару минут. Но в конечном итоге это всего лишь смешные декорации, с которыми быстро надоест играть. Их совсем не сложно реализовать, не нужно быть профессионалом или иметь большую команду специалистов. Тогда почему у нас нет набегающих домиков и корованов в каждой второй игре? Потому что они просто никому не нужны. И когда кирилл осознаёт это, он бросает работу. Даже если бы у кирилла была волшебная кнопка "сделать игру", её не было бы никакого смысла нажимать...
>>72353 >>72369
Я уверен, что официальная поддержка C# в Godot - это исключительно маркетинговый ход. Ни для кого не секрет, что инди-сцена взлетела в последние 10-15 лет в основном за счёт агрессивного маркетинга Unity, которая давно поддерживает только C#, да и сам C# крайне агрессивно впаривается маркетологами Microsoft с целью подмять под себя рынок приложений, добавив проблем другим ОС. В результате мы имеем огромное количество скриптопись, которые ничего кроме C# и/или Unity в своей жизни не видели и, как и все мы, страдают синдромом утёнка. Очевидно, что для приманивания их на альтернативный движок этот движок должен быть подобен Unity и иметь поддержку C#, хотя бы чтобы подняться повыше в поисковых запросах. Конечно, есть и другие преимущества от поддержки C#, например, более простое использование сторонних библиотек, подключаемых к твоему коду на C#, а не к самому движку, но по большому счёту это всё чистой воды маркетинговый ход. Хуан - гений, смог не только закодить свой велосипед, но и "продать" его куче людей. Большинство других движкопись даже если могут сделать хороший движок, проваливаются в плане маркетинга, потому что просто "хороший движок" никому не нужен (Фалько, если ты это читаешь, мотай на ус).
>>72398 >>72402
Проблема данного предупреждения в том, что в API движка довольно много функций, возвращающих код ошибки или что-то вроде него, что крайне редко имеет смысл хранить и обрабатывать. Если твой код загружает файл из "res://", тебе бесполезно обрабатывать коды ошибок, т.к. ты точно знаешь, что файл будет на месте и будет читаемым; если ты создал экземпляр объекта и коннектишь его сигналы, то тебе опять же бесполезны коды ошибок, т.к. ты точно знаешь, что это нужный тебе объект и у него точно есть все необходимые сигналы, и они точно ещё не подключены. Обмазывать код лишними проверками вредно и скучно, отловить такие ошибки несложно и куча предупреждений об игнорируемых возвращаемых кодах ошибок тебе просто не нужны. Если не отключать предупреждение, приходится писать в таком стиле:
Лишь бы движок не выдавал 100500 предупреждений о том, что у тебя там int никуда не сохраняется. Да, есть возможность вставить комментарий, который локально подавляет предупреждение, но он занимает целую строчку и раздражает своей избыточностью больше, чем "_e = ...", которое хоть какой-то смысл несёт (легко вставить строчку проверки "if _e: printerr(_e)" и узнать код ошибки, в отличие от дурацкого подавляющего комментария).
Наверное, они заметили жалобы об этих бесполезных в большинстве случаев предупреждениях и поэтому сделали их выключенными по умолчанию. Кому действительно нужно - сам включить может.
Я уверен, что официальная поддержка C# в Godot - это исключительно маркетинговый ход. Ни для кого не секрет, что инди-сцена взлетела в последние 10-15 лет в основном за счёт агрессивного маркетинга Unity, которая давно поддерживает только C#, да и сам C# крайне агрессивно впаривается маркетологами Microsoft с целью подмять под себя рынок приложений, добавив проблем другим ОС. В результате мы имеем огромное количество скриптопись, которые ничего кроме C# и/или Unity в своей жизни не видели и, как и все мы, страдают синдромом утёнка. Очевидно, что для приманивания их на альтернативный движок этот движок должен быть подобен Unity и иметь поддержку C#, хотя бы чтобы подняться повыше в поисковых запросах. Конечно, есть и другие преимущества от поддержки C#, например, более простое использование сторонних библиотек, подключаемых к твоему коду на C#, а не к самому движку, но по большому счёту это всё чистой воды маркетинговый ход. Хуан - гений, смог не только закодить свой велосипед, но и "продать" его куче людей. Большинство других движкопись даже если могут сделать хороший движок, проваливаются в плане маркетинга, потому что просто "хороший движок" никому не нужен (Фалько, если ты это читаешь, мотай на ус).
>>72398 >>72402
Проблема данного предупреждения в том, что в API движка довольно много функций, возвращающих код ошибки или что-то вроде него, что крайне редко имеет смысл хранить и обрабатывать. Если твой код загружает файл из "res://", тебе бесполезно обрабатывать коды ошибок, т.к. ты точно знаешь, что файл будет на месте и будет читаемым; если ты создал экземпляр объекта и коннектишь его сигналы, то тебе опять же бесполезны коды ошибок, т.к. ты точно знаешь, что это нужный тебе объект и у него точно есть все необходимые сигналы, и они точно ещё не подключены. Обмазывать код лишними проверками вредно и скучно, отловить такие ошибки несложно и куча предупреждений об игнорируемых возвращаемых кодах ошибок тебе просто не нужны. Если не отключать предупреждение, приходится писать в таком стиле:
>var _e := connect(...)
>_e = connect(...)
>_e = connect(...)
Лишь бы движок не выдавал 100500 предупреждений о том, что у тебя там int никуда не сохраняется. Да, есть возможность вставить комментарий, который локально подавляет предупреждение, но он занимает целую строчку и раздражает своей избыточностью больше, чем "_e = ...", которое хоть какой-то смысл несёт (легко вставить строчку проверки "if _e: printerr(_e)" и узнать код ошибки, в отличие от дурацкого подавляющего комментария).
Наверное, они заметили жалобы об этих бесполезных в большинстве случаев предупреждениях и поэтому сделали их выключенными по умолчанию. Кому действительно нужно - сам включить может.
>>72353 >>72369
Я уверен, что официальная поддержка C# в Godot - это исключительно маркетинговый ход. Ни для кого не секрет, что инди-сцена взлетела в последние 10-15 лет в основном за счёт агрессивного маркетинга Unity, которая давно поддерживает только C#, да и сам C# крайне агрессивно впаривается маркетологами Microsoft с целью подмять под себя рынок приложений, добавив проблем другим ОС. В результате мы имеем огромное количество скриптопись, которые ничего кроме C# и/или Unity в своей жизни не видели и, как и все мы, страдают синдромом утёнка. Очевидно, что для приманивания их на альтернативный движок этот движок должен быть подобен Unity и иметь поддержку C#, хотя бы чтобы подняться повыше в поисковых запросах. Конечно, есть и другие преимущества от поддержки C#, например, более простое использование сторонних библиотек, подключаемых к твоему коду на C#, а не к самому движку, но по большому счёту это всё чистой воды маркетинговый ход. Хуан - гений, смог не только закодить свой велосипед, но и "продать" его куче людей. Большинство других движкопись даже если могут сделать хороший движок, проваливаются в плане маркетинга, потому что просто "хороший движок" никому не нужен (Фалько, если ты это читаешь, мотай на ус).
>>72398 >>72402
Проблема данного предупреждения в том, что в API движка довольно много функций, возвращающих код ошибки или что-то вроде него, что крайне редко имеет смысл хранить и обрабатывать. Если твой код загружает файл из "res://", тебе бесполезно обрабатывать коды ошибок, т.к. ты точно знаешь, что файл будет на месте и будет читаемым; если ты создал экземпляр объекта и коннектишь его сигналы, то тебе опять же бесполезны коды ошибок, т.к. ты точно знаешь, что это нужный тебе объект и у него точно есть все необходимые сигналы, и они точно ещё не подключены. Обмазывать код лишними проверками вредно и скучно, отловить такие ошибки несложно и куча предупреждений об игнорируемых возвращаемых кодах ошибок тебе просто не нужны. Если не отключать предупреждение, приходится писать в таком стиле:
Лишь бы движок не выдавал 100500 предупреждений о том, что у тебя там int никуда не сохраняется. Да, есть возможность вставить комментарий, который локально подавляет предупреждение, но он занимает целую строчку и раздражает своей избыточностью больше, чем "_e = ...", которое хоть какой-то смысл несёт (легко вставить строчку проверки "if _e: printerr(_e)" и узнать код ошибки, в отличие от дурацкого подавляющего комментария).
Наверное, они заметили жалобы об этих бесполезных в большинстве случаев предупреждениях и поэтому сделали их выключенными по умолчанию. Кому действительно нужно - сам включить может.
Я уверен, что официальная поддержка C# в Godot - это исключительно маркетинговый ход. Ни для кого не секрет, что инди-сцена взлетела в последние 10-15 лет в основном за счёт агрессивного маркетинга Unity, которая давно поддерживает только C#, да и сам C# крайне агрессивно впаривается маркетологами Microsoft с целью подмять под себя рынок приложений, добавив проблем другим ОС. В результате мы имеем огромное количество скриптопись, которые ничего кроме C# и/или Unity в своей жизни не видели и, как и все мы, страдают синдромом утёнка. Очевидно, что для приманивания их на альтернативный движок этот движок должен быть подобен Unity и иметь поддержку C#, хотя бы чтобы подняться повыше в поисковых запросах. Конечно, есть и другие преимущества от поддержки C#, например, более простое использование сторонних библиотек, подключаемых к твоему коду на C#, а не к самому движку, но по большому счёту это всё чистой воды маркетинговый ход. Хуан - гений, смог не только закодить свой велосипед, но и "продать" его куче людей. Большинство других движкопись даже если могут сделать хороший движок, проваливаются в плане маркетинга, потому что просто "хороший движок" никому не нужен (Фалько, если ты это читаешь, мотай на ус).
>>72398 >>72402
Проблема данного предупреждения в том, что в API движка довольно много функций, возвращающих код ошибки или что-то вроде него, что крайне редко имеет смысл хранить и обрабатывать. Если твой код загружает файл из "res://", тебе бесполезно обрабатывать коды ошибок, т.к. ты точно знаешь, что файл будет на месте и будет читаемым; если ты создал экземпляр объекта и коннектишь его сигналы, то тебе опять же бесполезны коды ошибок, т.к. ты точно знаешь, что это нужный тебе объект и у него точно есть все необходимые сигналы, и они точно ещё не подключены. Обмазывать код лишними проверками вредно и скучно, отловить такие ошибки несложно и куча предупреждений об игнорируемых возвращаемых кодах ошибок тебе просто не нужны. Если не отключать предупреждение, приходится писать в таком стиле:
>var _e := connect(...)
>_e = connect(...)
>_e = connect(...)
Лишь бы движок не выдавал 100500 предупреждений о том, что у тебя там int никуда не сохраняется. Да, есть возможность вставить комментарий, который локально подавляет предупреждение, но он занимает целую строчку и раздражает своей избыточностью больше, чем "_e = ...", которое хоть какой-то смысл несёт (легко вставить строчку проверки "if _e: printerr(_e)" и узнать код ошибки, в отличие от дурацкого подавляющего комментария).
Наверное, они заметили жалобы об этих бесполезных в большинстве случаев предупреждениях и поэтому сделали их выключенными по умолчанию. Кому действительно нужно - сам включить может.
>>72424
Еще меньше? Игор итак нет годных
>процент действительно достойных игр был бы намного меньше, чем сейчас
Еще меньше? Игор итак нет годных
>>72426
Тебе определение слова "процент" процитировать?
Если у тебя 100 игр и только 5 из них имеет смысл играть, а остальное - бездушные клоны клонов или декорации без геймплея, то у тебя 5% достойных игр. Если у тебя 100000 игр и только 10 из них имеет смысл играть, то у тебя 0.01% достойных игр. Чем проще становится делать игры, тем больше общее число игр и при этом меньше процент достойных игр, ведь чаще всего делают клоны клонов или какую-то фигню ни о чём. Поэтому создание и раскрутка бесплатных игровых движков и открытие торговых площадок для инди в среднем уменьшило процент достойных игр, ведь теперь каждый может высрать никому не нужную фигню, не имея бюджета, людей и связей. Нет, конечно, достойные проекты тоже стало легче делать, но сделать фигню всегда проще.
Тебе определение слова "процент" процитировать?
>матем. одна сотая часть
>разг. то же, что доля, часть
Если у тебя 100 игр и только 5 из них имеет смысл играть, а остальное - бездушные клоны клонов или декорации без геймплея, то у тебя 5% достойных игр. Если у тебя 100000 игр и только 10 из них имеет смысл играть, то у тебя 0.01% достойных игр. Чем проще становится делать игры, тем больше общее число игр и при этом меньше процент достойных игр, ведь чаще всего делают клоны клонов или какую-то фигню ни о чём. Поэтому создание и раскрутка бесплатных игровых движков и открытие торговых площадок для инди в среднем уменьшило процент достойных игр, ведь теперь каждый может высрать никому не нужную фигню, не имея бюджета, людей и связей. Нет, конечно, достойные проекты тоже стало легче делать, но сделать фигню всегда проще.
>>72425
А потом игры падают молча на рабочий стол при моддинге, вызывая лютый хейт сообществ. Вредный совет. Осуждаю.
> Если твой код загружает файл из "res://", тебе бесполезно обрабатывать коды ошибок, т.к. ты точно знаешь, что файл будет на месте и будет читаемым; если ты создал экземпляр объекта и коннектишь его сигналы, то тебе опять же бесполезны коды ошибок, т.к. ты точно знаешь, что это нужный тебе объект и у него точно есть все необходимые сигналы, и они точно ещё не подключены.
> Обмазывать код лишними проверками вредно и скучно
А потом игры падают молча на рабочий стол при моддинге, вызывая лютый хейт сообществ. Вредный совет. Осуждаю.
>>72425
Нет никакого синдрома утенка, и а на остальные языки можно и не смотреть. C# - объективно лучший язык с мощнейшей стандартной библиотекой, пиздатейшим синтаксисом и возможностью на изичах писать аллокейшен-фри код.
>которые ничего кроме C# и/или Unity в своей жизни не видели
>страдают синдромом утёнка.
Нет никакого синдрома утенка, и а на остальные языки можно и не смотреть. C# - объективно лучший язык с мощнейшей стандартной библиотекой, пиздатейшим синтаксисом и возможностью на изичах писать аллокейшен-фри код.
>>72369
Там в дорожной карте языка полноценная компилируемость, т.е. скоро твое "раздутие" ограничится 500кб сборщика мусора.
>C# в любом случае еще и билд раздувает
Там в дорожной карте языка полноценная компилируемость, т.е. скоро твое "раздутие" ограничится 500кб сборщика мусора.
>>72556
Что, и вся стандартная либа в 500кб уложится? Строки, коллекции, ну ты понял.
Что, и вся стандартная либа в 500кб уложится? Строки, коллекции, ну ты понял.
>>72558
Стандартная либа искаропки будет в венде. Но даже если брать линукс. 40-80 мегов фреймворка - мелочь по сравнению с 40-80 ГИГАМИ контента.
Стандартная либа искаропки будет в венде. Но даже если брать линукс. 40-80 мегов фреймворка - мелочь по сравнению с 40-80 ГИГАМИ контента.
>>72588
Да? А, ну сорян. Вечно я ебашу ответы не вчитываясь в детали.
Да? А, ну сорян. Вечно я ебашу ответы не вчитываясь в детали.
>>72480
Моддинг не входит в твою ответственность, если ты не предоставляешь официальный Mod API. Если ты его предоставляешь, то это совершенно другая история и обмазывать проверками нужно будет другие места.
Пишешь гайд по моддингу, включающий в себя объяснения того, как запускать игру с открытым окном консоли или где искать логи с ошибками. Игра не обязана показывать игроку красивое окошко с сообщением об ошибке, более того, зачастую удобнее найти это сообщение в логах или консоли. Если же ошибка не критическая, то см. предыдущий абзац.
>падают при моддинге
Моддинг не входит в твою ответственность, если ты не предоставляешь официальный Mod API. Если ты его предоставляешь, то это совершенно другая история и обмазывать проверками нужно будет другие места.
>падают молча
>лютый хейт сообществ
Пишешь гайд по моддингу, включающий в себя объяснения того, как запускать игру с открытым окном консоли или где искать логи с ошибками. Игра не обязана показывать игроку красивое окошко с сообщением об ошибке, более того, зачастую удобнее найти это сообщение в логах или консоли. Если же ошибка не критическая, то см. предыдущий абзац.
>>72552
https://ru.wikipedia.org/wiki/Запечатление
Спешите видеть, утёнок защищает свою мамочку!
>>72558
ИМХО, нормальный компилируемый язык должен уметь брать из "либы" только то, что действительно нужно конкретной программе. Т.е. если ты используешь 1 функцию из 1000, в исполняемый файл войдёт только эта одна функция, а всё остальное будет срезано из-за того, что в твоём конкретном приложении к 999 функциям не происходит ни одного вызова. С данными немного сложнее, но если язык не позволяет обращаться к ним как-то иначе, чем по имени или индексу массива, то и тут можно оптимизировать, выбросив всё, до чего код программы явным образом не дотягивается. Также имеет смысл резать один жирный модуль из 1000 функций на 100 модулей по 10 функций в каждом, чтобы программист имел больше контроля над тем, что именно включать в его программу. Проблема в том, что это никому не нужно, всегда проще докупить жёстких дисков или купить очередной смартфон с 1 ТБ встроенной памяти, тем более что контент уже давно на порядки жирнее практически любой программы и поэтому ожирение программ становятся незаметным.
>Нет никакого синдрома утенка
https://ru.wikipedia.org/wiki/Запечатление
>C# - объективно лучший язык
Спешите видеть, утёнок защищает свою мамочку!
>>72558
>стандартная либа
ИМХО, нормальный компилируемый язык должен уметь брать из "либы" только то, что действительно нужно конкретной программе. Т.е. если ты используешь 1 функцию из 1000, в исполняемый файл войдёт только эта одна функция, а всё остальное будет срезано из-за того, что в твоём конкретном приложении к 999 функциям не происходит ни одного вызова. С данными немного сложнее, но если язык не позволяет обращаться к ним как-то иначе, чем по имени или индексу массива, то и тут можно оптимизировать, выбросив всё, до чего код программы явным образом не дотягивается. Также имеет смысл резать один жирный модуль из 1000 функций на 100 модулей по 10 функций в каждом, чтобы программист имел больше контроля над тем, что именно включать в его программу. Проблема в том, что это никому не нужно, всегда проще докупить жёстких дисков или купить очередной смартфон с 1 ТБ встроенной памяти, тем более что контент уже давно на порядки жирнее практически любой программы и поэтому ожирение программ становятся незаметным.
39 Кб, 970x364>>72608
Ну и где их искать? Логи-то?
Ты же прямо учишь анонов писать:
Вместо:
Нет логов!
А потом пикрил. Прямо из тесача, кстати, хайвмайнд какой-то!
Беседка предоставила, но моддерам захотелось большего. Там полдвижка переписали, скрипт экстендер фактически позволяет полноценные либы инжектить. На такое афторы явно не рассчитывали.
А ты - рассчитывай. Не повторяй их ошибок.
Короче. При проектировании игры следует рассматривать данные так, будто они могут неожиданно исчезнуть или поменять формат, если это возможно. А возможно это при динамическом типизировании. Поэтому в первую очередь надо всё проверять на тип. Если импортируешь жсон, заводишь в код схему и валидируешь по схеме. И так далее. И всё логгируешь. Даже тупо принтом. Принты пишутся в логи в папку user://logs/ Свою систему логгирования писать не обязательно.
> как запускать игру с открытым окном консоли или где искать логи с ошибками
Ну и где их искать? Логи-то?
Ты же прямо учишь анонов писать:
> connect("foo", bar, "baz")
Вместо:
> var err = connect(foo, bar, baz)
> if game.log.enabled: game.log.add("Signal %s connected to %s.%s" with status: %s" % [foo, bar, baz, err])
Нет логов!
> Моддинг не входит в твою ответственность
А потом пикрил. Прямо из тесача, кстати, хайвмайнд какой-то!
> предоставляешь официальный Mod API
Беседка предоставила, но моддерам захотелось большего. Там полдвижка переписали, скрипт экстендер фактически позволяет полноценные либы инжектить. На такое афторы явно не рассчитывали.
А ты - рассчитывай. Не повторяй их ошибок.
Короче. При проектировании игры следует рассматривать данные так, будто они могут неожиданно исчезнуть или поменять формат, если это возможно. А возможно это при динамическом типизировании. Поэтому в первую очередь надо всё проверять на тип. Если импортируешь жсон, заводишь в код схему и валидируешь по схеме. И так далее. И всё логгируешь. Даже тупо принтом. Принты пишутся в логи в папку user://logs/ Свою систему логгирования писать не обязательно.
>>72612
Ващета, не стоит через иф это делать, лучше ввести лог левелы. Как-то так:
А дальше уже сам объект лога по матчу принтует только те запросы, которые попадают в логлевел, настроенный в конфиге.
Ващета, не стоит через иф это делать, лучше ввести лог левелы. Как-то так:
> enum LOG_LEVEL { NOTHING, CRITICAL, DETAIL, ALL }
> ...
> var err = connect(foo, bar, baz)
> game.log.add(LOG_LEVEL.DETAIL, "Signal %s connected to %s.%s" with status: %s" % [foo, bar, baz, err])
А дальше уже сам объект лога по матчу принтует только те запросы, которые попадают в логлевел, настроенный в конфиге.
101 Кб, 387x591>>72610
Паскаль?
> ИМХО, нормальный компилируемый язык должен уметь брать из "либы" только то, что действительно нужно конкретной программе. Т.е. если ты используешь 1 функцию из 1000, в исполняемый файл войдёт только эта одна функция, а всё остальное будет срезано из-за того, что в твоём конкретном приложении к 999 функциям не происходит ни одного вызова.
Паскаль?
>>72612
А разве Godot не выводит кучу предупреждений в таких случаях? Или это только в DEBUG режиме? Потому что у меня неправильные коннекты выводят в консоль сообщения (может, не сразу).
В любом случае, в RELEASE билде ты не должен заниматься дебаггингом. Тем более чужих модов.
Буквально учишь делать синглтон на синглтоне и ещё обмазывать кучей ifов на каждый пук. Лапшу любишь?
Ну это даже комментировать бесполезно, человек сознательно ищет проблемы и успешно их находит, что тут сказать? Смышлёный мазохист, молодец.
Ну тут просто какой-то неудачный дизайн игры.
Моддеры сами виноваты, ищут проблемы себе на голову, когда могли бы играть в игровые движки.
Да чего тут рассчитывать? Выложил все исходники игры на гитхаб и дальше пусть игроки учат Godot и копаются в моём гениальном коде. Зачем делать какие-то костыли и велосипеды, когда есть Godot?
Для красноглазых параноиков есть GPL. Только большой корпорации твой код скорее всего вообще не нужен, у них там свои велосипеды, а ассетфлип от ассетфлипера не сможет перебить опенсурс.
Твоя игра не линукс, скопировать механики и контент большая корпорация сможет и без твоих исходников.
Потом будешь жаловаться в движкосраче на пропуки, которые сам же устроил проверкой каждого элемента огромного массива на тип, 240 раз в секунду.
Если у тебя в игре может что-то неожиданно исчезнуть или поменять формат, то ты делаешь игру как-то неправильно. Должна быть чётко продуманная архитектура, а не какие-то непредсказумые изменения, о которых ты ничего знать не можешь, но по какой-то причине несёшь ответственность.
Я понимаю, ты из тех, кто любит модами обмазаться, поэтому ты сидишь в /tes/ и знаешь жопную боль мазохистов с 600+ модами в игре. Но большинство людей модами не увлекается и если ставит моды, то максимум парочку QoL. Среди моддеров также есть расслоение на тех, кому достаточно через интерфейс игры заменить текстуру персонажа свою ЕОТ/вайфу, и тех, кто пытается сделать из игры что-то совершенно иное - вот первых большинство, а вторых единицы даже в самых популярных играх. Так что ты преувеличиваешь проблему.
Алсо, если постоянно заботиться о гипотетических моддерах твоей игры, то так можно и игру никогда не доделать до релизной версии. Особенно учитывая твоё стремление обмазывать код лапшой.
Сначала сделай игру, потом прикрутишь интерфейс для модов, потом пофиксишь ошибки наиболее популярных модов, если они когда-нибудь будут - а их скорее всего у тебя не будет, т.к. большинство игр никому не нужны.
>Нет логов!
А разве Godot не выводит кучу предупреждений в таких случаях? Или это только в DEBUG режиме? Потому что у меня неправильные коннекты выводят в консоль сообщения (может, не сразу).
В любом случае, в RELEASE билде ты не должен заниматься дебаггингом. Тем более чужих модов.
>if game.log.enabled
Буквально учишь делать синглтон на синглтоне и ещё обмазывать кучей ifов на каждый пук. Лапшу любишь?
>модов "около" 600
Ну это даже комментировать бесполезно, человек сознательно ищет проблемы и успешно их находит, что тут сказать? Смышлёный мазохист, молодец.
>файл сохранения = мод
>ссылки на удалённые моды в сейве крашат игру
Ну тут просто какой-то неудачный дизайн игры.
>моддерам захотелось большего
>полдвижка переписали
Моддеры сами виноваты, ищут проблемы себе на голову, когда могли бы играть в игровые движки.
>А ты - рассчитывай
Да чего тут рассчитывать? Выложил все исходники игры на гитхаб и дальше пусть игроки учат Godot и копаются в моём гениальном коде. Зачем делать какие-то костыли и велосипеды, когда есть Godot?
>inb4 украдут
Для красноглазых параноиков есть GPL. Только большой корпорации твой код скорее всего вообще не нужен, у них там свои велосипеды, а ассетфлип от ассетфлипера не сможет перебить опенсурс.
>inb4 а вот линукс украли
Твоя игра не линукс, скопировать механики и контент большая корпорация сможет и без твоих исходников.
>рассматривать данные так, будто они могут неожиданно исчезнуть или поменять формат
Потом будешь жаловаться в движкосраче на пропуки, которые сам же устроил проверкой каждого элемента огромного массива на тип, 240 раз в секунду.
Если у тебя в игре может что-то неожиданно исчезнуть или поменять формат, то ты делаешь игру как-то неправильно. Должна быть чётко продуманная архитектура, а не какие-то непредсказумые изменения, о которых ты ничего знать не можешь, но по какой-то причине несёшь ответственность.
Я понимаю, ты из тех, кто любит модами обмазаться, поэтому ты сидишь в /tes/ и знаешь жопную боль мазохистов с 600+ модами в игре. Но большинство людей модами не увлекается и если ставит моды, то максимум парочку QoL. Среди моддеров также есть расслоение на тех, кому достаточно через интерфейс игры заменить текстуру персонажа свою ЕОТ/вайфу, и тех, кто пытается сделать из игры что-то совершенно иное - вот первых большинство, а вторых единицы даже в самых популярных играх. Так что ты преувеличиваешь проблему.
Алсо, если постоянно заботиться о гипотетических моддерах твоей игры, то так можно и игру никогда не доделать до релизной версии. Особенно учитывая твоё стремление обмазывать код лапшой.
Сначала сделай игру, потом прикрутишь интерфейс для модов, потом пофиксишь ошибки наиболее популярных модов, если они когда-нибудь будут - а их скорее всего у тебя не будет, т.к. большинство игр никому не нужны.
>>72612
А разве Godot не выводит кучу предупреждений в таких случаях? Или это только в DEBUG режиме? Потому что у меня неправильные коннекты выводят в консоль сообщения (может, не сразу).
В любом случае, в RELEASE билде ты не должен заниматься дебаггингом. Тем более чужих модов.
Буквально учишь делать синглтон на синглтоне и ещё обмазывать кучей ifов на каждый пук. Лапшу любишь?
Ну это даже комментировать бесполезно, человек сознательно ищет проблемы и успешно их находит, что тут сказать? Смышлёный мазохист, молодец.
Ну тут просто какой-то неудачный дизайн игры.
Моддеры сами виноваты, ищут проблемы себе на голову, когда могли бы играть в игровые движки.
Да чего тут рассчитывать? Выложил все исходники игры на гитхаб и дальше пусть игроки учат Godot и копаются в моём гениальном коде. Зачем делать какие-то костыли и велосипеды, когда есть Godot?
Для красноглазых параноиков есть GPL. Только большой корпорации твой код скорее всего вообще не нужен, у них там свои велосипеды, а ассетфлип от ассетфлипера не сможет перебить опенсурс.
Твоя игра не линукс, скопировать механики и контент большая корпорация сможет и без твоих исходников.
Потом будешь жаловаться в движкосраче на пропуки, которые сам же устроил проверкой каждого элемента огромного массива на тип, 240 раз в секунду.
Если у тебя в игре может что-то неожиданно исчезнуть или поменять формат, то ты делаешь игру как-то неправильно. Должна быть чётко продуманная архитектура, а не какие-то непредсказумые изменения, о которых ты ничего знать не можешь, но по какой-то причине несёшь ответственность.
Я понимаю, ты из тех, кто любит модами обмазаться, поэтому ты сидишь в /tes/ и знаешь жопную боль мазохистов с 600+ модами в игре. Но большинство людей модами не увлекается и если ставит моды, то максимум парочку QoL. Среди моддеров также есть расслоение на тех, кому достаточно через интерфейс игры заменить текстуру персонажа свою ЕОТ/вайфу, и тех, кто пытается сделать из игры что-то совершенно иное - вот первых большинство, а вторых единицы даже в самых популярных играх. Так что ты преувеличиваешь проблему.
Алсо, если постоянно заботиться о гипотетических моддерах твоей игры, то так можно и игру никогда не доделать до релизной версии. Особенно учитывая твоё стремление обмазывать код лапшой.
Сначала сделай игру, потом прикрутишь интерфейс для модов, потом пофиксишь ошибки наиболее популярных модов, если они когда-нибудь будут - а их скорее всего у тебя не будет, т.к. большинство игр никому не нужны.
>Нет логов!
А разве Godot не выводит кучу предупреждений в таких случаях? Или это только в DEBUG режиме? Потому что у меня неправильные коннекты выводят в консоль сообщения (может, не сразу).
В любом случае, в RELEASE билде ты не должен заниматься дебаггингом. Тем более чужих модов.
>if game.log.enabled
Буквально учишь делать синглтон на синглтоне и ещё обмазывать кучей ifов на каждый пук. Лапшу любишь?
>модов "около" 600
Ну это даже комментировать бесполезно, человек сознательно ищет проблемы и успешно их находит, что тут сказать? Смышлёный мазохист, молодец.
>файл сохранения = мод
>ссылки на удалённые моды в сейве крашат игру
Ну тут просто какой-то неудачный дизайн игры.
>моддерам захотелось большего
>полдвижка переписали
Моддеры сами виноваты, ищут проблемы себе на голову, когда могли бы играть в игровые движки.
>А ты - рассчитывай
Да чего тут рассчитывать? Выложил все исходники игры на гитхаб и дальше пусть игроки учат Godot и копаются в моём гениальном коде. Зачем делать какие-то костыли и велосипеды, когда есть Godot?
>inb4 украдут
Для красноглазых параноиков есть GPL. Только большой корпорации твой код скорее всего вообще не нужен, у них там свои велосипеды, а ассетфлип от ассетфлипера не сможет перебить опенсурс.
>inb4 а вот линукс украли
Твоя игра не линукс, скопировать механики и контент большая корпорация сможет и без твоих исходников.
>рассматривать данные так, будто они могут неожиданно исчезнуть или поменять формат
Потом будешь жаловаться в движкосраче на пропуки, которые сам же устроил проверкой каждого элемента огромного массива на тип, 240 раз в секунду.
Если у тебя в игре может что-то неожиданно исчезнуть или поменять формат, то ты делаешь игру как-то неправильно. Должна быть чётко продуманная архитектура, а не какие-то непредсказумые изменения, о которых ты ничего знать не можешь, но по какой-то причине несёшь ответственность.
Я понимаю, ты из тех, кто любит модами обмазаться, поэтому ты сидишь в /tes/ и знаешь жопную боль мазохистов с 600+ модами в игре. Но большинство людей модами не увлекается и если ставит моды, то максимум парочку QoL. Среди моддеров также есть расслоение на тех, кому достаточно через интерфейс игры заменить текстуру персонажа свою ЕОТ/вайфу, и тех, кто пытается сделать из игры что-то совершенно иное - вот первых большинство, а вторых единицы даже в самых популярных играх. Так что ты преувеличиваешь проблему.
Алсо, если постоянно заботиться о гипотетических моддерах твоей игры, то так можно и игру никогда не доделать до релизной версии. Особенно учитывая твоё стремление обмазывать код лапшой.
Сначала сделай игру, потом прикрутишь интерфейс для модов, потом пофиксишь ошибки наиболее популярных модов, если они когда-нибудь будут - а их скорее всего у тебя не будет, т.к. большинство игр никому не нужны.
>>72629
Дело в том, что у меня хитрый план: сделать недопиленную игру, но распиарить её так, чтобы слетелась куча мододелов и допилили её модами.
Дело в том, что у меня хитрый план: сделать недопиленную игру, но распиарить её так, чтобы слетелась куча мододелов и допилили её модами.
>>72631
Тут был уже один такой, с прыгающей квадратной дверью. Уже год кнопки докрасить не может.
Тут был уже один такой, с прыгающей квадратной дверью. Уже год кнопки докрасить не может.
>>72631
Выпускаешь игру, её покупают, смотришь отзывы:
Твои действия?
На что они слетятся, если у тебя игроков нет?
Допилили до чего? Во что играть-то будем?
>>72635
Ты не понимаешь, у него арт-проект, важен каждый пиксель, это тебе не чужие ассеты в кучку флипать.
>сделать недопиленную игру, но распиарить
Выпускаешь игру, её покупают, смотришь отзывы:
>Overwhelmingly Negative (666)
Твои действия?
>слетелась куча мододелов
На что они слетятся, если у тебя игроков нет?
>допилили её модами
Допилили до чего? Во что играть-то будем?
>>72635
>кнопки докрасить не может
Ты не понимаешь, у него арт-проект, важен каждый пиксель, это тебе не чужие ассеты в кучку флипать.
>>72631
На самом деле твоя идея не так уж провальна, если ты с самого начала делаешь площадку для модов наподобие таких проектов, как G-Mod, Roblox, Minetest, VRChat и многих других. Такая мета-песочница для создания игр внутри одной большой "игры", которая на самом деле больше напоминает лаунчер для игр.
Но если ты имеешь в виду буквально недоделанную игру, в смысле 1.5 уровня и унылый геймплей с возможностью дополнить модами, то тут увы, тебе придётся сначала самому набить игру качественным контентом хотя бы в формате рациональных модов, прежде чем она сможет взлететь и набрать достаточную популярность для того, чтобы людям хотелось в неё бесплатно вкладываться.
Скажем так, есть те, кто делает моды для себя и своих друзей, но размер, качество и сложность этих модов оставляет желать лучшего, поэтому рассчитывать на них не стоит; а есть те, кто делает большой, качественный и сложный мод в надежде стать популярным в сообществе или принести пользу большому сообществу игроков. Вот если первые могут состряпать мод к любой понравившейся игре, то вторые придут только к уже популярной игре, поэтому надеяться на них с самого релиза не стоит - если игра не взлетит, их работа будет впустую. А создание действительно хорошего мода - это и есть работа, при том в большинстве случаев бесплатно, приносящая профиты совсем не тому, кто работал в поте лица.
В общем, сначала игра должна набрать популярность, а уже потом она может поддерживать популярность за счёт желающих сделать крупный мод ради хайпа.
Могу ошибаться, делаю выводы по наблюдениям.
На самом деле твоя идея не так уж провальна, если ты с самого начала делаешь площадку для модов наподобие таких проектов, как G-Mod, Roblox, Minetest, VRChat и многих других. Такая мета-песочница для создания игр внутри одной большой "игры", которая на самом деле больше напоминает лаунчер для игр.
Но если ты имеешь в виду буквально недоделанную игру, в смысле 1.5 уровня и унылый геймплей с возможностью дополнить модами, то тут увы, тебе придётся сначала самому набить игру качественным контентом хотя бы в формате рациональных модов, прежде чем она сможет взлететь и набрать достаточную популярность для того, чтобы людям хотелось в неё бесплатно вкладываться.
Скажем так, есть те, кто делает моды для себя и своих друзей, но размер, качество и сложность этих модов оставляет желать лучшего, поэтому рассчитывать на них не стоит; а есть те, кто делает большой, качественный и сложный мод в надежде стать популярным в сообществе или принести пользу большому сообществу игроков. Вот если первые могут состряпать мод к любой понравившейся игре, то вторые придут только к уже популярной игре, поэтому надеяться на них с самого релиза не стоит - если игра не взлетит, их работа будет впустую. А создание действительно хорошего мода - это и есть работа, при том в большинстве случаев бесплатно, приносящая профиты совсем не тому, кто работал в поте лица.
В общем, сначала игра должна набрать популярность, а уже потом она может поддерживать популярность за счёт желающих сделать крупный мод ради хайпа.
Могу ошибаться, делаю выводы по наблюдениям.
>>72639
1. Ходить персом от 3 лица в 3D-песочнице, состоящей из закрытых локаций.
2. Между локациями перемещаемся через мини-игру в лобби-комнате, выполненной в стимпаноквом стиле.
3. Собирать на локациях ресы. Крафтить апгрейды. Устанавливать в слоты в лобби-локации. открывать доступ к новым локациям с более крутыми ресами.
4. Качать собственный левел по дереву прокачки.
5. На мирных локациях общаться с неписями, получать квесты.
6. На враждебных локациях сражаться с монстрами, в том числе боссами.
7. Продвигаться по простенькому сюжету с дружбой, предательством, драмой и любовью.
8. В последней главе сюжета ГГ получает доступ к локации-городу, до этого он всё по деревням шастал. В городе будет финальная битва с главбоссом и выбор концовки.
9. Город будет больше декорацией, заточенной кокрастоке под моддинг, что моддеры напихают туда контента, заселят домики неписями, настрогают допквестов и т.д.
> Во что играть-то будем?
1. Ходить персом от 3 лица в 3D-песочнице, состоящей из закрытых локаций.
2. Между локациями перемещаемся через мини-игру в лобби-комнате, выполненной в стимпаноквом стиле.
3. Собирать на локациях ресы. Крафтить апгрейды. Устанавливать в слоты в лобби-локации. открывать доступ к новым локациям с более крутыми ресами.
4. Качать собственный левел по дереву прокачки.
5. На мирных локациях общаться с неписями, получать квесты.
6. На враждебных локациях сражаться с монстрами, в том числе боссами.
7. Продвигаться по простенькому сюжету с дружбой, предательством, драмой и любовью.
8. В последней главе сюжета ГГ получает доступ к локации-городу, до этого он всё по деревням шастал. В городе будет финальная битва с главбоссом и выбор концовки.
9. Город будет больше декорацией, заточенной кокрастоке под моддинг, что моддеры напихают туда контента, заселят домики неписями, настрогают допквестов и т.д.
>>72642
Увы, практика показала, что пиарщик из меня говёный. Мой пиар воспринимался как стёб. Честно говоря, начиналась эта идея как стёб. А потом начала обрастать лором у меня в голове и я такой думаю "а ведь она могла бы взлететь!"
> В общем, сначала игра должна набрать популярность
Увы, практика показала, что пиарщик из меня говёный. Мой пиар воспринимался как стёб. Честно говоря, начиналась эта идея как стёб. А потом начала обрастать лором у меня в голове и я такой думаю "а ведь она могла бы взлететь!"
>>72646
Т О Л Щ Е Х О Д Ы ?
>>72645
У тебя не только вселенная наоборот, но и подход к моддингу вывернутый наизнанку...
1. Будут ли мелкие локации процедурными?
2. Есть ли смысл уходить с финальной локации?
3. Продолжается ли игра после выбора концовки?
4. Как долго двигаться по сюжету к этому городу?
5. Можно ли моддить что-то кроме этого города?
6. Что делают NPC и насколько сложны квесты?
>Мой пиар воспринимался как стёб
>начиналась эта идея как стёб
>стимпанк-лобби
>закрытые локации
>апгрейды в слоты лобби
>общаться с неписями в локациях
>сюжет с дружбой, предательством и любовью
>путешествие ГГ от деревень к большому городу
Т О Л Щ Е Х О Д Ы ?
>>72645
>В последней главе сюжета ГГ получает доступ к
>заточенной кокрастоке под моддинг
>моддеры напихают туда контента
У тебя не только вселенная наоборот, но и подход к моддингу вывернутый наизнанку...
1. Будут ли мелкие локации процедурными?
2. Есть ли смысл уходить с финальной локации?
3. Продолжается ли игра после выбора концовки?
4. Как долго двигаться по сюжету к этому городу?
5. Можно ли моддить что-то кроме этого города?
6. Что делают NPC и насколько сложны квесты?
>>72645
Соглашусь с аноном выше что немного странная последовательность. Логичнее если с модденым контентом игрок столкнется раньше, чем прям в конце игры. Если только ты не подразумеваешь какой то бесконечный режим, но и то не факт что будет интересно после босса. И сайдквесты логичнее делать в основной массе до босса. Лучше его перенести в следующий город или на гору какую то.
Соглашусь с аноном выше что немного странная последовательность. Логичнее если с модденым контентом игрок столкнется раньше, чем прям в конце игры. Если только ты не подразумеваешь какой то бесконечный режим, но и то не факт что будет интересно после босса. И сайдквесты логичнее делать в основной массе до босса. Лучше его перенести в следующий город или на гору какую то.
А пока анон тут кирилльствует и ждёт мододелов, я почти допилил демоверсию своего 8-битного платформера. Там делов осталось: исправить пару багов да нарисовать пару уровней. А, и ещё какие-то титры на концовку прикрутить. Лол, титры из одного меня, потому что в одиночку всё запилил. Прошлой весной начал, но к маю забросил, а на прошлой неделе вот сдул пыль и решил доделать. План такой: допилить первый мир (примерно 1/8 от игры), выкинуть в интернеты и посмотреть не реакцию. Кстати, а какие щас ресурсы, кроме итча, для такого пригодны?
>>72673
Только декомпозировав и вывернув наизнанку весь геймдев - можно создать что-то отдалённо претендующее на новизну. Без этого будет очередное стардью, очередной майнкрафт, очередной скайрим, клоны, клоны, клоны, вторичка, вторичка, вторичка.
>>72673
Локации вручную, а их содержимое - процедурное по сиду без рандома, строго по внутренним правилам игрового мира.
Да и да. Мир проектируется полностью живым и динамическим. Единожды зачищенная враждебная локация со временем обрастает новой жизнью, с учётом соседних локаций. Причем она может как снова стать враждебной, так и заселиться мирными майнерами. Город, как я и писал выше, проектируется чтобы создать краткосрочный вау-эффект, когда игрок туда прибудет. Затем выяснится, что место это в целом скучное, делать там нехуй, по одним и тем же барам и магазинам прошёлся и всё. Игра должна подначивать игроков снова отправляться в поход. Это как крупные локации в Raft, чистенькие, удобные, но выжить геймплейно игрок не сможет, я обещал без вторичности, но мне нравится подход.
Сложно сказать на ранних этапах предпродакшена. А сколько надо?
Конешна! Давай сразу проясним. "Городом" центральная локация называется потому, что весь её объём застроен. Промышленными постройками. Жилыми кварталами. Короче, городской ассет. АПИ моддинга предполагает, что моддер сможет как внедрить свои изменения в существующие локации (добавить жилой дом вместо декоративного дома-коробки, с жильцами и квестами) а так же сможет добавить свои локации в любом месте карты мира, с любым типом ассетов, набить своим контентом, как захочет. Ну и по классике, можно будет менять или дополнять модели оружия, брони, одежды.
Стейтмашина с бехавиортрёй водят их по ГОАП-графику с учётом окружающей обстановки (если игрок обезумел, неписи будут разбегаться и только самые отважные попытаются с ним совладать).
Три уровня вложенности твистов. Шесть уровней развилок с ограничением по скиллам.
> подход к моддингу вывернутый наизнанку
Только декомпозировав и вывернув наизнанку весь геймдев - можно создать что-то отдалённо претендующее на новизну. Без этого будет очередное стардью, очередной майнкрафт, очередной скайрим, клоны, клоны, клоны, вторичка, вторичка, вторичка.
>>72673
>Будут ли мелкие локации процедурными?
Локации вручную, а их содержимое - процедурное по сиду без рандома, строго по внутренним правилам игрового мира.
>Есть ли смысл уходить с финальной локации?
>Продолжается ли игра после выбора концовки?
Да и да. Мир проектируется полностью живым и динамическим. Единожды зачищенная враждебная локация со временем обрастает новой жизнью, с учётом соседних локаций. Причем она может как снова стать враждебной, так и заселиться мирными майнерами. Город, как я и писал выше, проектируется чтобы создать краткосрочный вау-эффект, когда игрок туда прибудет. Затем выяснится, что место это в целом скучное, делать там нехуй, по одним и тем же барам и магазинам прошёлся и всё. Игра должна подначивать игроков снова отправляться в поход. Это как крупные локации в Raft, чистенькие, удобные, но выжить геймплейно игрок не сможет, я обещал без вторичности, но мне нравится подход.
>Как долго двигаться по сюжету к этому городу?
Сложно сказать на ранних этапах предпродакшена. А сколько надо?
>Можно ли моддить что-то кроме этого города?
Конешна! Давай сразу проясним. "Городом" центральная локация называется потому, что весь её объём застроен. Промышленными постройками. Жилыми кварталами. Короче, городской ассет. АПИ моддинга предполагает, что моддер сможет как внедрить свои изменения в существующие локации (добавить жилой дом вместо декоративного дома-коробки, с жильцами и квестами) а так же сможет добавить свои локации в любом месте карты мира, с любым типом ассетов, набить своим контентом, как захочет. Ну и по классике, можно будет менять или дополнять модели оружия, брони, одежды.
>Что делают NPC?
Стейтмашина с бехавиортрёй водят их по ГОАП-графику с учётом окружающей обстановки (если игрок обезумел, неписи будут разбегаться и только самые отважные попытаются с ним совладать).
>насколько сложны квесты?
Три уровня вложенности твистов. Шесть уровней развилок с ограничением по скиллам.
>>72673
Только декомпозировав и вывернув наизнанку весь геймдев - можно создать что-то отдалённо претендующее на новизну. Без этого будет очередное стардью, очередной майнкрафт, очередной скайрим, клоны, клоны, клоны, вторичка, вторичка, вторичка.
>>72673
Локации вручную, а их содержимое - процедурное по сиду без рандома, строго по внутренним правилам игрового мира.
Да и да. Мир проектируется полностью живым и динамическим. Единожды зачищенная враждебная локация со временем обрастает новой жизнью, с учётом соседних локаций. Причем она может как снова стать враждебной, так и заселиться мирными майнерами. Город, как я и писал выше, проектируется чтобы создать краткосрочный вау-эффект, когда игрок туда прибудет. Затем выяснится, что место это в целом скучное, делать там нехуй, по одним и тем же барам и магазинам прошёлся и всё. Игра должна подначивать игроков снова отправляться в поход. Это как крупные локации в Raft, чистенькие, удобные, но выжить геймплейно игрок не сможет, я обещал без вторичности, но мне нравится подход.
Сложно сказать на ранних этапах предпродакшена. А сколько надо?
Конешна! Давай сразу проясним. "Городом" центральная локация называется потому, что весь её объём застроен. Промышленными постройками. Жилыми кварталами. Короче, городской ассет. АПИ моддинга предполагает, что моддер сможет как внедрить свои изменения в существующие локации (добавить жилой дом вместо декоративного дома-коробки, с жильцами и квестами) а так же сможет добавить свои локации в любом месте карты мира, с любым типом ассетов, набить своим контентом, как захочет. Ну и по классике, можно будет менять или дополнять модели оружия, брони, одежды.
Стейтмашина с бехавиортрёй водят их по ГОАП-графику с учётом окружающей обстановки (если игрок обезумел, неписи будут разбегаться и только самые отважные попытаются с ним совладать).
Три уровня вложенности твистов. Шесть уровней развилок с ограничением по скиллам.
> подход к моддингу вывернутый наизнанку
Только декомпозировав и вывернув наизнанку весь геймдев - можно создать что-то отдалённо претендующее на новизну. Без этого будет очередное стардью, очередной майнкрафт, очередной скайрим, клоны, клоны, клоны, вторичка, вторичка, вторичка.
>>72673
>Будут ли мелкие локации процедурными?
Локации вручную, а их содержимое - процедурное по сиду без рандома, строго по внутренним правилам игрового мира.
>Есть ли смысл уходить с финальной локации?
>Продолжается ли игра после выбора концовки?
Да и да. Мир проектируется полностью живым и динамическим. Единожды зачищенная враждебная локация со временем обрастает новой жизнью, с учётом соседних локаций. Причем она может как снова стать враждебной, так и заселиться мирными майнерами. Город, как я и писал выше, проектируется чтобы создать краткосрочный вау-эффект, когда игрок туда прибудет. Затем выяснится, что место это в целом скучное, делать там нехуй, по одним и тем же барам и магазинам прошёлся и всё. Игра должна подначивать игроков снова отправляться в поход. Это как крупные локации в Raft, чистенькие, удобные, но выжить геймплейно игрок не сможет, я обещал без вторичности, но мне нравится подход.
>Как долго двигаться по сюжету к этому городу?
Сложно сказать на ранних этапах предпродакшена. А сколько надо?
>Можно ли моддить что-то кроме этого города?
Конешна! Давай сразу проясним. "Городом" центральная локация называется потому, что весь её объём застроен. Промышленными постройками. Жилыми кварталами. Короче, городской ассет. АПИ моддинга предполагает, что моддер сможет как внедрить свои изменения в существующие локации (добавить жилой дом вместо декоративного дома-коробки, с жильцами и квестами) а так же сможет добавить свои локации в любом месте карты мира, с любым типом ассетов, набить своим контентом, как захочет. Ну и по классике, можно будет менять или дополнять модели оружия, брони, одежды.
>Что делают NPC?
Стейтмашина с бехавиортрёй водят их по ГОАП-графику с учётом окружающей обстановки (если игрок обезумел, неписи будут разбегаться и только самые отважные попытаются с ним совладать).
>насколько сложны квесты?
Три уровня вложенности твистов. Шесть уровней развилок с ограничением по скиллам.
>>72675
Столкнётся раньше. Я по классике своего постинга выразился невнятно.
>Логичнее если с модденым контентом игрок столкнется раньше, чем прям в конце игры.
Столкнётся раньше. Я по классике своего постинга выразился невнятно.
>>72558
Именно. Стандартная либа всегда находилась в стороне от языка, поэтому связность с платформой у нее низкая, шейкить проблем не будет, т.е. никакого дополнительного оверхеда. Собственно, C# уже компилируется в последней версии, но пока через костыли, а не найтив, и там на нынешнем этапе "раздувание" порядка 5 мегабайт идет.
>Что, и вся стандартная либа в 500кб уложится?
Именно. Стандартная либа всегда находилась в стороне от языка, поэтому связность с платформой у нее низкая, шейкить проблем не будет, т.е. никакого дополнительного оверхеда. Собственно, C# уже компилируется в последней версии, но пока через костыли, а не найтив, и там на нынешнем этапе "раздувание" порядка 5 мегабайт идет.
>>72743
Хорошо если так, я почитал про trimming и это не кажется очень легкой проблемой, ну будем надеяться что движок достаточно самодостаточный и не полагается на проблемные штуки.
>шейкить проблем не будет
Хорошо если так, я почитал про trimming и это не кажется очень легкой проблемой, ну будем надеяться что движок достаточно самодостаточный и не полагается на проблемные штуки.
26 Кб, 627x345Вчера я посещал запретный тред и там пообщался с чуваком, который пилит свой движок на РАСТЕ. И там был ещё один из наших, который предложил ему переходить на годот. А я ещё и подкинул раст-аддон для годота, а потом предложил тому анону прорекламировать этот свой раст. И он прорекламировал.
И знаете что?
Я уже сутки смотрю туториалы и инфу по расту. Это охуенно! Синтаксис как смесь гдскрипта и си! Много крутых фич! Строгая типизация с выведением типов по инициализатору! Принцип владения и принцип типажей открывают свежий взгляд на ООП без наследования и с олдовыми интерфейсами, которые не являются программной сущностью "интерфейс", а являются интерфейсами программной сущности. Ссылкобезопасность и потокобезопасность бай дизайн искаропки! Системный автономный компилятор без зависимостей! Хоспаде, я долгие годы ждал такой язык. Буду переходить на него.
А ещё там match как в гдскрипте!
И знаете что?
Я уже сутки смотрю туториалы и инфу по расту. Это охуенно! Синтаксис как смесь гдскрипта и си! Много крутых фич! Строгая типизация с выведением типов по инициализатору! Принцип владения и принцип типажей открывают свежий взгляд на ООП без наследования и с олдовыми интерфейсами, которые не являются программной сущностью "интерфейс", а являются интерфейсами программной сущности. Ссылкобезопасность и потокобезопасность бай дизайн искаропки! Системный автономный компилятор без зависимостей! Хоспаде, я долгие годы ждал такой язык. Буду переходить на него.
А ещё там match как в гдскрипте!
>>72874
беви шо?
беви шо?
>>72714
Проблема в том, что новизна мало кому интересна, люди привыкают к определённому порядку вещей и потом недовольны изменениями. Вот пример выше - люди настолько привыкли к C, что авторы большинства новых языков делают свои языки похожими на C. Появляются ли новые языки, не похожие на C? Конечно, появляются, но о них ничего не слышно, потому что люди дрочат на C с его фигурными скобками и закорючками, а на любые альтернативы плюются и ругаются. Не говоря о том, насколько сильно доминирует императивная парадигма по сравнению с возможными альтернативами.
С играми всё точно так же - дрочат на одно и то же, каждый год покупая очередное переиздание с чисто косметическими изменениями за стоимость новой игры. Никому не хочется учиться чему-то новому ради игры. Кроме того, покупая любую игру, игрок имеет какие-то ожидания, и если игра не оправдала ожиданий - она зарабатывает негативный отзыв от этого игрока, а что является лучшим способом не оправдать чьи-то ожидания? Правильно, изобрести уникальный, ни на что не похожий велосипед, прямо противоположный любым ожиданиям.
Мне кажется, у тебя слишком амбициозные планы, ты взваливаешь на себя слишком много. Будь готов к тому, что придётся отбросить многие фичи.
>претендующее на новизну
>клоны, вторичка
Проблема в том, что новизна мало кому интересна, люди привыкают к определённому порядку вещей и потом недовольны изменениями. Вот пример выше - люди настолько привыкли к C, что авторы большинства новых языков делают свои языки похожими на C. Появляются ли новые языки, не похожие на C? Конечно, появляются, но о них ничего не слышно, потому что люди дрочат на C с его фигурными скобками и закорючками, а на любые альтернативы плюются и ругаются. Не говоря о том, насколько сильно доминирует императивная парадигма по сравнению с возможными альтернативами.
С играми всё точно так же - дрочат на одно и то же, каждый год покупая очередное переиздание с чисто косметическими изменениями за стоимость новой игры. Никому не хочется учиться чему-то новому ради игры. Кроме того, покупая любую игру, игрок имеет какие-то ожидания, и если игра не оправдала ожиданий - она зарабатывает негативный отзыв от этого игрока, а что является лучшим способом не оправдать чьи-то ожидания? Правильно, изобрести уникальный, ни на что не похожий велосипед, прямо противоположный любым ожиданиям.
>Мир проектируется полностью живым
Мне кажется, у тебя слишком амбициозные планы, ты взваливаешь на себя слишком много. Будь готов к тому, что придётся отбросить многие фичи.
>>72928
Немного поделав игор на твг (занимая первые с конца места, лол), я пришёл к выводу, что 3D в целом проще делать, чем 2D, как ни парадоксально. Казалось бы, в двадэ просто спрайты рисуй и всё, алгебра проще, а в тридэ меши, а в триде квартернионы, уууу! Но забывают, что красивый спрайт сложнее сделать, чем красивое лоуполи. А их нужно будет дохуя! И все должны быть красивы. И все в одном стиле. Трёхмерный матан, конечно сложнее двухмерного, но по существу, ненамного.
Полностью цельный, живой и открытый мир может показаться чем-то ужасающе сложным, но если разобраться, - это всего лишь база данных плюс набор систем-агентов, периодически обновляющих данные в этой базе, плюс набор сущностей-агентов, которые сверяются в своём поведении с базой данных.
Вот это на самом деле сильнее всего демотивирует. А если ещё добавить, что по настоящему новых идей исчезающе мало, и любая новая идея, которую мы можем придумать, будет на 99% подсознательной компиляцией ранее пережитого(просмотренного) нами, то становится совсем уж уныло. Я напомню: придуманная мной в 2018-ом "свежая" идея оказалась идеей с доброчана 2010-го, которую в том числе и я развивал в те годы, но забыл, и спустя годы она всплыла в памяти как своя, обрастая новыми подробностями.
> у тебя слишком амбициозные планы, ты взваливаешь на себя слишком много
Немного поделав игор на твг (занимая первые с конца места, лол), я пришёл к выводу, что 3D в целом проще делать, чем 2D, как ни парадоксально. Казалось бы, в двадэ просто спрайты рисуй и всё, алгебра проще, а в тридэ меши, а в триде квартернионы, уууу! Но забывают, что красивый спрайт сложнее сделать, чем красивое лоуполи. А их нужно будет дохуя! И все должны быть красивы. И все в одном стиле. Трёхмерный матан, конечно сложнее двухмерного, но по существу, ненамного.
Полностью цельный, живой и открытый мир может показаться чем-то ужасающе сложным, но если разобраться, - это всего лишь база данных плюс набор систем-агентов, периодически обновляющих данные в этой базе, плюс набор сущностей-агентов, которые сверяются в своём поведении с базой данных.
> Проблема в том, что новизна мало кому интересна
Вот это на самом деле сильнее всего демотивирует. А если ещё добавить, что по настоящему новых идей исчезающе мало, и любая новая идея, которую мы можем придумать, будет на 99% подсознательной компиляцией ранее пережитого(просмотренного) нами, то становится совсем уж уныло. Я напомню: придуманная мной в 2018-ом "свежая" идея оказалась идеей с доброчана 2010-го, которую в том числе и я развивал в те годы, но забыл, и спустя годы она всплыла в памяти как своя, обрастая новыми подробностями.
>>72928
А вот тут я бы поспорил. Скобки - это общепризнанный шаблон области видимости, так же известной как тело функции. Предложи свой вариант, как в одну строку записать несколько операторов, часть которых следует выделить в отдельную область?
Повторюсь, выделить надо в одну строку.
Сиподобные языки выделяют скобками:
Паскалеподобные - ключевыми словами:
Питоноподобные вообще в одну строку не могут и вводят в парсинг текста дополнительную сложность.
> потому что люди дрочат на C с его фигурными скобками и закорючками
А вот тут я бы поспорил. Скобки - это общепризнанный шаблон области видимости, так же известной как тело функции. Предложи свой вариант, как в одну строку записать несколько операторов, часть которых следует выделить в отдельную область?
> op1 op2 op3 op4 op5
Повторюсь, выделить надо в одну строку.
Сиподобные языки выделяют скобками:
> op1; op2 { op3; op4; } op5;
Паскалеподобные - ключевыми словами:
> op1; op2 begin op3; op4; end; op5.
Питоноподобные вообще в одну строку не могут и вводят в парсинг текста дополнительную сложность.
>>72959
Ах да, есть ещё языки типа бейсика, в которых если оператор объявил тело/область, её следует закончить специальным оператором end.
И ещё есть языки типа линуксового шеллскрипта, в которых, если оператор объявил тело/область, её следует закончить, написав тот же оператор наизнанку.
Ах да, есть ещё языки типа бейсика, в которых если оператор объявил тело/область, её следует закончить специальным оператором end.
И ещё есть языки типа линуксового шеллскрипта, в которых, если оператор объявил тело/область, её следует закончить, написав тот же оператор наизнанку.
>>72928
Раст слишком отличается от Си. Язык это не только скобочки.
Фигурные скобочки это топ, потому что позволяют однозначно показать блок кода, занимают всего 1 символ, и не полагаются на табы, которые легко проебать. Альтернативой может быть только какая-то другая скобочка, например круглая, но это смотрится хуже.
Раст слишком отличается от Си. Язык это не только скобочки.
> фигурными скобками
Фигурные скобочки это топ, потому что позволяют однозначно показать блок кода, занимают всего 1 символ, и не полагаются на табы, которые легко проебать. Альтернативой может быть только какая-то другая скобочка, например круглая, но это смотрится хуже.
296 Кб, 1795x907>>72974
Хватит, убийца всех языков вышел без скобочек, значит так лучше, привыкайте
>Фигурные скобочки это топ
Хватит, убийца всех языков вышел без скобочек, значит так лучше, привыкайте
>>72957
Ты прав, но я говорил не про сложность графики.
На практике он и является ужасающие сложным. А ты как думаешь, почему даже самые дорогие ААА игры выходят с декоративной пустышкой вместо живого мира? Всякие TES не сильно ушли от пустых декораций. Живой мир в играх сделать сложнее всего, а у тебя там ещё 9001 механика намечается судя по комбинации мирной жизни с развитием отношений, сражениями с монстрами и даже захватом территорий.
Ты замучаешься их выдумывать, кодить, а потом балансировать, чтобы твоя живая система не превращалась в выжженную пустыню от лёгкого ветерка, дунувшего на 0.5° в другом направлении.
Не говоря уж о том, что полноценная живая система большого объёма была бы слишком тяжёлой для персонального компьютера, поэтому игры, которые пытаются в живые миры, в конечном итоге режут всё на мелкие декорации с кучей костылей.
Шутишь что ли? Теории заговора "полой Земли" вроде бы уже несколько веков, были художественные книги, в фильмах что-то похожее было, даже в аниме. Целиком вывернуть весь космос в игре попытались ещё в 90-х, там игра про каких-то роботов была вроде бы и по сюжету мир был состоял из нескольких пузырей в некой тверди. Быстроходные землеройные машины тоже много веков выдумывали и в начале 20-го века даже пытались реализовать, но физика мешает осуществлять движение быстрее сантиметра в час или около того, лол, поэтому ничего быстрее проходческих щитов у нас нет, но пафоса и острых зубов у них достаточно. Всё это так или иначе влияет на людей и их фантазии, особенно у детей, поэтому твоя идея космоса наоборот не была новой даже в 2010.
Просто мало кому интересна такая реализация, вот и не делают. Подумай сам, что даёт тебе полый мир? Ну... Он такой же, как наш, только реки текут "вверх", но если диаметр достаточно большой - кривизну заметить сложно и противоположной стороны вообще не видно. Гравитация тянет тебя к поверхности, а в центре что-то вроде маленькой звезды, поэтому прыжком добраться до другой стороны невозможно. Эстетически красивого космоса со звёздами ночью ты вообще не увидишь. В чём же тогда фан такого мира? А если фана нет, то и реализовывать его смысла нет. Тем более что мир в играх чаще всего не имеет кривизны вообще, а представляет собой плоскость с невидимыми стенами, потому что вычисления физики и навигация на плоскости намного проще, особенно в 3D.
Далее, что даёт твёрдый космос? Огромные расстояния, через которые нужно копать туннели. Теоретически, какие-то ресурсы в огромных количествах. Но ты практически ничего не видишь, кроме скана сонарами и вынужден всё так же сидеть бесконечно долгое время в тарахтящей консервной банке. Никаких боевых ситуаций, манёвров и прочего тут уже не придумаешь, т.к. вокруг тебя плотные стены, разве что землеройные ракеты выпускать, но ты опять же ограничен в знании окружающего мира. Реальный космос тоже скучный, но он хотя бы красивый и даёт много места для добавления интересных игровых условностей, а космос наизнанку скучный, некрасивый и ограничен даже для игровых условностей, если не нарушать базовой установки "твердь вместо вакуума". Реализовать игромеханически такое ещё сложнее, нужны воксели и какой-то способ создать иллюзию бесконечности в любом направлении, что достаточно просто в пустом космосе (далёкие звёзды - спрайты, а всё остальное пространство очевидно пустое и компьютер не грузит). Я вижу, что ты отказался от буквальной реализации и заменил её неким лобби, который будет фактически телепортировать игрока из одного полого мира в другой, но стоило ли вообще тогда придумывать такой вывернутый космос? В чём его привлекательность для игрока?
Я не пытаюсь тебя отговорить, делай что хочешь. Реализовать твои идеи возможно и они не будут выглядеть слишком чужеродными, особенно если все основные механики (движение, бой, диалоги, инвентарь и т.д.) будут привычными. В конце концов, это просто причудливые декорации. Просто особого прикладного смысла в них нет, популярности как романтического сеттинга (стимпанк, дизельпанк, киберпанк) вроде бы нет, но и новизны (особенно у полых миров) тоже нет. Лично мне твоя концепция в целом нравится, но я не вижу в ней каких-то особых преимуществ для игрока, зато хорошо видны недостатки (в основном - технические трудности, но также геймплейные ограничения, баланс ресурсов, рациональное объяснение происходящих в мире игры событий и т.д.).
>спрайт сложнее сделать, чем красивое лоуполи
Ты прав, но я говорил не про сложность графики.
>Полностью цельный, живой и открытый мир может показаться чем-то ужасающе сложным
На практике он и является ужасающие сложным. А ты как думаешь, почему даже самые дорогие ААА игры выходят с декоративной пустышкой вместо живого мира? Всякие TES не сильно ушли от пустых декораций. Живой мир в играх сделать сложнее всего, а у тебя там ещё 9001 механика намечается судя по комбинации мирной жизни с развитием отношений, сражениями с монстрами и даже захватом территорий.
>набор систем-агентов
>набор сущностей-агентов
Ты замучаешься их выдумывать, кодить, а потом балансировать, чтобы твоя живая система не превращалась в выжженную пустыню от лёгкого ветерка, дунувшего на 0.5° в другом направлении.
Не говоря уж о том, что полноценная живая система большого объёма была бы слишком тяжёлой для персонального компьютера, поэтому игры, которые пытаются в живые миры, в конечном итоге режут всё на мелкие декорации с кучей костылей.
>в 2018-ом "свежая" идея
>идеей с доброчана 2010-го
Шутишь что ли? Теории заговора "полой Земли" вроде бы уже несколько веков, были художественные книги, в фильмах что-то похожее было, даже в аниме. Целиком вывернуть весь космос в игре попытались ещё в 90-х, там игра про каких-то роботов была вроде бы и по сюжету мир был состоял из нескольких пузырей в некой тверди. Быстроходные землеройные машины тоже много веков выдумывали и в начале 20-го века даже пытались реализовать, но физика мешает осуществлять движение быстрее сантиметра в час или около того, лол, поэтому ничего быстрее проходческих щитов у нас нет, но пафоса и острых зубов у них достаточно. Всё это так или иначе влияет на людей и их фантазии, особенно у детей, поэтому твоя идея космоса наоборот не была новой даже в 2010.
Просто мало кому интересна такая реализация, вот и не делают. Подумай сам, что даёт тебе полый мир? Ну... Он такой же, как наш, только реки текут "вверх", но если диаметр достаточно большой - кривизну заметить сложно и противоположной стороны вообще не видно. Гравитация тянет тебя к поверхности, а в центре что-то вроде маленькой звезды, поэтому прыжком добраться до другой стороны невозможно. Эстетически красивого космоса со звёздами ночью ты вообще не увидишь. В чём же тогда фан такого мира? А если фана нет, то и реализовывать его смысла нет. Тем более что мир в играх чаще всего не имеет кривизны вообще, а представляет собой плоскость с невидимыми стенами, потому что вычисления физики и навигация на плоскости намного проще, особенно в 3D.
Далее, что даёт твёрдый космос? Огромные расстояния, через которые нужно копать туннели. Теоретически, какие-то ресурсы в огромных количествах. Но ты практически ничего не видишь, кроме скана сонарами и вынужден всё так же сидеть бесконечно долгое время в тарахтящей консервной банке. Никаких боевых ситуаций, манёвров и прочего тут уже не придумаешь, т.к. вокруг тебя плотные стены, разве что землеройные ракеты выпускать, но ты опять же ограничен в знании окружающего мира. Реальный космос тоже скучный, но он хотя бы красивый и даёт много места для добавления интересных игровых условностей, а космос наизнанку скучный, некрасивый и ограничен даже для игровых условностей, если не нарушать базовой установки "твердь вместо вакуума". Реализовать игромеханически такое ещё сложнее, нужны воксели и какой-то способ создать иллюзию бесконечности в любом направлении, что достаточно просто в пустом космосе (далёкие звёзды - спрайты, а всё остальное пространство очевидно пустое и компьютер не грузит). Я вижу, что ты отказался от буквальной реализации и заменил её неким лобби, который будет фактически телепортировать игрока из одного полого мира в другой, но стоило ли вообще тогда придумывать такой вывернутый космос? В чём его привлекательность для игрока?
Я не пытаюсь тебя отговорить, делай что хочешь. Реализовать твои идеи возможно и они не будут выглядеть слишком чужеродными, особенно если все основные механики (движение, бой, диалоги, инвентарь и т.д.) будут привычными. В конце концов, это просто причудливые декорации. Просто особого прикладного смысла в них нет, популярности как романтического сеттинга (стимпанк, дизельпанк, киберпанк) вроде бы нет, но и новизны (особенно у полых миров) тоже нет. Лично мне твоя концепция в целом нравится, но я не вижу в ней каких-то особых преимуществ для игрока, зато хорошо видны недостатки (в основном - технические трудности, но также геймплейные ограничения, баланс ресурсов, рациональное объяснение происходящих в мире игры событий и т.д.).
>>72957
Ты прав, но я говорил не про сложность графики.
На практике он и является ужасающие сложным. А ты как думаешь, почему даже самые дорогие ААА игры выходят с декоративной пустышкой вместо живого мира? Всякие TES не сильно ушли от пустых декораций. Живой мир в играх сделать сложнее всего, а у тебя там ещё 9001 механика намечается судя по комбинации мирной жизни с развитием отношений, сражениями с монстрами и даже захватом территорий.
Ты замучаешься их выдумывать, кодить, а потом балансировать, чтобы твоя живая система не превращалась в выжженную пустыню от лёгкого ветерка, дунувшего на 0.5° в другом направлении.
Не говоря уж о том, что полноценная живая система большого объёма была бы слишком тяжёлой для персонального компьютера, поэтому игры, которые пытаются в живые миры, в конечном итоге режут всё на мелкие декорации с кучей костылей.
Шутишь что ли? Теории заговора "полой Земли" вроде бы уже несколько веков, были художественные книги, в фильмах что-то похожее было, даже в аниме. Целиком вывернуть весь космос в игре попытались ещё в 90-х, там игра про каких-то роботов была вроде бы и по сюжету мир был состоял из нескольких пузырей в некой тверди. Быстроходные землеройные машины тоже много веков выдумывали и в начале 20-го века даже пытались реализовать, но физика мешает осуществлять движение быстрее сантиметра в час или около того, лол, поэтому ничего быстрее проходческих щитов у нас нет, но пафоса и острых зубов у них достаточно. Всё это так или иначе влияет на людей и их фантазии, особенно у детей, поэтому твоя идея космоса наоборот не была новой даже в 2010.
Просто мало кому интересна такая реализация, вот и не делают. Подумай сам, что даёт тебе полый мир? Ну... Он такой же, как наш, только реки текут "вверх", но если диаметр достаточно большой - кривизну заметить сложно и противоположной стороны вообще не видно. Гравитация тянет тебя к поверхности, а в центре что-то вроде маленькой звезды, поэтому прыжком добраться до другой стороны невозможно. Эстетически красивого космоса со звёздами ночью ты вообще не увидишь. В чём же тогда фан такого мира? А если фана нет, то и реализовывать его смысла нет. Тем более что мир в играх чаще всего не имеет кривизны вообще, а представляет собой плоскость с невидимыми стенами, потому что вычисления физики и навигация на плоскости намного проще, особенно в 3D.
Далее, что даёт твёрдый космос? Огромные расстояния, через которые нужно копать туннели. Теоретически, какие-то ресурсы в огромных количествах. Но ты практически ничего не видишь, кроме скана сонарами и вынужден всё так же сидеть бесконечно долгое время в тарахтящей консервной банке. Никаких боевых ситуаций, манёвров и прочего тут уже не придумаешь, т.к. вокруг тебя плотные стены, разве что землеройные ракеты выпускать, но ты опять же ограничен в знании окружающего мира. Реальный космос тоже скучный, но он хотя бы красивый и даёт много места для добавления интересных игровых условностей, а космос наизнанку скучный, некрасивый и ограничен даже для игровых условностей, если не нарушать базовой установки "твердь вместо вакуума". Реализовать игромеханически такое ещё сложнее, нужны воксели и какой-то способ создать иллюзию бесконечности в любом направлении, что достаточно просто в пустом космосе (далёкие звёзды - спрайты, а всё остальное пространство очевидно пустое и компьютер не грузит). Я вижу, что ты отказался от буквальной реализации и заменил её неким лобби, который будет фактически телепортировать игрока из одного полого мира в другой, но стоило ли вообще тогда придумывать такой вывернутый космос? В чём его привлекательность для игрока?
Я не пытаюсь тебя отговорить, делай что хочешь. Реализовать твои идеи возможно и они не будут выглядеть слишком чужеродными, особенно если все основные механики (движение, бой, диалоги, инвентарь и т.д.) будут привычными. В конце концов, это просто причудливые декорации. Просто особого прикладного смысла в них нет, популярности как романтического сеттинга (стимпанк, дизельпанк, киберпанк) вроде бы нет, но и новизны (особенно у полых миров) тоже нет. Лично мне твоя концепция в целом нравится, но я не вижу в ней каких-то особых преимуществ для игрока, зато хорошо видны недостатки (в основном - технические трудности, но также геймплейные ограничения, баланс ресурсов, рациональное объяснение происходящих в мире игры событий и т.д.).
>спрайт сложнее сделать, чем красивое лоуполи
Ты прав, но я говорил не про сложность графики.
>Полностью цельный, живой и открытый мир может показаться чем-то ужасающе сложным
На практике он и является ужасающие сложным. А ты как думаешь, почему даже самые дорогие ААА игры выходят с декоративной пустышкой вместо живого мира? Всякие TES не сильно ушли от пустых декораций. Живой мир в играх сделать сложнее всего, а у тебя там ещё 9001 механика намечается судя по комбинации мирной жизни с развитием отношений, сражениями с монстрами и даже захватом территорий.
>набор систем-агентов
>набор сущностей-агентов
Ты замучаешься их выдумывать, кодить, а потом балансировать, чтобы твоя живая система не превращалась в выжженную пустыню от лёгкого ветерка, дунувшего на 0.5° в другом направлении.
Не говоря уж о том, что полноценная живая система большого объёма была бы слишком тяжёлой для персонального компьютера, поэтому игры, которые пытаются в живые миры, в конечном итоге режут всё на мелкие декорации с кучей костылей.
>в 2018-ом "свежая" идея
>идеей с доброчана 2010-го
Шутишь что ли? Теории заговора "полой Земли" вроде бы уже несколько веков, были художественные книги, в фильмах что-то похожее было, даже в аниме. Целиком вывернуть весь космос в игре попытались ещё в 90-х, там игра про каких-то роботов была вроде бы и по сюжету мир был состоял из нескольких пузырей в некой тверди. Быстроходные землеройные машины тоже много веков выдумывали и в начале 20-го века даже пытались реализовать, но физика мешает осуществлять движение быстрее сантиметра в час или около того, лол, поэтому ничего быстрее проходческих щитов у нас нет, но пафоса и острых зубов у них достаточно. Всё это так или иначе влияет на людей и их фантазии, особенно у детей, поэтому твоя идея космоса наоборот не была новой даже в 2010.
Просто мало кому интересна такая реализация, вот и не делают. Подумай сам, что даёт тебе полый мир? Ну... Он такой же, как наш, только реки текут "вверх", но если диаметр достаточно большой - кривизну заметить сложно и противоположной стороны вообще не видно. Гравитация тянет тебя к поверхности, а в центре что-то вроде маленькой звезды, поэтому прыжком добраться до другой стороны невозможно. Эстетически красивого космоса со звёздами ночью ты вообще не увидишь. В чём же тогда фан такого мира? А если фана нет, то и реализовывать его смысла нет. Тем более что мир в играх чаще всего не имеет кривизны вообще, а представляет собой плоскость с невидимыми стенами, потому что вычисления физики и навигация на плоскости намного проще, особенно в 3D.
Далее, что даёт твёрдый космос? Огромные расстояния, через которые нужно копать туннели. Теоретически, какие-то ресурсы в огромных количествах. Но ты практически ничего не видишь, кроме скана сонарами и вынужден всё так же сидеть бесконечно долгое время в тарахтящей консервной банке. Никаких боевых ситуаций, манёвров и прочего тут уже не придумаешь, т.к. вокруг тебя плотные стены, разве что землеройные ракеты выпускать, но ты опять же ограничен в знании окружающего мира. Реальный космос тоже скучный, но он хотя бы красивый и даёт много места для добавления интересных игровых условностей, а космос наизнанку скучный, некрасивый и ограничен даже для игровых условностей, если не нарушать базовой установки "твердь вместо вакуума". Реализовать игромеханически такое ещё сложнее, нужны воксели и какой-то способ создать иллюзию бесконечности в любом направлении, что достаточно просто в пустом космосе (далёкие звёзды - спрайты, а всё остальное пространство очевидно пустое и компьютер не грузит). Я вижу, что ты отказался от буквальной реализации и заменил её неким лобби, который будет фактически телепортировать игрока из одного полого мира в другой, но стоило ли вообще тогда придумывать такой вывернутый космос? В чём его привлекательность для игрока?
Я не пытаюсь тебя отговорить, делай что хочешь. Реализовать твои идеи возможно и они не будут выглядеть слишком чужеродными, особенно если все основные механики (движение, бой, диалоги, инвентарь и т.д.) будут привычными. В конце концов, это просто причудливые декорации. Просто особого прикладного смысла в них нет, популярности как романтического сеттинга (стимпанк, дизельпанк, киберпанк) вроде бы нет, но и новизны (особенно у полых миров) тоже нет. Лично мне твоя концепция в целом нравится, но я не вижу в ней каких-то особых преимуществ для игрока, зато хорошо видны недостатки (в основном - технические трудности, но также геймплейные ограничения, баланс ресурсов, рациональное объяснение происходящих в мире игры событий и т.д.).
>>72959
Общепризнанный за счёт синдрома утёнка.
Зачем? Это антипаттерн. Такой код сложно читать.
Зачем? ЗАЧЕМ? ЗАЧЕЕЕЕМ? Ты что, быдлокодер?
Ты забыл про Forth-подобные:
Эта имба настолько мощная, что о ней боятся даже говорить, ведь тогда весь мирок кококодерков рухнет в один час: 100 кодерков могут быть легко заменены всего 1 фортистом, а для кодогенерирующей нейронки это будет вообще турбоускоритель. И это не говоря о том, что компилятор и одновременно рабочая среда Форта для любой физической платформы пишется за пару часов и может уместиться в полкилобайта загрузочного сектора, а ещё существует возможность создавать физические процессоры Форта, позволяющие реализовать 100500 независимых физических ядер уровня полноценного центрального процессора, о чём видимокарты с их бездушными ядрами-огрызками могут только мечтать.
Но откуда вам, утятам, такое знать и понимать... Утят научили сиподобному синтаксису и вот теперь мы живём в антиутопии, в которой все дрочат на DLL библиотеку весом больше гигабайта для запуска нейросетей на убогом графическом ускорителе.
>>72974
Скобочки формируют менталитет программистов.
Проще говоря, растисты точно так же как сишники склонны записывать свой код в одну строчку из максимально коротких обозрачений, как правило одно- и двухбуквенных, реже трёхбуквенных.
Вон, чуть выше тебя сишник уже высказался о том, как ему жизненно необходимо записывать большое количество инструкций на одной строке, которую он, конечно, не будет скроллить, но не из-за ультравайд монитора, а потому что у него всего операторы из 3 букв и он может уместить 9001 таких обрезков на одной строке на специально для этого приобретённом им ультравайд мониторе, выводя код 8-пунктовым шрифтом для максимально эффективного использования ширины экрана. Зачем? Не знаю, наверное, кончает радугой при виде таких записей? Практической пользы от этого, разумеется, нет, иначе он бы сразу пояснил, зачем ему такое извращение нужно на практике и как он компенсирует недостатки использования таких записей.
>Скобки - это общепризнанный шаблон
Общепризнанный за счёт синдрома утёнка.
>как в одну строку записать несколько операторов
Зачем? Это антипаттерн. Такой код сложно читать.
>выделить надо в одну строку
Зачем? ЗАЧЕМ? ЗАЧЕЕЕЕМ? Ты что, быдлокодер?
>Сиподобные
>Паскалеподобные
>Питоноподобные
>Бейсикоподобные
>Шеллскриптподобные
Ты забыл про Forth-подобные:
>op34: op3 op4 ; op125: op1 op2 op34 op5 ; op125
Эта имба настолько мощная, что о ней боятся даже говорить, ведь тогда весь мирок кококодерков рухнет в один час: 100 кодерков могут быть легко заменены всего 1 фортистом, а для кодогенерирующей нейронки это будет вообще турбоускоритель. И это не говоря о том, что компилятор и одновременно рабочая среда Форта для любой физической платформы пишется за пару часов и может уместиться в полкилобайта загрузочного сектора, а ещё существует возможность создавать физические процессоры Форта, позволяющие реализовать 100500 независимых физических ядер уровня полноценного центрального процессора, о чём видимокарты с их бездушными ядрами-огрызками могут только мечтать.
Но откуда вам, утятам, такое знать и понимать... Утят научили сиподобному синтаксису и вот теперь мы живём в антиутопии, в которой все дрочат на DLL библиотеку весом больше гигабайта для запуска нейросетей на убогом графическом ускорителе.
>>72974
>Язык это не только скобочки.
Скобочки формируют менталитет программистов.
>Фигурные скобочки это топ, потому что позволяют однозначно показать блок кода, занимают всего 1 символ, и не полагаются на табы
Проще говоря, растисты точно так же как сишники склонны записывать свой код в одну строчку из максимально коротких обозрачений, как правило одно- и двухбуквенных, реже трёхбуквенных.
Вон, чуть выше тебя сишник уже высказался о том, как ему жизненно необходимо записывать большое количество инструкций на одной строке, которую он, конечно, не будет скроллить, но не из-за ультравайд монитора, а потому что у него всего операторы из 3 букв и он может уместить 9001 таких обрезков на одной строке на специально для этого приобретённом им ультравайд мониторе, выводя код 8-пунктовым шрифтом для максимально эффективного использования ширины экрана. Зачем? Не знаю, наверное, кончает радугой при виде таких записей? Практической пользы от этого, разумеется, нет, иначе он бы сразу пояснил, зачем ему такое извращение нужно на практике и как он компенсирует недостатки использования таких записей.
>>72959
Общепризнанный за счёт синдрома утёнка.
Зачем? Это антипаттерн. Такой код сложно читать.
Зачем? ЗАЧЕМ? ЗАЧЕЕЕЕМ? Ты что, быдлокодер?
Ты забыл про Forth-подобные:
Эта имба настолько мощная, что о ней боятся даже говорить, ведь тогда весь мирок кококодерков рухнет в один час: 100 кодерков могут быть легко заменены всего 1 фортистом, а для кодогенерирующей нейронки это будет вообще турбоускоритель. И это не говоря о том, что компилятор и одновременно рабочая среда Форта для любой физической платформы пишется за пару часов и может уместиться в полкилобайта загрузочного сектора, а ещё существует возможность создавать физические процессоры Форта, позволяющие реализовать 100500 независимых физических ядер уровня полноценного центрального процессора, о чём видимокарты с их бездушными ядрами-огрызками могут только мечтать.
Но откуда вам, утятам, такое знать и понимать... Утят научили сиподобному синтаксису и вот теперь мы живём в антиутопии, в которой все дрочат на DLL библиотеку весом больше гигабайта для запуска нейросетей на убогом графическом ускорителе.
>>72974
Скобочки формируют менталитет программистов.
Проще говоря, растисты точно так же как сишники склонны записывать свой код в одну строчку из максимально коротких обозрачений, как правило одно- и двухбуквенных, реже трёхбуквенных.
Вон, чуть выше тебя сишник уже высказался о том, как ему жизненно необходимо записывать большое количество инструкций на одной строке, которую он, конечно, не будет скроллить, но не из-за ультравайд монитора, а потому что у него всего операторы из 3 букв и он может уместить 9001 таких обрезков на одной строке на специально для этого приобретённом им ультравайд мониторе, выводя код 8-пунктовым шрифтом для максимально эффективного использования ширины экрана. Зачем? Не знаю, наверное, кончает радугой при виде таких записей? Практической пользы от этого, разумеется, нет, иначе он бы сразу пояснил, зачем ему такое извращение нужно на практике и как он компенсирует недостатки использования таких записей.
>Скобки - это общепризнанный шаблон
Общепризнанный за счёт синдрома утёнка.
>как в одну строку записать несколько операторов
Зачем? Это антипаттерн. Такой код сложно читать.
>выделить надо в одну строку
Зачем? ЗАЧЕМ? ЗАЧЕЕЕЕМ? Ты что, быдлокодер?
>Сиподобные
>Паскалеподобные
>Питоноподобные
>Бейсикоподобные
>Шеллскриптподобные
Ты забыл про Forth-подобные:
>op34: op3 op4 ; op125: op1 op2 op34 op5 ; op125
Эта имба настолько мощная, что о ней боятся даже говорить, ведь тогда весь мирок кококодерков рухнет в один час: 100 кодерков могут быть легко заменены всего 1 фортистом, а для кодогенерирующей нейронки это будет вообще турбоускоритель. И это не говоря о том, что компилятор и одновременно рабочая среда Форта для любой физической платформы пишется за пару часов и может уместиться в полкилобайта загрузочного сектора, а ещё существует возможность создавать физические процессоры Форта, позволяющие реализовать 100500 независимых физических ядер уровня полноценного центрального процессора, о чём видимокарты с их бездушными ядрами-огрызками могут только мечтать.
Но откуда вам, утятам, такое знать и понимать... Утят научили сиподобному синтаксису и вот теперь мы живём в антиутопии, в которой все дрочат на DLL библиотеку весом больше гигабайта для запуска нейросетей на убогом графическом ускорителе.
>>72974
>Язык это не только скобочки.
Скобочки формируют менталитет программистов.
>Фигурные скобочки это топ, потому что позволяют однозначно показать блок кода, занимают всего 1 символ, и не полагаются на табы
Проще говоря, растисты точно так же как сишники склонны записывать свой код в одну строчку из максимально коротких обозрачений, как правило одно- и двухбуквенных, реже трёхбуквенных.
Вон, чуть выше тебя сишник уже высказался о том, как ему жизненно необходимо записывать большое количество инструкций на одной строке, которую он, конечно, не будет скроллить, но не из-за ультравайд монитора, а потому что у него всего операторы из 3 букв и он может уместить 9001 таких обрезков на одной строке на специально для этого приобретённом им ультравайд мониторе, выводя код 8-пунктовым шрифтом для максимально эффективного использования ширины экрана. Зачем? Не знаю, наверное, кончает радугой при виде таких записей? Практической пользы от этого, разумеется, нет, иначе он бы сразу пояснил, зачем ему такое извращение нужно на практике и как он компенсирует недостатки использования таких записей.
>>72994
Ну у тебя и вкус, анон... Не хочу обижать, но... ты понял.
>глаза расставлены шире ширины одного глаза
>нос
>НОС
>Н О С
>Н
>О
>С
>нос с ноздрями
>сплюснутый нос с ноздрями
>сплюснутый нос с ноздрями у аниме-тян
Ну у тебя и вкус, анон... Не хочу обижать, но... ты понял.
>>73000
С момента появления треда?
С момента появления треда?
99 Кб, 1280x720>>73003
Вот забирай её себе, женись и никому не показывай. Особенно нам. Особенно в шапке треда. Спасибо.
Пикрил можешь взять любовницей.
>нашел эту няшку раньше тебя
Вот забирай её себе, женись и никому не показывай. Особенно нам. Особенно в шапке треда. Спасибо.
Пикрил можешь взять любовницей.
>>74218
фантазер)
фантазер)