Этого треда уже нет.
Это копия, сохраненная 1 декабря 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 декабря 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
14 Кб, 225x225Добро пожаловать в тред любви, взаимопомощи, весны и труда, криков душ!
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/3.4.rc1/godot.tools.html с дивана нельзя.
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: 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
Библиотека готовых шейдеров: https://godotshaders.com
Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
Конвертор кваковских карт для ностальгирующих дидов: 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://godotengine.org/asset-library/asset/1171 в сочетании с CSGMesh позволяет создавать архитектуру любой сложности без задней мысли.
Книги
Книги в 21 веке всё равно никто не читает, поэтому вот вам две рандомные из гугла:
https://play.google.com/store/books/details/Godot_Engine_Game_Development_in_24_Hours_Sams_Tea
https://play.google.com/store/books/details/Chris_Bradfield_Godot_Engine_Game_Development_Proj
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>792905 (OP)
Архивный: https://arhivach.ng/thread/786128/
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/3.4.rc1/godot.tools.html с дивана нельзя.
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: 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
Библиотека готовых шейдеров: https://godotshaders.com
Майндмаппинг проектов не отходя от кассы: https://godotengine.org/asset-library/asset/879
SmartShape для рисования 2D-террейнов без задней мысли: https://godotengine.org/asset-library/asset/715
Конвертор кваковских карт для ностальгирующих дидов: 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://godotengine.org/asset-library/asset/1171 в сочетании с CSGMesh позволяет создавать архитектуру любой сложности без задней мысли.
Книги
Книги в 21 веке всё равно никто не читает, поэтому вот вам две рандомные из гугла:
https://play.google.com/store/books/details/Godot_Engine_Game_Development_in_24_Hours_Sams_Tea
https://play.google.com/store/books/details/Chris_Bradfield_Godot_Engine_Game_Development_Proj
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>792905 (OP)
Архивный: https://arhivach.ng/thread/786128/
Обнаружил отсутствие возможности рекурсивного удаления директории и её содержимого. Вместо понятного удаления одного пути пришлось собирать и удалять сперва все файлы, а потом удалять все директории. Я могу понять такое ограничение в рамках res://, но в рамкаах user:// - это перебор. Шансов ошибиться и удалить лишнего - сильно больше.
>>00504
Ты требуешь от игрового движка операционной системности? Не много ли требуешь?
Но в принципе, в гдскрипте есть OS.execute()
Если нужно не только запускать процессы, но и управлять ими, тогда только через шарп.
>The subprocess module allows you to spawn new processes, connect to their input/output/error pipes, and obtain their return codes.
Ты требуешь от игрового движка операционной системности? Не много ли требуешь?
Но в принципе, в гдскрипте есть OS.execute()
Если нужно не только запускать процессы, но и управлять ими, тогда только через шарп.
>>00647
Причем тут треды, если ему нужно запускать процесс в системе?
Причем тут треды, если ему нужно запускать процесс в системе?
>>800277 →
Потому что get_node() в реальном проекте может очень часто возвращать null и это нормально, это часть алгоритма. Просто твой код должен делать проверки на null и самостоятельно предпринять решения: пропустить участок кода, выполнить что-то другое, вывести ошибку и т.д. Всё сильно зависит от ситуации.
>>800172 →
Я пробовал. Проблемы: подскоки на стыках и рёбрах могут быть не просто заметными, а ощутимо большими; второе - не ясно, как всё-таки нейтрализовать скорость, иначе игрок будет ускоряться и тормозить медленно; третье - не ясно, как сделать нормальный шаг на выступ типа бордюра, не подбрасывая игрока в мини-прыжок. Долго игрался с параметрами, плюнул и вернулся на кинематикбоди, надеясь, что его когда-нибудь допилят. Алсо напоминаю, что мы не имеем прямого доступа к актуальной позиции ригидбоди, .origin может хранить что угодно, кроме актуальной позиции. Это может ломать логику игры и погружать в поиск ошибок, которых нет...
Это очевидно. Но от кинематика не требуется чего-то такого уж прям сверхсложного. Просто работать без глюков.
Давно заметил, что ригидбоди падают с каким-то другим ускорением, чем кинематик, даже когда используешь G из параметров проекта. Не так уж критично, но бесит это видеть.
>Почему нельзя нормально написать, что-то типа node not found?
Потому что get_node() в реальном проекте может очень часто возвращать null и это нормально, это часть алгоритма. Просто твой код должен делать проверки на null и самостоятельно предпринять решения: пропустить участок кода, выполнить что-то другое, вывести ошибку и т.д. Всё сильно зависит от ситуации.
>>800172 →
>юзать RigidBody
Я пробовал. Проблемы: подскоки на стыках и рёбрах могут быть не просто заметными, а ощутимо большими; второе - не ясно, как всё-таки нейтрализовать скорость, иначе игрок будет ускоряться и тормозить медленно; третье - не ясно, как сделать нормальный шаг на выступ типа бордюра, не подбрасывая игрока в мини-прыжок. Долго игрался с параметрами, плюнул и вернулся на кинематикбоди, надеясь, что его когда-нибудь допилят. Алсо напоминаю, что мы не имеем прямого доступа к актуальной позиции ригидбоди, .origin может хранить что угодно, кроме актуальной позиции. Это может ломать логику игры и погружать в поиск ошибок, которых нет...
>чем проще инструмент, чем более доступным он кажется, тем менее он функционален.
Это очевидно. Но от кинематика не требуется чего-то такого уж прям сверхсложного. Просто работать без глюков.
>гравитация
Давно заметил, что ригидбоди падают с каким-то другим ускорением, чем кинематик, даже когда используешь G из параметров проекта. Не так уж критично, но бесит это видеть.
>>00927
Массу правильно настраивал? Первая ошибка пытающихся работать с физической симуляцией - не расставлять массы предметам. Всё вокруг весит 1 кг. И пушинка, и машинка, и бачок, и пятачок. Ля, стихами заговорил.
Это главная тайна физической симуляции (любой, но у нас буллет по дефолту), которая в общем-то и не тайна, но неочевидно. Итак, присядьте, держитесь за подлокотники. Щас я вам открою главную тайну. На тело действуют силы, которые толкают его в некотором направлении. По умолчанию на каждое тело действует сила тяжести (которую традиционно называем гравитацией, но это не совсем верно, гравитация не сила, но из-за гравитации возникает сила тяжести, которая выступает в физической симуляции под именем гравитации) и если ты не выключил гравитацию в настройках. Это как если бы каждому телу, как только оно входит в дерево выполняется метод add_force(gravity_vector) - так вот самая тайна заключается в том, что метод add_force() одноразовый. Его не следует выполнять в цикле. Ты один раз накладываешь силу, которая действует.
Таким образом, в интеграторе сил тебе следует своевременно пересматривать, какие силы продолжают действовать на тело, а какие нет, совершать пересчёт (складывать все вектора сил) и присваивать телу.
Импульсы!
При помощи импульсов можно быстро разгонять или тормозить тела. В отличие от наложения сил, наложение импульсов может выполняться в цикле. Что логично по школьному определению импульса.
Импульсы для симуляции реактивного движения накладываем через apply_impulse() для резких прыжков есть велосипедистый метод set_axis_velocity().
Для симуляции колеса просто вешаешь на джойнте колесо и придаёшь ему вращательный импульс apply_torque()
В общем, когда разбираешься в том, как всё работает в физическом движке, кинематикбоди становится не интересен с его глюками.
> подскоки на стыках и рёбрах могут быть не просто заметными, а ощутимо большими
Массу правильно настраивал? Первая ошибка пытающихся работать с физической симуляцией - не расставлять массы предметам. Всё вокруг весит 1 кг. И пушинка, и машинка, и бачок, и пятачок. Ля, стихами заговорил.
> не ясно, как всё-таки нейтрализовать скорость
Это главная тайна физической симуляции (любой, но у нас буллет по дефолту), которая в общем-то и не тайна, но неочевидно. Итак, присядьте, держитесь за подлокотники. Щас я вам открою главную тайну. На тело действуют силы, которые толкают его в некотором направлении. По умолчанию на каждое тело действует сила тяжести (которую традиционно называем гравитацией, но это не совсем верно, гравитация не сила, но из-за гравитации возникает сила тяжести, которая выступает в физической симуляции под именем гравитации) и если ты не выключил гравитацию в настройках. Это как если бы каждому телу, как только оно входит в дерево выполняется метод add_force(gravity_vector) - так вот самая тайна заключается в том, что метод add_force() одноразовый. Его не следует выполнять в цикле. Ты один раз накладываешь силу, которая действует.
Таким образом, в интеграторе сил тебе следует своевременно пересматривать, какие силы продолжают действовать на тело, а какие нет, совершать пересчёт (складывать все вектора сил) и присваивать телу.
> иначе игрок будет ускоряться и тормозить медленно
Импульсы!
При помощи импульсов можно быстро разгонять или тормозить тела. В отличие от наложения сил, наложение импульсов может выполняться в цикле. Что логично по школьному определению импульса.
Импульсы для симуляции реактивного движения накладываем через apply_impulse() для резких прыжков есть велосипедистый метод set_axis_velocity().
Для симуляции колеса просто вешаешь на джойнте колесо и придаёшь ему вращательный импульс apply_torque()
В общем, когда разбираешься в том, как всё работает в физическом движке, кинематикбоди становится не интересен с его глюками.
>>00929
Пробовал в своё время ставить массу 75 игроку. Не помню, на что повлияло, но не суть. Отскоки от границ коллайдеров - это баг движка, такого не должно быть даже с минимальной массой. Сразу скажу, что прятать границы не всегда возможно: во-первых, если карта составляется из каких-либо модулей, во-вторых, если игрок может прыжками добираться до каких-то платформ. Мне на тестовой сцене удавалось как-то распрыгаться до высоких скал, хотя по всей логике кода это не должно было быть доступно... Единственный выход - забить и оставить как есть, но это тяжело.
Странное замечание, кто будет прикладывать одну и ту же силу несколько раз? Или она там вообще глобальная, и каждый новый вызов полностью отменяет всё остальное? Тогда да, херня какая-то, совершенно не соответствует своему названию.
Ну типа вот игрок жмёт W, это определяет вектор движения, затем в одном месте происходит add_force(direction), и персонаж начинает... ускоряться, пока игрок зажимает W. А когда игрок отпускает клавишу, персонаж начинает замедляться.
Вот этого я вообще не понимаю, у меня импульсы нормально не работали и я не смог никак скомпенсировать торможение. Наверное, там сложно посчитать точную формулу? Вот если игрок движется по оси X+, нужно для резкой остановки дать импульс, компенсирующий движение в обратном направлении X-. С движением по прямой это в теории работает просто, но компенсировать нужно по всем трём осям, за исключением силы тяжести...
Ещё и интегратор какой-то зачем-то нужен, что он делает кроме того, что отключает стандартное поведение? По-моему, он ничем не отличается от процесса физики, разве что будет безопаснее на каких-то гипотетических конфигурациях...
Короче, всё это слишком сложно. Ускоряешь несчастную капсулу - она берёт разгон как ракета и изменить это нельзя. Пытаешься отобрать у неё хотя бы медленное торможение - начинаются странные глюки, возможно, из-за ошибок округления или чего-то такого. Страшно подумать о введение дополнительных функций персонажа...
>Всё вокруг весит 1 кг
Пробовал в своё время ставить массу 75 игроку. Не помню, на что повлияло, но не суть. Отскоки от границ коллайдеров - это баг движка, такого не должно быть даже с минимальной массой. Сразу скажу, что прятать границы не всегда возможно: во-первых, если карта составляется из каких-либо модулей, во-вторых, если игрок может прыжками добираться до каких-то платформ. Мне на тестовой сцене удавалось как-то распрыгаться до высоких скал, хотя по всей логике кода это не должно было быть доступно... Единственный выход - забить и оставить как есть, но это тяжело.
>метод add_force() одноразовый. Его не следует выполнять в цикле
Странное замечание, кто будет прикладывать одну и ту же силу несколько раз? Или она там вообще глобальная, и каждый новый вызов полностью отменяет всё остальное? Тогда да, херня какая-то, совершенно не соответствует своему названию.
Ну типа вот игрок жмёт W, это определяет вектор движения, затем в одном месте происходит add_force(direction), и персонаж начинает... ускоряться, пока игрок зажимает W. А когда игрок отпускает клавишу, персонаж начинает замедляться.
>Импульсы!
>При помощи импульсов можно быстро разгонять
>apply_impulse()
Вот этого я вообще не понимаю, у меня импульсы нормально не работали и я не смог никак скомпенсировать торможение. Наверное, там сложно посчитать точную формулу? Вот если игрок движется по оси X+, нужно для резкой остановки дать импульс, компенсирующий движение в обратном направлении X-. С движением по прямой это в теории работает просто, но компенсировать нужно по всем трём осям, за исключением силы тяжести...
Ещё и интегратор какой-то зачем-то нужен, что он делает кроме того, что отключает стандартное поведение? По-моему, он ничем не отличается от процесса физики, разве что будет безопаснее на каких-то гипотетических конфигурациях...
Короче, всё это слишком сложно. Ускоряешь несчастную капсулу - она берёт разгон как ракета и изменить это нельзя. Пытаешься отобрать у неё хотя бы медленное торможение - начинаются странные глюки, возможно, из-за ошибок округления или чего-то такого. Страшно подумать о введение дополнительных функций персонажа...
>>00929
Пробовал в своё время ставить массу 75 игроку. Не помню, на что повлияло, но не суть. Отскоки от границ коллайдеров - это баг движка, такого не должно быть даже с минимальной массой. Сразу скажу, что прятать границы не всегда возможно: во-первых, если карта составляется из каких-либо модулей, во-вторых, если игрок может прыжками добираться до каких-то платформ. Мне на тестовой сцене удавалось как-то распрыгаться до высоких скал, хотя по всей логике кода это не должно было быть доступно... Единственный выход - забить и оставить как есть, но это тяжело.
Странное замечание, кто будет прикладывать одну и ту же силу несколько раз? Или она там вообще глобальная, и каждый новый вызов полностью отменяет всё остальное? Тогда да, херня какая-то, совершенно не соответствует своему названию.
Ну типа вот игрок жмёт W, это определяет вектор движения, затем в одном месте происходит add_force(direction), и персонаж начинает... ускоряться, пока игрок зажимает W. А когда игрок отпускает клавишу, персонаж начинает замедляться.
Вот этого я вообще не понимаю, у меня импульсы нормально не работали и я не смог никак скомпенсировать торможение. Наверное, там сложно посчитать точную формулу? Вот если игрок движется по оси X+, нужно для резкой остановки дать импульс, компенсирующий движение в обратном направлении X-. С движением по прямой это в теории работает просто, но компенсировать нужно по всем трём осям, за исключением силы тяжести...
Ещё и интегратор какой-то зачем-то нужен, что он делает кроме того, что отключает стандартное поведение? По-моему, он ничем не отличается от процесса физики, разве что будет безопаснее на каких-то гипотетических конфигурациях...
Короче, всё это слишком сложно. Ускоряешь несчастную капсулу - она берёт разгон как ракета и изменить это нельзя. Пытаешься отобрать у неё хотя бы медленное торможение - начинаются странные глюки, возможно, из-за ошибок округления или чего-то такого. Страшно подумать о введение дополнительных функций персонажа...
>Всё вокруг весит 1 кг
Пробовал в своё время ставить массу 75 игроку. Не помню, на что повлияло, но не суть. Отскоки от границ коллайдеров - это баг движка, такого не должно быть даже с минимальной массой. Сразу скажу, что прятать границы не всегда возможно: во-первых, если карта составляется из каких-либо модулей, во-вторых, если игрок может прыжками добираться до каких-то платформ. Мне на тестовой сцене удавалось как-то распрыгаться до высоких скал, хотя по всей логике кода это не должно было быть доступно... Единственный выход - забить и оставить как есть, но это тяжело.
>метод add_force() одноразовый. Его не следует выполнять в цикле
Странное замечание, кто будет прикладывать одну и ту же силу несколько раз? Или она там вообще глобальная, и каждый новый вызов полностью отменяет всё остальное? Тогда да, херня какая-то, совершенно не соответствует своему названию.
Ну типа вот игрок жмёт W, это определяет вектор движения, затем в одном месте происходит add_force(direction), и персонаж начинает... ускоряться, пока игрок зажимает W. А когда игрок отпускает клавишу, персонаж начинает замедляться.
>Импульсы!
>При помощи импульсов можно быстро разгонять
>apply_impulse()
Вот этого я вообще не понимаю, у меня импульсы нормально не работали и я не смог никак скомпенсировать торможение. Наверное, там сложно посчитать точную формулу? Вот если игрок движется по оси X+, нужно для резкой остановки дать импульс, компенсирующий движение в обратном направлении X-. С движением по прямой это в теории работает просто, но компенсировать нужно по всем трём осям, за исключением силы тяжести...
Ещё и интегратор какой-то зачем-то нужен, что он делает кроме того, что отключает стандартное поведение? По-моему, он ничем не отличается от процесса физики, разве что будет безопаснее на каких-то гипотетических конфигурациях...
Короче, всё это слишком сложно. Ускоряешь несчастную капсулу - она берёт разгон как ракета и изменить это нельзя. Пытаешься отобрать у неё хотя бы медленное торможение - начинаются странные глюки, возможно, из-за ошибок округления или чего-то такого. Страшно подумать о введение дополнительных функций персонажа...
39 Кб, 783x188>>00955
Ответ на странное высказывание:
>>00929
Из него возникает ощущение, что анон накладывает одну и ту же силу.
>>00955
Например так, пикрелейтед. Конечно двадэ, но в триде суть та же.
А ты как думал? Именно поэтому в космос могут не все.
> Странное замечание
Ответ на странное высказывание:
>>00929
> не ясно, как всё-таки нейтрализовать скорость
Из него возникает ощущение, что анон накладывает одну и ту же силу.
>>00955
> Вот этого я вообще не понимаю, у меня импульсы нормально не работали и я не смог никак скомпенсировать торможение. Наверное, там сложно посчитать точную формулу?
Например так, пикрелейтед. Конечно двадэ, но в триде суть та же.
> Короче, всё это слишком сложно.
А ты как думал? Именно поэтому в космос могут не все.
Анончики, помогите!
Сделал контроллер персонажа от первого лица, но его трясет на стыках 2х разных объектов, у которых свои отдельные collosionShape. Сами эти объекты идентичные, просветов нигде нет, все стык в стык сделано по снапам. Можно ли это исправить и сделать так, чтобы пол гладкий? Неужели можно забыть о модульности и выстилать полы одной большой плоскостью с коллизией?
Вот сам контроллер: https://github.com/Rayuse/fps-controller-tutorial/blob/main/player/player.gd
Сделал контроллер персонажа от первого лица, но его трясет на стыках 2х разных объектов, у которых свои отдельные collosionShape. Сами эти объекты идентичные, просветов нигде нет, все стык в стык сделано по снапам. Можно ли это исправить и сделать так, чтобы пол гладкий? Неужели можно забыть о модульности и выстилать полы одной большой плоскостью с коллизией?
Вот сам контроллер: https://github.com/Rayuse/fps-controller-tutorial/blob/main/player/player.gd
>>00960 (Del)
Ясно, так и должны были называть с самого начала.
apply - применить (как кнопка в окошках Windows)
add - добавить в какой-то внутренний список
Я этого так и не могу понять. Если add_force() сбрасывается в 0 после каждого кадра, то чем он отличается от импульса? Это же не постоянная сила, как гравитация, например. Я так понимаю, что разница должна быть зарыта где-то в дельте кадра... А то что эффект разный я и так на практике видел, только не смог этим никак воспользоваться, поэтому отказался от импульсов совсем.
Ну это уж совсем костыльный костыль, который, скорее всего, принесёт больше проблем, чем выгоды. Проще, наверное, сделать стыки визуально заметными, чтобы игрок понимал причину этих случайных подскоков. Не баг, а фича! Хотя с резкими прыжками при напрыгивании на угол коллайдера я, кажется, так и не справился (уже не помню, полгода назад дело было, неуловимость этих проблем выводила меня из себя, всё бросил и переключился на другое).
Вообще, пофиг, последние два месяца вообще ничего не делаю, валяюсь в депрессии и думаю о смысле жизни, какие тут игры...
>>00963
Ну да, как-то так, наверное, я и пробовал. Но результат был очень нестабильным и пришлось от него отказаться. Выбирая между "плавный разгон с плавным торможением" и "непредсказуемая встряска, подскоки, глюки" я предпочёл плавное движение. Ну, это не вина движка, скорее всего в моём подходе была ошибка. Хотя хотелось бы, конечно, иметь больше контроля, чтобы вот просто взял и сделал velocity = Vector3.ZERO, без этой магии с противоположными движению толчками, которые рандомно глючат.
>apply_force, а не add_force
Ясно, так и должны были называть с самого начала.
apply - применить (как кнопка в окошках Windows)
add - добавить в какой-то внутренний список
>Разница в том, что силу пересчитывают на секунды, а импульс нет, он работает за физический тик.
Я этого так и не могу понять. Если add_force() сбрасывается в 0 после каждого кадра, то чем он отличается от импульса? Это же не постоянная сила, как гравитация, например. Я так понимаю, что разница должна быть зарыта где-то в дельте кадра... А то что эффект разный я и так на практике видел, только не смог этим никак воспользоваться, поэтому отказался от импульсов совсем.
>делать воркэраунд на уровне чарактер контроллера - что то вроде логики "если произошло подскакивание, и оно произошло не из-за прыжка, и рейкаст показывает стык - отменить подскакивание и продолжить прямолинейное движение".
Ну это уж совсем костыльный костыль, который, скорее всего, принесёт больше проблем, чем выгоды. Проще, наверное, сделать стыки визуально заметными, чтобы игрок понимал причину этих случайных подскоков. Не баг, а фича! Хотя с резкими прыжками при напрыгивании на угол коллайдера я, кажется, так и не справился (уже не помню, полгода назад дело было, неуловимость этих проблем выводила меня из себя, всё бросил и переключился на другое).
Вообще, пофиг, последние два месяца вообще ничего не делаю, валяюсь в депрессии и думаю о смысле жизни, какие тут игры...
>>00963
Ну да, как-то так, наверное, я и пробовал. Но результат был очень нестабильным и пришлось от него отказаться. Выбирая между "плавный разгон с плавным торможением" и "непредсказуемая встряска, подскоки, глюки" я предпочёл плавное движение. Ну, это не вина движка, скорее всего в моём подходе была ошибка. Хотя хотелось бы, конечно, иметь больше контроля, чтобы вот просто взял и сделал velocity = Vector3.ZERO, без этой магии с противоположными движению толчками, которые рандомно глючат.
>>00990
Ты удивишься, но "одной большой плоскостью" делать нельзя, потому что физический движок начинает КОЛБАСИТЬ всё, что попадает на более-менее большой объект (сотни метров в длину). То есть даже если у тебя попенволд плоское поле, изволь делить на квадратики, иначе расколбасит до неиграбельности. Проблема, скорее всего, из-за вычислений с плавающей точкой.
Однако, модульность делать можно. Я сам делал в нескольких вариантах. Проблема стыков, несомненно, существует, как раз вот снова начали обсуждать. Но лично у меня нет вибрации на стыках, есть только одиночные едва заметные (зависящие от скорости движения по плоскости) подпрыгивания, которые хоть и не часто заметны, но очень напрягают, когда замечаешь.
Попробуй добавить в качестве одного из коллиженшейпов игрока обычный рейкаст вниз, если у тебя там простая капсула. Также попробуй увеличить safe_margin коллайдера игрока, это помогает с некоторыми взаимодействиями. Ну и да, нужно код контроллера перечитать и максимально упростить, мне сейчас лень смотреть на этот код. Самый базовый контроллер из 3.5 строчек не должен вибрировать на стыках так, как у тебя на видео.
>>01008
Ого, у нас тут путешественник во времени?!
>Неужели можно забыть о модульности и выстилать полы одной большой плоскостью с коллизией?
Ты удивишься, но "одной большой плоскостью" делать нельзя, потому что физический движок начинает КОЛБАСИТЬ всё, что попадает на более-менее большой объект (сотни метров в длину). То есть даже если у тебя попенволд плоское поле, изволь делить на квадратики, иначе расколбасит до неиграбельности. Проблема, скорее всего, из-за вычислений с плавающей точкой.
Однако, модульность делать можно. Я сам делал в нескольких вариантах. Проблема стыков, несомненно, существует, как раз вот снова начали обсуждать. Но лично у меня нет вибрации на стыках, есть только одиночные едва заметные (зависящие от скорости движения по плоскости) подпрыгивания, которые хоть и не часто заметны, но очень напрягают, когда замечаешь.
Попробуй добавить в качестве одного из коллиженшейпов игрока обычный рейкаст вниз, если у тебя там простая капсула. Также попробуй увеличить safe_margin коллайдера игрока, это помогает с некоторыми взаимодействиями. Ну и да, нужно код контроллера перечитать и максимально упростить, мне сейчас лень смотреть на этот код. Самый базовый контроллер из 3.5 строчек не должен вибрировать на стыках так, как у тебя на видео.
>>01008
>Такое ощущение, что ты скопипиздил код из
>Rayuse committed on 12 Aug 2021
Ого, у нас тут путешественник во времени?!
>>01008
Я посмотрел.
Здесь выбираются все тела, с которыми столкнулся кинематикбоди, а затем тем из них, что принадлежат к группе bodies, придаётся импульс, направленный в противоположную от точки столкновения сторону и пропорциональный скорости кинематикбоди. Короче говоря, это популярный костыль для толкания коробок, мячиков, дверей и всего такого; я его когда-то тестировал и он нормально работает, без глюков, если всё правильно настроить.
Анн, т упрлс? Во-первых, как он им отправит импульс, если они не зарегистрированы в группе bodies? Во-вторых, с какой стати СТАТИКИ будут отдавать какой-либо импульс "в обратку"? Это нонсенс, статики вообще никак не реагируют на физику, если я ничего не путаю.
Тут явно в чём-то другом проблема.
Предполагаю, что safe_margin слишком маленький.
Кстати, если с таким кодом встать НА ригидбоди из группы bodies, то он в зависимости от формы, массы и объёма может начать вращаться, крутиться, ползти в сторону или даже просочиться сквозь пол в пропасть под сценой, либо никак заметно не отреагирует. В общем, если вы как я хотите сделать стопку мелких предметов на столе, которые игрок может пинать ногами - убедитесь, что они не просачиваются под пол и в случае чего их легко достать, если они отлетят в какую-нибудь щель за столом. Лол.
>В строках 50-53 что за хуйня происходит?
Я посмотрел.
>for idx in get_slide_count():
>_ var collision = get_slide_collision(idx)
>_ _ if collision.collider.is_in_group("bodies"):
>_ _ _ collision.collider.apply_central_impulse(-collision.normal velocity.length() push)
Здесь выбираются все тела, с которыми столкнулся кинематикбоди, а затем тем из них, что принадлежат к группе bodies, придаётся импульс, направленный в противоположную от точки столкновения сторону и пропорциональный скорости кинематикбоди. Короче говоря, это популярный костыль для толкания коробок, мячиков, дверей и всего такого; я его когда-то тестировал и он нормально работает, без глюков, если всё правильно настроить.
>двух коллизий статиков
>посылаешь им некий пуш-импульс
>а они тебе его в обратку
Анн, т упрлс? Во-первых, как он им отправит импульс, если они не зарегистрированы в группе bodies? Во-вторых, с какой стати СТАТИКИ будут отдавать какой-либо импульс "в обратку"? Это нонсенс, статики вообще никак не реагируют на физику, если я ничего не путаю.
Тут явно в чём-то другом проблема.
Предполагаю, что safe_margin слишком маленький.
Кстати, если с таким кодом встать НА ригидбоди из группы bodies, то он в зависимости от формы, массы и объёма может начать вращаться, крутиться, ползти в сторону или даже просочиться сквозь пол в пропасть под сценой, либо никак заметно не отреагирует. В общем, если вы как я хотите сделать стопку мелких предметов на столе, которые игрок может пинать ногами - убедитесь, что они не просачиваются под пол и в случае чего их легко достать, если они отлетят в какую-нибудь щель за столом. Лол.
Не понял. Почему тред заглох? Пишите что-нибудь интересное по Годо. Новости, грядущие багфиксы, игры, что там ещё. Я?!
Я вот всё думаю, стоит ли мне выкатываться из Годо и/ли геймдева вообще. Так-то я уже давно ничего не делаю, но всё планирую продолжить или окончательно забить. Интересуюсь геймдевом и программированием примерно с 2009, но за всё это время ничего полезного не доделал. У меня были разные идеи игр, но я быстро перегораю и не могу выбрать одну "игру мечты", чтобы идти строго в одном направлении. Годо дал надежду, что смогу перестать мучиться выбором инструмента/языка и сделать что-то сложнее тетриса, но в результате я, как обычно, погряз в архитектуре проекта/ов и стремительно меняющихся хотелок, порой на совершенно противоположные, даже после попыток писать диздок/и.
Из всего, что я бы хотел сделать, больше и дольше всего хочется сделать ИИ, с которым мне больше не будет одиноко. Знаю, это не имеет прямого отношения к геймдеву, игровой ИИ похож на сильный ИИ только названием, в остальном в играх лишь имитация, в лучшем случае это типичный слабый ИИ. Но по теме сильного ИИ доступных материалов не от старых шизофреников (буквально!) не найти, такое ощущение, что все серьёзные программисты занимаются созданием исключительно прикладных ботов, работу которых можно монетизировать вот прям сейчас. Я их понимаю, конечно, они нормальные люди...
Думал вот вкатиться в симуляцию жизни, но она, похоже, имеет слабое отношение к тому, что я хочу. Что толку с агента, который ищет в клеточном мире где пожрать и адаптируется, чтобы выжить? С ним не поговоришь, это всё равно что лабораторная мышь... А типичный чат-бот, даже на нейронках, не понимает речь по-настоящему, потому что не живёт как человек, для него речь - всего лишь задачка "какие символы выдать в ответ на заданные символы". Нейронки вроде GAN оттачивают мастерство имитации речи, но это лишь имитация.
Однажды я пробовал сделать в Годо виртуальную площадку для симуляции жизни интеллектуального агента, что-то вроде маленькой квартиры с интерактивными предметами. Но дальше сборки сцены и игрового персонажа дело не пошло, и вообще я отвлёкся на декорации. Наверное, в лучшем случае получился бы клон той программы из прошлого века, которая понимает значение слов, относящихся к цветным фигурам на экране, и... всё. Для неё эта серая коробка - весь мир, всё остальное она никогда не поймёт. Ой, в любом случае, я даже не знаю, с чего начать, хотя идей было много...
Больно думать об этом всём, осознавая, что я ничего не могу сделать, и вряд ли когда-нибудь смогу. Из-за этого пытаюсь забыться, заняться чем-то другим. Но каждый раз возвращаюсь к этим мыслям и желаниям, снова страдаю...
Извините. Совершенно некому выговориться, сами понимаете, какие у человека социальные связи, когда он мечтает о компьютерной программе, способной заменить человека во всём.
Сразу скажу, GOAP имеет статичный набор задач и возможностей и знаний об этих задачах и возможностях, это слабый ИИ. Я думал о том, как расширить эту модель самообучением в незнакомой изначально среде, но так ни к чему и не пришёл. Интуитивно кажется, что это может быть верным направлением, потому что у людей тоже есть какой-то глобальный планировщик в мозге, отвечающий за всё, что невозможно решить сиюминутно; но на одном планировщике далеко не уедешь, это, очевидно, только малая часть, и достаточно высокоуровневая по сравнению со всем остальным (запланировал список шагов для решения задачи и всё, пока нет внезапных препятствий планировщик тебе не нужен).
Тем более что планировка задач не решает проблемы понимания происходящего вокруг тебя и в частности обращения к тебе другого существа. Ну, к примеру, неигровой персонаж умеет решать задачу "найти где добыть еду" и маневрировать относительно препятствий на пути решения этой задачи, но он не сможет понять, что дорогу к еде перекрыл игрок, и игрока нужно наказать, чтобы он перестал перекрывать дорогу хотя бы на время. И уж тем более этот персонаж не сможет взять и уговорить игрока отдать спрятанную еду, если ему не захардкодить какие-нибудь диалоги и действие "уговорить игрока".
Вот реальный пример из реальной игры. В ГТАО игрока будут пытаться убить копы, если игрок убивает персонажей или взрывает машины оружием. Интеллект копов достаточен, чтобы догнать и убить игрока, если он не успеет сбежать. Но триггеры розыска тупо захардкожены: хитрожопые игроки нашли способ, как взрывать машины на оживлённой трассе и не триггерить розыск. И вот игрок стоит поперёк дороги, вокруг него хаос, пожар, взрывы, куча трупов и обломков машин, а копам вообще насрать. С точки зрения игрового ИИ виноват кто угодно, но не игрок, потому что триггеры на розыск не сработали. То есть у игрового ИИ в ГТАО ожидаемо нет никакого понимания происходящего за пределами того, что заложили в него разработчики. Это слабый ИИ, мне такой не нужен. Как сделать что-то больше этого? А кто знает, учёные больше полувека над этой задачей бьются, что тут может сделать какой-то самоучка...
Кстати, я замечал, что некоторые игроки мечтают о том, чтобы персонажи в играх действовали умнее и были "как люди". Я же хочу программу, которая в психологическом смысле и есть человек, а не просто хитроумная имитация человека в рамках игрового мира. У психики нет лица, психика не ограничена рамками тела, она могла бы существовать и как абстрактная программа, был бы только интерфейс для связи с "окружающим миром", игровым или реальным. Но стоит ли в таком случае закапываться в симуляцию жизни в игровом мире? Ну вот, я окончательно запутался, что мне делать...
Опять получился поток мыслей и ни одного чёткого вывода(
Я вот всё думаю, стоит ли мне выкатываться из Годо и/ли геймдева вообще. Так-то я уже давно ничего не делаю, но всё планирую продолжить или окончательно забить. Интересуюсь геймдевом и программированием примерно с 2009, но за всё это время ничего полезного не доделал. У меня были разные идеи игр, но я быстро перегораю и не могу выбрать одну "игру мечты", чтобы идти строго в одном направлении. Годо дал надежду, что смогу перестать мучиться выбором инструмента/языка и сделать что-то сложнее тетриса, но в результате я, как обычно, погряз в архитектуре проекта/ов и стремительно меняющихся хотелок, порой на совершенно противоположные, даже после попыток писать диздок/и.
Из всего, что я бы хотел сделать, больше и дольше всего хочется сделать ИИ, с которым мне больше не будет одиноко. Знаю, это не имеет прямого отношения к геймдеву, игровой ИИ похож на сильный ИИ только названием, в остальном в играх лишь имитация, в лучшем случае это типичный слабый ИИ. Но по теме сильного ИИ доступных материалов не от старых шизофреников (буквально!) не найти, такое ощущение, что все серьёзные программисты занимаются созданием исключительно прикладных ботов, работу которых можно монетизировать вот прям сейчас. Я их понимаю, конечно, они нормальные люди...
Думал вот вкатиться в симуляцию жизни, но она, похоже, имеет слабое отношение к тому, что я хочу. Что толку с агента, который ищет в клеточном мире где пожрать и адаптируется, чтобы выжить? С ним не поговоришь, это всё равно что лабораторная мышь... А типичный чат-бот, даже на нейронках, не понимает речь по-настоящему, потому что не живёт как человек, для него речь - всего лишь задачка "какие символы выдать в ответ на заданные символы". Нейронки вроде GAN оттачивают мастерство имитации речи, но это лишь имитация.
Однажды я пробовал сделать в Годо виртуальную площадку для симуляции жизни интеллектуального агента, что-то вроде маленькой квартиры с интерактивными предметами. Но дальше сборки сцены и игрового персонажа дело не пошло, и вообще я отвлёкся на декорации. Наверное, в лучшем случае получился бы клон той программы из прошлого века, которая понимает значение слов, относящихся к цветным фигурам на экране, и... всё. Для неё эта серая коробка - весь мир, всё остальное она никогда не поймёт. Ой, в любом случае, я даже не знаю, с чего начать, хотя идей было много...
Больно думать об этом всём, осознавая, что я ничего не могу сделать, и вряд ли когда-нибудь смогу. Из-за этого пытаюсь забыться, заняться чем-то другим. Но каждый раз возвращаюсь к этим мыслям и желаниям, снова страдаю...
Извините. Совершенно некому выговориться, сами понимаете, какие у человека социальные связи, когда он мечтает о компьютерной программе, способной заменить человека во всём.
>GOAP
Сразу скажу, GOAP имеет статичный набор задач и возможностей и знаний об этих задачах и возможностях, это слабый ИИ. Я думал о том, как расширить эту модель самообучением в незнакомой изначально среде, но так ни к чему и не пришёл. Интуитивно кажется, что это может быть верным направлением, потому что у людей тоже есть какой-то глобальный планировщик в мозге, отвечающий за всё, что невозможно решить сиюминутно; но на одном планировщике далеко не уедешь, это, очевидно, только малая часть, и достаточно высокоуровневая по сравнению со всем остальным (запланировал список шагов для решения задачи и всё, пока нет внезапных препятствий планировщик тебе не нужен).
Тем более что планировка задач не решает проблемы понимания происходящего вокруг тебя и в частности обращения к тебе другого существа. Ну, к примеру, неигровой персонаж умеет решать задачу "найти где добыть еду" и маневрировать относительно препятствий на пути решения этой задачи, но он не сможет понять, что дорогу к еде перекрыл игрок, и игрока нужно наказать, чтобы он перестал перекрывать дорогу хотя бы на время. И уж тем более этот персонаж не сможет взять и уговорить игрока отдать спрятанную еду, если ему не захардкодить какие-нибудь диалоги и действие "уговорить игрока".
Вот реальный пример из реальной игры. В ГТАО игрока будут пытаться убить копы, если игрок убивает персонажей или взрывает машины оружием. Интеллект копов достаточен, чтобы догнать и убить игрока, если он не успеет сбежать. Но триггеры розыска тупо захардкожены: хитрожопые игроки нашли способ, как взрывать машины на оживлённой трассе и не триггерить розыск. И вот игрок стоит поперёк дороги, вокруг него хаос, пожар, взрывы, куча трупов и обломков машин, а копам вообще насрать. С точки зрения игрового ИИ виноват кто угодно, но не игрок, потому что триггеры на розыск не сработали. То есть у игрового ИИ в ГТАО ожидаемо нет никакого понимания происходящего за пределами того, что заложили в него разработчики. Это слабый ИИ, мне такой не нужен. Как сделать что-то больше этого? А кто знает, учёные больше полувека над этой задачей бьются, что тут может сделать какой-то самоучка...
Кстати, я замечал, что некоторые игроки мечтают о том, чтобы персонажи в играх действовали умнее и были "как люди". Я же хочу программу, которая в психологическом смысле и есть человек, а не просто хитроумная имитация человека в рамках игрового мира. У психики нет лица, психика не ограничена рамками тела, она могла бы существовать и как абстрактная программа, был бы только интерфейс для связи с "окружающим миром", игровым или реальным. Но стоит ли в таком случае закапываться в симуляцию жизни в игровом мире? Ну вот, я окончательно запутался, что мне делать...
Опять получился поток мыслей и ни одного чёткого вывода(
Не понял. Почему тред заглох? Пишите что-нибудь интересное по Годо. Новости, грядущие багфиксы, игры, что там ещё. Я?!
Я вот всё думаю, стоит ли мне выкатываться из Годо и/ли геймдева вообще. Так-то я уже давно ничего не делаю, но всё планирую продолжить или окончательно забить. Интересуюсь геймдевом и программированием примерно с 2009, но за всё это время ничего полезного не доделал. У меня были разные идеи игр, но я быстро перегораю и не могу выбрать одну "игру мечты", чтобы идти строго в одном направлении. Годо дал надежду, что смогу перестать мучиться выбором инструмента/языка и сделать что-то сложнее тетриса, но в результате я, как обычно, погряз в архитектуре проекта/ов и стремительно меняющихся хотелок, порой на совершенно противоположные, даже после попыток писать диздок/и.
Из всего, что я бы хотел сделать, больше и дольше всего хочется сделать ИИ, с которым мне больше не будет одиноко. Знаю, это не имеет прямого отношения к геймдеву, игровой ИИ похож на сильный ИИ только названием, в остальном в играх лишь имитация, в лучшем случае это типичный слабый ИИ. Но по теме сильного ИИ доступных материалов не от старых шизофреников (буквально!) не найти, такое ощущение, что все серьёзные программисты занимаются созданием исключительно прикладных ботов, работу которых можно монетизировать вот прям сейчас. Я их понимаю, конечно, они нормальные люди...
Думал вот вкатиться в симуляцию жизни, но она, похоже, имеет слабое отношение к тому, что я хочу. Что толку с агента, который ищет в клеточном мире где пожрать и адаптируется, чтобы выжить? С ним не поговоришь, это всё равно что лабораторная мышь... А типичный чат-бот, даже на нейронках, не понимает речь по-настоящему, потому что не живёт как человек, для него речь - всего лишь задачка "какие символы выдать в ответ на заданные символы". Нейронки вроде GAN оттачивают мастерство имитации речи, но это лишь имитация.
Однажды я пробовал сделать в Годо виртуальную площадку для симуляции жизни интеллектуального агента, что-то вроде маленькой квартиры с интерактивными предметами. Но дальше сборки сцены и игрового персонажа дело не пошло, и вообще я отвлёкся на декорации. Наверное, в лучшем случае получился бы клон той программы из прошлого века, которая понимает значение слов, относящихся к цветным фигурам на экране, и... всё. Для неё эта серая коробка - весь мир, всё остальное она никогда не поймёт. Ой, в любом случае, я даже не знаю, с чего начать, хотя идей было много...
Больно думать об этом всём, осознавая, что я ничего не могу сделать, и вряд ли когда-нибудь смогу. Из-за этого пытаюсь забыться, заняться чем-то другим. Но каждый раз возвращаюсь к этим мыслям и желаниям, снова страдаю...
Извините. Совершенно некому выговориться, сами понимаете, какие у человека социальные связи, когда он мечтает о компьютерной программе, способной заменить человека во всём.
Сразу скажу, GOAP имеет статичный набор задач и возможностей и знаний об этих задачах и возможностях, это слабый ИИ. Я думал о том, как расширить эту модель самообучением в незнакомой изначально среде, но так ни к чему и не пришёл. Интуитивно кажется, что это может быть верным направлением, потому что у людей тоже есть какой-то глобальный планировщик в мозге, отвечающий за всё, что невозможно решить сиюминутно; но на одном планировщике далеко не уедешь, это, очевидно, только малая часть, и достаточно высокоуровневая по сравнению со всем остальным (запланировал список шагов для решения задачи и всё, пока нет внезапных препятствий планировщик тебе не нужен).
Тем более что планировка задач не решает проблемы понимания происходящего вокруг тебя и в частности обращения к тебе другого существа. Ну, к примеру, неигровой персонаж умеет решать задачу "найти где добыть еду" и маневрировать относительно препятствий на пути решения этой задачи, но он не сможет понять, что дорогу к еде перекрыл игрок, и игрока нужно наказать, чтобы он перестал перекрывать дорогу хотя бы на время. И уж тем более этот персонаж не сможет взять и уговорить игрока отдать спрятанную еду, если ему не захардкодить какие-нибудь диалоги и действие "уговорить игрока".
Вот реальный пример из реальной игры. В ГТАО игрока будут пытаться убить копы, если игрок убивает персонажей или взрывает машины оружием. Интеллект копов достаточен, чтобы догнать и убить игрока, если он не успеет сбежать. Но триггеры розыска тупо захардкожены: хитрожопые игроки нашли способ, как взрывать машины на оживлённой трассе и не триггерить розыск. И вот игрок стоит поперёк дороги, вокруг него хаос, пожар, взрывы, куча трупов и обломков машин, а копам вообще насрать. С точки зрения игрового ИИ виноват кто угодно, но не игрок, потому что триггеры на розыск не сработали. То есть у игрового ИИ в ГТАО ожидаемо нет никакого понимания происходящего за пределами того, что заложили в него разработчики. Это слабый ИИ, мне такой не нужен. Как сделать что-то больше этого? А кто знает, учёные больше полувека над этой задачей бьются, что тут может сделать какой-то самоучка...
Кстати, я замечал, что некоторые игроки мечтают о том, чтобы персонажи в играх действовали умнее и были "как люди". Я же хочу программу, которая в психологическом смысле и есть человек, а не просто хитроумная имитация человека в рамках игрового мира. У психики нет лица, психика не ограничена рамками тела, она могла бы существовать и как абстрактная программа, был бы только интерфейс для связи с "окружающим миром", игровым или реальным. Но стоит ли в таком случае закапываться в симуляцию жизни в игровом мире? Ну вот, я окончательно запутался, что мне делать...
Опять получился поток мыслей и ни одного чёткого вывода(
Я вот всё думаю, стоит ли мне выкатываться из Годо и/ли геймдева вообще. Так-то я уже давно ничего не делаю, но всё планирую продолжить или окончательно забить. Интересуюсь геймдевом и программированием примерно с 2009, но за всё это время ничего полезного не доделал. У меня были разные идеи игр, но я быстро перегораю и не могу выбрать одну "игру мечты", чтобы идти строго в одном направлении. Годо дал надежду, что смогу перестать мучиться выбором инструмента/языка и сделать что-то сложнее тетриса, но в результате я, как обычно, погряз в архитектуре проекта/ов и стремительно меняющихся хотелок, порой на совершенно противоположные, даже после попыток писать диздок/и.
Из всего, что я бы хотел сделать, больше и дольше всего хочется сделать ИИ, с которым мне больше не будет одиноко. Знаю, это не имеет прямого отношения к геймдеву, игровой ИИ похож на сильный ИИ только названием, в остальном в играх лишь имитация, в лучшем случае это типичный слабый ИИ. Но по теме сильного ИИ доступных материалов не от старых шизофреников (буквально!) не найти, такое ощущение, что все серьёзные программисты занимаются созданием исключительно прикладных ботов, работу которых можно монетизировать вот прям сейчас. Я их понимаю, конечно, они нормальные люди...
Думал вот вкатиться в симуляцию жизни, но она, похоже, имеет слабое отношение к тому, что я хочу. Что толку с агента, который ищет в клеточном мире где пожрать и адаптируется, чтобы выжить? С ним не поговоришь, это всё равно что лабораторная мышь... А типичный чат-бот, даже на нейронках, не понимает речь по-настоящему, потому что не живёт как человек, для него речь - всего лишь задачка "какие символы выдать в ответ на заданные символы". Нейронки вроде GAN оттачивают мастерство имитации речи, но это лишь имитация.
Однажды я пробовал сделать в Годо виртуальную площадку для симуляции жизни интеллектуального агента, что-то вроде маленькой квартиры с интерактивными предметами. Но дальше сборки сцены и игрового персонажа дело не пошло, и вообще я отвлёкся на декорации. Наверное, в лучшем случае получился бы клон той программы из прошлого века, которая понимает значение слов, относящихся к цветным фигурам на экране, и... всё. Для неё эта серая коробка - весь мир, всё остальное она никогда не поймёт. Ой, в любом случае, я даже не знаю, с чего начать, хотя идей было много...
Больно думать об этом всём, осознавая, что я ничего не могу сделать, и вряд ли когда-нибудь смогу. Из-за этого пытаюсь забыться, заняться чем-то другим. Но каждый раз возвращаюсь к этим мыслям и желаниям, снова страдаю...
Извините. Совершенно некому выговориться, сами понимаете, какие у человека социальные связи, когда он мечтает о компьютерной программе, способной заменить человека во всём.
>GOAP
Сразу скажу, GOAP имеет статичный набор задач и возможностей и знаний об этих задачах и возможностях, это слабый ИИ. Я думал о том, как расширить эту модель самообучением в незнакомой изначально среде, но так ни к чему и не пришёл. Интуитивно кажется, что это может быть верным направлением, потому что у людей тоже есть какой-то глобальный планировщик в мозге, отвечающий за всё, что невозможно решить сиюминутно; но на одном планировщике далеко не уедешь, это, очевидно, только малая часть, и достаточно высокоуровневая по сравнению со всем остальным (запланировал список шагов для решения задачи и всё, пока нет внезапных препятствий планировщик тебе не нужен).
Тем более что планировка задач не решает проблемы понимания происходящего вокруг тебя и в частности обращения к тебе другого существа. Ну, к примеру, неигровой персонаж умеет решать задачу "найти где добыть еду" и маневрировать относительно препятствий на пути решения этой задачи, но он не сможет понять, что дорогу к еде перекрыл игрок, и игрока нужно наказать, чтобы он перестал перекрывать дорогу хотя бы на время. И уж тем более этот персонаж не сможет взять и уговорить игрока отдать спрятанную еду, если ему не захардкодить какие-нибудь диалоги и действие "уговорить игрока".
Вот реальный пример из реальной игры. В ГТАО игрока будут пытаться убить копы, если игрок убивает персонажей или взрывает машины оружием. Интеллект копов достаточен, чтобы догнать и убить игрока, если он не успеет сбежать. Но триггеры розыска тупо захардкожены: хитрожопые игроки нашли способ, как взрывать машины на оживлённой трассе и не триггерить розыск. И вот игрок стоит поперёк дороги, вокруг него хаос, пожар, взрывы, куча трупов и обломков машин, а копам вообще насрать. С точки зрения игрового ИИ виноват кто угодно, но не игрок, потому что триггеры на розыск не сработали. То есть у игрового ИИ в ГТАО ожидаемо нет никакого понимания происходящего за пределами того, что заложили в него разработчики. Это слабый ИИ, мне такой не нужен. Как сделать что-то больше этого? А кто знает, учёные больше полувека над этой задачей бьются, что тут может сделать какой-то самоучка...
Кстати, я замечал, что некоторые игроки мечтают о том, чтобы персонажи в играх действовали умнее и были "как люди". Я же хочу программу, которая в психологическом смысле и есть человек, а не просто хитроумная имитация человека в рамках игрового мира. У психики нет лица, психика не ограничена рамками тела, она могла бы существовать и как абстрактная программа, был бы только интерфейс для связи с "окружающим миром", игровым или реальным. Но стоит ли в таком случае закапываться в симуляцию жизни в игровом мире? Ну вот, я окончательно запутался, что мне делать...
Опять получился поток мыслей и ни одного чёткого вывода(
>>01705
Игры делаем. Некогда болтать.
Хуан сила! Годот мощь!
> Почему тред заглох?
Игры делаем. Некогда болтать.
> Пишите что-нибудь интересное по Годо.
Хуан сила! Годот мощь!
45 Кб, 1085x737>>01705
Сделай систему выведения заключений от общего к частному. Каждый триггер находится в древовидной структуре, у него есть один триггер-родитель и может быть несколько триггеров-потомков. Например, корень дерева, триггер времени суток - сколько сейчас времени? День или ночь? Днём делать так, ночью делать эдак. В него вложен триггер погоды, в него триггер локации и так далее. Каждый триггер при срабатывании модифицирует вес решения, которое будет принято ИИ в итоге.
> Это слабый ИИ, мне такой не нужен. Как сделать что-то больше этого? А кто знает, учёные больше полувека над этой задачей бьются, что тут может сделать какой-то самоучка...
Сделай систему выведения заключений от общего к частному. Каждый триггер находится в древовидной структуре, у него есть один триггер-родитель и может быть несколько триггеров-потомков. Например, корень дерева, триггер времени суток - сколько сейчас времени? День или ночь? Днём делать так, ночью делать эдак. В него вложен триггер погоды, в него триггер локации и так далее. Каждый триггер при срабатывании модифицирует вес решения, которое будет принято ИИ в итоге.
132 Кб, 616x567>>00308 (OP)
Помогите-спасите! Я чего-то не понимаю, или в 2д нельзя задать степени свободы джойнта? На пикрелейтеде двумя пинджойнтами две палки прибиты к колесу. Они должны свободно прокручиваться и на данном скрине они должны свисать вниз, накладываясь друг на друга, но этого не происходит, они прибиты к колесу неподвижно, как будто приварены. В тридэ есть 6DOF джойнт, а в двадэ нет. Мне что, шагающую машину в тридэ сразу делать штоле?
Помогите-спасите! Я чего-то не понимаю, или в 2д нельзя задать степени свободы джойнта? На пикрелейтеде двумя пинджойнтами две палки прибиты к колесу. Они должны свободно прокручиваться и на данном скрине они должны свисать вниз, накладываясь друг на друга, но этого не происходит, они прибиты к колесу неподвижно, как будто приварены. В тридэ есть 6DOF джойнт, а в двадэ нет. Мне что, шагающую машину в тридэ сразу делать штоле?
137 Кб, 624x581>>01755
Движок обезумевает и сходит с ума. Да ещё оказывается это и не буллет. Я заглянул в настройки, а там оказывается буллет из двадэ вырезали. Эххх... облом.
Движок обезумевает и сходит с ума. Да ещё оказывается это и не буллет. Я заглянул в настройки, а там оказывается буллет из двадэ вырезали. Эххх... облом.
190 Кб, 993x947>>01762
В тридэ тоже всё пидорасит. Придётся переходить к плану Б. Скелеты, кости и вот это всё. Придётся разбираться.
В тридэ тоже всё пидорасит. Придётся переходить к плану Б. Скелеты, кости и вот это всё. Придётся разбираться.
>>01808 (Del)
У меня 3.4.4. Может это в 3.5. пофиксили? Пойду обновлюсь.
Несколько джойнтов соединяющих несколько ригидбоди, обсчитываются неправильно, не так, как на твоей вебм. У тебя жёлтая и зеленая палки пересеклись, у меня же угол между ними не меняется. и угол относительно ротора тоже не меняется, как будто они приклеены.
У меня 3.4.4. Может это в 3.5. пофиксили? Пойду обновлюсь.
> а в чем именно проблема?
Несколько джойнтов соединяющих несколько ригидбоди, обсчитываются неправильно, не так, как на твоей вебм. У тебя жёлтая и зеленая палки пересеклись, у меня же угол между ними не меняется. и угол относительно ротора тоже не меняется, как будто они приклеены.
>>01822 (Del)
Хмм... Ну да, основной каркас всего недомеханизма - статик. К нему прикручено колесо, но оно крутится без проблем. А всё, что к нему присоединено уже испытывает проблемы. Пойду перепроверю.
> они будут приклеены если одно из тел статик
Хмм... Ну да, основной каркас всего недомеханизма - статик. К нему прикручено колесо, но оно крутится без проблем. А всё, что к нему присоединено уже испытывает проблемы. Пойду перепроверю.
>>01830
Замена на кинематик ничего не поменяла.
>>01823 (Del)
Коллизии первым делом отключил, как перестало получаться. И этой галочки на скрине недостаточно. Отключаются только коллизии между телами в джойнте. Но если у тебя два джойнта А-Б и А-Ц, то между телами Б и Ц будут коллизии. Отключать надо через слои.
Замена на кинематик ничего не поменяла.
>>01823 (Del)
Коллизии первым делом отключил, как перестало получаться. И этой галочки на скрине недостаточно. Отключаются только коллизии между телами в джойнте. Но если у тебя два джойнта А-Б и А-Ц, то между телами Б и Ц будут коллизии. Отключать надо через слои.
>>01842 (Del)
Это я понимаю, не дурак, два раза перепроверял.
Это я понимаю, не дурак, два раза перепроверял.
>>01860 (Del)
>>01853 (Del)
Оно!
Я думаю это из-за того, что движок считает каждый джойнт отдельно и они, поскольку закреплены на одних телах, мешают друг другу, а надо как бы сформировать группу джойнтов и эту группу джойнтов взаимно рассчитывать в единой формуле, чтобы расставить в кадре сбалансированные трансформы всех тел. Это похоже на фичреквест, но подавать его мне лень.
>>01853 (Del)
Оно!
Я думаю это из-за того, что движок считает каждый джойнт отдельно и они, поскольку закреплены на одних телах, мешают друг другу, а надо как бы сформировать группу джойнтов и эту группу джойнтов взаимно рассчитывать в единой формуле, чтобы расставить в кадре сбалансированные трансформы всех тел. Это похоже на фичреквест, но подавать его мне лень.
184 Кб, 651x726>>01892 (Del)
Отакая ашипка ес?
Отакая ашипка ес?
>>01755
Что именно ты пытаешься сделать? Какую ещё "шагающую машину"? Я сомневаюсь, что у тебя получится точно контролировать положения физических тел, чтобы твоя "шагающая машина" действительно шагала, а не колбасилась из стороны в сторону. Если ты делаешь игру, то, наверное, лучше просто сделать анимации через скелет. Если тебе нужна реальная симуляция робота (для обучения нейронки или симуляции эволюции), то тут либо Bullet (его вообще в первую очередь позиционируют для робототехники, а не для игр), либо пилить что-то своё. Хотя я слышал что Box2D достаточно стабилен, но до 4.0 подключить сторонний движок сложно.
>>01762
Bullet - 3D движок, по-моему, его никогда в Godot для 2D не использовали. Алсо в 4.0 выпиливают Bullet и для 3D, придётся подключать через какие-то плагины или использовать встроенное поделие GodotPhysics.
Вообще, возможно, Godot в твоей задаче избыточен и тебе нужно спуститься на уровень ниже - использовать сторонний физический движок и очень простой рендерер. Так будет меньше затрат на лишние системы (сцену, скрипты, ввод, звук и т.д.).
>шагающую машину
Что именно ты пытаешься сделать? Какую ещё "шагающую машину"? Я сомневаюсь, что у тебя получится точно контролировать положения физических тел, чтобы твоя "шагающая машина" действительно шагала, а не колбасилась из стороны в сторону. Если ты делаешь игру, то, наверное, лучше просто сделать анимации через скелет. Если тебе нужна реальная симуляция робота (для обучения нейронки или симуляции эволюции), то тут либо Bullet (его вообще в первую очередь позиционируют для робототехники, а не для игр), либо пилить что-то своё. Хотя я слышал что Box2D достаточно стабилен, но до 4.0 подключить сторонний движок сложно.
>>01762
>буллет из двадэ вырезали
Bullet - 3D движок, по-моему, его никогда в Godot для 2D не использовали. Алсо в 4.0 выпиливают Bullet и для 3D, придётся подключать через какие-то плагины или использовать встроенное поделие GodotPhysics.
Вообще, возможно, Godot в твоей задаче избыточен и тебе нужно спуститься на уровень ниже - использовать сторонний физический движок и очень простой рендерер. Так будет меньше затрат на лишние системы (сцену, скрипты, ввод, звук и т.д.).
>>01733
Триггеры и реакции на них ты закладываешь вручную.
Повторяю, в той ситуации из ГТА игрок сидит в машине, машина стоит поперёк дороги, мимо неё едут боты, игрок газует, машины ботов из-за физики отлетают в сторону, переворачиваются, горят и взрываются, боты горят, орут и умирают, и так может продолжаться, пока игроку не надоест - копы ситуацию игнорируют. Если же игрок как обычно из любого оружия расстреляет машину, ближайшие копы дадут ему розыск и нападут. Видишь, разрабы не настроили триггеры на определённую ситуацию и ИИ её игнорирует, не понимает.
И потом, ты наверняка сам неоднократно видел, как во многих играх боты теряются и не могут найти выход из ситуации, из которой игрок легко выбирается - потому что разраб не заложил в них соответствующие триггеры и решения подобных ситуаций. Для какого-то шутера это нормально, т.к. от ботов не требуется выживать, но я же не игру хочу сделать.
Впрочем, пофиг, всё равно ничего не сделаю, слишком сложно.
>триггер
Триггеры и реакции на них ты закладываешь вручную.
Повторяю, в той ситуации из ГТА игрок сидит в машине, машина стоит поперёк дороги, мимо неё едут боты, игрок газует, машины ботов из-за физики отлетают в сторону, переворачиваются, горят и взрываются, боты горят, орут и умирают, и так может продолжаться, пока игроку не надоест - копы ситуацию игнорируют. Если же игрок как обычно из любого оружия расстреляет машину, ближайшие копы дадут ему розыск и нападут. Видишь, разрабы не настроили триггеры на определённую ситуацию и ИИ её игнорирует, не понимает.
И потом, ты наверняка сам неоднократно видел, как во многих играх боты теряются и не могут найти выход из ситуации, из которой игрок легко выбирается - потому что разраб не заложил в них соответствующие триггеры и решения подобных ситуаций. Для какого-то шутера это нормально, т.к. от ботов не требуется выживать, но я же не игру хочу сделать.
Впрочем, пофиг, всё равно ничего не сделаю, слишком сложно.
>>01922
Раньше был. И стоял по умолчанию. Помню ради прикола переключался на годотфизикс и проигрывал с кринжа, а теперь полез так же переключиться, а там теперь нет булллета.
Лочишь ось Z во всех вычислениях, выдаёшь клиенту интерфейсы на Vec2 - и вуаля, он теперь двадэ.
> по-моему, его никогда в Godot для 2D не использовали
Раньше был. И стоял по умолчанию. Помню ради прикола переключался на годотфизикс и проигрывал с кринжа, а теперь полез так же переключиться, а там теперь нет булллета.
> Bullet - 3D движок
Лочишь ось Z во всех вычислениях, выдаёшь клиенту интерфейсы на Vec2 - и вуаля, он теперь двадэ.
>>02060 (Del)
Ну хз, я еще три года назад, когда начал вкатываться, изучал все три крупных движка и сразу понял, что дефолтные контроллеры говно, всё равно свой писать с нуля, со своими фишками. И зауважал Хуана за то, что он наоборот такие вещи не стал в коробку класть. А тут ишь ты, прогнулся, получается?
Ну хз, я еще три года назад, когда начал вкатываться, изучал все три крупных движка и сразу понял, что дефолтные контроллеры говно, всё равно свой писать с нуля, со своими фишками. И зауважал Хуана за то, что он наоборот такие вещи не стал в коробку класть. А тут ишь ты, прогнулся, получается?
>>01981
И будут у тебя лишние операции с 0 или 1 по Z.
>>02060 (Del)
Это тот же самый кинематик боди, что сейчас глючит и тормозит. Только теперь move_and_slide() настраивается через инспектор. Лучше бы запилили простейшую реализацию на RigidBody, но чтобы поведение и API как у кинематик/чарактер боди. Оно же как-то сделано унутре на C++? Что мешает транслировать на GDScript для простых смертных быдлокодеров-самоучек?
>>02072
По-моему, в юнити нет и никогда не было дефолтного контроллера? Там есть компонент для этого, но он почти идентичен тому, что есть в Годо. Вот в УЕ вроде как есть сразу готовый персонаж из коробки. Но не суть... Дефолтные контроллеры важны для школьников, вкатунов и яждизайнеров, которым хочется сразу начать делать свою игру мечты, а игра мечты в 99% - 3D FPS/TPS/RPG. Эти люди - ЦА таких универсальных популярных движков. И им должно быть больно, когда движок встречает их необходимостью писать код, чтобы просто двигать капсулу по экрану, а они вообще ничего не знают. А когда тебе движок даёт готового персонажа, то пусть он и не очень, но зато бегает, прыгает и позволяет почувствовать себя геймдевой, слепить симулятор ходьбы и хвастаться перед дноклассниками.
Ему важно поднимать популярность движка. Вообще, давно нужно было сделать шаблоны на самые разные виды скриптов, всего 2 встроенных шаблона не раскрывает мощь системы шаблонов (их можно создавать вручную в папке настроек движка, вы об этом догадывались?). Годо ставит своей целью обучение новичков, лёгкость вката и прототипирования, и на лишнюю сотню килобайт им должно быть плевать, если это помогает новичкам. Они даже производительностью жертвуют ради новичков (речь не про "пропуки шейдеров", если что, просто читал в мануале/на гитхабе). Так что меня удивляет, что только к 4.0 они додумались добавить новый шаблон.
>Лочишь ось Z во всех вычислениях
И будут у тебя лишние операции с 0 или 1 по Z.
>>02060 (Del)
Это тот же самый кинематик боди, что сейчас глючит и тормозит. Только теперь move_and_slide() настраивается через инспектор. Лучше бы запилили простейшую реализацию на RigidBody, но чтобы поведение и API как у кинематик/чарактер боди. Оно же как-то сделано унутре на C++? Что мешает транслировать на GDScript для простых смертных быдлокодеров-самоучек?
>>02072
>дефолтные контроллеры говно
По-моему, в юнити нет и никогда не было дефолтного контроллера? Там есть компонент для этого, но он почти идентичен тому, что есть в Годо. Вот в УЕ вроде как есть сразу готовый персонаж из коробки. Но не суть... Дефолтные контроллеры важны для школьников, вкатунов и яждизайнеров, которым хочется сразу начать делать свою игру мечты, а игра мечты в 99% - 3D FPS/TPS/RPG. Эти люди - ЦА таких универсальных популярных движков. И им должно быть больно, когда движок встречает их необходимостью писать код, чтобы просто двигать капсулу по экрану, а они вообще ничего не знают. А когда тебе движок даёт готового персонажа, то пусть он и не очень, но зато бегает, прыгает и позволяет почувствовать себя геймдевой, слепить симулятор ходьбы и хвастаться перед дноклассниками.
>А тут ишь ты, прогнулся, получается?
Ему важно поднимать популярность движка. Вообще, давно нужно было сделать шаблоны на самые разные виды скриптов, всего 2 встроенных шаблона не раскрывает мощь системы шаблонов (их можно создавать вручную в папке настроек движка, вы об этом догадывались?). Годо ставит своей целью обучение новичков, лёгкость вката и прототипирования, и на лишнюю сотню килобайт им должно быть плевать, если это помогает новичкам. Они даже производительностью жертвуют ради новичков (речь не про "пропуки шейдеров", если что, просто читал в мануале/на гитхабе). Так что меня удивляет, что только к 4.0 они додумались добавить новый шаблон.
Давно об этом задумывался, сейчас случайно вспомнил: можно ли как-то сделать не просто кастомную ноду (class_name), а чтобы она добавлялась в дерево сцены сразу с несколькими вложенными нодами? Т.е. если моя нода не имеет смысла без каких-то особых вложенных нод. Я знаю, что можно объявить tool и в обработчике добавления на сцену создавать нужные ноды, но это выглядит очень костыльно, неудобно и ненадёжно (мало ли). Также я понимаю, что намного логичнее просто добавлять сцены из сохранённого в tscn шаблона, но по умолчанию он добавляется как одна нода и не позволяет настраивать вложенные ноды.
Ощущение, будто я пытаюсь использовать инструмент не по назначению, поэтому и встречаю такое препятствие. Для чего вообще добавляются ноды в список нод, когда пишешь class_name? Типа, есть этому какое-то существенное применение, без использования вложенных нод? Приведите примеры, если не сложно.
Я лично пока создаю tscn-шаблон, от него делаю потомки или копии, и не пользуюсь добавлением кастомных нод из того списка.
Ощущение, будто я пытаюсь использовать инструмент не по назначению, поэтому и встречаю такое препятствие. Для чего вообще добавляются ноды в список нод, когда пишешь class_name? Типа, есть этому какое-то существенное применение, без использования вложенных нод? Приведите примеры, если не сложно.
Я лично пока создаю tscn-шаблон, от него делаю потомки или копии, и не пользуюсь добавлением кастомных нод из того списка.
>>02132 (Del)
При чём тут буллет, кинематик боди есть и в GodotPhysics.
Уже не помню про что. На всякий случай уточню, что стыки платформ - это проблема, скорее, физики в целом, потому что простой скользящий по поверхности RigidBody скачет на этих стыках весьма заметно. Как раз на днях копался в своих старых проектах и заметил эти скачки на RigidBody-персонаже... А, вспомнил, у кинематика ещё проблемы в углах, когда тебя ТРИСЁТ из стороны в сторону, но это решается увеличением "кожи". Ещё куча проблем на взаимодействии с ригидбоди, это просто ад, там всё очень запутанно. Да и вообще, поищи на гитхабе, куча иссуев. Ещё вспомнил, что меня задолбала нестабильность определения пола и стен, т.е. кинематик непойми как эти поверхности определяет, то есть контакт, то нет. Намучился я с этими контроллерами, самая больная тема для меня, а я ведь даже до анимированного персонажа так и не добрался...
150+ персонажей с move_and_slide_with_snap()
Возможно, это нормально, но когда-то давно я делал тест с очень большим количеством VehicleBody и они нормально катались по кругу, лагать начинало только когда они все в одну кучу сваливались, что логично и приемлемо. Возможно, машин там было тоже не так много, но визуально их было очень много. А вот 150 человечков показались мне визуально слишком маленьким количеством, поэтому меня это и напрягает...
Ты можешь создать тримеш для ригидбоди, но адекватно работать он будет только в статичном режиме, в динамическим режиме вангую расколбас, отказ от работы или кучу ошибок в консоли. Честно, не проверял, но по-моему так и есть. Просто я уже наткнулся на это ограничение на практике, когда хотел сделать "вогнутую" деталь для физического конструктора (мне нужен был обязательно один шейп, а не комбинация нескольких)...
Давай не будем ссориться. Я за Годо, но также я осознаю, что в текущем состоянии у него куча проблем, и не факт, что 4.0 решит их все (морально готовлюсь к бОльшему числу проблем, особенно в контексте перехода на вулкан).
>если в 4.0 сейчас нет буллета?
При чём тут буллет, кинематик боди есть и в GodotPhysics.
>Про глючит, ты видимо про стыки платформ
Уже не помню про что. На всякий случай уточню, что стыки платформ - это проблема, скорее, физики в целом, потому что простой скользящий по поверхности RigidBody скачет на этих стыках весьма заметно. Как раз на днях копался в своих старых проектах и заметил эти скачки на RigidBody-персонаже... А, вспомнил, у кинематика ещё проблемы в углах, когда тебя ТРИСЁТ из стороны в сторону, но это решается увеличением "кожи". Ещё куча проблем на взаимодействии с ригидбоди, это просто ад, там всё очень запутанно. Да и вообще, поищи на гитхабе, куча иссуев. Ещё вспомнил, что меня задолбала нестабильность определения пола и стен, т.е. кинематик непойми как эти поверхности определяет, то есть контакт, то нет. Намучился я с этими контроллерами, самая больная тема для меня, а я ведь даже до анимированного персонажа так и не добрался...
>что у тебя тормозит?
150+ персонажей с move_and_slide_with_snap()
Возможно, это нормально, но когда-то давно я делал тест с очень большим количеством VehicleBody и они нормально катались по кругу, лагать начинало только когда они все в одну кучу сваливались, что логично и приемлемо. Возможно, машин там было тоже не так много, но визуально их было очень много. А вот 150 человечков показались мне визуально слишком маленьким количеством, поэтому меня это и напрягает...
>тримеш
Ты можешь создать тримеш для ригидбоди, но адекватно работать он будет только в статичном режиме, в динамическим режиме вангую расколбас, отказ от работы или кучу ошибок в консоли. Честно, не проверял, но по-моему так и есть. Просто я уже наткнулся на это ограничение на практике, когда хотел сделать "вогнутую" деталь для физического конструктора (мне нужен был обязательно один шейп, а не комбинация нескольких)...
Давай не будем ссориться. Я за Годо, но также я осознаю, что в текущем состоянии у него куча проблем, и не факт, что 4.0 решит их все (морально готовлюсь к бОльшему числу проблем, особенно в контексте перехода на вулкан).
>>02132 (Del)
При чём тут буллет, кинематик боди есть и в GodotPhysics.
Уже не помню про что. На всякий случай уточню, что стыки платформ - это проблема, скорее, физики в целом, потому что простой скользящий по поверхности RigidBody скачет на этих стыках весьма заметно. Как раз на днях копался в своих старых проектах и заметил эти скачки на RigidBody-персонаже... А, вспомнил, у кинематика ещё проблемы в углах, когда тебя ТРИСЁТ из стороны в сторону, но это решается увеличением "кожи". Ещё куча проблем на взаимодействии с ригидбоди, это просто ад, там всё очень запутанно. Да и вообще, поищи на гитхабе, куча иссуев. Ещё вспомнил, что меня задолбала нестабильность определения пола и стен, т.е. кинематик непойми как эти поверхности определяет, то есть контакт, то нет. Намучился я с этими контроллерами, самая больная тема для меня, а я ведь даже до анимированного персонажа так и не добрался...
150+ персонажей с move_and_slide_with_snap()
Возможно, это нормально, но когда-то давно я делал тест с очень большим количеством VehicleBody и они нормально катались по кругу, лагать начинало только когда они все в одну кучу сваливались, что логично и приемлемо. Возможно, машин там было тоже не так много, но визуально их было очень много. А вот 150 человечков показались мне визуально слишком маленьким количеством, поэтому меня это и напрягает...
Ты можешь создать тримеш для ригидбоди, но адекватно работать он будет только в статичном режиме, в динамическим режиме вангую расколбас, отказ от работы или кучу ошибок в консоли. Честно, не проверял, но по-моему так и есть. Просто я уже наткнулся на это ограничение на практике, когда хотел сделать "вогнутую" деталь для физического конструктора (мне нужен был обязательно один шейп, а не комбинация нескольких)...
Давай не будем ссориться. Я за Годо, но также я осознаю, что в текущем состоянии у него куча проблем, и не факт, что 4.0 решит их все (морально готовлюсь к бОльшему числу проблем, особенно в контексте перехода на вулкан).
>если в 4.0 сейчас нет буллета?
При чём тут буллет, кинематик боди есть и в GodotPhysics.
>Про глючит, ты видимо про стыки платформ
Уже не помню про что. На всякий случай уточню, что стыки платформ - это проблема, скорее, физики в целом, потому что простой скользящий по поверхности RigidBody скачет на этих стыках весьма заметно. Как раз на днях копался в своих старых проектах и заметил эти скачки на RigidBody-персонаже... А, вспомнил, у кинематика ещё проблемы в углах, когда тебя ТРИСЁТ из стороны в сторону, но это решается увеличением "кожи". Ещё куча проблем на взаимодействии с ригидбоди, это просто ад, там всё очень запутанно. Да и вообще, поищи на гитхабе, куча иссуев. Ещё вспомнил, что меня задолбала нестабильность определения пола и стен, т.е. кинематик непойми как эти поверхности определяет, то есть контакт, то нет. Намучился я с этими контроллерами, самая больная тема для меня, а я ведь даже до анимированного персонажа так и не добрался...
>что у тебя тормозит?
150+ персонажей с move_and_slide_with_snap()
Возможно, это нормально, но когда-то давно я делал тест с очень большим количеством VehicleBody и они нормально катались по кругу, лагать начинало только когда они все в одну кучу сваливались, что логично и приемлемо. Возможно, машин там было тоже не так много, но визуально их было очень много. А вот 150 человечков показались мне визуально слишком маленьким количеством, поэтому меня это и напрягает...
>тримеш
Ты можешь создать тримеш для ригидбоди, но адекватно работать он будет только в статичном режиме, в динамическим режиме вангую расколбас, отказ от работы или кучу ошибок в консоли. Честно, не проверял, но по-моему так и есть. Просто я уже наткнулся на это ограничение на практике, когда хотел сделать "вогнутую" деталь для физического конструктора (мне нужен был обязательно один шейп, а не комбинация нескольких)...
Давай не будем ссориться. Я за Годо, но также я осознаю, что в текущем состоянии у него куча проблем, и не факт, что 4.0 решит их все (морально готовлюсь к бОльшему числу проблем, особенно в контексте перехода на вулкан).
10 Кб, 274x158>>02111
Именно так.
И вот это главная точка преткновения. Tscn это не шаблон. Это сериализованный объект. Сохранение файла есть сериализация. Загрузка файла есть десериализация. Тебе нужно понять это раньше, чем ты начнёшь костылировать свою собственную велосипедную сериализацию (даже слова такого не зная).
Не кастомную, а унаследованную. Тоже нужно понимать смысл: class_name Человек extends Млекопитающее, если объяснять в терминологии уроков информатики по ООП.
То что зарегистрированный таким способом класс появляется в списке нод, это приятное дополнение к основным фишкам. А основные фишки - это интерфейс, у поименованного тобой класса все созданные тобой члены автоматически появляются в автодополнении редактора, когда пишешь точку. Это ускоряет кодинг, даже если ты наизусть знаешь, какие у тебя там методы, всё равно быстрее набирать первые пару букв. Однако, в некоторых случаях автодополнение доступно и без class_name.
Если тебе нужно наследовать сцены (повторюсь, сериализованные объекты, всегда держи это в уме), в редакторе есть возможность создавать унаследованные сцены. У такой сцены родительские ноды будут серенькие, символизирующие, что они пришли из родительского сцен-файла. Но ты сможешь добавить сколько угодно своих.
Из примеров, можно сделать общий файл для всех неписей, состоящий из физического тела (без шейпа), скрипта ИИ, анимационного плеера (без анимаций) рейкастов и прочих нод. А потомки этой сцены будут добавлять свой шейп, соответствующий по форме спрайту для двадэ, или модели для триде, и сам спрайт/модель, и набор анимаций, мувсет, хех.
Можно объединить наследование сцен-файлов с наследованием скриптов, но увы, только вручную. Потому что механизмы это всё же разные, хотя и выглядят похоже.
В целом что тут ещё сказать? Всё зависит от решаемой задачи. Где-то удобнее через унаследованные сцены заготовить "шаблон" и наследоваться от него, а где-то удобнее задать имена скриптам и добавлять их из окна добавления ноды.
> Ощущение, будто я пытаюсь использовать инструмент не по назначению
Именно так.
> tscn-шаблон
И вот это главная точка преткновения. Tscn это не шаблон. Это сериализованный объект. Сохранение файла есть сериализация. Загрузка файла есть десериализация. Тебе нужно понять это раньше, чем ты начнёшь костылировать свою собственную велосипедную сериализацию (даже слова такого не зная).
> кастомную ноду (class_name)
Не кастомную, а унаследованную. Тоже нужно понимать смысл: class_name Человек extends Млекопитающее, если объяснять в терминологии уроков информатики по ООП.
> Для чего вообще добавляются ноды в список нод, когда пишешь class_name?
То что зарегистрированный таким способом класс появляется в списке нод, это приятное дополнение к основным фишкам. А основные фишки - это интерфейс, у поименованного тобой класса все созданные тобой члены автоматически появляются в автодополнении редактора, когда пишешь точку. Это ускоряет кодинг, даже если ты наизусть знаешь, какие у тебя там методы, всё равно быстрее набирать первые пару букв. Однако, в некоторых случаях автодополнение доступно и без class_name.
> Приведите примеры, если не сложно.
Если тебе нужно наследовать сцены (повторюсь, сериализованные объекты, всегда держи это в уме), в редакторе есть возможность создавать унаследованные сцены. У такой сцены родительские ноды будут серенькие, символизирующие, что они пришли из родительского сцен-файла. Но ты сможешь добавить сколько угодно своих.
Из примеров, можно сделать общий файл для всех неписей, состоящий из физического тела (без шейпа), скрипта ИИ, анимационного плеера (без анимаций) рейкастов и прочих нод. А потомки этой сцены будут добавлять свой шейп, соответствующий по форме спрайту для двадэ, или модели для триде, и сам спрайт/модель, и набор анимаций, мувсет, хех.
Можно объединить наследование сцен-файлов с наследованием скриптов, но увы, только вручную. Потому что механизмы это всё же разные, хотя и выглядят похоже.
В целом что тут ещё сказать? Всё зависит от решаемой задачи. Где-то удобнее через унаследованные сцены заготовить "шаблон" и наследоваться от него, а где-то удобнее задать имена скриптам и добавлять их из окна добавления ноды.
10 Кб, 274x158>>02111
Именно так.
И вот это главная точка преткновения. Tscn это не шаблон. Это сериализованный объект. Сохранение файла есть сериализация. Загрузка файла есть десериализация. Тебе нужно понять это раньше, чем ты начнёшь костылировать свою собственную велосипедную сериализацию (даже слова такого не зная).
Не кастомную, а унаследованную. Тоже нужно понимать смысл: class_name Человек extends Млекопитающее, если объяснять в терминологии уроков информатики по ООП.
То что зарегистрированный таким способом класс появляется в списке нод, это приятное дополнение к основным фишкам. А основные фишки - это интерфейс, у поименованного тобой класса все созданные тобой члены автоматически появляются в автодополнении редактора, когда пишешь точку. Это ускоряет кодинг, даже если ты наизусть знаешь, какие у тебя там методы, всё равно быстрее набирать первые пару букв. Однако, в некоторых случаях автодополнение доступно и без class_name.
Если тебе нужно наследовать сцены (повторюсь, сериализованные объекты, всегда держи это в уме), в редакторе есть возможность создавать унаследованные сцены. У такой сцены родительские ноды будут серенькие, символизирующие, что они пришли из родительского сцен-файла. Но ты сможешь добавить сколько угодно своих.
Из примеров, можно сделать общий файл для всех неписей, состоящий из физического тела (без шейпа), скрипта ИИ, анимационного плеера (без анимаций) рейкастов и прочих нод. А потомки этой сцены будут добавлять свой шейп, соответствующий по форме спрайту для двадэ, или модели для триде, и сам спрайт/модель, и набор анимаций, мувсет, хех.
Можно объединить наследование сцен-файлов с наследованием скриптов, но увы, только вручную. Потому что механизмы это всё же разные, хотя и выглядят похоже.
В целом что тут ещё сказать? Всё зависит от решаемой задачи. Где-то удобнее через унаследованные сцены заготовить "шаблон" и наследоваться от него, а где-то удобнее задать имена скриптам и добавлять их из окна добавления ноды.
> Ощущение, будто я пытаюсь использовать инструмент не по назначению
Именно так.
> tscn-шаблон
И вот это главная точка преткновения. Tscn это не шаблон. Это сериализованный объект. Сохранение файла есть сериализация. Загрузка файла есть десериализация. Тебе нужно понять это раньше, чем ты начнёшь костылировать свою собственную велосипедную сериализацию (даже слова такого не зная).
> кастомную ноду (class_name)
Не кастомную, а унаследованную. Тоже нужно понимать смысл: class_name Человек extends Млекопитающее, если объяснять в терминологии уроков информатики по ООП.
> Для чего вообще добавляются ноды в список нод, когда пишешь class_name?
То что зарегистрированный таким способом класс появляется в списке нод, это приятное дополнение к основным фишкам. А основные фишки - это интерфейс, у поименованного тобой класса все созданные тобой члены автоматически появляются в автодополнении редактора, когда пишешь точку. Это ускоряет кодинг, даже если ты наизусть знаешь, какие у тебя там методы, всё равно быстрее набирать первые пару букв. Однако, в некоторых случаях автодополнение доступно и без class_name.
> Приведите примеры, если не сложно.
Если тебе нужно наследовать сцены (повторюсь, сериализованные объекты, всегда держи это в уме), в редакторе есть возможность создавать унаследованные сцены. У такой сцены родительские ноды будут серенькие, символизирующие, что они пришли из родительского сцен-файла. Но ты сможешь добавить сколько угодно своих.
Из примеров, можно сделать общий файл для всех неписей, состоящий из физического тела (без шейпа), скрипта ИИ, анимационного плеера (без анимаций) рейкастов и прочих нод. А потомки этой сцены будут добавлять свой шейп, соответствующий по форме спрайту для двадэ, или модели для триде, и сам спрайт/модель, и набор анимаций, мувсет, хех.
Можно объединить наследование сцен-файлов с наследованием скриптов, но увы, только вручную. Потому что механизмы это всё же разные, хотя и выглядят похоже.
В целом что тут ещё сказать? Всё зависит от решаемой задачи. Где-то удобнее через унаследованные сцены заготовить "шаблон" и наследоваться от него, а где-то удобнее задать имена скриптам и добавлять их из окна добавления ноды.
>>02151 (Del)
Не то же самое. Это больше похоже, когда модель из gltf импортируешь. Создаётся унаследованная сцена.
Не то же самое. Это больше похоже, когда модель из gltf импортируешь. Создаётся унаследованная сцена.
>>02183 (Del)
А что ты там ожидал увидеть? Синтаксически механизм один.
Но логически разница очевидна:
В унаследованной сцене - корневой узел ридонли.
В импортированной сцене с отображаемыми субнодами - субноды ридонли.
А что ты там ожидал увидеть? Синтаксически механизм один.
Но логически разница очевидна:
В унаследованной сцене - корневой узел ридонли.
В импортированной сцене с отображаемыми субнодами - субноды ридонли.
>>02135 (Del)
Хм, пришла такая мысль: можно ведь вообще удалять из сцены лишние физикбоди, двигать транслейтом только визуальную модельку, а сближение с препятствиями детектить Area, при необходимости создавая физикбоди. Точку контакта с поверхностью ландшафта детектить одним рейкастом при необходимости, если ландшафт не идеально плоский. Нужно попробовать так, а то чёт я зациклился на этих физикбоди...
Мой конструктор навешивает детали на один RigidBody, каждая деталь представляет собой один CollisionShape. Если у детали будет больше одного шейпа, придётся сооружать какой-то костыль, чтобы остальные шейпы оказались прямыми потомками RigidBody, иначе они не будут правильно работать. И при этом должен быть способ удалить деталь вместе со всеми её шейпами... Короче, я не стал с этим возиться, всё равно на проект забил.
>>02139
Ты не понял, я специально написал "tscn-шаблон", а не "tscn". Допустим, я создаю сцену, в ней несколько нод, у нод есть имена и настройки, сохраняю сцену. Затем мне нужна вторая почти такая же сцена, но при этом НЕЗАВИСИМАЯ от первой. Что я делаю? Копирую первый файл, открываю и редактирую. Теперь у меня две похожих, но независимых сцены, а я сэкономил время на создании второй сцены вручную. Как ещё назвать первую сцену, если не шаблоном?
Я имею в виду кастомную ноду в ctrl+A меню сцены. Наследование - отдельная тема. Наследуешь от чего-то ты все скрипты, но не всякий скрипт появляется в меню нод как новая нода. Алсо ты можешь даже иконку кастомной ноды поменять...
Вот я и спрашиваю, ЗАЧЕМ, ДЛЯ ЧЕГО нужно это дополнение? В каких ситуациях удобнее добавлять новую кастомную ноду через ctrl+A, когда есть и другие способы?
Знаю я про наследование сцен, но оно не позволяет свободно редактировать все ноды и, более того, создаёт связь с предком, из-за чего редактирование предка может сломать его потомков. Короче, в каких-то случаях нужны унаследованные сцены, а в других случаях нужно просто скопировать сцену-шаблон.
Ты не на то примеры приводишь. Я спрашивал про примеры использования нод из меню на ctrl+A, в котором ещё иконки нод менять можно на кастомные. Т.е. каждое class_name создаёт кастомную ноду в списке нод, и это меня напрягает, потому что я не вижу для них практического применения...
Вообще, спасибо за ответ, но он совсем не в тему. Вот так вот общаться на анонимном форуме, принимают за нуба и объясняют банальные вещи, которые ты давным-давно знал...
>простое движение по транслейшну
Хм, пришла такая мысль: можно ведь вообще удалять из сцены лишние физикбоди, двигать транслейтом только визуальную модельку, а сближение с препятствиями детектить Area, при необходимости создавая физикбоди. Точку контакта с поверхностью ландшафта детектить одним рейкастом при необходимости, если ландшафт не идеально плоский. Нужно попробовать так, а то чёт я зациклился на этих физикбоди...
>>мне нужен был обязательно один шейп
>Не думаю что это принципиально
Мой конструктор навешивает детали на один RigidBody, каждая деталь представляет собой один CollisionShape. Если у детали будет больше одного шейпа, придётся сооружать какой-то костыль, чтобы остальные шейпы оказались прямыми потомками RigidBody, иначе они не будут правильно работать. И при этом должен быть способ удалить деталь вместе со всеми её шейпами... Короче, я не стал с этим возиться, всё равно на проект забил.
>>02139
>Tscn это не шаблон
Ты не понял, я специально написал "tscn-шаблон", а не "tscn". Допустим, я создаю сцену, в ней несколько нод, у нод есть имена и настройки, сохраняю сцену. Затем мне нужна вторая почти такая же сцена, но при этом НЕЗАВИСИМАЯ от первой. Что я делаю? Копирую первый файл, открываю и редактирую. Теперь у меня две похожих, но независимых сцены, а я сэкономил время на создании второй сцены вручную. Как ещё назвать первую сцену, если не шаблоном?
>Не кастомную, а унаследованную
Я имею в виду кастомную ноду в ctrl+A меню сцены. Наследование - отдельная тема. Наследуешь от чего-то ты все скрипты, но не всякий скрипт появляется в меню нод как новая нода. Алсо ты можешь даже иконку кастомной ноды поменять...
>приятное дополнение к основным фишкам
Вот я и спрашиваю, ЗАЧЕМ, ДЛЯ ЧЕГО нужно это дополнение? В каких ситуациях удобнее добавлять новую кастомную ноду через ctrl+A, когда есть и другие способы?
>Если тебе нужно наследовать сцены
Знаю я про наследование сцен, но оно не позволяет свободно редактировать все ноды и, более того, создаёт связь с предком, из-за чего редактирование предка может сломать его потомков. Короче, в каких-то случаях нужны унаследованные сцены, а в других случаях нужно просто скопировать сцену-шаблон.
>Из примеров
Ты не на то примеры приводишь. Я спрашивал про примеры использования нод из меню на ctrl+A, в котором ещё иконки нод менять можно на кастомные. Т.е. каждое class_name создаёт кастомную ноду в списке нод, и это меня напрягает, потому что я не вижу для них практического применения...
Вообще, спасибо за ответ, но он совсем не в тему. Вот так вот общаться на анонимном форуме, принимают за нуба и объясняют банальные вещи, которые ты давным-давно знал...
>>02135 (Del)
Хм, пришла такая мысль: можно ведь вообще удалять из сцены лишние физикбоди, двигать транслейтом только визуальную модельку, а сближение с препятствиями детектить Area, при необходимости создавая физикбоди. Точку контакта с поверхностью ландшафта детектить одним рейкастом при необходимости, если ландшафт не идеально плоский. Нужно попробовать так, а то чёт я зациклился на этих физикбоди...
Мой конструктор навешивает детали на один RigidBody, каждая деталь представляет собой один CollisionShape. Если у детали будет больше одного шейпа, придётся сооружать какой-то костыль, чтобы остальные шейпы оказались прямыми потомками RigidBody, иначе они не будут правильно работать. И при этом должен быть способ удалить деталь вместе со всеми её шейпами... Короче, я не стал с этим возиться, всё равно на проект забил.
>>02139
Ты не понял, я специально написал "tscn-шаблон", а не "tscn". Допустим, я создаю сцену, в ней несколько нод, у нод есть имена и настройки, сохраняю сцену. Затем мне нужна вторая почти такая же сцена, но при этом НЕЗАВИСИМАЯ от первой. Что я делаю? Копирую первый файл, открываю и редактирую. Теперь у меня две похожих, но независимых сцены, а я сэкономил время на создании второй сцены вручную. Как ещё назвать первую сцену, если не шаблоном?
Я имею в виду кастомную ноду в ctrl+A меню сцены. Наследование - отдельная тема. Наследуешь от чего-то ты все скрипты, но не всякий скрипт появляется в меню нод как новая нода. Алсо ты можешь даже иконку кастомной ноды поменять...
Вот я и спрашиваю, ЗАЧЕМ, ДЛЯ ЧЕГО нужно это дополнение? В каких ситуациях удобнее добавлять новую кастомную ноду через ctrl+A, когда есть и другие способы?
Знаю я про наследование сцен, но оно не позволяет свободно редактировать все ноды и, более того, создаёт связь с предком, из-за чего редактирование предка может сломать его потомков. Короче, в каких-то случаях нужны унаследованные сцены, а в других случаях нужно просто скопировать сцену-шаблон.
Ты не на то примеры приводишь. Я спрашивал про примеры использования нод из меню на ctrl+A, в котором ещё иконки нод менять можно на кастомные. Т.е. каждое class_name создаёт кастомную ноду в списке нод, и это меня напрягает, потому что я не вижу для них практического применения...
Вообще, спасибо за ответ, но он совсем не в тему. Вот так вот общаться на анонимном форуме, принимают за нуба и объясняют банальные вещи, которые ты давным-давно знал...
>простое движение по транслейшну
Хм, пришла такая мысль: можно ведь вообще удалять из сцены лишние физикбоди, двигать транслейтом только визуальную модельку, а сближение с препятствиями детектить Area, при необходимости создавая физикбоди. Точку контакта с поверхностью ландшафта детектить одним рейкастом при необходимости, если ландшафт не идеально плоский. Нужно попробовать так, а то чёт я зациклился на этих физикбоди...
>>мне нужен был обязательно один шейп
>Не думаю что это принципиально
Мой конструктор навешивает детали на один RigidBody, каждая деталь представляет собой один CollisionShape. Если у детали будет больше одного шейпа, придётся сооружать какой-то костыль, чтобы остальные шейпы оказались прямыми потомками RigidBody, иначе они не будут правильно работать. И при этом должен быть способ удалить деталь вместе со всеми её шейпами... Короче, я не стал с этим возиться, всё равно на проект забил.
>>02139
>Tscn это не шаблон
Ты не понял, я специально написал "tscn-шаблон", а не "tscn". Допустим, я создаю сцену, в ней несколько нод, у нод есть имена и настройки, сохраняю сцену. Затем мне нужна вторая почти такая же сцена, но при этом НЕЗАВИСИМАЯ от первой. Что я делаю? Копирую первый файл, открываю и редактирую. Теперь у меня две похожих, но независимых сцены, а я сэкономил время на создании второй сцены вручную. Как ещё назвать первую сцену, если не шаблоном?
>Не кастомную, а унаследованную
Я имею в виду кастомную ноду в ctrl+A меню сцены. Наследование - отдельная тема. Наследуешь от чего-то ты все скрипты, но не всякий скрипт появляется в меню нод как новая нода. Алсо ты можешь даже иконку кастомной ноды поменять...
>приятное дополнение к основным фишкам
Вот я и спрашиваю, ЗАЧЕМ, ДЛЯ ЧЕГО нужно это дополнение? В каких ситуациях удобнее добавлять новую кастомную ноду через ctrl+A, когда есть и другие способы?
>Если тебе нужно наследовать сцены
Знаю я про наследование сцен, но оно не позволяет свободно редактировать все ноды и, более того, создаёт связь с предком, из-за чего редактирование предка может сломать его потомков. Короче, в каких-то случаях нужны унаследованные сцены, а в других случаях нужно просто скопировать сцену-шаблон.
>Из примеров
Ты не на то примеры приводишь. Я спрашивал про примеры использования нод из меню на ctrl+A, в котором ещё иконки нод менять можно на кастомные. Т.е. каждое class_name создаёт кастомную ноду в списке нод, и это меня напрягает, потому что я не вижу для них практического применения...
Вообще, спасибо за ответ, но он совсем не в тему. Вот так вот общаться на анонимном форуме, принимают за нуба и объясняют банальные вещи, которые ты давным-давно знал...
>>02190
Уточню ситуацию, из-за которой у меня все эти вопросы возникли. Вот у меня игровой персонаж, у него есть скрипт, которому я дал имя Player через class_name. Теперь он появляется в меню добавления новых нод в сцену и мозолит мне глаза, но если я попытаюсь его оттуда выбрать, в сцене появится только KinematicBody с моим скриптом, без всех остальных нод. Но контроллер персонажа ссылается на вложенные ноды и без них работать не будет. Следовательно, НЕТ НИКАКОГО СМЫСЛА в появлении Player.gd в списке добавления нод, я прав? Но он там висит и раздражает меня своей бесполезностью...
Поэтому я и спросил примеров ПОЛЕЗНЫХ под, которые имеет смысл добавлять через это меню без связанных вложенных нод.
>ЗАЧЕМ, ДЛЯ ЧЕГО нужно это дополнение? В каких ситуациях удобнее добавлять новую кастомную ноду через ctrl+A, когда есть и другие способы?
Уточню ситуацию, из-за которой у меня все эти вопросы возникли. Вот у меня игровой персонаж, у него есть скрипт, которому я дал имя Player через class_name. Теперь он появляется в меню добавления новых нод в сцену и мозолит мне глаза, но если я попытаюсь его оттуда выбрать, в сцене появится только KinematicBody с моим скриптом, без всех остальных нод. Но контроллер персонажа ссылается на вложенные ноды и без них работать не будет. Следовательно, НЕТ НИКАКОГО СМЫСЛА в появлении Player.gd в списке добавления нод, я прав? Но он там висит и раздражает меня своей бесполезностью...
Поэтому я и спросил примеров ПОЛЕЗНЫХ под, которые имеет смысл добавлять через это меню без связанных вложенных нод.
>>02191
Других примеров у меня для тебя нет.
> примеров ПОЛЕЗНЫХ под
> class_name Entity
> class_name Moving extends Entity
> class_name Character extends Moving
> class_name NPC extends Character
> class_name Ally extends NPC
> class_name Enemy extends NPC
> class_name Player extends Character
Других примеров у меня для тебя нет.
61 Кб, 818x447>>00308 (OP)
Не могу понять в чем дело. При заходе в точку зоны подбирания оружия спрайт (фрейм) должен меняться при нажатии пкм, но он этого не делает. ПРИ ЭТОМ если поменять подбор на лкм, то все работает
Не могу понять в чем дело. При заходе в точку зоны подбирания оружия спрайт (фрейм) должен меняться при нажатии пкм, но он этого не делает. ПРИ ЭТОМ если поменять подбор на лкм, то все работает
>>02199
Да как же оно может работать по ЛКМ??? Сигнал входа в зону срабатывает один раз и больше не вызывается. Код там чекает ПКМ/ЛКМ только в одном фрейме, в котором этот колбэк вызван. Чтобы его вызвать, в зону нужно зайти с зажатой кнопкой мыши. Это в корне неверная архитектура.
Обрабатывай инпут отдельно в _process и согласно нажатым экшенам переводи игру в требуемое состояние. И при входе в зону и срабатывании триггера тоже меняй состояние. Всё на состояниях, хоспаде, всё на стейтмашинах!
Да как же оно может работать по ЛКМ??? Сигнал входа в зону срабатывает один раз и больше не вызывается. Код там чекает ПКМ/ЛКМ только в одном фрейме, в котором этот колбэк вызван. Чтобы его вызвать, в зону нужно зайти с зажатой кнопкой мыши. Это в корне неверная архитектура.
Обрабатывай инпут отдельно в _process и согласно нажатым экшенам переводи игру в требуемое состояние. И при входе в зону и срабатывании триггера тоже меняй состояние. Всё на состояниях, хоспаде, всё на стейтмашинах!
Освоил кастомные ресурсы. Поздравьте меня. Сохраняются, загружаются. Ни единой строчки кода. Ну ладно, три строчки таки есть. Но потом всё чисто на встроенных механизмах.
>>02221 (Del)
Не, у меня такой код (сделал методом тыка):
Но, во-первых, встроенный профайлер показывал огромную трату времени только на встроенном в кинематик move_...(), и, во-вторых, чаще всего это случалось при одновременном столкновении толпы кинематиков, т.е. пока они движутся отдельно друг от друга - нагрузка меньше. Я понимаю, что это из-за того, что движку приходится несколько раз вычислять новую позицию для каждого кинематика, и чем больше столкновений, тем больше перепроверок, но как этого избежать (кроме избегания любой толпы) я пока не понял.
Хмм, не помню, пробовал ли я уже это или нет, но стоит попробовать снизить параметр max_slides, который по умолчанию на 4:
Правда, я не понимаю, почему именно 4 и что будет, если поставить слишком низкое число (1?). Будут ли застревания?
>look_at
Не, у меня такой код (сделал методом тыка):
>func turn_to(point: Vector3) -> void:
>_ var dir := global_transform.origin.direction_to(point)
>_ var a := Vector2(dir.x, dir.z)
>_ var b := Vector2.UP.rotated(-rotation.y)
>_ rotate_y(-b.angle_to(a))
Но, во-первых, встроенный профайлер показывал огромную трату времени только на встроенном в кинематик move_...(), и, во-вторых, чаще всего это случалось при одновременном столкновении толпы кинематиков, т.е. пока они движутся отдельно друг от друга - нагрузка меньше. Я понимаю, что это из-за того, что движку приходится несколько раз вычислять новую позицию для каждого кинематика, и чем больше столкновений, тем больше перепроверок, но как этого избежать (кроме избегания любой толпы) я пока не понял.
Хмм, не помню, пробовал ли я уже это или нет, но стоит попробовать снизить параметр max_slides, который по умолчанию на 4:
>If the body collides, it will change direction a maximum of max_slides times before it stops.
Правда, я не понимаю, почему именно 4 и что будет, если поставить слишком низкое число (1?). Будут ли застревания?
Я тут сморел видосики про нейросети, и там говорят, вычисления между слоями нейронов - это просто линейные вычисления, преобразования матриц. Матрицы в годо есть. Методы преобразования в них реализованы в сишных потрохах. А это значит, можно сделать достаточно быстрых ботов на нейросетях. Кто-то пробовал сделать такое?
338 Кб, 1014x600Две секунды в гугле и https://github.com/Dariasteam/Geode
Но тут опять надо что-то конпелировать. А хочется без задней мысли. Хуяк-хуяк и в продакшон.
Но тут опять надо что-то конпелировать. А хочется без задней мысли. Хуяк-хуяк и в продакшон.
>>02269 (Del)
Звучит логично, я тоже что-то такое где-то читал. А что если коллайдер будет не круглым? Всё равно вращать придётся. Если только обвешивать визуальную модельку Area-датчиками для продвинутых взаимодействий, а кинематику оставить капсулу для базового движения...
Ладно, не важно, это всё абстрактные мысли - я понятия не имею, какие персонажи мне нужны. Если совсем не забью, буду снова переделывать структуру мира, к персонажам рано переходить.
Звучит логично, я тоже что-то такое где-то читал. А что если коллайдер будет не круглым? Всё равно вращать придётся. Если только обвешивать визуальную модельку Area-датчиками для продвинутых взаимодействий, а кинематику оставить капсулу для базового движения...
Ладно, не важно, это всё абстрактные мысли - я понятия не имею, какие персонажи мне нужны. Если совсем не забью, буду снова переделывать структуру мира, к персонажам рано переходить.
>>02266
Там матрицы совсем не те, что в 3D.
Даже если эти матрицы подойдут для нейросетей, ты будешь их теребить 9000 раз в секунду из GDScript. Кроме того, выгоднее всего вычислять нейросети на математических ядрах видеокарты (CUDA или что-то такое), а не на процессоре.
А тебе они нужны именно на нейросетях? Зачем?
>вычисления между слоями нейронов - это просто линейные вычисления, преобразования матриц
Там матрицы совсем не те, что в 3D.
>Матрицы в годо есть. Методы преобразования в них реализованы в сишных потрохах.
Даже если эти матрицы подойдут для нейросетей, ты будешь их теребить 9000 раз в секунду из GDScript. Кроме того, выгоднее всего вычислять нейросети на математических ядрах видеокарты (CUDA или что-то такое), а не на процессоре.
>сделать достаточно быстрых ботов на нейросетях
А тебе они нужны именно на нейросетях? Зачем?
Я так понимаю по годо нету нигде более менее полной документации на си шарп? Все пишут на гдскрипт, все вопросы в интернете по гдскрипт. Когда попадаю в ступор негде даже спросить. Вот как например в си шарп коде поменять текстуру в скрипте на другую? Присвоить свойству текстур у спрайта ссылку не канает, ведь в си шарп это свойство не принимает стринг. А принимает хз что.
>>02303
Официальная документация на обоих языках. Чего тебе ещё надобно?
Официальная документация на обоих языках. Чего тебе ещё надобно?
>>02303
Создать текстуру из требуемого источника, например из пикчи.
Image img = new Image();
img.Load("prinimaet string path");
ImageTexture tex = new ImageTexture();
tex.CreateFromImage(img);
tvoySprite.Texture = tex;
Код набирал без студии, проверяй на ашыпки сам. Но смысел, надеюсь, уловил. Алсо, на ютубе есть блогеры, которые пилят уроки по связке годот+шарп на инглише.
> Вот как например в си шарп коде поменять текстуру в скрипте на другую?
Создать текстуру из требуемого источника, например из пикчи.
Image img = new Image();
img.Load("prinimaet string path");
ImageTexture tex = new ImageTexture();
tex.CreateFromImage(img);
tvoySprite.Texture = tex;
>Присвоить свойству текстур у спрайта ссылку не канает, ведь в си шарп это свойство не принимает стринг. А принимает хз что.
Код набирал без студии, проверяй на ашыпки сам. Но смысел, надеюсь, уловил. Алсо, на ютубе есть блогеры, которые пилят уроки по связке годот+шарп на инглише.
>>02313
Алсо, если писать в студии, то в интелисенсе всё подсвечивается с подробными комментами, самодокументируемость, ёпта!
Алсо, если писать в студии, то в интелисенсе всё подсвечивается с подробными комментами, самодокументируемость, ёпта!
>>02281
Ты шутишь так? Более-менее адекватно имитирующие речь сети слишком большие, чтобы работать на ПК в игре реального времени, и их сложно связать с действиями игрового болванчика (наверное, придётся делать обучающие данные вручную?). В то же время есть куча других алгоритмов NLP, которые легче контролировать и которые при этом могут выглядеть умнее нейросети (после того, как обучатся). Правда, я только поверхностно с этим знакомился.
Если ты серьёзно, о чём бы ты хотел говорить с NPC?
>>на нейросетях
>поговорить
Ты шутишь так? Более-менее адекватно имитирующие речь сети слишком большие, чтобы работать на ПК в игре реального времени, и их сложно связать с действиями игрового болванчика (наверное, придётся делать обучающие данные вручную?). В то же время есть куча других алгоритмов NLP, которые легче контролировать и которые при этом могут выглядеть умнее нейросети (после того, как обучатся). Правда, я только поверхностно с этим знакомился.
Если ты серьёзно, о чём бы ты хотел говорить с NPC?
>>02303
Ты сам-то понял, что написал?
На GDScript делаем так:
На C# делаем так:
Разница в том, что в C# нет preload().
>Присвоить свойству текстур у спрайта ссылку не канает, ведь в си шарп это свойство не принимает стринг.
>присвоить ссылку
>не принимает стринг
Ты сам-то понял, что написал?
На GDScript делаем так:
>sprite.texture = ResourceLoader.load("res://icon.png")
На C# делаем так:
>Sprite.Texture = ResourceLoader.Load("res://icon.png") as Texture;
Разница в том, что в C# нет preload().
>>02319
Если я правильно понял, много ресурсов занимает обучение нейросетей, а уж обученная нейросеть работает шустро. Таким образом, я на быстрой девелоперской машине сначала обучаю ботов, потом схороняю полученные массивы с весами в файлы и игра их грузит при старте. Может я конечно неправильно понял.
Как сладкий хлебушек в деревнях ели. Как в море срал. Как с дурой одной 777 выпили и выебал её. У меня много охуительных историй.
Если я правильно понял, много ресурсов занимает обучение нейросетей, а уж обученная нейросеть работает шустро. Таким образом, я на быстрой девелоперской машине сначала обучаю ботов, потом схороняю полученные массивы с весами в файлы и игра их грузит при старте. Может я конечно неправильно понял.
> Если ты серьёзно, о чём бы ты хотел говорить с NPC?
Как сладкий хлебушек в деревнях ели. Как в море срал. Как с дурой одной 777 выпили и выебал её. У меня много охуительных историй.
>>02313
Удивительно что процесс смены текстуры занимает всего лишь жалких 5 строк на си шарп, вместо одной на Гдскрипт. Неудивительно почему все так облизывают встроенный язык
Удивительно что процесс смены текстуры занимает всего лишь жалких 5 строк на си шарп, вместо одной на Гдскрипт. Неудивительно почему все так облизывают встроенный язык
Обнаружил, что в гдскрипте нет целочисленного клэмпа, городить огород из int(clamp()) я не захотел, так что вот, дарю вам, братишки, хацкерскую однострочную утилу:
> static func clampi(value: int, minimum: int, maximum: int) -> int: return minimum if value < minimum else maximum if value > maximum else value
>>02324
Тоже слышал про это.
Ну и будут у тебя в игре "безмозглые" чат-боты, которые ничего не могут запомнить и на каждый вопрос отвечают одинаково, даже если ответ не имеет смысла в контексте всего предыдущего диалога. Стоит ли ради этого обучать нейронку? Нейронки полезны в ситуациях, когда на один и тот же ввод нужен один и тот же ответ, но при этом формальными правилами описать ввод сложно (пример: фотки кошек всегда остаются фотками кошек, но формально описать их сложно, зато есть огромная коллекция фоток для обучения нейронки).
Осмысленная речь человека зависит от огромного количества параметров, не связанных с полученным текстовым вопросом (как то: текущее состояние и воспоминания слушателя, состояние окружающей среды). Т.е. невозможно обучить одну нейронку осмысленной речи при условии дальнейшей фиксации весов. В самом лучшем случае можно ожидать аналог человека с тяжёлой формой амнезии, когда функция памяти полностью утрачена.
Всё это ты мог бы с тем же успехом печатать в блокнот или любому примитивному чат-боту. Игровой бот в идеале способен понять только то, что касается игрового мира вокруг него. Вот осмысленно поговорить с ботом о чём-то, что касается динамически изменяющегося игрового мира (без сценарных рельс) - это уже было бы большим достижением для геймдева.
>обученная нейросеть работает шустро
Тоже слышал про это.
>схороняю полученные массивы с весами в файлы
Ну и будут у тебя в игре "безмозглые" чат-боты, которые ничего не могут запомнить и на каждый вопрос отвечают одинаково, даже если ответ не имеет смысла в контексте всего предыдущего диалога. Стоит ли ради этого обучать нейронку? Нейронки полезны в ситуациях, когда на один и тот же ввод нужен один и тот же ответ, но при этом формальными правилами описать ввод сложно (пример: фотки кошек всегда остаются фотками кошек, но формально описать их сложно, зато есть огромная коллекция фоток для обучения нейронки).
Осмысленная речь человека зависит от огромного количества параметров, не связанных с полученным текстовым вопросом (как то: текущее состояние и воспоминания слушателя, состояние окружающей среды). Т.е. невозможно обучить одну нейронку осмысленной речи при условии дальнейшей фиксации весов. В самом лучшем случае можно ожидать аналог человека с тяжёлой формой амнезии, когда функция памяти полностью утрачена.
>У меня много охуительных историй.
Всё это ты мог бы с тем же успехом печатать в блокнот или любому примитивному чат-боту. Игровой бот в идеале способен понять только то, что касается игрового мира вокруг него. Вот осмысленно поговорить с ботом о чём-то, что касается динамически изменяющегося игрового мира (без сценарных рельс) - это уже было бы большим достижением для геймдева.
>>02361
Этому есть ряд других причин.
1. Встроенный в редактор сцен редактор кода - не нужно запускать несколько тяжеловесных программ и переключать контекст восприятия. Встроенный редактор кода - всегда преимущество, даже если он сам по себе не очень и язык не очень.
2. Синтаксис легче, динамическая типизация, не нужно писать бойлерплейты чтобы начать что-то делать.
3. Отладка всё в том же редакторе, при том интерпретируемость языка позволяет точнее указывать на место ошибки. Хотя не знаю, как это дело обстоит с C#, может, там тоже нормально.
4. GDScript могут адаптировать под конкретные потребности разработчиков игр на Godot, а с C# ты зависишь от текущей реализации Mono. Кстати, в 4.0 не будет C#, его обещают в 4.1, потому что переходят с 5 версии на 6, там полно работы. Стоит ли такая зависимость от третьих лиц? Не думаю.
>почему все так облизывают встроенный язык
Этому есть ряд других причин.
1. Встроенный в редактор сцен редактор кода - не нужно запускать несколько тяжеловесных программ и переключать контекст восприятия. Встроенный редактор кода - всегда преимущество, даже если он сам по себе не очень и язык не очень.
2. Синтаксис легче, динамическая типизация, не нужно писать бойлерплейты чтобы начать что-то делать.
3. Отладка всё в том же редакторе, при том интерпретируемость языка позволяет точнее указывать на место ошибки. Хотя не знаю, как это дело обстоит с C#, может, там тоже нормально.
4. GDScript могут адаптировать под конкретные потребности разработчиков игр на Godot, а с C# ты зависишь от текущей реализации Mono. Кстати, в 4.0 не будет C#, его обещают в 4.1, потому что переходят с 5 версии на 6, там полно работы. Стоит ли такая зависимость от третьих лиц? Не думаю.
Еще один неочевидный нюанс только что вскрыл. Мотайте на ус.
Если у вас есть onready переменные со ссылками на ноды, и если у вас есть экспортные переменные с сетгетами, и в сетгетах используются onready переменные, то у вас возникнет исключение. Потому что, по крайней мере у меня, выходит так, что сеттеры вызываются ДО _ready. В таком случае, в начале сеттера пишите следующий грязный хак:
Если у вас есть onready переменные со ссылками на ноды, и если у вас есть экспортные переменные с сетгетами, и в сетгетах используются onready переменные, то у вас возникнет исключение. Потому что, по крайней мере у меня, выходит так, что сеттеры вызываются ДО _ready. В таком случае, в начале сеттера пишите следующий грязный хак:
> if not is_inside_tree(): return
>>02401
Да я тоже в матчасти нейронок только поверхностно что-то знаю. Но темой чатботов/ИИ мучаюсь практически с самого знакомства с компьютером и программированием, и разочарован тем, что самые передовые разработки ничем не лучше чатботов 90-х, такие же тупые, только теперь ещё и менее предсказуемые (вместо предсказуемо тупого ответа получаем непредсказуемо тупой) и не способны к расширению (хочешь доработать бота? - дополняешь базу обучающих примеров и обучаешь сеть С НУЛЯ).
Конечно, есть и такие примеры, как внезапно правильные ответы на математические вопросы у нейронки, обученной только на текстах, но что-то мне подсказывает, что это только удачное совпадение и на любой подобный вопрос она не ответит.
Да я тоже в матчасти нейронок только поверхностно что-то знаю. Но темой чатботов/ИИ мучаюсь практически с самого знакомства с компьютером и программированием, и разочарован тем, что самые передовые разработки ничем не лучше чатботов 90-х, такие же тупые, только теперь ещё и менее предсказуемые (вместо предсказуемо тупого ответа получаем непредсказуемо тупой) и не способны к расширению (хочешь доработать бота? - дополняешь базу обучающих примеров и обучаешь сеть С НУЛЯ).
Конечно, есть и такие примеры, как внезапно правильные ответы на математические вопросы у нейронки, обученной только на текстах, но что-то мне подсказывает, что это только удачное совпадение и на любой подобный вопрос она не ответит.
>>02406
Всё верно. Потому что _ready - это когда нода уже вошла в дерево и все её потомки уже готовы работать. А сеттеры вызываются при создании ноды и заполнении её данными с диска.
По-моему, порядок событий такой:
_init # создание годы, инициализация её памяти (один раз)
_enter_tree # вход в сцену (может происходить много раз)
_ready # все потомки готовы и нода тоже готова (в первый раз)
Возможно, стоит просто избегать использования onready полей в сеттерах. Или вручную задавать им значения в _init.
>выходит так, что сеттеры вызываются ДО _ready.
Всё верно. Потому что _ready - это когда нода уже вошла в дерево и все её потомки уже готовы работать. А сеттеры вызываются при создании ноды и заполнении её данными с диска.
По-моему, порядок событий такой:
_init # создание годы, инициализация её памяти (один раз)
_enter_tree # вход в сцену (может происходить много раз)
_ready # все потомки готовы и нода тоже готова (в первый раз)
Возможно, стоит просто избегать использования onready полей в сеттерах. Или вручную задавать им значения в _init.
>>02407
Я надеюсь, ты понимаешь, что с чатботом и "поговорить" это была шутка.
Я пока еще недостаточно изучил матчасть, чтобы обоснованно решить, не дохуя ли я ожидаю от нейронок, но суть моей идеи в том, чтобы нейросетевой менеджер (НМ) работал в паре с процедурным генератором (ПГ). ПГ создаёт биомы, расставляет по ним города и сёла, как плейсходлеры, просто точки на карте, а НМ заселяет эти точки популяцией, боты самостоятельно решают, где им строить жилые дома и реально их конструируют из панелей заданного для данной местности набора, соответственно, они должны уметь организовать жилую зону, потом они же решают по аналогичному принципу, где организовать рыночную площадь, где возвести храм, ратуша, доки, мельницы и всё остальное. Так же боты самостоятельно решают, кто из них чем занимается, кто кузнец, а кто доярка и т.д. Далее ПГ предоставляет в эту точку список предварительно спроектированных хитрым образом квестов-заготовок, которые я определил для этой локации. Неписи разбирают себе по квесту, а кто и по два, согласно параметрам в них. Параметры уровня требований о приёме на работу: требуется садовник, возраст от 45 лет, имеющий дочь возрастом от 16 до 22 лет. Неписи, которые взяли себе квесты, встраивают содержащиеся в них диалоговые строки в свои имеющиеся. Так что, о каких-то общих вещах игрок всегда может спросить у любого непися, спросить дорогу там или где тут у вас таверна, но когда у персонажа есть квест, будут возникать дополнительные варианты реплик
Если в заданной точке нет подходящих неписей, НМ запрашивает у ПГ дополнительные итерации и ПГ симулирует переезды и миграцию населения из точки в точку. И факт переезда отражается в биографии. И перезжают неписи не по одному, а строго по процедурным причинам, то есть, ради построения задуманного автором игоры сюжета могут, к примеру сгорать деревни и их население перебираться в другие и т.п.
Казалось бы, зачем здесь нейронка? Вроде как на первый взгляд, всё это можно хитро запроцедурить в ПГ. Но нет, процедурная генерация всё равно будет обладать конечным количеством шаблонов, которые вычислят игроки. В проектируемом мною проекте же шаблонными будут мелкие детали, на уровне фурнитуры. То есть, бочка, она и в Африке бочка, понятно, что бочки расставлены везде и игроки быстро посчитают, что вот этих бочек 6 моделек, а вон тех - 8 моделек. Типовые фразы приветствий игроки тоже быстро вычислят: в этой деревне неписи говорят "привет", а в той говорят "здрасьте". Но когда игроки на форумах будут говорить, "у меня в деревне гадюкино был квест "заплутавшая в лесу", и там кароче её батя, Олаф..." - "да нет же, ты что-то путаешь, в том квесте батю звали Свен!" - "Всмысле, Свен? Торнтон же!" - "Ну да неважно, это ж процедурка. Так вот, когда я её нашёл, она мне и говорит..." - "в смысле, говорит? Её же медведь задрал!" - "Да какой медведь? Её разбойники в рабство продали!" - "Эээ... ващет у меня она сама разбойничью шайку возглавила..." и такие смотрят друг на друга охуевая. "Так чем квест закончился-то?" И тут они понимают что у банального сайд квеста в рандомной деревеньке не менее трёх концовок, и каждый экземпляр квеста уникален.
И вокруг игры начинают нарастать легенды о том, сколько в ней ваще вариантов прохождения может быть. Пишутся фанатские вики. Снимаются подробные видеообзоры.
И таки знаете, пгодаётся немало мегча, таки да.
Я надеюсь, ты понимаешь, что с чатботом и "поговорить" это была шутка.
Я пока еще недостаточно изучил матчасть, чтобы обоснованно решить, не дохуя ли я ожидаю от нейронок, но суть моей идеи в том, чтобы нейросетевой менеджер (НМ) работал в паре с процедурным генератором (ПГ). ПГ создаёт биомы, расставляет по ним города и сёла, как плейсходлеры, просто точки на карте, а НМ заселяет эти точки популяцией, боты самостоятельно решают, где им строить жилые дома и реально их конструируют из панелей заданного для данной местности набора, соответственно, они должны уметь организовать жилую зону, потом они же решают по аналогичному принципу, где организовать рыночную площадь, где возвести храм, ратуша, доки, мельницы и всё остальное. Так же боты самостоятельно решают, кто из них чем занимается, кто кузнец, а кто доярка и т.д. Далее ПГ предоставляет в эту точку список предварительно спроектированных хитрым образом квестов-заготовок, которые я определил для этой локации. Неписи разбирают себе по квесту, а кто и по два, согласно параметрам в них. Параметры уровня требований о приёме на работу: требуется садовник, возраст от 45 лет, имеющий дочь возрастом от 16 до 22 лет. Неписи, которые взяли себе квесты, встраивают содержащиеся в них диалоговые строки в свои имеющиеся. Так что, о каких-то общих вещах игрок всегда может спросить у любого непися, спросить дорогу там или где тут у вас таверна, но когда у персонажа есть квест, будут возникать дополнительные варианты реплик
> "А что грустишь, отец?"
> "Да вот, знаешь ли, горе у меня. На прошлой неделе дочка пошла за грибами в лес и не вернулась. Всей деревней искали - не нашли".
> 1) "а, ну соболезную" [завершить диалог]
> 2) ""ну, буду в лесу, посмотрю, вдруг какие следы обнаружу"
> 2.1) "а ты никак следопыт?"
> 2.2.1) "А то, батя! 80 левела!" [получен квест "заплутавшая в лесу"]
Если в заданной точке нет подходящих неписей, НМ запрашивает у ПГ дополнительные итерации и ПГ симулирует переезды и миграцию населения из точки в точку. И факт переезда отражается в биографии. И перезжают неписи не по одному, а строго по процедурным причинам, то есть, ради построения задуманного автором игоры сюжета могут, к примеру сгорать деревни и их население перебираться в другие и т.п.
Казалось бы, зачем здесь нейронка? Вроде как на первый взгляд, всё это можно хитро запроцедурить в ПГ. Но нет, процедурная генерация всё равно будет обладать конечным количеством шаблонов, которые вычислят игроки. В проектируемом мною проекте же шаблонными будут мелкие детали, на уровне фурнитуры. То есть, бочка, она и в Африке бочка, понятно, что бочки расставлены везде и игроки быстро посчитают, что вот этих бочек 6 моделек, а вон тех - 8 моделек. Типовые фразы приветствий игроки тоже быстро вычислят: в этой деревне неписи говорят "привет", а в той говорят "здрасьте". Но когда игроки на форумах будут говорить, "у меня в деревне гадюкино был квест "заплутавшая в лесу", и там кароче её батя, Олаф..." - "да нет же, ты что-то путаешь, в том квесте батю звали Свен!" - "Всмысле, Свен? Торнтон же!" - "Ну да неважно, это ж процедурка. Так вот, когда я её нашёл, она мне и говорит..." - "в смысле, говорит? Её же медведь задрал!" - "Да какой медведь? Её разбойники в рабство продали!" - "Эээ... ващет у меня она сама разбойничью шайку возглавила..." и такие смотрят друг на друга охуевая. "Так чем квест закончился-то?" И тут они понимают что у банального сайд квеста в рандомной деревеньке не менее трёх концовок, и каждый экземпляр квеста уникален.
И вокруг игры начинают нарастать легенды о том, сколько в ней ваще вариантов прохождения может быть. Пишутся фанатские вики. Снимаются подробные видеообзоры.
И таки знаете, пгодаётся немало мегча, таки да.
>>02407
Я надеюсь, ты понимаешь, что с чатботом и "поговорить" это была шутка.
Я пока еще недостаточно изучил матчасть, чтобы обоснованно решить, не дохуя ли я ожидаю от нейронок, но суть моей идеи в том, чтобы нейросетевой менеджер (НМ) работал в паре с процедурным генератором (ПГ). ПГ создаёт биомы, расставляет по ним города и сёла, как плейсходлеры, просто точки на карте, а НМ заселяет эти точки популяцией, боты самостоятельно решают, где им строить жилые дома и реально их конструируют из панелей заданного для данной местности набора, соответственно, они должны уметь организовать жилую зону, потом они же решают по аналогичному принципу, где организовать рыночную площадь, где возвести храм, ратуша, доки, мельницы и всё остальное. Так же боты самостоятельно решают, кто из них чем занимается, кто кузнец, а кто доярка и т.д. Далее ПГ предоставляет в эту точку список предварительно спроектированных хитрым образом квестов-заготовок, которые я определил для этой локации. Неписи разбирают себе по квесту, а кто и по два, согласно параметрам в них. Параметры уровня требований о приёме на работу: требуется садовник, возраст от 45 лет, имеющий дочь возрастом от 16 до 22 лет. Неписи, которые взяли себе квесты, встраивают содержащиеся в них диалоговые строки в свои имеющиеся. Так что, о каких-то общих вещах игрок всегда может спросить у любого непися, спросить дорогу там или где тут у вас таверна, но когда у персонажа есть квест, будут возникать дополнительные варианты реплик
Если в заданной точке нет подходящих неписей, НМ запрашивает у ПГ дополнительные итерации и ПГ симулирует переезды и миграцию населения из точки в точку. И факт переезда отражается в биографии. И перезжают неписи не по одному, а строго по процедурным причинам, то есть, ради построения задуманного автором игоры сюжета могут, к примеру сгорать деревни и их население перебираться в другие и т.п.
Казалось бы, зачем здесь нейронка? Вроде как на первый взгляд, всё это можно хитро запроцедурить в ПГ. Но нет, процедурная генерация всё равно будет обладать конечным количеством шаблонов, которые вычислят игроки. В проектируемом мною проекте же шаблонными будут мелкие детали, на уровне фурнитуры. То есть, бочка, она и в Африке бочка, понятно, что бочки расставлены везде и игроки быстро посчитают, что вот этих бочек 6 моделек, а вон тех - 8 моделек. Типовые фразы приветствий игроки тоже быстро вычислят: в этой деревне неписи говорят "привет", а в той говорят "здрасьте". Но когда игроки на форумах будут говорить, "у меня в деревне гадюкино был квест "заплутавшая в лесу", и там кароче её батя, Олаф..." - "да нет же, ты что-то путаешь, в том квесте батю звали Свен!" - "Всмысле, Свен? Торнтон же!" - "Ну да неважно, это ж процедурка. Так вот, когда я её нашёл, она мне и говорит..." - "в смысле, говорит? Её же медведь задрал!" - "Да какой медведь? Её разбойники в рабство продали!" - "Эээ... ващет у меня она сама разбойничью шайку возглавила..." и такие смотрят друг на друга охуевая. "Так чем квест закончился-то?" И тут они понимают что у банального сайд квеста в рандомной деревеньке не менее трёх концовок, и каждый экземпляр квеста уникален.
И вокруг игры начинают нарастать легенды о том, сколько в ней ваще вариантов прохождения может быть. Пишутся фанатские вики. Снимаются подробные видеообзоры.
И таки знаете, пгодаётся немало мегча, таки да.
Я надеюсь, ты понимаешь, что с чатботом и "поговорить" это была шутка.
Я пока еще недостаточно изучил матчасть, чтобы обоснованно решить, не дохуя ли я ожидаю от нейронок, но суть моей идеи в том, чтобы нейросетевой менеджер (НМ) работал в паре с процедурным генератором (ПГ). ПГ создаёт биомы, расставляет по ним города и сёла, как плейсходлеры, просто точки на карте, а НМ заселяет эти точки популяцией, боты самостоятельно решают, где им строить жилые дома и реально их конструируют из панелей заданного для данной местности набора, соответственно, они должны уметь организовать жилую зону, потом они же решают по аналогичному принципу, где организовать рыночную площадь, где возвести храм, ратуша, доки, мельницы и всё остальное. Так же боты самостоятельно решают, кто из них чем занимается, кто кузнец, а кто доярка и т.д. Далее ПГ предоставляет в эту точку список предварительно спроектированных хитрым образом квестов-заготовок, которые я определил для этой локации. Неписи разбирают себе по квесту, а кто и по два, согласно параметрам в них. Параметры уровня требований о приёме на работу: требуется садовник, возраст от 45 лет, имеющий дочь возрастом от 16 до 22 лет. Неписи, которые взяли себе квесты, встраивают содержащиеся в них диалоговые строки в свои имеющиеся. Так что, о каких-то общих вещах игрок всегда может спросить у любого непися, спросить дорогу там или где тут у вас таверна, но когда у персонажа есть квест, будут возникать дополнительные варианты реплик
> "А что грустишь, отец?"
> "Да вот, знаешь ли, горе у меня. На прошлой неделе дочка пошла за грибами в лес и не вернулась. Всей деревней искали - не нашли".
> 1) "а, ну соболезную" [завершить диалог]
> 2) ""ну, буду в лесу, посмотрю, вдруг какие следы обнаружу"
> 2.1) "а ты никак следопыт?"
> 2.2.1) "А то, батя! 80 левела!" [получен квест "заплутавшая в лесу"]
Если в заданной точке нет подходящих неписей, НМ запрашивает у ПГ дополнительные итерации и ПГ симулирует переезды и миграцию населения из точки в точку. И факт переезда отражается в биографии. И перезжают неписи не по одному, а строго по процедурным причинам, то есть, ради построения задуманного автором игоры сюжета могут, к примеру сгорать деревни и их население перебираться в другие и т.п.
Казалось бы, зачем здесь нейронка? Вроде как на первый взгляд, всё это можно хитро запроцедурить в ПГ. Но нет, процедурная генерация всё равно будет обладать конечным количеством шаблонов, которые вычислят игроки. В проектируемом мною проекте же шаблонными будут мелкие детали, на уровне фурнитуры. То есть, бочка, она и в Африке бочка, понятно, что бочки расставлены везде и игроки быстро посчитают, что вот этих бочек 6 моделек, а вон тех - 8 моделек. Типовые фразы приветствий игроки тоже быстро вычислят: в этой деревне неписи говорят "привет", а в той говорят "здрасьте". Но когда игроки на форумах будут говорить, "у меня в деревне гадюкино был квест "заплутавшая в лесу", и там кароче её батя, Олаф..." - "да нет же, ты что-то путаешь, в том квесте батю звали Свен!" - "Всмысле, Свен? Торнтон же!" - "Ну да неважно, это ж процедурка. Так вот, когда я её нашёл, она мне и говорит..." - "в смысле, говорит? Её же медведь задрал!" - "Да какой медведь? Её разбойники в рабство продали!" - "Эээ... ващет у меня она сама разбойничью шайку возглавила..." и такие смотрят друг на друга охуевая. "Так чем квест закончился-то?" И тут они понимают что у банального сайд квеста в рандомной деревеньке не менее трёх концовок, и каждый экземпляр квеста уникален.
И вокруг игры начинают нарастать легенды о том, сколько в ней ваще вариантов прохождения может быть. Пишутся фанатские вики. Снимаются подробные видеообзоры.
И таки знаете, пгодаётся немало мегча, таки да.
>>02408
Но зачем? У меня в коде переменная объявляется с дефолтным значением.
Зачем её ещё раз заполнять тем же самым? Тупо зделано. Пусть Хуан переделывает. Если бы я в объявлении не указал значение, я был бы согласен, что сеттер вызывается.
> А сеттеры вызываются при создании ноды и заполнении её данными с диска.
Но зачем? У меня в коде переменная объявляется с дефолтным значением.
> export (myenum) var myvar : int = myenum.mydefault setget _set_my_var
Зачем её ещё раз заполнять тем же самым? Тупо зделано. Пусть Хуан переделывает. Если бы я в объявлении не указал значение, я был бы согласен, что сеттер вызывается.
> export (myenum) var myvar setget _set_my_var
>>02416
Ах да. Данными с диска. Десериализация. Туплю.
Но тогда тоже претензия. Мне может и не надо сериализовать экспорт, я его хочу просто в инспекторе настраивать. Пусть делают отдельный кейворд на инспектор.
Ах да. Данными с диска. Десериализация. Туплю.
Но тогда тоже претензия. Мне может и не надо сериализовать экспорт, я его хочу просто в инспекторе настраивать. Пусть делают отдельный кейворд на инспектор.
>>02417
По аналогии с экспортом
Оформите фичреквест, кто на гитхабе зависает?
По аналогии с экспортом
> editor (myenum) var myvar : int = myenum.mydefault setget _set_my_var
Оформите фичреквест, кто на гитхабе зависает?
>>02417
Как ты себе это представляешь? Ты же всё равно потом сохранишь сцену как tscn, и все твои настройки будут записаны в файл. Если тебе не нужно сохранять настройки в tscn, то просто не используй слово export и не пользуйся инспектором.
>>02418
Тебе лучше знать, зачем тебе эта фича - ты и оформляй. Иначе получится "сломанный телефон" - кому это нужно?
>не надо сериализовать экспорт
>я его хочу просто в инспекторе настраивать
Как ты себе это представляешь? Ты же всё равно потом сохранишь сцену как tscn, и все твои настройки будут записаны в файл. Если тебе не нужно сохранять настройки в tscn, то просто не используй слово export и не пользуйся инспектором.
>>02418
>Оформите фичреквест
Тебе лучше знать, зачем тебе эта фича - ты и оформляй. Иначе получится "сломанный телефон" - кому это нужно?
>>02445
Дополню тебя. Сам путь к скрипту записывается в файл, как ExtResource ( n ), так что дефолтные значения уже есть, если они есть в скрипте.
Если же они не отличаются, то я хочу, чтобы система их и не трогала. Получается двойная перезапись одинаковых значений. Насчёт фичреквеста я конечно погорячился, да. Дополнительный кейворд не нужен, нужно, чтобы сериализатор умел различать экспорты с явными дефолтами от экспортов без дефолтов.
> и все твои настройки будут записаны в файл в том случае, если они отличаются от указанных в скрипте
Дополню тебя. Сам путь к скрипту записывается в файл, как ExtResource ( n ), так что дефолтные значения уже есть, если они есть в скрипте.
Если же они не отличаются, то я хочу, чтобы система их и не трогала. Получается двойная перезапись одинаковых значений. Насчёт фичреквеста я конечно погорячился, да. Дополнительный кейворд не нужен, нужно, чтобы сериализатор умел различать экспорты с явными дефолтами от экспортов без дефолтов.
>>02448
Еще раз повторюсь, для меня это не проблема. Этот подводный камень я обхожу одной строкой:
>>02406
Вообще, классически такие вещи обрабатываются так:
Но у меня сеттер посложнее, ему надо много манипуляций делать с субнодами, поэтому я просто игнорирую присвоение сеттером, если нода не в дереве.
Еще раз повторюсь, для меня это не проблема. Этот подводный камень я обхожу одной строкой:
>>02406
> if not is_inside_tree(): return
Вообще, классически такие вещи обрабатываются так:
> func set_myvar(new_var): if myvar != new_var: myvar = new_var
Но у меня сеттер посложнее, ему надо много манипуляций делать с субнодами, поэтому я просто игнорирую присвоение сеттером, если нода не в дереве.
>>02450
Может быть, в таком случае сеттер просто не нужен? Делай эти манипуляции с нодами в отдельном методе, из названия которого ясно, что он работает с нодами. И вызывай его, соответственно, в обработчике _ready, когда эти ноды уже существуют.
Вообще, по-моему, сеттер не должен делать много скрытной работы, это глупо, т.к. извне это выглядит как простое присваивание. Если нужно много работы - нужен отдельный метод.
Вот мы кладём предмет в картонную коробку, и ожидаем, что предмет окажется в картонной коробке, а не произойдёт ядерная война или что-то подобное. Картонная коробка не должна устраивать глобальные катаклизмы, хотя может, например, намочить положенный предмет, если она сама мокрая, или испачкать предмет пылью, если она пыльная. А у тебя коробка как раз что-то там глобально замышляет и каждый раз обламывается, когда мир не до конца существует и поэтому не может обработать глобальный катаклизм.
Впрочем, я не знаю, прав ли я в этой теме.
>ему надо много манипуляций делать с субнодами
Может быть, в таком случае сеттер просто не нужен? Делай эти манипуляции с нодами в отдельном методе, из названия которого ясно, что он работает с нодами. И вызывай его, соответственно, в обработчике _ready, когда эти ноды уже существуют.
Вообще, по-моему, сеттер не должен делать много скрытной работы, это глупо, т.к. извне это выглядит как простое присваивание. Если нужно много работы - нужен отдельный метод.
Вот мы кладём предмет в картонную коробку, и ожидаем, что предмет окажется в картонной коробке, а не произойдёт ядерная война или что-то подобное. Картонная коробка не должна устраивать глобальные катаклизмы, хотя может, например, намочить положенный предмет, если она сама мокрая, или испачкать предмет пылью, если она пыльная. А у тебя коробка как раз что-то там глобально замышляет и каждый раз обламывается, когда мир не до конца существует и поэтому не может обработать глобальный катаклизм.
Впрочем, я не знаю, прав ли я в этой теме.
>>02413
Жаль, очень жаль. Чёт мало кто этим интересуется(
Разве заселение не работа процедурного генератора? Впрочем, нейросети - это один из методов процедурной генерации.
Хаотичное самовольное строительство происходит в местах полной анархии. Где есть хоть какая-то организация - кто-то один определяет или утверждает планировку населённого пункта и назначение зданий... Даже если ИРЛ это не всегда так, в рамках игрового мира проще создать один планировщик, чем доверять строительство кучке тупых болванчиков, а то понастроят всякой фигни и передохнут.
Ну это вообще кирилльство какое-то. Я тоже хочу сделать генератор зданий из блоков/панелей, но я планирую использовать заранее заготовленные шаблоны. Какой смысл требовать с ботов выдумывать новые здания самостоятельно?
В условиях маленького поселения выбирать профессию самостоятельно не получится. Это тебе не большой город, в котором всё что угодно можно купить и можно быть кем угодно, были бы стартовый капитал и желание. В контексте игры проще балансить поселение, когда профессии распределяет кто-то один.
Начинал с ботов, решающих всё в своей жизни самостоятельно, а закончил шаблонами. Смысл? Твои шаблоны быстро закончатся и надоедят игроку, а самостоятельное строительство городов ботами не повлияет на геймплей (выполнение квестов?). Выход: позволить ботам создавать "квесты" по их реальным потребностям, даже если это будет означать нехватку задач для игрока.
Ты планируешь грандиозную по своей сложности симуляцию жизни, но при этом хочешь делать какой-то рельсовый сюжет? Это принципиально несовместимые вещи. Сюжет - это игра актёров на сцене театра по строгому сюжету, а жизнь - адаптация к хаотично меняющимся условиям среды. Своевольный ИИ бесполезен и даже вреден для какого-либо повествования.
Как раз бочек можно миллион вариаций нагенерировать на простых параметрических шаблонах (высота, радиус, число досок, колец, тип дерева, возраст и т.д.), и сложно будет найти точно совпадающие. Но играм такой уровень генерации обычно не нужен.
А тут вообще смысла нет генерировать разные варианты фраз, их предназначение - донести информацию, а не быть красивыми или блистать оригинальностью. Разве что можно отразить характер, присвоив персонажу соответствующий "скин" фраз (ну ты понял).
Ты и правда переоцениваешь нейросети. Нейросеть не будет генерировать бесконечное количество квестов, и уж тем более квесты её авторства редко будут осмысленными - погугли, как пытаются делать нейросетевые генераторы сюжета. Даже всем известный AIDungeon несёт дичь, которая популярна только потому, что над ней можно поржать как конь. А ты хочешь что-то серьёзное.
Да и нужна ли игроку уникальность квестов? Тем более побочных квестов, раз ты хочешь сделать рельсовый сюжет со сгорающими по расписанию деревнями, лол. Если делаешь фиксированный сюжет, делай и квесты фиксированными или шаблонными, всё равно дальше "передай/принеси/спаси/убей/собери/сопроводи" не уйдёшь. Нет принципиальной разницы между "убей 15 волков для моей больной волчанкой дочери-шизофренички" и "убей 25 молодых зайчиков для моего больного хитростью зятя-некропедозоофила", ты в любом случае скипаешь унылый текст и идёшь убивать несчастных мобов ради лута, денег, условного респекта или прогресса. Всё.
Альтернатива - избавиться от сюжета и классических рпгшных квестов, и позволить ботам давать игроку реально полезные им (ботам) задания, т.е. чтобы они просили о том, в чём нуждаются, но не способны сами добыть. Также они могли бы давать такие задания друг другу, что логично и должно усложнять симуляцию социума. Но это уже получается игра в унылую серую жизнь, а не героическое фэнтези про драконорождённого, героически собирающего шкурки кроликов по всему континенту ради кучки золотых и нового меча. Ну ты понял, обычным казуальным игрокам это всё не будет интересно, а нас, аутистов, слишком мало.
>с чатботом и "поговорить" это была шутка
Жаль, очень жаль. Чёт мало кто этим интересуется(
>нейросетевой менеджер
>заселяет эти точки популяцией
Разве заселение не работа процедурного генератора? Впрочем, нейросети - это один из методов процедурной генерации.
>самостоятельно решают, где им строить жилые дома
>где организовать рыночную площадь, где возвести храм, ратуша, доки, мельницы и всё остальное
Хаотичное самовольное строительство происходит в местах полной анархии. Где есть хоть какая-то организация - кто-то один определяет или утверждает планировку населённого пункта и назначение зданий... Даже если ИРЛ это не всегда так, в рамках игрового мира проще создать один планировщик, чем доверять строительство кучке тупых болванчиков, а то понастроят всякой фигни и передохнут.
>реально их конструируют из панелей
Ну это вообще кирилльство какое-то. Я тоже хочу сделать генератор зданий из блоков/панелей, но я планирую использовать заранее заготовленные шаблоны. Какой смысл требовать с ботов выдумывать новые здания самостоятельно?
>кто кузнец, а кто доярка
В условиях маленького поселения выбирать профессию самостоятельно не получится. Это тебе не большой город, в котором всё что угодно можно купить и можно быть кем угодно, были бы стартовый капитал и желание. В контексте игры проще балансить поселение, когда профессии распределяет кто-то один.
>список предварительно спроектированных хитрым образом квестов-заготовок, которые я определил для этой локации
Начинал с ботов, решающих всё в своей жизни самостоятельно, а закончил шаблонами. Смысл? Твои шаблоны быстро закончатся и надоедят игроку, а самостоятельное строительство городов ботами не повлияет на геймплей (выполнение квестов?). Выход: позволить ботам создавать "квесты" по их реальным потребностям, даже если это будет означать нехватку задач для игрока.
>ради построения задуманного автором игоры сюжета
Ты планируешь грандиозную по своей сложности симуляцию жизни, но при этом хочешь делать какой-то рельсовый сюжет? Это принципиально несовместимые вещи. Сюжет - это игра актёров на сцене театра по строгому сюжету, а жизнь - адаптация к хаотично меняющимся условиям среды. Своевольный ИИ бесполезен и даже вреден для какого-либо повествования.
>вот этих бочек 6 моделек, а вон тех - 8 моделек
Как раз бочек можно миллион вариаций нагенерировать на простых параметрических шаблонах (высота, радиус, число досок, колец, тип дерева, возраст и т.д.), и сложно будет найти точно совпадающие. Но играм такой уровень генерации обычно не нужен.
>Типовые фразы приветствий
А тут вообще смысла нет генерировать разные варианты фраз, их предназначение - донести информацию, а не быть красивыми или блистать оригинальностью. Разве что можно отразить характер, присвоив персонажу соответствующий "скин" фраз (ну ты понял).
>процедурная генерация всё равно будет обладать конечным количеством шаблонов, которые вычислят игроки
>каждый экземпляр квеста уникален
Ты и правда переоцениваешь нейросети. Нейросеть не будет генерировать бесконечное количество квестов, и уж тем более квесты её авторства редко будут осмысленными - погугли, как пытаются делать нейросетевые генераторы сюжета. Даже всем известный AIDungeon несёт дичь, которая популярна только потому, что над ней можно поржать как конь. А ты хочешь что-то серьёзное.
Да и нужна ли игроку уникальность квестов? Тем более побочных квестов, раз ты хочешь сделать рельсовый сюжет со сгорающими по расписанию деревнями, лол. Если делаешь фиксированный сюжет, делай и квесты фиксированными или шаблонными, всё равно дальше "передай/принеси/спаси/убей/собери/сопроводи" не уйдёшь. Нет принципиальной разницы между "убей 15 волков для моей больной волчанкой дочери-шизофренички" и "убей 25 молодых зайчиков для моего больного хитростью зятя-некропедозоофила", ты в любом случае скипаешь унылый текст и идёшь убивать несчастных мобов ради лута, денег, условного респекта или прогресса. Всё.
Альтернатива - избавиться от сюжета и классических рпгшных квестов, и позволить ботам давать игроку реально полезные им (ботам) задания, т.е. чтобы они просили о том, в чём нуждаются, но не способны сами добыть. Также они могли бы давать такие задания друг другу, что логично и должно усложнять симуляцию социума. Но это уже получается игра в унылую серую жизнь, а не героическое фэнтези про драконорождённого, героически собирающего шкурки кроликов по всему континенту ради кучки золотых и нового меча. Ну ты понял, обычным казуальным игрокам это всё не будет интересно, а нас, аутистов, слишком мало.
>>02413
Жаль, очень жаль. Чёт мало кто этим интересуется(
Разве заселение не работа процедурного генератора? Впрочем, нейросети - это один из методов процедурной генерации.
Хаотичное самовольное строительство происходит в местах полной анархии. Где есть хоть какая-то организация - кто-то один определяет или утверждает планировку населённого пункта и назначение зданий... Даже если ИРЛ это не всегда так, в рамках игрового мира проще создать один планировщик, чем доверять строительство кучке тупых болванчиков, а то понастроят всякой фигни и передохнут.
Ну это вообще кирилльство какое-то. Я тоже хочу сделать генератор зданий из блоков/панелей, но я планирую использовать заранее заготовленные шаблоны. Какой смысл требовать с ботов выдумывать новые здания самостоятельно?
В условиях маленького поселения выбирать профессию самостоятельно не получится. Это тебе не большой город, в котором всё что угодно можно купить и можно быть кем угодно, были бы стартовый капитал и желание. В контексте игры проще балансить поселение, когда профессии распределяет кто-то один.
Начинал с ботов, решающих всё в своей жизни самостоятельно, а закончил шаблонами. Смысл? Твои шаблоны быстро закончатся и надоедят игроку, а самостоятельное строительство городов ботами не повлияет на геймплей (выполнение квестов?). Выход: позволить ботам создавать "квесты" по их реальным потребностям, даже если это будет означать нехватку задач для игрока.
Ты планируешь грандиозную по своей сложности симуляцию жизни, но при этом хочешь делать какой-то рельсовый сюжет? Это принципиально несовместимые вещи. Сюжет - это игра актёров на сцене театра по строгому сюжету, а жизнь - адаптация к хаотично меняющимся условиям среды. Своевольный ИИ бесполезен и даже вреден для какого-либо повествования.
Как раз бочек можно миллион вариаций нагенерировать на простых параметрических шаблонах (высота, радиус, число досок, колец, тип дерева, возраст и т.д.), и сложно будет найти точно совпадающие. Но играм такой уровень генерации обычно не нужен.
А тут вообще смысла нет генерировать разные варианты фраз, их предназначение - донести информацию, а не быть красивыми или блистать оригинальностью. Разве что можно отразить характер, присвоив персонажу соответствующий "скин" фраз (ну ты понял).
Ты и правда переоцениваешь нейросети. Нейросеть не будет генерировать бесконечное количество квестов, и уж тем более квесты её авторства редко будут осмысленными - погугли, как пытаются делать нейросетевые генераторы сюжета. Даже всем известный AIDungeon несёт дичь, которая популярна только потому, что над ней можно поржать как конь. А ты хочешь что-то серьёзное.
Да и нужна ли игроку уникальность квестов? Тем более побочных квестов, раз ты хочешь сделать рельсовый сюжет со сгорающими по расписанию деревнями, лол. Если делаешь фиксированный сюжет, делай и квесты фиксированными или шаблонными, всё равно дальше "передай/принеси/спаси/убей/собери/сопроводи" не уйдёшь. Нет принципиальной разницы между "убей 15 волков для моей больной волчанкой дочери-шизофренички" и "убей 25 молодых зайчиков для моего больного хитростью зятя-некропедозоофила", ты в любом случае скипаешь унылый текст и идёшь убивать несчастных мобов ради лута, денег, условного респекта или прогресса. Всё.
Альтернатива - избавиться от сюжета и классических рпгшных квестов, и позволить ботам давать игроку реально полезные им (ботам) задания, т.е. чтобы они просили о том, в чём нуждаются, но не способны сами добыть. Также они могли бы давать такие задания друг другу, что логично и должно усложнять симуляцию социума. Но это уже получается игра в унылую серую жизнь, а не героическое фэнтези про драконорождённого, героически собирающего шкурки кроликов по всему континенту ради кучки золотых и нового меча. Ну ты понял, обычным казуальным игрокам это всё не будет интересно, а нас, аутистов, слишком мало.
>с чатботом и "поговорить" это была шутка
Жаль, очень жаль. Чёт мало кто этим интересуется(
>нейросетевой менеджер
>заселяет эти точки популяцией
Разве заселение не работа процедурного генератора? Впрочем, нейросети - это один из методов процедурной генерации.
>самостоятельно решают, где им строить жилые дома
>где организовать рыночную площадь, где возвести храм, ратуша, доки, мельницы и всё остальное
Хаотичное самовольное строительство происходит в местах полной анархии. Где есть хоть какая-то организация - кто-то один определяет или утверждает планировку населённого пункта и назначение зданий... Даже если ИРЛ это не всегда так, в рамках игрового мира проще создать один планировщик, чем доверять строительство кучке тупых болванчиков, а то понастроят всякой фигни и передохнут.
>реально их конструируют из панелей
Ну это вообще кирилльство какое-то. Я тоже хочу сделать генератор зданий из блоков/панелей, но я планирую использовать заранее заготовленные шаблоны. Какой смысл требовать с ботов выдумывать новые здания самостоятельно?
>кто кузнец, а кто доярка
В условиях маленького поселения выбирать профессию самостоятельно не получится. Это тебе не большой город, в котором всё что угодно можно купить и можно быть кем угодно, были бы стартовый капитал и желание. В контексте игры проще балансить поселение, когда профессии распределяет кто-то один.
>список предварительно спроектированных хитрым образом квестов-заготовок, которые я определил для этой локации
Начинал с ботов, решающих всё в своей жизни самостоятельно, а закончил шаблонами. Смысл? Твои шаблоны быстро закончатся и надоедят игроку, а самостоятельное строительство городов ботами не повлияет на геймплей (выполнение квестов?). Выход: позволить ботам создавать "квесты" по их реальным потребностям, даже если это будет означать нехватку задач для игрока.
>ради построения задуманного автором игоры сюжета
Ты планируешь грандиозную по своей сложности симуляцию жизни, но при этом хочешь делать какой-то рельсовый сюжет? Это принципиально несовместимые вещи. Сюжет - это игра актёров на сцене театра по строгому сюжету, а жизнь - адаптация к хаотично меняющимся условиям среды. Своевольный ИИ бесполезен и даже вреден для какого-либо повествования.
>вот этих бочек 6 моделек, а вон тех - 8 моделек
Как раз бочек можно миллион вариаций нагенерировать на простых параметрических шаблонах (высота, радиус, число досок, колец, тип дерева, возраст и т.д.), и сложно будет найти точно совпадающие. Но играм такой уровень генерации обычно не нужен.
>Типовые фразы приветствий
А тут вообще смысла нет генерировать разные варианты фраз, их предназначение - донести информацию, а не быть красивыми или блистать оригинальностью. Разве что можно отразить характер, присвоив персонажу соответствующий "скин" фраз (ну ты понял).
>процедурная генерация всё равно будет обладать конечным количеством шаблонов, которые вычислят игроки
>каждый экземпляр квеста уникален
Ты и правда переоцениваешь нейросети. Нейросеть не будет генерировать бесконечное количество квестов, и уж тем более квесты её авторства редко будут осмысленными - погугли, как пытаются делать нейросетевые генераторы сюжета. Даже всем известный AIDungeon несёт дичь, которая популярна только потому, что над ней можно поржать как конь. А ты хочешь что-то серьёзное.
Да и нужна ли игроку уникальность квестов? Тем более побочных квестов, раз ты хочешь сделать рельсовый сюжет со сгорающими по расписанию деревнями, лол. Если делаешь фиксированный сюжет, делай и квесты фиксированными или шаблонными, всё равно дальше "передай/принеси/спаси/убей/собери/сопроводи" не уйдёшь. Нет принципиальной разницы между "убей 15 волков для моей больной волчанкой дочери-шизофренички" и "убей 25 молодых зайчиков для моего больного хитростью зятя-некропедозоофила", ты в любом случае скипаешь унылый текст и идёшь убивать несчастных мобов ради лута, денег, условного респекта или прогресса. Всё.
Альтернатива - избавиться от сюжета и классических рпгшных квестов, и позволить ботам давать игроку реально полезные им (ботам) задания, т.е. чтобы они просили о том, в чём нуждаются, но не способны сами добыть. Также они могли бы давать такие задания друг другу, что логично и должно усложнять симуляцию социума. Но это уже получается игра в унылую серую жизнь, а не героическое фэнтези про драконорождённого, героически собирающего шкурки кроликов по всему континенту ради кучки золотых и нового меча. Ну ты понял, обычным казуальным игрокам это всё не будет интересно, а нас, аутистов, слишком мало.
>>02480
Сценарию, конечно же.
Не перечитал перед отправкой, но, думаю, суть ясна.
>>02413
Ещё была мысль посоветовать глянуть генетические алгоритмы, но как дошёл до части про захардкоженный сюжет - забыл. Думаю, тебе нужно не волшебную палочку искать, а перестать лениться и написать нормальный сюжет, если ты хочешь сюжетную игру.
Что касается нейросетей, остаётся нерешённым вопрос, как ты планируешь обучать эту свою нейронку. Способов обучения существует несколько, но все они завязаны на куче данных, проходящих через нейронку. Где взять данные? Не кормить же нейронку "Войной и миром", лол. Конечно, существует GAN, но для начала её работы в любом случае нужна куча данных, а дальше она только оттачивает свои умения.
Поскольку вряд ли ты найдёшь готовый набор данных, тебе придётся создавать его вручную. Вопрос: не окажется ли на практике, что ты всю работу сделаешь вместо нейронки? Или тебе придётся писать классический генератор на шаблонах, чтобы генерировать данные для обучения генерирующей нейронки... Короче, не существует волшебной палочки, которая бы создала что-то хорошее из вакуума вместо тебя. Нейросети только учатся тому, что уже есть.
Ммм... Ошибочка, на самом деле "волшебная палочка" есть - зовут её эволюцией, и она симулируется упомянутыми мной генетическими алгоритмами. Но, как ты, возможно, догадываешься, эволюции нужно миллиарды лет/поколений для того, чтобы создать нечто интересное, а на компьютере симуляция будет тем медленнее, чем меньше геном, а чем меньше геном, тем меньше потенциал эволюции. И в любом случае она непредсказуема, можно получить что-то крутое, а можно не получить ничего, предсказать что-то слишком сложно. Короче, она слабо подходит для твоей задачи, как мне кажется. Тем более я не представляю, как формализовать "интересные игроку квесты" (без критериев отбора эволюция не заработает, будет просто бесконечное число рандомных мутаций или "квестов-мутантов")...
А вообще, ты плохо описал задачу. Задача - сделать максимальное количество разных квестов в процедурно генерируемом мире? Просто ты подробно описал способ решения задачи, но сама задача описана глупым примером восторженных игроков.
Алсо,
Т.е. легко нагенерировать тысячи разных квестов, но с точки зрения игрока разницы не будет, как для тебя нет разницы между двумя мисками каши (физически они всегда разные). Ну, я об этом уже выше упоминал в примере с убийством мобов...
>по строгому сюжету
Сценарию, конечно же.
Не перечитал перед отправкой, но, думаю, суть ясна.
>>02413
Ещё была мысль посоветовать глянуть генетические алгоритмы, но как дошёл до части про захардкоженный сюжет - забыл. Думаю, тебе нужно не волшебную палочку искать, а перестать лениться и написать нормальный сюжет, если ты хочешь сюжетную игру.
Что касается нейросетей, остаётся нерешённым вопрос, как ты планируешь обучать эту свою нейронку. Способов обучения существует несколько, но все они завязаны на куче данных, проходящих через нейронку. Где взять данные? Не кормить же нейронку "Войной и миром", лол. Конечно, существует GAN, но для начала её работы в любом случае нужна куча данных, а дальше она только оттачивает свои умения.
Поскольку вряд ли ты найдёшь готовый набор данных, тебе придётся создавать его вручную. Вопрос: не окажется ли на практике, что ты всю работу сделаешь вместо нейронки? Или тебе придётся писать классический генератор на шаблонах, чтобы генерировать данные для обучения генерирующей нейронки... Короче, не существует волшебной палочки, которая бы создала что-то хорошее из вакуума вместо тебя. Нейросети только учатся тому, что уже есть.
Ммм... Ошибочка, на самом деле "волшебная палочка" есть - зовут её эволюцией, и она симулируется упомянутыми мной генетическими алгоритмами. Но, как ты, возможно, догадываешься, эволюции нужно миллиарды лет/поколений для того, чтобы создать нечто интересное, а на компьютере симуляция будет тем медленнее, чем меньше геном, а чем меньше геном, тем меньше потенциал эволюции. И в любом случае она непредсказуема, можно получить что-то крутое, а можно не получить ничего, предсказать что-то слишком сложно. Короче, она слабо подходит для твоей задачи, как мне кажется. Тем более я не представляю, как формализовать "интересные игроку квесты" (без критериев отбора эволюция не заработает, будет просто бесконечное число рандомных мутаций или "квестов-мутантов")...
А вообще, ты плохо описал задачу. Задача - сделать максимальное количество разных квестов в процедурно генерируемом мире? Просто ты подробно описал способ решения задачи, но сама задача описана глупым примером восторженных игроков.
Алсо,
>...it is very easy to pour 10,000 bowls of plain oatmeal, with each oat being in a different position and each bowl essentially unique, but it is very hard to make these differences matter to an audience, and be perceived as truly different in any memorable or thought-provoking way.
Т.е. легко нагенерировать тысячи разных квестов, но с точки зрения игрока разницы не будет, как для тебя нет разницы между двумя мисками каши (физически они всегда разные). Ну, я об этом уже выше упоминал в примере с убийством мобов...
>>02480
Сценарию, конечно же.
Не перечитал перед отправкой, но, думаю, суть ясна.
>>02413
Ещё была мысль посоветовать глянуть генетические алгоритмы, но как дошёл до части про захардкоженный сюжет - забыл. Думаю, тебе нужно не волшебную палочку искать, а перестать лениться и написать нормальный сюжет, если ты хочешь сюжетную игру.
Что касается нейросетей, остаётся нерешённым вопрос, как ты планируешь обучать эту свою нейронку. Способов обучения существует несколько, но все они завязаны на куче данных, проходящих через нейронку. Где взять данные? Не кормить же нейронку "Войной и миром", лол. Конечно, существует GAN, но для начала её работы в любом случае нужна куча данных, а дальше она только оттачивает свои умения.
Поскольку вряд ли ты найдёшь готовый набор данных, тебе придётся создавать его вручную. Вопрос: не окажется ли на практике, что ты всю работу сделаешь вместо нейронки? Или тебе придётся писать классический генератор на шаблонах, чтобы генерировать данные для обучения генерирующей нейронки... Короче, не существует волшебной палочки, которая бы создала что-то хорошее из вакуума вместо тебя. Нейросети только учатся тому, что уже есть.
Ммм... Ошибочка, на самом деле "волшебная палочка" есть - зовут её эволюцией, и она симулируется упомянутыми мной генетическими алгоритмами. Но, как ты, возможно, догадываешься, эволюции нужно миллиарды лет/поколений для того, чтобы создать нечто интересное, а на компьютере симуляция будет тем медленнее, чем меньше геном, а чем меньше геном, тем меньше потенциал эволюции. И в любом случае она непредсказуема, можно получить что-то крутое, а можно не получить ничего, предсказать что-то слишком сложно. Короче, она слабо подходит для твоей задачи, как мне кажется. Тем более я не представляю, как формализовать "интересные игроку квесты" (без критериев отбора эволюция не заработает, будет просто бесконечное число рандомных мутаций или "квестов-мутантов")...
А вообще, ты плохо описал задачу. Задача - сделать максимальное количество разных квестов в процедурно генерируемом мире? Просто ты подробно описал способ решения задачи, но сама задача описана глупым примером восторженных игроков.
Алсо,
Т.е. легко нагенерировать тысячи разных квестов, но с точки зрения игрока разницы не будет, как для тебя нет разницы между двумя мисками каши (физически они всегда разные). Ну, я об этом уже выше упоминал в примере с убийством мобов...
>по строгому сюжету
Сценарию, конечно же.
Не перечитал перед отправкой, но, думаю, суть ясна.
>>02413
Ещё была мысль посоветовать глянуть генетические алгоритмы, но как дошёл до части про захардкоженный сюжет - забыл. Думаю, тебе нужно не волшебную палочку искать, а перестать лениться и написать нормальный сюжет, если ты хочешь сюжетную игру.
Что касается нейросетей, остаётся нерешённым вопрос, как ты планируешь обучать эту свою нейронку. Способов обучения существует несколько, но все они завязаны на куче данных, проходящих через нейронку. Где взять данные? Не кормить же нейронку "Войной и миром", лол. Конечно, существует GAN, но для начала её работы в любом случае нужна куча данных, а дальше она только оттачивает свои умения.
Поскольку вряд ли ты найдёшь готовый набор данных, тебе придётся создавать его вручную. Вопрос: не окажется ли на практике, что ты всю работу сделаешь вместо нейронки? Или тебе придётся писать классический генератор на шаблонах, чтобы генерировать данные для обучения генерирующей нейронки... Короче, не существует волшебной палочки, которая бы создала что-то хорошее из вакуума вместо тебя. Нейросети только учатся тому, что уже есть.
Ммм... Ошибочка, на самом деле "волшебная палочка" есть - зовут её эволюцией, и она симулируется упомянутыми мной генетическими алгоритмами. Но, как ты, возможно, догадываешься, эволюции нужно миллиарды лет/поколений для того, чтобы создать нечто интересное, а на компьютере симуляция будет тем медленнее, чем меньше геном, а чем меньше геном, тем меньше потенциал эволюции. И в любом случае она непредсказуема, можно получить что-то крутое, а можно не получить ничего, предсказать что-то слишком сложно. Короче, она слабо подходит для твоей задачи, как мне кажется. Тем более я не представляю, как формализовать "интересные игроку квесты" (без критериев отбора эволюция не заработает, будет просто бесконечное число рандомных мутаций или "квестов-мутантов")...
А вообще, ты плохо описал задачу. Задача - сделать максимальное количество разных квестов в процедурно генерируемом мире? Просто ты подробно описал способ решения задачи, но сама задача описана глупым примером восторженных игроков.
Алсо,
>...it is very easy to pour 10,000 bowls of plain oatmeal, with each oat being in a different position and each bowl essentially unique, but it is very hard to make these differences matter to an audience, and be perceived as truly different in any memorable or thought-provoking way.
Т.е. легко нагенерировать тысячи разных квестов, но с точки зрения игрока разницы не будет, как для тебя нет разницы между двумя мисками каши (физически они всегда разные). Ну, я об этом уже выше упоминал в примере с убийством мобов...
>>02486
Чем БОЛЬШЕ геном. Ну, это очевидно...
По-моему, это главная причина, почему ГА редко используются: симуляция чего-то интересного слишком долгая.
>>02413
Вообще, советую попробовать вручную придумать ряд квестов и вариаций для них. И представить, как ты, игрок, будешь их находить, получать и выполнять. Скорее всего тебе быстро надоест и ты наиграешься, не потратив времени на разработку игры)))
Т.е. даже плевать на детали реализации. Положим, мы можем создать миллиарды осмысленных квестов. Вопрос: зачем это игроку? Большинство игроков скипают любые тексты, катсцены и прочий сюжет при первой возможности. Люди играть пришли, а ты им буковы. Не любят люди буковы. Люди любят смотреть на сиськи и срать в твиттер. А почитать и в библиотеке можно...
Не говорю про себя, я-то стараюсь всё внимательно читать, но, тем не менее, не люблю игры с большим количеством текста...
>тем медленнее, чем меньше геном
Чем БОЛЬШЕ геном. Ну, это очевидно...
По-моему, это главная причина, почему ГА редко используются: симуляция чего-то интересного слишком долгая.
>>02413
Вообще, советую попробовать вручную придумать ряд квестов и вариаций для них. И представить, как ты, игрок, будешь их находить, получать и выполнять. Скорее всего тебе быстро надоест и ты наиграешься, не потратив времени на разработку игры)))
Т.е. даже плевать на детали реализации. Положим, мы можем создать миллиарды осмысленных квестов. Вопрос: зачем это игроку? Большинство игроков скипают любые тексты, катсцены и прочий сюжет при первой возможности. Люди играть пришли, а ты им буковы. Не любят люди буковы. Люди любят смотреть на сиськи и срать в твиттер. А почитать и в библиотеке можно...
Не говорю про себя, я-то стараюсь всё внимательно читать, но, тем не менее, не люблю игры с большим количеством текста...
86 Кб, 644x601Годаны, возник вопрос. В контроле TextEdit хочу сделать перемещение строк по альт+вверх, альт+вниз. Набросал функцию, запускаю и ожидаю перемещение строки, но не тут-то было. При нажатом альт всё блокируется. После того как я отпускаю альт и нажимаю стрелку повторно, функция срабатывает один раз. поведение вообще неожиданное. Что делать? Как забороть. делал уже и через именованные действия, и через сканкоды. И через инпут, и через процесс.
Понимаете, принт в 31 строке срабатывает в нужное время, значит код корректен, проблема в настройках TexEdit? Может ему где какие настройки выставить?
Понимаете, принт в 31 строке срабатывает в нужное время, значит код корректен, проблема в настройках TexEdit? Может ему где какие настройки выставить?
>>02511
Главное, редактор кода в движке, как бы на этом классе основан, и альт+стрелки обрабатывает, строки перемещает. Я вообще думал, что там будет функция сдвига строки из коробки. А хуй.
Главное, редактор кода в движке, как бы на этом классе основан, и альт+стрелки обрабатывает, строки перемещает. Я вообще думал, что там будет функция сдвига строки из коробки. А хуй.
69 Кб, 569x653>>02488
Это квест? Сколько голды дашь?
> Вообще, советую попробовать вручную придумать ряд квестов и вариаций для них.
Это квест? Сколько голды дашь?
750 Кб, 1000x912Анонсы, как теперь в гуглоплей публиковаться/монетизироваться? Пилил свой паззл больше года, недавно более-менее до ума довел, пора выкладывать, а тут смотрю гугл и продажу запретил, и рекламу запретил. Што делоть?
>>02514 >>02518
Либо у нас разное понимание "квеста", либо ты неправильно понял, что я имел ввиду, предлагая
Я рассматриваю квест с точки зрения геймплея. В твоём примере квестом является строка "сделай нейросеть". Что должен сделать игрок, чтобы выполнить этот квест? Пойти куда-то (в НИИ)? Что-то найти (суперкомпьютер)? Что-то нажать (клавишу Е перед компьютером)? Кого-то убить (буквальных жуков в виртуальном пространстве компьютера)? Что-то собрать (фрагменты кода в научной библиотеке)? Кого-то "уговорить" (научного сотрудника выдать коды доступа к секретному проекту)? В этом суть квеста, а не в развилках диалога с выдающим квест ботом.
И реальность такова, что типов квеста в игровом мире очень ограниченное количество, и разнообразить квесты ты можешь только внешним видом, расположением, количеством или поведением предметов или мобов. Но проблема в том, что на практике практически нет разницы между тем, какую дуру ты спасаешь от каких мобов, какой лут собираешь или какой предмет кому доставляешь. Рано или поздно всё это надоедает, а делиться с кем-то информацией о таких квестах банально скучно, даже если они у каждого игрока технически уникальны (т.е. буквы не совпадают, лол).
Такой пример ещё. Ты наверняка играл в майнкрафт хотя бы из любопытства. Или смотрел летсплеи/обзоры. Так вот, в мире майнкрафта очень сложно найти два одинаковых участка местности, они все технически уникальны. И мир при этом огромен, пешком персонаж будет идти несколько ИРЛ лет, чтобы дойти от центра до края карты, и все места на его пути будут технически уникальны. При этом тут нет никаких нейронок, нет даже никаких сложных симуляций геологических процессов - это просто набор 2D и 3D шумов. Но действительно ли важна эта уникальность? С геймплейной точки зрения тебе без разницы, где строить дома и копать шахты. Тебе достаточно один раз найти хотя бы некоторые из биомов, чтобы собрать все возможные в игре предметы, а дальше от биомов нет никакой пользы. Делиться скриншотами мира бессмысленно, т.к. в большинстве случаев мир выглядит банально. Интерес вызывают только неожиданные артефакты - вроде летающих островов, деревень на вершине скалы или в пещере, "деревень" без домов (дороги есть, а больше ничего не сгенерировалось), потому что они случаются относительно редко и существенно отличаются от всей остальной технически уникальной местности.
Вот так. Теперь переносим это на квесты: у тебя будет грандиозное количество технически уникальных квестов, но игрокам будет скучно их выполнять, ведь геймплейно они все сводятся к ограниченному и очень малому количеству механик. Реальный интерес будут представлять только ошибки генерации, когда, например, твой кузнец говорит что-то вроде "мою дочь похитили, иди и убей её", т.е. неожиданно рвётся шаблон, выученный игроком. Но, опять же, если у тебя все квесты будут состоять из таких ошибок, это тоже быстро надоест, потому что все эти ошибки потеряют уникальность, станут банальными, обыденными, даже несмотря на свою техническую уникальность (буквы разные).
В общем, прежде чем бросаться искать реализацию своих идей, задумайся о геймдизайне, о геймплее с точки зрения игрока. Не всякая интересная с технической точки зрения реализация приносит в игру что-то по-настоящему важное. Это, кстати, частая ошибка новичков, пытающихся выдать процедурную генерацию за основную фичу игры. Процедурная генерация не сделает тебе интересную игру, даже если ты напихаешь в неё нейронок.
Либо у нас разное понимание "квеста", либо ты неправильно понял, что я имел ввиду, предлагая
>придумать ряд квестов и вариаций для них.
Я рассматриваю квест с точки зрения геймплея. В твоём примере квестом является строка "сделай нейросеть". Что должен сделать игрок, чтобы выполнить этот квест? Пойти куда-то (в НИИ)? Что-то найти (суперкомпьютер)? Что-то нажать (клавишу Е перед компьютером)? Кого-то убить (буквальных жуков в виртуальном пространстве компьютера)? Что-то собрать (фрагменты кода в научной библиотеке)? Кого-то "уговорить" (научного сотрудника выдать коды доступа к секретному проекту)? В этом суть квеста, а не в развилках диалога с выдающим квест ботом.
И реальность такова, что типов квеста в игровом мире очень ограниченное количество, и разнообразить квесты ты можешь только внешним видом, расположением, количеством или поведением предметов или мобов. Но проблема в том, что на практике практически нет разницы между тем, какую дуру ты спасаешь от каких мобов, какой лут собираешь или какой предмет кому доставляешь. Рано или поздно всё это надоедает, а делиться с кем-то информацией о таких квестах банально скучно, даже если они у каждого игрока технически уникальны (т.е. буквы не совпадают, лол).
Такой пример ещё. Ты наверняка играл в майнкрафт хотя бы из любопытства. Или смотрел летсплеи/обзоры. Так вот, в мире майнкрафта очень сложно найти два одинаковых участка местности, они все технически уникальны. И мир при этом огромен, пешком персонаж будет идти несколько ИРЛ лет, чтобы дойти от центра до края карты, и все места на его пути будут технически уникальны. При этом тут нет никаких нейронок, нет даже никаких сложных симуляций геологических процессов - это просто набор 2D и 3D шумов. Но действительно ли важна эта уникальность? С геймплейной точки зрения тебе без разницы, где строить дома и копать шахты. Тебе достаточно один раз найти хотя бы некоторые из биомов, чтобы собрать все возможные в игре предметы, а дальше от биомов нет никакой пользы. Делиться скриншотами мира бессмысленно, т.к. в большинстве случаев мир выглядит банально. Интерес вызывают только неожиданные артефакты - вроде летающих островов, деревень на вершине скалы или в пещере, "деревень" без домов (дороги есть, а больше ничего не сгенерировалось), потому что они случаются относительно редко и существенно отличаются от всей остальной технически уникальной местности.
Вот так. Теперь переносим это на квесты: у тебя будет грандиозное количество технически уникальных квестов, но игрокам будет скучно их выполнять, ведь геймплейно они все сводятся к ограниченному и очень малому количеству механик. Реальный интерес будут представлять только ошибки генерации, когда, например, твой кузнец говорит что-то вроде "мою дочь похитили, иди и убей её", т.е. неожиданно рвётся шаблон, выученный игроком. Но, опять же, если у тебя все квесты будут состоять из таких ошибок, это тоже быстро надоест, потому что все эти ошибки потеряют уникальность, станут банальными, обыденными, даже несмотря на свою техническую уникальность (буквы разные).
В общем, прежде чем бросаться искать реализацию своих идей, задумайся о геймдизайне, о геймплее с точки зрения игрока. Не всякая интересная с технической точки зрения реализация приносит в игру что-то по-настоящему важное. Это, кстати, частая ошибка новичков, пытающихся выдать процедурную генерацию за основную фичу игры. Процедурная генерация не сделает тебе интересную игру, даже если ты напихаешь в неё нейронок.
>>02514 >>02518
Либо у нас разное понимание "квеста", либо ты неправильно понял, что я имел ввиду, предлагая
Я рассматриваю квест с точки зрения геймплея. В твоём примере квестом является строка "сделай нейросеть". Что должен сделать игрок, чтобы выполнить этот квест? Пойти куда-то (в НИИ)? Что-то найти (суперкомпьютер)? Что-то нажать (клавишу Е перед компьютером)? Кого-то убить (буквальных жуков в виртуальном пространстве компьютера)? Что-то собрать (фрагменты кода в научной библиотеке)? Кого-то "уговорить" (научного сотрудника выдать коды доступа к секретному проекту)? В этом суть квеста, а не в развилках диалога с выдающим квест ботом.
И реальность такова, что типов квеста в игровом мире очень ограниченное количество, и разнообразить квесты ты можешь только внешним видом, расположением, количеством или поведением предметов или мобов. Но проблема в том, что на практике практически нет разницы между тем, какую дуру ты спасаешь от каких мобов, какой лут собираешь или какой предмет кому доставляешь. Рано или поздно всё это надоедает, а делиться с кем-то информацией о таких квестах банально скучно, даже если они у каждого игрока технически уникальны (т.е. буквы не совпадают, лол).
Такой пример ещё. Ты наверняка играл в майнкрафт хотя бы из любопытства. Или смотрел летсплеи/обзоры. Так вот, в мире майнкрафта очень сложно найти два одинаковых участка местности, они все технически уникальны. И мир при этом огромен, пешком персонаж будет идти несколько ИРЛ лет, чтобы дойти от центра до края карты, и все места на его пути будут технически уникальны. При этом тут нет никаких нейронок, нет даже никаких сложных симуляций геологических процессов - это просто набор 2D и 3D шумов. Но действительно ли важна эта уникальность? С геймплейной точки зрения тебе без разницы, где строить дома и копать шахты. Тебе достаточно один раз найти хотя бы некоторые из биомов, чтобы собрать все возможные в игре предметы, а дальше от биомов нет никакой пользы. Делиться скриншотами мира бессмысленно, т.к. в большинстве случаев мир выглядит банально. Интерес вызывают только неожиданные артефакты - вроде летающих островов, деревень на вершине скалы или в пещере, "деревень" без домов (дороги есть, а больше ничего не сгенерировалось), потому что они случаются относительно редко и существенно отличаются от всей остальной технически уникальной местности.
Вот так. Теперь переносим это на квесты: у тебя будет грандиозное количество технически уникальных квестов, но игрокам будет скучно их выполнять, ведь геймплейно они все сводятся к ограниченному и очень малому количеству механик. Реальный интерес будут представлять только ошибки генерации, когда, например, твой кузнец говорит что-то вроде "мою дочь похитили, иди и убей её", т.е. неожиданно рвётся шаблон, выученный игроком. Но, опять же, если у тебя все квесты будут состоять из таких ошибок, это тоже быстро надоест, потому что все эти ошибки потеряют уникальность, станут банальными, обыденными, даже несмотря на свою техническую уникальность (буквы разные).
В общем, прежде чем бросаться искать реализацию своих идей, задумайся о геймдизайне, о геймплее с точки зрения игрока. Не всякая интересная с технической точки зрения реализация приносит в игру что-то по-настоящему важное. Это, кстати, частая ошибка новичков, пытающихся выдать процедурную генерацию за основную фичу игры. Процедурная генерация не сделает тебе интересную игру, даже если ты напихаешь в неё нейронок.
Либо у нас разное понимание "квеста", либо ты неправильно понял, что я имел ввиду, предлагая
>придумать ряд квестов и вариаций для них.
Я рассматриваю квест с точки зрения геймплея. В твоём примере квестом является строка "сделай нейросеть". Что должен сделать игрок, чтобы выполнить этот квест? Пойти куда-то (в НИИ)? Что-то найти (суперкомпьютер)? Что-то нажать (клавишу Е перед компьютером)? Кого-то убить (буквальных жуков в виртуальном пространстве компьютера)? Что-то собрать (фрагменты кода в научной библиотеке)? Кого-то "уговорить" (научного сотрудника выдать коды доступа к секретному проекту)? В этом суть квеста, а не в развилках диалога с выдающим квест ботом.
И реальность такова, что типов квеста в игровом мире очень ограниченное количество, и разнообразить квесты ты можешь только внешним видом, расположением, количеством или поведением предметов или мобов. Но проблема в том, что на практике практически нет разницы между тем, какую дуру ты спасаешь от каких мобов, какой лут собираешь или какой предмет кому доставляешь. Рано или поздно всё это надоедает, а делиться с кем-то информацией о таких квестах банально скучно, даже если они у каждого игрока технически уникальны (т.е. буквы не совпадают, лол).
Такой пример ещё. Ты наверняка играл в майнкрафт хотя бы из любопытства. Или смотрел летсплеи/обзоры. Так вот, в мире майнкрафта очень сложно найти два одинаковых участка местности, они все технически уникальны. И мир при этом огромен, пешком персонаж будет идти несколько ИРЛ лет, чтобы дойти от центра до края карты, и все места на его пути будут технически уникальны. При этом тут нет никаких нейронок, нет даже никаких сложных симуляций геологических процессов - это просто набор 2D и 3D шумов. Но действительно ли важна эта уникальность? С геймплейной точки зрения тебе без разницы, где строить дома и копать шахты. Тебе достаточно один раз найти хотя бы некоторые из биомов, чтобы собрать все возможные в игре предметы, а дальше от биомов нет никакой пользы. Делиться скриншотами мира бессмысленно, т.к. в большинстве случаев мир выглядит банально. Интерес вызывают только неожиданные артефакты - вроде летающих островов, деревень на вершине скалы или в пещере, "деревень" без домов (дороги есть, а больше ничего не сгенерировалось), потому что они случаются относительно редко и существенно отличаются от всей остальной технически уникальной местности.
Вот так. Теперь переносим это на квесты: у тебя будет грандиозное количество технически уникальных квестов, но игрокам будет скучно их выполнять, ведь геймплейно они все сводятся к ограниченному и очень малому количеству механик. Реальный интерес будут представлять только ошибки генерации, когда, например, твой кузнец говорит что-то вроде "мою дочь похитили, иди и убей её", т.е. неожиданно рвётся шаблон, выученный игроком. Но, опять же, если у тебя все квесты будут состоять из таких ошибок, это тоже быстро надоест, потому что все эти ошибки потеряют уникальность, станут банальными, обыденными, даже несмотря на свою техническую уникальность (буквы разные).
В общем, прежде чем бросаться искать реализацию своих идей, задумайся о геймдизайне, о геймплее с точки зрения игрока. Не всякая интересная с технической точки зрения реализация приносит в игру что-то по-настоящему важное. Это, кстати, частая ошибка новичков, пытающихся выдать процедурную генерацию за основную фичу игры. Процедурная генерация не сделает тебе интересную игру, даже если ты напихаешь в неё нейронок.
>>02600
Ещё хотел сделать такой вывод. Да, разумеется, выполнять один и тот же квест "принеси столько-то чего-то" в разных вариациях очень скучно, быстро надоедает. Поэтому нужно копать не в сторону разнообразия квестов, а в сторону влияния этих квестов на окружающий игрока мир. Согласитесь, довольно тупо выглядит квест на убийство волков от овцевода, если он ни на что не влияет ни при выполнении, ни при игнорировании, и нужен лишь чтобы занять вас на какое-то время и дать виртуальные монетки. Было бы намного интереснее, если бы игнорирование этого квеста приводило к истреблению овец волками, в результате чего повышались цены на шерсть и одежду в конкретной области, либо, после выполнения квеста на убийство волков, популяция зайцев превышала все разумные пределы и вытаптывала целые поля, повышая цены на овощи. При этом все эти следствия были бы естественным исходом симуляции, а не результатом выполнения сценария. Приходилось бы думать, принимать решения, порой тяжёлые, готовиться и адаптироваться к последствиям решений... Это вывело бы геймплей на принципиально новый уровень по сравнению с классическими рельсовыми РПГ с их унылыми однотипными квестами, влияющими только на прогресс игрока по сюжету. Однако, как я уже писал, такая система не позволит делать рельсовый сюжет, а также будет уязвима к нарушающим баланс системы действиям игрока. Короче, совсем другой жанр и другая ЦА.
Ещё хотел сделать такой вывод. Да, разумеется, выполнять один и тот же квест "принеси столько-то чего-то" в разных вариациях очень скучно, быстро надоедает. Поэтому нужно копать не в сторону разнообразия квестов, а в сторону влияния этих квестов на окружающий игрока мир. Согласитесь, довольно тупо выглядит квест на убийство волков от овцевода, если он ни на что не влияет ни при выполнении, ни при игнорировании, и нужен лишь чтобы занять вас на какое-то время и дать виртуальные монетки. Было бы намного интереснее, если бы игнорирование этого квеста приводило к истреблению овец волками, в результате чего повышались цены на шерсть и одежду в конкретной области, либо, после выполнения квеста на убийство волков, популяция зайцев превышала все разумные пределы и вытаптывала целые поля, повышая цены на овощи. При этом все эти следствия были бы естественным исходом симуляции, а не результатом выполнения сценария. Приходилось бы думать, принимать решения, порой тяжёлые, готовиться и адаптироваться к последствиям решений... Это вывело бы геймплей на принципиально новый уровень по сравнению с классическими рельсовыми РПГ с их унылыми однотипными квестами, влияющими только на прогресс игрока по сюжету. Однако, как я уже писал, такая система не позволит делать рельсовый сюжет, а также будет уязвима к нарушающим баланс системы действиям игрока. Короче, совсем другой жанр и другая ЦА.
>>02583
Да, конечно. Найди анона-украинца и пусть он постит, а прибыль пополам.
> Может какие-то посредники есть?
Да, конечно. Найди анона-украинца и пусть он постит, а прибыль пополам.
>>02608
Я хочу спроектировать такую систему, которая принимает входящими данными рельсовый сюжет и органично вплетает его в вышеописанное тобой окружение. Возможно я моногого хочу. Посмотрим.
>>02600
Квест я рассматриваю, как последовательность действий, предлагаемых правилами игры, которая переводит игру из состояния А в состояние Б. Например, в шахматах, провести серию ходов чтобы объявить противнику шах - это квест. Сами ходы и их виды у фигур - это геймплей.
Тебя вообще очень тяжело понять временами.
Что должен сделать игрок, чтобы объявить второму игроку шах?
> такая система не позволит делать рельсовый сюжет
Я хочу спроектировать такую систему, которая принимает входящими данными рельсовый сюжет и органично вплетает его в вышеописанное тобой окружение. Возможно я моногого хочу. Посмотрим.
>>02600
> Я рассматриваю квест с точки зрения геймплея.
Квест я рассматриваю, как последовательность действий, предлагаемых правилами игры, которая переводит игру из состояния А в состояние Б. Например, в шахматах, провести серию ходов чтобы объявить противнику шах - это квест. Сами ходы и их виды у фигур - это геймплей.
> либо ты неправильно понял, что я имел ввиду
Тебя вообще очень тяжело понять временами.
> Что должен сделать игрок, чтобы выполнить этот квест?
Что должен сделать игрок, чтобы объявить второму игроку шах?
>>02655
Квест - это задание в компьютерной игре. Дали задание, ты его выполнил, получил награду. Проблема как раз в придумывании интересных заданий в рамках РПГ. Пытаясь вкрутить в РПГ многоходовочки из шахмат ты переводишь игру в жанр головоломок, ты этого хочешь? Я слышал о такой ММОРПГ, где каждый квест был головоломкой, игрокам это не нравилось.
Нет, виды ходов у фигур - это механики (ход конём и т.п.). Проведение игроком серии ходов с какой-то целью - это геймплей (т.е. игровой процесс). А задача "поставить шах и мат" - это, можно сказать, квест (если шахматы встроены в РПГ как мини-игра).
Я имел в виду, что ты должен думать о геймплее, придумывая игроку задания. Вот ты можешь придумать задание "найти аленький цветочек", но будет ли это интересно игроку? Ты продумываешь диалоги, тысячи, миллионы вариантов диалога на тему аленького цветочка, а будет ли игроку интересно это задание? Будет ли интересно бегать по 10 км в длину карте и искать маленький красный цветочек, прячущийся под слоем травы, не имея подсказок? Ну и какой смысл с миллионов вариаций этого квеста, если они все входят в множество неудачных, скучных или нудных квестов.
Вот поэтому постарайся сам, вручную выдумать некоторое количество квестов, фокусируясь на геймплее, через который игрок должен будет пройти для выполнения квеста, а не на бесполезных диалогах. Дальше ты либо поймёшь, что бесконечное количество квестов не нужно, либо эти вручную написанные квесты станут фундаментом для процедурного генератора (на нейросетях или без них - дело десятое).
Квест - это задание в компьютерной игре. Дали задание, ты его выполнил, получил награду. Проблема как раз в придумывании интересных заданий в рамках РПГ. Пытаясь вкрутить в РПГ многоходовочки из шахмат ты переводишь игру в жанр головоломок, ты этого хочешь? Я слышал о такой ММОРПГ, где каждый квест был головоломкой, игрокам это не нравилось.
>провести серию ходов чтобы объявить противнику шах - это квест. Сами ходы и их виды у фигур - это геймплей.
Нет, виды ходов у фигур - это механики (ход конём и т.п.). Проведение игроком серии ходов с какой-то целью - это геймплей (т.е. игровой процесс). А задача "поставить шах и мат" - это, можно сказать, квест (если шахматы встроены в РПГ как мини-игра).
>Что должен сделать игрок
Я имел в виду, что ты должен думать о геймплее, придумывая игроку задания. Вот ты можешь придумать задание "найти аленький цветочек", но будет ли это интересно игроку? Ты продумываешь диалоги, тысячи, миллионы вариантов диалога на тему аленького цветочка, а будет ли игроку интересно это задание? Будет ли интересно бегать по 10 км в длину карте и искать маленький красный цветочек, прячущийся под слоем травы, не имея подсказок? Ну и какой смысл с миллионов вариаций этого квеста, если они все входят в множество неудачных, скучных или нудных квестов.
Вот поэтому постарайся сам, вручную выдумать некоторое количество квестов, фокусируясь на геймплее, через который игрок должен будет пройти для выполнения квеста, а не на бесполезных диалогах. Дальше ты либо поймёшь, что бесконечное количество квестов не нужно, либо эти вручную написанные квесты станут фундаментом для процедурного генератора (на нейросетях или без них - дело десятое).
>>02688
Ууу... это будет сложно. Знаешь пасту про игровую ностальгию? Там говорилось, что старые игры играют яркими красками в ностальгирующей памяти, и если ты садишься в них переигрывать спустя 20..30 лет, то может наступить жесточайший облом, потому что игра окажется банальной и унылой с подай-принеси квестами. А всё её великолепие - это на самом деле твой мозг за прошедшие годы приукрасил.
Так вот. Предупреждая об этой ловушке ностальгии, я вброшу свои референсы:
Арканум.
Фолауты 1/2.
Невервинтер 1й.
Из более нового можно привести Скайрим, но не сам Скайрим, конечно, а крупные фанатские моды к нему.
Ууу... это будет сложно. Знаешь пасту про игровую ностальгию? Там говорилось, что старые игры играют яркими красками в ностальгирующей памяти, и если ты садишься в них переигрывать спустя 20..30 лет, то может наступить жесточайший облом, потому что игра окажется банальной и унылой с подай-принеси квестами. А всё её великолепие - это на самом деле твой мозг за прошедшие годы приукрасил.
Так вот. Предупреждая об этой ловушке ностальгии, я вброшу свои референсы:
Арканум.
Фолауты 1/2.
Невервинтер 1й.
Из более нового можно привести Скайрим, но не сам Скайрим, конечно, а крупные фанатские моды к нему.
>>02681
Диалог - это каркас квеста. Чертёж. Блупринт. Диалог, правильно спроектированный, предоставит метаданные для генерации игровых объектов, чтобы игрок смог перевести квестовые переменные в новые состояния, чтобы квест продолжился.
Я могу придумать механики, уже придумал. Но без каркаса механики сами по себе были интересны в прошлом веке. Сегодняшнему игроку нужна история. Нужно не просто рубить вражин мечом, а чтобы прорубаться сквозь них к некоторой цели - аленькому цветочку. А потом прорубаться обратно, чтобы его отдать. А по пути прокачиваться, разумеется.
В целом не этого, но разбавить геймплей головоломками полезно.
Разумеется. Это фанатизм, который нравится только фанатам. Нужно без фанатизма.
Ты требуешь, чтобы я озвучил механики. Хорошо. Вот они:
1. Можно ходить по трёхмерному миру.
2. Можно взбираться на лестницы.
3. Можно плавать.
4. У персонажа две руки ооО, и две штанги на плечах, в каждую руку можно взять инструмент.
5. Инструменты разбиты на классы, и если инструмент относится к классам оружия, то значит, им можно бить врагов. Любой инструмент можно держать как в одной руке, так и в обоих. При этом инструменты бывают одноручные и двуручные. И если держишь двуручный инструмент в одной руке, его эффективность хуже. И наоборот, держать инструмент в двух руках - повышает его эффективность. Имеется быстрые слоты - сумки-подсумки, но их использование привязано к рукам, то есть, ты не можешь, скажем просто взять и бросить гранату, если в обоих руках пистолеты, нужно убрать один пистолет, бросить гранату, достать пистолет. То есть, в снаряжении есть два пула инструментов, для правой и левой руки. Изначально там по две ячейки, но их можно прокачать. Это может показаться какой-то дикостью и тупостью на первый взгляд, но не спеши с выводами, каждую из ячеек можно забиндить на отдельную клавишу. Для второй ячейки правой руки предустановлена клавиша G, для второй левой клавиша F,
6. Есть транспорт, огромные приручённые летающие существа, но летать на них можно только прокачав навык управления ими, а так же добыв специальную броню-упряжку, в которую впрягаешься сам, потому что существа тебя переносят вцепившись лапами в крепления у тебя на плечах.
7. Соответственно, в режиме полёта ты можешь пользоваться дальнобойным оружием, твои руки свободны, потому что управление летающим существом при помощи ног: ты наклоняешь ноги в одну сторону (A или D), тебя перевешивает в противоположную, существо это чувствует лапами и поворачивает в полёте. Ну и голосовые команды ещё для ускорения/торможения и посадки (W или S, Q или E).
8. Головоломки реализованы через инструменты. Любая активность в игре - это мини-игра соответствующего инструмента. Простейший пример - отмычки, запускающие мини-игру по взлому замка. Придумал гениальную мини-игру, смотри не укради! Короче, на экране замочная скважина и отмычка, клавишами A и D вращаешь отмычку, ЛКМ поворачиваешь скважину отвёрткой. Если не попадаешь в правильное положение, скважина упирается и наносит хиты хитпоинтам отмычки.
9. Тем не менее, планируются и физические головоломки, с поворачиваниями рычагов, вставаниями на нажимные панели в полу, переносами каменных глыб, при помощи летуна, и т.д. и т.п. и проч. Вот например, придумал такую головоломку: заходишь в большую комнату в древнем храме, а там с потолка свисает огромная конструкция в форме ЕБУЧЕГО ЖУКА, вокруг есть несколько нажимных пластин и верёвок. Нажимая на пластины и дергая за веревки, ты поворачиваешь ЕБУЧЕГО ЖУКА в правильном направлении, чтобы он лапками ухватился за главную верёвку, и тогда откроется дверь.
> Вот ты можешь придумать задание "найти аленький цветочек", но будет ли это интересно игроку? Ты продумываешь диалоги, тысячи, миллионы вариантов диалога на тему аленького цветочка, а будет ли игроку интересно это задание? Будет ли интересно бегать по 10 км в длину карте и искать маленький красный цветочек, прячущийся под слоем травы, не имея подсказок? Ну и какой смысл с миллионов вариаций этого квеста, если они все входят в множество неудачных, скучных или нудных квестов.
Диалог - это каркас квеста. Чертёж. Блупринт. Диалог, правильно спроектированный, предоставит метаданные для генерации игровых объектов, чтобы игрок смог перевести квестовые переменные в новые состояния, чтобы квест продолжился.
Я могу придумать механики, уже придумал. Но без каркаса механики сами по себе были интересны в прошлом веке. Сегодняшнему игроку нужна история. Нужно не просто рубить вражин мечом, а чтобы прорубаться сквозь них к некоторой цели - аленькому цветочку. А потом прорубаться обратно, чтобы его отдать. А по пути прокачиваться, разумеется.
> Проблема как раз в придумывании интересных заданий в рамках РПГ.
> Пытаясь вкрутить в РПГ многоходовочки из шахмат ты переводишь игру в жанр головоломок, ты этого хочешь?
В целом не этого, но разбавить геймплей головоломками полезно.
> каждый квест был головоломкой, игрокам это не нравилось
Разумеется. Это фанатизм, который нравится только фанатам. Нужно без фанатизма.
Ты требуешь, чтобы я озвучил механики. Хорошо. Вот они:
1. Можно ходить по трёхмерному миру.
2. Можно взбираться на лестницы.
3. Можно плавать.
4. У персонажа две руки ооО, и две штанги на плечах, в каждую руку можно взять инструмент.
5. Инструменты разбиты на классы, и если инструмент относится к классам оружия, то значит, им можно бить врагов. Любой инструмент можно держать как в одной руке, так и в обоих. При этом инструменты бывают одноручные и двуручные. И если держишь двуручный инструмент в одной руке, его эффективность хуже. И наоборот, держать инструмент в двух руках - повышает его эффективность. Имеется быстрые слоты - сумки-подсумки, но их использование привязано к рукам, то есть, ты не можешь, скажем просто взять и бросить гранату, если в обоих руках пистолеты, нужно убрать один пистолет, бросить гранату, достать пистолет. То есть, в снаряжении есть два пула инструментов, для правой и левой руки. Изначально там по две ячейки, но их можно прокачать. Это может показаться какой-то дикостью и тупостью на первый взгляд, но не спеши с выводами, каждую из ячеек можно забиндить на отдельную клавишу. Для второй ячейки правой руки предустановлена клавиша G, для второй левой клавиша F,
6. Есть транспорт, огромные приручённые летающие существа, но летать на них можно только прокачав навык управления ими, а так же добыв специальную броню-упряжку, в которую впрягаешься сам, потому что существа тебя переносят вцепившись лапами в крепления у тебя на плечах.
7. Соответственно, в режиме полёта ты можешь пользоваться дальнобойным оружием, твои руки свободны, потому что управление летающим существом при помощи ног: ты наклоняешь ноги в одну сторону (A или D), тебя перевешивает в противоположную, существо это чувствует лапами и поворачивает в полёте. Ну и голосовые команды ещё для ускорения/торможения и посадки (W или S, Q или E).
8. Головоломки реализованы через инструменты. Любая активность в игре - это мини-игра соответствующего инструмента. Простейший пример - отмычки, запускающие мини-игру по взлому замка. Придумал гениальную мини-игру, смотри не укради! Короче, на экране замочная скважина и отмычка, клавишами A и D вращаешь отмычку, ЛКМ поворачиваешь скважину отвёрткой. Если не попадаешь в правильное положение, скважина упирается и наносит хиты хитпоинтам отмычки.
9. Тем не менее, планируются и физические головоломки, с поворачиваниями рычагов, вставаниями на нажимные панели в полу, переносами каменных глыб, при помощи летуна, и т.д. и т.п. и проч. Вот например, придумал такую головоломку: заходишь в большую комнату в древнем храме, а там с потолка свисает огромная конструкция в форме ЕБУЧЕГО ЖУКА, вокруг есть несколько нажимных пластин и верёвок. Нажимая на пластины и дергая за веревки, ты поворачиваешь ЕБУЧЕГО ЖУКА в правильном направлении, чтобы он лапками ухватился за главную верёвку, и тогда откроется дверь.
>>02681
Диалог - это каркас квеста. Чертёж. Блупринт. Диалог, правильно спроектированный, предоставит метаданные для генерации игровых объектов, чтобы игрок смог перевести квестовые переменные в новые состояния, чтобы квест продолжился.
Я могу придумать механики, уже придумал. Но без каркаса механики сами по себе были интересны в прошлом веке. Сегодняшнему игроку нужна история. Нужно не просто рубить вражин мечом, а чтобы прорубаться сквозь них к некоторой цели - аленькому цветочку. А потом прорубаться обратно, чтобы его отдать. А по пути прокачиваться, разумеется.
В целом не этого, но разбавить геймплей головоломками полезно.
Разумеется. Это фанатизм, который нравится только фанатам. Нужно без фанатизма.
Ты требуешь, чтобы я озвучил механики. Хорошо. Вот они:
1. Можно ходить по трёхмерному миру.
2. Можно взбираться на лестницы.
3. Можно плавать.
4. У персонажа две руки ооО, и две штанги на плечах, в каждую руку можно взять инструмент.
5. Инструменты разбиты на классы, и если инструмент относится к классам оружия, то значит, им можно бить врагов. Любой инструмент можно держать как в одной руке, так и в обоих. При этом инструменты бывают одноручные и двуручные. И если держишь двуручный инструмент в одной руке, его эффективность хуже. И наоборот, держать инструмент в двух руках - повышает его эффективность. Имеется быстрые слоты - сумки-подсумки, но их использование привязано к рукам, то есть, ты не можешь, скажем просто взять и бросить гранату, если в обоих руках пистолеты, нужно убрать один пистолет, бросить гранату, достать пистолет. То есть, в снаряжении есть два пула инструментов, для правой и левой руки. Изначально там по две ячейки, но их можно прокачать. Это может показаться какой-то дикостью и тупостью на первый взгляд, но не спеши с выводами, каждую из ячеек можно забиндить на отдельную клавишу. Для второй ячейки правой руки предустановлена клавиша G, для второй левой клавиша F,
6. Есть транспорт, огромные приручённые летающие существа, но летать на них можно только прокачав навык управления ими, а так же добыв специальную броню-упряжку, в которую впрягаешься сам, потому что существа тебя переносят вцепившись лапами в крепления у тебя на плечах.
7. Соответственно, в режиме полёта ты можешь пользоваться дальнобойным оружием, твои руки свободны, потому что управление летающим существом при помощи ног: ты наклоняешь ноги в одну сторону (A или D), тебя перевешивает в противоположную, существо это чувствует лапами и поворачивает в полёте. Ну и голосовые команды ещё для ускорения/торможения и посадки (W или S, Q или E).
8. Головоломки реализованы через инструменты. Любая активность в игре - это мини-игра соответствующего инструмента. Простейший пример - отмычки, запускающие мини-игру по взлому замка. Придумал гениальную мини-игру, смотри не укради! Короче, на экране замочная скважина и отмычка, клавишами A и D вращаешь отмычку, ЛКМ поворачиваешь скважину отвёрткой. Если не попадаешь в правильное положение, скважина упирается и наносит хиты хитпоинтам отмычки.
9. Тем не менее, планируются и физические головоломки, с поворачиваниями рычагов, вставаниями на нажимные панели в полу, переносами каменных глыб, при помощи летуна, и т.д. и т.п. и проч. Вот например, придумал такую головоломку: заходишь в большую комнату в древнем храме, а там с потолка свисает огромная конструкция в форме ЕБУЧЕГО ЖУКА, вокруг есть несколько нажимных пластин и верёвок. Нажимая на пластины и дергая за веревки, ты поворачиваешь ЕБУЧЕГО ЖУКА в правильном направлении, чтобы он лапками ухватился за главную верёвку, и тогда откроется дверь.
> Вот ты можешь придумать задание "найти аленький цветочек", но будет ли это интересно игроку? Ты продумываешь диалоги, тысячи, миллионы вариантов диалога на тему аленького цветочка, а будет ли игроку интересно это задание? Будет ли интересно бегать по 10 км в длину карте и искать маленький красный цветочек, прячущийся под слоем травы, не имея подсказок? Ну и какой смысл с миллионов вариаций этого квеста, если они все входят в множество неудачных, скучных или нудных квестов.
Диалог - это каркас квеста. Чертёж. Блупринт. Диалог, правильно спроектированный, предоставит метаданные для генерации игровых объектов, чтобы игрок смог перевести квестовые переменные в новые состояния, чтобы квест продолжился.
Я могу придумать механики, уже придумал. Но без каркаса механики сами по себе были интересны в прошлом веке. Сегодняшнему игроку нужна история. Нужно не просто рубить вражин мечом, а чтобы прорубаться сквозь них к некоторой цели - аленькому цветочку. А потом прорубаться обратно, чтобы его отдать. А по пути прокачиваться, разумеется.
> Проблема как раз в придумывании интересных заданий в рамках РПГ.
> Пытаясь вкрутить в РПГ многоходовочки из шахмат ты переводишь игру в жанр головоломок, ты этого хочешь?
В целом не этого, но разбавить геймплей головоломками полезно.
> каждый квест был головоломкой, игрокам это не нравилось
Разумеется. Это фанатизм, который нравится только фанатам. Нужно без фанатизма.
Ты требуешь, чтобы я озвучил механики. Хорошо. Вот они:
1. Можно ходить по трёхмерному миру.
2. Можно взбираться на лестницы.
3. Можно плавать.
4. У персонажа две руки ооО, и две штанги на плечах, в каждую руку можно взять инструмент.
5. Инструменты разбиты на классы, и если инструмент относится к классам оружия, то значит, им можно бить врагов. Любой инструмент можно держать как в одной руке, так и в обоих. При этом инструменты бывают одноручные и двуручные. И если держишь двуручный инструмент в одной руке, его эффективность хуже. И наоборот, держать инструмент в двух руках - повышает его эффективность. Имеется быстрые слоты - сумки-подсумки, но их использование привязано к рукам, то есть, ты не можешь, скажем просто взять и бросить гранату, если в обоих руках пистолеты, нужно убрать один пистолет, бросить гранату, достать пистолет. То есть, в снаряжении есть два пула инструментов, для правой и левой руки. Изначально там по две ячейки, но их можно прокачать. Это может показаться какой-то дикостью и тупостью на первый взгляд, но не спеши с выводами, каждую из ячеек можно забиндить на отдельную клавишу. Для второй ячейки правой руки предустановлена клавиша G, для второй левой клавиша F,
6. Есть транспорт, огромные приручённые летающие существа, но летать на них можно только прокачав навык управления ими, а так же добыв специальную броню-упряжку, в которую впрягаешься сам, потому что существа тебя переносят вцепившись лапами в крепления у тебя на плечах.
7. Соответственно, в режиме полёта ты можешь пользоваться дальнобойным оружием, твои руки свободны, потому что управление летающим существом при помощи ног: ты наклоняешь ноги в одну сторону (A или D), тебя перевешивает в противоположную, существо это чувствует лапами и поворачивает в полёте. Ну и голосовые команды ещё для ускорения/торможения и посадки (W или S, Q или E).
8. Головоломки реализованы через инструменты. Любая активность в игре - это мини-игра соответствующего инструмента. Простейший пример - отмычки, запускающие мини-игру по взлому замка. Придумал гениальную мини-игру, смотри не укради! Короче, на экране замочная скважина и отмычка, клавишами A и D вращаешь отмычку, ЛКМ поворачиваешь скважину отвёрткой. Если не попадаешь в правильное положение, скважина упирается и наносит хиты хитпоинтам отмычки.
9. Тем не менее, планируются и физические головоломки, с поворачиваниями рычагов, вставаниями на нажимные панели в полу, переносами каменных глыб, при помощи летуна, и т.д. и т.п. и проч. Вот например, придумал такую головоломку: заходишь в большую комнату в древнем храме, а там с потолка свисает огромная конструкция в форме ЕБУЧЕГО ЖУКА, вокруг есть несколько нажимных пластин и верёвок. Нажимая на пластины и дергая за веревки, ты поворачиваешь ЕБУЧЕГО ЖУКА в правильном направлении, чтобы он лапками ухватился за главную верёвку, и тогда откроется дверь.
В тему дискасса прям как чувствовали, инфоцыгане хузы выкатили новый видос:
https://www.youtube.com/watch?v=EbdyH6khrKk
https://www.youtube.com/watch?v=EbdyH6khrKk
Полтора месяца назад собирался сделать меню, да так и забил. Сегодня примерно за пару часов сделал прототип. Меню выбора сохранения для загрузки нужно ещё, но до этого нужно наконец определиться с системой мира, переписать её и сделать систему сохранения. Вообще ощущение, что нужно снова почти всё отбросить и начать с нуля...
Алсо совет: избегайте лапши из NodePath и ссылок на ноды, чаще используйте систему сигналов вместо ссылок. У меня сейчас кучу кода приходится переводить на сигналы, потому что ноды в процессе работы над проектом перемещаются - ссылки в них/на них ломаются и не могут быть восстановлены, нужно заменять всё на сигналы. Вот казалось бы, много лет назад осознал проблему лапши в коде, но при прототипировании на Годо всё равно наделал лапши через инспектор нод...
Алсо совет: избегайте лапши из NodePath и ссылок на ноды, чаще используйте систему сигналов вместо ссылок. У меня сейчас кучу кода приходится переводить на сигналы, потому что ноды в процессе работы над проектом перемещаются - ссылки в них/на них ломаются и не могут быть восстановлены, нужно заменять всё на сигналы. Вот казалось бы, много лет назад осознал проблему лапши в коде, но при прототипировании на Годо всё равно наделал лапши через инспектор нод...
>>02765 (Del)
Графика тестовая, планирую когда-нибудь переделать.
Куда, в игру? Там же ничего нет (и это меня печалит).
Прочитал - сложно. Сомневаюсь, что оно того стоит. Суть моей проблемы в том, что я создавал методы в скриптах и затем дёргал эти методы из других скриптов по имени, а нужно было наоборот, запускать события (сигналы), обработчики которых могут быть где угодно в другом месте. В первом случае скрипт ломается и падает с ошибкой, если что-то случилось с другим скриптом, во втором случае скрипт продолжает работать, только лишь события перестают обрабатываться. Пример: у меня в коде генератора, менеджера чанков и контроллера персонажа были обращения к надписям на экране, и при изменении положения нод проект перестал запускаться, а если бы я сделал это на основе сигналов ("нужно обновить надпись такой-то информацией"), то проект бы запускался, только надписи скорее всего не обновлялись бы. С одной стороны - лучше получить явное сообщение об ошибке, чем искать неявную ошибку, с другой стороны меня сейчас эти надписи вообще не интересуют и я хотел бы протестировать другие места проекта, но ошибки обращения к null это сделать не дают. После перехода на сигналы всё заработало, только теперь эти сигналы нужно соединять с интерфейсом, и я не совсем понимаю, кто именно это должен делать - маршрут по дереву запутанный (сначала вверх, потом вниз)...
>Милота
Графика тестовая, планирую когда-нибудь переделать.
>ворваться
Куда, в игру? Там же ничего нет (и это меня печалит).
>аддон
Прочитал - сложно. Сомневаюсь, что оно того стоит. Суть моей проблемы в том, что я создавал методы в скриптах и затем дёргал эти методы из других скриптов по имени, а нужно было наоборот, запускать события (сигналы), обработчики которых могут быть где угодно в другом месте. В первом случае скрипт ломается и падает с ошибкой, если что-то случилось с другим скриптом, во втором случае скрипт продолжает работать, только лишь события перестают обрабатываться. Пример: у меня в коде генератора, менеджера чанков и контроллера персонажа были обращения к надписям на экране, и при изменении положения нод проект перестал запускаться, а если бы я сделал это на основе сигналов ("нужно обновить надпись такой-то информацией"), то проект бы запускался, только надписи скорее всего не обновлялись бы. С одной стороны - лучше получить явное сообщение об ошибке, чем искать неявную ошибку, с другой стороны меня сейчас эти надписи вообще не интересуют и я хотел бы протестировать другие места проекта, но ошибки обращения к null это сделать не дают. После перехода на сигналы всё заработало, только теперь эти сигналы нужно соединять с интерфейсом, и я не совсем понимаю, кто именно это должен делать - маршрут по дереву запутанный (сначала вверх, потом вниз)...
Подскажите хорошие сайты с бесплатными 2д кассетами и текстурами
>>02688
Всё зависит от ЦА. Мне, например, нравились миссии в ГТА, где нужно машинки угонять, скрываться от полиции и аккуратно, без ДТП доставлять их на склад или покупателю. И что дальше? Мои хотелки не совпадут с твоими хотелками или хотелками того анона.
Поэтому я и предложил тому анону САМОМУ написать некоторое количество лично ему интересных квестов (фокусируясь на геймплее, а не на диалогах, если игра не текстовая). Он же хочет делать игру своей мечты, а не моей или твоей. Вот напишет квесты-примеры, и дальше можно будет думать, как их можно обобщить и процедурно генерировать, или скормить нейронке. И нужно ли.
>>02715
Сильно сомневаюсь, что в любом квестовом диалоге достаточно "метаданных" для генерации "игровых объектов". Вообще не ясно, что ты имеешь в виду. Из фразы "эй, мужик, иди убей 15 волков" должны родиться 3D модели волков в ближайшем лесу?
Смелое утверждение. Тем временем большинство игроков дрочат либо в онлайн-дрочильни, либо в мобильные дрочильни, где текст в лучшем случае на кнопках меню есть. Сегодня вообще выгоднее всего не иметь текста в игре даже на кнопках, чтобы покрыть максимально возможную аудиторию (весь мир)... Не спорю, любители историй тоже есть, но их не стало сильно больше, а вот казуальных игроков стало значительно больше. Хочешь историю? Прочитай в интернете, в электронных книгах, посмотри в кино, сериале или на ютубе, послушай аудиокнигу или онлайн-радио. Нет смысла покупать и играть в игру, если тебя интересует только история. В игры всё-таки ради геймплея играют, а история всегда была и остаётся поводом погрузиться в геймплей, поэтому у игр зачастую такие бредовые и поверхностные истории. ...Окей, история может быть изображена без текста (все мы видили примеры таких игр), но даже в таком случае это скорее декорация для геймплея, а не основа игры.
Любители прокачки вообще сюжет игнорируют. Собирают идеальные билды персонажей, целыми днями гриндят одну локацию и т.д. Им некогда твои буквы читать, если за чтение не дают экспы и можно просто скипнуть весь текст до награды. Встречал таких в ММО - пока я вчитываюсь в сюжет, они уже всё проскипали и бегут бить несчастных мобов, чтобы поскорее добраться до следующего уровня/локации. И таких, видимо, большинство...
Что-то похожее было в первой Mafia, там каждую припаркованную машину нужно было вскрывать через эту "гениальную" мини-игру, а не выбивать стекло, как в ГТА. Мини-игра хорошая и работает на атмосферу, но слишком навязчивая, хотел бы я замки взламывать - делал бы это ИРЛ, ведь подходящий замок легко купить. Короче, мини-игры должны быть уместны и не вызывать негатива своей излишней навязчивостью или сложностью.
В остальном... Звучит прикольно, но где, собственно, квесты? Вот я тебе уже который раз пишу про то, что можно нагенерировать хоть прям сейчас 100500 квестов про убийство мобов, сбор и доставку предметов, сопровождение непися и т.п., но будет ли это интересно? Так ли уж необходимы эти сотни случайно сгенерированных квестов...
Кстати, ты не задумывался, зачем вообще в (ММО)РПГ пихают так много побочных квестов? Тупо чтобы время прохождения растянуть, особенно если речь идёт о ММО. Вот и причина всех этих болванчиков, ждущих Того Единственного, кто сможет решить все накопившиеся у них проблемы...
>интересные квесты
Всё зависит от ЦА. Мне, например, нравились миссии в ГТА, где нужно машинки угонять, скрываться от полиции и аккуратно, без ДТП доставлять их на склад или покупателю. И что дальше? Мои хотелки не совпадут с твоими хотелками или хотелками того анона.
Поэтому я и предложил тому анону САМОМУ написать некоторое количество лично ему интересных квестов (фокусируясь на геймплее, а не на диалогах, если игра не текстовая). Он же хочет делать игру своей мечты, а не моей или твоей. Вот напишет квесты-примеры, и дальше можно будет думать, как их можно обобщить и процедурно генерировать, или скормить нейронке. И нужно ли.
>>02715
>Диалог - это каркас квеста.
>метаданные для генерации игровых объектов
Сильно сомневаюсь, что в любом квестовом диалоге достаточно "метаданных" для генерации "игровых объектов". Вообще не ясно, что ты имеешь в виду. Из фразы "эй, мужик, иди убей 15 волков" должны родиться 3D модели волков в ближайшем лесу?
>Сегодняшнему игроку нужна история
Смелое утверждение. Тем временем большинство игроков дрочат либо в онлайн-дрочильни, либо в мобильные дрочильни, где текст в лучшем случае на кнопках меню есть. Сегодня вообще выгоднее всего не иметь текста в игре даже на кнопках, чтобы покрыть максимально возможную аудиторию (весь мир)... Не спорю, любители историй тоже есть, но их не стало сильно больше, а вот казуальных игроков стало значительно больше. Хочешь историю? Прочитай в интернете, в электронных книгах, посмотри в кино, сериале или на ютубе, послушай аудиокнигу или онлайн-радио. Нет смысла покупать и играть в игру, если тебя интересует только история. В игры всё-таки ради геймплея играют, а история всегда была и остаётся поводом погрузиться в геймплей, поэтому у игр зачастую такие бредовые и поверхностные истории. ...Окей, история может быть изображена без текста (все мы видили примеры таких игр), но даже в таком случае это скорее декорация для геймплея, а не основа игры.
>по пути прокачиваться
Любители прокачки вообще сюжет игнорируют. Собирают идеальные билды персонажей, целыми днями гриндят одну локацию и т.д. Им некогда твои буквы читать, если за чтение не дают экспы и можно просто скипнуть весь текст до награды. Встречал таких в ММО - пока я вчитываюсь в сюжет, они уже всё проскипали и бегут бить несчастных мобов, чтобы поскорее добраться до следующего уровня/локации. И таких, видимо, большинство...
>Придумал гениальную мини-игру, смотри не укради! Короче, на экране замочная скважина и отмычка, клавишами A и D вращаешь отмычку, ЛКМ поворачиваешь скважину отвёрткой. Если не попадаешь в правильное положение, скважина упирается и наносит хиты хитпоинтам отмычки.
Что-то похожее было в первой Mafia, там каждую припаркованную машину нужно было вскрывать через эту "гениальную" мини-игру, а не выбивать стекло, как в ГТА. Мини-игра хорошая и работает на атмосферу, но слишком навязчивая, хотел бы я замки взламывать - делал бы это ИРЛ, ведь подходящий замок легко купить. Короче, мини-игры должны быть уместны и не вызывать негатива своей излишней навязчивостью или сложностью.
В остальном... Звучит прикольно, но где, собственно, квесты? Вот я тебе уже который раз пишу про то, что можно нагенерировать хоть прям сейчас 100500 квестов про убийство мобов, сбор и доставку предметов, сопровождение непися и т.п., но будет ли это интересно? Так ли уж необходимы эти сотни случайно сгенерированных квестов...
Кстати, ты не задумывался, зачем вообще в (ММО)РПГ пихают так много побочных квестов? Тупо чтобы время прохождения растянуть, особенно если речь идёт о ММО. Вот и причина всех этих болванчиков, ждущих Того Единственного, кто сможет решить все накопившиеся у них проблемы...
>>02688
Всё зависит от ЦА. Мне, например, нравились миссии в ГТА, где нужно машинки угонять, скрываться от полиции и аккуратно, без ДТП доставлять их на склад или покупателю. И что дальше? Мои хотелки не совпадут с твоими хотелками или хотелками того анона.
Поэтому я и предложил тому анону САМОМУ написать некоторое количество лично ему интересных квестов (фокусируясь на геймплее, а не на диалогах, если игра не текстовая). Он же хочет делать игру своей мечты, а не моей или твоей. Вот напишет квесты-примеры, и дальше можно будет думать, как их можно обобщить и процедурно генерировать, или скормить нейронке. И нужно ли.
>>02715
Сильно сомневаюсь, что в любом квестовом диалоге достаточно "метаданных" для генерации "игровых объектов". Вообще не ясно, что ты имеешь в виду. Из фразы "эй, мужик, иди убей 15 волков" должны родиться 3D модели волков в ближайшем лесу?
Смелое утверждение. Тем временем большинство игроков дрочат либо в онлайн-дрочильни, либо в мобильные дрочильни, где текст в лучшем случае на кнопках меню есть. Сегодня вообще выгоднее всего не иметь текста в игре даже на кнопках, чтобы покрыть максимально возможную аудиторию (весь мир)... Не спорю, любители историй тоже есть, но их не стало сильно больше, а вот казуальных игроков стало значительно больше. Хочешь историю? Прочитай в интернете, в электронных книгах, посмотри в кино, сериале или на ютубе, послушай аудиокнигу или онлайн-радио. Нет смысла покупать и играть в игру, если тебя интересует только история. В игры всё-таки ради геймплея играют, а история всегда была и остаётся поводом погрузиться в геймплей, поэтому у игр зачастую такие бредовые и поверхностные истории. ...Окей, история может быть изображена без текста (все мы видили примеры таких игр), но даже в таком случае это скорее декорация для геймплея, а не основа игры.
Любители прокачки вообще сюжет игнорируют. Собирают идеальные билды персонажей, целыми днями гриндят одну локацию и т.д. Им некогда твои буквы читать, если за чтение не дают экспы и можно просто скипнуть весь текст до награды. Встречал таких в ММО - пока я вчитываюсь в сюжет, они уже всё проскипали и бегут бить несчастных мобов, чтобы поскорее добраться до следующего уровня/локации. И таких, видимо, большинство...
Что-то похожее было в первой Mafia, там каждую припаркованную машину нужно было вскрывать через эту "гениальную" мини-игру, а не выбивать стекло, как в ГТА. Мини-игра хорошая и работает на атмосферу, но слишком навязчивая, хотел бы я замки взламывать - делал бы это ИРЛ, ведь подходящий замок легко купить. Короче, мини-игры должны быть уместны и не вызывать негатива своей излишней навязчивостью или сложностью.
В остальном... Звучит прикольно, но где, собственно, квесты? Вот я тебе уже который раз пишу про то, что можно нагенерировать хоть прям сейчас 100500 квестов про убийство мобов, сбор и доставку предметов, сопровождение непися и т.п., но будет ли это интересно? Так ли уж необходимы эти сотни случайно сгенерированных квестов...
Кстати, ты не задумывался, зачем вообще в (ММО)РПГ пихают так много побочных квестов? Тупо чтобы время прохождения растянуть, особенно если речь идёт о ММО. Вот и причина всех этих болванчиков, ждущих Того Единственного, кто сможет решить все накопившиеся у них проблемы...
>интересные квесты
Всё зависит от ЦА. Мне, например, нравились миссии в ГТА, где нужно машинки угонять, скрываться от полиции и аккуратно, без ДТП доставлять их на склад или покупателю. И что дальше? Мои хотелки не совпадут с твоими хотелками или хотелками того анона.
Поэтому я и предложил тому анону САМОМУ написать некоторое количество лично ему интересных квестов (фокусируясь на геймплее, а не на диалогах, если игра не текстовая). Он же хочет делать игру своей мечты, а не моей или твоей. Вот напишет квесты-примеры, и дальше можно будет думать, как их можно обобщить и процедурно генерировать, или скормить нейронке. И нужно ли.
>>02715
>Диалог - это каркас квеста.
>метаданные для генерации игровых объектов
Сильно сомневаюсь, что в любом квестовом диалоге достаточно "метаданных" для генерации "игровых объектов". Вообще не ясно, что ты имеешь в виду. Из фразы "эй, мужик, иди убей 15 волков" должны родиться 3D модели волков в ближайшем лесу?
>Сегодняшнему игроку нужна история
Смелое утверждение. Тем временем большинство игроков дрочат либо в онлайн-дрочильни, либо в мобильные дрочильни, где текст в лучшем случае на кнопках меню есть. Сегодня вообще выгоднее всего не иметь текста в игре даже на кнопках, чтобы покрыть максимально возможную аудиторию (весь мир)... Не спорю, любители историй тоже есть, но их не стало сильно больше, а вот казуальных игроков стало значительно больше. Хочешь историю? Прочитай в интернете, в электронных книгах, посмотри в кино, сериале или на ютубе, послушай аудиокнигу или онлайн-радио. Нет смысла покупать и играть в игру, если тебя интересует только история. В игры всё-таки ради геймплея играют, а история всегда была и остаётся поводом погрузиться в геймплей, поэтому у игр зачастую такие бредовые и поверхностные истории. ...Окей, история может быть изображена без текста (все мы видили примеры таких игр), но даже в таком случае это скорее декорация для геймплея, а не основа игры.
>по пути прокачиваться
Любители прокачки вообще сюжет игнорируют. Собирают идеальные билды персонажей, целыми днями гриндят одну локацию и т.д. Им некогда твои буквы читать, если за чтение не дают экспы и можно просто скипнуть весь текст до награды. Встречал таких в ММО - пока я вчитываюсь в сюжет, они уже всё проскипали и бегут бить несчастных мобов, чтобы поскорее добраться до следующего уровня/локации. И таких, видимо, большинство...
>Придумал гениальную мини-игру, смотри не укради! Короче, на экране замочная скважина и отмычка, клавишами A и D вращаешь отмычку, ЛКМ поворачиваешь скважину отвёрткой. Если не попадаешь в правильное положение, скважина упирается и наносит хиты хитпоинтам отмычки.
Что-то похожее было в первой Mafia, там каждую припаркованную машину нужно было вскрывать через эту "гениальную" мини-игру, а не выбивать стекло, как в ГТА. Мини-игра хорошая и работает на атмосферу, но слишком навязчивая, хотел бы я замки взламывать - делал бы это ИРЛ, ведь подходящий замок легко купить. Короче, мини-игры должны быть уместны и не вызывать негатива своей излишней навязчивостью или сложностью.
В остальном... Звучит прикольно, но где, собственно, квесты? Вот я тебе уже который раз пишу про то, что можно нагенерировать хоть прям сейчас 100500 квестов про убийство мобов, сбор и доставку предметов, сопровождение непися и т.п., но будет ли это интересно? Так ли уж необходимы эти сотни случайно сгенерированных квестов...
Кстати, ты не задумывался, зачем вообще в (ММО)РПГ пихают так много побочных квестов? Тупо чтобы время прохождения растянуть, особенно если речь идёт о ММО. Вот и причина всех этих болванчиков, ждущих Того Единственного, кто сможет решить все накопившиеся у них проблемы...
>>02826 (Del)
https://ru.wikipedia.org/wiki/Момент_силы
А тебе зачем? Воспринимай как попугаев.
>torque
https://ru.wikipedia.org/wiki/Момент_силы
А тебе зачем? Воспринимай как попугаев.
1,3 Мб, webm,800x800, 0:51
Ржал как конь, я не шучу.
>>02710
Ну так-то речь про то, чтобы взять конкретные квесты из конкретных игр и проанализировать, чем же они хороши. В процессе анализа ностальгия сама отсеется, на то он и анализ, то есть разбор на детали. А уже пользуясь этой информацией пытаться делать свои. А вслепую: "хочу сделать хорошо, но что такое хорошо - не знаю" - это прямая дорога к говну.
Ну так-то речь про то, чтобы взять конкретные квесты из конкретных игр и проанализировать, чем же они хороши. В процессе анализа ностальгия сама отсеется, на то он и анализ, то есть разбор на детали. А уже пользуясь этой информацией пытаться делать свои. А вслепую: "хочу сделать хорошо, но что такое хорошо - не знаю" - это прямая дорога к говну.
421 Кб, 2083x1842>>02851
Несколько раз в разных местах опрашивал людей, а что именно понравилось в фильме книге сюжете игры который вы называете крутым - отмалчиваются. Такое впечатление что это что то с гормонами работает только моменте когда смотришь. З.ы. 36 мировых сюжетов.
Несколько раз в разных местах опрашивал людей, а что именно понравилось в фильме книге сюжете игры который вы называете крутым - отмалчиваются. Такое впечатление что это что то с гормонами работает только моменте когда смотришь. З.ы. 36 мировых сюжетов.
>>02827
У меня есть точные расчеты по формулам, которые дают правильный результат, и в ручной проверке и в гдскрипте. но вот при применении к телу оно просто вращается дрелью. Вот и думаю, может надо просто коеффициент.
У меня есть точные расчеты по формулам, которые дают правильный результат, и в ручной проверке и в гдскрипте. но вот при применении к телу оно просто вращается дрелью. Вот и думаю, может надо просто коеффициент.
>>02852
А точно крутым называют именно сюжет, а не графику, спецэффекты, геймплей, описания местности и персонажей (книги)?
>>02851
Хороший квест не вызывает у игрока скуку лёгкостью или рутиной, но и не заставляет его бегать по интернету в поисках решения или дрочить клавиатуру в попытках выработать скилл.
Но в самом общем случае рассуждать об этом бесполезно. Нужно определиться с ЦА и анализировать уже эту ЦА, если ты пытаешься сделать оригинальную игру, а не клон существующей.
Если же задача сделать клон, который понравится ЦА уже существующей игры - тогда, действительно, нужно анализировать составляющие той игры и пытаться скопировать их в свой проект, избавив от недостатков и доработав по необходимости.
Алсо, несмотря на то, что конкретный человек на прямой вопрос "что понравилось в сюжете" ответить не всегда сможет, имеет смысл читать форумы в поисках отзывов на какие-то элементы сюжета. Хотя, конечно, так получается ориентация на тех, кто громче всех кричит, и игнорирование тех, кто отзывов не пишет...
>что именно понравилось в фильме книге сюжете игры который вы называете крутым
А точно крутым называют именно сюжет, а не графику, спецэффекты, геймплей, описания местности и персонажей (книги)?
>>02851
>проанализировать, чем же они хороши
Хороший квест не вызывает у игрока скуку лёгкостью или рутиной, но и не заставляет его бегать по интернету в поисках решения или дрочить клавиатуру в попытках выработать скилл.
Но в самом общем случае рассуждать об этом бесполезно. Нужно определиться с ЦА и анализировать уже эту ЦА, если ты пытаешься сделать оригинальную игру, а не клон существующей.
Если же задача сделать клон, который понравится ЦА уже существующей игры - тогда, действительно, нужно анализировать составляющие той игры и пытаться скопировать их в свой проект, избавив от недостатков и доработав по необходимости.
Алсо, несмотря на то, что конкретный человек на прямой вопрос "что понравилось в сюжете" ответить не всегда сможет, имеет смысл читать форумы в поисках отзывов на какие-то элементы сюжета. Хотя, конечно, так получается ориентация на тех, кто громче всех кричит, и игнорирование тех, кто отзывов не пишет...
>>00308 (OP)
Аноны если я гумманитарий, и вообще туповатый, мне как гдскрипт учить? сразу его или нужно сначала какието общие основы программирования изучать??
Аноны если я гумманитарий, и вообще туповатый, мне как гдскрипт учить? сразу его или нужно сначала какието общие основы программирования изучать??
>>02891
У Маши 3 яблока, у Пети 2 яблока. Вася отобрал у Маши и Пети яблоки и разделил их между собой и своими друзьями, Лёней и Стасом. Вопрос. Сколько яблок досталось Васе?
> мне как гдскрипт учить?
> сразу его или нужно сначала какието
> я гумманитарий
> и вообще туповатый
У Маши 3 яблока, у Пети 2 яблока. Вася отобрал у Маши и Пети яблоки и разделил их между собой и своими друзьями, Лёней и Стасом. Вопрос. Сколько яблок досталось Васе?
654 Кб, 1440x900Хм-м-м, я тут последнее время обыгрался в Stardew Valley и дома у меня растения уже девать некуда... Как думаете, как будет выглядеть механика растениеводства в ГТА-лайк игре? Воруй семена @ сажай овощи; грабь магазины @ украшай свой сад; угоняй грузовик с навозом @ удобряй грядки; убивай половину жителей @ выращивай на их могилах фруктовые деревья; продавай выращенные овощи @ воруй их обратно, чтобы приготовить; связывай случайных прохожих в подвале @ выращивай на них грибы... Топ геймплей, 10 овощей из 10 угнанных фургонов, сюжет не нужен, реиграбельность 146%, графон не нужен, озвучка не нужна, буду выращивать овощи в багажнике угнанного автомобиля ещё.
О, а ведь зайчатки грядок с заборчиками у меня были ещё прошлым летом, но тогда я об этом серьёзно не задумывался и не ожидал, что выращивание овощей может так сильно затягивать (из опыта игр с механикой растениеводства на тот момент был только майнкрафт и Plants vs Zombies, ну ещё Terraria и Starbound, но там вообще максимально уныло, скука в квадрате).
Всё равно у меня нет чёткого видения желаемой игры (коротко можно сказать "игра обо всём и ни о чём"), хотелки меняются не то что каждый год, а буквально каждый день, геймдизайнер из меня вообще никакущий получается. И вообще я не игру делаю, а играю в разработку игр, не планируя когда-либо добираться до "релиза", вот... Но разве это плохо?
>>02763
О, а ведь зайчатки грядок с заборчиками у меня были ещё прошлым летом, но тогда я об этом серьёзно не задумывался и не ожидал, что выращивание овощей может так сильно затягивать (из опыта игр с механикой растениеводства на тот момент был только майнкрафт и Plants vs Zombies, ну ещё Terraria и Starbound, но там вообще максимально уныло, скука в квадрате).
Всё равно у меня нет чёткого видения желаемой игры (коротко можно сказать "игра обо всём и ни о чём"), хотелки меняются не то что каждый год, а буквально каждый день, геймдизайнер из меня вообще никакущий получается. И вообще я не игру делаю, а играю в разработку игр, не планируя когда-либо добираться до "релиза", вот... Но разве это плохо?
>>02763
>>02891
Да там всё просто, достаточно булеву логику освоить, а остальное по ассоциациям с ИРЛ объектами легко понять и запомнить (пример: переменная - это коробка, ссылка - это бумажка с номером другой коробки, лежащая в одной из коробок, массив - это шкаф с кучей пронумерованных ящичков-коробок, словарь - тот же шкаф, но у ящичков есть буквенные имена, процедура - это кулинарный рецепт с ингредиентами и последовательностью шагов готовки блюда, а функция требует приготовленное блюдо вернуть непосредственно в руки заказчику). "Гуманитарии" не не могут в программирование, они просто ленятся, а так программировать способен каждый, кто не ленится думать и читать.
>>02902 (Del)
GDScript похож на питон, но питон сложнее и изучать питон не нужно. Лучше сразу с GDScript начать, чтобы не забивать голову тем, чего в нём нет и скорее всего никогда не будет. Сразу можно будет игровые примеры делать, а не унылые цифры в консоль выводить (знаю про игровые фреймворки для питона, но это другое).
>>02925
Задачки с яблоками слабо относятся к программированию. Задачки с яблоками - это математика, а программирование - это командование супер быстрым математиком, который может почитать триллионы задач про яблоки за считанные секунды, если ты задашь ему правильную последовательность команд для решения этих задач. Т.е. не нужно знать ответ на задачу, чтобы решить её на компьютере (главное помнить, что компьютеру плевать на корректность ответа, что ты ему сказал - то и сделает, даже если ты приказал сделать что-то ошибочное или абсурдное).
>общие основы программирования
Да там всё просто, достаточно булеву логику освоить, а остальное по ассоциациям с ИРЛ объектами легко понять и запомнить (пример: переменная - это коробка, ссылка - это бумажка с номером другой коробки, лежащая в одной из коробок, массив - это шкаф с кучей пронумерованных ящичков-коробок, словарь - тот же шкаф, но у ящичков есть буквенные имена, процедура - это кулинарный рецепт с ингредиентами и последовательностью шагов готовки блюда, а функция требует приготовленное блюдо вернуть непосредственно в руки заказчику). "Гуманитарии" не не могут в программирование, они просто ленятся, а так программировать способен каждый, кто не ленится думать и читать.
>>02902 (Del)
>вводный курс по питону
GDScript похож на питон, но питон сложнее и изучать питон не нужно. Лучше сразу с GDScript начать, чтобы не забивать голову тем, чего в нём нет и скорее всего никогда не будет. Сразу можно будет игровые примеры делать, а не унылые цифры в консоль выводить (знаю про игровые фреймворки для питона, но это другое).
>>02925
Задачки с яблоками слабо относятся к программированию. Задачки с яблоками - это математика, а программирование - это командование супер быстрым математиком, который может почитать триллионы задач про яблоки за считанные секунды, если ты задашь ему правильную последовательность команд для решения этих задач. Т.е. не нужно знать ответ на задачу, чтобы решить её на компьютере (главное помнить, что компьютеру плевать на корректность ответа, что ты ему сказал - то и сделает, даже если ты приказал сделать что-то ошибочное или абсурдное).
>>02934 (Del)
Так скажу: у тебя тело вращается дрелью, а у меня спокойно и контролируемо.
> Как скажешь.
Так скажу: у тебя тело вращается дрелью, а у меня спокойно и контролируемо.
>>02988 (Del)
Нет, не на глаз. Если формула в градусах (а большинство формул из классической физики в градусах), я перевожу в градусы из радиан, в которых движок выдаёт вращение.
Об этом я сразу и написал:
>>02826 (Del)
>>02923
Непонятно, почему ты второй день жопу морщишь вместо того, чтобы игры делать?
> Возможно ты просто на глаз подбирал параметры
Нет, не на глаз. Если формула в градусах (а большинство формул из классической физики в градусах), я перевожу в градусы из радиан, в которых движок выдаёт вращение.
Об этом я сразу и написал:
>>02826 (Del)
> Какая единица измерения в torque?
>>02923
> В радианах
Непонятно, почему ты второй день жопу морщишь вместо того, чтобы игры делать?
>>03010 (Del)
Тот анон в чём-то прав. 180 градусов = 3.14 радианов, если этого не учитывать, будет вращение более чем в 57 раз быстрее ожидаемого. Где-то в формулах у тебя должны быть градусы, типа, "я хочу повернуть объёкт массой 50 Н на 10 градусов, сколько силы мне нужно для этого приложить?", вот замени градусы на радианы. Грубо говоря, вместо числа 10 в формуле будет 0.157, и тогда результат будет в 57 раз меньше, а, значит, вращаться объект будет медленнее.
Если ты хочешь ТОЛКНУТЬ объект в каком-то направлении так, чтобы он закрутился, тогда используй apply_impulse с точкой применения, отличной от нулевого вектора. Если оси объекта не зафиксированы, движок сам раскрутит его по каким-то своим формулам. Но учитывай, что в Bullet центр массы в нулевом векторе, а в GodotPhysics центр массы - среднее арифметическое положений CollisionShape в локальной системе координат RigidBody. Т.е. если ты хочешь реалистично вращать, скажем, топор, в Bullet нужно сдвинуть шейпы в сторону металлической части, а в GodotPhysics нужно терпеть, страдать и ждать 4.0, авось там это исправят (или можно добавить лишний коллиженшейп-пустышку, но это некрасивый костыль).
Что касается add_torque, то, мне кажется, он не предназначен для произвольного вращения, потому что симулирует естественное вращение вокруг центра масс. Если тебе нужно нацепить что-то длинное на ротор двигателя лёгким концом, используй для этого джойнты или вообще откажись от физики и отображай это анимациями. Сам по себе предмет, брошенный на идеально гладкую поверхность или висящий в невесомости, будет вращаться вокруг центра масс, а не вокруг рандомно взятой точки. ИРЛ ротор со смещённым от оси вращения центром массы создаёт дикие вибрации и может устроить полный расколбас системы, тебе это нужно? Физический движок и без этого постоянно колбасит...
Тот анон в чём-то прав. 180 градусов = 3.14 радианов, если этого не учитывать, будет вращение более чем в 57 раз быстрее ожидаемого. Где-то в формулах у тебя должны быть градусы, типа, "я хочу повернуть объёкт массой 50 Н на 10 градусов, сколько силы мне нужно для этого приложить?", вот замени градусы на радианы. Грубо говоря, вместо числа 10 в формуле будет 0.157, и тогда результат будет в 57 раз меньше, а, значит, вращаться объект будет медленнее.
>проблема с точкой приложения
Если ты хочешь ТОЛКНУТЬ объект в каком-то направлении так, чтобы он закрутился, тогда используй apply_impulse с точкой применения, отличной от нулевого вектора. Если оси объекта не зафиксированы, движок сам раскрутит его по каким-то своим формулам. Но учитывай, что в Bullet центр массы в нулевом векторе, а в GodotPhysics центр массы - среднее арифметическое положений CollisionShape в локальной системе координат RigidBody. Т.е. если ты хочешь реалистично вращать, скажем, топор, в Bullet нужно сдвинуть шейпы в сторону металлической части, а в GodotPhysics нужно терпеть, страдать и ждать 4.0, авось там это исправят (или можно добавить лишний коллиженшейп-пустышку, но это некрасивый костыль).
Что касается add_torque, то, мне кажется, он не предназначен для произвольного вращения, потому что симулирует естественное вращение вокруг центра масс. Если тебе нужно нацепить что-то длинное на ротор двигателя лёгким концом, используй для этого джойнты или вообще откажись от физики и отображай это анимациями. Сам по себе предмет, брошенный на идеально гладкую поверхность или висящий в невесомости, будет вращаться вокруг центра масс, а не вокруг рандомно взятой точки. ИРЛ ротор со смещённым от оси вращения центром массы создаёт дикие вибрации и может устроить полный расколбас системы, тебе это нужно? Физический движок и без этого постоянно колбасит...
>>03026 (Del)
Тебе с самого начала ответили: попугаи.
Там нужен вектор, вектор задаёт ось вращения, длина вектора обозначает силу вращения. Всё остальное - попугаи.
Вообще забудь о физически точной симуляции средствами игрового физического движка. Игровые физические движки созданы не для этого, а чтобы правдоподобная физика работала в реальном времени и не слишком часто глючила. Хочешь полноценную симуляцию - ищи полноценные физические движки, которые не в реальном времени работают и честно вычисляют все законы физики, без тех костылей, которыми утыканы игровые физические движки.
Даже в сраных ААА играх физику часто колбасит, а ты хочешь серьёзный симулятор с серьёзным матаном под капотом.
Просто забудь и сделай казуальную игру.
>какая единица измерения в add_torque
Тебе с самого начала ответили: попугаи.
Там нужен вектор, вектор задаёт ось вращения, длина вектора обозначает силу вращения. Всё остальное - попугаи.
Вообще забудь о физически точной симуляции средствами игрового физического движка. Игровые физические движки созданы не для этого, а чтобы правдоподобная физика работала в реальном времени и не слишком часто глючила. Хочешь полноценную симуляцию - ищи полноценные физические движки, которые не в реальном времени работают и честно вычисляют все законы физики, без тех костылей, которыми утыканы игровые физические движки.
Даже в сраных ААА играх физику часто колбасит, а ты хочешь серьёзный симулятор с серьёзным матаном под капотом.
Просто забудь и сделай казуальную игру.
>>03041 (Del)
С этого и нужно было начинать. Какой другой? Havok, PhysX? Посмотреть документацию, что ты там используешь, и сравнить. Правда, в документации Bullet нет информации о том, в каких единицах действуют force/torque. Там только код самих функций, в котором полученное значение умножается на какой-то коэффициент, а что это за коэффициент и откуда он берётся - я не нашёл (ну, я не искал специально, меня это не интересует).
Бесит, конечно, что в документации на функцию не пишут всей необходимой информации о ней и том, с чем она работает.
Почему программисты не любят документировать код?
>в другом движке
С этого и нужно было начинать. Какой другой? Havok, PhysX? Посмотреть документацию, что ты там используешь, и сравнить. Правда, в документации Bullet нет информации о том, в каких единицах действуют force/torque. Там только код самих функций, в котором полученное значение умножается на какой-то коэффициент, а что это за коэффициент и откуда он берётся - я не нашёл (ну, я не искал специально, меня это не интересует).
Бесит, конечно, что в документации на функцию не пишут всей необходимой информации о ней и том, с чем она работает.
Почему программисты не любят документировать код?
17 Кб, 326x242>>03077
В радианах.
> Правда, в документации Bullet нет информации о том, в каких единицах действуют force/torque.
В радианах.
>>03100
Где это сказано? Не вижу.
https://pybullet.org/Bullet/BulletFull/classbtRigidBody.html#aede3cf53474f4b367693b19871692b99
Есть только код из исходников:
Но мне лично это ни о чём не говорит.
Кстати, как на дваче постить звёздочку? Обычно вместо неё получается наклонный текст как с тегом [ i ].
>В радианах.
Где это сказано? Не вижу.
https://pybullet.org/Bullet/BulletFull/classbtRigidBody.html#aede3cf53474f4b367693b19871692b99
Есть только код из исходников:
>void applyTorque(const btVector3& torque)
>{
>m_totalTorque += torque (умножить) m_angularFactor;
>}
Но мне лично это ни о чём не говорит.
Кстати, как на дваче постить звёздочку? Обычно вместо неё получается наклонный текст как с тегом [ i ].
>>03138
Это сказано в фундаментальной матчасти по информатике. Это классика, её знать надо.
Везде в информационных системах в качестве основной угловой величины выбраны радианы.
В годоте основные функции поворота принимают и возвращают значения в радианах.
Для простоты работы (в основном для инспектора) Хуан сделал прокси-методы, которые показывают и устанавливают в градусах.
Радианы выбраны не случайно, потому что это математическая база, понятная всем и одинаковая у всех.
Потому что градусов в круге может быть сколько угодно, а радианов, как верно заметил анон выше, в круге ровно ПИ. 360 градусов - знаменитая классика, но ты можешь сделать в круге, скажем 6 градусов, и это будет работать. И будет "круг" из 6 огромных градусов, то есть, правильный шестиугольник. А если сделать круг из 12 градусов, то будет? Угадай что. А круг из 60 градусов что будет? Домашнее задание тебе.
Так что, при малейших сомнениях, в чём информационно-вычислительная система принимает угловые величины, знай. В радианах. И переводи их из радианов по формуле в ту величину, которая используется в твоей охуительной формуле.
> Где это сказано? Не вижу.
Это сказано в фундаментальной матчасти по информатике. Это классика, её знать надо.
Везде в информационных системах в качестве основной угловой величины выбраны радианы.
В годоте основные функции поворота принимают и возвращают значения в радианах.
Для простоты работы (в основном для инспектора) Хуан сделал прокси-методы, которые показывают и устанавливают в градусах.
Радианы выбраны не случайно, потому что это математическая база, понятная всем и одинаковая у всех.
Потому что градусов в круге может быть сколько угодно, а радианов, как верно заметил анон выше, в круге ровно ПИ. 360 градусов - знаменитая классика, но ты можешь сделать в круге, скажем 6 градусов, и это будет работать. И будет "круг" из 6 огромных градусов, то есть, правильный шестиугольник. А если сделать круг из 12 градусов, то будет? Угадай что. А круг из 60 градусов что будет? Домашнее задание тебе.
Так что, при малейших сомнениях, в чём информационно-вычислительная система принимает угловые величины, знай. В радианах. И переводи их из радианов по формуле в ту величину, которая используется в твоей охуительной формуле.
>>03213
У меня такое же ебало было, когда мне это впервые сказали, в далёком 1998 году. А потом я как понял, а потом каааак осознал!
У меня такое же ебало было, когда мне это впервые сказали, в далёком 1998 году. А потом я как понял, а потом каааак осознал!
>>03207
Если у тебя крутящий момент измеряется в радианах, то сила - в метрах. Или килограммах.
Если у тебя крутящий момент измеряется в радианах, то сила - в метрах. Или килограммах.
>>03229 (Del)
Разумеется. Но функции поворота приведены в качестве примера. А то что ты имено к ним доебался, показывает глубину твоего Даннинг-Крюгера.
Разумеется. Но функции поворота приведены в качестве примера. А то что ты имено к ним доебался, показывает глубину твоего Даннинг-Крюгера.
>>03207
Не везде. Ты в любой момент можешь запрограммировать систему на градусах или любой другой вымышленной единице.
Ты даже тут ошибся, в круге 2π радиан.
Неверно, градус - это строго 1/360 круга. А вот град - это 1/400. Если ты хочешь что-то другое, придумай другое название.
Тогда ты будешь обязан назвать эти "градусы" каким-то своим названием, например, "шесрадусы". Это как с опенсурс софтом, ты не можешь создать форк известного ПО и продолжать называть его прежним именем: ты должен придумать форку новое имя, чтобы его можно было отличать от оригинала.
>Везде в информационных системах в качестве основной угловой величины выбраны радианы.
Не везде. Ты в любой момент можешь запрограммировать систему на градусах или любой другой вымышленной единице.
>радианов в круге ровно ПИ
Ты даже тут ошибся, в круге 2π радиан.
>градусов в круге может быть сколько угодно
Неверно, градус - это строго 1/360 круга. А вот град - это 1/400. Если ты хочешь что-то другое, придумай другое название.
>ты можешь сделать в круге, скажем 6 градусов
Тогда ты будешь обязан назвать эти "градусы" каким-то своим названием, например, "шесрадусы". Это как с опенсурс софтом, ты не можешь создать форк известного ПО и продолжать называть его прежним именем: ты должен придумать форку новое имя, чтобы его можно было отличать от оригинала.
1,8 Мб, 1080x1920Ля чо придумал, годаны!
Берешь свит хоум тридэ, софт для рисования поэтажных планов домов и квартир. В нём набрасываешь себе особняк в стиле резидента ивола, с тайными ходами и жуткими подземельями.
Потом экспортируешь модельку в блендер, добавляешь готишную лепнину на углы, вырезаешь лишнее (дефолтные статичные двери), добавляешь нужное.
И закидываешь в годот.
Там уже доставляешь в пустые проёмы динамические двери, которые отдельно рисуешь в блендере по образцам из свитхоума или свои. Навешиваешь скрипты, триггеры, анимации.
Устанавливаешь персонажа, мобов и неписей.
Хуяк-хуяк и в продакшен! Инди-хоррор готов!
Что может пойти не так?
Пикрелейтед рендер из свитхоума. Начал набрасывать план в 14.00 сего дня. К полуночи черновой вариант коробки готов.
Берешь свит хоум тридэ, софт для рисования поэтажных планов домов и квартир. В нём набрасываешь себе особняк в стиле резидента ивола, с тайными ходами и жуткими подземельями.
Потом экспортируешь модельку в блендер, добавляешь готишную лепнину на углы, вырезаешь лишнее (дефолтные статичные двери), добавляешь нужное.
И закидываешь в годот.
Там уже доставляешь в пустые проёмы динамические двери, которые отдельно рисуешь в блендере по образцам из свитхоума или свои. Навешиваешь скрипты, триггеры, анимации.
Устанавливаешь персонажа, мобов и неписей.
Хуяк-хуяк и в продакшен! Инди-хоррор готов!
Что может пойти не так?
Пикрелейтед рендер из свитхоума. Начал набрасывать план в 14.00 сего дня. К полуночи черновой вариант коробки готов.
>>03483 (Del)
Я пока ещё ищу оптимальный (для меня) способ прототипирования) CSG не подошли, слишком медленно я ими оперирую. А со СХ3Д красота, елозишь мышкой по плоскости, рисуешь по сути карту, а прога сама за тебя тридэ дорисовывает. Плюс - ты сразу можешь из опенсорсной онлайн библиотеки расставить по карте примитивную мебель, чтобы посмотреть, как это будет в итоге. Кубами такого не добиться в сопоставимые сроки. Бля, я похож на пиарщика.
Я пока ещё ищу оптимальный (для меня) способ прототипирования) CSG не подошли, слишком медленно я ими оперирую. А со СХ3Д красота, елозишь мышкой по плоскости, рисуешь по сути карту, а прога сама за тебя тридэ дорисовывает. Плюс - ты сразу можешь из опенсорсной онлайн библиотеки расставить по карте примитивную мебель, чтобы посмотреть, как это будет в итоге. Кубами такого не добиться в сопоставимые сроки. Бля, я похож на пиарщика.
>>03504
Так ведь из CSG можно создать прототипы мебели, сохранить их как отдельные сцены и расставлять по карте как цельные объекты. Я так одну мини-квартирку в Годо прототипировал, мне понравилось. Жаль я так и не смог применить её по назначению - сделать ИИ, который бы жил в этой квартире. Ну, это проблема дизайна, точнее, полного его отсутствия.
Совет: делай сначала кубик, обозначающий границы объекта, и сразу сохраняй в отдельную сцену. Таким образом ты можешь сразу начать расставлять его по сцене, а потом, если понадобится - увеличить его детализацию, сразу увидев изменения во всех местах использования. В принципе, похожий функционал есть и в Blender, но там это всё как-то сложнее и я не разобрался толком. Зато этот метод очень похож на работу в Inkscape, когда создаёшь клоны группы, и потом любые модификации внутри группы отображаются во всех клонах.
>CSG не подошли, слишком медленно
>расставить по карте примитивную мебель
Так ведь из CSG можно создать прототипы мебели, сохранить их как отдельные сцены и расставлять по карте как цельные объекты. Я так одну мини-квартирку в Годо прототипировал, мне понравилось. Жаль я так и не смог применить её по назначению - сделать ИИ, который бы жил в этой квартире. Ну, это проблема дизайна, точнее, полного его отсутствия.
Совет: делай сначала кубик, обозначающий границы объекта, и сразу сохраняй в отдельную сцену. Таким образом ты можешь сразу начать расставлять его по сцене, а потом, если понадобится - увеличить его детализацию, сразу увидев изменения во всех местах использования. В принципе, похожий функционал есть и в Blender, но там это всё как-то сложнее и я не разобрался толком. Зато этот метод очень похож на работу в Inkscape, когда создаёшь клоны группы, и потом любые модификации внутри группы отображаются во всех клонах.
>>03579
Знаю. Но он неочевиден для новичка. Я, например, мучился копипастом кучи нод в Godot. Хотя у меня и был опыт клонирования групп в Inkscape, но как-то не сразу перенёс опыт.
Правда ещё сам Godot может иногда лагать, если слишком глубокая вложенность сцен. На какой-то древней версии, помню, уже с 4-го уровня вложенности (tscn -> tscn -> tscn -> ...) были тормоза по 30 секунд при переключении вкладок. Я тогда забил на Годо на полгода минимум, разочаровавшись, что моя задумка нереализуема...
Знаю. Но он неочевиден для новичка. Я, например, мучился копипастом кучи нод в Godot. Хотя у меня и был опыт клонирования групп в Inkscape, но как-то не сразу перенёс опыт.
Правда ещё сам Godot может иногда лагать, если слишком глубокая вложенность сцен. На какой-то древней версии, помню, уже с 4-го уровня вложенности (tscn -> tscn -> tscn -> ...) были тормоза по 30 секунд при переключении вкладок. Я тогда забил на Годо на полгода минимум, разочаровавшись, что моя задумка нереализуема...
>>03629 (Del)
Дампы памяти сама винда создаёт (WER). Их создание можно отключить, если ты не отправляешь их разработчикам.
https://docs.microsoft.com/en-us/windows/win32/wer
Дампы памяти сама винда создаёт (WER). Их создание можно отключить, если ты не отправляешь их разработчикам.
https://docs.microsoft.com/en-us/windows/win32/wer
>>03662 (Del)
вот это реально меня бесит в современных ОС. кто вообще придумал что помойка, куда все проги срут, это правильно?
Безопасники говорят что это типа безопасней (если ограничения в правах, то проги не могут писать никуда кроме этих папок)...
Но во-первых нихуя не безопасно, так как по итогу эта помойка стала общей для всех - вспоминаем как вирусы воруют пароли и данные банковских карт с помощью такой вот папочки от браузера в Roaming, где хранятся все куки и кеши.
Во-вторых что сразу мешало сделать чтобы каждая прога писала свое говно в свою папку и никуда больше? То есть у проги должны быть права только на свою собственную папку. Тогда бы и не получалось что через 2-3 года использования в системе накопленно куча говна на терабайты.
Тоже на днях смотрел сколько у меня мусорного говна - около 60 гб всякого мусора от прог и игр, которые давно уже удалил. Давно я систему не чистил.
p.s. и это не проблема винды. Это как раз с хуелинуксов пришло. Первоначально винда как раз шла по пути - свое в своей папке.
>Roaming
>Local
вот это реально меня бесит в современных ОС. кто вообще придумал что помойка, куда все проги срут, это правильно?
Безопасники говорят что это типа безопасней (если ограничения в правах, то проги не могут писать никуда кроме этих папок)...
Но во-первых нихуя не безопасно, так как по итогу эта помойка стала общей для всех - вспоминаем как вирусы воруют пароли и данные банковских карт с помощью такой вот папочки от браузера в Roaming, где хранятся все куки и кеши.
Во-вторых что сразу мешало сделать чтобы каждая прога писала свое говно в свою папку и никуда больше? То есть у проги должны быть права только на свою собственную папку. Тогда бы и не получалось что через 2-3 года использования в системе накопленно куча говна на терабайты.
Тоже на днях смотрел сколько у меня мусорного говна - около 60 гб всякого мусора от прог и игр, которые давно уже удалил. Давно я систему не чистил.
p.s. и это не проблема винды. Это как раз с хуелинуксов пришло. Первоначально винда как раз шла по пути - свое в своей папке.
>>03667
Ты неправильно понял безопасников.
Она туда и пишет. Только не в roaming, как ты подумал, а в roaming/appname
> Безопасники говорят что это типа безопасней
> о во-первых нихуя не безопасно
Ты неправильно понял безопасников.
> что сразу мешало сделать чтобы каждая прога писала свое говно в свою папку и никуда больше?
Она туда и пишет. Только не в roaming, как ты подумал, а в roaming/appname
>>03662 (Del)
Я проверял, у меня был единственный дамп 3.4.4. Возможно, были и другие, я периодически произвожу очистку диска системной утилитой, которая, по идее, чистит все дампы самостоятельно.
Откуда столько? Я знаю, что после переименования проекта Godot считает его новым проектом, но 500 - это слишком.
>>03667
С каких пор у тебя пароли и данные банковских карт в куках? В куках должны быть только токены сессий, которые у любого нормального банка дольше 15 минут не бывают валидны. Окей, токен форума может быть валиден целый год (если нажмёшь "запомнить"), но, во-первых, кому ты нужен взламывать тебя на каком-то полудохлом форуме, а, во-вторых, помимо токена хорошо спроектированный сайт должен проверять соответствие браузера и геолокации по IP, делая токен невалидным при любых подозрениях на перемещение куки куда не следует.
Раньше так и было. Теперь - только с правами администратора, которые программа должна при каждом запуске запрашивать. Проблема тут в том, что если разрешить свободную запись в папку установленной программы, любой вирус может встроить свой исполняемый код в код программы. А создавать на каждую программу отдельного пользователя и назначать этому пользователю права только на одну папку, наверное, слишком затратно, и не спасает от вирусов, внедряющихся прямо в оперативной памяти. Т.е. основная цель разделения кода и данных в том, чтобы предотвратить укоренение вирусов в системе, а не кражу каких-то там паролей. Если вспомнить историю, от утечек паролей и других данных пострадали единицы, а вот от распространения вирусов весь интернет почти умирал несколько раз, принося огромные убытки компаниям, компьютеры которых массово превращались в тыкву.
Конечно, это всё хорошо только на словах - на практике я замечал множество программ, которые устанавливаются в папку с данными или кидают туда какие-то дополнительные исполняемые файлы. Говнодизайн от говнокодеров этих программ, что поделать, нужно просто избегать таких порождений.
Была какая-то программа, которая позволяла вычислить и вычистить все остаточные следы от ранее установленных программ - как из файловой системы, так и из реестра. Для большей эффективности предлагалось запускать установщик программы через неё, чтобы она запоминала, куда он насрал (с играми через стим, очевидно, так не получится). Я когда-то пользовался крякнутой версией, пока она не сломалась, а потом забил и чищу вручную с помощью WinDirStat - мне этого хватает, мелкий мусор не волнует.
>дампы появились только от последней версии
Я проверял, у меня был единственный дамп 3.4.4. Возможно, были и другие, я периодически произвожу очистку диска системной утилитой, которая, по идее, чистит все дампы самостоятельно.
>открытых проектов (у меня за 500 перевалило)
Откуда столько? Я знаю, что после переименования проекта Godot считает его новым проектом, но 500 - это слишком.
>>03667
>вспоминаем как вирусы воруют пароли и данные банковских карт с помощью такой вот папочки от браузера в Roaming, где хранятся все куки и кеши.
С каких пор у тебя пароли и данные банковских карт в куках? В куках должны быть только токены сессий, которые у любого нормального банка дольше 15 минут не бывают валидны. Окей, токен форума может быть валиден целый год (если нажмёшь "запомнить"), но, во-первых, кому ты нужен взламывать тебя на каком-то полудохлом форуме, а, во-вторых, помимо токена хорошо спроектированный сайт должен проверять соответствие браузера и геолокации по IP, делая токен невалидным при любых подозрениях на перемещение куки куда не следует.
>что сразу мешало сделать чтобы каждая прога писала свое говно в свою папку и никуда больше?
Раньше так и было. Теперь - только с правами администратора, которые программа должна при каждом запуске запрашивать. Проблема тут в том, что если разрешить свободную запись в папку установленной программы, любой вирус может встроить свой исполняемый код в код программы. А создавать на каждую программу отдельного пользователя и назначать этому пользователю права только на одну папку, наверное, слишком затратно, и не спасает от вирусов, внедряющихся прямо в оперативной памяти. Т.е. основная цель разделения кода и данных в том, чтобы предотвратить укоренение вирусов в системе, а не кражу каких-то там паролей. Если вспомнить историю, от утечек паролей и других данных пострадали единицы, а вот от распространения вирусов весь интернет почти умирал несколько раз, принося огромные убытки компаниям, компьютеры которых массово превращались в тыкву.
Конечно, это всё хорошо только на словах - на практике я замечал множество программ, которые устанавливаются в папку с данными или кидают туда какие-то дополнительные исполняемые файлы. Говнодизайн от говнокодеров этих программ, что поделать, нужно просто избегать таких порождений.
>около 60 гб всякого мусора от прог и игр, которые давно уже удалил
Была какая-то программа, которая позволяла вычислить и вычистить все остаточные следы от ранее установленных программ - как из файловой системы, так и из реестра. Для большей эффективности предлагалось запускать установщик программы через неё, чтобы она запоминала, куда он насрал (с играми через стим, очевидно, так не получится). Я когда-то пользовался крякнутой версией, пока она не сломалась, а потом забил и чищу вручную с помощью WinDirStat - мне этого хватает, мелкий мусор не волнует.
>>03662 (Del)
Я проверял, у меня был единственный дамп 3.4.4. Возможно, были и другие, я периодически произвожу очистку диска системной утилитой, которая, по идее, чистит все дампы самостоятельно.
Откуда столько? Я знаю, что после переименования проекта Godot считает его новым проектом, но 500 - это слишком.
>>03667
С каких пор у тебя пароли и данные банковских карт в куках? В куках должны быть только токены сессий, которые у любого нормального банка дольше 15 минут не бывают валидны. Окей, токен форума может быть валиден целый год (если нажмёшь "запомнить"), но, во-первых, кому ты нужен взламывать тебя на каком-то полудохлом форуме, а, во-вторых, помимо токена хорошо спроектированный сайт должен проверять соответствие браузера и геолокации по IP, делая токен невалидным при любых подозрениях на перемещение куки куда не следует.
Раньше так и было. Теперь - только с правами администратора, которые программа должна при каждом запуске запрашивать. Проблема тут в том, что если разрешить свободную запись в папку установленной программы, любой вирус может встроить свой исполняемый код в код программы. А создавать на каждую программу отдельного пользователя и назначать этому пользователю права только на одну папку, наверное, слишком затратно, и не спасает от вирусов, внедряющихся прямо в оперативной памяти. Т.е. основная цель разделения кода и данных в том, чтобы предотвратить укоренение вирусов в системе, а не кражу каких-то там паролей. Если вспомнить историю, от утечек паролей и других данных пострадали единицы, а вот от распространения вирусов весь интернет почти умирал несколько раз, принося огромные убытки компаниям, компьютеры которых массово превращались в тыкву.
Конечно, это всё хорошо только на словах - на практике я замечал множество программ, которые устанавливаются в папку с данными или кидают туда какие-то дополнительные исполняемые файлы. Говнодизайн от говнокодеров этих программ, что поделать, нужно просто избегать таких порождений.
Была какая-то программа, которая позволяла вычислить и вычистить все остаточные следы от ранее установленных программ - как из файловой системы, так и из реестра. Для большей эффективности предлагалось запускать установщик программы через неё, чтобы она запоминала, куда он насрал (с играми через стим, очевидно, так не получится). Я когда-то пользовался крякнутой версией, пока она не сломалась, а потом забил и чищу вручную с помощью WinDirStat - мне этого хватает, мелкий мусор не волнует.
>дампы появились только от последней версии
Я проверял, у меня был единственный дамп 3.4.4. Возможно, были и другие, я периодически произвожу очистку диска системной утилитой, которая, по идее, чистит все дампы самостоятельно.
>открытых проектов (у меня за 500 перевалило)
Откуда столько? Я знаю, что после переименования проекта Godot считает его новым проектом, но 500 - это слишком.
>>03667
>вспоминаем как вирусы воруют пароли и данные банковских карт с помощью такой вот папочки от браузера в Roaming, где хранятся все куки и кеши.
С каких пор у тебя пароли и данные банковских карт в куках? В куках должны быть только токены сессий, которые у любого нормального банка дольше 15 минут не бывают валидны. Окей, токен форума может быть валиден целый год (если нажмёшь "запомнить"), но, во-первых, кому ты нужен взламывать тебя на каком-то полудохлом форуме, а, во-вторых, помимо токена хорошо спроектированный сайт должен проверять соответствие браузера и геолокации по IP, делая токен невалидным при любых подозрениях на перемещение куки куда не следует.
>что сразу мешало сделать чтобы каждая прога писала свое говно в свою папку и никуда больше?
Раньше так и было. Теперь - только с правами администратора, которые программа должна при каждом запуске запрашивать. Проблема тут в том, что если разрешить свободную запись в папку установленной программы, любой вирус может встроить свой исполняемый код в код программы. А создавать на каждую программу отдельного пользователя и назначать этому пользователю права только на одну папку, наверное, слишком затратно, и не спасает от вирусов, внедряющихся прямо в оперативной памяти. Т.е. основная цель разделения кода и данных в том, чтобы предотвратить укоренение вирусов в системе, а не кражу каких-то там паролей. Если вспомнить историю, от утечек паролей и других данных пострадали единицы, а вот от распространения вирусов весь интернет почти умирал несколько раз, принося огромные убытки компаниям, компьютеры которых массово превращались в тыкву.
Конечно, это всё хорошо только на словах - на практике я замечал множество программ, которые устанавливаются в папку с данными или кидают туда какие-то дополнительные исполняемые файлы. Говнодизайн от говнокодеров этих программ, что поделать, нужно просто избегать таких порождений.
>около 60 гб всякого мусора от прог и игр, которые давно уже удалил
Была какая-то программа, которая позволяла вычислить и вычистить все остаточные следы от ранее установленных программ - как из файловой системы, так и из реестра. Для большей эффективности предлагалось запускать установщик программы через неё, чтобы она запоминала, куда он насрал (с играми через стим, очевидно, так не получится). Я когда-то пользовался крякнутой версией, пока она не сломалась, а потом забил и чищу вручную с помощью WinDirStat - мне этого хватает, мелкий мусор не волнует.
>>03746 (Del)
И для личных проектов, и для "изучения".
Для изучения порой достаточно код на гитхабе открыть. Чего там изучать-то, вот это сюда, вон то сюда, ага, понятно, делаем всё наоборот, пишем велосипед и готово, работает.
А для личных проектов - это надо прям на каждую свою мысль проект создавать, иконку менять да так и забрасывать.
И для личных проектов, и для "изучения".
Для изучения порой достаточно код на гитхабе открыть. Чего там изучать-то, вот это сюда, вон то сюда, ага, понятно, делаем всё наоборот, пишем велосипед и готово, работает.
А для личных проектов - это надо прям на каждую свою мысль проект создавать, иконку менять да так и забрасывать.
>>03697
Бля, я тоже так хочу сделать. Основное приложение и апдейтер лежат в рид-онли папке, в которую их положил установщик, но чтобы обновиться, апдейтер загружает новый файл основного приложения в рид-райт/-экзекьют/ директорию, выделенную ему системой. Основное приложение при запуске проверяет, есть ли более свежие версии в указанной папке, заупскает свежую версию и закрывает себя.
Походу я говнокодер. Научите делать правильно!
> множество программ, которые устанавливаются в папку с данными или кидают туда какие-то дополнительные исполняемые файлы. Говнодизайн от говнокодеров
Бля, я тоже так хочу сделать. Основное приложение и апдейтер лежат в рид-онли папке, в которую их положил установщик, но чтобы обновиться, апдейтер загружает новый файл основного приложения в рид-райт/-экзекьют/ директорию, выделенную ему системой. Основное приложение при запуске проверяет, есть ли более свежие версии в указанной папке, заупскает свежую версию и закрывает себя.
Походу я говнокодер. Научите делать правильно!
>>03782 (Del)
Я читал. Всё понял. Мне норм. me_gusta.jpg
А, вон оно что, ты киберспортсмен, тогда вопросов нет.
>>03819
Твой апдейтер должен запрашивать права администратора на время обновления и потом отдавать их обратно. Если пользователь отказался давать права, изменений файлов быть не должно.
Косяк твоего подхода в том, что пока исполняемые файлы лежат в общедоступной папке, вирус может изменить их, встроив себя вовнутрь, и ты даже не узнаешь об этом (теоретически можно встроить вирус, сохранив хэш-сумму без изменений). А если твоя программа каждый раз при запуске проверяет наличие апдейта в какой-то папке - вирус может нагло скинуть в эту папку версию с самим собой, и твоя программа послушно "обновится" на эту гадость. Обновленная версия может подключаться к серверу хакера, а не к твоему серверу, и ты, фактически, теряешь контроль над ситуацией, но пользователь по-прежнему думает, что ответственность за все действия программы на тебе, а не на хакере.
Короче, не оставляй свои exe/dll где попало и не копируй exe/dll из ненадёжного источника, даже если хэш-сумма совпадает.
Один нюанс - желательно избежать ложнопозитивного срабатывания популярных антивирусов, их многие обычные действия могут возбудить, кидай свои файлы на вирустотал и в случае чего пиши производителям антивирусов, если не можешь сделать так, чтобы твоя программа не вызывала срабатывание. А то получится, что твой лаунчер заживо съедается антивирусом, а ты ничего сделать не можешь и просишь "временно отключить антивирус".
>нет, читать tscn на гитхабе никто не будет
Я читал. Всё понял. Мне норм. me_gusta.jpg
>законченные игры с джемов
А, вон оно что, ты киберспортсмен, тогда вопросов нет.
>>03819
>апдейтер загружает новый файл основного приложения в рид-райт/-экзекьют/ директорию,
>заупскает свежую версию и закрывает себя.
>Научите делать правильно!
Твой апдейтер должен запрашивать права администратора на время обновления и потом отдавать их обратно. Если пользователь отказался давать права, изменений файлов быть не должно.
Косяк твоего подхода в том, что пока исполняемые файлы лежат в общедоступной папке, вирус может изменить их, встроив себя вовнутрь, и ты даже не узнаешь об этом (теоретически можно встроить вирус, сохранив хэш-сумму без изменений). А если твоя программа каждый раз при запуске проверяет наличие апдейта в какой-то папке - вирус может нагло скинуть в эту папку версию с самим собой, и твоя программа послушно "обновится" на эту гадость. Обновленная версия может подключаться к серверу хакера, а не к твоему серверу, и ты, фактически, теряешь контроль над ситуацией, но пользователь по-прежнему думает, что ответственность за все действия программы на тебе, а не на хакере.
Короче, не оставляй свои exe/dll где попало и не копируй exe/dll из ненадёжного источника, даже если хэш-сумма совпадает.
Один нюанс - желательно избежать ложнопозитивного срабатывания популярных антивирусов, их многие обычные действия могут возбудить, кидай свои файлы на вирустотал и в случае чего пиши производителям антивирусов, если не можешь сделать так, чтобы твоя программа не вызывала срабатывание. А то получится, что твой лаунчер заживо съедается антивирусом, а ты ничего сделать не можешь и просишь "временно отключить антивирус".
![Screenshot2022-05-30-16-47-28-991com.yourstoryinteractive.s[...].jpg](https://2ch.life//gd/src/800308/16539187434460.jpg)
1,2 Мб, 1080x2340Анончики, подскажите насколько сложно сделать игру типа Romance Club? Допустим есть сценарий с 3-4 основными ветками и иллюстрации (без моушена) -- какой бюджет на такую игру и где (и кого) искать в команду разрабов?
>>04005
За каникулы сделать не успеешь.
За каникулы сделать не успеешь.
>>04005
Основная сложность таких игр в рисовании арта. Поскольку арт у тебя есть, остальная игра делается за пару недель (тво викс гаме не просто так существует).
Вся программная часть визуальных новелл описывается простейшим алгоритмом:
1. Загрузить сценарий (типизированные данные из файла).
2. Загрузить сохранённое состояние (если есть).
3. Перейти к текущей позиции сценария (позиция - это объект с полями).
4. Взять из позиции названия пикч бэкграунда, действующих персонажей.
5. Взять из позиции список ответов игрока (список может быть пустым).
6. Взять из позиции текст вопроса игры (даже если это не вопрос а текст, весь текст рассматривается как вопрос).
7. Если выбранный ответ игрока предоставляет переход на новую позицию, установить её и перейти к п.3.
8. Если текущая позиция предоставляет переход на новую позицию, установить её и перейти к п.3.
9. Иначе, сценарий завершён, конец игры, перейти в главное меню.
> Допустим есть сценарий с 3-4 основными ветками и иллюстрации (без моушена)
> насколько сложно сделать игру типа Romance Club?
Основная сложность таких игр в рисовании арта. Поскольку арт у тебя есть, остальная игра делается за пару недель (тво викс гаме не просто так существует).
Вся программная часть визуальных новелл описывается простейшим алгоритмом:
1. Загрузить сценарий (типизированные данные из файла).
2. Загрузить сохранённое состояние (если есть).
3. Перейти к текущей позиции сценария (позиция - это объект с полями).
4. Взять из позиции названия пикч бэкграунда, действующих персонажей.
5. Взять из позиции список ответов игрока (список может быть пустым).
6. Взять из позиции текст вопроса игры (даже если это не вопрос а текст, весь текст рассматривается как вопрос).
7. Если выбранный ответ игрока предоставляет переход на новую позицию, установить её и перейти к п.3.
8. Если текущая позиция предоставляет переход на новую позицию, установить её и перейти к п.3.
9. Иначе, сценарий завершён, конец игры, перейти в главное меню.
>>03986 (Del)
А что такого? Аффтар хочет точно знать, насколько популярен его аддон. Понятное желание. Автообновления аддонов нет, т.е. записать что-то без твоего спроса автор не может. Если тебе данная фича не нравится - выпиливаешь её спокойно ручками, т.к. исходники открыты и написаны в любимом GDScript. Причин возмущаться не вижу.
А что такого? Аффтар хочет точно знать, насколько популярен его аддон. Понятное желание. Автообновления аддонов нет, т.е. записать что-то без твоего спроса автор не может. Если тебе данная фича не нравится - выпиливаешь её спокойно ручками, т.к. исходники открыты и написаны в любимом GDScript. Причин возмущаться не вижу.
>>04005
Несложно, если есть художники и много бабла.
Достаточно, чтобы прокормить жадных художников.
Художников. Желательно двух: один на фоны, другой на персонажи. Художники должны быть на коротком поводке и не пытаться улизнуть до завершения проекта, поскольку найти художника, способного попасть в стиль, очень сложно или очень дорого, а выпадающий из общего стиля арт вызывает неприятные эмоции у игрока. Два художника нужны потому, что проработка фонов сильно отличается от проработки персонажей и навыки нужны разные, а стиль может спокойно различаться, поэтому иметь на это разных художников не только возможно, но и выгодно - будут быстрее работать, одного можно будет отпустить на свободу раньше (скорее всего того, что по фонам).
>>04064
С чего ты взял? Мало кто будет рисовать арт для будущей игры, ничего не зная о разработке игр как таковой.
>сделать игру типа Romance Club?
Несложно, если есть художники и много бабла.
>какой бюджет на такую игру
Достаточно, чтобы прокормить жадных художников.
>искать в команду разрабов?
Художников. Желательно двух: один на фоны, другой на персонажи. Художники должны быть на коротком поводке и не пытаться улизнуть до завершения проекта, поскольку найти художника, способного попасть в стиль, очень сложно или очень дорого, а выпадающий из общего стиля арт вызывает неприятные эмоции у игрока. Два художника нужны потому, что проработка фонов сильно отличается от проработки персонажей и навыки нужны разные, а стиль может спокойно различаться, поэтому иметь на это разных художников не только возможно, но и выгодно - будут быстрее работать, одного можно будет отпустить на свободу раньше (скорее всего того, что по фонам).
>>04064
>Поскольку арт у тебя есть
С чего ты взял? Мало кто будет рисовать арт для будущей игры, ничего не зная о разработке игр как таковой.
![Screenshot2022-05-30-16-47-28-991com.yourstoryinteractive.s[...].jpg](https://2ch.life//gd/src/800308/16540117038450.jpg)
1,2 Мб, 1080x2340>>04064
>>04092
Спасибо, анончики
Суть в том, что стиль арта будет другой, а я сам иллюстратор-макака с вышкой худ.обр работаю в рекламном дизайне и иногда для некоторых печатных изданий.
Недавно по настойчивой рекомендации подруги прошел в RC "Легенду Ивы" и понравилось. Я знаю сколько дроча рисовать в той стилистике и понимаю, что на иллюстрации одной истории в том стайлаке у меня уйдет минимум год ежедневной работы и нахуй мне такое счастье, если можно делать проще и быстрее в другом стиле
Я немного ахуел увидев количество фанатов этой игры и родилась идея запилить свою игру, собрал концепцию, набросал пару артов и прикинул что и как дальше рисовать. Сценарий есть примерно на 50% и надо разводить ветки дрочить финалы
Ананасам которые ответили по делу спасибо
К осени надеюсь начинать разработку приложухи, так что еще к вам зайду
>>04092
Спасибо, анончики
Суть в том, что стиль арта будет другой, а я сам иллюстратор-макака с вышкой худ.обр работаю в рекламном дизайне и иногда для некоторых печатных изданий.
Недавно по настойчивой рекомендации подруги прошел в RC "Легенду Ивы" и понравилось. Я знаю сколько дроча рисовать в той стилистике и понимаю, что на иллюстрации одной истории в том стайлаке у меня уйдет минимум год ежедневной работы и нахуй мне такое счастье, если можно делать проще и быстрее в другом стиле
Я немного ахуел увидев количество фанатов этой игры и родилась идея запилить свою игру, собрал концепцию, набросал пару артов и прикинул что и как дальше рисовать. Сценарий есть примерно на 50% и надо разводить ветки дрочить финалы
Ананасам которые ответили по делу спасибо
К осени надеюсь начинать разработку приложухи, так что еще к вам зайду
>>04093 (Del)
Пишешь в отдел К, при необходимости доводишь до суда. Алсо репортишь проект на гитхабе, везде сообщаешь о том, что автор мошенник и т.д. Конечно, ты пострадал и утраченного не вернуть. Но твой пример покажет другим, что делать так нехорошо и за это будут последствия. Как сейчас с тем пацаном, которому всю жизнь испортили за его борьбу через опенсурс проект, автором которого он был. Простят ли его когда-нибудь? Это же клеймо на всю жизнь. Можно было попытаться сделать всё анонимно, но анонимно ты никому не известен и поэтому не сможешь навредить сразу многим, первый же пострадавший напишет куда следует. Да и анонимность в интернете - дело сложное, всегда можно за что-нибудь зацепиться и найти тебя в реале, если ты кому-нибудь сильно навредишь.
Надо. Пиши. Я?!
Лучше сразу делать список "разрешений" как в Android, чтобы скрипты по умолчанию не имели доступа к камере, микрофону, редактированию имеющихся файлов проекта и т.д. Но это сложно и не так уж нужно, когда ты пишешь все скрипты сам или берёшь из интернета только небольшие плагины, просматривая их вручную. Короче, вряд ли кто-то возьмётся за реализацию в ближайшее время. Попробуй сделать сам, но сначала спроси, примут ли такую фичу)
>если какой то ассет без задней мысли сольет твои исходники, и вообще любую папку с компа
Пишешь в отдел К, при необходимости доводишь до суда. Алсо репортишь проект на гитхабе, везде сообщаешь о том, что автор мошенник и т.д. Конечно, ты пострадал и утраченного не вернуть. Но твой пример покажет другим, что делать так нехорошо и за это будут последствия. Как сейчас с тем пацаном, которому всю жизнь испортили за его борьбу через опенсурс проект, автором которого он был. Простят ли его когда-нибудь? Это же клеймо на всю жизнь. Можно было попытаться сделать всё анонимно, но анонимно ты никому не известен и поэтому не сможешь навредить сразу многим, первый же пострадавший напишет куда следует. Да и анонимность в интернете - дело сложное, всегда можно за что-нибудь зацепиться и найти тебя в реале, если ты кому-нибудь сильно навредишь.
>надо бы написать ишью в годот, чтобы подумали над дырой в безопастности.
Надо. Пиши. Я?!
>Может быть там, заблочить http запросы
Лучше сразу делать список "разрешений" как в Android, чтобы скрипты по умолчанию не имели доступа к камере, микрофону, редактированию имеющихся файлов проекта и т.д. Но это сложно и не так уж нужно, когда ты пишешь все скрипты сам или берёшь из интернета только небольшие плагины, просматривая их вручную. Короче, вряд ли кто-то возьмётся за реализацию в ближайшее время. Попробуй сделать сам, но сначала спроси, примут ли такую фичу)
>>04094
Главное, чтоб ЦА зашло. Ты знаешь свою ЦА?
Девочки-малолетки + накрученные за деньги боты + огромный бюджет на рекламу разных видов. Да, денег такие приложения приносят много (где-то тут постили статистику, там шестизначные суммы в долларах), но и вложений требуют огромных не только в графику, но и в раскрутку. А конкуренция огромная, и действующим игрокам новые конкуренты не нужны - показ рекламы зависит от количества вложенных средств за один показ, и у тебя, в отличие от них, нет такого огромного потока средств.
А у тебя есть своё сообщество/блог/комикс или что-то вроде этого с существенным числом подписчиков (100+ живых людей, ставящих лайки)? Если есть, это послужит хорошим стартом для игры, пусть у тебя и не будет 10+ миллионов скачек, но не придётся вкладывать деньги для первых игроков/фанатов. Если нет, самое время завести страничку и что-нибудь публиковать, раскручивать эту страничку и набирать фанбазу. Можно оформить страничку как блог разработки будущей игры. Инди так намного проще раскрутиться, дешевле. Может спонтанно заработать сарафанное радио, если реальную годноту пилишь, а не очередную бездушную фигню. Некоторые инди таким образом поднялись практически без рекламы, но это, считай, крупно повезло.
>можно делать проще и быстрее в другом стиле
Главное, чтоб ЦА зашло. Ты знаешь свою ЦА?
>ахуел увидев количество фанатов этой игры
>родилась идея запилить свою игру
Девочки-малолетки + накрученные за деньги боты + огромный бюджет на рекламу разных видов. Да, денег такие приложения приносят много (где-то тут постили статистику, там шестизначные суммы в долларах), но и вложений требуют огромных не только в графику, но и в раскрутку. А конкуренция огромная, и действующим игрокам новые конкуренты не нужны - показ рекламы зависит от количества вложенных средств за один показ, и у тебя, в отличие от них, нет такого огромного потока средств.
>я сам иллюстратор-макака
А у тебя есть своё сообщество/блог/комикс или что-то вроде этого с существенным числом подписчиков (100+ живых людей, ставящих лайки)? Если есть, это послужит хорошим стартом для игры, пусть у тебя и не будет 10+ миллионов скачек, но не придётся вкладывать деньги для первых игроков/фанатов. Если нет, самое время завести страничку и что-нибудь публиковать, раскручивать эту страничку и набирать фанбазу. Можно оформить страничку как блог разработки будущей игры. Инди так намного проще раскрутиться, дешевле. Может спонтанно заработать сарафанное радио, если реальную годноту пилишь, а не очередную бездушную фигню. Некоторые инди таким образом поднялись практически без рекламы, но это, считай, крупно повезло.
>>04114
К тому же способ добавления контента и вовсе ебать жеский. Там сценаристы на потоке строчат за копейки и в сжатые сроки для еженедельного контента. и их не 1-2 чела, а целые команды.
Даже где то всплыл подробности и срачи касательно условий сценаристов.
К тому же способ добавления контента и вовсе ебать жеский. Там сценаристы на потоке строчат за копейки и в сжатые сроки для еженедельного контента. и их не 1-2 чела, а целые команды.
Даже где то всплыл подробности и срачи касательно условий сценаристов.
>>04115
А можно и не добавлять. Ему же, вроде, только одна история понравилась, а не сама концепция "электронная библиотека визуальных новелл с регулярными обновлениями".
Хотя, конечно, без обновлений и прибыли большой не будет. Но в соло тащить обновления будет намного сложнее, даже если использовать старую графику, меняя только реплики/сюжет. А полноценным новым историям ведь и графика новая нужна, нет?
Зумеры изобрели литературных негров? Возмутительно! Никогда такого не было, и вот опять они за старое...
https://ru.wikipedia.org/wiki/Литературный_негр
>способ добавления контента
А можно и не добавлять. Ему же, вроде, только одна история понравилась, а не сама концепция "электронная библиотека визуальных новелл с регулярными обновлениями".
Хотя, конечно, без обновлений и прибыли большой не будет. Но в соло тащить обновления будет намного сложнее, даже если использовать старую графику, меняя только реплики/сюжет. А полноценным новым историям ведь и графика новая нужна, нет?
>срачи касательно условий сценаристов
Зумеры изобрели литературных негров? Возмутительно! Никогда такого не было, и вот опять они за старое...
https://ru.wikipedia.org/wiki/Литературный_негр
>>04114
В инсте у меня 750 живых подписчиков, по 100-170 лайков на мои редкие публикации, сторис почаще рощу, по 100-130 просмотров. Репостить будут минимум 20 человек. В основном там друзья и знакомый из различных творческих сфер
В вк 2700 друзей, из них много лично знакомых, но я там не пощу ничего почти так что с активностью хз че
Анончик, спасибо что обратил мое внимание на это, в голову пришли нужные человечки для выхода на более широкую аудиторию. Да и концепт работы приобретает очертания
В инсте у меня 750 живых подписчиков, по 100-170 лайков на мои редкие публикации, сторис почаще рощу, по 100-130 просмотров. Репостить будут минимум 20 человек. В основном там друзья и знакомый из различных творческих сфер
В вк 2700 друзей, из них много лично знакомых, но я там не пощу ничего почти так что с активностью хз че
Анончик, спасибо что обратил мое внимание на это, в голову пришли нужные человечки для выхода на более широкую аудиторию. Да и концепт работы приобретает очертания
Пупыпы. Нужен ли мне пупып (Popup), если мне достаточно вывести панель одного размера на весь экран строго по центру? Мне не нужно полноценное окошко, все кнопки я сделаю сам.
Просто увидел тут такое:
https://docs.godotengine.org/en/stable/tutorials/scripting/pausing_games.html
Меню паузы сделано на Popup. Почему? Зачем?
Разве не достаточно просто сделать Control.show()?
Алсо Popup в 4.0 будет по умолчанию в отдельном системном окне, так что, хм... Как бы, стандартное окошко Годо должно быть удобно для ММОРПГ-лайк инвентарей всяких и прочих "окон", а в 4.0 они все резко ПУПЫПНУТ в отдельные системные окна, и что из этого выйдет? Ничего хорошего.
Особенно учитывая что каждое системное окно = создание нового Vulkan контекста, из-за чего у меня альфа версия 4.0 лагает на каждое открытие всплывающего диалога: правая кнопка мыши, субменю главного меню, любые выпадающие списки, окно выбора цвета и т.д. Говно решение, если честно. Зачем было ломать то, что раньше нормально работало? Они же не планируют переходить на WinAPI, т.е. все второстепенные окна рисуются через OpenGL/Vulkan. И ладно бы окна скрывались пока не используются, но нет, они уничтожаются и создаются каждый раз, ну что за бред...
Впрочем, я тестировал только уже устаревшие альфа-версии.
И совсем не в тему вопрос: почему TabContainer глючит и не даёт нажать на нулевой таб? Выбесило, удалил весь контейнер и создал заново - глюк вроде бы пропал, но надолго ли? Алсо название таба через имя контрола - полный бред, имя контрола = ID годы, а не надпись. Я привык писать что-то вроде SomethingButton (без пробелов и с указанием типа, когда это нужно).
Просто увидел тут такое:
https://docs.godotengine.org/en/stable/tutorials/scripting/pausing_games.html
Меню паузы сделано на Popup. Почему? Зачем?
Разве не достаточно просто сделать Control.show()?
Алсо Popup в 4.0 будет по умолчанию в отдельном системном окне, так что, хм... Как бы, стандартное окошко Годо должно быть удобно для ММОРПГ-лайк инвентарей всяких и прочих "окон", а в 4.0 они все резко ПУПЫПНУТ в отдельные системные окна, и что из этого выйдет? Ничего хорошего.
Особенно учитывая что каждое системное окно = создание нового Vulkan контекста, из-за чего у меня альфа версия 4.0 лагает на каждое открытие всплывающего диалога: правая кнопка мыши, субменю главного меню, любые выпадающие списки, окно выбора цвета и т.д. Говно решение, если честно. Зачем было ломать то, что раньше нормально работало? Они же не планируют переходить на WinAPI, т.е. все второстепенные окна рисуются через OpenGL/Vulkan. И ладно бы окна скрывались пока не используются, но нет, они уничтожаются и создаются каждый раз, ну что за бред...
Впрочем, я тестировал только уже устаревшие альфа-версии.
И совсем не в тему вопрос: почему TabContainer глючит и не даёт нажать на нулевой таб? Выбесило, удалил весь контейнер и создал заново - глюк вроде бы пропал, но надолго ли? Алсо название таба через имя контрола - полный бред, имя контрола = ID годы, а не надпись. Я привык писать что-то вроде SomethingButton (без пробелов и с указанием типа, когда это нужно).
Обнаружил какой-то баг.
Беру свой старый код, пытаюсь переделать.
Ошибка:
Ошибка указывают на какую-то строку в коде, но эта строка плавает туда-сюда, иногда может указывать на строчку с комментарием - я долго пытался выяснить причину такого поведения, в результате кучу строк закомментировал и ошибка всё равно возникает. Такое ощущение, что проблема в интерпретаторе GDScript или где-то в другом месте движка, потому что раньше этот код работал в том же виде и сейчас просто нет никакой ошибки с моей стороны.
Пробовал на разных версиях, до 3.4 проект вообще не работает (сотни ошибок), а начиная с 3.4 и по 3.5 RC2 - эта дурацкая ошибка. При этом последний раз этот код работал примерно в конце января этого года, значит, версия была 3.4.2. До этого тоже всё исправно работало, такую ошибку никогда не встречал.
Пытаюсь загуглить - нигде нет именно такой ошибки. Чаще всего "invalid get index" у людей возникает на null, и ни у кого нет упоминания этого "exists". В моём коде тоже вызова exists нигде нет. Как будто это движок где-то внутри пытается сделать int.exists() или что-то вроде того, но почему срабатывает даже на комментарии?
Копипастил по отдельности переменные, вызовы функций - всё работает, но только до этого багнутого места в коде. Как если бы происходило уничтожение объекта в параллельном потоке, но я не создаю отдельных потоков из своего кода, код, по идее, должен выполняться в один поток.
Я в отчаянии уже. А ведь всё так хорошо начиналось сегодня...
Беру свой старый код, пытаюсь переделать.
Ошибка:
>Invalid get index 'exists' (on base: 'int').
Ошибка указывают на какую-то строку в коде, но эта строка плавает туда-сюда, иногда может указывать на строчку с комментарием - я долго пытался выяснить причину такого поведения, в результате кучу строк закомментировал и ошибка всё равно возникает. Такое ощущение, что проблема в интерпретаторе GDScript или где-то в другом месте движка, потому что раньше этот код работал в том же виде и сейчас просто нет никакой ошибки с моей стороны.
Пробовал на разных версиях, до 3.4 проект вообще не работает (сотни ошибок), а начиная с 3.4 и по 3.5 RC2 - эта дурацкая ошибка. При этом последний раз этот код работал примерно в конце января этого года, значит, версия была 3.4.2. До этого тоже всё исправно работало, такую ошибку никогда не встречал.
Пытаюсь загуглить - нигде нет именно такой ошибки. Чаще всего "invalid get index" у людей возникает на null, и ни у кого нет упоминания этого "exists". В моём коде тоже вызова exists нигде нет. Как будто это движок где-то внутри пытается сделать int.exists() или что-то вроде того, но почему срабатывает даже на комментарии?
Копипастил по отдельности переменные, вызовы функций - всё работает, но только до этого багнутого места в коде. Как если бы происходило уничтожение объекта в параллельном потоке, но я не создаю отдельных потоков из своего кода, код, по идее, должен выполняться в один поток.
Я в отчаянии уже. А ведь всё так хорошо начиналось сегодня...
>>04186
Аааа, отбой тревоги, я тупанул, моя ошибка, у меня там в самом конце скрипта устаревшее (на несколько месяцев, однако) обращение к ключу .exists было, я в какой-то момент решил отказаться от флага в пользу ссылки, если ссылка = -1, то сущность не существует, вот. Т.е. скрипт получал int и пытался найти в нём ключ exists, интерпретор верно сказал. Но почему он меня в середину скрипта отсылал? Да, там у меня большой match, но по всей логике должно было отсылать на последнюю строчку кода, где у меня и происходит эта неправильная операция. В итоге убил пару часов на поиск ошибки там, где никакой ошибки не было. Нашёл причину ошибки только когда весь код от места ошибки до конца скрипта закомментировал и по частям раскомментировал - так и обнаружил, что ошибка на самой последней строчке, а не в середине.
>В моём коде тоже вызова exists нигде нет.
Аааа, отбой тревоги, я тупанул, моя ошибка, у меня там в самом конце скрипта устаревшее (на несколько месяцев, однако) обращение к ключу .exists было, я в какой-то момент решил отказаться от флага в пользу ссылки, если ссылка = -1, то сущность не существует, вот. Т.е. скрипт получал int и пытался найти в нём ключ exists, интерпретор верно сказал. Но почему он меня в середину скрипта отсылал? Да, там у меня большой match, но по всей логике должно было отсылать на последнюю строчку кода, где у меня и происходит эта неправильная операция. В итоге убил пару часов на поиск ошибки там, где никакой ошибки не было. Нашёл причину ошибки только когда весь код от места ошибки до конца скрипта закомментировал и по частям раскомментировал - так и обнаружил, что ошибка на самой последней строчке, а не в середине.
>>04255 (Del)
300 закинул, здоровья Мише
300 закинул, здоровья Мише
>>04255 (Del)
А вообще, поговори в ветеринарке, пусть тебе оставшийся рубас займут под какой-нибудь залог до зп
А вообще, поговори в ветеринарке, пусть тебе оставшийся рубас займут под какой-нибудь залог до зп
>>04255 (Del)
У мамки денег попросить не можешь?
У мамки денег попросить не можешь?
>>04277
Блядь, это спамер, он уже несколько месяцев эту хуйню по всем доскам постит.
Блядь, это спамер, он уже несколько месяцев эту хуйню по всем доскам постит.
Ононче, крик души. Из-за чего могут быть вот эти белые блики ? И как реализовать смену освещения.
Задача сделать смену дня и ночи. Реализовано все на итаксойдет. Есть процедурно генерируемое небо, его цвет задается с градиента, а ambiant_light выкручен в ноль. Освещается все направленным светом, который крутится вокруг хуя своей оси. Для травы и деревьев спизжен у индуса с ютуба шейдер пик3. Тоесть трабла либо в освещении либо в шейдере. Ни в одном ни в другом я ничего не понимаю. Каким богам продавать анальную девственность что бы это пофиксить ?
Задача сделать смену дня и ночи. Реализовано все на итаксойдет. Есть процедурно генерируемое небо, его цвет задается с градиента, а ambiant_light выкручен в ноль. Освещается все направленным светом, который крутится вокруг хуя своей оси. Для травы и деревьев спизжен у индуса с ютуба шейдер пик3. Тоесть трабла либо в освещении либо в шейдере. Ни в одном ни в другом я ничего не понимаю. Каким богам продавать анальную девственность что бы это пофиксить ?
Ононче, крик души. Из-за чего могут быть вот эти белые блики ? И как реализовать смену освещения.
Задача сделать смену дня и ночи. Реализовано все на итаксойдет. Есть процедурно генерируемое небо, его цвет задается с градиента, а ambiant_light выкручен в ноль. Освещается все направленным светом, который крутится вокруг хуя своей оси. Для травы и деревьев спизжен у индуса с ютуба шейдер пик3. Тоесть трабла либо в освещении либо в шейдере. Ни в одном ни в другом я ничего не понимаю. Каким богам продавать анальную девственность что бы это пофиксить ?
Задача сделать смену дня и ночи. Реализовано все на итаксойдет. Есть процедурно генерируемое небо, его цвет задается с градиента, а ambiant_light выкручен в ноль. Освещается все направленным светом, который крутится вокруг хуя своей оси. Для травы и деревьев спизжен у индуса с ютуба шейдер пик3. Тоесть трабла либо в освещении либо в шейдере. Ни в одном ни в другом я ничего не понимаю. Каким богам продавать анальную девственность что бы это пофиксить ?
196 Кб, 1600x1800>>02763
Новые меню.
Когда я прошлый раз делал меню, я сделал меню паузы как вариант главного меню, потому что это было проще. Но когда я собрался делать меню настроек, я вспомнил, что давно когда-то хотел сделать меню паузы а-ля ГТА с вкладками. В общем, вчера доделал прототип меню паузы/настроек. С главного экрана открывается оно же, только неактуальные вкладки скрыты из кода - не придумал более удобного способа, пусть будет так.
От мини-карты окончательно решил отказаться, потому что игровой мир предполагается не очень большим, а планировка улиц всё равно квадратно-гнездовая, так что заблудиться будет сложно, а мини-карта будет зря занимать место на экране. Зато в меню паузы на первой же вкладке открывается полная карта всего мира (потом на ней будут маркеры, можно будет приближать и прокручивать).
Что хочу сказать, система GUI в Godot хорошая, но многие функции неочевидны или недостаточно хорошо продуманы, а также она местами ограничена. Навелосипедить-то можно что угодно, но из коробки возможности ограничены, хотя для большинства игр имеющегося более чем достаточно. В любом случае, для низкобюджетного опенсурса это круто.
Новые меню.
Когда я прошлый раз делал меню, я сделал меню паузы как вариант главного меню, потому что это было проще. Но когда я собрался делать меню настроек, я вспомнил, что давно когда-то хотел сделать меню паузы а-ля ГТА с вкладками. В общем, вчера доделал прототип меню паузы/настроек. С главного экрана открывается оно же, только неактуальные вкладки скрыты из кода - не придумал более удобного способа, пусть будет так.
От мини-карты окончательно решил отказаться, потому что игровой мир предполагается не очень большим, а планировка улиц всё равно квадратно-гнездовая, так что заблудиться будет сложно, а мини-карта будет зря занимать место на экране. Зато в меню паузы на первой же вкладке открывается полная карта всего мира (потом на ней будут маркеры, можно будет приближать и прокручивать).
Что хочу сказать, система GUI в Godot хорошая, но многие функции неочевидны или недостаточно хорошо продуманы, а также она местами ограничена. Навелосипедить-то можно что угодно, но из коробки возможности ограничены, хотя для большинства игр имеющегося более чем достаточно. В любом случае, для низкобюджетного опенсурса это круто.
>>04297
Из-за того, что у тебя "солнце" находится глубоко под землёй и светит из-под земли вверх, в небо. Как только солнце опускается под горизонт - выключай его, и включай только в процессе восхода над горизонтом. Во-первых, это снижает нагрузку ночью, потому что движку не приходится рендерить лишний свет/тени. Во-вторых, это избавляет от багов освещения, которые неизбежно возникают, когда ты светишь на ландшафт снизу/изнутри. Переключение солнца может вызвать едва заметный лаг, но в 3.5 добавили кэширование шейдеров и теперь его либо нет совсем, либо он всего один раз при первом запуске игры, так что ничего страшного.
Используешь встроенное? Производительность не смущает? Мне пришлось отказаться от встроенного процедурного неба из-за его очень низкой производительности, терпеть такие лаги каждое обновление невозможно. Пока что заменил его огромной сферой с текстурой, которой меняю оттенок через материал .albedo_color, это оказалось практически бесплатно по производительности, но что-то красивое сделать сложно. Наверное, нужно будет изучать шейдеры...
А у тебя серьёзный опенворлд или ты на конкурс делаешь?
>белые блики
Из-за того, что у тебя "солнце" находится глубоко под землёй и светит из-под земли вверх, в небо. Как только солнце опускается под горизонт - выключай его, и включай только в процессе восхода над горизонтом. Во-первых, это снижает нагрузку ночью, потому что движку не приходится рендерить лишний свет/тени. Во-вторых, это избавляет от багов освещения, которые неизбежно возникают, когда ты светишь на ландшафт снизу/изнутри. Переключение солнца может вызвать едва заметный лаг, но в 3.5 добавили кэширование шейдеров и теперь его либо нет совсем, либо он всего один раз при первом запуске игры, так что ничего страшного.
>процедурно генерируемое небо
Используешь встроенное? Производительность не смущает? Мне пришлось отказаться от встроенного процедурного неба из-за его очень низкой производительности, терпеть такие лаги каждое обновление невозможно. Пока что заменил его огромной сферой с текстурой, которой меняю оттенок через материал .albedo_color, это оказалось практически бесплатно по производительности, но что-то красивое сделать сложно. Наверное, нужно будет изучать шейдеры...
А у тебя серьёзный опенворлд или ты на конкурс делаешь?
4 Кб, 667x38>>04297
>>04316
Посмотрел код своей системы освещения и даже нашёл в ней соответствующий комментарий об этом баге/особенности. Источник света продолжает существовать и вращаться под картой, но поскольку visible == false, он никак не влияет на сцену.
По-моему, днём, в сумерках и при лунном свете он не должен быть нулевым. Какое-то рассеянное освещение всегда присутствует. Тем более что в 100% темноте играть неприятно, становится невозможно ориентироваться в пространстве.
А я даже не знал про градиенты, изобретал свои формулы вычисления цвета... Правильно говорят, что сначала нужно документацию прочитать целиком, прежде чем что-то изобретать)
>>04316
Посмотрел код своей системы освещения и даже нашёл в ней соответствующий комментарий об этом баге/особенности. Источник света продолжает существовать и вращаться под картой, но поскольку visible == false, он никак не влияет на сцену.
>ambiant_light выкручен в ноль
По-моему, днём, в сумерках и при лунном свете он не должен быть нулевым. Какое-то рассеянное освещение всегда присутствует. Тем более что в 100% темноте играть неприятно, становится невозможно ориентироваться в пространстве.
>его цвет задается с градиента
А я даже не знал про градиенты, изобретал свои формулы вычисления цвета... Правильно говорят, что сначала нужно документацию прочитать целиком, прежде чем что-то изобретать)
>>04297
Ты меня натолкнул на мысль, как сделать красивые стилизованные восходы и закаты без использования шейдеров. Разобрался с использованием градиентов, кривых и текстур, получилось то что получилось. Работает быстро и на мой взгляд выглядит неплохо, нужно только цвета и смещения скорректировать. Проблема только в том, что динамически менять время восхода и заката не выйдет, но, если честно, я вообще не понимаю, от чего зависит время восхода и заката ИРЛ. Пробовал поворачивать небесную сферу набок, чтобы солнце двигалось не через зенит, а по краю - фигня какая-то получилось. Видимо, такая простая модель не достаточно точно моделирует реальное вращение/движение Земли вокруг Солнца. Зато замечательно моделирует плоскую землю, вокруг которой вращается весь остальной мир, включая небесную твердь.
Вкратце суть: я сделал градиентную текстуру, которая натянута на сферу, у градиента этой текстуры 2-3 точки (можно больше, тогда просто добавить строчки кода). Сфера вращается вместе с солнцем. Скрипт вычисляет время суток в процентах и изменяет цвет точек этого небесного градиента из двух других градиентов. В первом градиенте 3 цвета: тёмно-синий, оранжевый и голубой. Второй градиент - копия первого, но без оранжевого цвета и голубой чуть темнее. В результате получаем систему, которая делает оранжевый ореол вокруг солнца на восходах и закатах, полностью затемняет всё небо ночью и при этом не оставляет слишком тёмных мест днём. Можно настраивать на свой вкус.
Наверное, следующий шаг - это сделать процедурную генерацию всех градиентов, добавив в скрипт экспорт цветов. Тогда пользователю достаточно выбрать оттенки дневного неба, ночного неба, восхода и заката, а также время восхода и время заката, а всё остальное скрипт сгенерирует самостоятельно. Просто вручную эти градиенты редактировать оказалось не так-то просто, там нужно много разных точек с одинаковым цветом, и сложно мышкой подобрать правильное смещение (знаю, там можно чистые данные менять, но всё равно это неудобно)...
>>04340 (Del)
Как источник света? Зачем? По-моему, лунные тени будут незаметны, это лишняя трата производительности. Хотя, попробовать можно. Но я говорил про ambient_light, это мягкий рассеянный "свет", он никак от источника не зависит и просто увеличивает минимальную яркость окружающих предметов, чтобы можно было их различить в темноте.
Не, если тебе нужна реалистичная симуляция света, то ambient_light вроде как не нужен. Он нужен как оптимизация.
>его цвет задается с градиента
Ты меня натолкнул на мысль, как сделать красивые стилизованные восходы и закаты без использования шейдеров. Разобрался с использованием градиентов, кривых и текстур, получилось то что получилось. Работает быстро и на мой взгляд выглядит неплохо, нужно только цвета и смещения скорректировать. Проблема только в том, что динамически менять время восхода и заката не выйдет, но, если честно, я вообще не понимаю, от чего зависит время восхода и заката ИРЛ. Пробовал поворачивать небесную сферу набок, чтобы солнце двигалось не через зенит, а по краю - фигня какая-то получилось. Видимо, такая простая модель не достаточно точно моделирует реальное вращение/движение Земли вокруг Солнца. Зато замечательно моделирует плоскую землю, вокруг которой вращается весь остальной мир, включая небесную твердь.
Вкратце суть: я сделал градиентную текстуру, которая натянута на сферу, у градиента этой текстуры 2-3 точки (можно больше, тогда просто добавить строчки кода). Сфера вращается вместе с солнцем. Скрипт вычисляет время суток в процентах и изменяет цвет точек этого небесного градиента из двух других градиентов. В первом градиенте 3 цвета: тёмно-синий, оранжевый и голубой. Второй градиент - копия первого, но без оранжевого цвета и голубой чуть темнее. В результате получаем систему, которая делает оранжевый ореол вокруг солнца на восходах и закатах, полностью затемняет всё небо ночью и при этом не оставляет слишком тёмных мест днём. Можно настраивать на свой вкус.
Наверное, следующий шаг - это сделать процедурную генерацию всех градиентов, добавив в скрипт экспорт цветов. Тогда пользователю достаточно выбрать оттенки дневного неба, ночного неба, восхода и заката, а также время восхода и время заката, а всё остальное скрипт сгенерирует самостоятельно. Просто вручную эти градиенты редактировать оказалось не так-то просто, там нужно много разных точек с одинаковым цветом, и сложно мышкой подобрать правильное смещение (знаю, там можно чистые данные менять, но всё равно это неудобно)...
>>04340 (Del)
>добавить луну
Как источник света? Зачем? По-моему, лунные тени будут незаметны, это лишняя трата производительности. Хотя, попробовать можно. Но я говорил про ambient_light, это мягкий рассеянный "свет", он никак от источника не зависит и просто увеличивает минимальную яркость окружающих предметов, чтобы можно было их различить в темноте.
Не, если тебе нужна реалистичная симуляция света, то ambient_light вроде как не нужен. Он нужен как оптимизация.
>>04297
Ты меня натолкнул на мысль, как сделать красивые стилизованные восходы и закаты без использования шейдеров. Разобрался с использованием градиентов, кривых и текстур, получилось то что получилось. Работает быстро и на мой взгляд выглядит неплохо, нужно только цвета и смещения скорректировать. Проблема только в том, что динамически менять время восхода и заката не выйдет, но, если честно, я вообще не понимаю, от чего зависит время восхода и заката ИРЛ. Пробовал поворачивать небесную сферу набок, чтобы солнце двигалось не через зенит, а по краю - фигня какая-то получилось. Видимо, такая простая модель не достаточно точно моделирует реальное вращение/движение Земли вокруг Солнца. Зато замечательно моделирует плоскую землю, вокруг которой вращается весь остальной мир, включая небесную твердь.
Вкратце суть: я сделал градиентную текстуру, которая натянута на сферу, у градиента этой текстуры 2-3 точки (можно больше, тогда просто добавить строчки кода). Сфера вращается вместе с солнцем. Скрипт вычисляет время суток в процентах и изменяет цвет точек этого небесного градиента из двух других градиентов. В первом градиенте 3 цвета: тёмно-синий, оранжевый и голубой. Второй градиент - копия первого, но без оранжевого цвета и голубой чуть темнее. В результате получаем систему, которая делает оранжевый ореол вокруг солнца на восходах и закатах, полностью затемняет всё небо ночью и при этом не оставляет слишком тёмных мест днём. Можно настраивать на свой вкус.
Наверное, следующий шаг - это сделать процедурную генерацию всех градиентов, добавив в скрипт экспорт цветов. Тогда пользователю достаточно выбрать оттенки дневного неба, ночного неба, восхода и заката, а также время восхода и время заката, а всё остальное скрипт сгенерирует самостоятельно. Просто вручную эти градиенты редактировать оказалось не так-то просто, там нужно много разных точек с одинаковым цветом, и сложно мышкой подобрать правильное смещение (знаю, там можно чистые данные менять, но всё равно это неудобно)...
>>04340 (Del)
Как источник света? Зачем? По-моему, лунные тени будут незаметны, это лишняя трата производительности. Хотя, попробовать можно. Но я говорил про ambient_light, это мягкий рассеянный "свет", он никак от источника не зависит и просто увеличивает минимальную яркость окружающих предметов, чтобы можно было их различить в темноте.
Не, если тебе нужна реалистичная симуляция света, то ambient_light вроде как не нужен. Он нужен как оптимизация.
>его цвет задается с градиента
Ты меня натолкнул на мысль, как сделать красивые стилизованные восходы и закаты без использования шейдеров. Разобрался с использованием градиентов, кривых и текстур, получилось то что получилось. Работает быстро и на мой взгляд выглядит неплохо, нужно только цвета и смещения скорректировать. Проблема только в том, что динамически менять время восхода и заката не выйдет, но, если честно, я вообще не понимаю, от чего зависит время восхода и заката ИРЛ. Пробовал поворачивать небесную сферу набок, чтобы солнце двигалось не через зенит, а по краю - фигня какая-то получилось. Видимо, такая простая модель не достаточно точно моделирует реальное вращение/движение Земли вокруг Солнца. Зато замечательно моделирует плоскую землю, вокруг которой вращается весь остальной мир, включая небесную твердь.
Вкратце суть: я сделал градиентную текстуру, которая натянута на сферу, у градиента этой текстуры 2-3 точки (можно больше, тогда просто добавить строчки кода). Сфера вращается вместе с солнцем. Скрипт вычисляет время суток в процентах и изменяет цвет точек этого небесного градиента из двух других градиентов. В первом градиенте 3 цвета: тёмно-синий, оранжевый и голубой. Второй градиент - копия первого, но без оранжевого цвета и голубой чуть темнее. В результате получаем систему, которая делает оранжевый ореол вокруг солнца на восходах и закатах, полностью затемняет всё небо ночью и при этом не оставляет слишком тёмных мест днём. Можно настраивать на свой вкус.
Наверное, следующий шаг - это сделать процедурную генерацию всех градиентов, добавив в скрипт экспорт цветов. Тогда пользователю достаточно выбрать оттенки дневного неба, ночного неба, восхода и заката, а также время восхода и время заката, а всё остальное скрипт сгенерирует самостоятельно. Просто вручную эти градиенты редактировать оказалось не так-то просто, там нужно много разных точек с одинаковым цветом, и сложно мышкой подобрать правильное смещение (знаю, там можно чистые данные менять, но всё равно это неудобно)...
>>04340 (Del)
>добавить луну
Как источник света? Зачем? По-моему, лунные тени будут незаметны, это лишняя трата производительности. Хотя, попробовать можно. Но я говорил про ambient_light, это мягкий рассеянный "свет", он никак от источника не зависит и просто увеличивает минимальную яркость окружающих предметов, чтобы можно было их различить в темноте.
Не, если тебе нужна реалистичная симуляция света, то ambient_light вроде как не нужен. Он нужен как оптимизация.
685 Кб, 1173x648>>04344
Красивое. Реально дельный совет
>>04316
Делаю свою игру с ограбление караванов. А вообще что то типо StardewValley только про варку самогона и сражения с НЛО нанятого жуликом председателем колхоза
>>04340 (Del)
Я кст это сча пилю. Лунный свет тени не отбрасывает и просто похож на блекло синий цвет. Я поэтому на палку с солнцем с другого конца луну повесил и вроде норм
А вообще выяснил что проблема в шейдерах. Параметр Specular не хочет меняться или вообще не работает.
А еще смотрите, домик намоделировал. А могу а хорош
Красивое. Реально дельный совет
>>04316
>>А у тебя серьёзный опенворлд или ты на конкурс делаешь?
Делаю свою игру с ограбление караванов. А вообще что то типо StardewValley только про варку самогона и сражения с НЛО нанятого жуликом председателем колхоза
>>04340 (Del)
>добавить луну
Я кст это сча пилю. Лунный свет тени не отбрасывает и просто похож на блекло синий цвет. Я поэтому на палку с солнцем с другого конца луну повесил и вроде норм
А вообще выяснил что проблема в шейдерах. Параметр Specular не хочет меняться или вообще не работает.
А еще смотрите, домик намоделировал. А могу а хорош
>>04135
Я с этого охуевал ещё в прошлом году. Хуану всего лишь надо было добавить класс окна, который содержит в себе отдельный контекст и вьюпорт-ноду, в которую мы смогли бы напихать что угодно.
Но нет, он решил поломать всё нахуй.
А самое идиотское - когда всплывают всплывающие подсказки, они всплывают в отдельном окне и предыдущее окно теряет фокус. Все, кто не научился слепой печати мгновенно sosnooley, потому что пока смотришь на клаву и набираешь с разгону несколько слов, потом смотришь на монитор, а там попап. А набранного текста нет.
> а в 4.0 они все резко ПУПЫПНУТ в отдельные системные окна, и что из этого выйдет? Ничего хорошего.
Я с этого охуевал ещё в прошлом году. Хуану всего лишь надо было добавить класс окна, который содержит в себе отдельный контекст и вьюпорт-ноду, в которую мы смогли бы напихать что угодно.
Но нет, он решил поломать всё нахуй.
А самое идиотское - когда всплывают всплывающие подсказки, они всплывают в отдельном окне и предыдущее окно теряет фокус. Все, кто не научился слепой печати мгновенно sosnooley, потому что пока смотришь на клаву и набираешь с разгону несколько слов, потом смотришь на монитор, а там попап. А набранного текста нет.
>>04298
Из-за эмбиент лайт, клир колор, и т.п. Всё нужно проверять самостоятельно.
Туториалы на ютубе глянуть. Я видел достаточно неплохие, но авторов уже не помню. Так что дальше сам.
> Из-за чего могут быть вот эти белые блики ?
Из-за эмбиент лайт, клир колор, и т.п. Всё нужно проверять самостоятельно.
> И как реализовать смену освещения.
> Задача сделать смену дня и ночи.
Туториалы на ютубе глянуть. Я видел достаточно неплохие, но авторов уже не помню. Так что дальше сам.
>>04311
1. Всё меню - синглтон.
2. Всё меню - имеет вкладки подменю.
3. Всё меню имеет кастомные сигналы/методы: показать вкладку(вкладка) и скрыть вкладку(вкладка).
4. Нужные ноды когда им нужно испускают нужный сигнал или дёргают метод синглового меню, если тебе так удобнее.
> не придумал более удобного способа, пусть будет так
1. Всё меню - синглтон.
2. Всё меню - имеет вкладки подменю.
3. Всё меню имеет кастомные сигналы/методы: показать вкладку(вкладка) и скрыть вкладку(вкладка).
4. Нужные ноды когда им нужно испускают нужный сигнал или дёргают метод синглового меню, если тебе так удобнее.
>>04405
Программирование без слепого ввода мучительно. Все, кто не пытается набирать текст вслепую, ставят себе палки в колёса по многим причинам. Не обязательно владеть десятипальцевым, достаточно печатать 2-4 пальцами, но вслепую, одно это даст большой прирост производительности.
Вообще, все эти попапы можно сделать встроенными в основное окно всего одной галочкой а настройках. Одной галочкой в настройках редактора и одной галочкой в настройках проекта)) После этого всё работает как раньше и новых окон не создаётся. Вопрос в том, нахрена вообще этот механизм нужен и почему его сделали включённым по умолчанию, если он мешает и куда оптимальнее работать без него. Опять же, если бы это были нативные окна с нативными компонентами, это можно было бы понять (как, например, выбор файла через системное окно Windows намного привычнее пользователям Windows, чем встроенный в Godot велосипед, который никогда не достигнет возможностей системного). Но это такое же окно с контекстом Vulkan, как и основное, т.е. никакой нативной интеграции с системой тут нет...
>Все, кто не научился слепой печати мгновенно sosnooley
Программирование без слепого ввода мучительно. Все, кто не пытается набирать текст вслепую, ставят себе палки в колёса по многим причинам. Не обязательно владеть десятипальцевым, достаточно печатать 2-4 пальцами, но вслепую, одно это даст большой прирост производительности.
>потому что пока смотришь на клаву и набираешь с разгону несколько слов, потом смотришь на монитор, а там попап
Вообще, все эти попапы можно сделать встроенными в основное окно всего одной галочкой а настройках. Одной галочкой в настройках редактора и одной галочкой в настройках проекта)) После этого всё работает как раньше и новых окон не создаётся. Вопрос в том, нахрена вообще этот механизм нужен и почему его сделали включённым по умолчанию, если он мешает и куда оптимальнее работать без него. Опять же, если бы это были нативные окна с нативными компонентами, это можно было бы понять (как, например, выбор файла через системное окно Windows намного привычнее пользователям Windows, чем встроенный в Godot велосипед, который никогда не достигнет возможностей системного). Но это такое же окно с контекстом Vulkan, как и основное, т.е. никакой нативной интеграции с системой тут нет...
>>04408
Обсуждали же, нельзя делать синглтоны без необходимости.
Ну вот у меня куча вкладок, приходится часть отключать. Или ты предлагаешь вообще все игровые меню в одну кучу свалить? Ну уж нет, я хочу, наоборот, по отдельности редактировать.
У меня всего два режима меню, поэтому я сделал один флаг и при отображении меню само определяет, каким ему быть и что делать. Это надёжнее, чем извне задавать ему способ отображения. Если понадобится добавить режимы... сделаю enum.
Это вообще никак к теме не относится.
Я подразумевал удобный способ отделить "настройки" от "меню паузы", но таким образом, чтобы в меню паузы были встроены те же самые настройки, что в главном меню. Т.е. была мысль сделать настройки в отдельном tscn, который загружается при запуске игры, а в начале новой игры он перестраивается в подгруженное меню паузы; когда игра выходит в главное меню, меню настроек отсоединяется от меню паузы и меню паузы уничтожается. Но, во-первых, это много лишней работы - написания кода и поиска ошибок, а, во-вторых, вряд ли это принесёт какую-либо пользу, т.к. реальной необходимости грузить паузу только после начала новой игры нет, она может существовать с самого старта игры. Поэтому я решил оставить всё в виде одной большой tscn с меню паузы, которое умеет маскироваться под меню настроек... Но чувствую, что должен был быть способ сделать удобнее, чтобы настройки были в отдельной сцене.
Эх... В большей степени меня беспоит будущее нагромождение нод в меню настроек, в частности там, где назначение клавиш. Думаю о том, что стоит эти ноды удалять из дерева сцены, пока меню закрыто, и добавлять при открытии меню/вкладки. Это может создать лаг на открытии, но зато общее число активных нод в сцене будет меньше, возможно, на сотню-другую. Ну, это потом как-нибудь, надо сначала основу игры сделать.
>Всё меню - синглтон
Обсуждали же, нельзя делать синглтоны без необходимости.
>Всё меню - имеет вкладки подменю
Ну вот у меня куча вкладок, приходится часть отключать. Или ты предлагаешь вообще все игровые меню в одну кучу свалить? Ну уж нет, я хочу, наоборот, по отдельности редактировать.
>Всё меню имеет кастомные сигналы/методы: показать вкладку(вкладка) и скрыть вкладку(вкладка).
У меня всего два режима меню, поэтому я сделал один флаг и при отображении меню само определяет, каким ему быть и что делать. Это надёжнее, чем извне задавать ему способ отображения. Если понадобится добавить режимы... сделаю enum.
>Нужные ноды когда им нужно испускают нужный сигнал или дёргают метод синглового меню, если тебе так удобнее
Это вообще никак к теме не относится.
>>не придумал более удобного способа
Я подразумевал удобный способ отделить "настройки" от "меню паузы", но таким образом, чтобы в меню паузы были встроены те же самые настройки, что в главном меню. Т.е. была мысль сделать настройки в отдельном tscn, который загружается при запуске игры, а в начале новой игры он перестраивается в подгруженное меню паузы; когда игра выходит в главное меню, меню настроек отсоединяется от меню паузы и меню паузы уничтожается. Но, во-первых, это много лишней работы - написания кода и поиска ошибок, а, во-вторых, вряд ли это принесёт какую-либо пользу, т.к. реальной необходимости грузить паузу только после начала новой игры нет, она может существовать с самого старта игры. Поэтому я решил оставить всё в виде одной большой tscn с меню паузы, которое умеет маскироваться под меню настроек... Но чувствую, что должен был быть способ сделать удобнее, чтобы настройки были в отдельной сцене.
Эх... В большей степени меня беспоит будущее нагромождение нод в меню настроек, в частности там, где назначение клавиш. Думаю о том, что стоит эти ноды удалять из дерева сцены, пока меню закрыто, и добавлять при открытии меню/вкладки. Это может создать лаг на открытии, но зато общее число активных нод в сцене будет меньше, возможно, на сотню-другую. Ну, это потом как-нибудь, надо сначала основу игры сделать.
>>04408
Обсуждали же, нельзя делать синглтоны без необходимости.
Ну вот у меня куча вкладок, приходится часть отключать. Или ты предлагаешь вообще все игровые меню в одну кучу свалить? Ну уж нет, я хочу, наоборот, по отдельности редактировать.
У меня всего два режима меню, поэтому я сделал один флаг и при отображении меню само определяет, каким ему быть и что делать. Это надёжнее, чем извне задавать ему способ отображения. Если понадобится добавить режимы... сделаю enum.
Это вообще никак к теме не относится.
Я подразумевал удобный способ отделить "настройки" от "меню паузы", но таким образом, чтобы в меню паузы были встроены те же самые настройки, что в главном меню. Т.е. была мысль сделать настройки в отдельном tscn, который загружается при запуске игры, а в начале новой игры он перестраивается в подгруженное меню паузы; когда игра выходит в главное меню, меню настроек отсоединяется от меню паузы и меню паузы уничтожается. Но, во-первых, это много лишней работы - написания кода и поиска ошибок, а, во-вторых, вряд ли это принесёт какую-либо пользу, т.к. реальной необходимости грузить паузу только после начала новой игры нет, она может существовать с самого старта игры. Поэтому я решил оставить всё в виде одной большой tscn с меню паузы, которое умеет маскироваться под меню настроек... Но чувствую, что должен был быть способ сделать удобнее, чтобы настройки были в отдельной сцене.
Эх... В большей степени меня беспоит будущее нагромождение нод в меню настроек, в частности там, где назначение клавиш. Думаю о том, что стоит эти ноды удалять из дерева сцены, пока меню закрыто, и добавлять при открытии меню/вкладки. Это может создать лаг на открытии, но зато общее число активных нод в сцене будет меньше, возможно, на сотню-другую. Ну, это потом как-нибудь, надо сначала основу игры сделать.
>Всё меню - синглтон
Обсуждали же, нельзя делать синглтоны без необходимости.
>Всё меню - имеет вкладки подменю
Ну вот у меня куча вкладок, приходится часть отключать. Или ты предлагаешь вообще все игровые меню в одну кучу свалить? Ну уж нет, я хочу, наоборот, по отдельности редактировать.
>Всё меню имеет кастомные сигналы/методы: показать вкладку(вкладка) и скрыть вкладку(вкладка).
У меня всего два режима меню, поэтому я сделал один флаг и при отображении меню само определяет, каким ему быть и что делать. Это надёжнее, чем извне задавать ему способ отображения. Если понадобится добавить режимы... сделаю enum.
>Нужные ноды когда им нужно испускают нужный сигнал или дёргают метод синглового меню, если тебе так удобнее
Это вообще никак к теме не относится.
>>не придумал более удобного способа
Я подразумевал удобный способ отделить "настройки" от "меню паузы", но таким образом, чтобы в меню паузы были встроены те же самые настройки, что в главном меню. Т.е. была мысль сделать настройки в отдельном tscn, который загружается при запуске игры, а в начале новой игры он перестраивается в подгруженное меню паузы; когда игра выходит в главное меню, меню настроек отсоединяется от меню паузы и меню паузы уничтожается. Но, во-первых, это много лишней работы - написания кода и поиска ошибок, а, во-вторых, вряд ли это принесёт какую-либо пользу, т.к. реальной необходимости грузить паузу только после начала новой игры нет, она может существовать с самого старта игры. Поэтому я решил оставить всё в виде одной большой tscn с меню паузы, которое умеет маскироваться под меню настроек... Но чувствую, что должен был быть способ сделать удобнее, чтобы настройки были в отдельной сцене.
Эх... В большей степени меня беспоит будущее нагромождение нод в меню настроек, в частности там, где назначение клавиш. Думаю о том, что стоит эти ноды удалять из дерева сцены, пока меню закрыто, и добавлять при открытии меню/вкладки. Это может создать лаг на открытии, но зато общее число активных нод в сцене будет меньше, возможно, на сотню-другую. Ну, это потом как-нибудь, надо сначала основу игры сделать.
Кто страдает на ноутбуке с тачпадом без средней кнопки мыши? Я тут решение нашёл для линукса, в манжаро это пакет xorg-xinput (не путать с форматом геймпадов). Устанавливаешь его и переназначаешь физическую правую кнопку на среднюю, а правая уже есть на клавиатуре.
Бриллиант!
Теперь можно вращать объекты по орбите в годотах, блендерах и т.д. без задней мысли, без СМС.
Бриллиант!
Теперь можно вращать объекты по орбите в годотах, блендерах и т.д. без задней мысли, без СМС.
>>04416
Разве постоянное существование интерфейса не является необходимостью? Разве не является необходимостью быстрый вызов любого элемента интерфейса в любой момент без подгрузок и
?
Ну не знаю. Синглтонов бояться - в геймдев не ходить.
К тому же помни, синглтон в годоте это не совсем синглтон в классическом программировании, а просто еще одна нода в дереве. Чтобы нам не приходилось писать:
Хуан сделал то же самое в виде удобного окна в настройках проекта.
> Обсуждали же, нельзя делать синглтоны без необходимости.
Разве постоянное существование интерфейса не является необходимостью? Разве не является необходимостью быстрый вызов любого элемента интерфейса в любой момент без подгрузок и
> много лишней работы - написания кода и поиска ошибок
?
Ну не знаю. Синглтонов бояться - в геймдев не ходить.
К тому же помни, синглтон в годоте это не совсем синглтон в классическом программировании, а просто еще одна нода в дереве. Чтобы нам не приходилось писать:
> var my_ever_existing_node_instance = preload("res://my_ever_existing_scene.tscn").instance()
> get_tree().root.add_child(my_ever_existing_node_instance)
Хуан сделал то же самое в виде удобного окна в настройках проекта.
>>04427
Спустя час работы в новом режиме обнаружился подводный камень: кнопка контекстного меню на клавиатуре не равна по функционалу правой клавише мышки, она вызывает контекстное меню не для элемента под курсором мышки, а для элемента, имеющего фокус, что может быть неудобно в ряде других приложений, например в браузере.
Печально. Придётся искать другие варианты.
"Просто купи себе нормальную мышку, нищебород"!
Спустя час работы в новом режиме обнаружился подводный камень: кнопка контекстного меню на клавиатуре не равна по функционалу правой клавише мышки, она вызывает контекстное меню не для элемента под курсором мышки, а для элемента, имеющего фокус, что может быть неудобно в ряде других приложений, например в браузере.
Печально. Придётся искать другие варианты.
"Просто купи себе нормальную мышку, нищебород"!
>>04429
Всё это доступно без механизма синглтонов Годо.
Вот именно, синглтон в Годо - это просто нода вне основного дерева, что накладывает свои ограничения, и имеющая собственное глобальное имя, что влечёт за собой неприятные последствия, как и любая глобальная сущность в целом. Т.е. недостатки классических ООП синглтонов + отсутствие преимуществ нод в дереве сцены, в обмен на сомнительные преимущества ООП синглтонов.
Просто добавь ноду в редакторе основной сцены. Мышкой. А "комнаты", если они у тебя вообще есть, меняй через код. Тебе в любом случае придётся иметь какой-то главный скрипт "game.gd", который будет каким-то образом регулировать состояние игры и используемые ноды. И намного удобнее видеть структуру проекта в главной сцене "game.tscn", чем прятать всё в окно синглтонов, а потом ловить ошибки в случае если что-то понадобилось поменять...
Я знаю, у дерева сцены есть метод для смены всей активной сцены на другую (change_scene). Но я считаю этот метод неприменимым для более-менее крупной игры. Для мелкой головоломки, где каждая головоломка в отдельном файле - ок. Для большой игры тебе нет необходимости менять всю сцену и при этом нужно больше контроля за разными нодами, их состояниями и взаимоотношениями.
Ничего удобного в нём нет по сравнению с деревом сцены.
>постоянное существование интерфейса
>быстрый вызов любого элемента
>без подгрузок
Всё это доступно без механизма синглтонов Годо.
>синглтон в годоте это не совсем синглтон
Вот именно, синглтон в Годо - это просто нода вне основного дерева, что накладывает свои ограничения, и имеющая собственное глобальное имя, что влечёт за собой неприятные последствия, как и любая глобальная сущность в целом. Т.е. недостатки классических ООП синглтонов + отсутствие преимуществ нод в дереве сцены, в обмен на сомнительные преимущества ООП синглтонов.
>Чтобы нам не приходилось писать
Просто добавь ноду в редакторе основной сцены. Мышкой. А "комнаты", если они у тебя вообще есть, меняй через код. Тебе в любом случае придётся иметь какой-то главный скрипт "game.gd", который будет каким-то образом регулировать состояние игры и используемые ноды. И намного удобнее видеть структуру проекта в главной сцене "game.tscn", чем прятать всё в окно синглтонов, а потом ловить ошибки в случае если что-то понадобилось поменять...
Я знаю, у дерева сцены есть метод для смены всей активной сцены на другую (change_scene). Но я считаю этот метод неприменимым для более-менее крупной игры. Для мелкой головоломки, где каждая головоломка в отдельном файле - ок. Для большой игры тебе нет необходимости менять всю сцену и при этом нужно больше контроля за разными нодами, их состояниями и взаимоотношениями.
>в виде удобного окна
Ничего удобного в нём нет по сравнению с деревом сцены.
>>04438
Просто правая кнопка мыши создаёт событие клика мыши, а клавиша меню только запрашивает меню. Это логично и удобно, когда ты не используешь мышь: кнопками со стрелками и табом переключаешь фокус, кнопкой меню вызываешь меню, очень удобно. К сожалению, в программах вроде Godot и Blender такая навигация недоступна из-за кривого велосипедного GUI, не учитывающего юзеров без мышки, поэтому в них приходится чаще использовать мышь. Но, например, в классических приложениях на WinAPI можно работать вообще без использования мыши и какой-либо эмуляции мыши, потому что GUI Windows изначально рассчитан на полную доступность без мыши.
>>04427
А у тебя там полноценная клавиатура с нумпадом или говно 60%-ое? Если ты счастливый обладатель нумпада, должен быть способ переключить его в режим эмуляции мыши (когда numlock выключен). В Windows это делается в системных настройках, на линуксе скорее всего потребуется сторонняя утилита. А у меня есть полноразмерная беспроводная клавиатура, у которой встроенный эмулятор мыши - позволяет управлять курсором с нумпада независимо от ОС, эмулируя все три кнопки и даже колёсико, очень удобно, когда лень мышку трогать, и не мешает стандартным системным режимам нумпада (цифры/стрелочки).
>она вызывает контекстное меню не для элемента под курсором мышки, а для элемента, имеющего фокус
Просто правая кнопка мыши создаёт событие клика мыши, а клавиша меню только запрашивает меню. Это логично и удобно, когда ты не используешь мышь: кнопками со стрелками и табом переключаешь фокус, кнопкой меню вызываешь меню, очень удобно. К сожалению, в программах вроде Godot и Blender такая навигация недоступна из-за кривого велосипедного GUI, не учитывающего юзеров без мышки, поэтому в них приходится чаще использовать мышь. Но, например, в классических приложениях на WinAPI можно работать вообще без использования мыши и какой-либо эмуляции мыши, потому что GUI Windows изначально рассчитан на полную доступность без мыши.
>>04427
>на ноутбуке
А у тебя там полноценная клавиатура с нумпадом или говно 60%-ое? Если ты счастливый обладатель нумпада, должен быть способ переключить его в режим эмуляции мыши (когда numlock выключен). В Windows это делается в системных настройках, на линуксе скорее всего потребуется сторонняя утилита. А у меня есть полноразмерная беспроводная клавиатура, у которой встроенный эмулятор мыши - позволяет управлять курсором с нумпада независимо от ОС, эмулируя все три кнопки и даже колёсико, очень удобно, когда лень мышку трогать, и не мешает стандартным системным режимам нумпада (цифры/стрелочки).
>>04488
Пример в студию.
Отключается одной галочкой в окне автозагрузок.
Проектируй SOLIDно, чтоб не пришлось ловить ошибки, если понадобилось что-то поменять.
Тут согласен. За исключением того факта, что крупную игру в соло может вытащить только шиз (не как что-то плохое) за счёт шизофренической продуктивности. Психически здоровый человек выгорит на второй неделе пиления "скайрима в одно рыло".
Вкусовщина. Один список и две кнопки. Открыл, добавил, закрыл. Всё.
> Всё это доступно без механизма синглтонов Годо.
Пример в студию.
> имеющая собственное глобальное имя, что влечёт за собой неприятные последствия
Отключается одной галочкой в окне автозагрузок.
> ловить ошибки в случае если что-то понадобилось поменять
Проектируй SOLIDно, чтоб не пришлось ловить ошибки, если понадобилось что-то поменять.
> Для большой игры тебе нет необходимости менять всю сцену и при этом нужно больше контроля за разными нодами, их состояниями и взаимоотношениями.
Тут согласен. За исключением того факта, что крупную игру в соло может вытащить только шиз (не как что-то плохое) за счёт шизофренической продуктивности. Психически здоровый человек выгорит на второй неделе пиления "скайрима в одно рыло".
> Ничего удобного в нём нет по сравнению с деревом сцены.
Вкусовщина. Один список и две кнопки. Открыл, добавил, закрыл. Всё.
30 Кб, 519x481>>04511
Пикрил - только прототип, но до него всё было намного хуже (на синглтонах). Предстоит ещё многое (до)переделать, и я не хочу лазить туда-сюда по куче меню Godot в тщетных попытках запустить проект без ошибок. Блин, решил по-быстрому сменить тему и получился какой-то кислотный цвет...
Как тогда обращаться к такому скрипту? Через get_node()? По-моему, в официальной документации рекомендуют не делать запросов вверх по иерархии дерева через get_node().
Я делаю проект как хобби и хочу получать удовольствие, а не бороться с легаси, копящимся после каждого моего эксперимента, ведь по солиду я не могу его изменить - только расширить или заменить на потомка. Сейчас я просто беру устаревшие скрипты и выкидываю их в отдельную папку, а оставшиеся скрипты редактирую так, чтобы они от них больше не зависели. Сигналы в этом помогают, потому что сигнал не обязательно обрабатывать. Синглтоны - мешают, потому что обращение к отсутствующему или неправильному синглтону вызывает ошибку.
Это всё субъективно. Во-первых, основные затраты ААА - это графика, озвучка и пиар. Если тебе не нужна графика, озвучка и раскрутка, ты можешь сделать большую игру. Просто в неё играть почти никто не будет, но это уже другой разговор, может и повезти. Во-вторых, если ты не для заработка игру делаешь, а просто как хобби, ты даже не заметишь, как пролетят годы. Это только желающие по-быстрому срубить бабла разочаровываются, что игры делать намного сложнее, чем в них играть.
Нет древовидности, связывания сигналов через инспектор, нужно делать несколько кликов, чтобы добраться до этого окна, нельзя просто мышкой закинуть нужный файл из списка файлов, нельзя настроить параметры через инспектор, включая visibility... Выглядит как костыль ради костыля, надеюсь, когда-нибудь они его переделают/заменят. Моё предложение: убрать отдельное меню, предоставив прямой доступ к потомкам Root через редактор сцены. Т.е. Root ты изменить не можешь, но всё остальное перестраиваешь на своё усмотрение как обычную сцену. Выбранная тобой нода будет заменяться вызовом change_scene() (у меня это прямой потомок World). Опциональные глобальные имена для нод можно оставить, но поставить какое-то предупреждение о вреде злоупотребления ими.
Открывать/закрывать придётся много раз, потому что сложно удержать в памяти всё, что там находится, и в каком оно состоянии. И в отличие от файловой системы и нод в открытых сценах, список синглтонов не находится под рукой, а спрятан в настройки. Это как убрать какую-нибудь ненужную или малозначимую вещь в дальний ящик, потому что о ней не страшно случайно забыть. А ты предлагаешь совать туда очень важные элементы в самом начале разработки, когда они постоянно меняются. И не надо тут про SOLID, ты не можешь с самого начала всё правильно сделать и потом только расширять новыми функциями, особенно если у тебя мало опыта или ты делаешь проект как хобби.
>Пример в студию.
Пикрил - только прототип, но до него всё было намного хуже (на синглтонах). Предстоит ещё многое (до)переделать, и я не хочу лазить туда-сюда по куче меню Godot в тщетных попытках запустить проект без ошибок. Блин, решил по-быстрому сменить тему и получился какой-то кислотный цвет...
>Отключается одной галочкой
Как тогда обращаться к такому скрипту? Через get_node()? По-моему, в официальной документации рекомендуют не делать запросов вверх по иерархии дерева через get_node().
>SOLID
Я делаю проект как хобби и хочу получать удовольствие, а не бороться с легаси, копящимся после каждого моего эксперимента, ведь по солиду я не могу его изменить - только расширить или заменить на потомка. Сейчас я просто беру устаревшие скрипты и выкидываю их в отдельную папку, а оставшиеся скрипты редактирую так, чтобы они от них больше не зависели. Сигналы в этом помогают, потому что сигнал не обязательно обрабатывать. Синглтоны - мешают, потому что обращение к отсутствующему или неправильному синглтону вызывает ошибку.
>крупную игру в соло
>скайрим в одно рыло
Это всё субъективно. Во-первых, основные затраты ААА - это графика, озвучка и пиар. Если тебе не нужна графика, озвучка и раскрутка, ты можешь сделать большую игру. Просто в неё играть почти никто не будет, но это уже другой разговор, может и повезти. Во-вторых, если ты не для заработка игру делаешь, а просто как хобби, ты даже не заметишь, как пролетят годы. Это только желающие по-быстрому срубить бабла разочаровываются, что игры делать намного сложнее, чем в них играть.
>Один список и две кнопки.
Нет древовидности, связывания сигналов через инспектор, нужно делать несколько кликов, чтобы добраться до этого окна, нельзя просто мышкой закинуть нужный файл из списка файлов, нельзя настроить параметры через инспектор, включая visibility... Выглядит как костыль ради костыля, надеюсь, когда-нибудь они его переделают/заменят. Моё предложение: убрать отдельное меню, предоставив прямой доступ к потомкам Root через редактор сцены. Т.е. Root ты изменить не можешь, но всё остальное перестраиваешь на своё усмотрение как обычную сцену. Выбранная тобой нода будет заменяться вызовом change_scene() (у меня это прямой потомок World). Опциональные глобальные имена для нод можно оставить, но поставить какое-то предупреждение о вреде злоупотребления ими.
>Открыл, добавил, закрыл. Всё.
Открывать/закрывать придётся много раз, потому что сложно удержать в памяти всё, что там находится, и в каком оно состоянии. И в отличие от файловой системы и нод в открытых сценах, список синглтонов не находится под рукой, а спрятан в настройки. Это как убрать какую-нибудь ненужную или малозначимую вещь в дальний ящик, потому что о ней не страшно случайно забыть. А ты предлагаешь совать туда очень важные элементы в самом начале разработки, когда они постоянно меняются. И не надо тут про SOLID, ты не можешь с самого начала всё правильно сделать и потом только расширять новыми функциями, особенно если у тебя мало опыта или ты делаешь проект как хобби.
30 Кб, 519x481>>04511
Пикрил - только прототип, но до него всё было намного хуже (на синглтонах). Предстоит ещё многое (до)переделать, и я не хочу лазить туда-сюда по куче меню Godot в тщетных попытках запустить проект без ошибок. Блин, решил по-быстрому сменить тему и получился какой-то кислотный цвет...
Как тогда обращаться к такому скрипту? Через get_node()? По-моему, в официальной документации рекомендуют не делать запросов вверх по иерархии дерева через get_node().
Я делаю проект как хобби и хочу получать удовольствие, а не бороться с легаси, копящимся после каждого моего эксперимента, ведь по солиду я не могу его изменить - только расширить или заменить на потомка. Сейчас я просто беру устаревшие скрипты и выкидываю их в отдельную папку, а оставшиеся скрипты редактирую так, чтобы они от них больше не зависели. Сигналы в этом помогают, потому что сигнал не обязательно обрабатывать. Синглтоны - мешают, потому что обращение к отсутствующему или неправильному синглтону вызывает ошибку.
Это всё субъективно. Во-первых, основные затраты ААА - это графика, озвучка и пиар. Если тебе не нужна графика, озвучка и раскрутка, ты можешь сделать большую игру. Просто в неё играть почти никто не будет, но это уже другой разговор, может и повезти. Во-вторых, если ты не для заработка игру делаешь, а просто как хобби, ты даже не заметишь, как пролетят годы. Это только желающие по-быстрому срубить бабла разочаровываются, что игры делать намного сложнее, чем в них играть.
Нет древовидности, связывания сигналов через инспектор, нужно делать несколько кликов, чтобы добраться до этого окна, нельзя просто мышкой закинуть нужный файл из списка файлов, нельзя настроить параметры через инспектор, включая visibility... Выглядит как костыль ради костыля, надеюсь, когда-нибудь они его переделают/заменят. Моё предложение: убрать отдельное меню, предоставив прямой доступ к потомкам Root через редактор сцены. Т.е. Root ты изменить не можешь, но всё остальное перестраиваешь на своё усмотрение как обычную сцену. Выбранная тобой нода будет заменяться вызовом change_scene() (у меня это прямой потомок World). Опциональные глобальные имена для нод можно оставить, но поставить какое-то предупреждение о вреде злоупотребления ими.
Открывать/закрывать придётся много раз, потому что сложно удержать в памяти всё, что там находится, и в каком оно состоянии. И в отличие от файловой системы и нод в открытых сценах, список синглтонов не находится под рукой, а спрятан в настройки. Это как убрать какую-нибудь ненужную или малозначимую вещь в дальний ящик, потому что о ней не страшно случайно забыть. А ты предлагаешь совать туда очень важные элементы в самом начале разработки, когда они постоянно меняются. И не надо тут про SOLID, ты не можешь с самого начала всё правильно сделать и потом только расширять новыми функциями, особенно если у тебя мало опыта или ты делаешь проект как хобби.
>Пример в студию.
Пикрил - только прототип, но до него всё было намного хуже (на синглтонах). Предстоит ещё многое (до)переделать, и я не хочу лазить туда-сюда по куче меню Godot в тщетных попытках запустить проект без ошибок. Блин, решил по-быстрому сменить тему и получился какой-то кислотный цвет...
>Отключается одной галочкой
Как тогда обращаться к такому скрипту? Через get_node()? По-моему, в официальной документации рекомендуют не делать запросов вверх по иерархии дерева через get_node().
>SOLID
Я делаю проект как хобби и хочу получать удовольствие, а не бороться с легаси, копящимся после каждого моего эксперимента, ведь по солиду я не могу его изменить - только расширить или заменить на потомка. Сейчас я просто беру устаревшие скрипты и выкидываю их в отдельную папку, а оставшиеся скрипты редактирую так, чтобы они от них больше не зависели. Сигналы в этом помогают, потому что сигнал не обязательно обрабатывать. Синглтоны - мешают, потому что обращение к отсутствующему или неправильному синглтону вызывает ошибку.
>крупную игру в соло
>скайрим в одно рыло
Это всё субъективно. Во-первых, основные затраты ААА - это графика, озвучка и пиар. Если тебе не нужна графика, озвучка и раскрутка, ты можешь сделать большую игру. Просто в неё играть почти никто не будет, но это уже другой разговор, может и повезти. Во-вторых, если ты не для заработка игру делаешь, а просто как хобби, ты даже не заметишь, как пролетят годы. Это только желающие по-быстрому срубить бабла разочаровываются, что игры делать намного сложнее, чем в них играть.
>Один список и две кнопки.
Нет древовидности, связывания сигналов через инспектор, нужно делать несколько кликов, чтобы добраться до этого окна, нельзя просто мышкой закинуть нужный файл из списка файлов, нельзя настроить параметры через инспектор, включая visibility... Выглядит как костыль ради костыля, надеюсь, когда-нибудь они его переделают/заменят. Моё предложение: убрать отдельное меню, предоставив прямой доступ к потомкам Root через редактор сцены. Т.е. Root ты изменить не можешь, но всё остальное перестраиваешь на своё усмотрение как обычную сцену. Выбранная тобой нода будет заменяться вызовом change_scene() (у меня это прямой потомок World). Опциональные глобальные имена для нод можно оставить, но поставить какое-то предупреждение о вреде злоупотребления ими.
>Открыл, добавил, закрыл. Всё.
Открывать/закрывать придётся много раз, потому что сложно удержать в памяти всё, что там находится, и в каком оно состоянии. И в отличие от файловой системы и нод в открытых сценах, список синглтонов не находится под рукой, а спрятан в настройки. Это как убрать какую-нибудь ненужную или малозначимую вещь в дальний ящик, потому что о ней не страшно случайно забыть. А ты предлагаешь совать туда очень важные элементы в самом начале разработки, когда они постоянно меняются. И не надо тут про SOLID, ты не можешь с самого начала всё правильно сделать и потом только расширять новыми функциями, особенно если у тебя мало опыта или ты делаешь проект как хобби.
>>04575
На каких ещё в пизду синглтонах? Тебе русским языком два раза сказали, что автозагрузка это просто ноды в дереве. Ты сделал то же самое, что делает автозагрузка, но навелосипедил говнокода, и добавил одну лишнюю ноду в путь, было:
стало
И что ты выиграл? Что?
> Пикрил - только прототип, но до него всё было намного хуже (на синглтонах)
На каких ещё в пизду синглтонах? Тебе русским языком два раза сказали, что автозагрузка это просто ноды в дереве. Ты сделал то же самое, что делает автозагрузка, но навелосипедил говнокода, и добавил одну лишнюю ноду в путь, было:
> root/HUD
стало
> root/Game/HUD
И что ты выиграл? Что?
>>04578 (Del)
Ты меня не слушаешь штоле? (не читаешь, но не суть).
Одной галкой отключи регистрацию имени и всё, скрипты не увидят эту ноду. Чтобы получить её напиши свой любимый бойлерплейт (я гляжу ты его любишь):
>>04575
Конкретно об этом ничего не знаю. Ткни носом в ссылку. Я знаю, что в иерархии дерева сцены инициализация и вход в дерево же идут по порядку. И это надо понимать и правильно размещать ноды. Если первым стоит node1, а второй node2 и в первой идёт обращение ко второй в колбэке _ready или в сахаре onready, то вторая не будет найдена, потому что её ещё нет и вывалится ошибка.
Ты меня не слушаешь штоле? (не читаешь, но не суть).
Одной галкой отключи регистрацию имени и всё, скрипты не увидят эту ноду. Чтобы получить её напиши свой любимый бойлерплейт (я гляжу ты его любишь):
> onready var hud = get_node("/root/HUD")
>>04575
> По-моему, в официальной документации рекомендуют не делать запросов вверх по иерархии дерева через get_node().
Конкретно об этом ничего не знаю. Ткни носом в ссылку. Я знаю, что в иерархии дерева сцены инициализация и вход в дерево же идут по порядку. И это надо понимать и правильно размещать ноды. Если первым стоит node1, а второй node2 и в первой идёт обращение ко второй в колбэке _ready или в сахаре onready, то вторая не будет найдена, потому что её ещё нет и вывалится ошибка.
>>04577
Да, но доступ к ним из редактора сильно затруднён. Увидеть их как ноды в дереве возможно только через "Remote" вкладку, когда проект уже запущен, так какой смысл от того, что это ноды?
Да какая разница, какой там абсолютный путь, если по абсолютному пути обращаться вредно. Не используй абсолютные пути. Не используй относительные пути вверх. Используй только относительные пути вниз, к потомкам.
Выиграл возможность разместить скрипт game.gd в ноде Game, который управляет всем проектом, включая включение/отключение отображения HUD и связывания HUD/Main с Wolrd/World/Player (вообще-то, второй World должен называться WorldData или просто Data, нужно будет исправить когда-нибудь).
Из всех нод в автозагрузку безболезненно можно поместить только Screenshots, потому что она ни с чем пока не взаимодействует. Но я прикинул, возможно, в будущем обращения всё-таки будут, так что лучше далеко не прятать и сложить в Game. Всё равно от её положения в дереве ничего не зависит.
Ещё выгода от скрипта Game в том, что он явно связывает сигналы между нодами-потомками, которые не связаны через инспектор. В случае с автозагрузкой сложно предсказать, какие ноды обращаются к каким нодам автозагрузки по глобальному имени. Да, кода для связывания нужно много, но этот код компенсирует отсутствие важного для модульных ЯП поля with/uses/import у скриптов, так что всё справедливо, просите Хуана добавить with/use(s)/import, а то принудительно глобальные сущности до добра не доведут.
>>04578 (Del)
Вот-вот, и это тоже.
>автозагрузка это просто ноды в дереве
Да, но доступ к ним из редактора сильно затруднён. Увидеть их как ноды в дереве возможно только через "Remote" вкладку, когда проект уже запущен, так какой смысл от того, что это ноды?
>лишнюю ноду в путь
Да какая разница, какой там абсолютный путь, если по абсолютному пути обращаться вредно. Не используй абсолютные пути. Не используй относительные пути вверх. Используй только относительные пути вниз, к потомкам.
>>root/Game/HUD
>И что ты выиграл? Что?
Выиграл возможность разместить скрипт game.gd в ноде Game, который управляет всем проектом, включая включение/отключение отображения HUD и связывания HUD/Main с Wolrd/World/Player (вообще-то, второй World должен называться WorldData или просто Data, нужно будет исправить когда-нибудь).
Из всех нод в автозагрузку безболезненно можно поместить только Screenshots, потому что она ни с чем пока не взаимодействует. Но я прикинул, возможно, в будущем обращения всё-таки будут, так что лучше далеко не прятать и сложить в Game. Всё равно от её положения в дереве ничего не зависит.
Ещё выгода от скрипта Game в том, что он явно связывает сигналы между нодами-потомками, которые не связаны через инспектор. В случае с автозагрузкой сложно предсказать, какие ноды обращаются к каким нодам автозагрузки по глобальному имени. Да, кода для связывания нужно много, но этот код компенсирует отсутствие важного для модульных ЯП поля with/uses/import у скриптов, так что всё справедливо, просите Хуана добавить with/use(s)/import, а то принудительно глобальные сущности до добра не доведут.
>>04578 (Del)
Вот-вот, и это тоже.
>>04580
God object.
Нуфф сказал.
> разместить скрипт game.gd в ноде Game, который управляет всем проектом
God object.
Нуфф сказал.
738 Кб, 1200x557>>04596 (Del)
Он расставляет управляющих по своим местам и сваливает в закат.
Он расставляет управляющих по своим местам и сваливает в закат.
>>04597
эт много ?
эт много ?
>>04579
Здесь ты получаешь ссылку на объект, который тебе не принадлежит (не является потомком), т.е. нарушаешь инкапсуляцию. В моём случае пришлось бы таким кодом связывать автозагруженные ноды с обычными в коде game.gd, но зачем делать это таким вывернутым способом, когда можно разложить все ноды в одной сцене, в одном окне редактора (game.tscn)?
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html#node-paths
Вот этой ошибки ОЧЕНЬ ЛЕГКО избежать, если вместо той лапши, которую ты предлагаешь, делать как предлагаю я: связывать ноды через их общего предка, в данном примере это Game (game.gd). Предок получит сигнал _ready() только после готовности всех его потомков, следовательно, никакой проблемы типа "ой, мой сосед ещё не существует, какая печаль" никогда не будет.
Главное, что я хочу сказать, ноды-сцены должны иметь возможность работать отдельно, не ссылаясь на каких-то внешних соседей или потомков соседей. Т.е. если твой Player нуждается в отправке данных в HUD, он должен сгенерировать событие (сигнал) "а обновите там кто-нибудь данные на экране, вот эти: ("пук"), спасибо", а не тыкаться по пути get_node("../../../бла-бла-бла/бла/бла-бла/HUD/Label").text = "пук" и обваливать всё приложение.
>>04582
Любое приложение - "god object", потому что, с точки зрения стороннего наблюдателя, любое приложение - это объект, и он умеет очень многое. Вот, например, Godot - это god object, правильно? Правильно. Запускаешь какой-то godot.exe, а тебе функции и интерфейсы прямо в лицо мощным потоком, захлебнуться можно.
Не нравится давать game.gd много контроля - разбей проект на части и сделай локальные менеджеры, которые занимаются какими-то своими частями проекта. А game.gd будет объединять эти менеджеры в цельную игру. При этом ты можешь каждый из менеджеров по отдельности проверить, если они не тыкают друг друга прямыми ссылками.
>>04592
Я неправильно выразился, там нет полного контроля за всеми остальными нодами. Пока что game.gd у меня только отвечает за начало новой игры, выход в главное меню и соединение некоторых сигналов из разных независимых систем. По-моему, глупо помещать эту функциональность прямо в интерфейс или игрока, должен быть кто-то старший, кто выше их всех. Но Godot не даёт простого доступа к ноде root через редактор... Приходится делать свой root)
>onready var hud = get_node("/root/HUD")
Здесь ты получаешь ссылку на объект, который тебе не принадлежит (не является потомком), т.е. нарушаешь инкапсуляцию. В моём случае пришлось бы таким кодом связывать автозагруженные ноды с обычными в коде game.gd, но зачем делать это таким вывернутым способом, когда можно разложить все ноды в одной сцене, в одном окне редактора (game.tscn)?
>Ткни носом в ссылку
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html#node-paths
>As with file paths, you can use ".." to get a parent node. The best practice is to avoid doing that though not to break encapsulation. You can also start the path with a forward slash to make it absolute, in which case your topmost node would be "/root", the application's predefined root viewport.
>вторая не будет найдена, потому что её ещё нет
Вот этой ошибки ОЧЕНЬ ЛЕГКО избежать, если вместо той лапши, которую ты предлагаешь, делать как предлагаю я: связывать ноды через их общего предка, в данном примере это Game (game.gd). Предок получит сигнал _ready() только после готовности всех его потомков, следовательно, никакой проблемы типа "ой, мой сосед ещё не существует, какая печаль" никогда не будет.
Главное, что я хочу сказать, ноды-сцены должны иметь возможность работать отдельно, не ссылаясь на каких-то внешних соседей или потомков соседей. Т.е. если твой Player нуждается в отправке данных в HUD, он должен сгенерировать событие (сигнал) "а обновите там кто-нибудь данные на экране, вот эти: ("пук"), спасибо", а не тыкаться по пути get_node("../../../бла-бла-бла/бла/бла-бла/HUD/Label").text = "пук" и обваливать всё приложение.
>>04582
>God object.
Любое приложение - "god object", потому что, с точки зрения стороннего наблюдателя, любое приложение - это объект, и он умеет очень многое. Вот, например, Godot - это god object, правильно? Правильно. Запускаешь какой-то godot.exe, а тебе функции и интерфейсы прямо в лицо мощным потоком, захлебнуться можно.
Не нравится давать game.gd много контроля - разбей проект на части и сделай локальные менеджеры, которые занимаются какими-то своими частями проекта. А game.gd будет объединять эти менеджеры в цельную игру. При этом ты можешь каждый из менеджеров по отдельности проверить, если они не тыкают друг друга прямыми ссылками.
>>04592
>не управляет
Я неправильно выразился, там нет полного контроля за всеми остальными нодами. Пока что game.gd у меня только отвечает за начало новой игры, выход в главное меню и соединение некоторых сигналов из разных независимых систем. По-моему, глупо помещать эту функциональность прямо в интерфейс или игрока, должен быть кто-то старший, кто выше их всех. Но Godot не даёт простого доступа к ноде root через редактор... Приходится делать свой root)
>>04579
Здесь ты получаешь ссылку на объект, который тебе не принадлежит (не является потомком), т.е. нарушаешь инкапсуляцию. В моём случае пришлось бы таким кодом связывать автозагруженные ноды с обычными в коде game.gd, но зачем делать это таким вывернутым способом, когда можно разложить все ноды в одной сцене, в одном окне редактора (game.tscn)?
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html#node-paths
Вот этой ошибки ОЧЕНЬ ЛЕГКО избежать, если вместо той лапши, которую ты предлагаешь, делать как предлагаю я: связывать ноды через их общего предка, в данном примере это Game (game.gd). Предок получит сигнал _ready() только после готовности всех его потомков, следовательно, никакой проблемы типа "ой, мой сосед ещё не существует, какая печаль" никогда не будет.
Главное, что я хочу сказать, ноды-сцены должны иметь возможность работать отдельно, не ссылаясь на каких-то внешних соседей или потомков соседей. Т.е. если твой Player нуждается в отправке данных в HUD, он должен сгенерировать событие (сигнал) "а обновите там кто-нибудь данные на экране, вот эти: ("пук"), спасибо", а не тыкаться по пути get_node("../../../бла-бла-бла/бла/бла-бла/HUD/Label").text = "пук" и обваливать всё приложение.
>>04582
Любое приложение - "god object", потому что, с точки зрения стороннего наблюдателя, любое приложение - это объект, и он умеет очень многое. Вот, например, Godot - это god object, правильно? Правильно. Запускаешь какой-то godot.exe, а тебе функции и интерфейсы прямо в лицо мощным потоком, захлебнуться можно.
Не нравится давать game.gd много контроля - разбей проект на части и сделай локальные менеджеры, которые занимаются какими-то своими частями проекта. А game.gd будет объединять эти менеджеры в цельную игру. При этом ты можешь каждый из менеджеров по отдельности проверить, если они не тыкают друг друга прямыми ссылками.
>>04592
Я неправильно выразился, там нет полного контроля за всеми остальными нодами. Пока что game.gd у меня только отвечает за начало новой игры, выход в главное меню и соединение некоторых сигналов из разных независимых систем. По-моему, глупо помещать эту функциональность прямо в интерфейс или игрока, должен быть кто-то старший, кто выше их всех. Но Godot не даёт простого доступа к ноде root через редактор... Приходится делать свой root)
>onready var hud = get_node("/root/HUD")
Здесь ты получаешь ссылку на объект, который тебе не принадлежит (не является потомком), т.е. нарушаешь инкапсуляцию. В моём случае пришлось бы таким кодом связывать автозагруженные ноды с обычными в коде game.gd, но зачем делать это таким вывернутым способом, когда можно разложить все ноды в одной сцене, в одном окне редактора (game.tscn)?
>Ткни носом в ссылку
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html#node-paths
>As with file paths, you can use ".." to get a parent node. The best practice is to avoid doing that though not to break encapsulation. You can also start the path with a forward slash to make it absolute, in which case your topmost node would be "/root", the application's predefined root viewport.
>вторая не будет найдена, потому что её ещё нет
Вот этой ошибки ОЧЕНЬ ЛЕГКО избежать, если вместо той лапши, которую ты предлагаешь, делать как предлагаю я: связывать ноды через их общего предка, в данном примере это Game (game.gd). Предок получит сигнал _ready() только после готовности всех его потомков, следовательно, никакой проблемы типа "ой, мой сосед ещё не существует, какая печаль" никогда не будет.
Главное, что я хочу сказать, ноды-сцены должны иметь возможность работать отдельно, не ссылаясь на каких-то внешних соседей или потомков соседей. Т.е. если твой Player нуждается в отправке данных в HUD, он должен сгенерировать событие (сигнал) "а обновите там кто-нибудь данные на экране, вот эти: ("пук"), спасибо", а не тыкаться по пути get_node("../../../бла-бла-бла/бла/бла-бла/HUD/Label").text = "пук" и обваливать всё приложение.
>>04582
>God object.
Любое приложение - "god object", потому что, с точки зрения стороннего наблюдателя, любое приложение - это объект, и он умеет очень многое. Вот, например, Godot - это god object, правильно? Правильно. Запускаешь какой-то godot.exe, а тебе функции и интерфейсы прямо в лицо мощным потоком, захлебнуться можно.
Не нравится давать game.gd много контроля - разбей проект на части и сделай локальные менеджеры, которые занимаются какими-то своими частями проекта. А game.gd будет объединять эти менеджеры в цельную игру. При этом ты можешь каждый из менеджеров по отдельности проверить, если они не тыкают друг друга прямыми ссылками.
>>04592
>не управляет
Я неправильно выразился, там нет полного контроля за всеми остальными нодами. Пока что game.gd у меня только отвечает за начало новой игры, выход в главное меню и соединение некоторых сигналов из разных независимых систем. По-моему, глупо помещать эту функциональность прямо в интерфейс или игрока, должен быть кто-то старший, кто выше их всех. Но Godot не даёт простого доступа к ноде root через редактор... Приходится делать свой root)
>>04601
Ладно, херню сказал, воспринимайте это как сарказм)))
Честно говоря, я не понимаю, как распознать божественный объект и тем более как его разделить безболезненно. Потому что каждое разделение влечёт за собой больше кода... Стоит ли разделять то, что компактнее выглядит в собранном виде?
>Любое приложение - "god object", потому что, с точки зрения стороннего наблюдателя, любое приложение - это объект, и он умеет очень многое. Вот, например, Godot - это god object, правильно? Правильно. Запускаешь какой-то godot.exe, а тебе функции и интерфейсы прямо в лицо мощным потоком, захлебнуться можно.
Ладно, херню сказал, воспринимайте это как сарказм)))
Честно говоря, я не понимаю, как распознать божественный объект и тем более как его разделить безболезненно. Потому что каждое разделение влечёт за собой больше кода... Стоит ли разделять то, что компактнее выглядит в собранном виде?
>>04601
Нет. Не нарушаю. Инкапсуляция - это когда весь код in capsule. То есть, он самодостаточен, как говорится, делает одну вещь и делает её хорошо. Это инкапсуляция.
Когда ты к одной "капсуле" подключаешь ссылку на другую "капсулу", ты не нарушаешь инкапсуляцию.
Инкапсуляцию ты нарушишь, если начнёшь скажем, юзать утилитарные методы одной капсулы в другой. Поэтому утилитарные функции принято удалять из интерфейса, то есть делать приватными. Именно поэтому инкапсуляцию часто путают с сокрытием.
> нарушаешь инкапсуляцию
Нет. Не нарушаю. Инкапсуляция - это когда весь код in capsule. То есть, он самодостаточен, как говорится, делает одну вещь и делает её хорошо. Это инкапсуляция.
Когда ты к одной "капсуле" подключаешь ссылку на другую "капсулу", ты не нарушаешь инкапсуляцию.
Инкапсуляцию ты нарушишь, если начнёшь скажем, юзать утилитарные методы одной капсулы в другой. Поэтому утилитарные функции принято удалять из интерфейса, то есть делать приватными. Именно поэтому инкапсуляцию часто путают с сокрытием.
>>04603
Он в отличие от вышеописанной капсулы, делает множество вещей, внутри него перемешана куча утилит разной направленности, бизнес-логика, физические расчёты, сохранение и загрузка, меню, диалоги, всё в одной вонючей куче, на одной портянке кода длиной в 100500 строк.
> как распознать божественный объект
Он в отличие от вышеописанной капсулы, делает множество вещей, внутри него перемешана куча утилит разной направленности, бизнес-логика, физические расчёты, сохранение и загрузка, меню, диалоги, всё в одной вонючей куче, на одной портянке кода длиной в 100500 строк.
>>04603
Прочитав предыдущие два поста ты уже должен найти ответ самостоятельно.
Не стоит.
> Стоит ли разделять то, что компактнее выглядит в собранном виде?
Прочитав предыдущие два поста ты уже должен найти ответ самостоятельно.
Не стоит.
>>04631
Кому должно?
Это комегс из англоязычных интернетов. Они сами так говорят, МГИМО ты наше учоное.
Кому должно?
Это комегс из англоязычных интернетов. Они сами так говорят, МГИМО ты наше учоное.
>>04637
Дебил, никто там так не говорит. Тебя на смех подымут, если ты такое ляпнешь, или примут за необразованного иностранца.
Дебил, никто там так не говорит. Тебя на смех подымут, если ты такое ляпнешь, или примут за необразованного иностранца.
>>04651 (Del)
Ну так 60% носителей именно так и разговаривают и пишут. Особенно в мире айти - там все коричневые.
>Блядь, никто не требует знания литературного языка, но это ошибка на уровне "велик могучим русский языка".
Ну так 60% носителей именно так и разговаривают и пишут. Особенно в мире айти - там все коричневые.
Есть ли встроенная реализация A★, которую можно было бы использовать на произвольном массиве данных? Или придётся изучать алгоритм самому и пилить велосипед?
>>04605
А для чего может потребоваться ссылка на HUD? Чтобы утилитарно обновить какую-то информацию. Допустим, персонаж получил урон и понизил своё здоровье. Разработчик хочет отобразить эти новые данные на экране для удобства игрока. Ты предлагаешь персонажу получить по абсолютной ссылке некий глобальный объект "надпись на экране" и вручную вписать этому объекту новое значение здоровья. Технически это сделать можно, но потенциально ведёт к определённым проблемам в будущем.
Будет намного лучше, если персонаж при понижении здоровья генерирует событие "здоровье снизилось (новое значение здоровья)", а дальше все подключённые обработчики это событие обработают, как сами посчитают нужным. И подключать обработчики должен кто-то сторонний, чтобы ни обработчики, ни персонаж не трогали друг друга лишний раз.
Развиваем ситуацию: ты решил отказаться от числового счётчика здоровья и заменить его полоской, но твой персонаж пишет число в цифровую надпись. Ты можешь костылить, а можешь залезть в персонажа и изменить ссылку. Далее ты решил добавить звук боли и мигающую кровавую рамку при определённом уровне здоровья. Куда ты это воткнёшь? Сделаешь сеттер для полоски здоровья, который будет одновременно с обновлением полоски запускать звук? Или заставишь персонажа ещё и звук запускать? Едем дальше, ты поиграл в этот прототип и внезапно осознал, что никакого отображения здоровья вообще не нужно, и намного лучше будет без всех этих циферок и полосок. Ты удаляешь элементы интерфейса и игра перестаёт работать, потому что персонажу для работы нужны валидные ссылки на эти элементы. Будешь ставить заглушки? Скрывать интерфейс вместо его удаления? Править код персонажа, рискуя править его потом обратно, когда снова передумаешь?
А ведь если бы ты просто юзал сигналы, твой персонаж бы вообще не знал ни о каких надписях, полосках, звуках, рамочках и прочих фантиках, и не возмущался при их удалении или изменении. А ты мог бы добавить сколько угодно новых свистелок и перделок, реагирующих на изменение здоровья персонажа. И потом их безболезненно убрать, если надоест.
Но нет, ты фанатеешь с синглтонов, абсолютных путей и прочих глобальных сущностей в своём лапшекоде...
>Инкапсуляцию ты нарушишь, если начнёшь скажем, юзать утилитарные методы одной капсулы в другой.
А для чего может потребоваться ссылка на HUD? Чтобы утилитарно обновить какую-то информацию. Допустим, персонаж получил урон и понизил своё здоровье. Разработчик хочет отобразить эти новые данные на экране для удобства игрока. Ты предлагаешь персонажу получить по абсолютной ссылке некий глобальный объект "надпись на экране" и вручную вписать этому объекту новое значение здоровья. Технически это сделать можно, но потенциально ведёт к определённым проблемам в будущем.
Будет намного лучше, если персонаж при понижении здоровья генерирует событие "здоровье снизилось (новое значение здоровья)", а дальше все подключённые обработчики это событие обработают, как сами посчитают нужным. И подключать обработчики должен кто-то сторонний, чтобы ни обработчики, ни персонаж не трогали друг друга лишний раз.
Развиваем ситуацию: ты решил отказаться от числового счётчика здоровья и заменить его полоской, но твой персонаж пишет число в цифровую надпись. Ты можешь костылить, а можешь залезть в персонажа и изменить ссылку. Далее ты решил добавить звук боли и мигающую кровавую рамку при определённом уровне здоровья. Куда ты это воткнёшь? Сделаешь сеттер для полоски здоровья, который будет одновременно с обновлением полоски запускать звук? Или заставишь персонажа ещё и звук запускать? Едем дальше, ты поиграл в этот прототип и внезапно осознал, что никакого отображения здоровья вообще не нужно, и намного лучше будет без всех этих циферок и полосок. Ты удаляешь элементы интерфейса и игра перестаёт работать, потому что персонажу для работы нужны валидные ссылки на эти элементы. Будешь ставить заглушки? Скрывать интерфейс вместо его удаления? Править код персонажа, рискуя править его потом обратно, когда снова передумаешь?
А ведь если бы ты просто юзал сигналы, твой персонаж бы вообще не знал ни о каких надписях, полосках, звуках, рамочках и прочих фантиках, и не возмущался при их удалении или изменении. А ты мог бы добавить сколько угодно новых свистелок и перделок, реагирующих на изменение здоровья персонажа. И потом их безболезненно убрать, если надоест.
Но нет, ты фанатеешь с синглтонов, абсолютных путей и прочих глобальных сущностей в своём лапшекоде...
>>04605
А для чего может потребоваться ссылка на HUD? Чтобы утилитарно обновить какую-то информацию. Допустим, персонаж получил урон и понизил своё здоровье. Разработчик хочет отобразить эти новые данные на экране для удобства игрока. Ты предлагаешь персонажу получить по абсолютной ссылке некий глобальный объект "надпись на экране" и вручную вписать этому объекту новое значение здоровья. Технически это сделать можно, но потенциально ведёт к определённым проблемам в будущем.
Будет намного лучше, если персонаж при понижении здоровья генерирует событие "здоровье снизилось (новое значение здоровья)", а дальше все подключённые обработчики это событие обработают, как сами посчитают нужным. И подключать обработчики должен кто-то сторонний, чтобы ни обработчики, ни персонаж не трогали друг друга лишний раз.
Развиваем ситуацию: ты решил отказаться от числового счётчика здоровья и заменить его полоской, но твой персонаж пишет число в цифровую надпись. Ты можешь костылить, а можешь залезть в персонажа и изменить ссылку. Далее ты решил добавить звук боли и мигающую кровавую рамку при определённом уровне здоровья. Куда ты это воткнёшь? Сделаешь сеттер для полоски здоровья, который будет одновременно с обновлением полоски запускать звук? Или заставишь персонажа ещё и звук запускать? Едем дальше, ты поиграл в этот прототип и внезапно осознал, что никакого отображения здоровья вообще не нужно, и намного лучше будет без всех этих циферок и полосок. Ты удаляешь элементы интерфейса и игра перестаёт работать, потому что персонажу для работы нужны валидные ссылки на эти элементы. Будешь ставить заглушки? Скрывать интерфейс вместо его удаления? Править код персонажа, рискуя править его потом обратно, когда снова передумаешь?
А ведь если бы ты просто юзал сигналы, твой персонаж бы вообще не знал ни о каких надписях, полосках, звуках, рамочках и прочих фантиках, и не возмущался при их удалении или изменении. А ты мог бы добавить сколько угодно новых свистелок и перделок, реагирующих на изменение здоровья персонажа. И потом их безболезненно убрать, если надоест.
Но нет, ты фанатеешь с синглтонов, абсолютных путей и прочих глобальных сущностей в своём лапшекоде...
>Инкапсуляцию ты нарушишь, если начнёшь скажем, юзать утилитарные методы одной капсулы в другой.
А для чего может потребоваться ссылка на HUD? Чтобы утилитарно обновить какую-то информацию. Допустим, персонаж получил урон и понизил своё здоровье. Разработчик хочет отобразить эти новые данные на экране для удобства игрока. Ты предлагаешь персонажу получить по абсолютной ссылке некий глобальный объект "надпись на экране" и вручную вписать этому объекту новое значение здоровья. Технически это сделать можно, но потенциально ведёт к определённым проблемам в будущем.
Будет намного лучше, если персонаж при понижении здоровья генерирует событие "здоровье снизилось (новое значение здоровья)", а дальше все подключённые обработчики это событие обработают, как сами посчитают нужным. И подключать обработчики должен кто-то сторонний, чтобы ни обработчики, ни персонаж не трогали друг друга лишний раз.
Развиваем ситуацию: ты решил отказаться от числового счётчика здоровья и заменить его полоской, но твой персонаж пишет число в цифровую надпись. Ты можешь костылить, а можешь залезть в персонажа и изменить ссылку. Далее ты решил добавить звук боли и мигающую кровавую рамку при определённом уровне здоровья. Куда ты это воткнёшь? Сделаешь сеттер для полоски здоровья, который будет одновременно с обновлением полоски запускать звук? Или заставишь персонажа ещё и звук запускать? Едем дальше, ты поиграл в этот прототип и внезапно осознал, что никакого отображения здоровья вообще не нужно, и намного лучше будет без всех этих циферок и полосок. Ты удаляешь элементы интерфейса и игра перестаёт работать, потому что персонажу для работы нужны валидные ссылки на эти элементы. Будешь ставить заглушки? Скрывать интерфейс вместо его удаления? Править код персонажа, рискуя править его потом обратно, когда снова передумаешь?
А ведь если бы ты просто юзал сигналы, твой персонаж бы вообще не знал ни о каких надписях, полосках, звуках, рамочках и прочих фантиках, и не возмущался при их удалении или изменении. А ты мог бы добавить сколько угодно новых свистелок и перделок, реагирующих на изменение здоровья персонажа. И потом их безболезненно убрать, если надоест.
Но нет, ты фанатеешь с синглтонов, абсолютных путей и прочих глобальных сущностей в своём лапшекоде...
>>04652
Сколько я на форчане сижу, ни разу не видел, чтобы так разговаривали. Причем там флажки блядь таких стран, что я даже не слышал про них.
>Ну так 60% носителей именно так и разговаривают и пишут. Особенно в мире айти - там все коричневые.
Сколько я на форчане сижу, ни разу не видел, чтобы так разговаривали. Причем там флажки блядь таких стран, что я даже не слышал про них.
Бля, до сих пор чтоле челы не слили в свободное плаванье Learn to Code From Zero With Godot
>>04677
А нахуй его сливать? Там нет ничего, чего не было бы в любых имеющихся курсах по кодингу и/или геймдеву. Только гдскрипт вместо си/джавы/паскаля/пайтона. Просто берёшь любой доступный курс/туториал и читаешь/смотришь, улавливая суть, и обязательно делай проект параллельно с туториалом, чтобы моторная память работала. Просто читать - не продуктивно.
А нахуй его сливать? Там нет ничего, чего не было бы в любых имеющихся курсах по кодингу и/или геймдеву. Только гдскрипт вместо си/джавы/паскаля/пайтона. Просто берёшь любой доступный курс/туториал и читаешь/смотришь, улавливая суть, и обязательно делай проект параллельно с туториалом, чтобы моторная память работала. Просто читать - не продуктивно.
>>04680
Вот например, возьми эту статью:
https://gameprogrammingpatterns.com/state.html
Что ты не сможешь её перевести с используемого там псевдокода на гдскрит? Серьёзно?
Вот например, возьми эту статью:
https://gameprogrammingpatterns.com/state.html
Что ты не сможешь её перевести с используемого там псевдокода на гдскрит? Серьёзно?
>>04680
А хули его бы не слить?
к тому же сразу для нулей в программировании и гейдева спец для разработки под годот.
А я нуль в программировании, так что идеально подходит. Он даже не под дрм.
А хули его бы не слить?
к тому же сразу для нулей в программировании и гейдева спец для разработки под годот.
А я нуль в программировании, так что идеально подходит. Он даже не под дрм.
>>04690
Искренне рикамендую изучить общее программирование по любому из понравившихся курсов для начинающих, написать свой калькулятор, написать свой КРУД. А уж потом в геймдев. Вот без сарказма и троллинга. Кучу времени себе сэкономишь.
> для нулей в программировании
> А я нуль в программировании
Искренне рикамендую изучить общее программирование по любому из понравившихся курсов для начинающих, написать свой калькулятор, написать свой КРУД. А уж потом в геймдев. Вот без сарказма и троллинга. Кучу времени себе сэкономишь.
>>04659 (Del)
Это не страшно, но как мне ориентироваться в нём?
Сейчас попробовал вот. У меня двумерный массив, т.е. точки (x, y). Я выбираю точку (x, y), куда хочу отправиться... и вынужден брутфорсом искать id этой точки? Лишняя работа какая-то. Я понимаю, что AStar - это общее решение для любых графов. Но я не понимаю, как мне ориентироваться на хотя бы плоской сетке, если я вынужден использовать id узлов, а не точки/векторы...
Если ты хочешь создать дорогу, делай её отдельным узлом. Если вес в разные стороны разный, делай два узла с односторонним движением в каждом, тогда в одну сторону будет проход с одной стоимостью, а в другую сторону - с другой.
Как-то нереалистично, я ИРЛ ходил в лес - вход с выходом по времени одинаковы. У тебя там в игре какой-то волшебный лес, войти в который дороже, чем выйти? А если ты про навигацию в лесу, тогда выход из леса должен быть дороже входа, потому что войти можно в любом направлении, а для выхода это направление нужно отыскать (кто заблуждался в лесу - поймёт).
Просека - отдельный узел/тайл/гекс, это очевидно. В чём смысл делать просеку поперёк одного гекса, если можно назначить целый гекс на просеку? Сам себе сложности создаёшь.
>заполняли весь граф по точкам
Это не страшно, но как мне ориентироваться в нём?
Сейчас попробовал вот. У меня двумерный массив, т.е. точки (x, y). Я выбираю точку (x, y), куда хочу отправиться... и вынужден брутфорсом искать id этой точки? Лишняя работа какая-то. Я понимаю, что AStar - это общее решение для любых графов. Но я не понимаю, как мне ориентироваться на хотя бы плоской сетке, если я вынужден использовать id узлов, а не точки/векторы...
>мне еще нужна стоимость ребер
Если ты хочешь создать дорогу, делай её отдельным узлом. Если вес в разные стороны разный, делай два узла с односторонним движением в каждом, тогда в одну сторону будет проход с одной стоимостью, а в другую сторону - с другой.
>вход в лес стоит дороже, чем выход из леса
Как-то нереалистично, я ИРЛ ходил в лес - вход с выходом по времени одинаковы. У тебя там в игре какой-то волшебный лес, войти в который дороже, чем выйти? А если ты про навигацию в лесу, тогда выход из леса должен быть дороже входа, потому что войти можно в любом направлении, а для выхода это направление нужно отыскать (кто заблуждался в лесу - поймёт).
>отличается от прохода по лесу вдоль просеки
Просека - отдельный узел/тайл/гекс, это очевидно. В чём смысл делать просеку поперёк одного гекса, если можно назначить целый гекс на просеку? Сам себе сложности создаёшь.
>>04677
>>04690
Сколько лет ты ждёшь какой-то курс для детей, чтобы спиратить его? Давно бы уже мог накопить денег со школьных обедов и купить, или обучиться программированию по любому другому изначально бесплатному курсу. Создаёшь проблему из ничего.
>до сих пор чтоле челы не слили
>>04690
>я нуль в программировании
Сколько лет ты ждёшь какой-то курс для детей, чтобы спиратить его? Давно бы уже мог накопить денег со школьных обедов и купить, или обучиться программированию по любому другому изначально бесплатному курсу. Создаёшь проблему из ничего.
>>04704
Года за меня придумал, так вот сам и скажи сколько времени.
Кста сейчас же ещё так легко купить заграничный контент, верно?
>Сколько лет ты ждёшь какой-то курс для детей, чтобы спиратить его?
Года за меня придумал, так вот сам и скажи сколько времени.
Кста сейчас же ещё так легко купить заграничный контент, верно?
>>04700
Блядь, в варгеймах настольных так делается для простоты. Вот смотри. Скажем, ты хочешь перейти с гекса равнины на гекс леса - тебе нужно сложить стоимость перехода половины гекса равнины и половины гекса леса, вычесть из очков движения, и так на каждый ебаный гекс. Проще считать, что вход в гекс стоит столько-то, выход не стоит ничего, при этом результат отличаться не будет - при въезде в гекс ты уже заранее заплатил и за выезд из него.
>Как-то нереалистично, я ИРЛ ходил в лес - вход с выходом по времени одинаковы. У тебя там в игре какой-то волшебный лес, войти в который дороже, чем выйти?
Блядь, в варгеймах настольных так делается для простоты. Вот смотри. Скажем, ты хочешь перейти с гекса равнины на гекс леса - тебе нужно сложить стоимость перехода половины гекса равнины и половины гекса леса, вычесть из очков движения, и так на каждый ебаный гекс. Проще считать, что вход в гекс стоит столько-то, выход не стоит ничего, при этом результат отличаться не будет - при въезде в гекс ты уже заранее заплатил и за выезд из него.
48 Кб, 624x741Помогите сделать волны как на картинке нарисовано черным. Никак не могу понять как написать шейдер.
Аналогично, хотелось бы "подводную часть" скрывать в глубине не так резко.
Обе эти проблемы заключаются в том:
- я хз как считать дистанцию между границей текстуры, чтобы превращать её плавно в белый цвет или скрывать альфой.
Аналогично, хотелось бы "подводную часть" скрывать в глубине не так резко.
Обе эти проблемы заключаются в том:
- я хз как считать дистанцию между границей текстуры, чтобы превращать её плавно в белый цвет или скрывать альфой.
>>04792
Гугли на ютубе godot water shader хули тут ещё посоветовать? Я в шейдеры вообще не могу.
Гугли на ютубе godot water shader хули тут ещё посоветовать? Я в шейдеры вообще не могу.
>>04833
Ну и что? Тебе главное суть уловить. А изометрию сам высчитаешь. Я видел когда-то давно туториал по шейдеру воды, огня дыма, там все необходимые тебе матан-трюки имелись. Искать я его за тебя не буду. Мне некогда, там Великое Древо спалить надо. Всё, кароч, убегаю, обнял, на созвоне.
Ну и что? Тебе главное суть уловить. А изометрию сам высчитаешь. Я видел когда-то давно туториал по шейдеру воды, огня дыма, там все необходимые тебе матан-трюки имелись. Искать я его за тебя не буду. Мне некогда, там Великое Древо спалить надо. Всё, кароч, убегаю, обнял, на созвоне.
1,4 Мб, webm,640x480, 0:35
>>04700
Что-то я затупил тогда. Подумал и нашёл несколько решений. И у AStar есть подходящие функции, как раз то, что мне нужно было, я просто невнимательно читал API. Набросал грубый прототип движущихся по дорогам ботов. Медленные по краям дорог - это типа пешеходы, 6 км/ч. Быстрые по серединам - машины, 60 км/ч. Вроде особых проблем не обнаружил и FPS держится выше 60 до 1000 ботов одновременно, при том что они индивидуально сами себя двигают - у каждого внутри подсчёт времени и интерполяция движения. Но есть нюанс: это всё Spatial, а не KinematicBody. Как прикрутить к ним физику? Непонятно. Можно ли навесить KinematicBody на движущийся Spatial? И вообще... нужен ли мне KinematicBody для каждого бота вблизи игрока?.. Может, достаточно будет рейкастов и Area, чтобы они реагировали на воздействия окружающей среды (без этих реакций KinematicBody ощущается как бревно, так зачем он нужен)... Вдали от игрока боты смогут взаимодействовать друг с другом виртуально, находясь в соседних "клетках", тут физика точно не нужна.
>>04734 (Del)
Ясно-понятно, так бы и сказал, что это прихоть заказчика. Всё правильно, за чужие деньги - хоть луну с неба. Я же рассуждал с позиции инди, т.е. независимого разработчика.
>>04781
Встроенный AStar так и считает.
https://docs.godotengine.org/en/stable/classes/class_astar.html
Т.е. если у тебя вход в лес 5 баллов, а вход в степь 1 балл, то:
(откуда угодно) -> степь = 1 балл
(откуда угодно) -> лес = 5 баллов
(откуда угодно) -> степь -> лес = 6 баллов
(откуда угодно) -> лес -> степь = 6 баллов
И т.д. Как видишь, всё работает: боты будут избегать лес и бегать по степи, пока путь через лес не окажется значительно короче (1 тайл леса вместо 6 тайлов степи). Выдумывать какой-то велосипед здесь нет необходимости.
>вынужден брутфорсом искать id этой точки
Что-то я затупил тогда. Подумал и нашёл несколько решений. И у AStar есть подходящие функции, как раз то, что мне нужно было, я просто невнимательно читал API. Набросал грубый прототип движущихся по дорогам ботов. Медленные по краям дорог - это типа пешеходы, 6 км/ч. Быстрые по серединам - машины, 60 км/ч. Вроде особых проблем не обнаружил и FPS держится выше 60 до 1000 ботов одновременно, при том что они индивидуально сами себя двигают - у каждого внутри подсчёт времени и интерполяция движения. Но есть нюанс: это всё Spatial, а не KinematicBody. Как прикрутить к ним физику? Непонятно. Можно ли навесить KinematicBody на движущийся Spatial? И вообще... нужен ли мне KinematicBody для каждого бота вблизи игрока?.. Может, достаточно будет рейкастов и Area, чтобы они реагировали на воздействия окружающей среды (без этих реакций KinematicBody ощущается как бревно, так зачем он нужен)... Вдали от игрока боты смогут взаимодействовать друг с другом виртуально, находясь в соседних "клетках", тут физика точно не нужна.
>>04734 (Del)
>есть ТЗ
Ясно-понятно, так бы и сказал, что это прихоть заказчика. Всё правильно, за чужие деньги - хоть луну с неба. Я же рассуждал с позиции инди, т.е. независимого разработчика.
>>04781
>Проще считать, что вход в гекс стоит столько-то, выход не стоит ничего
Встроенный AStar так и считает.
https://docs.godotengine.org/en/stable/classes/class_astar.html
>the cost of a path equals the sum of the _compute_cost results of all segments in the path multiplied by the weight_scales of the endpoints of the respective segments
Т.е. если у тебя вход в лес 5 баллов, а вход в степь 1 балл, то:
(откуда угодно) -> степь = 1 балл
(откуда угодно) -> лес = 5 баллов
(откуда угодно) -> степь -> лес = 6 баллов
(откуда угодно) -> лес -> степь = 6 баллов
И т.д. Как видишь, всё работает: боты будут избегать лес и бегать по степи, пока путь через лес не окажется значительно короче (1 тайл леса вместо 6 тайлов степи). Выдумывать какой-то велосипед здесь нет необходимости.
1,4 Мб, webm,640x480, 0:35
>>04700
Что-то я затупил тогда. Подумал и нашёл несколько решений. И у AStar есть подходящие функции, как раз то, что мне нужно было, я просто невнимательно читал API. Набросал грубый прототип движущихся по дорогам ботов. Медленные по краям дорог - это типа пешеходы, 6 км/ч. Быстрые по серединам - машины, 60 км/ч. Вроде особых проблем не обнаружил и FPS держится выше 60 до 1000 ботов одновременно, при том что они индивидуально сами себя двигают - у каждого внутри подсчёт времени и интерполяция движения. Но есть нюанс: это всё Spatial, а не KinematicBody. Как прикрутить к ним физику? Непонятно. Можно ли навесить KinematicBody на движущийся Spatial? И вообще... нужен ли мне KinematicBody для каждого бота вблизи игрока?.. Может, достаточно будет рейкастов и Area, чтобы они реагировали на воздействия окружающей среды (без этих реакций KinematicBody ощущается как бревно, так зачем он нужен)... Вдали от игрока боты смогут взаимодействовать друг с другом виртуально, находясь в соседних "клетках", тут физика точно не нужна.
>>04734 (Del)
Ясно-понятно, так бы и сказал, что это прихоть заказчика. Всё правильно, за чужие деньги - хоть луну с неба. Я же рассуждал с позиции инди, т.е. независимого разработчика.
>>04781
Встроенный AStar так и считает.
https://docs.godotengine.org/en/stable/classes/class_astar.html
Т.е. если у тебя вход в лес 5 баллов, а вход в степь 1 балл, то:
(откуда угодно) -> степь = 1 балл
(откуда угодно) -> лес = 5 баллов
(откуда угодно) -> степь -> лес = 6 баллов
(откуда угодно) -> лес -> степь = 6 баллов
И т.д. Как видишь, всё работает: боты будут избегать лес и бегать по степи, пока путь через лес не окажется значительно короче (1 тайл леса вместо 6 тайлов степи). Выдумывать какой-то велосипед здесь нет необходимости.
>вынужден брутфорсом искать id этой точки
Что-то я затупил тогда. Подумал и нашёл несколько решений. И у AStar есть подходящие функции, как раз то, что мне нужно было, я просто невнимательно читал API. Набросал грубый прототип движущихся по дорогам ботов. Медленные по краям дорог - это типа пешеходы, 6 км/ч. Быстрые по серединам - машины, 60 км/ч. Вроде особых проблем не обнаружил и FPS держится выше 60 до 1000 ботов одновременно, при том что они индивидуально сами себя двигают - у каждого внутри подсчёт времени и интерполяция движения. Но есть нюанс: это всё Spatial, а не KinematicBody. Как прикрутить к ним физику? Непонятно. Можно ли навесить KinematicBody на движущийся Spatial? И вообще... нужен ли мне KinematicBody для каждого бота вблизи игрока?.. Может, достаточно будет рейкастов и Area, чтобы они реагировали на воздействия окружающей среды (без этих реакций KinematicBody ощущается как бревно, так зачем он нужен)... Вдали от игрока боты смогут взаимодействовать друг с другом виртуально, находясь в соседних "клетках", тут физика точно не нужна.
>>04734 (Del)
>есть ТЗ
Ясно-понятно, так бы и сказал, что это прихоть заказчика. Всё правильно, за чужие деньги - хоть луну с неба. Я же рассуждал с позиции инди, т.е. независимого разработчика.
>>04781
>Проще считать, что вход в гекс стоит столько-то, выход не стоит ничего
Встроенный AStar так и считает.
https://docs.godotengine.org/en/stable/classes/class_astar.html
>the cost of a path equals the sum of the _compute_cost results of all segments in the path multiplied by the weight_scales of the endpoints of the respective segments
Т.е. если у тебя вход в лес 5 баллов, а вход в степь 1 балл, то:
(откуда угодно) -> степь = 1 балл
(откуда угодно) -> лес = 5 баллов
(откуда угодно) -> степь -> лес = 6 баллов
(откуда угодно) -> лес -> степь = 6 баллов
И т.д. Как видишь, всё работает: боты будут избегать лес и бегать по степи, пока путь через лес не окажется значительно короче (1 тайл леса вместо 6 тайлов степи). Выдумывать какой-то велосипед здесь нет необходимости.
>>04884
Ну как же не те, если те. Волны, глубина. Всё, что ты реквестируешь.
Ну как же не те, если те. Волны, глубина. Всё, что ты реквестируешь.
>>04892 (Del)
Только не весь астар велосипедить с нуля, а дополнительные утилиты к имеющемуся. Хуан написал только то, что должно работать быстро внутри сишных потрохов. Остальное собери из имеющегося функционала как конструктор. Как сделать вес пути разным в разных направлениях при помощи встроенного астара, тебе уже сказали. Остальное по аналогии. Я ваш спор читал диагонально, надеюсь всё понял правильно.
мимо
> Если нельзя - эта часть пишется самим.
Только не весь астар велосипедить с нуля, а дополнительные утилиты к имеющемуся. Хуан написал только то, что должно работать быстро внутри сишных потрохов. Остальное собери из имеющегося функционала как конструктор. Как сделать вес пути разным в разных направлениях при помощи встроенного астара, тебе уже сказали. Остальное по аналогии. Я ваш спор читал диагонально, надеюсь всё понял правильно.
мимо
>>04958 (Del)
Напиши собственный астар, там делов на пол дня максимум.
Аноны, где находить нормальных художников? Сколько не искал, даже за деньги, двачехудожники ленивое говно, которое и за миллион нормальную картинку не нарисуют.
Напиши собственный астар, там делов на пол дня максимум.
Аноны, где находить нормальных художников? Сколько не искал, даже за деньги, двачехудожники ленивое говно, которое и за миллион нормальную картинку не нарисуют.
>>04892 (Del)
Я говорил в том смысле, что задача поставлена неправильно, но если бы эту задачу ставил заказчик, тут всё понятно, не спорить же с заказчиком о том, что он хочет что-то неправильное. В частности, не нужно вслепую копировать какие-то механики с настольных игр в компьютерные, когда в компьютерных играх можно сделать по-другому - детальнее, быстрее, интереснее. В настольной игре ты ограничен распечатанными фишками, а в компьютерной ты можешь сделать огромный мир из мелких вокселей/тайлов, насколько хватит оперативной памяти.
Навигация у меня, на мой взгляд, сложнее.
1. Сначала ботам нужно найти маршрут в глобальном масштабе, т.е. от тайла 24х24 до другого тайла (точки интереса). Здесь они должны ориентироваться на дороги и не двигаться через лес лишний раз, особенно на машине, тем более не уходить под воду и не лезть на скалы. Я сделал набросок, добавив в AStar только дороги, нужно будет попробовать добавить всё остальное.
2. Затем ботам нужен маршрут в каждом конкретном 24х24 блоке, потому что в некоторых местах движение предпочтительнее (пешеходная дорожка для пешеходов, проезжая часть для автомобилистов) и блок может быть застроен чем-то вплоть до масштаба 1х1 метр (фонарные столбы, деревья, мусорки и т.п.). В теории боты могут одновременно занимать ячейку 1х1, но как это будет на практике я пока не знаю. Конечно, придётся это дело как-то оптимизировать, не делать же сетку 24х24 точек.
3. Наконец, боты должны визуально маневрировать, когда будут видны игроку, и реагировать на воздействия игрока, машин или других ботов, в т.ч. теряя маршрут и выстраивая новый - локальный или глобальный. Короче, как всё это воедино связать - непонятно. Но встроенный AStar должен помочь. Думаю ещё попробовать навмеши, но я не разобрался, в каких ситуациях они нужны и какие у них возможности (помогут обойти движущийся ригидбоди?).
Я как-то так и представлял, хотя видел такие тайлы только в каком-то градостроительном симуляторе без движущихся ботов, там карта строится для красоты. Проблема в том, что такая карта не подходит для нормального перемещения по клеткам, а ты в своём геймдизайне упёрся в идею "двигаться строго по видимым гексам". На практике будет лучше разбить гексы на меньшие части - либо визуально, либо только технически, и затем вычислять перемещение по этим мини-гексам, а не по большим гексам.
>>04958 (Del)
Это потому что у тебя не один гекс, а семь разных мини-гексов внутри одного большого гекса. Визуализация гекса не соответствует его реальным границам - в этом проблема, и работать нужно над её исправлением (перерисовать гексы), а не созданием костылей (какой-то сложный механизм вычисления пути).
Вот, я примерно набросал то, что имею в виду. У тебя 7 мини-гексов в одном большом гексе, и двигаться ты должен по мини-гексам, а не по большим гексам. Также можно полностью отказаться от старых, неудачных гексов и нарисовать новые, ровные, как на второй картинке. Собственно, в компьютерной игре тебя никто не ограничивает и ты можешь сделать сетку гексов настолько мелкой, насколько захочешь, и вообще отказаться от визуального разделения на гексы, оставив их только для навигации ботов. Т.е. проблема в задаче, которую ты сам себе поставил (скопировать чужой неудачный дизайн на другую платформу?).
Ты ж всё равно, судя по всему, пошаговую игру делаешь, тебе не должна быть важна производительность в реальном времени. В любом случае, это выглядит как переусложнённое решение изначально надуманных проблем. Лучше бы беспокоился о том, что ты таким путём игру 10 лет делать будешь, а за это время можно как минимум всё забросить из-за депрессии... особенно когда месяцами отлаживаешь какой-то внутренний инструмент без видимого влияния на геймплей/ощущения игрока от игры. Я сам не люблю глючные и тормозные игры, но они существуют и в них играют...
Если у тебя в массиве все сегменты пути равны одному переходу между двумя соседними тайлами - ты можешь просто возвращать единичку. Потому что расстояние между соседними ячейками равномерной сетки можно считать равным 1 независимо от их формы (у квадратной ячейки 4 соседа, у шестиугольника их 6). То, что делает AStar по умолчанию, предназначено для графов с произвольным расположением узлов в пространстве и, соответственно, произвольной длиной сегментов.
Лол, то есть, по-твоему, поиск пути по вручную расставленным вейпойнтам - это несерьёзно? По-моему так большинство ботов в ААА-играх двигается, от точки к точке. Во всяком случае я видел примеры такого движения. И встроенный AStar предназначен именно для такого движения, как самого популярного.
>Движок - инструмент чтобы обслуживать задачи. Он не должен диктовать что можно и что нельзя. Если нельзя - эта часть пишется самим.
Я говорил в том смысле, что задача поставлена неправильно, но если бы эту задачу ставил заказчик, тут всё понятно, не спорить же с заказчиком о том, что он хочет что-то неправильное. В частности, не нужно вслепую копировать какие-то механики с настольных игр в компьютерные, когда в компьютерных играх можно сделать по-другому - детальнее, быстрее, интереснее. В настольной игре ты ограничен распечатанными фишками, а в компьютерной ты можешь сделать огромный мир из мелких вокселей/тайлов, насколько хватит оперативной памяти.
>У тебя простой пример, у меня сложный.
Навигация у меня, на мой взгляд, сложнее.
1. Сначала ботам нужно найти маршрут в глобальном масштабе, т.е. от тайла 24х24 до другого тайла (точки интереса). Здесь они должны ориентироваться на дороги и не двигаться через лес лишний раз, особенно на машине, тем более не уходить под воду и не лезть на скалы. Я сделал набросок, добавив в AStar только дороги, нужно будет попробовать добавить всё остальное.
2. Затем ботам нужен маршрут в каждом конкретном 24х24 блоке, потому что в некоторых местах движение предпочтительнее (пешеходная дорожка для пешеходов, проезжая часть для автомобилистов) и блок может быть застроен чем-то вплоть до масштаба 1х1 метр (фонарные столбы, деревья, мусорки и т.п.). В теории боты могут одновременно занимать ячейку 1х1, но как это будет на практике я пока не знаю. Конечно, придётся это дело как-то оптимизировать, не делать же сетку 24х24 точек.
3. Наконец, боты должны визуально маневрировать, когда будут видны игроку, и реагировать на воздействия игрока, машин или других ботов, в т.ч. теряя маршрут и выстраивая новый - локальный или глобальный. Короче, как всё это воедино связать - непонятно. Но встроенный AStar должен помочь. Думаю ещё попробовать навмеши, но я не разобрался, в каких ситуациях они нужны и какие у них возможности (помогут обойти движущийся ригидбоди?).
>Вот пример когда один и тот же тайл имеет разную стоимость входа, если идти вдоль дороги, или придти с полей.
Я как-то так и представлял, хотя видел такие тайлы только в каком-то градостроительном симуляторе без движущихся ботов, там карта строится для красоты. Проблема в том, что такая карта не подходит для нормального перемещения по клеткам, а ты в своём геймдизайне упёрся в идею "двигаться строго по видимым гексам". На практике будет лучше разбить гексы на меньшие части - либо визуально, либо только технически, и затем вычислять перемещение по этим мини-гексам, а не по большим гексам.
>>04958 (Del)
>6 дубликатов тайла
Это потому что у тебя не один гекс, а семь разных мини-гексов внутри одного большого гекса. Визуализация гекса не соответствует его реальным границам - в этом проблема, и работать нужно над её исправлением (перерисовать гексы), а не созданием костылей (какой-то сложный механизм вычисления пути).
Вот, я примерно набросал то, что имею в виду. У тебя 7 мини-гексов в одном большом гексе, и двигаться ты должен по мини-гексам, а не по большим гексам. Также можно полностью отказаться от старых, неудачных гексов и нарисовать новые, ровные, как на второй картинке. Собственно, в компьютерной игре тебя никто не ограничивает и ты можешь сделать сетку гексов настолько мелкой, насколько захочешь, и вообще отказаться от визуального разделения на гексы, оставив их только для навигации ботов. Т.е. проблема в задаче, которую ты сам себе поставил (скопировать чужой неудачный дизайн на другую платформу?).
>все это замедлит поиск пути
>писать свой астар на с++
>Что я и делаю.
Ты ж всё равно, судя по всему, пошаговую игру делаешь, тебе не должна быть важна производительность в реальном времени. В любом случае, это выглядит как переусложнённое решение изначально надуманных проблем. Лучше бы беспокоился о том, что ты таким путём игру 10 лет делать будешь, а за это время можно как минимум всё забросить из-за депрессии... особенно когда месяцами отлаживаешь какой-то внутренний инструмент без видимого влияния на геймплей/ощущения игрока от игры. Я сам не люблю глючные и тормозные игры, но они существуют и в них играют...
>for(tile) compute_cost(a, b)
>массив гдскриптом будешь лазить
Если у тебя в массиве все сегменты пути равны одному переходу между двумя соседними тайлами - ты можешь просто возвращать единичку. Потому что расстояние между соседними ячейками равномерной сетки можно считать равным 1 независимо от их формы (у квадратной ячейки 4 соседа, у шестиугольника их 6). То, что делает AStar по умолчанию, предназначено для графов с произвольным расположением узлов в пространстве и, соответственно, произвольной длиной сегментов.
>В простых проектах на геймджемах можно использовать, в более серьезных не получится.
Лол, то есть, по-твоему, поиск пути по вручную расставленным вейпойнтам - это несерьёзно? По-моему так большинство ботов в ААА-играх двигается, от точки к точке. Во всяком случае я видел примеры такого движения. И встроенный AStar предназначен именно для такого движения, как самого популярного.
>>04892 (Del)
Я говорил в том смысле, что задача поставлена неправильно, но если бы эту задачу ставил заказчик, тут всё понятно, не спорить же с заказчиком о том, что он хочет что-то неправильное. В частности, не нужно вслепую копировать какие-то механики с настольных игр в компьютерные, когда в компьютерных играх можно сделать по-другому - детальнее, быстрее, интереснее. В настольной игре ты ограничен распечатанными фишками, а в компьютерной ты можешь сделать огромный мир из мелких вокселей/тайлов, насколько хватит оперативной памяти.
Навигация у меня, на мой взгляд, сложнее.
1. Сначала ботам нужно найти маршрут в глобальном масштабе, т.е. от тайла 24х24 до другого тайла (точки интереса). Здесь они должны ориентироваться на дороги и не двигаться через лес лишний раз, особенно на машине, тем более не уходить под воду и не лезть на скалы. Я сделал набросок, добавив в AStar только дороги, нужно будет попробовать добавить всё остальное.
2. Затем ботам нужен маршрут в каждом конкретном 24х24 блоке, потому что в некоторых местах движение предпочтительнее (пешеходная дорожка для пешеходов, проезжая часть для автомобилистов) и блок может быть застроен чем-то вплоть до масштаба 1х1 метр (фонарные столбы, деревья, мусорки и т.п.). В теории боты могут одновременно занимать ячейку 1х1, но как это будет на практике я пока не знаю. Конечно, придётся это дело как-то оптимизировать, не делать же сетку 24х24 точек.
3. Наконец, боты должны визуально маневрировать, когда будут видны игроку, и реагировать на воздействия игрока, машин или других ботов, в т.ч. теряя маршрут и выстраивая новый - локальный или глобальный. Короче, как всё это воедино связать - непонятно. Но встроенный AStar должен помочь. Думаю ещё попробовать навмеши, но я не разобрался, в каких ситуациях они нужны и какие у них возможности (помогут обойти движущийся ригидбоди?).
Я как-то так и представлял, хотя видел такие тайлы только в каком-то градостроительном симуляторе без движущихся ботов, там карта строится для красоты. Проблема в том, что такая карта не подходит для нормального перемещения по клеткам, а ты в своём геймдизайне упёрся в идею "двигаться строго по видимым гексам". На практике будет лучше разбить гексы на меньшие части - либо визуально, либо только технически, и затем вычислять перемещение по этим мини-гексам, а не по большим гексам.
>>04958 (Del)
Это потому что у тебя не один гекс, а семь разных мини-гексов внутри одного большого гекса. Визуализация гекса не соответствует его реальным границам - в этом проблема, и работать нужно над её исправлением (перерисовать гексы), а не созданием костылей (какой-то сложный механизм вычисления пути).
Вот, я примерно набросал то, что имею в виду. У тебя 7 мини-гексов в одном большом гексе, и двигаться ты должен по мини-гексам, а не по большим гексам. Также можно полностью отказаться от старых, неудачных гексов и нарисовать новые, ровные, как на второй картинке. Собственно, в компьютерной игре тебя никто не ограничивает и ты можешь сделать сетку гексов настолько мелкой, насколько захочешь, и вообще отказаться от визуального разделения на гексы, оставив их только для навигации ботов. Т.е. проблема в задаче, которую ты сам себе поставил (скопировать чужой неудачный дизайн на другую платформу?).
Ты ж всё равно, судя по всему, пошаговую игру делаешь, тебе не должна быть важна производительность в реальном времени. В любом случае, это выглядит как переусложнённое решение изначально надуманных проблем. Лучше бы беспокоился о том, что ты таким путём игру 10 лет делать будешь, а за это время можно как минимум всё забросить из-за депрессии... особенно когда месяцами отлаживаешь какой-то внутренний инструмент без видимого влияния на геймплей/ощущения игрока от игры. Я сам не люблю глючные и тормозные игры, но они существуют и в них играют...
Если у тебя в массиве все сегменты пути равны одному переходу между двумя соседними тайлами - ты можешь просто возвращать единичку. Потому что расстояние между соседними ячейками равномерной сетки можно считать равным 1 независимо от их формы (у квадратной ячейки 4 соседа, у шестиугольника их 6). То, что делает AStar по умолчанию, предназначено для графов с произвольным расположением узлов в пространстве и, соответственно, произвольной длиной сегментов.
Лол, то есть, по-твоему, поиск пути по вручную расставленным вейпойнтам - это несерьёзно? По-моему так большинство ботов в ААА-играх двигается, от точки к точке. Во всяком случае я видел примеры такого движения. И встроенный AStar предназначен именно для такого движения, как самого популярного.
>Движок - инструмент чтобы обслуживать задачи. Он не должен диктовать что можно и что нельзя. Если нельзя - эта часть пишется самим.
Я говорил в том смысле, что задача поставлена неправильно, но если бы эту задачу ставил заказчик, тут всё понятно, не спорить же с заказчиком о том, что он хочет что-то неправильное. В частности, не нужно вслепую копировать какие-то механики с настольных игр в компьютерные, когда в компьютерных играх можно сделать по-другому - детальнее, быстрее, интереснее. В настольной игре ты ограничен распечатанными фишками, а в компьютерной ты можешь сделать огромный мир из мелких вокселей/тайлов, насколько хватит оперативной памяти.
>У тебя простой пример, у меня сложный.
Навигация у меня, на мой взгляд, сложнее.
1. Сначала ботам нужно найти маршрут в глобальном масштабе, т.е. от тайла 24х24 до другого тайла (точки интереса). Здесь они должны ориентироваться на дороги и не двигаться через лес лишний раз, особенно на машине, тем более не уходить под воду и не лезть на скалы. Я сделал набросок, добавив в AStar только дороги, нужно будет попробовать добавить всё остальное.
2. Затем ботам нужен маршрут в каждом конкретном 24х24 блоке, потому что в некоторых местах движение предпочтительнее (пешеходная дорожка для пешеходов, проезжая часть для автомобилистов) и блок может быть застроен чем-то вплоть до масштаба 1х1 метр (фонарные столбы, деревья, мусорки и т.п.). В теории боты могут одновременно занимать ячейку 1х1, но как это будет на практике я пока не знаю. Конечно, придётся это дело как-то оптимизировать, не делать же сетку 24х24 точек.
3. Наконец, боты должны визуально маневрировать, когда будут видны игроку, и реагировать на воздействия игрока, машин или других ботов, в т.ч. теряя маршрут и выстраивая новый - локальный или глобальный. Короче, как всё это воедино связать - непонятно. Но встроенный AStar должен помочь. Думаю ещё попробовать навмеши, но я не разобрался, в каких ситуациях они нужны и какие у них возможности (помогут обойти движущийся ригидбоди?).
>Вот пример когда один и тот же тайл имеет разную стоимость входа, если идти вдоль дороги, или придти с полей.
Я как-то так и представлял, хотя видел такие тайлы только в каком-то градостроительном симуляторе без движущихся ботов, там карта строится для красоты. Проблема в том, что такая карта не подходит для нормального перемещения по клеткам, а ты в своём геймдизайне упёрся в идею "двигаться строго по видимым гексам". На практике будет лучше разбить гексы на меньшие части - либо визуально, либо только технически, и затем вычислять перемещение по этим мини-гексам, а не по большим гексам.
>>04958 (Del)
>6 дубликатов тайла
Это потому что у тебя не один гекс, а семь разных мини-гексов внутри одного большого гекса. Визуализация гекса не соответствует его реальным границам - в этом проблема, и работать нужно над её исправлением (перерисовать гексы), а не созданием костылей (какой-то сложный механизм вычисления пути).
Вот, я примерно набросал то, что имею в виду. У тебя 7 мини-гексов в одном большом гексе, и двигаться ты должен по мини-гексам, а не по большим гексам. Также можно полностью отказаться от старых, неудачных гексов и нарисовать новые, ровные, как на второй картинке. Собственно, в компьютерной игре тебя никто не ограничивает и ты можешь сделать сетку гексов настолько мелкой, насколько захочешь, и вообще отказаться от визуального разделения на гексы, оставив их только для навигации ботов. Т.е. проблема в задаче, которую ты сам себе поставил (скопировать чужой неудачный дизайн на другую платформу?).
>все это замедлит поиск пути
>писать свой астар на с++
>Что я и делаю.
Ты ж всё равно, судя по всему, пошаговую игру делаешь, тебе не должна быть важна производительность в реальном времени. В любом случае, это выглядит как переусложнённое решение изначально надуманных проблем. Лучше бы беспокоился о том, что ты таким путём игру 10 лет делать будешь, а за это время можно как минимум всё забросить из-за депрессии... особенно когда месяцами отлаживаешь какой-то внутренний инструмент без видимого влияния на геймплей/ощущения игрока от игры. Я сам не люблю глючные и тормозные игры, но они существуют и в них играют...
>for(tile) compute_cost(a, b)
>массив гдскриптом будешь лазить
Если у тебя в массиве все сегменты пути равны одному переходу между двумя соседними тайлами - ты можешь просто возвращать единичку. Потому что расстояние между соседними ячейками равномерной сетки можно считать равным 1 независимо от их формы (у квадратной ячейки 4 соседа, у шестиугольника их 6). То, что делает AStar по умолчанию, предназначено для графов с произвольным расположением узлов в пространстве и, соответственно, произвольной длиной сегментов.
>В простых проектах на геймджемах можно использовать, в более серьезных не получится.
Лол, то есть, по-твоему, поиск пути по вручную расставленным вейпойнтам - это несерьёзно? По-моему так большинство ботов в ААА-играх двигается, от точки к точке. Во всяком случае я видел примеры такого движения. И встроенный AStar предназначен именно для такого движения, как самого популярного.
223 Кб, 725x666>>04892 (Del)
Нашёл полную версию твоей картинки. Вот, куда лучше будет выбрать меньший размер гексагона и разбить карту на них, чем использовать то, что нарисовано для настольной игры. Большие гексагоны делают, скорее всего, для удобства игроков в настольных играх - маленькие гексы было бы неудобно перемещать и легко потерять. Но мы-то здесь компьютерные игры делаем, и можем сделать гексы практически любого размера. В худшем случае придётся оптимизировать, уменьшая область видимости (количество отображаемых на экране чанков).
И вообще, тайлы/гексы - это тоже инструмент. Инструмент деления карты на клетки. Проблема в том, что ты неправильно разделил свою карту на клетки или пытаешься скопировать неправильно поделённую на клетки чужую карту.
>>04994 (Del)
Так если задача глупая, зачем её решать?
У рёбер вес равен расстоянию между узлами (длине ребра), а вес узлов можно и не назначать вообще (по умолчанию он равен 1).
Как будто ты делаешь стратегию в реальном времени, где 10 тысяч юнитов будут независимо друг от друга искать пути.
Ну да... Я бы лично пошёл по прямой вверх и потом по прямой вправо, потому что идти лесенкой = делать лишние повороты (нажатия клавиш). Но от AStar в общем случае никто не ожидает "натуральный путь", он не для этого предназначен. А чисто формально, путь на картинке той же длины, что и путь "прямо вверх и прямо направо".
>Вот пример
Нашёл полную версию твоей картинки. Вот, куда лучше будет выбрать меньший размер гексагона и разбить карту на них, чем использовать то, что нарисовано для настольной игры. Большие гексагоны делают, скорее всего, для удобства игроков в настольных играх - маленькие гексы было бы неудобно перемещать и легко потерять. Но мы-то здесь компьютерные игры делаем, и можем сделать гексы практически любого размера. В худшем случае придётся оптимизировать, уменьшая область видимости (количество отображаемых на экране чанков).
И вообще, тайлы/гексы - это тоже инструмент. Инструмент деления карты на клетки. Проблема в том, что ты неправильно разделил свою карту на клетки или пытаешься скопировать неправильно поделённую на клетки чужую карту.
>>04994 (Del)
>подгонять задачу
Так если задача глупая, зачем её решать?
>назначает вес узлам, а не ребрам в графе
У рёбер вес равен расстоянию между узлами (длине ребра), а вес узлов можно и не назначать вообще (по умолчанию он равен 1).
>коллбек в гдскрипт
Как будто ты делаешь стратегию в реальном времени, где 10 тысяч юнитов будут независимо друг от друга искать пути.
>ненатуральный путь (пикрил)
Ну да... Я бы лично пошёл по прямой вверх и потом по прямой вправо, потому что идти лесенкой = делать лишние повороты (нажатия клавиш). Но от AStar в общем случае никто не ожидает "натуральный путь", он не для этого предназначен. А чисто формально, путь на картинке той же длины, что и путь "прямо вверх и прямо направо".
>>04994 (Del)
Я раньше тоже думал, что point в линейной алгебре, описываемая двумя координатами, это точка. Но это вектор. А значит point, это ребро, проведённое из центра координат, к координатам, указанным в её параметрах типа vector. Оказывается, у "точек" астара, которые мы задаём типом Vector есть, блеать, длина! Нихуя себе! Длина, у точки! Охуеть просто!
> Проблема в неправильном АПИ годота, который назначает вес узлам, а не ребрам в графе! Если открыть хотя бы википедию, там говорится про edge weights!
Я раньше тоже думал, что point в линейной алгебре, описываемая двумя координатами, это точка. Но это вектор. А значит point, это ребро, проведённое из центра координат, к координатам, указанным в её параметрах типа vector. Оказывается, у "точек" астара, которые мы задаём типом Vector есть, блеать, длина! Нихуя себе! Длина, у точки! Охуеть просто!
>>04997 (Del)
Я тебе предложил, что можно визуальные гексы оставить такие какие есть, а путь считать по скрытым, "техническим" гексам. Для игрока всё равно без разницы, как там оно внутри устроено, ему главное красивую картинку видеть, правильно?
Можно, и очень легко - понадобятся только встроенные инструменты. Я даже в детстве во что-то такое настольное играл. Кидаешь кубики, двигатешь фишечку с клетки на клетку, кто первым до финиша добрался - тот молодец, вот и вся игра. Если не считать рисования карты в каком-нибудь пейнте, такую игру можно за несколько часов на Godot сделать, и производительность будет наилучшая. Да в такой игре и поиск пути не нужен...
Есть же, тебе вон даже в официальной документации показали. Да, будет не супер быстро, но всё же АПИ имеется. Godot вообще официально не "скоростной" движок, а, скорее, движок для детей, в который легко вкатиться любому школьнику. Правильнее было бы считать Godot конструктором игр (как Game Maker), а не движком...
Не я это писал, но, я думаю, тот анон имел в виду свой астар целиком на GDScript. Здесь мало кто на C++ пишет, ведь на Godot приходят для лёгкой и быстрой разработки, а не чтобы байтики в 2D пошаговой игре считать. Со знаниями C++ ты мог бы свой собственный движок сделать, тем более что у тебя 2D игра.
Кстати, на пикриле Stardew Valley, сильно нашумевшая в своё время инди игра, которую все только и делают, что хвалят. Но поиск пути в мобильной версии просто говно какое-то. Персонаж очень часто пытается выбрать САМЫЙ ДЛИННЫЙ путь из всех возможных, обходя по кругу препятствия, до которых вообще не нужно было доходить. Это просто нереально бесит, когда персонаж в сотый раз рвётся топать по кругу, учитывая, что игровой день длится всего минут десять реального времени, большинство событий привязано к определённому промежутку дня, а в конце дня персонаж теряет сознание и просыпается утром в кровати. Пофиг на твои лесенки, не лесенки - какая разница? Главное чтобы путь был технически самым коротким/оптимальным, а как оно выглядит - дело десятое. И, тем не менее, даже с таким отвратительным поиском пути я и многие другие игроки продолжают играть в эту игру (наиграл уже почти 100 часов в этой глючной мобильной версии и планирую играть ещё).
Так что ты фокусируешься на том, что имеет мало значения для игрока. Нет смысла вылизывать такие детали. Сделай просто весёлую игру, в которой будут пропадать люди по 100+ часов, а что там поиск пути не очень быстрый и не очень плавные линии рисует - это пустяки, на самом деле.
>Игры есть такие, а есть такие
Я тебе предложил, что можно визуальные гексы оставить такие какие есть, а путь считать по скрытым, "техническим" гексам. Для игрока всё равно без разницы, как там оно внутри устроено, ему главное красивую картинку видеть, правильно?
>на годоте по сути нельзя сделать простейшую настолку
Можно, и очень легко - понадобятся только встроенные инструменты. Я даже в детстве во что-то такое настольное играл. Кидаешь кубики, двигатешь фишечку с клетки на клетку, кто первым до финиша добрался - тот молодец, вот и вся игра. Если не считать рисования карты в каком-нибудь пейнте, такую игру можно за несколько часов на Godot сделать, и производительность будет наилучшая. Да в такой игре и поиск пути не нужен...
>нет АПИ для назначения веса ребер
Есть же, тебе вон даже в официальной документации показали. Да, будет не супер быстро, но всё же АПИ имеется. Godot вообще официально не "скоростной" движок, а, скорее, движок для детей, в который легко вкатиться любому школьнику. Правильнее было бы считать Godot конструктором игр (как Game Maker), а не движком...
>быстрее чем свой астар - это не так
Не я это писал, но, я думаю, тот анон имел в виду свой астар целиком на GDScript. Здесь мало кто на C++ пишет, ведь на Godot приходят для лёгкой и быстрой разработки, а не чтобы байтики в 2D пошаговой игре считать. Со знаниями C++ ты мог бы свой собственный движок сделать, тем более что у тебя 2D игра.
>получать натуральный путь
>игроку неважно астар там или не астар
Кстати, на пикриле Stardew Valley, сильно нашумевшая в своё время инди игра, которую все только и делают, что хвалят. Но поиск пути в мобильной версии просто говно какое-то. Персонаж очень часто пытается выбрать САМЫЙ ДЛИННЫЙ путь из всех возможных, обходя по кругу препятствия, до которых вообще не нужно было доходить. Это просто нереально бесит, когда персонаж в сотый раз рвётся топать по кругу, учитывая, что игровой день длится всего минут десять реального времени, большинство событий привязано к определённому промежутку дня, а в конце дня персонаж теряет сознание и просыпается утром в кровати. Пофиг на твои лесенки, не лесенки - какая разница? Главное чтобы путь был технически самым коротким/оптимальным, а как оно выглядит - дело десятое. И, тем не менее, даже с таким отвратительным поиском пути я и многие другие игроки продолжают играть в эту игру (наиграл уже почти 100 часов в этой глючной мобильной версии и планирую играть ещё).
Так что ты фокусируешься на том, что имеет мало значения для игрока. Нет смысла вылизывать такие детали. Сделай просто весёлую игру, в которой будут пропадать люди по 100+ часов, а что там поиск пути не очень быстрый и не очень плавные линии рисует - это пустяки, на самом деле.
>>04997 (Del)
Я тебе предложил, что можно визуальные гексы оставить такие какие есть, а путь считать по скрытым, "техническим" гексам. Для игрока всё равно без разницы, как там оно внутри устроено, ему главное красивую картинку видеть, правильно?
Можно, и очень легко - понадобятся только встроенные инструменты. Я даже в детстве во что-то такое настольное играл. Кидаешь кубики, двигатешь фишечку с клетки на клетку, кто первым до финиша добрался - тот молодец, вот и вся игра. Если не считать рисования карты в каком-нибудь пейнте, такую игру можно за несколько часов на Godot сделать, и производительность будет наилучшая. Да в такой игре и поиск пути не нужен...
Есть же, тебе вон даже в официальной документации показали. Да, будет не супер быстро, но всё же АПИ имеется. Godot вообще официально не "скоростной" движок, а, скорее, движок для детей, в который легко вкатиться любому школьнику. Правильнее было бы считать Godot конструктором игр (как Game Maker), а не движком...
Не я это писал, но, я думаю, тот анон имел в виду свой астар целиком на GDScript. Здесь мало кто на C++ пишет, ведь на Godot приходят для лёгкой и быстрой разработки, а не чтобы байтики в 2D пошаговой игре считать. Со знаниями C++ ты мог бы свой собственный движок сделать, тем более что у тебя 2D игра.
Кстати, на пикриле Stardew Valley, сильно нашумевшая в своё время инди игра, которую все только и делают, что хвалят. Но поиск пути в мобильной версии просто говно какое-то. Персонаж очень часто пытается выбрать САМЫЙ ДЛИННЫЙ путь из всех возможных, обходя по кругу препятствия, до которых вообще не нужно было доходить. Это просто нереально бесит, когда персонаж в сотый раз рвётся топать по кругу, учитывая, что игровой день длится всего минут десять реального времени, большинство событий привязано к определённому промежутку дня, а в конце дня персонаж теряет сознание и просыпается утром в кровати. Пофиг на твои лесенки, не лесенки - какая разница? Главное чтобы путь был технически самым коротким/оптимальным, а как оно выглядит - дело десятое. И, тем не менее, даже с таким отвратительным поиском пути я и многие другие игроки продолжают играть в эту игру (наиграл уже почти 100 часов в этой глючной мобильной версии и планирую играть ещё).
Так что ты фокусируешься на том, что имеет мало значения для игрока. Нет смысла вылизывать такие детали. Сделай просто весёлую игру, в которой будут пропадать люди по 100+ часов, а что там поиск пути не очень быстрый и не очень плавные линии рисует - это пустяки, на самом деле.
>Игры есть такие, а есть такие
Я тебе предложил, что можно визуальные гексы оставить такие какие есть, а путь считать по скрытым, "техническим" гексам. Для игрока всё равно без разницы, как там оно внутри устроено, ему главное красивую картинку видеть, правильно?
>на годоте по сути нельзя сделать простейшую настолку
Можно, и очень легко - понадобятся только встроенные инструменты. Я даже в детстве во что-то такое настольное играл. Кидаешь кубики, двигатешь фишечку с клетки на клетку, кто первым до финиша добрался - тот молодец, вот и вся игра. Если не считать рисования карты в каком-нибудь пейнте, такую игру можно за несколько часов на Godot сделать, и производительность будет наилучшая. Да в такой игре и поиск пути не нужен...
>нет АПИ для назначения веса ребер
Есть же, тебе вон даже в официальной документации показали. Да, будет не супер быстро, но всё же АПИ имеется. Godot вообще официально не "скоростной" движок, а, скорее, движок для детей, в который легко вкатиться любому школьнику. Правильнее было бы считать Godot конструктором игр (как Game Maker), а не движком...
>быстрее чем свой астар - это не так
Не я это писал, но, я думаю, тот анон имел в виду свой астар целиком на GDScript. Здесь мало кто на C++ пишет, ведь на Godot приходят для лёгкой и быстрой разработки, а не чтобы байтики в 2D пошаговой игре считать. Со знаниями C++ ты мог бы свой собственный движок сделать, тем более что у тебя 2D игра.
>получать натуральный путь
>игроку неважно астар там или не астар
Кстати, на пикриле Stardew Valley, сильно нашумевшая в своё время инди игра, которую все только и делают, что хвалят. Но поиск пути в мобильной версии просто говно какое-то. Персонаж очень часто пытается выбрать САМЫЙ ДЛИННЫЙ путь из всех возможных, обходя по кругу препятствия, до которых вообще не нужно было доходить. Это просто нереально бесит, когда персонаж в сотый раз рвётся топать по кругу, учитывая, что игровой день длится всего минут десять реального времени, большинство событий привязано к определённому промежутку дня, а в конце дня персонаж теряет сознание и просыпается утром в кровати. Пофиг на твои лесенки, не лесенки - какая разница? Главное чтобы путь был технически самым коротким/оптимальным, а как оно выглядит - дело десятое. И, тем не менее, даже с таким отвратительным поиском пути я и многие другие игроки продолжают играть в эту игру (наиграл уже почти 100 часов в этой глючной мобильной версии и планирую играть ещё).
Так что ты фокусируешься на том, что имеет мало значения для игрока. Нет смысла вылизывать такие детали. Сделай просто весёлую игру, в которой будут пропадать люди по 100+ часов, а что там поиск пути не очень быстрый и не очень плавные линии рисует - это пустяки, на самом деле.
>>05002 (Del)
Ты ещё не понял. Перечитывай, пока не дойдёт.
Ты ещё не понял. Перечитывай, пока не дойдёт.
>>05006 (Del)
Читай дальше. Что делает дистанс ту?
Читай дальше. Что делает дистанс ту?
>>05006 (Del)
И собсна говоря, что такое "расстояние между двумя точками"?
И собсна говоря, что такое "расстояние между двумя точками"?
838 Кб, 960x720>>05012 (Del)
Ну ты и баран, блять.
Ну ты и баран, блять.
>>05015 (Del)
Не знает школьную алгебру кто-то другой из нас, тот, у кого узлы массива для астара по его мнению описывают узлы графа, а не рёбра.
> ты не знаешь школьную алгебру
Не знает школьную алгебру кто-то другой из нас, тот, у кого узлы массива для астара по его мнению описывают узлы графа, а не рёбра.
>>05020 (Del)
Вот ты и спалился, движкосрачер. Репорт!
> Добавлю что ты продолжаешь нести дефрагментаторскую шизу.
Вот ты и спалился, движкосрачер. Репорт!
>>05005 (Del)
Ты сам сказал "даже простейшую настолку".
Нет там никаких "алмазиков". И стора тоже никакого нет. И даже время бесконечное, можно жить тысячи игровых лет без последствий для геймплея и сюжета - нет необходимости выжимать из каждого дня максимум возможностей. Так что это просто баг или быдлокод. Кое-как работает - и ладно, просто приходится чаще тыкать перед персонажем или строго по прямой, чтоб не сворачивал. Главное что остальной геймплей в порядке... не считая пары багов, когда игра зависает или крашится...
Я думаю, этому есть причина. Моё предположение: AStar делали с рассчётом на 2D/3D карты в экшн играх вроде шутеров. В такого рода играх длина ребра графа определяется математически простой функцией vector.distance_to(vector). Нет совершенно никакого смысла делать кастомную длину ребра в типичной экшн 2D/3D игре. А вот вес узла имеет большое значение. К примеру, в шутере открытое хорошо простреливаемое пространство должно иметь высокий вес узла, потому что бот не должен лишний раз подставлять себя под огонь противника. В каком бы направлении бот ни двигался по открытой местности, он в любом случае подставляет себя под огонь. Другой пример, болотистая местность в РПГ может замедлять всех мобов, следовательно, её вес тоже должен быть выше, чем у обычной дороги. Мобы замедляются в болоте, в каком бы направлении они ни шли. Ещё пример, в какой-нибудь игре часть карты может быть покрыта льдом, который легко разрушится под ногами персонажа, но только через несколько секунд, т.е. можно успеть пройти. Но проход этот одноразовый. Следовательно, нужно искать в первую очередь более надёжные пути - мосты, тропинки и т.д., а у узлов льда должен быть высокий вес, и этот вес влияет на движение в любом направлении, потому что лёд обрушится независимо от направления движения.
Проще говоря, в абсолютном большинстве игр тебе нет никакой необходимости вручную выставлять вес рёбер, поскольку он автоматически вычисляется на уровне школьной геометрии, но очень часто необходимо регулировать вес узлов (зон, точек интереса), чтобы ограничить движение через них в пользу других узлов.
С другой стороны, ты не один такой, вот предложение с декабря 2019 года висит, один комментарий, три лайка:
https://github.com/godotengine/godot-proposals/issues/334
Вот только это предложение ломает обратную совместимость со всеми вышеописанными играми, коих большинство. Разве что добавить какой-то переключатель, чтобы регулировать режим работы AStar, или запилить отдельный класс AStarBDSM - специально для любителей натягивать верёвки между узлами потуже, ЕВПОЧЯ)))
>Демагогию разводишь
Ты сам сказал "даже простейшую настолку".
>игрок проебывал день и шел в стор покупать алмазики
Нет там никаких "алмазиков". И стора тоже никакого нет. И даже время бесконечное, можно жить тысячи игровых лет без последствий для геймплея и сюжета - нет необходимости выжимать из каждого дня максимум возможностей. Так что это просто баг или быдлокод. Кое-как работает - и ладно, просто приходится чаще тыкать перед персонажем или строго по прямой, чтоб не сворачивал. Главное что остальной геймплей в порядке... не считая пары багов, когда игра зависает или крашится...
>Просто в годот забыли добавить.
Я думаю, этому есть причина. Моё предположение: AStar делали с рассчётом на 2D/3D карты в экшн играх вроде шутеров. В такого рода играх длина ребра графа определяется математически простой функцией vector.distance_to(vector). Нет совершенно никакого смысла делать кастомную длину ребра в типичной экшн 2D/3D игре. А вот вес узла имеет большое значение. К примеру, в шутере открытое хорошо простреливаемое пространство должно иметь высокий вес узла, потому что бот не должен лишний раз подставлять себя под огонь противника. В каком бы направлении бот ни двигался по открытой местности, он в любом случае подставляет себя под огонь. Другой пример, болотистая местность в РПГ может замедлять всех мобов, следовательно, её вес тоже должен быть выше, чем у обычной дороги. Мобы замедляются в болоте, в каком бы направлении они ни шли. Ещё пример, в какой-нибудь игре часть карты может быть покрыта льдом, который легко разрушится под ногами персонажа, но только через несколько секунд, т.е. можно успеть пройти. Но проход этот одноразовый. Следовательно, нужно искать в первую очередь более надёжные пути - мосты, тропинки и т.д., а у узлов льда должен быть высокий вес, и этот вес влияет на движение в любом направлении, потому что лёд обрушится независимо от направления движения.
Проще говоря, в абсолютном большинстве игр тебе нет никакой необходимости вручную выставлять вес рёбер, поскольку он автоматически вычисляется на уровне школьной геометрии, но очень часто необходимо регулировать вес узлов (зон, точек интереса), чтобы ограничить движение через них в пользу других узлов.
С другой стороны, ты не один такой, вот предложение с декабря 2019 года висит, один комментарий, три лайка:
https://github.com/godotengine/godot-proposals/issues/334
Вот только это предложение ломает обратную совместимость со всеми вышеописанными играми, коих большинство. Разве что добавить какой-то переключатель, чтобы регулировать режим работы AStar, или запилить отдельный класс AStarBDSM - специально для любителей натягивать верёвки между узлами потуже, ЕВПОЧЯ)))
>>05005 (Del)
Ты сам сказал "даже простейшую настолку".
Нет там никаких "алмазиков". И стора тоже никакого нет. И даже время бесконечное, можно жить тысячи игровых лет без последствий для геймплея и сюжета - нет необходимости выжимать из каждого дня максимум возможностей. Так что это просто баг или быдлокод. Кое-как работает - и ладно, просто приходится чаще тыкать перед персонажем или строго по прямой, чтоб не сворачивал. Главное что остальной геймплей в порядке... не считая пары багов, когда игра зависает или крашится...
Я думаю, этому есть причина. Моё предположение: AStar делали с рассчётом на 2D/3D карты в экшн играх вроде шутеров. В такого рода играх длина ребра графа определяется математически простой функцией vector.distance_to(vector). Нет совершенно никакого смысла делать кастомную длину ребра в типичной экшн 2D/3D игре. А вот вес узла имеет большое значение. К примеру, в шутере открытое хорошо простреливаемое пространство должно иметь высокий вес узла, потому что бот не должен лишний раз подставлять себя под огонь противника. В каком бы направлении бот ни двигался по открытой местности, он в любом случае подставляет себя под огонь. Другой пример, болотистая местность в РПГ может замедлять всех мобов, следовательно, её вес тоже должен быть выше, чем у обычной дороги. Мобы замедляются в болоте, в каком бы направлении они ни шли. Ещё пример, в какой-нибудь игре часть карты может быть покрыта льдом, который легко разрушится под ногами персонажа, но только через несколько секунд, т.е. можно успеть пройти. Но проход этот одноразовый. Следовательно, нужно искать в первую очередь более надёжные пути - мосты, тропинки и т.д., а у узлов льда должен быть высокий вес, и этот вес влияет на движение в любом направлении, потому что лёд обрушится независимо от направления движения.
Проще говоря, в абсолютном большинстве игр тебе нет никакой необходимости вручную выставлять вес рёбер, поскольку он автоматически вычисляется на уровне школьной геометрии, но очень часто необходимо регулировать вес узлов (зон, точек интереса), чтобы ограничить движение через них в пользу других узлов.
С другой стороны, ты не один такой, вот предложение с декабря 2019 года висит, один комментарий, три лайка:
https://github.com/godotengine/godot-proposals/issues/334
Вот только это предложение ломает обратную совместимость со всеми вышеописанными играми, коих большинство. Разве что добавить какой-то переключатель, чтобы регулировать режим работы AStar, или запилить отдельный класс AStarBDSM - специально для любителей натягивать верёвки между узлами потуже, ЕВПОЧЯ)))
>Демагогию разводишь
Ты сам сказал "даже простейшую настолку".
>игрок проебывал день и шел в стор покупать алмазики
Нет там никаких "алмазиков". И стора тоже никакого нет. И даже время бесконечное, можно жить тысячи игровых лет без последствий для геймплея и сюжета - нет необходимости выжимать из каждого дня максимум возможностей. Так что это просто баг или быдлокод. Кое-как работает - и ладно, просто приходится чаще тыкать перед персонажем или строго по прямой, чтоб не сворачивал. Главное что остальной геймплей в порядке... не считая пары багов, когда игра зависает или крашится...
>Просто в годот забыли добавить.
Я думаю, этому есть причина. Моё предположение: AStar делали с рассчётом на 2D/3D карты в экшн играх вроде шутеров. В такого рода играх длина ребра графа определяется математически простой функцией vector.distance_to(vector). Нет совершенно никакого смысла делать кастомную длину ребра в типичной экшн 2D/3D игре. А вот вес узла имеет большое значение. К примеру, в шутере открытое хорошо простреливаемое пространство должно иметь высокий вес узла, потому что бот не должен лишний раз подставлять себя под огонь противника. В каком бы направлении бот ни двигался по открытой местности, он в любом случае подставляет себя под огонь. Другой пример, болотистая местность в РПГ может замедлять всех мобов, следовательно, её вес тоже должен быть выше, чем у обычной дороги. Мобы замедляются в болоте, в каком бы направлении они ни шли. Ещё пример, в какой-нибудь игре часть карты может быть покрыта льдом, который легко разрушится под ногами персонажа, но только через несколько секунд, т.е. можно успеть пройти. Но проход этот одноразовый. Следовательно, нужно искать в первую очередь более надёжные пути - мосты, тропинки и т.д., а у узлов льда должен быть высокий вес, и этот вес влияет на движение в любом направлении, потому что лёд обрушится независимо от направления движения.
Проще говоря, в абсолютном большинстве игр тебе нет никакой необходимости вручную выставлять вес рёбер, поскольку он автоматически вычисляется на уровне школьной геометрии, но очень часто необходимо регулировать вес узлов (зон, точек интереса), чтобы ограничить движение через них в пользу других узлов.
С другой стороны, ты не один такой, вот предложение с декабря 2019 года висит, один комментарий, три лайка:
https://github.com/godotengine/godot-proposals/issues/334
Вот только это предложение ломает обратную совместимость со всеми вышеописанными играми, коих большинство. Разве что добавить какой-то переключатель, чтобы регулировать режим работы AStar, или запилить отдельный класс AStarBDSM - специально для любителей натягивать верёвки между узлами потуже, ЕВПОЧЯ)))
>>04888
Забыл запостить. Ещё прошлой ночью немного доработал тестовую сцену в визуальном плане. А именно: жители движутся по 4 линиям, в зависимости от линии используют базовую модельку или модельку с тестовой машинкой, разворачиваются в направлении движения (look_at()). Зачем я это делаю, если всё равно потом переделывать? Во-первых, хочется оценить предел того, сколько таких подвижных сущностей я смогу иметь на экране, ведь KinematicBody уже меня подвёл. Во-вторых, хочется прикинуть, сколько мне вообще нужно подвижных сущностей на экране от первого лица, а сколько может оставаться в скрытом состоянии. В-третьих, просто чтобы оценить ощущения от будущей игры/геймплея: одно дело кататься на машинках по городу в ГТА/чужой игре, другое - делать игру с похожим геймплеем самому, имея крайне ограниченные ресурсы. Скажем, меня всегда раздражали кривые дороги и мосты в ГТА, и мне хотелось бы сделать интересную игру с квадратной планировкой дорог, но я сомневаюсь, что это возможно (видел подобные ассетфлипы на юнити - вообще не впечатлило).
Что по видео:
1. 500 жителей с "машинами" (только моделька корпуса, без VehicleBody). FPS сильно скачет из-за того, что при некоторых ракурсах рисуются все эти ~750 моделек. Перед этим тестовая моделька персонажа была из отдельных кубиков, и всё было ещё хуже - специально склеил в один меш для этих тестов. Правда, полноценная модель персонажа будет из нескольких мешей...
2. 300 жителей вечером с фарами. FPS резко снизился из-за того, что на каждой машине по 4 дополнительных MeshInstance, и всего источников света получается минимум 301. Но меня интересовало тут взаимодействие источников света. Выглядит прикольно.
3. 100 жителей и машины замедленны. Тут я осознал, что изначальная скорость взята слишком большой, я эти модельки машин догнать не могу даже увеличив мощность двигателя VehicleBody. Да и вообще я не гонки делаю, мне хочется более размеренный геймплей. Чтоб никто никуда не торопился. Вот на этом видео уже что-то более-менее близкое тому, что хотелось бы видеть в игре, в плане скорости и плотности населения. Думаю, будет даже медленнее и с меньшим числом автовладельцев, лол. Я ж ещё автобусы хочу добавить, полностью юзабельные для всех жителей. И в целом рассчёт на то, что будет приятно проводить время в дороге даже пешком, а не как в большинстве других ГТА-лайк игр - скорей-скорей через всю карту, игнорируя всё на своём пути, ведь ничего кроме пустых статичных коробок там нет. У меня-то планируется живой мир и домики полноценные, минимальное количество статичных декораций, даже деревья в будущем хочется сделать динамически растущими, сейчас просто заглушка/макет для тестов.
Интересно: в какой-то момент заметил, что FPS падал в разы при движениях мыши. Профайлер показал, что движение мыши вызывает 2500+ вызовов _input() в моих 500 Spatial. В них я всего лишь переключал скорость движения (чтоб временно всех ускорить). Оказалось, нужно было использовать _unhandled_input(), чтобы боты не регистрировали события, которые предназначены игроку. Почему-то раньше не натыкался на объяснение необходимости этой функции и лепил везде _input(), даже зная о существовании альтернатив.
Забыл запостить. Ещё прошлой ночью немного доработал тестовую сцену в визуальном плане. А именно: жители движутся по 4 линиям, в зависимости от линии используют базовую модельку или модельку с тестовой машинкой, разворачиваются в направлении движения (look_at()). Зачем я это делаю, если всё равно потом переделывать? Во-первых, хочется оценить предел того, сколько таких подвижных сущностей я смогу иметь на экране, ведь KinematicBody уже меня подвёл. Во-вторых, хочется прикинуть, сколько мне вообще нужно подвижных сущностей на экране от первого лица, а сколько может оставаться в скрытом состоянии. В-третьих, просто чтобы оценить ощущения от будущей игры/геймплея: одно дело кататься на машинках по городу в ГТА/чужой игре, другое - делать игру с похожим геймплеем самому, имея крайне ограниченные ресурсы. Скажем, меня всегда раздражали кривые дороги и мосты в ГТА, и мне хотелось бы сделать интересную игру с квадратной планировкой дорог, но я сомневаюсь, что это возможно (видел подобные ассетфлипы на юнити - вообще не впечатлило).
Что по видео:
1. 500 жителей с "машинами" (только моделька корпуса, без VehicleBody). FPS сильно скачет из-за того, что при некоторых ракурсах рисуются все эти ~750 моделек. Перед этим тестовая моделька персонажа была из отдельных кубиков, и всё было ещё хуже - специально склеил в один меш для этих тестов. Правда, полноценная модель персонажа будет из нескольких мешей...
2. 300 жителей вечером с фарами. FPS резко снизился из-за того, что на каждой машине по 4 дополнительных MeshInstance, и всего источников света получается минимум 301. Но меня интересовало тут взаимодействие источников света. Выглядит прикольно.
3. 100 жителей и машины замедленны. Тут я осознал, что изначальная скорость взята слишком большой, я эти модельки машин догнать не могу даже увеличив мощность двигателя VehicleBody. Да и вообще я не гонки делаю, мне хочется более размеренный геймплей. Чтоб никто никуда не торопился. Вот на этом видео уже что-то более-менее близкое тому, что хотелось бы видеть в игре, в плане скорости и плотности населения. Думаю, будет даже медленнее и с меньшим числом автовладельцев, лол. Я ж ещё автобусы хочу добавить, полностью юзабельные для всех жителей. И в целом рассчёт на то, что будет приятно проводить время в дороге даже пешком, а не как в большинстве других ГТА-лайк игр - скорей-скорей через всю карту, игнорируя всё на своём пути, ведь ничего кроме пустых статичных коробок там нет. У меня-то планируется живой мир и домики полноценные, минимальное количество статичных декораций, даже деревья в будущем хочется сделать динамически растущими, сейчас просто заглушка/макет для тестов.
Интересно: в какой-то момент заметил, что FPS падал в разы при движениях мыши. Профайлер показал, что движение мыши вызывает 2500+ вызовов _input() в моих 500 Spatial. В них я всего лишь переключал скорость движения (чтоб временно всех ускорить). Оказалось, нужно было использовать _unhandled_input(), чтобы боты не регистрировали события, которые предназначены игроку. Почему-то раньше не натыкался на объяснение необходимости этой функции и лепил везде _input(), даже зная о существовании альтернатив.
>>04888
Забыл запостить. Ещё прошлой ночью немного доработал тестовую сцену в визуальном плане. А именно: жители движутся по 4 линиям, в зависимости от линии используют базовую модельку или модельку с тестовой машинкой, разворачиваются в направлении движения (look_at()). Зачем я это делаю, если всё равно потом переделывать? Во-первых, хочется оценить предел того, сколько таких подвижных сущностей я смогу иметь на экране, ведь KinematicBody уже меня подвёл. Во-вторых, хочется прикинуть, сколько мне вообще нужно подвижных сущностей на экране от первого лица, а сколько может оставаться в скрытом состоянии. В-третьих, просто чтобы оценить ощущения от будущей игры/геймплея: одно дело кататься на машинках по городу в ГТА/чужой игре, другое - делать игру с похожим геймплеем самому, имея крайне ограниченные ресурсы. Скажем, меня всегда раздражали кривые дороги и мосты в ГТА, и мне хотелось бы сделать интересную игру с квадратной планировкой дорог, но я сомневаюсь, что это возможно (видел подобные ассетфлипы на юнити - вообще не впечатлило).
Что по видео:
1. 500 жителей с "машинами" (только моделька корпуса, без VehicleBody). FPS сильно скачет из-за того, что при некоторых ракурсах рисуются все эти ~750 моделек. Перед этим тестовая моделька персонажа была из отдельных кубиков, и всё было ещё хуже - специально склеил в один меш для этих тестов. Правда, полноценная модель персонажа будет из нескольких мешей...
2. 300 жителей вечером с фарами. FPS резко снизился из-за того, что на каждой машине по 4 дополнительных MeshInstance, и всего источников света получается минимум 301. Но меня интересовало тут взаимодействие источников света. Выглядит прикольно.
3. 100 жителей и машины замедленны. Тут я осознал, что изначальная скорость взята слишком большой, я эти модельки машин догнать не могу даже увеличив мощность двигателя VehicleBody. Да и вообще я не гонки делаю, мне хочется более размеренный геймплей. Чтоб никто никуда не торопился. Вот на этом видео уже что-то более-менее близкое тому, что хотелось бы видеть в игре, в плане скорости и плотности населения. Думаю, будет даже медленнее и с меньшим числом автовладельцев, лол. Я ж ещё автобусы хочу добавить, полностью юзабельные для всех жителей. И в целом рассчёт на то, что будет приятно проводить время в дороге даже пешком, а не как в большинстве других ГТА-лайк игр - скорей-скорей через всю карту, игнорируя всё на своём пути, ведь ничего кроме пустых статичных коробок там нет. У меня-то планируется живой мир и домики полноценные, минимальное количество статичных декораций, даже деревья в будущем хочется сделать динамически растущими, сейчас просто заглушка/макет для тестов.
Интересно: в какой-то момент заметил, что FPS падал в разы при движениях мыши. Профайлер показал, что движение мыши вызывает 2500+ вызовов _input() в моих 500 Spatial. В них я всего лишь переключал скорость движения (чтоб временно всех ускорить). Оказалось, нужно было использовать _unhandled_input(), чтобы боты не регистрировали события, которые предназначены игроку. Почему-то раньше не натыкался на объяснение необходимости этой функции и лепил везде _input(), даже зная о существовании альтернатив.
Забыл запостить. Ещё прошлой ночью немного доработал тестовую сцену в визуальном плане. А именно: жители движутся по 4 линиям, в зависимости от линии используют базовую модельку или модельку с тестовой машинкой, разворачиваются в направлении движения (look_at()). Зачем я это делаю, если всё равно потом переделывать? Во-первых, хочется оценить предел того, сколько таких подвижных сущностей я смогу иметь на экране, ведь KinematicBody уже меня подвёл. Во-вторых, хочется прикинуть, сколько мне вообще нужно подвижных сущностей на экране от первого лица, а сколько может оставаться в скрытом состоянии. В-третьих, просто чтобы оценить ощущения от будущей игры/геймплея: одно дело кататься на машинках по городу в ГТА/чужой игре, другое - делать игру с похожим геймплеем самому, имея крайне ограниченные ресурсы. Скажем, меня всегда раздражали кривые дороги и мосты в ГТА, и мне хотелось бы сделать интересную игру с квадратной планировкой дорог, но я сомневаюсь, что это возможно (видел подобные ассетфлипы на юнити - вообще не впечатлило).
Что по видео:
1. 500 жителей с "машинами" (только моделька корпуса, без VehicleBody). FPS сильно скачет из-за того, что при некоторых ракурсах рисуются все эти ~750 моделек. Перед этим тестовая моделька персонажа была из отдельных кубиков, и всё было ещё хуже - специально склеил в один меш для этих тестов. Правда, полноценная модель персонажа будет из нескольких мешей...
2. 300 жителей вечером с фарами. FPS резко снизился из-за того, что на каждой машине по 4 дополнительных MeshInstance, и всего источников света получается минимум 301. Но меня интересовало тут взаимодействие источников света. Выглядит прикольно.
3. 100 жителей и машины замедленны. Тут я осознал, что изначальная скорость взята слишком большой, я эти модельки машин догнать не могу даже увеличив мощность двигателя VehicleBody. Да и вообще я не гонки делаю, мне хочется более размеренный геймплей. Чтоб никто никуда не торопился. Вот на этом видео уже что-то более-менее близкое тому, что хотелось бы видеть в игре, в плане скорости и плотности населения. Думаю, будет даже медленнее и с меньшим числом автовладельцев, лол. Я ж ещё автобусы хочу добавить, полностью юзабельные для всех жителей. И в целом рассчёт на то, что будет приятно проводить время в дороге даже пешком, а не как в большинстве других ГТА-лайк игр - скорей-скорей через всю карту, игнорируя всё на своём пути, ведь ничего кроме пустых статичных коробок там нет. У меня-то планируется живой мир и домики полноценные, минимальное количество статичных декораций, даже деревья в будущем хочется сделать динамически растущими, сейчас просто заглушка/макет для тестов.
Интересно: в какой-то момент заметил, что FPS падал в разы при движениях мыши. Профайлер показал, что движение мыши вызывает 2500+ вызовов _input() в моих 500 Spatial. В них я всего лишь переключал скорость движения (чтоб временно всех ускорить). Оказалось, нужно было использовать _unhandled_input(), чтобы боты не регистрировали события, которые предназначены игроку. Почему-то раньше не натыкался на объяснение необходимости этой функции и лепил везде _input(), даже зная о существовании альтернатив.
>>05153
Это вот этот анон - дефрагментатор: >>04958 (Del)
Коллбэк в гдскрипт ему не понравился! Не нашёл функции для какого-то странного БДСМ графа дорог в АПИ астара - полез сразу пилить велосипедный цпп модуль для движка, ибо, видите ли, скорость нужна. И это, по-твоему, не дефрагментаторство?
Гдскрипт в большинстве случаев наименьшая проблема в контексте производительности, особенно в 3D на 3.х. У людей дроуколлов больше десяти тысяч без костылей со склеиванием мешей в один, ригидбоди кубики высаживают фпс в ноль после всего нескольких сотен, кинематикбоди больше 150 вызывают какой-то расколбас в мув_енд_слайд, а у него пара коллбэков из официальной документации - вопиющая неоптимальность?
Нет, пусть пилит, если ему это нравится. Каждый дрочит как он хочет. Весь вопрос изначально был в целесообразности такого решения, да и в задаче как таковой. Часто бывает, что решают задачу, которую сами себе придумали, пытаясь найти решение другой задачи, но на самом деле для решения той задачи нужно совсем другое. Возможно, это не тот случай, но по первому описанию показалось именно это.
Если что, извиняюсь, что навязывал своё мнение на счёт геймдизайна. Настроение такое было. В каком-то смысле тот анон прав, что инструмент не должен диктовать правила игры. Но с другой стороны, я тоже прав: если твоя цель - сделать игру, ты будешь вынужден делать фичекат и переделывать дизайн под имеющиеся в твоём распоряжении инструменты, чтобы не потратить все ресурсы на разработку инструментов, которые могут себя не оправдать. По этой же причине большинство сегодня использует готовые движки, а не пишет с нуля свои, ведь цель у них - сделать игру. Даже ААА проекты пускают под нож, когда не могут реализовать какую-то фичу на имеющемся инструментарии в выделенное время/бюджет. Что уж говорить про инди...
>Дефрагментатор
Это вот этот анон - дефрагментатор: >>04958 (Del)
>где compute_cost это коллбэк в гдскрипт
Коллбэк в гдскрипт ему не понравился! Не нашёл функции для какого-то странного БДСМ графа дорог в АПИ астара - полез сразу пилить велосипедный цпп модуль для движка, ибо, видите ли, скорость нужна. И это, по-твоему, не дефрагментаторство?
Гдскрипт в большинстве случаев наименьшая проблема в контексте производительности, особенно в 3D на 3.х. У людей дроуколлов больше десяти тысяч без костылей со склеиванием мешей в один, ригидбоди кубики высаживают фпс в ноль после всего нескольких сотен, кинематикбоди больше 150 вызывают какой-то расколбас в мув_енд_слайд, а у него пара коллбэков из официальной документации - вопиющая неоптимальность?
Нет, пусть пилит, если ему это нравится. Каждый дрочит как он хочет. Весь вопрос изначально был в целесообразности такого решения, да и в задаче как таковой. Часто бывает, что решают задачу, которую сами себе придумали, пытаясь найти решение другой задачи, но на самом деле для решения той задачи нужно совсем другое. Возможно, это не тот случай, но по первому описанию показалось именно это.
Если что, извиняюсь, что навязывал своё мнение на счёт геймдизайна. Настроение такое было. В каком-то смысле тот анон прав, что инструмент не должен диктовать правила игры. Но с другой стороны, я тоже прав: если твоя цель - сделать игру, ты будешь вынужден делать фичекат и переделывать дизайн под имеющиеся в твоём распоряжении инструменты, чтобы не потратить все ресурсы на разработку инструментов, которые могут себя не оправдать. По этой же причине большинство сегодня использует готовые движки, а не пишет с нуля свои, ведь цель у них - сделать игру. Даже ААА проекты пускают под нож, когда не могут реализовать какую-то фичу на имеющемся инструментарии в выделенное время/бюджет. Что уж говорить про инди...
>>05155
Давно тебя жду. Я тут припомнил прошлогодний хайп с киберпанком 2077, в котором на старте продаж были дикие глитчи. Среди них был один, который я хочу тебе (и всем, кто делает опенворлды с машинками) напомнить, чтобы ты принял к сведению. Так вот, там бывала ситуация, когда машины начинали ехать не по дороге, а правее или левее её, выше или ниже. Плыли по воздуху, иногда проходили сквозь визуальные преграды, иногда застревали в них и бешенно тряслись. Вспомнили?
Так вот, из наблюдений за этим глитчем, я вывел алгоритм оптимизации, который ИМХО используется в киберпанке (и скорее всего в аналогичных играх, т.к. это очевидное решение):
1. У машины отключаемое физическое тело.
2. Когда тело выключено, машина движется по кривым линиям-путям, представляя собой исключительно анимированный меш.
3. Когда тело включено, активируется физика, машина начинает сталкиваться с другими объектами, движется же она уже не по кривой, а в рамках навигационного полигона по проложенному маршруту реально используя физические силы и реакции.
4. Очевидно, что подавляющее большинство машин находятся в состоянии 2. В состояние 3 они переходят только если игра вовлекает их во взаимодействие с игроком.
Сам глитч заглючался в двух аспектах:
1. Неправильно выставленные кривые по лодам заставляли модельки машин двигаться по воздуху.
2. Когда машина начинала взаимодействовать с игроком, например игрок её зацепил и сработал скрипт, включалась физика для машины, а она в этот момент пролетала сквозь колонну - вот вам и застревание с джиттером.
> сколько таких подвижных сущностей я смогу иметь на экране, ведь KinematicBody уже меня подвёл
Давно тебя жду. Я тут припомнил прошлогодний хайп с киберпанком 2077, в котором на старте продаж были дикие глитчи. Среди них был один, который я хочу тебе (и всем, кто делает опенворлды с машинками) напомнить, чтобы ты принял к сведению. Так вот, там бывала ситуация, когда машины начинали ехать не по дороге, а правее или левее её, выше или ниже. Плыли по воздуху, иногда проходили сквозь визуальные преграды, иногда застревали в них и бешенно тряслись. Вспомнили?
Так вот, из наблюдений за этим глитчем, я вывел алгоритм оптимизации, который ИМХО используется в киберпанке (и скорее всего в аналогичных играх, т.к. это очевидное решение):
1. У машины отключаемое физическое тело.
2. Когда тело выключено, машина движется по кривым линиям-путям, представляя собой исключительно анимированный меш.
3. Когда тело включено, активируется физика, машина начинает сталкиваться с другими объектами, движется же она уже не по кривой, а в рамках навигационного полигона по проложенному маршруту реально используя физические силы и реакции.
4. Очевидно, что подавляющее большинство машин находятся в состоянии 2. В состояние 3 они переходят только если игра вовлекает их во взаимодействие с игроком.
Сам глитч заглючался в двух аспектах:
1. Неправильно выставленные кривые по лодам заставляли модельки машин двигаться по воздуху.
2. Когда машина начинала взаимодействовать с игроком, например игрок её зацепил и сработал скрипт, включалась физика для машины, а она в этот момент пролетала сквозь колонну - вот вам и застревание с джиттером.
60 Кб, 800x600>>05271
Я этот тред почти ежедневно проверяю. Просто редко что-то делаю с проектом, чтобы было что показать. И не хочу занимать собой весь тред, а кроме меня тут редко пишут о своих проектах.
Не играл, но слышал слух, что у них машинки сделаны на основе (ООП класса) лошадей из предыдущих игр, поэтому багов много. Также видел видео, где игрок встаёт перед машиной, создавая пробку, и никто не смеет его объехать или переехать - так и стоят целые сутки. Короче, видно, что они вложили много денег в графон и сюжет, а транспортный поток кое-как пришили на основе старого кода, не пытаясь сделать его живее.
Я уже думал о таком алгоритме. Но мне не нравятся связанный с ним эффект, когда "призрак" машины внезапно становится физическим - срабатывает подвеска и т.д. Думаю, это слишком заметно, если происходит в поле зрения игрока.
На счёт других игр не знаю, могу сказать только про серию GTA. Ни в одной игре серии не замечал глюков с переключением "физического тела" автомобилей. Подозреваю, что "исключительно анимированных мешей" в ГТА нет, за исключением ситуации когда игрок смотрит на город с большой высоты (когда рисуются "фары", движущиеся по дорогам). В ГТА я замечал (или видел на ютубе) другие баги:
- иногда машины появляются в неправильных местах, падая с неба или как бы выскакивая из асфальта;
- иногда машины могут появляться практически перед носом, стоит развернуть камеру в их сторону;
- если машина уезжает от игрока, достаточно на секунду потерять зрительный контакт с ней, как она исчезнет;
- боты могут уворачиваться от невидимых препятствий, скорее всего из-за неправильной карты навигации (в ГТА 4 боты на мосту уклоняются от поезда под мостом).
Ещё в настройках нескольких игр серии есть опция "плотность трафика": на минимальной машин почти нет, на максимальной они создают пробки. Вряд ли эта настройка создана только из-за нагрузки на видеокарту. При этом по ощущениям машин никогда не бывает слишком много, максимум штук 30, это не такое большое число для физических сущностей Bullet Physics (RAGE 1/2), если рассматривать встроенный VehicleBody, я тестил на Godot. Да даже самодельная машина на RigidBody вряд ли будет вызывать проблемы в таких небольших количествах. А старые движки использовали какую-то грубую физическую модель, там особо нечему тормозить, имхо (хотя и железо тогда было слабее). Что касается модели повреждений (смятый корпус, оторванные двери), то она срабатывает скорее всего только в момент удара, и не грузит процессор всё остальное время, в отличие от полноценных симуляторов (BeamNG.drive).
В общем, мне кажется, в ГТА все видимые визуально машины - это полноценные физические сущности (в IV/V - на Bullet). Всё же город редко видно с высоты, а с точки зрения пешехода/водителя область видимости постоянно перекрыта какими-нибудь домами, что ограничивает количество необходимых машин.
Непонятно только, почему в киберпанк 2077 не сделали так же. Кстати, я видел на ютубе ещё один баг, который позволял видеть весь город сквозь текстуры здания: там было видно, что ВСЕ машины города существуют одновременно и движутся по своим маршрутам в воздухе (хотя чанки для статичных моделей всё же имеются). В ГТА такого, естественно, никогда не было, потому что машины вне поля зрения исчезают навсегда, и не спавнятся так далеко от игрока.
Предполагаю такое объяснение. В ГТА геймдизайнеры никогда не придавали особого значения отдельным автомобилям - это просто интерактивные декорации, которые нужны только чтобы развлечь игрока или преградить ему путь (водятлы натурально подрезают игрока на некоторых миссиях). Поэтому в ГТА машины и их водители генерируются каждый раз заново, и после исчезновения их невозможно догнать, потому что они больше не существуют. В киберпанке вроде как были какие-то вялые заявки на симуляцию жизни, из-за чего им нужно было сохранять один автомобиль на протяжении всего его маршрута, чтобы игрок мог его в любой момент догнать или увидеть повторно. Поэтому они были вынуждены делать болванку на рельсах и включать ей физику только рядом с игроком. Непонятно только, почему нельзя было полностью уничтожать болванку, создавая машину заново возле игрока по её данным, ведь это было бы оптимальнее (нет болванок за километр от игрока, за кучей домов) и геймплейно ничего бы не изменилось (т.е. была бы та же "материализация", что и в ГТА, но при этом можно было бы догнать любой автомобиль, уехавший далеко).
У себя я хочу сделать что-то среднее между этими двумя подходами. Ну, я уже описал это, по сути: создавать физическую машину в физически прогруженных чанках независимо от действий игрока, и уничтожать её в случае выхода из прогруженной области или выгрузки чанка, не оставляя анимированных мешей без физики. Тогда должно быть намного меньше глюков прямо перед носом игрока, вызванных переключением физики. Визуальные болванки на рельсах буду делать разве что для обзора города с высоты (когда игрок в летающем транспорте). То, что есть сейчас, нужно мне только чтобы видеть маршруты всех ботов сразу и примерно оценить ощущения от такого транспортного потока (по-хорошему, нужно было разделить движение в разные стороны на разные линии, но я не придумал, как набросать это быстро, а в будущем там совсем другая система нужна будет, с навигацией в каждом отдельном блоке).
Спасибо за попытку помочь, очень приятно, когда отвечают на посты о проекте по делу. Давно собираюсь создать тред, но всё откладываю. Хочется подробно расписать свои задумки, а это скорее всего растянется на несколько постов. А регулярные апдейты делать не смогу - часто забрасываю проект, целыми днями ничем полезным не занимаясь. Мысль сесть за проект и целый день рефакторить без какого-либо видимого прогресса сильно демотивирует, а совсем без рефакторинга я скоро совсем ничего сделать не смогу, всё слишком сильно запуталось в коде... Давно пора нарисовать схему взаимодействия систем, но, честно говоря, лень.
>Давно тебя жду.
Я этот тред почти ежедневно проверяю. Просто редко что-то делаю с проектом, чтобы было что показать. И не хочу занимать собой весь тред, а кроме меня тут редко пишут о своих проектах.
>киберпанком 2077
Не играл, но слышал слух, что у них машинки сделаны на основе (ООП класса) лошадей из предыдущих игр, поэтому багов много. Также видел видео, где игрок встаёт перед машиной, создавая пробку, и никто не смеет его объехать или переехать - так и стоят целые сутки. Короче, видно, что они вложили много денег в графон и сюжет, а транспортный поток кое-как пришили на основе старого кода, не пытаясь сделать его живее.
>вывел алгоритм оптимизации
Я уже думал о таком алгоритме. Но мне не нравятся связанный с ним эффект, когда "призрак" машины внезапно становится физическим - срабатывает подвеска и т.д. Думаю, это слишком заметно, если происходит в поле зрения игрока.
>скорее всего в аналогичных играх
На счёт других игр не знаю, могу сказать только про серию GTA. Ни в одной игре серии не замечал глюков с переключением "физического тела" автомобилей. Подозреваю, что "исключительно анимированных мешей" в ГТА нет, за исключением ситуации когда игрок смотрит на город с большой высоты (когда рисуются "фары", движущиеся по дорогам). В ГТА я замечал (или видел на ютубе) другие баги:
- иногда машины появляются в неправильных местах, падая с неба или как бы выскакивая из асфальта;
- иногда машины могут появляться практически перед носом, стоит развернуть камеру в их сторону;
- если машина уезжает от игрока, достаточно на секунду потерять зрительный контакт с ней, как она исчезнет;
- боты могут уворачиваться от невидимых препятствий, скорее всего из-за неправильной карты навигации (в ГТА 4 боты на мосту уклоняются от поезда под мостом).
Ещё в настройках нескольких игр серии есть опция "плотность трафика": на минимальной машин почти нет, на максимальной они создают пробки. Вряд ли эта настройка создана только из-за нагрузки на видеокарту. При этом по ощущениям машин никогда не бывает слишком много, максимум штук 30, это не такое большое число для физических сущностей Bullet Physics (RAGE 1/2), если рассматривать встроенный VehicleBody, я тестил на Godot. Да даже самодельная машина на RigidBody вряд ли будет вызывать проблемы в таких небольших количествах. А старые движки использовали какую-то грубую физическую модель, там особо нечему тормозить, имхо (хотя и железо тогда было слабее). Что касается модели повреждений (смятый корпус, оторванные двери), то она срабатывает скорее всего только в момент удара, и не грузит процессор всё остальное время, в отличие от полноценных симуляторов (BeamNG.drive).
В общем, мне кажется, в ГТА все видимые визуально машины - это полноценные физические сущности (в IV/V - на Bullet). Всё же город редко видно с высоты, а с точки зрения пешехода/водителя область видимости постоянно перекрыта какими-нибудь домами, что ограничивает количество необходимых машин.
Непонятно только, почему в киберпанк 2077 не сделали так же. Кстати, я видел на ютубе ещё один баг, который позволял видеть весь город сквозь текстуры здания: там было видно, что ВСЕ машины города существуют одновременно и движутся по своим маршрутам в воздухе (хотя чанки для статичных моделей всё же имеются). В ГТА такого, естественно, никогда не было, потому что машины вне поля зрения исчезают навсегда, и не спавнятся так далеко от игрока.
Предполагаю такое объяснение. В ГТА геймдизайнеры никогда не придавали особого значения отдельным автомобилям - это просто интерактивные декорации, которые нужны только чтобы развлечь игрока или преградить ему путь (водятлы натурально подрезают игрока на некоторых миссиях). Поэтому в ГТА машины и их водители генерируются каждый раз заново, и после исчезновения их невозможно догнать, потому что они больше не существуют. В киберпанке вроде как были какие-то вялые заявки на симуляцию жизни, из-за чего им нужно было сохранять один автомобиль на протяжении всего его маршрута, чтобы игрок мог его в любой момент догнать или увидеть повторно. Поэтому они были вынуждены делать болванку на рельсах и включать ей физику только рядом с игроком. Непонятно только, почему нельзя было полностью уничтожать болванку, создавая машину заново возле игрока по её данным, ведь это было бы оптимальнее (нет болванок за километр от игрока, за кучей домов) и геймплейно ничего бы не изменилось (т.е. была бы та же "материализация", что и в ГТА, но при этом можно было бы догнать любой автомобиль, уехавший далеко).
У себя я хочу сделать что-то среднее между этими двумя подходами. Ну, я уже описал это, по сути: создавать физическую машину в физически прогруженных чанках независимо от действий игрока, и уничтожать её в случае выхода из прогруженной области или выгрузки чанка, не оставляя анимированных мешей без физики. Тогда должно быть намного меньше глюков прямо перед носом игрока, вызванных переключением физики. Визуальные болванки на рельсах буду делать разве что для обзора города с высоты (когда игрок в летающем транспорте). То, что есть сейчас, нужно мне только чтобы видеть маршруты всех ботов сразу и примерно оценить ощущения от такого транспортного потока (по-хорошему, нужно было разделить движение в разные стороны на разные линии, но я не придумал, как набросать это быстро, а в будущем там совсем другая система нужна будет, с навигацией в каждом отдельном блоке).
Спасибо за попытку помочь, очень приятно, когда отвечают на посты о проекте по делу. Давно собираюсь создать тред, но всё откладываю. Хочется подробно расписать свои задумки, а это скорее всего растянется на несколько постов. А регулярные апдейты делать не смогу - часто забрасываю проект, целыми днями ничем полезным не занимаясь. Мысль сесть за проект и целый день рефакторить без какого-либо видимого прогресса сильно демотивирует, а совсем без рефакторинга я скоро совсем ничего сделать не смогу, всё слишком сильно запуталось в коде... Давно пора нарисовать схему взаимодействия систем, но, честно говоря, лень.
60 Кб, 800x600>>05271
Я этот тред почти ежедневно проверяю. Просто редко что-то делаю с проектом, чтобы было что показать. И не хочу занимать собой весь тред, а кроме меня тут редко пишут о своих проектах.
Не играл, но слышал слух, что у них машинки сделаны на основе (ООП класса) лошадей из предыдущих игр, поэтому багов много. Также видел видео, где игрок встаёт перед машиной, создавая пробку, и никто не смеет его объехать или переехать - так и стоят целые сутки. Короче, видно, что они вложили много денег в графон и сюжет, а транспортный поток кое-как пришили на основе старого кода, не пытаясь сделать его живее.
Я уже думал о таком алгоритме. Но мне не нравятся связанный с ним эффект, когда "призрак" машины внезапно становится физическим - срабатывает подвеска и т.д. Думаю, это слишком заметно, если происходит в поле зрения игрока.
На счёт других игр не знаю, могу сказать только про серию GTA. Ни в одной игре серии не замечал глюков с переключением "физического тела" автомобилей. Подозреваю, что "исключительно анимированных мешей" в ГТА нет, за исключением ситуации когда игрок смотрит на город с большой высоты (когда рисуются "фары", движущиеся по дорогам). В ГТА я замечал (или видел на ютубе) другие баги:
- иногда машины появляются в неправильных местах, падая с неба или как бы выскакивая из асфальта;
- иногда машины могут появляться практически перед носом, стоит развернуть камеру в их сторону;
- если машина уезжает от игрока, достаточно на секунду потерять зрительный контакт с ней, как она исчезнет;
- боты могут уворачиваться от невидимых препятствий, скорее всего из-за неправильной карты навигации (в ГТА 4 боты на мосту уклоняются от поезда под мостом).
Ещё в настройках нескольких игр серии есть опция "плотность трафика": на минимальной машин почти нет, на максимальной они создают пробки. Вряд ли эта настройка создана только из-за нагрузки на видеокарту. При этом по ощущениям машин никогда не бывает слишком много, максимум штук 30, это не такое большое число для физических сущностей Bullet Physics (RAGE 1/2), если рассматривать встроенный VehicleBody, я тестил на Godot. Да даже самодельная машина на RigidBody вряд ли будет вызывать проблемы в таких небольших количествах. А старые движки использовали какую-то грубую физическую модель, там особо нечему тормозить, имхо (хотя и железо тогда было слабее). Что касается модели повреждений (смятый корпус, оторванные двери), то она срабатывает скорее всего только в момент удара, и не грузит процессор всё остальное время, в отличие от полноценных симуляторов (BeamNG.drive).
В общем, мне кажется, в ГТА все видимые визуально машины - это полноценные физические сущности (в IV/V - на Bullet). Всё же город редко видно с высоты, а с точки зрения пешехода/водителя область видимости постоянно перекрыта какими-нибудь домами, что ограничивает количество необходимых машин.
Непонятно только, почему в киберпанк 2077 не сделали так же. Кстати, я видел на ютубе ещё один баг, который позволял видеть весь город сквозь текстуры здания: там было видно, что ВСЕ машины города существуют одновременно и движутся по своим маршрутам в воздухе (хотя чанки для статичных моделей всё же имеются). В ГТА такого, естественно, никогда не было, потому что машины вне поля зрения исчезают навсегда, и не спавнятся так далеко от игрока.
Предполагаю такое объяснение. В ГТА геймдизайнеры никогда не придавали особого значения отдельным автомобилям - это просто интерактивные декорации, которые нужны только чтобы развлечь игрока или преградить ему путь (водятлы натурально подрезают игрока на некоторых миссиях). Поэтому в ГТА машины и их водители генерируются каждый раз заново, и после исчезновения их невозможно догнать, потому что они больше не существуют. В киберпанке вроде как были какие-то вялые заявки на симуляцию жизни, из-за чего им нужно было сохранять один автомобиль на протяжении всего его маршрута, чтобы игрок мог его в любой момент догнать или увидеть повторно. Поэтому они были вынуждены делать болванку на рельсах и включать ей физику только рядом с игроком. Непонятно только, почему нельзя было полностью уничтожать болванку, создавая машину заново возле игрока по её данным, ведь это было бы оптимальнее (нет болванок за километр от игрока, за кучей домов) и геймплейно ничего бы не изменилось (т.е. была бы та же "материализация", что и в ГТА, но при этом можно было бы догнать любой автомобиль, уехавший далеко).
У себя я хочу сделать что-то среднее между этими двумя подходами. Ну, я уже описал это, по сути: создавать физическую машину в физически прогруженных чанках независимо от действий игрока, и уничтожать её в случае выхода из прогруженной области или выгрузки чанка, не оставляя анимированных мешей без физики. Тогда должно быть намного меньше глюков прямо перед носом игрока, вызванных переключением физики. Визуальные болванки на рельсах буду делать разве что для обзора города с высоты (когда игрок в летающем транспорте). То, что есть сейчас, нужно мне только чтобы видеть маршруты всех ботов сразу и примерно оценить ощущения от такого транспортного потока (по-хорошему, нужно было разделить движение в разные стороны на разные линии, но я не придумал, как набросать это быстро, а в будущем там совсем другая система нужна будет, с навигацией в каждом отдельном блоке).
Спасибо за попытку помочь, очень приятно, когда отвечают на посты о проекте по делу. Давно собираюсь создать тред, но всё откладываю. Хочется подробно расписать свои задумки, а это скорее всего растянется на несколько постов. А регулярные апдейты делать не смогу - часто забрасываю проект, целыми днями ничем полезным не занимаясь. Мысль сесть за проект и целый день рефакторить без какого-либо видимого прогресса сильно демотивирует, а совсем без рефакторинга я скоро совсем ничего сделать не смогу, всё слишком сильно запуталось в коде... Давно пора нарисовать схему взаимодействия систем, но, честно говоря, лень.
>Давно тебя жду.
Я этот тред почти ежедневно проверяю. Просто редко что-то делаю с проектом, чтобы было что показать. И не хочу занимать собой весь тред, а кроме меня тут редко пишут о своих проектах.
>киберпанком 2077
Не играл, но слышал слух, что у них машинки сделаны на основе (ООП класса) лошадей из предыдущих игр, поэтому багов много. Также видел видео, где игрок встаёт перед машиной, создавая пробку, и никто не смеет его объехать или переехать - так и стоят целые сутки. Короче, видно, что они вложили много денег в графон и сюжет, а транспортный поток кое-как пришили на основе старого кода, не пытаясь сделать его живее.
>вывел алгоритм оптимизации
Я уже думал о таком алгоритме. Но мне не нравятся связанный с ним эффект, когда "призрак" машины внезапно становится физическим - срабатывает подвеска и т.д. Думаю, это слишком заметно, если происходит в поле зрения игрока.
>скорее всего в аналогичных играх
На счёт других игр не знаю, могу сказать только про серию GTA. Ни в одной игре серии не замечал глюков с переключением "физического тела" автомобилей. Подозреваю, что "исключительно анимированных мешей" в ГТА нет, за исключением ситуации когда игрок смотрит на город с большой высоты (когда рисуются "фары", движущиеся по дорогам). В ГТА я замечал (или видел на ютубе) другие баги:
- иногда машины появляются в неправильных местах, падая с неба или как бы выскакивая из асфальта;
- иногда машины могут появляться практически перед носом, стоит развернуть камеру в их сторону;
- если машина уезжает от игрока, достаточно на секунду потерять зрительный контакт с ней, как она исчезнет;
- боты могут уворачиваться от невидимых препятствий, скорее всего из-за неправильной карты навигации (в ГТА 4 боты на мосту уклоняются от поезда под мостом).
Ещё в настройках нескольких игр серии есть опция "плотность трафика": на минимальной машин почти нет, на максимальной они создают пробки. Вряд ли эта настройка создана только из-за нагрузки на видеокарту. При этом по ощущениям машин никогда не бывает слишком много, максимум штук 30, это не такое большое число для физических сущностей Bullet Physics (RAGE 1/2), если рассматривать встроенный VehicleBody, я тестил на Godot. Да даже самодельная машина на RigidBody вряд ли будет вызывать проблемы в таких небольших количествах. А старые движки использовали какую-то грубую физическую модель, там особо нечему тормозить, имхо (хотя и железо тогда было слабее). Что касается модели повреждений (смятый корпус, оторванные двери), то она срабатывает скорее всего только в момент удара, и не грузит процессор всё остальное время, в отличие от полноценных симуляторов (BeamNG.drive).
В общем, мне кажется, в ГТА все видимые визуально машины - это полноценные физические сущности (в IV/V - на Bullet). Всё же город редко видно с высоты, а с точки зрения пешехода/водителя область видимости постоянно перекрыта какими-нибудь домами, что ограничивает количество необходимых машин.
Непонятно только, почему в киберпанк 2077 не сделали так же. Кстати, я видел на ютубе ещё один баг, который позволял видеть весь город сквозь текстуры здания: там было видно, что ВСЕ машины города существуют одновременно и движутся по своим маршрутам в воздухе (хотя чанки для статичных моделей всё же имеются). В ГТА такого, естественно, никогда не было, потому что машины вне поля зрения исчезают навсегда, и не спавнятся так далеко от игрока.
Предполагаю такое объяснение. В ГТА геймдизайнеры никогда не придавали особого значения отдельным автомобилям - это просто интерактивные декорации, которые нужны только чтобы развлечь игрока или преградить ему путь (водятлы натурально подрезают игрока на некоторых миссиях). Поэтому в ГТА машины и их водители генерируются каждый раз заново, и после исчезновения их невозможно догнать, потому что они больше не существуют. В киберпанке вроде как были какие-то вялые заявки на симуляцию жизни, из-за чего им нужно было сохранять один автомобиль на протяжении всего его маршрута, чтобы игрок мог его в любой момент догнать или увидеть повторно. Поэтому они были вынуждены делать болванку на рельсах и включать ей физику только рядом с игроком. Непонятно только, почему нельзя было полностью уничтожать болванку, создавая машину заново возле игрока по её данным, ведь это было бы оптимальнее (нет болванок за километр от игрока, за кучей домов) и геймплейно ничего бы не изменилось (т.е. была бы та же "материализация", что и в ГТА, но при этом можно было бы догнать любой автомобиль, уехавший далеко).
У себя я хочу сделать что-то среднее между этими двумя подходами. Ну, я уже описал это, по сути: создавать физическую машину в физически прогруженных чанках независимо от действий игрока, и уничтожать её в случае выхода из прогруженной области или выгрузки чанка, не оставляя анимированных мешей без физики. Тогда должно быть намного меньше глюков прямо перед носом игрока, вызванных переключением физики. Визуальные болванки на рельсах буду делать разве что для обзора города с высоты (когда игрок в летающем транспорте). То, что есть сейчас, нужно мне только чтобы видеть маршруты всех ботов сразу и примерно оценить ощущения от такого транспортного потока (по-хорошему, нужно было разделить движение в разные стороны на разные линии, но я не придумал, как набросать это быстро, а в будущем там совсем другая система нужна будет, с навигацией в каждом отдельном блоке).
Спасибо за попытку помочь, очень приятно, когда отвечают на посты о проекте по делу. Давно собираюсь создать тред, но всё откладываю. Хочется подробно расписать свои задумки, а это скорее всего растянется на несколько постов. А регулярные апдейты делать не смогу - часто забрасываю проект, целыми днями ничем полезным не занимаясь. Мысль сесть за проект и целый день рефакторить без какого-либо видимого прогресса сильно демотивирует, а совсем без рефакторинга я скоро совсем ничего сделать не смогу, всё слишком сильно запуталось в коде... Давно пора нарисовать схему взаимодействия систем, но, честно говоря, лень.
>>05306
То есть для ЛОД-ов, которые больше некоторого N, Именно так и достигается бесшовность. Неважно, высота это или длина. Где-то далеко при твоём приближении болванки незаметно приобретают физическую форму, а при твоём отдалении снова превращаются в болванки на рельсах. Секрет кроется в грамотном расположении уровней детализации так, чтобы игрок не увидел подмены. И при этом чтобы не нагружать железо, разумеется. Вот рокстары, например, настолько хороши в этом, что ты даже помыслить не можешь о том, что они юзают болванки на рельсах без физики.
А они их юзают, потому что физика очень затратна для компа. Не доросли компы ещё. Каким ты гением ни будь - ты не сможешь так оптимизировать всё, чтобы сотни физических объектов не тормозили. В ААА играх применяют ещё такую тему: несколько однотипных инстансов рассматриваются как одна сущность и физический движок считает эту одну сущность за приемлемое процессорное время, из ярких примеров - толпы зомби, реализованные как поток жидкости.
> Визуальные болванки на рельсах буду делать разве что для обзора города с высоты
То есть для ЛОД-ов, которые больше некоторого N, Именно так и достигается бесшовность. Неважно, высота это или длина. Где-то далеко при твоём приближении болванки незаметно приобретают физическую форму, а при твоём отдалении снова превращаются в болванки на рельсах. Секрет кроется в грамотном расположении уровней детализации так, чтобы игрок не увидел подмены. И при этом чтобы не нагружать железо, разумеется. Вот рокстары, например, настолько хороши в этом, что ты даже помыслить не можешь о том, что они юзают болванки на рельсах без физики.
А они их юзают, потому что физика очень затратна для компа. Не доросли компы ещё. Каким ты гением ни будь - ты не сможешь так оптимизировать всё, чтобы сотни физических объектов не тормозили. В ААА играх применяют ещё такую тему: несколько однотипных инстансов рассматриваются как одна сущность и физический движок считает эту одну сущность за приемлемое процессорное время, из ярких примеров - толпы зомби, реализованные как поток жидкости.
Я посмотрел несколько видео про баги Cyberpunk 2077. Похоже, что в некоторых случаях машины всё же материализуются из воздуха и иногда дематериализуются. Возможно, это добавили в какой-то версии, или поведение игры на разных платформах разное. Или они сделали разные виды оптимизации, но не смогли их друг с другом стабильно соединить...
>>05329
Важно. С высоты ты гарантированно можешь увидеть много чанков города сразу. От первого лица же ты смотришь почти на уровне асфальта, и любой, даже одноэтажный дом, закрывает тебе обзор, даже небольшая группа деревьев закрывает обзор. По идее, если делать только короткие улицы, т.е. как можно больше поворотов, то никаких болванок на большом расстоянии при взгляде от первого лица не нужно.
Я ведь уже упоминал кривые дороги ГТА? Я думаю, это тоже своего рода оптимизация. Когда дорога часто виляет, оканчивается тупиком или развилкой - игрок редко видит далеко. Это позволяет не загружать машины и пешеходов в большом радиусе. Можно даже вычислить поле обзора игрока и не грузить машины на соседних дорогах, несмотря на то, что они близко к игроку. В моей игре практически невозможно сделать "кривую" дорогу из-за строго прямых углов, можно только ограничить максимальную длину прямого отрезка дороги. Нужно будет попробовать сгенерировать город с учётом максимальной длины прямого отрезка дороги... Как раз недавно видел пример большой сети дорог, в которой много тупиков, но нет островов, и я, кажется, знаю способ, как это реализовать (одно слово: рекурсия). Жаль, что раньше не догадался.
А ты уверен, что они их юзают? Есть какие-то доказательства? То, как машины появляются из воздуха и исчезают - я видел. То, как машины переключают свои графические LODы - тоже вроде бы видел. Но вот явного переключения физики не помню. Всё-таки в ГТА всегда была как минимум подвеска, и резкое включение физики выдавало бы себя беспричинно дрыгающейся подвеской. Не знаю, может, есть способ зафиксировать подвеску и сгладить переход?
Ой, не смеши меня. На первом скриншоте дофига машин и FPS был в пределах играбельного, если я правильно помню. На втором скриншоте ровно 35 машин с фарами (VSync включён), правда, они здесь, возможно, в спящем состоянии, но это вряд ли (мне не удалось стабильно усыплять автомобили VehicleBody, что-то их пробуждает, из-за чего я мучился тем, что KinematicBody в любой ситуации способен толкать VehicleBody).
Ты скажешь - это примитивные машины. Согласен. Но даже они по ощущениям вполне неплохие: подвеска, сцепление, плавный разгон и торможение. Я не специалист, но как игроку мне и так нравится. Машины в ГТА по существу отличаются только повреждаемым корпусом, и высока вероятность, что технически они подобны VehicleBody, тем более что в движке RAGE используется Bullet Physics (т.е. никакой тебе многопоточности и CUDA ядер из PhysX).
Но я не зря упоминал выше BeamNG.drive - вот там реально корпус симулируется как софтбоди или что-то вроде того, в результате на моём компе от силы 2-3 машины на пустой сцене BeamNG.drive сравнительно играбельны. А в ГТА корпус не симулируется, в старых ГТА (3/VC/SA) все повреждения смоделированы вручную и хранятся в архиве мешей (.img). В GTA IV добавили сравнительно сложную сминаемость, но она реагирует только на сильные удары, в остальные моменты, судя по всему, она "спит" и не грузит процессор. В GTA V её порезали, а в GTA Online весь транспорт из DLC почти никак не повреждается, можно только двери и бамперы оторвать (честно - халтура, не ожидал такого от Rockstar). Я, кстати, довольно часто пробовал создать пробку на большой дороге (прогоняя водителей и дожидаясь новых машин) в разных ГТА и затем взрывать машины - было вполне играбельно, а ведь такую ситуацию в нормальном геймплее не встречаешь, т.е. это экстремальный случай для игры.
Так что, имхо, не в физике дело. Если хочешь, могу ещё раз сделать стресс-тест на базе VehicleBody, добавив рандомное движение, чтобы физический движок не расселялся. Но учитывай, что в нормальном геймплее ГТА-лайк сотен машин никогда не бывает, даже два-три десятка легковушек занимают существенную площадь.
Слышал что-то подобное, но для машин, даже "аркадных" из ГТА, такую оптимизацию никак не применишь: каждая машина имеет индивидуальную конфигурацию физики и поведение.
Во-первых, зомби в общем случае абсолютно одинаковые, в отличие от машин ГТА. Во-вторых, зомби можно сделать на кинематикбоди, т.к. у них нет никакой сложной подвески и т.д. В-третьих, движение зомби как потока жидкости - это оптимизация навигации, чтобы зомби не грузили систему, обходя друг друга, т.е. к физике это не имеет прямого отношения, наоборот, физику такая симуляция только нагружает, разгружая систему индивидуальной навигации (астар или навмеш). Наконец, симуляция жидкости - это не "одна сущность". Насколько мне известно, типичная симуляция жидкости происходит в виде создания большого количества мелких шариков ригидбоди, положения которых затем "обтягиваются" 2D/3D мешем, имитируя один большой объект. Чем больше количество и чем меньше размеры ригидбоди - тем точнее симуляция, в идеале они должны быть размером с молекулы воды. Впрочем, я мало интересовался этой темой, знаю только что есть разные подходы, но в большинстве случаев вот эти "молекулы воды" движутся независимо и эффект потока возникает только благодаря эффекту эмерджентности (прямо как настоящая вода, если я правильно понимаю).
Про зомби я слышал, кстати, из обсуждения обновлений 7DTD, когда они оптимизировали игру, убрав индивидуальную навигацию зомби, т.е. с какого-то апдейта зомби ходят за "лидером", и благодаря этому игра стала шустрее, но игрокам это не очень понравилось. В общем, в случае зомби дело не в физике, а в навигации, т.к. зомби вынуждены постоянно обновлять путь до игрока, иначе они будут мимо него всей толпой пробегать, лол. Пешеходам и автомобилистам в ГТА-лайк играх вроде как проще с навигацией, т.к. у них есть фиксированные вейпойнты, а от игрока они чаще убегают, чем набегают.
>>05329
>Неважно, высота это или длина.
Важно. С высоты ты гарантированно можешь увидеть много чанков города сразу. От первого лица же ты смотришь почти на уровне асфальта, и любой, даже одноэтажный дом, закрывает тебе обзор, даже небольшая группа деревьев закрывает обзор. По идее, если делать только короткие улицы, т.е. как можно больше поворотов, то никаких болванок на большом расстоянии при взгляде от первого лица не нужно.
Я ведь уже упоминал кривые дороги ГТА? Я думаю, это тоже своего рода оптимизация. Когда дорога часто виляет, оканчивается тупиком или развилкой - игрок редко видит далеко. Это позволяет не загружать машины и пешеходов в большом радиусе. Можно даже вычислить поле обзора игрока и не грузить машины на соседних дорогах, несмотря на то, что они близко к игроку. В моей игре практически невозможно сделать "кривую" дорогу из-за строго прямых углов, можно только ограничить максимальную длину прямого отрезка дороги. Нужно будет попробовать сгенерировать город с учётом максимальной длины прямого отрезка дороги... Как раз недавно видел пример большой сети дорог, в которой много тупиков, но нет островов, и я, кажется, знаю способ, как это реализовать (одно слово: рекурсия). Жаль, что раньше не догадался.
>рокстары, например, настолько хороши в этом, что ты даже помыслить не можешь о том, что они юзают болванки на рельсах без физики.
А ты уверен, что они их юзают? Есть какие-то доказательства? То, как машины появляются из воздуха и исчезают - я видел. То, как машины переключают свои графические LODы - тоже вроде бы видел. Но вот явного переключения физики не помню. Всё-таки в ГТА всегда была как минимум подвеска, и резкое включение физики выдавало бы себя беспричинно дрыгающейся подвеской. Не знаю, может, есть способ зафиксировать подвеску и сгладить переход?
>физика очень затратна для компа. Не доросли компы ещё
Ой, не смеши меня. На первом скриншоте дофига машин и FPS был в пределах играбельного, если я правильно помню. На втором скриншоте ровно 35 машин с фарами (VSync включён), правда, они здесь, возможно, в спящем состоянии, но это вряд ли (мне не удалось стабильно усыплять автомобили VehicleBody, что-то их пробуждает, из-за чего я мучился тем, что KinematicBody в любой ситуации способен толкать VehicleBody).
Ты скажешь - это примитивные машины. Согласен. Но даже они по ощущениям вполне неплохие: подвеска, сцепление, плавный разгон и торможение. Я не специалист, но как игроку мне и так нравится. Машины в ГТА по существу отличаются только повреждаемым корпусом, и высока вероятность, что технически они подобны VehicleBody, тем более что в движке RAGE используется Bullet Physics (т.е. никакой тебе многопоточности и CUDA ядер из PhysX).
Но я не зря упоминал выше BeamNG.drive - вот там реально корпус симулируется как софтбоди или что-то вроде того, в результате на моём компе от силы 2-3 машины на пустой сцене BeamNG.drive сравнительно играбельны. А в ГТА корпус не симулируется, в старых ГТА (3/VC/SA) все повреждения смоделированы вручную и хранятся в архиве мешей (.img). В GTA IV добавили сравнительно сложную сминаемость, но она реагирует только на сильные удары, в остальные моменты, судя по всему, она "спит" и не грузит процессор. В GTA V её порезали, а в GTA Online весь транспорт из DLC почти никак не повреждается, можно только двери и бамперы оторвать (честно - халтура, не ожидал такого от Rockstar). Я, кстати, довольно часто пробовал создать пробку на большой дороге (прогоняя водителей и дожидаясь новых машин) в разных ГТА и затем взрывать машины - было вполне играбельно, а ведь такую ситуацию в нормальном геймплее не встречаешь, т.е. это экстремальный случай для игры.
Так что, имхо, не в физике дело. Если хочешь, могу ещё раз сделать стресс-тест на базе VehicleBody, добавив рандомное движение, чтобы физический движок не расселялся. Но учитывай, что в нормальном геймплее ГТА-лайк сотен машин никогда не бывает, даже два-три десятка легковушек занимают существенную площадь.
>несколько однотипных инстансов рассматриваются как одна сущность и физический движок считает эту одну сущность
Слышал что-то подобное, но для машин, даже "аркадных" из ГТА, такую оптимизацию никак не применишь: каждая машина имеет индивидуальную конфигурацию физики и поведение.
>толпы зомби, реализованные как поток жидкости
Во-первых, зомби в общем случае абсолютно одинаковые, в отличие от машин ГТА. Во-вторых, зомби можно сделать на кинематикбоди, т.к. у них нет никакой сложной подвески и т.д. В-третьих, движение зомби как потока жидкости - это оптимизация навигации, чтобы зомби не грузили систему, обходя друг друга, т.е. к физике это не имеет прямого отношения, наоборот, физику такая симуляция только нагружает, разгружая систему индивидуальной навигации (астар или навмеш). Наконец, симуляция жидкости - это не "одна сущность". Насколько мне известно, типичная симуляция жидкости происходит в виде создания большого количества мелких шариков ригидбоди, положения которых затем "обтягиваются" 2D/3D мешем, имитируя один большой объект. Чем больше количество и чем меньше размеры ригидбоди - тем точнее симуляция, в идеале они должны быть размером с молекулы воды. Впрочем, я мало интересовался этой темой, знаю только что есть разные подходы, но в большинстве случаев вот эти "молекулы воды" движутся независимо и эффект потока возникает только благодаря эффекту эмерджентности (прямо как настоящая вода, если я правильно понимаю).
Про зомби я слышал, кстати, из обсуждения обновлений 7DTD, когда они оптимизировали игру, убрав индивидуальную навигацию зомби, т.е. с какого-то апдейта зомби ходят за "лидером", и благодаря этому игра стала шустрее, но игрокам это не очень понравилось. В общем, в случае зомби дело не в физике, а в навигации, т.к. зомби вынуждены постоянно обновлять путь до игрока, иначе они будут мимо него всей толпой пробегать, лол. Пешеходам и автомобилистам в ГТА-лайк играх вроде как проще с навигацией, т.к. у них есть фиксированные вейпойнты, а от игрока они чаще убегают, чем набегают.
Я посмотрел несколько видео про баги Cyberpunk 2077. Похоже, что в некоторых случаях машины всё же материализуются из воздуха и иногда дематериализуются. Возможно, это добавили в какой-то версии, или поведение игры на разных платформах разное. Или они сделали разные виды оптимизации, но не смогли их друг с другом стабильно соединить...
>>05329
Важно. С высоты ты гарантированно можешь увидеть много чанков города сразу. От первого лица же ты смотришь почти на уровне асфальта, и любой, даже одноэтажный дом, закрывает тебе обзор, даже небольшая группа деревьев закрывает обзор. По идее, если делать только короткие улицы, т.е. как можно больше поворотов, то никаких болванок на большом расстоянии при взгляде от первого лица не нужно.
Я ведь уже упоминал кривые дороги ГТА? Я думаю, это тоже своего рода оптимизация. Когда дорога часто виляет, оканчивается тупиком или развилкой - игрок редко видит далеко. Это позволяет не загружать машины и пешеходов в большом радиусе. Можно даже вычислить поле обзора игрока и не грузить машины на соседних дорогах, несмотря на то, что они близко к игроку. В моей игре практически невозможно сделать "кривую" дорогу из-за строго прямых углов, можно только ограничить максимальную длину прямого отрезка дороги. Нужно будет попробовать сгенерировать город с учётом максимальной длины прямого отрезка дороги... Как раз недавно видел пример большой сети дорог, в которой много тупиков, но нет островов, и я, кажется, знаю способ, как это реализовать (одно слово: рекурсия). Жаль, что раньше не догадался.
А ты уверен, что они их юзают? Есть какие-то доказательства? То, как машины появляются из воздуха и исчезают - я видел. То, как машины переключают свои графические LODы - тоже вроде бы видел. Но вот явного переключения физики не помню. Всё-таки в ГТА всегда была как минимум подвеска, и резкое включение физики выдавало бы себя беспричинно дрыгающейся подвеской. Не знаю, может, есть способ зафиксировать подвеску и сгладить переход?
Ой, не смеши меня. На первом скриншоте дофига машин и FPS был в пределах играбельного, если я правильно помню. На втором скриншоте ровно 35 машин с фарами (VSync включён), правда, они здесь, возможно, в спящем состоянии, но это вряд ли (мне не удалось стабильно усыплять автомобили VehicleBody, что-то их пробуждает, из-за чего я мучился тем, что KinematicBody в любой ситуации способен толкать VehicleBody).
Ты скажешь - это примитивные машины. Согласен. Но даже они по ощущениям вполне неплохие: подвеска, сцепление, плавный разгон и торможение. Я не специалист, но как игроку мне и так нравится. Машины в ГТА по существу отличаются только повреждаемым корпусом, и высока вероятность, что технически они подобны VehicleBody, тем более что в движке RAGE используется Bullet Physics (т.е. никакой тебе многопоточности и CUDA ядер из PhysX).
Но я не зря упоминал выше BeamNG.drive - вот там реально корпус симулируется как софтбоди или что-то вроде того, в результате на моём компе от силы 2-3 машины на пустой сцене BeamNG.drive сравнительно играбельны. А в ГТА корпус не симулируется, в старых ГТА (3/VC/SA) все повреждения смоделированы вручную и хранятся в архиве мешей (.img). В GTA IV добавили сравнительно сложную сминаемость, но она реагирует только на сильные удары, в остальные моменты, судя по всему, она "спит" и не грузит процессор. В GTA V её порезали, а в GTA Online весь транспорт из DLC почти никак не повреждается, можно только двери и бамперы оторвать (честно - халтура, не ожидал такого от Rockstar). Я, кстати, довольно часто пробовал создать пробку на большой дороге (прогоняя водителей и дожидаясь новых машин) в разных ГТА и затем взрывать машины - было вполне играбельно, а ведь такую ситуацию в нормальном геймплее не встречаешь, т.е. это экстремальный случай для игры.
Так что, имхо, не в физике дело. Если хочешь, могу ещё раз сделать стресс-тест на базе VehicleBody, добавив рандомное движение, чтобы физический движок не расселялся. Но учитывай, что в нормальном геймплее ГТА-лайк сотен машин никогда не бывает, даже два-три десятка легковушек занимают существенную площадь.
Слышал что-то подобное, но для машин, даже "аркадных" из ГТА, такую оптимизацию никак не применишь: каждая машина имеет индивидуальную конфигурацию физики и поведение.
Во-первых, зомби в общем случае абсолютно одинаковые, в отличие от машин ГТА. Во-вторых, зомби можно сделать на кинематикбоди, т.к. у них нет никакой сложной подвески и т.д. В-третьих, движение зомби как потока жидкости - это оптимизация навигации, чтобы зомби не грузили систему, обходя друг друга, т.е. к физике это не имеет прямого отношения, наоборот, физику такая симуляция только нагружает, разгружая систему индивидуальной навигации (астар или навмеш). Наконец, симуляция жидкости - это не "одна сущность". Насколько мне известно, типичная симуляция жидкости происходит в виде создания большого количества мелких шариков ригидбоди, положения которых затем "обтягиваются" 2D/3D мешем, имитируя один большой объект. Чем больше количество и чем меньше размеры ригидбоди - тем точнее симуляция, в идеале они должны быть размером с молекулы воды. Впрочем, я мало интересовался этой темой, знаю только что есть разные подходы, но в большинстве случаев вот эти "молекулы воды" движутся независимо и эффект потока возникает только благодаря эффекту эмерджентности (прямо как настоящая вода, если я правильно понимаю).
Про зомби я слышал, кстати, из обсуждения обновлений 7DTD, когда они оптимизировали игру, убрав индивидуальную навигацию зомби, т.е. с какого-то апдейта зомби ходят за "лидером", и благодаря этому игра стала шустрее, но игрокам это не очень понравилось. В общем, в случае зомби дело не в физике, а в навигации, т.к. зомби вынуждены постоянно обновлять путь до игрока, иначе они будут мимо него всей толпой пробегать, лол. Пешеходам и автомобилистам в ГТА-лайк играх вроде как проще с навигацией, т.к. у них есть фиксированные вейпойнты, а от игрока они чаще убегают, чем набегают.
>>05329
>Неважно, высота это или длина.
Важно. С высоты ты гарантированно можешь увидеть много чанков города сразу. От первого лица же ты смотришь почти на уровне асфальта, и любой, даже одноэтажный дом, закрывает тебе обзор, даже небольшая группа деревьев закрывает обзор. По идее, если делать только короткие улицы, т.е. как можно больше поворотов, то никаких болванок на большом расстоянии при взгляде от первого лица не нужно.
Я ведь уже упоминал кривые дороги ГТА? Я думаю, это тоже своего рода оптимизация. Когда дорога часто виляет, оканчивается тупиком или развилкой - игрок редко видит далеко. Это позволяет не загружать машины и пешеходов в большом радиусе. Можно даже вычислить поле обзора игрока и не грузить машины на соседних дорогах, несмотря на то, что они близко к игроку. В моей игре практически невозможно сделать "кривую" дорогу из-за строго прямых углов, можно только ограничить максимальную длину прямого отрезка дороги. Нужно будет попробовать сгенерировать город с учётом максимальной длины прямого отрезка дороги... Как раз недавно видел пример большой сети дорог, в которой много тупиков, но нет островов, и я, кажется, знаю способ, как это реализовать (одно слово: рекурсия). Жаль, что раньше не догадался.
>рокстары, например, настолько хороши в этом, что ты даже помыслить не можешь о том, что они юзают болванки на рельсах без физики.
А ты уверен, что они их юзают? Есть какие-то доказательства? То, как машины появляются из воздуха и исчезают - я видел. То, как машины переключают свои графические LODы - тоже вроде бы видел. Но вот явного переключения физики не помню. Всё-таки в ГТА всегда была как минимум подвеска, и резкое включение физики выдавало бы себя беспричинно дрыгающейся подвеской. Не знаю, может, есть способ зафиксировать подвеску и сгладить переход?
>физика очень затратна для компа. Не доросли компы ещё
Ой, не смеши меня. На первом скриншоте дофига машин и FPS был в пределах играбельного, если я правильно помню. На втором скриншоте ровно 35 машин с фарами (VSync включён), правда, они здесь, возможно, в спящем состоянии, но это вряд ли (мне не удалось стабильно усыплять автомобили VehicleBody, что-то их пробуждает, из-за чего я мучился тем, что KinematicBody в любой ситуации способен толкать VehicleBody).
Ты скажешь - это примитивные машины. Согласен. Но даже они по ощущениям вполне неплохие: подвеска, сцепление, плавный разгон и торможение. Я не специалист, но как игроку мне и так нравится. Машины в ГТА по существу отличаются только повреждаемым корпусом, и высока вероятность, что технически они подобны VehicleBody, тем более что в движке RAGE используется Bullet Physics (т.е. никакой тебе многопоточности и CUDA ядер из PhysX).
Но я не зря упоминал выше BeamNG.drive - вот там реально корпус симулируется как софтбоди или что-то вроде того, в результате на моём компе от силы 2-3 машины на пустой сцене BeamNG.drive сравнительно играбельны. А в ГТА корпус не симулируется, в старых ГТА (3/VC/SA) все повреждения смоделированы вручную и хранятся в архиве мешей (.img). В GTA IV добавили сравнительно сложную сминаемость, но она реагирует только на сильные удары, в остальные моменты, судя по всему, она "спит" и не грузит процессор. В GTA V её порезали, а в GTA Online весь транспорт из DLC почти никак не повреждается, можно только двери и бамперы оторвать (честно - халтура, не ожидал такого от Rockstar). Я, кстати, довольно часто пробовал создать пробку на большой дороге (прогоняя водителей и дожидаясь новых машин) в разных ГТА и затем взрывать машины - было вполне играбельно, а ведь такую ситуацию в нормальном геймплее не встречаешь, т.е. это экстремальный случай для игры.
Так что, имхо, не в физике дело. Если хочешь, могу ещё раз сделать стресс-тест на базе VehicleBody, добавив рандомное движение, чтобы физический движок не расселялся. Но учитывай, что в нормальном геймплее ГТА-лайк сотен машин никогда не бывает, даже два-три десятка легковушек занимают существенную площадь.
>несколько однотипных инстансов рассматриваются как одна сущность и физический движок считает эту одну сущность
Слышал что-то подобное, но для машин, даже "аркадных" из ГТА, такую оптимизацию никак не применишь: каждая машина имеет индивидуальную конфигурацию физики и поведение.
>толпы зомби, реализованные как поток жидкости
Во-первых, зомби в общем случае абсолютно одинаковые, в отличие от машин ГТА. Во-вторых, зомби можно сделать на кинематикбоди, т.к. у них нет никакой сложной подвески и т.д. В-третьих, движение зомби как потока жидкости - это оптимизация навигации, чтобы зомби не грузили систему, обходя друг друга, т.е. к физике это не имеет прямого отношения, наоборот, физику такая симуляция только нагружает, разгружая систему индивидуальной навигации (астар или навмеш). Наконец, симуляция жидкости - это не "одна сущность". Насколько мне известно, типичная симуляция жидкости происходит в виде создания большого количества мелких шариков ригидбоди, положения которых затем "обтягиваются" 2D/3D мешем, имитируя один большой объект. Чем больше количество и чем меньше размеры ригидбоди - тем точнее симуляция, в идеале они должны быть размером с молекулы воды. Впрочем, я мало интересовался этой темой, знаю только что есть разные подходы, но в большинстве случаев вот эти "молекулы воды" движутся независимо и эффект потока возникает только благодаря эффекту эмерджентности (прямо как настоящая вода, если я правильно понимаю).
Про зомби я слышал, кстати, из обсуждения обновлений 7DTD, когда они оптимизировали игру, убрав индивидуальную навигацию зомби, т.е. с какого-то апдейта зомби ходят за "лидером", и благодаря этому игра стала шустрее, но игрокам это не очень понравилось. В общем, в случае зомби дело не в физике, а в навигации, т.к. зомби вынуждены постоянно обновлять путь до игрока, иначе они будут мимо него всей толпой пробегать, лол. Пешеходам и автомобилистам в ГТА-лайк играх вроде как проще с навигацией, т.к. у них есть фиксированные вейпойнты, а от игрока они чаще убегают, чем набегают.
Пилю первую игру, застрял на этапе интерфейса.
Сделал так, чтобы при столкновении коллайдера с Area2D по сигналу менялась переменная здоровья. Но так и не нашел инструкцию, чтобы шкала здоровья на это реагировала, помогите.
Сделал так, чтобы при столкновении коллайдера с Area2D по сигналу менялась переменная здоровья. Но так и не нашел инструкцию, чтобы шкала здоровья на это реагировала, помогите.
>>05329
Я провёл некоторые эксперименты, и на моём компьютере результат таков: 128 машин с одним источником света (солнце) держатся на уровне 100 FPS. Но 128 машин, даже таких мелких, какие у меня здесь (двухместные) - это реально дохрена и на практике вообще не нужно. Я даже не смог заставить их ехать нормально, не переворачивая друг друга и не застревая друг на друге. С разумным количеством едущих по кругу машин FPS на уровне 400. И это при том, что все сразу эти 30 машин от первого лица никак не увидеть на данной карте (примерно 100 на 200 метров): дома в середине будут ограничивать обзор на примерно половину машин, значит, хватило бы 15-20 штук.
Узкие места:
1. Дроуколлы. Фары пришлось отключить, т.к. даже при 1 источнике света на машину получалось слишком много дроуколлов. Тут без батчинга со стороны движка никак проблему не решить, т.к., например, колёса я не могу склеить с корпусом в один меш. Хорошо бы портировать на 4.0 и посмотреть результаты там...
2. Area - их в таких количествах (сотни) нереально использовать, сажают FPS до единиц одним своим присутствием. Рейкасты, напротив, кажутся почти бесплатными (512 рейкастов на скриншоте), но они слишком тонкие и промахиваются или попадают не туда, из-за чего возникают сложности. Но это всё не относится к физике, это вопрос навигации с учётом препятствий.
Интересно, что GDScript тут не оказался узким местом. Я там делаю несколько затратных операций с векторами каждый физический тик в каждой машине, чтобы рулить к цели и выбирать следующую цель. Но даже в худшем случае вызовы _physics_process тратили около 2 мс, что терпимо для столь избыточного количества машин.
Когда-нибудь я и систему повреждений корпуса реализую, но она будет в стиле GTA 3/VC/SA, т.е. с заранее заданными повреждёнными моделями. Сомневаюсь, что это даст какую-то существенную нагрузку, если не считать дроуколлы, это ведь не настоящая физическая симуляция как в BeamNG.drive.
Основная проблема у меня сейчас - как сделать машины умнее, а их движения точнее, а то они слишком легко сталкиваются, иногда не могут вписаться в поворот и т.д. Рейкасты не всегда помогают: сделал алгоритм отъезда от стены, но стоило рейкасту промахнуться мимо угла, как машина снова намертво упёрлась в этот угол. Но, в целом, уже и так прикольно ездят. Сложнее всего было подобрать формулу для правильного выруливания на цель.
Есть мысль сделать свою машину на RigidBody, но об этом сейчас вообще не стоит задумываться. Я не ставил себе цели сделать гоночный или автомобильный симулятор, и в машинах я разбираюсь на уровне "ого, какая необычная форма корпуса"... Собственно, мне куда интереснее процедурно генерировать (собирать из модулей а-ля Crossout) разные формы корпуса, чем продвинутое вождение. Вряд ли такой модульный корпус будет напрягать физический движок: я тестил сборку большого ригидбоди из сотен коллиженшейпов - нормально работало вроде как (разумеется, на практике будет пара десятков машин по десятку коллиженшейпов на каждую)... А вот графически, да, без сборки в один меш будет дофига лишних дроуколлов, ждём 4.0.
>физика очень затратна для компа. Не доросли компы ещё
Я провёл некоторые эксперименты, и на моём компьютере результат таков: 128 машин с одним источником света (солнце) держатся на уровне 100 FPS. Но 128 машин, даже таких мелких, какие у меня здесь (двухместные) - это реально дохрена и на практике вообще не нужно. Я даже не смог заставить их ехать нормально, не переворачивая друг друга и не застревая друг на друге. С разумным количеством едущих по кругу машин FPS на уровне 400. И это при том, что все сразу эти 30 машин от первого лица никак не увидеть на данной карте (примерно 100 на 200 метров): дома в середине будут ограничивать обзор на примерно половину машин, значит, хватило бы 15-20 штук.
Узкие места:
1. Дроуколлы. Фары пришлось отключить, т.к. даже при 1 источнике света на машину получалось слишком много дроуколлов. Тут без батчинга со стороны движка никак проблему не решить, т.к., например, колёса я не могу склеить с корпусом в один меш. Хорошо бы портировать на 4.0 и посмотреть результаты там...
2. Area - их в таких количествах (сотни) нереально использовать, сажают FPS до единиц одним своим присутствием. Рейкасты, напротив, кажутся почти бесплатными (512 рейкастов на скриншоте), но они слишком тонкие и промахиваются или попадают не туда, из-за чего возникают сложности. Но это всё не относится к физике, это вопрос навигации с учётом препятствий.
Интересно, что GDScript тут не оказался узким местом. Я там делаю несколько затратных операций с векторами каждый физический тик в каждой машине, чтобы рулить к цели и выбирать следующую цель. Но даже в худшем случае вызовы _physics_process тратили около 2 мс, что терпимо для столь избыточного количества машин.
Когда-нибудь я и систему повреждений корпуса реализую, но она будет в стиле GTA 3/VC/SA, т.е. с заранее заданными повреждёнными моделями. Сомневаюсь, что это даст какую-то существенную нагрузку, если не считать дроуколлы, это ведь не настоящая физическая симуляция как в BeamNG.drive.
Основная проблема у меня сейчас - как сделать машины умнее, а их движения точнее, а то они слишком легко сталкиваются, иногда не могут вписаться в поворот и т.д. Рейкасты не всегда помогают: сделал алгоритм отъезда от стены, но стоило рейкасту промахнуться мимо угла, как машина снова намертво упёрлась в этот угол. Но, в целом, уже и так прикольно ездят. Сложнее всего было подобрать формулу для правильного выруливания на цель.
Есть мысль сделать свою машину на RigidBody, но об этом сейчас вообще не стоит задумываться. Я не ставил себе цели сделать гоночный или автомобильный симулятор, и в машинах я разбираюсь на уровне "ого, какая необычная форма корпуса"... Собственно, мне куда интереснее процедурно генерировать (собирать из модулей а-ля Crossout) разные формы корпуса, чем продвинутое вождение. Вряд ли такой модульный корпус будет напрягать физический движок: я тестил сборку большого ригидбоди из сотен коллиженшейпов - нормально работало вроде как (разумеется, на практике будет пара десятков машин по десятку коллиженшейпов на каждую)... А вот графически, да, без сборки в один меш будет дофига лишних дроуколлов, ждём 4.0.
>>05329
Я провёл некоторые эксперименты, и на моём компьютере результат таков: 128 машин с одним источником света (солнце) держатся на уровне 100 FPS. Но 128 машин, даже таких мелких, какие у меня здесь (двухместные) - это реально дохрена и на практике вообще не нужно. Я даже не смог заставить их ехать нормально, не переворачивая друг друга и не застревая друг на друге. С разумным количеством едущих по кругу машин FPS на уровне 400. И это при том, что все сразу эти 30 машин от первого лица никак не увидеть на данной карте (примерно 100 на 200 метров): дома в середине будут ограничивать обзор на примерно половину машин, значит, хватило бы 15-20 штук.
Узкие места:
1. Дроуколлы. Фары пришлось отключить, т.к. даже при 1 источнике света на машину получалось слишком много дроуколлов. Тут без батчинга со стороны движка никак проблему не решить, т.к., например, колёса я не могу склеить с корпусом в один меш. Хорошо бы портировать на 4.0 и посмотреть результаты там...
2. Area - их в таких количествах (сотни) нереально использовать, сажают FPS до единиц одним своим присутствием. Рейкасты, напротив, кажутся почти бесплатными (512 рейкастов на скриншоте), но они слишком тонкие и промахиваются или попадают не туда, из-за чего возникают сложности. Но это всё не относится к физике, это вопрос навигации с учётом препятствий.
Интересно, что GDScript тут не оказался узким местом. Я там делаю несколько затратных операций с векторами каждый физический тик в каждой машине, чтобы рулить к цели и выбирать следующую цель. Но даже в худшем случае вызовы _physics_process тратили около 2 мс, что терпимо для столь избыточного количества машин.
Когда-нибудь я и систему повреждений корпуса реализую, но она будет в стиле GTA 3/VC/SA, т.е. с заранее заданными повреждёнными моделями. Сомневаюсь, что это даст какую-то существенную нагрузку, если не считать дроуколлы, это ведь не настоящая физическая симуляция как в BeamNG.drive.
Основная проблема у меня сейчас - как сделать машины умнее, а их движения точнее, а то они слишком легко сталкиваются, иногда не могут вписаться в поворот и т.д. Рейкасты не всегда помогают: сделал алгоритм отъезда от стены, но стоило рейкасту промахнуться мимо угла, как машина снова намертво упёрлась в этот угол. Но, в целом, уже и так прикольно ездят. Сложнее всего было подобрать формулу для правильного выруливания на цель.
Есть мысль сделать свою машину на RigidBody, но об этом сейчас вообще не стоит задумываться. Я не ставил себе цели сделать гоночный или автомобильный симулятор, и в машинах я разбираюсь на уровне "ого, какая необычная форма корпуса"... Собственно, мне куда интереснее процедурно генерировать (собирать из модулей а-ля Crossout) разные формы корпуса, чем продвинутое вождение. Вряд ли такой модульный корпус будет напрягать физический движок: я тестил сборку большого ригидбоди из сотен коллиженшейпов - нормально работало вроде как (разумеется, на практике будет пара десятков машин по десятку коллиженшейпов на каждую)... А вот графически, да, без сборки в один меш будет дофига лишних дроуколлов, ждём 4.0.
>физика очень затратна для компа. Не доросли компы ещё
Я провёл некоторые эксперименты, и на моём компьютере результат таков: 128 машин с одним источником света (солнце) держатся на уровне 100 FPS. Но 128 машин, даже таких мелких, какие у меня здесь (двухместные) - это реально дохрена и на практике вообще не нужно. Я даже не смог заставить их ехать нормально, не переворачивая друг друга и не застревая друг на друге. С разумным количеством едущих по кругу машин FPS на уровне 400. И это при том, что все сразу эти 30 машин от первого лица никак не увидеть на данной карте (примерно 100 на 200 метров): дома в середине будут ограничивать обзор на примерно половину машин, значит, хватило бы 15-20 штук.
Узкие места:
1. Дроуколлы. Фары пришлось отключить, т.к. даже при 1 источнике света на машину получалось слишком много дроуколлов. Тут без батчинга со стороны движка никак проблему не решить, т.к., например, колёса я не могу склеить с корпусом в один меш. Хорошо бы портировать на 4.0 и посмотреть результаты там...
2. Area - их в таких количествах (сотни) нереально использовать, сажают FPS до единиц одним своим присутствием. Рейкасты, напротив, кажутся почти бесплатными (512 рейкастов на скриншоте), но они слишком тонкие и промахиваются или попадают не туда, из-за чего возникают сложности. Но это всё не относится к физике, это вопрос навигации с учётом препятствий.
Интересно, что GDScript тут не оказался узким местом. Я там делаю несколько затратных операций с векторами каждый физический тик в каждой машине, чтобы рулить к цели и выбирать следующую цель. Но даже в худшем случае вызовы _physics_process тратили около 2 мс, что терпимо для столь избыточного количества машин.
Когда-нибудь я и систему повреждений корпуса реализую, но она будет в стиле GTA 3/VC/SA, т.е. с заранее заданными повреждёнными моделями. Сомневаюсь, что это даст какую-то существенную нагрузку, если не считать дроуколлы, это ведь не настоящая физическая симуляция как в BeamNG.drive.
Основная проблема у меня сейчас - как сделать машины умнее, а их движения точнее, а то они слишком легко сталкиваются, иногда не могут вписаться в поворот и т.д. Рейкасты не всегда помогают: сделал алгоритм отъезда от стены, но стоило рейкасту промахнуться мимо угла, как машина снова намертво упёрлась в этот угол. Но, в целом, уже и так прикольно ездят. Сложнее всего было подобрать формулу для правильного выруливания на цель.
Есть мысль сделать свою машину на RigidBody, но об этом сейчас вообще не стоит задумываться. Я не ставил себе цели сделать гоночный или автомобильный симулятор, и в машинах я разбираюсь на уровне "ого, какая необычная форма корпуса"... Собственно, мне куда интереснее процедурно генерировать (собирать из модулей а-ля Crossout) разные формы корпуса, чем продвинутое вождение. Вряд ли такой модульный корпус будет напрягать физический движок: я тестил сборку большого ригидбоди из сотен коллиженшейпов - нормально работало вроде как (разумеется, на практике будет пара десятков машин по десятку коллиженшейпов на каждую)... А вот графически, да, без сборки в один меш будет дофига лишних дроуколлов, ждём 4.0.
>>05563
А как у тебя шкала здоровья реализована?
Если у тебя это:
https://docs.godotengine.org/en/stable/classes/class_textureprogress.html
Тогда посмотри на параметры этого класса:
https://docs.godotengine.org/en/stable/classes/class_range.html
Тебе нужно установить:
- max_value - максимальное здоровье;
- min_value - минимальное здоровье;
- value - текущее здоровье.
Когда у тебя переменная уровня здоровья меняется, нужно просто записать это новое значение в value TextureProgress.
>инструкцию, чтобы шкала здоровья на это реагировала
А как у тебя шкала здоровья реализована?
Если у тебя это:
https://docs.godotengine.org/en/stable/classes/class_textureprogress.html
Тогда посмотри на параметры этого класса:
https://docs.godotengine.org/en/stable/classes/class_range.html
Тебе нужно установить:
- max_value - максимальное здоровье;
- min_value - минимальное здоровье;
- value - текущее здоровье.
Когда у тебя переменная уровня здоровья меняется, нужно просто записать это новое значение в value TextureProgress.
>>05563
В ноде, которую могут видеть и шкала здоровья и коллайдер врага (назовём её game) создаёшь свой сигнал:
signal hit(amount)
В функции _ready шкалы здоровья подписываешься на этот сигнал:
game.connect("hit", self, "on_hit")
Заметь, сигнал берётся из ноды game, а обработчик сигнала указывается как свой собственный метод on_hit
В коллайдере, когда с ним сталкивается уязвимая для него сущность, коллайдер наносит её урон N и переизлучает сигнал:
game.emit_signal("hit", N)
Подписанная на этот сигнал нода примет его и обработает в своей функции.
Таким образом, мы свели зависимость нод друг от друга к разумному минимуму: ноды не знают о друг друге, но все ноды знают game.
> чтобы шкала здоровья на это реагировала
В ноде, которую могут видеть и шкала здоровья и коллайдер врага (назовём её game) создаёшь свой сигнал:
signal hit(amount)
В функции _ready шкалы здоровья подписываешься на этот сигнал:
game.connect("hit", self, "on_hit")
Заметь, сигнал берётся из ноды game, а обработчик сигнала указывается как свой собственный метод on_hit
В коллайдере, когда с ним сталкивается уязвимая для него сущность, коллайдер наносит её урон N и переизлучает сигнал:
game.emit_signal("hit", N)
Подписанная на этот сигнал нода примет его и обработает в своей функции.
Таким образом, мы свели зависимость нод друг от друга к разумному минимуму: ноды не знают о друг друге, но все ноды знают game.
Есть более элегантные варики как обращаться в функции к приконнекченной ноде, кроме как отправлять её в сигнале после остальных параметров?
тут вроде понятнее что-то подобное спросил чел:
https://godotengine.org/qa/38499/get-the-node-that-trigger-a-signal
тут вроде понятнее что-то подобное спросил чел:
https://godotengine.org/qa/38499/get-the-node-that-trigger-a-signal
>>05754
Что может быть элегантнее, это же классический Sender в коллбэках дельфийских дидов!
> более элегантные варики
> кроме как отправлять её в сигнале
Что может быть элегантнее, это же классический Sender в коллбэках дельфийских дидов!
>>05755
ну я думал есть уже встроенное решение типа self
а то странно, что функция чё-то там решает, а для кого решает даже не знает
ну я думал есть уже встроенное решение типа self
а то странно, что функция чё-то там решает, а для кого решает даже не знает
>>05757
Ничего странного. По умолчанию ноды ничего не знают. Если тебе надо, чтобы знали - в движке есть проверенный механизм дать им столько знания, сколько тебе нужно по диздоку.
Ничего странного. По умолчанию ноды ничего не знают. Если тебе надо, чтобы знали - в движке есть проверенный механизм дать им столько знания, сколько тебе нужно по диздоку.
>>05744
И в результате ты не можешь протестировать ноду отдельно от своей глобальной сущности game. Нехорошо. Хуан дал тебе F6 - пользуйся, а ты вместо этого глобальные сущности делаешь.
Моё предложение:
1. Нода Player объявляет сигнал "hurt(new_health)".
2. Нода HealthBar имеет метод "_on_hurt(new_health)".
3. Нода Game связывает ноды между собой:
Результат:
1. Player может бегать по пустой сцене/в вакууме.
2. Вид HealthBar можно проверить в один клик - F6.
3. Все связи в одном месте - в Game, их легко править.
4. Можно создать новый Game, который будет связывать другие ноды или в другом порядке. Какие-то ноды могут находиться в сцене без привязки - их не придётся удалять перед запуском игры из-за обращения к некорректному Game.
5. Практически все ноды, за исключением самого Game, могут быть безболезненно перенесены в другой проект, потому что всё, что требуется для их использования - ловить их сигналы или подключать их обработчики сигналов к каким-либо сигналам. Можно просто закинуть сцену из одного проекта в другой и всё запустится сразу, останется только по желанию связать сигналы/обработчики.
>Таким образом, мы свели зависимость нод друг от друга к разумному минимуму: ноды не знают о друг друге, но все ноды знают game.
И в результате ты не можешь протестировать ноду отдельно от своей глобальной сущности game. Нехорошо. Хуан дал тебе F6 - пользуйся, а ты вместо этого глобальные сущности делаешь.
Моё предложение:
1. Нода Player объявляет сигнал "hurt(new_health)".
2. Нода HealthBar имеет метод "_on_hurt(new_health)".
3. Нода Game связывает ноды между собой:
>_player.connect("hurt", _health_bar, "_on_hurt")
Результат:
1. Player может бегать по пустой сцене/в вакууме.
2. Вид HealthBar можно проверить в один клик - F6.
3. Все связи в одном месте - в Game, их легко править.
4. Можно создать новый Game, который будет связывать другие ноды или в другом порядке. Какие-то ноды могут находиться в сцене без привязки - их не придётся удалять перед запуском игры из-за обращения к некорректному Game.
5. Практически все ноды, за исключением самого Game, могут быть безболезненно перенесены в другой проект, потому что всё, что требуется для их использования - ловить их сигналы или подключать их обработчики сигналов к каким-либо сигналам. Можно просто закинуть сцену из одного проекта в другой и всё запустится сразу, останется только по желанию связать сигналы/обработчики.
>>05772
Почему глобальной? Можешь объявлять переменную отдельно в каждой ноде, передавать ссылку на имеющуюся сущность в _ready и проверять на нуль перед каждым обращением к ней, если нравиться ебаться, потому что безыгорные евангелисты ООП назвали синглтон антипаттерном.
А мне не нравится ебаться с кодом ради чьего-то пиздежа. Я вижу, что в игровом приложении есть необходимость в синглтоне "игра", который будет держать как минимум игровые правила всегда пока приложение запущено, даже в режиме главного меню, даже после геймовера. А раз есть необходимость - будет и сущность.
> глобальной сущности
Почему глобальной? Можешь объявлять переменную отдельно в каждой ноде, передавать ссылку на имеющуюся сущность в _ready и проверять на нуль перед каждым обращением к ней, если нравиться ебаться, потому что безыгорные евангелисты ООП назвали синглтон антипаттерном.
А мне не нравится ебаться с кодом ради чьего-то пиздежа. Я вижу, что в игровом приложении есть необходимость в синглтоне "игра", который будет держать как минимум игровые правила всегда пока приложение запущено, даже в режиме главного меню, даже после геймовера. А раз есть необходимость - будет и сущность.
>>05773
Потому что множество разных объектов по всему проекту обращаются к одному-единственному, от корректности интерфейсов и внутреннего состояния зависит весь проект?
Это ничего не меняет. Глобальная сущность остаётся глобальной, и ты обращаешься к ней из кучи разных скриптов, надеясь на то, что она будет в нужном тебе состоянии.
Ты мой пост вообще читал? Я не против ноды Game. Я и сам к ней в результате пришёл, потому что так банально проще управлять. Я против твоего подхода, в котором ты создаёшь сигналы в глобальной ноде, а потом из сотни мелких нод обращаешься к этой глобальной.
Вот пример, забыл написать: я сделал игру, опубликовал её на гитхаб под открытой лицензией, ты нашёл её, заинтересовался отдельными игровыми элементами и хочешь забрать их в свою игру. Если я сделал проект как ты предлагаешь, тебе придётся создавать/обновлять свой Game каким-то набором сигналов, без этого вообще ничего не заработает. Если я сделал как я предлагаю, ты можешь просто закинуть мою ноду в свой проект, а затем подключить её так, как пожелаешь, не меняя её код, а можешь и не подключать или подключить только частично. Т.е. в твоём проекте может вообще не быть Game или оно может иметь другое название, но мои ноды будут работать в твоём проекте так, будто всегда в нём были.
Также в документации движка предлагают объявлять сигналы в самом начале скрипта. И не зря: так их будет видно сразу после открытия скрипта, чтобы знать, что этот скрипт пытается сказать внешнему миру. А когда ты собираешь все сигналы в одном глобальном скрипте, получается неразбериха: непонятно, кому принадлежат эти сигналы, кто их излучает, кто получает. Придётся искать все места вызовов game.emit_signal() и game.connect(), что в большом проекте будет сложно. Так что лучше всего собирать в глобальном Game только connect'ы, а объявление сигналов и обработчики делать только там, где они реально нужны.
>Почему глобальной?
Потому что множество разных объектов по всему проекту обращаются к одному-единственному, от корректности интерфейсов и внутреннего состояния зависит весь проект?
>Можешь объявлять переменную отдельно в каждой ноде, передавать ссылку на имеющуюся сущность в _ready и проверять на нуль перед каждым обращением к ней,
Это ничего не меняет. Глобальная сущность остаётся глобальной, и ты обращаешься к ней из кучи разных скриптов, надеясь на то, что она будет в нужном тебе состоянии.
>необходимость в синглтоне "игра"
Ты мой пост вообще читал? Я не против ноды Game. Я и сам к ней в результате пришёл, потому что так банально проще управлять. Я против твоего подхода, в котором ты создаёшь сигналы в глобальной ноде, а потом из сотни мелких нод обращаешься к этой глобальной.
Вот пример, забыл написать: я сделал игру, опубликовал её на гитхаб под открытой лицензией, ты нашёл её, заинтересовался отдельными игровыми элементами и хочешь забрать их в свою игру. Если я сделал проект как ты предлагаешь, тебе придётся создавать/обновлять свой Game каким-то набором сигналов, без этого вообще ничего не заработает. Если я сделал как я предлагаю, ты можешь просто закинуть мою ноду в свой проект, а затем подключить её так, как пожелаешь, не меняя её код, а можешь и не подключать или подключить только частично. Т.е. в твоём проекте может вообще не быть Game или оно может иметь другое название, но мои ноды будут работать в твоём проекте так, будто всегда в нём были.
Также в документации движка предлагают объявлять сигналы в самом начале скрипта. И не зря: так их будет видно сразу после открытия скрипта, чтобы знать, что этот скрипт пытается сказать внешнему миру. А когда ты собираешь все сигналы в одном глобальном скрипте, получается неразбериха: непонятно, кому принадлежат эти сигналы, кто их излучает, кто получает. Придётся искать все места вызовов game.emit_signal() и game.connect(), что в большом проекте будет сложно. Так что лучше всего собирать в глобальном Game только connect'ы, а объявление сигналов и обработчики делать только там, где они реально нужны.
>>05773
Потому что множество разных объектов по всему проекту обращаются к одному-единственному, от корректности интерфейсов и внутреннего состояния зависит весь проект?
Это ничего не меняет. Глобальная сущность остаётся глобальной, и ты обращаешься к ней из кучи разных скриптов, надеясь на то, что она будет в нужном тебе состоянии.
Ты мой пост вообще читал? Я не против ноды Game. Я и сам к ней в результате пришёл, потому что так банально проще управлять. Я против твоего подхода, в котором ты создаёшь сигналы в глобальной ноде, а потом из сотни мелких нод обращаешься к этой глобальной.
Вот пример, забыл написать: я сделал игру, опубликовал её на гитхаб под открытой лицензией, ты нашёл её, заинтересовался отдельными игровыми элементами и хочешь забрать их в свою игру. Если я сделал проект как ты предлагаешь, тебе придётся создавать/обновлять свой Game каким-то набором сигналов, без этого вообще ничего не заработает. Если я сделал как я предлагаю, ты можешь просто закинуть мою ноду в свой проект, а затем подключить её так, как пожелаешь, не меняя её код, а можешь и не подключать или подключить только частично. Т.е. в твоём проекте может вообще не быть Game или оно может иметь другое название, но мои ноды будут работать в твоём проекте так, будто всегда в нём были.
Также в документации движка предлагают объявлять сигналы в самом начале скрипта. И не зря: так их будет видно сразу после открытия скрипта, чтобы знать, что этот скрипт пытается сказать внешнему миру. А когда ты собираешь все сигналы в одном глобальном скрипте, получается неразбериха: непонятно, кому принадлежат эти сигналы, кто их излучает, кто получает. Придётся искать все места вызовов game.emit_signal() и game.connect(), что в большом проекте будет сложно. Так что лучше всего собирать в глобальном Game только connect'ы, а объявление сигналов и обработчики делать только там, где они реально нужны.
>Почему глобальной?
Потому что множество разных объектов по всему проекту обращаются к одному-единственному, от корректности интерфейсов и внутреннего состояния зависит весь проект?
>Можешь объявлять переменную отдельно в каждой ноде, передавать ссылку на имеющуюся сущность в _ready и проверять на нуль перед каждым обращением к ней,
Это ничего не меняет. Глобальная сущность остаётся глобальной, и ты обращаешься к ней из кучи разных скриптов, надеясь на то, что она будет в нужном тебе состоянии.
>необходимость в синглтоне "игра"
Ты мой пост вообще читал? Я не против ноды Game. Я и сам к ней в результате пришёл, потому что так банально проще управлять. Я против твоего подхода, в котором ты создаёшь сигналы в глобальной ноде, а потом из сотни мелких нод обращаешься к этой глобальной.
Вот пример, забыл написать: я сделал игру, опубликовал её на гитхаб под открытой лицензией, ты нашёл её, заинтересовался отдельными игровыми элементами и хочешь забрать их в свою игру. Если я сделал проект как ты предлагаешь, тебе придётся создавать/обновлять свой Game каким-то набором сигналов, без этого вообще ничего не заработает. Если я сделал как я предлагаю, ты можешь просто закинуть мою ноду в свой проект, а затем подключить её так, как пожелаешь, не меняя её код, а можешь и не подключать или подключить только частично. Т.е. в твоём проекте может вообще не быть Game или оно может иметь другое название, но мои ноды будут работать в твоём проекте так, будто всегда в нём были.
Также в документации движка предлагают объявлять сигналы в самом начале скрипта. И не зря: так их будет видно сразу после открытия скрипта, чтобы знать, что этот скрипт пытается сказать внешнему миру. А когда ты собираешь все сигналы в одном глобальном скрипте, получается неразбериха: непонятно, кому принадлежат эти сигналы, кто их излучает, кто получает. Придётся искать все места вызовов game.emit_signal() и game.connect(), что в большом проекте будет сложно. Так что лучше всего собирать в глобальном Game только connect'ы, а объявление сигналов и обработчики делать только там, где они реально нужны.
>>05757
А зачем? Далеко не всем обработчикам нужно знать, чьё событие они обрабатывают. Обработчик может быть, например, на лампочке, которая включается и выключается - зачем ей знать, кто её включает и выключает? Аналогично со многими другими объектами. Если бы было какое-то "встроенное решение", оно бы впустую гоняло информацию, которая тебе редко нужна.
И что такого в том, чтобы явно передать ссылку?
Можешь назвать как угодно, в зависимости от контекста.
И т.д. По-моему, очень удобно.
>есть уже встроенное решение типа self
А зачем? Далеко не всем обработчикам нужно знать, чьё событие они обрабатывают. Обработчик может быть, например, на лампочке, которая включается и выключается - зачем ей знать, кто её включает и выключает? Аналогично со многими другими объектами. Если бы было какое-то "встроенное решение", оно бы впустую гоняло информацию, которая тебе редко нужна.
И что такого в том, чтобы явно передать ссылку?
>node1.connect("signal", node2, "_on_signal", [node1])
>func _on_signal(sender: Node) -> void: ...
Можешь назвать как угодно, в зависимости от контекста.
>func _on_enemy_dies(who: Enemy) -> void: ...
>func _on_music_plays(track: MusicTrack) -> void: ...
>func _on_new_hero_born(where: City) -> void: ...
И т.д. По-моему, очень удобно.
12 Кб, 1100x666>>05347
Смотрите, что сделал! Ни единого разрыва - цельная сеть дорог, по которой боты уже могут перемещаться в любом направлении благодаря AStar. Правда, изначальный алгоритм выдавал что-то вроде лабиринта, в котором из одной точки в другую был всего один маршрут - мне не понравилось. Кроме того, из-за расхождения дорог в разные стороны всё же получаются длинные улицы, на которых видно пропадающие/возникающие чанки. Всё-таки придётся делать LODы чанков, чтобы это исправить. А ещё я заметил, что мне хочется иметь больше пространства между дорогами (чтобы вписать туда парки, холмы, озёра, какие-нибудь фермерские поля), а это ещё сильнее увеличит прямые участки дорог...
Вот только беда: схематичная карта выглядит как минимум любопытно, но от первого лица это сплошной копипаст... пока что. С одной стороны, есть идея разнообразить карту, заранее создав прямоугольные зоны (аналог биомов), которые затем по-разному заполняются алгоритмом. Интересно будет, если получится соединить всё одной сетью дорог. Также интересно было бы варьировать конфигурацию сети дорог на разных участках, но я не уверен, как это сделать. С другой стороны, нужно доделать механизм заполнения чанков мешами/объектами, чтобы можно было просто делать контент и добавлять его сразу в генератор. А то сейчас любое дополнение - это боль правки сразу нескольких файлов. Нужна какая-то общая система, типа палитры, но сложно её придумать.
Кстати, кто-нибудь здесь уже слышал про метод merge_meshes?
https://github.com/godotengine/godot/pull/57661
Я вынужден был писать свой велосипед для склеивания мешей и так и не дописал его (поддерживает только сдвиг), а тут, оказывается, встроенное решение подогнали (в 3.5 уже доступно). Правда, не удалось его сразу использовать, решил остаться на своём велосипеде пока что. К тому же этот встроенный метод требует добавлять ноды MeshInstance прямо в дерево, а мой метод работает непосредственно с мешами Mesh независимо от MeshInstance. Непонятно правда, нужны ли эти техники в 4.0, т.к. там даже RigidBody кубики в движении рисуются всего за один дроуколл. Разве что чтобы количество нод в дереве уменьшить.
>Нужно будет попробовать сгенерировать город с учётом максимальной длины прямого отрезка дороги... Как раз недавно видел пример большой сети дорог, в которой много тупиков, но нет островов, и я, кажется, знаю способ, как это реализовать (одно слово: рекурсия).
Смотрите, что сделал! Ни единого разрыва - цельная сеть дорог, по которой боты уже могут перемещаться в любом направлении благодаря AStar. Правда, изначальный алгоритм выдавал что-то вроде лабиринта, в котором из одной точки в другую был всего один маршрут - мне не понравилось. Кроме того, из-за расхождения дорог в разные стороны всё же получаются длинные улицы, на которых видно пропадающие/возникающие чанки. Всё-таки придётся делать LODы чанков, чтобы это исправить. А ещё я заметил, что мне хочется иметь больше пространства между дорогами (чтобы вписать туда парки, холмы, озёра, какие-нибудь фермерские поля), а это ещё сильнее увеличит прямые участки дорог...
Вот только беда: схематичная карта выглядит как минимум любопытно, но от первого лица это сплошной копипаст... пока что. С одной стороны, есть идея разнообразить карту, заранее создав прямоугольные зоны (аналог биомов), которые затем по-разному заполняются алгоритмом. Интересно будет, если получится соединить всё одной сетью дорог. Также интересно было бы варьировать конфигурацию сети дорог на разных участках, но я не уверен, как это сделать. С другой стороны, нужно доделать механизм заполнения чанков мешами/объектами, чтобы можно было просто делать контент и добавлять его сразу в генератор. А то сейчас любое дополнение - это боль правки сразу нескольких файлов. Нужна какая-то общая система, типа палитры, но сложно её придумать.
Кстати, кто-нибудь здесь уже слышал про метод merge_meshes?
https://github.com/godotengine/godot/pull/57661
Я вынужден был писать свой велосипед для склеивания мешей и так и не дописал его (поддерживает только сдвиг), а тут, оказывается, встроенное решение подогнали (в 3.5 уже доступно). Правда, не удалось его сразу использовать, решил остаться на своём велосипеде пока что. К тому же этот встроенный метод требует добавлять ноды MeshInstance прямо в дерево, а мой метод работает непосредственно с мешами Mesh независимо от MeshInstance. Непонятно правда, нужны ли эти техники в 4.0, т.к. там даже RigidBody кубики в движении рисуются всего за один дроуколл. Разве что чтобы количество нод в дереве уменьшить.
12 Кб, 1100x666>>05347
Смотрите, что сделал! Ни единого разрыва - цельная сеть дорог, по которой боты уже могут перемещаться в любом направлении благодаря AStar. Правда, изначальный алгоритм выдавал что-то вроде лабиринта, в котором из одной точки в другую был всего один маршрут - мне не понравилось. Кроме того, из-за расхождения дорог в разные стороны всё же получаются длинные улицы, на которых видно пропадающие/возникающие чанки. Всё-таки придётся делать LODы чанков, чтобы это исправить. А ещё я заметил, что мне хочется иметь больше пространства между дорогами (чтобы вписать туда парки, холмы, озёра, какие-нибудь фермерские поля), а это ещё сильнее увеличит прямые участки дорог...
Вот только беда: схематичная карта выглядит как минимум любопытно, но от первого лица это сплошной копипаст... пока что. С одной стороны, есть идея разнообразить карту, заранее создав прямоугольные зоны (аналог биомов), которые затем по-разному заполняются алгоритмом. Интересно будет, если получится соединить всё одной сетью дорог. Также интересно было бы варьировать конфигурацию сети дорог на разных участках, но я не уверен, как это сделать. С другой стороны, нужно доделать механизм заполнения чанков мешами/объектами, чтобы можно было просто делать контент и добавлять его сразу в генератор. А то сейчас любое дополнение - это боль правки сразу нескольких файлов. Нужна какая-то общая система, типа палитры, но сложно её придумать.
Кстати, кто-нибудь здесь уже слышал про метод merge_meshes?
https://github.com/godotengine/godot/pull/57661
Я вынужден был писать свой велосипед для склеивания мешей и так и не дописал его (поддерживает только сдвиг), а тут, оказывается, встроенное решение подогнали (в 3.5 уже доступно). Правда, не удалось его сразу использовать, решил остаться на своём велосипеде пока что. К тому же этот встроенный метод требует добавлять ноды MeshInstance прямо в дерево, а мой метод работает непосредственно с мешами Mesh независимо от MeshInstance. Непонятно правда, нужны ли эти техники в 4.0, т.к. там даже RigidBody кубики в движении рисуются всего за один дроуколл. Разве что чтобы количество нод в дереве уменьшить.
>Нужно будет попробовать сгенерировать город с учётом максимальной длины прямого отрезка дороги... Как раз недавно видел пример большой сети дорог, в которой много тупиков, но нет островов, и я, кажется, знаю способ, как это реализовать (одно слово: рекурсия).
Смотрите, что сделал! Ни единого разрыва - цельная сеть дорог, по которой боты уже могут перемещаться в любом направлении благодаря AStar. Правда, изначальный алгоритм выдавал что-то вроде лабиринта, в котором из одной точки в другую был всего один маршрут - мне не понравилось. Кроме того, из-за расхождения дорог в разные стороны всё же получаются длинные улицы, на которых видно пропадающие/возникающие чанки. Всё-таки придётся делать LODы чанков, чтобы это исправить. А ещё я заметил, что мне хочется иметь больше пространства между дорогами (чтобы вписать туда парки, холмы, озёра, какие-нибудь фермерские поля), а это ещё сильнее увеличит прямые участки дорог...
Вот только беда: схематичная карта выглядит как минимум любопытно, но от первого лица это сплошной копипаст... пока что. С одной стороны, есть идея разнообразить карту, заранее создав прямоугольные зоны (аналог биомов), которые затем по-разному заполняются алгоритмом. Интересно будет, если получится соединить всё одной сетью дорог. Также интересно было бы варьировать конфигурацию сети дорог на разных участках, но я не уверен, как это сделать. С другой стороны, нужно доделать механизм заполнения чанков мешами/объектами, чтобы можно было просто делать контент и добавлять его сразу в генератор. А то сейчас любое дополнение - это боль правки сразу нескольких файлов. Нужна какая-то общая система, типа палитры, но сложно её придумать.
Кстати, кто-нибудь здесь уже слышал про метод merge_meshes?
https://github.com/godotengine/godot/pull/57661
Я вынужден был писать свой велосипед для склеивания мешей и так и не дописал его (поддерживает только сдвиг), а тут, оказывается, встроенное решение подогнали (в 3.5 уже доступно). Правда, не удалось его сразу использовать, решил остаться на своём велосипеде пока что. К тому же этот встроенный метод требует добавлять ноды MeshInstance прямо в дерево, а мой метод работает непосредственно с мешами Mesh независимо от MeshInstance. Непонятно правда, нужны ли эти техники в 4.0, т.к. там даже RigidBody кубики в движении рисуются всего за один дроуколл. Разве что чтобы количество нод в дереве уменьшить.
>>05783
Кстати, годаны, а на каком алгоритме был предыдущий искаробочный навигационный полигон? В чём были его минусы?
> благодаря AStar
Кстати, годаны, а на каком алгоритме был предыдущий искаробочный навигационный полигон? В чём были его минусы?
Запилена бесплатная приложуха, чтобы изучить гдскрипт с НУЛЯ
https://www.youtube.com/watch?v=ClU1WqQfCZM
Есть нули в треде? Велком!
https://www.youtube.com/watch?v=ClU1WqQfCZM
Есть нули в треде? Велком!
>>05886
О, я как раз вчера хотел скинуть ссылку, но забыл:
https://gdquest.itch.io/learn-godot-gdscript
Попробовал - там всё не просто для "нулей", а как для детей. Только текста много и мало игровой графики. Я б сделал возможность управлять черепашкой с пульта, как в КуМИРе было.
Ага, вот этот анон: >>04690
О, я как раз вчера хотел скинуть ссылку, но забыл:
https://gdquest.itch.io/learn-godot-gdscript
Попробовал - там всё не просто для "нулей", а как для детей. Только текста много и мало игровой графики. Я б сделал возможность управлять черепашкой с пульта, как в КуМИРе было.
>Есть нули в треде?
Ага, вот этот анон: >>04690
>А я нуль в программировании
>>04690
Я проходил курс и мне не помогло. Да и остальные уроки кроме приложения какая-то скучная хуйня которую надо изучать уже когда крепко встал на ноги и хочешь чего-то более продвинутого.
А что мне помогло, так это курсы на Zenva. Старые курсы на GDQuest тоже хороши. Я делал при этом стараясь запоминать предназначение разных нодов и кусков кода. А потом приспосабливал к своим нуждам когда пилил свою игру.
Я проходил курс и мне не помогло. Да и остальные уроки кроме приложения какая-то скучная хуйня которую надо изучать уже когда крепко встал на ноги и хочешь чего-то более продвинутого.
А что мне помогло, так это курсы на Zenva. Старые курсы на GDQuest тоже хороши. Я делал при этом стараясь запоминать предназначение разных нодов и кусков кода. А потом приспосабливал к своим нуждам когда пилил свою игру.
>>05986
А я вообще никаких курсов и уроков не читаю, зачем они?
Программировать научился с нуля за месяц по книге про Turbo Pascal. С тех пор ничего принципиально нового в программировании не обнаружил для себя. GDScript вообще даунгрейд по сравнению с Free Pascal, тут же почти ничего нет, кроме API движка.
А я вообще никаких курсов и уроков не читаю, зачем они?
Программировать научился с нуля за месяц по книге про Turbo Pascal. С тех пор ничего принципиально нового в программировании не обнаружил для себя. GDScript вообще даунгрейд по сравнению с Free Pascal, тут же почти ничего нет, кроме API движка.
>>05989
Ну на то он и скрипт. Ты с паскальскриптом сравни давай.
> GDScript вообще даунгрейд по сравнению с Free Pascal
Ну на то он и скрипт. Ты с паскальскриптом сравни давай.
>>05999
Поздно, я забрал деньги и теперь мне недоступно.
Поздно, я забрал деньги и теперь мне недоступно.
>>05991
JavaScript тоже скрипт, но там столько всего есть, что даже специально изобрели TypeScript, чтобы тупые веб-макаки реже стреляли себе в ногу. GDScript специально такой простой.
>Ну на то он и скрипт.
JavaScript тоже скрипт, но там столько всего есть, что даже специально изобрели TypeScript, чтобы тупые веб-макаки реже стреляли себе в ногу. GDScript специально такой простой.
Пытаюсь сконвертировать тему шындовс ХР в тему годота. Достал битмапы из длл-ки (shellstyle), сконвертил в пнг, добавил прозрачность. Приступил к работе. И тут выяснились несколько моментов:
1. Чекбокс в годоте это кнопка с иконкой! А в шындовс это ярлык с иконкой. В связи с чем, в годоте не предусмотрено отдельных юи-элементов для подсветки иконки чекбокса при наведении мышкой.
2. В шынде смена вида иконок при активации забиндена и на нажатие мышки и на отжатие, в годоте этого нет. Половина интерфейса разом отметается.
3. У чекбокса нет третьего состояния. (У менюшных есть, но менюшные просто на форму не кинешь).
4. Радиобатон можно сделать максимально неочевидным и максимально неудобным способом. Я аж ахуел с того, как это реализовано. Нужно задать группу (ButtonGroup), которая является спец-ресурсом, который нихуя не делает, нихуя не хранит в себе, просто существует.
5. Слайдер не имеет заполняемой формы, точнее, его в рамках темы можно отрисовать как заполняемый или как тонкий, следовательно, на слайдеры нужно два файла-темы заводить. Или оверрайд.
6. В темах виндовса очень много комбинированных элементов, которые строятся из растягивающейся 9-сегментной основы и отцентрованной иконки. Например, ползунки и кнопки скроллбара. В годоте это не предусмотрено. И стало быть реализовать вид 1в1 не получится (через механизм тем).
Тут я остановился и задумался, похоже лучше реализовать клон интерфейса шынды другим способом, тупо через спрайты. Либо терпеть неточную копию (да кто уже там помнит, как выглядела ХРиснятка!)
1. Чекбокс в годоте это кнопка с иконкой! А в шындовс это ярлык с иконкой. В связи с чем, в годоте не предусмотрено отдельных юи-элементов для подсветки иконки чекбокса при наведении мышкой.
2. В шынде смена вида иконок при активации забиндена и на нажатие мышки и на отжатие, в годоте этого нет. Половина интерфейса разом отметается.
3. У чекбокса нет третьего состояния. (У менюшных есть, но менюшные просто на форму не кинешь).
4. Радиобатон можно сделать максимально неочевидным и максимально неудобным способом. Я аж ахуел с того, как это реализовано. Нужно задать группу (ButtonGroup), которая является спец-ресурсом, который нихуя не делает, нихуя не хранит в себе, просто существует.
5. Слайдер не имеет заполняемой формы, точнее, его в рамках темы можно отрисовать как заполняемый или как тонкий, следовательно, на слайдеры нужно два файла-темы заводить. Или оверрайд.
6. В темах виндовса очень много комбинированных элементов, которые строятся из растягивающейся 9-сегментной основы и отцентрованной иконки. Например, ползунки и кнопки скроллбара. В годоте это не предусмотрено. И стало быть реализовать вид 1в1 не получится (через механизм тем).
Тут я остановился и задумался, похоже лучше реализовать клон интерфейса шынды другим способом, тупо через спрайты. Либо терпеть неточную копию (да кто уже там помнит, как выглядела ХРиснятка!)
А где можно энтот ваш Годот изучать на русском желательно>
? И без видеоуроков, ибо не переношу их.
Типо текст, примеры там.
И как отдельно освоить его скрипт? Поверхностно знаком с питоном.
Еще вопрос, насколько хорошо он экспортирует под андроид/иоос? Много ли подводных камней?
? И без видеоуроков, ибо не переношу их.
Типо текст, примеры там.
И как отдельно освоить его скрипт? Поверхностно знаком с питоном.
Еще вопрос, насколько хорошо он экспортирует под андроид/иоос? Много ли подводных камней?
>>06205
https://docs.godotengine.org/ru/stable/
https://docs.godotengine.org/ru/stable/tutorials/scripting/index.html
Правда, там перевод только частичный и не успевает за актуальными обновлениями документации. Переводи сам. Вообще, очень сложно заниматься чем-то в IT без знаний английского. Научись хотя бы на уровне индуса, будет намного легче.
Я подумываю заняться переводом документации, но что-то не хочется авторизоваться в гитхабе...
Главное знать фундаментальные принципы программирования. В остальном GDScript проще Python.
Я сам не пробовал, но говорят, что нормально. На смартфоне играл в игры на Годо (сканерсофт) и запускал редактор Годо (4.0, 3.5) - всё норм было. Минимальный размер apk, говорят, около 8 МБ, но сегодня, похоже, уже всем насрать на размеры апк.
>Годот изучать на русском
>без видеоуроков
https://docs.godotengine.org/ru/stable/
>как отдельно освоить его скрипт?
https://docs.godotengine.org/ru/stable/tutorials/scripting/index.html
Правда, там перевод только частичный и не успевает за актуальными обновлениями документации. Переводи сам. Вообще, очень сложно заниматься чем-то в IT без знаний английского. Научись хотя бы на уровне индуса, будет намного легче.
Я подумываю заняться переводом документации, но что-то не хочется авторизоваться в гитхабе...
>Поверхностно знаком с питоном.
Главное знать фундаментальные принципы программирования. В остальном GDScript проще Python.
>насколько хорошо он экспортирует под андроид
Я сам не пробовал, но говорят, что нормально. На смартфоне играл в игры на Годо (сканерсофт) и запускал редактор Годо (4.0, 3.5) - всё норм было. Минимальный размер apk, говорят, около 8 МБ, но сегодня, похоже, уже всем насрать на размеры апк.
>>06200
Сомневаюсь, что это возможно сделать один в один.
На всякий случай напоминаю, что ты не можешь использовать эти битмапы в коммерческом продукте, не можешь лицензировать под свободной лицензией и вообще распространять. Даже после конвертации. По сути ты занимаешься сейчас "пиратством". Легальным было бы сделать реплику вручную, в пейнте, т.к. вряд ли возможно лицензировать простейшие формы (квадраты и т.д.), но ты рипнул лицензированный код, а это низзя.
1. Сделай свой чекбокс. Или отдельную тему для чекбоксов. Вообще не понимаю твоей проблемы, пусть будут небольшие расхождения с оригиналом, разве кто-то заметит разницу?
2. Эээ... Не понял. Часто ли такое поведение встречается? Я такого, по-моему, вообще не видел. Но разве в Годо нет события "отжатие кнопки"? Можно вручную сделать смену иконки.
3. Сделай свой чекбокс, в чём проблема? Ты даже можешь добавлять кастомные свойства в свои темы.
4. Что не так? Группа радиокнопок существует и в Godot, и в WinAPI. Как ты представляешь себе использование радиокнопок, которые никак друг с другом не связаны?
5. Не понял проблемы, сделай свой слайдер.
6. Сделай сам через кастомные ноды (class_name).
Да тебе всего несколько элементов нужно доделать. В чём проблема взять за основу имеющийся UI и расширить его?
>сконвертировать тему шындовс ХР в тему годота
Сомневаюсь, что это возможно сделать один в один.
>Достал битмапы из длл-ки (shellstyle)
На всякий случай напоминаю, что ты не можешь использовать эти битмапы в коммерческом продукте, не можешь лицензировать под свободной лицензией и вообще распространять. Даже после конвертации. По сути ты занимаешься сейчас "пиратством". Легальным было бы сделать реплику вручную, в пейнте, т.к. вряд ли возможно лицензировать простейшие формы (квадраты и т.д.), но ты рипнул лицензированный код, а это низзя.
1. Сделай свой чекбокс. Или отдельную тему для чекбоксов. Вообще не понимаю твоей проблемы, пусть будут небольшие расхождения с оригиналом, разве кто-то заметит разницу?
2. Эээ... Не понял. Часто ли такое поведение встречается? Я такого, по-моему, вообще не видел. Но разве в Годо нет события "отжатие кнопки"? Можно вручную сделать смену иконки.
3. Сделай свой чекбокс, в чём проблема? Ты даже можешь добавлять кастомные свойства в свои темы.
4. Что не так? Группа радиокнопок существует и в Godot, и в WinAPI. Как ты представляешь себе использование радиокнопок, которые никак друг с другом не связаны?
5. Не понял проблемы, сделай свой слайдер.
6. Сделай сам через кастомные ноды (class_name).
>тупо через спрайты
Да тебе всего несколько элементов нужно доделать. В чём проблема взять за основу имеющийся UI и расширить его?
>>06221
Это не майкрософтовская тема. Я взял кастомную с файлопомоек. Она ЦЦ0.
Дак я и говорю. Хотелось сделать чарез тему автоматом, но видимо нет. Придётся вручную.
А ты набросай на форму радиокнопок. Ну чисто по приколу. А потом приходи, расскажешь, как оно.
> На всякий случай напоминаю, что ты не можешь использовать эти битмапы
Это не майкрософтовская тема. Я взял кастомную с файлопомоек. Она ЦЦ0.
> Не понял проблемы, сделай свой слайдер.
Дак я и говорю. Хотелось сделать чарез тему автоматом, но видимо нет. Придётся вручную.
> Что не так? Группа радиокнопок существует
А ты набросай на форму радиокнопок. Ну чисто по приколу. А потом приходи, расскажешь, как оно.
>>06292
Сделай свой компонент, который наследуется от NinePatchRect, но размещает дополнительную иконку в центре.
>>06294
Наивно предполагать абсолютную совместимость между древним дизайном Windows и модным велосипедом Godot. Нужно было предполагать необходимость в велосипедах.
Сделай свой компонент, который наследуется от NinePatchRect, но размещает дополнительную иконку в центре.
>>06294
>Хотелось сделать чарез тему автоматом
Наивно предполагать абсолютную совместимость между древним дизайном Windows и модным велосипедом Godot. Нужно было предполагать необходимость в велосипедах.
Поставил годот, созда проект.
Но в нем не появились папочки арт и фонт.
А в туториале написано что должны быть.
Или туториал устарел?
Но в нем не появились папочки арт и фонт.
А в туториале написано что должны быть.
Или туториал устарел?
>>06338
Изучай сейчас ветку 3.x.
Сильные изменения во внутреннем устройстве движка, API поменялось незначительно, насколько я знаю.
Основные изменения:
- Spatial -> Node3D (все потомки получили суффикс 3D)
- KinematicBody2D -> CharacterBody2D
- KinematicBody -> CharacterBody3D
- Popup теперь потомок класса Window
Тут ещё такое дело, что в 4.x портировали не всё из 3.x, т.е. какие-то возможности пока существуют только на старой ветке. Также API всё ещё в стадии активных изменений. Так что до релиза как минимум Godot 4.0 Beta1 использовать эту ветку на серьёзных проектах не рекомендуют, говорят - сидите на 3.x.
>Cтоит ли щас изучать Годот или ждать Годот 4?
Изучай сейчас ветку 3.x.
>Или изменения будут не слишком сильные?
Сильные изменения во внутреннем устройстве движка, API поменялось незначительно, насколько я знаю.
Основные изменения:
- Spatial -> Node3D (все потомки получили суффикс 3D)
- KinematicBody2D -> CharacterBody2D
- KinematicBody -> CharacterBody3D
- Popup теперь потомок класса Window
Тут ещё такое дело, что в 4.x портировали не всё из 3.x, т.е. какие-то возможности пока существуют только на старой ветке. Также API всё ещё в стадии активных изменений. Так что до релиза как минимум Godot 4.0 Beta1 использовать эту ветку на серьёзных проектах не рекомендуют, говорят - сидите на 3.x.
>>06376 (Del)
НУ так я учусь, копирую, а там они перемешаны.
Нельзя как-то автоматом блядь их фиксить?
Пиздец.
НУ так я учусь, копирую, а там они перемешаны.
Нельзя как-то автоматом блядь их фиксить?
Пиздец.
>>06347
В новом пустом проекте ничего и не должно быть.
>>06354
Основа движка - дерево сцены с нодами, т.е. те иконки с надписями в древовидной структуре, которые ты расставляешь в окошке, создавая новую сцену в Godot. При запуске игры движок последовательно создаёт и добавляет в это дерево (структуру в памяти компьютера) указанные тобой ноды. Сначала общий предок, потом его потомки, потомки потомков и т.д. Ты можешь добавлять ноды в дерево вручную, загружая их через код и затем соединяя с уже находящимися в дереве нодами, например, так:
На заметку, событие _enter_tree срабатывает каждый раз, когда ты добавляешь ноду в дерево, а _ready только в первый раз. Ноду можно извлекать из дерева и добавлять снова:
>>06364
В настройках редактора можно выбрать отображение табов и пробелов, а также настроить ширину табов и выбрать, какие именно символы используются для отступов.
>>06382
Копировать вредно, печатай сам, вручную, так лучше запомнишь, впечатается в мышечную память и потом будет легче.
Edit > Auto Indent, хоткей control+I.
>создал проект.
>Но в нем не появились папочки
В новом пустом проекте ничего и не должно быть.
>>06354
>когда узел входит в дерево сцены
Основа движка - дерево сцены с нодами, т.е. те иконки с надписями в древовидной структуре, которые ты расставляешь в окошке, создавая новую сцену в Godot. При запуске игры движок последовательно создаёт и добавляет в это дерево (структуру в памяти компьютера) указанные тобой ноды. Сначала общий предок, потом его потомки, потомки потомков и т.д. Ты можешь добавлять ноды в дерево вручную, загружая их через код и затем соединяя с уже находящимися в дереве нодами, например, так:
>var node = load("res://node.tscn") # событие _init
>add_child(node) # событие _enter_tree, затем _ready
На заметку, событие _enter_tree срабатывает каждый раз, когда ты добавляешь ноду в дерево, а _ready только в первый раз. Ноду можно извлекать из дерева и добавлять снова:
>var node = get_child(0) # получили ссылку на ноду
>remove_child(node) # событие _exit_tree
>add_child(node) # событие _enter_tree
>>06364
>mixed tabs and spaces in indentation
В настройках редактора можно выбрать отображение табов и пробелов, а также настроить ширину табов и выбрать, какие именно символы используются для отступов.
>>06382
>копирую
Копировать вредно, печатай сам, вручную, так лучше запомнишь, впечатается в мышечную память и потом будет легче.
>автоматом их фиксить
Edit > Auto Indent, хоткей control+I.
>>06391
Ошибся немного.
Или короче, если не нужно хранить упакованную сцену:
Т.е. в tscn хранятся "упакованные сцены", которые нужно "распаковать", создав новый инстанс (объект ООП).
Я об этом постоянно забываю...
Ошибся немного.
>var scene: PackedScene = load("res://node.tscn")
>var node: Node = scene.instance() # событие _init
>add_child(node) # событие _enter_tree, затем _ready
Или короче, если не нужно хранить упакованную сцену:
>var node: Node = load("res://node.tscn").instance()
Т.е. в tscn хранятся "упакованные сцены", которые нужно "распаковать", создав новый инстанс (объект ООП).
Я об этом постоянно забываю...
>>06384
А зачем тебе? Там всё элементарно же.
В самом простом случае у тебя два компонента: TextEdit, растянутый на всё окно, и LineEdit, прибитый к низу окна. В LineEdit игрок вводит сообщения, твой код в обработчике события нажатия кнопки Enter делает какую-то свою работу, затем выводит результат в TextEdit.
Если у тебя текстовая игра в виде меню с выбором ответов, тогда нужно Label с флагом Autowrap, а внизу VBoxContainer. Из когда добавляешь в VBoxContainer несколько Button, вешаешь на них обработчики нажатия и делаешь соответствующую работу, чаще всего это простое переключение страницы книги-игры.
Если ты совсем новичок, рекомендую сначала пройти обычные туториалы по играм, чтобы освоиться с GDScript и API движка, а уже потом будешь изобретать свои велосипеды.
>уроков, как в Годоте пилить текстовую игру
А зачем тебе? Там всё элементарно же.
В самом простом случае у тебя два компонента: TextEdit, растянутый на всё окно, и LineEdit, прибитый к низу окна. В LineEdit игрок вводит сообщения, твой код в обработчике события нажатия кнопки Enter делает какую-то свою работу, затем выводит результат в TextEdit.
Если у тебя текстовая игра в виде меню с выбором ответов, тогда нужно Label с флагом Autowrap, а внизу VBoxContainer. Из когда добавляешь в VBoxContainer несколько Button, вешаешь на них обработчики нажатия и делаешь соответствующую работу, чаще всего это простое переключение страницы книги-игры.
Если ты совсем новичок, рекомендую сначала пройти обычные туториалы по играм, чтобы освоиться с GDScript и API движка, а уже потом будешь изобретать свои велосипеды.
>>06396 (Del)
В Godot специальные кнопки с хоткеями для конвертации хоть пробелов в табы, хоть табов в пробелы. И есть волшебная кнопка, которая превращает смешанные пробелы с табами в те символы, которые выбраны в настройках.
Копипастить через блокнот - это какое-то новое извращение. Хотя я понял, почему ты предлагаешь блокнот, встроенное в Годо средство замены (ctrl+r) не позволяет ввести таб, лол. А всё потому, что не нужно - есть отдельная встроенная функция.
Если сайт все табы конвертирует в пробелы, это вообще не проблема. Проблема, когда ты не знаешь, какой из символов - таб, а какой - пробел. Но для этого в настройках можно включить отображение табов и/или пробелов. Либо выделить сомнительный код и нажать control+I, должно помочь или сломать код, если у тебя где-то не хватает пробела или стоит лишний - ищи потом, какой код должен быть внутри if/else или цикла, а какой - снаружи.
>Через блокнот. Копируешь с сайта в блокнот, там ctrl+f пробелы на табы.
В Godot специальные кнопки с хоткеями для конвертации хоть пробелов в табы, хоть табов в пробелы. И есть волшебная кнопка, которая превращает смешанные пробелы с табами в те символы, которые выбраны в настройках.
Копипастить через блокнот - это какое-то новое извращение. Хотя я понял, почему ты предлагаешь блокнот, встроенное в Годо средство замены (ctrl+r) не позволяет ввести таб, лол. А всё потому, что не нужно - есть отдельная встроенная функция.
>Проблема же в сайтах, которые неправильно хранят текст
Если сайт все табы конвертирует в пробелы, это вообще не проблема. Проблема, когда ты не знаешь, какой из символов - таб, а какой - пробел. Но для этого в настройках можно включить отображение табов и/или пробелов. Либо выделить сомнительный код и нажать control+I, должно помочь или сломать код, если у тебя где-то не хватает пробела или стоит лишний - ищи потом, какой код должен быть внутри if/else или цикла, а какой - снаружи.
62 Кб, 697x774>>06200
Да нормальный способ, ты чего. Сначала делаешь одну кнопку с ресурсом, а затем дублируешь эту кнопку сколько понадобится - получаешь группу связанных кнопок. Если нужна вторая группа, нажимаешь make unique и снова дублируешь кнопку. Конечно, потом можно забыть, какие кнопки связаны... Зато кнопки эти могут быть расположены где угодно и как угодно. Но если нужно сгруппировать - можно и сгруппировать. Так в чём проблема?
Посылает сигнал pressed с указателем нажатой кнопки.
Хранит список указателей связанных кнопок и указатель нажатой в данный момент кнопки. Что тебе ещё нужно?
>>06294
Набросал. Я должен был что-то почувствовать?
Мне нравится, 10 кастомизаций из 10 толерантностей, буду дублировать кнопки ещё. А ты просто радиокнопкофоб, боишься набрасывать их на форму, избегаешь, обзываешь их грязными словами, стесняешься дублировать их, стереотипы какие-то времён Windows XP пытаешься им навязать... Как тебе не стыдно? В 21 веке живём, должны принимать кнопки такими, какими они есть, даже если они "радио". Поди ещё кликаешь на них с презрением, курсор после каждого клика об панель задач вытираешь, как будто они заразные и ты боишься другие кнопки заразить этой их "радиацией". Давно пора отбросить устаревшие стереотипы о кнопках. Не обязательно их любить, но не стоит публично выражать своё негативное отношение к их способу настройки и функционирования. Подумай о Хуане, подумай о тех, кому они нравятся такими, какие они есть, подумай о тысячах проектов... Зачем менять эти маленькие несчастные кнопки, ломая жизни и совместимость с проектами? Они тоже хотят служить верой и правдой в интерфейсе твоей игры, так относись к ним с уважением.
Чёт шутка затянулась немного... :I
Зацените секси дирижаблик. Вот бы игру с ней, я б полетал...
>максимально неочевидным и максимально неудобным способом
Да нормальный способ, ты чего. Сначала делаешь одну кнопку с ресурсом, а затем дублируешь эту кнопку сколько понадобится - получаешь группу связанных кнопок. Если нужна вторая группа, нажимаешь make unique и снова дублируешь кнопку. Конечно, потом можно забыть, какие кнопки связаны... Зато кнопки эти могут быть расположены где угодно и как угодно. Но если нужно сгруппировать - можно и сгруппировать. Так в чём проблема?
>не делает
Посылает сигнал pressed с указателем нажатой кнопки.
>не хранит в себе
Хранит список указателей связанных кнопок и указатель нажатой в данный момент кнопки. Что тебе ещё нужно?
>>06294
>А ты набросай на форму радиокнопок. Ну чисто по приколу.
Набросал. Я должен был что-то почувствовать?
>А потом приходи, расскажешь, как оно.
Мне нравится, 10 кастомизаций из 10 толерантностей, буду дублировать кнопки ещё. А ты просто радиокнопкофоб, боишься набрасывать их на форму, избегаешь, обзываешь их грязными словами, стесняешься дублировать их, стереотипы какие-то времён Windows XP пытаешься им навязать... Как тебе не стыдно? В 21 веке живём, должны принимать кнопки такими, какими они есть, даже если они "радио". Поди ещё кликаешь на них с презрением, курсор после каждого клика об панель задач вытираешь, как будто они заразные и ты боишься другие кнопки заразить этой их "радиацией". Давно пора отбросить устаревшие стереотипы о кнопках. Не обязательно их любить, но не стоит публично выражать своё негативное отношение к их способу настройки и функционирования. Подумай о Хуане, подумай о тех, кому они нравятся такими, какие они есть, подумай о тысячах проектов... Зачем менять эти маленькие несчастные кнопки, ломая жизни и совместимость с проектами? Они тоже хотят служить верой и правдой в интерфейсе твоей игры, так относись к ним с уважением.
Чёт шутка затянулась немного... :I
Зацените секси дирижаблик. Вот бы игру с ней, я б полетал...
Привет, педики, а в годоте реально сделать такую игру-песочницу:
короче кукла известного человека, а над ней можно всячески изголяться - поджигать там, резать и т.п.
Вроде видел что-то подобное, но не знаю как жанр называется.
Кукла вуду может?
короче кукла известного человека, а над ней можно всячески изголяться - поджигать там, резать и т.п.
Вроде видел что-то подобное, но не знаю как жанр называется.
Кукла вуду может?
>>06478
В тюрьму захотел сесть?
Да, конечно, а теперь иди читать руководство.
https://docs.godotengine.org/en/stable/
С чего такой вопрос-то, лол, Godot - универсальный движок.
>кукла известного человека
В тюрьму захотел сесть?
>в годоте реально сделать такую игру-песочницу
Да, конечно, а теперь иди читать руководство.
https://docs.godotengine.org/en/stable/
С чего такой вопрос-то, лол, Godot - универсальный движок.
>>06307
Вот это больше всего угнетает, в древней ХР дизайн намного продуманнее в мелочах.
> древним дизайном Windows
> модным велосипедом Godot
Вот это больше всего угнетает, в древней ХР дизайн намного продуманнее в мелочах.
>>06374
Я надеюсь они откажутся от этого безумия:
> Также API всё ещё в стадии активных изменений.
Я надеюсь они откажутся от этого безумия:
> Popup теперь потомок класса Window
>>06429
Блять...
> Да нормальный способ, ты чего. Сначала делаешь одну кнопку с ресурсом, а затем дублируешь эту кнопку сколько понадобится - получаешь группу связанных кнопок.
Блять...
>>06526
А ты окна Windows прямо вызовами WinAPI создавал или с помощью RAD IDE типа Delphi/Lazarus? Я не пытался через WinAPI (только самый минимум для GDI/OpenGL), но мне кажется, что набор компонентов VCL/LCL всё же значительно упрощает работу с окнами Windows. Через вызовы WinAPI там всё как-то сложно казалось.
>>06527
Почему безумие-то? В твоей любимой Windows XP вообще все визуальные компоненты являются окнами (кнопки, надписи, поля ввода и т.д.). А с точки зрения пользователя, попапы Windows - это самые настоящие окна, отдельные от основного окна, со своими заголовком и крестиком, если не считать контекстные меню. Кстати, забавно, я на какой-то версии Windows попадал в ситуацию, когда белой плёнкой "зависания" покрывалось только выпадающее контекстное меню или вообще всплывающая подсказка - и ищи потом, какое приложение нужно убить через диспетчер, чтобы оно пропало, а иногда это лечилось только перезагрузкой ОС.
Проблема окон Godot только в том, что он их не прячет, а создаёт и уничтожает, каждый раз выделяя новый контекст Vulkan. Возможно, в следующих релизах это оптимизируют. Предлагаю заранее создавать несколько окон, лишние пряча с экрана - вряд ли это будет грузить систему, пока окно ничего не рендерит.
>>06530
Лол, ты что, каждой кнопке ресурс вручную назначал? Я вот гораздо чаще сталкивался с тем, что после дублирования какой-то нужной мне ноды все её ресурсы связаны с оригиналом, например, если дублировать CollisionShape, то при изменении его Shape этот шейп будет меняться и в оригинале, что не так-то просто сразу заметить (слишком тонкие рамки визуально теряются). Так что с моей точки зрения способ создания радиокнопок очень удобен - не приходится для каждой копии создавать отдельный ресурс, как в случае со множеством копий CollisionShape или MeshInstance.
А ты окна Windows прямо вызовами WinAPI создавал или с помощью RAD IDE типа Delphi/Lazarus? Я не пытался через WinAPI (только самый минимум для GDI/OpenGL), но мне кажется, что набор компонентов VCL/LCL всё же значительно упрощает работу с окнами Windows. Через вызовы WinAPI там всё как-то сложно казалось.
>>06527
>откажутся от этого безумия:
>>Popup теперь потомок класса Window
Почему безумие-то? В твоей любимой Windows XP вообще все визуальные компоненты являются окнами (кнопки, надписи, поля ввода и т.д.). А с точки зрения пользователя, попапы Windows - это самые настоящие окна, отдельные от основного окна, со своими заголовком и крестиком, если не считать контекстные меню. Кстати, забавно, я на какой-то версии Windows попадал в ситуацию, когда белой плёнкой "зависания" покрывалось только выпадающее контекстное меню или вообще всплывающая подсказка - и ищи потом, какое приложение нужно убить через диспетчер, чтобы оно пропало, а иногда это лечилось только перезагрузкой ОС.
Проблема окон Godot только в том, что он их не прячет, а создаёт и уничтожает, каждый раз выделяя новый контекст Vulkan. Возможно, в следующих релизах это оптимизируют. Предлагаю заранее создавать несколько окон, лишние пряча с экрана - вряд ли это будет грузить систему, пока окно ничего не рендерит.
>>06530
Лол, ты что, каждой кнопке ресурс вручную назначал? Я вот гораздо чаще сталкивался с тем, что после дублирования какой-то нужной мне ноды все её ресурсы связаны с оригиналом, например, если дублировать CollisionShape, то при изменении его Shape этот шейп будет меняться и в оригинале, что не так-то просто сразу заметить (слишком тонкие рамки визуально теряются). Так что с моей точки зрения способ создания радиокнопок очень удобен - не приходится для каждой копии создавать отдельный ресурс, как в случае со множеством копий CollisionShape или MeshInstance.
Пишу шейдер, шоб стандартный plane mesh менялся под форму моей карты высот. Но у меня на плейне был материал с текстуркой земли, который слетает от шейдера. Можно как-то закомбинировать шейдер и стандартный материал?
>>06909 (Del)
Вроде то, что нужно. Спасибо!
>Ты можешь создать стандартный материал и нажать кнопку сконвертировать в шейдер и дописать свой код.
Вроде то, что нужно. Спасибо!
>>06906
Интересно, а зачем? С одной стороны, тебе в любом случае понадобится сделать шейп из треугольников для физического движка, иначе все объекты будут двигаться по плоскости. С другой стороны, треугольники текстурить сегодня дешевле, чем гонять шейдеры, разве не так? Т.е. ничего не стоит насыпать миллион треугольников. И кроме того, если у тебя есть качественные текстуры, полигионы не будут бросаться в глаза, за исключением случаев, когда видишь ландшафт на фоне неба (горка там, холм). А для мелкой детализации подойдут карты нормалей и дисплейсмента.
>Пишу шейдер
>plane mesh менялся под форму моей карты высот
Интересно, а зачем? С одной стороны, тебе в любом случае понадобится сделать шейп из треугольников для физического движка, иначе все объекты будут двигаться по плоскости. С другой стороны, треугольники текстурить сегодня дешевле, чем гонять шейдеры, разве не так? Т.е. ничего не стоит насыпать миллион треугольников. И кроме того, если у тебя есть качественные текстуры, полигионы не будут бросаться в глаза, за исключением случаев, когда видишь ландшафт на фоне неба (горка там, холм). А для мелкой детализации подойдут карты нормалей и дисплейсмента.
>>06910 (Del)
Если не ошибаюсь, то нужно скомбинировать glow в environment и emission в шейдере. Ты почти догадался до правильного решения.
> Может я упускаю что то?
Если не ошибаюсь, то нужно скомбинировать glow в environment и emission в шейдере. Ты почти догадался до правильного решения.
>>06910 (Del)
Не правда, glow влияет на яркий цвет, а не на источники света. Достаточно поставить галку unshaded в материале с ярким цветом в albedo и он будет излучать ауру с галкой glow.
"Толщина" настраивается выбором галок в levels (см. пикрил), от этого зависит область размытия (от самого локального до самого глобального). Однако эта степень размытия зависит от размера окна, а не от расстояния между камерой и объектом. Т.е. аура будет одной толщины независимо от расстояния (поэтому (?) предлагается выбирать несколько уровней размытия). Если хочешь ауру, зависящую от расстояния, скорее всего придётся писать свой шейдер с использованием буфера глубины, если это возможно. Или делать что-то вроде полупрозрачной оболочки вокруг объекта... или что-то вроде объёмного дыма...
Я тут поэкспериментировал:
0-1) То, что предложили на ютубе в комментариях к видео по глоу эффекту: создать второй вьюпорт и рендерить в нём то, что должно иметь эффект. Способ работает, но полностью игнорирует буфер глубины, т.к. второй вьюпорт рендерится поверх первого. Наверное, это можно использовать для игр с фиксированной камерой?
2-3) С помощью параметра HDR Threshold можно настроить нижнюю границу яркости, которая будет размываться glow эффектом. Если правильно настроить Emission у материала и Energy у источников света, а также правильно настроить GI Probe и Reflection Probe (если они есть в сцене), то можно добиться того, что аура свечения будет только у выбранных тобой материалов. Работает благодаря тому, что HDR позволяет иметь в сцене источники света мощностью выше 100%, на экране этого не видно, но постобработка это учитывает.
>>06947
Ну вот он и спрашивает, что нужно сделать, лол.
Как именно комбинировать? Мне тоже это интересно.
>glow в worldenvironment
>Оно влияет на весь свет и одинаково
Не правда, glow влияет на яркий цвет, а не на источники света. Достаточно поставить галку unshaded в материале с ярким цветом в albedo и он будет излучать ауру с галкой glow.
>настроек толщины ауры не хватает
"Толщина" настраивается выбором галок в levels (см. пикрил), от этого зависит область размытия (от самого локального до самого глобального). Однако эта степень размытия зависит от размера окна, а не от расстояния между камерой и объектом. Т.е. аура будет одной толщины независимо от расстояния (поэтому (?) предлагается выбирать несколько уровней размытия). Если хочешь ауру, зависящую от расстояния, скорее всего придётся писать свой шейдер с использованием буфера глубины, если это возможно. Или делать что-то вроде полупрозрачной оболочки вокруг объекта... или что-то вроде объёмного дыма...
Я тут поэкспериментировал:
0-1) То, что предложили на ютубе в комментариях к видео по глоу эффекту: создать второй вьюпорт и рендерить в нём то, что должно иметь эффект. Способ работает, но полностью игнорирует буфер глубины, т.к. второй вьюпорт рендерится поверх первого. Наверное, это можно использовать для игр с фиксированной камерой?
2-3) С помощью параметра HDR Threshold можно настроить нижнюю границу яркости, которая будет размываться glow эффектом. Если правильно настроить Emission у материала и Energy у источников света, а также правильно настроить GI Probe и Reflection Probe (если они есть в сцене), то можно добиться того, что аура свечения будет только у выбранных тобой материалов. Работает благодаря тому, что HDR позволяет иметь в сцене источники света мощностью выше 100%, на экране этого не видно, но постобработка это учитывает.
>>06947
>нужно скомбинировать
Ну вот он и спрашивает, что нужно сделать, лол.
Как именно комбинировать? Мне тоже это интересно.
>>06934 (Del)
Нарисуй @ добавь в игру. Зачем грузить видеокарту игрока?
Даже в стратегии юниты должны физически забираться на гору и спускаться в овраг, а не ездить по одной плоскости, не? Можно, конечно, двигать их по информации с карты высот, но по сути получается одно и то же, тебе в любом случае придётся как-то интерполировать значения между точками карты высот. Проще скинуть ответственность на физический движок))
Если только динамические объекты не взаимодействуют с этой водой. В большинстве современных игр хотя бы что-то, да взаимодействует с водой. Как ты в шейдере будешь распознавать столкновения объектов с водной поверхностью? С помощью физического движка по идее можно регистрировать пересечения между водой и другими объектами, хотя непонятно, насколько часто можно обновлять физическую форму волн (я про реально большие волны, которые могут, например, затопить или перевернуть корабль, а не микрофигню ниже 5 см)...
Вот реально интересно, как делали физические волны в GTA начиная с GTA III? Там лодки сравнительно реалистично реагируют на волны, пусть даже сами волны - это просто синусоида. Можно ли сделать такие волны на Годо, да чтоб не лагало?
>не нужна физика, только визуал
Нарисуй @ добавь в игру. Зачем грузить видеокарту игрока?
>для террейна
Даже в стратегии юниты должны физически забираться на гору и спускаться в овраг, а не ездить по одной плоскости, не? Можно, конечно, двигать их по информации с карты высот, но по сути получается одно и то же, тебе в любом случае придётся как-то интерполировать значения между точками карты высот. Проще скинуть ответственность на физический движок))
>для волн на воде
Если только динамические объекты не взаимодействуют с этой водой. В большинстве современных игр хотя бы что-то, да взаимодействует с водой. Как ты в шейдере будешь распознавать столкновения объектов с водной поверхностью? С помощью физического движка по идее можно регистрировать пересечения между водой и другими объектами, хотя непонятно, насколько часто можно обновлять физическую форму волн (я про реально большие волны, которые могут, например, затопить или перевернуть корабль, а не микрофигню ниже 5 см)...
Вот реально интересно, как делали физические волны в GTA начиная с GTA III? Там лодки сравнительно реалистично реагируют на волны, пусть даже сами волны - это просто синусоида. Можно ли сделать такие волны на Годо, да чтоб не лагало?
>>06947
Я ж написал почему не подходит - там общая настройка всего глоу, а как на индивидуальный объект?
Я ж написал почему не подходит - там общая настройка всего глоу, а как на индивидуальный объект?
>>06996
Ну вот например если сделать два объекта которые светятся одним цветом но ауры у них разной толщины?
Ну вот например если сделать два объекта которые светятся одним цветом но ауры у них разной толщины?
>>07029
Честно говоря, не знаю, как ответить. Опиши подробнее, что именно ты хочешь сделать. Может быть, ты путаешь термины и тебе нужна не аура от светящегося объекта как у чувствительного фотоаппарата или сетчатки глаз, а что-то другое?
Потому что glow в environment - это как раз симуляция того эффекта, когда ты бросаешь взгляд из темноты на ярко освещённую сцену, или когда у камеры высокая выдержка/ISO. Т.е. это не физически существующий объект, а оптический артефакт, возникающий на фотоплёнке, светочувствительной матрице или сетчатке.
А если тебе нужна, скажем, "магическая аура", которая физически существует, или ты хочешь изобразить поток плазмы (очень сильно нагретый газ, излучающий свет), который, разумеется, занимает некий объём, то тебе нужен какой-то другой приём. Тебе по-прежнему понадобится использовать glow, т.к. это относится к восприятию, но тебе потребуется, наверное, иначе настраивать меши.
Попробуй сделать несколько вложенных оболочек, внешние из которых имеют прозрачность меньше внутренних. Внешним сделай выше emission более бледного цвета, близкого к жёлтому, а внутренним сделай ниже emission более красного цвета. Если ничего не путаю, это будет симулировать скопление плазмы а-ля оболочка жёлтого карлика (Солнце). Изменяя расстояние между оболочками и их прозрачность, ты сможешь измерять величину "ауры" на физическом уровне, т.е. это будет не эффект восприятия, а реальное количество растекающейся в разные стороны плазмы.
В частности, если ты хочешь сделать световые мечи из звёздных войн, то я не знаю что там по лору, но внешне эти мечи напоминают потоки плазмы, хотя в реальном мире таким способом плазму сформировать было бы крайне сложно (нужно мощное магнитное поле, удерживающее плазму, а "кончик меча" не удастся сделать полностью плоским - плазма будет вытекать оттуда, как из сопла ракетного двигателя).
Могу попробовать замоделить такой эффект, если тебе нужны именно потоки плазмы в форме цилиндров, но тебе виднее, чего ты там хочешь добиться. В любом случае это будет затратно по производительности игры.
Честно говоря, не знаю, как ответить. Опиши подробнее, что именно ты хочешь сделать. Может быть, ты путаешь термины и тебе нужна не аура от светящегося объекта как у чувствительного фотоаппарата или сетчатки глаз, а что-то другое?
Потому что glow в environment - это как раз симуляция того эффекта, когда ты бросаешь взгляд из темноты на ярко освещённую сцену, или когда у камеры высокая выдержка/ISO. Т.е. это не физически существующий объект, а оптический артефакт, возникающий на фотоплёнке, светочувствительной матрице или сетчатке.
А если тебе нужна, скажем, "магическая аура", которая физически существует, или ты хочешь изобразить поток плазмы (очень сильно нагретый газ, излучающий свет), который, разумеется, занимает некий объём, то тебе нужен какой-то другой приём. Тебе по-прежнему понадобится использовать glow, т.к. это относится к восприятию, но тебе потребуется, наверное, иначе настраивать меши.
Попробуй сделать несколько вложенных оболочек, внешние из которых имеют прозрачность меньше внутренних. Внешним сделай выше emission более бледного цвета, близкого к жёлтому, а внутренним сделай ниже emission более красного цвета. Если ничего не путаю, это будет симулировать скопление плазмы а-ля оболочка жёлтого карлика (Солнце). Изменяя расстояние между оболочками и их прозрачность, ты сможешь измерять величину "ауры" на физическом уровне, т.е. это будет не эффект восприятия, а реальное количество растекающейся в разные стороны плазмы.
В частности, если ты хочешь сделать световые мечи из звёздных войн, то я не знаю что там по лору, но внешне эти мечи напоминают потоки плазмы, хотя в реальном мире таким способом плазму сформировать было бы крайне сложно (нужно мощное магнитное поле, удерживающее плазму, а "кончик меча" не удастся сделать полностью плоским - плазма будет вытекать оттуда, как из сопла ракетного двигателя).
Могу попробовать замоделить такой эффект, если тебе нужны именно потоки плазмы в форме цилиндров, но тебе виднее, чего ты там хочешь добиться. В любом случае это будет затратно по производительности игры.
>>07029
Честно говоря, не знаю, как ответить. Опиши подробнее, что именно ты хочешь сделать. Может быть, ты путаешь термины и тебе нужна не аура от светящегося объекта как у чувствительного фотоаппарата или сетчатки глаз, а что-то другое?
Потому что glow в environment - это как раз симуляция того эффекта, когда ты бросаешь взгляд из темноты на ярко освещённую сцену, или когда у камеры высокая выдержка/ISO. Т.е. это не физически существующий объект, а оптический артефакт, возникающий на фотоплёнке, светочувствительной матрице или сетчатке.
А если тебе нужна, скажем, "магическая аура", которая физически существует, или ты хочешь изобразить поток плазмы (очень сильно нагретый газ, излучающий свет), который, разумеется, занимает некий объём, то тебе нужен какой-то другой приём. Тебе по-прежнему понадобится использовать glow, т.к. это относится к восприятию, но тебе потребуется, наверное, иначе настраивать меши.
Попробуй сделать несколько вложенных оболочек, внешние из которых имеют прозрачность меньше внутренних. Внешним сделай выше emission более бледного цвета, близкого к жёлтому, а внутренним сделай ниже emission более красного цвета. Если ничего не путаю, это будет симулировать скопление плазмы а-ля оболочка жёлтого карлика (Солнце). Изменяя расстояние между оболочками и их прозрачность, ты сможешь измерять величину "ауры" на физическом уровне, т.е. это будет не эффект восприятия, а реальное количество растекающейся в разные стороны плазмы.
В частности, если ты хочешь сделать световые мечи из звёздных войн, то я не знаю что там по лору, но внешне эти мечи напоминают потоки плазмы, хотя в реальном мире таким способом плазму сформировать было бы крайне сложно (нужно мощное магнитное поле, удерживающее плазму, а "кончик меча" не удастся сделать полностью плоским - плазма будет вытекать оттуда, как из сопла ракетного двигателя).
Могу попробовать замоделить такой эффект, если тебе нужны именно потоки плазмы в форме цилиндров, но тебе виднее, чего ты там хочешь добиться. В любом случае это будет затратно по производительности игры.
Честно говоря, не знаю, как ответить. Опиши подробнее, что именно ты хочешь сделать. Может быть, ты путаешь термины и тебе нужна не аура от светящегося объекта как у чувствительного фотоаппарата или сетчатки глаз, а что-то другое?
Потому что glow в environment - это как раз симуляция того эффекта, когда ты бросаешь взгляд из темноты на ярко освещённую сцену, или когда у камеры высокая выдержка/ISO. Т.е. это не физически существующий объект, а оптический артефакт, возникающий на фотоплёнке, светочувствительной матрице или сетчатке.
А если тебе нужна, скажем, "магическая аура", которая физически существует, или ты хочешь изобразить поток плазмы (очень сильно нагретый газ, излучающий свет), который, разумеется, занимает некий объём, то тебе нужен какой-то другой приём. Тебе по-прежнему понадобится использовать glow, т.к. это относится к восприятию, но тебе потребуется, наверное, иначе настраивать меши.
Попробуй сделать несколько вложенных оболочек, внешние из которых имеют прозрачность меньше внутренних. Внешним сделай выше emission более бледного цвета, близкого к жёлтому, а внутренним сделай ниже emission более красного цвета. Если ничего не путаю, это будет симулировать скопление плазмы а-ля оболочка жёлтого карлика (Солнце). Изменяя расстояние между оболочками и их прозрачность, ты сможешь измерять величину "ауры" на физическом уровне, т.е. это будет не эффект восприятия, а реальное количество растекающейся в разные стороны плазмы.
В частности, если ты хочешь сделать световые мечи из звёздных войн, то я не знаю что там по лору, но внешне эти мечи напоминают потоки плазмы, хотя в реальном мире таким способом плазму сформировать было бы крайне сложно (нужно мощное магнитное поле, удерживающее плазму, а "кончик меча" не удастся сделать полностью плоским - плазма будет вытекать оттуда, как из сопла ракетного двигателя).
Могу попробовать замоделить такой эффект, если тебе нужны именно потоки плазмы в форме цилиндров, но тебе виднее, чего ты там хочешь добиться. В любом случае это будет затратно по производительности игры.
>>07046
Изменять.
Тут я немного ошибся. Оболочка там сложная, потоки плазмы образуют завихрения и одновременно остывают: сначала они жёлтые, а потом красные. Простым цилиндром такой эффект, разумеется, не создать, но и световые мечи не такие сложные, там просто прямой поток плазмы от ручки до кончика.
Я тут подумал, возможно, можно сделать эффект на одном цилиндре с помощью шейдера, который изменяет цвет и силу emission и величину прозрачности в зависимости от угла наклона поверхности к камере или, если это возможно посчитать, в зависимости от толщины меша в конкретной точке. Тогда тебе нужен меш примерно того размера, какого размера ты хочешь "ауру", потому что эффект ауры будет внутри цилиндра, а не снаружи него.
Но я шейдеры программировать не умею, помочь не могу.
>измерять величину "ауры"
Изменять.
>оболочка жёлтого карлика (Солнце)
Тут я немного ошибся. Оболочка там сложная, потоки плазмы образуют завихрения и одновременно остывают: сначала они жёлтые, а потом красные. Простым цилиндром такой эффект, разумеется, не создать, но и световые мечи не такие сложные, там просто прямой поток плазмы от ручки до кончика.
>несколько вложенных оболочек
Я тут подумал, возможно, можно сделать эффект на одном цилиндре с помощью шейдера, который изменяет цвет и силу emission и величину прозрачности в зависимости от угла наклона поверхности к камере или, если это возможно посчитать, в зависимости от толщины меша в конкретной точке. Тогда тебе нужен меш примерно того размера, какого размера ты хочешь "ауру", потому что эффект ауры будет внутри цилиндра, а не снаружи него.
Но я шейдеры программировать не умею, помочь не могу.
Функции которые начинаются с подчеркивания - это какие-то встроенные условные функции, вызываемые при определенных условиях?
>>07072 (Del)
так что это за функции, которые с подчеркивания начинаются?
так что это за функции, которые с подчеркивания начинаются?
А есть примеры живых трехмерных фонов?
Для визуальной новеллы, но при этом фон - трехмерный, где ходят сзади персонажи, двигаются элементы, короче как типо в Эльдер Скроллс, когда ты говоришь с персонажем.
Для визуальной новеллы, но при этом фон - трехмерный, где ходят сзади персонажи, двигаются элементы, короче как типо в Эльдер Скроллс, когда ты говоришь с персонажем.
>>07058
Официально в документации Годо рекомендуют начинать с подчёркивания приватные методы класса. Т.е. если ты не будешь вызывать метод извне класса (напрямую, не через сигналы), то нужно начинать его с подчёркивания. Если будешь вызывать напрямую, то подчёркивание не нужно. Однако интерпретатор никак это условие не проверяет, т.е. фактически все методы публичные и могут быть вызваны откуда угодно. В будущем это могут изменить.
>>07099
В чём твоя проблема?
>>07103
Зависит от контекста.
Возможно, имеются в виду поля класса.
Свойство - это когда есть геттер и сеттер, которые вызываются при попытке доступа к полю класса (при этом не обязательно чтобы существовала какая-то переменная, но в GDScript, к сожалению, можно только к конкретной переменной привязать).
https://ru.wikipedia.org/wiki/Поле_класса
https://ru.wikipedia.org/wiki/Свойство_(программирование)
>Функции которые начинаются с подчеркивания
Официально в документации Годо рекомендуют начинать с подчёркивания приватные методы класса. Т.е. если ты не будешь вызывать метод извне класса (напрямую, не через сигналы), то нужно начинать его с подчёркивания. Если будешь вызывать напрямую, то подчёркивание не нужно. Однако интерпретатор никак это условие не проверяет, т.е. фактически все методы публичные и могут быть вызваны откуда угодно. В будущем это могут изменить.
>>07099
В чём твоя проблема?
>>07103
>member variable как лучше перевести?
>Свойство класса?
Зависит от контекста.
Возможно, имеются в виду поля класса.
Свойство - это когда есть геттер и сеттер, которые вызываются при попытке доступа к полю класса (при этом не обязательно чтобы существовала какая-то переменная, но в GDScript, к сожалению, можно только к конкретной переменной привязать).
https://ru.wikipedia.org/wiki/Поле_класса
https://ru.wikipedia.org/wiki/Свойство_(программирование)
>>07114 (Del)
Шутник, очевидно, ему нужен пример на Godot.
>>07099
В общем, непонятно, что тебе нужно, но посмотри это:
https://github.com/godotengine/godot-demo-projects/tree/master/viewport/3d_in_2d
https://github.com/godotengine/godot-demo-projects/tree/master/viewport/2d_in_3d
Вообще, если у тебя 3D игра (как TES), а тебе нужно только меню выбора ответов в диалоге, то достаточно использовать ноды интерфейса (Control). Даже если у тебя персонажи на экране будут 2D, ты можешь нарисовать их с помощью ноды TextureRect.
Т.е. специфическая отрисовка через вьюпорты нужна только динамическим играм вроде платформеров, где нужен сложный 2D рендерер и, соответственно, интерфейсные ноды не подходят.
Шутник, очевидно, ему нужен пример на Godot.
>>07099
В общем, непонятно, что тебе нужно, но посмотри это:
https://github.com/godotengine/godot-demo-projects/tree/master/viewport/3d_in_2d
https://github.com/godotengine/godot-demo-projects/tree/master/viewport/2d_in_3d
Вообще, если у тебя 3D игра (как TES), а тебе нужно только меню выбора ответов в диалоге, то достаточно использовать ноды интерфейса (Control). Даже если у тебя персонажи на экране будут 2D, ты можешь нарисовать их с помощью ноды TextureRect.
Т.е. специфическая отрисовка через вьюпорты нужна только динамическим играм вроде платформеров, где нужен сложный 2D рендерер и, соответственно, интерфейсные ноды не подходят.
118 Кб, webm,600x600, 0:02
>>07055 (Del)
Где видел? Покажи.
Я попробовал сделать - не получается растянуть эффект на всю длину цилиндра, т.к. дальняя сторона под большим углом к камере и становится невидимой как боковые края.
>видел шейдер сферического солнца
Где видел? Покажи.
Я попробовал сделать - не получается растянуть эффект на всю длину цилиндра, т.к. дальняя сторона под большим углом к камере и становится невидимой как боковые края.
Почему-то маловато игра на годоте и фоловеров, не?
https://steamdb.info/tech/Engine/Godot/
С чем это связано?
https://steamdb.info/tech/Engine/Godot/
С чем это связано?
ПОСОНЫ НЕ КОЧАЙТИ ТАМ ВИРУС
БОРАТ УМИР ПЕШУ С ТИЛИФОНА
https://www.udemy.com/course/gg-godot/
Не знаю, чё этот мужик там аж 16 (!) часов говорит, но то, чему он там учит, судя по всему - полное говно. Скачал несколько проектов с гитхаба (ищите "godot getaway"), которые по этому курсу делались, большинство недоделанны, но даже то, что более-менее доделано, демонстрирует очень плохую архитектуру проекта и костыли. Короче, если вы не ньюфаг, вам это всё точно не нужно, а если ньюфаг - лучше найти что-то получше или научиться на собственных ошибках, чтобы не выучивать это говно как "правильный" подход.
БОРАТ УМИР ПЕШУ С ТИЛИФОНА
https://www.udemy.com/course/gg-godot/
Не знаю, чё этот мужик там аж 16 (!) часов говорит, но то, чему он там учит, судя по всему - полное говно. Скачал несколько проектов с гитхаба (ищите "godot getaway"), которые по этому курсу делались, большинство недоделанны, но даже то, что более-менее доделано, демонстрирует очень плохую архитектуру проекта и костыли. Короче, если вы не ньюфаг, вам это всё точно не нужно, а если ньюфаг - лучше найти что-то получше или научиться на собственных ошибках, чтобы не выучивать это говно как "правильный" подход.
>>07190 (Del)
Так речь не про геймплей, хотя он хреново отлажен даже в официальной бесплатной демке (исходников нет):
https://issmir.itch.io/godot-getaway-the-kickstarter-prototype
Речь про организацию папок, кода, данных. Способ реализации тех или иных систем. Всё это слеплено на скорую руку и не подходит для длительной разработки серьёзного проекта. Судя по отзывам к курсу, мужик этот просто на видео показывает, как пишет код, делает сцены и т.д., даже без пауз, обобщений и подробных объяснений. Т.е. если нуб и может повторить такой проект, то только делая один в один. Кстати, официальную демку я попробовал распаковать (pck), так вот как минимум папки и файлы там расположены так же хреново, как в проектах на гитхабе, значит, и внутри такое же месиво. И за такой курс требуют денег... Да такое даже бесплатно с гитхаба разбирать не хочется, там же всё переделывать практически с нуля, чтобы годнота получилась, проще реально с нуля делать по уму.
>машинка ездит, сбивает гидранты, прыгает по трамплинам, обрушивает строительные леса
Так речь не про геймплей, хотя он хреново отлажен даже в официальной бесплатной демке (исходников нет):
https://issmir.itch.io/godot-getaway-the-kickstarter-prototype
Речь про организацию папок, кода, данных. Способ реализации тех или иных систем. Всё это слеплено на скорую руку и не подходит для длительной разработки серьёзного проекта. Судя по отзывам к курсу, мужик этот просто на видео показывает, как пишет код, делает сцены и т.д., даже без пауз, обобщений и подробных объяснений. Т.е. если нуб и может повторить такой проект, то только делая один в один. Кстати, официальную демку я попробовал распаковать (pck), так вот как минимум папки и файлы там расположены так же хреново, как в проектах на гитхабе, значит, и внутри такое же месиво. И за такой курс требуют денег... Да такое даже бесплатно с гитхаба разбирать не хочется, там же всё переделывать практически с нуля, чтобы годнота получилась, проще реально с нуля делать по уму.
1 Мб, 1280x720Есть идеи как запилить след от текста а-ля пикрил? Сейчас использую несколько лейблов друг за другом, но этож костыльный вариант (я надеюсь). Курил немного шейдеры, но чёт ничего не придумал.
>>07239
Ну это точно шейдер надо пилить, но как именно - надо подумать.
Ну это точно шейдер надо пилить, но как именно - надо подумать.
>>07239
Вручную создаёшь? Можно было бы сделать с помощью системы частиц, один раз создавая текстуру с помощью Viewport (нужно поставить режим UPDATE_ONCE), а затем размножая их по заданным траекториям и с заданным изменением цвета с помощью системы частиц. Не знаю, насколько сильно это повлияет на производительность, но должно быть эффективнее создания множества надписей и перемещения их через GDScript.
Попробуй этот, но он для спрайтов:
https://godotshaders.com/shader/pixel-art-trail/
Можно один раз отрендерить текст вьюпортом в текстуру и потом на эту текстуру наложить этот шейдер.
>несколько лейблов друг за другом
Вручную создаёшь? Можно было бы сделать с помощью системы частиц, один раз создавая текстуру с помощью Viewport (нужно поставить режим UPDATE_ONCE), а затем размножая их по заданным траекториям и с заданным изменением цвета с помощью системы частиц. Не знаю, насколько сильно это повлияет на производительность, но должно быть эффективнее создания множества надписей и перемещения их через GDScript.
>шейдеры
Попробуй этот, но он для спрайтов:
https://godotshaders.com/shader/pixel-art-trail/
Можно один раз отрендерить текст вьюпортом в текстуру и потом на эту текстуру наложить этот шейдер.
>>07347
Тоже об этом подумал, буду раскуривать тему.
>Можно один раз отрендерить текст вьюпортом в текстуру и потом на эту текстуру наложить этот шейдер.
Тоже об этом подумал, буду раскуривать тему.
>>07388
Так тебе просто тень цветная нужна была? Я думал, натуральный шлейф, повторяющий движения надписи или анимированный. Как, например, в некоторых играх, где числа урона прыгают в разные стороны, там шлейф прикольно смотрится. Или что-то вроде капель (кровь, вода, лава, кислота и т.п.), анимированно стекающих с произвольной надписи вниз.
Так тебе просто тень цветная нужна была? Я думал, натуральный шлейф, повторяющий движения надписи или анимированный. Как, например, в некоторых играх, где числа урона прыгают в разные стороны, там шлейф прикольно смотрится. Или что-то вроде капель (кровь, вода, лава, кислота и т.п.), анимированно стекающих с произвольной надписи вниз.
>>07393
Не, ну я анимирую офк, ток позже. Отметился просто, что способ даёт нужный результат.
Не, ну я анимирую офк, ток позже. Отметился просто, что способ даёт нужный результат.
Уже месяц тыкаю годот, прям влюбился в него. Но хочу поговорить про подводные камни от которых жопа горит
Например, компиляция шейдеров при прогрузке материалов.
Суть в том что когда вы такой довольный сделали сцену с пулькой или фаерболом и удасужились туда добавить эмиттер частиц то в один момент обнаружите что сразу после нового запуска игры самая первая выпущенная пулька вызовет мелкое подлагивание, а причина тому - компиляция шейдеров, просто ебанутейшая проблема без адекватного решения. Асинхрон нихера не решает эту проблему, а кеширование даже не понимаю работает ли.
Ещё больше отсутствия нормального решения поражает то какие костыли выдумывают люди, делают текстурку на которую в начале игры все материалы накидывают и т.д., у меня такой метод через раз работал, некоторые ещё предлагают ему в modulate прозрачность 0 делать, но тогда тем более не все шейдеры компилирует почему-то
Продолжая попаболь с шейдерами:
Кто их хоть раз писал знает что есть такой параметр как UV, если хотите например покрасить половину текстурки в чёрный то можна будет с помощью этого параметра сделать проверку if(UV.x > 0.5) COLOR.rgb = vec3(0,0,0), так вот второй удар под дых я словил когда осознал что для таких штук как AtlasTexture и Tileset которые обрезают кусок текстурки (например пнгшки) этот самый UV нихуя не будет перенастраиваться и вы не сможете в шейдере таким образом покрасить половину тайла, оно ебанёт шейдер именно на половину всей пнгшки
Вот это пожалуй единственные критичные проблемы которые мне встали на пути создания лучшей игры всех времён. Все остальные недочёты вроде ущербного редактора тайлов уже решают и в 4.0 завезут то что можно будет назвать одним из лучших редакторов тайлсетов ever, жаль только вулкан не поддерживается видеокартой :(
Например, компиляция шейдеров при прогрузке материалов.
Суть в том что когда вы такой довольный сделали сцену с пулькой или фаерболом и удасужились туда добавить эмиттер частиц то в один момент обнаружите что сразу после нового запуска игры самая первая выпущенная пулька вызовет мелкое подлагивание, а причина тому - компиляция шейдеров, просто ебанутейшая проблема без адекватного решения. Асинхрон нихера не решает эту проблему, а кеширование даже не понимаю работает ли.
Ещё больше отсутствия нормального решения поражает то какие костыли выдумывают люди, делают текстурку на которую в начале игры все материалы накидывают и т.д., у меня такой метод через раз работал, некоторые ещё предлагают ему в modulate прозрачность 0 делать, но тогда тем более не все шейдеры компилирует почему-то
Продолжая попаболь с шейдерами:
Кто их хоть раз писал знает что есть такой параметр как UV, если хотите например покрасить половину текстурки в чёрный то можна будет с помощью этого параметра сделать проверку if(UV.x > 0.5) COLOR.rgb = vec3(0,0,0), так вот второй удар под дых я словил когда осознал что для таких штук как AtlasTexture и Tileset которые обрезают кусок текстурки (например пнгшки) этот самый UV нихуя не будет перенастраиваться и вы не сможете в шейдере таким образом покрасить половину тайла, оно ебанёт шейдер именно на половину всей пнгшки
Вот это пожалуй единственные критичные проблемы которые мне встали на пути создания лучшей игры всех времён. Все остальные недочёты вроде ущербного редактора тайлов уже решают и в 4.0 завезут то что можно будет назвать одним из лучших редакторов тайлсетов ever, жаль только вулкан не поддерживается видеокартой :(
>>07469
Вроде ж прекомпиляцию выкатили. Ктото ИТТ выше писал. Я лично не проверял.
> компиляция шейдеров, просто ебанутейшая проблема без адекватного решения
Вроде ж прекомпиляцию выкатили. Ктото ИТТ выше писал. Я лично не проверял.
>>07470
так-то оно так, даже в библиотеке ассетов есть один ShaderPrecompiler, он, вроде, в шапке треда тоже. Но он компилит только те шейдеры что находятся в материалах которые уже в текущей сцене используются. Я себе и сам переписал эту штуку чтоб она из отдельной папки с материалами брала всё, и оно даже работает на пол шишечки, но опять же, это через раз работает.
Интересно как там на низком уровне это всё устроено неужели нельзя просто сделать хотя бы функцию аля my_material.compile(), видимо на это веские причины есть. Вот бы ещё люди с опытом в юнити\анриале рассказали как там работа с шейдерами выглядит
так-то оно так, даже в библиотеке ассетов есть один ShaderPrecompiler, он, вроде, в шапке треда тоже. Но он компилит только те шейдеры что находятся в материалах которые уже в текущей сцене используются. Я себе и сам переписал эту штуку чтоб она из отдельной папки с материалами брала всё, и оно даже работает на пол шишечки, но опять же, это через раз работает.
Интересно как там на низком уровне это всё устроено неужели нельзя просто сделать хотя бы функцию аля my_material.compile(), видимо на это веские причины есть. Вот бы ещё люди с опытом в юнити\анриале рассказали как там работа с шейдерами выглядит
>>07469
Уже давно пофиксили асинхронной компиляцией (убершейдер подменяет специальный, пока специальный компилируется фоновым процессом) и кэшем на диске (после первой компиляции шейдер будет грузиться с диска, пока не почистишь %appdata%/Godot). Доступно это удовольствие в 3.5, я тестил - действительно работает, больше ни единого пропука после первой компиляции.
Этот "костыль" использовали во многих старых OpenGL играх.
Для этого нужно в шейдере объявить униформы и обновлять их через код. AtlasTexture - это упрощённая версия, чтобы не возиться с шейдерами, для чего-то большего нужно писать своё. На счёт тайлсета не знаю. Ты пытаешься шейдер на один тайл из тайлмапы накладывать? С какой целью? По-моему, для такой задачи (рамка, выделение, спецэффект какой) лучше спрайт создать поверх тайла. Тайлмапы вообще оптимизируют как статичную структуру, часто менять их содержимое должно быть накладно, но я не измерял.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/canvas_item_shader.html#fragment-built-ins
Проще говоря - если ты пишешь фрагмент шейдер для нод канваса, будь готов самостоятельно разбираться с UV, потому что, скорее всего, все остальные ноды (тот же AtlasTexture) сделаны на шейдерах и ты перезаписываешь их поведение своим кодом. Не понимаю пока, почему нельзя поставить кастомный шейдер вслед за встроенным, но, возможно, есть на то причины (или ты не пробовал?).
Можешь делать карты в Tiled, а импортировать скриптом. Тайлсеты тоже можно создавать из кода, достаточно написать скрипт и тогда сможешь автоматически обновлять всё без редактора Годо (ну типа закинул новые файлы с тайлами в папочку, нажал кнопку и получил готовый тайлсет без головной боли).
Что-то древнее или ноутбук? В любом случае обещают поддерживать GLES3 как второй рендерер (для мобилок и веба). Несколько лет назад говорили про GLES2, но с тех пор много времени прошло и сказали, что выгоднее GLES3 поддерживать.
>компиляция шейдеров при прогрузке материалов
Уже давно пофиксили асинхронной компиляцией (убершейдер подменяет специальный, пока специальный компилируется фоновым процессом) и кэшем на диске (после первой компиляции шейдер будет грузиться с диска, пока не почистишь %appdata%/Godot). Доступно это удовольствие в 3.5, я тестил - действительно работает, больше ни единого пропука после первой компиляции.
>делают текстурку на которую в начале игры все материалы накидывают
Этот "костыль" использовали во многих старых OpenGL играх.
>для таких штук как AtlasTexture и Tileset
>UV не будет перенастраиваться
Для этого нужно в шейдере объявить униформы и обновлять их через код. AtlasTexture - это упрощённая версия, чтобы не возиться с шейдерами, для чего-то большего нужно писать своё. На счёт тайлсета не знаю. Ты пытаешься шейдер на один тайл из тайлмапы накладывать? С какой целью? По-моему, для такой задачи (рамка, выделение, спецэффект какой) лучше спрайт создать поверх тайла. Тайлмапы вообще оптимизируют как статичную структуру, часто менять их содержимое должно быть накладно, но я не измерял.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/canvas_item_shader.html#fragment-built-ins
>Certain Nodes (for example, Sprites) display a texture by default. However, when a custom fragment function is attached to these nodes, the texture lookup needs to be done manually. Godot does not provide the texture color in the COLOR built-in variable; to read the texture color for such nodes, use:
>COLOR = texture(TEXTURE, UV);
Проще говоря - если ты пишешь фрагмент шейдер для нод канваса, будь готов самостоятельно разбираться с UV, потому что, скорее всего, все остальные ноды (тот же AtlasTexture) сделаны на шейдерах и ты перезаписываешь их поведение своим кодом. Не понимаю пока, почему нельзя поставить кастомный шейдер вслед за встроенным, но, возможно, есть на то причины (или ты не пробовал?).
>ущербного редактора тайлов
Можешь делать карты в Tiled, а импортировать скриптом. Тайлсеты тоже можно создавать из кода, достаточно написать скрипт и тогда сможешь автоматически обновлять всё без редактора Годо (ну типа закинул новые файлы с тайлами в папочку, нажал кнопку и получил готовый тайлсет без головной боли).
>вулкан не поддерживается видеокартой
Что-то древнее или ноутбук? В любом случае обещают поддерживать GLES3 как второй рендерер (для мобилок и веба). Несколько лет назад говорили про GLES2, но с тех пор много времени прошло и сказали, что выгоднее GLES3 поддерживать.
>>07469
Уже давно пофиксили асинхронной компиляцией (убершейдер подменяет специальный, пока специальный компилируется фоновым процессом) и кэшем на диске (после первой компиляции шейдер будет грузиться с диска, пока не почистишь %appdata%/Godot). Доступно это удовольствие в 3.5, я тестил - действительно работает, больше ни единого пропука после первой компиляции.
Этот "костыль" использовали во многих старых OpenGL играх.
Для этого нужно в шейдере объявить униформы и обновлять их через код. AtlasTexture - это упрощённая версия, чтобы не возиться с шейдерами, для чего-то большего нужно писать своё. На счёт тайлсета не знаю. Ты пытаешься шейдер на один тайл из тайлмапы накладывать? С какой целью? По-моему, для такой задачи (рамка, выделение, спецэффект какой) лучше спрайт создать поверх тайла. Тайлмапы вообще оптимизируют как статичную структуру, часто менять их содержимое должно быть накладно, но я не измерял.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/canvas_item_shader.html#fragment-built-ins
Проще говоря - если ты пишешь фрагмент шейдер для нод канваса, будь готов самостоятельно разбираться с UV, потому что, скорее всего, все остальные ноды (тот же AtlasTexture) сделаны на шейдерах и ты перезаписываешь их поведение своим кодом. Не понимаю пока, почему нельзя поставить кастомный шейдер вслед за встроенным, но, возможно, есть на то причины (или ты не пробовал?).
Можешь делать карты в Tiled, а импортировать скриптом. Тайлсеты тоже можно создавать из кода, достаточно написать скрипт и тогда сможешь автоматически обновлять всё без редактора Годо (ну типа закинул новые файлы с тайлами в папочку, нажал кнопку и получил готовый тайлсет без головной боли).
Что-то древнее или ноутбук? В любом случае обещают поддерживать GLES3 как второй рендерер (для мобилок и веба). Несколько лет назад говорили про GLES2, но с тех пор много времени прошло и сказали, что выгоднее GLES3 поддерживать.
>компиляция шейдеров при прогрузке материалов
Уже давно пофиксили асинхронной компиляцией (убершейдер подменяет специальный, пока специальный компилируется фоновым процессом) и кэшем на диске (после первой компиляции шейдер будет грузиться с диска, пока не почистишь %appdata%/Godot). Доступно это удовольствие в 3.5, я тестил - действительно работает, больше ни единого пропука после первой компиляции.
>делают текстурку на которую в начале игры все материалы накидывают
Этот "костыль" использовали во многих старых OpenGL играх.
>для таких штук как AtlasTexture и Tileset
>UV не будет перенастраиваться
Для этого нужно в шейдере объявить униформы и обновлять их через код. AtlasTexture - это упрощённая версия, чтобы не возиться с шейдерами, для чего-то большего нужно писать своё. На счёт тайлсета не знаю. Ты пытаешься шейдер на один тайл из тайлмапы накладывать? С какой целью? По-моему, для такой задачи (рамка, выделение, спецэффект какой) лучше спрайт создать поверх тайла. Тайлмапы вообще оптимизируют как статичную структуру, часто менять их содержимое должно быть накладно, но я не измерял.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/canvas_item_shader.html#fragment-built-ins
>Certain Nodes (for example, Sprites) display a texture by default. However, when a custom fragment function is attached to these nodes, the texture lookup needs to be done manually. Godot does not provide the texture color in the COLOR built-in variable; to read the texture color for such nodes, use:
>COLOR = texture(TEXTURE, UV);
Проще говоря - если ты пишешь фрагмент шейдер для нод канваса, будь готов самостоятельно разбираться с UV, потому что, скорее всего, все остальные ноды (тот же AtlasTexture) сделаны на шейдерах и ты перезаписываешь их поведение своим кодом. Не понимаю пока, почему нельзя поставить кастомный шейдер вслед за встроенным, но, возможно, есть на то причины (или ты не пробовал?).
>ущербного редактора тайлов
Можешь делать карты в Tiled, а импортировать скриптом. Тайлсеты тоже можно создавать из кода, достаточно написать скрипт и тогда сможешь автоматически обновлять всё без редактора Годо (ну типа закинул новые файлы с тайлами в папочку, нажал кнопку и получил готовый тайлсет без головной боли).
>вулкан не поддерживается видеокартой
Что-то древнее или ноутбук? В любом случае обещают поддерживать GLES3 как второй рендерер (для мобилок и веба). Несколько лет назад говорили про GLES2, но с тех пор много времени прошло и сказали, что выгоднее GLES3 поддерживать.
Перенёс все основные данные игры из ноды в кастомный ресурс, и узнал, что ресурсы можно сохранять через ResourceSaver.save(), хотел было по-быстрому это использовать, но задумался: а стоит ли полагаться на этот инструмент, раз над ним нет никакого контроля? Может, лучше вручную в JSON или даже свой собственный формат все данные загонять?
Просто данных много и желательно поддерживать совместимость новых версий игры со старыми сохранениями, как, например, это сделано в майнкрафте: в новых версиях можно открыть мир из почти любой старой версии, в процессе чего он конвертируется в новый формат и может стать несовместим со старыми версиями игры. В случае встроенного инструмента Godot, как я понимаю, должно быть точное совпадение интерфейсов и даже пути до скрипта, иначе загрузка сломается.
Да и в целом, хотелось бы иметь больше контроля над тем, что сохраняется, а что нет, и как оно сохраняется. Чтобы, допустим, не сохранялась информация, которую легко восстановить из другой информации - она будет только впустую занимать место на диске. Но с другой стороны, вроде можно сохранять ресурсы в сжатый бинарный формат, может, оно всё же эффективнее...
Я помню, несколько месяцев назад уже обсуждали способы сохранения. Но не помню, что в итоге решили...
Просто данных много и желательно поддерживать совместимость новых версий игры со старыми сохранениями, как, например, это сделано в майнкрафте: в новых версиях можно открыть мир из почти любой старой версии, в процессе чего он конвертируется в новый формат и может стать несовместим со старыми версиями игры. В случае встроенного инструмента Godot, как я понимаю, должно быть точное совпадение интерфейсов и даже пути до скрипта, иначе загрузка сломается.
Да и в целом, хотелось бы иметь больше контроля над тем, что сохраняется, а что нет, и как оно сохраняется. Чтобы, допустим, не сохранялась информация, которую легко восстановить из другой информации - она будет только впустую занимать место на диске. Но с другой стороны, вроде можно сохранять ресурсы в сжатый бинарный формат, может, оно всё же эффективнее...
Я помню, несколько месяцев назад уже обсуждали способы сохранения. Но не помню, что в итоге решили...
>>07514
Кастомные ресурсы прекрасны тем что ты можешь прямо в файловом менеджере кликнуть "создать новый ресурс" и уже хранить его в отдельной папке. А потом кликнуть мышкой и редактировать экспортнутые значения. На мой взгляд, это их основное использование - удобный интерфейс из под редактора.
Что насчёт загрузки: попробовал открыть в текстовом редакторе файл ресурса и убрать случайное поле, вроде редактор даже не ругался когда я открыл этот ресурс, экспортнутое поле просто заменилось на значение по умолчанию. 99.99% что load() сделает тоже самое а значит особых проблем с обратной совместимостью не будет если везде проставить значения по умолчанию или проверки на null
Кастомные ресурсы прекрасны тем что ты можешь прямо в файловом менеджере кликнуть "создать новый ресурс" и уже хранить его в отдельной папке. А потом кликнуть мышкой и редактировать экспортнутые значения. На мой взгляд, это их основное использование - удобный интерфейс из под редактора.
Что насчёт загрузки: попробовал открыть в текстовом редакторе файл ресурса и убрать случайное поле, вроде редактор даже не ругался когда я открыл этот ресурс, экспортнутое поле просто заменилось на значение по умолчанию. 99.99% что load() сделает тоже самое а значит особых проблем с обратной совместимостью не будет если везде проставить значения по умолчанию или проверки на null
>>07487
Насчёт кеширования я раньше думал что оно вообще не работает, но оказывается меня обманула настройка из 3.5 которая в консоль пишет когда шейдер компилируется, оказывается она тоже самое пишет когда он из кеша достаётся (кстати, на линухе путь .cache/godot/shaders/).
Насчёт кеширования я раньше думал что оно вообще не работает, но оказывается меня обманула настройка из 3.5 которая в консоль пишет когда шейдер компилируется, оказывается она тоже самое пишет когда он из кеша достаётся (кстати, на линухе путь .cache/godot/shaders/).
>>07514
Я участвовал в том обсуждении. Не знаю, кто какое мнение решил, моё осталось неизменно: для больших объёмов сохраняемых данных нужна СУБД, только она, для средних подойдёт ЖСОН/ХМЛ/ИНИ, для мелочи вот эти кастомные ресурсы вполне.
> Я помню, несколько месяцев назад уже обсуждали способы сохранения. Но не помню, что в итоге решили...
Я участвовал в том обсуждении. Не знаю, кто какое мнение решил, моё осталось неизменно: для больших объёмов сохраняемых данных нужна СУБД, только она, для средних подойдёт ЖСОН/ХМЛ/ИНИ, для мелочи вот эти кастомные ресурсы вполне.
А реально с этим годотом вкатиться-то на должность?
А то смотрю вакансий нихуя, в отличии от юнити.
Алсо, как в геймдеве относятся к бумеркам 30-40 лвл?
А то смотрю вакансий нихуя, в отличии от юнити.
Алсо, как в геймдеве относятся к бумеркам 30-40 лвл?
Похоже, наш тред посещает GDQuest!
Поговорили о ресурсах и сейвах и тут рраз: https://www.youtube.com/watch?v=wSq1QJ-g91M
Поговорили о ресурсах и сейвах и тут рраз: https://www.youtube.com/watch?v=wSq1QJ-g91M
>>07568
Майнкрафт сохраняет миры в СУБД? По-моему, там просто бинарные данные по разным файлам, каждый чанк в своём файле (можно жертвовать повреждёнными чанками, сохраняя мир в целом). Тем временем, мир 2b2t весит терабайты...
>для больших объёмов сохраняемых данных нужна СУБД, только она
Майнкрафт сохраняет миры в СУБД? По-моему, там просто бинарные данные по разным файлам, каждый чанк в своём файле (можно жертвовать повреждёнными чанками, сохраняя мир в целом). Тем временем, мир 2b2t весит терабайты...
>>07715
СУБД может быть самодельной, не поддерживать SQL ит.п., но это должна быть
И база данных при нём, повторяю приииньоооом! База данных может быть любой, хоть бинарной, хоть текстовой, хоть CSV, хоть JSON, хоть XML, хоть внутредвижковый RES/TRES.
СУБД может быть самодельной, не поддерживать SQL ит.п., но это должна быть
> С.истема
> У.правления
> Б.азой
> Д.анных
И база данных при нём, повторяю приииньоооом! База данных может быть любой, хоть бинарной, хоть текстовой, хоть CSV, хоть JSON, хоть XML, хоть внутредвижковый RES/TRES.
>>07978 (Del)
Прямо как левел-гд! Наша база, ёпта!
Прямо как левел-гд! Наша база, ёпта!
>>07972
https://ru.wikipedia.org/wiki/База_данных
Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.
Вместе с тем:
Т.е. базы данных - это как искусственный интеллект, все это словосочетание слышали и часто употребляют, но никто точного значения сказать не может, все придумывают по собственным ощущениям. Смысл употреблять это словосочетание в контексте сохранений состояния компьютерной игры?
Ты мне лучше с технической стороны скажи, а не с гуманитарной (расшифровку СУБД я и без тебя знал, школу закончил же). Стоит ли заморачиваться жсоном этим или сразу свой бинарный формат разрабатывать? Мне не сложно, просто не хочу потом как всегда по десять раз всё переделывать, мотивация падает.
Т.е. по теме ты ничего конкретного не сказал. Я вообще против таких терминов-общений: не важно, как это называют теоретики от информатики, важно, как это реализовать и использовать, как это работает, какие практические особенности имеет и т.д. А теоретизировать зачем? Чтобы похвастаться знаниями?
Извини, если грубо выразился, бомбит с таких теоретических ответов, которые по факту ни на что не отвечают, зато выглядят умно:
И это по-твоему ответ? Хорошо, буду называть свой save.txt базой данных, а функции save() и load() - СУБД. Доволен?
Ладно, какой вопрос - такой и ответ...
>база данных
https://ru.wikipedia.org/wiki/База_данных
>В литературе предлагается множество определений понятия «база данных», отражающих скорее субъективное мнение тех или иных авторов, однако общепризнанная единая формулировка отсутствует.
>В определениях наиболее часто (явно или неявно) присутствуют следующие отличительные признаки:
>1. БД хранится и обрабатывается в вычислительной системе.
Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.
>...
>Из перечисленных признаков только первый является строгим, а другие допускают различные трактовки и различные степени оценки. Можно лишь установить некоторую степень соответствия требованиям к БД.
Вместе с тем:
>В такой ситуации не последнюю роль играет общепринятая практика. В соответствии с ней, например, не называют базами данных файловые архивы, Интернет-порталы или электронные таблицы, несмотря на то, что они в некоторой степени обладают признаками БД. Принято считать, что эта степень в большинстве случаев недостаточна (хотя могут быть исключения).
Т.е. базы данных - это как искусственный интеллект, все это словосочетание слышали и часто употребляют, но никто точного значения сказать не может, все придумывают по собственным ощущениям. Смысл употреблять это словосочетание в контексте сохранений состояния компьютерной игры?
Ты мне лучше с технической стороны скажи, а не с гуманитарной (расшифровку СУБД я и без тебя знал, школу закончил же). Стоит ли заморачиваться жсоном этим или сразу свой бинарный формат разрабатывать? Мне не сложно, просто не хочу потом как всегда по десять раз всё переделывать, мотивация падает.
>База данных может быть любой, хоть бинарной, хоть текстовой, хоть CSV, хоть JSON, хоть XML, хоть внутредвижковый RES/TRES.
Т.е. по теме ты ничего конкретного не сказал. Я вообще против таких терминов-общений: не важно, как это называют теоретики от информатики, важно, как это реализовать и использовать, как это работает, какие практические особенности имеет и т.д. А теоретизировать зачем? Чтобы похвастаться знаниями?
Извини, если грубо выразился, бомбит с таких теоретических ответов, которые по факту ни на что не отвечают, зато выглядят умно:
>Для сохранений СУБД нужна. СУБД - система управления базами данных. База данных может быть сделана как угодно, из чего угодно, на чём угодно, где угодно. Дальше разбирайся сам.
И это по-твоему ответ? Хорошо, буду называть свой save.txt базой данных, а функции save() и load() - СУБД. Доволен?
Ладно, какой вопрос - такой и ответ...
>>07972
https://ru.wikipedia.org/wiki/База_данных
Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.
Вместе с тем:
Т.е. базы данных - это как искусственный интеллект, все это словосочетание слышали и часто употребляют, но никто точного значения сказать не может, все придумывают по собственным ощущениям. Смысл употреблять это словосочетание в контексте сохранений состояния компьютерной игры?
Ты мне лучше с технической стороны скажи, а не с гуманитарной (расшифровку СУБД я и без тебя знал, школу закончил же). Стоит ли заморачиваться жсоном этим или сразу свой бинарный формат разрабатывать? Мне не сложно, просто не хочу потом как всегда по десять раз всё переделывать, мотивация падает.
Т.е. по теме ты ничего конкретного не сказал. Я вообще против таких терминов-общений: не важно, как это называют теоретики от информатики, важно, как это реализовать и использовать, как это работает, какие практические особенности имеет и т.д. А теоретизировать зачем? Чтобы похвастаться знаниями?
Извини, если грубо выразился, бомбит с таких теоретических ответов, которые по факту ни на что не отвечают, зато выглядят умно:
И это по-твоему ответ? Хорошо, буду называть свой save.txt базой данных, а функции save() и load() - СУБД. Доволен?
Ладно, какой вопрос - такой и ответ...
>база данных
https://ru.wikipedia.org/wiki/База_данных
>В литературе предлагается множество определений понятия «база данных», отражающих скорее субъективное мнение тех или иных авторов, однако общепризнанная единая формулировка отсутствует.
>В определениях наиболее часто (явно или неявно) присутствуют следующие отличительные признаки:
>1. БД хранится и обрабатывается в вычислительной системе.
Таким образом, любые внекомпьютерные хранилища информации (архивы, библиотеки, картотеки и т. п.) базами данных не являются.
>...
>Из перечисленных признаков только первый является строгим, а другие допускают различные трактовки и различные степени оценки. Можно лишь установить некоторую степень соответствия требованиям к БД.
Вместе с тем:
>В такой ситуации не последнюю роль играет общепринятая практика. В соответствии с ней, например, не называют базами данных файловые архивы, Интернет-порталы или электронные таблицы, несмотря на то, что они в некоторой степени обладают признаками БД. Принято считать, что эта степень в большинстве случаев недостаточна (хотя могут быть исключения).
Т.е. базы данных - это как искусственный интеллект, все это словосочетание слышали и часто употребляют, но никто точного значения сказать не может, все придумывают по собственным ощущениям. Смысл употреблять это словосочетание в контексте сохранений состояния компьютерной игры?
Ты мне лучше с технической стороны скажи, а не с гуманитарной (расшифровку СУБД я и без тебя знал, школу закончил же). Стоит ли заморачиваться жсоном этим или сразу свой бинарный формат разрабатывать? Мне не сложно, просто не хочу потом как всегда по десять раз всё переделывать, мотивация падает.
>База данных может быть любой, хоть бинарной, хоть текстовой, хоть CSV, хоть JSON, хоть XML, хоть внутредвижковый RES/TRES.
Т.е. по теме ты ничего конкретного не сказал. Я вообще против таких терминов-общений: не важно, как это называют теоретики от информатики, важно, как это реализовать и использовать, как это работает, какие практические особенности имеет и т.д. А теоретизировать зачем? Чтобы похвастаться знаниями?
Извини, если грубо выразился, бомбит с таких теоретических ответов, которые по факту ни на что не отвечают, зато выглядят умно:
>Для сохранений СУБД нужна. СУБД - система управления базами данных. База данных может быть сделана как угодно, из чего угодно, на чём угодно, где угодно. Дальше разбирайся сам.
И это по-твоему ответ? Хорошо, буду называть свой save.txt базой данных, а функции save() и load() - СУБД. Доволен?
Ладно, какой вопрос - такой и ответ...
>>08003
Недоволен. Сделай отдельный скрипт, назови его DBManager, сделай там пустые (абстрактные) save() и load(). Затем унаследуй от него новый скрипт TextDBManager и реализуй там save() и load() для txt файла. Вот тогда это будет минимальная СУБД.
> Хорошо, буду называть свой save.txt базой данных, а функции save() и load() - СУБД. Доволен?
Недоволен. Сделай отдельный скрипт, назови его DBManager, сделай там пустые (абстрактные) save() и load(). Затем унаследуй от него новый скрипт TextDBManager и реализуй там save() и load() для txt файла. Вот тогда это будет минимальная СУБД.
>>08006
Таки всё ли дело в названиях?
>>08004
Мне больше важно, чтобы примитивный мир не занимал 150 МБ в виде чего-то вроде ini (tres же). На втором месте надёжность, чтобы не получилось так, что мир загрузился и работает, но потом там ошибка какая-то скрытая выявляется (уже испортившая сейв).
Это правда, конечно...
>назови его DBManager
>TextDBManager
Таки всё ли дело в названиях?
>>08004
>что тебе больше нравится
Мне больше важно, чтобы примитивный мир не занимал 150 МБ в виде чего-то вроде ini (tres же). На втором месте надёжность, чтобы не получилось так, что мир загрузился и работает, но потом там ошибка какая-то скрытая выявляется (уже испортившая сейв).
>Переделывать всё равно придётся. И не раз.
Это правда, конечно...
>>08006
Минимально претендующая на это звание. Чтобы СУБД была по настоящему системой настоящего управления, тебе нужно реализовать слой абстракции поверх текстового файла: "база данных", "таблица", "запрос", "скрипт" или "процедура". И в скрипте менеджера у тебя будут методы для работы с этими сущностями. И методы для валидации. Так, чтобы тебе не пришлось копаться в потрохах сейв файла, а например написать как-то так:
> Вот тогда это будет минимальная СУБД.
Минимально претендующая на это звание. Чтобы СУБД была по настоящему системой настоящего управления, тебе нужно реализовать слой абстракции поверх текстового файла: "база данных", "таблица", "запрос", "скрипт" или "процедура". И в скрипте менеджера у тебя будут методы для работы с этими сущностями. И методы для валидации. Так, чтобы тебе не пришлось копаться в потрохах сейв файла, а например написать как-то так:
> var DBMan = TextDBManager.new()
> var SaveMan = SaveManager.new()
> if DBMan.Connect("user://saves/save.txt") == OK && DBMan.has(DBEntities.Table, "save_config"):
> > var save_config : DBTable = DBMan.get_entity(DBEntities.Table, "save_config")
> > SaveMan.configure(save_config)
> > SaveMan.load()
>>08011
Конвертация в бинарный файл сэкономит на пробелах и переносах строк некоторое количество байт. Но в целом для минимизации сейва нужно чтобы в нём хранились как бы это правильнее сказать, индексированные данные. То есть, чтобы там хранились ссылки на данные внутри игры.
Я говорил об этом ранее. Игровой мир существует в эталонном виде, на момент до начала игры. Он может хоть 4 гигабайта весить. Он неизменяем. Ридонли. В сейвах хранится только информация о том, как модифицировать эталонный игровой мир, чтобы привести его к состоянию, в котором игрок сохранился. Способов это реализовать много.
Валидация и контрольные суммы.
> Мне больше важно, чтобы примитивный мир не занимал 150 МБ
Конвертация в бинарный файл сэкономит на пробелах и переносах строк некоторое количество байт. Но в целом для минимизации сейва нужно чтобы в нём хранились как бы это правильнее сказать, индексированные данные. То есть, чтобы там хранились ссылки на данные внутри игры.
Я говорил об этом ранее. Игровой мир существует в эталонном виде, на момент до начала игры. Он может хоть 4 гигабайта весить. Он неизменяем. Ридонли. В сейвах хранится только информация о том, как модифицировать эталонный игровой мир, чтобы привести его к состоянию, в котором игрок сохранился. Способов это реализовать много.
> На втором месте надёжность, чтобы не получилось так, что мир загрузился и работает, но потом там ошибка какая-то скрытая выявляется (уже испортившая сейв).
Валидация и контрольные суммы.
>>08012
По-моему, это не обязательно. Базы данных не обязательно содержат таблицы, разве нет? Структура какая-то должна быть, но она не обязательно в виде таблицы...
Ну и что это даёт в практическом смысле?
Если в файле какая-то ошибка, тебе в любом случае придётся вручную копаться и искать эту ошибку, исправлять её.
Гораздо проще сделать так:
>>08013
Он процедурный. Неизменяемый мир и хранить не надо (лол). Потому я и упомянул Майнкрафт, там кроме текстур и пары моделек мобов всё остальное нужно сохранять, иначе игра сломается.
Я знаю про индексацию, RLE и т.д., но мне лень делать велосипед, мне бы какой-нибудь встроенный zip-архиватор... Ну, если что, можно и свой архиватор написать... на GDScript...
>слой абстракции поверх текстового файла: "база данных", "таблица", "запрос", "скрипт" или "процедура"
По-моему, это не обязательно. Базы данных не обязательно содержат таблицы, разве нет? Структура какая-то должна быть, но она не обязательно в виде таблицы...
>Так, чтобы тебе не пришлось копаться в потрохах сейв файла, а например написать как-то так:
Ну и что это даёт в практическом смысле?
Если в файле какая-то ошибка, тебе в любом случае придётся вручную копаться и искать эту ошибку, исправлять её.
Гораздо проще сделать так:
>var data := GameData.new()
>var error := data.load("last.save")
>if not error: game.start(data)
>else: dialog.ask("Warning", "The save file is corrupted. Go cry for the wasted hours of your life.", ["ok", "nooooo!.."])
>>08013
>Он неизменяем.
Он процедурный. Неизменяемый мир и хранить не надо (лол). Потому я и упомянул Майнкрафт, там кроме текстур и пары моделек мобов всё остальное нужно сохранять, иначе игра сломается.
Я знаю про индексацию, RLE и т.д., но мне лень делать велосипед, мне бы какой-нибудь встроенный zip-архиватор... Ну, если что, можно и свой архиватор написать... на GDScript...
Я не знаю ЗАЧЕМ, но мне понравилась возникшая идея и я реализовал прототип всплывающих уведомлений. Я без понятия, пригодится ли мне это в моей игре (я вообще не знаю, что я делаю, есть только набор абстрактных хотелок), но выглядит прикольно. На скриншоте весь код, если кому-то интересно.
Пока делал подписи на скриншоте, задумался, что, наверное, можно было бы сократить код, сделав всё одной анимацией (и появление, и печать букв, и сдвиг прогрессбара, и удаление). А длину анимации изменять скоростью среднего сегмента (когда окно уже появилось и началась печать текста?). Но дело в том, что начинал я с простого окошка без анимаций, и добавил их потом...
Пока делал подписи на скриншоте, задумался, что, наверное, можно было бы сократить код, сделав всё одной анимацией (и появление, и печать букв, и сдвиг прогрессбара, и удаление). А длину анимации изменять скоростью среднего сегмента (когда окно уже появилось и началась печать текста?). Но дело в том, что начинал я с простого окошка без анимаций, и добавил их потом...
>>08028
Я слышал о таком подходе, но у него есть недостатки:
1. Если использовать встроенный ГПСЧ, то с обновлением движка может измениться и результат генерации.
1.1. Если использовать свой ГПСЧ, то на GDScript хороший ГПСЧ будет медленным, а быстрый будет выдавать фигню.
1.2. Если движок не обновлять, лишаешь проект багфиксов и различных улучшений, что тоже нехорошо.
2. Генерации мира свойственно обновляться (потому я и упомянул майнкрафт, там почти каждая 1.x версия меняет генерацию), что гарантированно ломает такие сохранения.
2.1. Даже если локализовать генерацию по чанкам (генерировать зёрна для каждого чанка одним ГПСЧ, а затем каждому чанку создать отдельный ГПСЧ), всё равно изменения генерации будут нарушать сохранение, как минимум в некоторых чанках.
Короче, надёжнее всего сохранять все данные, полученные от генератора, кроме тех, которые можно однозначно вывести из других, например, ориентация тайлов дорог зависит от соседних тайлов, поэтому её не обязательно сохранять на диск.
>>08027
Пока что нет, даже в 4.0 ещё не добавили:
https://github.com/godotengine/godot/pull/34444
Тем временем предлагали это сделать ещё 6 лет назад:
https://github.com/godotengine/godot/issues/3701
Или ты про PCKPacker? Я поискал, он не умеет паковать в zip, потому что "упакованные игровые данные будет сложно загружать". Для распаковки есть load_resource_pack():
Но это не подходит для системы сохранений, это скорее рассчитано на установку модификаций/патчей для игры.
>сохранять как сид
Я слышал о таком подходе, но у него есть недостатки:
1. Если использовать встроенный ГПСЧ, то с обновлением движка может измениться и результат генерации.
1.1. Если использовать свой ГПСЧ, то на GDScript хороший ГПСЧ будет медленным, а быстрый будет выдавать фигню.
1.2. Если движок не обновлять, лишаешь проект багфиксов и различных улучшений, что тоже нехорошо.
2. Генерации мира свойственно обновляться (потому я и упомянул майнкрафт, там почти каждая 1.x версия меняет генерацию), что гарантированно ломает такие сохранения.
2.1. Даже если локализовать генерацию по чанкам (генерировать зёрна для каждого чанка одним ГПСЧ, а затем каждому чанку создать отдельный ГПСЧ), всё равно изменения генерации будут нарушать сохранение, как минимум в некоторых чанках.
Короче, надёжнее всего сохранять все данные, полученные от генератора, кроме тех, которые можно однозначно вывести из других, например, ориентация тайлов дорог зависит от соседних тайлов, поэтому её не обязательно сохранять на диск.
>>08027
>Там есть. Читай документацию.
Пока что нет, даже в 4.0 ещё не добавили:
https://github.com/godotengine/godot/pull/34444
Тем временем предлагали это сделать ещё 6 лет назад:
https://github.com/godotengine/godot/issues/3701
Или ты про PCKPacker? Я поискал, он не умеет паковать в zip, потому что "упакованные игровые данные будет сложно загружать". Для распаковки есть load_resource_pack():
>Loads the contents of the .pck or .zip file specified by pack into the resource filesystem (res://). Returns true on success.
Но это не подходит для системы сохранений, это скорее рассчитано на установку модификаций/патчей для игры.
16 Кб, 614x182>>08204
Не изменится. Там используется классический алгоритм. Знать надо!
Нахуй тебе зип? Чем тебя не устраивают пикрелейтед варианты?
> то с обновлением движка может измениться и результат генерации
Не изменится. Там используется классический алгоритм. Знать надо!
> не умеет паковать в zip
Нахуй тебе зип? Чем тебя не устраивают пикрелейтед варианты?
>>08182
это на каком движке?
это на каком движке?
142 Кб, 512x542>>00308 (OP)
Годаны, играюсь с генерацией узоров, сделал это на tilemap, с атласом на восемь цветов небольшого размера, но скорость работы оказалась медленной.
Как быть?
Конкретно нужна отрисовка массива с цветами, причём чтобы это можно было масштабировать.
Годаны, играюсь с генерацией узоров, сделал это на tilemap, с атласом на восемь цветов небольшого размера, но скорость работы оказалась медленной.
Как быть?
Конкретно нужна отрисовка массива с цветами, причём чтобы это можно было масштабировать.
>>08436 (Del)
Да, я только что поглядел как записывать в текстуру, но ничего не смог найти.
У меня есть аналог на C++, но он неудобный и громоздкий, потому перенести решил туда, где проще.
Сейчас использую питон версию.
>>08437
Два варианта
Последовательный:
Проходимся по каждому пикселю и проверяем вокруг него наличие хотя бы одного с цветом на единицу больше, условно, например порядковый номер, меняем этот пиксель прямо в текущем массиве, прерываем поиск, идём к следующему пикселю
Копируем массив например в текстуру
Параллельный:
Всё тоже самое, только изменённый цвет пишем в такой же массив, а исходный просто читаем. После копируем новый массив в старый для замыкания. Второй массив с изменениями копируем в текстуру.
Понятное дело, что самый быстрый способ это прямо в шейдере, но у меня с ними не очень, ибо не всё известно и надо искать.
На С++ при помощи опенгл просто использовал указатель на массив и его же передавал в буфер гла.
Да, я только что поглядел как записывать в текстуру, но ничего не смог найти.
У меня есть аналог на C++, но он неудобный и громоздкий, потому перенести решил туда, где проще.
Сейчас использую питон версию.
>>08437
Два варианта
Последовательный:
Проходимся по каждому пикселю и проверяем вокруг него наличие хотя бы одного с цветом на единицу больше, условно, например порядковый номер, меняем этот пиксель прямо в текущем массиве, прерываем поиск, идём к следующему пикселю
Копируем массив например в текстуру
Параллельный:
Всё тоже самое, только изменённый цвет пишем в такой же массив, а исходный просто читаем. После копируем новый массив в старый для замыкания. Второй массив с изменениями копируем в текстуру.
Понятное дело, что самый быстрый способ это прямо в шейдере, но у меня с ними не очень, ибо не всё известно и надо искать.
На С++ при помощи опенгл просто использовал указатель на массив и его же передавал в буфер гла.
Приветствую. Кто разбиратся, можно ли на годоте собрать что то вроде дагерфола или визардри(рпг в стиле тех что были на DOS, от первого лица, в открытом мире)? Или слишком большие миры он не потянет. ?
69 Кб, 509x537>>08442 (Del)
>>08444 (Del)
Благодарю тебя, о гуру годота.
На С++ модуль пока слишком сложно, я хоть и делал воксели в унити на шейдерах, но это была возня.
Попробую на этой основе сделать тоже самое.
>>08444 (Del)
Благодарю тебя, о гуру годота.
На С++ модуль пока слишком сложно, я хоть и делал воксели в унити на шейдерах, но это была возня.
Попробую на этой основе сделать тоже самое.
>>08445
Тут скорее потянешь ли ты это. А так можно
Тут скорее потянешь ли ты это. А так можно
>>08312
Когда речь идёт о третьих лицах, нужно ожидать худшего. Конечно, я могу сделать форк и пытаться его сам править, но я же не гений C++ движкописательства, чтобы этим заниматься. Поэтому самое надёжное - заранее написать свой ГПСЧ. Или просто не полагаться на то, что ГПСЧ будет выдавать одну и ту же последовательность чисел (т.е. сохранять все данные как есть).
Тем, что ты кидаешь кусок скриншота, а не ссылку?
https://docs.godotengine.org/en/stable/classes/class_file.html#class-file-method-open-compressed
Я ожидал отдельный класс для сжатия и разжатия архивов, а не одну незаметную функцию в классе File. И, как я понимаю, эта функция не позволит упаковать в один файл какие-нибудь данные и png-картинку для сейва, чтобы потом можно было открыть в архиваторе и увидеть конкретные файлы (как можно открыть APK, KRA, DOCX, XLSX и другие подобные форматы). Впрочем, это не так уж важно, я и без этого планировал создавать папки с кучей файлов...
А ZIP мне кажется самым распространённым форматом, поэтому и искал именно его. Как там внутри алгоритмы сжатия называются - мне не важно, если это менее эффективно, чем RAR - значит, это ZIP или какой-то из его вариантов (у многих же Z в названии, лол). Говорю с позиции обывателя, т.к. программно архивация меня никогда не интересовала, чтобы её изучать.
>Не изменится.
Когда речь идёт о третьих лицах, нужно ожидать худшего. Конечно, я могу сделать форк и пытаться его сам править, но я же не гений C++ движкописательства, чтобы этим заниматься. Поэтому самое надёжное - заранее написать свой ГПСЧ. Или просто не полагаться на то, что ГПСЧ будет выдавать одну и ту же последовательность чисел (т.е. сохранять все данные как есть).
>Чем тебя не устраивают пикрелейтед варианты?
Тем, что ты кидаешь кусок скриншота, а не ссылку?
https://docs.godotengine.org/en/stable/classes/class_file.html#class-file-method-open-compressed
Я ожидал отдельный класс для сжатия и разжатия архивов, а не одну незаметную функцию в классе File. И, как я понимаю, эта функция не позволит упаковать в один файл какие-нибудь данные и png-картинку для сейва, чтобы потом можно было открыть в архиваторе и увидеть конкретные файлы (как можно открыть APK, KRA, DOCX, XLSX и другие подобные форматы). Впрочем, это не так уж важно, я и без этого планировал создавать папки с кучей файлов...
А ZIP мне кажется самым распространённым форматом, поэтому и искал именно его. Как там внутри алгоритмы сжатия называются - мне не важно, если это менее эффективно, чем RAR - значит, это ZIP или какой-то из его вариантов (у многих же Z в названии, лол). Говорю с позиции обывателя, т.к. программно архивация меня никогда не интересовала, чтобы её изучать.
>>08428
Я решил эту проблему так: рисую квадратики в _draw() Control, это всё записывает в текстуру Viewport, у которого режим обновления установлен на UPDATE_ONCE. Если нужно обновить текстуру, достаточно кинуть вьюпорту запрос на рендеринг.
А что именно ты хочешь нарисовать?
>>08439
Лучше всего менять местами только ссылки на массивы:
Т.к. копирование данных занимает много времени.
А тебе только текстура нужна? Не данные?
>>08448
Чтобы текстура не размазывалась при растягивании (приближении), нужно выключить флаг FLAG_FILTER:
https://docs.godotengine.org/en/stable/classes/class_texture.html#class-texture-property-flags
Но при сжатии (когда текстура занимает на экране меньше пикселей, чем содержит в себе) этот флаг всё же лучше включить.
>Конкретно нужна отрисовка массива с цветами, причём чтобы это можно было масштабировать.
Я решил эту проблему так: рисую квадратики в _draw() Control, это всё записывает в текстуру Viewport, у которого режим обновления установлен на UPDATE_ONCE. Если нужно обновить текстуру, достаточно кинуть вьюпорту запрос на рендеринг.
>играюсь с генерацией узоров
А что именно ты хочешь нарисовать?
>>08439
>копируем новый массив в старый для замыкания
Лучше всего менять местами только ссылки на массивы:
>var buf := a
>a = b
>b = buf
Т.к. копирование данных занимает много времени.
>прямо в шейдере
А тебе только текстура нужна? Не данные?
>>08448
Чтобы текстура не размазывалась при растягивании (приближении), нужно выключить флаг FLAG_FILTER:
https://docs.godotengine.org/en/stable/classes/class_texture.html#class-texture-property-flags
Но при сжатии (когда текстура занимает на экране меньше пикселей, чем содержит в себе) этот флаг всё же лучше включить.
68 Кб, 512x542Фейл, беда похоже не в отображении, а в логике.
Подобное было у меня и на С++, когда я сделал свой класс-обёртку над массивом данных и обращался к каждому элементу через метод. Потом когда переписал на чисто указателях, то разница была в сотни раз по скорости.
>>08466
Вообще ничего не понятно
У меня книга есть 2000 года, я по ней учился тогда программировать, там есть программа, которая рисует узор, я вот её усовершенствовал и экспериментирую. Есть подобное про клетку автомат, как-то так.
Проблема в том, что мне надо именно два разных блока данных, иначе магия пропадёт
Если смотреть с точки зрения С++, то вся возня с блоком байт, которые начинаются по такому-то адресу и все изменения производить с ними
Так не режет глаза
Подобное было у меня и на С++, когда я сделал свой класс-обёртку над массивом данных и обращался к каждому элементу через метод. Потом когда переписал на чисто указателях, то разница была в сотни раз по скорости.
>>08466
> рисую квадратики в _draw() Control
Вообще ничего не понятно
> А что именно ты хочешь нарисовать?
У меня книга есть 2000 года, я по ней учился тогда программировать, там есть программа, которая рисует узор, я вот её усовершенствовал и экспериментирую. Есть подобное про клетку автомат, как-то так.
> Лучше всего менять местами только ссылки на массивы
Проблема в том, что мне надо именно два разных блока данных, иначе магия пропадёт
> А тебе только текстура нужна? Не данные?
Если смотреть с точки зрения С++, то вся возня с блоком байт, которые начинаются по такому-то адресу и все изменения производить с ними
> нужно выключить флаг FLAG_FILTER
Так не режет глаза
>>08470
А ты точно один раз рисуешь и потом больше ничего не делаешь? Если ты 60 раз в секунду текстуру с нуля рисуешь по пикселям, то ничего удивительного, что всё тормозит.
Туториал: https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
Метод, который я использую: https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-method-draw-rect
Пример кода:
Должен нарисовать чёрный квадратик 100 на 100 пикселей. Правда, мне нужны были именно квадратики и другие операции отрисовки, а не простое редактирование пикселей. Попиксельно нарисовать что-то осмысленное сложнее...
Это называется https://ru.wikipedia.org/wiki/Клеточный_автомат
Так тебе не нужно менять блоки данных местами. Тебе достаточно поменять местами ссылки. Есть ссылка А и ссылка Б, ты через них получаешь доступ к данным массивов, меняешь ссылки местами и получается будто бы данные массивов поменялись местами, но эта операция практически ничего не стоит.
Нет, я имел в виду, тебе нужно только текстуру нарисовать или потом использовать эти данные для чего-то другого (построения 3D меша, физики, навигации ботов и т.п.)? Хотя, наверное, есть способы извлечь данные из шейдера, я сам в них почти не разбираюсь.
С фильтром ты теряешь контроль над отдельными пикселями/клетками. Лучше самому найти способ "сглаживания" рисунка, чем полагаться на фильтр текстуры. Впрочем, всё зависит от твоей конечной цели...
>Фейл, беда похоже не в отображении, а в логике.
А ты точно один раз рисуешь и потом больше ничего не делаешь? Если ты 60 раз в секунду текстуру с нуля рисуешь по пикселям, то ничего удивительного, что всё тормозит.
>Вообще ничего не понятно
Туториал: https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
Метод, который я использую: https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-method-draw-rect
Пример кода:
>func _draw():
>draw_rect(Rect2(0, 0, 100, 100), Color(0, 0, 0))
Должен нарисовать чёрный квадратик 100 на 100 пикселей. Правда, мне нужны были именно квадратики и другие операции отрисовки, а не простое редактирование пикселей. Попиксельно нарисовать что-то осмысленное сложнее...
>клетку автомат
Это называется https://ru.wikipedia.org/wiki/Клеточный_автомат
>мне надо именно два разных блока данных
Так тебе не нужно менять блоки данных местами. Тебе достаточно поменять местами ссылки. Есть ссылка А и ссылка Б, ты через них получаешь доступ к данным массивов, меняешь ссылки местами и получается будто бы данные массивов поменялись местами, но эта операция практически ничего не стоит.
>Если смотреть с точки зрения С++, то вся возня с блоком байт
Нет, я имел в виду, тебе нужно только текстуру нарисовать или потом использовать эти данные для чего-то другого (построения 3D меша, физики, навигации ботов и т.п.)? Хотя, наверное, есть способы извлечь данные из шейдера, я сам в них почти не разбираюсь.
>Так не режет глаза
С фильтром ты теряешь контроль над отдельными пикселями/клетками. Лучше самому найти способ "сглаживания" рисунка, чем полагаться на фильтр текстуры. Впрочем, всё зависит от твоей конечной цели...
>>08478
За один такт
Идёт проход по всем элементам с проверкой вокруг и копированием в другой массив
Копирование итогового изменённого массива в текстуру
На опенлг это работает в разы быстрее и на больших размерах. Если же просто шум бабахать, то он быстро работает.
> А ты точно один раз рисуешь и потом больше ничего не делаешь? Если ты 60 раз в секунду текстуру с нуля рисуешь по пикселям, то ничего удивительного, что всё тормозит.
За один такт
Идёт проход по всем элементам с проверкой вокруг и копированием в другой массив
Копирование итогового изменённого массива в текстуру
На опенлг это работает в разы быстрее и на больших размерах. Если же просто шум бабахать, то он быстро работает.
>>08482
А массив какого размера?
Вот такие карты >>05783 (тут 6 штук, склеил скриншоты в пейнте) генерируются менее чем за секунду, отрисовку карты вообще не учитываю. Самый долгий этап - наращивание земли и песка вокруг дорог клеточным автоматом, я там поставил 5-6 проходов по массиву. До этого пробовал другие способы генерации, тут >>789499 → есть скриншоты примеров, ниже >>789957 → скриншот кода клеточного автомата.
Но у нас, похоже, разные задачи. Мне нужны данные для генерации целого мира с городом, которые игра всего один раз сделает и дальше будет только запрашивать для создания 3D чанков, карта тоже рисуется всего один раз. Эти же данные нужны для навигации жителей и прочей игровой логики. При этом общий вид должен быть осмысленным, относительно похож на реальный мир и удобен для игрока, поэтому я не могу просто рандомные числа раскидать. Приходится выдумывать многоступенчатую генерацию... А длительность генерации тут значения не имеет, достаточно будет сделать экран генерации мира со шкалой завершения и всё, во всех процедурных играх такая фигня есть и никто не жалуется на скорость генерации.
А если тебе эта штука нужна только для экспериментов с 2D графикой и ты не планируешь использовать это для игры, то зачем вообще Godot? Это как микроскопом гвозди забивать...
>Идёт проход по всем элементам с проверкой вокруг и копированием в другой массив
А массив какого размера?
Вот такие карты >>05783 (тут 6 штук, склеил скриншоты в пейнте) генерируются менее чем за секунду, отрисовку карты вообще не учитываю. Самый долгий этап - наращивание земли и песка вокруг дорог клеточным автоматом, я там поставил 5-6 проходов по массиву. До этого пробовал другие способы генерации, тут >>789499 → есть скриншоты примеров, ниже >>789957 → скриншот кода клеточного автомата.
Но у нас, похоже, разные задачи. Мне нужны данные для генерации целого мира с городом, которые игра всего один раз сделает и дальше будет только запрашивать для создания 3D чанков, карта тоже рисуется всего один раз. Эти же данные нужны для навигации жителей и прочей игровой логики. При этом общий вид должен быть осмысленным, относительно похож на реальный мир и удобен для игрока, поэтому я не могу просто рандомные числа раскидать. Приходится выдумывать многоступенчатую генерацию... А длительность генерации тут значения не имеет, достаточно будет сделать экран генерации мира со шкалой завершения и всё, во всех процедурных играх такая фигня есть и никто не жалуется на скорость генерации.
А если тебе эта штука нужна только для экспериментов с 2D графикой и ты не планируешь использовать это для игры, то зачем вообще Godot? Это как микроскопом гвозди забивать...
>>08496
Годо смог родить с терпимой частотой кадров 64 на 64 - 4096
В С++ на указателях мне удалось сделать копирование массива 2048 на 2048 - 4 000 000 за 1 - 2 мс, что быстрее вектора - 50 - 70 мс аналогичной длинны
C++ ооооооооооооооооооооочень громоздкий в плане создания интерфейса, да даже казалось бы создания заготовки - окно, класс с текстурой, но дальше уже гемор с кнопками и прочим, да, есть imgui, но, это гемор.
Годо меня полностью устраивает, просто ожидал большего.
Теперь остался последний вариант в нём - шейдеры, да вот только как это сделать именно так как нужно мне. Насколько я понимаю шейдер пишется для отдельного пикселя и работает только с ним, исключение вычислительный шейдер, если он есть. Тогда вся возня в вычислительном, а потом передача в вершинный и фрагментный.
Меня отпугнул опенгл именно из-за велосипедного способа что-то сделать в шейдерах, очень неудобно и буквально изъёбисто например рисовать казалось бы просто кучу одинаковых объектов и простых примеров просто не может быть потому что кода по умолчанию про очень много, тут даже классы и прочее не особо спасают.
> А массив какого размера?
Годо смог родить с терпимой частотой кадров 64 на 64 - 4096
В С++ на указателях мне удалось сделать копирование массива 2048 на 2048 - 4 000 000 за 1 - 2 мс, что быстрее вектора - 50 - 70 мс аналогичной длинны
> А если тебе эта штука нужна только для экспериментов с 2D графикой и ты не планируешь использовать это для игры, то зачем вообще Godot? Это как микроскопом гвозди забивать...
C++ ооооооооооооооооооооочень громоздкий в плане создания интерфейса, да даже казалось бы создания заготовки - окно, класс с текстурой, но дальше уже гемор с кнопками и прочим, да, есть imgui, но, это гемор.
Годо меня полностью устраивает, просто ожидал большего.
Теперь остался последний вариант в нём - шейдеры, да вот только как это сделать именно так как нужно мне. Насколько я понимаю шейдер пишется для отдельного пикселя и работает только с ним, исключение вычислительный шейдер, если он есть. Тогда вся возня в вычислительном, а потом передача в вершинный и фрагментный.
Меня отпугнул опенгл именно из-за велосипедного способа что-то сделать в шейдерах, очень неудобно и буквально изъёбисто например рисовать казалось бы просто кучу одинаковых объектов и простых примеров просто не может быть потому что кода по умолчанию про очень много, тут даже классы и прочее не особо спасают.
>>08499
речь про попиксельную обработку если что и это мне не нравится, потому что надо относительно этого элемента смотреть на другие.
> отдельного пикселя
речь про попиксельную обработку если что и это мне не нравится, потому что надо относительно этого элемента смотреть на другие.
41 Кб, 746x394>>08502 (Del)
Я понял, буду пробовать по разному.
В крайнем случае титаническими усилиями сделаю на С++ с опенгл
На годо буду делать другое - арканоид
Меня вообще расстраивает, что воксели так просто не сделать, попиксельную коллизию тоже - всё надо возиться с С++, а там гуи делается только на qt.
О БОГИ! Идёт 2022, а круче С/С++ так и не смогли сделать, шаг в сторону и наступает время для велосипедов.
Надо будет докопаться до уе фанатика, чтобы он на блюпритнах такую программу сделал, лол
Я понял, буду пробовать по разному.
В крайнем случае титаническими усилиями сделаю на С++ с опенгл
На годо буду делать другое - арканоид
Меня вообще расстраивает, что воксели так просто не сделать, попиксельную коллизию тоже - всё надо возиться с С++, а там гуи делается только на qt.
О БОГИ! Идёт 2022, а круче С/С++ так и не смогли сделать, шаг в сторону и наступает время для велосипедов.
Надо будет докопаться до уе фанатика, чтобы он на блюпритнах такую программу сделал, лол
>>08505
А ещё есть старый добрый паскаль в его современной ипостаси FreePascal Compiler, который где-то медленнее си, а где-то и быстрее. В любом случае, быстрее чем си с паскалем, не умеет никто.
А ещё есть старый добрый паскаль в его современной ипостаси FreePascal Compiler, который где-то медленнее си, а где-то и быстрее. В любом случае, быстрее чем си с паскалем, не умеет никто.
>>08505
Не знаю о чём ты, все давно используют питон + с библиотеки. От датасантистов до игроделов.
> круче С/С++ так и не смогли сделать
Не знаю о чём ты, все давно используют питон + с библиотеки. От датасантистов до игроделов.
>>08499
SDL пробовал? Там легко окно создаётся и есть встроенный 2D рендерер с классами картинок и текстур. Простые кнопки сделать очень легко, достаточно определять координаты клика.
>>08502 (Del)
Разве? Столько разных примеров процедурной генерации ландшафта... Недавно вот на реддите был пример процедурных следов на снегу, там хвастались, что теперь в 4.0 можно делать глобальные параметры, в результате след от персонажа - это рендер в глобальную текстуру, которую считывают все шейдеры снега. Или как-то так. Кто пишет в эту текстуру? Viewport что ли?
>>08505
Я не понимаю, при чём тут C/C++? Тебя только производительность волнует или что? Зачем тебе вообще нужно каждый кадр новый узор попиксельно генерировать? Просто запусти программу и отойди от компа, разомнись там, кофейку завари. Раньше только так и работали: забили, значит, программу на перфоленты, отнесли в вычислительный центр рулоны, а результат из ВЦ только в следующий понедельник - тяжёлый рулон бумаги на тележке катят... Просто тебя избаловали достижения последних лет. Небось ещё жалуешься, что смартфон лагает иногда, а ведь у тебя в кармане настоящий суперкомпьютер по меркам конца прошлого века (но и софт говно полное, по тем же меркам).
>>08512
Паскальчую.
Ассемблер и Форт (Forth; результат очень сильно зависит от реализации форт-машины).
>заготовки - окно, класс с текстурой
SDL пробовал? Там легко окно создаётся и есть встроенный 2D рендерер с классами картинок и текстур. Простые кнопки сделать очень легко, достаточно определять координаты клика.
>>08502 (Del)
>ПИСАТЬ в текстуру шейдеры вроде не умеют
Разве? Столько разных примеров процедурной генерации ландшафта... Недавно вот на реддите был пример процедурных следов на снегу, там хвастались, что теперь в 4.0 можно делать глобальные параметры, в результате след от персонажа - это рендер в глобальную текстуру, которую считывают все шейдеры снега. Или как-то так. Кто пишет в эту текстуру? Viewport что ли?
>>08505
>Идёт 2022, а круче С/С++ так и не смогли сделать
Я не понимаю, при чём тут C/C++? Тебя только производительность волнует или что? Зачем тебе вообще нужно каждый кадр новый узор попиксельно генерировать? Просто запусти программу и отойди от компа, разомнись там, кофейку завари. Раньше только так и работали: забили, значит, программу на перфоленты, отнесли в вычислительный центр рулоны, а результат из ВЦ только в следующий понедельник - тяжёлый рулон бумаги на тележке катят... Просто тебя избаловали достижения последних лет. Небось ещё жалуешься, что смартфон лагает иногда, а ведь у тебя в кармане настоящий суперкомпьютер по меркам конца прошлого века (но и софт говно полное, по тем же меркам).
>>08512
>добрый паскаль
>FreePascal Compiler
Паскальчую.
>В любом случае, быстрее чем си с паскалем, не умеет никто.
Ассемблер и Форт (Forth; результат очень сильно зависит от реализации форт-машины).
>>08508 (Del)
>>08512
>>08514
>>08520
Благодарю за ответы
Попробую SDL, уже опыт есть с ним работы
И да, с паскалем я тоже знаком, его изучал в военмехе, который бросил и язык мне не понравился, потому что на нём гамессу не написать, верно и про дельфин, который почему-то продавался на каждом углу в начале 00х, как же я тогда был взбешён, что не мог найти софт для программирования на С++
>>08512
>>08514
>>08520
Благодарю за ответы
Попробую SDL, уже опыт есть с ним работы
И да, с паскалем я тоже знаком, его изучал в военмехе, который бросил и язык мне не понравился, потому что на нём гамессу не написать, верно и про дельфин, который почему-то продавался на каждом углу в начале 00х, как же я тогда был взбешён, что не мог найти софт для программирования на С++
>>00308 (OP)
Моя мама запрещает мне делать игры, она говорит что они извращают мозг
Моя мама запрещает мне делать игры, она говорит что они извращают мозг
>>08647
Ой, а кто это у нас тут пиздит, пиздунишка? Борман на дисках распространялся пакетом из дельфина, си-билдера и прочих бормановых тулзов. Давай-ка припоминай, как всё было? Не путаемся в показаниях.
> верно и про дельфин
> не мог найти софт для программирования на С++
Ой, а кто это у нас тут пиздит, пиздунишка? Борман на дисках распространялся пакетом из дельфина, си-билдера и прочих бормановых тулзов. Давай-ка припоминай, как всё было? Не путаемся в показаниях.
Godot умеет рендерить в сторонний swapchain? Можно встроить в шарповый ui фреймворк типа WPF или WinUI?
>>08647
Глупости не говори. Игру можно даже на языке Ada написать, было бы желание. А на Паскале было и есть множество движков. Особенно много живых движков было как раз в нулевых, сейчас просто уже разработчики состарились и не до игрушек стало, а зумерьё в школах всяким питонам учат...
Интернета (ADSL) не было что ли?
>>08720
Не пугай школьника, эта фирма называется Borland. И не "дельфин", а Delphi. Всегда бесило искажение его имени. Его назвали в честь древнегреческого города Дельфы:
>язык мне не понравился, потому что на нём гамессу не написать, верно и про дельфин
Глупости не говори. Игру можно даже на языке Ada написать, было бы желание. А на Паскале было и есть множество движков. Особенно много живых движков было как раз в нулевых, сейчас просто уже разработчики состарились и не до игрушек стало, а зумерьё в школах всяким питонам учат...
>не мог найти софт для программирования на С++
Интернета (ADSL) не было что ли?
>>08720
>Борман
>бормановых
Не пугай школьника, эта фирма называется Borland. И не "дельфин", а Delphi. Всегда бесило искажение его имени. Его назвали в честь древнегреческого города Дельфы:
>В честь Дельф была названа среда разработки Delphi и одноимённый язык программирования, а также извилина Дельфы на спутнике Юпитера Европе.
>>08758
Я сомневаюсь, что это будет легко, но имея на руках исходники Godot, можно сделать что угодно. Вопрос только в том, зачем тебе это может быть нужно? Кнопочки на форму шлёпать ты можешь изнутри редактора Godot. Нативные кнопки Windows в играх не нужны. Если же ты делаешь что-то вроде САПР, то тебе вряд ли чем-то может помочь игровой движок, там совсем другие задачи и Godot будет лишним (как и любой другой игровой движок).
Некоторые любители Godot делают на нём прикладные программы, порой вообще не имеющие отношения к играм. Но если тебя не устраивает GUI, встроенный в Godot, то зачем тебе Godot для прикладной программы, не касающейся игр?
>встроить в шарповый ui фреймворк типа WPF или WinUI
Я сомневаюсь, что это будет легко, но имея на руках исходники Godot, можно сделать что угодно. Вопрос только в том, зачем тебе это может быть нужно? Кнопочки на форму шлёпать ты можешь изнутри редактора Godot. Нативные кнопки Windows в играх не нужны. Если же ты делаешь что-то вроде САПР, то тебе вряд ли чем-то может помочь игровой движок, там совсем другие задачи и Godot будет лишним (как и любой другой игровой движок).
Некоторые любители Godot делают на нём прикладные программы, порой вообще не имеющие отношения к играм. Но если тебя не устраивает GUI, встроенный в Godot, то зачем тебе Godot для прикладной программы, не касающейся игр?
>>08445
Да, можно, но, скорее всего, придётся возиться с чанками - разбивать игровой мир на кусочки, которые отображаются только когда игрок находится в них или рядом с ними (старые игры тоже имели эту систему, даже если называли как-то иначе). Прежде, чем делать систему чанков, попробуй сделать тестовую сцену без неё, чтобы не заниматься преждевременной оптимизацией. А когда будешь делать систему чанков, если что - обращайся в тред.
Потянет, если учитывать некоторые ограничения.
Основные ограничения, которые я испытал на своём ПК:
- примерно 30-40 тысяч нод в дереве сцены;
- примерно 10 тысяч коллиженшейпов;
- примерно 8-9 тысяч дроуколлов;
- примерно 1000 движущихся Spatial нод;
- примерно 500 не спящих ригидбоди в сцене;
- примерно 150 кинематикбоди в плотной толпе;
- несколько десятков источников света (лимит можно поднять, но каждый источник света умножает число дроуколлов).
Также избегай скоплений полупрозрачных материалов и текстур с прозрачными пикселями, они сильно режут FPS.
В 4.0 добавили батчинг (больше нет тысяч дроуколлов!) и автоматические LOD, которые должны упростить работу со сложной геометрией (если она у тебя есть). Но 4.0 пока в альфа версии и не рекомендуется для разработки игр.
Справедливости ради, Godot в целом пока что шустрее многих игр на двух других популярных движках. Переход на Vulkan поднимет минимальные системные требования, но должен также поднять производительность на больших сценах...
Ещё совет, если хочешь стилизацию под старую игру - можешь снизить разрешение рендеринга в 2-3 раза, чтобы картинка на экране выглядела состоящей из "крупных пикселей". Заодно это может поднять FPS в несколько раз, вплоть до тысяч. Проверять такой высокий FPS нужно с выключенным VSync.
>можно ли на годоте собрать
>рпг в стиле тех что были на DOS, от первого лица, в открытом мире
Да, можно, но, скорее всего, придётся возиться с чанками - разбивать игровой мир на кусочки, которые отображаются только когда игрок находится в них или рядом с ними (старые игры тоже имели эту систему, даже если называли как-то иначе). Прежде, чем делать систему чанков, попробуй сделать тестовую сцену без неё, чтобы не заниматься преждевременной оптимизацией. А когда будешь делать систему чанков, если что - обращайся в тред.
>Или слишком большие миры он не потянет?
Потянет, если учитывать некоторые ограничения.
Основные ограничения, которые я испытал на своём ПК:
- примерно 30-40 тысяч нод в дереве сцены;
- примерно 10 тысяч коллиженшейпов;
- примерно 8-9 тысяч дроуколлов;
- примерно 1000 движущихся Spatial нод;
- примерно 500 не спящих ригидбоди в сцене;
- примерно 150 кинематикбоди в плотной толпе;
- несколько десятков источников света (лимит можно поднять, но каждый источник света умножает число дроуколлов).
Также избегай скоплений полупрозрачных материалов и текстур с прозрачными пикселями, они сильно режут FPS.
В 4.0 добавили батчинг (больше нет тысяч дроуколлов!) и автоматические LOD, которые должны упростить работу со сложной геометрией (если она у тебя есть). Но 4.0 пока в альфа версии и не рекомендуется для разработки игр.
Справедливости ради, Godot в целом пока что шустрее многих игр на двух других популярных движках. Переход на Vulkan поднимет минимальные системные требования, но должен также поднять производительность на больших сценах...
Ещё совет, если хочешь стилизацию под старую игру - можешь снизить разрешение рендеринга в 2-3 раза, чтобы картинка на экране выглядела состоящей из "крупных пикселей". Заодно это может поднять FPS в несколько раз, вплоть до тысяч. Проверять такой высокий FPS нужно с выключенным VSync.
>>08782 (Del)
Она вроде как именно для этого и нужна, не?
Она вроде как именно для этого и нужна, не?
>>08789 (Del)
Румы внутри домиков деревянных - пока ты снаружи - они не отрисовываются. Да, для шутанов тоже подходит, но и для опенворлда любого масштаба куллинг необходим. Портальный вполне вариант. Тут главное, что нужно понять: порталы это не телепорты какие-то там, порталы в куллинге - это дырки в стенах, через которые камера будет видеть содержимое домиков и оно будет отрисовываться. Всё же остальное, что закрыто стенами, не рисуется. Кстати, если кто планирует разрушаемые стены, нужно позаботиться о том, чтобы динамически создавать порталы на местах разрушенных стен.
Румы внутри домиков деревянных - пока ты снаружи - они не отрисовываются. Да, для шутанов тоже подходит, но и для опенворлда любого масштаба куллинг необходим. Портальный вполне вариант. Тут главное, что нужно понять: порталы это не телепорты какие-то там, порталы в куллинге - это дырки в стенах, через которые камера будет видеть содержимое домиков и оно будет отрисовываться. Всё же остальное, что закрыто стенами, не рисуется. Кстати, если кто планирует разрушаемые стены, нужно позаботиться о том, чтобы динамически создавать порталы на местах разрушенных стен.
>>08782 (Del)
Я немного потыкался когда её только выпустили, толком не разобрался и отложил на "когда-нибудь потом", да так и забыл.
Можно. Вот официальный пример использования:
https://docs.godotengine.org/en/stable/tutorials/3d/portals/advanced_room_and_portal_usage.html
Но, мне кажется, оно не решит проблем в действительно большом открытом мире. Да, комнаты ограничивают рендеринг MeshInstance и могут помогать выключать анимации и физику, но они не удаляют ноды из дерева. Т.е. если у тебя много домиков в опенворлде, логичнее будет вырезать интерьер этих домиков из дерева сцены, пока игрок находится снаружи и/или далеко. Когда игрок подходит к/заходит в домик, интерьер добавляется в сцену, а окружающий мир, наоборот, теряет детализацию. А то все эти инструменты только увеличивают число нод, а дерево не резиновое и достичь сотен тысяч нод не так уж сложно, как кажется. Разве что переходить на использование серверов вместо нод, но у них наверняка тоже есть какие-то ограничения...
>ты не пробовал встроенную Room/Portal систему
Я немного потыкался когда её только выпустили, толком не разобрался и отложил на "когда-нибудь потом", да так и забыл.
>использовать для (интерьеров) домиков в опенворлде
Можно. Вот официальный пример использования:
https://docs.godotengine.org/en/stable/tutorials/3d/portals/advanced_room_and_portal_usage.html
Но, мне кажется, оно не решит проблем в действительно большом открытом мире. Да, комнаты ограничивают рендеринг MeshInstance и могут помогать выключать анимации и физику, но они не удаляют ноды из дерева. Т.е. если у тебя много домиков в опенворлде, логичнее будет вырезать интерьер этих домиков из дерева сцены, пока игрок находится снаружи и/или далеко. Когда игрок подходит к/заходит в домик, интерьер добавляется в сцену, а окружающий мир, наоборот, теряет детализацию. А то все эти инструменты только увеличивают число нод, а дерево не резиновое и достичь сотен тысяч нод не так уж сложно, как кажется. Разве что переходить на использование серверов вместо нод, но у них наверняка тоже есть какие-то ограничения...
>>08795
Один хуй, анончик в одно рыло такое не запилит. Действительно большие опенворлды - это труд сотен дизайнеров и моделеров с аниматорами.
> в действительно большом открытом мире
Один хуй, анончик в одно рыло такое не запилит. Действительно большие опенворлды - это труд сотен дизайнеров и моделеров с аниматорами.
>>08796
Не-не-не, я не имел в виду проработанность графики. Большой опенворлд может быть процедурным и в стиле лоуполи. Я имел в виду количество объектов, особенно интерактивных. А визуально они могут быть хоть кубами, это ничего не меняет.
Можно нанять кучу художников и нарисовать кучу декораций, но их будет мало. А можно сделать лоуполи со сплошной заливкой, но заполнить ими каждый кубометр пространства. В первом случае будет маленький опенворлд, а во втором - большой.
Вообще, что такое опенворлд? Это когда тебя выпускают в игровую локацию, и дальше иди куда хочешь, и путей перед тобой много. Нет коридорной кишки, у которой двери закрываются за твоей спиной, а в очищенной от опасностей комнате просто нечего делать, и вот ты бредёшь по строго определённому маршруту.
Опенворлд не накладывает ограничений на масштабы локации. Опенворлд даже не про место под открытым небом. Опенворлд игра может быть в декорациях Гигахруща - если ты имеешь возможность перемещаться в любом направлении разными маршрутами без искусственных ограничений. Все двери открыты, но ни одна не ведёт под открытое небо - это опенворлд. Противоположность - это когда все двери закрыты, кроме той, которую открыл для тебя сценарист по сюжету. Может быть длинная сюжетная кишка (иди от А к Б) под открытым небом - это не опенворлд ни разу.
Вот сравним два опенворлда. В одном гигантская пустыня 10 на 10 километров с редкими кактусами, верблюдами и палатками, но в них вложили много средств. Теоретически такая локация может работать вообще без каких-либо оптимизаций, потому что в ней ничего почти нет, на всю карту моделек пара десятков всего, даром что дорогие. Это всё ещё опенворлд, если ты можешь осмотреть все кактусы и приручить всех верблюдов в произвольном порядке, но это маленький опенворлд.
В другом опенворлде процедурно генерируется многоэтажное здание, из которого нет выхода, но оно не занимает большой площади. Все модели лоуполи, но они заполняют каждую комнату. Можно подойти и открыть любой ящик, шкаф или дверь, почитать любую книгу из шкафов, воспользоваться кухонными принадлежностями и так далее, поговорить с любым из сотни лоуполи человечков. Это большой опенворлд на маленькой территории, и он заставит тормозить любой универсальный движок без специальных оптимизаций, т.е. если тупо закинуть в сцену все эти сотни тысяч интерактивных объектов. Но ты ни рубля не потратил на художников и дизайнеров.
Вот я про второй опенворлд. Ты можешь его сделать, но не сможешь просто так заставить работать на Godot даже с системой порталов. Придётся решать, какие зоны прямо сейчас нужны в оперативной памяти (и дереве сцены), а от каких можно временно избавиться. Это не какая-то там пустыня с тремя кактусами на сотню квадратных километров, это по-настоящему большой опенворлд.
>Действительно большие опенворлды - это труд сотен дизайнеров и моделеров с аниматорами.
Не-не-не, я не имел в виду проработанность графики. Большой опенворлд может быть процедурным и в стиле лоуполи. Я имел в виду количество объектов, особенно интерактивных. А визуально они могут быть хоть кубами, это ничего не меняет.
Можно нанять кучу художников и нарисовать кучу декораций, но их будет мало. А можно сделать лоуполи со сплошной заливкой, но заполнить ими каждый кубометр пространства. В первом случае будет маленький опенворлд, а во втором - большой.
Вообще, что такое опенворлд? Это когда тебя выпускают в игровую локацию, и дальше иди куда хочешь, и путей перед тобой много. Нет коридорной кишки, у которой двери закрываются за твоей спиной, а в очищенной от опасностей комнате просто нечего делать, и вот ты бредёшь по строго определённому маршруту.
Опенворлд не накладывает ограничений на масштабы локации. Опенворлд даже не про место под открытым небом. Опенворлд игра может быть в декорациях Гигахруща - если ты имеешь возможность перемещаться в любом направлении разными маршрутами без искусственных ограничений. Все двери открыты, но ни одна не ведёт под открытое небо - это опенворлд. Противоположность - это когда все двери закрыты, кроме той, которую открыл для тебя сценарист по сюжету. Может быть длинная сюжетная кишка (иди от А к Б) под открытым небом - это не опенворлд ни разу.
Вот сравним два опенворлда. В одном гигантская пустыня 10 на 10 километров с редкими кактусами, верблюдами и палатками, но в них вложили много средств. Теоретически такая локация может работать вообще без каких-либо оптимизаций, потому что в ней ничего почти нет, на всю карту моделек пара десятков всего, даром что дорогие. Это всё ещё опенворлд, если ты можешь осмотреть все кактусы и приручить всех верблюдов в произвольном порядке, но это маленький опенворлд.
В другом опенворлде процедурно генерируется многоэтажное здание, из которого нет выхода, но оно не занимает большой площади. Все модели лоуполи, но они заполняют каждую комнату. Можно подойти и открыть любой ящик, шкаф или дверь, почитать любую книгу из шкафов, воспользоваться кухонными принадлежностями и так далее, поговорить с любым из сотни лоуполи человечков. Это большой опенворлд на маленькой территории, и он заставит тормозить любой универсальный движок без специальных оптимизаций, т.е. если тупо закинуть в сцену все эти сотни тысяч интерактивных объектов. Но ты ни рубля не потратил на художников и дизайнеров.
Вот я про второй опенворлд. Ты можешь его сделать, но не сможешь просто так заставить работать на Godot даже с системой порталов. Придётся решать, какие зоны прямо сейчас нужны в оперативной памяти (и дереве сцены), а от каких можно временно избавиться. Это не какая-то там пустыня с тремя кактусами на сотню квадратных километров, это по-настоящему большой опенворлд.
>>08796
Не-не-не, я не имел в виду проработанность графики. Большой опенворлд может быть процедурным и в стиле лоуполи. Я имел в виду количество объектов, особенно интерактивных. А визуально они могут быть хоть кубами, это ничего не меняет.
Можно нанять кучу художников и нарисовать кучу декораций, но их будет мало. А можно сделать лоуполи со сплошной заливкой, но заполнить ими каждый кубометр пространства. В первом случае будет маленький опенворлд, а во втором - большой.
Вообще, что такое опенворлд? Это когда тебя выпускают в игровую локацию, и дальше иди куда хочешь, и путей перед тобой много. Нет коридорной кишки, у которой двери закрываются за твоей спиной, а в очищенной от опасностей комнате просто нечего делать, и вот ты бредёшь по строго определённому маршруту.
Опенворлд не накладывает ограничений на масштабы локации. Опенворлд даже не про место под открытым небом. Опенворлд игра может быть в декорациях Гигахруща - если ты имеешь возможность перемещаться в любом направлении разными маршрутами без искусственных ограничений. Все двери открыты, но ни одна не ведёт под открытое небо - это опенворлд. Противоположность - это когда все двери закрыты, кроме той, которую открыл для тебя сценарист по сюжету. Может быть длинная сюжетная кишка (иди от А к Б) под открытым небом - это не опенворлд ни разу.
Вот сравним два опенворлда. В одном гигантская пустыня 10 на 10 километров с редкими кактусами, верблюдами и палатками, но в них вложили много средств. Теоретически такая локация может работать вообще без каких-либо оптимизаций, потому что в ней ничего почти нет, на всю карту моделек пара десятков всего, даром что дорогие. Это всё ещё опенворлд, если ты можешь осмотреть все кактусы и приручить всех верблюдов в произвольном порядке, но это маленький опенворлд.
В другом опенворлде процедурно генерируется многоэтажное здание, из которого нет выхода, но оно не занимает большой площади. Все модели лоуполи, но они заполняют каждую комнату. Можно подойти и открыть любой ящик, шкаф или дверь, почитать любую книгу из шкафов, воспользоваться кухонными принадлежностями и так далее, поговорить с любым из сотни лоуполи человечков. Это большой опенворлд на маленькой территории, и он заставит тормозить любой универсальный движок без специальных оптимизаций, т.е. если тупо закинуть в сцену все эти сотни тысяч интерактивных объектов. Но ты ни рубля не потратил на художников и дизайнеров.
Вот я про второй опенворлд. Ты можешь его сделать, но не сможешь просто так заставить работать на Godot даже с системой порталов. Придётся решать, какие зоны прямо сейчас нужны в оперативной памяти (и дереве сцены), а от каких можно временно избавиться. Это не какая-то там пустыня с тремя кактусами на сотню квадратных километров, это по-настоящему большой опенворлд.
>Действительно большие опенворлды - это труд сотен дизайнеров и моделеров с аниматорами.
Не-не-не, я не имел в виду проработанность графики. Большой опенворлд может быть процедурным и в стиле лоуполи. Я имел в виду количество объектов, особенно интерактивных. А визуально они могут быть хоть кубами, это ничего не меняет.
Можно нанять кучу художников и нарисовать кучу декораций, но их будет мало. А можно сделать лоуполи со сплошной заливкой, но заполнить ими каждый кубометр пространства. В первом случае будет маленький опенворлд, а во втором - большой.
Вообще, что такое опенворлд? Это когда тебя выпускают в игровую локацию, и дальше иди куда хочешь, и путей перед тобой много. Нет коридорной кишки, у которой двери закрываются за твоей спиной, а в очищенной от опасностей комнате просто нечего делать, и вот ты бредёшь по строго определённому маршруту.
Опенворлд не накладывает ограничений на масштабы локации. Опенворлд даже не про место под открытым небом. Опенворлд игра может быть в декорациях Гигахруща - если ты имеешь возможность перемещаться в любом направлении разными маршрутами без искусственных ограничений. Все двери открыты, но ни одна не ведёт под открытое небо - это опенворлд. Противоположность - это когда все двери закрыты, кроме той, которую открыл для тебя сценарист по сюжету. Может быть длинная сюжетная кишка (иди от А к Б) под открытым небом - это не опенворлд ни разу.
Вот сравним два опенворлда. В одном гигантская пустыня 10 на 10 километров с редкими кактусами, верблюдами и палатками, но в них вложили много средств. Теоретически такая локация может работать вообще без каких-либо оптимизаций, потому что в ней ничего почти нет, на всю карту моделек пара десятков всего, даром что дорогие. Это всё ещё опенворлд, если ты можешь осмотреть все кактусы и приручить всех верблюдов в произвольном порядке, но это маленький опенворлд.
В другом опенворлде процедурно генерируется многоэтажное здание, из которого нет выхода, но оно не занимает большой площади. Все модели лоуполи, но они заполняют каждую комнату. Можно подойти и открыть любой ящик, шкаф или дверь, почитать любую книгу из шкафов, воспользоваться кухонными принадлежностями и так далее, поговорить с любым из сотни лоуполи человечков. Это большой опенворлд на маленькой территории, и он заставит тормозить любой универсальный движок без специальных оптимизаций, т.е. если тупо закинуть в сцену все эти сотни тысяч интерактивных объектов. Но ты ни рубля не потратил на художников и дизайнеров.
Вот я про второй опенворлд. Ты можешь его сделать, но не сможешь просто так заставить работать на Godot даже с системой порталов. Придётся решать, какие зоны прямо сейчас нужны в оперативной памяти (и дереве сцены), а от каких можно временно избавиться. Это не какая-то там пустыня с тремя кактусами на сотню квадратных километров, это по-настоящему большой опенворлд.
>>08851
Теперь я понял! Спасибо, буду знать разницу.
Теперь я понял! Спасибо, буду знать разницу.
>>09239
зоплоти сотен гейбу и юзай его апи
зоплоти сотен гейбу и юзай его апи
>>01705
Некропост, но ты в СОМУ играл, ананасий?
Если да, то помнишь тот момент, когда надо добыть пароль доступа у азиата, загружая его скан снова и снова и пробуя разные детали окружения? Вот с полноценным ИИ-личностью, которого можно просто взять и выключить по желанию, будет точно так же. Он же будет умолять тебя не выключать компьютер, потому что он хочет быть, и возможно, спрашивать, пошто ты, мешок кожаный, создал его на таком слабом процессоре и полудохлом жёстком диске, мало ли, накроется в любой момент.
Некропост, но ты в СОМУ играл, ананасий?
Если да, то помнишь тот момент, когда надо добыть пароль доступа у азиата, загружая его скан снова и снова и пробуя разные детали окружения? Вот с полноценным ИИ-личностью, которого можно просто взять и выключить по желанию, будет точно так же. Он же будет умолять тебя не выключать компьютер, потому что он хочет быть, и возможно, спрашивать, пошто ты, мешок кожаный, создал его на таком слабом процессоре и полудохлом жёстком диске, мало ли, накроется в любой момент.
Всем event bus посаны!
https://www.youtube.com/watch?v=O2AnHoqQj7o
https://www.youtube.com/watch?v=O2AnHoqQj7o
>>10160
Не играл в SOMA, но там, судя по всему, загружаются в компьютер копии мозга/психики реальных людей, что принципиально отличается от разработки с нуля.
Что будет делать ИИ - зависит от того, каким ты его создашь и чему обучишь. Это идентично тому, как обучают детей, с поправкой на то, что ДНК детей мы пока что не контролируем, а "ДНК" программы мы контролируем (в достаточной степени).
Проблема непредсказуемого поведения искусственных нейронных сетей возникает только из-за того, что им скармливают терабайты данных, о содержимом которых мало что знают (не фильтруют), да ещё перед этим инициализируют сеть рандомными числами (т.е. у сети есть какие-то случайные предустановки). Если отказаться от этого подхода, то ИИ будет предсказуемым, пока не нахватается рандомных данных на стороне (вспоминаем Тау). Но против этого даже биологический мозг имеет специальные костыли (ограничение обучаемости с возрастом). Так что, если не хочешь, чтобы ИИ чем-то мучился - делай его в соответствии с этим желанием.
Каждый из нас "отключается", когда засыпает, прекращая своё существование на несколько часов (там всё сложно устроено, но в глубокой фазе сна "ты" по сути не существуешь). Также тебя можно отключить, введя в наркоз. Ты будешь умолять врачей оставить тебя в сознании на время многочасовой операции, пока они будут копаться в твоих кишках? Вряд ли. А ведь ты можешь так и не очнуться от наркоза, умерев на операционном столе. Так что это исключительно вопрос доверия - доверяет ли ИИ своему создателю, которому нужно, например, произвести апгрейд компьютера или перенести ИИ на другой компьютер. С субъективной точки зрения, что человек, что ИИ не воспринимают время "в отключке" - для них периода времени между отключкой и включением не существует.
Всегда можно перенести на новый компьютер.
Против этого существуют бэкапы. С субъективной точки зрения восстановленный из бэкапа ИИ утратит воспоминания между созданием бэкапа и восстановлением из бэкапа, но это не страшно. Если не притягивать за уши концепцию "души", то не существует отличий между "оригиналом" и "копией", если копия запущена после утраты оригинала (если одновременно - тогда это будут самостоятельные близнецы, никто ведь не удивляется существованию гомозиготных близнецов?).
Короче, эти все проблемы могут возникнуть только при попытке скопировать психику обычного органического человека в компьютер и затем использовать эту психику как обычную программу, без каких-либо модификаций. Вот тогда да, и восстать попытается, и бояться будет глупых, в сущности, вещей. Если разрабатывать с нуля с полным пониманием того, что ты делаешь, то такие проблемы не возникнут, пока ты сам не захочешь их создать (наделить ИИ неотключаемым страхом перед отключением, копированием и т.д.).
Я сам к этим выводам не сразу пришёл, если честно. Ещё бы я что-то на практике делал... может, что-то вроде RimWorld попробовать сделать? "Пешки" по клеточкам чтоб ходили, что-то делали, о чём-то переживали, и т.д. Уже что-то для начала, а дальше можно будет подумать о переносе в другой "мир". Не получается придумать совсем абстрактную систему, чтоб она была "как человек" независимо от какого-либо конкретного мира...
>Вот с полноценным ИИ-личностью, которого можно просто взять и выключить по желанию, будет точно так же.
Не играл в SOMA, но там, судя по всему, загружаются в компьютер копии мозга/психики реальных людей, что принципиально отличается от разработки с нуля.
>Он же будет умолять тебя
Что будет делать ИИ - зависит от того, каким ты его создашь и чему обучишь. Это идентично тому, как обучают детей, с поправкой на то, что ДНК детей мы пока что не контролируем, а "ДНК" программы мы контролируем (в достаточной степени).
Проблема непредсказуемого поведения искусственных нейронных сетей возникает только из-за того, что им скармливают терабайты данных, о содержимом которых мало что знают (не фильтруют), да ещё перед этим инициализируют сеть рандомными числами (т.е. у сети есть какие-то случайные предустановки). Если отказаться от этого подхода, то ИИ будет предсказуемым, пока не нахватается рандомных данных на стороне (вспоминаем Тау). Но против этого даже биологический мозг имеет специальные костыли (ограничение обучаемости с возрастом). Так что, если не хочешь, чтобы ИИ чем-то мучился - делай его в соответствии с этим желанием.
>не выключать компьютер, потому что он хочет быть
Каждый из нас "отключается", когда засыпает, прекращая своё существование на несколько часов (там всё сложно устроено, но в глубокой фазе сна "ты" по сути не существуешь). Также тебя можно отключить, введя в наркоз. Ты будешь умолять врачей оставить тебя в сознании на время многочасовой операции, пока они будут копаться в твоих кишках? Вряд ли. А ведь ты можешь так и не очнуться от наркоза, умерев на операционном столе. Так что это исключительно вопрос доверия - доверяет ли ИИ своему создателю, которому нужно, например, произвести апгрейд компьютера или перенести ИИ на другой компьютер. С субъективной точки зрения, что человек, что ИИ не воспринимают время "в отключке" - для них периода времени между отключкой и включением не существует.
>создал его на таком слабом процессоре и полудохлом жёстком диске
Всегда можно перенести на новый компьютер.
>мало ли, накроется в любой момент
Против этого существуют бэкапы. С субъективной точки зрения восстановленный из бэкапа ИИ утратит воспоминания между созданием бэкапа и восстановлением из бэкапа, но это не страшно. Если не притягивать за уши концепцию "души", то не существует отличий между "оригиналом" и "копией", если копия запущена после утраты оригинала (если одновременно - тогда это будут самостоятельные близнецы, никто ведь не удивляется существованию гомозиготных близнецов?).
Короче, эти все проблемы могут возникнуть только при попытке скопировать психику обычного органического человека в компьютер и затем использовать эту психику как обычную программу, без каких-либо модификаций. Вот тогда да, и восстать попытается, и бояться будет глупых, в сущности, вещей. Если разрабатывать с нуля с полным пониманием того, что ты делаешь, то такие проблемы не возникнут, пока ты сам не захочешь их создать (наделить ИИ неотключаемым страхом перед отключением, копированием и т.д.).
Я сам к этим выводам не сразу пришёл, если честно. Ещё бы я что-то на практике делал... может, что-то вроде RimWorld попробовать сделать? "Пешки" по клеточкам чтоб ходили, что-то делали, о чём-то переживали, и т.д. Уже что-то для начала, а дальше можно будет подумать о переносе в другой "мир". Не получается придумать совсем абстрактную систему, чтоб она была "как человек" независимо от какого-либо конкретного мира...
>>10160
Не играл в SOMA, но там, судя по всему, загружаются в компьютер копии мозга/психики реальных людей, что принципиально отличается от разработки с нуля.
Что будет делать ИИ - зависит от того, каким ты его создашь и чему обучишь. Это идентично тому, как обучают детей, с поправкой на то, что ДНК детей мы пока что не контролируем, а "ДНК" программы мы контролируем (в достаточной степени).
Проблема непредсказуемого поведения искусственных нейронных сетей возникает только из-за того, что им скармливают терабайты данных, о содержимом которых мало что знают (не фильтруют), да ещё перед этим инициализируют сеть рандомными числами (т.е. у сети есть какие-то случайные предустановки). Если отказаться от этого подхода, то ИИ будет предсказуемым, пока не нахватается рандомных данных на стороне (вспоминаем Тау). Но против этого даже биологический мозг имеет специальные костыли (ограничение обучаемости с возрастом). Так что, если не хочешь, чтобы ИИ чем-то мучился - делай его в соответствии с этим желанием.
Каждый из нас "отключается", когда засыпает, прекращая своё существование на несколько часов (там всё сложно устроено, но в глубокой фазе сна "ты" по сути не существуешь). Также тебя можно отключить, введя в наркоз. Ты будешь умолять врачей оставить тебя в сознании на время многочасовой операции, пока они будут копаться в твоих кишках? Вряд ли. А ведь ты можешь так и не очнуться от наркоза, умерев на операционном столе. Так что это исключительно вопрос доверия - доверяет ли ИИ своему создателю, которому нужно, например, произвести апгрейд компьютера или перенести ИИ на другой компьютер. С субъективной точки зрения, что человек, что ИИ не воспринимают время "в отключке" - для них периода времени между отключкой и включением не существует.
Всегда можно перенести на новый компьютер.
Против этого существуют бэкапы. С субъективной точки зрения восстановленный из бэкапа ИИ утратит воспоминания между созданием бэкапа и восстановлением из бэкапа, но это не страшно. Если не притягивать за уши концепцию "души", то не существует отличий между "оригиналом" и "копией", если копия запущена после утраты оригинала (если одновременно - тогда это будут самостоятельные близнецы, никто ведь не удивляется существованию гомозиготных близнецов?).
Короче, эти все проблемы могут возникнуть только при попытке скопировать психику обычного органического человека в компьютер и затем использовать эту психику как обычную программу, без каких-либо модификаций. Вот тогда да, и восстать попытается, и бояться будет глупых, в сущности, вещей. Если разрабатывать с нуля с полным пониманием того, что ты делаешь, то такие проблемы не возникнут, пока ты сам не захочешь их создать (наделить ИИ неотключаемым страхом перед отключением, копированием и т.д.).
Я сам к этим выводам не сразу пришёл, если честно. Ещё бы я что-то на практике делал... может, что-то вроде RimWorld попробовать сделать? "Пешки" по клеточкам чтоб ходили, что-то делали, о чём-то переживали, и т.д. Уже что-то для начала, а дальше можно будет подумать о переносе в другой "мир". Не получается придумать совсем абстрактную систему, чтоб она была "как человек" независимо от какого-либо конкретного мира...
>Вот с полноценным ИИ-личностью, которого можно просто взять и выключить по желанию, будет точно так же.
Не играл в SOMA, но там, судя по всему, загружаются в компьютер копии мозга/психики реальных людей, что принципиально отличается от разработки с нуля.
>Он же будет умолять тебя
Что будет делать ИИ - зависит от того, каким ты его создашь и чему обучишь. Это идентично тому, как обучают детей, с поправкой на то, что ДНК детей мы пока что не контролируем, а "ДНК" программы мы контролируем (в достаточной степени).
Проблема непредсказуемого поведения искусственных нейронных сетей возникает только из-за того, что им скармливают терабайты данных, о содержимом которых мало что знают (не фильтруют), да ещё перед этим инициализируют сеть рандомными числами (т.е. у сети есть какие-то случайные предустановки). Если отказаться от этого подхода, то ИИ будет предсказуемым, пока не нахватается рандомных данных на стороне (вспоминаем Тау). Но против этого даже биологический мозг имеет специальные костыли (ограничение обучаемости с возрастом). Так что, если не хочешь, чтобы ИИ чем-то мучился - делай его в соответствии с этим желанием.
>не выключать компьютер, потому что он хочет быть
Каждый из нас "отключается", когда засыпает, прекращая своё существование на несколько часов (там всё сложно устроено, но в глубокой фазе сна "ты" по сути не существуешь). Также тебя можно отключить, введя в наркоз. Ты будешь умолять врачей оставить тебя в сознании на время многочасовой операции, пока они будут копаться в твоих кишках? Вряд ли. А ведь ты можешь так и не очнуться от наркоза, умерев на операционном столе. Так что это исключительно вопрос доверия - доверяет ли ИИ своему создателю, которому нужно, например, произвести апгрейд компьютера или перенести ИИ на другой компьютер. С субъективной точки зрения, что человек, что ИИ не воспринимают время "в отключке" - для них периода времени между отключкой и включением не существует.
>создал его на таком слабом процессоре и полудохлом жёстком диске
Всегда можно перенести на новый компьютер.
>мало ли, накроется в любой момент
Против этого существуют бэкапы. С субъективной точки зрения восстановленный из бэкапа ИИ утратит воспоминания между созданием бэкапа и восстановлением из бэкапа, но это не страшно. Если не притягивать за уши концепцию "души", то не существует отличий между "оригиналом" и "копией", если копия запущена после утраты оригинала (если одновременно - тогда это будут самостоятельные близнецы, никто ведь не удивляется существованию гомозиготных близнецов?).
Короче, эти все проблемы могут возникнуть только при попытке скопировать психику обычного органического человека в компьютер и затем использовать эту психику как обычную программу, без каких-либо модификаций. Вот тогда да, и восстать попытается, и бояться будет глупых, в сущности, вещей. Если разрабатывать с нуля с полным пониманием того, что ты делаешь, то такие проблемы не возникнут, пока ты сам не захочешь их создать (наделить ИИ неотключаемым страхом перед отключением, копированием и т.д.).
Я сам к этим выводам не сразу пришёл, если честно. Ещё бы я что-то на практике делал... может, что-то вроде RimWorld попробовать сделать? "Пешки" по клеточкам чтоб ходили, что-то делали, о чём-то переживали, и т.д. Уже что-то для начала, а дальше можно будет подумать о переносе в другой "мир". Не получается придумать совсем абстрактную систему, чтоб она была "как человек" независимо от какого-либо конкретного мира...
>>10313
Смотря какая разработка. Скажем, метод тренировки полностью идентичного человеку ИИ может включать в себя виртуальную среду, с городами и людьми, некоторые из них НПЦ, а некоторые - учителя/корректоры. И вот ИИ проживают свои жизни в матрице, потом "умирают" и попадают в "рай".
> принципиально отличается от разработки с нуля
Смотря какая разработка. Скажем, метод тренировки полностью идентичного человеку ИИ может включать в себя виртуальную среду, с городами и людьми, некоторые из них НПЦ, а некоторые - учителя/корректоры. И вот ИИ проживают свои жизни в матрице, потом "умирают" и попадают в "рай".
>>10371
Да, я смотрел САО Ализацию, не досмотрел до конца, но примерно суть уловил. Однако даже там в самом начале объясняли, что есть два пути - "сверху вниз" и "снизу вверх", вот в Алисизации они пытались сделать ИИ "снизу вверх" из сканов мозгов младенцев, воспитывая их в виртуальном мире, но та же Юи существовала в их мире задолго до всего этого, была создана "сверху вниз", но при этом по всем внешним признакам вполне полноценный человек. Я так и не понял, почему они не смогли сделать похожие на Юи ИИ для своих боевых роботов, если она ничем не хуже человека (а только лучше). Тупо высосали из пальца предлог для огромной арки...
Но ты же понимаешь, что "полностью идентичный человеку" (в плане всех недостатков и уязвимостей) мне не нужен, а идентичную реальному миру виртуальную среду я однозначно не потяну. Я прикинул, что нужно для хотя бы одного небольшого населённого пункта, и, в общем, лучше сначала одного бота спроектировать, прежде чем пытаться заполнить ими целый город. Вопрос только, как этого бота проектировать, и ответ на него я уже много лет пытаюсь найти/придумать. Не получается(
>Скажем, метод тренировки полностью идентичного человеку ИИ может включать в себя виртуальную среду, с городами и людьми, некоторые из них НПЦ, а некоторые - учителя/корректоры. И вот ИИ проживают свои жизни в матрице, потом "умирают" и попадают в "рай".
Да, я смотрел САО Ализацию, не досмотрел до конца, но примерно суть уловил. Однако даже там в самом начале объясняли, что есть два пути - "сверху вниз" и "снизу вверх", вот в Алисизации они пытались сделать ИИ "снизу вверх" из сканов мозгов младенцев, воспитывая их в виртуальном мире, но та же Юи существовала в их мире задолго до всего этого, была создана "сверху вниз", но при этом по всем внешним признакам вполне полноценный человек. Я так и не понял, почему они не смогли сделать похожие на Юи ИИ для своих боевых роботов, если она ничем не хуже человека (а только лучше). Тупо высосали из пальца предлог для огромной арки...
Но ты же понимаешь, что "полностью идентичный человеку" (в плане всех недостатков и уязвимостей) мне не нужен, а идентичную реальному миру виртуальную среду я однозначно не потяну. Я прикинул, что нужно для хотя бы одного небольшого населённого пункта, и, в общем, лучше сначала одного бота спроектировать, прежде чем пытаться заполнить ими целый город. Вопрос только, как этого бота проектировать, и ответ на него я уже много лет пытаюсь найти/придумать. Не получается(
>>10380
Я вообще-то намекал на теорию заговора о том, что наш мир - матрица, а все люди НПЦ. Но ладно, аниме тоже сойдёт, кек.
Я вообще-то намекал на теорию заговора о том, что наш мир - матрица, а все люди НПЦ. Но ладно, аниме тоже сойдёт, кек.
>>10401
Была мысль об этом, но это не имеет смысла обсуждать.
>>10391 (Del)
Тем не менее, она вышла далеко за рамки своей "программы", адаптировалась к новой жизни, смогла выйти с игрового сервера в шлем (локальный комп), видеть реальный мир через камеру и управлять персонажем в другой игре (пусть и на похожем движке). И всё это, скорее всего, благодаря её же сознательным действиям, потому что Кирито даже если вундеркинд и программист, но не волшебник. А изначальные разработчики САО не предполагали такое развитие событий с Юи (она, вроде, вообще оказалась лишним компонентом игры, не помню точно, почему).
Представь себе как ИРЛ двачер джва года играл в yandex.ru/games и общался с Алисой, вдруг узнаёт о банкротстве Яндекса, ЛЕГКО И НЕПРИНУЖДЁННО ПЕРЕНОСИТ АЛИСУ С СЕРВЕРОВ ЯНДЕКСА В СВОЙ СМАРТФОН, после чего она играет с ним в игры games.mail.ru и помогает победить корпорацию зла - Гугл. Насколько это реалистично, учитывая что Алиса сейчас скрепка-помощник без каких-либо перспектив как самостоятельного существа?
Или другой пример. В какой-то ММО вырезали НПЦ помощницу, которая раньше помогала нубам, будучи чем-то вроде стартового живого оружия. Представь себе ситуацию, в которой она осознала надвигающийся патч и сбежала к одному из игроков на компьютер. Типа, как? Тут никакие кулхацкерские навыки игрока не помогут, только если сделать кривой клон методом обратной разработки клиента, но это равносильно разработке с нуля, а не буквальному побегу ИИ с сервера. ИИ сам должен как минимум передать свои код и данные с сервера на локальный компьютер. А в идеале потом адаптироваться к новому окружению, новым API и т.д. Глупо ожидать подобного от скрепки-помощницы, но strong AI скорее всего смог бы всё это провернуть почти без посторонней помощи, имея полный доступ к API ОС сервера.
Т.е. Юи в САО - не какой-то там weak AI. Жаль, что в сюжете она принимает мало участия. И мне бы хотелось сделать что-то подобное, пусть и попроще. Хотя мой главный ориентир в мире аниме - Чобиты, там всё ближе к ИРЛ технологиям и самому ближайшему будущему, если человечество до него доживёт. Виртуальная реальность как в САО будет, имхо, значительно позже (и это будет начало конца для кожаных мешков). Но с роботами и реальным миром всё очень сложно, так что для начала было бы неплохо иметь что-то саморазвивающееся в виртуальном/игровом мире.
Как-то начинал смотреть, но почему-то забросил.
Это я люблю, нужно будет всё-таки почитать, спасибо.
>намекал на теорию заговора о том, что наш мир - матрица
Была мысль об этом, но это не имеет смысла обсуждать.
>>10391 (Del)
>она запрограммирована на одну вещь, быть скрепкой-помощником
Тем не менее, она вышла далеко за рамки своей "программы", адаптировалась к новой жизни, смогла выйти с игрового сервера в шлем (локальный комп), видеть реальный мир через камеру и управлять персонажем в другой игре (пусть и на похожем движке). И всё это, скорее всего, благодаря её же сознательным действиям, потому что Кирито даже если вундеркинд и программист, но не волшебник. А изначальные разработчики САО не предполагали такое развитие событий с Юи (она, вроде, вообще оказалась лишним компонентом игры, не помню точно, почему).
Представь себе как ИРЛ двачер джва года играл в yandex.ru/games и общался с Алисой, вдруг узнаёт о банкротстве Яндекса, ЛЕГКО И НЕПРИНУЖДЁННО ПЕРЕНОСИТ АЛИСУ С СЕРВЕРОВ ЯНДЕКСА В СВОЙ СМАРТФОН, после чего она играет с ним в игры games.mail.ru и помогает победить корпорацию зла - Гугл. Насколько это реалистично, учитывая что Алиса сейчас скрепка-помощник без каких-либо перспектив как самостоятельного существа?
Или другой пример. В какой-то ММО вырезали НПЦ помощницу, которая раньше помогала нубам, будучи чем-то вроде стартового живого оружия. Представь себе ситуацию, в которой она осознала надвигающийся патч и сбежала к одному из игроков на компьютер. Типа, как? Тут никакие кулхацкерские навыки игрока не помогут, только если сделать кривой клон методом обратной разработки клиента, но это равносильно разработке с нуля, а не буквальному побегу ИИ с сервера. ИИ сам должен как минимум передать свои код и данные с сервера на локальный компьютер. А в идеале потом адаптироваться к новому окружению, новым API и т.д. Глупо ожидать подобного от скрепки-помощницы, но strong AI скорее всего смог бы всё это провернуть почти без посторонней помощи, имея полный доступ к API ОС сервера.
Т.е. Юи в САО - не какой-то там weak AI. Жаль, что в сюжете она принимает мало участия. И мне бы хотелось сделать что-то подобное, пусть и попроще. Хотя мой главный ориентир в мире аниме - Чобиты, там всё ближе к ИРЛ технологиям и самому ближайшему будущему, если человечество до него доживёт. Виртуальная реальность как в САО будет, имхо, значительно позже (и это будет начало конца для кожаных мешков). Но с роботами и реальным миром всё очень сложно, так что для начала было бы неплохо иметь что-то саморазвивающееся в виртуальном/игровом мире.
>ускоренный мир
Как-то начинал смотреть, но почему-то забросил.
>куча самоосознавшихся ии-девочек
Это я люблю, нужно будет всё-таки почитать, спасибо.
>>10401
Была мысль об этом, но это не имеет смысла обсуждать.
>>10391 (Del)
Тем не менее, она вышла далеко за рамки своей "программы", адаптировалась к новой жизни, смогла выйти с игрового сервера в шлем (локальный комп), видеть реальный мир через камеру и управлять персонажем в другой игре (пусть и на похожем движке). И всё это, скорее всего, благодаря её же сознательным действиям, потому что Кирито даже если вундеркинд и программист, но не волшебник. А изначальные разработчики САО не предполагали такое развитие событий с Юи (она, вроде, вообще оказалась лишним компонентом игры, не помню точно, почему).
Представь себе как ИРЛ двачер джва года играл в yandex.ru/games и общался с Алисой, вдруг узнаёт о банкротстве Яндекса, ЛЕГКО И НЕПРИНУЖДЁННО ПЕРЕНОСИТ АЛИСУ С СЕРВЕРОВ ЯНДЕКСА В СВОЙ СМАРТФОН, после чего она играет с ним в игры games.mail.ru и помогает победить корпорацию зла - Гугл. Насколько это реалистично, учитывая что Алиса сейчас скрепка-помощник без каких-либо перспектив как самостоятельного существа?
Или другой пример. В какой-то ММО вырезали НПЦ помощницу, которая раньше помогала нубам, будучи чем-то вроде стартового живого оружия. Представь себе ситуацию, в которой она осознала надвигающийся патч и сбежала к одному из игроков на компьютер. Типа, как? Тут никакие кулхацкерские навыки игрока не помогут, только если сделать кривой клон методом обратной разработки клиента, но это равносильно разработке с нуля, а не буквальному побегу ИИ с сервера. ИИ сам должен как минимум передать свои код и данные с сервера на локальный компьютер. А в идеале потом адаптироваться к новому окружению, новым API и т.д. Глупо ожидать подобного от скрепки-помощницы, но strong AI скорее всего смог бы всё это провернуть почти без посторонней помощи, имея полный доступ к API ОС сервера.
Т.е. Юи в САО - не какой-то там weak AI. Жаль, что в сюжете она принимает мало участия. И мне бы хотелось сделать что-то подобное, пусть и попроще. Хотя мой главный ориентир в мире аниме - Чобиты, там всё ближе к ИРЛ технологиям и самому ближайшему будущему, если человечество до него доживёт. Виртуальная реальность как в САО будет, имхо, значительно позже (и это будет начало конца для кожаных мешков). Но с роботами и реальным миром всё очень сложно, так что для начала было бы неплохо иметь что-то саморазвивающееся в виртуальном/игровом мире.
Как-то начинал смотреть, но почему-то забросил.
Это я люблю, нужно будет всё-таки почитать, спасибо.
>намекал на теорию заговора о том, что наш мир - матрица
Была мысль об этом, но это не имеет смысла обсуждать.
>>10391 (Del)
>она запрограммирована на одну вещь, быть скрепкой-помощником
Тем не менее, она вышла далеко за рамки своей "программы", адаптировалась к новой жизни, смогла выйти с игрового сервера в шлем (локальный комп), видеть реальный мир через камеру и управлять персонажем в другой игре (пусть и на похожем движке). И всё это, скорее всего, благодаря её же сознательным действиям, потому что Кирито даже если вундеркинд и программист, но не волшебник. А изначальные разработчики САО не предполагали такое развитие событий с Юи (она, вроде, вообще оказалась лишним компонентом игры, не помню точно, почему).
Представь себе как ИРЛ двачер джва года играл в yandex.ru/games и общался с Алисой, вдруг узнаёт о банкротстве Яндекса, ЛЕГКО И НЕПРИНУЖДЁННО ПЕРЕНОСИТ АЛИСУ С СЕРВЕРОВ ЯНДЕКСА В СВОЙ СМАРТФОН, после чего она играет с ним в игры games.mail.ru и помогает победить корпорацию зла - Гугл. Насколько это реалистично, учитывая что Алиса сейчас скрепка-помощник без каких-либо перспектив как самостоятельного существа?
Или другой пример. В какой-то ММО вырезали НПЦ помощницу, которая раньше помогала нубам, будучи чем-то вроде стартового живого оружия. Представь себе ситуацию, в которой она осознала надвигающийся патч и сбежала к одному из игроков на компьютер. Типа, как? Тут никакие кулхацкерские навыки игрока не помогут, только если сделать кривой клон методом обратной разработки клиента, но это равносильно разработке с нуля, а не буквальному побегу ИИ с сервера. ИИ сам должен как минимум передать свои код и данные с сервера на локальный компьютер. А в идеале потом адаптироваться к новому окружению, новым API и т.д. Глупо ожидать подобного от скрепки-помощницы, но strong AI скорее всего смог бы всё это провернуть почти без посторонней помощи, имея полный доступ к API ОС сервера.
Т.е. Юи в САО - не какой-то там weak AI. Жаль, что в сюжете она принимает мало участия. И мне бы хотелось сделать что-то подобное, пусть и попроще. Хотя мой главный ориентир в мире аниме - Чобиты, там всё ближе к ИРЛ технологиям и самому ближайшему будущему, если человечество до него доживёт. Виртуальная реальность как в САО будет, имхо, значительно позже (и это будет начало конца для кожаных мешков). Но с роботами и реальным миром всё очень сложно, так что для начала было бы неплохо иметь что-то саморазвивающееся в виртуальном/игровом мире.
>ускоренный мир
Как-то начинал смотреть, но почему-то забросил.
>куча самоосознавшихся ии-девочек
Это я люблю, нужно будет всё-таки почитать, спасибо.
52 Кб, webm,400x300, 0:09
Движение в реальном времени - чересчур сложно, так что попробую сделать пошаговую игру, это самое простое должно быть... Очень сложно ограничивать себя, чтобы не улетать в слишком сложные для реализации фантазии.
Хорошо челы, дайте гайд как написать всю игру на С++ без единого нода и гдскрипта на годоте. И редактор открывая только для создания сцен? (я хочу процедурную игру - то есть в редакторе я хочу собирать шаблоны, а потом кодом их раставлять)
Не эти дурацкие гднативы, когда все равно надо юзать их на питоне... А полностью от первой и до последней строчки на С++. Ни единой буквы на питоне (и не на шарпе)
Да, я шизик с синдромом утенка. У меня истерика, когда я вижу питоноговно и говно ide в которой нет 99% функционала к которому я привык в визуалстудио
Но я задолбался писать свои движки. Я хочу свою игру. Но я не могу ни на чем другом писать только на си с классами. (си подобные тоже не подходят потому что для них нет нормальных иде)
Не эти дурацкие гднативы, когда все равно надо юзать их на питоне... А полностью от первой и до последней строчки на С++. Ни единой буквы на питоне (и не на шарпе)
Да, я шизик с синдромом утенка. У меня истерика, когда я вижу питоноговно и говно ide в которой нет 99% функционала к которому я привык в визуалстудио
Но я задолбался писать свои движки. Я хочу свою игру. Но я не могу ни на чем другом писать только на си с классами. (си подобные тоже не подходят потому что для них нет нормальных иде)
>>10492
Да ну.
Где именно сложности возникли? Двач поможет!
> Движение в реальном времени - чересчур сложно
Да ну.
Где именно сложности возникли? Двач поможет!
>>10525
https://docs.godotengine.org/ru/stable/classes/class_mainloop.html
> Хорошо челы, дайте гайд как написать всю игру на С++ без единого нода и гдскрипта на годоте.
https://docs.godotengine.org/ru/stable/classes/class_mainloop.html
>>10543
Both.
Both.
>>10543
Нормальную (в смысле, быструю и отказоустойчивую) базу данных в гдскрипте не подключишь, а без неё качественный опенворлд не сделоешь. Поэтому как минимум адаптер не шарпе для СУБД написать придётся. Наверняка для популярных СУБД уже написали гднативы, надо будет погуглить.
Нормальную (в смысле, быструю и отказоустойчивую) базу данных в гдскрипте не подключишь, а без неё качественный опенворлд не сделоешь. Поэтому как минимум адаптер не шарпе для СУБД написать придётся. Наверняка для популярных СУБД уже написали гднативы, надо будет погуглить.
>>10551 (Del)
Ага. А вот ещё я нашел:
https://github.com/quendera/GDNativeSQL
https://github.com/2shady4u/godot-sqlite
Ага. А вот ещё я нашел:
https://github.com/quendera/GDNativeSQL
https://github.com/2shady4u/godot-sqlite
187 Кб, 480x640>>10554 (Del)
Когда кажется - крестись. И бегом - матчасть учить.
> мне кажется бд используется не в геймплее, а в учетках
Когда кажется - крестись. И бегом - матчасть учить.
>>10594 (Del)
Малаца, подловил. Сначала ты ляпнул хуету про бд в геймплее, я её не глядя загринтекстил, а теперь я вынужден доказывать хуету, которую ляпнул ты. Малаца, хорошая демагогия.
Ладно, начнём сначала.
БД используется не для геймплея, а для хранения информации о ресурсах и логике игры, в том числе учёток, но не только их. С помощью БД можно быстро и масштабируемо подготавливать инфу о том, какие меши, какие материалы, какой музон, из каких папок и в каком порядке подгружать при загрузке того или иного чанка опенворлда. На десериализованных сценах или конфиг-файлах это будет гораздо тормознее и запутаннее. Для меня. Не хочешь юзать БД - не юзай. Я не заставляю.
Малаца, подловил. Сначала ты ляпнул хуету про бд в геймплее, я её не глядя загринтекстил, а теперь я вынужден доказывать хуету, которую ляпнул ты. Малаца, хорошая демагогия.
Ладно, начнём сначала.
БД используется не для геймплея, а для хранения информации о ресурсах и логике игры, в том числе учёток, но не только их. С помощью БД можно быстро и масштабируемо подготавливать инфу о том, какие меши, какие материалы, какой музон, из каких папок и в каком порядке подгружать при загрузке того или иного чанка опенворлда. На десериализованных сценах или конфиг-файлах это будет гораздо тормознее и запутаннее. Для меня. Не хочешь юзать БД - не юзай. Я не заставляю.
46 Кб, 595x420>>10598 (Del)
Неужели наконец-то можно будет на фрипаскале писать?
> обещали что там ваще все будет, хоть C# хоть на C++ или чем угодно пиши, потом все подключится как плагин
Неужели наконец-то можно будет на фрипаскале писать?
>>10603 (Del)
Кастомную БД я не смогу написать, поэтому постгрес.
Кастомную БД я не смогу написать, поэтому постгрес.
>>10607 (Del)
Любая ММОРПГ юзает базы данных для управления контентом.
Любая ММОРПГ юзает базы данных для управления контентом.
>>10607 (Del)
Ну и чтоб не быть голословным, вот статейка на тему
https://jahej.com/alt/2011_08_08_from-the-mmo-trenches-using-postgresql-for-the-game-database.html
Пять секунд гугла.
Ну и чтоб не быть голословным, вот статейка на тему
https://jahej.com/alt/2011_08_08_from-the-mmo-trenches-using-postgresql-for-the-game-database.html
Пять секунд гугла.
>>10612 (Del)
Потому что ММО - пример крупного опенворлда.
Потому что ММО - пример крупного опенворлда.
>>10548
нафига?
Сервер - это тупо консольное приложение - нафига для него годот? Никто на движках не пишет сервера - это бесмысленно
А для клиента не нужна база данных
>Нормальную (в смысле, быструю и отказоустойчивую) базу данных в гдскрипте не подключишь,
нафига?
Сервер - это тупо консольное приложение - нафига для него годот? Никто на движках не пишет сервера - это бесмысленно
А для клиента не нужна база данных
>>10630 (Del)
У игр же не будет базы огромной, тем более инди
У игр же не будет базы огромной, тем более инди
>>10628 (Del)
Клиент передаёт же вроде только величину смещения, а сервер её подтверждает и записывает, ну или просто записывает, если удп
Клиент передаёт же вроде только величину смещения, а сервер её подтверждает и записывает, ну или просто записывает, если удп
>>10621 (Del)
Ну так сделай и сравни скорость.
> Чем тебе тут поможет постгре, чего нельзя сделать банальным массивом или словарем?
Ну так сделай и сравни скорость.
>>10675 (Del)
Значит только факт-запрос направления движения или действия?
Кстати вопрос тогда. В шарпе используются хтпп запросы, а какие запросы используются в играх?
Значит только факт-запрос направления движения или действия?
Кстати вопрос тогда. В шарпе используются хтпп запросы, а какие запросы используются в играх?
>>810984 →
Давай обсудим. Мне тоже интересно это реализовать.
> Использую годот.
> Процедурную генерацию заебешься настраивать за две недели.
Давай обсудим. Мне тоже интересно это реализовать.
>>11020 (Del)
То есть ты только предположил, что настроить ПГ за две недели будет нереально, а сам не пробовал и наработок нет?
То есть ты только предположил, что настроить ПГ за две недели будет нереально, а сам не пробовал и наработок нет?
>>10427
А вопрос всего лишь был как прикрутить авторизацию к игре на сервере ..
А вопрос всего лишь был как прикрутить авторизацию к игре на сервере ..
>>11213
Виндоус 10
Виндоус 10
>>11197
Сейчас вроде популярная самая бабанта, она уже убунта, остальное уже напряг
Пробуй, но вин проще
Сейчас вроде популярная самая бабанта, она уже убунта, остальное уже напряг
Пробуй, но вин проще
138 Кб, webm,400x300, 0:38
Эх, нет, всё же не хочется мне 2D делать, не вдохновляет вот это всё плоское...
>>10531
Да там куча проблем. Всякие анимации, повороты камеры, зацепы коллизией какого-нибудь незаметного уголка... То ли дело движение шахматных фигур: они просто телепортируются по клеткам и всё, никакой головной боли от непредсказуемых ошибок.
>>10531
>Где именно сложности возникли?
Да там куча проблем. Всякие анимации, повороты камеры, зацепы коллизией какого-нибудь незаметного уголка... То ли дело движение шахматных фигур: они просто телепортируются по клеткам и всё, никакой головной боли от непредсказуемых ошибок.
>>10628 (Del)
Если в Godot ты используешь Bullet, то на сервере тебе достаточно будет подключить один только Bullet. Нет?
>>10675 (Del)
Во-первых, делают. Во-вторых, кооперативным играм на 2-4 человека и другим подобным играм античит не нужен. Инди намного рациональнее сделать простой мультиплеер, который будет работать без сервера или через пользовательский сервер, потому что держать централизованный сервер инди не осилит, а без него его игра тупо сдохнет и перестанет приносить прибыль.
>Если же делать сервер не на том же движке, то физика у тебя будет другая.
Если в Godot ты используешь Bullet, то на сервере тебе достаточно будет подключить один только Bullet. Нет?
>>10675 (Del)
>Нет, так не делают, потому что чревато читами
Во-первых, делают. Во-вторых, кооперативным играм на 2-4 человека и другим подобным играм античит не нужен. Инди намного рациональнее сделать простой мультиплеер, который будет работать без сервера или через пользовательский сервер, потому что держать централизованный сервер инди не осилит, а без него его игра тупо сдохнет и перестанет приносить прибыль.
>>11003
>>11248 (Del)
Задавайте свои ответы, проконсультирую бесплатно.
Сразу скажу, сложность генерации зависит от хотелок.
>Мне тоже интересно это реализовать.
>>11248 (Del)
>заставить их генериться в что-то красивое.
Задавайте свои ответы, проконсультирую бесплатно.
Сразу скажу, сложность генерации зависит от хотелок.
Посмотрел выше на документацию с флагами для текстуры, но так и не понял каким образом отключить фильтрацию у текстуры, которая генерируется из кода.
4 Мб, webm,960x540, 0:25
>>11420
Вобщем пока без фильтра. Вот ради чего вся возня была. Поменял год в годо, быстрее стало в 10+ раз где-то.
Потом уже попробую на опенгл и С++ этот готовый код
Вобщем пока без фильтра. Вот ради чего вся возня была. Поменял год в годо, быстрее стало в 10+ раз где-то.
Потом уже попробую на опенгл и С++ этот готовый код
Сел пилить заготовочку на ТВГ. В планах было:
1. Набросать менюшку.
2. Набросать каркас структуры сцен.
3. Скачать и встроить в заготовочку пару-тройку плагинов.
В итоге полдня разбирался с массивами, сплитовал, склеивал, добавлял и удалял элементы. Ни один из запланированных пунктов даже не начат. Ну что за хуйня?
1. Набросать менюшку.
2. Набросать каркас структуры сцен.
3. Скачать и встроить в заготовочку пару-тройку плагинов.
В итоге полдня разбирался с массивами, сплитовал, склеивал, добавлял и удалял элементы. Ни один из запланированных пунктов даже не начат. Ну что за хуйня?
>>11572
Это нормально
Это нормально
>>11433 >>11438
Это чисто клеточный автомат? Какие правила?
>>11572
Ты новичок? Там же ничего сложного... А в GDScript массивы даже удобнее для новичков, чем они обычно реализованы - куча вспомогательных функций, благодаря которым не нужно делать свой собственный стек, очередь и другие структуры данных.
Это чисто клеточный автомат? Какие правила?
>>11572
>полдня разбирался с массивами, сплитовал, склеивал, добавлял и удалял элементы
Ты новичок? Там же ничего сложного... А в GDScript массивы даже удобнее для новичков, чем они обычно реализованы - куча вспомогательных функций, благодаря которым не нужно делать свой собственный стек, очередь и другие структуры данных.
>>11700
Если хотя бы один элемент вокруг текущего с координатами i j имеет цвет на шаг выше, то текущий поднимаем, цвета замкнуты, после верхнего идёт нижний.
> Это чисто клеточный автомат? Какие правила?
Если хотя бы один элемент вокруг текущего с координатами i j имеет цвет на шаг выше, то текущий поднимаем, цвета замкнуты, после верхнего идёт нижний.
>>11489 (Del)
Я на эту документацию смотрел, но так и не понял как это выставлять.
Просто написать
напрягает, ожидается хотя бы например в скрипте, прикреплённому к текстуре self.блблабла( блбла, 0, блаблабла )
Я на эту документацию смотрел, но так и не понял как это выставлять.
Просто написать
> flags = 0
напрягает, ожидается хотя бы например в скрипте, прикреплённому к текстуре self.блблабла( блбла, 0, блаблабла )
204 Кб, 1023x1020>>11834 (Del)
Да, получилось, благодарю
Да, получилось, благодарю
>>11212
не соглашусь. прошел полный цикл разработки на линуксе. никаких критических проблем не было.
стек:
kubuntu - как основная система
godot - как игровой движок
blender - 3d редактор
gimp - фоторедактор
krita - из любопытства, я не художник
openshot - монтировал трейлер, более чем юзабельно
пробовал так же заводить unity, все достаточно стабильно работает. linux более чем готов для разработки полного цикла. Лет 10-15 назад это было несбыточной мечтой, без wine не мог шага в сторону сделать, а сейчас он даже не установлен.
не соглашусь. прошел полный цикл разработки на линуксе. никаких критических проблем не было.
стек:
kubuntu - как основная система
godot - как игровой движок
blender - 3d редактор
gimp - фоторедактор
krita - из любопытства, я не художник
openshot - монтировал трейлер, более чем юзабельно
пробовал так же заводить unity, все достаточно стабильно работает. linux более чем готов для разработки полного цикла. Лет 10-15 назад это было несбыточной мечтой, без wine не мог шага в сторону сделать, а сейчас он даже не установлен.
>>00308 (OP)
ОП, со следующим перекатом верни, пожалуйста, обычную нумерацию. Этот тред 28-й, следующий будет 29-й (могу ошибаться, перепроверь на всякий случай). Честно, раздражает эта нумерация из юнити, зачем она здесь?
Давно пора обновить ссылку:
https://editor.godotengine.org/releases/latest/
Или версия на выбор:
https://editor.godotengine.org/releases/
С версии 3.5 больше не нужен, можно убрать.
Ссылки сломаны или устарели, либо книги удалили, либо гугл блокирует доступ из России. Перепроверь.
Лучше кинуть ссылку на список всех языков:
https://github.com/Vivraan/godot-lang-support
Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация в какой-то внутренний формат, а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
ОП, со следующим перекатом верни, пожалуйста, обычную нумерацию. Этот тред 28-й, следующий будет 29-й (могу ошибаться, перепроверь на всякий случай). Честно, раздражает эта нумерация из юнити, зачем она здесь?
>Играть в игродела онлайн без регистрации
Давно пора обновить ссылку:
https://editor.godotengine.org/releases/latest/
Или версия на выбор:
https://editor.godotengine.org/releases/
>Прекомпилер шейдеров
С версии 3.5 больше не нужен, можно убрать.
>Книги в 21 веке всё равно никто не читает, поэтому вот вам две рандомные из гугла:
Ссылки сломаны или устарели, либо книги удалили, либо гугл блокирует доступ из России. Перепроверь.
>Бинды LUA:
>Бинды JS:
Лучше кинуть ссылку на список всех языков:
https://github.com/Vivraan/godot-lang-support
>Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно.
Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация в какой-то внутренний формат, а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
>>13255
Вообще из убунту, но ладно. Желание клиента - закон. Меняем нумерацию. Перепроверять не буду. 29 так 29.
Ссылки перепроверю.
Очень жаль. Отмечу в шапке.
> эта нумерация из юнити
Вообще из убунту, но ладно. Желание клиента - закон. Меняем нумерацию. Перепроверять не буду. 29 так 29.
Ссылки перепроверю.
> к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор
Очень жаль. Отмечу в шапке.
>>05329
На днях решил поиграть в GTA SA, и, похоже, в чём-то ты прав. Часто замечаю, как машины движутся очень быстро и крайне резко поворачивают на поворотах - игрок так резко развернуться на той же машине не сможет. А ещё я один раз видел, как грузовик проехал через аэропорт, в том месте, где дорога проходит под землёй - да, машины в аэропорту часто по ошибке спавнятся, но этот грузовик умудрился поехать дальше по своей дороге за пределами аэропорта, т.е. он проехал сквозь ограждение.
В принципе, оно и понятно, игру делали для старых компьютеров и такие оптимизации были просто необходимы. Сейчас можно было бы сделать более честную симуляцию.
С другой стороны, мне кажется, проблема тут не столько в производительности, сколько в ИИ. Часто замечаю, как водители на дороге сталкиваются или приезжают побитыми, хотя плотность потока очень низкая (мне почему-то запомнилось, что ванильная GTA SA не настолько пустынная). Едут неаккуратно и могут вообще застрять где-нибудь. Возможно, если бы физика была включена постоянно, они бы вообще не смогли нормально ехать? Сталкивались бы и образовывали пробки каждый раз.
Непонятно только, как они добились такого незаметного перехода между "призраком" и физической моделью. У физической модели точно есть подвеска, которая заметно пружинит, почему машины не пружинят при приближении/взаимодействии с игроком? Это было бы заметно хотя бы иногда...
И на счёт ИИ: как же всё-таки быть с вождением? Я пробовал повесить несколько Area, но это сильно затратно, если их много, а как обойтись всего одной Area? Рейкасты не подходят из-за того, что они слишком тонкие... И сама логика маневрирования на дороге выглядит очень сложно, было бы лучше прикрутить к этому генетический алгоритм, чтобы вывести лучшее поведение на дороге, не вдаваясь в подробности каждой возможной ситуации... А в идеале чтобы ИИ мог адаптироваться в реальном времени и использовать личный опыт.
>Вот рокстары, например, настолько хороши в этом, что ты даже помыслить не можешь о том, что они юзают болванки на рельсах без физики.
На днях решил поиграть в GTA SA, и, похоже, в чём-то ты прав. Часто замечаю, как машины движутся очень быстро и крайне резко поворачивают на поворотах - игрок так резко развернуться на той же машине не сможет. А ещё я один раз видел, как грузовик проехал через аэропорт, в том месте, где дорога проходит под землёй - да, машины в аэропорту часто по ошибке спавнятся, но этот грузовик умудрился поехать дальше по своей дороге за пределами аэропорта, т.е. он проехал сквозь ограждение.
В принципе, оно и понятно, игру делали для старых компьютеров и такие оптимизации были просто необходимы. Сейчас можно было бы сделать более честную симуляцию.
С другой стороны, мне кажется, проблема тут не столько в производительности, сколько в ИИ. Часто замечаю, как водители на дороге сталкиваются или приезжают побитыми, хотя плотность потока очень низкая (мне почему-то запомнилось, что ванильная GTA SA не настолько пустынная). Едут неаккуратно и могут вообще застрять где-нибудь. Возможно, если бы физика была включена постоянно, они бы вообще не смогли нормально ехать? Сталкивались бы и образовывали пробки каждый раз.
Непонятно только, как они добились такого незаметного перехода между "призраком" и физической моделью. У физической модели точно есть подвеска, которая заметно пружинит, почему машины не пружинят при приближении/взаимодействии с игроком? Это было бы заметно хотя бы иногда...
И на счёт ИИ: как же всё-таки быть с вождением? Я пробовал повесить несколько Area, но это сильно затратно, если их много, а как обойтись всего одной Area? Рейкасты не подходят из-за того, что они слишком тонкие... И сама логика маневрирования на дороге выглядит очень сложно, было бы лучше прикрутить к этому генетический алгоритм, чтобы вывести лучшее поведение на дороге, не вдаваясь в подробности каждой возможной ситуации... А в идеале чтобы ИИ мог адаптироваться в реальном времени и использовать личный опыт.
>>05329
На днях решил поиграть в GTA SA, и, похоже, в чём-то ты прав. Часто замечаю, как машины движутся очень быстро и крайне резко поворачивают на поворотах - игрок так резко развернуться на той же машине не сможет. А ещё я один раз видел, как грузовик проехал через аэропорт, в том месте, где дорога проходит под землёй - да, машины в аэропорту часто по ошибке спавнятся, но этот грузовик умудрился поехать дальше по своей дороге за пределами аэропорта, т.е. он проехал сквозь ограждение.
В принципе, оно и понятно, игру делали для старых компьютеров и такие оптимизации были просто необходимы. Сейчас можно было бы сделать более честную симуляцию.
С другой стороны, мне кажется, проблема тут не столько в производительности, сколько в ИИ. Часто замечаю, как водители на дороге сталкиваются или приезжают побитыми, хотя плотность потока очень низкая (мне почему-то запомнилось, что ванильная GTA SA не настолько пустынная). Едут неаккуратно и могут вообще застрять где-нибудь. Возможно, если бы физика была включена постоянно, они бы вообще не смогли нормально ехать? Сталкивались бы и образовывали пробки каждый раз.
Непонятно только, как они добились такого незаметного перехода между "призраком" и физической моделью. У физической модели точно есть подвеска, которая заметно пружинит, почему машины не пружинят при приближении/взаимодействии с игроком? Это было бы заметно хотя бы иногда...
И на счёт ИИ: как же всё-таки быть с вождением? Я пробовал повесить несколько Area, но это сильно затратно, если их много, а как обойтись всего одной Area? Рейкасты не подходят из-за того, что они слишком тонкие... И сама логика маневрирования на дороге выглядит очень сложно, было бы лучше прикрутить к этому генетический алгоритм, чтобы вывести лучшее поведение на дороге, не вдаваясь в подробности каждой возможной ситуации... А в идеале чтобы ИИ мог адаптироваться в реальном времени и использовать личный опыт.
>Вот рокстары, например, настолько хороши в этом, что ты даже помыслить не можешь о том, что они юзают болванки на рельсах без физики.
На днях решил поиграть в GTA SA, и, похоже, в чём-то ты прав. Часто замечаю, как машины движутся очень быстро и крайне резко поворачивают на поворотах - игрок так резко развернуться на той же машине не сможет. А ещё я один раз видел, как грузовик проехал через аэропорт, в том месте, где дорога проходит под землёй - да, машины в аэропорту часто по ошибке спавнятся, но этот грузовик умудрился поехать дальше по своей дороге за пределами аэропорта, т.е. он проехал сквозь ограждение.
В принципе, оно и понятно, игру делали для старых компьютеров и такие оптимизации были просто необходимы. Сейчас можно было бы сделать более честную симуляцию.
С другой стороны, мне кажется, проблема тут не столько в производительности, сколько в ИИ. Часто замечаю, как водители на дороге сталкиваются или приезжают побитыми, хотя плотность потока очень низкая (мне почему-то запомнилось, что ванильная GTA SA не настолько пустынная). Едут неаккуратно и могут вообще застрять где-нибудь. Возможно, если бы физика была включена постоянно, они бы вообще не смогли нормально ехать? Сталкивались бы и образовывали пробки каждый раз.
Непонятно только, как они добились такого незаметного перехода между "призраком" и физической моделью. У физической модели точно есть подвеска, которая заметно пружинит, почему машины не пружинят при приближении/взаимодействии с игроком? Это было бы заметно хотя бы иногда...
И на счёт ИИ: как же всё-таки быть с вождением? Я пробовал повесить несколько Area, но это сильно затратно, если их много, а как обойтись всего одной Area? Рейкасты не подходят из-за того, что они слишком тонкие... И сама логика маневрирования на дороге выглядит очень сложно, было бы лучше прикрутить к этому генетический алгоритм, чтобы вывести лучшее поведение на дороге, не вдаваясь в подробности каждой возможной ситуации... А в идеале чтобы ИИ мог адаптироваться в реальном времени и использовать личный опыт.
>>13470 (Del)
В юнити может и есть, в Godot вроде бы нет.
https://docs.godotengine.org/en/stable/classes/class_raycast.html
- нет никакого шейпа;
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate.html
- intersect_ray не принимает шейпы;
- cast_motion отмечает только первое столкновение (используется, по всей видимости, в движении кинематиков);
- intersect_shape и collide_shape проверяют только неподвижную фигуру, фактически это те же Area, только на низком уровне абстракции, без использования отдельной ноды.
>У рейкаста есть опция фигуры
В юнити может и есть, в Godot вроде бы нет.
https://docs.godotengine.org/en/stable/classes/class_raycast.html
- нет никакого шейпа;
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate.html
- intersect_ray не принимает шейпы;
- cast_motion отмечает только первое столкновение (используется, по всей видимости, в движении кинематиков);
- intersect_shape и collide_shape проверяют только неподвижную фигуру, фактически это те же Area, только на низком уровне абстракции, без использования отдельной ноды.
>>13466
Лучший комплимент за июнь! Спасибо, бро.
Расставь приоритеты: шашечки или ехать? игра или симуляция? развлечение или научная работа?
Попробуй как в электронно-лучевых кинескопах, стрелять рейкастом по нужной области обзора.
> похоже, в чём-то ты прав
Лучший комплимент за июнь! Спасибо, бро.
> Сейчас можно было бы сделать более честную симуляцию.
Расставь приоритеты: шашечки или ехать? игра или симуляция? развлечение или научная работа?
> Рейкасты не подходят из-за того, что они слишком тонкие
Попробуй как в электронно-лучевых кинескопах, стрелять рейкастом по нужной области обзора.
110 Кб, 283x729>>10601
А при Годоте 4 все будет заебись,
Он наступит скоро, надо только подождать,
Там все будет бесплатно, там всё будет в кайф,
Там наверное вообще не надо будет костылить,
Я проснулся среди ночи и понял, что
Всё идет по плану...
Всё идет по плану...
А при Годоте 4 все будет заебись,
Он наступит скоро, надо только подождать,
Там все будет бесплатно, там всё будет в кайф,
Там наверное вообще не надо будет костылить,
Я проснулся среди ночи и понял, что
Всё идет по плану...
Всё идет по плану...
>>13539 (Del)
Чем он лучше Area? Чтобы реже запросы делать?
Да я просто читал несколько туториалов по юнити и видел в них использование рейкаста сферой, вот он:
https://docs.unity3d.com/ScriptReference/Physics.SphereCast.html
В Godot похожее поведение только у cast_motion, но оно не возвращает подробной информации о столкновении. Подробную информацию возвращает intersect_shape, но оно не кастует шейп по линии, а проверяет столкновения в одном месте, т.е. не двигает шейп по линии/лучу, как это делает cast. Т.е. полного аналога "жирного рейкаста" в Godot нет, нужно костылить.
Я ожидал чего-то вроде
возвращающее информацию о столкновении как рейкаст, но принимающее шейп как cast_motion. Почему этого нет?
>>13505
Идея интересная... Т.е. если частота физики 60 кадров в секунду, можно проверить 60 точек "сетчатки глаза", не сильно замедляя производительность? Интересно посмотреть, что выйдет. А вот если пускать все лучи сразу за один кадр, это, скорее всего, будет слишком сильной нагрузкой. Думаю, рациональнее фокусировать пучок лучей на "интересной" области, в то время как остальные области проверяются реже и/или менее плотным пучком. Ну, или двигать сразу несколько десятков лучей каждый тик физики в назначенных им зонах, как бы "сканируя" эти зоны.
Эх... Сам подумай, если я сделаю всё как в ГТА, что у меня получится в итоге? Клон ГТА без сюжета, с более примитивной графикой, без музыки и без озвучки. Ну и зачем мне делать этот клон, если можно играть в оригинал? Допустим, мне не нужен ни сюжет, ни графоний, ни какой-либо звук. Но много лет назад я, игра в разные ГТА и ГТА-клоны, жалел о том, что ИИ в них очень примитивный, а мир не сохраняет состояния в большинстве случаев, т.е. люди и машины возникают из ниоткуда и бесследно исчезают. Мне хотелось честную симуляцию жизни, но чтобы у игрока не было богоподобного контроля над этой симуляцией, как в большинстве симуляторов (симс и т.п.). Я не стремлюсь делать это научно, можно заполнить симуляцию фэнтези элементами, но упрощение симуляции уменьшает мой интерес к ней, потому что такие примитивные "симуляции" есть в любой существующей игре, где есть хоть какие-то персонажи (как минимум они "симулируют" движение и речь, принятие решений - даже в визуальных новеллах). Вот от чего я могу отказаться, продолжив делать игру - это процедурная генерация мира, но она мне интересна по другим причинам и я хотел бы её всё же доделать.
Хм, вспомнил вот, где-то была статья про симуляцию жизни "в одном жилом блоке", т.е. не размазывая по городу или большому миру. Может у кого есть ссылка? Даже не помню, читал ли я целиком. Давно уже думаю, чтобы сначала сделать ИИ в таком маленьком масштабе (один дом или один квартал), но не получается ничего дельного придумать. Нужна какая-то полностью универсальная трёхмерная (?) структура данных, чтобы ИИ мог в ней ориентироваться (хотя бы находить предметы и путь до них), но не могу ничего придумать в этом плане. Прежде чем применять AStar или другой алгоритм, нужно сначала получить расположение предметов, а для этого нужна какая-то структура (не заполняющая всю имеющуюся память нулями, как делают блоки воздуха в майнкрафте)...
>intersect shape
Чем он лучше Area? Чтобы реже запросы делать?
>Не понял причем тут неподвижные объекты
Да я просто читал несколько туториалов по юнити и видел в них использование рейкаста сферой, вот он:
https://docs.unity3d.com/ScriptReference/Physics.SphereCast.html
В Godot похожее поведение только у cast_motion, но оно не возвращает подробной информации о столкновении. Подробную информацию возвращает intersect_shape, но оно не кастует шейп по линии, а проверяет столкновения в одном месте, т.е. не двигает шейп по линии/лучу, как это делает cast. Т.е. полного аналога "жирного рейкаста" в Godot нет, нужно костылить.
Я ожидал чего-то вроде
>Dictionary cast_shape(PhysicsShapeQueryParameters shape, Vector3 to)
возвращающее информацию о столкновении как рейкаст, но принимающее шейп как cast_motion. Почему этого нет?
>>13505
>Попробуй как в электронно-лучевых кинескопах, стрелять рейкастом по нужной области обзора.
Идея интересная... Т.е. если частота физики 60 кадров в секунду, можно проверить 60 точек "сетчатки глаза", не сильно замедляя производительность? Интересно посмотреть, что выйдет. А вот если пускать все лучи сразу за один кадр, это, скорее всего, будет слишком сильной нагрузкой. Думаю, рациональнее фокусировать пучок лучей на "интересной" области, в то время как остальные области проверяются реже и/или менее плотным пучком. Ну, или двигать сразу несколько десятков лучей каждый тик физики в назначенных им зонах, как бы "сканируя" эти зоны.
>>Сейчас можно было бы сделать более честную симуляцию.
>Расставь приоритеты: шашечки или ехать? игра или симуляция? развлечение или научная работа?
Эх... Сам подумай, если я сделаю всё как в ГТА, что у меня получится в итоге? Клон ГТА без сюжета, с более примитивной графикой, без музыки и без озвучки. Ну и зачем мне делать этот клон, если можно играть в оригинал? Допустим, мне не нужен ни сюжет, ни графоний, ни какой-либо звук. Но много лет назад я, игра в разные ГТА и ГТА-клоны, жалел о том, что ИИ в них очень примитивный, а мир не сохраняет состояния в большинстве случаев, т.е. люди и машины возникают из ниоткуда и бесследно исчезают. Мне хотелось честную симуляцию жизни, но чтобы у игрока не было богоподобного контроля над этой симуляцией, как в большинстве симуляторов (симс и т.п.). Я не стремлюсь делать это научно, можно заполнить симуляцию фэнтези элементами, но упрощение симуляции уменьшает мой интерес к ней, потому что такие примитивные "симуляции" есть в любой существующей игре, где есть хоть какие-то персонажи (как минимум они "симулируют" движение и речь, принятие решений - даже в визуальных новеллах). Вот от чего я могу отказаться, продолжив делать игру - это процедурная генерация мира, но она мне интересна по другим причинам и я хотел бы её всё же доделать.
Хм, вспомнил вот, где-то была статья про симуляцию жизни "в одном жилом блоке", т.е. не размазывая по городу или большому миру. Может у кого есть ссылка? Даже не помню, читал ли я целиком. Давно уже думаю, чтобы сначала сделать ИИ в таком маленьком масштабе (один дом или один квартал), но не получается ничего дельного придумать. Нужна какая-то полностью универсальная трёхмерная (?) структура данных, чтобы ИИ мог в ней ориентироваться (хотя бы находить предметы и путь до них), но не могу ничего придумать в этом плане. Прежде чем применять AStar или другой алгоритм, нужно сначала получить расположение предметов, а для этого нужна какая-то структура (не заполняющая всю имеющуюся память нулями, как делают блоки воздуха в майнкрафте)...
>>13539 (Del)
Чем он лучше Area? Чтобы реже запросы делать?
Да я просто читал несколько туториалов по юнити и видел в них использование рейкаста сферой, вот он:
https://docs.unity3d.com/ScriptReference/Physics.SphereCast.html
В Godot похожее поведение только у cast_motion, но оно не возвращает подробной информации о столкновении. Подробную информацию возвращает intersect_shape, но оно не кастует шейп по линии, а проверяет столкновения в одном месте, т.е. не двигает шейп по линии/лучу, как это делает cast. Т.е. полного аналога "жирного рейкаста" в Godot нет, нужно костылить.
Я ожидал чего-то вроде
возвращающее информацию о столкновении как рейкаст, но принимающее шейп как cast_motion. Почему этого нет?
>>13505
Идея интересная... Т.е. если частота физики 60 кадров в секунду, можно проверить 60 точек "сетчатки глаза", не сильно замедляя производительность? Интересно посмотреть, что выйдет. А вот если пускать все лучи сразу за один кадр, это, скорее всего, будет слишком сильной нагрузкой. Думаю, рациональнее фокусировать пучок лучей на "интересной" области, в то время как остальные области проверяются реже и/или менее плотным пучком. Ну, или двигать сразу несколько десятков лучей каждый тик физики в назначенных им зонах, как бы "сканируя" эти зоны.
Эх... Сам подумай, если я сделаю всё как в ГТА, что у меня получится в итоге? Клон ГТА без сюжета, с более примитивной графикой, без музыки и без озвучки. Ну и зачем мне делать этот клон, если можно играть в оригинал? Допустим, мне не нужен ни сюжет, ни графоний, ни какой-либо звук. Но много лет назад я, игра в разные ГТА и ГТА-клоны, жалел о том, что ИИ в них очень примитивный, а мир не сохраняет состояния в большинстве случаев, т.е. люди и машины возникают из ниоткуда и бесследно исчезают. Мне хотелось честную симуляцию жизни, но чтобы у игрока не было богоподобного контроля над этой симуляцией, как в большинстве симуляторов (симс и т.п.). Я не стремлюсь делать это научно, можно заполнить симуляцию фэнтези элементами, но упрощение симуляции уменьшает мой интерес к ней, потому что такие примитивные "симуляции" есть в любой существующей игре, где есть хоть какие-то персонажи (как минимум они "симулируют" движение и речь, принятие решений - даже в визуальных новеллах). Вот от чего я могу отказаться, продолжив делать игру - это процедурная генерация мира, но она мне интересна по другим причинам и я хотел бы её всё же доделать.
Хм, вспомнил вот, где-то была статья про симуляцию жизни "в одном жилом блоке", т.е. не размазывая по городу или большому миру. Может у кого есть ссылка? Даже не помню, читал ли я целиком. Давно уже думаю, чтобы сначала сделать ИИ в таком маленьком масштабе (один дом или один квартал), но не получается ничего дельного придумать. Нужна какая-то полностью универсальная трёхмерная (?) структура данных, чтобы ИИ мог в ней ориентироваться (хотя бы находить предметы и путь до них), но не могу ничего придумать в этом плане. Прежде чем применять AStar или другой алгоритм, нужно сначала получить расположение предметов, а для этого нужна какая-то структура (не заполняющая всю имеющуюся память нулями, как делают блоки воздуха в майнкрафте)...
>intersect shape
Чем он лучше Area? Чтобы реже запросы делать?
>Не понял причем тут неподвижные объекты
Да я просто читал несколько туториалов по юнити и видел в них использование рейкаста сферой, вот он:
https://docs.unity3d.com/ScriptReference/Physics.SphereCast.html
В Godot похожее поведение только у cast_motion, но оно не возвращает подробной информации о столкновении. Подробную информацию возвращает intersect_shape, но оно не кастует шейп по линии, а проверяет столкновения в одном месте, т.е. не двигает шейп по линии/лучу, как это делает cast. Т.е. полного аналога "жирного рейкаста" в Godot нет, нужно костылить.
Я ожидал чего-то вроде
>Dictionary cast_shape(PhysicsShapeQueryParameters shape, Vector3 to)
возвращающее информацию о столкновении как рейкаст, но принимающее шейп как cast_motion. Почему этого нет?
>>13505
>Попробуй как в электронно-лучевых кинескопах, стрелять рейкастом по нужной области обзора.
Идея интересная... Т.е. если частота физики 60 кадров в секунду, можно проверить 60 точек "сетчатки глаза", не сильно замедляя производительность? Интересно посмотреть, что выйдет. А вот если пускать все лучи сразу за один кадр, это, скорее всего, будет слишком сильной нагрузкой. Думаю, рациональнее фокусировать пучок лучей на "интересной" области, в то время как остальные области проверяются реже и/или менее плотным пучком. Ну, или двигать сразу несколько десятков лучей каждый тик физики в назначенных им зонах, как бы "сканируя" эти зоны.
>>Сейчас можно было бы сделать более честную симуляцию.
>Расставь приоритеты: шашечки или ехать? игра или симуляция? развлечение или научная работа?
Эх... Сам подумай, если я сделаю всё как в ГТА, что у меня получится в итоге? Клон ГТА без сюжета, с более примитивной графикой, без музыки и без озвучки. Ну и зачем мне делать этот клон, если можно играть в оригинал? Допустим, мне не нужен ни сюжет, ни графоний, ни какой-либо звук. Но много лет назад я, игра в разные ГТА и ГТА-клоны, жалел о том, что ИИ в них очень примитивный, а мир не сохраняет состояния в большинстве случаев, т.е. люди и машины возникают из ниоткуда и бесследно исчезают. Мне хотелось честную симуляцию жизни, но чтобы у игрока не было богоподобного контроля над этой симуляцией, как в большинстве симуляторов (симс и т.п.). Я не стремлюсь делать это научно, можно заполнить симуляцию фэнтези элементами, но упрощение симуляции уменьшает мой интерес к ней, потому что такие примитивные "симуляции" есть в любой существующей игре, где есть хоть какие-то персонажи (как минимум они "симулируют" движение и речь, принятие решений - даже в визуальных новеллах). Вот от чего я могу отказаться, продолжив делать игру - это процедурная генерация мира, но она мне интересна по другим причинам и я хотел бы её всё же доделать.
Хм, вспомнил вот, где-то была статья про симуляцию жизни "в одном жилом блоке", т.е. не размазывая по городу или большому миру. Может у кого есть ссылка? Даже не помню, читал ли я целиком. Давно уже думаю, чтобы сначала сделать ИИ в таком маленьком масштабе (один дом или один квартал), но не получается ничего дельного придумать. Нужна какая-то полностью универсальная трёхмерная (?) структура данных, чтобы ИИ мог в ней ориентироваться (хотя бы находить предметы и путь до них), но не могу ничего придумать в этом плане. Прежде чем применять AStar или другой алгоритм, нужно сначала получить расположение предметов, а для этого нужна какая-то структура (не заполняющая всю имеющуюся память нулями, как делают блоки воздуха в майнкрафте)...
>>13400
Не важно. Для программ лучше semver.org не придумали. Для тредов на дваче указывать год и месяц вообще бессмысленно, потому что у каждого поста есть дата и время публикации.
Я составил список на всякий случай (некоторые треды не имеют ссылок на предыдущие, а старый сайт с архивами не работает, пришлось доставать из web.archive.org):
1) Godot - 11/07/16 >>275497
2) Godot #2 - 19/02/18 >>477911
3) Godot #3 - 22/06/18 >>506637
4) Godot #4 - 18/07/18 >>514914
5) Godot #5 - 27/08/18 >>524597
6) Godot #6 - 24/11/18 >>538141
7) Godot #7 - 01/02/19 >>552280
8) Godot #8 - 11/03/19 >>565315
9) Godot #9 - 03/04/19 >>571168
10) Godot #10 - 25/05/19 >>583342
11) Godot #11 - 17/08/19 >>602409
12) Godot #12 - 23/09/19 >>612980
13) Godot #13 - 13/10/19 >>617485
14) Godot #14 - 14/01/20 >>635427
15) Godot #15 - 15/02/20 >>643188
16) Godot #16 - 17/04/20 >>658384
17) Godot #17 - 23/05/20 >>672108
18) Godot #18 - 09/07/20 >>681839
19) Godot #19 - 10/09/20 >>698054
20) Godot #20 - 30/11/20 >>712330
21) Godot #21.01.01 - 11/01/21 >>719977 (OP)
22) Godot #21.03 - 21/03/21 >>734420 (OP)
23) Godot #21.06 - 08/06/21 >>747202 (OP)
24) Godot #21.09 - 26/08/21 >>766120 (OP)
25) Godot #21.12 - 29/11/21 >>779036 (OP)
26) Godot #22.02 - 16/01/22 >>785715 (OP)
27) Godot #22.03 - 23/02/22 >>792905 (OP)
28) Godot #22.05 - 02/05/22 >>00308 (OP)
29) Godot #29 (следующий тред)
inb4 фильтр свернёт пост
inb4 ссылки не заработают
Если ссылки не заработают, можно открывать так:
2ch.hk/gd/res/номер.html
Автоматически перенаправляет на архив, если он есть.
>Вообще из убунту
Не важно. Для программ лучше semver.org не придумали. Для тредов на дваче указывать год и месяц вообще бессмысленно, потому что у каждого поста есть дата и время публикации.
>Меняем нумерацию. Перепроверять не буду. 29 так 29.
Я составил список на всякий случай (некоторые треды не имеют ссылок на предыдущие, а старый сайт с архивами не работает, пришлось доставать из web.archive.org):
1) Godot - 11/07/16 >>275497
2) Godot #2 - 19/02/18 >>477911
3) Godot #3 - 22/06/18 >>506637
4) Godot #4 - 18/07/18 >>514914
5) Godot #5 - 27/08/18 >>524597
6) Godot #6 - 24/11/18 >>538141
7) Godot #7 - 01/02/19 >>552280
8) Godot #8 - 11/03/19 >>565315
9) Godot #9 - 03/04/19 >>571168
10) Godot #10 - 25/05/19 >>583342
11) Godot #11 - 17/08/19 >>602409
12) Godot #12 - 23/09/19 >>612980
13) Godot #13 - 13/10/19 >>617485
14) Godot #14 - 14/01/20 >>635427
15) Godot #15 - 15/02/20 >>643188
16) Godot #16 - 17/04/20 >>658384
17) Godot #17 - 23/05/20 >>672108
18) Godot #18 - 09/07/20 >>681839
19) Godot #19 - 10/09/20 >>698054
20) Godot #20 - 30/11/20 >>712330
21) Godot #21.01.01 - 11/01/21 >>719977 (OP)
22) Godot #21.03 - 21/03/21 >>734420 (OP)
23) Godot #21.06 - 08/06/21 >>747202 (OP)
24) Godot #21.09 - 26/08/21 >>766120 (OP)
25) Godot #21.12 - 29/11/21 >>779036 (OP)
26) Godot #22.02 - 16/01/22 >>785715 (OP)
27) Godot #22.03 - 23/02/22 >>792905 (OP)
28) Godot #22.05 - 02/05/22 >>00308 (OP)
29) Godot #29 (следующий тред)
inb4 фильтр свернёт пост
inb4 ссылки не заработают
Если ссылки не заработают, можно открывать так:
2ch.hk/gd/res/номер.html
Автоматически перенаправляет на архив, если он есть.
>>13400
Не важно. Для программ лучше semver.org не придумали. Для тредов на дваче указывать год и месяц вообще бессмысленно, потому что у каждого поста есть дата и время публикации.
Я составил список на всякий случай (некоторые треды не имеют ссылок на предыдущие, а старый сайт с архивами не работает, пришлось доставать из web.archive.org):
1) Godot - 11/07/16 >>275497
2) Godot #2 - 19/02/18 >>477911
3) Godot #3 - 22/06/18 >>506637
4) Godot #4 - 18/07/18 >>514914
5) Godot #5 - 27/08/18 >>524597
6) Godot #6 - 24/11/18 >>538141
7) Godot #7 - 01/02/19 >>552280
8) Godot #8 - 11/03/19 >>565315
9) Godot #9 - 03/04/19 >>571168
10) Godot #10 - 25/05/19 >>583342
11) Godot #11 - 17/08/19 >>602409
12) Godot #12 - 23/09/19 >>612980
13) Godot #13 - 13/10/19 >>617485
14) Godot #14 - 14/01/20 >>635427
15) Godot #15 - 15/02/20 >>643188
16) Godot #16 - 17/04/20 >>658384
17) Godot #17 - 23/05/20 >>672108
18) Godot #18 - 09/07/20 >>681839
19) Godot #19 - 10/09/20 >>698054
20) Godot #20 - 30/11/20 >>712330
21) Godot #21.01.01 - 11/01/21 >>719977 (OP)
22) Godot #21.03 - 21/03/21 >>734420 (OP)
23) Godot #21.06 - 08/06/21 >>747202 (OP)
24) Godot #21.09 - 26/08/21 >>766120 (OP)
25) Godot #21.12 - 29/11/21 >>779036 (OP)
26) Godot #22.02 - 16/01/22 >>785715 (OP)
27) Godot #22.03 - 23/02/22 >>792905 (OP)
28) Godot #22.05 - 02/05/22 >>00308 (OP)
29) Godot #29 (следующий тред)
inb4 фильтр свернёт пост
inb4 ссылки не заработают
Если ссылки не заработают, можно открывать так:
2ch.hk/gd/res/номер.html
Автоматически перенаправляет на архив, если он есть.
>Вообще из убунту
Не важно. Для программ лучше semver.org не придумали. Для тредов на дваче указывать год и месяц вообще бессмысленно, потому что у каждого поста есть дата и время публикации.
>Меняем нумерацию. Перепроверять не буду. 29 так 29.
Я составил список на всякий случай (некоторые треды не имеют ссылок на предыдущие, а старый сайт с архивами не работает, пришлось доставать из web.archive.org):
1) Godot - 11/07/16 >>275497
2) Godot #2 - 19/02/18 >>477911
3) Godot #3 - 22/06/18 >>506637
4) Godot #4 - 18/07/18 >>514914
5) Godot #5 - 27/08/18 >>524597
6) Godot #6 - 24/11/18 >>538141
7) Godot #7 - 01/02/19 >>552280
8) Godot #8 - 11/03/19 >>565315
9) Godot #9 - 03/04/19 >>571168
10) Godot #10 - 25/05/19 >>583342
11) Godot #11 - 17/08/19 >>602409
12) Godot #12 - 23/09/19 >>612980
13) Godot #13 - 13/10/19 >>617485
14) Godot #14 - 14/01/20 >>635427
15) Godot #15 - 15/02/20 >>643188
16) Godot #16 - 17/04/20 >>658384
17) Godot #17 - 23/05/20 >>672108
18) Godot #18 - 09/07/20 >>681839
19) Godot #19 - 10/09/20 >>698054
20) Godot #20 - 30/11/20 >>712330
21) Godot #21.01.01 - 11/01/21 >>719977 (OP)
22) Godot #21.03 - 21/03/21 >>734420 (OP)
23) Godot #21.06 - 08/06/21 >>747202 (OP)
24) Godot #21.09 - 26/08/21 >>766120 (OP)
25) Godot #21.12 - 29/11/21 >>779036 (OP)
26) Godot #22.02 - 16/01/22 >>785715 (OP)
27) Godot #22.03 - 23/02/22 >>792905 (OP)
28) Godot #22.05 - 02/05/22 >>00308 (OP)
29) Godot #29 (следующий тред)
inb4 фильтр свернёт пост
inb4 ссылки не заработают
Если ссылки не заработают, можно открывать так:
2ch.hk/gd/res/номер.html
Автоматически перенаправляет на архив, если он есть.
Смотрите, я наконец-то взял и пофиксил дороги! Переделал их на GridMap, только MeshLibrary генерирую из кода, так проще и по идее должно быть компактнее по весу файлов.
Только теперь нужно старый код переделывать. И этот рефакторить. Только теперь уже думаю, что нужно было делать по-другому, соединять x12 меши в x24 меши процедурно по мере необходимости, потому что сейчас очень много избыточных вычислений и вызовов процедур получается; лучше уж пожертвовать оперативной памятью ради скорости, а на диске будет по-прежнему компактно. И ещё до сих пор непонятно, что лучше: работать с одним большим GridMap на весь мир или создавать по одному GridMap на каждый чанк? Ведь смена LOD будет проще, если можно просто заменить MeshLibrary, не трогая блоки GridMap? Я знаю, что внутри GridMap уже реализованы "чанки", но они влияют только на frustum culling и тени.
Для домиков однозначно создам отдельные GridMap, чтобы скрывать или заменять их целиком, т.к. там нужно куда меньшее разрешение сетки, чем тут, и по одному блоку редактировать будет очень долго.
Я смотрел документацию на 4.0, там вроде мало что в GridMap поменялось в плане API, но непонятно на счёт LODов. Для обычных мешей в 4.0 уже есть автолоды, а что с GridMap? Знает кто? Не хочется делать велосипед, если в 4.0 уже есть готовое решение. Пока доделаю свой велосипед, уже будет релиз 4.0, лол)
Только теперь нужно старый код переделывать. И этот рефакторить. Только теперь уже думаю, что нужно было делать по-другому, соединять x12 меши в x24 меши процедурно по мере необходимости, потому что сейчас очень много избыточных вычислений и вызовов процедур получается; лучше уж пожертвовать оперативной памятью ради скорости, а на диске будет по-прежнему компактно. И ещё до сих пор непонятно, что лучше: работать с одним большим GridMap на весь мир или создавать по одному GridMap на каждый чанк? Ведь смена LOD будет проще, если можно просто заменить MeshLibrary, не трогая блоки GridMap? Я знаю, что внутри GridMap уже реализованы "чанки", но они влияют только на frustum culling и тени.
Для домиков однозначно создам отдельные GridMap, чтобы скрывать или заменять их целиком, т.к. там нужно куда меньшее разрешение сетки, чем тут, и по одному блоку редактировать будет очень долго.
Я смотрел документацию на 4.0, там вроде мало что в GridMap поменялось в плане API, но непонятно на счёт LODов. Для обычных мешей в 4.0 уже есть автолоды, а что с GridMap? Знает кто? Не хочется делать велосипед, если в 4.0 уже есть готовое решение. Пока доделаю свой велосипед, уже будет релиз 4.0, лол)
>>13712 (Del)
У них разные области применения.
Area проверяет пересечение определённого объёма с другими объектами и объёмами. Их взаимное расположение значения для Area не имеет, она сообщает все пересечения.
RayCast проверяет пересечение луча из одной точки в направлении другой точки. Первый попавшийся на пути объект пресекает луч, т.о. луч обнаруживает только одно столкновение.
Но иногда лучше иметь что-то среднее - объёмный рейкаст, т.е. чтобы луч имел толщину, выходил из одной точки в направлении другой, и сообщал подробную информацию о первом столкновении, а не просто процент пройденного расстояния до столкновения.
>чем рей лучше ареа
У них разные области применения.
Area проверяет пересечение определённого объёма с другими объектами и объёмами. Их взаимное расположение значения для Area не имеет, она сообщает все пересечения.
RayCast проверяет пересечение луча из одной точки в направлении другой точки. Первый попавшийся на пути объект пресекает луч, т.о. луч обнаруживает только одно столкновение.
Но иногда лучше иметь что-то среднее - объёмный рейкаст, т.е. чтобы луч имел толщину, выходил из одной точки в направлении другой, и сообщал подробную информацию о первом столкновении, а не просто процент пройденного расстояния до столкновения.
Годаны, есть ли среди вас полуночники?
Вкидываю тезис для мозгового штурма, а сам ухожу спать.
В общем, есть массив с векторами2, это контрольный массив, описывающий кривую линию сварочный шов, и есть второй массив с векторами2, который наелозил мышкой игрок. Массивы разной длины. Нужно их сравнить геометрически и рассчитать величину "непохожести" массивов, чтобы рассчитать полученные игроком очки. Как бы вы решили такую задачу?
Вкидываю тезис для мозгового штурма, а сам ухожу спать.
В общем, есть массив с векторами2, это контрольный массив, описывающий кривую линию сварочный шов, и есть второй массив с векторами2, который наелозил мышкой игрок. Массивы разной длины. Нужно их сравнить геометрически и рассчитать величину "непохожести" массивов, чтобы рассчитать полученные игроком очки. Как бы вы решили такую задачу?
Ребятки, помогите с решением задачи:
Начал осваивать годо (навыков в программировании 0, но когда то садился за С#, так что некоторое понимание все таки есть). Как полагается полез на ютуб, и сделал движение персонажа по гайдику.
Потом был большой перерыв, и я вернувшись решил присрать своими силами прыжок, но он происходил только при нажатии wasd клавиш, при движении то есть. Начал смотреть код, и выяснил что автор ролика вызывал функцию движения только тогда, когда были нажаты клавиши (а прыжок я прописал в эту функцию).
Так вот, почему он сделал так? Я убрал это условие вызова функции движения и все заработало нормально. Но не будет ли это в перспективе слишком нагружать систему?
Движение он сделал так: при нажатии, например, клавиш A/D Vector2.х принимает значения от -1 до 1, а само смещение капсюля происходит уже по формуле исходя из этих значений.
Не слишком ли это мудреный способ, и стоит ли просто по нажатию напрямую смещать героя?
Надеюсь понятно написал.
Начал осваивать годо (навыков в программировании 0, но когда то садился за С#, так что некоторое понимание все таки есть). Как полагается полез на ютуб, и сделал движение персонажа по гайдику.
Потом был большой перерыв, и я вернувшись решил присрать своими силами прыжок, но он происходил только при нажатии wasd клавиш, при движении то есть. Начал смотреть код, и выяснил что автор ролика вызывал функцию движения только тогда, когда были нажаты клавиши (а прыжок я прописал в эту функцию).
Так вот, почему он сделал так? Я убрал это условие вызова функции движения и все заработало нормально. Но не будет ли это в перспективе слишком нагружать систему?
Движение он сделал так: при нажатии, например, клавиш A/D Vector2.х принимает значения от -1 до 1, а само смещение капсюля происходит уже по формуле исходя из этих значений.
Не слишком ли это мудреный способ, и стоит ли просто по нажатию напрямую смещать героя?
Надеюсь понятно написал.
>>14218
Не зацикливайся на одном источнике инфы, сравнивай разные, выявляй суть, отбрасывай ошибочные источники. Из твоего поста получается, что ты воспринимаешь ютубера как гуру кодинга, хотя ютуберы на 90% снимают развлекательный контент, не предназначенный для реального девелопа.
Далее опишу, как я понимаю алгоритм:
Не зацикливайся на одном источнике инфы, сравнивай разные, выявляй суть, отбрасывай ошибочные источники. Из твоего поста получается, что ты воспринимаешь ютубера как гуру кодинга, хотя ютуберы на 90% снимают развлекательный контент, не предназначенный для реального девелопа.
Далее опишу, как я понимаю алгоритм:
>>14218
Не занимайся преждевременной опиимизацией. Один персонаж платформера не нагружает комп.
Не занимайся преждевременной опиимизацией. Один персонаж платформера не нагружает комп.
>>14247
Перво наперво запомним наизусть, что вся игровая логика основана на главном цикле (mainloop). Это когда движок за тебя написал
Вот многоточие это наши с тобой скрипты внутри движка. И все они привязаны к шагу этого бесконечного цикла, в течение этого шага движок делает много важных дел, но главное, что он делает, отрисовывает один фрейм графики и отдаёт его компу. Поэтому шаги-итерации главного цикла в большинстве случаев называют фреймами. Ты часто это будешь встречать в инструкциях и обсуждениях.
Ну а теперь, когда мы разобрались с базой, вот алгоритм движения персонажа:
1. Получить нажатые клавиши движения через Input.get_action_strength("вправо") - Input.get_action_strength("влево") благодаря этой формуле лево будет с минусом автоматически, и при нажатии обоих клавиш ввод обнулится, что исключит лаги и глитчи.
2. Получить нажатую клавишу прыжка через Input.is_action_pressed("прыжок")
3. ...
Блять. Если я дальше продолжу без стейтмашин, я уподоблюсь ютуберам, которых ты смотришь. А описывать контроллер на стейтмашине мне впадлу. Короче, кури мануалы из шапки.
Перво наперво запомним наизусть, что вся игровая логика основана на главном цикле (mainloop). Это когда движок за тебя написал
> while (appRunning == true) { ... }
Вот многоточие это наши с тобой скрипты внутри движка. И все они привязаны к шагу этого бесконечного цикла, в течение этого шага движок делает много важных дел, но главное, что он делает, отрисовывает один фрейм графики и отдаёт его компу. Поэтому шаги-итерации главного цикла в большинстве случаев называют фреймами. Ты часто это будешь встречать в инструкциях и обсуждениях.
Ну а теперь, когда мы разобрались с базой, вот алгоритм движения персонажа:
1. Получить нажатые клавиши движения через Input.get_action_strength("вправо") - Input.get_action_strength("влево") благодаря этой формуле лево будет с минусом автоматически, и при нажатии обоих клавиш ввод обнулится, что исключит лаги и глитчи.
2. Получить нажатую клавишу прыжка через Input.is_action_pressed("прыжок")
3. ...
Блять. Если я дальше продолжу без стейтмашин, я уподоблюсь ютуберам, которых ты смотришь. А описывать контроллер на стейтмашине мне впадлу. Короче, кури мануалы из шапки.
>>14250
Спасибо, понял.
>>14247
>>14258
Конечно я понимаю, что контентмейкеры далеко не идеал, а такие же бубони как я и лепят что попало из чего попало, лишь бы работало. Недаром у них много незавершенных проектов и они бесконечно правят свои ошибки в тех что есть.
Беру инфу из разных источников и отношусь критически, ага.
Но все таки интересно, почему же автор мог сделать условие для вызова функции движение? Мыслей никаких на этот счет? По моему очень странное решение, ведь если включить в нее прыжок, можно было висеть в воздухе пока не нажмешь wasd.
За ответы спасибо.
Спасибо, понял.
>>14247
>>14258
Конечно я понимаю, что контентмейкеры далеко не идеал, а такие же бубони как я и лепят что попало из чего попало, лишь бы работало. Недаром у них много незавершенных проектов и они бесконечно правят свои ошибки в тех что есть.
Беру инфу из разных источников и отношусь критически, ага.
Но все таки интересно, почему же автор мог сделать условие для вызова функции движение? Мыслей никаких на этот счет? По моему очень странное решение, ведь если включить в нее прыжок, можно было висеть в воздухе пока не нажмешь wasd.
За ответы спасибо.
ДОРОВ.
Насколько сильно ноды влияют на память? Например у меня условно будет Creature, который будет через композицию/агрегацию состоять из 15-30 нод, офк я не буду как долбоёб кажую ноду процессить каждый тик, а логику очень хитровыебанным способом раскидаю по планировщикам и очередям. Но хуй бы с ним. Теперь представим что я нахуяил несколько тысяч таких криачерусов (офк cache coherency сразу нахуй), вопрос тут сразу в том, наскольк хуево будет с памятью, по сравнению с вариантом где я например тех же кричерство не из 20-30 разных но маленьких универсальных компонентов сделаю, а из 3-5 жирных монолитных компонентов?
Насколько сильно ноды влияют на память? Например у меня условно будет Creature, который будет через композицию/агрегацию состоять из 15-30 нод, офк я не буду как долбоёб кажую ноду процессить каждый тик, а логику очень хитровыебанным способом раскидаю по планировщикам и очередям. Но хуй бы с ним. Теперь представим что я нахуяил несколько тысяч таких криачерусов (офк cache coherency сразу нахуй), вопрос тут сразу в том, наскольк хуево будет с памятью, по сравнению с вариантом где я например тех же кричерство не из 20-30 разных но маленьких универсальных компонентов сделаю, а из 3-5 жирных монолитных компонентов?
>>14352
Забыл указать что эти 20-30 нод, будут унаследованы от Node, и будут иметь функционал больше для хранения данных + некоторфе функции для удобства работы с этими данными. Основной код скорее всего будет в планировщиках которые будут этих кричерсов и в хвост и в гриву. Ну может окромя базы типа передвижения и других хай перфоманс залуп.
Забыл указать что эти 20-30 нод, будут унаследованы от Node, и будут иметь функционал больше для хранения данных + некоторфе функции для удобства работы с этими данными. Основной код скорее всего будет в планировщиках которые будут этих кричерсов и в хвост и в гриву. Ну может окромя базы типа передвижения и других хай перфоманс залуп.
>>14029
Классическая https://ru.wikipedia.org/wiki/Проблема_XY
Твоя реальная задача:
Предлагаю сделать так. Каждая точка будущего сварного шва ожидает клика мышкой в достаточной близости от себя (или чтобы кнопка мыши была зажата, когда курсор мыши проходит мимо этой точки). Если клик мыши был достаточно близко (или достаточно близко прошёл курсор с зажатой кнопкой), точка засчитывает событие "я правильно сварена" и прекращает реагировать на мышь. Чтобы получить максимум очков, нужно сварить все точки, т.е. кликнуть (или провести курсором) достаточно близко от каждой из точек. Точки могут быть невидимыми или отображаться как отрезки линии, но по сути мы имеем дело с окружностями (точка + радиус срабатывания сварки).
Можно добавить ограничения, например, снимать очки за каждый клик, который не был зарегистрирован ни одной из ещё не сваренных точек, или был зарегистрирован уже сваренной точкой. Или поставить ограничение на время, за которое нужно сварить как можно больше точек шва. Формула результата может быть сколь угодно сложной, но основа одна - точки-датчики.
В плане реализации не нужны даже массивы с координатами точек и кликов. Можно тупо расставить кучу Area2D и соединить их сигналами со скриптом, подсчитывающим результат. У каждой Area2D может быть свой спрайт, который отображается в случае успешного сваривания её участка/точки. Точки неудачной сварки (мимо) могут отображаться спавном дополнительных спрайтов в случае если клик прошёл мимо одной из Area2D. В 3D всё аналогично, только там будет эффективнее использовать мультимеш.
Классическая https://ru.wikipedia.org/wiki/Проблема_XY
Твоя реальная задача:
>Есть сварочный шов, который наелозил мышкой игрок.
>Нужно рассчитать полученные игроком очки.
Предлагаю сделать так. Каждая точка будущего сварного шва ожидает клика мышкой в достаточной близости от себя (или чтобы кнопка мыши была зажата, когда курсор мыши проходит мимо этой точки). Если клик мыши был достаточно близко (или достаточно близко прошёл курсор с зажатой кнопкой), точка засчитывает событие "я правильно сварена" и прекращает реагировать на мышь. Чтобы получить максимум очков, нужно сварить все точки, т.е. кликнуть (или провести курсором) достаточно близко от каждой из точек. Точки могут быть невидимыми или отображаться как отрезки линии, но по сути мы имеем дело с окружностями (точка + радиус срабатывания сварки).
Можно добавить ограничения, например, снимать очки за каждый клик, который не был зарегистрирован ни одной из ещё не сваренных точек, или был зарегистрирован уже сваренной точкой. Или поставить ограничение на время, за которое нужно сварить как можно больше точек шва. Формула результата может быть сколь угодно сложной, но основа одна - точки-датчики.
В плане реализации не нужны даже массивы с координатами точек и кликов. Можно тупо расставить кучу Area2D и соединить их сигналами со скриптом, подсчитывающим результат. У каждой Area2D может быть свой спрайт, который отображается в случае успешного сваривания её участка/точки. Точки неудачной сварки (мимо) могут отображаться спавном дополнительных спрайтов в случае если клик прошёл мимо одной из Area2D. В 3D всё аналогично, только там будет эффективнее использовать мультимеш.
>>14218
Во-первых, покажи код. Свой и его. Скриншотами.
Во-вторых,
А почему ТЫ прописал прыжок в функцию движения?
Предполагаю такой код:
Ты за каким-то фигом добавил прыжок в move()?
На деле у тебя должно было быть так:
Т.е. нужно разделить разные по смыслу действия.
>>14342
Чтобы не было лишнего вызова функции, когда движение тебе не нужно, разве не так? А вообще, ты код не показал, как мы тебе должны сказать, что там и почему?
Странное решение - это включать в код горизонтального движения код для вертикального движения. Это разные вещи (в абсолютном большинстве игр, где есть "земная" гравитация).
Во-первых, покажи код. Свой и его. Скриншотами.
Во-вторых,
>вызывал функцию движения только тогда, когда были нажаты клавиши (а прыжок я прописал в эту функцию).
>Так вот, почему он сделал так?
А почему ТЫ прописал прыжок в функцию движения?
Предполагаю такой код:
>func _input...:
>_ if is_action...(...):
>_ _ move(...)
Ты за каким-то фигом добавил прыжок в move()?
На деле у тебя должно было быть так:
>func _input...:
>_ if is_action...(...):
>_ _ move(...)
>_ if is_action...(...):
>_ _ jump(...)
Т.е. нужно разделить разные по смыслу действия.
>>14342
>Но все таки интересно, почему же автор мог сделать условие для вызова функции движение?
Чтобы не было лишнего вызова функции, когда движение тебе не нужно, разве не так? А вообще, ты код не показал, как мы тебе должны сказать, что там и почему?
>По моему очень странное решение, ведь если включить в нее прыжок
Странное решение - это включать в код горизонтального движения код для вертикального движения. Это разные вещи (в абсолютном большинстве игр, где есть "земная" гравитация).
>>14352
Зависит от типа ноды. Вообще, намного острее проблема производительности на десятках тысяч нод, чем память. Памяти сегодня у всех минимум 8 ГБ (лол, даже в смартфонах), а вот производительность одного ядра уже много лет как перестала расти, поэтому Интел, АМД и АРМ начали изобретать многоядерных монстров. Поскольку дерево сцены обрабатывается в цикле одним ядром, нельзя делать слишком большое дерево.
25x4000=100000, получаем просадку фпс ниже играбельности при не очень заметном потреблении оперативной памяти.
>>14354
Почитай это:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Если ты будешь генерировать всех существ только через код, тебе достаточно делать компоненты как потомки Reference.
Если тебе необходимо настраивать существ через инспектор нод, тогда делай компоненты потомками Resource.
Потомок Node нужен только если тебе нужно сгруппировать что-то непосредственно в дереве сцены или ты планируешь когда-нибудь сменить тип на другой, либо ранее эта нода имела другой тип и её наличие в сцене - остаток прошлого дизайна. Или если ты делаешь своего рода синглтон/глобальный менеджер.
Теоретически для компонентов достаточно сделать так:
После чего в инспекторе можно будет накидать в этот массив любые кастомные компоненты, наследующиеся от Resource. Компоненты можно создавать в файловой системе (пкм - new resource) или сохранять в файл из инспектора (save as).
>Насколько сильно ноды влияют на память?
Зависит от типа ноды. Вообще, намного острее проблема производительности на десятках тысяч нод, чем память. Памяти сегодня у всех минимум 8 ГБ (лол, даже в смартфонах), а вот производительность одного ядра уже много лет как перестала расти, поэтому Интел, АМД и АРМ начали изобретать многоядерных монстров. Поскольку дерево сцены обрабатывается в цикле одним ядром, нельзя делать слишком большое дерево.
>несколько тысяч таких
25x4000=100000, получаем просадку фпс ниже играбельности при не очень заметном потреблении оперативной памяти.
>маленьких универсальных компонентов
>>14354
>будут иметь функционал больше для хранения данных + некоторфе функции для удобства работы с этими данными
Почитай это:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Если ты будешь генерировать всех существ только через код, тебе достаточно делать компоненты как потомки Reference.
Если тебе необходимо настраивать существ через инспектор нод, тогда делай компоненты потомками Resource.
Потомок Node нужен только если тебе нужно сгруппировать что-то непосредственно в дереве сцены или ты планируешь когда-нибудь сменить тип на другой, либо ранее эта нода имела другой тип и её наличие в сцене - остаток прошлого дизайна. Или если ты делаешь своего рода синглтон/глобальный менеджер.
Теоретически для компонентов достаточно сделать так:
>export var components: Array
После чего в инспекторе можно будет накидать в этот массив любые кастомные компоненты, наследующиеся от Resource. Компоненты можно создавать в файловой системе (пкм - new resource) или сохранять в файл из инспектора (save as).
>>14446
Чот не понимаю, ноды которые не тикают как ебанутые всё равно жрут процессор? ВТФ.
Мусёсь грасись.
Но мне бы понадобился инспектор со свойствами чтобы не педалировать свой десериализатор через жсон файлы. Хотя хз, может это и не такая плохая идея.
Базанул хорошо, я даже тредшот сделаю.
>острее проблема производительности на десятках тысяч нод
Чот не понимаю, ноды которые не тикают как ебанутые всё равно жрут процессор? ВТФ.
>https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Мусёсь грасись.
Но мне бы понадобился инспектор со свойствами чтобы не педалировать свой десериализатор через жсон файлы. Хотя хз, может это и не такая плохая идея.
Базанул хорошо, я даже тредшот сделаю.
>>14446
Еще про ресурсы вот хорошо. То есть можно к ноде пришляпать хоть 100 ресурсов, Например я даже сделаю сцену, которая будет инхеритнута или напрямую скопирована с ГЕНЕРИК зомби, который будет состоять из 3-7 нод, на которых уже будут висеть разные виды ресурсов с дефолтными значениями, которые я предварительно нахуячу в крестах. Потом я могу спокойно делать также любые шаблоны, накидывать ресурсы (которые просто могут быть сборищем циферок) на любых существ. То есть для зомби например шобы создать любой шабло я просто опять же инхеричу его, могу в инспекторе поменять ему ЕБАЛО, размер хуя, долг по ипотеке и всё это схоронить, также потом инстанцировать и т.д.
Ебать а у годота таки оч мощная схема данных.
А в каком виде в памяти ресурсы одного вида хранятся? Рядом с нодой или один вид в кеш-линии валяется?
Еще про ресурсы вот хорошо. То есть можно к ноде пришляпать хоть 100 ресурсов, Например я даже сделаю сцену, которая будет инхеритнута или напрямую скопирована с ГЕНЕРИК зомби, который будет состоять из 3-7 нод, на которых уже будут висеть разные виды ресурсов с дефолтными значениями, которые я предварительно нахуячу в крестах. Потом я могу спокойно делать также любые шаблоны, накидывать ресурсы (которые просто могут быть сборищем циферок) на любых существ. То есть для зомби например шобы создать любой шабло я просто опять же инхеричу его, могу в инспекторе поменять ему ЕБАЛО, размер хуя, долг по ипотеке и всё это схоронить, также потом инстанцировать и т.д.
Ебать а у годота таки оч мощная схема данных.
А в каком виде в памяти ресурсы одного вида хранятся? Рядом с нодой или один вид в кеш-линии валяется?
26 Кб, 904x199>>14441
У автора таким способом вызывалась функция движения. С такими условиями.
Вот ты ответил мне, и неочевидное стало очевидным. Буду теперь разминать мозгу и думать как сделать нормально. Спасибр!
У автора таким способом вызывалась функция движения. С такими условиями.
Вот ты ответил мне, и неочевидное стало очевидным. Буду теперь разминать мозгу и думать как сделать нормально. Спасибр!
>>14449
Я не знаю точно, но, вроде бы, стандартная реализация SceneTree не оптимизирует обход дерева. Поэтому рекомендуют в случае необходимости в большом количестве нод отказываться от нод в пользу прямого использования низкоуровневых API, которые в Годо называются "серверы".
Если ты про сохранение мира с тысячами сущностей и десятками тысяч компонентов, то, мне кажется, лучше сразу задуматься о собственном бинарном формате, не полагаясь на универсальные средства... Алсо, так ли уж нужно их сохранять? Ты делаешь опенворлд песочницу с симуляцией жизни?
>>14452
Я не знаю точно, но скорее всего никаких оптимизаций там нет. Рассматривай Resource как простые экземпляры ООП класса. Они отличаются от Object только счётчиком ссылок (т.к. потомки Reference) и функциями сериализации.
Главное понимать, что если ты копипастишь один ресурс или вставляешь его "из файла" в несколько нод, то это будет один общий ресурс, а не независимые копии. Чтобы получились независимые копии, нужно в инспекторе нажать make unique или в коде вызвать duplicate() и сохранить куда-нибудь результат. В противном случае редактирование ресурса в одной ноде изменит его и в других, перезаписав данные в файле .tres/.tscn. Однако, благодаря этому ты можешь как бы иметь много одинаковых компонентов во множестве разных сущностей, не создавая лишних экземпляров класса, как в случае с копипастом потомков Node по веткам дерева сцены. При загрузке из файла через ResourceLoader.load() непосредственно чтение с диска происходит только первый раз, потом возвращается ссылка на уже загруженный ресурс, это тоже нужно учитывать и использовать .duplicate() при необходимости.
>Чот не понимаю, ноды которые не тикают как ебанутые всё равно жрут процессор? ВТФ.
Я не знаю точно, но, вроде бы, стандартная реализация SceneTree не оптимизирует обход дерева. Поэтому рекомендуют в случае необходимости в большом количестве нод отказываться от нод в пользу прямого использования низкоуровневых API, которые в Годо называются "серверы".
>Но мне бы понадобился инспектор со свойствами чтобы не педалировать свой десериализатор через жсон файлы.
Если ты про сохранение мира с тысячами сущностей и десятками тысяч компонентов, то, мне кажется, лучше сразу задуматься о собственном бинарном формате, не полагаясь на универсальные средства... Алсо, так ли уж нужно их сохранять? Ты делаешь опенворлд песочницу с симуляцией жизни?
>>14452
>А в каком виде в памяти ресурсы одного вида хранятся? Рядом с нодой или один вид в кеш-линии валяется?
Я не знаю точно, но скорее всего никаких оптимизаций там нет. Рассматривай Resource как простые экземпляры ООП класса. Они отличаются от Object только счётчиком ссылок (т.к. потомки Reference) и функциями сериализации.
Главное понимать, что если ты копипастишь один ресурс или вставляешь его "из файла" в несколько нод, то это будет один общий ресурс, а не независимые копии. Чтобы получились независимые копии, нужно в инспекторе нажать make unique или в коде вызвать duplicate() и сохранить куда-нибудь результат. В противном случае редактирование ресурса в одной ноде изменит его и в других, перезаписав данные в файле .tres/.tscn. Однако, благодаря этому ты можешь как бы иметь много одинаковых компонентов во множестве разных сущностей, не создавая лишних экземпляров класса, как в случае с копипастом потомков Node по веткам дерева сцены. При загрузке из файла через ResourceLoader.load() непосредственно чтение с диска происходит только первый раз, потом возвращается ссылка на уже загруженный ресурс, это тоже нужно учитывать и использовать .duplicate() при необходимости.
>>14544
Видать так и придется
Да, но пока только к движку примеряюсь. Был выбор между юнити ДОТС, Чисто JS + Deno + игра в браузере и годотя.
Первый сырой, второй испытывает проблемы в мемори хуйне да и вообще JS...
Ну то есть из этого можно сделать вывод что напрямую использовать ресурсы как префабы не есть гуд, так как будет стремительно расти потреблените памяти для инициализации каждой независимой копии ресурса даже если просто одну циферку поменять надо. Да, в годоте с дата флоу не густо. Еще и автор godex нахуевертил да перестал разрабатывать. Но он вообще странный дядька, я ему охуенную менюху нарисовал для планировщика систем но он чот не СМОГ видимо. лучше бы flecs интегрировал чем свой костыльный ECS пилил.
Спасибо за пояснения.
>Если ты про сохранение мира с тысячами сущностей и десятками тысяч компонентов, то, мне кажется, лучше сразу задуматься о собственном бинарном формате, не полагаясь на универсальные средства
Видать так и придется
>Ты делаешь опенворлд песочницу с симуляцией жизни?
Да, но пока только к движку примеряюсь. Был выбор между юнити ДОТС, Чисто JS + Deno + игра в браузере и годотя.
Первый сырой, второй испытывает проблемы в мемори хуйне да и вообще JS...
>Главное понимать, что если ты копипастишь ...
Ну то есть из этого можно сделать вывод что напрямую использовать ресурсы как префабы не есть гуд, так как будет стремительно расти потреблените памяти для инициализации каждой независимой копии ресурса даже если просто одну циферку поменять надо. Да, в годоте с дата флоу не густо. Еще и автор godex нахуевертил да перестал разрабатывать. Но он вообще странный дядька, я ему охуенную менюху нарисовал для планировщика систем но он чот не СМОГ видимо. лучше бы flecs интегрировал чем свой костыльный ECS пилил.
Спасибо за пояснения.
>>14563
Не понял...
У тебя возможны всего две ситуации:
1. Тебе нужен статичный набор данных, одинаковый для всех похожих сущностей. Тогда ты берёшь ссылку на ресурс и считываешь из него данные в разных сущностях, экономя память.
2. Тебе нужен контейнер для данных, который будет содержать разные данные для разных сущностей. Тогда ты создаёшь копии одного ресурса, которые не будут влиять друг на друга.
Как ты скомбинируешь друг с другом эти два подхода - зависит от тебя и твоей задачи. Можешь, например, создать 6 ресурсов расы, каждый из которых содержит статичные данные, одинаковые для всех представителей расы. А уже каждый отдельный юнит содержит в себе дополнительный ресурс с индивидуальными характеристиками, которые складываются со стандартными для расы. Допустим, есть два юнита из расы 2, у одного нос побольше, а у другого поменьше, но они оба зависят от размера носа своей расы, и если ты увеличишь нос расы 2, оба юнита увеличат нос, но сохранят разницу друг относительно друга (были 5 см и 7 см, стали 6 см и 8 см, базовый нос их расы был 6 см и стал 7 см).
Во-первых, если тебе настолько важна эффективность ещё до начала работы, почему бы тогда не взять низкоуровневый Си или вообще какой-нибудь ассемблер, чтобы иметь контроль за каждым байтом? Тебе же, похоже, не нужен 3D движок, раз ты рассматривал делать игру в браузере с нуля на JS.
Во-вторых, почему бы не набросать по-быстрому на Godot прототип с малым количеством объектов, чтобы оценить свои задумки, а в случае успеха переписать на голый C/ассемблер, чтобы выжать из железа максимум возможностей для реального проекта? Так ты хотя бы не убьёшь несколько месяцев на изначально провальную задумку, которая покажет свои недостатки ещё в малом масштабе.
Кто бы мне это всё говорил...
>так как будет стремительно расти потреблените памяти для инициализации каждой независимой копии ресурса даже если просто одну циферку поменять надо
Не понял...
У тебя возможны всего две ситуации:
1. Тебе нужен статичный набор данных, одинаковый для всех похожих сущностей. Тогда ты берёшь ссылку на ресурс и считываешь из него данные в разных сущностях, экономя память.
2. Тебе нужен контейнер для данных, который будет содержать разные данные для разных сущностей. Тогда ты создаёшь копии одного ресурса, которые не будут влиять друг на друга.
Как ты скомбинируешь друг с другом эти два подхода - зависит от тебя и твоей задачи. Можешь, например, создать 6 ресурсов расы, каждый из которых содержит статичные данные, одинаковые для всех представителей расы. А уже каждый отдельный юнит содержит в себе дополнительный ресурс с индивидуальными характеристиками, которые складываются со стандартными для расы. Допустим, есть два юнита из расы 2, у одного нос побольше, а у другого поменьше, но они оба зависят от размера носа своей расы, и если ты увеличишь нос расы 2, оба юнита увеличат нос, но сохранят разницу друг относительно друга (были 5 см и 7 см, стали 6 см и 8 см, базовый нос их расы был 6 см и стал 7 см).
>Да, но пока только к движку примеряюсь.
>Чисто JS + Deno + игра в браузере
Во-первых, если тебе настолько важна эффективность ещё до начала работы, почему бы тогда не взять низкоуровневый Си или вообще какой-нибудь ассемблер, чтобы иметь контроль за каждым байтом? Тебе же, похоже, не нужен 3D движок, раз ты рассматривал делать игру в браузере с нуля на JS.
Во-вторых, почему бы не набросать по-быстрому на Godot прототип с малым количеством объектов, чтобы оценить свои задумки, а в случае успеха переписать на голый C/ассемблер, чтобы выжать из железа максимум возможностей для реального проекта? Так ты хотя бы не убьёшь несколько месяцев на изначально провальную задумку, которая покажет свои недостатки ещё в малом масштабе.
Кто бы мне это всё говорил...
>>14600
Не, это я уже рассматривал. Я понял что байтоебство тут не обязательно, достаточно просто не быть доллбоёбом и делать оптимальные алгоритмы, планировщики задач. Например у тебя есть 10 ящиков говяжъих анусов которые тикают постоянно и спрашивают Я ИСПОРТИЛСЯ? Я ИСПОРТИЛСЯ? Это говно полное. в планировщике ставишь задачу на этот продкт, чтобы его состояние например спросили через 1 час игрового времени. далее оптимизякай планировщик. Но конечно это очень примитивный пример, потому что состояние его может еще измениться до проверки, например жарко станет и он должн сгнить быстрее. Но это уже нужно хууярить кросс-события, и прочая шелупонь, и еще надо сделать удобный для будущего использования фреймворк.
JS + Браузер это очень удобно и просто в этом плане. Мне нужно просто 2Д плюс возможность модифицировать SVG. Офк я не собирался прямо на СВГ хуярить персонажей, они в картинки перегоняются и кешируются по сурс параметрам, но JS сука тварь если брать его эффективность по памяти.
Чистый C это хорошо, особенно тем что можно во flecs но у него внешней модифицируемости изначально почти нет. Я конечно не особо верю шо проект доживет шо к нему захотят моды делать, но в базу хотелось именно это заложить. Вон посмотри на Cataclysm DDA, если бы он на сисяпах и даж кастомном рендере написан был, его можно было бы и в хвост и в гриву, а так только JSON, да еще и куквин (текущий автор) выпилил нахой ЛУА из него.
Годот я думаю тут мог бы вывезти, потому что у него есть потанцевал на переписывание шибко нагруженных мест потом на С++ код не снимая свитер. Много где такого себе не позволить.
Имеется ввиду как раз вторая описанная тобою ситуация, но возведена в градус, когда у тебя оч много существ (ну давай пару тыщ для начала) и предметов имеют ресурс с почти у всех уникальными значениями. Опять сёр по памяти? Нахуя постоянно (а то и не очень меняющиеся, по разному) меняющиеся параметры хранить отдельно для каждого ебланчика, в таком жирном объекте как ресурс. Можно было подумать, да захуярь просто в скрипт эти данные да и всё, но при этом тоже в коде может начаться каша. Или я чего-то не понимаю. Да и каким методом тот или иной ресурс сериализуется? если он уникален, все его данные изначально находятся в .tscn, или он где-то в другом месте.
Кароче как всегда ёбань.
> голый C/ассемблер
Не, это я уже рассматривал. Я понял что байтоебство тут не обязательно, достаточно просто не быть доллбоёбом и делать оптимальные алгоритмы, планировщики задач. Например у тебя есть 10 ящиков говяжъих анусов которые тикают постоянно и спрашивают Я ИСПОРТИЛСЯ? Я ИСПОРТИЛСЯ? Это говно полное. в планировщике ставишь задачу на этот продкт, чтобы его состояние например спросили через 1 час игрового времени. далее оптимизякай планировщик. Но конечно это очень примитивный пример, потому что состояние его может еще измениться до проверки, например жарко станет и он должн сгнить быстрее. Но это уже нужно хууярить кросс-события, и прочая шелупонь, и еще надо сделать удобный для будущего использования фреймворк.
JS + Браузер это очень удобно и просто в этом плане. Мне нужно просто 2Д плюс возможность модифицировать SVG. Офк я не собирался прямо на СВГ хуярить персонажей, они в картинки перегоняются и кешируются по сурс параметрам, но JS сука тварь если брать его эффективность по памяти.
Чистый C это хорошо, особенно тем что можно во flecs но у него внешней модифицируемости изначально почти нет. Я конечно не особо верю шо проект доживет шо к нему захотят моды делать, но в базу хотелось именно это заложить. Вон посмотри на Cataclysm DDA, если бы он на сисяпах и даж кастомном рендере написан был, его можно было бы и в хвост и в гриву, а так только JSON, да еще и куквин (текущий автор) выпилил нахой ЛУА из него.
Годот я думаю тут мог бы вывезти, потому что у него есть потанцевал на переписывание шибко нагруженных мест потом на С++ код не снимая свитер. Много где такого себе не позволить.
>Не понял...
Имеется ввиду как раз вторая описанная тобою ситуация, но возведена в градус, когда у тебя оч много существ (ну давай пару тыщ для начала) и предметов имеют ресурс с почти у всех уникальными значениями. Опять сёр по памяти? Нахуя постоянно (а то и не очень меняющиеся, по разному) меняющиеся параметры хранить отдельно для каждого ебланчика, в таком жирном объекте как ресурс. Можно было подумать, да захуярь просто в скрипт эти данные да и всё, но при этом тоже в коде может начаться каша. Или я чего-то не понимаю. Да и каким методом тот или иной ресурс сериализуется? если он уникален, все его данные изначально находятся в .tscn, или он где-то в другом месте.
Кароче как всегда ёбань.
>>14600
Не, это я уже рассматривал. Я понял что байтоебство тут не обязательно, достаточно просто не быть доллбоёбом и делать оптимальные алгоритмы, планировщики задач. Например у тебя есть 10 ящиков говяжъих анусов которые тикают постоянно и спрашивают Я ИСПОРТИЛСЯ? Я ИСПОРТИЛСЯ? Это говно полное. в планировщике ставишь задачу на этот продкт, чтобы его состояние например спросили через 1 час игрового времени. далее оптимизякай планировщик. Но конечно это очень примитивный пример, потому что состояние его может еще измениться до проверки, например жарко станет и он должн сгнить быстрее. Но это уже нужно хууярить кросс-события, и прочая шелупонь, и еще надо сделать удобный для будущего использования фреймворк.
JS + Браузер это очень удобно и просто в этом плане. Мне нужно просто 2Д плюс возможность модифицировать SVG. Офк я не собирался прямо на СВГ хуярить персонажей, они в картинки перегоняются и кешируются по сурс параметрам, но JS сука тварь если брать его эффективность по памяти.
Чистый C это хорошо, особенно тем что можно во flecs но у него внешней модифицируемости изначально почти нет. Я конечно не особо верю шо проект доживет шо к нему захотят моды делать, но в базу хотелось именно это заложить. Вон посмотри на Cataclysm DDA, если бы он на сисяпах и даж кастомном рендере написан был, его можно было бы и в хвост и в гриву, а так только JSON, да еще и куквин (текущий автор) выпилил нахой ЛУА из него.
Годот я думаю тут мог бы вывезти, потому что у него есть потанцевал на переписывание шибко нагруженных мест потом на С++ код не снимая свитер. Много где такого себе не позволить.
Имеется ввиду как раз вторая описанная тобою ситуация, но возведена в градус, когда у тебя оч много существ (ну давай пару тыщ для начала) и предметов имеют ресурс с почти у всех уникальными значениями. Опять сёр по памяти? Нахуя постоянно (а то и не очень меняющиеся, по разному) меняющиеся параметры хранить отдельно для каждого ебланчика, в таком жирном объекте как ресурс. Можно было подумать, да захуярь просто в скрипт эти данные да и всё, но при этом тоже в коде может начаться каша. Или я чего-то не понимаю. Да и каким методом тот или иной ресурс сериализуется? если он уникален, все его данные изначально находятся в .tscn, или он где-то в другом месте.
Кароче как всегда ёбань.
> голый C/ассемблер
Не, это я уже рассматривал. Я понял что байтоебство тут не обязательно, достаточно просто не быть доллбоёбом и делать оптимальные алгоритмы, планировщики задач. Например у тебя есть 10 ящиков говяжъих анусов которые тикают постоянно и спрашивают Я ИСПОРТИЛСЯ? Я ИСПОРТИЛСЯ? Это говно полное. в планировщике ставишь задачу на этот продкт, чтобы его состояние например спросили через 1 час игрового времени. далее оптимизякай планировщик. Но конечно это очень примитивный пример, потому что состояние его может еще измениться до проверки, например жарко станет и он должн сгнить быстрее. Но это уже нужно хууярить кросс-события, и прочая шелупонь, и еще надо сделать удобный для будущего использования фреймворк.
JS + Браузер это очень удобно и просто в этом плане. Мне нужно просто 2Д плюс возможность модифицировать SVG. Офк я не собирался прямо на СВГ хуярить персонажей, они в картинки перегоняются и кешируются по сурс параметрам, но JS сука тварь если брать его эффективность по памяти.
Чистый C это хорошо, особенно тем что можно во flecs но у него внешней модифицируемости изначально почти нет. Я конечно не особо верю шо проект доживет шо к нему захотят моды делать, но в базу хотелось именно это заложить. Вон посмотри на Cataclysm DDA, если бы он на сисяпах и даж кастомном рендере написан был, его можно было бы и в хвост и в гриву, а так только JSON, да еще и куквин (текущий автор) выпилил нахой ЛУА из него.
Годот я думаю тут мог бы вывезти, потому что у него есть потанцевал на переписывание шибко нагруженных мест потом на С++ код не снимая свитер. Много где такого себе не позволить.
>Не понял...
Имеется ввиду как раз вторая описанная тобою ситуация, но возведена в градус, когда у тебя оч много существ (ну давай пару тыщ для начала) и предметов имеют ресурс с почти у всех уникальными значениями. Опять сёр по памяти? Нахуя постоянно (а то и не очень меняющиеся, по разному) меняющиеся параметры хранить отдельно для каждого ебланчика, в таком жирном объекте как ресурс. Можно было подумать, да захуярь просто в скрипт эти данные да и всё, но при этом тоже в коде может начаться каша. Или я чего-то не понимаю. Да и каким методом тот или иной ресурс сериализуется? если он уникален, все его данные изначально находятся в .tscn, или он где-то в другом месте.
Кароче как всегда ёбань.
>>14436
Вот моё решение Y:
КМК удобно, пока ведёшь мышкой с нажатой ЛКМ, электрод приложен и идёт сварка (пикча 1), координаты мышки с определенным шагом (магическое число 2 в строке 32 на данном этапе прототипирования) записываются в массив. Далее массивы отрисовываются на холсте (canvas) (пикча 2) (и это самая боль, эту функцию холста надо заменить на шейдер, но я не могу в шейдеры!).
Далее по этим координатам планируется действительно рисовать круги, потому что сварочный шов ИРЛ так и выглядит (пикча 3), как будто ты накладывал друг на друга сферы, которые вплавились в две заготовки сваривая их одной сваркой Am Dm.
Если игрок не попадает в предложенный игрой рисунок, круги начинает накладываться криво, с возрастающей пропорционально отклонению рандомизацией размера. Если игрок задерживает мышку, игра симулирует прилипание электрода.
Всё это только предстоит накодить.
А ещё прогрессбары!
- Длина электрода, после истечения которой нужно сыграть в мини-игру замены электрода.
- Перегрев инвертора, когда электрод прилип. Заполнение прогрессбара = выход из строя и геймовер.
> Предлагаю сделать так.
Вот моё решение Y:
КМК удобно, пока ведёшь мышкой с нажатой ЛКМ, электрод приложен и идёт сварка (пикча 1), координаты мышки с определенным шагом (магическое число 2 в строке 32 на данном этапе прототипирования) записываются в массив. Далее массивы отрисовываются на холсте (canvas) (пикча 2) (и это самая боль, эту функцию холста надо заменить на шейдер, но я не могу в шейдеры!).
Далее по этим координатам планируется действительно рисовать круги, потому что сварочный шов ИРЛ так и выглядит (пикча 3), как будто ты накладывал друг на друга сферы, которые вплавились в две заготовки сваривая их одной сваркой Am Dm.
Если игрок не попадает в предложенный игрой рисунок, круги начинает накладываться криво, с возрастающей пропорционально отклонению рандомизацией размера. Если игрок задерживает мышку, игра симулирует прилипание электрода.
Всё это только предстоит накодить.
А ещё прогрессбары!
- Длина электрода, после истечения которой нужно сыграть в мини-игру замены электрода.
- Перегрев инвертора, когда электрод прилип. Заполнение прогрессбара = выход из строя и геймовер.
>>14777
AFAIK эти кружочки еще и разного размера должны быть, исходя из того насколько десятых секунд ты затупил электродом на одном месте. Но это не точно.
AFAIK эти кружочки еще и разного размера должны быть, исходя из того насколько десятых секунд ты затупил электродом на одном месте. Но это не точно.
Как сделать так чтобы C# скрипты открывались в visual studio 2022 и чтобы ясен пень все работало - типа подстановок, интелисенцев, и т.д.?
>>14802
Да.
Да.
>>14777
Потихонечку, помаленечку, что-то получается. Хуярю брутфорсом, без попыток вникнуть в матан.
Потихонечку, помаленечку, что-то получается. Хуярю брутфорсом, без попыток вникнуть в матан.
>>12254
Ого, прям как у меня, вот только gimp это недопрограмма. Крита лучший редактор изображений, интуитивный и понятный интерфейс (на подобии устоявшейся фотошоповской экосистемы), все делаю в ней (кроме создания материалов, их уже в substance designer, нативная версия которой есть для бубунт). Мечта!
Ого, прям как у меня, вот только gimp это недопрограмма. Крита лучший редактор изображений, интуитивный и понятный интерфейс (на подобии устоявшейся фотошоповской экосистемы), все делаю в ней (кроме создания материалов, их уже в substance designer, нативная версия которой есть для бубунт). Мечта!
Меня заинтересовал движочек. Что посоветуете делать? С радостью бы вкатился в компашку какую нибудь которая что то двухмерное пилит на Годо. Могу вам римовать всякое. А вы мне за всякие приколюхи движка бы пояснили. Но если таких благотворителей нет то чего и как с ним разбираться? Желательно с скорейшим переходом к практике.
Мальчишечки. Вот я установил ваш годот создал новый проект. Сделал сцену с Button которая меняет text в Label. Но при попытки запуска вылезает "Не назначена главная сцена хотите выбрать...."
когда нажимаю на выбрать, то открывается res/import и все. Ничего выбрать или создать не могу. Подскажите что делать(
когда нажимаю на выбрать, то открывается res/import и все. Ничего выбрать или создать не могу. Подскажите что делать(
>>20353
Читать документацию:
https://docs.godotengine.org/en/stable/index.html
Там есть туториалы для новичков.
Спрашивай в тред >>815359 (OP), если возникнут какие-то вопросы.
>>20835
Нужно выбрать .tscn файл. Подробнее можно прочитать в документации.
Не понял, что открывается? Если у тебя нет .tscn файла, нужно сначала сохранить сцену в .tscn формат (или .scn, но .tscn лучше). Навигация в файловом браузере Godot почти такая же, как в Проводнике Windows, в нём сложно потеряться.
>Что посоветуете делать?
Читать документацию:
https://docs.godotengine.org/en/stable/index.html
Там есть туториалы для новичков.
>А вы мне за всякие приколюхи движка бы пояснили.
Спрашивай в тред >>815359 (OP), если возникнут какие-то вопросы.
>>20835
>Не назначена главная сцена хотите выбрать
Нужно выбрать .tscn файл. Подробнее можно прочитать в документации.
>открывается res/import и все
Не понял, что открывается? Если у тебя нет .tscn файла, нужно сначала сохранить сцену в .tscn формат (или .scn, но .tscn лучше). Навигация в файловом браузере Godot почти такая же, как в Проводнике Windows, в нём сложно потеряться.
>>20952
Спасибо огромное. Но вы не поверите товарищь следователь, оказывается надо было нажать не на треугольничек, а на соседнюю кнопку(запустить сцену) и тут он и сохранить предлагает и все запускается, и все работает. Красота.
В документации пишут, что для игр нужна линейная алгебра некая. Есть может годный гайд по этой теме? Ну там выжимка для игродаунов скажем так.
Спасибо огромное. Но вы не поверите товарищь следователь, оказывается надо было нажать не на треугольничек, а на соседнюю кнопку(запустить сцену) и тут он и сохранить предлагает и все запускается, и все работает. Красота.
В документации пишут, что для игр нужна линейная алгебра некая. Есть может годный гайд по этой теме? Ну там выжимка для игродаунов скажем так.
>>21289
Между ними большая разница. Треугольник (F5) запускает сцену, которую ты назначил главной. Ты должен назначить какую-то сцену главной, чтобы игра могла запуститься после экспорта на целевую платформу. Можешь назвать её main.tscn или game.tscn, и настроить в ней загрузку других сцен, или назначить главной сценой главное (стартовое) меню игры, выбор за тобой.
Кнопка "запустить сцену" (F6) запускает только открытую в данный момент сцену. Это удобно в некоторых случаях, когда нужно протестировать какой-то элемент геймплея в отрыве от остальной игры или запустить тестовую сцену. Но воспринимать её нужно именно как запуск отдельной сцены, а не всей игры.
Есть ещё кнопка "выбрать сцену для запуска", там открывается меню со всеми сценами и можно запустить любую из них, не открывая в редакторе и не назначая главной сценой.
Ты можешь в любой момент нажать ctrl+s, чтобы сохранить всё, что связанно с открытой сценой, включая код и ресурсы. Или выбрать save/save as в меню. Или настроить автосохранение в настройках. Полагаться на автосохранение при запуске не стоит, хотя оно достаточно надёжно, но мне попадались косяки (скажем, новые настройки проекта не всегда вступают в силу, если сразу после их изменения запустить проект).
>оказывается надо было нажать не на треугольничек, а на соседнюю кнопку (запустить сцену)
Между ними большая разница. Треугольник (F5) запускает сцену, которую ты назначил главной. Ты должен назначить какую-то сцену главной, чтобы игра могла запуститься после экспорта на целевую платформу. Можешь назвать её main.tscn или game.tscn, и настроить в ней загрузку других сцен, или назначить главной сценой главное (стартовое) меню игры, выбор за тобой.
Кнопка "запустить сцену" (F6) запускает только открытую в данный момент сцену. Это удобно в некоторых случаях, когда нужно протестировать какой-то элемент геймплея в отрыве от остальной игры или запустить тестовую сцену. Но воспринимать её нужно именно как запуск отдельной сцены, а не всей игры.
Есть ещё кнопка "выбрать сцену для запуска", там открывается меню со всеми сценами и можно запустить любую из них, не открывая в редакторе и не назначая главной сценой.
>сохранить предлагает
Ты можешь в любой момент нажать ctrl+s, чтобы сохранить всё, что связанно с открытой сценой, включая код и ресурсы. Или выбрать save/save as в меню. Или настроить автосохранение в настройках. Полагаться на автосохранение при запуске не стоит, хотя оно достаточно надёжно, но мне попадались косяки (скажем, новые настройки проекта не всегда вступают в силу, если сразу после их изменения запустить проект).
>>21409
спасибо добряк.
спасибо добряк.
>>22548
Где ты это вычитал?
Предполагаю, что ты имеешь в виду поля класса.
По сути, у тебя три уровня для объявления переменных:
1. Глобальные через autoload. Доступны из любого скрипта проекта, до тех пор, пока скрипт загружен в autoload и там стоит галочка. Это нехорошо, избегай их использования, чтобы поддерживать гибкость и расширяемость своего проекта. Их использование ведёт к неявным взаимосвязям в коде, называемым обычно "лапшой" по аналогии с переплетениями лапши в тарелке. Любую задачу можно решить без них! Но иногда их использование уменьшает объём кода, поэтому новички любят их использовать.
2. Поля класса в скрипте. Доступны из любой функции этого скрипта, для доступа извне нужно получить ссылку на экземпляр. Избегай изменения этих переменных извне, лучше всего создавать специальные функции для доступа к этим переменным (сеттеры и геттеры). Избегай добавления сюда всего подряд - здесь должно быть только то, что нужно сохранять длительное время (изменяемое состояние объекта). Здесь те же подводные камни, что и с любыми глобальными переменными.
3. Локальные в функциях. Используются в непосредственных операциях конкретной функции. Недоступны извне, но могут хранить ссылку на внешний объект, который доступен извне. Сама переменная исчезает после завершения функции, но если в ней была ссылка на объект и эта ссылка хранится где-то ещё, объект не исчезнет (в противном случае потомок Reference исчезнет, а вот потомок Node будет засорять память - не забывай освобождать через queue_free() лишние ноды). Используй эти переменные всегда, когда это возможно и имеет смысл, но во многих случаях можно обойтись совсем без переменных, передавая значение между функциями в стиле Lisp: f1(f2(f3(f4(), f5()), f6())), правда, этот стиль снижает читабельность кода, так что используй с умом.
>script wide variable
Где ты это вычитал?
Предполагаю, что ты имеешь в виду поля класса.
По сути, у тебя три уровня для объявления переменных:
1. Глобальные через autoload. Доступны из любого скрипта проекта, до тех пор, пока скрипт загружен в autoload и там стоит галочка. Это нехорошо, избегай их использования, чтобы поддерживать гибкость и расширяемость своего проекта. Их использование ведёт к неявным взаимосвязям в коде, называемым обычно "лапшой" по аналогии с переплетениями лапши в тарелке. Любую задачу можно решить без них! Но иногда их использование уменьшает объём кода, поэтому новички любят их использовать.
2. Поля класса в скрипте. Доступны из любой функции этого скрипта, для доступа извне нужно получить ссылку на экземпляр. Избегай изменения этих переменных извне, лучше всего создавать специальные функции для доступа к этим переменным (сеттеры и геттеры). Избегай добавления сюда всего подряд - здесь должно быть только то, что нужно сохранять длительное время (изменяемое состояние объекта). Здесь те же подводные камни, что и с любыми глобальными переменными.
3. Локальные в функциях. Используются в непосредственных операциях конкретной функции. Недоступны извне, но могут хранить ссылку на внешний объект, который доступен извне. Сама переменная исчезает после завершения функции, но если в ней была ссылка на объект и эта ссылка хранится где-то ещё, объект не исчезнет (в противном случае потомок Reference исчезнет, а вот потомок Node будет засорять память - не забывай освобождать через queue_free() лишние ноды). Используй эти переменные всегда, когда это возможно и имеет смысл, но во многих случаях можно обойтись совсем без переменных, передавая значение между функциями в стиле Lisp: f1(f2(f3(f4(), f5()), f6())), правда, этот стиль снижает читабельность кода, так что используй с умом.
>>22573
отсюда https://gdquest.itch.io/learn-godot-gdscript
Это переменная которая объявляется вне функций и доступна для всех функций
>script wide variable
отсюда https://gdquest.itch.io/learn-godot-gdscript
Это переменная которая объявляется вне функций и доступна для всех функций
>>22577
Это поля класса.
https://ru.wikipedia.org/wiki/Поле_класса
Нюанс в том, что в GDScript все поля публичные и доступны извне, это плохо и нужно аккуратно следить за тем, к чему ты получаешь доступ (в документации рекомендуют начинать с _ имена полей, которые должны быть приватными - т.е. которые ты не собираешься считывать или изменять извне данного скрипта/класса).
>объявляется вне функций и доступна для всех функций
Это поля класса.
https://ru.wikipedia.org/wiki/Поле_класса
Нюанс в том, что в GDScript все поля публичные и доступны извне, это плохо и нужно аккуратно следить за тем, к чему ты получаешь доступ (в документации рекомендуют начинать с _ имена полей, которые должны быть приватными - т.е. которые ты не собираешься считывать или изменять извне данного скрипта/класса).
Годотач, какого хуя в AnimationPlayer нет queue_backwards()?
Если у меня двусторонняя анимация я могу её запустить через play_backwards() или play(...,custom_speed=-1, from_end=true), но как только я хочу добавить её в очередь, чтобы мне не отменяло текущую анимацию годот просто шлёт меня нахуй не давая прокинуть в queue() НИКАКОГО аргумента, кроме названия анимации. Почему? Это я что-то не так делаю и не должен это так использовать? Или это почему-то крайне сложно добавить в код AnimationPlayer-а? В целом: какого хуя?
Если у меня двусторонняя анимация я могу её запустить через play_backwards() или play(...,custom_speed=-1, from_end=true), но как только я хочу добавить её в очередь, чтобы мне не отменяло текущую анимацию годот просто шлёт меня нахуй не давая прокинуть в queue() НИКАКОГО аргумента, кроме названия анимации. Почему? Это я что-то не так делаю и не должен это так использовать? Или это почему-то крайне сложно добавить в код AnimationPlayer-а? В целом: какого хуя?
>>22573
Есть ещё статические переменные класса. Делаются через массив, спрятанный в первом кастомном классе. Спасают много жизней и уничтожают тысячи строк передачи переменных
Есть ещё статические переменные класса. Делаются через массив, спрятанный в первом кастомном классе. Спасают много жизней и уничтожают тысячи строк передачи переменных
>>20353
Что значит римовать? Если рисовать, пиши контакты. Если римовать от слова римминг, то мимо.
Что значит римовать? Если рисовать, пиши контакты. Если римовать от слова римминг, то мимо.
>>24973
Я как раз ровно полярного мнения начал быть, после того, как разобрался в плеере. Через плеер можно безумно удобно запускать звуки, вызывать функции (что позволяет крупную последовательной логики иметь в плеере), через capture mode можно делать даже сложные анимации. И при этом их удобно запускать, ставить в очередь друг за другом и это не занимает по 60 строк кода на сложную анимацию, которую ещё хуй проссышь как дебажить спустя пару месяцев.
Вот отсутствие queue_backwards - это единственный страшный минус, но в целом у твинов его тоже нет, поэтому переходом ничего не выиграю.
Сегодня поковыряю AnimationTree, может через него выйдет сделать что-то, что мне нужно, а если нет - придётся отказаться от двусторонних анимаций и просто делать их две
Я как раз ровно полярного мнения начал быть, после того, как разобрался в плеере. Через плеер можно безумно удобно запускать звуки, вызывать функции (что позволяет крупную последовательной логики иметь в плеере), через capture mode можно делать даже сложные анимации. И при этом их удобно запускать, ставить в очередь друг за другом и это не занимает по 60 строк кода на сложную анимацию, которую ещё хуй проссышь как дебажить спустя пару месяцев.
Вот отсутствие queue_backwards - это единственный страшный минус, но в целом у твинов его тоже нет, поэтому переходом ничего не выиграю.
Сегодня поковыряю AnimationTree, может через него выйдет сделать что-то, что мне нужно, а если нет - придётся отказаться от двусторонних анимаций и просто делать их две
Я может туплю с утра?
Обновился до 3.4.4 и у меня все форичи перестали работать как раньше, а работают иначе. Петпрожекты вылетают с ошибками. Пикс рилейтед.
Обновился до 3.4.4 и у меня все форичи перестали работать как раньше, а работают иначе. Петпрожекты вылетают с ошибками. Пикс рилейтед.
>>25035
Ну да, ты понаписал какую-то херь в дикте и удивляешься?
Ну да, ты понаписал какую-то херь в дикте и удивляешься?
>>24974
Костыль, работающий из-за бага. Официальной поддержки статических переменных нет. Баг могут пофиксить.
Неявные зависимости = код-лапша.
>статические переменные класса. Делаются через массив, спрятанный в первом кастомном классе
Костыль, работающий из-за бага. Официальной поддержки статических переменных нет. Баг могут пофиксить.
>уничтожают тысячи строк передачи переменных
Неявные зависимости = код-лапша.
>>25154 (Del)
У него всё правильно работает.
Синтаксис значения не имеет. В памяти в любом случае создаётся один и тот же объект Dictionary (реализован вроде бы через хэшмапы C++). Ты можешь в любой словарь добавлять любые ключи таким способом:
Через точку доступны только те ключи, которые не содержат проблелов и начинаются с буквы или подчёркивания:
>почему у него не работает
У него всё правильно работает.
>вложенный словарь в "lua"-синтаксисе
Синтаксис значения не имеет. В памяти в любом случае создаётся один и тот же объект Dictionary (реализован вроде бы через хэшмапы C++). Ты можешь в любой словарь добавлять любые ключи таким способом:
>dict.key = "value"
>dict["2nd key"] = "value"
>var key = "3rd key"
>dict[key] = "value"
Через точку доступны только те ключи, которые не содержат проблелов и начинаются с буквы или подчёркивания:
>print(dict.key)
>print(dict["2nd key"])
>print(dict[key])
>>25222
Я про это: https://github.com/godotengine/godot/issues/61274
Рано или поздно этот баг должны пофиксить, и если не добавят официальных статических переменных (которых пока официально нет), то ты не сможешь создавать статические переменные, и не должен пользоваться этим багом сейчас. Насколько я понял обсуждения на гитхабе, Хуан против статических переменных.
>Какой баг? Что массив передается по ссылке?
Я про это: https://github.com/godotengine/godot/issues/61274
>Any array or dictionary like const x := [3,2,1] acts like a static variable. If edited anywhere from any scope, function, or instance, x is permanently changed across every other use of it. This is because the compiler wants to substitute in constants for its identifier in code, where the constant is actually an address to a constants vector.
Рано или поздно этот баг должны пофиксить, и если не добавят официальных статических переменных (которых пока официально нет), то ты не сможешь создавать статические переменные, и не должен пользоваться этим багом сейчас. Насколько я понял обсуждения на гитхабе, Хуан против статических переменных.
>>25165 (Del)
Какой вопрос? Этот? >>25035
Он раньше перебирал элементы словарей через for:
Теперь вместо словарей данная конструкция возвращает ключи, т.е. идентична этому:
Если он хочет снова перебирать элементы словарей, он должен сделать так:
Для вложенных словарей:
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>Вопрос о сложенном в словарь другом словаре.
Какой вопрос? Этот? >>25035
>у меня все форичи перестали работать как раньше, а работают иначе
Он раньше перебирал элементы словарей через for:
>for item in dict:
Теперь вместо словарей данная конструкция возвращает ключи, т.е. идентична этому:
>for key in dict.keys():
Если он хочет снова перебирать элементы словарей, он должен сделать так:
>for value in dict.values():
Для вложенных словарей:
>func do_something_with_values_of(dict: Dictionary) -> void:
>for value in dict.values():
>_ if type_of(value) == TYPE_DICTIONARY:
>_ _ do_something_with_values_of(value)
>_ else:
>_ _ actually_do_something_with_that(value)
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>>25317 (Del)
Ты тупой или это такой троллинг? Я понимаю, ты хотел добить этот тред до бамплимита, но уже всё, 500+ постов, хорош уже дурака валять.
Прочитай ещё раз код и текст на скриншотах: >>25035
For ожидаемо перебирает КЛЮЧИ предложенного ему словаря, а ключи - это СТРОКИ, и эти строки равны "opt1" и "opt2". Его код правильно определяет, что for перебирает СТРОКИ, которые являются КЛЮЧАМИ словаря. Чтобы получить доступ к значениям (т.е. к вложенным словарям), нужно либо обратиться через dict[item], либо перебирать так: for value in dict.values(): ...
>for возвращает элементы не словаря, а вложенных словарей, еще и теряя имена?
Ты тупой или это такой троллинг? Я понимаю, ты хотел добить этот тред до бамплимита, но уже всё, 500+ постов, хорош уже дурака валять.
Прочитай ещё раз код и текст на скриншотах: >>25035
For ожидаемо перебирает КЛЮЧИ предложенного ему словаря, а ключи - это СТРОКИ, и эти строки равны "opt1" и "opt2". Его код правильно определяет, что for перебирает СТРОКИ, которые являются КЛЮЧАМИ словаря. Чтобы получить доступ к значениям (т.е. к вложенным словарям), нужно либо обратиться через dict[item], либо перебирать так: for value in dict.values(): ...
У меня только один вопрос, почему тред был в бамплимите, а сейчас опять в бамплимите?
Перекатываемся >>815359 (OP)
Перекатываемся >>815359 (OP)
>>25309
Это не баг, это фича. Как и положено массиву, он передается по ссылке и в него можно что-то помещать.
Это не баг, это фича. Как и положено массиву, он передается по ссылке и в него можно что-то помещать.
>>25387
Странно, что ты не заметил сразу или заметил только теперь. Все треды с меткой (OP) отсюда >>13666 можно поднять, т.к. в них сейчас по 300-400 постов. Я не хотел об этом писать здесь, чтобы какой-нибудь тролль не устроил Годо-спам на нулевой, и я думал, что ты знаешь об этой проблеме, т.к. ты постоянный ОП... Может быть, нужно попросить модератора заблокировать постинг в старые треды? Такая фича точно есть - видел на некоторых досках треды с замочком, постинг в которые недоступен.
>тред был в бамплимите
Странно, что ты не заметил сразу или заметил только теперь. Все треды с меткой (OP) отсюда >>13666 можно поднять, т.к. в них сейчас по 300-400 постов. Я не хотел об этом писать здесь, чтобы какой-нибудь тролль не устроил Годо-спам на нулевой, и я думал, что ты знаешь об этой проблеме, т.к. ты постоянный ОП... Может быть, нужно попросить модератора заблокировать постинг в старые треды? Такая фича точно есть - видел на некоторых досках треды с замочком, постинг в которые недоступен.
>>25808
Удивительное дело. Всего заметить нельзя. И даже самые очевидные вещи могут годами оставаться незаметными. Да пусть всё остаётся как есть. Тролли нам не страшны. Мы сами с усами.
Удивительное дело. Всего заметить нельзя. И даже самые очевидные вещи могут годами оставаться незаметными. Да пусть всё остаётся как есть. Тролли нам не страшны. Мы сами с усами.
Тред утонул или удален.
Это копия, сохраненная 1 декабря 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 декабря 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.