Шапка: https://hipolink.me/godothread
Предыдущий 82: >>1097332 (OP)
---
Maintenance release: Godot 4.7.2: https://godotengine.org/article/maintenance-release-godot-4-7-2/
Maintenance release: Godot 3.6.3: https://godotengine.org/article/maintenance-release-godot-3-6-3/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
Я не сделал игру.
Анатолий Э. Тавомалов
Пока что скрестил элементы из пары проектов и немного смоделил пушки из мешинстанстов. Думаю ещё начну постепенно глубже изучать блендер, чтобы делать более приятную глазу картинку если не задушусь, в таком случае всё будет как будет
Ого, ты вернулся, а то я думал, куда ты пропал...
А что с тем киберпанк-шутером со световыми мечами? Почему бы не добавить выживание, РПГ-прокачку и квесты в открытом мире прямо туда? Мне кажется, киберпанк-сеттинг с крысами-мутантами и всякими киборгами интереснее, чем очередной "казуальный выживач" в лесу с охотничьим ружьём.
Но ладно. По видео могу сказать: если это глухой лес и игрок будет проводить в нём кучу времени, ища ресурсы и борясь с животными/монстрами, то тебе обязательно нужен ландшафт с холмами, оврагами, обрывами, речушками, какими-нибудь пещерами/канализацией (лол, рядом с городом бывает и такое: идёшь по лесу, а там раз - бетонная дырка канализации посреди ничего, как какой-то артефакт древней цивилизации) и другими подобными деталями местности. Потому что бегать по плоскости будет очень скучно, и это довольно нереалистично, на мой взгляд. Поэтому первым делом нужно сделать/скачать и протестировать ландшафт. Не обязательно воксельный, на картах высот можно сделать много чего интересного. Взаимодействие с ландшафтом в 3D выживалке очень важно.
А "приятная глазу картинка" складывается в основном из работы с текстурами (особенно если это стилизованная игра) и написания кастомных шейдеров. На одних только мешах из блендера ты не уедешь далеко, и, ИМХО, работать по ААА-пайплайну (хайполи печётся в лоуполи) намного дольше и сложнее, чем просто покрасить лоуполи/мидлполи мультяшными/пережатыми текстурками и потом щедро обмазаться динамичными шейдерами в движке. В общем-то, твоя киберпанк игра уже неплохо выглядела для своей ниши, а с этим выживанием в лесу ты непонятно чего добиваешься...
>выживач
Снес ракетницей белочку, распилил ветки деревьев пулеметом, разжег костёр гранатой - сготовил белочку, выжил.
Грубо говоря так и будет! А крафт будет выглядеть как просто скидывание категоризированных предметов в кучу две штуки второго тира кожи соединяем с первым тиром ветки и получаем палатку в которой восстанавливаем здоровье и силы
>>1105125
>Ого, ты вернулся, а то я думал, куда ты пропал...
>А что с тем киберпанк-шутером со световыми мечами?
А я как раз им и занимался. В целом. Всё основное что хотел там сделать, было сделано кроме мультиплеера, но на него уже не осталось моральных сил и после демо фестиваля в стиме в октябре она выйдет. Компания и сюжет есть. Боевка и прогрессия есть. Фарм валюты для покупки скинов и пара арен для аутирования тоже. Можно было бы дальше игру шлифовать и наполнять контентом, но я уже немного устал от неё и есть ощущение бессмысленности перед последующими стараниями, поэтому пусть всё будет как будет, посмотрю отзывы в будущем и сделаю выводы для будущей части хочу развивать эту серию и в целом вселенную с широким таймлайном
>Почему бы не добавить выживание, РПГ-прокачку и квесты в открытом мире прямо туда? Мне кажется, киберпанк-сеттинг с крысами-мутантами и всякими киборгами интереснее, чем очередной "казуальный выживач" в лесу с охотничьим ружьём.
Вообщеееее... Изначально так и планировал. И собсна кирпичики складывал ещё в самурайской игре. Но по нескольким причинам решил взять за основу другой контроллер персонажа:
1) Я в целом устал от прошлого контроллера, поэтому нужно переключиться на что-то новое.
2) Я хотел добавить больше стилей борьбы и развитие боев на мечах, рукопашку, больше пушек, выживание как в метал гире 3, а так же улучшить графику. Но, честно говоря, думаю этот "вес" я пока не смогу осилить речь не только про программирование, но и модели и левел дизайн, и будет правильней отработать часть механик и подтянуть скилы на проекте по проще.
Поэтому в общем чет посидев и покурив, вспомнил про старый иммерсив сим темплейт для годота, COGITO, в целом давно его заприметил, и так же давно хотел начать пробовать на нём что-то запилить, но был занят самураем. В итоге скачал его и посмотрел. В целом прикольный аддон, но потыкавшись, геймплейно мне он показался каким-то топорным, да и те вещи, которые хотелось бы украсть, можно впринципе и самому и понятней для себя сделать, поэтому взглянул на один свой джемовый проект. Ну и тут собственно появился образ будущей игры, иммерсивный выживач, где в безопасных деревнях можно пить пиво и делать квесты, а за их пределами преодолевать многокиллометровые расстояния и выживать в дикой местности.
>Мне кажется, киберпанк-сеттинг с крысами-мутантами и всякими киборгами интереснее, чем очередной "казуальный выживач" в лесу с охотничьим ружьём.
Игра планируется как приквел, в котором закину удочку на эволюцию крыс. Грубо говоря это постапокалипсис в тайге с мутантами, и военными структурами подчиняющими местных голожопых аборигенов. В целом мне кажется этот сеттинг не менее интересным, и развить его можно прям вообще в любую сторону.
>если это глухой лес и игрок будет проводить в нём кучу времени, ища ресурсы и борясь с животными/монстрами, то тебе обязательно нужен ландшафт с холмами, оврагами, обрывами, речушками, какими-нибудь пещерами/канализацией (лол, рядом с городом бывает и такое: идёшь по лесу, а там раз - бетонная дырка канализации посреди ничего, как какой-то артефакт древней цивилизации) и другими подобными деталями местности
Спасибо что сказал про обрывы и канализации, добавил в список. А так да. Грубо говоря часть времени нужно будет выживать на природе, не только леса, горы, пустыши, развалины, речки.
>Поэтому первым делом нужно сделать/скачать и протестировать ландшафт. Не обязательно воксельный, на картах высот можно сделать много чего интересного. Взаимодействие с ландшафтом в 3D выживалке очень важно.
Хорошо, понял. Щас в ближайшее время закончу с функционалом пушек, и начну гуглить в эту сторону.
>А "приятная глазу картинка" складывается в основном из работы с текстурами (особенно если это стилизованная игра) и написания кастомных шейдеров
Вообще, так погуглив, насколько понял важна работа с материалами для текстур пик, это типа базовый минимум для каждой модели, который щас все делают. Ну и сами текстуры конечно нужны.
>На одних только мешах из блендера ты не уедешь далеко, и, ИМХО, работать по ААА-пайплайну (хайполи печётся в лоуполи) намного дольше и сложнее, чем просто покрасить лоуполи/мидлполи мультяшными/пережатыми текстурками и потом щедро обмазаться динамичными шейдерами в движке.
В целом, самостоятельно я все равно не вывезу хайполи, да и через чур много времени будет на модели уходить, поэтому продолжаю склонятся к лоу поли, но с большим числом полигонов и нормально выделеными материалами.
>В общем-то, твоя киберпанк игра уже неплохо выглядела для своей ниши
Спасибо!
>а с этим выживанием в лесу ты непонятно чего добиваешься...
В целом, я примерно такой образ представляю, будто в первой халфе моддер делает камерную природную локацию, но со вкраплениями бетона типа как когда выходишь к каньону в первой халфе, вроде ощущается масштаб, но и камерность ощущается. Но в целом, посмотрим что получится, свой корявый стиль конечно же органично интегрирую
К чему спрашиваю. Эта херня работает по принципу automatic lod, т.е. движок сам определяет какой array_index использовать. По идее, это должно быть лучше чем, допустим, сделать как обычно несколько lod для одного дерева и задать каждому свой visibility range.
1. Тут не будет никакого popin-popout.
2. Объект 1, а не равен количеству lod.
Единственный минус, что памяти немного больше займёт.
Я чёт подводных не вижу. Или они есть?
И да, понятное дело что количество материалов должно быть одинаковым для всех lods, а также array_tex_uv, array_normal и прочие должны тоже присутствовать (ну или заполнить ничем лол) для всех lods.
Я не понял о чём ты спрашиваешь и что сделать хочешь. Модельки, которые ты импортируешь в Godot из любого формата сами превращаются в ArrayMesh.
По умолчанию в импортере стоит галочка Generate LOD которая и LODы из модели генерирует,
https://docs.godotengine.org/en/4.7/tutorials/3d/mesh_lod.html
Это то понятно, но можно использовать тот же инструмент, чтобы лоды не генерировались, а использовались твои, сделанные в том же блендер.
Можно и свои, но придётся чутка напрячься - или написать свой импортер, или выключить генерацию LODов и подставлять разные модели, в зависимости от расстояния до камеры, или воспользоваться аддоном https://github.com/puchik/godot-importance-lod или послушать свежую лекцию Кейси Муратори (пик), который показывает что ещё в 1974г Дональд Кнут писал в статье, что нефиг оптимизировать раньше времени.
Так вот я и спрашиваю, нет ли подводных.
>в зависимости от расстояния до камеры
Там немного не так работает. Оценивается не расстояние до камеры, а какой screen ratio объект на экране занимает.
Можешь попробовать послушать тут https://www.youtube.com/watch?v=l0O7KUME_K0
я не смотрел.
Про подводные я не знаю....
>Тут не будет никакого popin-popout
Почему так считаешь? Там же чётко сказано: нужно указывать float, который примерно пропорционален расстоянию, на котором LOD используется. То есть, указываешь неправильное число - будет заметно невооружённым глазом или будет бестолковым.
>Объект 1, а не равен количеству lod
Щас бы экономить на объектах...
>минус, что памяти немного больше займёт
Ты же сам сказал, что объектов меньше, лол.
>Я чёт подводных не вижу. Или они есть?
Подводные в том, что ты неправильно понимаешь:
>сделать как обычно несколько lod для одного дерева и задать каждому свой visibility range.
Настройка visibility range на нодах необходима для автоматической подмены нескольких нод одной. Ну, помнишь пасту Кирилла про корованы? Там он писал наподобие "деревья вдалеке картинкой" - так раньше повсеместно было, да и сейчас, думаю, тоже юзают.
Например, у тебя есть город. Когда игрок на улице, то детальные модели домов грузятся по отдельности и отображаются как отдельные ноды. Но когда игрок забирается в горы или на самолёте летит, весь город отображается одним лоуполи мешем - одной нодой.
С помощью LOD в ArrayMesh ты такого в принципе не сделаешь, потому что там ARRAY_INDEX - порядковые номера в ARRAY_VERTEX, ARRAY_UV и т.д. - т.е. у тебя уникальный массив точек, который РЕДУЦИРУЕТСЯ механизмом Level of Detail, а не просто подменяется.
Кроме того, использовать эту фичу через блендер не настолько просто, как кажется. Думаю, это больше процедурной геометрии подходит: чанков ландшафта, например, или чего-то подобного. Через Blender тебе придётся как-то... синхронизировать индексы мешей.
Пример: ты сделал восьмиугольник, шестиугольник и квадрат. У них разное число точек, но точки эти не совпадают друг с другом. Если квадрат ещё как-то вписывается в восьмиугольник (если увеличить), то шестиугольник имеет 2 вершины, которых у него нет.
Ещё нагрузка на GPU не столько от вершин, сколько материалов и текстур. Уменьшить нагрузку лучше с помощью упрощения шейдера и уменьшения числа обращения к текстурам. Но LOD в ArrayMesh будет использовать один и тот же материал с теми же UV.
Т.е. LOD через ArrayMesh - узкоспециализированная функция, хорошо подходящая только для простых хайпольных моделек, которые достаточно упрощать уменьшением массива индексов, без объединения с окружающими мешами и без изменений материала.
Алсо, для большой игры типа GTA 5 в любом случае потребуется писать велосипед - Godot пока не умеет в "asset streaming", который будет необходим, когда вес ассетов игры превышает объём RAM/VRAM у игрока. Жирные 150+ ГБ игры этим непрерывно занимаются.
P.S. Знаю это от интереса к процедурной генерации.
>То есть, указываешь неправильное число - будет заметно невооружённым глазом или будет бестолковым.
Ну так вот надо пытаться правильное.
>Ты же сам сказал, что объектов меньше, лол.
Ну так у тебя 1 базовый меш и 3 lod. 10к вершин, 2к, 500 и 20, итого 12520 вершин, памяти чуть больше займёт (хотя по факту также, т.к. память от упрощенных мешей теперь в одном). А объектов меньше, да.
>Через Blender тебе придётся как-то... синхронизировать индексы мешей.
Можно сделать в самом годо через скрипт. Тебе ж надо по сути сделать так
[lod0..........][lod1......][lod2...][lod3.]
Т.е. тупо присобачить нужные тебе вершины с нужным офсетом для конкретного lod. Вроде не сложно. Главное, как ты и написал, если в lod0 есть например uv2, то он во всех других должен быть.
Короче че пиздеть, завтра буду пробовать. А пока надо смену на заводе дожить.
Ты так и так вынужден подгонять числа, если хочешь смастерить свои собственные LODы. Избавиться от подгонки позволяет только механизм auto-LOD.
Память: отдельные меши имеют свои собственные ARRAY_VERTEX и т.п., а один меш будет иметь общие, поэтому памяти МЕНЬШЕ, чем если ты создаёшь LOD посредством отдельных объектов (mesh instance).
>[lod0..........][lod1......][lod2...][lod3.]
Хмм... Но тогда ты не экономишь память, и вообще непонятно, зачем ты это делаешь. Чтобы на нодах сэкономить, что ли? А почему тебе auto-LOD здесь не подходит? Выдаёт сильно некачественный вариант?
>завтра буду пробовать
У тебя есть, с чем работать? Я согласен с >>1105209
>нефиг оптимизировать раньше времени.
Если у тебя этот >>1105099 проект, то, мне кажется, рановато ты заботишься о LOD. Те же деревья... Ну, допустим, это самый маленький 3D LOD, ниже - это подменять 3D модели 2D спрайтами, не иначе...
>А почему тебе auto-LOD здесь не подходит? Выдаёт сильно некачественный вариант?
Именно. Хочу чтобы был 1 объект и о нем заботился auto lod. Но при этом lodы мои.
Ой, да делай как хочешь. Только потом не ной, что ты потратил две недели на код, который оказался тупо медленнее/жирнее по памяти/хуже по результату на экране... Тыщу раз такое было: придумываешь свой велосипед, долго его отлаживаешь, потом смотришь - колёса-то квадратные и заменить никак не выходит. Поэтому такие оптимизационные велосипеды стоит откладывать на потом, чтоб не растерять энтузиазм.
Основная причина, почему я хочу сделать с помощью auto lod, это чтобы выбор lod'a зависел от размера на экране, а не от расстояния до камеры. И он это как раз делает. А т.к. само редуцирование часто из говна, то было бы неплохо попробовать сделать свои.
Даже не знаю, с чего начать, но есть смутный вопрос/тема для обсуждения...
Не знаю, остались ли тут те, кто помнит, но в ноябре 2023 я где-то десяток дней потратил на свой собственный аддон для создания... хм, ветвящихся последовательностей чего-то? Задумывалось это как редактор на базе GraphEdit, который может быть полезен как для визуальной новеллы, так и для штук вроде катсцен и даже поведения NPC. Но это не скриптовый язык... Хотелось чего-то упрощённого, минимального, но позволяющего быстро накидать то, что роится в голове.
Основная фича: где не нужно ветвление, можно не создавать отдельные плавающие блоки и не возиться с ниточками: достаточно добавлять новые элементы в линейный блок-список. При этом элементы возможно перетаскивать из одного списка в другой мышкой и легко создавать новый, дропнув элемент в пустое пространство. Меньше развилок - граф меньше в ширину и больше в высоту. Также эти блоки-списки можно сворачивать в заголовок, чтобы можно было свернуть длинную портянку из десятков элементов и видеть только её входящие и исходящие связи. А у элементов списка могут быть теги для каких-то дополнительных функций (например, если это ВН, то удобно добавить тег-имя говорящего и тег-эмоцию, или тег-фон). Всё это GUI в той или иной степени реализовано на достаточно удобном уровне, и я вроде кидал скриншоты. Также была идея с созданием блоков-агрегатов, чтобы скрыть не только линейные портянки, но и все внутренние развилки, оставив только свободные точки входа и выхода из агрегата, но так и не дошёл до этой стадии, т.к. даже с сохранением/загрузкой возникли какие-то проблемы.
Как нетрудно догадаться, я забил на этот проект почти на три года. А на днях опять загорелось сделать что-то вроде визуальной новеллы/виртуального питомца, и я подумал - почему бы не попытаться довести этот аддон до юзабельного состояния, учитывая, что я сделал 80% от всего минимально необходимого. Начал изучать, что я наделал... И вспомнил одну проблему UI/UX, которую я тогда толком не смог решить концептуально: что делать с условными выражениями?
Но сначала поясню, зачем вообще нужны эти условия: смысл аддона в создании разветвлённых графов, а не просто линейных портянок; самый простой, базовый граф не имеет в себе никаких условий, и может быть использован для простой ВНки, где игроку доступны все выборы сразу; однако, более сложные сюжетные ветвления требуют условий разблокировки, как, например, "если есть зонтик и идёт дождь" разрешает ветку "предложить пойти вместе под одним зонтом" - необходимо где-то и как-то обозначить это условие, не так ли? Но... где?
Потенциальные варианты:
- сделать сложную форму для добавления условий (готово на 80%);
- сделать просто поле для ввода GDScript кода, и потом eval() его;
- сделать некий способ подключения функций на GDScript к графу.
Последнее я в целом планировал и без условий, то есть чтобы можно было вызывать функции, созданные на GDScript, прямо из графа, но без возврата значений; если использовать это для условных выражений, нужно будет возвращать и проверять bool для разблокировки ветки.
Изначально я начал делать форму с выпадающими списками и т.п., даже как отдельный блок, а потом подумал "зачем блок, если он будет использоваться только перед блоком-списком" и упаковал его в начало блока-списка, но потом... Что-то я засомневался, стоит ли эмулировать функциональность GDScript через такой GUI? Но если делать по-другому, не будет ли это как-то скрывать то, что реально вычисляется кодом, от внешнего представления графа в редакторе?
Даже не знаю, как иначе описать эту проблему. Мне кажется, я забил на этот проект в первую очередь из-за этой неопределённости с условиями... Где их отображать, как обрабатывать и т.д. Много неопределённого, что не так-то просто протестировать без сложного демо-проекта.
Знаю, что есть готовые решения для подобного, и я их смотрел - они мне как-то не нравятся. Текстовые скрипты мне не нравятся тем же, чем не нравится запись сценария на GDScript: все развилки становятся закопаны где-то в слоях линейного текста. Лапшичные редакторы зачастую страдают тем, что там одна реплика = один блок, и самый простой диалог вырастает в ширину очень быстро, что крайне неудобно, особенно когда каждый блок с кучей своих свистелок.
Что думаете? Чем вы пользуетесь для подобного? Как ощущения?
- Новая нода Trail3D для спецэффекта "ленточка" (Line3D могут добавить в будущем).
- Группировка нод визуальных шейдеров, позволяющая переиспользовать куски кода.
- Конвертация плагинов "главного экрана" в "доки" (docks); все экраны можно двигать.
- Список методов в редакторе скриптов теперь представлен в виде аккуратного дерева.
- Label и RichTextLabel смогут автоматически масштабировать текст, чтоб он умещался.
- Аппроксимация окружающего затенения (AO) со множественными отскоками света.
- Информация об отражённом свете (specular) теперь может запекаться в LightmapGI.
- Поддержка декалей в режиме Compatibility (есть несколько ограничений на число).
- Автоматическое скачивание и установка Android и Java SDK для экспорта на Android.
- Улучшение редактирования Polygon2D (по сути, фикс ошибки).
- Что-то связанное с анимациями - я не понял, лень разбираться...
- Фикс избыточного потребления ресурсов CPU в фоне (CoreAudio).
- Ускорение доступа к полям Object до x1.6 раз благодаря GDType.
- Превью замены текста во множестве файлов функции Find in Files.
- Кнопка для скрытия оверлея с метаданными в превью у текстуры.
- Очистка/упрощение заголовка инспектора (кнопки в бургер-меню).
- GDScript: предупреждение антипаттерна """строк-комментариев""".
- Разрешено провозглашать тост во время застолья с окошками!🥂
> Информация об отражённом свете (specular) теперь может запекаться в LightmapGI.
А ведь когда-то допрут до того, что запекать можно и вектор нормаля
Я бы рекомендовал посмотреть на старый добрый редактор квестов для Космических Рейнджеров (2), скорее всего он натолкнёт тебя на правильные мысли. Там конечно будут гейм-специфик константы, типа списка рас, такие вещи тебе у себя придётся перепридумать, как некие глобальные теги или переменные.
>Новая нода Trail3D для спецэффекта "ленточка"
Нечто переписывает код китайца на классы годота, используя ИИ (конечно я верю что он использовался только для поиска по коду, как оно пишет в первом сообщении)
В обзоре пишут что китаец taking a stab (пукнул-сренькнул, в контексте) в процессе своей реализации, но указывают что практически просто взяли его алгоритмы
Помогать нечту пришли все, только что сам Хуан не пришёл, все мегазанятые контрибуторы нашли время чтобы указать на проблемы в коде. Как починить что-то - так у них времени нет, постоянно пишут в статьях про это, как вычитывать кумовской нейрослоп - так пожалуйста, ведь надо помочь закрыть такой важный пропосал от этого нечто.
Как же тебя трудно читать, я нефига не понял. Можешь попросить нейронку чтобы она за тебя написала осмысленный текст?
Хуан, вроде, уже пару лет не пишет код, а занимается бизнесом W4.