Этого треда уже нет.
Это копия, сохраненная 2 марта в 10:12.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 2 марта в 10:12.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1,8 Мб, 1600x1600Добро пожаловать в тред любви, взаимопомощи и нормальной нумерации!
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
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 С версии 3.5 больше не нужен.
Библиотека готовых шейдеров: 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 в папку и импортируется.
Книги
Смотри пункт 1 из краткого гайда выше.
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Лучше кинуть ссылку на список всех языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>800308 (OP)
Архивный: https://arhivach.ng/thread/804394/
Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Играть в игродела онлайн без регистрации: https://editor.godotengine.org/releases/latest/ с дивана нельзя.
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 С версии 3.5 больше не нужен.
Библиотека готовых шейдеров: 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 в папку и импортируется.
Книги
Смотри пункт 1 из краткого гайда выше.
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Лучше кинуть ссылку на список всех языков: https://github.com/Vivraan/godot-lang-support
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе). Тут нужно отметить, что проект не запустится без папки .import и файлов в нём. Если попытаться запустить без неё, Godot попросит запустить редактор, чтобы импортировать ресурсы заново. Т.е., к сожалению, невозможно просто отредактировать текстуру в пейнте и увидеть изменения в игре - в любом случае потребуется запускать редактор, чтобы он импортировал текстуру заново, потому что импорт - это конвертация во внутренний формат (etc/etc2/s3tc/bptc), а оригинальный файл (.png, .jpg и т.д.) игрой не читается (load("res://icon.png") грузит версию из папки импорта, а не ту, что мы ожидаем).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>800308 (OP)
Архивный: https://arhivach.ng/thread/804394/
>>15467
Ты может быть только что вышел из комы? В ГД ТВГ идёт в полный рост. Некогда нам в тредах срать. Погоди недельку - будет тебе постинг.
Ты может быть только что вышел из комы? В ГД ТВГ идёт в полный рост. Некогда нам в тредах срать. Погоди недельку - будет тебе постинг.
>>15686 (Del)
То то у меня ломались проекты с нихуя и вечно крашилось без ошибки, это из-за этого?
То то у меня ломались проекты с нихуя и вечно крашилось без ошибки, это из-за этого?
>>16156 (Del)
Эта хуйня рандомно происходила. Раньше такого не было.
Эта хуйня рандомно происходила. Раньше такого не было.
>>814718 →
Если этот ресурс есть у всех без исключения, то почему нельзя сделать его просто частью общего для всех класса?
Вместо:
Будет:
Но изначально ты говорил о компонентах, предполагая, что существа могут иметь произвольный набор компонентов произвольных типов. Ты не знаешь заранее, какие компоненты кому будут принадлежать, и сколько их будет в памяти. Вот для этого и нужны классы и ссылки между ними.
А вообще, лучшая оптимизация - ограничить количество и детализацию существ на уровне геймдизайна, если ты делаешь игру. Старые игры всегда ограничивали масштабы происходящих событий и количество действующих лиц, равно как и детализацию всего и вся. С тех пор не сильно всё изменилось, по-прежнему нужно вписываться в лимиты железа, если хочешь симуляцию в реальном времени на обычном персональном компьютере.
Если ты пишешь код на GDScript, то у тебя все данные находятся в таких "жирных объектах". Потому что Array и Dictionary - это тоже классы, которые к тому же оперируют исключительно Variant типом данных, а это сильно повышает требования к памяти и скорость чтения/записи. Есть специализированные массивы, хранящие данные только одного типа, но это тоже отдельные классы. В Godot 4.0 вроде обещали как-то оптимизировать всё это...
Я, кстати, в своём проекте замучился оперировать массивом словарей и сделал свой класс, потомок Reference, которым заполняю тот же массив - ощутимых ухудшений в работе проекта не заметил, зато в коде теперь есть подсказки для полей этого класса, и в функциях могу чётко указать тип данных.
https://docs.godotengine.org/en/stable/classes/class_resourcesaver.html
На диске они могут храниться где пожелаешь.
>оч много существ (ну давай пару тыщ для начала) и предметов имеют ресурс с почти у всех уникальными значениями
Если этот ресурс есть у всех без исключения, то почему нельзя сделать его просто частью общего для всех класса?
Вместо:
>export var dna: DNAResource
Будет:
>export var dna: String
Но изначально ты говорил о компонентах, предполагая, что существа могут иметь произвольный набор компонентов произвольных типов. Ты не знаешь заранее, какие компоненты кому будут принадлежать, и сколько их будет в памяти. Вот для этого и нужны классы и ссылки между ними.
А вообще, лучшая оптимизация - ограничить количество и детализацию существ на уровне геймдизайна, если ты делаешь игру. Старые игры всегда ограничивали масштабы происходящих событий и количество действующих лиц, равно как и детализацию всего и вся. С тех пор не сильно всё изменилось, по-прежнему нужно вписываться в лимиты железа, если хочешь симуляцию в реальном времени на обычном персональном компьютере.
>хранить в таком жирном объекте как ресурс
Если ты пишешь код на GDScript, то у тебя все данные находятся в таких "жирных объектах". Потому что Array и Dictionary - это тоже классы, которые к тому же оперируют исключительно Variant типом данных, а это сильно повышает требования к памяти и скорость чтения/записи. Есть специализированные массивы, хранящие данные только одного типа, но это тоже отдельные классы. В Godot 4.0 вроде обещали как-то оптимизировать всё это...
Я, кстати, в своём проекте замучился оперировать массивом словарей и сделал свой класс, потомок Reference, которым заполняю тот же массив - ощутимых ухудшений в работе проекта не заметил, зато в коде теперь есть подсказки для полей этого класса, и в функциях могу чётко указать тип данных.
>Да и каким методом тот или иной ресурс сериализуется?
https://docs.godotengine.org/en/stable/classes/class_resourcesaver.html
>если он уникален, все его данные изначально находятся в .tscn, или он где-то в другом месте.
На диске они могут храниться где пожелаешь.
>>814718 →
Если этот ресурс есть у всех без исключения, то почему нельзя сделать его просто частью общего для всех класса?
Вместо:
Будет:
Но изначально ты говорил о компонентах, предполагая, что существа могут иметь произвольный набор компонентов произвольных типов. Ты не знаешь заранее, какие компоненты кому будут принадлежать, и сколько их будет в памяти. Вот для этого и нужны классы и ссылки между ними.
А вообще, лучшая оптимизация - ограничить количество и детализацию существ на уровне геймдизайна, если ты делаешь игру. Старые игры всегда ограничивали масштабы происходящих событий и количество действующих лиц, равно как и детализацию всего и вся. С тех пор не сильно всё изменилось, по-прежнему нужно вписываться в лимиты железа, если хочешь симуляцию в реальном времени на обычном персональном компьютере.
Если ты пишешь код на GDScript, то у тебя все данные находятся в таких "жирных объектах". Потому что Array и Dictionary - это тоже классы, которые к тому же оперируют исключительно Variant типом данных, а это сильно повышает требования к памяти и скорость чтения/записи. Есть специализированные массивы, хранящие данные только одного типа, но это тоже отдельные классы. В Godot 4.0 вроде обещали как-то оптимизировать всё это...
Я, кстати, в своём проекте замучился оперировать массивом словарей и сделал свой класс, потомок Reference, которым заполняю тот же массив - ощутимых ухудшений в работе проекта не заметил, зато в коде теперь есть подсказки для полей этого класса, и в функциях могу чётко указать тип данных.
https://docs.godotengine.org/en/stable/classes/class_resourcesaver.html
На диске они могут храниться где пожелаешь.
>оч много существ (ну давай пару тыщ для начала) и предметов имеют ресурс с почти у всех уникальными значениями
Если этот ресурс есть у всех без исключения, то почему нельзя сделать его просто частью общего для всех класса?
Вместо:
>export var dna: DNAResource
Будет:
>export var dna: String
Но изначально ты говорил о компонентах, предполагая, что существа могут иметь произвольный набор компонентов произвольных типов. Ты не знаешь заранее, какие компоненты кому будут принадлежать, и сколько их будет в памяти. Вот для этого и нужны классы и ссылки между ними.
А вообще, лучшая оптимизация - ограничить количество и детализацию существ на уровне геймдизайна, если ты делаешь игру. Старые игры всегда ограничивали масштабы происходящих событий и количество действующих лиц, равно как и детализацию всего и вся. С тех пор не сильно всё изменилось, по-прежнему нужно вписываться в лимиты железа, если хочешь симуляцию в реальном времени на обычном персональном компьютере.
>хранить в таком жирном объекте как ресурс
Если ты пишешь код на GDScript, то у тебя все данные находятся в таких "жирных объектах". Потому что Array и Dictionary - это тоже классы, которые к тому же оперируют исключительно Variant типом данных, а это сильно повышает требования к памяти и скорость чтения/записи. Есть специализированные массивы, хранящие данные только одного типа, но это тоже отдельные классы. В Godot 4.0 вроде обещали как-то оптимизировать всё это...
Я, кстати, в своём проекте замучился оперировать массивом словарей и сделал свой класс, потомок Reference, которым заполняю тот же массив - ощутимых ухудшений в работе проекта не заметил, зато в коде теперь есть подсказки для полей этого класса, и в функциях могу чётко указать тип данных.
>Да и каким методом тот или иной ресурс сериализуется?
https://docs.godotengine.org/en/stable/classes/class_resourcesaver.html
>если он уникален, все его данные изначально находятся в .tscn, или он где-то в другом месте.
На диске они могут храниться где пожелаешь.
>>17521
Ошибся, нельзя экспортировать кастомный ресурс, можно только встроенный. Поскольку кастомный наследуется скорее всего от Resource, можно указать так:
И в инспекторе придётся листать огромный список всех возможных ресурсов... или перенести мышкой сохранённый ресурс из браузера файловой системы в инспектор нод.
Не знаю, почему так и почему до сих пор не исправили в 3.х, но об этой проблеме давно все знают и вроде обещают пофиксить в 4.0, но я не помню, готово ли оно уже в альфе.
Возможно, это как раз из-за механизма сериализации. Парсер скриптов не знает, как сохранять кастомный тип, поэтому отвергает его. С другой стороны, в файловом браузере можно создать и сразу сохранить на диск любой кастомный ресурс, так в чём же проблема? И почему так долго не исправляют...
>export var dna: DNAResource
Ошибся, нельзя экспортировать кастомный ресурс, можно только встроенный. Поскольку кастомный наследуется скорее всего от Resource, можно указать так:
>export var dna: Resource
И в инспекторе придётся листать огромный список всех возможных ресурсов... или перенести мышкой сохранённый ресурс из браузера файловой системы в инспектор нод.
Не знаю, почему так и почему до сих пор не исправили в 3.х, но об этой проблеме давно все знают и вроде обещают пофиксить в 4.0, но я не помню, готово ли оно уже в альфе.
Возможно, это как раз из-за механизма сериализации. Парсер скриптов не знает, как сохранять кастомный тип, поэтому отвергает его. С другой стороны, в файловом браузере можно создать и сразу сохранить на диск любой кастомный ресурс, так в чём же проблема? И почему так долго не исправляют...
Godot 4 Beta планируется в следующем месяце, а стабильная версия в конце этого года-начале следующего года!
https://twitter.com/reduzio/status/1546907192917467137
https://twitter.com/reduzio/status/1546907192917467137
>>17521
Потому что я хотел делать совсем не то чем явдяется годот, какой то ECS из него сделать хотел. То что ты говоришь так то имеет смысл, но вот я подкину говна в вентилятор.
Когда у тебя всё на компонентах, а игровой объект является "игровым" (существом, предметов и т.д.) именно настолько, какие компоненты он имеет. Всё становится однородным и как бы самоэмерджируемым (если конечно еще правильно построить архитекутуру). Например любой ентити с компонентом контейнер уже умеет хранить ресурсы, и похуй что в мире у него нет позиции (он может просто быть привязанным к другому контейнеру, быть временным, контейнером может стать даже очко какого нибудь вурдалака, опять же чисто в силу модульности самой архитектуры игры). У ентити может быть компонент "Материальности", вес, масса, материал из которого они состоят, и компонент "позиции". Теперь у тебя спокойно может быть предмет который где то находится но нематериален, и может быть чем угодно, или кусок говна который находится в неопределённом местоположении (хз зачем но прикольно же). Раздельные компоненты локомоушена (то что даёт импульс к движению объекта в мире) и Контроллера (жрёт команды от ии или игрока, притом они насколько возможно универсальны). Теперь в любую ёбань можно вселиться, и если какой-то из компонентов сможет сожрать команду на движение которая в очереди сидит (в нашем случае локомошен) то объект ее исполнит. Также с компонентами "Манипуляция", то есть оживить зачем то тряпку то у нее будет манипуляция качество 1 там нахуй, и можно маленькие предметы таскать, или скрафтить что-то (хотя по идее не должно с таким маленьким качеством получиться.)
Пойдём в ещё большее безумие. Теперь можно закинуть на любой ентити компонент DNA (нахуй ты меня надоумил), который в себе будет содержать код, который можно будет расшифровывать и он будет в полурандомном порядке немного менять свойства ентити (алгоритм где то у меня валяется). ОФК по логике этот компонент не должен быть отдельным от компонента "Углеродная форма дизни на ДНК", но чисто из шизофренического эксперимента можно навесить его на ентити ножа, теперь облучаем (тупо, но для примера) нож радиацией, и ОН МУТИРУЕТ НАХУЙ. Стал коротким как кордуплик, неудобный но острота на 4% повысилась. Ну вот кароче и такого ебанутого безумия может быть просто тонны ёбаные.
То есть в теории исчезает ситуация когда ентитис каким-то набором компонентов может быть реально невалидным. Он может быть скоорапченым и работать не так как надо, или что-то еще, но всегда он будет реагировать на действия игрока или самого мира на него естественным ходом.
>Если этот ресурс есть у всех без исключения, то почему нельзя сделать его просто частью общего для всех класса?
Потому что я хотел делать совсем не то чем явдяется годот, какой то ECS из него сделать хотел. То что ты говоришь так то имеет смысл, но вот я подкину говна в вентилятор.
Когда у тебя всё на компонентах, а игровой объект является "игровым" (существом, предметов и т.д.) именно настолько, какие компоненты он имеет. Всё становится однородным и как бы самоэмерджируемым (если конечно еще правильно построить архитекутуру). Например любой ентити с компонентом контейнер уже умеет хранить ресурсы, и похуй что в мире у него нет позиции (он может просто быть привязанным к другому контейнеру, быть временным, контейнером может стать даже очко какого нибудь вурдалака, опять же чисто в силу модульности самой архитектуры игры). У ентити может быть компонент "Материальности", вес, масса, материал из которого они состоят, и компонент "позиции". Теперь у тебя спокойно может быть предмет который где то находится но нематериален, и может быть чем угодно, или кусок говна который находится в неопределённом местоположении (хз зачем но прикольно же). Раздельные компоненты локомоушена (то что даёт импульс к движению объекта в мире) и Контроллера (жрёт команды от ии или игрока, притом они насколько возможно универсальны). Теперь в любую ёбань можно вселиться, и если какой-то из компонентов сможет сожрать команду на движение которая в очереди сидит (в нашем случае локомошен) то объект ее исполнит. Также с компонентами "Манипуляция", то есть оживить зачем то тряпку то у нее будет манипуляция качество 1 там нахуй, и можно маленькие предметы таскать, или скрафтить что-то (хотя по идее не должно с таким маленьким качеством получиться.)
Пойдём в ещё большее безумие. Теперь можно закинуть на любой ентити компонент DNA (нахуй ты меня надоумил), который в себе будет содержать код, который можно будет расшифровывать и он будет в полурандомном порядке немного менять свойства ентити (алгоритм где то у меня валяется). ОФК по логике этот компонент не должен быть отдельным от компонента "Углеродная форма дизни на ДНК", но чисто из шизофренического эксперимента можно навесить его на ентити ножа, теперь облучаем (тупо, но для примера) нож радиацией, и ОН МУТИРУЕТ НАХУЙ. Стал коротким как кордуплик, неудобный но острота на 4% повысилась. Ну вот кароче и такого ебанутого безумия может быть просто тонны ёбаные.
То есть в теории исчезает ситуация когда ентитис каким-то набором компонентов может быть реально невалидным. Он может быть скоорапченым и работать не так как надо, или что-то еще, но всегда он будет реагировать на действия игрока или самого мира на него естественным ходом.
>>17521
Потому что я хотел делать совсем не то чем явдяется годот, какой то ECS из него сделать хотел. То что ты говоришь так то имеет смысл, но вот я подкину говна в вентилятор.
Когда у тебя всё на компонентах, а игровой объект является "игровым" (существом, предметов и т.д.) именно настолько, какие компоненты он имеет. Всё становится однородным и как бы самоэмерджируемым (если конечно еще правильно построить архитекутуру). Например любой ентити с компонентом контейнер уже умеет хранить ресурсы, и похуй что в мире у него нет позиции (он может просто быть привязанным к другому контейнеру, быть временным, контейнером может стать даже очко какого нибудь вурдалака, опять же чисто в силу модульности самой архитектуры игры). У ентити может быть компонент "Материальности", вес, масса, материал из которого они состоят, и компонент "позиции". Теперь у тебя спокойно может быть предмет который где то находится но нематериален, и может быть чем угодно, или кусок говна который находится в неопределённом местоположении (хз зачем но прикольно же). Раздельные компоненты локомоушена (то что даёт импульс к движению объекта в мире) и Контроллера (жрёт команды от ии или игрока, притом они насколько возможно универсальны). Теперь в любую ёбань можно вселиться, и если какой-то из компонентов сможет сожрать команду на движение которая в очереди сидит (в нашем случае локомошен) то объект ее исполнит. Также с компонентами "Манипуляция", то есть оживить зачем то тряпку то у нее будет манипуляция качество 1 там нахуй, и можно маленькие предметы таскать, или скрафтить что-то (хотя по идее не должно с таким маленьким качеством получиться.)
Пойдём в ещё большее безумие. Теперь можно закинуть на любой ентити компонент DNA (нахуй ты меня надоумил), который в себе будет содержать код, который можно будет расшифровывать и он будет в полурандомном порядке немного менять свойства ентити (алгоритм где то у меня валяется). ОФК по логике этот компонент не должен быть отдельным от компонента "Углеродная форма дизни на ДНК", но чисто из шизофренического эксперимента можно навесить его на ентити ножа, теперь облучаем (тупо, но для примера) нож радиацией, и ОН МУТИРУЕТ НАХУЙ. Стал коротким как кордуплик, неудобный но острота на 4% повысилась. Ну вот кароче и такого ебанутого безумия может быть просто тонны ёбаные.
То есть в теории исчезает ситуация когда ентитис каким-то набором компонентов может быть реально невалидным. Он может быть скоорапченым и работать не так как надо, или что-то еще, но всегда он будет реагировать на действия игрока или самого мира на него естественным ходом.
>Если этот ресурс есть у всех без исключения, то почему нельзя сделать его просто частью общего для всех класса?
Потому что я хотел делать совсем не то чем явдяется годот, какой то ECS из него сделать хотел. То что ты говоришь так то имеет смысл, но вот я подкину говна в вентилятор.
Когда у тебя всё на компонентах, а игровой объект является "игровым" (существом, предметов и т.д.) именно настолько, какие компоненты он имеет. Всё становится однородным и как бы самоэмерджируемым (если конечно еще правильно построить архитекутуру). Например любой ентити с компонентом контейнер уже умеет хранить ресурсы, и похуй что в мире у него нет позиции (он может просто быть привязанным к другому контейнеру, быть временным, контейнером может стать даже очко какого нибудь вурдалака, опять же чисто в силу модульности самой архитектуры игры). У ентити может быть компонент "Материальности", вес, масса, материал из которого они состоят, и компонент "позиции". Теперь у тебя спокойно может быть предмет который где то находится но нематериален, и может быть чем угодно, или кусок говна который находится в неопределённом местоположении (хз зачем но прикольно же). Раздельные компоненты локомоушена (то что даёт импульс к движению объекта в мире) и Контроллера (жрёт команды от ии или игрока, притом они насколько возможно универсальны). Теперь в любую ёбань можно вселиться, и если какой-то из компонентов сможет сожрать команду на движение которая в очереди сидит (в нашем случае локомошен) то объект ее исполнит. Также с компонентами "Манипуляция", то есть оживить зачем то тряпку то у нее будет манипуляция качество 1 там нахуй, и можно маленькие предметы таскать, или скрафтить что-то (хотя по идее не должно с таким маленьким качеством получиться.)
Пойдём в ещё большее безумие. Теперь можно закинуть на любой ентити компонент DNA (нахуй ты меня надоумил), который в себе будет содержать код, который можно будет расшифровывать и он будет в полурандомном порядке немного менять свойства ентити (алгоритм где то у меня валяется). ОФК по логике этот компонент не должен быть отдельным от компонента "Углеродная форма дизни на ДНК", но чисто из шизофренического эксперимента можно навесить его на ентити ножа, теперь облучаем (тупо, но для примера) нож радиацией, и ОН МУТИРУЕТ НАХУЙ. Стал коротким как кордуплик, неудобный но острота на 4% повысилась. Ну вот кароче и такого ебанутого безумия может быть просто тонны ёбаные.
То есть в теории исчезает ситуация когда ентитис каким-то набором компонентов может быть реально невалидным. Он может быть скоорапченым и работать не так как надо, или что-то еще, но всегда он будет реагировать на действия игрока или самого мира на него естественным ходом.
>>814563 →
А поделись геймдизайном/идеями/планами, если не секрет. Я тоже хочу "опенворлд песочницу с симуляцией жизни", но я делаю всё очень медленно и часто забрасываю проект. Как подумаю о том, сколько всего нужно сделать до минимальной реализации желаемого, как-то уже и не хочется ничего...
>>Ты делаешь опенворлд песочницу с симуляцией жизни?
>Да, но пока только к движку примеряюсь.
А поделись геймдизайном/идеями/планами, если не секрет. Я тоже хочу "опенворлд песочницу с симуляцией жизни", но я делаю всё очень медленно и часто забрасываю проект. Как подумаю о том, сколько всего нужно сделать до минимальной реализации желаемого, как-то уже и не хочется ничего...
Еще добавлю:
>>17521
Я таки собирался в будущем переносить код на С++, если почувствую что я серьезно собираюсь игру свою до ума доводить. Но тем не менее, если архитектура и игровой редактор годоти не будет располагать к тому чтобы на нём более менее удобно и с производительностью хотя бы какой-то можно было кулякать игру в достаточном стиле composition over inheritance.
Потому я считаю что лучше будет написать отдельный сервер который бы хавал JSON и исходя из того что там насрано уже конструировать объедки и ентитя. Может я долбоёб и пытаюсь свелосипедить то что уже есть, но сцуко нихуянепонятнокаквсёработаетбляяя
>>17521
>Если ты пишешь код на GDScript, то у тебя все данные находятся в таких "жирных объектах".
Я таки собирался в будущем переносить код на С++, если почувствую что я серьезно собираюсь игру свою до ума доводить. Но тем не менее, если архитектура и игровой редактор годоти не будет располагать к тому чтобы на нём более менее удобно и с производительностью хотя бы какой-то можно было кулякать игру в достаточном стиле composition over inheritance.
>Возможно, это как раз из-за механизма сериализации. Парсер скриптов не знает, как сохранять кастомный тип, поэтому отвергает его.
Потому я считаю что лучше будет написать отдельный сервер который бы хавал JSON и исходя из того что там насрано уже конструировать объедки и ентитя. Может я долбоёб и пытаюсь свелосипедить то что уже есть, но сцуко нихуянепонятнокаквсёработаетбляяя
1,2 Мб, 1366x766>>17610
Ой блять я там насрал пиздец просто.
Уже и название игры придумал, прямо сочное такое, наполненное смыслом и довольно оригинальное а хуй вам не скажу, пусть оно умрёт со мной если нихуя не сделаю
По сути рилтайм псевдо2д недосюрвайвал (пушта абсолютного выживание там не обязательно, только если надо что-то ТАЙНОЕ или НОВОЕ открыть, придётся пиздовать в места где тебя могут абасцать) песочница.
Графика 2д, тайлы похожи на пик1, но немного пошире, стилистка скорее всего другая, графика минималистичная, потому что хотел использовать контент ген на основе SVGtoPNG. вроде пояснял уже. Отличие в том что видно верхние и нижние уровни, но чтобы верхние уровни не загораживали обзор, логика того что именно видно оч хитрая. Есть система транспорта/вложенных уровней, это значит что можно построить ЙОБУ и тех же самых блоков что и мир вокруг (это литерали просто другой левел вставленый в основной левел). Транспорт ездиет, вращается на 180 градусов (на предельных точках когда тайлы уже под 80 градусов на бок переворачиваются просто перспектива меняется, как будто на здание с другой стороны палишь).
Система органов, генетики и прочей залупы КАК В ДВЫРФФАРТРЕС кирилл, спок.
С сеттингом тоже двоякая штука, хотелось чтобы тоже был закос под "генератор историй", но при этом есть свой странный сеттинг, в котором и недомагии-недопсионики (искусственное разделение тащемта) есть место, и техномагии (ебать угорел с кукольных мастеров из наруто пиздец), и чего только нет. Всякий рандом кароче ебанутый как в нуменере, но более, так скажем, приглушённый, в плане того что в нуменере любая ебанутая хуйня могла быть без объяснения почему именно так и всё.
Идей так-то много я записал, там ебанёшься скок ДИЗДОКОВ, но сам понимаешь если даже просто с инструментом сладить не могу, какие тут рогалики.
Ой блять я там насрал пиздец просто.
Уже и название игры придумал, прямо сочное такое, наполненное смыслом и довольно оригинальное а хуй вам не скажу, пусть оно умрёт со мной если нихуя не сделаю
По сути рилтайм псевдо2д недосюрвайвал (пушта абсолютного выживание там не обязательно, только если надо что-то ТАЙНОЕ или НОВОЕ открыть, придётся пиздовать в места где тебя могут абасцать) песочница.
Графика 2д, тайлы похожи на пик1, но немного пошире, стилистка скорее всего другая, графика минималистичная, потому что хотел использовать контент ген на основе SVGtoPNG. вроде пояснял уже. Отличие в том что видно верхние и нижние уровни, но чтобы верхние уровни не загораживали обзор, логика того что именно видно оч хитрая. Есть система транспорта/вложенных уровней, это значит что можно построить ЙОБУ и тех же самых блоков что и мир вокруг (это литерали просто другой левел вставленый в основной левел). Транспорт ездиет, вращается на 180 градусов (на предельных точках когда тайлы уже под 80 градусов на бок переворачиваются просто перспектива меняется, как будто на здание с другой стороны палишь).
Система органов, генетики и прочей залупы КАК В ДВЫРФФАРТРЕС кирилл, спок.
С сеттингом тоже двоякая штука, хотелось чтобы тоже был закос под "генератор историй", но при этом есть свой странный сеттинг, в котором и недомагии-недопсионики (искусственное разделение тащемта) есть место, и техномагии (ебать угорел с кукольных мастеров из наруто пиздец), и чего только нет. Всякий рандом кароче ебанутый как в нуменере, но более, так скажем, приглушённый, в плане того что в нуменере любая ебанутая хуйня могла быть без объяснения почему именно так и всё.
Идей так-то много я записал, там ебанёшься скок ДИЗДОКОВ, но сам понимаешь если даже просто с инструментом сладить не могу, какие тут рогалики.
>>17616
Мне хотелось это проработать потому что понравился момент связанный с тем как в римворлде ты мог как шизанутый менгеле мутить всякие генетико-механические эксперименты над пешками.
Я кстати даже хотел спиздануть стилизацию как в римворлде (просто она идеальна под мой вариант), но хз, её так частно пиздили что это уже бесстыдство какое-то.
>Система органов, генетики и прочей залупы КАК В ДВЫРФФАРТРЕС кирилл, спок.
Мне хотелось это проработать потому что понравился момент связанный с тем как в римворлде ты мог как шизанутый менгеле мутить всякие генетико-механические эксперименты над пешками.
Я кстати даже хотел спиздануть стилизацию как в римворлде (просто она идеальна под мой вариант), но хз, её так частно пиздили что это уже бесстыдство какое-то.
>>17609
я хочу просто понять, может все эти вещи в годоте можно композировать без диких потерь преизводительности, но как я хз.
я хочу просто понять, может все эти вещи в годоте можно композировать без диких потерь преизводительности, но как я хз.
>>17609
Я думаю, для этого следует написать свой C++ модуль, который будет объявлять "сущность", "компонент" и "систему", а на GDScript только создавать и заполнять их. Чтобы все операции с памятью были под контролем и хорошо оптимизированы. Чисто на GDScript можно сделать ECS, но она будет медленной и прожорливой.
Да, я всё это прекрасно знаю. И на Godot это всё можно легко реализовать, хоть на нодах, хоть на компонентах, хоть на Reference. Проблема только в производительности и удобстве использования той или иной реализации. Но всё зависит от твоих потребностей (дизайна игры) и способности оптимизировать игру на высоком уровне, допустим, выгружая лишние чанки со всеми принадлежащими им существами из оперативной памяти.
Симуляция жизни как жанр не требует тысяч существ одновременно, достаточно одного существа, пытающегося как-то выжить в маленьком статичном мире. Или двух существ, борющихся друг с другом за какие-то цели. Первые эксперименты с виртуальной жизнью так и происходили, в очень маленьком масштабе, с малым числом существ и характеристик этих существ. Ты просто замахиваешься на слишком масштабные цели...
>>17612
Ну можно, да, можно, делай, пробуй. Способов несколько, не обязательно ноды мышкой таскать...
Лучше, но потому, что сложную структуру мира и существ может быть оптимальнее хранить в какой-то бинарной структуре (по типу файловой системы ОС), чем в JSON или другом текстовом формате. В текстовом формате у тебя могут оказаться гигабайты данных на визуально примитивный мир (а-ля майнкрафт). А для JSON есть встроенные инструменты, я ими пользуюсь, всё прекрасно.
Ты же вроде знаешь C++, вот иди изучай исходники движка)
>>17616
С точки зрения геймплея будет значительно лучше сделать полноценную 3D игру, чем насиловать 2D тайлы. Так тебе не придётся реализовывать всякие "хитрости" для отображения 3D структур в 2D тайловом мире, а игроку не придётся ломать голову и клавиатуру в попытке эти структуры понять. Я знаю, что подобные игры есть (CDDA, например, там транспорт из тайлов строится), но они для очень узкой ЦА, для каких-то особых ценителей стиля (ASCII, вот это всё).
Ну это-то как раз не сложно. Dictionary с перечислением всех органов и их состояний, и какой-то метод для изменения состояний. Гены вообще могут описывать что угодно в рамках вымышленного виртуального мира, следовательно, никаких ограничений в плане генетики нет - делай что хочешь, и это можно будет назвать "генетикой", если там есть "гены". Совсем другое дело, если ты хочешь реализовать точную модель ИРЛ генетики...
Делай один. Рекомендую на основе вики-движка, например, вот https://tiddlywiki.com/ удобная штука в стиле вики.
>>17617
Ясно, понятно, меня лично интересует только чтобы "пешки" были не простыми "пешками", а жили по-настоящему как люди, и могли справиться с возникающими проблемами, например, не позволить игроку проводить над ними эксперименты) Делать полноценную сложную симуляцию жизни для простой выживалки-песочницы "для экспериментов игрока над тупыми ботами" как минимум бессмысленно, тех же результатов можно добиться без какой-либо симуляции (а-ля майнкрафт - в нём симуляции считай что нет).
Рекомендую начать с простейшего и самого основного, а уже потом добавлять какие-то идеи. Сделай для начала 2D тайловую карту (TileMap), одного персонажа и его навигацию по клеткам карты, чтобы он шёл до клетки, на которую кликнул игрок, обходя препятствия. Это сравнительно просто с использованием встроенных инструментов. Потом добавь на карту какую-нибудь еду, а персонажу добавь самостоятельный выбор цели, чтобы он шёл есть еду, когда у него начинается голод. И так далее, постепенно усложняя поведение и наполнение мира. Так у тебя уже будет какая-то основа для игры, которую можно будет дорабатывать или переделывать на другую архитектуру, если ты придумаешь что-то лучше, или переносить на другой движок/ЯП/платформу. А пока ты только теоретизируешь, работа с места не сдвинется...
>какой то ECS из него сделать хотел
Я думаю, для этого следует написать свой C++ модуль, который будет объявлять "сущность", "компонент" и "систему", а на GDScript только создавать и заполнять их. Чтобы все операции с памятью были под контролем и хорошо оптимизированы. Чисто на GDScript можно сделать ECS, но она будет медленной и прожорливой.
>Когда у тебя всё на компонентах...
Да, я всё это прекрасно знаю. И на Godot это всё можно легко реализовать, хоть на нодах, хоть на компонентах, хоть на Reference. Проблема только в производительности и удобстве использования той или иной реализации. Но всё зависит от твоих потребностей (дизайна игры) и способности оптимизировать игру на высоком уровне, допустим, выгружая лишние чанки со всеми принадлежащими им существами из оперативной памяти.
Симуляция жизни как жанр не требует тысяч существ одновременно, достаточно одного существа, пытающегося как-то выжить в маленьком статичном мире. Или двух существ, борющихся друг с другом за какие-то цели. Первые эксперименты с виртуальной жизнью так и происходили, в очень маленьком масштабе, с малым числом существ и характеристик этих существ. Ты просто замахиваешься на слишком масштабные цели...
>>17612
>хотя бы какой-то можно было кулякать игру в достаточном стиле composition over inheritance.
Ну можно, да, можно, делай, пробуй. Способов несколько, не обязательно ноды мышкой таскать...
>лучше будет написать отдельный сервер
Лучше, но потому, что сложную структуру мира и существ может быть оптимальнее хранить в какой-то бинарной структуре (по типу файловой системы ОС), чем в JSON или другом текстовом формате. В текстовом формате у тебя могут оказаться гигабайты данных на визуально примитивный мир (а-ля майнкрафт). А для JSON есть встроенные инструменты, я ими пользуюсь, всё прекрасно.
>непонятнокаквсёработает
Ты же вроде знаешь C++, вот иди изучай исходники движка)
>>17616
>Графика 2д, тайлы
>графика минималистичная,
>система транспорта/вложенных уровней
>Транспорт ездиет, вращается на 180 градусов.
С точки зрения геймплея будет значительно лучше сделать полноценную 3D игру, чем насиловать 2D тайлы. Так тебе не придётся реализовывать всякие "хитрости" для отображения 3D структур в 2D тайловом мире, а игроку не придётся ломать голову и клавиатуру в попытке эти структуры понять. Я знаю, что подобные игры есть (CDDA, например, там транспорт из тайлов строится), но они для очень узкой ЦА, для каких-то особых ценителей стиля (ASCII, вот это всё).
>Система органов, генетики
Ну это-то как раз не сложно. Dictionary с перечислением всех органов и их состояний, и какой-то метод для изменения состояний. Гены вообще могут описывать что угодно в рамках вымышленного виртуального мира, следовательно, никаких ограничений в плане генетики нет - делай что хочешь, и это можно будет назвать "генетикой", если там есть "гены". Совсем другое дело, если ты хочешь реализовать точную модель ИРЛ генетики...
>скок ДИЗДОКОВ
Делай один. Рекомендую на основе вики-движка, например, вот https://tiddlywiki.com/ удобная штука в стиле вики.
>>17617
>всякие генетико-механические эксперименты над пешками.
Ясно, понятно, меня лично интересует только чтобы "пешки" были не простыми "пешками", а жили по-настоящему как люди, и могли справиться с возникающими проблемами, например, не позволить игроку проводить над ними эксперименты) Делать полноценную сложную симуляцию жизни для простой выживалки-песочницы "для экспериментов игрока над тупыми ботами" как минимум бессмысленно, тех же результатов можно добиться без какой-либо симуляции (а-ля майнкрафт - в нём симуляции считай что нет).
>если даже просто с инструментом сладить не могу, какие тут рогалики.
Рекомендую начать с простейшего и самого основного, а уже потом добавлять какие-то идеи. Сделай для начала 2D тайловую карту (TileMap), одного персонажа и его навигацию по клеткам карты, чтобы он шёл до клетки, на которую кликнул игрок, обходя препятствия. Это сравнительно просто с использованием встроенных инструментов. Потом добавь на карту какую-нибудь еду, а персонажу добавь самостоятельный выбор цели, чтобы он шёл есть еду, когда у него начинается голод. И так далее, постепенно усложняя поведение и наполнение мира. Так у тебя уже будет какая-то основа для игры, которую можно будет дорабатывать или переделывать на другую архитектуру, если ты придумаешь что-то лучше, или переносить на другой движок/ЯП/платформу. А пока ты только теоретизируешь, работа с места не сдвинется...
>>17609
Я думаю, для этого следует написать свой C++ модуль, который будет объявлять "сущность", "компонент" и "систему", а на GDScript только создавать и заполнять их. Чтобы все операции с памятью были под контролем и хорошо оптимизированы. Чисто на GDScript можно сделать ECS, но она будет медленной и прожорливой.
Да, я всё это прекрасно знаю. И на Godot это всё можно легко реализовать, хоть на нодах, хоть на компонентах, хоть на Reference. Проблема только в производительности и удобстве использования той или иной реализации. Но всё зависит от твоих потребностей (дизайна игры) и способности оптимизировать игру на высоком уровне, допустим, выгружая лишние чанки со всеми принадлежащими им существами из оперативной памяти.
Симуляция жизни как жанр не требует тысяч существ одновременно, достаточно одного существа, пытающегося как-то выжить в маленьком статичном мире. Или двух существ, борющихся друг с другом за какие-то цели. Первые эксперименты с виртуальной жизнью так и происходили, в очень маленьком масштабе, с малым числом существ и характеристик этих существ. Ты просто замахиваешься на слишком масштабные цели...
>>17612
Ну можно, да, можно, делай, пробуй. Способов несколько, не обязательно ноды мышкой таскать...
Лучше, но потому, что сложную структуру мира и существ может быть оптимальнее хранить в какой-то бинарной структуре (по типу файловой системы ОС), чем в JSON или другом текстовом формате. В текстовом формате у тебя могут оказаться гигабайты данных на визуально примитивный мир (а-ля майнкрафт). А для JSON есть встроенные инструменты, я ими пользуюсь, всё прекрасно.
Ты же вроде знаешь C++, вот иди изучай исходники движка)
>>17616
С точки зрения геймплея будет значительно лучше сделать полноценную 3D игру, чем насиловать 2D тайлы. Так тебе не придётся реализовывать всякие "хитрости" для отображения 3D структур в 2D тайловом мире, а игроку не придётся ломать голову и клавиатуру в попытке эти структуры понять. Я знаю, что подобные игры есть (CDDA, например, там транспорт из тайлов строится), но они для очень узкой ЦА, для каких-то особых ценителей стиля (ASCII, вот это всё).
Ну это-то как раз не сложно. Dictionary с перечислением всех органов и их состояний, и какой-то метод для изменения состояний. Гены вообще могут описывать что угодно в рамках вымышленного виртуального мира, следовательно, никаких ограничений в плане генетики нет - делай что хочешь, и это можно будет назвать "генетикой", если там есть "гены". Совсем другое дело, если ты хочешь реализовать точную модель ИРЛ генетики...
Делай один. Рекомендую на основе вики-движка, например, вот https://tiddlywiki.com/ удобная штука в стиле вики.
>>17617
Ясно, понятно, меня лично интересует только чтобы "пешки" были не простыми "пешками", а жили по-настоящему как люди, и могли справиться с возникающими проблемами, например, не позволить игроку проводить над ними эксперименты) Делать полноценную сложную симуляцию жизни для простой выживалки-песочницы "для экспериментов игрока над тупыми ботами" как минимум бессмысленно, тех же результатов можно добиться без какой-либо симуляции (а-ля майнкрафт - в нём симуляции считай что нет).
Рекомендую начать с простейшего и самого основного, а уже потом добавлять какие-то идеи. Сделай для начала 2D тайловую карту (TileMap), одного персонажа и его навигацию по клеткам карты, чтобы он шёл до клетки, на которую кликнул игрок, обходя препятствия. Это сравнительно просто с использованием встроенных инструментов. Потом добавь на карту какую-нибудь еду, а персонажу добавь самостоятельный выбор цели, чтобы он шёл есть еду, когда у него начинается голод. И так далее, постепенно усложняя поведение и наполнение мира. Так у тебя уже будет какая-то основа для игры, которую можно будет дорабатывать или переделывать на другую архитектуру, если ты придумаешь что-то лучше, или переносить на другой движок/ЯП/платформу. А пока ты только теоретизируешь, работа с места не сдвинется...
>какой то ECS из него сделать хотел
Я думаю, для этого следует написать свой C++ модуль, который будет объявлять "сущность", "компонент" и "систему", а на GDScript только создавать и заполнять их. Чтобы все операции с памятью были под контролем и хорошо оптимизированы. Чисто на GDScript можно сделать ECS, но она будет медленной и прожорливой.
>Когда у тебя всё на компонентах...
Да, я всё это прекрасно знаю. И на Godot это всё можно легко реализовать, хоть на нодах, хоть на компонентах, хоть на Reference. Проблема только в производительности и удобстве использования той или иной реализации. Но всё зависит от твоих потребностей (дизайна игры) и способности оптимизировать игру на высоком уровне, допустим, выгружая лишние чанки со всеми принадлежащими им существами из оперативной памяти.
Симуляция жизни как жанр не требует тысяч существ одновременно, достаточно одного существа, пытающегося как-то выжить в маленьком статичном мире. Или двух существ, борющихся друг с другом за какие-то цели. Первые эксперименты с виртуальной жизнью так и происходили, в очень маленьком масштабе, с малым числом существ и характеристик этих существ. Ты просто замахиваешься на слишком масштабные цели...
>>17612
>хотя бы какой-то можно было кулякать игру в достаточном стиле composition over inheritance.
Ну можно, да, можно, делай, пробуй. Способов несколько, не обязательно ноды мышкой таскать...
>лучше будет написать отдельный сервер
Лучше, но потому, что сложную структуру мира и существ может быть оптимальнее хранить в какой-то бинарной структуре (по типу файловой системы ОС), чем в JSON или другом текстовом формате. В текстовом формате у тебя могут оказаться гигабайты данных на визуально примитивный мир (а-ля майнкрафт). А для JSON есть встроенные инструменты, я ими пользуюсь, всё прекрасно.
>непонятнокаквсёработает
Ты же вроде знаешь C++, вот иди изучай исходники движка)
>>17616
>Графика 2д, тайлы
>графика минималистичная,
>система транспорта/вложенных уровней
>Транспорт ездиет, вращается на 180 градусов.
С точки зрения геймплея будет значительно лучше сделать полноценную 3D игру, чем насиловать 2D тайлы. Так тебе не придётся реализовывать всякие "хитрости" для отображения 3D структур в 2D тайловом мире, а игроку не придётся ломать голову и клавиатуру в попытке эти структуры понять. Я знаю, что подобные игры есть (CDDA, например, там транспорт из тайлов строится), но они для очень узкой ЦА, для каких-то особых ценителей стиля (ASCII, вот это всё).
>Система органов, генетики
Ну это-то как раз не сложно. Dictionary с перечислением всех органов и их состояний, и какой-то метод для изменения состояний. Гены вообще могут описывать что угодно в рамках вымышленного виртуального мира, следовательно, никаких ограничений в плане генетики нет - делай что хочешь, и это можно будет назвать "генетикой", если там есть "гены". Совсем другое дело, если ты хочешь реализовать точную модель ИРЛ генетики...
>скок ДИЗДОКОВ
Делай один. Рекомендую на основе вики-движка, например, вот https://tiddlywiki.com/ удобная штука в стиле вики.
>>17617
>всякие генетико-механические эксперименты над пешками.
Ясно, понятно, меня лично интересует только чтобы "пешки" были не простыми "пешками", а жили по-настоящему как люди, и могли справиться с возникающими проблемами, например, не позволить игроку проводить над ними эксперименты) Делать полноценную сложную симуляцию жизни для простой выживалки-песочницы "для экспериментов игрока над тупыми ботами" как минимум бессмысленно, тех же результатов можно добиться без какой-либо симуляции (а-ля майнкрафт - в нём симуляции считай что нет).
>если даже просто с инструментом сладить не могу, какие тут рогалики.
Рекомендую начать с простейшего и самого основного, а уже потом добавлять какие-то идеи. Сделай для начала 2D тайловую карту (TileMap), одного персонажа и его навигацию по клеткам карты, чтобы он шёл до клетки, на которую кликнул игрок, обходя препятствия. Это сравнительно просто с использованием встроенных инструментов. Потом добавь на карту какую-нибудь еду, а персонажу добавь самостоятельный выбор цели, чтобы он шёл есть еду, когда у него начинается голод. И так далее, постепенно усложняя поведение и наполнение мира. Так у тебя уже будет какая-то основа для игры, которую можно будет дорабатывать или переделывать на другую архитектуру, если ты придумаешь что-то лучше, или переносить на другой движок/ЯП/платформу. А пока ты только теоретизируешь, работа с места не сдвинется...
>>17629
Уже кстати есть GodeX, я даже с автором общался некоторое время но он ее забросил, а код внутри эт пиздос.
Я кстати особо то и не хотел, ну может максимум пару сотен, и то в городах. Наверное всё таки если грамотно организовывать высокую логику то можно хоть и на нодах делать композицию.
Хранить только измнения в мире + существ и всякие стейты хранить как патчи. Но вообще годот свою систему схоронений имеет, а JSON файлы скорее для быстрого добавления тысяч вещей всяких
Я таки на 2Д изначально и нацеливался, уже думал про 3д но там очень много работы бы тогда было по контент-генерации. с 2д достаточно адаптировать XML редакторы и вынести SVGtoTexture в рантайм. Тут я как бы просекаю как решить этот вопрос.
Нет не точную, смысла нет. достаточно просто жирный хер распиленный по блокам, и условные веса для каждого параметра (какие то повышают какие-то наоборот) раскиданные рандомно по символам хеша. Даже если у тебя будет аппарат где ты можешь точечно какой-нибудь сабаке менять гены, и производить быструю футуристичную генную терапию, хз чо выйдет. При этом там в системе генетики еще есть "большие-мутации", то есть ты увеличил силу настолько, что у твоей собаки уже не просто мышцы наросли, а мышцы например (технически) заменяются на другую часть тела, условно ГИГАМышцы. или глаза мутируют и можно видеть теперь инфракрасный цвет.
Часть в тиддли лежит, часть в Notion
Пешками называют в римворлде болванчиков. Офк можно сделать чтобы они при попытке шото там сделать (их еще в камеру генной терапии запихнуть надо умудриться), ебашили в челюсть или просто убегали. Конечно симуляцию интеллекта и приятия решений я тоже хотел въебать.
Меня просто мысль тормозит что я вот сейчас сделаю что-нибудь, и пойму что выжать достойную производительность не получится даже с учетом переписывания под С++. По идее больше 200-400 существ активных держать не придётся. Если ноды не тикают постоянно, они вроде как не обрабатываются, потому статические предметы (декали, ошмётки говна в огромном количестве) могут спокойно находиться тысячами на уровне, так или нет?
>Я думаю, для этого следует написать свой C++ модуль, который будет объявлять "сущность", "компонент" и "систему"
Уже кстати есть GodeX, я даже с автором общался некоторое время но он ее забросил, а код внутри эт пиздос.
>Симуляция жизни как жанр не требует тысяч существ одновременно
Я кстати особо то и не хотел, ну может максимум пару сотен, и то в городах. Наверное всё таки если грамотно организовывать высокую логику то можно хоть и на нодах делать композицию.
>оказаться гигабайты данных
Хранить только измнения в мире + существ и всякие стейты хранить как патчи. Но вообще годот свою систему схоронений имеет, а JSON файлы скорее для быстрого добавления тысяч вещей всяких
>С точки зрения геймплея будет значительно лучше сделать полноценную 3D игру, чем насиловать 2D тайлы.
Я таки на 2Д изначально и нацеливался, уже думал про 3д но там очень много работы бы тогда было по контент-генерации. с 2д достаточно адаптировать XML редакторы и вынести SVGtoTexture в рантайм. Тут я как бы просекаю как решить этот вопрос.
>Совсем другое дело, если ты хочешь реализовать точную модель ИРЛ генетики...
Нет не точную, смысла нет. достаточно просто жирный хер распиленный по блокам, и условные веса для каждого параметра (какие то повышают какие-то наоборот) раскиданные рандомно по символам хеша. Даже если у тебя будет аппарат где ты можешь точечно какой-нибудь сабаке менять гены, и производить быструю футуристичную генную терапию, хз чо выйдет. При этом там в системе генетики еще есть "большие-мутации", то есть ты увеличил силу настолько, что у твоей собаки уже не просто мышцы наросли, а мышцы например (технически) заменяются на другую часть тела, условно ГИГАМышцы. или глаза мутируют и можно видеть теперь инфракрасный цвет.
>скок ДИЗДОКОВ
Часть в тиддли лежит, часть в Notion
> только чтобы "пешки" были не простыми "пешками", а жили по-настоящему как люди, и могли справиться с возникающими проблемами
Пешками называют в римворлде болванчиков. Офк можно сделать чтобы они при попытке шото там сделать (их еще в камеру генной терапии запихнуть надо умудриться), ебашили в челюсть или просто убегали. Конечно симуляцию интеллекта и приятия решений я тоже хотел въебать.
>Рекомендую начать с простейшего и самого основного, а уже потом добавлять какие-то идеи.
Меня просто мысль тормозит что я вот сейчас сделаю что-нибудь, и пойму что выжать достойную производительность не получится даже с учетом переписывания под С++. По идее больше 200-400 существ активных держать не придётся. Если ноды не тикают постоянно, они вроде как не обрабатываются, потому статические предметы (декали, ошмётки говна в огромном количестве) могут спокойно находиться тысячами на уровне, так или нет?
>>17629
Уже кстати есть GodeX, я даже с автором общался некоторое время но он ее забросил, а код внутри эт пиздос.
Я кстати особо то и не хотел, ну может максимум пару сотен, и то в городах. Наверное всё таки если грамотно организовывать высокую логику то можно хоть и на нодах делать композицию.
Хранить только измнения в мире + существ и всякие стейты хранить как патчи. Но вообще годот свою систему схоронений имеет, а JSON файлы скорее для быстрого добавления тысяч вещей всяких
Я таки на 2Д изначально и нацеливался, уже думал про 3д но там очень много работы бы тогда было по контент-генерации. с 2д достаточно адаптировать XML редакторы и вынести SVGtoTexture в рантайм. Тут я как бы просекаю как решить этот вопрос.
Нет не точную, смысла нет. достаточно просто жирный хер распиленный по блокам, и условные веса для каждого параметра (какие то повышают какие-то наоборот) раскиданные рандомно по символам хеша. Даже если у тебя будет аппарат где ты можешь точечно какой-нибудь сабаке менять гены, и производить быструю футуристичную генную терапию, хз чо выйдет. При этом там в системе генетики еще есть "большие-мутации", то есть ты увеличил силу настолько, что у твоей собаки уже не просто мышцы наросли, а мышцы например (технически) заменяются на другую часть тела, условно ГИГАМышцы. или глаза мутируют и можно видеть теперь инфракрасный цвет.
Часть в тиддли лежит, часть в Notion
Пешками называют в римворлде болванчиков. Офк можно сделать чтобы они при попытке шото там сделать (их еще в камеру генной терапии запихнуть надо умудриться), ебашили в челюсть или просто убегали. Конечно симуляцию интеллекта и приятия решений я тоже хотел въебать.
Меня просто мысль тормозит что я вот сейчас сделаю что-нибудь, и пойму что выжать достойную производительность не получится даже с учетом переписывания под С++. По идее больше 200-400 существ активных держать не придётся. Если ноды не тикают постоянно, они вроде как не обрабатываются, потому статические предметы (декали, ошмётки говна в огромном количестве) могут спокойно находиться тысячами на уровне, так или нет?
>Я думаю, для этого следует написать свой C++ модуль, который будет объявлять "сущность", "компонент" и "систему"
Уже кстати есть GodeX, я даже с автором общался некоторое время но он ее забросил, а код внутри эт пиздос.
>Симуляция жизни как жанр не требует тысяч существ одновременно
Я кстати особо то и не хотел, ну может максимум пару сотен, и то в городах. Наверное всё таки если грамотно организовывать высокую логику то можно хоть и на нодах делать композицию.
>оказаться гигабайты данных
Хранить только измнения в мире + существ и всякие стейты хранить как патчи. Но вообще годот свою систему схоронений имеет, а JSON файлы скорее для быстрого добавления тысяч вещей всяких
>С точки зрения геймплея будет значительно лучше сделать полноценную 3D игру, чем насиловать 2D тайлы.
Я таки на 2Д изначально и нацеливался, уже думал про 3д но там очень много работы бы тогда было по контент-генерации. с 2д достаточно адаптировать XML редакторы и вынести SVGtoTexture в рантайм. Тут я как бы просекаю как решить этот вопрос.
>Совсем другое дело, если ты хочешь реализовать точную модель ИРЛ генетики...
Нет не точную, смысла нет. достаточно просто жирный хер распиленный по блокам, и условные веса для каждого параметра (какие то повышают какие-то наоборот) раскиданные рандомно по символам хеша. Даже если у тебя будет аппарат где ты можешь точечно какой-нибудь сабаке менять гены, и производить быструю футуристичную генную терапию, хз чо выйдет. При этом там в системе генетики еще есть "большие-мутации", то есть ты увеличил силу настолько, что у твоей собаки уже не просто мышцы наросли, а мышцы например (технически) заменяются на другую часть тела, условно ГИГАМышцы. или глаза мутируют и можно видеть теперь инфракрасный цвет.
>скок ДИЗДОКОВ
Часть в тиддли лежит, часть в Notion
> только чтобы "пешки" были не простыми "пешками", а жили по-настоящему как люди, и могли справиться с возникающими проблемами
Пешками называют в римворлде болванчиков. Офк можно сделать чтобы они при попытке шото там сделать (их еще в камеру генной терапии запихнуть надо умудриться), ебашили в челюсть или просто убегали. Конечно симуляцию интеллекта и приятия решений я тоже хотел въебать.
>Рекомендую начать с простейшего и самого основного, а уже потом добавлять какие-то идеи.
Меня просто мысль тормозит что я вот сейчас сделаю что-нибудь, и пойму что выжать достойную производительность не получится даже с учетом переписывания под С++. По идее больше 200-400 существ активных держать не придётся. Если ноды не тикают постоянно, они вроде как не обрабатываются, потому статические предметы (декали, ошмётки говна в огромном количестве) могут спокойно находиться тысячами на уровне, так или нет?
>>17640
Имеется ввиду не просто что нибудь а такой существенный шматок проекта.
>тормозит что я вот сейчас сделаю что-нибудь
Имеется ввиду не просто что нибудь а такой существенный шматок проекта.
>>17640
Зависит от желаемого результата. Я предлагаю 3D только как средство ориентации в пространстве, т.е. чтобы можно было мышкой вращать орбитальную камеру, приближать и отдалять, менять точку фокуса и т.д. Или ходить по помещениям от первого лица. Статичная геометрия может быть из заранее созданных деталек на GridMap, а динамические модельки можно либо заменить на спрайты (а-ля DOOM), либо соединять из готовых деталек. Если не нравится стиль Minecraft, глянь LEGO Worlds. Тебе ведь не обязательно генерировать модели уровня SPORE (хотя инструменты для такой генерации в Godot есть, но на GDScript большие массивы точек долго обрабатывать).
Я лично не хочу играть в Dwarf Fortress (и аналоги) в частности потому, что мир там очень тяжело воспринимать. Он трёхмерный, но ты видишь только 2D проекцию среза, и это очень неудобно, даже не считая управления. Вроде есть какие-то 3D рендереры для DF, но настраивать всё это лень, если уж сел играть - игра должна быть играбельной из коробки, а не требовать сборку из деталей. Поэтому у него и аудитория такая маленькая, имхо.
В предыдущем треде было видео, там 500+ Spatial с прикреплённой 3D моделькой двигались по маршрутам. Существенно лагать начинало только после 1000 таких 3D моделек, и то, по-моему, там проблема с количеством вызовов отрисовки (обращений к видеокарте). В 2D, если часть спрайтов за пределами видимой области экрана, я думаю, можно сделать больше независимых существ почти без ручной оптимизации. Но это не считая всей той логики, которую они будут выполнять периодически. Ну и зависит от компьютера...
Могут, но могут потребоваться оптимизации. Честно говоря, я интересуюсь в основном 3D и не делал стресс-тестов в 2D, так что без понятия, на каком количестве объектов могут потребоваться оптимизации. Всё же предлагаю доверять руководству и не множить ноды десятками тысяч без необходимости...
Для примера, может быть такая оптимизация: если у тебя 2D тайловый мир как в RimWorld, брошенный на землю предмет может образовывать "контейнер", который висит в дереве сцены и выводит спрайт последнего брошенного на землю предмета, собирая в себя все остальные брошенные предметы и извлекая их из дерева сцены. Если предмет берётся из этой стопки персонажем, стопка обновляет спрайт на следующий предмет в очереди на извлечение, а персонажу отдаёт ноду/ресурс извлечённого предмета. После извлечения последнего предмета стопка уничтожается, исчезая из сцены. Вряд ли тебе потребуется иметь стопку на каждом тайле карты, верно?
>Я таки на 2Д изначально и нацеливался, уже думал про 3д но там очень много работы бы тогда было по контент-генерации.
Зависит от желаемого результата. Я предлагаю 3D только как средство ориентации в пространстве, т.е. чтобы можно было мышкой вращать орбитальную камеру, приближать и отдалять, менять точку фокуса и т.д. Или ходить по помещениям от первого лица. Статичная геометрия может быть из заранее созданных деталек на GridMap, а динамические модельки можно либо заменить на спрайты (а-ля DOOM), либо соединять из готовых деталек. Если не нравится стиль Minecraft, глянь LEGO Worlds. Тебе ведь не обязательно генерировать модели уровня SPORE (хотя инструменты для такой генерации в Godot есть, но на GDScript большие массивы точек долго обрабатывать).
Я лично не хочу играть в Dwarf Fortress (и аналоги) в частности потому, что мир там очень тяжело воспринимать. Он трёхмерный, но ты видишь только 2D проекцию среза, и это очень неудобно, даже не считая управления. Вроде есть какие-то 3D рендереры для DF, но настраивать всё это лень, если уж сел играть - игра должна быть играбельной из коробки, а не требовать сборку из деталей. Поэтому у него и аудитория такая маленькая, имхо.
>По идее больше 200-400 существ активных держать не придётся.
В предыдущем треде было видео, там 500+ Spatial с прикреплённой 3D моделькой двигались по маршрутам. Существенно лагать начинало только после 1000 таких 3D моделек, и то, по-моему, там проблема с количеством вызовов отрисовки (обращений к видеокарте). В 2D, если часть спрайтов за пределами видимой области экрана, я думаю, можно сделать больше независимых существ почти без ручной оптимизации. Но это не считая всей той логики, которую они будут выполнять периодически. Ну и зависит от компьютера...
>статические предметы могут спокойно находиться тысячами на уровне, так или нет?
Могут, но могут потребоваться оптимизации. Честно говоря, я интересуюсь в основном 3D и не делал стресс-тестов в 2D, так что без понятия, на каком количестве объектов могут потребоваться оптимизации. Всё же предлагаю доверять руководству и не множить ноды десятками тысяч без необходимости...
Для примера, может быть такая оптимизация: если у тебя 2D тайловый мир как в RimWorld, брошенный на землю предмет может образовывать "контейнер", который висит в дереве сцены и выводит спрайт последнего брошенного на землю предмета, собирая в себя все остальные брошенные предметы и извлекая их из дерева сцены. Если предмет берётся из этой стопки персонажем, стопка обновляет спрайт на следующий предмет в очереди на извлечение, а персонажу отдаёт ноду/ресурс извлечённого предмета. После извлечения последнего предмета стопка уничтожается, исчезая из сцены. Вряд ли тебе потребуется иметь стопку на каждом тайле карты, верно?
>>17640
Зависит от желаемого результата. Я предлагаю 3D только как средство ориентации в пространстве, т.е. чтобы можно было мышкой вращать орбитальную камеру, приближать и отдалять, менять точку фокуса и т.д. Или ходить по помещениям от первого лица. Статичная геометрия может быть из заранее созданных деталек на GridMap, а динамические модельки можно либо заменить на спрайты (а-ля DOOM), либо соединять из готовых деталек. Если не нравится стиль Minecraft, глянь LEGO Worlds. Тебе ведь не обязательно генерировать модели уровня SPORE (хотя инструменты для такой генерации в Godot есть, но на GDScript большие массивы точек долго обрабатывать).
Я лично не хочу играть в Dwarf Fortress (и аналоги) в частности потому, что мир там очень тяжело воспринимать. Он трёхмерный, но ты видишь только 2D проекцию среза, и это очень неудобно, даже не считая управления. Вроде есть какие-то 3D рендереры для DF, но настраивать всё это лень, если уж сел играть - игра должна быть играбельной из коробки, а не требовать сборку из деталей. Поэтому у него и аудитория такая маленькая, имхо.
В предыдущем треде было видео, там 500+ Spatial с прикреплённой 3D моделькой двигались по маршрутам. Существенно лагать начинало только после 1000 таких 3D моделек, и то, по-моему, там проблема с количеством вызовов отрисовки (обращений к видеокарте). В 2D, если часть спрайтов за пределами видимой области экрана, я думаю, можно сделать больше независимых существ почти без ручной оптимизации. Но это не считая всей той логики, которую они будут выполнять периодически. Ну и зависит от компьютера...
Могут, но могут потребоваться оптимизации. Честно говоря, я интересуюсь в основном 3D и не делал стресс-тестов в 2D, так что без понятия, на каком количестве объектов могут потребоваться оптимизации. Всё же предлагаю доверять руководству и не множить ноды десятками тысяч без необходимости...
Для примера, может быть такая оптимизация: если у тебя 2D тайловый мир как в RimWorld, брошенный на землю предмет может образовывать "контейнер", который висит в дереве сцены и выводит спрайт последнего брошенного на землю предмета, собирая в себя все остальные брошенные предметы и извлекая их из дерева сцены. Если предмет берётся из этой стопки персонажем, стопка обновляет спрайт на следующий предмет в очереди на извлечение, а персонажу отдаёт ноду/ресурс извлечённого предмета. После извлечения последнего предмета стопка уничтожается, исчезая из сцены. Вряд ли тебе потребуется иметь стопку на каждом тайле карты, верно?
>Я таки на 2Д изначально и нацеливался, уже думал про 3д но там очень много работы бы тогда было по контент-генерации.
Зависит от желаемого результата. Я предлагаю 3D только как средство ориентации в пространстве, т.е. чтобы можно было мышкой вращать орбитальную камеру, приближать и отдалять, менять точку фокуса и т.д. Или ходить по помещениям от первого лица. Статичная геометрия может быть из заранее созданных деталек на GridMap, а динамические модельки можно либо заменить на спрайты (а-ля DOOM), либо соединять из готовых деталек. Если не нравится стиль Minecraft, глянь LEGO Worlds. Тебе ведь не обязательно генерировать модели уровня SPORE (хотя инструменты для такой генерации в Godot есть, но на GDScript большие массивы точек долго обрабатывать).
Я лично не хочу играть в Dwarf Fortress (и аналоги) в частности потому, что мир там очень тяжело воспринимать. Он трёхмерный, но ты видишь только 2D проекцию среза, и это очень неудобно, даже не считая управления. Вроде есть какие-то 3D рендереры для DF, но настраивать всё это лень, если уж сел играть - игра должна быть играбельной из коробки, а не требовать сборку из деталей. Поэтому у него и аудитория такая маленькая, имхо.
>По идее больше 200-400 существ активных держать не придётся.
В предыдущем треде было видео, там 500+ Spatial с прикреплённой 3D моделькой двигались по маршрутам. Существенно лагать начинало только после 1000 таких 3D моделек, и то, по-моему, там проблема с количеством вызовов отрисовки (обращений к видеокарте). В 2D, если часть спрайтов за пределами видимой области экрана, я думаю, можно сделать больше независимых существ почти без ручной оптимизации. Но это не считая всей той логики, которую они будут выполнять периодически. Ну и зависит от компьютера...
>статические предметы могут спокойно находиться тысячами на уровне, так или нет?
Могут, но могут потребоваться оптимизации. Честно говоря, я интересуюсь в основном 3D и не делал стресс-тестов в 2D, так что без понятия, на каком количестве объектов могут потребоваться оптимизации. Всё же предлагаю доверять руководству и не множить ноды десятками тысяч без необходимости...
Для примера, может быть такая оптимизация: если у тебя 2D тайловый мир как в RimWorld, брошенный на землю предмет может образовывать "контейнер", который висит в дереве сцены и выводит спрайт последнего брошенного на землю предмета, собирая в себя все остальные брошенные предметы и извлекая их из дерева сцены. Если предмет берётся из этой стопки персонажем, стопка обновляет спрайт на следующий предмет в очереди на извлечение, а персонажу отдаёт ноду/ресурс извлечённого предмета. После извлечения последнего предмета стопка уничтожается, исчезая из сцены. Вряд ли тебе потребуется иметь стопку на каждом тайле карты, верно?
>>17686
Да я изначально также и хотел, просто потом подумалось что генерить десятки разных видов КАМНЕЙ будет намного лучше если ты просто сделаешь что то типа вот:
{
"type": "static",
"id" : "test_stone_gabbro",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 31.10,
"density": 10,
"govnyak": 5112,
},
"colors": {
"primary": "#111111",
"subtone": "#123123",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_slate",
"template": "test_stone // Считай берем любой предмет и патчим его нашим слейтом",
"materail": {
"thicc": 21.14,
"density": 8,
"govnyak": 5125,
},
"colors": {
"primary": "#a5511a",
"subtone": "#a33333",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_granite",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 68,
"density": 21,
"govnyak": 4124,
},
"colors": {
"primary": "#b1a1f1",
"subtone": "#c1f1f1",
"something": "#444444",
}
}
Если делать 3д, то придется намного больше заёбываться с визуалом. НАМНОГО больше. Потому что просто кубоидами оставлять я это всё не собираюсь. Тогда сразу надо будет поддерживать кастомные модели, эти кастомные модели в огромных количествах делать, а там и до анимации этих кастомных моделей недалеко. Ну нахуй это. Тот же римач выглядит вполне красиво, просто считай по хитрому отображение верхних уровней попробую зделоть. Может по восприятию игра и станет легче но и у меня силы не бесконечные всё это педалировать. Я бы хотел, но хз, очень хз что вывезу 3д.
Дык а рогалики это андерграунд нахуй, не знаю, мне лично и так воспринимать дф норм, тем более раз я взялся делать многослойное 2д, то попробую сделать его насколько могу заебись.
Обнадёживает
Да, я что-то такое хотел сделать. Только еще используя наложение нескольких предметов (похожее на спейс стейшон), и когда предметов оч много куча превращается в месиво из рандома + самые объемистые предметы в ней. Может и без последнего пункта но что-то подобное можно.
Ха-ха. Ты ещё не видел что за свинарник на карте происходит когда в cataclysm dda ты на полной скорости въезжаешь в толпу зомби. Вся дорога просто фаршем покрывается.
>Статичная геометрия может быть из заранее созданных деталек на GridMap
Да я изначально также и хотел, просто потом подумалось что генерить десятки разных видов КАМНЕЙ будет намного лучше если ты просто сделаешь что то типа вот:
{
"type": "static",
"id" : "test_stone_gabbro",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 31.10,
"density": 10,
"govnyak": 5112,
},
"colors": {
"primary": "#111111",
"subtone": "#123123",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_slate",
"template": "test_stone // Считай берем любой предмет и патчим его нашим слейтом",
"materail": {
"thicc": 21.14,
"density": 8,
"govnyak": 5125,
},
"colors": {
"primary": "#a5511a",
"subtone": "#a33333",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_granite",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 68,
"density": 21,
"govnyak": 4124,
},
"colors": {
"primary": "#b1a1f1",
"subtone": "#c1f1f1",
"something": "#444444",
}
}
Если делать 3д, то придется намного больше заёбываться с визуалом. НАМНОГО больше. Потому что просто кубоидами оставлять я это всё не собираюсь. Тогда сразу надо будет поддерживать кастомные модели, эти кастомные модели в огромных количествах делать, а там и до анимации этих кастомных моделей недалеко. Ну нахуй это. Тот же римач выглядит вполне красиво, просто считай по хитрому отображение верхних уровней попробую зделоть. Может по восприятию игра и станет легче но и у меня силы не бесконечные всё это педалировать. Я бы хотел, но хз, очень хз что вывезу 3д.
>Я лично не хочу играть в Dwarf Fortress (и аналоги) в частности потому, что мир там очень тяжело воспринимать.
Дык а рогалики это андерграунд нахуй, не знаю, мне лично и так воспринимать дф норм, тем более раз я взялся делать многослойное 2д, то попробую сделать его насколько могу заебись.
>В предыдущем треде было видео, там 500+ Spatial с прикреплённой 3D моделькой двигались по маршрутам.
Обнадёживает
>Для примера, может быть такая оптимизация: если у тебя 2D тайловый мир как в RimWorld
Да, я что-то такое хотел сделать. Только еще используя наложение нескольких предметов (похожее на спейс стейшон), и когда предметов оч много куча превращается в месиво из рандома + самые объемистые предметы в ней. Может и без последнего пункта но что-то подобное можно.
>Вряд ли тебе потребуется иметь стопку на каждом тайле карты, верно?
Ха-ха. Ты ещё не видел что за свинарник на карте происходит когда в cataclysm dda ты на полной скорости въезжаешь в толпу зомби. Вся дорога просто фаршем покрывается.
>>17686
Да я изначально также и хотел, просто потом подумалось что генерить десятки разных видов КАМНЕЙ будет намного лучше если ты просто сделаешь что то типа вот:
{
"type": "static",
"id" : "test_stone_gabbro",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 31.10,
"density": 10,
"govnyak": 5112,
},
"colors": {
"primary": "#111111",
"subtone": "#123123",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_slate",
"template": "test_stone // Считай берем любой предмет и патчим его нашим слейтом",
"materail": {
"thicc": 21.14,
"density": 8,
"govnyak": 5125,
},
"colors": {
"primary": "#a5511a",
"subtone": "#a33333",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_granite",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 68,
"density": 21,
"govnyak": 4124,
},
"colors": {
"primary": "#b1a1f1",
"subtone": "#c1f1f1",
"something": "#444444",
}
}
Если делать 3д, то придется намного больше заёбываться с визуалом. НАМНОГО больше. Потому что просто кубоидами оставлять я это всё не собираюсь. Тогда сразу надо будет поддерживать кастомные модели, эти кастомные модели в огромных количествах делать, а там и до анимации этих кастомных моделей недалеко. Ну нахуй это. Тот же римач выглядит вполне красиво, просто считай по хитрому отображение верхних уровней попробую зделоть. Может по восприятию игра и станет легче но и у меня силы не бесконечные всё это педалировать. Я бы хотел, но хз, очень хз что вывезу 3д.
Дык а рогалики это андерграунд нахуй, не знаю, мне лично и так воспринимать дф норм, тем более раз я взялся делать многослойное 2д, то попробую сделать его насколько могу заебись.
Обнадёживает
Да, я что-то такое хотел сделать. Только еще используя наложение нескольких предметов (похожее на спейс стейшон), и когда предметов оч много куча превращается в месиво из рандома + самые объемистые предметы в ней. Может и без последнего пункта но что-то подобное можно.
Ха-ха. Ты ещё не видел что за свинарник на карте происходит когда в cataclysm dda ты на полной скорости въезжаешь в толпу зомби. Вся дорога просто фаршем покрывается.
>Статичная геометрия может быть из заранее созданных деталек на GridMap
Да я изначально также и хотел, просто потом подумалось что генерить десятки разных видов КАМНЕЙ будет намного лучше если ты просто сделаешь что то типа вот:
{
"type": "static",
"id" : "test_stone_gabbro",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 31.10,
"density": 10,
"govnyak": 5112,
},
"colors": {
"primary": "#111111",
"subtone": "#123123",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_slate",
"template": "test_stone // Считай берем любой предмет и патчим его нашим слейтом",
"materail": {
"thicc": 21.14,
"density": 8,
"govnyak": 5125,
},
"colors": {
"primary": "#a5511a",
"subtone": "#a33333",
"something": "#444444",
}
},
{
"type": "static",
"id" : "test_stone_granite",
"template": "test_stone // Считай берем любой предмет и патчим его нашим габбро",
"materail": {
"thicc": 68,
"density": 21,
"govnyak": 4124,
},
"colors": {
"primary": "#b1a1f1",
"subtone": "#c1f1f1",
"something": "#444444",
}
}
Если делать 3д, то придется намного больше заёбываться с визуалом. НАМНОГО больше. Потому что просто кубоидами оставлять я это всё не собираюсь. Тогда сразу надо будет поддерживать кастомные модели, эти кастомные модели в огромных количествах делать, а там и до анимации этих кастомных моделей недалеко. Ну нахуй это. Тот же римач выглядит вполне красиво, просто считай по хитрому отображение верхних уровней попробую зделоть. Может по восприятию игра и станет легче но и у меня силы не бесконечные всё это педалировать. Я бы хотел, но хз, очень хз что вывезу 3д.
>Я лично не хочу играть в Dwarf Fortress (и аналоги) в частности потому, что мир там очень тяжело воспринимать.
Дык а рогалики это андерграунд нахуй, не знаю, мне лично и так воспринимать дф норм, тем более раз я взялся делать многослойное 2д, то попробую сделать его насколько могу заебись.
>В предыдущем треде было видео, там 500+ Spatial с прикреплённой 3D моделькой двигались по маршрутам.
Обнадёживает
>Для примера, может быть такая оптимизация: если у тебя 2D тайловый мир как в RimWorld
Да, я что-то такое хотел сделать. Только еще используя наложение нескольких предметов (похожее на спейс стейшон), и когда предметов оч много куча превращается в месиво из рандома + самые объемистые предметы в ней. Может и без последнего пункта но что-то подобное можно.
>Вряд ли тебе потребуется иметь стопку на каждом тайле карты, верно?
Ха-ха. Ты ещё не видел что за свинарник на карте происходит когда в cataclysm dda ты на полной скорости въезжаешь в толпу зомби. Вся дорога просто фаршем покрывается.
>>17694
Зачем тебе десятки видов КАМНЕЙ? Так ли уж они нужны песочнице, тем более с ориентацией на симуляцию жизни? Даже в майнкрафте есть всего одна текстура камня, который природно генерируется, в последних версиях добавили ещё несколько видов каменных пород, но суть не сильно изменилась. Тем не менее, майнкрафт даже в ванильной версии достаточно хорошо справляется с процедурной генерацией мира. А в симуляторе жизни тебе вообще не важны камни и их отображение, главное чтобы камень можно было отличить от всего, что камнем не является. В симуляторе жизни фокус на формах жизни или конкретном разумном виде жизни, но даже так их внешний вид вторичен и редко выходит за пределы "комбинация кусочков из нескольких ограниченных наборов кусочков" - как в 2D, так и в 3D. Главное чтобы игрок мог отличить жителя А от жителя Б за приемлемое время, т.е. не тратил много времени на поиски (поэтому отличия должны быть существенными).
Ну и? Подобная структура в JSON будет в любой достаточно сложной игре, что 2D, что 3D, что со статичной картой, что с процедурной генерацией всего и вся. Потому что альтернатива - хардкод, а это нехорошо для гибкой разработки. Разница между структурами будет только в частных ресурсах и параметрах, например, в 2D может быть ссылка на sprite(sheet).png и его размер/поворот, в 3D - на mesh.obj и его масштаб/поворот, но это несущественно. Тебя никто не заставляет генерировать меш параметрически (хотя в этом нет особой сложности, если тебя устроят лоуполи модели).
Ты буквально хочешь какую-то 2D фигню из SVG кругов и квадратов, но в 3D тебе обязательно ультрареализм?
В Godot всё необходимое доступно из коробки.
Ты можешь процедурно комбинировать несколько базовых мешей, создавая миллионы возможных комбинаций не считая расцветок. Лучше, конечно, если графика будет достаточно абстрактной, и уж тем более не реализм (No Man's Sky... а, нет, там не такой уж реализм).
Да пофиг, инди редко имеют хорошие анимации, можно обойтись чем-то минимальным и абстрактным, так многие делают. Суть твоей игры ведь не в анимациях и даже не в красоте моделек.
Думай в первую очередь о геймплее и удобстве игрока. RimWorld не зря однослойный, это многое упрощает. Я тоже когда-то думал сделать 3D мир с полностью 2D графикой, но в конце концов отказался от этой затеи как слишком сложной для восприятия и управления игроком. Сегодня не так сложно сделать 3D графику и никто особо не будет ругать за слишком примитивный 3D стиль, сейчас это, наоборот, набирает популярность в определённых кругах. Даже придумали натягивать пиксель-арт на 3D лоуполи меши и, внезапно, это стало популярным.
Может пригодиться запекание нескольких спрайтов в одну текстуру с помощью Viewport. Не знаю, понадобится ли это тебе, но это может сократить число спрайтовых нод и снизить нагрузку на встроенный батчинг (он, очевидно, тоже имеет предел). Либо, если нужно только отрисовать спрайты, можно использовать визуальный сервер, создавая вместо нод Sprite сущности в визуальном сервере (к ним обращение по RID, главное не забывать очищать лишнее). Собственно серверы в Годо предназначены в первую очередь чтобы обойти ограничения дерева сцены на число нод в сцене, но использовать их не так просто, как кидать ноды на сцену. Проще говоря, потребуется чуть больше кода на создание, настройку, управление и освобождение ресурсов, которые ты решил "перенести" на сервер (изнутри каждая нода обращается к серверам, т.е. ноды - это просто удобный интерфейс, но это удобство влечёт за собой некоторое снижение производительности, которое не важно для мелких проектов, но мешает в больших по числу объектов мирах).
Можно создать дополнительный TileMap с полупрозрачными тайлами крови и других декалей. TileMap внутри оптимизирован таким образом, чтобы множество тайлов (чанк) рисовались как одна текстура. Для 2D выгоднее всего использовать TileMap для всего, что находится неподвижно на клетках сетки и не имеет анимаций (сомневаюсь, можно ли анимировать тайлы TileMap). Логику можно держать в скрипте, работающем сразу со всей тайлмапой, а не с отдельным предметом (это как System в ECS). Отдельные спрайты нужны только для того, что плавно двигается между клетками, имеет сложные анимации, нуждается в иерархии нод или должно сортироваться тайлмапой (ну это когда тайлы сверху-сбоку и перекрывают часть подвижных объектов, популярно в jRPG).
>генерить десятки разных видов КАМНЕЙ
Зачем тебе десятки видов КАМНЕЙ? Так ли уж они нужны песочнице, тем более с ориентацией на симуляцию жизни? Даже в майнкрафте есть всего одна текстура камня, который природно генерируется, в последних версиях добавили ещё несколько видов каменных пород, но суть не сильно изменилась. Тем не менее, майнкрафт даже в ванильной версии достаточно хорошо справляется с процедурной генерацией мира. А в симуляторе жизни тебе вообще не важны камни и их отображение, главное чтобы камень можно было отличить от всего, что камнем не является. В симуляторе жизни фокус на формах жизни или конкретном разумном виде жизни, но даже так их внешний вид вторичен и редко выходит за пределы "комбинация кусочков из нескольких ограниченных наборов кусочков" - как в 2D, так и в 3D. Главное чтобы игрок мог отличить жителя А от жителя Б за приемлемое время, т.е. не тратил много времени на поиски (поэтому отличия должны быть существенными).
>будет намного лучше если ты просто сделаешь что то типа вот
Ну и? Подобная структура в JSON будет в любой достаточно сложной игре, что 2D, что 3D, что со статичной картой, что с процедурной генерацией всего и вся. Потому что альтернатива - хардкод, а это нехорошо для гибкой разработки. Разница между структурами будет только в частных ресурсах и параметрах, например, в 2D может быть ссылка на sprite(sheet).png и его размер/поворот, в 3D - на mesh.obj и его масштаб/поворот, но это несущественно. Тебя никто не заставляет генерировать меш параметрически (хотя в этом нет особой сложности, если тебя устроят лоуполи модели).
>просто кубоидами оставлять я это всё не собираюсь
Ты буквально хочешь какую-то 2D фигню из SVG кругов и квадратов, но в 3D тебе обязательно ультрареализм?
>Тогда сразу надо будет поддерживать кастомные модели
В Godot всё необходимое доступно из коробки.
>эти кастомные модели в огромных количествах делать
Ты можешь процедурно комбинировать несколько базовых мешей, создавая миллионы возможных комбинаций не считая расцветок. Лучше, конечно, если графика будет достаточно абстрактной, и уж тем более не реализм (No Man's Sky... а, нет, там не такой уж реализм).
>а там и до анимации этих кастомных моделей недалеко
Да пофиг, инди редко имеют хорошие анимации, можно обойтись чем-то минимальным и абстрактным, так многие делают. Суть твоей игры ведь не в анимациях и даже не в красоте моделек.
>просто считай по хитрому отображение верхних уровней попробую зделоть
Думай в первую очередь о геймплее и удобстве игрока. RimWorld не зря однослойный, это многое упрощает. Я тоже когда-то думал сделать 3D мир с полностью 2D графикой, но в конце концов отказался от этой затеи как слишком сложной для восприятия и управления игроком. Сегодня не так сложно сделать 3D графику и никто особо не будет ругать за слишком примитивный 3D стиль, сейчас это, наоборот, набирает популярность в определённых кругах. Даже придумали натягивать пиксель-арт на 3D лоуполи меши и, внезапно, это стало популярным.
>наложение нескольких предметов (похожее на спейс стейшон), и когда предметов оч много куча превращается в месиво из рандома + самые объемистые предметы в ней.
Может пригодиться запекание нескольких спрайтов в одну текстуру с помощью Viewport. Не знаю, понадобится ли это тебе, но это может сократить число спрайтовых нод и снизить нагрузку на встроенный батчинг (он, очевидно, тоже имеет предел). Либо, если нужно только отрисовать спрайты, можно использовать визуальный сервер, создавая вместо нод Sprite сущности в визуальном сервере (к ним обращение по RID, главное не забывать очищать лишнее). Собственно серверы в Годо предназначены в первую очередь чтобы обойти ограничения дерева сцены на число нод в сцене, но использовать их не так просто, как кидать ноды на сцену. Проще говоря, потребуется чуть больше кода на создание, настройку, управление и освобождение ресурсов, которые ты решил "перенести" на сервер (изнутри каждая нода обращается к серверам, т.е. ноды - это просто удобный интерфейс, но это удобство влечёт за собой некоторое снижение производительности, которое не важно для мелких проектов, но мешает в больших по числу объектов мирах).
>Вся дорога просто фаршем покрывается.
Можно создать дополнительный TileMap с полупрозрачными тайлами крови и других декалей. TileMap внутри оптимизирован таким образом, чтобы множество тайлов (чанк) рисовались как одна текстура. Для 2D выгоднее всего использовать TileMap для всего, что находится неподвижно на клетках сетки и не имеет анимаций (сомневаюсь, можно ли анимировать тайлы TileMap). Логику можно держать в скрипте, работающем сразу со всей тайлмапой, а не с отдельным предметом (это как System в ECS). Отдельные спрайты нужны только для того, что плавно двигается между клетками, имеет сложные анимации, нуждается в иерархии нод или должно сортироваться тайлмапой (ну это когда тайлы сверху-сбоку и перекрывают часть подвижных объектов, популярно в jRPG).
>>17694
Зачем тебе десятки видов КАМНЕЙ? Так ли уж они нужны песочнице, тем более с ориентацией на симуляцию жизни? Даже в майнкрафте есть всего одна текстура камня, который природно генерируется, в последних версиях добавили ещё несколько видов каменных пород, но суть не сильно изменилась. Тем не менее, майнкрафт даже в ванильной версии достаточно хорошо справляется с процедурной генерацией мира. А в симуляторе жизни тебе вообще не важны камни и их отображение, главное чтобы камень можно было отличить от всего, что камнем не является. В симуляторе жизни фокус на формах жизни или конкретном разумном виде жизни, но даже так их внешний вид вторичен и редко выходит за пределы "комбинация кусочков из нескольких ограниченных наборов кусочков" - как в 2D, так и в 3D. Главное чтобы игрок мог отличить жителя А от жителя Б за приемлемое время, т.е. не тратил много времени на поиски (поэтому отличия должны быть существенными).
Ну и? Подобная структура в JSON будет в любой достаточно сложной игре, что 2D, что 3D, что со статичной картой, что с процедурной генерацией всего и вся. Потому что альтернатива - хардкод, а это нехорошо для гибкой разработки. Разница между структурами будет только в частных ресурсах и параметрах, например, в 2D может быть ссылка на sprite(sheet).png и его размер/поворот, в 3D - на mesh.obj и его масштаб/поворот, но это несущественно. Тебя никто не заставляет генерировать меш параметрически (хотя в этом нет особой сложности, если тебя устроят лоуполи модели).
Ты буквально хочешь какую-то 2D фигню из SVG кругов и квадратов, но в 3D тебе обязательно ультрареализм?
В Godot всё необходимое доступно из коробки.
Ты можешь процедурно комбинировать несколько базовых мешей, создавая миллионы возможных комбинаций не считая расцветок. Лучше, конечно, если графика будет достаточно абстрактной, и уж тем более не реализм (No Man's Sky... а, нет, там не такой уж реализм).
Да пофиг, инди редко имеют хорошие анимации, можно обойтись чем-то минимальным и абстрактным, так многие делают. Суть твоей игры ведь не в анимациях и даже не в красоте моделек.
Думай в первую очередь о геймплее и удобстве игрока. RimWorld не зря однослойный, это многое упрощает. Я тоже когда-то думал сделать 3D мир с полностью 2D графикой, но в конце концов отказался от этой затеи как слишком сложной для восприятия и управления игроком. Сегодня не так сложно сделать 3D графику и никто особо не будет ругать за слишком примитивный 3D стиль, сейчас это, наоборот, набирает популярность в определённых кругах. Даже придумали натягивать пиксель-арт на 3D лоуполи меши и, внезапно, это стало популярным.
Может пригодиться запекание нескольких спрайтов в одну текстуру с помощью Viewport. Не знаю, понадобится ли это тебе, но это может сократить число спрайтовых нод и снизить нагрузку на встроенный батчинг (он, очевидно, тоже имеет предел). Либо, если нужно только отрисовать спрайты, можно использовать визуальный сервер, создавая вместо нод Sprite сущности в визуальном сервере (к ним обращение по RID, главное не забывать очищать лишнее). Собственно серверы в Годо предназначены в первую очередь чтобы обойти ограничения дерева сцены на число нод в сцене, но использовать их не так просто, как кидать ноды на сцену. Проще говоря, потребуется чуть больше кода на создание, настройку, управление и освобождение ресурсов, которые ты решил "перенести" на сервер (изнутри каждая нода обращается к серверам, т.е. ноды - это просто удобный интерфейс, но это удобство влечёт за собой некоторое снижение производительности, которое не важно для мелких проектов, но мешает в больших по числу объектов мирах).
Можно создать дополнительный TileMap с полупрозрачными тайлами крови и других декалей. TileMap внутри оптимизирован таким образом, чтобы множество тайлов (чанк) рисовались как одна текстура. Для 2D выгоднее всего использовать TileMap для всего, что находится неподвижно на клетках сетки и не имеет анимаций (сомневаюсь, можно ли анимировать тайлы TileMap). Логику можно держать в скрипте, работающем сразу со всей тайлмапой, а не с отдельным предметом (это как System в ECS). Отдельные спрайты нужны только для того, что плавно двигается между клетками, имеет сложные анимации, нуждается в иерархии нод или должно сортироваться тайлмапой (ну это когда тайлы сверху-сбоку и перекрывают часть подвижных объектов, популярно в jRPG).
>генерить десятки разных видов КАМНЕЙ
Зачем тебе десятки видов КАМНЕЙ? Так ли уж они нужны песочнице, тем более с ориентацией на симуляцию жизни? Даже в майнкрафте есть всего одна текстура камня, который природно генерируется, в последних версиях добавили ещё несколько видов каменных пород, но суть не сильно изменилась. Тем не менее, майнкрафт даже в ванильной версии достаточно хорошо справляется с процедурной генерацией мира. А в симуляторе жизни тебе вообще не важны камни и их отображение, главное чтобы камень можно было отличить от всего, что камнем не является. В симуляторе жизни фокус на формах жизни или конкретном разумном виде жизни, но даже так их внешний вид вторичен и редко выходит за пределы "комбинация кусочков из нескольких ограниченных наборов кусочков" - как в 2D, так и в 3D. Главное чтобы игрок мог отличить жителя А от жителя Б за приемлемое время, т.е. не тратил много времени на поиски (поэтому отличия должны быть существенными).
>будет намного лучше если ты просто сделаешь что то типа вот
Ну и? Подобная структура в JSON будет в любой достаточно сложной игре, что 2D, что 3D, что со статичной картой, что с процедурной генерацией всего и вся. Потому что альтернатива - хардкод, а это нехорошо для гибкой разработки. Разница между структурами будет только в частных ресурсах и параметрах, например, в 2D может быть ссылка на sprite(sheet).png и его размер/поворот, в 3D - на mesh.obj и его масштаб/поворот, но это несущественно. Тебя никто не заставляет генерировать меш параметрически (хотя в этом нет особой сложности, если тебя устроят лоуполи модели).
>просто кубоидами оставлять я это всё не собираюсь
Ты буквально хочешь какую-то 2D фигню из SVG кругов и квадратов, но в 3D тебе обязательно ультрареализм?
>Тогда сразу надо будет поддерживать кастомные модели
В Godot всё необходимое доступно из коробки.
>эти кастомные модели в огромных количествах делать
Ты можешь процедурно комбинировать несколько базовых мешей, создавая миллионы возможных комбинаций не считая расцветок. Лучше, конечно, если графика будет достаточно абстрактной, и уж тем более не реализм (No Man's Sky... а, нет, там не такой уж реализм).
>а там и до анимации этих кастомных моделей недалеко
Да пофиг, инди редко имеют хорошие анимации, можно обойтись чем-то минимальным и абстрактным, так многие делают. Суть твоей игры ведь не в анимациях и даже не в красоте моделек.
>просто считай по хитрому отображение верхних уровней попробую зделоть
Думай в первую очередь о геймплее и удобстве игрока. RimWorld не зря однослойный, это многое упрощает. Я тоже когда-то думал сделать 3D мир с полностью 2D графикой, но в конце концов отказался от этой затеи как слишком сложной для восприятия и управления игроком. Сегодня не так сложно сделать 3D графику и никто особо не будет ругать за слишком примитивный 3D стиль, сейчас это, наоборот, набирает популярность в определённых кругах. Даже придумали натягивать пиксель-арт на 3D лоуполи меши и, внезапно, это стало популярным.
>наложение нескольких предметов (похожее на спейс стейшон), и когда предметов оч много куча превращается в месиво из рандома + самые объемистые предметы в ней.
Может пригодиться запекание нескольких спрайтов в одну текстуру с помощью Viewport. Не знаю, понадобится ли это тебе, но это может сократить число спрайтовых нод и снизить нагрузку на встроенный батчинг (он, очевидно, тоже имеет предел). Либо, если нужно только отрисовать спрайты, можно использовать визуальный сервер, создавая вместо нод Sprite сущности в визуальном сервере (к ним обращение по RID, главное не забывать очищать лишнее). Собственно серверы в Годо предназначены в первую очередь чтобы обойти ограничения дерева сцены на число нод в сцене, но использовать их не так просто, как кидать ноды на сцену. Проще говоря, потребуется чуть больше кода на создание, настройку, управление и освобождение ресурсов, которые ты решил "перенести" на сервер (изнутри каждая нода обращается к серверам, т.е. ноды - это просто удобный интерфейс, но это удобство влечёт за собой некоторое снижение производительности, которое не важно для мелких проектов, но мешает в больших по числу объектов мирах).
>Вся дорога просто фаршем покрывается.
Можно создать дополнительный TileMap с полупрозрачными тайлами крови и других декалей. TileMap внутри оптимизирован таким образом, чтобы множество тайлов (чанк) рисовались как одна текстура. Для 2D выгоднее всего использовать TileMap для всего, что находится неподвижно на клетках сетки и не имеет анимаций (сомневаюсь, можно ли анимировать тайлы TileMap). Логику можно держать в скрипте, работающем сразу со всей тайлмапой, а не с отдельным предметом (это как System в ECS). Отдельные спрайты нужны только для того, что плавно двигается между клетками, имеет сложные анимации, нуждается в иерархии нод или должно сортироваться тайлмапой (ну это когда тайлы сверху-сбоку и перекрывают часть подвижных объектов, популярно в jRPG).
>>17811
Не воспринимай так близко, я про сам механизм генерации в общем. Да и понятие ориентирована на симуляцию жизни тоже не совсем правильно. Игра вообще с прямым управлением а не как в ДФ. Больше скорее бродилка с симулятивным миром. Но это не значит что болванчики вокруг будут обделены каким-то подобием личности или социумом.
Палку в пояснении перегибаю. Я не знаю инструменты в годоте, которые без лишней мороки и потери итак оставшихся крох перфоманса (там с 3Д всегда проблемы были, хз много ли поменялось в 4-ой версии).
Примеры приведи как этакое делать. Я лично видел вот такую либу (https://github.com/protongraph/protongraph). Если бы автор довёл её до ума, можно было бы и на 3д легко перейти. Были даже идеи 3д генерации кричерсов, но там требуются фичи которые я хз есть ли в годоте:
- Генерация скелетов, или мерджинг, скелета из разных частей.
- Универсальные анимации под разные скелеты. блендинг этих анимаций.
- рилтайм риггинг
По сути так каждая часть тела это примитив, и его можно процедурно изменять (+ сила и увеличивается обьем мускулов)
Но я не хочу с этим всем возиться, это конечно интересные идеи но мне графика в основном до пизды, я вообще мог бы и на ascii играть, так что да.
В теории конечно может можно просто оставить 3д стены, рампы и всякий статический скарб, а остальное 2д спрайты. как ты сказал, их можно генерить на изи, ну поясняй как.
За советы ниже спасибо.
Еще странная херня кстати, не могу импортировать .png в новом билде годота, вылетает editor\editor_file_system.cpp:2131 - Condition "!importer.is_valid()" is true. Continuing. Вот эта строчка в репозитории
https://github.com/godotengine/godot/blob/master/editor/editor_file_system.cpp#L2131
Причём самое странное что один из png он спокойно импортировал. Другие ни в какую.
>Зачем тебе десятки видов КАМНЕЙ?
Не воспринимай так близко, я про сам механизм генерации в общем. Да и понятие ориентирована на симуляцию жизни тоже не совсем правильно. Игра вообще с прямым управлением а не как в ДФ. Больше скорее бродилка с симулятивным миром. Но это не значит что болванчики вокруг будут обделены каким-то подобием личности или социумом.
>Ты буквально хочешь какую-то 2D фигню из SVG кругов и квадратов, но в 3D тебе обязательно ультрареализм?
Палку в пояснении перегибаю. Я не знаю инструменты в годоте, которые без лишней мороки и потери итак оставшихся крох перфоманса (там с 3Д всегда проблемы были, хз много ли поменялось в 4-ой версии).
>Ты можешь процедурно комбинировать несколько базовых мешей, создавая миллионы возможных комбинаций не считая расцветок.
Примеры приведи как этакое делать. Я лично видел вот такую либу (https://github.com/protongraph/protongraph). Если бы автор довёл её до ума, можно было бы и на 3д легко перейти. Были даже идеи 3д генерации кричерсов, но там требуются фичи которые я хз есть ли в годоте:
- Генерация скелетов, или мерджинг, скелета из разных частей.
- Универсальные анимации под разные скелеты. блендинг этих анимаций.
- рилтайм риггинг
По сути так каждая часть тела это примитив, и его можно процедурно изменять (+ сила и увеличивается обьем мускулов)
Но я не хочу с этим всем возиться, это конечно интересные идеи но мне графика в основном до пизды, я вообще мог бы и на ascii играть, так что да.
>Ты можешь процедурно комбинировать несколько базовых мешей
В теории конечно может можно просто оставить 3д стены, рампы и всякий статический скарб, а остальное 2д спрайты. как ты сказал, их можно генерить на изи, ну поясняй как.
За советы ниже спасибо.
Еще странная херня кстати, не могу импортировать .png в новом билде годота, вылетает editor\editor_file_system.cpp:2131 - Condition "!importer.is_valid()" is true. Continuing. Вот эта строчка в репозитории
https://github.com/godotengine/godot/blob/master/editor/editor_file_system.cpp#L2131
Причём самое странное что один из png он спокойно импортировал. Другие ни в какую.
>>17811
Не воспринимай так близко, я про сам механизм генерации в общем. Да и понятие ориентирована на симуляцию жизни тоже не совсем правильно. Игра вообще с прямым управлением а не как в ДФ. Больше скорее бродилка с симулятивным миром. Но это не значит что болванчики вокруг будут обделены каким-то подобием личности или социумом.
Палку в пояснении перегибаю. Я не знаю инструменты в годоте, которые без лишней мороки и потери итак оставшихся крох перфоманса (там с 3Д всегда проблемы были, хз много ли поменялось в 4-ой версии).
Примеры приведи как этакое делать. Я лично видел вот такую либу (https://github.com/protongraph/protongraph). Если бы автор довёл её до ума, можно было бы и на 3д легко перейти. Были даже идеи 3д генерации кричерсов, но там требуются фичи которые я хз есть ли в годоте:
- Генерация скелетов, или мерджинг, скелета из разных частей.
- Универсальные анимации под разные скелеты. блендинг этих анимаций.
- рилтайм риггинг
По сути так каждая часть тела это примитив, и его можно процедурно изменять (+ сила и увеличивается обьем мускулов)
Но я не хочу с этим всем возиться, это конечно интересные идеи но мне графика в основном до пизды, я вообще мог бы и на ascii играть, так что да.
В теории конечно может можно просто оставить 3д стены, рампы и всякий статический скарб, а остальное 2д спрайты. как ты сказал, их можно генерить на изи, ну поясняй как.
За советы ниже спасибо.
Еще странная херня кстати, не могу импортировать .png в новом билде годота, вылетает editor\editor_file_system.cpp:2131 - Condition "!importer.is_valid()" is true. Continuing. Вот эта строчка в репозитории
https://github.com/godotengine/godot/blob/master/editor/editor_file_system.cpp#L2131
Причём самое странное что один из png он спокойно импортировал. Другие ни в какую.
>Зачем тебе десятки видов КАМНЕЙ?
Не воспринимай так близко, я про сам механизм генерации в общем. Да и понятие ориентирована на симуляцию жизни тоже не совсем правильно. Игра вообще с прямым управлением а не как в ДФ. Больше скорее бродилка с симулятивным миром. Но это не значит что болванчики вокруг будут обделены каким-то подобием личности или социумом.
>Ты буквально хочешь какую-то 2D фигню из SVG кругов и квадратов, но в 3D тебе обязательно ультрареализм?
Палку в пояснении перегибаю. Я не знаю инструменты в годоте, которые без лишней мороки и потери итак оставшихся крох перфоманса (там с 3Д всегда проблемы были, хз много ли поменялось в 4-ой версии).
>Ты можешь процедурно комбинировать несколько базовых мешей, создавая миллионы возможных комбинаций не считая расцветок.
Примеры приведи как этакое делать. Я лично видел вот такую либу (https://github.com/protongraph/protongraph). Если бы автор довёл её до ума, можно было бы и на 3д легко перейти. Были даже идеи 3д генерации кричерсов, но там требуются фичи которые я хз есть ли в годоте:
- Генерация скелетов, или мерджинг, скелета из разных частей.
- Универсальные анимации под разные скелеты. блендинг этих анимаций.
- рилтайм риггинг
По сути так каждая часть тела это примитив, и его можно процедурно изменять (+ сила и увеличивается обьем мускулов)
Но я не хочу с этим всем возиться, это конечно интересные идеи но мне графика в основном до пизды, я вообще мог бы и на ascii играть, так что да.
>Ты можешь процедурно комбинировать несколько базовых мешей
В теории конечно может можно просто оставить 3д стены, рампы и всякий статический скарб, а остальное 2д спрайты. как ты сказал, их можно генерить на изи, ну поясняй как.
За советы ниже спасибо.
Еще странная херня кстати, не могу импортировать .png в новом билде годота, вылетает editor\editor_file_system.cpp:2131 - Condition "!importer.is_valid()" is true. Continuing. Вот эта строчка в репозитории
https://github.com/godotengine/godot/blob/master/editor/editor_file_system.cpp#L2131
Причём самое странное что один из png он спокойно импортировал. Другие ни в какую.
>>17815
Решил проблему. Почему-то ебанула система импорта, очистил кэш - всё ок.
>Еще странная херня кстати, не могу импортировать .png в новом билде годота, вылетает editor\editor_file_system.cpp:2131 - Condition "!importer.is_valid()" is true. Continuing. Вот эта строчка в репозитории
Решил проблему. Почему-то ебанула система импорта, очистил кэш - всё ок.
Давно спросить хотел, только сейчас вспомнил.
Из документации:
Я в своём коде для тестирования производительности одного участка кода использовал get_ticks_msec(). Всё было нормально, пока я не попробовал инициализировать GridMap огромным количеством обращений в цикле, который происходил прямо перед завершающим обращением к get_ticks_msec(). Ожидание: правильное вычисление затраченного времени на заполнение GridMap. Реальность: игра зависает на ощутимое количество секунд (скажем, больше 10), но мой код пишет, что прошло всего 1.5 секунды (время на код, который был до заполнения GridMap). Похоже, баг? Тики движка не обновляются в какой-то момент? Как это можно обойти? Не так уж важно, но всё же хотелось иметь точный счётчик времени...
Когда я пробовал писать свой движок на Паскале, я использовал встроенный в ОС (BIOS?) счётчик тиков. Он считает тики со старта компьютера (скорее всего это он отображается в Диспетчере задач Windows), и, соответственно, не зависит от зависания приложения или даже зависания ОС (потому что счётчик времени независим от процессора, это отдельная микросхема, сбить его может только нестабильное питание материнской платы + мёртвая батарейка, насколько я понимаю). Почему в Godot нет доступа к этому счётчику, и вместо него какой-то велосипед, который способен сильно ошибаться при зависании движка? Я понимаю, "юзер может изменить время" и "система может корректировать время", но данный счётчик не является счётчиком времени, он считает тики со старта компьютера. Единственный недостаток - он, вроде, вмещает всего два месяца аптайма компьютера, но вряд ли у многих домашний компьютер работает столько времени без перезагрузки (тем более с Windows 10+). На смартфонах с Android тоже есть такой счётчик, считающий время с момента включения телефона независимо от установленного пользователем времени (можно увидеть в AIDA64)...
Из документации:
>int get_unix_time ( ) const
>Returns the current UNIX epoch timestamp in seconds.
>Important: This is the system clock that the user can manually set. Never use this method for precise time calculation since its results are also subject to automatic adjustments by the operating system. Always use get_ticks_usec or get_ticks_msec for precise time calculation instead, since they are guaranteed to be monotonic (i.e. never decrease).
>int get_ticks_msec ( ) const
>Returns the amount of time passed in milliseconds since the engine started.
>int get_ticks_usec ( ) const
>Returns the amount of time passed in microseconds since the engine started.
Я в своём коде для тестирования производительности одного участка кода использовал get_ticks_msec(). Всё было нормально, пока я не попробовал инициализировать GridMap огромным количеством обращений в цикле, который происходил прямо перед завершающим обращением к get_ticks_msec(). Ожидание: правильное вычисление затраченного времени на заполнение GridMap. Реальность: игра зависает на ощутимое количество секунд (скажем, больше 10), но мой код пишет, что прошло всего 1.5 секунды (время на код, который был до заполнения GridMap). Похоже, баг? Тики движка не обновляются в какой-то момент? Как это можно обойти? Не так уж важно, но всё же хотелось иметь точный счётчик времени...
Когда я пробовал писать свой движок на Паскале, я использовал встроенный в ОС (BIOS?) счётчик тиков. Он считает тики со старта компьютера (скорее всего это он отображается в Диспетчере задач Windows), и, соответственно, не зависит от зависания приложения или даже зависания ОС (потому что счётчик времени независим от процессора, это отдельная микросхема, сбить его может только нестабильное питание материнской платы + мёртвая батарейка, насколько я понимаю). Почему в Godot нет доступа к этому счётчику, и вместо него какой-то велосипед, который способен сильно ошибаться при зависании движка? Я понимаю, "юзер может изменить время" и "система может корректировать время", но данный счётчик не является счётчиком времени, он считает тики со старта компьютера. Единственный недостаток - он, вроде, вмещает всего два месяца аптайма компьютера, но вряд ли у многих домашний компьютер работает столько времени без перезагрузки (тем более с Windows 10+). На смартфонах с Android тоже есть такой счётчик, считающий время с момента включения телефона независимо от установленного пользователем времени (можно увидеть в AIDA64)...
Давно спросить хотел, только сейчас вспомнил.
Из документации:
Я в своём коде для тестирования производительности одного участка кода использовал get_ticks_msec(). Всё было нормально, пока я не попробовал инициализировать GridMap огромным количеством обращений в цикле, который происходил прямо перед завершающим обращением к get_ticks_msec(). Ожидание: правильное вычисление затраченного времени на заполнение GridMap. Реальность: игра зависает на ощутимое количество секунд (скажем, больше 10), но мой код пишет, что прошло всего 1.5 секунды (время на код, который был до заполнения GridMap). Похоже, баг? Тики движка не обновляются в какой-то момент? Как это можно обойти? Не так уж важно, но всё же хотелось иметь точный счётчик времени...
Когда я пробовал писать свой движок на Паскале, я использовал встроенный в ОС (BIOS?) счётчик тиков. Он считает тики со старта компьютера (скорее всего это он отображается в Диспетчере задач Windows), и, соответственно, не зависит от зависания приложения или даже зависания ОС (потому что счётчик времени независим от процессора, это отдельная микросхема, сбить его может только нестабильное питание материнской платы + мёртвая батарейка, насколько я понимаю). Почему в Godot нет доступа к этому счётчику, и вместо него какой-то велосипед, который способен сильно ошибаться при зависании движка? Я понимаю, "юзер может изменить время" и "система может корректировать время", но данный счётчик не является счётчиком времени, он считает тики со старта компьютера. Единственный недостаток - он, вроде, вмещает всего два месяца аптайма компьютера, но вряд ли у многих домашний компьютер работает столько времени без перезагрузки (тем более с Windows 10+). На смартфонах с Android тоже есть такой счётчик, считающий время с момента включения телефона независимо от установленного пользователем времени (можно увидеть в AIDA64)...
Из документации:
>int get_unix_time ( ) const
>Returns the current UNIX epoch timestamp in seconds.
>Important: This is the system clock that the user can manually set. Never use this method for precise time calculation since its results are also subject to automatic adjustments by the operating system. Always use get_ticks_usec or get_ticks_msec for precise time calculation instead, since they are guaranteed to be monotonic (i.e. never decrease).
>int get_ticks_msec ( ) const
>Returns the amount of time passed in milliseconds since the engine started.
>int get_ticks_usec ( ) const
>Returns the amount of time passed in microseconds since the engine started.
Я в своём коде для тестирования производительности одного участка кода использовал get_ticks_msec(). Всё было нормально, пока я не попробовал инициализировать GridMap огромным количеством обращений в цикле, который происходил прямо перед завершающим обращением к get_ticks_msec(). Ожидание: правильное вычисление затраченного времени на заполнение GridMap. Реальность: игра зависает на ощутимое количество секунд (скажем, больше 10), но мой код пишет, что прошло всего 1.5 секунды (время на код, который был до заполнения GridMap). Похоже, баг? Тики движка не обновляются в какой-то момент? Как это можно обойти? Не так уж важно, но всё же хотелось иметь точный счётчик времени...
Когда я пробовал писать свой движок на Паскале, я использовал встроенный в ОС (BIOS?) счётчик тиков. Он считает тики со старта компьютера (скорее всего это он отображается в Диспетчере задач Windows), и, соответственно, не зависит от зависания приложения или даже зависания ОС (потому что счётчик времени независим от процессора, это отдельная микросхема, сбить его может только нестабильное питание материнской платы + мёртвая батарейка, насколько я понимаю). Почему в Godot нет доступа к этому счётчику, и вместо него какой-то велосипед, который способен сильно ошибаться при зависании движка? Я понимаю, "юзер может изменить время" и "система может корректировать время", но данный счётчик не является счётчиком времени, он считает тики со старта компьютера. Единственный недостаток - он, вроде, вмещает всего два месяца аптайма компьютера, но вряд ли у многих домашний компьютер работает столько времени без перезагрузки (тем более с Windows 10+). На смартфонах с Android тоже есть такой счётчик, считающий время с момента включения телефона независимо от установленного пользователем времени (можно увидеть в AIDA64)...
>>17815
Это хорошо, у меня похожая концепция игры.
GridMap для клеточно-тайлового мира, MultiMeshInstance для большого количества близко расположенных одинаковых мешей, система "комнат" и окклюдеров для скрытия/отображения лишнего/нужного, ещё что-то, также в процессе разработки склеиватель мешей, который ранее использовался только для комнат, а теперь будет доступен для всех MeshInstance. Ну, чанковую систему тебе в любом случае придётся делать самому, что для 2D, что для 3D.
Там теперь не нужно беспокоиться о дроуколлах, потому что в Vulkan какой-то новый графический пайплайн. Также реализована встроенная система LOD, которая автоматически редуцирует меши по мере отдаления от камеры (визуально качество неотличимо). Ещё вроде бы избавились от лишних перерисовок, т.е. объекты не рисуются позади других объектов, поэтому системы комнат из 3.х ветки нет и вроде не будет (не в 4.0) - не нужна. В целом нагрузка для минимального проекта возросла, но снизился рост нагрузки при увеличении количества и сложности мешей - как раз то, что нужно для больших миров.
А что именно тебя интересует? Есть разные применения такого подхода. Практически любой 3D генератор в играх всего лишь комбинирует заранее заготовленные детальки, потому что это банально проще. Бывают, конечно, параметрические генераторы (как аддон Сверчок или Geometry Nodes в Blender), но их, имхо, сложно настраивать для чего-то визуально сложного.
В любом случае, вот это может помочь для начала:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
Для простого склеивания простых статичных мешей подойдёт эта функция в 3.5 (выше упоминал его):
https://docs.godotengine.org/en/3.5/classes/class_meshinstance.html#class-meshinstance-method-merge-meshes
Да: https://docs.godotengine.org/en/stable/classes/class_skeleton.html
Можно делать процедурные анимации с инверсной кинематикой, вроде такое даже в официальных демках есть.
Ты как будто Spore хочешь делать. Но, вроде, это всё возможно сделать на Godot. Инструменты есть.
Ну и в чём тогда проблема сделать трёхмерные фигурки а-ля фигуры из шахмат? Разница только в удобстве восприятия пространства. В одном случае можно полетать камерой как угодно, а в другом ты смотришь на горизонтальный срез объёмной местности сверху вниз и нихрена не понимаешь. Или видишь плоскость, которая на самом деле не плоская, и снова нихрена не понимаешь. А существ можешь теми же ASCII символами на билбордах делать.
Ну, ладно, дело твоё, я просто предложил как вариант. Можно даже сделать сразу два вида графики на выбор игрока, 2D и 3D, не вижу проблемы, если делать игру на Godot и не замахиваться на реализм, обойдясь абстрактными формами.
Viewport + заранее заготовленные спрайты или код в _draw() для рисования линий, прямоугольников, окружностей, кривых и т.д. Полученные таким образом текстуры сохраняешь в массив и используешь в билбордах. Дальше всё зависит от фантазии)
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
А ты альфу 4.0 используешь? Она же нестабильна очень...
>Игра вообще с прямым управлением а не как в ДФ. Больше скорее бродилка с симулятивным миром. Но это не значит что болванчики вокруг будут обделены каким-то подобием личности или социумом.
Это хорошо, у меня похожая концепция игры.
>Я не знаю инструменты в годоте, которые без лишней мороки и потери итак оставшихся крох перфоманса
GridMap для клеточно-тайлового мира, MultiMeshInstance для большого количества близко расположенных одинаковых мешей, система "комнат" и окклюдеров для скрытия/отображения лишнего/нужного, ещё что-то, также в процессе разработки склеиватель мешей, который ранее использовался только для комнат, а теперь будет доступен для всех MeshInstance. Ну, чанковую систему тебе в любом случае придётся делать самому, что для 2D, что для 3D.
>много ли поменялось в 4-ой версии
Там теперь не нужно беспокоиться о дроуколлах, потому что в Vulkan какой-то новый графический пайплайн. Также реализована встроенная система LOD, которая автоматически редуцирует меши по мере отдаления от камеры (визуально качество неотличимо). Ещё вроде бы избавились от лишних перерисовок, т.е. объекты не рисуются позади других объектов, поэтому системы комнат из 3.х ветки нет и вроде не будет (не в 4.0) - не нужна. В целом нагрузка для минимального проекта возросла, но снизился рост нагрузки при увеличении количества и сложности мешей - как раз то, что нужно для больших миров.
>Примеры приведи как этакое делать.
А что именно тебя интересует? Есть разные применения такого подхода. Практически любой 3D генератор в играх всего лишь комбинирует заранее заготовленные детальки, потому что это банально проще. Бывают, конечно, параметрические генераторы (как аддон Сверчок или Geometry Nodes в Blender), но их, имхо, сложно настраивать для чего-то визуально сложного.
В любом случае, вот это может помочь для начала:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
Для простого склеивания простых статичных мешей подойдёт эта функция в 3.5 (выше упоминал его):
https://docs.godotengine.org/en/3.5/classes/class_meshinstance.html#class-meshinstance-method-merge-meshes
>Генерация скелетов, или мерджинг, скелета из разных частей.
Да: https://docs.godotengine.org/en/stable/classes/class_skeleton.html
Можно делать процедурные анимации с инверсной кинематикой, вроде такое даже в официальных демках есть.
>Универсальные анимации под разные скелеты. блендинг этих анимаций.
>рилтайм риггинг
Ты как будто Spore хочешь делать. Но, вроде, это всё возможно сделать на Godot. Инструменты есть.
>не хочу с этим всем возиться
>вообще мог бы и на ascii играть
Ну и в чём тогда проблема сделать трёхмерные фигурки а-ля фигуры из шахмат? Разница только в удобстве восприятия пространства. В одном случае можно полетать камерой как угодно, а в другом ты смотришь на горизонтальный срез объёмной местности сверху вниз и нихрена не понимаешь. Или видишь плоскость, которая на самом деле не плоская, и снова нихрена не понимаешь. А существ можешь теми же ASCII символами на билбордах делать.
Ну, ладно, дело твоё, я просто предложил как вариант. Можно даже сделать сразу два вида графики на выбор игрока, 2D и 3D, не вижу проблемы, если делать игру на Godot и не замахиваться на реализм, обойдясь абстрактными формами.
>остальное 2д спрайты. как ты сказал, их можно генерить на изи, ну поясняй как.
Viewport + заранее заготовленные спрайты или код в _draw() для рисования линий, прямоугольников, окружностей, кривых и т.д. Полученные таким образом текстуры сохраняешь в массив и используешь в билбордах. Дальше всё зависит от фантазии)
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
А ты альфу 4.0 используешь? Она же нестабильна очень...
>>17815
Это хорошо, у меня похожая концепция игры.
GridMap для клеточно-тайлового мира, MultiMeshInstance для большого количества близко расположенных одинаковых мешей, система "комнат" и окклюдеров для скрытия/отображения лишнего/нужного, ещё что-то, также в процессе разработки склеиватель мешей, который ранее использовался только для комнат, а теперь будет доступен для всех MeshInstance. Ну, чанковую систему тебе в любом случае придётся делать самому, что для 2D, что для 3D.
Там теперь не нужно беспокоиться о дроуколлах, потому что в Vulkan какой-то новый графический пайплайн. Также реализована встроенная система LOD, которая автоматически редуцирует меши по мере отдаления от камеры (визуально качество неотличимо). Ещё вроде бы избавились от лишних перерисовок, т.е. объекты не рисуются позади других объектов, поэтому системы комнат из 3.х ветки нет и вроде не будет (не в 4.0) - не нужна. В целом нагрузка для минимального проекта возросла, но снизился рост нагрузки при увеличении количества и сложности мешей - как раз то, что нужно для больших миров.
А что именно тебя интересует? Есть разные применения такого подхода. Практически любой 3D генератор в играх всего лишь комбинирует заранее заготовленные детальки, потому что это банально проще. Бывают, конечно, параметрические генераторы (как аддон Сверчок или Geometry Nodes в Blender), но их, имхо, сложно настраивать для чего-то визуально сложного.
В любом случае, вот это может помочь для начала:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
Для простого склеивания простых статичных мешей подойдёт эта функция в 3.5 (выше упоминал его):
https://docs.godotengine.org/en/3.5/classes/class_meshinstance.html#class-meshinstance-method-merge-meshes
Да: https://docs.godotengine.org/en/stable/classes/class_skeleton.html
Можно делать процедурные анимации с инверсной кинематикой, вроде такое даже в официальных демках есть.
Ты как будто Spore хочешь делать. Но, вроде, это всё возможно сделать на Godot. Инструменты есть.
Ну и в чём тогда проблема сделать трёхмерные фигурки а-ля фигуры из шахмат? Разница только в удобстве восприятия пространства. В одном случае можно полетать камерой как угодно, а в другом ты смотришь на горизонтальный срез объёмной местности сверху вниз и нихрена не понимаешь. Или видишь плоскость, которая на самом деле не плоская, и снова нихрена не понимаешь. А существ можешь теми же ASCII символами на билбордах делать.
Ну, ладно, дело твоё, я просто предложил как вариант. Можно даже сделать сразу два вида графики на выбор игрока, 2D и 3D, не вижу проблемы, если делать игру на Godot и не замахиваться на реализм, обойдясь абстрактными формами.
Viewport + заранее заготовленные спрайты или код в _draw() для рисования линий, прямоугольников, окружностей, кривых и т.д. Полученные таким образом текстуры сохраняешь в массив и используешь в билбордах. Дальше всё зависит от фантазии)
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
А ты альфу 4.0 используешь? Она же нестабильна очень...
>Игра вообще с прямым управлением а не как в ДФ. Больше скорее бродилка с симулятивным миром. Но это не значит что болванчики вокруг будут обделены каким-то подобием личности или социумом.
Это хорошо, у меня похожая концепция игры.
>Я не знаю инструменты в годоте, которые без лишней мороки и потери итак оставшихся крох перфоманса
GridMap для клеточно-тайлового мира, MultiMeshInstance для большого количества близко расположенных одинаковых мешей, система "комнат" и окклюдеров для скрытия/отображения лишнего/нужного, ещё что-то, также в процессе разработки склеиватель мешей, который ранее использовался только для комнат, а теперь будет доступен для всех MeshInstance. Ну, чанковую систему тебе в любом случае придётся делать самому, что для 2D, что для 3D.
>много ли поменялось в 4-ой версии
Там теперь не нужно беспокоиться о дроуколлах, потому что в Vulkan какой-то новый графический пайплайн. Также реализована встроенная система LOD, которая автоматически редуцирует меши по мере отдаления от камеры (визуально качество неотличимо). Ещё вроде бы избавились от лишних перерисовок, т.е. объекты не рисуются позади других объектов, поэтому системы комнат из 3.х ветки нет и вроде не будет (не в 4.0) - не нужна. В целом нагрузка для минимального проекта возросла, но снизился рост нагрузки при увеличении количества и сложности мешей - как раз то, что нужно для больших миров.
>Примеры приведи как этакое делать.
А что именно тебя интересует? Есть разные применения такого подхода. Практически любой 3D генератор в играх всего лишь комбинирует заранее заготовленные детальки, потому что это банально проще. Бывают, конечно, параметрические генераторы (как аддон Сверчок или Geometry Nodes в Blender), но их, имхо, сложно настраивать для чего-то визуально сложного.
В любом случае, вот это может помочь для начала:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
Для простого склеивания простых статичных мешей подойдёт эта функция в 3.5 (выше упоминал его):
https://docs.godotengine.org/en/3.5/classes/class_meshinstance.html#class-meshinstance-method-merge-meshes
>Генерация скелетов, или мерджинг, скелета из разных частей.
Да: https://docs.godotengine.org/en/stable/classes/class_skeleton.html
Можно делать процедурные анимации с инверсной кинематикой, вроде такое даже в официальных демках есть.
>Универсальные анимации под разные скелеты. блендинг этих анимаций.
>рилтайм риггинг
Ты как будто Spore хочешь делать. Но, вроде, это всё возможно сделать на Godot. Инструменты есть.
>не хочу с этим всем возиться
>вообще мог бы и на ascii играть
Ну и в чём тогда проблема сделать трёхмерные фигурки а-ля фигуры из шахмат? Разница только в удобстве восприятия пространства. В одном случае можно полетать камерой как угодно, а в другом ты смотришь на горизонтальный срез объёмной местности сверху вниз и нихрена не понимаешь. Или видишь плоскость, которая на самом деле не плоская, и снова нихрена не понимаешь. А существ можешь теми же ASCII символами на билбордах делать.
Ну, ладно, дело твоё, я просто предложил как вариант. Можно даже сделать сразу два вида графики на выбор игрока, 2D и 3D, не вижу проблемы, если делать игру на Godot и не замахиваться на реализм, обойдясь абстрактными формами.
>остальное 2д спрайты. как ты сказал, их можно генерить на изи, ну поясняй как.
Viewport + заранее заготовленные спрайты или код в _draw() для рисования линий, прямоугольников, окружностей, кривых и т.д. Полученные таким образом текстуры сохраняешь в массив и используешь в билбордах. Дальше всё зависит от фантазии)
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
А ты альфу 4.0 используешь? Она же нестабильна очень...
1014 Кб, 1200x675>>17822
А, это то я знаю. Я вообще для 3д хотел пользовать вот эту библиотеку https://github.com/Zylann/godot_voxel .
Это я тоже знал.
Вот это интересная штука.
Не совсем как в споре, там существа в одну сетку превращались, а у меня они сегментами получается должны быть.
Да я же не против 3д в целом, просто тут есть баланс между удобство восприятия/юзабилити и объемом механик игровых и т.д. Ресурсы для соло разработчика, как ты понимаешь дико ограничены, я не могу просто мыть уверенным, что начни я всё делать в 3д, или хотя бы часть, не придётся постоянно повышать комплексность этих всех визуализационных систем, просто ради того чтобы они хоть как-то передавали непосредственный стейт мира, а не просто были кубиком на котором написано "он в говне и немного порушен, но так шо свет через него проходит" (как пример, может еще сложнее вещи будут)
Этот баланс между сложностью и комплексностью механик и юзабилити вообще не решаем определённо. Почти каждая игра склоняется к юзабилити, и мало какие (за редким почти неизвестным исключением) склоняются к первому. Держать тут баланс это очень огронмый труд, часто пришлось бы ебашить целые экосистемы новые. До этого я хотел рогуль сделать от 1-го лица на маленьких (несколько км радиусом) планетах, и контент генерацию через свою собственную либу сделать. Даже доки какие-то написал перед созданием. Там с помощью SDF, разных генераций скелетов и блендинга можно было параметрические предметы, существ, даже небо и аллаха создавать. Я придумал как с помощью СДФ риггать не только модельку, но и перетекание форм при анимации. Например изменение объема бицепса. Это была бы просто ебическая мощная штука, во первых сам процесс создания новых персонажей, особенно низкодетализированных (как на пике) там был бы просто 20 из 10. Риггать можно не снимая свитер, а потом прямо в рилтайме в коде игры менять им форму головы, въебать новые конечности, аугментации, изменить рост, комплекцию и т.д. И это всё было бы делать очень легко. С анимациями там тоже было бы красиво (см. https://youtu.be/KLjTU0yKS00). Но это просто опиздоебический объем работы. ТАм не только либу но целый редактор пришлось бы писать с нуля, я подумал что это слишком дохуя работы даже для простого кирилла в голове, и понял что лучше сделать что то простое по визуалу, но с огромным количеством всяких эмерджнтых механик.
Но вообще с 3д миром и 2д предметами в мире я подумаю, довольно хорошая затея, не знаю, надо поэкспериментировать еще с 2д раз у меня мысли есть.
Щас я настолько опустился по ожиданиям что даже существам анимацию ног не даю. Будут сука скользить + декаль шагов под ногами. Оружие, щиты перед ними "летать" будет. Потому что тоже для боевки с точки зрения механики у меня много придумано, но визуально такое делать это сдохнешь нахуй. Но не думай, совсем про юзабилити забывать я не собираюсь, я постараюсь именно в таких сжатых рамках всё равно сделать так чтобы игра могла норм восприниматься. Диволье кроется в деталях.
Диволье кроется в деталях. Я думаю тут можно что-то с этим сделать. хитрые тени или другие эффекты. Восприятие можно наебать если знать как.
Идея будет работать только в случае если 3д окажутся только стены. Вот только как ты собрался поворачивать плавно такие объекты как телефон нахуй настенный? сбоку видно что он выпуклый, спереди он будет плоской картинкой. Когда ты камеру поворачиваешь он у тебя плоский, и в один момент переход на вид сбоку? Не слишком ли ёбань получается? Или дополнительно еще и хуярить для каждого предмета 2д и 3д вид? каво нахуй?
Да с этим я знаю. Не самые эффективные вещи. Моя задумка была использовать SVG, кешировать их в простые картинки и составлять из частей, или уже зааготовленные картинки и их уже рендерить. Драв использовать только местами.
Там фичи сочные (ГДскрипт2 как минимум), можно и потерпеть. А то потом еще проект переписывать весь под 4 когда зарелизится. Всё равно пока ничего особого не сделано.
>GridMap для клеточно-тайлового мира, MultiMeshInstance для большого количества близко расположенных одинаковых мешей, система "комнат" и окклюдеров для скрытия/отображения лишнего/нужного,
А, это то я знаю. Я вообще для 3д хотел пользовать вот эту библиотеку https://github.com/Zylann/godot_voxel .
>А что именно тебя интересует? Есть разные применения такого подхода.
Это я тоже знал.
>Генерация скелетов, или мерджинг, скелета из разных частей.
Вот это интересная штука.
> Ты как будто Spore хочешь делать. Но, вроде, это всё возможно сделать на Godot. Инструменты есть.
Не совсем как в споре, там существа в одну сетку превращались, а у меня они сегментами получается должны быть.
>Ну и в чём тогда проблема сделать трёхмерные фигурки а-ля фигуры из шахмат?
Да я же не против 3д в целом, просто тут есть баланс между удобство восприятия/юзабилити и объемом механик игровых и т.д. Ресурсы для соло разработчика, как ты понимаешь дико ограничены, я не могу просто мыть уверенным, что начни я всё делать в 3д, или хотя бы часть, не придётся постоянно повышать комплексность этих всех визуализационных систем, просто ради того чтобы они хоть как-то передавали непосредственный стейт мира, а не просто были кубиком на котором написано "он в говне и немного порушен, но так шо свет через него проходит" (как пример, может еще сложнее вещи будут)
Этот баланс между сложностью и комплексностью механик и юзабилити вообще не решаем определённо. Почти каждая игра склоняется к юзабилити, и мало какие (за редким почти неизвестным исключением) склоняются к первому. Держать тут баланс это очень огронмый труд, часто пришлось бы ебашить целые экосистемы новые. До этого я хотел рогуль сделать от 1-го лица на маленьких (несколько км радиусом) планетах, и контент генерацию через свою собственную либу сделать. Даже доки какие-то написал перед созданием. Там с помощью SDF, разных генераций скелетов и блендинга можно было параметрические предметы, существ, даже небо и аллаха создавать. Я придумал как с помощью СДФ риггать не только модельку, но и перетекание форм при анимации. Например изменение объема бицепса. Это была бы просто ебическая мощная штука, во первых сам процесс создания новых персонажей, особенно низкодетализированных (как на пике) там был бы просто 20 из 10. Риггать можно не снимая свитер, а потом прямо в рилтайме в коде игры менять им форму головы, въебать новые конечности, аугментации, изменить рост, комплекцию и т.д. И это всё было бы делать очень легко. С анимациями там тоже было бы красиво (см. https://youtu.be/KLjTU0yKS00). Но это просто опиздоебический объем работы. ТАм не только либу но целый редактор пришлось бы писать с нуля, я подумал что это слишком дохуя работы даже для простого кирилла в голове, и понял что лучше сделать что то простое по визуалу, но с огромным количеством всяких эмерджнтых механик.
Но вообще с 3д миром и 2д предметами в мире я подумаю, довольно хорошая затея, не знаю, надо поэкспериментировать еще с 2д раз у меня мысли есть.
Щас я настолько опустился по ожиданиям что даже существам анимацию ног не даю. Будут сука скользить + декаль шагов под ногами. Оружие, щиты перед ними "летать" будет. Потому что тоже для боевки с точки зрения механики у меня много придумано, но визуально такое делать это сдохнешь нахуй. Но не думай, совсем про юзабилити забывать я не собираюсь, я постараюсь именно в таких сжатых рамках всё равно сделать так чтобы игра могла норм восприниматься. Диволье кроется в деталях.
>Или видишь плоскость, которая на самом деле не плоская, и снова нихрена не понимаешь.
Диволье кроется в деталях. Я думаю тут можно что-то с этим сделать. хитрые тени или другие эффекты. Восприятие можно наебать если знать как.
>Можно даже сделать сразу два вида графики на выбор игрока, 2D и 3D
Идея будет работать только в случае если 3д окажутся только стены. Вот только как ты собрался поворачивать плавно такие объекты как телефон нахуй настенный? сбоку видно что он выпуклый, спереди он будет плоской картинкой. Когда ты камеру поворачиваешь он у тебя плоский, и в один момент переход на вид сбоку? Не слишком ли ёбань получается? Или дополнительно еще и хуярить для каждого предмета 2д и 3д вид? каво нахуй?
> код в _draw()
Да с этим я знаю. Не самые эффективные вещи. Моя задумка была использовать SVG, кешировать их в простые картинки и составлять из частей, или уже зааготовленные картинки и их уже рендерить. Драв использовать только местами.
>А ты альфу 4.0 используешь? Она же нестабильна очень...
Там фичи сочные (ГДскрипт2 как минимум), можно и потерпеть. А то потом еще проект переписывать весь под 4 когда зарелизится. Всё равно пока ничего особого не сделано.
1014 Кб, 1200x675>>17822
А, это то я знаю. Я вообще для 3д хотел пользовать вот эту библиотеку https://github.com/Zylann/godot_voxel .
Это я тоже знал.
Вот это интересная штука.
Не совсем как в споре, там существа в одну сетку превращались, а у меня они сегментами получается должны быть.
Да я же не против 3д в целом, просто тут есть баланс между удобство восприятия/юзабилити и объемом механик игровых и т.д. Ресурсы для соло разработчика, как ты понимаешь дико ограничены, я не могу просто мыть уверенным, что начни я всё делать в 3д, или хотя бы часть, не придётся постоянно повышать комплексность этих всех визуализационных систем, просто ради того чтобы они хоть как-то передавали непосредственный стейт мира, а не просто были кубиком на котором написано "он в говне и немного порушен, но так шо свет через него проходит" (как пример, может еще сложнее вещи будут)
Этот баланс между сложностью и комплексностью механик и юзабилити вообще не решаем определённо. Почти каждая игра склоняется к юзабилити, и мало какие (за редким почти неизвестным исключением) склоняются к первому. Держать тут баланс это очень огронмый труд, часто пришлось бы ебашить целые экосистемы новые. До этого я хотел рогуль сделать от 1-го лица на маленьких (несколько км радиусом) планетах, и контент генерацию через свою собственную либу сделать. Даже доки какие-то написал перед созданием. Там с помощью SDF, разных генераций скелетов и блендинга можно было параметрические предметы, существ, даже небо и аллаха создавать. Я придумал как с помощью СДФ риггать не только модельку, но и перетекание форм при анимации. Например изменение объема бицепса. Это была бы просто ебическая мощная штука, во первых сам процесс создания новых персонажей, особенно низкодетализированных (как на пике) там был бы просто 20 из 10. Риггать можно не снимая свитер, а потом прямо в рилтайме в коде игры менять им форму головы, въебать новые конечности, аугментации, изменить рост, комплекцию и т.д. И это всё было бы делать очень легко. С анимациями там тоже было бы красиво (см. https://youtu.be/KLjTU0yKS00). Но это просто опиздоебический объем работы. ТАм не только либу но целый редактор пришлось бы писать с нуля, я подумал что это слишком дохуя работы даже для простого кирилла в голове, и понял что лучше сделать что то простое по визуалу, но с огромным количеством всяких эмерджнтых механик.
Но вообще с 3д миром и 2д предметами в мире я подумаю, довольно хорошая затея, не знаю, надо поэкспериментировать еще с 2д раз у меня мысли есть.
Щас я настолько опустился по ожиданиям что даже существам анимацию ног не даю. Будут сука скользить + декаль шагов под ногами. Оружие, щиты перед ними "летать" будет. Потому что тоже для боевки с точки зрения механики у меня много придумано, но визуально такое делать это сдохнешь нахуй. Но не думай, совсем про юзабилити забывать я не собираюсь, я постараюсь именно в таких сжатых рамках всё равно сделать так чтобы игра могла норм восприниматься. Диволье кроется в деталях.
Диволье кроется в деталях. Я думаю тут можно что-то с этим сделать. хитрые тени или другие эффекты. Восприятие можно наебать если знать как.
Идея будет работать только в случае если 3д окажутся только стены. Вот только как ты собрался поворачивать плавно такие объекты как телефон нахуй настенный? сбоку видно что он выпуклый, спереди он будет плоской картинкой. Когда ты камеру поворачиваешь он у тебя плоский, и в один момент переход на вид сбоку? Не слишком ли ёбань получается? Или дополнительно еще и хуярить для каждого предмета 2д и 3д вид? каво нахуй?
Да с этим я знаю. Не самые эффективные вещи. Моя задумка была использовать SVG, кешировать их в простые картинки и составлять из частей, или уже зааготовленные картинки и их уже рендерить. Драв использовать только местами.
Там фичи сочные (ГДскрипт2 как минимум), можно и потерпеть. А то потом еще проект переписывать весь под 4 когда зарелизится. Всё равно пока ничего особого не сделано.
>GridMap для клеточно-тайлового мира, MultiMeshInstance для большого количества близко расположенных одинаковых мешей, система "комнат" и окклюдеров для скрытия/отображения лишнего/нужного,
А, это то я знаю. Я вообще для 3д хотел пользовать вот эту библиотеку https://github.com/Zylann/godot_voxel .
>А что именно тебя интересует? Есть разные применения такого подхода.
Это я тоже знал.
>Генерация скелетов, или мерджинг, скелета из разных частей.
Вот это интересная штука.
> Ты как будто Spore хочешь делать. Но, вроде, это всё возможно сделать на Godot. Инструменты есть.
Не совсем как в споре, там существа в одну сетку превращались, а у меня они сегментами получается должны быть.
>Ну и в чём тогда проблема сделать трёхмерные фигурки а-ля фигуры из шахмат?
Да я же не против 3д в целом, просто тут есть баланс между удобство восприятия/юзабилити и объемом механик игровых и т.д. Ресурсы для соло разработчика, как ты понимаешь дико ограничены, я не могу просто мыть уверенным, что начни я всё делать в 3д, или хотя бы часть, не придётся постоянно повышать комплексность этих всех визуализационных систем, просто ради того чтобы они хоть как-то передавали непосредственный стейт мира, а не просто были кубиком на котором написано "он в говне и немного порушен, но так шо свет через него проходит" (как пример, может еще сложнее вещи будут)
Этот баланс между сложностью и комплексностью механик и юзабилити вообще не решаем определённо. Почти каждая игра склоняется к юзабилити, и мало какие (за редким почти неизвестным исключением) склоняются к первому. Держать тут баланс это очень огронмый труд, часто пришлось бы ебашить целые экосистемы новые. До этого я хотел рогуль сделать от 1-го лица на маленьких (несколько км радиусом) планетах, и контент генерацию через свою собственную либу сделать. Даже доки какие-то написал перед созданием. Там с помощью SDF, разных генераций скелетов и блендинга можно было параметрические предметы, существ, даже небо и аллаха создавать. Я придумал как с помощью СДФ риггать не только модельку, но и перетекание форм при анимации. Например изменение объема бицепса. Это была бы просто ебическая мощная штука, во первых сам процесс создания новых персонажей, особенно низкодетализированных (как на пике) там был бы просто 20 из 10. Риггать можно не снимая свитер, а потом прямо в рилтайме в коде игры менять им форму головы, въебать новые конечности, аугментации, изменить рост, комплекцию и т.д. И это всё было бы делать очень легко. С анимациями там тоже было бы красиво (см. https://youtu.be/KLjTU0yKS00). Но это просто опиздоебический объем работы. ТАм не только либу но целый редактор пришлось бы писать с нуля, я подумал что это слишком дохуя работы даже для простого кирилла в голове, и понял что лучше сделать что то простое по визуалу, но с огромным количеством всяких эмерджнтых механик.
Но вообще с 3д миром и 2д предметами в мире я подумаю, довольно хорошая затея, не знаю, надо поэкспериментировать еще с 2д раз у меня мысли есть.
Щас я настолько опустился по ожиданиям что даже существам анимацию ног не даю. Будут сука скользить + декаль шагов под ногами. Оружие, щиты перед ними "летать" будет. Потому что тоже для боевки с точки зрения механики у меня много придумано, но визуально такое делать это сдохнешь нахуй. Но не думай, совсем про юзабилити забывать я не собираюсь, я постараюсь именно в таких сжатых рамках всё равно сделать так чтобы игра могла норм восприниматься. Диволье кроется в деталях.
>Или видишь плоскость, которая на самом деле не плоская, и снова нихрена не понимаешь.
Диволье кроется в деталях. Я думаю тут можно что-то с этим сделать. хитрые тени или другие эффекты. Восприятие можно наебать если знать как.
>Можно даже сделать сразу два вида графики на выбор игрока, 2D и 3D
Идея будет работать только в случае если 3д окажутся только стены. Вот только как ты собрался поворачивать плавно такие объекты как телефон нахуй настенный? сбоку видно что он выпуклый, спереди он будет плоской картинкой. Когда ты камеру поворачиваешь он у тебя плоский, и в один момент переход на вид сбоку? Не слишком ли ёбань получается? Или дополнительно еще и хуярить для каждого предмета 2д и 3д вид? каво нахуй?
> код в _draw()
Да с этим я знаю. Не самые эффективные вещи. Моя задумка была использовать SVG, кешировать их в простые картинки и составлять из частей, или уже зааготовленные картинки и их уже рендерить. Драв использовать только местами.
>А ты альфу 4.0 используешь? Она же нестабильна очень...
Там фичи сочные (ГДскрипт2 как минимум), можно и потерпеть. А то потом еще проект переписывать весь под 4 когда зарелизится. Всё равно пока ничего особого не сделано.
>>17888
Вот что то типа редактора, но там только модели без риггинга + не знаю как оно всё экспортируется в меш.
Вот похожие либы на юнити, но я хотел опенсус и без рилтайм анимаций геометрии (постоянно перестраивать геометрию очень жирно, всё должно в меши запекаться). Алгоритм дуалмарчинга тоже собирался юзать.
https://assetstore.unity.com/packages/tools/particles-effects/mudbun-volumetric-vfx-modeling-177891
https://assetstore.unity.com/packages/tools/game-toolkits/clayxels-165312
>и контент генерацию через свою собственную либу сделать.
Вот что то типа редактора, но там только модели без риггинга + не знаю как оно всё экспортируется в меш.
Вот похожие либы на юнити, но я хотел опенсус и без рилтайм анимаций геометрии (постоянно перестраивать геометрию очень жирно, всё должно в меши запекаться). Алгоритм дуалмарчинга тоже собирался юзать.
https://assetstore.unity.com/packages/tools/particles-effects/mudbun-volumetric-vfx-modeling-177891
https://assetstore.unity.com/packages/tools/game-toolkits/clayxels-165312
21 Кб, 421x627>>15359 (OP)
Возможно ли круги, которые рисуются как матрица в цикле рисовать в некое подготовленное изображение?
На картинке результат отрисовки в цикле в функции _draw(), что не фонтан по скорости и жору оперативки
Возможно ли круги, которые рисуются как матрица в цикле рисовать в некое подготовленное изображение?
На картинке результат отрисовки в цикле в функции _draw(), что не фонтан по скорости и жору оперативки
Со временем понял главное, всё что нужно от движка это вывод графики.
Это невероятно трудоёмкая и багогенерируемая задача, которая желательно должна быть максимально реализована и оптимизирована из коробки.
По сравнению с ней сама игровая логика это так, детская прогулка. Если движок заставляет юзера пердолица с реализацией какиз-то функций по выводу графики, то лучше его сразу дропать.
Это невероятно трудоёмкая и багогенерируемая задача, которая желательно должна быть максимально реализована и оптимизирована из коробки.
По сравнению с ней сама игровая логика это так, детская прогулка. Если движок заставляет юзера пердолица с реализацией какиз-то функций по выводу графики, то лучше его сразу дропать.
54 Кб, 1444x881>>17976 (Del)
Благодарю, попробую, пока получилось с полигонами и оперативку не жрёт пачкой
Теперь ещё вопрос - я нашёл как делать скрин, но это скрин не всех данных в окне, а только той части, что видна на общем экране, мне нужен скрин всего окна даже если оно больше реальных размеров монитора.
Благодарю, попробую, пока получилось с полигонами и оперативку не жрёт пачкой
Теперь ещё вопрос - я нашёл как делать скрин, но это скрин не всех данных в окне, а только той части, что видна на общем экране, мне нужен скрин всего окна даже если оно больше реальных размеров монитора.
>>17981
Тоже верно и про создание ГУИ, С++ + опенгл хорош, но лютый гемор сделать основу для отрисовки нужного
Тоже верно и про создание ГУИ, С++ + опенгл хорош, но лютый гемор сделать основу для отрисовки нужного
>>17976 (Del)
Гуру поиска, а помоги и мне, плиз?
Мне нужен шейдер, который принимает на вход массив точек (я знаю, что массивы пока что нельзя, я планирую нахуярить 255 переменных и из скрипта их заполнять из массива) и отрисовывает по этим точкам кривую.
Гуру поиска, а помоги и мне, плиз?
Мне нужен шейдер, который принимает на вход массив точек (я знаю, что массивы пока что нельзя, я планирую нахуярить 255 переменных и из скрипта их заполнять из массива) и отрисовывает по этим точкам кривую.
>>17997
Стоит написать в тред просьбу, как тут же находится ответ самостоятельно! Чудеса!
https://www.youtube.com/watch?v=4S6G-zenbFM
Стоит написать в тред просьбу, как тут же находится ответ самостоятельно! Чудеса!
https://www.youtube.com/watch?v=4S6G-zenbFM
>>18002
А хотя, надо ещё погуглить, сдаётся мне, я охуею высчитывать лагранжиан 255 точек.
А хотя, надо ещё погуглить, сдаётся мне, я охуею высчитывать лагранжиан 255 точек.
>>18003
Ты можешь просто рисовать квадратные полигоны с координатами точек
Так же массив сделать из векторов не проблема, ну и цвета
Ты можешь просто рисовать квадратные полигоны с координатами точек
Так же массив сделать из векторов не проблема, ну и цвета
72 Кб, 846x440Возникла подобная проблема - нужно сохранить текстуру после обработки шейдером в файл, при сохранении програмно текстуры, она сохраняется без изменений
Ну и актуален вопрос сохранения буфера изображения окна годота целиком, а не того, что попадает в окно
Ну и актуален вопрос сохранения буфера изображения окна годота целиком, а не того, что попадает в окно
>>18004
Речь идёт о шейдере. Шейдер - это матанматическая функция в интервале 0;0..1;1 рисующая точки R;G;B;A. Я могу подкинуть внутрь этой функции константу, и проверять ифом, но каждый иф в шейдере умножает его производительность на 0,5. Идеальный вариант для меня был бы - лангранжиан, который без ифов просто высчитывает кривую по точкам. Если я всё правильно понимаю.
> Ты можешь просто рисовать квадратные полигоны с координатами точек
Речь идёт о шейдере. Шейдер - это матанматическая функция в интервале 0;0..1;1 рисующая точки R;G;B;A. Я могу подкинуть внутрь этой функции константу, и проверять ифом, но каждый иф в шейдере умножает его производительность на 0,5. Идеальный вариант для меня был бы - лангранжиан, который без ифов просто высчитывает кривую по точкам. Если я всё правильно понимаю.
>>18142
А вычислить положения ЦПУ и закинуть в шейдер?
Я просто точно могу сказать как это сделать на ЦПУ в годо и при необходимости можно порезать углы - запомнить некоторые повторяющиеся вычисления
А вычислить положения ЦПУ и закинуть в шейдер?
Я просто точно могу сказать как это сделать на ЦПУ в годо и при необходимости можно порезать углы - запомнить некоторые повторяющиеся вычисления
>>17969
Добавляешь ноду, на которой рисуешь, во Viewport.
Делаешь это присваивание:
И забираешь текстуру из Viewport. Если текстура нужна для какого-то объекта на сцене, можно связать её заранее (ViewportTexture). Если текстура нужна в сыром виде и как можно раньше, придётся подождать один кадр, когда Viewport закончит отрисовку.
Я так карту мира рисую. Один кадр = готовая карта, после чего отображается только полученная текстура.
>На картинке результат отрисовки в цикле в функции _draw(), что не фонтан по скорости и жору оперативки
Добавляешь ноду, на которой рисуешь, во Viewport.
Делаешь это присваивание:
>viewport.render_target_update_mode = UPDATE_ONCE
И забираешь текстуру из Viewport. Если текстура нужна для какого-то объекта на сцене, можно связать её заранее (ViewportTexture). Если текстура нужна в сыром виде и как можно раньше, придётся подождать один кадр, когда Viewport закончит отрисовку.
Я так карту мира рисую. Один кадр = готовая карта, после чего отображается только полученная текстура.
>>18236
Заебца! Попробую.
Заебца! Попробую.
339 Кб, 1044x881>>18236
Проблема осталась, мне нужен скрин всего изображения, а сохраняет только то, что в экран попало.
Как вариант масштабировать окно с сохранением высокго разрешения, но я не нашёл как это сделать.
Проблема осталась, мне нужен скрин всего изображения, а сохраняет только то, что в экран попало.
Как вариант масштабировать окно с сохранением высокго разрешения, но я не нашёл как это сделать.
>>18296
Эээ... Ты точно правильно настроил Viewport? Ты можешь настроить в нём любое разрешение, которое никак не зависит от размера окна (окно рендерится в основном вьюпорте, а ты создаёшь второй). Куда ты потом текстуру с этого вьюпорта денешь - зависит от тебя. Ты можешь не выводить её на экран, а сразу сохранить в файл, если ты занимаешься чем-то вроде конвертации изображений. Так будет даже быстрее, чем делать скриншот экрана (основного вьюпорта).
Алгоритм такой:
1. Загружаешь исходную картинку.
2. Задаёшь специально созданному Viewport размер текстуры в соответствии с размером картинки.
3. Рисуешь картинку своими кругами в _draw() CanvasItem, который размещён в твоём Viewport.
4. viewport.render_target_update_mode = Viewport.UPDATE_ONCE
5. Ждёшь следующего кадра, когда Viewport закончит работу.
6. Берешь текстуру с Viewport и сохраняешь в файл.
>мне нужен скрин всего изображения, а сохраняет только то, что в экран попало
Эээ... Ты точно правильно настроил Viewport? Ты можешь настроить в нём любое разрешение, которое никак не зависит от размера окна (окно рендерится в основном вьюпорте, а ты создаёшь второй). Куда ты потом текстуру с этого вьюпорта денешь - зависит от тебя. Ты можешь не выводить её на экран, а сразу сохранить в файл, если ты занимаешься чем-то вроде конвертации изображений. Так будет даже быстрее, чем делать скриншот экрана (основного вьюпорта).
Алгоритм такой:
1. Загружаешь исходную картинку.
2. Задаёшь специально созданному Viewport размер текстуры в соответствии с размером картинки.
3. Рисуешь картинку своими кругами в _draw() CanvasItem, который размещён в твоём Viewport.
4. viewport.render_target_update_mode = Viewport.UPDATE_ONCE
5. Ждёшь следующего кадра, когда Viewport закончит работу.
6. Берешь текстуру с Viewport и сохраняешь в файл.
>>18187
На, по точкам нету рисовки, зато как в максе, рино, автокаде, хрензнаетещёчто, рисовать линии по двум точкам легко и довольно бистро
Шейдер посмотрел, но ничего интересного не нашёл, но наверняка можно эти точки передавать в него и по ним например квадраты отрисовывать
На, по точкам нету рисовки, зато как в максе, рино, автокаде, хрензнаетещёчто, рисовать линии по двум точкам легко и довольно бистро
Шейдер посмотрел, но ничего интересного не нашёл, но наверняка можно эти точки передавать в него и по ним например квадраты отрисовывать
>>18310
Уже понятнее, осталось только узнать как рисовать в конкретный viewport.
Я вчера инет как мог обыскивал, но то, чего ты пишешь не нашёл, лишь намёки и не по теме
Уже понятнее, осталось только узнать как рисовать в конкретный viewport.
Я вчера инет как мог обыскивал, но то, чего ты пишешь не нашёл, лишь намёки и не по теме
>>18312
Да блять, даже я понял, как! Ты не во вьюпорт рисуешь, а в ноду, которую ты положил во вьюпорт. А готовую текстуру берешь со вьюпорта. Ты даже можешь несколько нод положить во вьюпорт, влодить друг в друга, и рисовать в каждой из них. И на выходе получишь одну готовую вьюпорт-текстуру.
мимо
> узнать как рисовать в конкретный viewport
Да блять, даже я понял, как! Ты не во вьюпорт рисуешь, а в ноду, которую ты положил во вьюпорт. А готовую текстуру берешь со вьюпорта. Ты даже можешь несколько нод положить во вьюпорт, влодить друг в друга, и рисовать в каждой из них. И на выходе получишь одну готовую вьюпорт-текстуру.
мимо
>>18311
Блять. Советы уровня ПРО, базара ноль. Синус отрисовать - эт конешно мощ.
У меня ващет массив точек строится динамически из движений мышки игрока.
> На,
Блять. Советы уровня ПРО, базара ноль. Синус отрисовать - эт конешно мощ.
У меня ващет массив точек строится динамически из движений мышки игрока.
>>18326
Так и в чём проблема? Это сожрёт любой массив с точками
>>18324
Херня какая-то анон
Как я вижу то, что он предлагает - есть буфер, в который рисуется изображение и текстуры - основной, а можно создать дополнительный и рисовать в него, такой, что он будет иметь любое разрешение и его можно сжать до любого масштаба.
Твоё объяснение только путает ещё больше
Ещё пример - С++ + опенгл - создаём массив нужного разрешения, в него пишем некое изображение, создаём текстуру, с мелкими размерами, задаём ей размеры в пикселях, равные массиву, копируем, готово.
Ты бы лучше пример с кодом привёл, очень простой, где в отдельный вьюпорт рисуется квадрат - основное окно 320 на 240, а вьюпорт 1920 на 1080
Так и в чём проблема? Это сожрёт любой массив с точками
>>18324
Херня какая-то анон
Как я вижу то, что он предлагает - есть буфер, в который рисуется изображение и текстуры - основной, а можно создать дополнительный и рисовать в него, такой, что он будет иметь любое разрешение и его можно сжать до любого масштаба.
Твоё объяснение только путает ещё больше
Ещё пример - С++ + опенгл - создаём массив нужного разрешения, в него пишем некое изображение, создаём текстуру, с мелкими размерами, задаём ей размеры в пикселях, равные массиву, копируем, готово.
Ты бы лучше пример с кодом привёл, очень простой, где в отдельный вьюпорт рисуется квадрат - основное окно 320 на 240, а вьюпорт 1920 на 1080
19 Кб, 822x68>>18335
Сорян. Мало того, я щас пытаюсь реализовать его отрисовку в буфер через механизм вьюпортов, и получаю это:
> Твоё объяснение только путает ещё больше
Сорян. Мало того, я щас пытаюсь реализовать его отрисовку в буфер через механизм вьюпортов, и получаю это:
>>18335
То, что написано в документации.
Выше ссылка была, ты почему не читал?
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
>>18348
Зачем тебе Camera2D, если ты рисуешь на Control? Зачем тебе ViewportContainter, если ты можешь и должен задавать размер Viewport вручную, чтобы не зависеть от размера экрана? Зачем тебе TextureRect, если ты рисуешь через _draw()?
>что он предлагает
То, что написано в документации.
Выше ссылка была, ты почему не читал?
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
>Think of a Viewport as a screen onto which the game is projected. In order to see the game, we need to have a surface on which to draw it; that surface is the Root Viewport.
>Viewports can also be added to the scene so that there are multiple surfaces to draw on. When we are drawing to a Viewport that is not the Root, we call it a render target. We can access the contents of a render target by accessing its corresponding texture. By using a Viewport as a render target, we can either render multiple scenes simultaneously or we can render to a texture which is applied to an object in the scene, for example a dynamic skybox.
>>18348
Зачем тебе Camera2D, если ты рисуешь на Control? Зачем тебе ViewportContainter, если ты можешь и должен задавать размер Viewport вручную, чтобы не зависеть от размера экрана? Зачем тебе TextureRect, если ты рисуешь через _draw()?
Сразу скажу - гуглить лень, предлагаю обсудить.
Как можно реализовать автотайлинг из TileMap в GridMap? Предложите/укажите самые общие алгоритмы, как это вообще может делаться универсально. Я задолбался писать портянки с кучей магических чисел на каждый элемент гридмапы и хочу либо всё бросить, либо переписать универсально, но не понимаю, как это сделать. Я даже в TileMap плохо понимаю автотайлинг, а в GridMap его вообще нет... Почему они его не сделали?
Как можно реализовать автотайлинг из TileMap в GridMap? Предложите/укажите самые общие алгоритмы, как это вообще может делаться универсально. Я задолбался писать портянки с кучей магических чисел на каждый элемент гридмапы и хочу либо всё бросить, либо переписать универсально, но не понимаю, как это сделать. Я даже в TileMap плохо понимаю автотайлинг, а в GridMap его вообще нет... Почему они его не сделали?
>>18579
Ладно, я погуглил - примеров много (2D), но все какие-то сложные и тоже состоят из магических чисел. Я бы хотел реализовать что-то типа битовых масок из TileMap, только указывать их буду во внешнем .json файле для каждого тайлсета.
Но всё равно предлагаю обсудить. Кто уже сталкивался с этим? Как решили? Должна ли эта фича быть из коробки?
GridMap как-то недоделанным выглядит...
>гуглить лень
Ладно, я погуглил - примеров много (2D), но все какие-то сложные и тоже состоят из магических чисел. Я бы хотел реализовать что-то типа битовых масок из TileMap, только указывать их буду во внешнем .json файле для каждого тайлсета.
Но всё равно предлагаю обсудить. Кто уже сталкивался с этим? Как решили? Должна ли эта фича быть из коробки?
GridMap как-то недоделанным выглядит...
89 Кб, 960x600А чё, где все? ТВГ же закончился вроде? Алсо народ массово мигрирует с юнити на годо в свете недавних событий, а тут я сам с собой общаюсь в полном одиночестве(
>>18579
Решил, что пока сойдёт ad hoc решение, которое я, оказывается, сделал ещё вчера, нужно было только поправить пару ошибок... По мере усложнения проекта, надеюсь, удастся выработать что-то более универсальное, а пока и так сойдёт.
Только теперь снова встала в полный рост проблема с чарактер контроллером. Дело в том, что я поставил персонажа на рейкаст в качестве "ноги", благодаря чему персонаж может легко "шагать" на бордюры и другие мелкие выступы. Но этот же рейкаст заставляет его взлетать на любые наклонные поверхности, например, почти вертикальные стволы деревьев и, конечно, эти склоны (пока что всего лишь 60°, нужно увеличить). Настройки рейкаста и move_and_slide_with_snap() ничего не дают, значение наклонной поверхности в 45° не мешает взлетать на стены. Я чего-то не понимаю? Я должен сам определять, когда нужно остановиться, проверяя нормаль точки опоры? Так лень это делать...
Алсо, меня уже который месяц бесит поведение теней от источников света в Godot. Ладно тень от солнца улетает от ног персонажа, тут я вообще не уверен, по-моему, это персонаж по воздуху "ходит". Главная проблема с тенями от SpotLight. Мне нужны 1-2 фонарика на машину и один фонарик для персонажа, если я хочу полноценную симуляцию ночных условий (ладно ночью я добавил свет от луны, но на закате и восходе вообще ничего кроме неба не видно, лол). Так вот, свет от фонарика очень часто покрывается решёткой тени, независимо от настроек shadow_bias и других, и я не могу завысить это значение, т.к. тогда тень выглядит так, будто фонарик за спиной персонажа или светит изнутри машины. Если тени отключить, всё идеально, но без теней свет выглядит ненатурально.
Меня уже волнует больше не способ решения этой проблемы, а причина этой проблемы. Почему я никогда не видел таких артефактов в различных 3D играх? Я видел плохие тени, видел размытые тени, видел пиксельные тени и тени в виде шахматной доски, но эти тени были только там, где они должны быть, а не поверх всего, на что попадает свет. И многие игры сделаны на OpenGL... впрочем, насколько мне известно, в OpenGL нет встроенных теней, есть только источники света, а тени каждый делает сам. Значит, в Godot просто хреновая реализация теней на OpenGL? Почему за столько лет не нашли приемлемого решения? Эти тени могут выглядеть хорошо только если источник света зафиксирован и объекты статичны, иначе обязательно найдётся угол, под которым всё покрывается решёткой...
Пойду снова гуглить решение этой проблемы... Очень надеюсь, что они пофиксили это в 4.0, тогда будет больше мотивации перекатываться на бету.
>>18579
>самые общие алгоритмы, как это вообще может делаться универсально
Решил, что пока сойдёт ad hoc решение, которое я, оказывается, сделал ещё вчера, нужно было только поправить пару ошибок... По мере усложнения проекта, надеюсь, удастся выработать что-то более универсальное, а пока и так сойдёт.
Только теперь снова встала в полный рост проблема с чарактер контроллером. Дело в том, что я поставил персонажа на рейкаст в качестве "ноги", благодаря чему персонаж может легко "шагать" на бордюры и другие мелкие выступы. Но этот же рейкаст заставляет его взлетать на любые наклонные поверхности, например, почти вертикальные стволы деревьев и, конечно, эти склоны (пока что всего лишь 60°, нужно увеличить). Настройки рейкаста и move_and_slide_with_snap() ничего не дают, значение наклонной поверхности в 45° не мешает взлетать на стены. Я чего-то не понимаю? Я должен сам определять, когда нужно остановиться, проверяя нормаль точки опоры? Так лень это делать...
Алсо, меня уже который месяц бесит поведение теней от источников света в Godot. Ладно тень от солнца улетает от ног персонажа, тут я вообще не уверен, по-моему, это персонаж по воздуху "ходит". Главная проблема с тенями от SpotLight. Мне нужны 1-2 фонарика на машину и один фонарик для персонажа, если я хочу полноценную симуляцию ночных условий (ладно ночью я добавил свет от луны, но на закате и восходе вообще ничего кроме неба не видно, лол). Так вот, свет от фонарика очень часто покрывается решёткой тени, независимо от настроек shadow_bias и других, и я не могу завысить это значение, т.к. тогда тень выглядит так, будто фонарик за спиной персонажа или светит изнутри машины. Если тени отключить, всё идеально, но без теней свет выглядит ненатурально.
Меня уже волнует больше не способ решения этой проблемы, а причина этой проблемы. Почему я никогда не видел таких артефактов в различных 3D играх? Я видел плохие тени, видел размытые тени, видел пиксельные тени и тени в виде шахматной доски, но эти тени были только там, где они должны быть, а не поверх всего, на что попадает свет. И многие игры сделаны на OpenGL... впрочем, насколько мне известно, в OpenGL нет встроенных теней, есть только источники света, а тени каждый делает сам. Значит, в Godot просто хреновая реализация теней на OpenGL? Почему за столько лет не нашли приемлемого решения? Эти тени могут выглядеть хорошо только если источник света зафиксирован и объекты статичны, иначе обязательно найдётся угол, под которым всё покрывается решёткой...
Пойду снова гуглить решение этой проблемы... Очень надеюсь, что они пофиксили это в 4.0, тогда будет больше мотивации перекатываться на бету.
89 Кб, 960x600А чё, где все? ТВГ же закончился вроде? Алсо народ массово мигрирует с юнити на годо в свете недавних событий, а тут я сам с собой общаюсь в полном одиночестве(
>>18579
Решил, что пока сойдёт ad hoc решение, которое я, оказывается, сделал ещё вчера, нужно было только поправить пару ошибок... По мере усложнения проекта, надеюсь, удастся выработать что-то более универсальное, а пока и так сойдёт.
Только теперь снова встала в полный рост проблема с чарактер контроллером. Дело в том, что я поставил персонажа на рейкаст в качестве "ноги", благодаря чему персонаж может легко "шагать" на бордюры и другие мелкие выступы. Но этот же рейкаст заставляет его взлетать на любые наклонные поверхности, например, почти вертикальные стволы деревьев и, конечно, эти склоны (пока что всего лишь 60°, нужно увеличить). Настройки рейкаста и move_and_slide_with_snap() ничего не дают, значение наклонной поверхности в 45° не мешает взлетать на стены. Я чего-то не понимаю? Я должен сам определять, когда нужно остановиться, проверяя нормаль точки опоры? Так лень это делать...
Алсо, меня уже который месяц бесит поведение теней от источников света в Godot. Ладно тень от солнца улетает от ног персонажа, тут я вообще не уверен, по-моему, это персонаж по воздуху "ходит". Главная проблема с тенями от SpotLight. Мне нужны 1-2 фонарика на машину и один фонарик для персонажа, если я хочу полноценную симуляцию ночных условий (ладно ночью я добавил свет от луны, но на закате и восходе вообще ничего кроме неба не видно, лол). Так вот, свет от фонарика очень часто покрывается решёткой тени, независимо от настроек shadow_bias и других, и я не могу завысить это значение, т.к. тогда тень выглядит так, будто фонарик за спиной персонажа или светит изнутри машины. Если тени отключить, всё идеально, но без теней свет выглядит ненатурально.
Меня уже волнует больше не способ решения этой проблемы, а причина этой проблемы. Почему я никогда не видел таких артефактов в различных 3D играх? Я видел плохие тени, видел размытые тени, видел пиксельные тени и тени в виде шахматной доски, но эти тени были только там, где они должны быть, а не поверх всего, на что попадает свет. И многие игры сделаны на OpenGL... впрочем, насколько мне известно, в OpenGL нет встроенных теней, есть только источники света, а тени каждый делает сам. Значит, в Godot просто хреновая реализация теней на OpenGL? Почему за столько лет не нашли приемлемого решения? Эти тени могут выглядеть хорошо только если источник света зафиксирован и объекты статичны, иначе обязательно найдётся угол, под которым всё покрывается решёткой...
Пойду снова гуглить решение этой проблемы... Очень надеюсь, что они пофиксили это в 4.0, тогда будет больше мотивации перекатываться на бету.
>>18579
>самые общие алгоритмы, как это вообще может делаться универсально
Решил, что пока сойдёт ad hoc решение, которое я, оказывается, сделал ещё вчера, нужно было только поправить пару ошибок... По мере усложнения проекта, надеюсь, удастся выработать что-то более универсальное, а пока и так сойдёт.
Только теперь снова встала в полный рост проблема с чарактер контроллером. Дело в том, что я поставил персонажа на рейкаст в качестве "ноги", благодаря чему персонаж может легко "шагать" на бордюры и другие мелкие выступы. Но этот же рейкаст заставляет его взлетать на любые наклонные поверхности, например, почти вертикальные стволы деревьев и, конечно, эти склоны (пока что всего лишь 60°, нужно увеличить). Настройки рейкаста и move_and_slide_with_snap() ничего не дают, значение наклонной поверхности в 45° не мешает взлетать на стены. Я чего-то не понимаю? Я должен сам определять, когда нужно остановиться, проверяя нормаль точки опоры? Так лень это делать...
Алсо, меня уже который месяц бесит поведение теней от источников света в Godot. Ладно тень от солнца улетает от ног персонажа, тут я вообще не уверен, по-моему, это персонаж по воздуху "ходит". Главная проблема с тенями от SpotLight. Мне нужны 1-2 фонарика на машину и один фонарик для персонажа, если я хочу полноценную симуляцию ночных условий (ладно ночью я добавил свет от луны, но на закате и восходе вообще ничего кроме неба не видно, лол). Так вот, свет от фонарика очень часто покрывается решёткой тени, независимо от настроек shadow_bias и других, и я не могу завысить это значение, т.к. тогда тень выглядит так, будто фонарик за спиной персонажа или светит изнутри машины. Если тени отключить, всё идеально, но без теней свет выглядит ненатурально.
Меня уже волнует больше не способ решения этой проблемы, а причина этой проблемы. Почему я никогда не видел таких артефактов в различных 3D играх? Я видел плохие тени, видел размытые тени, видел пиксельные тени и тени в виде шахматной доски, но эти тени были только там, где они должны быть, а не поверх всего, на что попадает свет. И многие игры сделаны на OpenGL... впрочем, насколько мне известно, в OpenGL нет встроенных теней, есть только источники света, а тени каждый делает сам. Значит, в Godot просто хреновая реализация теней на OpenGL? Почему за столько лет не нашли приемлемого решения? Эти тени могут выглядеть хорошо только если источник света зафиксирован и объекты статичны, иначе обязательно найдётся угол, под которым всё покрывается решёткой...
Пойду снова гуглить решение этой проблемы... Очень надеюсь, что они пофиксили это в 4.0, тогда будет больше мотивации перекатываться на бету.
>>18772
Ну да, в выводе 3D графония гигантский конвеер, полагать что один человек нормально закодит всё это крайне наивно. Тут и 100 человек мало будет для хорошей реализации. Просто вдумайся сколько это человеко-часов.
Ну да, в выводе 3D графония гигантский конвеер, полагать что один человек нормально закодит всё это крайне наивно. Тут и 100 человек мало будет для хорошей реализации. Просто вдумайся сколько это человеко-часов.
>>18579
Так же, через маски, только аналогом маски 2х2 будет 2х2х2, а аналогом 3х3 будет 3х3х3, символизирующая куб-ячейку и окружающие её.
ХЗ, ИМХО у них задачи посущественнее на первом плане, чем пилить функционал, который будет юзать один анон из далёкой России.
>>18772
Я пиво пил, шашлыки кушал. Щас поотвечаю на вопросы ИТТ и обратно уйду ИРЛ. Лето на дворе, ёпт! Сходи пробздись.
> Как можно реализовать автотайлинг из TileMap в GridMap?
Так же, через маски, только аналогом маски 2х2 будет 2х2х2, а аналогом 3х3 будет 3х3х3, символизирующая куб-ячейку и окружающие её.
> Почему они его не сделали?
ХЗ, ИМХО у них задачи посущественнее на первом плане, чем пилить функционал, который будет юзать один анон из далёкой России.
>>18772
> А чё, где все? ТВГ же закончился вроде?
Я пиво пил, шашлыки кушал. Щас поотвечаю на вопросы ИТТ и обратно уйду ИРЛ. Лето на дворе, ёпт! Сходи пробздись.
>>18772
Причина в том, что посчитать тени - очень дорогостоящая операция. Её оптимизировали, как могли. Результат оптимизаций ты видишь.
Решение, самое современное: отдать расчёт теней сами-знаете-какой-видеокарте, которая посчитает тени (а заодно и отражения, с дифракциями-рефракциями) при помощи рейтрейсинга. Только у тебя такой видеокарты нет. И у меня нет. И в ближайшие годы не будет. А если и будет, нужно знать си++, чтобы модуль-адаптер к RTX-API написать и годот с этим модулем пересобрать. Так что в принципе, можешь начинать учить кресты уже сегодня. Не помешает.
> Меня уже волнует больше не способ решения этой проблемы, а причина этой проблемы.
Причина в том, что посчитать тени - очень дорогостоящая операция. Её оптимизировали, как могли. Результат оптимизаций ты видишь.
Решение, самое современное: отдать расчёт теней сами-знаете-какой-видеокарте, которая посчитает тени (а заодно и отражения, с дифракциями-рефракциями) при помощи рейтрейсинга. Только у тебя такой видеокарты нет. И у меня нет. И в ближайшие годы не будет. А если и будет, нужно знать си++, чтобы модуль-адаптер к RTX-API написать и годот с этим модулем пересобрать. Так что в принципе, можешь начинать учить кресты уже сегодня. Не помешает.
12,1 Мб, mp4,960x600, 2:04
Окончательно сломал демо-сцену в главном меню, которую собирал вручную, поэтому создал заново на базе основного генератора. Очень кстати оказалось использование ресурсов вместо нод и независимость генератора от остальных нод, раньше такой трюк я бы сделать не смог (поэтому и делал демо-сцену вручную).
В процессе импровизации добавил крутящуюся камеру и, самое интересное, затемнение экрана, скрывающее генерацию мира - внезапно получилось ощущение полноценной игры, прям ух, как круто выглядит, даже в майнкрафте такого нет (игрок видит прорисовку чанков в самом начале)! Надо только теперь понять, где этот эффект лучше хранить, в общей куче или локально...
Также попробовал сделать шейдер воды, но только после записи видео осознал, что шейдеры не встают на паузу. Придётся вместо TIME использовать uniform, задаваемый извне скриптом, тогда анимация должна останавливаться на паузу. И ещё, если я хочу сделать физику воды а-ля GTA3, мне придётся вычислять форму волны в определённой точке пространства на процессоре, ведь из шейдера эту информацию никак не достать?
Тормоза на видео скорее всего из-за записи OBS. Пробовал новые настройки кодировки, чтобы сразу записывалось компактно. Всё равно пришлось сжимать отдельно...
>>18772
Короче, не важно, я писал тот пост в состоянии фрустрации. В общем, оказалось, что это не источники света кривые, а моя тестовая 3D моделька мешалась своей вывернутой наизнанку поверхностью, которую я сделал по древним рекомендациям, для контура. Ну, не велика беда, мне такие глючные контуры не нравились.
Нужно выставить такие настройки:
shadow_reverse_cull_face = true
shadow_bias = -0.01
Тогда все тени будут работать нормально. Но с такой настройкой нельзя иметь меши с двухсторонней отрисовкой, они будут покрываться тенью/решёткой. Алсо толщина любых объектов должна быть больше shadow_bias (в абсолютном значении), т.е. одиночный полигон будет с одной стороны просвечивать, а слишком тонкая стенка может пропускать свет через углы. Вообще-то я уже ставил точно такие же настройки, но забыл об их предназначении.
>>18786
Не понимаю, о чём ты, там же всё на API вызовах построено, нужно только знать это API и уметь в математику.
Что касается теней, я погуглил, короче, решётка - это из-за пикселизации карт теней, т.е. карте теней не хватает разрешения для того, чтобы правильно спроецироваться на очень круто наклонённую поверхность. Поэтому артефакты возникают только на тех полигонах, которые расположены почти перпендикулярно плоскости экрана. Эта проблема касается любой реализации shadow mapping:
https://learnopengl.com/Advanced-Lighting/Shadows/Shadow-Mapping
https://computergraphics.stackexchange.com/questions/2192/
https://stackoverflow.com/questions/3849052/
Кстати, если я правильно понимаю, в Godot реализована техника Cascaded Shadow Maps - для неё тени рендерятся в несколько разрешений в зависимости от удалённости от камеры:
https://gamedev.stackexchange.com/questions/68016/
Только называется иначе, но суть та же:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#directional-shadow-mapping
>>19069
Вопрос был про алгоритм. У меня не получилось использовать такие маски, поэтому просто захардкодил числа)
Думаю, большинству 3D игр будет достаточно двухмерной маски, хотя трёхмерная даст больше возможностей.
GridMap так редко используют? Вот смотри, у них в официальных примерах есть что-то типа мини-гольфа. Предлагается делать карту полностью вручную, но в 2D на TileMap такое можно было бы хотя бы частично автоматизировать автотайлами. Хочешь 3D домик? Тебе придётся вручную выбирать направление стен. Хочешь дорогу? Придётся вручную расставлять кусочки дороги. Хотя это всё можно и нужно автоматизировать. Если GridMap рекомендуют использовать и его реально используют, то почему у него нет такой, очевидно полезной, фичи, как автотайлинг? Скорее всего просто некому этим заниматься, опенсурс такой опенсурс...
Впрочем, не важно, на GDScript это всё (определение блоков) не так много времени занимает. Куда больше волнует то, что заполнение GridMap большим количеством предметов ощутимо фризит игру и сбивает счётчик(и) времени >>17818, вплоть до зависания окна игры. Я, конечно, могу разделить обращения к GridMap по кадрам, но больше хотелось бы многопоточность... хм, а это идея, нужно попробовать использовать потоки, я как-то не задумывался об этом.
>>19072
Не совсем так, по ссылкам выше пройдись, причина этих артефактов в самой сути шедоу маппинга. Он по определению будет создавать такие артефакты, если не использовать определённые трюки. Разве что увеличение карты теней могло бы в теории помочь (даже в руководстве Godot рекомендуют), но я пробовал её увеличить - у меня оперативка переполнилась (2 ГБ + 8 ГБ + файл подкачки), лол, а артефакты как были, так и остались. Так что единственный реальный путь - вывернуть геометрию и стараться делать все объекты достаточно толстыми (ну, это вроде не проблема).
Сомневаюсь, что тени на рейтрейсинге имеют смысл. RTX просто бросает кучу прожорливых ядер на задачу, которая не стоит таких затрат мощности. Если карты теней дают достаточно хороший результат в большинстве сцен, зачем рейтрейсинг? В смысле, в большинстве игр ты не будешь обращать внимание на пиксели или размытие теней, лишь бы не было этой проклятой решётки поверх всего на свете. Особенно смешно выглядит применение рейтрейсинга для ультралоуполи графики с мультяшными текстурами или вообще без них. Из пушки по воробьям...
Базовый C++ понимаю. Но синтаксис C-подобных языков вызывает у меня отвращение: слишком много лишних спецсимволов там, где можно было бы обойтись обычными английскими буквами или вообще без всего. Поэтому не хочу кодить на нём.
Вот Паскаль, Ада и другие подобные языки - это приятно. GDScript норм, но лучше бы вместо табов добавили слово end как в Lua (лучше а-ля Ada: end func, end if, end for, end while и т.п.) - во-первых, код стал бы куда читабельнее, во-вторых, можно было бы копипастить на форумы, которые не поддерживают табы (сюда), в-третьих, не пришлось бы каждый раз писать pass для подавления "ошибок" в процессе написания очередного блока кода (иногда бесит). Жаль, что 4.0 уже скоро выходит в бету, так что такие изменения в GDScript если и стоит ждать, то только в 5.0. И то очень вряд ли, питонофильское лобби слишком сильно(
В процессе импровизации добавил крутящуюся камеру и, самое интересное, затемнение экрана, скрывающее генерацию мира - внезапно получилось ощущение полноценной игры, прям ух, как круто выглядит, даже в майнкрафте такого нет (игрок видит прорисовку чанков в самом начале)! Надо только теперь понять, где этот эффект лучше хранить, в общей куче или локально...
Также попробовал сделать шейдер воды, но только после записи видео осознал, что шейдеры не встают на паузу. Придётся вместо TIME использовать uniform, задаваемый извне скриптом, тогда анимация должна останавливаться на паузу. И ещё, если я хочу сделать физику воды а-ля GTA3, мне придётся вычислять форму волны в определённой точке пространства на процессоре, ведь из шейдера эту информацию никак не достать?
Тормоза на видео скорее всего из-за записи OBS. Пробовал новые настройки кодировки, чтобы сразу записывалось компактно. Всё равно пришлось сжимать отдельно...
>>18772
>бесит поведение теней от источников света
Короче, не важно, я писал тот пост в состоянии фрустрации. В общем, оказалось, что это не источники света кривые, а моя тестовая 3D моделька мешалась своей вывернутой наизнанку поверхностью, которую я сделал по древним рекомендациям, для контура. Ну, не велика беда, мне такие глючные контуры не нравились.
Нужно выставить такие настройки:
shadow_reverse_cull_face = true
shadow_bias = -0.01
Тогда все тени будут работать нормально. Но с такой настройкой нельзя иметь меши с двухсторонней отрисовкой, они будут покрываться тенью/решёткой. Алсо толщина любых объектов должна быть больше shadow_bias (в абсолютном значении), т.е. одиночный полигон будет с одной стороны просвечивать, а слишком тонкая стенка может пропускать свет через углы. Вообще-то я уже ставил точно такие же настройки, но забыл об их предназначении.
>>18786
>в выводе 3D графония гигантский конвеер
Не понимаю, о чём ты, там же всё на API вызовах построено, нужно только знать это API и уметь в математику.
Что касается теней, я погуглил, короче, решётка - это из-за пикселизации карт теней, т.е. карте теней не хватает разрешения для того, чтобы правильно спроецироваться на очень круто наклонённую поверхность. Поэтому артефакты возникают только на тех полигонах, которые расположены почти перпендикулярно плоскости экрана. Эта проблема касается любой реализации shadow mapping:
https://learnopengl.com/Advanced-Lighting/Shadows/Shadow-Mapping
https://computergraphics.stackexchange.com/questions/2192/
https://stackoverflow.com/questions/3849052/
>Shadow maps. A little hard to implement if you never made any openGL. Hard to get right. Pixellated shadows. Deals with lots of polygons. Doesn't deal with big worlds.
>Myriads of Shadow maps variants. Lots of research these recent years. Current best is Cascaded Shadow Maps: Difficult, still hard to make it look good, but fast, deals with loads of polygons and huge worlds.
Кстати, если я правильно понимаю, в Godot реализована техника Cascaded Shadow Maps - для неё тени рендерятся в несколько разрешений в зависимости от удалённости от камеры:
https://gamedev.stackexchange.com/questions/68016/
Только называется иначе, но суть та же:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#directional-shadow-mapping
>To fix this, a technique named "Parallel Split Shadow Maps" (or PSSM) is used. This splits the view frustum in 2 or 4 areas. Each area gets its own shadow map. This allows small areas close to the viewer to have the same shadow resolution as a huge, far-away area.
>>19069
>>Как можно реализовать автотайлинг
>Так же, через маски
Вопрос был про алгоритм. У меня не получилось использовать такие маски, поэтому просто захардкодил числа)
>аналогом маски 2х2 будет 2х2х2
Думаю, большинству 3D игр будет достаточно двухмерной маски, хотя трёхмерная даст больше возможностей.
>функционал, который будет юзать один анон
GridMap так редко используют? Вот смотри, у них в официальных примерах есть что-то типа мини-гольфа. Предлагается делать карту полностью вручную, но в 2D на TileMap такое можно было бы хотя бы частично автоматизировать автотайлами. Хочешь 3D домик? Тебе придётся вручную выбирать направление стен. Хочешь дорогу? Придётся вручную расставлять кусочки дороги. Хотя это всё можно и нужно автоматизировать. Если GridMap рекомендуют использовать и его реально используют, то почему у него нет такой, очевидно полезной, фичи, как автотайлинг? Скорее всего просто некому этим заниматься, опенсурс такой опенсурс...
Впрочем, не важно, на GDScript это всё (определение блоков) не так много времени занимает. Куда больше волнует то, что заполнение GridMap большим количеством предметов ощутимо фризит игру и сбивает счётчик(и) времени >>17818, вплоть до зависания окна игры. Я, конечно, могу разделить обращения к GridMap по кадрам, но больше хотелось бы многопоточность... хм, а это идея, нужно попробовать использовать потоки, я как-то не задумывался об этом.
>>19072
>посчитать тени - очень дорогостоящая операция
>Результат оптимизаций ты видишь.
Не совсем так, по ссылкам выше пройдись, причина этих артефактов в самой сути шедоу маппинга. Он по определению будет создавать такие артефакты, если не использовать определённые трюки. Разве что увеличение карты теней могло бы в теории помочь (даже в руководстве Godot рекомендуют), но я пробовал её увеличить - у меня оперативка переполнилась (2 ГБ + 8 ГБ + файл подкачки), лол, а артефакты как были, так и остались. Так что единственный реальный путь - вывернуть геометрию и стараться делать все объекты достаточно толстыми (ну, это вроде не проблема).
>RTX
Сомневаюсь, что тени на рейтрейсинге имеют смысл. RTX просто бросает кучу прожорливых ядер на задачу, которая не стоит таких затрат мощности. Если карты теней дают достаточно хороший результат в большинстве сцен, зачем рейтрейсинг? В смысле, в большинстве игр ты не будешь обращать внимание на пиксели или размытие теней, лишь бы не было этой проклятой решётки поверх всего на свете. Особенно смешно выглядит применение рейтрейсинга для ультралоуполи графики с мультяшными текстурами или вообще без них. Из пушки по воробьям...
>учить кресты
Базовый C++ понимаю. Но синтаксис C-подобных языков вызывает у меня отвращение: слишком много лишних спецсимволов там, где можно было бы обойтись обычными английскими буквами или вообще без всего. Поэтому не хочу кодить на нём.
Вот Паскаль, Ада и другие подобные языки - это приятно. GDScript норм, но лучше бы вместо табов добавили слово end как в Lua (лучше а-ля Ada: end func, end if, end for, end while и т.п.) - во-первых, код стал бы куда читабельнее, во-вторых, можно было бы копипастить на форумы, которые не поддерживают табы (сюда), в-третьих, не пришлось бы каждый раз писать pass для подавления "ошибок" в процессе написания очередного блока кода (иногда бесит). Жаль, что 4.0 уже скоро выходит в бету, так что такие изменения в GDScript если и стоит ждать, то только в 5.0. И то очень вряд ли, питонофильское лобби слишком сильно(
12,1 Мб, mp4,960x600, 2:04
Окончательно сломал демо-сцену в главном меню, которую собирал вручную, поэтому создал заново на базе основного генератора. Очень кстати оказалось использование ресурсов вместо нод и независимость генератора от остальных нод, раньше такой трюк я бы сделать не смог (поэтому и делал демо-сцену вручную).
В процессе импровизации добавил крутящуюся камеру и, самое интересное, затемнение экрана, скрывающее генерацию мира - внезапно получилось ощущение полноценной игры, прям ух, как круто выглядит, даже в майнкрафте такого нет (игрок видит прорисовку чанков в самом начале)! Надо только теперь понять, где этот эффект лучше хранить, в общей куче или локально...
Также попробовал сделать шейдер воды, но только после записи видео осознал, что шейдеры не встают на паузу. Придётся вместо TIME использовать uniform, задаваемый извне скриптом, тогда анимация должна останавливаться на паузу. И ещё, если я хочу сделать физику воды а-ля GTA3, мне придётся вычислять форму волны в определённой точке пространства на процессоре, ведь из шейдера эту информацию никак не достать?
Тормоза на видео скорее всего из-за записи OBS. Пробовал новые настройки кодировки, чтобы сразу записывалось компактно. Всё равно пришлось сжимать отдельно...
>>18772
Короче, не важно, я писал тот пост в состоянии фрустрации. В общем, оказалось, что это не источники света кривые, а моя тестовая 3D моделька мешалась своей вывернутой наизнанку поверхностью, которую я сделал по древним рекомендациям, для контура. Ну, не велика беда, мне такие глючные контуры не нравились.
Нужно выставить такие настройки:
shadow_reverse_cull_face = true
shadow_bias = -0.01
Тогда все тени будут работать нормально. Но с такой настройкой нельзя иметь меши с двухсторонней отрисовкой, они будут покрываться тенью/решёткой. Алсо толщина любых объектов должна быть больше shadow_bias (в абсолютном значении), т.е. одиночный полигон будет с одной стороны просвечивать, а слишком тонкая стенка может пропускать свет через углы. Вообще-то я уже ставил точно такие же настройки, но забыл об их предназначении.
>>18786
Не понимаю, о чём ты, там же всё на API вызовах построено, нужно только знать это API и уметь в математику.
Что касается теней, я погуглил, короче, решётка - это из-за пикселизации карт теней, т.е. карте теней не хватает разрешения для того, чтобы правильно спроецироваться на очень круто наклонённую поверхность. Поэтому артефакты возникают только на тех полигонах, которые расположены почти перпендикулярно плоскости экрана. Эта проблема касается любой реализации shadow mapping:
https://learnopengl.com/Advanced-Lighting/Shadows/Shadow-Mapping
https://computergraphics.stackexchange.com/questions/2192/
https://stackoverflow.com/questions/3849052/
Кстати, если я правильно понимаю, в Godot реализована техника Cascaded Shadow Maps - для неё тени рендерятся в несколько разрешений в зависимости от удалённости от камеры:
https://gamedev.stackexchange.com/questions/68016/
Только называется иначе, но суть та же:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#directional-shadow-mapping
>>19069
Вопрос был про алгоритм. У меня не получилось использовать такие маски, поэтому просто захардкодил числа)
Думаю, большинству 3D игр будет достаточно двухмерной маски, хотя трёхмерная даст больше возможностей.
GridMap так редко используют? Вот смотри, у них в официальных примерах есть что-то типа мини-гольфа. Предлагается делать карту полностью вручную, но в 2D на TileMap такое можно было бы хотя бы частично автоматизировать автотайлами. Хочешь 3D домик? Тебе придётся вручную выбирать направление стен. Хочешь дорогу? Придётся вручную расставлять кусочки дороги. Хотя это всё можно и нужно автоматизировать. Если GridMap рекомендуют использовать и его реально используют, то почему у него нет такой, очевидно полезной, фичи, как автотайлинг? Скорее всего просто некому этим заниматься, опенсурс такой опенсурс...
Впрочем, не важно, на GDScript это всё (определение блоков) не так много времени занимает. Куда больше волнует то, что заполнение GridMap большим количеством предметов ощутимо фризит игру и сбивает счётчик(и) времени >>17818, вплоть до зависания окна игры. Я, конечно, могу разделить обращения к GridMap по кадрам, но больше хотелось бы многопоточность... хм, а это идея, нужно попробовать использовать потоки, я как-то не задумывался об этом.
>>19072
Не совсем так, по ссылкам выше пройдись, причина этих артефактов в самой сути шедоу маппинга. Он по определению будет создавать такие артефакты, если не использовать определённые трюки. Разве что увеличение карты теней могло бы в теории помочь (даже в руководстве Godot рекомендуют), но я пробовал её увеличить - у меня оперативка переполнилась (2 ГБ + 8 ГБ + файл подкачки), лол, а артефакты как были, так и остались. Так что единственный реальный путь - вывернуть геометрию и стараться делать все объекты достаточно толстыми (ну, это вроде не проблема).
Сомневаюсь, что тени на рейтрейсинге имеют смысл. RTX просто бросает кучу прожорливых ядер на задачу, которая не стоит таких затрат мощности. Если карты теней дают достаточно хороший результат в большинстве сцен, зачем рейтрейсинг? В смысле, в большинстве игр ты не будешь обращать внимание на пиксели или размытие теней, лишь бы не было этой проклятой решётки поверх всего на свете. Особенно смешно выглядит применение рейтрейсинга для ультралоуполи графики с мультяшными текстурами или вообще без них. Из пушки по воробьям...
Базовый C++ понимаю. Но синтаксис C-подобных языков вызывает у меня отвращение: слишком много лишних спецсимволов там, где можно было бы обойтись обычными английскими буквами или вообще без всего. Поэтому не хочу кодить на нём.
Вот Паскаль, Ада и другие подобные языки - это приятно. GDScript норм, но лучше бы вместо табов добавили слово end как в Lua (лучше а-ля Ada: end func, end if, end for, end while и т.п.) - во-первых, код стал бы куда читабельнее, во-вторых, можно было бы копипастить на форумы, которые не поддерживают табы (сюда), в-третьих, не пришлось бы каждый раз писать pass для подавления "ошибок" в процессе написания очередного блока кода (иногда бесит). Жаль, что 4.0 уже скоро выходит в бету, так что такие изменения в GDScript если и стоит ждать, то только в 5.0. И то очень вряд ли, питонофильское лобби слишком сильно(
В процессе импровизации добавил крутящуюся камеру и, самое интересное, затемнение экрана, скрывающее генерацию мира - внезапно получилось ощущение полноценной игры, прям ух, как круто выглядит, даже в майнкрафте такого нет (игрок видит прорисовку чанков в самом начале)! Надо только теперь понять, где этот эффект лучше хранить, в общей куче или локально...
Также попробовал сделать шейдер воды, но только после записи видео осознал, что шейдеры не встают на паузу. Придётся вместо TIME использовать uniform, задаваемый извне скриптом, тогда анимация должна останавливаться на паузу. И ещё, если я хочу сделать физику воды а-ля GTA3, мне придётся вычислять форму волны в определённой точке пространства на процессоре, ведь из шейдера эту информацию никак не достать?
Тормоза на видео скорее всего из-за записи OBS. Пробовал новые настройки кодировки, чтобы сразу записывалось компактно. Всё равно пришлось сжимать отдельно...
>>18772
>бесит поведение теней от источников света
Короче, не важно, я писал тот пост в состоянии фрустрации. В общем, оказалось, что это не источники света кривые, а моя тестовая 3D моделька мешалась своей вывернутой наизнанку поверхностью, которую я сделал по древним рекомендациям, для контура. Ну, не велика беда, мне такие глючные контуры не нравились.
Нужно выставить такие настройки:
shadow_reverse_cull_face = true
shadow_bias = -0.01
Тогда все тени будут работать нормально. Но с такой настройкой нельзя иметь меши с двухсторонней отрисовкой, они будут покрываться тенью/решёткой. Алсо толщина любых объектов должна быть больше shadow_bias (в абсолютном значении), т.е. одиночный полигон будет с одной стороны просвечивать, а слишком тонкая стенка может пропускать свет через углы. Вообще-то я уже ставил точно такие же настройки, но забыл об их предназначении.
>>18786
>в выводе 3D графония гигантский конвеер
Не понимаю, о чём ты, там же всё на API вызовах построено, нужно только знать это API и уметь в математику.
Что касается теней, я погуглил, короче, решётка - это из-за пикселизации карт теней, т.е. карте теней не хватает разрешения для того, чтобы правильно спроецироваться на очень круто наклонённую поверхность. Поэтому артефакты возникают только на тех полигонах, которые расположены почти перпендикулярно плоскости экрана. Эта проблема касается любой реализации shadow mapping:
https://learnopengl.com/Advanced-Lighting/Shadows/Shadow-Mapping
https://computergraphics.stackexchange.com/questions/2192/
https://stackoverflow.com/questions/3849052/
>Shadow maps. A little hard to implement if you never made any openGL. Hard to get right. Pixellated shadows. Deals with lots of polygons. Doesn't deal with big worlds.
>Myriads of Shadow maps variants. Lots of research these recent years. Current best is Cascaded Shadow Maps: Difficult, still hard to make it look good, but fast, deals with loads of polygons and huge worlds.
Кстати, если я правильно понимаю, в Godot реализована техника Cascaded Shadow Maps - для неё тени рендерятся в несколько разрешений в зависимости от удалённости от камеры:
https://gamedev.stackexchange.com/questions/68016/
Только называется иначе, но суть та же:
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html#directional-shadow-mapping
>To fix this, a technique named "Parallel Split Shadow Maps" (or PSSM) is used. This splits the view frustum in 2 or 4 areas. Each area gets its own shadow map. This allows small areas close to the viewer to have the same shadow resolution as a huge, far-away area.
>>19069
>>Как можно реализовать автотайлинг
>Так же, через маски
Вопрос был про алгоритм. У меня не получилось использовать такие маски, поэтому просто захардкодил числа)
>аналогом маски 2х2 будет 2х2х2
Думаю, большинству 3D игр будет достаточно двухмерной маски, хотя трёхмерная даст больше возможностей.
>функционал, который будет юзать один анон
GridMap так редко используют? Вот смотри, у них в официальных примерах есть что-то типа мини-гольфа. Предлагается делать карту полностью вручную, но в 2D на TileMap такое можно было бы хотя бы частично автоматизировать автотайлами. Хочешь 3D домик? Тебе придётся вручную выбирать направление стен. Хочешь дорогу? Придётся вручную расставлять кусочки дороги. Хотя это всё можно и нужно автоматизировать. Если GridMap рекомендуют использовать и его реально используют, то почему у него нет такой, очевидно полезной, фичи, как автотайлинг? Скорее всего просто некому этим заниматься, опенсурс такой опенсурс...
Впрочем, не важно, на GDScript это всё (определение блоков) не так много времени занимает. Куда больше волнует то, что заполнение GridMap большим количеством предметов ощутимо фризит игру и сбивает счётчик(и) времени >>17818, вплоть до зависания окна игры. Я, конечно, могу разделить обращения к GridMap по кадрам, но больше хотелось бы многопоточность... хм, а это идея, нужно попробовать использовать потоки, я как-то не задумывался об этом.
>>19072
>посчитать тени - очень дорогостоящая операция
>Результат оптимизаций ты видишь.
Не совсем так, по ссылкам выше пройдись, причина этих артефактов в самой сути шедоу маппинга. Он по определению будет создавать такие артефакты, если не использовать определённые трюки. Разве что увеличение карты теней могло бы в теории помочь (даже в руководстве Godot рекомендуют), но я пробовал её увеличить - у меня оперативка переполнилась (2 ГБ + 8 ГБ + файл подкачки), лол, а артефакты как были, так и остались. Так что единственный реальный путь - вывернуть геометрию и стараться делать все объекты достаточно толстыми (ну, это вроде не проблема).
>RTX
Сомневаюсь, что тени на рейтрейсинге имеют смысл. RTX просто бросает кучу прожорливых ядер на задачу, которая не стоит таких затрат мощности. Если карты теней дают достаточно хороший результат в большинстве сцен, зачем рейтрейсинг? В смысле, в большинстве игр ты не будешь обращать внимание на пиксели или размытие теней, лишь бы не было этой проклятой решётки поверх всего на свете. Особенно смешно выглядит применение рейтрейсинга для ультралоуполи графики с мультяшными текстурами или вообще без них. Из пушки по воробьям...
>учить кресты
Базовый C++ понимаю. Но синтаксис C-подобных языков вызывает у меня отвращение: слишком много лишних спецсимволов там, где можно было бы обойтись обычными английскими буквами или вообще без всего. Поэтому не хочу кодить на нём.
Вот Паскаль, Ада и другие подобные языки - это приятно. GDScript норм, но лучше бы вместо табов добавили слово end как в Lua (лучше а-ля Ada: end func, end if, end for, end while и т.п.) - во-первых, код стал бы куда читабельнее, во-вторых, можно было бы копипастить на форумы, которые не поддерживают табы (сюда), в-третьих, не пришлось бы каждый раз писать pass для подавления "ошибок" в процессе написания очередного блока кода (иногда бесит). Жаль, что 4.0 уже скоро выходит в бету, так что такие изменения в GDScript если и стоит ждать, то только в 5.0. И то очень вряд ли, питонофильское лобби слишком сильно(
>>19133
Поразмыслю над алгоритмом на досуге.
Насколько я сделал вывод, да, редко. Гораздо чаще 3д-объекты расставляют по сетке, по кривым (сплайнам штоле или как там), при помощи специальных алгоритмов. Потому что в большинстве случаев объекты в процессе игры нужно будет двигать, да, статики, да, двигать. Поэтому гридмап видится тут как бесполезный костыль.
> Вопрос был про алгоритм.
Поразмыслю над алгоритмом на досуге.
> GridMap так редко используют?
Насколько я сделал вывод, да, редко. Гораздо чаще 3д-объекты расставляют по сетке, по кривым (сплайнам штоле или как там), при помощи специальных алгоритмов. Потому что в большинстве случаев объекты в процессе игры нужно будет двигать, да, статики, да, двигать. Поэтому гридмап видится тут как бесполезный костыль.
>>19133
https://www.youtube.com/watch?v=Yvy8vQ-5O_w
> Хочешь дорогу? Придётся вручную расставлять кусочки дороги.
https://www.youtube.com/watch?v=Yvy8vQ-5O_w
5 Кб, 338x159Пользуется кто моно версией? Что за хрень с _Input?
2 минуты подвигал мышкой и результат на пике. Мне стоит беспокоиться или всё в норме?
2 минуты подвигал мышкой и результат на пике. Мне стоит беспокоиться или всё в норме?
>>19258
Нет.
Нет.
1,5 Мб, mp4,960x600, 0:32
>>19133
Решил всё же убрать в автозагрузку, сделав глобальный менеджер эффектов. Также добавил надпись, которая появляется на полностью чёрном экране и имитирует работу "бесконечного прогрессбара". Шрифт потом скорее всего поменяю (Impact можно использовать для картинок-надписей в играх, но тут мне пришлось разделить надпись на буквы с помощью AtlasTexture, чего условия лицензии Майкрософт вроде бы не разрешают).
>>19182
Ты не так понял, я имел в виду дорогу в GridMap. Вот есть 3 кусочка дороги, из них можно создать множество комбинаций, образующих разные сегменты дороги. Я написал код для процедурной сборки таких дорог, достаточно отметить точки маршрута. Но если использовать только GridMap, придётся делать это всё вручную, что долго и скучно. Вот в TileMap можно настроить эти кусочки так, чтобы дорога формировалась автоматически, а в GridMap - только если свой собственный код писать (или искать аддон).
Впрочем, ладно, я тут подумал - наверное, автотайлинг в 3D из коробки не нужен, потому что слишком много вариантов может быть, и все их учитывать = раздувать ядро движка, а если не учитывать хотя бы часть = вынуждать пилить велосипед. Ну и да, число активных пользователей сомнительно.
>>19179
Да не стоит, если тебе это не нужно. Свою проблему я уже позавчера решил, а так можно было бы код из интернета взять и адаптировать для GridMap. Там главная проблема в том, чтобы найти соответствие между соседями и номером тайла из набора, для этого нужен большой Dictionary со всеми комбинациями. Точнее, проблема составить этот словарь. Короче, не важно уже, я разобрался по сути (нужно только переписать мою реализацию универсально).
Вот тут есть пример реализации: https://youtu.be/bwcEh2HffoY
https://github.com/Calame321/Godot_Auto_GridMap
Но мне, если честно, лень разбираться.
По какой сетке? GridMap и есть сетка, с точки зрения пользователя. Внутри не массив массивов массивов, а что-то оптимальное, чтобы не тратить память на пустые ячейки, но снаружи интерфейс как у массива - удобно, если нужно разместить что-то по сетке.
Что ты имеешь в виду? В большинстве игр статичная геометрия никак не двигается. Вот вообще никак. Исключение - огромные миры длиной больше 8 километров, но GridMap можно двигать целиком, и это выгоднее, чем двигать каждый объект по отдельности.
Если же ты хочешь "двигать" (переставлять с места на место) объекты как мебель в домах Симс - то для этого достаточно удалять и снова устанавливать итем в GridMap, а в руки персонажу давать отдельный объект (если подразумевается возможность перемещать мебель в руках, но размещая её на пол строго по сетке).
Если ты хочешь разрушаемость, то для этого можно удалять итем из гридмапы и спавнить на его месте ригидбоди с той же моделью или моделью обломков. Чтобы понять, что пора "разрушить" объект, я думаю, нужно проверять координаты точки столкновения, потому что узнать конкретный коллайдер от столкновения с GridMap почему-то нельзя (во всяком случае невозможно определить коллайдер простым рейкастом - возвращается только ссылка на GridMap).
Почему же? Гридмап упрощает тебе оптимизации. Внутри прямое обращение к графическому и физическому серверам, при этом и меши, и коллизии группируются по октантам. Если ты не будешь использовать GridMap, тебе придётся использовать MultiMeshInstance или вручную соединять несколько мешей в один комбинированный меш. А если у тебя слишком много нод, тебе придётся создавать собственную систему с обращениями к серверам напрямую.
Вот я применил гридмапы и всё стало легче. Даже деревья размещаю на гридмапе, и траву тоже пробовал, но для травы это, конечно, не лучший способ (слишком скучно выглядит). Число дроуколлов сократилось и даже физика не тормозит, хотя я поленился и генерирую тримеши даже там, где они не нужны. Щас дореализую заново чанковую систему с LODами и вообще круто будет.
Ну, вообще, я мог бы и без гридмапов всё это сделать. И, возможно, потом переделаю, чтобы работало без них. Но для быстрого прототипа самое то, не нужно возиться в низкоуровневых АПИ и с математикой локальных/глобальных трансформаций.
>где этот эффект лучше хранить
Решил всё же убрать в автозагрузку, сделав глобальный менеджер эффектов. Также добавил надпись, которая появляется на полностью чёрном экране и имитирует работу "бесконечного прогрессбара". Шрифт потом скорее всего поменяю (Impact можно использовать для картинок-надписей в играх, но тут мне пришлось разделить надпись на буквы с помощью AtlasTexture, чего условия лицензии Майкрософт вроде бы не разрешают).
>>19182
>дорогу
Ты не так понял, я имел в виду дорогу в GridMap. Вот есть 3 кусочка дороги, из них можно создать множество комбинаций, образующих разные сегменты дороги. Я написал код для процедурной сборки таких дорог, достаточно отметить точки маршрута. Но если использовать только GridMap, придётся делать это всё вручную, что долго и скучно. Вот в TileMap можно настроить эти кусочки так, чтобы дорога формировалась автоматически, а в GridMap - только если свой собственный код писать (или искать аддон).
Впрочем, ладно, я тут подумал - наверное, автотайлинг в 3D из коробки не нужен, потому что слишком много вариантов может быть, и все их учитывать = раздувать ядро движка, а если не учитывать хотя бы часть = вынуждать пилить велосипед. Ну и да, число активных пользователей сомнительно.
>>19179
>Поразмыслю над алгоритмом
Да не стоит, если тебе это не нужно. Свою проблему я уже позавчера решил, а так можно было бы код из интернета взять и адаптировать для GridMap. Там главная проблема в том, чтобы найти соответствие между соседями и номером тайла из набора, для этого нужен большой Dictionary со всеми комбинациями. Точнее, проблема составить этот словарь. Короче, не важно уже, я разобрался по сути (нужно только переписать мою реализацию универсально).
Вот тут есть пример реализации: https://youtu.be/bwcEh2HffoY
https://github.com/Calame321/Godot_Auto_GridMap
Но мне, если честно, лень разбираться.
>Гораздо чаще 3д-объекты расставляют по сетке,
По какой сетке? GridMap и есть сетка, с точки зрения пользователя. Внутри не массив массивов массивов, а что-то оптимальное, чтобы не тратить память на пустые ячейки, но снаружи интерфейс как у массива - удобно, если нужно разместить что-то по сетке.
>Потому что в большинстве случаев объекты в процессе игры нужно будет двигать, да, статики, да, двигать.
Что ты имеешь в виду? В большинстве игр статичная геометрия никак не двигается. Вот вообще никак. Исключение - огромные миры длиной больше 8 километров, но GridMap можно двигать целиком, и это выгоднее, чем двигать каждый объект по отдельности.
Если же ты хочешь "двигать" (переставлять с места на место) объекты как мебель в домах Симс - то для этого достаточно удалять и снова устанавливать итем в GridMap, а в руки персонажу давать отдельный объект (если подразумевается возможность перемещать мебель в руках, но размещая её на пол строго по сетке).
Если ты хочешь разрушаемость, то для этого можно удалять итем из гридмапы и спавнить на его месте ригидбоди с той же моделью или моделью обломков. Чтобы понять, что пора "разрушить" объект, я думаю, нужно проверять координаты точки столкновения, потому что узнать конкретный коллайдер от столкновения с GridMap почему-то нельзя (во всяком случае невозможно определить коллайдер простым рейкастом - возвращается только ссылка на GridMap).
>Поэтому гридмап видится тут как бесполезный костыль.
Почему же? Гридмап упрощает тебе оптимизации. Внутри прямое обращение к графическому и физическому серверам, при этом и меши, и коллизии группируются по октантам. Если ты не будешь использовать GridMap, тебе придётся использовать MultiMeshInstance или вручную соединять несколько мешей в один комбинированный меш. А если у тебя слишком много нод, тебе придётся создавать собственную систему с обращениями к серверам напрямую.
Вот я применил гридмапы и всё стало легче. Даже деревья размещаю на гридмапе, и траву тоже пробовал, но для травы это, конечно, не лучший способ (слишком скучно выглядит). Число дроуколлов сократилось и даже физика не тормозит, хотя я поленился и генерирую тримеши даже там, где они не нужны. Щас дореализую заново чанковую систему с LODами и вообще круто будет.
Ну, вообще, я мог бы и без гридмапов всё это сделать. И, возможно, потом переделаю, чтобы работало без них. Но для быстрого прототипа самое то, не нужно возиться в низкоуровневых АПИ и с математикой локальных/глобальных трансформаций.
1,5 Мб, mp4,960x600, 0:32
>>19133
Решил всё же убрать в автозагрузку, сделав глобальный менеджер эффектов. Также добавил надпись, которая появляется на полностью чёрном экране и имитирует работу "бесконечного прогрессбара". Шрифт потом скорее всего поменяю (Impact можно использовать для картинок-надписей в играх, но тут мне пришлось разделить надпись на буквы с помощью AtlasTexture, чего условия лицензии Майкрософт вроде бы не разрешают).
>>19182
Ты не так понял, я имел в виду дорогу в GridMap. Вот есть 3 кусочка дороги, из них можно создать множество комбинаций, образующих разные сегменты дороги. Я написал код для процедурной сборки таких дорог, достаточно отметить точки маршрута. Но если использовать только GridMap, придётся делать это всё вручную, что долго и скучно. Вот в TileMap можно настроить эти кусочки так, чтобы дорога формировалась автоматически, а в GridMap - только если свой собственный код писать (или искать аддон).
Впрочем, ладно, я тут подумал - наверное, автотайлинг в 3D из коробки не нужен, потому что слишком много вариантов может быть, и все их учитывать = раздувать ядро движка, а если не учитывать хотя бы часть = вынуждать пилить велосипед. Ну и да, число активных пользователей сомнительно.
>>19179
Да не стоит, если тебе это не нужно. Свою проблему я уже позавчера решил, а так можно было бы код из интернета взять и адаптировать для GridMap. Там главная проблема в том, чтобы найти соответствие между соседями и номером тайла из набора, для этого нужен большой Dictionary со всеми комбинациями. Точнее, проблема составить этот словарь. Короче, не важно уже, я разобрался по сути (нужно только переписать мою реализацию универсально).
Вот тут есть пример реализации: https://youtu.be/bwcEh2HffoY
https://github.com/Calame321/Godot_Auto_GridMap
Но мне, если честно, лень разбираться.
По какой сетке? GridMap и есть сетка, с точки зрения пользователя. Внутри не массив массивов массивов, а что-то оптимальное, чтобы не тратить память на пустые ячейки, но снаружи интерфейс как у массива - удобно, если нужно разместить что-то по сетке.
Что ты имеешь в виду? В большинстве игр статичная геометрия никак не двигается. Вот вообще никак. Исключение - огромные миры длиной больше 8 километров, но GridMap можно двигать целиком, и это выгоднее, чем двигать каждый объект по отдельности.
Если же ты хочешь "двигать" (переставлять с места на место) объекты как мебель в домах Симс - то для этого достаточно удалять и снова устанавливать итем в GridMap, а в руки персонажу давать отдельный объект (если подразумевается возможность перемещать мебель в руках, но размещая её на пол строго по сетке).
Если ты хочешь разрушаемость, то для этого можно удалять итем из гридмапы и спавнить на его месте ригидбоди с той же моделью или моделью обломков. Чтобы понять, что пора "разрушить" объект, я думаю, нужно проверять координаты точки столкновения, потому что узнать конкретный коллайдер от столкновения с GridMap почему-то нельзя (во всяком случае невозможно определить коллайдер простым рейкастом - возвращается только ссылка на GridMap).
Почему же? Гридмап упрощает тебе оптимизации. Внутри прямое обращение к графическому и физическому серверам, при этом и меши, и коллизии группируются по октантам. Если ты не будешь использовать GridMap, тебе придётся использовать MultiMeshInstance или вручную соединять несколько мешей в один комбинированный меш. А если у тебя слишком много нод, тебе придётся создавать собственную систему с обращениями к серверам напрямую.
Вот я применил гридмапы и всё стало легче. Даже деревья размещаю на гридмапе, и траву тоже пробовал, но для травы это, конечно, не лучший способ (слишком скучно выглядит). Число дроуколлов сократилось и даже физика не тормозит, хотя я поленился и генерирую тримеши даже там, где они не нужны. Щас дореализую заново чанковую систему с LODами и вообще круто будет.
Ну, вообще, я мог бы и без гридмапов всё это сделать. И, возможно, потом переделаю, чтобы работало без них. Но для быстрого прототипа самое то, не нужно возиться в низкоуровневых АПИ и с математикой локальных/глобальных трансформаций.
>где этот эффект лучше хранить
Решил всё же убрать в автозагрузку, сделав глобальный менеджер эффектов. Также добавил надпись, которая появляется на полностью чёрном экране и имитирует работу "бесконечного прогрессбара". Шрифт потом скорее всего поменяю (Impact можно использовать для картинок-надписей в играх, но тут мне пришлось разделить надпись на буквы с помощью AtlasTexture, чего условия лицензии Майкрософт вроде бы не разрешают).
>>19182
>дорогу
Ты не так понял, я имел в виду дорогу в GridMap. Вот есть 3 кусочка дороги, из них можно создать множество комбинаций, образующих разные сегменты дороги. Я написал код для процедурной сборки таких дорог, достаточно отметить точки маршрута. Но если использовать только GridMap, придётся делать это всё вручную, что долго и скучно. Вот в TileMap можно настроить эти кусочки так, чтобы дорога формировалась автоматически, а в GridMap - только если свой собственный код писать (или искать аддон).
Впрочем, ладно, я тут подумал - наверное, автотайлинг в 3D из коробки не нужен, потому что слишком много вариантов может быть, и все их учитывать = раздувать ядро движка, а если не учитывать хотя бы часть = вынуждать пилить велосипед. Ну и да, число активных пользователей сомнительно.
>>19179
>Поразмыслю над алгоритмом
Да не стоит, если тебе это не нужно. Свою проблему я уже позавчера решил, а так можно было бы код из интернета взять и адаптировать для GridMap. Там главная проблема в том, чтобы найти соответствие между соседями и номером тайла из набора, для этого нужен большой Dictionary со всеми комбинациями. Точнее, проблема составить этот словарь. Короче, не важно уже, я разобрался по сути (нужно только переписать мою реализацию универсально).
Вот тут есть пример реализации: https://youtu.be/bwcEh2HffoY
https://github.com/Calame321/Godot_Auto_GridMap
Но мне, если честно, лень разбираться.
>Гораздо чаще 3д-объекты расставляют по сетке,
По какой сетке? GridMap и есть сетка, с точки зрения пользователя. Внутри не массив массивов массивов, а что-то оптимальное, чтобы не тратить память на пустые ячейки, но снаружи интерфейс как у массива - удобно, если нужно разместить что-то по сетке.
>Потому что в большинстве случаев объекты в процессе игры нужно будет двигать, да, статики, да, двигать.
Что ты имеешь в виду? В большинстве игр статичная геометрия никак не двигается. Вот вообще никак. Исключение - огромные миры длиной больше 8 километров, но GridMap можно двигать целиком, и это выгоднее, чем двигать каждый объект по отдельности.
Если же ты хочешь "двигать" (переставлять с места на место) объекты как мебель в домах Симс - то для этого достаточно удалять и снова устанавливать итем в GridMap, а в руки персонажу давать отдельный объект (если подразумевается возможность перемещать мебель в руках, но размещая её на пол строго по сетке).
Если ты хочешь разрушаемость, то для этого можно удалять итем из гридмапы и спавнить на его месте ригидбоди с той же моделью или моделью обломков. Чтобы понять, что пора "разрушить" объект, я думаю, нужно проверять координаты точки столкновения, потому что узнать конкретный коллайдер от столкновения с GridMap почему-то нельзя (во всяком случае невозможно определить коллайдер простым рейкастом - возвращается только ссылка на GridMap).
>Поэтому гридмап видится тут как бесполезный костыль.
Почему же? Гридмап упрощает тебе оптимизации. Внутри прямое обращение к графическому и физическому серверам, при этом и меши, и коллизии группируются по октантам. Если ты не будешь использовать GridMap, тебе придётся использовать MultiMeshInstance или вручную соединять несколько мешей в один комбинированный меш. А если у тебя слишком много нод, тебе придётся создавать собственную систему с обращениями к серверам напрямую.
Вот я применил гридмапы и всё стало легче. Даже деревья размещаю на гридмапе, и траву тоже пробовал, но для травы это, конечно, не лучший способ (слишком скучно выглядит). Число дроуколлов сократилось и даже физика не тормозит, хотя я поленился и генерирую тримеши даже там, где они не нужны. Щас дореализую заново чанковую систему с LODами и вообще круто будет.
Ну, вообще, я мог бы и без гридмапов всё это сделать. И, возможно, потом переделаю, чтобы работало без них. Но для быстрого прототипа самое то, не нужно возиться в низкоуровневых АПИ и с математикой локальных/глобальных трансформаций.
>>17888
Ты хочешь воксельный мир как в майнкрафте?
В Spore цельный меш только в качестве "кожи" вокруг "костей". Думаю, это не так уж сложно сделать - есть похожий инструмент в Blender, значит, алгоритм известный. А вот все остальные части тела, т.е. внешние органы, в Spore имеют строго определённую форму и никак с сеткой "кожи" не взаимодействуют, это легко заметить по сломанному в местах соединений шейдингу. В общем, можно реализовать стандартными средствами Godot.
В том же RimWorld большинство параметров можно прочитать только в специальном окошке меню, они не влияют на графику. А в ASCII играх вообще всё очень сильно ограничено в этом плане. Относись к 3D реализации так же, как к 2D: это просто способ отобразить часть информации - взаимное расположение объектов, а не попытка создать фотореализм уровня ААА проектов.
Я к тому, что если у тебя активно используются все 3 оси игрового пространства, т.е. если объекты достаточно часто находятся выше или ниже других объектов (при виде строго сверху), тогда вместо костылей для 2D будет разумнее сделать всё в 3D, с нормальной камерой (не прибитой к потолку). Это не имеет отношения к качеству графики, повторюсь, можешь хоть ASCII символы на кубах писать, даже в таком виде будет лучше, чем 2D проекция строго сверху. Менюшки с подробной информацией об объектах никуда не денутся, просто посмотри на любую 3D ММОРПГ, лол.
А у тебя эта библиотека уже готова или ты только фантазировал о том, как будешь её использовать? Если готова, можно подключить к Godot через GDNative/GDExtension. Если нет... не хочу разочаровывать, но на практике всё обычно сложнее, чем в мыслях/планах.
И ты называешь это низкодетализированным? Да такого уровня даже вручную в Blender будет сложно добиться, а полностью процедурно генерировать - слишком сложно. Другое дело, если собирать меш из заранее заготовленных фрагментов с уже готовыми текстурами, но тут будут сложности с подгонкой одного под другое. В любом случае, очень много работы непонятно зачем.
Что это? Не гуглится нормально.
Ну да, в чём проблема сделать ультралоуполи модельки? А если ты такой мастер рисовать 2D, то текстуры легко нарисуешь. В лоупольном 3D текстуры всё решают.
>>17889
Ты понимаешь, что это всё художники рисуют? Да, с помощью каких-то особых инструментов, но это вручную делается. С тем же успехом ты бы мог делать всё это в Blender. Процедурно такую графику генерировать не получится, придётся вручную закладывать в генератор знания о том, как выглядят люди, животные и т.п. Тогда уж лучше попытаться обучить нейронку, чем заниматься этим вручную. Процедурная генерация - не магия, она делает только то, что ты ей скажешь, и говорить придётся очень много.
>хотел пользовать вот эту библиотеку
Ты хочешь воксельный мир как в майнкрафте?
>Не совсем как в споре, там существа в одну сетку превращались, а у меня они сегментами получается должны быть.
В Spore цельный меш только в качестве "кожи" вокруг "костей". Думаю, это не так уж сложно сделать - есть похожий инструмент в Blender, значит, алгоритм известный. А вот все остальные части тела, т.е. внешние органы, в Spore имеют строго определённую форму и никак с сеткой "кожи" не взаимодействуют, это легко заметить по сломанному в местах соединений шейдингу. В общем, можно реализовать стандартными средствами Godot.
>повышать комплексность этих всех визуализационных систем, просто ради того чтобы они хоть как-то передавали непосредственный стейт мира, а не просто были кубиком на котором написано
В том же RimWorld большинство параметров можно прочитать только в специальном окошке меню, они не влияют на графику. А в ASCII играх вообще всё очень сильно ограничено в этом плане. Относись к 3D реализации так же, как к 2D: это просто способ отобразить часть информации - взаимное расположение объектов, а не попытка создать фотореализм уровня ААА проектов.
Я к тому, что если у тебя активно используются все 3 оси игрового пространства, т.е. если объекты достаточно часто находятся выше или ниже других объектов (при виде строго сверху), тогда вместо костылей для 2D будет разумнее сделать всё в 3D, с нормальной камерой (не прибитой к потолку). Это не имеет отношения к качеству графики, повторюсь, можешь хоть ASCII символы на кубах писать, даже в таком виде будет лучше, чем 2D проекция строго сверху. Менюшки с подробной информацией об объектах никуда не денутся, просто посмотри на любую 3D ММОРПГ, лол.
>через свою собственную либу сделать
А у тебя эта библиотека уже готова или ты только фантазировал о том, как будешь её использовать? Если готова, можно подключить к Godot через GDNative/GDExtension. Если нет... не хочу разочаровывать, но на практике всё обычно сложнее, чем в мыслях/планах.
>процесс создания новых персонажей, особенно низкодетализированных (как на пике)
И ты называешь это низкодетализированным? Да такого уровня даже вручную в Blender будет сложно добиться, а полностью процедурно генерировать - слишком сложно. Другое дело, если собирать меш из заранее заготовленных фрагментов с уже готовыми текстурами, но тут будут сложности с подгонкой одного под другое. В любом случае, очень много работы непонятно зачем.
>SDF
>СДФ
Что это? Не гуглится нормально.
>для каждого предмета 2д и 3д вид?
Ну да, в чём проблема сделать ультралоуполи модельки? А если ты такой мастер рисовать 2D, то текстуры легко нарисуешь. В лоупольном 3D текстуры всё решают.
>>17889
>Вот похожие либы на юнити
Ты понимаешь, что это всё художники рисуют? Да, с помощью каких-то особых инструментов, но это вручную делается. С тем же успехом ты бы мог делать всё это в Blender. Процедурно такую графику генерировать не получится, придётся вручную закладывать в генератор знания о том, как выглядят люди, животные и т.п. Тогда уж лучше попытаться обучить нейронку, чем заниматься этим вручную. Процедурная генерация - не магия, она делает только то, что ты ей скажешь, и говорить придётся очень много.
>>17888
Ты хочешь воксельный мир как в майнкрафте?
В Spore цельный меш только в качестве "кожи" вокруг "костей". Думаю, это не так уж сложно сделать - есть похожий инструмент в Blender, значит, алгоритм известный. А вот все остальные части тела, т.е. внешние органы, в Spore имеют строго определённую форму и никак с сеткой "кожи" не взаимодействуют, это легко заметить по сломанному в местах соединений шейдингу. В общем, можно реализовать стандартными средствами Godot.
В том же RimWorld большинство параметров можно прочитать только в специальном окошке меню, они не влияют на графику. А в ASCII играх вообще всё очень сильно ограничено в этом плане. Относись к 3D реализации так же, как к 2D: это просто способ отобразить часть информации - взаимное расположение объектов, а не попытка создать фотореализм уровня ААА проектов.
Я к тому, что если у тебя активно используются все 3 оси игрового пространства, т.е. если объекты достаточно часто находятся выше или ниже других объектов (при виде строго сверху), тогда вместо костылей для 2D будет разумнее сделать всё в 3D, с нормальной камерой (не прибитой к потолку). Это не имеет отношения к качеству графики, повторюсь, можешь хоть ASCII символы на кубах писать, даже в таком виде будет лучше, чем 2D проекция строго сверху. Менюшки с подробной информацией об объектах никуда не денутся, просто посмотри на любую 3D ММОРПГ, лол.
А у тебя эта библиотека уже готова или ты только фантазировал о том, как будешь её использовать? Если готова, можно подключить к Godot через GDNative/GDExtension. Если нет... не хочу разочаровывать, но на практике всё обычно сложнее, чем в мыслях/планах.
И ты называешь это низкодетализированным? Да такого уровня даже вручную в Blender будет сложно добиться, а полностью процедурно генерировать - слишком сложно. Другое дело, если собирать меш из заранее заготовленных фрагментов с уже готовыми текстурами, но тут будут сложности с подгонкой одного под другое. В любом случае, очень много работы непонятно зачем.
Что это? Не гуглится нормально.
Ну да, в чём проблема сделать ультралоуполи модельки? А если ты такой мастер рисовать 2D, то текстуры легко нарисуешь. В лоупольном 3D текстуры всё решают.
>>17889
Ты понимаешь, что это всё художники рисуют? Да, с помощью каких-то особых инструментов, но это вручную делается. С тем же успехом ты бы мог делать всё это в Blender. Процедурно такую графику генерировать не получится, придётся вручную закладывать в генератор знания о том, как выглядят люди, животные и т.п. Тогда уж лучше попытаться обучить нейронку, чем заниматься этим вручную. Процедурная генерация - не магия, она делает только то, что ты ей скажешь, и говорить придётся очень много.
>хотел пользовать вот эту библиотеку
Ты хочешь воксельный мир как в майнкрафте?
>Не совсем как в споре, там существа в одну сетку превращались, а у меня они сегментами получается должны быть.
В Spore цельный меш только в качестве "кожи" вокруг "костей". Думаю, это не так уж сложно сделать - есть похожий инструмент в Blender, значит, алгоритм известный. А вот все остальные части тела, т.е. внешние органы, в Spore имеют строго определённую форму и никак с сеткой "кожи" не взаимодействуют, это легко заметить по сломанному в местах соединений шейдингу. В общем, можно реализовать стандартными средствами Godot.
>повышать комплексность этих всех визуализационных систем, просто ради того чтобы они хоть как-то передавали непосредственный стейт мира, а не просто были кубиком на котором написано
В том же RimWorld большинство параметров можно прочитать только в специальном окошке меню, они не влияют на графику. А в ASCII играх вообще всё очень сильно ограничено в этом плане. Относись к 3D реализации так же, как к 2D: это просто способ отобразить часть информации - взаимное расположение объектов, а не попытка создать фотореализм уровня ААА проектов.
Я к тому, что если у тебя активно используются все 3 оси игрового пространства, т.е. если объекты достаточно часто находятся выше или ниже других объектов (при виде строго сверху), тогда вместо костылей для 2D будет разумнее сделать всё в 3D, с нормальной камерой (не прибитой к потолку). Это не имеет отношения к качеству графики, повторюсь, можешь хоть ASCII символы на кубах писать, даже в таком виде будет лучше, чем 2D проекция строго сверху. Менюшки с подробной информацией об объектах никуда не денутся, просто посмотри на любую 3D ММОРПГ, лол.
>через свою собственную либу сделать
А у тебя эта библиотека уже готова или ты только фантазировал о том, как будешь её использовать? Если готова, можно подключить к Godot через GDNative/GDExtension. Если нет... не хочу разочаровывать, но на практике всё обычно сложнее, чем в мыслях/планах.
>процесс создания новых персонажей, особенно низкодетализированных (как на пике)
И ты называешь это низкодетализированным? Да такого уровня даже вручную в Blender будет сложно добиться, а полностью процедурно генерировать - слишком сложно. Другое дело, если собирать меш из заранее заготовленных фрагментов с уже готовыми текстурами, но тут будут сложности с подгонкой одного под другое. В любом случае, очень много работы непонятно зачем.
>SDF
>СДФ
Что это? Не гуглится нормально.
>для каждого предмета 2д и 3д вид?
Ну да, в чём проблема сделать ультралоуполи модельки? А если ты такой мастер рисовать 2D, то текстуры легко нарисуешь. В лоупольном 3D текстуры всё решают.
>>17889
>Вот похожие либы на юнити
Ты понимаешь, что это всё художники рисуют? Да, с помощью каких-то особых инструментов, но это вручную делается. С тем же успехом ты бы мог делать всё это в Blender. Процедурно такую графику генерировать не получится, придётся вручную закладывать в генератор знания о том, как выглядят люди, животные и т.п. Тогда уж лучше попытаться обучить нейронку, чем заниматься этим вручную. Процедурная генерация - не магия, она делает только то, что ты ей скажешь, и говорить придётся очень много.
>>19390
Хорошо у тебя риторика прокачана. Убедительно говоришь. Ладно, даю добро на гридмап. А движение статиков, это на самом деле (я уже позже понял свою ошибку) это на самом деле отключение статиков и создание на их месте динамиков, и применяется оно в разрушаемом окружении. И через гридмап все хлопоты по отключению статика в том месте, куда прилетело, чтобы сгенерировать там взрыв и обломки, это лишь задание нулевого номера меш-тайла.
Хорошо у тебя риторика прокачана. Убедительно говоришь. Ладно, даю добро на гридмап. А движение статиков, это на самом деле (я уже позже понял свою ошибку) это на самом деле отключение статиков и создание на их месте динамиков, и применяется оно в разрушаемом окружении. И через гридмап все хлопоты по отключению статика в том месте, куда прилетело, чтобы сгенерировать там взрыв и обломки, это лишь задание нулевого номера меш-тайла.
>>19133
Оно и видно, всё какие-то маняфантазии о создании в соло того что делают тысячи куда более квалифицированных специалистов.
>Не понимаю, о чём ты
Оно и видно, всё какие-то маняфантазии о создании в соло того что делают тысячи куда более квалифицированных специалистов.
>>19390
И вот еще контрпример, есть такая игра CONTROL, там действие происходит в эдаком финском гигахруще, который себя самосбором трансформирует, и ваще он разумный и самоосознающий, в лучших традициях крипоты. Так вот, там, когда совершаешь ряд действий, там стены комнат и камер начинают вращаться, двигаться и перестраиваться. И там при этом видна кубическая структура, но при этом это не статичный гридмап, который содержит только индекс меша, он у них (если у них подобный алгоритм, ОфК) содержит ещё и трансформ ячейки с мешем. В нашем же гридмапе полноценного трансформа нет, есть только статичные прямые углы поворота меша-тайла. Поэтому на данном этапе, гридмап хорош лишь для прототипирования и для простых игор. Что-то более сложное (уровня КОНТРОЛЯ) упрётся в отсутствие функционала.
Но для прототипирования опять же есть CSG.
И есть выравнивание в редакторе, по сетке, по направляющим и т.д.
И вот еще контрпример, есть такая игра CONTROL, там действие происходит в эдаком финском гигахруще, который себя самосбором трансформирует, и ваще он разумный и самоосознающий, в лучших традициях крипоты. Так вот, там, когда совершаешь ряд действий, там стены комнат и камер начинают вращаться, двигаться и перестраиваться. И там при этом видна кубическая структура, но при этом это не статичный гридмап, который содержит только индекс меша, он у них (если у них подобный алгоритм, ОфК) содержит ещё и трансформ ячейки с мешем. В нашем же гридмапе полноценного трансформа нет, есть только статичные прямые углы поворота меша-тайла. Поэтому на данном этапе, гридмап хорош лишь для прототипирования и для простых игор. Что-то более сложное (уровня КОНТРОЛЯ) упрётся в отсутствие функционала.
Но для прототипирования опять же есть CSG.
И есть выравнивание в редакторе, по сетке, по направляющим и т.д.
>>19390
Спасибо за ссылки! Топовый ютубер, туториалы профессиональные. Всем годанам рекомендую.
> Вот тут есть пример реализации: Godot Tutorial | Auto Tile for GridMap
Спасибо за ссылки! Топовый ютубер, туториалы профессиональные. Всем годанам рекомендую.
>>19404
Очень условно. 3д мир по клеткам, можно сказать что это воксели, можно 2д тайлы и вертикальные слои сделать. Но это не буквально чисто кубы с 16бит текстурками.
Да кто бы спорил, можно и ГТА5 сделать, да только ебанёшься один всё делать.
Туше.
Туше х2. Уговорил чертяка.
Нихуя не готово, потому что понял что начни разрабатывать ее до игры точно не дойдет нахой. Есть только много кукаретизации о том как она внутри должна работать, алгоритмов и бумаг которые можно использовать
Как раз таки SDF (Signed Distance Field) + на его основе нодовый редактор формул поможет хуярить подобник лоуполи-челиков просто конвейрерами нахуй. Пример (https://youtu.be/8--5LwHRhjk). И это дядко делал ещё ручками.
Д. но SDF и параметрическая графика ВНЕЗАПНО умеет в параметризацию. В прямых руках это мощный инструмент (который еще не зделоли). Я уже заебался это пояснять как и че там работает. Условно говоря будет гибрид между ручным трудом + модификаторы разные.
>Ты хочешь воксельный мир как в майнкрафте?
Очень условно. 3д мир по клеткам, можно сказать что это воксели, можно 2д тайлы и вертикальные слои сделать. Но это не буквально чисто кубы с 16бит текстурками.
>В общем, можно реализовать стандартными средствами Godot.
Да кто бы спорил, можно и ГТА5 сделать, да только ебанёшься один всё делать.
>Относись к 3D реализации так же, как к 2D: это просто способ отобразить часть информации - взаимное расположение объектов
Туше.
>Я к тому, что если у тебя активно используются все 3 оси игрового пространства, т.е. если объекты достаточно часто находятся выше или ниже других объектов (при виде строго сверху)
Туше х2. Уговорил чертяка.
>или ты только фантазировал о том, как будешь её использовать
Нихуя не готово, потому что понял что начни разрабатывать ее до игры точно не дойдет нахой. Есть только много кукаретизации о том как она внутри должна работать, алгоритмов и бумаг которые можно использовать
>И ты называешь это низкодетализированным?
Как раз таки SDF (Signed Distance Field) + на его основе нодовый редактор формул поможет хуярить подобник лоуполи-челиков просто конвейрерами нахуй. Пример (https://youtu.be/8--5LwHRhjk). И это дядко делал ещё ручками.
>Ты понимаешь, что это всё художники рисуют?
Д. но SDF и параметрическая графика ВНЕЗАПНО умеет в параметризацию. В прямых руках это мощный инструмент (который еще не зделоли). Я уже заебался это пояснять как и че там работает. Условно говоря будет гибрид между ручным трудом + модификаторы разные.
>>19547
Тебе не попадались такое же про процедурную/параметрическую генерацию тел? Гуманоида/мульяшку/аниме. Давно ищу.
Тебе не попадались такое же про процедурную/параметрическую генерацию тел? Гуманоида/мульяшку/аниме. Давно ищу.
>>19690
Нет, не сделали такой инструмент говорю же. Это чисто моя кукаретическая задумка. такое нахуй никому не надо. Технология сложная а пайплайн новый придумывать несмотря на то что все уже на старом (просто полигонально моделлить) оч много рынка
Нет, не сделали такой инструмент говорю же. Это чисто моя кукаретическая задумка. такое нахуй никому не надо. Технология сложная а пайплайн новый придумывать несмотря на то что все уже на старом (просто полигонально моделлить) оч много рынка
158 Кб, 1125x928Я ньюфаг в 3Д и Годо, поэтому извиняюсь если задаю глупый вопрос. Почему в редакторе есть "окружающий свет" или темнота, а в игре нет? В чём может быть причина, аноны?
>>19488
Ну да, о чём я и говорил. Хотя в некоторых ситуациях, наверное, будет лучше иметь RigidBody с sleeping = true.
Не 0, а -1, или, если точнее, GridMap.INVALID_CELL_ITEM
>>19497
Отдельные ячейки трансформировать нельзя, но можно указать полноценный трансформ для итема, т.е. чтобы все одинаковые ячейки трансформировались одинаково. Удобно, если ты генерируешь MeshLibrary процедурно: можно взять один mesh и создать сразу несколько item на его основе, применяя разные Transform. Это если тебе нужны, например, зеркальные копии блоков.
У GridMap главное преимущество в оптимизации с простым внешним интерфейсом. Тебе достаточно иметь одну ноду и заполнить её блоками, всё остальное произойдёт автоматически. Но ты прав, из-за этого теряется контроль, поэтому для чего-то сложнее придётся делать собственное решение из более низкоуровневых компонентов.
>отключение статиков и создание на их месте динамиков, и применяется оно в разрушаемом окружении
Ну да, о чём я и говорил. Хотя в некоторых ситуациях, наверное, будет лучше иметь RigidBody с sleeping = true.
>задание нулевого номера
Не 0, а -1, или, если точнее, GridMap.INVALID_CELL_ITEM
>>19497
>трансформ ячейки с мешем
>полноценного трансформа нет
Отдельные ячейки трансформировать нельзя, но можно указать полноценный трансформ для итема, т.е. чтобы все одинаковые ячейки трансформировались одинаково. Удобно, если ты генерируешь MeshLibrary процедурно: можно взять один mesh и создать сразу несколько item на его основе, применяя разные Transform. Это если тебе нужны, например, зеркальные копии блоков.
>Но для прототипирования опять же есть CSG.
>И есть выравнивание в редакторе, по сетке, по направляющим и т.д.
У GridMap главное преимущество в оптимизации с простым внешним интерфейсом. Тебе достаточно иметь одну ноду и заполнить её блоками, всё остальное произойдёт автоматически. Но ты прав, из-за этого теряется контроль, поэтому для чего-то сложнее придётся делать собственное решение из более низкоуровневых компонентов.
>>15359 (OP)
Подключаем SQLite к игоре, храним в таблицах списки мечей, топоров, монеток, кристаллов, бронелифчиков, статы, ивенты, диалоги и всё остальное. Получаем доступ к данным за полсекунды. Быдло оче боится.
https://www.youtube.com/watch?v=HG-PV4rlzoY
Подключаем SQLite к игоре, храним в таблицах списки мечей, топоров, монеток, кристаллов, бронелифчиков, статы, ивенты, диалоги и всё остальное. Получаем доступ к данным за полсекунды. Быдло оче боится.
https://www.youtube.com/watch?v=HG-PV4rlzoY
Нубам лучше юнити освавивать ибо дохуя ассетов и можно в одного собрать прилично выглядящую игру + дохуя возникающих проблем решено.
Я прав?
Я прав?
>>20080
Зачем? Ну вот, допустим, у меня в игре 1500 предметов, я должен сделать 1500 запросов к какой-то сторонней библиотеке, чтобы получить массив со всеми предметами? Или ты предлагаешь делать запрос к сторонней библиотеке каждый раз, когда тебе нужен какой-либо предмет? То-то же интерфейсы в современных играх так долго грузятся, когда открываешь инвентарь с предметами...
>храним в таблицах
Зачем? Ну вот, допустим, у меня в игре 1500 предметов, я должен сделать 1500 запросов к какой-то сторонней библиотеке, чтобы получить массив со всеми предметами? Или ты предлагаешь делать запрос к сторонней библиотеке каждый раз, когда тебе нужен какой-либо предмет? То-то же интерфейсы в современных играх так долго грузятся, когда открываешь инвентарь с предметами...
>>20102
Ну ты бы хоть погуглил матчасть. Язык SQL, если расписывать его для мимокроков, выглядит так:
Вот такое предложение пишешь, отправляешь один запрос (а не тысячу!!) и получаешь подтаблицу с нужной тебе выборкой.
Карочи. Если не шаришь - то тебе не надо. Проходи мимо. Даунинг и Крюгер не дадут соврать.
> Ну вот, допустим, у меня в игре 1500 предметов, я должен сделать 1500 запросов
Ну ты бы хоть погуглил матчасть. Язык SQL, если расписывать его для мимокроков, выглядит так:
> ВЫБЕРИ мне из таблицы ПРЕДМЕТОВ предметы, у которых ТИП = 10 и МАССА < 20, добавь к выборке таблицу ТИПОВ и таблицу МАСС, со следующими заголовками столбцов: ПРЕДМЕТ.ИМЯ как ПРЕДМЕТ, МАССА.ИМЯ как МАССА, ТИП.ИМЯ как ТИП, ПРЕДМЕТ.ВИД как ВИД
Вот такое предложение пишешь, отправляешь один запрос (а не тысячу!!) и получаешь подтаблицу с нужной тебе выборкой.
Карочи. Если не шаришь - то тебе не надо. Проходи мимо. Даунинг и Крюгер не дадут соврать.
>>15359 (OP)
Подскажите как реализован мультиплеер в годоте? В юньке использовал их последний геймобджект, по сути он создавал дубликаты объектов на каждом клиенте и они работали со свеой логикой исходя из того на каком клиенте чей.
Как тут это происходит? Синхронизация и коннект из коробки или надо ебаться с байтами самому?
Подскажите как реализован мультиплеер в годоте? В юньке использовал их последний геймобджект, по сути он создавал дубликаты объектов на каждом клиенте и они работали со свеой логикой исходя из того на каком клиенте чей.
Как тут это происходит? Синхронизация и коннект из коробки или надо ебаться с байтами самому?
>>20095
Тысячу раз обсуждалось на всех геймдев форумах. Нет, ты не сможешь собрать "прилично выглядящую игру" из одних только готовых ассетов, если ты хочешь что-то большее, чем ассет-флип за 30 рублей. Ты должен делать контент сам, под свою игру. Если ты берёшь какой-то готовый ассет, изволь все свои ассеты делать в том же стиле. Если ты берёшь один фотореалистичный камень, ты должен будешь всю остальную графику делать в фотореализме, бегая с фотоаппаратом за текстурами на улицу. А лоуполи без текстур любой ребёнок сделает.
Какие конкретно проблемы у тебя возникают? Перечисли.
Особенность любого универсального движка в том, что он по определению не способен решить все возможные проблемы. Если же он пытается решить все возможные проблемы, это приводит к сильному раздуванию кода движка, из-за чего твоя игра становится тяжелее и медленнее. Так что лучше брать низкоуровневые движки или движки, к исходным кодам которых ты имеешь доступ. К примеру, ты можешь удалить из исходников Godot не нужные тебе модули и скомпилировать свою версию движка. Или добавить что-то.
Godot проще для освоения с нуля. Разработчики специально максимально снижают порог входа, даже в ущерб производительности и функциональности. Т.е. приоритет Godot - доступность для всех, включая нубов.
>из ассетов можно в одного собрать прилично выглядящую игру
Тысячу раз обсуждалось на всех геймдев форумах. Нет, ты не сможешь собрать "прилично выглядящую игру" из одних только готовых ассетов, если ты хочешь что-то большее, чем ассет-флип за 30 рублей. Ты должен делать контент сам, под свою игру. Если ты берёшь какой-то готовый ассет, изволь все свои ассеты делать в том же стиле. Если ты берёшь один фотореалистичный камень, ты должен будешь всю остальную графику делать в фотореализме, бегая с фотоаппаратом за текстурами на улицу. А лоуполи без текстур любой ребёнок сделает.
>возникающих проблем решено
Какие конкретно проблемы у тебя возникают? Перечисли.
Особенность любого универсального движка в том, что он по определению не способен решить все возможные проблемы. Если же он пытается решить все возможные проблемы, это приводит к сильному раздуванию кода движка, из-за чего твоя игра становится тяжелее и медленнее. Так что лучше брать низкоуровневые движки или движки, к исходным кодам которых ты имеешь доступ. К примеру, ты можешь удалить из исходников Godot не нужные тебе модули и скомпилировать свою версию движка. Или добавить что-то.
>Нубам лучше
Godot проще для освоения с нуля. Разработчики специально максимально снижают порог входа, даже в ущерб производительности и функциональности. Т.е. приоритет Godot - доступность для всех, включая нубов.
>>20112
Под проблемами я понимаю проблемы движка - баги, незадокументированные особенности и т.д.
Под проблемами я понимаю проблемы движка - баги, незадокументированные особенности и т.д.
>>20111
Читай документацию, там доступным языком всё.
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Судя по всему, в Годо похожая система. Не думаю, что в принципе возможно что-то иное. Как ты себе представляешь игру, у которой объекты будут только на одном клиенте? Другие клиенты не смогут отобразить объекты, которых у них нет, верно?
Да, конечно. Также есть низкоуровневое API (UDP, TCP, HTTP).
>мультиплеер в годоте
Читай документацию, там доступным языком всё.
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
>создавал дубликаты объектов на каждом клиенте и они работали со свеой логикой исходя из того на каком клиенте чей
Судя по всему, в Годо похожая система. Не думаю, что в принципе возможно что-то иное. Как ты себе представляешь игру, у которой объекты будут только на одном клиенте? Другие клиенты не смогут отобразить объекты, которых у них нет, верно?
>Синхронизация и коннект из коробки
Да, конечно. Также есть низкоуровневое API (UDP, TCP, HTTP).
>>20114
Godot достаточно стабилен, когда релизится stable версия. Конечно, alpha/beta релизы будут нестабильны, но никто не заставляет тебя их использовать. RC (release candidate) сравнительно стабильны. Достаточно часто выходят патчи с багфиксами, если какой-то баг критический, его быстро исправляют. Хотя некоторые баги остаются годами, но они не критичны для большинства игр, ты о них можешь никогда не узнать на личном опыте.
Официальный багтрекер:
https://github.com/godotengine/godot/issues?q=is:issue+is:open+label:bug
Только учитывай, что большинство этих багов относится к 4.0 версии, которая уже несколько лет в разработке. Актуальные 3.x версии достаточно стабильны для разработки и релиза игр.
А вот на Юнити полный бардак с багами. И с годами всё только хуже становится, судя по постам на форумах. Сам я только немного её пробовал, не понравилось.
У Godot очень хорошая документация (если говорить о stable версиях), в т.ч. встроенная в движок. Не описаны только самые малозначимые функции, сомневаюсь, что они когда-либо понадобятся разработчику игры (они доступны скорее всего потому, что редактор Godot - это "игра" на движке Godot). Но даже если будет что-то важное и недокументированное, ты можешь сам поискать по коду или попросить на гитхабе задокументировать фичу.
https://github.com/godotengine/godot-docs/issues
Разработчики отзывчивые, и если ты культурно спросишь, получишь нормальный ответ (там даже откровенных шизов не особо прогоняют, инклюзивность однако, хотя украинца одного забанили за какое-то неприличное поведение, ну он конкретно поехавший какой-то, даром что контрибутил код, теперь "кенселит" в твиттере).
>проблемы движка - баги
Godot достаточно стабилен, когда релизится stable версия. Конечно, alpha/beta релизы будут нестабильны, но никто не заставляет тебя их использовать. RC (release candidate) сравнительно стабильны. Достаточно часто выходят патчи с багфиксами, если какой-то баг критический, его быстро исправляют. Хотя некоторые баги остаются годами, но они не критичны для большинства игр, ты о них можешь никогда не узнать на личном опыте.
Официальный багтрекер:
https://github.com/godotengine/godot/issues?q=is:issue+is:open+label:bug
Только учитывай, что большинство этих багов относится к 4.0 версии, которая уже несколько лет в разработке. Актуальные 3.x версии достаточно стабильны для разработки и релиза игр.
А вот на Юнити полный бардак с багами. И с годами всё только хуже становится, судя по постам на форумах. Сам я только немного её пробовал, не понравилось.
>незадокументированные особенности
У Godot очень хорошая документация (если говорить о stable версиях), в т.ч. встроенная в движок. Не описаны только самые малозначимые функции, сомневаюсь, что они когда-либо понадобятся разработчику игры (они доступны скорее всего потому, что редактор Godot - это "игра" на движке Godot). Но даже если будет что-то важное и недокументированное, ты можешь сам поискать по коду или попросить на гитхабе задокументировать фичу.
https://github.com/godotengine/godot-docs/issues
Разработчики отзывчивые, и если ты культурно спросишь, получишь нормальный ответ (там даже откровенных шизов не особо прогоняют, инклюзивность однако, хотя украинца одного забанили за какое-то неприличное поведение, ну он конкретно поехавший какой-то, даром что контрибутил код, теперь "кенселит" в твиттере).
>>20107
Я знаю, как он выглядит, я создавал такие таблицы в вебе. Но в вебе эта технология нужна, чтобы не было прямого доступа к файлам на сервере, т.е. ради безопасности данных.
Опиши ситуацию, в которой тебе в игре необходимо создавать такие запросы всего раз за всю игру? И почему ты не можешь заранее отсортировать свои данные по массивам, которые тебе в любом случае потребуется хранить в оперативной памяти?
По-моему, необходимость в SQL в игре может возникнуть только из-за плохой архитектуры игры. Когда, например, какой-то код каждый раз грузит с диска и сортирует список предметов, хотя по-хорошему он этого делать никогда не должен. Вот для сортировки инвентаря а-ля майнкрафт ты предлагаешь делать запрос к SQL базе? А не лучше ли будет отсортировать ноды, которыми ты рендеришь инвентарь? Ведь твои ноды должны быть связаны с какими-то объектами в оперативной памяти, которые загружены ещё на старте игры. Нет, ты будешь тратить драгоценные секунды на составление запроса к посторонней библиотеке, которая будет искать данные на диске, чтобы ты затем перезагрузил и переприсвоил текстуры для неподвижных нод на экране - и так на каждое открытие инвентаря? Это просто плохой дизайн системы, и SQL тут лишний костыль.
>Язык SQL выглядит так
Я знаю, как он выглядит, я создавал такие таблицы в вебе. Но в вебе эта технология нужна, чтобы не было прямого доступа к файлам на сервере, т.е. ради безопасности данных.
>отправляешь один запрос (а не тысячу!!)
Опиши ситуацию, в которой тебе в игре необходимо создавать такие запросы всего раз за всю игру? И почему ты не можешь заранее отсортировать свои данные по массивам, которые тебе в любом случае потребуется хранить в оперативной памяти?
По-моему, необходимость в SQL в игре может возникнуть только из-за плохой архитектуры игры. Когда, например, какой-то код каждый раз грузит с диска и сортирует список предметов, хотя по-хорошему он этого делать никогда не должен. Вот для сортировки инвентаря а-ля майнкрафт ты предлагаешь делать запрос к SQL базе? А не лучше ли будет отсортировать ноды, которыми ты рендеришь инвентарь? Ведь твои ноды должны быть связаны с какими-то объектами в оперативной памяти, которые загружены ещё на старте игры. Нет, ты будешь тратить драгоценные секунды на составление запроса к посторонней библиотеке, которая будет искать данные на диске, чтобы ты затем перезагрузил и переприсвоил текстуры для неподвижных нод на экране - и так на каждое открытие инвентаря? Это просто плохой дизайн системы, и SQL тут лишний костыль.
Уже несколько дней задумываюсь, а можно ли сделать имитацию маленькой сферической планеты, не прибегая к деформации мешей и изменении рассчётов? Т.е. накинуть шейдер на "экран". Я знаю, что в майнкрафте такое возможно, видел примеры. Сегодня глянул примеры шейдеров, смог считать снимок экрана и наложить на него буфер глубины, отобразив на QuadMesh перед камерой. Но я не понимаю, как вычислить смещение пикселей относительно дальности от камеры. Как я понимаю, наиболее дальние пиксели должны смещаться вниз, как бы скрываясь за поверхностью планеты (или другими объектами), однако как это реализовать, если fragment() работает только с текущим пикселем и не может, скажем, сместить его вниз? Алсо не ясно что делать, когда камера смотрит не строго параллельно поверхности планеты.
Или лучше отбросить эту затею и попытаться реализовать истинно сферическую планету? Я не знаю, как это сделать, если брать за основу квадратные блоки - их же придётся деформировать. Насколько я знаю, не существует идеальной развёртки сферы, чтобы все "тайлы" были одинаковой формы и размера.
Нет, для моего проекта это всё не обязательно. Просто идея очень любопытная, и если её не очень сложно реализовать, это было круто. Тогда не пришлось бы беспокоиться о краях карты...
Или лучше отбросить эту затею и попытаться реализовать истинно сферическую планету? Я не знаю, как это сделать, если брать за основу квадратные блоки - их же придётся деформировать. Насколько я знаю, не существует идеальной развёртки сферы, чтобы все "тайлы" были одинаковой формы и размера.
Нет, для моего проекта это всё не обязательно. Просто идея очень любопытная, и если её не очень сложно реализовать, это было круто. Тогда не пришлось бы беспокоиться о краях карты...
>>19547
Тогда что-то вроде проекта выше по треду (на видео)?
Вообще-то, в твоём примере модель рендерится рейтрейсингом, и никакого меша не существует - только математические формулы. Меш по формулам тоже можно сгенерировать, конечно, но меш такого уровня детализации - ни разу не лоуполи.
Хм... Ты же знаешь про VisualScript? Это встроенный визуальный ЯП в Godot, предназначенный для всяких яждизайнеров и прочих гуманитариев. Под капотом там отдельная от GDScript виртуальная машина, а код состоит из нод. В теории, если ты разработаешь свой SDF генератор мешей на GDScript/C#/C++/любом другом подключаемом к Godot ЯП, ты сможешь распоряжаться этим генератором через VisualScript, визуально натягивая лапшу между визуальными блоками своих функций, генерирующих меши. Хрен знает, чем оно тебе поможет (кодом всё равно проще), но если ты хочешь визуальный редактор формул - это оно.
Ну или можно по-быстрому набросать велосипед. И даже встроить в интерфейс редактора Годо, чтобы появилось дополнительное окошко с твоими супер-пупер нодами. В документации должна быть информация, как такое можно сделать, плюс я видел примеры подобных встроенных редакторов чего-то. Хех, теоретически из Godot можно сделать огромный комбайн, даже не притрагиваясь к исходным кодам, чисто на плагинах, тул-скриптах и GDNative.
В смысле не сделали?
https://github.com/nortikin/sverchok/blob/master/README_RU.md
https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/introduction.html
Или ты хочешь чтобы это было в Godot из коробки? Godot - универсальный движок, а параметрическая графика - очень специфическая вещь, мало кому нужна. Достаточно того, что добавили CSG ноды, пусть и не очень надёжные (треугольники постоянно ломаются, а результат при экспорте ужасает, т.е. для моделирования лучше юзать Blender).
>>19690
>>19754
Ну, например, такое есть:
https://github.com/animate1978/MB-Lab
https://github.com/Upliner/CharMorph
Там не та математика, что в твоём видео, а обычные морфы базовых мешей, но этого хватит в 99% индюшачих проектов.
А так, вы можете сами сделать процедурный генератор гуманоидов на Сверчке или геометри нодах в Блендере, только я даже не могу представить себе объём работы...
Вообще не понимаю, зачем вам парить себе мозг высшей математикой, пытаясь построить гуманоидов из математических операций, когда есть способы намного проще и быстрее. Вы же не планируете гонять весь этот матан на компьютере пользователя? Всё равно придётся "запечь" формулы в меши, чтобы не парить компьютер и его пользователя лишними вычислениями.
>3д мир по клеткам
>это не буквально чисто кубы
Тогда что-то вроде проекта выше по треду (на видео)?
>SDF
>лоуполи
>Пример
Вообще-то, в твоём примере модель рендерится рейтрейсингом, и никакого меша не существует - только математические формулы. Меш по формулам тоже можно сгенерировать, конечно, но меш такого уровня детализации - ни разу не лоуполи.
>нодовый редактор формул
Хм... Ты же знаешь про VisualScript? Это встроенный визуальный ЯП в Godot, предназначенный для всяких яждизайнеров и прочих гуманитариев. Под капотом там отдельная от GDScript виртуальная машина, а код состоит из нод. В теории, если ты разработаешь свой SDF генератор мешей на GDScript/C#/C++/любом другом подключаемом к Godot ЯП, ты сможешь распоряжаться этим генератором через VisualScript, визуально натягивая лапшу между визуальными блоками своих функций, генерирующих меши. Хрен знает, чем оно тебе поможет (кодом всё равно проще), но если ты хочешь визуальный редактор формул - это оно.
Ну или можно по-быстрому набросать велосипед. И даже встроить в интерфейс редактора Годо, чтобы появилось дополнительное окошко с твоими супер-пупер нодами. В документации должна быть информация, как такое можно сделать, плюс я видел примеры подобных встроенных редакторов чего-то. Хех, теоретически из Godot можно сделать огромный комбайн, даже не притрагиваясь к исходным кодам, чисто на плагинах, тул-скриптах и GDNative.
>параметрическая графика
>который еще не зделоли
В смысле не сделали?
https://github.com/nortikin/sverchok/blob/master/README_RU.md
https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/introduction.html
Или ты хочешь чтобы это было в Godot из коробки? Godot - универсальный движок, а параметрическая графика - очень специфическая вещь, мало кому нужна. Достаточно того, что добавили CSG ноды, пусть и не очень надёжные (треугольники постоянно ломаются, а результат при экспорте ужасает, т.е. для моделирования лучше юзать Blender).
>>19690
>процедурную/параметрическую генерацию тел
>Гуманоида/мульяшку/аниме
>>19754
>Нет, не сделали такой инструмент
Ну, например, такое есть:
https://github.com/animate1978/MB-Lab
https://github.com/Upliner/CharMorph
Там не та математика, что в твоём видео, а обычные морфы базовых мешей, но этого хватит в 99% индюшачих проектов.
А так, вы можете сами сделать процедурный генератор гуманоидов на Сверчке или геометри нодах в Блендере, только я даже не могу представить себе объём работы...
Вообще не понимаю, зачем вам парить себе мозг высшей математикой, пытаясь построить гуманоидов из математических операций, когда есть способы намного проще и быстрее. Вы же не планируете гонять весь этот матан на компьютере пользователя? Всё равно придётся "запечь" формулы в меши, чтобы не парить компьютер и его пользователя лишними вычислениями.
>>19547
Тогда что-то вроде проекта выше по треду (на видео)?
Вообще-то, в твоём примере модель рендерится рейтрейсингом, и никакого меша не существует - только математические формулы. Меш по формулам тоже можно сгенерировать, конечно, но меш такого уровня детализации - ни разу не лоуполи.
Хм... Ты же знаешь про VisualScript? Это встроенный визуальный ЯП в Godot, предназначенный для всяких яждизайнеров и прочих гуманитариев. Под капотом там отдельная от GDScript виртуальная машина, а код состоит из нод. В теории, если ты разработаешь свой SDF генератор мешей на GDScript/C#/C++/любом другом подключаемом к Godot ЯП, ты сможешь распоряжаться этим генератором через VisualScript, визуально натягивая лапшу между визуальными блоками своих функций, генерирующих меши. Хрен знает, чем оно тебе поможет (кодом всё равно проще), но если ты хочешь визуальный редактор формул - это оно.
Ну или можно по-быстрому набросать велосипед. И даже встроить в интерфейс редактора Годо, чтобы появилось дополнительное окошко с твоими супер-пупер нодами. В документации должна быть информация, как такое можно сделать, плюс я видел примеры подобных встроенных редакторов чего-то. Хех, теоретически из Godot можно сделать огромный комбайн, даже не притрагиваясь к исходным кодам, чисто на плагинах, тул-скриптах и GDNative.
В смысле не сделали?
https://github.com/nortikin/sverchok/blob/master/README_RU.md
https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/introduction.html
Или ты хочешь чтобы это было в Godot из коробки? Godot - универсальный движок, а параметрическая графика - очень специфическая вещь, мало кому нужна. Достаточно того, что добавили CSG ноды, пусть и не очень надёжные (треугольники постоянно ломаются, а результат при экспорте ужасает, т.е. для моделирования лучше юзать Blender).
>>19690
>>19754
Ну, например, такое есть:
https://github.com/animate1978/MB-Lab
https://github.com/Upliner/CharMorph
Там не та математика, что в твоём видео, а обычные морфы базовых мешей, но этого хватит в 99% индюшачих проектов.
А так, вы можете сами сделать процедурный генератор гуманоидов на Сверчке или геометри нодах в Блендере, только я даже не могу представить себе объём работы...
Вообще не понимаю, зачем вам парить себе мозг высшей математикой, пытаясь построить гуманоидов из математических операций, когда есть способы намного проще и быстрее. Вы же не планируете гонять весь этот матан на компьютере пользователя? Всё равно придётся "запечь" формулы в меши, чтобы не парить компьютер и его пользователя лишними вычислениями.
>3д мир по клеткам
>это не буквально чисто кубы
Тогда что-то вроде проекта выше по треду (на видео)?
>SDF
>лоуполи
>Пример
Вообще-то, в твоём примере модель рендерится рейтрейсингом, и никакого меша не существует - только математические формулы. Меш по формулам тоже можно сгенерировать, конечно, но меш такого уровня детализации - ни разу не лоуполи.
>нодовый редактор формул
Хм... Ты же знаешь про VisualScript? Это встроенный визуальный ЯП в Godot, предназначенный для всяких яждизайнеров и прочих гуманитариев. Под капотом там отдельная от GDScript виртуальная машина, а код состоит из нод. В теории, если ты разработаешь свой SDF генератор мешей на GDScript/C#/C++/любом другом подключаемом к Godot ЯП, ты сможешь распоряжаться этим генератором через VisualScript, визуально натягивая лапшу между визуальными блоками своих функций, генерирующих меши. Хрен знает, чем оно тебе поможет (кодом всё равно проще), но если ты хочешь визуальный редактор формул - это оно.
Ну или можно по-быстрому набросать велосипед. И даже встроить в интерфейс редактора Годо, чтобы появилось дополнительное окошко с твоими супер-пупер нодами. В документации должна быть информация, как такое можно сделать, плюс я видел примеры подобных встроенных редакторов чего-то. Хех, теоретически из Godot можно сделать огромный комбайн, даже не притрагиваясь к исходным кодам, чисто на плагинах, тул-скриптах и GDNative.
>параметрическая графика
>который еще не зделоли
В смысле не сделали?
https://github.com/nortikin/sverchok/blob/master/README_RU.md
https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/introduction.html
Или ты хочешь чтобы это было в Godot из коробки? Godot - универсальный движок, а параметрическая графика - очень специфическая вещь, мало кому нужна. Достаточно того, что добавили CSG ноды, пусть и не очень надёжные (треугольники постоянно ломаются, а результат при экспорте ужасает, т.е. для моделирования лучше юзать Blender).
>>19690
>процедурную/параметрическую генерацию тел
>Гуманоида/мульяшку/аниме
>>19754
>Нет, не сделали такой инструмент
Ну, например, такое есть:
https://github.com/animate1978/MB-Lab
https://github.com/Upliner/CharMorph
Там не та математика, что в твоём видео, а обычные морфы базовых мешей, но этого хватит в 99% индюшачих проектов.
А так, вы можете сами сделать процедурный генератор гуманоидов на Сверчке или геометри нодах в Блендере, только я даже не могу представить себе объём работы...
Вообще не понимаю, зачем вам парить себе мозг высшей математикой, пытаясь построить гуманоидов из математических операций, когда есть способы намного проще и быстрее. Вы же не планируете гонять весь этот матан на компьютере пользователя? Всё равно придётся "запечь" формулы в меши, чтобы не парить компьютер и его пользователя лишними вычислениями.
Можно ли на gdscript писать самостоятельный код, не привязанный к нодам, создавать свои классы, структуры данных, библиотеки? Есть ли там полноценная поддержка ООП и обобщенного программирования?
95 Кб, 960x600>>19547
Я тут копался в интерфейсе игры и ТАКОЕ нашёл! Ты смотри! У нас есть прямой доступ к тем нодам, которые используются в VisualScript и VisualShader! ПРОСТО садишься и делаешь свой нодовый редактор чего угодно! Офигеть. Осталось придумать, что с этим сделать...
https://docs.godotengine.org/en/stable/classes/class_graphedit.html
https://docs.godotengine.org/en/stable/classes/class_graphnode.html
Как этим всем управлять:
1. Бросаешь в сцену GraphEdit.
2. Ему в потомки бросаешь GraphNode.
3. В потомки GraphNode - любые наследники Control, например, Label для надписи, LineEdit для поля ввода...
4. В инспекторе настраиваешь входные и выходные порты каждого GraphNode. Имеет смысл сохранить их как сцены.
5. Вешаешь на GraphEdit скрипт и обрабатываешь в нём сигналы, которые можно найти в инспекторе. Дело в том, что сами по себе ноды ничего не делают, они только генерируют сигналы, а ты сам должен решать, что нужно в ответ на эти сигналы делать, и дёргать соответствующие функции в GraphEdit/GraphNode. Это даёт максимальную свободу, но требует время на настройку.
В общем, вот, оказывается, сделать что-то вроде Geometry Nodes или Сверчка даже проще, чем я думал. В смысле, в плане GUI - не придётся изобретать велосипед.
>нодовый редактор
Я тут копался в интерфейсе игры и ТАКОЕ нашёл! Ты смотри! У нас есть прямой доступ к тем нодам, которые используются в VisualScript и VisualShader! ПРОСТО садишься и делаешь свой нодовый редактор чего угодно! Офигеть. Осталось придумать, что с этим сделать...
https://docs.godotengine.org/en/stable/classes/class_graphedit.html
https://docs.godotengine.org/en/stable/classes/class_graphnode.html
Как этим всем управлять:
1. Бросаешь в сцену GraphEdit.
2. Ему в потомки бросаешь GraphNode.
3. В потомки GraphNode - любые наследники Control, например, Label для надписи, LineEdit для поля ввода...
4. В инспекторе настраиваешь входные и выходные порты каждого GraphNode. Имеет смысл сохранить их как сцены.
5. Вешаешь на GraphEdit скрипт и обрабатываешь в нём сигналы, которые можно найти в инспекторе. Дело в том, что сами по себе ноды ничего не делают, они только генерируют сигналы, а ты сам должен решать, что нужно в ответ на эти сигналы делать, и дёргать соответствующие функции в GraphEdit/GraphNode. Это даёт максимальную свободу, но требует время на настройку.
В общем, вот, оказывается, сделать что-то вроде Geometry Nodes или Сверчка даже проще, чем я думал. В смысле, в плане GUI - не придётся изобретать велосипед.
>>20475
Может быть и да.
Формулы для формы и текстуры. Потом формулы строятся через Dual countoring или любой подобный алгоритм (есть и лучше/быстрее/не требущие дифференциальных функций). https://www.youtube.com/results?search_query=mesh+dual+contouring
Уже давно эту идею забросил, но технически изучил как всё реализовать. Да, знал. Вот пример (https://github.com/protongraph/protongraph) того как это могло выглядеть в теории, но чувак тоже забросил.
Я ничего больше по этой теме не хочу. нужно фанатеть по визуалу + блендер это совсем не рилтайм. В теории подобная графика может заменить в инди играх обычную именно из за своей гибкости и модифицируемости прямо в рилтайме.
Именно что идея в рилтайме. Я согласен что я большинства игр такая технология нахуй не нужна, и предложенный тобою пайплайн бы с лихвой всё оккупил. Я говорю о реально симулятивных 3д играх с более-менее информативным визуалом где потенциальные комбинации возможных модификаций и изменений различных персонажей, предметов и окружения можно передавать как раз параметризацией. Но никто нахуй такое делать кажись не будет, потому что всем нравится уплетать статичные сетки за обе щёки. Или проще это я шизофреник поехавший.
А на что тебе компьюте шейдеры? Выше скинул примеры, в теории такие бешеные модификации сеток могут производиться по 30 раз в секунду, хотя для моей задумки по сути изменение сетки происходит только в месте модификации меша, и то крайне редко (относительно скорости компьютера). Потенциал ебейший на самом деле.
>Тогда что-то вроде проекта выше по треду (на видео)?
Может быть и да.
>Вообще-то, в твоём примере модель рендерится рейтрейсингом
Формулы для формы и текстуры. Потом формулы строятся через Dual countoring или любой подобный алгоритм (есть и лучше/быстрее/не требущие дифференциальных функций). https://www.youtube.com/results?search_query=mesh+dual+contouring
>Хм... Ты же знаешь про VisualScript?
Уже давно эту идею забросил, но технически изучил как всё реализовать. Да, знал. Вот пример (https://github.com/protongraph/protongraph) того как это могло выглядеть в теории, но чувак тоже забросил.
>Или ты хочешь чтобы это было в Godot из коробки?
Я ничего больше по этой теме не хочу. нужно фанатеть по визуалу + блендер это совсем не рилтайм. В теории подобная графика может заменить в инди играх обычную именно из за своей гибкости и модифицируемости прямо в рилтайме.
>Всё равно придётся "запечь" формулы в меши, чтобы не парить компьютер и его пользователя лишними вычислениями.
Именно что идея в рилтайме. Я согласен что я большинства игр такая технология нахуй не нужна, и предложенный тобою пайплайн бы с лихвой всё оккупил. Я говорю о реально симулятивных 3д играх с более-менее информативным визуалом где потенциальные комбинации возможных модификаций и изменений различных персонажей, предметов и окружения можно передавать как раз параметризацией. Но никто нахуй такое делать кажись не будет, потому что всем нравится уплетать статичные сетки за обе щёки. Или проще это я шизофреник поехавший.
>Вы же не планируете гонять весь этот матан на компьютере пользователя?
А на что тебе компьюте шейдеры? Выше скинул примеры, в теории такие бешеные модификации сеток могут производиться по 30 раз в секунду, хотя для моей задумки по сути изменение сетки происходит только в месте модификации меша, и то крайне редко (относительно скорости компьютера). Потенциал ебейший на самом деле.
40 Кб, 844x681>>20528
Да, я не сомневался что это сложно. Проблема в том объёме работ под капотом. Просто рас рас и готово, с генерацией мешей на ЦПУ не выйдет. Нужны пиздецовые исследования не только в плане производительности этого дела (а это уже работы обоссать все шторы), так и непосредственно совершеннол новые алгроитмы. Например как на сгенерированную SDF модельку персонажа накинуть веса? Идеи есть? А это только самое начало. Сколько инструментов придется с нуля нахуярить, что там по текстуркам? Как их накладывать на 3д объект? Обмазывать по поверхности или создавать отдельный SDF слой который несёт информацию о цвете, и создавать эти цветовые шарики на персонаже?
При такой структуре модели появляется EZ возможность сделать органы внутренние например. Ты литералли моделлишь то что находится в персонаже. Но что делать с сетками? Их атм тоже генерить?
И это только самый поверхностный поток вопросов. Чот в голову мне пришла слишком неподъёмная затея. Надеюсь какой нибудь пизданутый гений спиздит её и сделает за меня.
Решил еще вкинуть какую-то хуйню которую про анимацию костную писал, как ее делать на параметричности
Да, я не сомневался что это сложно. Проблема в том объёме работ под капотом. Просто рас рас и готово, с генерацией мешей на ЦПУ не выйдет. Нужны пиздецовые исследования не только в плане производительности этого дела (а это уже работы обоссать все шторы), так и непосредственно совершеннол новые алгроитмы. Например как на сгенерированную SDF модельку персонажа накинуть веса? Идеи есть? А это только самое начало. Сколько инструментов придется с нуля нахуярить, что там по текстуркам? Как их накладывать на 3д объект? Обмазывать по поверхности или создавать отдельный SDF слой который несёт информацию о цвете, и создавать эти цветовые шарики на персонаже?
При такой структуре модели появляется EZ возможность сделать органы внутренние например. Ты литералли моделлишь то что находится в персонаже. Но что делать с сетками? Их атм тоже генерить?
И это только самый поверхностный поток вопросов. Чот в голову мне пришла слишком неподъёмная затея. Надеюсь какой нибудь пизданутый гений спиздит её и сделает за меня.
Решил еще вкинуть какую-то хуйню которую про анимацию костную писал, как ее делать на параметричности
>>20528
Забыл сказать: на каждый прямой потомок GraphNode можно задать два порта - входящий и исходящий. Но не обязательно, каждый из них включается и настраивается по отдельности.
Я имел в виду сохранить GraphNode. Потому что такой визуальный редактор подразумевает создание нод из библиотеки/списка нод, и создаваемые ноды должны быть уже настроены. Имеет смысл каждую сохранить в отдельный .tscn и инстансить по необходимости, например, по клику на определённую кнопку...
>>20529
Если модифицировать меши в рантайме, будет сильная просадка производительности, либо меши будут слишком лоуполи.
А кто сказал, что "реальная симуляция" - это обязательно процедурно генерируемые меши? Это никак не связанные темы. Во-первых, даже если ты процедурно генерируешь что-то, ты задаёшь генератору параметры генерации, шаблоны и т.д. Это то же самое, что "статичные сетки" из блендера - заранее заготовленная информация. Во-вторых, кто сказал, что в симуляции должны быть миллионы миллионов миллионов вариантов одного камня на дороге, который ничего не делает, просто существует? Это бессмысленный максимализм. Симуляция может быть ограниченной набором некоторых возможностей. ИРЛ вот скорость света считается непреодолимой, но это ведь не делает наш мир... менее реальной симуляцией. Ты не можешь прыгнуть до Луны, но это не делает симуляцию твоего тела менее реальной. И т.д. Виртуальный мир по определению будет иметь больше ограничений, чем мир, в котором он симулируется (потому что банально атомов не хватит на симуляцию), и мы можем лишь смириться с этими ограничениями.
>>20533
Ну вот ты рассуждаешь о сложности, но оправдана ли эта сложность? Зачем это всё будет делать тот абстрактный гений, который может это всё сделать? Можно же просто заготовить "статичных" мешей и комбинировать их друг с другом. Чем больше вариантов мешей и чем больше возможностей по их комбинации, тем больше в результате вариантов процедурной генерации. И практически бесплатно как по умственным затратам, так и по производительности компьютера. И симуляция получается полноценная, если ты делаешь игру, а не научный проект по симуляции человеческого тела со всеми органами и тканями в соответствии с реальной физикой и химией.
>4. В инспекторе настраиваешь входные и выходные порты каждого GraphNode.
Забыл сказать: на каждый прямой потомок GraphNode можно задать два порта - входящий и исходящий. Но не обязательно, каждый из них включается и настраивается по отдельности.
>Имеет смысл сохранить их как сцены.
Я имел в виду сохранить GraphNode. Потому что такой визуальный редактор подразумевает создание нод из библиотеки/списка нод, и создаваемые ноды должны быть уже настроены. Имеет смысл каждую сохранить в отдельный .tscn и инстансить по необходимости, например, по клику на определённую кнопку...
>>20529
>модифицируемости прямо в рилтайме
Если модифицировать меши в рантайме, будет сильная просадка производительности, либо меши будут слишком лоуполи.
>говорю о реально симулятивных 3д играх
>всем нравится уплетать статичные сетки
А кто сказал, что "реальная симуляция" - это обязательно процедурно генерируемые меши? Это никак не связанные темы. Во-первых, даже если ты процедурно генерируешь что-то, ты задаёшь генератору параметры генерации, шаблоны и т.д. Это то же самое, что "статичные сетки" из блендера - заранее заготовленная информация. Во-вторых, кто сказал, что в симуляции должны быть миллионы миллионов миллионов вариантов одного камня на дороге, который ничего не делает, просто существует? Это бессмысленный максимализм. Симуляция может быть ограниченной набором некоторых возможностей. ИРЛ вот скорость света считается непреодолимой, но это ведь не делает наш мир... менее реальной симуляцией. Ты не можешь прыгнуть до Луны, но это не делает симуляцию твоего тела менее реальной. И т.д. Виртуальный мир по определению будет иметь больше ограничений, чем мир, в котором он симулируется (потому что банально атомов не хватит на симуляцию), и мы можем лишь смириться с этими ограничениями.
>>20533
Ну вот ты рассуждаешь о сложности, но оправдана ли эта сложность? Зачем это всё будет делать тот абстрактный гений, который может это всё сделать? Можно же просто заготовить "статичных" мешей и комбинировать их друг с другом. Чем больше вариантов мешей и чем больше возможностей по их комбинации, тем больше в результате вариантов процедурной генерации. И практически бесплатно как по умственным затратам, так и по производительности компьютера. И симуляция получается полноценная, если ты делаешь игру, а не научный проект по симуляции человеческого тела со всеми органами и тканями в соответствии с реальной физикой и химией.
>>20528
Забыл сказать: на каждый прямой потомок GraphNode можно задать два порта - входящий и исходящий. Но не обязательно, каждый из них включается и настраивается по отдельности.
Я имел в виду сохранить GraphNode. Потому что такой визуальный редактор подразумевает создание нод из библиотеки/списка нод, и создаваемые ноды должны быть уже настроены. Имеет смысл каждую сохранить в отдельный .tscn и инстансить по необходимости, например, по клику на определённую кнопку...
>>20529
Если модифицировать меши в рантайме, будет сильная просадка производительности, либо меши будут слишком лоуполи.
А кто сказал, что "реальная симуляция" - это обязательно процедурно генерируемые меши? Это никак не связанные темы. Во-первых, даже если ты процедурно генерируешь что-то, ты задаёшь генератору параметры генерации, шаблоны и т.д. Это то же самое, что "статичные сетки" из блендера - заранее заготовленная информация. Во-вторых, кто сказал, что в симуляции должны быть миллионы миллионов миллионов вариантов одного камня на дороге, который ничего не делает, просто существует? Это бессмысленный максимализм. Симуляция может быть ограниченной набором некоторых возможностей. ИРЛ вот скорость света считается непреодолимой, но это ведь не делает наш мир... менее реальной симуляцией. Ты не можешь прыгнуть до Луны, но это не делает симуляцию твоего тела менее реальной. И т.д. Виртуальный мир по определению будет иметь больше ограничений, чем мир, в котором он симулируется (потому что банально атомов не хватит на симуляцию), и мы можем лишь смириться с этими ограничениями.
>>20533
Ну вот ты рассуждаешь о сложности, но оправдана ли эта сложность? Зачем это всё будет делать тот абстрактный гений, который может это всё сделать? Можно же просто заготовить "статичных" мешей и комбинировать их друг с другом. Чем больше вариантов мешей и чем больше возможностей по их комбинации, тем больше в результате вариантов процедурной генерации. И практически бесплатно как по умственным затратам, так и по производительности компьютера. И симуляция получается полноценная, если ты делаешь игру, а не научный проект по симуляции человеческого тела со всеми органами и тканями в соответствии с реальной физикой и химией.
>4. В инспекторе настраиваешь входные и выходные порты каждого GraphNode.
Забыл сказать: на каждый прямой потомок GraphNode можно задать два порта - входящий и исходящий. Но не обязательно, каждый из них включается и настраивается по отдельности.
>Имеет смысл сохранить их как сцены.
Я имел в виду сохранить GraphNode. Потому что такой визуальный редактор подразумевает создание нод из библиотеки/списка нод, и создаваемые ноды должны быть уже настроены. Имеет смысл каждую сохранить в отдельный .tscn и инстансить по необходимости, например, по клику на определённую кнопку...
>>20529
>модифицируемости прямо в рилтайме
Если модифицировать меши в рантайме, будет сильная просадка производительности, либо меши будут слишком лоуполи.
>говорю о реально симулятивных 3д играх
>всем нравится уплетать статичные сетки
А кто сказал, что "реальная симуляция" - это обязательно процедурно генерируемые меши? Это никак не связанные темы. Во-первых, даже если ты процедурно генерируешь что-то, ты задаёшь генератору параметры генерации, шаблоны и т.д. Это то же самое, что "статичные сетки" из блендера - заранее заготовленная информация. Во-вторых, кто сказал, что в симуляции должны быть миллионы миллионов миллионов вариантов одного камня на дороге, который ничего не делает, просто существует? Это бессмысленный максимализм. Симуляция может быть ограниченной набором некоторых возможностей. ИРЛ вот скорость света считается непреодолимой, но это ведь не делает наш мир... менее реальной симуляцией. Ты не можешь прыгнуть до Луны, но это не делает симуляцию твоего тела менее реальной. И т.д. Виртуальный мир по определению будет иметь больше ограничений, чем мир, в котором он симулируется (потому что банально атомов не хватит на симуляцию), и мы можем лишь смириться с этими ограничениями.
>>20533
Ну вот ты рассуждаешь о сложности, но оправдана ли эта сложность? Зачем это всё будет делать тот абстрактный гений, который может это всё сделать? Можно же просто заготовить "статичных" мешей и комбинировать их друг с другом. Чем больше вариантов мешей и чем больше возможностей по их комбинации, тем больше в результате вариантов процедурной генерации. И практически бесплатно как по умственным затратам, так и по производительности компьютера. И симуляция получается полноценная, если ты делаешь игру, а не научный проект по симуляции человеческого тела со всеми органами и тканями в соответствии с реальной физикой и химией.
2 Мб, 1920x1080>>20536
Это скорее про комбинаторику.
Блять, не перегибай, а. Ладно, это надо на примере точном пояснить но их еще не придумали.
Вот тебе пример на словах, я уже заебался всем пояснять если честно:
У нас есть стандартная парам. моделька существа, ну по детализации как на пике. Начнем с простого, то есть того что ещё можно как-то сделать чисто на мешах + текстурках. Рост, жирность, мускулатура, фейсморфинг, размер ЖОПЫ, тонкая настройка шейпа тела и т.д. Хуй даже с ним, одежду можно еще адаптировать под все эти формы тела. Но дальше у нас идёт модификаторы, например сделать большой разрез от удара, удалить конечность, добавить мутации, из за которых очень сильно меняется форма головы (морда вырастает), появляются на ебле галочки от этих щупалец из за того что "пообщался" с тнёй из какого-то космоборделя. Горб нахуй, левая нога разделяется на 3 ноги нахуй (простые анимации которые на разные типы конечностей тут https://youtu.be/KLjTU0yKS00). Хвост, втора бошка из жопы, потом еще надо под каждую мутацию прописать правила морфинга одежды, чтобы она где-то рвалась, где-то рукав новый генерился. Идём дальше. Мы двух существ разной формы скрещиваем, и теперь у них еще вся биомеханика перемешана рандомно, потом накладываем киберулучшения, КАМЕННАЯ БОЛЕЗНЬ (срака становится по текстуре и форме как камень). Дыра в груди, чтобы удобнее здороваться с теми кто за спиной. 40 ног, теперь ты сороконожка ебать. И всё это в безконечноых генетико-кибернетических вариациях которые опять же нативно более менее будут работать, сделай только скелет модульным.
И че бля? ты думаешь это всё можно сделать простыми мешами? Гонишь нахуй? Я специально такой шизоидный пример выдал потому что надо понимать что потенциал визуального отображения всей хуйни в играх вообще можно сказать в зачаточном состоянии нахдится. Много серпантина но реально странных и интересных комбинаций практически не водится. И это я еще не говори лпро разные виды предметов которые по схожей технологии могут генериться. лезвие меча будет искажаться согласно тому материалу из которого оно сделано. Например из кварца, или камня, и это не просто текстурка а именно сама модель грубой становится. Или вообще прямо внутри игры на изи сделать вытачивание кирок блять самому. Моделлинг прямо в игре нахуй.
И это только начало потенциального безумия.
Еще есть сомнения?
>А кто сказал, что "реальная симуляция" - это обязательно процедурно генерируемые меши?
Это скорее про комбинаторику.
>Во-вторых, кто сказал, что в симуляции должны быть миллионы миллионов миллионов вариантов одного камня на дороге
>Ну вот ты рассуждаешь о сложности, но оправдана ли эта сложность?
Блять, не перегибай, а. Ладно, это надо на примере точном пояснить но их еще не придумали.
Вот тебе пример на словах, я уже заебался всем пояснять если честно:
У нас есть стандартная парам. моделька существа, ну по детализации как на пике. Начнем с простого, то есть того что ещё можно как-то сделать чисто на мешах + текстурках. Рост, жирность, мускулатура, фейсморфинг, размер ЖОПЫ, тонкая настройка шейпа тела и т.д. Хуй даже с ним, одежду можно еще адаптировать под все эти формы тела. Но дальше у нас идёт модификаторы, например сделать большой разрез от удара, удалить конечность, добавить мутации, из за которых очень сильно меняется форма головы (морда вырастает), появляются на ебле галочки от этих щупалец из за того что "пообщался" с тнёй из какого-то космоборделя. Горб нахуй, левая нога разделяется на 3 ноги нахуй (простые анимации которые на разные типы конечностей тут https://youtu.be/KLjTU0yKS00). Хвост, втора бошка из жопы, потом еще надо под каждую мутацию прописать правила морфинга одежды, чтобы она где-то рвалась, где-то рукав новый генерился. Идём дальше. Мы двух существ разной формы скрещиваем, и теперь у них еще вся биомеханика перемешана рандомно, потом накладываем киберулучшения, КАМЕННАЯ БОЛЕЗНЬ (срака становится по текстуре и форме как камень). Дыра в груди, чтобы удобнее здороваться с теми кто за спиной. 40 ног, теперь ты сороконожка ебать. И всё это в безконечноых генетико-кибернетических вариациях которые опять же нативно более менее будут работать, сделай только скелет модульным.
И че бля? ты думаешь это всё можно сделать простыми мешами? Гонишь нахуй? Я специально такой шизоидный пример выдал потому что надо понимать что потенциал визуального отображения всей хуйни в играх вообще можно сказать в зачаточном состоянии нахдится. Много серпантина но реально странных и интересных комбинаций практически не водится. И это я еще не говори лпро разные виды предметов которые по схожей технологии могут генериться. лезвие меча будет искажаться согласно тому материалу из которого оно сделано. Например из кварца, или камня, и это не просто текстурка а именно сама модель грубой становится. Или вообще прямо внутри игры на изи сделать вытачивание кирок блять самому. Моделлинг прямо в игре нахуй.
И это только начало потенциального безумия.
Еще есть сомнения?
2 Мб, 1920x1080>>20536
Это скорее про комбинаторику.
Блять, не перегибай, а. Ладно, это надо на примере точном пояснить но их еще не придумали.
Вот тебе пример на словах, я уже заебался всем пояснять если честно:
У нас есть стандартная парам. моделька существа, ну по детализации как на пике. Начнем с простого, то есть того что ещё можно как-то сделать чисто на мешах + текстурках. Рост, жирность, мускулатура, фейсморфинг, размер ЖОПЫ, тонкая настройка шейпа тела и т.д. Хуй даже с ним, одежду можно еще адаптировать под все эти формы тела. Но дальше у нас идёт модификаторы, например сделать большой разрез от удара, удалить конечность, добавить мутации, из за которых очень сильно меняется форма головы (морда вырастает), появляются на ебле галочки от этих щупалец из за того что "пообщался" с тнёй из какого-то космоборделя. Горб нахуй, левая нога разделяется на 3 ноги нахуй (простые анимации которые на разные типы конечностей тут https://youtu.be/KLjTU0yKS00). Хвост, втора бошка из жопы, потом еще надо под каждую мутацию прописать правила морфинга одежды, чтобы она где-то рвалась, где-то рукав новый генерился. Идём дальше. Мы двух существ разной формы скрещиваем, и теперь у них еще вся биомеханика перемешана рандомно, потом накладываем киберулучшения, КАМЕННАЯ БОЛЕЗНЬ (срака становится по текстуре и форме как камень). Дыра в груди, чтобы удобнее здороваться с теми кто за спиной. 40 ног, теперь ты сороконожка ебать. И всё это в безконечноых генетико-кибернетических вариациях которые опять же нативно более менее будут работать, сделай только скелет модульным.
И че бля? ты думаешь это всё можно сделать простыми мешами? Гонишь нахуй? Я специально такой шизоидный пример выдал потому что надо понимать что потенциал визуального отображения всей хуйни в играх вообще можно сказать в зачаточном состоянии нахдится. Много серпантина но реально странных и интересных комбинаций практически не водится. И это я еще не говори лпро разные виды предметов которые по схожей технологии могут генериться. лезвие меча будет искажаться согласно тому материалу из которого оно сделано. Например из кварца, или камня, и это не просто текстурка а именно сама модель грубой становится. Или вообще прямо внутри игры на изи сделать вытачивание кирок блять самому. Моделлинг прямо в игре нахуй.
И это только начало потенциального безумия.
Еще есть сомнения?
>А кто сказал, что "реальная симуляция" - это обязательно процедурно генерируемые меши?
Это скорее про комбинаторику.
>Во-вторых, кто сказал, что в симуляции должны быть миллионы миллионов миллионов вариантов одного камня на дороге
>Ну вот ты рассуждаешь о сложности, но оправдана ли эта сложность?
Блять, не перегибай, а. Ладно, это надо на примере точном пояснить но их еще не придумали.
Вот тебе пример на словах, я уже заебался всем пояснять если честно:
У нас есть стандартная парам. моделька существа, ну по детализации как на пике. Начнем с простого, то есть того что ещё можно как-то сделать чисто на мешах + текстурках. Рост, жирность, мускулатура, фейсморфинг, размер ЖОПЫ, тонкая настройка шейпа тела и т.д. Хуй даже с ним, одежду можно еще адаптировать под все эти формы тела. Но дальше у нас идёт модификаторы, например сделать большой разрез от удара, удалить конечность, добавить мутации, из за которых очень сильно меняется форма головы (морда вырастает), появляются на ебле галочки от этих щупалец из за того что "пообщался" с тнёй из какого-то космоборделя. Горб нахуй, левая нога разделяется на 3 ноги нахуй (простые анимации которые на разные типы конечностей тут https://youtu.be/KLjTU0yKS00). Хвост, втора бошка из жопы, потом еще надо под каждую мутацию прописать правила морфинга одежды, чтобы она где-то рвалась, где-то рукав новый генерился. Идём дальше. Мы двух существ разной формы скрещиваем, и теперь у них еще вся биомеханика перемешана рандомно, потом накладываем киберулучшения, КАМЕННАЯ БОЛЕЗНЬ (срака становится по текстуре и форме как камень). Дыра в груди, чтобы удобнее здороваться с теми кто за спиной. 40 ног, теперь ты сороконожка ебать. И всё это в безконечноых генетико-кибернетических вариациях которые опять же нативно более менее будут работать, сделай только скелет модульным.
И че бля? ты думаешь это всё можно сделать простыми мешами? Гонишь нахуй? Я специально такой шизоидный пример выдал потому что надо понимать что потенциал визуального отображения всей хуйни в играх вообще можно сказать в зачаточном состоянии нахдится. Много серпантина но реально странных и интересных комбинаций практически не водится. И это я еще не говори лпро разные виды предметов которые по схожей технологии могут генериться. лезвие меча будет искажаться согласно тому материалу из которого оно сделано. Например из кварца, или камня, и это не просто текстурка а именно сама модель грубой становится. Или вообще прямо внутри игры на изи сделать вытачивание кирок блять самому. Моделлинг прямо в игре нахуй.
И это только начало потенциального безумия.
Еще есть сомнения?
>>20516
Да, можно. Выбирай, от кого наследоваться:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Если класс-предок не указывать, по умолчанию считается, что ты наследуешься от Reference.
По сути любой твой скрипт на GDScript - это класс. Просто по умолчанию он безымянный. Ему можно дать имя в заголовке:
Также можно создавать локальные классы:
Такой класс будет легкодоступен внутри класса, в котором объявлен, а из других скриптов обращаться можно будет так:
Конечно, создаёшь класс и хранишь в его полях данные. К сожалению, наследоваться от Array/Dictionary нельзя, но есть специальный класс Resource, упрощающий сериализацию и предоставляющий дополнительную фичу - экземпляр такого класса можно создать в инспекторе нод или в файловой системе.
Ты можешь объявить статичные методы:
Доступ к ним будет даже без создания экземпляра класса.
Вместо этого:
Можно будет сделать так:
Также можно создать "синглтон", разместив какой-либо скрипт, наследующийся от Node или её потомков, в список автозагрузки. Тогда скрипт будет доступен отовсюду по уникальному имени и сможет изменять своё состояние (статичные не могут).
Смотря что ты подразумеваешь под "полноценной поддержкой". Следовать принципам ООП можно на любом ЯП.
GDScript динамически типизированный по умолчанию, хотя ты можешь указывать типы, чтобы иметь больше контроля. Т.е. пока ты явно не указываешь тип аргумента функции, она может принимать в себя что угодно. Внутри функции ты можешь делать проверки на тип, и соответственно менять поведение:
И т.д. Но всё же рекомендую по возможности везде указывать типы, это сэкономит тебе кучу времени на поиск ошибок, а также во многих местах добавит всплывающие подсказки (без указания типа редактор не знает, что именно подсказывать). По той же причине иногда выгодно указывать имя собственного класса через class_name (но лишний раз называть скрипты не нужно).
>Можно ли на gdscript писать самостоятельный код, не привязанный к нодам
Да, можно. Выбирай, от кого наследоваться:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Если класс-предок не указывать, по умолчанию считается, что ты наследуешься от Reference.
>создавать свои классы
По сути любой твой скрипт на GDScript - это класс. Просто по умолчанию он безымянный. Ему можно дать имя в заголовке:
>class_name MyOwnClass
Также можно создавать локальные классы:
>class MyInnerClass
Такой класс будет легкодоступен внутри класса, в котором объявлен, а из других скриптов обращаться можно будет так:
>MyOwnClass.MyInnerClass
>структуры данных
Конечно, создаёшь класс и хранишь в его полях данные. К сожалению, наследоваться от Array/Dictionary нельзя, но есть специальный класс Resource, упрощающий сериализацию и предоставляющий дополнительную фичу - экземпляр такого класса можно создать в инспекторе нод или в файловой системе.
>библиотеки
Ты можешь объявить статичные методы:
>static func my_func() -> Vector2: return Vector2(2, 4)
Доступ к ним будет даже без создания экземпляра класса.
Вместо этого:
>var c := MyClass.new(); var v := c.my_func()
Можно будет сделать так:
>var v := MyClass.my_func()
Также можно создать "синглтон", разместив какой-либо скрипт, наследующийся от Node или её потомков, в список автозагрузки. Тогда скрипт будет доступен отовсюду по уникальному имени и сможет изменять своё состояние (статичные не могут).
>Есть ли там полноценная поддержка ООП
Смотря что ты подразумеваешь под "полноценной поддержкой". Следовать принципам ООП можно на любом ЯП.
>обобщенного программирования
GDScript динамически типизированный по умолчанию, хотя ты можешь указывать типы, чтобы иметь больше контроля. Т.е. пока ты явно не указываешь тип аргумента функции, она может принимать в себя что угодно. Внутри функции ты можешь делать проверки на тип, и соответственно менять поведение:
>func my_func(value):
>_ if value is String:
>_ _ print(value + "!")
>_ if value is float:
>_ _ print(pow(float, 2))
И т.д. Но всё же рекомендую по возможности везде указывать типы, это сэкономит тебе кучу времени на поиск ошибок, а также во многих местах добавит всплывающие подсказки (без указания типа редактор не знает, что именно подсказывать). По той же причине иногда выгодно указывать имя собственного класса через class_name (но лишний раз называть скрипты не нужно).
>>20516
Да, можно. Выбирай, от кого наследоваться:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Если класс-предок не указывать, по умолчанию считается, что ты наследуешься от Reference.
По сути любой твой скрипт на GDScript - это класс. Просто по умолчанию он безымянный. Ему можно дать имя в заголовке:
Также можно создавать локальные классы:
Такой класс будет легкодоступен внутри класса, в котором объявлен, а из других скриптов обращаться можно будет так:
Конечно, создаёшь класс и хранишь в его полях данные. К сожалению, наследоваться от Array/Dictionary нельзя, но есть специальный класс Resource, упрощающий сериализацию и предоставляющий дополнительную фичу - экземпляр такого класса можно создать в инспекторе нод или в файловой системе.
Ты можешь объявить статичные методы:
Доступ к ним будет даже без создания экземпляра класса.
Вместо этого:
Можно будет сделать так:
Также можно создать "синглтон", разместив какой-либо скрипт, наследующийся от Node или её потомков, в список автозагрузки. Тогда скрипт будет доступен отовсюду по уникальному имени и сможет изменять своё состояние (статичные не могут).
Смотря что ты подразумеваешь под "полноценной поддержкой". Следовать принципам ООП можно на любом ЯП.
GDScript динамически типизированный по умолчанию, хотя ты можешь указывать типы, чтобы иметь больше контроля. Т.е. пока ты явно не указываешь тип аргумента функции, она может принимать в себя что угодно. Внутри функции ты можешь делать проверки на тип, и соответственно менять поведение:
И т.д. Но всё же рекомендую по возможности везде указывать типы, это сэкономит тебе кучу времени на поиск ошибок, а также во многих местах добавит всплывающие подсказки (без указания типа редактор не знает, что именно подсказывать). По той же причине иногда выгодно указывать имя собственного класса через class_name (но лишний раз называть скрипты не нужно).
>Можно ли на gdscript писать самостоятельный код, не привязанный к нодам
Да, можно. Выбирай, от кого наследоваться:
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Если класс-предок не указывать, по умолчанию считается, что ты наследуешься от Reference.
>создавать свои классы
По сути любой твой скрипт на GDScript - это класс. Просто по умолчанию он безымянный. Ему можно дать имя в заголовке:
>class_name MyOwnClass
Также можно создавать локальные классы:
>class MyInnerClass
Такой класс будет легкодоступен внутри класса, в котором объявлен, а из других скриптов обращаться можно будет так:
>MyOwnClass.MyInnerClass
>структуры данных
Конечно, создаёшь класс и хранишь в его полях данные. К сожалению, наследоваться от Array/Dictionary нельзя, но есть специальный класс Resource, упрощающий сериализацию и предоставляющий дополнительную фичу - экземпляр такого класса можно создать в инспекторе нод или в файловой системе.
>библиотеки
Ты можешь объявить статичные методы:
>static func my_func() -> Vector2: return Vector2(2, 4)
Доступ к ним будет даже без создания экземпляра класса.
Вместо этого:
>var c := MyClass.new(); var v := c.my_func()
Можно будет сделать так:
>var v := MyClass.my_func()
Также можно создать "синглтон", разместив какой-либо скрипт, наследующийся от Node или её потомков, в список автозагрузки. Тогда скрипт будет доступен отовсюду по уникальному имени и сможет изменять своё состояние (статичные не могут).
>Есть ли там полноценная поддержка ООП
Смотря что ты подразумеваешь под "полноценной поддержкой". Следовать принципам ООП можно на любом ЯП.
>обобщенного программирования
GDScript динамически типизированный по умолчанию, хотя ты можешь указывать типы, чтобы иметь больше контроля. Т.е. пока ты явно не указываешь тип аргумента функции, она может принимать в себя что угодно. Внутри функции ты можешь делать проверки на тип, и соответственно менять поведение:
>func my_func(value):
>_ if value is String:
>_ _ print(value + "!")
>_ if value is float:
>_ _ print(pow(float, 2))
И т.д. Но всё же рекомендую по возможности везде указывать типы, это сэкономит тебе кучу времени на поиск ошибок, а также во многих местах добавит всплывающие подсказки (без указания типа редактор не знает, что именно подсказывать). По той же причине иногда выгодно указывать имя собственного класса через class_name (но лишний раз называть скрипты не нужно).
>>20541
Какое-то кирилльство. Ты забыл упомянуть, что если один глаз потерять, экран наполовину темнеет... Без обид)
Нет, я думаю, что это всё НИНУЖНО в играх. Ты описываешь какую-то вундервафлю... Проще было бы сказать "весь мир из атомов и атомы следуют ИРЛ законам физики". Это сразу решило бы все проблемы и ответило бы на все вопросы, кроме проблемы ограниченных компьютерных ресурсов.
А ты играл когда-нибудь в Kerbal Space Program? У тебя достаточно мощный ПК? Впрочем, не важно. Это лоуполи игра с мультяшными текстурами из нулевых, которая тормозит и крашится на топовых ПК ютуберов, пытаясь справиться с симуляцией космического корабля из небольшого количества "статичных" блоков. Если игра не крашится, то что-нибудь спонтанно взрывается и персонажи погибают. А планета, с которой мы стартуем - по сути голый шар, кроме сооружений вокруг стартовой площадки ничего тяжёлого там нет.
Представь, что было бы, если бы ты реализовал все свои идеи на базе такого полноценного симулятора? Нихрена бы не было, у тебя бы никакого топового железа не хватило бы, чтобы такое запустить в реальном времени. Да и зачем оно нужно...
А тем временем в KSP наигрывают сотни часов даже без модов. И получают удовольствие. Ну и смысл делать всех этих процедурно генерируемых пришельцев, если одна, повторюсь, ОДНА моделька кербонавта совершенно спокойно справляется со всеми задачами, поставленными перед данным симулятором?
Т.е. возвращаемся к
Ладно, а почему "грубая модель" лучше, чем "просто текстура"? Визуально разницы ты не заметишь, а физический материал никак с визуальной моделью не соотносится.
Какой-то бессмысленный спор, я уже не понимаю, зачем мы об этом спорим здесь. С чего всё началось?.. >>814352 →
Ага, ясно. Прошло уже две недели, ты что-нибудь сделал? Попробовал хотя бы несколько своих Creature создать, как я (вроде бы) советовал для начала? Мне любопытно наблюдать за проектами симуляторов, но ты чёт перешёл с симуляторов на графодрочинг...
>модификаторы, например сделать большой разрез от удара, удалить конечность, добавить мутации, из за которых очень сильно меняется форма головы (морда вырастает)
Какое-то кирилльство. Ты забыл упомянуть, что если один глаз потерять, экран наполовину темнеет... Без обид)
>ты думаешь это всё можно сделать простыми мешами?
Нет, я думаю, что это всё НИНУЖНО в играх. Ты описываешь какую-то вундервафлю... Проще было бы сказать "весь мир из атомов и атомы следуют ИРЛ законам физики". Это сразу решило бы все проблемы и ответило бы на все вопросы, кроме проблемы ограниченных компьютерных ресурсов.
>потенциал визуального отображения
>в зачаточном состоянии нахдится.
А ты играл когда-нибудь в Kerbal Space Program? У тебя достаточно мощный ПК? Впрочем, не важно. Это лоуполи игра с мультяшными текстурами из нулевых, которая тормозит и крашится на топовых ПК ютуберов, пытаясь справиться с симуляцией космического корабля из небольшого количества "статичных" блоков. Если игра не крашится, то что-нибудь спонтанно взрывается и персонажи погибают. А планета, с которой мы стартуем - по сути голый шар, кроме сооружений вокруг стартовой площадки ничего тяжёлого там нет.
Представь, что было бы, если бы ты реализовал все свои идеи на базе такого полноценного симулятора? Нихрена бы не было, у тебя бы никакого топового железа не хватило бы, чтобы такое запустить в реальном времени. Да и зачем оно нужно...
А тем временем в KSP наигрывают сотни часов даже без модов. И получают удовольствие. Ну и смысл делать всех этих процедурно генерируемых пришельцев, если одна, повторюсь, ОДНА моделька кербонавта совершенно спокойно справляется со всеми задачами, поставленными перед данным симулятором?
Т.е. возвращаемся к
>оправдана ли эта сложность?
>это не просто текстурка а именно сама модель грубой становится
Ладно, а почему "грубая модель" лучше, чем "просто текстура"? Визуально разницы ты не заметишь, а физический материал никак с визуальной моделью не соотносится.
Какой-то бессмысленный спор, я уже не понимаю, зачем мы об этом спорим здесь. С чего всё началось?.. >>814352 →
>06/07/22
>Насколько сильно ноды влияют на память? Например у меня условно будет Creature, который будет через композицию/агрегацию состоять из 15-30 нод...
Ага, ясно. Прошло уже две недели, ты что-нибудь сделал? Попробовал хотя бы несколько своих Creature создать, как я (вроде бы) советовал для начала? Мне любопытно наблюдать за проектами симуляторов, но ты чёт перешёл с симуляторов на графодрочинг...
>>20541
Какое-то кирилльство. Ты забыл упомянуть, что если один глаз потерять, экран наполовину темнеет... Без обид)
Нет, я думаю, что это всё НИНУЖНО в играх. Ты описываешь какую-то вундервафлю... Проще было бы сказать "весь мир из атомов и атомы следуют ИРЛ законам физики". Это сразу решило бы все проблемы и ответило бы на все вопросы, кроме проблемы ограниченных компьютерных ресурсов.
А ты играл когда-нибудь в Kerbal Space Program? У тебя достаточно мощный ПК? Впрочем, не важно. Это лоуполи игра с мультяшными текстурами из нулевых, которая тормозит и крашится на топовых ПК ютуберов, пытаясь справиться с симуляцией космического корабля из небольшого количества "статичных" блоков. Если игра не крашится, то что-нибудь спонтанно взрывается и персонажи погибают. А планета, с которой мы стартуем - по сути голый шар, кроме сооружений вокруг стартовой площадки ничего тяжёлого там нет.
Представь, что было бы, если бы ты реализовал все свои идеи на базе такого полноценного симулятора? Нихрена бы не было, у тебя бы никакого топового железа не хватило бы, чтобы такое запустить в реальном времени. Да и зачем оно нужно...
А тем временем в KSP наигрывают сотни часов даже без модов. И получают удовольствие. Ну и смысл делать всех этих процедурно генерируемых пришельцев, если одна, повторюсь, ОДНА моделька кербонавта совершенно спокойно справляется со всеми задачами, поставленными перед данным симулятором?
Т.е. возвращаемся к
Ладно, а почему "грубая модель" лучше, чем "просто текстура"? Визуально разницы ты не заметишь, а физический материал никак с визуальной моделью не соотносится.
Какой-то бессмысленный спор, я уже не понимаю, зачем мы об этом спорим здесь. С чего всё началось?.. >>814352 →
Ага, ясно. Прошло уже две недели, ты что-нибудь сделал? Попробовал хотя бы несколько своих Creature создать, как я (вроде бы) советовал для начала? Мне любопытно наблюдать за проектами симуляторов, но ты чёт перешёл с симуляторов на графодрочинг...
>модификаторы, например сделать большой разрез от удара, удалить конечность, добавить мутации, из за которых очень сильно меняется форма головы (морда вырастает)
Какое-то кирилльство. Ты забыл упомянуть, что если один глаз потерять, экран наполовину темнеет... Без обид)
>ты думаешь это всё можно сделать простыми мешами?
Нет, я думаю, что это всё НИНУЖНО в играх. Ты описываешь какую-то вундервафлю... Проще было бы сказать "весь мир из атомов и атомы следуют ИРЛ законам физики". Это сразу решило бы все проблемы и ответило бы на все вопросы, кроме проблемы ограниченных компьютерных ресурсов.
>потенциал визуального отображения
>в зачаточном состоянии нахдится.
А ты играл когда-нибудь в Kerbal Space Program? У тебя достаточно мощный ПК? Впрочем, не важно. Это лоуполи игра с мультяшными текстурами из нулевых, которая тормозит и крашится на топовых ПК ютуберов, пытаясь справиться с симуляцией космического корабля из небольшого количества "статичных" блоков. Если игра не крашится, то что-нибудь спонтанно взрывается и персонажи погибают. А планета, с которой мы стартуем - по сути голый шар, кроме сооружений вокруг стартовой площадки ничего тяжёлого там нет.
Представь, что было бы, если бы ты реализовал все свои идеи на базе такого полноценного симулятора? Нихрена бы не было, у тебя бы никакого топового железа не хватило бы, чтобы такое запустить в реальном времени. Да и зачем оно нужно...
А тем временем в KSP наигрывают сотни часов даже без модов. И получают удовольствие. Ну и смысл делать всех этих процедурно генерируемых пришельцев, если одна, повторюсь, ОДНА моделька кербонавта совершенно спокойно справляется со всеми задачами, поставленными перед данным симулятором?
Т.е. возвращаемся к
>оправдана ли эта сложность?
>это не просто текстурка а именно сама модель грубой становится
Ладно, а почему "грубая модель" лучше, чем "просто текстура"? Визуально разницы ты не заметишь, а физический материал никак с визуальной моделью не соотносится.
Какой-то бессмысленный спор, я уже не понимаю, зачем мы об этом спорим здесь. С чего всё началось?.. >>814352 →
>06/07/22
>Насколько сильно ноды влияют на память? Например у меня условно будет Creature, который будет через композицию/агрегацию состоять из 15-30 нод...
Ага, ясно. Прошло уже две недели, ты что-нибудь сделал? Попробовал хотя бы несколько своих Creature создать, как я (вроде бы) советовал для начала? Мне любопытно наблюдать за проектами симуляторов, но ты чёт перешёл с симуляторов на графодрочинг...
>>20548
Офк нет, я занят был, работал. Но советы твои записал.
>Прошло уже две недели, ты что-нибудь сделал?
Офк нет, я занят был, работал. Но советы твои записал.
>>20542
Понятно, буду пробовать.
Понятно, буду пробовать.
>>20140
Сохранение-загрузка.
Потому что данные это таблицы, а сущности это объекты.
Например: Загрузилась локация, подняла из БД данные, сконфигурировалась, отправилась игроку на экран. Это происходит достаточно часто, чтобы задуматься об оптимизации получения данных с диска.
> Опиши ситуацию, в которой тебе в игре необходимо создавать такие запросы всего раз за всю игру?
Сохранение-загрузка.
> И почему ты не можешь заранее отсортировать свои данные по массивам, которые тебе в любом случае потребуется хранить в оперативной памяти?
Потому что данные это таблицы, а сущности это объекты.
> По-моему, необходимость в SQL в игре может возникнуть только из-за плохой архитектуры игры. Когда, например, какой-то код каждый раз грузит с диска и сортирует список предметов, хотя по-хорошему он этого делать никогда не должен.
Например: Загрузилась локация, подняла из БД данные, сконфигурировалась, отправилась игроку на экран. Это происходит достаточно часто, чтобы задуматься об оптимизации получения данных с диска.
>>20542
Автозагрузка это одно, а "синглтон" это другое, это неудачно названная опция элементов автозагрузки, при которой элементу с опцией "синглтон" выделяется глобальное имя в редакторе скриптов.
Синглтоном это не является.
Синглтон, это когда ты в рамках одного выполнения программы пишешь:
потом в другом совершенно месте пишешь:
И у тебя переменные s1 и s2 содержат ссылку на один и тот же экземпляр. Вот это синглтон. В гдскрипте такой фичи, насколько я знаю, нет. Однако, при задании опции "синглтон" в автозагрузке, мы получаем аналогичное левой части вышеприведенных выражений. Мы получаем уникальную глобальную переменную, ссылающуюся на одну конкретную ноду в дереве.
Но!
Это всё ещё просто нода в дереве, ты можешь обратиться к ней по её пути в дереве. get_tree().get_node("MyPseudoSingleton") как-то так.
> Также можно создать "синглтон", разместив какой-либо скрипт, наследующийся от Node или её потомков, в список автозагрузки.
Автозагрузка это одно, а "синглтон" это другое, это неудачно названная опция элементов автозагрузки, при которой элементу с опцией "синглтон" выделяется глобальное имя в редакторе скриптов.
Синглтоном это не является.
Синглтон, это когда ты в рамках одного выполнения программы пишешь:
> var s1 = MySingleClass.new()
потом в другом совершенно месте пишешь:
> var s2 = MySingleClass.new()
И у тебя переменные s1 и s2 содержат ссылку на один и тот же экземпляр. Вот это синглтон. В гдскрипте такой фичи, насколько я знаю, нет. Однако, при задании опции "синглтон" в автозагрузке, мы получаем аналогичное левой части вышеприведенных выражений. Мы получаем уникальную глобальную переменную, ссылающуюся на одну конкретную ноду в дереве.
Но!
Это всё ещё просто нода в дереве, ты можешь обратиться к ней по её пути в дереве. get_tree().get_node("MyPseudoSingleton") как-то так.
>>20654
Кстати, в текущей версии движка эту оплошность исправили и переименовали опцию. Теперь нет никаких синглтонов. Нет антипаттерна. Юзайте на здоровье.
Кстати, в текущей версии движка эту оплошность исправили и переименовали опцию. Теперь нет никаких синглтонов. Нет антипаттерна. Юзайте на здоровье.
47 Кб, 824x618Привет, годоти. Хочу попробовать сделать свою приложуху на этой опенсорсной йобе, такой вопросик, можно как-то импортировать collada, что бы можно было у отдельных мешей присутствовали их ID ? А то у меня в движке node1, node2, node3.... итд. ИД нигде не вижу.
>>20663
У тебя там везде стоит name="node", но поскольку имена соседних нод должны быть уникальны, он добавляет к ним индекс по порядку добавления в сцену. Если хочешь уникальные имена нод, которые всегда будут одинаковы, переименуй свои ноды в том 3D редакторе, который ты используешь.
Алсо, если не ошибаюсь, Godot лучше всего поддерживает GLTF, и его рекомендуют использовать в документации. При экспорте из Blender все имена нод сохраняются.
>А то у меня в движке node1, node2, node3...
У тебя там везде стоит name="node", но поскольку имена соседних нод должны быть уникальны, он добавляет к ним индекс по порядку добавления в сцену. Если хочешь уникальные имена нод, которые всегда будут одинаковы, переименуй свои ноды в том 3D редакторе, который ты используешь.
Алсо, если не ошибаюсь, Godot лучше всего поддерживает GLTF, и его рекомендуют использовать в документации. При экспорте из Blender все имена нод сохраняются.
>>20654
Ну не знаю, я всегда считал синглтоном глобальный экземпляр класса, который ты никогда и нигде не создаёшь, потому что он создаётся всего один раз автоматически.
Т.е. вот это:
Я считаю нонсенсом. В смысле, как ты можешь создать синглтон, если он по определению должен быть несоздаваем?
Думаю, тут разница в том, каким способом получается ссылка на этот экземпляр. Ты предлагаешь получать ссылку через .new(), я же считаю это нонсенсом, ведь ты буквально говоришь:
А в ответ получаешь ссылку на ПОДЕРЖАННЫЙ экземпляр, который юзали до тебя 100500 раз, но ты об этом НЕ ЗНАЕШЬ, потому что ты ясно и чётко запрашивал НОВЫЙ экземпляр.
Ну и зачем это нужно тогда? Только чтобы запутать код? Лучше условиться заранее, что ты никогда и ни при каких условиях не создаёшь экземпляр класса, обращаясь только к глобальному экземпляру этого класса. И всё будет ясно - ты однозначно обращаешься к подержанному экземпляру, который юзали до тебя много раз, и ты это ЗНАЕШЬ.
Другое дело, что глобальные переменные превращают код в лапшу, следовательно, синглтоны тоже превращают код в лапшу, следовательно, использовать их вредно.
>И у тебя переменные s1 и s2 содержат ссылку на один и тот же экземпляр. Вот это синглтон.
Ну не знаю, я всегда считал синглтоном глобальный экземпляр класса, который ты никогда и нигде не создаёшь, потому что он создаётся всего один раз автоматически.
Т.е. вот это:
>var s1 = MySingleClass.new()
>var s2 = MySingleClass.new()
Я считаю нонсенсом. В смысле, как ты можешь создать синглтон, если он по определению должен быть несоздаваем?
Думаю, тут разница в том, каким способом получается ссылка на этот экземпляр. Ты предлагаешь получать ссылку через .new(), я же считаю это нонсенсом, ведь ты буквально говоришь:
>Эй, предоставьте мне НОВЫЙ экземпляр класса MySingleClass, мне нужен НОВЫЙ экземпляр, заранее спасибо.
А в ответ получаешь ссылку на ПОДЕРЖАННЫЙ экземпляр, который юзали до тебя 100500 раз, но ты об этом НЕ ЗНАЕШЬ, потому что ты ясно и чётко запрашивал НОВЫЙ экземпляр.
Ну и зачем это нужно тогда? Только чтобы запутать код? Лучше условиться заранее, что ты никогда и ни при каких условиях не создаёшь экземпляр класса, обращаясь только к глобальному экземпляру этого класса. И всё будет ясно - ты однозначно обращаешься к подержанному экземпляру, который юзали до тебя много раз, и ты это ЗНАЕШЬ.
Другое дело, что глобальные переменные превращают код в лапшу, следовательно, синглтоны тоже превращают код в лапшу, следовательно, использовать их вредно.
>>20651
Так Godot ведь уже всё оптимизирует в этом плане. Все текстуры, меши и прочие ресурсы считываются с диска всего один раз, если специально не задать игнорирование кэша. Конфигурацию ты тоже можешь хранить в Resource, или там ещё где, не вижу смысла поднимать громоздкую СУБД ради пары строчек конфигурации.
И потом, ну сколько у тебя будет мегабайт конфигурации? Попробуй хотя бы до одного мегабайта дойти (примерно миллион символов), прежде чем задумываться об оптимизациях. Оптимизировать нужно текстуры и прочий мусор, чтоб игру не раздувало до 100 ГБ, а конфигурации у тебя никогда не будет так уж много.
Ты ж не сервер гугл, с петабайтами данных. У тебя и текстурок может на гигабайт не вывесить, если будешь экономить.
>Загрузилась локация, подняла из БД данные, сконфигурировалась, отправилась игроку на экран. Это происходит достаточно часто, чтобы задуматься об оптимизации получения данных с диска.
Так Godot ведь уже всё оптимизирует в этом плане. Все текстуры, меши и прочие ресурсы считываются с диска всего один раз, если специально не задать игнорирование кэша. Конфигурацию ты тоже можешь хранить в Resource, или там ещё где, не вижу смысла поднимать громоздкую СУБД ради пары строчек конфигурации.
И потом, ну сколько у тебя будет мегабайт конфигурации? Попробуй хотя бы до одного мегабайта дойти (примерно миллион символов), прежде чем задумываться об оптимизациях. Оптимизировать нужно текстуры и прочий мусор, чтоб игру не раздувало до 100 ГБ, а конфигурации у тебя никогда не будет так уж много.
Ты ж не сервер гугл, с петабайтами данных. У тебя и текстурок может на гигабайт не вывесить, если будешь экономить.
>>20694
По сути мне без разницы, как называются сами ноды, но мне хотелось бы получить доступ к их ID из кода. В инспекторе изучая эти ноды я у них нигде в свойствах данные ID не нашел. Почему мне это надо? Суть в том, что из другой проги я получаю 3д модель в виде collada - xml с айди элементов и таблицу параметров, что привязываются по ID к этим элементам. Мне надо через код все это обрабатывать.
По сути мне без разницы, как называются сами ноды, но мне хотелось бы получить доступ к их ID из кода. В инспекторе изучая эти ноды я у них нигде в свойствах данные ID не нашел. Почему мне это надо? Суть в том, что из другой проги я получаю 3д модель в виде collada - xml с айди элементов и таблицу параметров, что привязываются по ID к этим элементам. Мне надо через код все это обрабатывать.
>>20710
А ты можешь в ней задать имена нод, чтобы они были равны ID, которые тебе нужны? Всё равно оригинальные имена ты не используешь, а так будет доступ к ID. Если ты создаёшь таблицу параметров каким-то скриптом, наверняка можешь использовать вместо ID имена или изменять имена на ID.
Потому что в сценах Godot нет таких ID, только имена и порядковые номера. Скорее всего в процессе импорта данные ID игнорируются. Можешь посмотреть исходники, что там как.
>из другой проги я получаю 3д модель
А ты можешь в ней задать имена нод, чтобы они были равны ID, которые тебе нужны? Всё равно оригинальные имена ты не используешь, а так будет доступ к ID. Если ты создаёшь таблицу параметров каким-то скриптом, наверняка можешь использовать вместо ID имена или изменять имена на ID.
>нигде в свойствах данные ID не нашел
Потому что в сценах Godot нет таких ID, только имена и порядковые номера. Скорее всего в процессе импорта данные ID игнорируются. Можешь посмотреть исходники, что там как.
>>20706
В видосике по ссылке даны все ответы. Не можешь в инглиш - включи субтитры с переводом. У меня нет желания тебе видос пересказывать.
В видосике по ссылке даны все ответы. Не можешь в инглиш - включи субтитры с переводом. У меня нет желания тебе видос пересказывать.
Сяп, я новичок. Почему у .fbx формата крестик красный на иконке? Вроде же поддерживает такой формат. Или лучше .obj использовать?
>>20814 >>20815
Я встречал такую иконку, но сам не знаю, что она означает. По идее это должно значить "я не могу отобразить превью из-за ошибки". Возможно, там ошибка с путями, нужно глянуть зависимости (какой материал, какая текстура и т.п.).
Тут подробнее на тему выбора формата:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_scenes.html
Я встречал такую иконку, но сам не знаю, что она означает. По идее это должно значить "я не могу отобразить превью из-за ошибки". Возможно, там ошибка с путями, нужно глянуть зависимости (какой материал, какая текстура и т.п.).
>Или лучше .obj использовать?
Тут подробнее на тему выбора формата:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_scenes.html
>>20818
Написано что хорошая поддержка для gltf.
Я им никогда не пользовался. Не знаешь, он включает в себя пивот, текстуры, скелет?
Написано что хорошая поддержка для gltf.
Я им никогда не пользовался. Не знаешь, он включает в себя пивот, текстуры, скелет?
>>20815
Я тоже такое встречал. Но у меня была проблема с .png файлами. Открой консоль и посмотри чо там пишется. У меня почему-то пнг импортер сломался к хуям во всём проекте (ну тащемта годот 4ая версия, так что д.) По итогу просто снёс все импорты, метаданные по импорту со всего проекта, и всё заработало. Точно не понял в каком месте именно ошибка.
Я тоже такое встречал. Но у меня была проблема с .png файлами. Открой консоль и посмотри чо там пишется. У меня почему-то пнг импортер сломался к хуям во всём проекте (ну тащемта годот 4ая версия, так что д.) По итогу просто снёс все импорты, метаданные по импорту со всего проекта, и всё заработало. Точно не понял в каком месте именно ошибка.
>>20700
Да это раковый шаблон, его даже в книгах по ооп рекомендуют избегать всеми силами.
Да это раковый шаблон, его даже в книгах по ооп рекомендуют избегать всеми силами.
>>20819
Да, если экспортировать по умолчанию, будет вся сцена + текстуры с материалами + анимации скелета и т.д.
Это открытый свободный формат, подробности можно узнать здесь: https://www.khronos.org/gltf/
>gltf
>он включает в себя пивот, текстуры, скелет?
Да, если экспортировать по умолчанию, будет вся сцена + текстуры с материалами + анимации скелета и т.д.
Это открытый свободный формат, подробности можно узнать здесь: https://www.khronos.org/gltf/
А как можно добавить delta из _process() в lerp()?
Вот у меня какое-то вычисление происходит в _process(). Я решил сгладить его с помощью lerp(), вот так:
Но в результате получается, что это выражение сильно зависит от частоты кадров. Если на 60 кадрах нормально (как задумано), на 20 сглаживание слишком сильное, а на 200 - слишком слабое. Значит, нужно куда-то всунуть delta, чтобы была зависимость от времени.
Вопрос - куда? Я попытался изменять percent в зависимости от delta, но он должен оставаться в пределах 0..1, иначе начинаются глюки, а так не получается...
Вот у меня какое-то вычисление происходит в _process(). Я решил сгладить его с помощью lerp(), вот так:
>lerp(v1, v2, percent)
Но в результате получается, что это выражение сильно зависит от частоты кадров. Если на 60 кадрах нормально (как задумано), на 20 сглаживание слишком сильное, а на 200 - слишком слабое. Значит, нужно куда-то всунуть delta, чтобы была зависимость от времени.
Вопрос - куда? Я попытался изменять percent в зависимости от delta, но он должен оставаться в пределах 0..1, иначе начинаются глюки, а так не получается...
Добрейшего вечерочка. Поздравляю вас всех с новым вкатышем(со мной). Помимо двачика, у нас есть какой нибудь уголок? Или все разбежались по своим проектам, а сюда заходят помериться знаниями?
>>21290
Да тысячи их. Но на двачах, насколько я знаю, не принято указывать ссылки на другие форумы.
Да тысячи их. Но на двачах, насколько я знаю, не принято указывать ссылки на другие форумы.
>>21250
1. Почему я должен смотреть видео на 11 минут, где какой-то рандомный чувак настраивает проект с нуля (половину видео) и по буковке (по буковке, анон!) печатает говнокод, не следующий официальному руководству по стилю, если мне нужно всего пару строчек кода узнать?
2. ТАМ НЕТ ИСПОЛЬЗОВАНИЯ lerp()!
>>21285
Спасибо за попытку помочь, но я уже пробовал этот метод. Проблема в том, что тогда быстро возникает выход за 1.
1. Допустим, целевой percent == 0.8 при 60 КВС.
2. 0.8 / (1 / 60) = 48 — это "speed".
3. 48 × (1 / 60) = 0.8 — тут правильно;
4. 48 × (1 / 20) = 2.4 — это слишком много!
5. 48 × (1 / 200) = 0.24 — а это слишком мало...
В общем, в моём коде ощутимые значения начинаются примерно от 0.6~0.7, и становятся невыносимыми примерно на 0.9+. Поэтому мне недостаточно просто перемножить какую-то константу на дельту времени, т.к. дельта способна изменяться в широких пределах.
В теории можно было бы прибить код к скорости физических тиков, но физические тики тоже не гарантированы быть одинаковыми, да и этот код мне нужен для сглаживания камеры, т.е. он должен выполняться как можно чаще/быстрее.
Походу, проще отказаться от этой фичи...
1. Почему я должен смотреть видео на 11 минут, где какой-то рандомный чувак настраивает проект с нуля (половину видео) и по буковке (по буковке, анон!) печатает говнокод, не следующий официальному руководству по стилю, если мне нужно всего пару строчек кода узнать?
2. ТАМ НЕТ ИСПОЛЬЗОВАНИЯ lerp()!
>>21285
Спасибо за попытку помочь, но я уже пробовал этот метод. Проблема в том, что тогда быстро возникает выход за 1.
1. Допустим, целевой percent == 0.8 при 60 КВС.
2. 0.8 / (1 / 60) = 48 — это "speed".
3. 48 × (1 / 60) = 0.8 — тут правильно;
4. 48 × (1 / 20) = 2.4 — это слишком много!
5. 48 × (1 / 200) = 0.24 — а это слишком мало...
В общем, в моём коде ощутимые значения начинаются примерно от 0.6~0.7, и становятся невыносимыми примерно на 0.9+. Поэтому мне недостаточно просто перемножить какую-то константу на дельту времени, т.к. дельта способна изменяться в широких пределах.
В теории можно было бы прибить код к скорости физических тиков, но физические тики тоже не гарантированы быть одинаковыми, да и этот код мне нужен для сглаживания камеры, т.е. он должен выполняться как можно чаще/быстрее.
Походу, проще отказаться от этой фичи...
>>21290
https://godotengine.org/community
Там все ссылки на официальные ресурсы, листай вниз.
Из того, что там нет, это ссылка на стековерфлоу:
https://stackoverflow.com/questions/tagged/godot
Хотя он довольно вялый, не рекомендую.
Мой тебе совет, не фокусируется только на том, что касается Godot. Зачастую ресурсы для других движков и ресурсы для движкописателей могут дать ответ на твои вопросы, или натолкнуть на какую-то идею, или вдохновить. Godot использует популярные подходы к геймдеву. Тебе достаточно разбираться в официальном API движка (см. документацию и чаще пользуйся F1 в редакторе), а всё остальное в той или иной степени легко переносится с движка на движок (даже ассеты, подготовленные для другого движка, но тут придётся иметь знания этого другого движка).
>у нас есть какой нибудь уголок?
https://godotengine.org/community
Там все ссылки на официальные ресурсы, листай вниз.
Из того, что там нет, это ссылка на стековерфлоу:
https://stackoverflow.com/questions/tagged/godot
Хотя он довольно вялый, не рекомендую.
Мой тебе совет, не фокусируется только на том, что касается Godot. Зачастую ресурсы для других движков и ресурсы для движкописателей могут дать ответ на твои вопросы, или натолкнуть на какую-то идею, или вдохновить. Godot использует популярные подходы к геймдеву. Тебе достаточно разбираться в официальном API движка (см. документацию и чаще пользуйся F1 в редакторе), а всё остальное в той или иной степени легко переносится с движка на движок (даже ассеты, подготовленные для другого движка, но тут придётся иметь знания этого другого движка).
>>21416
ну у меня посредственный опыт в программировании и достаточный в рисовании. Так что я думал что надо просто изучить движок до состояния в котором я смогу собрать там игру. А для этого и GDScript надо изучить и в самих приколах движка разобраться.
ну у меня посредственный опыт в программировании и достаточный в рисовании. Так что я думал что надо просто изучить движок до состояния в котором я смогу собрать там игру. А для этого и GDScript надо изучить и в самих приколах движка разобраться.
229 Кб, 800x1200>>18455
https://shikimori.one/animes/48742-kono-healer-mendokusai
Kono Healer, Mendokusai
Сегодня повозился, удалось с ГПУ шейдером, но при попытке загрузки через код виснет, ну и с гуи не всё так просто получается
> Это Carla из Fairy Tail? Что-то не ищется этот арт
https://shikimori.one/animes/48742-kono-healer-mendokusai
Kono Healer, Mendokusai
Сегодня повозился, удалось с ГПУ шейдером, но при попытке загрузки через код виснет, ну и с гуи не всё так просто получается
>>21402
Ты пишешь странные вещи.
1. В камере 2д и так есть опция включить smooth. Там не лерп, а асимптотика, то есть возможны колебания у конечной точки, но это думаю легко закостылить.
Кроме того, раньше была InterpolatedCamera ни ее депрекейтнули. Но легко ищутся аддоны заменяющие ее, с кодом. Там вместо lerp vector.interpolate_with(vectorB, delta x ratio). Но это то же самое. Таким образом, никакой нужды отказываться от плавной камеры ни у кого не возникло.
2. Конда ты используешь deltaT, ты и добавляешь зависимость от частоты кадров. Если у тебя просадка до 20 фпс, то оптимизировать надо ее, а камере то все равно, ей надо за секунду пройти заданное растояние, а поскольку секунда теперь делится не на 60 частей, а на 20, то и получатся что за каждый кадр она пролетает 2.4, а не 0.8, что же тут неправильного? Или ты хочешь делать слоумоушн, но при этом чтобы камера двигалась с той же скоростью?
Впрочем, если тебе непременно надо, то ты можешь сделать clamp от lerp, чтобы результат все равно остался в диапазоне 0.8-0.9, но это все равно глупость какая-то.
Ты пишешь странные вещи.
1. В камере 2д и так есть опция включить smooth. Там не лерп, а асимптотика, то есть возможны колебания у конечной точки, но это думаю легко закостылить.
Кроме того, раньше была InterpolatedCamera ни ее депрекейтнули. Но легко ищутся аддоны заменяющие ее, с кодом. Там вместо lerp vector.interpolate_with(vectorB, delta x ratio). Но это то же самое. Таким образом, никакой нужды отказываться от плавной камеры ни у кого не возникло.
2. Конда ты используешь deltaT, ты и добавляешь зависимость от частоты кадров. Если у тебя просадка до 20 фпс, то оптимизировать надо ее, а камере то все равно, ей надо за секунду пройти заданное растояние, а поскольку секунда теперь делится не на 60 частей, а на 20, то и получатся что за каждый кадр она пролетает 2.4, а не 0.8, что же тут неправильного? Или ты хочешь делать слоумоушн, но при этом чтобы камера двигалась с той же скоростью?
Впрочем, если тебе непременно надо, то ты можешь сделать clamp от lerp, чтобы результат все равно остался в диапазоне 0.8-0.9, но это все равно глупость какая-то.
>>21480
Рекомендую сразу пробовать сделать то, что хочешь сделать. Если не получается, ищи в интернете (или спрашивай здесь), как сделать что-то конкретное. А то если ты будешь всё подряд изучать (включая сетевые протоколы, VR/AR и т.д.), до самой игры дело ещё не скоро дойдёт. Даже если с таким подходом получится плохой код, потом всегда успеешь отрефакторить - главное, что прототип у тебя уже будет работать, пусть и не очень быстро/гибко. Godot позволяет быстро набросать геймплейные фичи, совершенно не разбираясь во всех остальных сферах разработки, например, не разбираясь в графических интерфейсах, сохранении/загрузке и т.д. - пользуйся этой возможностью, это позволяет не терять интерес.
>изучить движок до состояния
Рекомендую сразу пробовать сделать то, что хочешь сделать. Если не получается, ищи в интернете (или спрашивай здесь), как сделать что-то конкретное. А то если ты будешь всё подряд изучать (включая сетевые протоколы, VR/AR и т.д.), до самой игры дело ещё не скоро дойдёт. Даже если с таким подходом получится плохой код, потом всегда успеешь отрефакторить - главное, что прототип у тебя уже будет работать, пусть и не очень быстро/гибко. Godot позволяет быстро набросать геймплейные фичи, совершенно не разбираясь во всех остальных сферах разработки, например, не разбираясь в графических интерфейсах, сохранении/загрузке и т.д. - пользуйся этой возможностью, это позволяет не терять интерес.
11 Кб, 525x132Поясните за импорт моделей. Сколько не смотрел туториалов, понимания не прибавляется. Почему я не могу просто импортировать модель? Почему мои изменения не сохранятся если я просто открою модель в годот?
>>21528
Во-первых, читай документацию: https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_scenes.html
Во-вторых, я не понимаю, в чём твоя проблема?
Как это - "просто"? Разве скинуть файл в папку - сложно?
Потому что:
1. В Godot есть парсер формата X, но нет возможности записывать в формат X. Следовательно, ты можешь открыть файл .X, но не можешь сохранить изменения в этот формат.
2. Предполагается, что ты кидаешь модели из внешнего 3D редактора, который может что-то по-своему изменять. Чтобы не было никаких случайных потерь и несовместимостей в случае перезаписи этого файла из внешнего редактора, принято не менять этот исходный файл через Godot. Он не будет входить в данные (.pck) экспортированной игры, там будет внутренний формат Godot.
Если ты хочешь вносить изменения, делай это через унаследованную сцену (левая кнопка) - тогда даже в случае изменения импортированного файла, унаследованная сцена сохранит и твои изменения, и обновления из импортированного файла.
Альтернатива - извлечь все ресурсы в форматы Godot (.mesh, .material или общий для всех видов ресурсов текстовый .tres), а импортированный файл удалить как лишний.
Однако, если тебе не нужно менять импортированный файл в Godot, ты можешь просто добавлять его в любую свою сцену или загружать динамически из кода. Т.е. либо мышкой кидай из файловой системы в дерево сцены, либо в коде пиши add_child(load("...gltf").instance()). В данном случае имеет смысл открыть (средняя кнопка, open anyway) импортированную сцену просто чтобы проверить - правильно ли она выглядит, не внося изменений.
Во-первых, читай документацию: https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_scenes.html
Во-вторых, я не понимаю, в чём твоя проблема?
>Почему я не могу просто импортировать модель?
Как это - "просто"? Разве скинуть файл в папку - сложно?
>Почему мои изменения не сохранятся если я просто открою модель в годот?
Потому что:
1. В Godot есть парсер формата X, но нет возможности записывать в формат X. Следовательно, ты можешь открыть файл .X, но не можешь сохранить изменения в этот формат.
2. Предполагается, что ты кидаешь модели из внешнего 3D редактора, который может что-то по-своему изменять. Чтобы не было никаких случайных потерь и несовместимостей в случае перезаписи этого файла из внешнего редактора, принято не менять этот исходный файл через Godot. Он не будет входить в данные (.pck) экспортированной игры, там будет внутренний формат Godot.
Если ты хочешь вносить изменения, делай это через унаследованную сцену (левая кнопка) - тогда даже в случае изменения импортированного файла, унаследованная сцена сохранит и твои изменения, и обновления из импортированного файла.
Альтернатива - извлечь все ресурсы в форматы Godot (.mesh, .material или общий для всех видов ресурсов текстовый .tres), а импортированный файл удалить как лишний.
Однако, если тебе не нужно менять импортированный файл в Godot, ты можешь просто добавлять его в любую свою сцену или загружать динамически из кода. Т.е. либо мышкой кидай из файловой системы в дерево сцены, либо в коде пиши add_child(load("...gltf").instance()). В данном случае имеет смысл открыть (средняя кнопка, open anyway) импортированную сцену просто чтобы проверить - правильно ли она выглядит, не внося изменений.
>>21525
Слушай, а можешь раскидать, примерно, что нужно для базы отсмотреть. Или прочитать? Может есть видео курс или выжимка из документации?
А то хочу сделать леталку с видом свеху. Для начала. Или сложно такое?
Слушай, а можешь раскидать, примерно, что нужно для базы отсмотреть. Или прочитать? Может есть видео курс или выжимка из документации?
А то хочу сделать леталку с видом свеху. Для начала. Или сложно такое?
>>21594
Там и так кратко.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
https://docs.godotengine.org/en/stable/getting_started/first_3d_game/index.html
2D? 3D? С физикой или аркадно?
Аркадную сделать просто. Вся сложность в математике, если захочешь сделать реалистичную модель самолёта.
>выжимка из документации
Там и так кратко.
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
https://docs.godotengine.org/en/stable/getting_started/step_by_step/index.html
https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
https://docs.godotengine.org/en/stable/getting_started/first_3d_game/index.html
>леталку с видом свеху
2D? 3D? С физикой или аркадно?
Аркадную сделать просто. Вся сложность в математике, если захочешь сделать реалистичную модель самолёта.
>>21603
В таком случае выглядит не страшно.
Аркадную естессно. С какой нибудь аркадной физикой тип инерции, разгона и прочего.
>Там и так кратко
В таком случае выглядит не страшно.
>Аркадную сделать просто.
Аркадную естессно. С какой нибудь аркадной физикой тип инерции, разгона и прочего.
>>21603
А у меня вот есть прям острое желание сделать 2 игры.
1-я практически идентична ANNO: Mutationem
2-я практически идентична witchbrook но чуть более навороченное.
Насколько реально на годоте такое?
А у меня вот есть прям острое желание сделать 2 игры.
1-я практически идентична ANNO: Mutationem
2-я практически идентична witchbrook но чуть более навороченное.
Насколько реально на годоте такое?
>>21509
Вообще-то, я спрашивал больше в общем смысле, как с такими ситуациями в принципе справляться. Ну ладно...
У меня 3D.
Помню про неё, это не то.
Нет, Vector3.linear_interpolate(). Но это не то.
Эээ, вообще-то delta используют, чтобы избавиться от зависимости от частоты кадров в вычислениях, которые должны происходить каждый кадр. Если ты каждый кадр что-то вычитаешь, без дельты ты будешь вычитать за разное время на разных машинах. Дельта позволяет относительно уравнять время вычислений.
Ладно, не 20 (хотя я часто играл в игры на 15-20 фпс), а 30 (для экономии аккумулятора, например), против 120-240 фпс у современных задротов. Вилка очень большая, в любом случае.
Ладно, суть такова.
Камера - орбитальная, 3D.
В _инпут идёт накопление сдвига мыши:
В _процесс идёт разворот камеры:
Но разворот резкий, чувствует все колебания мыши.
Я попытался сгладить эти колебания:
Получилась фигня, чем больше кадров - тем более резкие движения, чем меньше кадров - тем более плавные движения. Очевидно, нужно куда-то влепить дельту, но куда? В лерп влепить нельзя, тогда вместо интерполяции будет экстраполяция.
Но, повторюсь, конкретный случай - фигня, мне просто взбрело в голову так сделать, важнее понимать, как поступать во всех подобных случаях (калибровать лерп по времени кадра).
Ощущение, будто я неправильно понимаю назначение лерпа... Но мой способ работает правильно на фиксированной частоте кадров, как ещё можно добиться подобного эффекта?
Вообще-то, я спрашивал больше в общем смысле, как с такими ситуациями в принципе справляться. Ну ладно...
>камере 2д
У меня 3D.
>InterpolatedCamera
Помню про неё, это не то.
>vector.interpolate_with
Нет, Vector3.linear_interpolate(). Но это не то.
>добавляешь зависимость от частоты кадров
Эээ, вообще-то delta используют, чтобы избавиться от зависимости от частоты кадров в вычислениях, которые должны происходить каждый кадр. Если ты каждый кадр что-то вычитаешь, без дельты ты будешь вычитать за разное время на разных машинах. Дельта позволяет относительно уравнять время вычислений.
>Если у тебя просадка до 20 фпс, то оптимизировать надо ее
Ладно, не 20 (хотя я часто играл в игры на 15-20 фпс), а 30 (для экономии аккумулятора, например), против 120-240 фпс у современных задротов. Вилка очень большая, в любом случае.
Ладно, суть такова.
Камера - орбитальная, 3D.
В _инпут идёт накопление сдвига мыши:
>func _input(event: InputEvent) -> void:
>_ if event.is_class("InputEventMouseMotion"):
>_ _ _mouse_vector += event.relative
В _процесс идёт разворот камеры:
>func _process(_delta: float) -> void:
>_ rotation.y -= _mouse_vector.x × sensitivity
>_ rotation.x -= _mouse_vector.y × sensitivity
Но разворот резкий, чувствует все колебания мыши.
Я попытался сгладить эти колебания:
>func _process(_delta: float) -> void:
>_ var smooth: Vector2 = lerp(_mouse_vector, Vector2.ZERO, SMOOTH_PERCENT)
>_ rotation.y -= smooth.x × sensitivity
>_ rotation.x -= smooth.y × sensitivity
>_ _mouse_vector -= smooth
Получилась фигня, чем больше кадров - тем более резкие движения, чем меньше кадров - тем более плавные движения. Очевидно, нужно куда-то влепить дельту, но куда? В лерп влепить нельзя, тогда вместо интерполяции будет экстраполяция.
Но, повторюсь, конкретный случай - фигня, мне просто взбрело в голову так сделать, важнее понимать, как поступать во всех подобных случаях (калибровать лерп по времени кадра).
Ощущение, будто я неправильно понимаю назначение лерпа... Но мой способ работает правильно на фиксированной частоте кадров, как ещё можно добиться подобного эффекта?
>>21509
Вообще-то, я спрашивал больше в общем смысле, как с такими ситуациями в принципе справляться. Ну ладно...
У меня 3D.
Помню про неё, это не то.
Нет, Vector3.linear_interpolate(). Но это не то.
Эээ, вообще-то delta используют, чтобы избавиться от зависимости от частоты кадров в вычислениях, которые должны происходить каждый кадр. Если ты каждый кадр что-то вычитаешь, без дельты ты будешь вычитать за разное время на разных машинах. Дельта позволяет относительно уравнять время вычислений.
Ладно, не 20 (хотя я часто играл в игры на 15-20 фпс), а 30 (для экономии аккумулятора, например), против 120-240 фпс у современных задротов. Вилка очень большая, в любом случае.
Ладно, суть такова.
Камера - орбитальная, 3D.
В _инпут идёт накопление сдвига мыши:
В _процесс идёт разворот камеры:
Но разворот резкий, чувствует все колебания мыши.
Я попытался сгладить эти колебания:
Получилась фигня, чем больше кадров - тем более резкие движения, чем меньше кадров - тем более плавные движения. Очевидно, нужно куда-то влепить дельту, но куда? В лерп влепить нельзя, тогда вместо интерполяции будет экстраполяция.
Но, повторюсь, конкретный случай - фигня, мне просто взбрело в голову так сделать, важнее понимать, как поступать во всех подобных случаях (калибровать лерп по времени кадра).
Ощущение, будто я неправильно понимаю назначение лерпа... Но мой способ работает правильно на фиксированной частоте кадров, как ещё можно добиться подобного эффекта?
Вообще-то, я спрашивал больше в общем смысле, как с такими ситуациями в принципе справляться. Ну ладно...
>камере 2д
У меня 3D.
>InterpolatedCamera
Помню про неё, это не то.
>vector.interpolate_with
Нет, Vector3.linear_interpolate(). Но это не то.
>добавляешь зависимость от частоты кадров
Эээ, вообще-то delta используют, чтобы избавиться от зависимости от частоты кадров в вычислениях, которые должны происходить каждый кадр. Если ты каждый кадр что-то вычитаешь, без дельты ты будешь вычитать за разное время на разных машинах. Дельта позволяет относительно уравнять время вычислений.
>Если у тебя просадка до 20 фпс, то оптимизировать надо ее
Ладно, не 20 (хотя я часто играл в игры на 15-20 фпс), а 30 (для экономии аккумулятора, например), против 120-240 фпс у современных задротов. Вилка очень большая, в любом случае.
Ладно, суть такова.
Камера - орбитальная, 3D.
В _инпут идёт накопление сдвига мыши:
>func _input(event: InputEvent) -> void:
>_ if event.is_class("InputEventMouseMotion"):
>_ _ _mouse_vector += event.relative
В _процесс идёт разворот камеры:
>func _process(_delta: float) -> void:
>_ rotation.y -= _mouse_vector.x × sensitivity
>_ rotation.x -= _mouse_vector.y × sensitivity
Но разворот резкий, чувствует все колебания мыши.
Я попытался сгладить эти колебания:
>func _process(_delta: float) -> void:
>_ var smooth: Vector2 = lerp(_mouse_vector, Vector2.ZERO, SMOOTH_PERCENT)
>_ rotation.y -= smooth.x × sensitivity
>_ rotation.x -= smooth.y × sensitivity
>_ _mouse_vector -= smooth
Получилась фигня, чем больше кадров - тем более резкие движения, чем меньше кадров - тем более плавные движения. Очевидно, нужно куда-то влепить дельту, но куда? В лерп влепить нельзя, тогда вместо интерполяции будет экстраполяция.
Но, повторюсь, конкретный случай - фигня, мне просто взбрело в голову так сделать, важнее понимать, как поступать во всех подобных случаях (калибровать лерп по времени кадра).
Ощущение, будто я неправильно понимаю назначение лерпа... Но мой способ работает правильно на фиксированной частоте кадров, как ещё можно добиться подобного эффекта?
>>21622
Кажется, можно ещё так сделать:
Но всё равно непонятно, куда здесь дельту лепить...
>как ещё можно добиться подобного эффекта?
Кажется, можно ещё так сделать:
>if _mouse_vector > Vector2.ZERO:
>_ var smooth: Vector2 = _mouse_vector × 0.8 # <= 1.0
>_ rotation.y -= smooth.x × sensitivity
>_ rotation.x -= smooth.y × sensitivity
>_ if _mouse_vector > smooth: # ну тут нужно по x/y разбить
>_ _ _mouse_vector -= smooth
>_ else: _mouse_vector = Vector2.ZERO
Но всё равно непонятно, куда здесь дельту лепить...
>>21618
Впервые слышу об этих двух играх, но если там 2D или простенькое 3D, то абсолютно реально. Тут другой вопрос, потянешь ли ты графику уровня тех игр в одиночку за обозримое время?
Godot пока что сложно использовать для ААА графона в огромном мире под открытым небом, когда дальность видимости несколько километров и всё заполнено предметами. Ну, то есть тебе пришлось бы изобретать способы оптимизации, тогда как в других движках может из коробки иметься оптимизация для подобных огромных миров. Всё нытьё движкосрачеров из-за того, что чего-то нет из коробки и нужно самому доделывать под себя. Но возможность доделать определённо есть, если знаешь как.
>Насколько реально на годоте такое?
Впервые слышу об этих двух играх, но если там 2D или простенькое 3D, то абсолютно реально. Тут другой вопрос, потянешь ли ты графику уровня тех игр в одиночку за обозримое время?
Godot пока что сложно использовать для ААА графона в огромном мире под открытым небом, когда дальность видимости несколько километров и всё заполнено предметами. Ну, то есть тебе пришлось бы изобретать способы оптимизации, тогда как в других движках может из коробки иметься оптимизация для подобных огромных миров. Всё нытьё движкосрачеров из-за того, что чего-то нет из коробки и нужно самому доделывать под себя. Но возможность доделать определённо есть, если знаешь как.
>>21622
В твоем коде дельта не использована. Дельта - это сколько времени прошло между кадрами.
В твоем коде дельта не использована. Дельта - это сколько времени прошло между кадрами.
>>21618
Сделай небольшой мир кусочек да управление, этого будет достаточно для проверки сил
Сделай небольшой мир кусочек да управление, этого будет достаточно для проверки сил
842 Кб, 1712x800>>21638
Я в курсе, что в конкретном отрывке кода она не используется. Я спрашиваю, как её использовать, чтобы плавное сглаживание движения камеры было одинаковым на любой частоте кадров. Чувствую, что должно быть решение, но не понимаю, какое. Алсо это должно быть какое-то глобальное решение, применимое для любых подобных (сглаженных) вычислений...
>В твоем коде дельта не использована.
Я в курсе, что в конкретном отрывке кода она не используется. Я спрашиваю, как её использовать, чтобы плавное сглаживание движения камеры было одинаковым на любой частоте кадров. Чувствую, что должно быть решение, но не понимаю, какое. Алсо это должно быть какое-то глобальное решение, применимое для любых подобных (сглаженных) вычислений...
>>21649
Не знаю почему ты игнорируешь написанное в моем ответе.
Дельта - это время между кадрами. Если у тебя фпс 60, то delta=1/60. Если 20, то 1/20. Если фпс поменялся, то и дельта поменялась. И любое число, умноженное на delta, пропорционально проведенному в кадре времени. И я даже писал выше interpolate(delta x ratio).
Не знаю почему ты игнорируешь написанное в моем ответе.
Дельта - это время между кадрами. Если у тебя фпс 60, то delta=1/60. Если 20, то 1/20. Если фпс поменялся, то и дельта поменялась. И любое число, умноженное на delta, пропорционально проведенному в кадре времени. И я даже писал выше interpolate(delta x ratio).
>>21648
Я хотел написать что не получится, но полистал видосы и думаю все необходимое уже есть. Но ты столько арта все равно не нарисуешь.
Я хотел написать что не получится, но полистал видосы и думаю все необходимое уже есть. Но ты столько арта все равно не нарисуешь.
>>21661
Я не игнорирую. Я всё это прекрасно знаю.
Я не игнорирую. Я всё это прекрасно знаю.
>писал выше interpolate(delta x ratio)
>Vector2 linear_interpolate ( Vector2 to, float weight )
>Returns the result of the linear interpolation between this vector and to by amount weight. weight is on the range of 0.0 to 1.0, representing the amount of interpolation.
>>21676
Во-первых, lerp это просто формула a+(b-a) * weight
Так что ей ничего не мешает выйти за пределы. Иногда это имеет смысл, например ты хочешь, чтобы объект гротескно перелетал цель.
Во-вторых, ну используй от 0 до 1, а на дельту умножай результат лерпа, если тебе так больше нравится.
Ты писал контроллер персонажа? Там же есть дельта.
Во-первых, lerp это просто формула a+(b-a) * weight
Так что ей ничего не мешает выйти за пределы. Иногда это имеет смысл, например ты хочешь, чтобы объект гротескно перелетал цель.
Во-вторых, ну используй от 0 до 1, а на дельту умножай результат лерпа, если тебе так больше нравится.
Ты писал контроллер персонажа? Там же есть дельта.
>>21772
По-моему, не универсальное решение.
Допустим, можно вычесть максимум 1. После лерпа остаётся 0.6. Если время кадра будет равно 2 (кадр в две секунды, такое реально в процессе загрузки чего-либо), тогда получится 1.2, и результат окажется отрицательным (-0.2). Вставлять очередную проверку на отрицательность? Выглядит как костыль.
>на дельту умножай результат лерпа
По-моему, не универсальное решение.
Допустим, можно вычесть максимум 1. После лерпа остаётся 0.6. Если время кадра будет равно 2 (кадр в две секунды, такое реально в процессе загрузки чего-либо), тогда получится 1.2, и результат окажется отрицательным (-0.2). Вставлять очередную проверку на отрицательность? Выглядит как костыль.
>>21823
Ограничить delta значением 1.0?
Ограничить delta значением 1.0?
>>21823
2-секундная загрузка это в любом случае баг игры, например предстаь что произойдет с физикой, скорее всего обхекты начнут пролетать сквозь стены. Надо делать либо многопоточную, либо паузу с экраном загрузки.
2-секундная загрузка это в любом случае баг игры, например предстаь что произойдет с физикой, скорее всего обхекты начнут пролетать сквозь стены. Надо делать либо многопоточную, либо паузу с экраном загрузки.
>>22159
По-моему, никак.
Здесь перечислены все встроенные поля/функции:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/spatial_shader.html#vertex-built-ins
Можно узнать локальные координаты вершины, но не ID.
>айди вершины
По-моему, никак.
Здесь перечислены все встроенные поля/функции:
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/spatial_shader.html#vertex-built-ins
Можно узнать локальные координаты вершины, но не ID.
>>22205
https://github.com/godotengine/godot/blob/3.4/servers/visual/shader_types.cpp
https://github.com/godotengine/godot/blob/3.x/servers/visual/shader_types.cpp#L69
Они добавили в 3.х, а в последней 3.4.4 её ещё нету.
https://github.com/godotengine/godot/blob/3.4/servers/visual/shader_types.cpp
https://github.com/godotengine/godot/blob/3.x/servers/visual/shader_types.cpp#L69
Они добавили в 3.х, а в последней 3.4.4 её ещё нету.
>>22211
Пофиг, 3.5 уже в релиз кандидатах.
Пофиг, 3.5 уже в релиз кандидатах.
>>22274 (Del)
Сколькр ТЫ сделал пулл реквестов чтобы это произошло?
Сколькр ТЫ сделал пулл реквестов чтобы это произошло?
606 Кб, 1920x1038>>22317 (Del)
>>22274 (Del)
Читаешь такие комментарии и понимаешь, что где-то там сидит чепушилла, что срёт в гд, а так ни одной игры не сделал.
Какое же чмо, хра тфу.
>>22274 (Del)
Читаешь такие комментарии и понимаешь, что где-то там сидит чепушилла, что срёт в гд, а так ни одной игры не сделал.
Какое же чмо, хра тфу.
>>21648
Ты не за годо переживай, а за твои силы, ты даже лоуполи мирок небольшой ахуеешь делать, инфа сотка
Ты не за годо переживай, а за твои силы, ты даже лоуполи мирок небольшой ахуеешь делать, инфа сотка
>>22323
Бля жеско
Бля жеско
>>22595
Вот-вот, очень сложно и долго.
Для меня пример того как надо - Берсерия, небольшие локации и минимум проблем, даже по скорость отрисовки переживать не надо, ибо расстояния небольшие, а дальше уже и про сюжет и про игровой процесс можно думать.
Вот-вот, очень сложно и долго.
Для меня пример того как надо - Берсерия, небольшие локации и минимум проблем, даже по скорость отрисовки переживать не надо, ибо расстояния небольшие, а дальше уже и про сюжет и про игровой процесс можно думать.
35 Кб, 400x225Здравствуйте, возможно ли в годоте сделать такую визуализацию подхватывая все звуки из ОСи, а не только из внутри проекта?
>>22779
Можно.
Можно.
>>22843
И от Хуана ещё видос, максимально по делу, да с таким-то музоном.
https://www.youtube.com/watch?v=5z9uuU0xVX4
И от Хуана ещё видос, максимально по делу, да с таким-то музоном.
https://www.youtube.com/watch?v=5z9uuU0xVX4
>>22845
Причем тут это вообще? Вопрос не в картиночках, а сугубо технический - в захвате аудиовыхода винды.
Причем тут это вообще? Вопрос не в картиночках, а сугубо технический - в захвате аудиовыхода винды.
>>22893
Я тебя помню, ты уже не в первый раз разводишь срач, не разбираясь в вопросе и называя рандомные вещи, в надежде что они чудом заработают. Ты даже не пробовал, иначе бы увидел что запишется тишина.
Твоя галочка даже в описании говорит про микрофон. С ней никаких новых устройств в списке аудиосервера не появляется. Еще раз для непонятливых - анон спросил, как получить захват итогового аутпута винды, а не микрофона или воспроизводимого из годота аудиофайла.
Даже если сравнить с этим кодом
https://stackoverflow.com/questions/64318206/record-an-audio-stream-with-wasapi
И поискать по коду годота флаг AUDCLNT_STREAMFLAGS_LOOPBACK
Я тебя помню, ты уже не в первый раз разводишь срач, не разбираясь в вопросе и называя рандомные вещи, в надежде что они чудом заработают. Ты даже не пробовал, иначе бы увидел что запишется тишина.
Твоя галочка даже в описании говорит про микрофон. С ней никаких новых устройств в списке аудиосервера не появляется. Еще раз для непонятливых - анон спросил, как получить захват итогового аутпута винды, а не микрофона или воспроизводимого из годота аудиофайла.
Даже если сравнить с этим кодом
https://stackoverflow.com/questions/64318206/record-an-audio-stream-with-wasapi
И поискать по коду годота флаг AUDCLNT_STREAMFLAGS_LOOPBACK
>>22997
Конкретно где?
Инпут по умолчанию в системе с микрофоном - это микрофон, в системе без микрофона - это стереомикс. Если нужно записывать стереомикс на системе с микрофоном, нужно выбрать правильное устройство.
> Твоя галочка даже в описании говорит про микрофон.
Конкретно где?
Инпут по умолчанию в системе с микрофоном - это микрофон, в системе без микрофона - это стереомикс. Если нужно записывать стереомикс на системе с микрофоном, нужно выбрать правильное устройство.
>>23011
В тултипе при наведении мышкой
У меня без микрофона устройства default и realtek input, причем второй даже не выставляется, скидывается на default. Дисятка. Окей, возможно у большинства есть этот стереомикс, у меня его нет.
> где
В тултипе при наведении мышкой
У меня без микрофона устройства default и realtek input, причем второй даже не выставляется, скидывается на default. Дисятка. Окей, возможно у большинства есть этот стереомикс, у меня его нет.
>>23020
Странно, потому что "stereo mix" это именно реалтековская терминология.
> есть этот стереомикс, у меня его нет
Странно, потому что "stereo mix" это именно реалтековская терминология.
>>23343 (Del)
Тебе сколько лет? Думаю, меньше 30-ти. Скорее всего вещи, о которых я тебе скажу, ты услышишь впервые. Итак.
В аудиодрайвере бывает несколько виртуальных входных устройств. И выходных устройств тоже несколько. Они имеют свои уникальные индексы и идентификаторы. По одному из устройств ввода и вывода является дефолтным.
Все аудиодрайверы шындовс совместимы с ВинАПИ для того, чтобы винда в трее могла универсально открывать параметры звука или микшер.
Соответственно.
Если воспользоваться ВинАПИ, то можно получать список устройств, можно задавать устройство вывода самостоятельно. То есть делать программно то, что ты мышкой делаешь в окошке на скрине анона выше.
Вот на твоём месте я копал бы в эту сторону. Если движок всего этого не может, у него есть модуль OS который может запускать батники. Намёк ясен?
Тебе сколько лет? Думаю, меньше 30-ти. Скорее всего вещи, о которых я тебе скажу, ты услышишь впервые. Итак.
В аудиодрайвере бывает несколько виртуальных входных устройств. И выходных устройств тоже несколько. Они имеют свои уникальные индексы и идентификаторы. По одному из устройств ввода и вывода является дефолтным.
Все аудиодрайверы шындовс совместимы с ВинАПИ для того, чтобы винда в трее могла универсально открывать параметры звука или микшер.
Соответственно.
Если воспользоваться ВинАПИ, то можно получать список устройств, можно задавать устройство вывода самостоятельно. То есть делать программно то, что ты мышкой делаешь в окошке на скрине анона выше.
Вот на твоём месте я копал бы в эту сторону. Если движок всего этого не может, у него есть модуль OS который может запускать батники. Намёк ясен?
45 Кб, 986x409>>23343 (Del)
Ну, собсна, надо делать настройку с менюбаттоном, в который выводить список аудиоустройств (пикрелейтед) и давать игроку самостоятельно выбрать. Потому что названия у всех разные. А ещё у меня стереомикшер был отключён (я щас проверил), хотя ОБС исправно пишет звук с системы. Можешь ещё погуглить, как это делает ОБС при выключенном системном-драйверном стереомикшере.
Ну, собсна, надо делать настройку с менюбаттоном, в который выводить список аудиоустройств (пикрелейтед) и давать игроку самостоятельно выбрать. Потому что названия у всех разные. А ещё у меня стереомикшер был отключён (я щас проверил), хотя ОБС исправно пишет звук с системы. Можешь ещё погуглить, как это делает ОБС при выключенном системном-драйверном стереомикшере.
>>23420 (Del)
Затем, что когда стереомикшер (за каким-то хуем) отключён в системе, годот его не видит.
Затем, что когда стереомикшер (за каким-то хуем) отключён в системе, годот его не видит.
>>23408
С чего такой эйджизм? Не пугай новичков в треде.
Хех, недостаточно кроссплатформенно.
Имхо, лучше написать модуль на GDNative, его можно сделать кроссплатформенным, а батник не кроссплатформенный.
>>23410
Кстати, да, я тоже вспомнил, что OBS пишет звук, даже если все устройства записи выключены в драйвере.
Можно посмотреть код, если ты достаточно безумен:
https://github.com/obsproject/obs-studio
>меньше 30-ти
С чего такой эйджизм? Не пугай новичков в треде.
>ВинАПИ
Хех, недостаточно кроссплатформенно.
>запускать батники
Имхо, лучше написать модуль на GDNative, его можно сделать кроссплатформенным, а батник не кроссплатформенный.
>>23410
>ОБС исправно пишет
Кстати, да, я тоже вспомнил, что OBS пишет звук, даже если все устройства записи выключены в драйвере.
Можно посмотреть код, если ты достаточно безумен:
https://github.com/obsproject/obs-studio
21 Кб, 307x410Анончики, подскажите пожалуйста, можно ли как то настроить очередность исполнения скриптов в годо? Хочу написать простой ИИ для нпс. Суть такая: есть лагерь, в котором находится несколько нпс, у кажого имеется своя работа в нем (патрулирование, стойка смирно, проигрывание анимации на определенном месте и тд). И чтобы не хардкодить каждому kinematic body их работу, я пытаюсь сделать некую мастер ноду для лагеря (smart_terrain), которая сама определяет имеющиеся "работы" в дочерних нодах (works), имеющихся нпс (pawns) и распределяет каждому нпс эту работу. Пока работа это просто набор точек, между которыми нпс должны передвигаться. Сначала я хотел, чтобы smart_terrain сам смотрел какие работы и какие нпс у него имеются и рандомно распределял эти работы нпсам, явно пробрасывая array с координатами точек, но бробрасывает он бред полный, вариант не работает. Затем решил поменять механику: smart_terrain все так же собирает инфу о работах, распределяет их среди имеющихся нпс и хранит у себя в списке, который уже парсят сами нпс на старте, но код smart_terrainа не исполнятся, тк очередь до него не доходит. Мучаюсь с этой проблемой. Где я еблан? Предпочтительно конечно реализовать первый вариант, когда смарт террейн сам передает нпс их работу, но вот только как это сделать...
https://pastebin.com/a9d7sAbt
https://pastebin.com/a9d7sAbt
>>23434
Стейт-машина. Других вариантов я не знаю. Просмотрел бегло твой код. Не вижу там стейтмашины.
> можно ли как то настроить очередность исполнения скриптов
Стейт-машина. Других вариантов я не знаю. Просмотрел бегло твой код. Не вижу там стейтмашины.
>>23446
В целом механизм я себе вижу так:
Лагерь - имеет список задач, и состояние из набора состояний доступных ему. Состояния переключает одна стейтмашина, назовём её ЛСМ. Логика переключений зависит от погоды, времени дня, ну и продвижения по сюжету собсна.
Неписи - могут получать задачи сверху, у неписей тоже есть состояние из набора состояний непися. И у каждого непися своя стейтмашина (НСМ). Определенные задачи непись делает в определенных состояниях. За переключение состояний отвечает ГОАП. У каждого непися персональный распорядок дня. Гугли GOAP.
И вот неписи обращаются к Лагерю (или как ты там навыдумывал, к смарт террейну(шо?) как к доске объявлений. Видят в списке подходящие задания и если у них сейчас по ГОАП время поработать, берут из стека рабочее задание. Если у них по ГОАП время попинать хуи, берут из стека хуепинательное задание. И так далее.
В целом механизм я себе вижу так:
Лагерь - имеет список задач, и состояние из набора состояний доступных ему. Состояния переключает одна стейтмашина, назовём её ЛСМ. Логика переключений зависит от погоды, времени дня, ну и продвижения по сюжету собсна.
Неписи - могут получать задачи сверху, у неписей тоже есть состояние из набора состояний непися. И у каждого непися своя стейтмашина (НСМ). Определенные задачи непись делает в определенных состояниях. За переключение состояний отвечает ГОАП. У каждого непися персональный распорядок дня. Гугли GOAP.
И вот неписи обращаются к Лагерю (или как ты там навыдумывал, к смарт террейну(шо?) как к доске объявлений. Видят в списке подходящие задания и если у них сейчас по ГОАП время поработать, берут из стека рабочее задание. Если у них по ГОАП время попинать хуи, берут из стека хуепинательное задание. И так далее.
>>23434
Да.
1. Исключаешь из своих скриптов все обработчики стандартных событий: _process, _physics_process и т.д.
2. Создаёшь в этих же скриптах метод update.
3. Собираешь в одном скрипте ссылки на эти скрипты.
4. Сортируешь список ссылок как тебе угодно.
5. Делаешь for link in links: link.update()
6. Ты восхитителен.
Альтернативы:
1. Сортировать ноды в дереве. Обработчики стандартных событий нод вызываются в определённом порядке, который зависит от их расположения в дереве сцены.
2. Сделать свою реализацию MainLoop.
Весь остальной твой пост я читал, но ничего не понял(
>настроить очередность исполнения скриптов
Да.
1. Исключаешь из своих скриптов все обработчики стандартных событий: _process, _physics_process и т.д.
2. Создаёшь в этих же скриптах метод update.
3. Собираешь в одном скрипте ссылки на эти скрипты.
4. Сортируешь список ссылок как тебе угодно.
5. Делаешь for link in links: link.update()
6. Ты восхитителен.
Альтернативы:
1. Сортировать ноды в дереве. Обработчики стандартных событий нод вызываются в определённом порядке, который зависит от их расположения в дереве сцены.
2. Сделать свою реализацию MainLoop.
Весь остальной твой пост я читал, но ничего не понял(
Есть Панель.
В панели StyleboxTexture с текстурой с модом stretch и margin right-left по 20 пикселей, чтобы левая и правая сторона игнорировали stretch.
Задача:
- закрасить половину текстуры красным цветом, а другую половину жёлтым цветом.
В панели StyleboxTexture с текстурой с модом stretch и margin right-left по 20 пикселей, чтобы левая и правая сторона игнорировали stretch.
Задача:
- закрасить половину текстуры красным цветом, а другую половину жёлтым цветом.
>>23434
Кстати, нода Navigation устарела и скоро будет удалена. Предлагают использовать NavigationServer вместо этой ноды. Я вчера попробовал на 3.5rc6, ничего не получилось, психанул, забил.
Ты разберись сначала, что это за "бред полный" и почему он пробрасывается вместо того, что ты ожидаешь. Попробуй вывести этот "бред" в консоль, или выполнить скрипты пошагово, просматривая значения переменных в дебагере.
Это невозможно, за исключением ситуации, если у тебя произошёл бесконечный цикл в одной из дочерних нод или выполнение было остановленно из-за какой-то ошибки в дочерних нодах.
Рекомендую указывать везде типы и следовать этому руководству по оформлению кода:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
Особенно этот параграф:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#code-order
Так твой код будет проще читать, в том числе тебе самому, и проще искать ошибки в нём.
Кстати, нода Navigation устарела и скоро будет удалена. Предлагают использовать NavigationServer вместо этой ноды. Я вчера попробовал на 3.5rc6, ничего не получилось, психанул, забил.
>бробрасывает он бред полный
Ты разберись сначала, что это за "бред полный" и почему он пробрасывается вместо того, что ты ожидаешь. Попробуй вывести этот "бред" в консоль, или выполнить скрипты пошагово, просматривая значения переменных в дебагере.
>код smart_terrainа не исполнятся, тк очередь до него не доходит
Это невозможно, за исключением ситуации, если у тебя произошёл бесконечный цикл в одной из дочерних нод или выполнение было остановленно из-за какой-то ошибки в дочерних нодах.
Рекомендую указывать везде типы и следовать этому руководству по оформлению кода:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
Особенно этот параграф:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#code-order
Так твой код будет проще читать, в том числе тебе самому, и проще искать ошибки в нём.
>>23456
Возможны варианты:
1. Добавить два ColorRect с полупрозрачным цветом.
https://docs.godotengine.org/en/stable/classes/class_colorrect.html
2. Вызывать draw_rect() в обработчике _draw() Panel.
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
3. Повесить на Panel CanvasItem шейдер.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/canvas_item_shader.html
>закрасить половину текстуры
Возможны варианты:
1. Добавить два ColorRect с полупрозрачным цветом.
https://docs.godotengine.org/en/stable/classes/class_colorrect.html
2. Вызывать draw_rect() в обработчике _draw() Panel.
https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
3. Повесить на Panel CanvasItem шейдер.
https://docs.godotengine.org/en/stable/tutorials/shaders/shader_reference/canvas_item_shader.html
>>23465 (Del)
>>23468 (Del)
Да я пытался по-быстрому получить маршрут в GridMap, без создания каких-либо агентов. А оно мне какую-то фигню возвращает, я не стал разбираться, почему оно так работает.
>>23468 (Del)
Да я пытался по-быстрому получить маршрут в GridMap, без создания каких-либо агентов. А оно мне какую-то фигню возвращает, я не стал разбираться, почему оно так работает.
>>23471 (Del)
Знаю, но астар по-быстрому не накидать, если у тебя блоки сложнее "пусто/стена". Т.е. если блок может иметь стену с любой из 4 сторон (и вращаться хотя бы по одной из осей - Y), например, это сильно усложняет настройку астара.
Но у гридмапы есть возможность присваивать навмеши каждому блоку, а затем комбинировать их для навигации. Даже есть галочка "bake navigation" или что-то вроде. Но я не разобрался, как это всё использовать. Потом как-нибудь почитаю туториалы, наверняка я что-то упускаю...
Знаю, но астар по-быстрому не накидать, если у тебя блоки сложнее "пусто/стена". Т.е. если блок может иметь стену с любой из 4 сторон (и вращаться хотя бы по одной из осей - Y), например, это сильно усложняет настройку астара.
Но у гридмапы есть возможность присваивать навмеши каждому блоку, а затем комбинировать их для навигации. Даже есть галочка "bake navigation" или что-то вроде. Но я не разобрался, как это всё использовать. Потом как-нибудь почитаю туториалы, наверняка я что-то упускаю...
>>23462
Вариант с шейдером и интересует. Сможешь сделать простой пример и показать на скрине? Я вот не смог.
Вариант с шейдером и интересует. Сможешь сделать простой пример и показать на скрине? Я вот не смог.
>>23513
Как-то так.
Как это может быть сложно?
> Сможешь сделать простой пример и показать на скрине?
> if UV > 0.5 COLOR = 1 else COLOR = 2
Как-то так.
Как это может быть сложно?
>>23520
Попробуй запустить свой код и посмотреть на результат. Приложи скриншот, на котором будет видно, что это панель с стилем в котором стреч текстура.
Попробуй запустить свой код и посмотреть на результат. Приложи скриншот, на котором будет видно, что это панель с стилем в котором стреч текстура.
38 Кб, 1192x628>>23521
Нахуй стили. Тебе русским языком сказали. Положи шейдер поверх панели, а не стиля.
>>23547 (Del)
Ёбом токнуть? Это предложения пользователей, а не баги.
> Попробуй запустить свой код и посмотреть на результат.
> это панель с стилем
Нахуй стили. Тебе русским языком сказали. Положи шейдер поверх панели, а не стиля.
>>23547 (Del)
> Похоже что Stlybox нельзя назначить шейдер.
>godot-proposals
Ёбом токнуть? Это предложения пользователей, а не баги.
>>23542 (Del)
Я могу написать COLOR.rgb = UV.xxx и посмотреть, что стреч к хуям ломает UV разверстку, т.к. UV в объекте - это UV текстуры, и видимо ДО применения к ней стилей и иного "взаимодействия".
В общем, как поправить эту херь без SCREEN_TEXTURE, которая мобилки превращает в фарш, я пока даже не знаю.
(Реальная задача не поменять цвет, естественно).
Я могу написать COLOR.rgb = UV.xxx и посмотреть, что стреч к хуям ломает UV разверстку, т.к. UV в объекте - это UV текстуры, и видимо ДО применения к ней стилей и иного "взаимодействия".
В общем, как поправить эту херь без SCREEN_TEXTURE, которая мобилки превращает в фарш, я пока даже не знаю.
(Реальная задача не поменять цвет, естественно).
>>23633 (Del)
А UV выживет при этом или его тоже растянет по середине к хуям?
А UV выживет при этом или его тоже растянет по середине к хуям?
33 Кб, 1185x730>>23456
>>23513
Имхо, если тебе нужен цветной фильтр и эта панель всего одна, то лучше сделать с помощью полупрозрачных нод. Это будет более гибкое решение, чем хардкод в шейдере.
Вот, строго по твоему ТЗ.
>>23631
Кому естественно? Ты просил поменять цвет в зависимости от стороны, а не что-то сложное. Рассказывай теперь, что тебе реально нужно сделать с этой текстурой.
>Есть Панель.
>В панели StyleboxTexture с текстурой с модом stretch и margin right-left по 20 пикселей, чтобы левая и правая сторона игнорировали stretch.
>Задача закрасить половину текстуры красным цветом, а другую половину жёлтым цветом.
>>23513
>Вариант с шейдером и интересует.
Имхо, если тебе нужен цветной фильтр и эта панель всего одна, то лучше сделать с помощью полупрозрачных нод. Это будет более гибкое решение, чем хардкод в шейдере.
>Сможешь сделать простой пример и показать на скрине?
Вот, строго по твоему ТЗ.
>>23631
>Реальная задача не поменять цвет, естественно
Кому естественно? Ты просил поменять цвет в зависимости от стороны, а не что-то сложное. Рассказывай теперь, что тебе реально нужно сделать с этой текстурой.
>>23646
У тебя иконка случаем не 40 пикселей? Растяни иконку вбок, чтобы стретч всем анонса показать.
У тебя иконка случаем не 40 пикселей? Растяни иконку вбок, чтобы стретч всем анонса показать.
>>23631
Вычислять аспект, передавать его в шейдер юниформом, домножать свои вычисления на аспект. Не?
> как поправить эту херь
Вычислять аспект, передавать его в шейдер юниформом, домножать свои вычисления на аспект. Не?
129 Кб, 722x765>>23655
Надо margin'ы 9-path текстуры под шейдером пробрасывать в шейдер юниформами, и проводить вычисления, иначе получится довольно любопытный эффект. Сплиттер (SplitIndent из пикрелейтеда) будет медленно продвигаться у краёв найнпатча и быстро в середине.
Но всё решаемо.
Надо margin'ы 9-path текстуры под шейдером пробрасывать в шейдер юниформами, и проводить вычисления, иначе получится довольно любопытный эффект. Сплиттер (SplitIndent из пикрелейтеда) будет медленно продвигаться у краёв найнпатча и быстро в середине.
Но всё решаемо.
>>23674
Пофиксил глаза + сделал Full HD версию.
Если кто хочет, могу отрендерить в другом разрешении.
Сделаем WIDEOT великим, снова!
>>23699
Вот тут >>23646 Shader Param видишь? Я не зря вынес оба цвета туда. Добавляешь ноду AnimationPlayer и анимируешь цвета как пожелаешь. Лучше через эту ноду, т.к. больше контроля и гибкости, чем мутить что-то через шейдеры или GDScript. В скрипте потом пишешь просто $AnimationPlayer.play("имя анимации"), когда тебе нужно проиграть эту анимацию.
Пофиксил глаза + сделал Full HD версию.
Если кто хочет, могу отрендерить в другом разрешении.
Сделаем WIDEOT великим, снова!
>>23699
>сделать плавную анимацию
Вот тут >>23646 Shader Param видишь? Я не зря вынес оба цвета туда. Добавляешь ноду AnimationPlayer и анимируешь цвета как пожелаешь. Лучше через эту ноду, т.к. больше контроля и гибкости, чем мутить что-то через шейдеры или GDScript. В скрипте потом пишешь просто $AnimationPlayer.play("имя анимации"), когда тебе нужно проиграть эту анимацию.
>>23713
Чтобы не скакало надо:
>>23668
Читай внимательнее.
> Она будет скакать аки лань, место плавного перехода.
Чтобы не скакало надо:
>>23668
> Надо margin'ы 9-path текстуры под шейдером пробрасывать в шейдер юниформами, и проводить вычисления, иначе получится довольно любопытный эффект. Сплиттер (SplitIndent из пикрелейтеда) будет медленно продвигаться у краёв найнпатча и быстро в середине.
Читай внимательнее.
Ребят, в чем косяк? Есть 2 переменные, которым передается одинаковый array, в цикле первый объект из ОДНОГО списка удаляется, по факту почему то удаляются у обоих. В чем проблема? Других remove'ов я не ставил нигде.
>>23719
В том, что Array передаётся по ссылке. Юзай Array.duplicate() чтобы создать уникальную независимую копию.
> В чем проблема?
В том, что Array передаётся по ссылке. Юзай Array.duplicate() чтобы создать уникальную независимую копию.
>>23721
Фух, заработало... Огромное спасибо!
Фух, заработало... Огромное спасибо!
>>23728
Еба ты дизайнер. Все, мои извинения, оказывается это фича. Хуан как всегда всех переиграл.
Еба ты дизайнер. Все, мои извинения, оказывается это фича. Хуан как всегда всех переиграл.
Допустим, я хочу сделать 2.5D-игру по типу Вульфа. Насколько будет ебануто, если я всю игровую логику сделаю в 2D - коллижны там, карты из тайлмап, а потом буду вручную рисовать в канвасе изображение при помощи самописного рейкаста?
31 Кб, 160x160>>23728
Ну это ящитаю контент для оп-пикч на перекат.
Ну это ящитаю контент для оп-пикч на перекат.
146 Кб, mp4,648x600, 0:05
>>23740
Долго думал, зачем тебе всё это закрашивание нужно... Только сегодня дошло, что ты, скорее всего, хотел сделать.
Если тебе нужен прогресс-бар с равномерным перекрашиванием с одного цвета в другой, то для этого есть специальная нода:
https://docs.godotengine.org/en/stable/classes/class_textureprogress.html
Там до трёх текстур (подложка-шкала, текстура для заполнения, текстура для бликов/декораций поверх), настройка 9-patch для них, множество способов закрашивания, любой цвет на выбор. И никаких шейдеров писать не нужно. Можешь растянуть этот TextureProgress на весь экран и будет тебе визуально та же фигня, что ты пытаешься сделать с Panel и StyleBoxTexture. Точно так же можно анимировать, настраивать плавность перехода и т.д. Конечно, для чего-то сложнее (типа шкалы с шестью разными видами здоровья, как в Overwatch) придётся выдумывать другой способ, но в большинстве игр хватит стандартного функционала.
https://ru.wikipedia.org/wiki/Проблема_XY
>оказывается это фича
Долго думал, зачем тебе всё это закрашивание нужно... Только сегодня дошло, что ты, скорее всего, хотел сделать.
Если тебе нужен прогресс-бар с равномерным перекрашиванием с одного цвета в другой, то для этого есть специальная нода:
https://docs.godotengine.org/en/stable/classes/class_textureprogress.html
Там до трёх текстур (подложка-шкала, текстура для заполнения, текстура для бликов/декораций поверх), настройка 9-patch для них, множество способов закрашивания, любой цвет на выбор. И никаких шейдеров писать не нужно. Можешь растянуть этот TextureProgress на весь экран и будет тебе визуально та же фигня, что ты пытаешься сделать с Panel и StyleBoxTexture. Точно так же можно анимировать, настраивать плавность перехода и т.д. Конечно, для чего-то сложнее (типа шкалы с шестью разными видами здоровья, как в Overwatch) придётся выдумывать другой способ, но в большинстве игр хватит стандартного функционала.
https://ru.wikipedia.org/wiki/Проблема_XY
>>23862
О, кстати, раз вспомнили. А как сделать прогрессбар как в дарксолсах, при изменении бара, он закрашивается третьим цветом/текстурой, на величину, на которую он изменится, затем изменяется. Я имею, ввиду, есть ли для этого готовый функционал? А то сам алгоритм особых проблем не вызывает, если велосипедить.
мимо
О, кстати, раз вспомнили. А как сделать прогрессбар как в дарксолсах, при изменении бара, он закрашивается третьим цветом/текстурой, на величину, на которую он изменится, затем изменяется. Я имею, ввиду, есть ли для этого готовый функционал? А то сам алгоритм особых проблем не вызывает, если велосипедить.
мимо
570 Кб, webm,400x300, 1:08
>>23766
Чисто из спортивного интереса можно, но не вижу причины делать такое на Godot, учитывая что встроенные инструменты позволяют сделать полноценное 3D достаточного качества. Т.е. ты сделаешь игру методом из тех времён, когда 600 КБ хватало всем, но на движке, которому для запуска нужны сотни мегабайт оперативной и видеопамяти. Если уж делать полный технический клон с нуля, стоит взять что-то более низкоуровневое, имхо.
Честно говоря, я не уверен, хватит ли тебе производительности для достаточно чёткого изображения. Вот это шебм я записал, сделав рейтрейсинг матрицей из лучей сцены из 3D физических объектов (у них нет мешей, только шейпы - боксы и сферы). Но при увеличении матрицы лучей, производительность быстро падает до неиграбельной. Конечно, для рейкастинга (X) нужно значительно меньше лучей, чем для рейтрейсинга (X×Y), и сами лучи по идее должны быть дешевле (2D вместо 3D), но всё равно есть сомнения...
>хочу сделать 2.5D-игру по типу Вульфа
Чисто из спортивного интереса можно, но не вижу причины делать такое на Godot, учитывая что встроенные инструменты позволяют сделать полноценное 3D достаточного качества. Т.е. ты сделаешь игру методом из тех времён, когда 600 КБ хватало всем, но на движке, которому для запуска нужны сотни мегабайт оперативной и видеопамяти. Если уж делать полный технический клон с нуля, стоит взять что-то более низкоуровневое, имхо.
>потом буду вручную рисовать в канвасе изображение при помощи самописного рейкаста
Честно говоря, я не уверен, хватит ли тебе производительности для достаточно чёткого изображения. Вот это шебм я записал, сделав рейтрейсинг матрицей из лучей сцены из 3D физических объектов (у них нет мешей, только шейпы - боксы и сферы). Но при увеличении матрицы лучей, производительность быстро падает до неиграбельной. Конечно, для рейкастинга (X) нужно значительно меньше лучей, чем для рейтрейсинга (X×Y), и сами лучи по идее должны быть дешевле (2D вместо 3D), но всё равно есть сомнения...
>>23868
С чего взял, что я участвовал в твг? Я не участвовал.
>>23869
Вот прям на 100% готового нет, но его легко реализовать с помощью двух TextureProgress, один будет отображать актуальное здоровье (сниженное), а другой, под ним - плавную анимацию снижения здоровья от прежнего уровня до нового, например, так:
https://youtu.be/YEZXVK1-tlU
>твг
С чего взял, что я участвовал в твг? Я не участвовал.
>>23869
>при изменении бара, он закрашивается третьим цветом/текстурой, на величину, на которую он изменится, затем изменяется
>есть ли для этого готовый функционал?
Вот прям на 100% готового нет, но его легко реализовать с помощью двух TextureProgress, один будет отображать актуальное здоровье (сниженное), а другой, под ним - плавную анимацию снижения здоровья от прежнего уровня до нового, например, так:
https://youtu.be/YEZXVK1-tlU
>>23862
Не, я хотел обьект/текст альфаканалом анимировано постепенно показывать, но столкнулся с тем, что UV мертв. Особенно в тексте.
Не, я хотел обьект/текст альфаканалом анимировано постепенно показывать, но столкнулся с тем, что UV мертв. Особенно в тексте.
>>23873
Зря я сомневался, больше тысячи лучей в 2D обрабатывает без каких-либо проблем. Тем более что для такого рода игры много лучей не нужно, т.к. на прямоугольники должны накладываться кусочки текстур блоков стен.
Только мне непонятно, почему у меня перспектива такая кривая. Вроде лучи излучаю правильно, а стены изогнутые и вообще большие проблемы с восприятием расстояния. Погуглил - похоже, прямоугольники должны быть разной толщины, но пока что не представляю себе, как это реализовать.
Нет, конечно, я нашёл пример на JavaScript, но мне захотелось самому с нуля реализовать, а не копипастить готовое(
>хватит ли тебе производительности
Зря я сомневался, больше тысячи лучей в 2D обрабатывает без каких-либо проблем. Тем более что для такого рода игры много лучей не нужно, т.к. на прямоугольники должны накладываться кусочки текстур блоков стен.
Только мне непонятно, почему у меня перспектива такая кривая. Вроде лучи излучаю правильно, а стены изогнутые и вообще большие проблемы с восприятием расстояния. Погуглил - похоже, прямоугольники должны быть разной толщины, но пока что не представляю себе, как это реализовать.
Нет, конечно, я нашёл пример на JavaScript, но мне захотелось самому с нуля реализовать, а не копипастить готовое(
>>23971
https://youtu.be/gYRrGTC7GtA?t=872
>Только мне непонятно, почему у меня перспектива такая кривая
https://youtu.be/gYRrGTC7GtA?t=872
>>23921 (Del)
В чем проблема-то? У обоих опенсорсная лицензия. Все вокруг колхозное, все вокруг мое.
В чем проблема-то? У обоих опенсорсная лицензия. Все вокруг колхозное, все вокруг мое.
>>23976
Что ещё за "воксельные спрайты"?
Спрайт - это 2D картинка.
Воксель - это точка в трёхмерном пространстве.
Из вокселей можно создавать скульптуры, 3D модели.
Эти модели можно рендерить разными способами, но в любом случае это не имеет отношения к рейкастингу. Самый близкий к рейкастингу способ рендеринга вокселей - рейтрейсинг, но на GDScript нормальный рейтрейсинг не получится, максимум такое: >>23873, потому что все эти рейкасты на процессоре в один поток + ограниченная производительность GDScript.
Я видел воксельные движки, где трушные воксели рисуются цветными точками (т.е. никаких пикселявых кубов), но даже не знаю, какая там магия внутри творится. Это очень сложно оптимизировать, мне кажется. К тому же пользы от использования Godot (или любого другого универсального движка) для трушно воксельной игры практически не будет.
>помимо обычных спрайтов воткнуть воксельные
Что ещё за "воксельные спрайты"?
Спрайт - это 2D картинка.
Воксель - это точка в трёхмерном пространстве.
Из вокселей можно создавать скульптуры, 3D модели.
Эти модели можно рендерить разными способами, но в любом случае это не имеет отношения к рейкастингу. Самый близкий к рейкастингу способ рендеринга вокселей - рейтрейсинг, но на GDScript нормальный рейтрейсинг не получится, максимум такое: >>23873, потому что все эти рейкасты на процессоре в один поток + ограниченная производительность GDScript.
Я видел воксельные движки, где трушные воксели рисуются цветными точками (т.е. никаких пикселявых кубов), но даже не знаю, какая там магия внутри творится. Это очень сложно оптимизировать, мне кажется. К тому же пользы от использования Godot (или любого другого универсального движка) для трушно воксельной игры практически не будет.
267 Кб, 1128x525>>23992
Объёмная матрица из вокселей размерами i j k
Я хочу сделать, и давно, ещё с конца 00х, спрайтовую анимацию из вокселей - кадр вот такая вот матрица и они следуют в файле один за другим, всё как в 2д, даже как хранить или уменьшить количество их придумал
Касаемо кастинга, то в команче они именно так и рисуются - столбики на экране, поэтому то оно и выглядело детализированнее чем тогдашнее 3д
Касаемо оптимизации, то тут скорее всего придётся дробить пространство на области и отслеживать объёмную трапецию
Рисовка вокселей - отсеивание относительно линии обзора камеры или плоскости
Дум бы снова порвал игровую индустрию, замени там все спрайты на трёхмерные воксельные, а стены на плоскости воксельные, я это в унити давно уже родил, да со светом беда
Так как шейдер это универсальная программа, то попробую бахнуть на годо.
Достаточно то сделать аналог рейкастер двигла и всё
Ты только представь игровой опыт, когда монстры ТРЁХМЕРНЫЕ, когда всё окружение не плоское, а РЕЛЬЕФНОЕ
Весь мир застынет от ахуевания, а местный сернут ненавистник годо так вообще улетит к краю вселенной.
> Что ещё за "воксельные спрайты"?
Объёмная матрица из вокселей размерами i j k
Я хочу сделать, и давно, ещё с конца 00х, спрайтовую анимацию из вокселей - кадр вот такая вот матрица и они следуют в файле один за другим, всё как в 2д, даже как хранить или уменьшить количество их придумал
Касаемо кастинга, то в команче они именно так и рисуются - столбики на экране, поэтому то оно и выглядело детализированнее чем тогдашнее 3д
Касаемо оптимизации, то тут скорее всего придётся дробить пространство на области и отслеживать объёмную трапецию
Рисовка вокселей - отсеивание относительно линии обзора камеры или плоскости
Дум бы снова порвал игровую индустрию, замени там все спрайты на трёхмерные воксельные, а стены на плоскости воксельные, я это в унити давно уже родил, да со светом беда
Так как шейдер это универсальная программа, то попробую бахнуть на годо.
Достаточно то сделать аналог рейкастер двигла и всё
Ты только представь игровой опыт, когда монстры ТРЁХМЕРНЫЕ, когда всё окружение не плоское, а РЕЛЬЕФНОЕ
Весь мир застынет от ахуевания, а местный сернут ненавистник годо так вообще улетит к краю вселенной.
>>23992
Вот это, нашёл:
https://youtube.com/channel/UCM2RhfMLoLqG24e_DYgTQeA/videos
https://twitter.com/ProgrammerLin
Жаль, что он перестал выходить на связь; надеюсь, он ещё жив и вернётся к проекту. Автор Cube World, например, пропал на 6 лет, но, тем не менее, всё же релизнул игру...
>>23998
Это не спрайт, это воксельная модель.
Не спрайтовая, а, наверное, покадровая, хотя "кадр" тоже не очень подходит для воксельных моделей. Посмотри по ссылкам выше, там в одном из видео видно анимации животных и травы - как раз покадровая воксельная анимация.
...по-моему, ты потерялся во времени.
Чем рельефные полигональные меши хуже вокселей? В любом случае, всю историю видеокарты оптимизировали под работу с мешами, а не с вокселями. Сегодня делать трушно воксельные движки слишком тяжело - нет подходящего железа. Много памяти, много мощности ЦПУ/ГПУ только на рендер. А всё зачем? Единственное реальное преимущество вокселей - абсолютная разрушаемость, но так ли она нужна? Большинству игр разрушаемое окружение только повредит. В общем, воксели ещё долгое время будут очень нишевой игрушкой для программистов, и неизвестно, наступит ли для них другое время (т.к. современные процессоры уже не могут наращивать мощность ядра прежними темпами, а в какой-то момент рост вообще прекратится).
С ним бесполезно спорить. И уж тем более утраченные технологии древних не изменят его мнения, потому что его, похоже, интересуют только фотореалистичные большие миры. Добиться фотореализма вокселями на бытовом компьютере сегодня возможно, но не в реальном времени, а мы как бы игры обсуждаем, для нас 60+ фпс должно быть важнее реализма...
>воксельные движки, где трушные воксели
Вот это, нашёл:
https://youtube.com/channel/UCM2RhfMLoLqG24e_DYgTQeA/videos
https://twitter.com/ProgrammerLin
Жаль, что он перестал выходить на связь; надеюсь, он ещё жив и вернётся к проекту. Автор Cube World, например, пропал на 6 лет, но, тем не менее, всё же релизнул игру...
>>23998
>Объёмная матрица из вокселей
Это не спрайт, это воксельная модель.
>спрайтовую анимацию из вокселей
Не спрайтовая, а, наверное, покадровая, хотя "кадр" тоже не очень подходит для воксельных моделей. Посмотри по ссылкам выше, там в одном из видео видно анимации животных и травы - как раз покадровая воксельная анимация.
>Дум бы снова порвал игровую индустрию
...по-моему, ты потерялся во времени.
>Ты только представь игровой опыт, когда монстры ТРЁХМЕРНЫЕ, когда всё окружение не плоское, а РЕЛЬЕФНОЕ
Чем рельефные полигональные меши хуже вокселей? В любом случае, всю историю видеокарты оптимизировали под работу с мешами, а не с вокселями. Сегодня делать трушно воксельные движки слишком тяжело - нет подходящего железа. Много памяти, много мощности ЦПУ/ГПУ только на рендер. А всё зачем? Единственное реальное преимущество вокселей - абсолютная разрушаемость, но так ли она нужна? Большинству игр разрушаемое окружение только повредит. В общем, воксели ещё долгое время будут очень нишевой игрушкой для программистов, и неизвестно, наступит ли для них другое время (т.к. современные процессоры уже не могут наращивать мощность ядра прежними темпами, а в какой-то момент рост вообще прекратится).
>местный сернут ненавистник годо
С ним бесполезно спорить. И уж тем более утраченные технологии древних не изменят его мнения, потому что его, похоже, интересуют только фотореалистичные большие миры. Добиться фотореализма вокселями на бытовом компьютере сегодня возможно, но не в реальном времени, а мы как бы игры обсуждаем, для нас 60+ фпс должно быть важнее реализма...
>>24021
Я видел его работы, аж присел от сложности его трудов
Но ты смотришь именно на сложный способ, я же про стиль графики, не потребуется много памяти
Я видел его работы, аж присел от сложности его трудов
Но ты смотришь именно на сложный способ, я же про стиль графики, не потребуется много памяти
2,8 Мб, mp4,1200x600, 0:40
>>23971
Всё, я сдаюсь, это невозможно отладить. Сколько ни менял угол (разброс лучей) и дальность обзора (длина лучей) - всё какая-то фигня: проходы слишком узкие, стены слишком близко или слишком далеко, стоя под острым углом к стене - стена изгибается (косинус тут не помогает), прямые углы чаще всего округлые. Как потом на это ещё текстуры натягивать - вообще не хочется думать.
Лучше посмотрите, как другие могут:
https://github.com/andrew-lim/html5-raycast
Идеальная геометрия, ровные углы, текстуры. Магия какая-то. Я мельком глядел код - вроде мало строк и выражения простые, а всё равно что-то сложное происходит. Можно было бы скопировать на GDScript, но меня такое не интересует вообще.
Всё, я сдаюсь, это невозможно отладить. Сколько ни менял угол (разброс лучей) и дальность обзора (длина лучей) - всё какая-то фигня: проходы слишком узкие, стены слишком близко или слишком далеко, стоя под острым углом к стене - стена изгибается (косинус тут не помогает), прямые углы чаще всего округлые. Как потом на это ещё текстуры натягивать - вообще не хочется думать.
Лучше посмотрите, как другие могут:
https://github.com/andrew-lim/html5-raycast
Идеальная геометрия, ровные углы, текстуры. Магия какая-то. Я мельком глядел код - вроде мало строк и выражения простые, а всё равно что-то сложное происходит. Можно было бы скопировать на GDScript, но меня такое не интересует вообще.
>>24062
А, стоп... Точно. Я же совсем не подумал о том, какого размера у меня клетки карты. Мне казалось, что они должны выглядеть большими, и поэтому я ожидал широкие проходы и т.д. Но на деле персонаж лишь немного тоньше этих проходов, чтобы проходить сквозь них. Если представить, что персонаж - человек, то проходы будут где-то 0.5 метра в ширину, т.е. одна клетка = 0.5×0.5 метров. А самая большая пустая комната размером 4.5×4.5 метра. Тогда, наверное, всё рендерится не так уж плохо. Просто нужно либо персонажа уменьшить и скорость движения снизить, либо делать карту большей площади из большего количества тайлов.
Но это всё не решает проблемы гнутых стен. Не понимаю, эффект рыбьего глаза вроде исправил (подсмотрел в том JS примере), т.е. стена при взгляде под прямым углом к ней выглядит ровной, но если смотреть под острым углом - изгибается... Возможно, на периферии должно быть меньше лучей, чем в центре?
А, стоп... Точно. Я же совсем не подумал о том, какого размера у меня клетки карты. Мне казалось, что они должны выглядеть большими, и поэтому я ожидал широкие проходы и т.д. Но на деле персонаж лишь немного тоньше этих проходов, чтобы проходить сквозь них. Если представить, что персонаж - человек, то проходы будут где-то 0.5 метра в ширину, т.е. одна клетка = 0.5×0.5 метров. А самая большая пустая комната размером 4.5×4.5 метра. Тогда, наверное, всё рендерится не так уж плохо. Просто нужно либо персонажа уменьшить и скорость движения снизить, либо делать карту большей площади из большего количества тайлов.
Но это всё не решает проблемы гнутых стен. Не понимаю, эффект рыбьего глаза вроде исправил (подсмотрел в том JS примере), т.е. стена при взгляде под прямым углом к ней выглядит ровной, но если смотреть под острым углом - изгибается... Возможно, на периферии должно быть меньше лучей, чем в центре?
>>24064 (Del)
Тем не менее, здесь:
https://github.com/andrew-lim/html5-raycast/blob/master/raycast3d.htm#L630
И здесь: >>23973
Используются косинусы от угла луча.
>синусов там никаких вроде быть не должно
Тем не менее, здесь:
https://github.com/andrew-lim/html5-raycast/blob/master/raycast3d.htm#L630
И здесь: >>23973
Используются косинусы от угла луча.
>>24071 (Del)
Насколько я понял тот код, то там идёт умножение на косинус угла относительно центральной линии взгляда игрока
Насколько я понял тот код, то там идёт умножение на косинус угла относительно центральной линии взгляда игрока
>>24142
Под конкретную игру ищи и потом уже под конкрентые задачи, есть видео длинной не более 5 - 10 минут, быстро научишься.
Под конкретную игру ищи и потом уже под конкрентые задачи, есть видео длинной не более 5 - 10 минут, быстро научишься.
>>24159
Спасибо
Спасибо
Я тут вылез из небытия впервые с февраля.
Помню, что в этом году 4 версия должна выйти.
И увидел, что там вместо gdnative теперь gdextensions.
И у себя я дошёл до стадии, когда надо завозить быстроту в циклы.
Короче вопрос в том, насколько работа с гднэйтив отличается от работы с гдэкстеншенс?
Помню, что в этом году 4 версия должна выйти.
И увидел, что там вместо gdnative теперь gdextensions.
И у себя я дошёл до стадии, когда надо завозить быстроту в циклы.
Короче вопрос в том, насколько работа с гднэйтив отличается от работы с гдэкстеншенс?
>>24219
Эм, скорее всего у тебя кривая архитектура. Циклы не нужны, если в них ты не перебираешь 90% объектов для действия.
Эм, скорее всего у тебя кривая архитектура. Циклы не нужны, если в них ты не перебираешь 90% объектов для действия.
>>24221
У меня нужны. Мне как раз нужен последовательный перебор объектов. Мне надо в пошаговой задать связанность клеток для ходов, чтобы потом astar работал нормально.
У меня нужны. Мне как раз нужен последовательный перебор объектов. Мне надо в пошаговой задать связанность клеток для ходов, чтобы потом astar работал нормально.
Аноны, а есть какая то годная статья или видео где разжёвывают вектора, трансформации, ворлд_ориджины, бэйсисы и все эти методы? В офф документации нихуя непонятно, я слишком тупой для нее, но математику понимаю, по алгебре и геометрии четверки были.
>>24278 (Del)
В дополнение к этому посту анона я хочу добавить, что для любителей кватернионов есть функции конвертации из туда в обратно и наоборот, чтобы все операции делать кватернионами, а результат конвертировать в трансформ.
Квартернионы хороши для создания авиасимуляторов, потому что в них решена проблема "Складывание рамок", или блокировка карданного подвеса, также ошибочно шарнирный замок (жарг.) (англ. gimbal lock)
В дополнение к этому посту анона я хочу добавить, что для любителей кватернионов есть функции конвертации из туда в обратно и наоборот, чтобы все операции делать кватернионами, а результат конвертировать в трансформ.
Квартернионы хороши для создания авиасимуляторов, потому что в них решена проблема "Складывание рамок", или блокировка карданного подвеса, также ошибочно шарнирный замок (жарг.) (англ. gimbal lock)
>>24219
Они о нём ещё несколько лет назад говорили... Я думаю, нужно сначала беты 4.0 дождаться. Документацию до конца доделают только к релизу, наверное, т.е. к зиме.
>>24251
Делаешь это перед началом игры, на загрузочном экране - и всё, никаких проблем, игрок подождёт сколько будет нужно (1.5 секунды поди?). Если у тебя вот прям невероятно огромная карта, тогда дели её на части и меняй геймплей соответственно, иначе никак. Особенно если твой код взаимодействует с API движка или ОС, тут можно ускориться только убрав это взаимодействие.
>вместо gdnative теперь gdextensions
Они о нём ещё несколько лет назад говорили... Я думаю, нужно сначала беты 4.0 дождаться. Документацию до конца доделают только к релизу, наверное, т.е. к зиме.
>>24251
>Мне надо в пошаговой задать связанность клеток для ходов, чтобы потом astar работал нормально.
Делаешь это перед началом игры, на загрузочном экране - и всё, никаких проблем, игрок подождёт сколько будет нужно (1.5 секунды поди?). Если у тебя вот прям невероятно огромная карта, тогда дели её на части и меняй геймплей соответственно, иначе никак. Особенно если твой код взаимодействует с API движка или ОС, тут можно ускориться только убрав это взаимодействие.
>>24311
Двачую этого.
Не в первый раз замечаю, что новички в геймдеве, глядя на существующие ААА-опенворлды, уверены в том, что те опенворлды существуют в оперативке одномоментно. Никакие аргументы их не вразумляют. Они свято верят, что когда какой-нибудь Нейтан Дрейк, закрывает за собой очередную сюжетную дверь, мир за той дверью продолжает существовать, и при желании, дверь можно открыть и вернуться обратно. Нет. При закрытии двери чанк выгружается из памяти.
Красивые горы вдалеке - это простые меши без коллизий.
Машины вдалеке - это простые меши без физики, ездящие по сплайнам-рельсам.
Птицы в небе это простые спрайты.
Лифты, заваленные двери, которые игровые герои преодолевают за некоторое время - это замены экрана загрузки.
Посмотрите на ютубе разборы спидранов различных игор. Именно там вся эта внутренняя кухня вылезает наружу, разрушая иллюзию единомоментно существующего опенворлда.
И перестаньте лепить на одну карту невпихуемое.
> Если у тебя вот прям невероятно огромная карта, тогда дели её на части и меняй геймплей соответственно, иначе никак. Особенно если твой код взаимодействует с API движка или ОС, тут можно ускориться только убрав это взаимодействие.
Двачую этого.
Не в первый раз замечаю, что новички в геймдеве, глядя на существующие ААА-опенворлды, уверены в том, что те опенворлды существуют в оперативке одномоментно. Никакие аргументы их не вразумляют. Они свято верят, что когда какой-нибудь Нейтан Дрейк, закрывает за собой очередную сюжетную дверь, мир за той дверью продолжает существовать, и при желании, дверь можно открыть и вернуться обратно. Нет. При закрытии двери чанк выгружается из памяти.
Красивые горы вдалеке - это простые меши без коллизий.
Машины вдалеке - это простые меши без физики, ездящие по сплайнам-рельсам.
Птицы в небе это простые спрайты.
Лифты, заваленные двери, которые игровые герои преодолевают за некоторое время - это замены экрана загрузки.
Посмотрите на ютубе разборы спидранов различных игор. Именно там вся эта внутренняя кухня вылезает наружу, разрушая иллюзию единомоментно существующего опенворлда.
И перестаньте лепить на одну карту невпихуемое.
>>24316
Достаточно запустить, например, GTA 5 на слабом двухъядерном процессоре и медленном HDD. Вступительную миссию ты в любом случае пройдёшь, потому что она в отдельном месте происходит, а вот в городе любая поездка будет заканчиваться тем, что ты стоишь на воздухе в пустом пространстве, наблюдая, как вокруг тебя ездят по воздуху машины, и ждёшь, когда загрузится всё остальное (дома и дороги). Потому что загрузка чанков не успевает за скоростью передвижения игрока на машине.
Но это GTA, а что на счёт симуляторов? Ты не можешь просто выкинуть из памяти всю информацию о чанке, потому что внутри него должны непрерывно перемещаться NPC. Логично обсчитывать путь в рамках чанковой системы и каждого чанка по отдельности, чтобы не работать с огромным массивом точек во всех чанках одновременно. Я про это писал (навигация астаром в сверхбольшой карте мира), а не про чанки в общем и целом. Если игра 2D и геймплей не требует бесшовных карт (как в РПГ), тогда можно создать для каждой карты отдельный AStar и NPC будут обращаться только к нему, а не к гигантской сетке размером в весь мир. Если же AStar нужен только для игрока, то его можно заполнять при переходе в следующую комнату, как раз на экране загрузки.
>Никакие аргументы их не вразумляют.
Достаточно запустить, например, GTA 5 на слабом двухъядерном процессоре и медленном HDD. Вступительную миссию ты в любом случае пройдёшь, потому что она в отдельном месте происходит, а вот в городе любая поездка будет заканчиваться тем, что ты стоишь на воздухе в пустом пространстве, наблюдая, как вокруг тебя ездят по воздуху машины, и ждёшь, когда загрузится всё остальное (дома и дороги). Потому что загрузка чанков не успевает за скоростью передвижения игрока на машине.
Но это GTA, а что на счёт симуляторов? Ты не можешь просто выкинуть из памяти всю информацию о чанке, потому что внутри него должны непрерывно перемещаться NPC. Логично обсчитывать путь в рамках чанковой системы и каждого чанка по отдельности, чтобы не работать с огромным массивом точек во всех чанках одновременно. Я про это писал (навигация астаром в сверхбольшой карте мира), а не про чанки в общем и целом. Если игра 2D и геймплей не требует бесшовных карт (как в РПГ), тогда можно создать для каждой карты отдельный AStar и NPC будут обращаться только к нему, а не к гигантской сетке размером в весь мир. Если же AStar нужен только для игрока, то его можно заполнять при переходе в следующую комнату, как раз на экране загрузки.
>>24328
Не должны. Достаточно, чтобы ИИ-манагер раз в минуту обновлял данные у себя в табличке о том, где находится и что делает НПЦ. Чтобы при загрузке чанка, загрузить тех НПЦ, которые согласно ГОАП-табличке в загружаемом чанке находятся.
Если сверхбольшая карта это просто абстрактная таблица - то работа с ней сверхбыстра, никакя навигация не нужна. Тв просто обновляешь у себя в табличках:
И всё, если игрок в этот период игрового времени зайдёт в кафе в Барановке, игра наричует ему за одним из столиков Петрова. И игре не надо было всё это время считать Петрову навигацию, коллизии и прочее. Он просто не существовал всё это время, всё это время менеджер ИИ, словно гейм-мастер в днд придумывал, где может быть Иванов, петров, Сидоров, в каждый следующий момент, чтобы, когда ты загрузишь очередную локацию, нарисовать в ней тех, кто там по расчётам менеджера ИИ оказался.
> потому что внутри него должны непрерывно перемещаться NPC
Не должны. Достаточно, чтобы ИИ-манагер раз в минуту обновлял данные у себя в табличке о том, где находится и что делает НПЦ. Чтобы при загрузке чанка, загрузить тех НПЦ, которые согласно ГОАП-табличке в загружаемом чанке находятся.
> навигация астаром в сверхбольшой карте мира
Если сверхбольшая карта это просто абстрактная таблица - то работа с ней сверхбыстра, никакя навигация не нужна. Тв просто обновляешь у себя в табличках:
> Иванов прошёл Козловку, остановился на заправке.
> Петров остановился в Барановке и зашёл в придорожное кафе.
> Сидоров движется по М123 в сторону Собачинска.
И всё, если игрок в этот период игрового времени зайдёт в кафе в Барановке, игра наричует ему за одним из столиков Петрова. И игре не надо было всё это время считать Петрову навигацию, коллизии и прочее. Он просто не существовал всё это время, всё это время менеджер ИИ, словно гейм-мастер в днд придумывал, где может быть Иванов, петров, Сидоров, в каждый следующий момент, чтобы, когда ты загрузишь очередную локацию, нарисовать в ней тех, кто там по расчётам менеджера ИИ оказался.
>>24331
Сорян за опечатки. У меня от жары уже руки трясутся. И вычитать пост забыл.
Сорян за опечатки. У меня от жары уже руки трясутся. И вычитать пост забыл.
>>24311
Пошаговая стратегия. Время в минутах.
Просто перебрать в памяти массив чисел от 0 до х для условной карты 300 на 500 с 8 сложениями и вычитаниями с 3 или 4 if. Без привязки к каким-либо игровым объектам на этой стадии. Почему на каждый вопрос тут вместо ответа начинают сразу придумывать оптимизацию для придуманных ситуаций, будто там всё уже присобаченов в процесс, без инстанцирования и прочего?
>Делаешь это перед началом игры, на загрузочном экране - и всё, никаких проблем, игрок подождёт сколько будет нужно (1.5 секунды поди?).
Пошаговая стратегия. Время в минутах.
Просто перебрать в памяти массив чисел от 0 до х для условной карты 300 на 500 с 8 сложениями и вычитаниями с 3 или 4 if. Без привязки к каким-либо игровым объектам на этой стадии. Почему на каждый вопрос тут вместо ответа начинают сразу придумывать оптимизацию для придуманных ситуаций, будто там всё уже присобаченов в процесс, без инстанцирования и прочего?
>>24337
300*500 это 150_000 прогонов. Каждый кадр надеюсь, и для 150 юнитов? ;)
300*500 это 150_000 прогонов. Каждый кадр надеюсь, и для 150 юнитов? ;)
>>24337
Потому что ты неправильно задаёшь вопросы, в стиле "проблема XY"
> Почему на каждый вопрос тут вместо ответа начинают сразу придумывать оптимизацию для придуманных ситуаций
Потому что ты неправильно задаёшь вопросы, в стиле "проблема XY"
>>24337
Если это нужно для навигации юнитов, то это должно происходить один раз на старте игры, если карта процедурная. Если карта заранее создана, все эти числа можно сохранить в файл и просто загружать. Если карта разрушаемая, достаточно обновлять отдельные клетки в AStar, они не зря по ID доступны.
Если это нужно тебе для ИИ противника, ты реально брутфорсом перебираешь всю карту по 8 раз на каждый юнит, проверяя какие-то 3-4 условия на каждой клетке? Во-первых, ИИ должен мыслить в общих чертах: "у меня столько-то юнитов здесь, у противника столько-то юнитов вон там", а не обсчитывать каждую клетку, ища своих и чужих юнитов после каждого хода. Во-вторых, юниты в стратегиях обычно очень ограничены в движениях, нет смысла проверять клетки всей карты для передвижения одной пешки. В-третьих, игровой ИИ не должен быть слишком умным, он должен красиво проигрывать. Поэтому не бойся упрощать алгоритмы, жертвуя "умом" ИИ, если это в целом улучшает игровой опыт игрока.
>>24331
Это одно и то же. Чтобы "менеджер ИИ" мог работать с навигацией ботов в частично выгруженных чанках, часть информации об этих чанках должна оставаться в оперативной памяти. Иначе твои боты будут проходить непреодолимые препятствия, пока игрок на них не смотрит, что фатально для правдоподобной симуляции.
>Просто перебрать в памяти массив чисел от 0 до х для условной карты 300 на 500 с 8 сложениями и вычитаниями с 3 или 4 if.
Если это нужно для навигации юнитов, то это должно происходить один раз на старте игры, если карта процедурная. Если карта заранее создана, все эти числа можно сохранить в файл и просто загружать. Если карта разрушаемая, достаточно обновлять отдельные клетки в AStar, они не зря по ID доступны.
Если это нужно тебе для ИИ противника, ты реально брутфорсом перебираешь всю карту по 8 раз на каждый юнит, проверяя какие-то 3-4 условия на каждой клетке? Во-первых, ИИ должен мыслить в общих чертах: "у меня столько-то юнитов здесь, у противника столько-то юнитов вон там", а не обсчитывать каждую клетку, ища своих и чужих юнитов после каждого хода. Во-вторых, юниты в стратегиях обычно очень ограничены в движениях, нет смысла проверять клетки всей карты для передвижения одной пешки. В-третьих, игровой ИИ не должен быть слишком умным, он должен красиво проигрывать. Поэтому не бойся упрощать алгоритмы, жертвуя "умом" ИИ, если это в целом улучшает игровой опыт игрока.
>>24331
>>внутри него должны непрерывно перемещаться NPC
>всё это время менеджер ИИ, словно гейм-мастер в днд придумывал, где может быть Иванов, петров, Сидоров, в каждый следующий момент
Это одно и то же. Чтобы "менеджер ИИ" мог работать с навигацией ботов в частично выгруженных чанках, часть информации об этих чанках должна оставаться в оперативной памяти. Иначе твои боты будут проходить непреодолимые препятствия, пока игрок на них не смотрит, что фатально для правдоподобной симуляции.
>>24404
Ты так и не понял.
Ботов не существует, пока чанки выгружены. Препятствий не существует. Есть только периодически обновляемые записи о том, что бот по состоянию на 23:07 находится вот тут. Пойми уже наконец. Это же база, классика, знать надо!
> Иначе твои боты будут проходить непреодолимые препятствия, пока игрок на них не смотрит, что фатально для правдоподобной симуляции.
Ты так и не понял.
Ботов не существует, пока чанки выгружены. Препятствий не существует. Есть только периодически обновляемые записи о том, что бот по состоянию на 23:07 находится вот тут. Пойми уже наконец. Это же база, классика, знать надо!
>>24408
Ну да. Представь такую ситуацию: бот идёт из одного поселения в другое, но тропинка петляет между лесами, реками и озёрами. Вдруг игрок приходит туда, где идёт бот, и ВНЕЗАПНО видит бота, беспомощно оглядывающегося по сторонам на маленьком островке суши посередине бурной реки, при том что ни один персонаж в игре в принципе плавать не может. Да даже если и может - какой смысл перебираться вплавь через реку, если буквально в нескольких метрах есть мост через реку? А чтобы навигатор ботов не делал таких косяков, он должен точно знать, что находится в каждом чанке, какие там препятствия и дороги, каким путём логичнее идти. И всё это должно быть в реальном времени, а не раз в 10 минут, потому что игрок может зайти в любой момент. Ты можешь сказать, что для игры с фиксированной неизменяемой картой можно задать всем ботам фиксированные маршруты, но, во-первых, это не очень-то честная симуляция получается, во-вторых, таки существуют игры с процедурной генерацией и/или изменяемой картой, где ты не можешь заранее знать все маршруты, не храня в памяти хотя бы часть информации об этой карте. А что, если боты могут менять ландшафт в скрытых чанках? Крестьянин решил выкопать пруд или колодец, и теперь на месте прежней тропинки яма - ИИ должен это учитывать, чтобы после появления игрока бот не застрял в безвыходной ситуации. Или если бот построил себе домик, и в нём внезапно оказались дикие звери, сбившиеся с пути из-за того, что искали этот путь в выгруженных чанках, лол.
>Препятствий не существует
Ну да. Представь такую ситуацию: бот идёт из одного поселения в другое, но тропинка петляет между лесами, реками и озёрами. Вдруг игрок приходит туда, где идёт бот, и ВНЕЗАПНО видит бота, беспомощно оглядывающегося по сторонам на маленьком островке суши посередине бурной реки, при том что ни один персонаж в игре в принципе плавать не может. Да даже если и может - какой смысл перебираться вплавь через реку, если буквально в нескольких метрах есть мост через реку? А чтобы навигатор ботов не делал таких косяков, он должен точно знать, что находится в каждом чанке, какие там препятствия и дороги, каким путём логичнее идти. И всё это должно быть в реальном времени, а не раз в 10 минут, потому что игрок может зайти в любой момент. Ты можешь сказать, что для игры с фиксированной неизменяемой картой можно задать всем ботам фиксированные маршруты, но, во-первых, это не очень-то честная симуляция получается, во-вторых, таки существуют игры с процедурной генерацией и/или изменяемой картой, где ты не можешь заранее знать все маршруты, не храня в памяти хотя бы часть информации об этой карте. А что, если боты могут менять ландшафт в скрытых чанках? Крестьянин решил выкопать пруд или колодец, и теперь на месте прежней тропинки яма - ИИ должен это учитывать, чтобы после появления игрока бот не застрял в безвыходной ситуации. Или если бот построил себе домик, и в нём внезапно оказались дикие звери, сбившиеся с пути из-за того, что искали этот путь в выгруженных чанках, лол.
>>24410
Не должен навигатор знать что там, вода или что. Навигатору нужно накинуть пару десятков векторов объединенных в граф и водить по ним ботов относительно прошедшему времени.
Не должен навигатор знать что там, вода или что. Навигатору нужно накинуть пару десятков векторов объединенных в граф и водить по ним ботов относительно прошедшему времени.
>>24404
Именно. Но вряд ли кого устроит на старте каждой игры на рандомной карте ждать пару минут загрузки карты.
>Если это нужно для навигации юнитов, то это должно происходить один раз на старте игры, если карта процедурная.
Именно. Но вряд ли кого устроит на старте каждой игры на рандомной карте ждать пару минут загрузки карты.
>>24410
Если чанки автогенерируемые, то при их генерации генерируем навмеш, гарантированно не имеющий замкнутых внутри чанка областей. Спавним ботов в пределах навмеша.
Если чанки кропотливо созданные вручнуюtm, то так же кропотливо прорабатываем намеш.
Что за хуйня? Зачем ты выдумываешь глупые проблемы, у которых элементарные решения? Ты прокрастинатор? Иди игру делай, вместо того, чтобы пиздеть.
Если чанки автогенерируемые, то при их генерации генерируем навмеш, гарантированно не имеющий замкнутых внутри чанка областей. Спавним ботов в пределах навмеша.
Если чанки кропотливо созданные вручнуюtm, то так же кропотливо прорабатываем намеш.
Что за хуйня? Зачем ты выдумываешь глупые проблемы, у которых элементарные решения? Ты прокрастинатор? Иди игру делай, вместо того, чтобы пиздеть.
Если вы измените значение на ''PhysicsMaterial'' одного экземпляра — это повлияет на все остальные. Это связано с тем, что ''PhysicsMaterial'' является ресурсом, а ресурсы используются экземплярами совместно. Чтобы сделать ресурс уникальным для одного экземпляра, щелкните его правой кнопкой мыши в Инспекторе и выберите в контекстном меню команду Сделать уникальным.
Я не понял. Речь идет именно PhysicsMateria или вкладки в нем типо Боунс? Я просто поменял у одного боунч, но у других он судя по интерфейску не изменился.
Я не понял. Речь идет именно PhysicsMateria или вкладки в нем типо Боунс? Я просто поменял у одного боунч, но у других он судя по интерфейску не изменился.
>>24547
а не поменялся
а не поменялся
Почему у Vector2(0, 0) только 2 координаты? Должно же быть 4 как у вектора - начальная и конечная. Или за начальную приняты координаты родительского объекта?
Хуево что в гдскрипте нет строгой типизации.
И где вообще правила приведения типо почитать?
умножаешь вектор(координаты) на флоат.
Или вот var x= 5, вот какой тип у X тут? Флоат, интигер?
И где вообще правила приведения типо почитать?
умножаешь вектор(координаты) на флоат.
Или вот var x= 5, вот какой тип у X тут? Флоат, интигер?
>>24606
путаешь с отрезком. у 2д вектора две координаты. можешь думать, что начальной точкой всех векторов является 0,0, а конечной - координаты вектора
путаешь с отрезком. у 2д вектора две координаты. можешь думать, что начальной точкой всех векторов является 0,0, а конечной - координаты вектора
18 Кб, 497x115>>24614
ну вообще он связан с системой отсчета и его начальные координат 0.0 должны быть
Вот только зачем здесь rotated тогда?
То есть я нажимаю вверх(по Y это минус), и он как бы поворачивает всю координатную сетку?
ну вообще он связан с системой отсчета и его начальные координат 0.0 должны быть
Вот только зачем здесь rotated тогда?
То есть я нажимаю вверх(по Y это минус), и он как бы поворачивает всю координатную сетку?
Т.е. до этого уже повренут спрайт,
и если юзать без rotated - то просто будет этот спрайт в повернутом виде вверх двигаться.
А так получается он двигается вперед(можно повернуть в любую сторону), хотя нажимаю я только вверх.
По факту это значит что вся координатная плоскость вращается?
и если юзать без rotated - то просто будет этот спрайт в повернутом виде вверх двигаться.
А так получается он двигается вперед(можно повернуть в любую сторону), хотя нажимаю я только вверх.
По факту это значит что вся координатная плоскость вращается?
>>24619
Вектор - отдельная сущность, он не связан со спрайтом.
Любой вектор можно повернуть. Пик. Будешь ли ты использовать его как координатную сетку зависит только от тебя.
Вектор с началом и концом - это по сути сумма вектора от нуля (координаты) и собственно твоего вектора. Пик2
Любые ноды обладают своей координатной сеткой, в этом смысл их иерархии. Рука может быть повернута относительно плеча, а кисть - относительно руки.
Вектор - отдельная сущность, он не связан со спрайтом.
Любой вектор можно повернуть. Пик. Будешь ли ты использовать его как координатную сетку зависит только от тебя.
Вектор с началом и концом - это по сути сумма вектора от нуля (координаты) и собственно твоего вектора. Пик2
Любые ноды обладают своей координатной сеткой, в этом смысл их иерархии. Рука может быть повернута относительно плеча, а кисть - относительно руки.
>>24420
Эти вектора связаны с чанком же. Т.е. ты в любом случае нуждаешься в части информации о выгруженных чанках.
>>24446
Навмеш-то ты будешь из памяти выгружать или нет?
Что тут глупого? Мне говорят "в выгруженных чанках ничего нет и ничего не перемещается", я говорю "нет, выгруженные чанки не выгружены на 100%, иначе не удастся правильно симулировать перемещение ботов в этих чанках". Очевидное противоречие, ты не можешь говорить "выгрузи все данные", если хотя бы часть этих данных (векторы, астар, навмеш, что угодно) нужна для рассчётов, которые ты советуешь.
Да, это так.
>>24430 (Del)
Костыль. Костыли чреваты ещё большими ошибками, например, боты смогут телепортироваться за забор.
А откуда картинка? Не удаётся найти источник. Интересно, какие карты можно собирать из таких тайлов...
>накинуть пару десятков векторов
Эти вектора связаны с чанком же. Т.е. ты в любом случае нуждаешься в части информации о выгруженных чанках.
>>24446
>генерируем навмеш
Навмеш-то ты будешь из памяти выгружать или нет?
>Зачем ты выдумываешь глупые проблемы, у которых элементарные решения?
Что тут глупого? Мне говорят "в выгруженных чанках ничего нет и ничего не перемещается", я говорю "нет, выгруженные чанки не выгружены на 100%, иначе не удастся правильно симулировать перемещение ботов в этих чанках". Очевидное противоречие, ты не можешь говорить "выгрузи все данные", если хотя бы часть этих данных (векторы, астар, навмеш, что угодно) нужна для рассчётов, которые ты советуешь.
>Ты прокрастинатор?
Да, это так.
>>24430 (Del)
>если он оказался в недоступной зоне, перемещать его в ближайшую доступную.
Костыль. Костыли чреваты ещё большими ошибками, например, боты смогут телепортироваться за забор.
А откуда картинка? Не удаётся найти источник. Интересно, какие карты можно собирать из таких тайлов...
>>24618
Ну значит и есть.
А раз они всегда 0.0, тогда зачем их писать?
> ну вообще он связан с системой отсчета и его начальные координат 0.0 должны быть
Ну значит и есть.
А раз они всегда 0.0, тогда зачем их писать?
>>24639
Буду.
Хорошо. Выражусь иначе. Моё видение архитектуры опенворлда следующее:
Игровая сущность начинается с набора данных примитивных типов (инт, флоат, стринг, буль), которые эту сущность описывают.
По этим наборам данных сущности инициализируются, вызываются уже непримитивные объектные классы, создаются инстансы, и! конфигурируются из вышеописанного набора данных.
При уничтожении игровой сущности, она сохраняет свой текущий набор данных в пуле, ответственном за это. Так, что игра всегда может воссоздать эту сущность из набора данных.
Попрошу не путать этот подход с сериализацией. При сериализации мы неразрывно связаны с понятием инстанса объекта и его сериализованной репрезентации в файле либо в потоке. В описываемом мной варианте, мы держим ООП в сторонке.
Набор данных примитивных типов - не объектен, в нём только "бизнес-логика".
И вот с этой "бизнес-логикой" мы так же можем совершать манипуляции. Создавать(Create), Читать(Read), Модифицировать(Update), Удалять(Delete) в отсутствие объектов, которые должны этими данными загружаться и по своему работать с этими данными. Когда работа с данными происходит в объектах, это уже происходит по навмешам, по физике, и так далее. И это уже не просто данные, это поля и свойства объектов.
Однако, чтобы переместить игровую сущность из одной локации в другую, при этом ни одна из локаций в данный момент не загружена, для нас было бы глупо грузить локации в память. Зачем?
Мы просто удалим запись относящуюся к локации1, и добавим запись относящуюся к локации 2, что наша сущность теперь там.
Поэтому, как я уже второй тред пишу. Чанка нет. Он не существует. НПЦ нет, он не существует. Тем не менее, существует ГОАП-график непися, который по таймеру обновляется и обновляет инфу в "бизнес-логике" игры, о том, какое у НПЦ сейчас состояние, где он находится в том числе.
Затем, когда НПЦ оказывается в пределах самого дальнего ЛОДа, этот ЛОД выводит спрайты шевелящихся вдалеке неписей, в том числе нашего. При приближении в следующий ЛОД на непися накидывается меш-моделька. В следующем ЛОДе, в котором уже подгружаются навмеши, ему подкидывается физик-боди и весь функционал самостоятельного брождения по карте. И в обратном порядке аналогично с НПЦ снимаются и высвобождаются из памяти более ненужные фичи, до тех пор, пока он не исчезнет из нашего вида и снова от него останется только обновляющаяся "бизнес-логика" на примитивных типах. Только в этом смысле он можно сказать и существует.
Если я всё верно понял из гор туториалов и документаций (а так же из своего опыта в CRUD-формошлёпстве) это называется DOD. Data Oriented Design. Когда мы выполняем основную работу по симуляции мира как апдейты базы данных, а визуальная и физическая симуляция идёт к базе данных как приложение.
> Навмеш-то ты будешь из памяти выгружать или нет?
Буду.
> Что тут глупого? Мне говорят
Хорошо. Выражусь иначе. Моё видение архитектуры опенворлда следующее:
Игровая сущность начинается с набора данных примитивных типов (инт, флоат, стринг, буль), которые эту сущность описывают.
По этим наборам данных сущности инициализируются, вызываются уже непримитивные объектные классы, создаются инстансы, и! конфигурируются из вышеописанного набора данных.
При уничтожении игровой сущности, она сохраняет свой текущий набор данных в пуле, ответственном за это. Так, что игра всегда может воссоздать эту сущность из набора данных.
Попрошу не путать этот подход с сериализацией. При сериализации мы неразрывно связаны с понятием инстанса объекта и его сериализованной репрезентации в файле либо в потоке. В описываемом мной варианте, мы держим ООП в сторонке.
Набор данных примитивных типов - не объектен, в нём только "бизнес-логика".
И вот с этой "бизнес-логикой" мы так же можем совершать манипуляции. Создавать(Create), Читать(Read), Модифицировать(Update), Удалять(Delete) в отсутствие объектов, которые должны этими данными загружаться и по своему работать с этими данными. Когда работа с данными происходит в объектах, это уже происходит по навмешам, по физике, и так далее. И это уже не просто данные, это поля и свойства объектов.
Однако, чтобы переместить игровую сущность из одной локации в другую, при этом ни одна из локаций в данный момент не загружена, для нас было бы глупо грузить локации в память. Зачем?
Мы просто удалим запись относящуюся к локации1, и добавим запись относящуюся к локации 2, что наша сущность теперь там.
Поэтому, как я уже второй тред пишу. Чанка нет. Он не существует. НПЦ нет, он не существует. Тем не менее, существует ГОАП-график непися, который по таймеру обновляется и обновляет инфу в "бизнес-логике" игры, о том, какое у НПЦ сейчас состояние, где он находится в том числе.
Затем, когда НПЦ оказывается в пределах самого дальнего ЛОДа, этот ЛОД выводит спрайты шевелящихся вдалеке неписей, в том числе нашего. При приближении в следующий ЛОД на непися накидывается меш-моделька. В следующем ЛОДе, в котором уже подгружаются навмеши, ему подкидывается физик-боди и весь функционал самостоятельного брождения по карте. И в обратном порядке аналогично с НПЦ снимаются и высвобождаются из памяти более ненужные фичи, до тех пор, пока он не исчезнет из нашего вида и снова от него останется только обновляющаяся "бизнес-логика" на примитивных типах. Только в этом смысле он можно сказать и существует.
Если я всё верно понял из гор туториалов и документаций (а так же из своего опыта в CRUD-формошлёпстве) это называется DOD. Data Oriented Design. Когда мы выполняем основную работу по симуляции мира как апдейты базы данных, а визуальная и физическая симуляция идёт к базе данных как приложение.
>>24639
Буду.
Хорошо. Выражусь иначе. Моё видение архитектуры опенворлда следующее:
Игровая сущность начинается с набора данных примитивных типов (инт, флоат, стринг, буль), которые эту сущность описывают.
По этим наборам данных сущности инициализируются, вызываются уже непримитивные объектные классы, создаются инстансы, и! конфигурируются из вышеописанного набора данных.
При уничтожении игровой сущности, она сохраняет свой текущий набор данных в пуле, ответственном за это. Так, что игра всегда может воссоздать эту сущность из набора данных.
Попрошу не путать этот подход с сериализацией. При сериализации мы неразрывно связаны с понятием инстанса объекта и его сериализованной репрезентации в файле либо в потоке. В описываемом мной варианте, мы держим ООП в сторонке.
Набор данных примитивных типов - не объектен, в нём только "бизнес-логика".
И вот с этой "бизнес-логикой" мы так же можем совершать манипуляции. Создавать(Create), Читать(Read), Модифицировать(Update), Удалять(Delete) в отсутствие объектов, которые должны этими данными загружаться и по своему работать с этими данными. Когда работа с данными происходит в объектах, это уже происходит по навмешам, по физике, и так далее. И это уже не просто данные, это поля и свойства объектов.
Однако, чтобы переместить игровую сущность из одной локации в другую, при этом ни одна из локаций в данный момент не загружена, для нас было бы глупо грузить локации в память. Зачем?
Мы просто удалим запись относящуюся к локации1, и добавим запись относящуюся к локации 2, что наша сущность теперь там.
Поэтому, как я уже второй тред пишу. Чанка нет. Он не существует. НПЦ нет, он не существует. Тем не менее, существует ГОАП-график непися, который по таймеру обновляется и обновляет инфу в "бизнес-логике" игры, о том, какое у НПЦ сейчас состояние, где он находится в том числе.
Затем, когда НПЦ оказывается в пределах самого дальнего ЛОДа, этот ЛОД выводит спрайты шевелящихся вдалеке неписей, в том числе нашего. При приближении в следующий ЛОД на непися накидывается меш-моделька. В следующем ЛОДе, в котором уже подгружаются навмеши, ему подкидывается физик-боди и весь функционал самостоятельного брождения по карте. И в обратном порядке аналогично с НПЦ снимаются и высвобождаются из памяти более ненужные фичи, до тех пор, пока он не исчезнет из нашего вида и снова от него останется только обновляющаяся "бизнес-логика" на примитивных типах. Только в этом смысле он можно сказать и существует.
Если я всё верно понял из гор туториалов и документаций (а так же из своего опыта в CRUD-формошлёпстве) это называется DOD. Data Oriented Design. Когда мы выполняем основную работу по симуляции мира как апдейты базы данных, а визуальная и физическая симуляция идёт к базе данных как приложение.
> Навмеш-то ты будешь из памяти выгружать или нет?
Буду.
> Что тут глупого? Мне говорят
Хорошо. Выражусь иначе. Моё видение архитектуры опенворлда следующее:
Игровая сущность начинается с набора данных примитивных типов (инт, флоат, стринг, буль), которые эту сущность описывают.
По этим наборам данных сущности инициализируются, вызываются уже непримитивные объектные классы, создаются инстансы, и! конфигурируются из вышеописанного набора данных.
При уничтожении игровой сущности, она сохраняет свой текущий набор данных в пуле, ответственном за это. Так, что игра всегда может воссоздать эту сущность из набора данных.
Попрошу не путать этот подход с сериализацией. При сериализации мы неразрывно связаны с понятием инстанса объекта и его сериализованной репрезентации в файле либо в потоке. В описываемом мной варианте, мы держим ООП в сторонке.
Набор данных примитивных типов - не объектен, в нём только "бизнес-логика".
И вот с этой "бизнес-логикой" мы так же можем совершать манипуляции. Создавать(Create), Читать(Read), Модифицировать(Update), Удалять(Delete) в отсутствие объектов, которые должны этими данными загружаться и по своему работать с этими данными. Когда работа с данными происходит в объектах, это уже происходит по навмешам, по физике, и так далее. И это уже не просто данные, это поля и свойства объектов.
Однако, чтобы переместить игровую сущность из одной локации в другую, при этом ни одна из локаций в данный момент не загружена, для нас было бы глупо грузить локации в память. Зачем?
Мы просто удалим запись относящуюся к локации1, и добавим запись относящуюся к локации 2, что наша сущность теперь там.
Поэтому, как я уже второй тред пишу. Чанка нет. Он не существует. НПЦ нет, он не существует. Тем не менее, существует ГОАП-график непися, который по таймеру обновляется и обновляет инфу в "бизнес-логике" игры, о том, какое у НПЦ сейчас состояние, где он находится в том числе.
Затем, когда НПЦ оказывается в пределах самого дальнего ЛОДа, этот ЛОД выводит спрайты шевелящихся вдалеке неписей, в том числе нашего. При приближении в следующий ЛОД на непися накидывается меш-моделька. В следующем ЛОДе, в котором уже подгружаются навмеши, ему подкидывается физик-боди и весь функционал самостоятельного брождения по карте. И в обратном порядке аналогично с НПЦ снимаются и высвобождаются из памяти более ненужные фичи, до тех пор, пока он не исчезнет из нашего вида и снова от него останется только обновляющаяся "бизнес-логика" на примитивных типах. Только в этом смысле он можно сказать и существует.
Если я всё верно понял из гор туториалов и документаций (а так же из своего опыта в CRUD-формошлёпстве) это называется DOD. Data Oriented Design. Когда мы выполняем основную работу по симуляции мира как апдейты базы данных, а визуальная и физическая симуляция идёт к базе данных как приложение.
>>24547
Да. И вообще про любой ресурс (класс, наследующийся от Resource). Они передаются по ссылке по умолчанию, в результате разные ноды хранят ссылку на один ресурс. Это экономит память, но в результате изменения ресурса отражаются на множестве использующих его нод. Иногда так и нужно, а если не нужно - нужно сделать дубликат ресурса, т.е. чтобы в памяти было два разных ресурса.
Это поля класса ресурса. Они уникальны, если хранят простые типы (целое или вещественное число, строку, вектор), но также ресурс может иметь вложенный ресурс, тогда там будет такая же ситуация, что и с ресурсом в полях ноды.
Это ООП, это знать надо!
>Речь идет именно PhysicsMateria
Да. И вообще про любой ресурс (класс, наследующийся от Resource). Они передаются по ссылке по умолчанию, в результате разные ноды хранят ссылку на один ресурс. Это экономит память, но в результате изменения ресурса отражаются на множестве использующих его нод. Иногда так и нужно, а если не нужно - нужно сделать дубликат ресурса, т.е. чтобы в памяти было два разных ресурса.
>вкладки в нем типо Боунс
Это поля класса ресурса. Они уникальны, если хранят простые типы (целое или вещественное число, строку, вектор), но также ресурс может иметь вложенный ресурс, тогда там будет такая же ситуация, что и с ресурсом в полях ноды.
Это ООП, это знать надо!
>>24615
Она есть, но опциональная и не до конца доделанная. В 4.0 будет лучше, чем сейчас, а пока можно указывать типы при объявлении переменных, аргументов функций, возврата из функций. Единственный минус пока что - элементам массивов и словарей нельзя задать тип, но есть специальные типизированные массивы (имена начинаются на Pool).
Почитай документацию. Многие вопросы отпадут.
И получаешь вектор, что логично, потому что ты умножаешь каждую составляющую вектора на вещественное число. На строго типизированном языке ты тоже так можешь делать, если перезагрузишь оператор умножения с аргументами вектора и вещественного числа. Здесь это просто из коробки.
Целое число, потому что без точки. Вернее, у тебя будет variant с целым числом внутри. То есть ты сможешь присвоить этому x значение любого другого типа - вещественное число, строка, массив, словарь, объект и т.д. Иногда это реально нужно и удобно, в остальных случаях рекомендую явно указывать тип:
Тогда тебе выдаст ошибку, если ты попытаешься присвоить значение неправильного типа. Во второй строке 5 будет конвертировано из целого числа в вещественное. Но если сделать так:
Редактор тебя предупредит, что здесь идёт потеря точности при конвертации из вещественного числа в целое.
Есть ещё возможность автоматически определить тип:
И так далее. Такая запись аналогична по свойствам явному указанию типа, то есть не будет принимать значения других типов. Но в некоторых случаях определить тип невозможно, тогда редактор предложит указать тип явно или убрать типизацию.
Здесь интерпретатор не знает, какого типа будет x, потому что функция f может вернуть что угодно. Поэтому делай так:
Теперь интерпретатор точно знает, что функция f возвращает всегда значения типа int и может назначить тип переменной x.
>в гдскрипте нет строгой типизации
Она есть, но опциональная и не до конца доделанная. В 4.0 будет лучше, чем сейчас, а пока можно указывать типы при объявлении переменных, аргументов функций, возврата из функций. Единственный минус пока что - элементам массивов и словарей нельзя задать тип, но есть специальные типизированные массивы (имена начинаются на Pool).
>И где вообще правила приведения типо почитать?
Почитай документацию. Многие вопросы отпадут.
>умножаешь вектор(координаты) на флоат
И получаешь вектор, что логично, потому что ты умножаешь каждую составляющую вектора на вещественное число. На строго типизированном языке ты тоже так можешь делать, если перезагрузишь оператор умножения с аргументами вектора и вещественного числа. Здесь это просто из коробки.
>Или вот var x= 5, вот какой тип у X тут? Флоат, интигер?
Целое число, потому что без точки. Вернее, у тебя будет variant с целым числом внутри. То есть ты сможешь присвоить этому x значение любого другого типа - вещественное число, строка, массив, словарь, объект и т.д. Иногда это реально нужно и удобно, в остальных случаях рекомендую явно указывать тип:
>var x: int = 5
>var y: float = 5
>var s: String = "5"
>var a: Array = [5]
Тогда тебе выдаст ошибку, если ты попытаешься присвоить значение неправильного типа. Во второй строке 5 будет конвертировано из целого числа в вещественное. Но если сделать так:
>var f: int = 5.0
Редактор тебя предупредит, что здесь идёт потеря точности при конвертации из вещественного числа в целое.
Есть ещё возможность автоматически определить тип:
>var i := 0 # целое число
>var f := 0.0 # вещественное число
>var s := "" # строка
>var a := [] # массив
>var d := {} # словарь
>var n := Node.new() # объект класса Node
И так далее. Такая запись аналогична по свойствам явному указанию типа, то есть не будет принимать значения других типов. Но в некоторых случаях определить тип невозможно, тогда редактор предложит указать тип явно или убрать типизацию.
>var x := f(a)
>func f(a): return a + a
Здесь интерпретатор не знает, какого типа будет x, потому что функция f может вернуть что угодно. Поэтому делай так:
>var x := f(a)
>func f(a: int) -> int: return a + a
Теперь интерпретатор точно знает, что функция f возвращает всегда значения типа int и может назначить тип переменной x.
>>24615
Она есть, но опциональная и не до конца доделанная. В 4.0 будет лучше, чем сейчас, а пока можно указывать типы при объявлении переменных, аргументов функций, возврата из функций. Единственный минус пока что - элементам массивов и словарей нельзя задать тип, но есть специальные типизированные массивы (имена начинаются на Pool).
Почитай документацию. Многие вопросы отпадут.
И получаешь вектор, что логично, потому что ты умножаешь каждую составляющую вектора на вещественное число. На строго типизированном языке ты тоже так можешь делать, если перезагрузишь оператор умножения с аргументами вектора и вещественного числа. Здесь это просто из коробки.
Целое число, потому что без точки. Вернее, у тебя будет variant с целым числом внутри. То есть ты сможешь присвоить этому x значение любого другого типа - вещественное число, строка, массив, словарь, объект и т.д. Иногда это реально нужно и удобно, в остальных случаях рекомендую явно указывать тип:
Тогда тебе выдаст ошибку, если ты попытаешься присвоить значение неправильного типа. Во второй строке 5 будет конвертировано из целого числа в вещественное. Но если сделать так:
Редактор тебя предупредит, что здесь идёт потеря точности при конвертации из вещественного числа в целое.
Есть ещё возможность автоматически определить тип:
И так далее. Такая запись аналогична по свойствам явному указанию типа, то есть не будет принимать значения других типов. Но в некоторых случаях определить тип невозможно, тогда редактор предложит указать тип явно или убрать типизацию.
Здесь интерпретатор не знает, какого типа будет x, потому что функция f может вернуть что угодно. Поэтому делай так:
Теперь интерпретатор точно знает, что функция f возвращает всегда значения типа int и может назначить тип переменной x.
>в гдскрипте нет строгой типизации
Она есть, но опциональная и не до конца доделанная. В 4.0 будет лучше, чем сейчас, а пока можно указывать типы при объявлении переменных, аргументов функций, возврата из функций. Единственный минус пока что - элементам массивов и словарей нельзя задать тип, но есть специальные типизированные массивы (имена начинаются на Pool).
>И где вообще правила приведения типо почитать?
Почитай документацию. Многие вопросы отпадут.
>умножаешь вектор(координаты) на флоат
И получаешь вектор, что логично, потому что ты умножаешь каждую составляющую вектора на вещественное число. На строго типизированном языке ты тоже так можешь делать, если перезагрузишь оператор умножения с аргументами вектора и вещественного числа. Здесь это просто из коробки.
>Или вот var x= 5, вот какой тип у X тут? Флоат, интигер?
Целое число, потому что без точки. Вернее, у тебя будет variant с целым числом внутри. То есть ты сможешь присвоить этому x значение любого другого типа - вещественное число, строка, массив, словарь, объект и т.д. Иногда это реально нужно и удобно, в остальных случаях рекомендую явно указывать тип:
>var x: int = 5
>var y: float = 5
>var s: String = "5"
>var a: Array = [5]
Тогда тебе выдаст ошибку, если ты попытаешься присвоить значение неправильного типа. Во второй строке 5 будет конвертировано из целого числа в вещественное. Но если сделать так:
>var f: int = 5.0
Редактор тебя предупредит, что здесь идёт потеря точности при конвертации из вещественного числа в целое.
Есть ещё возможность автоматически определить тип:
>var i := 0 # целое число
>var f := 0.0 # вещественное число
>var s := "" # строка
>var a := [] # массив
>var d := {} # словарь
>var n := Node.new() # объект класса Node
И так далее. Такая запись аналогична по свойствам явному указанию типа, то есть не будет принимать значения других типов. Но в некоторых случаях определить тип невозможно, тогда редактор предложит указать тип явно или убрать типизацию.
>var x := f(a)
>func f(a): return a + a
Здесь интерпретатор не знает, какого типа будет x, потому что функция f может вернуть что угодно. Поэтому делай так:
>var x := f(a)
>func f(a: int) -> int: return a + a
Теперь интерпретатор точно знает, что функция f возвращает всегда значения типа int и может назначить тип переменной x.
>>24645
Ты предлагаешь хранить описание персонажа отдельно от объекта, который будет создаваться и уничтожаться вместе с чанком. Я понимаю тебя. Но такая система имеет свои недостатки. Во-первых, ты будешь тратить дополнительное время на выделение памяти под объекты и их инициализацию, а потом на сохранение их состояния и освобождение памяти. Во-вторых, у тебя будет лишний дубликат данных отдельно от объекта. Главный вопрос: а что ты в результате получишь? Очень сильно сомневаюсь, что один объект сильно хуже кучки "простых данных". Тем более что мы говорим о GDScript, тут Array и Dictionary хранят кучу variant и работают в куче, т.е. как те же самые объекты. Меняешь шило на мыло...
Кроме того, получается, нужно отдельно делать ИИ для этого набора данных, который будет отвечать за ботов в выгруженных чанках. Нет, конечно, можно сделать этот ИИ единственным, как в какой-нибудь стратегии, где один предводитель управляет всеми, но это будет недостаточно гибким решением для честной симуляции, в которой все сущности действуют независимо. В честной симуляции ты можешь добавить какое-нибудь новое существо, не трогая код старых существ, и все существа смогут взаимодействовать друг с другом, пока у них совпадают интерфейсы. А в одном глобальном ИИ тебе придётся копаться, добавляя новый тип существа, его характер, взаимодействия с другими типами и т.д. Т.е. это принципиальный вопрос - управляем ли мы сотней болванчиков из одного Центра Управления, или мы позволяем каждому гражданину (и не только) думать своей головой (или что там у него) за себя.
Очень спорно. Хуан дал нам ноды, а ты предлагаешь не пользоваться? Удобно иметь class_name WorldChunk extends Spatial, который будет самостоятельно заниматься своими чанковскими делами по сигналу "сверху" или "снизу". Внутри чанк может обращаться к серверам, чтобы не заваливать сцену лишними нодами, а нода самого чанка не помешает, потому чанков не должно быть слишком много. Нет, конечно, можно сделать абстрактно (сначала я так и сделал, но мне не понравилось), но тогда теряется возможность сделать chunk.visible = false или другое подобное, а код менеджера чанков очень сильно раздувает.
Ещё круче, а как он тогда будет отображаться? Тебе в любом случае потребуется KinematicBody с какой-то логикой для движения. Поскольку у игрока такой же KinematicBody, логично сделать им общего предка. Только игрок управляется с клавиатуры, а неигровой персонаж будет управляться ИИ в дочернем классе.
Вот кстати, я видел реализацию ГОАП в Годо НА НОДАХ, как тебе такое? Пока ты тут борешься против лишних Spatial чанка и непися, кто-то спамит сотнями нод для мозгов ОДНОГО непися, и это на твоём любимом ГОАП, между прочим. Просто вспомнилось.
Вот это разделение мне больше всего не нравится.
Нет, DOD - это когда данные сваливаются в одну общую кучу (массив), чтобы процессору было проще работать с этими данными в своём кэше, лишний раз не трогая оперативную память. Но пока мы работаем на GDScript или полагаемся на API Godot, сомневаюсь, что DOD имеет смысл, т.к. внутренности движка могут сбивать все наши попытки оптимизировать работу с кэшем.
Ты описываешь паттерн MVC: Model View Controller. В нашем случае графика движка - это View (отображает изменения модели), управление с клавиатуры игрока - Controller (влияет на модель), а всё то, что ты описывал до этого - Model (производит какие-то вычисления, симуляции и т.п.). Физика движка - это отдельная Model, с тем же View и Controller.
Ты предлагаешь хранить описание персонажа отдельно от объекта, который будет создаваться и уничтожаться вместе с чанком. Я понимаю тебя. Но такая система имеет свои недостатки. Во-первых, ты будешь тратить дополнительное время на выделение памяти под объекты и их инициализацию, а потом на сохранение их состояния и освобождение памяти. Во-вторых, у тебя будет лишний дубликат данных отдельно от объекта. Главный вопрос: а что ты в результате получишь? Очень сильно сомневаюсь, что один объект сильно хуже кучки "простых данных". Тем более что мы говорим о GDScript, тут Array и Dictionary хранят кучу variant и работают в куче, т.е. как те же самые объекты. Меняешь шило на мыло...
Кроме того, получается, нужно отдельно делать ИИ для этого набора данных, который будет отвечать за ботов в выгруженных чанках. Нет, конечно, можно сделать этот ИИ единственным, как в какой-нибудь стратегии, где один предводитель управляет всеми, но это будет недостаточно гибким решением для честной симуляции, в которой все сущности действуют независимо. В честной симуляции ты можешь добавить какое-нибудь новое существо, не трогая код старых существ, и все существа смогут взаимодействовать друг с другом, пока у них совпадают интерфейсы. А в одном глобальном ИИ тебе придётся копаться, добавляя новый тип существа, его характер, взаимодействия с другими типами и т.д. Т.е. это принципиальный вопрос - управляем ли мы сотней болванчиков из одного Центра Управления, или мы позволяем каждому гражданину (и не только) думать своей головой (или что там у него) за себя.
>Чанка нет. Он не существует.
Очень спорно. Хуан дал нам ноды, а ты предлагаешь не пользоваться? Удобно иметь class_name WorldChunk extends Spatial, который будет самостоятельно заниматься своими чанковскими делами по сигналу "сверху" или "снизу". Внутри чанк может обращаться к серверам, чтобы не заваливать сцену лишними нодами, а нода самого чанка не помешает, потому чанков не должно быть слишком много. Нет, конечно, можно сделать абстрактно (сначала я так и сделал, но мне не понравилось), но тогда теряется возможность сделать chunk.visible = false или другое подобное, а код менеджера чанков очень сильно раздувает.
>НПЦ нет, он не существует.
Ещё круче, а как он тогда будет отображаться? Тебе в любом случае потребуется KinematicBody с какой-то логикой для движения. Поскольку у игрока такой же KinematicBody, логично сделать им общего предка. Только игрок управляется с клавиатуры, а неигровой персонаж будет управляться ИИ в дочернем классе.
>ГОАП-график
Вот кстати, я видел реализацию ГОАП в Годо НА НОДАХ, как тебе такое? Пока ты тут борешься против лишних Spatial чанка и непися, кто-то спамит сотнями нод для мозгов ОДНОГО непися, и это на твоём любимом ГОАП, между прочим. Просто вспомнилось.
>весь функционал самостоятельного брождения
Вот это разделение мне больше всего не нравится.
>Data Oriented Design
Нет, DOD - это когда данные сваливаются в одну общую кучу (массив), чтобы процессору было проще работать с этими данными в своём кэше, лишний раз не трогая оперативную память. Но пока мы работаем на GDScript или полагаемся на API Godot, сомневаюсь, что DOD имеет смысл, т.к. внутренности движка могут сбивать все наши попытки оптимизировать работу с кэшем.
>Когда мы выполняем основную работу по симуляции мира как апдейты базы данных, а визуальная и физическая симуляция идёт к базе данных как приложение.
Ты описываешь паттерн MVC: Model View Controller. В нашем случае графика движка - это View (отображает изменения модели), управление с клавиатуры игрока - Controller (влияет на модель), а всё то, что ты описывал до этого - Model (производит какие-то вычисления, симуляции и т.п.). Физика движка - это отдельная Model, с тем же View и Controller.
>>24645
Ты предлагаешь хранить описание персонажа отдельно от объекта, который будет создаваться и уничтожаться вместе с чанком. Я понимаю тебя. Но такая система имеет свои недостатки. Во-первых, ты будешь тратить дополнительное время на выделение памяти под объекты и их инициализацию, а потом на сохранение их состояния и освобождение памяти. Во-вторых, у тебя будет лишний дубликат данных отдельно от объекта. Главный вопрос: а что ты в результате получишь? Очень сильно сомневаюсь, что один объект сильно хуже кучки "простых данных". Тем более что мы говорим о GDScript, тут Array и Dictionary хранят кучу variant и работают в куче, т.е. как те же самые объекты. Меняешь шило на мыло...
Кроме того, получается, нужно отдельно делать ИИ для этого набора данных, который будет отвечать за ботов в выгруженных чанках. Нет, конечно, можно сделать этот ИИ единственным, как в какой-нибудь стратегии, где один предводитель управляет всеми, но это будет недостаточно гибким решением для честной симуляции, в которой все сущности действуют независимо. В честной симуляции ты можешь добавить какое-нибудь новое существо, не трогая код старых существ, и все существа смогут взаимодействовать друг с другом, пока у них совпадают интерфейсы. А в одном глобальном ИИ тебе придётся копаться, добавляя новый тип существа, его характер, взаимодействия с другими типами и т.д. Т.е. это принципиальный вопрос - управляем ли мы сотней болванчиков из одного Центра Управления, или мы позволяем каждому гражданину (и не только) думать своей головой (или что там у него) за себя.
Очень спорно. Хуан дал нам ноды, а ты предлагаешь не пользоваться? Удобно иметь class_name WorldChunk extends Spatial, который будет самостоятельно заниматься своими чанковскими делами по сигналу "сверху" или "снизу". Внутри чанк может обращаться к серверам, чтобы не заваливать сцену лишними нодами, а нода самого чанка не помешает, потому чанков не должно быть слишком много. Нет, конечно, можно сделать абстрактно (сначала я так и сделал, но мне не понравилось), но тогда теряется возможность сделать chunk.visible = false или другое подобное, а код менеджера чанков очень сильно раздувает.
Ещё круче, а как он тогда будет отображаться? Тебе в любом случае потребуется KinematicBody с какой-то логикой для движения. Поскольку у игрока такой же KinematicBody, логично сделать им общего предка. Только игрок управляется с клавиатуры, а неигровой персонаж будет управляться ИИ в дочернем классе.
Вот кстати, я видел реализацию ГОАП в Годо НА НОДАХ, как тебе такое? Пока ты тут борешься против лишних Spatial чанка и непися, кто-то спамит сотнями нод для мозгов ОДНОГО непися, и это на твоём любимом ГОАП, между прочим. Просто вспомнилось.
Вот это разделение мне больше всего не нравится.
Нет, DOD - это когда данные сваливаются в одну общую кучу (массив), чтобы процессору было проще работать с этими данными в своём кэше, лишний раз не трогая оперативную память. Но пока мы работаем на GDScript или полагаемся на API Godot, сомневаюсь, что DOD имеет смысл, т.к. внутренности движка могут сбивать все наши попытки оптимизировать работу с кэшем.
Ты описываешь паттерн MVC: Model View Controller. В нашем случае графика движка - это View (отображает изменения модели), управление с клавиатуры игрока - Controller (влияет на модель), а всё то, что ты описывал до этого - Model (производит какие-то вычисления, симуляции и т.п.). Физика движка - это отдельная Model, с тем же View и Controller.
Ты предлагаешь хранить описание персонажа отдельно от объекта, который будет создаваться и уничтожаться вместе с чанком. Я понимаю тебя. Но такая система имеет свои недостатки. Во-первых, ты будешь тратить дополнительное время на выделение памяти под объекты и их инициализацию, а потом на сохранение их состояния и освобождение памяти. Во-вторых, у тебя будет лишний дубликат данных отдельно от объекта. Главный вопрос: а что ты в результате получишь? Очень сильно сомневаюсь, что один объект сильно хуже кучки "простых данных". Тем более что мы говорим о GDScript, тут Array и Dictionary хранят кучу variant и работают в куче, т.е. как те же самые объекты. Меняешь шило на мыло...
Кроме того, получается, нужно отдельно делать ИИ для этого набора данных, который будет отвечать за ботов в выгруженных чанках. Нет, конечно, можно сделать этот ИИ единственным, как в какой-нибудь стратегии, где один предводитель управляет всеми, но это будет недостаточно гибким решением для честной симуляции, в которой все сущности действуют независимо. В честной симуляции ты можешь добавить какое-нибудь новое существо, не трогая код старых существ, и все существа смогут взаимодействовать друг с другом, пока у них совпадают интерфейсы. А в одном глобальном ИИ тебе придётся копаться, добавляя новый тип существа, его характер, взаимодействия с другими типами и т.д. Т.е. это принципиальный вопрос - управляем ли мы сотней болванчиков из одного Центра Управления, или мы позволяем каждому гражданину (и не только) думать своей головой (или что там у него) за себя.
>Чанка нет. Он не существует.
Очень спорно. Хуан дал нам ноды, а ты предлагаешь не пользоваться? Удобно иметь class_name WorldChunk extends Spatial, который будет самостоятельно заниматься своими чанковскими делами по сигналу "сверху" или "снизу". Внутри чанк может обращаться к серверам, чтобы не заваливать сцену лишними нодами, а нода самого чанка не помешает, потому чанков не должно быть слишком много. Нет, конечно, можно сделать абстрактно (сначала я так и сделал, но мне не понравилось), но тогда теряется возможность сделать chunk.visible = false или другое подобное, а код менеджера чанков очень сильно раздувает.
>НПЦ нет, он не существует.
Ещё круче, а как он тогда будет отображаться? Тебе в любом случае потребуется KinematicBody с какой-то логикой для движения. Поскольку у игрока такой же KinematicBody, логично сделать им общего предка. Только игрок управляется с клавиатуры, а неигровой персонаж будет управляться ИИ в дочернем классе.
>ГОАП-график
Вот кстати, я видел реализацию ГОАП в Годо НА НОДАХ, как тебе такое? Пока ты тут борешься против лишних Spatial чанка и непися, кто-то спамит сотнями нод для мозгов ОДНОГО непися, и это на твоём любимом ГОАП, между прочим. Просто вспомнилось.
>весь функционал самостоятельного брождения
Вот это разделение мне больше всего не нравится.
>Data Oriented Design
Нет, DOD - это когда данные сваливаются в одну общую кучу (массив), чтобы процессору было проще работать с этими данными в своём кэше, лишний раз не трогая оперативную память. Но пока мы работаем на GDScript или полагаемся на API Godot, сомневаюсь, что DOD имеет смысл, т.к. внутренности движка могут сбивать все наши попытки оптимизировать работу с кэшем.
>Когда мы выполняем основную работу по симуляции мира как апдейты базы данных, а визуальная и физическая симуляция идёт к базе данных как приложение.
Ты описываешь паттерн MVC: Model View Controller. В нашем случае графика движка - это View (отображает изменения модели), управление с клавиатуры игрока - Controller (влияет на модель), а всё то, что ты описывал до этого - Model (производит какие-то вычисления, симуляции и т.п.). Физика движка - это отдельная Model, с тем же View и Controller.
>>24615
Скорее есть.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
>>24654
Для основных штук хватает, хотя в словарях - да, не хватает.
>Хуево что в гдскрипте нет строгой типизации.
Скорее есть.
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
>>24654
>Она есть, но опциональная и не до конца доделанная
Для основных штук хватает, хотя в словарях - да, не хватает.
Готов взять шефство над продвинутым разработчиком на годоте и уничтожить. Готов вам генерировать задачи по полному концепту, главное чтобы Вы их выполняли.
В рамках выполнения задач, Вы научитесь игровому прототипированию, сделаете популярную игру и выложите ее в андроид стор.
Если вы считаете, что Вы это все умеете, то где хоть одна готовая Ваша игра в сторах? Я же помогу довести Вам ее до конца.
В рамках выполнения задач, Вы научитесь игровому прототипированию, сделаете популярную игру и выложите ее в андроид стор.
Если вы считаете, что Вы это все умеете, то где хоть одна готовая Ваша игра в сторах? Я же помогу довести Вам ее до конца.
>>24690
На сколько интересную ты сделаешь игру, на столько со стора и получишь. Каждый просмотр рекламы стоит 1 цент с русского и 15 центов с иностранца. Поэтому на твоём месте я бы сделал игру, в которой рекламу посмотрят минимум 100_00 игроков.
На сколько интересную ты сделаешь игру, на столько со стора и получишь. Каждый просмотр рекламы стоит 1 цент с русского и 15 центов с иностранца. Поэтому на твоём месте я бы сделал игру, в которой рекламу посмотрят минимум 100_00 игроков.
>>24691
Деточка, здесь опенсорц. Здесь профессиональные кодеры работают за фиксированную оплату. Готов платить 150К/мес? Сделаем тебе игру.
Деточка, здесь опенсорц. Здесь профессиональные кодеры работают за фиксированную оплату. Готов платить 150К/мес? Сделаем тебе игру.
>>24692
Судя по твоим расценкам, ты так себе, а не кодер. Покажи свои проекты на гуглплее или в Стиме, чтобы я более точно оценил, с кем я имею дело.
Судя по твоим расценкам, ты так себе, а не кодер. Покажи свои проекты на гуглплее или в Стиме, чтобы я более точно оценил, с кем я имею дело.
198 Кб, 650x420>>15359 (OP)
https://godotengine.org/article/godot-4-0-development-enters-feature-freeze
Предлагаю добавить в следующую шапку.
https://godotengine.org/article/godot-4-0-development-enters-feature-freeze
>August 3rd — the roadmap for 4.0 enters feature freeze; submit your work before that.
>August 17th — the scope of beta 1 is determined; reviews and assessment of PRs continues.
>Early September — beta 1 is released.
Предлагаю добавить в следующую шапку.
>>24695
Вот поэтому я и пишу "взять шефство", а не "сделать мне игру". Как минимум потому что ты не сделал ещё ни одной игры, и я готов тебе в этом помочь, чтобы ты не краснел перед другими пацанами, за то что тебе уже 35, а ты ещё не выпустил ни одного своего продукта, хотя занимался "разработкой" лет 10 круглосуточно. По сути, в стол.
Вот поэтому я и пишу "взять шефство", а не "сделать мне игру". Как минимум потому что ты не сделал ещё ни одной игры, и я готов тебе в этом помочь, чтобы ты не краснел перед другими пацанами, за то что тебе уже 35, а ты ещё не выпустил ни одного своего продукта, хотя занимался "разработкой" лет 10 круглосуточно. По сути, в стол.
>>24691
Молодой человек, вы ошиблись тредом, тред ассет-флиперов дальше по каталогу.
>Каждый просмотр рекламы
>игру, в которой рекламу посмотрят
Молодой человек, вы ошиблись тредом, тред ассет-флиперов дальше по каталогу.
>>24699
Нет, вы так же нарисует оригинальный арт сами, конечно же. Вы можете так же и установить конкретную начальную цену на вашу игру в районе 1$. Думаю, что это даже больше даст прибыли вне ру сегмента
Нет, вы так же нарисует оригинальный арт сами, конечно же. Вы можете так же и установить конкретную начальную цену на вашу игру в районе 1$. Думаю, что это даже больше даст прибыли вне ру сегмента
>>24798
Все ответы, которые ему там выше ответили - универсальные для любых движков.
Все ответы, которые ему там выше ответили - универсальные для любых движков.
>>24814
Нет никаких проблем с текстом.
Нет никаких проблем с текстом.
прохожу уроки по сайту, в уроке про сигналы кнопку сделал, но она не отображается при запуске почему-то
>>24744
Я научу тебя, как не умея рисовать нарисовать арт, чтобы ты не сидел как сыч. Мышкой.
Я научу тебя, как не умея рисовать нарисовать арт, чтобы ты не сидел как сыч. Мышкой.
>>24834
С учётом что ты запостил экошизичку которую используют все кому не лень, чтобы уйти от зависимости Российских энергоресурсов с помощью неработающей зелёной энергетики, а теперь как припекло, вообще все позабыли, то считаю, что ты верно описал свою ситуацию и однозначно подтвердил мою правоту.
С учётом что ты запостил экошизичку которую используют все кому не лень, чтобы уйти от зависимости Российских энергоресурсов с помощью неработающей зелёной энергетики, а теперь как припекло, вообще все позабыли, то считаю, что ты верно описал свою ситуацию и однозначно подтвердил мою правоту.
>>24865
Давай не скатывать в политоту годототред. Это не продуктивно.
>>24861
В общем, я свое предложение сделал. Через месяц-два у тебя бы была уже опубликованная игра, которая бы приносила тебе доход, если ты, конечно, не вводишь всех в заблуждение наличием у тебя каких-то навыков. Ты можешь продолжать считать, что тебя здесь как-то пытаются обмануть или иначе оправдывать свою "безыгорность", я лишь дал шанс тем анонам, которые действительно хотят сделать какой-то продукт и получить опыт и экспертизу "готового" продукта, а не уровня ниже технодемки. Удачи!
> АЭС работают, ГЭС работают, что тебе ещё нужно?
Давай не скатывать в политоту годототред. Это не продуктивно.
>>24861
В общем, я свое предложение сделал. Через месяц-два у тебя бы была уже опубликованная игра, которая бы приносила тебе доход, если ты, конечно, не вводишь всех в заблуждение наличием у тебя каких-то навыков. Ты можешь продолжать считать, что тебя здесь как-то пытаются обмануть или иначе оправдывать свою "безыгорность", я лишь дал шанс тем анонам, которые действительно хотят сделать какой-то продукт и получить опыт и экспертизу "готового" продукта, а не уровня ниже технодемки. Удачи!
>>24870
А у тебя сколько игр выпущено? Можно глянуть? Дай пару ссылок на гуглплей или стим.
А у тебя сколько игр выпущено? Можно глянуть? Дай пару ссылок на гуглплей или стим.
Так поясните.
Сдела вторую сцену. В ней созда 2д ноду.
Потом согласно инструкции взяли из отдела файл (левый нижний угол) и перетащил первую сцену в первую.
Я думал создался новый экземпляр. В первой сцене - чисто 1 спрайт.
Ну так в торой сцене я у спрайте меняю скрипт, смотрю- он поменялся. Получается хуйня какая-то. Это не экземпляр что ли.
Вторая сцена назначена главной если что.
Сдела вторую сцену. В ней созда 2д ноду.
Потом согласно инструкции взяли из отдела файл (левый нижний угол) и перетащил первую сцену в первую.
Я думал создался новый экземпляр. В первой сцене - чисто 1 спрайт.
Ну так в торой сцене я у спрайте меняю скрипт, смотрю- он поменялся. Получается хуйня какая-то. Это не экземпляр что ли.
Вторая сцена назначена главной если что.
>>24877
Как могущий взять шефство над кем угодно:
1. Ты создал файл-сцену, в который поместил какие-то ноды и сохранил отдельно.
2. Ты разместил его на другой сцене, создав "копию".
Если поменяешь параметры у размещенноной в сцене копии, ты изменишь конкретно её параметры.
Если ты поменяешь параметры у главной сцены (файла ноды), то если у "копий" не были изменены эти параметры, которые ты меняешь, они поменяются вместе с родителем у всех копий.
Для того, чтобы работать с копией, как с отдельным экземпляром требуется нажать на неё (копию) ПКМ и выбрать "editable children". Но это не приветствуется.
Как могущий взять шефство над кем угодно:
1. Ты создал файл-сцену, в который поместил какие-то ноды и сохранил отдельно.
2. Ты разместил его на другой сцене, создав "копию".
Если поменяешь параметры у размещенноной в сцене копии, ты изменишь конкретно её параметры.
Если ты поменяешь параметры у главной сцены (файла ноды), то если у "копий" не были изменены эти параметры, которые ты меняешь, они поменяются вместе с родителем у всех копий.
Для того, чтобы работать с копией, как с отдельным экземпляром требуется нажать на неё (копию) ПКМ и выбрать "editable children". Но это не приветствуется.
106 Кб, 1053x709>>24879
Не очень понял.
Вот что я сделал - сцену из файла перетащил в ноду другой сцены.
Содержание первой сцены - тупо 1 спрайт.
Я так понял при перетаскивании содержание всей сцены перетаскивается?
Получается что это не копия создалась (новый экземлпляр) а произошло связывание - элемент из 1 сцены стал чайлдом элемента во 2 сцена. По-сути получается что один и тот же элемент теперь доступен в двух сценах?
Не очень понял.
Вот что я сделал - сцену из файла перетащил в ноду другой сцены.
Содержание первой сцены - тупо 1 спрайт.
Я так понял при перетаскивании содержание всей сцены перетаскивается?
Получается что это не копия создалась (новый экземлпляр) а произошло связывание - элемент из 1 сцены стал чайлдом элемента во 2 сцена. По-сути получается что один и тот же элемент теперь доступен в двух сценах?
>>24904
Я работаю в годоте уже порядка 5 лет, но, естественно, с промежутками времени. Специализируюсь в основном на пошаговых стратегиях, т.к. с физикой определенное время у Godot'а были проблемы прохождения тел.
Ты можешь написать мне на почтуrblu%bVe.git ANUSgmai42al PUNCTUMcZVHom .
>>24906
Не совсем так. Каждая сцена "закрытая" в файлике tscn - считай что это отдельный объект. Эти объекты можно кидать в другие сцены, как и дефолтные ноды в годоте. Если ты меняешь закинутую сцену внутри другой сцены, то ты меняешь потомка. Если ты меняешь его в "его файлике", то ты меняешь его для всех сцен куда он был закинут.
Если внутри "файлика-объекта" миллион нод, то все они перетащатся в сцену при перетаскивании, просто не будут тебе видны.
"Связывание по ссылке" не произошло, потому что если ты поменяешь размер своего спрайта в сцене Node2D, то он не поменяется в файле Sprite.tscn. А вот если сделаешь наоборот - поменяется. Считай, что это просто "наследование".
Я работаю в годоте уже порядка 5 лет, но, естественно, с промежутками времени. Специализируюсь в основном на пошаговых стратегиях, т.к. с физикой определенное время у Godot'а были проблемы прохождения тел.
Ты можешь написать мне на почту
>>24906
Не совсем так. Каждая сцена "закрытая" в файлике tscn - считай что это отдельный объект. Эти объекты можно кидать в другие сцены, как и дефолтные ноды в годоте. Если ты меняешь закинутую сцену внутри другой сцены, то ты меняешь потомка. Если ты меняешь его в "его файлике", то ты меняешь его для всех сцен куда он был закинут.
Если внутри "файлика-объекта" миллион нод, то все они перетащатся в сцену при перетаскивании, просто не будут тебе видны.
"Связывание по ссылке" не произошло, потому что если ты поменяешь размер своего спрайта в сцене Node2D, то он не поменяется в файле Sprite.tscn. А вот если сделаешь наоборот - поменяется. Считай, что это просто "наследование".
>>24877 >>24906
Чтобы понять механизм сцен в Годо, проще всего открыть .tscn в Блокноте и представить, как движок будет это всё грузить в рантайме. Там по ключевым словам всё понятно:
[ext_resource path= - внешний ресурс, считывается из указанного в path файла.
[sub_resource type= - внутренний ресурс, создаётся с нуля (поэтому обязательно указан тип создаваемого ресурса) в процессе чтения этого файла.
В заголовке нод вида "[node name="Sprite" parent="." instance=ExtResource( 1 )]":
instance=ExtResource( 1 ) - создание нового экземпляра (instance) внешнего ресурса (типа PackedScene, упакованная сцена).
В описании самой ноды:
texture = ExtResource( 1 ) - связывание с внешним ресурсом
texture = SubResource( 1 ) - связывание с внутренним ресурсом
Если мы говорим о main.tscn, в котором инстанциирована сцена sprite.tscn, то вышеописанные строчки перезапишут значения полей из sprite.tscn, но только в конкретном экземпляре. Потому что, как видно из предыдущего абзаца, мы создаём новый instance из внешнего ресурса (который типа PackedScene), который никак не связан с другими инстансами.
Однако, другая ситуация с внешними ресурсами. По умолчанию они считываются с диска только один раз, а потом менеджер ресурсов выдаёт ссылку на уже загруженный ресурс.
Если, например, ты переносишь из файловой системы спрайт в поле texture, то он по умолчанию будет внешним ресурсом:
[ext_resource path="res://icon.png" type="Texture" id=1]
Такой ресурс будет одним для всех. Если его где-то изменить (например, изменить флаги текстуры, убрав/добавив фильтрацию), он изменится везде. Но ты можешь нажать "Make Unique" и тогда будет создан новый внутренний ресурс, который описывается как-то так:
[sub_resource type="StreamTexture" id=1]
flags = 4
load_path = "res://.import/icon.png-много-букв.stex"
Вот теперь это отдельный ресурс, который не будет влиять на остальные копии.
TL;DR: Сцены - это ресурсы типа PackedScene:
[ext_resource path="res://sprite.tscn" type="PackedScene" id=1]
Которые можно "инстанциировать":
[node name="Sprite" parent="." instance=ExtResource( 1 )]
position = Vector2( 33, 36 )
[node name="Sprite2" parent="." instance=ExtResource( 1 )]
position = Vector2( 79, 36 )
Так вот редактирование нашего res://sprite.tscn отражает изменения и в Sprite, и в Sprite2, но перезаписывание свойств Sprite (например, position) не влияет на свойства Sprite2, поскольку это два независимых экземпляра нод (ООП классов), а не оригинальный ресурс.
Чтобы понять механизм сцен в Годо, проще всего открыть .tscn в Блокноте и представить, как движок будет это всё грузить в рантайме. Там по ключевым словам всё понятно:
[ext_resource path= - внешний ресурс, считывается из указанного в path файла.
[sub_resource type= - внутренний ресурс, создаётся с нуля (поэтому обязательно указан тип создаваемого ресурса) в процессе чтения этого файла.
В заголовке нод вида "[node name="Sprite" parent="." instance=ExtResource( 1 )]":
instance=ExtResource( 1 ) - создание нового экземпляра (instance) внешнего ресурса (типа PackedScene, упакованная сцена).
В описании самой ноды:
texture = ExtResource( 1 ) - связывание с внешним ресурсом
texture = SubResource( 1 ) - связывание с внутренним ресурсом
Если мы говорим о main.tscn, в котором инстанциирована сцена sprite.tscn, то вышеописанные строчки перезапишут значения полей из sprite.tscn, но только в конкретном экземпляре. Потому что, как видно из предыдущего абзаца, мы создаём новый instance из внешнего ресурса (который типа PackedScene), который никак не связан с другими инстансами.
Однако, другая ситуация с внешними ресурсами. По умолчанию они считываются с диска только один раз, а потом менеджер ресурсов выдаёт ссылку на уже загруженный ресурс.
Если, например, ты переносишь из файловой системы спрайт в поле texture, то он по умолчанию будет внешним ресурсом:
[ext_resource path="res://icon.png" type="Texture" id=1]
Такой ресурс будет одним для всех. Если его где-то изменить (например, изменить флаги текстуры, убрав/добавив фильтрацию), он изменится везде. Но ты можешь нажать "Make Unique" и тогда будет создан новый внутренний ресурс, который описывается как-то так:
[sub_resource type="StreamTexture" id=1]
flags = 4
load_path = "res://.import/icon.png-много-букв.stex"
Вот теперь это отдельный ресурс, который не будет влиять на остальные копии.
TL;DR: Сцены - это ресурсы типа PackedScene:
[ext_resource path="res://sprite.tscn" type="PackedScene" id=1]
Которые можно "инстанциировать":
[node name="Sprite" parent="." instance=ExtResource( 1 )]
position = Vector2( 33, 36 )
[node name="Sprite2" parent="." instance=ExtResource( 1 )]
position = Vector2( 79, 36 )
Так вот редактирование нашего res://sprite.tscn отражает изменения и в Sprite, и в Sprite2, но перезаписывание свойств Sprite (например, position) не влияет на свойства Sprite2, поскольку это два независимых экземпляра нод (ООП классов), а не оригинальный ресурс.
>>24877 >>24906
Чтобы понять механизм сцен в Годо, проще всего открыть .tscn в Блокноте и представить, как движок будет это всё грузить в рантайме. Там по ключевым словам всё понятно:
[ext_resource path= - внешний ресурс, считывается из указанного в path файла.
[sub_resource type= - внутренний ресурс, создаётся с нуля (поэтому обязательно указан тип создаваемого ресурса) в процессе чтения этого файла.
В заголовке нод вида "[node name="Sprite" parent="." instance=ExtResource( 1 )]":
instance=ExtResource( 1 ) - создание нового экземпляра (instance) внешнего ресурса (типа PackedScene, упакованная сцена).
В описании самой ноды:
texture = ExtResource( 1 ) - связывание с внешним ресурсом
texture = SubResource( 1 ) - связывание с внутренним ресурсом
Если мы говорим о main.tscn, в котором инстанциирована сцена sprite.tscn, то вышеописанные строчки перезапишут значения полей из sprite.tscn, но только в конкретном экземпляре. Потому что, как видно из предыдущего абзаца, мы создаём новый instance из внешнего ресурса (который типа PackedScene), который никак не связан с другими инстансами.
Однако, другая ситуация с внешними ресурсами. По умолчанию они считываются с диска только один раз, а потом менеджер ресурсов выдаёт ссылку на уже загруженный ресурс.
Если, например, ты переносишь из файловой системы спрайт в поле texture, то он по умолчанию будет внешним ресурсом:
[ext_resource path="res://icon.png" type="Texture" id=1]
Такой ресурс будет одним для всех. Если его где-то изменить (например, изменить флаги текстуры, убрав/добавив фильтрацию), он изменится везде. Но ты можешь нажать "Make Unique" и тогда будет создан новый внутренний ресурс, который описывается как-то так:
[sub_resource type="StreamTexture" id=1]
flags = 4
load_path = "res://.import/icon.png-много-букв.stex"
Вот теперь это отдельный ресурс, который не будет влиять на остальные копии.
TL;DR: Сцены - это ресурсы типа PackedScene:
[ext_resource path="res://sprite.tscn" type="PackedScene" id=1]
Которые можно "инстанциировать":
[node name="Sprite" parent="." instance=ExtResource( 1 )]
position = Vector2( 33, 36 )
[node name="Sprite2" parent="." instance=ExtResource( 1 )]
position = Vector2( 79, 36 )
Так вот редактирование нашего res://sprite.tscn отражает изменения и в Sprite, и в Sprite2, но перезаписывание свойств Sprite (например, position) не влияет на свойства Sprite2, поскольку это два независимых экземпляра нод (ООП классов), а не оригинальный ресурс.
Чтобы понять механизм сцен в Годо, проще всего открыть .tscn в Блокноте и представить, как движок будет это всё грузить в рантайме. Там по ключевым словам всё понятно:
[ext_resource path= - внешний ресурс, считывается из указанного в path файла.
[sub_resource type= - внутренний ресурс, создаётся с нуля (поэтому обязательно указан тип создаваемого ресурса) в процессе чтения этого файла.
В заголовке нод вида "[node name="Sprite" parent="." instance=ExtResource( 1 )]":
instance=ExtResource( 1 ) - создание нового экземпляра (instance) внешнего ресурса (типа PackedScene, упакованная сцена).
В описании самой ноды:
texture = ExtResource( 1 ) - связывание с внешним ресурсом
texture = SubResource( 1 ) - связывание с внутренним ресурсом
Если мы говорим о main.tscn, в котором инстанциирована сцена sprite.tscn, то вышеописанные строчки перезапишут значения полей из sprite.tscn, но только в конкретном экземпляре. Потому что, как видно из предыдущего абзаца, мы создаём новый instance из внешнего ресурса (который типа PackedScene), который никак не связан с другими инстансами.
Однако, другая ситуация с внешними ресурсами. По умолчанию они считываются с диска только один раз, а потом менеджер ресурсов выдаёт ссылку на уже загруженный ресурс.
Если, например, ты переносишь из файловой системы спрайт в поле texture, то он по умолчанию будет внешним ресурсом:
[ext_resource path="res://icon.png" type="Texture" id=1]
Такой ресурс будет одним для всех. Если его где-то изменить (например, изменить флаги текстуры, убрав/добавив фильтрацию), он изменится везде. Но ты можешь нажать "Make Unique" и тогда будет создан новый внутренний ресурс, который описывается как-то так:
[sub_resource type="StreamTexture" id=1]
flags = 4
load_path = "res://.import/icon.png-много-букв.stex"
Вот теперь это отдельный ресурс, который не будет влиять на остальные копии.
TL;DR: Сцены - это ресурсы типа PackedScene:
[ext_resource path="res://sprite.tscn" type="PackedScene" id=1]
Которые можно "инстанциировать":
[node name="Sprite" parent="." instance=ExtResource( 1 )]
position = Vector2( 33, 36 )
[node name="Sprite2" parent="." instance=ExtResource( 1 )]
position = Vector2( 79, 36 )
Так вот редактирование нашего res://sprite.tscn отражает изменения и в Sprite, и в Sprite2, но перезаписывание свойств Sprite (например, position) не влияет на свойства Sprite2, поскольку это два независимых экземпляра нод (ООП классов), а не оригинальный ресурс.
>>24954
Это Т9, сижу с телефона. Никакого троллинга.
Это Т9, сижу с телефона. Никакого троллинга.
Здравствуйте ребята. Недавно и очень медленно стал ковырять Годот. Уже пару раз тут появлялся с тупыми вопросами. И не планирую останавливаться.
Мне порекомендовали сделать игру и типо в процессе я гораздо лучше разберусь в движке, чем просто читать документацию от корки до корки. И вот у меня есть несколько идей, по которым хочу получить от вас комментарии на тему, того, насколько это выполнимо в одиночку и стоит ли браться за такие штуки, для первого проекта.
1)Сделать клон Galaxy on fire(именно первой части, которая ещё на тапочках выходила). Такой космический шутер с видом от третьего лица. Летаешь на звёздном истребителе и делаешь пиу пиу по врагам. Миссий всего несколько видов. Уборка мусора(стрелять по обломкам), сопровождение(не дать кого то уничтожить), такси(не дать уничтожить себя) и выстоять несколько волн. Можно покупать корабли и пушки на станциях. Такая простенькая кастомизация. Во второй части появился типо открытый мир, но я думаю это слишком. Поэтому можно сделать как в первой, звёздную карту где ты перемещается по станциям/планетам и берешь там Мисси, после чего они сразу стартуют и после завершения автоматически возвращают тебя на станцию. Как то так. Модельки и рисуночки вполне могу сделать сам если что.
2) РПГновеллу в очень маленьком мирке(деревня/район/космическая станция). Тоесть реализовать создание персонажа, влияние его характеристик на проверки в диалогах, в действиях. Сделать боевку как в какой нибудь жрпг. Свободное перемещение по локации, точки интереса, случайные события. И минимум графики, маскимум описаний.
Короче принимаются любые предъявив в мой адрес. А так же советы и пожелания. Можете вообще предложить мне что то от себя. Люблю целую.
Мне порекомендовали сделать игру и типо в процессе я гораздо лучше разберусь в движке, чем просто читать документацию от корки до корки. И вот у меня есть несколько идей, по которым хочу получить от вас комментарии на тему, того, насколько это выполнимо в одиночку и стоит ли браться за такие штуки, для первого проекта.
1)Сделать клон Galaxy on fire(именно первой части, которая ещё на тапочках выходила). Такой космический шутер с видом от третьего лица. Летаешь на звёздном истребителе и делаешь пиу пиу по врагам. Миссий всего несколько видов. Уборка мусора(стрелять по обломкам), сопровождение(не дать кого то уничтожить), такси(не дать уничтожить себя) и выстоять несколько волн. Можно покупать корабли и пушки на станциях. Такая простенькая кастомизация. Во второй части появился типо открытый мир, но я думаю это слишком. Поэтому можно сделать как в первой, звёздную карту где ты перемещается по станциям/планетам и берешь там Мисси, после чего они сразу стартуют и после завершения автоматически возвращают тебя на станцию. Как то так. Модельки и рисуночки вполне могу сделать сам если что.
2) РПГновеллу в очень маленьком мирке(деревня/район/космическая станция). Тоесть реализовать создание персонажа, влияние его характеристик на проверки в диалогах, в действиях. Сделать боевку как в какой нибудь жрпг. Свободное перемещение по локации, точки интереса, случайные события. И минимум графики, маскимум описаний.
Короче принимаются любые предъявив в мой адрес. А так же советы и пожелания. Можете вообще предложить мне что то от себя. Люблю целую.
>>24958
[node name="Node2D" type="Node2D"]
[node name="Sprite" parent="." instance=ExtResource( 1 )]
position = Vector2( 222, 170 )
[node name="Button" type="Button" parent="."]
А почему парент - "." ? По логике парент должен быть Node2d
Ну допустим Спрайт ссылается на внешний ресурс. Но Баттон я создавал именно как чайлд для Ноды.
[node name="Node2D" type="Node2D"]
[node name="Sprite" parent="." instance=ExtResource( 1 )]
position = Vector2( 222, 170 )
[node name="Button" type="Button" parent="."]
А почему парент - "." ? По логике парент должен быть Node2d
Ну допустим Спрайт ссылается на внешний ресурс. Но Баттон я создавал именно как чайлд для Ноды.
>>24913
Дашь ссылку на готовые игры?
Что-то не помню особо много пошаховых стратеги. Только Политопию на мобилках и её клоны. Ну еще была цива революция, но она довольная стремная.
> Специализируюсь в основном на пошаговых стратегиях,
Дашь ссылку на готовые игры?
Что-то не помню особо много пошаховых стратеги. Только Политопию на мобилках и её клоны. Ну еще была цива революция, но она довольная стремная.
>>25002 (Del)
О, нормально. Я вообще хочу сделать именно миссии вылеты, тоесть пиздишь с нпс он даёт тебе квест, снаряжаешь корабль нажимаешь старт и вот ты уже на миссии. Тоесть никакой симуляции мира или реального опен ворлда не планирую.
О, нормально. Я вообще хочу сделать именно миссии вылеты, тоесть пиздишь с нпс он даёт тебе квест, снаряжаешь корабль нажимаешь старт и вот ты уже на миссии. Тоесть никакой симуляции мира или реального опен ворлда не планирую.
>>24988
Окей, предъявляю:
Штат - от 10 человек. Бюджет - от 100К
Штат - от 30 человек. Бюджет - от 500К.
> Короче принимаются любые предъявив в мой адрес.
Окей, предъявляю:
> 1)
Штат - от 10 человек. Бюджет - от 100К
> 2)
Штат - от 30 человек. Бюджет - от 500К.
>>25195 (Del)
А контроллер я так понимаю, это самое сложное в этом деле. ?
А контроллер я так понимаю, это самое сложное в этом деле. ?
>>25207
Чет сомневаюсь даже на вскидку. Highflet запили два задрота, kenshi один человек. Список в принципе можно продолжать.
Чет сомневаюсь даже на вскидку. Highflet запили два задрота, kenshi один человек. Список в принципе можно продолжать.
>>25210
А ты чего ж тогда не запилишь? Всё сидишь да мечтаешь. Ну, давай ещё поболтаем, обсудим, сколько задротов что запилили? Вот расскажи?
> запили два задрота
А ты чего ж тогда не запилишь? Всё сидишь да мечтаешь. Ну, давай ещё поболтаем, обсудим, сколько задротов что запилили? Вот расскажи?
>>25216 (Del)
Ну тогда пойду попробую скопипастить. Может чего и выйдет)
Ну тогда пойду попробую скопипастить. Может чего и выйдет)
А где описания классов находятся? В смысле их определение, типо с конструктором, полями и методами. Или это в глубинах движка в C++ ?
Я вообще могу собственный классы создавать?
Я вообще могу собственный классы создавать?
>>25228
Свои можешь офк, код встроенных почитать можешь только в исходниках.
Свои можешь офк, код встроенных почитать можешь только в исходниках.
>>25228
В документации.
В документации.
В документации.
Анонимус разрешает.
> А где описания классов находятся?
В документации.
> В смысле их определение, типо с конструктором, полями и методами.
В документации.
> Или это в глубинах движка в C++ ?
В документации.
> Я вообще могу собственный классы создавать?
Анонимус разрешает.
>>25231
ТЫ НЕ Понял.
Под описаниями я имею в виду тело описания класса.
Класс же должен где-то формулироваться.
Ну вот берем мы джабу, там есть класс Класс, через который создаются другие классы.
ТЫ НЕ Понял.
Под описаниями я имею в виду тело описания класса.
Класс же должен где-то формулироваться.
Ну вот берем мы джабу, там есть класс Класс, через который создаются другие классы.
>>25169
Ты слышал что-нибудь про Into the Breach?
Ты слышал что-нибудь про Into the Breach?
Подскажите, а этот движок подходит под полного нуба? В идеале мне хочется изучать туториалы, параллельно наполняя окружение своими поделками в блендере. Жанр - РПГ
Моей первой планкой будет создание локации, и ее проработка.
Далее я хочу добавить персонажа и неписей, и взаимодействие с ними посредством диалогового окна.
И уже потом характеристики, элементарная боевая система, враждебные нпс.
Последним этапом будет экипировка.
____
Это реализуемо на годоте или для этого нужно полностью знать движок от и до?
Моей первой планкой будет создание локации, и ее проработка.
Далее я хочу добавить персонажа и неписей, и взаимодействие с ними посредством диалогового окна.
И уже потом характеристики, элементарная боевая система, враждебные нпс.
Последним этапом будет экипировка.
____
Это реализуемо на годоте или для этого нужно полностью знать движок от и до?
21 Кб, 1440x718Годоспода, а скиньте какую-нибудь насыщенную цветами и деталями 3D сцену, которую можно быстро закинуть в Godot и повертеть. Тестирую шейдер постеризации, который подсмотрел тут:
https://gist.github.com/erdavids/3cc909f68adb8e8b6589158e30819eff
Но я добавил 16 цветов, планирую добить до 32. Тестирую палитры с lospec.com, на пикриле слева 3D оригинал, а справа вот эта палитра (8 цветов, отображается 7):
https://lospec.com/palette-list/funkyfuture-8
https://gist.github.com/erdavids/3cc909f68adb8e8b6589158e30819eff
Но я добавил 16 цветов, планирую добить до 32. Тестирую палитры с lospec.com, на пикриле слева 3D оригинал, а справа вот эта палитра (8 цветов, отображается 7):
https://lospec.com/palette-list/funkyfuture-8
>>25249
Да, в таком смысле, код искаробочных классов находится в исходниках на си++. Когда ты наследуешься от них, твои переопределения находятся в ГДскрипте. Или в любом из поддерживаемых языков.
>>25264
Он дружелюбен к пользователям, но под полного нуба геймдев в принципе подходит мало, от движка это не зависит. Держи это в уме, когда будешь натыкаться на тяжёлые моменты и будет хотеться бросить всё к хуям.
Хороший план, без сарказма и швейцарских часов. Ду ит!
Полностью реализуемо, вплоть до того, что прототип игоры ты сможешь сделать не используя сторонний софт вообще.
Да, в таком смысле, код искаробочных классов находится в исходниках на си++. Когда ты наследуешься от них, твои переопределения находятся в ГДскрипте. Или в любом из поддерживаемых языков.
>>25264
> Подскажите, а этот движок подходит под полного нуба?
Он дружелюбен к пользователям, но под полного нуба геймдев в принципе подходит мало, от движка это не зависит. Держи это в уме, когда будешь натыкаться на тяжёлые моменты и будет хотеться бросить всё к хуям.
> В идеале мне хочется изучать туториалы, параллельно наполняя окружение своими поделками в блендере.
Хороший план, без сарказма и швейцарских часов. Ду ит!
> Это реализуемо на годоте или для этого нужно полностью знать движок от и до?
Полностью реализуемо, вплоть до того, что прототип игоры ты сможешь сделать не используя сторонний софт вообще.
>>25265
А что если тебе открыть вкладку ассетов в редакторе и поискать там, а?
> Годоспода, а скиньте какую-нибудь насыщенную цветами и деталями 3D сцену
А что если тебе открыть вкладку ассетов в редакторе и поискать там, а?
>>25282
Там искать сложно, большинство ассетов скриптовые или 2D. Я помню, что были какие-то сцены специально для теста графики, но понятия не имею, как это называется или как найти. Прости, если грубо прозвучало, я просто хотел поделиться прикольным эффектом, который, оказывается, совсем не так уж сложно сделать.
>>25284 (Del)
Спасибо за ссылки.
>>25265
Есть кое-какие мысли:
1. Исходные цвета текстур + шейдинга должны быть ближе к цветам палитры, чтобы не было внезапных скачков с синего на оранжевое и обратно (очень заметно в движении). Т.е. когда исходный цвет приблизительно похож на два цвета из палитры, он может стать любым из них в разных условиях. Иными словами, работы с текстурами и светом не избежать...
2. С другой стороны, преимущества такого фильтра - возможность заменить палитру на что-то другое. Скажем, во время дождя всего лишь замена палитры на более тусклую и более синюю может передать значительную часть дождливой атмосферы. Ночью и в темноте, можно было бы вообще отключать красный и зелёный оттенки, т.к. в темноте человек их не различает. Переходы из палитры в палитру можно даже сделать плавными!
3. Однако для этого может оказаться недостаточно просто сменить палитру в шейдере. Конечно, алгоритм попытается найти ближайшие цвета, даже если в палитре будут только синие оттенки, а в оригинале - только красные и зелёные. Но результат сложно контролировать.
4. Напрашивается решение - вместо поиска похожих цветов на никак не подготовленных моделях, подготовить модели таким образом, чтобы у них были специальные кодирующие цвета, а в шейдере связывать цвет-код с номером цвета из палитры. Т.е. код может быть малиновым, а результат будет любого оттенка, насыщенности и яркости, независимо от остальных цветов в палитре. Тогда можно будет легко перекрашивать всю сцену в любые цвета, или даже удалять отдельные цвета, делая их равными с соседними (два кодирующих цвета - один результат). Правда, по-моему, это не очень сочетается со стандартным шейдингом, разве что тун-шейдинг может помочь.
5. Интересно, что из этого может выйти. Возможно ли сделать большой опенворлд с таким эффектом, на 16-32 цвета максимум? Никакого "ретро", просто чтобы стилистически приятно выглядело (а не очередное "лоуполи"). Смотрю сейчас на эту вращающуюся модельку, так прикольно выглядит... Специально попробовал отдалить от камеры - конечно, не труъ пиксель-арт, но ведь главная проблема в исходных текстурах.
Там искать сложно, большинство ассетов скриптовые или 2D. Я помню, что были какие-то сцены специально для теста графики, но понятия не имею, как это называется или как найти. Прости, если грубо прозвучало, я просто хотел поделиться прикольным эффектом, который, оказывается, совсем не так уж сложно сделать.
>>25284 (Del)
Спасибо за ссылки.
>>25265
Есть кое-какие мысли:
1. Исходные цвета текстур + шейдинга должны быть ближе к цветам палитры, чтобы не было внезапных скачков с синего на оранжевое и обратно (очень заметно в движении). Т.е. когда исходный цвет приблизительно похож на два цвета из палитры, он может стать любым из них в разных условиях. Иными словами, работы с текстурами и светом не избежать...
2. С другой стороны, преимущества такого фильтра - возможность заменить палитру на что-то другое. Скажем, во время дождя всего лишь замена палитры на более тусклую и более синюю может передать значительную часть дождливой атмосферы. Ночью и в темноте, можно было бы вообще отключать красный и зелёный оттенки, т.к. в темноте человек их не различает. Переходы из палитры в палитру можно даже сделать плавными!
3. Однако для этого может оказаться недостаточно просто сменить палитру в шейдере. Конечно, алгоритм попытается найти ближайшие цвета, даже если в палитре будут только синие оттенки, а в оригинале - только красные и зелёные. Но результат сложно контролировать.
4. Напрашивается решение - вместо поиска похожих цветов на никак не подготовленных моделях, подготовить модели таким образом, чтобы у них были специальные кодирующие цвета, а в шейдере связывать цвет-код с номером цвета из палитры. Т.е. код может быть малиновым, а результат будет любого оттенка, насыщенности и яркости, независимо от остальных цветов в палитре. Тогда можно будет легко перекрашивать всю сцену в любые цвета, или даже удалять отдельные цвета, делая их равными с соседними (два кодирующих цвета - один результат). Правда, по-моему, это не очень сочетается со стандартным шейдингом, разве что тун-шейдинг может помочь.
5. Интересно, что из этого может выйти. Возможно ли сделать большой опенворлд с таким эффектом, на 16-32 цвета максимум? Никакого "ретро", просто чтобы стилистически приятно выглядело (а не очередное "лоуполи"). Смотрю сейчас на эту вращающуюся модельку, так прикольно выглядит... Специально попробовал отдалить от камеры - конечно, не труъ пиксель-арт, но ведь главная проблема в исходных текстурах.
>>25282
Там искать сложно, большинство ассетов скриптовые или 2D. Я помню, что были какие-то сцены специально для теста графики, но понятия не имею, как это называется или как найти. Прости, если грубо прозвучало, я просто хотел поделиться прикольным эффектом, который, оказывается, совсем не так уж сложно сделать.
>>25284 (Del)
Спасибо за ссылки.
>>25265
Есть кое-какие мысли:
1. Исходные цвета текстур + шейдинга должны быть ближе к цветам палитры, чтобы не было внезапных скачков с синего на оранжевое и обратно (очень заметно в движении). Т.е. когда исходный цвет приблизительно похож на два цвета из палитры, он может стать любым из них в разных условиях. Иными словами, работы с текстурами и светом не избежать...
2. С другой стороны, преимущества такого фильтра - возможность заменить палитру на что-то другое. Скажем, во время дождя всего лишь замена палитры на более тусклую и более синюю может передать значительную часть дождливой атмосферы. Ночью и в темноте, можно было бы вообще отключать красный и зелёный оттенки, т.к. в темноте человек их не различает. Переходы из палитры в палитру можно даже сделать плавными!
3. Однако для этого может оказаться недостаточно просто сменить палитру в шейдере. Конечно, алгоритм попытается найти ближайшие цвета, даже если в палитре будут только синие оттенки, а в оригинале - только красные и зелёные. Но результат сложно контролировать.
4. Напрашивается решение - вместо поиска похожих цветов на никак не подготовленных моделях, подготовить модели таким образом, чтобы у них были специальные кодирующие цвета, а в шейдере связывать цвет-код с номером цвета из палитры. Т.е. код может быть малиновым, а результат будет любого оттенка, насыщенности и яркости, независимо от остальных цветов в палитре. Тогда можно будет легко перекрашивать всю сцену в любые цвета, или даже удалять отдельные цвета, делая их равными с соседними (два кодирующих цвета - один результат). Правда, по-моему, это не очень сочетается со стандартным шейдингом, разве что тун-шейдинг может помочь.
5. Интересно, что из этого может выйти. Возможно ли сделать большой опенворлд с таким эффектом, на 16-32 цвета максимум? Никакого "ретро", просто чтобы стилистически приятно выглядело (а не очередное "лоуполи"). Смотрю сейчас на эту вращающуюся модельку, так прикольно выглядит... Специально попробовал отдалить от камеры - конечно, не труъ пиксель-арт, но ведь главная проблема в исходных текстурах.
Там искать сложно, большинство ассетов скриптовые или 2D. Я помню, что были какие-то сцены специально для теста графики, но понятия не имею, как это называется или как найти. Прости, если грубо прозвучало, я просто хотел поделиться прикольным эффектом, который, оказывается, совсем не так уж сложно сделать.
>>25284 (Del)
Спасибо за ссылки.
>>25265
Есть кое-какие мысли:
1. Исходные цвета текстур + шейдинга должны быть ближе к цветам палитры, чтобы не было внезапных скачков с синего на оранжевое и обратно (очень заметно в движении). Т.е. когда исходный цвет приблизительно похож на два цвета из палитры, он может стать любым из них в разных условиях. Иными словами, работы с текстурами и светом не избежать...
2. С другой стороны, преимущества такого фильтра - возможность заменить палитру на что-то другое. Скажем, во время дождя всего лишь замена палитры на более тусклую и более синюю может передать значительную часть дождливой атмосферы. Ночью и в темноте, можно было бы вообще отключать красный и зелёный оттенки, т.к. в темноте человек их не различает. Переходы из палитры в палитру можно даже сделать плавными!
3. Однако для этого может оказаться недостаточно просто сменить палитру в шейдере. Конечно, алгоритм попытается найти ближайшие цвета, даже если в палитре будут только синие оттенки, а в оригинале - только красные и зелёные. Но результат сложно контролировать.
4. Напрашивается решение - вместо поиска похожих цветов на никак не подготовленных моделях, подготовить модели таким образом, чтобы у них были специальные кодирующие цвета, а в шейдере связывать цвет-код с номером цвета из палитры. Т.е. код может быть малиновым, а результат будет любого оттенка, насыщенности и яркости, независимо от остальных цветов в палитре. Тогда можно будет легко перекрашивать всю сцену в любые цвета, или даже удалять отдельные цвета, делая их равными с соседними (два кодирующих цвета - один результат). Правда, по-моему, это не очень сочетается со стандартным шейдингом, разве что тун-шейдинг может помочь.
5. Интересно, что из этого может выйти. Возможно ли сделать большой опенворлд с таким эффектом, на 16-32 цвета максимум? Никакого "ретро", просто чтобы стилистически приятно выглядело (а не очередное "лоуполи"). Смотрю сейчас на эту вращающуюся модельку, так прикольно выглядит... Специально попробовал отдалить от камеры - конечно, не труъ пиксель-арт, но ведь главная проблема в исходных текстурах.
>>25249
Смотри исходники, например, вот Node3D (бывший Spatial):
Интерфейс:
https://github.com/godotengine/godot/blob/master/scene/3d/node_3d.h
Реализация:
https://github.com/godotengine/godot/blob/master/scene/3d/node_3d.cpp
Ну там по папкам побегай, всё логично называется, сложно заблудиться.
>Под описаниями я имею в виду тело описания класса.
Смотри исходники, например, вот Node3D (бывший Spatial):
Интерфейс:
https://github.com/godotengine/godot/blob/master/scene/3d/node_3d.h
Реализация:
https://github.com/godotengine/godot/blob/master/scene/3d/node_3d.cpp
Ну там по папкам побегай, всё логично называется, сложно заблудиться.
>>25264
Да. Он даже специально затачивается под новичков в геймдеве. Но, в отличие от "детских" инструментов по типу Scratch, это полноценный "взрослый" инструмент, пусть пока и не очень популярный.
Хорошо, что у тебя уже есть какие-то поделки. Главное изучай туториалы без спешки, не перепрыгивая страницы/главы. Начни с официальных туториалов "GETTING STARTED", которые есть в документации: https://docs.godotengine.org/en/stable/ - они позволят освоиться с основными элементами движка.
Сложный жанр, если подходить к делу серьёзно. Обычно рекомендуют первой игрой брать 2D, платформеры, головоломки и всё такое. Но если ты не из тех, кто психует и всё бросает, сможешь осилить и 3D РПГ первой игрой.
Можешь накидать прототип из встроенных CSG фигур (результат может быть немного кривым с пропадающими треугольниками, но это чисто для прототипов инструмент):
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Для любого вида локации полезно сначала сделать "blockout", т.е. набросать геометрию примитивными фигурами, а уже потом заменять эти фигуры красивыми моделями с текстурами. Для прототипа локации удобно использовать такие текстуры:
https://youtu.be/mGaBfyAx25M https://kenney.nl/assets/prototype-textures
Заранее предупрежу, чтобы не расстраивался: в Godot нет встроенного "ландшафта", т.е. компонента для создания почвы с травой. Есть аддоны, добавляющие такой ландшафт, но можно просто замоделить в Blender и импортировать. Проблемы начнутся только если тебе хочется многокилометровый ландшафт; текущая версия (3.x) имеет мало оптимизаций для 3D графики, поэтому придётся оптимизировать самому или ждать выхода стабильной 4.0 версии. Однако для небольших локаций с разумным уровнем детализации оптимизаций может вообще не потребоваться.
Для персонажа можешь скачать готовый контроллер персонажа от первого или от третьего лица. В туториалах обычно только самый примитив показывают, а самому с нуля писать довольно муторно.
GUI в Godot очень хороший, легко справишься с этим. Подсказка: повесь на персонажа игрока один RayCast в направлении взгляда, так игрок сможет выбирать неигрового персонажа одним только взглядом, но на ограниченном расстоянии.
Тут тебе в основном математика потребуется.
А здесь потребуется делать "поиск пути" и какой-то алгоритм принятия решений. Здесь часто рекомендуют GOAP, но для первого опыта обычного конечного автомата хватит. Поиск пути можно реализовать через навмеши или AStar, каждый метод имеет свои преимущества в зависимости от дизайна твоей карты.
Не знаю, что ты имеешь в виду, но сложность этого будет зависеть от сложности 3D модели твоего персонажа. Вкратце, в 3D играх одежда персонажей заменяет им кожу, т.е. чтобы "раздеться догола" необходимо удалить или скрыть меши одежды и добавить или отобразить меши с текстурой кожи. Самое сложное, как мне кажется, это скрыть швы на стыках между разными элементами одежды/частями тела персонажа. В худшем случае персонаж будет выглядеть как шарнирная кукла, но если у тебя такая стилизация, то это даже хорошо. В любом случае, от движка это всё не зависит.
Да, всё реализуемо, хотя что-то проще, что-то сложнее.
Нет, не нужно, ты можешь не знать очень многих вещей о движке, чтобы слепить на нём играбельный прототип игры. Скажем, ты ничего не сказал про звук и сеть - поэтому тебе сейчас не нужно изучать работу со звуком и сетью на Godot, не забивай себе этим голову, пока не потребуется в игре. Если ты делаешь чисто 3D игру, тебе достаточно знать основные ноды-потомки Spatial (Node3D в 4.0), а потомки Node2D можешь игнорировать. Вообще, очень много встроенных нод, но многие тебе могут вообще никогда не понадобиться, поэтому изучай по мере необходимости. Вот GDScript советую изучить подробно, чтобы писать хороший чистый код и пользоваться встроенными возможностями, а то начнёшь изобретать велосипеды и потом сам в своём коде не разберёшься. Но для прохождения начальных туториалов прям целиком язык изучать не нужно, достаточно повторять по шагам и экспериментировать.
Короче, удачи, по возможности хвастайся в треде об успехах со скриншотами и видео, а то что-то у нас тредов даже больше, чем у "конкурентов", а постинг как будто медленнее, чем у них...
>этот движок подходит под полного нуба?
Да. Он даже специально затачивается под новичков в геймдеве. Но, в отличие от "детских" инструментов по типу Scratch, это полноценный "взрослый" инструмент, пусть пока и не очень популярный.
>хочется изучать туториалы, параллельно наполняя окружение своими поделками в блендере
Хорошо, что у тебя уже есть какие-то поделки. Главное изучай туториалы без спешки, не перепрыгивая страницы/главы. Начни с официальных туториалов "GETTING STARTED", которые есть в документации: https://docs.godotengine.org/en/stable/ - они позволят освоиться с основными элементами движка.
>Жанр - РПГ
Сложный жанр, если подходить к делу серьёзно. Обычно рекомендуют первой игрой брать 2D, платформеры, головоломки и всё такое. Но если ты не из тех, кто психует и всё бросает, сможешь осилить и 3D РПГ первой игрой.
>Моей первой планкой будет создание локации, и ее проработка.
Можешь накидать прототип из встроенных CSG фигур (результат может быть немного кривым с пропадающими треугольниками, но это чисто для прототипов инструмент):
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Для любого вида локации полезно сначала сделать "blockout", т.е. набросать геометрию примитивными фигурами, а уже потом заменять эти фигуры красивыми моделями с текстурами. Для прототипа локации удобно использовать такие текстуры:
https://youtu.be/mGaBfyAx25M https://kenney.nl/assets/prototype-textures
Заранее предупрежу, чтобы не расстраивался: в Godot нет встроенного "ландшафта", т.е. компонента для создания почвы с травой. Есть аддоны, добавляющие такой ландшафт, но можно просто замоделить в Blender и импортировать. Проблемы начнутся только если тебе хочется многокилометровый ландшафт; текущая версия (3.x) имеет мало оптимизаций для 3D графики, поэтому придётся оптимизировать самому или ждать выхода стабильной 4.0 версии. Однако для небольших локаций с разумным уровнем детализации оптимизаций может вообще не потребоваться.
>Далее я хочу добавить персонажа и неписей
Для персонажа можешь скачать готовый контроллер персонажа от первого или от третьего лица. В туториалах обычно только самый примитив показывают, а самому с нуля писать довольно муторно.
>взаимодействие с ними посредством диалогового окна.
GUI в Godot очень хороший, легко справишься с этим. Подсказка: повесь на персонажа игрока один RayCast в направлении взгляда, так игрок сможет выбирать неигрового персонажа одним только взглядом, но на ограниченном расстоянии.
>И уже потом характеристики, элементарная боевая система
Тут тебе в основном математика потребуется.
>враждебные нпс.
А здесь потребуется делать "поиск пути" и какой-то алгоритм принятия решений. Здесь часто рекомендуют GOAP, но для первого опыта обычного конечного автомата хватит. Поиск пути можно реализовать через навмеши или AStar, каждый метод имеет свои преимущества в зависимости от дизайна твоей карты.
>Последним этапом будет экипировка.
Не знаю, что ты имеешь в виду, но сложность этого будет зависеть от сложности 3D модели твоего персонажа. Вкратце, в 3D играх одежда персонажей заменяет им кожу, т.е. чтобы "раздеться догола" необходимо удалить или скрыть меши одежды и добавить или отобразить меши с текстурой кожи. Самое сложное, как мне кажется, это скрыть швы на стыках между разными элементами одежды/частями тела персонажа. В худшем случае персонаж будет выглядеть как шарнирная кукла, но если у тебя такая стилизация, то это даже хорошо. В любом случае, от движка это всё не зависит.
>Это реализуемо на годоте
Да, всё реализуемо, хотя что-то проще, что-то сложнее.
>или для этого нужно полностью знать движок от и до?
Нет, не нужно, ты можешь не знать очень многих вещей о движке, чтобы слепить на нём играбельный прототип игры. Скажем, ты ничего не сказал про звук и сеть - поэтому тебе сейчас не нужно изучать работу со звуком и сетью на Godot, не забивай себе этим голову, пока не потребуется в игре. Если ты делаешь чисто 3D игру, тебе достаточно знать основные ноды-потомки Spatial (Node3D в 4.0), а потомки Node2D можешь игнорировать. Вообще, очень много встроенных нод, но многие тебе могут вообще никогда не понадобиться, поэтому изучай по мере необходимости. Вот GDScript советую изучить подробно, чтобы писать хороший чистый код и пользоваться встроенными возможностями, а то начнёшь изобретать велосипеды и потом сам в своём коде не разберёшься. Но для прохождения начальных туториалов прям целиком язык изучать не нужно, достаточно повторять по шагам и экспериментировать.
Короче, удачи, по возможности хвастайся в треде об успехах со скриншотами и видео, а то что-то у нас тредов даже больше, чем у "конкурентов", а постинг как будто медленнее, чем у них...
>>25264
Да. Он даже специально затачивается под новичков в геймдеве. Но, в отличие от "детских" инструментов по типу Scratch, это полноценный "взрослый" инструмент, пусть пока и не очень популярный.
Хорошо, что у тебя уже есть какие-то поделки. Главное изучай туториалы без спешки, не перепрыгивая страницы/главы. Начни с официальных туториалов "GETTING STARTED", которые есть в документации: https://docs.godotengine.org/en/stable/ - они позволят освоиться с основными элементами движка.
Сложный жанр, если подходить к делу серьёзно. Обычно рекомендуют первой игрой брать 2D, платформеры, головоломки и всё такое. Но если ты не из тех, кто психует и всё бросает, сможешь осилить и 3D РПГ первой игрой.
Можешь накидать прототип из встроенных CSG фигур (результат может быть немного кривым с пропадающими треугольниками, но это чисто для прототипов инструмент):
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Для любого вида локации полезно сначала сделать "blockout", т.е. набросать геометрию примитивными фигурами, а уже потом заменять эти фигуры красивыми моделями с текстурами. Для прототипа локации удобно использовать такие текстуры:
https://youtu.be/mGaBfyAx25M https://kenney.nl/assets/prototype-textures
Заранее предупрежу, чтобы не расстраивался: в Godot нет встроенного "ландшафта", т.е. компонента для создания почвы с травой. Есть аддоны, добавляющие такой ландшафт, но можно просто замоделить в Blender и импортировать. Проблемы начнутся только если тебе хочется многокилометровый ландшафт; текущая версия (3.x) имеет мало оптимизаций для 3D графики, поэтому придётся оптимизировать самому или ждать выхода стабильной 4.0 версии. Однако для небольших локаций с разумным уровнем детализации оптимизаций может вообще не потребоваться.
Для персонажа можешь скачать готовый контроллер персонажа от первого или от третьего лица. В туториалах обычно только самый примитив показывают, а самому с нуля писать довольно муторно.
GUI в Godot очень хороший, легко справишься с этим. Подсказка: повесь на персонажа игрока один RayCast в направлении взгляда, так игрок сможет выбирать неигрового персонажа одним только взглядом, но на ограниченном расстоянии.
Тут тебе в основном математика потребуется.
А здесь потребуется делать "поиск пути" и какой-то алгоритм принятия решений. Здесь часто рекомендуют GOAP, но для первого опыта обычного конечного автомата хватит. Поиск пути можно реализовать через навмеши или AStar, каждый метод имеет свои преимущества в зависимости от дизайна твоей карты.
Не знаю, что ты имеешь в виду, но сложность этого будет зависеть от сложности 3D модели твоего персонажа. Вкратце, в 3D играх одежда персонажей заменяет им кожу, т.е. чтобы "раздеться догола" необходимо удалить или скрыть меши одежды и добавить или отобразить меши с текстурой кожи. Самое сложное, как мне кажется, это скрыть швы на стыках между разными элементами одежды/частями тела персонажа. В худшем случае персонаж будет выглядеть как шарнирная кукла, но если у тебя такая стилизация, то это даже хорошо. В любом случае, от движка это всё не зависит.
Да, всё реализуемо, хотя что-то проще, что-то сложнее.
Нет, не нужно, ты можешь не знать очень многих вещей о движке, чтобы слепить на нём играбельный прототип игры. Скажем, ты ничего не сказал про звук и сеть - поэтому тебе сейчас не нужно изучать работу со звуком и сетью на Godot, не забивай себе этим голову, пока не потребуется в игре. Если ты делаешь чисто 3D игру, тебе достаточно знать основные ноды-потомки Spatial (Node3D в 4.0), а потомки Node2D можешь игнорировать. Вообще, очень много встроенных нод, но многие тебе могут вообще никогда не понадобиться, поэтому изучай по мере необходимости. Вот GDScript советую изучить подробно, чтобы писать хороший чистый код и пользоваться встроенными возможностями, а то начнёшь изобретать велосипеды и потом сам в своём коде не разберёшься. Но для прохождения начальных туториалов прям целиком язык изучать не нужно, достаточно повторять по шагам и экспериментировать.
Короче, удачи, по возможности хвастайся в треде об успехах со скриншотами и видео, а то что-то у нас тредов даже больше, чем у "конкурентов", а постинг как будто медленнее, чем у них...
>этот движок подходит под полного нуба?
Да. Он даже специально затачивается под новичков в геймдеве. Но, в отличие от "детских" инструментов по типу Scratch, это полноценный "взрослый" инструмент, пусть пока и не очень популярный.
>хочется изучать туториалы, параллельно наполняя окружение своими поделками в блендере
Хорошо, что у тебя уже есть какие-то поделки. Главное изучай туториалы без спешки, не перепрыгивая страницы/главы. Начни с официальных туториалов "GETTING STARTED", которые есть в документации: https://docs.godotengine.org/en/stable/ - они позволят освоиться с основными элементами движка.
>Жанр - РПГ
Сложный жанр, если подходить к делу серьёзно. Обычно рекомендуют первой игрой брать 2D, платформеры, головоломки и всё такое. Но если ты не из тех, кто психует и всё бросает, сможешь осилить и 3D РПГ первой игрой.
>Моей первой планкой будет создание локации, и ее проработка.
Можешь накидать прототип из встроенных CSG фигур (результат может быть немного кривым с пропадающими треугольниками, но это чисто для прототипов инструмент):
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Для любого вида локации полезно сначала сделать "blockout", т.е. набросать геометрию примитивными фигурами, а уже потом заменять эти фигуры красивыми моделями с текстурами. Для прототипа локации удобно использовать такие текстуры:
https://youtu.be/mGaBfyAx25M https://kenney.nl/assets/prototype-textures
Заранее предупрежу, чтобы не расстраивался: в Godot нет встроенного "ландшафта", т.е. компонента для создания почвы с травой. Есть аддоны, добавляющие такой ландшафт, но можно просто замоделить в Blender и импортировать. Проблемы начнутся только если тебе хочется многокилометровый ландшафт; текущая версия (3.x) имеет мало оптимизаций для 3D графики, поэтому придётся оптимизировать самому или ждать выхода стабильной 4.0 версии. Однако для небольших локаций с разумным уровнем детализации оптимизаций может вообще не потребоваться.
>Далее я хочу добавить персонажа и неписей
Для персонажа можешь скачать готовый контроллер персонажа от первого или от третьего лица. В туториалах обычно только самый примитив показывают, а самому с нуля писать довольно муторно.
>взаимодействие с ними посредством диалогового окна.
GUI в Godot очень хороший, легко справишься с этим. Подсказка: повесь на персонажа игрока один RayCast в направлении взгляда, так игрок сможет выбирать неигрового персонажа одним только взглядом, но на ограниченном расстоянии.
>И уже потом характеристики, элементарная боевая система
Тут тебе в основном математика потребуется.
>враждебные нпс.
А здесь потребуется делать "поиск пути" и какой-то алгоритм принятия решений. Здесь часто рекомендуют GOAP, но для первого опыта обычного конечного автомата хватит. Поиск пути можно реализовать через навмеши или AStar, каждый метод имеет свои преимущества в зависимости от дизайна твоей карты.
>Последним этапом будет экипировка.
Не знаю, что ты имеешь в виду, но сложность этого будет зависеть от сложности 3D модели твоего персонажа. Вкратце, в 3D играх одежда персонажей заменяет им кожу, т.е. чтобы "раздеться догола" необходимо удалить или скрыть меши одежды и добавить или отобразить меши с текстурой кожи. Самое сложное, как мне кажется, это скрыть швы на стыках между разными элементами одежды/частями тела персонажа. В худшем случае персонаж будет выглядеть как шарнирная кукла, но если у тебя такая стилизация, то это даже хорошо. В любом случае, от движка это всё не зависит.
>Это реализуемо на годоте
Да, всё реализуемо, хотя что-то проще, что-то сложнее.
>или для этого нужно полностью знать движок от и до?
Нет, не нужно, ты можешь не знать очень многих вещей о движке, чтобы слепить на нём играбельный прототип игры. Скажем, ты ничего не сказал про звук и сеть - поэтому тебе сейчас не нужно изучать работу со звуком и сетью на Godot, не забивай себе этим голову, пока не потребуется в игре. Если ты делаешь чисто 3D игру, тебе достаточно знать основные ноды-потомки Spatial (Node3D в 4.0), а потомки Node2D можешь игнорировать. Вообще, очень много встроенных нод, но многие тебе могут вообще никогда не понадобиться, поэтому изучай по мере необходимости. Вот GDScript советую изучить подробно, чтобы писать хороший чистый код и пользоваться встроенными возможностями, а то начнёшь изобретать велосипеды и потом сам в своём коде не разберёшься. Но для прохождения начальных туториалов прям целиком язык изучать не нужно, достаточно повторять по шагам и экспериментировать.
Короче, удачи, по возможности хвастайся в треде об успехах со скриншотами и видео, а то что-то у нас тредов даже больше, чем у "конкурентов", а постинг как будто медленнее, чем у них...
Годаны, зацените, что я придумал. Принцип обратного кодинга. Сначала пишешь строку, как бы тебе хотелось обращаться к свойствам игры и объектов. Эта строка будет выдавать ошибки. Затем ты добавляешь классы и методы до тех пор, пока эта строка не перестанет выдавать ошибку. Есть ли в кодинге подобные подходы? Наверняка я велосипед изобрёл. Приведу пример. Сначала пишешь так:
Подразумевая, что данная строка закинет персонажу игрока в инвентарь 100 голды.
Затем начинаешь создавать всё, что требуется этой строке, чтобы она перестала светиться красным.
1. ссылка на player это объект, имеющий в себе свойство inventory
2. inventory имеет метод add_item(type, amount)
3. type подтягивается из объекта-базы или перечисления, кому как удобнее
4. ссылка на items должна тоже быть.
Принцип обратного кодинга.
Дискасс.
> player.inventory.add_item(items.gold_coin, 100)
Подразумевая, что данная строка закинет персонажу игрока в инвентарь 100 голды.
Затем начинаешь создавать всё, что требуется этой строке, чтобы она перестала светиться красным.
1. ссылка на player это объект, имеющий в себе свойство inventory
2. inventory имеет метод add_item(type, amount)
3. type подтягивается из объекта-базы или перечисления, кому как удобнее
4. ссылка на items должна тоже быть.
Принцип обратного кодинга.
Дискасс.
>>25398
декларативно дописывая код в критической ошибке, надеяться, что с последней скобкой ошибка рассосётся и на выходе будет идеально отлаженный код, чутка наивно
на практике ты держишь эту строку в голове, прототипируешь класс плеера, инвентаря и метод add_item в нём, с телом-пустышкой
добавляешь эту строку, запускаешь код, и, если всё работает, дописываешь нужную логику в add_item
принцип обратного кодинга, также известный как принцип просто кодинга. если бы процесс реально шел наоборот, то мы, программируя некий бэкэнд, броуновским движением приближались бы к финальной идее, оставаясь в полном неведении до момента, когда у нас щелкнуло бы в голове "о, так я всё это писал ради того, чтобы добавить сюда функцию add item, теперь понятно!"
декларативно дописывая код в критической ошибке, надеяться, что с последней скобкой ошибка рассосётся и на выходе будет идеально отлаженный код, чутка наивно
на практике ты держишь эту строку в голове, прототипируешь класс плеера, инвентаря и метод add_item в нём, с телом-пустышкой
добавляешь эту строку, запускаешь код, и, если всё работает, дописываешь нужную логику в add_item
принцип обратного кодинга, также известный как принцип просто кодинга. если бы процесс реально шел наоборот, то мы, программируя некий бэкэнд, броуновским движением приближались бы к финальной идее, оставаясь в полном неведении до момента, когда у нас щелкнуло бы в голове "о, так я всё это писал ради того, чтобы добавить сюда функцию add item, теперь понятно!"
>>25409
Обоснованные доводы. Принимаются.
Обоснованные доводы. Принимаются.
Насколько легко в годоте реализуется переход между локациями? Как мне уже выше ответили, многокилометровые ландшафты не оптимизированы, может быть есть какая то реализация быстрой прогрузки?
>>25486
Причем желательно чтобы при переходе в новую локацию, игрок мог позади наблюдать место откуда он ушел.
Я понимаю что можно вставить костыли в виде огромных врат или пещер, но может уже все придумано
Причем желательно чтобы при переходе в новую локацию, игрок мог позади наблюдать место откуда он ушел.
Я понимаю что можно вставить костыли в виде огромных врат или пещер, но может уже все придумано
>>25490 (Del)
Охуенный ассет, погонял щас демку. Красота!
Охуенный ассет, погонял щас демку. Красота!
>>25500 (Del)
О, а тут как раз пригодится моя патентованная ворлд-сейв-система, которую я периодически пиарю из треда в тред.
Суть её токова, есть глобальный словарь world разбитый на несколько секций, каждая из которых может быть разбита на подсекции. Глобальный словарь содержит в себе данные всех зон, всех предметов, всех НПЦ. Это глобальная база данных, в которую все, кто желает сохраняться, постоянно пишут свои изменения. Таким образом, при выгрузке зоны ничего не надо делать, если были какие-то изменения, они уже записаны. При следующей загрузке они прочитаются. Соответственно, добавить для зон нужно только чтение конфига из глобального словаря при загрузке.
Сохранение игры в этом случае предельно просто: сохраняется этот глобальный словарь.
> You need to save your zone data when it is unloaded and restore it when the zone is loaded
О, а тут как раз пригодится моя патентованная ворлд-сейв-система, которую я периодически пиарю из треда в тред.
Суть её токова, есть глобальный словарь world разбитый на несколько секций, каждая из которых может быть разбита на подсекции. Глобальный словарь содержит в себе данные всех зон, всех предметов, всех НПЦ. Это глобальная база данных, в которую все, кто желает сохраняться, постоянно пишут свои изменения. Таким образом, при выгрузке зоны ничего не надо делать, если были какие-то изменения, они уже записаны. При следующей загрузке они прочитаются. Соответственно, добавить для зон нужно только чтение конфига из глобального словаря при загрузке.
Сохранение игры в этом случае предельно просто: сохраняется этот глобальный словарь.
>>25504
Эту систему за прошедшие треды я дополнил следующими фишками:
1. Глобальных словарей как минимум два, эталонный и корректировочный. Эталонный существует рид-онли и олицетворяет собой состояние мира на начало игры. Он может быть очень большим, при запуске игры он может собираться из нескольких [десятков! сотен!] отдельных файлов-ресурсов (в том числе модов, масштабируемость - ё-маё). Корректировочный словарь олицетворяет состояние мира с течением времени, в котором отражена как симуляция мира игрой, так и само собой действия игрока. Корректировочный словарь намного меньше эталонного, но по мере игры может расти. И он как раз является содержимым для сейв-файла. Алгоритм чтения данных из двух словарей тривиален: ищем данные в корректировке, если да, возвращаем, если нет, ищем в эталоне, если да, возвращаем, если нет, возвращаем указанное дефолтное значение.
2. Симуляция мира может охватывать весь мир целиком, и она может работать с базой данных из вышеописанных двух словарей. Изменять значения в них соответственно алгоритму симуляции. Таким образом, если непись шел из зоны А в зону Ц за время Т, игрок мог проследить за его передвижением, находясь в этих зонах, но если игрок был в зоне Б, то всё равно менеджер симуляции мира, будет с периодическим шагом обновлять координаты непися в словаре-корректировке таким образом, что через Т времени непись окажется приписан к зоне Ц, и игрок встретит его там. Я писал об этом ИТТ.
>>25510
Спасибо!
Эту систему за прошедшие треды я дополнил следующими фишками:
1. Глобальных словарей как минимум два, эталонный и корректировочный. Эталонный существует рид-онли и олицетворяет собой состояние мира на начало игры. Он может быть очень большим, при запуске игры он может собираться из нескольких [десятков! сотен!] отдельных файлов-ресурсов (в том числе модов, масштабируемость - ё-маё). Корректировочный словарь олицетворяет состояние мира с течением времени, в котором отражена как симуляция мира игрой, так и само собой действия игрока. Корректировочный словарь намного меньше эталонного, но по мере игры может расти. И он как раз является содержимым для сейв-файла. Алгоритм чтения данных из двух словарей тривиален: ищем данные в корректировке, если да, возвращаем, если нет, ищем в эталоне, если да, возвращаем, если нет, возвращаем указанное дефолтное значение.
2. Симуляция мира может охватывать весь мир целиком, и она может работать с базой данных из вышеописанных двух словарей. Изменять значения в них соответственно алгоритму симуляции. Таким образом, если непись шел из зоны А в зону Ц за время Т, игрок мог проследить за его передвижением, находясь в этих зонах, но если игрок был в зоне Б, то всё равно менеджер симуляции мира, будет с периодическим шагом обновлять координаты непися в словаре-корректировке таким образом, что через Т времени непись окажется приписан к зоне Ц, и игрок встретит его там. Я писал об этом ИТТ.
>>25510
Спасибо!
>>25513
Ах и да.
3. Собсна говоря, чтобы оптимизировать работу с памятью, я планирую аддоном подключать к проекту базу данных, и вместо вышеописанных словарей юзать таблицы.
Например https://godotengine.org/asset-library/asset/444
Ах и да.
3. Собсна говоря, чтобы оптимизировать работу с памятью, я планирую аддоном подключать к проекту базу данных, и вместо вышеописанных словарей юзать таблицы.
Например https://godotengine.org/asset-library/asset/444
>>25516
Да ты так скоро изобретешь сервер-клиент систему
Да ты так скоро изобретешь сервер-клиент систему
>>15359 (OP)
Недавно вкатился в написание модулей на крестах и всё бы хорошо но в editor кастомные ноды появляются раз на раз. Иногда после первого запуска игры, иногда появляются в рандомный момент. Вроде бы всё настроил по туториалу с официальной документации. Ну разве что сам модуль помещён в папку addons и оформлен как плагин чтобы легче было юзать и распространять. Сталкивался ли кто-то с такой проблеммой? Я заебался, уже думаю переписывать всю хуйню на чистом C++ и raylib. Алсо, вместо ебатни с трёшкой мб стоит на альфу 4.0 перейти? Я слышал там новая система для C/C++ модулей...
Недавно вкатился в написание модулей на крестах и всё бы хорошо но в editor кастомные ноды появляются раз на раз. Иногда после первого запуска игры, иногда появляются в рандомный момент. Вроде бы всё настроил по туториалу с официальной документации. Ну разве что сам модуль помещён в папку addons и оформлен как плагин чтобы легче было юзать и распространять. Сталкивался ли кто-то с такой проблеммой? Я заебался, уже думаю переписывать всю хуйню на чистом C++ и raylib. Алсо, вместо ебатни с трёшкой мб стоит на альфу 4.0 перейти? Я слышал там новая система для C/C++ модулей...
Неделю разбираюсь с годотом, вообще мне все нравится, но есть вещи которые ОЧЕНЬ НАПРЯГАЮТ. И у этих вещей есть определенный паттерн, так сказать:
1. У CollisionObject есть какой-то незадокументированный shape owner (только упомянут).
2. Есть какие-то методы set_deferred и call_deferred, которыми нужно пользоваться если проперти или метод можно вызвать только на следующем тике физики. Точный список вещей, которые надо вызывать так, когда это делать, и т.п. не задокументировано.
На гитхабе просьбы разъяснить или переделать это висят с 2020 года. Я боюсь представить сколько еще такой хуйни. Да, можно найти предположения других людей (что само по себе лол - предположения!), можно какие-то обрывочные сведения. Но все равно эти вещи не задокументировоаны!
Это же полный пиздец, получается на годоте пока можно только туториалы собирать. Я прикидывал как сделать более сложную систему хитбоксов/хуртбоксов (например для файтинга), но в таком состоянии это невозможно.
И не надо мне рассказывать как это работает, лучше скажите - есть какой-то роадмап когда доки будут написаны? Я не нашел ничего конкретного, только призывы их писать, даже списка признанных разработчиками белых пятен, которые могут вызвать баги, типа выше перечсленных, нет.
Я не тролю и это не движкосрач, реально нравился годот, и тут такое разочарование.
1. У CollisionObject есть какой-то незадокументированный shape owner (только упомянут).
2. Есть какие-то методы set_deferred и call_deferred, которыми нужно пользоваться если проперти или метод можно вызвать только на следующем тике физики. Точный список вещей, которые надо вызывать так, когда это делать, и т.п. не задокументировано.
На гитхабе просьбы разъяснить или переделать это висят с 2020 года. Я боюсь представить сколько еще такой хуйни. Да, можно найти предположения других людей (что само по себе лол - предположения!), можно какие-то обрывочные сведения. Но все равно эти вещи не задокументировоаны!
Это же полный пиздец, получается на годоте пока можно только туториалы собирать. Я прикидывал как сделать более сложную систему хитбоксов/хуртбоксов (например для файтинга), но в таком состоянии это невозможно.
И не надо мне рассказывать как это работает, лучше скажите - есть какой-то роадмап когда доки будут написаны? Я не нашел ничего конкретного, только призывы их писать, даже списка признанных разработчиками белых пятен, которые могут вызвать баги, типа выше перечсленных, нет.
Я не тролю и это не движкосрач, реально нравился годот, и тут такое разочарование.
>>25561 (Del)
Это несерьезно, исходники лол. Во-первых, должно быть четкое разделение на то что меня касается и что нет. В упомянутых deterred это касается меня - если я не использую их там где надо, годот молча, не выдавая никаких ошибок в коде или в рантайме не выполнит вызов - это трудноустранимый баг. Deterred вызовы усложняют код (например, если результат вызова как-то используется - он будет доступен только в следующем апдейте) и пихать под них все подряд нельзя. И где про это написано? В туториале 2д игры про амеб!
В документации самого колижен шейп 2д про это ничего не сказано. Зато там сказано:
То есть это эдитор онли хелпер, но в туториале предлагается юзать его в рантайме, но этого делать не надо, вместо этого используйте колижен обжект 2д с незадокументированными овнерами.
Итого:
Незадокументированная вызывающая критические баги особенность, объект про который доки АЖ ОРУТ НАХУЙ не испольовать в рантайме используется в рантайме, целая незадокументированная важная система, без которой я хз как делать колижены.
Это несерьезно, исходники лол. Во-первых, должно быть четкое разделение на то что меня касается и что нет. В упомянутых deterred это касается меня - если я не использую их там где надо, годот молча, не выдавая никаких ошибок в коде или в рантайме не выполнит вызов - это трудноустранимый баг. Deterred вызовы усложняют код (например, если результат вызова как-то используется - он будет доступен только в следующем апдейте) и пихать под них все подряд нельзя. И где про это написано? В туториале 2д игры про амеб!
> # Must be deferred as we can't change physics properties on a physics callback.
> $CollisionShape2D.set_deferred("disabled", true)
В документации самого колижен шейп 2д про это ничего не сказано. Зато там сказано:
>IMPORTANT: this is an Editor-only helper to create shapes, use CollisionObject2D.shape_owner_get_shape to get the actual shape.
То есть это эдитор онли хелпер, но в туториале предлагается юзать его в рантайме, но этого делать не надо, вместо этого используйте колижен обжект 2д с незадокументированными овнерами.
Итого:
Незадокументированная вызывающая критические баги особенность, объект про который доки АЖ ОРУТ НАХУЙ не испольовать в рантайме используется в рантайме, целая незадокументированная важная система, без которой я хз как делать колижены.
65 Кб, 717x327>>25563
Ах да, хитбоксы в файтингах, наверное, самые сложные хитбоксы в геймдеве. Пикрелейтед - хитбоксы для одного кадра анимации. Я думал писать для хитбоксов целый отдельный мини редактор, так будет удобнее. Но это ладно, главное что их надо каждый кадр переключать, и это дело уже входит в серую зону непонятного хелпера и других приколов.
Выклянчивать инфу у других неприятно, рабоать методом тыка неприятно. Ощущение что я хуй какой-то а не относительно опытный программист. Вот серьезно, это просто удар под дых. Годот надо жестко трясти и канселить пока они не начнут что-то с этим делать, потому что знающему человеку описать в двух словах все что касается деферред это минут 20 наверное, а хелперы все 5. Но это не сделано с 2020 года минимум.
Ах да, хитбоксы в файтингах, наверное, самые сложные хитбоксы в геймдеве. Пикрелейтед - хитбоксы для одного кадра анимации. Я думал писать для хитбоксов целый отдельный мини редактор, так будет удобнее. Но это ладно, главное что их надо каждый кадр переключать, и это дело уже входит в серую зону непонятного хелпера и других приколов.
Выклянчивать инфу у других неприятно, рабоать методом тыка неприятно. Ощущение что я хуй какой-то а не относительно опытный программист. Вот серьезно, это просто удар под дых. Годот надо жестко трясти и канселить пока они не начнут что-то с этим делать, потому что знающему человеку описать в двух словах все что касается деферред это минут 20 наверное, а хелперы все 5. Но это не сделано с 2020 года минимум.
>>25565 (Del)
Не неси хуйню. В исходниках чтобы понять как работает какая-то часть движка в целом надо несколько месяцев копаться. А это взаимодействие нескольких систем, это тысячи строк кода на с++.
>>25566 (Del)
https://www.youtube.com/watch?v=2mAGmWvwUHw
Еще раз повторяю, что это не дело. Разраб в дискорде сказал гдквесту (или кому то еще), он выпустил быдлотуториал. Не дело.
Не неси хуйню. В исходниках чтобы понять как работает какая-то часть движка в целом надо несколько месяцев копаться. А это взаимодействие нескольких систем, это тысячи строк кода на с++.
>>25566 (Del)
https://www.youtube.com/watch?v=2mAGmWvwUHw
Еще раз повторяю, что это не дело. Разраб в дискорде сказал гдквесту (или кому то еще), он выпустил быдлотуториал. Не дело.
55 Кб, 1148x480>>25568 (Del)
Насчет сорцов повторяю - сам попробуй бля. Ты вообще понимаешь о чем ты говоришь?
Потестил deferred, оказалось что спамит ошибками в консольку, ну на этом спасибо, конечно. Но общее впечатление не изменилось. Экспорт молча игнорит это, бтв.
Насчет сорцов повторяю - сам попробуй бля. Ты вообще понимаешь о чем ты говоришь?
Потестил deferred, оказалось что спамит ошибками в консольку, ну на этом спасибо, конечно. Но общее впечатление не изменилось. Экспорт молча игнорит это, бтв.
>>25570 (Del)
Переиграл и уничтожил дешовку! Браво!
Переиграл и уничтожил дешовку! Браво!
>>25564
Чувак, такие хитбокы только в членодевках есть, потому что там геймдиз малахольный. Обычно все гораздо проще.
>Пикрелейтед - хитбоксы для одного кадра анимации
Чувак, такие хитбокы только в членодевках есть, потому что там геймдиз малахольный. Обычно все гораздо проще.
>>25583 (Del)
Вдобавок, от себя хочу заметить, что несмотря на то, что коллиженшейпы являются редакторными хелперами, Ими можно и нужно пользоваться в рантайме. При входе в дерево, хелпер обращается к физическому движку, чтобы тот создал коллайдер, с параметрами, аналогичными своему. При изменении трансформа хелпера в рантайме, он отправляет физическому движку запросы, чтобы тот трансформировал ассоциированный коллайдер. Удобно же, чо. Если коллиженшейпами управляет анимационный плеер, то там вообще какая-то оптимизационная магия срабатывает и шейпы двигаются шустрее, чем их из кода двигать.
В общем всем нытикам рекомендую юзать поменьше кода в тех местах, где можно организовать анимации через анимплеер.
Вдобавок, от себя хочу заметить, что несмотря на то, что коллиженшейпы являются редакторными хелперами, Ими можно и нужно пользоваться в рантайме. При входе в дерево, хелпер обращается к физическому движку, чтобы тот создал коллайдер, с параметрами, аналогичными своему. При изменении трансформа хелпера в рантайме, он отправляет физическому движку запросы, чтобы тот трансформировал ассоциированный коллайдер. Удобно же, чо. Если коллиженшейпами управляет анимационный плеер, то там вообще какая-то оптимизационная магия срабатывает и шейпы двигаются шустрее, чем их из кода двигать.
В общем всем нытикам рекомендую юзать поменьше кода в тех местах, где можно организовать анимации через анимплеер.
>>25589
Но вообще говоря, пользоваться нужно не шейпами внутри одного тела, а конструировать несколько тел на джойнтах. Тогда у физического движка вообще никаких вопросов к вам не будет.
Но вообще говоря, пользоваться нужно не шейпами внутри одного тела, а конструировать несколько тел на джойнтах. Тогда у физического движка вообще никаких вопросов к вам не будет.
35 Кб, 210x182>>25583 (Del)
Тут ты ничего не показал, это частный случай, повезло. А представь что проблему, которую решает деферред, сами разработчики несколько месяцев искали, и в коде движка нет никакого списочка очка? Вообще так оно и есть, настоящая то проблема сложнее. Ты не нашел причину, по которой в 3.2 добавили это ограничение. У меня есть небольшой травмирующий опыт чтения таких исходников, и я пессимист а у тебя кажется данинг-крюгер, сорян конечно но это так.
>>25577
Нет, это просто в стрит файтере нет всяких мечей на пол экрана или хлыстов.
>>25589
То что ты говоришь прямо противоречит документации, или просто отсутствует в ней. Ты защищаешь документацию, а потом сам приводишь пример инфы, которую (если это правда) я должен откапывать хз где. Это противоречит нормальной работе, когда человек может почитать доки, может быть немного (не в целях установить незадокументированное поведение) поэкспериментировать и принять решение.
>>25609
Каких еще тел, это area2d а не тела. Ты с дуба рухнул вообще? Тела не сигналят колижены и у них неотключаемый физический колижен. Ну окей, тела юзаются как контейнер для ареа2д, но это какой-то странный костыль.
Тут ты ничего не показал, это частный случай, повезло. А представь что проблему, которую решает деферред, сами разработчики несколько месяцев искали, и в коде движка нет никакого списочка очка? Вообще так оно и есть, настоящая то проблема сложнее. Ты не нашел причину, по которой в 3.2 добавили это ограничение. У меня есть небольшой травмирующий опыт чтения таких исходников, и я пессимист а у тебя кажется данинг-крюгер, сорян конечно но это так.
>>25577
Нет, это просто в стрит файтере нет всяких мечей на пол экрана или хлыстов.
>>25589
То что ты говоришь прямо противоречит документации, или просто отсутствует в ней. Ты защищаешь документацию, а потом сам приводишь пример инфы, которую (если это правда) я должен откапывать хз где. Это противоречит нормальной работе, когда человек может почитать доки, может быть немного (не в целях установить незадокументированное поведение) поэкспериментировать и принять решение.
>>25609
Каких еще тел, это area2d а не тела. Ты с дуба рухнул вообще? Тела не сигналят колижены и у них неотключаемый физический колижен. Ну окей, тела юзаются как контейнер для ареа2д, но это какой-то странный костыль.
>>25635
Окей, не несколько месяцев, тут достаточно логично - вещи, которые изменяют физическую среду, могут вызывать ошибки, если их менять внутри тика. Исчезающие или появляющиеся коллайдеры например. Я больше удивлен что в списке, если ты нашел его весь, так мало.
Но показать в коде, доказать возникновение этих проблем слабо? Представь что списочка не было бы, как и этой проверки. Или была бы катч где-то по факту этих проблем, в 15 тысячах строк от места, куда ссылается дебаггер? Думаешь нереально? Вполне норм ситуация в таком сложном коде. Раз на раз не приходится короче.
Окей, не несколько месяцев, тут достаточно логично - вещи, которые изменяют физическую среду, могут вызывать ошибки, если их менять внутри тика. Исчезающие или появляющиеся коллайдеры например. Я больше удивлен что в списке, если ты нашел его весь, так мало.
Но показать в коде, доказать возникновение этих проблем слабо? Представь что списочка не было бы, как и этой проверки. Или была бы катч где-то по факту этих проблем, в 15 тысячах строк от места, куда ссылается дебаггер? Думаешь нереально? Вполне норм ситуация в таком сложном коде. Раз на раз не приходится короче.
>>25635
Не вижу ничего странного в том, чтобы юзать физические тела и/или физические области целиком и по прямому назначению, а не пытаться организовать внутри них велосипеды из их компонентов.
В чём я неправ?
> это какой-то странный костыль
Не вижу ничего странного в том, чтобы юзать физические тела и/или физические области целиком и по прямому назначению, а не пытаться организовать внутри них велосипеды из их компонентов.
В чём я неправ?
Анончики, помогите! Почему KinematicBody укладывает на землю при использовании функции look_at? По задумке он смотрит вперед по ходу движения, пути которого дает NavMesh. При старте он ложится, но выравниется и начинает нормально перемещаться когда я его "пинаю" своей коллизией.
>>25648
Ты бредишь. Джойнты работают только на ригид и статик боди. С кинематикбоди и ареа они не должны работать. Не говоря уже о том что гирлянды из тел или ареа2д вместо управления их формой - хуйня, а не наоборот.
Ты бредишь. Джойнты работают только на ригид и статик боди. С кинематикбоди и ареа они не должны работать. Не говоря уже о том что гирлянды из тел или ареа2д вместо управления их формой - хуйня, а не наоборот.
>>25662 (Del)
Функция движения вызывается, когда path не пустой. Без look_at кинематик спокойно перемещается.
Функция движения вызывается, когда path не пустой. Без look_at кинематик спокойно перемещается.
>>25653
Возможно. Я ж не такой спец, как ты. Ну ладно, давай начнём сначала. Какие конкретно проблемы ты испытываешь?
> Ты бредишь.
Возможно. Я ж не такой спец, как ты. Ну ладно, давай начнём сначала. Какие конкретно проблемы ты испытываешь?
>>25651
Похоже на пресловутый gimbal lock. Но не знаю.
> Почему KinematicBody укладывает на землю при использовании функции look_at?
Похоже на пресловутый gimbal lock. Но не знаю.
>>25667
Я испытываю отсутствие исчерпывающей документации, которая позволит мне знать вообще все что нужно о движке, не знать то чего не нужно, и планировать архитектуру без маня экспериментов.
Поэтому я сказал что сейчас использовать годот опасно, можно подвести себя или других. Правда это верно про любой движок, но там есть (платный/для платных версий) саппорт.
Я испытываю отсутствие исчерпывающей документации, которая позволит мне знать вообще все что нужно о движке, не знать то чего не нужно, и планировать архитектуру без маня экспериментов.
Поэтому я сказал что сейчас использовать годот опасно, можно подвести себя или других. Правда это верно про любой движок, но там есть (платный/для платных версий) саппорт.
>>25668
>>25670 (Del)
>>25671 (Del)
НавМеш выстраивает путь до конечной точки и высирает array с точками, по которым KinematicBody должен двигаться. В начале движения он смотрит на первую точку, которая по факту является координатой нынешнего положения кинематика, следовательно он смотрит прямо на нее, т.е. себе в ноги, как я понял. Только я не понимаю как можно этого избежать, там же указывается вторым аргументом в look_at Vector3.UP, который указывает ось вращения кинематика, не давая ему наклоняться. Но почему его при этом пидорасит?
>>25670 (Del)
>>25671 (Del)
НавМеш выстраивает путь до конечной точки и высирает array с точками, по которым KinematicBody должен двигаться. В начале движения он смотрит на первую точку, которая по факту является координатой нынешнего положения кинематика, следовательно он смотрит прямо на нее, т.е. себе в ноги, как я понял. Только я не понимаю как можно этого избежать, там же указывается вторым аргументом в look_at Vector3.UP, который указывает ось вращения кинематика, не давая ему наклоняться. Но почему его при этом пидорасит?
>>25672
Вот здесь я вынужден согласиться. Но таков твой выбор, ты используешь опенсурсный движок под лицензией MIT, разрабатываемый двумя мексиканцами. Не нравится такая свобода? Используй Юнити.
>Я испытываю отсутствие исчерпывающей документации
Вот здесь я вынужден согласиться. Но таков твой выбор, ты используешь опенсурсный движок под лицензией MIT, разрабатываемый двумя мексиканцами. Не нравится такая свобода? Используй Юнити.
>>25679 (Del)
Я и не собирался использовать события бтв, с чего ты взял? В любом случае, я отвлекся, это да. Сделать то как то можно.
В остальном да, я начал передергивать. Но все равно, сложно было описать систему шейп овнеров? И почему бы их не отключать, никакой проблемы я с этим не вижу.
Ну не совсем, для игры типа файтингов вертикальный срез это вся основная механика по сути.
Испытывал на себе, не в игровом движке, но я аутист который может разозлить целый дискорд разрабов из за ерунды. Да.
Но суть в том, что тут просто требуется побольше написать в свободном стиле, даже, без формальностей, о каких-то системах, и это 5 минут работы для человека который в курсе как они устроены. Документация не просто незаконченная, она написана намеками.
Я и не собирался использовать события бтв, с чего ты взял? В любом случае, я отвлекся, это да. Сделать то как то можно.
В остальном да, я начал передергивать. Но все равно, сложно было описать систему шейп овнеров? И почему бы их не отключать, никакой проблемы я с этим не вижу.
>Это вертикальный срез.
Ну не совсем, для игры типа файтингов вертикальный срез это вся основная механика по сути.
>wont fix
Испытывал на себе, не в игровом движке, но я аутист который может разозлить целый дискорд разрабов из за ерунды. Да.
Но суть в том, что тут просто требуется побольше написать в свободном стиле, даже, без формальностей, о каких-то системах, и это 5 минут работы для человека который в курсе как они устроены. Документация не просто незаконченная, она написана намеками.
>>25687 (Del)
Откуда я это должен был знать? Интуитивно что она может проявляться и в других физикс процессах. А может и нет, это инфа о том как устроен движок. Если один из физикс апдейтов решает убрать глобальный физический объект, то часть апдейтов фрейма с ними провзаимодействуют а чатсь нет, и невозможно предсказать какая именно. Это проблема. Это все что можно предположить с дивана, остальное опять таки то, чего я в идеале знать не должен.
Откуда я это должен был знать? Интуитивно что она может проявляться и в других физикс процессах. А может и нет, это инфа о том как устроен движок. Если один из физикс апдейтов решает убрать глобальный физический объект, то часть апдейтов фрейма с ними провзаимодействуют а чатсь нет, и невозможно предсказать какая именно. Это проблема. Это все что можно предположить с дивана, остальное опять таки то, чего я в идеале знать не должен.
>>25700 (Del)
Это именно то что я думал про апдейты, включая _physycs_process.
Теперь я все понял, окей, но опять же документация мозаична, и написана намеками.
>Интуитивно колбеки могут вызываться в другом потоке или контексте.
Это именно то что я думал про апдейты, включая _physycs_process.
Теперь я все понял, окей, но опять же документация мозаична, и написана намеками.
1001 Кб, 1280x720>>25635
А какая разница? Этот меч или хлыст тебе сделают тем же квадратом.
>Нет, это просто в стрит файтере нет всяких мечей на пол экрана или хлыстов.
А какая разница? Этот меч или хлыст тебе сделают тем же квадратом.
А в каком порядке вообще тогда происходят физические тикии что в них входит?
Сказано, что get_overlapping_
Движение может происходить до физики? И коллбек обязательно придет до? Вообще нет, он не обязан, или эт будет зависеть от производительности, или что? Временная - последовательная модель основного лупа где? Что за чем, когда?
Когда происходит рендер? Что на текущем кадре в момент физик тика? Для чего вообще эта рекомендация использовать сигналы, для чего кому-то вообще immediately? Для высоких фпс? При 60 фпс это неважно, или это гарантированная разница в 1 физический тик?
Я именно что хотел разобраться как делать полностью покадровую игру, избегать эвентов, коллайдерами вручную управлять :(
>>25716
Ну и что, все равно редактор где ты можешь мышкой рисовать поверх анимации хитбоксы удобнее. Просто один за другим, кликаешь в один угол тянешь в другой. Выбираешь тип, кодируется цветами, прямо как на этих пикчах. Я хотел иметь такой конструктор, а потом сидеть и не напрягаться.
Сказано, что get_overlapping_
>For performance reasons (collisions are all processed at the same time) this list is modified once during the physics step, not immediately after objects are moved. Consider using signals instead.
Движение может происходить до физики? И коллбек обязательно придет до? Вообще нет, он не обязан, или эт будет зависеть от производительности, или что? Временная - последовательная модель основного лупа где? Что за чем, когда?
Когда происходит рендер? Что на текущем кадре в момент физик тика? Для чего вообще эта рекомендация использовать сигналы, для чего кому-то вообще immediately? Для высоких фпс? При 60 фпс это неважно, или это гарантированная разница в 1 физический тик?
Я именно что хотел разобраться как делать полностью покадровую игру, избегать эвентов, коллайдерами вручную управлять :(
>>25716
Ну и что, все равно редактор где ты можешь мышкой рисовать поверх анимации хитбоксы удобнее. Просто один за другим, кликаешь в один угол тянешь в другой. Выбираешь тип, кодируется цветами, прямо как на этих пикчах. Я хотел иметь такой конструктор, а потом сидеть и не напрягаться.
>>25725
Быдло - решение, которое мне видится, это юзать эвенты и запилить массив вошедших объектов, там же есть сигналы на входе и выходе. Вошел добавился, вышел удалился. Но я чувствую, что это неправильно.
Быдло - решение, которое мне видится, это юзать эвенты и запилить массив вошедших объектов, там же есть сигналы на входе и выходе. Вошел добавился, вышел удалился. Но я чувствую, что это неправильно.
>>25746 (Del)
Пройти несколько зон в кадр? Получается движение физических объектов недискретно? Я думал что физический объект прост телепортируется небольшими шагами, и это выглядит как движение но на самом деле это покадровая цепочка телепортаций. Ну, как это обычно делается. И если он пролетит сквозь area2d, он литерали пролетит, не вызывая никаких срабатываний.
Но если он как бы рейкастит в точку своего следующего появления, и собирает на каждом шагу все через что он пролетает, то это совершенно другое дело и я об этом не думал. Это крутая фича если так.
Пройти несколько зон в кадр? Получается движение физических объектов недискретно? Я думал что физический объект прост телепортируется небольшими шагами, и это выглядит как движение но на самом деле это покадровая цепочка телепортаций. Ну, как это обычно делается. И если он пролетит сквозь area2d, он литерали пролетит, не вызывая никаких срабатываний.
Но если он как бы рейкастит в точку своего следующего появления, и собирает на каждом шагу все через что он пролетает, то это совершенно другое дело и я об этом не думал. Это крутая фича если так.
>>25398
Ты открыл для себя разработку сверху-вниз.
https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design#Programming
>Принцип обратного кодинга.
>Наверняка я велосипед изобрёл.
Ты открыл для себя разработку сверху-вниз.
https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design#Programming
>>25672
>>25679 (Del)
https://godotengine.org/contact
1. Большинство вопросов можно и нужно решать через коммьюнити, потому что у разработчиков нет времени на нубские вопросы тех, кому лень прочитать две строчки в документации.
2. Тем не менее, разработчики будут рады помочь тебе, если ты не можешь получить ответ обычным способом. Подразумевается, что это как-то связано с проблемами движка, и помощь тебе может помочь другим пользователям движка.
3. Официальной структуры коммерческой техподдержки пока нет, но, тем не менее, можно обратиться за предоставлением техподдержки на индивидуальной основе. Сравни с покупкой в крупном магазине самообслуживания и покупкой с рук у соседа.
4. Многие разработчики движка могут работать над твоими проблемами с почасовой оплатой или перейти в состав твоей компании (в смысле, на зарплату). Лично меня это напрягает, т.к. каждый такой перешедший = замедление разработки движка для всех, надеюсь, они стараются так не делать. Особенно жаль, что лицензия Godot не GPL - поработал над движком для чужой компании и не можешь ни с кем поделиться((
5. Они попытаются найти подходящего человека из команды под конкретные запросы, т.к. разные люди работают над разными частями движка, например, кто-то работает в основном над графикой, кто-то - над физикой и так далее. Если почитать обсуждения на гитхабе, можно заметить это разделение. Соответственно, работавший над конкретной частью движка будет более компетентен в её устройстве и быстрее сможет помочь.
Остаётся нерешённым вопрос, есть ли у тебя деньги?
>Правда это верно про любой движок, но там есть (платный/для платных версий) саппорт.
>>25679 (Del)
>В принципе думаю что если у тебя будет реальная игра с проблемами, и ты свяжешься с командой, у тебя тоже будет саппорт, платный или бесплатный.
https://godotengine.org/contact
>Support
>If you have a problem learning Godot or need help, please first use the various community channels. Godot developers are busy working in making Godot better, so they can't always answer questions. They will, however, be glad to assist you if you can't get an answer from conventional means.
>Commercial support
>While we don't have a formal structure for offering commercial support, many Godot developers can already help you, work per hour, or relocate to your company. For such inquiries, contact
s7Fsupport ANUSgodotef`Jngine PUNCTUMoW7Vrg . Let us know about your needs and we'll try to find the right person for you.
1. Большинство вопросов можно и нужно решать через коммьюнити, потому что у разработчиков нет времени на нубские вопросы тех, кому лень прочитать две строчки в документации.
2. Тем не менее, разработчики будут рады помочь тебе, если ты не можешь получить ответ обычным способом. Подразумевается, что это как-то связано с проблемами движка, и помощь тебе может помочь другим пользователям движка.
3. Официальной структуры коммерческой техподдержки пока нет, но, тем не менее, можно обратиться за предоставлением техподдержки на индивидуальной основе. Сравни с покупкой в крупном магазине самообслуживания и покупкой с рук у соседа.
4. Многие разработчики движка могут работать над твоими проблемами с почасовой оплатой или перейти в состав твоей компании (в смысле, на зарплату). Лично меня это напрягает, т.к. каждый такой перешедший = замедление разработки движка для всех, надеюсь, они стараются так не делать. Особенно жаль, что лицензия Godot не GPL - поработал над движком для чужой компании и не можешь ни с кем поделиться((
5. Они попытаются найти подходящего человека из команды под конкретные запросы, т.к. разные люди работают над разными частями движка, например, кто-то работает в основном над графикой, кто-то - над физикой и так далее. Если почитать обсуждения на гитхабе, можно заметить это разделение. Соответственно, работавший над конкретной частью движка будет более компетентен в её устройстве и быстрее сможет помочь.
Остаётся нерешённым вопрос, есть ли у тебя деньги?
>>25672
>>25679 (Del)
https://godotengine.org/contact
1. Большинство вопросов можно и нужно решать через коммьюнити, потому что у разработчиков нет времени на нубские вопросы тех, кому лень прочитать две строчки в документации.
2. Тем не менее, разработчики будут рады помочь тебе, если ты не можешь получить ответ обычным способом. Подразумевается, что это как-то связано с проблемами движка, и помощь тебе может помочь другим пользователям движка.
3. Официальной структуры коммерческой техподдержки пока нет, но, тем не менее, можно обратиться за предоставлением техподдержки на индивидуальной основе. Сравни с покупкой в крупном магазине самообслуживания и покупкой с рук у соседа.
4. Многие разработчики движка могут работать над твоими проблемами с почасовой оплатой или перейти в состав твоей компании (в смысле, на зарплату). Лично меня это напрягает, т.к. каждый такой перешедший = замедление разработки движка для всех, надеюсь, они стараются так не делать. Особенно жаль, что лицензия Godot не GPL - поработал над движком для чужой компании и не можешь ни с кем поделиться((
5. Они попытаются найти подходящего человека из команды под конкретные запросы, т.к. разные люди работают над разными частями движка, например, кто-то работает в основном над графикой, кто-то - над физикой и так далее. Если почитать обсуждения на гитхабе, можно заметить это разделение. Соответственно, работавший над конкретной частью движка будет более компетентен в её устройстве и быстрее сможет помочь.
Остаётся нерешённым вопрос, есть ли у тебя деньги?
>Правда это верно про любой движок, но там есть (платный/для платных версий) саппорт.
>>25679 (Del)
>В принципе думаю что если у тебя будет реальная игра с проблемами, и ты свяжешься с командой, у тебя тоже будет саппорт, платный или бесплатный.
https://godotengine.org/contact
>Support
>If you have a problem learning Godot or need help, please first use the various community channels. Godot developers are busy working in making Godot better, so they can't always answer questions. They will, however, be glad to assist you if you can't get an answer from conventional means.
>Commercial support
>While we don't have a formal structure for offering commercial support, many Godot developers can already help you, work per hour, or relocate to your company. For such inquiries, contact
s7Fsupport ANUSgodotef`Jngine PUNCTUMoW7Vrg . Let us know about your needs and we'll try to find the right person for you.
1. Большинство вопросов можно и нужно решать через коммьюнити, потому что у разработчиков нет времени на нубские вопросы тех, кому лень прочитать две строчки в документации.
2. Тем не менее, разработчики будут рады помочь тебе, если ты не можешь получить ответ обычным способом. Подразумевается, что это как-то связано с проблемами движка, и помощь тебе может помочь другим пользователям движка.
3. Официальной структуры коммерческой техподдержки пока нет, но, тем не менее, можно обратиться за предоставлением техподдержки на индивидуальной основе. Сравни с покупкой в крупном магазине самообслуживания и покупкой с рук у соседа.
4. Многие разработчики движка могут работать над твоими проблемами с почасовой оплатой или перейти в состав твоей компании (в смысле, на зарплату). Лично меня это напрягает, т.к. каждый такой перешедший = замедление разработки движка для всех, надеюсь, они стараются так не делать. Особенно жаль, что лицензия Godot не GPL - поработал над движком для чужой компании и не можешь ни с кем поделиться((
5. Они попытаются найти подходящего человека из команды под конкретные запросы, т.к. разные люди работают над разными частями движка, например, кто-то работает в основном над графикой, кто-то - над физикой и так далее. Если почитать обсуждения на гитхабе, можно заметить это разделение. Соответственно, работавший над конкретной частью движка будет более компетентен в её устройстве и быстрее сможет помочь.
Остаётся нерешённым вопрос, есть ли у тебя деньги?
>>25725
Да, разумеется. Ты можешь двигать (менять позицию) объекты в любой момент любое количество раз до физического тика, т.е. до того момента, когда физический движок сделает шаг своей симуляции. Рекомендуется, однако, двигать физические объекты только в _physics_process, поскольку из-за многопоточности некоторая информация может быть заблокирована, т.е. в теории ты можешь попасть в момент, когда физический движок делает симуляцию, если твой код сдвига находится вне _physics_process. Также нужно знать, что обновление transform.origin происходит реже физических тиков (т.е. там обычно неактуальная позиция) и запись в это поле может сбивать с толку тебя и/или физический движок. Выяснил это экспериментальным путём...
Описание в документации:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html
https://docs.godotengine.org/en/latest/classes/class_scenetree.html
Код реализации (мастер ветка = альфа/бета 4.0+):
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.h
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.cpp
Кратко: этот подход стимулирует писать более гибкий код. Сигналы можно подключать и отключать в разные места, они могут не иметь обработчика или иметь несколько и т.д.
Но главное, сигнал гарантированно говорит о каком-то событии, которое только что или недавно произошло. По умолчанию "только что", т.е. emit_signal() напрямую вызывает обработчики, но можно включить очередь, чтобы обработчики вызывались по мере возможности. Другими словами, вместо кучи if else if else твой код будет работать с конкретными событиями: персонаж кого-то ударил, персонажа кто-то ударил и так далее. Не придётся гадать, куда пихнуть ещё один if else и что делают уже имеющиеся. Особенно это выгодно играм с большим количеством сущностей, число которых динамически меняется.
По сути, сигнал в Годо - это event, по-русски "событие":
https://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
Для чего угодно. Представь, что ты решил сделать какую-то проверку сразу после сдвига объекта. Ты пишешь что-то вроде:
Этот код не сработает так, как ты ожидаешь, потому что коллизии обрабатываются в строго определённый момент, а не тогда, когда объект сместился в новую позицию. Его следует разбить на несколько физических тиков, либо заменить кастом лучей/шейпов с помощью вот этого объекта (см. туториал "Ray-casting"):
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate.html
Достаточно увеличить частоту тиков физического движка. По умолчанию 60, может быть любым значением, но на слабых машинах, конечно, слишком высокой скорости не добиться.
Зачем? Так ты только захардкодишь то, что можно было не хардкодить. Ты сам приводил пример из Skullgirls - там много персонажей и много анимаций, делать взаимодействия каждого персонажа с каждым другим покадрово с ума сойдёшь, нужна автоматизация. Я когда-то играл в эту игру, и мне кажется, что там многие анимации просто устроены - универсально, т.е. чтобы можно было добавлять новых персонажей без экспоненциального роста сложности добавления следующих. Всё-таки денежная корова, которую будут доить ещё долгое время, тут без гибкого подхода никак не обойтись - игрокам нужны обновления контента.
Это можно делать через AnimationPlayer и AnimationTree. Тебе в любом случае не нужны новые хитбоксы каждый кадр, это было бы ужасно неэффективно из-за постоянного заполнения и очистки кучи в памяти; тебе необходимо и достаточно менять размеры и позиции уже существующих хитбоксов. Какие-то можно временно скрывать, какие-то временно отображать. Всё зависит от твоей фантазии.
Ты можешь написать tool скрипт для своих CollisionShape2D, который в методе _draw() будет рисовать свой шейп заданным тобой цветом, пока выполняется в редакторе. У шейпа даже есть метод, в котором можно указать цвет отрисовки:
https://docs.godotengine.org/en/stable/classes/class_shape2d.html#class-shape2d-method-draw
Для этого не нужен никакой отдельный редактор, и это будет сочетаться с работой в AnimationPlayer. Правда, сам я так не пробовал, не знаю, будут ли подводные камни.
>>25752
Да, по умолчанию (см. ниже) именно так и происходит. Слишком быстрый объект может пролететь сквозь слишком тонкий объект. Слишком низкая частота физических тиков будет выглядеть прерывисто в комбинации с высокой частотой кадров. Последнее можно сгладить галочкой в настройках проекта, но, по-моему, это не повлияет на пролетание сквозь объекты (т.к. интерполяция визуальная).
Этот режим можно принудительно включить:
https://docs.godotengine.org/en/stable/classes/class_rigidbody2d.html#class-rigidbody2d-property-continuous-cd
Включать его следует только если у тебя реально наблюдаются пролёты сквозь объекты. Особенно если у тебя на сцене много тонких препятствий, а движущийся объект достаточно маленький и/или очень быстрый. Скажем, если ты делаешь симулятор реактивного самолёта, то тебе нужно включить для самолёта режим кастинга шейпа. Или если ты делаешь реалистичные пули, для них можно включить режим рейкастинга. В остальных случаях этот режим не принесёт пользы, но потратит время процессора.
Стоп, это всё не работает, уже 5 лет не могут починить:
https://github.com/godotengine/godot/issues/9071
Ну штош, всегда можно сделать рейкаст из кода (см. выше)...
А для 2D файтинга достаточно сделать скорость физического движка в несколько раз выше стандартной. Раз 200 в секунду должно хватить, я так думаю, как считаешь? Вместо скачков по 1/60 сдвига за секунду будут скачки по 1/200 сдвига за секунду. Это должно решить проблемы пролёта сквозь маленькие Area2D. А учитывая, что на экране всего два персонажа, проблем с производительностью скорее всего не будет. Анимации в AnimationPlayer тоже возможно синхронизировать с тиками физики (по умолчанию стоит другой режим):
А если не секрет и если не трудно, расскажи, как ты планировал делать файтинг "покадрово"? Может быть, тебе достаточно будет отказаться от RigidBody2D? В смысле, персонажам в файтингах ведь не нужна настоящая физика. Area2D сами по себе никогда не двигаются, тебе в любом случае придётся двигать их вручную кодом или через анимации. Анимации, кстати, можно проигрывать покадрово из кода, для этого есть отдельный режим...
>Движение может происходить до физики?
Да, разумеется. Ты можешь двигать (менять позицию) объекты в любой момент любое количество раз до физического тика, т.е. до того момента, когда физический движок сделает шаг своей симуляции. Рекомендуется, однако, двигать физические объекты только в _physics_process, поскольку из-за многопоточности некоторая информация может быть заблокирована, т.е. в теории ты можешь попасть в момент, когда физический движок делает симуляцию, если твой код сдвига находится вне _physics_process. Также нужно знать, что обновление transform.origin происходит реже физических тиков (т.е. там обычно неактуальная позиция) и запись в это поле может сбивать с толку тебя и/или физический движок. Выяснил это экспериментальным путём...
>последовательная модель основного лупа где?
Описание в документации:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html
https://docs.godotengine.org/en/latest/classes/class_scenetree.html
Код реализации (мастер ветка = альфа/бета 4.0+):
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.h
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.cpp
>Для чего вообще эта рекомендация использовать сигналы
Кратко: этот подход стимулирует писать более гибкий код. Сигналы можно подключать и отключать в разные места, они могут не иметь обработчика или иметь несколько и т.д.
Но главное, сигнал гарантированно говорит о каком-то событии, которое только что или недавно произошло. По умолчанию "только что", т.е. emit_signal() напрямую вызывает обработчики, но можно включить очередь, чтобы обработчики вызывались по мере возможности. Другими словами, вместо кучи if else if else твой код будет работать с конкретными событиями: персонаж кого-то ударил, персонажа кто-то ударил и так далее. Не придётся гадать, куда пихнуть ещё один if else и что делают уже имеющиеся. Особенно это выгодно играм с большим количеством сущностей, число которых динамически меняется.
По сути, сигнал в Годо - это event, по-русски "событие":
https://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
>для чего кому-то вообще immediately?
Для чего угодно. Представь, что ты решил сделать какую-то проверку сразу после сдвига объекта. Ты пишешь что-то вроде:
>translate(vector)
>if is_collided(): ...
>translate(vector)
>if is_collided(): ...
Этот код не сработает так, как ты ожидаешь, потому что коллизии обрабатываются в строго определённый момент, а не тогда, когда объект сместился в новую позицию. Его следует разбить на несколько физических тиков, либо заменить кастом лучей/шейпов с помощью вот этого объекта (см. туториал "Ray-casting"):
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate.html
>Для высоких фпс?
Достаточно увеличить частоту тиков физического движка. По умолчанию 60, может быть любым значением, но на слабых машинах, конечно, слишком высокой скорости не добиться.
>Я именно что хотел разобраться как делать полностью покадровую игру, избегать эвентов, коллайдерами вручную управлять :(
Зачем? Так ты только захардкодишь то, что можно было не хардкодить. Ты сам приводил пример из Skullgirls - там много персонажей и много анимаций, делать взаимодействия каждого персонажа с каждым другим покадрово с ума сойдёшь, нужна автоматизация. Я когда-то играл в эту игру, и мне кажется, что там многие анимации просто устроены - универсально, т.е. чтобы можно было добавлять новых персонажей без экспоненциального роста сложности добавления следующих. Всё-таки денежная корова, которую будут доить ещё долгое время, тут без гибкого подхода никак не обойтись - игрокам нужны обновления контента.
>редактор где ты можешь мышкой рисовать поверх анимации хитбоксы
Это можно делать через AnimationPlayer и AnimationTree. Тебе в любом случае не нужны новые хитбоксы каждый кадр, это было бы ужасно неэффективно из-за постоянного заполнения и очистки кучи в памяти; тебе необходимо и достаточно менять размеры и позиции уже существующих хитбоксов. Какие-то можно временно скрывать, какие-то временно отображать. Всё зависит от твоей фантазии.
>Выбираешь тип, кодируется цветами
Ты можешь написать tool скрипт для своих CollisionShape2D, который в методе _draw() будет рисовать свой шейп заданным тобой цветом, пока выполняется в редакторе. У шейпа даже есть метод, в котором можно указать цвет отрисовки:
https://docs.godotengine.org/en/stable/classes/class_shape2d.html#class-shape2d-method-draw
Для этого не нужен никакой отдельный редактор, и это будет сочетаться с работой в AnimationPlayer. Правда, сам я так не пробовал, не знаю, будут ли подводные камни.
>>25752
>Я думал что физический объект прост телепортируется небольшими шагами, и это выглядит как движение но на самом деле это покадровая цепочка телепортаций.
Да, по умолчанию (см. ниже) именно так и происходит. Слишком быстрый объект может пролететь сквозь слишком тонкий объект. Слишком низкая частота физических тиков будет выглядеть прерывисто в комбинации с высокой частотой кадров. Последнее можно сгладить галочкой в настройках проекта, но, по-моему, это не повлияет на пролетание сквозь объекты (т.к. интерполяция визуальная).
>Но если он как бы рейкастит в точку своего следующего появления, и собирает на каждом шагу все через что он пролетает, то это совершенно другое дело и я об этом не думал. Это крутая фича если так.
Этот режим можно принудительно включить:
https://docs.godotengine.org/en/stable/classes/class_rigidbody2d.html#class-rigidbody2d-property-continuous-cd
Включать его следует только если у тебя реально наблюдаются пролёты сквозь объекты. Особенно если у тебя на сцене много тонких препятствий, а движущийся объект достаточно маленький и/или очень быстрый. Скажем, если ты делаешь симулятор реактивного самолёта, то тебе нужно включить для самолёта режим кастинга шейпа. Или если ты делаешь реалистичные пули, для них можно включить режим рейкастинга. В остальных случаях этот режим не принесёт пользы, но потратит время процессора.
Стоп, это всё не работает, уже 5 лет не могут починить:
https://github.com/godotengine/godot/issues/9071
Ну штош, всегда можно сделать рейкаст из кода (см. выше)...
А для 2D файтинга достаточно сделать скорость физического движка в несколько раз выше стандартной. Раз 200 в секунду должно хватить, я так думаю, как считаешь? Вместо скачков по 1/60 сдвига за секунду будут скачки по 1/200 сдвига за секунду. Это должно решить проблемы пролёта сквозь маленькие Area2D. А учитывая, что на экране всего два персонажа, проблем с производительностью скорее всего не будет. Анимации в AnimationPlayer тоже возможно синхронизировать с тиками физики (по умолчанию стоит другой режим):
>ANIMATION_PROCESS_PHYSICS = 0 --- Process animation during the physics process. This is especially useful when animating physics bodies.
А если не секрет и если не трудно, расскажи, как ты планировал делать файтинг "покадрово"? Может быть, тебе достаточно будет отказаться от RigidBody2D? В смысле, персонажам в файтингах ведь не нужна настоящая физика. Area2D сами по себе никогда не двигаются, тебе в любом случае придётся двигать их вручную кодом или через анимации. Анимации, кстати, можно проигрывать покадрово из кода, для этого есть отдельный режим...
>>25725
Да, разумеется. Ты можешь двигать (менять позицию) объекты в любой момент любое количество раз до физического тика, т.е. до того момента, когда физический движок сделает шаг своей симуляции. Рекомендуется, однако, двигать физические объекты только в _physics_process, поскольку из-за многопоточности некоторая информация может быть заблокирована, т.е. в теории ты можешь попасть в момент, когда физический движок делает симуляцию, если твой код сдвига находится вне _physics_process. Также нужно знать, что обновление transform.origin происходит реже физических тиков (т.е. там обычно неактуальная позиция) и запись в это поле может сбивать с толку тебя и/или физический движок. Выяснил это экспериментальным путём...
Описание в документации:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html
https://docs.godotengine.org/en/latest/classes/class_scenetree.html
Код реализации (мастер ветка = альфа/бета 4.0+):
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.h
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.cpp
Кратко: этот подход стимулирует писать более гибкий код. Сигналы можно подключать и отключать в разные места, они могут не иметь обработчика или иметь несколько и т.д.
Но главное, сигнал гарантированно говорит о каком-то событии, которое только что или недавно произошло. По умолчанию "только что", т.е. emit_signal() напрямую вызывает обработчики, но можно включить очередь, чтобы обработчики вызывались по мере возможности. Другими словами, вместо кучи if else if else твой код будет работать с конкретными событиями: персонаж кого-то ударил, персонажа кто-то ударил и так далее. Не придётся гадать, куда пихнуть ещё один if else и что делают уже имеющиеся. Особенно это выгодно играм с большим количеством сущностей, число которых динамически меняется.
По сути, сигнал в Годо - это event, по-русски "событие":
https://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
Для чего угодно. Представь, что ты решил сделать какую-то проверку сразу после сдвига объекта. Ты пишешь что-то вроде:
Этот код не сработает так, как ты ожидаешь, потому что коллизии обрабатываются в строго определённый момент, а не тогда, когда объект сместился в новую позицию. Его следует разбить на несколько физических тиков, либо заменить кастом лучей/шейпов с помощью вот этого объекта (см. туториал "Ray-casting"):
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate.html
Достаточно увеличить частоту тиков физического движка. По умолчанию 60, может быть любым значением, но на слабых машинах, конечно, слишком высокой скорости не добиться.
Зачем? Так ты только захардкодишь то, что можно было не хардкодить. Ты сам приводил пример из Skullgirls - там много персонажей и много анимаций, делать взаимодействия каждого персонажа с каждым другим покадрово с ума сойдёшь, нужна автоматизация. Я когда-то играл в эту игру, и мне кажется, что там многие анимации просто устроены - универсально, т.е. чтобы можно было добавлять новых персонажей без экспоненциального роста сложности добавления следующих. Всё-таки денежная корова, которую будут доить ещё долгое время, тут без гибкого подхода никак не обойтись - игрокам нужны обновления контента.
Это можно делать через AnimationPlayer и AnimationTree. Тебе в любом случае не нужны новые хитбоксы каждый кадр, это было бы ужасно неэффективно из-за постоянного заполнения и очистки кучи в памяти; тебе необходимо и достаточно менять размеры и позиции уже существующих хитбоксов. Какие-то можно временно скрывать, какие-то временно отображать. Всё зависит от твоей фантазии.
Ты можешь написать tool скрипт для своих CollisionShape2D, который в методе _draw() будет рисовать свой шейп заданным тобой цветом, пока выполняется в редакторе. У шейпа даже есть метод, в котором можно указать цвет отрисовки:
https://docs.godotengine.org/en/stable/classes/class_shape2d.html#class-shape2d-method-draw
Для этого не нужен никакой отдельный редактор, и это будет сочетаться с работой в AnimationPlayer. Правда, сам я так не пробовал, не знаю, будут ли подводные камни.
>>25752
Да, по умолчанию (см. ниже) именно так и происходит. Слишком быстрый объект может пролететь сквозь слишком тонкий объект. Слишком низкая частота физических тиков будет выглядеть прерывисто в комбинации с высокой частотой кадров. Последнее можно сгладить галочкой в настройках проекта, но, по-моему, это не повлияет на пролетание сквозь объекты (т.к. интерполяция визуальная).
Этот режим можно принудительно включить:
https://docs.godotengine.org/en/stable/classes/class_rigidbody2d.html#class-rigidbody2d-property-continuous-cd
Включать его следует только если у тебя реально наблюдаются пролёты сквозь объекты. Особенно если у тебя на сцене много тонких препятствий, а движущийся объект достаточно маленький и/или очень быстрый. Скажем, если ты делаешь симулятор реактивного самолёта, то тебе нужно включить для самолёта режим кастинга шейпа. Или если ты делаешь реалистичные пули, для них можно включить режим рейкастинга. В остальных случаях этот режим не принесёт пользы, но потратит время процессора.
Стоп, это всё не работает, уже 5 лет не могут починить:
https://github.com/godotengine/godot/issues/9071
Ну штош, всегда можно сделать рейкаст из кода (см. выше)...
А для 2D файтинга достаточно сделать скорость физического движка в несколько раз выше стандартной. Раз 200 в секунду должно хватить, я так думаю, как считаешь? Вместо скачков по 1/60 сдвига за секунду будут скачки по 1/200 сдвига за секунду. Это должно решить проблемы пролёта сквозь маленькие Area2D. А учитывая, что на экране всего два персонажа, проблем с производительностью скорее всего не будет. Анимации в AnimationPlayer тоже возможно синхронизировать с тиками физики (по умолчанию стоит другой режим):
А если не секрет и если не трудно, расскажи, как ты планировал делать файтинг "покадрово"? Может быть, тебе достаточно будет отказаться от RigidBody2D? В смысле, персонажам в файтингах ведь не нужна настоящая физика. Area2D сами по себе никогда не двигаются, тебе в любом случае придётся двигать их вручную кодом или через анимации. Анимации, кстати, можно проигрывать покадрово из кода, для этого есть отдельный режим...
>Движение может происходить до физики?
Да, разумеется. Ты можешь двигать (менять позицию) объекты в любой момент любое количество раз до физического тика, т.е. до того момента, когда физический движок сделает шаг своей симуляции. Рекомендуется, однако, двигать физические объекты только в _physics_process, поскольку из-за многопоточности некоторая информация может быть заблокирована, т.е. в теории ты можешь попасть в момент, когда физический движок делает симуляцию, если твой код сдвига находится вне _physics_process. Также нужно знать, что обновление transform.origin происходит реже физических тиков (т.е. там обычно неактуальная позиция) и запись в это поле может сбивать с толку тебя и/или физический движок. Выяснил это экспериментальным путём...
>последовательная модель основного лупа где?
Описание в документации:
https://docs.godotengine.org/en/stable/classes/class_scenetree.html
https://docs.godotengine.org/en/latest/classes/class_scenetree.html
Код реализации (мастер ветка = альфа/бета 4.0+):
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.h
https://github.com/godotengine/godot/blob/master/scene/main/scene_tree.cpp
>Для чего вообще эта рекомендация использовать сигналы
Кратко: этот подход стимулирует писать более гибкий код. Сигналы можно подключать и отключать в разные места, они могут не иметь обработчика или иметь несколько и т.д.
Но главное, сигнал гарантированно говорит о каком-то событии, которое только что или недавно произошло. По умолчанию "только что", т.е. emit_signal() напрямую вызывает обработчики, но можно включить очередь, чтобы обработчики вызывались по мере возможности. Другими словами, вместо кучи if else if else твой код будет работать с конкретными событиями: персонаж кого-то ударил, персонажа кто-то ударил и так далее. Не придётся гадать, куда пихнуть ещё один if else и что делают уже имеющиеся. Особенно это выгодно играм с большим количеством сущностей, число которых динамически меняется.
По сути, сигнал в Годо - это event, по-русски "событие":
https://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
>для чего кому-то вообще immediately?
Для чего угодно. Представь, что ты решил сделать какую-то проверку сразу после сдвига объекта. Ты пишешь что-то вроде:
>translate(vector)
>if is_collided(): ...
>translate(vector)
>if is_collided(): ...
Этот код не сработает так, как ты ожидаешь, потому что коллизии обрабатываются в строго определённый момент, а не тогда, когда объект сместился в новую позицию. Его следует разбить на несколько физических тиков, либо заменить кастом лучей/шейпов с помощью вот этого объекта (см. туториал "Ray-casting"):
https://docs.godotengine.org/en/stable/classes/class_physicsdirectspacestate.html
>Для высоких фпс?
Достаточно увеличить частоту тиков физического движка. По умолчанию 60, может быть любым значением, но на слабых машинах, конечно, слишком высокой скорости не добиться.
>Я именно что хотел разобраться как делать полностью покадровую игру, избегать эвентов, коллайдерами вручную управлять :(
Зачем? Так ты только захардкодишь то, что можно было не хардкодить. Ты сам приводил пример из Skullgirls - там много персонажей и много анимаций, делать взаимодействия каждого персонажа с каждым другим покадрово с ума сойдёшь, нужна автоматизация. Я когда-то играл в эту игру, и мне кажется, что там многие анимации просто устроены - универсально, т.е. чтобы можно было добавлять новых персонажей без экспоненциального роста сложности добавления следующих. Всё-таки денежная корова, которую будут доить ещё долгое время, тут без гибкого подхода никак не обойтись - игрокам нужны обновления контента.
>редактор где ты можешь мышкой рисовать поверх анимации хитбоксы
Это можно делать через AnimationPlayer и AnimationTree. Тебе в любом случае не нужны новые хитбоксы каждый кадр, это было бы ужасно неэффективно из-за постоянного заполнения и очистки кучи в памяти; тебе необходимо и достаточно менять размеры и позиции уже существующих хитбоксов. Какие-то можно временно скрывать, какие-то временно отображать. Всё зависит от твоей фантазии.
>Выбираешь тип, кодируется цветами
Ты можешь написать tool скрипт для своих CollisionShape2D, который в методе _draw() будет рисовать свой шейп заданным тобой цветом, пока выполняется в редакторе. У шейпа даже есть метод, в котором можно указать цвет отрисовки:
https://docs.godotengine.org/en/stable/classes/class_shape2d.html#class-shape2d-method-draw
Для этого не нужен никакой отдельный редактор, и это будет сочетаться с работой в AnimationPlayer. Правда, сам я так не пробовал, не знаю, будут ли подводные камни.
>>25752
>Я думал что физический объект прост телепортируется небольшими шагами, и это выглядит как движение но на самом деле это покадровая цепочка телепортаций.
Да, по умолчанию (см. ниже) именно так и происходит. Слишком быстрый объект может пролететь сквозь слишком тонкий объект. Слишком низкая частота физических тиков будет выглядеть прерывисто в комбинации с высокой частотой кадров. Последнее можно сгладить галочкой в настройках проекта, но, по-моему, это не повлияет на пролетание сквозь объекты (т.к. интерполяция визуальная).
>Но если он как бы рейкастит в точку своего следующего появления, и собирает на каждом шагу все через что он пролетает, то это совершенно другое дело и я об этом не думал. Это крутая фича если так.
Этот режим можно принудительно включить:
https://docs.godotengine.org/en/stable/classes/class_rigidbody2d.html#class-rigidbody2d-property-continuous-cd
Включать его следует только если у тебя реально наблюдаются пролёты сквозь объекты. Особенно если у тебя на сцене много тонких препятствий, а движущийся объект достаточно маленький и/или очень быстрый. Скажем, если ты делаешь симулятор реактивного самолёта, то тебе нужно включить для самолёта режим кастинга шейпа. Или если ты делаешь реалистичные пули, для них можно включить режим рейкастинга. В остальных случаях этот режим не принесёт пользы, но потратит время процессора.
Стоп, это всё не работает, уже 5 лет не могут починить:
https://github.com/godotengine/godot/issues/9071
Ну штош, всегда можно сделать рейкаст из кода (см. выше)...
А для 2D файтинга достаточно сделать скорость физического движка в несколько раз выше стандартной. Раз 200 в секунду должно хватить, я так думаю, как считаешь? Вместо скачков по 1/60 сдвига за секунду будут скачки по 1/200 сдвига за секунду. Это должно решить проблемы пролёта сквозь маленькие Area2D. А учитывая, что на экране всего два персонажа, проблем с производительностью скорее всего не будет. Анимации в AnimationPlayer тоже возможно синхронизировать с тиками физики (по умолчанию стоит другой режим):
>ANIMATION_PROCESS_PHYSICS = 0 --- Process animation during the physics process. This is especially useful when animating physics bodies.
А если не секрет и если не трудно, расскажи, как ты планировал делать файтинг "покадрово"? Может быть, тебе достаточно будет отказаться от RigidBody2D? В смысле, персонажам в файтингах ведь не нужна настоящая физика. Area2D сами по себе никогда не двигаются, тебе в любом случае придётся двигать их вручную кодом или через анимации. Анимации, кстати, можно проигрывать покадрово из кода, для этого есть отдельный режим...
>>825477 →
Мы обсуждали const array = []. Слово "const" означает константу, то есть значение, которое по определению должно быть невозможно изменять, в отличие от переменной (var = variable). Программист должен ожидать, что все значения массива-константы изменить нельзя. В других языках, например, в Object Pascal, это так и есть. Но в GDScript интерпретатор ошибочно создаёт массив и не следит за состоянием его ячеек, сохраняя неизменным только ссылку на него. Это однозначно ошибочное поведение, нарушающее логику программы, т.е. баг, который должен быть исправлен.
Кстати, массиву вовсе не "положено" передаваться по ссылке. Это реализация variant массивов в GDScript передаётся по ссылке. Но даже в GDScript есть массивы, передающиеся по значению - это массивы с названиями PoolТипArray:
При том что их размер тоже можно свободно менять, но хранить можно только один тип данных вместо variant.
Ещё раз повторю:
1. Поведение const массивов и словарей в GDScript ошибочно, является следствием бага и должно быть рано или поздно исправлено.
2. Если вам нужны статичные поля, для их объявления нужно было бы использовать слово static, но статичные поля в GDScript официально не поддерживаются и их поддержка в ближайшее время не планируется.
3. Использовать вместо static полей const массивы и словари некорректно и рискованно, потому что вы можете оказаться в ситуации, когда баг с const уже исправлен, а поддержка static всё ещё не планируется или планируется в отдалённом будущем - тогда для обновления на новую версию движка придётся существенно переработать архитектуру проекта.
4. В общем и целом использовать недокументированные или ошибочные свойства стороннего движка неправильно и несёт в себе повышенный риск для проекта, если, конечно, вы не планируете оставаться на одной версии движка или не хотите надолго застрять на одной из версий движка; аналогично верно для компилятора и процессора, если вы пишите свой движок с нуля или свой компилятор с нуля соответственно.
>Это не баг, это фича. Как и положено массиву, он передается по ссылке и в него можно что-то помещать.
Мы обсуждали const array = []. Слово "const" означает константу, то есть значение, которое по определению должно быть невозможно изменять, в отличие от переменной (var = variable). Программист должен ожидать, что все значения массива-константы изменить нельзя. В других языках, например, в Object Pascal, это так и есть. Но в GDScript интерпретатор ошибочно создаёт массив и не следит за состоянием его ячеек, сохраняя неизменным только ссылку на него. Это однозначно ошибочное поведение, нарушающее логику программы, т.е. баг, который должен быть исправлен.
Кстати, массиву вовсе не "положено" передаваться по ссылке. Это реализация variant массивов в GDScript передаётся по ссылке. Но даже в GDScript есть массивы, передающиеся по значению - это массивы с названиями PoolТипArray:
>Note: This type is passed by value and not by reference.
При том что их размер тоже можно свободно менять, но хранить можно только один тип данных вместо variant.
Ещё раз повторю:
1. Поведение const массивов и словарей в GDScript ошибочно, является следствием бага и должно быть рано или поздно исправлено.
2. Если вам нужны статичные поля, для их объявления нужно было бы использовать слово static, но статичные поля в GDScript официально не поддерживаются и их поддержка в ближайшее время не планируется.
3. Использовать вместо static полей const массивы и словари некорректно и рискованно, потому что вы можете оказаться в ситуации, когда баг с const уже исправлен, а поддержка static всё ещё не планируется или планируется в отдалённом будущем - тогда для обновления на новую версию движка придётся существенно переработать архитектуру проекта.
4. В общем и целом использовать недокументированные или ошибочные свойства стороннего движка неправильно и несёт в себе повышенный риск для проекта, если, конечно, вы не планируете оставаться на одной версии движка или не хотите надолго застрять на одной из версий движка; аналогично верно для компилятора и процессора, если вы пишите свой движок с нуля или свой компилятор с нуля соответственно.
>>825477 →
Мы обсуждали const array = []. Слово "const" означает константу, то есть значение, которое по определению должно быть невозможно изменять, в отличие от переменной (var = variable). Программист должен ожидать, что все значения массива-константы изменить нельзя. В других языках, например, в Object Pascal, это так и есть. Но в GDScript интерпретатор ошибочно создаёт массив и не следит за состоянием его ячеек, сохраняя неизменным только ссылку на него. Это однозначно ошибочное поведение, нарушающее логику программы, т.е. баг, который должен быть исправлен.
Кстати, массиву вовсе не "положено" передаваться по ссылке. Это реализация variant массивов в GDScript передаётся по ссылке. Но даже в GDScript есть массивы, передающиеся по значению - это массивы с названиями PoolТипArray:
При том что их размер тоже можно свободно менять, но хранить можно только один тип данных вместо variant.
Ещё раз повторю:
1. Поведение const массивов и словарей в GDScript ошибочно, является следствием бага и должно быть рано или поздно исправлено.
2. Если вам нужны статичные поля, для их объявления нужно было бы использовать слово static, но статичные поля в GDScript официально не поддерживаются и их поддержка в ближайшее время не планируется.
3. Использовать вместо static полей const массивы и словари некорректно и рискованно, потому что вы можете оказаться в ситуации, когда баг с const уже исправлен, а поддержка static всё ещё не планируется или планируется в отдалённом будущем - тогда для обновления на новую версию движка придётся существенно переработать архитектуру проекта.
4. В общем и целом использовать недокументированные или ошибочные свойства стороннего движка неправильно и несёт в себе повышенный риск для проекта, если, конечно, вы не планируете оставаться на одной версии движка или не хотите надолго застрять на одной из версий движка; аналогично верно для компилятора и процессора, если вы пишите свой движок с нуля или свой компилятор с нуля соответственно.
>Это не баг, это фича. Как и положено массиву, он передается по ссылке и в него можно что-то помещать.
Мы обсуждали const array = []. Слово "const" означает константу, то есть значение, которое по определению должно быть невозможно изменять, в отличие от переменной (var = variable). Программист должен ожидать, что все значения массива-константы изменить нельзя. В других языках, например, в Object Pascal, это так и есть. Но в GDScript интерпретатор ошибочно создаёт массив и не следит за состоянием его ячеек, сохраняя неизменным только ссылку на него. Это однозначно ошибочное поведение, нарушающее логику программы, т.е. баг, который должен быть исправлен.
Кстати, массиву вовсе не "положено" передаваться по ссылке. Это реализация variant массивов в GDScript передаётся по ссылке. Но даже в GDScript есть массивы, передающиеся по значению - это массивы с названиями PoolТипArray:
>Note: This type is passed by value and not by reference.
При том что их размер тоже можно свободно менять, но хранить можно только один тип данных вместо variant.
Ещё раз повторю:
1. Поведение const массивов и словарей в GDScript ошибочно, является следствием бага и должно быть рано или поздно исправлено.
2. Если вам нужны статичные поля, для их объявления нужно было бы использовать слово static, но статичные поля в GDScript официально не поддерживаются и их поддержка в ближайшее время не планируется.
3. Использовать вместо static полей const массивы и словари некорректно и рискованно, потому что вы можете оказаться в ситуации, когда баг с const уже исправлен, а поддержка static всё ещё не планируется или планируется в отдалённом будущем - тогда для обновления на новую версию движка придётся существенно переработать архитектуру проекта.
4. В общем и целом использовать недокументированные или ошибочные свойства стороннего движка неправильно и несёт в себе повышенный риск для проекта, если, конечно, вы не планируете оставаться на одной версии движка или не хотите надолго застрять на одной из версий движка; аналогично верно для компилятора и процессора, если вы пишите свой движок с нуля или свой компилятор с нуля соответственно.
>>25810
Может это и ошибочное поведение, но необычным оно не выглядит - в с/с++ const array не означает array of const.
Может это и ошибочное поведение, но необычным оно не выглядит - в с/с++ const array не означает array of const.
>>25800
Нормальные разрабы и без гпл делятся
https://github.com/godotengine/godot/issues/62291
А говнюки и с гпл бы не поделиись. (Знаю софт который 5 лет всем по губам водит)
Нормальные разрабы и без гпл делятся
https://github.com/godotengine/godot/issues/62291
А говнюки и с гпл бы не поделиись. (Знаю софт который 5 лет всем по губам водит)
>>25827
Нет, там чел использует чужой гпл и не отдает сорцы.
А у аспрайта все в порядке. Дело в том, что автор(ы) могут лицензировать свой код несколькими способами, напр. Dual lucense gpl для всех + коммерческая лицензия с eula. поэтому если все контрибуторы согласились отказаться от gpl, то все ок, либо код отказавшихся просто удалят и перепишут, такие случаи тоже были. Другое дело что чем больше контрибьюторов тем сложнее получить согласие всех, так что годота это не коснется никогда.
Нет, там чел использует чужой гпл и не отдает сорцы.
А у аспрайта все в порядке. Дело в том, что автор(ы) могут лицензировать свой код несколькими способами, напр. Dual lucense gpl для всех + коммерческая лицензия с eula. поэтому если все контрибуторы согласились отказаться от gpl, то все ок, либо код отказавшихся просто удалят и перепишут, такие случаи тоже были. Другое дело что чем больше контрибьюторов тем сложнее получить согласие всех, так что годота это не коснется никогда.
297 Кб, 1200x1500>>25829
Лицензия MIT позволяет сделать это без чего-либо согласия, потому что не заставляет публиковать код - достаточно только указать авторство используемого кода. Достаточно уйти основным разработчикам, и кто тогда останется поддерживать оставшуюся свободной версию движка? Придётся выбирать между закрытой продвинутой версией, в которой есть всё из открытой до и после разделения, и открытой, но во всём отстающей от закрытой.
Но GPL, конечно, всех бы только распугала. И в первую очередь юзеров движка, т.е. разработчиков игр. Возможно, только поэтому Blender Game Engine не взлетел, хотя Blender стремительно набирал популярность и юзать BGE прямо из Blender было удобнее, чем, например, переносить модели из Blender в Godot сегодня. UPBGE до сих пор кто-то пилит, но кто им пользуется?
>Другое дело что чем больше контрибьюторов тем сложнее получить согласие всех, так что годота это не коснется никогда.
Лицензия MIT позволяет сделать это без чего-либо согласия, потому что не заставляет публиковать код - достаточно только указать авторство используемого кода. Достаточно уйти основным разработчикам, и кто тогда останется поддерживать оставшуюся свободной версию движка? Придётся выбирать между закрытой продвинутой версией, в которой есть всё из открытой до и после разделения, и открытой, но во всём отстающей от закрытой.
Но GPL, конечно, всех бы только распугала. И в первую очередь юзеров движка, т.е. разработчиков игр. Возможно, только поэтому Blender Game Engine не взлетел, хотя Blender стремительно набирал популярность и юзать BGE прямо из Blender было удобнее, чем, например, переносить модели из Blender в Godot сегодня. UPBGE до сих пор кто-то пилит, но кто им пользуется?
>>25805
Я собирался делать универсальный контроллер отдельно и набор анимаций с хитбоксами отдельно. Взаимодействие персонажей с каждым другим - что, зачем?
Я представлял себе такой луп - движение > обработка > движение. Контроллеры прочитали инпут, произвели движение и смену анимаций. Их хитбоксы возможно соприкоснулись. Контроллеры прочитали все хитбоксы, выяснили что в них залетело, приняли решение по следующему стейту, анимации, движению. Все просто, всех со всеми хардкодить не надо. Например, если персонаж ударил хитбоксом в хуртбокс другого персонажа, тот получил информацию о том какая атака его ударила, какой урон и эффекты. Ударивший остается в нейтрал стейте, контроллер слушает следущие инпуты. Ударенный проигрывает анимацию откидывания или что-то такое. То есть застывшая картина, стоп кадр - полный анализ этой картины - следующий шаг - следующая картина. Это позволит иметь четкий приоритет действий, например, успел ли в этом кадре персонаж поставить блок, и четкий тайминг. Тайминги вообще крайне важны, и они считаются обычно в (физических) кадрах.
Возможно с тиком физики в 200 это все будет работать, действительно.
Для файтинга важен низкий и единообразный инпут лаг. Даже если есть некоторая задержка, лучше пусть она будет одинаковой. Система эвентов вносит в задержку непредсказуемость, выполнение обработчиков может зависеть от производительности или очереди поступления эвентов, а для таймингов надо делать какой-то таймер, я даже не знаю что, что-то надежное, что будет, возможно, в конце концов возвращать эту ригиндность.
Вообще нет, там только несколько групп коллайдеров, попадение в любой из группы равнозначно. Неважно куда ударили например, в голову или в кончик ноги, в файтингах все это не учитывается. Это обычный контроллер со стейт машиной например. >>25772 (Del) вот тут анон пишет что эвенты часто приходят наоборот, тот который должен был произойти первым происходит вторым. Я не знаю, можно ли на это повлиять очередью обработки, не видел ее. Но в целом такое поведение для файтинга, или даже для хардкорного платформера нежелательно. Для любой игры типа слешера, соулс лайка, с действительно выверенной боевкой может быть нежелательно, но это надо тестить. С дивана вызывает недоверие.
И повторю еще раз, это не значит шизофренический хардкодинг или ооп-диссидентство.
> делать взаимодействия каждого персонажа с каждым другим покадрово с ума сойдёшь
>А если не секрет и если не трудно, расскажи, как ты планировал делать файтинг "покадрово"?
Я собирался делать универсальный контроллер отдельно и набор анимаций с хитбоксами отдельно. Взаимодействие персонажей с каждым другим - что, зачем?
Я представлял себе такой луп - движение > обработка > движение. Контроллеры прочитали инпут, произвели движение и смену анимаций. Их хитбоксы возможно соприкоснулись. Контроллеры прочитали все хитбоксы, выяснили что в них залетело, приняли решение по следующему стейту, анимации, движению. Все просто, всех со всеми хардкодить не надо. Например, если персонаж ударил хитбоксом в хуртбокс другого персонажа, тот получил информацию о том какая атака его ударила, какой урон и эффекты. Ударивший остается в нейтрал стейте, контроллер слушает следущие инпуты. Ударенный проигрывает анимацию откидывания или что-то такое. То есть застывшая картина, стоп кадр - полный анализ этой картины - следующий шаг - следующая картина. Это позволит иметь четкий приоритет действий, например, успел ли в этом кадре персонаж поставить блок, и четкий тайминг. Тайминги вообще крайне важны, и они считаются обычно в (физических) кадрах.
Возможно с тиком физики в 200 это все будет работать, действительно.
Для файтинга важен низкий и единообразный инпут лаг. Даже если есть некоторая задержка, лучше пусть она будет одинаковой. Система эвентов вносит в задержку непредсказуемость, выполнение обработчиков может зависеть от производительности или очереди поступления эвентов, а для таймингов надо делать какой-то таймер, я даже не знаю что, что-то надежное, что будет, возможно, в конце концов возвращать эту ригиндность.
>if else if else if else
Вообще нет, там только несколько групп коллайдеров, попадение в любой из группы равнозначно. Неважно куда ударили например, в голову или в кончик ноги, в файтингах все это не учитывается. Это обычный контроллер со стейт машиной например. >>25772 (Del) вот тут анон пишет что эвенты часто приходят наоборот, тот который должен был произойти первым происходит вторым. Я не знаю, можно ли на это повлиять очередью обработки, не видел ее. Но в целом такое поведение для файтинга, или даже для хардкорного платформера нежелательно. Для любой игры типа слешера, соулс лайка, с действительно выверенной боевкой может быть нежелательно, но это надо тестить. С дивана вызывает недоверие.
И повторю еще раз, это не значит шизофренический хардкодинг или ооп-диссидентство.
>>25805
Я собирался делать универсальный контроллер отдельно и набор анимаций с хитбоксами отдельно. Взаимодействие персонажей с каждым другим - что, зачем?
Я представлял себе такой луп - движение > обработка > движение. Контроллеры прочитали инпут, произвели движение и смену анимаций. Их хитбоксы возможно соприкоснулись. Контроллеры прочитали все хитбоксы, выяснили что в них залетело, приняли решение по следующему стейту, анимации, движению. Все просто, всех со всеми хардкодить не надо. Например, если персонаж ударил хитбоксом в хуртбокс другого персонажа, тот получил информацию о том какая атака его ударила, какой урон и эффекты. Ударивший остается в нейтрал стейте, контроллер слушает следущие инпуты. Ударенный проигрывает анимацию откидывания или что-то такое. То есть застывшая картина, стоп кадр - полный анализ этой картины - следующий шаг - следующая картина. Это позволит иметь четкий приоритет действий, например, успел ли в этом кадре персонаж поставить блок, и четкий тайминг. Тайминги вообще крайне важны, и они считаются обычно в (физических) кадрах.
Возможно с тиком физики в 200 это все будет работать, действительно.
Для файтинга важен низкий и единообразный инпут лаг. Даже если есть некоторая задержка, лучше пусть она будет одинаковой. Система эвентов вносит в задержку непредсказуемость, выполнение обработчиков может зависеть от производительности или очереди поступления эвентов, а для таймингов надо делать какой-то таймер, я даже не знаю что, что-то надежное, что будет, возможно, в конце концов возвращать эту ригиндность.
Вообще нет, там только несколько групп коллайдеров, попадение в любой из группы равнозначно. Неважно куда ударили например, в голову или в кончик ноги, в файтингах все это не учитывается. Это обычный контроллер со стейт машиной например. >>25772 (Del) вот тут анон пишет что эвенты часто приходят наоборот, тот который должен был произойти первым происходит вторым. Я не знаю, можно ли на это повлиять очередью обработки, не видел ее. Но в целом такое поведение для файтинга, или даже для хардкорного платформера нежелательно. Для любой игры типа слешера, соулс лайка, с действительно выверенной боевкой может быть нежелательно, но это надо тестить. С дивана вызывает недоверие.
И повторю еще раз, это не значит шизофренический хардкодинг или ооп-диссидентство.
> делать взаимодействия каждого персонажа с каждым другим покадрово с ума сойдёшь
>А если не секрет и если не трудно, расскажи, как ты планировал делать файтинг "покадрово"?
Я собирался делать универсальный контроллер отдельно и набор анимаций с хитбоксами отдельно. Взаимодействие персонажей с каждым другим - что, зачем?
Я представлял себе такой луп - движение > обработка > движение. Контроллеры прочитали инпут, произвели движение и смену анимаций. Их хитбоксы возможно соприкоснулись. Контроллеры прочитали все хитбоксы, выяснили что в них залетело, приняли решение по следующему стейту, анимации, движению. Все просто, всех со всеми хардкодить не надо. Например, если персонаж ударил хитбоксом в хуртбокс другого персонажа, тот получил информацию о том какая атака его ударила, какой урон и эффекты. Ударивший остается в нейтрал стейте, контроллер слушает следущие инпуты. Ударенный проигрывает анимацию откидывания или что-то такое. То есть застывшая картина, стоп кадр - полный анализ этой картины - следующий шаг - следующая картина. Это позволит иметь четкий приоритет действий, например, успел ли в этом кадре персонаж поставить блок, и четкий тайминг. Тайминги вообще крайне важны, и они считаются обычно в (физических) кадрах.
Возможно с тиком физики в 200 это все будет работать, действительно.
Для файтинга важен низкий и единообразный инпут лаг. Даже если есть некоторая задержка, лучше пусть она будет одинаковой. Система эвентов вносит в задержку непредсказуемость, выполнение обработчиков может зависеть от производительности или очереди поступления эвентов, а для таймингов надо делать какой-то таймер, я даже не знаю что, что-то надежное, что будет, возможно, в конце концов возвращать эту ригиндность.
>if else if else if else
Вообще нет, там только несколько групп коллайдеров, попадение в любой из группы равнозначно. Неважно куда ударили например, в голову или в кончик ноги, в файтингах все это не учитывается. Это обычный контроллер со стейт машиной например. >>25772 (Del) вот тут анон пишет что эвенты часто приходят наоборот, тот который должен был произойти первым происходит вторым. Я не знаю, можно ли на это повлиять очередью обработки, не видел ее. Но в целом такое поведение для файтинга, или даже для хардкорного платформера нежелательно. Для любой игры типа слешера, соулс лайка, с действительно выверенной боевкой может быть нежелательно, но это надо тестить. С дивана вызывает недоверие.
И повторю еще раз, это не значит шизофренический хардкодинг или ооп-диссидентство.
>>25879
Никто и не говорил про риджидбоди. Я собирался делать либо кинематик боди либо без боди вообще. Физика, действительно, не нужна. речь была только про систему коллиженов.
>Может быть, тебе достаточно будет отказаться от RigidBody2D?
Никто и не говорил про риджидбоди. Я собирался делать либо кинематик боди либо без боди вообще. Физика, действительно, не нужна. речь была только про систему коллиженов.
>>25879
Посмотри может в движке есть быстрые aabb проверки пересечений, тогда физика вообще не нужна.
Посмотри может в движке есть быстрые aabb проверки пересечений, тогда физика вообще не нужна.
>>25882
Думал об этом, нашел rect2 и aabb, там написано про проверки пересечений но их пока не нашел, видимо они есть.
Думал об этом, нашел rect2 и aabb, там написано про проверки пересечений но их пока не нашел, видимо они есть.
>>25900 (Del)
Я все неправильно понял с этими рект2, я думал их использует движок, из какого-то поста где-то в голове застряло что суть оптимизации в том что там невозможно вращение, типа axis aligned по четырем (двум) точкам, но все равно движком. Но да, конечно же, он прост сравнивает свои глобальные координаты.
Я все неправильно понял с этими рект2, я думал их использует движок, из какого-то поста где-то в голове застряло что суть оптимизации в том что там невозможно вращение, типа axis aligned по четырем (двум) точкам, но все равно движком. Но да, конечно же, он прост сравнивает свои глобальные координаты.
>>25915 (Del)
Так движок оптимизирует неповернутые колайдеры? Должен по идее.
Так движок оптимизирует неповернутые колайдеры? Должен по идее.
>>25810
Так новый массив туда и нельзя определить.
Так новый массив туда и нельзя определить.
Как можно поменять систему?
Проблема. У меня в сцене много объектов, и это приводит к торомозам.
Есть нода forest, в которую инстанцируются чайлды tree.
Каждое tree - просто дочерняя сцена, где присутствует моделька в виде пирамидки + прицепленный скрипт, где просто пара dictionary с описанием свойств дерева.
Вот просто наличие этого приводит к тормозам. Если видимость чайлдов убираю, то производительность возвращается в норму.
Но разве инстанциирование без какой либо обработки (в условном process) не должно от таких штук помогать?
Проблема. У меня в сцене много объектов, и это приводит к торомозам.
Есть нода forest, в которую инстанцируются чайлды tree.
Каждое tree - просто дочерняя сцена, где присутствует моделька в виде пирамидки + прицепленный скрипт, где просто пара dictionary с описанием свойств дерева.
Вот просто наличие этого приводит к тормозам. Если видимость чайлдов убираю, то производительность возвращается в норму.
Но разве инстанциирование без какой либо обработки (в условном process) не должно от таких штук помогать?
>>25964 (Del)
Не, с добавлением всё ок. Тормоза начинаются по fps, когда камеру по уже построенной сцене двигать начинаю, хотя у меня ничего там не происходит и не считается. Только объекты присутствуют.
Не, с добавлением всё ок. Тормоза начинаются по fps, когда камеру по уже построенной сцене двигать начинаю, хотя у меня ничего там не происходит и не считается. Только объекты присутствуют.
>>25999 (Del)
Поздравляю, анон.
Так же поздравляю всех с выходом новой макабы.
Где моя галка ОПа?
https://www.youtube.com/watch?v=NjIJm2jax68&t=320s
>Поздравляю с выходом 3.5, ребятки
Поздравляю, анон.
Так же поздравляю всех с выходом новой макабы.
Где моя галка ОПа?
https://www.youtube.com/watch?v=NjIJm2jax68&t=320s
Там в 3.5 какие то пины ввели, чтобы поля фиксировать. Нахуй они нужны? Есть хоть один реальный кейс, когда нужны?
>>26004
Ну смотри, у тебя базовый ассет со скоростью 150. А от него наследуются две группы ассетов, одна с базовой скоростью 350, а вторая 100. А от них наследуются ассеты мобов, неписей и т.д. И вот ты в группах фиксируешь скорости 350 и 100.
А от базового ассета у тебя наследуется игрок, и ему надо оставить 150.
Ну смотри, у тебя базовый ассет со скоростью 150. А от него наследуются две группы ассетов, одна с базовой скоростью 350, а вторая 100. А от них наследуются ассеты мобов, неписей и т.д. И вот ты в группах фиксируешь скорости 350 и 100.
А от базового ассета у тебя наследуется игрок, и ему надо оставить 150.
>>26008
Так нельзя чтобы рутом была изменённая нода. Т.е. наследуют скрипты. Т.е. теперь есть возможность между наследованием переопределить константы и переменные в чилд классе?
Так нельзя чтобы рутом была изменённая нода. Т.е. наследуют скрипты. Т.е. теперь есть возможность между наследованием переопределить константы и переменные в чилд классе?
Ещё видос с воцньюсами
https://www.youtube.com/watch?v=FATA85YE4eY
https://www.youtube.com/watch?v=FATA85YE4eY
>>26010
И как это в скрипте написать? Я видел, что они какие то марки ставили. Где кусок кода ответственный за переопределение.
И как это в скрипте написать? Я видел, что они какие то марки ставили. Где кусок кода ответственный за переопределение.
>>26013
Ну, этот объект не может стать рутом другого объекта. Он же кастомный. Зачем мне на то, что не может дать прямых детей вешать дефолт значения?
Ну, этот объект не может стать рутом другого объекта. Он же кастомный. Зачем мне на то, что не может дать прямых детей вешать дефолт значения?
1,6 Мб, mp4,258x398, 0:32
Должен ли max rate у AudioStreamSample увеличивать Pitch проигрываемого звука в AudioStreamPlayer?
>>25879
Разве? Но как тогда выбирать анимацию?
Пример:
- делаем подсечку
- делаем подсечку, но перед этим подпрыгнули
В первом случае удар придётся по ноге противника и он должен упасть лицом вперёд, во втором случае удар придётся в голову или грудь противника и он должен упасть на спину.
Либо ты говоришь о каких-то совсем простых файтингах, где нет никакой симуляции боя, а весь геймплей заточен на скорость реакции игрока...
>Неважно куда ударили например, в голову или в кончик ноги, в файтингах все это не учитывается.
Разве? Но как тогда выбирать анимацию?
Пример:
- делаем подсечку
- делаем подсечку, но перед этим подпрыгнули
В первом случае удар придётся по ноге противника и он должен упасть лицом вперёд, во втором случае удар придётся в голову или грудь противника и он должен упасть на спину.
Либо ты говоришь о каких-то совсем простых файтингах, где нет никакой симуляции боя, а весь геймплей заточен на скорость реакции игрока...
>>25900 (Del)
https://docs.godotengine.org/en/stable/classes/class_sprite.html#class-sprite-method-get-rect
https://docs.godotengine.org/en/stable/classes/class_sprite.html#class-sprite-method-get-rect
>Returns a Rect2 representing the Sprite's boundary in local coordinates.
>>25956
Дело в том, что отдельные MeshInstance Godot 3.x рендерит отдельными вызовами отрисовки (draw call). Вызов отрисовки - запрос к видеокарте, скорость которого зависит в большей степени от процессора, а не от видеокарты. Т.е. представь себе ситуацию, как очень быстрый исполнитель получает задания по одному от очень медленного заказчика - исполнитель большую часть времени бездействует, ожидая следующий запрос от заказчика, в результате суммарное время выполнения всех задач очень сильно удлиняется. Основных решения проблемы два - использовать инстансинг для одинаковых объектов (MultiMeshInstance, он же используется внутри GridMap) или объединять разные объекты в один цельный меш (в 3.5 добавили метод для склеивания мешей с одинаковыми материалами). В Godot 4.0 проблему частично решили для одинаковых объектов, теперь они автоматически рендерятся за один вызов отрисовки.
>Если видимость чайлдов убираю, то производительность возвращается в норму.
Дело в том, что отдельные MeshInstance Godot 3.x рендерит отдельными вызовами отрисовки (draw call). Вызов отрисовки - запрос к видеокарте, скорость которого зависит в большей степени от процессора, а не от видеокарты. Т.е. представь себе ситуацию, как очень быстрый исполнитель получает задания по одному от очень медленного заказчика - исполнитель большую часть времени бездействует, ожидая следующий запрос от заказчика, в результате суммарное время выполнения всех задач очень сильно удлиняется. Основных решения проблемы два - использовать инстансинг для одинаковых объектов (MultiMeshInstance, он же используется внутри GridMap) или объединять разные объекты в один цельный меш (в 3.5 добавили метод для склеивания мешей с одинаковыми материалами). В Godot 4.0 проблему частично решили для одинаковых объектов, теперь они автоматически рендерятся за один вызов отрисовки.
3,6 Мб, 465x338>>26063
БАЛЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ Заработало. Перекодил все аудиофайлы в MP3. Ебаный рот этого казино
БАЛЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯЯ Заработало. Перекодил все аудиофайлы в MP3. Ебаный рот этого казино
>>26056
По идее всё так и должно быть. Чем выше высота звука, тем короче волны и тем плотнее они расположены. Дискретизация звука - это сохранение значений волны с определённой скоростью. Если у тебя звук сохранён с частотой дискретизации 22 кГц, это означает, что у тебя 22 тысячи точек на каждую секунду. Если ты будешь считывать волну как если бы она была записана с частотой 44 кГц, у тебя волны будут в 2 раза короче и, следовательно, в 2 раза выше. Если ты хочешь качество звука 44 кГц, тебе нужно найти запись на такой частоте, потому что движок не сможет придумать то, чего нет в твоих исходных файлах.
>>26080
Ну и что толку, если оригиналы были 22 кГц?
По идее всё так и должно быть. Чем выше высота звука, тем короче волны и тем плотнее они расположены. Дискретизация звука - это сохранение значений волны с определённой скоростью. Если у тебя звук сохранён с частотой дискретизации 22 кГц, это означает, что у тебя 22 тысячи точек на каждую секунду. Если ты будешь считывать волну как если бы она была записана с частотой 44 кГц, у тебя волны будут в 2 раза короче и, следовательно, в 2 раза выше. Если ты хочешь качество звука 44 кГц, тебе нужно найти запись на такой частоте, потому что движок не сможет придумать то, чего нет в твоих исходных файлах.
>>26080
>Перекодил все аудиофайлы в MP3.
Ну и что толку, если оригиналы были 22 кГц?
>>26087
Все wav-файлы варьировались от 22кгц до 48кгц. Частоту приходилось устанавливать вручную, годот устанавливал всем max rate в значение 44100 по умолчанию.
С MP3 такого нет. Закинул, работает.
Ни в одном туторе вот этой всей хуйни не упоминается. Справедливо полагать, баг.
Все wav-файлы варьировались от 22кгц до 48кгц. Частоту приходилось устанавливать вручную, годот устанавливал всем max rate в значение 44100 по умолчанию.
С MP3 такого нет. Закинул, работает.
Ни в одном туторе вот этой всей хуйни не упоминается. Справедливо полагать, баг.
109 Кб, 1280x1238>>26098 (Del)
Как делать красиво?
Алсо вьюпорт для надписей больше не нужен, сделали специальную ноду Label3D и создание мешей из букв.
>Красиво делай
Как делать красиво?
Алсо вьюпорт для надписей больше не нужен, сделали специальную ноду Label3D и создание мешей из букв.
Странные вопросы возникли.
А можно ли батчами данные писать в словарь, например?
Например, хочу сделать 500 ключей, от 0 до 499, где у каждого из них есть значение. И в каой-то момент хочу поменять значения у всех на одинаковое.
Чтобы не циклами вида "for i in range(0, 499, 1)" это изменять.
Можно ли в своих модулях переиспользовать имеющийся функционал, вроде AStar2D?
А можно ли батчами данные писать в словарь, например?
Например, хочу сделать 500 ключей, от 0 до 499, где у каждого из них есть значение. И в каой-то момент хочу поменять значения у всех на одинаковое.
Чтобы не циклами вида "for i in range(0, 499, 1)" это изменять.
Можно ли в своих модулях переиспользовать имеющийся функционал, вроде AStar2D?
>>26196
Ебани сигнал, обновляющий словарь.
Ебани коннекты с биндом на каждый ключ словаря.
При испускании сигнала теоретически все колбэки законнекченные выстрелят в одном фрейме одновременно. Но это такой диван, шояебу! Проверяй сам. Тока схорони проект перед запуском, лол.
> батчами данные писать в словарь, например?
> И в каой-то момент хочу поменять значения у всех на одинаковое.
Ебани сигнал, обновляющий словарь.
>signal update_data(new_value)
Ебани коннекты с биндом на каждый ключ словаря.
>connect("update_data", self, "on_update_data", ["key1"])
>connect("update_data", self, "on_update_data", ["key2"])
>...
>connect("update_data", self, "on_update_data", ["key500"])
>...
>func on_update_data(new_value, binded_key):
> >my_dick[binded_key] = new_value
При испускании сигнала теоретически все колбэки законнекченные выстрелят в одном фрейме одновременно. Но это такой диван, шояебу! Проверяй сам. Тока схорони проект перед запуском, лол.
55 Кб, 800x600>>26111 (Del)
Нет, от шрифта это не зависит. На том скриншоте, если я правильно помню (зря удалили, проблема реально есть), была проблема с размером шрифта по умолчанию - он слишком маленький, поэтому видны сильные артефакты от растягивания текстуры в 3D. Чтобы Label3D выглядел гладко, нужно увеличивать размер шрифта и уменьшать параметр pixel_size:
https://docs.godotengine.org/en/stable/classes/class_label3d.html#class-label3d-property-pixel-size
На пикриле размер шрифта 64, pixel_size равен чему-то около 0.0025. Т.е. увеличил шрифт в 4 раза по сравнению со шрифтом по умолчанию и соответственно сжал Label3D - получилось сравнительно гладко, без пиксельных артефактов.
Кстати, установив alpha_cut = ALPHA_CUT_DISCARD, можно полностью избавиться от сглаживания текста, получив нечто вроде пиксельного шрифта, если размер шрифта по умолчанию или около того.
Вообще, Godot часто страдает от неудачных настроек по умолчанию. Первое впечатление при знакомстве с возможностями движка очень важно, многие не станут искать решение в интернете, увидив неудачный или неподходящий им результат с настройками по умолчанию...
>Вставить красивый шрифт.
Нет, от шрифта это не зависит. На том скриншоте, если я правильно помню (зря удалили, проблема реально есть), была проблема с размером шрифта по умолчанию - он слишком маленький, поэтому видны сильные артефакты от растягивания текстуры в 3D. Чтобы Label3D выглядел гладко, нужно увеличивать размер шрифта и уменьшать параметр pixel_size:
https://docs.godotengine.org/en/stable/classes/class_label3d.html#class-label3d-property-pixel-size
На пикриле размер шрифта 64, pixel_size равен чему-то около 0.0025. Т.е. увеличил шрифт в 4 раза по сравнению со шрифтом по умолчанию и соответственно сжал Label3D - получилось сравнительно гладко, без пиксельных артефактов.
Кстати, установив alpha_cut = ALPHA_CUT_DISCARD, можно полностью избавиться от сглаживания текста, получив нечто вроде пиксельного шрифта, если размер шрифта по умолчанию или около того.
Вообще, Godot часто страдает от неудачных настроек по умолчанию. Первое впечатление при знакомстве с возможностями движка очень важно, многие не станут искать решение в интернете, увидив неудачный или неподходящий им результат с настройками по умолчанию...
>>26253
Кстати, если подумать...
В каких единицах измерения 0.01? По всей видимости, в метрах. Т.е. по умолчанию один пиксель текста Label3D занимает квадрат 1x1 см в пространстве. Хорошо это или плохо? Если в игре мы смотрим на персонажей с большой высоты, то, возможно, это оптимальный размер. Но если мы играем от первого лица и тычемся в персонажей лицом к лицу, сантиметровые пиксели будут бросаться в глаза.
А это равно 2.5 мм, что значительно менее заметно в случае игры от первого лица.
Я бы добавил пояснение/рекомендацию в документацию к описанию pixel_size, чтобы сразу было понятно, какой примерно размер пикселя нужен пользователю. А то это 0.01 без указания единиц измерения сбивает с толку - непонятно, почему выбрали именно его, и нужно ли тебе его изменять, и если нужно, то когда и зачем. В частности, может возникнуть вопрос, чем отличается pixel_size от параметра Node3D.scale в контексте "...to scale it in 3D".
Кстати, если подумать...
>float pixel_size
>Default 0.01
>The size of one pixel's width on the label to scale it in 3D.
В каких единицах измерения 0.01? По всей видимости, в метрах. Т.е. по умолчанию один пиксель текста Label3D занимает квадрат 1x1 см в пространстве. Хорошо это или плохо? Если в игре мы смотрим на персонажей с большой высоты, то, возможно, это оптимальный размер. Но если мы играем от первого лица и тычемся в персонажей лицом к лицу, сантиметровые пиксели будут бросаться в глаза.
>0.0025
А это равно 2.5 мм, что значительно менее заметно в случае игры от первого лица.
Я бы добавил пояснение/рекомендацию в документацию к описанию pixel_size, чтобы сразу было понятно, какой примерно размер пикселя нужен пользователю. А то это 0.01 без указания единиц измерения сбивает с толку - непонятно, почему выбрали именно его, и нужно ли тебе его изменять, и если нужно, то когда и зачем. В частности, может возникнуть вопрос, чем отличается pixel_size от параметра Node3D.scale в контексте "...to scale it in 3D".
>>26196
Ты имеешь в виду низкоуровневую оптимизацию записи в словарь или синтаксический сахар? Насколько мне известно, ни того, ни другого в GDScript нет.
Но если тебя волнует только синтаксический сахар, ты можешь написать такую функцию:
И использовать её где угодно в проекте:
Жаль, что нельзя создать свой класс на основе Dictionary, это позволило бы сделать более удобно.
Модули Godot - это просто код на C++. Естественно, тебе доступен весь код Godot, делай с ним что хочешь. Как я понимаю, единственные ограничения - возможности C++ и баги твоего компилятора, лол.
>>26220
Это такая шутка? Зачем насиловать движок и самого себя таким извращённым способом, который здесь вообще ни к чему? Насколько я понимаю, тот анон спрашивал скорее про более оптимальный способ, чем в цикле присваивать каждому элементу новое значение (поскольку на каждую запись значения словарь сначала вычисляет хэш-сумму ключа и только потом обращается к значению), а ты предлагаешь намного менее оптимальный способ.
Это невозможно, по умолчанию весь код GDScript выполняется в одном потоке, поэтому обработчики будут выполняться последовательно, скорее всего, в порядке их подключения к сигналу. Т.е. где-то в недрах движка будет цикл на 500 элементов, последовательно вызывающий обработчики и ждущий их завершения. Пока 500-й обработчик не завершит свою работу, твой код не сдвинется дальше строчки emit_signal("update_data", "value").
Если ты хочешь продолжить выполнение кода после emit_signal(), не дожидаясь выполнения обработчиков, ты можешь присоединять обработчики с флагом CONNECT_DEFERRED. Тогда вызов обработчиков будет отложен до момента бездействия (idle time), но они всё равно будут выполняться в порядке очереди, а не одновременно.
И даже если бы обработчики могли выполняться одновременно на нескольких ядрах процессора, 500 операций просто разделились бы на 2/4/8/16 циклов, соответственно числу ядер, и в рамках одного ядра выполнялись бы последовательно, а не одновременно.
Чтобы сделать 500 перезаписей одновременно, нужен суперкомпьютер с 512+ независимыми универсальными ядрами, да и то не ясно, смогут ли они одновременно обращаться к разным участкам одной памяти (в плане физического устройства). Скорее всего, скорость будет ограничена шиной данных между процессорами и оперативной памятью. Всё же настолько распределённые вычисления имеют смысл только если вычисление достаточно сложное, но никак не зависит от других вычислений, т.е. его можно исполнять на отдельной машине с собственной, физически независимой памятью. Короче, нет смысла распределять присваивание на сотни ядер.
>А можно ли батчами данные писать в словарь, например?
Ты имеешь в виду низкоуровневую оптимизацию записи в словарь или синтаксический сахар? Насколько мне известно, ни того, ни другого в GDScript нет.
Но если тебя волнует только синтаксический сахар, ты можешь написать такую функцию:
>class_name DictUtils
>static func change_values(dict: Dictionary, value):
>_ for key in dict.keys():
>_ _ dict[key] = value
И использовать её где угодно в проекте:
>DictUtils.change_values(people, "Ivan Ivanov")
Жаль, что нельзя создать свой класс на основе Dictionary, это позволило бы сделать более удобно.
>Можно ли в своих модулях переиспользовать имеющийся функционал
Модули Godot - это просто код на C++. Естественно, тебе доступен весь код Godot, делай с ним что хочешь. Как я понимаю, единственные ограничения - возможности C++ и баги твоего компилятора, лол.
>>26220
>сигнал, обновляющий словарь
>коннекты с биндом на каждый ключ
Это такая шутка? Зачем насиловать движок и самого себя таким извращённым способом, который здесь вообще ни к чему? Насколько я понимаю, тот анон спрашивал скорее про более оптимальный способ, чем в цикле присваивать каждому элементу новое значение (поскольку на каждую запись значения словарь сначала вычисляет хэш-сумму ключа и только потом обращается к значению), а ты предлагаешь намного менее оптимальный способ.
>колбэки
>одновременно
Это невозможно, по умолчанию весь код GDScript выполняется в одном потоке, поэтому обработчики будут выполняться последовательно, скорее всего, в порядке их подключения к сигналу. Т.е. где-то в недрах движка будет цикл на 500 элементов, последовательно вызывающий обработчики и ждущий их завершения. Пока 500-й обработчик не завершит свою работу, твой код не сдвинется дальше строчки emit_signal("update_data", "value").
Если ты хочешь продолжить выполнение кода после emit_signal(), не дожидаясь выполнения обработчиков, ты можешь присоединять обработчики с флагом CONNECT_DEFERRED. Тогда вызов обработчиков будет отложен до момента бездействия (idle time), но они всё равно будут выполняться в порядке очереди, а не одновременно.
И даже если бы обработчики могли выполняться одновременно на нескольких ядрах процессора, 500 операций просто разделились бы на 2/4/8/16 циклов, соответственно числу ядер, и в рамках одного ядра выполнялись бы последовательно, а не одновременно.
Чтобы сделать 500 перезаписей одновременно, нужен суперкомпьютер с 512+ независимыми универсальными ядрами, да и то не ясно, смогут ли они одновременно обращаться к разным участкам одной памяти (в плане физического устройства). Скорее всего, скорость будет ограничена шиной данных между процессорами и оперативной памятью. Всё же настолько распределённые вычисления имеют смысл только если вычисление достаточно сложное, но никак не зависит от других вычислений, т.е. его можно исполнять на отдельной машине с собственной, физически независимой памятью. Короче, нет смысла распределять присваивание на сотни ядер.
>>26196
Ты имеешь в виду низкоуровневую оптимизацию записи в словарь или синтаксический сахар? Насколько мне известно, ни того, ни другого в GDScript нет.
Но если тебя волнует только синтаксический сахар, ты можешь написать такую функцию:
И использовать её где угодно в проекте:
Жаль, что нельзя создать свой класс на основе Dictionary, это позволило бы сделать более удобно.
Модули Godot - это просто код на C++. Естественно, тебе доступен весь код Godot, делай с ним что хочешь. Как я понимаю, единственные ограничения - возможности C++ и баги твоего компилятора, лол.
>>26220
Это такая шутка? Зачем насиловать движок и самого себя таким извращённым способом, который здесь вообще ни к чему? Насколько я понимаю, тот анон спрашивал скорее про более оптимальный способ, чем в цикле присваивать каждому элементу новое значение (поскольку на каждую запись значения словарь сначала вычисляет хэш-сумму ключа и только потом обращается к значению), а ты предлагаешь намного менее оптимальный способ.
Это невозможно, по умолчанию весь код GDScript выполняется в одном потоке, поэтому обработчики будут выполняться последовательно, скорее всего, в порядке их подключения к сигналу. Т.е. где-то в недрах движка будет цикл на 500 элементов, последовательно вызывающий обработчики и ждущий их завершения. Пока 500-й обработчик не завершит свою работу, твой код не сдвинется дальше строчки emit_signal("update_data", "value").
Если ты хочешь продолжить выполнение кода после emit_signal(), не дожидаясь выполнения обработчиков, ты можешь присоединять обработчики с флагом CONNECT_DEFERRED. Тогда вызов обработчиков будет отложен до момента бездействия (idle time), но они всё равно будут выполняться в порядке очереди, а не одновременно.
И даже если бы обработчики могли выполняться одновременно на нескольких ядрах процессора, 500 операций просто разделились бы на 2/4/8/16 циклов, соответственно числу ядер, и в рамках одного ядра выполнялись бы последовательно, а не одновременно.
Чтобы сделать 500 перезаписей одновременно, нужен суперкомпьютер с 512+ независимыми универсальными ядрами, да и то не ясно, смогут ли они одновременно обращаться к разным участкам одной памяти (в плане физического устройства). Скорее всего, скорость будет ограничена шиной данных между процессорами и оперативной памятью. Всё же настолько распределённые вычисления имеют смысл только если вычисление достаточно сложное, но никак не зависит от других вычислений, т.е. его можно исполнять на отдельной машине с собственной, физически независимой памятью. Короче, нет смысла распределять присваивание на сотни ядер.
>А можно ли батчами данные писать в словарь, например?
Ты имеешь в виду низкоуровневую оптимизацию записи в словарь или синтаксический сахар? Насколько мне известно, ни того, ни другого в GDScript нет.
Но если тебя волнует только синтаксический сахар, ты можешь написать такую функцию:
>class_name DictUtils
>static func change_values(dict: Dictionary, value):
>_ for key in dict.keys():
>_ _ dict[key] = value
И использовать её где угодно в проекте:
>DictUtils.change_values(people, "Ivan Ivanov")
Жаль, что нельзя создать свой класс на основе Dictionary, это позволило бы сделать более удобно.
>Можно ли в своих модулях переиспользовать имеющийся функционал
Модули Godot - это просто код на C++. Естественно, тебе доступен весь код Godot, делай с ним что хочешь. Как я понимаю, единственные ограничения - возможности C++ и баги твоего компилятора, лол.
>>26220
>сигнал, обновляющий словарь
>коннекты с биндом на каждый ключ
Это такая шутка? Зачем насиловать движок и самого себя таким извращённым способом, который здесь вообще ни к чему? Насколько я понимаю, тот анон спрашивал скорее про более оптимальный способ, чем в цикле присваивать каждому элементу новое значение (поскольку на каждую запись значения словарь сначала вычисляет хэш-сумму ключа и только потом обращается к значению), а ты предлагаешь намного менее оптимальный способ.
>колбэки
>одновременно
Это невозможно, по умолчанию весь код GDScript выполняется в одном потоке, поэтому обработчики будут выполняться последовательно, скорее всего, в порядке их подключения к сигналу. Т.е. где-то в недрах движка будет цикл на 500 элементов, последовательно вызывающий обработчики и ждущий их завершения. Пока 500-й обработчик не завершит свою работу, твой код не сдвинется дальше строчки emit_signal("update_data", "value").
Если ты хочешь продолжить выполнение кода после emit_signal(), не дожидаясь выполнения обработчиков, ты можешь присоединять обработчики с флагом CONNECT_DEFERRED. Тогда вызов обработчиков будет отложен до момента бездействия (idle time), но они всё равно будут выполняться в порядке очереди, а не одновременно.
И даже если бы обработчики могли выполняться одновременно на нескольких ядрах процессора, 500 операций просто разделились бы на 2/4/8/16 циклов, соответственно числу ядер, и в рамках одного ядра выполнялись бы последовательно, а не одновременно.
Чтобы сделать 500 перезаписей одновременно, нужен суперкомпьютер с 512+ независимыми универсальными ядрами, да и то не ясно, смогут ли они одновременно обращаться к разным участкам одной памяти (в плане физического устройства). Скорее всего, скорость будет ограничена шиной данных между процессорами и оперативной памятью. Всё же настолько распределённые вычисления имеют смысл только если вычисление достаточно сложное, но никак не зависит от других вычислений, т.е. его можно исполнять на отдельной машине с собственной, физически независимой памятью. Короче, нет смысла распределять присваивание на сотни ядер.
>>26260 (Del)
Согласен, полезная фича была бы.
Я воспринимаю единицу как метр, потому что в Blender по умолчанию единица равна метру, а в Godot импорт из Blender идёт один к одному. Также я ассоциирую 3D игры с играми от первого/третьего лица, где мы управляем человеком или примерно равным ему по размерам существом - не понимаю, зачем делать в 3D стратегии и подобные им жанры, которым от 3D нет практической пользы (3D - это для "погружения" в первую очередь, а для этого нужен персонаж-человечек).
В моём представлении ты кусок суши или жидкого космоса скукоживаешь до квадрата 1х1 метр, а не определяешь единицу пространства равной 1 км или 1 парсек. А вообще, 3D стратегии - это как шахматы в 3D: выглядит прикольно, но бесполезно и только мешает. И там как и в шахматах размерность клеток значения не имеет: ты мыслишь не размерами, а самими клетками.
Меня вот больше интересует восприятие пространства с точки зрения игрока. И я не про FOV, это другое. Приведу пример на двух играх: TerraTech и Scrap Mechanic. В самом общем виде они одинаковы: мы строим некие технические приспособления для добычи ресурсов и выживания на абстрактной плоской планете. Но в TerraTech всё выглядит очень маленьким, буквально игрушечным: маленькие машинки из детских кубиков катаются вокруг маленьких деревьев, собирая какие-то крошки, масштаба совсем не чувствуется, хотя, если подумать, все машины просто гигантские (начальная кабина = кабина УАЗ СГР, но это минимальный по размеру блок). В то же время в Scrap Mechanic масштабы чувствуются в полной мере: есть и деревья-гиганты, и многоэтажные здания, а ты строишь почти настоящий полноразмерный грузовик, хотя с высоты зданий он и выглядит крошечным, а в лесу вообще легко потерять за деревьями. Вот как так? Неужели всё дело только в расстоянии камеры до того, чем мы управляем, и ракурсе камеры (сверху/снизу)? Хочется, чтобы в игре ощущалась масштабность, не было лишней "игрушечности", независимо от вида графики и геймплея. В том же Scrap Mechanic графика очень мультяшная, но это не мешает ощущать масштабность объектов, они не выглядят игрушечными несмотря на мультяшный внешний вид. Как добиться такого ощущения, интересно...
>Это тогда надо как в блендере делать, настройку где ты сам укажешь и эта единица будет приписываться во всех полях объектов.
Согласен, полезная фича была бы.
>абстрактные юниты
Я воспринимаю единицу как метр, потому что в Blender по умолчанию единица равна метру, а в Godot импорт из Blender идёт один к одному. Также я ассоциирую 3D игры с играми от первого/третьего лица, где мы управляем человеком или примерно равным ему по размерам существом - не понимаю, зачем делать в 3D стратегии и подобные им жанры, которым от 3D нет практической пользы (3D - это для "погружения" в первую очередь, а для этого нужен персонаж-человечек).
>А в РТС клетка может быть 1 км. А в космостратегии 1 парсек.
В моём представлении ты кусок суши или жидкого космоса скукоживаешь до квадрата 1х1 метр, а не определяешь единицу пространства равной 1 км или 1 парсек. А вообще, 3D стратегии - это как шахматы в 3D: выглядит прикольно, но бесполезно и только мешает. И там как и в шахматах размерность клеток значения не имеет: ты мыслишь не размерами, а самими клетками.
Меня вот больше интересует восприятие пространства с точки зрения игрока. И я не про FOV, это другое. Приведу пример на двух играх: TerraTech и Scrap Mechanic. В самом общем виде они одинаковы: мы строим некие технические приспособления для добычи ресурсов и выживания на абстрактной плоской планете. Но в TerraTech всё выглядит очень маленьким, буквально игрушечным: маленькие машинки из детских кубиков катаются вокруг маленьких деревьев, собирая какие-то крошки, масштаба совсем не чувствуется, хотя, если подумать, все машины просто гигантские (начальная кабина = кабина УАЗ СГР, но это минимальный по размеру блок). В то же время в Scrap Mechanic масштабы чувствуются в полной мере: есть и деревья-гиганты, и многоэтажные здания, а ты строишь почти настоящий полноразмерный грузовик, хотя с высоты зданий он и выглядит крошечным, а в лесу вообще легко потерять за деревьями. Вот как так? Неужели всё дело только в расстоянии камеры до того, чем мы управляем, и ракурсе камеры (сверху/снизу)? Хочется, чтобы в игре ощущалась масштабность, не было лишней "игрушечности", независимо от вида графики и геймплея. В том же Scrap Mechanic графика очень мультяшная, но это не мешает ощущать масштабность объектов, они не выглядят игрушечными несмотря на мультяшный внешний вид. Как добиться такого ощущения, интересно...
>>26260 (Del)
Согласен, полезная фича была бы.
Я воспринимаю единицу как метр, потому что в Blender по умолчанию единица равна метру, а в Godot импорт из Blender идёт один к одному. Также я ассоциирую 3D игры с играми от первого/третьего лица, где мы управляем человеком или примерно равным ему по размерам существом - не понимаю, зачем делать в 3D стратегии и подобные им жанры, которым от 3D нет практической пользы (3D - это для "погружения" в первую очередь, а для этого нужен персонаж-человечек).
В моём представлении ты кусок суши или жидкого космоса скукоживаешь до квадрата 1х1 метр, а не определяешь единицу пространства равной 1 км или 1 парсек. А вообще, 3D стратегии - это как шахматы в 3D: выглядит прикольно, но бесполезно и только мешает. И там как и в шахматах размерность клеток значения не имеет: ты мыслишь не размерами, а самими клетками.
Меня вот больше интересует восприятие пространства с точки зрения игрока. И я не про FOV, это другое. Приведу пример на двух играх: TerraTech и Scrap Mechanic. В самом общем виде они одинаковы: мы строим некие технические приспособления для добычи ресурсов и выживания на абстрактной плоской планете. Но в TerraTech всё выглядит очень маленьким, буквально игрушечным: маленькие машинки из детских кубиков катаются вокруг маленьких деревьев, собирая какие-то крошки, масштаба совсем не чувствуется, хотя, если подумать, все машины просто гигантские (начальная кабина = кабина УАЗ СГР, но это минимальный по размеру блок). В то же время в Scrap Mechanic масштабы чувствуются в полной мере: есть и деревья-гиганты, и многоэтажные здания, а ты строишь почти настоящий полноразмерный грузовик, хотя с высоты зданий он и выглядит крошечным, а в лесу вообще легко потерять за деревьями. Вот как так? Неужели всё дело только в расстоянии камеры до того, чем мы управляем, и ракурсе камеры (сверху/снизу)? Хочется, чтобы в игре ощущалась масштабность, не было лишней "игрушечности", независимо от вида графики и геймплея. В том же Scrap Mechanic графика очень мультяшная, но это не мешает ощущать масштабность объектов, они не выглядят игрушечными несмотря на мультяшный внешний вид. Как добиться такого ощущения, интересно...
>Это тогда надо как в блендере делать, настройку где ты сам укажешь и эта единица будет приписываться во всех полях объектов.
Согласен, полезная фича была бы.
>абстрактные юниты
Я воспринимаю единицу как метр, потому что в Blender по умолчанию единица равна метру, а в Godot импорт из Blender идёт один к одному. Также я ассоциирую 3D игры с играми от первого/третьего лица, где мы управляем человеком или примерно равным ему по размерам существом - не понимаю, зачем делать в 3D стратегии и подобные им жанры, которым от 3D нет практической пользы (3D - это для "погружения" в первую очередь, а для этого нужен персонаж-человечек).
>А в РТС клетка может быть 1 км. А в космостратегии 1 парсек.
В моём представлении ты кусок суши или жидкого космоса скукоживаешь до квадрата 1х1 метр, а не определяешь единицу пространства равной 1 км или 1 парсек. А вообще, 3D стратегии - это как шахматы в 3D: выглядит прикольно, но бесполезно и только мешает. И там как и в шахматах размерность клеток значения не имеет: ты мыслишь не размерами, а самими клетками.
Меня вот больше интересует восприятие пространства с точки зрения игрока. И я не про FOV, это другое. Приведу пример на двух играх: TerraTech и Scrap Mechanic. В самом общем виде они одинаковы: мы строим некие технические приспособления для добычи ресурсов и выживания на абстрактной плоской планете. Но в TerraTech всё выглядит очень маленьким, буквально игрушечным: маленькие машинки из детских кубиков катаются вокруг маленьких деревьев, собирая какие-то крошки, масштаба совсем не чувствуется, хотя, если подумать, все машины просто гигантские (начальная кабина = кабина УАЗ СГР, но это минимальный по размеру блок). В то же время в Scrap Mechanic масштабы чувствуются в полной мере: есть и деревья-гиганты, и многоэтажные здания, а ты строишь почти настоящий полноразмерный грузовик, хотя с высоты зданий он и выглядит крошечным, а в лесу вообще легко потерять за деревьями. Вот как так? Неужели всё дело только в расстоянии камеры до того, чем мы управляем, и ракурсе камеры (сверху/снизу)? Хочется, чтобы в игре ощущалась масштабность, не было лишней "игрушечности", независимо от вида графики и геймплея. В том же Scrap Mechanic графика очень мультяшная, но это не мешает ощущать масштабность объектов, они не выглядят игрушечными несмотря на мультяшный внешний вид. Как добиться такого ощущения, интересно...
>>26264
Двачую.
Двачую.
Так годаны!
Поскольку мод или скрипт удоляет из бамплимитных тредов примерно 200-300 мусорных постов, предлагаю перекатывать примерно на 700 посте.
Дискасс.
Всем ли будет удобно?
Или катить как положено на 500-ом?
Поскольку мод или скрипт удоляет из бамплимитных тредов примерно 200-300 мусорных постов, предлагаю перекатывать примерно на 700 посте.
Дискасс.
Всем ли будет удобно?
Или катить как положено на 500-ом?
>>26277
Ну мааам! Ну можно на этот раз впезду?
Ну мааам! Ну можно на этот раз впезду?
>>26264
FOV обычно можно изменить через настройки игры. Низкий FOV выглядит как будто смотришь в подзорную трубу, а высокий - как будто немного отошёл назад. Правильно настроенный FOV зависит от пропорций экрана и личных предпочтений, и не должен влиять на восприятие игры.
Всё же склоняюсь к тому, что всё зависит от ракурса камеры. В TerraTech камеру вверх поднять почти невозможно, а приближать к технике неудобно, так и ездишь почти всё время смотря с высоты птичьего полёта вниз-вперёд. В Scrap Mechanic наоборот, можно ездить даже от первого лица, а бегать персонажем даже удобнее от первого лица, чем от третьего, и камера от третьего лица слишком далеко не отдаляется, по ощущениям примерно как в GTA. Вопрос в том, если отдалить камеру далеко вверх, сильно ли изменится восприятие сцены, станет ли она "игрушечной" только из-за этого? Если нет, то дело в чём-то другом. Может, я просто под общим впечатлением делаю предвзятую оценку...
>>26271
Перекатывай как положено, не наша проблема, что старые треды опустели. Не наши посты удаляют и не мы их удаляем, не нам и решать эту проблему. А если Годо-треда не будет на нулевой, новички могут случайно вступить в какое-нибудь юнити или чего похуже.
FOV обычно можно изменить через настройки игры. Низкий FOV выглядит как будто смотришь в подзорную трубу, а высокий - как будто немного отошёл назад. Правильно настроенный FOV зависит от пропорций экрана и личных предпочтений, и не должен влиять на восприятие игры.
Всё же склоняюсь к тому, что всё зависит от ракурса камеры. В TerraTech камеру вверх поднять почти невозможно, а приближать к технике неудобно, так и ездишь почти всё время смотря с высоты птичьего полёта вниз-вперёд. В Scrap Mechanic наоборот, можно ездить даже от первого лица, а бегать персонажем даже удобнее от первого лица, чем от третьего, и камера от третьего лица слишком далеко не отдаляется, по ощущениям примерно как в GTA. Вопрос в том, если отдалить камеру далеко вверх, сильно ли изменится восприятие сцены, станет ли она "игрушечной" только из-за этого? Если нет, то дело в чём-то другом. Может, я просто под общим впечатлением делаю предвзятую оценку...
>>26271
Перекатывай как положено, не наша проблема, что старые треды опустели. Не наши посты удаляют и не мы их удаляем, не нам и решать эту проблему. А если Годо-треда не будет на нулевой, новички могут случайно вступить в какое-нибудь юнити или чего похуже.
>>26279
Окей, перекат будет после полудня МСК.
Окей, перекат будет после полудня МСК.
240 Кб, 1920x1080Суп. Хочу в рантайме процедурно составлять тайлмапу из заранее нагенерированных и сохранённых «комнат», киньте какой-нибудь мануал/пример на этот счёт, а? А то вангую, что моя велосипедная реализация с txt-файликом будет очень уж далека от best practices.
>>26287
Какие бест практисис, в процедурной генерации нет никаких готовых и правильных решений, это чисто искусство, как рисование, только формулами и алгоритмами. Ну а банальщину вроде "не делать стопицот вложенных друг в друга циклов, иначе это займёт времени до отключения света за неуплату" ты и сам знаешь.
Используй JSON, в Годо встроенная реализация для чтения и записи, не придётся выдумывать свой парсер. Всё равно в памяти свой txt-файл ты преобразуешь в набор массивов и словарей, так почему бы не использовать JSON, в котором они очень просто описываются.
Алсо я не совсем понял, что ты хочешь. Комнаты будут процедурно генерироваться, а потом процедурно совмещаться друг с другом? При чём тут тогда txt? Или ты хочешь хранить в txt созданные вручную комнаты? Я думаю, в случае вручную создаваемых комнат лучше использовать tscn сцену с тайлмапой, в которой ты визуально создаёшь комнату, отмечая проходы в неё невидимыми тайлами. Далее твой генератор карты либо делает телепорты в соответствии с положением проходов относительно центра каждой комнаты, либо бесшовно совмещает их этими невидимыми тайлами в одной сцене, но во втором случае нужно ещё позаботиться о геометрии, чтобы не было пересечений границ комнат. В общем, как-то так я бы сделал...
>процедурно составлять тайлмапу из заранее нагенерированных и сохранённых «комнат»
>best practices
Какие бест практисис, в процедурной генерации нет никаких готовых и правильных решений, это чисто искусство, как рисование, только формулами и алгоритмами. Ну а банальщину вроде "не делать стопицот вложенных друг в друга циклов, иначе это займёт времени до отключения света за неуплату" ты и сам знаешь.
>реализация с txt-файликом
Используй JSON, в Годо встроенная реализация для чтения и записи, не придётся выдумывать свой парсер. Всё равно в памяти свой txt-файл ты преобразуешь в набор массивов и словарей, так почему бы не использовать JSON, в котором они очень просто описываются.
Алсо я не совсем понял, что ты хочешь. Комнаты будут процедурно генерироваться, а потом процедурно совмещаться друг с другом? При чём тут тогда txt? Или ты хочешь хранить в txt созданные вручную комнаты? Я думаю, в случае вручную создаваемых комнат лучше использовать tscn сцену с тайлмапой, в которой ты визуально создаёшь комнату, отмечая проходы в неё невидимыми тайлами. Далее твой генератор карты либо делает телепорты в соответствии с положением проходов относительно центра каждой комнаты, либо бесшовно совмещает их этими невидимыми тайлами в одной сцене, но во втором случае нужно ещё позаботиться о геометрии, чтобы не было пересечений границ комнат. В общем, как-то так я бы сделал...
>>26293
Пока я скорее хочу вручную понаделать кусков, а потом уже собирать из них уровень, по крайней мере с этого начать. И каждый уровень делать сценой из одной стартовой локации, а потом при загрузке или даже прямо по прохождению триггеров шлёпать подряд случайно выбранные комнаты. (С геометрией проблем не будет, потому что предполагается геймплей раннера с извращениями.)
Пока я скорее хочу вручную понаделать кусков, а потом уже собирать из них уровень, по крайней мере с этого начать. И каждый уровень делать сценой из одной стартовой локации, а потом при загрузке или даже прямо по прохождению триггеров шлёпать подряд случайно выбранные комнаты. (С геометрией проблем не будет, потому что предполагается геймплей раннера с извращениями.)
> static func pred(value : int) -> int: return value -1
> static func succ(value : int) -> int: return value +1
Каких бы ещё олдовых функций добавить в коробку?
>>26257
Просто делаешь функцию:
Func dict_get(id:int):
if all_def_value:
Return all_def_value;
Return dict.get(id, all_def_value);
Готово. Значение мгновенно изменится на дефолтное у всех.
Просто делаешь функцию:
Func dict_get(id:int):
if all_def_value:
Return all_def_value;
Return dict.get(id, all_def_value);
Готово. Значение мгновенно изменится на дефолтное у всех.
>>26315
Во-о-о, спасибо. Пойду разбирать, чего там нагорожено.
Во-о-о, спасибо. Пойду разбирать, чего там нагорожено.
>>26319
С чего ты решил, что ему нужно значение по умолчанию? И кроме того, что будет, если какой-то объект сохранит полученную ссылку себе и не будет её обновлять? А если запишет какое-то значение по полученной ссылке? Твой "all_def_value" в любой момент может перестать быть "all_def_value", потому что какие-то значения стали другими. Чтобы этого не произошло, нужно сделать так:
Т.е. создать копию, скопировав все ключи и значения, включая вложенные массивы и словари. Тогда эту копию можно будет изменять, не повреждая all_def_value. Но всё это не имеет смысла, потому что изначально была задача избежать прохода циклом по всем ключам, что и делает duplicate() для копирования словаря.
>all_def_value
С чего ты решил, что ему нужно значение по умолчанию? И кроме того, что будет, если какой-то объект сохранит полученную ссылку себе и не будет её обновлять? А если запишет какое-то значение по полученной ссылке? Твой "all_def_value" в любой момент может перестать быть "all_def_value", потому что какие-то значения стали другими. Чтобы этого не произошло, нужно сделать так:
>return all_def_value.duplicate(true)
Т.е. создать копию, скопировав все ключи и значения, включая вложенные массивы и словари. Тогда эту копию можно будет изменять, не повреждая all_def_value. Но всё это не имеет смысла, потому что изначально была задача избежать прохода циклом по всем ключам, что и делает duplicate() для копирования словаря.
А вот и >>826340 (OP)
>>26308
Ну, это можно просто сделать.
Делаешь комнаты в разных .tscn.
У комнаты в скрипте объявляешь:
И заполняешь его ссылками res:// на те комнаты, которые могут быть рандомно подставлены после текущей.
Стартовая комната ничем от одной из следующих не отличается, такой же скрипт, такой же список сцен.
Для удобства можно сохранить список сцен в виде .tres файла, чтобы подставлять его в разные комнаты без изменений, для этого нужно создать Resource:
В скрипте комнаты:
Создаёшь в файловой системе ресурсы RoomList, настраиваешь их и заполняешь ими комнаты.
Как альтернатива, можно использовать наследование сцен. Допустим, у тебя есть тип комнаты "длинный коридор" и "квадратная комната", при этом после коридора может следовать только квадрат, а после квадрата только коридор. Создаёшь две сцены-пустышки и делаешь от них дочерние сцены - варианты комнат и коридоров. Теперь, заполняя поля сцен-предков, все потомки получат такие же параметры... должны, во всяком случае.
Ну, это можно просто сделать.
Делаешь комнаты в разных .tscn.
У комнаты в скрипте объявляешь:
>export var possible_next_rooms: Array
И заполняешь его ссылками res:// на те комнаты, которые могут быть рандомно подставлены после текущей.
Стартовая комната ничем от одной из следующих не отличается, такой же скрипт, такой же список сцен.
Для удобства можно сохранить список сцен в виде .tres файла, чтобы подставлять его в разные комнаты без изменений, для этого нужно создать Resource:
>class_name RoomList
>extends Resource
>export var room_list: Array
В скрипте комнаты:
>export var possible_next_rooms: Resource
Создаёшь в файловой системе ресурсы RoomList, настраиваешь их и заполняешь ими комнаты.
Как альтернатива, можно использовать наследование сцен. Допустим, у тебя есть тип комнаты "длинный коридор" и "квадратная комната", при этом после коридора может следовать только квадрат, а после квадрата только коридор. Создаёшь две сцены-пустышки и делаешь от них дочерние сцены - варианты комнат и коридоров. Теперь, заполняя поля сцен-предков, все потомки получат такие же параметры... должны, во всяком случае.
>>26346
Вот это я схороню для своей Wunderspiele, которая в соседней папочке пылью и паутиной покрывается.
Но сейчас мне плодить сцены точно не хочется, в частности из-за платформинга, чтобы не лечить потом баги вида «хитбокс проваливается под землю в комнате № 37» (хотя на самом деле просто нужно слои в рантайме включать, и тогда проблем не будет). Мне по сути нужно просто быстро изменить кучку тайлов, координаты которых легко вычисляются.
Вот это я схороню для своей Wunderspiele, которая в соседней папочке пылью и паутиной покрывается.
Но сейчас мне плодить сцены точно не хочется, в частности из-за платформинга, чтобы не лечить потом баги вида «хитбокс проваливается под землю в комнате № 37» (хотя на самом деле просто нужно слои в рантайме включать, и тогда проблем не будет). Мне по сути нужно просто быстро изменить кучку тайлов, координаты которых легко вычисляются.
Каким образом создавать вьюпорты на сцене так, чтобы они НЕ ЛАГАЛИ при первом создании? Godot 3.4.4
Вьюпорт нужен потому что требуется на набор спрайтов-чилдов применить один и тот же шейдер, а у этих спрайтов есть свои шейдеры.
Вьюпорт нужен потому что требуется на набор спрайтов-чилдов применить один и тот же шейдер, а у этих спрайтов есть свои шейдеры.
Сап Годотач
Выпал из геймдева когда осознал насколько уебански работают шейдеры вызывая адские подлагивания.
Так вот:
Пофиксили?
Выпал из геймдева когда осознал насколько уебански работают шейдеры вызывая адские подлагивания.
Так вот:
Пофиксили?
>>29134
Пользуйся профайлером и находи проблему.
Пользуйся профайлером и находи проблему.
>>29134
Пруфы где? Не испытывал никаких "подлагиваний" ни со стандартными шейдерами, ни с самописными. За исключением компиляции шейдера в самом начале всё идёт достаточно гладко (хотя бывают некоторые странные "заикания", но в играх на юнити/анриле у меня вообще <30 фпс обычно с просадками до нуля, а на Годо 200-300 фпс с просадками до 60, так что не вижу проблемы).
>работают шейдеры вызывая адские подлагивания
Пруфы где? Не испытывал никаких "подлагиваний" ни со стандартными шейдерами, ни с самописными. За исключением компиляции шейдера в самом начале всё идёт достаточно гладко (хотя бывают некоторые странные "заикания", но в играх на юнити/анриле у меня вообще <30 фпс обычно с просадками до нуля, а на Годо 200-300 фпс с просадками до 60, так что не вижу проблемы).
Почему ваша синяя хуила крашит мне драйвер на видеокарту? Что само двигло (глес 2/3 оба крашат), что игры на нем (круелти сквад, дом кипер). Я хотел чилово копать желтые квадраты, а по итогу безрезультатно пляшу с бубном. Карточка нвидия ион ес че
Заранее извините за глупый вопрос начинающего. Возможно ли на Godot собрать проект уровня Project Zomboid? Если я реализую мультиплеер, 3D лоуполи чарактеров, нпс, мобов через вьюпорты, экшен боевку, всё это на 2D изометрической тайловой сетке в открытом мире с биомами, сменой климата, циклом день/ночь, насколько Godot удачное/неудачное решение для такого проекта в сравнении с Unity/UE?
Скоро у меня появится много свободного времени и мне бы хотелось изучив движок приступить к разработке игры мечты, диздок которой я периодически пишу уже 5 лет.
Ещё раз простите, если вас вырвало, пока вы читали мой шизоидный высер.
Скоро у меня появится много свободного времени и мне бы хотелось изучив движок приступить к разработке игры мечты, диздок которой я периодически пишу уже 5 лет.
Ещё раз простите, если вас вырвало, пока вы читали мой шизоидный высер.
>>33668
Прототип такого за 2-3 недели делается(на готовых 3д ассетах), так что если у тебя много времени, просто попробуй и узнаешь чего хватает-не хватает. Из подводных могу сказать, в подобной игре столкнулся с неудобными методами создания обводки (когда надо выделить персонажа/объект), и с тенями придется повозиться. Хотя если у тебя долгострой, возможно ты дождешься 4.2 и у тебя все будет хорошо. А так, Godot всегда к удаче, что тут сомневаться.
Прототип такого за 2-3 недели делается(на готовых 3д ассетах), так что если у тебя много времени, просто попробуй и узнаешь чего хватает-не хватает. Из подводных могу сказать, в подобной игре столкнулся с неудобными методами создания обводки (когда надо выделить персонажа/объект), и с тенями придется повозиться. Хотя если у тебя долгострой, возможно ты дождешься 4.2 и у тебя все будет хорошо. А так, Godot всегда к удаче, что тут сомневаться.
>>15359 (OP)
Мне надо получить список методов выбранного объекта. Какие есть варианты?
Я попробовал юзать get_method_list, но он выдаёт методы, включая унаследованные, а мне надо раздельно по каждому объекту выводить списки.
Я попробовал нагородить велосипед, в котором я указываю искомый объект и объект-предок, для каждого из них получаю список методов, а затем удаляю методы из искомого списка, содержащиеся в предковом списке. Но тут другая трабла. Мне нужны списки для абстрактных классов, которые нельзя инстанцировать, а мой велосипед работает только с инстансами, но не с классами.
На пикчах мой код и что я хочу получить, пикча три для каждого класса в движке.
Может быть у кого-то из годанов есть готовый велосипед на такой случай?
Может попытаться распарсить заголовочные файлы?
Мне надо получить список методов выбранного объекта. Какие есть варианты?
Я попробовал юзать get_method_list, но он выдаёт методы, включая унаследованные, а мне надо раздельно по каждому объекту выводить списки.
Я попробовал нагородить велосипед, в котором я указываю искомый объект и объект-предок, для каждого из них получаю список методов, а затем удаляю методы из искомого списка, содержащиеся в предковом списке. Но тут другая трабла. Мне нужны списки для абстрактных классов, которые нельзя инстанцировать, а мой велосипед работает только с инстансами, но не с классами.
На пикчах мой код и что я хочу получить, пикча три для каждого класса в движке.
Может быть у кого-то из годанов есть готовый велосипед на такой случай?
Может попытаться распарсить заголовочные файлы?
>>33705
Они уже распарсены
https://github.com/godotengine/godot-headers/blob/3.x/api.json>Sync API Основано на Latest commit 1049927 on Aug 3
Чтобы получить свежие, можно запустить движок так: godot --gdnative-generate-json-api api.json
Они уже распарсены
https://github.com/godotengine/godot-headers/blob/3.x/api.json>Sync API Основано на Latest commit 1049927 on Aug 3
Чтобы получить свежие, можно запустить движок так: godot --gdnative-generate-json-api api.json
>>33702
Не знаю где ты чсв разглядел, в синей хуиле разве что. Это планировалось как шутейка, но у меня чувство юмора в канаве. Бтв, краши пофиксились добавлением одной строчки в реестр, просто кто-то гуглить не умеет
Не знаю где ты чсв разглядел, в синей хуиле разве что. Это планировалось как шутейка, но у меня чувство юмора в канаве. Бтв, краши пофиксились добавлением одной строчки в реестр, просто кто-то гуглить не умеет
87 Кб, 225x225>>33731
Не только ты ещё подробно и плотно держал в курсе, что ты хотел, и как, и на каком железе.
> в синей хуиле разве что
Не только ты ещё подробно и плотно держал в курсе, что ты хотел, и как, и на каком железе.
>>33733
Всегда стараюсь описать проблему как можно точнее, чтоб дополнительных вопросов не возникало. Если для тебя это считается чсв – твои проблемы
Всегда стараюсь описать проблему как можно точнее, чтоб дополнительных вопросов не возникало. Если для тебя это считается чсв – твои проблемы
10 Кб, 465x117Пентипл, лол
Тред утонул или удален.
Это копия, сохраненная 2 марта в 10:12.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 2 марта в 10:12.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.